Webcam Vchan support

[ctr49]

The problem you're addressing (if any)
I often have problems with passing through my USB webcam. Sometimes it works, sometimes not. Most often it works but then breaks after some time. Passing through an entire device to use its functionality is also not what I would consider "Qubes-native".

Describe the solution you'd like
Instead, the video stream (assuming people use a dedicated microphone) should be passed through a vchan, much like audio is).

Where is the value to a user, and who might that user be?
Potentially increased security from not passing the (USB) device into the target domain and imho a better stability.

Describe alternatives you've considered
Passing through the USB device. Which breaks often.

Additional context
This is a proof-of-concept that works fine for me: https://gist.github.com/ctr49/24bb4986e9878e50ceca60167f7acf67
Some fine-tuning is needed to make this work for many other environments or webcams, but it is already working fine for me.
My goal was minimal interaction (i.e. video processing) in the USB qube. That's why I use v4l-ctl to stream the raw video rather than using ffmpeg in the USB qube already.

[iamahuman]

I often have problems with passing through my USB webcam. Sometimes it works, sometimes not. Most often it works but then breaks after some time.

You might have luck with increasing memory allocated to the USB VM.

This is a proof-of-concept that works fine for me: https://gist.github.com/ctr49/24bb4986e9878e50ceca60167f7acf67
Some fine-tuning is needed to make this work for many other environments or webcams,

Also, a scheme to negotiate video resolution, format and codec. I'm not sure how it should be designed, though.

My goal was minimal interaction (i.e. video processing) in the USB qube. That's why I use v4l-ctl to stream the raw video rather than using ffmpeg in the USB qube already.

How about ditching FFmpeg completely and using v4l2-ctl --stream-from=- ... from the receiving side?

[DemiMarie]

I often have problems with passing through my USB webcam. Sometimes it works, sometimes not. Most often it works but then breaks after some time.

You might have luck with increasing memory allocated to the USB VM.

This is a proof-of-concept that works fine for me: https://gist.github.com/ctr49/24bb4986e9878e50ceca60167f7acf67
Some fine-tuning is needed to make this work for many other environments or webcams,

Also, a scheme to negotiate video resolution, format and codec. I'm not sure how it should be designed, though.

Do most cameras support this natively?

My goal was minimal interaction (i.e. video processing) in the USB qube. That's why I use v4l-ctl to stream the raw video rather than using ffmpeg in the USB qube already.

How about ditching FFmpeg completely and using v4l2-ctl --stream-from=- ... from the receiving side?

👍

This might also be a motivation to improve qrexec throughput.

[iamahuman]

I often have problems with passing through my USB webcam. Sometimes it works, sometimes not. Most often it works but then breaks after some time.

You might have luck with increasing memory allocated to the USB VM.

This is a proof-of-concept that works fine for me: https://gist.github.com/ctr49/24bb4986e9878e50ceca60167f7acf67
Some fine-tuning is needed to make this work for many other environments or webcams,

Also, a scheme to negotiate video resolution, format and codec. I'm not sure how it should be designed, though.

Do most cameras support this natively?

I meant negotiation between the source VM and the destination VM. This is needed especially due to varying resolution/format support from different cameras.

My goal was minimal interaction (i.e. video processing) in the USB qube. That's why I use v4l-ctl to stream the raw video rather than using ffmpeg in the USB qube already.

How about ditching FFmpeg completely and using v4l2-ctl --stream-from=- ... from the receiving side?

👍

This might also be a motivation to improve qrexec throughput.

As far as thoughput is considered, we should use the approach taken by GUI Agent to transfer framebuffer from AppVM to GUI VM. A simple implementation would be grant refs (perhaps abstract these for other VMMs) + v4l2-ctl --stream-mmap.

[marmarek]

Duplicate of #2079 ?

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.