From joey at nicewarrior.org Thu Jan 1 03:20:40 2004 From: joey at nicewarrior.org (Joey Parrish) Date: Wed, 31 Dec 2003 20:20:40 -0600 Subject: [MPlayer-G2-dev] framer API, demuxer chaining In-Reply-To: <20031231171137.521376f0.attila@kinali.ch> References: <20031231154153.557CF2009F@mail.mplayerhq.hu> <20031231160652.GA17610@nicewarrior.org> <20031231171137.521376f0.attila@kinali.ch> Message-ID: <20040101022039.GA18913@nicewarrior.org> On Wed, Dec 31, 2003 at 05:11:37PM +0100, Attila Kinali wrote: > You are too slow :) > See also Richs mail. Bah! Rich's mail came 5 minutes after mine (ignoring timezones). > We discussed this already on irc: All streams need to be opened. Serves me right for never using irc. :) --Joey -- "I know Kung Fu." --Darth Vader From arpi at thot.banki.hu Thu Jan 1 03:26:25 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 1 Jan 2004 03:26:25 +0100 (CET) Subject: [MPlayer-G2-dev] VP layer progress In-Reply-To: <20031219123858.GH7833@brightrain.aerifal.cx> Message-ID: <20040101022625.6AA1C1FF0D@mail.mplayerhq.hu> Hi, > In the interest of promoting discussion, I'd like to open up my > in-progress VP code for public viewing. Keep in mind this is under > constant revision, and probably doesn't compile, and would earn me > crates full of cola if it were actually used in some sort of release. > :)))) > > http://brightrain.aerifal.cx/~dalias/vp-in-progress/ i've just read API3 doc from the above url. some notes: PRESERVE/REUSABLE vs locking: think again my idea, of using 2 locks (a read lock and a write lock) instead of singel lock and these flags. anywya, where do you want to put the locks and the flags? they will be link-only or be passed together with the image data? (i mean each link/context will have its own lock and flags, or the structure containing teh buffer pointers will have it, and it will be passed to next filters?) query_format: i very like the idea of reporting 'distance' of fault. clever!!! what i miss: - stride handshaking/negotiation (including 'classic' stride flags of g1, for MB aligned, byte-aligned, pixel-aligned, and for planar modes the inter-plane restrictions like uvstride*2=ystride etc) - aspect ratio handling about locking implementation: PLEASE do it using functions to lock/unlock, do not alow the nodes change the lock variable directly. why? we should add high level of (optional) debugging/tracing support to the vp core. ie. something like 'lock log' where you track which filters set which locks etc, so in case of debugging enabled you can print detailed info on buffers status. very useful when hunting image corruptions, sig11s, memleaks. i've spent lots of time in both g1 and especially in g2 with adding printfs to find out what happens to a buffer and where does it get free'd before it should, or be overwritten. also, such code not only helps debugging, but could (in case of trace/debug enabled, to avoid performance loss for end-users) detect invalid cases, so badly written filters will trigger asserts/errors insteda of silly sig11s and leaks. helps a lot for bugreports... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Thu Jan 1 03:43:35 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 1 Jan 2004 03:43:35 +0100 (CET) Subject: [MPlayer-G2-dev] Rich's TODO Message-ID: <20040101024335.1C91B1FF0D@mail.mplayerhq.hu> Hi, pre-note: here is already 2004, so time to get back to g2 development :) notes for http://brightrain.aerifal.cx/~dalias/vp-in-progress/TODO: vo2-vp wrapper ============== * remove and make vo drivers vp-native (?????) NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! my No.1 goal making g2 was to keep vo driver as simple and minimal as possible. they should not do more than knowing the underlaying driver or hardware, and exporting the resource. why? - vo drivers will be written for many platforms, archs, drivers, we won't eb able to change them or even test them after some api change. - if vo drivers implement complicated vp API, we'll end up having the same isses as g1 hasve: some vo drivers in some vf+vd combinations do flicker, corruption etc. nera impossible to debug them without having that architecture/card/driver. - vo drivers will be mostly written other developers, wihtout vp knowledge, so to avoid broken api implementation (see g1) we should keep api as simple as we can. - no need to duplicate same vp interface code in every vo driver, make a clever vp->vo wrapper. - keep vo layer vp-idnependent, ie. usable without vp code (for other projects etc. i knwo it sounds silly now, but if more project will start use libvo2, it may be sooner-or-later the defacto standard replacing SDL etc... :)) i always vote for keeping the various layers independent, and add wrappers between them. better for testing, and changing API of one wont require us to patch many files of the other layers. yes i know you hate wrappers, i also hate them, at least silly ones. demuxers ======== * convert to use rate_d/rate_m based pts rather than 1/rate_d already discussed, ok * clean up nonsense pts flags for example? * pts==0 is used to indicate "not available", this is broken. change! agree. i also found it broken, but it was too late then :) anyway i'm open for idea how to pass 'broken' value in an 'int' variable? (actually 'int' may be too limited for pts anyway) * always seek to a point with known exact pts! why? for raw streams, you simply cannot do that. for example .mp3 * remove resync_audio_stream already discussed, i agree. it should even be done for g1 too. * instead have seek be driven from vp/ap layer huh? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Thu Jan 1 06:11:35 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 1 Jan 2004 00:11:35 -0500 Subject: [MPlayer-G2-dev] VP layer progress In-Reply-To: <20040101022625.6AA1C1FF0D@mail.mplayerhq.hu> References: <20031219123858.GH7833@brightrain.aerifal.cx> <20040101022625.6AA1C1FF0D@mail.mplayerhq.hu> Message-ID: <20040101051135.GS257@brightrain.aerifal.cx> On Thu, Jan 01, 2004 at 03:26:25AM +0100, Arpi wrote: > i've just read API3 doc from the above url. > some notes: > > PRESERVE/REUSABLE vs locking: > think again my idea, of using 2 locks (a read lock and a write lock) > instead of singel lock and these flags. IMO it's not possible. It doesn't matter for AUTO (allocated) buffers, but for DIRECT and EXPORT it matters a lot. For example, a vo driver or filter might _not_ be able to provide a buffer if REUSABLE or PRESERVE is needed. Buffers in video memory definitely are not reusable (for very next frame, but might be reusable at some later time). I don't know how to properly handle this. It's related to buffer age... Also think of EXPORT buffers. If PRESERVE isn't set, the dest filter is allowed to trash the (possibly internal) buffers of the source while processing. > anywya, where do you want to put the locks and the flags? they will > be link-only or be passed together with the image data? > (i mean each link/context will have its own lock and flags, or the > structure containing teh buffer pointers will have it, and it will be > passed to next filters?) My design has always been that locks should be on mpi's, not buffers. But perhaps it's worth discussing. > query_format: > i very like the idea of reporting 'distance' of fault. clever!!! Yes, I'm not sure how useful it is, but it could be nice. Actually I think we need a more advanced query system for negotiating link parameters, so the vp layer can see _why_ certain combinations fail and auto-load filters to correct. > what i miss: > - stride handshaking/negotiation > (including 'classic' stride flags of g1, for MB aligned, byte-aligned, > pixel-aligned, and for planar modes the inter-plane restrictions like > uvstride*2=ystride etc) The flags are there, but the code isn't complete. See striderest_t. The align array specifies byte alignment requirements for each plane, and the negotiation code will take the requirements and capabilities of the source and dest filter and work out a common agreed-upon stride, if possible. Otherwise expand will have to be loaded... > - aspect ratio handling SAR is negotiated at config time. Most filters can only output a single SAR: either the same as their input, or 2x or 1/2 height or something. Scale is probably the only one that can output any SAR, so provided the user has selected to use aspect correction, the vo will force scale to get loaded if it can't hardware-scale and the SAR doesn't match the monitor's pixel aspect ratio in the selected video mode. > about locking implementation: > PLEASE do it using functions to lock/unlock, do not alow the nodes > change the lock variable directly. why? I agree totally. That's why vp_lock_image exists. Rich From attila at kinali.ch Thu Jan 1 15:54:26 2004 From: attila at kinali.ch (Attila Kinali) Date: Thu, 1 Jan 2004 15:54:26 +0100 Subject: [MPlayer-G2-dev] Rich's TODO In-Reply-To: <20040101024335.1C91B1FF0D@mail.mplayerhq.hu> References: <20040101024335.1C91B1FF0D@mail.mplayerhq.hu> Message-ID: <20040101155426.025866f7.attila@kinali.ch> On Thu, 1 Jan 2004 03:43:35 +0100 (CET) Arpi wrote: > vo2-vp wrapper > ============== > * remove and make vo drivers vp-native (?????) > > NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO > OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! > > my No.1 goal making g2 was to keep vo driver as simple and minimal > as possible. they should not do more than knowing the underlaying driver > or hardware, and exporting the resource. > why? Could you then rework the vo2 api a bit to match the current vp design ? Beside i think there are still a few drawbacks inherited in the current vo design (dont ask me what exactly, it's a too long time since i read the api docs). Attila "who wants to start to rework the x11 code" Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From dalias at aerifal.cx Fri Jan 2 00:18:38 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 1 Jan 2004 18:18:38 -0500 Subject: [MPlayer-G2-dev] Rich's TODO In-Reply-To: <20040101024335.1C91B1FF0D@mail.mplayerhq.hu> References: <20040101024335.1C91B1FF0D@mail.mplayerhq.hu> Message-ID: <20040101231838.GX257@brightrain.aerifal.cx> On Thu, Jan 01, 2004 at 03:43:35AM +0100, Arpi wrote: > Hi, > > pre-note: here is already 2004, so time to get back to g2 development :) :)) > notes for http://brightrain.aerifal.cx/~dalias/vp-in-progress/TODO: > > vo2-vp wrapper > ============== > * remove and make vo drivers vp-native (?????) > > NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO > OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! > > my No.1 goal making g2 was to keep vo driver as simple and minimal > as possible. they should not do more than knowing the underlaying driver > or hardware, and exporting the resource. No need to explain, I agree. All the ? marks there meant "is this really a good idea?" and you're right that the answer is no. On the other hand, the vo drivers need to be more intelligent in how they provide buffers or we're going to run into trouble. The current method is too naive... > yes i know you hate wrappers, i also hate them, at least silly ones. I hate wrappers when they just change the names of the functions and structs and have no good reason to be there. For example in G1 we had VFCTRL_* and VOCTRL_* which were identical, mappings between control and query_format, and other nonsense which just complicated matters for developers by introducing gratuitous differences between the different api's. But if we can really make the vo api simple enough that it can be wrapped nicely, I have no objection to using a wrapper. > demuxers > ======== > * convert to use rate_d/rate_m based pts rather than 1/rate_d > already discussed, ok Thanks! > * clean up nonsense pts flags > for example? PTS_FOR_BLOCK doesn't seem to be used. (or useful?) PTS_FOR_NEXT was only created because you misunderstood mpeg audio pts, and you already said you were going to remove it. PTS_IN_DISPLAY_ORDER is at least a confusing name, and might not even be useful. (The framer could take care of the problem using DTS or something...) PTS_ACCURATE is kinda pointless. Why even set pts if it's likely to be wrong? The framer should be able to give valid pts based on the last known pts. > * pts==0 is used to indicate "not available", this is broken. change! > agree. i also found it broken, but it was too late then :) > anyway i'm open for idea how to pass 'broken' value in an 'int' variable? > (actually 'int' may be too limited for pts anyway) Do you think it's too limiting to require pts to be nonnegative? Then we could use -1 for invalid. If you'd prefer, we could have a flag for whether pts is valid instead. > * always seek to a point with known exact pts! > why? for raw streams, you simply cannot do that. for example .mp3 Hmm, sounds like a job for runtime indexbuilder. > * remove resync_audio_stream > already discussed, i agree. it should even be done for g1 too. :) > * instead have seek be driven from vp/ap layer > huh? My idea was for seek requests to be passed back thru the vp or ap layer (depending on whether the user has selected audio-based seeking or video-based...maybe this is dumb) so that one could have vf_edl (editlist) that does seeking on its own and intercepts seek requests for transparent seeking in files with editlists. But maybe you think this is dumb. IMO it could be added later without too much pain, so we could leave it out for the time being anyway until we decide if it's a good idea. Rich From ivan at cacad.com Fri Jan 2 00:54:34 2004 From: ivan at cacad.com (Ivan Kalvachev) Date: Fri, 2 Jan 2004 01:54:34 +0200 (EET) Subject: [MPlayer-G2-dev] vo3 In-Reply-To: <20031228051830.GG257@brightrain.aerifal.cx> References: <2710.212.116.154.213.1072479682.squirrel@mail.cacad.com><20031228003136.GA257@brightrain.aerifal.cx><1367.212.116.154.213.1072579883.squirrel@mail.cacad.com> <20031228051830.GG257@brightrain.aerifal.cx> Message-ID: <1289.212.116.154.213.1073001274.squirrel@mail.cacad.com> D Richard Felker III said: >> User-Agent: SquirrelMail/1.4.1 > > Ivan, if you expect a reply, please get a mailer that understands how > to wrap lines at 80 columns and preserve formatting when quoting. Your > broken SquirrelMail converted all the quotes into multi-hundred-column > unreadable jibberish. The problem is that nowdays I use public computers for internet and having my favorite mail client configured properly is luxury. Anyway wrap lines at 60, not 80 ;) > > On Sun, Dec 28, 2003 at 04:51:23AM +0200, Ivan Kalvachev wrote: >> D Richard Felker III said: >> > On Sat, Dec 27, 2003 at 01:01:22AM +0200, Ivan Kalvachev wrote: >> >> Hi, here is some of my ideas, >> >> i'm afraid that there already too late to be implemented, as >> >> dalias is coding him pipeline system, while i have not finished the >> >> drafts >> >> already, but feel free to send comments... >> > >> > Time to pour on the kerosine and light the flames... :) >> Your are very bad in making good points, you always fall in flame. I >> noticed that you like flames, even if you burn in them sometimes. > > This line was a joke. Maybe if you'd taken it as such you would have > been more thoughtful in your responses to what followed. Well as I said bellow I didn't hear any good points from you (1'st time). I also made a joke, probably the level of humor is too low, and better be dropped out completely. Do you know that there is a law in China that obligates people to always smile on the street. Simply the cities are so over-crowded that one negative person may spoil the day of 1 Million citizen. It is very easy to push people in internet. And because it is easy we should be friendly even when we talk with idiots. Otherwise the chain reaction will spoil more than our day. >> >> Here are few features that I'm trying to achieve: >> >> ? decreasing memcpy by using one and same buffer by all filters >> >> that can do it (already done in g1 as Direct Rendering method 1) >> >> ? support of partial rendering (slices and DR m2) >> > >> > These are obviously necessary for any system that's not going to be >> > completely unusably sucky. And they're already covered in G1 and G2 >> > VP. >> flame. I know that, you know that, everybody know that. > > Huh? Who am I flaming? I don't follow. I just mean that the quote and the reply could have been skipped. They don't say anything. But there is ?suck? in it. >> >> ? ability to quickly reconfigure and if possible - to reuse data that >> >> is already processed (e.g. we have scale and the user resizes the >> >> image, - only images after scale will be redone), >> > >> > In my design, this makes no sense. The final scale filter for resizing >> > would not pass any frames to the vo until time to display them. >> final scale filter?!!! >> How many scale filters do you have? > Normally only one. But suppose you did something like the following: > > -vf scale=640:480,pullup > > with output to vo_x11. The idea is that since you'll be resizing DVD > to square pixels anyway, you might as well do it before the inverse > telecine and save some cycles. Just for the protocol;) I'm sure you know that scaling interlaced frames vertically will mangle interlacing. The rest is discussed latter bellow. > > Now the user resizes the window... In yours (and Arpi's old) very bad > way, the scale filter gets reconfigured, ruining the fields. If you > don't like this example (there are other ways to handle interlacing) > then just consider something like denoising with scaling. My principle > in response is that the player should NEVER alter configuration for > any filters inserted manually by the user. Instead, it should create > its own scale filter for dynamic window resizing and final vo > colorspace conversion. > I'm sorry to say it but you cannot see the forest because there are too many trees. (that's saying/proverb) I give it as example. I like to give example that are not totally fictitious. And as you may have noticed the scale filter is the final one. So having 2 scale one after another is not very good. And as Diego says it could be used for resizing while paused, and stuff like that. About scale. Yep, I agree that it is good to have one scale filter at the end. If I am not wrong, now in G1 the scale filter is inserted constantly at one and same position, this way preventing automatic conversion except in the ordinary case. The other big problem with scale is that it makes way too many things. It makes format conversion, it scales, it makes format conversion and scale at the same time. Of course this is done to maximize speed. >> >> safe seeking, auto-insertion of filters. >> > >> > What is safe-seeking? >> When seeking filters that have stored frames should flush them >> For example now both mpeg2 decoders don't do that, causing garbage in >> B-Frames decoding after seek. Same apply for any temporal filter. >> In G1 there is control(SEEK,...), but usually it is not used. > > OK, understood perfectly. > >> > Auto-insertion is of course covered. >> I'm not criticizing your system. This comment is not for me. >> Or I hear irony? > > And I wasn't criticizing yours, here. I was just saying it's not a > problem for either system. How about new level of filter insertion - runtime insertion without dropping frames? > >> >> In short the ideas used are : >> >> ? common buffer and separate mpi ? already exist in g1 in some form ? >> >> counting buffer usage by mpi and freeing after not used ? huh, sound >> >> like java :O >> > >> > No. Reference counting is good. GC is idiotic. And you should never >> >free >> > buffers anyway until close, just repool them. >> I didn't say that. Free buffer is buffer that is not busy and could be >> reused. >> Moreover I don't like the way frames are locked in your code. It doesn't >> seem obvious. > > In VP, you will _only_ lock frames if you need to keep them after > passing them on to the next filter. Normally you shouldn't be doing > this. > At first I could understand what GC is, after i send my reply i realized that it comes from Garbage Collector :O I hate GC, I don't like java because of GC. As you may have missed (and misleaded by my java appointment) is that buffers have counters. It is simple - on MPI allocation buffer counter is increased , on MPI release it is decreased. When usage is 0 then the buffer may be reused. You see ? no locking needed. On another hand buffer reusing is of cource connected to skipped_blocks optimization. But I still have no idea how to do it :( >> The goal in my design is all the work of freeing/quering to >> be moved to vf/vp functions. So in my design you will see only >> get_image/release_image, but never lock/unlock. Because having buffer >> mean that you need it. (well most of the time) > > Keep in mind there's no unlock function. It's just get/lock/release. > > Perhaps you should spend some time thinking about the needs of various > filters and codecs. The reason I have a lock function is that the > _normal_ case is passing your image on to the next filter without > keeping it. Images could start out with 2 locks (1 for source, 1 for > dest) and then the source would have to explicitly release it when > finished, but IMHO this just adds complexity since most filters should > never think about a frame again once sending it out. Yes this is what I do. The only differense is that simple filter may release frame after it pass it to the next one. > >> >> ? allocating all mpi&buffer before starting drawing (look obvious, >> >> doesn't it?) ? in G1 filters had to copy frames in its own buffers or >> >> play hazard by using buffers out of their scope >> > >> > Yes, maybe G1 was broken. All the codecs/filters I know allocate >> > mpi/buffers before drawing, though. >> In G1 if you draw_slice out-of-order it is possible to go to a filter >> that >> haven't yet allocated buffer for this frame - some frames are allocated >> on >> put_frame. > > This is because G1 is horribly broken. Slices should not be expected > to work at all in G1 except direct VD->VO. Ouch. But your current implementation is based on the same principle.) > >> That's also the reason to have one common process()! > > I disagree. > >> >> ? using flag IN_ORDER, to indicate that these frames are "drawn" and >> >> there won't come frames with "earlier" PTS. >> > >> > I find this really ugly. >> It's the only sane way to do it, if you really do out-of-order >> processing. > > No, the draw_slice/commit_slice recursion with frames getting pulled > in order works just fine. And it's much more intuitive. > >> >> ? using common function for processing frame and slices ? to make >> >> slice >> >> support more easier >> > >> > This can easily be done at the filter implementation level, if >> > possible. In many cases, it's not. Processing the image _contents_ and >> > the _frame_ are two distinct tasks. >> Not so easy. Very few filters in G1 support slices, mainly because it >> is >> separate chain. > > No, mainly because the api is _incorrect_ and cannot work. Slices in > G1 will inevitably sig11. > Haven't you noticed that in G1 slice-ing is turned on by default? ;) >> > One thing omitted in G2 so far is allowing for mixed buffer types, >> > where different planes are allocated by different parties. For >> > example, exporting U and V planes unchanged and direct rendering a new >> >Y plane. I'm not sure if it's worth supporting this, since it would be >> > excessively complicated. However, it would greatly speed up certain >> > filters such as equalizer. >> Yes I was thinking about such hacks. But definitely they are not worth >> implementing. Matrox YUV mode need such hack, but it could be done in vo >> level. > > Actually it doesn't. The YV12->NV12 converter can just allow direct > rendering, with passthru to the VO's Y plane and its own U/V planes. > Then, on draw_slice, the converter does nothing with Y and packs U/V > into place in the VO's DR buffer. This is all perfectly valid and no > effort to implement in my design. > > The difficult case is when you want to export some planes and DR > others... > Just one tiny-mini problem. What will be locked if a filter needs the frame for later processing? Any separate buffer scheme makes these tricks very hard and hazardous. One possible solution is to have separate buffer for Y,U,V planes, also QuantTable, SkippedBlocksTbl. But then we will have to manage with multiple buffers into one mpi. It seems like solution is worse then the problem. >> >> Dalias already pointed that processing may not be strictly top from >> >> bottom, may not be line, slice, or blocks based. This question is >> >> still >> >> open for discussion. Anyway the most flexible x,y,w,h way proved to >> >> be >> >> also the most hardier and totally painful. Just take a look of crop >> >>or >> >> expand filters in G1. More over the current G1 >> >> scheme have some major flaws: >> >> ? the drawn rectangles may overlap (it depends only on decoder) >> > >> > No, my spec says that draw_slice/commit_slice must be called exactly >> > once for each pixel. If your codec is broken and does not honor this, >> > you must wrap it or else not use slices. >> The problem may arrases in filter slices too! Imagine rounding errors;) > > Huh? Rounding? WTF? You can't render half a pixel. If a filter is > doing slices+resizing (e.g. scale, subpel translate, etc.) it has to > deal with the hideous boundary conditions itself... > Yep, but you forget that x,y,w,h may have any values. In the ordinary way they will be multiple of 16, but after one resize filter, this is no longer true. And how are you gonna manage the things if you got odd x,y,w,h in YV12 image :O Now I believe that line counters from top to bottom is the most sane alternative. If the only VP3 filter draws top from bottom, then we won't process slices for it. Only full images. But I doubt that VfW codecs may do it too. Anyway they don't have slices. [snip] >> Anyway the IN_ORDER doesn't force us to display the frame. >> There is no need to start displaying frame in the moment they are >> compleated. > > Yes, but it's hard to know when to display unless you're using threads > (or the cool pageflip-from-slice-callback hack :)) > >> I agree that there may be some problems for vo with one buffer. >> So far you have one (good) point. > > I never said anything about vo with one buffer. IMO it sucks so much > it shouldn't even be supported, but then Arpi would get mad. > Same thing could be extend for decoder with n=2 static buffers at once, and vo with only 2 buffers. Same for n=n+1; Well after some brainstorming. I take my words back. That what decoder does is to delay one frame by buffering it. As my whole video filter system acts like a codec, then we should take control of the buffer delay. This could be done by adding ?global? variable LowDelay, that contains the number of frames we need to wait before starting displaying. In MPEG-1/2/4 case it will be 1 or 0, for h264 it may be a little bit higher ;). It have nothing to do with buffering ahead. It is just low_delay ripped from codec and put into video system. >> >> As you can see it is very easy for the decoders to set the IN_ORDER >> >> flag, it could be done om G1's decode() end, when the frames are in >> >> order. >> > >> > Actually, this is totally false. Libavcodec does _not_ export any >> > information which allows the caller to know if the frames are being >> > decoded in order or not. :( Yes, this means lavc is horribly broken... >> >> avcodec always display frames in order, unless you set manually flags >> >>like >> >>_OUT_OF_ORDER or _LOW_DELAY ;) > > No. Keep in mind that your chain will be running from the > draw_horiz_band callback... (in which case, it will be out of order) I > would expect you to set the LOW_DELAY flag under these circumstances, > but maybe you wouldn't. > Yep. >> >> If an MPI is freed without setting IN_ORDER then we could guess that >> >> it >> >> have been skipped. >> > >> > Frame sources cannot be allowed to skip frames. Only the destination >> > requesting frames can skip them. >> If this rule is removed then IN_ORDER don't have any meening. Usually >> filter that makes such frames is broken. If a filter that wants to >> remove >> dublicated frames may set flag SKIPPED (well if such flag exists;) >> SKIPPED/INVALID is requared because there are always 2 mpi's that point >> to >> one buffer (vf1->out and vf_2->in ) > > I misunderstood IN_ORDER. SKIPPED makes sense now, it's just not quite > the way I would implement it. > >> >> Skipping/Rebuilding >> > >> > This entire section should be trashed. It's very bad design. >> did i said somewhere - not finished? > > Yes. IMO it just shouldn't exist, though. It's unnecessary complexity > and part requires sacrificing performance. > Not really. When rebuild request appears, a filter may ignore it and skip the frame instead of processing it. I will try to add new example. Let say that I liked your idea for aspect processing. There is only one SAR (sample aspect ratio). We started decoding and we have displayed some frames. But the user decide that (s)he doesn't like the resolution and switch it (like vo_sdl have key for switching resolution). Now, the DAR is changed (e.g. From 4:3 to 16:9). This mean that the SAR of the image should be changed. In the usual case all images and buffers should be flushed. Including some of the buffers in temporal filters. In other words we have to ?seek? or to start building video chain again (e.g. vd_ffmpeg::init_vo). This what I do, is ability for the filter to decide if he can and want to start with the new parameters or simply to skip frames emulating ?seek? flush. As you may have guessed the aspect is transferred by get_image and stored in MPI. There is another side effect ? at the same time there may be images with different aspects. >> >> Now the skipping issue is rising. I propose 2 flags, that should be >> >> added like IN_ORDER flag, I call them SKIPPED and REBUILD. I thought >> >> about one common INVALID, but it would have different meaning >> >> depending from the array it resides (incoming or outgoing) >> >> SKIPPED is requared when a get_image frame is gotten but the >> >> processing is not performed. The first filter sets this flag in the >> >> outgoing mpi, and when next filter process the date, if should free >> >> the mpi (that is now in the incoming). If the filter had allocated >> >> another >> >> frame, where the skipped frame should have been draw, then it can >> >> free it by setting it as SKIPPED. >> > >> > Turn things around in the only direction that works, and you don't >> >need an image flag for SKIPPED at all. The filter _requesting_ the image >> > knows if it intends to use the contents or not, so if not, it just >> > ignores what's there. There IS NO CORRECT WAY to frameskip from the >> > source side. >> I'm not talking about skipping of frame to maintain A-V sync. > > OK, misunderstood. > >> And decoders are from the source side, they DO skip frames. And in this >> section I use SKIPPED in meaning of INVALID, as you can see from the >> quote. > > I couldn't tell. If the codec skipped a frame at user-request, it > would also be invalid... > >> how many scaling filters are you planing to have? don't you know that >> scale filter is slow? > > Yes, it's slow. vo_x11 sucks. My point is that the player should > _never_ automatically do stuff that gives incorrect output. > Yep. That's why this rebuild/skipped/invalid mubo-jumbo is about. The filters should know better if they can recreate frame or better to skip it. The problem is that I do out-of-order rendering, that in main case mean that I have some frames that I have processed, but they ar. When something changes, I need to rebuild these frames. If I can't I should not display them - skip. >> > Bad point 2: your "rebuild" idea is not possible. Suppose the scale >> > filter has stored its output in video memory, and its input has >> > already been freed/overwritten. If you don't allow for this, >> > performance will suck. >> If you had read carefully you would see that I had pointed that problem >> too (with solution I don't like very much). That's the main reason this >> section is not completed. > > :(( > >> >> > >> >> [...] >> >> -vf spp=5,scale=512:384,osd >> >> [...] >> >> Now the user turns off OSD that have been already rendered into a >> >> frame. Then vf_osd set REBUILD for all affected frames in the >> >> incoming array. The scale filter will draw the frame again, but it >> >> won't call spp again. And this gives a big win because vf_spp could be >> >> extremely slow. >>> >>> This is stupid. We have a much better design for osd: as it >>> slice-renders its output, it makes backups (in very efficient form) of >>> the data that's destroyed by overwriting/alphablending. It can then undo >>> the process at any time, without ever reading from its old input buffers >>> or output buffers. In fact, it can handle slices of any shape and size, >>> too! >> OSD is only EXAMPLE. not the real case. >> Well then I had gave bad example. In fact REBUILD is necessary then >> filter uses a buffer that is requested by the previous filter. Also if vo >> invalidate the buffer by some reason, this is the only way it could >> signal the rest of the filters. > > Invalidating buffers is a problem... > >> Yeh, these issues are raised by he way i handle mpi/buffer, but I have >> not >> seen any such system so far. Usually in such situation all filters will >> get something like reset and will start from next frame. Of course this >> could be a lot of pain in out-of-order scheme! > > It's not really too bad. Although ideally it should be possible to > make small changes to the filter chain _without_ any discontinuity in > the output video... > >> > This is an insurmountible problem. The buffers will very likely no >> > longer exist. Forcing them to be kept will destroy performance. >> You mean will consume a lot of memory? >> huh? > > No. You might have to _copy_ them, which kills performance. Think of > export-type buffers, which are NOT just for obsolete codecs! Or > reusable/static-type buffers! > Well I don't think that we have to copy them. If they are no longer available then we cannot do anything else than skip the frame instead of rebuilding it. >> >> 1. Interlacing ? should the second field have its own PTS? >> > >> > In principle, definitely yes. IMO the easiest way to handle it is to >> require codecs that output interlaced video to set the duration field, >> and then pts of the second field is just pts+duration/2. >> Why? Just because you like it that way? > > Yes. Any other way is fine too. Unfortunately it's impossible to > detect whether the source video is interlaced or not (stupid flags are > always wrong), so some other methods such as always treating fields > independently are troublesome... > >> > Then don't send it to public mailing lists... :) >> The author is never limited by the license, I own full copyright of this >> document and I may set any rules on it. > > Yes but you already published it in a public place. :) > I can do it. I'm the author. I own the copyright You can not do it. You are not the author. Well I guess that this may prevent you from quoting me in the maillist. But I said that it is for mplayer developers eyes only, so as long as there are no users in this list you may quote me ;) Will write a better license next time:) >> > So, despite all the flames, I think there _are_ a few really good ideas >> > here, at least as far as deficiencies in G1 (or even G2 VP) which we >> > need to resolve. But I don't like Ivan's push-based out-of-order >> > rendering pipeline at all. It's highly non-intuitive, and maybe even >> > restrictive. >> Huh, I'm happy to hear that there are good ideas. You didn't point >> anything good. I see only critics&flames. > > Sorry, I wasn't at all clear. The best ideas from my standpoint were > the ones that highlighted deficiencies in my design, e.g. the > buffers-from-multiple-sources thing. Even though I flame them, I also > sort of line your slice ideas, but basically every way of doing slices > sucks... :( > > Another thing is the rebuild idea. Even though I don't see any way it > can be done correctly with your proposal, it would be nice to be able > to regenerate the current frame. Think of a screenshot function, for > example. > There is an easier way to make a screen shot ;) you just need a split filter that uses DR for one of the chains. This filter will do no drawing as it always do DR. When A user wants a screen shot, the filter should copy the current frame and pass it on the second chain that ends with vo_png or something like it. Even scale filter may be auto-inserted into the second chain ;) >> > Actually, the name (VO3) reflects what I don't like about it: Ivan's >> > design is an api for the codec to _output_ slices, thus calling it >> > video >> > output. (In fact, all filter execution is initiated from within the >> > codec's slice callback!) >> This is one of the possible ways. In the vo2 drafts I wanted to >> implement >> something called automatic sliceing- forcing filters to use slices even >> when decoder doesn't support slicing. (I can nearly imagine the flames >> you are thinking in the moment;) > > I understand what you're saying. I'm just strongly opposed to the main > entry point being at the codec end. In particular, it does not allow > cpu-saving frame dropping. Only in a pull-based system where you wait > to decode/process a frame until the next filter wants it can you skip > (expensive!) processing (or even decoding, for B frames!) based on > whether the output is destined for the encoder/monitor or the > bitbucket... > > Ultimately, slice _processing_ isn't very friendly to this goal. The > more we discuss it, the more I'm doubting that slice processing is > even useful. On the one hand it's very nice, for optimizing cache > usage, but on the other, it forces you to process frames before you > even want them. This is a _big_ obstacle to framedropping, and to > smooth playback, since displaying certain frames might require no > processing, and displaying others might require processing 2 or 3 > frames first... :(( > >> Anyway my API makes all filter codecses. That's why the scheme looks so >> complicated, and that's why simple filter is so necessary. The full >> beauty >> of the API will be seen only for people that make temporal filters and >> adding/removing frames. This mean by you :O > > Perhaps you could port vf_pullup to pseudocode using your api and see > if you could convince me? > >> > On the other hand, I'm looking for an API >> > for _obtaining_ frames to show on a display, which might come from >> > anywhere -- not just a codec. For instance they might even be >> > generated by visualization plugins from audio data, or even from >> /dev/urandom! >> Oh, Could you explain why mine API cannot be used for these things? > > It's _called_ from the codec's draw_slice! Not very good at all for > multiple video sources, e.g. music + music video + overlaid > visualization. > >> > So, Ivan. I'll try to take the best parts of what you've proposed and >> > incorporate them into the code for G2. Maybe we'll be able to find >> > something we're both happy with. >> Wrong, We need something that we both are equally unhappy with:))) > > Yes... > >> But as far as you code it is natural you to implement your ideas. > > Yes again. > > So, now let me make some general remarks (yes, this is long > already...) > > After this email, I understand your proposal a lot better. The big > difference between our approaches is that I treat buffers (including > "indirect" buffers) as objects which filters obtain and hold onto > internally and which they only "pass along" when it's time to display > them, while you treat buffers as entities which are carefully managed > in a queue between each pair of filters, which can be processed > immediately, and which are only "activated" (IN_ORDER flag) when it's > actually their time. > > Here are some things I like better about your approach: > - It's very easy to cancel buffers when unloading/resetting filters. > - Buffer management can't be 'hidden' inside the filters, meaning that > we're less likely to have leaks/crashes from buggy filters. > - Processing can be done in decoding order even when slices aren't > supported (dunno whether this actually happens). > - Slices are fairly restricted, easing implementation. > > And here are some things I really don't like about your approach: > - It's push-based rather than pull-based. Thus: > - No good way to handle (intentional) frame dropping. This will be a > problem _whenever_ you do out-of-order processing, so it happens > with my design too. But the only time I do OOO is for slices... Actually there is a way and it works the very same way > - Slices are fairly restricted, limiting their usefulness. > - Having the chain run from the decoder's callback sucks. :( > - It doesn't allow "dumb slices" (small reused buffer). > - It doesn't have a way to handle buffer age/skipped blocks (I know, > my design doesn't solve this either...)~: > - My YV12->NV12 conversion might not be possible with your buffer > management system...? > > Now that my faith in slices has been shaken, I think it would be > really beneficial to see some _benchmarks_. Particularly, a comparison > of slice-rendering through scale for colorspace conversion (and > possibly also scaling) versus non-slice. If slices don't help (or > hurt) for such complex processing (due to cache thrashing from the > scale process itself), then I would be inclined to throw away slices > for everything except copying to write-only DR buffers while > decoding... On the other hand, if they help, then they're at least > good for in-order rendering (non-B codecs). There is nice cache examination tool in valgrind debugger. If I remember right last time I run it i got about 30% cache hits. Anyway in general case they give 5-10% speed up. And this by using them only for B-Frames (in-order) I think that you can imagine the speed-up;))) > > And Ivan, remember: a (pseudocode?) port of vf_pullup to your layer > might be very useful in convincing me of its merits or demerits. Also > feel free to criticize the way pullup.c does all its own internal > buffer management -- perhaps you'd prefer it obtain buffers from the > next filter. :) This can be arranged if it will help. Will Do it later. (in next mail:) I'm first gonna add few simple example filters ;) > > As much as I dislike some of your ideas, I'm open to changing things > to be more like what you propose. I want G2 to be the best possible > tool for video! And that matters more than ego/flames/eliteness/etc. > Maybe you'll even get me to write your (modified) design for you, if > you come up with convincing proposals... :)) > > Rich > As a whole I my current design have only sense in using slices. The whole concept is to process the data after it have been decoded and while it is still in the cache. For this you need 2 things ? to process the data in the order it is decoded (out-of-order is in fact decode order), and to process it in small peaces that fit into cache, but not too small to avoid function call overhead. Best Regards Ivan Kalvachev iive From dalias at aerifal.cx Fri Jan 2 04:51:28 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 1 Jan 2004 22:51:28 -0500 Subject: [MPlayer-G2-dev] vo3 In-Reply-To: <1289.212.116.154.213.1073001274.squirrel@mail.cacad.com> References: <20031228051830.GG257@brightrain.aerifal.cx> <1289.212.116.154.213.1073001274.squirrel@mail.cacad.com> Message-ID: <20040102035128.GC257@brightrain.aerifal.cx> On Fri, Jan 02, 2004 at 01:54:34AM +0200, Ivan Kalvachev wrote: > >> > In my design, this makes no sense. The final scale filter for resizing > >> > would not pass any frames to the vo until time to display them. > >> final scale filter?!!! > >> How many scale filters do you have? > > > Normally only one. But suppose you did something like the following: > > > > -vf scale=640:480,pullup > > > > with output to vo_x11. The idea is that since you'll be resizing DVD > > to square pixels anyway, you might as well do it before the inverse > > telecine and save some cycles. > > Just for the protocol;) I'm sure you know that scaling interlaced frames > vertically will mangle interlacing. No, that filter chain only does _horizontal_ scaling (telecine is in NTSC land, remember? :). Anyway scaling interlaced frames is perfectly valid if you scale the fields independently (which G2 should do automatically), but it's a bad idea before inverse telecine as it will decreace accuracy. > > Now the user resizes the window... In yours (and Arpi's old) very bad > > way, the scale filter gets reconfigured, ruining the fields. If you > > don't like this example (there are other ways to handle interlacing) > > then just consider something like denoising with scaling. My principle > > in response is that the player should NEVER alter configuration for > > any filters inserted manually by the user. Instead, it should create > > its own scale filter for dynamic window resizing and final vo > > colorspace conversion. > > > > I'm sorry to say it but you cannot see the forest because there are too > many trees. (that's saying/proverb) > > I give it as example. I like to give example that are not totally > fictitious. > > And as you may have noticed the scale filter is the final one. So having 2 > scale one after another is not very good. > > And as Diego says it could be used for resizing while paused, and stuff > like that. > > About scale. Yep, I agree that it is good to have one scale filter at the > end. If I am not wrong, now in G1 the scale filter is inserted constantly > at one and same position, this way preventing automatic conversion except > in the ordinary case. > > The other big problem with scale is that it makes way too many things. It > makes format conversion, it scales, it makes format conversion and scale at > the same time. Of course this is done to maximize speed. > > > >> >> safe seeking, auto-insertion of filters. > >> > > >> > What is safe-seeking? > >> When seeking filters that have stored frames should flush them > >> For example now both mpeg2 decoders don't do that, causing garbage in > >> B-Frames decoding after seek. Same apply for any temporal filter. > >> In G1 there is control(SEEK,...), but usually it is not used. > > > > OK, understood perfectly. > > > >> > Auto-insertion is of course covered. > >> I'm not criticizing your system. This comment is not for me. > >> Or I hear irony? > > > > And I wasn't criticizing yours, here. I was just saying it's not a > > problem for either system. > > How about new level of filter insertion - runtime insertion without > dropping frames? > > > > >> >> In short the ideas used are : > >> >> ? common buffer and separate mpi ? already exist in g1 in some form ? > >> >> counting buffer usage by mpi and freeing after not used ? huh, sound > >> >> like java :O > >> > > >> > No. Reference counting is good. GC is idiotic. And you should never > >> >free > >> > buffers anyway until close, just repool them. > >> I didn't say that. Free buffer is buffer that is not busy and could be > >> reused. > >> Moreover I don't like the way frames are locked in your code. It doesn't > >> seem obvious. > > > > In VP, you will _only_ lock frames if you need to keep them after > > passing them on to the next filter. Normally you shouldn't be doing > > this. > > > > At first I could understand what GC is, after i send my reply i realized > that it comes from Garbage Collector :O I hate GC, I don't like java > because of GC. As you may have missed (and misleaded by my java appointment) > is that buffers have counters. It is simple - on MPI allocation buffer > counter is increased , on MPI release it is decreased. When usage is 0 then > the buffer may be reused. > You see ? no locking needed. Lock and reference/usage count are exactly the same thing. Just different words for it. > On another hand buffer reusing is of cource connected to > skipped_blocks optimization. > But I still have no idea how to do it :( > > > >> The goal in my design is all the work of freeing/quering to > >> be moved to vf/vp functions. So in my design you will see only > >> get_image/release_image, but never lock/unlock. Because having buffer > >> mean that you need it. (well most of the time) > > > > Keep in mind there's no unlock function. It's just get/lock/release. > > > > Perhaps you should spend some time thinking about the needs of various > > filters and codecs. The reason I have a lock function is that the > > _normal_ case is passing your image on to the next filter without > > keeping it. Images could start out with 2 locks (1 for source, 1 for > > dest) and then the source would have to explicitly release it when > > finished, but IMHO this just adds complexity since most filters should > > never think about a frame again once sending it out. > > Yes this is what I do. > The only differense is that simple filter may release frame after > it pass it to the next one. > > > > >> >> ? allocating all mpi&buffer before starting drawing (look obvious, > >> >> doesn't it?) ? in G1 filters had to copy frames in its own buffers or > >> >> play hazard by using buffers out of their scope > >> > > >> > Yes, maybe G1 was broken. All the codecs/filters I know allocate > >> > mpi/buffers before drawing, though. > >> In G1 if you draw_slice out-of-order it is possible to go to a filter > >> that > >> haven't yet allocated buffer for this frame - some frames are allocated > >> on > >> put_frame. > > > > This is because G1 is horribly broken. Slices should not be expected > > to work at all in G1 except direct VD->VO. > > Ouch. But your current implementation is based on the same principle.) No, not at all. With my implementation slices are always attached to an mpi, so you know (when that mpi gets to you) that it goes with the slices you processed previously. In G1, there's no way to tell, except to assume that all slices between start_slices and put_image go with the same frame. > >> That's also the reason to have one common process()! > > > > I disagree. > > > >> >> ? using flag IN_ORDER, to indicate that these frames are "drawn" and > >> >> there won't come frames with "earlier" PTS. > >> > > >> > I find this really ugly. > >> It's the only sane way to do it, if you really do out-of-order > >> processing. > > > > No, the draw_slice/commit_slice recursion with frames getting pulled > > in order works just fine. And it's much more intuitive. > > > >> >> ? using common function for processing frame and slices ? to make > >> >> slice > >> >> support more easier > >> > > >> > This can easily be done at the filter implementation level, if > >> > possible. In many cases, it's not. Processing the image _contents_ and > >> > the _frame_ are two distinct tasks. > >> Not so easy. Very few filters in G1 support slices, mainly because it > >> is > >> separate chain. > > > > No, mainly because the api is _incorrect_ and cannot work. Slices in > > G1 will inevitably sig11. > > > > Haven't you noticed that in G1 slice-ing is turned on by default? > ;) Yes... And I've noticed sig11's with various combinations of crop, expand, and scale... :( > > Actually it doesn't. The YV12->NV12 converter can just allow direct > > rendering, with passthru to the VO's Y plane and its own U/V planes. > > Then, on draw_slice, the converter does nothing with Y and packs U/V > > into place in the VO's DR buffer. This is all perfectly valid and no > > effort to implement in my design. > > > > The difficult case is when you want to export some planes and DR > > others... > > > > Just one tiny-mini problem. What will be locked if a filter needs the frame > for later processing? If which filter does? If the source (rendering the YV12 into the converter) needs to keep the frame, it just keeps the DIRECT mpi it obtained from the converter locked, which in turn keeps the vo's NV12 buffer locked. The release will later happen recursively, as expected. If the destionation (getting the NV12 image) needs to keep it (dunno why since only a vo would want NV12), then the converter isn't involved at all. The NV12 image is in it's own buffer, with which it can do whatever it wants. In summary: my system of buffer lock management _inherently_ handles all cases correctly, with no difficulty or hacks. So there's no need to ask questions like this. > One possible solution is to have separate buffer for Y,U,V planes, also > QuantTable, SkippedBlocksTbl. But then we will have to manage with multiple > buffers into one mpi. No, the mpi's priv area just needs to keep track of its 'dependencies' and the bufdesc_t struct has to have the right pointers stored in it. > > Huh? Rounding? WTF? You can't render half a pixel. If a filter is > > doing slices+resizing (e.g. scale, subpel translate, etc.) it has to > > deal with the hideous boundary conditions itself... > > > > Yep, but you forget that x,y,w,h may have any values. In the ordinary way > they will be multiple of 16, but after one resize filter, this is no > longer true. And how are you gonna manage the things if you got odd > x,y,w,h in YV12 image :O They're invalid, as always. :) > Now I believe that line counters from top to bottom is the most sane > alternative. I'm still not convinced...but as you can see from some of my previous posts on this list about slices, I don't like arbitrary unrestricted slices too much either... > If the only VP3 filter draws top from bottom, then we won't process slices > for it. Only full images. This is stupid, even slower than G1. > But I doubt that VfW codecs may do it too. Anyway they don't have slices. Right, no slices there. > >> I agree that there may be some problems for vo with one buffer. > >> So far you have one (good) point. > > > > I never said anything about vo with one buffer. IMO it sucks so much > > it shouldn't even be supported, but then Arpi would get mad. > > > > Same thing could be extend for decoder with n=2 static buffers at once, and > vo with only 2 buffers. Same for n=n+1; > > Well after some brainstorming. I take my words back. That what decoder does > is to delay one frame by buffering it. As my whole video filter system acts > like a codec, then we should take control of the buffer delay. This could be > done by adding ?global? variable LowDelay, that contains the number of > frames we need to wait before starting displaying. In MPEG-1/2/4 case it > will be 1 or 0, for h264 it may be a little bit higher ;). This is nonsense. The delay is variable for inverse telecine because sometimes you need 3 fields to get a frame, and sometimes just 2... :) > It have nothing to do with buffering ahead. It is just low_delay ripped from > codec and put into video system. I think you mean "delay". "low_delay" is a flag that means delay==0. > >> >> Skipping/Rebuilding > >> > > >> > This entire section should be trashed. It's very bad design. > >> did i said somewhere - not finished? > > > > Yes. IMO it just shouldn't exist, though. It's unnecessary complexity > > and part requires sacrificing performance. > > > > Not really. When rebuild request appears, a filter may ignore it and > skip the frame instead of processing it. > I will try to add new example. > > Let say that I liked your idea for aspect processing. There is only one SAR > (sample aspect ratio). We started decoding and we have displayed some > frames. But the user decide that (s)he doesn't like the resolution and > switch it (like vo_sdl have key for switching resolution). Now, the DAR is > changed (e.g. From 4:3 to 16:9). This mean that the SAR of the image should > be changed. In the usual case all images and buffers should be flushed. > Including some of the buffers in temporal filters. In other words we have to > ?seek? or to start building video chain again (e.g. vd_ffmpeg::init_vo). No. If the vo suppors hardware scaling, no change is necessary. If not, then the final scale filter needs to be reconfigured for the new output aspect (or loaded if none exists already). None of the rest of the chain needs to be touched. You should understand that many temporal filters _cannot_ handle reconfiguration without creating annoying discontinuities in the output. So the system should seek to accommodate them > This what I do, is ability for the filter to decide if he can and want to > start with the new parameters or simply to skip frames emulating ?seek? > flush. > > As you may have guessed the aspect is transferred by get_image and stored in > MPI. > > There is another side effect ? at the same time there may be images with > different aspects. This is very bad. One of my key design points of vp is that you never tell get_image _any_ image properties, and instead configure the link for the type of images you'll be passing. > >> how many scaling filters are you planing to have? don't you know that > >> scale filter is slow? > > > > Yes, it's slow. vo_x11 sucks. My point is that the player should > > _never_ automatically do stuff that gives incorrect output. > > > > Yep. That's why this rebuild/skipped/invalid mubo-jumbo is about. The > filters should know better if they can recreate frame or better to skip it. > > The problem is that I do out-of-order rendering, that in main case mean that > I have some frames that I have processed, but they ar. When > something changes, I need to rebuild these frames. If I can't I should not > display them - skip. I wonder if there's not a simpler way to do it, when it's possible... > >> > This is an insurmountible problem. The buffers will very likely no > >> > longer exist. Forcing them to be kept will destroy performance. > >> You mean will consume a lot of memory? > >> huh? > > > > No. You might have to _copy_ them, which kills performance. Think of > > export-type buffers, which are NOT just for obsolete codecs! Or > > reusable/static-type buffers! > > > Well I don't think that we have to copy them. If they are no longer > available then we cannot do anything else than skip the frame instead of > rebuilding it. This is better. > >> > Then don't send it to public mailing lists... :) > >> The author is never limited by the license, I own full copyright of this > >> document and I may set any rules on it. > > > > Yes but you already published it in a public place. :) > > > I can do it. I'm the author. I own the copyright > You can not do it. You are not the author. > Well I guess that this may prevent you from quoting me in the maillist. > But I said that it is for mplayer developers eyes only, so as long as there > are no users in this list you may quote me ;) > Will write a better license next time:) And better learn that MPlayer devs don't care about licenses and copyrights... :) > > Another thing is the rebuild idea. Even though I don't see any way it > > can be done correctly with your proposal, it would be nice to be able > > to regenerate the current frame. Think of a screenshot function, for > > example. > > > > There is an easier way to make a screen shot ;) > you just need a split filter that uses DR for one of the chains. > This filter will do no drawing as it always do DR. > When A user wants a screen shot, the filter should copy the current frame > and pass it on the second chain that ends with vo_png or something like it. > Even scale filter may be auto-inserted into the second chain ;) This isn't possible without an added burden on buffers. The filter that does the splitting for screenshots has to keep the currently displayed image locked so it can send it to vo_png or whatever. In particular, this means PRESERVE and READABLE must be set!!! (If preserve isn't set, OSD or something might overwrite the picture!) Also, if the vo only has a small limited number of buffers, you waste one! Screenshots are MUCH more complicated than you think! The other way it to take screenshot of _next_ frame, but users might not like that... :) > > And here are some things I really don't like about your approach: > > - It's push-based rather than pull-based. Thus: > > - No good way to handle (intentional) frame dropping. This will be a > > problem _whenever_ you do out-of-order processing, so it happens > > with my design too. But the only time I do OOO is for slices... > > Actually there is a way and it works the very same way Please explain. See below.. > > Now that my faith in slices has been shaken, I think it would be > > really beneficial to see some _benchmarks_. Particularly, a comparison > > of slice-rendering through scale for colorspace conversion (and > > possibly also scaling) versus non-slice. If slices don't help (or > > hurt) for such complex processing (due to cache thrashing from the > > scale process itself), then I would be inclined to throw away slices > > for everything except copying to write-only DR buffers while > > decoding... On the other hand, if they help, then they're at least > > good for in-order rendering (non-B codecs). > There is nice cache examination tool in valgrind debugger. > If I remember right last time I run it i got about 30% cache hits. > Anyway in general case they give 5-10% speed up. And this by using them > only for B-Frames (in-order) > I think that you can imagine the speed-up;))) Well do you have any idea for how to reconcile slices with frame dropping?? Here's the problem: A filter wants to drop some frames, either to compensate for slow cpu, or to generate fixed-fps output, or to do smart seeking to non-key frames, etc. So it somehow needs to signal the earlier part of the chain when it intends to throw away the next image it gets. This way, we can skip processing entirely, as long as there are no temporal filters that need to see all frames. However, if we run the filter chain out of order (slices), then the frame currently bring processed is _not_ the next frame _temporally_ which we want to drop, but instead some future frame, which we don't yet know whether we want to drop! How do you solve it?? > > And Ivan, remember: a (pseudocode?) port of vf_pullup to your layer > > might be very useful in convincing me of its merits or demerits. Also > > feel free to criticize the way pullup.c does all its own internal > > buffer management -- perhaps you'd prefer it obtain buffers from the > > next filter. :) This can be arranged if it will help. > Will Do it later. (in next mail:) > I'm first gonna add few simple example filters ;) OK, thanks! > As a whole I my current design have only sense in using slices. Yes... > The whole concept is to process the data after it have been decoded and > while it is still in the cache. For this you need 2 things ? to process the > data in the order it is decoded (out-of-order is in fact decode order), and > to process it in small peaces that fit into cache, but not too small to > avoid function call overhead. There's also the question of whether all the _code_ for running the whole chain with slices will thrash the cache. In G1, everything that uses slices is trivial code, so it doesn't matter, but if you're doing complicated processing the game could change... Rich P.S. Could you avoid using mswindows charset in emails?? (?, etc.) From dalias at aerifal.cx Wed Jan 7 20:49:04 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 7 Jan 2004 14:49:04 -0500 Subject: [MPlayer-G2-dev] requirements for vo2 layer Message-ID: <20040107194903.GA23773@brightrain.aerifal.cx> Attila asked for some requirements for changes in the vo2 layer to accommodate the new vp stuff (and just sanitize it in general). So here they are: * A way to query whether a buffer is available for writing the next frame. Buffers which are currently displayed or pending display on next vblank are NOT available. Also, buffers in shm which the X server is presently copying are not available. Etc. Ideally, VO's which have temporarily-unavailable states (like the Xshm thing or displayed-but-new-frame-is-pending-on-vblank) should have a "sync" function we can call (implemented with XSync or a wait-for-vblank ioctl, etc.) to wait until the buffer is again writable, for reget_buffer or REUSABLE buffers. [ Note: this isn't strictly a requirement, but it can prevent visual glitches on very fast machines, so it's probably desired! Otherwise we could get in trouble if we start writing to a still-busy frame too soon! ] * The dynamic buffer allocation system makes no sense. There's an IN_USE flag for buffers obtained dynamically, but it's meaningless since the caller has to manage its own pool. IMO the IN_USE flag should be removed and replaced with the above buffer availability system, and the caller (vp_vo2.c or whatever) should * Provide some way for the caller to know (at least roughly) how many buffers will be available. At least vo's that can provide an essentially unlimited number (x11, xv, etc.) should indicate so, and ones with a small fixed number of buffers should also report this. * Simplification of query_format to a simple yes/no. VO's should never perform colorspace conversion, software scaling, etc. Flipping is just negative stride in G2, so it falls in the next point: * Report or negotiate pixel aspect ratio of the output picture. For drivers without overlay which can change video mode, we might actually want some way of negotiating a video mode to meet certain size/aspect constraints. * Exporting stride restrictions so the vo2 wrapper can negotiate stride with the filter chain in hopes of getting DR to work. There are actually 2 sets of stride restrictions: one for direct rendering, and the other for all input images. The latter restriction should _ONLY_ be in place if the VO driver does not export its buffers, and requires some sort of slice or frame drawing function to be called (svgalib?). [ Note: this does not preclude stupid VO's that change stride, like DirectX. It's legal to provide a DR buffer whose stride differs from the negotiated stride, but _only_ if the STATIC stride restriction isn't in place. But some filters/codecs don't allow stride to change (especially lavc!) so negotiation is important if you want DR to work. Otherwise lavc will get one stride for the first I frame's allocated buffer, then another (possibly different!) stride for the first B frame's DR buffer!! ] Can't think of anything else... Rich From dalias at aerifal.cx Thu Jan 8 01:08:47 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 7 Jan 2004 19:08:47 -0500 Subject: [MPlayer-G2-dev] requirements for vo2 layer In-Reply-To: <20040107194903.GA23773@brightrain.aerifal.cx> References: <20040107194903.GA23773@brightrain.aerifal.cx> Message-ID: <20040108000847.GG257@brightrain.aerifal.cx> On Wed, Jan 07, 2004 at 02:49:04PM -0500, D Richard Felker III wrote: > Attila asked for some requirements for changes in the vo2 layer to > accommodate the new vp stuff (and just sanitize it in general). So > here they are: Ack, forgot a big one! Here it is: * A method to request oversized buffers with extra space (which can be written with junk) outside the image dimensions. This allows panscan style direct rendering through crop (and thus vf_panscan) and may be needed for broken codecs which can't do edge emulation or which need extra space to write when width or height % 16 != 0. Rich From dalias at aerifal.cx Thu Jan 8 01:34:55 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 7 Jan 2004 19:34:55 -0500 Subject: [MPlayer-G2-dev] buffer age & slices: nasty problems Message-ID: <20040108003455.GA24349@brightrain.aerifal.cx> Buffer age refers to the number of elapsed frames since a buffer was written. Keeping track of buffer age is very useful for codecs (and perhaps some filters) because they can skip writing areas that haven't changed. But it's also a very difficult thing to keep track of with general get_buffer type management instead of the dumb old IMGTYPE_IPB approach. I see two possible ways to handle it: 1. Keeping track of buffer age in the vp layer itself. Basically, when requesting an image buffer you'd specify an AGE flag, meaning (a) you want vp to keep track of the buffer's age, and (b) you want the vp layer (or the filter/vo you're direct rendering into) the youngest buffer it can. This is very easy for AUTO type buffers, and of course not necessary for EXPORT. But for DIRECT and INDIRECT buffers that are going through several intermediate filters, it could be very difficult to implement correctly. Think of a chain like: decoder -> tfields -> expand -> vo Since tfields makes one INDIRECT buffer out of every _pair_ of INDIRECT buffers it gets from the vo, it would have to convert 2 ages into 1... 2. Force codecs that want to take advantage of buffer age/unchanged blocks to keep a lock on the old buffers and use some sort of reget_buffer function. The basic idea here is that once a buffer is released, its contents should be considered 100% invalid and its age infinity. Thus if you want to take advantage of what's already in the buffer, you should hang onto it. The nice aspect of this approach is that it simplifies the vp layer, and moves the complexity to the (few) codecs that care about buffer age. The bad part is that I'm not sure the basic premise is good. For example, if we accept that premise, then vf_expand cannot assume the black bars are still black after it releases its buffers, and would either have to redraw them every time or keep its buffers locked. Just checking buffer age (and only clearing the black bars if age==infinity) seems like a more sane approach. 3. (??) Maybe some other buffer management scheme I haven't though of yet...????? NOW, MORE BAD NEWS... All of this is further complicated by the fact that, when you're doing DR2 or slices, you actually have _2_ output buffers. One is the READABLE EXPORT or AUTO type buffer that you're decoding in, and the other is the non-READABLE DIRECT or INDIRECT type buffer you're slice-rendering to. In principle, their ages could be different. Right now, I have code in the vp layer to simplify slice rendering, so that when you want to slice-render, you just call start_slices on the AUTO or EXPORT image you already have, and it then internally manages the associated DIRECT or INDIRECT type image obtained from the next filter/vo. But this creates a problem if age isn't managed by the vp layer, since the codec has no way to tell the age of the (hidden) buffer slices are going to, and thus doesn't know if it can skip blocks. Even worse, some filters might accept skipped blocks (simple colorspace conversion) while others (scale) might have real trouble with them without lots of clever hacks! Ultimately what this points out is that slices are the barons of hell (or maybe the cyberdemon) and there seems to be no good way to handle them while maintaining both _generality_ and sufficient _restraints_ so that filters can actually handle the slices. So in response to this email, I'd like two things: A. Recommendations on which way to handle buffer age. B. Ideas on how to make slices (at least slightly) less hellish... Rich From fre_ax at mbnet.fi Thu Jan 8 04:29:30 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Thu, 8 Jan 2004 05:29:30 +0200 (EET) Subject: [MPlayer-G2-dev] Data communication between demuxers and UIs Message-ID: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> I decided to give a shot and try to implement dvb playlist for GUI to allow users remove/add/rename/group channels. I soon realized that this is impossible because its not easy to transmit data between libmpdemux/dvbin.c and GUI. Now, to solve this problem I was thinking if demuxers would be allowed to register virtual filesystems for UIs. "Services" would then register mount points like DVB, HTTP, FTP, CDDA, ... Demuxers would then look for possible files/streams to play and list them by the virtual filesystem. --Aapo Tahkola From albeu at free.fr Thu Jan 8 13:08:23 2004 From: albeu at free.fr (Alban Bedel) Date: Thu, 8 Jan 2004 13:08:23 +0100 Subject: [MPlayer-G2-dev] Re: requirements for vo2 layer References: <20040107194903.GA23773@brightrain.aerifal.cx> Message-ID: <20040108130823.3b941957.albeu@free.fr> Hi D Richard Felker III, on Wed, 7 Jan 2004 14:49:04 -0500 you wrote: [...] > * Simplification of query_format to a simple yes/no. VO's should never > perform colorspace conversion, software scaling, etc. Flipping is > just negative stride in G2, so it falls in the next point: But what about hw conversion ? Often not all colorspace give the same speep. Imho the driver should be able to "rate" the colorsapce in order to let the caller know wich one is the fastest. > * Report or negotiate pixel aspect ratio of the output picture. For > drivers without overlay which can change video mode, we might > actually want some way of negotiating a video mode to meet certain > size/aspect constraints. What we rather want is: the physical aspect ratio of the screen and all possible resolutions on this screen. This also imply a way to set these videmode. Imho this should be, if possible, separated from the vo drivers. All x drivers can use the same code, most console based can use the fb modedb thing, etc I think that it must be up to libvo2 user to query avaible video mode and set a new mode before calling query_format, config, etc An helper func wich auto select best video mode would be nice, but libvo2 usurs must have 100% control over video mode selection if they need to. > * Exporting stride restrictions so the vo2 wrapper can negotiate > stride with the filter chain in hopes of getting DR to work. There > are actually 2 sets of stride restrictions: one for direct > rendering, and the other for all input images. The latter > restriction should _ONLY_ be in place if the VO driver does not > export its buffers, and requires some sort of slice or frame drawing > function to be called (svgalib?). Also note that some vo can nearly provide any stride you want. It's the case with tdfx_vid wich can use any stride > width (no negative stride). Currently in libvo2 the driver have to choose the stride itself :( If it knew what stride the last fliter want it could just provide it most of the time. However there are probably vo that will have different restrictions for different colorspace. [...] > * A method to request oversized buffers with extra space (which can be > written with junk) outside the image dimensions. This allows panscan > style direct rendering through crop (and thus vf_panscan) and may be > needed for broken codecs which can't do edge emulation or which need > extra space to write when width or height % 16 != 0. Yes, that sound like a very good idea. Basicaly what is needed is a "visible area" area information. However i think that this info must also be avaible at config time. To resume i think that query_format should return : colorspace rating (0 = not supported 1-255 speed rating) flags (support oversized buffer, need aligned stride, etc) max visible width,height min,max strides And config should get: colorspace src width, height visible width, height, x,y (only if oversized buf supported) src aspect (imho we should give aspect and helper funcs instead of d_width,d_height) desired strides (the driver doesn't have to respect these) desired num_buff flags (fullscreen, etc) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From dalias at aerifal.cx Fri Jan 9 04:56:40 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 8 Jan 2004 22:56:40 -0500 Subject: [MPlayer-G2-dev] Re: requirements for vo2 layer In-Reply-To: <20040108130823.3b941957.albeu@free.fr> References: <20040107194903.GA23773@brightrain.aerifal.cx> <20040108130823.3b941957.albeu@free.fr> Message-ID: <20040109035640.GJ257@brightrain.aerifal.cx> On Thu, Jan 08, 2004 at 01:08:23PM +0100, Alban Bedel wrote: > Hi D Richard Felker III, > > on Wed, 7 Jan 2004 14:49:04 -0500 you wrote: > > [...] > > * Simplification of query_format to a simple yes/no. VO's should never > > perform colorspace conversion, software scaling, etc. Flipping is > > just negative stride in G2, so it falls in the next point: > But what about hw conversion ? Often not all colorspace give the same speep. > Imho the driver should be able to "rate" the colorsapce in order to let > the caller know wich one is the fastest. Does this case really exist? I've never heard of it. Usually the conversion is done in the driver, not the hardware, and this is slow so it shouldn't be supported. > > * Report or negotiate pixel aspect ratio of the output picture. For > > drivers without overlay which can change video mode, we might > > actually want some way of negotiating a video mode to meet certain > > size/aspect constraints. > What we rather want is: the physical aspect ratio of the screen and > all possible resolutions on this screen. This also imply a way to > set these videmode. Imho this should be, if possible, separated from > the vo drivers. All x drivers can use the same code, most console based > can use the fb modedb thing, etc It's still part of the vo driver. If the vo driver wants to call generic code from x11_helper, that's fine. > I think that it must be up to libvo2 user to query avaible video mode > and set a new mode before calling query_format, config, etc > An helper func wich auto select best video mode would be nice, but > libvo2 usurs must have 100% control over video mode selection if > they need to. This is nonsense. You have no idea what video mode you want until the filter chain starts configuring. > > * Exporting stride restrictions so the vo2 wrapper can negotiate > > stride with the filter chain in hopes of getting DR to work. There > > are actually 2 sets of stride restrictions: one for direct > > rendering, and the other for all input images. The latter > > restriction should _ONLY_ be in place if the VO driver does not > > export its buffers, and requires some sort of slice or frame drawing > > function to be called (svgalib?). > Also note that some vo can nearly provide any stride you want. It's the > case with tdfx_vid wich can use any stride > width (no negative stride). > Currently in libvo2 the driver have to choose the stride itself :( > If it knew what stride the last fliter want it could just provide it > most of the time. No problem. The caller (vp layer) decides the stride it wants based on the source and destination's stride restrictions. Then it will configure the vo for the selected stride. > However there are probably vo that will have different restrictions > for different colorspace. This is annoying, but not necessarily a critical problem. > > * A method to request oversized buffers with extra space (which can be > > written with junk) outside the image dimensions. This allows panscan > > style direct rendering through crop (and thus vf_panscan) and may be > > needed for broken codecs which can't do edge emulation or which need > > extra space to write when width or height % 16 != 0. > Yes, that sound like a very good idea. Basicaly what is needed is a > "visible area" area information. However i think that this info must also > be avaible at config time. Of course. _EVERYTHING_ about the image passing is determined at config time. Dimensions, stride, borders, colorspace, SAR, ... This is one of the main differences from G1. > To resume i think that query_format should return : > colorspace rating (0 = not supported 1-255 speed rating) > flags (support oversized buffer, need aligned stride, etc) > max visible width,height > min,max strides I don't like querying everything at once. Ultimately the only things you absolutely _need_ to know when configuring are (a) supported colorspace and (b) whether there's an absolute stride restriction (only happens when buffers are indirect). All the other queries are only needed for direct rendering. I still haven't decided exactly how query and config should work, though... :( > And config should get: > colorspace > src width, height > visible width, height, x,y (only if oversized buf supported) This is ugly, or at least very different from how vp will work. It will have width, height, and 4 border sizes (top, bottom, left, right). But I don't really care if vo is done differently since we get to wrap it anyway. > src aspect (imho we should give aspect and helper funcs instead of > d_width,d_height) Of course. We use sample (pixel) aspect, not hideous d_width/d_height stuff like G1. > desired strides (the driver doesn't have to respect these) Yes it does (under certain conditions, at least), but the desired stride is guaranteed to be something the vo agreed to support already. That's why we negotiate strides in advance. > desired num_buff This is never known. :( Very unfortunate, but I don't see any way we can possibly know it. Maybe force each vp node (decoders and filters) to report how many buffers they'll need at config time? This would be very helpful, but might be impossible for some! Or at least very very difficult to guess correctly... > flags (fullscreen, etc) This is irrelevant to the filter chain. It should be configured some other way. Rich From albeu at free.fr Fri Jan 9 09:57:12 2004 From: albeu at free.fr (Alban Bedel) Date: Fri, 9 Jan 2004 09:57:12 +0100 Subject: [MPlayer-G2-dev] Re: requirements for vo2 layer References: <20040107194903.GA23773@brightrain.aerifal.cx> <20040108130823.3b941957.albeu@free.fr> <20040109035640.GJ257@brightrain.aerifal.cx> Message-ID: <20040109095712.07b3e9cb.albeu@free.fr> Hi D Richard Felker III, on Thu, 8 Jan 2004 22:56:40 -0500 you wrote: > On Thu, Jan 08, 2004 at 01:08:23PM +0100, Alban Bedel wrote: > > Hi D Richard Felker III, > > > > on Wed, 7 Jan 2004 14:49:04 -0500 you wrote: > > > > [...] > > > * Simplification of query_format to a simple yes/no. VO's should > > > never > > > perform colorspace conversion, software scaling, etc. Flipping is > > > just negative stride in G2, so it falls in the next point: > > But what about hw conversion ? Often not all colorspace give the same > > speep. Imho the driver should be able to "rate" the colorsapce in > > order to let the caller know wich one is the fastest. > > Does this case really exist? I've never heard of it. 3dfx stuff have such colorspace converters on board. 1 YUV planar -> packed and 1 YUV packed -> RGB. They are heavily used by tdfxfb and tdfx_vid. > Usually the conversion is done in the driver, not the hardware, and this > is slow so it shouldn't be supported. ROTF ??? are you proposing that i rewrite vo_tdfx_vid so it use sw converter in the driver instead of the hw converters ? That probably make things a lot faster !!! BTW, this rating i'm proposing should not be taken so seriously. I'm just thinking that it would be nice if the user could "easily" tell wich is the fastest colorspace a given vo support. > > > * Report or negotiate pixel aspect ratio of the output picture. For > > > drivers without overlay which can change video mode, we might > > > actually want some way of negotiating a video mode to meet certain > > > size/aspect constraints. > > What we rather want is: the physical aspect ratio of the screen and > > all possible resolutions on this screen. This also imply a way to > > set these videmode. Imho this should be, if possible, separated from > > the vo drivers. All x drivers can use the same code, most console > > based can use the fb modedb thing, etc > > It's still part of the vo driver. If the vo driver wants to call > generic code from x11_helper, that's fine. I was more thinking along the line of a "video mode" driver to allow a single API for video mode query/setting while avoiding duplicate code. > > I think that it must be up to libvo2 user to query avaible video mode > > and set a new mode before calling query_format, config, etc > > An helper func wich auto select best video mode would be nice, but > > libvo2 usurs must have 100% control over video mode selection if > > they need to. > > This is nonsense. You have no idea what video mode you want until the > filter chain starts configuring. Right. But what i was thinking about is that most limits that a vo may have (stride, visible area, etc) will in most case depend on the selected video mode and colorspace. Or taken the other way aroud: it will be hard for a vo to give it's stride restrictions without knowing in wich resolution/colorspace it will run. And that's only resolution. Now if you change display depth you may also change the avaible colorspace too :( I think that we must assume the following to be safe with most hw: - each video mode support a number of colorspace. - in each video mode, each colorspace have it's own restrictions. This mean that you can know the restriction only when you choosed a video mode. What i proposed is the simplest: first set the mode then query restriction. It make driver implementation easy. I agree it would be better if one could query restrictions without really setting the video mode. But it make implementation in drivers a bit harder and for some hw you probably have no other way than setting the mode at least once to get the limits :( > > > * Exporting stride restrictions so the vo2 wrapper can negotiate > > > stride with the filter chain in hopes of getting DR to work. There > > > are actually 2 sets of stride restrictions: one for direct > > > rendering, and the other for all input images. The latter > > > restriction should _ONLY_ be in place if the VO driver does not > > > export its buffers, and requires some sort of slice or frame > > > drawing function to be called (svgalib?). > > Also note that some vo can nearly provide any stride you want. It's > > the case with tdfx_vid wich can use any stride > width (no negative > > stride). Currently in libvo2 the driver have to choose the stride > > itself :( If it knew what stride the last fliter want it could just > > provide it most of the time. > > No problem. The caller (vp layer) decides the stride it wants based on > the source and destination's stride restrictions. Then it will > configure the vo for the selected stride. > > > However there are probably vo that will have different restrictions > > for different colorspace. > > This is annoying, but not necessarily a critical problem. Well, the colorspace imply the bitdepth wich imply how many buffer you may use, how big they can be (bcs of stride limit), etc When i think about nice overlay chip i don't think it's a big problem. But when a start to think about some shitty vga hw ... i fear ;) > > > * A method to request oversized buffers with extra space (which can > > > be > > > written with junk) outside the image dimensions. This allows > > > panscan style direct rendering through crop (and thus vf_panscan) > > > and may be needed for broken codecs which can't do edge emulation > > > or which need extra space to write when width or height % 16 != 0. > > Yes, that sound like a very good idea. Basicaly what is needed is a > > "visible area" area information. However i think that this info must > > also be avaible at config time. > > Of course. _EVERYTHING_ about the image passing is determined at > config time. Dimensions, stride, borders, colorspace, SAR, ... This is > one of the main differences from G1. > > > To resume i think that query_format should return : > > colorspace rating (0 = not supported 1-255 speed rating) > > flags (support oversized buffer, need aligned stride, etc) > > max visible width,height > > min,max strides > > I don't like querying everything at once. Ultimately the only things > you absolutely _need_ to know when configuring are (a) supported > colorspace and (b) whether there's an absolute stride restriction > (only happens when buffers are indirect). All the other queries are > only needed for direct rendering. Personaly i don't like to implement too many query stuff. Again as restrictions depend on colorspace it made sense for me to put that together. > I still haven't decided exactly how query and config should work, > though... :( That's why i was doing some proposition ;) > > And config should get: > > colorspace > > src width, height > > visible width, height, x,y (only if oversized buf supported) > > This is ugly, or at least very different from how vp will work. It > will have width, height, and 4 border sizes (top, bottom, left, > right). But I don't really care if vo is done differently since we get > to wrap it anyway. How fields are named is smthg i don't care about, as long as the information is there in some form or another ;) Imho it should be the same as in vp (or vp the same as vo ;) > > src aspect (imho we should give aspect and helper funcs instead of > > d_width,d_height) > > Of course. We use sample (pixel) aspect, not hideous d_width/d_height > stuff like G1. > > > desired strides (the driver doesn't have to respect these) > > Yes it does (under certain conditions, at least), but the desired > stride is guaranteed to be something the vo agreed to support already. > That's why we negotiate strides in advance. Imvho drivers should work even if the given stride is invalid. So users who don't care can just set it to 0. > > desired num_buff > > This is never known. :( > Very unfortunate, but I don't see any way we can possibly know it. > Maybe force each vp node (decoders and filters) to report how many > buffers they'll need at config time? This would be very helpful, but > might be impossible for some! Or at least very very difficult to guess > correctly... I really understand that in vp it's near to impossible to know. Anyway i thought that as a hint only. It should just give the vo a "good number" to start with. In mplayer the default value would 2 or 3, smtg a la mplayer-xp would would set it to 20 or more. > > flags (fullscreen, etc) > > This is irrelevant to the filter chain. It should be configured some > other way. We are talking about libvo2, aren't we ? At least I am ;) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From attila at kinali.ch Fri Jan 9 10:38:23 2004 From: attila at kinali.ch (Attila Kinali) Date: Fri, 9 Jan 2004 10:38:23 +0100 Subject: [MPlayer-G2-dev] Data communication between demuxers and UIs In-Reply-To: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> Message-ID: <20040109103823.1da75805.attila@kinali.ch> On Thu, 8 Jan 2004 05:29:30 +0200 (EET) Fre_ax wrote: > Now, to solve this problem I was thinking if demuxers would be allowed to > register virtual filesystems for UIs. "Services" would then register mount > points like DVB, HTTP, FTP, CDDA, ... Demuxers would then look for possible > files/streams to play and list them by the virtual filesystem IMHO this should go into to the config layer as there will be more than just the demuxers who should be able to provide dynamical config data after init. And if i understood the current design of the cfg layer, it's thought only for a fixed number of variables which are known at compile time. But i see also a design problem here. IIRC most of the parameters which would be interesting for such a system are not know after preinit, but when the first packet is decoded and the first frame passed trough the vp chain. Am i right ? Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From arpi at thot.banki.hu Thu Jan 15 14:39:11 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 Jan 2004 14:39:11 +0100 (CET) Subject: [Mplayer-g2-dev] test Message-ID: <20040115133911.F07E82C@mail.mplayerhq.hu> Hi, hopefully this list is working again A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Thu Jan 15 14:58:48 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 Jan 2004 14:58:48 +0100 (CET) Subject: [Mplayer-g2-dev] test 2 Message-ID: <20040115135848.49AB485A9@mail.mplayerhq.hu> Hi, huh A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu Jan 15 15:02:10 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 Jan 2004 16:02:10 +0200 Subject: [Mplayer-g2-dev] Re: test 2 In-Reply-To: <20040115135848.49AB485A9@mail.mplayerhq.hu> References: <20040115135848.49AB485A9@mail.mplayerhq.hu> Message-ID: <20040115140210.GF32010@lucky.net> Hi, Arpi! Sometime (on Thursday, January 15 at 15:59) I've received something... >huh It works, don't worry. :) Andriy. From bogus@does.not.exist.com Fri Jan 9 21:21:34 2004 From: bogus@does.not.exist.com () Date: Fri, 9 Jan 2004 15:21:34 -0500 Subject: [MPlayer-G2-dev] Re: requirements for vo2 layer In-Reply-To: <20040109095712.07b3e9cb.albeu@free.fr> References: <20040107194903.GA23773@brightrain.aerifal.cx> <20040108130823.3b941957.albeu@free.fr> <20040109035640.GJ257@brightrain.aerifal.cx> <20040109095712.07b3e9cb.albeu@free.fr> Message-ID: <20040109202134.GR257@brightrain.aerifal.cx> On Fri, Jan 09, 2004 at 09:57:12AM +0100, Alban Bedel wrote: > > Does this case really exist? I've never heard of it. > > 3dfx stuff have such colorspace converters on board. 1 YUV planar -> packed > and 1 YUV packed -> RGB. They are heavily used by tdfxfb and tdfx_vid. > > > Usually the conversion is done in the driver, not the hardware, and this > > is slow so it shouldn't be supported. > > ROTF ??? are you proposing that i rewrite vo_tdfx_vid so it use sw converter > in the driver instead of the hw converters ? That probably make things > a lot faster !!! No, the proposal was that you don't do any conversion and only support the native format, but I agree that's slow in this nasty case. :) > BTW, this rating i'm proposing should not be taken so seriously. I'm just > thinking that it would be nice if the user could "easily" tell wich is > the fastest colorspace a given vo support. OK, how disgusting. Maybe we could indicate some sort of preference, but IMO it will also work without it. The only time you'd be trying to choose between yuy2 and yv12 is when vf_scale is picking its output format, and it already has other considerations to use -- mainly picking the format that minimizes both loss in quality and increase in size. So for example, here are some choices vf_scale would make (assuming both yv12 and yuy2 output are supported): When converting from rgb: yuy2 When downscaling from rgb to 1/2 height or less: yv12 When upscaling from yv12: yv12 When downscaling from yv12: yuy2 When upscaling from yuy2: yuy2 When downscaling from yuy2 to 1/2 height or less: yv12 etc. All of these minimize the amount of computation done in software, so they should give the best performance even if the conversion in hardware is sub-optimal. It's rare that a source filter/codec can generate yuy2 and yv12 with equal efficiency, so I doubt the performance of the hardware converter would ever be a factor. > > > > * Report or negotiate pixel aspect ratio of the output picture. For > > > > drivers without overlay which can change video mode, we might > > > > actually want some way of negotiating a video mode to meet certain > > > > size/aspect constraints. > > > What we rather want is: the physical aspect ratio of the screen and > > > all possible resolutions on this screen. This also imply a way to > > > set these videmode. Imho this should be, if possible, separated from > > > the vo drivers. All x drivers can use the same code, most console > > > based can use the fb modedb thing, etc > > > > It's still part of the vo driver. If the vo driver wants to call > > generic code from x11_helper, that's fine. > > I was more thinking along the line of a "video mode" driver to allow > a single API for video mode query/setting while avoiding duplicate code. This really belongs in the vo. The only common case is X11. Everything else needs its own code (or doesn't care about video mode), and we already have x11_helper for x11. > > > I think that it must be up to libvo2 user to query avaible video mode > > > and set a new mode before calling query_format, config, etc > > > An helper func wich auto select best video mode would be nice, but > > > libvo2 usurs must have 100% control over video mode selection if > > > they need to. > > > > This is nonsense. You have no idea what video mode you want until the > > filter chain starts configuring. > > Right. But what i was thinking about is that most limits that a vo may > have (stride, visible area, etc) will in most case depend on the > selected video mode and colorspace. Or taken the other way aroud: > it will be hard for a vo to give it's stride restrictions without > knowing in wich resolution/colorspace it will run. > > And that's only resolution. Now if you change display depth you may > also change the avaible colorspace too :( > > I think that we must assume the following to be safe with most hw: > - each video mode support a number of colorspace. Each video mode supports a single colorspace. Colorspace is part of the video mode. > - in each video mode, each colorspace have it's own restrictions. Is this really true or not? Stride restrictions are not necessarily fixed numbers. They're things like "must be positive", "must be aligned at N pixels", "must be aligned at N bytes", etc... Do these really differ from mode to mode? > This mean that you can know the restriction only when you choosed > a video mode. What i proposed is the simplest: first set the mode > then query restriction. It make driver implementation easy. This is possible as long as the vo exports its buffers. But it's not possible for vo's that require draw_slice. They _must_ report their restrictions in advance so vf_expand can be inserted if necessary, _before_ the vo is configured. Also this setup is incompatible with the STATIC stride restriction (meaning lavc can't direct render into such vo's). > I agree it would be better if one could query restrictions without > really setting the video mode. But it make implementation in drivers > a bit harder and for some hw you probably have no other way than > setting the mode at least once to get the limits :( Some output API's suck. A few of those (SDL comes to mind) won't be supported because they suck. Others will just have limited capabilities (no DR). Crippling MPlayer for the sake of shitty video api's is not acceptable. > > > To resume i think that query_format should return : > > > colorspace rating (0 = not supported 1-255 speed rating) > > > flags (support oversized buffer, need aligned stride, etc) > > > max visible width,height > > > min,max strides > > > > I don't like querying everything at once. Ultimately the only things > > you absolutely _need_ to know when configuring are (a) supported > > colorspace and (b) whether there's an absolute stride restriction > > (only happens when buffers are indirect). All the other queries are > > only needed for direct rendering. > > Personaly i don't like to implement too many query stuff. > Again as restrictions depend on colorspace it made sense for me to put > that together. > > > I still haven't decided exactly how query and config should work, > > though... :( > > That's why i was doing some proposition ;) OK, let's work out what all is needed: Colorspace Slice stride restrictions Buffer stride restrictions Borders/oversized buffers Max w/h[/stride?] Aspect And now where they're needed: At negotiation time, before actual config: - Colorspace - Slice stride restrictions - Aspect - Width/height If source and dest can't agree on these, converter must be loaded! It must be possible to tell _which_ one is the problem so that the right conversions can be done!! At config time: - Buffer stride restrictions - Borders/oversized buffers These will affect the border and stride options that get stored in the link layer. But if the vo can't provide what's requested, that's ok -- direct rendering will just be disabled and the vp layer will meet the requests using its allocated buffers. > > > And config should get: > > > colorspace > > > src width, height > > > visible width, height, x,y (only if oversized buf supported) > > > > This is ugly, or at least very different from how vp will work. It > > will have width, height, and 4 border sizes (top, bottom, left, > > right). But I don't really care if vo is done differently since we get > > to wrap it anyway. > > How fields are named is smthg i don't care about, as long as the information > is there in some form or another ;) > Imho it should be the same as in vp (or vp the same as vo ;) Well from vp's perspective, the "visible" w/h is the only important property, and the others are just scratch space to the sides of the image to prevent sig11. :) Maybe the vo wants to think of it from a different perspective, but I tend to agree that consistency between the two would be better. > > > desired num_buff > > > > This is never known. :( > > Very unfortunate, but I don't see any way we can possibly know it. > > Maybe force each vp node (decoders and filters) to report how many > > buffers they'll need at config time? This would be very helpful, but > > might be impossible for some! Or at least very very difficult to guess > > correctly... > > I really understand that in vp it's near to impossible to know. Anyway > i thought that as a hint only. It should just give the vo a "good number" > to start with. In mplayer the default value would 2 or 3, smtg a la 2 is never sufficient and 3 is only sufficient without B frames. Default would have to be "unknown" since filters can do whatever they want. On the other hand, lots of problems arise out of not knowing how many buffers we need. I'm almost inclined to completely overhaul the buffer management system (again :/) and include some provision whereby you set up the number of buffers you'll need to use, but I can't think of any way to do it correctly anyway... > > > flags (fullscreen, etc) > > > > This is irrelevant to the filter chain. It should be configured some > > other way. > We are talking about libvo2, aren't we ? At least I am ;) Yes. G1 had a stupid method of setting fullscreen flag at the beginning of the chain and passing it all the way thru, even tho it was irrelevant to everything but the UI. In G2 there's no reason for it to know about fullscreen. That's entirely a UI matter, just like positioning the window on the screen, resizing, etc. Rich From attila at kinali.ch Sun Jan 11 14:36:29 2004 From: attila at kinali.ch (Attila Kinali) Date: Sun, 11 Jan 2004 14:36:29 +0100 Subject: [MPlayer-G2-dev] buffer age & slices: nasty problems In-Reply-To: <20040108003455.GA24349@brightrain.aerifal.cx> References: <20040108003455.GA24349@brightrain.aerifal.cx> Message-ID: <20040111143629.48efdf3c.attila@kinali.ch> On Wed, 7 Jan 2004 19:34:55 -0500 D Richard Felker III wrote: > Buffer age refers to the number of elapsed frames since a buffer was > written. Keeping track of buffer age is very useful for codecs (and > perhaps some filters) because they can skip writing areas that haven't > changed. But it's also a very difficult thing to keep track of with > general get_buffer type management instead of the dumb old IMGTYPE_IPB > approach. > > I see two possible ways to handle it: > > 1. Keeping track of buffer age in the vp layer itself. > > Basically, when requesting an image buffer you'd specify an AGE flag, > meaning (a) you want vp to keep track of the buffer's age, and (b) you > want the vp layer (or the filter/vo you're direct rendering into) the > youngest buffer it can. IMHO this is the best way to go. > This is very easy for AUTO type buffers, and of course not necessary > for EXPORT. But for DIRECT and INDIRECT buffers that are going through > several intermediate filters, it could be very difficult to implement > correctly. Think of a chain like: > > decoder -> tfields -> expand -> vo > > Since tfields makes one INDIRECT buffer out of every _pair_ of > INDIRECT buffers it gets from the vo, it would have to convert 2 ages > into 1... >From my uneducated point of view that's a problem tfields should handle. If i understand it correctly tfields will always need two buffers to write into, so those buffers should be either grouped in pairs or if this is not possible (eg only 3 buffers) then buffer age should be always infinity. > 2. Force codecs that want to take advantage of buffer age/unchanged > blocks to keep a lock on the old buffers and use some sort of > reget_buffer function. > > The basic idea here is that once a buffer is released, its contents > should be considered 100% invalid and its age infinity. Thus if you > want to take advantage of what's already in the buffer, you should > hang onto it. This sound a bit strange to me. Do you mean that the codec should hold a lock trough all the filter chain ? > NOW, MORE BAD NEWS... > > All of this is further complicated by the fact that, when you're doing > DR2 or slices, you actually have _2_ output buffers. One is the > READABLE EXPORT or AUTO type buffer that you're decoding in, and the > other is the non-READABLE DIRECT or INDIRECT type buffer you're > slice-rendering to. In principle, their ages could be different. > > Right now, I have code in the vp layer to simplify slice rendering, so > that when you want to slice-render, you just call start_slices on the > AUTO or EXPORT image you already have, and it then internally manages > the associated DIRECT or INDIRECT type image obtained from the next > filter/vo. But this creates a problem if age isn't managed by the vp > layer, since the codec has no way to tell the age of the (hidden) > buffer slices are going to, and thus doesn't know if it can skip > blocks. Thus i think it should be hanlde by the vp layer. The filters should not have to care about buffer age unless they want to use it for optimization. > Even worse, some filters might accept skipped blocks (simple > colorspace conversion) while others (scale) might have real trouble > with them without lots of clever hacks! how about a flag here ? > Ultimately what this points out is that slices are the barons of hell > (or maybe the cyberdemon) and there seems to be no good way to handle > them while maintaining both _generality_ and sufficient _restraints_ > so that filters can actually handle the slices. Do they give so much speed that it's worth this mess ? For me it looks like that there is a lot of overhead that is needed for proper slice handling that it eats a lot of the cpu time we got out of slices. Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From fre_ax at mbnet.fi Thu Jan 15 15:19:55 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Thu, 15 Jan 2004 16:19:55 +0200 (EET) Subject: [MPlayer-G2-dev] Data communication between demuxers and UIs In-Reply-To: <32798.62.78.110.200.1073821825.squirrel@webmail.mbnet.fi> References: <32798.62.78.110.200.1073821825.squirrel@webmail.mbnet.fi> Message-ID: <32799.62.78.124.185.1074176395.squirrel@webmail.mbnet.fi> Nice to see things working again :) > But i see also a design problem here. IIRC most of the parameters > which would be interesting for such a system are not know after > preinit, but when the first packet is decoded and the first frame > passed trough the vp chain. Am i right ? I dont know about that. Anyhow, this could be partly fixed by allowing "dynamic config data providers" to remove and add options as they want. but this is, as far as i know, very difficult to implement without using timers and other tricks. So the main problem with this is: how to make UIs update available options if new options appear after playback has started ? --Aapo Tahkola From dalias at aerifal.cx Thu Jan 15 18:00:55 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 Jan 2004 12:00:55 -0500 Subject: [MPlayer-G2-dev] buffer age & slices: nasty problems In-Reply-To: <20040111143629.48efdf3c.attila@kinali.ch> References: <20040108003455.GA24349@brightrain.aerifal.cx> <20040111143629.48efdf3c.attila@kinali.ch> Message-ID: <20040115170055.GC257@brightrain.aerifal.cx> On Sun, Jan 11, 2004 at 02:36:29PM +0100, Attila Kinali wrote: > On Wed, 7 Jan 2004 19:34:55 -0500 > D Richard Felker III wrote: > > > Buffer age refers to the number of elapsed frames since a buffer was > > written. Keeping track of buffer age is very useful for codecs (and > > perhaps some filters) because they can skip writing areas that haven't > > changed. But it's also a very difficult thing to keep track of with > > general get_buffer type management instead of the dumb old IMGTYPE_IPB > > approach. > > > > I see two possible ways to handle it: > > > > 1. Keeping track of buffer age in the vp layer itself. > > > > Basically, when requesting an image buffer you'd specify an AGE flag, > > meaning (a) you want vp to keep track of the buffer's age, and (b) you > > want the vp layer (or the filter/vo you're direct rendering into) the > > youngest buffer it can. > > IMHO this is the best way to go. Yeah, I tend to like it too... > > This is very easy for AUTO type buffers, and of course not necessary > > for EXPORT. But for DIRECT and INDIRECT buffers that are going through > > several intermediate filters, it could be very difficult to implement > > correctly. Think of a chain like: > > > > decoder -> tfields -> expand -> vo > > > > Since tfields makes one INDIRECT buffer out of every _pair_ of > > INDIRECT buffers it gets from the vo, it would have to convert 2 ages > > into 1... > > From my uneducated point of view that's a problem tfields should handle. Yes. > > 2. Force codecs that want to take advantage of buffer age/unchanged > > blocks to keep a lock on the old buffers and use some sort of > > reget_buffer function. > > > > The basic idea here is that once a buffer is released, its contents > > should be considered 100% invalid and its age infinity. Thus if you > > want to take advantage of what's already in the buffer, you should > > hang onto it. > > This sound a bit strange to me. Do you mean that the codec > should hold a lock trough all the filter chain ? Yes, I agree it's sort of strange/ugly. > > Even worse, some filters might accept skipped blocks (simple > > colorspace conversion) while others (scale) might have real trouble > > with them without lots of clever hacks! > > how about a flag here ? Maybe, but there are lots of other approaches too... This goes back to the discussion between me and Ivan over how slices should work. Both of our ideas have lots of ugly problems. > > Ultimately what this points out is that slices are the barons of hell > > (or maybe the cyberdemon) and there seems to be no good way to handle > > them while maintaining both _generality_ and sufficient _restraints_ > > so that filters can actually handle the slices. > > Do they give so much speed that it's worth this mess ? > For me it looks like that there is a lot of overhead that > is needed for proper slice handling that it eats a lot > of the cpu time we got out of slices. For just plain drawing, yes, it's huge. Having either slices or DR2 (or both) is absolutely required for a player that doesn't suck. On the other hand, I have no idea if slices significantly improve performance when real filtering is involved, since the extra code coming into the cache to do the image processing might slow us down as much as having the pixels in the cache speeds us up. I wish we had a good way of knowing without spending tons of effort writing this ugly mess... Rich From attila at kinali.ch Thu Jan 15 18:06:39 2004 From: attila at kinali.ch (Attila Kinali) Date: Thu, 15 Jan 2004 18:06:39 +0100 Subject: [MPlayer-G2-dev] buffer age & slices: nasty problems In-Reply-To: <20040115170055.GC257@brightrain.aerifal.cx> References: <20040108003455.GA24349@brightrain.aerifal.cx> <20040111143629.48efdf3c.attila@kinali.ch> <20040115170055.GC257@brightrain.aerifal.cx> Message-ID: <20040115180639.1493bde7.attila@kinali.ch> On Thu, 15 Jan 2004 12:00:55 -0500 D Richard Felker III wrote: > > Do they give so much speed that it's worth this mess ? > > For me it looks like that there is a lot of overhead that > > is needed for proper slice handling that it eats a lot > > of the cpu time we got out of slices. > > For just plain drawing, yes, it's huge. Having either slices or DR2 > (or both) is absolutely required for a player that doesn't suck. On > the other hand, I have no idea if slices significantly improve > performance when real filtering is involved, since the extra code > coming into the cache to do the image processing might slow us down as > much as having the pixels in the cache speeds us up. I wish we had a > good way of knowing without spending tons of effort writing this ugly > mess... In any case of doubt, go allways for the simplest aproach :) Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From dalias at aerifal.cx Thu Jan 15 18:45:42 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 Jan 2004 12:45:42 -0500 Subject: [MPlayer-G2-dev] buffer age & slices: nasty problems In-Reply-To: <20040115180639.1493bde7.attila@kinali.ch> References: <20040108003455.GA24349@brightrain.aerifal.cx> <20040111143629.48efdf3c.attila@kinali.ch> <20040115170055.GC257@brightrain.aerifal.cx> <20040115180639.1493bde7.attila@kinali.ch> Message-ID: <20040115174542.GH257@brightrain.aerifal.cx> On Thu, Jan 15, 2004 at 06:06:39PM +0100, Attila Kinali wrote: > On Thu, 15 Jan 2004 12:00:55 -0500 > D Richard Felker III wrote: > > > > Do they give so much speed that it's worth this mess ? > > > For me it looks like that there is a lot of overhead that > > > is needed for proper slice handling that it eats a lot > > > of the cpu time we got out of slices. > > > > For just plain drawing, yes, it's huge. Having either slices or DR2 > > (or both) is absolutely required for a player that doesn't suck. On > > the other hand, I have no idea if slices significantly improve > > performance when real filtering is involved, since the extra code > > coming into the cache to do the image processing might slow us down as > > much as having the pixels in the cache speeds us up. I wish we had a > > good way of knowing without spending tons of effort writing this ugly > > mess... > > In any case of doubt, go allways for the simplest aproach :) Then G2 will be nice and slow like xine... :) Rich From miffe-miffe at telia.com Thu Jan 15 18:46:08 2004 From: miffe-miffe at telia.com (Mikael Eriksson) Date: Thu, 15 Jan 2004 18:46:08 +0100 Subject: [Mplayer-g2-dev] test In-Reply-To: <20040115133911.F07E82C@mail.mplayerhq.hu> References: <20040115133911.F07E82C@mail.mplayerhq.hu> Message-ID: <4006D1E0.7060209@telia.com> Arpi wrote: > Hi, > > hopefully this list is working again > Why did I get subscribed again? I have been unsubscribet for a few months. > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > Mplayer-g2-dev mailing list > Mplayer-g2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Thu Jan 15 18:50:56 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 Jan 2004 18:50:56 +0100 (CET) Subject: [Mplayer-g2-dev] test In-Reply-To: <4006D1E0.7060209@telia.com> Message-ID: <20040115175056.8183D8746@mail.mplayerhq.hu> Hi, > Arpi wrote: > > Hi, > > > > hopefully this list is working again > > > > Why did I get subscribed again? > I have been unsubscribet for a few months. read news at www.mplayerhq.hu this list has been destroyed due to hdd crash, so been recreated and used userlist from august 2003. please unsubscribe again then. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ivan at cacad.com Thu Jan 15 19:34:32 2004 From: ivan at cacad.com (Ivan Kalvachev) Date: Thu, 15 Jan 2004 20:34:32 +0200 (EET) Subject: [Mplayer-g2-dev] test In-Reply-To: <20040115175056.8183D8746@mail.mplayerhq.hu> References: <4006D1E0.7060209@telia.com> <20040115175056.8183D8746@mail.mplayerhq.hu> Message-ID: <1391.212.116.153.147.1074191672.squirrel@mail.cacad.com> Obviously my previous mail have gone in wrong direction... so i repeat it again. Hmm did I miss something? Yep, it seems that i'm subscribed again to g2 (thx arpi). And it works:)) How about mplayer-dev? the last mail in my inbox is from quite some time. Ivan Arpi said: > Hi, > >> Arpi wrote: >> > Hi, >> > >> > hopefully this list is working again >> > >> >> Why did I get subscribed again? >> I have been unsubscribet for a few months. > > read news at www.mplayerhq.hu > > this list has been destroyed due to hdd crash, so been > recreated and used userlist from august 2003. > > please unsubscribe again then. > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev > From arpi at thot.banki.hu Thu Jan 15 19:40:00 2004 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 Jan 2004 19:40:00 +0100 (CET) Subject: [Mplayer-g2-dev] test In-Reply-To: <1391.212.116.153.147.1074191672.squirrel@mail.cacad.com> Message-ID: <20040115184000.2DDFF87F1@mail.mplayerhq.hu> Hi, > Obviously my previous mail have gone in wrong direction... > so i repeat it again. > > Hmm did I miss something? > Yep, it seems that i'm subscribed again to g2 (thx arpi). And it works:)) > How about mplayer-dev? the last mail in my inbox is from quite some time. this is *NOT* the right list for discussion maillist usage problems... please _STOP_ sending mails like 'i'm subscribed but i didnt get mails' and 'i've unsubscribed why did you subscribe me again' and so on. read news at www.mplayerhq.hu, it's told there that we had several hdd crashes in past weeks and mailman databases got corrupted, so some list are screwed up. verify your subscriptions and (un)subscribe again if needed. i can *NOT* help you doing that. my backup of configs is half year old, so recent changes are all lost. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From joey at nicewarrior.org Thu Jan 15 20:23:48 2004 From: joey at nicewarrior.org (Joey Parrish) Date: Thu, 15 Jan 2004 13:23:48 -0600 Subject: [MPlayer-G2-dev] Data communication between demuxers and UIs In-Reply-To: <32799.62.78.124.185.1074176395.squirrel@webmail.mbnet.fi> References: <32798.62.78.110.200.1073821825.squirrel@webmail.mbnet.fi> <32799.62.78.124.185.1074176395.squirrel@webmail.mbnet.fi> Message-ID: <20040115192348.GB5618@nicewarrior.org> Ack! Where's the reply-to header? Sorry for the duplicate mail Fre_ax, but I meant to send to the list the first time. On Thu, Jan 15, 2004 at 04:19:55PM +0200, Fre_ax wrote: > Anyhow, this could be partly fixed by allowing "dynamic config data > providers" to remove and add > options as they want. but this is, as far as i know, very difficult to > implement without using timers and other tricks. So the main problem > with this is: how to make UIs update available options if new options > appear after playback has started ? Hooks into the UI are out of the question, obviously, so to me it seems like there should be some way for the UI to check to see if these things have changed. If they have, then the UI can request the info, etc. UI's who don't care about this data need not even check for it's existance. Timing can be the problem of the UI? I'm not sure what is involved with that part of the problem, though. --Joey -- All philosophy is naive. From andrej at lucky.net Fri Jan 16 13:33:40 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Fri, 16 Jan 2004 14:33:40 +0200 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040109103823.1da75805.attila@kinali.ch> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> Message-ID: <20040116123340.GG23189@lucky.net> Hi, Attila Kinali! Sometime (on Friday, January 9 at 11:39) I've received something... >On Thu, 8 Jan 2004 05:29:30 +0200 (EET) >Fre_ax wrote: >> Now, to solve this problem I was thinking if demuxers would be allowed to >> register virtual filesystems for UIs. "Services" would then register mount >> points like DVB, HTTP, FTP, CDDA, ... Demuxers would then look for possible >> files/streams to play and list them by the virtual filesystem >IMHO this should go into to the config layer as there will be more than >just the demuxers who should be able to provide dynamical config data >after init. And if i understood the current design of the cfg layer, it's >thought only for a fixed number of variables which are known at compile time. I've already proposed that (see CONF_TYPE_LIST and CONF_TYPE_GROUP config types in maillist earlier) but it seems nobody was interested in dinamic config then although I've said many reasons for that, so config layer still isn't flex enough. :) With best wishes. Andriy. From attila at kinali.ch Fri Jan 16 14:10:12 2004 From: attila at kinali.ch (Attila Kinali) Date: Fri, 16 Jan 2004 14:10:12 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040116123340.GG23189@lucky.net> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> Message-ID: <20040116141012.4a347328.attila@kinali.ch> On Fri, 16 Jan 2004 14:33:40 +0200 "Andriy N. Gritsenko" wrote: > > I've already proposed that (see CONF_TYPE_LIST and CONF_TYPE_GROUP > config types in maillist earlier) but it seems nobody was interested in > dinamic config then although I've said many reasons for that, so config > layer still isn't flex enough. :) The config layer is ok as it is. Dynamic stuff should not be mixed with static variables. The config api should be extended to query for dynamic variables, but i dont have a good idea how to do so. Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From andrej at lucky.net Fri Jan 16 14:48:02 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Fri, 16 Jan 2004 15:48:02 +0200 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040116141012.4a347328.attila@kinali.ch> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> <20040116141012.4a347328.attila@kinali.ch> Message-ID: <20040116134802.GH23189@lucky.net> Hi, Attila Kinali! Sometime (on Friday, January 16 at 15:13) I've received something... >On Fri, 16 Jan 2004 14:33:40 +0200 >"Andriy N. Gritsenko" wrote: >> I've already proposed that (see CONF_TYPE_LIST and CONF_TYPE_GROUP >> config types in maillist earlier) but it seems nobody was interested in >> dinamic config then although I've said many reasons for that, so config >> layer still isn't flex enough. :) >The config layer is ok as it is. Dynamic stuff should not be mixed with >static variables. The config api should be extended to query for dynamic >variables, but i dont have a good idea how to do so. So I've proposed the idea then: 1) node which could have dinamic variables list provides that list (template) as a variable with a special type to UI; 2) UI calls that node for init; 3) node changes own config structure as it needs; 4) UI rechecks node's config structure. I think it must be very simple. Tell me if I was dumb in that. With best wishes. Andriy. From attila at kinali.ch Fri Jan 16 17:20:48 2004 From: attila at kinali.ch (Attila Kinali) Date: Fri, 16 Jan 2004 17:20:48 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040116134802.GH23189@lucky.net> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> <20040116141012.4a347328.attila@kinali.ch> <20040116134802.GH23189@lucky.net> Message-ID: <20040116172048.4d023248.attila@kinali.ch> On Fri, 16 Jan 2004 15:48:02 +0200 "Andriy N. Gritsenko" wrote: > So I've proposed the idea then: > 1) node which could have dinamic variables list provides that list > (template) as a variable with a special type to UI; > 2) UI calls that node for init; > 3) node changes own config structure as it needs; > 4) UI rechecks node's config structure. > > I think it must be very simple. Tell me if I was dumb in that. Yes, it's simple and that is the problem with it, it's too simple. 1) How do you represent the variables, their types and ranges ? 2) How do you avoid inconsistencies (possible sig11) when the node changes the available variables and their ranges. 3) How do you signal changed values. Rechecking all structures for changes isn't a good idea. Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From andrej at lucky.net Mon Jan 19 00:32:28 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 Jan 2004 01:32:28 +0200 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040116172048.4d023248.attila@kinali.ch> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> <20040116141012.4a347328.attila@kinali.ch> <20040116134802.GH23189@lucky.net> <20040116172048.4d023248.attila@kinali.ch> Message-ID: <20040118233228.GA45737@lucky.net> Hi, Attila Kinali! Sometime (on Friday, January 16 at 18:22) I've received something... >On Fri, 16 Jan 2004 15:48:02 +0200 >"Andriy N. Gritsenko" wrote: >> So I've proposed the idea then: >> 1) node which could have dinamic variables list provides that list >> (template) as a variable with a special type to UI; >> 2) UI calls that node for init; >> 3) node changes own config structure as it needs; >> 4) UI rechecks node's config structure. >> >> I think it must be very simple. Tell me if I was dumb in that. >Yes, it's simple and that is the problem with it, it's too simple. >1) How do you represent the variables, their types and ranges ? Of course, as usual, via fields of config_t for each variable. All variables are available as NULL-terminated list, as usual but it must be not static structure for module but dynamic list instead. >2) How do you avoid inconsistencies (possible sig11) when the node > changes the available variables and their ranges. Each time when UI wants change (select, etc.) something in current tree of chains then it will just build own windows etc. based on current tree of variables. So we agree to don't hash all inside of UI and it's all. :) If you mean the case when current value is outside of new range then I think filter/codec/etc. anyway will not get that current value from previous filter/codec/etc. but it may do only UI. >3) How do you signal changed values. Rechecking all structures > for changes isn't a good idea. Let's see - when values may be changed? Only when UI sends some signal to node - play new file, insert new filter, etc. While you play the same file it's silly to change anything by node itself. Then UI will anyway recheck all as I said before in 4). If UI doesn't want change anything then it'll just leave all as before. If UI wants then it'll change it and send some request to node to accept changes. With best wishes. Andriy. From attila at kinali.ch Mon Jan 19 10:58:41 2004 From: attila at kinali.ch (Attila Kinali) Date: Mon, 19 Jan 2004 10:58:41 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040118233228.GA45737@lucky.net> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> <20040116141012.4a347328.attila@kinali.ch> <20040116134802.GH23189@lucky.net> <20040116172048.4d023248.attila@kinali.ch> <20040118233228.GA45737@lucky.net> Message-ID: <20040119105841.57082871.attila@kinali.ch> On Mon, 19 Jan 2004 01:32:28 +0200 "Andriy N. Gritsenko" wrote: > >Yes, it's simple and that is the problem with it, it's too simple. > > >1) How do you represent the variables, their types and ranges ? > > Of course, as usual, via fields of config_t for each variable. All > variables are available as NULL-terminated list, as usual but it must be > not static structure for module but dynamic list instead. That's clear, but how do you set/get the variables itself ? how are they exported ? > >2) How do you avoid inconsistencies (possible sig11) when the node > > changes the available variables and their ranges. > > Each time when UI wants change (select, etc.) something in current > tree of chains then it will just build own windows etc. based on current > tree of variables. So we agree to don't hash all inside of UI and it's > all. :) Ok. > If you mean the case when current value is outside of new range then > I think filter/codec/etc. anyway will not get that current value from > previous filter/codec/etc. but it may do only UI. That's something the UI has to handle. > >3) How do you signal changed values. Rechecking all structures > > for changes isn't a good idea. > > Let's see - when values may be changed? Only when UI sends some > signal to node - play new file, insert new filter, etc. While you play > the same file it's silly to change anything by node itself. Then UI will > anyway recheck all as I said before in 4). If UI doesn't want change > anything then it'll just leave all as before. If UI wants then it'll > change it and send some request to node to accept changes. Sure there isnt any silly container out there, that needs to change the available variables or the variables itself at runtime ? I've seen too many stupid designs in the last few months. Greetings Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From fre_ax at mbnet.fi Tue Jan 20 04:23:23 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Tue, 20 Jan 2004 05:23:23 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040116141012.4a347328.attila@kinali.ch> References: <20040116141012.4a347328.attila@kinali.ch> Message-ID: <32847.62.78.124.181.1074569003.squirrel@webmail.mbnet.fi> > The config layer is ok as it is. Dynamic stuff should not be mixed > with static variables. The config api should be extended to query for > dynamic variables, but i dont have a good idea how to do so. I see no reason why should there be different versions for static and dynamic configurations mainly because there isnt just enough difference between them. Heres my version: Now the main reason why there should be directories is not because config layer would need them but because DVB playlists and generic playlists need it. gmplayer currently implements its own playlist and i see no reason why would all UIs need to have duplicated playlist implementations. Even though UIs wouldnt need to use duplicated playlist code i see this way far more cleaner. This system could also be modified to create directory entries as user opens them(HTTP and FTP browsing). This is how UIs might see this virtual filesystem: - root - generic setup ... - DVB - options option1 option2 - playlist channel1 channel2 - playlist path to playlist file - playlist file1 file2 - demuxers ... Each entry would contain flags that define things like: status locked, disabled, hidden ... dynamic/static config data providers(hosts) would also define data types and limits for each entry so that developers wouldnt need to make changes to UIs each time changes are made. So since these entries can be updated i was thinking if this would be done by adding timestamps(running counter would probably do) for each directory and entry. Example: If DVB->options->option1 gets changed, not only option1's timestamp gets updated but also DVB's and options's. This way UIs would only need to compaire timestamps at the root directory. This isnt perfect though as UIs need to keep track of all entries timestamps. Or would it be better if only the root directory would contain an timestamp and UI's would update everything if that changes ? I also think that removing entries and directories shouldnt be allowed when some directory works as a "dynamic-config"-mode as this way who ever provides dynamic config data could define all reguired data types as global variables. On the other hand, playlists would need linked lists to work with out any silly limitations. This can however be solved by just adding a new directory type. So this would not only take care of current static/dynamic config stuff but also give plenty of slack for future needs. Also using multiple UIs at the same time would be possible, since directories carry locks. Another nice feature would be that config values could be fetched out from cfg clients and saved into config files. Now some code: /* I recall seeing similar system in mplayer g1 */ #define CFG_ENTRY_NODE_INT 1 #define CFG_ENTRY_NODE_STRING 2 #define CFG_ENTRY_NODE_BOOLEAN 3 /* checkbox maybe ? */ /* other data types could include: selection lists, radio buttons, progress bars(i see no problem implementing this), ... */ struct cfg_entry_node_int{ int value; int min_range, max_range; }; struct cfg_entry_node_string{ char *value; // this could be allocated to max_len so that UIs never need to realloc int max_len; /* not really reguired as clients can ask hosts to verify correctness of values */ char *allowed_chars; // 1 allowed, 0 not. size would be 256 of course // ...? }; /* cfg_entry_node_int with ranges 0-1 could take care of this */ struct cfg_entry_node_boolean{ char value; }; struct cfg_entry_option{ int type; /* some info about this option for UIs. (could also be used by the command line interface) */ char *info; union{ struct cfg_entry_node_int int_d; struct cfg_entry_node_string string_d; struct cfg_entry_node_boolean boolean_d; }; }; struct cfg_entry; struct cfg_entry_dir{ char *name; struct cfg_entry *parent; /* could be cfg_entry_dir as well */ llist *entries; // linked list filled with config_entry's pthread_mutex mutex; // or something similar }; #define CFG_ENTRY_TYPE_OPTION 1 #define CFG_ENTRY_TYPE_DIR 2 // more types ? #define CFG_ENTRY_FLAG_LOCKED 1 // read only for UI's #define CFG_ENTRY_FLAG_HIDDEN 2 // hidden dir/option #define CFG_ENTRY_FLAG_DISABLED 3 // dir/option not currently available struct cfg_entry{ int type; /* UIs need to keep track of these and update if changed. Not very nice but i didnt come up with anything better... UIs can however easily check if updates have occurred since all parent directories will get their timestamps updated. Folowing the "path" will then lead to the entry that has changed */ unsigned int timestamp; int flags; union{ struct cfg_entry_option option; struct cfg_entry_dir dir; }; }; #define CFG_OK 0 #define CFG_EINVAL 1 /* ...? */ /* gets filled by hosts */ struct cfg_host { struct cfg_entry *entry; /* UIs call this to do sanity checks. returns CFG_OK, CFG_EINVAL ... It might be smarter if clients never directly modify any of the values in cfg_entry_option since this might make hosts crazy as they loose their sane values(assuming that they dont keep backups), so this callback could be used to actually set the values */ int (*entry_set) (struct cfg_entry *entry, struct cfg_entry *new); // or: //int (*entry_changed) (struct cfg_entry *entry); }; --Aapo Tahkola From dalias at aerifal.cx Tue Jan 20 05:14:56 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 19 Jan 2004 23:14:56 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32847.62.78.124.181.1074569003.squirrel@webmail.mbnet.fi> References: <20040116141012.4a347328.attila@kinali.ch> <32847.62.78.124.181.1074569003.squirrel@webmail.mbnet.fi> Message-ID: <20040120041456.GV257@brightrain.aerifal.cx> On Tue, Jan 20, 2004 at 05:23:23AM +0200, Fre_ax wrote: > > The config layer is ok as it is. Dynamic stuff should not be mixed > > with static variables. The config api should be extended to query for > > dynamic variables, but i dont have a good idea how to do so. > > I see no reason why should there be different versions for static and dynamic > configurations mainly because there isnt just enough difference between them. > > Heres my version: > > Now the main reason why there should be directories is not > because config layer > would need them but because DVB playlists and generic playlists need it. I see no reason playlists are a "config" item. Rather, a playlist is a list of sources and configurations for playing them. Some users of the mplayer-g2 core will want to have playlists, but for others it makes no sense, or needs to be treated differently, so I'm opposed to putting all kinds of playlist nonsense into the core. > gmplayer currently implements its own playlist and i see no reason why would > all UIs need to have duplicated playlist implementations. > Even though UIs wouldnt need to use duplicated playlist code i see this > way far more cleaner. This system could also be modified to create directory > entries as user opens them(HTTP and FTP browsing). > > This is how UIs might see this virtual filesystem: > - root > - generic setup > ... > - DVB > - options > option1 > option2 > - playlist > channel1 > channel2 > > - playlist > path to playlist file > - playlist > file1 > file2 > > - demuxers > ... Interesting but this has nothing to do with the config system as we know it. > Each entry would contain flags that define things like: status locked, > disabled, hidden ... > dynamic/static config data providers(hosts) would also define > data types and limits for each entry so that developers wouldnt > need to make changes to UIs each time changes are made. > > So since these entries can be updated i was thinking if this would be done > by adding timestamps(running counter would probably do) for each > directory and entry. > Example: > If DVB->options->option1 gets changed, not only option1's timestamp > gets updated but also DVB's and options's. > This way UIs would only need to compaire timestamps at the root > directory. This isnt perfect though as UIs need to keep track of all > entries timestamps. Or would it be better if only the root directory > would contain an timestamp and UI's would update everything if that changes ? I don't like this whole "directories" thing. It's windowsish, bloated, and forces a particular system on the caller which won't be appropriate for anything but gui players with playlists. I see no reason why you couldn't build something like this on top of the G2 architecture (including the existing config system) without having to tie all this mess in at a low level where it would be annoying to users who don't want it. Rich From andrej at lucky.net Tue Jan 20 10:38:33 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 20 Jan 2004 11:38:33 +0200 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040119105841.57082871.attila@kinali.ch> References: <32804.62.78.110.237.1073532570.squirrel@webmail.mbnet.fi> <20040109103823.1da75805.attila@kinali.ch> <20040116123340.GG23189@lucky.net> <20040116141012.4a347328.attila@kinali.ch> <20040116134802.GH23189@lucky.net> <20040116172048.4d023248.attila@kinali.ch> <20040118233228.GA45737@lucky.net> <20040119105841.57082871.attila@kinali.ch> Message-ID: <20040120093833.GA49365@lucky.net> Hi, Attila Kinali! Sometime (on Monday, January 19 at 11:59) I've received something... >On Mon, 19 Jan 2004 01:32:28 +0200 >"Andriy N. Gritsenko" wrote: >> >Yes, it's simple and that is the problem with it, it's too simple. >> >1) How do you represent the variables, their types and ranges ? >> Of course, as usual, via fields of config_t for each variable. All >> variables are available as NULL-terminated list, as usual but it must be >> not static structure for module but dynamic list instead. >That's clear, but how do you set/get the variables itself ? >how are they exported ? I'll try to explain it again. Of course, node has no variables until node isn't fully inited. After it's done, node set config_t list in some node->config (note: it must be not static as module->config but only per-instance config so as I've proposed before we have to have config_t* and config_data* entries in each node structure not in module only). And UI knows it's dynamic so it'll do all as usual but after init only. :) >> >2) How do you avoid inconsistencies (possible sig11) when the node >> > changes the available variables and their ranges. >> Each time when UI wants change (select, etc.) something in current >> tree of chains then it will just build own windows etc. based on current >> tree of variables. So we agree to don't hash all inside of UI and it's >> all. :) >Ok. >> If you mean the case when current value is outside of new range then >> I think filter/codec/etc. anyway will not get that current value from >> previous filter/codec/etc. but it may do only UI. >That's something the UI has to handle. >> >3) How do you signal changed values. Rechecking all structures >> > for changes isn't a good idea. >> Let's see - when values may be changed? Only when UI sends some >> signal to node - play new file, insert new filter, etc. While you play >> the same file it's silly to change anything by node itself. Then UI will >> anyway recheck all as I said before in 4). If UI doesn't want change >> anything then it'll just leave all as before. If UI wants then it'll >> change it and send some request to node to accept changes. >Sure there isnt any silly container out there, that needs to change >the available variables or the variables itself at runtime ? >I've seen too many stupid designs in the last few months. Hmm, it may be a little problem. Anyway there is field flags in config_t so we may create some CONF_CHANGED flag to notify UI there was changes in it. And anyway since we agree UI cannot cache config items, these items will show all changed values when UI will want see them. :) >Greetings With best wishes to you too. Andriy. From fre_ax at mbnet.fi Tue Jan 20 23:01:28 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Wed, 21 Jan 2004 00:01:28 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040120041456.GV257@brightrain.aerifal.cx> References: <20040120041456.GV257@brightrain.aerifal.cx> Message-ID: <32793.62.78.123.163.1074636088.squirrel@webmail.mbnet.fi> > I see no reason playlists are a "config" item. Rather, a playlist is a > list of sources and configurations for playing them. Some users of the > mplayer-g2 core will want to have playlists, but for others it makes > no sense, or needs to be treated differently, so I'm opposed to > putting all kinds of playlist nonsense into the core. So lets rename it to "data layer" and add seperate directory types for config data and playlists. I dont set the rules, by all means code at Gui directory could register these playlist directories. > Interesting but this has nothing to do with the config system as we > know it. Yes i have realized that this is more about providing from place to place. > I don't like this whole "directories" thing. It's windowsish, bloated, > and forces a particular system on the caller which won't be > appropriate for anything but gui players with playlists. True but who says the command line interface would need to open this playlist directory and activate(generate entries in side the directory) this code at all?Of course these directories wouldnt even exist if user wants no guis. So you think its nicer to have tens and tens of options without grouping them atall ? Yes, defined data types will define the "look" of UIs(including command line interface) but i dont see why this would be any kind of problem. what do you mean by bloated exactly? > I see no reason why you couldn't build something like this on top of > the G2 architecture (including the existing config system) without > having to tie all this mess in at a low level where it would be > annoying to users who don't want it. Why would one want to keep this system and existing config system seperate ? Adding new entry type that contains codecs_t or similar structures is no problem. I do agree that its useless to implement this system if both dynamic and static configs(including relevant data communication with these structs) cannot be handled by extending this system. I would however want to remind you that this system solves problems with DVB playlists, dynamic configuration and probably some other things. --Aapo Tahkola From dalias at aerifal.cx Wed Jan 21 03:51:35 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 20 Jan 2004 21:51:35 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32793.62.78.123.163.1074636088.squirrel@webmail.mbnet.fi> References: <20040120041456.GV257@brightrain.aerifal.cx> <32793.62.78.123.163.1074636088.squirrel@webmail.mbnet.fi> Message-ID: <20040121025135.GM257@brightrain.aerifal.cx> On Wed, Jan 21, 2004 at 12:01:28AM +0200, Fre_ax wrote: > > I see no reason playlists are a "config" item. Rather, a playlist is a > > list of sources and configurations for playing them. Some users of the > > mplayer-g2 core will want to have playlists, but for others it makes > > no sense, or needs to be treated differently, so I'm opposed to > > putting all kinds of playlist nonsense into the core. > So lets rename it to "data layer" and add seperate directory types for > config data > and playlists. Config does NOT fit into nice little directories like you imagine. You have little understanding of the config requirements it seems. > I dont set the rules, by all means code at Gui directory could register > these playlist directories. > > > Interesting but this has nothing to do with the config system as we > > know it. > Yes i have realized that this is more about providing from place to place. > > > I don't like this whole "directories" thing. It's windowsish, bloated, > > and forces a particular system on the caller which won't be > > appropriate for anything but gui players with playlists. > True but who says the command line interface would need to open this playlist > directory and activate(generate entries in side the directory) this code > at all?Of course these directories wouldnt even exist if user wants no guis. > So you think its nicer to have tens and tens of options without grouping > them atall ? No, if you'd read any of the previous material on the config layer you'd notice that it's all associated with instances of something, not horrible globals like in G1. > Yes, defined data types will define the "look" of UIs(including command line > interface) but i dont see why this would be any kind of problem. > > what do you mean by bloated exactly? Dependency on an extra layer which isn't needed. > > I see no reason why you couldn't build something like this on top of > > the G2 architecture (including the existing config system) without > > having to tie all this mess in at a low level where it would be > > annoying to users who don't want it. > Why would one want to keep this system and existing config system seperate ? Because they don't belong together. Your directory "contains" config data, so it can depend on the config layer, but there is no poing whatsoever in the config layer depending on your directory stuff. In fact when the config system was first discussed, one of the major proposals that caused lots of flames was tightly integrating the config system with gui/app/playlist stuff. The final decision was to layer the config system, with the basic levels only defining data structures and functions for manipulating config, and only putting the gui/app stuff on the very top (and totally optional) layer. > Adding new entry type that contains codecs_t or similar structures is no > problem. > > I do agree that its useless to implement this system if both dynamic and > static configs(including relevant data communication with these structs) > cannot be handled by extending this system. What on earth is a dynamic config?? > I would however want to remind you that this system solves problems with DVB > playlists, dynamic configuration and probably some other things. It doesn't solve any problem with dynamic configuration. The difficult end of dynamic configuration is the other end, the implementation. As for DVB playlists, WTF is so special about them? How are they different than any other playlist? Rich From fre_ax at mbnet.fi Thu Jan 22 03:13:36 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Thu, 22 Jan 2004 04:13:36 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040121025135.GM257@brightrain.aerifal.cx> References: <20040121025135.GM257@brightrain.aerifal.cx> Message-ID: <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> >> > I see no reason playlists are a "config" item. Rather, a playlist is >> > a list of sources and configurations for playing them. Some users >> > of the mplayer-g2 core will want to have playlists, but for others >> > it makes no sense, or needs to be treated differently, so I'm >> > opposed to putting all kinds of playlist nonsense into the core. >> So lets rename it to "data layer" and add seperate directory types >> for config data >> and playlists. > > Config does NOT fit into nice little directories like you imagine. You > have little understanding of the config requirements it seems. Yes im having trouble understanding how adding directories would make everythingincompatible. >> > I don't like this whole "directories" thing. It's windowsish, >> > bloated, and forces a particular system on the caller which won't >> > be >> > appropriate for anything but gui players with playlists. >> True but who says the command line interface would need to open this >> playlist directory and activate(generate entries in side the >> directory) this code at all?Of course these directories wouldnt even >> exist if user wants no guis. So you think its nicer to have tens and >> tens of options without grouping them atall ? > > No, if you'd read any of the previous material on the config layer > you'd notice that it's all associated with instances of something, not > horrible globals like in G1. Good, so g2's config system is now good and capable of taking care of future needs ? >> what do you mean by bloated exactly? > > Dependency on an extra layer which isn't needed. I believe its needed for option groups. The command line interface is JUST another UI with some special needs. If you disagree with this then you are discriminating other UIs. Dont get me wrong iv seen these media players for linux come and go so i understand that in mplayer g1 command line interface is superior but thisis g2 we speak of. This way adding new options can be done by editing just ONE file BTW. > In fact when the config system was first discussed, one of the major > proposals that caused lots of flames was tightly integrating the > config system with gui/app/playlist stuff. The final decision was to > layer the config system, with the basic levels only defining data > structures and functions for manipulating config, and only putting the > gui/app stuff on the very top (and totally optional) layer. Again if you guys think g2s config system is now good, i can just as well implement this system for playlists only. >> Adding new entry type that contains codecs_t or similar structures is >> no problem. >> >> I do agree that its useless to implement this system if both dynamic >> and static configs(including relevant data communication with these >> structs) cannot be handled by extending this system. > > What on earth is a dynamic config?? Static you mean? Say configuration that cannot take place when playing files. This of course makes no difference for guis as all configuration can be considered to be dynamic. >> I would however want to remind you that this system solves problems >> with DVB playlists, dynamic configuration and probably some other >> things. > > It doesn't solve any problem with dynamic configuration. The difficult > end of dynamic configuration is the other end, the implementation. I take that back, it implements dynamic configuration. > As for DVB playlists, WTF is so special about them? How are they > different than any other playlist? DVB channels arent real files but rather io calls to kernel land. This is currently done with libmpdemux/dvb* files in mplayer g1. Also i would be willing to partly(or entirely) implement curses based mplayer after/if you get this dynamic config stuff sorted out. Or would it be better ifthere would be GUI in the playback window ? --Aapo Tahkola From dalias at aerifal.cx Thu Jan 22 07:28:22 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 22 Jan 2004 01:28:22 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> References: <20040121025135.GM257@brightrain.aerifal.cx> <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> Message-ID: <20040122062822.GW257@brightrain.aerifal.cx> On Thu, Jan 22, 2004 at 04:13:36AM +0200, Fre_ax wrote: > >> > I see no reason playlists are a "config" item. Rather, a playlist is > >> > a list of sources and configurations for playing them. Some users > >> > of the mplayer-g2 core will want to have playlists, but for others > >> > it makes no sense, or needs to be treated differently, so I'm > >> > opposed to putting all kinds of playlist nonsense into the core. > >> So lets rename it to "data layer" and add seperate directory types > >> for config data > >> and playlists. > > > > Config does NOT fit into nice little directories like you imagine. You > > have little understanding of the config requirements it seems. > > Yes im having trouble understanding how adding directories would make > everythingincompatible. Explain for us how you configure audio and video filter chains with your directory system. ...and nonlinear ones? > >> > I don't like this whole "directories" thing. It's windowsish, > >> > bloated, and forces a particular system on the caller which won't > >> > be > >> > appropriate for anything but gui players with playlists. > >> True but who says the command line interface would need to open this > >> playlist directory and activate(generate entries in side the > >> directory) this code at all?Of course these directories wouldnt even > >> exist if user wants no guis. So you think its nicer to have tens and > >> tens of options without grouping them atall ? > > > > No, if you'd read any of the previous material on the config layer > > you'd notice that it's all associated with instances of something, not > > horrible globals like in G1. > > Good, so g2's config system is now good and capable of taking care of future > needs ? Yes the config system is already good. Please read the work that's already been done before trying to reinvent it. > >> what do you mean by bloated exactly? > > > > Dependency on an extra layer which isn't needed. > > I believe its needed for option groups. The command line interface is JUST > another UI with some special needs. If you disagree with this then you are > discriminating other UIs. Good. :) It's not that I want to make things difficult on the gui fans... ;) but command line/config file option=value type stuff is somehow special (and imo much more important since the gui stuff will be built on top of it with extra hints to govern ranges, grouping, etc.) > Dont get me wrong iv seen these media players for linux come and go I've seen one usable one come and some other nonusable ones (too slow, X-only, buggy/crashing, etc.) go... > so i understand that in mplayer g1 command line interface is superior but > thisis g2 we speak of. > This way adding new options can be done by editing just ONE file BTW. Huh? No way. The options can't all be in one file because they belong to different _independent_ modules. Independence of the modules is one of the key goals of g2. > > In fact when the config system was first discussed, one of the major > > proposals that caused lots of flames was tightly integrating the > > config system with gui/app/playlist stuff. The final decision was to > > layer the config system, with the basic levels only defining data > > structures and functions for manipulating config, and only putting the > > gui/app stuff on the very top (and totally optional) layer. > > Again if you guys think g2s config system is now good, i can just as > well implement this system for playlists only. Yes. Your idea may very well be good for playlists. One obstacle though is storing with your playlist the necessary config to represent the rendering pipeline (audio and video filters, etc.). Depending on how we want to do this, it may affect the generality of your playlist system, and that in turn provides a good reason why the MPlayer core shouldn't depend on the playlist system. For example most players may not care to support multi-file input streams with filters to merge them, so maybe the playlist shouldn't either. It seems to me this sort of feature is mainly useful in an editor/encoder app instead. On the other hand, maybe someone would find it useful. I don't know the answers to all these questions right now, so I'm trying to work on the lower-level stuff that really matters right now so we can defer decisions like this until after the basic code is in place and working. > >> Adding new entry type that contains codecs_t or similar structures is > >> no problem. > >> > >> I do agree that its useless to implement this system if both dynamic > >> and static configs(including relevant data communication with these > >> structs) cannot be handled by extending this system. > > > > What on earth is a dynamic config?? > > Static you mean? Say configuration that cannot take place when > playing files. This of course makes no difference for guis as all > configuration can be considered to be dynamic. Oh, ok. I thought you were talking about extra options that somehow "dynamically" came into existence later on. > >> I would however want to remind you that this system solves problems > >> with DVB playlists, dynamic configuration and probably some other > >> things. > > > > It doesn't solve any problem with dynamic configuration. The difficult > > end of dynamic configuration is the other end, the implementation. > > I take that back, it implements dynamic configuration. IMO it doesn't do that. Anyway, there are two ends to dynamic configuration. The end you (and the other config people) are trying to "solve" is the trivial end, the api for the UI to use to reconfigure options. There's nothing difficult about that at all. The difficult end is "repairing" filter chains, renegotiating link parameters, etc. to accommodate changing options. > > As for DVB playlists, WTF is so special about them? How are they > > different than any other playlist? > > DVB channels arent real files but rather io calls to kernel land. > This is currently done with libmpdemux/dvb* files in mplayer g1. > > Also i would be willing to partly(or entirely) implement curses based mplayer > after/if you get this dynamic config stuff sorted out. Or would it be > better ifthere would be GUI in the playback window ? UI in playback window would be much better, IMO. How are you supposed to see the curses interface if there's a movie in front of it? :) On the other hand, since it might be useful sometimes (windowed playback under X only) you could make a curses interface, and then add a terminal-emulator to MPlayer. :))) So MPlayer could run its curses gui inside its own terminal emulator which displays overlaid onto the movie... ;) Rich From attila at kinali.ch Thu Jan 22 09:03:45 2004 From: attila at kinali.ch (Attila Kinali) Date: Thu, 22 Jan 2004 09:03:45 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122062822.GW257@brightrain.aerifal.cx> References: <20040121025135.GM257@brightrain.aerifal.cx> <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> <20040122062822.GW257@brightrain.aerifal.cx> Message-ID: <20040122090345.13b0cb84.attila@kinali.ch> On Thu, 22 Jan 2004 01:28:22 -0500 D Richard Felker III wrote: > The difficult > end is "repairing" filter chains, renegotiating link parameters, etc. > to accommodate changing options. That's a really good question. Do you have an idea how this can be done ? Or is it a trivial, call config() on all nodes in the chain ? Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu From fre_ax at mbnet.fi Thu Jan 22 11:06:53 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Thu, 22 Jan 2004 12:06:53 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122062822.GW257@brightrain.aerifal.cx> References: <20040122062822.GW257@brightrain.aerifal.cx> Message-ID: <32966.62.78.106.123.1074766013.squirrel@webmail.mbnet.fi> >> >> > I see no reason playlists are a "config" item. Rather, a playlist >> >> > is a list of sources and configurations for playing them. Some >> >> > users of the mplayer-g2 core will want to have playlists, but >> >> > for others it makes no sense, or needs to be treated >> >> > differently, so I'm opposed to putting all kinds of playlist >> >> > nonsense into the core. >> >> So lets rename it to "data layer" and add seperate directory types >> >> for config data >> >> and playlists. >> > >> > Config does NOT fit into nice little directories like you imagine. >> > You have little understanding of the config requirements it seems. >> >> Yes im having trouble understanding how adding directories would make >> everythingincompatible. > > Explain for us how you configure audio and video filter chains with > your directory system. > > ...and nonlinear ones? Remember that entry_set function pointer in struct cfg_host ? This funtion would also allow "config hosts" make further changes to the configuration. int (*entry_set) (struct cfg_entry *entry, struct cfg_entry *new); Would change to: char *(*entry_set) (struct cfg_entry *entry, struct cfg_entry *new, struct cfg_entry *root_dir); Text returned by this "activate option" function could then be showed to the user on error cases. This together with host side callback function should take care of it. ;) Of course im not sure as i dont know how these things work in reality. >> >> > I don't like this whole "directories" thing. It's windowsish, >> >> > bloated, and forces a particular system on the caller which >> >> > won't be >> >> > appropriate for anything but gui players with playlists. >> >> True but who says the command line interface would need to open >> >> this playlist directory and activate(generate entries in side the >> >> directory) this code at all?Of course these directories wouldnt >> >> even exist if user wants no guis. So you think its nicer to have >> >> tens and tens of options without grouping them atall ? >> > >> > No, if you'd read any of the previous material on the config layer >> > you'd notice that it's all associated with instances of something, >> > not horrible globals like in G1. >> >> Good, so g2's config system is now good and capable of taking care of >> future needs ? > > Yes the config system is already good. Please read the work that's > already been done before trying to reinvent it. Im exactly reinventing this for my own needs as im working on something that will need lots of options and functions to make it work with plugins. However im still claiming that my system would be adding other than directories. >> >> what do you mean by bloated exactly? >> > >> > Dependency on an extra layer which isn't needed. >> >> I believe its needed for option groups. The command line interface is >> JUST another UI with some special needs. If you disagree with this >> then you are discriminating other UIs. > > Good. :) > It's not that I want to make things difficult on the gui fans... ;) Im no gui fan! :D I just see having around 1000(half of them dont even work) channels kinda troublesome to handle and group with emacs. ;) Sure there are some programs that can do it but they are all, as far as i know,bad solutions as they dont directly handle this stuff inside mplayer. > but command line/config file option=value type stuff is somehow > special (and imo much more important since the gui stuff will be built > on top of it with extra hints to govern ranges, grouping, etc.) >> This way adding new options can be done by editing just ONE file BTW. > Huh? No way. The options can't all be in one file because they belong > to different _independent_ modules. Independence of the modules is one > of the key goals of g2. No, not that way. Each module would of course define their own stuff. What i mean is that UIs would just "render" this directory(module) as they want. >> > In fact when the config system was first discussed, one of the >> > major proposals that caused lots of flames was tightly integrating >> > the config system with gui/app/playlist stuff. The final decision >> > was to layer the config system, with the basic levels only defining >> > data structures and functions for manipulating config, and only >> > putting the gui/app stuff on the very top (and totally optional) >> > layer. >> >> Again if you guys think g2s config system is now good, i can just as >> well implement this system for playlists only. > > Yes. Your idea may very well be good for playlists. > > One obstacle though is storing with your playlist the necessary config > to represent the rendering pipeline (audio and video filters, etc.). > Depending on how we want to do this, it may affect the generality of > your playlist system, and that in turn provides a good reason why the > MPlayer core shouldn't depend on the playlist system. > > For example most players may not care to support multi-file input > streams with filters to merge them, so maybe the playlist shouldn't > either. It seems to me this sort of feature is mainly useful in an > editor/encoder app instead. On the other hand, maybe someone would > find it useful. I don't know the answers to all these questions right > now, so I'm trying to work on the lower-level stuff that really > matters right now so we can defer decisions like this until after the > basic code is in place and working. Agreed. I see creating new channels can be a problem and thats why i think playlists should be allowed to optionally define the representation of this. I mean if dvb, http and ftp gets implemented this way why wouldnt normal filesystem ? But then again, would it work ? That would the command line interface think about this ? I do think that guis should not be given more than bunch of config_t's to represent the outlook of the options. >> >> I would however want to remind you that this system solves >> >> problems with DVB playlists, dynamic configuration and probably >> >> some other things. >> > >> > It doesn't solve any problem with dynamic configuration. The >> > difficult end of dynamic configuration is the other end, the >> > implementation. >> >> I take that back, it implements dynamic configuration. > > IMO it doesn't do that. Anyway, there are two ends to dynamic > configuration. The end you (and the other config people) are trying to > "solve" is the trivial end, the api for the UI to use to reconfigure > options. There's nothing difficult about that at all. The difficult > end is "repairing" filter chains, renegotiating link parameters, etc. > to accommodate changing options. I believe this could be possible since this "activate option" function at the configuration client side can make further changes to the configuration. Again im not sure as i havent been reading mplayers sources much. >> Also i would be willing to partly(or entirely) implement curses based >> mplayer after/if you get this dynamic config stuff sorted out. Or >> would it be better ifthere would be GUI in the playback window ? > > UI in playback window would be much better, IMO. How are you supposed > to see the curses interface if there's a movie in front of it? :) Yes and this would be pretty useless for console users with framebuffers. > On the other hand, since it might be useful sometimes (windowed > playback under X only) you could make a curses interface, and then add > a terminal-emulator to MPlayer. :))) So MPlayer could run its curses > gui inside its own terminal emulator which displays overlaid onto the > movie... ;) Hehe. Yah, im not sure how curses works but as far as i can remember it only allows users to set chars at x, y location on screen. So this "show-on-screen"-functioncould just as well be function pointer that can be switched when using different UIs. --Aapo Tahkola From ajh at watri.org.au Thu Jan 22 16:37:47 2004 From: ajh at watri.org.au (Anders Johansson) Date: Thu, 22 Jan 2004 23:37:47 +0800 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122090345.13b0cb84.attila@kinali.ch> References: <20040121025135.GM257@brightrain.aerifal.cx> <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> <20040122062822.GW257@brightrain.aerifal.cx> <20040122090345.13b0cb84.attila@kinali.ch> Message-ID: <20040122153747.GB12960@watri.org.au> > On Thu, 22 Jan 2004 01:28:22 -0500 > D Richard Felker III wrote: > > > The difficult > > end is "repairing" filter chains, renegotiating link parameters, etc. > > to accommodate changing options. > > > That's a really good question. Do you have an idea how this can > be done ? > Or is it a trivial, call config() on all nodes in the chain ? > > Attila Kinali I bet someone thought about this prevously, I have for one (differnt application though). I ended up with software standards for middle ware like CORBA and XMLRPC, Sun has some solution as well, in the end I gave up and went for a static config using XML (I have the code in a lib if someone is interested). If someone actually find a good solution/standard to dynamic config please post it here. Cheers, //Anders From dalias at aerifal.cx Thu Jan 22 18:06:40 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 22 Jan 2004 12:06:40 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32966.62.78.106.123.1074766013.squirrel@webmail.mbnet.fi> References: <20040122062822.GW257@brightrain.aerifal.cx> <32966.62.78.106.123.1074766013.squirrel@webmail.mbnet.fi> Message-ID: <20040122170640.GB257@brightrain.aerifal.cx> On Thu, Jan 22, 2004 at 12:06:53PM +0200, Fre_ax wrote: > >> >> what do you mean by bloated exactly? > >> > > >> > Dependency on an extra layer which isn't needed. > >> > >> I believe its needed for option groups. The command line interface is > >> JUST another UI with some special needs. If you disagree with this > >> then you are discriminating other UIs. > > > > Good. :) > > It's not that I want to make things difficult on the gui fans... ;) > > Im no gui fan! :D > I just see having around 1000(half of them dont even work) channels kinda > troublesome to handle and group with emacs. ;) That's what perl is for. :) > >> This way adding new options can be done by editing just ONE file BTW. > > > Huh? No way. The options can't all be in one file because they belong > > to different _independent_ modules. Independence of the modules is one > > of the key goals of g2. > > No, not that way. Each module would of course define their own stuff. > What i mean is that UIs would just "render" this directory(module) as they > want. That's what you misunderstand about modules. They are NOT single-instance components, but can be loaded many times with completely independent configuration for use in different places, and the only thing that distinguishes one instance from another is "where" it is connected to other modules. Without your playlist/"directory" system this is entirely the problem of the calling app to handle. (It's actually fairly simple in the command-line case since the caller can just pass string config to helper functions without having to worry about the internals, but for gui or runtime config it's more complicated.) AFAIK your directory system is not designed to handle something like this. > >> > In fact when the config system was first discussed, one of the > >> > major proposals that caused lots of flames was tightly integrating > >> > the config system with gui/app/playlist stuff. The final decision > >> > was to layer the config system, with the basic levels only defining > >> > data structures and functions for manipulating config, and only > >> > putting the gui/app stuff on the very top (and totally optional) > >> > layer. > >> > >> Again if you guys think g2s config system is now good, i can just as > >> well implement this system for playlists only. > > > > Yes. Your idea may very well be good for playlists. > > > > One obstacle though is storing with your playlist the necessary config > > to represent the rendering pipeline (audio and video filters, etc.). > > Depending on how we want to do this, it may affect the generality of > > your playlist system, and that in turn provides a good reason why the > > MPlayer core shouldn't depend on the playlist system. > > > > For example most players may not care to support multi-file input > > streams with filters to merge them, so maybe the playlist shouldn't > > either. It seems to me this sort of feature is mainly useful in an > > editor/encoder app instead. On the other hand, maybe someone would > > find it useful. I don't know the answers to all these questions right > > now, so I'm trying to work on the lower-level stuff that really > > matters right now so we can defer decisions like this until after the > > basic code is in place and working. > > Agreed. I see creating new channels can be a problem and thats why i think > playlists should be allowed to optionally define the representation of this. Huh? This has nothing to do with what I said. > I mean if dvb, http and ftp gets implemented this way why wouldnt normal > filesystem ? ??? > But then again, would it work ? > That would the command line interface think about this ? ??? > I do think that guis should not be given more than bunch of > config_t's to represent the outlook of the options. Sorry, that's simply not possible. They have to be aware of the structure in which components are connected. > > On the other hand, since it might be useful sometimes (windowed > > playback under X only) you could make a curses interface, and then add > > a terminal-emulator to MPlayer. :))) So MPlayer could run its curses > > gui inside its own terminal emulator which displays overlaid onto the > > movie... ;) > Hehe. > Yah, im not sure how curses works but as far as i can remember it only allows > users to set chars at x, y location on screen. So this > "show-on-screen"-functioncould just as well be function pointer that can be switched when using > different UIs. That's not what I mean. I said an actual terminal emulator in MPlayer. Rich From dalias at aerifal.cx Thu Jan 22 18:09:11 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 22 Jan 2004 12:09:11 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122090345.13b0cb84.attila@kinali.ch> References: <20040121025135.GM257@brightrain.aerifal.cx> <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> <20040122062822.GW257@brightrain.aerifal.cx> <20040122090345.13b0cb84.attila@kinali.ch> Message-ID: <20040122170911.GC257@brightrain.aerifal.cx> On Thu, Jan 22, 2004 at 09:03:45AM +0100, Attila Kinali wrote: > On Thu, 22 Jan 2004 01:28:22 -0500 > D Richard Felker III wrote: > > > The difficult > > end is "repairing" filter chains, renegotiating link parameters, etc. > > to accommodate changing options. > > > That's a really good question. Do you have an idea how this can > be done ? > Or is it a trivial, call config() on all nodes in the chain ? Yes, it basically amounts to that, but there are various questions. For example if there's a filter that can't change parameters without losing frames (due to internal buffering latency), should you completely reset this filter and give bad output? Or should you insert scale on one or both sides of it to hide the format/size changes from it? I don't know what the best answer is... Rich From fre_ax at mbnet.fi Fri Jan 23 09:25:15 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Fri, 23 Jan 2004 10:25:15 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122170640.GB257@brightrain.aerifal.cx> References: <20040122170640.GB257@brightrain.aerifal.cx> Message-ID: <32874.62.78.105.77.1074846315.squirrel@webmail.mbnet.fi> >> >> This way adding new options can be done by editing just ONE file >> >> BTW. >> >> > Huh? No way. The options can't all be in one file because they >> > belong to different _independent_ modules. Independence of the >> > modules is one of the key goals of g2. >> >> No, not that way. Each module would of course define their own stuff. >> What i mean is that UIs would just "render" this directory(module) as >> they want. > > That's what you misunderstand about modules. They are NOT > single-instance components, but can be loaded many times with > completely independent configuration for use in different places, and > the only thing that distinguishes one instance from another is "where" > it is connected to other modules. Without your playlist/"directory" > system this is entirely the problem of the calling app to handle. > (It's actually fairly simple in the command-line case since the caller > can just pass string config to helper functions without having to > worry about the internals, but for gui or runtime config it's more > complicated.) AFAIK your directory system is not designed to handle > something like this. Aha. >> >> > In fact when the config system was first discussed, one of the >> >> > major proposals that caused lots of flames was tightly >> >> > integrating the config system with gui/app/playlist stuff. The >> >> > final decision was to layer the config system, with the basic >> >> > levels only defining data structures and functions for >> >> > manipulating config, and only putting the gui/app stuff on the >> >> > very top (and totally optional) layer. >> >> >> >> Again if you guys think g2s config system is now good, i can just >> >> as well implement this system for playlists only. >> > >> > Yes. Your idea may very well be good for playlists. >> > >> > One obstacle though is storing with your playlist the necessary >> > config to represent the rendering pipeline (audio and video >> > filters, etc.). Depending on how we want to do this, it may affect >> > the generality of your playlist system, and that in turn provides a >> > good reason why the MPlayer core shouldn't depend on the playlist >> > system. >> > >> > For example most players may not care to support multi-file input >> > streams with filters to merge them, so maybe the playlist shouldn't >> > either. It seems to me this sort of feature is mainly useful in an >> > editor/encoder app instead. On the other hand, maybe someone would >> > find it useful. I don't know the answers to all these questions >> > right now, so I'm trying to work on the lower-level stuff that >> > really matters right now so we can defer decisions like this until >> > after the basic code is in place and working. >> >> Agreed. I see creating new channels can be a problem and thats why i >> think playlists should be allowed to optionally define the >> representation of this. > > Huh? This has nothing to do with what I said. I agree that its too early to say without knowing how lower level works. Got carried away from the subject. ;) In order to add new DVB channels with any of the guis one would need to definethings like name, frequency, polarity, satellite no, symbol rate, vpid, apid. There are plentty of ways to do this IMHO but id say dynamic config would stepin at some point. And no i dont mean just DVB channels but maybe also https user names, passwords, ports and maybe other streaming stuff that just cannot be treated as normal files. What i mean is that browsing of normal files and playlists could be implementedwith virtual directories just above each individual gui. So each gui wouldnt need to use opendir and stuff directly. >> I do think that guis should not be given more than bunch of >> config_t's to represent the outlook of the options. > > Sorry, that's simply not possible. They have to be aware of the > structure in which components are connected. I think you misunderstood what i ment. I mean that each individual gui wouldnt have code like: // create widget for option x ... // create widget for option y ... ... Why ? Because i feel that not all developer would bother adding each new optionfor all guis. So this might lead to situation where some options are missing for some guis. So options would at some level before each gui would turn in to struct that contains enough information(text entry, check box, ...) in order to make guis just "render" these options. I also feel that this would be cleaner and end up with less duplicated code for each gui. Sure some options with some guis might "look" better but i think this way shouldbe considered. >> > On the other hand, since it might be useful sometimes (windowed >> > playback under X only) you could make a curses interface, and then >> > add a terminal-emulator to MPlayer. :))) So MPlayer could run its >> > curses gui inside its own terminal emulator which displays overlaid >> > onto the movie... ;) >> Hehe. >> Yah, im not sure how curses works but as far as i can remember it only >> allows users to set chars at x, y location on screen. So this >> "show-on-screen"-functioncould just as well be function pointer that >> can be switched when using different UIs. > > That's not what I mean. I said an actual terminal emulator in MPlayer. So users could cd from place to place and use mplayer to play files ? Like xmms does ? Sounds good to me. I however think that this should be optional since this would cause compatibility problems with windows and possibly other os'es with no terminal emulation. So why not have both ? :) --Aapo Tahkola From andrej at lucky.net Fri Jan 23 10:13:19 2004 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Fri, 23 Jan 2004 11:13:19 +0200 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040122170911.GC257@brightrain.aerifal.cx> References: <20040121025135.GM257@brightrain.aerifal.cx> <32849.62.78.120.140.1074737616.squirrel@webmail.mbnet.fi> <20040122062822.GW257@brightrain.aerifal.cx> <20040122090345.13b0cb84.attila@kinali.ch> <20040122170911.GC257@brightrain.aerifal.cx> Message-ID: <20040123091319.GA65540@lucky.net> Hi, D Richard Felker III! Sometime (on Thursday, January 22 at 19:05) I've received something... >On Thu, Jan 22, 2004 at 09:03:45AM +0100, Attila Kinali wrote: >> On Thu, 22 Jan 2004 01:28:22 -0500 >> D Richard Felker III wrote: >> > The difficult >> > end is "repairing" filter chains, renegotiating link parameters, etc. >> > to accommodate changing options. >> That's a really good question. Do you have an idea how this can >> be done ? >> Or is it a trivial, call config() on all nodes in the chain ? >Yes, it basically amounts to that, but there are various questions. >For example if there's a filter that can't change parameters without >losing frames (due to internal buffering latency), should you >completely reset this filter and give bad output? Or should you insert >scale on one or both sides of it to hide the format/size changes from >it? I don't know what the best answer is... If you would like to hear my thoughts I'll tell you I prefer third way - any filter that may lose frames with internal buffering must use some API call to scale frame itself. I'm sorry but your way when "API knows about all better than filters" is too similar to Microsoft way of writting applications so I don't like it. And I don't like to drop the frames too. ;) And I also want layers' internals to be as simple as possible - layer have to do nothing but be a glue to its components, and on other hand it have to have some helper functions for components (modules, filters, etc) but nothing more. I don't like layers with AI, any AI seems to be hack. Forgive me if that offends you, please. With best wishes. Andriy. From albeu at free.fr Fri Jan 23 13:16:32 2004 From: albeu at free.fr (Alban Bedel) Date: Fri, 23 Jan 2004 13:16:32 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs References: <20040122170640.GB257@brightrain.aerifal.cx> <32874.62.78.105.77.1074846315.squirrel@webmail.mbnet.fi> Message-ID: <20040123131632.2379fc30.albeu@free.fr> Hi Fre_ax, on Fri, 23 Jan 2004 10:25:15 +0200 (EET) you wrote: > What i mean is that browsing of normal files and playlists could be > implementedwith virtual directories just above each individual gui. > > So each gui wouldnt need to use opendir and stuff directly. I thought about smthg simillar when i wrote an ftp menu for G1 (also lost in this stupid rm accident )): As lazy as i am i wanted some generic menu with the 'media depedent' stuff implemented at the stream level. So the menu could use the stream in a similar way as opendir. However it was painfull in G1. This could be intersting but then some helpers to cache small directory structure (like for cd and dvd) have to be provided imho. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From dalias at aerifal.cx Fri Jan 23 16:23:17 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 23 Jan 2004 10:23:17 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32874.62.78.105.77.1074846315.squirrel@webmail.mbnet.fi> References: <20040122170640.GB257@brightrain.aerifal.cx> <32874.62.78.105.77.1074846315.squirrel@webmail.mbnet.fi> Message-ID: <20040123152317.GM257@brightrain.aerifal.cx> On Fri, Jan 23, 2004 at 10:25:15AM +0200, Fre_ax wrote: > >> > For example most players may not care to support multi-file input > >> > streams with filters to merge them, so maybe the playlist shouldn't > >> > either. It seems to me this sort of feature is mainly useful in an > >> > editor/encoder app instead. On the other hand, maybe someone would > >> > find it useful. I don't know the answers to all these questions > >> > right now, so I'm trying to work on the lower-level stuff that > >> > really matters right now so we can defer decisions like this until > >> > after the basic code is in place and working. > >> > >> Agreed. I see creating new channels can be a problem and thats why i > >> think playlists should be allowed to optionally define the > >> representation of this. > > > > Huh? This has nothing to do with what I said. > > I agree that its too early to say without knowing how lower level works. > Got carried away from the subject. ;) Yeah. > In order to add new DVB channels with any of the guis one would need to > definethings like name, frequency, polarity, satellite no, symbol rate, vpid, apid. > > There are plentty of ways to do this IMHO but id say dynamic config would > stepin at some point. > > And no i dont mean just DVB channels but maybe also https user names, > passwords, > ports and maybe other streaming stuff that just cannot be treated as normal > files. Eh? All of these can be treated as normal files in a playlist. They all have urls. IMO this can be done very easily for DVB channels too, and probably should...then some kind of aliasing/playlist system could sit on top for selecting channels. > >> I do think that guis should not be given more than bunch of > >> config_t's to represent the outlook of the options. > > > > Sorry, that's simply not possible. They have to be aware of the > > structure in which components are connected. > > I think you misunderstood what i ment. > > I mean that each individual gui wouldnt have code like: > // create widget for option x > ... > // create widget for option y > ... > ... > Why ? Because i feel that not all developer would bother adding each new > optionfor all guis. So this might lead to situation where some options are missing > for some guis. > > So options would at some level before each gui would turn in to struct that > contains enough information(text entry, check box, ...) in order to make > guis just "render" these options. > > I also feel that this would be cleaner and end up with less duplicated code > for each gui. Arrg RTFmla (mailing list archive). This was discussed about a year ago and already done! > > That's not what I mean. I said an actual terminal emulator in MPlayer. > > So users could cd from place to place and use mplayer to play files ? > Like xmms does ? Sounds good to me. No. Do you know what a terminal emulator is? > I however think that this should be optional since this would cause > compatibility > problems with windows and possibly other os'es with no terminal emulation. Obviously. Rich From fre_ax at mbnet.fi Sat Jan 24 03:26:29 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Sat, 24 Jan 2004 04:26:29 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040123152317.GM257@brightrain.aerifal.cx> References: <20040123152317.GM257@brightrain.aerifal.cx> Message-ID: <32798.62.78.127.69.1074911189.squirrel@webmail.mbnet.fi> >> In order to add new DVB channels with any of the guis one would need >> to definethings like name, frequency, polarity, satellite no, symbol >> rate, vpid, apid. >> There are plentty of ways to do this IMHO but id say dynamic config >> would stepin at some point. >> >> And no i dont mean just DVB channels but maybe also https user names, >> passwords, >> ports and maybe other streaming stuff that just cannot be treated as >> normal files. > > Eh? All of these can be treated as normal files in a playlist. They > all have urls. IMO this can be done very easily for DVB channels too, > and probably should...then some kind of aliasing/playlist system could > sit on top for selecting channels. Hmm. Yeah it should be suitable IMHO. I think DVB playlists wouldnt even need real playlists as saving this "playlist"should get done at demuxer level where reading channels.conf currently takes place. Implementing opendir, readdir, closedir, mkdir, rmdir ... for urls might just do it. Or is it done already ? :)< This should however implemented in a way that ordering of channels in this playlist/directory doesnt get mixed up when adding new channels. With linked lists maybe ? readdir i mean. >> >> I do think that guis should not be given more than bunch of >> >> config_t's to represent the outlook of the options. >> > >> > Sorry, that's simply not possible. They have to be aware of the >> > structure in which components are connected. >> >> I think you misunderstood what i ment. >> >> I mean that each individual gui wouldnt have code like: >> // create widget for option x >> ... >> // create widget for option y >> ... >> ... >> Why ? Because i feel that not all developer would bother adding each >> new optionfor all guis. So this might lead to situation where some >> options are missing for some guis. >> >> So options would at some level before each gui would turn in to struct >> that contains enough information(text entry, check box, ...) in order >> to make guis just "render" these options. >> >> I also feel that this would be cleaner and end up with less duplicated >> code for each gui. > > Arrg RTFmla (mailing list archive). This was discussed about a year > ago and already done! Good, good. :D >> > That's not what I mean. I said an actual terminal emulator in >> > MPlayer. >> >> So users could cd from place to place and use mplayer to play files ? >> Like xmms does ? Sounds good to me. > > No. Do you know what a terminal emulator is? I believe terminal emulation is done by connecting to /dev/"something" and thenwriting everything that user types there and displaying everything that comes out of there, right ? No i dont know how far you can go with this and what things could be done withterminal emulation. With some IPC stuff one could even use dymanic config with command line interface. Or what you had in mind ? What about auto completion for not so GUI-like UIs ? If there is readdir for urls this could be done for some UIs. With some IPC stuff in mplayer controlling mplayer via remote login would also possible. :) So i think using multiple GUIs or UIs at the same time should be possible at least without running in to implementational issues if someone wants to implement stuff like that. --Aapo Tahkola From dalias at aerifal.cx Sat Jan 24 05:42:45 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 23 Jan 2004 23:42:45 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32798.62.78.127.69.1074911189.squirrel@webmail.mbnet.fi> References: <20040123152317.GM257@brightrain.aerifal.cx> <32798.62.78.127.69.1074911189.squirrel@webmail.mbnet.fi> Message-ID: <20040124044245.GU257@brightrain.aerifal.cx> On Sat, Jan 24, 2004 at 04:26:29AM +0200, Fre_ax wrote: > >> In order to add new DVB channels with any of the guis one would need > >> to definethings like name, frequency, polarity, satellite no, symbol > >> rate, vpid, apid. > >> There are plentty of ways to do this IMHO but id say dynamic config > >> would stepin at some point. > >> > >> And no i dont mean just DVB channels but maybe also https user names, > >> passwords, > >> ports and maybe other streaming stuff that just cannot be treated as > >> normal files. > > > > Eh? All of these can be treated as normal files in a playlist. They > > all have urls. IMO this can be done very easily for DVB channels too, > > and probably should...then some kind of aliasing/playlist system could > > sit on top for selecting channels. > > Hmm. Yeah it should be suitable IMHO. > I think DVB playlists wouldnt even need real playlists as saving this > "playlist"should get done at demuxer level where reading channels.conf currently takes > place. IMO a demuxer should not read config files itself. This is very bad practice. Instead the DVB playlist code belongs at the playlist level, in the player. The demuxer should just accept freq/etc. parameters from the player. > Implementing opendir, readdir, closedir, mkdir, rmdir ... for urls might just > do it. Or is it done already ? :)< Huh? It's not needed. Sometimes a url gives you a playlist (e.g. asx streams) in which case that gets loaded by the playlist loader and then played. DVB could do the same if it has a way of reading channel info from the signal; I have no idea since I've never seen/used DVB. Rich From fre_ax at mbnet.fi Sat Jan 24 08:40:28 2004 From: fre_ax at mbnet.fi (Fre_ax) Date: Sat, 24 Jan 2004 09:40:28 +0200 (EET) Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <20040124044245.GU257@brightrain.aerifal.cx> References: <20040124044245.GU257@brightrain.aerifal.cx> Message-ID: <32915.62.78.127.69.1074930028.squirrel@webmail.mbnet.fi> >> >> In order to add new DVB channels with any of the guis one would >> >> need to definethings like name, frequency, polarity, satellite no, >> >> symbol rate, vpid, apid. >> >> There are plentty of ways to do this IMHO but id say dynamic >> >> config would stepin at some point. >> >> >> >> And no i dont mean just DVB channels but maybe also https user >> >> names, passwords, >> >> ports and maybe other streaming stuff that just cannot be treated >> >> as normal files. >> > >> > Eh? All of these can be treated as normal files in a playlist. They >> > all have urls. IMO this can be done very easily for DVB channels >> > too, and probably should...then some kind of aliasing/playlist >> > system could sit on top for selecting channels. >> >> Hmm. Yeah it should be suitable IMHO. >> I think DVB playlists wouldnt even need real playlists as saving this >> "playlist"should get done at demuxer level where reading channels.conf >> currently takes place. > > IMO a demuxer should not read config files itself. This is very bad > practice. channels.conf syntax is already pretty widely known and used so it doesnt fallinto configuration class IMHO. Its filled with stuff like this: ... Das Erste:11837:h:0:27500:101:102 ZDF:11954:h:0:27500:110:120 ... Well i dont care who reads it but both traditional DVB:// playing and GUI playlist playing need to use same code to avoid duplicated code. > Instead the DVB playlist code belongs at the playlist level, > in the player. I agree. Player as in GUI or UI player or both ? Because if there will be playlists in low level, problem solved. > The demuxer should just accept freq/etc. parameters > from the player. Yes, but that DVB:// is still there. ;) Or would it be possible to move libmpdemux/dvb* to somewhere else without breaking url playing of DVB channels ? Or if playlists get to be implemented for command line also... >> Implementing opendir, readdir, closedir, mkdir, rmdir ... for urls >> might just do it. Or is it done already ? :)< > > Huh? It's not needed. Sometimes a url gives you a playlist (e.g. asx > streams) in which case that gets loaded by the playlist loader and > then played. DVB could do the same if it has a way of reading channel > info from the signal; I have no idea since I've never seen/used DVB. No not possible. Even though probing would be possible it would take way too long(we are talkingabout hours here) to probe all channels. Info about channels must come from channels.conf. --Aapo Tahkola From nsabbi at tiscali.it Sat Jan 24 10:22:59 2004 From: nsabbi at tiscali.it (Nico) Date: Sat, 24 Jan 2004 10:22:59 +0100 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <32915.62.78.127.69.1074930028.squirrel@webmail.mbnet.fi> References: <20040124044245.GU257@brightrain.aerifal.cx> <32915.62.78.127.69.1074930028.squirrel@webmail.mbnet.fi> Message-ID: <40123973.6090907@tiscali.it> Fre_ax wrote: >>>>>In order to add new DVB channels with any of the guis one would >>>>>need to definethings like name, frequency, polarity, satellite no, >>>>>symbol rate, vpid, apid. >>>>>There are plentty of ways to do this IMHO but id say dynamic >>>>>config would stepin at some point. >>>>> >>>>>And no i dont mean just DVB channels but maybe also https user >>>>>names, passwords, >>>>>ports and maybe other streaming stuff that just cannot be treated >>>>>as normal files. >>>>> >>>>> >>>>Eh? All of these can be treated as normal files in a playlist. They >>>>all have urls. IMO this can be done very easily for DVB channels >>>>too, and probably should...then some kind of aliasing/playlist >>>>system could sit on top for selecting channels. >>>> >>>> >>>Hmm. Yeah it should be suitable IMHO. >>>I think DVB playlists wouldnt even need real playlists as saving this >>>"playlist"should get done at demuxer level where reading channels.conf >>>currently takes place. >>> >>> >>IMO a demuxer should not read config files itself. This is very bad >>practice. >> >> > >channels.conf syntax is already pretty widely known and used so it doesnt >fallinto configuration class IMHO. > >Its filled with stuff like this: >... >Das Erste:11837:h:0:27500:101:102 >ZDF:11954:h:0:27500:110:120 >... > > channels.conf is read by dvbin.c that works at the stream (not demuxer) level. I agree It's ugly, but at the time I wrote the code there was no way to instruct the config layer to interpret the file (that can have 3 different syntaxes: DVB-T/S/C). >Well i dont care who reads it but both traditional DVB:// >playing and >GUI playlist playing need to use same code to avoid duplicated code. > > > >>Instead the DVB playlist code belongs at the playlist level, >>in the player. >> >> > >I agree. Player as in GUI or UI player or both ? >Because if there will be playlists in low level, problem solved. > > > >>The demuxer should just accept freq/etc. parameters >>from the player. >> >> > >Yes, but that DVB:// is still there. ;) > >Or would it be possible to move libmpdemux/dvb* to somewhere else without >breaking >url playing of DVB channels ? > >Or if playlists get to be implemented for command line also... > > > >>>Implementing opendir, readdir, closedir, mkdir, rmdir ... for urls >>>might just do it. Or is it done already ? :)< >>> >>> >>Huh? It's not needed. Sometimes a url gives you a playlist (e.g. asx >>streams) in which case that gets loaded by the playlist loader and >>then played. DVB could do the same if it has a way of reading channel >>info from the signal; I have no idea since I've never seen/used DVB. >> >> > >No not possible. >Even though probing would be possible it would take way too long(we are >talkingabout hours here) to probe all channels. Info about channels must come from >channels.conf. > >--Aapo Tahkola > > > > I agree: channels should be stored in a file by a scan application. Nico From dalias at aerifal.cx Sat Jan 24 19:47:54 2004 From: dalias at aerifal.cx (D Richard Felker III) Date: Sat, 24 Jan 2004 13:47:54 -0500 Subject: [MPlayer-G2-dev] Re: Data communication between demuxers and UIs In-Reply-To: <40123973.6090907@tiscali.it> References: <20040124044245.GU257@brightrain.aerifal.cx> <32915.62.78.127.69.1074930028.squirrel@webmail.mbnet.fi> <40123973.6090907@tiscali.it> Message-ID: <20040124184754.GZ257@brightrain.aerifal.cx> On Sat, Jan 24, 2004 at 10:22:59AM +0100, Nico wrote: > channels.conf is read by dvbin.c that works at the stream (not demuxer) > level. I agree It's ugly, but > at the time I wrote the code there was no way to instruct the config > layer to interpret the file (that can have > 3 different syntaxes: DVB-T/S/C). I understand this is how it works in G1, but there's no reason G2 should copy the bad design and put lots more crap on top to accommodate it... Rich From alex at fsn.hu Sat Jan 31 22:02:21 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 22:02:21 +0100 Subject: [MPlayer-G2-dev] G2 in CVS Message-ID: <20040131220221.7e69454a@caprice.artificis.hu> Hi, just imported -preview42 into cvs tree called 'g2', check it out! Note: 1, it includes libavcodec (will soon change to g1 behaviour) 2, probably if g2 api-s stabilizes, we'll create a new cvs tree -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) From diego at biurrun.de Sat Jan 31 21:54:57 2004 From: diego at biurrun.de (Diego Biurrun) Date: Sat, 31 Jan 2004 17:54:57 -0300 Subject: [MPlayer-G2-dev] G2 in CVS In-Reply-To: <20040131220221.7e69454a@caprice.artificis.hu> References: <20040131220221.7e69454a@caprice.artificis.hu> Message-ID: <16412.5665.870415.310286@biurrun.de> Alex Beregszaszi writes: > just imported -preview42 into cvs tree called 'g2', check it out! first commit :-P Very cool. I hope and believe this will speed up G2 development. Diego From diego at biurrun.de Sat Jan 31 22:03:58 2004 From: diego at biurrun.de (Diego Biurrun) Date: Sat, 31 Jan 2004 18:03:58 -0300 Subject: [MPlayer-G2-dev] G2 in CVS In-Reply-To: <16412.5665.870415.310286@biurrun.de> References: <20040131220221.7e69454a@caprice.artificis.hu> <16412.5665.870415.310286@biurrun.de> Message-ID: <16412.6206.866527.640591@biurrun.de> Diego Biurrun writes: > Alex Beregszaszi writes: > > just imported -preview42 into cvs tree called 'g2', check it out! > > first commit :-P Awaiting moderator approval. diego at mphq is not subscribed... Diego From alex at fsn.hu Sat Jan 31 22:50:01 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 22:50:01 +0100 Subject: [MPlayer-G2-dev] G2 in CVS In-Reply-To: <16412.6206.866527.640591@biurrun.de> References: <20040131220221.7e69454a@caprice.artificis.hu> <16412.5665.870415.310286@biurrun.de> <16412.6206.866527.640591@biurrun.de> Message-ID: <20040131225001.3384f73e@caprice.artificis.hu> Hi, > > > just imported -preview42 into cvs tree called 'g2', check it > > > out! > > > > first commit :-P > > Awaiting moderator approval. diego at mphq is not subscribed... Yes, under progress :) -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) From diego at mplayerhq.hu Sat Jan 31 21:53:37 2004 From: diego at mplayerhq.hu (Diego Biurrun CVS) Date: Sat, 31 Jan 2004 21:53:37 +0100 (CET) Subject: [MPlayer-G2-dev] CVS: g2/DOCS README,1.1.1.1,1.2 Message-ID: <20040131205337.6B9EA71E@mail.mplayerhq.hu> Update of /cvsroot/mplayer/g2/DOCS In directory mail:/var2/tmp/cvs-serv27225 Modified Files: README Log Message: grammar/spelling/wording Index: README =================================================================== RCS file: /cvsroot/mplayer/g2/DOCS/README,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- README 31 Jan 2004 20:16:18 -0000 1.1.1.1 +++ README 31 Jan 2004 20:53:34 -0000 1.2 @@ -8,28 +8,26 @@ It is designed to be reentrant, so adding thread-safety is easy (just a few locks around the demuxer layer entry calls). -NOTE: It's in early stage of development, don't compare to the 0.90 feature set. -The goal is not (yet) to create an all-in-one player, but a clean framework -for experimenting with new ideas and solutions for already known problems. +NOTE: It's in an early stage of development, don't compare it to the 0.90 +feature set. The goal is not (yet) to create a complete player, but a clean +framework for experimenting with new ideas and solutions for known problems. A long-term goal is creating a media processing library, to be usable as the backend of media/movie players, converters, editors, capture tools. Some of the major differences to 0.90: -- video codecs pull the data from the demuxer, instead of the old push-method. -- video filtering path is driven from the other end: vo, so filters can +- Video codecs pull the data from the demuxer, instead of the old push-method. +- The video filtering path is driven from the other end: vo, so filters can insert new frames without going up to the codecs. -- video codecs and filters may modify the timing info (PTS/duration) of frames +- Video codecs and filters may modify the timing info (PTS/duration) of frames. - libvo2 has been redesigned, now vo drivers do the minimal thing only: - controls the actual device and export its buffers to the vo core (vf_vo2.c) + control the actual device and export its buffers to the vo core (vf_vo2.c) All the rest (like draw_slice() implementation, OSD rendering, buffer - management is handled by the core, not the driver itself). -- audio and video codecs/filters/path has been separated -- the stream and demuxer code have been modularized, instead of switch-case mess -- demuxers now handle more than one audio and video stream at the same time, + management) is handled by the core, not the driver itself. +- Audio and video codecs/filters/path have been separated. +- Stream and demuxer code has been modularized, instead of switch-case mess. +- Demuxers now handle more than one audio and video stream at the same time, so runtime stream switching or playback/conversion of multiple audio/video tracks at the same time is now possible. -- stream-less demuxers are not hacks any longer, they are legal using the DUMMY +- Stream-less demuxers are not hacks any longer, they are legal using the DUMMY stream type, auto-created based on URL. - - From syncmail at mplayerhq.hu Sat Jan 31 22:54:42 2004 From: syncmail at mplayerhq.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 22:54:42 +0100 (CET) Subject: [MPlayer-G2-dev] g2/confiG2ure configure.log,1.1.1.1,NONE Message-ID: <20040131215442.0BB714CF@mail.mplayerhq.hu> Update of /cvsroot/mplayer/g2/confiG2ure In directory mail:/home/alex/a/g2/confiG2ure Removed Files: configure.log Log Message: test syncmail-g2 CVS change done by Alex Beregszaszi --- configure.log DELETED --- From syncmail at mplayerhq.hu Sat Jan 31 22:57:59 2004 From: syncmail at mplayerhq.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 22:57:59 +0100 (CET) Subject: [MPlayer-G2-dev] g2/confiG2ure target,1.1.1.1,1.2 Message-ID: <20040131215759.B2FDF9A9@mail.mplayerhq.hu> CVS change done by Alex Beregszaszi Update of /cvsroot/mplayer/g2/confiG2ure In directory mail:/home/alex/a/g2/confiG2ure Modified Files: target Log Message: better parisc detection Index: target =================================================================== RCS file: /cvsroot/mplayer/g2/confiG2ure/target,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- target 31 Jan 2004 20:16:18 -0000 1.1.1.1 +++ target 31 Jan 2004 21:57:57 -0000 1.2 @@ -50,7 +50,7 @@ ppc) host_arch=ppc ;; alpha) host_arch=alpha ;; sparc*) host_arch=sparc ;; - 9000*) host_arch=hppa ;; + hppa*|9000*|parisc*) host_arch=hppa ;; arm*) host_arch=arm ;; s390) host_arch=s390 ;; s390x) host_arch=s390x ;; From alex at fsn.hu Sat Jan 31 23:45:03 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 23:45:03 +0100 Subject: [MPlayer-G2-dev] G2 in CVS In-Reply-To: <16412.6206.866527.640591@biurrun.de> References: <20040131220221.7e69454a@caprice.artificis.hu> <16412.5665.870415.310286@biurrun.de> <16412.6206.866527.640591@biurrun.de> Message-ID: <20040131234503.0f5e260d@caprice.artificis.hu> Hi, > Awaiting moderator approval. diego at mphq is not subscribed... Just finished syncmail-g2 script :) Improvements: 1, sender is now syncmail at mplayerhq so we can finally change -cvslog to members only :) 2, it doesn't truncates the diffs -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) From alex at fsn.hu Sat Jan 31 23:59:33 2004 From: alex at fsn.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 23:59:33 +0100 Subject: [MPlayer-G2-dev] Codec identifier (fourcc) handling proposal Message-ID: <20040131235933.7719c1f4@caprice.artificis.hu> Hi, There's a need for defining the way we're handling codec identifiers, in G1 this wasn't such a big issue, as MEncoder could only handle AVI well. 1, input layer - demuxer 2, core 3, output layer - muxer Imho in core we should deal with fourcc's (four character codes) only, both for audio and video. Maybe we should define better names for audio codecs. You know that AVI uses twocc for audio, but others (real, qt) uses fourcc for that too and nut is going to handle this situation well. The input layer should wrap the known identifiers to fourccs known by the core. The output layer should wrap the fourccs to the formats identifires. What do you think? -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) From arpi at thot.banki.hu Sat Jan 31 23:21:38 2004 From: arpi at thot.banki.hu (Arpi) Date: Sat, 31 Jan 2004 23:21:38 +0100 (CET) Subject: [MPlayer-G2-dev] Codec identifier (fourcc) handling proposal In-Reply-To: <20040131235933.7719c1f4@caprice.artificis.hu> Message-ID: <20040131222138.F3E72934@mail.mplayerhq.hu> Hi, > There's a need for defining the way we're handling codec identifiers, in > G1 this wasn't such a big issue, as MEncoder could only handle AVI well. > > 1, input layer - demuxer > 2, core > 3, output layer - muxer > > Imho in core we should deal with fourcc's (four character codes) only, > both for audio and video. Maybe we should define better names for audio > codecs. You know that AVI uses twocc for audio, but others (real, qt) > uses fourcc for that too and nut is going to handle this situation well. > > The input layer should wrap the known identifiers to fourccs known by > the core. the second parameter to fourcc/format 'commands' of codecs.conf is for this maybe we should merge fourcc and format, to fourcc, and stuff in ' ' or " " would be always fourcc ("1234"), numbers (0x1234 or 1234) are formats, and the rest is fourcc too. this could be done for g1 too. > The output layer should wrap the fourccs to the formats identifires. > > What do you think? agree A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From syncmail at mplayerhq.hu Sat Jan 31 23:27:14 2004 From: syncmail at mplayerhq.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 23:27:14 +0100 (CET) Subject: [MPlayer-G2-dev] CVS: g2/demux demux_ogg.c,1.1.1.1,1.2 Message-ID: <20040131222714.35EF48DD@mail.mplayerhq.hu> CVS change done by Alex Beregszaszi Update of /cvsroot/mplayer/g2/demux In directory mail:/var2/tmp/cvs-serv28713 Modified Files: demux_ogg.c Log Message: flac support Index: demux_ogg.c =================================================================== RCS file: /cvsroot/mplayer/g2/demux/demux_ogg.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- demux_ogg.c 31 Jan 2004 20:16:18 -0000 1.1.1.1 +++ demux_ogg.c 31 Jan 2004 22:27:11 -0000 1.2 @@ -66,6 +66,7 @@ #define OGGS_FORMAT_THEORA 2 #define OGGS_FORMAT_DSHOW_OLD 3 #define OGGS_FORMAT_DSHOW_NEW 4 +#define OGGS_FORMAT_FLAC 5 // return value: 1 = packet should be queued 0 = packet should be dropped static int ogg_parse_header(demux_stream_t* ds, unsigned char* buffer, int len){ @@ -90,6 +91,14 @@ ds->format=mmioFOURCC('T','h','r','a'); return 0; } + /* first ogg packet contains ONLY the fLaC signature */ + if(len>=4 && !strncmp(&buffer[0],"fLaC", 4)){ + mp_msg(MSGT_DEMUX,MSGL_INFO,"demux_ogg: stream #%d: FLAC audio\n",ds->id); + ds->type=DEMUX_STREAM_TYPE_AUDIO; ds->priv->format=OGGS_FORMAT_FLAC; +// ds->format=0x43614c66; + ds->format=mmioFOURCC('f','L','a','C'); + return 1; + } if(len>=142 && !strncmp(&buffer[1],"Direct Show Samples embedded in Ogg",35)){ ds->priv->format=OGGS_FORMAT_DSHOW_OLD; switch(*((uint32_t*)(buffer+96))){ @@ -337,7 +346,7 @@ NULL, // url "ogg", "Xiph.org OGG Stream (OggS) format", - "A'rpi", + "A'rpi, Alex", ext_list, driver_open }; From syncmail at mplayerhq.hu Sat Jan 31 23:29:21 2004 From: syncmail at mplayerhq.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 23:29:21 +0100 (CET) Subject: [MPlayer-G2-dev] CVS: g2/demux demux_avi.c,1.1.1.1,1.2 Message-ID: <20040131222921.A5A008DD@mail.mplayerhq.hu> CVS change done by Alex Beregszaszi Update of /cvsroot/mplayer/g2/demux In directory mail:/var2/tmp/cvs-serv27442 Modified Files: demux_avi.c Log Message: support for obscure on2 avi Index: demux_avi.c =================================================================== RCS file: /cvsroot/mplayer/g2/demux/demux_avi.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- demux_avi.c 31 Jan 2004 20:16:18 -0000 1.1.1.1 +++ demux_avi.c 31 Jan 2004 22:29:18 -0000 1.2 @@ -178,17 +178,23 @@ demux_stream_t* ds=NULL; int stream_id=0; int id; + int on2_hack = 0; if(level!=DEMUX_CHECK_LEVEL_FORCE && level!=DEMUX_CHECK_LEVEL_SHORT) return -1; // given detection level not supported //---- check RIFF header: id=stream_read_dword_le(demuxer->stream); // "RIFF" - if(id!=FOURCC_RIFF) return 0; // not a RIFF file + if(id==mmioFOURCC('O','N','2',' ')) on2_hack = 1; + else if(id!=FOURCC_RIFF) return 0; // not a RIFF file stream_read_dword_le(demuxer->stream); // ignore filesize id=stream_read_dword_le(demuxer->stream); // "AVI " - if(id!=formtypeAVI) return 0; // not an AVI file + if(on2_hack && id!=mmioFOURCC('O','N','2','f')) return 0; + else if(!on2_hack && id!=formtypeAVI) return 0; // not an AVI file + + if (on2_hack) + mp_msg(MSGT_HEADER,MSGL_V,"Obscure ON2 AVI detected\n"); demuxer->priv=calloc(sizeof(struct demuxer_priv_s),1); @@ -304,6 +310,7 @@ // case mmioFOURCC('I','S','M','P'): hdr="Time Code";break; // case mmioFOURCC('I','D','I','T'): hdr="Digitization Time";break; + case mmioFOURCC('O','N','2','h'): case ckidAVIMAINHDR: // read 'avih' stream_read(demuxer->stream,(char*) &demuxer->priv->avih,MIN(size2,sizeof(demuxer->priv->avih))); le2me_MainAVIHeader(&demuxer->priv->avih); // swap to machine endian @@ -465,7 +472,7 @@ NULL, // url "avi", "RIFF AVI (Audio-Video Interleaved)", - "A'rpi", + "A'rpi, Alex", ext_list, driver_open }; From syncmail at mplayerhq.hu Sat Jan 31 23:31:28 2004 From: syncmail at mplayerhq.hu (Alex Beregszaszi) Date: Sat, 31 Jan 2004 23:31:28 +0100 (CET) Subject: [MPlayer-G2-dev] CVS: g2/demux demux_nut.c,1.1.1.1,1.2 Message-ID: <20040131223128.C899A8E6@mail.mplayerhq.hu> CVS change done by Alex Beregszaszi Update of /cvsroot/mplayer/g2/demux In directory mail:/var2/tmp/cvs-serv19875 Modified Files: demux_nut.c Log Message: support for timestamp shift Index: demux_nut.c =================================================================== RCS file: /cvsroot/mplayer/g2/demux/demux_nut.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- demux_nut.c 31 Jan 2004 20:16:18 -0000 1.1.1.1 +++ demux_nut.c 31 Jan 2004 22:31:25 -0000 1.2 @@ -1,5 +1,5 @@ /* - * "NUT" Container Format demuxer (DRAFT-20031003) + * "NUT" Container Format demuxer (DRAFT-20031102) * Copyright (C) 2002 Alex Beregszaszi * * This library is free software; you can redistribute it and/or modify @@ -48,7 +48,8 @@ int last_frame_size; demux_stream_t* audio; demux_stream_t* video; - int msb_timestamp_shift; + int msb_timestamp_shift[256]; // FIXME!! + int64_t last_msb_timestamp[256]; // FIXME!! }; #define MAIN_STARTCODE (0xF9526A6200000000ULL + ('N'<<24) + ('U'<<16) + ('T'<<8) + 'M') @@ -115,7 +116,7 @@ data[i] = stream_read_char(s); stream_skip(s, len-i); - return 0; + return len; } static int get_packetheader(demuxer_t *demuxer) @@ -191,8 +192,7 @@ static int driver_fill(demuxer_t *demuxer, demux_stream_t* ds){ struct demuxer_priv_s *priv = demuxer->priv; int key_frame = 0, id, len, flags; - uint64_t ptype; - int64_t pts = 0; + uint64_t ptype, pts = 0; start: demuxer->filepos = stream_tell(demuxer->stream); @@ -209,7 +209,8 @@ get_packetheader(demuxer); do { char data[32]; - int hdr = 0; + int hdr = 0, len; + i = get_v(demuxer->stream); switch(i) { @@ -220,11 +221,12 @@ case 9: hdr = DEMUX_META_STRING_SOFTWARE; break; default: } - get_b(demuxer->stream, &data, 32); + len = get_b(demuxer->stream, &data, 32); + data[len-1] = 0; if (hdr) demux_metadata_add(&demuxer->meta, hdr, data, -1, 1); } while ((i != 0) && !stream_eof(demuxer->stream)); - stream_skip(demuxer->stream, 4); + stream_skip(demuxer->stream, 4); /* checksum */ goto start; } if ((ptype != KEYFRAME_STARTCODE) && (ptype != 0)) @@ -248,11 +250,18 @@ get_packetheader(demuxer); id = get_v(demuxer->stream); if ((flags & 0x8) >> 3) /* msb timestamp */ - pts = get_v(demuxer->stream) << priv->msb_timestamp_shift; - pts |= get_s(demuxer->stream); + priv->last_msb_timestamp[id] = get_v(demuxer->stream) << priv->msb_timestamp_shift[id]; +#ifdef DEBUG + printf("timestamp last msb: %llx shift: %d\n", + priv->last_msb_timestamp[id], priv->msb_timestamp_shift[id]); +#endif +// pts = priv->last_msb_timestamp[id] + get_v(demuxer->stream); + pts = get_v(demuxer->stream); +// printf("pts: %x\n", pts); + pts += priv->last_msb_timestamp[id]; len = priv->curr_frame_size - (stream_tell(demuxer->stream) - priv->curr_frame_start); #ifdef DEBUG - printf("%srame flags: %d, id: %d, len: %d, pts: %lld\n", + printf("%srame flags: %d, id: %d, len: %d, pts: %x\n", (key_frame) ? "Keyf" : "F", flags, id, len, pts); #endif @@ -264,7 +273,9 @@ else if (len && !stream_eof(demuxer->stream)) { if (ds && !ds->ignore) - ds_read_packet(ds, demuxer->stream, len, pts, demuxer->filepos, key_frame?1:0); + { + ds_read_packet(ds, demuxer->stream, len, (int)pts, demuxer->filepos, (key_frame?1:0)); + } else stream_skip(demuxer->stream, len); } @@ -284,7 +295,7 @@ if (search_packet(demuxer->stream, 8192, MAIN_STARTCODE) < 0) { - printf("Couldn't find main header!\n"); +// printf("Couldn't find main header!\n"); return 0; } @@ -325,7 +336,7 @@ rate = get_v(demuxer->stream); rate_base = get_v(demuxer->stream); printf("rate: (m) %d, base: (d) %d\n", rate, rate_base); - demuxer->priv->msb_timestamp_shift = get_v(demuxer->stream); + demuxer->priv->msb_timestamp_shift[id] = get_v(demuxer->stream); get_v(demuxer->stream); /* shuffle type */ stream_skip(demuxer->stream, 1); /* flags */