GNOME Bugzilla – Bug 746080
v4l2: enumerate output ports and add a property to select input/output
Last modified: 2018-11-03 14:58:41 UTC
V4L2 device can have multiple input/output port and they expose them through ENUMINPUT/ENUMOUTPUT ioctls. But currently we only enumerate input whatever device is a capture one or an output one. I think, we should enumerate according to the device type. Also I think it can be useful to enable user to select which input/output they want to use. To solve this I propose to add a property to v4l2object to let user select input/output. I found this while playing with Vivid which have multiple input/output port.
Created attachment 299170 [details] [review] v4l2_calls: add support of video output enumeration Like for capture device, an output device can have multiple outputs. This commit add two helpers to enumerate input/output and use one of them according to device type to fill corresponding structure the same way it was originaly done with input.
Created attachment 299171 [details] [review] v4l2object: add a property to select device input/output For devices which have multiple input/output port (like vivid), we should enable users to decide which one they want to use. To do so, we export a property, named 'inout-index' to select a port. By default, it takes the one returned by the device. Currently, I named this property inout-index, but if you have better ideas, I'm willing to change it.
That's nice, we might want to start using properties and simply remove the old / unused tuner interface. This would be a lot more useful if there was a property to get the list of ports (called channels in this case). Do you know if this list may change dynamicilly ? Also, to swith input/output, do one need to stop streaming and renegotiate the format ?
(In reply to Nicolas Dufresne (stormer) from comment #3) > That's nice, we might want to start using properties and simply remove the > old / unused tuner interface. This would be a lot more useful if there was a > property to get the list of ports (called channels in this case). Do you And tuner interface is quite confusing now since v4l2 is no more about tuner only. The property to get a lst of channels could be a good idea, what type of structure do you think we should use ? (I'm not really familiar with good practice with boxed properties) > know if this list may change dynamicilly ? Also, to swith input/output, do > one need to stop streaming and renegotiate the format ? According to the spec, it is related to physical connectors so I think it can't change dynamically, but we may ask for confirmation in LinuxMedia ML. Also if the the user want to change input/output, I think it should stop streaming, and renegotiate format: "Because of these possible side effects applications must select an input before querying or negotiating any other parameters." (http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-input.html)
Ok, I think we really want that kind of property. I'll document myself too, so I can better scope what else we should do. Maybe after that it will be time to remove the old and confusing tuner interface.
(In reply to Aurélien Zanelli from comment #4) > (In reply to Nicolas Dufresne (stormer) from comment #3) > > know if this list may change dynamicilly ? Also, to swith input/output, do > > one need to stop streaming and renegotiate the format ? > According to the spec, it is related to physical connectors so I think it > can't change dynamically, but we may ask for confirmation in LinuxMedia ML. Question has been asked in LinuxMediaML. Answer is that list is fixed even if the spec doesn't explicitely forbid it. Dynamic list is not allowed at the moment.
*** Bug 796915 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/168.