On 2015-04-23 15:51, Mario Mey wrote:
Well, I don't know if I was on 'video' group but I did the addition. I checked the file you sent me and it works. However, for the moment, I have 3 questions:
- If I don't activate the device in the right side of the patch, nor
Blender nor VLC can get the image from /dev/video1 (VLC shows errors on console, Blender says nothing, but it makes black texture) Why is like that? Supposedly, being pix_record there and activated, I should get from where I want...
this could have a multitude of reasons. i would suggest first checking what those errors are that VLC throws (chances are they mean something). then try using gstreamer(-0.10!) to display the video. something like: $ gst-launch0.10 v4l2src device=/dev/video1 ! ffmpegcolorspace ! xvimagesink
- Look at the attached image: why the video is vertically inverted? I
don't know about GEM, but I didn't find any object that do that.
it's the olde discrepancy between openGL image coordinates (starting in the lower left corner) and most other pixel coordinates (starting in the upper left corner), and a small bug in the old recordV4L2 implementation of Gem (which should be fixed in recent git). iirc putting a [pix_flip] before [pix_record] might fix the problem.
anyhow, this means that the v4l2loopback output is working. so that leaves two more potential candidates for your problem:
- the v4l2loopback kernel module (there are some known issues with e.g.
gstreamer-1.0; which version are you using?)
- the consumer applications (blender/vlc): while working on the
v4l2loopback module i noticed that quite a number of v4l2 applications make unjustified assumptions about the v4l2 device, which sometimes are not satisfied by v4l2loopback. (like refusing to work when the card_name does not match the device-name...)
- How the patch should be if I want to send the GEM window to loopback?
I mean, not only the color and vertical inverted video, but the whole window...
checkout [pix_snap] to fetch a framebuffer into pixes.
fgasm IOhannes