[gstreamer-bugs] [Bug 625944] New GstDiscoverer helper library

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Aug 6 09:32:06 PDT 2010


https://bugzilla.gnome.org/show_bug.cgi?id=625944
  GStreamer | gst-plugins-base | git

--- Comment #19 from Sebastian Dröge <slomo at circular-chaos.org> 2010-08-06 16:31:58 UTC ---
(In reply to comment #17)

> > Alternatives may be of different format/resolution/bitrate etc.
> > 
> > But different tracks may also have different characteristics even if they're
> > the same format, at the very least tags/bitrate/duration. And the user might
> > want to know that there are different tracks in this single file in the first
> > place, so the question would still be if/how to expose that.
> 
>   Will the TOC API allow different URI for the various track/angle/whatev ? If
> so I might be inclined to have a way to inform the user that the URI contains
> multiple angles/scenes/tracks/... with the individual track-specific URIs which
> he can then re-add to discoverer.

What do you mean with different URIs? The URI will still be the same, you can
just send SELECT events to the elements to select some part of the TOC and the
elements give you TOC events/messages to inform you about the TOC.

The TOC entries can be incomplete, i.e. there could be subentries but in the
generic case you can only know that after selecting the TOC entry and at least
pre-roll it (in the case of chapters being detected during playback when they
appear you only know them during playback of course).

(In reply to comment #18)
> >  (...) but I'd like to avoid having a gazillion methods.  How about :
> > ....
> > gboolean
> > gst_discoverer_information_parse(GstDiscoverStreamInfo *i,
> > GstDiscovererStreamInfo **prev, GstDiscovererStreamInfo **next, GstCaps **caps,
> > GstTagList **tags, GstStructure **misc);
> > 
> > And then _parse for all the subclasses (having them parse the common info might
> > be a good idea too for easy bindings, but then they're going to have a huge
> > number of arguments).
> 
> I find this rather ugly tbh. I still prefer the 'gazillion' methods approach,
> at least for the audio/video/container stream structures, because that's just
> nicer and more straight-forward API IMHO, and also easier to extend when there
> will be more things to extract in future (ie. just add a new getter vs. a
> parse_more()).
> 
> People often have problems with out arguments (see parsing functions in core),
> and this is supposed to be *nice* end-user API, the bar should be low here.

I'd prefer the million methods too. In the end I thought we wanted opaque
structures because they're better to extend later and if you now add a method
for parsing it completely we again have the extension problem ;)
You could make the info structs GObjects with properties maybe, then you don't
have millions of functions...


And again on the topic of making the structs GstMiniObjects (or GObjects if you
want properties...)... it would allow people to check if the stream info they
have is in reality a audio stream info, i.e. look at the exact type of it and
walk the type hierarchy and things like that.

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