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

Lucas Soltic lucas.soltic at orange.fr
Sat Mar 29 01:52:30 CET 2014

> 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?".


More information about the Libav-user mailing list