[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 #52 from Sebastian Dröge <slomo at circular-chaos.org> 2010-08-05 07:00:06 UTC ---
(In reply to comment #50)
> > There's no need for the format, start and stop values now with the TOC select
> > event. You can remove them.
> 
> I think that these values would be useful for some reasons:
> 
> 1. To seek to appropriate time in TOC select event handling. Otherwise how can
> I get time for particular UID?

Well, you would put the UID into the TOC select event and the element would
then handle everything needed, e.g. the conversion to time or something else.
For a playlist element there wouldn't be any times for example.

> 2. It would be useful for applications to display start/stop positions of the
> chapters/tracks.

Right, that might be useful. But for that we could put something into the
GstStructure because it's not something generic but only useful for some
elements.

> > gst_toc_entry_new() should probably take a pad parameter too.
> 
> So, I'll change gpointer to GList and add a pad parameter to gst_toc_entry(),
> ok?

Not sure, before you work on this a second oppinion might be good to have :)

You could add a gst_toc_entry_new() without pad parameter, a
gst_toc_entry_new_with_pad() with a single pad parameter and
gst_toc_entry_new_with_pads() with a const GList* of pads. Or maybe only the
first, I don't know

> Well, GstTocSetter interface is ready :) but I want to write some tests for it
> before. I need a bit of time for that.

Great :)

> > And then the pad selection might not be really optimal for muxers. Some muxers
> > will require the same pads for the complete stream and then allow to structure
> > that stream with a TOC (e.g. flac). Other muxers (e.g. matroska) could mux many
> > different streams on many different pads and then structure/group them with a
> > TOC. So the application really has to know what the element it uses needs.
> > 
> > (And in most cases the pad will be NULL, e.g. the complete stream/stream group
> > I guess... for muxing at least)
> 
> You mean that one stream can be muxed from some pads with the TOC, then another
> stream can be muxed from another set of pads with the TOC, and finally we need
> to know, which pads in the TOC to which stream belong?

Yes, for example.

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