[gst-devel] Re: [gst-cvs] wtay gstreamer: gstreamer/ gstreamer/docs/design/ gstreamer/gst/base/

[Wim Taymans]

On Tue, 2005-05-03 at 15:39 +0200, Benjamin Otte wrote:
> > Purpose
> >   Queries are used to get information about the stream.
> >   A query is started on a specific pad and travels up or downstream.
> > Types of queries
> >   - get length of stream
> >   - get position in stream
> >   - get seeking capabilities
> >   - get latency
> >   - convert one value to another
> >   - query supported formats
> >   - query internal links.
> >
> I think all of these are wrong as a query and can be implemented better
> without the need for a querying framework. I'll elaborate:
> - get length of stream
> This is currently polled when instead it should just be delivered when
> available. The current mechanism to provide metainformation about a data
> stream is tags. I don't see why using the GST_TAG_DURATION tag (and
> probably a GST_TAG_SIZE for the size in bytes) tag won't work. This of
> course requires adapting some elements to modify this tag, but in the end
> people wanting to get tags are better off.

Posting a size message on the bus whenever the length of the stream
changes is indeed something usefull. Problem is that many elements will
have some idea about the length of the stream in
bytes/samples/frames/etc while the application is mostly interested in
the length as it will be played.

> - get position in stream
> The position inside the stream equals the timestamp + duration of the last
> buffer. Or in finer grained environments (like audiosink) you can
> get it directly from the element. In both cases there's no need to send a
> query through the stream. Especially since queries that end up in other
> threads tend to return widely differing positions anyway.

Queuing can screw this up, both in things like an audiosink or a queue.
Current possition before and after the queue is different. It's rather
hard to figure out what goes on by looking at the buffers that pass by.
The query is more convenient for the programmer as there is only a
single API to get the info. 

> - get seeking capabilities
> Seeking capabilities need to be negotiated, since it should not be
> possible to link a non-seekable sink with an AVI muxer for example.

The query is exactly how the information is obtained to perform this
negotiation.

> - get latency
> I'll pass on this since I have no clue what the exact requirements for
> this are. but I've thought that sending a PING event somewhere and
> receiving a PONG event from the endpoint is a much better idea than
> requiring elements to calculate their latency. Especially in this case:
> src ! ... ! tcpserversink  tcpclientsrc ! ... ! sink

Latency is usefull for alsasrc ! alsasink, a clock adjust has to be
aplied to make sure no samples arrive too late in the sink. In the case
you state above you mix up the method of obtaining the latency and
eventually using it. 

> - convert one value to another
> This should be part of the caps media type meta information stuff (where
> we put the fixate functions). Converting a timestamp to an offset is the
> same as long as the format is the same. So it's better to just do
> gst_convert (caps, format, value, &target_format, &target_value) or even
> gst_pad_convert (pad, format, value, &target_format, &target_value) which
> would use the pad's current negotiated caps. Especially because this
> really eases the work of writing a new element, since conversions don't
> need to be explicitly supported by each and every element.

Caps only provide info about the media type, not the processing state of
the element. Caps don't give enough info to do a conversion to get the
actual bitrate of encoder, for example.

> - query supported formats
> If that's the conversion formats, this would easily be solved by the stuff
> I outlined above.

Exposing that a seek can be done on a chapter in a DVD cannot be derived
from the caps, let alone that the caps provide info on the number of
chapters.

> - query internal links
> Is there any reason why someone would want to query it from outside the
> element? (This is neglecting the fact that internal links are just a poor
> hack to get default event handlers doing something that most likely will
> look as if it'll work and therefore should go away.)

For shutting down part of a pipeline one must be able to follow the flow
of data, hence the internal links. This is currently used to dispatch
events but also in playbin to mute streams.

> 
> > Proposition
> >   - define GstQuery extending GstData and containing a GstStructure (see GstMessage)
> >   - define standard query types (see proposed types)
> >   - define methods to create a parse the results in the GstQuery.
> >   - define pad method:
> >      gboolean                (*GstPadQueryFunction)          (GstPad *pad, GstQuery *query);
> >     pad returns result in query structure and TRUE as result or FALSE when
> >     query is not supported.
> >
> So you propose to make a query be an event, and even have the same
> signature?
> Wouldn't it make sense to just define some new events?

It would have the same datastructure (as GstMessage) but with a
different intend, hence a different name for the structure. 

Wim 

> 
> 
> Benjamin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>