GNOME Bugzilla – Bug 769565
tsdemux: playback is faster than normal speed for certain files
Last modified: 2018-11-03 13:54:11 UTC
There are some streams in which PCR is present at interval more than 500ms(say for example 1 sec or 1.5 sec) at few positions. When there is a PCR gap of more than 500ms between last PCR and new PCR, a new PCR group is formed. While forming new PCR group, PCR offset is computed with respect to previous group and stored. But this stored PCR offset is not computed properly. And when this group is referred to compute timestamp for a frame, it is done based on first PCR and PCR offset of this group. Since the PCR offset is wrongly stored when forming the group, time stamp computation also goes wrong. PCR offset stored is little less than the right PCR offset. Because of lesser PCR offset, time stamp computed also lesser than actual. Due to this playback ends very fast than the actual duration. And also because of wrong PCR offset for last group(which set during initial scanning), duration of file computed is less than the actual.
With this patch change, above mentioned issue is not observed. diff --git a/gst/mpegtsdemux/mpegtspacketizer.c b/gst/mpegtsdemux/mpegtspacketizer.c index a7e0798..787dde8 100644 --- a/gst/mpegtsdemux/mpegtspacketizer.c +++ b/gst/mpegtsdemux/mpegtspacketizer.c @@ -1830,11 +1830,6 @@ _set_current_group (MpegTSPCR * pcrtable, /* The previous group closed at the raw last_pcr diff (+100ms for safety) */ pcr_offset += prev->values[prev->last_value].pcr + 100 * PCR_MSECOND; } - } else if (lastpcr < pcr - 500 * PCR_MSECOND) { - GST_WARNING ("GAP detected. diff %" GST_TIME_FORMAT, - GST_TIME_ARGS (PCRTIME_TO_GSTTIME (pcr - lastpcr))); - /* The previous group closed at the raw last_pcr diff (+500ms for safety) */ - pcr_offset += prev->values[prev->last_value].pcr + 500 * PCR_MSECOND; } else /* Normal continuation (contiguous in time) */ pcr_offset += pcr - prev->first_pcr;
If you could attach (parts of) a sample file that might be helpful.
This file seems to be able to reproduce the problem. vlc can not get duration, but can be smooth playback. gst-play-1.0 every few seconds, there is a sense of jump, and print the following information: Redistribute latency ... Redistribute latency ... Redistribute latency ...
Sorry for miss submission. This file seems to be able to reproduce the problem. ---------- https://drive.google.com/file/d/0B8t5E5lSOxhHRUZYSkpvX0VRdzg/view?usp=sharing or http://www.mediafire.com/file/4el4nw4m6jy3v5b/2m.ts ---------- vlc can not get duration, but can be smooth playback. gst-play-1.0 every few seconds, there is a sense of jump, and print the following information: Redistribute latency ... Redistribute latency ... Redistribute latency ... 0:00:05.9 / 0:09:05.3 0:00:06.0 / 0:09:18.2 0:00:07.5 / 0:08:19.9 0:00:07.8 / 0:08:19.9 0:00:07.9 / 0:08:19.9 0:00:10.3 / 0:06:59.6 0:00:13.2 / 0:05:39.6 0:00:13.2 / 0:05:40.7 0:00:16.2 / 0:05:21.9 0:00:16.9 / 0:05:33.9
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/415.