GNOME Bugzilla – Bug 702638
v4l2: Optimize negotiation by removing the query filter
Last modified: 2013-07-02 08:38:12 UTC
Created attachment 247250 [details] [review] proposed patch As cameras tend to have a quite specific set of capabilities (specific framerates for each resolution), getting the peer caps filtered by our probed caps can cause a big increase in the caps size which slows down things quire a bit. As for negotiation v4l2 iterates through the caps of the peer to find the first intersection with the probed caps, getting the fully expanded intersection of capabilities is not useful. Using the same testcase as for bug #702632, adding this patch on top of the patches suggested there speeds up getting the inital frame from around ~14-15 seconds to around ~3-4 seconds.
But shouldn't the filter actually cause more restricted caps to be passed between elements, and thus usually create smaller caps?
The problem here is that the camera caps are quite specific e.g (my camera has 28 different resolutions it can do, both in YUYV and MJPG (56 caps entries), which about doubles again once you start doing the emulated formats through libv4l). All these tend to be of the following form, so don't easily simplify: video/x-raw, height=1280,width=720, framerate=15/1, video/x-raw,height=640, width=320, framerate=30/1. etc etc. While the remainder of the pipeline has a bunch of transform elements, so the "full" set will be all the original entries expanded with all the possible transformations.. Which turns out to be a lot...
Ok, fine then :)
commit 8e43c0ec9ea627d3cea0cecf6d3e168bf4d5d09e Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Date: Wed Jun 19 12:37:31 2013 +0200 v4l2: Optimize negotiation by removing the query filter As cameras tend to have a quite specific set of capabilities (specific framerates for each resolution), getting the peer caps filtered by our probed caps can cause a big increase in the caps size which slows down things quire a bit. As for negotiation v4l2 iterates through the caps of the peer to find the first intersection with the probed caps, getting the fully expanded intersection of capabilities is not useful. Using the same testcase as for bug #702632, adding this patch on top of the patches suggested there speeds up getting the inital frame from around ~14-15 seconds to around ~3-4 seconds. https://bugzilla.gnome.org/show_bug.cgi?id=702638
Maybe instead of doing the full filter, you can filter it by only the format, for example.
Sjoerd?
(In reply to comment #5) > Maybe instead of doing the full filter, you can filter it by only the format, > for example. You mean passing a filter with just video/x-raw,format={A, B, C} downstream instead of the multi-structure, large filter? Would make sense IMHO