[FFmpeg-user] PTS resolution

[Mark Filipak (ffmpeg)]

On 2021-02-23 00:01, Jim DeLaHunt wrote:
> 
> On 2021-02-22 18:53, Mark Filipak (ffmpeg) wrote:
>> Are these correct?
>>
>> ffmpeg PTS resolution is 1ms.…
> 
> This at least is not correct AFAIK.

Thanks, Jim. I certainly didn't expect such a lengthy response. I'll respond more verbosely.

> The Presentation Time Stamp (PTS) value which FFmpeg associates with video frames and audio data is 
> a 64-bit integer. There is an associated time base attribute for each video or audio stream, which 
> gives the number of seconds between successive values of PTS. This time base might be thought of as 
> the resolution of PTS. Thus if you have two PTS values pts1 and pts2, then the difference in seconds 
> between them is (pts2-pts1)*time_base.


MPEG PES (Presentation Elemental Stream) uses a 27MHz (exact) clock divided by 300 (exact), so that 
timebase is 1/(90000Hz) (which is 0.01[1..]ms between ticks, exactly). Thus, MPEG sources (found on 
DVDs & BDs) presents frames with PTS resolution = 0.01[1..]ms. In contrast, my best information so 
far is that, at least out of the encoder, ffmpeg encodes frames with PTS resolution = 1ms.

I see an unfortunate problem with ffmpeg's much lower PTS resolution that may help to explain quite 
a few of the non-CLI problems (i.e. internal problems) that I and others have with ffmpeg.

To put this into perspective, a 24fps video has delta-PTS = 41.[6..]ms whereas a 24/1.001fps video 
has delta-PTS = 41.708[3..]milliseconds. That means that the difference between the two is less than 
the resolution of the ffmpeg timebase (at least, for the encoder -- I don't know about the decoder 
and the pipeline). That essentially means that ffmpeg can't differentiate between them based on the 
working PTSs that it keeps.

I seek someone who can either, 1, confirm what I think, or 2, tell me what the resolution of the 
decoder and pipeline actually is.


> The time base can be represented as a rational number, e.g. 1001/30000. In this case, 31 frames 
> might have PTS values of 0, 1, 2, 3, …, 30. The difference in seconds between frame 31 and frame 1 
> is (30 - 0)*(1001/30000) = 1.001 seconds exactly. The PTS resolution is slightly under 1/30 second.
> 
> A different media stream might have a time base of of 1001/30,000,000. 31 frames might have PTS 
> values of 0, 1,000, 2,000, 3,000, …, 30,000. The difference in seconds between frame 31 and frame 1 
> is (30,000 - 0)*(1001/30,000,000) = 1.001 seconds exactly. The PTS resolution is slightly under 
> 1/30,000 second.
> 
> FFmpeg does not promise a relationship between the value of (pts*time_base) and wall clock time. 
> Some media streams could be authored with such a relationship, but FFmpeg does not enforce it.  If 
> two media streams have the same time base, and one stream has PTS values of 0, 1, 2, 3, and the 
> other has 422, 423, 424, 425, then FFmpeg should make the same presentation time calculations for 
> both streams.
> 
> This is all based on my limited reading of the source. There are many developers on this list who 
> know the source better than I do. Perhaps some of them might step in to correct whatever I got wrong.
> 
> Best regards,
>       —Jim DeLaHunt