It always uses decode_mcu_slow even with dinfo.dct_method = J_DCT_METHOD::JDCT_IFAST

[Boscop]

When I write dinfo.dct_method = J_DCT_METHOD::JDCT_IFAST; it seems to call the same decode_mcu_slow function as without.
It seems to not change anything (same CPU usage when decoding 30fps 1080p MJPEG).
Is this library hardcoded to use ISLOW or is it dictated by the specific jpeg image that it cannot be decoded with IFAST?

This is what I'm doing every frame:

	let mut err: jpeg_error_mgr = mem::zeroed();
	let mut dinfo: jpeg_decompress_struct = mem::zeroed();
	dinfo.common.err = jpeg_std_error(&mut err);
	jpeg_create_decompress(&mut dinfo);
	dinfo.dct_method = J_DCT_METHOD::JDCT_IFAST;
	jpeg_mem_src(&mut dinfo, self.cam_frame.as_ptr() as *const u8, self.cam_frame.len() as u32 * 4);
	jpeg_read_header(&mut dinfo, true as boolean);
	dinfo.out_color_space = J_COLOR_SPACE::JCS_RGB;
	jpeg_start_decompress(&mut dinfo);
	let row_stride = dinfo.image_width as usize * dinfo.output_components as usize;
	let buffer_size = row_stride * dinfo.image_height as usize;
	debug_assert!(buffer_size <= DECODED_MJPEG_FRAME_SIZE);
	while dinfo.output_scanline < dinfo.output_height {
		let offset = dinfo.output_scanline as usize * row_stride;
		let mut jsamparray = [self.decoded_mjpeg[offset..].as_mut_ptr()];
		jpeg_read_scanlines(&mut dinfo, jsamparray.as_mut_ptr(), 1);
	}
	jpeg_finish_decompress(&mut dinfo);
	jpeg_destroy_decompress(&mut dinfo);

I profiled it, and IFAST made no difference, I got the same execution times as without setting it:

Any idea how I can make it really use IFAST? :)

[kornelski]

You're changing DCT method, but profiling MCU entropy decoding. These are completely different unrelated things. Use of decode_mcu_slow indicates that the JPEG data is corrupt or incomplete.

[kornelski]

BTW, MozJPEG is slow by design. It intentionally uses slowest (but highest quality) version of everything.

[Boscop]

Use of decode_mcu_slow indicates that the JPEG data is corrupt or incomplete.

Hm, any idea why it could be corrupt/incomplete? I'm getting complete frames out at the end, and I'm just forwarding the data that I'm getting from the webcam.
The thing that's definitely missing is the huffman tables (so the default ones are used), but how could it be corrupt or missing something else?

Could it be because it's a cheap webcam that delivers corrupted MJPEG frames?

MozJPEG is slow by design. It intentionally uses slowest (but highest quality) version of everything.

Is there any jpeg decoder that's faster and also has Rust bindings? :)

(Btw, with this crate I'm getting 9-10% CPU usage (and without webcam decoding, my application only has 4% CPU usage). I tried the jpeg_decoder crate but it uses even more CPU than mozjpeg (total 16%).)

[kornelski]

I haven't studied MJPEG spec, so I can't say why exactly it's like that.

If you could reproduce the issue with pure C code, you could ask about it in libjpeg-turbo project (MozJPEG is a fork of libjpeg-turbo).