[FFmpeg-user] 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).