>> >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 ;)
I'll be doing the same (what spare time? ;)
>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
Good idea, let's do that.
>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'.
Why don't we leave y4m as is, and split wav off to multiplex_wav?
If that sounds reasonable to you, I can go ahead and do this (and add the
fourth -y parameter too).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
