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

[Benjamin Otte]

> 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.
- 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.
- 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.
- 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
- 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.
- query supported formats
If that's the conversion formats, this would easily be solved by the stuff
I outlined above.
- 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.)

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


Benjamin