tsmux produces timestamps with ~1hr offset

[Edward Hervey]

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