[gst-devel] Buffers.....dont have any.

[Sojan James]

One more thing I forgot to mention, the MPEG decoder is not controlled by
the V4L2 driver. The output of the MPEG decoder just turns up as another
input for the V4L2 driver. To the V4L2 driver, it is just another digital
video stream.
Once I push the raw mpeg data into the driver of the mpeg decoder, I have
no control over it. These buffers are definitely Video/mpeg.
 The only remaining work is to setup the hardware to display the digital video
source coming from the mpeg decoder (setup the correct input, setup the
overlay and turn on video) this is done via the V4L2 driver.

This is what I had in mind.

 --------      ----------                 -----------------
| filesrc| -> | MPEG Dec | -> (video) -> |Video sink (v4l2)|
 --------      ----------                 -----------------
                    |
                     -> audio
Nothing different one might think, but only the mpeg decoder sink accepts
buffers. The mpeg-decoder output pretends to have a buffer, probably
passing empty buffers to the video sink, which again pretends to take the
buffer from the mpeg decoder. The data flows within the hardware. The crux
of the matter is that, video data _does not_ flow through the gst-buffers,
except between the filesrc and the MPEG decoder.

The same thing goes for audio.

Regards
Sojan.


On 22 Mar 2002, Ronald Bultje wrote:

> On Fri, 2002-03-22 at 12:45, Sojan James wrote:
> >    Yes, I did try out your plugin. The only problem I faced is that my
> > setup just doesn't provide a way to capture video into buffers..which is
> > expected by your plugin. The hardware does all the hard work.. I just have
> > to order things around. ;-).
>
> But you need to mmap() the buffer in order to write the mpeg frames,
> right? We have a MJPEG output plugin (DC10+ and such) which can play
> JPEG encoded frames, so the v4lelement doesn't only support raw video
> (this is also an answer to your "which mime type should I take"
> question: video/mpeg). Or do you use write() to write the MPEG data to
> the device? In that case, you still have a buffer but it's the buffer
> pointed to by your write() call :-). In both cases, the MPEG data
> (mmap()'ed/kernel-side or user-side/write()) is the buffer.
>
> > When do you expect the porting to V4L2 to be complete. Once that is done,
> > I could take the base class element and build on that.
>
> I don't know. Will probably take me several weeks, but at least it'll
> give a clean interface, which is the most important thing. I'd like to
> keep the v4l/v4l2 stuff easy and clean :-).
>
> > About IRC, is there an IRC client that can go through a http proxy? I also
> > think that company policy prohibits chat rooms. I propably will try
> > getting on from home after work. Since I'm a few hours ahead of you guys,
> > I guess it shouldn't be a problem. (I'm in India).
>
> Ok, see you tonight, I'll try to be there as much as possible (though I
> might be away due to class and so :-) ).
>
> Ronald
>
> --
> -   .-.
> -   /V\    | Ronald Bultje <rbultje at ronald.bitfreak.net>
> -  // \\   | Running: Linux 2.4.18-XFS and OpenBSD 3.0
> - /(   )\  | http://ronald.bitfreak.net/
> -  ^^-^^
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>