[Bug]: Device lose video capture capability!

[GreatAg]

Is there an existing issue for this?

• [X] I have searched the existing issues

Detail

I am using v4l2loopback for webcam as a virtual device in container for chrome application. Here is the scenario: 1- i build the source and load the devices with exclusive_caps 2- i run the container and map the device into container using --device flag 3- open the webcam test in chrome and everything is fine 4- delete the container and run again 5- that device no longer known as a webcam or capture device!!

I run v4l2-ctl device=/dev/video2 --all before and after using it in container and find out after destroy the container the device lose it's capture device capability!!

Here is the log before i run container at fresh loading:

root@dmz:/var/modules/v4l2# v4l2-ctl --device=/dev/video2 --all
Driver Info:
    Driver name      : v4l2 loopback
    Card type        : test
    Bus info         : platform:v4l2loopback-002
    Driver version   : 5.4.255
    Capabilities     : 0x85200002
        Video Output
        Read/Write
        Streaming
        Extended Pix Format
        Device Capabilities
    Device Caps      : 0x05200002
        Video Output
        Read/Write
        Streaming
        Extended Pix Format
Priority: 2
Video output: 0 (loopback in)
Format Video Output:
    Width/Height      : 0/0
    Pixel Format      : 'BGR4' (32-bit BGRA/X 8-8-8-8)
    Field             : None
    Bytes per Line    : 0
    Size Image        : 0
    Colorspace        : sRGB
    Transfer Function : Default (maps to sRGB)
    YCbCr/HSV Encoding: Default (maps to ITU-R 601)
    Quantization      : Default (maps to Full Range)
    Flags             : 
Streaming Parameters Video Capture:
    Frames per second: 30.000 (30/1)
    Read buffers     : 2
Streaming Parameters Video Output:
    Frames per second: 30.000 (30/1)
    Write buffers    : 2

User Controls

                    keep_format 0x0098f900 (bool)   : default=0 value=0
              sustain_framerate 0x0098f901 (bool)   : default=0 value=0
                        timeout 0x0098f902 (int)    : min=0 max=100000 step=1 default=0 value=0
               timeout_image_io 0x0098f903 (bool)   : default=0 value=0

And this is after i remove the container:

root@dmz:/dev# v4l2-ctl --device=/dev/video2 --all
Driver Info:
    Driver name      : v4l2 loopback
    Card type        : test
    Bus info         : platform:v4l2loopback-002
    Driver version   : 5.4.255
    Capabilities     : 0x85200000
        Read/Write
        Streaming
        Extended Pix Format
        Device Capabilities
    Device Caps      : 0x05200000
        Read/Write
        Streaming
        Extended Pix Format
Priority: 2

User Controls

                    keep_format 0x0098f900 (bool)   : default=0 value=0
              sustain_framerate 0x0098f901 (bool)   : default=0 value=0
                        timeout 0x0098f902 (int)    : min=0 max=100000 step=1 default=0 value=0
               timeout_image_io 0x0098f903 (bool)   : default=0 value=0

What is wrong? what is modifying the device? how can i resolve this?

v4l2loopback version

0.12.5

kernel version

Linux dmz 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

OS Version

Ubuntu 20.04

Which CPU are you using?

amd64/x86_64 ("64bit Intel")

[umlaeute]

1. Please check with the latest release of v4l2loopback(at the time of writing this is 0.13.2)
2. If this doesn't help, please provide actual commands to reproduce the problem on a pristine machine (eg rather than "run the container" I would expect something like docker run --rm -ti alpine:latest bash

[GreatAg]

Thanks for the replay, I run my container using this command: docker run -d --device=/dev/video2 ubuntu:20:04 which i have chrome installed in that image and i want to use webcam in container.

[GreatAg]

also i checked the latest version and the problem still there. This is really weird.

[umlaeute]

I run my container using this command:

that was really just an example. i would need all commands you run, and I need know where you run each of them (within the container, or outside).

e.g. in your example there is no a producer anywhere.

[GreatAg]

You can take a look at kasm application (https://kasmweb.com/) I am doing pretty much the same thing in my app Also kasm using v4l2loopback

[umlaeute]

sorry, I don't think i will (find the time to) checkout kasm, just to reproduce this issue.

please try to provide a minimal reproducible example.

[GreatAg]

Thanks, you are right If it is possible help me by answering my question to fix my problem. I install v4l2loopback by building the source rather than using dkms in every update of my app i upgrade the kernel (apt upgrade) and then build and load v4l2loopback modules without rebooting the OS, does it a problem? When i remove the older version of the kernel, i build and load v4l2loopback module again and everything was fine. What is the problem you think? And please tell me how can i entirely remove v4l2loopback from my kernel like it never was exist?

[umlaeute]

in every update of my app i upgrade the kernel (apt upgrade) and then build and load v4l2loopback modules without rebooting the OS, does it a problem?

1. you have to unload the module (rmmod v4l2loopback), before you can load the module again (same version or older version)
2. if you just upgrade the kernel, you are still running the old kernel; in order to run the new kernel, you have to reboot (iirc); using kexec and friends will reduce the downtime, but you essentially still need to restart the kernel and restart PID 0 (and everything that depends on it...which is practically everything); i don't know about ksplice

[GreatAg]

Ok i see, So here is the scenario:

1. I already build and load v4l2loopback module
2. I upgrade my kernel
3. reboot the OS
4. build v4l2loopback module again for new kernel
5. load v4l2loopback module

everything should work in this scenario, right?

and what if i use dkms? i shouldnt do stage 4 because dkms build the module for the new kernel automatically right?

[umlaeute]

yes. you can also build the module for a specific kernel without rebooting (e.g. before rebooting), by setting the KERNELRELEASE (make-)variable. i see that this was not mentioned in the README (but is fixed now).