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

[Wim Taymans]

On Mon, 2005-05-02 at 20:24 +0200, Ronald S. Bultje wrote:
> 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.

Many function names while they basically all get info from the pad in
question. Moving to a generic message based system to get info might
give us better extensibility and might allow for specific new queries
without having to change an API. It's and idea (hence the draft status
of the document). Having only processing, an event and a query function
to a pad could simplify a lot of API.
> 
> 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);
> }

Well, data-passed (if it happens when I think it would happen, like
with every buffer passed on a pad) is certainly even more suboptimal...

My proposal includes 1 query to get both length, position and other
stuff. For this particular query there is not much more you can do to 
make it more optimal IMO.

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

If the position info is reported in a GstStructure we're not far away
from it being tags..  What's the advantage of it being a real tag? 
merging with metadata is easier as it can use existing APIs?

Wim
> 
> Ronald
> 
> PS whoever has access to CVSROOT, can you please fix the inline cvs diff
> messages? They're not useful and misleading.
> 
-- 
Wim Taymans <wim at fluendo.com>