[gst-devel] proposal of new core element

[Ronald Bultje]

Hi Thomas,

audio and video are slightly different. The purpose of the audio one is
make sure that the buffer has a specific/fixed amount of samples. Incoming
buffers might have different amounts of samples, but will still be
aligned. For video, however, each buffer is one, and exactly one, frame.
It makes no sense to have buffers of zero or three or X frames.

For the compressed case, it's even more complicated because of different
sizes per frame. An extension to bytestream would make much more sense
here imo, especially if we make it chain-based functional (or we go ahead
with Dave/Benjamin's idea of making everything iterate-based, in which
case this is not needed). The extension would be to suggest buffer sizes
to previous elements, e.g. something like my proposal of some time ago to
add an optionally implemtable read(num_bytes) call next to the default
get() call to get-based elements.

But maybe others have different ideas...

Ronald

On Wed, 21 Apr 2004, Thomas Vander Stichele wrote:

> Hi,
>
> I'd like to add a new element to the core.  It would work on its own as
> well as serve as a base element to subclass from for specific media
> types.
>
> Basically, it rechunks buffers to a given size.  It's based on Andy's
> buffer-frames-convert element.  We need the same functionality for
> video, so I thought it'd make sense to have this as a core element.
>
> The reason we need this for video is that sometimes one buffer doesn't
> correspond to one video frame; for example in the case of getting raw
> video data from the network or a pipe.  This hasn't been a problem up to
> now because most elements working with video implicitly give out or take
> in one buffer as a frame; ie. our video decoders happen to send out one
> buffer per frame, and our video consumers happen to take one buffer per
> frame.
>
> The basic element currently has a buffer-size and buffer-rate property.
> For video, for example, the buffer-size can be calculated from the caps.
>
> Right now, it explicitly sets timestamps, ignoring the incoming ones.
> It probably makes sense to have a way of disabling that, and recalculate
> timestamps from incoming buffers.  It will need some guesswork though
> since the outgoing buffers have slightly different timestamps in
> practice, but it's not always easy to calculate if the mapping is not
> linear.
>
> In the future, maybe it might make sense to have a suggested buffer size
> be part of the caps somehow, just like Andy added buffer-frames for
> pro-audio.
>
> Anyway, feel free to comment on the base element.  Does anyone mind if I
> commit this (with some cleanups) so I don't have to lug patches around
> all the time ? :)
>
> Thanks
> Thomas
>
>
> Dave/Dina : future TV today ! - http://www.davedina.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> I can't go away with you on a rock climbing weekend
> What if something's on TV and it's never shown again
> Just as well I'm not invited I'm afraid of heights
> I lied about being the outdoor type
> <-*- thomas (at) apestaart (dot) org -*->
> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
>
>