Decreasing startup delay with v4lsrc

[Nicolas Dufresne]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170115/67687370/attachment.sig>