From arpi at thot.banki.hu Sun Jul 6 01:13:36 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 6 Jul 2003 01:13:36 +0200 Subject: [MPlayer-G2-dev] pre32 released! Message-ID: <200307052313.h65NDa4j028751@mail.mplayerhq.hu> Hi, mphq/~arpi/g2/mplayer-G2-preview32.tar.gz pre32: - cvs up (libavcodec, swscale, mp3lib updated) - input support into test-play - codec-cfg.c updated to use img_format.* functions for fourcc<->name - audio-only fixes (sleep, print status etc) - x11 framework code separated to libvo2/x11_common.c. event check/handle code ported from g1 (ugly, needs cleanup/rewrite!), now it handles key and move/resize events from the window. works well with -vo xv now test-play is somewhat usable as a commandline player :) ok, no seeking yet, i'm working on it. also no fullscreen switching, someone with X11 knowledge and enough patience should implement that. (i would go for the 2 windows solution used by SDL and xine too, instead of our -fstype hacks with single window, but you know) i've copypasted lots of code from g1's libvo to x11_common.c to get x11 things (window move/resize, keyboard events) functioning somewhat. it's very ugly, has lots of globals and so on, someone should cleanup/rewrite that. read DOCS/tech/libvo2.txt before you start. note that in libvo2, the x11 vo drivers do just the rendering, all the window handling work is done by the next layer, currently implemented in x11_common.c it must be independent layer, so gui developers (who want to control video window directly, for example embed it in a browser or skinned player) can replace it with their implementation. 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 Jul 7 02:58:29 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 7 Jul 2003 02:58:29 +0200 Subject: [MPlayer-G2-dev] pre32 released! In-Reply-To: <200307052313.h65NDa4j028751@mail.mplayerhq.hu> Message-ID: <200307070058.h670wTHX023045@mail.mplayerhq.hu> Hi, > mphq/~arpi/g2/mplayer-G2-preview32.tar.gz mphq/~arpi/g2/mplayer-G2-preview33.tar.gz pre33: - vd_ffmpeg + mpeg4 + slices fixed - initial seeking support, not finished yet (no keyframe search, no audio skip, no auto index handler, buggy with libmpeg2) - various small fixes 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 Jul 7 03:33:17 2003 From: ajh at watri.org.au (Anders Johansson) Date: Mon, 7 Jul 2003 09:33:17 +0800 Subject: [MPlayer-G2-dev] pre32 released! In-Reply-To: <200307070058.h670wTHX023045@mail.mplayerhq.hu> References: <200307052313.h65NDa4j028751@mail.mplayerhq.hu> <200307070058.h670wTHX023045@mail.mplayerhq.hu> Message-ID: <20030707013317.GC32263@watri.org.au> Hi, I have a working prototype of the new ao. Do you want me to try to include it in g2 or g1? > Hi, > > > mphq/~arpi/g2/mplayer-G2-preview32.tar.gz > mphq/~arpi/g2/mplayer-G2-preview33.tar.gz > > pre33: > - vd_ffmpeg + mpeg4 + slices fixed > - initial seeking support, not finished yet (no keyframe search, no audio skip, > no auto index handler, buggy with libmpeg2) > - various small fixes > > > A'rpi / Astral & ESP-team > //Anders From arpi at thot.banki.hu Mon Jul 7 03:50:23 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 7 Jul 2003 03:50:23 +0200 Subject: [MPlayer-G2-dev] pre32 released! In-Reply-To: <20030707013317.GC32263@watri.org.au> Message-ID: <200307070150.h671oNDu028936@mail.mplayerhq.hu> Hi, > Hi, > > I have a working prototype of the new ao. Do you want me to try to could you send it to me? > include it in g2 or g1? i'm interested in g2 only imho it has no much sense to put more development to g1, as g2 will be usabel in very soon (actually it's already usable, just need to port all demuxers/codecs/filters/vo drivers from g1 and finish the CLI) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon Jul 7 08:11:57 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 7 Jul 2003 09:11:57 +0300 Subject: [MPlayer-G2-dev] Re: pre32 released! In-Reply-To: <200307070058.h670wTHX023045@mail.mplayerhq.hu> References: <200307052313.h65NDa4j028751@mail.mplayerhq.hu> <200307070058.h670wTHX023045@mail.mplayerhq.hu> Message-ID: <20030707061157.GB88734@lucky.net> Hi, Arpi! Sometime (on Monday, July 7 at 3:54) I've received something... >> mphq/~arpi/g2/mplayer-G2-preview32.tar.gz >mphq/~arpi/g2/mplayer-G2-preview33.tar.gz How about config stuff that we discussed last time? :) I wanted to work on fame encoder but I want resolve all config items (are still TODO yet) before that. With best wishes. Andriy. From arpi at thot.banki.hu Mon Jul 7 23:14:00 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 7 Jul 2003 23:14:00 +0200 Subject: [MPlayer-G2-dev] libvo2 api/design problem Message-ID: <200307072114.h67LE0Cl008941@mail.mplayerhq.hu> Hi, There is soem design issue with the X11 and non-X11 vo2 drivers. As we decided & implemented, vo drivers doesnt have window management code, they receive display (at preinit) and window (via control) IDs and render the image there. I won't plan to change this! The only problem, is that it isn't visible from outside if a given vo driver uses X11 or not. So currently (in pre33) every vo driver gets an X11 window (even -vo null)... The original idea was that open X11 if available (vo_x11_init()), and pass teh display ID/handle to vo's preinit() function, so drivers supporting X11 can access the connection (and check device/driver caps, like Xv, DGA or GLX availability). But we have to know if the given driver actually uses that X11 handle, or ignored it. Currently this is not solved. Now when a vo driver is configured, vo->event_callback is called wiht VO_EVENT_CONFIG, so the event handler can open a window and set it via the VOCTRL_SET_WINDOW control(). I 2 possible solutions: 1. assume that every vo device with name beginning wiht char 'x' is x11 device. so xv, xmga, xvidix, xgl... it sounds quite lame, but this is the only way to know if a driver is x11 or non-x11 driver, before calling preinit(). it may be interesting for a GUI or even for a CLI app to know which drivers require X11 or which drivers won't use X11 (if the GUI has embedded winde, liek a browser plugin). 2. instead of using VO_EVENT_CONFIG to requiest teh window, we could define VO_EVENT_SET_WINDOW or so, so x11 drivers can ask for a window (at config()) if not yet set (via control()). A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lgb at lgb.hu Mon Jul 7 23:35:20 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Mon, 7 Jul 2003 23:35:20 +0200 Subject: [MPlayer-G2-dev] libvo2 api/design problem In-Reply-To: <200307072114.h67LE0Cl008941@mail.mplayerhq.hu> References: <200307072114.h67LE0Cl008941@mail.mplayerhq.hu> Message-ID: <20030707213520.GD7938@vega.digitel2002.hu> On Mon, Jul 07, 2003 at 11:14:00PM +0200, Arpi wrote: > Now when a vo driver is configured, vo->event_callback is called > wiht VO_EVENT_CONFIG, so the event handler can open a window and set > it via the VOCTRL_SET_WINDOW control(). > > I 2 possible solutions: > 1. assume that every vo device with name beginning wiht char 'x' is x11 > device. so xv, xmga, xvidix, xgl... > it sounds quite lame, but this is the only way to know if a driver is > x11 or non-x11 driver, before calling preinit(). it may be interesting > for a GUI or even for a CLI app to know which drivers require X11 or > which drivers won't use X11 (if the GUI has embedded winde, liek a > browser plugin). > 2. instead of using VO_EVENT_CONFIG to requiest teh window, we could > define VO_EVENT_SET_WINDOW or so, so x11 drivers can ask for a > window (at config()) if not yet set (via control()). I guess idea #2 looks more familiar at least for me. It's more clear even from the point of view of modularization. But #1 is interesting as well, however for THIS single problem #2 is better, IMHO. Of course it will be also good to have some dependency information without messing with vo drivers, but it can be easily implemented to extend the vo_info_t structure with some 'dependency' flags (X11 dependent vo, etc, maybe other good ideas as well). Also I think, some of the VOs should be NOT available for an average GUI, because GUI users often does not know too much about program internals, and so, that's why -vo mga will be VERY annoying for them (you can't make them understand that -vo mga will produce only an overlay and not a window at the point of X). For them only xmga, or xv can be assumed as selectable vo drivers. But maybe not :) Also, for eg builing plugger for browsers requires replacing x11_common.c. It would be better to provide some call mechanism to allow to UI frontend coders to easily pass some function pointers or something with their own functions without replacing code, also it would allow to link together the object files with a plugger skeleton, then with mplayer CLI skeleton etc, without tricking x11_common.c and their replacments. So modularization :) - G?bor (larta'H) From kinali at gmx.net Mon Jul 7 23:49:57 2003 From: kinali at gmx.net (Attila Kinali) Date: Mon, 7 Jul 2003 23:49:57 +0200 Subject: [MPlayer-G2-dev] libvo2 api/design problem In-Reply-To: <200307072114.h67LE0Cl008941@mail.mplayerhq.hu> References: <200307072114.h67LE0Cl008941@mail.mplayerhq.hu> Message-ID: <20030707234957.51df0516.kinali@gmx.net> On Mon, 7 Jul 2003 23:14:00 +0200 Arpi wrote: > I 2 possible solutions: > 1. assume that every vo device with name beginning wiht char 'x' is x11 > device. so xv, xmga, xvidix, xgl... > it sounds quite lame, but this is the only way to know if a driver is > x11 or non-x11 driver, before calling preinit(). it may be interesting > for a GUI or even for a CLI app to know which drivers require X11 or > which drivers won't use X11 (if the GUI has embedded winde, liek a > browser plugin). > 2. instead of using VO_EVENT_CONFIG to requiest teh window, we could > define VO_EVENT_SET_WINDOW or so, so x11 drivers can ask for a > window (at config()) if not yet set (via control()). I'd prefere #1, but would extend the vo_info_t structure by a special requirements field and put there a VO_NEED_X11 or something like that. Attila Kinali -- Emacs ist f?r mich kein Editor. F?r mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (f?r die Sonntagbr?tchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtl?nge bekomme. Ich wei? nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion From pontscho at kac.poliod.hu Tue Jul 8 10:22:19 2003 From: pontscho at kac.poliod.hu (Zoltan Ponekker) Date: Tue, 8 Jul 2003 10:22:19 +0200 (CEST) Subject: [MPlayer-G2-dev] libvo2 api/design problem In-Reply-To: <20030707234957.51df0516.kinali@gmx.net> Message-ID: Hali > I'd prefere #1, but would extend the vo_info_t structure by > a special requirements field and put there a VO_NEED_X11 or something > like that. Me too. Pontscho / fresh!mindworkz --- MPlayer Core Team - www.MPlayerHQ.hu From albeu at free.fr Tue Jul 8 11:20:49 2003 From: albeu at free.fr (Alban Bedel) Date: Tue, 8 Jul 2003 11:20:49 +0200 Subject: [MPlayer-G2-dev] Re: libvo2 api/design problem References: <20030707234957.51df0516.kinali@gmx.net> Message-ID: <20030708112049.618736ff.albeu@free.fr> Hi Zoltan Ponekker, on Tue, 8 Jul 2003 10:22:19 +0200 (CEST) you wrote: > > Hali > > > I'd prefere #1, but would extend the vo_info_t structure by > > a special requirements field and put there a VO_NEED_X11 or something > > like that. > > Me too. I'd like to see smthg like VO_X11_CAPS wich mean that the vo can optionaly use a provided window (like tdfx_vid, mga?, etc). These won't fail if a window isn't avaible. And VO_NEED_X11 for the vo's wich always need a window (x11,xv,etc). Imho smtgh in the lines of vo_xover could be intersting too. This is for vo's wich use an overlay with colorkey (pretty common in our case). I'm too lazy to try to explain xover, so below is some g1 psedo-code. xover_preinit(subvo) { // subvo is another vo wich must support xover controls subvo->control(VO_CTRL_HAS_XOVER, ...); // check api support subvo->preinit; // First look if the subvo work x11_preinit; } xover_config( ... ) { subvo->config( ... ); // A flag is passed to make the subvo know that he is under xover setup_x11_win; // see vo_xover, vo_xmga or vo_xvidix ;) subvo->control(VO_CTRL_SET_COLORKEY, ...); // Set the colorkey subvo->control(VO_CTRL_SET_WIN, ... ); // Set the position/size of the overlay } xover_check_event( ) { if(check_x11_event()) // Check for window move/resize subvo->control(VO_CTRL_SET_WIN, ... ); subvo->check_event; } All other call are (more or less) directly passed to the subvo. So vo's wich support this little 'api' get automatic x11 support. Another advantage of such method is that it can be used with any windowing system. I didn't looked libvo2 yet but it's probably easy to have something similar in a cleaner way. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Tue Jul 8 12:39:41 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 8 Jul 2003 12:39:41 +0200 Subject: [MPlayer-G2-dev] Re: libvo2 api/design problem In-Reply-To: <20030708112049.618736ff.albeu@free.fr> Message-ID: <200307081039.h68AdfhY013660@mail.mplayerhq.hu> Hi, > > > I'd prefere #1, but would extend the vo_info_t structure by the problem is that no such thing called vo_info_t there is now module_t which is common for all module types (i didn't like the common info_t thingie, but i ack it's required for nice config and plugin management code). > > > a special requirements field and put there a VO_NEED_X11 or something > > > like that. > > > > Me too. > I'd like to see smthg like VO_X11_CAPS wich mean that the vo can > optionaly use a provided window (like tdfx_vid, mga?, etc). > These won't fail if a window isn't avaible. > And VO_NEED_X11 for the vo's wich always need a window (x11,xv,etc). > > Imho smtgh in the lines of vo_xover could be intersting too. This is for > vo's wich use an overlay with colorkey (pretty common in our case). > I'm too lazy to try to explain xover, so below is some g1 psedo-code. yes, we definitly need something like this. Nick's vosub_*.c in g1 tried to implement the same as you in vo_xover (but he added support for vosub into vo_vesa and vo_fbdev too). We need to define a standard way of linking overlay and parent drivers, so every overlay-type driver (be it mga, tdfx, vidix or even dxr3) could be used with "parent" drivers: x11 (xover), vesa, fbdev, svgalib etc. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ajh at watri.org.au Thu Jul 10 02:39:17 2003 From: ajh at watri.org.au (Anders Johansson) Date: Thu, 10 Jul 2003 08:39:17 +0800 Subject: [MPlayer-G2-dev] Re: libvo2 api/design problem In-Reply-To: <200307081039.h68AdfhY013660@mail.mplayerhq.hu> References: <20030708112049.618736ff.albeu@free.fr> <200307081039.h68AdfhY013660@mail.mplayerhq.hu> Message-ID: <20030710003917.GD32263@watri.org.au> Hi, > Hi, > > > > > I'd prefere #1, but would extend the vo_info_t structure by > > the problem is that no such thing called vo_info_t > there is now module_t which is common for all module types > (i didn't like the common info_t thingie, but i ack it's required for > nice config and plugin management code). Why not using the flag field? the upper 16 bits could be used for module specific info? I wouild like this for af as well. //Anders From albeu at free.fr Thu Jul 10 13:20:30 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 10 Jul 2003 13:20:30 +0200 Subject: [MPlayer-G2-dev] Subtitles demuxer Message-ID: <20030710132030.1aa5dc37.albeu@free.fr> Hi, I started to do some g2 hacking with $SUBJ. I added subtitles stream to the demux_find_streams function and wrote a simple mpsub demuxer. To test that i added a quick hack to test-play to show the subs on the terminal. Sadly i have atm no good movie / subtitle combination to do proper test about the sync but it seems to be ok. The demuxer don't do autodetection atm so you have to force it : test-play -sub subfile -subdemuxer txtsub Now this is only a quick hack to have some thing comming out of the demuxer level. I'd like to know what are the plans for the subtitles decoding/filtering/output. If there are any ;) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-subs.diff Type: application/octet-stream Size: 10842 bytes Desc: not available URL: From arpi at thot.banki.hu Thu Jul 10 14:41:40 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 10 Jul 2003 14:41:40 +0200 Subject: [MPlayer-G2-dev] Subtitles demuxer In-Reply-To: <20030710132030.1aa5dc37.albeu@free.fr> Message-ID: <200307101241.h6ACfeRc029269@mail.mplayerhq.hu> Hi, > I started to do some g2 hacking with $SUBJ. I added subtitles stream to > the demux_find_streams function and wrote a simple mpsub demuxer. > > To test that i added a quick hack to test-play to show the subs on the > terminal. Sadly i have atm no good movie / subtitle combination > to do proper test about the sync but it seems to be ok. > > The demuxer don't do autodetection atm so you have to force it : > test-play -sub subfile -subdemuxer txtsub the patch looks ok, i'll apply > Now this is only a quick hack to have some thing comming out of the > demuxer level. I'd like to know what are the plans for the subtitles > decoding/filtering/output. If there are any ;) plans: not really, i have only ideas. someone really should sit down and design the API for subtitle/osd stuff. maybe these 2 (osd and subs) shouldnt be mixed (keep them as 2 independent layer). what do we need: - define subtitle stream formats (like ascii, html?, spu etc) - maybe define subtitles decoder/filter/encoder layer (like vd/vf/ve in video/) sub filters may do things like subdelay/fps change, codepage conversion, word-wrapping etc. en/decoders may do spu<->bitmap conversion, text->bitmap->spu, spu->ocr->text :) we also need to define the OSD api. it is harder. wanted features, ideas: - allow several independent osd "zones". for example it could allow putting osd (including subs) bellow & above the video image, but not over it, thus allowing full DR. or it could allow OSD to external LCD device or second display (for example playback video to TVout but display OSD on monitor/gui/lcd) or it could define osd zone over the image, and another bellow the image, so the over-image one will be scaled by BES (it could be used to display progress bar/volume symbols etc) the bellow one (unscaled) could be used for nice subtitles. - it should support differential remove/draw, like in g1, so devices with hardware osd but slow osd-ram access (like DVB or PVR-350) could benefit. - it should allow full control over osd to the UI, so UI can put its own messages. it would be better if the UI moves the subtitle osd to the osd engine, maybe via setting a callback. - support for direct rendering compressed subs, ie. direct dvd->dxr3 spu transfer without decoding spu, osd engine, encoding. maybe it doesnt worth the extra complexity? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Thu Jul 10 15:26:59 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 10 Jul 2003 15:26:59 +0200 Subject: [MPlayer-G2-dev] Re: Subtitles demuxer References: <20030710132030.1aa5dc37.albeu@free.fr> <200307101241.h6ACfeRc029269@mail.mplayerhq.hu> Message-ID: <20030710152659.7300ba17.albeu@free.fr> Hi Arpi, on Thu, 10 Jul 2003 14:41:40 +0200 you wrote: > Hi, > > > I started to do some g2 hacking with $SUBJ. I added subtitles stream > > to the demux_find_streams function and wrote a simple mpsub demuxer. > > > > To test that i added a quick hack to test-play to show the subs on the > > terminal. Sadly i have atm no good movie / subtitle combination > > to do proper test about the sync but it seems to be ok. > > > > The demuxer don't do autodetection atm so you have to force it : > > test-play -sub subfile -subdemuxer txtsub > > the patch looks ok, i'll apply > > > Now this is only a quick hack to have some thing comming out of the > > demuxer level. I'd like to know what are the plans for the subtitles > > decoding/filtering/output. If there are any ;) > > plans: not really, i have only ideas. > someone really should sit down and design the API for subtitle/osd > stuff. maybe these 2 (osd and subs) shouldnt be mixed (keep them as 2 > independent layer). I think so too. > what do we need: > - define subtitle stream formats (like ascii, html?, spu etc) Yes. Most text stuff won't need much info,but stuff like spu need resolution, colorspace, extra header and so on. While looking at sh_video i think 90% of the fields present there might be useful for subtitles too. > - maybe define subtitles decoder/filter/encoder layer (like vd/vf/ve in > video/) > sub filters may do things like subdelay/fps change, codepage > conversion, word-wrapping etc. en/decoders may do spu<->bitmap > conversion, text->bitmap->spu, spu->ocr->text :) Ok glad to see that we are thinking about the same thing :) Beeing able to use standard vf would be nice, alpha would be nice too. > we also need to define the OSD api. it is harder. > wanted features, ideas: > - allow several independent osd "zones". > for example it could allow putting osd (including subs) bellow & above > the video image, but not over it, thus allowing full DR. > or it could allow OSD to external LCD device or second display (for > example playback video to TVout but display OSD on monitor/gui/lcd) > or it could define osd zone over the image, and another bellow the > image, so the over-image one will be scaled by BES (it could be used > to display progress bar/volume symbols etc) the bellow one (unscaled) > could be used for nice subtitles. With LCD do you mean the graphic or text devices ? > - it should support differential remove/draw, like in g1, so devices > with > hardware osd but slow osd-ram access (like DVB or PVR-350) could > benefit. > - it should allow full control over osd to the UI, so UI can put its own > messages. it would be better if the UI moves the subtitle osd to the > osd engine, maybe via setting a callback. > - support for direct rendering compressed subs, ie. direct dvd->dxr3 spu > transfer without decoding spu, osd engine, encoding. maybe it doesnt > worth the extra complexity? Plain text is also usable for aa lib :) So this would mean that the subtiles chain must be able to output to the osd engine or the vo. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Thu Jul 10 18:20:09 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 10 Jul 2003 18:20:09 +0200 Subject: [MPlayer-G2-dev] Re: Subtitles demuxer In-Reply-To: <20030710152659.7300ba17.albeu@free.fr> Message-ID: <200307101620.h6AGK9J9004512@mail.mplayerhq.hu> Hi, > > > I started to do some g2 hacking with $SUBJ. I added subtitles stream > > > to the demux_find_streams function and wrote a simple mpsub demuxer. > > > > > > To test that i added a quick hack to test-play to show the subs on the > > > terminal. Sadly i have atm no good movie / subtitle combination > > > to do proper test about the sync but it seems to be ok. > > > > > > The demuxer don't do autodetection atm so you have to force it : > > > test-play -sub subfile -subdemuxer txtsub > > > > the patch looks ok, i'll apply > > > > > Now this is only a quick hack to have some thing comming out of the > > > demuxer level. I'd like to know what are the plans for the subtitles > > > decoding/filtering/output. If there are any ;) > > > > plans: not really, i have only ideas. > > someone really should sit down and design the API for subtitle/osd > > stuff. maybe these 2 (osd and subs) shouldnt be mixed (keep them as 2 > > independent layer). > I think so too. > > > what do we need: > > - define subtitle stream formats (like ascii, html?, spu etc) > Yes. Most text stuff won't need much info,but stuff like spu need > resolution, colorspace, extra header and so on. While looking at > sh_video i think 90% of the fields present there might be useful > for subtitles too. imho its not a good idea to share that struct, we should define sh_subtitle then > > - maybe define subtitles decoder/filter/encoder layer (like vd/vf/ve in > > video/) > > sub filters may do things like subdelay/fps change, codepage > > conversion, word-wrapping etc. en/decoders may do spu<->bitmap > > conversion, text->bitmap->spu, spu->ocr->text :) > Ok glad to see that we are thinking about the same thing :) :) > Beeing able to use standard vf would be nice, alpha would be nice too. disagree mixing vf layer into subtitles is a very bad idea imho and anyway most vf filters are useless for subtitles, while it adds extra complexity to vf's > > we also need to define the OSD api. it is harder. > > wanted features, ideas: > > - allow several independent osd "zones". > > for example it could allow putting osd (including subs) bellow & above > > the video image, but not over it, thus allowing full DR. > > or it could allow OSD to external LCD device or second display (for > > example playback video to TVout but display OSD on monitor/gui/lcd) > > or it could define osd zone over the image, and another bellow the > > image, so the over-image one will be scaled by BES (it could be used > > to display progress bar/volume symbols etc) the bellow one (unscaled) > > could be used for nice subtitles. > With LCD do you mean the graphic or text devices ? i meant graphic, but now so you mentioned, we should think of text ones too > > - it should support differential remove/draw, like in g1, so devices > > with > > hardware osd but slow osd-ram access (like DVB or PVR-350) could > > benefit. > > - it should allow full control over osd to the UI, so UI can put its own > > messages. it would be better if the UI moves the subtitle osd to the > > osd engine, maybe via setting a callback. > > - support for direct rendering compressed subs, ie. direct dvd->dxr3 spu > > transfer without decoding spu, osd engine, encoding. maybe it doesnt > > worth the extra complexity? > Plain text is also usable for aa lib :) So this would mean that the > subtiles chain must be able to output to the osd engine or the vo. or we should allow osd layer to export in multiple formats, not only bitmap (btw it should support colors too, not only Y+A) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lgb at lgb.hu Fri Jul 11 09:22:41 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Fri, 11 Jul 2003 09:22:41 +0200 Subject: [MPlayer-G2-dev] Re: Subtitles demuxer In-Reply-To: <200307101620.h6AGK9J9004512@mail.mplayerhq.hu> References: <20030710152659.7300ba17.albeu@free.fr> <200307101620.h6AGK9J9004512@mail.mplayerhq.hu> Message-ID: <20030711072241.GB10766@vega.digitel2002.hu> What about -so switch? :) -ao Audio Output -vo Video Output -so Subtitle Output So someone can implement several subtitle output drivers (sure, the most natural one for most people is to display "on" the movie or similar), even like the solution to feed subtitles to external program like a speech synth software, or to LCD panel or anything :) Also, instead of a single linked list for storing subtitles inside the memory during playing should be extended to have even multiple ones, so eg you can load multiple subtitles at the simetime and switch between them real-time. Eg for several movies I have multiple subtitles, and sometimes it would be nice to switch between them without restart mplayer of course ... - G?bor (larta'H) From jjermann at gmx.net Fri Jul 11 10:44:59 2003 From: jjermann at gmx.net (Jonas Jermann) Date: Fri, 11 Jul 2003 10:44:59 +0200 Subject: [MPlayer-G2-dev] Re: Subtitles demuxer In-Reply-To: <20030711072241.GB10766@vega.digitel2002.hu> References: <20030710152659.7300ba17.albeu@free.fr> <200307101620.h6AGK9J9004512@mail.mplayerhq.hu> <20030711072241.GB10766@vega.digitel2002.hu> Message-ID: <20030711084459.GA679@morannon> On Fri, Jul 11, 2003 at 09:22:41AM +0200, G?bor L?n?rt wrote: > What about -so switch? :) > -ao Audio Output > -vo Video Output > -so Subtitle Output Hehe. I like the idea, what about -sf, -sc, -sfm, -se? ;) Regards Jonas From arpi at thot.banki.hu Sat Jul 12 19:16:30 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 12 Jul 2003 19:16:30 +0200 Subject: [MPlayer-G2-dev] Re: libvo2 api/design problem In-Reply-To: <20030708112049.618736ff.albeu@free.fr> Message-ID: <200307121716.h6CHGUxl017540@mail.mplayerhq.hu> Hi, > > > I'd prefere #1, but would extend the vo_info_t structure by > > > a special requirements field and put there a VO_NEED_X11 or something > > > like that. > > > > Me too. Ok i've extended the module_info_t wtsurtc with a flags field, low 16 bit is generic, upper 16 bits are module type dependant. > I'd like to see smthg like VO_X11_CAPS wich mean that the vo can > optionaly use a provided window (like tdfx_vid, mga?, etc). > These won't fail if a window isn't avaible. Are there any vo driver which may work with and without X11 ? (assuming we're implementing parent-child system for overlays like mga or tdfx_vid to work with x11, fbdev, vesa etc) I guess no, so i left ot out for now. My idea for the vo2 module capabilities flags: //****** vo2 specific module_info_t flags: ******** // module can work as parent for other sub-vo module (xover, vesa, fbdev...) #define VO_MODULE_CAPS_PARENT 0x10000 // module can work as child or other parent module // NOTE: when both PARENT and CHILD caps set, it means: the module can work // as parent but can host itself as child, but cannot work as child of other vo #define VO_MODULE_CAPS_CHILD 0x20000 // module requires X11 connection (as parameter in preinit()) #define VO_MODULE_CAPS_X11 0x40000 // module renders into a window // NOTE: if both X11 and WINDOW caps set: it requires an X11 window via control #define VO_MODULE_CAPS_WINDOW 0x80000 some example of flags: sdl,directx: WINDOW (it has self-managed window) mga,tdfx_vid,vidix: CHILD (can work as child) xover: PARENT+X11+WINDOW (can only work as parent, requires x11 and window) fbdev,vesa: PARENT+CHILD (can work as parent for overlays, or run alone) xv,gl: X11+WINDOW (requires X11 and window, but cannot work as parent) did i miss sth? maybe an VO_MODULE_CAPS_GUI for drivers available for GUI users? (so gui wouldn't list/allow mga, fbdev and other x11 unfriendly drivers) 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 Jul 13 01:23:04 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 13 Jul 2003 01:23:04 +0200 Subject: [MPlayer-G2-dev] pre34 & vf/vo resize problem Message-ID: <200307122323.h6CNN4cX002855@mail.mplayerhq.hu> Hi, pre34: - networking enabled again (STREAMING -> MPLAYER_NETWORK rename) although mms/mmst seems to be broken :( - initial subtitle support patch by Albeu - 'flags' field added to module_info_t - some compiler warnings fixed - (x11) event handling docimented in libvo2.txt in more detail - obsolete 'flags' removed from vo2's config() parameters - VO_MODULE_CAPS_* defined - some cleanup of x11_common.c, renamed to x11_helper.c and event.c and introducing yet another problem for discussion, mayeb you have better ideas than me: there are several vo drivers without scaling ability. (and there are some with limited scaling, left them for now). in g1 we included swscaler support in all of them to workaround this. of course it isn't acceptable in g2. i found 2 ways to solve: 1. simple, g1-like but cleaner method: include swscaler support into vf_vo2, the vf->vo wrapper. so if it receives scaling request, but vo is not capable of scaling, it will use swscaler instead of memcpy. advantages: easy to implement, less errors possible disadvantage: doesnt use filters, so even if there is scale in the filter path, it wont be used but yet another swscaler. (vf_scale right before vf_vo2 may be workarounded by ugly hacks) 2. complex but very interesting solution: add controls to filters changing size and/or aspect to convert between src/dst sizes (both direction). so when the user resizes the window to X*Y, this control would be launched from vd to get the resulting image sized to X*Y. Ok it isnt so simple to implement, imho you need at least 2 controls: one to calculate the d_width/d_height for first vf to get X*Y at the end of filter path, and one to setup scaling/resizing in filters. (maybe the second one can be (shoudl be?) replaced by config() re-call?) advantages: utilizes vfilters. allows not only scaling, but for example crop/expand and other resizing filters to be used to change window size. Can use scale before other filters, for example -vop expand=0:-100,scale will scale the iamge up when you resize the window, but always keep the constant 100 pixel height black band under the image for the subtitles. disadvantages: very complex, requires new/extra code in many vf_* any better idea? or ideas how to implement 2. ? (my control/config method is even too complex to describe here... i'm thinking on it for 2 days already, but always find new problems) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Sun Jul 13 12:52:40 2003 From: albeu at free.fr (Alban Bedel) Date: Sun, 13 Jul 2003 12:52:40 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem References: <200307122323.h6CNN4cX002855@mail.mplayerhq.hu> Message-ID: <20030713125240.3fb470e7.albeu@free.fr> Hi Arpi, on Sun, 13 Jul 2003 01:23:04 +0200 you wrote: > and introducing yet another problem for discussion, mayeb you have > better ideas than me: > > there are several vo drivers without scaling ability. > (and there are some with limited scaling, left them for now). > in g1 we included swscaler support in all of them to workaround this. > of course it isn't acceptable in g2. > i found 2 ways to solve: > 1. simple, g1-like but cleaner method: include swscaler support into > vf_vo2, the vf->vo wrapper. so if it receives scaling request, but > vo is not capable of scaling, it will use swscaler instead of memcpy. > advantages: easy to implement, less errors possible > disadvantage: doesnt use filters, so even if there is scale in the > filter path, it wont be used but yet another swscaler. > (vf_scale right before vf_vo2 may be workarounded by ugly hacks) > 2. complex but very interesting solution: > add controls to filters changing size and/or aspect to convert > between src/dst sizes (both direction). > so when the user resizes the window to X*Y, this control would be > launched from vd to get the resulting image sized to X*Y. > Ok it isnt so simple to implement, imho you need at least 2 controls: > one to calculate the d_width/d_height for first vf to get X*Y at the > end of filter path, and one to setup scaling/resizing in filters. > (maybe the second one can be (shoudl be?) replaced by config() > re-call?) advantages: utilizes vfilters. allows not only scaling, but > for example crop/expand and other resizing filters to be used to > change window size. Can use scale before other filters, for example > -vop expand=0:-100,scale will scale the iamge up when you resize the > window, but always keep the constant 100 pixel height black band > under the image for the subtitles. disadvantages: very complex, > requires new/extra code in many vf_* > > any better idea? > or ideas how to implement 2. ? > (my control/config method is even too complex to describe here... > i'm thinking on it for 2 days already, but always find new problems) I'm not sure if i understood everything, so feel free to try to explain more, that wolud be nice :) Imho the problem with 2. is that the control call go in the wrong direction. Shouldn't the call for resize be done on vf_vo2 and then have it (if needed) go back in the chain until it meet a filter capable of resizing ?? I know that it's not really possible atm to have some call to go up in the filter chain. But in such case it make a lot more sense i think. Allthought it's possible to have the control first pass the call down in the chain to see if another filter (wich is later in the chain) can do it. With such method it would also be possible for the user (via filter options) to set a filter as the "resizer" so the resize is not necessarily done by the last scale filter (or is done by expand, etc). However, i don't know if using config() to setup a new size is a so good idea regarding the vo's. For filters it's allright but for in the case of vo's, config() will often setup some buffer, etc. What about having a control to set new size, so vo like x11 can optimize the resize case a bit. But if the vo doesn't support the control then we fallback on config(). Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Sun Jul 13 16:26:49 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 13 Jul 2003 16:26:49 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem In-Reply-To: <20030713125240.3fb470e7.albeu@free.fr> Message-ID: <200307131426.h6DEQnvI013879@mail.mplayerhq.hu> Hi, > > there are several vo drivers without scaling ability. > > (and there are some with limited scaling, left them for now). > > in g1 we included swscaler support in all of them to workaround this. > > of course it isn't acceptable in g2. > > i found 2 ways to solve: > > 1. simple, g1-like but cleaner method: include swscaler support into > > vf_vo2, the vf->vo wrapper. so if it receives scaling request, but > > vo is not capable of scaling, it will use swscaler instead of memcpy. > > advantages: easy to implement, less errors possible > > disadvantage: doesnt use filters, so even if there is scale in the > > filter path, it wont be used but yet another swscaler. > > (vf_scale right before vf_vo2 may be workarounded by ugly hacks) > > 2. complex but very interesting solution: > > add controls to filters changing size and/or aspect to convert > > between src/dst sizes (both direction). > > so when the user resizes the window to X*Y, this control would be > > launched from vd to get the resulting image sized to X*Y. > > Ok it isnt so simple to implement, imho you need at least 2 controls: > > one to calculate the d_width/d_height for first vf to get X*Y at the > > end of filter path, and one to setup scaling/resizing in filters. > > (maybe the second one can be (shoudl be?) replaced by config() > > re-call?) advantages: utilizes vfilters. allows not only scaling, but > > for example crop/expand and other resizing filters to be used to > > change window size. Can use scale before other filters, for example > > -vop expand=0:-100,scale will scale the iamge up when you resize the > > window, but always keep the constant 100 pixel height black band > > under the image for the subtitles. disadvantages: very complex, > > requires new/extra code in many vf_* > > > > any better idea? > > or ideas how to implement 2. ? > > (my control/config method is even too complex to describe here... > > i'm thinking on it for 2 days already, but always find new problems) > I'm not sure if i understood everything, so feel free to try to explain > more, that wolud be nice :) > > Imho the problem with 2. is that the control call go in the wrong > direction. Shouldn't the call for resize be done on vf_vo2 and then have > it (if needed) go back in the chain until it meet a filter capable > of resizing ?? yes > I know that it's not really possible atm to have some call to go up > in the filter chain. But in such case it make a lot more sense i think. actually you can do it (tricky), and i meant the control above this way. control(int* p){ call_next_control(p) do something with p[] values } so you can start teh control from the top, it will call down to the bottom (vf_vo2) filter and then returns the values up to the caller through all teh filters so they can alter the values. > Allthought it's possible to have the control first pass the call down > in the chain to see if another filter (wich is later in the chain) can yes i mean the same > do it. With such method it would also be possible for the user (via > filter options) to set a filter as the "resizer" so the resize is > not necessarily done by the last scale filter (or is done by expand, etc). yes, i also planned such resize/noresize flags for such filters for example, filter 'expand' by default would do automatic resizing, but if you give it relative sizes (like expand=-1:-100) it disables resizing by default andlet other filters to do it. normally the last filter capable to resize (including vo via vf_vo2) would do it. the question is how to do the actual impelmentation. you have the wanted dwidth/dheight at the vo (so the resized window's new width/height) and you have to send a (or 2) control through teh filter layer to get them reconfigured for this new desitination size. i'm interested in sample/pshedo code, my ideas are overcomplicated :( > However, i don't know if using config() to setup a new size is a so good > idea regarding the vo's. For filters it's allright but for in the case > of vo's, config() will often setup some buffer, etc. but when you only have to config() when the vo isnt capable of resizing, and then it really have to resize (reallocate) the buffers so its' o kto call it, imho. although vo drivers should support multiple config() calls, and do optimizations based on changed parameters. > What about having a control to set new size, so vo like x11 can optimize > the resize case a bit. But if the vo doesn't support the control then we > fallback on config(). i wonder what can you optimize in vo_x11, at least in vo2 when teh only thing that config() does is allocating buffer. (actually even buffer allocation can be moved out of config to get_buffer) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Sun Jul 13 18:00:24 2003 From: albeu at free.fr (Alban Bedel) Date: Sun, 13 Jul 2003 18:00:24 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem References: <20030713125240.3fb470e7.albeu@free.fr> <200307131426.h6DEQnvI013879@mail.mplayerhq.hu> Message-ID: <20030713180024.5cca34dc.albeu@free.fr> Hi Arpi, on Sun, 13 Jul 2003 16:26:49 +0200 you wrote: > Hi, > > > > there are several vo drivers without scaling ability. > > > (and there are some with limited scaling, left them for now). > > > in g1 we included swscaler support in all of them to workaround > > > this. of course it isn't acceptable in g2. > > > i found 2 ways to solve: > > > 1. simple, g1-like but cleaner method: include swscaler support into > > > vf_vo2, the vf->vo wrapper. so if it receives scaling request, > > > but vo is not capable of scaling, it will use swscaler instead of > > > memcpy. advantages: easy to implement, less errors possible > > > disadvantage: doesnt use filters, so even if there is scale in > > > the > > > filter path, it wont be used but yet another swscaler. > > > (vf_scale right before vf_vo2 may be workarounded by ugly > > > hacks) > > > 2. complex but very interesting solution: > > > add controls to filters changing size and/or aspect to convert > > > between src/dst sizes (both direction). > > > so when the user resizes the window to X*Y, this control would be > > > launched from vd to get the resulting image sized to X*Y. > > > Ok it isnt so simple to implement, imho you need at least 2 > > > controls: one to calculate the d_width/d_height for first vf to > > > get X*Y at the end of filter path, and one to setup > > > scaling/resizing in filters.(maybe the second one can be (shoudl > > > be?) replaced by config() re-call?) advantages: utilizes > > > vfilters. allows not only scaling, but for example crop/expand > > > and other resizing filters to be used to change window size. Can > > > use scale before other filters, for example-vop > > > expand=0:-100,scale will scale the iamge up when you resize the > > > window, but always keep the constant 100 pixel height black band > > > under the image for the subtitles. disadvantages: very complex, > > > requires new/extra code in many vf_* > > > > > > any better idea? > > > or ideas how to implement 2. ? > > > (my control/config method is even too complex to describe here... > > > i'm thinking on it for 2 days already, but always find new problems) > > I'm not sure if i understood everything, so feel free to try to > > explain more, that wolud be nice :) > > > > Imho the problem with 2. is that the control call go in the wrong > > direction. Shouldn't the call for resize be done on vf_vo2 and then > > have it (if needed) go back in the chain until it meet a filter > > capable of resizing ?? > > yes > > > I know that it's not really possible atm to have some call to go up > > in the filter chain. But in such case it make a lot more sense i > > think. > > actually you can do it (tricky), and i meant the control above this way. > > control(int* p){ > call_next_control(p) > do something with p[] values > } > > so you can start teh control from the top, it will call down to the > bottom(vf_vo2) filter and then returns the values up to the caller > through all teh filters so they can alter the values. > > > Allthought it's possible to have the control first pass the call down > > in the chain to see if another filter (wich is later in the chain) can > > yes i mean the same > > > do it. With such method it would also be possible for the user (via > > filter options) to set a filter as the "resizer" so the resize is > > not necessarily done by the last scale filter (or is done by expand, > > etc). > > yes, i also planned such resize/noresize flags for such filters > for example, filter 'expand' by default would do automatic resizing, > but if you give it relative sizes (like expand=-1:-100) it disables > resizing by default andlet other filters to do it. > normally the last filter capable to resize (including vo via vf_vo2) > would do it. That would be really nice. > the question is how to do the actual impelmentation. > you have the wanted dwidth/dheight at the vo (so the resized window's > new width/height) and you have to send a (or 2) control through teh > filter layer to get them reconfigured for this new desitination size. > i'm interested in sample/pshedo code, my ideas are overcomplicated :( It is complex but we'll make it !!! Basiclly afaiu it should work like this : - The app get a resize event from the vo (optional) - The app call vf_resize(..., d_width,d_height) - vf_resize check that the chain is really capable of resize - Call the resize control on the first filter. - The control call reach a resize capable filter (let say scale). - The filter pass the control to the next filter to see if some other filter can do it. - The filter setup itself to now output in d_width x d_height size. - Call config(....,d_width,d_height,d_width,d_height,..) on the next filter to setup the following filters with the new size. Ok it's too simple ;) So i probably overlooked a lot of stuff considering that you said you were thinking on that for 2 days. > > However, i don't know if using config() to setup a new size is a so > > good idea regarding the vo's. For filters it's allright but for in the > > case of vo's, config() will often setup some buffer, etc. > > but when you only have to config() when the vo isnt capable of resizing, > and then it really have to resize (reallocate) the buffers so its' o kto > call it, imho. although vo drivers should support multiple config() > calls, and do optimizations based on changed parameters. That's my point. This multiple config call is alredy not so easy to implement. So if you have also to take in account that sometimes this call is used only for resize then it's even worse. I speak from my g1 experience, so this may be somewhat different in g2. Anyway this kind of issues is unimportant atm. > > What about having a control to set new size, so vo like x11 can > > optimize the resize case a bit. But if the vo doesn't support the > > control then we fallback on config(). > > i wonder what can you optimize in vo_x11, at least in vo2 when teh only > thing that config() does is allocating buffer. > (actually even buffer allocation can be moved out of config to > get_buffer) I just took x11 bcs it can't scale. I really have to look at libvo2 it sound so nice :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Sun Jul 13 19:17:06 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 13 Jul 2003 19:17:06 +0200 Subject: [MPlayer-G2-dev] vo_x11 vs. shm Message-ID: <200307131717.h6DHH6TQ016124@mail.mplayerhq.hu> Hi, I've tried to port vo_x11 from g1 (actually rewrite) t obe able to test our ideas of automatic scaling/resizing. It works wihtout shm, but when i enable shm it fails when d_height != height. It would be great if someone with more X11 knowledge tham me could check/fix the code: mphq/~arpi/g2/vo_x11.c (copy to libvo2 dir and add to the video_out_drivers[] list in video_out.c) 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 Jul 13 21:01:59 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 13 Jul 2003 21:01:59 +0200 Subject: [MPlayer-G2-dev] vo_x11 vs. shm In-Reply-To: <200307131717.h6DHH6TQ016124@mail.mplayerhq.hu> Message-ID: <200307131901.h6DJ1xNn006175@mail.mplayerhq.hu> Hi, > I've tried to port vo_x11 from g1 (actually rewrite) t obe able to test > our ideas of automatic scaling/resizing. It works wihtout shm, but > when i enable shm it fails when d_height != height. > > It would be great if someone with more X11 knowledge tham me could > check/fix the code: mphq/~arpi/g2/vo_x11.c > (copy to libvo2 dir and add to the video_out_drivers[] list in video_out.c) fixed, it was 100l... (using vo->h instead of vo->buffer_h in show_frame()) 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 Jul 13 21:56:28 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 13 Jul 2003 21:56:28 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem In-Reply-To: <20030713180024.5cca34dc.albeu@free.fr> Message-ID: <200307131956.h6DJuS2N016865@mail.mplayerhq.hu> Hi, > > the question is how to do the actual impelmentation. > > you have the wanted dwidth/dheight at the vo (so the resized window's > > new width/height) and you have to send a (or 2) control through teh > > filter layer to get them reconfigured for this new desitination size. > > i'm interested in sample/pshedo code, my ideas are overcomplicated :( > It is complex but we'll make it !!! :) > Basiclly afaiu it should work like this : > > - The app get a resize event from the vo (optional) > - The app call vf_resize(..., d_width,d_height) > - vf_resize check that the chain is really capable of resize > - Call the resize control on the first filter. > - The control call reach a resize capable filter (let say scale). > - The filter pass the control to the next filter to see if some > other filter can do it. > - The filter setup itself to now output in d_width x d_height size. > - Call config(....,d_width,d_height,d_width,d_height,..) on > the next filter to setup the following filters with the new size. > > Ok it's too simple ;) So i probably overlooked a lot of stuff Yes, i would say that you missed the step of d_width/d_height altering filters, like rotate, relative expand, frame<->field converters etc. But maybe you're right, I was on wrong step, it all can be done in oen step maybe, some psuecode: // expand=-1:-100 resize(vf,int* p){ if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; if(we_do_resize){ vf->priv->exp_w=p[0]; vf->priv->exp_h=p[1]; vf->config(vf,vf->priv->w,vf->priv->h,vf->priv->exp_w,vf->priv->exp_h); return VF_TRUE; // we do resizing } else { // tell the upper filters to resize to d_width x d_height-100 // so we can provide d_width x d_height-100+100 images p[1]-=100; return VF_FALSE; } } // rotate: resize(vf,int* p){ if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; swap(p[0],p[1]); return VF_FALSE; } (of course there will be no new vf->resize() but a control for this) > considering that you said you were thinking on that for 2 days. it does mean nothing, it seems :) > > > However, i don't know if using config() to setup a new size is a so > > > good idea regarding the vo's. For filters it's allright but for in the > > > case of vo's, config() will often setup some buffer, etc. > > > > but when you only have to config() when the vo isnt capable of resizing, > > and then it really have to resize (reallocate) the buffers so its' o kto > > call it, imho. although vo drivers should support multiple config() > > calls, and do optimizations based on changed parameters. > That's my point. This multiple config call is alredy not so easy to > implement. So if you have also to take in account that sometimes > this call is used only for resize then it's even worse. I'll release pre35 today, pelase check vo_xv and vo_x11, the config() is less than 5 lines of code... actually it does near nothing, just creates GC for the window if not yet done and saves the new w/h to the vo struct. (buffer creation/releasing is done in get/release_buffer(), X11 init in preinit()) > I speak from my g1 experience, so this may be somewhat different in g2. there is really BIG difference between g1's libvo and g2's libvo2 (but it also means that porting g1 vo drivers to g2 is a lots of work and actually means rewrite from scratch) > Anyway this kind of issues is unimportant atm. agree A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Sun Jul 13 23:49:23 2003 From: albeu at free.fr (Alban Bedel) Date: Sun, 13 Jul 2003 23:49:23 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem References: <20030713180024.5cca34dc.albeu@free.fr> <200307131956.h6DJuS2N016865@mail.mplayerhq.hu> Message-ID: <20030713234923.59885429.albeu@free.fr> Hi Arpi, on Sun, 13 Jul 2003 21:56:28 +0200 you wrote: > But maybe you're right, I was on wrong step, it all can be done in oen > step maybe, some psuecode: > > // expand=-1:-100 > resize(vf,int* p){ > if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; > if(we_do_resize){ > vf->priv->exp_w=p[0]; > vf->priv->exp_h=p[1]; > vf->config(vf,vf->priv->w,vf->priv->h,vf->priv->exp_w,vf->priv- > >exp_h); > return VF_TRUE; // we do resizing > } else { > // tell the upper filters to resize to d_width x d_height-100 > // so we can provide d_width x d_height-100+100 images > p[1]-=100; > return VF_FALSE; > } > } > > // rotate: > resize(vf,int* p){ > if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; > swap(p[0],p[1]); > return VF_FALSE; > } > > (of course there will be no new vf->resize() but a control for this) Look both easy to implement and powerfull :) > > considering that you said you were thinking on that for 2 days. > > it does mean nothing, it seems :) Sometimes ... but it won't make me doubt of your (incredible) programming abilities ;) > I'll release pre35 today, pelase check vo_xv and vo_x11, the config() > is less than 5 lines of code... > actually it does near nothing, just creates GC for the window if not yet > done and saves the new w/h to the vo struct. > (buffer creation/releasing is done in get/release_buffer(), X11 init in > preinit()) I'll check that, i plan to port tdfx_vid (someday in the futur). > > I speak from my g1 experience, so this may be somewhat different in > > g2. > > there is really BIG difference between g1's libvo and g2's libvo2 > (but it also means that porting g1 vo drivers to g2 is a lots of work > and actually means rewrite from scratch) It's probably not that bad that vo have to them rewrote from scratch. g1 vo (especially the x11 ones) became so ugly :(( Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Mon Jul 14 00:13:54 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 14 Jul 2003 00:13:54 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem In-Reply-To: <20030713234923.59885429.albeu@free.fr> Message-ID: <200307132213.h6DMDs2I013358@mail.mplayerhq.hu> Hi, > > // rotate: > > resize(vf,int* p){ > > if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; > > swap(p[0],p[1]); > > return VF_FALSE; > > } > > > > (of course there will be no new vf->resize() but a control for this) > Look both easy to implement and powerfull :) > > I'll release pre35 today, pelase check vo_xv and vo_x11, the config() done, pre35 released 0.3 minutes ago :) it has vo_x11 and resize control to handle resizes automagically :) > > is less than 5 lines of code... > > actually it does near nothing, just creates GC for the window if not yet > > done and saves the new w/h to the vo struct. > > (buffer creation/releasing is done in get/release_buffer(), X11 init in > > preinit()) > I'll check that, i plan to port tdfx_vid (someday in the futur). you should do it ASAP, i'm going to buty my new 21/24" monitor tomorrow for movies/tv, and it will be connected to the voodoo3 :) > > > I speak from my g1 experience, so this may be somewhat different in > > > g2. > > > > there is really BIG difference between g1's libvo and g2's libvo2 > > (but it also means that porting g1 vo drivers to g2 is a lots of work > > and actually means rewrite from scratch) > It's probably not that bad that vo have to them rewrote from scratch. not g2's vo2 is bad, but g1's vo1 is. vo2 is clean modular design, preinit, config, buffer allocation, buffer release, buffer/frame display, etc all separated. also the whole x11 window management (including messing with visuals, vidmode change, xinerama, creating window, fullscreen sw. etc) are moved out of vo drivers. > g1 vo (especially the x11 ones) became so ugly :(( not only x11 ones A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Mon Jul 14 00:57:26 2003 From: albeu at free.fr (Alban Bedel) Date: Mon, 14 Jul 2003 00:57:26 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem References: <20030713234923.59885429.albeu@free.fr> <200307132213.h6DMDs2I013358@mail.mplayerhq.hu> Message-ID: <20030714005726.1088d519.albeu@free.fr> Hi Arpi, on Mon, 14 Jul 2003 00:13:54 +0200 you wrote: > Hi, > > > > // rotate: > > > resize(vf,int* p){ > > > if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE; > > > swap(p[0],p[1]); > > > return VF_FALSE; > > > } > > > > > > (of course there will be no new vf->resize() but a control for this) > > Look both easy to implement and powerfull :) > > > > I'll release pre35 today, pelase check vo_xv and vo_x11, the > > > config() > > done, pre35 released 0.3 minutes ago :) > it has vo_x11 and resize control to handle resizes automagically :) Cool :))) > > > is less than 5 lines of code... > > > actually it does near nothing, just creates GC for the window if not > > > yet done and saves the new w/h to the vo struct. > > > (buffer creation/releasing is done in get/release_buffer(), X11 init > > > in preinit()) > > I'll check that, i plan to port tdfx_vid (someday in the futur). > > you should do it ASAP, i'm going to buty my new 21/24" monitor tomorrow > for movies/tv, and it will be connected to the voodoo3 :) :)) How big is that in metric unit ? Now when some1 as need for it, it give some motivation. I'll try to do that before my holidays in france. > > > > I speak from my g1 experience, so this may be somewhat different > > > > in g2. > > > > > > there is really BIG difference between g1's libvo and g2's libvo2 > > > (but it also means that porting g1 vo drivers to g2 is a lots of > > > work and actually means rewrite from scratch) > > It's probably not that bad that vo have to them rewrote from scratch. > > not g2's vo2 is bad, but g1's vo1 is. I never meant that vo2 is bad :) Just my wording wich is gone crazy. I meant that it's a good thing that g1 vo can't be used "as is" as most of them are now more a montain of hack than anything else. > vo2 is clean modular design, preinit, config, buffer allocation, buffer > release, buffer/frame display, etc all separated. > > also the whole x11 window management (including messing with visuals, > vidmode change, xinerama, creating window, fullscreen sw. etc) are > moved out of vo drivers. That's great. X11 was always somewhat of a pain in g1. > > g1 vo (especially the x11 ones) became so ugly :(( > > not only x11 ones Sadly. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Mon Jul 14 01:14:16 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 14 Jul 2003 01:14:16 +0200 Subject: [MPlayer-G2-dev] Re: pre34 & vf/vo resize problem In-Reply-To: <20030714005726.1088d519.albeu@free.fr> Message-ID: <200307132314.h6DNEGC9025867@mail.mplayerhq.hu> Hi, > > > > actually it does near nothing, just creates GC for the window if not > > > > yet done and saves the new w/h to the vo struct. > > > > (buffer creation/releasing is done in get/release_buffer(), X11 init > > > > in preinit()) > > > I'll check that, i plan to port tdfx_vid (someday in the futur). > > > > you should do it ASAP, i'm going to buty my new 21/24" monitor tomorrow > > for movies/tv, and it will be connected to the voodoo3 :) > :)) How big is that in metric unit ? around 50-55cm (i didn't decide yet between sony g520, eizo, viewsonic and dell 21-24" models) not so big but my current TV is 55cm too so no (big) difference > Now when some1 as need for it, it give some motivation. I'll try to do > that before my holidays in france. thanx :) > > > > > I speak from my g1 experience, so this may be somewhat different > > > > > in g2. > > > > > > > > there is really BIG difference between g1's libvo and g2's libvo2 > > > > (but it also means that porting g1 vo drivers to g2 is a lots of > > > > work and actually means rewrite from scratch) > > > It's probably not that bad that vo have to them rewrote from scratch. > > > > not g2's vo2 is bad, but g1's vo1 is. > I never meant that vo2 is bad :) Just my wording wich is gone crazy. > I meant that it's a good thing that g1 vo can't be used "as is" as > most of them are now more a montain of hack than anything else. :)) > > also the whole x11 window management (including messing with visuals, > > vidmode change, xinerama, creating window, fullscreen sw. etc) are > > moved out of vo drivers. > That's great. X11 was always somewhat of a pain in g1. the main goals with vo2 were that move out non-driver/device-specific code out of the vo drivers, so we can work/fix/tets generic code wiht any vo driver, and the vo drivers are simpler (less bugs possible). i also moved out all x11 window management code, so guis can use their own, and there is common x11 code for all x11 vo drivers. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon Jul 14 05:47:05 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 13 Jul 2003 23:47:05 -0400 Subject: [MPlayer-G2-dev] Re: libvo2 api/design problem In-Reply-To: <200307121716.h6CHGUxl017540@mail.mplayerhq.hu> References: <20030708112049.618736ff.albeu@free.fr> <200307121716.h6CHGUxl017540@mail.mplayerhq.hu> Message-ID: <20030714034705.GB227@brightrain.aerifal.cx> On Sat, Jul 12, 2003 at 07:16:30PM +0200, Arpi wrote: > Hi, > > > > > I'd prefere #1, but would extend the vo_info_t structure by > > > > a special requirements field and put there a VO_NEED_X11 or something > > > > like that. > > > > > > Me too. > > Ok i've extended the module_info_t wtsurtc with a flags field, low 16 > bit is generic, upper 16 bits are module type dependant. > > > I'd like to see smthg like VO_X11_CAPS wich mean that the vo can > > optionaly use a provided window (like tdfx_vid, mga?, etc). > > These won't fail if a window isn't avaible. > > Are there any vo driver which may work with and without X11 ? > (assuming we're implementing parent-child system for overlays like > mga or tdfx_vid to work with x11, fbdev, vesa etc) > > I guess no, so i left ot out for now. > My idea for the vo2 module capabilities flags: > > //****** vo2 specific module_info_t flags: ******** > // module can work as parent for other sub-vo module (xover, vesa, fbdev...) > #define VO_MODULE_CAPS_PARENT 0x10000 > // module can work as child or other parent module > // NOTE: when both PARENT and CHILD caps set, it means: the module can work > // as parent but can host itself as child, but cannot work as child of other vo > #define VO_MODULE_CAPS_CHILD 0x20000 > // module requires X11 connection (as parameter in preinit()) > #define VO_MODULE_CAPS_X11 0x40000 > // module renders into a window > // NOTE: if both X11 and WINDOW caps set: it requires an X11 window via control > #define VO_MODULE_CAPS_WINDOW 0x80000 > > some example of flags: > > sdl,directx: WINDOW (it has self-managed window) > mga,tdfx_vid,vidix: CHILD (can work as child) > xover: PARENT+X11+WINDOW (can only work as parent, requires x11 and window) > fbdev,vesa: PARENT+CHILD (can work as parent for overlays, or run alone) > xv,gl: X11+WINDOW (requires X11 and window, but cannot work as parent) > > did i miss sth? Yes, mga does not need a parent... This is especially an issue if the fbdev parent does something idiotic like clearing the background, changing video mode, capturing tty and switching it to 'graphics mode' if it's a vc, etc... Rich From dalias at aerifal.cx Mon Jul 14 05:52:32 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 13 Jul 2003 23:52:32 -0400 Subject: [MPlayer-G2-dev] pre34 & vf/vo resize problem In-Reply-To: <200307122323.h6CNN4cX002855@mail.mplayerhq.hu> References: <200307122323.h6CNN4cX002855@mail.mplayerhq.hu> Message-ID: <20030714035232.GC227@brightrain.aerifal.cx> On Sun, Jul 13, 2003 at 01:23:04AM +0200, Arpi wrote: > Hi, > > pre34: > - networking enabled again (STREAMING -> MPLAYER_NETWORK rename) > although mms/mmst seems to be broken :( > - initial subtitle support patch by Albeu > - 'flags' field added to module_info_t > - some compiler warnings fixed > - (x11) event handling docimented in libvo2.txt in more detail > - obsolete 'flags' removed from vo2's config() parameters > - VO_MODULE_CAPS_* defined > - some cleanup of x11_common.c, renamed to x11_helper.c and event.c > > and introducing yet another problem for discussion, mayeb you have > better ideas than me: > > there are several vo drivers without scaling ability. > (and there are some with limited scaling, left them for now). > in g1 we included swscaler support in all of them to workaround this. > of course it isn't acceptable in g2. While we're talking about scaling/displaysize, there's an issue I ran into that I think we should address. Certain filters (scale, crop, etc.) adjust d_width and d_height to preserve aspect. However, these values are stored as integers, so they become victims of rather bad rounding. This often causes the overlay not to quite fill the screen in fullscreen mode, leaving a few pixels of console behind... Also it's really bad for the "autoaspect" option I added to ve_lavc... Is there maybe some better way we could handle the whole issue (keeping floats or ratios?) so that rounding doesn't become such a problem? Rich From ajh at watri.org.au Wed Jul 16 13:18:48 2003 From: ajh at watri.org.au (Anders Johansson) Date: Wed, 16 Jul 2003 19:18:48 +0800 Subject: [MPlayer-G2-dev] New libao2 Message-ID: <20030716111848.GG32263@watri.org.au> Hi, I've been working on the new audio I/O library a bit. Can't get the sync to work, but I will continue to work on it. I will also implement the new config system (not done yet). Anyway just wanted to show what I have done to see what you think of it. The source I have been working on is from version 33 (I think). down load it from: www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz Cheers, //Anders From arpi at thot.banki.hu Wed Jul 16 13:56:19 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 16 Jul 2003 13:56:19 +0200 Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <20030716111848.GG32263@watri.org.au> Message-ID: <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> Hi, > I've been working on the new audio I/O library a bit. Can't get the > sync to work, but I will continue to work on it. I will also implement > the new config system (not done yet). Anyway just wanted to show what > I have done to see what you think of it. > > The source I have been working on is from version 33 (I think). > > down load it from: > www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz Hmmm, interesting. Few comments: int (*get_delay)(struct aio_instance_s* aio); it should return float, 1sec accuracy is far not enough for a-v sync you can easily replace aio_conf_t by module_info_t, which have the same fields (actually a few more) and is required/recommended for new config system. we should define the metrics of in/out parameters, ie. byte vs. sample, and that stereo sample-pair does count one or two samples. and that bps is bits-per-second, bits-per-sample, bytes-per-second or what. it made the most confusion around mplayer-g1 audio layer causing various bugs. /* Audio data chunk */ typedef struct aio_data_s { void* audio; // data buffer int size; // size of bffer int len; // bytes in buffer }aio_data_t; Do you have plans to replace libaf, or it's "good as-is" ? For audio in/out it's ok to use packets, but i like fifo-type buffers better for filters (esp. that you cannot give exact in/out rate for some filters, see buffer size over/underflow problems in libaf when using resample). (i don't like its "packetized buffer" design but i have no time in the near future to implement my idea) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From ivan at cacad.com Wed Jul 16 14:31:30 2003 From: ivan at cacad.com (Ivan Kalvachev) Date: Wed, 16 Jul 2003 15:31:30 +0300 (EEST) Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> References: <20030716111848.GG32263@watri.org.au> <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> Message-ID: <1092.194.12.248.137.1058358690.squirrel@mail.cacad.com> Arpi said: > > we should define the metrics of in/out parameters, ie. byte vs. sample, > and that stereo sample-pair does count one or two samples. > and that bps is bits-per-second, bits-per-sample, bytes-per-second or > what. it made the most confusion around mplayer-g1 audio layer causing > various bugs. > Agree:)) Without seeing the actual code. > /* Audio data chunk */ > typedef struct aio_data_s > { > void* audio; // data buffer > int size; // size of bffer > int len; // bytes in buffer > }aio_data_t; hmm size is the size in samples? I have though that if could be good to have something like .... void * audio; int number_of_samples; //(44100 for one second) int size_of_sample; //( 4 bytes for 16bit stereo) int chanels; //(2 for stereo) .... //? mabe format here too? this way an compressed data could be hanled the same way as non compressed with only limitation that if the compressed data is variable size then it it could be only one sample (number_of_samples=1) This structure also makes it easier to add samples to the current buffer and/or to extract them. > > Do you have plans to replace libaf, or it's "good as-is" ? > For audio in/out it's ok to use packets, but i like fifo-type buffers > better for filters (esp. that you cannot give exact in/out rate for some > filters, see buffer size over/underflow problems in libaf when using > resample). (i don't like its "packetized buffer" design but i have no > time in the near future to implement my idea) > > > A'rpi / Astral & ESP-team > > -- Best Regards Ivan Kalvachev iive From ajh at watri.org.au Thu Jul 17 02:13:44 2003 From: ajh at watri.org.au (Anders Johansson) Date: Thu, 17 Jul 2003 08:13:44 +0800 Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> References: <20030716111848.GG32263@watri.org.au> <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> Message-ID: <20030717001344.GH32263@watri.org.au> > Hi, > > > I've been working on the new audio I/O library a bit. Can't get the > > sync to work, but I will continue to work on it. I will also implement > > the new config system (not done yet). Anyway just wanted to show what > > I have done to see what you think of it. > > > > The source I have been working on is from version 33 (I think). > > > > down load it from: > > www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz > > Hmmm, interesting. > > Few comments: > > int (*get_delay)(struct aio_instance_s* aio); The return value is not the dealy it is AIO_OK or AIO_ERROR depending on if get_delay was sucesfull in getting the delay. The actual delay values is found in aio_driver->out->delay and aio_driver->in->delay. > it should return float, 1sec accuracy is far not enough for a-v sync > > you can easily replace aio_conf_t by module_info_t, which have the same > fields (actually a few more) and is required/recommended for new config system. Actually it is aio_info_t, but yes I will, both for aio and af. > we should define the metrics of in/out parameters, ie. byte vs. sample, and > that stereo sample-pair does count one or two samples. > and that bps is bits-per-second, bits-per-sample, bytes-per-second or what. > it made the most confusion around mplayer-g1 audio layer causing various bugs. Below struct is not used. It was from a prevous attempt. > /* Audio data chunk */ > typedef struct aio_data_s > { > void* audio; // data buffer > int size; // size of bffer > int len; // bytes in buffer > }aio_data_t; > Do you have plans to replace libaf, or it's "good as-is" ? I think it is good as is. > For audio in/out it's ok to use packets, but i like fifo-type buffers better > for filters I am not sure what you mean by fifo - type? > (esp. that you cannot give exact in/out rate for some filters, > see buffer size over/underflow problems in libaf when using resample). > (i don't like its "packetized buffer" design but i have no time in the near > future to implement my idea) > > A'rpi / Astral & ESP-team //Anders From ajh at watri.org.au Thu Jul 17 02:24:16 2003 From: ajh at watri.org.au (Anders Johansson) Date: Thu, 17 Jul 2003 08:24:16 +0800 Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <1092.194.12.248.137.1058358690.squirrel@mail.cacad.com> References: <20030716111848.GG32263@watri.org.au> <200307161156.h6GBuJYm025816@mail.mplayerhq.hu> <1092.194.12.248.137.1058358690.squirrel@mail.cacad.com> Message-ID: <20030717002416.GI32263@watri.org.au> Hi, > Arpi said: > > > > we should define the metrics of in/out parameters, ie. byte vs. sample, > > and that stereo sample-pair does count one or two samples. > > and that bps is bits-per-second, bits-per-sample, bytes-per-second or > > what. it made the most confusion around mplayer-g1 audio layer causing > > various bugs. > > > Agree:)) I have tried to be consistent: rate is sampe rate. nch is number of channels. format is a bitfield describing the sample format. bps is the number of bytes per sample. len is the current number of bytes in the buffer. audio contains the current audio data. Looking back len could have been set as number of samples in buffer, or number of samples per channel. I can still make that change if it is desirable. Below definition is not used. > Without seeing the actual code. > > /* Audio data chunk */ > > typedef struct aio_data_s > > { > > void* audio; // data buffer > > int size; // size of bffer > > int len; // bytes in buffer > > }aio_data_t; > hmm > size is the size in samples? > I have though that if could be good to have something like > .... > void * audio; > int number_of_samples; //(44100 for one second) > int size_of_sample; //( 4 bytes for 16bit stereo) > int chanels; //(2 for stereo) > .... //? mabe format here too? > > this way an compressed data could be hanled the same way as non compressed > with only limitation that if the compressed data is variable size then it > it could be only one sample (number_of_samples=1) Just extend the format bitfield with some new types and we have what you want. > This structure also makes it easier to add samples to the current buffer > and/or to extract them. Agree. > > > > Do you have plans to replace libaf, or it's "good as-is" ? > > For audio in/out it's ok to use packets, but i like fifo-type buffers > > better for filters (esp. that you cannot give exact in/out rate for some > > filters, see buffer size over/underflow problems in libaf when using > > resample). (i don't like its "packetized buffer" design but i have no > > time in the near future to implement my idea) > > > > > > A'rpi / Astral & ESP-team > > > > Best Regards > Ivan Kalvachev > iive //Anders From albeu at free.fr Thu Jul 17 16:20:50 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 17 Jul 2003 16:20:50 +0200 Subject: [MPlayer-G2-dev] [PATCH] vo_tdfx_vid.c and vo_xover.c Message-ID: <20030717162050.2f61fd30.albeu@free.fr> Hi all, i implemented $SUBJ. A few comments : tdfx_vid I included my current tdfx_vid driver because i used some stuff wich are not yet commited to the main cvs driver. I tried a new "sleep" method. I discussed it a bit yesterday with Arpi on IRC. The idea is to suppress the sleep before show_frame and give show frame the delay needed before the frame must be displayed (in other words the time that would have been spent sleeping). Then in show_frame the banshee is setup to do the flip at the right time (in fact after a given number of V-Sync). So instead of sleeping the player can contiue. In my test i get a good cut down on CPU by using this. A 640x272 clip uselly need ~80% of the CPU, need only ~55% with this method. This is according to top so it's not a so good measurment, but still. xover This is not completly ready. It mostly work (with tdfx_vid) but i must say i have been confused by VOCTRL_RESIZE_DEST. Quoting libvo2.txt : --- VOCTRL_RESIZE_DEST: Asks the driver to redefine (move/resize) the display area. The parameters passed in a int[4] array: x,y,w,h. -1 means unchanged. --- So i thought that this would be the position of the window/overlay on the screen. But then in x11_helper.c i found : --- case VO_EVENT_MOVE: mp_msg(MSGT_CPLAYER,MSGL_V,"vo-event: moved to %d x %d\n",x,y); // dont do that, we're moving the window, not the picture inside the window! // { int tmp[4]; // tmp[2]=tmp[3]=-1; tmp[0]=x; tmp[1]=y; // vo->control(vo,VOCTRL_RESIZE_DEST,tmp); // } --- So it then seemed that this control was intended for something else ? Anyway i uncommented this and used the control for overlay resize/move. If this control is really intended for another use, wich one should i use ? A new one ? Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: vo.g2.diff Type: application/octet-stream Size: 70554 bytes Desc: not available URL: From arpi at thot.banki.hu Thu Jul 17 17:28:58 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 17 Jul 2003 17:28:58 +0200 Subject: [MPlayer-G2-dev] [PATCH] vo_tdfx_vid.c and vo_xover.c In-Reply-To: <20030717162050.2f61fd30.albeu@free.fr> Message-ID: <200307171528.h6HFSw8t028559@mail.mplayerhq.hu> Hi, > In my test i get a good cut down on CPU by using this. A 640x272 clip > uselly need ~80% of the CPU, need only ~55% with this method. > This is according to top so it's not a so good measurment, but still. hmm. > xover > This is not completly ready. It mostly work (with tdfx_vid) but i must say > i have been confused by VOCTRL_RESIZE_DEST. Quoting libvo2.txt : > --- > VOCTRL_RESIZE_DEST: > Asks the driver to redefine (move/resize) the display area. > The parameters passed in a int[4] array: x,y,w,h. -1 means unchanged. > --- > So i thought that this would be the position of the window/overlay on yes it is. but x,y means the position of overlay relative to the window corner, not to the screen, so unless you add black bars or do things like panscan or zoom, it should be 0,0 > the screen. But then in x11_helper.c i found : > --- > case VO_EVENT_MOVE: > mp_msg(MSGT_CPLAYER,MSGL_V,"vo-event: moved to %d x %d\n",x,y); > // dont do that, we're moving the window, not the picture inside the window! > // { int tmp[4]; > // tmp[2]=tmp[3]=-1; tmp[0]=x; tmp[1]=y; > // vo->control(vo,VOCTRL_RESIZE_DEST,tmp); > // } > --- > So it then seemed that this control was intended for something else ? > Anyway i uncommented this and used the control for overlay resize/move. it's wrong. hmm, maybe you're right, the lowlevel overlay drivers need the position relative to the screen corner instead of the window corner. so your xover should calculate the distance (actually window position) and adjust the x,y before passing to the lowlevel overlay driver (vo) (where x,y means relative to screen corner, as no windows at all) but that should be done by vo_xover, not x11_util! A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Thu Jul 17 17:51:05 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 17 Jul 2003 17:51:05 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c References: <20030717162050.2f61fd30.albeu@free.fr> <200307171528.h6HFSw8t028559@mail.mplayerhq.hu> Message-ID: <20030717175105.351d9ae7.albeu@free.fr> Hi Arpi, on Thu, 17 Jul 2003 17:28:58 +0200 you wrote: > Hi, > > > In my test i get a good cut down on CPU by using this. A 640x272 clip > > uselly need ~80% of the CPU, need only ~55% with this method. > > This is according to top so it's not a so good measurment, but still. > > hmm. Try it for yourself. A better benchmark method miss here :( Also in video-only mode the timing seems a bit better. This is very subjective but with soft-sleep it always seems to play a little bit faster than it should. > > xover > > This is not completly ready. It mostly work (with tdfx_vid) but i must > > say i have been confused by VOCTRL_RESIZE_DEST. Quoting libvo2.txt : > > --- > > VOCTRL_RESIZE_DEST: > > Asks the driver to redefine (move/resize) the display area. > > The parameters passed in a int[4] array: x,y,w,h. -1 means > > unchanged. > > --- > > So i thought that this would be the position of the window/overlay on > > yes it is. > but x,y means the position of overlay relative to the window corner, > not to the screen, so unless you add black bars or do things like > panscan or zoom, it should be 0,0 > > > the screen. But then in x11_helper.c i found : > > --- > > case VO_EVENT_MOVE: > > mp_msg(MSGT_CPLAYER,MSGL_V,"vo-event: moved to %d x > > %d\n",x,y); > > // dont do that, we're moving the window, not the picture inside the > > window!// { int tmp[4]; > > // tmp[2]=tmp[3]=-1; tmp[0]=x; tmp[1]=y; > > // vo->control(vo,VOCTRL_RESIZE_DEST,tmp); > > // } > > --- > > So it then seemed that this control was intended for something else ? > > Anyway i uncommented this and used the control for overlay > > resize/move. > > it's wrong. > hmm, maybe you're right, the lowlevel overlay drivers need the position > relative to the screen corner instead of the window corner. > so your xover should calculate the distance (actually window position) > and adjust the x,y before passing to the lowlevel overlay driver (vo) > (where x,y means relative to screen corner, as no windows at all) > > but that should be done by vo_xover, not x11_util! Ok, i'll do that. It make the implementation a bit more complex but that make sense. So if i undestood correctly VOCTRL_RESIZE_DEST define the position/size of the image in the parent window (wich stuff like xover translate in screen cords and VOCTRL_RESIZE_SRC the part of the buffer that should be displayed. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Thu Jul 17 20:27:14 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 17 Jul 2003 20:27:14 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c In-Reply-To: <20030717175105.351d9ae7.albeu@free.fr> Message-ID: <200307171827.h6HIREhj000655@mail.mplayerhq.hu> Hi, > > but that should be done by vo_xover, not x11_util! > Ok, i'll do that. It make the implementation a bit more complex but > that make sense. > > So if i undestood correctly VOCTRL_RESIZE_DEST define the > position/size of the image in the parent window (wich stuff like xover > translate in screen cords and > VOCTRL_RESIZE_SRC the part of the buffer that should be displayed. yes A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Fri Jul 18 22:38:54 2003 From: albeu at free.fr (Alban Bedel) Date: Fri, 18 Jul 2003 22:38:54 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c References: <20030717175105.351d9ae7.albeu@free.fr> <200307171827.h6HIREhj000655@mail.mplayerhq.hu> Message-ID: <20030718223854.77962b5c.albeu@free.fr> Hi Arpi, on Thu, 17 Jul 2003 20:27:14 +0200 you wrote: New version. Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: g2.diff Type: application/octet-stream Size: 75064 bytes Desc: not available URL: From arpi at thot.banki.hu Sat Jul 19 02:37:38 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 19 Jul 2003 02:37:38 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c In-Reply-To: <20030718223854.77962b5c.albeu@free.fr> Message-ID: <200307190037.h6J0bcsD026548@mail.mplayerhq.hu> Hi, > Hi Arpi, > > on Thu, 17 Jul 2003 20:27:14 +0200 you wrote: > > New version. > Albeu thx, mostly applied i've fixed it for mga too, but while doing it i found a design issue :(((( dont worry, not a big thing. currently we have VOCTRL_RESIZE_DEST, with int[4] params where -1 means unchanged. this is bad, as -1 may be valid! for example when the overlay window is dragged halfway outside of the screen (window have negative x position, and so the overlay have too). The original purpose of this control was to allow caller (UI) to do hw-accelerated pan&scan and zoom of image. Even in that case x,y may be <0 Probably (re-)adding VOCTRL_MOVE_DEST could solve the problem, but i wanna know if you see other posisble problems too. (originanly it was there, but then i find that passing x,y to RESIZE_DEST makes more sence. i was wrong...) if no objections or better ideas, i'll go for VOCTRL_MOVE_DEST (and VOCTRL_MOVE_SRC) 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 Jul 19 03:33:08 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 19 Jul 2003 03:33:08 +0200 Subject: [MPlayer-G2-dev] released: pre36 Message-ID: <200307190133.h6J1X8bW001766@mail.mplayerhq.hu> Hi, pre36: - new filter: vf_madei, a motion-adaptive deinterlacer - fastmemcpy.h/memcpy_pic() fixed for stride>width+16 - cvs up: libavcodec+vd_ffmpeg - ( ) escaping support into subconfig parser (patch by Albeu) - tdfx_vid + vo_tdfx ported (Albeu) - vo_xover (worx with tdfx_vid and mga_vid) (patch by Albeu) - VO_BUFFER_FLAG_SLEEP: usleep() done by the vo (patch by Albeu) - vo_mga: VOCTRL_RESIZE_DEST support A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Sat Jul 19 10:58:26 2003 From: albeu at free.fr (Alban Bedel) Date: Sat, 19 Jul 2003 10:58:26 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c References: <20030718223854.77962b5c.albeu@free.fr> <200307190037.h6J0bcsD026548@mail.mplayerhq.hu> Message-ID: <20030719105826.5bee2f1d.albeu@free.fr> Hi Arpi, on Sat, 19 Jul 2003 02:37:38 +0200 you wrote: > Hi, > > > Hi Arpi, > > > > on Thu, 17 Jul 2003 20:27:14 +0200 you wrote: > > > > New version. > > Albeu > > thx, mostly applied > > i've fixed it for mga too, but while doing it i found a design issue > :(((( dont worry, not a big thing. > currently we have VOCTRL_RESIZE_DEST, with int[4] params where -1 means > unchanged. this is bad, as -1 may be valid! > for example when the overlay window is dragged halfway outside of the > screen(window have negative x position, and so the overlay have too). > The original purpose of this control was to allow caller (UI) to do > hw-accelerated pan&scan and zoom of image. Even in that case x,y may be > <0 Strange that none thought to it before :) > Probably (re-)adding VOCTRL_MOVE_DEST could solve the problem, but i > wanna know if you see other posisble problems too. > (originanly it was there, but then i find that passing x,y to > RESIZE_DEST makes more sence. i was wrong...) It's ok, imho. > if no objections or better ideas, i'll go for VOCTRL_MOVE_DEST > (and VOCTRL_MOVE_SRC) But for SRC i don't think we'll really need another control, as negative x,y can be converted to w -= x, h -= y, x = 0, y = 0. But it won't harm, to have it :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Sat Jul 19 13:28:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 19 Jul 2003 13:28:43 +0200 Subject: [MPlayer-G2-dev] Re: [PATCH] vo_tdfx_vid.c and vo_xover.c In-Reply-To: <20030719105826.5bee2f1d.albeu@free.fr> Message-ID: <200307191128.h6JBSh5K029113@mail.mplayerhq.hu> Hi, > > if no objections or better ideas, i'll go for VOCTRL_MOVE_DEST > > (and VOCTRL_MOVE_SRC) > But for SRC i don't think we'll really need another control, as > negative x,y can be converted to w -= x, h -= y, x = 0, y = 0. > But it won't harm, to have it :) not really, unless you re-allocate the buffers or do crop in software. but hmm. negative x,y makes no sence for SRC, right. it would mean pixels outside of teh buffers, which is garbage... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Sat Jul 19 15:12:32 2003 From: albeu at free.fr (Alban Bedel) Date: Sat, 19 Jul 2003 15:12:32 +0200 Subject: [MPlayer-G2-dev] OSD Message-ID: <20030719151232.147d8a6c.albeu@free.fr> Hi, I worked a bit on OSD. Here is my current work. Comment are welcome :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: g2.osd.diff Type: application/octet-stream Size: 28090 bytes Desc: not available URL: From albeu at free.fr Sat Jul 19 15:16:54 2003 From: albeu at free.fr (Alban Bedel) Date: Sat, 19 Jul 2003 15:16:54 +0200 Subject: [MPlayer-G2-dev] Re: OSD References: <20030719151232.147d8a6c.albeu@free.fr> Message-ID: <20030719151654.35e6c07e.albeu@free.fr> Hi Alban Bedel, on Sat, 19 Jul 2003 15:12:32 +0200 you wrote: > > Hi, > > I worked a bit on OSD. Here is my current work. Comment are welcome :) Sorry for the chitty diff, i forgot to save the file after cleanup :( Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: g2.osd.diff Type: application/octet-stream Size: 25143 bytes Desc: not available URL: From arpi at thot.banki.hu Sun Jul 20 13:46:27 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 20 Jul 2003 13:46:27 +0200 Subject: [MPlayer-G2-dev] new idea for vo parent-child, xover etc. Message-ID: <200307201146.h6KBkRxx015961@mail.mplayerhq.hu> Hi, Albeu implemented vo_xover, nice. Although at least half of that code si generic and sould be duplicated to every parent-capable vo drivers. Not a big deal, easy to move out to separate file or vo core. But what about OSD? We should be able to do tricks, like render osd to the key color, without antialiasing but in hi-res it doesnt really matter, and still looks better than 320x200 antialieased subs upscaled (together with the video window) to 1024x768 for example. Also we could render antialiased subs bellow the image (when widescreen). Of course all this can be done with the xover approach, by adding new controls etc, but why to do that, if we can do it easier: Let's allow vf_vo2 to control 2 vo in a special way, ie. parent and chield. It could open vo_x11 to draw a window with colorkey, osd etc, and open vo_mga to display overlay to translated coords retrieved from vo_x11 (unfortunatelly we need a special control to get absolute window position... or put that info to the vo struct, like win_x, win_y) So, actually vo_x11 doesn't even know about vo_mga, and vice versa. It allows us to do mroe vo combinations without extra support code in them, and do tricky osd rendering, adding black bars without using more YUV memory (when window and overlay aspect differs) and so on. Since controls like RESIZE_DEST come from teh vf layer, vf_vo can send it to both vo drivers, it's not problem. Any comments? Maybe i'm wrong and lots some important point making this impossible? Looks way too simple and easy :) 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 Jul 20 18:21:02 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 20 Jul 2003 18:21:02 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase Message-ID: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> Hi, Imho we should consider removing of some included libraries from g2: - libmpdvdkit - it doesnt differ from libdvdcss/libdvdread nowdays (originally it was created to include several patches and bugfixes not present in official libdvdcss/libdvdread) - libmpeg2 - it's quite broken, at least it cannot handle seeking at all and is already patched to hell to work at all work mplayer... Also when we port things from g1, we should consider - dropping .raw font support, imho freetype alone is enough. - libdha / vidix shouldnt be included, but support the vidix.sf.net release instead - dropping xvid_vbr.c/divx4_vbr.c, last evrsins of divx5/xvid/lavc have its own 2pass API functions, no need for external control anything left out? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From joey at nicewarrior.org Sun Jul 20 18:52:35 2003 From: joey at nicewarrior.org (Joseph Parrish) Date: Sun, 20 Jul 2003 11:52:35 -0500 (CDT) Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> Message-ID: <1533.4.64.231.70.1058719955.squirrel@pop.jtan.com> > Hi, > > Imho we should consider removing of some included libraries from g2: > > - libmpdvdkit - it doesnt differ from libdvdcss/libdvdread nowdays > (originally it was created to include several patches and bugfixes > not present in official libdvdcss/libdvdread) I agree with all, except libmpdvdkit. Please correct me if I'm wrong, I've lost internet access at home and can't do a quick grep through the source to verify this... Does mplayer support external libdvdcss? IIRC, it supports "libcss" which doesn't seem to be compatible with latest libdvdcss. Drop mpdvdkit from G2, just don't forget that the libcss support from G1 is not right. --Joey From arpi at thot.banki.hu Sun Jul 20 19:05:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 20 Jul 2003 19:05:50 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <1533.4.64.231.70.1058719955.squirrel@pop.jtan.com> Message-ID: <200307201705.h6KH5oPg017968@mail.mplayerhq.hu> Hi, > > Imho we should consider removing of some included libraries from g2: > > > > - libmpdvdkit - it doesnt differ from libdvdcss/libdvdread nowdays > > (originally it was created to include several patches and bugfixes > > not present in official libdvdcss/libdvdread) > > I agree with all, except libmpdvdkit. Please correct me if I'm wrong, > I've lost internet access at home and can't do a quick grep through the > source to verify this... > > Does mplayer support external libdvdcss? IIRC, it supports "libcss" which > doesn't seem to be compatible with latest libdvdcss. Drop mpdvdkit from > G2, just don't forget that the libcss support from G1 is not right. I dont plan to port libcss support from g1. It's a very very old hack, from the pre-libdvdcss times. And anyway, dinamically loaded libdvdcss is a feature of the official libdvdread, so by using the official libdvdread it's also supported. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lgb at lgb.hu Sun Jul 20 19:06:19 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Sun, 20 Jul 2003 19:06:19 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <200307201705.h6KH5oPg017968@mail.mplayerhq.hu> References: <1533.4.64.231.70.1058719955.squirrel@pop.jtan.com> <200307201705.h6KH5oPg017968@mail.mplayerhq.hu> Message-ID: <20030720170619.GB10519@vega.digitel2002.hu> On Sun, Jul 20, 2003 at 07:05:50PM +0200, Arpi wrote: > > Does mplayer support external libdvdcss? IIRC, it supports "libcss" which > > doesn't seem to be compatible with latest libdvdcss. Drop mpdvdkit from > > G2, just don't forget that the libcss support from G1 is not right. > > I dont plan to port libcss support from g1. It's a very very old hack, > from the pre-libdvdcss times. Agreed. This was an ugly hack by me, because my brand new DVD drive was not supported under Linux to play DVDs by other players ... it's simply a hack to decode file on-the-fly, which also means that it was nothing with IFO or something, you should mount DVD disk, select a file from video_ts dir, and mplayer decoded the stream on the fly by libcss but NOTHING more ... I don't think that it's ("old-style dvd support") used by even one user nowdays :) It was especially ugly because it needs root right or a setuit wrapper program to get the physical starting sector of file which is needed by CSS. Or at least AFAIK, and as far as I remember ;) > And anyway, dinamically loaded libdvdcss is a feature of the official > libdvdread, so by using the official libdvdread it's also supported. - G?bor (larta'H) From ivan at cacad.com Sun Jul 20 21:14:01 2003 From: ivan at cacad.com (Ivan Kalvachev) Date: Sun, 20 Jul 2003 22:14:01 +0300 (EEST) Subject: [MPlayer-G2-dev] new idea for vo parent-child, xover etc. In-Reply-To: <200307201146.h6KBkRxx015961@mail.mplayerhq.hu> References: <200307201146.h6KBkRxx015961@mail.mplayerhq.hu> Message-ID: <1568.194.12.248.135.1058728441.squirrel@mail.cacad.com> Arpi said: > Hi, > > Albeu implemented vo_xover, nice. > [snip] > Let's allow vf_vo2 to control 2 vo in a special way, ie. parent and > chield. It could open vo_x11 to draw a window with colorkey, osd etc, > and open vo_mga to display overlay to translated coords retrieved from > vo_x11 (unfortunatelly we need a special control to get absolute window > position... or put that info to the vo struct, like win_x, win_y) just FYI. XvMC have a blend function that can do "picture in picture" displaying Xvideo shm image as OSD. And this is different than the usuall IA44 osd format:)) [snip] > A'rpi / Astral & ESP-team Best Regards Ivan Kalvachev iive From albeu at free.fr Sun Jul 20 21:44:38 2003 From: albeu at free.fr (Alban Bedel) Date: Sun, 20 Jul 2003 21:44:38 +0200 Subject: [MPlayer-G2-dev] OSD, again :) Message-ID: <20030720214438.18e2ce2e.albeu@free.fr> Hi, The system is based on what i called "osd display". The display role is to manage draw/clear of the various objects currently attached to the display. Once a display is configured then you just feed it with some mp_image and it will draw the objects. The "osd display" doesn't do any drawing/clearing. It just take care of what have to be done, draw are handled by the object themself, and clear by a callback. The system make the drawing/clearing decisions upon the "buffer type". The display itself have a buffer type but it's also possible to define some area with a different buffer type. There is 3 buffer types : TEMP : We never clear it, everything is redrawn at every frame STATIC : We need to clear it if it change but we don't need to redraw it at every frame. LOCKED : This forbid drawing. So TEMP is the movie area, STATIC the black bands and LOCKED is for IP/B, PRESERVE, etc. The osd filter is just like expand (should have took it ;) But by default the filter will use LOCKED area for IP/B so you won't see anythig unless you either expand enouth or use force=1 (wich then allow DR only on TEMP). The osd object need freetype (with freetype-config for the build). So you also need to pass it a font name. Use something like: -vop osd=force=1:objs=test=font=/path/to/your/font and you should see some text comming from the right :) Ok, this is "just some experiment", feedback appreciated :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. -------------- next part -------------- A non-text attachment was scrubbed... Name: g2.osd.diff Type: application/octet-stream Size: 32571 bytes Desc: not available URL: From arpi at thot.banki.hu Mon Jul 21 00:08:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 21 Jul 2003 00:08:43 +0200 Subject: [MPlayer-G2-dev] OSD, again :) In-Reply-To: <20030720214438.18e2ce2e.albeu@free.fr> Message-ID: <200307202208.h6KM8hDp020674@mail.mplayerhq.hu> Hi, Hmm, interesting code, but far from perfect... :) Actually a better description of how objects are related and what is the purpose of them, maybe telling me/us how does rendering subtitles and osd symbols will eb done using this API would explain it better than RTFS. > The system is based on what i called "osd display". The display role is > to manage draw/clear of the various objects currently attached to the > display. Once a display is configured then you just feed it with some > mp_image and it will draw the objects. > The "osd display" doesn't do any drawing/clearing. It just take care > of what have to be done, draw are handled by the object themself, and > clear by a callback. > The system make the drawing/clearing decisions upon the "buffer type". > The display itself have a buffer type but it's also possible to define > some area with a different buffer type. There is 3 > buffer types : I like the basic idea, but: - it shouldn't mess with mpi. NEVER! it will be used on non-mpi surfaces too, like vo buffer, lcd device or spu encoder, or vo_dvb's osd buffer. - there should be per-area (and not per-display) draw & clear functions (the purpose of multiple areas in a display to handle areas with different behaviour - so allowing different funcs is trivial) - instead of TEMP/STATIC/LOCKED types (btw why is buffer_type in both display and area structs? i guess the display one is obsolete/unused?) there should be save and restore modes, describing how to do these: save modes: - just draw (it's TEMP) - save original pixels before draw (if the osd object doesnt support this, we should save whole area) restore modes: - no need to restore - fill with given color - call external clear function - restore saved original pixels maybe it's better to combine single mode parameter... so: - just draw (TEMP) - save & restore original pixels - fill with given color - call external save & restore functions - rendering: we should add a generic luma+alpha osd renderer (like in g1), so simple osd objects could use that. supporting many pixel formats in every osd obj is nonsence and big work. although this renderer should optinally support colors. this renderer could do optimized orig. pixel saving/restoring too (based on alpha value). Maybe a generic font rendering engine could help a lot, so it could cache up font bitmaps, saher between osd objects, etc etc - what about the spu and text (ascii) output/passthru ? - how to pass text to be displayed to the osd objects from outside (eg. UI) ? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Mon Jul 21 01:54:41 2003 From: albeu at free.fr (Alban Bedel) Date: Mon, 21 Jul 2003 01:54:41 +0200 Subject: [MPlayer-G2-dev] Re: OSD, again :) References: <20030720214438.18e2ce2e.albeu@free.fr> <200307202208.h6KM8hDp020674@mail.mplayerhq.hu> Message-ID: <20030721015441.39a275f5.albeu@free.fr> Hi Arpi, on Mon, 21 Jul 2003 00:08:43 +0200 you wrote: > Hi, > > Hmm, interesting code, but far from perfect... :) Sure :) > Actually a better description of how objects are related and what is the > purpose of them, maybe telling me/us how does rendering subtitles and > osd symbols will eb done using this API would explain it better than > RTFS. hmm, RTF vo_osd.c :) A display is createad/exported by vf/vo/whatever (if needed it add some area). Finnaly the clients (main app, subtitle renderer, etc) create the objects they need and attach them to the display. The clients should only deal with the objects. Settings specific to an object type (like setting the current string to display) will probably go through control. > > The system is based on what i called "osd display". The display role > > is to manage draw/clear of the various objects currently attached to > > the display. Once a display is configured then you just feed it with > > some mp_image and it will draw the objects. > > The "osd display" doesn't do any drawing/clearing. It just take care > > of what have to be done, draw are handled by the object themself, and > > clear by a callback. > > The system make the drawing/clearing decisions upon the "buffer type". > > The display itself have a buffer type but it's also possible to define > > some area with a different buffer type. There is 3 > > buffer types : > > I like the basic idea, but: > - it shouldn't mess with mpi. NEVER! > it will be used on non-mpi surfaces too, like vo buffer, lcd device > or spu encoder, or vo_dvb's osd buffer. This is discutable :) mpi is nice atm bcs it can handle pretty much any kind of data, and we alredy have some useful helper for it :) Anyway if we darsticly reduce the number of colorspace then, yes mpi doesn't make that much sense. However if draw might be done in planar YUV i still vote for the mpi bcs it's nice for the object writer. > - there should be per-area (and not per-display) draw & clear functions > (the purpose of multiple areas in a display to handle areas with > different behaviour - so allowing different funcs is trivial) Draw is currently done directly by the object, clear is per display. > - instead of TEMP/STATIC/LOCKED types (btw why is buffer_type in both > display and area structs? i guess the display one is obsolete/unused?) It's the type of the "root", ie object wich doesn't fall in any area. > there should be save and restore modes, describing how to do these: > save modes: > - just draw (it's TEMP) > - save original pixels before draw > (if the osd object doesnt support this, we should save whole area) > restore modes: > - no need to restore > - fill with given color > - call external clear function > - restore saved original pixels > maybe it's better to combine single mode parameter... so: yes > - just draw (TEMP) > - save & restore original pixels > - fill with given color > - call external save & restore functions ok > - rendering: we should add a generic luma+alpha osd renderer (like in > g1), so > simple osd objects could use that. supporting many pixel formats in > every osd obj is nonsence and big work. I think you'r right on this. And anyway we need to cache the drawing so it doesn't really make sense to draw directly on the target buffer. > although this renderer should > optinally support colors. this renderer could do optimized orig. pixel > saving/restoring too (based on alpha value). So we must define wich colorspace we support. Obviously 8bit gray + 8bit alpha like in g1, 8bit char for ASCII. For color dunno, 24bit RGB + 8bit alpha, or do we go for YUV + alpha too ? > Maybe a generic font rendering engine could help a lot, so it could > cache up font bitmaps, saher between osd objects, etc etc That would be nice. I have to look but i think freetype have some caching stuff. That's perhaps enouth ? > - what about the spu and text (ascii) output/passthru ? Text output make only sense when the object drawing function support it imho. For the rest we can try lib aa,conversion but i doubt it will really work :) For spu i don't really know. We must output the osd to an encoder and then pass the coded stuff to the vo. So we probaly need yet another interface for these encoders. For real passthru (ie only dvd subs "as is") we just get rid of all this crap and pass the packets from the demuxer right to the vo :) Ok, we need to process these packet a bit before passing them to the vo ircc. But imho i don't think that we should bother with that here. > - how to pass text to be displayed to the osd objects from outside (eg. > UI) ? control :) A more important question is how will it iteract nicely with the subtitle chain ? Well the subtitle chain is still to be defined ;) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From arpi at thot.banki.hu Mon Jul 21 03:06:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 21 Jul 2003 03:06:50 +0200 Subject: [MPlayer-G2-dev] Re: OSD, again :) In-Reply-To: <20030721015441.39a275f5.albeu@free.fr> Message-ID: <200307210106.h6L16otG016629@mail.mplayerhq.hu> Hi, > > Hmm, interesting code, but far from perfect... :) > Sure :) > > > Actually a better description of how objects are related and what is the > > purpose of them, maybe telling me/us how does rendering subtitles and > > osd symbols will eb done using this API would explain it better than > > RTFS. > hmm, RTF vo_osd.c :) A display is createad/exported by vf/vo/whatever > (if needed it add some area). Finnaly the clients (main app, subtitle > renderer, etc) create the objects they need and attach them to the > display. The clients should only deal with the objects. Settings specific > to an object type (like setting the current string to display) will > probably go through control. > > > > The system is based on what i called "osd display". The display role > > > is to manage draw/clear of the various objects currently attached to > > > the display. Once a display is configured then you just feed it with > > > some mp_image and it will draw the objects. > > > The "osd display" doesn't do any drawing/clearing. It just take care > > > of what have to be done, draw are handled by the object themself, and > > > clear by a callback. > > > The system make the drawing/clearing decisions upon the "buffer type". > > > The display itself have a buffer type but it's also possible to define > > > some area with a different buffer type. There is 3 > > > buffer types : > > > > I like the basic idea, but: > > - it shouldn't mess with mpi. NEVER! > > it will be used on non-mpi surfaces too, like vo buffer, lcd device > > or spu encoder, or vo_dvb's osd buffer. > This is discutable :) mpi is nice atm bcs it can handle pretty much any > kind of data, and we alredy have some useful helper for it :) > Anyway if we darsticly reduce the number of colorspace then, yes > mpi doesn't make that much sense. However if draw might be done in planar > YUV i still vote for the mpi bcs it's nice for the object writer. i want to keep those layers independent, so not using vf/mpi functions in osd and vo etc. actually i put vf to the top, nothing outside of video/ should depend on it. vf interfaces (via wrappers) to vd, vo, osd. as you saw, i even want to handle vo-vo connection (parent+child) in vf_vo2 instead of the vo drivers, to keep the rest simple. ok maybe i move too much code to vf, but i have some (arguable) reason: i know the vf layer very well, and if we can keep all the rest (vd, vo, osd etc) simple (atomic) then we don't have to change APIs, fix bugs, add features etc at many places. if you remember :), in g1 we couldn't do many API changes (or it was painful and buggy) due to complex code everywhere includeing the atomic modules/plugins. my design "idea" for g2, to keep every layer simple, atomic, and add complex wrappers to handle the mess. > > - there should be per-area (and not per-display) draw & clear functions > > (the purpose of multiple areas in a display to handle areas with > > different behaviour - so allowing different funcs is trivial) > Draw is currently done directly by the object, clear is per display. I saw, but i dont like it for example, the DVB card (and the hauppauge PVR 250/350 too) have object-oriented OSD, so you can define small areas with 1/2/4/8 bpp resolution (paletted rgb+alpha) and put osd there. the total memory usage of these areas is very limited :( > > - instead of TEMP/STATIC/LOCKED types (btw why is buffer_type in both > > display and area structs? i guess the display one is obsolete/unused?) > It's the type of the "root", ie object wich doesn't fall in any area. imho it's nonsence. the 'root' (space uncovered by areas) should be forbidden, ie never draw there. or do you want to allow overlapping areas, ie. root drawable with a hole in the middle defined by an 'locked' type area? doesnt worth it. imho handling root specially just makes osd code a bit more compelx, with no real value. > > there should be save and restore modes, describing how to do these: > > save modes: > > - just draw (it's TEMP) > > - save original pixels before draw > > (if the osd object doesnt support this, we should save whole area) > > restore modes: > > - no need to restore > > - fill with given color > > - call external clear function > > - restore saved original pixels > > maybe it's better to combine single mode parameter... so: > yes > > - just draw (TEMP) > > - save & restore original pixels > > - fill with given color > > - call external save & restore functions > ok > > > - rendering: we should add a generic luma+alpha osd renderer (like in > > g1), so > > simple osd objects could use that. supporting many pixel formats in > > every osd obj is nonsence and big work. > I think you'r right on this. And anyway we need to cache the drawing so yes > it doesn't really make sense to draw directly on the target buffer. > > > although this renderer should > > optinally support colors. this renderer could do optimized orig. pixel > > saving/restoring too (based on alpha value). > So we must define wich colorspace we support. Obviously 8bit gray + 8bit > alpha like in g1, 8bit char for ASCII. For color dunno, 24bit RGB + 8bit > alpha, or do we go for YUV + alpha too ? i agree with gray+alpha bitmap, with global color parameter to renderer (so you can render colored text as many ppl wanted earlier) for text, i vote for 16bit or 32bit unicode. there are chinese and japanise mplayer users too :) and we have to pass unicode to text->bitmap renderer, so unless you want to do codepage conversion inside the osd object, it's better to passthru as-is. for color bitmaps, probably rgba32 (with alpha) and a 8bpp palettized format should be used. we only need yuv overlay for SPU subtitles, and they are already palettized things. also palette allows several optimizations in renderer, and assist hardware osd (spu, dvb) better. the palette could come in yuv or rgb, doesnt really matter (easy to convert). it's already 4 -> many converters... > > Maybe a generic font rendering engine could help a lot, so it could > > cache up font bitmaps, saher between osd objects, etc etc > That would be nice. I have to look but i think freetype have some caching > stuff. That's perhaps enouth ? probably it's better to cache the alphamapped chars (remember the runtime generated outlining+blur alphamaps) imho it would be nice to have some char (and/or string) rendering function, and also some draw_box style thing in the osd core to help the osd objects. > > - what about the spu and text (ascii) output/passthru ? > Text output make only sense when the object drawing function support > it imho. For the rest we can try lib aa,conversion but i doubt it will > really work :) > > For spu i don't really know. We must output the osd to an encoder > and then pass the coded stuff to the vo. So we probaly need yet > another interface for these encoders. No real need for new interface, we'll define a way to pass osd data (remember the external draw function) in ascii or gray+alpha format to the vo (via DRAW_OSD-like controls/functions) so SPU-capable vo driver(s) can call the encoder and pass teh data. Afaik only dxr3 can handle SPU. DVB and PVR have their own OSD pixel formats. AAlib handles text. In this case the vo driver will create the osd display, set format to what it can accept. > For real passthru (ie only dvd subs "as is") we just get rid of all this > crap and pass the packets from the demuxer right to the vo :) > Ok, we need to process these packet a bit before passing them to the vo > ircc. But imho i don't think that we should bother with that here. i tend to agree... maybe we could allow passthru (not using osd layer at all) or decoding, osd layer stuff, and finally encoding. thsi way users could add osd symbols and other stuff to the spu with relative low cpu usage. > > - how to pass text to be displayed to the osd objects from outside (eg. > > UI) ? > control :) A more important question is how will it iteract nicely with > the subtitle chain ? it's the job of the UI and the a-v sync playback loop/core. UI can define where (osd object) to render the subtitles, and the A-V sync stuff will lookup the right subtitle (from demuxer) and pass to the osd. > Well the subtitle chain is still to be defined ;) i'm not sure if we need subtitle decoders/filters now. esp. that the spu/ascii/bitmap conversion will be handled by osd/vo stuff. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Mon Jul 21 12:00:41 2003 From: albeu at free.fr (Alban Bedel) Date: Mon, 21 Jul 2003 12:00:41 +0200 Subject: [MPlayer-G2-dev] Re: OSD, again :) References: <20030721015441.39a275f5.albeu@free.fr> <200307210106.h6L16otG016629@mail.mplayerhq.hu> Message-ID: <20030721120041.2a8b893d.albeu@free.fr> Hi Arpi, on Mon, 21 Jul 2003 03:06:50 +0200 you wrote: > Hi, > > > > Hmm, interesting code, but far from perfect... :) > > Sure :) > > > > > Actually a better description of how objects are related and what is > > > the purpose of them, maybe telling me/us how does rendering > > > subtitles and osd symbols will eb done using this API would explain > > > it better than RTFS. > > hmm, RTF vo_osd.c :) A display is createad/exported by vf/vo/whatever > > (if needed it add some area). Finnaly the clients (main app, subtitle > > renderer, etc) create the objects they need and attach them to the > > display. The clients should only deal with the objects. Settings > > specific to an object type (like setting the current string to > > display) will probably go through control. > > > > > > The system is based on what i called "osd display". The display > > > > role is to manage draw/clear of the various objects currently > > > > attached to the display. Once a display is configured then you > > > > just feed it with some mp_image and it will draw the objects. > > > > The "osd display" doesn't do any drawing/clearing. It just take > > > > care of what have to be done, draw are handled by the object > > > > themself, and clear by a callback. > > > > The system make the drawing/clearing decisions upon the "buffer > > > > type". The display itself have a buffer type but it's also > > > > possible to define some area with a different buffer type. There > > > > is 3 buffer types : > > > > > > I like the basic idea, but: > > > - it shouldn't mess with mpi. NEVER! > > > it will be used on non-mpi surfaces too, like vo buffer, lcd > > > device or spu encoder, or vo_dvb's osd buffer. > > This is discutable :) mpi is nice atm bcs it can handle pretty much > > any kind of data, and we alredy have some useful helper for it :) > > Anyway if we darsticly reduce the number of colorspace then, yes > > mpi doesn't make that much sense. However if draw might be done in > > planar YUV i still vote for the mpi bcs it's nice for the object > > writer. > > i want to keep those layers independent, so not using vf/mpi functions > in osd and vo etc. > actually i put vf to the top, nothing outside of video/ should depend on > it. vf interfaces (via wrappers) to vd, vo, osd. Nothing in the current osd code depend on vf, beside the use of 2 headers imagefmt.h and mp_image.h. Anyway i don't plan to keep on using mpi, don't worry :) > as you saw, i even want to handle vo-vo connection (parent+child) in > vf_vo2 instead of the vo drivers, to keep the rest simple. > > ok maybe i move too much code to vf, but i have some (arguable) reason: > i know the vf layer very well, and if we can keep all the rest (vd, vo, > osd etc) simple (atomic) then we don't have to change APIs, fix bugs, > add features etc at many places. > > if you remember :), in g1 we couldn't do many API changes (or it was > painful and buggy) due to complex code everywhere includeing the atomic > modules/plugins. i do remember that pain ;) > my design "idea" for g2, to keep every layer simple, atomic, and add > complex wrappers to handle the mess. I know and i want the same. > > > - there should be per-area (and not per-display) draw & clear > > > functions > > > (the purpose of multiple areas in a display to handle areas with > > > different behaviour - so allowing different funcs is trivial) > > Draw is currently done directly by the object, clear is per display. > > I saw, but i dont like it > for example, the DVB card (and the hauppauge PVR 250/350 too) have > object-oriented OSD, so you can define small areas with 1/2/4/8 bpp > resolution (paletted rgb+alpha) and put osd there. the total memory > usage of these areas is very limited :( Ok, i wasn't aware of that. On the other hand most of the other stuff on wich osd will drawn don't behave like this. Also this imply a completly different way of managing the objects. I need to think more about these :) > > > - instead of TEMP/STATIC/LOCKED types (btw why is buffer_type in > > > both > > > display and area structs? i guess the display one is > > > obsolete/unused?) > > It's the type of the "root", ie object wich doesn't fall in any area. > > imho it's nonsence. > the 'root' (space uncovered by areas) should be forbidden, ie never draw > there. or do you want to allow overlapping areas, ie. root drawable with > a hole in the middle defined by an 'locked' type area? doesnt worth it. imho forbiding the root as a whole is none-sense. Take the common case where you have some black space around the movie. An area define the space where the movie is draw. Unless you are in the rare case that the movie need a temp buffer you have to handle stuff draw on movie differently than those on the black parts. But if you forbid draw on the root then what can you do ? Define 4 areas around the movie ??? That doesn't make more sense. The idea behind area is just to define (if at all needed) how object (or part of object) found in a particular part of the display must be cleared/drawn. > imho handling root specially just makes osd code a bit more compelx, > with no real value. I think you didn't understood that these "area" are only hints so to say. These hints are used by the display to properly clear/draw object. Such thing is imho requiered if the system must handle more complex case than just a movie wich take the whole screen. > > > there should be save and restore modes, describing how to do > > > these: > > > save modes: > > > - just draw (it's TEMP) > > > - save original pixels before draw > > > (if the osd object doesnt support this, we should save whole > > > area) > > > restore modes: > > > - no need to restore > > > - fill with given color > > > - call external clear function > > > - restore saved original pixels > > > maybe it's better to combine single mode parameter... so: > > yes > > > - just draw (TEMP) > > > - save & restore original pixels > > > - fill with given color > > > - call external save & restore functions > > ok > > > > > - rendering: we should add a generic luma+alpha osd renderer (like > > > in g1), so > > > simple osd objects could use that. supporting many pixel formats > > > in every osd obj is nonsence and big work. > > I think you'r right on this. And anyway we need to cache the drawing > > so > > yes > > > it doesn't really make sense to draw directly on the target buffer. > > > > > although this renderer should > > > optinally support colors. this renderer could do optimized orig. > > > pixel saving/restoring too (based on alpha value). > > So we must define wich colorspace we support. Obviously 8bit gray + > > 8bit alpha like in g1, 8bit char for ASCII. For color dunno, 24bit RGB > > + 8bit alpha, or do we go for YUV + alpha too ? > > i agree with gray+alpha bitmap, with global color parameter to renderer > (so you can render colored text as many ppl wanted earlier) Good idea. > for text, i vote for 16bit or 32bit unicode. > there are chinese and japanise mplayer users too :) Ok. But afaik text display only use 8bit char, dunno how it is for chinese. That would be a bit stupid if 90% of the user end up with c char -> unicode -> c char. > and we have to pass unicode to text->bitmap renderer, so unless you want > to do codepage conversion inside the osd object, it's better to passthru > as-is. > > for color bitmaps, probably rgba32 (with alpha) and a 8bpp palettized > format should be used. we only need yuv overlay for SPU subtitles, and > they are already palettized things. also palette allows several > optimizations in renderer, and assist hardware osd (spu, dvb) better. > > the palette could come in yuv or rgb, doesnt really matter (easy to > convert). > > it's already 4 -> many converters... yes :) > > > Maybe a generic font rendering engine could help a lot, so it > > > could cache up font bitmaps, saher between osd objects, etc etc > > That would be nice. I have to look but i think freetype have some > > caching stuff. That's perhaps enouth ? > > probably it's better to cache the alphamapped chars (remember the > runtime generated outlining+blur alphamaps) > > imho it would be nice to have some char (and/or string) rendering > function, and also some draw_box style thing in the osd core to help the > osd objects. Yes, would be nice :) > > > - what about the spu and text (ascii) output/passthru ? > > Text output make only sense when the object drawing function support > > it imho. For the rest we can try lib aa,conversion but i doubt it will > > really work :) > > > > For spu i don't really know. We must output the osd to an encoder > > and then pass the coded stuff to the vo. So we probaly need yet > > another interface for these encoders. > > No real need for new interface, we'll define a way to pass osd data > (remember the external draw function) in ascii or gray+alpha format to > the vo (via DRAW_OSD-like controls/functions) so SPU-capable vo > driver(s) can call the encoder and pass teh data. Afaik only dxr3 can > handle SPU. DVB and PVR have their own OSD pixel formats. AAlib handles > text. Imho vo shouldn't have to use the spu encoder themself. That's why i talked about another interface. > In this case the vo driver will create the osd display, set format to > what it can accept. For SPU it's probably better and simpler to pass the encoded data to the vo directly. > > For real passthru (ie only dvd subs "as is") we just get rid of all > > this crap and pass the packets from the demuxer right to the vo :) > > Ok, we need to process these packet a bit before passing them to the > > vo ircc. But imho i don't think that we should bother with that here. > > i tend to agree... > maybe we could allow passthru (not using osd layer at all) or decoding, > osd layer stuff, and finally encoding. thsi way users could add osd > symbols and other stuff to the spu with relative low cpu usage. > > > - how to pass text to be displayed to the osd objects from outside > > > (eg. UI) ? > > control :) A more important question is how will it iteract nicely > > with the subtitle chain ? > > it's the job of the UI and the a-v sync playback loop/core. > UI can define where (osd object) to render the subtitles, and the A-V > sync stuff will lookup the right subtitle (from demuxer) and pass to the > osd. As long as there is no subtitle filter, that's ok. > > Well the subtitle chain is still to be defined ;) > > i'm not sure if we need subtitle decoders/filters now. > esp. that the spu/ascii/bitmap conversion will be handled by osd/vo > stuff. Atm there is no need for subtitle filtering but we have to keep it in mind ;) Albeu PS: I'm going to .nl and .fr for holidays today, so my next reply is in 3 weeks :) -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs. From nsabbi at libero.it Mon Jul 21 21:10:47 2003 From: nsabbi at libero.it (Nico) Date: Mon, 21 Jul 2003 21:10:47 +0200 Subject: [MPlayer-G2-dev] demux_packet_t question References: <200307210106.h6L16otG016629@mail.mplayerhq.hu> Message-ID: <3F1C3AB7.8030608@libero.it> Hi, what's the use of the last 8 bytes in new_demux_packet() ? dp->buffer=len?(unsigned char*)malloc(len+8):NULL; if(len) memset(dp->buffer+len,0,8); If I want to change via realloc() the size of the packet (I know it' nasty, but just to know) how should I reflect the change in these last 8 bytes ? Thanks, Nico From arpi at thot.banki.hu Mon Jul 21 21:22:51 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 21 Jul 2003 21:22:51 +0200 Subject: [MPlayer-G2-dev] demux_packet_t question In-Reply-To: <3F1C3AB7.8030608@libero.it> Message-ID: <200307211922.h6LJMpGA028175@mail.mplayerhq.hu> Hi, > what's the use of the last 8 bytes in new_demux_packet() ? some codecs - libavcodec - reads a few bytes (ma x8) more than required (due to buffering of get_bits) so to avoid sig11 we allocate 8 bytes more. it's nasty, but a lot faster than boundary checking in get_bits() which is called million times per frame. > dp->buffer=len?(unsigned char*)malloc(len+8):NULL; > if(len) memset(dp->buffer+len,0,8); > > If I want to change via realloc() the size of the packet (I know it' > nasty, but just to know) > how should I reflect the change in these last 8 bytes ? dunno, depends on codec you will use overallocating doesnt hurt A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Tue Jul 22 07:47:27 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 22 Jul 2003 01:47:27 -0400 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> Message-ID: <20030722054727.GA253@brightrain.aerifal.cx> On Sun, Jul 20, 2003 at 06:21:02PM +0200, Arpi wrote: > Hi, > > Imho we should consider removing of some included libraries from g2: > > - libmpdvdkit - it doesnt differ from libdvdcss/libdvdread nowdays > (originally it was created to include several patches and bugfixes > not present in official libdvdcss/libdvdread) Agree mostly, but a bit undecided... It sucks for users to have to install special libs to compile a working mplayer, especially when those libs are considered "risky" by distro maintainers, and thus not included in distros. > - libmpeg2 - it's quite broken, at least it cannot handle seeking at all > and is already patched to hell to work at all work mplayer... And slower than libavcodec, it seems... > Also when we port things from g1, we should consider > > - dropping .raw font support, imho freetype alone is enough. Agree totally. > - libdha / vidix shouldnt be included, but support the vidix.sf.net release > instead Yes, or something better (not so brain-damaged)... > - dropping xvid_vbr.c/divx4_vbr.c, last evrsins of divx5/xvid/lavc have its > own 2pass API functions, no need for external control Agree. > anything left out? Of course. Nothing in particular comes to mind, but there're tons of nonsense hacks that should NOT be ported to g2... Rich From gabucino at mplayerhq.hu Tue Jul 22 09:21:35 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Tue, 22 Jul 2003 09:21:35 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <20030722054727.GA253@brightrain.aerifal.cx> References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> <20030722054727.GA253@brightrain.aerifal.cx> Message-ID: <20030722072135.GC871@woodstock.localdomain> D Richard Felker III wrote: > Agree mostly, but a bit undecided... It sucks for users to have to > install special libs to compile a working mplayer, especially when > those libs are considered "risky" by distro maintainers, and thus not > included in distros. So they are gonna drop it out of MPlayer too :) BTW Joe User usually installs libdvd* stuff anyways, just in case.. So we might actually drop mpdvdkit. > > - libmpeg2 - it's quite broken, at least it cannot handle seeking at all > > and is already patched to hell to work at all work mplayer... > And slower than libavcodec, it seems... libmpeg2: BENCHMARKs: VC: 0.825s VO: 1.394s A: 0.000s Sys: 0.329s = 2.548s ffmpeg12: BENCHMARKs: VC: 0.999s VO: 1.300s A: 0.000s Sys: 0.378s = 2.677s libmpeg2 seems to be 5% faster (x86), can be considered marginal, for sake of simplicity and workability. > > Also when we port things from g1, we should consider > > - dropping .raw font support, imho freetype alone is enough. > Agree totally. Hold the horses ;) While personally I haven't used RAW fonts for about a year, the libttf-dependancy I think is a very good reason to keep RAW fonts. And on top of all the shit, only recent libttf works together with MPlayer... -- 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 diego at biurrun.de Tue Jul 22 17:59:57 2003 From: diego at biurrun.de (Diego Biurrun) Date: Tue, 22 Jul 2003 17:59:57 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <20030722072135.GC871@woodstock.localdomain> References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> <20030722054727.GA253@brightrain.aerifal.cx> <20030722072135.GC871@woodstock.localdomain> Message-ID: <16157.24445.219742.54869@silver.semantics.de> gabucino at mplayerhq.hu writes: > D Richard Felker III wrote: > > Agree mostly, but a bit undecided... It sucks for users to have to > > install special libs to compile a working mplayer, especially when > > those libs are considered "risky" by distro maintainers, and thus not > > included in distros. > So they are gonna drop it out of MPlayer too :) > BTW Joe User usually installs libdvd* stuff anyways, just in case.. So we > might actually drop mpdvdkit. I don't think Joe User does that, but since Joe User is such a hypothetical person, let's not speculate any further. We can also make a compromise here: Remove libmpdvdkit, but add a link to it on our download page and try to document it properly, something like "Step X: download some extra libs". We might also build some all-in-one packages for greater convenience, but this is just a wild idea. > > > Also when we port things from g1, we should consider > > > - dropping .raw font support, imho freetype alone is enough. > > Agree totally. > Hold the horses ;) While personally I haven't used RAW fonts for about a year, > the libttf-dependancy I think is a very good reason to keep RAW fonts. And on > top of all the shit, only recent libttf works together with MPlayer... A new library dependency will not be a problem for G2, it will just have an entirely new set of library dependencies, see above. Besides when it will become usable and widely available moderately old libttf libs will be enough. Diego From nsabbi at libero.it Tue Jul 22 18:26:19 2003 From: nsabbi at libero.it (Nico) Date: Tue, 22 Jul 2003 18:26:19 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> <20030722054727.GA253@brightrain.aerifal.cx> <20030722072135.GC871@woodstock.localdomain> <16157.24445.219742.54869@silver.semantics.de> Message-ID: <3F1D65AB.8040202@libero.it> Diego Biurrun wrote: >gabucino at mplayerhq.hu writes: > > D Richard Felker III wrote: > > > Agree mostly, but a bit undecided... It sucks for users to have to > > > install special libs to compile a working mplayer, especially when > > > those libs are considered "risky" by distro maintainers, and thus not > > > included in distros. > > So they are gonna drop it out of MPlayer too :) > > BTW Joe User usually installs libdvd* stuff anyways, just in case.. So we > > might actually drop mpdvdkit. > >I don't think Joe User does that, but since Joe User is such a >hypothetical person, let's not speculate any further. > >We can also make a compromise here: Remove libmpdvdkit, but add a link >to it on our download page and try to document it properly, something >like "Step X: download some extra libs". We might also build some >all-in-one packages for greater convenience, but this is just a wild >idea. > > mpdvdkit is guaranteed to compile and work out of the tarball, libdvd* dependencies aren't. IMHO if you don't want to be pestered by "boooh, doesn't compile" -> "me too" messages in the ML it's better to keep them. And one thing I would ADD to g2 is faad: it's always a nightmare to compile, as it's always half broken, and not all of the package is needed for mplayer > > > > Also when we port things from g1, we should consider > > > > - dropping .raw font support, imho freetype alone is enough. > > > Agree totally. > > Hold the horses ;) While personally I haven't used RAW fonts for about a year, > > the libttf-dependancy I think is a very good reason to keep RAW fonts. And on > > top of all the shit, only recent libttf works together with MPlayer... > >A new library dependency will not be a problem for G2, it will just >have an entirely new set of library dependencies, see above. Besides >when it will become usable and widely available moderately old libttf >libs will be enough. > >Diego > >_______________________________________________ >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 Tue Jul 22 18:58:57 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 22 Jul 2003 18:58:57 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <16157.24445.219742.54869@silver.semantics.de> Message-ID: <200307221658.h6MGwvvO026426@mail.mplayerhq.hu> Hi, > gabucino at mplayerhq.hu writes: > > D Richard Felker III wrote: > > > Agree mostly, but a bit undecided... It sucks for users to have to > > > install special libs to compile a working mplayer, especially when > > > those libs are considered "risky" by distro maintainers, and thus not > > > included in distros. > > So they are gonna drop it out of MPlayer too :) > > BTW Joe User usually installs libdvd* stuff anyways, just in case.. So we > > might actually drop mpdvdkit. > > I don't think Joe User does that, but since Joe User is such a > hypothetical person, let's not speculate any further. Hey, hey! don't forget where youare, this isn't about G1 at all. We're talking about mp-g2, a library, which is not used as-is by any user. And frontends/guis which will include/support mp-g2 still can ship with mpdvdkit or other dvdcss/dvdread libraries. And anyway when mp-g2 will replace the current g1 tree, we can re-cosider re-including libdvdread/dvdcss again. But for now it's an useless ballast now. > We can also make a compromise here: Remove libmpdvdkit, but add a link > to it on our download page and try to document it properly, something > like "Step X: download some extra libs". We might also build some First we need to create a g2 homepage... > all-in-one packages for greater convenience, but this is just a wild > idea. sure. with libfaad (something which really needs patching to work) and others. > > > > Also when we port things from g1, we should consider > > > > - dropping .raw font support, imho freetype alone is enough. > > > Agree totally. > > Hold the horses ;) While personally I haven't used RAW fonts for about a year, > > the libttf-dependancy I think is a very good reason to keep RAW fonts. And on > > top of all the shit, only recent libttf works together with MPlayer... > > A new library dependency will not be a problem for G2, it will just > have an entirely new set of library dependencies, see above. Besides > when it will become usable and widely available moderately old libttf > libs will be enough. :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From gabucino at mplayerhq.hu Wed Jul 23 00:11:01 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Wed, 23 Jul 2003 00:11:01 +0200 Subject: [MPlayer-G2-dev] reducing/simplifying codebase In-Reply-To: <16157.24445.219742.54869@silver.semantics.de> References: <200307201621.h6KGL28j002286@mail.mplayerhq.hu> <20030722054727.GA253@brightrain.aerifal.cx> <20030722072135.GC871@woodstock.localdomain> <16157.24445.219742.54869@silver.semantics.de> Message-ID: <20030722221101.GC1095@woodstock.localdomain> Diego Biurrun wrote: > I don't think Joe User does that, but since Joe User is such a > hypothetical person, let's not speculate any further. I remember seeing MANY user bugreports saying they've installed libdvd* > We can also make a compromise here: Remove libmpdvdkit, but add a link > to it on our download page No-no ;) It's the same as libdvd*, as A'rpi said. > this is just a wild idea. Yes :) -- 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 Wed Jul 23 03:02:36 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 23 Jul 2003 04:02:36 +0300 Subject: [MPlayer-G2-dev] Question for Arpi :) Message-ID: <20030723010236.GA28408@lucky.net> Hi there! Could you point me to detailed description of new VF API? I don't want to make mistakes so I want description of all API functions. :) Anyway it will be good to have all API described, not only libvo and cfg in DOCS but all APIs. :) With the best wishes. Andriy. From arpi at thot.banki.hu Wed Jul 23 11:55:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 23 Jul 2003 11:55:43 +0200 Subject: [MPlayer-G2-dev] Question for Arpi :) In-Reply-To: <20030723010236.GA28408@lucky.net> Message-ID: <200307230955.h6N9thXn001722@mail.mplayerhq.hu> Hi, > Could you point me to detailed description of new VF API? I don't > want to make mistakes so I want description of all API functions. :) no new vf api, it's teh same as in g1 with little differences i described here on the ML > Anyway it will be good to have all API described, not only libvo and cfg > in DOCS but all APIs. :) agree, feel free to document them... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu Jul 24 10:29:05 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 24 Jul 2003 11:29:05 +0300 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <200307230955.h6N9thXn001722@mail.mplayerhq.hu> References: <20030723010236.GA28408@lucky.net> <200307230955.h6N9thXn001722@mail.mplayerhq.hu> Message-ID: <20030724082905.GA99385@lucky.net> Hi, Arpi! Sometime (on Wednesday, July 23 at 12:48) I've received something... >> Could you point me to detailed description of new VF API? I don't >> want to make mistakes so I want description of all API functions. :) >no new vf api, it's teh same as in g1 with little differences i described >here on the ML Sorry, may be I've lost something but I still don't get exactly how new flag drop works in get_pending_image() and process_image() - does it allow framedropping by filter or does it force drop pulled frame? Another question is what get_pending_image exactly does. Does it just return frame if filter already has one in buffer without pulling it from demuxer, doesn't it? With the best wishes. Andriy. From arpi at thot.banki.hu Thu Jul 24 17:13:45 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 24 Jul 2003 17:13:45 +0200 Subject: [MPlayer-G2-dev] Fwd: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY) In-Reply-To: <825B35E231A@vcnet.vc.cvut.cz> Message-ID: <200307241513.h6OFDjGq005711@mail.mplayerhq.hu> --------- Forwarded message --------- From: "Petr Vandrovec" To: Arpi Subject: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY) On 24 Jul 03 at 3:49, Arpi wrote: > > return -EINVAL; > > if (con == m2info->currcon) > > matroxfb_dh_pan_var(m2info, var); > > dsp->var.xoffset = var->xoffset; > > dsp->var.yoffset = var->yoffset; > > > > like driver does everywhere else. > > :) > > I assume you'll submit this patch to mainstream kernel... Maybe... > > For 2.6.x you can do FBIO_WAITFORVSYNC ioctl, as I finally took Syrjala's > > patch, extended it to handle both CRTC and put into the driver. > > I know his patch, but it makes apps blocking until vsync arrives. > It may work for multithreaded apps (blocking only the display thread), > but for mpalyer (which runs in single thread) it's just eating cpu :( if (!fork()) { ioctl(FBIO_WAITFORVSYNC); ioctl(FBIO_PANDISPLAY); exit(0) ;-) I'm not sure how fast it is... > > Supporting FB_ACTIVATE_VBL for setting videomode is impossible (due to > > connection to the tty subsystem), but if you can find somewhere (or if > > you can persuade me that API author thought it that way) > > that FB_ACTIVATE_VBL should be looked at for panning too, then it is > > definitely (very) simple to extend 2.6.x matroxfb to do that. > > The strange thing is, that both vidmode setting and panning behaves like > FB_ACTIVATE_VBL set for crtc2, and behaves like FB_ACTIVATE_VBL unset > for crtc1. I gues sit's only a (or a few) bits in register programming, > i'll try to find it when i re-read g400 register docs for crtc2 yuv support. page 4-75, CRTC1: When accessing the three-part startadd field, the portion which is located in CRTCEXT0 must always be written; it must always be written after the other portions of startadd, which are located in CRTCC and CRTCD). The change of start address will take effect at the beginning of the next horizontal retrace following the write to CRTCEXT0. Display will continue at the next line, using the new startadd value. This arrangement permits page flipping at any line, with no tearing occurring within the line. To avoid tearing between lines within a frame, software can poll either vcount or the vretrace field of INSTS1, or use the VSYNC interrupt to update CRTCEXT0 between frames. page 4-143, CRTC2: All the addresses programmed in the 2nd CRTC address generator must be aligned on an 8 quadword boundary (the 6 LSBs set to '000000'). All these address registers are double-buffered. This means that, the addresses written in these registers become effective after the beginning of the next vertical blank. At this point, the programming values written during the drawing of a frame will only affect the next frame, therefore, no tearing occurs. So CRTC1 reloads address at the end of line, CRTC2 at the end of frame. No way around it for CRTC2, but we can emulate VBL reload for CRTC1. I'll do that. More work :-( Petr From dalias at aerifal.cx Thu Jul 24 17:25:18 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 24 Jul 2003 11:25:18 -0400 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <20030724082905.GA99385@lucky.net> References: <20030723010236.GA28408@lucky.net> <200307230955.h6N9thXn001722@mail.mplayerhq.hu> <20030724082905.GA99385@lucky.net> Message-ID: <20030724152518.GB253@brightrain.aerifal.cx> On Thu, Jul 24, 2003 at 11:29:05AM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Wednesday, July 23 at 12:48) I've received something... > >> Could you point me to detailed description of new VF API? I don't > >> want to make mistakes so I want description of all API functions. :) > > >no new vf api, it's teh same as in g1 with little differences i described > >here on the ML > > Sorry, may be I've lost something but I still don't get exactly how > new flag drop works in get_pending_image() and process_image() - does it > allow framedropping by filter or does it force drop pulled frame? That's a very misleading way to talk about it. What it allows is for a filter to generate frames in such a way that there is no one-to-one correspondence between input frames and output frames. > Another question is what get_pending_image exactly does. Does it just > return frame if filter already has one in buffer without pulling it from > demuxer, doesn't it? Again, that may be true with certain filters, but it's a misleading way to describe it. I'm still confused over this whole api so I'm not sure what the correct description is. Better to read the ML archives... Rich From andrej at lucky.net Thu Jul 24 17:52:48 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 24 Jul 2003 18:52:48 +0300 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <20030724152518.GB253@brightrain.aerifal.cx> References: <20030723010236.GA28408@lucky.net> <200307230955.h6N9thXn001722@mail.mplayerhq.hu> <20030724082905.GA99385@lucky.net> <20030724152518.GB253@brightrain.aerifal.cx> Message-ID: <20030724155248.GA92967@lucky.net> Hi, D Richard Felker III! Sometime (on Thursday, July 24 at 18:23) I've received something... >> >> Could you point me to detailed description of new VF API? I don't >> >> want to make mistakes so I want description of all API functions. :) >> >no new vf api, it's teh same as in g1 with little differences i described >> >here on the ML >> Sorry, may be I've lost something but I still don't get exactly how >> new flag drop works in get_pending_image() and process_image() - does it >> allow framedropping by filter or does it force drop pulled frame? >That's a very misleading way to talk about it. What it allows is for a >filter to generate frames in such a way that there is no one-to-one >correspondence between input frames and output frames. It's unavoidable in many cases when we're changing framerate. >> Another question is what get_pending_image exactly does. Does it just >> return frame if filter already has one in buffer without pulling it from >> demuxer, doesn't it? >Again, that may be true with certain filters, but it's a misleading >way to describe it. I'm still confused over this whole api so I'm not >sure what the correct description is. Better to read the ML >archives... So I'm confused with API too. It's why I want _really_ exact API description. Then there will no way to say "that may be true but may be not". If we have good defined API then we'll avoid headaches in the future - then with any changes in function it's behavior will never change due to strong API. :) I've got that question when I attempted to port my dint filter from G1 to G2 and get confused with new API then. With best wishes. Andriy. From arpi at thot.banki.hu Thu Jul 24 18:45:19 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 24 Jul 2003 18:45:19 +0200 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <20030724155248.GA92967@lucky.net> Message-ID: <200307241645.h6OGjJ8x024431@mail.mplayerhq.hu> Hi, > So I'm confused with API too. It's why I want _really_ exact API > description. Then there will no way to say "that may be true but may be > not". If we have good defined API then we'll avoid headaches in the > future - then with any changes in function it's behavior will never > change due to strong API. :) The video decoder/filter api is not yet final. There are a few unused fields/flags, and some unclear states. But for ppl wanting to port their filter ASAP, i hacke dtogether a quick text of differences from g1: Video decoder/filter API changes since G1: ========================================== NOTE: first you should read g1's DOCS/tech/libmpcodecs.txt ! Differences in video decoding: ============================== video decoders don't get the demuxed fraem as parameter (data/len) to the decode() function, instead they should request from the demuxer by using ds_get_packet (or other ds reading functions). This change was required to allow non-1:1 demux-packet -> video frame correspondence. For example, libmpeg2 want raw mpeg packets instead of the ES-demuxed frames. Also, field-based mpeg2 could be handled in decoders, by reading 2 ds packet and output 1 frame. Also, decoders can skip demuxer reading, for example when outputting buffered (from previous packets) frames. There is an other difference: decoders may (optional!) alter the timestamps and/or duration got from demuxer. It's required for formats when timestamp is encoded in the video packet (instead of the packet header in container), or when you don't have 1:1 mapping between demuxer packets and frames (see above). Differences in video filters: ============================= By default, everything works the same way as in G1, except that put_image won't call next filter's put_image directly, but return the dmpi. So, instead of 'return vf_next_put_image(vf,dmpi);' you have to write 'return dmpi;' now. And, isntead of 'return 0;' you write 'return NULL;'. Additionally, filters also have a 'drop' parameter, to allow frame dropping at filters. By default you can ignore this flag, your put_image() won't be called when drop!=0. Let's see the non-default case now: Your filters may set 2 special flags to control frame dropping: // filter wants process_image() to be called with mpi=NULL for dropped frames #define VFCAP_NOTIFY_DROPPED_FRAMES 0x2000 // filter wants to see all frames, even if we want to drop them... // (so you can't drop frame above this filter) #define VFCAP_WANTS_DROPPED_FRAMES 0x4000 As you can see, the 'drop' flag has effect only with VFCAP_WANTS_DROPPED_FRAMES. These flags will allow filters to be notified about dropped frames, it's required for pattern-matching (like inverse telecine) filters and temporal postprocessing filters. Non-1:1 frame mapping in filters: In G2, you can write filters outputting more frames than inputting, ie. increasing frame-rate. (Outputting less frames than input was possible in g1 too, by returning no frame (0 in g1, NULL in g2)). For this, you have to implement get_pending_image(). When available, this function will be called first, to check if any buffered/queued frame is available. If it returns NULL, the previous filter (up to the decoder) will be called, and then put_image() will receive the new input frame. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Thu Jul 24 21:22:45 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 24 Jul 2003 21:22:45 +0200 Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <20030716111848.GG32263@watri.org.au> Message-ID: <200307241922.h6OJMjKp030606@mail.mplayerhq.hu> Hi, > I've been working on the new audio I/O library a bit. Can't get the > sync to work, but I will continue to work on it. I will also implement > the new config system (not done yet). Anyway just wanted to show what > I have done to see what you think of it. > > The source I have been working on is from version 33 (I think). > > down load it from: > www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz any updates/new versions? i'm about applying your changes 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 Jul 25 09:59:30 2003 From: ajh at watri.org.au (Anders Johansson) Date: Fri, 25 Jul 2003 15:59:30 +0800 Subject: [MPlayer-G2-dev] New libao2 In-Reply-To: <200307241922.h6OJMjKp030606@mail.mplayerhq.hu> References: <20030716111848.GG32263@watri.org.au> <200307241922.h6OJMjKp030606@mail.mplayerhq.hu> Message-ID: <20030725075930.GA919@watri.org.au> Hi, > Hi, > > > I've been working on the new audio I/O library a bit. Can't get the > > sync to work, but I will continue to work on it. I will also implement > > the new config system (not done yet). Anyway just wanted to show what > > I have done to see what you think of it. > > > > The source I have been working on is from version 33 (I think). > > > > down load it from: > > www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz > > any updates/new versions? No, Only thing I have done is to delete the aio_data_s struct from aio.h. BTW observe that input isn't completely finished (no proper buffering or delay measurement). Also I guess you have noticed that I have separated audio and mixer, what do you think about that? > i'm about applying your changes excellent! I'll continue to work on it once you are done. > > A'rpi / Astral & ESP-team > //Anders From andrej at lucky.net Fri Jul 25 12:05:27 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Fri, 25 Jul 2003 13:05:27 +0300 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <200307241645.h6OGjJ8x024431@mail.mplayerhq.hu> References: <20030724155248.GA92967@lucky.net> <200307241645.h6OGjJ8x024431@mail.mplayerhq.hu> Message-ID: <20030725100527.GA29650@lucky.net> Hi, Arpi! Sometime (on Thursday, July 24 at 19:37) I've received something... [.......] >Differences in video filters: >============================= >By default, everything works the same way as in G1, except that put_image >won't call next filter's put_image directly, but return the dmpi. >So, instead of 'return vf_next_put_image(vf,dmpi);' you have to write >'return dmpi;' now. And, isntead of 'return 0;' you write 'return NULL;'. >Additionally, filters also have a 'drop' parameter, to allow frame >dropping at filters. By default you can ignore this flag, your put_image() >won't be called when drop!=0. >Let's see the non-default case now: >Your filters may set 2 special flags to control frame dropping: >// filter wants process_image() to be called with mpi=NULL for dropped frames >#define VFCAP_NOTIFY_DROPPED_FRAMES 0x2000 >// filter wants to see all frames, even if we want to drop them... >// (so you can't drop frame above this filter) >#define VFCAP_WANTS_DROPPED_FRAMES 0x4000 >As you can see, the 'drop' flag has effect only with VFCAP_WANTS_DROPPED_FRAMES. >These flags will allow filters to be notified about dropped frames, it's >required for pattern-matching (like inverse telecine) filters and temporal >postprocessing filters. Hmm, I've analyzed the sources and didn't get it at all. If we call vf_process_image(vf_last,0) for bottom filter (vo or muxer) then any filter could not get parameter drop as 1. If we call vf_process_image with drop=1 (well, we are about to drop this frame) then again, we never can let filter with VFCAP_WANTS_DROPPED_FRAMES get frame if we dropped it above, because if some filter above drop frame it will return mpi==NULL. So I can see how flag VFCAP_NOTIFY_DROPPED_FRAMES works but flag VFCAP_WANTS_DROPPED_FRAMES will work only if no filter above could drop frames. But if there is no filter above which could drop frames then that flag has no sence - filter with VFCAP_WANTS_DROPPED_FRAMES will _always_ get _all_ frames already. :) So, example: we have demuxer->filter1->filter2->muxer chain. Filter1 may drop frames, filter2 has both flags VFCAP_WANTS_DROPPED_FRAMES and VFCAP_NOTIFY_DROPPED_FRAMES. Then we have next choises: 1) muxer wants to drop that frame: drop==1. Filter2 may get the frame or NULL (if filter1 has VFCAP_NOTIFY_DROPPED_FRAMES too). 2) muxer doesn't force to drop that frame: drop==0. Filter1 wants that frame be dropped. Filter2 will get NULL as mpi. 3) drop==0, filter1 doesn't drop the frame. Filter2 will get the frame. So as you can see, VFCAP_WANTS_DROPPED_FRAMES has no effect at all. May be you have to modify vf.c:vf_process_image() function and get that behavior you mentioned above? Moreover, no filter with VFCAP_NOTIFY_DROPPED_FRAMES will be notified about dropped frames when drop==1 and no VFCAP_WANTS_DROPPED_FRAMES for that filter or below, see your source. With best wishes. Andriy. From dalias at aerifal.cx Fri Jul 25 18:45:45 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 25 Jul 2003 12:45:45 -0400 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <20030725100527.GA29650@lucky.net> References: <20030724155248.GA92967@lucky.net> <200307241645.h6OGjJ8x024431@mail.mplayerhq.hu> <20030725100527.GA29650@lucky.net> Message-ID: <20030725164545.GK253@brightrain.aerifal.cx> On Fri, Jul 25, 2003 at 01:05:27PM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Thursday, July 24 at 19:37) I've received something... > [.......] > >Differences in video filters: > >============================= > >By default, everything works the same way as in G1, except that put_image > >won't call next filter's put_image directly, but return the dmpi. > >So, instead of 'return vf_next_put_image(vf,dmpi);' you have to write > >'return dmpi;' now. And, isntead of 'return 0;' you write 'return NULL;'. > > >Additionally, filters also have a 'drop' parameter, to allow frame > >dropping at filters. By default you can ignore this flag, your put_image() > >won't be called when drop!=0. > > >Let's see the non-default case now: > >Your filters may set 2 special flags to control frame dropping: > > >// filter wants process_image() to be called with mpi=NULL for dropped frames > >#define VFCAP_NOTIFY_DROPPED_FRAMES 0x2000 > > >// filter wants to see all frames, even if we want to drop them... > >// (so you can't drop frame above this filter) > >#define VFCAP_WANTS_DROPPED_FRAMES 0x4000 > > >As you can see, the 'drop' flag has effect only with VFCAP_WANTS_DROPPED_FRAMES. > >These flags will allow filters to be notified about dropped frames, it's > >required for pattern-matching (like inverse telecine) filters and temporal > >postprocessing filters. > > Hmm, I've analyzed the sources and didn't get it at all. If we call > vf_process_image(vf_last,0) for bottom filter (vo or muxer) then any > filter could not get parameter drop as 1. If we call vf_process_image > with drop=1 (well, we are about to drop this frame) then again, we never > can let filter with VFCAP_WANTS_DROPPED_FRAMES get frame if we dropped it > above, because if some filter above drop frame it will return mpi==NULL. > So I can see how flag VFCAP_NOTIFY_DROPPED_FRAMES works but flag > VFCAP_WANTS_DROPPED_FRAMES will work only if no filter above could drop > frames. But if there is no filter above which could drop frames then that > flag has no sence - filter with VFCAP_WANTS_DROPPED_FRAMES will _always_ > get _all_ frames already. :) > > So, example: we have demuxer->filter1->filter2->muxer chain. Filter1 > may drop frames, filter2 has both flags VFCAP_WANTS_DROPPED_FRAMES and > VFCAP_NOTIFY_DROPPED_FRAMES. Then we have next choises: > > 1) muxer wants to drop that frame: drop==1. Filter2 may get the frame or > NULL (if filter1 has VFCAP_NOTIFY_DROPPED_FRAMES too). > 2) muxer doesn't force to drop that frame: drop==0. Filter1 wants that > frame be dropped. Filter2 will get NULL as mpi. > 3) drop==0, filter1 doesn't drop the frame. Filter2 will get the frame. > > So as you can see, VFCAP_WANTS_DROPPED_FRAMES has no effect at all. > May be you have to modify vf.c:vf_process_image() function and get that > behavior you mentioned above? > Moreover, no filter with VFCAP_NOTIFY_DROPPED_FRAMES will be notified > about dropped frames when drop==1 and no VFCAP_WANTS_DROPPED_FRAMES for > that filter or below, see your source. I don't know the exact answer to your question, but remember, the chain runs *backwards*!! It's not a simple one-filter-calles-the-next thing like in g1; the calling app has a complicated loop for calling the filters. So my first guess (without reading your question in detail) would be that Arpi is right. :) Rich From andrej at lucky.net Sat Jul 26 09:50:11 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 26 Jul 2003 10:50:11 +0300 Subject: [MPlayer-G2-dev] Re: Question for Arpi :) In-Reply-To: <20030725164545.GK253@brightrain.aerifal.cx> References: <20030724155248.GA92967@lucky.net> <200307241645.h6OGjJ8x024431@mail.mplayerhq.hu> <20030725100527.GA29650@lucky.net> <20030725164545.GK253@brightrain.aerifal.cx> Message-ID: <20030726075011.GA30792@lucky.net> Hi, D Richard Felker III! Sometime (on Friday, July 25 at 19:36) I've received something... >On Fri, Jul 25, 2003 at 01:05:27PM +0300, Andriy N. Gritsenko wrote: >> Hi, Arpi! >> >> Sometime (on Thursday, July 24 at 19:37) I've received something... >> [.......] >> >Differences in video filters: >> >============================= >> >By default, everything works the same way as in G1, except that put_image >> >won't call next filter's put_image directly, but return the dmpi. >> >So, instead of 'return vf_next_put_image(vf,dmpi);' you have to write >> >'return dmpi;' now. And, isntead of 'return 0;' you write 'return NULL;'. >> >> >Additionally, filters also have a 'drop' parameter, to allow frame >> >dropping at filters. By default you can ignore this flag, your put_image() >> >won't be called when drop!=0. >> >> >Let's see the non-default case now: >> >Your filters may set 2 special flags to control frame dropping: >> >> >// filter wants process_image() to be called with mpi=NULL for dropped frames >> >#define VFCAP_NOTIFY_DROPPED_FRAMES 0x2000 >> >> >// filter wants to see all frames, even if we want to drop them... >> >// (so you can't drop frame above this filter) >> >#define VFCAP_WANTS_DROPPED_FRAMES 0x4000 >> >> >As you can see, the 'drop' flag has effect only with VFCAP_WANTS_DROPPED_FRAMES. >> >These flags will allow filters to be notified about dropped frames, it's >> >required for pattern-matching (like inverse telecine) filters and temporal >> >postprocessing filters. >> >> Hmm, I've analyzed the sources and didn't get it at all. If we call >> vf_process_image(vf_last,0) for bottom filter (vo or muxer) then any >> filter could not get parameter drop as 1. If we call vf_process_image >> with drop=1 (well, we are about to drop this frame) then again, we never >> can let filter with VFCAP_WANTS_DROPPED_FRAMES get frame if we dropped it >> above, because if some filter above drop frame it will return mpi==NULL. >> So I can see how flag VFCAP_NOTIFY_DROPPED_FRAMES works but flag >> VFCAP_WANTS_DROPPED_FRAMES will work only if no filter above could drop >> frames. But if there is no filter above which could drop frames then that >> flag has no sence - filter with VFCAP_WANTS_DROPPED_FRAMES will _always_ >> get _all_ frames already. :) >> >> So, example: we have demuxer->filter1->filter2->muxer chain. Filter1 >> may drop frames, filter2 has both flags VFCAP_WANTS_DROPPED_FRAMES and >> VFCAP_NOTIFY_DROPPED_FRAMES. Then we have next choises: >> >> 1) muxer wants to drop that frame: drop==1. Filter2 may get the frame or >> NULL (if filter1 has VFCAP_NOTIFY_DROPPED_FRAMES too). >> 2) muxer doesn't force to drop that frame: drop==0. Filter1 wants that >> frame be dropped. Filter2 will get NULL as mpi. >> 3) drop==0, filter1 doesn't drop the frame. Filter2 will get the frame. >> >> So as you can see, VFCAP_WANTS_DROPPED_FRAMES has no effect at all. >> May be you have to modify vf.c:vf_process_image() function and get that >> behavior you mentioned above? >> Moreover, no filter with VFCAP_NOTIFY_DROPPED_FRAMES will be notified >> about dropped frames when drop==1 and no VFCAP_WANTS_DROPPED_FRAMES for >> that filter or below, see your source. >I don't know the exact answer to your question, but remember, the >chain runs *backwards*!! It's not a simple one-filter-calles-the-next >thing like in g1; the calling app has a complicated loop for calling >the filters. So my first guess (without reading your question in >detail) would be that Arpi is right. :) Thank you, but I already know that. :) Chain runs backwards until it get the frame, after that it runs forwards through all chain (see that function vf_process_image() in vf.c) - but some filter may drop the frame to NULL. Read my example above, please. If you still don't believe then create test filter and run it with gdb. :) With best wishes. Andriy. From arpi at thot.banki.hu Sun Jul 27 18:21:44 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 27 Jul 2003 18:21:44 +0200 Subject: [MPlayer-G2-dev] pre37 released Message-ID: <200307271621.h6RGLia4030936@mail.mplayerhq.hu> Hi, http://mplayerhq.hu/~arpi/g2/mplayer-G2-preview37.tar.gz pre37: - vf_madei: config support, blurring (noise removal) before motion detection - IPB codecs in AVI container resulting bad PTS order fixed - libmpeg2 crash at seek fixed (but no I frame / keyframe search yet) - mpeg demuxer: using ds packet for ES video, support for layer 1, 2 audio - mp3lib: layer-1 support (backport from main) - vo_fbdev.c, with v-synced triple buffering support - DOCS/video.txt A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu