Hi, > Check Lucky.asf and enjoy saved memory :) - also would be good > idea to send me proper patches if you would see the reason for them - > but I've prepared some hooks to make it easy for you.
Ok, I'll check (later). yesterday I tried to import directshow C sources to mplayer, not working yet. you didn't converted ds_videodecoder/ds_audiodecoder, so i got them from xine. but of course they are not compatible with yours, but it was easy to fix. now video decoding works, but no setvalue/getvalue yet (it's disabled in xine, - dunno how do they set postprocessing then). Do you plan to convert these, or i should do some cleanup of xine's version? > Also if there is no reason to have that strange NEW_CRITICAL_SECTION > I'd like to remove it (and do few other cleanups to remove dead code > and useless headers) I'll ask al3x. afaik he added for VP31, but it should be usefull for others too (i think, not sure). > What is necessary for qtx support ? What you #if 0'd. :) Mostly the tls_ linked list stuff. expTlsAlloc and so on. qtx codecs assumes some relations between tls pointers and something at FS: segment space. dunno the details, Eugene fixed it and sent patch. qtx support not yet working, as we should find out the structure of Component. in their sdk it's a dummy int[1] placeholder, and their static lib handle it :( but codecs expect some data and fourcc's there. i should do some more demugging, mostly in crossover plugin, but i'm too busy now so it's delayed a bit. > Seeing you have already converted some cpp code yourself - I'll try no. it's for xine, just fixed a bit for our needs and to be compatible with your ds_filter stuff. > to come with some clean solution usable for both of use later. ok. > Would you agree on the style used by DS_Filter - or you want to > see DS_Videodecoder_Decompress(This,) instead of > This->Decompress(This,..) DS_Filter-like stuff is ok for me. btw i must keep the wrappers, as libwin32.h and the lots of stuff included there does conflicts with other includes in mplayer. :( but it's my prob... > And finaly - may I expect some common config parser or do I have to > write this also myself. check our codec-cfg.c|h, it has everything we need. I bet you won't like it's coding style so you'll rewrite it :), but in its current state it is working well and provides an array of codecs with all info parsed from the codecs.conf file. some things can be removed, mainly the native codec ids. it's enough to keep acm/vfw and dshow types, and maybe qtx in the future. i have some ideas to improve it for win32 stuff, especially for outfmt. we don't detect it, we set it in codecs.conf. it's bad for some special format like cram and huffyuv (their outfmt depends on input bitmapinfohdr). but on the other side, soem codecs provides false info at detection. so we should improve it to something: outfmt YV12?,YUY2,RGB24,RGB16? ? means: should be detected/queried. also: outfmt * it means all outfmt should be detected (and it's the default if no outfmt line(s) for that codecs) re: your letetr about users editing codecs.conf. no, i didn't say that users will do it. btw soem users already did it and sent us patches for codecs.conf with working codecs, without any mods to win32.c i agree in that win32.c should be usually modified for new codecs. but codecs.conf is very usefull for _us_, developers, as we don't have to recompile program at every codec parameter modification to test. and easier for users too, they can upgrade codecs.conf, don't have to recompile player (unless it needs win32.c mods) maybe we should add some version number to win32 loader/emu code, and add such field to codecs.conf (min_emu_version 127) A'rpi / Astral & ESP-team -- mailto:[EMAIL PROTECTED] http://esp-team.scene.hu _______________________________________________ Avifile mailing list [EMAIL PROTECTED] http://prak.org/mailman/listinfo/avifile
