[Bug 732326] v4l2: slow UVC webcam startup due to excessive S_FMT

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732326
  GStreamer | gst-plugins-good | git

--- Comment #4 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-06-28 17:15:38 UTC ---
(In reply to comment #3)
> This brings startup back down to half a second. I think we should apply this,
> but then I wasn't happy to have this workaround in our code the first place.

This workaround caused me serious head-hake when trying to implement M2M
support, so I'd be very happy to get rid of it. It will break drivers that
simply don't support TRY_FMT (this was added after, so we cannot stand with
saying this is a buggy drivers). Would be nice to track when this was added, or
what drivers that may still be affected today (for release notes).

> 
> What I find also curious is that I have fast startup with <= 1.2, just master
> is slow, yet this code is in all branches if I'm not mistaken. (I haven't
> investigated further though).

What I think is the caused is that distro kernel are earlier then the
distributed headers. This has mean we now do step enumeration when drivers
supports it, and we do that enumeration the slowest possible way (by probing
every single steps). There is a report for the PyCam and some drivers that
expose a step of 1, where things becomes a disaster, and caps become really
huge.

See bugs #726521 and #724521

Imho, steps are like range, we should probe the first and the last. We should
also have a special case for small steps, to avoid exploding the caps size and
let the implicit (through alignment) crop now in place do it's job (for small
steps up to 4 pixels, it's really not a problem to crop, we'll need to decide
on a threshold).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.