tsmux produces timestamps with ~1hr offset

[Krzysztof Konopko]

Thanks, that explains a lot.

Cheers,
Kris

On 13/11/12 11:36, Edward Hervey wrote:
> Hi,
> 
>   Those are PCR values. They are allowed to be any value whatsoever, and
> are not considered as *timestamps* but as references.
> 
>   Your "local playback timestamp" will be the difference between the PTS
> of the stream and the current PCR.
>   In this case, the first PCR is 1hour, and the first video PTS is 1hour
> also, therefore you do have a "local playback timestamp" of 0s (plays
> straight away).
> 
>   Your reader application should be able to support this (else it will
> not be able to read 99.9999999% of the mpeg-ts files out there).
> 
>     Edward
> 
> On Tue, 2012-11-13 at 10:06 +0000, Krzysztof Konopko wrote:
>> Hi,
>>
>> The following will produce a test TS stream:
>>
>> gst-launch \
>>   videotestsrc num-buffers=10 \
>>   ! mpeg2enc ! mpegtsmux \
>>   ! filesink location=test.ts
>>
>> Now if I inspect produced TS packets with dvbsnoop [1], I can see that
>> the first TS packet has a ~1hr offset:
>>
>> dvbsnoop -s ts -tssubdecode -if test.ts | grep -i time | less
>>
>> ==> program_clock_reference: 97196625000 (0x16a15ecc68)  [=
>> PCR-Timestamp: 0:59:59.875000]
>>  ==> PTS: 324000000 (0x134fd900)  [= 90 kHz-Timestamp: 1:00:00.0000]
>> time_code:
>>  time_code_hours: 0 (0x00)
>>  time_code_minutes: 0 (0x00)
>>  time_code_seconds: 0 (0x00)
>>  time_code_pictures: 0 (0x00)
>>    ==> PTS: 324002999 (0x134fe4b7)  [= 90 kHz-Timestamp: 1:00:00.0333]
>> ==> program_clock_reference: 97198424700 (0x16a17a427c)  [=
>> PCR-Timestamp: 0:59:59.941655]
>>    ==> PTS: 324005999 (0x134ff06f)  [= 90 kHz-Timestamp: 1:00:00.0666]
>>    ==> PTS: 324009000 (0x134ffc28)  [= 90 kHz-Timestamp: 1:00:00.1000]
>> ==> program_clock_reference: 97200224700 (0x16a195b9bc)  [=
>> PCR-Timestamp: 1:00:00.008322]
>>    ==> PTS: 324011999 (0x135007df)  [= 90 kHz-Timestamp: 1:00:00.1333]
>>    ==> PTS: 324014999 (0x13501397)  [= 90 kHz-Timestamp: 1:00:00.1666]
>> ==> program_clock_reference: 97202025000 (0x16a1b13228)  [=
>> PCR-Timestamp: 1:00:00.075000]
>>    ==> PTS: 324018000 (0x13501f50)  [= 90 kHz-Timestamp: 1:00:00.2000]
>>    ==> PTS: 324020999 (0x13502b07)  [= 90 kHz-Timestamp: 1:00:00.2333]
>> ==> program_clock_reference: 97203824700 (0x16a1cca83c)  [=
>> PCR-Timestamp: 1:00:00.141655]
>>    ==> PTS: 324023999 (0x135036bf)  [= 90 kHz-Timestamp: 1:00:00.2666]
>>    ==> PTS: 324027000 (0x13504278)  [= 90 kHz-Timestamp: 1:00:00.3000]
>>
>>
>> It looks like the following code is responsible for that
>> (tsmux_write_stream_packet()):
>>
>>     /* FIXME: The current PCR needs more careful calculation than just
>>      * writing a fixed offset */
>>     if (cur_pts != -1) {
>>       /* CLOCK_BASE >= TSMUX_PCR_OFFSET */
>>       cur_pts += CLOCK_BASE;
>>       cur_pcr = (cur_pts - TSMUX_PCR_OFFSET) *
>>           (TSMUX_SYS_CLOCK_FREQ / TSMUX_CLOCK_FREQ);
>>     }
>>
>> Gstreamer-0.10.x produces TS packets without the offset so it looks like
>> a regression. Is there any bug reported? Or maybe there's some
>> explanation of this situation? Or maybe it doesn't matter at all in
>> practice?
>>
>> [1] http://dvbsnoop.sourceforge.net
>>
>> Cheers,
>> Kris
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> 
>