Re: [V4L] [ANNOUNCE] video4linux loopback 0.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Sat, 09 Sep 2000 wrote Jeroen Vreeken:
>
>Version 0.6 of the driver now uses semaphores for locking and is a
>little bit cleaner.
>I have also integrated it into the 2.4.0-test7 source tree and included
>a patch for it.
>It can be found at: http://motion.technolust.cx/vloopback/

Hi Jeroen,

a "v4l loopback driver" implementation was discussed on
livid-ati@xxxxxxxxxxxxxx some days ago. I have included the proposed
function of the driver (see below). It is a bit different to your implementation
but I think both are a valuable addition to V4L.

The (new) proposed V4L driver would be very useful to link V4L and the Xvideo
extension for multimedia video cards (i.e. ATI All-in-wonder, Matrox Marvel,
etc.) which are capable of capturing video streams. A pure V4L driver for such
cards is very tricky as they combine graphics cards (XFree86 domain) and capture
cards (V4L domain). 

As vloopback already exists it should not be too difficult to enhance it. What
do you think ?

Marko


-----
Here is the posting "Re: loopback v4l driver (was [livid-ati] My Sin)" on
livid-ati:

> Hi,
> 
> > Or I would prefer another solution: you taking your time and writing
> > "loopback v4l driver" which would solve all our problems with video
> > capture and Xv extension.
> 
> This idea sounds interesting, promising and challenging. Could you outline
> such a "loopback v4l driver" (what it does or should do) ?

Maybe it's already written :)) (I haven't checked recently).

Basically it should work like virtual terminal pair. 

So it creates and entry in /proc  (like /proc/video/loopback-master0)

Any application (restricted by permission perhaps) can open it and issue
an ioctl requesting to create virtual v4l device and giving, say frame
size and number of frames the buffer must have.

The driver creates v4l device and allocates chunk of kernel space for
frames.

Then the application that opened loopback-master0 can issue ioctl's
providing data (I suggest at first to simply copy it - the overhead isn't
that big)

And the driver will store these frames in ring buffer - feeding them to
any application that opened it as v4l device. 

There a few similar drivers in the kernel - like virtual framebuffer
driver. Unlike those ours will be useful for more than testing.

Once the basic functionality is done we can go on improving it:
* using mmaped memory instead of ioctl's to transfer frames
(perhaps ioctl is used to only report that new frame has been added)

* pass v4l configure requests back and force to master application

* teach driver to request DMA'able memory so we can setup video device
to DMA directly into the buffer (though my feeling is this is
completely unnecessary - capture perfomance look to be limited
by CPU only when you try to compress on-the-fly and by disk when
you write there)

A suggested way to implement this driver is to take any existing one,
throw out hardware dependent part and implement /proc entry to make
v4l requests. I also suggest to take a look at USB camera drivers -
they support hotplugging so might have a better way of doing
initialization than static bt848 cards. And they will already
have a mechanism to setup buffers - as they usually are nothing
more than controlling interface - the actual transfer is done by
USB subsystem.

Vladimir Dergachev





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux