June 9, 2010 at 18:45Fake Chatroulette on Linux - More Flexible Than on Windows
All of you know about services like CR, which on the Internet today have divorced enough. The basic behavior of users of these services, to put it mildly, depressing. No, of course, it is very beneficial to manufacturers of keyboards and mice that are destroyed by actively clicking / pressing the next button, but, imho, it should blow up the brain to any normal homo sapiens and cause creative itching in it and hands, requiring actions to destroy total symmetry and uniformity in the behavior of those who show evidence. In addition, there are as many as 76,800 pixels of advertising space. In general, you need to do something about it. And in this text, a story about how you can start these things (cases aimed at launching arbitrary video streams in chat roulettes) in Linux. In addition, you will learn from it: (1) how to use dd for buffering, (2) how with ffmpeg grab '
1. Linux
In general, of course, you can download some kind of utility like the one on manycam.com and gain access to some features in Windows. But ... These possibilities, although diverse, are limited by the will of the authors of this program and the authors of plug-ins for it. Writing these plugins is not so easy. And what is good about Linux and unixway for these tasks, as a philosophy of information processing, is that you can quite simply and flexibly couple all sorts of filters of varying degrees of fun'ovity together and end up with an interesting result. There is more freedom, so everything below is unfolding in Linux. But, of course, Windows users should also join the struggle for a variety of chat roulettes, at least with the help of the same ManyCam.com.
2. avld and vloopback
The first thing to do is to establish a video interface with flashplayer through which all these chat roulettes work. Flashplayer on Linux understands the video devices of the video4linux (2) subsystem, so you need to organize such a virtual device. This can be done using special drivers. There are many of them in the wild, but I personally managed to get to work only avld and vloopback. More or less sane, they work even on the kernel version 2.6.33.4. Another plus is that these drivers (as far as I know) are included in the Ubuntu repositories, and that (for sure) they are in AUR Arch Linux, they probably are in Gentoo too - so it’s enough to simply install them correctly in the system : no need to do self-assembly. I will not waste time describing how to install these packages,
The answer is this. For most fun scenarios, avld will be enough for you - it is very easy to use and reliable, like felt boots in winter, but it has a significant drawback: avld (so far) does not support many video devices, only one virtual v4l device is created during driver downloads, which is not enough. vloopback allows you to create many devices (videopipes), but at the same time it is able to firmly suspend flashplayer with the browser, and you need to use it according to a rather shamanistic scenario. Of course, you can decide, to give a damn about complexity, to use only vloopback, but it has one more serious drawback: it produces a video stream at the speed at which the process reading this video stream is able to receive it, fps is not controlled in any way. Even if the process is video stream generating, produces frames very rarely, just in this case vloopback will produce the same frame for a while. Therefore, firefox through flashplayer when working with a vloopback device turns into a 100% cpu pig. Therefore, if you are having fun with vloopback on a laptop, it makes sense to put the processor in powersave mode, otherwise the system will warm up without much benefit.
avld allows you to set fps, through which the cpu-gluttony of flashplayer is limited, and there is an additional ability to control video.
So, you installed the drivers, what to do next?
1.1. avld
First, you need to download the driver. Do it better with a team
After that, a device should appear in your system
It should be clear what the numbers are indicated in the module parameters, and the documentation on avld says that these parameters can be changed in runtime if you
but I could not change the settings in this way. However, you can change them if you simply reload the module.
After loading the module with the necessary parameters (and for flashplayer 320x240 25fps, it works well; with other sizes), you can immediately launch a browser, go to some chatroulette.com, poke the flash plug-in area with the right mouse button and select the camera that appears in the settings (its name will begin with the words 'Dummy video device').
After turning on the camera, you should see a black square of almost your own production. To fill it with paints, you need to write raw pictures sequentially, that is, just a sequence of values encoding the colors of the pixels into the device
That is, a certain video file is taken, a video stream is extracted from it (
If you direct the stream from ffmpeg immediately to
Actually, everything is with avld. You can record in
By the way, yes. MEncoder writes the results of video decoding in raw format just frame by frame, which allows you to use it without dd.
1.2. vloopback
The interface for this thing is much more complicated compared to avld. The reason is that vloopback was not conceived as a fake video camera, but rather as a device like pipe (which | in bash) for realtime video processing. In this regard, this thing has a rather sophisticated set of options, and a rather complicated program interface, which may require the use of special utilities to configure the parameters of these very videopipes, which, for example, can scale video (right inside the kernel, yes ... Linux happens weird). But if the goal is to get fun, and not to understand all the intricacies of vloopback, then you can act in a simple way.
First, of course, you need to load the module into the kernel:
where the pipes parameter can be used to request vloopback to create the appropriate number of pipes. After loading, vloopback will tell you where the
For each channel, there are two names in
Now, everything is ready to send the video stream to the vloopback channel. However, vloopback requires gentle treatment, so that nothing hangs, you need to follow some rules. Firstly, you always need to start the video stream in vloopback first, then start the application that will read data from the video device. To stop work, you must first close the application that reads, and then writes the data to the vloopback channel. In short, as in the stack.
In addition, vloopback requires adjusting the geometry and presentation format of the pixel, this can be done using mplayer. So, first the video stream to the vloopback channel:
In this case, the browser with flashplugin should not be launched. Before you open any kind of chat roulette in it, you need to configure / check the output end of the video channel. This can be done using mplayer.
After completing mplayer, you can launch a browser with some chat roulette and select a newborn virtual camera. REMEMBER: so that nothing hangs, you must first close the browser (or disable flashplugin), and only then stop recording frames in the channel.
2. Content.
So, virtual cameras, perceived by flashplugin, are now known how to do. But how to fill them - that’s the question. In general, when I started this all, I had an acute desire to check: either my face is crooked, or in these chatroulets people are sitting there to constantly poke on the next button.
Therefore, the first thing I wanted to do was to become a “man in the middle” between two users, that is, broadcast the video stream of the first to the second and, of course, vice versa. You can probably get into flashplugin behind this video stream through preloaded libraries, but it is long and difficult. It's easier to take a finished picture from the screen. ffmpeg will help with this (for avld):
The parameter
But then another question arises: how to attract the attention of people (preferably, the attention of girls)? In general, what is positive, a good degree of attractiveness is the translation of the desktop (for those who are not quite in the topic, the beginning of the team):
on which, for example, a game of chess is open or something more or less intellectual. Of course, on the desktop you can also post your bright and thoughtful face, showing the video stream from a real camera in a separate window:
But non-production windows interfere, so there is a desire to overlay various video streams in memory, and then send them to a virtual webcam. Of course, again, you can try to find a utility that does this, but you can also remember that the X-Window itself provides good opportunities for imposing anything on anything.
3. Xvfb
So that you can draw in a virtual framebuffer, this is a buffer, first, of course, you need to create and run:
this creates a virtual display 1 with a new screen 1, the resolution and color depth should be obvious with which ones (Yoda master). Well, that’s it. Further is as obvious. You can send a video stream of your desktop to this virtual display:
ffplay at initialization will see the DISPLAY environment variable and understand which X-server it is drawn on (I use yuv4mpegpipe here to write fewer keys on the receiving side of the pipe, but it’s clear that the color is converted to yuv444, and then from it to draw pictures add processor load, it’s more efficient to use -f rawvideo, but then you’ll have to specify the pixel format and frame size everywhere). Next, you can overlay your video image on this mess:
Well, send the video stream to the virtual video camera:
OK, at this moment we have a picture in a picture, and we can show others our chess abilities, etc. etc. But, unfortunately, the reality is harsh and pornographic. Most of all people (including girls) living in chatroulets are hooked by a video series where couples make love in front of webcams (yeah, people like to peep).
4. Crop
But most of these videos that you can get on the Internet ...
(By the way, here’s a simple way to pull out video from any flash media in firefox. Now flashplayer-10.0.42.5 works with video content like this: it starts downloading the video through the browser’s cache, and while the video is buffering, the corresponding file is in the cache firefox, but when the buffering ends, the file is deleted, it just remains open, and flashplugin can read it. But, Linux and we, naturally, to save this file on your disk, you need to make a hard link to it. Therefore, if you want to save the video, then open the page with it, then id those in the properties and clean your browser's cache will remove all but the desired video, making it hard link command
So, most videos of dubious content on the Internet are hung with all sorts of different logos and running lines that you need to get rid of so as not to destroy the illusion of those watching. Of course, you need to get rid of them by cutting out clean video material from the whole picture. To do this, the ffmpeg - crop video filter is suitable (crop in Nashnensky). But this filter works severely and if you write something like:
then you are scolded for the fact that the box with the coordinates (left_up - right_low) (32.32) - (432.332) does not fall into a 320x240 frame, that is, ffmpeg first scales the frame, and then tries to apply the crop filter to it. Of course, you can run
Well, here you can say this to everyone: thank you for your attention, happy video creativity in the open spaces of chat roulettes. But I still pogromomania, for a long time I did not write on Habré.
5. Atom users.
In general, for all these entertainments, the performance of some not the most powerful Athlon II X2 is more than enough. You can still watch a couple of films (at the same time) in p720 resolution at this time. But now the single-core Atom pulls this badly, and I want to somehow squeeze extra fps out of it.
And here, despite the symmetry of its hardware threads, installing affinity for different groups of processes can help. This is probably due to the fact that the scheduler does not distinguish between hardware threads, considering them to be completely equal entities, and freely throws processes between them. BUT, after all, TLB of these threads should be different. And when the process is thrown, forced switching of these same TLBs occurs. If firefox mixes up with ffmpeg in its execution, then, in order to switch from one to another within the x86 architecture, you need to completely reset the TLB and reload it with new data.
Therefore, productivity increases slightly if you nail with
firefox to the second thread, and all processes associated with the processing of any video to the thread of the first thread (with number 0). Two or three frames per second can be won in this way.
6. Audio.
But I did not manage to build a virtual microphone from ALSA. And this despite the fact that ALSA has a native loopback driver called aloop. And it really works as expected: everything that is written into one of its channels can be read from the corresponding other channel. The jack-server works fine with it, and you can transfer sound between different applications in different ways. But to build from this aloop something that would look like a virtual microphone did not work out for me. But, probably, it’s possible, I just didn’t have the patience and time to understand these ALSA wooden configs.
And so, this would open the way to audio advertising on the open spaces of chat roulettes. If anyone comes out with this, write an article on Habré, I promise to use karma for that :) :)
Well, that's it.
I hope it was not boring and boring. Have fun, and all that.
1. Linux
In general, of course, you can download some kind of utility like the one on manycam.com and gain access to some features in Windows. But ... These possibilities, although diverse, are limited by the will of the authors of this program and the authors of plug-ins for it. Writing these plugins is not so easy. And what is good about Linux and unixway for these tasks, as a philosophy of information processing, is that you can quite simply and flexibly couple all sorts of filters of varying degrees of fun'ovity together and end up with an interesting result. There is more freedom, so everything below is unfolding in Linux. But, of course, Windows users should also join the struggle for a variety of chat roulettes, at least with the help of the same ManyCam.com.
2. avld and vloopback
The first thing to do is to establish a video interface with flashplayer through which all these chat roulettes work. Flashplayer on Linux understands the video devices of the video4linux (2) subsystem, so you need to organize such a virtual device. This can be done using special drivers. There are many of them in the wild, but I personally managed to get to work only avld and vloopback. More or less sane, they work even on the kernel version 2.6.33.4. Another plus is that these drivers (as far as I know) are included in the Ubuntu repositories, and that (for sure) they are in AUR Arch Linux, they probably are in Gentoo too - so it’s enough to simply install them correctly in the system : no need to do self-assembly. I will not waste time describing how to install these packages,
The answer is this. For most fun scenarios, avld will be enough for you - it is very easy to use and reliable, like felt boots in winter, but it has a significant drawback: avld (so far) does not support many video devices, only one virtual v4l device is created during driver downloads, which is not enough. vloopback allows you to create many devices (videopipes), but at the same time it is able to firmly suspend flashplayer with the browser, and you need to use it according to a rather shamanistic scenario. Of course, you can decide, to give a damn about complexity, to use only vloopback, but it has one more serious drawback: it produces a video stream at the speed at which the process reading this video stream is able to receive it, fps is not controlled in any way. Even if the process is video stream generating, produces frames very rarely, just in this case vloopback will produce the same frame for a while. Therefore, firefox through flashplayer when working with a vloopback device turns into a 100% cpu pig. Therefore, if you are having fun with vloopback on a laptop, it makes sense to put the processor in powersave mode, otherwise the system will warm up without much benefit.
avld allows you to set fps, through which the cpu-gluttony of flashplayer is limited, and there is an additional ability to control video.
So, you installed the drivers, what to do next?
1.1. avld
First, you need to download the driver. Do it better with a team
modprobe avld width = 320 height = 240 fps = 30
After that, a device should appear in your system
/dev/videoNwhere the number N depends on the number of already existing v4l devices in the system. Theoretically, according to the standard for Linux distributions, users of a group should have read and write access to this device video, so be sure to add yourself to it. It should be clear what the numbers are indicated in the module parameters, and the documentation on avld says that these parameters can be changed in runtime if you
/dev/videoNwrite a new configuration:echo 'width = 640 height = 320 fps = 15'> / dev / videoN
but I could not change the settings in this way. However, you can change them if you simply reload the module.
After loading the module with the necessary parameters (and for flashplayer 320x240 25fps, it works well; with other sizes), you can immediately launch a browser, go to some chatroulette.com, poke the flash plug-in area with the right mouse button and select the camera that appears in the settings (its name will begin with the words 'Dummy video device').
After turning on the camera, you should see a black square of almost your own production. To fill it with paints, you need to write raw pictures sequentially, that is, just a sequence of values encoding the colors of the pixels into the device
/dev/videoN. You can do it this way:ffmpeg -an -i some_video.avi -f rawvideo -s 320x240 -pix_fmt bgr24 - | dd obs = $ ((320 * 240 * 3)) of = / dev / videoN
That is, a certain video file is taken, a video stream is extracted from it (
-antells ffmpeg not to pay attention to audio tracks), it is decoded into a sequence of raw images of the right size with the desired format of color information about the pixel, and is written in whole, in a block size ( 320 * 240 * 3) bytes, in avld. If you direct the stream from ffmpeg immediately to
/dev/videoN, then nothing will come of it, because avld believes that each frame is completely provided to it in a separate callwritewith the appropriate file descriptor, and ffmpeg writes its output in small portions, in a few kilobytes, respectively, avld will think that it receives the whole frame, but at the same time receive only a small piece, and because of this give out some kind of porridge. To fix this above and using dd, the obs option tells which blocks to output to the output file. That is, here dd is used as a buffer to accumulate complete information about the frame, and then spit it out as an inextricable block in avld. Actually, everything is with avld. You can record in
/dev/videoNanything you want. It is also useful that avld remembers the last frame and gives it to an application that consumes the video stream from this v4l device. Therefore, you can write in/dev/videoNone picture, and it will appear before the not very clear gaze of the inhabitants of chatroulettes. By the way, yes. MEncoder writes the results of video decoding in raw format just frame by frame, which allows you to use it without dd.
1.2. vloopback
The interface for this thing is much more complicated compared to avld. The reason is that vloopback was not conceived as a fake video camera, but rather as a device like pipe (which | in bash) for realtime video processing. In this regard, this thing has a rather sophisticated set of options, and a rather complicated program interface, which may require the use of special utilities to configure the parameters of these very videopipes, which, for example, can scale video (right inside the kernel, yes ... Linux happens weird). But if the goal is to get fun, and not to understand all the intricacies of vloopback, then you can act in a simple way.
First, of course, you need to load the module into the kernel:
modprobe vloopback pipes=Mwhere the pipes parameter can be used to request vloopback to create the appropriate number of pipes. After loading, vloopback will tell you where the
/devnames for the inputs and outputs of the corresponding channels will be placed in . You can view this information as follows:$ dmesg | grep vloop [vloopback_init]: video4linux loopback driver v1.4-trunk [vloopback_init]: Loopback 0 registered, input: video0, output: video1 [vloopback_init]: Loopback 0, Using 2 buffers [vloopback_init]: Loopback 1 registered, input: video2, output: video3 [vloopback_init]: Loopback 1, Using 2 buffers
For each channel, there are two names in
/dev, pretending to be a v4l device, of course, the output of the channel, and the data for this device is written to input. But the protocol for writing to the vloopback channel, although simple, is not trivial, as is the case with avld, and you will have to use a utility with a harsh name to write a sequence of frames to the channel mjpegtools_yuv_to_v4l. This package is not in the repositories and AUR Arch Linux, so I personally had to compile this utility from the sources, which is quite simple: (1) unpack the sources www.filewatcher.com/m/mjpegtools_yuv_to_v4l-0.2.tgz.11065.0.0.html , ( 2) run make.Now, everything is ready to send the video stream to the vloopback channel. However, vloopback requires gentle treatment, so that nothing hangs, you need to follow some rules. Firstly, you always need to start the video stream in vloopback first, then start the application that will read data from the video device. To stop work, you must first close the application that reads, and then writes the data to the vloopback channel. In short, as in the stack.
In addition, vloopback requires adjusting the geometry and presentation format of the pixel, this can be done using mplayer. So, first the video stream to the vloopback channel:
ffmpeg -an -i some_file.avi -f yuv4mpegpipe -s 320x240 -pix_fmt yuv420p - | mjpegtools_yuv_to_v4l / dev / video0
In this case, the browser with flashplugin should not be launched. Before you open any kind of chat roulette in it, you need to configure / check the output end of the video channel. This can be done using mplayer.
mplayer tv: // -tv 'driver = v4l: width = 320: height = 240: device = / dev / video1'
After completing mplayer, you can launch a browser with some chat roulette and select a newborn virtual camera. REMEMBER: so that nothing hangs, you must first close the browser (or disable flashplugin), and only then stop recording frames in the channel.
2. Content.
So, virtual cameras, perceived by flashplugin, are now known how to do. But how to fill them - that’s the question. In general, when I started this all, I had an acute desire to check: either my face is crooked, or in these chatroulets people are sitting there to constantly poke on the next button.
Therefore, the first thing I wanted to do was to become a “man in the middle” between two users, that is, broadcast the video stream of the first to the second and, of course, vice versa. You can probably get into flashplugin behind this video stream through preloaded libraries, but it is long and difficult. It's easier to take a finished picture from the screen. ffmpeg will help with this (for avld):
ffmpeg -f x11grab -s 320x240 -r 15 -i: 0.0 + x_offset + y_offset -f rawvideo -pix_fmt bgr24 - | dd obs = $ ((320 * 240 * 3)) of = / dev / videoN
The parameter
-rsets fps - the frequency of taking frames from the screen. And choosing the right parameters x_offset and y_offset a couple of times you can achieve the desired cross-translation and thereby spoil your mood, because it immediately catches your eye that the people are really sitting and stupidly pressing the next button, regardless of who they see in front of them (which gives rise to the hypothesis that all these chatroulets are the machinations of manufacturers of mice and keyboards hoping for faster wear of some buttons). Perhaps this behavior is a manifestation of the social analogue of Newton’s second law, when the body in the absence of forces (if, in the conditions of symmetry of the environment) moves linearly and uniformly.But then another question arises: how to attract the attention of people (preferably, the attention of girls)? In general, what is positive, a good degree of attractiveness is the translation of the desktop (for those who are not quite in the topic, the beginning of the team):
ffmpeg -f x11grab -s 1680x1050 -r 15 -i: 0.0 ...
on which, for example, a game of chess is open or something more or less intellectual. Of course, on the desktop you can also post your bright and thoughtful face, showing the video stream from a real camera in a separate window:
mplayer -nosound tv: //
But non-production windows interfere, so there is a desire to overlay various video streams in memory, and then send them to a virtual webcam. Of course, again, you can try to find a utility that does this, but you can also remember that the X-Window itself provides good opportunities for imposing anything on anything.
3. Xvfb
So that you can draw in a virtual framebuffer, this is a buffer, first, of course, you need to create and run:
Xvfb: 1-screen 1 640x480x32
this creates a virtual display 1 with a new screen 1, the resolution and color depth should be obvious with which ones (Yoda master). Well, that’s it. Further is as obvious. You can send a video stream of your desktop to this virtual display:
export DISPLAY =: 1.1; ffmpeg -f x11grab -s 1680x1050 -r 15 -i: 0.0 -f yuv4mpegpipe -pix_fmt yuv444p -s 640x480 - | ffplay -f yuv4mpegpipe -
ffplay at initialization will see the DISPLAY environment variable and understand which X-server it is drawn on (I use yuv4mpegpipe here to write fewer keys on the receiving side of the pipe, but it’s clear that the color is converted to yuv444, and then from it to draw pictures add processor load, it’s more efficient to use -f rawvideo, but then you’ll have to specify the pixel format and frame size everywhere). Next, you can overlay your video image on this mess:
mplayer -nosound tv: // -tv 'width = 160: height = 120' -display: 1.1 -geometry + $ ((640 - 160 - 10)) + $ ((320 - 120 - 10))
Well, send the video stream to the virtual video camera:
ffmpeg -f x11grab -s 640x480 -r 15 -i: 1.1 -f rawvideo -s 320x240 ...
OK, at this moment we have a picture in a picture, and we can show others our chess abilities, etc. etc. But, unfortunately, the reality is harsh and pornographic. Most of all people (including girls) living in chatroulets are hooked by a video series where couples make love in front of webcams (yeah, people like to peep).
4. Crop
But most of these videos that you can get on the Internet ...
(By the way, here’s a simple way to pull out video from any flash media in firefox. Now flashplayer-10.0.42.5 works with video content like this: it starts downloading the video through the browser’s cache, and while the video is buffering, the corresponding file is in the cache firefox, but when the buffering ends, the file is deleted, it just remains open, and flashplugin can read it. But, Linux and we, naturally, to save this file on your disk, you need to make a hard link to it. Therefore, if you want to save the video, then open the page with it, then id those in the properties and clean your browser's cache will remove all but the desired video, making it hard link command
ln, well, everything - I've found yours.So, most videos of dubious content on the Internet are hung with all sorts of different logos and running lines that you need to get rid of so as not to destroy the illusion of those watching. Of course, you need to get rid of them by cutting out clean video material from the whole picture. To do this, the ffmpeg - crop video filter is suitable (crop in Nashnensky). But this filter works severely and if you write something like:
ffmpeg -an -i some_video.avi -vf crop = 32: 32: 400: 300 -f rawvideo -s 320x240 ...
then you are scolded for the fact that the box with the coordinates (left_up - right_low) (32.32) - (432.332) does not fall into a 320x240 frame, that is, ffmpeg first scales the frame, and then tries to apply the crop filter to it. Of course, you can run
bc -land calculate everything you need in order to finally get a clean picture of a suitable size, but this is tiring, you can use the pipeline instead:ffmpeg -an -i some_video.avi -vf crop = 32: 32: 400: 300 -f yuv4mpegpipe - | ffmpeg -f yuv4mpegpipe -i - -f rawvideo -s 320x240 -pix_fmt ...
Well, here you can say this to everyone: thank you for your attention, happy video creativity in the open spaces of chat roulettes. But I still pogromomania, for a long time I did not write on Habré.
5. Atom users.
In general, for all these entertainments, the performance of some not the most powerful Athlon II X2 is more than enough. You can still watch a couple of films (at the same time) in p720 resolution at this time. But now the single-core Atom pulls this badly, and I want to somehow squeeze extra fps out of it.
And here, despite the symmetry of its hardware threads, installing affinity for different groups of processes can help. This is probably due to the fact that the scheduler does not distinguish between hardware threads, considering them to be completely equal entities, and freely throws processes between them. BUT, after all, TLB of these threads should be different. And when the process is thrown, forced switching of these same TLBs occurs. If firefox mixes up with ffmpeg in its execution, then, in order to switch from one to another within the x86 architecture, you need to completely reset the TLB and reload it with new data.
Therefore, productivity increases slightly if you nail with
taskset -c 1 firefox
firefox to the second thread, and all processes associated with the processing of any video to the thread of the first thread (with number 0). Two or three frames per second can be won in this way.
6. Audio.
But I did not manage to build a virtual microphone from ALSA. And this despite the fact that ALSA has a native loopback driver called aloop. And it really works as expected: everything that is written into one of its channels can be read from the corresponding other channel. The jack-server works fine with it, and you can transfer sound between different applications in different ways. But to build from this aloop something that would look like a virtual microphone did not work out for me. But, probably, it’s possible, I just didn’t have the patience and time to understand these ALSA wooden configs.
And so, this would open the way to audio advertising on the open spaces of chat roulettes. If anyone comes out with this, write an article on Habré, I promise to use karma for that :) :)
Well, that's it.
I hope it was not boring and boring. Have fun, and all that.
