GNOME Bugzilla – Bug 702595
tsdemux: reverse playback support
Last modified: 2018-11-03 13:15:54 UTC
I'm working on playspeed support related to mpeg-ts using latest GStreamer-1.X code on Ubuntu 12.4. I have been testing with the GStreamer playspeed tutorial - "Basic tutorial 13: Playback speed" (http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+13%3A+Playback+speed). (See Bug 694369 for code attachment and a sample mpeg2 ts file). The tutorial fails when attempting to switch to a reverse playspeed. To demonstrate issue, enter "S" to switch from 1x to 2x playback speed. Then enter "D" option to change direction from 2x to -2x rate I get the following error: GStreamer-CRITICAL **: gst_segment_clip: assertion `segment->format == format' failed 0:00:39.902699443 11915 0xb5d144f0 WARN mpeg2dec gstmpeg2dec.c:474:gst_mpeg2dec_discard_buffer: Could not find buffer 1822, will be leaked until next reset
Created attachment 247203 [details] Log file from run showing error when attempting to switch to -2x
Created attachment 247204 [details] Log file from run showing error when attempting to switch to -2x Wrong file with previous attachment, correct log
It should be noted that the program exits with seg fault with following bt: Program received signal SIGSEGV, Segmentation fault.
+ Trace 232098
Thread 3059743552 (LWP 12949)
This is non-trivial. Marking as enhancement.
Some thoughts ... There are two sorts of reverse playback: 1) Either we are given chunks of mpeg-ts from upstream in reverse order (I'm thinking of HLS for example). In that case it shouldn't be too hard (take incoming TIME segments and forward them, push out demuxed data and don't forget about discont flags. I'll ignore this for the remainder. 2) Upstream can't handle sending us the data in reverse order, therefore it's up to tsdemux to get the data. That requires figuring out in tsdemux what "chunks" we need to get from upstream in reverse order. Since we don't have indexes, we need to do more or less work to figure out where the underlying audio/video (key)frames are. Several options are available: 1) "Be quick or be dead": This is the simplest solution. Guesstimate the bitrate and grab the equivalent of 10s of data in reverse order and push it downstream (and recursively go back by as much). 2) Add parsing to figure out where keyframes are. Use the same as above but remember where keyframes are, so that the next time backwards you fetch data up until that previous keyframe. The advantage of 1) is that it's doable rather quickly. The downside is ... you're not guaranteed to have full GOP quickly enough, so you might not see much especially at low reverse speed. The advantage of 2) is that you'll be sending all the data expected downstream. The downsides are that it requires parsing support and it might be quite expensive i/o and cpu-wise. Implementation-wise, option 2 would require most of the work done in option 1.
Note that another bug ( #675132 ) would require parsing support.
Just a note: this is not required for reverse playback in HLS
-- 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/97.