[Bug 702595] tsdemux: reverse playback support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702595
  GStreamer | gst-plugins-bad | 1.x

--- Comment #5 from Edward Hervey <bilboed at bilboed.com> 2014-02-05 15:43:27 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.