Fix MJPEG camera decoding on Linux

[shiena]

fixed #113357
MJPEG streams from cameras have two issues:

1. V4L2 buffer size is allocated for the maximum frame size, which is larger than the actual JPEG data size. Passing the entire buffer to the decoder causes it to fail due to invalid trailing data.
2. Real-time streams may have partially corrupted frames. The standard JPEG decoder strictly rejects these as errors.

→ Solution:

• Use v4l2_buffer.bytesused to get the actual frame size.
• Add an internal function that decodes using libjpeg-turbo's lenient mode (tolerates partial corruption).

[j20001970]

From my testing that when decoding partially corrupted MJPEG frames, tj3Decompress8 still returns -1 indicating a warning is encountered. An issue from libjpeg-turbo also mentioned such behaviour but for tjDecompress2.

We can use tjGetErrorCode instead to determine if the error is fatal (TJERR_FATAL) or not (TJERR_WARNING).

[j20001970]

TJPARAM_STOPONWARNING is already 0 by default since libjpeg-turbo 2.1.90, maybe the additional p_strict parameter is not needed?

[shiena]

It seems like the libjpeg-turbo upgrade in #113945 may have resolved the noise and frame drop issues. This PR might not be necessary anymore.

[shiena]

When Motion JPEG is selected, commit 94971e1 on master repeatedly throws the following error under high load (high resolution or frame rate). This PR fixes the error but introduces more block noise, as shown in the attached video. The block noise is likely caused by processing load and remains unresolved.

ERROR: Condition "err" is true. Returning: Ref<Image>()
   at: _jpeg_turbo_mem_loader_func (modules/jpg/image_loader_libjpeg_turbo.cpp:104)
ERROR: Condition "image.is_null()" is true. Returning: ERR_PARSE_ERROR
   at: _load_from_buffer (core/io/image.cpp:4542)

linux-camera-mjpeg.mp4

[shiena]

For reference, playing the camera with the same format using ffmpeg also produces block noise and errors.

$ ffplay -f v4l2 -input_format mjpeg -video_size 640x480 -i /dev/video0
[mjpeg @ 0x726320002440] mjpeg_decode_dc: bad vlc: 0:0 (0x726320004048)
[mjpeg @ 0x726320002440] error dc
[mjpeg @ 0x726320002440] error y=47 x=19
[mjpeg @ 0x726320002440] EOI missing, emulating

ffmpeg-linux-mjpeg.mp4

[j20001970]

c36f7d4f13b6d2ff502138113738e91241180f6b works as expected with Logitech C270 webcam, no visual glitch is observed from decoded MJPEG frames.

[shiena]

I tested with Steam Deck + Logitech C920 and there was no noise. The noise was occurring in a WSL2 + usbipd USB passthrough environment, so it appears the overhead was causing latency.

steamdeck-camera-mjpeg.mp4