[gst-devel] proposal of new core element

Thomas Vander Stichele thomas at apestaart.org
Wed Apr 21 15:53:09 CEST 2004

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

I know, but in practice this cannot be guaranteed.  Raw video coming in
from a file, a pipe, or a socket just doesn't know how much bytes a
buffer should contain.

Also, the core basically contains a set of general pipe elements, which
have "pipe theory" operations.  A reframing one is missing there IMO. 
With the current core, I also don't see another way of doing this
nicely.  If I subclass the generic core element and calculate the frame
byte size from the video caps this works quite well.

> For the compressed case, it's even more complicated because of different
> sizes per frame.

Agreed, but it might still be possible to do this.

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

I don't see how bytestream is solving this, esp. for elements that
aren't using bytestream in the first place :)

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

Yeah, that makes sense, but it's probably not going to be in 0.8.x is it

Anyway, even with all of this in place, for testing purposes and generic
stuff a simple reframer still sounds like a good idea to me :)


More information about the gstreamer-devel mailing list