GNOME Bugzilla – Bug 745102
mpeg-ts: wrong position after non flushing seeks
Last modified: 2018-11-03 13:31:02 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.
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 ?
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.
Maybe best to use DTS if here, otherwise PTS. Good point about several streams. How bout something like: if (GST_CLOCK_TIME_IS_VALID (GST_BUFFER_DTS (buffer))) demux->segment.position = demux->segment.start + GST_BUFFER_DTS (buffer) - stream->first_ts (with s/DTS/PTS/ depending on which is set) ?
Created attachment 301223 [details] [review] fix for the general case Works with the test case I have, and does what I said above.
Any reason why that is in the gst-devtool component?
No, mistake I guess. In -bad now.
I pushed that last patch. Keeping this open for now in case of further comments.
Hi, I submitted bug #763262 probably introduced by commit >commit ade79a9ad24a72d1b02f2e35e7dbeaf3bd59bb6c >Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> >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. > > https://bugzilla.gnome.org/show_bug.cgi?id=745102 which references this bug.
Something is wrong here, that commit references this bug entry ... but it never was posted here.
-- 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/213.