Re: [gst-devel] Non-seekable getrange

[Andy W. <wi...@po...>]

Been thinking a bit more.

On Mon, 2005-04-18 at 13:15 +0200, Andy Wingo wrote: 
> that
>     getrange(pad, offset, size, &buf)
> keep its current semantics;
> 
> and that
>     getrange(pad, -1, size, &buf)
> mean to get the next SIZE bytes from the pad.

Being able to pass the offset as a parameter to gst_pad_pull makes it
seem like all sources are random access, which in fact is the exception.
Maybe it's a good idea to explicitly begin random access by sending an
event upstream, and make sure that all upstream elements support random
access.

The only point about this that's bothering me is the part of the code
that figures out whether a connection should go into push or pull mode.
Now gst_element_pads_activate does a check_get_range, which will figure
out if upstream elements can handle a get_range and if so schedules the
connection pull-based. Otherwise it's push-based. Buuuuut it might be
misleading if you can't actually do random access, but the downstream
element is assuming it's possible because it was activated in pull mode.

The goal of this all is to (1) seek cheaply when necessary and (2) avoid
reframing of buffers. Offset getrange allows (1) and (2), and offsetless
getrange allows only (2) via the size parameter. Chain-based scheduling
avoids neither. So maybe there is a hierarchy of activation methods:

First GST_ACTIVATE_PULL_RANGE (getrange with offset)
Otherwise GST_ACTIVATE_PULL (getrange, offset doesn't mean anything)
Otherwise GST_ACTIVATE_PUSH (chaining, src element has control)

PULL_RANGE would be a new activation method.

That's what I'm looking at as a plan.

Ciao,
-- 
Andy Wingo
http://wingolog.org/