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

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.

Start with the attached python.exe.14488.dmp and output.txt, then reproduce the crash using manifest_1783409233627.txt through python-mpv/libmpv with rapid MPEG-DASH Period transitions. Compare worker-thread behavior with vo=gpu, vo=gpu-next, and hwdec=no; done means playback continues without the NULL+0x2C access violation.