[Bug 678742] [0.11] [API] GstToc API review

[GStreamer (bugzilla.gnome.org)]

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

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at circular-chaos.org

--- Comment #1 from Sebastian Dröge <slomo at circular-chaos.org> 2012-06-25 09:33:14 UTC ---
(In reply to comment #0)

>  - the entry types are way too limited, we lose
>     all semantics here. An application will want to
>     know if an entry is a title (dvd), track, chapter,
>     or angle. And if only to present it properly in
>     the user interface (see below)

The idea of the entry types was to have one for "alternatives" (angles, a set
of chapters with an alternate ending, ...) and "sequences" (chapters, titles,
...). Maybe there could be a tag or something else for the adding this kind of
information to the entries?

>  - how do I represent a DVD with titles that
>    are sub-divided into chapters? I would have
>    to use chapters for the titles, and then
>    chapters for the actual chapters. That
>    doesn't make sense.

titles[chapters]->chapters[chapters]

>  - how do I represent a simple Audo CD with
>    a number of CD tracks? Using 'chapters'
>    here feels a bit wrong

chapters :)

>  - I there's no reason not to, I will add
>     additional entry types for
>     TRACK, TITLE, ANGLE

Maybe make the entry type an entry type "class" (alternative or sequence) and
additionally something else to say that this is a track, title, angle, ...?

>  - is an entry's start/stop supposed to
>    be in TIME format? If yes, the function
>    should have _time in it to make that
>    clear IMHO, or one should add a
>    GstFormat parameter (though I think
>    it makes most sense to just stick to
>    time)

TIME, yes

>  - if TIME, relative to what? just whatever
>    makes sense? For a CD track, would it
>    be time relative to the start of the first
>    track, say?

Yes, needs some clarifications probably.

>  - how is an application supposed to
>    present an entry in a UI? Just hope
>    there's a TITLE tag in the taglist ?
>    Should every app create their own
>    _("Chapter/Title/Track/Angle %d") ?
>    Note that titles may not be numbered
>    in sequence, e.g. one might only
>    expose Title 1 and Title 10 on a DVD.

My idea was to use the TITLE tag, yes. For some formats there are even titles
for the chapters for example

>  - the whole 'info' structure thing is
>    weird. The fact that there is such an
>    'info' structure should be hidden as
>    an implementation detail behind API
>    that allows elements to add an
>    additional GstStructure of their
>    own (similar to qdata). If it then
>    stores that inside another 'info'
>    GstStructure or a GList or whatever
>    should be an implementation detail.
>    There should be setter/getter API
>    that takes either a string or
>    a quark or a GstObject as key and
>    then a GstStructure as value.

Agreed

>  - (there should generally be
>     getter/setter API, but that's just
>     a nitpick compared to the other
>     issues)

What do you mean with getter/setter API?

>  - what's with the recommendation/
>    tendency to start every TOC with
>    a top-level edition entry, even if
>    there's only one actual TOC ?
>    I find this weird semantically,
>    and it makes things much harder
>    for apps to handle, and to decide
>    what to use and what to expose.

If there's only one edition and you don't have specific metadata for it, just
start with the chapters at the top-level?
What would you suggest instead?

>    If there can be multiple sources
>    for a TOC, there should be
>    multiple GstTocs IMHO. A different
>    "edition" of the toc itself is not
>    the same thing as a different
>    edition of the medium. But
>    perhaps there's a misunderstanding
>    on my part here. If not, then I
>    would suggest we add some kind
>    of gst_toc_add_alternate() or so.
>    That would get rid of the top
>    level edition thing, and also makes
>    it clear to apps which TOC they
>    should use/prefer etc. (i.e. they
>    can just ignore the alternates).

For that maybe we should add a "primary" or "priority" field to the entries.
For the meaning of edition and chapter see above.

> - (some more guidance on the
>    uid thing would be nice in the
>    docs, what it is supposed to
>    look like ideally for example)

Whatever you like to have in there, just some unique string representating the
entry. For some formats you could use the in-stream UIDs for example, for
others things like "Title 2/Chapter 17/Angle 2"

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