qsvh264dec: non-deterministic output with parallel processes

[rsanchez87]

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 1

Comparison:
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
moved to https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/4777

[mdimopoulos]

@rsanchez87 since the fix of https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/4777 (or any possible future bug against QSV abstraction layer) does not depend on us or this project i suggest that we limit the number of threads to 1 automatically when this decoder is detected at runtime.
Do you agree with the idea?