Player closes unexpectedly on Twitch low-latency streaming with ffmpeg 9.0.1

[Lordshinjo]

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.360.1
FFmpeg version: 9.0 (runtime 9.0.1)
FFmpeg library versions:
   libavcodec      63.1.100 (runtime 63.1.101)
   libavdevice     63.1.100 (runtime 63.1.101)
   libavfilter     12.1.100 (runtime 12.1.101)
   libavformat     63.1.100 (runtime 63.1.101)
   libavutil       61.1.100 (runtime 61.1.101)
   libswresample   7.1.100 (runtime 7.1.101)
   libswscale      10.1.100 (runtime 10.1.101)

Other Information

- macOS version: macOS 26.6.2 (25G83)
- Source of mpv: Homebrew, though master exhibits the same behavior
- Latest known working version: N/A
- Issue started after the following happened: Upgrade of ffmpeg to 9.0.1

Note that ffmpeg 9.0.1 contains the following change which causes the issue: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23750
However I don't know whether this is a bug in ffmpeg or a bug in mpv exposed by this change.

This is also closely linked to using the latest version 8.5.0 of [streamlink](https://github.com/streamlink/streamlink), though it seems unlikely to me that streamlink causes the issue.

Reproduction Steps

The issue happens when playing a Twitch stream that uses Twitch Enhanced Broadcasting using streamlink in low latency mode and passing data to mpv through stdin (the default).

Example command:

streamlink https://www.twitch.tv/cohhcarnage best --twitch-low-latency --player-verbose --player mpv --player-args '--no-config'

This command will fork a mpv process like this:

mpv --force-media-title=https://www.twitch.tv/cohhcarnage --no-config -

Then it feeds data from the segments located in the EXT-X-TWITCH-PREFETCH tags of the m3u8 playlist provided by Twitch, as they are being downloaded.

Note: This requires both using low latency mode (--twitch-low-latency) and passing data through stdin (e.g. using a named pipe by using the --player-fifo streamlink argument does not exhibit the issue)

Expected Behavior

The stream plays properly until it ends or the player is exited.

Actual Behavior

After a relatively short time (less than a minute), the player closes after displaying an error like this:

[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: trun sample count 7 exceeds the -97 samples the input can hold
[lavf] error reading packet: Invalid data found when processing input.
Exiting... (End of file)

Log File

Output from running:

streamlink https://www.twitch.tv/cohhcarnage best --twitch-low-latency --player-verbose --player mpv --player-args '--no-config --gpu-debug --log-file=output.txt'

output.txt

Sample Files

I cannot supply a reproducible media file as this concerns streaming (and the error may be linked to network latency), but other streamers on which this fails include: https://www.twitch.tv/patty, https://www.twitch.tv/whiskeyding0.

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.

[Lordshinjo]

Sorry, I went back on it and found a way to reproduce it (at least reliably on my system) without having to rely on Twitch.

test.mp4

When reading this file directly, this plays properly with the timestamp going from 08:49:20 to 08:49:33.
When reading through test.py, the player exits early at 08:49:32 with:

[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: trun sample count 5 exceeds the -194 samples the input can hold

Also note that I was unable to reproduce the issue using ffplay or ffmpeg instead of mpv.