[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 #4 from Sebastian Dröge  2008-08-22 08:31 UTC -------
The GstQuery could then contain a GstStructure, containing a GstArray which
contains GstStructures containing the TOC information.

The query could be called TOC, gst_query_new_toc() would take a variable number
of GstQueryTocEntry and gst_query_parse_toc() would return a NULL-terminated
array of GstQueryTocEntry.

GstQueryTocEntry would contain various information about a chapter/track, like
name, duration, .... and a GstStructure for additional information. Fortunately
we can have nested GstStructure nowadays :)

This then would make it possible to use the TOCs with the standard GStreamer
techniques: queries for getting information, seeking in a new format for
selecting a specific chapter/track, ...

As this had to go to core it should be media independend and I guess this is
the case here as one could, for example, implement an element parsing URI lists
and exporting them via the TOC query.

Only question is, what the terminology for such a TOC entry should be and how
the new GstFormat could be called. Is it a chapter? A track? A TOC entry?

IMHO this would be the preferred implementation.


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