[Libav-user] av_frame_get_best_effort_timestamp(): PTS or DTS?

[wm4]

On Sat, 29 Mar 2014 01:52:30 +0100
Lucas Soltic <lucas.soltic at orange.fr> wrote:

> > Le 29 mars 2014 à 01:34, wm4 <nfxjfg at googlemail.com> a écrit :
> > 
> > On Sat, 29 Mar 2014 00:49:18 +0100
> > Lucas Soltic <lucas.soltic at orange.fr> wrote:
> > 
> >>> Le 28 mars 2014 à 22:04, wm4 <nfxjfg at googlemail.com> a écrit :
> >>> 
> >>> On Fri, 28 Mar 2014 21:19:55 +0100
> >>> Lucas Soltic <lucas.soltic at orange.fr> wrote:
> >>> 
> >>>> Hello!
> >>>> 
> >>>> Does av_frame_get_best_effort_timestamp() gives a PTS or DTS?
> >>>> 
> >>>> At first I would have thought it's a PTS, because it's impossible for decoding to correctly happen if DTS does not exist in the packet, but then I read that the packet DTS may be AV_NOPTS_VALUE (DTS being a NOPTS..??!). If that is correct, is there a reliable way to know the DTS too (in the core meaning of DTS, even if the file does not set it)?
> >>> 
> >>> Some files have PTS and DTS mixed (mpeg mostly), some files have PTS
> >>> only (e.g. Matroska), some files have DTS only (e.g. AVI). The general
> >>> solution is to use DTS if PTS is set to NOPTS.
> >>> 
> >>> Here's how av_frame_get_best_effort_timestamp() is calculated:
> >>> 
> >>> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utils.c;h=b43f67540e834d45058f9d694cc6c090d1b4c27d;hb=HEAD#l1995
> >>> 
> >>> Looks complicated, but is rather simple. As I understand, this is
> >>> mostly a workaround if PTS or DTS are set incorrectly. 
> >>> 
> >>> 
> >>> This function takes AVFrame.pkt_pts and AVFrame.pkt_dts as inputs. It
> >>> returns what will be used as AVFrame.best_effort_timestamp. What this
> >>> function does is:
> >>> 
> >>> 1. count how often it happens that PTS or DTS are not monotonic
> >>>  (normally, the DTS _and_ PTS should not decrease after the decoder;
> >>>  this is not true _before_ the decoder, but the decoder should
> >>>  reorder them so that they're monotonic, and some broken files might
> >>>  violate this)
> >>> 2. if PTS is more often wrong than DTS, use the DTS as output timestamp
> >>> 
> >>> Libav does not have the AVFrame.best_effort_timestamp field. Butthe
> >>> Libav command line tools (avplay, avconv) calculates it the same way:
> >>> 
> >>> https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=69a11bdd4fb33ccdc1420e15edb7c47c8ce84098;hb=HEAD#l1431
> >>> 
> >>> And that's why I would recommend just copying the code. It's trivial
> >>> anyway, at least once you understand it, and your project will be
> >>> compatible to both FFmpeg and Libav.
> >>> _______________________________________________
> >>> Libav-user mailing list
> >>> Libav-user at ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/libav-user
> >> 
> >> Thanks for all your answers :)
> >> 
> >> So... to sum it up, some formats have DTS or PTS or both. I guess no file has none?
> > 
> > I guess it's not impossible that some files have no or just broken
> > timestamps. But with "normal" files this usually doesn't happen.
> > 
> >> Then if I want to seek, I saw that some demuxers seek by PTS, others by DTS, depending on whether AVFMT_SEEK_TO_PTS is set.
> >> 
> >> If the format only has DTS, will AVFMT_SEEK_TO_PTS never be set?
> >> If the format only has PTS, will AVFMT_SEEK_TO_PTS always be set?
> >> If AVFMT_SEEK_TO_PTS is set, are the PTS provided by the format reliable?
> >> If AVFMT_SEEK_TO_PTS is not set, are the DTS provided by the format reliable?
> > 
> > I don't think you should try to conclude anything from these flags.
> > They're probably mostly for the libavformat internal seek code.
> > _______________________________________________
> > Libav-user mailing list
> > Libav-user at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/libav-user
> 
> Well.. the purpose is not really to make deductions but just to make sure there is no inconsistency. If a format requires to seek by PTS when the same format has no pts is clearly an error.
> 
> As for the last two questions, the point rather was "is there always a reliable way to seek?".

From my experience, seeking often goes wrong. For file formats that
were not designed for seeking (like transport streams etc.), you can be
lucky if seeking works well enough for your purposes.

If you want 100% reliable seeking, you'll have to decode the whole file
and index it, or something like this. (Libraries like ffms2 do this for
you.)