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