[gst-devel] Non-seekable getrange

[Andy Wingo]

Yo,

On Mon, 2005-04-18 at 14:21 +0200, Ronald S. Bultje wrote:
> > and that
> >     getrange(pad, -1, size, &buf)
> > mean to get the next SIZE bytes from the pad.
>
> So, logic-wise, what's the point of replacing get/pull + bytestream with
> getrange then?

As far as I can tell, combining offset and size with get/pull is purely
an optimization. I believe that it was written with demuxers in mind,
but I really like passing the size, from a dsp perspective. It is
convenient to be able to specify the (max) size of a buffer.

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

What do you think the purpose is? (I think it's probably for demuxers,
but I might have missed something.)

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

Pbbblt. Yeah, dunno. GstBlockSrc, probably. The other option is to have
getrange(pad, -1, -1, &buf) return a buffer of whatever size the source
chooses. Lots of protocol, eh. I would lean towards not doing that,
because with the offset it's well-specified what the offset is, we're
just not mentioning it. Whereas if an element's getrange is called, it's
not driving the pipeline, and is thus at the whim of whatever has the
loop function. But that's just an instinct, dunno.

> What are you guys aiming at?

I can only speak for myself, and that's that I like passing the size
when pulling. Personally I have no use for offset, but demuxers do need
it.

>  What kind of data will be processed by
> getrange-based elements? Only raw file data? Audio data? Video data?

Ummmm, raw file data only? Dunno. Lemme get wim on this tomorrow.

Thanks for the response,
-- 
Andy Wingo
http://wingolog.org/