[Bug 721362] [PATCH] RFC: additional toc api to represent edit lists and loops

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=721362
  GStreamer | gstreamer (core) | 1.x

--- Comment #3 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2014-01-03 10:12:20 UTC ---
For the edit-list in e.g. mp4 I was wondering too how to deal with it. We want
the demuxer to apply the edit list by default, but also give control to
applications to request the raw-data + the edit list.

I could definitely create a new subsystem for edit lists that works similar to
the toc. One benefit of having it as part of the toc api is that we can do
things like
Media
  Edition1
    Chapter1 0:00 - 1:00, loop=none, repeat=0
    Chapter2 1:00 - 5:00, loop=forward, repeat=infinite
  Edition2
    Chapter1 ...

That is associate the loops with segments in the media. If we have a separate
loop api, we would probably still relate it to the toc eventually. If you look
at the AIFF spec [1]. They have markers ('MARK') and then reference them from
an instrument chunk ('INST') for looping. We could have a separate loop api,
that uses the uuid from GstTocEntry to lookup the loop data.

If we can't think of too many additional fields, we could just add them as I do
with this patch (other stuff I could think of is a "play_back_rate" field).

Alternatively we could add a GstStucture with extra_data to GstTocEntry. I
could then add "loop::type" and "loop::repeat_count". Other elements could add
e.g. "playback::rate". While this is flexible, we would need to define the keys
like in GstTaglist though.

[1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Docs/AIFF-1.3.pdf

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