From arpi at thot.banki.hu Wed May 7 16:58:41 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 7 May 2003 16:58:41 +0200 Subject: [MPlayer-G2-dev] teszt 4 Message-ID: <200305071458.h47EwfVN000481@mail.mplayerhq.hu> jdgsj From danchr at daimi.au.dk Wed May 7 20:43:20 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Wed, 7 May 2003 20:43:20 +0200 Subject: [MPlayer-G2-dev] Darwin port Message-ID: Attached below is a patch to make g2 pre20 compile on Darwin/Mac OS X. Everything seems to work quite well, except there's no working vo module. Here's a short description of what I did: - The WORDS_BIGENDIAN code had obviously never been compiled. Added a some missing casts as well as a missing macro. - Changed "$(AR) r" to "$(AR) sr" to avoid using ranlib. Does this work on other platforms as well? - The libvo2 test requires all sorts of odd flags and libraries to compile on Darwin. Rather than clogging the Makefile with them, I removed it from "all". - Made "make clean" recursive. - Updated timer-macosx. - Added the required libraries to each target in the main Makefile. I wish there was some way to simplify this.. I ran into one problem which I couldn't figure out how to solve properly. It seems like gCpuCaps symbol isn't included in libosdep.a, so I had to explicitly link osdep/cpudetect.o into test-codecs. I tried everything I could think of, and I still don't understand why it doesn't work... > # FIXME: for some odd reason the gCpuCaps symbol will be undefined on > Darwin > # unless osdep/cpudetect.o is explicitely linked > $(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs > $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) > $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) > $(VO_LIBS) $(I18NLIBS) -lm Other than that, with these changes, mplayer-g2 should compile fine assuming the configure script from mplayer is used. BTW, when you write the interface for the actual library, please consider adding a simple way to extract metadata from a file. There really aren't any utilities out there which can read metadata from most media files. Also, if anyone is considering porting vo_gl from mplayer, could you perhaps try to isolate the X11 dependencies in the same time? I tried to make a mac native vo based off it, but it was too difficult for me. - Dan Christiansen -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-darwin.diff Type: application/octet-stream Size: 13560 bytes Desc: not available URL: From arpi at thot.banki.hu Wed May 7 23:29:33 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 7 May 2003 23:29:33 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: Message-ID: <200305072129.h47LTXpT010981@mail.mplayerhq.hu> Hi, > Attached below is a patch to make g2 pre20 compile on Darwin/Mac OS X. thanks > Everything seems to work quite well, except there's no working vo > module. Here's a short description of what I did: hmm. no Xv on darwin? > - The WORDS_BIGENDIAN code had obviously never been compiled. Added a > some missing casts as well as a missing macro. > - Changed "$(AR) r" to "$(AR) sr" to avoid using ranlib. Does this work > on other platforms as well? > - The libvo2 test requires all sorts of odd flags and libraries to > compile on Darwin. Rather than clogging the Makefile with them, I > removed it from "all". > - Made "make clean" recursive. > - Updated timer-macosx. > - Added the required libraries to each target in the main Makefile. I these look ok > wish there was some way to simplify this.. designing a new configure/make system is on the TODO. i have some ideas, but no implementation / final design yet. > I ran into one problem which I couldn't figure out how to solve > properly. It seems like gCpuCaps symbol isn't included in libosdep.a, > so I had to explicitly link osdep/cpudetect.o into test-codecs. I tried > everything I could think of, and I still don't understand why it > doesn't work... I guess it's linking order. You have to move libosdep to the end of list of libs, but probably before mp_msg.o because depends on that. > > # FIXME: for some odd reason the gCpuCaps symbol will be undefined on > > Darwin > > # unless osdep/cpudetect.o is explicitely linked > > $(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs > > $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) > > $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) > > $(VO_LIBS) $(I18NLIBS) -lm > > Other than that, with these changes, mplayer-g2 should compile fine > assuming the configure script from mplayer is used. great! > BTW, when you write the interface for the actual library, please > consider adding a simple way to extract metadata from a file. There > really aren't any utilities out there which can read metadata from most > media files. It's already possible, at least demuxers export the metadata. See test-stream for example. > Also, if anyone is considering porting vo_gl from mplayer, could you > perhaps try to isolate the X11 dependencies in the same time? I tried > to make a mac native vo based off it, but it was too difficult for me. Hmm. It would be good for win32 port too. The problem is that big part of the GL setup is GLX (or WGL on win32, dunno the Mac case) function calls. Maybe we need 3 implementations of this init code, one for each major OS. And maybe a 4th for FBDRI on linux... And a 5th for gtk-GL and a 6th for SDL-GL :) Maybe it's worth to completely (in file level) separate GL and OS-dependnet parts. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From danchr at daimi.au.dk Thu May 8 01:01:27 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Thu, 8 May 2003 01:01:27 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305072129.h47LTXpT010981@mail.mplayerhq.hu> Message-ID: On Wednesday, May 7, 2003, at 11:29 PM, Arpi wrote: > Hi, > >> Attached below is a patch to make g2 pre20 compile on Darwin/Mac OS X. > > thanks > >> Everything seems to work quite well, except there's no working vo >> module. Here's a short description of what I did: > > hmm. no Xv on darwin? Nope. At least not in standard XFree86. In main MPlayer, the status of the VO's are: xv, sdl, aa: working gl: buggy gl2, xover, xv: non-functional The rest aren't compiled in. >> - The WORDS_BIGENDIAN code had obviously never been compiled. Added a >> some missing casts as well as a missing macro. Forgot to say thanks for writing those parts in the first place. A lot of x86 developers are totally oblivious to the fact that most other CPUs are big endian :) >> - Changed "$(AR) r" to "$(AR) sr" to avoid using ranlib. Does this >> work >> on other platforms as well? >> - The libvo2 test requires all sorts of odd flags and libraries to >> compile on Darwin. Rather than clogging the Makefile with them, I >> removed it from "all". >> - Made "make clean" recursive. >> - Updated timer-macosx. >> - Added the required libraries to each target in the main Makefile. I > > these look ok > >> wish there was some way to simplify this.. > > designing a new configure/make system is on the TODO. i have some > ideas, but > no implementation / final design yet. > >> I ran into one problem which I couldn't figure out how to solve >> properly. It seems like gCpuCaps symbol isn't included in libosdep.a, >> so I had to explicitly link osdep/cpudetect.o into test-codecs. I >> tried >> everything I could think of, and I still don't understand why it >> doesn't work... > > I guess it's linking order. You have to move libosdep to the end of > list of > libs, but probably before mp_msg.o because depends on that. I tried putting it there twice, in the beginning and the end; same result. I suspect that either my setup is broken, some option somewhere is wrong, or a bug is being exposed. >>> # FIXME: for some odd reason the gCpuCaps symbol will be undefined on >>> Darwin >>> # unless osdep/cpudetect.o is explicitely linked >>> $(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs >>> $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) >>> $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) >>> $(VO_LIBS) $(I18NLIBS) -lm >> >> Other than that, with these changes, mplayer-g2 should compile fine >> assuming the configure script from mplayer is used. > > great! > >> BTW, when you write the interface for the actual library, please >> consider adding a simple way to extract metadata from a file. There >> really aren't any utilities out there which can read metadata from >> most >> media files. > > It's already possible, at least demuxers export the metadata. > See test-stream for example. I'll take a look later :) >> Also, if anyone is considering porting vo_gl from mplayer, could you >> perhaps try to isolate the X11 dependencies in the same time? I tried >> to make a mac native vo based off it, but it was too difficult for me. > > Hmm. It would be good for win32 port too. > The problem is that big part of the GL setup is GLX (or WGL on win32, > dunno > the Mac case) function calls. Maybe we need 3 implementations of this > init > code, one for each major OS. And maybe a 4th for FBDRI on linux... > And a 5th for gtk-GL and a 6th for SDL-GL :) > Maybe it's worth to completely (in file level) separate GL and > OS-dependnet parts. How about doing it sort of like the X11 stuff is done in g1 with a gl_common? It would probably be best to isolate the individual parts. The way I understand it, it's basically creating the GLContext and registering event listeners that differs. Given a context, the OpenGL code should be the same. I have a feeling that SDL is slowing things down horribly on Mac OS X; I ought to be able to play just about any DivX on my 400MHz, but most drop frames in MPlayer. I'd very much like to help out writing a native video out module. Considering different implementations: You could even do two versions on Mac OS X - one using the C API (Carbon) and another one using the Objective-C API (Cocoa). Personally, I'd go for the ObjC version. With the new, library based approach, a vo should simply return a pointer to/instance of a GUI element to which it renders, right? - Dan From arpi at thot.banki.hu Thu May 8 01:41:23 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 8 May 2003 01:41:23 +0200 Subject: [MPlayer-G2-dev] mpeg container's timing (PTS values) Message-ID: <200305072341.h47NfN2j001374@mail.mplayerhq.hu> Hi, I've "developed" a new a-v sync engine in g2 code, which produces A-V: 0.0000 for most mpeg1/vob streams i have. The video part is relative easy, but a bit tricky: when a PS packet has a PTS timestamp, that timestamp belongs to the next complete frame. (not to the one which ends in that packet!) The audio is however very tricky. The old (used in mplayer-g1) audio pts calculation method assumed, that the timestamps received from the demuxer belongs to the first byte of that packet. So, after decoded an audio frame/block, it increased PTS by the compressed frame size divided by compressed byterate. It is very inaccurate for mpeg. Now i've found why: in mpeg containers, the audio timestamps behave like the video: they belong to the _next_ complete frame/block. As AC3 frames are big, they usually go accross multiple packets, this error may be big. But fixing this, I got stable A-V but non-zero ct (correction total). After experimencng with several streams, i've found that ct: value is the time length of an audio frame. Strange, isn't it? It means, that the PTS doesn't even belongs to the next audio frame, but to the next after the next. Or in other words: it's the timestamp for the last byte/sample of the next frame, instead of the first one: v-- the PTS belongs to the PTS end of f2 (or start of f3) v frames: [.....f1......][......f2......][.....f3......] packets: | p1 | p2 | p3 | p4 | p5 | ^PTS^ ^- the PTS is coded in p2's header Using this logic I got <5ms ct: times for all mpeg streams! But quoting the mpeg-system.pdf: " In the T-STD in figure 2-6 on page 11 the display of a video presentation unit (a picture) occurs instantaneously at its presentation time, tp n (k). In the T_STD the output of an audio presentation unit starts at its presentation time, tp n (k), when the decoder instantaneously presents the first sample. Subsequent samples in the presentation unit are presented in sequence at the audio sampling rate. " It suggests that PTS if the beginning of that audio block, not the end! Do anyone have accurate info about the meaning/calculation of audio PTS for mpeg container? A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Thu May 8 01:51:48 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 8 May 2003 01:51:48 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: Message-ID: <200305072351.h47Npmos010152@mail.mplayerhq.hu> Hi, > >> - The WORDS_BIGENDIAN code had obviously never been compiled. Added a > >> some missing casts as well as a missing macro. > > Forgot to say thanks for writing those parts in the first place. A lot > of x86 developers are totally oblivious to the fact that most other > CPUs are big endian :) Most of that lowlevel code comes from mp 0_90 or main, so they are not new. > >> I ran into one problem which I couldn't figure out how to solve > >> properly. It seems like gCpuCaps symbol isn't included in libosdep.a, > >> so I had to explicitly link osdep/cpudetect.o into test-codecs. I > >> tried > >> everything I could think of, and I still don't understand why it > >> doesn't work... > > > > I guess it's linking order. You have to move libosdep to the end of > > list of > > libs, but probably before mp_msg.o because depends on that. > > I tried putting it there twice, in the beginning and the end; same > result. I suspect that either my setup is broken, some option somewhere > is wrong, or a bug is being exposed. maybe a linker bug, sadly :( > >> perhaps try to isolate the X11 dependencies in the same time? I tried > >> to make a mac native vo based off it, but it was too difficult for me. > > > > Hmm. It would be good for win32 port too. > > The problem is that big part of the GL setup is GLX (or WGL on win32, > > dunno > > the Mac case) function calls. Maybe we need 3 implementations of this > > init > > code, one for each major OS. And maybe a 4th for FBDRI on linux... > > And a 5th for gtk-GL and a 6th for SDL-GL :) > > Maybe it's worth to completely (in file level) separate GL and > > OS-dependnet parts. > > How about doing it sort of like the X11 stuff is done in g1 with a > gl_common? It would probably be best to isolate the individual parts. > The way I understand it, it's basically creating the GLContext and > registering event listeners that differs. Given a context, the OpenGL yes, good idea. > code should be the same. I have a feeling that SDL is slowing things > down horribly on Mac OS X; I ought to be able to play just about any > DivX on my 400MHz, but most drop frames in MPlayer. I'd very much like > to help out writing a native video out module. feel free to do. i've simplified the vo API to make it even more easier to write new native vo modules instead of hacks like SDL or GGI. > Considering different implementations: You could even do two versions > on Mac OS X - one using the C API (Carbon) and another one using the > Objective-C API (Cocoa). Personally, I'd go for the ObjC version. > > With the new, library based approach, a vo should simply return a > pointer to/instance of a GUI element to which it renders, right? Yes. You can either export your buffers as-is (as pointers and bytes-per-line (aka. stride) values), in this case all teh rendering will be handled by vf_vo2.c Or if your device doesn't have such buffers (special cases, when the driver have functions to blit data, but you have no direct access) then you can implement draw_slice() (just like in mplayer g1) to blit parts of the image. Hmm, just thinking about it a bit, it may be possible that some evil devices/drivers doesn't even supports blitting by slices, just whole images. So i have to re-add the VFCAP_ACCEPT_STRIDE for this purpose. Ugh, maybe even VFCAP_ACCEPT_STRIDE is still needed? I think it's time to write libvo2.txt A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From vektor at dumbterm.net Thu May 8 01:20:43 2003 From: vektor at dumbterm.net (Billy Biggs) Date: Wed, 7 May 2003 18:20:43 -0500 Subject: [MPlayer-G2-dev] mpeg container's timing (PTS values) In-Reply-To: <200305072341.h47NfN2j001374@mail.mplayerhq.hu> References: <200305072341.h47NfN2j001374@mail.mplayerhq.hu> Message-ID: <20030507232043.GV14404@dumbterm.net> Arpi (arpi at thot.banki.hu): > The video part is relative easy, but a bit tricky: when a PS packet > has a PTS timestamp, that timestamp belongs to the next complete > frame. (not to the one which ends in that packet!) Doesn't it belong to the video frame which starts in that packet? > The audio is however very tricky. I remember it being a total bitch. > It is very inaccurate for mpeg. Now i've found why: in mpeg > containers, the audio timestamps behave like the video: they belong to > the _next_ complete frame/block. I don't think this is exactly correct. > After experimencng with several streams, i've found that ct: value is > the time length of an audio frame. Strange, isn't it? I think there is a more logical explination. > Do anyone have accurate info about the meaning/calculation of audio > PTS for mpeg container? It's been a while, but here is a comment I wrote in movietime: /** * Interesting tidbit. The PTS value in an A/52 audio frame * is for the audio frame which starts after the pointer * value (bytes p[2] and p[3] of the 4-byte header, byte * p[1] is the number of frames in the pack). So, I need to * pass this into the A/52 parse code so it can tag the new * PTS at the correct position. */ Basically, each pack can contain multiple audio frames, and the header tells you which one the PTS belongs to. It's not necessarily the first one. I can go through my code some more, but when I wrote all this code in movietime walken and I had a ton of conversations on IRC, and I was just shocked at how hard it was to get all the sync to line up perfectly such that I wasn't like dropping audio or resyncing my video all the time. Once I had it done though, everything lined up _perfect_. I'm anxious to get into the G2 code, and when I'll do I'll probably go through it alongside my movietime code and post any discrepancies I find. If it would help, I can go through my code some more and refresh my memory. -Billy From arpi at thot.banki.hu Thu May 8 02:14:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 8 May 2003 02:14:05 +0200 Subject: [MPlayer-G2-dev] mpeg container's timing (PTS values) In-Reply-To: <20030507232043.GV14404@dumbterm.net> Message-ID: <200305080014.h480E5gw031983@mail.mplayerhq.hu> Hi, > Arpi (arpi at thot.banki.hu): > > > The video part is relative easy, but a bit tricky: when a PS packet > > has a PTS timestamp, that timestamp belongs to the next complete > > frame. (not to the one which ends in that packet!) > > Doesn't it belong to the video frame which starts in that packet? yes, we say the same but with different words :) (next complete frame == the frame starts in this packet) > > The audio is however very tricky. > > I remember it being a total bitch. :) > > It is very inaccurate for mpeg. Now i've found why: in mpeg > > containers, the audio timestamps behave like the video: they belong to > > the _next_ complete frame/block. > > I don't think this is exactly correct. neither me, this is why sending that mail :) > > After experimencng with several streams, i've found that ct: value is > > the time length of an audio frame. Strange, isn't it? > > I think there is a more logical explination. I hope so. > > Do anyone have accurate info about the meaning/calculation of audio > > PTS for mpeg container? > > It's been a while, but here is a comment I wrote in movietime: > > /** > * Interesting tidbit. The PTS value in an A/52 audio frame > * is for the audio frame which starts after the pointer > * value (bytes p[2] and p[3] of the 4-byte header, byte > * p[1] is the number of frames in the pack). So, I need to > * pass this into the A/52 parse code so it can tag the new > * PTS at the correct position. > */ Sounds interesting. > Basically, each pack can contain multiple audio frames, and the header > tells you which one the PTS belongs to. It's not necessarily the first > one. I need samples, where it isn't (always) the first one :) > If it would help, I can go through my code some more and refresh my > memory. would be great! A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Thu May 8 09:43:16 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 8 May 2003 03:43:16 -0400 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305072351.h47Npmos010152@mail.mplayerhq.hu> References: <200305072351.h47Npmos010152@mail.mplayerhq.hu> Message-ID: <20030508074316.GX23552@brightrain.aerifal.cx> On Thu, May 08, 2003 at 01:51:48AM +0200, Arpi wrote: > Yes. You can either export your buffers as-is (as pointers and > bytes-per-line (aka. stride) values), in this case all teh rendering > will be handled by vf_vo2.c > Or if your device doesn't have such buffers (special cases, when the > driver have functions to blit data, but you have no direct access) > then you can implement draw_slice() (just like in mplayer g1) to blit > parts of the image. Arpi, I'm trying to decide how to best implement G200 support in G2. You're prolly already aware, but just to remind you, G200's "YV12" mode gives you 4:2:0 semi-planar, with Y in a plane by itself, but U and V packed together in a w*(h/2) byte buffer. I see a couple possible ways of handling this: 1) Same as G1: don't allow DR, but use draw_slice instead, and interleave slices as they're drawn. Easy, but slow when the last filter has to copy to a temp buffer rather than DR. 2) Export DR buffers, but allocate fake U/V planes in system memory. Let the codec/filters DR into real Y and fake U/V planes, then interleave U/V when put_image is called. This method is nice when the codec/filter can DR, but for non-B frames with IP[B] codecs, it will result in extra senseless copying from the readable buffer in system memory to the fake U/V buffers, then interleaving into the real U/V buffer. 3) Have vo_mga report that YV12 is NOT available for G200, and define a new image format for this 'semi-planar' mode. Then vf_scale can get automatically inserted, and use a super-fast interleave-only converter without scaling. With the appropriate enhancements (which should be there for planar 4:1:1/4:1:0 modes anyway), vf_scale could allow direct rendering straight through it for the Y plane, but use its own buffers for U/V which need to be converted. It could do a similar trick for slice rendering through scale, and likewise by setting up an EXPORT type image when not using DR or slices. Personally, I think option (3) is the cleanest solution, if it can be done without a performance hit. That way we don't clutter up vf_vo2.c or vo_mga.c with all sorts of hacks. Maybe you have another better idea, though? Rich From ivan at cacad.com Thu May 8 13:22:51 2003 From: ivan at cacad.com (Ivan Kalvachev) Date: Thu, 8 May 2003 14:22:51 +0300 (EEST) Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <20030508074316.GX23552@brightrain.aerifal.cx> References: <200305072351.h47Npmos010152@mail.mplayerhq.hu> <20030508074316.GX23552@brightrain.aerifal.cx> Message-ID: <1044.212.116.158.147.1052392971.squirrel@mail.cacad.com> Would this help I don't have the g200 spec, but is that mode like that: YYYYYYYYY UUUUVVVV Y_width=width Y_slice=width*2 Y_offset=0; U_width=width/2; U_slice=width*2; U_offset=width; //start after Y line V_width=width/2; V_slice=width*2; V_offset=width+(width/2);//start after Y and U line Or it have packed UV in the same word (short)- YYYYYYYY UVUVUVUV Best Regards Ivan D Richard Felker III said: > On Thu, May 08, 2003 at 01:51:48AM +0200, Arpi wrote: >> Yes. You can either export your buffers as-is (as pointers and >> bytes-per-line (aka. stride) values), in this case all teh rendering >> will be handled by vf_vo2.c >> Or if your device doesn't have such buffers (special cases, when the >> driver have functions to blit data, but you have no direct access) >> then you can implement draw_slice() (just like in mplayer g1) to blit >> parts of the image. > > Arpi, I'm trying to decide how to best implement G200 support in G2. > You're prolly already aware, but just to remind you, G200's "YV12" mode > gives you 4:2:0 semi-planar, with Y in a plane by itself, but U and V > packed together in a w*(h/2) byte buffer. I see a couple > possible ways of handling this: > > 1) Same as G1: don't allow DR, but use draw_slice instead, and > interleave slices as they're drawn. Easy, but slow when the last > filter has to copy to a temp buffer rather than DR. > > 2) Export DR buffers, but allocate fake U/V planes in system memory. > Let the codec/filters DR into real Y and fake U/V planes, then > interleave U/V when put_image is called. This method is nice when the > codec/filter can DR, but for non-B frames with IP[B] codecs, it will > result in extra senseless copying from the readable buffer in system > memory to the fake U/V buffers, then interleaving into the real U/V > buffer. > > 3) Have vo_mga report that YV12 is NOT available for G200, and define > a new image format for this 'semi-planar' mode. Then vf_scale can get > automatically inserted, and use a super-fast interleave-only > converter without scaling. With the appropriate enhancements (which > should be there for planar 4:1:1/4:1:0 modes anyway), vf_scale > could allow direct rendering straight through it for the Y plane, but > use its own buffers for U/V which need to be converted. It > could do a similar trick for slice rendering through scale, and > likewise by setting up an EXPORT type image when not using DR or > slices. > > Personally, I think option (3) is the cleanest solution, if it can be > done without a performance hit. That way we don't clutter up vf_vo2.c or > vo_mga.c with all sorts of hacks. Maybe you have another better idea, > though? > > Rich > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From andrej at lucky.net Thu May 8 14:49:59 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 8 May 2003 15:49:59 +0300 Subject: [MPlayer-G2-dev] mp-G2: play_frame() Message-ID: <20030508124959.GA60402@lucky.net> Hi! It's only concept, not really workink subroutine. Sorry, I don't have enough time now to do all researches on G2 streaming but someone here are working on that problem too so I think it will be very useful to join our thoughts. :) Yesterday's evening I've spent some time to write play_frame() a bit. See it in attachment. It allows multiple play contexts and multiple audio or video streams, has no static vars, and is independent of other parts of G2 as much as possible. Some comments: 1) I didn't do some audio/video specific parts since I didn't get yet how to pull audio and video frames from chain, sorry. 2) I've changed skiplimit variable to float. Some time ago I wanted to run mplayer with -skiplimit 0.2 since it may allow me significally decrease number of dropped valuable frames despite of little A-V desync. 3) Many applications may have more than one play context (for example, player with multiscreen ability, video editor, streaming server, etc.) so have static variables (such as sh_audio or video_out) isn't good solution. So I've implemented struct play_context. :) 4) Since it's allowed to have more than one video or audio stream, each stream has to have his own sync mechanism, it dissalows to have static vars so I've moved statics for that into sh_audio and sh_video (may be, we will implement some struct chain_t instead of sh_audio_t/sh_video_t for unification later?). These variables are: double skipcnt; // counter how many skips are possible now double pts; // presentation timestamp of last gotten frame double corr; // correction time for this stream chain int skipped; // number of skipped (dropped) non-duplicate frames int dupped; // number of inserted duplicate frames 5) play_frame() will work in any application (player, encoder, etc.) with no changes and hacks. :) 6) Input chain (from source stream to play_frame subroutine) have not push frame to output chain (audio/video out or muxer) directly but play_frame() will do that instead. It's because only play_frame() may decide if frame has to be dropped or duplicated. Anyway each input chain must have appropriate output chain. :) Any questions/comments are welcomed but don't ask me wrote all missed stuff - I have no enough time for researches on G2 streams now and they are too complex to solve it without knowing the details. Sorry for that. With best wishes. Andriy. From andrej at lucky.net Thu May 8 15:37:25 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 8 May 2003 16:37:25 +0300 Subject: [MPlayer-G2-dev] Re: mp-G2: play_frame() In-Reply-To: <20030508124959.GA60402@lucky.net> References: <20030508124959.GA60402@lucky.net> Message-ID: <20030508133725.GC20204@lucky.net> Hi! OOPS, sorry, I've forgotten to attach the file. :( It's only concept, not really workink subroutine. Sorry, I don't have enough time now to do all researches on G2 streaming but someone here are working on that problem too so I think it will be very useful to join our thoughts. :) Yesterday's evening I've spent some time to write play_frame() a bit. See it in attachment. It allows multiple play contexts and multiple audio or video streams, has no static vars, and is independent of other parts of G2 as much as possible. Some comments: 1) I didn't do some audio/video specific parts since I didn't get yet how to pull audio and video frames from chain, sorry. 2) I've changed skiplimit variable to float. Some time ago I wanted to run mplayer with -skiplimit 0.2 since it may allow me significally decrease number of dropped valuable frames despite of little A-V desync. 3) Many applications may have more than one play context (for example, player with multiscreen ability, video editor, streaming server, etc.) so have static variables (such as sh_audio or video_out) isn't good solution. So I've implemented struct play_context. :) 4) Since it's allowed to have more than one video or audio stream, each stream has to have his own sync mechanism, it dissalows to have static vars so I've moved statics for that into sh_audio and sh_video (may be, we will implement some struct chain_t instead of sh_audio_t/sh_video_t for unification later?). These variables are: double skipcnt; // counter how many skips are possible now double pts; // presentation timestamp of last gotten frame double corr; // correction time for this stream chain int skipped; // number of skipped (dropped) non-duplicate frames int dupped; // number of inserted duplicate frames 5) play_frame() will work in any application (player, encoder, etc.) with no changes and hacks. :) 6) Input chain (from source stream to play_frame subroutine) have not push frame to output chain (audio/video out or muxer) directly but play_frame() will do that instead. It's because only play_frame() may decide if frame has to be dropped or duplicated. Anyway each input chain must have appropriate output chain. :) Any questions/comments are welcomed but don't ask me wrote all missed stuff - I have no enough time for researches on G2 streams now and they are too complex to solve it without knowing the details. Sorry for that. With best wishes. Andriy. -------------- next part -------------- #include "ctl.h" float skiplimit = -1; // config variable! typedef struct { sh_audio_t **sh_audio; ao_functions_t **audio_out; int audio_streams; // chains sh_audio and audio_out sh_video_t **sh_video; vo_instance_t **video_out; int video_streams; // chains sh_video and video_out double pts; // presentation timestamp at end of last played frame } play_context; /* play the frame at timestamp pts with frame duration duration */ int play_frame (play_context *ctx, double pts, double duration) { int i; //double seek = check_control(); //pts += seek; // play all audio for (i = 0; i < ctx->audio_streams; i++) { sh_audio_t *sh_a = ctx->sh_audio[i]; ao_functions_t *ao = ctx->audio_out[i]; if (sh_a->ds->eof) continue; // input ended // since it multistreamed now, pts must be added into sh_audio_t! do { // do seek if pts and ctx->pts are too different (may be only in player) //... // decode audio //... // play audio //... // update sh_a->pts //... } while (sh_a->pts + sh_a->corr < pts+duration); } // play all video for (i = 0; i < ctx->video_streams; i++) { sh_video_t *sh_v = ctx->sh_video[i]; vo_instance_t *vo = ctx->video_out[i]; static struct mp_image_s *mpi = NULL; if (sh_v->ds->eof) continue; // input ended // do seek if pts and ctx->pts are too different (may be only in player) //... // check if we jumped past current frame if (sh_v->pts + sh_v->corr < pts) { // we have to skip that frame if (skiplimit > 0) sh_v->skipcnt += skiplimit; while (skiplimit < 0 || sh_v->skipcnt >= 1) { // skip frame(s) if possible // decode videoframe (just for dropping now) sh_v->vfilter->get_image(sh_v->vfilter, mpi); if (mpi) { // if it isn't duplicate/dropped sh_v->skipcnt -= 1.0; sh_v->skipped += 1; } // videoframe skipped! // update sh_v->pts //... // checks for success if (sh_v->ds->eof || sh_v->pts + sh_v->corr >= pts+duration) break; } continue; // next video } // we can process that frame if (skiplimit > 0) sh_v->skipcnt -= skiplimit; // duplicate current frame if it's need and possible if ((skiplimit < 0 || sh_v->skipcnt <= -1) && sh_v->pts + sh_v->corr >= pts+duration) { sh_v->dupped += 1; // push duplicate frame with duration duration //... sh_v->corr += duration; sh_v->skipcnt += 1.0; } // process videoframe(s) while (sh_v->pts + sh_v->corr < pts+duration) { double frametime; // frame duration // decode videoframe (for play, full process) sh_v->vfilter->get_image(sh_v->vfilter, mpi); // get frame duration //... if (!mpi && sh_v->corr > 0) { // if it is duplicate/dropped // update sh_v->pts and drop it if possible sh_v->pts += frametime; sh_v->corr -= frametime; continue; } if (!mpi) sh_v->dupped += 1; // play videoframe (even duplicate one) //... sh_v->pts += frametime; break; // we cannot play more than one frame once } } // update ctx->pts ctx->pts = pts + duration; } From lgb at lgb.hu Thu May 8 15:49:49 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Thu, 8 May 2003 15:49:49 +0200 Subject: [MPlayer-G2-dev] None Message-ID: <200305081424.h48EOnUG012683@mail.mplayerhq.hu> " Subject: G2 CLI/GUI Message-ID: <20030508134949.GE26745 at vega.digitel2002.hu> Reply-To: lgb at lgb.hu Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: vega Linux 2.4.20 i686 User-Agent: Mutt/1.5.4i Hi! As far as I could see, the main problem with the current GUI is lacking features which eg CLI has. This is because of the fact that MPlayer is evolving fast, and it's very hard to follow it with the GUI and likes. I can see THREE interfaces now which can controll G1: * command line interface * OSD menu (though not for ALTERING settings as far as I checked it last) * "official" GUI mainly by .so It's very NICE to have seperated structure for G2 eg having some "core" mplayer which is like a separated library which can be used by several UIs. But of course it would be nice to have some "official" GUI for G2 even it it means that it's the same level of integration than any other G2 GUI project (currently with G1 it's not true, "official" GUI is integrated into the source, while others trying to use the slave mode of mplayer). I thing the best solution for G2 would be a _common_ (but separated from G2 core of course!) structure describes various options, their meanings, their dependencies to other options etc, and this (maybe compilacted) structure can be used by: * command line interface [even for displaying help!] * OSD menus * GTK GUI menus This would allow to make a SINGLE modoification and each of UIs supports this description "language" (it can be XML, but even some C coded linked lists of complex structures, etc) can support ALL of the features implemented, without the need to code into GUI, to code into OSD menu etc etc etc separatly, which is slow process, it's wase of time and even it introduces code redundancy ... - G?bor (larta'H) From lgb at lgb.hu Thu May 8 15:51:19 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Thu, 8 May 2003 15:51:19 +0200 Subject: [MPlayer-G2-dev] G2 CLI/GUI Message-ID: <20030508135119.GF26745@vega.digitel2002.hu> Sorry, my brand new MUA experiments may insert a '\' into the address field of the mail so I dunno it will be processed by MTAs ;-) So here again: ----- Forwarded message from G?bor L?n?rt ----- Date: Thu, 8 May 2003 15:49:49 +0200 From: G?bor L?n?rt Subject: G2 CLI/GUI To: mplayer-g2-dev at mplayerhq.hu\ Hi! As far as I could see, the main problem with the current GUI is lacking features which eg CLI has. This is because of the fact that MPlayer is evolving fast, and it's very hard to follow it with the GUI and likes. I can see THREE interfaces now which can controll G1: * command line interface * OSD menu (though not for ALTERING settings as far as I checked it last) * "official" GUI mainly by .so It's very NICE to have seperated structure for G2 eg having some "core" mplayer which is like a separated library which can be used by several UIs. But of course it would be nice to have some "official" GUI for G2 even it it means that it's the same level of integration than any other G2 GUI project (currently with G1 it's not true, "official" GUI is integrated into the source, while others trying to use the slave mode of mplayer). I thing the best solution for G2 would be a _common_ (but separated from G2 core of course!) structure describes various options, their meanings, their dependencies to other options etc, and this (maybe compilacted) structure can be used by: * command line interface [even for displaying help!] * OSD menus * GTK GUI menus This would allow to make a SINGLE modoification and each of UIs supports this description "language" (it can be XML, but even some C coded linked lists of complex structures, etc) can support ALL of the features implemented, without the need to code into GUI, to code into OSD menu etc etc etc separatly, which is slow process, it's wase of time and even it introduces code redundancy ... - G?bor (larta'H) ----- End forwarded message ----- -- - G?bor (larta'H) From andrej at lucky.net Thu May 8 16:35:29 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 8 May 2003 17:35:29 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030508135119.GF26745@vega.digitel2002.hu> References: <20030508135119.GF26745@vega.digitel2002.hu> Message-ID: <20030508143529.GD20204@lucky.net> Hi, G?bor L?n?rt! Sometime (on Thursday, May 8 at 16:52) I've received something... >I thing the best solution for G2 would be a _common_ (but separated from G2 >core of course!) structure describes various options, their meanings, their >dependencies to other options etc, and this (maybe compilacted) structure >can be used by: > * command line interface [even for displaying help!] > * OSD menus > * GTK GUI menus >This would allow to make a SINGLE modoification and each of UIs supports >this description "language" (it can be XML, but even some C coded linked >lists of complex structures, etc) can support ALL of the features implemented, >without the need to code into GUI, to code into OSD menu etc etc etc separatly, >which is slow process, it's wase of time and even it introduces code redundancy ... It was the main goal of my impact info G1 m_config.* two months ago. Since that time I've learned very much about these things and I'm working now on new implementation of it, for G2 since that G2 is much better fit in this concept. Main goals - most of process have to be hidden inside of parser, many parsers (not only mentioned by you) are possible, etc. Just wait it, please. When ready, I'll post it here and we will do it the best together. :) BTW, I don't like to sink in argues until it ready so I'll listen any ideas/demands/wishes but I'll don't tell you any details yet, sorry. With best wishes. Andriy. From dalias at aerifal.cx Thu May 8 16:51:49 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 8 May 2003 10:51:49 -0400 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <1044.212.116.158.147.1052392971.squirrel@mail.cacad.com> References: <200305072351.h47Npmos010152@mail.mplayerhq.hu> <20030508074316.GX23552@brightrain.aerifal.cx> <1044.212.116.158.147.1052392971.squirrel@mail.cacad.com> Message-ID: <20030508145149.GA23552@brightrain.aerifal.cx> On Thu, May 08, 2003 at 02:22:51PM +0300, Ivan Kalvachev wrote: > Would this help > I don't have the g200 spec, but is that mode like that: > > YYYYYYYYY > UUUUVVVV > > > Y_width=width > Y_slice=width*2 > Y_offset=0; > > U_width=width/2; > U_slice=width*2; > U_offset=width; //start after Y line > > V_width=width/2; > V_slice=width*2; > V_offset=width+(width/2);//start after Y and U line > > > Or it have packed UV in the same word (short)- > YYYYYYYY > UVUVUVUV Packed like this of course. If it were the former, all you'd have to do is play with strides. Rich From arpi at thot.banki.hu Fri May 9 01:22:46 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 9 May 2003 01:22:46 +0200 Subject: [MPlayer-G2-dev] a-v sync again Message-ID: <200305082322.h48NMkZp011604@mail.mplayerhq.hu> Hi, I've introduced pts_bytes in dp (demux_packet struct), as the initializer value for ds->pts_bytes, it solved vob's lpcm/ac3 pts delay problems. Thanks to Vektor for tips :) Anyway mpeg audio is still inaccurate, unless I delay PTS to the next compelte audio header. And PTS is still for teh end of frame, not the start. I think i can't avoid introducing some flags into ds struct, describing the timing/PTS behaviour for teh given container/stream format. It could solve such problems for long period. (but gives some confitions which means more testing and less generic code :(() Btw now that PTS calculation is abouut 100 times more precise, than in g1, a new problem raised: waveing. Now the correction loop works this way, done after each displayed frame: AV_delay=a_pts-v_pts-delay; x=AV_delay*0.1; if(x<-max_pts_correction) x=-max_pts_correction; else if(x> max_pts_correction) x= max_pts_correction; delay+=x; It worked fine in g1, but now, with accurate PTS values, it is waving, when AV_delay!=0.0: As AV_delay>0, x>0, delay is increased, it starts decreasing AV_delay but it is decreased faster than should so it goes negative. then x<=0, resulting AV_delay increasing again, and so on. in a few (10-20) secs it stabilizes around 0, but this is not good. For big initial AV_delay (like 330ms for some LCPM VOBs) it just keep waving for a minute. I guess the silly (found by trial&error) x=AV_delay*0.1; eq. should be replaced by something better, probably something using pow(). It could also help to do smaller corrections for small AV_delay and big corrections (faster reaction) to big delay, and avoid waving at the same time. Anyone with better math background, could suggest sth good? :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri May 9 01:32:22 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 9 May 2003 01:32:22 +0200 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <20030508074316.GX23552@brightrain.aerifal.cx> Message-ID: <200305082332.h48NWMC4018994@mail.mplayerhq.hu> Hi, > Arpi, I'm trying to decide how to best implement G200 support in G2. > You're prolly already aware, but just to remind you, G200's "YV12" > mode gives you 4:2:0 semi-planar, with Y in a plane by itself, but U > and V packed together in a w*(h/2) byte buffer. I see a couple > possible ways of handling this: > > 1) Same as G1: don't allow DR, but use draw_slice instead, and > interleave slices as they're drawn. Easy, but slow when the last > filter has to copy to a temp buffer rather than DR. > > 2) Export DR buffers, but allocate fake U/V planes in system memory. > Let the codec/filters DR into real Y and fake U/V planes, then > interleave U/V when put_image is called. This method is nice when > the codec/filter can DR, but for non-B frames with IP[B] codecs, it > will result in extra senseless copying from the readable buffer in > system memory to the fake U/V buffers, then interleaving into the > real U/V buffer. > > 3) Have vo_mga report that YV12 is NOT available for G200, and define > a new image format for this 'semi-planar' mode. Then vf_scale can > get automatically inserted, and use a super-fast interleave-only > converter without scaling. With the appropriate enhancements (which > should be there for planar 4:1:1/4:1:0 modes anyway), vf_scale > could allow direct rendering straight through it for the Y plane, > but use its own buffers for U/V which need to be converted. It > could do a similar trick for slice rendering through scale, and > likewise by setting up an EXPORT type image when not using DR or > slices. > > Personally, I think option (3) is the cleanest solution, if it can be > done without a performance hit. That way we don't clutter up vf_vo2.c > or vo_mga.c with all sorts of hacks. Maybe you have another better > idea, though? No, 3) is the best (and only acceptable, imho) solution. As you wrote, it will try to get DR (get_image()) buffers, then passthru Y buffer for the upper level (prev. filters/codec) while doing per-slice (using draw_slice()) for UV conversion. Actaully it's possible in g1 too, but in g1 DR and slices are mutually exclusive, you can't do both at the same time. In g2 you can. (so even if you do DR, unless you mask out DRAW_CALBACKS flag, your draw_slice also will be called - note this feature is not yet well tested (nothing supports/use it yet), but in theory it's supoprted and should work) Btw Vektor mentioned scanline buffers yesterday, and I think it's a very interesting approach. ie. replace plane+stride with array of scanline pointers :) It would allow very amazing optimizations, like DR scanlines without OSD, and copy the rest. But I guess such feature won't go into g2 soon, maybe into g3, or in g2 v2.0 :)) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Fri May 9 01:26:30 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 8 May 2003 19:26:30 -0400 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <200305082332.h48NWMC4018994@mail.mplayerhq.hu> References: <20030508074316.GX23552@brightrain.aerifal.cx> <200305082332.h48NWMC4018994@mail.mplayerhq.hu> Message-ID: <20030508232630.GB23552@brightrain.aerifal.cx> On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote: > Btw Vektor mentioned scanline buffers yesterday, and I think it's a very > interesting approach. ie. replace plane+stride with array of scanline > pointers :) > It would allow very amazing optimizations, like DR scanlines without OSD, > and copy the rest. But I guess such feature won't go into g2 soon, maybe > into g3, or in g2 v2.0 :)) Yes, but it's only good for scanline-based filters. For example, if you want to apply a block-based filter (e.g. deblock, dering, telecine detection, anything DCT-based, etc.) you have to load a separate base pointer every 8 pixels or so inside your inner loop, which is horribly inefficient. With a single base plus stride, you can just use two registers (current position and stride) with no extra memory reads. Rich From arpi at thot.banki.hu Fri May 9 01:55:36 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 9 May 2003 01:55:36 +0200 Subject: [MPlayer-G2-dev] a-v sync again In-Reply-To: <200305082322.h48NMkZp011604@mail.mplayerhq.hu> Message-ID: <200305082355.h48NtaRq008579@mail.mplayerhq.hu> Hi, > It worked fine in g1, but now, with accurate PTS values, it is waving, > when AV_delay!=0.0: > As AV_delay>0, x>0, delay is increased, it starts decreasing AV_delay but it > is decreased faster than should so it goes negative. then x<=0, resulting > AV_delay increasing again, and so on. in a few (10-20) secs it stabilizes > around 0, but this is not good. For big initial AV_delay (like 330ms for > some LCPM VOBs) it just keep waving for a minute. Sorry, 100l to me :) I've enabled autosync yesterday to test sth, and forgot to disable... And it seems the autosync code (which smooths out soundcard's timing) causes this waving, as it doesn't know directly about the delay change, just through the soundcard smoothed. Even I should know that a simple x'=x-x*0.1; func cannot wave around zero :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Fri May 9 01:57:31 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 9 May 2003 01:57:31 +0200 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <20030508232630.GB23552@brightrain.aerifal.cx> Message-ID: <200305082357.h48NvVN2010147@mail.mplayerhq.hu> Hi, > On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote: > > Btw Vektor mentioned scanline buffers yesterday, and I think it's a very > > interesting approach. ie. replace plane+stride with array of scanline > > pointers :) > > It would allow very amazing optimizations, like DR scanlines without OSD, > > and copy the rest. But I guess such feature won't go into g2 soon, maybe > > into g3, or in g2 v2.0 :)) > > Yes, but it's only good for scanline-based filters. For example, if > you want to apply a block-based filter (e.g. deblock, dering, telecine > detection, anything DCT-based, etc.) you have to load a separate base > pointer every 8 pixels or so inside your inner loop, which is horribly > inefficient. With a single base plus stride, you can just use two > registers (current position and stride) with no extra memory reads. Hmm, you're right... Btw afair Michael's postproc code copies macroblocks into some internal aligned in-l1-cache buffer for processing and at the end it copies it back. Btw 2, what about MB-lines instead of scanlines? :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From vektor at dumbterm.net Fri May 9 01:26:08 2003 From: vektor at dumbterm.net (Billy Biggs) Date: Thu, 8 May 2003 18:26:08 -0500 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <20030508232630.GB23552@brightrain.aerifal.cx> References: <20030508074316.GX23552@brightrain.aerifal.cx> <200305082332.h48NWMC4018994@mail.mplayerhq.hu> <20030508232630.GB23552@brightrain.aerifal.cx> Message-ID: <20030508232608.GA15230@dumbterm.net> D Richard Felker III (dalias at aerifal.cx): > On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote: > > Btw Vektor mentioned scanline buffers yesterday, and I think it's a very > > interesting approach. ie. replace plane+stride with array of scanline > > pointers :) > > It would allow very amazing optimizations, like DR scanlines without OSD, > > and copy the rest. But I guess such feature won't go into g2 soon, maybe > > into g3, or in g2 v2.0 :)) > > Yes, but it's only good for scanline-based filters. For example, if you want > to apply a block-based filter (e.g. deblock, dering, telecine detection, > anything DCT-based, etc.) you have to load a separate base pointer every 8 > pixels or so inside your inner loop, which is horribly inefficient. With a > single base plus stride, you can just use two registers (current position and > stride) with no extra memory reads. You can detect the case when they're all from the same buffer pretty easily though, or just have a flag. -Billy From arpi at thot.banki.hu Sat May 10 01:39:42 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 10 May 2003 01:39:42 +0200 Subject: [MPlayer-G2-dev] pre21 released Message-ID: <200305092339.h49NdgQu000959@mail.mplayerhq.hu> Hi, pre21 is not a big change in diff size, but a big step forward in a-v sync code. now playing mpeg streams (tested with mpeg 1/2 video, mpeg/ac3/lpcm audio) have constant A-V: 0.000 :) most asf is jumping as hell, but it is not easy to fix. it seems that wma is like vorbis, the number of uncompressed samples per compressed frame is not constant. but the timestamps stored for each compressed frame in the container have constant distance... so either they calculate timestamps for input rate (why?) or they are dumb (why?) ... the strange thing is that wma-in-asf works fine (in sync) using the acm dll codec (in mplayer g1 0.90), but have variable 200..500ms desync with ffwma. i remember that the acm codec buffered huge (around 150k) amount of compressed data, so maybe it's some average bitrate compression, which is somewhat smoothed/delayed by the dll codec, but isn't by ffwma. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Sat May 10 01:58:41 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 10 May 2003 01:58:41 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: Message-ID: <200305092358.h49Nwf9T019435@mail.mplayerhq.hu> Hi, > --- ./osdep/timer-macosx.c Wed Feb 19 18:22:02 2003 > +++ ../g2-pre20/osdep/timer-macosx.c Wed May 7 19:50:08 2003 > @@ -4,13 +4,22 @@ > * (C) 2003 Dan Christiansen > * > * Released into the public domain. > + * > + * Changelog: > + * 07/05/2003 sleep_accurate() merged from timer-lx.c > + * updated to mplayer-g2 > + * > */ I guess (hope) darwin isn't as lame as linux is about usleep(), ie it can do at least 1ms accurate delay (linux's usleep() is +-20ms "accurate" only), at least afaik freebsd can. So, for non-linux systems it should be imho: float sleep_accurate(float x){ usec_sleep(x*1000000.0); return 0; } could you test if it's accurate enough (A-V: 0.000 cosntant for mpeg files), and teh delay number in the () after V: is constant (usually 0.040), too? A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From danchr at daimi.au.dk Sat May 10 12:59:30 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Sat, 10 May 2003 12:59:30 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305092358.h49Nwf9T019435@mail.mplayerhq.hu> Message-ID: <79B13919-82D6-11D7-96D8-000A27B4ECCA@daimi.au.dk> Just wondering, is it on purpose that the darwin/big endian parts aren't in pre21? The pre20 patch applies fine, though, so I'm compiling it right now. I'll do some testing of the accuracy of usleep(), nanosleep() and CFRunLoopRunInMode() later today. I'm especially interested in how CoreFoundation performs - using a run loop instead of blocking has some advantages. Which stresses the timers most? Dropping frames or playing smoothly? On Saturday, May 10, 2003, at 01:58 AM, Arpi wrote: > Hi, > >> --- ./osdep/timer-macosx.c Wed Feb 19 18:22:02 2003 >> +++ ../g2-pre20/osdep/timer-macosx.c Wed May 7 19:50:08 2003 >> @@ -4,13 +4,22 @@ >> * (C) 2003 Dan Christiansen >> * >> * Released into the public domain. >> + * >> + * Changelog: >> + * 07/05/2003 sleep_accurate() merged from timer-lx.c >> + * updated to mplayer-g2 >> + * >> */ > > I guess (hope) darwin isn't as lame as linux is about usleep(), ie it > can do > at least 1ms accurate delay (linux's usleep() is +-20ms "accurate" > only), > at least afaik freebsd can. > > So, for non-linux systems it should be imho: > > float sleep_accurate(float x){ > usec_sleep(x*1000000.0); > return 0; > } > > could you test if it's accurate enough (A-V: 0.000 cosntant for mpeg > files), > and teh delay number in the () after V: is constant (usually 0.040), > too? From arpi at thot.banki.hu Sat May 10 14:06:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 10 May 2003 14:06:05 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <79B13919-82D6-11D7-96D8-000A27B4ECCA@daimi.au.dk> Message-ID: <200305101206.h4AC65AT018144@mail.mplayerhq.hu> Hi, > Just wondering, is it on purpose that the darwin/big endian parts > aren't in pre21? The pre20 patch applies fine, though, so I'm compiling > it right now. if you check teh changelog (in pre21), the porting patches (including yours) will be in pre22. i didn't want to mix porting and new ync code in one change. > I'll do some testing of the accuracy of usleep(), nanosleep() and > CFRunLoopRunInMode() later today. I'm especially interested in how thanks > CoreFoundation performs - using a run loop instead of blocking has some > advantages. Which stresses the timers most? Dropping frames or playing > smoothly? the later but using system timer funcs instead of busy loopig (called softsleep in linux timer.c) has the advantage that other apps can get the idle cpu. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From michaelni at gmx.at Sat May 10 15:17:20 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Sat, 10 May 2003 15:17:20 +0200 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <200305082357.h48NvVN2010147@mail.mplayerhq.hu> References: <200305082357.h48NvVN2010147@mail.mplayerhq.hu> Message-ID: <200305101517.20907.michaelni@gmx.at> Hi On Friday 09 May 2003 01:57, Arpi wrote: > Hi, > > > On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote: > > > Btw Vektor mentioned scanline buffers yesterday, and I think it's a > > > very interesting approach. ie. replace plane+stride with array of > > > scanline pointers :) > > > It would allow very amazing optimizations, like DR scanlines without > > > OSD, and copy the rest. But I guess such feature won't go into g2 soon, > > > maybe into g3, or in g2 v2.0 :)) > > > > Yes, but it's only good for scanline-based filters. For example, if > > you want to apply a block-based filter (e.g. deblock, dering, telecine > > detection, anything DCT-based, etc.) you have to load a separate base > > pointer every 8 pixels or so inside your inner loop, which is horribly > > inefficient. With a single base plus stride, you can just use two > > registers (current position and stride) with no extra memory reads. > > Hmm, you're right... > Btw afair Michael's postproc code copies macroblocks into some internal > aligned in-l1-cache buffer for processing and at the end it copies it back. this copy is only done for the first / last row of blocks so the filters dont need to check y>=0 / y > Btw 2, what about MB-lines instead of scanlines? :) IMHO, the per line pointers are a good idea for simple filters (eq, noise, ...) but for complexer ones which need to fetch pixels in the vertical direction in the inner loops its probably too complex/slow, MB-lines are probably faster to access but not simpler btw, how many MB based filters do we have which would benefit from that? [...] -- Michael screen[y][x] ^= cursor[cy][cx]; (violates patent #4,197,590) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From michaelni at gmx.at Sat May 10 15:33:01 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Sat, 10 May 2003 15:33:01 +0200 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <200305101517.20907.michaelni@gmx.at> References: <200305082357.h48NvVN2010147@mail.mplayerhq.hu> <200305101517.20907.michaelni@gmx.at> Message-ID: <200305101533.01066.michaelni@gmx.at> Hi On Saturday 10 May 2003 15:17, Michael Niedermayer wrote: > Hi > > On Friday 09 May 2003 01:57, Arpi wrote: > > Hi, > > > > > On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote: > > > > Btw Vektor mentioned scanline buffers yesterday, and I think it's a > > > > very interesting approach. ie. replace plane+stride with array of > > > > scanline pointers :) > > > > It would allow very amazing optimizations, like DR scanlines without > > > > OSD, and copy the rest. But I guess such feature won't go into g2 > > > > soon, maybe into g3, or in g2 v2.0 :)) > > > > > > Yes, but it's only good for scanline-based filters. For example, if > > > you want to apply a block-based filter (e.g. deblock, dering, telecine > > > detection, anything DCT-based, etc.) you have to load a separate base > > > pointer every 8 pixels or so inside your inner loop, which is horribly > > > inefficient. With a single base plus stride, you can just use two > > > registers (current position and stride) with no extra memory reads. > > > > Hmm, you're right... > > Btw afair Michael's postproc code copies macroblocks into some internal > > aligned in-l1-cache buffer for processing and at the end it copies it > > back. > > this copy is only done for the first / last row of blocks so the filters > dont need to check y>=0 / y but the source data is practically copied (+brightness/contrast corrected) > to the destination buffer before filtering so if just the source is line > indirect then it should be possible with only a few modifications but i > dunno by how much it will be slower ... > > > Btw 2, what about MB-lines instead of scanlines? :) > > IMHO, the per line pointers are a good idea for simple filters (eq, noise, > ...) but for complexer ones which need to fetch pixels in the vertical > direction in the inner loops its probably too complex/slow, MB-lines are > probably faster to access but not simpler > btw, how many MB based filters do we have which would benefit from that? another more insane & overcomplicated idea: why not squares instead of lines? with constant stride within a square ... [...] -- Michael screen[y][x] ^= cursor[cy][cx]; (violates patent #4,197,590) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From michaelni at gmx.at Sat May 10 15:48:15 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Sat, 10 May 2003 15:48:15 +0200 Subject: G200+NV12 (Re: [MPlayer-G2-dev] Darwin port) In-Reply-To: <200305101533.01066.michaelni@gmx.at> References: <200305082357.h48NvVN2010147@mail.mplayerhq.hu> <200305101517.20907.michaelni@gmx.at> <200305101533.01066.michaelni@gmx.at> Message-ID: <200305101548.15429.michaelni@gmx.at> Hi On Saturday 10 May 2003 15:33, Michael Niedermayer wrote: [...] > > > Btw 2, what about MB-lines instead of scanlines? :) > > > > IMHO, the per line pointers are a good idea for simple filters (eq, > > noise, ...) but for complexer ones which need to fetch pixels in the > > vertical direction in the inner loops its probably too complex/slow, > > MB-lines are probably faster to access but not simpler > > btw, how many MB based filters do we have which would benefit from that? > > another more insane & overcomplicated idea: > why not squares instead of lines? with constant stride within a square ... or perhaps use the stride of the picture for the squares so that if a horizontal continous set of squares is from the same buffer then they can be accessed with a single memcpy/filter_line() per line [...] -- Michael screen[y][x] ^= cursor[cy][cx]; (violates patent #4,197,590) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From nexus at irc.pl Sat May 10 18:10:44 2003 From: nexus at irc.pl (Bohdan Horst) Date: Sat, 10 May 2003 18:10:44 +0200 Subject: [MPlayer-G2-dev] FreeBSD patches (g2p21) Message-ID: <20030510161044.GA8481@essus.net> after: - apply two included patches - import config.h, config.mak from g1 - #undef HAVE_VCD, #undef USE_ESD in config.h G2 compile without any problems on my FreeBSD :) (and works;) best regards -- / irl: Bohdan 'Nexus' Horst | irc: Nexus \ {----------------------v-------^---------------} \ http://irc.pl/nexus | mailto: nexus at irc.pl / -------------- next part -------------- --- Makefile Sun May 4 21:00:05 2003 +++ Makefile Sat May 10 17:55:52 2003 @@ -71,20 +71,20 @@ $(MAKE) -C swscale test-stream: $(OBJS) $(STREAM_DEPS) osdep/libosdep.a test-stream.o - $(CC) $(OBJS) test-stream.o -o test-stream $(STREAM_DEPS) osdep/libosdep.a $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) -lm + $(CC) $(OBJS) test-stream.o -o test-stream $(STREAM_DEPS) osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(I18NLIBS) -lm test-codecs: $(OBJS) $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a test-codecs.o - $(CC) $(OBJS) test-codecs.o -o test-codecs $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) -lm + $(CC) $(OBJS) test-codecs.o -o test-codecs $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(X11_INC) $(VO_LIBS) $(I18NLIBS) -lm test-play: $(OBJS) $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a test-play.o input/libinput.a - $(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) -lm + $(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(I18NLIBS) -lm test-input: test-input.o input/libinput.a osdep/libosdep.a mp_msg.o get_path.o - $(CC) test-input.o -o test-input input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(TERMCAP_LIB) $(LIRC_LIB) + $(CC) test-input.o -o test-input input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(TERMCAP_LIB) $(LIRC_LIB) $(EXTRA_LIB) $(I18NLIBS) .c.o: - $(CC) -c $(CFLAGS) -o $@ $< + $(CC) -c $(CFLAGS) $(X11_INC) -o $@ $< clean: rm -f *.o *.a *~ -------------- next part -------------- --- libvo2/Makefile Fri May 2 18:34:00 2003 +++ libvo2/Makefile Sat May 10 17:52:59 2003 @@ -29,7 +29,7 @@ $(AR) r $(LIBNAME) $(OBJS) test: test.o $(LIBNAME) - $(CC) test.o -o test $(LIBNAME) $(X_LIB) ../mp_msg.c + $(CC) test.o -o test $(EXTRA_INC) $(EXTRA_LIB) $(LIBNAME) $(X_LIB) $(I18NLIBS) ../mp_msg.c clean: rm -f *.o *.a *~ From arpi at thot.banki.hu Sat May 10 22:04:04 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 10 May 2003 22:04:04 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out Message-ID: <200305102004.h4AK44Ua010303@mail.mplayerhq.hu> Hi, I've just uploaded pre22, with the bsd/darwin patches, and some libvo2 api simplification. I've also finished libvo2 dosc, here's it for discussion: Libvo G2 API definition, driver porting tips: [by A'rpi] ============================================= The main differences to libvo1 (used in mplayer 0.90/main): drivers now export their own buffers, instead of handling them: In libvo1, you had to implement draw_slice, draw_frame, draw_image which did the image blitting (copy to buffer), or get_image to export buffer when several conditions accepted. Also vo1 drivers did OSD rendering. In libvo2, you (almost) always export the buffer pointers (planes[]+stride[]) and a flag set describing the buffer behaviour (is it in cvideo ram or fast system ram, is it visible while rendering into it or it's backbuffer etc). All the buffer selection (for double/triple etc buffering), video blitting, colorspace conversion, DR decisions (get_image) is done by vf_vo2.c now. Actually there is a way (for compatibility?) to let vo2 drivers fo the blitting, by implementig draw_slice(), for the cases when tere are no actual buffers to export or it's too problematic to implement for dunno-what reason. An example for that is old SVGALIB api, when you had to call a draw() function to get your image displayed, you never see teh actual video buffer. (actually for some old vga cards it isn't even visible at once, as it's segmented to 64k blocks... so you can access it via a 64k window) Buffers: ~~~~~~~~ So, the first decision you have to do, when starting to write/port a vo2 driver: Are you able to export the buffers (plane pointers and stride(==bytes per line)) or aren't. The former case (exporting buffers) is simpler: You have to allocate (calloc()) an array of vo_bufffer_t structures, and put the pointer into vo->buffers. Then loop though the array and fill each buffer description struct, ie. put plane pointers/stride there. You can store your private per-buffer data in vo_buffer_t->priv. The number of allocated buffers should be put into vo->num_buffers. The case for indirect access (cannot export buffers, but can blit into it) is very similar, with the difference that you don't fill the planes/stride of the buffers, and you set the VO_BUFFER_FLAG_INDIRECT later. In this case, you have to implement draw_slice() function, which will do the blitting (copy to the buffer). You have to fill the buffer_flags, according to the behaviour of your buffers: VO_BUFFER_FLAG_INDIRECT: Set this flag, if you don't export buffers (buffer[n]->planes/stride unset) but you will do the blitting in draw_slice(). Try to avoid this, for performance reasons. VO_BUFFER_FLAG_VIDEORAM: Set this flag, if your buffer is located in slow, linear adressable, mostly write-only buffer. When this flag set, the buffers won't be used for storing prediction (I/P) frames or doing in-place filtering. (so, set this flag, if reading or random addressing of this buffer is much (at least 2 times) slower than doing the same in system ram) VO_BUFFER_FLAG_VISIBLE: Set this flag, if the changes in this buffer are immediatelly visible, not only when calling show_frame(). So, if your buffers are back-buffers copied to the visible area (usually the videocard's RAM) by the driver or the hardware (DMA etc) itself, NOT set this. If your buffers are in the visible video ram area, set this. [Note: for the case of num_buffers>1, it's always meant to the buffer addressed in the show_frame(). It's natural, that if you render into different buffer than show_frame() addressed, it won't be visible...] This flag is used to make buffering setup decisions, with VISIBLE buffers you need at least 3 buffer (triple buffering) for flickerless picture, but with back-buffer (this flag NOT set) it's enough to have only one. VO_BUFFER_FLAG_TIMER: Set this flag, when your vo driver (hardware) can display the buffer content at a given (by PTS) time. Ie, if your hardware have a timer, what you can program to display the buffer only when a given timestamp reached. This flag is useful for hardware mpeg/mjpeg decoder cards, and maybe some advanced TV play-out hardware. But I can imagine the case, when for example mga_vid implements vblank (vertical retrace) IRQ handler, and it can check and swap buffers to have proper interlaced 50/60Hz output rather than usec_sleep() timing. General driver layout: ~~~~~~~~~~~~~~~~~~~~~~ The layout is very similar to libvo1: You have a preinit, uninit and config function. The order is: 1. preinit() 2. multiple calls to query_format() 3. 0, 1, 2 or more calls to config() 4. uninit() preinit: it should detect the availability of the device/driver, and return 0 (error) if it isn't usable. It have 2 parameters, the first one is the subdevice string (can be used to name the device, or pass extra parameters) and a special second parameter to pass teh X11 Display connection, required only by X11-based drivers. Any x11 drivers should return 0 immediatelly when x11_display==NULL ! non-x11 drivers should ignore that parameter! query_format: it is called multiple times to auto-negotiate a common colorspace format and query some driver capability flags. It's used (required) to find and setup optimal filter path for the rendering. See vfcap.h for flags, and read bellow the details i next section. config: it will be called to configure (or change) the device, to a given source/destination size and colorspace format. NOTE that config() may be called zero (==never called), one, or more times between preinit and uninit! You have to be extra carefull to prepare your driver for this, ie it should NOT crash in uninit() when config() was never called, and second config() shouldn't crash or open new window/device!!! To help you, there is vo->config_count, it's always increased by 1, when config() returns 1, by the caller. Note2: config() is called only after successfull (return 1) preinit() call! uninit: called when the apps stop using this driver (usually at exit, or vo driver change). Note: it's only called after successfull (return 1) preinit() call! Driver capability flags ie. what query_format() may return: ~~~~~~~~~~~~~~~~~~~~~~~ The return value of query_format() should be a flag set composed from these, defined at ../video/vfcap.h: VFCAP_CSP_SUPPORTED: The given (parameter of query-format) colorspace is supported. VFCAP_CSP_SUPPORTED_BY_HW: The given colorspace is supported directly, without conversion. Some driver may support multiple colorspaces, but use internal software converters to handle non-native formats. This flag can be used to give some modes a priority over the rest. Note: when you set VFCAP_CSP_SUPPORTED_BY_HW, you also HAVE TO set VFCAP_CSP_SUPPORTED too!!! VFCAP_OSD: The driver/hardware can do OSD rendering. NOTE: You do NOT need to implement osd rendering controls and set this flag to have OSD working! It's normally done by vf_vo2.c or vf_expand, this flag is only needed for hardware-accelerated OSD renderers, or hardware mpeg/mjpeg decoders wiht overlay image support! VFCAP_SPU: Similar to VFCAP_OSD, but teh driver expects compessed/coded SPU stream instead of OSD bitmaps. Useful (only) for hardware mpeg2 decoders. VFCAP_HWSCALE_UP: The vo driver can do upscaling with hardware acceleration. VFCAP_HWSCALE_DOWN: The vo driver can do downscaling with hardware acceleration. VFCAP_SWSCALE: The vo driver (or the underlaying driver layer) can do software scaling. NOTE: You do NOT need to implement swscaler support and set this flag to have software scaling working! It's handled by vf_scale in the filter layer. VFCAP_FLIP: The driver/hardware can display the buffer upside-down. Useful for codecs which produce upside-down pictures. VFCAP_FLIPPED: Set if the driver/hardware always display the picture upside-down! VFCAP_TIMER: Obsolete, see vo->buffer-flags&VO_BUFFER_FLAG_TIMER ! VFCAP_ACCEPT_STRIDE: Set if your draw_slice() does NOT ignore stride[] values. NOTE: it should be set for most cases when draw_slice is implemented, unless yo uhave a very good reason to not support stride (ie. the underlaying driver layer's draw/blit function doesn't have such parameter) Note: the rest of vfcap.h belongs to filters only, they are N/A for vo drivers. control(): ~~~~~~~~~~ There is a control() intercace to pass driver-dependent and extra/optional functions: VOCTRL_RESIZE_DEST: Asks the driver to redefine (move/resize) the display area. The parameters passed in a int[4] array: w,h,x,y. -1 means unchanged. VOCTRL_RESIZE_SRC: Asks the driver to redefine (move/resize) the image source area. The parameters passed in a int[4] array: w,h,x,y. This is useful to implement zooming or panscan. Requires driver/hardware support to display (upscale) only a sub-area of teh source buffer. VOCTRL_SET_WINDOW: Used by X11/Win32 drivers to receive the window handle. May be called multiple times, to move the drawable to other window (2-window fullscreen switching etc) VOCTRL_PAUSE: Tell the vo driver tat we paused the playback. Usefull for drivers/hw with timer. VOCTRL_RESET: Tell the vo driver that we did reset/seek, so there is a discontinuity of the timestamps. Usefull for drivers/hw with timer. VOCTRL_GET_EQUALIZER & VOCTRL_SET_EQUALIZER: read/Write the video equalizer (brightness/contrast/saturation/hue) attributes. Rendering: ~~~~~~~~~~ There are 4 optional functions to cover the rendering process: 1. frame_start: tells the vo driver that we start rendering to the given buffer. Also can be used to lock buffer handle (SDL requies it). 2. draw_slice: asks teh driver to copy/blit the given image area. Note: even if VO_BUFFER_FLAG_INDIRECT is not set, you may implement draw_slice() to get _notified_ when a area of the image is ready, so you can do partial blit or whatever you want. Note, that in this case (VO_BUFFER_FLAG_INDIRECT not set) the image is already copied to the buffer you exported, you don't need to copy it, and src[] points into your buffer! 3. frame_done: tells the vo driver that we finished rendering to the given buffer. the driver may do blitting of its backbuffer to video ram, or upload buffer as texture (opengl) etc. Do NOT SHOW the frame yet! Also can be used to unlock buffer handle (SDL requies it). 4. show_frame: asks the vo driver to show the given buffer/frame. NOTE: it may be different to the buffer passed to last frame_done() !!! (in case of out-of-order decoding, the above functions 1.-3. are called in decoding order, and 4. is called in display order) Event handling: ~~~~~~~~~~~~~~~ vo drivers may implement check_events(), it will be called by the (G)UI to poll input events (mouse/keyboard/etc activity). Events should be passed via the (optional) event_callback() callback function set by (G)UI or vo2 core. details: TODO. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From gabucino at mplayerhq.hu Sun May 11 08:46:50 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Sun, 11 May 2003 08:46:50 +0200 Subject: [MPlayer-G2-dev] pre21 released In-Reply-To: <200305092339.h49NdgQu000959@mail.mplayerhq.hu> References: <200305092339.h49NdgQu000959@mail.mplayerhq.hu> Message-ID: <20030511064650.GA1042@woodstock.localdomain> Arpi wrote: > calculate timestamps for input rate (why?) or they are dumb (why?) ... Why not :) > the strange thing is that wma-in-asf works fine (in sync) using the acm dll > codec (in mplayer g1 0.90), but have variable 200..500ms desync with ffwma. In any case, ffwma is currently unusable (with some files?). You remember that TotalCar video.. 0.91 should come :) -- 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 arpi at thot.banki.hu Sun May 11 14:22:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 11 May 2003 14:22:50 +0200 Subject: [MPlayer-G2-dev] mpeg container's timing (PTS values) In-Reply-To: <200305080014.h480E5gw031983@mail.mplayerhq.hu> Message-ID: <200305111222.h4BCMoJ6030530@mail.mplayerhq.hu> Hi, > > > After experimencng with several streams, i've found that ct: value is > > > the time length of an audio frame. Strange, isn't it? > > > > I think there is a more logical explination. > > I hope so. I've found the explanation: it was me, ie. my 100l bug :) I processed the timestamp after decompressing the frame (before teh decompress it was not available yet), but as ac3 audio frames were split through myultiple packets, i 'connected' the timestamp of packet 2 to the frame started in packet1 (but ended in packet2)... it's fixed now, in pre23 A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From danchr at daimi.au.dk Sun May 11 13:56:25 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Sun, 11 May 2003 13:56:25 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305101206.h4AC65AT018144@mail.mplayerhq.hu> Message-ID: <976C1770-83A7-11D7-B3FD-000A27B4ECCA@daimi.au.dk> I rewrote the mac timer routines. There's a bit of info in the patch. I get some pretty odd behaviour; _lots_ of frames are skipped on even fairly simple material, and A-V is steadily increasing. This is on an MPEG-1 file. Do you have some verified material I could test it with? - Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-timer.diff Type: application/octet-stream Size: 2841 bytes Desc: not available URL: -------------- next part -------------- From arpi at thot.banki.hu Sun May 11 14:45:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 11 May 2003 14:45:20 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <976C1770-83A7-11D7-B3FD-000A27B4ECCA@daimi.au.dk> Message-ID: <200305111245.h4BCjKrU023534@mail.mplayerhq.hu> Hi, > I rewrote the mac timer routines. There's a bit of info in the patch. > > I get some pretty odd behaviour; _lots_ of frames are skipped on even > fairly simple material, and A-V is steadily increasing. This is on an > MPEG-1 file. Do you have some verified material I could test it with? 405divx_sm_v2[1].avi Alice Deejay - Back In My Life.asf Ray_of_light.vob TheJackal-VP3-Sample-VBR-MP3-atmos.avi apollo_440_-_lost_in_space(jason_nevis_lunar_landing).vob bomb.mpg matrix.vob these work for sure, some are from mphq samples > +/* timing without rounding errors */ > float sleep_accurate(float time_frame){ > - // -------- USLEEP + SOFTSLEEP ----------- > - usec_sleep(1000000*time_frame); > - time_frame-=GetRelativeTime(); > - return time_frame; > + float start, end; > + > + start = CFAbsoluteTimeGetCurrent(); > + CFRunLoopRunInMode(kCFRunLoopDefaultMode, time_frame, false); > + end = CFAbsoluteTimeGetCurrent(); > + > + return end-start; > } it should return the timing error, not the actual time spent in sleep. so, in ideal case (very accurate timer) it should return 0. you should try sth like return time_frame-(end-start); Btw how accurate is that CFRunLoopRunInMode() ? <+-1ms? A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From danchr at daimi.au.dk Sun May 11 16:00:58 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Sun, 11 May 2003 16:00:58 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305111245.h4BCjKrU023534@mail.mplayerhq.hu> Message-ID: On Sunday, May 11, 2003, at 02:45 PM, Arpi wrote: > Hi, > >> [snip] > > 405divx_sm_v2[1].avi > Alice Deejay - Back In My Life.asf I tested with this one. >> [snip] > > it should return the timing error, not the actual time spent in sleep. > so, in ideal case (very accurate timer) it should return 0. > you should try sth like return time_frame-(end-start); > > Btw how accurate is that CFRunLoopRunInMode() ? <+-1ms? In my tests, it's almost always ~0,3ms off, but when I use it for timing, A-V drifts up to a second. nanosleep seems quite reliable, and it's mostly 0,1ms and less off. I now use CFRunLoop for "long" intervals and nanosleep for short ones. If a long interval is >0,005, I get drift up to ~0,3s, if it's 0,01, drift is up to ~0,1s. Disk access, swap, etc. can throw it up to a second off. How much A-V drift is acceptable? - Dan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timer-macosx.c URL: -------------- next part -------------- From arpi at thot.banki.hu Sun May 11 16:46:40 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 11 May 2003 16:46:40 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: Message-ID: <200305111446.h4BEkeKe006077@mail.mplayerhq.hu> Hi, > > > > it should return the timing error, not the actual time spent in sleep. > > so, in ideal case (very accurate timer) it should return 0. > > you should try sth like return time_frame-(end-start); > > > > Btw how accurate is that CFRunLoopRunInMode() ? <+-1ms? > > In my tests, it's almost always ~0,3ms off, but when I use it for > timing, A-V drifts up to a second. nanosleep seems quite reliable, and > it's mostly 0,1ms and less off. I now use CFRunLoop for "long" > intervals and nanosleep for short ones. > > If a long interval is >0,005, I get drift up to ~0,3s, if it's 0,01, > drift is up to ~0,1s. Disk access, swap, etc. can throw it up to a hmm. you should test it by printing the return value of sleep_accurate(), it should be close to zero. it should be never less than -0.005 and more than 0.010, but in ideal case it's max +-0.001 off. > second off. How much A-V drift is acceptable? zero but never moe than half frametime, ie around 0.020 for a 25fps video btw that alice dj clip isn't too good for testing, as it have wma audio, which's a-v sycn is somewhat broken with the ddwma decoder (and g2 doesn't supports DLL decoder yet, but it would be useless on macosx anyway) try some mpegs instead A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Sun May 11 16:51:10 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 11 May 2003 16:51:10 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305111446.h4BEkeKe006077@mail.mplayerhq.hu> Message-ID: <200305111451.h4BEpAvV010349@mail.mplayerhq.hu> Hi, > > try some mpegs instead the mpegs from /MPlayer/benchmark/testsuite1/ are perfect, i get constant A-V: 0.0000 playing them. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From danchr at daimi.au.dk Sun May 11 22:00:55 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Sun, 11 May 2003 22:00:55 +0200 Subject: [MPlayer-G2-dev] Darwin port In-Reply-To: <200305111446.h4BEkeKe006077@mail.mplayerhq.hu> Message-ID: <4687AA76-83EB-11D7-B3FD-000A27B4ECCA@daimi.au.dk> On Sunday, May 11, 2003, at 04:46 PM, Arpi wrote: > hmm. you should test it by printing the return value of > sleep_accurate(), > it should be close to zero. it should be never less than -0.005 and > more > than 0.010, but in ideal case it's max +-0.001 off. I changed it to use mach (kernel space) timers instead. It's what Apple encourages for precise timing. It appears that clock_sleep() is always a little late, but never early. I ran it on the matrix vcd clip, and had 9 values which were >0,010 or <-0,005. (Run as root, niced to -20 - I had many more when running unniced.) > zero > but never moe than half frametime, ie around 0.020 for a 25fps video It seems to be largely within those borders, but still fluctuating. - Dan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timer-macosx.c URL: From Jiri.Svoboda at seznam.cz Sun May 11 22:04:12 2003 From: Jiri.Svoboda at seznam.cz (=?iso-8859-2?Q?Ji=F8=ED_Svoboda?=) Date: Sun, 11 May 2003 22:04:12 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <200305102004.h4AK44Ua010303@mail.mplayerhq.hu> Message-ID: Hi, just small comment to interface -frame_start,frame_done.... should return VO_XXXX depending on succes/fail Another question is about plane pointers in buffer structure. Are they considered valid all the time? This will not be true for some vo drivers. For example directfb - valid pointers are supplied only between frame_start and frame_done when surface/buffer is locked. All the rest of the time buffers can be moved without any notification. Jiri Svoboda From arpi at thot.banki.hu Sun May 11 22:45:02 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 11 May 2003 22:45:02 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: Message-ID: <200305112045.h4BKj22X017589@mail.mplayerhq.hu> Hi, > Hi, > just small comment to interface > -frame_start,frame_done.... should return VO_XXXX depending on > succes/fail > > Another question is about plane pointers in buffer structure. Are they > considered valid all the time? This will not be true for some vo > drivers. For example directfb - valid pointers are supplied only between > frame_start and frame_done when surface/buffer is locked. All the rest > of the time buffers can be moved without any notification. huh. i've expected that they are constant since the config() call, but the code doesn't expect it, so it should work. actually the buffers are read/write only between frame_start/frame_done, so otherwise the pointers aren't used. it's better to set them NULL at config and frame_done, for easier bug hunting :) maybe it requires changes in vf_vo2's get_image(), as the stride is required for DR1 decisions, and afair it's done before frame_start. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Mon May 12 02:41:44 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 12 May 2003 02:41:44 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer Message-ID: <200305120041.h4C0fiJI026669@mail.mplayerhq.hu> Hi, pre23: - AVI demuxer: now it can parse interleaved streams. - a_pts calculation fixes, now it handles all mpegs & avis correctly (the flag DEMUX_STREAM_FLAG_PTS_FOR_NEXT is ignored now, it's redundant!) - native Ogg/Ogm/OggS demuxer :) vorbis support not yet finished, nor the old directshow format theora and new dshow video (divx etc) works! yes, i wrote a native ogg demuxer from scratch, based on the ogg fformat specs (libogg/doc/ogg/datastructures.html), it was not a big deal, ogg is very simple (even simpler than vivo) format. the messy/complicated things come when you're parsing codec-specific headers... the demuxer part can be implemented in 1k, see TOOLS/dump_ogg.c :) i didn't implement audio support yet, for 2 reasons: - i don't like vorbis :) - i don't have ogg files using non-vorbis audio. if you have some, upload! (yes yes i know i could use teh ogm-tools to create some, but i'm lazy to rtfm etc to produce well-made sample streams) also no a-v sync code for ogg files yet A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon May 12 05:11:11 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 11 May 2003 23:11:11 -0400 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <200305120041.h4C0fiJI026669@mail.mplayerhq.hu> References: <200305120041.h4C0fiJI026669@mail.mplayerhq.hu> Message-ID: <20030512031111.GH23552@brightrain.aerifal.cx> On Mon, May 12, 2003 at 02:41:44AM +0200, Arpi wrote: > Hi, > > pre23: > - AVI demuxer: now it can parse interleaved streams. Good, at this point, this is the most important one... (When will someone implement nut? Will I have to do it...?!?) > - a_pts calculation fixes, now it handles all mpegs & avis correctly > (the flag DEMUX_STREAM_FLAG_PTS_FOR_NEXT is ignored now, it's redundant!) > - native Ogg/Ogm/OggS demuxer :) > vorbis support not yet finished, nor the old directshow format > theora and new dshow video (divx etc) works! > > > yes, i wrote a native ogg demuxer from scratch, based on the ogg fformat > specs (libogg/doc/ogg/datastructures.html), it was not a big deal, ogg is > very simple (even simpler than vivo) format. the messy/complicated things > come when you're parsing codec-specific headers... > the demuxer part can be implemented in 1k, see TOOLS/dump_ogg.c :) Great! Yep, it's silly to require a special lib to demux ogg. > i didn't implement audio support yet, for 2 reasons: > - i don't like vorbis :) Why? Vorbis seems to be the best audio codec available right now... > - i don't have ogg files using non-vorbis audio. if you have some, upload! > (yes yes i know i could use teh ogm-tools to create some, but i'm lazy to > rtfm etc to produce well-made sample streams) I'm too lazy to make one too. :)) Rich From arpi at thot.banki.hu Mon May 12 12:43:38 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 12 May 2003 12:43:38 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <20030512031111.GH23552@brightrain.aerifal.cx> Message-ID: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> Hi, > On Mon, May 12, 2003 at 02:41:44AM +0200, Arpi wrote: > > Hi, > > > > pre23: > > - AVI demuxer: now it can parse interleaved streams. > > Good, at this point, this is the most important one... (When will > someone implement nut? Will I have to do it...?!?) i'll implement nut demuxer, but i'm lazy & buzy to wrote muxer > > - a_pts calculation fixes, now it handles all mpegs & avis correctly > > (the flag DEMUX_STREAM_FLAG_PTS_FOR_NEXT is ignored now, it's redundant!) > > - native Ogg/Ogm/OggS demuxer :) > > vorbis support not yet finished, nor the old directshow format > > theora and new dshow video (divx etc) works! > > > > > > yes, i wrote a native ogg demuxer from scratch, based on the ogg fformat > > specs (libogg/doc/ogg/datastructures.html), it was not a big deal, ogg is > > very simple (even simpler than vivo) format. the messy/complicated things > > come when you're parsing codec-specific headers... > > the demuxer part can be implemented in 1k, see TOOLS/dump_ogg.c :) > > Great! Yep, it's silly to require a special lib to demux ogg. yes nice to see that what libogg can do is actually doable in 1k of c code :) > > i didn't implement audio support yet, for 2 reasons: > > - i don't like vorbis :) > > Why? Vorbis seems to be the best audio codec available right now... i mean the library, with its extra-silly API and libogg-dependency and idiot way of passing headers from demuxer. > > - i don't have ogg files using non-vorbis audio. if you have some, upload! > > (yes yes i know i could use teh ogm-tools to create some, but i'm lazy to > > rtfm etc to produce well-made sample streams) > > I'm too lazy to make one too. :)) :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon May 12 13:43:57 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 07:43:57 -0400 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> References: <20030512031111.GH23552@brightrain.aerifal.cx> <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> Message-ID: <20030512114357.GN23552@brightrain.aerifal.cx> On Mon, May 12, 2003 at 12:43:38PM +0200, Arpi wrote: > Hi, > > > On Mon, May 12, 2003 at 02:41:44AM +0200, Arpi wrote: > > > Hi, > > > > > > pre23: > > > - AVI demuxer: now it can parse interleaved streams. > > > > Good, at this point, this is the most important one... (When will > > someone implement nut? Will I have to do it...?!?) > > i'll implement nut demuxer, but i'm lazy & buzy to wrote muxer Demuxer for mplayer and g2, or just g2? If you'll do both, I'll see if I can write a muxer soon. I'm getting annoyed that *someone* offered to implement nut to help it get ahead of crap like matroska and mcf, then turned around and implemented matroska support in mplayer first... :(( > > > - a_pts calculation fixes, now it handles all mpegs & avis correctly > > > (the flag DEMUX_STREAM_FLAG_PTS_FOR_NEXT is ignored now, it's redundant!) > > > - native Ogg/Ogm/OggS demuxer :) > > > vorbis support not yet finished, nor the old directshow format > > > theora and new dshow video (divx etc) works! > > > > > > > > > yes, i wrote a native ogg demuxer from scratch, based on the ogg fformat > > > specs (libogg/doc/ogg/datastructures.html), it was not a big deal, ogg is > > > very simple (even simpler than vivo) format. the messy/complicated things > > > come when you're parsing codec-specific headers... > > > the demuxer part can be implemented in 1k, see TOOLS/dump_ogg.c :) > > > > Great! Yep, it's silly to require a special lib to demux ogg. > > yes > nice to see that what libogg can do is actually doable in 1k of c code :) Yep. libogg isn't huge itself, tho. It's just ugly. And the checksum checking is nonsense slowdown. > > > i didn't implement audio support yet, for 2 reasons: > > > - i don't like vorbis :) > > > > Why? Vorbis seems to be the best audio codec available right now... > > i mean the library, with its extra-silly API and libogg-dependency and idiot > way of passing headers from demuxer. Oh. How about just importing the tremor (integer ogg decoder) code into MPlayer? It's quite small, performs much better, and has 24 bits of precision so it shouldn't be lower quality. I'm sure it could be stripped down even more minimally (and optimized too) if desired. Rich From moritz at bunkus.org Mon May 12 14:24:16 2003 From: moritz at bunkus.org (Moritz Bunkus) Date: Mon, 12 May 2003 14:24:16 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <20030512114357.GN23552@brightrain.aerifal.cx> References: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> <20030512114357.GN23552@brightrain.aerifal.cx> Message-ID: <20030512122416.GA2990@bunkus.org> Hi. > I'm getting annoyed that *someone* offered to implement nut to help it > get ahead of crap like matroska and mcf, then turned around and > implemented matroska support in mplayer first... :(( Thanks for the kind words. You have probably misunderstood me. I wanted a new format, I wanted it now, and I wanted my work not to be wasted. So after Matroska really had some source code I could work with I chose Matroska - one of the main reason being its intended audience. (Both of us have just different priorities, so I can understand that you're pissed at me because I promised to work for something that's more important for you than it is for me. I'm sorry I broke that promise.) -- ==> Ciao, Mosu (Moritz Bunkus) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrej at lucky.net Mon May 12 16:55:41 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 12 May 2003 17:55:41 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030508143529.GD20204@lucky.net> References: <20030508135119.GF26745@vega.digitel2002.hu> <20030508143529.GD20204@lucky.net> Message-ID: <20030512145541.GA79333@lucky.net> Hi, community! It's ready now! I mean new config API. Main goals: 1) independency from all other API; 2) independency from any parsers/UI impementation; 3) no global static vars (since all may have many instances); and I strict on keeping these goals forever. :) The proposed API consist of two parts: plugins API (loadable plugin support isn't implemented yet but it's only question of time, I think) and config API. Plugins API consists of 3 structs and 3 functions. Config API consist of 3 structs, 3 functions, and number of constants. And I want to don't extend that API any more, it's big enough. ;) Plugins API (all prefixed pl_ ): struct pl_info_t - info for plugin (it's only structure in loadable module that is visible for link); contains all module information, pointer to open() function and to module type specific functions array (it may replace all *_info_t in the future, may be) struct pl_func_s - module type specific functions struct pl_instance_t - plugin instance specification; is dinamically created pl_register_plugin() - to register plugin in internal list pl_get_plugin() - to get new plugin instance by name and type and add it to chain pl_open_plugin() - wrapper to module specific open() function Config API (all prefixed cfg_ ): struct cfg_t - former struct config (cfg_t is simplest prefixed with cfg_ name) - the most common structure for modules configuration; struct pl_func_s - config specific functions list struct cfg_tree_t - module independent tree of options cfg_register() - to register options in tree cfg_unregister() - to unregister options in tree cfg_find() - to find the option's subtree in tree by name So tree may be extandable at any time (you can add and remove options and suboptions on the fly on any branch), trees may be different, each context may have its own if you need, any UI may be attached just by opening module, no parser-specific calls are allowed. cfg-new.tar.gz contains new API files. g2-diff is patch, it applies new API to cfgparser.c (it's config/commandline parser module now), cfgparser.h (it's for backward compatibility of config parser module only now) and test-cfg.h. Also cfg_register() is added to test-codecs.c and test-play.c. I hope I commented it all well in cfg.h. Try it, please, and send any remarks, demands, changes, etc. I want to have it independent and flexible. Let's do it together! :) With the best wishes. Andriy. P.S. By next step I want to apply new API to -vf option (and to -ovc of mencoder-g2, of course) to get it fully configurable. :) P.P.S. CONF_TYPE_POSITION CONF_TYPE_CHOOSE CONF_TYPE_LIST CONF_TYPE_CHAIN types and save_config() function are not implemented in cfgparser.c yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg-new.tar.gz Type: application/x-tar-gz Size: 4172 bytes Desc: not available URL: -------------- next part -------------- diff -udpr g2/Makefile g2.new/Makefile --- g2/Makefile Mon May 12 02:52:44 2003 +++ g2.new/Makefile Mon May 12 16:17:13 2003 @@ -1,7 +1,7 @@ include config.mak -SRCS = mp_msg.c get_path.c codec-cfg.c cfgparser.c # test-stream.c test-codecs.c +SRCS = mp_msg.c get_path.c codec-cfg.c cfgparser.c cfg.c cfg-plugin.c # test-stream.c test-codecs.c OBJS = $(SRCS:.c=.o) INCLUDE = -I. $(EXTRA_INC) $(X11_INC) diff -udpr g2/cfgparser.c g2.new/cfgparser.c --- g2/cfgparser.c Sat Apr 19 02:14:16 2003 +++ g2.new/cfgparser.c Mon May 12 16:17:13 2003 @@ -4,6 +4,8 @@ * (C) 2001 * * subconfig support by alex + * + * new way of modularized config by Andriy Gritsenko (C) 2003 */ //#define DEBUG @@ -31,78 +33,147 @@ #include "cfgparser.h" -static struct config *config; -static int nr_options; /* number of options in 'conf' */ -static int parser_mode; /* COMMAND_LINE or CONFIG_FILE */ +struct pl_priv_s { + int num; // number of unparsed parameters + char **name; // unparsed options list + char **param; // unparsed parameters list + pl_instance_t *cfgparser; // used for CLI plugin management +}; + static int recursion_depth = 0; -static int init_conf(struct config *conf, int mode) +static char *print_option_help(cfg_t *opt, char *c, size_t s) { -#ifdef DEBUG - assert(conf != NULL); -#endif + switch(opt->type){ + case CONF_TYPE_INT: + if (opt->flags & CONF_MIN){ + if (opt->flags & CONF_MAX) + snprintf(c, s, "%s <%d .. %d>", opt->desc, (int)opt->min, (int)opt->max); + else snprintf(c, s, "%s <%d .. >", opt->desc, (int)opt->min); + } else if (opt->flags & CONF_MAX) { + snprintf(c, s, "%s < .. %d>", opt->desc, (int)opt->max); + } else + goto help_simple; + break; + case CONF_TYPE_FLOAT: + if (opt->flags & CONF_MIN){ + if (opt->flags & CONF_MAX) + snprintf(c, s, "%s <%3.1f .. %3.1f>", opt->desc, opt->min, opt->max); + else snprintf(c, s, "%s <%3.1f .. >", opt->desc, opt->min); + } else if (opt->flags & CONF_MAX) { + snprintf(c, s, "%s < .. %3.1f>", opt->desc, opt->max); + } else + snprintf(c, s, "%s ", opt->desc); + break; + case CONF_TYPE_STRING: + if (opt->flags & CONF_MIN){ + if (opt->flags & CONF_MAX) + snprintf(c, s, "%s <%d...%d chars>", opt->desc, (int)opt->min, (int)opt->max); + else snprintf(c, s, "%s <%d chars min>", opt->desc, (int)opt->min); + } else if (opt->flags & CONF_MAX) { + snprintf(c, s, "%s <%d chars max>", opt->desc, (int)opt->max); + } else + goto help_simple; + break; + case CONF_TYPE_STRING_LIST: + snprintf(c, s, "%s ", opt->desc); + break; + case CONF_TYPE_FUNC_PARAM: + snprintf(c, s, "%s ", opt->desc); + break; + case CONF_TYPE_FUNC_FULL: + snprintf(c, s, "%s []", opt->desc); + break; + case CONF_TYPE_SUBCONFIG: + snprintf(c, s, "%s ", opt->desc); + break; + case CONF_TYPE_FLAG: + case CONF_TYPE_FUNC: + default: +help_simple: + snprintf(c, s, "%s", opt->desc); + } + return c; +} - /* calculate the number of options in 'conf' */ - for (nr_options = 0; conf[nr_options].name != NULL; nr_options++) - /* NOTHING */; +static char *reparse_postponed(pl_instance_t *pli, cfg_tree_t *conf, char *name) +{ + int i; + char *param; + (void) conf; - config = conf; -#ifdef DEBUG - if (mode != COMMAND_LINE && mode != CONFIG_FILE) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "init_conf: wrong mode!\n"); - return -1; + for (i = 0; i < pli->priv->num; i++) { + if (strcmp(pli->priv->name[i], name) == 0) { + pli->priv->num--; + free(pli->priv->name[i]); + param = pli->priv->param[i]; + if (pli->priv->num != i) { + if (i) { + memmove(&pli->priv->name[i], &pli->priv->name[i+1], + (pli->priv->num - i) * sizeof(*pli->priv->name)); + memmove(&pli->priv->param[i], &pli->priv->param[i+1], + (pli->priv->num - i) * sizeof(*pli->priv->param)); + } else { + free(pli->priv->param); + free(pli->priv->name); } -#endif - parser_mode = mode; - return 1; + } + return param; + } + } + return NULL; } -static int read_option(struct config *conf, int conf_optnr, char *opt, char *param) +static int read_option(cfg_tree_t *conf, char *name, char *param, int mode) { - int i; long tmp_int; double tmp_float; int ret = -1; char *endptr; + cfg_t *opt = conf->opt; - mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "read_option: conf=%p optnr=%d opt='%s' param='%s'\n", - conf, conf_optnr, opt, param); - for (i = 0; i < conf_optnr; i++) { - int namelength; - /* allow 'aa*' in config.name */ - namelength=strlen(conf[i].name); - if ( (conf[i].name[namelength-1]=='*') && - !memcmp(opt, conf[i].name, namelength-1)) - break; - - - if (!strcasecmp(opt, conf[i].name)) - break; - } - if (i == conf_optnr) { - if (parser_mode == CONFIG_FILE) - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "invalid option: %s\n", opt); + mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "read_option: name='%s' p=%p type=%d\n", + name, opt->p, opt->type); + + if ((opt->flags & CONF_NOCFG) && mode == CONFIG_FILE) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "this option can only be used on command line: %s\n", name); ret = ERR_NOT_AN_OPTION; goto out; } - mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "read_option: name='%s' p=%p type=%d\n", - conf[i].name, conf[i].p, conf[i].type); - - if (conf[i].flags & CONF_NOCFG && parser_mode == CONFIG_FILE) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "this option can only be used on command line: %s\n", opt); + if ((opt->flags & CONF_NOCMD) && mode == COMMAND_LINE) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "this option can only be used in config file: %s\n", name); ret = ERR_NOT_AN_OPTION; goto out; } - if (conf[i].flags & CONF_NOCMD && parser_mode == COMMAND_LINE) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "this option can only be used in config file: %s\n", opt); + + // Special treat for option listing + if (param && !strcasecmp (param, "help")) { + char c[256]; + + if (mode != COMMAND_LINE) { ret = ERR_NOT_AN_OPTION; goto out; + } + if (CONF_TYPE_HAS_CHILD(opt->type)) { + if (opt->type != CONF_TYPE_DUMMY) + mp_msg(MSGT_CFGPARSER,MSGL_INFO,"\nAvailable suboptions for %s:\n",print_option_help(opt,c,sizeof(c))); + for (conf = conf->subtree; conf; conf = conf->next) { + if (conf->opt->type == CONF_TYPE_DUMMY) // recurse + read_option(conf, name, param, mode); + else if (!(conf->opt->flags & CONF_NOCMD) && opt->desc) + mp_msg(MSGT_CFGPARSER,MSGL_INFO," %-15s - %s\n",conf->opt->name,print_option_help(conf->opt,c,sizeof(c))); + } + } else if (opt->desc) + mp_msg(MSGT_CFGPARSER,MSGL_INFO,"\n %-15s - %s\n",name,print_option_help(opt,c,sizeof(c))); + exit(1); /* terminate all */ } - switch (conf[i].type) { + switch (opt->type) { case CONF_TYPE_FLAG: /* flags need a parameter in config file */ - if (parser_mode == CONFIG_FILE) { + if (mode == CONFIG_FILE && param == NULL) + goto err_missing_param; + else if (param) { if (!strcasecmp(param, "yes") || /* any other language? */ !strcasecmp(param, "ja") || !strcasecmp(param, "si") || @@ -111,22 +182,22 @@ static int read_option(struct config *co !strcasecmp(param, "j") || !strcasecmp(param, "i") || !strcmp(param, "1")) - *((int *) conf[i].p) = conf[i].max; + *((int *) opt->p) = opt->max; else if (!strcasecmp(param, "no") || !strcasecmp(param, "nein") || !strcasecmp(param, "nicht") || !strcasecmp(param, "nem") || !strcasecmp(param, "n") || !strcmp(param, "0")) - *((int *) conf[i].p) = conf[i].min; + *((int *) opt->p) = opt->min; else { mp_msg(MSGT_CFGPARSER, MSGL_ERR, "invalid parameter for flag: %s\n", param); ret = ERR_OUT_OF_RANGE; goto out; } ret = 1; - } else { /* parser_mode == COMMAND_LINE */ - *((int *) conf[i].p) = conf[i].max; + } else { /* mode == COMMAND_LINE */ + *((int *) opt->p) = opt->max; ret = 0; } break; @@ -141,21 +212,19 @@ static int read_option(struct config *co goto out; } - if (conf[i].flags & CONF_MIN) - if (tmp_int < conf[i].min) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be >= %d: %s\n", (int) conf[i].min, param); + if ((opt->flags & CONF_MIN) && tmp_int < opt->min) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be >= %d: %s\n", (int) opt->min, param); ret = ERR_OUT_OF_RANGE; goto out; } - if (conf[i].flags & CONF_MAX) - if (tmp_int > conf[i].max) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be <= %d: %s\n", (int) conf[i].max, param); + if ((opt->flags & CONF_MAX) && tmp_int > opt->max) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be <= %d: %s\n", (int) opt->max, param); ret = ERR_OUT_OF_RANGE; goto out; } - *((int *) conf[i].p) = tmp_int; + *((int *) opt->p) = tmp_int; ret = 1; break; case CONF_TYPE_FLOAT: @@ -164,8 +233,22 @@ static int read_option(struct config *co tmp_float = strtod(param, &endptr); - if ((*endptr == ':') || (*endptr == '/')) + switch (*endptr) { + case ':': + case '/': tmp_float /= strtod(endptr+1, &endptr); + break; + case '.': + case ',': + /* we also handle floats specified with + * non-locale decimal point ::atmos + */ + if(tmp_float<0) + tmp_float -= 1.0/pow(10,strlen(endptr+1)) * strtod(endptr+1, &endptr); + else + tmp_float += 1.0/pow(10,strlen(endptr+1)) * strtod(endptr+1, &endptr); + break; + } if (*endptr) { mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be a floating point number" @@ -174,43 +257,39 @@ static int read_option(struct config *co goto out; } - if (conf[i].flags & CONF_MIN) - if (tmp_float < conf[i].min) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be >= %f: %s\n", conf[i].min, param); + if ((opt->flags & CONF_MIN) && tmp_float < opt->min) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be >= %f: %s\n", opt->min, param); ret = ERR_OUT_OF_RANGE; goto out; } - if (conf[i].flags & CONF_MAX) - if (tmp_float > conf[i].max) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be <= %f: %s\n", conf[i].max, param); + if ((opt->flags & CONF_MAX) && tmp_float > opt->max) { + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be <= %f: %s\n", opt->max, param); ret = ERR_OUT_OF_RANGE; goto out; } - *((float *) conf[i].p) = tmp_float; + *((float *) opt->p) = tmp_float; ret = 1; break; case CONF_TYPE_STRING: if (param == NULL) goto err_missing_param; - if (conf[i].flags & CONF_MIN) - if (strlen(param) < conf[i].min) { + if ((opt->flags & CONF_MIN) && strlen(param) < opt->min) { mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be >= %d chars: %s\n", - (int) conf[i].min, param); + (int) opt->min, param); ret = ERR_OUT_OF_RANGE; goto out; } - if (conf[i].flags & CONF_MAX) - if (strlen(param) > conf[i].max) { + if ((opt->flags & CONF_MAX) && strlen(param) > opt->max) { mp_msg(MSGT_CFGPARSER, MSGL_ERR, "parameter must be <= %d chars: %s\n", - (int) conf[i].max, param); + (int) opt->max, param); ret = ERR_OUT_OF_RANGE; goto out; } - *((char **) conf[i].p) = strdup(param); + *((char **) opt->p) = strdup(param); ret = 1; break; case CONF_TYPE_STRING_LIST: @@ -233,8 +312,8 @@ static int read_option(struct config *co } if(n == 0) goto err_missing_param; - else if( (conf[i].flags & CONF_MIN && n < conf[i].min) || - (conf[i].flags & CONF_MAX && n > conf[i].max) ) { + else if( ((opt->flags & CONF_MIN) && n < opt->min) || + ((opt->flags & CONF_MAX) && n > opt->max) ) { ret = ERR_OUT_OF_RANGE; goto out; } @@ -262,13 +341,13 @@ static int read_option(struct config *co n++; } res[n] = NULL; - *((char ***) conf[i].p) = res; + *((char ***) opt->p) = res; } break; case CONF_TYPE_FUNC_PARAM: if (param == NULL) goto err_missing_param; - if ((((cfg_func_param_t) conf[i].p)(config + i, param)) < 0) { + if ((((cfg_func_param_t) opt->p)(conf, param)) < 0) { ret = ERR_FUNC_ERR; goto out; } @@ -276,17 +355,17 @@ static int read_option(struct config *co break; case CONF_TYPE_FUNC_FULL: if (param!=NULL && param[0]=='-'){ - ret=((cfg_func_arg_param_t) conf[i].p)(config + i, opt, NULL); + ret=((cfg_func_arg_param_t) opt->p)(conf, name, NULL); if (ret>=0) ret=0; /* if we return >=0: param is processed again (if there is any) */ }else{ - ret=((cfg_func_arg_param_t) conf[i].p)(config + i, opt, param); + ret=((cfg_func_arg_param_t) opt->p)(conf, name, param); /* if we return 0: need no param, precess it again */ /* if we return 1: accepted param */ } break; case CONF_TYPE_FUNC: - ret = (((cfg_func_t) conf[i].p)(config + i)); + ret = (((cfg_func_t) opt->p)(conf)); if(ret<0){ ret = ERR_FUNC_ERR; goto out; @@ -298,95 +377,115 @@ static int read_option(struct config *co { char *subparam; char *subopt; - int subconf_optnr; - struct config *subconf; + char *p, *subopt_p; + char *c; + cfg_tree_t *subconf; char *token; int sscanf_ret; + int subparam_n = 0; if (param == NULL) goto err_missing_param; subparam = malloc(strlen(param)+1); - subopt = malloc(strlen(param)+1); + subopt = subopt_p = malloc(strlen(param)+1); - subconf = conf[i].p; - for (subconf_optnr = 0; subconf[subconf_optnr].name != NULL; subconf_optnr++) - /* NOTHING */; + subconf = conf->subtree; + p = strdup(param); // In case that param is a static string (cf man strtok) + ret = 1; token = strtok(param, (char *)&(":")); - while(token) + while(token && ret > 0) { /* clear out */ - subopt[0] = subparam[0] = 0; + subopt_p[0] = subparam[0] = 0; // sscanf_ret = sscanf(token, "%[^=]=%[^\n\0]", subopt, subparam); - sscanf_ret = sscanf(token, "%[^=]=%s", subopt, subparam); + /* special care for unnamed */ + if (opt->flags & CONF_SEQUENT) { + if (++subparam_n > 9) { // SEQUENT cannot have above of 10 options + sscanf_ret = 0; + c = NULL; + } else { + // form the name for read_option() + c = malloc(strlen(name)+4); + sprintf(c, "%s[%d]", name, subparam_n); + sscanf_ret = 1; + subopt = token; + } + } else { + // form the name for read_option() + c = malloc(strlen(name)+1+strlen(subopt)+1); + sprintf(c, "%s:%s", name, subopt); + sscanf_ret = sscanf(token, "%[^=]=%s", subopt_p, subparam); + } - mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "token: '%s', i=%d, subopt='%s', subparam='%s' (ret: %d)\n", token, i, subopt, subparam, sscanf_ret); + mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "token: '%s', subopt='%s', subparam='%s' (ret: %d)\n", token, subopt, subparam, sscanf_ret); switch(sscanf_ret) { case 1: subparam[0] = 0; case 2: - if ((ret = read_option((struct config *)subconf, subconf_optnr, subopt, subparam)) < 0) + if ((subconf = cfg_find(conf->subtree, subopt)) == NULL || + (ret = read_option(subconf, c, *subparam ? subparam : NULL, mode)) < 0) { - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "Subconfig parsing returned error: %d in token: %s\n", - ret, token); - goto out; + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "Subconfig parsing returned error: %d in token: %s\n", ret, token); + ret = ERR_NOT_AN_OPTION; } + if (c) free(c); break; default: mp_msg(MSGT_CFGPARSER, MSGL_ERR, "Invalid subconfig argument! ('%s')\n", token); ret = ERR_NOT_AN_OPTION; - goto out; } token = strtok(NULL, (char *)&(":")); } free(subparam); - free(subopt); - ret = 1; + free(subopt_p); + free(p); break; } case CONF_TYPE_PRINT: - printf("%s", (char *) conf[i].p); + mp_msg(MSGT_CFGPARSER, MSGL_INFO, "%s", (char *) opt->p); exit(1); default: mp_msg(MSGT_CFGPARSER, MSGL_ERR, "Unknown config type specified in conf-mplayer.h!\n"); - break; + goto out; } + conf->flags = 1; // mark it as set out: return ret; err_missing_param: - mp_msg(MSGT_CFGPARSER, MSGL_ERR, "missing parameter for option: %s\n", opt); + mp_msg(MSGT_CFGPARSER, MSGL_ERR, "missing parameter for option: %s\n", name); ret = ERR_MISSING_PARAM; goto out; } -int parse_config_file(struct config *conf, char *conffile) +static int parse_config(pl_instance_t *pli, cfg_tree_t *conf, int argc, char **argv) { -#define PRINT_LINENUM printf("%s(%d): ", conffile, line_num) -#define MAX_LINE_LEN 1000 +#define PRINT_LINENUM printf("%s(%d): ", argv[ret], line_num) +#define MAX_LINE_LEN 2000 #define MAX_OPT_LEN 100 -#define MAX_PARAM_LEN 100 +#define MAX_PARAM_LEN 1000 FILE *fp; char *line; char opt[MAX_OPT_LEN + 1]; char param[MAX_PARAM_LEN + 1]; char c; /* for the "" and '' check */ + cfg_tree_t *co; int tmp; int line_num = 0; int line_pos; /* line pos */ int opt_pos; /* opt pos */ int param_pos; /* param pos */ - int ret = 1; + int ret; int errors = 0; #ifdef DEBUG - assert(conffile != NULL); + assert(argv != NULL); + assert(argc >= 1); #endif - if (++recursion_depth > 1) - printf("Reading config file: %s", conffile); if (recursion_depth > MAX_RECURSION_DEPTH) { printf(": too deep 'include'. check your configfiles\n"); @@ -394,30 +493,32 @@ int parse_config_file(struct config *con goto out; } - if (init_conf(conf, CONFIG_FILE) == -1) { - ret = -1; - goto out; - } - if ((line = (char *) malloc(MAX_LINE_LEN + 1)) == NULL) { printf("\ncan't get memory for 'line': %s", strerror(errno)); ret = -1; goto out; } - if ((fp = fopen(conffile, "r")) == NULL) { + for (ret = 0; ret < argc; ret++) { + if (++recursion_depth > 1) + printf("Reading config file: %s", argv[ret]); + + fp = fopen(argv[ret], "r"); + if (fp == NULL) { if (recursion_depth > 1) printf(": %s\n", strerror(errno)); free(line); ret = 0; goto out; - } - if (recursion_depth > 1) + } + if (recursion_depth > 1) printf("\n"); - while (fgets(line, MAX_LINE_LEN, fp)) { + while (fgets(line, MAX_LINE_LEN, fp)) { if (errors >= 16) { printf("too many errors\n"); + free(line); + fclose(fp); goto out; } @@ -442,14 +543,12 @@ int parse_config_file(struct config *con PRINT_LINENUM; printf("too long option\n"); errors++; - ret = -1; goto nextline; } } if (opt_pos == 0) { PRINT_LINENUM; printf("parse error\n"); - ret = -1; errors++; continue; } @@ -468,7 +567,6 @@ int parse_config_file(struct config *con if (line[line_pos++] != '=') { PRINT_LINENUM; printf("option without parameter\n"); - ret = -1; errors++; continue; } @@ -486,7 +584,6 @@ int parse_config_file(struct config *con if (param_pos >= MAX_PARAM_LEN) { PRINT_LINENUM; printf("too long parameter\n"); - ret = -1; errors++; goto nextline; } @@ -499,7 +596,6 @@ int parse_config_file(struct config *con if (param_pos >= MAX_PARAM_LEN) { PRINT_LINENUM; printf("too long parameter\n"); - ret = -1; errors++; goto nextline; } @@ -511,7 +607,6 @@ int parse_config_file(struct config *con if (param_pos == 0) { PRINT_LINENUM; printf("option without parameter\n"); - ret = -1; errors++; continue; } @@ -530,51 +625,65 @@ int parse_config_file(struct config *con if (line[line_pos] != '\0' && line[line_pos] != '#') { PRINT_LINENUM; printf("extra characters on line: %s\n", line+line_pos); - ret = -1; + errors++; } - tmp = read_option(config, nr_options, opt, param); + co = cfg_find(conf, opt); + if (co) + tmp = read_option(co, opt, param, CONFIG_FILE); + else + tmp = ERR_NOT_AN_OPTION; +// mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "read_option: conf=%p optnr=%d opt='%s' param='%s'\n", +// ??conf??, ??conf_optnr??, opt, param); switch (tmp) { case ERR_NOT_AN_OPTION: + if (co) { // option exist but isn't filled yet (plugin) + pli->priv->num++; + //TODO: check for realloc errors? + pli->priv->name = realloc(pli->priv->name, pli->priv->num * sizeof(char*)); + pli->priv->param = realloc(pli->priv->param, pli->priv->num * sizeof(char*)); + pli->priv->name[pli->priv->num-1] = strdup(opt); + pli->priv->param[pli->priv->num-1] = strdup(param); +#ifdef DEBUG + PRINT_LINENUM; + printf("%s postponed\n", opt); +#endif + continue; + } case ERR_MISSING_PARAM: case ERR_OUT_OF_RANGE: case ERR_FUNC_ERR: PRINT_LINENUM; printf("%s\n", opt); - ret = -1; errors++; continue; /* break */ } nextline: ; + } + free(line); + fclose(fp); } - free(line); - fclose(fp); out: --recursion_depth; + if (errors) return -1; return ret; } -int parse_command_line(struct config *conf, int argc, char **argv, char **envp, char ***filenames) +static int parse_cl(pl_instance_t *pli, cfg_tree_t *conf, int argc, char **argv) { int i; - char **f = NULL; - int f_nr = 0; int tmp; char *opt; int no_more_opts = 0; #ifdef DEBUG assert(argv != NULL); - assert(envp != NULL); assert(argc >= 1); #endif - if (init_conf(conf, COMMAND_LINE) == -1) - return -1; - /* in order to work recursion detection properly in parse_config_file */ ++recursion_depth; @@ -596,12 +705,20 @@ next: if ((no_more_opts == 0) && (*opt == '-') && (*(opt+1) != 0)) /* option */ { + cfg_tree_t *co; + /* remove trailing '-' */ opt++; mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "this_opt = option: %s\n", opt); - tmp = read_option(config, nr_options, opt, argv[i + 1]); + co = cfg_find(conf, opt); + if (co) + tmp = read_option(co, opt, argv[i + 1], COMMAND_LINE); + else + tmp = ERR_NOT_AN_OPTION; +// mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "read_option: conf=%p optnr=%d opt='%s' param='%s'\n", +// ??conf??, ??conf_optnr??, opt, param); switch (tmp) { case ERR_NOT_AN_OPTION: @@ -621,19 +738,18 @@ next: mp_msg(MSGT_CFGPARSER, MSGL_DBG3, "this_opt = filename: %s\n", opt); /* opt is not an option -> treat it as a filename */ - if (!(f = (char **) realloc(f, sizeof(*f) * (f_nr + 2)))) + if (!(pli->priv->param = (char **) realloc(pli->priv->param, + sizeof(*pli->priv->param) * (pli->priv->num + 2)))) goto err_out_mem; - f[f_nr++] = argv[i]; + pli->priv->param[pli->priv->num++] = argv[i]; } } - if (f) - f[f_nr] = NULL; - if (filenames) - *filenames = f; + if (pli->priv->param) + pli->priv->param[pli->priv->num] = NULL; --recursion_depth; - return f_nr; //filenames_nr; + return pli->priv->num; //filenames_nr; err_out_mem: mp_msg(MSGT_CFGPARSER, MSGL_ERR, "can't allocate memory for filenames (%s)\n", strerror(errno)); err_out: @@ -642,49 +758,140 @@ err_out: return -1; } -int list_cfg_options(struct config *conf){ - while(conf->name){ - printf(" -%s",conf->name); - switch(conf->type){ - case CONF_TYPE_FUNC: - case CONF_TYPE_FLAG: - default: - break; - case CONF_TYPE_INT: - if(conf->flags&CONF_RANGE){ - if(conf->flags&CONF_MIN) printf(" <%d",(int)conf->min); else printf("<"); - printf(" .. "); - if(conf->flags&CONF_MAX) printf("%d>",(int)conf->max); else printf(">"); - } else - printf(" "); - break; - case CONF_TYPE_FLOAT: - if(conf->flags&CONF_RANGE){ - if(conf->flags&CONF_MIN) printf(" <%3.1f",conf->min); else printf("<"); - printf(" .. "); - if(conf->flags&CONF_MAX) printf("%3.1f>",conf->max); else printf(">"); - } else - printf(" "); - break; - case CONF_TYPE_STRING: - printf(" "); - break; - case CONF_TYPE_STRING_LIST: - printf(" "); - break; - case CONF_TYPE_FUNC_PARAM: - printf(" "); - break; - case CONF_TYPE_FUNC_FULL: - printf("* []"); - break; - case CONF_TYPE_SUBCONFIG: - printf(" opt1=param1[:opt2=param2:...]"); - break; - } - printf("\n"); - ++conf; +static char *get_next_file(pl_instance_t *pli, cfg_tree_t *conf, char *name) +{ + (void) conf; + + if (pli->priv->num == 0) return NULL; + pli->priv->num--; + name = pli->priv->param[0]; + if (pli->priv->num) + memmove(pli->priv->param, &pli->priv->param[1], pli->priv->num * sizeof(char *)); + else + free(pli->priv->param); + return name; +} + +static int save_config(cfg_tree_t *conf, FILE *f){ + return -1; // not ready yet +} + +/* plugin information */ +static int open_cli(pl_instance_t *pli); + +static struct pl_func_s funcs_CLI={ + &parse_cl, + NULL, + &get_next_file, + NULL +}; + +static pl_info_t info_cli={ + { PLUGIN_VERSION_MAJOR, PLUGIN_VERSION_MINOR }, + PLUGIN_TYPE_CTL, + "CLI", + "commandline parser", + "", + "", + "", + &open_cli, + &funcs_CLI, + NULL +}; + +static struct pl_func_s funcs_cfgparser={ + &parse_config, + NULL, // may be do revert?? + &reparse_postponed, + &save_config +}; + +static pl_info_t info_cfgparser={ + { PLUGIN_VERSION_MAJOR, PLUGIN_VERSION_MINOR }, + PLUGIN_TYPE_CTL, + "cfgparser", + "config file parser", + "", + "", + "", + &open_cli, + &funcs_cfgparser, + NULL +}; + +static int open_cli(pl_instance_t *pli) +{ + if (!pli->priv) { // trying to keep all configs together + if (pli->prev && pli->prev->priv->cfgparser && pli->info == &info_cfgparser) + pli->priv = pli->prev->priv->cfgparser->priv; + else { + pli->priv = calloc(1, sizeof(struct pl_priv_s)); + if (pli->prev && pli->prev->priv->cfgparser) + pli->priv->cfgparser = pli->prev->priv->cfgparser; + else if (pli->info == &info_cfgparser) + pli->priv->cfgparser = pli; } - return 1; + } + return 0; +} + +/*void register_CLI(cfg_tree_t *conf) +{ + pl_register_plugin(info_cli, conf, &cli_preopen); + pl_register_plugin(info_cfgparser, conf, &cli_preopen); +}*/ + +/* backward compatibility stuff :) */ +static pl_instance_t *pl_cfgparser = NULL; + +int parse_config_file(cfg_tree_t *conf, char *conffile) +{ +#ifdef DEBUG + assert(conffile != NULL); + assert(conf != NULL); +#endif + + if (pl_cfgparser == NULL) { + pl_register_plugin(&info_cfgparser, conf, NULL); + pl_cfgparser = pl_get_plugin(NULL, PLUGIN_TYPE_CTL, "cfgparser"); + pl_open_plugin(pl_cfgparser); + } + return parse_config(pl_cfgparser, conf, 1, &conffile); } +static pl_instance_t *pl_cli = NULL; + +int parse_command_line(cfg_tree_t *conf, int argc, char **argv, char **envp, char ***filenames) +{ + int res; + (void) envp; + +#ifdef DEBUG + assert(conf != NULL); +#endif + + if (pl_cli == NULL) { + pl_register_plugin(&info_cli, conf, NULL); + pl_cli = pl_get_plugin(pl_cfgparser, PLUGIN_TYPE_CTL, "CLI"); + pl_open_plugin(pl_cli); + } + res = parse_cl(pl_cli, conf, argc, argv); + if (res >= 0 && filenames) { + *filenames = pl_cli->priv->param; + pl_cli->priv->num = 0; // returned so must be empty + } + return res; +} + +int list_cfg_options(cfg_tree_t *config) +{ + char c[256]; + + for ( ; config; config = config->next) { + if (config->opt->type == CONF_TYPE_DUMMY) + list_cfg_options(config->subtree); + else if (config->opt->desc) + printf(" -%-15s - %s\n",config->opt->name,print_option_help(config->opt,c,sizeof(c))); + } + return 1; +} diff -udpr g2/cfgparser.h g2.new/cfgparser.h --- g2/cfgparser.h Sat Apr 19 02:09:52 2003 +++ g2.new/cfgparser.h Mon May 12 16:17:13 2003 @@ -2,60 +2,27 @@ * command line and config file parser */ -#ifndef __CONFIG_H -#define __CONFIG_H - -#define CONF_TYPE_FLAG 0 -#define CONF_TYPE_INT 1 -#define CONF_TYPE_FLOAT 2 -#define CONF_TYPE_STRING 3 -#define CONF_TYPE_FUNC 4 -#define CONF_TYPE_FUNC_PARAM 5 -#define CONF_TYPE_PRINT 6 -#define CONF_TYPE_FUNC_FULL 7 -#define CONF_TYPE_SUBCONFIG 8 -#define CONF_TYPE_STRING_LIST 9 - - -#define ERR_NOT_AN_OPTION -1 -#define ERR_MISSING_PARAM -2 -#define ERR_OUT_OF_RANGE -3 -#define ERR_FUNC_ERR -4 - - - -#define CONF_MIN (1<<0) -#define CONF_MAX (1<<1) -#define CONF_RANGE (CONF_MIN|CONF_MAX) -#define CONF_NOCFG (1<<2) -#define CONF_NOCMD (1<<3) - -struct config { - char *name; - void *p; - unsigned int type; - unsigned int flags; - float min,max; -}; - -typedef int (*cfg_func_arg_param_t)(struct config *, char *, char *); -typedef int (*cfg_func_param_t)(struct config *, char *); -typedef int (*cfg_func_t)(struct config *); +#include "cfg.h" +// --------- Backward compatibility stuff --------- /* parse_config_file returns: * -1 on error (can't malloc, invalid option...) * 0 if can't open configfile * 1 on success */ -int parse_config_file(struct config *conf, char *conffile); +int parse_config_file(cfg_tree_t *conf, char *conffile); /* parse_command_line returns: * -1 on error (invalid option...) * 0 if there was no filename on command line * >=1 if there were filenames */ -int parse_command_line(struct config *conf, int argc, char **argv, char **envp, char ***filenames); +int parse_command_line(cfg_tree_t *conf, int argc, char **argv, char **envp, char ***filenames); -int list_cfg_options(struct config *conf); +int list_cfg_options(cfg_tree_t *conf); -#endif /* __CONFIG_H */ +/* register internal parsers - config and commandline + * called internally if you use only two functions above + * parse_config_file(main config) must be called before parse_command_line() + */ +//void register_CLI(cfg_tree_t *conf); diff -udpr g2/test-cfg.h g2.new/test-cfg.h --- g2/test-cfg.h Sat Apr 19 02:10:15 2003 +++ g2.new/test-cfg.h Mon May 12 16:17:13 2003 @@ -2,18 +2,18 @@ * config for cfgparser */ -static int cfg_inc_verbose(struct config *conf){ ++verbose; return 0;} +static int cfg_inc_verbose(cfg_tree_t *conf){ ++verbose; return 0;} -static int cfg_include(struct config *conf, char *filename){ +static int cfg_include(cfg_tree_t *conf, char *filename){ return parse_config_file(conf, filename); } -struct config conf[]={ +static cfg_t conf[]={ /* name, pointer, type, flags, min, max */ - {"include", cfg_include, CONF_TYPE_FUNC_PARAM, 0, 0, 0}, /* this must be the first!!! */ - {"-help", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0}, - {"help", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0}, - {"h", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0}, + {"-help", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0, NULL, NULL}, + {"help", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0, NULL, NULL}, + {"h", list_cfg_options, CONF_TYPE_FUNC, CONF_NOCFG, 0, 0, NULL, NULL}, + {"include", cfg_include, CONF_TYPE_FUNC_PARAM, CONF_NOSAVE, 0, 0, NULL, "include config file"}, /* this must be the first!!! */ //---------------------- libao/libvo/mplayer options ------------------------ // {"o", "Option -o has been renamed to -vo (video-out), use -vo !\n", @@ -22,24 +22,24 @@ struct config conf[]={ // {"aop", ao_plugin_conf, CONF_TYPE_SUBCONFIG, 0, 0, 0}, // {"osdlevel", &osd_level, CONF_TYPE_INT, CONF_RANGE, 0, 2 }, - {"dumpstream", &dumpstream, CONF_TYPE_FLAG, 0, 0, 1}, - {"id", &stream_id, CONF_TYPE_INT, CONF_RANGE, 0, MAX_STREAMS-1}, + {"dumpstream", &dumpstream, CONF_TYPE_FLAG, 0, 0, 1, NULL, NULL}, + {"id", &stream_id, CONF_TYPE_INT, CONF_RANGE, 0, MAX_STREAMS-1, NULL, NULL}, - {"extbased", &demuxer_use_file_ext, CONF_TYPE_FLAG, 0, 0, 1}, - {"noextbased", &demuxer_use_file_ext, CONF_TYPE_FLAG, 0, 1, 0}, + {"extbased", &demuxer_use_file_ext, CONF_TYPE_FLAG, 0, 0, 1, NULL, NULL}, + {"noextbased", &demuxer_use_file_ext, CONF_TYPE_FLAG, 0, 1, 0, NULL, NULL}, - {"demuxer", &demuxer_name, CONF_TYPE_STRING, 0, 0, 0}, + {"demuxer", &demuxer_name, CONF_TYPE_STRING, 0, 0, 0, NULL, "demuxer name"}, #ifdef TEST_CODECS - {"c", &codec_name_list, CONF_TYPE_STRING_LIST, 0, 0, 0}, - {"fm", &codec_fm_list, CONF_TYPE_STRING_LIST, 0, 0, 0}, + {"c", &codec_name_list, CONF_TYPE_STRING_LIST, 0, 0, 0, NULL, "codec name"}, + {"fm", &codec_fm_list, CONF_TYPE_STRING_LIST, 0, 0, 0, NULL, "codec family"}, - {"vo", &video_driver_list, CONF_TYPE_STRING_LIST, 0, 0, 0}, - {"ao", &audio_driver_list, CONF_TYPE_STRING_LIST, 0, 0, 0}, - {"vop", &video_filter_list, CONF_TYPE_STRING_LIST, 0, 0, 0}, + {"vo", &video_driver_list, CONF_TYPE_STRING_LIST, 0, 0, 0, NULL, "video out driver"}, + {"ao", &audio_driver_list, CONF_TYPE_STRING_LIST, 0, 0, 0, NULL, "audio out driver"}, + {"vop", &video_filter_list, CONF_TYPE_STRING_LIST, 0, 0, 0, NULL, "video filter list"}, #endif - {"verbose", &verbose, CONF_TYPE_INT, CONF_RANGE, 0, 100}, - {"v", cfg_inc_verbose, CONF_TYPE_FUNC, 0, 0, 0}, - {NULL, NULL, 0, 0, 0, 0} + {"verbose", &verbose, CONF_TYPE_INT, CONF_RANGE|CONF_GLOBAL, 0, 100, NULL, "verbosity level"}, + {"v", cfg_inc_verbose, CONF_TYPE_FUNC, CONF_GLOBAL, 0, 0, NULL, "increase verbosity"}, + {NULL, NULL, 0, 0, 0, 0, NULL, NULL} }; diff -udpr g2/test-play.c g2.new/test-play.c --- g2/test-play.c Sun May 11 15:12:06 2003 +++ g2.new/test-play.c Mon May 12 16:17:13 2003 @@ -83,6 +83,7 @@ int main(int argc,char* argv[], char *en ao_functions_t* audio_out=NULL; vo_instance_t* video_out=NULL; vf_instance_t* vf_vo2; + cfg_tree_t* mconfig=NULL; int i,ret; //INIT mp_msg @@ -92,8 +93,9 @@ int main(int argc,char* argv[], char *en GetCpuCaps(&gCpuCaps); //INIT config/cmdline - if (parse_config_file(conf, "test.conf") < 0) exit(1); - num_filenames=parse_command_line(conf, argc, argv, envp, &filenames); + cfg_register(&mconfig, conf, 0); + if (parse_config_file(mconfig, "test.conf") < 0) exit(1); + num_filenames=parse_command_line(mconfig, argc, argv, envp, &filenames); mp_msg_set_level(verbose+MSGL_STATUS); diff -udpr g2/test-stream.c g2.new/test-stream.c --- g2/test-stream.c Mon May 12 02:05:01 2003 +++ g2.new/test-stream.c Mon May 12 16:17:13 2003 @@ -29,6 +29,7 @@ int main(int argc,char* argv[], char *en demuxer_t* demuxer; FILE* f; int i; + cfg_tree_t* mconfig=NULL; off_t start_pos; //INIT mp_msg @@ -36,8 +37,9 @@ int main(int argc,char* argv[], char *en mp_msg_set_level(MSGL_STATUS); //INIT config/cmdline - if (parse_config_file(conf, "test.conf") < 0) exit(1); - num_filenames=parse_command_line(conf, argc, argv, envp, &filenames); + cfg_register(&mconfig, conf, 0); + if (parse_config_file(mconfig, "test.conf") < 0) exit(1); + num_filenames=parse_command_line(mconfig, argc, argv, envp, &filenames); mp_msg_set_level(verbose+MSGL_STATUS); diff -udpr g2/video/vf.h g2.new/video/vf.h --- g2/video/vf.h Fri May 2 23:02:21 2003 +++ g2.new/video/vf.h Mon May 12 16:17:13 2003 @@ -2,6 +2,8 @@ struct vf_instance_s; struct vf_priv_s; +#include "../cfg.h" + typedef struct vf_info_s { const char *info; const char *name; @@ -9,7 +11,7 @@ typedef struct vf_info_s { const char *comment; int (*open)(struct vf_instance_s* vf,char* args); // Ptr to a struct dscribing the options - void* opts; + cfg_t* opts; } vf_info_t; typedef struct vf_image_context_s { From arpi at thot.banki.hu Mon May 12 18:39:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 12 May 2003 18:39:05 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512145541.GA79333@lucky.net> Message-ID: <200305121639.h4CGd5dO026447@mail.mplayerhq.hu> Hi, > P.S. By next step I want to apply new API to -vf option (and to -ovc of > mencoder-g2, of course) to get it fully configurable. :) i wanna see how does vf configuration will work with this api. > P.P.S. CONF_TYPE_POSITION CONF_TYPE_CHOOSE CONF_TYPE_LIST CONF_TYPE_CHAIN > types and save_config() function are not implemented in cfgparser.c yet. is it supposed to handle the multifile configuration? (like playtree was in g1, but i always liked the method used in g1's parse-mecmd.c better) what i mean: when there are multiple files, one with their own commandline (or configfile) options, are you able to parse them separated, even in parallel? an example: i want to mux an audio, a video and a subtitle file together with mencoder-g2. so i need to open 3 streams, and 3 demuxers for them, in parallel. they probably have different options. btw it would be better to have the options (be it some global one, or demuxer/vfilter/etc specific) in dinamically allocated structurs, instead of in globals. actually i can't see your new cfg api solving either globals, or multiple files problem, not i can see how makes it modules (filters etc) configuration cleaner. btw, about dinamically loaded plugins: the cfg parser shouldn't know about them, esp. about their internal details, or loading them. when the user enables a filter by -vf foobar, then the vf layer will try to open the vf_foobar.so, same for codecs (base don codecs.conf) don't do the same as xine (it loads all plugins at startup). A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From gabucino at mplayerhq.hu Mon May 12 16:04:11 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Mon, 12 May 2003 16:04:11 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> References: <20030512031111.GH23552@brightrain.aerifal.cx> <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> Message-ID: <20030512140411.GA1215@woodstock.localdomain> Arpi wrote: > i'll implement nut demuxer, but i'm lazy & buzy to wrote muxer ^^^^ ROTFL!!! (buzi=gay) A'rpi if you come to the party this saturday, don't get those soft feelings towards me please :))) -- 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 gabucino at mplayerhq.hu Mon May 12 16:05:41 2003 From: gabucino at mplayerhq.hu (gabucino at mplayerhq.hu) Date: Mon, 12 May 2003 16:05:41 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <20030512122416.GA2990@bunkus.org> References: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> <20030512114357.GN23552@brightrain.aerifal.cx> <20030512122416.GA2990@bunkus.org> Message-ID: <20030512140541.GB1215@woodstock.localdomain> Moritz Bunkus wrote: > (Both of us have just different priorities, so I can understand that > you're pissed at me because I promised to work for something that's more > important for you than it is for me. I'm sorry I broke that promise.) Boycott Bunkus! Boycott Bunkus! (just joking:)) -- 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 alex at fsn.hu Mon May 12 18:18:32 2003 From: alex at fsn.hu (Alex Beregszaszi) Date: Mon, 12 May 2003 18:18:32 +0200 Subject: [MPlayer-G2-dev] pre23 released with native ogg demuxer In-Reply-To: <20030512140541.GB1215@woodstock.localdomain> References: <200305121043.h4CAhcv3003262@mail.mplayerhq.hu> <20030512114357.GN23552@brightrain.aerifal.cx> <20030512122416.GA2990@bunkus.org> <20030512140541.GB1215@woodstock.localdomain> Message-ID: <20030512181832.59809016.alex@fsn.hu> Hi, > > (Both of us have just different priorities, so I can understand that > > you're pissed at me because I promised to work for something that's > > more important for you than it is for me. I'm sorry I broke that > > promise.) > Boycott Bunkus! Boycott Bunkus! Boycott xine! (/me angry) -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) From alex at fsn.hu Mon May 12 18:48:24 2003 From: alex at fsn.hu (Alex Beregszaszi) Date: Mon, 12 May 2003 18:48:24 +0200 Subject: [MPlayer-G2-dev] AFMT cosmetics Message-ID: <20030512184824.69eb439e.alex@fsn.hu> Hi folks, this patch changes the "obosoletely named" audio_out_format_name to get_afmt_name and so it does with audio_out_format_bits. -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: afmt.diff URL: From alex at fsn.hu Mon May 12 18:56:27 2003 From: alex at fsn.hu (Alex Beregszaszi) Date: Mon, 12 May 2003 18:56:27 +0200 Subject: [MPlayer-G2-dev] IMGFMT cosmetics Message-ID: <20030512185627.65ae21f1.alex@fsn.hu> Hi, the same as with AFMT. vo_format_name -> get_imgfmt_name :) I'm not went that mad, but i wanted to do this since ages (~2 years?) -- Alex Beregszaszi (MPlayer Core Developer -- http://www.mplayerhq.hu/) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: imgfmt.diff URL: From andrej at lucky.net Mon May 12 19:22:08 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 12 May 2003 20:22:08 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121639.h4CGd5dO026447@mail.mplayerhq.hu> References: <20030512145541.GA79333@lucky.net> <200305121639.h4CGd5dO026447@mail.mplayerhq.hu> Message-ID: <20030512172208.GD80451@lucky.net> Hi, Arpi! Sometime (on Monday, May 12 at 19:03) I've received something... >> P.S. By next step I want to apply new API to -vf option (and to -ovc of >> mencoder-g2, of course) to get it fully configurable. :) >i wanna see how does vf configuration will work with this api. It isn't ready yet in code, just drafts but it will work by the ways we discussed before. >> P.P.S. CONF_TYPE_POSITION CONF_TYPE_CHOOSE CONF_TYPE_LIST CONF_TYPE_CHAIN >> types and save_config() function are not implemented in cfgparser.c yet. >is it supposed to handle the multifile configuration? >(like playtree was in g1, but i always liked the method used in >g1's parse-mecmd.c better) Of course, it will handle multifile configuration. See the function pli->f->uninit() for restoring old values from before. Just isn't ready yet, but it's only config parser function, end application don't have to know it's implementation, just standard calls: pl_instance_t *cfgparser; ..... while(*filenames) { .... get config name cfgparser->parse(cfgparser, mconfig, 1, &configfilename); .... open video file { .... play video file } cfgparser->uninit(cfgparser, mconfig); .... close video file } >what i mean: when there are multiple files, one with their own commandline >(or configfile) options, are you able to parse them separated, even in >parallel? Current way of commandline parsing doesn't allow to have multiple configuration. But don't take offence, please - I didn't improve the file cfgparser.c yet, I only made that API and applied it to cfgparser.c. That parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :) >an example: i want to mux an audio, a video and a subtitle file together >with mencoder-g2. so i need to open 3 streams, and 3 demuxers for them, in >parallel. they probably have different options. No problem with it. Only thing that you have to have is UI that will support that mode. It may be text UI, Gui, even improved version of that cfgparser.c, you don't have to change your application or anything to have it. I mean if you want that multiple configuration and parallelism then just improve cfgparser and nothing more - that API allows it without knowing implementation. >btw it would be better to have the options (be it some global one, or >demuxer/vfilter/etc specific) in dinamically allocated structurs, instead of >in globals. You mean options or variables? If you mean options then they already will be passed into dinamically allocated tree. If you mean variables then any application (user-end, filter, etc.) must at first allocate it then register it then use. No problem but it will take more memory, time of execution, additional API call, and code will be harder. :) >actually i can't see your new cfg api solving either globals, or multiple >files problem, not i can see how makes it modules (filters etc) >configuration cleaner. Heh. You want me to do all work at once. :( Sorry, but it was only API yet. API must be in the first place to prevent a mess in the future. Do you understand me? I'm sorry, my English is too bad sometimes. :/ >btw, about dinamically loaded plugins: the cfg parser shouldn't know about >them, esp. about their internal details, or loading them. It seems I expained it poorly, sorry. I've done that plugins API only because I planned to make CONF_TYPE_CHAIN option type. Current way of -vf is to have it as plain text until you open filter. It will be parsed then and only then when you open filter so you cannot pass it to any UI to preconfigure, UI will see only string "opt=param:..." but UI will don't know what are these opt's. It's not good so I wanted to some API to get these options and create a chain of filters by UI (as control interface, at least). That plugins API isn't really depend on config API, config API just will use two calls of it - pl_get_plugin() and pl_open_plugin(). I did it because I hoped it will start loadable modules support in G2. Do you against of loadable modules concept at all? If you do then I could remove the file cfg-plugin.c and all that API calls. Then UI's will be never unified but it's ok with me, we can always make bunch of functions alike parse_command_line() for each subtype of UI. :) >when the user enables a filter by -vf foobar, then the vf layer will try to >open the vf_foobar.so, same for codecs (base don codecs.conf) Certainly, it will. That plugin API is only wrapper to all different functions since I don't like to let any UI know what to do with each class of objects (vf, codecs, etc.). If you like to have many #include's in each UI/parser - ok, we will. >don't do the same as xine (it loads all plugins at startup). Sure, it's ugly. We have to load plugins when they are needed. I wanted it so I've developed that plugin API to control it, to don't load all plugins at once. Be sure, what I've proposed will easy solve all problems you did mention above without any dependencies (it's my first goal!) but it will take a time, unfortunately, I cannot write and check the code too fast. BTW, if anyone wants to be volunteer to help with that, it will be just great. With best wishes. Andriy. From pnis at coder.hu Mon May 12 19:28:41 2003 From: pnis at coder.hu (Balatoni Denes) Date: Mon, 12 May 2003 19:28:41 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512172208.GD80451@lucky.net> References: <20030512145541.GA79333@lucky.net> <200305121639.h4CGd5dO026447@mail.mplayerhq.hu> <20030512172208.GD80451@lucky.net> Message-ID: <200305121928.41559.pnis@coder.hu> Hi! I hope this isn't a stupid question, but why would there be a config parser/playtree code in mplayer-g2 ? Or that is part of the reference-ui ? On 2003. m?jus 12. 19.22, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Monday, May 12 at 19:03) I've received something... > > >> P.S. By next step I want to apply new API to -vf option (and to -ovc of > >> mencoder-g2, of course) to get it fully configurable. :) > > > >i wanna see how does vf configuration will work with this api. bye Denes From arpi at thot.banki.hu Mon May 12 20:25:46 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 12 May 2003 20:25:46 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512172208.GD80451@lucky.net> Message-ID: <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> Hi, > Sometime (on Monday, May 12 at 19:03) I've received something... > >> P.S. By next step I want to apply new API to -vf option (and to -ovc of > >> mencoder-g2, of course) to get it fully configurable. :) > > >i wanna see how does vf configuration will work with this api. > > It isn't ready yet in code, just drafts but it will work by the ways > we discussed before. last time we discuss it i said i don't like that static struct (nor the way that it initializes filter's priv struct) > >> P.P.S. CONF_TYPE_POSITION CONF_TYPE_CHOOSE CONF_TYPE_LIST CONF_TYPE_CHAIN > >> types and save_config() function are not implemented in cfgparser.c yet. > > >is it supposed to handle the multifile configuration? > >(like playtree was in g1, but i always liked the method used in > >g1's parse-mecmd.c better) > > Of course, it will handle multifile configuration. See the function > pli->f->uninit() for restoring old values from before. Just isn't ready > yet, but it's only config parser function, end application don't have to > know it's implementation, just standard calls: > > pl_instance_t *cfgparser; > ..... > while(*filenames) { > .... get config name > cfgparser->parse(cfgparser, mconfig, 1, &configfilename); hmm and where you tell the parser whic file is being played now? (ie which file-specific options you want) > .... open video file > { > .... play video file > } > cfgparser->uninit(cfgparser, mconfig); > .... close video file > } > > >what i mean: when there are multiple files, one with their own commandline > >(or configfile) options, are you able to parse them separated, even in > >parallel? > > Current way of commandline parsing doesn't allow to have multiple > configuration. But don't take offence, please - I didn't improve the file > cfgparser.c yet, I only made that API and applied it to cfgparser.c. That cfgparser.c was dropped in temporary (see changelog), for being able to pass some args to the test-* files. i didn't meant to keep or modify it for the final g2. it was just simpler than messing with for, strcmp and atoi in main() :) > parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :) dunno i meant the API provided by parser-mecmd.c: typedef struct m_entry_st { char* name; // Filename, url or whatever char** opts; // NULL terminated list of name,val pairs } m_entry_t; // Free a list returned by m_config_parse_command_line void m_entry_list_free(m_entry_t* lst); // Use this when you switch to another entry int m_entry_set_options(m_config_t *config, m_entry_t* entry); m_entry_t* m_config_parse_me_command_line(m_config_t *config, int argc, char **argv); so you get an array of files togethwer with their specific options, and you can select any of them and ask the "system" to set parameters to the ones belonging to that file. but imho it's UI problem, not g2 core. what i want in g2 is a simple struct where i can tell the UI the available options, and i'll receive a struct filled with their values at init. > >an example: i want to mux an audio, a video and a subtitle file together > >with mencoder-g2. so i need to open 3 streams, and 3 demuxers for them, in > >parallel. they probably have different options. > > No problem with it. Only thing that you have to have is UI that will > support that mode. It may be text UI, Gui, even improved version of that > cfgparser.c, you don't have to change your application or anything to > have it. I mean if you want that multiple configuration and parallelism > then just improve cfgparser and nothing more - that API allows it without > knowing implementation. great. how? > >btw it would be better to have the options (be it some global one, or > >demuxer/vfilter/etc specific) in dinamically allocated structurs, instead of > >in globals. > > You mean options or variables? If you mean options then they already aren't they the same? i mean values of the options so insteda of still messing with static globals, i want dinamically allocated structs filled by the values (be it default or the one set by various ui options, confifile etc). so i could even have different sets of configuration values in parallel. > will be passed into dinamically allocated tree. If you mean variables > then any application (user-end, filter, etc.) must at first allocate it > then register it then use. No problem but it will take more memory, time > of execution, additional API call, and code will be harder. :) why? i could imagine that an app/plugin defines a struct to keep configuration variables. it also defines a cfg_t table describing these fields. and then export (register?) this info for the config parser. hmm, maybe your idea with static struct in vfilters isn't that bad, if you use it a bit different way: that static struct in the plugin code is read-only, ie modification is not allowed. it serves as storage of the default values, and struct layout. you export the cfg_t struct (with pointers into that static struct) and the static structs parameters (pointer to it and sizeof it), and you'll receive a dinamically allocated copy of it, fields may be overwritten by the ones from commandline/config/ui/etc options. > >actually i can't see your new cfg api solving either globals, or multiple > >files problem, not i can see how makes it modules (filters etc) > >configuration cleaner. > > Heh. You want me to do all work at once. :( Sorry, but it was only > API yet. API must be in the first place to prevent a mess in the future. > Do you understand me? I'm sorry, my English is too bad sometimes. :/ ok... you send it as being almost complete code > >btw, about dinamically loaded plugins: the cfg parser shouldn't know about > >them, esp. about their internal details, or loading them. > > It seems I expained it poorly, sorry. I've done that plugins API only > because I planned to make CONF_TYPE_CHAIN option type. Current way of -vf > is to have it as plain text until you open filter. It will be parsed then > and only then when you open filter so you cannot pass it to any UI to > preconfigure, UI will see only string "opt=param:..." but UI will don't > know what are these opt's. It's not good so I wanted to some API to get > these options and create a chain of filters by UI (as control interface, > at least). That plugins API isn't really depend on config API, config API > just will use two calls of it - pl_get_plugin() and pl_open_plugin(). I > did it because I hoped it will start loadable modules support in G2. Do > you against of loadable modules concept at all? If you do then I could no but i'm against load-all-modules-at-startup concept btw what you say about UI have some sence. ie. ui's "configure plugin" (be it builtin or dyn-loaded) should work, without starting the playback, so the UI have to be able to open plugin by name and receive its configuration structures. > remove the file cfg-plugin.c and all that API calls. Then UI's will be > never unified but it's ok with me, we can always make bunch of functions > alike parse_command_line() for each subtype of UI. :) dunno i still don't think that we should (can) unify all the plugin interfaces what you want is proabbly a function to 'enumerate' the available plugins in a common structure, into each layer. like plugin_list_t* vo_get_plugins(); will return a struct filled by the plugin name, description and config struct pointer. it's required anyway by the GUIs for the plugin selection comboboxes. > >when the user enables a filter by -vf foobar, then the vf layer will try to > >open the vf_foobar.so, same for codecs (base don codecs.conf) > > Certainly, it will. That plugin API is only wrapper to all different > functions since I don't like to let any UI know what to do with each > class of objects (vf, codecs, etc.). If you like to have many #include's > in each UI/parser - ok, we will. > > >don't do the same as xine (it loads all plugins at startup). > > Sure, it's ugly. We have to load plugins when they are needed. I > wanted it so I've developed that plugin API to control it, to don't load > all plugins at once. > > Be sure, what I've proposed will easy solve all problems you did > mention above without any dependencies (it's my first goal!) but it will > take a time, unfortunately, I cannot write and check the code too fast. > BTW, if anyone wants to be volunteer to help with that, it will be just > great. Albeu? :)))))))) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 12 19:52:01 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 12 May 2003 20:52:01 +0300 Subject: [MPlayer-G2-dev] Re: mp-G2 pre18 In-Reply-To: <200305121659.h4CGx8ww018860@mail.mplayerhq.hu> References: <20030512160507.GC80451@lucky.net> <200305121659.h4CGx8ww018860@mail.mplayerhq.hu> Message-ID: <20030512175201.GF80451@lucky.net> Hi, Arpi! Sometime (on Monday, May 12 at 19:23) I've received something... >i still prefer sth like: >struct priv_st { > int w,h > void* something; > char palette[1024]; > ... >}; Then you have to have struct priv_st priv_st_defaults={...} with defaults anyway. >static cfg_t config={ > "width", STRUCT_OFF(priv_st,w), ..., > ... > NULL >} >vf_foobar_open(vf_instance_t* vf, void* args){ > vf->priv=calloc(sizeof(priv_st),1); > if(!cfg_parse_args(vf->priv,config)) return 0; > ... > return 1; >} Only thing you missed there is it will be created only on plugin open so it's hard to change it's defaults from config. But may be it's also good to call config API after creating that instance. May be, because it will take new API entry and support of dinamically allocated objects. I didn't mention that all these objects will take extra memory for temporal buffer (do you remember about VFCTRL_GET_PARAMS ?) and may take extra memory for individual config trees. :) I think I know how to do it a like that (without additional type of struct, of course!) but it will take some big time to rebuild concept and code. ;) Also I have to say that cfg_parse_args() will be UI specific call so we cannot implement it without some pl_func_t* structure, so we again need plugins API. :) With best wishes. Andriy. From arpi at thot.banki.hu Mon May 12 20:29:05 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 12 May 2003 20:29:05 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121928.41559.pnis@coder.hu> Message-ID: <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> Hi, > Hi! > > I hope this isn't a stupid question, but why would there be a config > parser/playtree code in mplayer-g2 ? Or that is part of the reference-ui ? you have to define the options in the filters, ao/vo plugins, demuxers, so the external (G)UI will know what kind of parameters and how it can pass to the layers. in g2 core it only means a struct definition and such struct filled with data inside the modules/plugins. the rest is UI problem, but it would be nice to have a cfg parser in the core, usable by all UIs. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From pontscho at kac.poliod.hu Mon May 12 20:12:24 2003 From: pontscho at kac.poliod.hu (Zoltan Ponekker) Date: Mon, 12 May 2003 20:12:24 +0200 (CEST) Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121928.41559.pnis@coder.hu> Message-ID: Hali > I hope this isn't a stupid question, but why would there be a config > parser/playtree code in mplayer-g2 ? Or that is part of the reference-ui ? grrrrrrrrrrrr. Pontscho / fresh!mindworkz --- MPlayer Core Team - www.MPlayerHQ.hu From andrej at lucky.net Mon May 12 21:23:59 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 12 May 2003 22:23:59 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> Message-ID: <20030512192359.GG80451@lucky.net> Hi, Arpi! Sometime (on Monday, May 12 at 20:50) I've received something... >> >> P.S. By next step I want to apply new API to -vf option (and to -ovc of >> >> mencoder-g2, of course) to get it fully configurable. :) >> >i wanna see how does vf configuration will work with this api. >> It isn't ready yet in code, just drafts but it will work by the ways >> we discussed before. >last time we discuss it i said i don't like that static struct (nor the way >that it initializes filter's priv struct) I meant I don't want to link all code together but I want to get it all independent. :) About structs - ok, see my previous letter. [.......] >> parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :) >dunno >i meant the API provided by parser-mecmd.c: [.......] >so you get an array of files togethwer with their specific options, and you >can select any of them and ask the "system" to set parameters to the ones >belonging to that file. >but imho it's UI problem, not g2 core. I get it. But I said the same - it's only UI problem! The way it will be parsed and applied isn't concern of core! :) >what i want in g2 is a simple struct where i can tell the UI the available >options, and i'll receive a struct filled with their values at init. typedef struct {} cfg_tree_t; It's exactly what we all need (I've commented it as "module independent tree of options" in cfg.h). >> >an example: i want to mux an audio, a video and a subtitle file together >> >with mencoder-g2. so i need to open 3 streams, and 3 demuxers for them, in >> >parallel. they probably have different options. >> No problem with it. Only thing that you have to have is UI that will >> support that mode. It may be text UI, Gui, even improved version of that >> cfgparser.c, you don't have to change your application or anything to >> have it. I mean if you want that multiple configuration and parallelism >> then just improve cfgparser and nothing more - that API allows it without >> knowing implementation. >great. how? By the API calls, you said it yourself - "it's UI problem". :P Only thing that your mencoder-g2 has to allow that parallelism. BTW, I've sent sync code here that allows multiple streams, with multiple demuxers. :) >hmm, maybe your idea with static struct in vfilters isn't that bad, >if you use it a bit different way: >that static struct in the plugin code is read-only, ie modification is not >allowed. it serves as storage of the default values, and struct layout. >you export the cfg_t struct (with pointers into that static struct) and >the static structs parameters (pointer to it and sizeof it), and you'll >receive a dinamically allocated copy of it, fields may be overwritten by >the ones from commandline/config/ui/etc options. It's almost the same what I thought a hour ago. It was why I've said "I think I know how to do it" then. :) >> Heh. You want me to do all work at once. :( Sorry, but it was only >> API yet. API must be in the first place to prevent a mess in the future. >> Do you understand me? I'm sorry, my English is too bad sometimes. :/ >ok... >you send it as being almost complete code Complete as before - API was applied to that test cfgparser, nothing more. I didn't go any further. >> It seems I expained it poorly, sorry. I've done that plugins API only >> because I planned to make CONF_TYPE_CHAIN option type. Current way of -vf >> is to have it as plain text until you open filter. It will be parsed then >> and only then when you open filter so you cannot pass it to any UI to >> preconfigure, UI will see only string "opt=param:..." but UI will don't >> know what are these opt's. It's not good so I wanted to some API to get >> these options and create a chain of filters by UI (as control interface, >> at least). That plugins API isn't really depend on config API, config API >> just will use two calls of it - pl_get_plugin() and pl_open_plugin(). I >> did it because I hoped it will start loadable modules support in G2. Do >> you against of loadable modules concept at all? If you do then I could >no >but i'm against load-all-modules-at-startup concept I'm also! :) But may be anyway we have to scan all available modules at startup (don't load but check) - I don't think if check only by file name is enough. >btw what you say about UI have some sence. >ie. ui's "configure plugin" (be it builtin or dyn-loaded) should work, >without starting the playback, so the UI have to be able to open plugin by >name and receive its configuration structures. Good! I could be understandable now! :) It's that I wanted to say: plugins must be in config tree to allow UI load and configure them. So way UI will add plugin to list is: cfg_find(); // find plugin of that type pl_get_plugin(); // open found plugin ... parse_options ... Is it ok? Anyway that plugin API is very small (~1.8kB plugin.h in cfg.h and ~2.5kB plugin.c as cfg-plugin.c) so let us have it to improve with loadable modules support later. Also note that your current "-vf" has a static variable (char**) so if you will build a chain from UI/parser via plugin API then you don't need to have any statics ("-vf" just creates new chain, we have just associate that chain with the play context but it will do UI/parser/application by itself). >> remove the file cfg-plugin.c and all that API calls. Then UI's will be >> never unified but it's ok with me, we can always make bunch of functions >> alike parse_command_line() for each subtype of UI. :) >dunno >i still don't think that we should (can) unify all the plugin interfaces Why interfaces? It still have struct pl_func_s and struct pl_priv_s. Only unified thing is prev->pl->next thread and some common calls: open() and control() - if you look at vf_instance_t and af_instance_t you could see both these structs have all these things. >what you want is proabbly a function to 'enumerate' the available plugins in >a common structure, into each layer. >like plugin_list_t* vo_get_plugins(); >will return a struct filled by the plugin name, description and config >struct pointer. it's required anyway by the GUIs for the plugin selection >comboboxes. It's hard to Gui (for example) to call all these functions anyway, because when you want to add I'm sure any type of plugin must be just registered in tree. For example: static cfg_t cfg_vf[]={ {"vf",vf_create_chain,CONF_TYPE_PLUGIN_LIST,0,0,0,NULL,"video filters"}, {NULL,NULL,0,0,0,0,NULL,NULL} }; void vf_register_internal_plugins(cfg_tree_t *tree){ cfg_t *newlist=NULL; int i=0; for(...;...;...){ newlist=realloc(newlist,(i+1)*sizeof(cfg_t)); newlist[i].name=vf->info->name; newlist[i].desc=vf->info->info; newlist[i].type=CONF_TYPE_PLUGIN; newlist[i].priv=vf->info->opts; } if(newlist){ newlist[i].name=NULL; // termination cfg_register(tree,cfg_vf,0); tree=cfg_find(tree,"vf"); cfg_register(&tree,newlist,0); } } It may be done by common call pl_register_plugin(), of course, but we have to have plugins info unified then. >> Be sure, what I've proposed will easy solve all problems you did >> mention above without any dependencies (it's my first goal!) but it will >> take a time, unfortunately, I cannot write and check the code too fast. >> BTW, if anyone wants to be volunteer to help with that, it will be just >> great. >Albeu? :)))))))) No, thank you! :))) With best wishes. Andriy. From pnis at coder.hu Mon May 12 22:15:56 2003 From: pnis at coder.hu (Balatoni Denes) Date: Mon, 12 May 2003 22:15:56 +0200 Subject: [MPlayer-G2-dev] core API - was G2 CLI/GUI In-Reply-To: <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> References: <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> Message-ID: <200305122215.56840.pnis@coder.hu> Hi! > > Hi! > > > > I hope this isn't a stupid question, but why would there be a config > > parser/playtree code in mplayer-g2 ? Or that is part of the reference-ui > > ? > > you have to define the options in the filters, ao/vo plugins, demuxers, > so the external (G)UI will know what kind of parameters and how it can pass > to the layers. > > in g2 core it only means a struct definition and such struct filled with > data inside the modules/plugins. That sounds good indeed. To summarize (for myself at least) all plugins should have functions like this (perhaps trough control() fn or just function pointers or whatever you are thinking): parameters * get_available_parameters_and_their_defaults() instance* new_plugin_instance(parameters*) int put_parameters_and_reinit_(instance*, parameters*) int message_to_plugin(instance*, int message id, void * parameters) int do_stuff_the_plugin_is_for(instance* ) +functions specific to plugin type ---------------------------------- And g2 core would have functions roughly like this: mplayer_init() plugin** get_available_plugins_and_parameters() /*** stuff for playback ***/ /* returns title, author, length, suggested demuxer, audio/video codec + parameters, suggested vo ao, filterchains */ info* mplayer_get_info_about_medium(URL) /* URL, demuxer wanted , different filterchainf + filter's parameters, vo ao */ medium* mplayer_open_medium(info * ) /* decode to selected ao+vo with the options set*/ int mplayer_decode_n_frames(medium* , frame number) /* some usefull functions needed during playback by an ui */ int mplayer_seek(medium*) int mplayer_get_playback_status(medium*) /* time,pos etc */ int mplayer_send_message(plugin*, messageid, msg_parameter*) /* if ui eg. wants to put something on the OSD, or move the subtitle down */ /*** stuff for customizing info structure ***/ /* manipulate (append, insert, remove, check, set filter/options) audio/video/osd/whatever filterchain or separate plugin(if not in any chain) for an opened medium */ mplayer_fuck_with_filterchain(info * , chain_id ) mplayer_fuck_with_plugin(info *, A_PLUGIN_THAT_IS_NOT_IN_ANY_CHAIN) Is this what you have in mind roughly? I am curios what the plans are for the toplevel API of the core, if it is already known to some degree. > the rest is UI problem, but it would be nice to have a cfg parser in the > core, usable by all UIs. you are right, a helper library would be usefull (a'la libxmms in some way) > A'rpi / Astral & ESP-team best regards Denes From dalias at aerifal.cx Mon May 12 23:10:16 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 17:10:16 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512192359.GG80451@lucky.net> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030512192359.GG80451@lucky.net> Message-ID: <20030512211016.GS23552@brightrain.aerifal.cx> On Mon, May 12, 2003 at 10:23:59PM +0300, Andriy N. Gritsenko wrote: > >> did it because I hoped it will start loadable modules support in G2. Do > >> you against of loadable modules concept at all? If you do then I could > > >no > >but i'm against load-all-modules-at-startup concept > > I'm also! :) But may be anyway we have to scan all available modules > at startup (don't load but check) - I don't think if check only by file > name is enough. Not acceptable. This sort of bloated slow startup nonsense is what I expect from stuff like mozilla and gimp, not mplayer! Rich From andrej at lucky.net Mon May 12 23:14:50 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 00:14:50 +0300 Subject: [MPlayer-G2-dev] G2 CLI/GUI and config API again - a little request. Message-ID: <20030512211450.GH80451@lucky.net> Hi, Arpi! I have a little question. When I thought how to get rid of static variables for -vf then I've decided we have to have some structure for context. There is draft for that structure. I very want to see if you want to change anything in it (you said before you don't mind of that struct at all). I propose also other structure - play_stream. I'll tell you why I want to have two new structs below. typedef struct play_context { int audios; // number of streams in audio_stream[] struct play_stream audio_stream[]; int videos; struct play_stream video_stream[]; double pts; // presentation time stamp for parallel play sync cfg_tree_t *tree; // root of config for that context } play_context; typedef struct play_stream { demux_stream_t *ds; void *chain; // sh_video_t or sh_audio_t void *out; // vo_instance_t or ao_functions_t play_context *ctx; // where it belongs to } play_stream; Why I want that API? I want to add play_stream* to pl_instance_t so we could have another config context for each stream and any parsing function will know it's context - I mean vf_create_chain() from my previous letter to add new filter in the filter chain. So config belongs to play context and play stream has only one play context. So with that API we will get what you want and UI will create chain by itself. Each time any UI/parser can parse input in only one stream context, isn't it? Initiating new filter will work in order: 1) parse input in current stream context (directly from Gui or for current input file/sid from config parser); 2) load loadable plugin if need and get it's config structure; 3) call vf_create_chain() - it is vf_open_filter() but for plugin API; 3a) vf_open_filter() calling vf->open(); 3b) open() creating new params instance with defaults or previous settings (in depending of config variable alike "persistent_filters", some people will like one way, some other); 3c) open() calling cfg_parse_config() for that play_stream and own params instance; 3d) cfg_parse_config() setting parameters for instance; 4) continue parsing... :) Runtime change of parameters: some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call will do: 1) create new copy of vf->priv; 2) run cfg_parse_config() for own play_stream and copy of vf->priv; 3) update variables if it's possible; 4) free the copy of vf->priv. I hope it's the best way that can get rid of statics at all. Arpi, please, correct all what you don't like in these structs and that scheme (but I hope that scheme is already what you wanted :) and I will apply it all in version 2 of config API. :) With the best wishes. Andriy. From pnis at coder.hu Mon May 12 23:14:17 2003 From: pnis at coder.hu (Balatoni Denes) Date: Mon, 12 May 2003 23:14:17 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512211016.GS23552@brightrain.aerifal.cx> References: <20030512172208.GD80451@lucky.net> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> Message-ID: <200305122314.17022.pnis@coder.hu> Hi! My last question for today I promise. > > I'm also! :) But may be anyway we have to scan all available modules > > at startup (don't load but check) - I don't think if check only by file > > name is enough. > > Not acceptable. This sort of bloated slow startup nonsense is what I > expect from stuff like mozilla and gimp, not mplayer! Ok. How are you going to add plugins to g2 without asking/waiting for weeks for somebody to commit your plugin to cvs ? You can make patch or fork mplayer too, but distributing a binary (+ source) is IMHO more flexible and convenient. Now that I think of it, if users rebuild mplayer all the time, than distributing a filter in patch form is not that inconvinient - best would be imho if it was the users choice. > Rich bye Denes From andrej at lucky.net Mon May 12 23:25:12 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 00:25:12 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512211016.GS23552@brightrain.aerifal.cx> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> Message-ID: <20030512212512.GI80451@lucky.net> Hi, D Richard Felker III! Sometime (on Tuesday, May 13 at 0:02) I've received something... >On Mon, May 12, 2003 at 10:23:59PM +0300, Andriy N. Gritsenko wrote: >> >> did it because I hoped it will start loadable modules support in G2. Do >> >> you against of loadable modules concept at all? If you do then I could >> >no >> >but i'm against load-all-modules-at-startup concept >> I'm also! :) But may be anyway we have to scan all available modules >> at startup (don't load but check) - I don't think if check only by file >> name is enough. >Not acceptable. This sort of bloated slow startup nonsense is what I >expect from stuff like mozilla and gimp, not mplayer! I didn't say if we have do that scan by loading these plugins. There is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and put plugins of each type there. Plugins names will be name.so - it may be enough but version and validity check (and getting all plugin info) will be on loading on demand only. Is it ok? Andriy. From andrej at lucky.net Mon May 12 23:30:59 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 00:30:59 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305122314.17022.pnis@coder.hu> References: <20030512172208.GD80451@lucky.net> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> <200305122314.17022.pnis@coder.hu> Message-ID: <20030512213059.GJ80451@lucky.net> Hi, Balatoni Denes! Sometime (on Tuesday, May 13 at 0:17) I've received something... >Ok. How are you going to add plugins to g2 without asking/waiting for weeks >for somebody to commit your plugin to cvs ? You can make patch or fork mplayer >too, but distributing a binary (+ source) is IMHO more flexible and >convenient. >Now that I think of it, if users rebuild mplayer all the time, than >distributing a filter in patch form is not that inconvinient - best would be >imho if it was the users choice. It's why I wanted to have that plugins API. And remember also about copyrights. If you have only core and all codecs/filters/etc. as modules then you can be as much flexible as possible - don't install/distribute unwanted modules and it's all. :) Be lucky! Andriy. From andrej at lucky.net Mon May 12 23:57:48 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 00:57:48 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512212512.GI80451@lucky.net> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> <20030512212512.GI80451@lucky.net> Message-ID: <20030512215748.GK80451@lucky.net> Hi, D Richard Felker III! In addition to said by me in previous letter: > I didn't say if we have do that scan by loading these plugins. There >is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and >put plugins of each type there. Plugins names will be name.so - it may be >enough but version and validity check (and getting all plugin info) will >be on loading on demand only. Is it ok? Note that also we cannot get any description and help for loadable plugin until we open the file. BTW, opening of one dinamic file may take not so much time. I think mozilla/gimp/etc. just do so much work on the opening so it's sloooooow. When we about to get only info from it, it may be a much faster. Anyway, we could make a difference - we can create another pl_get_infos() call to scan info from loadable plugins. (it may be need for gui but don't need for commandline interface so we can do it only on demand, isn't it?) Andriy. From dalias at aerifal.cx Tue May 13 00:20:25 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 18:20:25 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305122314.17022.pnis@coder.hu> References: <20030512172208.GD80451@lucky.net> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> <200305122314.17022.pnis@coder.hu> Message-ID: <20030512222025.GT23552@brightrain.aerifal.cx> On Mon, May 12, 2003 at 11:14:17PM +0200, Balatoni Denes wrote: > Hi! > > My last question for today I promise. > > > > I'm also! :) But may be anyway we have to scan all available modules > > > at startup (don't load but check) - I don't think if check only by file > > > name is enough. > > > > Not acceptable. This sort of bloated slow startup nonsense is what I > > expect from stuff like mozilla and gimp, not mplayer! > > Ok. How are you going to add plugins to g2 without asking/waiting for weeks > for somebody to commit your plugin to cvs ? You can make patch or fork mplayer > too, but distributing a binary (+ source) is IMHO more flexible and > convenient. Huh? I didn't say anything about plugins being bad. What I said was that it's not acceptable to scan/load them all at startup. MPlayer MUST only load the stuff specifically requested by the user, so that it starts instantly. Rich From dalias at aerifal.cx Tue May 13 00:23:46 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 18:23:46 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512212512.GI80451@lucky.net> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030512192359.GG80451@lucky.net> <20030512211016.GS23552@brightrain.aerifal.cx> <20030512212512.GI80451@lucky.net> Message-ID: <20030512222346.GU23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 12:25:12AM +0300, Andriy N. Gritsenko wrote: > Hi, D Richard Felker III! > > Sometime (on Tuesday, May 13 at 0:02) I've received something... > >On Mon, May 12, 2003 at 10:23:59PM +0300, Andriy N. Gritsenko wrote: > >> >> did it because I hoped it will start loadable modules support in G2. Do > >> >> you against of loadable modules concept at all? If you do then I could > > >> >no > >> >but i'm against load-all-modules-at-startup concept > > >> I'm also! :) But may be anyway we have to scan all available modules > >> at startup (don't load but check) - I don't think if check only by file > >> name is enough. > > >Not acceptable. This sort of bloated slow startup nonsense is what I > >expect from stuff like mozilla and gimp, not mplayer! > > I didn't say if we have do that scan by loading these plugins. There > is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and > put plugins of each type there. Plugins names will be name.so - it may be > enough but version and validity check (and getting all plugin info) will > be on loading on demand only. Is it ok? Don't open and validate it, and only even list the files if the user is using a gui that needs to show a list of plugins. If I'm using mplayer from the command line, there's absolutely no reason it needs to know about any drivers/filters/codecs/etc. I'm not actually specifying on the command line. Checking them is just a waste of time. Stuff can fail later if the user specifies a plugin that doesn't actually exist, or a version mismatch occurs, etc., *** when it comes time to actually load it!! *** Rich From pnis at coder.hu Tue May 13 00:23:08 2003 From: pnis at coder.hu (Balatoni Denes) Date: Tue, 13 May 2003 00:23:08 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512222025.GT23552@brightrain.aerifal.cx> References: <20030512172208.GD80451@lucky.net> <200305122314.17022.pnis@coder.hu> <20030512222025.GT23552@brightrain.aerifal.cx> Message-ID: <200305130023.08743.pnis@coder.hu> Hi! > > Ok. How are you going to add plugins to g2 without asking/waiting for > > weeks for somebody to commit your plugin to cvs ? You can make patch or > > fork mplayer too, but distributing a binary (+ source) is IMHO more > > flexible and convenient. > > Huh? I didn't say anything about plugins being bad. What I said was > that it's not acceptable to scan/load them all at startup. MPlayer > MUST only load the stuff specifically requested by the user, so that > it starts instantly. I understand that, an indeed this should be possible. However if there is a plugin, it has to be dlopened (or something) to tell what parameters it excpects - that is if plugins can be added any time. Perhaps if a plugin is only opened when it's parameters are queried (and of course when it is used) than everybody will be happy - a cli to mplayer has the choice not to query the plugin if it knows the parameters by heart. > Rich bye Denes From andrej at lucky.net Tue May 13 00:50:41 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 01:50:41 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305130023.08743.pnis@coder.hu> References: <20030512172208.GD80451@lucky.net> <200305122314.17022.pnis@coder.hu> <20030512222025.GT23552@brightrain.aerifal.cx> <200305130023.08743.pnis@coder.hu> Message-ID: <20030512225041.GL80451@lucky.net> Hi, Balatoni Denes! Sometime (on Tuesday, May 13 at 1:25) I've received something... >> > Ok. How are you going to add plugins to g2 without asking/waiting for >> > weeks for somebody to commit your plugin to cvs ? You can make patch or >> > fork mplayer too, but distributing a binary (+ source) is IMHO more >> > flexible and convenient. >> Huh? I didn't say anything about plugins being bad. What I said was >> that it's not acceptable to scan/load them all at startup. MPlayer >> MUST only load the stuff specifically requested by the user, so that >> it starts instantly. >I understand that, an indeed this should be possible. However if there is a >plugin, it has to be dlopened (or something) to tell what parameters it >excpects - that is if plugins can be added any time. Nope. :) You can only tell at first if plugin is really exist. Then you can dlopen() it only if you requested to. But all plugins are expected to have ModuleInfo structure with certain order of fields. May be we have to set there also some kind of magic ['M','P'] for example. So we will check it on open: .... plr->handle = dlopen (path, RTLD_NOW); if (!handle) { return -1; } plr->info = dlsym (handle, "ModuleInfo"); if (!plr->info || plr->info->version[0] != PLUGIN_VERSION_MAJOR || plr->info->version[1] < PLUGIN_VERSION_MINOR || plr->info->version[2] != 'M' || plr->info->version[3] != 'P') { dlclose (plr->handle); return -1; } .... >Perhaps if a plugin is only opened when it's parameters are queried (and of >course when it is used) than everybody will be happy - a cli to mplayer has >the choice not to query the plugin if it knows the parameters by heart. I did it in the updated cfgparser.c - it remembers parameters for plugin from config(s) to apply it only when plugin is about to open. But it is details of implementation, nothing more, user application have to don't worry about that and even know. :) Andriy. From arpi at thot.banki.hu Tue May 13 01:40:29 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 01:40:29 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512211016.GS23552@brightrain.aerifal.cx> Message-ID: <200305122340.h4CNeTXA020426@mail.mplayerhq.hu> Hi, > On Mon, May 12, 2003 at 10:23:59PM +0300, Andriy N. Gritsenko wrote: > > >> did it because I hoped it will start loadable modules support in G2. Do > > >> you against of loadable modules concept at all? If you do then I could > > > > >no > > >but i'm against load-all-modules-at-startup concept > > > > I'm also! :) But may be anyway we have to scan all available modules > > at startup (don't load but check) - I don't think if check only by file > > name is enough. > > Not acceptable. This sort of bloated slow startup nonsense is what I > expect from stuff like mozilla and gimp, not mplayer! ahree we don't need to dlopen plugins just to be sure that they are plugins. if they are in mplayer's plugin directory, called as needed (like vf_something.so) then we can expect they will work. it's enough to fail with fatal error when we will opening them at playback. also we could include version (plugin API version) number in either directory name or plugin filename, like vf_scale-1.23.so (ala xanim plugins) to avoid enumerating incompatible plugins. another (ugly but still better) way of teh quicktime's method: append a plugin description structure at eth end of DLL, so the plugin loader can scan the plugin dir and read only these structs, without having to dlopen() and run the actual plugin to get this info. and i'm still against unified plugin structs/interfaces, it's just nonsence. there are well separated layers in g2, keep them so. we can define a plugin (instead of plugin, call them modules, they don't really behave as plugins!) desirciption struct common for the whole g2, and let each layer implement an enumeration function which will fill an array of such struct. btw 3, don't separate builtin and external (dlopened) plugins, they are the same. even in g1, you can compile modules to dynamically loadable .so files instead of compiling into the libs. ok it doesn't really work, due to the crossdependency of configparser and the other codes, but if g2's config code is done well, it could work. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Tue May 13 01:13:51 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 19:13:51 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512225041.GL80451@lucky.net> References: <20030512172208.GD80451@lucky.net> <200305122314.17022.pnis@coder.hu> <20030512222025.GT23552@brightrain.aerifal.cx> <200305130023.08743.pnis@coder.hu> <20030512225041.GL80451@lucky.net> Message-ID: <20030512231351.GV23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 01:50:41AM +0300, Andriy N. Gritsenko wrote: > Hi, Balatoni Denes! > > Sometime (on Tuesday, May 13 at 1:25) I've received something... > > >> > Ok. How are you going to add plugins to g2 without asking/waiting for > >> > weeks for somebody to commit your plugin to cvs ? You can make patch or > >> > fork mplayer too, but distributing a binary (+ source) is IMHO more > >> > flexible and convenient. > > >> Huh? I didn't say anything about plugins being bad. What I said was > >> that it's not acceptable to scan/load them all at startup. MPlayer > >> MUST only load the stuff specifically requested by the user, so that > >> it starts instantly. > > >I understand that, an indeed this should be possible. However if there is a > >plugin, it has to be dlopened (or something) to tell what parameters it > >excpects - that is if plugins can be added any time. > > Nope. :) You can only tell at first if plugin is really exist. Then you > can dlopen() it only if you requested to. But all plugins are expected to > have ModuleInfo structure with certain order of fields. May be we have to > set there also some kind of magic ['M','P'] for example. So we will check > it on open: Right. But you don't have to check if it exists until someone tries to create an instance and configure it. It's perfectly fine to open and/or dlopen the file because the user has specifically attempted to configure it. All that's not-ok is scanning all installed plugins on startup to make a list. > >Perhaps if a plugin is only opened when it's parameters are queried (and of > >course when it is used) than everybody will be happy - a cli to mplayer has > >the choice not to query the plugin if it knows the parameters by heart. > > I did it in the updated cfgparser.c - it remembers parameters for plugin > from config(s) to apply it only when plugin is about to open. But it is > details of implementation, nothing more, user application have to don't > worry about that and even know. :) Eh? What do you need to remember parameters for? Rich From arpi at thot.banki.hu Tue May 13 01:51:45 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 01:51:45 +0200 Subject: [MPlayer-G2-dev] G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030512211450.GH80451@lucky.net> Message-ID: <200305122351.h4CNpjDH030480@mail.mplayerhq.hu> Hi, > Why I want that API? I want to add play_stream* to pl_instance_t so > we could have another config context for each stream and any parsing > function will know it's context - I mean vf_create_chain() from my > previous letter to add new filter in the filter chain. So config belongs > to play context and play stream has only one play context. no, forget this mess it's getting the same cross-dependency everywhere as it was with playtree code don't mix player contexts (don't even define them yet, it's UI thing for sure) with underlaying layers and config api, please! > So with that API we will get what you want and UI will create chain > by itself. Each time any UI/parser can parse input in only one stream > context, isn't it? Initiating new filter will work in order: > 1) parse input in current stream context (directly from Gui or for > current input file/sid from config parser); > 2) load loadable plugin if need and get it's config structure; > 3) call vf_create_chain() - it is vf_open_filter() but for plugin API; > 3a) vf_open_filter() calling vf->open(); > 3b) open() creating new params instance with defaults or previous > settings (in depending of config variable alike "persistent_filters", > some people will like one way, some other); > 3c) open() calling cfg_parse_config() for that play_stream and own params > instance; > 3d) cfg_parse_config() setting parameters for instance; > 4) continue parsing... :) what a mess > Runtime change of parameters: > some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call > will do: > 1) create new copy of vf->priv; PLEASE! it's called priv (_P_ _R_ _I_ _V_) as it's from _PRIVATE_. It means it's not your business, you don't even know what is it. ok??? forget priv, please. priv may contain pluginspecific data types, big arrayes, whatever. don't mess it with configure, ok? keep config layer separated, as we defined as one of teh main goals. ie. pass a clean, config-variables-only structure to the open() functions, and let them decide what and how they will use from it. forget messing with priv, forever. > I hope it's the best way that can get rid of statics at all. Arpi, i doubt > please, correct all what you don't like in these structs and that scheme == rewrite it > (but I hope that scheme is already what you wanted :) and I will apply it not really... sorry. it seems we should (re-)discuss the goals and possible implementation ways first. probably all goals cannot be reached at the same time, so we have to decide which ones are less important, and remove them. then define how and what to implement to reach the rest. this ad-hoc coding doesm't seem to perform well... A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Tue May 13 01:58:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 01:58:50 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305122314.17022.pnis@coder.hu> Message-ID: <200305122358.h4CNwoab007487@mail.mplayerhq.hu> Hi, > My last question for today I promise. > > > > I'm also! :) But may be anyway we have to scan all available modules > > > at startup (don't load but check) - I don't think if check only by file > > > name is enough. > > > > Not acceptable. This sort of bloated slow startup nonsense is what I > > expect from stuff like mozilla and gimp, not mplayer! > > Ok. How are you going to add plugins to g2 without asking/waiting for weeks > for somebody to commit your plugin to cvs ? You can make patch or fork mplayer > too, but distributing a binary (+ source) is IMHO more flexible and > convenient. runtime loadable plugins aren't a no-no, they are even possible in g1! (afair it's --enable-dynamic-plugins or so) it's a bit limited, as you cannot export gloabls and set them using the config parser, but for most codecs/filters it's ok. Rich said that loading all available plugins at startup to see they are there, is nonsense, and i agree. btw, about your problem, wiht slow patch accepting: if a patch is good (== well made, clean etc), it will be accepted faster. remember how messy yoru first demuxer patch was, and how teh final (accepted/commited) one looks like. if we commit yoru first version, it would still be that messy unstable buggy code in cvs, in long term resulting bad code quality. mplayer is (ok, was) superior to avifile, xine etc, because it was stable, relative bugfree and always compilable, thanks to much more strict patch accept policy. even if you're unhappy, i'll be same (or more) strict on g2. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Tue May 13 02:00:37 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 02:00:37 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030512212512.GI80451@lucky.net> Message-ID: <200305130000.h4D00bjP008972@mail.mplayerhq.hu> Hi, > >Not acceptable. This sort of bloated slow startup nonsense is what I > >expect from stuff like mozilla and gimp, not mplayer! > > I didn't say if we have do that scan by loading these plugins. There > is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and > put plugins of each type there. Plugins names will be name.so - it may be > enough but version and validity check (and getting all plugin info) will > be on loading on demand only. Is it ok? plugin names are the same as teh .c file names, but with .so (or .a .dll etc, it's platform dependent!!!) extenion. so for example, demux_ogg.so, vf_scale.so maybe we can include api version number too in some way. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From andrej at lucky.net Tue May 13 02:30:30 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 03:30:30 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305122351.h4CNpjDH030480@mail.mplayerhq.hu> References: <20030512211450.GH80451@lucky.net> <200305122351.h4CNpjDH030480@mail.mplayerhq.hu> Message-ID: <20030513003030.GM80451@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 13 at 2:16) I've received something... >> Why I want that API? I want to add play_stream* to pl_instance_t so >> we could have another config context for each stream and any parsing >> function will know it's context - I mean vf_create_chain() from my >> previous letter to add new filter in the filter chain. So config belongs >> to play context and play stream has only one play context. >no, forget this mess >it's getting the same cross-dependency everywhere as it was with playtree >code Where did you see cross-dependency? Tell me, please. >don't mix player contexts (don't even define them yet, it's UI thing for >sure) with underlaying layers and config api, please! Ok. How do you propose to pass what of streams do you want to configure from UI to vf,etc. ? Using statics for it isn't acceptable - you are one who wants to avoid statics. You may have many streams (for example, 3 mixed videos and 2 audios from different files) and you have to configure each of it. If you want to dislike all I've proposed there then, please, tell me the other way. But we __have__ to pass some stream pointer from UI/parser to vf_open_filter(). Or you want to give up the multistreaming idea, eh? >> So with that API we will get what you want and UI will create chain >> by itself. Each time any UI/parser can parse input in only one stream >> context, isn't it? Initiating new filter will work in order: >> 1) parse input in current stream context (directly from Gui or for >> current input file/sid from config parser); UI/config parser have to parse it's input, isn't it? What's wrong? >> 2) load loadable plugin if need and get it's config structure; If we have that plugin loadable then how we can call open() if we don't dlopen() it? What's wrong? >> 3) call vf_create_chain() - it is vf_open_filter() but for plugin API; >> 3a) vf_open_filter() calling vf->open(); >> 3b) open() creating new params instance with defaults or previous >> settings (in depending of config variable alike "persistent_filters", >> some people will like one way, some other); >> 3c) open() calling cfg_parse_config() for that play_stream and own params >> instance; >> 3d) cfg_parse_config() setting parameters for instance; >> 4) continue parsing... :) >what a mess It's what _you_ said before. Cite with comments at right: ---- vf_foobar_open(vf_instance_t* vf, void* args){ <-- 3a) vf->priv=calloc(sizeof(priv_st),1); <-- 3b) if(!cfg_parse_args(vf->priv,config)) return 0; <-- 3c) 3d) ... return 1; } ---- What's wrong when I've written it in words? >> Runtime change of parameters: >> some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call >> will do: >> 1) create new copy of vf->priv; >PLEASE! >it's called priv (_P_ _R_ _I_ _V_) as it's from _PRIVATE_. >It means it's not your business, you don't even know what is it. ok??? >forget priv, please. >priv may contain pluginspecific data types, big arrayes, whatever. >don't mess it with configure, ok? OK, OK, I don't mind if we create new type of structure and add it in vf_instance_t. I've wrote vf->priv since vf->priv _already_ have the configuration variables _everywere_. So don't blame me for that, please. >keep config layer separated, as we defined as one of teh main goals. Without any API at all? :))))))) May be we have to forbid any UI or parsers for G2 at all? :))))))) Gui is the worst! Commandline deprecated too! Nothing is the best! :))))))) >ie. pass a clean, config-variables-only structure to the open() functions, >and let them decide what and how they will use from it. >forget messing with priv, forever. >> I hope it's the best way that can get rid of statics at all. Arpi, >i doubt I don't doubt, sorry. >> please, correct all what you don't like in these structs and that scheme >== rewrite it But how? You seem to dislike everything now. ;) >> (but I hope that scheme is already what you wanted :) and I will apply it >not really... >sorry. >it seems we should (re-)discuss the goals and possible implementation ways >first. probably all goals cannot be reached at the same time, so we have to >decide which ones are less important, and remove them. >then define how and what to implement to reach the rest. >this ad-hoc coding doesm't seem to perform well... Tell all goals you see. I already don't know what you want to see from config API at all, sorry. I wrote what I read from you - you calling it a mess, I proposed to have strict API - you say all API is parser specific. I don't know what you want. Sorry. :( I'm afraid we will never get good API that way... :( With best regards. Andriy. From ajh at watri.org.au Tue May 13 02:48:52 2003 From: ajh at watri.org.au (Anders Johansson) Date: Tue, 13 May 2003 08:48:52 +0800 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> References: <200305121928.41559.pnis@coder.hu> <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> Message-ID: <20030513004852.GA793@watri.org.au> Hi, > Hi, > > > Hi! > > > > I hope this isn't a stupid question, but why would there be a config > > parser/playtree code in mplayer-g2 ? Or that is part of the reference-ui ? > > you have to define the options in the filters, ao/vo plugins, demuxers, > so the external (G)UI will know what kind of parameters and how it can pass > to the layers. > > in g2 core it only means a struct definition and such struct filled with > data inside the modules/plugins. > > the rest is UI problem, but it would be nice to have a cfg parser in the > core, usable by all UIs. Just a question what about dynamically loaded modules? Isn't it better with a discovery protocol, so that an application that wants to control an already running instance of MPlayer can know what's loaded and not? > A'rpi / Astral & ESP-team //Anders From dalias at aerifal.cx Tue May 13 04:59:32 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 12 May 2003 22:59:32 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513003030.GM80451@lucky.net> References: <20030512211450.GH80451@lucky.net> <200305122351.h4CNpjDH030480@mail.mplayerhq.hu> <20030513003030.GM80451@lucky.net> Message-ID: <20030513025932.GW23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 03:30:30AM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Tuesday, May 13 at 2:16) I've received something... > >> Why I want that API? I want to add play_stream* to pl_instance_t so > >> we could have another config context for each stream and any parsing > >> function will know it's context - I mean vf_create_chain() from my > >> previous letter to add new filter in the filter chain. So config belongs > >> to play context and play stream has only one play context. > > >no, forget this mess > >it's getting the same cross-dependency everywhere as it was with playtree > >code > > Where did you see cross-dependency? Tell me, please. The config system should just manage querying and setting options in tree and chain structures. It doesn't need to know anything about movie playing. > >don't mix player contexts (don't even define them yet, it's UI thing for > >sure) with underlaying layers and config api, please! > > Ok. How do you propose to pass what of streams do you want to > configure from UI to vf,etc. ? Using statics for it isn't acceptable - > you are one who wants to avoid statics. You may have many streams (for > example, 3 mixed videos and 2 audios from different files) and you have > to configure each of it. If you want to dislike all I've proposed there > then, please, tell me the other way. But we __have__ to pass some stream > pointer from UI/parser to vf_open_filter(). Or you want to give up the > multistreaming idea, eh? Why do you need to have an associated stream to configure a filter chain? The caller can keep track of a config context as needed. If you're doing runtime configuration, the filters are already 'connected' to the stream by the player, and this has nothing to do with the config system, but the filters could presumably use the current stream attributes to limit configuration options. On the other hand, if you're configuring offline before anything is being played, then the filters will have to accept any options that might make sense, then sanitize them when the chain gets configured at playtime. > >> 2) load loadable plugin if need and get it's config structure; > > If we have that plugin loadable then how we can call open() if we > don't dlopen() it? What's wrong? I think Arpi was saying we could read the properties table without calling dlopen (may be slow) for cases where we just need to know what config variables are available, but not actually load the module. Rich From arpi at thot.banki.hu Tue May 13 08:23:27 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 08:23:27 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513003030.GM80451@lucky.net> Message-ID: <200305130623.h4D6NREG016404@mail.mplayerhq.hu> Hi, > Sometime (on Tuesday, May 13 at 2:16) I've received something... > >> Why I want that API? I want to add play_stream* to pl_instance_t so > >> we could have another config context for each stream and any parsing > >> function will know it's context - I mean vf_create_chain() from my > >> previous letter to add new filter in the filter chain. So config belongs > >> to play context and play stream has only one play context. > > >no, forget this mess > >it's getting the same cross-dependency everywhere as it was with playtree > >code > > Where did you see cross-dependency? Tell me, please. > > >don't mix player contexts (don't even define them yet, it's UI thing for > >sure) with underlaying layers and config api, please! > > Ok. How do you propose to pass what of streams do you want to > configure from UI to vf,etc. ? Using statics for it isn't acceptable - > you are one who wants to avoid statics. You may have many streams (for > example, 3 mixed videos and 2 audios from different files) and you have > to configure each of it. If you want to dislike all I've proposed there > then, please, tell me the other way. But we __have__ to pass some stream > pointer from UI/parser to vf_open_filter(). Or you want to give up the > multistreaming idea, eh? have you ever looked at test-play.c ? no streams and such things passed (directly) to vf_open_plugins() yes it's passed to vf_open_filter when opening special filter "vd" i can't see where UI plays or why do you want to introduce more structs here yes, the a-v sync engine surely needs some struct to keep stream state info (pts, etc), but it's another game, not related to filters or config layer. > >> So with that API we will get what you want and UI will create chain > >> by itself. Each time any UI/parser can parse input in only one stream > >> context, isn't it? Initiating new filter will work in order: > >> 1) parse input in current stream context (directly from Gui or for > >> current input file/sid from config parser); > > UI/config parser have to parse it's input, isn't it? What's wrong? > > >> 2) load loadable plugin if need and get it's config structure; > > If we have that plugin loadable then how we can call open() if we > don't dlopen() it? What's wrong? why do you want to call its open() in config level? > >> 3) call vf_create_chain() - it is vf_open_filter() but for plugin API; > >> 3a) vf_open_filter() calling vf->open(); > >> 3b) open() creating new params instance with defaults or previous > >> settings (in depending of config variable alike "persistent_filters", > >> some people will like one way, some other); > >> 3c) open() calling cfg_parse_config() for that play_stream and own params > >> instance; > >> 3d) cfg_parse_config() setting parameters for instance; > >> 4) continue parsing... :) > > >what a mess > > It's what _you_ said before. Cite with comments at right: > > ---- > vf_foobar_open(vf_instance_t* vf, void* args){ <-- 3a) > vf->priv=calloc(sizeof(priv_st),1); <-- 3b) > if(!cfg_parse_args(vf->priv,config)) return 0; <-- 3c) 3d) > ... > return 1; > } > ---- > > What's wrong when I've written it in words? > > >> Runtime change of parameters: > >> some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call > >> will do: > >> 1) create new copy of vf->priv; > > >PLEASE! > >it's called priv (_P_ _R_ _I_ _V_) as it's from _PRIVATE_. > >It means it's not your business, you don't even know what is it. ok??? > >forget priv, please. > >priv may contain pluginspecific data types, big arrayes, whatever. > >don't mess it with configure, ok? > > OK, OK, I don't mind if we create new type of structure and add it in > vf_instance_t. why to add it? why can't you pass it as a parameter, in place if char** args? > I've wrote vf->priv since vf->priv _already_ have the > configuration variables _everywere_. So don't blame me for that, please. > > >keep config layer separated, as we defined as one of teh main goals. > > Without any API at all? :))))))) May be we have to forbid any UI or > parsers for G2 at all? :))))))) Gui is the worst! Commandline deprecated > too! Nothing is the best! :))))))) cool, we finally agree on something :)))))))))))) > >ie. pass a clean, config-variables-only structure to the open() functions, > >and let them decide what and how they will use from it. > >forget messing with priv, forever. > > >> I hope it's the best way that can get rid of statics at all. Arpi, > >i doubt > > I don't doubt, sorry. > > >> please, correct all what you don't like in these structs and that scheme > >== rewrite it > > But how? You seem to dislike everything now. ;) yes > >> (but I hope that scheme is already what you wanted :) and I will apply it > >not really... > > >sorry. > >it seems we should (re-)discuss the goals and possible implementation ways > >first. probably all goals cannot be reached at the same time, so we have to > >decide which ones are less important, and remove them. > >then define how and what to implement to reach the rest. > >this ad-hoc coding doesm't seem to perform well... > > Tell all goals you see. I already don't know what you want to see i'll do that soon > from config API at all, sorry. I wrote what I read from you - you calling > it a mess, I proposed to have strict API - you say all API is parser > specific. I don't know what you want. Sorry. :( neither i know if i would know, i would already implement it. > I'm afraid we will never get good API that way... :( what way? by thinking & design first? A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From pnis at coder.hu Tue May 13 09:36:59 2003 From: pnis at coder.hu (Balatoni Denes) Date: Tue, 13 May 2003 09:36:59 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305122358.h4CNwoab007487@mail.mplayerhq.hu> References: <200305122358.h4CNwoab007487@mail.mplayerhq.hu> Message-ID: <200305130936.59593.pnis@coder.hu> Hi! > runtime loadable plugins aren't a no-no, they are even possible in g1! > (afair it's --enable-dynamic-plugins or so) > it's a bit limited, as you cannot export gloabls and set them using the > config parser, but for most codecs/filters it's ok. > > Rich said that loading all available plugins at startup to see they are > there, is nonsense, and i agree. understood and agreed. > btw, about your problem, wiht slow patch accepting: > if a patch is good (== well made, clean etc), it will be accepted faster. > remember how messy yoru first demuxer patch was, and how teh final > (accepted/commited) one looks like. if we commit yoru first version, it > would still be that messy unstable buggy code in cvs, in long term > resulting bad code quality. Ok, the first version of that patch wasn't exactly short and to the point. This is all good, but I can imagine contributors (me eg. :) ) who make a plugin that works most of the time, but sometimes it breaks , but they don't have time or something so for that moment they don't care about the bugs/problems. In other words imho if g2 will be stable as a rock is very good, and the possibility to have unstable experimental but usefull plugins to it is also good. I believe we agree on this anyhow. best regards Denes From andrej at lucky.net Tue May 13 10:12:33 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 11:12:33 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305130623.h4D6NREG016404@mail.mplayerhq.hu> References: <20030513003030.GM80451@lucky.net> <200305130623.h4D6NREG016404@mail.mplayerhq.hu> Message-ID: <20030513081233.GP80451@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 13 at 8:48) I've received something... >> Ok. How do you propose to pass what of streams do you want to >> configure from UI to vf,etc. ? Using statics for it isn't acceptable - >> you are one who wants to avoid statics. You may have many streams (for >> example, 3 mixed videos and 2 audios from different files) and you have >> to configure each of it. If you want to dislike all I've proposed there >> then, please, tell me the other way. But we __have__ to pass some stream >> pointer from UI/parser to vf_open_filter(). Or you want to give up the >> multistreaming idea, eh? >have you ever looked at test-play.c ? >no streams and such things passed (directly) to vf_open_plugins() >yes it's passed to vf_open_filter when opening special filter "vd" Yes, I've seen test-play.c many times, it has: static char** video_driver_list=NULL; static char** video_filter_list=(char**) NULL; etc. With that statement you will never can get more than one video stream (the same for audio) - you just fixed yourself on the one and it's all. You want to live with that limitation forever? I don't want but you let me change nothing, unfortunately. Ok, I know, my English is bad. I'll try to describe the problem in details. Player (or encoder, or smth else) never know what to play. Just think about it and you cannot deny it. Only parser (or UI, the same) may tell the player what and how to play. But player have to give the UI some variable(s) where UI will put that info. Currently it's static vars. I've proposed some play_context array for this and pass it to parser/UI. If you don't want to play more that one video and audio then leave it as static. If you want to play more then you have to develop some structure. Sorry but you have no choice. >i can't see where UI plays or why do you want to introduce more structs here >yes, the a-v sync engine surely needs some struct to keep stream state info >(pts, etc), but it's another game, not related to filters or config layer. See what I've said above. I hope I've said it clearly. >> >> So with that API we will get what you want and UI will create chain >> >> by itself. Each time any UI/parser can parse input in only one stream >> >> context, isn't it? Initiating new filter will work in order: >> >> 1) parse input in current stream context (directly from Gui or for >> >> current input file/sid from config parser); >> >> UI/config parser have to parse it's input, isn't it? What's wrong? >> >> >> 2) load loadable plugin if need and get it's config structure; >> >> If we have that plugin loadable then how we can call open() if we >> don't dlopen() it? What's wrong? >why do you want to call its open() in config level? See what I've said above. Only parser can tell you if you need to load that plugin or not. Anyway I've described then _not config_ work but all plugin load sequence - no difference who will call it in details, or test-play.c, or something else. >> OK, OK, I don't mind if we create new type of structure and add it in >> vf_instance_t. >why to add it? why can't you pass it as a parameter, in place if char** args? Pass where? I don't said to pass, I've said to keep parameters inside of filter (BTW, you've written it yourself as vf->priv in your examples). If you will dislike to keep these parameters in vf->priv then you could make new struct vf->params or something else. >> Without any API at all? :))))))) May be we have to forbid any UI or >> parsers for G2 at all? :))))))) Gui is the worst! Commandline deprecated >> too! Nothing is the best! :))))))) >cool, we finally agree on something :)))))))))))) It's not cool, it's c00l. ;))) >> But how? You seem to dislike everything now. ;) >yes Get rid of your bad spirit - join a party, go to the nature, see the nice movie, etc. - do what you want. :) It's bad to be in bad mood. :) BTW, I already tired of all that - you're saying your thought, I'm trying to do it, asking for details, you're aborting what you said before - if that will keep forever, I'll just give up. I really tired, sorry. :( With best wishes. Andriy. From arpi at thot.banki.hu Tue May 13 11:04:38 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 11:04:38 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513081233.GP80451@lucky.net> Message-ID: <200305130904.h4D94cRE005060@mail.mplayerhq.hu> Hi, > > Get rid of your bad spirit - join a party, go to the nature, see the > nice movie, etc. - do what you want. :) It's bad to be in bad mood. :) you're right... > BTW, I already tired of all that - you're saying your thought, I'm > trying to do it, asking for details, you're aborting what you said before > - if that will keep forever, I'll just give up. I really tired, sorry. :( instead of running to implement every sentence i said, we should first discuss the goals and the possible ways of implementation, then select the one that everyone accepts. this way no complaints later, or they can be silently ignored ;) i'm thinking about several things, i'll collect and write down it here at afternoon, after work. the problem was(is) that i don't really see what an UI/GUI needs, but you and others already help a lot by telling these, and posisble problems which may arrise if we go for my way of implementations. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From michaelni at gmx.at Tue May 13 11:38:27 2003 From: michaelni at gmx.at (Michael Niedermayer) Date: Tue, 13 May 2003 11:38:27 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305130000.h4D00bjP008972@mail.mplayerhq.hu> References: <200305130000.h4D00bjP008972@mail.mplayerhq.hu> Message-ID: <200305131138.29036.michaelni@gmx.at> Hi On Tuesday 13 May 2003 02:00, Arpi wrote: > Hi, > > > >Not acceptable. This sort of bloated slow startup nonsense is what I > > >expect from stuff like mozilla and gimp, not mplayer! > > > > I didn't say if we have do that scan by loading these plugins. There > > is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and > > put plugins of each type there. Plugins names will be name.so - it may be > > enough but version and validity check (and getting all plugin info) will > > be on loading on demand only. Is it ok? > > plugin names are the same as teh .c file names, but with .so (or .a .dll > etc, it's platform dependent!!!) extenion. so for example, demux_ogg.so, > vf_scale.so > maybe we can include api version number too in some way. an alternative way to quickly get some info (author, helptext, long description ...) about every plugin is to use a cache file, so that only new plugins are checked and then the info is stored in the cache file and loaded from there when needed in a subsequent run ... the advantage is that a GUI could quickly display the helptext or longdesc for example as a tooltip for the list of filters ... [...] -- Michael screen[y][x] ^= cursor[cy][cx]; (violates patent #4,197,590) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en From andrej at lucky.net Tue May 13 12:06:40 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 13:06:40 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305130904.h4D94cRE005060@mail.mplayerhq.hu> References: <20030513081233.GP80451@lucky.net> <200305130904.h4D94cRE005060@mail.mplayerhq.hu> Message-ID: <20030513100640.GC82210@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 13 at 11:29) I've received something... >> Get rid of your bad spirit - join a party, go to the nature, see the >> nice movie, etc. - do what you want. :) It's bad to be in bad mood. :) >you're right... So go for it! :) >> BTW, I already tired of all that - you're saying your thought, I'm >> trying to do it, asking for details, you're aborting what you said before >> - if that will keep forever, I'll just give up. I really tired, sorry. :( >instead of running to implement every sentence i said, we should first >discuss the goals and the possible ways of implementation, then select the >one that everyone accepts. this way no complaints later, or they can be >silently ignored ;) >i'm thinking about several things, i'll collect and write down it here at >afternoon, after work. >the problem was(is) that i don't really see what an UI/GUI needs, but you >and others already help a lot by telling these, and posisble problems which >may arrise if we go for my way of implementations. BTW, I've already spent enough the time to understand concept of UI there. UI (being it commandline parser, streaming server, text ui or gui) is one of the most valuable parts of any application. I'll attempt to describe what I mean. When we start application, it does: 1) prepare context; 2) setup all configuration: - check availability of components (list of codecs/modules/etc.); - load config variables if available; 3) main loop: - run parser/UI, get what you want to do; - run play/encode/etc. - in depent what command was get by parser/UI; - continue; You can easily check out it's what MPlayer or MEncoder (or something else in the future) exactly does. And it's conceptual (may be for any application in the world at all too:) - so parser/UI _always_ is first and execution (play/encode/start/stop/exit) is second stage of the main loop. So any application has to have appropriate input parser (I've even called it control before) and it is integral part of that application. For example, MPlayer has two parsers - config and commandline, gui-driven player has also two - config and Gui, some tools may have one or three or even more. So don't forget about that - we _really_ need a strong API for that, it have to get context of main loop to pass it to second stage after parsing and that context has to have own configuration (since that application may have more than one main loop). Also note that owner of context is main loop, first stage will change all in it, second stage will apply the changes. It's the main concept of applications we get before, now, and further. I hope I've helped you again. :) With best wishes. Andriy. From andrej at lucky.net Tue May 13 12:20:39 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 13:20:39 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305131138.29036.michaelni@gmx.at> References: <200305130000.h4D00bjP008972@mail.mplayerhq.hu> <200305131138.29036.michaelni@gmx.at> Message-ID: <20030513102039.GD82210@lucky.net> Hi, Michael Niedermayer! Sometime (on Tuesday, May 13 at 12:38) I've received something... >> > >Not acceptable. This sort of bloated slow startup nonsense is what I >> > >expect from stuff like mozilla and gimp, not mplayer! >> > I didn't say if we have do that scan by loading these plugins. There >> > is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and >> > put plugins of each type there. Plugins names will be name.so - it may be >> > enough but version and validity check (and getting all plugin info) will >> > be on loading on demand only. Is it ok? >> plugin names are the same as teh .c file names, but with .so (or .a .dll >> etc, it's platform dependent!!!) extenion. so for example, demux_ogg.so, >> vf_scale.so >> maybe we can include api version number too in some way. >an alternative way to quickly get some info (author, helptext, long >description ...) about every plugin is to use a cache file, so that only new >plugins are checked and then the info is stored in the cache file and loaded >from there when needed in a subsequent run ... >the advantage is that a GUI could quickly display the helptext or longdesc for >example as a tooltip for the list of filters ... Good. I think it's the best solution - we just have to save some file's parameters in the cache and rescan on demand if some file was added/changed/removed. It will solve all problems (about info and/or validating), I hope. Andriy. From andrej at lucky.net Tue May 13 13:34:04 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 14:34:04 +0300 Subject: [MPlayer-G2-dev] Re: core API - was G2 CLI/GUI In-Reply-To: <200305122215.56840.pnis@coder.hu> References: <200305121829.h4CIT5Hx025897@mail.mplayerhq.hu> <200305122215.56840.pnis@coder.hu> Message-ID: <20030513113404.GA7732@lucky.net> Hi, Balatoni Denes! Sometime (on Monday, May 12 at 23:18) I've received something... >> you have to define the options in the filters, ao/vo plugins, demuxers, >> so the external (G)UI will know what kind of parameters and how it can pass >> to the layers. >> in g2 core it only means a struct definition and such struct filled with >> data inside the modules/plugins. >That sounds good indeed. >To summarize (for myself at least) all plugins should have functions like this >(perhaps trough control() fn or just function pointers or whatever you are >thinking): >parameters * get_available_parameters_and_their_defaults() it's the structure plugin->opts, no need for extra API. >instance* new_plugin_instance(parameters*) I've called it pl_get_plugin() but parameters will be set later by calling some cfg_parse_params() - see Arpi's letter. >int put_parameters_and_reinit_(instance*, parameters*) Something alike vf->control(vf,VFCTRL_SET_PARAMS). If we will unify all common modules fields then it may be plugin->control(). >int message_to_plugin(instance*, int message id, void * parameters) It already exists - it's control() for af and vf. >int do_stuff_the_plugin_is_for(instance* ) >+functions specific to plugin type It's very specific - see video/vf.h and audio/libaf/af.h for example. >---------------------------------- >And g2 core would have functions roughly like this: >mplayer_init() No. Init will do main() function - it's too application specific. >plugin** get_available_plugins_and_parameters() All modules list must be in UI-independent config tree to be available for UI so we don't need that API. >/*** stuff for playback ***/ >/* returns title, author, length, suggested demuxer, audio/video codec + >parameters, suggested vo ao, filterchains */ >info* mplayer_get_info_about_medium(URL) >/* URL, demuxer wanted , different filterchainf + filter's parameters, vo ao > */ >medium* mplayer_open_medium(info * ) >/* decode to selected ao+vo with the options set*/ >int mplayer_decode_n_frames(medium* , frame number) >/* some usefull functions needed during playback by an ui */ >int mplayer_seek(medium*) >int mplayer_get_playback_status(medium*) /* time,pos etc */ >int mplayer_send_message(plugin*, messageid, msg_parameter*) /* if ui eg. >wants to put something on the OSD, or move the subtitle down */ Bad - it seems to be very mplayer specific. >/*** stuff for customizing info structure ***/ >/* manipulate (append, insert, remove, check, set filter/options) >audio/video/osd/whatever filterchain or separate plugin(if not in any chain) >for an opened medium */ >mplayer_fuck_with_filterchain(info * , chain_id ) >mplayer_fuck_with_plugin(info *, A_PLUGIN_THAT_IS_NOT_IN_ANY_CHAIN) It's the subject of argues now, I don't know that yet. It seems you don't have any solution so just wait until we get agreement with that API, please. Andriy. From andrej at lucky.net Tue May 13 14:11:52 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 15:11:52 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305130904.h4D94cRE005060@mail.mplayerhq.hu> References: <20030513081233.GP80451@lucky.net> <200305130904.h4D94cRE005060@mail.mplayerhq.hu> Message-ID: <20030513121152.GA23709@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 13 at 11:29) I've received something... >i'm thinking about several things, i'll collect and write down it here at >afternoon, after work. There are mine goals to design UI/parser API: 1) Application (and UI) can depend on core API but any of core libs can never have any dependencies on UI (so UI/parser API must be modules and UI/parser independent). 2) UI/parser API must support many contexts with many streams. 3) Each context/stream may have own config tree (but config tree may be shared between many contexts or inherited). 4) UI/parser API must support many UI/parser instances. 5) UI/parser API has to be as simple as possible (at most 2-3 structures and 3-5 functions). 6) Common options tree must contain full information for creating menu (in Gui) or help (in commandline parser). All these goals are reachable together and even by the different ways. :) I just wait yours (and other's, of course, but it seems we need this the most) goals to discuss and decide which way we will go. With best wishes. Andriy. From albeu at free.fr Tue May 13 14:51:13 2003 From: albeu at free.fr (Alban Bedel) Date: Tue, 13 May 2003 14:51:13 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> Message-ID: <20030513145113.670fa188.albeu@free.fr> Hi Arpi, on Mon, 12 May 2003 20:25:46 +0200 you wrote: > Albeu? :)))))))) Until now all i read here don't seems really new. What you describe with passing struct is alredy possible with the API avaible in G1 (m_struct_t). I know that you don't like the stuff i putted in for the vf. To be honest i don't find it so good either. The problem with G1 vf's atm is to get away from the old method (ie passimg string to the vf) to the new method (passing struct with the data in 'C format'). I intend to improve that in G1 so that no more string are passed to libmpcodec and that it doesn't touch priv anymore. Atm string 2 struct is done in vf.c wich is BAD, this should be moved up to the config parser. Now for G2 imho you are right that 'objects' (or module or whatever) should export a description of the struct they need as param. But imho 'objects' should also put the definition of this struct in a public header so they are fully useable without needing to use the 'option API' (for those who don't want to). For the dlopened stuff it's a bit more tricky. A GUI could load the objects as needed, no problem. But for a CLI you need to know all parameters when parsing the command line otherwise you can't check if the parameters are valid or not. It would still be possible to load the stuff as they are needed but that would be more a pain than anything else. Anyway i think we should stay away from the idea of registering and just have the 'objects' export the definition (wich then may or may not be used by the user of the objects). Concerning the API avaible in G1 i would say that i pretty satisfied with the overall design. By this i mean having the options parser completly independent of the rest. But the m_option implementation is tailored for the m_config system wich is bad for G2. Imho options parser (ie string 2 C value) should be rewriten with a better (ie simpler, cleaner) API for general use. Then writing something like m_struct to setup struct instead of vars is really easy. So in short my pov is that we don't need something really new. The concepts needed are all alredy avaible in G1 but their implementation herit the whole G1 history (ie backward compat. needs, etc) wich make the code unusable for G2 but a good part of it could be resused to create a better, cleaner API wich don't have all the m_config crap. After all if each instance of a module get his own struct their is really no need for the 'context saving' (ie m_config) wich is required by G1. Albeu From andrej at lucky.net Tue May 13 15:34:45 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 16:34:45 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030513145113.670fa188.albeu@free.fr> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030513145113.670fa188.albeu@free.fr> Message-ID: <20030513133445.GA45056@lucky.net> Hi, Alban Bedel! Sometime (on Tuesday, May 13 at 16:08) I've received something... >> Albeu? :)))))))) >Until now all i read here don't seems really new. What you describe with >passing struct is alredy possible with the API avaible in G1 (m_struct_t). >I know that you don't like the stuff i putted in for the vf. To be honest >i don't find it so good either. The problem with G1 vf's atm is to get >away from the old method (ie passimg string to the vf) to the new method >(passing struct with the data in 'C format'). >I intend to improve that in G1 so that no more string are passed to >libmpcodec and that it doesn't touch priv anymore. Atm string 2 struct >is done in vf.c wich is BAD, this should be moved up to the config >parser. >Now for G2 imho you are right that 'objects' (or module or whatever) >should export a description of the struct they need as param. But imho >'objects' should also put the definition of this struct in a public >header so they are fully useable without needing to use the >'option API' (for those who don't want to). >For the dlopened stuff it's a bit more tricky. A GUI could load the ^^^^^^ it's the keyword Albeu, I'm sorry for all, but you don't get the main goal. Main goal is don't use any tricks and don't create too much API calls, it's very unwanted behavior. Just count number of structs and functions in your m_* stuff and you'll understand what I mean. And read my demands that I wrote here before, please. >objects as needed, no problem. But for a CLI you need to know all >parameters when parsing the command line otherwise you can't >check if the parameters are valid or not. It would still be possible >to load the stuff as they are needed but that would be more a pain >than anything else. Anyway i think we should stay away from the idea >of registering and just have the 'objects' export the definition >(wich then may or may not be used by the user of the objects). >Concerning the API avaible in G1 i would say that i pretty satisfied >with the overall design. By this i mean having the options parser >completly independent of the rest. But the m_option implementation >is tailored for the m_config system wich is bad for G2. Where you can find all options list? How do you plan add or remove options from that list? I could ask these questions more and more and your implementation doesn't solve any of these problems. Please, don't tell us your implementation is the best, we are about to create an API which will satisfy all our demands and allow us reach all our goals. When it ready then (and only then) we will speak about implementation of the parsers (your m_* stuff is really only config parser implementation). You can write own (based on that API, of course), I can write own - only Arpi will decide which is better anyway. ;) All you can do for now - say your demands and goals, we all will discuss these. So I did. With best regards. Andriy. From albeu at free.fr Tue May 13 17:10:02 2003 From: albeu at free.fr (Alban Bedel) Date: Tue, 13 May 2003 17:10:02 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030513133445.GA45056@lucky.net> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030513145113.670fa188.albeu@free.fr> <20030513133445.GA45056@lucky.net> Message-ID: <20030513171002.4eaff678.albeu@free.fr> Hi Andriy N. Gritsenko, on Tue, 13 May 2003 16:34:45 +0300 you wrote: > Hi, Alban Bedel! > > Sometime (on Tuesday, May 13 at 16:08) I've received something... > >> Albeu? :)))))))) > > >Until now all i read here don't seems really new. What you describe > >with passing struct is alredy possible with the API avaible in G1 > >(m_struct_t). I know that you don't like the stuff i putted in for the > >vf. To be honest i don't find it so good either. The problem with G1 > >vf's atm is to get away from the old method (ie passimg string to the > >vf) to the new method(passing struct with the data in 'C format'). > >I intend to improve that in G1 so that no more string are passed to > >libmpcodec and that it doesn't touch priv anymore. Atm string 2 struct > >is done in vf.c wich is BAD, this should be moved up to the config > >parser. > > >Now for G2 imho you are right that 'objects' (or module or whatever) > >should export a description of the struct they need as param. But imho > >'objects' should also put the definition of this struct in a public > >header so they are fully useable without needing to use the > >'option API' (for those who don't want to). > > >For the dlopened stuff it's a bit more tricky. A GUI could load the > ^^^^^^ it's the keyword > > Albeu, I'm sorry for all, but you don't get the main goal. Main goal > is don't use any tricks and don't create too much API calls, it's very > unwanted behavior. Just count number of structs and functions in your > m_* stuff and you'll understand what I mean. And read my demands that I > wrote here before, please. Here are your goals : 1) independency from all other API; 2) independency from any parsers/UI impementation; 3) no global static vars (since all may have many instances); So what you want is just a fully passive descriptions of the options with no API provided to set them or what ? It may make sense but for the final users of the lib it 'may' be nice if they have a way to automatically convert user input (ie string) to the final c type without having to know anything from the underlying process. Anyway don't dream. If an apps should be able setup some struct in an easy way but without having the definition at compile time you need to provide some API otherwise it'll be a pain as C isn't provinding any kind of introspection. > > >objects as needed, no problem. But for a CLI you need to know all > >parameters when parsing the command line otherwise you can't > >check if the parameters are valid or not. It would still be possible > >to load the stuff as they are needed but that would be more a pain > >than anything else. Anyway i think we should stay away from the idea > >of registering and just have the 'objects' export the definition > >(wich then may or may not be used by the user of the objects). > > >Concerning the API avaible in G1 i would say that i pretty satisfied > >with the overall design. By this i mean having the options parser > >completly independent of the rest. But the m_option implementation > >is tailored for the m_config system wich is bad for G2. > > Where you can find all options list? Imho we don't need a global list of all options avaible. Just a way to retrive the options for this or that specific module, no more is needed in G2 lib. > How do you plan add or remove options from that list? As i said imho no list is needed, so no need to add/remove. > I could ask these questions more and more and > your implementation doesn't solve any of these problems. Please, don't > tell us your implementation is the best, we are about to create an API > which will satisfy all our demands and allow us reach all our goals. Pls can you point me to the place where i wrote that my implementation is the best ? I said this : > >Concerning the API avaible in G1 i would say that i pretty satisfied > >with the overall design. ^^^^^^^^^^^^^^^^^^ I would never dare to say that it's well implemented, but i'm satisfied by the fact that now option parsing (ie string 2 C), context saving (ie m_config) and command line/ config file parsing are well separated and no more 100% inter dependant as it was before. > When it ready then (and only then) we will speak about implementation of > the parsers (your m_* stuff is really only config parser > implementation). Yes and no. It was writed FOR a config parser and G1 design (ie global vars evrywhere) doesn't help to make multifile settings simple (hence the whole m_config stuff and too much complexity in m_option). But i really think that a whole bunch of the idea (and experience) that are in there can be reused. For example string 2 C conversion in a generic way is imho a good idea as it would help a lot CLI writers. On the other hand GUI writers may prefer to know the C type behind a specific option and directly access the struct field. > You can write own (based on that API, of course), I can > write own - only Arpi will decide which is better anyway. ;) > All you can do for now - say your demands and goals, we all will > discuss these. So I did. Pls stop this nonsense. I'm not fighting against you or anything of that kind. I refused some of your patchs. So what ? Does that mean that i'm your ennemy now ?? Albeu From dalias at aerifal.cx Tue May 13 17:22:06 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 13 May 2003 11:22:06 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513081233.GP80451@lucky.net> References: <20030513003030.GM80451@lucky.net> <200305130623.h4D6NREG016404@mail.mplayerhq.hu> <20030513081233.GP80451@lucky.net> Message-ID: <20030513152206.GY23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 11:12:33AM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Tuesday, May 13 at 8:48) I've received something... > >> Ok. How do you propose to pass what of streams do you want to > >> configure from UI to vf,etc. ? Using statics for it isn't acceptable - > >> you are one who wants to avoid statics. You may have many streams (for > >> example, 3 mixed videos and 2 audios from different files) and you have > >> to configure each of it. If you want to dislike all I've proposed there > >> then, please, tell me the other way. But we __have__ to pass some stream > >> pointer from UI/parser to vf_open_filter(). Or you want to give up the > >> multistreaming idea, eh? > > >have you ever looked at test-play.c ? > > >no streams and such things passed (directly) to vf_open_plugins() > >yes it's passed to vf_open_filter when opening special filter "vd" > > Yes, I've seen test-play.c many times, it has: > > static char** video_driver_list=NULL; > static char** video_filter_list=(char**) NULL; > etc. > > With that statement you will never can get more than one video stream > (the same for audio) - you just fixed yourself on the one and it's all. > You want to live with that limitation forever? I don't want but you let > me change nothing, unfortunately. Arrg, stop and think for a moment before saying more such nonsense!!! This is a limitation of the particular (TEST!!) player, not the API. There's no reason your config code should know or care if the calling program is using a static pointer to a single chain, or some sort of multi-chain multi-context approach. > >> >> So with that API we will get what you want and UI will create chain > >> >> by itself. Each time any UI/parser can parse input in only one stream > >> >> context, isn't it? Initiating new filter will work in order: > >> >> 1) parse input in current stream context (directly from Gui or for > >> >> current input file/sid from config parser); > >> > >> UI/config parser have to parse it's input, isn't it? What's wrong? > >> > >> >> 2) load loadable plugin if need and get it's config structure; > >> > >> If we have that plugin loadable then how we can call open() if we > >> don't dlopen() it? What's wrong? > > >why do you want to call its open() in config level? > > See what I've said above. Only parser can tell you if you need to > load that plugin or not. Anyway I've described then _not config_ work but > all plugin load sequence - no difference who will call it in details, or > test-play.c, or something else. Yes, there is a difference. The config code should just set variables, not load/initialize plugins. You're getting delusions of godhood here... The config code is not the centerpiece of mplayer! Rich From dalias at aerifal.cx Tue May 13 17:26:11 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 13 May 2003 11:26:11 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030513102039.GD82210@lucky.net> References: <200305130000.h4D00bjP008972@mail.mplayerhq.hu> <200305131138.29036.michaelni@gmx.at> <20030513102039.GD82210@lucky.net> Message-ID: <20030513152611.GZ23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 01:20:39PM +0300, Andriy N. Gritsenko wrote: > Hi, Michael Niedermayer! > > Sometime (on Tuesday, May 13 at 12:38) I've received something... > >> > >Not acceptable. This sort of bloated slow startup nonsense is what I > >> > >expect from stuff like mozilla and gimp, not mplayer! > >> > I didn't say if we have do that scan by loading these plugins. There > >> > is other way - to create /usr[/local]/lib/mplayer/{ctl,vo,vf} subdirs and > >> > put plugins of each type there. Plugins names will be name.so - it may be > >> > enough but version and validity check (and getting all plugin info) will > >> > be on loading on demand only. Is it ok? > > >> plugin names are the same as teh .c file names, but with .so (or .a .dll > >> etc, it's platform dependent!!!) extenion. so for example, demux_ogg.so, > >> vf_scale.so > >> maybe we can include api version number too in some way. > > >an alternative way to quickly get some info (author, helptext, long > >description ...) about every plugin is to use a cache file, so that only new > >plugins are checked and then the info is stored in the cache file and loaded > >from there when needed in a subsequent run ... > > >the advantage is that a GUI could quickly display the helptext or longdesc for > >example as a tooltip for the list of filters ... > > Good. I think it's the best solution - we just have to save some > file's parameters in the cache and rescan on demand if some file was > added/changed/removed. It will solve all problems (about info and/or > validating), I hope. I hope this 'feature' will be an optional part of the api, and limited to gui players, since it's useless for command line. Rich From andrej at lucky.net Tue May 13 17:56:52 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 18:56:52 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI In-Reply-To: <20030513171002.4eaff678.albeu@free.fr> References: <20030512172208.GD80451@lucky.net> <200305121825.h4CIPkUg022622@mail.mplayerhq.hu> <20030513145113.670fa188.albeu@free.fr> <20030513133445.GA45056@lucky.net> <20030513171002.4eaff678.albeu@free.fr> Message-ID: <20030513155652.GA84617@lucky.net> Hi, Alban Bedel! Sometime (on Tuesday, May 13 at 18:12) I've received something... >> Albeu, I'm sorry for all, but you don't get the main goal. Main goal >> is don't use any tricks and don't create too much API calls, it's very >> unwanted behavior. Just count number of structs and functions in your >> m_* stuff and you'll understand what I mean. And read my demands that I >> wrote here before, please. >Here are your goals : >1) independency from all other API; >2) independency from any parsers/UI impementation; >3) no global static vars (since all may have many instances); >So what you want is just a fully passive descriptions of the options with >no API provided to set them or what ? It may make sense but for the final >users of the lib it 'may' be nice if they have a way to automatically >convert user input (ie string) to the final c type without having >to know anything from the underlying process. >Anyway don't dream. If an apps should be able setup some struct in an easy >way but without having the definition at compile time you need to >provide some API otherwise it'll be a pain as C isn't provinding any >kind of introspection. I don't dreaming. All I want is really reachable. And by more that one way. API will solve all possible problems. It's why we speak about it. :) >> >Concerning the API avaible in G1 i would say that i pretty satisfied >> >with the overall design. By this i mean having the options parser >> >completly independent of the rest. But the m_option implementation >> >is tailored for the m_config system wich is bad for G2. >> >> Where you can find all options list? >Imho we don't need a global list of all options avaible. Just a way to >retrive the options for this or that specific module, no more is needed >in G2 lib. All options must be available. For Gui, for example, and for config parser, for other example. Or you want create for each application its own option list? You have that a mess in G1's Gui. Thank you but I don't like it at all. Just read the thread - all want have all options to be available at certain point. Unfortunately, cfg_t (aka struct config) is auto or static so we cannot reallocate it to manage it's child pointer. Another way may be to have some list of configs to scan it all but it's a bad way. >> How do you plan add or remove options from that list? >As i said imho no list is needed, so no need to add/remove. Disagree, and not only me but others too - see the thread. >> You can write own (based on that API, of course), I can >> write own - only Arpi will decide which is better anyway. ;) >> All you can do for now - say your demands and goals, we all will >> discuss these. So I did. >Pls stop this nonsense. I'm not fighting against you or anything of that >kind. I refused some of your patchs. So what ? Does that mean that i'm >your ennemy now ?? I'm sorry if you misunderstood me. I don't have you as enemy. Just I have other point of view to config means so we could not get a consent. We are just kind of competitors and I hope it will make our work much better. :) With the best wishes. Andriy. From andrej at lucky.net Tue May 13 19:20:02 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 20:20:02 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513152206.GY23552@brightrain.aerifal.cx> References: <20030513003030.GM80451@lucky.net> <200305130623.h4D6NREG016404@mail.mplayerhq.hu> <20030513081233.GP80451@lucky.net> <20030513152206.GY23552@brightrain.aerifal.cx> Message-ID: <20030513172002.GA2778@rep.kiev.ua> Hi, Rich! Sometime (on Tuesday, May 13 at 18:41) I've received something... >Arrg, stop and think for a moment before saying more such nonsense!!! >This is a limitation of the particular (TEST!!) player, not the API. >There's no reason your config code should know or care if the calling >program is using a static pointer to a single chain, or some sort of >multi-chain multi-context approach. Yes, you agree with me - we have to don't use static pointer but some pointer in the structure for some stream and create a good API. :))))))) >> >why do you want to call its open() in config level? >> See what I've said above. Only parser can tell you if you need to >> load that plugin or not. Anyway I've described then _not config_ work but >> all plugin load sequence - no difference who will call it in details, or >> test-play.c, or something else. >Yes, there is a difference. The config code should just set variables, >not load/initialize plugins. You're getting delusions of godhood >here... The config code is not the centerpiece of mplayer! Config code does the full control of mplayer as well - your mplayer without that config code cannot play anything because it doesn't know what it has to play. :) Ok, it seems you still don't understand what I meant. That behavior is just exception for af/vf since plugin list is very specific sort of config objects. I'll try to explain it with example. For example, you have at some time filter chain: vf_a -> vf_b(1) -> vf_c -> vf_b(2) CLI or GUI has found that it must be rebuilded by inserting vf_n after vf_a. Tell me, what will you do: exit from commandline parser with some exit code or just insert this filter into chain by standard core API call? I think if you exit then you will get a big headache to implement all possible exitcodes support in the mplayer (remember - your condition was to don't call anything from parser), and you have to return into commandline parser to continue after that, it isn't implemented also. Also remember - we have CONF_TYPE_FUNC_FULL already, it's backward call to some core or application function also with standard API. Another examples of similar tasks are: - delete filter vf_c from that chain; - move filter vf_b(2) after vf_a and before vf_b(1); Do you have any suggestions to do it without management of plugins by UI/parser? I want to hear it, tell me, please. With best wishes. Andriy. From arpi at thot.banki.hu Tue May 13 21:35:39 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 13 May 2003 21:35:39 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513172002.GA2778@rep.kiev.ua> Message-ID: <200305131935.h4DJZdIO015780@mail.mplayerhq.hu> Hi, > Config code does the full control of mplayer as well - your mplayer no > without that config code cannot play anything because it doesn't know > what it has to play. :) > Ok, it seems you still don't understand what I meant. That behavior > is just exception for af/vf since plugin list is very specific sort of > config objects. I'll try to explain it with example. > > For example, you have at some time filter chain: > vf_a -> vf_b(1) -> vf_c -> vf_b(2) > > CLI or GUI has found that it must be rebuilded by inserting vf_n after > vf_a. Tell me, what will you do: exit from commandline parser with some > exit code or just insert this filter into chain by standard core API since when does configparser builds the filter chains????????????????? it's total braindamage. > call? I think if you exit then you will get a big headache to implement > all possible exitcodes support in the mplayer (remember - your condition > was to don't call anything from parser), and you have to return into > commandline parser to continue after that, it isn't implemented also. > Also remember - we have CONF_TYPE_FUNC_FULL already, it's backward call > to some core or application function also with standard API. > > Another examples of similar tasks are: > - delete filter vf_c from that chain; there is vf api call for this > - move filter vf_b(2) after vf_a and before vf_b(1); this is nonsense remove and insert it > Do you have any suggestions to do it without management of plugins by > UI/parser? I want to hear it, tell me, please. plugin management by the parser? what a nonsense. what about video decoding by audio filters? :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From andrej at lucky.net Tue May 13 22:26:51 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 13 May 2003 23:26:51 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305131935.h4DJZdIO015780@mail.mplayerhq.hu> References: <20030513172002.GA2778@rep.kiev.ua> <200305131935.h4DJZdIO015780@mail.mplayerhq.hu> Message-ID: <20030513202651.GA40525@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 13 at 22:00) I've received something... >> Do you have any suggestions to do it without management of plugins by >> UI/parser? I want to hear it, tell me, please. >plugin management by the parser? what a nonsense. >what about video decoding by audio filters? :) audio filters cannot decode video but there is vf_open_filter() API to manage filters and that standard API could be called from UI. So there is difference between your samples. :) Ok, I say again - I've found only two ways to parse a command "insert filter vf_n after first filter in video chain" from command line or gui or something else: 1) exit from commandline parser or UI with some exit code to let player insert that filter then continue work of parser/UI; 2) insert this filter into chain by calling vf_open_filter() from UI. Note that if you use gui then you have to execute that immediately and don't wait for start playing or something else so player/encoder/editor could start vf->open() to configure it right after that. Unfortunately, I didn't found other ways beside of these two. If you can point me on some other way - it will be great. Anyway our parser/UI API must allow that. It's why I've started that theme. With the best wishes. Andriy. From dalias at aerifal.cx Tue May 13 23:23:01 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 13 May 2003 17:23:01 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513172002.GA2778@rep.kiev.ua> References: <20030513003030.GM80451@lucky.net> <200305130623.h4D6NREG016404@mail.mplayerhq.hu> <20030513081233.GP80451@lucky.net> <20030513152206.GY23552@brightrain.aerifal.cx> <20030513172002.GA2778@rep.kiev.ua> Message-ID: <20030513212301.GD23552@brightrain.aerifal.cx> On Tue, May 13, 2003 at 08:20:02PM +0300, Andriy N. Gritsenko wrote: > Do you have any suggestions to do it without management of plugins by > UI/parser? I want to hear it, tell me, please. Yes. 1) Inserting and removing filters is not the job of the config engine, aside from preparing the config variables for a filter when it's being added. 2) For initializing a chain, the config system can just take in the string, and return a chain of config structures. The player then proceeds to load and initialize the filters along with the codecs. 3) This is a side-note, but I want to make sure that it's possible for mp g2 to support not just filter chains, but filter trees. For example, we should be able to have two video sources and render them side-by-side, or pip. I'm not thinking just of toy-type things in the player, but rather a professional-quality digital filmmaking environment where you need to do cross-fades, overlay special effects, etc. 4) With that in mind, I think it might make more sense for the config system not to handle filters at all during the initial parsing phase, but just store filter chain strings provided from the command line or whatever. Then, when we get to the relevant file in the playtree, the player can split up the filter chain/tree, load the appropriate filters and connect them, then call the config code *again* with the config strings it has for each filter to initialize them. 5) Perhaps you'll also consider this part of the config code, but it's very different from the main options parser, IMO: There needs to be code somewhere to allow interactive editing of the filter tree, so that a gui interface could let you graphically connect the nodes, or or so that a script-based editing system could add and remove filters as needed during editing. (Perhaps some filters would even want to add and remove filters, e.g. a telecine detect filter removing/adding inverse telecine or interpolative deinterlace filters based on the detected content.) Arpi, comments? Rich From arpi at thot.banki.hu Wed May 14 00:14:53 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 00:14:53 +0200 Subject: [MPlayer-G2-dev] g2 config - restart... Message-ID: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Hi, (pre-note: Andriy please don't offend Albeu, he seems to understand the actual problems and solutions better than you...) Ok I guess we want to much from the config api. Actually wanting _a_ config api is alreayd too much. Better separate it to layers, like the rest of teh code (stream/demuxer/decoder/filter/ao/vo for example). the layers may depend only on eachother. imho the first layer should be a very lowlevel one, as all core libs will depend on it. ye syou read it right, i said depends. and even if you're saying no core dependency on config layer you still defien structs and parameters inside core plugins so you lie :) ok, back to the reality. let's define things: config layer 0 (any better name?): ================================== It's actually only a concept (==documentation) and 2 structs. No code. (why are you surprised? :)) This is teh only layer on which teh core libs may depend. This layer is responsible to tell the library user about teh available options/parameters and their type, valid range. In Albeu's terminology it exports the C-types. One of the structs is the good old (with possible changes to make it better for g2) struct config, aka config_t etc. So that one which you use to define the possible options. The other struct is a very simple struct to keep all info we want to know about a module/plugin/layer. It's inspired by Andriy's common generalized plugin_info thingie. While his idea is basically good, he wanted to generalize the whole instances types (like vf_instance_t), afair. So we could define a common structure to keep the pointers of config_t struct (and related data: pointer to default values struct and struxt size) and as a bonus, it could keep: - type of the module (like: core, stream, demux, vd, ad, vf, af, ao, vo etc) - (short) name of the module - plugin filename (NULL for core and built-in/compiled-in modules) (in first draft i wanted filename to be computable from type+shortname, like type==vf + name==scale -> filename=vf_scale.so, but then i find several nice uses of different plugin names, like multiple versions of the same plugin co-exists, etc) - credits related stuff (maintainer and author name/email/url/whatever) - long (one line?) description (for GUIs and automatic -help screens) Then redesign the current core APIs to base the vf_info_t etc on these structs. Some APIs already have some such info_t structs, so it's easier for them. Each core library should have an array of its built-in (static) modules, and a separate struct describing itself (the library may have "global" parameters, which belongs to the library itself (to control how to fins/ insert plugins or whatever) not to one of its specific plugin! for example, for demuxer layer you have parameters to control the autodetection process (extensionbased, contentbased, forced demuxer, list of preferred ones etc), other example is stream layer's -cache parameter) so what about libdemux exporting plugin_info* demux_core_info and plugin_info** demux_modules_info, and so on for every library. config layer 1: core libs configuration helper functions =============== you may ask now, what about the dinamic (dlopen'ed) plugins? we could write a helper function (probably as part of the config layer core) to scan a whole plugin dir(-structure) and read the above plugin_info structure from each plugin. it could include some kind of cache, as Michael proposed. if the UI (it may be CLI's -vf help kind of option, or GUI's dropdown combobox) needs the list of available modules/plugins, it can additionally call this function to get info about dinamic (optional) plugins. it's fully optional, UI only calls it if it wants, no one (esp. not the config parser!) will call that automatically at startup. also there should be a function to get plugin_info of one named plugin. it could also use the cache, or just dlopen() that plugin. this function could be used by CLI's what directly name the plugin to load (like -vop foobar=1:2:3 means that we should try to load vf_foobar.so) layer 2 will handle the lowlevel parsing, ie. string -> C-type conversions, ========================================= based on config_t structs. it will provide simple functions to parse options from sing and return teh dinamically allocated (cloned from static 'prototype' and the parsed options then overwrite defaults) ((there could be an optional prototype arg of the func, so UI can override the static prototype by some other, like configuration inherited from upper level, aka configtree/playtree)). it should also implement the opposite, ie C-type -> string conversion, for config file saving etc. ===== Ok now we have everything for a lowlevel API, so if we have parameters (in string format!!!) for various plugins, modules (like vo_subdev, vf args, etc) we can do this while building the framework (path of layers) we'll use: - retrieve layer/module/plugin's plugin_info (see layer1's 2nd func) - call layer2's parser func to transfer string to config structure, also do error/syntax checking and handle fatal errors (fail-out) - call the layer/module/plugin open() with the config structure as parameter repeat this for every layer/module initialization. ===== to be continued... :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 00:28:37 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 00:28:37 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030513212301.GD23552@brightrain.aerifal.cx> Message-ID: <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> Hi, > On Tue, May 13, 2003 at 08:20:02PM +0300, Andriy N. Gritsenko wrote: > > Do you have any suggestions to do it without management of plugins by > > UI/parser? I want to hear it, tell me, please. > > Yes. > > 1) Inserting and removing filters is not the job of the config engine, > aside from preparing the config variables for a filter when it's > being added. 1000% aggree > 2) For initializing a chain, the config system can just take in the > string, and return a chain of config structures. The player then > proceeds to load and initialize the filters along with the codecs. 1000% aggree > 3) This is a side-note, but I want to make sure that it's possible for > mp g2 to support not just filter chains, but filter trees. For > example, we should be able to have two video sources and render > them side-by-side, or pip. I'm not thinking just of toy-type things > in the player, but rather a professional-quality digital filmmaking > environment where you need to do cross-fades, overlay special > effects, etc. we (I + dun't remember who, maybe vektor or iive?) already discussed this a little bit. i didn't plan such thing (filter branching) in g2. i said that mayeb in g3... but recently i realized that many users (even including me) wants to see what is being recorded from tv, for example. it's somehting like mplayer+mencoder in one, or in simpler form: libvo support in mencoder. it actually means filter branching, you have to send the same image to both vf_vo2 and ve_something. and if we already implement such thing, free branching is not so far. although it raises several problems, related to DR, slices, colorspace, fps and stride and buffertype autonegitiation... it's far from being trivial to implement, and i want to avoif this extra complexity at this moment. but as g2 is desigend to be clean modular, it will be easy to add later. stream merging is easier a bit, but not much. > 4) With that in mind, I think it might make more sense for the config > system not to handle filters at all during the initial parsing > phase, but just store filter chain strings provided from the > command line or whatever. Then, when we get to the relevant file in > the playtree, the player can split up the filter chain/tree, load > the appropriate filters and connect them, then call the config code > *again* with the config strings it has for each filter to > initialize them. this is what i want, and described in a long mail sent 3 mins ago. > 5) Perhaps you'll also consider this part of the config code, but it's > very different from the main options parser, IMO: There needs to be > code somewhere to allow interactive editing of the filter tree, so it's planned via control() > that a gui interface could let you graphically connect the nodes, > or or so that a script-based editing system could add and remove > filters as needed during editing. (Perhaps some filters would even lol > want to add and remove filters, e.g. a telecine detect filter > removing/adding inverse telecine or interpolative deinterlace > filters based on the detected content.) > > Arpi, comments? see above but i guess stream path merging/splitting and graphedit cannot be expected before g3. first we should cleanup g1 (actually reproduce some parts, port the rest) to have something we can play (and not suck) with. if we define infinite requirements now, we'll never reach any working code. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 00:32:22 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 00:32:22 +0200 Subject: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <200305132232.h4DMWME2029414@mail.mplayerhq.hu> Hi, > > to be continued... :) layer 3 ======= it will handle high-level parsing, ie reading/writting config files, multi-file (config/playtree?) commandline configuration. it could be used as a base of both CLI and GUI players, while the CLI oen may have input (key/mouse/etc) events joined to some config variables, while the gui will have sliders and comboboces for this, but the startup (building the config struct chain, filled by the defaults and overwritten from configfile) and at exit write it back to configfile. i still have some doubts and unclear things about details, esp. about what level of conftrol we may allow here (it will require the ability to laod specified plugings to check their config structs) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From ivan at cacad.com Wed May 14 00:00:34 2003 From: ivan at cacad.com (Ivan Kalvachev) Date: Wed, 14 May 2003 01:00:34 +0300 (EEST) Subject: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <1150.212.116.158.165.1052863234.squirrel@mail.cacad.com> It looks like am too late with my drafts anyway i see that many of the ideas i had have been introdused. Anyway i send it as attachment, maybe there are still good ideas Ivan Arpi said: > Hi, > > (pre-note: Andriy please don't offend Albeu, he seems to understand the > actual problems and solutions better than you...) > > Ok I guess we want to much from the config api. > Actually wanting _a_ config api is alreayd too much. > Better separate it to layers, like the rest of teh code > (stream/demuxer/decoder/filter/ao/vo for example). > > the layers may depend only on eachother. > > imho the first layer should be a very lowlevel one, as all core libs > will depend on it. ye syou read it right, i said depends. > and even if you're saying no core dependency on config layer you still > defien structs and parameters inside core plugins so you lie :) > > ok, back to the reality. let's define things: > > config layer 0 (any better name?): > ================================== > It's actually only a concept (==documentation) and 2 structs. No code. > (why are you surprised? :)) > > This is teh only layer on which teh core libs may depend. > This layer is responsible to tell the library user about teh available > options/parameters and their type, valid range. In Albeu's terminology > it exports the C-types. > > One of the structs is the good old (with possible changes to make it > better for g2) struct config, aka config_t etc. So that one which you > use to define the possible options. > > The other struct is a very simple struct to keep all info we want to > know about a module/plugin/layer. It's inspired by Andriy's common > generalized plugin_info thingie. While his idea is basically good, he > wanted to generalize the whole instances types (like vf_instance_t), > afair. > So we could define a common structure to keep the pointers of config_t > struct (and related data: pointer to default values struct and struxt > size) and as a bonus, it could keep: > - type of the module (like: core, stream, demux, vd, ad, vf, af, ao, vo > etc) - (short) name of the module > - plugin filename (NULL for core and built-in/compiled-in modules) > (in first draft i wanted filename to be computable from > type+shortname, like type==vf + name==scale -> filename=vf_scale.so, > but then i find several nice uses of different plugin names, like > multiple versions of the same plugin co-exists, etc) > - credits related stuff (maintainer and author name/email/url/whatever) > - long (one line?) description (for GUIs and automatic -help screens) > > Then redesign the current core APIs to base the vf_info_t etc on these > structs. Some APIs already have some such info_t structs, so it's easier > for them. > > Each core library should have an array of its built-in (static) modules, > and a separate struct describing itself (the library may have "global" > parameters, which belongs to the library itself (to control how to fins/ > insert plugins or whatever) not to one of its specific plugin! > for example, for demuxer layer you have parameters to control the > autodetection process (extensionbased, contentbased, forced demuxer, > list of preferred ones etc), other example is stream layer's -cache > parameter) > > so what about libdemux exporting plugin_info* demux_core_info and > plugin_info** demux_modules_info, and so on for every library. > > config layer 1: core libs configuration helper functions > =============== > > you may ask now, what about the dinamic (dlopen'ed) plugins? > we could write a helper function (probably as part of the config layer > core) to scan a whole plugin dir(-structure) and read the above > plugin_info structure from each plugin. it could include some kind of > cache, as Michael proposed. if the UI (it may be CLI's -vf help kind of > option, or GUI's dropdown combobox) needs the list of available > modules/plugins, it can additionally call this function to get info > about dinamic (optional) plugins. it's fully optional, UI only calls it > if it wants, no one (esp. not the config parser!) will call that > automatically at startup. > > also there should be a function to get plugin_info of one named plugin. > it could also use the cache, or just dlopen() that plugin. > this function could be used by CLI's what directly name the plugin to > load (like -vop foobar=1:2:3 means that we should try to load > vf_foobar.so) > > layer 2 will handle the lowlevel parsing, ie. string -> C-type > conversions, ========================================= > based on config_t structs. it will provide simple functions to parse > options from sing and return teh dinamically allocated (cloned from > static 'prototype' and the parsed options then overwrite defaults) > ((there could be an optional prototype arg of the func, so UI can > override the static prototype by some other, like configuration > inherited from upper level, aka configtree/playtree)). > > it should also implement the opposite, ie C-type -> string conversion, > for config file saving etc. > > ===== > > Ok now we have everything for a lowlevel API, so if we have parameters > (in string format!!!) for various plugins, modules (like vo_subdev, vf > args, etc) we can do this while building the framework (path of layers) > we'll use: > - retrieve layer/module/plugin's plugin_info (see layer1's 2nd func) - > call layer2's parser func to transfer string to config structure, also > do > error/syntax checking and handle fatal errors (fail-out) > - call the layer/module/plugin open() with the config structure as > parameter > repeat this for every layer/module initialization. > > ===== > > to be continued... :) > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer, the Movie Player for Linux - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configdrafts.txt URL: From dalias at aerifal.cx Wed May 14 06:20:28 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 14 May 2003 00:20:28 -0400 Subject: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <20030514042028.GG23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 12:14:53AM +0200, Arpi wrote: > config layer 0 (any better name?): > ================================== > It's actually only a concept (==documentation) and 2 structs. No code. > (why are you surprised? :)) :)) > so what about libdemux exporting plugin_info* demux_core_info and > plugin_info** demux_modules_info, and so on for every library. You mentioned earlier that perhaps "module" is a better name than "plugin". I agree there! > config layer 1: core libs configuration helper functions > =============== > > you may ask now, what about the dinamic (dlopen'ed) plugins? > we could write a helper function (probably as part of the config layer core) > to scan a whole plugin dir(-structure) and read the above plugin_info > structure from each plugin. it could include some kind of cache, as Michael > proposed. if the UI (it may be CLI's -vf help kind of option, or GUI's > dropdown combobox) needs the list of available modules/plugins, it can > additionally call this function to get info about dinamic (optional) plugins. > it's fully optional, UI only calls it if it wants, no one (esp. not the > config parser!) will call that automatically at startup. Yes, ESPECIALLY not the config parser! :) > layer 2 will handle the lowlevel parsing, ie. string -> C-type conversions, > ========================================= > based on config_t structs. it will provide simple functions to parse options > from sing and return teh dinamically allocated (cloned from static > 'prototype' and the parsed options then overwrite defaults) > ((there could be an optional prototype arg of the func, so UI can override > the static prototype by some other, like configuration inherited from upper > level, aka configtree/playtree)). Yes, I like this idea a lot. It seems to simplify the whole playtree logic greatly. > Ok now we have everything for a lowlevel API, so if we have parameters (in > string format!!!) for various plugins, modules (like vo_subdev, vf args, etc) > we can do this while building the framework (path of layers) we'll use: > - retrieve layer/module/plugin's plugin_info (see layer1's 2nd func) > - call layer2's parser func to transfer string to config structure, also do > error/syntax checking and handle fatal errors (fail-out) > - call the layer/module/plugin open() with the config structure as parameter > repeat this for every layer/module initialization. Nice and clean. Rich From dalias at aerifal.cx Wed May 14 06:30:59 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 14 May 2003 00:30:59 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> References: <20030513212301.GD23552@brightrain.aerifal.cx> <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> Message-ID: <20030514043059.GH23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 12:28:37AM +0200, Arpi wrote: > > 3) This is a side-note, but I want to make sure that it's possible for > > mp g2 to support not just filter chains, but filter trees. For > > example, we should be able to have two video sources and render > > them side-by-side, or pip. I'm not thinking just of toy-type things > > in the player, but rather a professional-quality digital filmmaking > > environment where you need to do cross-fades, overlay special > > effects, etc. > > we (I + dun't remember who, maybe vektor or iive?) already discussed this a > little bit. i didn't plan such thing (filter branching) in g2. > i said that mayeb in g3... > > but recently i realized that many users (even including me) wants to see what > is being recorded from tv, for example. it's somehting like mplayer+mencoder > in one, or in simpler form: libvo support in mencoder. > it actually means filter branching, you have to send the same image to both > vf_vo2 and ve_something. and if we already implement such thing, free > branching is not so far. although it raises several problems, related to DR, > slices, colorspace, fps and stride and buffertype autonegitiation... > it's far from being trivial to implement, and i want to avoif this extra > complexity at this moment. > but as g2 is desigend to be clean modular, it will be easy to add later. > > stream merging is easier a bit, but not much. I'd really like to see this in g2, so do you mind discussing some of the difficulties you see? To me, it seems pretty simple. 1. If a filter has multiple outputs by nature (e.g. splitting fields to process separately, maybe even to encode as two separate files to save disk space), it just runs the config chain for each output path, and it will have to know what to do with each one. 2. If a filter has multiple inputs (e.g. cross fade), it obviously needs to expect a config from each one, and handle them in some sorta sane way. Both of these cases could get messy in some details, but that's a problem for the filter author (mostly), not for the filter architecture. The last case... 3. An ordinary filter with one output (and one or more inputs) needs to be connected to multiple outputs (e.g. to watch tv while recording). ...is a bit tougher. IMO the correct way to handle it is not to handle it. Instead, have a filter vf_tee that takes an input an splits it into multiple outputs. Then vf_tee is responsible for all the logic with handling DR. But, even nicer, we don't have to implement vf_tee to begin with. :)) As long as the overall filter architecture design is ok, it can be done later without affecting anything else. > > that a gui interface could let you graphically connect the nodes, > > or or so that a script-based editing system could add and remove > > filters as needed during editing. (Perhaps some filters would even > lol Well, it sounds a bit ridiculous for simple chains. But for a tree system like I'm talking about, it might be sort of reasonable. You could even consider the case of a graphical editing program, where you tell it to edit/encode for some duration of time, then stop to let you edit the filter chain (to start a new scene or something). Personally, I would want to do this with a script, but I can see how newbies might prefer to have a graphical approach. > but i guess stream path merging/splitting and graphedit cannot be expected > before g3. first we should cleanup g1 (actually reproduce some parts, port > the rest) to have something we can play (and not suck) with. > > if we define infinite requirements now, we'll never reach any working code. I hope we can do it without many requirements on the actual filter system, so it can be added painlessly without another rewrite-from-scratch. Or maybe you intend g3 to be more incremental, as opposed to g2 which is lots of rewrites. Rich From albeu at free.fr Wed May 14 09:18:37 2003 From: albeu at free.fr (Alban Bedel) Date: Wed, 14 May 2003 09:18:37 +0200 Subject: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <200305132232.h4DMWME2029414@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <200305132232.h4DMWME2029414@mail.mplayerhq.hu> Message-ID: <20030514091837.774deb27.albeu@free.fr> Hi Arpi, on Wed, 14 May 2003 00:32:22 +0200 you wrote: > Hi, > To be short I agree completly with everything up to layer 3. > layer 3 > ======= > > it will handle high-level parsing, ie reading/writting config files, > multi-file (config/playtree?) commandline configuration. > it could be used as a base of both CLI and GUI players, while the CLI > oen may have input (key/mouse/etc) events joined to some config > variables, while the gui will have sliders and comboboces for this, but > the startup(building the config struct chain, filled by the defaults and > overwritten from configfile) and at exit write it back to configfile. > > i still have some doubts and unclear things about details, esp. about > what level of conftrol we may allow here (it will require the ability to > laod specified plugings to check their config structs) Yeah layer 3 is bit more tricky. That is we come to a point where the app and the lib 'meet each other' so to say. The advantage of such layer is that various apps could use some common config files for example. It would also make things a lot easyer for loozy/lazy coders. On the other hand some will want xml config file, other simple plain text and so on and so on. As you clearly defined the taks of the other layers, the layer 3 could be some kind of sample/default implementation on how to use the config API. I think that having this part of the G2 lib is needed as a lot of ppl don't want/need to write their own. But it should be simple for an app to use its own stuff at this level. Now imho such sample implementation should be quiet simple so i vote for a playlist and not a playtree. Most of you would probably second that ;) be possible to easely From andrej at lucky.net Wed May 14 09:36:39 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 10:36:39 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> References: <20030513212301.GD23552@brightrain.aerifal.cx> <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> Message-ID: <20030514073638.GA75218@lucky.net> Hi, Arpi! Some words. We must have the concept, which we creating an API for, in the first place. So we are talking about concept now, aren't we? Sometime (on Wednesday, May 14 at 0:52) I've received something... >> 1) Inserting and removing filters is not the job of the config engine, >> aside from preparing the config variables for a filter when it's >> being added. >1000% aggree Don't argue, it may be the best thing. You didn't understand me. I've told not about inserting/removing filters as config engine job but about callback from config engine to core for doing that job by appropriate engine. Only that and nothing more. :) >> 2) For initializing a chain, the config system can just take in the >> string, and return a chain of config structures. The player then >> proceeds to load and initialize the filters along with the codecs. >1000% aggree Ok. I'll try to explain you with an example. You have a Gui encoder. You didn't started encoding yet. You opened dialog box for filters. Are you surprised with that? Do you still think if Gui may only have string input for the filters? If you think so then Gui is just graphic command line for you and users will call us hellmakers. So we are in that dialog box. It consists of two panels: on left we have created filters chain, on the right we have full filters list. What I want (I'm there an user)? I want take a filter in the right pane then drag it in selected place in the left (not only to end of list but in the some place there), drop, and after that doubleclick on it to configure. Any other behavior isn't understandable for me. So our concept _must_ allow that. We _must_ allow get a command from UI to insert or delete filter in the any place then return to UI but don't start encoding yet. Do you understand me? >> 4) With that in mind, I think it might make more sense for the config >> system not to handle filters at all during the initial parsing >> phase, but just store filter chain strings provided from the >> command line or whatever. Then, when we get to the relevant file in >> the playtree, the player can split up the filter chain/tree, load >> the appropriate filters and connect them, then call the config code >> *again* with the config strings it has for each filter to >> initialize them. >this is what i want, and described in a long mail sent 3 mins ago. If we talking about command line interface only then this is ok. For UI it's bad - why user have to close dialog box to let player create all chain then open it again to configure filters? It's hell for the user. Do you want to deny Gui at all or you think Gui isn't like a parser? >> 5) Perhaps you'll also consider this part of the config code, but it's >> very different from the main options parser, IMO: There needs to be >> code somewhere to allow interactive editing of the filter tree, so >it's planned via control() How you plan to use that control() if you disallow UI/parser to know that control() exists? >but i guess stream path merging/splitting and graphedit cannot be expected >before g3. first we should cleanup g1 (actually reproduce some parts, port >the rest) to have something we can play (and not suck) with. OOPS... we plan to deny API for UI before g3? It's too sad, we can die before that and don't see API for UI... :((( All we need is to create an API function to pass these insert/delete commands to vf or af engine. Is that too hard? Only one function will solve all problems so UI can do callback without exiting. Andriy. From dalias at aerifal.cx Wed May 14 09:59:38 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 14 May 2003 03:59:38 -0400 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030514073638.GA75218@lucky.net> References: <20030513212301.GD23552@brightrain.aerifal.cx> <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> <20030514073638.GA75218@lucky.net> Message-ID: <20030514075938.GI23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 10:36:39AM +0300, Andriy N. Gritsenko wrote: > >> 2) For initializing a chain, the config system can just take in the > >> string, and return a chain of config structures. The player then > >> proceeds to load and initialize the filters along with the codecs. > > >1000% aggree > > Ok. I'll try to explain you with an example. You have a Gui encoder. > You didn't started encoding yet. You opened dialog box for filters. Are > you surprised with that? Do you still think if Gui may only have string > input for the filters? If you think so then Gui is just graphic command > line for you and users will call us hellmakers. > So we are in that dialog box. It consists of two panels: on left we > have created filters chain, on the right we have full filters list. What > I want (I'm there an user)? I want take a filter in the right pane then > drag it in selected place in the left (not only to end of list but in the > some place there), drop, and after that doubleclick on it to configure. > Any other behavior isn't understandable for me. > So our concept _must_ allow that. We _must_ allow get a command from > UI to insert or delete filter in the any place then return to UI but > don't start encoding yet. Do you understand me? This has absolutely NOTHING to do with the config layer. It's something for the gui app to implement, based on the available functions in the mplayer lib(s) to list available filters and get configurable properties for them. This last step -- getting the configurable properties -- is the only thing remotely related to the config system, and even then it's only minimally related, for exporting the C variables for the filter config in such a way that the gui knows how to make text boxes, appropriately ranged sliders, etc. > >> 4) With that in mind, I think it might make more sense for the config > >> system not to handle filters at all during the initial parsing > >> phase, but just store filter chain strings provided from the > >> command line or whatever. Then, when we get to the relevant file in > >> the playtree, the player can split up the filter chain/tree, load > >> the appropriate filters and connect them, then call the config code > >> *again* with the config strings it has for each filter to > >> initialize them. > > >this is what i want, and described in a long mail sent 3 mins ago. > > If we talking about command line interface only then this is ok. For > UI it's bad - why user have to close dialog box to let player create all > chain then open it again to configure filters? It's hell for the user. Do > you want to deny Gui at all or you think Gui isn't like a parser? Gui can work perfectly fine with what I described. It just needs to be clueful about stuff. The goal of mplayer g2 is NOT to have idiots writing guis that just make a few calls to your config code and suddenly have "my own movie player". The frontend needs to communicate with all parts of the backend, not just the config system, and as long as it does that, everything will be fine! > >> 5) Perhaps you'll also consider this part of the config code, but it's > >> very different from the main options parser, IMO: There needs to be > >> code somewhere to allow interactive editing of the filter tree, so > > >it's planned via control() > > How you plan to use that control() if you disallow UI/parser to know > that control() exists? OK, since you seem particularly dense tonight, let me spell it out. Suppose your movie is running, with some filter chain, and the user decides to change some filter's options in the gui-toy-thingie. The player has pointers to the elements of the filter chain, since it built the filter chain! So what does it do? It queries the filter (with control(), or something new, whatever) to get the current options exported to it in a structure. Then it displays a panel to let the user modify the options. Then when the user hits apply (or immediately, if desired), the player makes another call to the filter telling it to update one or more options. Nice and simple. Adding and removing of course has nothing whatsoever to do with the config system. > >but i guess stream path merging/splitting and graphedit cannot be expected > >before g3. first we should cleanup g1 (actually reproduce some parts, port > >the rest) to have something we can play (and not suck) with. > > OOPS... we plan to deny API for UI before g3? It's too sad, we can die > before that and don't see API for UI... :((( All we need is to create an > API function to pass these insert/delete commands to vf or af engine. Is > that too hard? Only one function will solve all problems so UI can do > callback without exiting. Huh? What are we talking about now, with callbacks??? Rich From andrej at lucky.net Wed May 14 10:18:28 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 11:18:28 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <20030514081828.GA74687@lucky.net> Hi, Arpi! Sometime (on Wednesday, May 14 at 0:39) I've received something... >(pre-note: Andriy please don't offend Albeu, he seems to understand the >actual problems and solutions better than you...) I want to say it in public: Albeu, please, forgive me if I offended you, I didn't want to offend you a little, I just wanted to have a good config API, it's all. >Ok I guess we want to much from the config api. >Actually wanting _a_ config api is alreayd too much. >Better separate it to layers, like the rest of teh code >(stream/demuxer/decoder/filter/ao/vo for example). [.....] Whole thing is good. But I have some questions to API implementation. 1. Where application and UI will have all options tree? 2. How application or UI will know about all available types of modules? 3. How application or UI/parser will find all available modules of some type? 4. How application or UI/parser will get options of certain module? 5. How open() function will call UI/parser to configure own instance of parameters? 6. How UI/parser can change parameters of certain module in runtime? 7. How UI can tell the core to rebuild (insert/delete module instance) filter chain? I think, it all must be in API documentation, and API must allow that. Any UI maker will ask you the same questions. Gui (or any other UI) _really_ need all these so we cannot deny it. Don't say, please, we should wait to G3 - current G2 can do all this. All we have to do - to create API that will allow that. :) With the best wishes. Andriy. From andrej at lucky.net Wed May 14 10:46:06 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 11:46:06 +0300 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030514075938.GI23552@brightrain.aerifal.cx> References: <20030513212301.GD23552@brightrain.aerifal.cx> <200305132228.h4DMSbEH024911@mail.mplayerhq.hu> <20030514073638.GA75218@lucky.net> <20030514075938.GI23552@brightrain.aerifal.cx> Message-ID: <20030514084606.GB74687@lucky.net> Hi, D Richard Felker III! Sometime (on Wednesday, May 14 at 10:52) I've received something... >This has absolutely NOTHING to do with the config layer. It's >something for the gui app to implement, based on the available So you mean config is just independent layer to parsing only config file(s) or command line but UI is part of player/encoder/something. It's ok. I thought we are speaking about the same thing - common API as for commandline parser as for any UI. If API doesn't touch UI then I see no problems at all - since UI is a part of player/encoder/something, it have rights to use all other (vf/af/ao) API. :) Gui will use some tricks to do all it wants but we don't touch it at the moment. ;) >OK, since you seem particularly dense tonight, let me spell it out. Thank you for the compliment. ;) Andriy. From andrej at lucky.net Wed May 14 11:33:31 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 12:33:31 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <20030514093331.GC74687@lucky.net> Hi, Arpi! Sometime (on Wednesday, May 14 at 0:39) I've received something... >config layer 0 (any better name?): >================================== >It's actually only a concept (==documentation) and 2 structs. No code. >(why are you surprised? :)) I'm not surprised at all. You just splitted all API to layers. It's good and I wanted to make that later. I wrote all layers in one cfg.h because I didn't want to create too many files, it's all. :) BTW, thank you, you've understood most of my thoughts. >The other struct is a very simple struct to keep all info we want to know >about a module/plugin/layer. It's inspired by Andriy's common generalized >plugin_info thingie. While his idea is basically good, he wanted to >generalize the whole instances types (like vf_instance_t), afair. Do you mean all *_instance_t must be thing for application only, not unified? >so what about libdemux exporting plugin_info* demux_core_info and >plugin_info** demux_modules_info, and so on for every library. Fully agree with that. Only question - how application will import these infos? We will implement some registering function or we will see its just as arrays and let application integrate it all in own trees by itself? Other question is how we would implement adding of options from demux_core_info into common list of options? Why I asking that? If we have only main config_t structure then it's a static array so we cannot reallocate it. It's why I proposed to make a structure cfg_tree_t. Sure, it's a structure for layer 2 only and it will be used for parsing and searching, but it will be better than (re)allocate a memory for whole main config_t thing, won't it? With the best wishes. Andriy. From andrej at lucky.net Wed May 14 11:52:48 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 12:52:48 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <20030514095248.GA25102@lucky.net> Hi, Arpi! Sometime (on Wednesday, May 14 at 0:39) I've received something... >layer 2 will handle the lowlevel parsing, ie. string -> C-type conversions, >========================================= It's config/commandline parser layer only since I wonder if something else will use plain text but (Gui for example, or something else) some internal representation of values. Andriy. From arpi at thot.banki.hu Wed May 14 14:29:38 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 14:29:38 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030514043059.GH23552@brightrain.aerifal.cx> Message-ID: <200305141229.h4ECTclR029677@mail.mplayerhq.hu> Hi, > > but i guess stream path merging/splitting and graphedit cannot be expected > > before g3. first we should cleanup g1 (actually reproduce some parts, port > > the rest) to have something we can play (and not suck) with. > > > > if we define infinite requirements now, we'll never reach any working code. > > I hope we can do it without many requirements on the actual filter > system, so it can be added painlessly without another > rewrite-from-scratch. Or maybe you intend g3 to be more incremental, > as opposed to g2 which is lots of rewrites. of course i hope that g2 is teh last rewrite. its main goal is cleanup g1, when needed, by rewrite. when g2 is ready, we can start playing with new ideas, new APIs without having to rewrite code or suck with hacks. btw i already have ideas for g3. (or g2.1) i plan to replace current mpi (mp_image_t with its specialzied MP_IMGTYPEs) by a more generic approach, recently introduced in ffmpeg: get_buffer+release_buffer. currently i see many new problems but also many problems solved, and many other advantages... A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 14:37:11 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 14:37:11 +0200 Subject: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <20030514091837.774deb27.albeu@free.fr> Message-ID: <200305141237.h4ECbBmU004009@mail.mplayerhq.hu> Hi, > > > Hi, > > > To be short I agree completly with everything up to layer 3. hmm, i'm surprised :) > > layer 3 > > ======= > > > > it will handle high-level parsing, ie reading/writting config files, > > multi-file (config/playtree?) commandline configuration. > > it could be used as a base of both CLI and GUI players, while the CLI > > oen may have input (key/mouse/etc) events joined to some config > > variables, while the gui will have sliders and comboboces for this, but > > the startup(building the config struct chain, filled by the defaults and > > overwritten from configfile) and at exit write it back to configfile. > > > > i still have some doubts and unclear things about details, esp. about > > what level of conftrol we may allow here (it will require the ability to > > laod specified plugings to check their config structs) > > Yeah layer 3 is bit more tricky. That is we come to a point where the > app and the lib 'meet each other' so to say. The advantage of such > layer is that various apps could use some common config files for > example. It would also make things a lot easyer for loozy/lazy coders. > On the other hand some will want xml config file, other simple plain > text and so on and so on. > As you clearly defined the taks of the other layers, the layer 3 could > be some kind of sample/default implementation on how to use the config of course! actually the whole g2 is build with layer independency in mind, so any app can left out layers or replace them with its own implementation. it's especially true for the config layer. for a GUI-only app it's enough to use cfg layer 0, and it may use its _own_ xml-based config parser and whatever to handle the options... > API. I think that having this part of the G2 lib is needed as a lot of > ppl don't want/need to write their own. But it should be simple for > an app to use its own stuff at this level. > Now imho such sample implementation should be quiet simple so i vote > for a playlist and not a playtree. Most of you would probably second > that ;) agree A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 14:46:32 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 14:46:32 +0200 Subject: [MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request. In-Reply-To: <20030514073638.GA75218@lucky.net> Message-ID: <200305141246.h4ECkWuc013272@mail.mplayerhq.hu> Hi, > Ok. I'll try to explain you with an example. You have a Gui encoder. > You didn't started encoding yet. You opened dialog box for filters. Are > you surprised with that? Do you still think if Gui may only have string > input for the filters? If you think so then Gui is just graphic command > line for you and users will call us hellmakers. > So we are in that dialog box. It consists of two panels: on left we > have created filters chain, on the right we have full filters list. What > I want (I'm there an user)? I want take a filter in the right pane then > drag it in selected place in the left (not only to end of list but in the > some place there), drop, and after that doubleclick on it to configure. > Any other behavior isn't understandable for me. > So our concept _must_ allow that. We _must_ allow get a command from > UI to insert or delete filter in the any place then return to UI but > don't start encoding yet. Do you understand me? yes, but you don't seem to understand the video filter layer at all. in gui, you build a list (be it a string list or config_t list) of filters and its parameters, but it doesn't mean you call filters' open() at all! you cannot even call filters' open() at this level, you can do it only after tail filter (encoder/vo) is prepared, and teh codec is initializing (the filter chain is opened from the top filter, ie vf_vd, after colorspace etc autonegotiation initiaetd by the codec!) Gui's work is to let user select filters from a combobox (drag'n'drop from right to left in any order, move/remove it from left list etc) but it's about a list of strings, not about actual filter code! At teh end teh gui will pass this array of filters/configs to the video core togethwer with codec info and tail filter (encoder/vo) and get the chain stabilize and open. it's far not the job of any config layer! > >> 4) With that in mind, I think it might make more sense for the config > >> system not to handle filters at all during the initial parsing > >> phase, but just store filter chain strings provided from the > >> command line or whatever. Then, when we get to the relevant file in > >> the playtree, the player can split up the filter chain/tree, load > >> the appropriate filters and connect them, then call the config code > >> *again* with the config strings it has for each filter to > >> initialize them. > > >this is what i want, and described in a long mail sent 3 mins ago. > > If we talking about command line interface only then this is ok. For no > UI it's bad - why user have to close dialog box to let player create all > chain then open it again to configure filters? It's hell for the user. Do > you want to deny Gui at all or you think Gui isn't like a parser? no may i ask such a silly question, too? do you want to implement a whole encoder/player gui called as config layer? > >> 5) Perhaps you'll also consider this part of the config code, but it's > >> very different from the main options parser, IMO: There needs to be > >> code somewhere to allow interactive editing of the filter tree, so > > >it's planned via control() > > How you plan to use that control() if you disallow UI/parser to know > that control() exists? since when i disallow that UI know it? i disallow parser know it, but it's not the job of any parser. parser's job is to do parsing. surprise? > >but i guess stream path merging/splitting and graphedit cannot be expected > >before g3. first we should cleanup g1 (actually reproduce some parts, port > >the rest) to have something we can play (and not suck) with. > > OOPS... we plan to deny API for UI before g3? It's too sad, we can die > before that and don't see API for UI... :((( All we need is to create an > API function to pass these insert/delete commands to vf or af engine. Is > that too hard? Only one function will solve all problems so UI can do > callback without exiting. lol A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 14:57:31 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 14:57:31 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514081828.GA74687@lucky.net> Message-ID: <200305141257.h4ECvV93031961@mail.mplayerhq.hu> Hi, > Sometime (on Wednesday, May 14 at 0:39) I've received something... > >(pre-note: Andriy please don't offend Albeu, he seems to understand the > >actual problems and solutions better than you...) > > I want to say it in public: Albeu, please, forgive me if I offended > you, I didn't want to offend you a little, I just wanted to have a good > config API, it's all. > > >Ok I guess we want to much from the config api. > >Actually wanting _a_ config api is alreayd too much. > >Better separate it to layers, like the rest of teh code > >(stream/demuxer/decoder/filter/ao/vo for example). > > [.....] > > Whole thing is good. But I have some questions to API implementation. > > 1. Where application and UI will have all options tree? where they store it, probably in memory... :) > 2. How application or UI will know about all available types of modules? app/ui author will read g2 framework layout documentation, so he will know that there are ao, vo, ad, vd, af, vf etc. He already have to know what he have and what he can use... > 3. How application or UI/parser will find all available modules of some > type? see layer 1 func 1 > 4. How application or UI/parser will get options of certain module? see layer 1 func 2 > 5. How open() function will call UI/parser to configure own instance of > parameters? heh? app/ui/layer3 will call filter's open after called the config parser (layer2). > 6. How UI/parser can change parameters of certain module in runtime? control() as you wrote days ago btw also see iive's draft, it has some nice ideas, esp. around runtime config > 7. How UI can tell the core to rebuild (insert/delete module instance) > filter chain? see vf.h > I think, it all must be in API documentation, and API must allow that. yes the missunderstanding is only what API filter insertion/deletion is part of filter api, not config api > Any UI maker will ask you the same questions. Gui (or any other UI) > _really_ need all these so we cannot deny it. Don't say, please, we > should wait to G3 - current G2 can do all this. All we have to do - to > create API that will allow that. :) sure A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 15:06:09 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 15:06:09 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514093331.GC74687@lucky.net> Message-ID: <200305141306.h4ED69mV007218@mail.mplayerhq.hu> Hi, > >The other struct is a very simple struct to keep all info we want to know > >about a module/plugin/layer. It's inspired by Andriy's common generalized > >plugin_info thingie. While his idea is basically good, he wanted to > >generalize the whole instances types (like vf_instance_t), afair. > > Do you mean all *_instance_t must be thing for application only, not > unified? yes it's lib/layer dependent, and it's internal thing of layers. > >so what about libdemux exporting plugin_info* demux_core_info and > >plugin_info** demux_modules_info, and so on for every library. > > Fully agree with that. Only question - how application will import > these infos? We will implement some registering function or we will see > its just as arrays and let application integrate it all in own trees by > itself? yes. they can call resgistering func for each libs/layers they use at startup or just handle them so. in a GUI, you don't have a single list of all plugins, but will have panels/windows, one for each layer (like: Video filter configuration panel) so you need list of modules of one type. you don't even need to check for types, you have one list for each type. > Other question is how we would implement adding of options from > demux_core_info into common list of options? Why I asking that? If we > have only main config_t structure then it's a static array so we cannot > reallocate it. It's why I proposed to make a structure cfg_tree_t. Sure, > it's a structure for layer 2 only and it will be used for parsing and > searching, but it will be better than (re)allocate a memory for whole > main config_t thing, won't it? yes it's the job of layer 3, what i'm working on (desigm. not code) right now sure it will not be realloc, but some kind of tree. i can imagien a single config_t which have links to other config_t structs (even to the plugins) like subconfigs, with some new special types. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 14 15:07:32 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 15:07:32 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514095248.GA25102@lucky.net> Message-ID: <200305141307.h4ED7WW4008686@mail.mplayerhq.hu> Hi, > Sometime (on Wednesday, May 14 at 0:39) I've received something... > > >layer 2 will handle the lowlevel parsing, ie. string -> C-type conversions, > >========================================= > > It's config/commandline parser layer only since I wonder if something > else will use plain text but (Gui for example, or something else) some > internal representation of values. yes i said exactly the same, did you read my mail with closed eyes? guis need no more than layer 0+1 layer2+3 are for configfiles/commandlines. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From saschasommer at freenet.de Wed May 14 15:45:02 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Wed, 14 May 2003 15:45:02 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out References: <200305112045.h4BKj22X017589@mail.mplayerhq.hu> Message-ID: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> > Hi, > > > Hi, > > just small comment to interface > > -frame_start,frame_done.... should return VO_XXXX depending on > > succes/fail > > > > Another question is about plane pointers in buffer structure. Are they > > considered valid all the time? This will not be true for some vo > > drivers. For example directfb - valid pointers are supplied only between > > frame_start and frame_done when surface/buffer is locked. All the rest > > of the time buffers can be moved without any notification. > > huh. > i've expected that they are constant since the config() call, but the code > doesn't expect it, so it should work. > actually the buffers are read/write only between frame_start/frame_done, > so otherwise the pointers aren't used. it's better to set them NULL at > config and frame_done, for easier bug hunting :) > > maybe it requires changes in vf_vo2's get_image(), as the stride is required > for DR1 decisions, and afair it's done before frame_start. > Hm will stride change in directfb? According to msdn for directx only the memory pointers will become invalid when the buffer gets unlocked. The stuff described above works at least for me. Only if scale gets autoinseted things go mad (calling frame_done twice, one time with buffer == 0x0 and accessing planes[1] for RGB etc.). I guess those are known issues. Another question is about VOCTRL_RESIZE_DEST and VOCTRL_RESIZE_SRC. What should I do, If I can't handle it, for example if my driver requires some minimum stretch factor. Do you have a solution for this? If not, would it be possible to set vo->x ,y w and h to valid ones and return VO_FALSE? Other limitations would be that card can only size down to a fixed height or some alignment restriction etc. Sascha From arpi at thot.banki.hu Wed May 14 16:39:01 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 16:39:01 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> Message-ID: <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> Hi, > > huh. > > i've expected that they are constant since the config() call, but the code > > doesn't expect it, so it should work. > > actually the buffers are read/write only between frame_start/frame_done, > > so otherwise the pointers aren't used. it's better to set them NULL at > > config and frame_done, for easier bug hunting :) > > > > maybe it requires changes in vf_vo2's get_image(), as the stride is > required > > for DR1 decisions, and afair it's done before frame_start. > > > > Hm will stride change in directfb? According to msdn for directx only > the memory pointers will become invalid when the buffer gets unlocked. > The stuff described above works at least for me. Only if scale gets > autoinseted > things go mad (calling frame_done twice, one time with buffer == 0x0 and > accessing > planes[1] for RGB etc.). > I guess those are known issues. yes as i told you on irc, filter autoinsertion is broken now, since vf_vd.c (i have to port some code from vd.c to vf_vd.c, and implement vf->priv setting at every place where filter insertion/removal happens) > Another question is about VOCTRL_RESIZE_DEST and VOCTRL_RESIZE_SRC. > What should I do, If I can't handle it, for example if my driver requires > some minimum stretch factor. > Do you have a solution for this? If not, would it be possible to set vo->x > ,y w and h to valid ones and return VO_FALSE? hmm don't touch vo->values, but if you cannot accept the values given, change the args (it's an int[]) and return VO_FALSE. > Other limitations would be that card can only size down to a fixed height or > some alignment > restriction etc. resize_dest is to handle window resizing/movement events. resize_src is to handle special effects like panscan or zooming. in both cases it's acceptable if you cannot exactly set the given params, but something else (close values). i just don't knowwhich is better: - change args[] and return VO_FALSE - set vo->* to what we can, and actually do the operation (resize) and return TRUE A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From andrej at lucky.net Wed May 14 18:15:39 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 19:15:39 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> Message-ID: <20030514161538.GA9528@lucky.net> Hi, Arpi! So I misunderstood whole thing - I thought we were about common API as for parser as for UIs. So we were speaking about different things, by different languages almost. ;) Now I've get rid of that misunderstanding so I could say - you did all I wanted with your level 0. I think it's enough and I happy. ;) BTW, did you wrote new config_t and module_info_t structures (I mean API layer 0) yet? If you didn't then there is a draft here (from yours API description, of course - you really fine generalized all). :) Also I typed here some #define because they have values of fields of config_t. I hope I did all correctly now. :) BTW, I'm not sure if filename must be in module_info_t - plugin subsystem can have it in internal arrays. That subsystem anyway has to keep bad filenames list to avoid trying its (in cache also, I think) further. Bad filenames - if plugins are in plugin's subdirectory but are not plugins or have incompatible version. ------------------------- begin of cfg.h #ifndef __CFG_H #define __CFG_H 1 typedef struct { char *name; void *p; /* variable pointer, type specific */ int type; unsigned int flags; float min, max; /* range */ void *priv; /* additional pointer, type specific */ char *desc; /* short description for help and gui */ } config_t; /* note: version has to be first in ModuleInfo struct in loadable module to allow us always do validation/version check of module */ typedef struct { unsigned char version[4]; // { PLUGIN_VERSION_MAJOR, PLUGIN_VERSION_MINOR, 'M', 'P' } int type; // for loadable module identification char *name; char *desc; // short description for help and gui char *maintainer; char *author; char *comment; config_t *opts; void *param_defaults; size_t *param_size; char *filename; // filled by plugin subsystem, NULL for internal } module_info_t; /* type (menu field) ->p ->min ->max ->priv */ enum { // flag (checkbox) int* reset set - CONF_TYPE_FLAG=0, // integer (slider) int* min max - CONF_TYPE_INT, // float (slider) float* min max - CONF_TYPE_FLOAT, // position (slider) off_t* min max - CONF_TYPE_POSITION, // string (input box) char** min max - CONF_TYPE_STRING, // string as list - must be obsoleted to CONF_TYPE_LIST CONF_TYPE_STRING_LIST, // function cfg_func* - - revert-cfg_func* CONF_TYPE_FUNC, CONF_TYPE_FUNC_PARAM, CONF_TYPE_FUNC_FULL, // text (none) char** - - - CONF_TYPE_PRINT, /* all below this have ->priv as config_t* */ // subconfig (dialog) - - - config_t* CONF_TYPE_SUBCONFIG, // choose list char** - length config_t* CONF_TYPE_CHOOSE, // select list char*** - - config_t* CONF_TYPE_LIST, // config group (sep.) - - - config_t* CONF_TYPE_DUMMY }; /* these macros are very useful for parsers or UI */ #define CONF_TYPE_HAS_CHILD(x) (x>=CONF_TYPE_SUBCONFIG) #define CONF_TYPE_ALLOW_WILDCARD(x) (x==CONF_TYPE_LIST||x==CONF_TYPE_CHAIN||x==CONF_TYPE_FUNC_FULL) #define CONF_NUM_TYPES (CONF_TYPE_DUMMY+1) /* flags for options */ #define CONF_MIN (1<<0) #define CONF_MAX (1<<1) #define CONF_RANGE (CONF_MIN|CONF_MAX) // This option cannot be in config file #define CONF_NOCFG (1<<2) // This option cannot be in command line #define CONF_NOCMD (1<<3) // This option is global : it won't be saved and only the command line // parser will set it when it's parsed (ie. it won't be set later) // e.g options : -v, -quiet #define CONF_GLOBAL (1<<4) // Do not save this option : it won't be saved on config save // or by UI on context change #define CONF_NOSAVE (1<<5) // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for example) // It looks like a regular subconfig but different in parsing a bit #define CONF_SEQUENT (1<<6) // It used for lists to reverse order of arguments in char*** #define CONF_REVERSE (1<<7) /* macro to get relative address of x.y in struct x */ #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) #endif /* __CFG_H */ ------------------------- end of cfg.h With best wishes. Andriy. From andrej at lucky.net Wed May 14 18:21:46 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 19:21:46 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514161538.GA9528@lucky.net> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> Message-ID: <20030514162146.GC9528@lucky.net> Sometime (on Wednesday, May 14 at 19:16) I've sent something... >typedef struct { > unsigned char version[4]; // { PLUGIN_VERSION_MAJOR, PLUGIN_VERSION_MINOR, 'M', 'P' } > int type; // for loadable module identification > char *name; > char *desc; // short description for help and gui > char *maintainer; > char *author; > char *comment; > config_t *opts; > void *param_defaults; > size_t *param_size; OOPS, it's typo, sorry, must be without '*': size_t param_size; > char *filename; // filled by plugin subsystem, NULL for internal >} module_info_t; With best wishes. Andriy. From albeu at free.fr Wed May 14 21:11:05 2003 From: albeu at free.fr (Alban Bedel) Date: Wed, 14 May 2003 21:11:05 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514161538.GA9528@lucky.net> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> Message-ID: <20030514211105.55c8ad8b.albeu@free.fr> Hi Andriy N. Gritsenko, on Wed, 14 May 2003 19:15:39 +0300 you wrote: > Hi, Arpi! > > So I misunderstood whole thing - I thought we were about common API > as for parser as for UIs. So we were speaking about different things, by > different languages almost. ;) Now I've get rid of that > misunderstanding so I could say - you did all I wanted with your level > 0. I think it's enough and I happy. ;) > > BTW, did you wrote new config_t and module_info_t structures (I mean > API layer 0) yet? If you didn't then there is a draft here (from yours > API description, of course - you really fine generalized all). :) Also > I typed here some #define because they have values of fields of > config_t. I hope I did all correctly now. :) BTW, I'm not sure if > filename must be in module_info_t - plugin subsystem can have it in > internal arrays. That subsystem anyway has to keep bad filenames list to > avoid trying its (in cache also, I think) further. Bad filenames - if > plugins are in plugin's subdirectory but are not plugins or have > incompatible version. I like the cache idea but imho the it should use more than the filename to identify a file. Smthg like filename + date (a hash would be better but that's probaly overkill) so we could detect if the file changed since last run. > ------------------------- begin of cfg.h > #ifndef __CFG_H > #define __CFG_H 1 > > typedef struct { > char *name; > void *p; /* variable pointer, type specific */ > int type; > unsigned int flags; > float min, max; /* range */ > void *priv; /* additional pointer, type specific */ > char *desc; /* short description for help and gui */ > } config_t; I liked the idea you had of putting some hint for GUI widget type. It would avoid having different options type wich are in fact the same C type and it would also make things nicer for GUI writers. Also type specific flags would be nice. Ok there is priv but if a type only need a few flags priv is overkill. We could either add another flag field or use the lower bit for common flags and the higher for type specific ones. > /* note: version has to be first in ModuleInfo struct in loadable module > to allow us always do validation/version check of module */ > typedef struct { > unsigned char version[4]; // { PLUGIN_VERSION_MAJOR, > PLUGIN_VERSION_MINOR, 'M', 'P' } > int type; // for loadable module identification > char *name; > char *desc; // short description for help and gui > char *maintainer; > char *author; > char *comment; > config_t *opts; > void *param_defaults; > size_t *param_size; > char *filename; // filled by plugin subsystem, NULL for internal > } module_info_t; > > /* type (menu field) ->p ->min ->max ->priv */ > enum { > // flag (checkbox) int* reset set - > CONF_TYPE_FLAG=0, > // integer (slider) int* min max - > CONF_TYPE_INT, > // float (slider) float* min max - > CONF_TYPE_FLOAT, > // position (slider) off_t* min max - > CONF_TYPE_POSITION, > // string (input box) char** min max - > CONF_TYPE_STRING, > // string as list - must be obsoleted to CONF_TYPE_LIST > CONF_TYPE_STRING_LIST, Obsolated stuff in a draft ?????? > // function cfg_func* - - revert-cfg_func* > CONF_TYPE_FUNC, > CONF_TYPE_FUNC_PARAM, > CONF_TYPE_FUNC_FULL, I think we should avoid callback based stuff. These were nice in the old days for very specific stuff. But now the only place in G1 where they are really needed is for the -aa* options of aalib. But as in G2 each module instance have it's own context it doesn't really make sense as options parsing append before instanciation. For options global to a layer that would make some sense but then the callback also need to get the struct/context on wich it should operate. So this context should be static otherwise you can't put it in the config_t->priv field. But we don't want static stuff so for G2 lib that's anyway completly unusefull. We may let that for app level stuff but i doubt it's really usefull. > // text (none) char** - - - > CONF_TYPE_PRINT, That's also only usefull at app level. > /* > all below this have > ->priv as config_t* > */ > // subconfig (dialog) - - - config_t* > CONF_TYPE_SUBCONFIG, > // choose list char** - length config_t* > CONF_TYPE_CHOOSE, > // select list char*** - - config_t* > CONF_TYPE_LIST, > // config group (sep.) - - - config_t* > CONF_TYPE_DUMMY > }; Could pls explain these a bit more. > /* these macros are very useful for parsers or UI */ > #define CONF_TYPE_HAS_CHILD(x) (x>=CONF_TYPE_SUBCONFIG) > #define CONF_TYPE_ALLOW_WILDCARD(x) > #(x==CONF_TYPE_LIST||x==CONF_TYPE_CHAIN||x==CONF_TYPE_FUNC_FULL) I don't like this way for wildcard. Wildcard support depend on the string 2 C parser so imho it should be queried from it. > #define CONF_NUM_TYPES (CONF_TYPE_DUMMY+1) > > /* flags for options */ > #define CONF_MIN (1<<0) > #define CONF_MAX (1<<1) > #define CONF_RANGE (CONF_MIN|CONF_MAX) > // This option cannot be in config file > #define CONF_NOCFG (1<<2) > // This option cannot be in command line > #define CONF_NOCMD (1<<3) > // This option is global : it won't be saved and only the command line > // parser will set it when it's parsed (ie. it won't be set later) > // e.g options : -v, -quiet > #define CONF_GLOBAL (1<<4) > // Do not save this option : it won't be saved on config save > // or by UI on context change > #define CONF_NOSAVE (1<<5) > // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for > example)// It looks like a regular subconfig but different in parsing a > bit > #define CONF_SEQUENT (1<<6) Dunno if that's really usefull as it's possible to have a parser how handle both mode (ie named and unamed suboptions) and even a mix of the 2. > // It used for lists to reverse order of arguments in char*** > #define CONF_REVERSE (1<<7) Is that really useful ??? I mean you need code to support that, on the other hand you can only just reorder your list instead of adding this flag. > /* macro to get relative address of x.y in struct x */ > #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) I doubt that this macro really work. And even if it work it need an instance to apply it to. Why don't you just take the one in m_struct.h (wich is from glib.h) wich just need the declaration of the struct. > #endif /* __CFG_H */ > ------------------------- end of cfg.h > > With best wishes. My best wishes too. Albeu From saschasommer at freenet.de Wed May 14 21:26:30 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Wed, 14 May 2003 21:26:30 +0200 Subject: [MPlayer-G2-dev] [PATCH] ms_hdr.h vs. wingdi.h Message-ID: <001401c31a4e$b9453e40$feb8ebd9@oemcomputer> This patch allows it to include windows.h in test-play.c It would also be nice if we could change DATADIR to MPDATADIR or something else. Sascha -------------- next part -------------- A non-text attachment was scrubbed... Name: ms_hdr.h.patch Type: application/octet-stream Size: 356 bytes Desc: not available URL: From arpi at thot.banki.hu Wed May 14 22:27:29 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 22:27:29 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514211105.55c8ad8b.albeu@free.fr> Message-ID: <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> Hi, > > BTW, did you wrote new config_t and module_info_t structures (I mean > > API layer 0) yet? If you didn't then there is a draft here (from yours > > API description, of course - you really fine generalized all). :) Also > > I typed here some #define because they have values of fields of > > config_t. I hope I did all correctly now. :) BTW, I'm not sure if > > filename must be in module_info_t - plugin subsystem can have it in > > internal arrays. That subsystem anyway has to keep bad filenames list to > > avoid trying its (in cache also, I think) further. Bad filenames - if > > plugins are in plugin's subdirectory but are not plugins or have > > incompatible version. > > I like the cache idea but imho the it should use more than the filename > to identify a file. Smthg like filename + date (a hash would be better > but that's probaly overkill) so we could detect if the file changed > since last run. Of course filename is not enough, maybe filename+date also not, but dunno. But these infos don't belong to the module_info_t at all. The filename is there for the dlopen() only, to allow any filename, but i'm not sure we really want to allow it. Esp., that CLI interfaces would load plugins by filename, without scanning the plugin dir first. > > ------------------------- begin of cfg.h > > #ifndef __CFG_H > > #define __CFG_H 1 > > > > typedef struct { > > char *name; > > void *p; /* variable pointer, type specific */ > > int type; > > unsigned int flags; > > float min, max; /* range */ > > void *priv; /* additional pointer, type specific */ > > char *desc; /* short description for help and gui */ > > } config_t; > > I liked the idea you had of putting some hint for GUI widget type. Yes, I also like that idea. > It would avoid having different options type wich are in fact the > same C type and it would also make things nicer for GUI writers. > Also type specific flags would be nice. Ok there is priv but > if a type only need a few flags priv is overkill. We could either > add another flag field or use the lower bit for common flags and > the higher for type specific ones. Yes, we could add more flags, to more exactly describe how it should look like on the GUI. Including step units (for sliders), and others. So a clever GUI coder could write an 'interpreter' which dinamically build gui panels based on these info. I've seen such thing in xine, they build Xv setup panel runtime based on the attribute list returned by xvinfo. > > /* note: version has to be first in ModuleInfo struct in loadable module > > to allow us always do validation/version check of module */ > > typedef struct { > > unsigned char version[4]; // { PLUGIN_VERSION_MAJOR, > > PLUGIN_VERSION_MINOR, 'M', 'P' } > > int type; // for loadable module identification > > char *name; > > char *desc; // short description for help and gui > > char *maintainer; > > char *author; > > char *comment; > > config_t *opts; > > void *param_defaults; > > size_t *param_size; > > char *filename; // filled by plugin subsystem, NULL for internal > > } module_info_t; > > > > /* type (menu field) ->p ->min ->max ->priv */ > > enum { > > // flag (checkbox) int* reset set - > > CONF_TYPE_FLAG=0, > > // integer (slider) int* min max - > > CONF_TYPE_INT, > > // float (slider) float* min max - > > CONF_TYPE_FLOAT, > > // position (slider) off_t* min max - > > CONF_TYPE_POSITION, > > // string (input box) char** min max - > > CONF_TYPE_STRING, > > // string as list - must be obsoleted to CONF_TYPE_LIST > > CONF_TYPE_STRING_LIST, > Obsolated stuff in a draft ?????? I can't see why is string list is obsolete? It's a good thing and is used a lot by g1 and in g2 too. > > > // function cfg_func* - - revert-cfg_func* > > CONF_TYPE_FUNC, > > CONF_TYPE_FUNC_PARAM, > > CONF_TYPE_FUNC_FULL, > I think we should avoid callback based stuff. These were nice in the > old days for very specific stuff. But now the only place in G1 where > they are really needed is for the -aa* options of aalib. But as in G2 > each module instance have it's own context it doesn't really make > sense as options parsing append before instanciation. > For options global to a layer that would make some sense but then the > callback also need to get the struct/context on wich it should > operate. So this context should be static otherwise you can't put > it in the config_t->priv field. But we don't want static stuff so > for G2 lib that's anyway completly unusefull. > We may let that for app level stuff but i doubt it's really usefull. it's usefull. think of an external plugin (wirtten by third party) which requires special parsing for some parameters. Ok, they could receive string and do parsing at open(), but implementing a parsing function is better, as the UI can notice syntax errors before getting to open(). but imho we don't need 3 of them, only one such type is enough. but we should define how to pass struct offset/pointer and number of args. > > // text (none) char** - - - > > CONF_TYPE_PRINT, > That's also only usefull at app level. this one is really obsolete, imho. it was used in g1 to abort UI at parsing level with error... (for obsolete parameters or when requested not compiled-in things) or dunno, maybe it's still usefull for something... but should be handled differently. > > /* these macros are very useful for parsers or UI */ > > #define CONF_TYPE_HAS_CHILD(x) (x>=CONF_TYPE_SUBCONFIG) > > #define CONF_TYPE_ALLOW_WILDCARD(x) > > #(x==CONF_TYPE_LIST||x==CONF_TYPE_CHAIN||x==CONF_TYPE_FUNC_FULL) > I don't like this way for wildcard. Wildcard support depend on the > string 2 C parser so imho it should be queried from it. i also don't like these > > #define CONF_SEQUENT (1<<6) > Dunno if that's really usefull as it's possible to have a parser > how handle both mode (ie named and unamed suboptions) and even > a mix of the 2. > > > // It used for lists to reverse order of arguments in char*** > > #define CONF_REVERSE (1<<7) > Is that really useful ??? I mean you need code to support that, on > the other hand you can only just reorder your list instead of > adding this flag. agree > > /* macro to get relative address of x.y in struct x */ > > #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) > I doubt that this macro really work. And even if it work it need an > instance to apply it to. Why don't you just take the one in m_struct.h > (wich is from glib.h) wich just need the declaration of the struct. agree btw i defined in my layer 0 draft, that you should make a static stuct, filled with the defaults. it also serevs as target of pointers in config_t, but that static instance is read-only, must not be modified. but you're maybe right, if defaulting everything to zero is ok, then we could left this out (optinally). A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From dalias at aerifal.cx Wed May 14 22:05:26 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 14 May 2003 16:05:26 -0400 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> References: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> Message-ID: <20030514200525.GJ23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 04:39:01PM +0200, Arpi wrote: > > Another question is about VOCTRL_RESIZE_DEST and VOCTRL_RESIZE_SRC. > > What should I do, If I can't handle it, for example if my driver requires > > some minimum stretch factor. > > Do you have a solution for this? If not, would it be possible to set vo->x > > ,y w and h to valid ones and return VO_FALSE? > > hmm > don't touch vo->values, but if you cannot accept the values given, change > the args (it's an int[]) and return VO_FALSE. > > > Other limitations would be that card can only size down to a fixed height or > > some alignment > > restriction etc. > > resize_dest is to handle window resizing/movement events. > resize_src is to handle special effects like panscan or zooming. > > in both cases it's acceptable if you cannot exactly set the given params, > but something else (close values). > i just don't knowwhich is better: > - change args[] and return VO_FALSE > - set vo->* to what we can, and actually do the operation (resize) and > return TRUE In any case, the mga_vid kernel driver seems like it's broken and can't handle changing source size. This is not a hardware limitation, but a stupid api design vektor and I encountered the other day while he was adding mga_vid support to tvtime... At some point, we really need to work out a *good* architecture for all the *_vid drivers to be in kernelspace, with access to dma, irq, etc. through the drm (if available)... Rich From arpi at thot.banki.hu Wed May 14 22:41:02 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 14 May 2003 22:41:02 +0200 Subject: Iive's version Re: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <1150.212.116.158.165.1052863234.squirrel@mail.cacad.com> Message-ID: <200305142041.h4EKf2fd003972@mail.mplayerhq.hu> Hi, > It looks like am too late with my drafts > anyway i see that many of the ideas i had have > been introdused. Anyway i send it as > attachment, maybe there are still good ideas yes, there are good ones, definitly! at least i found 2 interesting ideas: > Just an examples: > "*.demuxer.avi.nointerlace" = "1" > "1.demuxer.avi.nointeleave=0" > the avi demuxer will see only "nointerleave" part. this is good for teh config files. (dunno what is taht *. and 1. at the start, i skip them for now) such thing is already used by Xfree since ages: !Maker.Cursor.topleft: topleft !Maker.Cursor.top: top !Maker.Cursor.topright: topright .. imho it could also solve the problem of module-dependant options which may not be available always when parsing configfiles. btw i don't know yet teh naming convention for core and modules. for example it could be: demuxer.soemvar=123 demuxer.avi.something=456 or: demuxer.core.somevar=123 demuxer.avi.something=456 or demuxer.core.somevar=123 demuxer.modules.avi.something=456 or demuxer.somevar=123 demux_avi.something=456 better ideas? > 2. Implementation > There should not be global option file as it is now. > In instance structure to be added array of 'options' > > union { > int as_int; > float as_float; > void* as pointer > off-t as_off_t; > }param_u;//this is from g1 cfgparser.h > > .... > param_u options[]; > ... > } instance_t; > > In every module there should be array structure like config_t: > - name of the option - string > - type of the option number (int,float) or pointer (to string) > - option number - index in the options[] > - default value - string or number > - max,min limits (for numbers) > If option is changed at runtime a function could be called > so the nessessery reinit to be done.e.g. > > static uint32_t option_changed(int option_num){ > switch (option_num){ > case enum_idct: > lavc_idct_change(lavctx,module_inst->options[emum_idct].as_int); > return OK; > default: > return RESTORE; > } > } > // Better add new flag, CONF_RUNTIME_CHANGABLE or something... > > > 4. Bad sides. > The index values should be unique, and it is not always nice to work with > something like > if ( instance->options[15].as_int > 1 ) print_info(); > so each option will be enumarated (I've never used enum so far): > if ( instance->options[lavc_debug].as_int > 1 ) print_info(); > it raises a big question: module-dependent struct or array (of union)? (ie. my/albeu's vs. iive's idea of keeping config variables) both solutions have important advantages and disadvantages. for runtime configuration (control) and inter-module args passing (including automatic module insertion with some paramaters) is easier with array. it can also handle default values in config_t easier. > There is no place for suboptions. In fact suboptions are options > for some other module. ( Am I wrong?). yes, maybe you're right... it's actually question of commandline syntax we want to use to pass module-dependant args. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu From andrej at lucky.net Wed May 14 22:17:45 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 23:17:45 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514211105.55c8ad8b.albeu@free.fr> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> Message-ID: <20030514201745.GA64126@lucky.net> Hi, Alban Bedel! Sometime (on Wednesday, May 14 at 22:15) I've received something... >> BTW, did you wrote new config_t and module_info_t structures (I mean >> API layer 0) yet? If you didn't then there is a draft here (from yours >> API description, of course - you really fine generalized all). :) Also >> I typed here some #define because they have values of fields of >> config_t. I hope I did all correctly now. :) BTW, I'm not sure if >> filename must be in module_info_t - plugin subsystem can have it in >> internal arrays. That subsystem anyway has to keep bad filenames list to >> avoid trying its (in cache also, I think) further. Bad filenames - if >> plugins are in plugin's subdirectory but are not plugins or have >> incompatible version. >I like the cache idea but imho the it should use more than the filename >to identify a file. Smthg like filename + date (a hash would be better >but that's probaly overkill) so we could detect if the file changed >since last run. I wrote already (in one of previous letters) - in cache for identify each cache entry must have a path, modification time and size of file. :) But that is implementation issue. What I said above is that I wonder if we really need that info in module_info_t (as it was proposed by Arpi). >> ------------------------- begin of cfg.h >> #ifndef __CFG_H >> #define __CFG_H 1 >> >> typedef struct { >> char *name; >> void *p; /* variable pointer, type specific */ >> int type; >> unsigned int flags; >> float min, max; /* range */ >> void *priv; /* additional pointer, type specific */ >> char *desc; /* short description for help and gui */ >> } config_t; >I liked the idea you had of putting some hint for GUI widget type. >It would avoid having different options type wich are in fact the >same C type and it would also make things nicer for GUI writers. >Also type specific flags would be nice. Ok there is priv but >if a type only need a few flags priv is overkill. We could either >add another flag field or use the lower bit for common flags and >the higher for type specific ones. I think second way is better. >> // string as list - must be obsoleted to CONF_TYPE_LIST >> CONF_TYPE_STRING_LIST, >Obsolated stuff in a draft ?????? I've added that only because there are still options of that type. But I think you are right and we must remove it as soon we apply new API. :) >> // function cfg_func* - - revert-cfg_func* >> CONF_TYPE_FUNC, >> CONF_TYPE_FUNC_PARAM, >> CONF_TYPE_FUNC_FULL, >I think we should avoid callback based stuff. These were nice in the >old days for very specific stuff. But now the only place in G1 where >they are really needed is for the -aa* options of aalib. But as in G2 >each module instance have it's own context it doesn't really make >sense as options parsing append before instanciation. >For options global to a layer that would make some sense but then the >callback also need to get the struct/context on wich it should >operate. So this context should be static otherwise you can't put >it in the config_t->priv field. But we don't want static stuff so >for G2 lib that's anyway completly unusefull. >We may let that for app level stuff but i doubt it's really usefull. I've added these for the same reason as CONF_TYPE_STRING_LIST. And application level stuff of that type still exist and I wonder if we can avoid that - see "include" or "help" options. >> // text (none) char** - - - >> CONF_TYPE_PRINT, >That's also only usefull at app level. Of course, it is for application level. >> /* >> all below this have >> ->priv as config_t* >> */ >> // subconfig (dialog) - - - config_t* >> CONF_TYPE_SUBCONFIG, >> // choose list char** - length config_t* >> CONF_TYPE_CHOOSE, >> // select list char*** - - config_t* >> CONF_TYPE_LIST, >> // config group (sep.) - - - config_t* >> CONF_TYPE_DUMMY >> }; >Could pls explain these a bit more. CONF_TYPE_CHOOSE is string that could have only few fixed choises (in Gui it will be combobox). For example - oac:lame:mode may have values "1", "2", "3", "4" or "stereo", "joint", "dual", "mono". CONF_TYPE_LIST is string list but you will have subconfig for all available choises - it will help you to have subconfigs for these and let config parser check it itself. For example - "vo" will have list of currently available video drivers and you can get help for it and write in the commandline "-vo jpeg:quality=95" and get rid of option "-jpeg". CONF_TYPE_DUMMY is just subconfig type but it's name will be ignored so config parser will just parse it's subconfig as continuation of current config. It may be useful for: 1) adding new config_t without reallocation current config_t (someone already wrote about something alike here); 2) for Gui - it will indicates submenu or if option is empty then just menu separator. What I mean submenu - for example, you may have root config consists of options "File", "Video", "Audio", "About" but inside of it are real options. Also it's possible to have second, etc. level of menu, just look on any GUI application. It's also application level option, of course. :) >> /* these macros are very useful for parsers or UI */ >> #define CONF_TYPE_HAS_CHILD(x) (x>=CONF_TYPE_SUBCONFIG) >> #define CONF_TYPE_ALLOW_WILDCARD(x) >> #(x==CONF_TYPE_LIST||x==CONF_TYPE_CHAIN||x==CONF_TYPE_FUNC_FULL) >I don't like this way for wildcard. Wildcard support depend on the >string 2 C parser so imho it should be queried from it. You propose to move it into that parser? Anyway I placed it as helper macro so I don't mind to remove it. >> // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for >> example)// It looks like a regular subconfig but different in parsing a >> bit >> #define CONF_SEQUENT (1<<6) >Dunno if that's really usefull as it's possible to have a parser >how handle both mode (ie named and unamed suboptions) and even >a mix of the 2. What do you mean, sorry? I meant if we have that type of subconfig then suboptions of that option don't have to have names - it will be checked by parser and don't produce an error. Regular subconfigs have no rights to have unnamed suboptions (for example, "-info Me:NewFilm" is nonsence at least). >> // It used for lists to reverse order of arguments in char*** >> #define CONF_REVERSE (1<<7) >Is that really useful ??? I mean you need code to support that, on >the other hand you can only just reorder your list instead of >adding this flag. It really is here only for "-vop" option. If we'll get rid of it then it may be don't need. :) >> /* macro to get relative address of x.y in struct x */ >> #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) >I doubt that this macro really work. And even if it work it need an >instance to apply it to. Why don't you just take the one in m_struct.h >(wich is from glib.h) wich just need the declaration of the struct. Hmm. I think you are right. Sorry. It seems I tired and I must to have a rest. Thank you. This is right? #define STRUCT_OFF(x,y) ((void *)((x *)0)->y) >> With best wishes. >My best wishes too. Thank you. :) Best wishes again and more. :) Andriy. From vektor at dumbterm.net Wed May 14 22:24:05 2003 From: vektor at dumbterm.net (Billy Biggs) Date: Wed, 14 May 2003 15:24:05 -0500 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <20030514200525.GJ23552@brightrain.aerifal.cx> References: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> <20030514200525.GJ23552@brightrain.aerifal.cx> Message-ID: <20030514202404.GI499@dumbterm.net> D Richard Felker III (dalias at aerifal.cx): > At some point, we really need to work out a *good* architecture for > all the *_vid drivers to be in kernelspace, with access to dma, irq, > etc. through the drm (if available)... The mga_vid API is almost there. It's very clean and easy to use. One or two more ioctls and I'd be very happy. -Billy From andrej at lucky.net Wed May 14 22:28:51 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Wed, 14 May 2003 23:28:51 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> References: <20030514211105.55c8ad8b.albeu@free.fr> <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> Message-ID: <20030514202851.GB64126@lucky.net> Hi, Arpi! Sometime (on Wednesday, May 14 at 22:51) I've received something... >> > // string as list - must be obsoleted to CONF_TYPE_LIST >> > CONF_TYPE_STRING_LIST, >> Obsolated stuff in a draft ?????? >I can't see why is string list is obsolete? It's a good thing and is used a >lot by g1 and in g2 too. CONF_TYPE_STRING_LIST is just a string with commas so it cannot let any hints (for Gui or for help) what are choises to add to selection. So I've added CONF_TYPE_LIST as some kind of subconfig - it's more powerful and flexible than string-type list. >> > // function cfg_func* - - revert-cfg_func* >> > CONF_TYPE_FUNC, >> > CONF_TYPE_FUNC_PARAM, >> > CONF_TYPE_FUNC_FULL, >> I think we should avoid callback based stuff. These were nice in the >> old days for very specific stuff. But now the only place in G1 where >> they are really needed is for the -aa* options of aalib. But as in G2 >> each module instance have it's own context it doesn't really make >> sense as options parsing append before instanciation. >> For options global to a layer that would make some sense but then the >> callback also need to get the struct/context on wich it should >> operate. So this context should be static otherwise you can't put >> it in the config_t->priv field. But we don't want static stuff so >> for G2 lib that's anyway completly unusefull. >> We may let that for app level stuff but i doubt it's really usefull. >it's usefull. think of an external plugin (wirtten by third party) which >requires special parsing for some parameters. Ok, they could receive string >and do parsing at open(), but implementing a parsing function is better, as >the UI can notice syntax errors before getting to open(). >but imho we don't need 3 of them, only one such type is enough. >but we should define how to pass struct offset/pointer and number of args. Agree. With best wishes. Andriy. From dalias at aerifal.cx Thu May 15 00:05:57 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 14 May 2003 18:05:57 -0400 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514201745.GA64126@lucky.net> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> Message-ID: <20030514220557.GL23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 11:17:45PM +0300, Andriy N. Gritsenko wrote: > >> /* macro to get relative address of x.y in struct x */ > >> #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) > >I doubt that this macro really work. And even if it work it need an > >instance to apply it to. Why don't you just take the one in m_struct.h > >(wich is from glib.h) wich just need the declaration of the struct. > > Hmm. I think you are right. Sorry. It seems I tired and I must to have a > rest. Thank you. This is right? > > #define STRUCT_OFF(x,y) ((void *)((x *)0)->y) Huh? No way, it doesn't even evaluate to an int/offset, so there's no way it can be right!! Try this: #define STRUCT_OFF(x,y) (((char *)&((x *)0)->y)-((char *)0)) Taking the difference of pointers makes it evaluate to an offset type, as desired. It also handles the (nonsense) case where the null pointer is not all 0 bits, if we care about such stupid systems. :) Rich From arpi at thot.banki.hu Thu May 15 02:13:14 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 02:13:14 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <200305102004.h4AK44Ua010303@mail.mplayerhq.hu> Message-ID: <200305150013.h4F0DESC001347@mail.mplayerhq.hu> Hi, > I've also finished libvo2 dosc, here's it for discussion: Ok i've done some changes, actually added (optional) support for on-demand buffer allocation: ----- (paste from updated libvo2.txt) You have to allocate (calloc()) an array of vo_bufffer_t structures, and put the pointer into vo->buffers. Then loop though the array and fill each buffer description struct, ie. put plane pointers/stride there. You can store your private per-buffer data in vo_buffer_t->priv. The number of allocated buffers should be put into vo->num_buffers. You can also choose buffer allocation on-demand, ie. allocate buffers only when needed so you don't allocate more (or less) than the ideal number of buffers. For this, you need to implement get_buffer() and release_buffer() functions. get_buffer() will allocate and return a single buffer, or NULL if allocation failed (no more resources etc). release_buffer() will be called to free it. Note: you can mix the 2 methods, vo->num_buffers+vo->buffers[] and get_buffer(),in this case when num_buffers is not enough, then get_buffers() will be called (think it is called get_more_buffers :)). The release_buffer() is only called for buffers allocated by get_buffers(), never for the ones from buffers[] ! So you can allocate one buffer in config(), to test if allocation doesn't fail, and implement get_buffer() to allow application to request more buffers. ----- 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 May 15 03:37:32 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 03:37:32 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <200305150013.h4F0DESC001347@mail.mplayerhq.hu> Message-ID: <200305150137.h4F1bWi8007858@mail.mplayerhq.hu> Hi, > > I've also finished libvo2 dosc, here's it for discussion: > > Ok i've done some changes, actually added (optional) support for on-demand > buffer allocation: pre24 released with the related libvo2 and vf_vo2 changes: "upgrade" recommended for libvo2 developers/users only. pre24: - vf_vo2: query_format() fixed - libvo2: support for on-demand buffer allocation (& release) added - vf_vo2: get_image() reworked to use vo2_get|release_buffer - vf_vo2: combined DR + slices fixed/handled - temporary options added: -dr and -force-dr (DR1 is still disabled by default) - vf_vo2: verbose messages printed when DR checks failed, with reason detailed A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From albeu at free.fr Wed May 14 22:52:14 2003 From: albeu at free.fr (Alban Bedel) Date: Wed, 14 May 2003 22:52:14 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> References: <20030514211105.55c8ad8b.albeu@free.fr> <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> Message-ID: <20030514225214.4e3f23ed.albeu@free.fr> Hi Arpi, on Wed, 14 May 2003 22:27:29 +0200 you wrote: > Hi, > > > > BTW, did you wrote new config_t and module_info_t structures (I > > > mean > > > API layer 0) yet? If you didn't then there is a draft here (from > > > yours API description, of course - you really fine generalized all). > > > :) Also I typed here some #define because they have values of > > > fields of config_t. I hope I did all correctly now. :) BTW, I'm not > > > sure if filename must be in module_info_t - plugin subsystem can > > > have it in internal arrays. That subsystem anyway has to keep bad > > > filenames list to avoid trying its (in cache also, I think) further. > > > Bad filenames - if plugins are in plugin's subdirectory but are not > > > plugins or have incompatible version. > > > > I like the cache idea but imho the it should use more than the > > filename to identify a file. Smthg like filename + date (a hash would > > be better but that's probaly overkill) so we could detect if the file > > changed since last run. > > Of course filename is not enough, maybe filename+date also not, but > dunno. But these infos don't belong to the module_info_t at all. Sure that it doesn't belong to the module_info_t at all. I just a thought to this while reading this few lines about caching. > The filename is there for the dlopen() only, to allow any filename, but > i'm not sure we really want to allow it. Esp., that CLI interfaces would > load plugins by filename, without scanning the plugin dir first. > > > > > ------------------------- begin of cfg.h > > > #ifndef __CFG_H > > > #define __CFG_H 1 > > > > > > typedef struct { > > > char *name; > > > void *p; /* variable pointer, type specific */ > > > int type; > > > unsigned int flags; > > > float min, max; /* range */ > > > void *priv; /* additional pointer, type specific */ > > > char *desc; /* short description for help and gui */ > > > } config_t; > > > > I liked the idea you had of putting some hint for GUI widget type. > > Yes, I also like that idea. > > > It would avoid having different options type wich are in fact the > > same C type and it would also make things nicer for GUI writers. > > Also type specific flags would be nice. Ok there is priv but > > if a type only need a few flags priv is overkill. We could either > > add another flag field or use the lower bit for common flags and > > the higher for type specific ones. > > Yes, we could add more flags, to more exactly describe how it should > look like on the GUI. Including step units (for sliders), and others. > So a clever GUI coder could write an 'interpreter' which dinamically > build gui panels based on these info. I've seen such thing in xine, they > build Xv setup panel runtime based on the attribute list returned by > xvinfo. You'r right that for a true dynamic interface building we need more than a few flags. Another field to put a pointer to some (optional) other struct wich fully discribe the 'recommended' widget ? > > > /* note: version has to be first in ModuleInfo struct in loadable > > > module > > > to allow us always do validation/version check of module */ > > > typedef struct { > > > unsigned char version[4]; // { PLUGIN_VERSION_MAJOR, > > > PLUGIN_VERSION_MINOR, 'M', 'P' } > > > int type; // for loadable module identification > > > char *name; > > > char *desc; // short description for help and gui > > > char *maintainer; > > > char *author; > > > char *comment; > > > config_t *opts; > > > void *param_defaults; > > > size_t *param_size; > > > char *filename; // filled by plugin subsystem, NULL for internal > > > } module_info_t; > > > > > > /* type (menu field) ->p ->min ->max ->priv */ > > > enum { > > > // flag (checkbox) int* reset set - > > > CONF_TYPE_FLAG=0, > > > // integer (slider) int* min max - > > > CONF_TYPE_INT, > > > // float (slider) float* min max - > > > CONF_TYPE_FLOAT, > > > // position (slider) off_t* min max - > > > CONF_TYPE_POSITION, > > > // string (input box) char** min max - > > > CONF_TYPE_STRING, > > > // string as list - must be obsoleted to CONF_TYPE_LIST > > > CONF_TYPE_STRING_LIST, > > Obsolated stuff in a draft ?????? > > I can't see why is string list is obsolete? It's a good thing and is > used a lot by g1 and in g2 too. Well for GUI in some case it's perhaps a bit too generic, but i agree that it's should stay. > > > > > // function cfg_func* - - revert-cfg_func* > > > CONF_TYPE_FUNC, > > > CONF_TYPE_FUNC_PARAM, > > > CONF_TYPE_FUNC_FULL, > > I think we should avoid callback based stuff. These were nice in the > > old days for very specific stuff. But now the only place in G1 where > > they are really needed is for the -aa* options of aalib. But as in G2 > > each module instance have it's own context it doesn't really make > > sense as options parsing append before instanciation. > > For options global to a layer that would make some sense but then the > > callback also need to get the struct/context on wich it should > > operate. So this context should be static otherwise you can't put > > it in the config_t->priv field. But we don't want static stuff so > > for G2 lib that's anyway completly unusefull. > > We may let that for app level stuff but i doubt it's really usefull. > > it's usefull. think of an external plugin (wirtten by third party) which > requires special parsing for some parameters. Ok, they could receive > string and do parsing at open(), but implementing a parsing function is > better, as the UI can notice syntax errors before getting to open(). Yes, you'r right. > but imho we don't need 3 of them, only one such type is enough. > but we should define how to pass struct offset/pointer and number of > args. I agree too, only having the "full" is more than enought unless we want to kill everything gcc warnings ;) > > > // text (none) char** - - - > > > CONF_TYPE_PRINT, > > That's also only usefull at app level. > > this one is really obsolete, imho. > it was used in g1 to abort UI at parsing level with error... (for > obsolete parameters or when requested not compiled-in things) > > or dunno, maybe it's still usefull for something... > but should be handled differently. Imho the only place where it's usefull is for the top-level app like it's used in G1. We can provide it for the apps but in G2 libs it's really uneeded afaict. [...] > > > /* macro to get relative address of x.y in struct x */ > > > #define STRUCT_OFF(x,y) ((void *)(&x.y-x)) > > I doubt that this macro really work. And even if it work it need an > > instance to apply it to. Why don't you just take the one in m_struct.h > > (wich is from glib.h) wich just need the declaration of the struct. > > agree > > btw i defined in my layer 0 draft, that you should make a static stuct, > filled with the defaults. it also serevs as target of pointers in > config_t, but that static instance is read-only, must not be modified. That's why when discribing struct fields config_t->p should store the offset of the field in the struct and not a normal pointer. The offset is easy to get with such macro : // From glib.h (modified ;-) #define M_ST_OFF(struct_type, member) \ ((void*) &((struct_type*) 0)->member) #define M_ST_MB_P(struct_p, struct_offset) \ ((void*) (struct_p) + (unsigned long) (struct_offset)) #define M_ST_MB(member_type, struct_p, struct_offset) \ (*(member_type*) M_ST_MB_P ((struct_p), (struct_offset))) Then it's no prob. to set a specific field of the struct after having allocated some mem for it. > but you're maybe right, if defaulting everything to zero is ok, then we > could left this out (optinally). Imho the 'default struct' is needed bcs in many case you need default values wich are not zero and there is also cases where zero is a fully valid value but it shouldn't be the default (the evil case ;) Until now imho there is no big problem with implementing such stuff. The only problematic thing that i can see is the current main problem of the 'new' config code in G1 : dynamicly allocated stuff vs. mem leak vs. static values. If we strictly deal with struct that are create by (properly) copying the default stuct it's not a problem as we will only have dynamiclly allocted stuff. But if we also want to operate on 'normal' vars (we probably want) then it's a problem. In current G1 it's solved with a hack (when options are registered in the context saving system those who use dynamicly allocted mem (like string) have their initial value replaced by a copy of it so there is then only dynamic stuff). If somebody know how one can tell if a mem area was dynamiclly allocated or not then it's easy to solve. Othewise i really can't think of smthg clean. Albeu From dalias at aerifal.cx Thu May 15 10:22:09 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 May 2003 04:22:09 -0400 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514225214.4e3f23ed.albeu@free.fr> References: <20030514211105.55c8ad8b.albeu@free.fr> <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> <20030514225214.4e3f23ed.albeu@free.fr> Message-ID: <20030515082209.GU23552@brightrain.aerifal.cx> On Wed, May 14, 2003 at 10:52:14PM +0200, Alban Bedel wrote: > > btw i defined in my layer 0 draft, that you should make a static stuct, > > filled with the defaults. it also serevs as target of pointers in > > config_t, but that static instance is read-only, must not be modified. > > That's why when discribing struct fields config_t->p should store the > offset of the field in the struct and not a normal pointer. The offset is > easy to get with such macro : > > // From glib.h (modified ;-) > #define M_ST_OFF(struct_type, member) \ > ((void*) &((struct_type*) 0)->member) > #define M_ST_MB_P(struct_p, struct_offset) \ > ((void*) (struct_p) + (unsigned long) (struct_offset)) > #define M_ST_MB(member_type, struct_p, struct_offset) \ > (*(member_type*) M_ST_MB_P ((struct_p), (struct_offset))) > > Then it's no prob. to set a specific field of the struct after having > allocated some mem for it. LOL!!! These are from glib?? I figured someone who could write such a horrible library must not know C, but this is beyond even my expectations of their brain damage.... (Hint: learn the difference between pointer types and integer types!!) > > but you're maybe right, if defaulting everything to zero is ok, then we > > could left this out (optinally). > > Imho the 'default struct' is needed bcs in many case you need default > values wich are not zero and there is also cases where zero is a fully > valid value but it shouldn't be the default (the evil case ;) > > Until now imho there is no big problem with implementing such stuff. > The only problematic thing that i can see is the current main problem > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem > leak vs. static values. > If we strictly deal with struct that are create by (properly) copying > the default stuct it's not a problem as we will only have dynamiclly > allocted stuff. > But if we also want to operate on 'normal' vars (we probably want) > then it's a problem. > In current G1 it's solved with a hack (when options are registered > in the context saving system those who use dynamicly allocted > mem (like string) have their initial value replaced by a copy of it > so there is then only dynamic stuff). If somebody know how one can > tell if a mem area was dynamiclly allocated or not then it's easy > to solve. Othewise i really can't think of smthg clean. I say get rid of the hacks, and do it right. Since most of the things we'll be exporting config vars for can have multiple instances, it's nonsense to directly operate on variables that might be initialized with a constant string. Instead we should use a template for the defaults, and copy it into the dynamically allocated per-instance config structure. Rich From albeu at free.fr Thu May 15 10:36:42 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 10:36:42 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514201745.GA64126@lucky.net> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> Message-ID: <20030515103642.2307e16b.albeu@free.fr> Hi Andriy N. Gritsenko, on Wed, 14 May 2003 23:17:45 +0300 you wrote: > >> // string as list - must be obsoleted to CONF_TYPE_LIST > >> CONF_TYPE_STRING_LIST, > >Obsolated stuff in a draft ?????? > > I've added that only because there are still options of that type. But I > think you are right and we must remove it as soon we apply new API. :) Dunno, imho it still have some use. Sure that in most place where it's currently used it could replaced by smthg better but that doesn't make it completly unuseful. > >> // function cfg_func* - - revert-cfg_func* > >> CONF_TYPE_FUNC, > >> CONF_TYPE_FUNC_PARAM, > >> CONF_TYPE_FUNC_FULL, > >I think we should avoid callback based stuff. These were nice in the > >old days for very specific stuff. But now the only place in G1 where > >they are really needed is for the -aa* options of aalib. But as in G2 > >each module instance have it's own context it doesn't really make > >sense as options parsing append before instanciation. > >For options global to a layer that would make some sense but then the > >callback also need to get the struct/context on wich it should > >operate. So this context should be static otherwise you can't put > >it in the config_t->priv field. But we don't want static stuff so > >for G2 lib that's anyway completly unusefull. > >We may let that for app level stuff but i doubt it's really usefull. > > I've added these for the same reason as CONF_TYPE_STRING_LIST. And > application level stuff of that type still exist and I wonder if we can > avoid that - see "include" or "help" options. As discussed in other mails we should keep 1 of those. But for the example you point out it's not really needed: 'help' can be a simple print type and 'include' could be internaly implemented by the config parser. > >> // text (none) char** - - - > >> CONF_TYPE_PRINT, > >That's also only usefull at app level. > > Of course, it is for application level. > > >> /* > >> all below this have > >> ->priv as config_t* > >> */ > >> // subconfig (dialog) - - - config_t* > >> CONF_TYPE_SUBCONFIG, > >> // choose list char** - length config_t* > >> CONF_TYPE_CHOOSE, > >> // select list char*** - - config_t* > >> CONF_TYPE_LIST, > >> // config group (sep.) - - - config_t* > >> CONF_TYPE_DUMMY > >> }; > >Could pls explain these a bit more. > > CONF_TYPE_CHOOSE is string that could have only few fixed choises (in > Gui it will be combobox). For example - oac:lame:mode may have values > "1","2", "3", "4" or "stereo", "joint", "dual", "mono". Ok i think i get it. But then i don't get why you define the possible values with a config_t array. I thought to something more general but as useal with generalized stuff it's overkill for the simple case. It would be some kind of list of anything with name attached to all possible values. ->p would point to the target array to fill. And ->priv would be smthg like this : struct { int type; // Type of the elements in the array struct { char* name; // Name of this value like "stereo" union { // The value int i; float f; size_t s; void* p; } val; // There i don't know wich is better union or simple void* } *values; // contain all possible value and their names }; As i said it's overkill for the simple case like string list. For string case we could reduce that to: ->p : char** ->priv : char** where priv contain all possible values. > CONF_TYPE_LIST is string list but you will have subconfig for all > available choises - it will help you to have subconfigs for these and > let config parser check it itself. For example - "vo" will have list of > currently available video drivers and you can get help for it and write > in the commandline "-vo jpeg:quality=95" and get rid of option "-jpeg". Ok, but why is the target type char*** ? Anyway for the example you point out such type is imho not the good way. For an option wich handle a list of modules instance the option should have in priv the array of info struct for the corrensponding module type. Then possible modules names and their options are retrived from the info struct array. > >> // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for > >> example)// It looks like a regular subconfig but different in parsing > >a> bit > >> #define CONF_SEQUENT (1<<6) > >Dunno if that's really usefull as it's possible to have a parser > >how handle both mode (ie named and unamed suboptions) and even > >a mix of the 2. > > What do you mean, sorry? I meant if we have that type of subconfig then > suboptions of that option don't have to have names - it will be checked > by parser and don't produce an error. Regular subconfigs have no rights > to have unnamed suboptions (for example, "-info Me:NewFilm" is nonsence > at least). These unamed list come from G1 vf where each filter had to parse his options himself. So Arpi used this simple way in the firsts filters and it stuck. These unamed list just imply that you know the order of the suboptions. -info Me:NewFilm make sense if i know that the first field is author and the second one title. See -vf in G1, you can write '-vf filter=100:width=500:45' where 100 is the value for the first field, as width is the 12 field i name it to avoid entering the defaults of the first 11 fields and 45 is the value for the second field for wich i don't give the name bcs i'm lazy ;) This is what i mean with mixing named and unamed suboptions it's really possible and nice for lazy power users. Albeu From albeu at free.fr Thu May 15 10:50:08 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 10:50:08 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <20030514200525.GJ23552@brightrain.aerifal.cx> References: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> <20030514200525.GJ23552@brightrain.aerifal.cx> Message-ID: <20030515105008.32e77a15.albeu@free.fr> Hi D Richard Felker III, on Wed, 14 May 2003 16:05:26 -0400 you wrote: > At some point, we really need to work out a *good* architecture for > all the *_vid drivers to be in kernelspace, with access to dma, irq, > etc. through the drm (if available)... Perhaps but as the *_vid drivers are intended for high performance drivers it really depend on the way the card work. With the banshee for example 'internal blit' (ie copy inside the card mem) are essential as they can do scaleing and/or colorspace conversion. Moreover for this card the overlay can only do up scaling so when you want to downscale you have to either don't use the overlay at all or downscale when copying to the overlay mem and resetup the overlay source size. So i doubt that we can really get every bit of performance out of every card with a general approch. Perhaps that most modern cards can be well handled in general way but i doubt we'll find an interface wich will suit every kind of card with scaleing and/or colorspace conversion caps. Albeu From albeu at free.fr Thu May 15 11:05:11 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 11:05:11 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515082209.GU23552@brightrain.aerifal.cx> References: <20030514211105.55c8ad8b.albeu@free.fr> <200305142027.h4EKRTCZ023881@mail.mplayerhq.hu> <20030514225214.4e3f23ed.albeu@free.fr> <20030515082209.GU23552@brightrain.aerifal.cx> Message-ID: <20030515110511.665cd2c5.albeu@free.fr> Hi D Richard Felker III, on Thu, 15 May 2003 04:22:09 -0400 you wrote: > On Wed, May 14, 2003 at 10:52:14PM +0200, Alban Bedel wrote: > > > btw i defined in my layer 0 draft, that you should make a static > > > stuct, filled with the defaults. it also serevs as target of > > > pointers in config_t, but that static instance is read-only, must > > > not be modified. > > > > That's why when discribing struct fields config_t->p should store the > > offset of the field in the struct and not a normal pointer. The offset > > is easy to get with such macro : > > > > // From glib.h (modified ;-) ^^^^^^^^ > > #define M_ST_OFF(struct_type, member) \ > > ((void*) &((struct_type*) 0)->member) > > #define M_ST_MB_P(struct_p, struct_offset) \ > > ((void*) (struct_p) + (unsigned long) (struct_offset)) > > #define M_ST_MB(member_type, struct_p, struct_offset) \ > > (*(member_type*) M_ST_MB_P ((struct_p), (struct_offset))) > > > > Then it's no prob. to set a specific field of the struct after having > > allocated some mem for it. > > LOL!!! These are from glib?? I figured someone who could write such a > horrible library must not know C, but this is beyond even my > expectations of their brain damage.... (Hint: learn the difference > between pointer types and integer types!!) Well these are not the original from glib. Sure that it would have been better to cast the result of M_ST_OFF to some integer type. But as this macro is used to set the field of config_t->p wich is void* i instead casted it void* to avoid pages of warning. Or would it really different to have ((void*)((unsigned long) &((struct_type*) 0)->member)) ? I know that on some arch you can't store integer in pointer but here it's a struct offset so uselly only a few bytes so it will fit in both an integer and a void* in 99% of the case. I saw your other post and i agree that your version is better. > > > but you're maybe right, if defaulting everything to zero is ok, then > > > we could left this out (optinally). > > > > Imho the 'default struct' is needed bcs in many case you need default > > values wich are not zero and there is also cases where zero is a fully > > valid value but it shouldn't be the default (the evil case ;) > > > > Until now imho there is no big problem with implementing such stuff. > > The only problematic thing that i can see is the current main problem > > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem > > leak vs. static values. > > If we strictly deal with struct that are create by (properly) copying > > the default stuct it's not a problem as we will only have dynamiclly > > allocted stuff. > > But if we also want to operate on 'normal' vars (we probably want) > > then it's a problem. > > In current G1 it's solved with a hack (when options are registered > > in the context saving system those who use dynamicly allocted > > mem (like string) have their initial value replaced by a copy of it > > so there is then only dynamic stuff). If somebody know how one can > > tell if a mem area was dynamiclly allocated or not then it's easy > > to solve. Othewise i really can't think of smthg clean. > > I say get rid of the hacks, and do it right. Since most of the things > we'll be exporting config vars for can have multiple instances, it's > nonsense to directly operate on variables that might be initialized > with a constant string. Instead we should use a template for the > defaults, and copy it into the dynamically allocated per-instance > config structure. Well this lead us to the question: do we allow options to operate on vars or not ? For G2 libs it's not needed at all. But if we want to make this useful for apps too, then operating on really vars make sense. Albeu From arpi at thot.banki.hu Thu May 15 11:49:08 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 11:49:08 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030514225214.4e3f23ed.albeu@free.fr> Message-ID: <200305150949.h4F9n8rs024890@mail.mplayerhq.hu> Hi, > Until now imho there is no big problem with implementing such stuff. > The only problematic thing that i can see is the current main problem > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem > leak vs. static values. > If we strictly deal with struct that are create by (properly) copying > the default stuct it's not a problem as we will only have dynamiclly > allocted stuff. > But if we also want to operate on 'normal' vars (we probably want) > then it's a problem. > In current G1 it's solved with a hack (when options are registered > in the context saving system those who use dynamicly allocted > mem (like string) have their initial value replaced by a copy of it > so there is then only dynamic stuff). If somebody know how one can > tell if a mem area was dynamiclly allocated or not then it's easy > to solve. Othewise i really can't think of smthg clean. Sure, i was also thinking of it yesterday. The best would be to store somewhere (but where???) a flag telling the config system that the given field (string) was allocated by the config sys. It isn't really doable. The opposite approach is what you said: always duplicate (alloc+copy) everything, so you can safely free() at the end. The 3rd approach is not free() at all, it isn't big memory leak :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Thu May 15 11:30:38 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 May 2003 05:30:38 -0400 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) Message-ID: <20030515093037.GA8130@brightrain.aerifal.cx> Hey, Arpi. I was thinking earlier about some extra stuff libvo2 should support for dr. Maybe some of this is already possible, but I know parts aren't yet, and ideally they should be... 1. Direct rendering of exported images. Consider the case where you have a vo driver that sits on top of a graphics api, where you make an api call to blit an image from an arbitrary buffer buffer to the display. In this case, the vo driver should be able to pass an export-type image from the last filter directly to the blit call, without copying anything into its own allocated buffer first. 2. Dirty stride arithmetic tricks... :)) If the vo's buffer is an overlay in video memory, chances are good that you can customize the source width, source height, origin, and stride independent of the actual pixel layout in video memory. Is there some way we could let the filter chain take advantage of this? For example, the crop filter could let DR go right through it, allocating a buffer the size of the source image in video memory, but then only configuring the desired part of it to be visible. Another potential use is using stride arithmetic for deinterlacing, i.e. writing the whole interlaced picture to video memory, but selecting only one field to be visible at a time. Of course, I can't think of any nice clean way to implement all this without tons of hacks and special cases... :( But it would be very cool if we could do stuff like this..... Rich From dalias at aerifal.cx Thu May 15 11:33:36 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 May 2003 05:33:36 -0400 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515103642.2307e16b.albeu@free.fr> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> <20030515103642.2307e16b.albeu@free.fr> Message-ID: <20030515093336.GW23552@brightrain.aerifal.cx> On Thu, May 15, 2003 at 10:36:42AM +0200, Alban Bedel wrote: > > What do you mean, sorry? I meant if we have that type of subconfig then > > suboptions of that option don't have to have names - it will be checked > > by parser and don't produce an error. Regular subconfigs have no rights > > to have unnamed suboptions (for example, "-info Me:NewFilm" is nonsence > > at least). > > These unamed list come from G1 vf where each filter had to parse his > options himself. So Arpi used this simple way in the firsts filters > and it stuck. These unamed list just imply that you know the order of > the suboptions. -info Me:NewFilm make sense if i know that the first > field is author and the second one title. > See -vf in G1, you can write '-vf filter=100:width=500:45' where 100 > is the value for the first field, as width is the 12 field i name it > to avoid entering the defaults of the first 11 fields and 45 is > the value for the second field for wich i don't give the name bcs > i'm lazy ;) > This is what i mean with mixing named and unamed suboptions it's > really possible and nice for lazy power users. Agree, we should keep this. The whole point of being a power user is that your power lets you be lazy... :))) Seriously, tho, I like this stuff. Quite the opposite of bloat like XML (and EBML, lol! What does it stand for again? Extra Bloated Movie Language? :)) where you have to write 200 bytes of filler junk to select one or two simple options. Rich From dalias at aerifal.cx Thu May 15 11:37:31 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 15 May 2003 05:37:31 -0400 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <20030515105008.32e77a15.albeu@free.fr> References: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> <20030514200525.GJ23552@brightrain.aerifal.cx> <20030515105008.32e77a15.albeu@free.fr> Message-ID: <20030515093731.GX23552@brightrain.aerifal.cx> On Thu, May 15, 2003 at 10:50:08AM +0200, Alban Bedel wrote: > Hi D Richard Felker III, > > on Wed, 14 May 2003 16:05:26 -0400 you wrote: > > > At some point, we really need to work out a *good* architecture for > > all the *_vid drivers to be in kernelspace, with access to dma, irq, > > etc. through the drm (if available)... > > Perhaps but as the *_vid drivers are intended for high performance > drivers it really depend on the way the card work. With the banshee > for example 'internal blit' (ie copy inside the card mem) are > essential as they can do scaleing and/or colorspace conversion. > Moreover for this card the overlay can only do up scaling so when > you want to downscale you have to either don't use the overlay at > all or downscale when copying to the overlay mem and resetup > the overlay source size. > So i doubt that we can really get every bit of performance out of > every card with a general approch. > Perhaps that most modern cards can be well handled in general way > but i doubt we'll find an interface wich will suit every kind of > card with scaleing and/or colorspace conversion caps. As far as I can tell, all we need so far is a CAN_DOWNSCALE flag and a list of supported colorspaces... Doesn't sound too hard. VO drivers are already required to identify whether or not they can downscale, so the vo driver could just return the flag from the *_vid driver. As for non-overlay-based scalers, I think they're best kept separate. I was talking about a general driver architecture for video overlays (like vidix was supposed to be, except non-broken), not for all video scaling and colorspace conversion stuff. Rich From saschasommer at freenet.de Thu May 15 11:32:57 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Thu, 15 May 2003 11:32:57 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out References: <200305150137.h4F1bWi8007858@mail.mplayerhq.hu> Message-ID: <004801c31ac4$f8a0b620$d7b6ebd9@oemcomputer> > Hi, > > > > I've also finished libvo2 dosc, here's it for discussion: > > > > Ok i've done some changes, actually added (optional) support for on-demand > > buffer allocation: > > pre24 released with the related libvo2 and vf_vo2 changes: > > "upgrade" recommended for libvo2 developers/users only. > > pre24: > - vf_vo2: query_format() fixed > - libvo2: support for on-demand buffer allocation (& release) added > - vf_vo2: get_image() reworked to use vo2_get|release_buffer > - vf_vo2: combined DR + slices fixed/handled > - temporary options added: -dr and -force-dr (DR1 is still disabled by default) > - vf_vo2: verbose messages printed when DR checks failed, with reason detailed > Can you also add return values for frame_start and frame_done and disable rendering if they fail? It seems like a few (directfb, directx, sdl?...) drivers will probably use those to lock/unlock buffer memory. If this fails the pointers may become invalid what will, under bad conditions, leed to system locks. Sascha From arpi at thot.banki.hu Thu May 15 12:08:25 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 12:08:25 +0200 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <20030515093037.GA8130@brightrain.aerifal.cx> Message-ID: <200305151008.h4FA8PtN018697@mail.mplayerhq.hu> Hi, > Hey, Arpi. I was thinking earlier about some extra stuff libvo2 should > support for dr. Maybe some of this is already possible, but I know > parts aren't yet, and ideally they should be... > > 1. Direct rendering of exported images. Consider the case where you > have a vo driver that sits on top of a graphics api, where you make > an api call to blit an image from an arbitrary buffer buffer to the > display. In this case, the vo driver should be able to pass an > export-type image from the last filter directly to the blit call, > without copying anything into its own allocated buffer first. Hmm. it was possible (and natural) in g1, but i somehow forgot it in g2. Ok it's not completely true... There is 2 way to get your image to the vo driver: 1. vo driver exports its buffer 2. vo driver implements draw_slice() [which calls graphics api's blit()] so in normal cases it is always optimal. and i hope that there are no abnormal cases, where vo driver exports buffers but it can accept buffers from outside too. if it can use external buffer without extra copy, it should not export anything, but implement draw_slice(). > 2. Dirty stride arithmetic tricks... :)) If the vo's buffer is an > overlay in video memory, chances are good that you can customize > the source width, source height, origin, and stride independent of > the actual pixel layout in video memory. Is there some way we could > let the filter chain take advantage of this? For example, the crop > filter could let DR go right through it, allocating a buffer the > size of the source image in video memory, but then only configuring > the desired part of it to be visible. Another potential use is > using stride arithmetic for deinterlacing, i.e. writing the whole > interlaced picture to video memory, but selecting only one field to > be visible at a time. vo2 api is capable (RESIZE_SRC), but as you said it's not eays to implement cleanly. maybe the best way is implementing these as options to vf_vo2 filter. or maybe we could drive this control through the filter layer, so filters like fields or crop could query if RESIZE_SRC is available and use that instead of copy. (like the DRAW_OSD, VIDEO_EQ or SCALE controls in g1) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From nsabbi at libero.it Thu May 15 11:38:18 2003 From: nsabbi at libero.it (Nico) Date: Thu, 15 May 2003 11:38:18 +0200 Subject: [MPlayer-G2-dev] stream layer question Message-ID: <3EC3600A.5020206@libero.it> Hi, it seems that the stream layer has the same structure as the new api in g1, in particular this; #define STREAM_BUFFER_SIZE 2048 I wonder if it's feasible to add a parameter to stream_t: stream_stride, to indicate the preferred read() size. It's particularly useful for DVB (which has better read in 8K chunks, if you don't want to receive tons of buffer overflows), but even more so if in the future there will be support for HDTV cards (which surely need at least 64K stride). Or maybe it's already possible? :) Thanks, Nico From nsabbi at libero.it Thu May 15 11:42:46 2003 From: nsabbi at libero.it (Nico) Date: Thu, 15 May 2003 11:42:46 +0200 Subject: [MPlayer-G2-dev] stream layer question References: <3EC3600A.5020206@libero.it> Message-ID: <3EC36116.300@libero.it> I just read that there is stream->fill. Sorry. Forget the question, please. Nico wrote: > > Hi, > it seems that the stream layer has the same structure as the new api > in g1, in particular this; > > #define STREAM_BUFFER_SIZE 2048 > > I wonder if it's feasible to add a parameter to stream_t: > stream_stride, to indicate the preferred read() size. > It's particularly useful for DVB (which has better read in 8K chunks, > if you don't want to receive tons of buffer overflows), > but even more so if in the future there will be support for HDTV cards > (which surely need at least 64K stride). > > Or maybe it's already possible? :) > > Thanks, > Nico > > > > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev > From arpi at thot.banki.hu Thu May 15 12:17:33 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 12:17:33 +0200 Subject: [MPlayer-G2-dev] stream layer question In-Reply-To: <3EC3600A.5020206@libero.it> Message-ID: <200305151017.h4FAHXG4031097@mail.mplayerhq.hu> Hi, > it seems that the stream layer has the same structure as the new api in > g1, in particular this; > > #define STREAM_BUFFER_SIZE 2048 this is default only, you can override > I wonder if it's feasible to add a parameter to stream_t: stream_stride, > to indicate the preferred read() size. s->buffer_size=8192; see stream_http.c for example, it prefers 4kB buffers. > It's particularly useful for DVB (which has better read in 8K chunks, if > you don't want to receive tons of buffer overflows), > but even more so if in the future there will be support for HDTV cards > (which surely need at least 64K stride). > > Or maybe it's already possible? :) of couse :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu May 15 12:16:51 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 13:16:51 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515103642.2307e16b.albeu@free.fr> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> <20030515103642.2307e16b.albeu@free.fr> Message-ID: <20030515101651.GC24343@lucky.net> Hi, Alban Bedel! Sometime (on Thursday, May 15 at 11:52) I've received something... >As discussed in other mails we should keep 1 of those. But for the >example you point out it's not really needed: 'help' can be a simple >print type and 'include' could be internaly implemented by the >config parser. I think 1 type is sufficient anyway, so "help" will just ignore extra parameter (anyway it will exit(1) after execution and "include" will work with standard parameter handle so CONF_TYPE_FUNC_FULL may be only type for all FUNC*. :) >> >> /* >> >> all below this have >> >> ->priv as config_t* >> >> */ >> >> // subconfig (dialog) - - - config_t* >> >> CONF_TYPE_SUBCONFIG, >> >> // choose list char** - length config_t* >> >> CONF_TYPE_CHOOSE, >> >> // select list char*** - - config_t* >> >> CONF_TYPE_LIST, >> >> // config group (sep.) - - - config_t* >> >> CONF_TYPE_DUMMY >> >> }; >> >Could pls explain these a bit more. >> CONF_TYPE_CHOOSE is string that could have only few fixed choises (in >> Gui it will be combobox). For example - oac:lame:mode may have values >> "1","2", "3", "4" or "stereo", "joint", "dual", "mono". >Ok i think i get it. But then i don't get why you define the possible >values with a config_t array. Because parameters of that may have different types. See example below. Anyway if we have only string parameter but choises are just flags then module have to parse that string by itself and set these flags. In case of Gui it's even worse - Gui must allocate that string then pass it to module so we have two conversions - from Gui internal into string then from string into flag by module. Remember that Gui will not use option->name for own (because that field is for commandline or config parser) but use option->desc instead. >I thought to something more general but as useal with generalized >stuff it's overkill for the simple case. It would be some kind >of list of anything with name attached to all possible values. >->p would point to the target array to fill. And ->priv would be >smthg like this : >struct { > int type; // Type of the elements in the array > struct { > char* name; // Name of this value like "stereo" > union { // The value > int i; > float f; > size_t s; > void* p; > } val; // There i don't know wich is better union or simple void* > } *values; // contain all possible value and their names >}; You are going to add one more struct definition to layer 0? I think that extra struct definition is unnecessary. Sorry but it may be done by all we have already (I mean config_t) and that struct is overkill. >As i said it's overkill for the simple case like string list. For >string case we could reduce that to: >->p : char** >->priv : char** >where priv contain all possible values. We cannot, unfortunately. For example, we have an option '-fstype'. It's string list. It may have only few choises - "none","layer","above", "below","fullscreen", and "stays_on_top". All except "layer" are flag type options but layer must have integer parameter. Why we have parse it twice - once by commandline parser then after that have another parser in x11 module to do work that parser can do? We was about to avoid parsers in the modules, eh? So why that must be exception? And remember that any UI may have internal representation of parameters another that just string (strings are good only for config and commandline) so why we will force pass it unparsed? Anyway in that case we unable to do call open() with prefilled structure (as we all prefer) but pass parameters as string and force all modules do parsing itself. AFAIK, it's even impossible with our new concept. >> CONF_TYPE_LIST is string list but you will have subconfig for all >> available choises - it will help you to have subconfigs for these and >> let config parser check it itself. For example - "vo" will have list of >> currently available video drivers and you can get help for it and write >> in the commandline "-vo jpeg:quality=95" and get rid of option "-jpeg". >Ok, but why is the target type char*** ? The same as for CONF_TYPE_STRING_LIST. But may be we have to create typedef struct { char *item; char *param; } config_list_item_t; where if an item will have no params (after ':' or '=') then ->param there will be NULL. Would you like it? Then target type of CONF_TYPE_LIST will be **config_list_item_t. BTW, it will be a special prototype for CONF_TYPE_LIST since CONF_TYPE_FUNC_FULL will have a special prototype int (*cfg_func_t)(config_t *, char *, char *); >Anyway for the example you point out such type is imho not the good way. >For an option wich handle a list of modules instance the option should >have in priv the array of info struct for the corrensponding module type. >Then possible modules names and their options are retrived from the >info struct array. I think you are right and subconfig of that list has to have choises with special meaning. But we have to distinguish they are modules so add CONF_TYPE_MODULE type then parser will not parse suboptions for choises but leave its for application, and application will retrieve info array and call some parse_subconfig_params() function of parser (level 2) before calling open(). >> >> // This subconfig has unnamed parameters list (i.e. 0.3:-1:-1 for >> >> example)// It looks like a regular subconfig but different in parsing >> >a> bit >> >> #define CONF_SEQUENT (1<<6) >> >Dunno if that's really usefull as it's possible to have a parser >> >how handle both mode (ie named and unamed suboptions) and even >> >a mix of the 2. >> What do you mean, sorry? I meant if we have that type of subconfig then >> suboptions of that option don't have to have names - it will be checked >> by parser and don't produce an error. Regular subconfigs have no rights >> to have unnamed suboptions (for example, "-info Me:NewFilm" is nonsence >> at least). >These unamed list come from G1 vf where each filter had to parse his >options himself. So Arpi used this simple way in the firsts filters >and it stuck. These unamed list just imply that you know the order of >the suboptions. -info Me:NewFilm make sense if i know that the first >field is author and the second one title. You thinks about users too good. :) Unfortunately, many of users are too lazy to read documentation (at least) so they will step into that trap very frequently. So I like to check that small flag and avoid that. Anyway, it only means if we deny unnamed options then we don't set that CONF_SEQUENT flag. >See -vf in G1, you can write '-vf filter=100:width=500:45' where 100 >is the value for the first field, as width is the 12 field i name it >to avoid entering the defaults of the first 11 fields and 45 is >the value for the second field for wich i don't give the name bcs >i'm lazy ;) >This is what i mean with mixing named and unamed suboptions it's >really possible and nice for lazy power users. So you still can do this anyway - flag CONF_SEQUENT (may be, rename it to CONF_UNNAMED?) don't deny you have named parameters but contrary, allow you have unnamed ones. :) I hope, you understood me now. I don't like to be forced to type names for all filter options but I don't like to allow stupid user type "-info Me:NewFilm" also. With best wishes. Andriy. From albeu at free.fr Thu May 15 13:54:34 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 13:54:34 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305150949.h4F9n8rs024890@mail.mplayerhq.hu> References: <20030514225214.4e3f23ed.albeu@free.fr> <200305150949.h4F9n8rs024890@mail.mplayerhq.hu> Message-ID: <20030515135434.23b87b4b.albeu@free.fr> Hi Arpi, on Thu, 15 May 2003 11:49:08 +0200 you wrote: > Hi, > > > Until now imho there is no big problem with implementing such stuff. > > The only problematic thing that i can see is the current main problem > > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem > > leak vs. static values. > > If we strictly deal with struct that are create by (properly) copying > > the default stuct it's not a problem as we will only have dynamiclly > > allocted stuff. > > But if we also want to operate on 'normal' vars (we probably want) > > then it's a problem. > > In current G1 it's solved with a hack (when options are registered > > in the context saving system those who use dynamicly allocted > > mem (like string) have their initial value replaced by a copy of it > > so there is then only dynamic stuff). If somebody know how one can > > tell if a mem area was dynamiclly allocated or not then it's easy > > to solve. Othewise i really can't think of smthg clean. > > Sure, i was also thinking of it yesterday. > The best would be to store somewhere (but where???) a flag telling the > config system that the given field (string) was allocated by the config > sys. It isn't really doable. The question is should that be handled in layer2 or layer3. In G1 it's handled at layer3 but that not optimal bcs it's a tricky operation and it don't really belong there in fact (and make a layer3 implementation harder). Layer2 implement string <-> C conversions, so it should also implement copy of the C values (and destroy/free). This is requiered when first creating a copy of the default struct bcs of the dynmamiclly allocated stuff for wich simple memcpy isn't enought. So this 'protection' against freeing of static vars is required at layer2 imho. If we forbid double options (ie 2 options pointing to the same C var) for option type wich use dynamic mem then we can simply store a flag in the config_t struct wich indicate if the mem was allocated or not. If we allow double options on dynamic stuff i really can't think of a way to handle that at layer2 (beside smthg a la njamd ;) On the other hand it's not a big limitation as double options are mostly used for flags (wich are not using dynamic mem) and to keep backward comp. > The opposite approach is what you said: always duplicate (alloc+copy) > everything, so you can safely free() at the end. > The 3rd approach is not free() at all, it isn't big memory leak :) If you consider a server app wich should run for months it is really an important problem. Albeu From albeu at free.fr Thu May 15 14:19:13 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 14:19:13 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515101651.GC24343@lucky.net> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> <20030515103642.2307e16b.albeu@free.fr> <20030515101651.GC24343@lucky.net> Message-ID: <20030515141913.1d3306c1.albeu@free.fr> Hi Andriy N. Gritsenko, on Thu, 15 May 2003 13:16:51 +0300 you wrote: > Hi, Alban Bedel! > > >> CONF_TYPE_CHOOSE is string that could have only few fixed choises (in > >> Gui it will be combobox). For example - oac:lame:mode may have values > >> "1","2", "3", "4" or "stereo", "joint", "dual", "mono". > >Ok i think i get it. But then i don't get why you define the possible > >values with a config_t array. > > Because parameters of that may have different types. That's pure non-sense !!! An option is related to a C variable and afaik a C var can't have sevral type. So if the option is an integer it can't be a string at the same time !!!! We can provide different representations for the user (ie if 1==stereo then -oac lame=mode=1 is equivalent to -oac lame=mode=stereo). But an single option can't set both an int and/or a string. > See example > below. Anyway if we have only string parameter but choises are just > flags then module have to parse that string by itself and set these > flags. In case of Gui it's even worse - Gui must allocate that string > then pass it to module so we have two conversions - from Gui internal > into string then from string into flag by module. Remember that Gui will > not use option->name for own (because that field is for commandline or > config parser) but use option->desc instead. Again no app is forced to use more than the layer0. If you don't want to deal with strings in your GUI just stick with layer0. Then you can handle each option type in the way that you want. > >I thought to something more general but as useal with generalized > >stuff it's overkill for the simple case. It would be some kind > >of list of anything with name attached to all possible values. > >->p would point to the target array to fill. And ->priv would be > >smthg like this : > > >struct { > > int type; // Type of the elements in the array > > struct { > > char* name; // Name of this value like "stereo" > > union { // The value > > int i; > > float f; > > size_t s; > > void* p; > > } val; // There i don't know wich is better union or simple void* > > } *values; // contain all possible value and their names > >}; > > You are going to add one more struct definition to layer 0? I think that > extra struct definition is unnecessary. Sorry but it may be done by all > we have already (I mean config_t) and that struct is overkill. This is just a proposal of an option type. Advanced option type will need to define such kind of stuff, after all that's why there is a priv field. So complex option type can take some more parameters than a few flags. > >As i said it's overkill for the simple case like string list. For > >string case we could reduce that to: > >->p : char** > >->priv : char** > >where priv contain all possible values. > > We cannot, unfortunately. For example, we have an option '-fstype'. > It's string list. It may have only few choises - "none","layer","above", > "below","fullscreen", and "stays_on_top". All except "layer" are flag > type options but layer must have integer parameter. ???????? Again an option value must be of a well defined type. You can't shouldn't mix different value types. Also "none","layer","above", etc aren't flags, they are modules (wich can optionaly take parameters) like vf, af, etc are. [ ... ] > So you still can do this anyway - flag CONF_SEQUENT (may be, rename > it to CONF_UNNAMED?) don't deny you have named parameters but contrary, > allow you have unnamed ones. :) I hope, you understood me now. I don't > like to be forced to type names for all filter options but I don't like > to allow stupid user type "-info Me:NewFilm" also. I will NEVER do smthg that arm power users just for the shake of stupid users. Albeu From albeu at free.fr Thu May 15 14:25:29 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 14:25:29 +0200 Subject: [MPlayer-G2-dev] libvo2 documentation and pre22 iz out In-Reply-To: <20030515093731.GX23552@brightrain.aerifal.cx> References: <000e01c31a1f$05958820$2cbaebd9@oemcomputer> <200305141439.h4EEd1MM009022@mail.mplayerhq.hu> <20030514200525.GJ23552@brightrain.aerifal.cx> <20030515105008.32e77a15.albeu@free.fr> <20030515093731.GX23552@brightrain.aerifal.cx> Message-ID: <20030515142529.0d74ec8f.albeu@free.fr> Hi D Richard Felker III, on Thu, 15 May 2003 05:37:31 -0400 you wrote: > On Thu, May 15, 2003 at 10:50:08AM +0200, Alban Bedel wrote: > > Hi D Richard Felker III, > > > > on Wed, 14 May 2003 16:05:26 -0400 you wrote: > > > > > At some point, we really need to work out a *good* architecture for > > > all the *_vid drivers to be in kernelspace, with access to dma, irq, > > > etc. through the drm (if available)... > > > > Perhaps but as the *_vid drivers are intended for high performance > > drivers it really depend on the way the card work. With the banshee > > for example 'internal blit' (ie copy inside the card mem) are > > essential as they can do scaleing and/or colorspace conversion. > > Moreover for this card the overlay can only do up scaling so when > > you want to downscale you have to either don't use the overlay at > > all or downscale when copying to the overlay mem and resetup > > the overlay source size. > > So i doubt that we can really get every bit of performance out of > > every card with a general approch. > > Perhaps that most modern cards can be well handled in general way > > but i doubt we'll find an interface wich will suit every kind of > > card with scaleing and/or colorspace conversion caps. > > As far as I can tell, all we need so far is a CAN_DOWNSCALE flag and a > list of supported colorspaces... Doesn't sound too hard. VO drivers > are already required to identify whether or not they can downscale, so > the vo driver could just return the flag from the *_vid driver. Sure. My point was more that in some case it's possible but then it requiere some special trick wich can be hardly handled in a generic way. > As for non-overlay-based scalers, I think they're best kept separate. > I was talking about a general driver architecture for video overlays > (like vidix was supposed to be, except non-broken), not for all video > scaling and colorspace conversion stuff. Ok then tdfx_vid should probaly be renamed to something else ;) Albeu From arpi at thot.banki.hu Thu May 15 15:15:19 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 15:15:19 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515135434.23b87b4b.albeu@free.fr> Message-ID: <200305151315.h4FDFJsI015334@mail.mplayerhq.hu> Hi, > > > Until now imho there is no big problem with implementing such stuff. > > > The only problematic thing that i can see is the current main problem > > > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem > > > leak vs. static values. > > > If we strictly deal with struct that are create by (properly) copying > > > the default stuct it's not a problem as we will only have dynamiclly > > > allocted stuff. > > > But if we also want to operate on 'normal' vars (we probably want) > > > then it's a problem. > > > In current G1 it's solved with a hack (when options are registered > > > in the context saving system those who use dynamicly allocted > > > mem (like string) have their initial value replaced by a copy of it > > > so there is then only dynamic stuff). If somebody know how one can > > > tell if a mem area was dynamiclly allocated or not then it's easy > > > to solve. Othewise i really can't think of smthg clean. > > > > Sure, i was also thinking of it yesterday. > > The best would be to store somewhere (but where???) a flag telling the > > config system that the given field (string) was allocated by the config > > sys. It isn't really doable. > > The question is should that be handled in layer2 or layer3. In G1 it's > handled at layer3 but that not optimal bcs it's a tricky operation > and it don't really belong there in fact (and make a layer3 > implementation harder). > Layer2 implement string <-> C conversions, so it should also implement > copy of the C values (and destroy/free). This is requiered when first > creating a copy of the default struct bcs of the dynmamiclly allocated > stuff for wich simple memcpy isn't enought. yes > So this 'protection' against freeing of static vars is required at > layer2 imho. If we forbid double options (ie 2 options pointing > to the same C var) for option type wich use dynamic mem then we > can simply store a flag in the config_t struct wich indicate if > the mem was allocated or not. no, unfortunatelly you (config parser) can't store flags in config_t, as it's shared between several instances (consider it read-only). > If we allow double options on dynamic stuff i really can't think > of a way to handle that at layer2 (beside smthg a la njamd ;) :) > On the other hand it's not a big limitation as double options > are mostly used for flags (wich are not using dynamic mem) and > to keep backward comp. > > > The opposite approach is what you said: always duplicate (alloc+copy) > > everything, so you can safely free() at the end. I guess this is the only way, ie. always alloc+copy. > > The 3rd approach is not free() at all, it isn't big memory leak :) > If you consider a server app wich should run for months it is really > an important problem. why? i don't think that a server app keeps parsing config files for months :) it will parse it once at startup. 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 May 15 15:28:15 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 15:28:15 +0200 Subject: [MPlayer-G2-dev] GUI-related config (layer-0) metadata Message-ID: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> Hi, this thread is for the GUI/Frontend developers! As we discussed in layered config draft thread, the config_t structure could carry some extra information to help the GUI engine to build settings/preferences panels runtime, for any plugin (even unknown ones). See what are the other options: - modules/plugins may have builtin GUI configuration panels, "nice" examples are xmms plugins and win32 codecs (especially acm/vfw ones) - modules/plugins may have GUI "coded" in bloated XML description language, like the one used by Mozilla. - export only minimal info, like option type and min/max values - export detailed info along basics (type/min/max): for example relative position to the other options (column number?), recommended widget type, short name for GUI use (for exmaple: "Postprocessing level") and so on. i vote for the last one. first option (built-in gui) is unacceptable, second is overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to interpret and run the xml gui :)), third is probably not enough. comments? recommendations for gui-related fields into config_t, if we agree on teh 4th solution? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu May 15 15:05:12 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 16:05:12 +0300 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <20030515141913.1d3306c1.albeu@free.fr> References: <200305132214.h4DMErk3008527@mail.mplayerhq.hu> <20030514161538.GA9528@lucky.net> <20030514211105.55c8ad8b.albeu@free.fr> <20030514201745.GA64126@lucky.net> <20030515103642.2307e16b.albeu@free.fr> <20030515101651.GC24343@lucky.net> <20030515141913.1d3306c1.albeu@free.fr> Message-ID: <20030515130512.GG24343@lucky.net> Hi, Alban Bedel! Sometime (on Thursday, May 15 at 15:32) I've received something... >> >> CONF_TYPE_CHOOSE is string that could have only few fixed choises (in >> >> Gui it will be combobox). For example - oac:lame:mode may have values >> >> "1","2", "3", "4" or "stereo", "joint", "dual", "mono". >> >Ok i think i get it. But then i don't get why you define the possible >> >values with a config_t array. >> Because parameters of that may have different types. >That's pure non-sense !!! An option is related to a C variable and But CONF_TYPE_CHOOSE is really _not_ string _but_ subconfig. Just look at it better. String at ->p is _only_ for reference (and may be omitted in many cases). All difference between CONF_TYPE_SUBCONFIG and CONF_TYPE_CHOOSE is that CONF_TYPE_CHOOSE cannot have more than one subparameter but CONF_TYPE_SUBCONFIG may have as many as need. Did you understand now? :) >afaik a C var can't have sevral type. So if the option is an integer >it can't be a string at the same time !!!! We can provide different >representations for the user (ie if 1==stereo then -oac lame=mode=1 >is equivalent to -oac lame=mode=stereo). But an single option >can't set both an int and/or a string. See above. >> See example >> below. Anyway if we have only string parameter but choises are just >> flags then module have to parse that string by itself and set these >> flags. In case of Gui it's even worse - Gui must allocate that string >> then pass it to module so we have two conversions - from Gui internal >> into string then from string into flag by module. Remember that Gui will >> not use option->name for own (because that field is for commandline or >> config parser) but use option->desc instead. >Again no app is forced to use more than the layer0. If you don't want >to deal with strings in your GUI just stick with layer0. Then you can >handle each option type in the way that you want. Again. Do you have to recongnise if that option has to be parsed differently and have another types of ->p and ->priv? So CONF_TYPE_* are created to make that difference, isn't it? I hope I've answered to your question. :) >> >As i said it's overkill for the simple case like string list. For >> >string case we could reduce that to: >> >->p : char** >> >->priv : char** >> >where priv contain all possible values. >> >> We cannot, unfortunately. For example, we have an option '-fstype'. >> It's string list. It may have only few choises - "none","layer","above", >> "below","fullscreen", and "stays_on_top". All except "layer" are flag >> type options but layer must have integer parameter. >???????? There is an option '-fstype' in G1. How do you propose to parse it? It has _only_ simple C type parameters but these parameters are different type. Ok, we can change that syntax from "above,stays_on_top,layer=1" to "above:stays_on_top:layer=1" to have just CONF_TYPE_SUBCONFIG but why we have to change a current syntax? >Again an option value must be of a well defined type. You can't shouldn't >mix different value types. Also "none","layer","above", etc aren't flags, >they are modules (wich can optionaly take parameters) like vf, af, etc >are. What is option value for subconfig? See my comment above. CONF_TYPE_LIST is also subconfig - it really is combination of CONF_TYPE_STRING_LIST and CONF_TYPE_SUBCONFIG. If you have choises as modules then you are right - we have to have only list of these with parameters. But if you have choises as list of some flags or values then why you have to force application parse it by itself (since you never have subconfig to parse it by config parser)? I cannot understand that step back. >> So you still can do this anyway - flag CONF_SEQUENT (may be, rename >> it to CONF_UNNAMED?) don't deny you have named parameters but contrary, >> allow you have unnamed ones. :) I hope, you understood me now. I don't >> like to be forced to type names for all filter options but I don't like >> to allow stupid user type "-info Me:NewFilm" also. >I will NEVER do smthg that arm power users just for the shake of stupid >users. Are you so spite on users? :) But anyway - what's bad with flag CONF_SEQUENT? Other hand it's flag CONF_MUST_HAVE_A_NAME but with other sign. Why do you after forcing user to write "opt=value" instead of "value" for some options? Why you want to allow just "value" always? I didn't get it, sorry. Andriy. From andrej at lucky.net Thu May 15 15:20:36 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 16:20:36 +0300 Subject: [MPlayer-G2-dev] Re: GUI-related config (layer-0) metadata In-Reply-To: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> References: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> Message-ID: <20030515132036.GH24343@lucky.net> Hi, Arpi! Sometime (on Thursday, May 15 at 15:56) I've received something... >this thread is for the GUI/Frontend developers! >As we discussed in layered config draft thread, the config_t structure >could carry some extra information to help the GUI engine to build >settings/preferences panels runtime, for any plugin (even unknown ones). >See what are the other options: >- modules/plugins may have builtin GUI configuration panels, "nice" examples > are xmms plugins and win32 codecs (especially acm/vfw ones) >- modules/plugins may have GUI "coded" in bloated XML description language, > like the one used by Mozilla. >- export only minimal info, like option type and min/max values >- export detailed info along basics (type/min/max): for example relative > position to the other options (column number?), recommended widget type, > short name for GUI use (for exmaple: "Postprocessing level") and so on. >i vote for the last one. Count my vote for the same. :) >first option (built-in gui) is unacceptable, second is >overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to interpret >and run the xml gui :)), third is probably not enough. >comments? recommendations for gui-related fields into config_t, if we >agree on teh 4th solution? I'm not sure if we have to add more than one field for gui-related stuff. I'm really not very familiar with GUI widgets and I'm not sure if every module author is very familiar. So I think we could preserve some flags with hints for GUI (which will be clear for any author) but nothing more. About widget type - I think it's precisely defined by option type. With best wishes. Andriy. From pnis at coder.hu Thu May 15 15:42:11 2003 From: pnis at coder.hu (Balatoni Denes) Date: Thu, 15 May 2003 15:42:11 +0200 Subject: [MPlayer-G2-dev] GUI-related config (layer-0) metadata In-Reply-To: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> References: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> Message-ID: <200305151542.11831.pnis@coder.hu> Hi! On 2003. m?jus 15. 15.28, Arpi wrote: > - export only minimal info, like option type and min/max values > - export detailed info along basics (type/min/max): for example relative > position to the other options (column number?), recommended widget type, > short name for GUI use (for exmaple: "Postprocessing level") and so on. > > i vote for the last one. > first option (built-in gui) is unacceptable, second is > overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to interpret > and run the xml gui :)), third is probably not enough. i agree, 3 and 4 sound good to me. imho grouping for now is enough, ie. every option has a group number (and than a group info /name,whatever/ can be stored too for each group), and than the gui can place it as it wants to. I don't know what real advantage an additional preferred widget type info has over just the type of the option - if you know any, than that's good too. And than maybe an additional field for later improvements or something. best regards Denes From arpi at thot.banki.hu Thu May 15 15:52:13 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 15 May 2003 15:52:13 +0200 Subject: [MPlayer-G2-dev] GUI-related config (layer-0) metadata In-Reply-To: <200305151542.11831.pnis@coder.hu> Message-ID: <200305151352.h4FDqD1V027603@mail.mplayerhq.hu> Hi, > > i vote for the last one. > > first option (built-in gui) is unacceptable, second is > > overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to interpret > > and run the xml gui :)), third is probably not enough. > > i agree, 3 and 4 sound good to me. imho grouping for now is enough, ie. every > option has a group number (and than a group info /name,whatever/ can be > stored too for each group), and than the gui can place it as it wants to. I grouping sounds like a good idea > don't know what real advantage an additional preferred widget type info has > over just the type of the option - if you know any, than that's good too. you can 'visualize' an integer parameter in many ways. from manual typing, through various slidebars (may be linear or logarithmic), combobox etc. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Thu May 15 16:10:40 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 17:10:40 +0300 Subject: Iive's version Re: [MPlayer-G2-dev] g2 config - restart... In-Reply-To: <200305142041.h4EKf2fd003972@mail.mplayerhq.hu> References: <1150.212.116.158.165.1052863234.squirrel@mail.cacad.com> <200305142041.h4EKf2fd003972@mail.mplayerhq.hu> Message-ID: <20030515141040.GI24343@lucky.net> Hi, Arpi! Sometime (on Wednesday, May 14 at 23:05) I've received something... >imho it could also solve the problem of module-dependant options which may >not be available always when parsing configfiles. Configfile's parser has to keep these options and application will ask parser for these to set defaults on module open. IMHO, it's the best solution. >btw i don't know yet teh naming convention for core and modules. >for example it could be: >demuxer.soemvar=123 >demuxer.avi.something=456 >or: >demuxer.core.somevar=123 >demuxer.avi.something=456 >or >demuxer.core.somevar=123 >demuxer.modules.avi.something=456 >or >demuxer.somevar=123 >demux_avi.something=456 >better ideas? It was something like somevar and vf:filter:something already and I like that form with point also. So I think if we let it be: somevar=123 demuxer.avi.something=456 then it will be the best solution since it will not change syntax as much as possible (I'm lazy and some others too, I bet). But I don't mind if we will get demuxer.somevar instead of somevar despite of some headache when we will move to new syntax. Andriy. From lgb at lgb.hu Thu May 15 16:59:33 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Thu, 15 May 2003 16:59:33 +0200 Subject: [MPlayer-G2-dev] GUI-related config (layer-0) metadata In-Reply-To: <200305151352.h4FDqD1V027603@mail.mplayerhq.hu> References: <200305151542.11831.pnis@coder.hu> <200305151352.h4FDqD1V027603@mail.mplayerhq.hu> Message-ID: <20030515145933.GA18148@vega.digitel2002.hu> On Thu, May 15, 2003 at 03:52:13PM +0200, Arpi wrote: > Hi, > > > > i vote for the last one. > > > first option (built-in gui) is unacceptable, second is > > > overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to interpret > > > and run the xml gui :)), third is probably not enough. > > > > i agree, 3 and 4 sound good to me. imho grouping for now is enough, ie. every > > option has a group number (and than a group info /name,whatever/ can be > > stored too for each group), and than the gui can place it as it wants to. I Also maybe some OSD menu :) can grouping according this information, too? :) - G?bor (larta'H) From danchr at daimi.au.dk Thu May 15 18:10:30 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Thu, 15 May 2003 18:10:30 +0200 Subject: [MPlayer-G2-dev] GUI-related config (layer-0) metadata In-Reply-To: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> Message-ID: On Thursday, May 15, 2003, at 03:28 PM, Arpi wrote: > i vote for the last one. > first option (built-in gui) is unacceptable, second is > overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to > interpret > and run the xml gui :)), third is probably not enough. > > comments? recommendations for gui-related fields into config_t, if we > agree on teh 4th solution? I'd say having a function-based interface would be better. Accessing variables through a function has the advantage that something like input constraints could be handled directly. With a struct, you would need a complex interface to tell you that one option was set one. A function could return a non-zero value and set some errstring and/or errno. I believe this would be much more dynamic than a struct. A proposal: int module_get_option_type(module_t module, char *key, char **type); int module_get_option(module_t module, char *key, void **value); int module_set_option(module_t module, char *key, void *value); char **module_get_option_keys(module_t module); void **module_get_option_values(module_t module); char **module_get_option_types(module_t module); char *module_get_error_string(module_t module, int errno); - Dan From andrej at lucky.net Thu May 15 18:29:59 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 19:29:59 +0300 Subject: [MPlayer-G2-dev] Re: GUI-related config (layer-0) metadata In-Reply-To: References: <200305151328.h4FDSFgc028260@mail.mplayerhq.hu> Message-ID: <20030515162959.GK24343@lucky.net> Hi, Dan Christiansen! Sometime (on Thursday, May 15 at 19:11) I've received something... >On Thursday, May 15, 2003, at 03:28 PM, Arpi wrote: > >>i vote for the last one. >>first option (built-in gui) is unacceptable, second is >>overcomplicated/bloated (hehe embedd mozilla into mplayer-g2 to >>interpret >>and run the xml gui :)), third is probably not enough. >> >>comments? recommendations for gui-related fields into config_t, if we >>agree on teh 4th solution? > >I'd say having a function-based interface would be better. Accessing >variables through a function has the advantage that something like >input constraints could be handled directly. With a struct, you would >need a complex interface to tell you that one option was set one. A >function could return a non-zero value and set some errstring and/or >errno. I believe this would be much more dynamic than a struct. You're saying about implementation not API, sorry. API must consist of struct describing all variables. >A proposal: >int module_get_option_type(module_t module, char *key, char **type); You want implementing searching mechanism in module? It's unwanted since it may (and must) be implemented in application. >int module_get_option(module_t module, char *key, void **value); You need there also know option's size and type, etc. because you'll not know what you'll get in that void pointer. :) >int module_set_option(module_t module, char *key, void *value); The same as above. >char **module_get_option_keys(module_t module); >void **module_get_option_values(module_t module); >char **module_get_option_types(module_t module); It's overcomplicated - to parse each variable thru searching. >char *module_get_error_string(module_t module, int errno); It may be resonable but it's function of parser, not module, sorry. With best wishes. Andriy. From albeu at free.fr Thu May 15 17:56:11 2003 From: albeu at free.fr (Alban Bedel) Date: Thu, 15 May 2003 17:56:11 +0200 Subject: [MPlayer-G2-dev] Re: g2 config - restart... In-Reply-To: <200305151315.h4FDFJsI015334@mail.mplayerhq.hu> References: <20030515135434.23b87b4b.albeu@free.fr> <200305151315.h4FDFJsI015334@mail.mplayerhq.hu> Message-ID: <20030515175611.1e7e9e79.albeu@free.fr> Hi Arpi, on Thu, 15 May 2003 15:15:19 +0200 you wrote: > Hi, > > > > > Until now imho there is no big problem with implementing such > > > > stuff. The only problematic thing that i can see is the current > > > > main problem of the 'new' config code in G1 : dynamicly allocated > > > > stuff vs. mem leak vs. static values. > > > > If we strictly deal with struct that are create by (properly) > > > > copying the default stuct it's not a problem as we will only have > > > > dynamiclly allocted stuff. > > > > But if we also want to operate on 'normal' vars (we probably want) > > > > then it's a problem. > > > > In current G1 it's solved with a hack (when options are registered > > > > in the context saving system those who use dynamicly allocted > > > > mem (like string) have their initial value replaced by a copy of > > > > it so there is then only dynamic stuff). If somebody know how one > > > > can tell if a mem area was dynamiclly allocated or not then it's > > > > easy to solve. Othewise i really can't think of smthg clean. > > > > > > Sure, i was also thinking of it yesterday. > > > The best would be to store somewhere (but where???) a flag telling > > > the config system that the given field (string) was allocated by the > > > config sys. It isn't really doable. > > > > The question is should that be handled in layer2 or layer3. In G1 it's > > handled at layer3 but that not optimal bcs it's a tricky operation > > and it don't really belong there in fact (and make a layer3 > > implementation harder). > > Layer2 implement string <-> C conversions, so it should also implement > > copy of the C values (and destroy/free). This is requiered when first > > creating a copy of the default struct bcs of the dynmamiclly allocated > > stuff for wich simple memcpy isn't enought. > > yes > > > So this 'protection' against freeing of static vars is required at > > layer2 imho. If we forbid double options (ie 2 options pointing > > to the same C var) for option type wich use dynamic mem then we > > can simply store a flag in the config_t struct wich indicate if > > the mem was allocated or not. > > no, unfortunatelly you (config parser) can't store flags in config_t, > as it's shared between several instances (consider it read-only). Well here i'm strictly talking about options appling to a 'static' vars, not those who describe some struct fields. So they shouldn't be shared (or am i missing smthg ?). Options wich describe struct fields don't have this problem as in this case the only thing that we'll is copying the 'default' struct. But you'r right that config_t should be considered read-only. > > If we allow double options on dynamic stuff i really can't think > > of a way to handle that at layer2 (beside smthg a la njamd ;) > :) > > > On the other hand it's not a big limitation as double options > > are mostly used for flags (wich are not using dynamic mem) and > > to keep backward comp. > > > > > The opposite approach is what you said: always duplicate > > > (alloc+copy) everything, so you can safely free() at the end. > > I guess this is the only way, ie. always alloc+copy. Seems so sadly. > > > The 3rd approach is not free() at all, it isn't big memory leak :) > > If you consider a server app wich should run for months it is really > > an important problem. > > why? i don't think that a server app keeps parsing config files for > months :) it will parse it once at startup. Well an option wich is related to a 'static' var may be setted an unlimited number of time, for example betwen each file. Albeu From danchr at daimi.au.dk Thu May 15 20:15:21 2003 From: danchr at daimi.au.dk (Dan Christiansen) Date: Thu, 15 May 2003 20:15:21 +0200 Subject: [MPlayer-G2-dev] Re: GUI-related config (layer-0) metadata In-Reply-To: <20030515162959.GK24343@lucky.net> Message-ID: <30AE5A08-8701-11D7-A8EF-000A27B4ECCA@daimi.au.dk> On Thursday, May 15, 2003, at 06:29 PM, Andriy N. Gritsenko wrote: > You're saying about implementation not API, sorry. API must consist > of struct describing all variables. It seems like were talking about two different things; I'm talking about how a GUI application would manipulate the modules, you're talking about how the module/mplayer config interface should be. Actually, I'm saying the exact opposite; a function-based interface would be much more dynamic and interface better with the object oriented design of a GUI. What's behind the interface is a completely different matter. You could have the module/mplayer interface consist of a struct and have the GUI/module (via mplayer) interface consist of a set of functions which mplayer would interpret and manipulate with said functions. > You want implementing searching mechanism in module? It's unwanted > since it may (and must) be implemented in application. It could be implemented in mplayer. It's a very simple way of accessing options. >> int module_get_option(module_t module, char *key, void **value); > > You need there also know option's size and type, etc. because > you'll > not know what you'll get in that void pointer. :) You're right - I'm fairly new to C :) > >> int module_set_option(module_t module, char *key, void *value); > > The same as above. > >> char **module_get_option_keys(module_t module); >> void **module_get_option_values(module_t module); >> char **module_get_option_types(module_t module); > > It's overcomplicated - to parse each variable thru searching. No, it's to extract all values to store them in the GUI application. A GUI developer might want to store it in a different way, or might want to iterate through them. Anyway, accessing all options is necessary prior to displaying the visual interface. > >> char *module_get_error_string(module_t module, int errno); > > It may be resonable but it's function of parser, not module, sorry. Nonetheless, it would be useful in the API ie. the interface. - Dan From andrej at lucky.net Thu May 15 20:28:28 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 15 May 2003 21:28:28 +0300 Subject: [MPlayer-G2-dev] Re: GUI-related config (layer-0) metadata In-Reply-To: <30AE5A08-8701-11D7-A8EF-000A27B4ECCA@daimi.au.dk> References: <20030515162959.GK24343@lucky.net> <30AE5A08-8701-11D7-A8EF-000A27B4ECCA@daimi.au.dk> Message-ID: <20030515182828.GM24343@lucky.net> Hi, Dan Christiansen! Sometime (on Thursday, May 15 at 21:16) I've received something... >> You're saying about implementation not API, sorry. API must consist >>of struct describing all variables. >It seems like were talking about two different things; I'm talking >about how a GUI application would manipulate the modules, you're >talking about how the module/mplayer config interface should be. >Actually, I'm saying the exact opposite; a function-based interface >would be much more dynamic and interface better with the object >oriented design of a GUI. What's behind the interface is a completely >different matter. You could have the module/mplayer interface consist >of a struct and have the GUI/module (via mplayer) interface consist of >a set of functions which mplayer would interpret and manipulate with >said functions. Ah, I've got it. :) So anyway these are details of GUI-driven application implementation. It's too early to talk about this since common API for options isn't ready yet. But I'll glad to talk about it later, because I wanted to write GUI encoder but I'm novice at GUI at all. BTW, I agree with you that modularized structure of application is better than cross-linked. :) >It could be implemented in mplayer. It's a very simple way of accessing >options. Arpi already said it here - something alike of level 2 and 3, it's for mplayer internal parser module. It's not my concert at the time. May be later but may be not - I've too busy or lazy sometimes. ;) With best wishes. Andriy. From arpi at thot.banki.hu Fri May 16 01:46:07 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 16 May 2003 01:46:07 +0200 Subject: [MPlayer-G2-dev] pre25: ogg demuxer finished Message-ID: <200305152346.h4FNk7fK023618@mail.mplayerhq.hu> Hi, I've (almost) finished the ogg demuxer (and related codecs suppoert), now it plays all sample files i have properly, with <0.001sec A-V desync. Supported: - vorbis audio (ported from g1) - theora video (note it was broken in pre24, due to silly vf_vo2 bug) - video in directshow/OLD format (bitmapinfoheader stored) - video in directshow/NEW format (stream_header stored) - audio in directshow/NEW format (stream_header stored) [only ac3 tested] Unsupported: - text (in directshow/NEW format) streams (is it always subtitle?) - audio in directshow/OLD format (waveformatex stored???) - i need sample file! Note that the ogg demuxer is still <10kB :) (and at least 6k of 10k is codec-specific header parsing hacks...) Note 2: i've found that granule_pos field of ogg's page header is signed, at least i have sample file using negative values. g1's ogg demuxer failed to handle that file (it assumes unsigend value): samples/ogg/broken_syn_in_linux.ogm Note 3: there is a sample at mphq with DX50 (Divx 5.0) video using B frames. In that file, timestamps seem to be in display order, but vd_ffmpeg doesn't handle PTS reordering yet. Afair libavcodec supports it (Kabi told me once) so it could be implemented. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Fri May 16 13:02:02 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 16 May 2003 07:02:02 -0400 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <200305151008.h4FA8PtN018697@mail.mplayerhq.hu> References: <20030515093037.GA8130@brightrain.aerifal.cx> <200305151008.h4FA8PtN018697@mail.mplayerhq.hu> Message-ID: <20030516110202.GA23552@brightrain.aerifal.cx> On Thu, May 15, 2003 at 12:08:25PM +0200, Arpi wrote: > > 2. Dirty stride arithmetic tricks... :)) If the vo's buffer is an > > overlay in video memory, chances are good that you can customize > > the source width, source height, origin, and stride independent of > > the actual pixel layout in video memory. Is there some way we could > > let the filter chain take advantage of this? For example, the crop > > filter could let DR go right through it, allocating a buffer the > > size of the source image in video memory, but then only configuring > > the desired part of it to be visible. Another potential use is > > using stride arithmetic for deinterlacing, i.e. writing the whole > > interlaced picture to video memory, but selecting only one field to > > be visible at a time. > > vo2 api is capable (RESIZE_SRC), but as you said it's not eays to implement > cleanly. maybe the best way is implementing these as options to vf_vo2 > filter. or maybe we could drive this control through the filter layer, so > filters like fields or crop could query if RESIZE_SRC is available and use > that instead of copy. (like the DRAW_OSD, VIDEO_EQ or SCALE controls in g1) Arpi, I think I figured out what I meant for point #2... What I'd like to see is a way whereby the filter chain can get a pointer to an area in video memory from the vo driver, then give it back to the vo driver as an *export* image, i.e. specifying its own pointer somewhere inside video memory and stride. Naturally this would only work for very flexible vo drivers, but it would be nice and powerful and clean! Of course, the vo could tell the filter the minimum power of 2 that would have to divide stride, and likewise how aligned the origin offset would have to be... Rich From nexus at irc.pl Fri May 16 13:32:00 2003 From: nexus at irc.pl (Bohdan Horst) Date: Fri, 16 May 2003 13:32:00 +0200 Subject: [MPlayer-G2-dev] g2p25 FreeBSD patch - $(VORBIS_LIB) Message-ID: <20030516113200.GA15431@essus.net> FreeBSD g2p25 patch - $(VORBIS_LIB): -- / irl: Bohdan 'Nexus' Horst | irc: Nexus \ {----------------------v-------^---------------} \ http://irc.pl/nexus | mailto: nexus at irc.pl / -------------- next part -------------- --- Makefile.old Fri May 16 10:13:39 2003 +++ Makefile Fri May 16 10:14:41 2003 @@ -76,10 +76,10 @@ test-codecs: $(OBJS) $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a test-codecs.o # FIXME: for some odd reason the gCpuCaps symbol will be undefined on Darwin # unless osdep/cpudetect.o is explicitely linked - $(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(THEORA_LIB) $(I18NLIBS) -lm + $(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(VORBIS_LIB) $(THEORA_LIB) $(I18NLIBS) -lm test-play: $(OBJS) $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a test-play.o input/libinput.a - $(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(THEORA_LIB) $(I18NLIBS) -lm + $(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB) $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(VORBIS_LIB) $(THEORA_LIB) $(I18NLIBS) -lm test-input: test-input.o input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(CC) test-input.o -o test-input input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(EXTRA_LIB) $(TERMCAP_LIB) $(LIRC_LIB) $(I18NLIBS) $(MACOSX_FRAMEWORKS) From arpi at thot.banki.hu Fri May 16 15:36:21 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 16 May 2003 15:36:21 +0200 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <20030516110202.GA23552@brightrain.aerifal.cx> Message-ID: <200305161336.h4GDaLuF029083@mail.mplayerhq.hu> Hi, > Arpi, I think I figured out what I meant for point #2... great, then re-try to explain, this is nonsence: > What I'd like to see is a way whereby the filter chain can get a > pointer to an area in video memory from the vo driver, then give it > back to the vo driver as an *export* image, i.e. specifying its own > pointer somewhere inside video memory and stride. Naturally this would you mean indeirect rendering? even ten the vo driver must provide a buffer struct, and it may have pointers/stride it in (will be ignored by filters but will be give back to vo driver together with export img) > only work for very flexible vo drivers, but it would be nice and > powerful and clean! Of course, the vo could tell the filter the > minimum power of 2 that would have to divide stride, and likewise how > aligned the origin offset would have to be... power of 2 to divide stride? wtf? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Fri May 16 23:27:34 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 16 May 2003 17:27:34 -0400 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <200305161336.h4GDaLuF029083@mail.mplayerhq.hu> References: <20030516110202.GA23552@brightrain.aerifal.cx> <200305161336.h4GDaLuF029083@mail.mplayerhq.hu> Message-ID: <20030516212734.GB23552@brightrain.aerifal.cx> On Fri, May 16, 2003 at 03:36:21PM +0200, Arpi wrote: > Hi, > > > Arpi, I think I figured out what I meant for point #2... > > great, then re-try to explain, this is nonsence: Haha, ok, sorry. :) > > What I'd like to see is a way whereby the filter chain can get a > > pointer to an area in video memory from the vo driver, then give it > > back to the vo driver as an *export* image, i.e. specifying its own > > pointer somewhere inside video memory and stride. Naturally this would > > you mean indeirect rendering? even ten the vo driver must provide a > buffer struct, and it may have pointers/stride it in (will be ignored > by filters but will be give back to vo driver together with export img) I'm saying some drivers (not current mga_vid implementation, but certainly the mga bes hardware, and probably other cards' scalers) *don't* have to demand the image be at a particular location or have a particular stride. Instead, they could just allocate a block of video memory for the filter to use, and let the filter setup the origin and stride for it, to be passed back as an export-type mpi (or some similar mechanism). > > only work for very flexible vo drivers, but it would be nice and > > powerful and clean! Of course, the vo could tell the filter the > > minimum power of 2 that would have to divide stride, and likewise how > > aligned the origin offset would have to be... > > power of 2 to divide stride? wtf? Same deal as stride alignment. For example requiring stride%16==0. Rich From arpi at thot.banki.hu Sat May 17 00:42:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 17 May 2003 00:42:43 +0200 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <20030516212734.GB23552@brightrain.aerifal.cx> Message-ID: <200305162242.h4GMghZX016496@mail.mplayerhq.hu> Hi, > > > Arpi, I think I figured out what I meant for point #2... > > > > great, then re-try to explain, this is nonsence: > > Haha, ok, sorry. :) > > > > What I'd like to see is a way whereby the filter chain can get a > > > pointer to an area in video memory from the vo driver, then give it > > > back to the vo driver as an *export* image, i.e. specifying its own > > > pointer somewhere inside video memory and stride. Naturally this would > > > > you mean indeirect rendering? even ten the vo driver must provide a > > buffer struct, and it may have pointers/stride it in (will be ignored > > by filters but will be give back to vo driver together with export img) > > I'm saying some drivers (not current mga_vid implementation, but > certainly the mga bes hardware, and probably other cards' scalers) > *don't* have to demand the image be at a particular location or have a > particular stride. Instead, they could just allocate a block of video > memory for the filter to use, and let the filter setup the origin and > stride for it, to be passed back as an export-type mpi (or some > similar mechanism). ah, now i understand. the silly thing is that it's actually doable in g1, but not in g2 :)) i don't like the idea of exporting raw video memory, but it could be better to pass stride hints to vo2->get_buffer(). but actually it has no much sense, in practice. why? it's rare that codecs can (effectively) decode to video memory directly, and these codecs are designed to accept stride, for this purpose. the other thing which can render to slow videoram is some filters, like scale, expand, some postprocess/csp conversion, but they all accept stride. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Sat May 17 05:16:14 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Fri, 16 May 2003 23:16:14 -0400 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <200305162242.h4GMghZX016496@mail.mplayerhq.hu> References: <20030516212734.GB23552@brightrain.aerifal.cx> <200305162242.h4GMghZX016496@mail.mplayerhq.hu> Message-ID: <20030517031614.GC23552@brightrain.aerifal.cx> On Sat, May 17, 2003 at 12:42:43AM +0200, Arpi wrote: > Hi, > > > > > Arpi, I think I figured out what I meant for point #2... > > > > > > great, then re-try to explain, this is nonsence: > > > > Haha, ok, sorry. :) > > > > > > What I'd like to see is a way whereby the filter chain can get a > > > > pointer to an area in video memory from the vo driver, then give it > > > > back to the vo driver as an *export* image, i.e. specifying its own > > > > pointer somewhere inside video memory and stride. Naturally this would > > > > > > you mean indeirect rendering? even ten the vo driver must provide a > > > buffer struct, and it may have pointers/stride it in (will be ignored > > > by filters but will be give back to vo driver together with export img) > > > > I'm saying some drivers (not current mga_vid implementation, but > > certainly the mga bes hardware, and probably other cards' scalers) > > *don't* have to demand the image be at a particular location or have a > > particular stride. Instead, they could just allocate a block of video > > memory for the filter to use, and let the filter setup the origin and > > stride for it, to be passed back as an export-type mpi (or some > > similar mechanism). > > ah, now i understand. > the silly thing is that it's actually doable in g1, but not in g2 :)) > > i don't like the idea of exporting raw video memory, but it could be better > to pass stride hints to vo2->get_buffer(). > > but actually it has no much sense, in practice. > why? it's rare that codecs can (effectively) decode to video memory > directly, and these codecs are designed to accept stride, for this purpose. > the other thing which can render to slow videoram is some filters, like > scale, expand, some postprocess/csp conversion, but they all accept stride. The idea isn't that these filters can't accept stride. It's that they can do their work without doing anything :))) by manipulating origins and strides. For example, a crop filter could allocate enough video memory with the right stride for the previous filter (e.g. scale) to render the source image into, then 'export' that buffer back to the vo to just display the 'cropped' part. As another thought, consider interlaced mess. You could use 2x stride when exporting video memory back to the vo to only show one field, or do other similar hacks. Probably most of this can be done by other methods without too much performance loss, tho, so maybe it's all nonsense. :) Rich From arpi at thot.banki.hu Sat May 17 18:40:45 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 17 May 2003 18:40:45 +0200 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <20030517031614.GC23552@brightrain.aerifal.cx> Message-ID: <200305171640.h4HGejse003009@mail.mplayerhq.hu> Hi, > > > > > What I'd like to see is a way whereby the filter chain can get a > > > > > pointer to an area in video memory from the vo driver, then give it > > > > > back to the vo driver as an *export* image, i.e. specifying its own > > > > > pointer somewhere inside video memory and stride. Naturally this would > > > > > > > > you mean indeirect rendering? even ten the vo driver must provide a > > > > buffer struct, and it may have pointers/stride it in (will be ignored > > > > by filters but will be give back to vo driver together with export img) > > > > > > I'm saying some drivers (not current mga_vid implementation, but > > > certainly the mga bes hardware, and probably other cards' scalers) > > > *don't* have to demand the image be at a particular location or have a > > > particular stride. Instead, they could just allocate a block of video > > > memory for the filter to use, and let the filter setup the origin and > > > stride for it, to be passed back as an export-type mpi (or some > > > similar mechanism). > > > > ah, now i understand. > > the silly thing is that it's actually doable in g1, but not in g2 :)) > > > > i don't like the idea of exporting raw video memory, but it could be better > > to pass stride hints to vo2->get_buffer(). > > > > but actually it has no much sense, in practice. > > why? it's rare that codecs can (effectively) decode to video memory > > directly, and these codecs are designed to accept stride, for this purpose. > > the other thing which can render to slow videoram is some filters, like > > scale, expand, some postprocess/csp conversion, but they all accept stride. > > The idea isn't that these filters can't accept stride. It's that they > can do their work without doing anything :))) by manipulating origins > and strides. For example, a crop filter could allocate enough video > memory with the right stride for the previous filter (e.g. scale) to you should do crop before scale/blit/etc. this is the main point! > render the source image into, then 'export' that buffer back to the vo > to just display the 'cropped' part. As another thought, consider > interlaced mess. You could use 2x stride when exporting video memory > back to the vo to only show one field, or do other similar hacks. > > Probably most of this can be done by other methods without too much > performance loss, tho, so maybe it's all nonsense. :) imho we should avoid this kind of hacks in g2, at least for now. i can't see a good enough reason to implement it, and it would be a hack actually. btw if you really want it, it is doable then easily, just create a new flag in vfcap.h, for example VFCAP_MESS_WITH_POINTERS or sth :) and set in vo drivers supporting it. Then you can check it in vf_crop and change the pointers freely after get_image. Vo drivers supporting this mess should check (and update the hw) buffer->planes/stride in their frame_done(). but i still no see advantages of it. btw, about interlacing. i'm thinking of interlacing support in vf layer, and so in codecs/vo too. it would mean a 'field' parameter in mpi, 0=frame 1=top 2=bottom field. if both vo, codec and filters inbetween supports fields, then codec could decode per field and pass fields to vo, without 'interlacing them together'. btw 2, i'm thinking about a bigger change of the codec/vfilter layer, by dropping away mpi->type (MP_IMGTYPE_*) 'buffering templates' and introduce get_buffer/release_buffer style (already used in libavcodec). but i'm not sure if it's a really good idea... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Sat May 17 20:06:27 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sat, 17 May 2003 14:06:27 -0400 Subject: [MPlayer-G2-dev] extra dr types (oh no not more!! :) In-Reply-To: <200305171640.h4HGejse003009@mail.mplayerhq.hu> References: <20030517031614.GC23552@brightrain.aerifal.cx> <200305171640.h4HGejse003009@mail.mplayerhq.hu> Message-ID: <20030517180627.GF23552@brightrain.aerifal.cx> On Sat, May 17, 2003 at 06:40:45PM +0200, Arpi wrote: > > Probably most of this can be done by other methods without too much > > performance loss, tho, so maybe it's all nonsense. :) > > imho we should avoid this kind of hacks in g2, at least for now. OK, sounds fine. > btw, about interlacing. > i'm thinking of interlacing support in vf layer, and so in codecs/vo too. > it would mean a 'field' parameter in mpi, 0=frame 1=top 2=bottom field. > if both vo, codec and filters inbetween supports fields, then codec could > decode per field and pass fields to vo, without 'interlacing them together'. Yes, definitely. In addition, for interlaced fields paired into frames, there should be codes for bff and tff. For real 60 or 50 fps content, this is just nonsense of the way the mpeg2 is encoded. But for pulldown content, bff/tff really means something regarding the way the frames are done. In order to have filters that gracefully handle all the different cases (see samurix_detc.avi) without tons of user intervention, I think we need to have bff/tff flags, or at least a mode where the decoder outputs fields (in order). BTW, if the decoder inherently outputs fields, and mplayer has to have code to interleave those fields, I think it makes much more sense to move the interleaving OUT of the vd_* driver(s) and into its own vf_interleave or something. Then, based on user settings, we could auto-insert vf_interleave or else output translated/interpolated fields to the vo driver (with another filter) at 50/60 fps. This also allows scaling, denoising, sharpening, etc. of interlaced content to work without having to wrap the other filters in il=i:i and il=d:d. In reality, I think the ONLY time you'd want vf_interleave is when encoding interlaced video with a codec that expects interleaved fields, or when displaying on TVout. All other times, it'd be better to have the fields independent. > btw 2, i'm thinking about a bigger change of the codec/vfilter layer, > by dropping away mpi->type (MP_IMGTYPE_*) 'buffering templates' and > introduce get_buffer/release_buffer style (already used in libavcodec). > but i'm not sure if it's a really good idea... Perhaps explain how that would work in all the existing image type cases... I'm not so sure it's a good idea either -- it's harder to optimize buffer allocation when you don't know in advance how many buffers you'll need. Rich From arpi at thot.banki.hu Sat May 17 20:08:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 17 May 2003 20:08:17 +0200 Subject: [MPlayer-G2-dev] pre25: ogg demuxer finished In-Reply-To: <200305152346.h4FNk7fK023618@mail.mplayerhq.hu> Message-ID: <200305171808.h4HI8HJi021807@mail.mplayerhq.hu> Hi, ok there is pre26, with the vo2 related fixes/changes, mostly requested/reported by Faust3. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From saschasommer at freenet.de Sun May 18 12:57:09 2003 From: saschasommer at freenet.de (Sascha Sommer) Date: Sun, 18 May 2003 12:57:09 +0200 Subject: [MPlayer-G2-dev] pre25: ogg demuxer finished References: <200305171808.h4HI8HJi021807@mail.mplayerhq.hu> Message-ID: <000c01c31d2c$3b4a56c0$7bb1ebd9@oemcomputer> > Hi, > > ok there is pre26, with the vo2 related fixes/changes, mostly > requested/reported by Faust3. > Thank you. One more thing... num_buffers(): allocated #0: 00F2D920 num_buffers(): allocated #1: 00F2D948 num_buffers(2) -> 2 New buffer setup: 1 P + 1 B of total 2 (type=4 voflags=0x2) LOCKING f2d920 vf_vo2: DR n/a: can't read buffer (IMGFLAG_READABLE vs. BUFFER_VIDEORAM) *** [vo2] Allocating mp_image_t, 352x288x12bpp YUV planar, 152064 bytes vf_vo2: my_get_buffer() called with buffer!=NULL LOCKING f2d920 hm trying to unlock first UNLOCKING f2d920 vf_vo2: DR n/a: can't read buffer (IMGFLAG_READABLE vs. BUFFER_VIDEORAM) *** [vo2] Allocating mp_image_t, 352x288x12bpp YUV planar, 152064 bytes vf_vo2: my_get_buffer() called with buffer!=NULL LOCKING f2d920 hm trying to unlock first UNLOCKING f2d920 UNLOCKING f2d920 A: 0.263 (0.263) V: 0.230 (0.230) A-V: 0.0326 ct: 0.0000 d:0.325 x:0.000 LOCKING f2d948 *** [vo2] Direct Rendering mp_image_t, 352x288x12bpp YUV planar, 152064 bytes UNLOCKING f2d948 A: 0.263 (-0.000) V: 0.270 (0.040) A-V:-0.0074 ct: 0.0000 d:0.395 x:0.000 As you can see after those dr checks the buffers remain locked so further calls to frame_start and frame_done will fail if I do not unlock them in the vo. So is this the vo's job to unlock buffers if they are still locked or can vf_vo2 handle this? Sascha From arpi at thot.banki.hu Sun May 18 14:09:01 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 18 May 2003 14:09:01 +0200 Subject: [MPlayer-G2-dev] pre25: ogg demuxer finished In-Reply-To: <000c01c31d2c$3b4a56c0$7bb1ebd9@oemcomputer> Message-ID: <200305181209.h4IC918O002563@mail.mplayerhq.hu> Hi, > vf_vo2: my_get_buffer() called with buffer!=NULL hmm, this should NOT happen :( 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 May 19 11:17:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 19 May 2003 11:17:17 +0200 Subject: [MPlayer-G2-dev] cfg.h (config layer 0 discussion) Message-ID: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> Hi, Here's an updated/modified/extended/stipped :) version of Andriy's cfg.h: #ifndef __CFG_H #define __CFG_H 1 /* type (menu field) ->p ->min ->max ->priv */ typedef enum { // flag (checkbox) int* reset set - CONF_TYPE_FLAG=1, // integer (slider) int* min max - CONF_TYPE_INT, // float (slider) float* min max - CONF_TYPE_FLOAT, // position (slider) off_t* min max - CONF_TYPE_POSITION, // string (input box) char** min max - (min/max length) CONF_TYPE_STRING, // select list (combobox) int* - - config_select_list_t* CONF_TYPE_SELECT, // string list char*** min max - (min/max nr. of strings) // (comma-seperated list of strings, to be parsed later or to pass ordered list of strings) CONF_TYPE_STRING_LIST, // function void* arg1 arg2 (*parser_func)(void*,arg1,arg2) // (custom parser func for 3rd party plugins or special applications) CONF_TYPE_FUNC, // removed option - - - - // (removed option, parser should fail with error, with message from *desc, gui should ignore this) CONF_TYPE_OBSOLETE, // group separator - - - config_group_info_t* // (this is NOT a real option, but an option group definition, for gui use) CONF_TYPE_GROUP, //*** this is not a valid type, but the number of types: CONF_TYPE_MAX } config_type_t; typedef struct { int value; char* name; char* desc; } config_select_list_t; typedef struct { // TODO!!!! int dummy; } config_group_info_t; /* flags for options */ // 'min' value is given in config_t #define CONF_MIN (1<<0) // 'max' value is given in config_t #define CONF_MAX (1<<1) // both 'min' and 'max' value is given in config_t #define CONF_RANGE (CONF_MIN|CONF_MAX) // This option cannot be in config file #define CONF_NOCFG (1<<2) // This option cannot be in command line #define CONF_NOCMD (1<<3) // This option cannot (shouldn't) be visible in gui: #define CONF_NOGUI (1<<4) // This option can be used without explicit naming: #define CONF_UNNAMED (1<<5) typedef struct { char *name; void *p; /* pointer to variable where store result to, type specific */ config_type_t type; unsigned int flags; float min, max; /* valid range */ void *priv; /* additional pointer, type specific */ char *desc; /* short description for help and gui */ } config_t; /* note: version has to be first in ModuleInfo struct in loadable module to allow us always do validation/version check of module */ typedef struct { unsigned short type, version; // for loadable plugins char *name; char *desc; // short description for commandline help and gui char *maintainer; char *author; char *comment; config_t *config; void *config_defaults; int *config_size; // void *handle; } module_info_t; #endif /* __CFG_H */ Any questions/suggestions? (I've tried to apply the ideas/comments from that thread) Problem: we should store some reference inside the module_info_t struct to the actual module entry point (maybe the addess of the open() func? or the functions_t struct? do we need to store dlopen() handle there?) I'm trying to avoid the unification of all layer's API, but maybe we should decide between the open()-only (vo2, vf) and functions_t (ao2, ad, vd) style, and convert the looser. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 19 12:01:01 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 13:01:01 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> References: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> Message-ID: <20030519100101.GD70445@lucky.net> Hi, Arpi! Sometime (on Monday, May 19 at 12:16) I've received something... >Here's an updated/modified/extended/stipped :) version of Andriy's cfg.h: >#ifndef __CFG_H >#define __CFG_H 1 >/* type (menu field) ->p ->min ->max ->priv */ >typedef enum { >// flag (checkbox) int* reset set - > CONF_TYPE_FLAG=1, >// integer (slider) int* min max - > CONF_TYPE_INT, >// float (slider) float* min max - > CONF_TYPE_FLOAT, >// position (slider) off_t* min max - > CONF_TYPE_POSITION, >// string (input box) char** min max - (min/max length) > CONF_TYPE_STRING, >// select list (combobox) int* - - config_select_list_t* > CONF_TYPE_SELECT, Are you sure if limitation select list to int type only is enough? >// string list char*** min max - (min/max nr. of strings) >// (comma-seperated list of strings, to be parsed later or to pass ordered list of strings) > CONF_TYPE_STRING_LIST, >// function void* arg1 arg2 (*parser_func)(void*,arg1,arg2) >// (custom parser func for 3rd party plugins or special applications) > CONF_TYPE_FUNC, >// removed option - - - - >// (removed option, parser should fail with error, with message from *desc, gui should ignore this) > CONF_TYPE_OBSOLETE, >// group separator - - - config_group_info_t* >// (this is NOT a real option, but an option group definition, for gui use) > CONF_TYPE_GROUP, It was CONF_TYPE_DUMMY in mine, isn't it? But then we have to add into config_group_info_t* optional subconfig (config_t*). >//*** this is not a valid type, but the number of types: > CONF_TYPE_MAX >} config_type_t; Also I'm against of deleting CONF_TYPE_LIST here - it may be very useful in many of cases - I've written examples before. It you will stay only with CONF_TYPE_STRING_LIST then [G]UI has no ways to get hints which choises we have there. If you want to force [G]UI to have __only__ input field for string "any,some,next" then I don't think it's useful because we just deny [G]UI to have selection list box other than filters. If you want extra examples I could find more. And you were agree with me we have to have extended list type. :) >typedef struct { > int value; > char* name; > char* desc; >} config_select_list_t; >typedef struct { > // TODO!!!! > int dummy; >} config_group_info_t; >/* flags for options */ >// 'min' value is given in config_t >#define CONF_MIN (1<<0) >// 'max' value is given in config_t >#define CONF_MAX (1<<1) >// both 'min' and 'max' value is given in config_t >#define CONF_RANGE (CONF_MIN|CONF_MAX) >// This option cannot be in config file >#define CONF_NOCFG (1<<2) >// This option cannot be in command line >#define CONF_NOCMD (1<<3) >// This option cannot (shouldn't) be visible in gui: >#define CONF_NOGUI (1<<4) >// This option can be used without explicit naming: >#define CONF_UNNAMED (1<<5) CONF_NOSAVE were here for purpose of config save - no other hints we could have for config parser to don't write it in config if we'll request for saving it. Why you removed it? >typedef struct { > char *name; > void *p; /* pointer to variable where store result to, type specific */ > config_type_t type; > unsigned int flags; > float min, max; /* valid range */ > void *priv; /* additional pointer, type specific */ > char *desc; /* short description for help and gui */ >} config_t; >/* note: version has to be first in ModuleInfo struct in loadable module > to allow us always do validation/version check of module */ >typedef struct { > unsigned short type, version; // for loadable plugins I've proposed to have version as unsigned char[] so if we have it as unsigned short then we will fill it by some macro, will we? > char *name; > char *desc; // short description for commandline help and gui > char *maintainer; > char *author; > char *comment; > config_t *config; > void *config_defaults; > int *config_size; I was mistaken here - not int * but size_t (without '*'). (note: not int since size_t is standard type and is _always_ the same size as any pointer - int may have other size than void * on some systems). >// void *handle; >} module_info_t; >#endif /* __CFG_H */ >Any questions/suggestions? >(I've tried to apply the ideas/comments from that thread) >Problem: >we should store some reference inside the module_info_t struct to the >actual module entry point (maybe the addess of the open() func? or the >functions_t struct? do we need to store dlopen() handle there?) I've proposed to have open() here. It may be useful to have even control() pointer here also. :) With best wishes. Andriy. From arpi at thot.banki.hu Mon May 19 12:13:46 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 19 May 2003 12:13:46 +0200 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519100101.GD70445@lucky.net> Message-ID: <200305191013.h4JADkqW003126@mail.mplayerhq.hu> Hi, > >// position (slider) off_t* min max - > > CONF_TYPE_POSITION, > >// string (input box) char** min max - (min/max length) > > CONF_TYPE_STRING, > >// select list (combobox) int* - - config_select_list_t* > > CONF_TYPE_SELECT, > > Are you sure if limitation select list to int type only is enough? Not. Fisrt i also wanted a void* version, but then i dropped, as i couldn't find any examples of use. > >// group separator - - - config_group_info_t* > >// (this is NOT a real option, but an option group definition, for gui use) > > CONF_TYPE_GROUP, > > It was CONF_TYPE_DUMMY in mine, isn't it? But then we have to add into yes but dummy is a dummy name for it :) > config_group_info_t* optional subconfig (config_t*). why??? forget subconfig > >//*** this is not a valid type, but the number of types: > > CONF_TYPE_MAX > >} config_type_t; > > Also I'm against of deleting CONF_TYPE_LIST here - it may be very useful > in many of cases - I've written examples before. It you will stay only > with CONF_TYPE_STRING_LIST then [G]UI has no ways to get hints which > choises we have there. If you want to force [G]UI to have __only__ input > field for string "any,some,next" then I don't think it's useful because > we just deny [G]UI to have selection list box other than filters. If you > want extra examples I could find more. And you were agree with me we have > to have extended list type. :) i don't really understand your problem with gui here. guis should implement filter setup dialogs, with filter-dependent configs. commandline filter list parsing will be handled by layer 3, as i described in the past. actually it's a string list in the first parsing pass, then it tries to load each filter in the list and do 2nd pass parsing with its param list. > CONF_NOSAVE were here for purpose of config save - no other hints we > could have for config parser to don't write it in config if we'll request > for saving it. Why you removed it? ah, it was for config files? sorry, i'll readd then. i thought it's remained from g1's config, where it means no save its value (in playtree/configtree param saving/restoring mess). > >/* note: version has to be first in ModuleInfo struct in loadable module > > to allow us always do validation/version check of module */ > >typedef struct { > > unsigned short type, version; // for loadable plugins > > I've proposed to have version as unsigned char[] so if we have it as > unsigned short then we will fill it by some macro, will we? yes, and it's easier in module implementations than messing with chars it doens't really matter, i just don't like char as version type. > > char *name; > > char *desc; // short description for commandline help and gui > > char *maintainer; > > char *author; > > char *comment; > > config_t *config; > > void *config_defaults; > > int *config_size; > > I was mistaken here - not int * but size_t (without '*'). yes, i forgot to fix it > (note: not int since size_t is standard type and is _always_ the same > size as any pointer - int may have other size than void * on some > systems). i don't want the mess with size_t definition, it requires varios platform-dependent #includes to get it. since size_t is thye only non-C type in cfg.h, it's better to leave it and use int. i guess we won't have structs bigger than 2 GB :) you can still cast to size_t if needed > >Problem: > >we should store some reference inside the module_info_t struct to the > >actual module entry point (maybe the addess of the open() func? or the > >functions_t struct? do we need to store dlopen() handle there?) > > I've proposed to have open() here. It may be useful to have even > control() pointer here also. :) i've decided (after trying some variants), it will be void* entry, which may be casted to open() or xx_function_t, depending on module API. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 19 12:24:35 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 13:24:35 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> References: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> Message-ID: <20030519102435.GE70445@lucky.net> Hi, Arpi! Another note on the subject. :) Sometime (on Monday, May 19 at 12:16) I've received something... >#ifndef __CFG_H >#define __CFG_H 1 >/* type (menu field) ->p ->min ->max ->priv */ >typedef enum { >// flag (checkbox) int* reset set - > CONF_TYPE_FLAG=1, Why it's 1 there? Did we reserved 0 for something? If we'll implement some parser's array as struct and config_type_t is pointer there (str[i]) then str[0] will be just lost. So I've put 0 there by purpose. :) With best wishes. Andriy. From arpi at thot.banki.hu Mon May 19 12:27:58 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 19 May 2003 12:27:58 +0200 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519102435.GE70445@lucky.net> Message-ID: <200305191027.h4JARwIL011108@mail.mplayerhq.hu> Hi, > Sometime (on Monday, May 19 at 12:16) I've received something... > > >#ifndef __CFG_H > >#define __CFG_H 1 > > > >/* type (menu field) ->p ->min ->max ->priv */ > >typedef enum { > >// flag (checkbox) int* reset set - > > CONF_TYPE_FLAG=1, > > Why it's 1 there? Did we reserved 0 for something? If we'll implement to spot out badly written modules which set it (or unset) to 0 :) > some parser's array as struct and config_type_t is pointer there (str[i]) > then str[0] will be just lost. So I've put 0 there by purpose. :) and i've changed it to 1 by purpose ;) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 19 13:33:27 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 14:33:27 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <200305191013.h4JADkqW003126@mail.mplayerhq.hu> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> Message-ID: <20030519113327.GA59172@lucky.net> Hi, Arpi! Sometime (on Monday, May 19 at 13:13) I've received something... >> config_group_info_t* optional subconfig (config_t*). >why??? >forget subconfig I meant something like: config_t global_config[]={ {"~File", NULL, CONF_TYPE_GROUP, 0, 0, 0, file_config, NULL}, {"~Video", NULL, CONF_TYPE_GROUP, 0, 0, 0, video_config, NULL}, {"~Audio", NULL, CONF_TYPE_GROUP, 0, 0, 0, audio_config, NULL}, {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } then we could add optional items (to video_config[] for example) by GUI not in common config but in any. :) >> >//*** this is not a valid type, but the number of types: >> > CONF_TYPE_MAX >> >} config_type_t; >> >> Also I'm against of deleting CONF_TYPE_LIST here - it may be very useful >> in many of cases - I've written examples before. It you will stay only >> with CONF_TYPE_STRING_LIST then [G]UI has no ways to get hints which >> choises we have there. If you want to force [G]UI to have __only__ input >> field for string "any,some,next" then I don't think it's useful because >> we just deny [G]UI to have selection list box other than filters. If you >> want extra examples I could find more. And you were agree with me we have >> to have extended list type. :) >i don't really understand your problem with gui here. >guis should implement filter setup dialogs, with filter-dependent configs. From one of my previous letters: ------- For example, we have an option '-fstype'. It's string list. It may have only few choises - "none","layer","above", "below","fullscreen", and "stays_on_top". ------- For this sample, without CONF_TYPE_LIST we can only type some string ("below,fullscreen" for example) in some input field. No hints or known choises are available for GUI, unfortunately. '-fstype' isn't a module list, is it? If you need other samples, I could find these. Remember that string list isn't only for modules nor random string. Do you propose to handle all these items by GUI manually? Then GUI maker has to know _all_ these items and _all_ choises for they forever. It's a much worse than add a config type. :) >commandline filter list parsing will be handled by layer 3, as i described >in the past. actually it's a string list in the first parsing pass, then >it tries to load each filter in the list and do 2nd pass parsing with its >param list. For filters that is ok since we already know all filter types and can handle it manually by second pass. But if list isn't a filter list then we have no second pass for it (not-module items have no ->config fields) and list will remain just string with. BTW, in GUI modules will be processed by other way (not config at all) since GUI will not get it as string list but as GUI events (add, move, remove, etc.). :) >> CONF_NOSAVE were here for purpose of config save - no other hints we >> could have for config parser to don't write it in config if we'll request >> for saving it. Why you removed it? >ah, it was for config files? sorry, i'll readd then. >i thought it's remained from g1's config, where it means no save its value >(in playtree/configtree param saving/restoring mess). :) BTW, I don't think if GUI is only sample of UI so why don't rename CONF_NOGUI to CONF_NOUI ? >> (note: not int since size_t is standard type and is _always_ the same >> size as any pointer - int may have other size than void * on some >> systems). >i don't want the mess with size_t definition, it requires varios >platform-dependent #includes to get it. >since size_t is thye only non-C type in cfg.h, it's better to leave it and >use int. i guess we won't have structs bigger than 2 GB :) Then at least unsigned int - it's size is at least 16 bit so max config_size will be 65535 bytes. But anyway compiler will put some type conversion code then. ;) With best wishes. Andriy. From andrej at lucky.net Mon May 19 13:37:37 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 14:37:37 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519113327.GA59172@lucky.net> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> <20030519113327.GA59172@lucky.net> Message-ID: <20030519113737.GG70445@lucky.net> Hi, Andriy N. Gritsenko! Sometime (on Monday, May 19 at 14:33) I've received something... I've missed a word, sorry. > For filters that is ok since we already know all filter types and can >handle it manually by second pass. But if list isn't a filter list then >we have no second pass for it (not-module items have no ->config fields) >and list will remain just string with. ^commas Andriy. From dalias at aerifal.cx Mon May 19 14:17:36 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 19 May 2003 08:17:36 -0400 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519113327.GA59172@lucky.net> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> <20030519113327.GA59172@lucky.net> Message-ID: <20030519121736.GL23552@brightrain.aerifal.cx> On Mon, May 19, 2003 at 02:33:27PM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Monday, May 19 at 13:13) I've received something... > >> config_group_info_t* optional subconfig (config_t*). > > >why??? > >forget subconfig > > I meant something like: > > config_t global_config[]={ > {"~File", NULL, CONF_TYPE_GROUP, 0, 0, 0, file_config, NULL}, > {"~Video", NULL, CONF_TYPE_GROUP, 0, 0, 0, video_config, NULL}, > {"~Audio", NULL, CONF_TYPE_GROUP, 0, 0, 0, audio_config, NULL}, > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > then we could add optional items (to video_config[] for example) by GUI > not in common config but in any. :) Huh? I don't see why this is useful. Could you explain better? > BTW, I don't think if GUI is only sample of UI so why don't rename > CONF_NOGUI to CONF_NOUI ? I think I would tend to call any UI that presents users a list of config options (rather than just accepting commands) a "GUI", whether it's gtk-based, some fancy framebuffer stuff, osd, (n)curses, etc. > >> (note: not int since size_t is standard type and is _always_ the same > >> size as any pointer - int may have other size than void * on some > >> systems). > > >i don't want the mess with size_t definition, it requires varios > >platform-dependent #includes to get it. > >since size_t is thye only non-C type in cfg.h, it's better to leave it and > >use int. i guess we won't have structs bigger than 2 GB :) > > Then at least unsigned int - it's size is at least 16 bit so max > config_size will be 65535 bytes. But anyway compiler will put some type > conversion code then. ;) LOL, no, min size for int is 32 bits. If you think mplayer (or any modern code) will have any hope of running on a 16bit system, you are badly mistaken and need to go drink a whole crate of cola!! :)) Rich From andrej at lucky.net Mon May 19 14:36:34 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 15:36:34 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519121736.GL23552@brightrain.aerifal.cx> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> <20030519113327.GA59172@lucky.net> <20030519121736.GL23552@brightrain.aerifal.cx> Message-ID: <20030519123634.GJ70445@lucky.net> Hi, D Richard Felker III! Sometime (on Monday, May 19 at 15:09) I've received something... >On Mon, May 19, 2003 at 02:33:27PM +0300, Andriy N. Gritsenko wrote: >> Hi, Arpi! >> >> Sometime (on Monday, May 19 at 13:13) I've received something... >> >> config_group_info_t* optional subconfig (config_t*). >> >> >why??? >> >forget subconfig >> >> I meant something like: >> >> config_t global_config[]={ >> {"~File", NULL, CONF_TYPE_GROUP, 0, 0, 0, file_config, NULL}, >> {"~Video", NULL, CONF_TYPE_GROUP, 0, 0, 0, video_config, NULL}, >> {"~Audio", NULL, CONF_TYPE_GROUP, 0, 0, 0, audio_config, NULL}, >> {NULL, NULL, 0, 0, 0, 0, NULL, NULL} >> } >> >> then we could add optional items (to video_config[] for example) by GUI >> not in common config but in any. :) >Huh? I don't see why this is useful. Could you explain better? I'll try to explain. How menu system for GUI-based application may be created? By another structure that will copy config but with some tree? You may be very surprised but level 0 config already has all for GUI menu in it. Only thing it has not yet was formatting field (from main menu panel to drop-down menu, from drop-down menu to submenu, for separators between parts of drop-down menu, etc.). So that CONF_TYPE_GROUP at first was proposed as such formatting field (application-level type config item). Finally on "Alt" keypress or mouse event we can just run some function of GUI like display_menu(window,config) - it's enough and you don't have to make some deep changes to reformat menu - just reorder items of config in source or even in runtime. :) Did you understand now? With best wishes. Andriy. From dalias at aerifal.cx Mon May 19 15:25:53 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 19 May 2003 09:25:53 -0400 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519123634.GJ70445@lucky.net> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> <20030519113327.GA59172@lucky.net> <20030519121736.GL23552@brightrain.aerifal.cx> <20030519123634.GJ70445@lucky.net> Message-ID: <20030519132553.GM23552@brightrain.aerifal.cx> On Mon, May 19, 2003 at 03:36:34PM +0300, Andriy N. Gritsenko wrote: > Hi, D Richard Felker III! > > Sometime (on Monday, May 19 at 15:09) I've received something... > >On Mon, May 19, 2003 at 02:33:27PM +0300, Andriy N. Gritsenko wrote: > >> Hi, Arpi! > >> > >> Sometime (on Monday, May 19 at 13:13) I've received something... > >> >> config_group_info_t* optional subconfig (config_t*). > >> > >> >why??? > >> >forget subconfig > >> > >> I meant something like: > >> > >> config_t global_config[]={ > >> {"~File", NULL, CONF_TYPE_GROUP, 0, 0, 0, file_config, NULL}, > >> {"~Video", NULL, CONF_TYPE_GROUP, 0, 0, 0, video_config, NULL}, > >> {"~Audio", NULL, CONF_TYPE_GROUP, 0, 0, 0, audio_config, NULL}, > >> {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > >> } > >> > >> then we could add optional items (to video_config[] for example) by GUI > >> not in common config but in any. :) > > >Huh? I don't see why this is useful. Could you explain better? > > I'll try to explain. How menu system for GUI-based application may be > created? By another structure that will copy config but with some tree? > You may be very surprised but level 0 config already has all for GUI menu > in it. Only thing it has not yet was formatting field (from main menu > panel to drop-down menu, from drop-down menu to submenu, for separators > between parts of drop-down menu, etc.). So that CONF_TYPE_GROUP at first > was proposed as such formatting field (application-level type config > item). Finally on "Alt" keypress or mouse event we can just run some > function of GUI like display_menu(window,config) - it's enough and you > don't have to make some deep changes to reformat menu - just reorder > items of config in source or even in runtime. :) > Did you understand now? Hmm, so the point is to make it easy to nest groups (as subconfigs) and add and remove items from them? Rich From andrej at lucky.net Mon May 19 15:21:11 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 16:21:11 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519132553.GM23552@brightrain.aerifal.cx> References: <20030519100101.GD70445@lucky.net> <200305191013.h4JADkqW003126@mail.mplayerhq.hu> <20030519113327.GA59172@lucky.net> <20030519121736.GL23552@brightrain.aerifal.cx> <20030519123634.GJ70445@lucky.net> <20030519132553.GM23552@brightrain.aerifal.cx> Message-ID: <20030519132111.GL70445@lucky.net> Hi, D Richard Felker III! Sometime (on Monday, May 19 at 16:18) I've received something... >> >> then we could add optional items (to video_config[] for example) by GUI >> >> not in common config but in any. :) >> >Huh? I don't see why this is useful. Could you explain better? >> I'll try to explain. How menu system for GUI-based application may be >> created? By another structure that will copy config but with some tree? >> You may be very surprised but level 0 config already has all for GUI menu >> in it. Only thing it has not yet was formatting field (from main menu >> panel to drop-down menu, from drop-down menu to submenu, for separators >> between parts of drop-down menu, etc.). So that CONF_TYPE_GROUP at first >> was proposed as such formatting field (application-level type config >> item). Finally on "Alt" keypress or mouse event we can just run some >> function of GUI like display_menu(window,config) - it's enough and you >> don't have to make some deep changes to reformat menu - just reorder >> items of config in source or even in runtime. :) >> Did you understand now? >Hmm, so the point is to make it easy to nest groups (as subconfigs) >and add and remove items from them? Yes. For nested groups and separators. :) Andriy. From arpi at thot.banki.hu Mon May 19 15:28:35 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 19 May 2003 15:28:35 +0200 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519132111.GL70445@lucky.net> Message-ID: <200305191328.h4JDSZbS018560@mail.mplayerhq.hu> Hi, > >> I'll try to explain. How menu system for GUI-based application may be > >> created? By another structure that will copy config but with some tree? > >> You may be very surprised but level 0 config already has all for GUI menu > >> in it. Only thing it has not yet was formatting field (from main menu > >> panel to drop-down menu, from drop-down menu to submenu, for separators > >> between parts of drop-down menu, etc.). So that CONF_TYPE_GROUP at first > >> was proposed as such formatting field (application-level type config > >> item). Finally on "Alt" keypress or mouse event we can just run some > >> function of GUI like display_menu(window,config) - it's enough and you > >> don't have to make some deep changes to reformat menu - just reorder > >> items of config in source or even in runtime. :) > >> Did you understand now? > > >Hmm, so the point is to make it easy to nest groups (as subconfigs) > >and add and remove items from them? > > Yes. For nested groups and separators. :) Hmm. Do we really need nested groups?? It adds extra complexity (recursive parsing instead of for()) to config layers, with very small advantage. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 19 15:45:23 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 16:45:23 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <200305191328.h4JDSZbS018560@mail.mplayerhq.hu> References: <20030519132111.GL70445@lucky.net> <200305191328.h4JDSZbS018560@mail.mplayerhq.hu> Message-ID: <20030519134523.GM70445@lucky.net> Hi, Arpi! Sometime (on Monday, May 19 at 16:28) I've received something... >> >Hmm, so the point is to make it easy to nest groups (as subconfigs) >> >and add and remove items from them? >> Yes. For nested groups and separators. :) >Hmm. Do we really need nested groups?? >It adds extra complexity (recursive parsing instead of for()) to config >layers, with very small advantage. But we have recursive parsing already for CONF_TYPE_SUBCONFIG. Beside of that, this extra complexity is only one or two lines inside of parser (depending on implementation), for example (before strcmp, of course): if (opt->type==CONF_TYPE_GROUP && (err=read_config(....))==ERR_NOT_AN_OPTION) continue; and I don't think if that advantage is too small. It'll allow you don't create own type of option if you use a GUI and don't add lines above in the GUI's config parser in that case but use default. :) With best wishes. Andriy. From andrej at lucky.net Mon May 19 15:56:52 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 19 May 2003 16:56:52 +0300 Subject: [MPlayer-G2-dev] Re: cfg.h (config layer 0 discussion) In-Reply-To: <20030519134523.GM70445@lucky.net> References: <20030519132111.GL70445@lucky.net> <200305191328.h4JDSZbS018560@mail.mplayerhq.hu> <20030519134523.GM70445@lucky.net> Message-ID: <20030519135652.GN70445@lucky.net> Hi, Andriy N. Gritsenko! Sometime (on Monday, May 19 at 16:45) I've received something... >>> >Hmm, so the point is to make it easy to nest groups (as subconfigs) >>> >and add and remove items from them? >>> Yes. For nested groups and separators. :) >>Hmm. Do we really need nested groups?? >>It adds extra complexity (recursive parsing instead of for()) to config >>layers, with very small advantage. > But we have recursive parsing already for CONF_TYPE_SUBCONFIG. Beside >of that, this extra complexity is only one or two lines inside of parser >(depending on implementation), for example (before strcmp, of course): >if (opt->type==CONF_TYPE_GROUP && (err=read_config(....))==ERR_NOT_AN_OPTION) > continue; Hmm. It seems I'm wrong and it need more lines (because err may be error or exit code) but anyway IMHO 5-6 lines isn't a big cost. if(opt->type==CONF_TYPE_GROUP) { if((err=read_config())==ERR_NOT_AN_OPTION) continue; if(err>=0) goto exit_ok; goto exit_error; } >and I don't think if that advantage is too small. It'll allow you don't >create own type of option if you use a GUI and don't add lines above in >the GUI's config parser in that case but use default. :) With best wishes. Andriy. From FabianFranz at gmx.de Fri May 23 04:35:32 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 04:35:32 +0200 Subject: [MPlayer-G2-dev] [PATCH] vcd support ported from main (and as such removing globals) Message-ID: <200305230435.32236.FabianFranz@gmx.de> Hi, attached patch is based on vcd from main and has infrastructure from g2. There are some comments with //FF: - Those are just for things I wasn't sure with and should be removed before applying. Hope it did that job (with removing the global vars). cu Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-vcd-port.diff Type: text/x-diff Size: 21095 bytes Desc: not available URL: From FabianFranz at gmx.de Fri May 23 07:13:08 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 07:13:08 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support Message-ID: <200305230713.08419.FabianFranz@gmx.de> hi, attached is simply the reworked file, ported from main-tree. I also removed all globals so it is a more clean approach than before. It could also be backported to main as the g2-specific stuff is easy to see :-) Btw. I love this new stream-architecture. It is sooo nice to use :-)) cu Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: stream_cue.c Type: text/x-csrc Size: 15378 bytes Desc: not available URL: From arpi at thot.banki.hu Fri May 23 07:52:43 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 23 May 2003 07:52:43 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305230713.08419.FabianFranz@gmx.de> Message-ID: <200305230552.h4N5qhQG023786@mail.mplayerhq.hu> Hi, > hi, > > attached is simply the reworked file, ported from main-tree. > > I also removed all globals so it is a more clean approach than before. > > It could also be backported to main as the g2-specific stuff is easy to see > :-) > > Btw. I love this new stream-architecture. It is sooo nice to use :-)) and it could be ever more nice :) static int driver_fill(stream_t *s){ return cue_vcd_read((cue_priv_t*)s->priv,s->buffer); } i see no sence of such wrappers, the actual code could go into the actual function. also, if you rename cue_priv_t to struct stream_priv_s, you will get casting for free, ie you can access priv vars via stream->priv->something, without extra typecasting! also the buffer is still a static global, should be moved into the priv. (think of parallel (threaded) use of g2 libs (hmm ok it has no much sense, unless someone have 2 cdrom drivers and play 2 discs simultianiously:))) and there should be no globals (exported functions) except the info struct. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Fri May 23 16:40:00 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 16:40:00 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305230552.h4N5qhQG023786@mail.mplayerhq.hu> References: <200305230552.h4N5qhQG023786@mail.mplayerhq.hu> Message-ID: <200305231640.00616.FabianFranz@gmx.de> Am Freitag, 23. Mai 2003 07:52 schrieb Arpi: > Hi, > > > hi, > > > > attached is simply the reworked file, ported from main-tree. > > > > I also removed all globals so it is a more clean approach than before. > > > > It could also be backported to main as the g2-specific stuff is easy to > > see > > > > :-) > > > > Btw. I love this new stream-architecture. It is sooo nice to use :-)) > > and it could be ever more nice :) > > static int driver_fill(stream_t *s){ > return cue_vcd_read((cue_priv_t*)s->priv,s->buffer); > } > > i see no sence of such wrappers, the actual code could go into the actual > function. I did that to be backward-compatible. (and you did it in your old stream_vcd too. Heh, I'm taking exisitng code as my base :) ) > also, if you rename cue_priv_t to struct stream_priv_s, you will > get casting for free, ie you can access priv vars via > stream->priv->something, without extra typecasting! Sorry, I don't understand. Example ? > > also the buffer is still a static global, should be moved into the priv. where ? It uses the buffer provided by the stream_t like stream_vcd did and does. > (think of parallel (threaded) use of g2 libs (hmm ok it has no much sense, > unless someone have 2 cdrom drivers and play 2 discs simultianiously:))) I did design it with exact that scenario in head. Could you be more specific ? > > and there should be no globals (exported functions) except the info struct. yep, sure. That is a mistake. I'll send new PATCH/file asap. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Fri May 23 16:49:51 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 23 May 2003 16:49:51 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305231640.00616.FabianFranz@gmx.de> Message-ID: <200305231449.h4NEnpOx009219@mail.mplayerhq.hu> Hi, > > > It could also be backported to main as the g2-specific stuff is easy to > > > see > > > > > > :-) > > > > > > Btw. I love this new stream-architecture. It is sooo nice to use :-)) > > > > and it could be ever more nice :) > > > > static int driver_fill(stream_t *s){ > > return cue_vcd_read((cue_priv_t*)s->priv,s->buffer); > > } > > > > i see no sence of such wrappers, the actual code could go into the actual > > function. > > I did that to be backward-compatible. (and you did it in your old stream_vcd > too. Heh, I'm taking exisitng code as my base :) ) my stream_vcd.c was a quick hack, with strong 'TODO: cleanup!!!' in head and TODO. see stream_SAMPLE.c for sample :) > > also, if you rename cue_priv_t to struct stream_priv_s, you will > > get casting for free, ie you can access priv vars via > > stream->priv->something, without extra typecasting! > > Sorry, I don't understand. Example ? define priv struct the beginning of teh .c file: struct stream_priv_s { struct cdrom_tocentry vcd_entry; int xyz; ... }; then you can access you rpriv vars without typecasting, so, instead of: static int driver_fill(stream_t *s){ struct stream_priv_s* priv=(struct stream_priv_s*)s->priv; something(priv->xyz); return len; } you can do simply: static int driver_fill(stream_t *s){ something(s->priv->xyz); return len; } > > > > > also the buffer is still a static global, should be moved into the priv. > > where ? It uses the buffer provided by the stream_t like stream_vcd did and > does. static char vcd_buf[VCD_SECTOR_SIZE]; dunno if it's used but it is there in your patch :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Fri May 23 16:57:07 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 16:57:07 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305231449.h4NEnpOx009219@mail.mplayerhq.hu> References: <200305231449.h4NEnpOx009219@mail.mplayerhq.hu> Message-ID: <200305231657.07717.FabianFranz@gmx.de> Am Freitag, 23. Mai 2003 16:49 schrieb Arpi: > Hi, > > > > > It could also be backported to main as the g2-specific stuff is easy > > > > to see > > > > > > > > :-) > > > > > > > > Btw. I love this new stream-architecture. It is sooo nice to use :-)) > > > > > > and it could be ever more nice :) > > > > > > static int driver_fill(stream_t *s){ > > > return cue_vcd_read((cue_priv_t*)s->priv,s->buffer); > > > } > > > > > > i see no sence of such wrappers, the actual code could go into the > > > actual function. > > > > I did that to be backward-compatible. (and you did it in your old > > stream_vcd too. Heh, I'm taking exisitng code as my base :) ) > > my stream_vcd.c was a quick hack, with strong 'TODO: cleanup!!!' in head > and TODO. ok :) > > see stream_SAMPLE.c for sample :) already did, but it was sooo basic ;) > > > > also, if you rename cue_priv_t to struct stream_priv_s, you will > > > get casting for free, ie you can access priv vars via > > > stream->priv->something, without extra typecasting! > > > > Sorry, I don't understand. Example ? > > define priv struct the beginning of teh .c file: > > struct stream_priv_s { > struct cdrom_tocentry vcd_entry; > int xyz; > ... > }; ah, got it now > > > also the buffer is still a static global, should be moved into the > > > priv. > > > > where ? It uses the buffer provided by the stream_t like stream_vcd did > > and does. > > static char vcd_buf[VCD_SECTOR_SIZE]; > > dunno if it's used but it is there in your patch :) yep, who the f* does define globals all over the place in a file ? changed :) New file attached, that should solve all "problems", you spoke of. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: stream_cue.c Type: text/x-csrc Size: 15476 bytes Desc: not available URL: From arpi at thot.banki.hu Fri May 23 17:03:37 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 23 May 2003 17:03:37 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305231657.07717.FabianFranz@gmx.de> Message-ID: <200305231503.h4NF3b3t019198@mail.mplayerhq.hu> Hi, > yep, who the f* does define globals all over the place in a file ? albeu? :))) ok it was probably me... and others copypasted it from my vcd file > changed :) thx > New file attached, that should solve all "problems", you spoke of. it would be better (and save some time for me) to send perfect patches at first time :) so i don't have to keep reviewing and commenting it until it's ok :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Fri May 23 17:11:05 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 17:11:05 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305231503.h4NF3b3t019198@mail.mplayerhq.hu> References: <200305231503.h4NF3b3t019198@mail.mplayerhq.hu> Message-ID: <200305231711.05537.FabianFranz@gmx.de> Am Freitag, 23. Mai 2003 17:03 schrieb Arpi: > Hi, > > > yep, who the f* does define globals all over the place in a file ? > > albeu? :))) > ok it was probably me... and others copypasted it from my vcd file no, I think cuebin-support was a PATCH by "don't remember", that was after some hick-hack applied into cvs. > > > changed :) > > thx > > > New file attached, that should solve all "problems", you spoke of. > > it would be better (and save some time for me) to send perfect patches at > first time :) ok, lets note on my list: - use static - use direct functions (e.g. no wrapper functions) - use stream_priv_s (to get typecasting for free) - change ALL global vars ;) (e.g. don't overlook some) ok cat list > /dev/mind > so i don't have to keep reviewing and commenting it until it's ok :) heh, that was one of my first own ports from main and codebase was ugly ... :) Hope it is ok, to review patches ? I'll now head for trying to port mms://. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From FabianFranz at gmx.de Fri May 23 17:31:25 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Fri, 23 May 2003 17:31:25 +0200 Subject: [MPlayer-G2-dev] [PATCH] basic Proxy support (via http_proxy var) Message-ID: <200305231731.25134.FabianFranz@gmx.de> hi, attached patch adds proxy support. cu Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-proxy-fix.diff Type: text/x-diff Size: 466 bytes Desc: not available URL: From arpi at thot.banki.hu Fri May 23 21:09:49 2003 From: arpi at thot.banki.hu (Arpi) Date: Fri, 23 May 2003 21:09:49 +0200 Subject: [MPlayer-G2-dev] [PATCH] bin/cue-support In-Reply-To: <200305231711.05537.FabianFranz@gmx.de> Message-ID: <200305231909.h4NJ9nRZ026708@mail.mplayerhq.hu> Hi, > > cat list > /dev/mind lol :) > > I'll now head for trying to port mms://. good luck, it won't be easy :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Sat May 24 11:13:04 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 24 May 2003 12:13:04 +0300 Subject: [MPlayer-G2-dev] About final cfg.h (config layer 0 discussion) In-Reply-To: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> References: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> Message-ID: <20030524091304.GA29804@lucky.net> Hi, Arpi! It seems, cfg.h discussion almost ended but it seems something isn't decided yet. So I want to ask some questions now: 1. Why did you dropped CONF_TYPE_SUBCONFIG ? I've just noticed that. It's because all such options are modules parameters and you want to parse they by different way? 2. Do you still have something to argue about CONF_TYPE_LIST option type? 3. Will we change CONF_NOGUI to CONF_NOUI ? 4. Let's change unsigned short type, version to unsigned short version, type in module_info_t definition to have compatibility forever. :) Discussion about CONF_TYPE_GROUP isn't my concern right now since that option is application level only and it's marked as TODO anyway. :) Also about how to apply new config level 0 to video filters (and to all other in the future, of course). We have to describe how parameters will be passed to modules. So: 1. vf_open_filter(), vf_open_encoder(), and vf_insert_filter() functions have to get not char *args but void *args and that void * have to be preallocated array with parsed parameters (see module info); 2. we have to introduce VFCTRL_GET_PARAMS and VFCTRL_SET_PARAMS requests for vf->control(). These requests will have void *data as parameters array, preallocated by caller: for VFCTRL_GET_PARAMS it's array with undefined values and filter has to set all changeable parameters there; VFCTRL_SET_PARAMS will ask the filter to apply changed parameters to the instance. Size of that array defined by config_size in module info. It must be documented before we have all filters/encoders ported from G1 since it'll be huge headache after that. ;) For example, I want to port vf_dint.c to G2 but I still cannot until we decide all above and I wait for it... BTW, we have in VF API functions for inserting filter into begin of chain and to somewhere inside chain but how about adding filter at the end of chain? May be better is something like: vf_instance_t* vf_insert_filter(vf_instance_t *last, vf_instance_t *next, char *name, void *args); which will insert filter between instances last and next, and so if last==NULL then we'll insert filter at begin of chain (as vf_open_filter does) and if next==NULL then we'll add filter at end of chain. I think it's the best way to do it. BTW, with new layer 0 concept it may be more correct if we will use module_info_t* instead of char *name. With the best wishes. Andriy. From andrej at lucky.net Sat May 24 12:45:55 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 24 May 2003 13:45:55 +0300 Subject: [MPlayer-G2-dev] Re: 0.90.1 ??? In-Reply-To: <200305212207.h4LM7pgv024086@mail.mplayerhq.hu> References: <20030521204225.GC577@tower2.myhome.qwe> <200305212207.h4LM7pgv024086@mail.mplayerhq.hu> Message-ID: <20030524104555.GF84616@lucky.net> Hi, Arpi! Sometime (on Thursday, May 22 at 1:07) I've received something... >> at the moment, so i think that mantaining three versions (0_90, CVS and >> soon G2) is an overkill. >agree >we have no resources to maintain 0_90 any more. >we don't even have enough resources to maintain main and g2... >the problem is that there isn't a lot of people actively working on g2 >neither :( >the only g2 patches i got are only for bsd, darwin and cygwin compatibility. >(so except some design ideas on maillist and irc, i'm alone on g2 development) I could help with porting some of g1 stuff to g2, I'm just waiting for config layer 0 final API. I think that some developers are waiting for that too. :) >while i know (and said) that libvo2 API is stable now, also teh stream layer >of g2, so ppl. could start porting/rewriting stream/vo2 modules for g2. >and, when the major drivers are ported, we could replace g1's libvo and >stream layer too, by the g2 one. With the new config concept we have to replace vo_info_t with module_info_t and related stuff before mass-porting. >(stream layer is compatible (stream.h is the same) and there is vf_vo2 for >vf-vo2 interface so it's also easy to use libvo2 with g1) >although i hope that g2 will be usable in a month, actually it's already >usable but lacks of config layer 1-3 (1-2: not implemented yet, 3 not designed >yet), you can even play mpeg, avi, asf and ogg files with perfect (much >better than g1) a-v sync using g2's sample app, test-play.c. Let's finish with level 0 then we can implement these layers 1-2 (modules layer and config/commandline parser respectively) so I don't think if it's a problem. Anyway dynamic loading part of modules layer isn't too actual yet so it can wait, I think. :) Beside of this, levels 2 and 3 are application levels so anyone free to implement it for own application. :) Andriy. From andrej at lucky.net Sat May 24 13:57:59 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 24 May 2003 14:57:59 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030524091304.GA29804@lucky.net> References: <200305190917.h4J9HHK8003153@mail.mplayerhq.hu> <20030524091304.GA29804@lucky.net> Message-ID: <20030524115759.GA69584@lucky.net> Hi! I've missed something also, I found it when I tried to apply level 0 to my dint.c - we have to define some macro for unsigned short version, also we have to define MODULE_TYPE_*. However, it may be checked only for loadable modules and may be omitted in level 0 but set to 0 for built-in modules. Am I right? BTW, Arpi, let us know all module types and which of these may have parameters and which not (if there are). :) With best wishes. Andriy. From FabianFranz at gmx.de Sat May 24 14:23:34 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sat, 24 May 2003 14:23:34 +0200 Subject: [MPlayer-G2-dev] [SUGGESTIIONS] g2/stream/README, g2/stream/stream_smb.c Message-ID: <200305241423.34173.FabianFranz@gmx.de> Hi, update g2/stream/README to reflect that smb is suppported. (and cue after applying my patch ;) ) Change //err = smbc_init(smb_auth_fn, 10); // Initialize libsmbclient err = smbc_init(smb_auth_fn, 0); // Initialize libsmbclient As 10 is really tooo verbose. Is it possible for the module to query the verbose(level)-var ? Or can it just be used as it was in g1 ? cu Fabian From arpi at thot.banki.hu Sat May 24 14:30:13 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 24 May 2003 14:30:13 +0200 Subject: [MPlayer-G2-dev] About final cfg.h (config layer 0 discussion) In-Reply-To: <20030524091304.GA29804@lucky.net> Message-ID: <200305241230.h4OCUDje025827@mail.mplayerhq.hu> Hi, > 1. Why did you dropped CONF_TYPE_SUBCONFIG ? I've just noticed that. It's > because all such options are modules parameters and you want to parse > they by different way? > 2. Do you still have something to argue about CONF_TYPE_LIST option type? > 3. Will we change CONF_NOGUI to CONF_NOUI ? > 4. Let's change unsigned short type, version to unsigned short version, > type in module_info_t definition to have compatibility forever. :) .. i'm almost ready with the implementation, will be released soon (today?) so be patient, you'll get all these answered. > chain and to somewhere inside chain but how about adding filter at the > end of chain? May be better is something like: insert at teh end? why? it's the leaf filter always A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Sat May 24 15:32:50 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 24 May 2003 16:32:50 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <200305241230.h4OCUDje025827@mail.mplayerhq.hu> References: <20030524091304.GA29804@lucky.net> <200305241230.h4OCUDje025827@mail.mplayerhq.hu> Message-ID: <20030524133250.GA87369@lucky.net> Hi, Arpi! Sometime (on Saturday, May 24 at 15:28) I've received something... >> 1. Why did you dropped CONF_TYPE_SUBCONFIG ? I've just noticed that. It's >> because all such options are modules parameters and you want to parse >> they by different way? >> 2. Do you still have something to argue about CONF_TYPE_LIST option type? >> 3. Will we change CONF_NOGUI to CONF_NOUI ? >> 4. Let's change unsigned short type, version to unsigned short version, >> type in module_info_t definition to have compatibility forever. :) >.. >i'm almost ready with the implementation, will be released soon (today?) >so be patient, you'll get all these answered. So you took all my notices already? Great. :) >> chain and to somewhere inside chain but how about adding filter at the >> end of chain? May be better is something like: >insert at teh end? why? it's the leaf filter always If you want add filter at end of list from [G]UI or it may be also useful for '-vf' implementation (don't go to end of list and add filters in reverse order but just add to end of chain one by one). In both of these cases it will be better than use some tricks. Anyway all difference is in filling fields ->prev and ->next of vf_instance_t by function vf_insert_filter(). :) With best wishes. Andriy. From arpi at thot.banki.hu Sat May 24 15:57:34 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 24 May 2003 15:57:34 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030524133250.GA87369@lucky.net> Message-ID: <200305241357.h4ODvYLa011475@mail.mplayerhq.hu> Hi, > > >insert at teh end? why? it's the leaf filter always > > If you want add filter at end of list from [G]UI or it may be also you cannot add filter at the end - the last filter is a special 'leaf filtyer' which handles image output. it cannot be replaced. 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 May 24 20:42:02 2003 From: arpi at thot.banki.hu (Arpi) Date: Sat, 24 May 2003 20:42:02 +0200 Subject: [MPlayer-G2-dev] pre29: introducing config layer Message-ID: <200305241842.h4OIg24V020329@mail.mplayerhq.hu> Hi, pre29 is out... with the long-awaited config layer (layers 0+1 for now). Notes: - not all code/case finished (search for TODO and FIXME) - only a small part of code/modules updated to use new config layer yet - there are more than one structs/typedefs in cfg.h. with reason... - ... ok it's enough for now check it, and feel free to ask. i know you'll have many questions... i'll try to write some docs on config layer 0/1, to make things clear. and i'll start updateing the code to use config layer, ie. define the core modules and configs, and update plugin modules, migrate vo_info_t etc to module_info_t and so on. it will be a long and very boring work... :( A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lumag at qnc.ru Sat May 24 23:22:54 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 25 May 2003 01:22:54 +0400 Subject: [MPlayer-G2-dev] G2, DVDnav, etc. Message-ID: <1053811234.27771.210.camel@orangutan.home.ru> Hello! Here are some of my thoughts about adding support for DVDnav into G2. (As most ideas here, probably they will be changed mostly, etc.) 1. Unlike G1, stream+cache layer behaves like DVD (using stream_dvd), and not like MPEG stream after libdvdnav. 2. Next part is a code, which emulates DVDnav VM, seeks to correct places of DVD, etc. Of course it belongs somwhere between stream_dvd and demux_mpeg. So here is first question: what is better: to break into demux_mpeg, and add a lot of if(dvdnav){...}, or to create an especial demuxer for DVDnav? Or maybe there are other solutions? Anyway demuxer must be able to control, which of audio/subtitle streams are decoded. Probably, his would require significant changes in libao2. 3. Still frames support. Sorry, dunno g2 arch well enough, to even imagine, what changes are necessary here. FIXME :) 4. Interaction with user. Currently, IIUC, event hanling can be done only through libvo2. Suppose, it's not the best way. It's more or less acceptable for vo's, like xv, x11, etc. But for vo_vesa, and similars 'fake mouse' layer will be usefull. Such OSD-rendered 'mouse' (read pointer) will be controled via libinput. Moreover demuxer (at least its navigation part) also must be user-controled! Also keep in mind, some more 'controllable' demuxers (navigation in MOV's, NUT, and Matroska; maybe something else). I don't see proposed way for such control. 5. Latest part is output. What is required here? libvo2 must support image resizing/still frames. Resizing is supported (at least theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned above. Maybe I'm missing something,but IIUC, libaf chains are build independantly for each audio stream. So many parts of G2 must be changed/discussed to ease adding support for DVD (and maybe for Matroska/NUT/etc.) navigation. Good news are, that it will be (I hope) easier, than for G1. -- With best wishes Dmitry. From arpi at thot.banki.hu Sun May 25 13:58:25 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 13:58:25 +0200 Subject: [MPlayer-G2-dev] G2, DVDnav, etc. In-Reply-To: <1053811234.27771.210.camel@orangutan.home.ru> Message-ID: <200305251158.h4PBwPGY000885@mail.mplayerhq.hu> Hi, > Hello! > Here are some of my thoughts about adding support for DVDnav into G2. > (As most ideas here, probably they will be changed mostly, etc.) > > > 1. Unlike G1, stream+cache layer behaves like DVD (using stream_dvd), > and not like MPEG stream after libdvdnav. i don't understand this btw the problem with libdvdnav is that you cannot use mplayer's cache2 layer for it. i've heard about some patches which added some caching/buffering to libdvdnav, dunno if they are usable or still exists. > 2. Next part is a code, which emulates DVDnav VM, seeks to correct > places of DVD, etc. Of course it belongs somwhere between stream_dvd and > demux_mpeg. So here is first question: what is better: to break into > demux_mpeg, and add a lot of if(dvdnav){...}, or to create an especial > demuxer for DVDnav? Or maybe there are other solutions? imho it's all UI problem, not demuxer. imho dvdnav interface should go to the stream layer. some method could be added to pass events to/from UI from/to stream layer. any ideas? i'm not familiar with UI/events design at all. > Anyway demuxer must be able to control, which of audio/subtitle streams no, UI must be able to control it, and it IS able to do that. > are decoded. Probably, his would require significant changes in libao2. why? libao has nothing with that. you probably meant mpeg demuxer + audio codecs? g2 is designed to handle runtime codec/stream switch. (although multiple codec for single stream (aka mov's variable fourcc) not supported (yet)) > 3. Still frames support. Sorry, dunno g2 arch well enough, to even > imagine, what changes are necessary here. I hope that nothing. The final a-v sync code will recognize and handle still frames. The only problem i can see is the OSD rendering. Ie if we have to render something over the still images. > FIXME :) > > 4. Interaction with user. > Currently, IIUC, event hanling can be done only through libvo2. Suppose, not really libvo2 has event callback to be able to pass events from vo drivers to the UI. it's required as only the vo drivers are able to catch some input events. the real event handling core is in libinput. > it's not the best way. It's more or less acceptable for vo's, like xv, > x11, etc. But for vo_vesa, and similars 'fake mouse' layer will be > usefull. Such OSD-rendered 'mouse' (read pointer) will be controled via > libinput. Moreover demuxer (at least its navigation part) also must be > user-controled! Also keep in mind, some more 'controllable' demuxers > (navigation in MOV's, NUT, and Matroska; maybe something else). > I don't see proposed way for such control. I don't think that navigation belongs to the demuxers. > 5. Latest part is output. What is required here? libvo2 must support > image resizing/still frames. Resizing is supported (at least why? (why do dvdnav requires resizing at vo ???) > theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned > above. Maybe I'm missing something,but IIUC, libaf chains are build > independantly for each audio stream. yes > So many parts of G2 must be changed/discussed to ease adding support for i disagree > DVD (and maybe for Matroska/NUT/etc.) navigation. Good news are, that it > will be (I hope) easier, than for G1. sure 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 May 25 14:19:12 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 14:19:12 +0200 Subject: [MPlayer-G2-dev] About final cfg.h (config layer 0 discussion) In-Reply-To: <20030524091304.GA29804@lucky.net> Message-ID: <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> Hi, > 1. Why did you dropped CONF_TYPE_SUBCONFIG ? I've just noticed that. It's > because all such options are modules parameters and you want to parse > they by different way? yes there is CONF_TYPE_MODLIST now it handles -option module1[=[paramname=]param1:param2...][,module2=...]... format options (like -vf, -vo, -ao etc). the 'priv' field of the config_t entry points to a function which retrieve module_info_t* for a named module (ro NULL if it doesn't exists). the result (config_t->p) is stored in a config_modlist_t array, which contains module_info_t* and config_data_t* for each entry. see -vf in pre29. pretty clear and simple! anyway there is subconfig parser func in layer-1, used by CONF_TYPE_MODLIST parser too. so adding subconfig support is just a few lines, but until we find a good reason for it i don't add. imho we should keep g2's commandline syntax as consistent and logical as possible, it also means avoid subconfigs. as you (and others) said, subconfig in g1 was to pass module-specific stuff. since it's now handled in clean way (MODLIST, MODULE types) it has no use. > 2. Do you still have something to argue about CONF_TYPE_LIST option type? isn't my CONF_TYPE_SELECT the same? > 3. Will we change CONF_NOGUI to CONF_NOUI ? i like Rich's answer - UIs producing visual option lists are considered GUIs, even if they are actually CUI :) > 4. Let's change unsigned short type, version to unsigned short version, > type in module_info_t definition to have compatibility forever. :) no i'm thinking about add type-specific versions so if we change vf API we don't have to force demuxer, stream, vo etc plugin authors/users to recompile their plugins just to get version number bumped. > Discussion about CONF_TYPE_GROUP isn't my concern right now since > that option is application level only and it's marked as TODO anyway. :) actually i've added CONF_TYPE_MODULE which does the same as you expected from CONF_TYPE_GROUP. > Also about how to apply new config level 0 to video filters (and to > all other in the future, of course). We have to describe how parameters > will be passed to modules. So: > > 1. vf_open_filter(), vf_open_encoder(), and vf_insert_filter() functions > have to get not char *args but void *args and that void * have to be > preallocated array with parsed parameters (see module info); of course, it's already changed (see pre29) > 2. we have to introduce VFCTRL_GET_PARAMS and VFCTRL_SET_PARAMS requests yes, it's a TODO > for vf->control(). These requests will have void *data as parameters > array, preallocated by caller: for VFCTRL_GET_PARAMS it's array with > undefined values and filter has to set all changeable parameters there; > VFCTRL_SET_PARAMS will ask the filter to apply changed parameters to > the instance. Size of that array defined by config_size in module info. imho VFCTRL_GET_PARAMS is useless. config_data_t* (the struct containing the preallocated config vars) is part of the instance structs (vf_instance_t), and is used by the filter to keep the config data. (ie it's free()'d only at filter uninit). it's always readable by upper layer (so VFCTRL_GET_PARAMS is useless), but we should add VFCTRL_SET_PARAMS (or better name) to notify filter about config changes made by UI. i'm not completely sure about this one yet. (runtime config change is always a mess...) > It must be documented before we have all filters/encoders ported from > G1 since it'll be huge headache after that. ;) yes and we (i) should migrate the already ported modules first, so we can test (and find errors in) new config layer, and give some nice examples for porters. > For example, I want to port vf_dint.c to G2 but I still cannot until > we decide all above and I wait for it... > > BTW, we have in VF API functions for inserting filter into begin of > chain and to somewhere inside chain but how about adding filter at the > end of chain? May be better is something like: > > vf_instance_t* vf_insert_filter(vf_instance_t *last, vf_instance_t *next, > char *name, void *args); > > which will insert filter between instances last and next, and so if > last==NULL then we'll insert filter at begin of chain (as vf_open_filter > does) and if next==NULL then we'll add filter at end of chain. I think no but i'l mayeb rename functions to insert_above and insert_below instead of append and insert. > it's the best way to do it. BTW, with new layer 0 concept it may be more > correct if we will use module_info_t* instead of char *name. of course. see pre29... 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 May 25 15:42:59 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 15:42:59 +0200 Subject: [MPlayer-G2-dev] [SUGGESTIIONS] g2/stream/README, g2/stream/stream_smb.c In-Reply-To: <200305241423.34173.FabianFranz@gmx.de> Message-ID: <200305251342.h4PDgxYG024361@mail.mplayerhq.hu> Hi, > update g2/stream/README to reflect that smb is suppported. (and cue after > applying my patch ;) ) done :) > Change > > //err = smbc_init(smb_auth_fn, 10); // Initialize libsmbclient > err = smbc_init(smb_auth_fn, 0); // Initialize libsmbclient done i've changed it 1, hope it's ok A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lumag at qnc.ru Sun May 25 18:55:41 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 25 May 2003 20:55:41 +0400 Subject: [MPlayer-G2-dev] G2, DVDnav, etc. In-Reply-To: <200305251158.h4PBwPGY000885@mail.mplayerhq.hu> References: <200305251158.h4PBwPGY000885@mail.mplayerhq.hu> Message-ID: <1053881733.26414.155.camel@orangutan.home.ru> Hello! ?? ?? 25.05.2003, ?? 15:58, Arpi ??????????: > > 1. Unlike G1, stream+cache layer behaves like DVD (using stream_dvd), > > and not like MPEG stream after libdvdnav. > > i don't understand this > > btw the problem with libdvdnav is that you cannot use mplayer's cache2 > layer for it. i've heard about some patches which added some > caching/buffering to libdvdnav, dunno if they are usable or still exists. Yes it has caching support, but there is one small problem. We cannot use external libdvdnav: recently, they imported libdvdread into it, so mpdvdkit2 will probably clash with dvdread from libdvdnav. So, libdvdnav must be imported into G2. Then, IIUC, if we must import G2, why we must relay on their caching system, when there is good native cache? > > > 2. Next part is a code, which emulates DVDnav VM, seeks to correct > > places of DVD, etc. Of course it belongs somwhere between stream_dvd and > > demux_mpeg. So here is first question: what is better: to break into > > demux_mpeg, and add a lot of if(dvdnav){...}, or to create an especial > > demuxer for DVDnav? Or maybe there are other solutions? > > imho it's all UI problem, not demuxer. Why VM (Virtual Machine - I meant it, and not seeking, etc. caused by user). Probably you messed two event types: a) coming from user. They of course should pass from UI to dvdnav code. b) coming from nav VM. They are events, that libdvdnav returns. Maybe, if G2's DVDnav code will be placed in demuxer,most of such events won't exist (suppose, there will be only two - STILL_FRAME and STOP). > imho dvdnav interface should go to the stream layer. some method could be Why stream layer? Keep in mind MOV/NUT/etc. navigation. They of course belong to demuxer layer!So navigation-code placing must be standard. > added to pass events to/from UI from/to stream layer. > any ideas? i'm not familiar with UI/events design at all. > > > Anyway demuxer must be able to control, which of audio/subtitle streams > > no, UI must be able to control it, and it IS able to do that. > > > are decoded. Probably, his would require significant changes in libao2. > why? libao has nothing with that. you probably meant mpeg demuxer + audio > codecs? g2 is designed to handle runtime codec/stream switch. > (although multiple codec for single stream (aka mov's variable fourcc) > not supported (yet)) OK. This is probably a better idea:) My idea was to give all audio streams to decoder. Now I understand, that it was wrong idea. > > 3. Still frames support. Sorry, dunno g2 arch well enough, to even > > imagine, what changes are necessary here. > > I hope that nothing. > The final a-v sync code will recognize and handle still frames. > The only problem i can see is the OSD rendering. Ie if we have to render > something over the still images. We MUST render selections, which IIRC are SPU streams. Maybe there could be a simple vf, that passes all non-still images, and when we receive still-frame command, it stores frame in internal buffer? > > > FIXME :) > > > > 4. Interaction with user. > > Currently, IIUC, event hanling can be done only through libvo2. Suppose, > > not really > libvo2 has event callback to be able to pass events from vo drivers to > the UI. it's required as only the vo drivers are able to catch some input > events. That's what I told about > > the real event handling core is in libinput. > > it's not the best way. It's more or less acceptable for vo's, like xv, > > x11, etc. But for vo_vesa, and similars 'fake mouse' layer will be > > usefull. Such OSD-rendered 'mouse' (read pointer) will be controled via > > libinput. Moreover demuxer (at least its navigation part) also must be > > user-controled! Also keep in mind, some more 'controllable' demuxers > > (navigation in MOV's, NUT, and Matroska; maybe something else). > > I don't see proposed way for such control. > > I don't think that navigation belongs to the demuxers. Ok. So What part of player must control the behavior of demuxer, by reading navigation stream (Of couse, demuxer may simply read navigation commands from source file/stream and tranclate them to universal commands). Do you think, that it's a part of UI? then playing of same file/DVD will (or at least can) be UI-dependant. I suppose, that UI must only control parameters of playing. I really suppose, that navigation belongs to demuxer. Really: for DVDs it must be placed not later, than demuxer(or it will require more hacks), and for file-navigation (MOV/etc), it can't be placed before demuxer. So: navigation >= demuxer and navigation <= demuxer \longrightarrow navigation \in demuxer :) > > > 5. Latest part is output. What is required here? libvo2 must support > > image resizing/still frames. Resizing is supported (at least > > why? (why do dvdnav requires resizing at vo ???) not dvdnav. There are(or maybe it's a bug of ogle, but they could exist) DVDs, where nav menus could use different resolutions. > > > theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned > > above. Maybe I'm missing something,but IIUC, libaf chains are build > > independantly for each audio stream. > > yes Ok. Now we mustn't support switching of audio streams. We must support rebuilding of the whole audio chain on-fly. > > > So many parts of G2 must be changed/discussed to ease adding support for > > i disagree Suppose, you know better :) > > > DVD (and maybe for Matroska/NUT/etc.) navigation. Good news are, that it > > will be (I hope) easier, than for G1. > > sure good news > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry From FabianFranz at gmx.de Sun May 25 18:56:47 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 25 May 2003 18:56:47 +0200 Subject: [MPlayer-G2-dev] [PATCH] libmpeg2 post-processing support Message-ID: <200305251856.47890.FabianFranz@gmx.de> Hi, attached patch enables libmpeg2 to support post-processing. It also enables it in vd_libmpeg2.c. I've tested it and it works (at least for me :) ). (Slow, but the image got "better". Heh, my comptuer is slow ;) ) If this patch is correct, I'll try to get it into official libmpeg2-cvs. A'rpi, could you please check ? cu Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-libmpeg2-pp.diff Type: text/x-diff Size: 5269 bytes Desc: not available URL: From arpi at thot.banki.hu Sun May 25 19:11:34 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 19:11:34 +0200 Subject: [MPlayer-G2-dev] G2, DVDnav, etc. In-Reply-To: <1053881733.26414.155.camel@orangutan.home.ru> Message-ID: <200305251711.h4PHBYaB027770@mail.mplayerhq.hu> Hi, > > btw the problem with libdvdnav is that you cannot use mplayer's cache2 > > layer for it. i've heard about some patches which added some > > caching/buffering to libdvdnav, dunno if they are usable or still exists. > Yes it has caching support, but there is one small problem. We cannot > use external libdvdnav: recently, they imported libdvdread into it, so > mpdvdkit2 will probably clash with dvdread from libdvdnav. So, libdvdnav > must be imported into G2. Then, IIUC, if we must import G2, why we must > relay on their caching system, when there is good native cache? our cache (if you mean my cache2.c) is not able to cache events., and to pass events to/from child process. > > I hope that nothing. > > The final a-v sync code will recognize and handle still frames. > > The only problem i can see is the OSD rendering. Ie if we have to render > > something over the still images. > We MUST render selections, which IIRC are SPU streams. Maybe there could > be a simple vf, that passes all non-still images, and when we receive > still-frame command, it stores frame in internal buffer? yes, the OSD rendering filter (be it vf_expand or vf_vo2) should be able to restore original image after rendering osd into it. > I really suppose, that navigation belongs to demuxer. Really: and where the mpeg demuxer belongs to? ui? :) > > > 5. Latest part is output. What is required here? libvo2 must support > > > image resizing/still frames. Resizing is supported (at least > > > > why? (why do dvdnav requires resizing at vo ???) > not dvdnav. There are(or maybe it's a bug of ogle, but they could exist) > DVDs, where nav menus could use different resolutions. it's codec's problem to detect aspect/size changes and notify swscale or vo to resize. > > > theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned > > > above. Maybe I'm missing something,but IIUC, libaf chains are build > > > independantly for each audio stream. > > > > yes > Ok. Now we mustn't support switching of audio streams. > We must support rebuilding of the whole audio chain on-fly. of course. but why is it a problem? it's normal. if you switch from ac3 5.1 to ac3 2.0 or to lpcm you need to reconfigure the af layer to convert (up/downsample channels etc) the new codec's output format to the ao's input format. btw libaf was designed to allow runtime config changes without re-building the chain. so you need to replace codec but can keep af + ao. (but have to notify af about the change, of course). A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lumag at qnc.ru Sun May 25 20:58:15 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 25 May 2003 22:58:15 +0400 Subject: [MPlayer-G2-dev] G2, DVDnav, etc. In-Reply-To: <200305251711.h4PHBYaB027770@mail.mplayerhq.hu> References: <200305251711.h4PHBYaB027770@mail.mplayerhq.hu> Message-ID: <1053889091.5695.1.camel@orangutan.home.ru> Hello! ?? ?? 25.05.2003, ?? 21:11, Arpi ??????????: > Hi, > > > > btw the problem with libdvdnav is that you cannot use mplayer's cache2 > > > layer for it. i've heard about some patches which added some > > > caching/buffering to libdvdnav, dunno if they are usable or still exists. > > Yes it has caching support, but there is one small problem. We cannot > > use external libdvdnav: recently, they imported libdvdread into it, so > > mpdvdkit2 will probably clash with dvdread from libdvdnav. So, libdvdnav > > must be imported into G2. Then, IIUC, if we must import G2, why we must > > relay on their caching system, when there is good native cache? > > our cache (if you mean my cache2.c) is not able to cache events., and to > pass events to/from child process. This isn't required: That's what I told in first letter. Cache layer caches DVD (AS IS, I hope cache2.c can do this?). navigation (VM-emulation) takes place in main process. > > > I hope that nothing. > > > The final a-v sync code will recognize and handle still frames. > > > The only problem i can see is the OSD rendering. Ie if we have to render > > > something over the still images. > > We MUST render selections, which IIRC are SPU streams. Maybe there could > > be a simple vf, that passes all non-still images, and when we receive > > still-frame command, it stores frame in internal buffer? > > yes, the OSD rendering filter (be it vf_expand or vf_vo2) should be able to > restore original image after rendering osd into it. Good news. > > I really suppose, that navigation belongs to demuxer. Really: > > and where the mpeg demuxer belongs to? ui? :) Why? I mean that code, that really 'navigates' - gets user events from libinput or anything else, and executes specified VM instructions. It doesn't have anything to do with ui. Why do you want to place VM in UI? > > > > 5. Latest part is output. What is required here? libvo2 must support > > > > image resizing/still frames. Resizing is supported (at least > > > > > > why? (why do dvdnav requires resizing at vo ???) > > not dvdnav. There are(or maybe it's a bug of ogle, but they could exist) > > DVDs, where nav menus could use different resolutions. > > it's codec's problem to detect aspect/size changes and notify swscale or vo > to resize. Ok. Of course VM-emulation doesn't have anything connected with direct frames. > > > > theoretically - VOCTRL_RESIZE_*). libao2 (or maybe libao3) is mentioned > > > > above. Maybe I'm missing something,but IIUC, libaf chains are build > > > > independantly for each audio stream. > > > > > > yes > > Ok. Now we mustn't support switching of audio streams. > > We must support rebuilding of the whole audio chain on-fly. > > of course. but why is it a problem? it's normal. I didn't say, that it's a problem. > if you switch from ac3 5.1 to ac3 2.0 or to lpcm you need to reconfigure > the af layer to convert (up/downsample channels etc) the new codec's output > format to the ao's input format. btw libaf was designed to allow runtime > config changes without re-building the chain. so you need to replace codec > but can keep af + ao. (but have to notify af about the change, of course). Ok. > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry Baryshkov From arpi at thot.banki.hu Sun May 25 22:12:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 22:12:50 +0200 Subject: [MPlayer-G2-dev] pre30... Message-ID: <200305252012.h4PKCowK003679@mail.mplayerhq.hu> Hi, pre30: - stream layer fixes/ports by Fabian Franz: - decreased smb:// verbose level - http proxy support - bin/cue support - vcd cleanup - DOCS/cfg.txt - libvo2 migrated to new config layer - vf_scale cleanup, migrated to new config layer (-sws, -ssf etc) - several 10ls fixed in config layers A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Sun May 25 23:14:00 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Sun, 25 May 2003 23:14:00 +0200 Subject: [MPlayer-G2-dev] [SUGGESTIIONS] g2/stream/README, g2/stream/stream_smb.c In-Reply-To: <200305251342.h4PDgxYG024361@mail.mplayerhq.hu> References: <200305251342.h4PDgxYG024361@mail.mplayerhq.hu> Message-ID: <200305252314.01064.FabianFranz@gmx.de> Am Sonntag, 25. Mai 2003 15:42 schrieb Arpi: > Hi, > > > update g2/stream/README to reflect that smb is suppported. (and cue after > > applying my patch ;) ) > > done :) liar ;) g2/stream/README was not updatet in pre30 :)) (but thats not really important, I'm just joking around) > > > Change > > > > //err = smbc_init(smb_auth_fn, 10); // Initialize libsmbclient > > err = smbc_init(smb_auth_fn, 0); // Initialize libsmbclient > > done > i've changed it 1, hope it's ok yep. Its perfect. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Sun May 25 23:17:15 2003 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 May 2003 23:17:15 +0200 Subject: [MPlayer-G2-dev] [SUGGESTIIONS] g2/stream/README, g2/stream/stream_smb.c In-Reply-To: <200305252314.01064.FabianFranz@gmx.de> Message-ID: <200305252117.h4PLHF0F013200@mail.mplayerhq.hu> Hi, > Am Sonntag, 25. Mai 2003 15:42 schrieb Arpi: > > Hi, > > > > > update g2/stream/README to reflect that smb is suppported. (and cue after > > > applying my patch ;) ) > > > > done :) > > liar ;) g2/stream/README was not updatet in pre30 :)) (but thats not really > important, I'm just joking around) eh, i meant TODO is it mentioned in README too? hmm A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 00:06:51 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 00:06:51 +0200 Subject: [MPlayer-G2-dev] [QUESTION] g1's network.c-nop-functions Message-ID: <200305260006.51698.FabianFranz@gmx.de> Hi, while porting mms-support I found that nop-functions, which seem to just do cached/buffered reads, but as cache2.c already has such functions and I think this should be handled in layers above, by setting stream->buf_size and so on, I don't understand WHY this functions are there and if they are needed for g2 ... (and even for g1) I guess not and will try to implement it that way ... Please enlight me! cu Fabian From arpi at thot.banki.hu Mon May 26 00:20:52 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 00:20:52 +0200 Subject: [MPlayer-G2-dev] [QUESTION] g1's network.c-nop-functions In-Reply-To: <200305260006.51698.FabianFranz@gmx.de> Message-ID: <200305252220.h4PMKqtG017305@mail.mplayerhq.hu> Hi, > Hi, > > while porting mms-support I found that nop-functions, which seem to just do > cached/buffered reads, but as cache2.c already has such functions and I think > this should be handled in layers above, by setting stream->buf_size and so > on, I don't understand WHY this functions are there and if they are needed > for g2 ... (and even for g1) > > I guess not and will try to implement it that way ... > > Please enlight me! dunno why are they there in g1, it's an useless buffering layer imho. imho the whole streaming_ctrl mess of g1 is useless. so i simply left them out in g2 and voala it still works. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 00:26:58 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 00:26:58 +0200 Subject: [MPlayer-G2-dev] [QUESTION] g1's network.c-nop-functions In-Reply-To: <200305252220.h4PMKqtG017305@mail.mplayerhq.hu> References: <200305252220.h4PMKqtG017305@mail.mplayerhq.hu> Message-ID: <200305260026.58291.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 00:20 schrieb Arpi: > Hi, > > > Hi, > > > > while porting mms-support I found that nop-functions, which seem to just > > do cached/buffered reads, but as cache2.c already has such functions and > > I think this should be handled in layers above, by setting > > stream->buf_size and so on, I don't understand WHY this functions are > > there and if they are needed for g2 ... (and even for g1) > > > > I guess not and will try to implement it that way ... > > > > Please enlight me! > > dunno why are they there in g1, it's an useless buffering layer imho. > imho the whole streaming_ctrl mess of g1 is useless. > so i simply left them out in g2 and voala it still works. Hm, yeah :) Seems that though I "need" (Its an nice extension that was there in g1) bandwidth, which shall be settable from comamndline/config ? How does I manage to do this with new config-layer ? And what about several streaming-modules that need to implement this var, does the config-layer handle that ? I don't think it would be good to add it to stream_s therefor I'm asking for other ways. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Mon May 26 00:44:36 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 00:44:36 +0200 Subject: [MPlayer-G2-dev] [QUESTION] g1's network.c-nop-functions In-Reply-To: <200305260026.58291.FabianFranz@gmx.de> Message-ID: <200305252244.h4PMiadm029343@mail.mplayerhq.hu> Hi, > Seems that though I "need" (Its an nice extension that was there in g1) > bandwidth, which shall be settable from comamndline/config ? > > How does I manage to do this with new config-layer ? define a global var :) > And what about several streaming-modules that need to implement this var, does > the config-layer handle that ? > > I don't think it would be good to add it to stream_s therefor I'm asking for > other ways. i'm still thinking about the stream/demuxer layer configuration. it's not so trivial as filters or vo drivers, as in this case the stream/demux driver to be used is autodetected, in case of streams it's even worse: it comes from the url:// of the url. my best idea (but i don't liek it) up to now: -stream vcd=/dev/hdd:speed=2:xyz=123,http=proxy=10.1.1.1:8080,mms=bw=384 so list the configuration for each module/plugin (you can put this into config files too) and the stream/demux core will pick up the one it actually uses. the other way is just -stream proxy=10.1.1.1:8080,bw=384 and it will be applied to the driver selected based on url://. both has pros and contras. better ideas? note, that for config files the former should go, in such sytnax: core.stream = plugindir=/usr/share/mplayer/plugins/stream/ stream.vcd = /dev/hdd:speed=2:xyz=123 stream.mms = proxy=10.1.1.1:8080,bw=384 .. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 01:22:45 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 01:22:45 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main Message-ID: <200305260122.45375.FabianFranz@gmx.de> hi, here it is. As always I had some questions and marked them with // FF: . But the good thing is, that it already works and output seems to me (as far as I can see with watching some videos ;) not different from mmst://) cu Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: stream_mms.c Type: text/x-csrc Size: 21506 bytes Desc: not available URL: From arpi at thot.banki.hu Mon May 26 01:41:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 01:41:17 +0200 Subject: [MPlayer-G2-dev] RFC: commandline syntax Message-ID: <200305252341.h4PNfHNk027652@mail.mplayerhq.hu> Hi, Before we start flaming about commandline parsing is UI's job, of course it is. But we have to prepare core libs and config code to serve it. And anyway defining a standard (reference) syntax for g2 libs is not a bad thing, imho. And anyway 2, we should implement a simple CLI for testing g2 libs (sth like current test-play.c). Ok, the topic of this thread will be the reference (recommended) commandline syntax. Ie how to pass arhs to the core libs, modules/plugins. AO/VO ~~~~~ In case of ao and vo, i would keep the old (g1) syntax, with the little difference that 'subdevice' is now parsed by the config layer instead of sscanf and such mess. I've already updated libvo2 to use it. Libao2 isn't update dyet, but 1. Anders promised some libao3? 2. we need to change libao2 API anyway to get rid of ao-data and such globals, so we can do the ao_info=>module_info change at the same time. So the syntax is -vo driver1[=[param1=]arg1[:[param2=]arg2...]][,driver2][,] In short: oen or more drivers (even teh same driver with different args, for example -vo mga:/dev/mga_vid1,mga:/dev/mga_vid0) can be listed together with their optional args (which may be just arg-list (like g1's -vf syntax) or named params (like g1's subconfig) or the combination of them). The list may be terminated by a comma (,), it means that non-listed drivers should be tried too. AF/VF ~~~~~ For audio/video filters, imho g1's -vf syntax is still ok: -vf filter1[=[param1=]arg1[:[param2=]arg2...]][,filter2][,] (so it's the same as ao/vo but lists filters instead of drivers, and all the filters are loaded/inited/used not only the first available one) It's implemented for video filters in g2 (ok it's buggy as it uses reverse (-vop) order but -vf name :)). I plan to redesign audio filter layer, so i left it for now. Ok we're over the simple things. AC/VC/AFM/VFM ~~~~~~~~~~~~~ Audio/video codecs: in g1 there is no way to pass options to codecs directly in -ac/-vc/-afm/-vfm options. There is -lavdopts for the only codec requiring extra config. So it's unusual that a codec have extra config, so I left codec level migration for now. It's not easy anyway (i have an almost-compilable version locally but it's ugly as hell due to triple typecasts in function calls). If we decide that we need to pass config to codecs in a generic way (ie. no -lavdopts), then the question is there: how?? Actually codec modules/plugins are named by -afm/-vfm options, the -ac/-vc options name codecs.conf entries, not plugins. Maybe an -vdopts/-adopts can do the job? see bellow at stream. STREAM ~~~~~~ It'ts tricky. Currently the stream driver to be used is determined from the url. If it has prot://... syntax, then stream_prot.c is used (if exists, otherwise dummy stream handle is created for stream-less demuxers...). If it has no prot://... syntax, it's assumed to be plain file or stream (==non-seekable file, like stdin or pipe). Ok it's not so simple. Plugins may be named differently than url:// syntax, to allow multiple plugins to handle same url (for example rtsp:// or rtp:// cases, when there is live.com, real-rtsp and dvbstream's rtp). So, we also need a way to explicitly name (or list in order) the stream drivers to be used. There is 2 methods to pass config: 1. -stream [option1=]value1[:option2=value2...], ie g1-subconfig syntax. it will allow options for single driver/plugin only, and will eb applied to the driver selected based on url/type. 2. -stream driver1[=[option1=]value1[:...]][,driver2...][,], ie. ao/vo syntax I guess we should vote for 2 (while 5 mins ago i thought 1. is better), because this way we get parsig for free (automatic handled by cfg layer 1) and we can explicitly name/order drivers, even the same driver with different args (like -stream vcd=dev=/dev/hdd:vcd=dev=/dev/hdc, to force player to try both cdrom drives when playing vcd) DEMUX: ~~~~~~ After writting the above lines, i guess it's the same case as stream. Maybe we should extend the syntax (both stream & demuxer, but it could help in codec acse too) somehow to allow out-of-order configuration. Ie list various plugins with their config/args, but _without_ changing the order 'hardcoded' in the core libs or codecs.conf. It could be different option (like -demuxopts or -demuxconf) or some special sign in the option list to note it's unordered, for example -demuxer !mpeg=maxpkt=8192 would mean use maxpkt=8192 for moeg demuxer, but do not raise mpeg demuxer to top priority. I'm interested in comments, better ideas, i'm not too good in CLI design ;( Also we should discuss/decide if we keep CLI somewhat compatible/consistent with g1 or redesign (option names, syntax) from scratch? Imho g1's syntax is not as bad, with the above things decided it could be usable. Also keeping g1's syntax will make migrating easier for users, and even for developers. Ah, and yet another thing: currently the cfg-parser is very strict, if you do synatx errors, list non-existant modules/plugins, it will exit with error. Imho we should find some nice way to handle existing but non-available options (like -dvd without dvdread support compiled in (YES i know it's wrong example for g2...)), and non-existant (or non-available, == not compiled / downloaded plugin) plugins. For example, g1's -vop allwoed to list non-existant filter, and it didn't even fail, just printed warning message that that filter doesn't exist and is ignored. ok, enough for today. happy brainstorming :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 01:49:30 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 01:49:30 +0200 Subject: [MPlayer-G2-dev] [QUESTION] (How) will you handle playlists and other info structures ? Message-ID: <200305260149.30419.FabianFranz@gmx.de> Hi, (How) will you handle playlists and other info structures ? like cddb-titles, dvd-titles, mov-lists, asx-parsing ( :( ) and so on to get it nicely to CONTROL (i.e. cli/gui) from demuxer/stream-layer. I think this still needs to be designed. cu Fabian From arpi at thot.banki.hu Mon May 26 01:54:45 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 01:54:45 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260122.45375.FabianFranz@gmx.de> Message-ID: <200305252354.h4PNsj5w003362@mail.mplayerhq.hu> Hi, > here it is. cool! btw it doesn't compile, could you send complete diff to pre30? it includes asf.h, but the one in g2 doesn't work (missing defines). also the stream_priv_s is nowhere defined, but is used. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 02:00:15 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 02:00:15 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305252354.h4PNsj5w003362@mail.mplayerhq.hu> References: <200305252354.h4PNsj5w003362@mail.mplayerhq.hu> Message-ID: <200305260200.15504.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 01:54 schrieb Arpi: > Hi, > > > here it is. > > cool! > > btw it doesn't compile, could you send complete diff to pre30? of course :) > it includes asf.h, but the one in g2 doesn't work (missing defines). yeah... sorry forgot that. > also the stream_priv_s is nowhere defined, but is used. huh ? it is defined in stream.h isn't it ? cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: g2-mms-support.diff Type: text/x-diff Size: 31385 bytes Desc: not available URL: From FabianFranz at gmx.de Mon May 26 02:09:00 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 02:09:00 +0200 Subject: [MPlayer-G2-dev] RFC: commandline syntax In-Reply-To: <200305252341.h4PNfHNk027652@mail.mplayerhq.hu> References: <200305252341.h4PNfHNk027652@mail.mplayerhq.hu> Message-ID: <200305260209.00940.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 01:41 schrieb Arpi: > Hi, > > AO/VO > ~~~~~ > > So the syntax is -vo > driver1[=[param1=]arg1[:[param2=]arg2...]][,driver2][,] I vote to keep that one. > > AF/VF > ~~~~~ > For audio/video filters, imho g1's -vf syntax is still ok: > -vf filter1[=[param1=]arg1[:[param2=]arg2...]][,filter2][,] I agree. > > Ok we're over the simple things. :-/ > > AC/VC/AFM/VFM > ~~~~~~~~~~~~~ > Audio/video codecs: in g1 there is no way to pass options to codecs > directly in -ac/-vc/-afm/-vfm options. There is -lavdopts for the only > codec requiring extra config. So it's unusual that a codec have extra > config, so I left codec level migration for now. It's not easy anyway (i > have an almost-compilable version locally but it's ugly as hell due to > triple typecasts in function calls). > If we decide that we need to pass config to codecs in a generic way (ie. no > -lavdopts), then the question is there: how?? > Actually codec modules/plugins are named by -afm/-vfm options, the -ac/-vc > options name codecs.conf entries, not plugins. Hm, so in g1 there is no difference, between vc/vfm and ac/afm but in g2 ? I don't understand why it is not possible to do: -vc codec=parameters,nextcodectotry > > STREAM > ~~~~~~ > It'ts tricky. Currently the stream driver to be used is determined from > the url. If it has prot://... syntax, then stream_prot.c is used (if > exists, otherwise dummy stream handle is created for stream-less > demuxers...). If it has no prot://... syntax, it's assumed to be plain file > or stream (==non-seekable file, like stdin or pipe). > Ok it's not so simple. Plugins may be named differently than url:// syntax, > to allow multiple plugins to handle same url (for example rtsp:// or rtp:// > cases, when there is live.com, real-rtsp and dvbstream's rtp). > So, we also need a way to explicitly name (or list in order) the stream > drivers to be used. > There is 2 methods to pass config: > 1. -stream [option1=]value1[:option2=value2...], ie g1-subconfig syntax. > it will allow options for single driver/plugin only, and will eb applied > to the driver selected based on url/type. > 2. -stream driver1[=[option1=]value1[:...]][,driver2...][,], ie. ao/vo > syntax I vote for 2. > > I guess we should vote for 2 (while 5 mins ago i thought 1. is better), > because this way we get parsig for free (automatic handled by cfg layer 1) > and we can explicitly name/order drivers, even the same driver with > different args (like -stream vcd=dev=/dev/hdd:vcd=dev=/dev/hdc, to force > player to try both cdrom drives when playing vcd) Uhm, did you mean: -stream vcd:dev=/dev/hdd,vcd:dev=/dev/hdc ? Else I don't see why it is the same syntax as with -vo/-ao > > DEMUX: > ~~~~~~ > After writting the above lines, i guess it's the same case as stream. > Maybe we should extend the syntax (both stream & demuxer, but it could > help in codec acse too) somehow to allow out-of-order configuration. > Ie list various plugins with their config/args, but _without_ changing > the order 'hardcoded' in the core libs or codecs.conf. > It could be different option (like -demuxopts or -demuxconf) or some > special sign in the option list to note it's unordered, for example > -demuxer !mpeg=maxpkt=8192 would mean use maxpkt=8192 for moeg demuxer, > but do not raise mpeg demuxer to top priority. Hm, I like -demuxopts better if one just wants to configure the demuxer. > > I'm interested in comments, better ideas, i'm not too good in CLI design ;( > Also we should discuss/decide if we keep CLI somewhat compatible/consistent > with g1 or redesign (option names, syntax) from scratch? > Imho g1's syntax is not as bad, with the above things decided it could be > usable. Also keeping g1's syntax will make migrating easier for users, > and even for developers. yes :) > > Ah, and yet another thing: currently the cfg-parser is very strict, if > you do synatx errors, list non-existant modules/plugins, it will exit with > error. I already oticed this while trying to use -vop pp :)) (-vf pp did of course work) > Imho we should find some nice way to handle existing but > non-available options (like -dvd without dvdread support compiled in > (YES i know it's wrong example for g2...)), and non-existant (or > non-available, == not compiled / downloaded plugin) plugins. Yes, I vote to have some possibility for a module to "pull" data out of the config-layer if needed. So not everything needs to be predicted and unknown values are just ignored and stored for later use. > For example, g1's -vop allwoed to list non-existant filter, and it didn't > even fail, just printed warning message that that filter doesn't exist and > is ignored. that is good :) cu Fabian > > ok, enough for today. happy brainstorming :) lightning/thunder ... *roll* > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Mon May 26 02:23:08 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 02:23:08 +0200 Subject: [MPlayer-G2-dev] RFC: commandline syntax In-Reply-To: <200305260209.00940.FabianFranz@gmx.de> Message-ID: <200305260023.h4Q0N8mK020229@mail.mplayerhq.hu> Hi, > > AC/VC/AFM/VFM > > ~~~~~~~~~~~~~ > > Audio/video codecs: in g1 there is no way to pass options to codecs > > directly in -ac/-vc/-afm/-vfm options. There is -lavdopts for the only > > codec requiring extra config. So it's unusual that a codec have extra > > config, so I left codec level migration for now. It's not easy anyway (i > > have an almost-compilable version locally but it's ugly as hell due to > > triple typecasts in function calls). > > If we decide that we need to pass config to codecs in a generic way (ie. no > > -lavdopts), then the question is there: how?? > > Actually codec modules/plugins are named by -afm/-vfm options, the -ac/-vc > > options name codecs.conf entries, not plugins. > > Hm, so in g1 there is no difference, between vc/vfm and ac/afm but in g2 ? > > I don't understand why it is not possible to do: > > -vc codec=parameters,nextcodectotry becaus ethere is no module/plugin called codec and nextcodectotry. the codec names used with -vc/-ac are not the module names, but some config/template name from codecs.conf. teh codecs.cofn entries contain the actual configuration for the codec plugin/module/driver. ok it could be hacked to pass -vc xyz=hjsgja to the module, but its' ugly hack in the config layers. (you have to send string though the codec.conf parsing codec opening etc before you can parse it). > > I guess we should vote for 2 (while 5 mins ago i thought 1. is better), > > because this way we get parsig for free (automatic handled by cfg layer 1) > > and we can explicitly name/order drivers, even the same driver with > > different args (like -stream vcd=dev=/dev/hdd:vcd=dev=/dev/hdc, to force > > player to try both cdrom drives when playing vcd) > > Uhm, did you mean: > > -stream vcd:dev=/dev/hdd,vcd:dev=/dev/hdc ? of course :) > Else I don't see why it is the same syntax as with -vo/-ao it was typo (not the first one in taht mail:)) > Yes, I vote to have some possibility for a module to "pull" data out of the > config-layer if needed. > > So not everything needs to be predicted and unknown values are just ignored > and stored for later use. hmm, no... the core libs shouldn't depend on config parsers. it was the main issue with g1. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Mon May 26 02:24:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 02:24:20 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260200.15504.FabianFranz@gmx.de> Message-ID: <200305260024.h4Q0OKLH020719@mail.mplayerhq.hu> Hi, > > also the stream_priv_s is nowhere defined, but is used. > > huh ? it is defined in stream.h isn't it ? huh? each stream plugin define its own priv struct... see my mail sent yesterday in teh cue-patch thrad :) then you said you understood :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 02:32:13 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 02:32:13 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260024.h4Q0OKLH020719@mail.mplayerhq.hu> References: <200305260024.h4Q0OKLH020719@mail.mplayerhq.hu> Message-ID: <200305260232.13280.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 02:24 schrieb Arpi: > Hi, > > > > also the stream_priv_s is nowhere defined, but is used. > > > > huh ? it is defined in stream.h isn't it ? > > huh? each stream plugin define its own priv struct... > see my mail sent yesterday in teh cue-patch thrad :) > then you said you understood :) lol, just a misunderstanding. Of course I did understand it :) I had implemented it in asf.h so naturally for me it was there and I thought you meant the prototype that was not there. :)) cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From FabianFranz at gmx.de Mon May 26 02:34:26 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 02:34:26 +0200 Subject: [MPlayer-G2-dev] RFC: commandline syntax In-Reply-To: <200305260023.h4Q0N8mK020229@mail.mplayerhq.hu> References: <200305260023.h4Q0N8mK020229@mail.mplayerhq.hu> Message-ID: <200305260234.26123.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 02:23 schrieb Arpi: > Hi, > > > > AC/VC/AFM/VFM > > > ~~~~~~~~~~~~~ > > > Audio/video codecs: in g1 there is no way to pass options to codecs > > > directly in -ac/-vc/-afm/-vfm options. There is -lavdopts for the only > > > codec requiring extra config. So it's unusual that a codec have extra > > > config, so I left codec level migration for now. It's not easy anyway > > > (i have an almost-compilable version locally but it's ugly as hell due > > > to triple typecasts in function calls). > > > If we decide that we need to pass config to codecs in a generic way > > > (ie. no -lavdopts), then the question is there: how?? > > > Actually codec modules/plugins are named by -afm/-vfm options, the > > > -ac/-vc options name codecs.conf entries, not plugins. > > > > Hm, so in g1 there is no difference, between vc/vfm and ac/afm but in g2 > > ? > > > > I don't understand why it is not possible to do: > > > > -vc codec=parameters,nextcodectotry > > becaus ethere is no module/plugin called codec and nextcodectotry. > the codec names used with -vc/-ac are not the module names, but some > config/template name from codecs.conf. teh codecs.cofn entries contain > the actual configuration for the codec plugin/module/driver. hm, ok > > ok it could be hacked to pass -vc xyz=hjsgja to the module, but its' ugly > hack in the config layers. (you have to send string though the codec.conf > parsing codec opening etc before you can parse it). hm, I understand now. > > > > I guess we should vote for 2 (while 5 mins ago i thought 1. is better), > > > because this way we get parsig for free (automatic handled by cfg layer > > > 1) and we can explicitly name/order drivers, even the same driver with > > > different args (like -stream vcd=dev=/dev/hdd:vcd=dev=/dev/hdc, to > > > force player to try both cdrom drives when playing vcd) > > > > Uhm, did you mean: > > > > -stream vcd:dev=/dev/hdd,vcd:dev=/dev/hdc ? > > of course :) > > > Else I don't see why it is the same syntax as with -vo/-ao > > it was typo (not the first one in taht mail:)) :) > > > Yes, I vote to have some possibility for a module to "pull" data out of > > the config-layer if needed. > > > > So not everything needs to be predicted and unknown values are just > > ignored and stored for later use. > > hmm, no... the core libs shouldn't depend on config parsers. > it was the main issue with g1. ok, understood. cu Fabian PS: Sorry for being off-topic, but are there other stream-things left to port ? > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Mon May 26 02:40:41 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 02:40:41 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260232.13280.FabianFranz@gmx.de> Message-ID: <200305260040.h4Q0efRQ026142@mail.mplayerhq.hu> Hi, > > > > > > also the stream_priv_s is nowhere defined, but is used. > > > > > > huh ? it is defined in stream.h isn't it ? > > > > huh? each stream plugin define its own priv struct... > > see my mail sent yesterday in teh cue-patch thrad :) > > then you said you understood :) > > lol, just a misunderstanding. Of course I did understand it :) > > I had implemented it in asf.h so naturally for me it was there and I thought > you meant the prototype that was not there. :)) ok i found it now (first you didn't sent asf.h and the one i had didn't contain stream_priv_s) now i've merged your asf.h with the one in demux/asf.h, to avoid useless duplication (they were 99% same). > PS: Sorry for being off-topic, but are there other stream-things left to port only realmedia rtsp://, but it isn't important and we cannot even test it yet as no demux_real in g2. 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 May 26 02:42:26 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 02:42:26 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260040.h4Q0efRQ026142@mail.mplayerhq.hu> Message-ID: <200305260042.h4Q0gQnT026827@mail.mplayerhq.hu> Hi, > > PS: Sorry for being off-topic, but are there other stream-things left to port btw, isn't better to use that check4proxies thingie instead of: // Check if we are using a proxy if( !strcasecmp( url->protocol, "http_proxy" ) ) { .. in mms too? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 02:43:01 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 02:43:01 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260040.h4Q0efRQ026142@mail.mplayerhq.hu> References: <200305260040.h4Q0efRQ026142@mail.mplayerhq.hu> Message-ID: <200305260243.01666.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 02:40 schrieb Arpi: > Hi, > > > > > > also the stream_priv_s is nowhere defined, but is used. > > > > > > > > huh ? it is defined in stream.h isn't it ? > > > > > > huh? each stream plugin define its own priv struct... > > > see my mail sent yesterday in teh cue-patch thrad :) > > > then you said you understood :) > > > > lol, just a misunderstanding. Of course I did understand it :) > > > > I had implemented it in asf.h so naturally for me it was there and I > > thought you meant the prototype that was not there. :)) > > ok i found it now > (first you didn't sent asf.h and the one i had didn't contain > stream_priv_s) of course not, and I did overlook that there was a asf.h in g2 ... :-/ *sorry* > > now i've merged your asf.h with the one in demux/asf.h, to avoid useless > duplication (they were 99% same). :) > > > PS: Sorry for being off-topic, but are there other stream-things left to > > port > > only realmedia rtsp://, but it isn't important and we cannot even test it > yet as no demux_real in g2. hm ... ok, what can I do/try now/next in your eyes ? cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Mon May 26 02:53:03 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 02:53:03 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260243.01666.FabianFranz@gmx.de> Message-ID: <200305260053.h4Q0r3kM030764@mail.mplayerhq.hu> Hi, > > > I had implemented it in asf.h so naturally for me it was there and I > > > thought you meant the prototype that was not there. :)) > > > > ok i found it now > > (first you didn't sent asf.h and the one i had didn't contain > > stream_priv_s) > > of course not, and I did overlook that there was a asf.h in g2 ... :-/ *sorry* it's there as asf demuxer needs the same structs. > > only realmedia rtsp://, but it isn't important and we cannot even test it > > yet as no demux_real in g2. > > hm ... ok, what can I do/try now/next in your eyes ? dunno... the TODO is quite long, ther are several interesting entries for you: demuxer layer: - layer 1/2 support into mp3_hdr.[ch] - mpeg4-es and h264 support into mpg demuxer - port other demuxers from mplayer 0_90/main stream layer: - add metadata support, export tracklist - realmedia rtsp:// support - cddb:// ??? I sugges this, it's a big project but is made for you: :))) - add metadata support, export tracklist ie design the way how stream plugins may export metadata, like artist/title (both global and per-track, like g2's demuxer's metadata stuff) and tracklist/track structure (including dvd titles/chapters/angle slist, cdda tracks, cddb info and so on) and (your favourite one:) playlists/redirectors. i guess the design should be done first and discussed here, before you hack all the modules :) i'm not sure but maybe even dvd navigation should be handled here? (as it's really a stream and not a demuxer, but dunno) If you don't like this, i understand :) You can still go for demuxers or port vo drivers. Or go and design the subtitles layer in demuxer :) (but imho it's better if done by me) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 03:05:51 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 03:05:51 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260042.h4Q0gQnT026827@mail.mplayerhq.hu> References: <200305260042.h4Q0gQnT026827@mail.mplayerhq.hu> Message-ID: <200305260305.51204.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 02:42 schrieb Arpi: > Hi, > > > > PS: Sorry for being off-topic, but are there other stream-things left > > > to port > > btw, isn't better to use that check4proxies thingie instead of: check4proxies is just an extension to set the protocol to http_proxy://proxy:port/some_prot://some_url ... > > // Check if we are using a proxy > if( !strcasecmp( url->protocol, "http_proxy" ) ) { > > .. in mms too? So it needs to be added additionally if, but it did not work for me in my tests. (neither with g1 nor with g2, so I guess I have proxies that don't support mms) For that we need somebody that implemented and used proxy with mms in g1. cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From FabianFranz at gmx.de Mon May 26 03:22:04 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 03:22:04 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260053.h4Q0r3kM030764@mail.mplayerhq.hu> References: <200305260053.h4Q0r3kM030764@mail.mplayerhq.hu> Message-ID: <200305260322.04791.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 02:53 schrieb Arpi: > Hi, > > I sugges this, it's a big project but is made for you: :))) :) > - add metadata support, export tracklist > > ie design the way how stream plugins may export metadata, like artist/title > (both global and per-track, like g2's demuxer's metadata stuff) and how is the metadata-stuff global ? (per track I can see) > tracklist/track structure (including dvd titles/chapters/angle slist, cdda > tracks, cddb info and so on) and (your favourite one:) > playlists/redirectors. i guess the design should be done first and > discussed here, before you hack all the modules :) Hm, Ill think about it ... > > i'm not sure but maybe even dvd navigation should be handled here? > (as it's really a stream and not a demuxer, but dunno) hm, its both a stream and a demuxer ... perhaps it should be really BOTH ... > > If you don't like this, i understand :) > You can still go for demuxers or port vo drivers. I don't know why, but vo-design seems very complicated to me. > Or go and design the subtitles layer in demuxer :) (but imho it's better if > done by me) :) So then you design the subtitles layer :)) cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From dalias at aerifal.cx Mon May 26 03:31:54 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Sun, 25 May 2003 21:31:54 -0400 Subject: [MPlayer-G2-dev] pre30... In-Reply-To: <200305252012.h4PKCowK003679@mail.mplayerhq.hu> References: <200305252012.h4PKCowK003679@mail.mplayerhq.hu> Message-ID: <20030526013154.GT23552@brightrain.aerifal.cx> On Sun, May 25, 2003 at 10:12:50PM +0200, Arpi wrote: > Hi, > > pre30: > - stream layer fixes/ports by Fabian Franz: > - decreased smb:// verbose level > - http proxy support > - bin/cue support > - vcd cleanup > - DOCS/cfg.txt > - libvo2 migrated to new config layer > - vf_scale cleanup, migrated to new config layer (-sws, -ssf etc) -sws, -ssf need to be removed in favor of per-instance config items in vf_scale... Rich From jonner at teegra.net Mon May 26 09:04:48 2003 From: jonner at teegra.net (Jonathan Rogers) Date: Mon, 26 May 2003 02:04:48 -0500 Subject: [MPlayer-G2-dev] Can I try it? Message-ID: I know that I'm not a G2 developer, and I do not wish to waste any time here, so I'll be brief. Is there any chance of getting anonymous CVS access for G2 so I can start trying it? I realize it's not "ready for the masses," but I want to follow development. I promise not to ask any questions here about getting it to work or otherwise waste anyone's time. Thanks for all the great work you guys have done so far. Jonathan Rogers From arpi at thot.banki.hu Mon May 26 10:30:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 10:30:20 +0200 Subject: [MPlayer-G2-dev] [PATCH] ported mms from main In-Reply-To: <200305260322.04791.FabianFranz@gmx.de> Message-ID: <200305260830.h4Q8UK6p018222@mail.mplayerhq.hu> Hi, > > - add metadata support, export tracklist > > > > ie design the way how stream plugins may export metadata, like artist/title > > (both global and per-track, like g2's demuxer's metadata stuff) and > > how is the metadata-stuff global ? (per track I can see) I mean there may be metadata for the whole media (disc, server, file) and there may be metadata entries for the tracks/channels/etc too. For example global metadata is the artist/title of a audio cd album, per-track metadata is track titles and their length etc. > > If you don't like this, i understand :) > > You can still go for demuxers or port vo drivers. > > I don't know why, but vo-design seems very complicated to me. why? it's a lot simpler/cleaner than in g1 A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Mon May 26 10:31:13 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 10:31:13 +0200 Subject: [MPlayer-G2-dev] pre30... In-Reply-To: <20030526013154.GT23552@brightrain.aerifal.cx> Message-ID: <200305260831.h4Q8VDPK018860@mail.mplayerhq.hu> Hi, > > - vf_scale cleanup, migrated to new config layer (-sws, -ssf etc) > > -sws, -ssf need to be removed in favor of per-instance config items in > vf_scale... i did exactly that now -vf scale have sws lgb etc parameters 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 May 26 10:40:58 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 10:40:58 +0200 Subject: [MPlayer-G2-dev] Can I try it? In-Reply-To: Message-ID: <200305260840.h4Q8ewZJ023539@mail.mplayerhq.hu> Hi, > I know that I'm not a G2 developer, and I do not wish to waste any time > here, so I'll be brief. Is there any chance of getting anonymous CVS g2 isn't (and will not be) in CVS. get it from http://mplayerhq.hu/~arpi/g2/ copy ./configure from g1, it isn't included 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 May 26 10:46:02 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 10:46:02 +0200 Subject: [MPlayer-G2-dev] [QUESTION] (How) will you handle playlists and other info structures ? In-Reply-To: <200305260149.30419.FabianFranz@gmx.de> Message-ID: <200305260846.h4Q8k2ts026108@mail.mplayerhq.hu> Hi, hmm i missed this mail :) > (How) will you handle playlists and other info structures ? > > like cddb-titles, dvd-titles, mov-lists, asx-parsing ( :( ) and so on to get > it nicely to CONTROL (i.e. cli/gui) from demuxer/stream-layer. > > I think this still needs to be designed. for stream layer, yes. for demuxer, it's what the metadata type exists for. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 26 10:44:24 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 11:44:24 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> Message-ID: <20030526084424.GA54253@lucky.net> Hi, Arpi! I've seen your new cfg.h now and I want to say - I'm against of including any function in it. You allow to create some unwanted dependencies on config parsers by lazy developers later! I'm against mpconfig_parse_*() very much! GUI won't have any parameter as string anyway so you'll force GUI makers convert all parameters to string to have compatibility with lazy programmers. It's ugly, sorry. Please, remove any functions from cfg.h and place they in some cfg-l1.h if you wish. Sometime (on Sunday, May 25 at 15:18) I've received something... >> 2. Do you still have something to argue about CONF_TYPE_LIST option type? >isn't my CONF_TYPE_SELECT the same? no. CONF_TYPE_SELECT is to select _one_ option from list of available ones (for example, combobox). CONF_TYPE_LIST is box for selection, remove, and reorder options from list (box with two fields, for example - left is selected list, right is available options list). These are too different and CONF_TYPE_LIST may have items with different type (see my example earlier). >> 4. Let's change unsigned short type, version to unsigned short version, >> type in module_info_t definition to have compatibility forever. :) >no >i'm thinking about add type-specific versions >so if we change vf API we don't have to force demuxer, stream, vo etc plugin >authors/users to recompile their plugins just to get version number bumped. Is there a difference between unsigned short type, version; and unsigned short version, type; anyway? This is anyway from this new API so I think it's easy. I'm thinkig about module loader only - putting unsigned short version as first member of struct will let us change that structure in the future and still have version check available. >> Discussion about CONF_TYPE_GROUP isn't my concern right now since >> that option is application level only and it's marked as TODO anyway. :) >actually i've added CONF_TYPE_MODULE which does the same as you expected >from CONF_TYPE_GROUP. no. :) I've explained that by examples earlier - submenus in GUI aren't modules, are they? I'll try to explain a bit more - see the menu for video encoder GUI: File Video Audio Tools About + ---------+ | Open... | | Save... | |---------------|+----------+ | Save stream...| Audio... | | File info |+ Video... | |---------------|| Text... | | Quit |+----------+ +---------------+ You have menu group 'File' and subgroup in 'Save stream...' option in it. I've explained good now? :) Another example for using of CONF_TYPE_GROUP: (*) constant quantizer [ ] ( ) variable quantizer ---------------------------- minimum quant [ ] maximum quant [ ] ................... --------------------------------------------------- so we have CONF_TYPE_SELECT with two choises: 1) CONF_TYPE_GROUP including 'vqscale' integer. 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options. When we select constant quantizer then second group will be disabled, when we select second group then we cannot change value of 'vqscale'. Config of vf_lavc must have hints for that. Simplest way for it is just have "transparent" CONG_TYPE_GROUP type. Did you understand? If we don't preserve that availability in config struct then GUI maker will have to create own config struct that will allow that by copying all from existing ve_lavc config but with changed a bit structure and then keep it up to date forever. It's too bad and we wanted to avoid that, aren't we? BTW, this sample explaining why I wanted to have CONF_TYPE_SELECT as subconig type too - config_select_list_t doesn't allow us to have choises as CONG_TYPE_GROUP but these must be available for GUI. ;) >> for vf->control(). These requests will have void *data as parameters >> array, preallocated by caller: for VFCTRL_GET_PARAMS it's array with >> undefined values and filter has to set all changeable parameters there; >> VFCTRL_SET_PARAMS will ask the filter to apply changed parameters to >> the instance. Size of that array defined by config_size in module info. >imho VFCTRL_GET_PARAMS is useless. >config_data_t* (the struct containing the preallocated config vars) >is part of the instance structs (vf_instance_t), and is used by the filter >to keep the config data. (ie it's free()'d only at filter uninit). >it's always readable by upper layer (so VFCTRL_GET_PARAMS is useless), but >we should add VFCTRL_SET_PARAMS (or better name) to notify filter about >config changes made by UI. i'm not completely sure about this one yet. >(runtime config change is always a mess...) As you said yourself, runtime config change may be a mess and I don't like to change parameters in running application - only filter may decide if parameter may be applied or not. So I've proposed to get copy of config_data_t* and let filter apply it instead of direct changing it, changes in a copy are always safe. So application will have something like: data_copy=malloc(vf->info->config_size); vf->control(vf, VFCTRL_GET_PARAMS, data_copy); .....change parameters..... vf->control(vf, VFCTRL_SET_PARAMS, data_copy); free(data_copy); Of course, we could data_copy=malloc(vf->info->config_size); memcpy(data_copy, vf->cfg, vf->info->config_size); .....change parameters..... vf->control(vf, VFCTRL_SET_PARAMS, data_copy); free(data_copy); but I don't like to trust developers if they will always use a copy but don't change existing data. You know it yourself, many programmers are too lazy to know all requirements and that may cause troubles. With best wishes. Andriy. From arpi at thot.banki.hu Mon May 26 10:56:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 10:56:20 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526084424.GA54253@lucky.net> Message-ID: <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> Hi, > Sometime (on Sunday, May 25 at 15:18) I've received something... > >> 2. Do you still have something to argue about CONF_TYPE_LIST option type? > > >isn't my CONF_TYPE_SELECT the same? > > no. > CONF_TYPE_SELECT is to select _one_ option from list of available ones > (for example, combobox). CONF_TYPE_LIST is box for selection, remove, and > reorder options from list (box with two fields, for example - left is > selected list, right is available options list). These are too different > and CONF_TYPE_LIST may have items with different type (see my example > earlier). ah, now i see. but why do we need such type? i can't imagine any use. > >> 4. Let's change unsigned short type, version to unsigned short version, > >> type in module_info_t definition to have compatibility forever. :) > > >no > >i'm thinking about add type-specific versions > >so if we change vf API we don't have to force demuxer, stream, vo etc plugin > >authors/users to recompile their plugins just to get version number bumped. > > Is there a difference between > > unsigned short type, version; > > and > > unsigned short version, type; > > anyway? This is anyway from this new API so I think it's easy. I'm > thinkig about module loader only - putting unsigned short version as > first member of struct will let us change that structure in the future > and still have version check available. but as i said, i want type dependant version, so version number without type is useless. > >> Discussion about CONF_TYPE_GROUP isn't my concern right now since > >> that option is application level only and it's marked as TODO anyway. :) > > >actually i've added CONF_TYPE_MODULE which does the same as you expected > >from CONF_TYPE_GROUP. > > no. :) > I've explained that by examples earlier - submenus in GUI aren't modules, > are they? I'll try to explain a bit more - see the menu for video encoder > GUI: > > File Video Audio Tools About > + ---------+ > | Open... | > | Save... | > |---------------|+----------+ > | Save stream...| Audio... | > | File info |+ Video... | > |---------------|| Text... | > | Quit |+----------+ > +---------------+ > > You have menu group 'File' and subgroup in 'Save stream...' option in it. > I've explained good now? :) not this example is not related to config layer at all. such menus are built by gui and not by config stuff. > Another example for using of CONF_TYPE_GROUP: > > (*) constant quantizer [ ] > ( ) variable quantizer ---------------------------- > minimum quant [ ] maximum quant [ ] > ................... > --------------------------------------------------- > > so we have CONF_TYPE_SELECT with two choises: > 1) CONF_TYPE_GROUP including 'vqscale' integer. > 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options. > > When we select constant quantizer then second group will be disabled, > when we select second group then we cannot change value of 'vqscale'. > Config of vf_lavc must have hints for that. Simplest way for it is just > have "transparent" CONG_TYPE_GROUP type. Did you understand? and how would you define the above situation with your types? i can't see how you GROUP helps here. also can't see what is the difference between yoru GROUP and my MODULE, except the name. > If we don't preserve that availability in config struct then GUI maker > will have to create own config struct that will allow that by copying all > from existing ve_lavc config but with changed a bit structure and then > keep it up to date forever. It's too bad and we wanted to avoid that, > aren't we? of course > BTW, this sample explaining why I wanted to have CONF_TYPE_SELECT as > subconig type too - config_select_list_t doesn't allow us to have choises > as CONG_TYPE_GROUP but these must be available for GUI. ;) but it's a mess to allow different tyopes/pointers in each selection A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 26 11:00:21 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 12:00:21 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526084424.GA54253@lucky.net> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> <20030526084424.GA54253@lucky.net> Message-ID: <20030526090021.GA83220@lucky.net> Hi, Andriy N. Gritsenko! Sometime (on Monday, May 26 at 11:44) I've written... >Another example for using of CONF_TYPE_GROUP: >(*) constant quantizer [ ] >( ) variable quantizer ---------------------------- >minimum quant [ ] maximum quant [ ] >................... >--------------------------------------------------- >so we have CONF_TYPE_SELECT with two choises: >1) CONF_TYPE_GROUP including 'vqscale' integer. >2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options. I'm explained a little bad, so I want to explain more. I was wrong here a bit. CONF_TYPE_SELECT really isn't present here but there is two CONF_TYPE_GROUP with some GUI hint (it may be flag in 'vqscale' to enable first group but disable second or may be another unnamed group with flag as select list) - CLI will skip CONF_TYPE_SELECT so for CLI suboptions are just 'vqscale', 'vqmin', 'vqmax', etc. but GUI will have all info it need to form options box. :) With best wishes. Andriy. From andrej at lucky.net Mon May 26 11:40:50 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 12:40:50 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> References: <20030526084424.GA54253@lucky.net> <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> Message-ID: <20030526094050.GB83220@lucky.net> Hi, Arpi! Sometime (on Monday, May 26 at 11:54) I've received something... >> CONF_TYPE_SELECT is to select _one_ option from list of available ones >> (for example, combobox). CONF_TYPE_LIST is box for selection, remove, and >> reorder options from list (box with two fields, for example - left is >> selected list, right is available options list). These are too different >> and CONF_TYPE_LIST may have items with different type (see my example >> earlier). >ah, now i see. >but why do we need such type? i can't imagine any use. See my example about '-fstype' option earlier. I think it's not only example. >> >> 4. Let's change unsigned short type, version to unsigned short version, >> >> type in module_info_t definition to have compatibility forever. :) >> >no >> >i'm thinking about add type-specific versions >> >so if we change vf API we don't have to force demuxer, stream, vo etc plugin >> >authors/users to recompile their plugins just to get version number bumped. >> Is there a difference between >> unsigned short type, version; >> and >> unsigned short version, type; >> anyway? This is anyway from this new API so I think it's easy. I'm >> thinkig about module loader only - putting unsigned short version as >> first member of struct will let us change that structure in the future >> and still have version check available. >but as i said, i want type dependant version, so version number without type >is useless. I didn't mean to omit type but just place version first and type second instead of type first and version second. :) >> >> Discussion about CONF_TYPE_GROUP isn't my concern right now since >> >> that option is application level only and it's marked as TODO anyway. :) >> >> >actually i've added CONF_TYPE_MODULE which does the same as you expected >> >from CONF_TYPE_GROUP. >> >> no. :) >> I've explained that by examples earlier - submenus in GUI aren't modules, >> are they? I'll try to explain a bit more - see the menu for video encoder >> GUI: >> >> File Video Audio Tools About >> + ---------+ >> | Open... | >> | Save... | >> |---------------|+----------+ >> | Save stream...| Audio... | >> | File info |+ Video... | >> |---------------|| Text... | >> | Quit |+----------+ >> +---------------+ >> >> You have menu group 'File' and subgroup in 'Save stream...' option in it. >> I've explained good now? :) >not >this example is not related to config layer at all. >such menus are built by gui and not by config stuff. Yes, you are right, but why we have to discover another special type by GUI and don't have a reserved type for it? Anyway if we don't preserve such type then GUI will have to have two configs - one for menu (with such type), another for config file load/save (if config parser doesn't support that CONF_TYPE_GROUP option). It's bad and doesn't worth avoiding of CONF_TYPE_GROUP. :) >> Another example for using of CONF_TYPE_GROUP: >> >> (*) constant quantizer [ ] >> ( ) variable quantizer ---------------------------- >> minimum quant [ ] maximum quant [ ] >> ................... >> --------------------------------------------------- >> >> so we have CONF_TYPE_SELECT with two choises: >> 1) CONF_TYPE_GROUP including 'vqscale' integer. >> 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options. >> >> When we select constant quantizer then second group will be disabled, >> when we select second group then we cannot change value of 'vqscale'. >> Config of vf_lavc must have hints for that. Simplest way for it is just >> have "transparent" CONG_TYPE_GROUP type. Did you understand? >and how would you define the above situation with your types? >i can't see how you GROUP helps here. For example, we assume that name of group is group selection flag. Then if we define all below we will have all hints to form box above but don't have any changes for CLI syntax: config_t const_vq_group[]={ {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, ""}, {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } config_t var_vq_group[]={ {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, ......... {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } ..... {"vqscale", NULL, CONF_TYPE_GROUP, 0, 0, 0, const_vq_group, "constant quantizer"}, {"!vqscale", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, ..... Of course, we could find another GUI hint instead of option name, I've used it in my example because option name isn't used at all (GUI will use only top-level menu names so it's useless for it, and CLI will skip CONF_TYPE_GROUP). That scheme is clean and simple, as for me, and based only on config layer 0 definitions. >> BTW, this sample explaining why I wanted to have CONF_TYPE_SELECT as >> subconig type too - config_select_list_t doesn't allow us to have choises >> as CONG_TYPE_GROUP but these must be available for GUI. ;) >but it's a mess to allow different tyopes/pointers in each selection Forget it, I've said "wanted" - that was in the past, now I think we can avoid subconfig for such option. :) With best wishes. Andriy. From andrej at lucky.net Mon May 26 11:51:43 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 12:51:43 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> References: <20030526084424.GA54253@lucky.net> <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> Message-ID: <20030526095143.GC83220@lucky.net> Hi, Arpi! Sometime (on Monday, May 26 at 11:54) I've received something... >but as i said, i want type dependant version, so version number without type >is useless. Ah, I get it now. But then we have to keep all versions for all module types in the core and also change it all if we'll change cfg.h. Then also remember to do never change type and version from unsigned short, ever. :) Andriy. From jonner at teegra.net Mon May 26 13:13:17 2003 From: jonner at teegra.net (Jonathan Rogers) Date: Mon, 26 May 2003 06:13:17 -0500 Subject: [MPlayer-G2-dev] Re: Can I try it? In-Reply-To: <200305260840.h4Q8ewZJ023539@mail.mplayerhq.hu> References: <200305260840.h4Q8ewZJ023539@mail.mplayerhq.hu> Message-ID: Arpi wrote: > g2 isn't (and will not be) in CVS. > get it from http://mplayerhq.hu/~arpi/g2/ Thanks Jonathan Rogers From arpi at thot.banki.hu Mon May 26 14:10:16 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 14:10:16 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526095143.GC83220@lucky.net> Message-ID: <200305261210.h4QCAG6Z021928@mail.mplayerhq.hu> Hi, > Sometime (on Monday, May 26 at 11:54) I've received something... > > >but as i said, i want type dependant version, so version number without type > >is useless. > > Ah, I get it now. But then we have to keep all versions for all > module types in the core and also change it all if we'll change cfg.h. > Then also remember to do never change type and version from unsigned > short, ever. :) of course i know that it's not so simple than a single version number, but we have to do this to avoid forcing all plugins to be recompiled when a single API changes. but i've already explained this... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 26 14:42:37 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 15:42:37 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526094050.GB83220@lucky.net> References: <20030526084424.GA54253@lucky.net> <200305260856.h4Q8uKr4002386@mail.mplayerhq.hu> <20030526094050.GB83220@lucky.net> Message-ID: <20030526124236.GA35697@lucky.net> Hi, Andriy N. Gritsenko! Sometime (on Monday, May 26 at 12:41) I've written something... >>> Another example for using of CONF_TYPE_GROUP: >>> >>> (*) constant quantizer [ ] >>> ( ) variable quantizer ---------------------------- >>> minimum quant [ ] maximum quant [ ] >>> ................... >>> --------------------------------------------------- >>> >>> so we have CONF_TYPE_SELECT with two choises: >>> 1) CONF_TYPE_GROUP including 'vqscale' integer. >>> 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options. >>> >>> When we select constant quantizer then second group will be disabled, >>> when we select second group then we cannot change value of 'vqscale'. >>> Config of vf_lavc must have hints for that. Simplest way for it is just >>> have "transparent" CONG_TYPE_GROUP type. Did you understand? >>and how would you define the above situation with your types? >>i can't see how you GROUP helps here. >For example, we assume that name of group is group selection flag. Then >if we define all below we will have all hints to form box above but don't >have any changes for CLI syntax: [.......] I like to write here another version for the same. We'll define that option->desc for CONF_TYPE_GROUP have two special meanings: NULL - this is menu separator line "*" - this is list of special choises (boxes inside box) Then we could: config_t var_vq_group[]={ {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, ......... {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } config_t vq_groups[]={ {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "constant quantizer"}, {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } ..... {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, vq_groups, "*"}, ..... It seems even simpler than previous version and allows even more that two group choises (and still no changes for CLI syntax). :) With best wishes. Andriy. From arpi at thot.banki.hu Mon May 26 15:38:50 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 15:38:50 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526124236.GA35697@lucky.net> Message-ID: <200305261338.h4QDco6u010410@mail.mplayerhq.hu> Hi, > >For example, we assume that name of group is group selection flag. Then > >if we define all below we will have all hints to form box above but don't > >have any changes for CLI syntax: > > [.......] > > I like to write here another version for the same. We'll define that > option->desc for CONF_TYPE_GROUP have two special meanings: > NULL - this is menu separator line > "*" - this is list of special choises (boxes inside box) > > Then we could: > > config_t var_vq_group[]={ > {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, > {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, > ......... > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > config_t vq_groups[]={ > {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "constant quantizer"}, > {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > ..... > {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, vq_groups, "*"}, > ..... > > It seems even simpler than previous version and allows even more that two > group choises (and still no changes for CLI syntax). :) hmm, i don't understand this version. i understood the first version, but it has a big bug: it doesn't store which group was selected by teh user. anyway i agree that we should support this kind of thing (ie. various set of options available depending on the result of a select/flag type option) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Mon May 26 16:33:56 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 26 May 2003 10:33:56 -0400 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526084424.GA54253@lucky.net> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> <20030526084424.GA54253@lucky.net> Message-ID: <20030526143356.GX23552@brightrain.aerifal.cx> On Mon, May 26, 2003 at 11:44:24AM +0300, Andriy N. Gritsenko wrote: > >it's always readable by upper layer (so VFCTRL_GET_PARAMS is useless), but > >we should add VFCTRL_SET_PARAMS (or better name) to notify filter about > >config changes made by UI. i'm not completely sure about this one yet. > >(runtime config change is always a mess...) > > As you said yourself, runtime config change may be a mess and I don't > like to change parameters in running application - only filter may decide > if parameter may be applied or not. So I've proposed to get copy of > config_data_t* and let filter apply it instead of direct changing it, > changes in a copy are always safe. So application will have something > like: > > data_copy=malloc(vf->info->config_size); > vf->control(vf, VFCTRL_GET_PARAMS, data_copy); > .....change parameters..... > vf->control(vf, VFCTRL_SET_PARAMS, data_copy); > free(data_copy); > > Of course, we could > > data_copy=malloc(vf->info->config_size); > memcpy(data_copy, vf->cfg, vf->info->config_size); > .....change parameters..... > vf->control(vf, VFCTRL_SET_PARAMS, data_copy); > free(data_copy); > > but I don't like to trust developers if they will always use a copy but > don't change existing data. You know it yourself, many programmers are > too lazy to know all requirements and that may cause troubles. This is total nonsense since some of vf->cfg may be pointers to other dynamically allocated stuff. With all this confusion about who will allocate, free, and update what, you're bound to create memory leaks. IMO you should just let the program modify vf->cfg directly. If the module needs an untouchable copy of the 'current value' of some param to use when deciding whether a runtime change it allowed, it should make its own copy of the data in vf->priv. Otherwise it should expect the program to call VFCTRL_SET_PARAMS immediately after changing vf->cfg. Rich From andrej at lucky.net Mon May 26 16:25:45 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 17:25:45 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <200305261338.h4QDco6u010410@mail.mplayerhq.hu> References: <20030526124236.GA35697@lucky.net> <200305261338.h4QDco6u010410@mail.mplayerhq.hu> Message-ID: <20030526142545.GA58498@lucky.net> Hi, Arpi! Sometime (on Monday, May 26 at 16:36) I've received something... >> >For example, we assume that name of group is group selection flag. Then >> >if we define all below we will have all hints to form box above but don't >> >have any changes for CLI syntax: >> >> [.......] >> >> I like to write here another version for the same. We'll define that >> option->desc for CONF_TYPE_GROUP have two special meanings: >> NULL - this is menu separator line >> "*" - this is list of special choises (boxes inside box) >> Then we could: >> config_t var_vq_group[]={ >> {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, >> {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, >> ......... >> {NULL, NULL, 0, 0, 0, 0, NULL, NULL} >> } >> config_t vq_groups[]={ >> {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "constant quantizer"}, >> {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, >> {NULL, NULL, 0, 0, 0, 0, NULL, NULL} >> } Variant from first version with 'vqscale' as only member of group: config_t const_vq_group[]={ {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, ""}, {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } config_t var_vq_group[]={ {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, ......... {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } config_t vq_groups[]={ {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, const_vq_group, "constant quantizer"}, {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, {NULL, NULL, 0, 0, 0, 0, NULL, NULL} } ..... {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, vq_groups, "*"}, ..... May be that way it's more clear? >> It seems even simpler than previous version and allows even more that two >> group choises (and still no changes for CLI syntax). :) >hmm, i don't understand this version. >i understood the first version, but it has a big bug: it doesn't store >which group was selected by teh user. Second version containing one more level of CONF_TYPE_GROUP that could have option->p as int* to indicate which subgroup was selected. First version cannot have that and I don't see how first version could have more that two choices. We cannot use CONF_TYPE_SELECT here because that grouping must be transparent for CLI (to preserve syntax). With best wishes. Andriy. From arpi at thot.banki.hu Mon May 26 16:34:10 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 16:34:10 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526143356.GX23552@brightrain.aerifal.cx> Message-ID: <200305261434.h4QEYAFY014824@mail.mplayerhq.hu> Hi, > This is total nonsense since some of vf->cfg may be pointers to other > dynamically allocated stuff. With all this confusion about who will > allocate, free, and update what, you're bound to create memory leaks. > > IMO you should just let the program modify vf->cfg directly. If the > module needs an untouchable copy of the 'current value' of some param > to use when deciding whether a runtime change it allowed, it should > make its own copy of the data in vf->priv. Otherwise it should expect > the program to call VFCTRL_SET_PARAMS immediately after changing > vf->cfg. 100% agree. btw, unless an option is flagged as runtime-changeable, it must not be modified after module initialization, by the caller. also, app may (and should) change values at init and VFCTRL_SET_PARAMS control, when they are not acceptable (for example the crop filter gets x+w>orig_w) so the caller will know the final (used) values. 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 May 26 16:43:18 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 16:43:18 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526142545.GA58498@lucky.net> Message-ID: <200305261443.h4QEhIq6019292@mail.mplayerhq.hu> Hi, > Variant from first version with 'vqscale' as only member of group: > > config_t const_vq_group[]={ > {"vqscale", &vqscale, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, ""}, > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > config_t var_vq_group[]={ > {"vqmin", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "minimun quant"}, > {"vqmax", &vqmin, CONF_TYPE_INT, CONF_RANGE, 1, 31, NULL, "maximum quant"}, > ......... > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > config_t vq_groups[]={ > {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, const_vq_group, "constant quantizer"}, > {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, var_vq_group, "variable quantizer"}, > {NULL, NULL, 0, 0, 0, 0, NULL, NULL} > } > > ..... > {"", NULL, CONF_TYPE_GROUP, 0, 0, 0, vq_groups, "*"}, > ..... > > May be that way it's more clear? i understand but it doesn't look nice. > >> It seems even simpler than previous version and allows even more that two > >> group choises (and still no changes for CLI syntax). :) > > >hmm, i don't understand this version. > > >i understood the first version, but it has a big bug: it doesn't store > >which group was selected by teh user. > > Second version containing one more level of CONF_TYPE_GROUP that > could have option->p as int* to indicate which subgroup was selected. how? where do you store the value to be stored at int* ? serial number of list member? min/max value as in flags? hey this is messy, this is not what we want. btw we could extend the config_select_list_t to include a config_t*, so we could "link" config entries to select-list elements. it looks cleaner. > First version cannot have that and I don't see how first version could > have more that two choices. We cannot use CONF_TYPE_SELECT here because > that grouping must be transparent for CLI (to preserve syntax). CLI also should follow "grouping", ie it shouldn't allow(*) vqmin/vqmax settings when constant qscale mode is selected... (*): maybe we should think 'like' insteda of 'allow', it it could warn user of wrong syntax but don't fail... or even better: this 'allow-some-errors policy' should be optional, something like gcc's -pedantic switch. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Mon May 26 16:48:53 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Mon, 26 May 2003 17:48:53 +0300 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526143356.GX23552@brightrain.aerifal.cx> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> <20030526084424.GA54253@lucky.net> <20030526143356.GX23552@brightrain.aerifal.cx> Message-ID: <20030526144853.GC58498@lucky.net> Hi, D Richard Felker III! Sometime (on Monday, May 26 at 17:26) I've received something... >On Mon, May 26, 2003 at 11:44:24AM +0300, Andriy N. Gritsenko wrote: >> >it's always readable by upper layer (so VFCTRL_GET_PARAMS is useless), but >> >we should add VFCTRL_SET_PARAMS (or better name) to notify filter about >> >config changes made by UI. i'm not completely sure about this one yet. >> >(runtime config change is always a mess...) >> >> As you said yourself, runtime config change may be a mess and I don't >> like to change parameters in running application - only filter may decide >> if parameter may be applied or not. So I've proposed to get copy of >> config_data_t* and let filter apply it instead of direct changing it, >> changes in a copy are always safe. So application will have something >> like: >> >> data_copy=malloc(vf->info->config_size); >> vf->control(vf, VFCTRL_GET_PARAMS, data_copy); >> .....change parameters..... >> vf->control(vf, VFCTRL_SET_PARAMS, data_copy); >> free(data_copy); >> >> Of course, we could >> >> data_copy=malloc(vf->info->config_size); >> memcpy(data_copy, vf->cfg, vf->info->config_size); >> .....change parameters..... >> vf->control(vf, VFCTRL_SET_PARAMS, data_copy); >> free(data_copy); >> >> but I don't like to trust developers if they will always use a copy but >> don't change existing data. You know it yourself, many programmers are >> too lazy to know all requirements and that may cause troubles. >This is total nonsense since some of vf->cfg may be pointers to other >dynamically allocated stuff. With all this confusion about who will >allocate, free, and update what, you're bound to create memory leaks. Where did you find memory leak in lines above? Caller (upper level of application) allocate memory, use it as temporal and then free it. No other level (core or other application layer) doesn't know what is that memory. No leaks at all! On other hand, if you will change vf->cfg directly in multithreaded application, you will get a memory leak - you don't know if some of parameters there are static or allocated and don't know if it will be reallocated or freed while you changing it. So don't touch that vf->cfg directly if you don't want memory leaks! :) About dinamically allocated data as string parameters - when you'll call VFCTRL_GET_PARAMS control you'll get only copy of parameters then only module itself may allocate and free own copies. Just let's have all documented well. >IMO you should just let the program modify vf->cfg directly. If the >module needs an untouchable copy of the 'current value' of some param >to use when deciding whether a runtime change it allowed, it should >make its own copy of the data in vf->priv. Otherwise it should expect >the program to call VFCTRL_SET_PARAMS immediately after changing >vf->cfg. How will you know if filter allowed set some parameter only on filter opening? If your application will change some parameter (for example, size of frame) which is critical for the filter then would you guarantee that _any_ filter will work correctly (think, please, about multitasking or multithreading application) until you say VFCTRL_SET_PARAMS for it? I would to say you may have a big mess if you will change some parameter directly. BTW, on running application you may have that vf->cfg already dinamically allocated and changed right when you trying to modify it. I'm against it very much and I've against have that vf->cfg visible for higher level of application at all - it's _private_ area of variables. With best wishes. Andriy. From lumag at qnc.ru Mon May 26 19:35:59 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 26 May 2003 21:35:59 +0400 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <200305260322.04791.FabianFranz@gmx.de> References: <200305260053.h4Q0r3kM030764@mail.mplayerhq.hu> <200305260322.04791.FabianFranz@gmx.de> Message-ID: <1053970484.30508.167.camel@orangutan.home.ru> Hello! ?? ?? 26.05.2003, ?? 05:22, Fabian Franz ??????????: [skipped] > > > > i'm not sure but maybe even dvd navigation should be handled here? > > (as it's really a stream and not a demuxer, but dunno) > > hm, its both a stream and a demuxer ... perhaps it should be really BOTH ... This was discussed (if it can be called that) in other thread, but: IMHO how it's organized in hardware player: 1) DVD-ROM provides raw DVD stream (mostly it's MPEG stream, and sometimes IFO files with commands for VM). 2) VM (or even special CPU) 'navigates' - gets user events, processes them, executes internal commands (from IFO files). At the end, if produces MPEG stream, which goes to demuxer (or something like that) and tells demuxer, which streams (Audio/SPU) to use. 3) Demuxer - demuxes, and gives audio, video and SPU streams to hardware decoders/etc. So navigation really lays between stream and demuxer. The main question is, where it will be easier to implement. 1. In stream layer. Then there must be API to pass events to/from stream layer. Moreover, (when using cache2.c) to/from caching process! Also, there is another problem. The main part of cache, is precache(IIUC), which means, that navigation will be _ALWAYS_ ahead of playing by some seconds. 2. In separate layer between stream layer and demuxer. Why we must add extra layer specifically for _DVD_ navigation VM? (I mean, that VM's for other navigations (NUT,MOV,etc) don't belong to such place, do they?) 3. In demuxer layer. Suppose, it's a best choice: Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using metalanguage): { exec_one_vm_instruction(); if (some_conditions) return EVENT_HAPPENED; if(next_is_nav_packet) { process_it_and_store_pci_and_dsi(&pci, &dsi); return NAV_PACKET; } return BLOCK_OK; } I really suppose, that this fits to the demuxer well (moreover, if there will be special demuxer for dvdnav, all if(dvdnav) can be ommited): { if (dvanav) { exec_one_vm)instruction(); if (some_conditions) process_event(); /* * This means change outputting Audio/SPU stream, * set still_frame flag, etc. */ if(next_is_nav_packet) { process_it_and_store_pci_and_dsi(&pci, &dsi); return MUST_REREAD; /*Or we can restart this function from beginning*/ } } demux_block_as_usual(); } [skipped] -- With best wishes Dmitry Baryshkov From arpi at thot.banki.hu Mon May 26 20:04:39 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 20:04:39 +0200 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <1053970484.30508.167.camel@orangutan.home.ru> Message-ID: <200305261804.h4QI4dLs008972@mail.mplayerhq.hu> Hi, > > hm, its both a stream and a demuxer ... perhaps it should be really BOTH ... > This was discussed (if it can be called that) in other thread, but: > IMHO how it's organized in hardware player: > 1) DVD-ROM provides raw DVD stream (mostly it's MPEG stream, and > sometimes IFO files with commands for VM). > 2) VM (or even special CPU) 'navigates' - gets user events, processes > them, executes internal commands (from IFO files). At the end, > if produces MPEG stream, which goes to demuxer (or something > like that) and tells demuxer, which streams (Audio/SPU) to use. > 3) Demuxer - demuxes, and gives audio, video and SPU streams > to hardware decoders/etc. there is a big difference, in hw players demux/decode work as push, not as pull. ie the VM push teh stream into the decoder hw and it will read and decoder the stream based on hw clock. the main problem is here. mplayer has opposite design. here the whole thing is pushed by the ao/vo end. so the control is done at ao/vo insteda of teh other end, demuxer. it was easier in g1, there demuxer was directly called by player, at least for video (audio was pulled even in g1). so actually it doesn't matter if you put navigation into stream or demux, it will not be easier. > So navigation really lays between stream and demuxer. yes. > The main question is, where it will be easier to implement. > 1. In stream layer. Then there must be API to pass events to/from > stream layer. Moreover, (when using cache2.c) to/from caching > process! Also, there is another problem. The main part of > cache, is precache(IIUC), which means, that navigation will > be _ALWAYS_ ahead of playing by some seconds. ok, we have to decide something: do you plan to use libdvdnav as-is (using its API), or modify/rewrite/restructure it to fit mplayer's structure/layers? i'm asking it because dvdnav includes the dvd reading code. so if we use it as-is, then we cannot use my cache2.c, for sure. (cache's delay in navigation is not acceptable, as it locks on still frames) > 2. In separate layer between stream layer and demuxer. > Why we must add extra layer specifically for _DVD_ navigation VM? > (I mean, that VM's for other navigations (NUT,MOV,etc) don't > belong to such place, do they?) > 3. In demuxer layer. Suppose, it's a best choice: > Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using > metalanguage): if you look at what libdvdnav does, it's trivial that it's a stream level element. it reads stream packets, and translates special (NAVI) packets to event data, nothing more. all the demuxing (including stream separation, format detection, timing) is done by demux_mpeg, not by libdvdnav. if you put it into demuxer layer, where do you want to implement mpeg ps stream demuxing? > > { > exec_one_vm_instruction(); > if (some_conditions) > return EVENT_HAPPENED; > if(next_is_nav_packet) > { > process_it_and_store_pci_and_dsi(&pci, &dsi); > return NAV_PACKET; > } > return BLOCK_OK; > } > > I really suppose, that this fits to the demuxer well (moreover, if > there will be special demuxer for dvdnav, all if(dvdnav) can be > ommited): but how in the hell do you plan to pass to/from navigation events between libdvdnav and UI ? maybe the new libdvdread's approach is better for mplayer g2, it uses callbacks to communicate with UI. btw do what you want, i'm interested in the actual implementation details, or patches :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 20:04:40 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 20:04:40 +0200 Subject: [MPlayer-G2-dev] [RFC] first draft of stream/demux-metadata support (+playlist-infos) Message-ID: <200305262004.40111.FabianFranz@gmx.de> Hi, I slept a while and think I found the different types, that need to be supported (supposed playlist-handlers will be complete in demuxer-level too) To-be-supported Examples: QT-MOVIE: (or other playlist) Metadata: Title: Foo's adventure Author: Bar Bar cue Date: 2005 References: (Ext-)Reference: url: foo-high-res.mov bitrate: 16000 quality: 9 -- url: foo-medi-res.mov -- url: foo-low-res1.mov -- url: foo-low-res2.mov (Ext-)Reference: url: foo-title2.mov DVD: Metadata: Title: Foo on DVD Author: Bar Bar Cue Date: 2005 DVD-META: Titles: 16 Chapters: 25 Subtitle-Languages: de en uk fr Audio-Languages: de en References: (Int-)Reference: name: Main-Movie (title1) offset: 1656 (Int-)Reference: name: Chapter 1 offset: 1656 (Int-)Reference: name: Chapter 2 offset: 1856 ... (Int-)Reference: name: title2 offset: 1987 CD: Metadata: Title: Bar is singing Author: Foo's hidden microphone Date: 2008 CD-META: nb_tracks = 16 length = 00:57:68 References: (Int-)Reference: name: Foo Title 1 offset: 108 (Int-)Reference: name: Foo Title 2 offset: 206 Proposed structures: -> Metadata as list. (as already implemented) -META as an struct specific to media. Reference: (somewaht similar to metadata, which should not be specific to demuxer-level) struct ref_list_s; typedef struct ref_entry_s { char* name; int offset; Url_t *URL; int bitrate; // perhaps present in Url_t ? int quality; ... int type; // external / internal reference ref_list_t* alternatives; ref_list_t* sublist; } ref_entry_t; typedef struct ref_list_s { int num_refs; // number of available entries int max_refs; // number of allocated entries (if(num_metas>=max_metas)realloc()) ref_entry_t* refs; } ref_list_t; So CD is a flat structure, which do not use alternatives or sublist. MOV can make use of alternatives to allow player an choice. DVD does make heavy use of sublist, as disk/titles/chapters have a somewaht nested strucutre. One goal in later implementation should be simplicity. num=add_ext_reference(reflist,name, url) // returns the index ... add_ext_reference_alternative(reflist,num, name, url, bitrate, quality, ...) add_ext_reference_alternative(reflist,num, name2, url2, bitrate2, quality2, ...) num=add_reference(reflist,dvdname, offset) // returns the index ... add_reference_sublist(reflist,num, chaptername, offset) add_reference_sublist(reflist,num, chaptername2, offset2) Later CONTROL-program can get the data via: for (i=0;iname); } Convert it into own playlist/playtree-format and so on... The whole thing shall be in stream_t stream* as meta_t *meta { metadata_list_t data; void* specific_data; // or struct some_specific_s (like stream_priv_s) ref_list_t list; } or similar. cu Fabian From dalias at aerifal.cx Mon May 26 20:28:16 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Mon, 26 May 2003 14:28:16 -0400 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526144853.GC58498@lucky.net> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> <20030526084424.GA54253@lucky.net> <20030526143356.GX23552@brightrain.aerifal.cx> <20030526144853.GC58498@lucky.net> Message-ID: <20030526182816.GA29073@brightrain.aerifal.cx> On Mon, May 26, 2003 at 05:48:53PM +0300, Andriy N. Gritsenko wrote: > >This is total nonsense since some of vf->cfg may be pointers to other > >dynamically allocated stuff. With all this confusion about who will > >allocate, free, and update what, you're bound to create memory leaks. > > Where did you find memory leak in lines above? Caller (upper level of > application) allocate memory, use it as temporal and then free it. No > other level (core or other application layer) doesn't know what is that > memory. No leaks at all! vf->cfg may be full of string pointers. > On other hand, if you will change vf->cfg directly in multithreaded > application, you will get a memory leak - you don't know if some of > parameters there are static or allocated and don't know if it will be > reallocated or freed while you changing it. So don't touch that vf->cfg > directly if you don't want memory leaks! :) > About dinamically allocated data as string parameters - when you'll > call VFCTRL_GET_PARAMS control you'll get only copy of parameters then > only module itself may allocate and free own copies. Just let's have all > documented well. > > >IMO you should just let the program modify vf->cfg directly. If the > >module needs an untouchable copy of the 'current value' of some param > >to use when deciding whether a runtime change it allowed, it should > >make its own copy of the data in vf->priv. Otherwise it should expect > >the program to call VFCTRL_SET_PARAMS immediately after changing > >vf->cfg. > > How will you know if filter allowed set some parameter only on filter > opening? If your application will change some parameter (for example, > size of frame) which is critical for the filter then would you guarantee > that _any_ filter will work correctly (think, please, about multitasking > or multithreading application) until you say VFCTRL_SET_PARAMS for it? I No, it's nonsense to allow setting filter options in a separate thread. MPlayer will not be polluted with such thread/locking/etc. crap. It's even a problem with your design unless the filters do some sort of locking during VFCTRL_SET_PARAMS, and filters MUST NOT have to be thread-aware!! If the calling program wants to do such idiocy, it should have to make its thread exclusive before setting vf->cfg and calling VFCTRL_SET_PARAMS. > would to say you may have a big mess if you will change some parameter > directly. BTW, on running application you may have that vf->cfg already > dinamically allocated and changed right when you trying to modify it. I'm > against it very much and I've against have that vf->cfg visible for > higher level of application at all - it's _private_ area of variables. No. vf->priv is private. vf->cfg is totally public. This is clean C code, not some object-oriented encapsulated bullshit with data-hiding. Rich From arpi at thot.banki.hu Mon May 26 20:23:55 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 20:23:55 +0200 Subject: [MPlayer-G2-dev] [RFC] first draft of stream/demux-metadata support (+playlist-infos) In-Reply-To: <200305262004.40111.FabianFranz@gmx.de> Message-ID: <200305261823.h4QINtsn018140@mail.mplayerhq.hu> Hi, > I slept a while and think I found the different types, that need to be > supported (supposed playlist-handlers will be complete in demuxer-level too) > > To-be-supported Examples: > > QT-MOVIE: (or other playlist) > > Metadata: > > Title: Foo's adventure > Author: Bar Bar cue > Date: 2005 isn't title/etc per-track? (allowing multiple titles in single file) > References: > (Ext-)Reference: > url: foo-high-res.mov > bitrate: 16000 > quality: 9 > -- > url: foo-medi-res.mov > -- > url: foo-low-res1.mov > -- > url: foo-low-res2.mov > (Ext-)Reference: > url: foo-title2.mov hmm, does such grouping exists in movs? > DVD: > > Metadata: > > Title: Foo on DVD > Author: Bar Bar Cue > Date: 2005 > > DVD-META: > > Titles: 16 > Chapters: 25 > Subtitle-Languages: de en uk fr > Audio-Languages: de en no no no it's not so simple :( the number of titles is global to a disc. then each titles has number of chapters, number of angles, sub and audio langue list. most dvd disc contain few titles, one for the movie (many chapters, audio languages etc), one for the trailers (few chapters, one chapter is one movie's trailer, usually single audio and a few subtitles), one for werkfilms (how we did that effect in matrix...) and so on. > References: > (Int-)Reference: > name: Main-Movie (title1) > offset: 1656 > (Int-)Reference: > name: Chapter 1 > offset: 1656 > (Int-)Reference: > name: Chapter 2 > offset: 1856 > ... > (Int-)Reference: > name: title2 > offset: 1987 hmm what's that offset? btw you should include length (play time) for cdda and dvd for titles and chapters. > CD: > > Metadata: > > Title: Bar is singing > Author: Foo's hidden microphone > Date: 2008 > > CD-META: > > nb_tracks = 16 > length = 00:57:68 > > References: > (Int-)Reference: > name: Foo Title 1 > offset: 108 > (Int-)Reference: > name: Foo Title 2 > offset: 206 > > Proposed structures: i guess we should move metadata stuff to the stream layer. as demuxer already depend son stream layer, and includes stream.h, it could use the same. > -> Metadata as list. (as already implemented) > -META as an struct specific to media. > > Reference: (somewaht similar to metadata, which should not be specific to > demuxer-level) > > struct ref_list_s; > > typedef struct ref_entry_s > { > char* name; > int offset; > Url_t *URL; > int bitrate; // perhaps present in Url_t ? > int quality; > ... > int type; // external / internal reference > ref_list_t* alternatives; > ref_list_t* sublist; > } ref_entry_t; good! i like the idea of reusing stream layer's URL_t to keep urls parsed instead of as plain strings. > typedef struct ref_list_s { > int num_refs; // number of available entries > int max_refs; // number of allocated entries > (if(num_metas>=max_metas)realloc()) > ref_entry_t* refs; > } ref_list_t; > > > So CD is a flat structure, which do not use alternatives or sublist. > MOV can make use of alternatives to allow player an choice. also does .asx and .rmf... we should also handle playlists at demuxer level, so don't forget about them! > DVD does make heavy use of sublist, as disk/titles/chapters have a somewaht > nested strucutre. yes > One goal in later implementation should be simplicity. yep. but we cannot (and shouldn't) avoid the hierarchical (tree) structure of the struct. btw, shouldn't we put metadata and references into the same struct? (as there is metadata for references) > num=add_ext_reference(reflist,name, url) // returns the index ... > add_ext_reference_alternative(reflist,num, name, url, bitrate, quality, ...) > add_ext_reference_alternative(reflist,num, name2, url2, bitrate2, quality2, > ...) > > num=add_reference(reflist,dvdname, offset) // returns the index ... > add_reference_sublist(reflist,num, chaptername, offset) > add_reference_sublist(reflist,num, chaptername2, offset2) > > Later CONTROL-program can get the data via: > > for (i=0;i { > printf("Name: %s\n",reflist.refs[i]->name); > } > > Convert it into own playlist/playtree-format and so on... > > The whole thing shall be in stream_t stream* as > > meta_t *meta > { > metadata_list_t data; > void* specific_data; // or struct some_specific_s (like stream_priv_s) > ref_list_t list; > } hmm 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 May 26 20:31:53 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 20:31:53 +0200 Subject: [MPlayer-G2-dev] Re: About final cfg.h (config layer 0 discussion) In-Reply-To: <20030526182816.GA29073@brightrain.aerifal.cx> Message-ID: <200305261831.h4QIVruT022500@mail.mplayerhq.hu> Hi, > On Mon, May 26, 2003 at 05:48:53PM +0300, Andriy N. Gritsenko wrote: > > >This is total nonsense since some of vf->cfg may be pointers to other > > >dynamically allocated stuff. With all this confusion about who will > > >allocate, free, and update what, you're bound to create memory leaks. > > > > Where did you find memory leak in lines above? Caller (upper level of > > application) allocate memory, use it as temporal and then free it. No > > other level (core or other application layer) doesn't know what is that > > memory. No leaks at all! > > vf->cfg may be full of string pointers. yes btw if you wnat to copy vf->cfg, there is a func in layer-0 for it: new_cfg=mpconfig_get_cfg(vf->info,vf->cfg); but it's not the way we want to go. > > On other hand, if you will change vf->cfg directly in multithreaded > > application, you will get a memory leak - you don't know if some of > > parameters there are static or allocated and don't know if it will be > > reallocated or freed while you changing it. So don't touch that vf->cfg > > directly if you don't want memory leaks! :) > > About dinamically allocated data as string parameters - when you'll > > call VFCTRL_GET_PARAMS control you'll get only copy of parameters then > > only module itself may allocate and free own copies. Just let's have all > > documented well. > > > > >IMO you should just let the program modify vf->cfg directly. If the > > >module needs an untouchable copy of the 'current value' of some param > > >to use when deciding whether a runtime change it allowed, it should > > >make its own copy of the data in vf->priv. Otherwise it should expect > > >the program to call VFCTRL_SET_PARAMS immediately after changing > > >vf->cfg. > > > > How will you know if filter allowed set some parameter only on filter > > opening? If your application will change some parameter (for example, > > size of frame) which is critical for the filter then would you guarantee > > that _any_ filter will work correctly (think, please, about multitasking > > or multithreading application) until you say VFCTRL_SET_PARAMS for it? I > > No, it's nonsense to allow setting filter options in a separate > thread. MPlayer will not be polluted with such thread/locking/etc. i want to make g2 libs thread-safe as far as possible (but where it means big mess/hacks/ugly code then it is ignored :)) > crap. It's even a problem with your design unless the filters do some > sort of locking during VFCTRL_SET_PARAMS, and filters MUST NOT have to > be thread-aware!! If the calling program wants to do such idiocy, it > should have to make its thread exclusive before setting vf->cfg and > calling VFCTRL_SET_PARAMS. actually filters should keep their local copies of the runtime changeable parameters if they want to read it after config() is done. (most filter params are used only to set up tables or internal data, it's not used any more after config()). they should read/write those vars only in open(), config() and VFCTRL_SET_PARAMS. > > would to say you may have a big mess if you will change some parameter > > directly. BTW, on running application you may have that vf->cfg already > > dinamically allocated and changed right when you trying to modify it. I'm > > against it very much and I've against have that vf->cfg visible for > > higher level of application at all - it's _private_ area of variables. > > No. vf->priv is private. vf->cfg is totally public. This is clean C yes > code, not some object-oriented encapsulated bullshit with data-hiding. also note that cfg is actually filled by the GUI code directly, before passing to the filter open. so it MUST access/see it. (in case of CLI, there is strings=>cfg parser in layer 1) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From pnis at coder.hu Mon May 26 21:13:47 2003 From: pnis at coder.hu (Balatoni Denes) Date: Mon, 26 May 2003 21:13:47 +0200 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <200305261804.h4QI4dLs008972@mail.mplayerhq.hu> References: <200305261804.h4QI4dLs008972@mail.mplayerhq.hu> Message-ID: <200305262113.47035.pnis@coder.hu> Hi! > but how in the hell do you plan to pass to/from navigation events between > libdvdnav and UI ? btw all modules should have the possibility to communicate with each other and ui (eg af module that reads out subtitles loud; vf that let's the user control whatever of the movie with the mouse)- so libdvdnav module with ui too. how, when, where I don't know I just mention it too see whether you agree! bye Denes > > A'rpi / Astral & ESP-team From lumag at qnc.ru Mon May 26 21:51:07 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 26 May 2003 23:51:07 +0400 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <200305261804.h4QI4dLs008972@mail.mplayerhq.hu> References: <200305261804.h4QI4dLs008972@mail.mplayerhq.hu> Message-ID: <1053978592.818.88.camel@orangutan.home.ru> Hello! Thank you for response. ?? ?? 26.05.2003, ?? 22:04, Arpi ??????????: > Hi, > > > > hm, its both a stream and a demuxer ... perhaps it should be really BOTH ... > > This was discussed (if it can be called that) in other thread, but: > > IMHO how it's organized in hardware player: > > 1) DVD-ROM provides raw DVD stream (mostly it's MPEG stream, and > > sometimes IFO files with commands for VM). > > 2) VM (or even special CPU) 'navigates' - gets user events, processes > > them, executes internal commands (from IFO files). At the end, > > if produces MPEG stream, which goes to demuxer (or something > > like that) and tells demuxer, which streams (Audio/SPU) to use. > > 3) Demuxer - demuxes, and gives audio, video and SPU streams > > to hardware decoders/etc. > > there is a big difference, in hw players demux/decode work as push, not as > pull. ie the VM push teh stream into the decoder hw and it will read and > decoder the stream based on hw clock. > > the main problem is here. mplayer has opposite design. > here the whole thing is pushed by the ao/vo end. so the control is done > at ao/vo insteda of teh other end, demuxer. > it was easier in g1, there demuxer was directly called by player, at least > for video (audio was pulled even in g1). Well...This really is a problem. Dunno, but suppose, that this situation can be possible: during calls of audio chain, VM jumps to (e.g.) STILL menu, where is no audio stream. Suppose, that in this situation, EOF will be returned for audio stream, and audio will be switched off. Then, user selects next chapter, and the audio playing must be restored! Moreover, things are even worse. Demuxer functions won't be called during STILL_FRAME's, unless they are supported directly in vf_vd.c . It's the only place, where we can store still_frame, and then return it via get_pending_image, when we are in still_frame. Only in such way, we can keep calling demuxer, when G2 is in still_frame handler. > so actually it doesn't matter if you put navigation into stream or demux, it > will not be easier. I don't say that placing VM into demux will be too easy. There are no easy things on the Earth. > > > So navigation really lays between stream and demuxer. > > yes. > > > The main question is, where it will be easier to implement. > > 1. In stream layer. Then there must be API to pass events to/from > > stream layer. Moreover, (when using cache2.c) to/from caching > > process! Also, there is another problem. The main part of > > cache, is precache(IIUC), which means, that navigation will > > be _ALWAYS_ ahead of playing by some seconds. > > ok, we have to decide something: do you plan to use libdvdnav as-is > (using its API), or modify/rewrite/restructure it to fit mplayer's > structure/layers? No. As I wrote in first letter, I will try to use VM-emulation and most types of events-from-VM(such as STILL_FRAME, HOP, SPU_CHANGE, etc.). > > i'm asking it because dvdnav includes the dvd reading code. > so if we use it as-is, then we cannot use my cache2.c, for sure. > (cache's delay in navigation is not acceptable, as it locks on still frames) You are reading from my mind :) > > > 2. In separate layer between stream layer and demuxer. > > Why we must add extra layer specifically for _DVD_ navigation VM? > > (I mean, that VM's for other navigations (NUT,MOV,etc) don't > > belong to such place, do they?) > > 3. In demuxer layer. Suppose, it's a best choice: > > Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using > > metalanguage): > > if you look at what libdvdnav does, it's trivial that it's a stream level > element. it reads stream packets, and translates special (NAVI) packets > to event data, nothing more. all the demuxing (including stream separation, > format detection, timing) is done by demux_mpeg, not by libdvdnav. Maybe you meant that, but IIUC, NAVI packets(or even NAVI stream from MPEG stream) are/is splitted into PCI[Presentation Control Information] and DSI[data search information] structures. Events (or better VM-instructions) comes from IFO files. > if you put it into demuxer layer, where do you want to implement mpeg ps > stream demuxing? In demuxer :) Well...IIUC, current stream API on the side of main process either are calls to cache2 (If it's enabled), or calls to stream_.c, but then cache2 is disabled. So, having DVDnav in stream layer will either require big changes to post-cache read functions (if we decide to put nav after cache2, but in stream layer), or hard-portable changes to cache2 to pass msgqueues between two processes (I don't think that M$Win have SYSV IPC or POSIX 1.b msg queues.). > > > > > > { > > exec_one_vm_instruction(); > > if (some_conditions) > > return EVENT_HAPPENED; > > if(next_is_nav_packet) > > { > > process_it_and_store_pci_and_dsi(&pci, &dsi); > > return NAV_PACKET; > > } > > return BLOCK_OK; > > } > > > > I really suppose, that this fits to the demuxer well (moreover, if > > there will be special demuxer for dvdnav, all if(dvdnav) can be > > ommited): > > but how in the hell do you plan to pass to/from navigation events between > libdvdnav and UI ? That is one of questions in my first mail (of course if you mean button-press events, etc.). You said, that it must be done through libinput (or maybe I din't understand you). > > maybe the new libdvdread's approach is better for mplayer g2, it uses > callbacks to communicate with UI. You mean libdvdplay? I looked in two-days-old CVS of dvdread, and I don't see any callbacks. > > btw do what you want, i'm interested in the actual implementation details, > or patches :) Me too:) I mean SPU-stream, event passing, etc. More concrete: In June I'll have exams in university, so don't expect too much. (The goal of theese letters was to discuss what is necessary in G2 to ease support of navigation (I don't mean only DVDnav). I suppose, that it's better to have such code from begining, than having to rewrite already-working code). But, I hope, that in July I'll have a lot of free time to work for G2. > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry Baryshkov From arpi at thot.banki.hu Mon May 26 22:26:15 2003 From: arpi at thot.banki.hu (Arpi) Date: Mon, 26 May 2003 22:26:15 +0200 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <1053978592.818.88.camel@orangutan.home.ru> Message-ID: <200305262026.h4QKQF4j029490@mail.mplayerhq.hu> Hi, > > the main problem is here. mplayer has opposite design. > > here the whole thing is pushed by the ao/vo end. so the control is done > > at ao/vo insteda of teh other end, demuxer. > > it was easier in g1, there demuxer was directly called by player, at least > > for video (audio was pulled even in g1). > Well...This really is a problem. Dunno, but suppose, that this situation > can be possible: during calls of audio chain, VM jumps to (e.g.) STILL > menu, where is no audio stream. Suppose, that in this situation, EOF > will be returned for audio stream, and audio will be switched off. yes > Then, user selects next chapter, and the audio playing must be restored! it's not a problem, the audio layer will be reinited then. UI will call the seek function for chapter change, it will reset EOF flag on demuxer streams and will reset audio and video decoder too. > Moreover, things are even worse. Demuxer functions won't be called > during STILL_FRAME's, unless they are supported directly in vf_vd.c . yes it's a serious problem, i didn't even think of yet. > It's the only place, where we can store still_frame, and then return it > via get_pending_image, when we are in still_frame. Only in such way, we > can keep calling demuxer, when G2 is in still_frame handler. no, we shouldn't put such mess into vf_vd. imho when we find a still frame, then demuxer should set video stream's EOF flag. event control in 'menu' mode (be it still frame or looped video) should be done via demuxer/stream control() function. (actually it should always be done via control()) > > so actually it doesn't matter if you put navigation into stream or demux, it > > will not be easier. > I don't say that placing VM into demux will be too easy. > There are no easy things on the Earth. yes > > > So navigation really lays between stream and demuxer. > > > > yes. > > > > > The main question is, where it will be easier to implement. > > > 1. In stream layer. Then there must be API to pass events to/from > > > stream layer. Moreover, (when using cache2.c) to/from caching > > > process! Also, there is another problem. The main part of > > > cache, is precache(IIUC), which means, that navigation will > > > be _ALWAYS_ ahead of playing by some seconds. > > > > ok, we have to decide something: do you plan to use libdvdnav as-is > > (using its API), or modify/rewrite/restructure it to fit mplayer's > > structure/layers? > No. No for which one? :) > As I wrote in first letter, I will try to use VM-emulation > and most types of events-from-VM(such as STILL_FRAME, HOP, > SPU_CHANGE, etc.). > > > > i'm asking it because dvdnav includes the dvd reading code. > > so if we use it as-is, then we cannot use my cache2.c, for sure. > > (cache's delay in navigation is not acceptable, as it locks on still frames) > You are reading from my mind :) > > > > > 2. In separate layer between stream layer and demuxer. > > > Why we must add extra layer specifically for _DVD_ navigation VM? > > > (I mean, that VM's for other navigations (NUT,MOV,etc) don't > > > belong to such place, do they?) > > > 3. In demuxer layer. Suppose, it's a best choice: > > > Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using > > > metalanguage): > > > > if you look at what libdvdnav does, it's trivial that it's a stream level > > element. it reads stream packets, and translates special (NAVI) packets > > to event data, nothing more. all the demuxing (including stream separation, > > format detection, timing) is done by demux_mpeg, not by libdvdnav. > Maybe you meant that, but IIUC, NAVI packets(or even NAVI > stream from MPEG stream) are/is splitted into PCI[Presentation > Control Information] and DSI[data search information] > structures. Events (or better VM-instructions) comes from IFO > files. i'm not familiar with dvd details, just know about NAVI, as i had to mess with that while implementing code of stream_dvd.c > > if you put it into demuxer layer, where do you want to implement mpeg ps > > stream demuxing? > In demuxer :) > Well...IIUC, current stream API on the side of main process > either are calls to cache2 (If it's enabled), or calls to > stream_.c, but then cache2 is disabled. > So, having DVDnav in stream layer will either require big > changes to post-cache read functions (if we decide to put nav > after cache2, but in stream layer), or hard-portable changes hmm, true. > to cache2 to pass msgqueues between two processes (I don't > think that M$Win have SYSV IPC or POSIX 1.b msg queues.). :) > > > { > > > exec_one_vm_instruction(); > > > if (some_conditions) > > > return EVENT_HAPPENED; > > > if(next_is_nav_packet) > > > { > > > process_it_and_store_pci_and_dsi(&pci, &dsi); > > > return NAV_PACKET; > > > } > > > return BLOCK_OK; > > > } > > > > > > I really suppose, that this fits to the demuxer well (moreover, if > > > there will be special demuxer for dvdnav, all if(dvdnav) can be > > > ommited): > > > > but how in the hell do you plan to pass to/from navigation events between > > libdvdnav and UI ? > That is one of questions in my first mail (of course if you > mean button-press events, etc.). You said, that it must be > done through libinput (or maybe I din't understand you). libinput is at the other end of the pipe. it receives keyboard/mouse/lirc/etc events (including mouse emulation if wanted) from all input devices, including libvo2 drivers, and translates to command code + parameters format based on input.conf. my current question is about the other end of the pipe: how do you plan to pass these events into the demuxers, and how do you plan to receive nav events (like still image, switch stream, whatever) from demuxer? > > maybe the new libdvdread's approach is better for mplayer g2, it uses > > callbacks to communicate with UI. > You mean libdvdplay? yes. > I looked in two-days-old CVS of dvdread, > and I don't see any callbacks. i meant libdvdplay, just mixed them, as dvdplay was made by dvdread authors and is better layered over dvdread. > > btw do what you want, i'm interested in the actual implementation details, > > or patches :) > Me too:) I mean SPU-stream, event passing, etc. :) > More concrete: In June I'll have exams in university, so don't > expect too much. (The goal of theese letters was to discuss > what is necessary in G2 to ease support of navigation (I don't > mean only DVDnav). I suppose, that it's better to have such > code from begining, than having to rewrite already-working yes btw while talking about the dvdnav issues every time, i'm more and more close to the conclusion: it is much better and easier to implement separated from a 'normal' movie player. it's very different philosophy. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From FabianFranz at gmx.de Mon May 26 22:40:09 2003 From: FabianFranz at gmx.de (Fabian Franz) Date: Mon, 26 May 2003 22:40:09 +0200 Subject: [MPlayer-G2-dev] [RFC] first draft of stream/demux-metadata support (+playlist-infos) In-Reply-To: <200305261823.h4QINtsn018140@mail.mplayerhq.hu> References: <200305261823.h4QINtsn018140@mail.mplayerhq.hu> Message-ID: <200305262240.09477.FabianFranz@gmx.de> Am Montag, 26. Mai 2003 20:23 schrieb Arpi: > Hi, > > > I slept a while and think I found the different types, that need to be > > supported (supposed playlist-handlers will be complete in demuxer-level > > too) > > > > To-be-supported Examples: > > > > QT-MOVIE: (or other playlist) > > > > Metadata: > > > > Title: Foo's adventure > > Author: Bar Bar cue > > Date: 2005 > > isn't title/etc per-track? > (allowing multiple titles in single file) yeah, but sometimes file has global title (i.e. album) > > > References: > > (Ext-)Reference: > > url: foo-high-res.mov > > bitrate: 16000 > > quality: 9 > > -- > > url: foo-medi-res.mov > > -- > > url: foo-low-res1.mov > > -- > > url: foo-low-res2.mov > > (Ext-)Reference: > > url: foo-title2.mov > > hmm, does such grouping exists in movs? yes, in mov-reference-files those are (always) alternative references, but that could be also in playlists or similar, where there are concurrent sources. > > > DVD: > > > > Metadata: > > > > Title: Foo on DVD > > Author: Bar Bar Cue > > Date: 2005 > > > > DVD-META: > > > > Titles: 16 > > Chapters: 25 > > Subtitle-Languages: de en uk fr > > Audio-Languages: de en > > no no no > it's not so simple :( :( > the number of titles is global to a disc. > then each titles has number of chapters, number of angles, sub and audio > langue list. > most dvd disc contain few titles, one for the movie (many chapters, audio > languages etc), one for the trailers (few chapters, one chapter is one > movie's trailer, usually single audio and a few subtitles), one for > werkfilms (how we did that effect in matrix...) and so on. hm ... > > > References: > > (Int-)Reference: > > name: Main-Movie (title1) > > offset: 1656 > > (Int-)Reference: > > name: Chapter 1 > > offset: 1656 > > (Int-)Reference: > > name: Chapter 2 > > offset: 1856 > > ... > > (Int-)Reference: > > name: title2 > > offset: 1987 > > hmm > what's that offset? pos in stream-layer ... as the control-unit needs to "say" to stream-layer go to "chapter 5" instead it says go to: offset/pos 1656 > > btw you should include length (play time) for cdda and dvd for titles and > chapters. hm, yeah. > > > CD: > > > > Metadata: > > > > Title: Bar is singing > > Author: Foo's hidden microphone > > Date: 2008 > > > > CD-META: > > > > nb_tracks = 16 > > length = 00:57:68 > > > > References: > > (Int-)Reference: > > name: Foo Title 1 > > offset: 108 > > (Int-)Reference: > > name: Foo Title 2 > > offset: 206 > > > > Proposed structures: > > i guess we should move metadata stuff to the stream layer. > as demuxer already depend son stream layer, and includes stream.h, it could > use the same. yeah, good idea. Problem is: What if meta-data from stream and demux layer are different. (i.e. asf-"streaming" which gets an title from stream and another one from demuxer ?) > > > -> Metadata as list. (as already implemented) > > -META as an struct specific to media. > > > > Reference: (somewaht similar to metadata, which should not be specific to > > demuxer-level) > > > > struct ref_list_s; > > > > typedef struct ref_entry_s > > { > > char* name; > > int offset; > > Url_t *URL; > > int bitrate; // perhaps present in Url_t ? > > int quality; > > ... > > int type; // external / internal reference > > ref_list_t* alternatives; > > ref_list_t* sublist; > > } ref_entry_t; > > good! > i like the idea of reusing stream layer's URL_t to keep urls parsed instead > of as plain strings. In my dream-structure everything would be handled by player as url "cdda://1, cdda://2,dvd://1/1-4/" would be a playlist but demuxer/stream (for cdda) would only be opened once and the second title would be just an seek internally. > > > typedef struct ref_list_s { > > int num_refs; // number of available entries > > int max_refs; // number of allocated entries > > (if(num_metas>=max_metas)realloc()) > > ref_entry_t* refs; > > } ref_list_t; > > > > > > So CD is a flat structure, which do not use alternatives or sublist. > > MOV can make use of alternatives to allow player an choice. > > also does .asx and .rmf... we should also handle playlists at demuxer > level, so don't forget about them! :) > > > DVD does make heavy use of sublist, as disk/titles/chapters have a > > somewaht nested strucutre. > > yes > > > One goal in later implementation should be simplicity. > > yep. but we cannot (and shouldn't) avoid the hierarchical (tree) structure > of the struct. yes. > > btw, shouldn't we put metadata and references into the same struct? > (as there is metadata for references) yes! That is a very good idea. Perhaps with this the structure can be simplified as it only needs Url_t, (+bitrate, quality) for external (i.e. new demuxer/codec open) and offset/pos for internal reference. (demuxer/stream already open) Hm, while thinking about it, I agree that it should be combined. reference |_ metadata_list_t |_ url |_ pos and reference is organized itself in a reference-list. Hm, perhaps it could be more combined and reference is jsut another type for meta_data ust like cd_info and dvd_info structures ? (of course it can't be called STRING_LIST then :-) ) > > > num=add_ext_reference(reflist,name, url) // returns the index ... > > add_ext_reference_alternative(reflist,num, name, url, bitrate, quality, > > ...) add_ext_reference_alternative(reflist,num, name2, url2, bitrate2, > > quality2, ...) > > > > num=add_reference(reflist,dvdname, offset) // returns the index ... > > add_reference_sublist(reflist,num, chaptername, offset) > > add_reference_sublist(reflist,num, chaptername2, offset2) those were just examples, that make it kind of easy to use the API ... With num one can get into each wanted level ... > > > > Later CONTROL-program can get the data via: > > > > for (i=0;i > { > > printf("Name: %s\n",reflist.refs[i]->name); > > } > > > > Convert it into own playlist/playtree-format and so on... > > > > The whole thing shall be in stream_t stream* as > > > > meta_t *meta > > { > > metadata_list_t data; > > void* specific_data; // or struct some_specific_s (like stream_priv_s) > > ref_list_t list; > > } > > hmm hm ... cu Fabian > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - > http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev From arpi at thot.banki.hu Tue May 27 00:26:04 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 27 May 2003 00:26:04 +0200 Subject: [MPlayer-G2-dev] [RFC] first draft of stream/demux-metadata support (+playlist-infos) In-Reply-To: <200305262240.09477.FabianFranz@gmx.de> Message-ID: <200305262226.h4QMQ4MW030137@mail.mplayerhq.hu> Hi, > > > (Int-)Reference: > > > name: title2 > > > offset: 1987 > > > > hmm > > what's that offset? > > pos in stream-layer ... as the control-unit needs to "say" to stream-layer go > to "chapter 5" instead it says go to: offset/pos 1656 then it should be off_t instead of int :) but i vote for a void*, so strea/demux layer could store its internal reference there. (think of demuxers where you cannot always describe a title with an offset, for example in a mov file). > > > Proposed structures: > > > > i guess we should move metadata stuff to the stream layer. > > as demuxer already depend son stream layer, and includes stream.h, it could > > use the same. > yeah, good idea. Problem is: What if meta-data from stream and demux layer are > different. (i.e. asf-"streaming" which gets an title from stream and another > one from demuxer ?) it's UI's problem. our (stream & demuxer writers) job is to store as many info as we can retrieve from input media in some structs and pass it to teh UI. then it's UI's problem how does it visualize that. i can imagine playlists with [+] sign before the urls which you can click to get the tree of its titles, chapters etc. each one has play time at the end of line, and if you move the mouse over the line you get more info (artist etc) in a floating popup window :) EOD (end of dreaming) > > > -> Metadata as list. (as already implemented) > > > -META as an struct specific to media. > > > > > > Reference: (somewaht similar to metadata, which should not be specific to > > > demuxer-level) > > > > > > struct ref_list_s; > > > > > > typedef struct ref_entry_s > > > { > > > char* name; > > > int offset; > > > Url_t *URL; > > > int bitrate; // perhaps present in Url_t ? > > > int quality; > > > ... > > > int type; // external / internal reference > > > ref_list_t* alternatives; > > > ref_list_t* sublist; > > > } ref_entry_t; > > > > good! > > i like the idea of reusing stream layer's URL_t to keep urls parsed instead > > of as plain strings. > > In my dream-structure everything would be handled by player as url "cdda://1, > cdda://2,dvd://1/1-4/" would be a playlist but demuxer/stream (for cdda) > would only be opened once and the second title would be just an seek > internally. :) > > > typedef struct ref_list_s { > > > int num_refs; // number of available entries > > > int max_refs; // number of allocated entries > > > (if(num_metas>=max_metas)realloc()) > > > ref_entry_t* refs; > > > } ref_list_t; > > > > > > > > > So CD is a flat structure, which do not use alternatives or sublist. > > > MOV can make use of alternatives to allow player an choice. > > > > also does .asx and .rmf... we should also handle playlists at demuxer > > level, so don't forget about them! > > :) don't laugh, it must be ported/implemented :) sth like demux_playlist.c to parse the various playlist formats. (or independent demux_asx demux_pls etc maybe) also there will be demux_sub to parse subtitles, but it's another game. > > > DVD does make heavy use of sublist, as disk/titles/chapters have a > > > somewaht nested strucutre. > > > > yes > > > > > One goal in later implementation should be simplicity. > > > > yep. but we cannot (and shouldn't) avoid the hierarchical (tree) structure > > of the struct. > > yes. > > > > > btw, shouldn't we put metadata and references into the same struct? > > (as there is metadata for references) > > yes! That is a very good idea. > > Perhaps with this the structure can be simplified as it only needs Url_t, > (+bitrate, quality) for external (i.e. new demuxer/codec open) and offset/pos > for internal reference. (demuxer/stream already open) yes. btw don't put things like bitrate, quality etc into the struct. they are all optional metadata info. imho a struct would look like this: typedef struct { URL_t* url; off_t pos; metadata_list* meta; metadata_list* sub; } metadata_entry_t; hmm maybe combining meta with ref isn't that good idea. what about this: typedef struct { URL_t* url; off_t pos; metadata_list* meta; ref_list_t* refs; } ref_entry_t; hmm but it doesn't handle alternatives. better ideas? > Hm, while thinking about it, I agree that it should be combined. > > reference > |_ metadata_list_t > |_ url > |_ pos > > and reference is organized itself in a reference-list. > > Hm, perhaps it could be more combined and reference is jsut another type for > meta_data ust like cd_info and dvd_info structures ? (of course it can't be > called STRING_LIST then :-) ) hmm, yes!!! you won't believe but it was my original plan when created demux_meta_t or what, i just forgot it :) btw imho we don't want/need cd_+info dvd_info and such structs, use more elementary/basic types, it's easier for all than supporting many kinds of format-specific structs. this way gui don't have to know these structs, just see what info is available and show it to the user. think of third-party plugins, ie. plugins written by ppl who can't add new types/structs into the gui or the core. ok it isn't so important :) but in my dreams, g2 gui is somewhat runtime generated, based on the structs exported by the core libs, be it config (preferences dialogs) or playlists (metadata stuff) or anything. it also means that you can add new code without messing with the gui. i hoep new config layer will be flexible enough to define gui stuff without any dependancy or knowledge on gui internals. if you can describe your filters options in a struct, and te gui will generate a nice settings window with mouse-over help etc from it, no matter if it uses gtk, qt, win32, macos APIs or plain ncurses :) > > > num=add_ext_reference(reflist,name, url) // returns the index ... > > > add_ext_reference_alternative(reflist,num, name, url, bitrate, quality, > > > ...) add_ext_reference_alternative(reflist,num, name2, url2, bitrate2, > > > quality2, ...) > > > > > > num=add_reference(reflist,dvdname, offset) // returns the index ... > > > add_reference_sublist(reflist,num, chaptername, offset) > > > add_reference_sublist(reflist,num, chaptername2, offset2) > > those were just examples, that make it kind of easy to use the API ... > > With num one can get into each wanted level ... > > > > > > > Later CONTROL-program can get the data via: > > > > > > for (i=0;i > > { > > > printf("Name: %s\n",reflist.refs[i]->name); > > > } > > > > > > Convert it into own playlist/playtree-format and so on... > > > > > > The whole thing shall be in stream_t stream* as > > > > > > meta_t *meta > > > { > > > metadata_list_t data; > > > void* specific_data; // or struct some_specific_s (like stream_priv_s) > > > ref_list_t list; > > > } > > > > hmm > > hm ... hm? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lumag at qnc.ru Tue May 27 11:49:12 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 27 May 2003 13:49:12 +0400 Subject: [MPlayer-G2-dev] DVDnavigation (was [PATCH] ported mms from main) In-Reply-To: <200305262026.h4QKQF4j029490@mail.mplayerhq.hu> References: <200305262026.h4QKQF4j029490@mail.mplayerhq.hu> Message-ID: <1054028867.4154.109.camel@orangutan.home.ru> Hello! ? ?? 27.05.2003, ? 00:26, Arpi ?????: > > > the main problem is here. mplayer has opposite design. > > > here the whole thing is pushed by the ao/vo end. so the control is done > > > at ao/vo insteda of teh other end, demuxer. > > > it was easier in g1, there demuxer was directly called by player, at least > > > for video (audio was pulled even in g1). > > Well...This really is a problem. Dunno, but suppose, that this situation > > can be possible: during calls of audio chain, VM jumps to (e.g.) STILL > > menu, where is no audio stream. Suppose, that in this situation, EOF > > will be returned for audio stream, and audio will be switched off. > > yes > > > Then, user selects next chapter, and the audio playing must be restored! > > it's not a problem, the audio layer will be reinited then. > UI will call the seek function for chapter change, it will reset EOF flag > on demuxer streams and will reset audio and video decoder too. Do you think, that UI must be notified about such changes? Is UI notified, when e.g. stream_cdda jumps to another track? > > > Moreover, things are even worse. Demuxer functions won't be called > > during STILL_FRAME's, unless they are supported directly in vf_vd.c . > > yes it's a serious problem, i didn't even think of yet. > > > It's the only place, where we can store still_frame, and then return it > > via get_pending_image, when we are in still_frame. Only in such way, we > > can keep calling demuxer, when G2 is in still_frame handler. > > no, we shouldn't put such mess into vf_vd. So we are returning to the one of major questions: which part of vf chain will support still frames & SPU rendering on them? I think, that if still_frame storing will be placed near vf_vd, other parts of player (excluding nav of course) can forget, that this is still_frame :) vf_vd will simply check, that we didn't get out of still_frame, and then it will simply return stored frame, hat will be then processed via usual vf chain and then merged with SPU and rendered via vf_vo2. If you don't want to mess vf_vd, there can be special vf_vd_nav that will be simple vf_vd with described changes. However it's not completely true:) I have to study, how to get that SPU patterns for buttons highlighting. I mean during STILL_FRAME . > > imho when we find a still frame, then demuxer should set video stream's EOF > flag. event control in 'menu' mode (be it still frame or looped video) > should be done via demuxer/stream control() function. > (actually it should always be done via control()) 'menu' mode? Well... I saw DVD (LotR-TT), on which menus were normal movie parts of ~5 secondslength, and only then followed by still frame. If 'menu mode' will be activated only at 'still frames', then buttons won't be accessible in that 5-7 second's (or I'm missing something). Moreover, I can imagine buttons in normal movie playback (hidden features, etc.) BTW. Have you seen LotR-TT trailers in QT player? It looks like this: +-----------------------+ |still banner of LotR-TT| +-----------------------+ | normal movie playback | +-----------------------+ | menu bar | +-----------------------+ Will it be possible to support such mess? > > > so actually it doesn't matter if you put navigation into stream or demux, it > > > will not be easier. > > I don't say that placing VM into demux will be too easy. > > There are no easy things on the Earth. > > yes > > > > > So navigation really lays between stream and demuxer. > > > > > > yes. > > > > > > > The main question is, where it will be easier to implement. > > > > 1. In stream layer. Then there must be API to pass events to/from > > > > stream layer. Moreover, (when using cache2.c) to/from caching > > > > process! Also, there is another problem. The main part of > > > > cache, is precache(IIUC), which means, that navigation will > > > > be _ALWAYS_ ahead of playing by some seconds. > > > > > > ok, we have to decide something: do you plan to use libdvdnav as-is > > > (using its API), or modify/rewrite/restructure it to fit mplayer's > > > structure/layers? > > No. > > No for which one? :) > > > As I wrote in first letter, I will try to use VM-emulation > > and most types of events-from-VM(such as STILL_FRAME, HOP, > > SPU_CHANGE, etc.). > > > > > > i'm asking it because dvdnav includes the dvd reading code. > > > so if we use it as-is, then we cannot use my cache2.c, for sure. > > > (cache's delay in navigation is not acceptable, as it locks on still frames) > > You are reading from my mind :) > > > > > > > 2. In separate layer between stream layer and demuxer. > > > > Why we must add extra layer specifically for _DVD_ navigation VM? > > > > (I mean, that VM's for other navigations (NUT,MOV,etc) don't > > > > belong to such place, do they?) > > > > 3. In demuxer layer. Suppose, it's a best choice: > > > > Look, how dvdnav_get_next_cache_block looks (from libdvdnav) (using > > > > metalanguage): > > > > > > if you look at what libdvdnav does, it's trivial that it's a stream level > > > element. it reads stream packets, and translates special (NAVI) packets > > > to event data, nothing more. all the demuxing (including stream separation, > > > format detection, timing) is done by demux_mpeg, not by libdvdnav. > > Maybe you meant that, but IIUC, NAVI packets(or even NAVI > > stream from MPEG stream) are/is splitted into PCI[Presentation > > Control Information] and DSI[data search information] > > structures. Events (or better VM-instructions) comes from IFO > > files. > > i'm not familiar with dvd details, just know about NAVI, as i had to mess > with that while implementing code of stream_dvd.c > > > > if you put it into demuxer layer, where do you want to implement mpeg ps > > > stream demuxing? > > In demuxer :) > > Well...IIUC, current stream API on the side of main process > > either are calls to cache2 (If it's enabled), or calls to > > stream_.c, but then cache2 is disabled. > > So, having DVDnav in stream layer will either require big > > changes to post-cache read functions (if we decide to put nav > > after cache2, but in stream layer), or hard-portable changes > > hmm, true. Does this 'true' means, that agree not to put dvdnav in stream layer ? > > > to cache2 to pass msgqueues between two processes (I don't > > think that M$Win have SYSV IPC or POSIX 1.b msg queues.). > > :) > > > > > { > > > > exec_one_vm_instruction(); > > > > if (some_conditions) > > > > return EVENT_HAPPENED; > > > > if(next_is_nav_packet) > > > > { > > > > process_it_and_store_pci_and_dsi(&pci, &dsi); > > > > return NAV_PACKET; > > > > } > > > > return BLOCK_OK; > > > > } > > > > > > > > I really suppose, that this fits to the demuxer well (moreover, if > > > > there will be special demuxer for dvdnav, all if(dvdnav) can be > > > > ommited): > > > > > > but how in the hell do you plan to pass to/from navigation events between > > > libdvdnav and UI ? > > That is one of questions in my first mail (of course if you > > mean button-press events, etc.). You said, that it must be > > done through libinput (or maybe I din't understand you). > > libinput is at the other end of the pipe. it receives keyboard/mouse/lirc/etc > events (including mouse emulation if wanted) from all input devices, > including libvo2 drivers, and translates to command code + parameters format > based on input.conf. > > my current question is about the other end of the pipe: how do you plan to > pass these events into the demuxers, and how do you plan to receive nav > events (like still image, switch stream, whatever) from demuxer? Well... It's my question too... I thought about library/API, which will register callbacks for each event-from-UI type. something like register_event_callback(EVENT_MOUSE_CLICK, nav_mouse_clicked); register_event_callback(EVENT_NAVIGATE_UP, nav_button_up); register_event_callback(EVENT_NAVIGATE_ENTER, nav_button_pressed); Or maybe a better solution: add all that EVENTS to demux->control function. > > > > maybe the new libdvdread's approach is better for mplayer g2, it uses > > > callbacks to communicate with UI. > > You mean libdvdplay? > > yes. > > I looked in two-days-old CVS of dvdread, > > and I don't see any callbacks. > > i meant libdvdplay, just mixed them, as dvdplay was made by dvdread authors > and is better layered over dvdread. I'll look into it. > > > btw do what you want, i'm interested in the actual implementation details, > > > or patches :) > > Me too:) I mean SPU-stream, event passing, etc. > > :) > > > More concrete: In June I'll have exams in university, so don't > > expect too much. (The goal of theese letters was to discuss > > what is necessary in G2 to ease support of navigation (I don't > > mean only DVDnav). I suppose, that it's better to have such > > code from begining, than having to rewrite already-working > > yes > > btw while talking about the dvdnav issues every time, i'm more and more > close to the conclusion: it is much better and easier to implement separated > from a 'normal' movie player. it's very different philosophy. Why? And what is 'normal' movie player? There are other nav's, among DVDnav (MOV, etc.). Moreover, IIRC G2 isn't a player :) > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry Baryshkov From arpi at thot.banki.hu Tue May 27 22:07:17 2003 From: arpi at thot.banki.hu (Arpi) Date: Tue, 27 May 2003 22:07:17 +0200 Subject: [MPlayer-G2-dev] trying mp_image -> get/release_buffer migration... Message-ID: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> Hi, After some problems raised (including still images and/or osd rendering into non-temp buffers), codecs using new buffering schemes (like vp3's gold frames, or h264's more-than-two P frames) i've decided to try to change video filter layer (yes, i said video filter layer, and yes, i remember what i did say before :)) to use the get_buffer/release_buffer concept insteda of current MP_IMAGE_TYPE thingie (buffering schemes like static, temp, export, ip, ipb) ok, it will be a hard and serious change, meaning that porting codecs & filters from g1 will be not as easy... but i feel it does worth it. and anyway as our primary codec is libavcodec, it will be even easier, as it already uses get/release buffer scheme. anyway my plans for this implementation inherits some key elements from g1's mp_image stuff: there will be a type field for get_buffer() requests: - EXPORT (it means that memory allocation is done by codec) - TEMP - STATIC (temp and static are actually the same, this type is only a hint for underlaying layers that we will keep this buffer after rendering for the next frames, or we'll drop it. maybe i'll leave this thing out?) also there will be restriction flags, just like in g1's mpi, to define what kind of stride and buffer alignment is accepted and do we need to preserve buffer content or allocate it in fast (readable and/or random writeable) memory. main differences from g1/mpi style: - no more specialized schemes like IP and IPB, and more than 3 buffers supported... (mpi is limited to 3) - no 'one frame decoding == one get_image call' restirction. it's possible to allocate 3 buffers at init (or at first farme decoding) and then use them all them and then release them at uninit. or a filter (likeinv. telecine) may delay video by many frames, by allocating for example 5 of them. and so on, there is no limit. it will solve some problems we currently have. and it also make sit easier to implement filter merging/branching (multiple vo drivers, mixing 2 videos etc) _later_. also a buffer (image) may be returned multiple times by process_image(). - buffer structs aren't cloned/copied while transfering from one filter to another, like mpi. although i'm not sure it's required / is a good idea. comments? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From andrej at lucky.net Tue May 27 22:42:15 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Tue, 27 May 2003 23:42:15 +0300 Subject: [MPlayer-G2-dev] Re: trying mp_image -> get/release_buffer migration... In-Reply-To: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> References: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> Message-ID: <20030527204215.GB35066@lucky.net> Hi, Arpi! Sometime (on Tuesday, May 27 at 23:06) I've received something... >- no 'one frame decoding == one get_image call' restirction. it's possible > to allocate 3 buffers at init (or at first farme decoding) and then use > them all them and then release them at uninit. or a filter (likeinv. > telecine) may delay video by many frames, by allocating for example 5 of > them. and so on, there is no limit. it will solve some problems we > currently have. and it also make sit easier to implement filter > merging/branching (multiple vo drivers, mixing 2 videos etc) _later_. > also a buffer (image) may be returned multiple times by process_image(). >- buffer structs aren't cloned/copied while transfering from one filter to > another, like mpi. although i'm not sure it's required / is a good idea. >comments? One question is how we have to calculate presentation time at end of filter chain if some filter will get more that one frame at once? That value is needed for any sync algorithm so we have to check it. Current scheme has it as sh_video->ds->pts but if we pull 5 frames (for example) then pts there will be advanced either. The same if some filter will scale pts (slowing or fasting video). So I think we have to have per-vf pts value now. Another question is if we will allow mixing video. It will be very big advantage to have more that one input stream for filter. So I think while you already will change vf_instance_t then you can add some new function vf_reopen_filter(). I'll try to describe it. If filter can have _only_ one input stream then all is as it is now and vf->prev contains previous vf and vf_reopen_filter() will work exactly as vf_open_filter(). If filter can support more than one input stream then it on open() will remove vf->prev into internal structure and set vf->prev to NULL. Then next call of function vf_reopen_filter() will check it and return error if that pointer is no-NULL. So for filter with only one input stream that vf_reopen_filter() will call vf->open() only once and for filter with more streams it may be called as much as filter allows. I hope that solution is good and fully compatible with all current implementation. That have also another advantage - it allows as to build concurrent OSD just as filter module not another layer that will mix video and OSD inputs. :) With the best wishes. Andriy. From dalias at aerifal.cx Wed May 28 01:59:28 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Tue, 27 May 2003 19:59:28 -0400 Subject: [MPlayer-G2-dev] trying mp_image -> get/release_buffer migration... In-Reply-To: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> References: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> Message-ID: <20030527235928.GD23552@brightrain.aerifal.cx> On Tue, May 27, 2003 at 10:07:17PM +0200, Arpi wrote: > main differences from g1/mpi style: > - no more specialized schemes like IP and IPB, and more than 3 buffers > supported... (mpi is limited to 3) > - no 'one frame decoding == one get_image call' restirction. it's possible > to allocate 3 buffers at init (or at first farme decoding) and then use > them all them and then release them at uninit. or a filter (likeinv. > telecine) may delay video by many frames, by allocating for example 5 of > them. and so on, there is no limit. it will solve some problems we > currently have. and it also make sit easier to implement filter > merging/branching (multiple vo drivers, mixing 2 videos etc) _later_. > also a buffer (image) may be returned multiple times by process_image(). > - buffer structs aren't cloned/copied while transfering from one filter to > another, like mpi. although i'm not sure it's required / is a good idea. > > comments? I'm a bit confused how all this works with DR into video memory, since a given buffer can only be "used" once, and the filter/codec drawing into it MUST release it along with displaying it in order to prevent shearing. Is this already covered, or do you have a plan in mind? Rich From finlayson at live.com Wed May 28 03:14:42 2003 From: finlayson at live.com (Ross Finlayson) Date: Tue, 27 May 2003 18:14:42 -0700 Subject: [MPlayer-G2-dev] Crash in G2 (v30) Message-ID: <4.3.1.1.20030527180827.00b6fe00@laptop-localhost> I downloaded and built MPlayer "G2" (v30) from (with the aim of seeing how easy it would be to port the LIVE.COM RTSP/RTP demuxer to it), but unfortunately "test-play" crashed when I tried to play an ordinary MPEG-1 Program Stream file. See the "gdb" output below. I have left a copy of the input file online as http://www.live.com/mplayer/test.mpg Ross. %gdb ./test-play GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run test.mpg Starting program: /home/rsf/mplayer/g2/./test-play ~/.mk/testProgs/test.mpg Using GNU internationalization Original domain: messages Original dirname: /usr/share/locale Current domain: mplayer Current dirname: /usr/local/share/locale CPU: Intel Celeron A Mendocino/Pentium II Dixon (Family: 6, Stepping: 10) Detected cache-line size is 32 bytes faszom 0/1 parsed /home/rsf/.mk/testProgs/test.mpg as filename get_path('codecs.conf') -> '/home/rsf/.mplayer/codecs.conf' Reading /home/rsf/.mplayer/codecs.conf: 53 audio & 141 video codecs Not an URL! Stream type: 0 len: 41639108 demuxer: trying [avi] based on Content, level 1 DEMUXER: freeing demuxer at 0x829d598 demuxer: trying [asf] based on Content, level 1 DEMUXER: freeing demuxer at 0x829d598 demuxer: trying [ogg] based on Content, level 1 DEMUXER: freeing demuxer at 0x829d598 demuxer: trying [nsv] based on Content, level 1 DEMUXER: freeing demuxer at 0x829d598 demuxer: trying [ts] based on Content, level 1 demuxer: trying [mpeg] based on Content, level 1 demuxer: trying [avi] based on Content, level 2 demuxer: trying [asf] based on Content, level 2 demuxer: trying [ogg] based on Content, level 2 demuxer: trying [nsv] based on Content, level 2 demuxer: trying [ts] based on Content, level 2 DEMUXER: freeing demuxer at 0x829d598 demuxer: trying [mpeg] based on Content, level 2 demuxer: trying [avi] based on Content, level 3 demuxer: trying [asf] based on Content, level 3 demuxer: trying [ogg] based on Content, level 3 demuxer: trying [nsv] based on Content, level 3 demuxer: trying [ts] based on Content, level 3 demuxer: trying [mpeg] based on Content, level 3 Detected fileformat: [mpeg] MPEG TS/PS/PES/ES Audio and/or Video MPEG-PS System Stream synced at 0x0 (0)! DEMUXER: New stream: 480 type: 1 DEMUXER: New stream: 448 type: 2 ######### Audio STREAM #448 (enabled) ######### Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 dec_audio: Allocating 4608 + 65536 = 70144 bytes for output buffer mp3lib: made decode tables with MMX optimization mp3lib: using MMX optimized decore! MP3lib: init layer2&3 finished, tables done Program received signal SIGILL, Illegal instruction. 0x81ab51b in fast_memcpy_SSE (to=0x8260e40, from=0x8260740, len=512) at aclib_template.c:213 213 __asm__ __volatile__ ( (gdb) where #0 0x81ab51b in fast_memcpy_SSE (to=0x8260e40, from=0x8260740, len=512) at aclib_template.c:213 #1 0x81ab60f in fast_memcpy (to=0x8260e40, from=0x8260740, len=512) at aclib.c:136 #2 0x816ec3b in MP3_DecodeFrame (hova=0x84aa380 "", single=-1) at sr1.c:168 #3 0x804fc0c in init (sh=0x84aa308) at ad_mp3lib.c:49 #4 0x804e91e in init_audio_codec (sh_audio=0x84aa308) at dec_audio.c:105 #5 0x804eb69 in init_audio (sh_audio=0x84aa308, codecname=0x0, afm=0x0, status=1) at dec_audio.c:195 #6 0x804ece1 in init_best_audio_codec (sh_audio=0x84aa308, audio_codec_list=0xbffffa44, audio_fm_list=0x0) at dec_audio.c:240 #7 0x804ddbc in main (argc=2, argv=0xbffffb04, envp=0xbffffb10) at test-play.c:206 (gdb) From arpi at thot.banki.hu Wed May 28 13:44:55 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 28 May 2003 13:44:55 +0200 Subject: [MPlayer-G2-dev] Crash in G2 (v30) In-Reply-To: <4.3.1.1.20030527180827.00b6fe00@laptop-localhost> Message-ID: <200305281144.h4SBit9j024046@mail.mplayerhq.hu> Hi, > CPU: Intel Celeron A Mendocino/Pentium II Dixon (Family: 6, Stepping: 10) > #0 0x81ab51b in fast_memcpy_SSE (to=0x8260e40, from=0x8260740, len=512) seems you have compiled it for p3 but you have p2 only... did you run g1's configure (or edit config.h+.mak by hand) before make? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From arpi at thot.banki.hu Wed May 28 14:33:18 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 28 May 2003 14:33:18 +0200 Subject: [MPlayer-G2-dev] trying mp_image -> get/release_buffer migration... In-Reply-To: <20030527235928.GD23552@brightrain.aerifal.cx> Message-ID: <200305281233.h4SCXIUw020210@mail.mplayerhq.hu> Hi, > > main differences from g1/mpi style: > > - no more specialized schemes like IP and IPB, and more than 3 buffers > > supported... (mpi is limited to 3) > > - no 'one frame decoding == one get_image call' restirction. it's possible > > to allocate 3 buffers at init (or at first farme decoding) and then use > > them all them and then release them at uninit. or a filter (likeinv. > > telecine) may delay video by many frames, by allocating for example 5 of > > them. and so on, there is no limit. it will solve some problems we > > currently have. and it also make sit easier to implement filter > > merging/branching (multiple vo drivers, mixing 2 videos etc) _later_. > > also a buffer (image) may be returned multiple times by process_image(). > > - buffer structs aren't cloned/copied while transfering from one filter to > > another, like mpi. although i'm not sure it's required / is a good idea. > > > > comments? > > I'm a bit confused how all this works with DR into video memory, since > a given buffer can only be "used" once, and the filter/codec drawing > into it MUST release it along with displaying it in order to prevent > shearing. Is this already covered, or do you have a plan in mind? it should work as before. it doesn't mean an 1:1 mapping of buffers, if the number or type of available vo buffers doesn't match / is enough for the filter/codec, then it will do copy (slices) instead of DR. there is a dr flag to control this stuff, it has 3 states: - no dr, ie dr is disallowed - default, dr is used only if it doens't mean quality (tearing etc) loss - force dr, it will prefer dr, even if it means worse quality (for example using double buffering instead of triple). usefull for very slow machines... so the user can decide if quality or speed has higher priority. but this is not new, it's done so already in g2, and partially in g1 too A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From dalias at aerifal.cx Wed May 28 22:25:39 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Wed, 28 May 2003 16:25:39 -0400 Subject: [MPlayer-G2-dev] Re: trying mp_image -> get/release_buffer migration... In-Reply-To: <20030527204215.GB35066@lucky.net> References: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> <20030527204215.GB35066@lucky.net> Message-ID: <20030528202539.GI23552@brightrain.aerifal.cx> On Tue, May 27, 2003 at 11:42:15PM +0300, Andriy N. Gritsenko wrote: > Hi, Arpi! > > Sometime (on Tuesday, May 27 at 23:06) I've received something... > >- no 'one frame decoding == one get_image call' restirction. it's possible > > to allocate 3 buffers at init (or at first farme decoding) and then use > > them all them and then release them at uninit. or a filter (likeinv. > > telecine) may delay video by many frames, by allocating for example 5 of > > them. and so on, there is no limit. it will solve some problems we > > currently have. and it also make sit easier to implement filter > > merging/branching (multiple vo drivers, mixing 2 videos etc) _later_. > > also a buffer (image) may be returned multiple times by process_image(). > >- buffer structs aren't cloned/copied while transfering from one filter to > > another, like mpi. although i'm not sure it's required / is a good idea. > > >comments? > > One question is how we have to calculate presentation time at end of > filter chain if some filter will get more that one frame at once? That > value is needed for any sync algorithm so we have to check it. Current > scheme has it as sh_video->ds->pts but if we pull 5 frames (for example) > then pts there will be advanced either. The same if some filter will > scale pts (slowing or fasting video). So I think we have to have per-vf > pts value now. This was discussed about a month ago. PTS (or rather duration) is a property of the image now, so it's not an issue. > Another question is if we will allow mixing video. It will be very > big advantage to have more that one input stream for filter. So I think > while you already will change vf_instance_t then you can add some new > function vf_reopen_filter(). I'll try to describe it. If filter can have > _only_ one input stream then all is as it is now and vf->prev contains > previous vf and vf_reopen_filter() will work exactly as vf_open_filter(). > If filter can support more than one input stream then it on open() will > remove vf->prev into internal structure and set vf->prev to NULL. Then > next call of function vf_reopen_filter() will check it and return error > if that pointer is no-NULL. So for filter with only one input stream that > vf_reopen_filter() will call vf->open() only once and for filter with > more streams it may be called as much as filter allows. I hope that > solution is good and fully compatible with all current implementation. > That have also another advantage - it allows as to build concurrent OSD > just as filter module not another layer that will mix video and OSD > inputs. :) That's a slow and nonsensical way to do OSD... Yes, we want multi-input support, but I don't think multiple opens makes any sense. If anything, multiple config, once for each source, but open should be called only once. Rich From arpi at thot.banki.hu Wed May 28 23:54:20 2003 From: arpi at thot.banki.hu (Arpi) Date: Wed, 28 May 2003 23:54:20 +0200 Subject: [MPlayer-G2-dev] pre31 + pause Message-ID: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> Hi, ok here's pre31, nothing special, just some patches applied, and configure from g1 included: pre31: - stream layer: mms:// support ported from g1/main by Fabian Franz - libmpeg2 postprocessing (export qscale) support by Fabian Franz - cvs up (libavcodec etc updated) - configure from g1 included (modified at help/* and mpdvdklit2 detection) - stream/README updated :))))) Don't expect pre32 soon, i'll mess up my tree to death to try out the get/release_buffer concept in practice. also i'll get my long-awaited hauppauge pvr-350 capture card tomorrow so i'll hack it for a few days. and i'll be away at weekend, so probably no g2 development until the end of this week... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lgb at lgb.hu Thu May 29 07:47:17 2003 From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=) Date: Thu, 29 May 2003 07:47:17 +0200 Subject: [MPlayer-G2-dev] pre31 + pause In-Reply-To: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> References: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> Message-ID: <20030529054717.GB5686@vega.digitel2002.hu> On Wed, May 28, 2003 at 11:54:20PM +0200, Arpi wrote: > hauppauge pvr-350 capture card tomorrow so i'll hack it for a few days. and > i'll be away at weekend, so probably no g2 development until the end of this > week... Eh, what's a Linus feeling :) - G?bor (larta'H) From andrej at lucky.net Thu May 29 09:25:31 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 29 May 2003 10:25:31 +0300 Subject: [MPlayer-G2-dev] Re: trying mp_image -> get/release_buffer migration... In-Reply-To: <20030528202539.GI23552@brightrain.aerifal.cx> References: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> <20030527204215.GB35066@lucky.net> <20030528202539.GI23552@brightrain.aerifal.cx> Message-ID: <20030529072531.GA40911@lucky.net> Hi, D Richard Felker III! Sometime (on Wednesday, May 28 at 23:17) I've received something... >> Another question is if we will allow mixing video. It will be very >> big advantage to have more that one input stream for filter. So I think >> while you already will change vf_instance_t then you can add some new >> function vf_reopen_filter(). I'll try to describe it. If filter can have >> _only_ one input stream then all is as it is now and vf->prev contains >> previous vf and vf_reopen_filter() will work exactly as vf_open_filter(). >> If filter can support more than one input stream then it on open() will >> remove vf->prev into internal structure and set vf->prev to NULL. Then >> next call of function vf_reopen_filter() will check it and return error >> if that pointer is no-NULL. So for filter with only one input stream that >> vf_reopen_filter() will call vf->open() only once and for filter with >> more streams it may be called as much as filter allows. I hope that >> solution is good and fully compatible with all current implementation. >> That have also another advantage - it allows as to build concurrent OSD >> just as filter module not another layer that will mix video and OSD >> inputs. :) >That's a slow and nonsensical way to do OSD... Yes, we want >multi-input support, but I don't think multiple opens makes any sense. >If anything, multiple config, once for each source, but open should be >called only once. I've proposed it to avoid changes as much as possible. Another way will bring changes in vf_instance_t structure. Beside of that, even multi vf->open() call are good if it's documented well. Don't forget that some GUI may want add input stream in already created chain (so vf->open() was already called) instead of saving parameters, destroying all chain and recreating it with new source for that filter. Anyway, if you have another solution - please, give it to us here. :) With best wishes. Andriy. From andrej at lucky.net Thu May 29 09:43:26 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Thu, 29 May 2003 10:43:26 +0300 Subject: [MPlayer-G2-dev] Re: pre31 + pause In-Reply-To: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> References: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> Message-ID: <20030529074326.GB40911@lucky.net> Hi, Arpi! Sometime (on Thursday, May 29 at 0:21) I've received something... >ok here's pre31, nothing special, just some patches applied, and configure >from g1 included: >pre31: >- stream layer: mms:// support ported from g1/main by Fabian Franz >- libmpeg2 postprocessing (export qscale) support by Fabian Franz >- cvs up (libavcodec etc updated) >- configure from g1 included (modified at help/* and mpdvdklit2 detection) >- stream/README updated :))))) >Don't expect pre32 soon, i'll mess up my tree to death to try out the >get/release_buffer concept in practice. also i'll get my long-awaited >hauppauge pvr-350 capture card tomorrow so i'll hack it for a few days. and >i'll be away at weekend, so probably no g2 development until the end of this >week... Do you have in mind all we discussed at this week about config? It seems still not finished yet so I want to see the final (less or much) version. I'll remind what it was about: 1. remove all mpconfig_parse_*() into some cfg-l1.h; 2. restore CONF_TYPE_LIST; 3. make decision about extention of CONG_TYPE_GROUP or CONF_TYPE_SELECT. With the best wishes. Andriy. From lumag at qnc.ru Thu May 29 18:29:17 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 29 May 2003 20:29:17 +0400 Subject: [MPlayer-G2-dev] pre31 + pause In-Reply-To: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> References: <200305282154.h4SLsKNe018494@mail.mplayerhq.hu> Message-ID: <1054225752.1558.2.camel@orangutan.home.ru> Hello! ? ??, 29.05.2003, ? 01:54, Arpi ?????: > Hi, > > ok here's pre31, nothing special, just some patches applied, and configure > from g1 included: > > pre31: > - stream layer: mms:// support ported from g1/main by Fabian Franz > - libmpeg2 postprocessing (export qscale) support by Fabian Franz > - cvs up (libavcodec etc updated) > - configure from g1 included (modified at help/* and mpdvdklit2 detection) THis modification doesn't work properly :) There are some places, where you need %s/libmpdvdkit/stream\/mpdvdkit/g [skipped] > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry Baryshkov From arpi at thot.banki.hu Thu May 29 19:10:19 2003 From: arpi at thot.banki.hu (Arpi) Date: Thu, 29 May 2003 19:10:19 +0200 Subject: [MPlayer-G2-dev] pre31 + pause In-Reply-To: <1054225752.1558.2.camel@orangutan.home.ru> Message-ID: <200305291710.h4THAJvp011309@mail.mplayerhq.hu> Hi, > Hello! > ? ??, 29.05.2003, . 01:54, Arpi .....: > > Hi, > > > > ok here's pre31, nothing special, just some patches applied, and configure > > from g1 included: > > > > pre31: > > - stream layer: mms:// support ported from g1/main by Fabian Franz > > - libmpeg2 postprocessing (export qscale) support by Fabian Franz > > - cvs up (libavcodec etc updated) > > - configure from g1 included (modified at help/* and mpdvdklit2 detection) > THis modification doesn't work properly :) > There are some places, where you need %s/libmpdvdkit/stream\/mpdvdkit/g > [skipped] send patch i has no time nor interest to test & fix more this configure script, as it's a temporal solution for ppl. who are unable to copy config.* from g1, or hand-edit the files... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From lumag at qnc.ru Thu May 29 18:51:39 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 29 May 2003 20:51:39 +0400 Subject: [PATCH] Fixed configure.g1 (was Re: [MPlayer-G2-dev] pre31 + pause) In-Reply-To: <200305291710.h4THAJvp011309@mail.mplayerhq.hu> References: <200305291710.h4THAJvp011309@mail.mplayerhq.hu> Message-ID: <1054227099.1558.6.camel@orangutan.home.ru> Hello! ? ??, 29.05.2003, ? 21:10, Arpi ?????: [skipped] > send patch attached > i has no time nor interest to test & fix more this configure script, as > it's a temporal solution for ppl. who are unable to copy config.* from g1, > or hand-edit the files... It's for such people:) > > > A'rpi / Astral & ESP-team > > -- > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > _______________________________________________ > MPlayer-G2-dev mailing list > MPlayer-G2-dev at mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With the best wishes Dmitry Baryshkov From lumag at qnc.ru Thu May 29 18:54:03 2003 From: lumag at qnc.ru (Dmitry Baryshkov) Date: 29 May 2003 20:54:03 +0400 Subject: [PATCH] Fixed configure.g1 (was Re: [MPlayer-G2-dev] pre31 + pause) In-Reply-To: <1054227099.1558.6.camel@orangutan.home.ru> References: <200305291710.h4THAJvp011309@mail.mplayerhq.hu> <1054227099.1558.6.camel@orangutan.home.ru> Message-ID: <1054227243.1559.8.camel@orangutan.home.ru> Hello! ? ??, 29.05.2003, ? 20:51, Dmitry Baryshkov ?????: > Hello! > ? ??, 29.05.2003, ? 21:10, Arpi ?????: > [skipped] > > send patch > attached Sorry, forgot to attach. > > i has no time nor interest to test & fix more this configure script, as > > it's a temporal solution for ppl. who are unable to copy config.* from g1, > > or hand-edit the files... > It's for such people:) > > > > > > A'rpi / Astral & ESP-team > > > > -- > > Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu > > > > _______________________________________________ > > MPlayer-G2-dev mailing list > > MPlayer-G2-dev at mplayerhq.hu > > http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev -- With best wishes Dmitry Baryshkov -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.g1.patch Type: application/octet-stream Size: 882 bytes Desc: not available URL: From dalias at aerifal.cx Thu May 29 20:22:05 2003 From: dalias at aerifal.cx (D Richard Felker III) Date: Thu, 29 May 2003 14:22:05 -0400 Subject: [MPlayer-G2-dev] Re: trying mp_image -> get/release_buffer migration... In-Reply-To: <20030529072531.GA40911@lucky.net> References: <200305272007.h4RK7HSj013747@mail.mplayerhq.hu> <20030527204215.GB35066@lucky.net> <20030528202539.GI23552@brightrain.aerifal.cx> <20030529072531.GA40911@lucky.net> Message-ID: <20030529182205.GL23552@brightrain.aerifal.cx> On Thu, May 29, 2003 at 10:25:31AM +0300, Andriy N. Gritsenko wrote: > Hi, D Richard Felker III! > > Sometime (on Wednesday, May 28 at 23:17) I've received something... > >> Another question is if we will allow mixing video. It will be very > >> big advantage to have more that one input stream for filter. So I think > >> while you already will change vf_instance_t then you can add some new > >> function vf_reopen_filter(). I'll try to describe it. If filter can have > >> _only_ one input stream then all is as it is now and vf->prev contains > >> previous vf and vf_reopen_filter() will work exactly as vf_open_filter(). > >> If filter can support more than one input stream then it on open() will > >> remove vf->prev into internal structure and set vf->prev to NULL. Then > >> next call of function vf_reopen_filter() will check it and return error > >> if that pointer is no-NULL. So for filter with only one input stream that > >> vf_reopen_filter() will call vf->open() only once and for filter with > >> more streams it may be called as much as filter allows. I hope that > >> solution is good and fully compatible with all current implementation. > >> That have also another advantage - it allows as to build concurrent OSD > >> just as filter module not another layer that will mix video and OSD > >> inputs. :) > > >That's a slow and nonsensical way to do OSD... Yes, we want > >multi-input support, but I don't think multiple opens makes any sense. > >If anything, multiple config, once for each source, but open should be > >called only once. > > I've proposed it to avoid changes as much as possible. Another way > will bring changes in vf_instance_t structure. Beside of that, even multi > vf->open() call are good if it's documented well. Don't forget that some > GUI may want add input stream in already created chain (so vf->open() was > already called) instead of saving parameters, destroying all chain and > recreating it with new source for that filter. > Anyway, if you have another solution - please, give it to us here. :) I think you misunderstand the open call. open is not used to connect an input to the filter, just to initialize the instance. config is the call that connects an input. Rich From andrej at lucky.net Sat May 31 09:49:27 2003 From: andrej at lucky.net (Andriy N. Gritsenko) Date: Sat, 31 May 2003 10:49:27 +0300 Subject: [MPlayer-G2-dev] About final cfg.h again. In-Reply-To: <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> References: <20030524091304.GA29804@lucky.net> <200305251219.h4PCJCtQ012380@mail.mplayerhq.hu> Message-ID: <20030531074927.GA13596@lucky.net> Hi, Arpi! Last time I found something bad about new config layer 0. Let's see. You dropped CONF_TYPE_SUBCONFIG. May be it's ok for modules but no only modules had that type. Without that type we cannot implement some things anymore. I mean option '-info' - this is no module subconfig but all in it are strings. Now there is no way to implement it at all. I'm agree, we can omit it and move it into muxer for example but I don't like to have info fields as muxer common fields - it's not convenient to mix all such different things as muxer variables and info, info has to be in separate box in GUI, not all muxers have the same info fields, etc. I.e., I prefer to have in my config: muxer.avi.info.copyright = The Studio instead of muxer.copyright = The Studio but it's impossible without CONF_TYPE_SUBCONFIG. With best wishes. Andriy.