big delay of 13 seconds to turn on the camera

[Nicolas Dufresne]

Le mercredi 26 octobre 2016 à 10:19 +0300, Sebastian Dröge a écrit :
> On Tue, 2016-10-25 at 21:01 +0200, ano ona wrote:
> > 
> > Hi, i'm new to gstreamer, played a little with the command line and
> > the C API. I have many issues, but don't know if it's coming from a
> > bad usage, my distro, or the framework itself. Sorry if the answer
> > is
> > obvious.
> > 
> > My goal is to build a camera triggered by a PIR sensor on the
> > beagleboard black (BBB).
> > 
> > I made test on laptop and the BBB.
> > 
> > Here, i'll address an issue, i have on both the BBB and the laptop.
> > Both are on ArchLinux.
> > 
> > So, i'll start with one that is quite annoying knowing my goal.
> > 
> > I have this problem, on laptop and BBB, with cmd-line and API.
> > 
> > GStreamer Core Library version 1.9.90
> > kernel 4.8.4-1-ARCH
> > 
> > Here, is a link of the log of the command :
> > 
> > gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-
> > raw,format=YUY2,width=960,height=544,framerate=20/1' !  jpegenc  !
> > rtpjpegpay !  fakesink &> log.txt
> > 
> > http://pastebin.com/4WbpyCau
> > 
> > U can see at line 151-152 the time it takes : 13scec
> > 
> > maybe it's gst_v4l2_object_probe_caps that takes this time ?
> 
> Take a look at a full debug log to check where time is spent, or use
> a
> profiler for that. A debug log should be enough for this huge amount
> of
> time though.
> 
> It could be anything really. You probably also want to add a queue
> after v4l2src in your pipeline to make it possible that v4l2src and
> the
> jpeg encoding can run on different CPU (cores).
> 
> 
> It could be the probing though, maybe we run into a tricky case here
> and probe too many formats, which might be slow with your camera to
> do.

Looking at it, it looks like a slow firmware. So whenever we do probing
it takes ages to reply. This could be solved in the UVC driver of
course since UVC only uses a subset of the V4L2 format. That results in
the same format to be probed over and over again. The driver could
cache the probe results. This way slow firmware won't cause such a
disaster. There is nothing we can really do in generic code (like
gstreamer code) as otherwise it would not be correct. There is already
few quirks specially for UVC, but I'm not such a fan. Other improvement
in the driver would be to introduce more ENUM_ methods. Right now we
can only enumerate formats, frame size and frame interval. It's missing
colorimetry, interlaced mode and many other.

regards,
Nicolas