GNOME Bugzilla – Bug 676134
rtpjpegpay doesn't handle MJPG from Logitech C-920 camera
Last modified: 2012-05-16 07:45:03 UTC
Created attachment 214163 [details] [review] rtpjpegpay patch The rtpjpegpay doesn't handle MJPG frames from the Logitech C-920 camera, complaining about "error: Invalid component", the code that complains is the one that reads the SOF header and checks that component 1 and 2 have the same quantization table. The RFC says that the components must use the same quant table : http://www.rfc-editor.org/rfc/rfc2435.txt section 3.1.8 (page 6) says : When table data is included, the number of tables present depends on the JPEG type field. For example, type 0 uses two tables (one for the luminance component and one shared by the chrominance components). The MJPG from the C920 uses a different quant table for each component, but in the DQT marker, the quant tables for component 1 and 2 (the ones used by U and V components) are exactly the same... I've written a patch that fixes support for the C920 camera by checking if both tables for U and V components are the same, if they are, it allows it and uses the same table for both, if not, then it would give that error about components being invalid. Patch is attached and available in my repo (in branches rtpjpegpay-0.10 and rtpjpegpay) http://cgit.collabora.com/git/user/kakaroto/gst-plugins-good.git/commit/?h=rtpjpegpay-0.10&id=b15ba7fb54d3d9512edc07070c3a0438837a108f Thanks.
commit e7614c49de7ff6c0bcab7d5c335595864de60e7b Author: Youness Alaoui <youness.alaoui@collabora.co.uk> Date: Tue May 15 20:58:25 2012 +0000 rtpjpegpay: Allow U and V components to use different quant tables if they contain the same data This allows some cameras (Logitech C920) that specify different quant tables but both with the same data, to work. Bug reported by Robert Krakora