[gst-devel] Re: [gst-cvs] wtay gstreamer: gstreamer/ gstreamer/docs/design/ gstreamer/gst/base/
Ronald S. Bultje
rbultje at ronald.bitfreak.net
Mon May 2 11:26:12 CEST 2005
Hi,
On Mon, 2005-05-02 at 15:55, Wim Taymans wrote:
> * docs/design/draft-query.txt:
> Added draft for new query API.
[..]
> 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.
> Current implementation
> The current implementation of query requires pads to implement the
> following functions:
> gboolean (*GstPadConvertFunction) (GstPad *pad,
> GstFormat src_format, gint64 src_value,
> GstFormat *dest_format, gint64 *dest_value);
> gboolean (*GstPadQueryFunction) (GstPad *pad, GstQueryType type,
> GstFormat *format, gint64 *value);
> GList* (*GstPadIntLinkFunction) (GstPad *pad);
> const GstFormat* (*GstPadFormatsFunction) (GstPad *pad);
> const GstEventMask* (*GstPadEventMaskFunction) (GstPad *pad);
> const GstQueryType* (*GstPadQueryTypeFunction) (GstPad *pad);
> Most of these functions are not very extensible in particular,
> the queryfunction can only return one value.
> Requirements
> - multiple return values, grouped together when they make sense.
> - one pad function to perform the query
> - extensible queries.
> 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.
> Proposed types
> - GST_QUERY_SEEKING:
> - get info on how seeking can be done
> - getrange, with/without offset/size
> - ranges where seeking is efficient (for caching network sources)
> - flags describing seeking behaviour (forward, backward, segments,
> play backwards, ...)
> - GST_QUERY_POSITION:
>
> - get info on current position of the stream
> - start position
> - current position
> - end position
> - length
> - GST_QUERY_LATENCY:
> - get amount of buffering
> - GST_QUERY_CONVERT:
> - convert format/value to another format/value pair.
> - GST_QUERY_FORMATS:
> - return list of supported formats.
> - GST_QUERY_LINKS:
> - return list of internal link pads.
> Also????
> - GST_QUERY_CAPS:
Apart from the cvs messages still being horribly broken, let's go into
it by using inline comments, still.
First, you're throwing together a whole lot of stuff that, if you ask
me, are completely unrelated. Is that good? What's wrong with the old
get_internal_links() API? What's wrong with GST_PAD_CAPS(pad) (or
whatever that was renamed to)? Etc.
OK, more important part. Tim complained that the polling is very
suboptimal for applications, which makes sense. So instead of:
bool idle_func (gpointer data) {
time = query_position();
update_slider(time);
return TRUE;
}
int main (void) {
g_timeout_add (500, idle_func, NULL);
}
It'd be nice to have:
void data_func (pipeline, data) {
update_slider (time (data));
}
int main (void) {
g_signal_connect (pipeline, "data-passed", data_func, NULL);
}
This may or may not work out; in the end, it should work for
transcoding, playback, capture, etc, and some of those may be more
difficult with this method, but there are probably awys to fix it. Some
people also argue that length should be reported as tags
(GST_TAG_DURATION) instead of a query. It has some advantages and
disadvantages, I honestly don't care.
Ronald
PS whoever has access to CVSROOT, can you please fix the inline cvs diff
messages? They're not useful and misleading.
--
Ronald S. Bultje <rbultje at ronald.bitfreak.net>
More information about the gstreamer-devel
mailing list