[gst-devel] media player issues

[Andy Wingo]

On Fri, 18 Jan 2002, Wim Taymans wrote:
> On Thu, 2002-01-17 at 12:52, Benjamin Otte wrote:
> > Hi everybody,
> Hi,
Greetings,

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

Just for reference, the DISCONTINUOUS event should be emitted if stream
encounters a discontinuity, as in if I set a new location on a filesrc
or alsasrc sees an underrun or something. DISCONTINUOUS travels
downstream. FLUSH is an upstream event meant for plugins to... er? i
dunno on this one, now that i think about it.

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

Well, we could just do something simple, like
#define GST_METADATA_AUTHOR "author"
which would be simple and extensible.

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

and the syntax would be gst-launch urisrc location=foo://bar

(ie, you'd have a 'urisrc' element)

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

yes, definitely. although we're getting to a position where this would
be more possible now. at least i feel that way now that i grok the
registry ;)

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

what's so hard about g_object_get/set()? (except that g_object_get isn't
in the shim, iirc)

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

s/src/filesrc/

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

i hear this used to work. it doesn't atm. i might be able to fix this,
as i have a local solution in my own app to do just this.

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

Streams that have lengths share the common feature that you can seek in
them. IMO seeking to a byte offset of -1 should seek to the end of the
stream, don't know if it does this now. Then you could look at the
stream metadata to get the length of the stream in time, as then the
codec would be able to parse the last time headers. You really have two
different cases here, one where you have time embedded in the stream and
the other with a constant bitrate. I'm just rambling here, I hope it's
been at least thought-provoking ;)


ok, that's all i have.

cheers,

wingo.