[Bug 721362] [PATCH] RFC: additional toc api to represent edit lists and loops

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #6 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2014-01-06 17:26:47 UTC ---
(In reply to comment #5)
> It's not that I think this is horrible or anything, I'm just wary of
> overloading the GstToc API with "wtf", and I also wonder if these fields will
> be sufficient in future, or if we just keep adding more and more stuff to it to
> accommodate more use cases.

If that is the concern we can either:
a) create an extension mechanism
b) or create new api (new event) that references toc-subentries

I think a) is overkill and would make it complicated for apps to deal with
loops. As I said earlier, I can think of too many extra fields.

> I'm just looking at this from an application writer perspective, and they tend
> to find GstToc already somewhat confusing in my experience, so I would not be
> happy to see more and more exotic/weird stuff added to it that just confuses
> people even more. The documentation in your patch tells users nothing about how
> this should be used, where they would get it, if they should worry about it or
> not. What should an application writer do with a loop entry?

If we would send the Loop info as a separate event, how would this change
anything for media-player apps? They will most likely ignore it, as they would
ignore looped subentries in the toc.
Maybe we just need another toc-entry type: GST_TOC_ENTRY_TYPE_SEGMENT (sequence
type).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.