Re: [PATCH] mplex A/V precedence order

Hi all,


> You're perfectly right. But the "problem" here is not the  
> 'video_first'  flag but the surrounding for-loop in conjunction with
> 
>    if( (*str)->MuxPossible(current_SCR) &&
>                                  ( !video_first || (*str)->Kind() ==  
> ElementaryStream::video )


> As str always points to a video stream ("master") stream when entering  
> the for-loop (first elementary stream), MuxPossible() and  
> ((*str)->Kind() ==ElementaryStream::video) will always be true until  
> the video scr is far ahead of the current scr (e.g. at the beginning  
> of the next GOP). Only then other streams are appended (and might be  
> late in terms of SCR). You may check that behaviour using VobuEdit  
> (windows Shareware)


Here's the complete code fragment... (sans #ifdef-ery)


    for( str = estreams.begin(); str < estreams.end(); ++str )
    {
            if( (*str)->MuxPossible(current_SCR) && 
                ( !video_first || (*str)->Kind() ==
ElementaryStream::video )
                 )
            {
                if( despatch == 0 || earliest > (*str)->RequiredDTS() )
                {
                    despatch = *str;
                    earliest = (*str)->RequiredDTS();
                }
            }
    }


If !video_first then 'despatch'  (the stream to despatch fur muxing)
will be set to the stream with the *lowest* 'required DTS'.  I.e.
despatch will be set to the 'most urgent' stream .

If video is coming in great big blocks then it *either* its because the
sync is so that this is necessary (big offset in video/audio DTS) OR
there's something else going on.



cheers,

	Andrew



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev