ksvideosrc device enumeration problem

[Jérôme Laheurte-3]

Hello. Just checking if anybody already knows about this, or even, heaven forbids, has a workaround :)

The device-path property associated with a given USB camera, as returned by gst-device-monitor (and the underlying API), is not the same depending of wether the device was plugged in when starting gst-device-monitor or not. I can reproduce this with all USB camera models I have:

1. Plug camera, launch gst-device-monitor, copy/paste the suggested command line and add autovideosink -> works
2. Unplug camera, launch gst-device-monitor -f, plug camera, copy/paste -> does not work. Notice that device-path is not the same.

On the other hand the device-path displayed when the camera is already plugged is always the same; and the one displayed on hotplug is also always the same :(

Cannot find anything on Bugzilla. Tested with the latest release (1.14.2). Do I open a bug ?

Best regards
Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 09 août 2018 à 15:48 +0200, Jérôme Laheurte a écrit :

> Hello. Just checking if anybody already knows about this, or even,
> heaven forbids, has a workaround :)
>
> The device-path property associated with a given USB camera, as
> returned by gst-device-monitor (and the underlying API), is not the
> same depending of wether the device was plugged in when starting gst-
> device-monitor or not. I can reproduce this with all USB camera
> models I have:
>
> 1. Plug camera, launch gst-device-monitor, copy/paste the suggested
> command line and add autovideosink -> works
> 2. Unplug camera, launch gst-device-monitor -f, plug camera,
> copy/paste -> does not work. Notice that device-path is not the same.
>
> On the other hand the device-path displayed when the camera is
> already plugged is always the same; and the one displayed on hotplug
> is also always the same :(
>
> Cannot find anything on Bugzilla. Tested with the latest release
> (1.14.2). Do I open a bug ?

That the device path changes, that does not seems like a bug. To
compare, on linux, if you have CAMERA A and B, the order in which you
plug the cameras will affect the /dev/videoX node being associate to
it.

But that you copy the traces launch command and it does not work, that
sounds like a bug. You should report.

>
> Best regards
> Jérôme Laheurte
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jérôme Laheurte-3]

Le 9 août 2018 à 16:08, Nicolas Dufresne <[hidden email]> a écrit :

Le jeudi 09 août 2018 à 15:48 +0200, Jérôme Laheurte a écrit :

Hello. Just checking if anybody already knows about this, or even,
heaven forbids, has a workaround :)

The device-path property associated with a given USB camera, as
returned by gst-device-monitor (and the underlying API), is not the
same depending of wether the device was plugged in when starting gst-
device-monitor or not. I can reproduce this with all USB camera
models I have:

1. Plug camera, launch gst-device-monitor, copy/paste the suggested
command line and add autovideosink -> works
2. Unplug camera, launch gst-device-monitor -f, plug camera,
copy/paste -> does not work. Notice that device-path is not the same.

On the other hand the device-path displayed when the camera is
already plugged is always the same; and the one displayed on hotplug
is also always the same :(

Cannot find anything on Bugzilla. Tested with the latest release
(1.14.2). Do I open a bug ?

That the device path changes, that does not seems like a bug. To
compare, on linux, if you have CAMERA A and B, the order in which you
plug the cameras will affect the /dev/videoX node being associate to
it.

Yep, but things are a bit different on Windows I think. The device path does not appear to depend on the plug order, USB port, not even USB controller.

But that you copy the traces launch command and it does not work, that
sounds like a bug. You should report.

Okay. I’ll have a quick look at the code first in case the problem is « obvious ». Thanks.

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jérôme Laheurte-3]

Le 9 août 2018 à 16:34, Jérôme Laheurte <[hidden email]> a écrit :

But that you copy the traces launch command and it does not work, that
sounds like a bug. You should report.

Okay. I’ll have a quick look at the code first in case the problem is « obvious ». Thanks.

Yep, I think I found the problem. Is there any good resource on how to setup a build environment on Windows to rebuild plugins-bad ?

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jérôme Laheurte-3]

Le 9 août 2018 à 17:08, Jérôme Laheurte <[hidden email]> a écrit :

Le 9 août 2018 à 16:34, Jérôme Laheurte <[hidden email]> a écrit :

But that you copy the traces launch command and it does not work, that
sounds like a bug. You should report.

Okay. I’ll have a quick look at the code first in case the problem is « obvious ». Thanks.

Yep, I think I found the problem. Is there any good resource on how to setup a build environment on Windows to rebuild plugins-bad ?

That was slightly less painful than anticipated. For reference

https://bugzilla.gnome.org/show_bug.cgi?id=796958

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel