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

[Lucas Soltic]

> Le 29 mars 2014 à 02:24, wm4 <nfxjfg at googlemail.com> a écrit :
> 
> 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.)
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

Oh ok.. is there a list or something to know which formats do support well seeking, and which format really don't support this at all (except with indexing) ? I don't plan to work with network streams for now so I guess transport streams are not a problem for me.


Thanks a lot for your help :)
Lucas