Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for split output/capture devices. #322

Open
normanr opened this issue Jul 2, 2020 · 2 comments · May be fixed by #359
Open

Add support for split output/capture devices. #322

normanr opened this issue Jul 2, 2020 · 2 comments · May be fixed by #359
Milestone

Comments

@normanr
Copy link

normanr commented Jul 2, 2020

Being able to attach the consumer before the producer is not possible with exclusive_caps=1. If the consumer if picky about the device capabilities, then it's not possible to revert to exclusive_caps=0. So this feature request proposal is to create device pairs instead of single devices, eg:

with exclusive_caps=0:
/dev/video0 Capabilities: Video Capture, Video Output

with exclusive_caps=1:
/dev/video0 Capabilities: Video Output
and once a producer is attached
/dev/video0 Capabilities: Video Capture

with this proposal (which would add a new flag or change exclusive_caps to an int and maybe use the value 2):
/dev/video0 Capabilities: Video Output
/dev/video1 Capabilities: Video Capture
in this mode video_nr and card_label would be devices * 2 in length with pairs of values being consumed for each output/capture device pair and a given device's capabilities would still be exclusive, but would not change once it was created.

This would also make sense if the linux kernel implemented support for Video4Linux device namespaces (similar to how network namespaces have veth, Video4Linux has v4l2loopback). You might want to run the producer and consumer in different device namespaces, so having two different devices is required for that.

@umlaeute
Copy link
Owner

umlaeute commented Jul 3, 2020

i find split devices ugly as hell.
however, it does solve a few problems, so i might consider it.

the actual API how to create such devices, is probably going to be coupled to the "dynamic device management" (see #282). in any case its not something that will be tackled before the dynamic device management works properly.

@normanr
Copy link
Author

normanr commented Jul 4, 2020

Acknowledged. That makes a lot of sense. I opened this issue instead of commenting on the one for dynamic device management to avoid (what would otherwise have been) an off topic request.

umlaeute added a commit that referenced this issue Jul 5, 2020
this is the basic groundwork for having split OUTPUT/CAPTURE devices
(from the public API pov)

Related: #322
@umlaeute umlaeute added this to the dynamic device managment milestone Oct 12, 2020
@umlaeute umlaeute linked a pull request Oct 15, 2020 that will close this issue
4 tasks
@umlaeute umlaeute modified the milestones: dynamic device management, release 0.13 Feb 5, 2021
@umlaeute umlaeute linked a pull request Mar 2, 2021 that will close this issue
4 tasks
@umlaeute umlaeute modified the milestones: release 0.13, release 0. May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants