[Bug 735666] design doc : trick mode handling in demuxers (SKIP)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735666
  GStreamer | gstreamer (core) | unspecified

--- Comment #10 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2015-01-07 11:41:29 UTC ---
About the API: it seems to me there are multiple different ways of doing
SKIP/trick-mode playback, and we will  want to be able to support all of them.

I think the question is if we think we will be able to squeeze all the things
we'll need in the near future into flags, or if we don't want something more
explicit instead which is easier to extend later. This could be either some
kind of GstTrickModeContext helper object that can then be added/gotten from
the seek event, or some kind of gst_event_seek_set_trick_mode_options (....)
with option/gtype/value style extendability.

Different trick mode "modes" we'll want to be able to support:

 (1) automatic (chosen by whoever drives the pipeline, source and/or demuxer,
perhaps based on the rate and other things)

 (2) I-frame only (continuous) (possible extra parameters: min-distance, for
higher-rate FF/FR)

 (3) I-frame only (single-shot) (i.e. EOS right after; useful for snapshotting
and simulated app-managed FF/FR)

 (4) Ref frames only / skip B-frames (avcodec has separate options for these)

 (5) play-skip style trickmodes, as described by Edward's proposal and
part-trickmodes.txt (I can imagine some parameters one might want to influence
the behaviour of this in future). Possibly with subvariants that limit the
input datarate and/our output datarate (Edward's proposal is to limit it to the
rate of the original stream on both counts, but one might want to allow higher
input/output rates for better trick mode performance if it is known that the
decoders can handle more or there's enough bandwidth and processing power on
the input side to handle more).

 - any of the above combined with additional options such as reducing
post-processing quality or somesuch

 - any of the above with or without audio

Most of the above could be modelled with flags, but e.g. the min-distance
parameter seems very useful to have in practice, and I think it would be
difficult to squeeze that into flags, for example.

Then there's the question what the SKIP flag alone is supposed to mean. I think
we should not try to run before we can walk, and let SKIP default to the lowest
common denominator (which could just be automatic/whatever mode). We don't even
support I-frame only SKIP mode anywhere yet!

I also wonder if we should default to no-audio by default, which seems like a
more sensible default to me (and what device vendors seem to do in practice.)

-- 
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.