[gstreamer-bugs] [Bug 540890] Need generic way of handling multi-track/chapters files

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=540890

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #7 from Sebastian Dröge  2008-08-23 18:55 UTC -------
After thinking about it a bit more and talking to Wim my current plan is like
this.

We get a new event, message and query type for the TOC. These will all contain
a GstStructure which represents the TOC.

This GstStructure contains information about the complete file and should
contain an array of GstStructure for all "subparts" and these can again contain
more GstStructures to create a tree-like structure.

The names for these GstStructure can be "chapter" or "edition" and all child
structures of a parent must have the same name. edition represents
alternatives, chapters represent parts. So let's say you have a movie separated
into 5 chapters and for the last chapter there exists an alternative version
then you would create the following structure:

                     toc
           edition1---|----edition2
        /   |                 /   |
   chapter1 chapter2 ...     ch1 ......  chapter5b

Another example: An album encoded to a single file would have the toc structure
containing an array of chapters.
Or a DVD with angles (assuming angles are per title) would be a TOC containing
the titles as chapters and the titles containing editions for the angles.


Now every of these structures should contain some fields. The top level toc
structure probably doesn't need to contain any fields but we might want to
include the taglist containing tags which are valid for the complete file or
the complete duration or something.

The chapters and editions must contain a unique identifier (I'd suggest using a
int64 for reasons explained later) and should also contain a name that can be
displayed to the user, the taglist with all tags specific to the
chapter/edition, the duration (including all durations of the child elements)
and a GstFormat for the duration.

Applications can show the user some kind of UI for this TOC tree and allow them
to select a specific chapter, etc.


Now the application needs a way to choose a specific chapter/edition or a range
of chapters/editions. For ranges IMHO it's enough to allow the application to
choose a start and stop chapter/edition at the same level or in the subtree of
the start chapter of the TOC tree.
The demuxer/source then has to play the complete subtree of every
chapter/edition and then stop playback.

I'd suggest that we invent a new GstFormat (GST_FORMAT_CHAPTER) for this.
Applications can then send a seek event in this format to the demuxer, the
start and stop position of the seek are the unique identifiers for the specific
chapter/edition. The demuxer/source will then go into some kind of "chapter"
mode and all following seek events, position/duration queries in other formats
will be relative to the currently playing chapters/editions. To get the old
behaviour back again a pre-defined UID is used for seeking.

To provide the application about some informations of the currently playing
chapter/edition I'd suggest using a new tag type ("chapter"). This will contain
the UID of the currently playing chapter/edition and will be sent by the
demuxer/source if it's in "chapter mode". This way the application always knows
at which point we're currently playing.

The demuxer/source should also send chapter/edition specific tags at the time a
chapter/edition is started.



Does anybody see issues with this proposal? Otherwise I'd start to write a
prototype implementation for the matroska element (as matroska has the probably
most complex chapter/editions system out there it should be the perfect test ;)
)


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=540890.