[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