qsvh264dec: non-deterministic output with parallel processes #322
Description
The qsvh264dec element produces corrupted frames with different MD5 checksums when multiple gst-launch-1.0 processes decode simultaneously. Sequential execution works correctly.
Reproduction:
- Sequential (-j 1): Deterministic results, identical MD5s across runs
- Parallel (-j 8): Non-deterministic, different MD5s per run (51-56/135 tests pass)
Example:
Same input produces different outputs:
Run 1: f6e11cbb38ae25ff060e3ed5228a6770
Run 2: 9be893ec02dcc317805a397bb3682fd2
Expected: 114d1cf94a2fcaffda0cf1b49964bf3d
Root cause: The qsv plugin in gst-plugins-bad (as of version 1.24.2) lacks proper inter-process synchronization when multiple gst-launch-1.0 processes access the Intel QSV hardware simultaneously. Unlike FFmpeg's QSV implementation which creates isolated hardware contexts per process (-init_hw_device qsv), GStreamer's implementation shares underlying driver resources without adequate locking.
Workaround: Always use -j 1 (sequential execution) when testing GStreamer QSV decoders:
./fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-QSV-Gst1.0 -j 1Comparison:
FFmpeg's h264_qsv handles parallel execution correctly using -init_hw_device qsv.
Environment:
GStreamer 1.24.2, gst-plugins-bad, Intel QSV hardware
GStreamer bug:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1832