M3U playlist misdetected as AMR-NB

[sfan5]

mpv Information

mpv v0.40.0-472-g23f9381b8 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Nov 29 2025 13:17:29
libplacebo version: v7.357.0 (v7.351.0-89-g06992a53)
FFmpeg version: n8.0
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Important Information

- Platform version: Arch Linux x86_64
- GPU model, driver and version: -
- Source of mpv: self-compiled
- Latest known working version: -
- Issue started after the following happened: -

Reproduction Steps

1. (echo '#EXTM3U'; for i in $(seq 1 102); do echo './aaaaaaa.00000..aaa'; done) >4.m3u
2. mpv --no-config 4.m3u

Expected Behavior

3. mpv reads the playlist contents

Actual Behavior

3. audio playback

Log File

mpv_log.txt

Sample Files

No response

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

• I tested with the latest mpv version to validate that the issue is not already fixed.
• 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.

[sfan5]

While it would be correct to blame the AMR demuxer in ffmpeg, I'm thinking shouldn't our playlist demuxer run before lavf?

Edit: apparently #14555 changed this, but it's not obvious to me why. @kasper93?

[kasper93]

Edit: apparently #14555 changed this, but it's not obvious to me why. @kasper93?

Changed what?

[sfan5]

demuxer_desc_playlist being above demuxer_desc_lavf (c54ad69)

[kasper93]

PR diff doesn't show this change. Move it if you feel it's better to ignore lavf detection.

[llyyr]

demuxer_desc_playlist being above demuxer_desc_lavf (c54ad69)

This is actually reverting a change made by the previous commit. History for that PR is not clean, but the priority list hasn't changed as a result of that PR

[kasper93]

demuxer_desc_playlist being above demuxer_desc_lavf (c54ad69)

This is actually reverting a change made by the previous commit. History for that PR is not clean, but the priority list hasn't changed as a result of that PR

What is not clean? The fact you don't understand the history of those changes, doesn't make it "not clean".

[kasper93]

demuxer_desc_playlist being above demuxer_desc_lavf (c54ad69)

This was wm4 in 8be9c49, so it has to be correct, right?

[sfan5]

Move it if you feel it's better to ignore lavf detection.

As far as it looks the probing code for the different formats is robust and can be safely applied before lavf probing.

[kasper93]

Move it if you feel it's better to ignore lavf detection.

As far as it looks the probing code for the different formats is robust and can be safely applied before lavf probing.

HLS works correctly? Because IIRC I needed to split directory and playlist demuxer, because using playlist demuxer first would load HLS as normal playlist instead of demuxing it in lavf.

[sfan5]

I didn't try, but should work apparently?

mpv/demux/demux_playlist.c

Lines 289 to 290 in c54ad69

	} else if (bstr_startswith0(line_dup, "#EXT-X-")) {
	p->format = "hls";

You're right, that wouldn't work.

Either way I'll report this to ffmpeg first.