After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758085 - v4l2: Track /dev/video* to triggered required probe
v4l2: Track /dev/video* to triggered required probe
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other All
: Normal enhancement
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 758078 758080 758083
Blocks:
 
 
Reported: 2015-11-13 22:49 UTC by Nicolas Dufresne (ndufresne)
Modified: 2015-11-25 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
v4l2: Track /dev/video* to triggered required probe (1.30 KB, patch)
2015-11-13 22:49 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
v4l2: Track /dev/video* to triggered required probe (2.81 KB, patch)
2015-11-19 22:22 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Nicolas Dufresne (ndufresne) 2015-11-13 22:49:56 UTC
This fixes issues where decoder and converter element does not appear when
a module is loaded, or have been reloaded.
Comment 1 Nicolas Dufresne (ndufresne) 2015-11-13 22:49:59 UTC
Created attachment 315437 [details] [review]
v4l2: Track /dev/video* to triggered required probe

If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.
Comment 2 Olivier Crête 2015-11-14 02:26:41 UTC
Review of attachment 315437 [details] [review]:

In ther patch title s/triggered/trigger/

::: sys/v4l2/gstv4l2.c
@@ +197,3 @@
 plugin_init (GstPlugin * plugin)
 {
+  const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };

It's /dev/v4l .. and there is no prefix in that case.
Comment 3 Tim-Philipp Müller 2015-11-14 11:22:25 UTC
I would like to understand the impact of this patch on 'normal operations' better first.

Does it mean the v4l plugin is typically reloaded after every reboot, even if nothing changed?

Does it mean the v4l plugin is reloaded every time a usb camera gets plugged or unplugged and a gst app is started?
Comment 4 Nicolas Dufresne (ndufresne) 2015-11-14 16:38:45 UTC
(In reply to Olivier Crête from comment #2)
> Review of attachment 315437 [details] [review] [review]:
> 
> In ther patch title s/triggered/trigger/
> 
> ::: sys/v4l2/gstv4l2.c
> @@ +197,3 @@
>  plugin_init (GstPlugin * plugin)
>  {
> +  const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };
> 
> It's /dev/v4l .. and there is no prefix in that case.

/dev/v4l is something else. It contains sub-folder by-id and by-patch, it's rather new. While /dev/v4l2 is ancient, is from when there was both v4l and v4l2 device (2.4 kernel). This is just to be consistent with the monitor (which is code from the probes).
Comment 5 Nicolas Dufresne (ndufresne) 2015-11-14 16:43:15 UTC
(In reply to Tim-Philipp Müller from comment #3)
> I would like to understand the impact of this patch on 'normal operations'
> better first.
> 
> Does it mean the v4l plugin is typically reloaded after every reboot, even
> if nothing changed?

With non-static /dev it will. It's a minor hassle compare to the underlying bugs. I can make this opt-in instead, if you don't agree. This feature need to go in, with compile option or not.

> 
> Does it mean the v4l plugin is reloaded every time a usb camera gets plugged
> or unplugged and a gst app is started?

It's not a daemon, so it will be updated after you have plugged/unplugged. There is no other mean with GStreamer to be smarter, and it's not worth writing infrastructure for this in my opinion. The probes are a very limited sub-set of the actual probes that get run when you switch to READY.
Comment 6 Nicolas Dufresne (ndufresne) 2015-11-19 22:22:05 UTC
Created attachment 315928 [details] [review]
v4l2: Track /dev/video* to triggered required probe

If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.
Comment 7 Nicolas Dufresne (ndufresne) 2015-11-19 22:24:33 UTC
This is an update, this time you need --enable-v4l2-probe to actually get that in-place. I also disable dynamic element probing by default. I think this is ideal until all the world have move to V4L2 m2m for CODEC ;-P It can also be handy on embedded system where probing takes time accompanied with the configurable version of the decoder/converter.
Comment 8 Tim-Philipp Müller 2015-11-19 22:30:24 UTC
So is this a "developer feature" then basically, for people hacking/trying drivers? If yes, I'd hide it behind an environment variable instead.

I would like to avoid unnecessary rescans of the plugin on non-embedded systems.
Comment 9 Nicolas Dufresne (ndufresne) 2015-11-20 01:50:26 UTC
(In reply to Tim-Philipp Müller from comment #8)
> So is this a "developer feature" then basically, for people hacking/trying
> drivers? If yes, I'd hide it behind an environment variable instead.

Not sure what makes you think that. There is no other way to use a M2M VL42 decoder (and there will never be) within playbin without that feature being enabled. You seems to expose a concern of having this probing code to run from time to time on platforms where there is no such decoder or converter.

> 
> I would like to avoid unnecessary rescans of the plugin on non-embedded
> systems.

At boot, it is necessary. We cannot know between two boots if the topology of the system will be the same or not. For that same reason, pulseaudio will probe the alsa devices every boot.

I think I have confused you with stating that this could be disable on certain embedded platform. In fact, I should have said on certain embedded use case, where static pipelines are to be used.
Comment 10 Nicolas Dufresne (ndufresne) 2015-11-20 01:53:05 UTC
Another important point to remember, the device numbers are not guaranteed by the linux kernel. Also, distribution might at some point enable such feature in their kernel, hence we need a scan to see the devices. And further update to the kernel could change the device order, resulting in bad cached value.
Comment 11 Nicolas Dufresne (ndufresne) 2015-11-25 19:32:24 UTC
Attachment 315928 [details] pushed as 3cdc700 - v4l2: Track /dev/video* to triggered required probe