Decreasing startup delay with v4lsrc

[Kristian Kielhofner]

Hello,

  I'm using gstreamer in a use case where startup time is critical.
I'm using v4l2src with a compatible camera. Everything works well
except that it takes gstreamer almost seven seconds to enumerate the
capabilities of the camera I'm using:

http://pastebin.com/HvZKgk8J

  This is gstreamer 1.11.1 built from source on Debian Jessie (x86_64)
although this delay is virtually identical with various other versions
and platforms I've tried.

  Is there a way to get Gstreamer to skip some or all of this
enumeration to speed startup time? In my particular case the camera
and application are fixed, if there is a way to provide the capable
and desired capabilities and skip enumeration that's certainly an
option in my case.

  Thanks!

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

[Nicolas Dufresne-5]

Le samedi 14 janvier 2017 à 13:41 -0500, Kristian Kielhofner a écrit :

>   I'm using gstreamer in a use case where startup time is critical.
> I'm using v4l2src with a compatible camera. Everything works well
> except that it takes gstreamer almost seven seconds to enumerate the
> capabilities of the camera I'm using:
>
> http://pastebin.com/HvZKgk8J
>
>   This is gstreamer 1.11.1 built from source on Debian Jessie
> (x86_64)
> although this delay is virtually identical with various other
> versions
> and platforms I've tried.
>
>   Is there a way to get Gstreamer to skip some or all of this
> enumeration to speed startup time? In my particular case the camera
> and application are fixed, if there is a way to provide the capable
> and desired capabilities and skip enumeration that's certainly an
> option in my case.

This issue is common with many UVC cameras. I have research the problem
and some improvement is possible. What you need to know is that UVC
interface expose only a subset of V4L2 and GStreamer capabilities
interface. Because we don't know from USERSPACE, we probe all the
possibilities through V4L2, which endup probing the hardware with the
same subset again and again. Some USB UVC camera are really slow at
probing time, which leads to this issue.

The best solution would be to implement a cache in the kernel driver of
the probed results. This way, the driver could return from the cache
whenever we probe something different but which has a subset identical
to a previous probe. Or, we could add some flags in the drivers that
enumerate which fields are implemented.

The second solution, could be to implement extra quirk in GStreamer
when probing the UVC drivers. This could require identifying exactly
which capabilities have no mapping on UVC side and make sure to avoid
probing for those capabilities.

A third solution, which I don't like much, would be to allow users to
pass the probed caps to the v4l2src element. The reason I don't like
it, is that by-passing the probes is error prone and may lead to
unusual error being reported. This endup being extra effort when
helping users over this mailing list.

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

[Kristian Kielhofner]

On Sun, Jan 15, 2017 at 11:47 AM, Nicolas Dufresne <[hidden email]> wrote:

>
> This issue is common with many UVC cameras. I have research the problem
> and some improvement is possible. What you need to know is that UVC
> interface expose only a subset of V4L2 and GStreamer capabilities
> interface. Because we don't know from USERSPACE, we probe all the
> possibilities through V4L2, which endup probing the hardware with the
> same subset again and again. Some USB UVC camera are really slow at
> probing time, which leads to this issue.
>
> The best solution would be to implement a cache in the kernel driver of
> the probed results. This way, the driver could return from the cache
> whenever we probe something different but which has a subset identical
> to a previous probe. Or, we could add some flags in the drivers that
> enumerate which fields are implemented.
>
> The second solution, could be to implement extra quirk in GStreamer
> when probing the UVC drivers. This could require identifying exactly
> which capabilities have no mapping on UVC side and make sure to avoid
> probing for those capabilities.
>
> A third solution, which I don't like much, would be to allow users to
> pass the probed caps to the v4l2src element. The reason I don't like
> it, is that by-passing the probes is error prone and may lead to
> unusual error being reported. This endup being extra effort when
> helping users over this mailing list.
>
> regards,
> Nicolas
>

Hi Nicolas,

  Thank you for getting back to me so quickly.

  I've implemented something similar to your second option, I only
enumerate for the formats I want and then I stop when Gstreamer probes
one resolution and one frame rate. In my application this provides the
exact capabilities I want and I've been able to reduce probe time from
seven seconds to about 1.5.

  The third option you provide would be best for my application. I
understand your hesitation about user confusion but perhaps there is a
way to implement this without creating extra support efforts?

  Thanks again!

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

[Nicolas Dufresne-5]

Le dimanche 15 janvier 2017 à 14:45 -0500, Kristian Kielhofner a
écrit :

> Hi Nicolas,
>
>   Thank you for getting back to me so quickly.
>
>   I've implemented something similar to your second option, I only
> enumerate for the formats I want and then I stop when Gstreamer
> probes
> one resolution and one frame rate. In my application this provides
> the
> exact capabilities I want and I've been able to reduce probe time
> from
> seven seconds to about 1.5.
>
>   The third option you provide would be best for my application. I
> understand your hesitation about user confusion but perhaps there is
> a
> way to implement this without creating extra support efforts?

Just a follow up. I started working on a patch in which we create caps
(on get caps) only based on what can be enumerated, no TRY_FMT
initially. This helps because this information is part of the
descriptor in UVC. That is only possible for capture. Then in fixate()
function, we'll apply the information we have with some default, then
transform back the FMT to caps, and check if that intersect with
downstream. Most of the time it will, so we'll get 1 TRY_FMT and 1
S_FMT in the best case. This should drastrically reduce the start time.
I hope I'll have time to finish this in the next few days. It the case
it does not, we'll be doing a series of TRY_FMT to find something
supported, but that will be done only for one resolution/framerate. And
will be restricted by downstream caps. This is generic enough, and
won't require the application to care.

regards,
Nicolas

p.s. not enumerating at all would break existing app like cheese.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel