Long filenames cause every audio output device to reinit with ao=pipewire

mpv Information

mpv v0.38.0-569-g7c70df0934 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.349.0 (v7.349.0-rc1)
FFmpeg version: N-115975-g0c0e7ec81e
FFmpeg library versions:
   libavcodec      61.8.100
   libavdevice     61.2.100
   libavfilter     10.2.102
   libavformat     61.3.104
   libavutil       59.25.100
   libswresample   5.2.100
   libswscale      8.2.100

Other Information

• Linux version: EndeavourOS Linux x86_64
• Kernel Version: 6.9.5-arch1-1
• GPU Model: NVIDIA GeForce RTX 3060 Ti
• Mesa/GPU Driver Version: nvidia-dkms 550.90.07-3
• Window Manager and Version: KDE 6.1.0-1
• Source mpv: mpv-full-git AUR
• Introduced in version: unknown

Reproduction Steps

I appended 100k characters to an EDL URI from a YouTube video's stream-open-filename.

Expected Behavior

Same behavior as with the original ytdl_hook EDL.

Actual Behavior

Causes this message to flash every few seconds, showing the audio device is getting re-initialized.

KDE reports no audio outputs while this is happening. Audio plays (both mpv and other applications) but has frequent glitches not present otherwise. Video plays as normal.

This continues for as long as mpv is kept open, and stops once mpv is closed or after switching to a different file.

Only happens with --ao=pipewire. Diff'd against log with the original EDL, but there is no trace of the constant reinits.

Log File

ao=pipewire mpv-audio-reinit-bug2-v-v.txt
ao=pulse mpv-audio-reinit-bug3-v-v.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.

Start by reproducing the issue with --ao=pipewire and an EDL URI extended by 100k characters, then compare the attached pipewire and pulse verbose logs with the original EDL behavior. Done means the long filename no longer causes repeated audio-device reinitialization or glitches, while normal playback remains unchanged.