PTS resolution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PTS resolution

Mark Filipak (ffmpeg)
Are these correct?

ffmpeg PTS resolution is 1ms.
DVD & BD PTS resolution is 0.01[1..]ms (i.e. 90x).
The PTS difference between 24Hz & 23.976Hz is 0.0416[6..]ms.
The PTS difference between 30Hz & 29.970Hz is 0.03[3..]ms.

Thanks,
Mark.

--
In the 1970s, a year at Ohio State Univ = 1 month of minimum wage earnings.
In the 2020s, a year at Ohio State Univ = 1+ year of minimum wage earnings.
In the 1970s, most jobs were manufacturing, corporate taxes were fair.
In the 2020s, most jobs are service, corporate taxes are nearly nonexistent.
The U.S. standard of living has plummeted; the wealth gap is now a canyon.
In the future, robots will supply the ultimate in slave labor.
The coming crisis is here. Beam me up, Scotty!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Jim DeLaHunt-2

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.

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.

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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Carl Zwanzig
In reply to this post by Jim DeLaHunt-2
(just saw Mark's latest as I was about to press send)

On 2/22/2021 9:01 PM, Jim DeLaHunt wrote:
> The time base can be represented as a rational number, e.g. 1001/30000

Usually expressed as the frame rate- 30000/1001 (for NTSC).

If you're starting with mpeg-ps or -ts, 'Presentation time stamps have a
resolution of 90kHz", so at 29.97fps the PTSs should be 3003.003... apart.
Since they're whole numbers, that would be 3003, 6006, etc with an extra +1
every 333 frames.


Jim says: The PTS resolution is slightly under 1/30,000 second.

That suggests ffmpeg is only using 1/3 the resolution available to the mpeg
formats, of am I misunderstanding something? (I don't have time to dive into
the code at the moment.)


There's also some interesting stuff at
http://dranger.com/ffmpeg/tutorial05.html
http://cseweb.ucsd.edu/classes/sp03/cse228/ (old, but should be useful)

and
"Understanding Timelines within MPEG Standards" (looks technically intense)
https://ir.cwi.nl/pub/23650/23650B.pdf
which I'll read in the next few days.

Later,


z!

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Mark Filipak (ffmpeg)
On 2021-02-23 00:41, Carl Zwanzig wrote:
-snip-
> If you're starting with mpeg-ps or -ts, ...

There's no such thing as PTS in mpeg-ts. The transport stream sets the SCR (System Clock Reference)
(aka TB) but the PTSs are in the presentation stream, stored as integer ticks of the SCR.

I've been told (at doom9.org) that MKV (which is a TS) stores PTSs but I find that hard to believe.

>... 'Presentation time stamps have a resolution of 90kHz", so at
> 29.97fps the PTSs should be 3003.003... apart. Since they're whole numbers, that would be 3003,
> 6006, etc with an extra +1 every 333 frames.

Are those MPEG SCR counts or ffmpeg TB counts? Let's see...
1001/30000 = 33.3[6..]ms.
1/90000 = 0.011[1..]ms.
33.3[6..]/0.011[1..] = 3003 (exactly), so you are a little bit off.

> Jim says: The PTS resolution is slightly under 1/30,000 second.
>
> That suggests ffmpeg is only using 1/3 the resolution available to the mpeg formats, of am I
> misunderstanding something? (I don't have time to dive into the code at the moment.)
>
>
> There's also some interesting stuff at
> http://dranger.com/ffmpeg/tutorial05.html
> http://cseweb.ucsd.edu/classes/sp03/cse228/ (old, but should be useful)
>
> and
> "Understanding Timelines within MPEG Standards" (looks technically intense)
> https://ir.cwi.nl/pub/23650/23650B.pdf
> which I'll read in the next few days.
>
> Later,
>
>
> z!
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".


--
In the 1970s, a year at Ohio State Univ = 1 month of minimum wage earnings.
In the 2020s, a year at Ohio State Univ = 1+ year of minimum wage earnings.
In the 1970s, most jobs were manufacturing, corporate taxes were fair.
In the 2020s, most jobs are service, corporate taxes are nearly nonexistent.
The U.S. standard of living has plummeted; the wealth gap is now a canyon.
In the future, robots will supply the ultimate in slave labor.
The coming crisis is here. Beam me up, Scotty!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Mark Filipak (ffmpeg)
On 2021-02-23 01:08, Mark Filipak (ffmpeg) wrote:
> On 2021-02-23 00:41, Carl Zwanzig wrote:
-snip-
>> ... 'Presentation time stamps have a resolution of 90kHz", so at 29.97fps the PTSs should be
>> 3003.003... apart. Since they're whole numbers, that would be 3003, 6006, etc with an extra +1
>> every 333 frames.
>
> Are those MPEG SCR counts or ffmpeg TB counts? Let's see...
> 1001/30000 = 33.3[6..]ms.
> 1/90000 = 0.011[1..]ms.
> 33.3[6..]/0.011[1..] = 3003 (exactly), so you are a little bit off.

You know, MPEG uses a 90KHz SCR (27MHz/300) for a good reason. The reason is so that all valid frame
rates (e.g. 30fps v. 30/1.001fps) come out as whole integers (not fractional).

The question is: What does ffmpeg use as its TB in the decoder and pipeline?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Carl Zwanzig
In reply to this post by Mark Filipak (ffmpeg)

You missed mentioning the program clock reference (PCR) of the -ts. -And-
many references to PTS directly say that it's contained in a -ts (which if
the -ts contains a -ps, is correct).


> The question is: What does ffmpeg use as its TB in the decoder and
> pipeline?
Read the source code? It's going to be in there somewhere.

z!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Mark Filipak (ffmpeg)
On 2021-02-23 01:38, Carl Zwanzig wrote:
>
> You missed mentioning the program clock reference (PCR) of the -ts. -And- many references to PTS
> directly say that it's contained in a -ts (which if the -ts contains a -ps, is correct).

The answers are in a GIF illustration (not text) in the H.262 spec, so searching the PDF doesn't
find any hits. From the GIF,

In the encoder:
STC (System Time Clock) is 27MHz.
PTC is (STC counter value)+(fixed buffer delay) that's written into the PS at the start of each
frame. [1]
PCR (Program Clock Reference) is (STC counter value) that's written into the TS (in the muxer) every
100ms.
In the decoder:
STC (System Time Clock) is 27MHz.
There are no counters in the decoder. There's a STC-PTS comparator to signal new frames and a
STC-PCR comparator to control the STC's phase lock loop.

[1] Why the GIF leaves out the by-300 PTS divider is a mystery, but I know it exists (i.e., PTS
resolution = 1/(27MHz/300).

>
>
>> The question is: What does ffmpeg use as its TB in the decoder and
>> pipeline?
 >
> Read the source code? It's going to be in there somewhere.

But I don't like SPAM! -- I don't read 'C'.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Gyan Doshi-2


On 23-02-2021 12:40 pm, Mark Filipak (ffmpeg) wrote:

> On 2021-02-23 01:38, Carl Zwanzig wrote:
>>
>> You missed mentioning the program clock reference (PCR) of the -ts.
>> -And- many references to PTS directly say that it's contained in a
>> -ts (which if the -ts contains a -ps, is correct).
>
> The answers are in a GIF illustration (not text) in the H.262 spec, so
> searching the PDF doesn't find any hits. From the GIF,
>
> In the encoder:
> STC (System Time Clock) is 27MHz.
> PTC is (STC counter value)+(fixed buffer delay) that's written into
> the PS at the start of each frame. [1]
> PCR (Program Clock Reference) is (STC counter value) that's written
> into the TS (in the muxer) every 100ms.
> In the decoder:
> STC (System Time Clock) is 27MHz.
> There are no counters in the decoder. There's a STC-PTS comparator to
> signal new frames and a STC-PCR comparator to control the STC's phase
> lock loop.
>
> [1] Why the GIF leaves out the by-300 PTS divider is a mystery, but I
> know it exists (i.e., PTS resolution = 1/(27MHz/300).

Our demuxer/muxer only read the top 33-bits (so TB is set at 90kHz). The
bottom 9-bits are ignored, last time I checked. There's 6 bits of
padding in between.

>>
>>
>>> The question is: What does ffmpeg use as its TB in the decoder and
>>> pipeline?

There is no fixed timebase used by ffmpeg. Decoders will set timebase of
emitted frames based on the bitsteam. Filters will use that unless they
set it based on user input or processing.
As a fallback when not set, modules may usually set it to 1/1000000.

Regards,
Gyan
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Mark Filipak (ffmpeg)
On 2021-02-23 02:46, Gyan Doshi wrote:

>
>
> On 23-02-2021 12:40 pm, Mark Filipak (ffmpeg) wrote:
>> On 2021-02-23 01:38, Carl Zwanzig wrote:
>>>
>>> You missed mentioning the program clock reference (PCR) of the -ts. -And- many references to PTS
>>> directly say that it's contained in a -ts (which if the -ts contains a -ps, is correct).
>>
>> The answers are in a GIF illustration (not text) in the H.262 spec, so searching the PDF doesn't
>> find any hits. From the GIF,
>>
>> In the encoder:
>> STC (System Time Clock) is 27MHz.
>> PTC is (STC counter value)+(fixed buffer delay) that's written into the PS at the start of each
>> frame. [1]
>> PCR (Program Clock Reference) is (STC counter value) that's written into the TS (in the muxer)
>> every 100ms.
>> In the decoder:
>> STC (System Time Clock) is 27MHz.
>> There are no counters in the decoder. There's a STC-PTS comparator to signal new frames and a
>> STC-PCR comparator to control the STC's phase lock loop.
>>
>> [1] Why the GIF leaves out the by-300 PTS divider is a mystery, but I know it exists (i.e., PTS
>> resolution = 1/(27MHz/300).
>
> Our demuxer/muxer only read the top 33-bits (so TB is set at 90kHz). The bottom 9-bits are ignored,
> last time I checked. There's 6 bits of padding in between.

I can scarcely overestimate how important this is.

Please clarify: ffmpeg ignores the bottom 9 bits of the PTS?

BTW, the PTS is part of the PES_HEADER_EXTENSION. A PES_HEADER occurs in each sector (2048 bytes) of
the TS, but a PES_HEADER_EXTENSION occurs only at the beginning of each frame, so I consider PTS
part of the presentation stream, not the transport stream. Your mileage may vary and opposing
opinions are entertained (though wrong).
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Mark Filipak (ffmpeg)
In reply to this post by Gyan Doshi-2
Attached are manual parses of sectors 1 & 2 of the DVD "RUNNING ON EMPTY". I'm attaching them
because there's 6200 characters in some of the lines.

I've gathered together the work of other people (cited within) and made some corrections.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

p24t24 RUNNING ON EMPTY, 085391184324, VTS_01_1.VOB, sector 000001 manually_parsed.txt (84K) Download Attachment
p24t24 RUNNING ON EMPTY, 085391184324, VTS_01_1.VOB, sector 000002 manually_parsed.txt (59K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-22 21:35, Mark Filipak (ffmpeg) wrote:

> On 2021-02-23 00:01, Jim DeLaHunt wrote:
>> 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)…
I've read something similar. My understanding is that MPEG PES encodes
Presentation Time Stamp values as integer tick counts in the data
stream. Is the timebase of 1/(90,000Hz) encoded in the data stream, or
it is only defined in the spec?
> …(which is 0.01[1..]ms between ticks, exactly).
Actually, for this discussion I think it's fair to say that 0.01[1..]ms
is not exactly 1/90 ms, it is just an approximation. Finite decimal
numbers will never get you the exact value. The rational number is
exact. For this discussion, it will be clearer to use exact rational
numbers.
> …my best information so far is that, at least out of the encoder,
> ffmpeg encodes frames with PTS resolution = 1ms.

My impression from reading the FPS filter source code is that it is
incomplete to talk about ffmpeg PTS values without also giving the
corresponding timebase value. It looks to me like the FPS filter does
not attempt to preserve the incoming PTS values or timebase. It sets a
new time base of 1/frame_rate, and generates successive integer values
for PTS. However, and this is crucial, it does seem to value being exact
about the value of PTS*time_base.

So, that seems to say that your statement "at least out of the encoder,
ffmpeg encodes frames with PTS resolution = 1ms" is not complete without
stating the time base value ffmpeg sets out of the encoder.

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

But what are the time base values which ffmpeg uses for these two
cases?  If the time base is 1/24 in the first case, and 1,001/24,000 in
the second case, then the same integer PTS values result in
PTS*time_base products being exactly the correct time offsets from the
first frame of the video in each of the two cases.


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

Implicit in your use of the definite article "the" is an apparent
assumption that FFmpeg has only one resolution for the decoder and the
pipeline. It looks to me like FFmpeg could well take the liberty of
changing resolution at each stage of decoder and pipeline, as long as it
preserves the values for PTS*time_base at each frame (or modifies them
intentionally, as the FPS filter does).

Best regards,
      —Jim DeLaHunt

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote
> On 2021-02-23 00:41, Carl Zwanzig wrote:
> -snip-
>> If you're starting with mpeg-ps or -ts, ...
>
> There's no such thing as PTS in mpeg-ts. The transport stream sets the SCR
> (System Clock Reference)
> (aka TB) but the PTSs are in the presentation stream, stored as integer
> ticks of the SCR.

There is no such thing as /external/ timestamps, or container timestamps for
MPEG-TS that govern the timing. Nor are there external timestamps  any CFR
container formats such as AVI. For AVI and MPEG-TS, MPEG-PS - the content
can be VFR (using field or frame repeats), but the container is CFR only.
Each coded frame cannot have variable display times in within a GOP.  




> I've been told (at doom9.org) that MKV (which is a TS) stores PTSs but I
> find that hard to believe.

Then read the MKV documentation, section 16 "External Timestamp Files".

MKV is a container format. "TS" is usually reserved to denote for MPEG2-TS
"TS for Transport Stream" (such as .ts, .m2ts, .mts) , not so loosely as any
container stream.

FFMpeg and modern video container formats have to be able to handle VFR
without coding field or frame repeats - External timestamps are how PTS are
controlled. This is what video players use to control playback. When you
extract PTS from MKV using mkvextract or ffprobe, that's what you're getting
- an external timestamps file. When you multiplex in timestamps file with
mkvmerge, that's what you 're using - an external timestamps file. MP4, MOV,
FLV, also use this method.











--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Mark Filipak (ffmpeg)
In reply to this post by Jim DeLaHunt-2
On 2021-02-23 03:58, Jim DeLaHunt wrote:

> On 2021-02-22 21:35, Mark Filipak (ffmpeg) wrote:
>
>> On 2021-02-23 00:01, Jim DeLaHunt wrote:
>>> 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)… >
> I've read something similar. My understanding is that MPEG PES encodes Presentation Time Stamp
> values as integer tick counts in the data stream. Is the timebase of 1/(90,000Hz) encoded in the
> data stream, or it is only defined in the spec?

The decoder is *assumed* to have a 90KHz timebase. Otherwise, the decode will not be correct. The
idea of manipulating the timebase is a creation of programmers. The timebase is hardware: a 27MHz
oscillator, followed by more hardware: a by-300 divider, followed by more hardware: a 33-bit counter
that produces a 33-bit binary number that's called PTS. The 33-bit counter is zeroed at the
beginning of the stream and is copied out at the beginning of each frame. Making the timebase
something different is like saying, "Let's make the wall clock's second a half a second." Doing that
doesn't make actual time speed up except maybe in "THE MATRIX".

>> …(which is 0.01[1..]ms between ticks, exactly).

> Actually, for this discussion I think it's fair to say that 0.01[1..]ms is not exactly 1/90 ms, it
> is just an approximation. ...

No, it's exactly 1/(90000Hz) == 0.011[1..] milliseconds.

>... Finite decimal numbers will never get you the exact value. ...

The 90KHz is as accurate as the 27MHz oscillator that drives it. A 27MHz crystal oscillator
oscillates (1 cycle) every 37.037[037..] nanoseconds. To give you an idea of how little it jitters,
consider this: The receiving decoder has its own 27MHz oscillator that is synchronized to the
encoder's recorded 27MHz oscillator count just 10 times per second -- *that* number (i.e. the count
at which synchronization occurs) is called "PCR". Between synchronization times, the decoder's
oscillator free runs. That it's sync'ed every 1/10th second means that it free runs for 2.7 million
oscillations -- in other words, it free runs for 2699999 parts out of 2700000 parts (i.e.
+/-0.00001.85[185..] percent). During that free run, it drifts a bit based on the Quality Factor and
cut of the crystal, the crystal trimming, the temperature, air pressure, the phase of the moon
...just kidding on that last one (or maybe not).

>... The rational
> number is exact. For this discussion, it will be clearer to use exact rational numbers.

Compared to the silken accuracy of a phase locked crystal oscillator system, your rational numbers
are stone hammers.

>> …my best information so far is that, at least out of the encoder, ffmpeg encodes frames with PTS
>> resolution = 1ms.
>
> My impression from reading the FPS filter source code is that it is incomplete to talk about ffmpeg
> PTS values without also giving the corresponding timebase value. ...

Except in "THE MATRIX", the timebase is 90KHz +/-0.00001.85%. Changing the timebase to something
else is a programming construct and is not real. That number should not have been called a time
base. It should have been called a time base divider. Thinking that by changing that number the
programmers are changing the actual time base is delusional. What they're doing is introducing
fractional errors in their calculations that occur when their "time base" isn't a whole multiple of
the real time base. You know, just because you can poke numbers into a 'C' struct doesn't mean those
numbers are real.

>... It looks to me like the FPS filter
> does not attempt to preserve the incoming PTS values or timebase. ...

Yes, that's what 'fps=<a number>' does. But remember, changing the actual time base is something
that's solely in "THE MATRIX".

Let me explain it like this:
What's the difference between 30fps and 30/1.001fps?
The difference is:
for 30fps, the current time base count is updated every 33.33[3..]ms, while
for 30/1.001fps, it is updated every 33.36[6..]ms.
(Note that the difference between them is smaller than 1ms.)
For a 90KHz time base, those numbers (i.e. PTSs) are,
for 30fps, '3000', and
for 30/1.001fps, '3003'.
Those are the only real numbers that matter.
In other words, the real time base (90KHz) and the real PTS differences ('3000' vs. '3003') are
producing effects that ffmpeg's bogus time base (1KHz) can't resolve because it can't 'see' a
difference of less than 1ms (i.e. the difference between 30fps and 30/1.001fps).

Do you 'get it'? I know it's hard, but that's the reality of life outside "THE MATRIX".

>... It sets a new time base of
> 1/frame_rate, and generates successive integer values for PTS. However, and this is crucial, it does
> seem to value being exact about the value of PTS*time_base.
>
> So, that seems to say that your statement "at least out of the encoder, ffmpeg encodes frames with
> PTS resolution = 1ms" is not complete without stating the time base value ffmpeg sets out of the
> encoder.

Software cannot change the real time base.

>> 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.
>
> But what are the time base values which ffmpeg uses for these two cases?  If the time base is 1/24
> in the first case, and 1,001/24,000 in the second case, then the same integer PTS values result in
> PTS*time_base products being exactly the correct time offsets from the first frame of the video in
> each of the two cases.

First, remember this:
For 30fps, delta-PTS = '3000', and
For 30/1.001fps, delta-PTS = '3003'.
Both are whole numbers.

For 24fps, delta-PTS = '3750'.
For 24/1.001fps, delta-PTS would be '3753.75' except that PTS must be a whole number, so I'd say
that 24/1.001fps is a bogus frame rate that exists solely in "THE MATRIX", not in real life.
So what happens if PTS is forced to '3754' to produce pseudo 24/1.001fps? I'd say the answer is:
playback and/or processing errors.

ASIDE: Frankly, the unreality of 24/1.001fps comes as a surprise to me. I had assumed (until a
couple of lines back) that 24/1.001fps was a real possibility in real video systems. I even have it
in my working documentation, i.e. that 24/1.001fps plays movies 0.1% slow, analogous to 24fps played
back at 25fps (PAL TV) being 4% fast (which I know is real). The difference is that a 4% PAL sped up
is real but a 0.1% slow down isn't real. The reason I didn't realize that 24/1.001fps is not real is
that, until a few lines back, I'd never run the numbers on it. I will correct my working
documentation to reflect that fact.

Yes, I know I can do this: '-vf fps=24000/1001' but that doesn't make it real.

Bottom line: The number or fraction that's poked into an 'fps' filter has to be real. Otherwise,
there will be problems. The number or fraction that's poked into an 'fps' filter has to be from a
limited set of real frame rates that fit the MPEG encoder-decoder model that's in the H.262
specification and that produce integer delta-PTSs.

The added requirement is that the ffmpeg decoder and pipeline have the resolution need to reproduce
the MPEG encoder-decoder model -- and that ain't 1ms, it's 0.011[1..]ms.

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

I think I've shown that the ffmpeg decoder and pipeline probably has higher resolution than 1ms, but
what it actually is remains a mystery.

> Implicit in your use of the definite article "the" is an apparent assumption that FFmpeg has only
> one resolution for the decoder and the pipeline. It looks to me like FFmpeg could well take the
> liberty of changing resolution at each stage of decoder and pipeline, as long as it preserves the
> values for PTS*time_base at each frame (or modifies them intentionally, as the FPS filter does).

Your observation is sound. What's important is how fine the pipeline timing can be set, not how many
digits PTS contains. From a general engineering standpoint, ffmpeg should use a time base that's
0.011[1..]ms or finer. Delta-PTS resolution that's less than 0.011[1..]ms will absolutely result in
playback and/or processing errors. How you find delta-PTS resolution in the source code is unknown.

> Best regards,
>       —Jim DeLaHunt
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".


--
In the 1970s, a year at Ohio State Univ = 1 month of minimum wage earnings.
In the 2020s, a year at Ohio State Univ = 1+ year of minimum wage earnings.
In the 1970s, most jobs were manufacturing, corporate taxes were fair.
In the 2020s, most jobs are service, corporate taxes are nearly nonexistent.
The U.S. standard of living has plummeted; the wealth gap is now a canyon.
In the future, robots will supply the ultimate in slave labor.
The coming crisis is here. Beam me up, Scotty!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Rob Hallam-2
On Tue, 23 Feb 2021 at 17:55, Mark Filipak (ffmpeg) <[hidden email]>
wrote:
> [ information on PTS ]

Interesting information, thank you for sharing those insights.

Without wanting to cast aspersions, does this mean that ffmpeg does
something different with regards to timestamps than the MPEG spec?

If this is the case, is it possible to quantify the difference, at least to
an order of magnitude?

Asking out of idle curiosity as the description of the hardware and spec
piqued my interest.

Cheers,
Rob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Carl Eugen Hoyos-2
Am Di., 23. Feb. 2021 um 19:24 Uhr schrieb Rob Hallam <[hidden email]>:

> Without wanting to cast aspersions, does this mean that ffmpeg does
> something different with regards to timestamps than the MPEG spec?

This is very, very unlikely:
FFmpeg has been used for more than a decade to produce DVD
streams, and it is known to produce compliant streams.

If you disregard that fact that FFmpeg completely disregards soft-
telecine (which has no meaning on devices where FFmpeg libraries
can decode something), decoding is also known to be compliant.

Carl Eugen, who wonders how to avoid such threads
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

Carl Eugen Hoyos-2
In reply to this post by Mark Filipak (ffmpeg)
Am Di., 23. Feb. 2021 um 06:39 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:

> at least out of the encoder, ffmpeg encodes frames with PTS resolution = 1ms.

(Since people may be reading this)
To quote Wolfgang Pauli, above is not even wrong.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote
> In contrast, my best information so far is that, at least out of the
> encoder, ffmpeg encodes frames with PTS resolution = 1ms.

Not true;

Check the timestamps at each step. Decoding, prefilter, postfilter after
each filter, postencode. If you need to check timestamps inbetween filters,
use -vf showinfo.

If you export use a container timebase of 1/1000s such as mkv, then yes, you
are limited beacuse of the container timebase. That has nothing to do with
ffmpeg. If you've "ripped" a dvd using makemkv, for input into ffmpeg then
you start with a timebase of 1/1000s. That's not ffmpeg's fault either

The container timebase for a MPEG2-PS is 90K (or 1/90000s) .ie.  ffmpeg -i
input.vob tbn is 90k

tb:1/90000 fr:30000/1001 sar:8/9
pts_time:0
pts_time:0.0333556
pts_time:0.0667222
pts_time:0.100089

(it's still wrong, it should have been )
tb:1/90000 fr:30000/1001 sar:8/9
pts_time:0
pts_time:0.0333667
pts_time:0.0667333
pts_time:0.1001

But the point is the "resolution" is finer than 1ms from decoding

But if you use DVD in MKV container input, the timebase reduces the "finer"
resolution to 1ms
tb:1/1000 fr:19001/317 sar:8/9
pts_time:0
pts_time:0.033
pts_time:0.067
pts_time:0.1







--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-23 09:51, Mark Filipak (ffmpeg) wrote:

> …Except in "THE MATRIX", the timebase is 90KHz ±0.00001.85%. Changing
> the timebase to something else is a programming construct and is not
> real.…


Mark, I think your original question was:

On 2021-02-22 18:53, Mark Filipak (ffmpeg) wrote:

> Are these correct?
>
> ffmpeg PTS resolution is 1ms.…


You asked a question about FFmpeg's behaviour, about its PTS resolution.
I think the answer is partly that FFmpeg has a timebase which is an
attribute of the (video) stream, and which can take different values.  I
will point out that FFmpeg is indeed a "programming construct".

If you want to dismiss FFmpeg's behaviour as "THE MATRIX", go ahead. But
that is a different thread, so please change the subject line.

If you still want to understand whether it is correct that "ffmpeg PTS
resolution is 1ms", then let's continue this thread.

Best regards,
      —Jim DeLaHunt


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: PTS resolution[s]

Mark Filipak (ffmpeg)
In reply to this post by Rob Hallam-2
On 2021-02-23 13:17, Rob Hallam wrote:
> On Tue, 23 Feb 2021 at 17:55, Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>> [ information on PTS ]
>
> Interesting information, thank you for sharing those insights.
>
> Without wanting to cast aspersions, does this mean that ffmpeg does
> something different with regards to timestamps than the MPEG spec?

Hey Rob,

Without knowing the decoder and pipeline delta-PTS resolution [1], I can't say for sure. What I can
say is that ffmpeg reports "1k tbn". I'm unsure what 'tbn' means but others have said that it means
"time base number" [2]. If 'tbn' is used in calculations as a surrogate for MPEG's 90KHz time base,
then I'd say that 1ms resolution is too small to prevent errors -- it would need to be no larger
than 0.01[1..]ms but could/should be even finer (in order to prevent accumulated error in chained
calculations).

[1] MPEG keeps PTS as a 33-bit value. Because the MPEG time base clock runs at 90KHz (i.e. the 27MHz
system time clock divided by 300), then the smallest possible frame-to-frame delta-PTS represents
0.011[1..]ms in time. Real examples: Changing delta-PTS from '3003' to '3000' is a frame-to-frame
change of 33.36[6..]ms to 33.33[3..]ms (which, as frame rates, is 30fps to 29.970fps). (Note that
33.36[6..]ms = 33.33[3..]ms + 0.011[1..]ms + 0.011[1..]ms + 0.011[1..]ms.)

[2] The meanings of 'tbr', 'tbn', and 'tbc' were the subjects of my very first posting to
ffmpeg-users back on 2019-09-29, subject: "Two initial questions". I got no answer then, and I've
not gotten a precise answer since. Oh, I've since gotten vague musings, but it appears that this
whole subject is quite murky to everyone. I accepted the situation because "those ffmpeg folks must
be awfully experienced, so I'll just hang out until I learn more". Based on (bogus, abusive)
reactions here and (courteous, more informed but still murky) discussions at doom9.org, well, I
guess I've lost my patience. Sorry.

> If this is the case, is it possible to quantify the difference, at least to
> an order of magnitude?
>
> Asking out of idle curiosity as the description of the hardware and spec
> piqued my interest.

You have just pulled the tubes out of your arms, my friend, and you are now ready to face the
implications of "THE MATRIX".

Let me expound a little further, eh?
If 30fps produces a delta-PTS of '3000' and 29.970 produces a delta-PTS of '3003', then what does a
delta-PTS of '3001' produce? (And is it possible? And is it valid?).
Yes, it is programmatically possible.
A delta-PTS of '3001' produces time stamps as though from a 29.99000333222259246917694101966fps video.
Will such a video play properly? Probably, but maybe not if burned to a DVD and popped into a DVD
player. MPEG's 'frame_rate_code' metadata allows for: '24/1.001', '24', '25', '30/1.001', '30',
'50', '60/1.001', and '60'. It doesn't allow for '30/1.0003[3..]', but a player will probably play
30fps and ignore the PTSs (or will ignore 'frame_rate_code' and 'play' the PTSs).
Is it valid? No.
And the biggest question: If those PTSs are further manipulated in chained calculations, what will
happen? I think errors happen. I think jitter happens. I think busted transcodes happen. I think
out-of-sync audio happens. I think scripts that have worked for a year but that break on particular
use cases happen.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12