[gst-devel] media player issues

[Wim Taymans]

On Thu, 2002-01-17 at 12:52, Benjamin Otte wrote:
> Hi everybody,

Hi,

> 
> I've found some problems while playing with gstmediaplay and trying to
> make it a nice application. These are just random things in no particular
> order.
> 
> 1) events
> As it looks, events are neither very well implemented nor documented. In
> particular, it isn't clear which event is used for what, even by reading
> the source. I.e. I still haven't found out the differences between
> DISCONTINUOUS and FLUSH events. And I don't know whether events can be
> emitted only on playing pipelines or on ready/paused pipelines too.

Events are mostly theoretical still, no plugin actively uses them yet.
EOS is an exception, it works very well. The event/buffer relation still
feels awkward IMO.

> 
> 2) meta information
> Extracting meta information unrelated to the stream (title, interpret,
> copyright...) is not implemented at all. At least not by using INFO
> events.

Elements can send key/value pairs to the application, they can be
catched by attaching the event signal to the toplevel bin. the values
are typed using properties. No infrastructure is in place to properly
parse the properties yet (you can include a private header but that's
not very nice..)

The idea is that the "key" contains a well defined string (bitrate,
channels, author etc...). Again, one could define a whole bunch of
standard predefined keys somewhere in a .h file (probably in the core)
which would (only) buy you some consistency in the keys as they will be
catched at compile time. The problem I have with these predefined keys
is that if someone wants a "foobar" key we need to update the .h file or
don't, which is the current situation.

> 
> 3) meta information extraction
> Nearly all media players are able to extract information like length,
> title and so on before the track is played. GStreamer does not support any
> way of extracting this. And the way Gstmediaplay currently does it - using
> external libs for some kind of media and not getting the information else
> -  is probably not a preferred way of doing this.


> 
> 4) URIs
> IMO there should be a standardized way of supplying URIs to all kinds of
> source plugins. I think anybody would prefer to "gst-launch src
> location=cdparanoia://Track1 ! osssink" and not care which source plugin
> is needed.
> 

yes, like a plugable uriprovider function that can be registered
somewhere. you then say: give me something that can handle http://


> 5) plugin selection
> This is basically the same problem as above. I'd like to have generic
> elements for "source", "datasink", "videosink" and "audiosink".
> Something like this: gstlaunch "src location=music.mp3 ! mad ! audiosink" and the
> default one is selected.

Some ideas:

 1- configurable plugin "aliases": audiosink is mapped to osssink
 2- configurable weighted aliases: 
    audiosink is mapped to osssink with value 10
    audiosink is mapped to alsasink with value 5
    (first try osssink if that fails, try alsasink)

I would look at a new registry infrastructure first (user/system) before
trying to add this.

> 
> 6) more standardized plugins
> It would be nice if the plugin object hierarchy weren't that flat. Nearly
> all plugins descend(sp?) from GstElement. I'd like to have them more
> standardized, because it's much easier if there are functions like
> gst_element_get_windowid(GstVideoSinkElement *),
> gst_element_get_uri(GstSourceElement *) or
> gst_element_set_volume(GstAudioSinkElement *, guint *)

One of the basic ideas of gstreamer was to make the base objects as flat
and as uniform as possible. The same philosphy applies to the media
types (hence the caps/properties system). What this buys you is an
extremely open an flexible system. The downside is that the interface is
very generic (_set/_get_property). anyway:

g_object_set ("channels", 2, NULL) == g_object_set_channels (2).

too bad this cannot be turned into a macro (or can it?)..
point being: it's syntactic sugar and compiler vs. dynamic typechecking,
"dynamic" is what allows you to switch implementation/plugin easily.
That said, glib2 interfaces are nice too, if elements are to have a set
of methods I would use interfaces as multiple inheritance is not
possible but (partialy) solved with interfaces.

> 
> 7) make the autoplugger an element
> The example says it best:
> "gst-launch src location=/any/supported/audiofile ! autoplugger !
> audiosink"

That is the idea of the experimental autoplugger element. It's too
simple for now, I agree. Doing a full-featured autoplugging element is a
nice exercise..

> 
> 8) LENGTH event?
> IMO there should be a (horizontal) length event, which supplies
> information about the length of the stream. It travels downstream and is
> intercepted by plugins who supply different length information. Examples:
> - Sources emit length events with the number of bytes they have.
> - Mad takes byte length events and converts them to (milli)seconds length
> events
> - Mikmod emits its own length events when the file is read.
> This way you can have sensible information about the length at the end of
> the pipeline.
> Another problem is how this should be communicated to the application.

yes, one of the ideas is to make filesrc send a bunch of properties on
it's srcpad (an event), like length, filename, whatmore. plugins can
modify/refine it. 

As for communication with the app several methods exist (are possible) 
 - listen for the events on a random pad in the pipeline.
 - make some element turn the event into an app event (sink objects?).

again, some rules need to be laid out so that this becomes practical for
the autoplugged player.

> 
> 9) standardize information in INFO events
> AFAIK there are no #DEFINEs which define how "bitrate" should be written
> in INFO events. And I don't want to miss the bitrate because some plugin
> calls
> it "bit rate" or something. A more serious example would be "author" and
> "authors" or even "AUTHORS".

a good guideline and a set of standard properties can easily fix this
problem. I wouldn't object to a .h file with some commonly used
properties (but not one with #define AUTHORS "authors", #define AUTHOR
"author", #define THE_AUTHOR "AUTHOR").

> And you would have a good hint about which information should be put out.
> 
> 10) distinguish between horizontal and vertical events
> I don't know if this is good or bad or irrelevant, but I'm often
> really confused about vertical (plugin -> app) and horizontal (plugin ->
> plugin) events. Maybe they should be called something different?
> 
Maybe yes.. I had named my local copy gstreamer-MESSAGES (I didn't even
rename it yet..) but then I figured it was actually the same code..
EVENTS/MESSAGES still makes sense to me..

> 
> See? I don't have many problems. ;)
> Anyway: If I'm missing something I haven't discovered yet, please tell me.

You didn't discover the elementfactory->klass field yet :)

Wim

> 
> And comments please, many many comments.
> 
> Benjamin
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>