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

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=540890

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #12 from Sebastian Dröge  2008-08-25 08:36 UTC -------
(In reply to comment #9)
> Probably stating the obvious, but if the (new) event mentioned above makes it
> downstream for elements there to figure out what is going on (e.g. muxers),
> then that should be fine for transcoding :)
> 
> [Or maybe not that obvious, IIRC there are (often?) "global tags" that demuxers
> only announce as messages, and that therefore do not give downstream a chance
> ...]

If elements are using gst_element_found_tags or _found_tags_for_pad the tags
will be sent as message and event. The only problem with some elements is, that
they send tags before a first NEWSEGMENT event which will make the tags-event
be dropped.

(In reply to comment #10)
> (In reply to comment #7)
> > Does anybody see issues with this proposal?
> 
> Hello Sebastian, I have an issue with this item:
> 
> > This GstStructure contains information about the complete file and should
> > contain an array of GstStructure for all "subparts" and these can again contain
> > more GstStructures to create a tree-like structure.
> 
> In the case of a DVD this can be an expensive operation to collect all the
> information to create the 1 tree for whole the disc, because the navigation
> data is spread across the disc, and disc access can be slow...
> 
> Accept from that the information about other titles on the disc is not
> interesting for the player and there will be much information in the tree that
> can't be translated to useful information for the end-user. So maybe it is the
> best to send a TOC only for the current playing title (angles/chapters), and if
> the user play's another title on this DVD a new TOC is send....

That would be possible too of course... we could make the TOCs for DVDs be
partial. I.e. first you will have just all titles, when the first title is
played an updated TOC with all chapters/angles of this title added will be
sent, etc. For this to work good we just need an "updated" flag in the
top-level TOC structure. Does this sound good for you?

(In reply to comment #11)
> I am not sure if seeking to editions fits the seeking metaphor. One seeks in a
> stream and chapters are sort of named points in time in that stream. Editions
> are more like a separate alternate stream.

The problem is, that these alternatives are not always at the top of the TOC
tree. DVD angles for example are specific to a title AFAIK (so you have
TOC->Title(as chapters)->Angle(as editions)->Chapters(as chapters).

In Matroska and all other formats I know they're fortunately top-level only...

> As a sidenote that might be useful for wavparse to. It can have loop-markers
> (loop-start/end) or cue lists. Where cue-lists are just named position markers,
> lopp-markers have even some special semantics. Not sure if we can easily mark
> special purpose TOC entries?

Well, it's a GstStructure... we can always add new things to it without
breaking compatibility. I've also thought about "hidden" TOC entries which are
not shown to the user but could be seeked to by a format specific mechanism
(DVD menus, Matroska menus or "scripts", ...)


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=540890.