[Bug 678742] New: [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

           Summary: [0.11] [API] GstToc API review
    Classification: Platform
           Product: GStreamer
           Version: 0.11.x
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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)

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

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

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

 - I there's no reason not to, I will add
    additional entry types for
    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)

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

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

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

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

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

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

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