After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745102 - mpeg-ts: wrong position after non flushing seeks
mpeg-ts: wrong position after non flushing seeks
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-02-24 17:50 UTC by Vincent Penquerc'h
Modified: 2018-11-03 13:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

keep track of current position (1.65 KB, patch)
2015-03-09 10:01 UTC, Vincent Penquerc'h
committed Details | Review
fix for the general case (1.24 KB, patch)
2015-04-09 16:38 UTC, Vincent Penquerc'h
committed Details | Review

Description Vincent Penquerc'h 2015-02-24 17:50:22 UTC
Using -base's playback-test program:

./tests/examples/playback/playback-test 0 file://$somempegtsfile

Seeking with the flushing flag off kinda works (though there is image corruption that looks very much like a keyframe is missing), the position will not be updated to the new one after the seek is performed.
Comment 1 Vincent Penquerc'h 2015-03-09 10:01:50 UTC
Created attachment 298859 [details] [review]
keep track of current position

I looked at this and came up with this patch. Seeking does not set base correctly to account for the running time of the previousl played part.

However, this still did not fix the issue, and further digging shows that the dts/pts are actually recreated by tsdemux based on running time...

I'm not sure why this is done. Does anyone know ?
Comment 2 Edward Hervey 2015-04-09 16:15:08 UTC
I can already see a few issues with this:
* DTS can vary (a lot) between different streams. Which one do you pick ?
* What if no DTS is set on the buffer ? There are streams out there which never have a DTS set
* There are streams which only set a DTS once in a while.
Comment 3 Vincent Penquerc'h 2015-04-09 16:23:42 UTC
Maybe best to use DTS if here, otherwise PTS.

Good point about several streams. How bout something like:

    demux->segment.position = demux->segment.start + GST_BUFFER_DTS (buffer) - stream->first_ts

(with s/DTS/PTS/ depending on which is set) ?
Comment 4 Vincent Penquerc'h 2015-04-09 16:38:00 UTC
Created attachment 301223 [details] [review]
fix for the general case

Works with the test case I have, and does what I said above.
Comment 5 Thibault Saunier 2015-04-15 12:49:40 UTC
Any reason why that is in the gst-devtool component?
Comment 6 Vincent Penquerc'h 2015-04-15 12:57:31 UTC
No, mistake I guess. In -bad now.
Comment 7 Vincent Penquerc'h 2015-04-16 12:38:09 UTC
I pushed that last patch. Keeping this open for now in case of further comments.
Comment 8 Hanczar 2016-03-07 19:58:56 UTC
I submitted bug #763262 probably introduced by commit 

>commit ade79a9ad24a72d1b02f2e35e7dbeaf3bd59bb6c
>Author: Vincent Penquerc'h <>
>Date:   Tue Mar 24 12:56:53 2015 +0000
>    tsdemux: send new segment when a stream is added
>    This will happen when the PMT changes, replacing streams with
>    new ones. In that case, we need to accumulate the running time
>    from the previous chain in the segment base.
which references this bug.
Comment 9 Edward Hervey 2016-03-08 10:21:06 UTC
Something is wrong here, that commit references this bug entry ... but it never was posted here.
Comment 10 GStreamer system administrator 2018-11-03 13:31:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: