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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Aug 4 23:24:39 PDT 2010


https://bugzilla.gnome.org/show_bug.cgi?id=540890
  GStreamer | gstreamer (core) | git

--- Comment #50 from Alexander Saprykin <xelfium at gmail.com> 2010-08-05 06:24:34 UTC ---
> 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?

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

Maybe leave them?

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

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

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

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




More information about the Gstreamer-bugs mailing list