On Mon, 05 Jun 2006 15:30:52 JST [EMAIL PROTECTED] (Andrew Church) wrote: > >That's pretty fine excepts for the fact that MPEG multiplexor will not pop > >out soon, surely not for 1.1.0 (at least not from my side, > >unfortunately :( ). So we need a temporary solution and perhaps the better > >thing it's to add a second-instance multiplexor (triggered by -m usage, I > >think). > > Okay, then why don't we do that for now?
Well, I'll patch existing code as long as I find some more spare time ;) > That leaves the question of > how to decide which multiplexor to use, but in the common (mp2) case it's > just raw data, so I guess we could default to multiplex_raw, At this moment my vote goes to "let the user choose", of course providing some documentation to help the user do a wise choice, and maybe defaulting to raw multiplexor. In other words, my idea is to require something like: transcode [...] -y foo,bar,buz,raw -m /tmp/blah.ext [...] Read: if user selects separate audio file (-m option), then REQUIRE the selection of second multiplexor too. Exit complaining if - second multiplexor selected (fourth -y argument) but NOT -m provided - -m provided but second multiplexor NOT selected > with maybe a > hack to use multiplex_wav (uh, looks like somebody needs to write it ;) ) > if the filename ends in .wav? It exists already, it's merged with yuv4mpeg "multiplexor" :) You can find both in "multiplex_y4m" module. Okay, maybe this sucks and maybe the name chooses sucks even more, but at time of writing this I was in mood "no more that one multiplexor at time!" :P Seriously speaking, I think this situation can stay as well as we are able to found a name more explicative and that sounds better for 'multiplex_y4m'. Splitting such multiplexor, if we go for this, isn't a pain, anyway. > BTW, I just hacked the -y option and encoder.c so you can now say > -y vid,aud,mplex and get the NMS encoder (if you only specify 1 or 2 then > it uses the old code). I did a little testing with -y xvid,copy,avi and > it seems to work fine. Yeah, I'm going to give it a spin too. ;) > Good work! (: My pleasure. But there is still a lot to do ;) Best regards, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact: (email-me, I have antispam default deny!) icq://27-83-87-867 some known bugs: http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
