Streams play as speckle noise — decode ruled out on local files; leading suspect is damaged bytes on the debrid stream path

[cubman3134]

Reported from use with a screenshot: many movie/TV streams play as dense coloured speckle noise with
horizontal streaking over a dark image. Subtitles render perfectly on top, so the render path is fine —
the decoded frames are corrupt. It affects many streams, so it is systematic, not the content.

What the log says the player actually did

16:07:44  mpv: hwdec requested='auto-safe' (setting=auto)
16:10:17  video: codec='H.264 / AVC …'  1920x798  pixfmt=cuda  hwdec-current=nvdec
16:20:47  mpv: hwdec requested='auto-safe' (setting=auto)
16:21:31  video: codec='H.265 / HEVC …'  1620x1080 pixfmt=cuda  hwdec-current=nvdec

hwdec-current=nvdec, pixfmt=cuda, on both an H.264 and an HEVC stream. That is nvdec direct: CUDA
frames handed to OpenGL through CUDA↔GL interop, not copied back to system memory.

The design assumption this contradicts

HwDecode.h and Settings.h document why auto is the default:

Auto = "auto-safe" (copy-back preferred, software fallback) is deliberately the default — it sidesteps
the D3D11VA 10-bit-HEVC corruption that made a blanket "no" the original hard-coded choice.

The intent is clearly copy-back. But mpv's auto-safe is a whitelist of decoders mpv considers safe,
and on an NVIDIA machine that whitelist includes nvdec direct — so auto-safe does not deliver
copy-back here. It delivers the interop path, and the interop path is what is corrupting frames.

This is a different failure from the one the comment remembers. That one was D3D11VA on 10-bit HEVC.
This one is nvdec interop on ordinary 8-bit H.264 and HEVC, through a Qt QOpenGLWidget context
(MPV_RENDER_API_TYPE_OPENGL, MpvWidget.cpp).

Corroborating evidence

• crash_report.log, 2026-08-25 16:12: a fatal 0xc0000005 inside nvoglv64.dll (the NVIDIA OpenGL
  driver) on a driver thread — the same GL path under load.
• The themed UI is deliberately software-rendered because of "an mpv GL conflict" (documented in
  main.cpp). GL sharing with mpv on this machine has form.

The fix to establish, not assume

mpv has hwdec=auto-copy-safe — the same safe whitelist, copy-back variants only — which is what
the design comment describes wanting. Mapping the auto choice to auto-copy-safe instead of
auto-safe would deliver the documented intent. Costs one frame copy per frame; on modern hardware
that is not a visible cost at these resolutions, and it removes the interop entirely.

Establish it empirically before shipping: the same stream under hwdec=nvdec (expect corruption),
nvdec-copy (expect clean), no (expect clean, baseline), and auto-copy-safe (expect clean and
hwdec-current=nvdec-copy). The log line at MpvWidget.cpp:503 already prints hwdec-current, so the
evidence is one grep per run.

Also check what auto-copy-safe resolves to on a machine without NVIDIA — the fix must not regress
D3D11VA-copy or Android's mediacodec-copy, both of which HwDecode.h reasons about explicitly.

Immediate workaround for a user

Settings → Video → hardware decoding → Off (video/hwdec=off). Guaranteed-correct software decode,
higher CPU. Flipping it and watching the corruption stop is also the cheapest confirmation of this
diagnosis.

[cubman3134]

Correction: the nvdec-interop cause I filed this with is not established, and is probably wrong

PR #230 measured every decode mode on the same frames — no, nvdec, nvdec-copy, auto-copy-safe, the old auto-safe — across five clips including 10-bit HEVC, with and without the app's full option set, and in the real app. Every one rendered clean. nvdec direct did not corrupt a pixel. My premise that auto-safe picked nvdec direct was right; my conclusion that this produced the speckle was not.

What #230 shipped is a real but different fix: three files documented auto as copy-back and the code did interop. It is now copy-back, mutation-tested, at +2% of one core at 1080p24. It was also not the one-liner I proposed — auto-copy-safe resolves to d3d11va-copy here, the exact family HwDecode.h carries a scar from, and 41% more CPU — so the mapping names decoders explicitly instead.

The leading suspect is now the bytes, not the decoder. MpvWidget.cpp already carries this comment on stream-lavf-o:

when a long transfer is reset, throttled out or expires part-way — routine for a multi-hour, multi-gigabyte debrid link — it returns short reads, and the demuxer hands the decoder truncated packets rather than an error. HEVC then propagates that damage from the broken reference frame onward, which looks like torn, smeared picture that never recovers

That is the screenshot. And reconnect=1,reconnect_streamed=1 is already set, so reconnect alone is not preventing it — which points at what happens on reconnect: a resume at the wrong byte offset, a CDN not honouring Range, or a signed debrid link that has expired between the drop and the retry so the retry fetches something other than the rest of the file.

Cheapest discriminator, and it needs the maintainer: set Hardware video decoding → Off and play a speckling stream. If the speckle survives software decode, it is the bytes, and this issue becomes a stream-path investigation. If it vanishes, the decode path is back in play on real streams in a way local files did not reproduce.

Every repro attempt so far used local files. The reported clips were ordinary 8-bit SDR ~1080p over debrid — the shape that tested clean locally, which is itself evidence for the transport.

[cubman3134]

Correction to my previous comment. I cited stream 1 finished with error: "HTTP/2 protocol error" as transport evidence for the speckle. #231's investigation established it is Qt Network's HTTP/2 handler reaching appLogHandler — the app's own HTTP stack (catalog/addon fetches), not the media transport. libmpv streams through ffmpeg/curl entirely outside Qt, so that line was structurally incapable of being about the failing stream. It is not evidence either way.

What #231 (merged) changes for this issue: ffmpeg's concealment warnings — the line that answers "damaged bytes or bad decode?" per frame — now reach stream_debug.log. The next speckling playback will say ffmpeg/video: h264: concealing N DC, N AC, N MV errors if the bytes are damaged, and will not if the decode is wrong. That replaces the hardware-decoding-Off experiment as the discriminator: just play a speckling stream on a build carrying 71cca7a3+ and read the log.

[cubman3134]

Second correction. I cited crash_report.log's 0xc0000005 at nvoglv64.dll+0xc3c684 (2026-08-25) as corroborating a GL-interop decode fault. It was not that. The RetroPark N64 work (PR #234, merged fda82fc9) reproduced that exact fault address two seconds into Majora's Mask and fixed it — the shim never returned the host's GL context after a hardware-render core took it. The same crash had fired on 17 and 25 August. It is RetroPark's, and it has nothing to do with video playback.

So both pieces of evidence I originally attached to this issue — hwdec-current=nvdec and the nvoglv64 crash — have now been eliminated as causes. What remains is the log capture from #231 (merged 60460603): the next speckling playback on a build carrying it will either show ffmpeg concealment lines (bytes) or not (decode), and that is the first evidence on this issue that will actually be about the reported symptom.