Re: video4linux loopback device

Em Fri, 24 Jul 2009 17:07:29 +0200
Folkert van Heusden <[email protected]> escreveu:

> > >> > Any chance that the video4linux loopback device will be integrated in
> > >> > the main video4linux distribution and included in the kernel?
> > >> > http://www.lavrsen.dk/foswiki/bin/view/Motion/VideoFourLinuxLoopbackDevice
> > >> > or
> > >> > http://sourceforge.net/projects/v4l2vd/
> > >> > or
> > >> > http://code.google.com/p/v4l2loopback/
> > >> > This enables userspace postprocessors to feed the altered stream to
> > >> > applications like amsn and skype for videochats.
> > >> If the postprocessor application is LGPL, the better is to add it at libv4l.
> > >
> > > I don't agree as the postprocessor implements fun-effects: warhol,
> > > puzzle, circles, wobble, etc.
> > 
> > and how one can make skype to get pictue from libv4l or alter the
> > picture which application is getting through libv4l?
> > again some proxy is needed here.
> 
> Correct so we definately need some external video loopback device.
> It gives as a much greater flexibility.

libv4l intercepts V4L2 calls by using LD_PRELOAD. Without it, skype doesn't
work with most of the cams, since it doesn't support several of the output
formats common on most cameras. I have lots of different webcam models here. I
think only one or two are directly supported by skype.

libv4l already have some postprocessor effects (currently limited to image
enhancements like auto-gain/auto-bright and similar stuff), but I don't see why
not adding there other effects including the fun ones.

Hans has several plans of improvements for it, including more post-processing
effects and the ability of duplicating a video to more than one application at
the same time.

The big problem with a v4l2 loopback is that you're adding something that it is
not proper to kernel, since it were not designed to be a proxy between two
userspace applications. This is the space where libraries were designed. Due to
that, you can affect the machine performance, due to the usage of kernel memory
barriers.

Also, you'll likely add extra buffering costs of copying control data and
stream mapping in order to access it  from/to kernel where you could just pass
a buffer between the effect processors and do a simple function call.



Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list