A successful encode is stronger than an encoder list.

Two APIs, different outcomes#

Observed in the reconstructed transcript: VA-API produced an HEVC segment. Unresolved in the recovered encoding work: QSV initialization failed with MFX error -9, despite QSV encoders appearing in FFmpeg’s list. Successful VA-API is not evidence that QSV was fixed.

A prior recap reported installing an Intel media driver package, but its installation output was not recovered. The publication does not elevate that recap into a complete reproducible driver installation.

Evidence: S05 · S09.

The five-minute QP23 test#

ffmpeg -hide_banner \
  -vaapi_device /dev/dri/renderD128 \
  -ss 00:10:00 -i "<INPUT_VIDEO.mkv>" -t 300 \
  -map 0:v:0 -map 0:a? -map 0:s? \
  -vf 'format=nv12,hwupload' \
  -c:v hevc_vaapi -qp 23 \
  -c:a copy -c:s copy \
  "<NEW_TEST_OUTPUT.mkv>"

Scroll within the table to see all columns.

Use a synthetic input and a new output path for a new test. Keep originals intact while comparing duration, stream layout, decoding and visual output. No video assets are published here.

Reference: FFmpeg command and stream-selection documentation. The tested command is historical and build-specific.

Evidence: S05.

Later QP28 results belong to different runs#

Recovered report. Later work used VA-API in Tdarr, with HEVC QP28 and copied audio/subtitles. A job summary reported exit code 0. One full-file comparison reported approximately 6.74 GB becoming 687 MB while retaining 1080p resolution, 5.1 audio, subtitles and duration; I accepted that test’s appearance. Another QP24 result was different.

Those are content-specific observations, not a compression ratio or quality promise. The recovered proposal put originals on an 8 TB disk and a separate cache at /temp. That proposal is not an exported, currently verified Tdarr volume configuration.

ffprobe -v error \
  -show_entries format=duration,size:stream=codec_type,codec_name,width,height,channels \
  -of json "<TEST_OUTPUT.mkv>"

Evidence: S09.

Look beyond CPU utilization#

Plex Direct Play still stalled during conversion in the recovered discussion. A 4 November sample showed approximately 9.65% CPU iowait and 81.83% idle. Those values justify checking storage latency and queue pressure; they do not identify the sole cause of all playback stalls.

iostat -xz 2

Compare the actual media and cache devices during the symptom, alongside Plex’s session mode and worker activity. A requested time schedule or Plex-aware pause was Proposed; no completed automation is established. Total job counts and accumulated savings are not claimed.

Evidence: S09 · S17.