[gstreamer-bugs] [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 #35 from Sebastian Dröge <slomo at circular-chaos.org> 2010-08-01 18:02:56 UTC ---
(In reply to comment #34)
> > a) When muxing something with chapters/editions, you might want to use sink_0
> > for chapter 1 of the video and sink_1 for chapter 2 of the video. So there
> > needs to be some way, to specify pads for chapters in the GstTocEntry.
> 
> Well, there are two ways to go, I think: to put such info right into the
> GstTocEntry, or store it somewhere in external structure. In first case we can
> store pointer to GstPad, but this information will be useless for other
> elements in pipeline I think, and especially for applications. Or we can store
> assotiations between pads and GstTocEntri'es in some external structure, like
> GHashTable. And muxer can operate with it in any way. Any other ideas?

Put them directly into the GstTocEntry. Otherwise things will become quite
complicated.

> > b) You might want to attach other information to tocs/toc entries, like a
> > description ("this is the high resolution version") or something to specify the
> > default edition etc. For this a GstStructure should be added to the toc and toc
> > entries.
> 
> Would there be any predefined fields in this GstStructure or not? Maybe
> description, or default entry, or start entry, etc?

Yes, but I don't think we should worry about that right now.

> > c) If you have a playlist "demuxer", followed by the matroska demuxer for
> > example, they're both exposing a TOC. But the application has no way to use
> > both TOCs and it gets even worse if there are more TOC elements next to the
> > matroska demuxer. For this we need quite some changes:
> >   - A TOC query, which allows to query the complete TOC but also allows
> > elements to query "their position" in the TOC so they can extent the TOC
> > somehow
> 
> I suggest to add TOC query (which contains query mode - whether to get full TOC
> or to get position to insert other TOC entries), which will return UID of the
> parent GstTocEntry (where to insert another TOC elements) and the type (chapter
> or edition) of GstTocEntry which can be inserted in that parent entry (for
> example, we return 0 for UID and EDITION for the type, which means that other
> entries should be inserted right into the root TOC and these entries should be
> editions) in case of position request mode, and full TOC in case of TOC request
> mode.

Well, I'd probably use a single TOC query type and it will always return the
complete TOC but contains some kind of marker for the TOC Entry for the pad
over which the query was received. That's probably a bit easier.

> >   - A TOC select event (upstream), which is like a seek event but for TOC UIDs
> > (this gets rid of the start/stop/format stuff from the entries). This is
> > required to allow seeking in these nested/cascaded TOCs unfortunatenly. Normal
> > seeks would only seek in the selected TOC parts.
> 
> I think that a new TOC seek event (maybe GST_EVENT_TOC_SEEK) with the seeking
> UID would be ok, isn't it?

Yes, but seek is no good metaphor for this IMHO. It's more a selection than a
seek.


Another thing we probably want is a "GstTocSetter" interface, similar to the
GstTagSetter interface. Which would then be used for muxers to set the TOC
properly on them. Sending events from the application to the element is not
really clean.

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