To slow libv4l MJPEG decoding with HD cameras

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

Logitech HD Pro Webcam C910 supports 2592x1944 at 10 FPS MJPEG stream.
This is really great but the problem is that libv4l decoding of MJPEG
is too slow for real-time on the fly decoding at this framerate. I use
2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz and
0.8.1 v4l-utils.

For example, with libv4l decoding of one pixel of MJPEG to BGR24 takes
around 0.025 microseconds on my machine. This is nothing important
with for example 640x480 resolution, it takes around 7680
microseconds, that is 8 milliseconds. But with 2592x1944 this becomes
around 125 milliseconds. So it is impossible to decode stream on the
fly in real-time with 10 FPS.

In comparison YUYV decoding takes 0.005 microseconds per pixel on
average. Those measurements per pixel (both for MJPEG and YUYV) are
quite consistent even for different framerates and frame sizes.

So maybe there is some room for improvement here? For example by using
ffmpeg MJPEG decoder instead of tinyjpeg? They argue (not really
kindly) that it has better performance:

https://roundup.ffmpeg.org/issue1816

Has anybody tried to improve MJPEG support in libv4l? With newer
cameras this becomes important.

And by the way, it would be useful to increase those hardcoded limits
in ib/libv4lconvert/tinyjpeg-internal.h to for example:

#define JPEG_MAX_WIDTH     4096
#define JPEG_MAX_HEIGHT    2048

Now we have affordable cameras which have bigger frame sizes than
those currently hardcoded. ;-)


Mitar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux