[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 #34 from Alexander Saprykin <xelfium at gmail.com> 2010-07-28 21:16:46 UTC ---
> 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?

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

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

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

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