Chromium cannot detect v4l2loopback device using exclusive_caps=1

[CatoMaior]

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]

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

[CatoMaior]

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

[sqwishy]

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; 0569340

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]

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 0569340

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

[derneue]

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]

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]

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

[takov751]

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]

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]

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: #274 (comment)

[alepez]

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]

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]

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]

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

[umlaeute]

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]

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]

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]

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]

@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]

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]

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]

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

[xslendix]

@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]

yes

[juerg-altwegg]

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]

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]

@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]

@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]

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

[Samurai336]

@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]

@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]

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]

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]

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]

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

"YUY2" packed 4:2:2 YUV

[umlaeute]

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]

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]

@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]

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]

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]

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]

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]

Am 12. Dezember 2020 14:20:05 MEZ schrieb peter <[email protected]>:

hy, thanks, but

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

[gaga9999]

why? just guessing?

[umlaeute]

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]

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

[sesse]

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]

good, but how to find out which are supported?

[sesse]

On Sat, Dec 12, 2020 at 11:12:44AM -0800, peter wrote: good, but how to find out which are supported?

1. Trial and failure 2. Consult the program's documentation, if any 3. Read the fine source /* Steinar */ -- Homepage: https://www.sesse.net/

[gaga9999]

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]

something there doesnt fit to v4l2.

probably. i honestly believe the issue is there rather than with v4l2 (or v4l2loopback)

[guest271314]

I am able to detect and capture the virtual device on Chromium 89, Firefox 84 throws "AbortError" "Starting video failed".

[sim590]

As a complementary solution for people having trouble with Chromium, the following may be of interest:

https://www.scs.stanford.edu/~dm/blog/hide-webcam.html

This post suggests to hide other webcams (the source webcams that are used by OBS for instance to create the new virtual camera) so that Chromium doesn't try to use it and fail. Then, it will find the virtual camera.

Personally, I had issues and at first I did solve it with exclusive_caps=1 on Debian, but at some point it ceased to work. I guess as this stackoverflow post suggests, versions >0.12.3 of v4l2loopback-dkms may caused this change. As I could not go back to 0.12.3, to test this (I'm having compilation errors when I try to), then I decided the test the blog's suggestion. In the end, it is really what fixed it for me. The relevant part of the blog is the following:

SUBSYSTEM!="video4linux", GOTO="hide_cam_end"
ATTR{name}=="v4l2lo[0-9]", GOTO="hide_cam_end"

ACTION=="add", RUN+="/bin/mkdir -p /dev/obs-only"
ACTION=="add", RUN+="/bin/mv -f $env{DEVNAME} /dev/obs-only/"
ACTION=="add", ATTR{index}=="0", RUN+="/bin/ln -fs $name /dev/obs-only/$env{ID_SERIAL}"

ACTION=="remove", RUN+="/bin/rm -f /dev/obs-only/$name"
ACTION=="remove", RUN+="/bin/rm -f /dev/obs-only/$env{ID_SERIAL}"

LABEL="hide_cam_end"

about an udev rule file which will hide cameras. Virtual devices created with v4l2loopback have to be properly named also for this to work:

# modprobe v4l2loopback nr_devices=2 exclusive_caps=1,1,1,1,1,1,1,1 video_nr=0,1 card_label=v4l2lo0,v4l2lo1

I'm not sure all of those options are necessary, but the naming as v4l2lo* is important to fit with the udev rule.

Hope this will help some.