[gst-devel] Non-seekable getrange

[Wim Taymans]

On Mon, 2005-04-18 at 14:21 +0200, Ronald S. Bultje wrote:
> Hey Andy,
> 
> On Mon, 2005-04-18 at 13:15, Andy Wingo wrote:
> [..]
> > 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
> 
> So, logic-wise, what's the point of replacing get/pull + bytestream with
> getrange then? You're basically back to original behaviour, but with a
> nicer implementation. I'm not saying that's a bad thing, btw. However,
> it's a change from what I understood the original purpose of the
> function was.

The intention is to get rid of a getrange based emulation using chain
based
elements and seek events for a real getrange function. Some elements can
operate in pull based mode, provided the offsets are continuously
increasing 
(ie , no seeking), for pro audio, one usually makes the audiosink drive
the
pipeline to eliminate a context switch between read/process/write
operations,
of course then you need pull based scheduling with cont increasing
ranges
and most likely fixed sized (segment sized) buffers. An audio card can
do pull based scheduling provided the offset is continuous. Provided we
expose enough info to peer plugins, all these scheduling choises can be
made. All this is not in the context of making an arbitrary plugin
support
getrange based scheduling by simulating it with bytestream, seeks, etc..

Also note that seeking from inside an element processing loop is not to
be attempted anymore (locks, flushes, clocks, ...). 

> 
> Next step is that we recognize that things like CD, DVD and VCD reading
> are better done block-wise, we re-implement a block-to-byte cacher like
> bytestream to easify getrange implementation and then where are we,
> exactly?
> 
> What are you guys aiming at? What kind of data will be processed by
> getrange-based elements? Only raw file data? Audio data? Video data?
> Anything? It's getting fuzzy for me.

getrange is mostly for raw data files next to a demuxer, audio data 
filters and audio sources/sinks. And yes, it is fuzzy as one or the
other scheduling method can be emulated. 

> 
> Ronald
> 
-- 
Wim Taymans <wim at fluendo.com>