[vlc-devel] issue arising from OggDirac muxing

Laurent Aimar fenrir at via.ecp.fr
Tue Oct 28 20:30:10 CET 2008


On Mon, Oct 27, 2008, David Flynn wrote:
> I'm currently trying to implement the OggDirac mapping, and fairly
> easily have something that works.  However, I've come up against a
> short coming in the ogg muxing.
> 
> The OggDirac mapping goes to great effort to allow the regeneration
> of both DTS and PTS from the granulepos.  The numbers are munged a
> bit into units of pictures rather than 90kHz.
> 
> Unfortunately Ogg doesn't really help matters with a lack of any real
> synchronisation primitives.
> 
> I'll start with an example of what a stream should look like, then
> how it all goes wrong:
> 
> So a correct OggDirac stream has pt(pts but in units of pictures
> and dt(similarly dts): (picture types are arbitrary examples)
>      I  P  P  P  P  P
> pt: [5, 0, 1, 2, 3, 4, ...]
> dt: [-1,0, 1, 2, 3, 4, ...]
> 
> Now, lets assume i'm transcoding some video that ends up with
> the following at the encoder output:
> Audio-pts: [ -, 10, 11, 12, 13, 14, 15 ...]
> Video-pts: [15, 10, 11, 12, 13, 14, ...]
> Video-dts: [ 9, 10, 11, 12, 13, 14, ...]
> 
> The first thing the oggmuxer does is to stash a copy of the first dts;
> call it dts[0]. The timestamps in the stream are now all normalised
> by subtracting dts[0] from them.
> 
> It is important to note that this is done *separately* for each stream:
> Audio-pt: [-, 0, 1, 2, 3, 4, ...
> Video-pt: [6, 1, 2, 3, 4, ...]
> Video-dt: [0, 1, 2, 3, 4, ...]
> Notice that the 'pt' for the first audio packet(pt=0) and first output
> video picture(pt=1) are no longer identical?  This results in this
> example for a 1frame a/v sync error.

 That is an error of the ogg muxer, it should not be done independantly
(unless if ogg does not permit a stream to not start from something != 0).

 The proper fix would be to use the lowest DTS over all ES IF ogg allows it.

 If the video stream use reordering (1 for normal B, more for hierarchical B 
like in h264), it will work.
 The only "weird" thing might be that the lowest PTS value will not be 0 but
reodering_max * frame_duration for CFR video.
 I do not thing it is a problem (for example .mp4 specs does work like this).
If not wanted then you have a problem because the initial DTS value would
then be < 0.

-- 
fenrir




More information about the vlc-devel mailing list