On Mon, 05 Jun 2006 12:17:46 JST
[EMAIL PROTECTED] (Andrew Church) wrote:

> >That's good for demuxers, but not so good for muxers. There is a couple of
> >issues:
> >1) encoder core code (src/encoder.c) uses single-instance multiplexor and
> >runs it, as well as A/V encoders, in a single thread. This happens both on
> >OMS and in NMS-powered code. I'm pretty satisfied of this situations
> >because it's work quite well, it's clean enough and... We need to join
> >streams at some point in processing pipeline!
> 
>      Why?  If you're outputting the audio to a separate file, it doesn't
> make sense to try and keep them in sync anyway.

Yep, that's true for this case. My key point on encoder it's just that our
main encoder (I mean src/encoder.c) expects also to join streams, so
separate A/V files is the exception, not the rule. That's the rule that
trained the other conclusions so the rationale for my first point was... My
second point (not quoted here) ;).

> It's easy enough to create
> a second multiplexor instance if we're outputting a separate audio stream,
> and call the multiplexor twice instead of once, like the (incomplete) patch
> below. 

That's a pretty nice idea indeed, but the the last one it's even better

> Or we could just drop support for separate audio export completely;
> the main reason for it (MPEG) will go away once we have MPEG multiplexing
> support, and if anyone really needs it we can tell them to do the audio run
> separately: transcode ... -o foo.wav
> 
>      So I'm still in favor of only one file argument (and no audio/video
> flag) to open().

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).

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

Reply via email to