tsmux produces timestamps with ~1hr offset

Krzysztof Konopko krzysztof.konopko at youview.com
Tue Nov 13 02:06:44 PST 2012


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


More information about the gstreamer-devel mailing list