[Ffmpeg-devel] Timestamps on Decoding

[Rich Felker]

On Sun, Oct 23, 2005 at 11:17:41AM -0400, Paul Curtis wrote:
> Rich Felker wrote:
> 
> >Neither. DTS is the decode timestamp, which is definitely NOT the
> >presentation timestamp (not even in the same order) unless the stream
> >contains no out-of-order frames.
> 
> At this point, I don't have any other choices. Without some indication 
> from either the codec or the demuxer, there is no way to determine the 
> actual frame timestamps. Since I haven't found any other value (on 
> decode) that can be used with reasonable accuracy, I'm forced to use the 
> DTS. It is not my first choice either ... I would much rather have the PTS.

Using DTS as PTS is blatently incorrect whenever there are B frames.
It will actually put the timestamps OUT OF ORDER!

> In reviewing the e-mails on this subject, and searching the lists, I 
> haven't found a single example of how to access the PTS across different 
> formats and codec. Since the decoder timestamp is present in the formats 
> I've tested, it will have to do.

It will make invalid files.

> I have found, however, that using the decoder timestamp as the basis for 
> the values to feed the Helix Producer encoder produces perfectly synced 
> RealMedia files, it is what I'm staying with. If someone has a better 
> solution, please post it.

If your files have no B frames, it's fine. If they do, all hell will
break loose and your files might randomly work with some broken
players, but the files you output will actually be highly invalid and
will not play in compliant players.

If you're decoding with a one-in, one-out decoder, getting PTS from
DTS is not too hard. When you input a frame with DTS "t", a frame with
PTS "t" will come out of the decoder. However this does not make
things very easy if you want to find PTS values to go with the
original encoded frames.

Unfortunately, the most common format (AVI) only has DTS and not PTS,
and there's no general way to convert DTS to PTS without processing
the codec-specific data in the frames themselves. The process of
getting PTS values (the way the decoder does it) involves reordering
the frames to display (presentation) order, which is fine if you're
decoding them and just intending to display them. But if you want to
keep them in decode order for remuxing into another container, it
requires lots of awkward buffering, and quite frankly I don't know a
proper way to do it... :(


Rich