Reference plex h264 vaapi segment muxer bug

When Plex transcodes a Dolby Vision Profile 5 source using a full VAAPI hardware pipeline (h264_vaapi encoder), the encoder produces packets faster than Plex's 1-second segment muxer can consume them. Symptom: h264_vaapi: Too many packets buffered for output stream 0:0 flood in the transcode log, zero chunk-* segments produced, transcode process runs but client never gets data.

This is a known ffmpeg + h264_vaapi + segment-output interaction triggered by DV5 source PTS irregularities.

Fix: In Plex Settings → Server → Transcoder, uncheck "Use hardware-accelerated video encoding" (keep hardware-accelerated decode ON). This creates a hybrid pipeline: VAAPI HEVC decode → scale_vaapi → tonemap_opencl → libx264 software encode. CPU cost of libx264 veryfast at 1080p 7Mbps is light (~30% of one core); the expensive decode and HDR tonemap stay on the GPU.

Alternatively, edit Preferences.xml directly and restart Plex (HardwareAcceleratedEncoders pref).

Why: After fixing the OpenCL render symlink (see reference_plex_gpu_xe_driver.md), a new blocker appeared — full VAAPI pipeline broke on the DV5 source even though GPU was working. How to apply: If a 4K HDR transcode starts but produces no playable segments after the OpenCL/VAAPI stack is confirmed working, check for this packet buffering error and switch to hybrid encode.

[auto-memory session 7312e334-e32e-4f5b-aaab-b74277a00ead, confidence 0.78, mode staged]