[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

--- Comment #4 from Alexander Saprykin <xelfium at gmail.com> 2012-06-25 20:45:42 UTC ---
(In reply to comment #0)
> Some quick comments on the GstToc API after attempting to add TOC support to
> GstAudioCdSrc.
> 
>  - toc and toc entry should be refcounted. They
>     are usually created once and then only read,
>     but not modified (done: made them mini objects)

Cool :)

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

Well, at the begining the main idea was to make it as much general and abstract
as possible to support most of media formats' needs. Yes, maybe naming
'chapter' isn't quite good enough. I like an idea to enhance toc entry. 

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

We can add more entry types (CHAPTER, TRACK, TITLE, ANGLE, etc) and rename
existing to SEQUENCE and ALTERNATIVE. The latter two are more abtract. Then it
would be: [TITLE]->sub-chapters. I think that two enums for entry typing will
introduce more problems.

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

[SEQUENCE]->tracks

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

Sure.

>  - 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)
>
>  - 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?

They are atored in nanoseconds (gint64) from the start of the file/stream. It's
my fault that it is not cleared in documentation.

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

Yeap, application should look for TITLE tag. So the element implementing GstToc
must name every entry. To simplify developers life we can add setter/getter for
the title, which will wrap TITLE tag inside. Well, there are songs without
artist and title tags. And it's OK. Any ideas how to handle entries with empty
titles? Maybe application should care about it or we can make helper function
which will give names to empty titles in order of TOC processing? Or
application can use entry's UID instead of empty title.

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

Agree. I think having two internal GstStructures (one for internal info and
another for user specific structures/data) would be nice. And add an
getter/setter API with quark and GstStructure. Later we can use this userspace
structure to store additional user specific data.


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

This design was taken from matroska format. But I don't see any limitations not
to store entries right inside the TOC.

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

I think combining several GstTocs together isn't a good idea. Resulting
structure can be really huge. I like an idea to add "priority" field so the
application can decide which one to use.

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

Agree. A bit of explaining is in the GstTocEntry description.

Uhf, a head is boiling a bit, maybe clearer thoughts will be at the morning :)
If we agree on implementation details I can do this work on GstToc.

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