GNOME Bugzilla – Bug 670080
Seeking problems on recorded mpegts streams
Last modified: 2013-07-15 14:35:54 UTC
We have problems when seeking on 'recorded' mpegts TV streams (DVB-S), that we don't see on 'normal' mpegts video streams. When recorded DVD-S mpegts streams (we use a Time-Shift-Server, but can be reproduced with any TV stream captured via 'udpsrc ... ! filesink') are played back by a gstreamer-pipeline and a seek_simple (with GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT) is issued we see that the pipeline needs a long time to start playback again (depending on the hardware up to a minute) and the process consumes lots of CPU and IO. Tracing down the issue showed that after the seek LOTS of buffers are dropped because they are too young relative to the NEW_SEGMENT that is defined after the sseek: mpegtsdemux gstmpegtsdemux.c:2959:gst_mpegts_demux_sink_event:<mpegtsdemux1>ESC[00m pushing time newsegment from 20:16:51.141321938 to 20:16:59.633147215 pos 0:00:21.224999716 ... mpeg2dec gstmpeg2dec.c:851:handle_slice:<mpeg2dec0>ESC[00m picture had pts 20:16:50.140433333, we had 20:16:50.1404333330:00:02.043965142 ESC[336m 4019ESC[00m 0x9d3a668 ESC[36mDEBUG ESC[00m ESC[00m mpeg2dec gstmpeg2dec.c:1008:handle_slice:<mpeg2dec0>ESC[00m dropping buffer, clipped ... ^^^ repeats ^^^ .... The amount of dropped/clipped buffers seem to increase with bigger seek steps. With longer streams and seek steps we saw > 1 minute of stream-time dropped which means, that seeking is practically unusable. No notable difference between souphttpsrc and filesrc. We would like to find a solution to this problem, but don't know enough about the internals to find out who to blame: mpegtsdemux's byte-to-time conversion? wrong base_pts? the mpegts-stream? Please let us know if we can provide further information (debugging output, ts-files, etc.) Thanks, Holger
Created attachment 207533 [details] logging output extract Attached an extract of the logging output produced by GST_DEBUG=mpeg2dec:5,mpegtsdemux:5 Will attach an url to a sample mpegts-stream later, bugzilla did not accept my 20mb :-(
20MB sample ts-file, that can be used to reproduce the issue: http://depositfiles.com/files/gej93xhkm
Created attachment 213275 [details] [review] fix seeking on recorded live streams This patch fixes the problem for us. For a more detailed description cf. git log in attached patch. We use this on different kind of streams (live, httpsrc) in production environment and consider it therefore tested. I know mpegtsdemux is about to die, but anyway ask you to consider it for upstream, as long as tsdemux shows the same problem and does not support everything mpegtsdemux does. This was ported fluendo's flutsdemux, Julien Moutte gave us an ok for posting this here. Shouldn't be a license problem as mpegtsdemux is already doubly licensed, no? Credits go to Fluendo! ;-) Regarding tsdemux: I only had time to give a quick look and it seems to show exactly the same behaviour as mpegtsdemux on the recorded live streams: calculation of lower segment boundary as calculated after seeking is too low with respect to the first buffers arriving, which are in turn dropped due to clipping in the decoder. The same approach taken for mpegtsdemux (resetting base-pts, in post seeking processing) might also help for tsdemux.
Sorry, correction: > calculation of lower segment boundary as calculated after seeking is too low > with respect to the first buffers arriving calculation of lower segment boundary as calculated after seeking is too *high*/late with respect to the first buffers arriving
(In reply to comment #2) > 20MB sample ts-file, that can be used to reproduce the issue: > http://depositfiles.com/files/gej93xhkm Can you make this file available again ?
Uploaded it here: http://www.math.uni-bielefeld.de/~hkaelber/vid/tv20mb.ts
Holger, that file is seekable fine with current git master. Can you try again and confirm ?
One month without response. Closing (works here). Please re-open if you can reproduce the issue with gstreamer 1.1.x or later.