GNOME Bugzilla – Bug 796908
v4l2: can't use different v4l2 input than the first one that was used
Last modified: 2018-08-02 12:34:40 UTC
Created attachment 373240 [details] [review] Proposed solution V4L2 devices may have different inputs, which can be selected with ioctl VIDIOC_S_INPUT. I'm using v4l2src and I need to change the input which is being used. GStreamer doesn't allow to do it (it used to allow it with GST_TUNER, but not now). What I've tried is to put the pipeline to null state, make an ioctl S_INPUT to select a different input, and put the pipeline to playing again. However, GStreamer selects again the original input that is started using the first time, undoing the input change I made. This is what I want to do: int input; // pipeline to null gst_element_set_state(pipeline, GST_STATE_NULL); // open video file descriptor int fd = open("/dev/video1", O_RDWR); // check current input ioctl(fd, VIDIOC_G_INPUT, &input); std::cout << "Current input: " << input << std::endl; // set new input input = NEW_INPUT; ioctl(fd, VIDIOC_S_INPUT, &input); // check that change is applied ioctl(fd, VIDIOC_G_INPUT, &input); std::cout << "Current input (pre-play): " << input << std::endl; // close file descriptor close(fd); // pipeline to playing and again to null gst_element_set_state (pipeline, GST_STATE_PLAYING); gst_element_set_state(pipeline, GST_STATE_NULL); // check if input is still the new one fd = open("/dev/video1", O_RDWR); ioctl(fd, VIDIOC_G_INPUT, &input); std::cout << "Current input (post-play): " << input << std::endl; close(fd); Now I get this output: Current input: 0 Current input (pre-play): 1 Current input (post-play): 0 I attach a patch with my proposed solution. When v4l2src changes to NULL state, it forget the previous input, making that next time it changes to PLAYING state, it checks again for the current selected input. I think this is the better behavior, considering that GStreamer doesn't allow to select an input and the first time it selects the currently selected one, I would expect the next times to do the same. Also, if not done like this, it is not possible for the user to select a different input reusing the same pipeline. Different inputs of the same device might have different formats, framesizes, etc, so for example I have had to change my selected caps for v4l2src, but that's something that the user have to take care of it. Also, it would be a good enhancement to allow selecting the input as a property of v4l2src (gst-launch-1.0 v4l2src device=/dev/video1 input=1 ! autovideosink). I haven't used v4l2sink, but I guess that the same could apply to its outputs.
Review of attachment 373240 [details] [review]: Patches should be made against master git repository as a commit. The generate a file with "git format-patch -1", and this file is what we accept here.
Created attachment 373243 [details] [review] Proposed solution (properly formatted)
Review of attachment 373243 [details] [review]: This patch looks right, it's worrying that we cleanup so little on _close, but that's another bug I guess. I totally agree that we should find a way to re-introduce input selection now that Tuner interface is gone. My impression was that maybe it should be expose as separate devices in the GstDeviceProvider. This way, application like Cheese would give you per input selection in the drop down. Just thinking out loud.
Queued for 1.14.3 as 5ebb41bbb80b2a2375d709bcc74ffa9885081d0a
Regarding exposing them as separate devices: only one input can be selected on the driver. If one app change the input, it affects to all other apps that are using the device (we cannot avoid this, because is the design of V4L2 itself). I don't know anything about how GstDeviceProvider works, but please take this into account. Should I submit an enhancement request regarding this?
(In reply to Iñigo Huguet from comment #5) > Regarding exposing them as separate devices: only one input can be selected > on the driver. If one app change the input, it affects to all other apps > that are using the device (we cannot avoid this, because is the design of > V4L2 itself). This is not to worry about, changing inputs while streaming returns EBUSY. > > I don't know anything about how GstDeviceProvider works, but please take > this into account. The GstDevice abstract the setup of device property, so it would abstract the input setup too, also it gives the caps, which are different for each inputs. > > Should I submit an enhancement request regarding this? Sure, if not already files of course ;-P
https://bugzilla.gnome.org/show_bug.cgi?id=746080