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

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #17 from Edward Hervey <bilboed at gmail.com> 2010-08-06 08:21:41 UTC ---
(In reply to comment #15)
> What about accessor functions and opaque stream info structs?

  I'm fine with opaque stream info structs but I'd like to avoid having a
gazillion methods.
  How about :

GstDiscovererStreamType  
gst_discover_information_get_stream_type(GstDiscoverStreamInfo *i);

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

(In reply to comment #16)
> > I'll switch them to pairs of guint32
> 
> Can we make that simple guints? IMHO sized integers in API should be avoided
> where possible.

  Sure.

> 
> 
> > > - Does anyone ever need to go back to the previous info?
> >
> > I don't understand what you mean.
> 
> I was wondering if the 'previous' member in GstStreamInformation is
> necessary/useful.

  You'd need it if you were looking at the GstDiscovererInformation stream_list
in order to known the predecessor.

> 
> 
> > > - We should wait for the TOC API to land before finalising
> > >   this API, so we can make sure it integrates well.
> >
> > I'd only care if you can show me one example of a URI with
> > multiple chapters that changes media type between chapters.
> 
> There are two things that may be expressed this way:
> 
>  - alternatives (ie. same title/chapter/whatever available in different
> resolutions)
>  - titles/tracks/chapters/parts
> 
> 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.

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