[vlc-devel] [PATCH 1/1] [rawvideo] Fix timestamps & input options

[Laurent Aimar]

On Wed, Nov 05, 2008, David Flynn wrote:
> On 2008-11-05, Laurent Aimar <fenrir at via.ecp.fr> wrote:
> > On Wed, Nov 05, 2008, davidf+nntp at woaf.net wrote:
> > Packetizer:
> > -----------
> >> +    if( !p_block->i_pts && !date_Get( &p_sys->m_pts ) )
> >> +    if( p_block->i_pts )
> > You MUST use dts if pts is not provided. Some demuxer will only set
> > dts (like avi, or asf).
> 
> That does seem to be the opposite of mpeg2 semantics, whereby if dts
> is present, pts must be present.
 For mpeg yes, for a lot of demuxer, you never have PTS, so DTS only must
be supported.

> (infact i've got a patch for avi which sets PTS=DTS for the first
> block output by the avi demux, since in a reordered codec, you can't
> guess PTS from DTS; this at least allows some form of a/v sync -- and
> allows a decoder to interpolate the pts at its output.  The downside
> is that you can't correctly remux an avi stream to say mpeg2ts, but you
> couldn't do that anyway so no real loss)
 It cannot be used.
 For simple codec (ie at least not h264) you can deduce pts from dts on B
frames and assume pts == dts until you have one (yes you will have 1 jump
on the first B frame but I don't see any other choice).
 Anyway, a decoder MUST NOT interpolate all PTS from just the starting one
when it has access to DTS. Otherwise you will not ensure that you don't
drift.

 Letting the decoder handles the dts/pts recreation is better that faking a
wrong pts from a demuxer, as at least the decoder can use all informations it
has.

-- 
fenrir