Re: [PATCH] mplex A/V precedence order

Zitat von Andrew Stevens <[email protected]>:

> Hi all (especially Bernhard) ...
>
>
>
> The invisble developer (turned Daddy/developer in a start-up) returns...
>
>> > The multiplex strategy in mplex will add all non-video packages at
>> > the  end of a GOP. While i don't know about other formats (VCD and
>> > so on),  in case of DVD all video information is put at the
>> > beginning of a VOBU  and the remaining streams are sent to the end
>> > of a VOBU, regardless of  their timestamps This behaviour may cause
>> > a buffer underrun in  standalone players.
>> > I cannot give concrete example for a real-live failure, but looking
>> > at  produced A/V streams (and code) gives me a strange feeling.
>
> This is not actually the case.  The absolute priority to video is only
> given when 'video_first' is set.   This occurs essentially only in the
> initial packet of VCD and 'DVD_NAV' multiplex runs where this is a
> special requirement.  Once this special first packet is done video_first
> is reset and priority is given to the most urgent packet.
>
>
> Some painful learnining messy details of messy pseudo-standards lies
> behind this. This should NOT be changed.
>
>
> cheers,
> 	Andrew
> PS
> I'm in the process of changing ISP... the googlemail email address is
> the only one that will remaint stable long-term.
>

Hi Daddy/Developer;-)

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)
The "video_first" flag is still vital to detect the priority of video  
streams and to put them directly behind nav sector (as you explained)

So the idea was to flip over the for loop to start at the end of a  
stream stack walking to the first (master) video stream - keeping the  
"video_first" flag as-is).

Cheers,
   Roland (another daddy;-)




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