Reproducible access violation (NULL+0x2C read) on worker thread during live DASH playback with frequent Period switching

[annah464545-hub]

mpv Information

・Reproduced on two independent builds:
　　1.mpv-1.dll bundled with mpv.net
　　2.mpv-2.dll from shinchiro/mpv-winbuild-cmake (dev package, mpv-dev-x86_64-v3-20260524-git-9e06c32)

・Both builds show the file version resource 2.0.0.0 (no further version string embedded)
・Embedded in a Python application via python-mpv (ctypes), libmpv API, vo=gpu-next (default) or vo=gpu (tested both, same result)

Other Information

Windows 10 (build 26100.1), Windows 11-style UI, AMD Ryzen with AMD Radeon(TM) Graphics (integrated), driver 31.0.21925.1001

Reproduction Steps

1.Open a live MPEG-DASH stream (ClearKey-encrypted; decryption is handled by a local HTTP proxy that rewrites the MPD and hands mpv a plain, non-DRM local URL, so mpv itself never touches the ClearKey layer)

2.Let it play through several minutes of content, including multiple "commercial break" segments

3.The commercial-break portion of this particular stream is unusual: it publishes a new element roughly every 15–30 seconds (see attached manifest_1783409233627.mpd, which shows three Periods only 15s and 30s apart, none of them encrypted)

4.After some number of these rapid Period transitions (not perfectly deterministic, but reliably reproducible within a few minutes of playback), the process crashes

Expected Behavior

The stream should continue playing through the Period transition without crashing.

Actual Behavior

The process crashes with an access violation (0xc0000005, read from NULL+0x2C) after playing
through several rapid transitions in a live MPEG-DASH stream (a new Period is published
roughly every 15-30 seconds during this stream's ad-break segments; see attached manifest.mpd).

Reproduced identically on two independent builds:

• mpv-1.dll bundled with mpv.net
• mpv-2.dll from shinchiro/mpv-winbuild-cmake (dev package, mpv-dev-x86_64-v3-20260524-git-9e06c32)

Both crash with the same instruction pattern:
mov r12d, dword ptr [rax+2Ch] ; rax = 0

The crash happens on a background worker thread (ucrtbase!thread_start), not the main thread.
Reproduced with both vo=gpu and vo=gpu-next, and with hwdec=no (software decoding), so it doesn't
appear to be tied to a specific VO backend or hardware decoding.

Embedded via python-mpv (ctypes/libmpv). Full manifest.mpd from one crash session is attached.

Log File

python.exe.14488.dmp

output.txt

Sample Files

manifest_1783409233627.txt

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[kasper93]

Reproduction Steps

Those are not really reproducible on my side.

python.exe.14488.dmp

shinchiro builds doesn't have debug information. In fact, I don't think anyone shared debug info for libmpv. https://github.com/zhongfly/mpv-winbuild/releases has them for mpv.exe only.

Either way, would be good if you could reproduce this with mpv.exe and capture the dump there, so we can have workable stack trace. Or provide steps so we can reproduce the crash. Else we don't really have anything tangible to work with.

[annah464545-hub]

mpv_issue_followup.md

output.txt

[annah464545-hub]

mpv_issue_followup2.md

[kasper93]

I'm attaching a fresh mpv.exe log/dump for the proxy-mediated crash captured

I don't see the dump attached.

If it would help, I can try to write a minimal standalone reproduction (a small local HTTP server that serves a synthetic DASH stream with this exact 503-then-recover-then-switch pattern

Yes, this would help a lot. Also I see in your log you are using slightly older build built on Jun 10 2026 00:25:12. There were a lot of changes recently to http (both new libcurl support and in ffmpeg itself) and even dash demuxer. Looking at the log, it seems that this build is without curl, but that's not really that important, because without a crash dump or reproduction ability, we can only guess where it fails.

proxy returns 503 instead of serving corrupt/incorrectly-decrypted data when it doesn't yet have the right decryption key, expecting mpv to just retry.

It will retry, but give up after max retries, I think you can configure this to higher number to keep retrying. But we need to fix the root cause of crash first. And yes, this sound reasonable that this behavior trigger some issues, not really tested scenario.

[annah464545-hub]

python.exe.14488.dmp

[annah464545-hub]

Here's a minimal standalone reproduction — no AbemaTV, no ClearKey/DRM, no dependency
on my app at all. It's a small Python stdlib-only HTTP server serving a synthetic
DASH stream that mimics the exact HTTP-level pattern I found right before every
crash: repeated 503 on the same segment, followed by a sudden recovery + switch to
a Period with multiple simultaneous Representations.

See attached README for usage. Let me know if it reproduces on your end too, or if
I should adjust the timing/counts (STALL_COUNT / STALL_INTERVAL_SEC in the script)
to more closely match the field case (17 consecutive 503s over ~5 minutes, ~15s apart).

Also noted your point about the build being older (Jun 10) and missing libcurl —
I'll grab the latest zhongfly build and re-test with that too.

mpv_repro_server.zip

[kasper93]

See attached README for usage. Let me know if it reproduces on your end too, or if
I should adjust the timing/counts (STALL_COUNT / STALL_INTERVAL_SEC in the script)
to more closely match the field case (17 consecutive 503s over ~5 minutes, ~15s apart).

It doesn't reproduce for me. I don't think the script does what you describe, because it does send dozen of 503 at the start of the playback and then never again. I would expect it to repeat 503 so it triggers error.

python.exe.14488.dmp

Like told before, libmpv doesn't have symbols in those builds, use mpv directly for dump.

[annah464545-hub]

Thanks for the patience. I've now verified the updated script on my end too —
the stall→cm cycle repeats correctly and the 503s are paced at ~2s intervals,
but mpv does not crash with the synthetic stream (same as what you observed).
This suggests the crash may require something present in the real AbemaTV stream
that the synthetic one doesn't replicate — most likely the specific MPD structure
(Period/@id format, SegmentTimeline layout, AdaptationSet attributes, etc.)
rather than the DRM/decryption side itself.
Two options I can think of:
1.Share an anonymized capture of the real AbemaTV MPD (no segments needed, just
the XML) so you can reproduce locally. I can strip any personally identifying
fields before sharing.
2.Try to reproduce on a live AbemaTV stream directly — let me know if that's
feasible on your end.

Happy to provide whichever is most useful for tracking down the root cause.

[kasper93]

Happy to provide whichever is most useful for tracking down the root cause.

I don't care how you provide the reproducible case. It's really up to you what you want to share it. However, please tell you LLM to test your minimal reproducer next time, don't waste my time.

[annah464545-hub]

Apologies for the wasted iterations on the synthetic reproducer. I've now obtained a crash dump directly from mpv.exe against the real AbemaTV stream via a local ClearKey decryption proxy, and it reproduces the exact same NULL+0x2C read:

Exception: EXCEPTION_ACCESS_VIOLATION (0xC0000005) — READ at 0x000000000000002C
Faulting address: mpv.exe+0x228E12F
Thread: 1656

Crash dump attached (mpv_exe_11688.dmp, 15 MB, from mpv.exe directly — not libmpv).
The scenario: a local HTTP proxy returns 503 on encrypted segment requests while waiting for a ClearKey key, then recovers when a CM (ad) Period with different Representation IDs appears in the MPD alongside the stalled Period. The crash occurs during or shortly after the Period transition.

mpv.exe.11688.dmp