From ardneh2 at hotmail.com Fri Aug 1 11:58:14 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Fri, 01 Aug 2003 09:58:14 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: I'm interested in writing a GTK2 GUI for mplayer-G2. Tell me how I can help. -Charles _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From ajh at watri.org.au Fri Aug 1 12:36:03 2003 From: ajh at watri.org.au (Anders Johansson) Date: Fri, 1 Aug 2003 18:36:03 +0800 Subject: [MPlayer-G2-dev] libaf Message-ID: <20030801103603.GB919@watri.org.au> Hi, I will try to convert libaf to the new general config system this weekend. Is there anything else you want me to change in the audio filter layer while I am at it? How is it going with the inclusion of my chages to libao? //Anders From arpi at thot.banki.hu Fri Aug 1 18:27:29 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 1 Aug 2003 18:27:29 +0200 Subject: [MPlayer-G2-dev] libaf In-Reply-To: <20030801103603.GB919@watri.org.au> Message-ID: <200308011627.h71GRTpH026150@mail.mplayerhq.hu> Hi, > I will try to convert libaf to the new general config system this > weekend. Is there anything else you want me to change in the audio > filter layer while I am at it? yes, rewrite from scratch :))) ok just joke. but i would like a stream/fifo like implementation instead of this current packet i/o style. the packet stuff would be ok, if you could accurately predict (calculate) in/out packet sizes, but i see it's not possible for many filters. what i really want to see in libaf, is very similar to vf layer: the bottom end (ao) requiest N samples (or bytes), from the af layer. then the last af filter is called to produce N samples. This filter then calculates that it needs M samples to be able to produce exactly N samples. then it calls the previous filter in line, to produce M samples and so on, up to the codec. actually the current libaf is similar, but it in first pass tries to estimate the required number of samples from codec (by multiplying constant sample in/out ratio of each filter), then ask codec to produce such amount of samples, then route this packet through all filters down to ao. it results inaccurate buffering (buffers are dinamically resized to fit the data size, and filters sometimes overflow the buffers, by producing more samples than predicted before). and as result, it almost never match the wanted number of samples at ao. > How is it going with the inclusion of my chages to libao? slowly. just before the last release i readed your patch (after creating patch from your double-packed patched version - next time please send patches) but i have too much things i don't like as-is. Mostly by API and parameter/naming style, so it's easier to fix myself than explain and get you fix. I want a similar API to libvo (and other libs). I'll do it, but nowdays i was busy with other stuff. (like the new Timer api, porters (macosx, win32 etc) get ready for a big timer update, you'll have to write new timer drivers for your arch!) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri Aug 1 18:51:28 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 1 Aug 2003 18:51:28 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <200308011651.h71GpSTv030001@mail.mplayerhq.hu> Hi, > I'm interested in writing a GTK2 GUI for mplayer-G2. Tell me how I can > help. > > -Charles As a start, d/l the last G2 snapshot. Actually I need some help to finalize the core libs <-> GUI interface. As you probably noticed, in G1 the GUI was a mess, with #ifdef'ed if(Gui) hooks everywhere in the source, even in the low-level drivers. The G2 'design' is about complete separation of core libraries from the UI code (be it commandline or Gui or browser plugin or whatever). As the playback core (which controls codec selection, A-V syncro, connection of decodres, filters and output devices) is under design/development. In G2, teh new config layer (see cfg.h) exports some usefull info, like the short name/description of options, and a more controlled, limited set of values (like using drop-down lists, min/max limited numbers etc, can be mapped to Gui's combo boxes, bars etc). I think, a runtime 'window builder' should be developed, which gets a module_info_t* as parameter and produces a window with controls of the module's (and its submodules if exists) options. This code then could be used to generate the control window for filters, codecs, output drivers etc. (all kinds of plugins/modules in libs) Yes, I know it's a big work. It has lots of advantages (the core, libraries are (G)UI independent, they export as many info about the controllable options as they can, in a well-defined simple struct. the plugin coders don't have to know Gui programming, and can use any (g)ui (be it gtk, qt, win32, aqua, osd menu or anything) immediatelly to control it. also it have to be written only once, and every new code can use it without the needs to extending gui), but it has some disadvantages too, especially may look worse, than a well-designed control window (although we could extend the config struct with gui-helper data, like position inside the window or grouping of options, if really required). About the video window: In G1, it was a big ugly mesys hack: i nteh Gui mode, the gui did control all the window management, instead of the vo drivers. It meant that gui receives events from X, processes them and then resizes, moves etc the actual vo window by X calls with that window's ID. There were several hacks to get it work. And it resulted many duplicated/redundant code, around X functions (liek xinerama, fullscreen switching etc, mostly all teh window management stuff) To workaround this problem, I took Xine's idea: let the (G)UI control all the windows, and vo (video-out, see libvo2/) drivers only do the minimal thing: allocating and configuring drawable surfaces. To help non-GUI UIs, i've added fallback code in x11_util.c, which is used for x11 drivers when no GUI to do that job. For a GUI it should not be used. (there are 2 callback functions in vo struct: event_callback and get_events, see libvo2.txt for details on them) So, what a GUI should do (imho): - handle file selection (open) and playlists (or even better: playtrees, i mean some playlist formats (including reference .mov files etc) support tree of files, and multiple (different bitrate, language etc) alternatives os same contents. it would be nice if the gui could display this and let the user to select from such tree. (note the metadata export from stream layer is not yet coded, it's required to export cdda/cddb tracklists, dvd title/chapter structure etc) - be able to generate plugin/module config windows on-the-fly (see above) - do window management for video window too, including fullscreen switching, setting title, always-on-top and such attributes... you should knoe better. (it can be done in x11-util.c too, but i was told that in gui 'mode' it must be done by the gui, to be able to swap gui and video windows overlapping or so.) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri Aug 1 20:11:25 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 1 Aug 2003 20:11:25 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer Message-ID: <200308011811.h71IBPBi013496@mail.mplayerhq.hu> Hi, I have a problem. (who has no problems? :)) Currently the PTS info (absolute and relative timestamp, duration time) is stored in the mpi (mp_image_t) structure while going through the video filter layer. It's nice, and makes it's easy to handle frame delaying, reordering. But what happens at skipped/dropped frames? PTS info also gets dropped, so we end up guessing skipped time at the a-v sync core. The issue is already visible when playing that 405*.avi sample from mphq ftp. (it begins with around 4 seconds of zero (black, dropped) frames) I have 2 ideas to solve this, none of them is nice ;( method 1: always return an mpi, never return NULL (except for errors, maybe). also introduce a new mpi type, called NULL or ZERO. it means it only holds 'the place of picture', ie. timestamp and frame counter, but no actual image data. method 2: create a pts_info structure, and use it to hold PTS info through filters. it needs filter API changes, and i have no nice idea how to store/pass this data. (teh function return values is mpi or NULL, so it could be an offset-type parameter like process_image(mpi,&ptsinfo) maybe, but it makes frame delaying/reordering (including attaching ptsinfto to mpi frames) tricky) any better ideas? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Fri Aug 1 20:29:34 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 1 Aug 2003 14:29:34 -0400 Subject: [MPlayer-G2-dev] libaf In-Reply-To: <20030801103603.GB919@watri.org.au> References: <20030801103603.GB919@watri.org.au> Message-ID: <20030801182933.GF220@brightrain.aerifal.cx> On Fri, Aug 01, 2003 at 06:36:03PM +0800, Anders Johansson wrote: > Hi, > > I will try to convert libaf to the new general config system this > weekend. Is there anything else you want me to change in the audio > filter layer while I am at it? I was going to respond, but I think Arpi already said everything I was going to, and a lot more. Rich From dalias at aerifal.cx Fri Aug 1 20:41:49 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 1 Aug 2003 14:41:49 -0400 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308011811.h71IBPBi013496@mail.mplayerhq.hu> References: <200308011811.h71IBPBi013496@mail.mplayerhq.hu> Message-ID: <20030801184149.GG220@brightrain.aerifal.cx> On Fri, Aug 01, 2003 at 08:11:25PM +0200, Arpi wrote: > Hi, > > I have a problem. (who has no problems? :)) > > Currently the PTS info (absolute and relative timestamp, duration time) > is stored in the mpi (mp_image_t) structure while going through the > video filter layer. It's nice, and makes it's easy to handle frame delaying, > reordering. But what happens at skipped/dropped frames? PTS info also gets > dropped, so we end up guessing skipped time at the a-v sync core. > The issue is already visible when playing that 405*.avi sample from mphq ftp. > (it begins with around 4 seconds of zero (black, dropped) frames) > > I have 2 ideas to solve this, none of them is nice ;( > method 1: > always return an mpi, never return NULL (except for errors, maybe). > also introduce a new mpi type, called NULL or ZERO. > it means it only holds 'the place of picture', ie. timestamp and frame > counter, but no actual image data. > method 2: > create a pts_info structure, and use it to hold PTS info through filters. > it needs filter API changes, and i have no nice idea how to store/pass > this data. (teh function return values is mpi or NULL, so it could be > an offset-type parameter like process_image(mpi,&ptsinfo) maybe, but > it makes frame delaying/reordering (including attaching ptsinfto to > mpi frames) tricky) > > any better ideas? IMO it should be much simpler than this. If the frames are being dropped at the codec/demuxer end (because of 0-byte skipped frames in .avi container and such, or nonrecoverable decoding errors or whatever) then the codec/demuxer layer or the wrapper between codec and vf layer should just adjust the relative_pts of the next frame it sends out to account for any dropped frames in between. [Hmm, this is another reason why relative_pts is much better than duration, since you can't lengthen the duration of the previous frame before knowing there'll be dropped frames after it. On the other hand, if you have both duration and relative_pts, which may be inconsistent when frames are dropped, that could be helpful, since it would let filters know both the original *intended* duration of a frame, and how long it actually has to stay on the screen before the next frame is shown, due to drops.] On the other hand, if the frames are being dropped by a filter, it seems to me that the filter should be responsible for pts accounting. This is already the case for filters like inverse telecine that don't actually 'drop' frames, but which have a non-1-to-1 correspondence between input and output frames, so it seems like it'd be ok for other filters (dint, decimate, etc.) which drop frames to do the same. BTW, I was thinking that (non-hard) framedrop for slow cpu and for output to fixed-fps container (for encoding) or vo should be an actual filter, rather than just part of the player/encoder loop. Then the user could insert it at an arbitrary position in the chain -- certainly after inverse telecine or temporal noise filters, but before expensive swscaler, etc. Rich From arpi at thot.banki.hu Fri Aug 1 20:53:23 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 1 Aug 2003 20:53:23 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <20030801184149.GG220@brightrain.aerifal.cx> Message-ID: <200308011853.h71IrNZ7019306@mail.mplayerhq.hu> Hi, > > any better ideas? > > IMO it should be much simpler than this. If the frames are being > dropped at the codec/demuxer end (because of 0-byte skipped frames in > .avi container and such, or nonrecoverable decoding errors or > whatever) then the codec/demuxer layer or the wrapper between codec > and vf layer should just adjust the relative_pts of the next frame it > sends out to account for any dropped frames in between. > On the other hand, if the frames are being dropped by a filter, it > seems to me that the filter should be responsible for pts accounting. > This is already the case for filters like inverse telecine that don't > actually 'drop' frames, but which have a non-1-to-1 correspondence > between input and output frames, so it seems like it'd be ok for other > filters (dint, decimate, etc.) which drop frames to do the same. you're right, as usual :) i'll go for this. (did you notice that in last release relative_pts is also in the struct?:)) > BTW, I was thinking that (non-hard) framedrop for slow cpu and for > output to fixed-fps container (for encoding) or vo should be an actual > filter, rather than just part of the player/encoder loop. Then the > user could insert it at an arbitrary position in the chain -- > certainly after inverse telecine or temporal noise filters, but before > expensive swscaler, etc. fixed-fps output is clean to be implemented as a filter. (maybe autoinserted for fixed-fps formats encoding) (btw we could develop filter which can interpolate images at fps upsampling, maybe by reusing some MC info exported by codec... :)) but for slow-cpu (and also slow-vga) type framedrop i think it's more than a filter. actually it's a drop signal to the codec to do decoding as fast as possible (ie. skip B frames, postprocessing etc) and skip all teh filtering and display. The special case of temporal filters is already hdnaled in the vf_process_image(), ie. drop 'signal' is not delivered above the last filter needing all frames. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri Aug 1 22:50:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 1 Aug 2003 22:50:20 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308011853.h71IrNZ7019306@mail.mplayerhq.hu> Message-ID: <200308012050.h71KoKUN007632@mail.mplayerhq.hu> Hi, > > > any better ideas? > > > > IMO it should be much simpler than this. If the frames are being > > dropped at the codec/demuxer end (because of 0-byte skipped frames in > > .avi container and such, or nonrecoverable decoding errors or > > whatever) then the codec/demuxer layer or the wrapper between codec > > and vf layer should just adjust the relative_pts of the next frame it > > sends out to account for any dropped frames in between. > > > On the other hand, if the frames are being dropped by a filter, it > > seems to me that the filter should be responsible for pts accounting. > > This is already the case for filters like inverse telecine that don't > > actually 'drop' frames, but which have a non-1-to-1 correspondence > > between input and output frames, so it seems like it'd be ok for other > > filters (dint, decimate, etc.) which drop frames to do the same. > > you're right, as usual :) > i'll go for this. I felt there will be some problems you didn't think of... For a start, there are cases, when only the codec can determine the actual PTS & duration (be it raw mpeg4 stream, or realvideo, or mpeg1/2), but frame dropping (soft -framedrop) is enabled. SO, for B frames the codec will return NULL (no iamge decoding done) so the PTS/duration info lost. One possible solution would be to make codec optionally handle PTS info. In this case the codec should take care of PTS calculation for next non-dropped frame (ie. adjusting its rel_pts). Another method would be let codecs don't support frame dropping. (most codecs don't support it anyway, as no B frames or such thing) This could be flagged by a flag in either codec's global frams (see codecs.conf) or module_info_t flags. Maybe the former is better, for things like win32 dlls, where some dll support it some not. For codecs with no framedroping ability, the vf_vd.c could calculate the PTS correction, for the rest the codec should take care of. Both way seems doable, but adds extra compelxity to the already complicated stuff. Better ideas? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Fri Aug 1 23:35:28 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 1 Aug 2003 17:35:28 -0400 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308011853.h71IrNZ7019306@mail.mplayerhq.hu> References: <20030801184149.GG220@brightrain.aerifal.cx> <200308011853.h71IrNZ7019306@mail.mplayerhq.hu> Message-ID: <20030801213528.GI220@brightrain.aerifal.cx> On Fri, Aug 01, 2003 at 08:53:23PM +0200, Arpi wrote: > but for slow-cpu (and also slow-vga) type framedrop i think it's > more than a filter. actually it's a drop signal to the codec to do decoding > as fast as possible (ie. skip B frames, postprocessing etc) and skip all teh > filtering and display. The special case of temporal filters is already > hdnaled in the vf_process_image(), ie. drop 'signal' is not delivered above > the last filter needing all frames. Well I think there are two different problems we're addressing here. One is where the cpu is actually too slow to play the movie at all, and you have to recover as much cpu time as possible. The other case is where the cpu is plenty fast to decode all frames, but video memory is very slow, or else you're software scaling the movie to fullscreen. In the first case, it makes sense to skip decoding B frames entirely and maybe even skip some P frames (hardframedrop). But for the latter case, where scale/vo is taking all the cpu time, it would be nice to decode ALL frames so that temporal filters get to see all the frames, and then only start dropping somewhere midway down the filter chain (i.e. before scale, equalizer, or other slow spatial-only filters). Perhaps we should have 3 or 4 levels of framedrop, instead of 2 like in G1: 1. Decode all frames, drop some with a filter if vf/vo is too slow. 2. Decode all I/P frames but skip B frames and filter chain if video gets behind (like -framedrop now). 3. (optional, big hack) Like 2, but use some sort of lookahead in demuxer layer to identify when we're getting close to a new I frame, and drop one or two P frames just before it. This probably wouldn't help divx but might be nice for DVD/VCD where keyframe interval is small. 4. Full -hardframedrop. Rich From dalias at aerifal.cx Fri Aug 1 23:37:48 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 1 Aug 2003 17:37:48 -0400 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308012050.h71KoKUN007632@mail.mplayerhq.hu> References: <200308011853.h71IrNZ7019306@mail.mplayerhq.hu> <200308012050.h71KoKUN007632@mail.mplayerhq.hu> Message-ID: <20030801213748.GJ220@brightrain.aerifal.cx> On Fri, Aug 01, 2003 at 10:50:20PM +0200, Arpi wrote: > Hi, > > > > > any better ideas? > > > > > > IMO it should be much simpler than this. If the frames are being > > > dropped at the codec/demuxer end (because of 0-byte skipped frames in > > > .avi container and such, or nonrecoverable decoding errors or > > > whatever) then the codec/demuxer layer or the wrapper between codec > > > and vf layer should just adjust the relative_pts of the next frame it > > > sends out to account for any dropped frames in between. > > > > > On the other hand, if the frames are being dropped by a filter, it > > > seems to me that the filter should be responsible for pts accounting. > > > This is already the case for filters like inverse telecine that don't > > > actually 'drop' frames, but which have a non-1-to-1 correspondence > > > between input and output frames, so it seems like it'd be ok for other > > > filters (dint, decimate, etc.) which drop frames to do the same. > > > > you're right, as usual :) > > i'll go for this. > > I felt there will be some problems you didn't think of... > > For a start, there are cases, when only the codec can determine the actual > PTS & duration (be it raw mpeg4 stream, or realvideo, or mpeg1/2), > but frame dropping (soft -framedrop) is enabled. SO, for B frames the codec > will return NULL (no iamge decoding done) so the PTS/duration info lost. Not sure about other codecs, but with lavc you should be able to ask it to parse the frame (and thus get pts info) without actually decoding. It's hurry_up==5 or something. Not sure how well this fits in with mplayer's codec/demuxer architecture tho... > One possible solution would be to make codec optionally handle PTS info. > In this case the codec should take care of PTS calculation for next > non-dropped frame (ie. adjusting its rel_pts). > > Another method would be let codecs don't support frame dropping. > (most codecs don't support it anyway, as no B frames or such thing) > This could be flagged by a flag in either codec's global frams (see > codecs.conf) or module_info_t flags. Maybe the former is better, for > things like win32 dlls, where some dll support it some not. > For codecs with no framedroping ability, the vf_vd.c could calculate > the PTS correction, for the rest the codec should take care of. > > Both way seems doable, but adds extra compelxity to the already > complicated stuff. > > Better ideas? Not really. Basically framedropping sucks. :( Rich From arpi at thot.banki.hu Sat Aug 2 01:31:58 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 01:31:58 +0200 Subject: [MPlayer-G2-dev] new release: pre38 Message-ID: <200308012331.h71NVwqA004206@mail.mplayerhq.hu> Hi, this is a big cleanup release, with side-effect feature: better A-V sync! pre38: - test-play.c: sleep/timing stuff reworked, cleanup - sleep_accurate() and GetRelativeTime() are obsolete, use sleep_accurate2() - PTS vs. framedrop cleanup: - ds->mpi PTS copy code moved from vd.c to vf_vd.c - code fixed to use rel_pts instead of duration, including test-play.c - vf_vd.c takes care of dropped frames, and transforms duration to rel_pts - vd_libmpeg2.c: little cleanup, removed outer mpi definition (actually unused) - libavcodec upgraded from cvs - new global codec flag: 'demux' (you should add it to mpeg12 in codecs.conf!!) it means that demuxer will be called by the codec, instead of vf_vd.c it also solved the ds_get_pack() FIXME things in vd_*.c files Note the last point, unless you add 'flags demux' to mpeg12 codecs.conf entry it won't work! I have also added/fixed a few comments in test-play.c to make it better understandable. The next release will include either the new OSD implementation, or the new Timer API (replaces osdep/timer* mess). I have both things in mind, and halfway coded, just need to finish them. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ardneh2 at hotmail.com Sat Aug 2 03:22:27 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sat, 02 Aug 2003 01:22:27 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Arpi writes: >Hi, >The G2 'design' is about complete separation of core libraries from the UI >code (be it commandline or Gui or browser plugin or whatever). Great. >In G2, teh new config layer (see cfg.h) exports some usefull info, like the >short name/description of options, and a more controlled, limited set of >values (like using drop-down lists, min/max limited numbers etc, can be >mapped to Gui's combo boxes, bars etc). I think, a runtime 'window builder' >should be developed, I was hoping you would say something like that. >This code then could be used to generate the control window for filters, >codecs, output drivers etc. (all kinds of plugins/modules in libs) >Yes, I know it's a big work. I don't mind hard work as long as there is a point. :) Creating the preferences was the thing I was dreading above all else because it is such high maintenance code (in this case). This will make things much better / easier in the long run. >don't have to know Gui programming, and can use any (g)ui (be it gtk, qt, >win32, aqua, osd menu or anything) immediatelly to control it. >also it have to be written only once, and every new code can use it without >the needs to extending gui), Do you mean one for each toolkit that wants to write a UI? Or just one window builder for all toolkits? >the needs to extending gui), but it has some disadvantages too, especially >may look worse, than a well-designed control window (although we could >extend the config struct with gui-helper data, like position inside the >window or grouping of options, if really required). The most I think you would need is grouping info. I do not see being able to represent positions usefully/accurately for different toolkits / GUIs. I've got a couple of ideas for implementing grouping. I will send them later. As for looks, we'll see when we get there. As long as there are not too many items on a page it should look OK (it will depend on how smart the window builder is). >So, what a GUI should do (imho): >- handle file selection (open) and playlists (or even better: playtrees, > i mean some playlist formats (including reference .mov files etc) > support tree of files, and multiple (different bitrate, language etc) > alternatives os same contents. it would be nice if the gui could display > this and let the user to select from such tree. > (note the metadata export from stream layer is not yet coded, it's >required > to export cdda/cddb tracklists, dvd title/chapter structure etc) Agreed. I looked at the playtrees in G1 and was wondering why they were not used by the GUI. >- do window management for video window too, including fullscreen >switching, > setting title, always-on-top and such attributes... you should knoe >better. > (it can be done in x11-util.c too, but i was told that in gui 'mode' it > must be done by the gui, to be able to swap gui and video windows > overlapping or so.) The less X code the better. Still, I'm sure there is code that can be used by everyone (using X) and it will be handy to have it in one place. I have to look into it more. -Charles _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From arpi at thot.banki.hu Sat Aug 2 13:40:55 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 13:40:55 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <200308021140.h72BetHB016484@mail.mplayerhq.hu> Hi, > >In G2, teh new config layer (see cfg.h) exports some usefull info, like the > >short name/description of options, and a more controlled, limited set of > >values (like using drop-down lists, min/max limited numbers etc, can be > >mapped to Gui's combo boxes, bars etc). I think, a runtime 'window builder' > >should be developed, > > I was hoping you would say something like that. Great! > >This code then could be used to generate the control window for filters, > >codecs, output drivers etc. (all kinds of plugins/modules in libs) > >Yes, I know it's a big work. > > I don't mind hard work as long as there is a point. :) > Creating the preferences was the thing I was dreading above all else > because it is such high maintenance code (in this case). > This will make things much better / easier in the long run. > > >don't have to know Gui programming, and can use any (g)ui (be it gtk, qt, > >win32, aqua, osd menu or anything) immediatelly to control it. > >also it have to be written only once, and every new code can use it without > >the needs to extending gui), > > Do you mean one for each toolkit that wants to write a UI? Or just one > window > builder for all toolkits? I meant one for each Gui implementation, but of you think it's easier to write a common 'gui builder' with toolkit-specific backends, do it :) I don't know these toolkits (i never programmed Guis), but i guess they are named differently because they have different logic, design, features. Of course you only need to support gtk2 , the win32 etc gui developers will do it for their toolkit/platform, i guess. > >the needs to extending gui), but it has some disadvantages too, especially > >may look worse, than a well-designed control window (although we could > >extend the config struct with gui-helper data, like position inside the > >window or grouping of options, if really required). > > The most I think you would need is grouping info. I do not see being able > to represent > positions usefully/accurately for different toolkits / GUIs. I've got a > couple of ideas for > implementing grouping. I will send them later. Ok. Actually grouping is already present in config layer, but afaik not yet used in any of teh plugins. Maybe we need more detailed grouping (multi-dimensional or hierarchieal?)... > As for looks, we'll see when we get there. As long as there are not too > many > items on a page it should look OK (it will depend on how smart the window > builder is). I think there wont be too much things. But it's sometimes possible that a module/plugin have options of type module_list_t, ie. a selection of other plugins/modules. I think this could be represented in gui by a pair of list boxes, the selected plugins on the left side, and the list of available modules (of that type) on right side. Then user can drag'n'drop (or other way add/remove) items from right to left, and by double-clicking on left side elements they can configure tehse modules (by pop-up new cofnig window). Or I'm just dreaming :))) > >So, what a GUI should do (imho): > >- handle file selection (open) and playlists (or even better: playtrees, > > i mean some playlist formats (including reference .mov files etc) > > support tree of files, and multiple (different bitrate, language etc) > > alternatives os same contents. it would be nice if the gui could display > > this and let the user to select from such tree. > > (note the metadata export from stream layer is not yet coded, it's > >required > > to export cdda/cddb tracklists, dvd title/chapter structure etc) > > Agreed. I looked at the playtrees in G1 and was wondering why they were not > used by the GUI. The playtree code in g1 was quite broken (dunno if it works ok now, i guess not yet), and Pontscho (g1 gui maker) didn't understand how it works. We were designing some metadata structure to use for exporting tracklists, playlists/trees etc from stream/demuxer layer, but it was not implemented yet. See teh mail archives if interested, but if you need it ASAP i'll increase its priority. Or if anyone interested in implementing that, tell me. > >- do window management for video window too, including fullscreen > >switching, > > setting title, always-on-top and such attributes... you should knoe > >better. > > (it can be done in x11-util.c too, but i was told that in gui 'mode' it > > must be done by the gui, to be able to swap gui and video windows > > overlapping or so.) > > The less X code the better. Still, I'm sure there is code that can be used > by everyone > (using X) and it will be handy to have it in one place. I have to look into > it more. Great! A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Sat Aug 2 13:52:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 13:52:17 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <200308021140.h72BetHB016484@mail.mplayerhq.hu> Message-ID: <200308021152.h72BqHD2017220@mail.mplayerhq.hu> Hi, > > >- do window management for video window too, including fullscreen > > >switching, > > > setting title, always-on-top and such attributes... you should knoe > > >better. > > > (it can be done in x11-util.c too, but i was told that in gui 'mode' it > > > must be done by the gui, to be able to swap gui and video windows > > > overlapping or so.) > > > > The less X code the better. Still, I'm sure there is code that can be used > > by everyone > > (using X) and it will be handy to have it in one place. I have to look into > > it more. Hmm, maybe we should keep in mind, that gtk(2) is already usable on multiple X-less 'platforms', like linux framebuffer, win32 etc. So if possible, X and gtk code shouldn't be mixed (like it was done in G1's gui) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Sat Aug 2 19:28:48 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 19:28:48 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <20030801213528.GI220@brightrain.aerifal.cx> Message-ID: <200308021728.h72HSm01006299@mail.mplayerhq.hu> Hi, > Perhaps we should have 3 or 4 levels of framedrop, instead of 2 like yes > 3. (optional, big hack) Like 2, but use some sort of lookahead in > demuxer layer to identify when we're getting close to a new I > frame, and drop one or two P frames just before it. This probably > wouldn't help divx but might be nice for DVD/VCD where keyframe > interval is small. It is really big hack, and simply doesn't worth it to implement. There are several issues: - needs big hacks in demuxers - formats using short keyframe rate, also mostly uses (easily droppable) B frames. it's true in general, that there are 2 kind of containers/codecs, one for live streaming (no B frames, big keyframe distance, no seeking, no cpu usage scalability, no backward (or speed!=1x) playback) and one for offline playback and editing, like mpeg (short keyframe/gop distance, B frames, and so on, the opposite of the other). - it's not completely true that I frames are keyframes in mpeg2. there are streams (actually most of them i've seen) using partial update in I frames, ie. you need to decode 2 or more I frames to get the complete picture, otherwise you'll see checkboard-liek thing. just try to seek in some mpeg2 streams... (mostly true for DVD and DVB files). I frames don't use prediction (ie. reference frames), so you can seek to them, but also don't always cover the whole image area, so you can't simply skip them. And anwyay, as you already mentioned: framedropping sucks. We shouldn't optimize our player for frame dropping (esp. at times of 2.6ghz p4 cpus being used even for word processing machines) but for speed and quality. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From gsbarbieri at yahoo.com.br Sat Aug 2 21:47:49 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sat, 2 Aug 2003 16:47:49 -0300 (ART) Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <20030802194749.4202.qmail@web20903.mail.yahoo.com> Wouldn't be easier if we use something like libglade to design the ui? I mean, it's good to have a window builder, but they can become ugly and non functional at a certain point, if no layout info is provided to it. However, putting too much layout info in mplayer's config would bloat it. What about have a window builder that constructs glade's xml and then one could go there and manually tweak the look. Mplayer gtk ui could be as easy as calling libglade! But, there comes a problem: how to keep track from human (manual) interventions? Maybe the window builder could try to keep the old layout (and maybe learn with it). Maybe we could keep the manual changes as patches and apply it over and over (ugly, but easier). PS: IMHO grouping is something that could be in mplayer config struct, and with that we can get a almost good GUI. Maybe just on releases we can tweak the xml, so things would be better layed out. Gustavo --- Charles Ezell escreveu: > Arpi writes: > > >Hi, > > >The G2 'design' is about complete separation of core libraries from > the UI > >code (be it commandline or Gui or browser plugin or whatever). > > Great. > > >In G2, teh new config layer (see cfg.h) exports some usefull info, > like the > >short name/description of options, and a more controlled, limited > set of > >values (like using drop-down lists, min/max limited numbers etc, can > be > >mapped to Gui's combo boxes, bars etc). I think, a runtime 'window > builder' > >should be developed, > > I was hoping you would say something like that. > > >This code then could be used to generate the control window for > filters, > >codecs, output drivers etc. (all kinds of plugins/modules in libs) > >Yes, I know it's a big work. > > I don't mind hard work as long as there is a point. :) > Creating the preferences was the thing I was dreading above all else > because it is such high maintenance code (in this case). > This will make things much better / easier in the long run. > > >don't have to know Gui programming, and can use any (g)ui (be it > gtk, qt, > >win32, aqua, osd menu or anything) immediatelly to control it. > >also it have to be written only once, and every new code can use it > without > >the needs to extending gui), > > Do you mean one for each toolkit that wants to write a UI? Or just > one > window > builder for all toolkits? > > >the needs to extending gui), but it has some disadvantages too, > especially > >may look worse, than a well-designed control window (although we > could > >extend the config struct with gui-helper data, like position inside > the > >window or grouping of options, if really required). > > The most I think you would need is grouping info. I do not see being > able > to represent > positions usefully/accurately for different toolkits / GUIs. I've > got a > couple of ideas for > implementing grouping. I will send them later. > > As for looks, we'll see when we get there. As long as there are not > too > many > items on a page it should look OK (it will depend on how smart the > window > builder is). > > >So, what a GUI should do (imho): > >- handle file selection (open) and playlists (or even better: > playtrees, > > i mean some playlist formats (including reference .mov files etc) > > support tree of files, and multiple (different bitrate, language > etc) > > alternatives os same contents. it would be nice if the gui could > display > > this and let the user to select from such tree. > > (note the metadata export from stream layer is not yet coded, it's > > >required > > to export cdda/cddb tracklists, dvd title/chapter structure etc) > > Agreed. I looked at the playtrees in G1 and was wondering why they > were not > used by the GUI. > > >- do window management for video window too, including fullscreen > >switching, > > setting title, always-on-top and such attributes... you should > knoe > >better. > > (it can be done in x11-util.c too, but i was told that in gui > 'mode' it > > must be done by the gui, to be able to swap gui and video windows > > overlapping or so.) > > The less X code the better. Still, I'm sure there is code that can > be used > by everyone > (using X) and it will be handy to have it in one place. I have to > look into > it more. > > -Charles > > _________________________________________________________________ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From dalias at aerifal.cx Sat Aug 2 22:15:54 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sat, 2 Aug 2003 16:15:54 -0400 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030802194749.4202.qmail@web20903.mail.yahoo.com> References: <20030802194749.4202.qmail@web20903.mail.yahoo.com> Message-ID: <20030802201554.GM220@brightrain.aerifal.cx> On Sat, Aug 02, 2003 at 04:47:49PM -0300, Gustavo Sverzut Barbieri wrote: > Wouldn't be easier if we use something like libglade to design the ui? > > I mean, it's good to have a window builder, but they can become ugly > and non functional at a certain point, if no layout info is provided to > it. > > However, putting too much layout info in mplayer's config would bloat > it. > > What about have a window builder that constructs glade's xml and then > one could go there and manually tweak the look. > Mplayer gtk ui could be as easy as calling libglade! How incredibly bloated. Something like glade is for people who don't know how to code... Rich From michaelni at gmx.at Sat Aug 2 22:41:22 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Sat, 2 Aug 2003 22:41:22 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308021728.h72HSm01006299@mail.mplayerhq.hu> References: <200308021728.h72HSm01006299@mail.mplayerhq.hu> Message-ID: <200308022241.23251.michaelni@gmx.at> Hi On Saturday 02 August 2003 19:28, Arpi wrote: [...] > - it's not completely true that I frames are keyframes in mpeg2. there are > streams (actually most of them i've seen) using partial update in I > frames, ie. you need to decode 2 or more I frames to get the complete > picture, otherwise you'll see checkboard-liek thing. just try to seek in > some mpeg2 streams... (mostly true for DVD and DVB files). I frames don't > use prediction (ie. reference frames), so you can seek to them, but also > don't always cover the whole image area, so you can't simply skip them. hmm, do u say that there are streams which have skiped MBs / skiped slices in I frames? the syntax would allow that but i thought thats not allowed in the standard or did u mean I field pictures, for these 2 are needed and the second could even be a P field picture ... btw, mplayer should call AVCodec.flush() before seeking to avoid trashed B frames, as the "future" refrence frame is wrong immediately after seeking I0 P2 B1 I4 B3 no seeking: I0, I0->P2, I0->B1<-P2, I4, P2->B3<-I4 seeking: I0, seek, I4, I0->B3<-I4 [...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From arpi at thot.banki.hu Sat Aug 2 22:59:24 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 22:59:24 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308022241.23251.michaelni@gmx.at> Message-ID: <200308022059.h72KxOfE021027@mail.mplayerhq.hu> Hi, > > - it's not completely true that I frames are keyframes in mpeg2. there are > > streams (actually most of them i've seen) using partial update in I > > frames, ie. you need to decode 2 or more I frames to get the complete > > picture, otherwise you'll see checkboard-liek thing. just try to seek in > > some mpeg2 streams... (mostly true for DVD and DVB files). I frames don't > > use prediction (ie. reference frames), so you can seek to them, but also > > don't always cover the whole image area, so you can't simply skip them. > hmm, do u say that there are streams which have skiped MBs / skiped slices in > I frames? the syntax would allow that but i thought thats not allowed in the yes, skipped MBs. it looks like a checkboard, every 2nd or 3rd MB is skipped, so you need 2 or 3 I/P frames to get the whole picture. try any VOB (i've tried matrix.vob and apollo_440_-_lost_in_space(jason_nevis_lunar_landing).vob, the later is on mphq too) with mplayer file.vob -nosound -fps 2 and then seek. > standard or did u mean I field pictures, for these 2 are needed and the no > btw, mplayer should call AVCodec.flush() before seeking to avoid trashed B > frames, as the "future" refrence frame is wrong immediately after seeking hmm. does it also flush internal buffers/states when using 'truncated' mode? (i mean passing mpeg frame data by small chunks instead as whole frame ?) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From joey at nicewarrior.org Sat Aug 2 22:49:54 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Sat, 2 Aug 2003 15:49:54 -0500 Subject: [MPlayer-G2-dev] new release: pre38 In-Reply-To: <200308012331.h71NVwqA004206@mail.mplayerhq.hu> References: <200308012331.h71NVwqA004206@mail.mplayerhq.hu> Message-ID: <20030802204954.GB7242@nicewarrior.org> On Sat, Aug 02, 2003 at 01:31:58AM +0200, Arpi wrote: > - new global codec flag: 'demux' (you should add it to mpeg12 in codecs.conf!!) > it means that demuxer will be called by the codec, instead of vf_vd.c > it also solved the ds_get_pack() FIXME things in vd_*.c files > > Note the last point, unless you add 'flags demux' to mpeg12 codecs.conf > entry it won't work! Can you explain in a little bit more detail how this works vs. how the last release worked? What is the difference between the sequence of calls with and without 'flags demux'? (I'm trying to finish my gif ports to pre37, so I want to know how I have to change my code.) --Joey From arpi at thot.banki.hu Sat Aug 2 23:18:52 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 23:18:52 +0200 Subject: [MPlayer-G2-dev] new release: pre38 In-Reply-To: <20030802204954.GB7242@nicewarrior.org> Message-ID: <200308022118.h72LIqqm022610@mail.mplayerhq.hu> Hi, > On Sat, Aug 02, 2003 at 01:31:58AM +0200, Arpi wrote: > > - new global codec flag: 'demux' (you should add it to mpeg12 in codecs.conf!!) > > it means that demuxer will be called by the codec, instead of vf_vd.c > > it also solved the ds_get_pack() FIXME things in vd_*.c files > > > > Note the last point, unless you add 'flags demux' to mpeg12 codecs.conf > > entry it won't work! > > Can you explain in a little bit more detail how this works vs. how the > last release worked? What is the difference between the sequence of > calls with and without 'flags demux'? (I'm trying to finish my gif > ports to pre37, so I want to know how I have to change my code.) > > --Joey In previous versions, every video codec's (vd_*.c) decode() function began with such line: len=ds_get_packet(sh->ds,&data); // FIXME In g1, the codec's decode() was called with the compressed data packet (pointer & len) of a single frame. It limited codecs to 1:1 mapping between demuxed packets and output frames. And it worked well for almost all codecs. Only a few codec support 'truncated data', ie you can pass a fragment of a compressed frame packet to the codec, and it will report 'i want more data' until it gets enough. libmpeg2 0.3.x is such thing, and libavcodec also supports this mode. It's interesting for raw formats, where the demuxer cannot determine the frame boundaries, just can pass fragments to codec, and let teh codec decide where a compressed frame ends. So, i've added support for this in g2 at first day, by allowing the video codec call the demuxer when they want, just like the audio codecs do since the first day of g1. So, in g2 (up to prev. release) every video codec had its own call to demuxer to get a cmpressed frame. But I found it difficult to handle PTS calculations (transform timestamp data from demuxer to vf_vd.c) if the codec calls teh demuxer, so i've moved it back to core (actually vf_vd.c) and only the selected (flags demux) codecs are allowed to mess with demuxer themself. It also helped compatibility with g1 codec api. And since libmpeg2 of g2 is such thing, it needs 'flags demux' A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From michaelni at gmx.at Sat Aug 2 23:17:39 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Sat, 2 Aug 2003 23:17:39 +0200 Subject: [MPlayer-G2-dev] bypassing PTS in video filter layer In-Reply-To: <200308022059.h72KxOfE021027@mail.mplayerhq.hu> References: <200308022059.h72KxOfE021027@mail.mplayerhq.hu> Message-ID: <200308022317.39653.michaelni@gmx.at> Hi On Saturday 02 August 2003 22:59, Arpi wrote: > Hi, > > > > - it's not completely true that I frames are keyframes in mpeg2. there > > > are streams (actually most of them i've seen) using partial update in I > > > frames, ie. you need to decode 2 or more I frames to get the complete > > > picture, otherwise you'll see checkboard-liek thing. just try to seek > > > in some mpeg2 streams... (mostly true for DVD and DVB files). I frames > > > don't use prediction (ie. reference frames), so you can seek to them, > > > but also don't always cover the whole image area, so you can't simply > > > skip them. > > > > hmm, do u say that there are streams which have skiped MBs / skiped > > slices in I frames? the syntax would allow that but i thought thats not > > allowed in the > > yes, skipped MBs. it looks like a checkboard, every 2nd or 3rd MB is > skipped, so you need 2 or 3 I/P frames to get the whole picture. btw, mpeg2 std: ---- There shall be no skipped macroblocks in I-pictures except when either picture_spatial_scalable_extension() follows the picture_header() of the current picture. or sequence_scalable_extension() is present in the bitstream and scalable_mode = "SNR scalability". ---- > > try any VOB (i've tried matrix.vob and > apollo_440_-_lost_in_space(jason_nevis_lunar_landing).vob, the later is on > mphq too) with mplayer file.vob -nosound -fps 2 and then seek. hmm, i only see the trashed b frames ... try: -----mpeg12.c.diff--- -if(s2->last_picture_ptr==NULL && s2->pict_type==B_TYPE) break; +if(s2->pict_type==B_TYPE) break; --------------------- this will skip all b frames > > > standard or did u mean I field pictures, for these 2 are needed and the > > no > > > btw, mplayer should call AVCodec.flush() before seeking to avoid trashed > > B frames, as the "future" refrence frame is wrong immediately after > > seeking > > hmm. does it also flush internal buffers/states when using 'truncated' > mode? (i mean passing mpeg frame data by small chunks instead as whole > frame ?) no, but it should, ill fix that, should be quite easy [...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From joey at nicewarrior.org Sat Aug 2 23:34:36 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Sat, 2 Aug 2003 16:34:36 -0500 Subject: [MPlayer-G2-dev] new release: pre38 In-Reply-To: <200308022118.h72LIqqm022610@mail.mplayerhq.hu> References: <20030802204954.GB7242@nicewarrior.org> <200308022118.h72LIqqm022610@mail.mplayerhq.hu> Message-ID: <20030802213435.GE7242@nicewarrior.org> On Sat, Aug 02, 2003 at 11:18:52PM +0200, Arpi wrote: > Only a few codec support 'truncated data', ie you can pass a fragment of a > compressed frame packet to the codec, and it will report 'i want more data' > until it gets enough. libmpeg2 0.3.x is such thing, and libavcodec also > supports this mode. It's interesting for raw formats, where the demuxer > cannot determine the frame boundaries, just can pass fragments to codec, and > let teh codec decide where a compressed frame ends. I see. So, in GIF format, a single image is split into blocks. You don't know how many blocks until you see a 'termination block.' What I just wrote was that the demux packet is resized over and over until all the blocks of one image are in one packet. Do you think preformance would be better if the GIF demuxer added a packet to the queue for each block and then let the LZW decoder ask for multiple packets? IIRC, realloc() uses memcpy, right? So this fragmented packets would be less memcpy since there is no realloc over and over. Is this correct? Thanks, --Joey From arpi at thot.banki.hu Sat Aug 2 23:47:56 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 2 Aug 2003 23:47:56 +0200 Subject: [MPlayer-G2-dev] new release: pre38 In-Reply-To: <20030802213435.GE7242@nicewarrior.org> Message-ID: <200308022147.h72LluRh027425@mail.mplayerhq.hu> Hi, > On Sat, Aug 02, 2003 at 11:18:52PM +0200, Arpi wrote: > > Only a few codec support 'truncated data', ie you can pass a fragment of a > > compressed frame packet to the codec, and it will report 'i want more data' > > until it gets enough. libmpeg2 0.3.x is such thing, and libavcodec also > > supports this mode. It's interesting for raw formats, where the demuxer > > cannot determine the frame boundaries, just can pass fragments to codec, and > > let teh codec decide where a compressed frame ends. > > I see. So, in GIF format, a single image is split into blocks. You > don't know how many blocks until you see a 'termination block.' > What I just wrote was that the demux packet is resized over and over > until all the blocks of one image are in one packet. Do you think > preformance would be better if the GIF demuxer added a packet to the > queue for each block and then let the LZW decoder ask for multiple > packets? yes. this is why libmpeg2 works this way, too. (mpeg video is splitted to so-called slices, a line of macroblocks, so yo have to read many of them to get a whole frame) > IIRC, realloc() uses memcpy, right? So this fragmented yes > packets would be less memcpy since there is no realloc over and over. > Is this correct? yes and realloc is slow anyway, it have to search for matching size free blocks. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From gsbarbieri at yahoo.com.br Sun Aug 3 03:31:07 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sat, 2 Aug 2003 22:31:07 -0300 (ART) Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030802201554.GM220@brightrain.aerifal.cx> Message-ID: <20030803013107.23155.qmail@web20901.mail.yahoo.com> Rich, I wouldn't say you need to code to make user interfaces... Also, people may have different knowledge, some like to code and some like to develop UI. I like to code and hate and I don't know how to make UI, I don't know how to lay things out and have an intuitive UI. Do you? I agree libglade could be bloated, however that will not make any difference to us since the hard stuff is coded by mplayer team, GUI wouldn't make it slower... Also, libglade stays out mplayer, so it is transparent to us. If it's bloated inside libglade, it will not make mplayer bloated. I vote for that kind of solution since it makes easier to people come and help improving UI, and yes, without knowing C. Gustavo --- D Richard Felker III escreveu: > On Sat, Aug 02, 2003 at 04:47:49PM -0300, Gustavo Sverzut Barbieri > wrote: > > Wouldn't be easier if we use something like libglade to design the > ui? > > > > I mean, it's good to have a window builder, but they can become > ugly > > and non functional at a certain point, if no layout info is > provided to > > it. > > > > However, putting too much layout info in mplayer's config would > bloat > > it. > > > > What about have a window builder that constructs glade's xml and > then > > one could go there and manually tweak the look. > > Mplayer gtk ui could be as easy as calling libglade! > > How incredibly bloated. Something like glade is for people who don't > know how to code... > > Rich > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From gsbarbieri at yahoo.com.br Sun Aug 3 04:06:22 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sat, 2 Aug 2003 23:06:22 -0300 (ART) Subject: [MPlayer-G2-dev] Other languages bindings? Message-ID: <20030803020622.38340.qmail@web20909.mail.yahoo.com> Hello, Since G2 will be mainly a lib, would be cool to have bindings to other languages, like Python, Perl, Java, Lisp, etc... So one can use those libraries everywhere. So, as I'm a Freevo developer and we use python, would be cool to have a mplayer module for python so we don't need to use pipes between mplayer and freevo, and I want to do those bindings. What functions I may export do do so? I mean, all functions in: dec_audio.h, sh_audio.h, dec_video.h, sh_video.h, audio_out.h and video_out.h That's it or I need more functions? Also, maybe you can tell if worth implementing some extra code, so make the life easy (I mean, implement more functions, like (if) AV correction code is always (?) the same, so having a code to do that instead of replicating that code everywhere...) Anyone interested? Gustavo _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From arpi at thot.banki.hu Sun Aug 3 04:21:47 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 3 Aug 2003 04:21:47 +0200 Subject: [MPlayer-G2-dev] Other languages bindings? In-Reply-To: <20030803020622.38340.qmail@web20909.mail.yahoo.com> Message-ID: <200308030221.h732LlQY010113@mail.mplayerhq.hu> Hi, > Since G2 will be mainly a lib, would be cool to have bindings to other > languages, like Python, Perl, Java, Lisp, etc... So one can use those > libraries everywhere. lol these libraries are too low-level (and performance critic, with thousand calls per second) for such script-langauges. maybe some player layer can be developed later, with high-level api functions (to control the player) exported... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From gsbarbieri at yahoo.com.br Sun Aug 3 04:48:44 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sat, 2 Aug 2003 23:48:44 -0300 (ART) Subject: [MPlayer-G2-dev] Other languages bindings? In-Reply-To: <200308030221.h732LlQY010113@mail.mplayerhq.hu> Message-ID: <20030803024844.86295.qmail@web20913.mail.yahoo.com> Hum... that was I imagined :) The "extra code" i mentioned could be (or be part of) the high-level player (maybe encoder too) api. :) also, I can be stupid to ask that but: if a video have 60fps and we would only call those functions from something like test-play, how it will be called "thousand calls per second"? And when I say binding I was just saying that I will make an interface for python (ie) calling the C libraries (compiled objects, binary, .so or static), so the critical optimisations (mmx, sse, ...) will still be there. (Of course you will have an overhead from this interface) Anyway, good you didn't lol more times as I was expecting :) Gustavo --- Arpi escreveu: > Hi, > > > Since G2 will be mainly a lib, would be cool to have bindings to > other > > languages, like Python, Perl, Java, Lisp, etc... So one can use > those > > libraries everywhere. > > lol > these libraries are too low-level (and performance critic, with > thousand > calls per second) for such script-langauges. > > maybe some player layer can be developed later, with high-level api > functions (to control the player) exported... > > > 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 _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From ardneh2 at hotmail.com Sun Aug 3 08:13:50 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 06:13:50 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: > > > >- do window management for video window too, including fullscreen > > > >switching, > > > > setting title, always-on-top and such attributes... you should knoe > > > >better. > > > > (it can be done in x11-util.c too, but i was told that in gui >'mode' it > > > > must be done by the gui, to be able to swap gui and video windows > > > > overlapping or so.) > > > > > > The less X code the better. Still, I'm sure there is code that can be >used > > > by everyone > > > (using X) and it will be handy to have it in one place. I have to >look into > > > it more. > >Hmm, maybe we should keep in mind, that gtk(2) is already usable on >multiple >X-less 'platforms', like linux framebuffer, win32 etc. >So if possible, X and gtk code shouldn't be mixed (like it was done in G1's >gui) Sorry, didn't mean to imply that I would ever put raw X code in with my code. Will not happen. However, there might be something I cannot do from GTK/GDK/GLib and I will need to call X directly. Should that happen I would put the X code in an appropriately named external function so it does not hurt portability. Please note that I do not expect this to happen, but you guys do some really low-level things so I'm just not sure yet. BTW, I'm hoping the GTK version will be good enough that no one will 'need' to write a native win32 version. XChat is really impressive on win32 and Gaim is getting there. Might be there, it's been a long time since I've tried it. >A'rpi / Astral & ESP-team _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From ardneh2 at hotmail.com Sun Aug 3 08:05:30 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 06:05:30 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: >I meant one for each Gui implementation, but of you think it's easier to >write a common 'gui builder' with toolkit-specific backends, do it :) Good. It is not. I wish it was. Not even worth thinking about. :( >> >the needs to extending gui), but it has some disadvantages too, >>especially >> >may look worse, than a well-designed control window (although we could >> >extend the config struct with gui-helper data, like position inside the >> >window or grouping of options, if really required). >> >>The most I think you would need is grouping info. I do not see being able >>to represent >>positions usefully/accurately for different toolkits / GUIs. I've got a >>couple of ideas for >>implementing grouping. I will send them later. >Ok. >Actually grouping is already present in config layer, but afaik not yet >used >in any of teh plugins. Maybe we need more detailed grouping >(multi-dimensional or hierarchieal?)... I saw the TODO. :) Hierarchical should be enough. The more I think about it, the more it would help to have, even for the command line player --it would provide automatic grouping of options. For GUIs it is much more important, though. It should enable me (or anyone else) to just do one pass through the config and only create the windows / controls that are needed. Before I make the suggestion I want to test it. No point in wasting everyone's time if it isn't workable. >As for looks, we'll see when we get there. As long as there are not too >many >items on a page it should look OK (it will depend on how smart the window >builder is). >I think there wont be too much things. >But it's sometimes possible that a module/plugin have options of type >module_list_t, ie. a selection of other plugins/modules. >I think this could be represented in gui by a pair of list boxes, the >selected plugins on the left side, and the list of available modules (of >that type) on right side. Then user can drag'n'drop (or other way >add/remove) items from right to left, and by double-clicking on left side >elements they can configure tehse modules (by pop-up new cofnig window). >Or I'm just dreaming :))) No. I have already written a program that does such a thing with modules. It worked very well. It's what I had in mind. :) >>Agreed. I looked at the playtrees in G1 and was wondering why they were >>not used by the GUI. >The playtree code in g1 was quite broken (dunno if it works ok now, i guess >not yet), and Pontscho (g1 gui maker) didn't understand how it works. >We were designing some metadata structure to use for exporting tracklists, >playlists/trees etc from stream/demuxer layer, but it was not implemented >yet. See teh mail archives if interested, but if you need it ASAP i'll >increase its priority. Or if anyone interested in implementing that, tell >me. Ah. OK. It is not a high priority. I don't understand them yet, either. :) They just looked neat. My first priority is getting the GTK2 window builder written (at least mostly). Once that is done I shouldn't have to mess with it too much, so I can go on to other things. -Charles _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From ardneh2 at hotmail.com Sun Aug 3 09:04:39 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 07:04:39 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: >Wouldn't be easier if we use something like libglade to design the ui? > >I mean, it's good to have a window builder, but they can become ugly >and non functional at a certain point, if no layout info is provided to >it. I was waiting for this. :) It's a good idea, but the answer (for the config windows) is no. Please keep reading for as to why. If I am not clear enough or you want more info, please ask. :) >However, putting too much layout info in mplayer's config would bloat >it. Worse, the layout info would be worthless for some toolkits / platforms. I do not know of a way to represent it in a meaningful way for enough platforms. They are too different. For instance, writing a gui builder for GTK is much easier than writing one for win32. Why? Because GTK uses containers/boxes to hold controls. In GTK, you just put controls in boxes and don't worry about the corordinates because those are handled automatically. This is so nice, because windows always tend to look good --even when they are resized. >What about have a window builder that constructs glade's xml and then >one could go there and manually tweak the look. > Mplayer gtk ui could be as easy as calling libglade! There are a couple problems with this. First, you would be doing the work twice, something I never like to do. Second, if I understand A'rpi correctly, is that the whole system is supposed to be dynamic. If I do my job correctly, you guys should be able to add dozens of modules to mplayer and the users will not have to upgrade the GUI. This isn't going to be possible if xml tweaking is involved. Third, the core gui builder code isn't that complex and the config design is well thought out. This makes things much easier. If I run into problems, we'll work things out. >But, there comes a problem: how to keep track from human (manual) >interventions? Maybe the window builder could try to keep the old >layout (and maybe learn with it). Maybe we could keep the manual >changes as patches and apply it over and over (ugly, but easier). That would be very hard to do and maintain. I am probably going to have to write some algorithms for control placement (mainly how many controls on a page is too many), I will tweak those as necessary. The most important thing is not jamming stuff together. >PS: IMHO grouping is something that could be in mplayer config struct, >and with that we can get a almost good GUI. Maybe just on releases we Yes, I believe you are correct about this (i.e more than just a flag). I'm working on it. But, as I said earlier, I'm going to make sure it works first and the impact on the rest of the system is minimal. >Gustavo Thank you for your ideas + comments, -Charles _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From gsbarbieri at yahoo.com.br Sun Aug 3 09:23:19 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sun, 3 Aug 2003 04:23:19 -0300 (ART) Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <20030803072319.50675.qmail@web20901.mail.yahoo.com> --- Charles Ezell escreveu: > > >Wouldn't be easier if we use something like libglade to design the > ui? > > > >I mean, it's good to have a window builder, but they can become ugly > >and non functional at a certain point, if no layout info is provided > to > >it. > > I was waiting for this. :) > It's a good idea, but the answer (for the config windows) is no. :) I imagined that, I myself was not that convinced because of the twice work needed :) But I want to comment/ask on some points... > Please keep reading for as to why. If I am not clear enough or you > want > more info, please ask. :) > > >However, putting too much layout info in mplayer's config would > bloat > >it. > > Worse, the layout info would be worthless for some toolkits / > platforms. > I do not know of a way to represent it in a meaningful way for enough > > platforms. > They are too different. > > For instance, writing a gui builder for GTK is much > easier than writing one for win32. Why? Because GTK uses > containers/boxes > to hold controls. > In GTK, you just put controls in boxes and don't worry about the > corordinates > because those are handled automatically. This is so nice, because > windows always tend to look good --even when they are resized. Yes, I know that... win32 is the other way (coordinates-based) and I don't know Mac to tell... > >What about have a window builder that constructs glade's xml and > then > >one could go there and manually tweak the look. > > Mplayer gtk ui could be as easy as calling libglade! > > There are a couple problems with this. > > First, you would be doing the work twice, something I never like to > do. Neither do I :( > Second, if I understand A'rpi correctly, is that the whole system > is supposed to be dynamic. If I do my job correctly, > you guys should be able to add dozens of modules to mplayer and the > users > will not have to upgrade the GUI. This isn't going to be possible > if xml tweaking is involved. How dynamic it would be... it will generate those windows at compile time or at run time? > Third, the core gui builder code isn't that complex and > the config design is well thought out. This makes things much > easier. > If I run into problems, we'll work things out. My only hope is that the ui doesn't become something unlogical and non-intuitive... sometimes it's better to put things together because they're related, but doesn't worth to put them in a Frame or a Tab... so maybe we can have at least 2 kind of groups: Visual (Frames, Tabs) and Non-Visual.... or 3: Frames, Tabs, Non-Visual... Any ideas on that? Also, maybe we could have the tab-order specified somewhere, so we can arrange items based on that order... maybe that list could be other place... And (just to make you crazy ;) sometimes it's cool to have small items arranged in 2/3 columns > >But, there comes a problem: how to keep track from human (manual) > >interventions? Maybe the window builder could try to keep the old > >layout (and maybe learn with it). Maybe we could keep the manual > >changes as patches and apply it over and over (ugly, but easier). > > That would be very hard to do and maintain. I am probably going to > have > to write some algorithms for control placement (mainly how many > controls on > a > page is too many), I will tweak those as necessary. > The most important thing is not jamming stuff together. IDEA: Every page you put, please I beg you to use a scroll-able content (automatic scrollbars), so if someone have a 800x600 with big fonts, things that generally looks well in 1024x768 will probably overflow the screen... that happens a lot with linux gui apps :( > >PS: IMHO grouping is something that could be in mplayer config > struct, > >and with that we can get a almost good GUI. Maybe just on releases > we > > Yes, I believe you are correct about this (i.e more than just a > flag). > I'm working on it. But, as I said earlier, I'm going to make sure it > works > first > and the impact on the rest of the system is minimal. > Ok. > Thank you for your ideas + comments, You're welcome. Gustavo _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From ardneh2 at hotmail.com Sun Aug 3 09:25:23 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 07:25:23 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: >On Sat, Aug 02, 2003 at 04:47:49PM -0300, Gustavo Sverzut Barbieri wrote: > > Wouldn't be easier if we use something like libglade to design the ui? > > > > I mean, it's good to have a window builder, but they can become ugly > > and non functional at a certain point, if no layout info is provided to > > it. > > > > However, putting too much layout info in mplayer's config would bloat > > it. > > > > What about have a window builder that constructs glade's xml and then > > one could go there and manually tweak the look. > > Mplayer gtk ui could be as easy as calling libglade! > >How incredibly bloated. Something like glade is for people who don't >know how to code... > >Rich lol. You're not serious, are you? I appologize if you are making a joke, I'm new here and still getting to know people. For those who do not know, libglade allows the creation of a GTK window and its controls from an xml file. It is the exact opposite of code bloat... I have certainly considered using it for the non-configuration related windows, but I am not there yet (and there are problems with using it for this project). BTW, I use GLADE (the application, not the library) to design all windows. I do not have enough time to waste it laying out controls manually. Respectfully, -Charles _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From ardneh2 at hotmail.com Sun Aug 3 09:49:01 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 07:49:01 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: >Rich, >I agree libglade could be bloated, however that will not make any >difference to us since the hard stuff is coded by mplayer team, GUI >wouldn't make it slower... Also, libglade stays out mplayer, so it is >transparent to us. If it's bloated inside libglade, it will not make >mplayer bloated. To put this to rest: /usr/lib$ ls -alh libglade-2.0.so.0.0.1 -rwxr-xr-x 1 root root 104k Apr 19 01:09 libglade-2.0.so.0.0.1* libglade is not incredibly bloated. Also, It does not have any dependencies a normal GTK+ application would not (with the possible exceptions of xml2 and expat). Good point about libglade being external, btw. >I vote for that kind of solution since it makes easier to people come >and help improving UI, and yes, without knowing C. Just ask. Make suggestions. I am listening and, as soon as I get something working (that is more than a toy), I will make it available so people can use it and provide feedback. As far as coding, if you (or anyone) are (is) interested in helping out, and don't know GUI programming, GTK+ is the easiest toolkit I have ever used. It is excellently designed and devhelp (http://www.imendio.com/projects/devhelp/) provides quick access to the api. Without that, porting mplayer to GTK2 probably wouldn't have happened. >Gustavo -Charles _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From gsbarbieri at yahoo.com.br Sun Aug 3 09:57:44 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sun, 3 Aug 2003 04:57:44 -0300 (ART) Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <20030803075744.83195.qmail@web20911.mail.yahoo.com> --- Charles Ezell escreveu: > > >Rich, > > >I agree libglade could be bloated, however that will not make any > >difference to us since the hard stuff is coded by mplayer team, GUI > >wouldn't make it slower... Also, libglade stays out mplayer, so it > is > >transparent to us. If it's bloated inside libglade, it will not make > >mplayer bloated. > > To put this to rest: > > /usr/lib$ ls -alh libglade-2.0.so.0.0.1 > -rwxr-xr-x 1 root root 104k Apr 19 01:09 > libglade-2.0.so.0.0.1* > > libglade is not incredibly bloated. > > Also, It does not have any dependencies a normal GTK+ application > would not > (with the possible exceptions of xml2 and expat). > Sure... > Good point about libglade being external, btw. :) > >I vote for that kind of solution since it makes easier to people > come > >and help improving UI, and yes, without knowing C. > > Just ask. Make suggestions. I am listening and, as soon as I get > something > working (that is more than a toy), I will make it available so people > can > use it > and provide feedback. Ok. I doesn't have gkt2 here yet... need to upgrade (or at least download it), but I'll be glad to help... > As far as coding, if you (or anyone) are (is) interested in helping > out, and Yes, I'm interested. > don't know > GUI programming, GTK+ is the easiest toolkit I have ever used. > It is excellently designed and devhelp > (http://www.imendio.com/projects/devhelp/) > provides quick access to the api. > Without that, porting mplayer to GTK2 probably wouldn't have > happened. I have to disagree here :) I already did some coding in gtk1 with perl and C, however IMHO QT is much easier to code, in C or Python or anything. I like OO for GUI and the QT API is very clear... However, it's my opinion and I do NOT have looked at gtk2 yet... I hope it's better than 1.2 Gustavo _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From ardneh2 at hotmail.com Sun Aug 3 10:37:46 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 08:37:46 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Gustavo writes: >Yes, I know that... win32 is the other way (coordinates-based) and I >don't know Mac to tell... Don't know either. :) But it is probably coord based. I was also thinking about Qt (which I know next to nothing about). > > Second, if I understand A'rpi correctly, is that the whole system > > is supposed to be dynamic. If I do my job correctly, > > you guys should be able to add dozens of modules to mplayer and the > > users > > will not have to upgrade the GUI. This isn't going to be possible > > if xml tweaking is involved. > >How dynamic it would be... it will generate those windows at compile >time or at run time? Run time. Completely dynamic. Also, I only want to create windows as they are needed. Example: (please see gedit2's prefs for a visual of the layout, if possible) you open the preferences and it generates the first page (because it is showing) but nothing else. Then you click on "Audio" (I am going to need help with internationalization) from the list on the left and it will create and show the audio options, complete with a list of audio plugins. Fun, huh? > > Third, the core gui builder code isn't that complex and > > the config design is well thought out. This makes things much > > easier. > > If I run into problems, we'll work things out. > >My only hope is that the ui doesn't become something unlogical and >non-intuitive... sometimes it's better to put things together because >they're related, but doesn't worth to put them in a Frame or a Tab... >so maybe we can have at least 2 kind of groups: Visual (Frames, Tabs) >and Non-Visual.... or 3: Frames, Tabs, Non-Visual... > Any ideas on that? I do not want that either. Yep. First I'm going to avoid tabs. If there are so many options they have to be used OK (like if one group of options is really large), but hopefully that won't be often. Second, a frame in GTK is a group box in win32. Does this help? Even a single item can look good in a frame (Anjuta's preferences are proof of that...) Third, I'm hoping to have unamed / anonymous groups. So if I group of options doesn't fit anywhere else they can be grouped together (probably without a frame / box). Fourth: What did you mean by non-visual? >Also, maybe we could have the tab-order specified somewhere, so we can >arrange items based on that order... maybe that list could be other >place... I think the options should be in the same order as in the config_t. If you mean for the case where there are so many options several tabs are needed, then that is worth thinking about. Since I would be generating tabs on the fly it would be next to impossible to come up with good names for them. 1, 2, 3 does not cut it. I think maybe you have best solution below. >And (just to make you crazy ;) sometimes it's cool to have small items >arranged in 2/3 columns I was actually planning to do that. :) Not necessarily based on size, but on how many options there are. Not based on size because of the way GTK works. This is definatley going to take some work. > > >But, there comes a problem: how to keep track from human (manual) > > >interventions? Maybe the window builder could try to keep the old > > >layout (and maybe learn with it). Maybe we could keep the manual > > >changes as patches and apply it over and over (ugly, but easier). > > > > That would be very hard to do and maintain. I am probably going to > > have > > to write some algorithms for control placement (mainly how many > > controls on > > a > > page is too many), I will tweak those as necessary. > > The most important thing is not jamming stuff together. > >IDEA: Every page you put, please I beg you to use a scroll-able content >(automatic scrollbars), so if someone have a 800x600 with big fonts, >things that generally looks well in 1024x768 will probably overflow the >screen... that happens a lot with linux gui apps :( Done. Really good idea. I usually run at 1280x1024 and admit I tend not to think about lower resolutions. :( Actually, I think I might just do this instead of tabs. I should be able to make the scrolling view look good, too. I have never tried anything like that so I'm going to have to get back to you. > > Thank you for your ideas + comments, > >You're welcome. > >Gustavo -Charles _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From arpi at thot.banki.hu Sun Aug 3 14:19:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 3 Aug 2003 14:19:05 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <200308031219.h73CJ5AI008706@mail.mplayerhq.hu> Hi, > I think the options should be in the same order as in the config_t. yes... config_t usually have options listed in importance order. for example at vf layer, the most often chanegd options come first, then the extras. we can change all config structs to look so. > >IDEA: Every page you put, please I beg you to use a scroll-able content > >(automatic scrollbars), so if someone have a 800x600 with big fonts, > >things that generally looks well in 1024x768 will probably overflow the > >screen... that happens a lot with linux gui apps :( > > Done. Really good idea. I usually run at 1280x1024 and admit I > tend not to think about lower resolutions. :( > > Actually, I think I might just do this instead of tabs. > I should be able to make the scrolling view look good, too. > I have never tried anything like that so I'm going to have to get > back to you. Agree, this is a good idea. And as we have the common options listed first, it's rare that an user have to scroll down (only if he want to tweak special rare options of a module). A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Sun Aug 3 17:21:25 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 3 Aug 2003 11:21:25 -0400 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: References: Message-ID: <20030803152125.GN220@brightrain.aerifal.cx> On Sun, Aug 03, 2003 at 07:25:23AM +0000, Charles Ezell wrote: > > >On Sat, Aug 02, 2003 at 04:47:49PM -0300, Gustavo Sverzut Barbieri wrote: > >> Wouldn't be easier if we use something like libglade to design the ui? > >> > >> I mean, it's good to have a window builder, but they can become ugly > >> and non functional at a certain point, if no layout info is provided to > >> it. > >> > >> However, putting too much layout info in mplayer's config would bloat > >> it. > >> > >> What about have a window builder that constructs glade's xml and then > >> one could go there and manually tweak the look. > >> Mplayer gtk ui could be as easy as calling libglade! > > > >How incredibly bloated. Something like glade is for people who don't > >know how to code... > > > >Rich > > lol. > > You're not serious, are you? I appologize if you are making a joke, > I'm new here and still getting to know people. > > For those who do not know, libglade allows the creation of a GTK window and > its > controls from an xml file. It is the exact opposite of code bloat... Bloat is not just code size. It's also binary size, data size, and speed. The bloat here is requiring libglade, libxml, etc. for a movie player! For goodness sake!! Look how massive and slow mozilla is by using its horrible gui layout language rather than just coding the gui native. I'm sure libglade is nowhere near as bad, but the whole thing is just dumb in principle. Especially if you have to write the code in C already to build a gui from exported config data. WTF is the point of writing mplayer config -> xml converter, then using glade to build the gui? You could just build the gui direct from the config data... Sorry if I sound overly fussy or argumentative. That's not my purpose. But mplayer does things a lot different than the other players out there, with minimal dependencies and bloat. Unlike xine, cat /proc/`pidof mplayer`/maps doesn't spew out 300+ lines... I don't want to discourage you from working on this -- myself and many others don't care about gui, so it's not our place to control how you write it -- but at the same time I don't like to see senseless bloat and slowness in the gui giving mplayer a bad reputation (like the current G1 gui does...) Rich From FabianFranz at gmx.de Sun Aug 3 17:44:42 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 3 Aug 2003 17:44:42 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030803152125.GN220@brightrain.aerifal.cx> References: <20030803152125.GN220@brightrain.aerifal.cx> Message-ID: <200308031744.45817.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > For those who do not know, libglade allows the creation of a GTK window > > and its > > controls from an xml file. It is the exact opposite of code bloat... > > Bloat is not just code size. It's also binary size, data size, and > speed. The bloat here is requiring libglade, libxml, etc. for a movie > player! For goodness sake!! Look how massive and slow mozilla is by > using its horrible gui layout language rather than just coding the gui > native. I'm sure libglade is nowhere near as bad, but the whole thing > is just dumb in principle. Especially if you have to write the code in > C already to build a gui from exported config data. WTF is the point > of writing mplayer config -> xml converter, then using glade to build > the gui? You could just build the gui direct from the config data... > Hm, it worked differently last time I saw a program that used glade ... You take xml-Files and glade makes C-Files/Objs out of it ... So no necessary bindings to libglade, libxml or whatever ... cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/LS3sI0lSH7CXz7MRAkd8AJ4stmXRU02nX/w27fot0CIrsOUFhACfQLsv qmZ6dC0qn81Q5uz18g0KEDw= =GDi6 -----END PGP SIGNATURE----- From arpi at thot.banki.hu Sun Aug 3 18:25:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 3 Aug 2003 18:25:50 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <200308031744.45817.FabianFranz@gmx.de> Message-ID: <200308031625.h73GPoRZ019377@mail.mplayerhq.hu> Hi, > > Bloat is not just code size. It's also binary size, data size, and > > speed. The bloat here is requiring libglade, libxml, etc. for a movie > > player! For goodness sake!! Look how massive and slow mozilla is by > > using its horrible gui layout language rather than just coding the gui > > native. I'm sure libglade is nowhere near as bad, but the whole thing > > is just dumb in principle. Especially if you have to write the code in > > C already to build a gui from exported config data. WTF is the point > > of writing mplayer config -> xml converter, then using glade to build > > the gui? You could just build the gui direct from the config data... > > > > Hm, it worked differently last time I saw a program that used glade ... > > You take xml-Files and glade makes C-Files/Objs out of it ... > > So no necessary bindings to libglade, libxml or whatever ... but the main idea here si to build gui in runtime, so loading new (unknown) plugins and configuring them via the gui will work too. > > Fabian welcome back. what about the stream/demux metadata/playlist export we talked about last time, before you disappeared? :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Sun Aug 3 18:43:06 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 3 Aug 2003 18:43:06 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <200308031625.h73GPoRZ019377@mail.mplayerhq.hu> References: <200308031625.h73GPoRZ019377@mail.mplayerhq.hu> Message-ID: <200308031843.22515.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Sonntag, 3. August 2003 18:25 schrieb Arpi: > Hi, > > > > Bloat is not just code size. It's also binary size, data size, and > > > speed. The bloat here is requiring libglade, libxml, etc. for a movie > > > player! For goodness sake!! Look how massive and slow mozilla is by > > > using its horrible gui layout language rather than just coding the gui > > > native. I'm sure libglade is nowhere near as bad, but the whole thing > > > is just dumb in principle. Especially if you have to write the code in > > > C already to build a gui from exported config data. WTF is the point > > > of writing mplayer config -> xml converter, then using glade to build > > > the gui? You could just build the gui direct from the config data... > > > > Hm, it worked differently last time I saw a program that used glade ... > > > > You take xml-Files and glade makes C-Files/Objs out of it ... > > > > So no necessary bindings to libglade, libxml or whatever ... > > but the main idea here si to build gui in runtime, so loading new (unknown) > plugins and configuring them via the gui will work too. yeah :-) > > > Fabian > > welcome back. what about the stream/demux metadata/playlist export we > talked about last time, before you disappeared? :) :) Had some stuff to do, to get popular on LinuxTag with Knoppix on Mac ... ;-) ok, back on topic ... I'm still interested in this development. However its a hard task to do a specification ... I would like to have something transparent and extensionable ... So that for the structure it does not matter if it is a CD, a DVD or a url ... Hm, but thats not easily possible ... And that was the point in my thinking where I got stuck ... Perhaps we could do again a brainstorming based on the previous work ... cu Fabian > > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/LTupI0lSH7CXz7MRAln6AJ9YlvnzTpcbimKLY89flMhDAi5Q9ACfdjWL +8i8p5BhTNpJXJJnYQuIRSI= =S1rE -----END PGP SIGNATURE----- From gsbarbieri at yahoo.com.br Sun Aug 3 18:54:43 2003 From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=) Date: Sun, 3 Aug 2003 13:54:43 -0300 (ART) Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <20030803165443.18056.qmail@web20907.mail.yahoo.com> --- Charles Ezell escreveu: > > Gustavo writes: > > >Yes, I know that... win32 is the other way (coordinates-based) and I > >don't know Mac to tell... > > Don't know either. :) But it is probably coord based. I was also > thinking > about Qt (which I know next to nothing about). QT works the same way gtk does, vertical and horizontal layout boxes. > > > Second, if I understand A'rpi correctly, is that the whole system > > > is supposed to be dynamic. If I do my job correctly, > > > you guys should be able to add dozens of modules to mplayer and > the > > > users > > > will not have to upgrade the GUI. This isn't going to be > possible > > > if xml tweaking is involved. > > > >How dynamic it would be... it will generate those windows at compile > >time or at run time? > > Run time. Completely dynamic. Also, I only want to create windows > as > they are needed. Cool! > Example: (please see gedit2's prefs for a visual of the layout, if > possible) In their site they don't have screenshots about the prefs. Could you send me some in private (outside the list)? > you open the preferences and it generates the first > page (because it is showing) but nothing else. Then you click on > "Audio" (I am going to need help with internationalization) > from the list on the left and it will create and show the > audio options, complete with a list of audio plugins. Fun, huh? Hum... I din't quite understood that :( And about translators, you have one: I'm Brazilian, so we can have pt_BR > > > > Third, the core gui builder code isn't that complex and > > > the config design is well thought out. This makes things much > > > easier. > > > If I run into problems, we'll work things out. > > > >My only hope is that the ui doesn't become something unlogical and > >non-intuitive... sometimes it's better to put things together > because > >they're related, but doesn't worth to put them in a Frame or a > Tab... > >so maybe we can have at least 2 kind of groups: Visual (Frames, > Tabs) > >and Non-Visual.... or 3: Frames, Tabs, Non-Visual... > > Any ideas on that? > > I do not want that either. > > Yep. First I'm going to avoid tabs. If there are so many options > they have to be used OK (like if one group of options is really > large), > but hopefully that won't be often. Sometimes we have to get some, like those in mplayer g1. I'm wrong? > Second, a frame in GTK is a group box in win32. Does this help? > Even a single item can look good in a frame (Anjuta's preferences are > proof of that...) I know about frames in gtk, and don't know nothing about win32 group boxes :) What I think is that sometimes you may have to groups things together as I said and if all the grouping is visible (like a frame), you will get many frames inside other and that's ugly :) > Third, I'm hoping to have unamed / anonymous groups. So if I group > of > options doesn't fit anywhere else they can be grouped together > (probably > without a frame / box). Ok > Fourth: What did you mean by non-visual? Only logical, they're put together but we don't have a frame around them. > >Also, maybe we could have the tab-order specified somewhere, so we > can > >arrange items based on that order... maybe that list could be other > >place... > > I think the options should be in the same order as in the config_t. It's an option! :) > If you mean for the case where there are so many options several tabs > are > needed, then that is worth thinking about. Since I would be > generating tabs > on the fly it would be next to impossible to come up with good names > for > them. > 1, 2, 3 does not cut it. Yes... maybe we could have a string as the name of the group, if the group is too large, it's dettached to a tab with that name? > I think maybe you have best solution below. :) > >And (just to make you crazy ;) sometimes it's cool to have small > items > >arranged in 2/3 columns > > I was actually planning to do that. :) Not necessarily based on > size, > but on how many options there are. Not based on size because of the > way GTK > works. Coll... but if there should be a selection(combo) box? > This is definatley going to take some work. Sure! :) > > > >But, there comes a problem: how to keep track from human > (manual) > > > >interventions? Maybe the window builder could try to keep the > old > > > >layout (and maybe learn with it). Maybe we could keep the manual > > > >changes as patches and apply it over and over (ugly, but > easier). > > > > > > That would be very hard to do and maintain. I am probably going > to > > > have > > > to write some algorithms for control placement (mainly how many > > > controls on > > > a > > > page is too many), I will tweak those as necessary. > > > The most important thing is not jamming stuff together. > > > >IDEA: Every page you put, please I beg you to use a scroll-able > content > >(automatic scrollbars), so if someone have a 800x600 with big fonts, > >things that generally looks well in 1024x768 will probably overflow > the > >screen... that happens a lot with linux gui apps :( > > Done. Really good idea. I usually run at 1280x1024 and admit I > tend not to think about lower resolutions. :( > > Actually, I think I might just do this instead of tabs. Again, I didn't understood what you say about gedit2 prefs, so maybe I misunderstanding things... But, only one page with all options inside it sucks very hard :) > I should be able to make the scrolling view look good, too. > I have never tried anything like that so I'm going to have to get > back to you. Ok. It's something like adding a viewport as the base widget and setting the scrollbars to automatic (maybe just the vertical if you don't want horizontal ones) Gustavo _______________________________________________________________________ Conhe?a o novo Cad?? - Mais r?pido, mais f?cil e mais preciso. Toda a web, 42 milh?es de p?ginas brasileiras e nova busca por imagens! http://www.cade.com.br From arpi at thot.banki.hu Sun Aug 3 19:14:26 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 3 Aug 2003 19:14:26 +0200 Subject: [MPlayer-G2-dev] playtree export structure [Was: Re: Developing a GTK2 GUI] In-Reply-To: <200308031843.22515.FabianFranz@gmx.de> Message-ID: <200308031714.h73HEQfc028872@mail.mplayerhq.hu> Hi, ps: don't cc: me, i'm subscribed :) > > welcome back. what about the stream/demux metadata/playlist export we > > talked about last time, before you disappeared? :) > > :) Had some stuff to do, to get popular on LinuxTag with Knoppix on Mac ... > ;-) you could meet other mplayer developers there (@linuxtag) :) > ok, back on topic ... > > I'm still interested in this development. > > However its a hard task to do a specification ... > > I would like to have something transparent and extensionable ... > > So that for the structure it does not matter if it is a CD, a DVD or a url ... yes > Hm, but thats not easily possible ... yes > And that was the point in my thinking where I got stuck ... :( > Perhaps we could do again a brainstorming based on the previous work ... sure. I think we should try to define what do we want to reach, ie. what kind of data it have to contain, mayeb with examples. It truned out to be helpful for API design in practice, at least to me. So, as a start, I try to list what kind of media we support already: - cdda/cddb: 1-D list of tracks, with the usual stuff (length, title etc) - dvd: 2 level depth tree, dvd "titles" at top level, chapters bellow it. also, alternatives (multiple angles) possible for titles. - dvb/mpeg-ts: 1-D list of "programs", ie. pairs of audio and video channels - ascii playlists (.pls, .asx, .ram etc): 1-D or hierarchical (tree) structure of files. alternatives (different bitrate/quality of same media) possible. - "reference movie" (quicktime .mov files): 1-D (?) list of titles, alternatives (multiple resolution/bitrate/player version) possible >From this, we "just" need a tree design, where 2 kind of "children" exists: - real children (nodes, which define different content) - alternatives So sth like: typedef struct entry_s { char* name; // to be displayed in gui playlist editor / menu demux_metadata_t meta; URL_t* url; struct entry_s * children; // or call it 'nodes' struct entry_s * alternatives; struct entry_s * next; // for linked list } entry_t; But probably this is too simplified... Any better ideas? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From gabucino at mplayerhq.hu Sun Aug 3 19:08:13 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Sun, 3 Aug 2003 19:08:13 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: References: Message-ID: <20030803170813.GA2945@woodstock.localdomain> Charles Ezell wrote: > -rwxr-xr-x 1 root root 104k Apr 19 01:09 libglade-2.0.so.0.0.1 > > libglade is not incredibly bloated. Hell, it doesn't even fit into my Commodore Plus/4's memory. -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From lgb at lgb.hu Sun Aug 3 19:25:49 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Sun, 3 Aug 2003 19:25:49 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030803170813.GA2945@woodstock.localdomain> References: <20030803170813.GA2945@woodstock.localdomain> Message-ID: <20030803172549.GB19613@vega.digitel2002.hu> On Sun, Aug 03, 2003 at 07:08:13PM +0200, gabucino at mplayerhq.hu wrote: > Charles Ezell wrote: > > -rwxr-xr-x 1 root root 104k Apr 19 01:09 libglade-2.0.so.0.0.1 > > > > libglade is not incredibly bloated. > Hell, it doesn't even fit into my Commodore Plus/4's memory. Yes it DOES, plus4's memory scheme allows easy upgrade ability, upto 256Kbyte IIRC ;-) [or more with custom additional hardware components] - G?bor (larta'H) From nsabbi at libero.it Sat Aug 2 19:39:17 2003 From: nsabbi at libero.it (Nico) Date: Sat, 02 Aug 2003 19:39:17 +0200 Subject: [MPlayer-G2-dev] Communication between layers? Message-ID: <3F2BF745.2040101@libero.it> Hi, it seems my message wan never delivered nor archived, so here it is again. The question is: is there an api to permit 2-way communication between layers (stream and demuxer in my case)? An application (that I care for) is: 1) the dvb input module opens the device and sets filters for pids 160 (V), 80 (A), eventually 500 (subs) and 0 (for PAT, that I'm working on) 2) the ts_demuxer queues the usual a/v/s content to the respective fifos and parses the PAT to find the PMT(same as above) pids 3) at this point ts_demux needs more TS pids: the ones corresponding to the PMTs found in the PAT, so it needs to ask the dvb stream module to add more pids to the stream. How to do it? 4) the dvb module tries to obey and needs to report the exit code to the demuxer 5) ts_demux needs to parse the PMTs and can decide to add or remove certain pids from the stream; it can also tell the dvb module that there are more channels available in the same frequency or what's the map of the other frequencies found in the NIT (i'm overly optimistic in this case). Thanks, Nico From arpi at thot.banki.hu Sun Aug 3 19:56:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 3 Aug 2003 19:56:05 +0200 Subject: [MPlayer-G2-dev] Communication between layers? In-Reply-To: <3F2BF745.2040101@libero.it> Message-ID: <200308031756.h73Hu55v007041@mail.mplayerhq.hu> Hi, > The question is: is there an api to permit 2-way communication between > layers (stream and demuxer in my case)? control() > An application (that I care for) is: > > 1) the dvb input module opens the device and sets filters for pids 160 > (V), 80 (A), eventually 500 (subs) and 0 > (for PAT, that I'm working on) > 2) the ts_demuxer queues the usual a/v/s content to the respective fifos > and parses the PAT to find the PMT(same as above) pids > 3) at this point ts_demux needs more TS pids: the ones corresponding to > the PMTs found in the PAT, so it needs to ask the > dvb stream module to add more pids to the stream. How to do it? > 4) the dvb module tries to obey and needs to report the exit code to the > demuxer > 5) ts_demux needs to parse the PMTs and can decide to add or remove > certain pids from the stream; > it can also tell the dvb module that there are more channels > available in the same frequency > or what's the map of the other frequencies found in the NIT (i'm > overly optimistic in this case). I think by default you should filter only the PAT in stream layer. The demuxer can parse it, and export the data in a form of playlist. So the user can select the wanted program and re-open teh device, giving the program id (or stream ids) as parameter in the URL. The other way is calling demux->stream->control() from ts demuxer to communicate with the stream layer, but i think it's not so clean. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ardneh2 at hotmail.com Mon Aug 4 00:11:04 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Sun, 03 Aug 2003 22:11:04 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Hi, Richard Felker III writes: > > You're not serious, are you? I appologize if you are making a joke, > > I'm new here and still getting to know people. > > > > For those who do not know, libglade allows the creation of a GTK window >and > > its > > controls from an xml file. It is the exact opposite of code bloat... > >Bloat is not just code size. It's also binary size, data size, and >speed. I know, I was simply trying the quick answer first. :) The real answer is that libglade is not bloated because it takes redundant code out of applications that use it. LOTS of redundant code --the creation and layout of windows and their components. If you think about it this way, you will realize that even _if_ libglade was twice as large as it needed to be it would still be saving an order of magnitude more code in applications that use it _and_ it would keep save more every time a new application used it. Now that is what I call a good deal. As for speed, that usually comes down to using the correct algorithms and data structures for the job. Please see the bottom of the page here: http://xmlsoft.org/ For exactly how fast libxml is in comparison to other xml libs. >The bloat here is requiring libglade, libxml, etc. for a movie >player! For goodness sake!! This really isn't a big deal. Libxml is a standard GNOME lib. Please see below. >Look how massive and slow mozilla is by >using its horrible gui layout language rather than just coding the gui >native. I'm sure libglade is nowhere near as bad, but the whole thing Please never bring up XUL... ;) Never thought I'd agree with you so quickly. Libglade is completely different than XUL. They are not comparable. (BTW, mozilla is getting much better and you do have the option to use (wrapped) native controls. I always build moz with GTK2 support. Firebird has gotten rid of a ton of the bloat as well.) >is just dumb in principle. Especially if you have to write the code in >C already to build a gui from exported config data. WTF is the point >of writing mplayer config -> xml converter, then using glade to build >the gui? You could just build the gui direct from the config data... Yes, you have summed up my argument exactly. Please see my other posts, I thought I made that clear. :( I am not going to use libglade for the config code and probably will not use it for anything else, either. I do not want win32 users to have libglade as well as the GTK libs. I am doing my best to consider everyone who would be using a GTK UI. And everyone who might need to look at my code to write other GUIs. >Sorry if I sound overly fussy or argumentative. That's not my purpose. It's not being argumentative that I care about. It's making broad assumptions about how bloated things are. >But mplayer does things a lot different than the other players out Yes, mplayer works. I don't use xine because 1) when I was first looking for a movie player years ago (geez, has it been that long?) all xine did was crash and 2) now, Totem, a GTK2 ui for libxine, doesn't start unless I delete one of its config files and sometimes I even have to use gconf! >there, with minimal dependencies and bloat. Unlike xine, cat Keep in mind, nothing I do is going to change that. First, the gui really is separate and should be. Second, using libraries does not make otherwise good code bloated. Third, you bring up the real issue below. >/proc/`pidof mplayer`/maps doesn't spew out 300+ lines... I don't want >to discourage you from working on this -- myself and many others don't >care about gui, so it's not our place to control how you write it -- >but at the same time I don't like to see senseless bloat and slowness >in the gui giving mplayer a bad reputation (like the current G1 gui >does...) I think the basic problem here is that you and others are concerned the GTK2 GUI is going to be like the first one. It is not. I spent over a week porting that to GTK2 and it became very clear that a lot of things were done that didn't need to be. It could have been much smaller, simpler and more portable. Part of the reason I am here is to make sure no one gets desparate and tries to use that for G2. I know, now, that I need never have worried. You don't have a chance of discouraging me. :) MPlayer is the best movie player I have used on any platform. It might not have a fancy playlist editor (yet) but it does what's important: it plays just about every type of video file and it plays them well. On windows you have to install lots of codec packs to even come close to playing what mplayer does --and then you still end up using multiple players. My goal is to write a maintainable, portable, featureful, fast and good looking GUI to show off MPlayer-G2 and to encourage others to use it in their programs instead of choosing some other library / framework. Maybe even be _the_ GNOME video/media player. (Why not think big?) Also, even though you don't seem to care about it, I am interested in your point of view. As a final note, I'd like to ask everyone to please move the old GUI to the back of their minds, if possible. I'm glad Pontscho wrote it, especially using GTK, because otherwise I probably wouldn't have started using MPlayer. And I certainly would not be here. However, we're starting from scratch and we know the old mistakes --so I don't see why they should come up again. >Rich The clarification of your opinion was much appreciated. Thank you, -Charles _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From arpi at thot.banki.hu Mon Aug 4 00:50:53 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 00:50:53 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: <200308032250.h73MorUV026882@mail.mplayerhq.hu> Hi, > >But mplayer does things a lot different than the other players out > > Yes, mplayer works. I don't use xine because 1) when I was first looking > for a movie player years ago (geez, has it been that long?) all xine did was > crash and 2) now, Totem, a GTK2 ui for libxine, doesn't start unless I > delete one > of its config files and sometimes I even have to use gconf! lol :) I've tried xine a year ago, and it look good, until i pressed play :) I liked its preferences window, it build Xvideo config dialog at runtime, by querying Xv attribs (like xvinfo) and used them to setup bars. (at least it looked so, i'm not 100% sure it was really runtime built or they were just tricky again, as usual...) It gave me the idea of runtime built config windows... > I think the basic problem here is that you and others > are concerned the GTK2 GUI is going to be like the first one. I really hope it won't. > I spent over a week porting that to GTK2 and it became > very clear that a lot of things were done that didn't need to be. > It could have been much smaller, simpler and more portable. Ok, time to tell teh big secret to you :) The original Gui (in v0.50) of g1 did not use gtk at all! It used Xlib only, and Pontscho wrote a skinned toolkit-like thing for it. If you look at old g1 skins, you'll see even the popup menus pre-drawn in .png. It worked for a while, until things like dinamically changed menus (like audio/vidoe ID, dvd title selectable in menu), and fileselector requirement came up. Ponstcho didn't want to code a so complex toolkit for his skin engine, so he started to hack gtk support in. Afair there wasn't gtk2 yet that times. Later more and more parts of his skinned stuff was replaced by gtk functions, and the things got more messy and ugly... you see the result. I think, if he start with gtk at first day, or he implements complex toolkit elements in his xlib-based skinned engine, it woudl be better, than this mixed gtk+xlib hack. To make things even worse, he wanted it to look very good (which wasn't possible with gtk1 afaik, i mean non-rectangular gui window etc), but the gui development was sponsored for a while by UHU Linux, given a deadline. So he had no time to mess more with xlib, he used gtk... > Part of the reason I am here is to make sure no one gets desparate and tries > to use that for G2. I know, now, that I need never have worried. :) > You don't have a chance of discouraging me. :) Nice to hear! I've never wanted g1's gui to be ported to g2, and as i'm not a gui coder (and i don't even want to be), i designed g2 to be ui-independent, so that many ppl who started coding guis/frontends for g1 (and failed due to g1's monolitic design) can do it now. Btw I have some crazy(?) ideas for the g2 gtk2 gui, for example a mode when it starts without a gui window, like the commandline player (and even gets options/filenames etc from commandline) but some mouse click or hotkey can bring up config windows/preferences so filters, plugins can be configured runtime in an user-friendly interface, even for commandline-liker users like me or Rich. (Rich: it's quite hard to control (and display) a 24-band audio equalizer from commandline...) I think with a well-written layered gui it's easily doable. > MPlayer is the best movie player I have used on any platform. :) > It might not have a fancy playlist editor (yet) but it does > what's important: it plays just about every type of video file and it > plays them well. And it does it a lot better in G2. The A-V sync engine improved a lot, and i'll code better demuxers for G2, including AVI demuxer which allows seeking without index, correct mpeg vs. mp3 detection (done), native .ogg demuxer (done) and so on. Actually decoding multiple streams at the same time, or stream/codec switching without stopping/restarting playback is possible with g2. > On windows you have to install lots of codec packs > to even come close to playing what mplayer does --and then you still end up > using multiple players. I've recently "installed" (unpacked to a dir) mplayer for a friend, and since that he is only using that for any file :) And it doesn't even have a gui (on win32)... > My goal is to write a maintainable, portable, featureful, fast and good looking > GUI to show off MPlayer-G2 and to encourage others to use it in their programs > instead of choosing some other library / framework. Great! A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon Aug 4 03:34:23 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 3 Aug 2003 21:34:23 -0400 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <200308032250.h73MorUV026882@mail.mplayerhq.hu> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> Message-ID: <20030804013423.GQ220@brightrain.aerifal.cx> On Mon, Aug 04, 2003 at 12:50:53AM +0200, Arpi wrote: > Btw I have some crazy(?) ideas for the g2 gtk2 gui, for example a mode > when it starts without a gui window, like the commandline player > (and even gets options/filenames etc from commandline) but some mouse > click or hotkey can bring up config windows/preferences so filters, > plugins can be configured runtime in an user-friendly interface, even > for commandline-liker users like me or Rich. > (Rich: it's quite hard to control (and display) a 24-band audio equalizer > from commandline...) Yes but it's also very hard to open a gtk window when there's no dfb or X server running. :) On the other hand, osd-menu based audio equalizer would be quite nice. :))) > > It might not have a fancy playlist editor (yet) but it does > > what's important: it plays just about every type of video file and it > > plays them well. > > And it does it a lot better in G2. > The A-V sync engine improved a lot, and i'll code better demuxers for G2, > including AVI demuxer which allows seeking without index, correct > mpeg vs. mp3 detection (done), native .ogg demuxer (done) and so on. > Actually decoding multiple streams at the same time, or stream/codec > switching without stopping/restarting playback is possible with g2. > > > On windows you have to install lots of codec packs > > to even come close to playing what mplayer does --and then you still end up > > using multiple players. > > I've recently "installed" (unpacked to a dir) mplayer for a friend, and > since that he is only using that for any file :) > And it doesn't even have a gui (on win32)... Yes, several people I know now have win32 mplayer on their desktop and just drag files onto it. :) > > My goal is to write a maintainable, portable, featureful, fast and good looking > > GUI to show off MPlayer-G2 and to encourage others to use it in their programs > > instead of choosing some other library / framework. > > Great! Agree! Rich From arpi at thot.banki.hu Mon Aug 4 03:37:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 03:37:05 +0200 Subject: [MPlayer-G2-dev] new release: pre39 Message-ID: <200308040137.h741b5qG030681@mail.mplayerhq.hu> Hi, http://mplayerhq.hu/~arpi/g2/mplayer-G2-preview39.tar.gz this is a big cleanup release, cleanup of A-V sync code in test-play.c i think now i'm close to be able to separate A-V sync to separate file. i've also fixed several problems, and added some benchmarking, see bellow: ChangeLog: pre39: - test-play.c: A-V sync correction code moved to sleep-time calculation. It simplified things a bit, and frame_time_remaining could be removed. At the same time, it's "fixed" to use the wanted sleep time instead of the actual sleep time, as we don't want to correct timer's errors by delaying streams. (timer's error is some small random value, depending on OS-dep timer implementation) - Implemented Rich's idea for inverse soft-telecine in vd_libmpeg2.c (later may can be moved to a filter) - Implemented Albeu's timer hack in vo_fbdev.c using FBIO_WAITFORVSYNC ioctl -> libvo2 API changed, pts is unsigned int (and is in microsecs), not float! - bugfix: autosync now merges corrections (from sndcard) back to time_pos - fix/cleanup: stream sync is now calculated from difference of sh_audio->delay and a_pts-v_pts. (previously time_frame and delay were included too, badly) - simple framedropping implemented (not finished yet), works for libmpeg2. - etc/codecs.conf included (note: not compatible with G1!) - TOOLS/cpuinfo.c added, for ./configure.g1 under win32. - pause (space, p) implemented - some A/V benchmarking added. A+V statusline changed, now it displays: video fps --v v-- A-V sync: effective/streams(corrected by) A: 165.311 V: 161.118 (29.970) A-V:+4.193/-0.0000(-0.0000) 102%(216%) ^---------^--- audio+video PTS CPU usage--->> avg^ max^ Note: The effective A-V sync is the delay what you can actualy see/hear. When this number goes up, it means that your CPU/VGA is probably too slow... If this isn't constant 0, but floating around zero, it means your timer (be it soundcard or system timer, depending on -autosync) is inaccurate! The 'streams A-V sync' (the second number after A-V:) is the actual difference of the audio and video stream timers. It should be zero, non-zero value means one of the streams (or both) run at wrong rate. It may be problem of codec, demuxer or even the file may be broken. This isn't influenced by slow cpu, inaccurate timers, broken sound drivers! The 3rd number in ( ) is the old ct: value, ie. the total corrected stream A-V delay (ie. value added to timer delay to compensate PTS delay). A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From joey at nicewarrior.org Mon Aug 4 04:56:36 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Sun, 3 Aug 2003 21:56:36 -0500 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030804013423.GQ220@brightrain.aerifal.cx> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> <20030804013423.GQ220@brightrain.aerifal.cx> Message-ID: <20030804025636.GA12182@nicewarrior.org> On Sun, Aug 03, 2003 at 09:34:23PM -0400, D Richard Felker III wrote: > > I've recently "installed" (unpacked to a dir) mplayer for a friend, and > > since that he is only using that for any file :) > > And it doesn't even have a gui (on win32)... > > Yes, several people I know now have win32 mplayer on their desktop and > just drag files onto it. :) Are we talking about out of the box cygwin mplayer or the packages I've been making? Because if there are more people out there using them, I could use some feedback, especially from non-linux people. Thanks, --Joey From dalias at aerifal.cx Mon Aug 4 08:40:47 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 4 Aug 2003 02:40:47 -0400 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030804025636.GA12182@nicewarrior.org> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> <20030804013423.GQ220@brightrain.aerifal.cx> <20030804025636.GA12182@nicewarrior.org> Message-ID: <20030804064047.GR220@brightrain.aerifal.cx> On Sun, Aug 03, 2003 at 09:56:36PM -0500, Joey Parrish wrote: > On Sun, Aug 03, 2003 at 09:34:23PM -0400, D Richard Felker III wrote: > > > I've recently "installed" (unpacked to a dir) mplayer for a friend, and > > > since that he is only using that for any file :) > > > And it doesn't even have a gui (on win32)... > > > > Yes, several people I know now have win32 mplayer on their desktop and > > just drag files onto it. :) > > Are we talking about out of the box cygwin mplayer or the packages I've > been making? Because if there are more people out there using them, I > could use some feedback, especially from non-linux people. Some out-of-the-box, some from mphq releases directory. Is that your package? Rich From dalias at aerifal.cx Mon Aug 4 08:52:13 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 4 Aug 2003 02:52:13 -0400 Subject: [MPlayer-G2-dev] new release: pre39 In-Reply-To: <200308040137.h741b5qG030681@mail.mplayerhq.hu> References: <200308040137.h741b5qG030681@mail.mplayerhq.hu> Message-ID: <20030804065213.GS220@brightrain.aerifal.cx> On Mon, Aug 04, 2003 at 03:37:05AM +0200, Arpi wrote: > - Implemented Rich's idea for inverse soft-telecine in vd_libmpeg2.c > (later may can be moved to a filter) Yes, that can be the first filter to demonstrate how to use the exported tff/rff flags. :)) > - Implemented Albeu's timer hack in vo_fbdev.c using FBIO_WAITFORVSYNC ioctl > -> libvo2 API changed, pts is unsigned int (and is in microsecs), not float! How about units of 1/1001000 sec? :)) OK maybe not. BTW, is this just relative pts, or absolute? With 32bit int, you only have room for ~4000 seconds before you wrap....and many movies are longer than that! BTW2, this would suggest that the float-based method was also very imprecise... BTW3, are you sure these inexact methods are ok for encoding and stuff, rather than just playing movies? > - etc/codecs.conf included (note: not compatible with G1!) Hmm, how about do like G1 and compile it into the binary? Somehow I suspect having the G2 codecs.conf installed will keep G1 from working... > video fps --v v-- A-V sync: effective/streams(corrected by) > A: 165.311 V: 161.118 (29.970) A-V:+4.193/-0.0000(-0.0000) 102%(216%) > ^---------^--- audio+video PTS CPU usage--->> avg^ max^ Is framerate really important? > Note: The effective A-V sync is the delay what you can actualy see/hear. > When this number goes up, it means that your CPU/VGA is probably too slow... > If this isn't constant 0, but floating around zero, it means your timer > (be it soundcard or system timer, depending on -autosync) is inaccurate! > > The 'streams A-V sync' (the second number after A-V:) is the actual > difference of the audio and video stream timers. It should be zero, > non-zero value means one of the streams (or both) run at wrong rate. > It may be problem of codec, demuxer or even the file may be broken. > This isn't influenced by slow cpu, inaccurate timers, broken sound drivers! Very nice to be able to tell the difference! Rich From arpi at thot.banki.hu Mon Aug 4 09:11:31 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 09:11:31 +0200 Subject: [MPlayer-G2-dev] new release: pre39 In-Reply-To: <20030804065213.GS220@brightrain.aerifal.cx> Message-ID: <200308040711.h747BVZf000663@mail.mplayerhq.hu> Hi, > On Mon, Aug 04, 2003 at 03:37:05AM +0200, Arpi wrote: > > - Implemented Rich's idea for inverse soft-telecine in vd_libmpeg2.c > > (later may can be moved to a filter) > > Yes, that can be the first filter to demonstrate how to use the > exported tff/rff flags. :)) :) > > - Implemented Albeu's timer hack in vo_fbdev.c using FBIO_WAITFORVSYNC ioctl > > -> libvo2 API changed, pts is unsigned int (and is in microsecs), not float! > > How about units of 1/1001000 sec? :)) OK maybe not. BTW, is this just nope > relative pts, or absolute? With 32bit int, you only have room for > ~4000 seconds before you wrap....and many movies are longer than that! it's absolute time counter truncated to 32 bits. it's far enough. no movies encoded at 1/4000 fps... > BTW2, this would suggest that the float-based method was also very it wasnt inprecise (or at least it was hidden by correction codes) but since all the system timer code work with microsecs, it was easier (and more accurate) this way. > imprecise... BTW3, are you sure these inexact methods are ok for > encoding and stuff, rather than just playing movies? thos 'inexact method' is for playback only. there are 2 time-spave now: - float/double based, for demuxer, codecs and filters - 1/1000000 sec based, for timing display and audio note that there is not 1000000:1 but 1000000:playback_speed mapping between them. > > - etc/codecs.conf included (note: not compatible with G1!) > > Hmm, how about do like G1 and compile it into the binary? Somehow I i don't remember why but i couldnt get that hack working in g2 at early days > suspect having the G2 codecs.conf installed will keep G1 from > working... no, g1 will ignore that codecs.conf, as being unparseable > > video fps --v v-- A-V sync: effective/streams(corrected by) > > A: 165.311 V: 161.118 (29.970) A-V:+4.193/-0.0000(-0.0000) 102%(216%) > > ^---------^--- audio+video PTS CPU usage--->> avg^ max^ > > Is framerate really important? no, but it's fun to see, esp. at mixed hard/soft telecined material :) you can guess it out, that this is a debug statusline, not a user-frindly one > > Note: The effective A-V sync is the delay what you can actualy see/hear. > > When this number goes up, it means that your CPU/VGA is probably too slow... > > If this isn't constant 0, but floating around zero, it means your timer > > (be it soundcard or system timer, depending on -autosync) is inaccurate! > > > > The 'streams A-V sync' (the second number after A-V:) is the actual > > difference of the audio and video stream timers. It should be zero, > > non-zero value means one of the streams (or both) run at wrong rate. > > It may be problem of codec, demuxer or even the file may be broken. > > This isn't influenced by slow cpu, inaccurate timers, broken sound drivers! > > Very nice to be able to tell the difference! :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon Aug 4 10:48:11 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 4 Aug 2003 04:48:11 -0400 Subject: [MPlayer-G2-dev] new release: pre39 In-Reply-To: <200308040711.h747BVZf000663@mail.mplayerhq.hu> References: <20030804065213.GS220@brightrain.aerifal.cx> <200308040711.h747BVZf000663@mail.mplayerhq.hu> Message-ID: <20030804084811.GV220@brightrain.aerifal.cx> On Mon, Aug 04, 2003 at 09:11:31AM +0200, Arpi wrote: > > relative pts, or absolute? With 32bit int, you only have room for > > ~4000 seconds before you wrap....and many movies are longer than that! > > it's absolute time counter truncated to 32 bits. it's far enough. > no movies encoded at 1/4000 fps... ?? > > BTW2, this would suggest that the float-based method was also very > > it wasnt inprecise (or at least it was hidden by correction codes) > but since all the system timer code work with microsecs, it was > easier (and more accurate) this way. If a movie goes beyond ~4000 seconds, you'd be using 13 bits of the float for the integral part, leaving 11 bits for the fractional part. That's still 0.5 ms precision, so not too bad, but it could start generating bad timestamps encoding to variable-fps output formats. Also, there's the case where you're working with really long files, where the error could easily get as large as frame durations, so I'd be happier using doubles, at least wherever absolute pts is needed. For relative, float is certainly fine. > > imprecise... BTW3, are you sure these inexact methods are ok for > > encoding and stuff, rather than just playing movies? > > thos 'inexact method' is for playback only. By inexact I mean it's not based on the same time base as the file, but rather approximation by float or fixed point number. > there are 2 time-spave now: > - float/double based, for demuxer, codecs and filters > - 1/1000000 sec based, for timing display and audio Ahh, I see. > note that there is not 1000000:1 but 1000000:playback_speed mapping between them. :) > > suspect having the G2 codecs.conf installed will keep G1 from > > working... > > no, g1 will ignore that codecs.conf, as being unparseable :) > > > video fps --v v-- A-V sync: effective/streams(corrected by) > > > A: 165.311 V: 161.118 (29.970) A-V:+4.193/-0.0000(-0.0000) 102%(216%) > > > ^---------^--- audio+video PTS CPU usage--->> avg^ max^ > > > > Is framerate really important? > > no, but it's fun to see, esp. at mixed hard/soft telecined material :) Ah, but I thought the new code didn't change nominal framerate, just delay rff frames by 1/120 sec... > you can guess it out, that this is a debug statusline, not a user-frindly one Yes. Rich From arpi at thot.banki.hu Mon Aug 4 11:09:32 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 11:09:32 +0200 Subject: [MPlayer-G2-dev] new release: pre39 In-Reply-To: <20030804084811.GV220@brightrain.aerifal.cx> Message-ID: <200308040909.h7499Wwa029060@mail.mplayerhq.hu> Hi, > On Mon, Aug 04, 2003 at 09:11:31AM +0200, Arpi wrote: > > > relative pts, or absolute? With 32bit int, you only have room for > > > ~4000 seconds before you wrap....and many movies are longer than that! > > > > it's absolute time counter truncated to 32 bits. it's far enough. > > no movies encoded at 1/4000 fps... > > ?? the integer 1/1000000 res. counters are used to do timing between 2 frames. so unless you have an 1/4000 fps "movie" (i would call it very slow slideshow instead) it won't overflow :) > > > BTW2, this would suggest that the float-based method was also very > > > > it wasnt inprecise (or at least it was hidden by correction codes) > > but since all the system timer code work with microsecs, it was > > easier (and more accurate) this way. > > If a movie goes beyond ~4000 seconds, you'd be using 13 bits of the > float for the integral part, leaving 11 bits for the fractional part. > That's still 0.5 ms precision, so not too bad, but it could start Sure. This is why absolute PTS is in double, and float/int is used for inter-frame durations/relative pts only. > generating bad timestamps encoding to variable-fps output formats. > Also, there's the case where you're working with really long files, > where the error could easily get as large as frame durations, so I'd > be happier using doubles, at least wherever absolute pts is needed. then RTFS mp_image.h ;) > For relative, float is certainly fine. sure. > By inexact I mean it's not based on the same time base as the file, > but rather approximation by float or fixed point number. yes, but since realtime timers (usleep, rtc and so on) are 1/1000000 based i nee dto convert to that base to do teh actual timing. and no human will be able to see the difference between 1us and 1.024 us, but not even 1us and 10us i think. > > no, but it's fun to see, esp. at mixed hard/soft telecined material :) > > Ah, but I thought the new code didn't change nominal framerate, just > delay rff frames by 1/120 sec... actually there is no thing as framerate in g2, only relative pts (or duration). so actually it prints 1/duration... (it printed duration in ms before, but fps loosk better) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon Aug 4 11:14:34 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 4 Aug 2003 12:14:34 +0300 Subject: [MPlayer-G2-dev] Re: Developing a GTK2 GUI In-Reply-To: <200308021140.h72BetHB016484@mail.mplayerhq.hu> References: <200308021140.h72BetHB016484@mail.mplayerhq.hu> Message-ID: <20030804091434.GB88993@lucky.net> Hi, Arpi! Sometime (on Saturday, August 2 at 14:31) I've received something... >I think there wont be too much things. >But it's sometimes possible that a module/plugin have options of type >module_list_t, ie. a selection of other plugins/modules. >I think this could be represented in gui by a pair of list boxes, the >selected plugins on the left side, and the list of available modules (of >that type) on right side. Then user can drag'n'drop (or other way >add/remove) items from right to left, and by double-clicking on left side >elements they can configure tehse modules (by pop-up new cofnig window). >Or I'm just dreaming :))) I'm sure, you aren't dreaming! This is the same as I said when we discussed config API. You remember it, don't you? :) So I think it may be done with G2 and it'll done! :) For above - items in left window may be reordered (even in runtime, we discussed it too, it's about VFCTRL_SET_PARAMS control) and easily configured (pop-up dialog). So, about GUI - it unable to handle CONF_TYPE_STRING_LIST config options. I said it already. GUI will never know any of audio or video drivers or codecs. Never ever. List of these drivers/codecs is never present in main config_t structure. And it's first example but others may be anywhere in modules. Do some hacks to handle some option with personal handler is very bad - GUI maker cannot track all these options forever. It's the reason why I always wanted to get rid of CONF_TYPE_STRING_LIST type. Now you have the trouble with GUI. ;) With best wishes. Andriy. From danchr at daimi.au.dk Mon Aug 4 13:22:38 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Mon, 4 Aug 2003 13:22:38 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: Message-ID: On Sunday, August 3, 2003, at 10:37 AM, Charles Ezell wrote: > Gustavo writes: > >> Yes, I know that... win32 is the other way (coordinates-based) and I >> don't know Mac to tell... > > Don't know either. :) But it is probably coord based. I was also > thinking > about Qt (which I know next to nothing about). I am not a GUI developer, but maybe I can shed some light on how things work on Mac OS X: On Mac OS X, as you may have heard, there are two independent GUI APIs, commonly referred to as Cocoa and Carbon. Cocoa is an Objective-C API and comes from NeXT, and it's intended that GUIs aren't generated in code, but dynamically from UI files - it encourages complete separation between code and UI. Carbon is based on the old Mac OS APIs, and is C - but IMO ugly C. You usually write the GUI in code, but very few things are handled for you, and good Carbon GUIs are more rare than good Cocoa GUIs. Both are coordinate-based, but in Cocoa, you would usually design the elements in Interface Builder and if necessary use that in code. If anyone wants to write a native GUI for Mac OS X, I'd say they should use Cocoa, and try to keep it separate from the main MPlayer since there are lots of files you probably wouldn't want to know about. Cocoa and Objective-C are fairly difficult to describe since they are very different from everything else out there, but they work quite well in practise. One good thing about Objective-C, though, is that it isn't C++ ;) - Dan Christiansen From gabucino at mplayerhq.hu Mon Aug 4 17:53:59 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Mon, 4 Aug 2003 17:53:59 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030804013423.GQ220@brightrain.aerifal.cx> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> <20030804013423.GQ220@brightrain.aerifal.cx> Message-ID: <20030804155359.GC1854@woodstock.localdomain> D Richard Felker III wrote: > Yes, several people I know now have win32 mplayer on their desktop and > just drag files onto it. :) Yes, me too. And nearly all of them are satisfied! I'm sometimes amazed. (some ppl miss sliders to seek with, but they are swiftly flamed by keyboard lovers;) -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From andrej at lucky.net Mon Aug 4 18:09:38 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 4 Aug 2003 19:09:38 +0300 Subject: [MPlayer-G2-dev] Re: Developing a GTK2 GUI In-Reply-To: <20030804155359.GC1854@woodstock.localdomain> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> <20030804013423.GQ220@brightrain.aerifal.cx> <20030804155359.GC1854@woodstock.localdomain> Message-ID: <20030804160938.GB86077@lucky.net> Hi, gabucino at mplayerhq.hu! Sometime (on Monday, August 4 at 18:55) I've received something... >D Richard Felker III wrote: >> Yes, several people I know now have win32 mplayer on their desktop and >> just drag files onto it. :) >Yes, me too. And nearly all of them are satisfied! I'm sometimes amazed. >(some ppl miss sliders to seek with, but they are swiftly flamed by >keyboard lovers;) I prefer keyboard arrows for seeking in the file to slider. I even could say I hate slider to seek in video, since I have to: 1) precisely position mouse cursor; 2) show seek bar on the screen. :P With best wishes. Andriy. From FabianFranz at gmx.de Mon Aug 4 19:55:58 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 4 Aug 2003 19:55:58 +0200 Subject: [MPlayer-G2-dev] playtree export structure [Was: Re: Developing a GTK2 GUI] In-Reply-To: <200308031714.h73HEQfc028872@mail.mplayerhq.hu> References: <200308031714.h73HEQfc028872@mail.mplayerhq.hu> Message-ID: <200308041956.03945.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Sonntag, 3. August 2003 19:14 schrieb Arpi: > Hi, > > ps: don't cc: me, i'm subscribed :) rofl :) :) ok > > > > welcome back. what about the stream/demux metadata/playlist export we > > > talked about last time, before you disappeared? :) > > > > > :) Had some stuff to do, to get popular on LinuxTag with Knoppix on Mac > > : ... > > > > ;-) > > you could meet other mplayer developers there (@linuxtag) :) yeah, I didn't know this as mplayer had no booth ... > > > ok, back on topic ... > > > > I'm still interested in this development. > > > > However its a hard task to do a specification ... > > > > I would like to have something transparent and extensionable ... > > > > So that for the structure it does not matter if it is a CD, a DVD or a > > url ... > > yes > > > Hm, but thats not easily possible ... > > yes > > > And that was the point in my thinking where I got stuck ... > > > :( > : > > Perhaps we could do again a brainstorming based on the previous work ... > > sure. > > I think we should try to define what do we want to reach, ie. what kind of > data it have to contain, mayeb with examples. It truned out to be helpful > for API design in practice, at least to me. > > So, as a start, I try to list what kind of media we support already: > - cdda/cddb: 1-D list of tracks, with the usual stuff (length, title etc) > - dvd: 2 level depth tree, dvd "titles" at top level, chapters bellow it. > also, alternatives (multiple angles) possible for titles. > - dvb/mpeg-ts: 1-D list of "programs", ie. pairs of audio and video > channels - ascii playlists (.pls, .asx, .ram etc): 1-D or hierarchical > (tree) structure of files. alternatives (different bitrate/quality of same > media) possible. - "reference movie" (quicktime .mov files): 1-D (?) list > of titles, alternatives (multiple resolution/bitrate/player version) > possible > > From this, we "just" need a tree design, where 2 kind of "children" exists: > - real children (nodes, which define different content) > - alternatives > > So sth like: > > typedef struct entry_s { > char* name; // to be displayed in gui playlist editor / menu > demux_metadata_t meta; > URL_t* url; > struct entry_s * children; // or call it 'nodes' > struct entry_s * alternatives; > struct entry_s * next; // for linked list > } entry_t; > > But probably this is too simplified... hm, I don't think so that its too simplified ... I think there need to be also an type-field as then the parser functions know, of which type the metadata-struct is ... Hm: another idea: One could store all metadata-information as strings as in mpcf. Is it possible to have all entries presented as url ? Ok, it _must_ be possible ... But how on a CD does the playlist-"parser/control" then know, that the demuxer and codec can be kept open, when tracktitle changes, but its the same media ... ? I think its then nice to also have playlists as an entry in the "Playtree" ... So, one can delete the playlist and all entries that belong to it, are removed ... (as long as the playlist is not changed of course ...) What about Audio-CDs or DVDs should the program ask for it, if they are not in Drive ? Or just ignore this entries ... hm, what I did not like about the last playtree-structure was that it was soo complicated, that everything was not easy to program and it was hardly possible for me to program an high-level-api ... Btw. I like you design of array-lists in stream better than with next-pointers ... Its much more easily to use ... But how does one go "up", from that again, if one is in an subnode ... Saving this information would be easy, but has overhead ... Lol, an idea I had (Thats possibly much too simplified): struct entry_list_s; struct entry_s { int type; URL_t* url; demux_metadata_t meta; entry_list_s list; } entry_t; typedef struct entry_list_s { int num_entries; // number of available entries int max_entries; // number of allocated entries (if(num_metas>=max_metas)realloc()) entry_t* entries; } entry_list_t; type determines now if list is: * an own object * a sublist * alternatives You ask yourself what happens if there are muplitple files and alternatives ? They are nested: file1 - meta entry with type alternative - alternative 1 - alternative 2 - alternative 3 file 2 - meta entry with type sublist - file 1 - file 2 ... Name and so on can be read from Meta-Data ... cu Fabian > Any better ideas? > > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/Lp4yI0lSH7CXz7MRAt+wAJ9CGurmG/9FodflBEH0vTDo66VP2wCdF3kH Sdn9sNq3nLpFXXImvUejqG4= =6sij -----END PGP SIGNATURE----- From dalias at aerifal.cx Mon Aug 4 20:30:20 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 4 Aug 2003 14:30:20 -0400 Subject: [MPlayer-G2-dev] new release: pre39 In-Reply-To: <200308040909.h7499Wwa029060@mail.mplayerhq.hu> References: <20030804084811.GV220@brightrain.aerifal.cx> <200308040909.h7499Wwa029060@mail.mplayerhq.hu> Message-ID: <20030804183020.GW220@brightrain.aerifal.cx> On Mon, Aug 04, 2003 at 11:09:32AM +0200, Arpi wrote: > Hi, > > > On Mon, Aug 04, 2003 at 09:11:31AM +0200, Arpi wrote: > > > > relative pts, or absolute? With 32bit int, you only have room for > > > > ~4000 seconds before you wrap....and many movies are longer than that! > > > > > > it's absolute time counter truncated to 32 bits. it's far enough. > > > no movies encoded at 1/4000 fps... > > > > ?? > > the integer 1/1000000 res. counters are used to do timing between 2 frames. > so unless you have an 1/4000 fps "movie" (i would call it very slow > slideshow instead) it won't overflow :) Yes, I see now. :) > > generating bad timestamps encoding to variable-fps output formats. > > Also, there's the case where you're working with really long files, > > where the error could easily get as large as frame durations, so I'd > > be happier using doubles, at least wherever absolute pts is needed. > > then RTFS mp_image.h ;) I'm too lame to RTFS. :( > > By inexact I mean it's not based on the same time base as the file, > > but rather approximation by float or fixed point number. > > yes, but since realtime timers (usleep, rtc and so on) are 1/1000000 based > i nee dto convert to that base to do teh actual timing. and no human will > be able to see the difference between 1us and 1.024 us, but not even 1us and > 10us i think. Yeah, should be fine. I'm just paranoid after seeing G1's mencoder do nonsense like duplicating a bunch of frames only to force itself to skip frames < 1sec later, generating horrible choppy output files. > > > no, but it's fun to see, esp. at mixed hard/soft telecined material :) > > > > Ah, but I thought the new code didn't change nominal framerate, just > > delay rff frames by 1/120 sec... > > actually there is no thing as framerate in g2, only relative pts (or > duration). so actually it prints 1/duration... > > (it printed duration in ms before, but fps loosk better) Ah, very cool. This is a nice number to know for encoding from variable-fps formats like asf into a fixed-fps container. :) Rich From saschasommer at freenet.de Mon Aug 4 20:29:56 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Mon, 4 Aug 2003 20:29:56 +0200 Subject: [MPlayer-G2-dev] [PATCH] Mingw fixes and experimental vo directx Message-ID: <014201c35ab6$68e82d60$856254d9@oemcomputer> Attached are some fixes for better mingw support. They are mainly backported from main cvs. The other patch, which, imho shouldn't be applied, contains a directx driver for libvo2. When all patches are applied mplayer should be compileable without network support. However the timer is still broken and the directx vo and the win32_helper are missing some important features. Sascha -------------- next part -------------- A non-text attachment was scrubbed... Name: experimentalvodirectxg2.diff Type: application/octet-stream Size: 31775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mingwfixes.diff Type: application/octet-stream Size: 15108 bytes Desc: not available URL: From joey at nicewarrior.org Mon Aug 4 20:38:48 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Mon, 4 Aug 2003 13:38:48 -0500 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030804064047.GR220@brightrain.aerifal.cx> References: <200308032250.h73MorUV026882@mail.mplayerhq.hu> <20030804013423.GQ220@brightrain.aerifal.cx> <20030804025636.GA12182@nicewarrior.org> <20030804064047.GR220@brightrain.aerifal.cx> Message-ID: <20030804183848.GA14686@nicewarrior.org> On Mon, Aug 04, 2003 at 02:40:47AM -0400, D Richard Felker III wrote: > Some out-of-the-box, some from mphq releases directory. Is that your > package? I doubt it. I've been making packages at http://joey.nicewarrior.org/cygmp/ but once I accomplish most of my goals with them, I'd like to get them hosted at mphq and linked to from downloads page. Even if they're still labelled 'unofficial.' By the way, my goals, in order: make it fairly usable without nice gui - mostly done now give it more features - proper vcd support, dvd title/chapter seeking... make it able to replace real and quicktime and wmp - painful at best due to dll stuff give it a nice native gui - more research into win32 coding remove dependance on cygwin dll without loss of features - ick. --Joey From saschasommer at freenet.de Mon Aug 4 20:57:44 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Mon, 4 Aug 2003 20:57:44 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI References: <200308032250.h73MorUV026882@mail.mplayerhq.hu><20030804013423.GQ220@brightrain.aerifal.cx><20030804025636.GA12182@nicewarrior.org><20030804064047.GR220@brightrain.aerifal.cx> <20030804183848.GA14686@nicewarrior.org> Message-ID: <01aa01c35aba$4a597760$856254d9@oemcomputer> > On Mon, Aug 04, 2003 at 02:40:47AM -0400, D Richard Felker III wrote: > > Some out-of-the-box, some from mphq releases directory. Is that your > > package? > > I doubt it. I've been making packages at > http://joey.nicewarrior.org/cygmp/ but once I accomplish most of my > goals with them, I'd like to get them hosted at mphq and linked to from > downloads page. Even if they're still labelled 'unofficial.' > > By the way, my goals, in order: > > make it fairly usable without nice gui > - mostly done now > give it more features > - proper vcd support, dvd title/chapter seeking... > make it able to replace real and quicktime and wmp > - painful at best due to dll stuff The only problem here is to get our dlls loaded from our codec dir(s) > give it a nice native gui Give me ~3 more weekends and mine should be halfway stable. > - more research into win32 coding > remove dependance on cygwin dll without loss of features Just compile it with mingw... The packages in releases/win32-beta contain only one executable and a few config files. Sascha From joey at nicewarrior.org Mon Aug 4 22:23:37 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Mon, 4 Aug 2003 15:23:37 -0500 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <01aa01c35aba$4a597760$856254d9@oemcomputer> References: <20030804183848.GA14686@nicewarrior.org> <01aa01c35aba$4a597760$856254d9@oemcomputer> Message-ID: <20030804202337.GA15103@nicewarrior.org> On Mon, Aug 04, 2003 at 08:57:44PM +0200, Sascha Sommer wrote: > > make it able to replace real and quicktime and wmp > > - painful at best due to dll stuff > > The only problem here is to get our dlls loaded from > our codec dir(s) That's not much of a problem, I did it in my old packages. The patches are very old and against 0.90, but I still have them. I'll rewrite them against main cvs when I get back to win32 dev. > > give it a nice native gui > > Give me ~3 more weekends and mine should be > halfway stable. Nice. > > - more research into win32 coding > > remove dependance on cygwin dll without loss of features > > Just compile it with mingw... The packages in releases/win32-beta > contain only one executable and a few config files. Yes, but do all of mplayer's features work under mingw? It has been a long time since I tried, and I know much work has been done since. I haven't done it yet because if it proves to cause any problems, I won't have time to deal with them at the same time as the things I'm already working on. Also, this has gotten off-topic. I apologize. If you would like, Sacha, we can continue talking about win32 stuff off of g2's list. I think that we should work together at some of these things. --Joey From bingham.21 at osu.edu Mon Aug 4 22:30:29 2003 From: bingham.21 at osu.edu (Bobby Bingham) Date: Mon, 4 Aug 2003 16:30:29 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? Message-ID: <20030804203029.GA25583%bingham.21@osu.edu> i was wondering, is anybody working on an mencoder port to g2, or is there still some major work that needs done on g2 before it wold be feasible? if it's just that nobody has worked on it yet, i might give it a shot. also, as i understand it, one advantage of g2 over g1 is that it can process multiple streams at once, and this would be great to put into an mencoder-g2 eg. for ripping multiple dvd audio tracks, etc. i'm just not sure how it would work with mplayer's command-line processing, especially what sort of syntax would be used to specify possibly different encoders/encoding options/filters for different streams. even with g1, just specifying a decent set of encoding options for one stream gets a bit unweildy. as much as i hate the abundant over-use of guis when there's no need, a gui for selecting tracks to encode, along with filters and encoding options could be much nicer than the command line for more complex encodes. or does somebody have an idea for a good command-line syntax? -- Bobby Bingham From arpi at thot.banki.hu Mon Aug 4 23:22:44 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 23:22:44 +0200 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030804203029.GA25583%bingham.21@osu.edu> Message-ID: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> Hi, > i was wondering, is anybody working on an mencoder port to g2, or is afaik not yet > there still some major work that needs done on g2 before it wold be > feasible? if it's just that nobody has worked on it yet, i might give > it a shot. > > also, as i understand it, one advantage of g2 over g1 is that it can > process multiple streams at once, and this would be great to put into > an mencoder-g2 eg. for ripping multiple dvd audio tracks, etc. i'm sure. i'll (maybe with help of Rich) develop it, later. g2 libs are far from being complete, we still have a lot of things to do. > just not sure how it would work with mplayer's command-line processing, > especially what sort of syntax would be used to specify possibly > different encoders/encoding options/filters for different streams. even > with g1, just specifying a decent set of encoding options for one stream > gets a bit unweildy. as much as i hate the abundant over-use of guis > when there's no need, a gui for selecting tracks to encode, along with > filters and encoding options could be much nicer than the command line > for more complex encodes. > > or does somebody have an idea for a good command-line syntax? Anyone may write guis for it (it's the idea behind G2's modular, UI-independnet design), but for mencoder, i think a good commandline syntax is required, and the already existant mencoder frontends will be updated to support it. Generating scripts/commandlines for commandline tool has the advantage, that you can run the long encoding process remote on X-less servers or in the background... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Mon Aug 4 23:53:19 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 4 Aug 2003 23:53:19 +0200 Subject: [MPlayer-G2-dev] [PATCH] Mingw fixes and experimental vo directx In-Reply-To: <014201c35ab6$68e82d60$856254d9@oemcomputer> Message-ID: <200308042153.h74LrJaU018147@mail.mplayerhq.hu> Hi, > Attached are some fixes for better mingw support. They are mainly backported > from main cvs. Applied, except the timer-win.c part. You should implement real timer, the busy waiting thing (softsleep) doesn't work alone. The OS will intercept the process anyway, so unless you 'let it do at the right time' it will intercept in the middle of your busy loop causing timer overflows. So you should use some sleep function which makes your process idle for the given time, so the OS can schedule other tasks for that period. > The other patch, which, imho shouldn't be applied, contains a directx driver > for libvo2. Ok, didn't apply. The win_util thing looks nice, although the directx is ugly (not your code, but the oh-so-long directx defines and guids :)) > When all patches are applied mplayer should be compileable without network > support. Any plans to port win32 network part from cvs? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From diego at biurrun.de Mon Aug 4 23:50:49 2003 From: diego at biurrun.de (Diego Biurrun) Date: Mon, 04 Aug 2003 23:50:49 +0200 Subject: [MPlayer-G2-dev] playtree export structure [Was: Re: Developing a GTK2 GUI] In-Reply-To: <200308041956.03945.FabianFranz@gmx.de> References: <200308031714.h73HEQfc028872@mail.mplayerhq.hu> <200308041956.03945.FabianFranz@gmx.de> Message-ID: <16174.54585.977350.626461@silver.semantics.de> Fabian Franz writes: > > you could meet other mplayer developers there (@linuxtag) :) > > yeah, I didn't know this as mplayer had no booth ... Yes, we had no booth, but we have been thinking about getting a booth next year. I talked with G?nter Bartsch about this at the xine/gentoo booth and it is not hard for a project to get a booth, it's free. You get some space, a table and a net connection. We thought we might even get a booth together, the Linux multimedia booth or video player booth or whatever. Diego From FabianFranz at gmx.de Mon Aug 4 23:56:18 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 4 Aug 2003 23:56:18 +0200 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> Message-ID: <200308042356.30849.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 4. August 2003 23:22 schrieb Arpi: > Hi, > > > > or does somebody have an idea for a good command-line syntax? > > Anyone may write guis for it (it's the idea behind G2's modular, > UI-independnet design), but for mencoder, i think a good commandline > syntax is required, and the already existant mencoder frontends will > be updated to support it. Generating scripts/commandlines for commandline > tool has the advantage, that you can run the long encoding process > remote on X-less servers or in the background... In my opinion a cfgfile-format would be nice ... And then gui could create those cfgfile, whic hcan then be run in the background. Of course this cfg-file should be human-readable ... But I think commandline does get so long and file is an nice solution to specify all rules needed for the whole process. cu Fabian > > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/LtaKI0lSH7CXz7MRAuuDAJ9OyCCueZfsqgi+AB1bvsJHP+Nu6gCfYmll 4nERlsEMKT8fjv3PaF2XhHk= =uQAK -----END PGP SIGNATURE----- From diego at biurrun.de Tue Aug 5 00:00:33 2003 From: diego at biurrun.de (Diego Biurrun) Date: Tue, 05 Aug 2003 00:00:33 +0200 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: <20030804202337.GA15103@nicewarrior.org> References: <20030804183848.GA14686@nicewarrior.org> <01aa01c35aba$4a597760$856254d9@oemcomputer> <20030804202337.GA15103@nicewarrior.org> Message-ID: <16174.55169.860025.458398@silver.semantics.de> Joey Parrish writes: > On Mon, Aug 04, 2003 at 08:57:44PM +0200, Sascha Sommer wrote: > > > make it able to replace real and quicktime and wmp > > > - painful at best due to dll stuff > > > > The only problem here is to get our dlls loaded from > > our codec dir(s) > > That's not much of a problem, I did it in my old packages. > The patches are very old and against 0.90, but I still have them. > I'll rewrite them against main cvs when I get back to win32 dev. That would be very nice since codecs only work from %WINDIR% atm after we applied a patch to make Real DLLs work. In other words: this is desperately needed ;-) > > > - more research into win32 coding > > > remove dependance on cygwin dll without loss of features > > > > Just compile it with mingw... The packages in releases/win32-beta > > contain only one executable and a few config files. > > Yes, but do all of mplayer's features work under mingw? > It has been a long time since I tried, and I know much work > has been done since. I haven't done it yet because if it > proves to cause any problems, I won't have time to deal with > them at the same time as the things I'm already working on. Try again, IIRC everything except OSD menu works. Let's take further discussion to mplayer-cygwin. Diego From ajh at watri.org.au Tue Aug 5 03:09:35 2003 From: ajh at watri.org.au (Anders Johansson) Date: Tue, 5 Aug 2003 09:09:35 +0800 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI In-Reply-To: References: Message-ID: <20030805010935.GC919@watri.org.au> Hi Charles, When I designed the audio filter layer I was inspired by: http://www.mackie.com/products/d8b_v5/photos.html All the interfaces to the different filters can be represented by a sliders, buttons or knobs on that mixer board. I have however made one slight change: the scales I use are not very good for controlling with sliders, but needs to be remapped in a UI (this is especially true for the volume control) to something better (normally millimetres (not joking)). Please contact me when you get there, so we can work something out. Cheers, //Anders From ardneh2 at hotmail.com Wed Aug 6 04:54:03 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Wed, 06 Aug 2003 02:54:03 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Hi, A'rpi writes: >Hi, > > > >But mplayer does things a lot different than the other players out > > > > Yes, mplayer works. I don't use xine because 1) when I was first >looking > > for a movie player years ago (geez, has it been that long?) all xine did >was > > crash and 2) now, Totem, a GTK2 ui for libxine, doesn't start unless I > > delete one > > of its config files and sometimes I even have to use gconf! > >lol :) > >I've tried xine a year ago, and it look good, until i pressed play :) >I liked its preferences window, it build Xvideo config dialog at runtime, >by querying Xv attribs (like xvinfo) and used them to setup bars. >(at least it looked so, i'm not 100% sure it was really runtime built >or they were just tricky again, as usual...) I haven't used xine itself since that first time. I will download it and check it out. >It gave me the idea of runtime built config windows... Cool. > > I spent over a week porting that to GTK2 and it became > > very clear that a lot of things were done that didn't need to be. > > It could have been much smaller, simpler and more portable. > >Ok, time to tell teh big secret to you :) > >The original Gui (in v0.50) of g1 did not use gtk at all! >It used Xlib only, and Pontscho wrote a skinned toolkit-like thing I know. I've looked at almost all the code in the Gui directory and know most of it by heart. >for it. If you look at old g1 skins, you'll see even the popup menus >pre-drawn in .png. It worked for a while, until things like dinamically >changed menus (like audio/vidoe ID, dvd title selectable in menu), >and fileselector requirement came up. Ponstcho didn't want to code a >so complex toolkit for his skin engine, so he started to hack gtk >support in. Afair there wasn't gtk2 yet that times. >Later more and more parts of his skinned stuff was replaced by gtk >functions, and the things got more messy and ugly... you see the result. Yes, what had happened was fairly obvious. :( >I think, if he start with gtk at first day, or he implements complex >toolkit elements in his xlib-based skinned engine, it woudl be better, >than this mixed gtk+xlib hack. I agree. He probably thinks so, too. >To make things even worse, he wanted it to look very good (which wasn't >possible with gtk1 afaik, i mean non-rectangular gui window etc), but No, it wasn't. The good news is GTK2 does and my skin test program worked very well. >the gui development was sponsored for a while by UHU Linux, given a >deadline. So he had no time to mess more with xlib, he used gtk... Ah. Well, I only have myself to worry about as far as funding. > > You don't have a chance of discouraging me. :) > >Nice to hear! :) >I've never wanted g1's gui to be ported to g2, and as i'm not a gui >coder (and i don't even want to be), i designed g2 to be ui-independent, >so that many ppl who started coding guis/frontends for g1 (and failed >due to g1's monolitic design) can do it now. For not being a GUI coder you seem to understand things very well. >Btw I have some crazy(?) ideas for the g2 gtk2 gui, for example a mode >when it starts without a gui window, like the commandline player >(and even gets options/filenames etc from commandline) but some mouse >click or hotkey can bring up config windows/preferences so filters, >plugins can be configured runtime in an user-friendly interface, even >for commandline-liker users like me or Rich. >(Rich: it's quite hard to control (and display) a 24-band audio equalizer >from commandline...) >I think with a well-written layered gui it's easily doable. I was not going to bring this up until later, but I guess now is fine. :) I would like to suggest that MODULE_TYPE_UI be added to module_type_t to represent all UI modules. This would enable UIs to be dynamically loaded / selected from either the mplayer conf file or the command line. Or from whatever UI is being used at the moment. (NOTE: Yes, it should still be possible to statically link a UI in, if this is an important feature. I certainly think it is very convenient.) Furthermore, UIs that _wanted to_ (this would not be forced on anyone) could be composed of sub-modules: one for the preferences, one for the equalizer, one for the main UI, etc... If it is done this way, then the individual UI sub-modules could be remapped at will (via the UI's config_t). A command line UI that uses the GTK preferences and equalizer, for example. All the code to do the UI switching / manipulation would (obviously) be placed in a separate source + header file and only be used by UIs which want to have a modular structure and be dynamically switchable. None of this should be detrimental to mplayer core. On the contrary --if I understand things correctly-- it should be possible to make test-play.c UI independent. I think that this is a very good thing. The main problems I see with this are: 1) it's going to have to be possible to find out what UIs are available on startup. 2) there needs to be a way to load and unload modules at will. module_info_t mentions loadable plugins so I'm assuming both of these are planned, if not currently implemented (I appologize for not checking the code more closely, I still have some work eating up all of my time). 3) It might not be possible because I do not understand mplayer well enough yet. That is my very low-priority suggestion. I am sure there are still things that need to be worked out and tested. What do you think? -Charles _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From ardneh2 at hotmail.com Wed Aug 6 05:44:52 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Wed, 06 Aug 2003 03:44:52 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Dan Christiansen writes: >On Sunday, August 3, 2003, at 10:37 AM, Charles Ezell wrote: > >>Gustavo writes: >> >>>Yes, I know that... win32 is the other way (coordinates-based) and I >>>don't know Mac to tell... >> >>Don't know either. :) But it is probably coord based. I was also >>thinking >>about Qt (which I know next to nothing about). > >I am not a GUI developer, but maybe I can shed some light on how things >work on Mac OS X: > >On Mac OS X, as you may have heard, there are two independent GUI APIs, >commonly referred to as Cocoa and Carbon. Cocoa is an Objective-C API and >comes from NeXT, and it's intended that GUIs aren't generated in code, but >dynamically from UI files - it encourages complete separation between code >and UI. Carbon is based on the old Mac OS APIs, and is C - but IMO ugly C. >You usually write the GUI in code, but very few things are handled for you, >and good Carbon GUIs are more rare than good Cocoa GUIs. > >Both are coordinate-based, but in Cocoa, you would usually design the >elements in Interface Builder and if necessary use that in code. If anyone >wants to write a native GUI for Mac OS X, I'd say they should use Cocoa, >and try to keep it separate from the main MPlayer since there are lots of >files you probably wouldn't want to know about. Anyone trying to write a (native) window builder for MacOS X will probably have a more difficult time of it then. >Cocoa and Objective-C are fairly difficult to describe since they are very >different from everything else out there, but they work quite well in >practise. One good thing about Objective-C, though, is that it isn't C++ ;) I've played around with Objective-C. I don't like it as much as C++ ;), but imho I am very glad Apple went in that direction instead of keeping an ancient (ugly) C API. Thank you for the info. :) -Charles _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From ardneh2 at hotmail.com Wed Aug 6 05:59:17 2003 From: ardneh2 at hotmail.com (Charles Ezell) Date: Wed, 06 Aug 2003 03:59:17 +0000 Subject: [MPlayer-G2-dev] Developing a GTK2 GUI Message-ID: Anders Johansson writes: >Hi Charles, > >When I designed the audio filter layer I was inspired by: >http://www.mackie.com/products/d8b_v5/photos.html Nice. I don't know much about audio mixing, however. :) >All the interfaces to the different filters can be represented by a >sliders, buttons or knobs on that mixer board. I have however made one >slight change: the scales I use are not very good for controlling with >sliders, but needs to be remapped in a UI (this is especially true for >the volume control) to something better (normally millimetres (not OK. That will take some extra care but I don't see any huge problem since I will always be able to get the size of the controls. >joking)). Please contact me when you get there, so we can work >something out. I will do so. Thank you for the info, -Charles _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From bingham.21 at osu.edu Thu Aug 7 00:13:51 2003 From: bingham.21 at osu.edu (Bobby Bingham) Date: Wed, 6 Aug 2003 18:13:51 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <200308042356.30849.FabianFranz@gmx.de> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> Message-ID: <20030806221351.GA3447%bingham.21@osu.edu> On Mon, Aug 04, 2003 at 11:56:18PM +0200, Fabian Franz wrote: > In my opinion a cfgfile-format would be nice ... > > And then gui could create those cfgfile, whic hcan then be run in the > background. Of course this cfg-file should be human-readable ... > > But I think commandline does get so long and file is an nice solution to > specify all rules needed for the whole process. > > cu > > Fabian that's probably best for complex encodes. i'd like to also support a command-line similar to the current mencoder that for single audio/video stream encodes. i don't know mplayer's command-line parsing system very well. is there a way to have the video encoder specified with it's params as suboptions like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than having to add a new option (-lavcopts, -xvidencopts, etc) for every new audio/video encoder. also, can the commandline parser also be used nicely on arbitrary strings, such as those i'd read from a cfgfile used to define multi-stream encoding? i also haven't looked closely at the muxing code from mencoder, but i seem to recall it sounding like a pain when the mpeg muxer was added (which doesn't always seem to work for me, but that's another story). is the current muxer code good/extensible enough? it might also be nice to use the libavformat muxers from ffmpeg, which already does both avi and mpeg muxing AFAIK. TIA, Bobby Bingham From joey at nicewarrior.org Thu Aug 7 04:09:00 2003 From: joey at nicewarrior.org (Joey Parrish) Date: Wed, 6 Aug 2003 21:09:00 -0500 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030806221351.GA3447%bingham.21@osu.edu> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> <20030806221351.GA3447%bingham.21@osu.edu> Message-ID: <20030807020859.GB23085@nicewarrior.org> On Wed, Aug 06, 2003 at 06:13:51PM -0400, Bobby Bingham wrote: > i don't know mplayer's command-line parsing system very well. is there > a way to have the video encoder specified with it's params as suboptions > like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than > having to add a new option (-lavcopts, -xvidencopts, etc) for every new > audio/video encoder. Does G2 even have a command line parser outside of test-play? I haven't looked, but I would assume that this is the job of the UI, not the lib. --Joey From bingham.21 at osu.edu Thu Aug 7 04:29:43 2003 From: bingham.21 at osu.edu (Bobby Bingham) Date: Wed, 6 Aug 2003 22:29:43 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030806221351.GA3447%bingham.21@osu.edu> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> <20030806221351.GA3447%bingham.21@osu.edu> Message-ID: <20030807022943.GB3442%bingham.21@osu.edu> On Wed, Aug 06, 2003 at 06:13:51PM -0400, Bobby Bingham wrote: > i don't know mplayer's command-line parsing system very well. is there > a way to have the video encoder specified with it's params as suboptions > like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than > having to add a new option (-lavcopts, -xvidencopts, etc) for every new > audio/video encoder. > > also, can the commandline parser also be used nicely on arbitrary > strings, such as those i'd read from a cfgfile used to define > multi-stream encoding? > ok, you can ignore that part - i RTFS ;) it looks like it's just as easy to parse from a file as from cmdline :). looks like for using encoder parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a CONF_TYPE_STRING, find the right module_info_t, and send it, along with the rest of the string to mpconfig_parse_subconfig(). From dalias at aerifal.cx Thu Aug 7 08:10:05 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 7 Aug 2003 02:10:05 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030806221351.GA3447%bingham.21@osu.edu> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> <20030806221351.GA3447%bingham.21@osu.edu> Message-ID: <20030807061004.GA198@brightrain.aerifal.cx> On Wed, Aug 06, 2003 at 06:13:51PM -0400, Bobby Bingham wrote: > On Mon, Aug 04, 2003 at 11:56:18PM +0200, Fabian Franz wrote: > > In my opinion a cfgfile-format would be nice ... > > > > And then gui could create those cfgfile, whic hcan then be run in the > > background. Of course this cfg-file should be human-readable ... > > > > But I think commandline does get so long and file is an nice solution to > > specify all rules needed for the whole process. > > > > cu > > > > Fabian > > that's probably best for complex encodes. i'd like to also support a > command-line similar to the current mencoder that for single audio/video > stream encodes. > > i don't know mplayer's command-line parsing system very well. is there > a way to have the video encoder specified with it's params as suboptions > like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than > having to add a new option (-lavcopts, -xvidencopts, etc) for every new > audio/video encoder. Any suggestions on how you put defaults in your config file with a system like this? > i also haven't looked closely at the muxing code from mencoder, but i > seem to recall it sounding like a pain when the mpeg muxer was added > (which doesn't always seem to work for me, but that's another story). > is the current muxer code good/extensible enough? it might also be nice No, current muxer code is horrible. > to use the libavformat muxers from ffmpeg, which already does both avi > and mpeg muxing AFAIK. No, libavformat is also horrible... :( Rich From andrej at lucky.net Thu Aug 7 09:43:30 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 7 Aug 2003 10:43:30 +0300 Subject: [MPlayer-G2-dev] Re: mencoder-g2 ? In-Reply-To: <20030806221351.GA3447%bingham.21@osu.edu> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> <20030806221351.GA3447%bingham.21@osu.edu> Message-ID: <20030807074330.GB42516@lucky.net> Hi, Bobby Bingham! Sometime (on Thursday, August 7 at 1:25) I've received something... >On Mon, Aug 04, 2003 at 11:56:18PM +0200, Fabian Franz wrote: >> In my opinion a cfgfile-format would be nice ... >> And then gui could create those cfgfile, whic hcan then be run in the >> background. Of course this cfg-file should be human-readable ... >> But I think commandline does get so long and file is an nice solution to >> specify all rules needed for the whole process. >that's probably best for complex encodes. i'd like to also support a >command-line similar to the current mencoder that for single audio/video >stream encodes. >i don't know mplayer's command-line parsing system very well. is there >a way to have the video encoder specified with it's params as suboptions >like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than >having to add a new option (-lavcopts, -xvidencopts, etc) for every new >audio/video encoder. I would prefer for example to have in config file: ovc:lavc = codec=mpeg4:hq ovc:jpeg = quality=90 oac:mp3lame = aq=0 and then run mencoder with mencoder -dvd -ovc lavc:vpass=1 -oac mp3lame:aq=9 mencoder -dvd -ovc lavc:vpass=2 -oac mp3lame If anyone will redo config/commandline parser then let me call mencoder that way, please. ;) >also, can the commandline parser also be used nicely on arbitrary >strings, such as those i'd read from a cfgfile used to define >multi-stream encoding? >i also haven't looked closely at the muxing code from mencoder, but i >seem to recall it sounding like a pain when the mpeg muxer was added >(which doesn't always seem to work for me, but that's another story). >is the current muxer code good/extensible enough? it might also be nice >to use the libavformat muxers from ffmpeg, which already does both avi >and mpeg muxing AFAIK. Muxer code in G2 still didn't developed so I'm not sure if it's working at all. I think I'll work on it later. Now I have too few time, unfortunately. With best wishes. Andriy. From arpi at thot.banki.hu Thu Aug 7 10:00:21 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 7 Aug 2003 10:00:21 +0200 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030807022943.GB3442%bingham.21@osu.edu> Message-ID: <200308070800.h7780LSQ011922@mail.mplayerhq.hu> Hi, > On Wed, Aug 06, 2003 at 06:13:51PM -0400, Bobby Bingham wrote: > > i don't know mplayer's command-line parsing system very well. is there > > a way to have the video encoder specified with it's params as suboptions > > like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than > > having to add a new option (-lavcopts, -xvidencopts, etc) for every new > > audio/video encoder. > > > > also, can the commandline parser also be used nicely on arbitrary > > strings, such as those i'd read from a cfgfile used to define > > multi-stream encoding? > > > > ok, you can ignore that part - i RTFS ;) it looks like it's just as easy > to parse from a file as from cmdline :). looks like for using encoder yes > parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a > CONF_TYPE_STRING, find the right module_info_t, and send it, along with > the rest of the string to mpconfig_parse_subconfig(). no you shuould use MODULE_LIST (limited to 1 module), so the parser will do all teh job automagically. you could do with STRING and directly calling mpconfig_parse_subconfig, but in that case Guis and extended UIs won't know teh syntax of that parameter. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu Aug 7 09:55:50 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 7 Aug 2003 10:55:50 +0300 Subject: [MPlayer-G2-dev] Re: mencoder-g2 ? In-Reply-To: <20030807020859.GB23085@nicewarrior.org> References: <200308042122.h74LMiKs013079@mail.mplayerhq.hu> <200308042356.30849.FabianFranz@gmx.de> <20030806221351.GA3447%bingham.21@osu.edu> <20030807020859.GB23085@nicewarrior.org> Message-ID: <20030807075550.GC42516@lucky.net> Hi, Joey Parrish! Sometime (on Thursday, August 7 at 5:09) I've received something... >On Wed, Aug 06, 2003 at 06:13:51PM -0400, Bobby Bingham wrote: >> i don't know mplayer's command-line parsing system very well. is there >> a way to have the video encoder specified with it's params as suboptions >> like "-ovc lavc:codec=mpeg4:hq:pass=1". i think that's better than >> having to add a new option (-lavcopts, -xvidencopts, etc) for every new >> audio/video encoder. >Does G2 even have a command line parser outside of test-play? I haven't >looked, but I would assume that this is the job of the UI, not the lib. Arpi called config/CL parser as Level1 and I think it seems as another lib, useful for all applications (since any player, encoder, video editor, etc. must read config file(s)). :) Best wishes for you. Andriy. From bingham.21 at osu.edu Thu Aug 7 18:56:49 2003 From: bingham.21 at osu.edu (Bobby Bingham) Date: Thu, 7 Aug 2003 12:56:49 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <200308070800.h7780LSQ011922@mail.mplayerhq.hu> References: <20030807022943.GB3442%bingham.21@osu.edu> <200308070800.h7780LSQ011922@mail.mplayerhq.hu> Message-ID: <20030807165649.GA3382%bingham.21@osu.edu> On Thu, Aug 07, 2003 at 10:00:21AM +0200, Arpi wrote: > Hi, > > > parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a > > CONF_TYPE_STRING, find the right module_info_t, and send it, along with > > the rest of the string to mpconfig_parse_subconfig(). > > no > you shuould use MODULE_LIST (limited to 1 module), so the parser will do all > teh job automagically. > you could do with STRING and directly calling mpconfig_parse_subconfig, but > in that case Guis and extended UIs won't know teh syntax of that parameter. > is there a way to limit MODULE_LIST to only 1 module? AFAICS there isn't. or do you mean to just ignore all but the first module returned? Bobby Bingham From dalias at aerifal.cx Thu Aug 7 19:29:12 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 7 Aug 2003 13:29:12 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030807165649.GA3382%bingham.21@osu.edu> References: <20030807022943.GB3442%bingham.21@osu.edu> <200308070800.h7780LSQ011922@mail.mplayerhq.hu> <20030807165649.GA3382%bingham.21@osu.edu> Message-ID: <20030807172912.GA3749@brightrain.aerifal.cx> On Thu, Aug 07, 2003 at 12:56:49PM -0400, Bobby Bingham wrote: > On Thu, Aug 07, 2003 at 10:00:21AM +0200, Arpi wrote: > > Hi, > > > > > parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a > > > CONF_TYPE_STRING, find the right module_info_t, and send it, along with > > > the rest of the string to mpconfig_parse_subconfig(). > > > > no > > you shuould use MODULE_LIST (limited to 1 module), so the parser will do all > > teh job automagically. > > you could do with STRING and directly calling mpconfig_parse_subconfig, but > > in that case Guis and extended UIs won't know teh syntax of that parameter. > > > > is there a way to limit MODULE_LIST to only 1 module? AFAICS there > isn't. or do you mean to just ignore all but the first module returned? It could be a list the same way -vc is a list, to fall back to later options in the list if the first one doesn't work... Rich From arpi at thot.banki.hu Thu Aug 7 21:45:28 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 7 Aug 2003 21:45:28 +0200 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030807165649.GA3382%bingham.21@osu.edu> Message-ID: <200308071945.h77JjSsB030300@mail.mplayerhq.hu> Hi, > On Thu, Aug 07, 2003 at 10:00:21AM +0200, Arpi wrote: > > Hi, > > > > > parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a > > > CONF_TYPE_STRING, find the right module_info_t, and send it, along with > > > the rest of the string to mpconfig_parse_subconfig(). > > > > no > > you shuould use MODULE_LIST (limited to 1 module), so the parser will do all > > teh job automagically. > > you could do with STRING and directly calling mpconfig_parse_subconfig, but > > in that case Guis and extended UIs won't know teh syntax of that parameter. > > > > is there a way to limit MODULE_LIST to only 1 module? AFAICS there > isn't. or do you mean to just ignore all but the first module returned? no set CONF_MAX and set max to 1 min/max values for lists are limits on number of elements A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From bingham.21 at osu.edu Thu Aug 7 22:42:59 2003 From: bingham.21 at osu.edu (Bobby Bingham) Date: Thu, 7 Aug 2003 16:42:59 -0400 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <200308071945.h77JjSsB030300@mail.mplayerhq.hu> References: <20030807165649.GA3382%bingham.21@osu.edu> <200308071945.h77JjSsB030300@mail.mplayerhq.hu> Message-ID: <20030807204259.GA3270%bingham.21@osu.edu> On Thu, Aug 07, 2003 at 09:45:28PM +0200, Arpi wrote: > Hi, > > > On Thu, Aug 07, 2003 at 10:00:21AM +0200, Arpi wrote: > > > Hi, > > > > > > > parameters like "-ovc lavc:codec=mpeg4:hq:pass=1", i just need to use a > > > > CONF_TYPE_STRING, find the right module_info_t, and send it, along with > > > > the rest of the string to mpconfig_parse_subconfig(). > > > > > > no > > > you shuould use MODULE_LIST (limited to 1 module), so the parser will do all > > > teh job automagically. > > > you could do with STRING and directly calling mpconfig_parse_subconfig, but > > > in that case Guis and extended UIs won't know teh syntax of that parameter. > > > > > > > is there a way to limit MODULE_LIST to only 1 module? AFAICS there > > isn't. or do you mean to just ignore all but the first module returned? > > no > set CONF_MAX and set max to 1 > min/max values for lists are limits on number of elements yes for CONF_TYPE_STRING_LIST. AFAICS, all this is in mpconfig_parse_param(). in there, nothing in the CONF_TYPE_MODLIST case even looks at cd->min/max, or cd->flags, let alone checks it for CONF_MAX. maybe just not implemented yet? > > > 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 Aug 7 23:09:09 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 7 Aug 2003 23:09:09 +0200 Subject: [MPlayer-G2-dev] mencoder-g2 ? In-Reply-To: <20030807204259.GA3270%bingham.21@osu.edu> Message-ID: <200308072109.h77L99r4013813@mail.mplayerhq.hu> Hi, > > no > > set CONF_MAX and set max to 1 > > min/max values for lists are limits on number of elements > > yes for CONF_TYPE_STRING_LIST. AFAICS, all this is in > mpconfig_parse_param(). in there, nothing in the CONF_TYPE_MODLIST case > even looks at cd->min/max, or cd->flags, let alone checks it for > CONF_MAX. > > maybe just not implemented yet? maybe. i remembered i already wrote it for sth, but maybe i mix sth. yes you're right, it's impl. only for string_list, as earlier it was used for module lists, then i realized a new type MODULE_LIST is better for UIs. anyway the min/max thing should be checked for all formats, where it has some sence, be it actual value or number of list elements. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ajh at watri.org.au Fri Aug 8 15:28:52 2003 From: ajh at watri.org.au (Anders Johansson) Date: Fri, 8 Aug 2003 21:28:52 +0800 Subject: [MPlayer-G2-dev] libaf In-Reply-To: <200308011627.h71GRTpH026150@mail.mplayerhq.hu> References: <20030801103603.GB919@watri.org.au> <200308011627.h71GRTpH026150@mail.mplayerhq.hu> Message-ID: <20030808132852.GA4196@watri.org.au> Hi, Got some questions. > Hi, > > > I will try to convert libaf to the new general config system this > > weekend. Is there anything else you want me to change in the audio > > filter layer while I am at it? > > yes, rewrite from scratch :))) > ok just joke. Are you sure? > but i would like a stream/fifo like implementation instead of this current > packet i/o style. the packet stuff would be ok, if you could accurately > predict (calculate) in/out packet sizes, but i see it's not possible for > many filters. Still not sure what you mean by stream/fifo. But think I have managed to work out a way to predict the number of samples, so I will implement it, pretty much what you describe below. > what i really want to see in libaf, is very similar to vf layer: > the bottom end (ao) requiest N samples (or bytes), from the af > layer. then the last af filter is called to produce N samples. > This filter then calculates that it needs M samples to be able to > produce exactly N samples. then it calls the previous filter in line, > to produce M samples and so on, up to the codec. Ok to the questions: 1. I have pretty much figured out how to define config_data_s, config_defaults, config_t config_format[] and xx_info_t structs, but I don't get how I am supposed to read the configuration data, I guess it will be in the config_defaults struct, but when is it valid? 2. How does runtime configuration work, where do I export the pointer to my control function? Or will the runtime UI have a separate interface to every part of the player? > A'rpi / Astral & ESP-team //Anders From arpi at thot.banki.hu Fri Aug 8 16:02:51 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 8 Aug 2003 16:02:51 +0200 Subject: [MPlayer-G2-dev] libaf In-Reply-To: <20030808132852.GA4196@watri.org.au> Message-ID: <200308081402.h78E2prW013611@mail.mplayerhq.hu> Hi, > Ok to the questions: > > 1. I have pretty much figured out how to define config_data_s, > config_defaults, config_t config_format[] and xx_info_t structs, but > I don't get how I am supposed to read the configuration data, I guess > it will be in the config_defaults struct, but when is it valid? No. You should read DOCS/config.txt of g2, it's explained there. Your filter's open/init/create (whatever you call it) function should get the pointer to the config structure. Normally it's cloned (copied) from your config_defaults, unless UI changes sth. > 2. How does runtime configuration work, where do I export the pointer That part is not finalized yet, but in my plans there will be a flag to select runtime (without reinit) changeable parameters. When the others are changed, the filter will be re-inited (or re-opened). When runtime chanegable parameter is changed, a special control (CFG_NOTIFY or so) will be called. This part is not yet implemented... (i'm waiting for teh first (G)UI to be able to test such thing) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Sun Aug 10 15:05:07 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 10 Aug 2003 15:05:07 +0200 Subject: [MPlayer-G2-dev] release: pre-40 Message-ID: <200308101305.h7AD574C015704@mail.mplayerhq.hu> Hi, pre40: - applied mingw/win32 patch from Sascha Sommer, shmem.[ch] updated from main - vf_remcirc, lame unfinished circle removal filter - first try at modular configure (c0nfigure/, name inspired by autom4te :)) - vo drivers reordered, now: directx, xv, xover, x11, fbdev, mga, tdfx_vid - fixed some bugs in vd_ffmpeg and vf_vd PTS handing code (GoneNutty.avi) - demuxer: type of absolute PTS changed from float to rate_m-based integer!! now you can get time in seconds: pts/rate_m, and frame number: pts/rate_d :) - vd_ffmpeg updated to CVS/main version, to fix slices func (width=>type) - vf_vo2: check buffer_h>=mpi->height too (fixes green line / sig11 bug) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From nsabbi at libero.it Sun Aug 10 18:32:27 2003 From: nsabbi at libero.it (Nico) Date: Sun, 10 Aug 2003 18:32:27 +0200 Subject: [MPlayer-G2-dev] release: pre-40 References: <200308101305.h7AD574C015704@mail.mplayerhq.hu> Message-ID: <3F36739B.8020804@libero.it> Hi, it seems that none of the stream drivers uses options (except stream_cdda.c that has the code #ifdef 0). Isn't it possible, yet? Arpi wrote: >Hi, > >pre40: >- applied mingw/win32 patch from Sascha Sommer, shmem.[ch] updated from main >- vf_remcirc, lame unfinished circle removal filter >- first try at modular configure (c0nfigure/, name inspired by autom4te :)) >- vo drivers reordered, now: directx, xv, xover, x11, fbdev, mga, tdfx_vid >- fixed some bugs in vd_ffmpeg and vf_vd PTS handing code (GoneNutty.avi) >- demuxer: type of absolute PTS changed from float to rate_m-based integer!! > now you can get time in seconds: pts/rate_m, and frame number: pts/rate_d :) >- vd_ffmpeg updated to CVS/main version, to fix slices func (width=>type) >- vf_vo2: check buffer_h>=mpi->height too (fixes green line / sig11 bug) > > >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 Sun Aug 10 22:43:31 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 10 Aug 2003 22:43:31 +0200 Subject: [MPlayer-G2-dev] release: pre-40 In-Reply-To: <3F36739B.8020804@libero.it> Message-ID: <200308102043.h7AKhVIV032731@mail.mplayerhq.hu> Hi, > > Hi, > > it seems that none of the stream drivers uses options (except > stream_cdda.c that has the code #ifdef 0). > > Isn't it possible, yet? yes, the stream layer wasnt updated yet to use the new config layer although it shouldn't take more than 10 minutes, and its' on my TODO... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ajh at watri.org.au Mon Aug 11 14:21:49 2003 From: ajh at watri.org.au (Anders Johansson) Date: Mon, 11 Aug 2003 20:21:49 +0800 Subject: [MPlayer-G2-dev] libaf In-Reply-To: <200308081402.h78E2prW013611@mail.mplayerhq.hu> References: <20030808132852.GA4196@watri.org.au> <200308081402.h78E2prW013611@mail.mplayerhq.hu> Message-ID: <20030811122149.GA8587@watri.org.au> Hi, > > 2. How does runtime configuration work, where do I export the pointer > > That part is not finalized yet, but in my plans there will be a flag to > select runtime (without reinit) changeable parameters. When the others are > changed, the filter will be re-inited (or re-opened). > When runtime chanegable parameter is changed, a special control (CFG_NOTIFY > or so) will be called. Why not use a pointer to the config struct as an input paramter to the config function? > This part is not yet implemented... > (i'm waiting for teh first (G)UI to be able to test such thing) I have a suggestion how the config management could be handeled. Create a linked list of structs according to typedef struct instance_s{ int (*control)(struct instance_s* instance, int cmd, void* arg); struct instance_s next; struct instance_s prev; }instance_t; Then for every module typ (af vf vo vd ad etc) "overload" the struct, example: typedef struct af_instance_s { int (*control)(struct af_instance_s* af, int cmd, void* arg); struct af_instance_s* next; struct af_instance_s* prev; void (*uninit)(struct af_instance_s* af); af_data_t* (*play)(struct af_instance_s* af, af_data_t* data); void* setup; // setup data for this specific instance and filter af_data_t* data; // configuration for outgoing data stream .. .. ..and so on }af_instance_t; Put all the module loading and linked list management in a common lib where the module specific xx_instance_t* are casted to instance_t* and export the list to the (G)UI. The UI will be able to call control in an module independent way without having to know exactly what it is talking to. > > A'rpi / Astral & ESP-team > //Anders From FabianFranz at gmx.de Mon Aug 11 15:18:46 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 11 Aug 2003 15:18:46 +0200 Subject: [MPlayer-G2-dev] MainActor Message-ID: <200308111518.50641.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, today mainconcepts released its video editing software MainActor for Linux ... As we are speking about GUI's and necessary compontents, we should also take a look, what the others do: http://www.mainconcept.com/mainactor_v5.shtml#linux Its for now in a preview version and can be downloaded ... Its for an SuSE Linux 8.2 / Mandrake 9.1 System and has as major dependancy qt3.1.1 ... On Systems, where qt3 is splitted to plugins it seems necessary to do: export LD_PRELOAD=/usr/lib/qt3/plugins/styles/libqwindowsstyle.so (Repeat for echt plugin that is expected to be in the binary or recompile libqt3 from source with threads) (Thats the case on debian-based systems for example) Another major dependancy is Pentium III / Athlon with 700 Mhz. (They use sse2/mmx2 optimized code for the codecs) However with deleting or renaming libmcdvd_32.so it was possible to start it, with just an AMD K6 II and one can still get an impression how the program works ... (DnD and context-menu seem to be two major parts of the ui-design) I'm just telling you, so that MPlayer G2 and its guis can compete with commercial projects :-). A'rpi, what would be nice was, if you could give a small status report about what is finished and what still needs to be done. (Somewhat more detailed than the TODO-List) ... Was just an idea :-) cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/N5e5I0lSH7CXz7MRAkqvAJsHJC8wuq9uo5DY4PNDitWpYbSxGgCeJkn0 cRc1vljXOX2XCDa5I5x3kVs= =iacj -----END PGP SIGNATURE----- From nexus at irc.pl Tue Aug 12 14:58:39 2003 From: nexus at irc.pl (Bohdan Horst) Date: Tue, 12 Aug 2003 14:58:39 +0200 Subject: [MPlayer-G2-dev] release: pre-40 In-Reply-To: <200308101305.h7AD574C015704@mail.mplayerhq.hu> References: <200308101305.h7AD574C015704@mail.mplayerhq.hu> Message-ID: <20030812125839.GB61415@essus.net> On Sun, Aug 10, 2003 at 03:05:07PM +0200, Arpi wrote: > Hi, > > pre40: [...] small patch to compile under FreeBSD: -- / irl: Bohdan 'Nexus' Horst | irc: Nexus \ {----------------------v-------^---------------} \ http://irc.pl/nexus | mailto: nexus at irc.pl / -------------- next part -------------- --- Makefile Thu Jul 24 00:12:27 2003 +++ Makefile.new Tue Aug 12 14:56:10 2003 @@ -3,8 +3,12 @@ LIBNAME = libvo2.a -SRCS=vo_null.c vo_fbdev.c vo_x11.c vo_xv.c vo_mga.c vo_tdfx_vid.c vo_xover.c video_out.c event.c x11_helper.c # vo_pgm.c vo_md5.c +SRCS=vo_null.c vo_x11.c vo_xv.c vo_mga.c vo_tdfx_vid.c vo_xover.c video_out.c event.c x11_helper.c # vo_pgm.c vo_md5.c OBJS=$(SRCS:.c=.o) + +ifeq ($(HAVE_FBDEV),yes) +SRCS += vo_fbdev.c +endif ifeq ($(VIDIX),yes) # SRCS += vosub_vidix.c From arpi at thot.banki.hu Tue Aug 12 20:27:47 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 12 Aug 2003 20:27:47 +0200 Subject: [MPlayer-G2-dev] module_list vs. gui Message-ID: <200308121827.h7CIRlLh021292@mail.mplayerhq.hu> Hi, As I already found it, and tdoay Albeu asked too, there is a problem with the current config element type MODULE_LIST. The current code uses a function to find modules by name, but it's not useful for guis where you want to list the available modules. Let's see what are our options: - find_module_by_name() (current) - not good for gui (can't list modules) - pointer to module_t array - not good for code, there may be multiple lists, dinamically loadable modules (and as we discussed earlier, a CLI shouldnt load all those, only the explicitly named modules), and special hidden modules (for internal use, like null or vf_vo2/vf_vd wrappers) - enumeration func: a function which returns a single module at a call, and can be called until you get null, to get all available modules (you should pass the previous return value (or null at 1st call) as parameter, to make it thread safe / reentrant) I would go for a mix of the 1st and 3rd option, ie. an enumeration function which can also do searching. Something like the good old findfirst/findnext of DOS: module_t* enum_modules(module_t* prev, char* mod_name, int type) prev: the result of previous call, NULL for 1st call mod_name: name of the module we're searching for (when explicitly named), or NULL (when we list all modules) type: some type value, like 0=static(builtin modules), 1=dinamic -1=internal (note: this field shouldn't be changed between the first and other calls, and implementations may read it only at 1st call) Mayeb it could be flags instead, ie 1, 2, 4, so they can be OR'ed So listing public (not hidden/internal) static and dinamic modules: for(t=0;t<=1;t++){ module_t* prev=NULL; while((prev=enum_modules(prev,NULL,t))){ printf("[%s] %s\n",t?"dinamic":"static", prev->name); } } And searching for a named module: mod=enum_modules(NULL,"vf_vo",0); You will ask why don't make 2 functions instead, one for search, and one for list/enumerate. The answer is simple: there is only one 'priv' (pointer) parameter in the config_t struct, and adding one more only for this is silly. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Thu Aug 14 23:15:07 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Thu, 14 Aug 2003 23:15:07 +0200 Subject: [MPlayer-G2-dev] [PATCH] ftp port from g1 to g2 :) Message-ID: <200308142315.12163.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, attached is the port from ftplib in g1 to g2 ... what still strange is that g2 needs much more time, before it displays the video/audio, but then it works perfect (at least for me ;)). Perhaps some cache-problem ? cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/O/veI0lSH7CXz7MRAoBBAJ9KHgJcqoJ95woJh6KJY082SaJp1wCfcDII CpagrGESpA24EuN1VG4I0yQ= =yh9q -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-ftp-support-port.diff Type: text/x-diff Size: 13506 bytes Desc: not available URL: From FabianFranz at gmx.de Fri Aug 15 00:28:41 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 15 Aug 2003 00:28:41 +0200 Subject: [MPlayer-G2-dev] [PATCH] ftp port from g1 to g2 :) In-Reply-To: <200308142315.12163.FabianFranz@gmx.de> References: <200308142315.12163.FabianFranz@gmx.de> Message-ID: <200308150028.46515.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 14. August 2003 23:15 schrieb Fabian Franz: > hi, > > attached is the port from ftplib in g1 to g2 ... > > what still strange is that g2 needs much more time, before it displays the > video/audio, but then it works perfect (at least for me ;)). > > Perhaps some cache-problem ? > > cu > > Fabian next try :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/PA0cI0lSH7CXz7MRApORAJ9wzh/IcNGbRXBls0juodLBeFBdQgCeO8aZ pBqH5ZhgCVQm6bf8eKgkLao= =iRgZ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-ftp-support-port.2.diff Type: text/x-diff Size: 13471 bytes Desc: not available URL: From FabianFranz at gmx.de Fri Aug 15 01:55:02 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 15 Aug 2003 01:55:02 +0200 Subject: [MPlayer-G2-dev] [PATCH] ftp port from g1 to g2 :) In-Reply-To: <200308150028.46515.FabianFranz@gmx.de> References: <200308142315.12163.FabianFranz@gmx.de> <200308150028.46515.FabianFranz@gmx.de> Message-ID: <200308150155.08353.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Freitag, 15. August 2003 00:28 schrieb Fabian Franz: > Am Donnerstag, 14. August 2003 23:15 schrieb Fabian Franz: > > hi, > > > > attached is the port from ftplib in g1 to g2 ... > > > > what still strange is that g2 needs much more time, before it displays > > the video/audio, but then it works perfect (at least for me ;)). > > > > Perhaps some cache-problem ? > > > > cu > > > > Fabian > > next try :) and the next one :) I had to remove the reconnecting code, because it did not work ... cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/PCFaI0lSH7CXz7MRAh6zAJ4kcbefqcNqFlRsYfUW9qnrAxAO2gCfVvH7 5HqxJb9qu+rHS2AoYQsoWIs= =XKMX -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-ftp-support-port.3.diff Type: text/x-diff Size: 15050 bytes Desc: not available URL: From albeu at free.fr Sat Aug 16 11:21:20 2003 From: albeu at free.fr (Alban Bedel) Date: Sat, 16 Aug 2003 11:21:20 +0200 Subject: [MPlayer-G2-dev] Re: module_list vs. gui References: <200308121827.h7CIRlLh021292@mail.mplayerhq.hu> Message-ID: <20030816112120.2a5de617.albeu@free.fr> Hi Arpi, on Tue, 12 Aug 2003 20:27:47 +0200 you wrote: > Hi, > > As I already found it, and tdoay Albeu asked too, there is a problem > with the current config element type MODULE_LIST. > The current code uses a function to find modules by name, but it's not > useful for guis where you want to list the available modules. > > Let's see what are our options: > - find_module_by_name() (current) - not good for gui (can't list > modules)- pointer to module_t array - not good for code, there may be > multiple > lists, dinamically loadable modules (and as we discussed earlier, a > CLI shouldnt load all those, only the explicitly named modules), and > special hidden modules (for internal use, like null or vf_vo2/vf_vd > wrappers) > - enumeration func: a function which returns a single module at a call, > and > can be called until you get null, to get all available modules > (you should pass the previous return value (or null at 1st call) as > parameter, to make it thread safe / reentrant) > > I would go for a mix of the 1st and 3rd option, ie. an enumeration > function which can also do searching. Something like the good old > findfirst/findnext of DOS: That's sound good to me. > module_t* enum_modules(module_t* prev, char* mod_name, int type) > prev: the result of previous call, NULL for 1st call > mod_name: name of the module we're searching for (when explicitly > named), > or NULL (when we list all modules) > type: some type value, like 0=static(builtin modules), 1=dinamic > -1=internal > (note: this field shouldn't be changed between the first and other > calls, and implementations may read it only at 1st call) > Mayeb it could be flags instead, ie 1, 2, 4, so they can be OR'ed Flags would make much more sense imho. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From andrej at lucky.net Sat Aug 16 11:33:00 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 16 Aug 2003 12:33:00 +0300 Subject: [MPlayer-G2-dev] Re: module_list vs. gui In-Reply-To: <20030816112120.2a5de617.albeu@free.fr> References: <200308121827.h7CIRlLh021292@mail.mplayerhq.hu> <20030816112120.2a5de617.albeu@free.fr> Message-ID: <20030816093300.GA21199@lucky.net> Hi, Alban Bedel! Sometime (on Saturday, August 16 at 12:21) I've received something... >Hi Arpi, >on Tue, 12 Aug 2003 20:27:47 +0200 you wrote: >> Hi, >> >> As I already found it, and tdoay Albeu asked too, there is a problem >> with the current config element type MODULE_LIST. [ ...skipped... ] It seems I never received message that Albeu answers. Is there problems with maillist or I have to kick ass of our postmaster? I still wonder why some of my earlier messages aren't answered too. :( With best wishes. Andriy. From FabianFranz at gmx.de Sun Aug 17 14:27:04 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 17 Aug 2003 14:27:04 +0200 Subject: [MPlayer-G2-dev] [PATCH] Fullscreen issues - g2 is great :-) Message-ID: <200308171427.08820.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I wanted to gain some experience in the field of fullscreen :-). (And g1 was sooooooooo slow in compiling that it was a pain to develop in it :)) ) So I started with g2 and it was astounishingly easy ... :) I create a second window on the fly if fullscreen, which I hacked in as I couldn't find the function, where events are parsed, is selected ... This window still needs to be removed of any decorations and so on, but one can guess what it will look like ... For that I had to "port" the aspect-code (copy & paste, and comment something out) ... That however gives some questions: - - Are two static variables that are global ok for the fullscreen and backup-window ? (only x11_helper.c affected) - - How can vo_xv, vo_x11 give the aspect code the correct screensize (vo_screenwidth, vo_screenheight) if it does not know about it ... -> The same goes for centering the picture (btw. I think this should go to aspect.c as it always the same and aspect.c renamed to helper or tools or similar ...) Of course, x11_helper.c could include aspect.h and set the aspect, when it knows about screenwidth, screenheight, but this gives the problems that gui-programmers NEED to do the same ... Which is bad, as they could get undesired behaviour and for fullscreen and don't know why ... Also for fullscreen I'm not satisfied with this code in x11_helper.c, as perhaps it would be nice to have this functions available for gui, but I dunno ... Should guis also use the helper-code ? I added screenwidth,height as global (I know its ugly) variables for now ... - - vo_x11 is always fullscreened to the widht, height, the window had ... Why is the RESIZE_CODE uncommented, it would be easier if it was handled that way ... In fullscreen resize-commands are ignored ... :) Btw. thanks for adding fullscreen flag to vo_instance_s :)). - - zoom parameter not yet accepted by vo_x11 (as there is no wide-used config layer yet ) So, I really like the new clean design ... Its really nice, with alle the events and callbacks handled nice and allowing finally to communicate with vo->layer :). cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/P3SbI0lSH7CXz7MRAl8CAJ9dBZJgEewnP/LXo3AdF68diknc1QCeNUp4 lmFJGfXKw+MGEaSOUabvSNM= =D0Nb -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-fs.diff Type: text/x-diff Size: 12669 bytes Desc: not available URL: From FabianFranz at gmx.de Sun Aug 17 14:44:16 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 17 Aug 2003 14:44:16 +0200 Subject: [MPlayer-G2-dev] [RIGHT-PATCH] Fullscreen issues - g2 is great :-) In-Reply-To: <200308171427.08820.FabianFranz@gmx.de> References: <200308171427.08820.FabianFranz@gmx.de> Message-ID: <200308171444.24038.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is more bad then to forget the patch ? To send broken patch ... Arggh, 10 l to me ... I wanted to get rid of some help var and did: vo->fullscreen=(int*)data, which obviously would not work ... as the pointer never was NULL ... vo->fullscreen=(int)*(int*)data; Was what I had intended ... int *fs; fs = (int*)data; vo->fullscreen=*fs; I had before :)) cu Fabian PS: Perhaps also: vo->fullscreen=*(int*)data would already be enough, but as I dunno and this one works I let it this way :)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/P3inI0lSH7CXz7MRArxQAJ941TOvOXh7Xs/A5QcD1Qif9aj/owCeM5wf rROW2KLOlOC40wm3ft/MfHc= =B7gn -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-fs.diff Type: text/x-diff Size: 12654 bytes Desc: not available URL: From pozsy at uhulinux.hu Sun Aug 17 17:44:08 2003 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Sun, 17 Aug 2003 17:44:08 +0200 (CEST) Subject: [MPlayer-G2-dev] [PATCH] Fullscreen issues - g2 is great :-) In-Reply-To: <200308171427.08820.FabianFranz@gmx.de> Message-ID: On Sun, 17 Aug 2003, Fabian Franz wrote: > I wanted to gain some experience in the field of fullscreen :-). (And g1 was > sooooooooo slow in compiling that it was a pain to develop in it :)) ) If compiling is slow, check out ccache (ccache.samba.org), it can really boost compile times! I use it all the time. (sorry for being a bit OT) -- pozsy From FabianFranz at gmx.de Sun Aug 17 18:09:10 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 17 Aug 2003 18:09:10 +0200 Subject: [MPlayer-G2-dev] [PATCH] Fullscreen issues - g2 is great :-) In-Reply-To: References: Message-ID: <200308171809.16787.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Sonntag, 17. August 2003 17:44 schrieb Pozsar Balazs: > On Sun, 17 Aug 2003, Fabian Franz wrote: > > I wanted to gain some experience in the field of fullscreen :-). (And g1 > > was sooooooooo slow in compiling that it was a pain to develop in it :)) > > ) > > If compiling is slow, check out ccache (ccache.samba.org), it can really > boost compile times! I use it all the time. No problem, I use ccache, but linking times of final binary are slow and mplayer is HUGE ... :-)) cu Fabian > > (sorry for being a bit OT) np, PS: I have an extended fullscreen-patch almost finished. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/P6iqI0lSH7CXz7MRAgqHAJ99pQKlHAzNpXl4FBo0DRnadz+SwgCfaWSv CN+uOKTUYSE0xRbSvXX5mMQ= =Upz1 -----END PGP SIGNATURE----- From arpi at thot.banki.hu Sun Aug 17 22:19:04 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 17 Aug 2003 20:19:04 -0000 Subject: [MPlayer-G2-dev] [RIGHT-PATCH] Fullscreen issues - g2 is great :-) In-Reply-To: <200308171444.24038.FabianFranz@gmx.de> Message-ID: <200308172018.h7HKIxar011496@mail.mplayerhq.hu> Hi, > > vo->fullscreen=(int)*(int*)data; > WTF? vo->fullscreen is a flag!!!!!! A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From arpi at thot.banki.hu Sun Aug 17 22:19:04 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 17 Aug 2003 20:19:04 -0000 Subject: [MPlayer-G2-dev] [PATCH] Fullscreen issues - g2 is great :-) In-Reply-To: <200308171427.08820.FabianFranz@gmx.de> Message-ID: <200308172018.h7HKIxJr011491@mail.mplayerhq.hu> Hi, > I wanted to gain some experience in the field of fullscreen :-). (And g1 was > sooooooooo slow in compiling that it was a pain to develop in it :)) ) lol > So I started with g2 and it was astounishingly easy ... :) > > I create a second window on the fly if fullscreen, which I hacked in as I > couldn't find the function, where events are parsed, is selected ... > > This window still needs to be removed of any decorations and so on, but one > can guess what it will look like ... > > For that I had to "port" the aspect-code (copy & paste, and comment something > out) ... ups > That however gives some questions: > > - - Are two static variables that are global ok for the fullscreen and > backup-window ? (only x11_helper.c affected) > - - How can vo_xv, vo_x11 give the aspect code the correct screensize > (vo_screenwidth, vo_screenheight) if it does not know about it ... the aspect thing should be handled by the vf layer. not vo. (since filters may resize/scale/rotate the image etc) the vo drivers should only export (in vo struct) the screen size and aspect. (this part still missing, patch welcomed) > -> The same goes for centering the picture (btw. I think this should go to > aspect.c as it always the same and aspect.c renamed to helper or tools or > similar ...) > Of course, x11_helper.c could include aspect.h and set the aspect, when it > knows about screenwidth, screenheight, but this gives the problems that > gui-programmers NEED to do the same ... Which is bad, as they could get > undesired behaviour and for fullscreen and don't know why ... > > Also for fullscreen I'm not satisfied with this code in x11_helper.c, as > perhaps it would be nice to have this functions available for gui, but I > dunno ... Should guis also use the helper-code ? Imho not. AT least in g1, gui had its own control of vo window, instead of using x11_common.c functions. I thought that in g2 I let the UI to handle the windows, but i provide a default/fallback implementation in x11_util If gui coders says they want to use those funcs, then we can re-thing the APIs. > I added screenwidth,height as global (I know its ugly) variables for now ... shit > - - vo_x11 is always fullscreened to the widht, height, the window had ... > Why is the RESIZE_CODE uncommented, it would be easier if it was handled > that way ... In fullscreen resize-commands are ignored ... :) huh? resizing is handled by vf layer, ecept when the vo driver support some kind of external (ie not swscaler) rescaling, in sdl or hardware. > Btw. thanks for adding fullscreen flag to vo_instance_s :)). > - - zoom parameter not yet accepted by vo_x11 (as there is no wide-used config > layer yet ) > > So, I really like the new clean design ... > > Its really nice, with alle the events and callbacks handled nice and allowing > finally to communicate with vo->layer :). you should read libvo2.txt before hack in more globals ;) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From FabianFranz at gmx.de Mon Aug 18 00:35:18 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 18 Aug 2003 00:35:18 +0200 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 Message-ID: <200308180035.22554.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, attached the new fs patch, especially for Gabucino to test it ... There are some issues: - - First: Design, this patch simply sucks. Its just a test suite for added x11_fs.c and for two window-system. So no resize, etc. ... This file is for guis and every code, that wants to use fullscreen (if with two windows or XReparentWindow). As it would be really bloat if each gui implemented this file itself ... I plan to make more functions static, all variables are already static and a header-file is missing, yet. This patch is NOT for inclusion. Its just for testers and people, who want to have fullscreen with g2 ;) - - Second issue is, that its all about timing, if you press 'f' at the right time, you get a good fullscreen-window else its not on top or not even there, just vanished ... Thats strange behaviour, but I guess there is somewhere a 10l I missed, yet ;) After you pressed f at leat 3 times it then does work: So the following should bring you always to good fullscreen-mode ;) : echo fff | ./test-play cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/QAMpI0lSH7CXz7MRAj36AJ0WUP6d7CBLmMk+A90JVonpIOeBLwCeMkW0 wppYZjkdWqYY1IcOYdfnaJ4= =Klkz -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-fs_v1.diff Type: text/x-diff Size: 27417 bytes Desc: not available URL: From FabianFranz at gmx.de Mon Aug 18 01:27:19 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 18 Aug 2003 01:27:19 +0200 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308180035.22554.FabianFranz@gmx.de> References: <200308180035.22554.FabianFranz@gmx.de> Message-ID: <200308180127.25316.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 18. August 2003 00:35 schrieb Fabian Franz: Updated version attached. Design still sucks, but fs is now always nice to use ... :) It seems that the Fullscreen window mustn't be visible, before its configured ... cu Fabian > Hi, > > attached the new fs patch, especially for Gabucino to test it ... > > There are some issues: > > - First: Design, this patch simply sucks. Its just a test suite for added > x11_fs.c and for two window-system. So no resize, etc. ... > > This file is for guis and every code, that wants to use fullscreen (if with > two windows or XReparentWindow). As it would be really bloat if each gui > implemented this file itself ... > > I plan to make more functions static, all variables are already static and > a header-file is missing, yet. > > This patch is NOT for inclusion. > > Its just for testers and people, who want to have fullscreen with g2 ;) > > - Second issue is, that its all about timing, if you press 'f' at the right > time, you get a good fullscreen-window else its not on top or not even > there, just vanished ... Thats strange behaviour, but I guess there is > somewhere a 10l I missed, yet ;) > After you pressed f at leat 3 times it then does work: > > So the following should bring you always to good fullscreen-mode ;) : > > echo fff | ./test-play > > cu > > Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/QA9bI0lSH7CXz7MRAqVlAJ9716lugGT1ubuIw1ilu5StHo1ZowCfdJXC uSPVseZbLInELn06cagerBs= =OZj3 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-fs_v2.diff Type: text/x-diff Size: 28356 bytes Desc: not available URL: From arpi at thot.banki.hu Tue Aug 19 15:37:51 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 19 Aug 2003 13:37:51 -0000 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308180035.22554.FabianFranz@gmx.de> Message-ID: <200308191337.h7JDbeBo012433@mail.mplayerhq.hu> Hi, > > This patch is NOT for inclusion. rotfl did you really think that i may apply this? :) aspct code in libvo is unacceptable. adding new code to each vo driver is unacceptable. using static vars is unacceptable. > - - Second issue is, that its all about timing, if you press 'f' at the right > time, you get a good fullscreen-window else its not on top or not even there, > just vanished ... Thats strange behaviour, but I guess there is somewhere a > 10l I missed, yet ;) > After you pressed f at leat 3 times it then does work: rotfl its about events, thre was such issue in g1 too years ago A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From FabianFranz at gmx.de Tue Aug 19 17:52:56 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Tue, 19 Aug 2003 17:52:56 +0200 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308191337.h7JDbeBo012433@mail.mplayerhq.hu> References: <200308191337.h7JDbeBo012433@mail.mplayerhq.hu> Message-ID: <200308191753.00335.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 1. Januar 1970 01:00 schrieb Arpi: > Hi, > > > This patch is NOT for inclusion. > > rotfl > > did you really think that i may apply this? :) No, but you flamed at my last "patch" ... So I did wrote this, to prevent any more ... :) ... Hm, didn't work ... Any other strategy ? ;) > > aspct code in libvo is unacceptable. of course .. > adding new code to each vo driver is unacceptable. yes > using static vars is unacceptable. yes > > > - - Second issue is, that its all about timing, if you press 'f' at the > > right time, you get a good fullscreen-window else its not on top or not > > even there, just vanished ... Thats strange behaviour, but I guess there > > is somewhere a 10l I missed, yet ;) > > After you pressed f at leat 3 times it then does work: > > rotfl > > its about events, thre was such issue in g1 too years ago Yeah, I sorted this out already ... :) Ok, back to business. What I am really missing is: How can I sent an event to move the "video surface" I think its called dest with the normal vo->event_callback-method, as MOVE just calls vo->control with RESIZE_DEST with -1,-1,-1,-1 and such just updating the video surface, but for aspect code I really need to "move" it. cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/QkfbI0lSH7CXz7MRAuEmAJ9bVbCCkt4Kwqkn5NVAP9bTaBGpTwCdGCsh KAbvyJmTsRmPdwxLqEvFLAQ= =yVJM -----END PGP SIGNATURE----- From arpi at thot.banki.hu Tue Aug 19 23:03:59 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 19 Aug 2003 21:03:59 -0000 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308191753.00335.FabianFranz@gmx.de> Message-ID: <200308192103.h7JL3nWE000570@mail.mplayerhq.hu> Hi, > What I am really missing is: > > How can I sent an event to move the "video surface" I think its called dest > with the normal vo->event_callback-method, as MOVE just calls vo->control > with RESIZE_DEST with -1,-1,-1,-1 and such just updating the video surface, > but for aspect code I really need to "move" it. send RESIZE_DEST control (not event, event is generated by the vo drivers not you!) to the current driver, to get the surface moved inside the window. but first the aspect stuff should be moved to vf layer. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From FabianFranz at gmx.de Tue Aug 19 23:00:49 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Tue, 19 Aug 2003 23:00:49 +0200 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308192103.h7JL3nWE000570@mail.mplayerhq.hu> References: <200308192103.h7JL3nWE000570@mail.mplayerhq.hu> Message-ID: <200308192300.54549.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 1. Januar 1970 01:00 schrieb Arpi: > Hi, > > > What I am really missing is: > > > > How can I sent an event to move the "video surface" I think its called > > dest with the normal vo->event_callback-method, as MOVE just calls > > vo->control with RESIZE_DEST with -1,-1,-1,-1 and such just updating the > > video surface, but for aspect code I really need to "move" it. > > send RESIZE_DEST control (not event, event is generated by the vo drivers > not you!) to the current driver, to get the surface moved inside the > window. ok, thats no problem for me, but vo_x11 does not handle RESIZE_DEST ... :-/ Can I change that behaviour ? That was the thing that really irritated me, that vo_x11 would not handle that part ... > > but first the aspect stuff should be moved to vf layer. yes, of course ... How can I transparently include/remove a filter in the queue from x11_helper.c ? Yes, I'll read TFS ... But it would be easier if there was docs or an smapll explaination by you :)) cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu > [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature > enabled] Wrong, the date is correct in that mail ;) > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/QpAFI0lSH7CXz7MRAkOzAJwJOQmLs78D3j6XgiuVdk2rTtvb4wCffkDz 7RnxTErFdnXNNFLdVN+/XbQ= =GFUA -----END PGP SIGNATURE----- From FabianFranz at gmx.de Wed Aug 20 01:51:11 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Wed, 20 Aug 2003 01:51:11 +0200 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE2] fullscreen again ... Message-ID: <200308200151.19003.FabianFranz@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, much cleaner, but not clean anough for A'rpi. ;) Still I don't understand the architecture enough, to change it accordingly ... So for now aspect-code is in x11_helper.c. However there are just 3 new global static vars... (and they _are_ needed) and 2 new EVENTS - FULLSCREEN & MOVIE, where the last sets the MOVIE-aspect, as I could not get this from vf_vo2 in any other way ... I can't see how to include aspect nicely with vf_layer from x11_helpers point of view ... Also you say, vo should not handle fullscreen directly and so on, but it has flags for vm, zoom, fs and flip ?! That seems to me a bit confusing ... cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/QrfyI0lSH7CXz7MRAs0hAJ4kk9GIBlXPAPyyrc/gOMpbHUoN9gCfQENP AROVD2Ilxz612q1uT2iliKg= =Qtwm -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-fs_v3.diff Type: text/x-diff Size: 26336 bytes Desc: not available URL: From arpi at thot.banki.hu Wed Aug 20 10:31:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 20 Aug 2003 08:31:17 -0000 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE] fullscreen-code from g1 In-Reply-To: <200308192300.54549.FabianFranz@gmx.de> Message-ID: <200308200831.h7K8VAEX015686@mail.mplayerhq.hu> Hi, > > > What I am really missing is: > > > > > > How can I sent an event to move the "video surface" I think its called > > > dest with the normal vo->event_callback-method, as MOVE just calls > > > vo->control with RESIZE_DEST with -1,-1,-1,-1 and such just updating the > > > video surface, but for aspect code I really need to "move" it. > > > > send RESIZE_DEST control (not event, event is generated by the vo drivers > > not you!) to the current driver, to get the surface moved inside the > > window. > > ok, thats no problem for me, but vo_x11 does not handle RESIZE_DEST ... :-/ then implement it... btw as we discussed a month ago here, the RESIZE_DEST should be split to MOVE and RESIZE. i'll do that once i'll be back at home. > Can I change that behaviour ? That was the thing that really irritated me, > that vo_x11 would not handle that part ... > > > > > but first the aspect stuff should be moved to vf layer. > > yes, of course ... > > How can I transparently include/remove a filter in the queue from x11_helper.c > ? you cant and you shouldnt. why do you want to do so? > > [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature > > enabled] > > Wrong, the date is correct in that mail ;) i also think the date is ok, but many ppl keep complaining about it the fun is that the same mua produces good date when run at mphq A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From arpi at thot.banki.hu Wed Aug 20 10:31:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 20 Aug 2003 08:31:17 -0000 Subject: [MPlayer-G2-dev] [PATCH][TESTSUITE2] fullscreen again ... In-Reply-To: <200308200151.19003.FabianFranz@gmx.de> Message-ID: <200308200831.h7K8VA6Z015698@mail.mplayerhq.hu> Hi, > I can't see how to include aspect nicely with vf_layer from x11_helpers point > of view ... i'll do that part then... > Also you say, vo should not handle fullscreen directly and so on, but it has > flags for vm, zoom, fs and flip ?! no, those flags are obsolete, and afair i already removed the flags param from config(). A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu [Using mailer3 v3.99pre3-CVS beta GSM edition, broken Date: feature enabled] From arpi at thot.banki.hu Fri Aug 22 02:41:07 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 22 Aug 2003 02:41:07 +0200 Subject: [MPlayer-G2-dev] pre41 released + aspect + fullscreen Message-ID: <200308220041.h7M0f7dX026484@mail.mplayerhq.hu> Hi, pre41: - libvo2: split VOCTRL_RESIZE_DEST to _RESIZE_DEST+_MOVE_DEST+_REDRAW - event.c: RESIZE now takes care of aspect ratio (vo drivers needs to be fixed to clear unused (out of buffer) area!!! patches wanted!) - dir c0nfigure renamed to confiG2ure :) - applied stream_ftp patch v3, ported by Fabian, original by Albeu So nothing interesting. For the aspect stuff: i've checked Fabian's fs patch, and the aspect.[ch] from g1 is something we NEVER ever want to see in g2. What it does is saving various parameters (orig, scaled, display w/h) to static vars via various functions, and then let s1 to read them back. Instead, we should have all the needed info in the vo struct, and do aspect calculation (hey, it's just a few lines, doesnt worth a new library) on-the-fly, ie. in the default event handler (event.c) or in the Gui. Now i've added a few lines to event.c to maintain aspect ratio when resizing, including 'maximize'. It's not final (may be inaccurate), we should add aspect w/h to vo struct, and let vf_vo2 set it at config(). Actually we should review/rework the aspect stuff of vf layer anyway, but it's another story, and it can be delayed. About the fullscreen switching: Fabian's patch "ported" most of the x11 fs code from g1 as-is. The main idea behind the 2 windows fs switching is to avoid all that mess. At least it works in xine, i remember seeing a half screen long fs switching code there using 2 windows. No messing with WM hints, etc, just create a window with some special flags. I'm not an X11 guru, not even a X11 newbie, so i can't decide hwo can it be done, but I think (at least hope) that porting that mess from g1 is not the Right Way. Note, that gtk and SDL also uses 2 window method for fs switch, and they both work since ages, without the need for that fs mess and commandline switches and WM patches we hacked together in g1. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri Aug 22 03:09:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 22 Aug 2003 03:09:43 +0200 Subject: [MPlayer-G2-dev] pre41 released + aspect + fullscreen In-Reply-To: <200308220041.h7M0f7dX026484@mail.mplayerhq.hu> Message-ID: <200308220109.h7M19hWP003886@mail.mplayerhq.hu> Hi, > About the fullscreen switching: Fabian's patch "ported" most of the x11 > fs code from g1 as-is. The main idea behind the 2 windows fs switching is to > avoid all that mess. At least it works in xine, i remember seeing a half > screen long fs switching code there using 2 windows. No messing with WM > hints, etc, just create a window with some special flags. I'm not an X11 > guru, not even a X11 newbie, so i can't decide hwo can it be done, but I > think (at least hope) that porting that mess from g1 is not the Right Way. > Note, that gtk and SDL also uses 2 window method for fs switch, and they > both work since ages, without the need for that fs mess and commandline > switches and WM patches we hacked together in g1. /xine-lib/doc/hackersguide/hackersguide.sgml:1581: Source code of a simple X11 frontend .. window[0] = XCreateSimpleWindow(display, XDefaultRootWindow(display), xpos, ypos, width, height, 1, 0, 0); window[1] = XCreateSimpleWindow(display, XDefaultRootWindow(display), 0, 0, (DisplayWidth(display, screen)), (DisplayHeight(display, screen)), 0, 0, 0); XSelectInput(display, window[0], (ExposureMask | ButtonPressMask | KeyPressMask | ButtonMotionMask | StructureNotifyMask | PropertyChangeMask | PointerMotionMask)); XSelectInput(display, window[1], (ExposureMask | ButtonPressMask | KeyPressMask | ButtonMotionMask | StructureNotifyMask | PropertyChangeMask | PointerMotionMask)); XA_NO_BORDER = XInternAtom(display, "_MOTIF_WM_HINTS", False); mwmhints.flags = MWM_HINTS_DECORATIONS; mwmhints.decorations = 0; XChangeProperty(display, window[1], XA_NO_BORDER, XA_NO_BORDER, 32, PropModeReplace, (unsigned char *) &mwmhints, PROP_MWM_HINTS_ELEMENTS); XMapRaised(display, window[fullscreen]); and then the FS switching code: case XK_F: { Window tmp_win; XLockDisplay(display); XUnmapWindow(display, window[fullscreen]); fullscreen = !fullscreen; XMapRaised(display, window[fullscreen]); XSync(display, False); XTranslateCoordinates(display, window[fullscreen], DefaultRootWindow(display), 0, 0, &xpos, &ypos, &tmp_win); XUnlockDisplay(display); xine_gui_send_vo_data(stream, XINE_GUI_SEND_DRAWABLE_CHANGED, (void*) window[fullscreen]); } break; So, this seems to be quite clean and easy, at least compared to g1's x11_common.c or Fabian's patches :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri Aug 22 21:48:58 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 22 Aug 2003 21:48:58 +0200 Subject: [MPlayer-G2-dev] [?] hit 3 flies - aspect ratio, resize, query_format Message-ID: <200308221948.h7MJmwZW017658@mail.mplayerhq.hu> Hi, I'm trying to solve several design issues/problems/ideas around the image size, including the bypassing buffer size to vo driver in query_format, aspect ratio handling in vf layer, cleanup of VFCTRL_RESIZE. After several hours of analyzing ideas, i'm still in doubt, but here is what i found out the best: feel free to tell me better solutions or point out possible problems with this method! I would extend vf's query_format() by a int p[6] parameter. (actually int* size, which points to an array of 6 integers) these 6 values are: buff_w, buff_h - w/h of the image buffer (real pixels) disp_w, disp_h - pre-scaled w/h (recommended display size) [for startup] want_w, want_h - wanted output size [for window resizing] query_format() of 'normal' filters (which dont alter aspect ratio nor buffer size) would just pass thru the pointer to next filter. other filters shoudl implement it this way: query_format(...){ - change buff_w/h (only filters which chaneg buffer dimensios) - change disp_w/h (only filters which change aspect ratio) - call next filter's query_format() - change want_w/h (only filters which change buffer dimensios) } also, the scaling flags of vfcap.h shoudl be reviewed: merging HSWSCALE_UP and HWSCALE_DOWN, it ha sno sence to keep them separated. query_format() implementations can now check source and dest resolution so can decide if sw/hw scaling is possible or not. if they can do the scaling (or resize), they should change the want_w/h values. otherwise left unchanged. actually buff_* and disp_* are the current w/h pairs passed in vf->config(). buff-* is the real (phisical) size of the buffer, ignoring any kind of apect ratios. it's originally the width/height of the movie, altered by filters which change the buffer dimensions (so scale, crop, expand, rotate). disp_* are the scaled (by movie aspect, and aspect changes by filters) dimensions. this can be used to get the final aspect ratio at the end (vo). if we put the prescale dmovei size into it at the top, we'll get the recommended display window size. it's useful for startup, before the window created. want_* are the values from current VFCTRL_RESIZE. it's the wanted output size (values of disp_* at the end of chain, ie. at vo). it's useful when the user resized the window by mouse, or switched to fullscreen. we can calculate dimenstions backward. value of want_* may be 0 (or -1?), in this case the final values of disp_* will be copied at the end of chain (vf_vo2). I would also change config() of vf layer. The second w/h pair (d_width/h_height) will be the wanted w/h. config() functions shouldn't change it. But the filters which are able to do some kind of resizing, should call query_format of next filter from config(), to check if the rest of the filter chain is able to fulfill the resizing request (to wanted w/h), and do it otherwise. Ok, I see (know) this sounds very complex. But at least quite easy to implement (but a big work, mostly testing and discovering hidden side-effects and tricks used in current filters). Also it affects special (size/aspect changig) filters only, so only a few. (the rest should be changed to byupass new parameter of query_format, but it has rto be done anyway to solve vo->query_format problem (some vo supports some colorspaces only at limited size range, same for scaling) Comments? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu