[gst-devel] proposal of new core element

[Thomas Vander Stichele]

Hi,
> 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 :)

Thomas