Shared publicly  - 
 
did not try it yet, but sounds good!
jessor originally shared:
 
Linux Screensharing in Google Hangouts

1. Get https://github.com/umlaeute/v4l2loopback
2. Build and load module (use modprobe v4l2loobpack debug=(1|2) for testing)
3. Compile yuv4mpeg_to_v4l2.c from experimental branch
4. mkfifo pipe
5. ./yuv4mpeg_to_v4l2 < pipe
6. cvlc --vout=yuv --yuv-yuv4mpeg2 --yuv-chroma=I420 --yuv-file=pipe screen:// --screen-width 640 --screen-height 360 --screen-fps 3 --screen-caching 200 --screen-top 75
7. ???
8. PROFIT =)

Play with transcode to get a higher cutout.
v4l2loopback - v4l2-loopback device
1
Maximilian Rehkopf's profile photoRalf Ertzinger's profile photoTobias Diedrich's profile photoCamrto Verievil's profile photo
8 comments
 
I have to admit that I completely fail to see the use case for this.

If I read the above right it uses vlc to grab the actual screen content and pushes it into the kernel, through the v4l sublayer, so that a second program can view the original screen content via a pseudo v4l device.

While this is certainly nice, why do I have to do this? If program A can grab the screen content in the first place, surely so can program B.
 
Headline: "Linux Screensharing in Google Hangouts".
The Google Talk plugin only captures from v4l devices. Or maybe, more generally, from /dev/video*. I don't know.
 
And that's fine and well for actual video devices, like, you know, a camera.

However, I seriously doubt anyone goes to the trouble of routing the screen content through the kernel on Windows or OSX.
 
Well, if anyone would care implement a libasound-like solution where you can have software-side dmix and other plugins we wouldn't have this problem :)
 
very good, this is great!!. do you know why yuv4mpeg_to_v4l2 stops controlling the pipe when video ends? is this the behavior of pipes?. I am using mplayer BTW "mplayer video.mp4 -vo yuv4mpeg:file=/tmp/pipe" and even when i put at tail an other stream it crashes the whole. I cannot think it is mplayer's bug. or yuv4mpeg_to_v4l2's bug. Any way will check everything and see who is shitting around ;-)
 
I'm pretty sure that's normal pipe behaviour - if you close one end of the pipe the other gets EOF. For example if you try "mkfifo /tmp/pipe; cat /tmp/pipe & echo foo > /tmp/pipe" the cat will return once echo closes it's end.
Add a comment...