Chromium cannot detect v4l2loopback device using exclusive_caps=1

CatoMaior commented 4 years ago

Hi, thanks for your work. I installed v4l2loopback via apt. After running sudo modprobe v4l2loopback exclusive_caps=1 Chromium (version 80.0.3987.162 snap) does not detect the loopback device. I have also tried to set a name for my interface with card_label="Test"but nothing changes.

v4l2loopback version: 0.12.2
kernel version: 5.3.0-45-generic
Distribution: Distributor ID: Ubuntu Description: Ubuntu 19.10 Release: 19.10 Codename: eoan

umlaeute commented 4 years ago

do you have a producer running that sends data to the device?

CatoMaior commented 4 years ago

Yes, I am using OBS with obs-v4l2sink by @CatxFish

sqwishy commented 4 years ago

Me too!

uname -a: Linux coconut 5.5.11-200.fc31.x86_64 #1 SMP Mon Mar 23 17:32:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Compiled from the most recent commit of v4l2loopback; 0569340b0dfd85cbb26d4dabf8051cae461af443

I get a traceback from my kernel when I modprobe using exclusive_caps=1. Here they are https://paste.centos.org/view/raw/c91ec727

ctubbsii commented 4 years ago

I had the same issue. I couldn't get the device detected by either Chrome or Slack.

EDIT: I got it to work fine with the HEAD commit 0569340b0dfd85cbb26d4dabf8051cae461af443

sudo modprobe v4l2loopback devices=1 video_nr=10 card_label="LoopbackCam" exclusive_caps=1

derneue commented 4 years ago

You can also try it with this one:

modprobe v4l2loopback devices=1 max_buffers=2 exclusive_caps=1 card_label="VirtualCam"

and ffmpeg:

ffmpeg -i SOMEDATA -f v4l2 /dev/video0

It works for me in both chrome and firefox. Check it with https://webcamtests.com/

takov751 commented 4 years ago

My experience so far . When i use a general mp4 video it does works even in electron apps. However i used gphoto2 to stream dslr feed over usb as a v4l2 device no chrome/electron based application could access it. OBS , vlc ,firefox works like a charm. I would suspect , that there is a specific format which causing the trouble

umlaeute commented 4 years ago

@takov751 most likely it's some specific video-format (like BGRA) that is not liked. try to find out which one.

takov751 commented 4 years ago

Case solved I have created a /etc/modprobe.d/v4l2loopback.conf file with this content:

options v4l2loopback devices=1 video_nr=10 card_label="VirtCam" exclusive_caps=1 max_buffers=2

with this it did worked, however some extra workaround for gphoto2 i used this script to make output more generic format:

#/bin/bash

gphoto2 --stdout --capture-movie | ffmpeg -i - -f rawvideo -pix_fmt yuv420p -threads 0  -s:v 1280x720 -r 25 -f v4l2 /dev/video10

sesse commented 4 years ago

Chrome is very picky about which formats it wants to support. It supports (from v4l2_capture_delegate.cc):

V4L2_PIX_FMT_YUV420, 
V4L2_PIX_FMT_Y16, 
V4L2_PIX_FMT_Z16, 
V4L2_PIX_FMT_INVZ, 
V4L2_PIX_FMT_YUYV, 
V4L2_PIX_FMT_RGB24, 
V4L2_PIX_FMT_MJPEG, 
V4L2_PIX_FMT_JPEG

derneue commented 4 years ago

On 14.04.2020, Steinar H. Gunderson wrote:

Chrome is very picky about which formats it wants to support. It supports (from v4l2_capture_delegate.cc):
V4L2_PIX_FMT_YUV420, 
V4L2_PIX_FMT_Y16, 
V4L2_PIX_FMT_Z16, 
V4L2_PIX_FMT_INVZ, 
V4L2_PIX_FMT_YUYV, 
V4L2_PIX_FMT_RGB24, 
V4L2_PIX_FMT_MJPEG, 
V4L2_PIX_FMT_JPEG
Ok thats interesting. This could solve my problems with gstreamer and chromium in the past.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/umlaeute/v4l2loopback/issues/274#issuecomment-613308856

alepez commented 4 years ago

I'm having the same issue with OBS + Chrome.

Module is loaded with these parameters:

modprobe v4l2loopback devices=4 video_nr=10,11,12,13 card_label="loop 0","loop 1","loop 2","loop 3" exclusive_caps=1,1,1,1 debug=1

OBS is configured to stream content to v4l2sink /dev/video10 with format YUV420 (it should be supported by chrome)

When the streaming starts, these lines appear in kernel log:

[169592.603528] v4l2-loopback[1858]: opened dev:000000007942450e with image:00000000b9a631fe
[169592.603537] v4l2-loopback[1003]: s_fmt_out(0) 1...1382400
[169592.603538] v4l2-loopback[1006]: outFOURCC=YU12

If I open the loopback device with mplayer, it shows as expected.

v4l2-ctl says that the device has Video Capture capability (only while obs is streaming)

Chrome is correctly listing the device on camera setting screen:

When I start using the camera (e.g. with webcamtoy.com) the camera does not appear as available.

I can use the loopback device with Discord. In Microsoft Teams for Linux, it appears as available, but the preview is black. Firefox has the same behavior as Chrome.

I think it is Chrome/Firefox fault, but is there any trick to make it working?

Bostwickenator commented 4 years ago

I'm getting this too. I was suspecting colourspace but I'm using V4L2_PIX_FMT_RGB24 so it seems from @sesse's info that should work. I'll dig a little further in and try other colourspaces just to make sure.

edit: It turns out Chromium wasn't detecting the video devices after I set exclusive caps until I restarted my machine. Now it's working as expected.

mjg commented 4 years ago

gphoto2 --stdout --capture-movie | gst-launch-1.0 fdsrc ! decodebin3 name=dec ! queue ! videoconvert ! v4l2sink device=/dev/videoX works with a DSLR over here (chrome, v4l2loopback with exclusive_caps), maybe it helps with chromium as well. Takes a bit of CPU, though, and outputting OBS to another loopback device takes even more.

derneue commented 4 years ago

Maybe you would like to update the v4l2loopback wiki on github with these informations. It would help other people a lot.

umlaeute commented 4 years ago

PRs welcome (github doesn't really supports PRs on wikis though; so sending a git format-patch via the issue-tracker would do as well)

stephematician commented 4 years ago

I was able to get v4l2loopback to operate ok in non-Chromium apps, e.g. (g)uvcview, firefox, teams, with the v4l2loopback-dkms (version 0.10.0-1ubuntu1.2) via

modprobe v4l2loopback
ffmpeg -i /dev/video0 -f v4l2 /dev/video1

I had no luck with Chromium (with or without exclusive_caps=1).

Build and install from source did eventually work (but complain about signing, and it would cause depmod -a to produce depmod: ERROR: fstatat(3, v4l2loopback.ko): No such file or directory) however (g)uvcview now fails, while firefox, teams, still worked (small price to pay). Chromium still fails regardless of exclusive_caps setting.

I should add this is on Ubuntu 18.04, with Linux 4.15.0-99-generic x86_64

rtbentley commented 4 years ago

I'm going to add the following:

I was experiencing similar symptoms. OBS + obs-v4l2sink by @CatxFish + v4l2loopback would work just fine in Firefox, Microsoft Teams and Zoom. It would not work in Chromium, Chrome or Slack. I would not even see the option for the Dummy Video device. The exclusive_caps=1 option did not seem to make any difference.

I then started playing with resolution in OBS, eventually taking Settings | Video | Base (Canvas) Resolution down to 640x480. At that point the Dummy Video Device did appear in Slack, Chrome and Chromium as well. After that I was able to take it back up to my regular resolution in OBS: Base (Canvas) Resolution of 1920x1080 and Output (Scaled) Resolution of 1280x720. It still worked.

I did successive rmmod v4l2loopback and modprobe v4l2loopback exclusive_caps=1. I restarted the machine. It just works now as long as exclusive_caps=1 is there.

Occasionally on the first time I make a call in Slack I will see the option for the Dummy Video Device but it will be black -- whether I'm running the desktop app or running Slack in Chrome. If I hang up the call and immediately call back, I then see the video. I have not had to take the resolution back down again.

I don't know if this will help. I'm half doubting my own trouble-shooting, but this has not worked for me for a long time and suddenly it does. In any case, if someone else is up against the same thing, try changing resolutions in the OBS video settings.

My configuration is bog standard if a little dated:

Xubuntu 18.04
Kernel 4.15.0-112-generic
obs-studio package, from the obsproject PPA, version 25.0.8-0obsproject1~bionic
v4l2loopback-dkms package from the distribution, version 0.10.0-1ubutu1.2
obs-v4l2sink package, the 0.1.0 release from @CatxFish
Slack version 4.8.0 64 bit
Default Chromium package, chromium-browser, 84.0.4147.105-0ubuntu0.18.04.1
Chrome 84.0.4147.105, official build, 64-bit

CMCDragonkai commented 4 years ago

I wanted to know if it is possible to enable exclusive caps on 1 device, but disable it on another device. So that way I can have /dev/video2 be usable by Skype... etc, while /dev/video3 is usable by Chromium. Thus when switching on obs sink I just have to change which sink to use.

umlaeute commented 4 years ago

@CMCDragonkai this seems to be a new question (even if it is somewhat related to the issue at hand), so it shouldn't be a follow up here.

also, this issue tracker is not a support-forum. please use stackoverflow for such kind of questions.

xslendix commented 4 years ago

I have the same issue, I tried running sudo modprobe v4l2loopback devices=2 video_nr=0,10 card_label="Webcam","OBS" exclusive_caps=1 but without any luck with chromium. It did work before but now its just dead. However, I have found sudo modprobe v4l2loopback alone to work but I need the second camera too. This is for chromium 85.0.4183.121 on Void Linux by the way.

Bostwickenator commented 4 years ago

I found during my testing of this feature that Chromium didn't pick up changed v4l2loopback config without a restart of the machine. Also you might want to set a scale factor on the seekviewer I've found some apps like Zoom ignore devices smaller than QVGA. Best of luck!

umlaeute commented 4 years ago

@xslendix your second device lacks the exclusive_caps property. see sudo modinfo v4l2loopback

xslendix commented 4 years ago

@xslendix your second device lacks the exclusive_caps property. see sudo modinfo v4l2loopback

so like this?

sudo modprobe v4l2loopback devices=2 video_nr=0,10 card_label="Webcam","OBS" exclusive_caps=1,1

umlaeute commented 4 years ago

yes

juerg-altwegg commented 4 years ago

I was experiencing similar symptoms on Ubuntu Studio 20.04 linux with OBS Studio 26.0.2: Discord and MPlayer are viewing the stream from virtual camera as expected. Within Firefox (e.g. WebEx or webcamtest) and Zoom the virtual camera can't even be selected. Both applications have been working for a while before. As far as I can see, after an update by apt, the described behavior started. So what happened?

After fiddling around with video device numbers, user rights, app-armor etc. no success with firefox nor zoom. Shortly before reinstalling the whole system (because starting an ubuntu from a live stick where everthings works fine), I found this thread. Thus, I saw the option debug=1 which guided me to the problem.

I did a make and make install on my system. The command v4l2loopback-ctl -v shows "v4l2loopback-ctl v0.12.5" so everthing seems fine. But the syslogs says otherwise (thanks to the debug=1 option): Version 0.12.3 and the usage of a DKMS path which points to a different module than the freshly compiled one (Dynamic Kernel Module Support). Bang!

After using the dkms commands as mentioned in the readme firefox and zoom are working like a charm. Thus, make sure the loaded kernel module is the right one (0.12.5 or later). Unfortunately, chromium browser still doesn't work on my system.

Samurai336 commented 4 years ago

I am having this issue too, but I am not having the problem consistently between applications. It works with Discord and chrome, but it does not work with firefox, cheese, skype and zoom. I've tried what folks are suggesting here and get the same applications that work and don't work. I am on Linux Mint 20, let me know what else I can provide.

umlaeute commented 4 years ago

@Samurai336 if some applications don't work, then it's likely an issue with the capabilities of these applications. e.g. they only support a given colorspace andn/or resolution.

@juerg-altwegg v4l2loopback-ctl -v really shows the version of the utility, which can (obviously) be different from the module loaded.

Samurai336 commented 4 years ago

@umlaeute To clarify, they were previously working and I haven't changed any settings in OBS, but I'll play around and see if that changes anything.

umlaeute commented 4 years ago

@Samurai336 to clarify: what did you change to make them work no longer?

Samurai336 commented 4 years ago

@umlaeute nothing explicit. Initially I used modprobe v4l2loopback video_nr=5 card_label="Virtualcam" then it stopped showing up in any applications, then I did some homework and changed it to modprobe v4l2loopback video_nr=5 devices=1 max_buffers=2 exclusive_caps=1 card_label="VirtualCam" and it started working in some applications as mentioned above.

cupofnestor commented 4 years ago

@umlaeute nothing explicit. Initially I used modprobe v4l2loopback video_nr=5 card_label="Virtualcam" then it stopped showing up in any applications, then I did some homework and changed it to modprobe v4l2loopback video_nr=5 devices=1 max_buffers=2 exclusive_caps=1 card_label="VirtualCam" and it started working in some applications as mentioned above.

I am having a very similar issue. I was having and issue with my pipeline that seems to be solved with max_buffers=x but am now not seeing it in chrome via webRTC. This is with 0.12.5 via DKMS. My eventual target is electron so I may try several versions of that tomorrow. This pipeline was working with 4vl2loopback and an older version of chrome with no need for even the exclusive_caps option so I think it is a chromium thing at this point.

cupofnestor commented 4 years ago

Older versions of Chromium did not work.

Chrome is very picky about which formats it wants to support. It supports (from v4l2_capture_delegate.cc):

V4L2_PIX_FMT_YUV420, V4L2_PIX_FMT_Y16, V4L2_PIX_FMT_Z16, V4L2_PIX_FMT_INVZ, V4L2_PIX_FMT_YUYV, V4L2_PIX_FMT_RGB24, V4L2_PIX_FMT_MJPEG, V4L2_PIX_FMT_JPEG

Turns out YUYV is not an option. I changed my stream to YUV420 and was successful. Here is my gstreamer pipeline:

gst-launch-1.0 -v decklinkvideosrc mode=15 connection=hdmi video-format=1 ! \
video/x-raw,format=UYVY,width=1920 ! \
videoconvert ! \
video/x-raw,format=I420,width=1920 ! \
v4l2sink device=/dev/video0 sync=false

sesse commented 4 years ago

YUYV is an option, but UYVY (Decklink's native format) is not. Converting to YUYV is cheaper and gives better quality than converting to I420.

cupofnestor commented 4 years ago

YUYV is an option, but UYVY (Decklink's native format) is not. Converting to YUYV is cheaper and gives better quality than converting to I420.

Excellent! I guess I'm slightly dyslexic - I totally missed the difference in YUYV<=>UYUV. I'll update my pipeline as 4:2:2 is desirable.

cupofnestor commented 4 years ago

Searching the GStreamer documentation for YUYV yields nada. The closest seems to be:

"YUY2" packed 4:2:2 YUV

umlaeute commented 4 years ago

fourCC-names are not exactly standardized, so there are a couple of duplicates. YUY2 is the very same as YUYV.

see https://www.fourcc.org/yuv.php

cupofnestor commented 4 years ago

Thanks, @umlaeute Using YUY2, my pipeline crashes with the seemingly ubiquitous (-5) error.

gst-launch-1.0 -v decklinkvideosrc mode=15 connection=hdmi video-format=1 ! \
video/x-raw,format=YUY2,width=1920 ! \
videoconvert ! \
video/x-raw,format=I420,width=1920 ! \
v4l2sink device=/dev/video0 sync=false

I will look into debugging gst-launch-1.0.

umlaeute commented 4 years ago

@cupofnestor your pipeline doesn't make sense. you are forcing the decklinkvideosrc to YUY2 (aka YUYV) - which it doesn't support -, and then convert it to I420 (yuv422p) - loosing precision.

gst-launch-1.0 -v decklinkvideosrc mode=15 connection=hdmi video-format=1 ! \
videoconvert ! \
video/x-raw,format=YUY2,width=1920 ! \
v4l2sink device=/dev/video0 sync=false

apart from that: this seems very off-topic for the issue at hand.

cupofnestor commented 4 years ago

You are correct, that is a copy/paste error. ~~The pipeline in your reply fails as well, perhaps my system is to blame.~~

[Edit] System rebooted at some point, this pipeline works.

Agreed that is off-topic but with your permission I would post a follow up if/when I find a working solution for chromium.

gaga9999 commented 3 years ago

My problem is that skype sees the test image from gstreamer but not any image from any other source (black window).

So the gstreamer test src is the format that works - at least with skype. does the gstreamer test src also work for chrome/chromium maybe?

so what works in skype is

gst-launch-1.0 videotestsrc ! videoconvert ! "video/x-raw,format=YUY2" ! v4l2sink device=/dev/video1

it also works without conversion

gst-launch-1.0 videotestsrc ! v4l2sink device=/dev/video1

what only works in vlc - player is

ffmpeg -i http://192.168.1.174:8080/video -pix_fmt yuv420p -threads 4 -f video4linux2 /dev/video1

gstream complains about pipeline not beeing initialized or stuff when using rtsp source or http source, it never works, what is a video4linux problem as it works when using i.e. a file output sink:

gst-launch-1.0 -v souphttpsrc location=http://192.168.1.174:8080/video do-timestamp=false ! videoconvert ! v4l2sink device=/dev/video1

i have paket 12.03 installed and

$ v4l2loopback-ctl -v
/usr/bin/v4l2loopback-ctl 0.6

...i think the problem is somewhat more subtle than wrong colour space?

umlaeute commented 3 years ago

On 12/12/20 10:33 AM, peter wrote:

...i think the problem is somewhat more subtle than wrong colour space?

why do you think so?

in your examples, there's a single (known) working colourspace. please try forcing the working colourspace to YUY2.

your 2nd pipeline (that runs "without conversion") obviously just happens to use a colourspace that works, because both videotestsrc and v4l2sink negotiated a colourspace that happens to also work with skype.

the souphttpsrc source will support (and prefer) different colourspaces than videotestsrc, so the used colourspace will be different.

also note, that some applications are picky about the actual video resolution. videotestsrc will (by default) pick a standard resolution. but souphttpsrc will use the resolution from it's source.

gaga9999 commented 3 years ago

hy, thanks, but

ffmpeg -i http://192.168.1.174:8080/video -pix_fmt yuv422p -c:v huffyuv -f v4l2 /dev/video1

"V4L2 output device supports only a single raw video stream Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument Error initializing output stream 0:0 -- "

yuy2: ffmpeg -i http://192.168.1.174:8080/video -pix_fmt yuv422p -threads 4 -f v4l2 /dev/video1 -pix_fmt yuy2 -still black in skype

is there a list of supported formats for v4l2?

umlaeute commented 3 years ago

Am 12. Dezember 2020 14:20:05 MEZ schrieb peter notifications@github.com:

hy, thanks, but

sorry, but this seems to be a documentation problem of ffmpeg (if at all), rather than a bug in v4l2loopback.

gaga9999 commented 3 years ago

why? just guessing?

umlaeute commented 3 years ago

why? just guessing?

no.

here's what i understand of your problem:

your gstreamer pipelines that either specify a colorspace or use a sink that can provide a default colorspace and resolution work
your ffmpeg commands don't work, but none of your commands tried to set a colorspace that is known to work (i don't think that YUV420P is going to work with chrome)
the cmdline where you tried to make ffmpeg use an alternative colorspace complained about totally unrelated things (namely: multiple video streams)

this brings me to the conclusion that so far you haven't been able to tell ffmpeg to create an output format that matches the required colourspace. this is likely to be a problem with how you call ffmpeg (e.g. because the documentation is incomplete).

since the original answer was "most likely a colourspace problem" and you haven't come up with any evidence that this is not the case (as in: create a video in UYVY that doesn't work), i believe that the original assessment still holds true.

https://github.com/umlaeute/v4l2loopback/#seeking-help

gaga9999 commented 3 years ago

ok, thanks for our elaboration, i understand, but which colorspaces are supported by v4l2? huffyuf is supposed to output 422

sesse commented 3 years ago

On Sat, Dec 12, 2020 at 10:21:47AM -0800, peter wrote:

ok , i understand, but which colorspaces are supported by v4l2? huffyuf is supposed to output 422

There are many different ways to encode 4:2:2 Y'CbCr (in particular: planar, UYVY, YUYV). V4L2 supports a bunch of them, but not all V4L2-using applications do.

/ Steinar / -- Homepage: https://www.sesse.net/

gaga9999 commented 3 years ago

good, but how to find out which are supported?

sesse commented 3 years ago

On Sat, Dec 12, 2020 at 11:12:44AM -0800, peter wrote:

good, but how to find out which are supported?

Trial and failure
Consult the program's documentation, if any
Read the fine source

/ Steinar / -- Homepage: https://www.sesse.net/

gaga9999 commented 3 years ago

for firefox and skype the following works, chrome doesnt detect nothing:

ffmpeg -i http://192.168.1.174:8080/video -pix_fmt yuv422p -threads 4 -vf scale=640:-1 -c:v rawvideo -r:v 25 -pix_fmt yuv420p -f v4l2 /dev/video0

for skype and firefox a higher resolution results in a greenish mess of a picture, something there doesnt fit to v4l2.

umlaeute / v4l2loopback

Chromium cannot detect v4l2loopback device using exclusive_caps=1 #274