[Bug 540890] Need generic way of handling multi-track/chapters files

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=540890
  GStreamer | gstreamer (core) | git

--- Comment #89 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2012-03-22 21:32:26 UTC ---
(In reply to comment #88)
> (In reply to comment #87)
> > Review of attachment 209758 [details] [details]:
> > 
> > ::: gst/gsttoc.c
> > @@ +39,3 @@
> > + * lists. You should use GST_TOC_ENTRY_TYPE_CHAPTER for generic TOC entry and
> > + * GST_TOC_ENTRY_TYPE_EDITION for the entries which are considered to be
> > alternatives
> > + * (like DVD angles, Matroska editions and so on).
> > 
> > Is the hierarchy at most two levels deep?
> > GstToc
> >   GstTocEntry (in GstToc.entries)
> >     GstTocEntry (in GstToc.subentries) 
> >     GstTocEntry (in GstToc.subentries) 
> >     ...
> >   GstTocEntry (in GstToc.entries)
> >     GstTocEntry (in GstToc.subentries)
> >     ...
> >   ...
> > 
> > 
> > Or is it arbitrary, so that GstTocEntries can have a list of GstTocEntries
> > again?
> 
> The hierarchy is arbitrary, so GstTocEntry has GList field named "subentries"
> which contains another GstTocEntries and so on.

Oh right. Thats cool then.

> The only limitation is that
> chapters and editions can't be mixed at the same hierarchy level. In that case
> TOC supposed to be broken. As I remember, we have disscussed this moment with
> Sebastian and decided that mixed chapters and angles on the same level wouldn't
> have much meaning.

I see no problem with that. Makes sense.
> 
> > @@ +55,3 @@
> > + * and gst_event_parse_toc_select() to parse received TOC select event. The
> > same rule for
> > + * the #GstMessage: gst_message_new_toc() to create new TOC #GstMessage, and
> > + * gst_message_parse_toc() to parse received TOC message. Also you can create
> > a new TOC query
> > 
> > For the toc parsing I am not sure how applications would iterate over the
> > content. Could point to the totem chapters plugin sources in a reply on this
> > bug?
> 
> Totem chapters plugin doesn't support TOC. So there is no application which
> uses it at all. Well, the iteration is quite easy: just go through subentries
> recursively. Functions you've mentioned below do exactly the same thing. I can
> write an example of such usage in developer paper which is coming next days.

I guess I was looking for functions like gst_toc_foreach(toc, foreach_func,
user_data), we can add those later if want though. This would hide that the
implementation uses a GList.

> 
> > @@ +482,3 @@
> > +GstToc *
> > +_gst_toc_from_structure (const GstStructure * toc)
> > +{
> > 
> > please add a comment for where this is needed.
> > 
> > @@ +647,3 @@
> > +GstStructure *
> > +_gst_toc_to_structure (const GstToc * toc)
> > +{
> > 
> > please add a comment for where this is needed.
> 
> These functions are used to parse TOC messages, events and queries. It seems
> that there is no need to make them public. Do you want to add comments about
> these functions right into the source code?

Yep, keep them as is, I was mainly thinking of adding a comment line "These
functions are used to parse TOC messages, events and queries."

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