[gst-devel] proposal of new core element

[Thomas Vander Stichele]

Hi,

> On Thu, 2004-04-22 at 00:49, Thomas Vander Stichele wrote:
> > > 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.
> 
> True. But if you speak of raw video, then you speak of a specific type
> of data. Doesn't that need a specific plugin? videorawparse? Like
> mpeg1videoparse, mpegparse, etc.

So, what would happen for raw video (or raw data of any type) is that
the subclassed element (videoreframer) is able to deduce the correct
frame byte size from the video caps of the next element down the pipe. 
"So how does it get the caps then" you may wonder.  See below ...


> > 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.
> 
> I think bytestream is more suited for this than subclassing...
> Subclassing is nice, but it doesn't really add anything to this use
> case. Rather, it complicates it because the size per frame differs for
> most data types. Bytestream is more appliccable here.

Implementing this as bytestream requires all the other elements to
actually use bytestream for this.  Elements like xvimagesink work fine
the way they are, there's no real need to complicate them with
bytestream for our use cases.

> > > 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.
> 
> Possible != preferrable. ;).

Well, let's just say we need *some* mechanism to reframe buffers :)

> > >  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 :)
> 
> They should use bytestream, or they should have a parser based on
> bytestream in front of it.

I'm really not convinced yet - unless you can give some reasons - why a
bytestream-based element should be put inbetween when a simple
chain-based reframer will do.


> Btw I can obviously see what you're heading to here, so the next obvious
> question: why do you want to stream raw video?

It's part of the architecture we're going to implement.  Consider one
machine doing gst-launch v4lsrc ! tcpsink and another doing gst-launch
tcpsrc ! reframer ! mpeg2enc ! tcpsink

There are some specific use cases where we want to address where it
makes sense to have capturing be done on a different machine than
processing.

In practice, this really only needs two things to work right now; a) a
mechanism to transport the caps from the first pipeline to the second,
and b) a way reframing the buffers correctly before being encoded.

I'm sure that it's possible to extend GStreamer to run pipelines on
different machines at some point in the future, making this transparent,
but that's not what we're aiming at right now :)

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I'd give anything to see you baby
I'd give anything to see you smile
My baby doesn't want just anything
she wants everything
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/