[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 #12 from Jan Schmidt <thaytan at noraisin.net> 2015-01-20 13:46:25 UTC ---
I don't think every possible trick mode desire can be represented by flags -
but the one's I want to implement can be :)

I avoided trying to define any further because of KISS, but also because flags
are the only thing that can be easily added to GstSegment in a
backwards-compatible way.

GstSegments are statically allocatable. There's some padding, but the ability
to add new fields is limited - we could easily fill the padding with
incorrectly thought out API. Sticking to flags is comparitively safe.

For adding a lot of trick-mode description stuff in the future, I was thinking
it would be better to define a new flag 'GST_SEEK_FLAG_TRICKMODE_EXTENDED' and
'GST_SEGMENT_FLAG_TRICKMODE_EXTENDED' that would indicate the presence of extra
fields in the GstStructure attached to seek and segment events respectively,
with a boxed GstTrickModeSettings struct containing all that extended info.
That flags might not even be needed - just the presence of the
'trickmode-settings' field in the event would be sufficient for a function call
like
gboolean gst_seek_event_parse_trickmode_settings() to return TRUE or FALSE.

Done that way, the extra info is not in GstSegment, and doesn't affect the
padding. Elements that know how to do fancier trickmode stuff can just check
for the info and then act on it when present, and store it alongside their
existing GstSegment(s) as needed.

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