[gst-devel] Non-seekable getrange

[Andy Wingo]

Hey all,

Been thinking a bit about getrange. GstBaseSrc for example determines
whether or not it supports getrange operation via a "is_seekable" class
vmethod, which belies the intent of the function: a method to be
provided by a random-access source.

Whereas, whether or not a source supports get-based operation is
independent of whether it has random access or not. For example in a
tree-based graph funneling down to an audio sink, you'd probably want
the sink to drive the pipeline by going into loop mode, so that you
don't spawn a bunch of threads. But you can't randomly access that data,
e.g. if it comes from a live source.

Or, in fakesrc ! fakesink, it doesn't matter which one has the loop
function, regardless of whether or not fakesrc has been told to support
random access.

To put it another way, the activation mode of a pad is a topological
consideration as well as a seeking consideration. It just so happens
that combining seeking and getting in one call is a win, so that's why
getrange gets passed an offset. But you should be able to get N bytes
without specifying an offset, which means getting from the current
offset.

So, the proposal:

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.

Furthermore, an element should be able to set a CONTINUOUS_GETRANGE flag
or so, indicating that getrange-based seeking is not possible. You can
still try to seek with events, like applications do, but you should be
prepared for a possible failure. And if it succeeds, you get a DISCONT,
which will trigger a specific code path that the normal
buffer-processing function doesn't have to deal with.

I would expect that network sources, live sound sources, dsp plugins
(like convolvers or so), etc would require CONTINUOUS_GETRANGE.

I'll think about implementing this after I get a chance to talk with
wim, but we do too much in-office planning here -- it's only fair to
discuss things on the list. So speak up if you care :-) Is this crack,
or does it sound ok?

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