[Bug 540890] Need generic way of handling multi-track/chapters files
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Apr 2 14:13:30 PDT 2012
https://bugzilla.gnome.org/show_bug.cgi?id=540890
GStreamer | gstreamer (core) | git
--- Comment #92 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2012-04-02 21:13:18 UTC ---
(In reply to comment #5)
> Some random thoughts:
>
> - why have a TOC query vs. posting a TOC message on the bus?
> (query would take same path as seek event; but it's inconsistent
> with how we announce tags; if it was a query, would we also have
> a TOC-changed message then?)
Thats indeed different that how we do tags. Imho it should work that elements
just wait for the toc event and parse it.
>
> - we'd need to allow for tree-like structures to be flexible, right?
> Is this easy-enough to do in a way that doesn't make it extremely
> painful to handle in apps? (we could predefine fixed hierarchy
> schemes, like title:chapter or disc:tracks with a bunch of utility
> functions for each)
We can add convenience api as we get a bit more experience when adding toc
support to other elements.
>
> - do we need a 'TOC' at all? Why not just put it into the normal tags,
> possibly with utility functions for easier parsing? (see e.g. the
> rather messy and basic, and also commented out, GST_TAG_CDDA_TRACK_TAGS
> stuff in cddabasesrc)
I see benefit from having it separate from tags. Taglists are list and tocs are
by nature hierarchical.
--
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.
More information about the gstreamer-bugs
mailing list