Does not write file to target location if filename contains escaped &

[balooii]

Noticed this on Kdenlive but can reproduce it in Shotcut exactly the same so this appears to be an issue in mlt.

Both applications will create an .mlt file where the consumer target property is set to /path/Black&White.mp4 when in GUI it was specified as /path/Black&White.mp4. When melt does its thing it will write the file to /path/Black&White.mp4 not /path/Black&White.mp4.

Thank you for your work on this project.

To reproduce I created a color clip in Shotcut/Kdenlive and exported using default h264 profile to a file named Black&White.mp4.

[ddennedy]

I just tested it on Linux, and it works fine for me:

<consumer ... target="/home/ddennedy/Videos/tests/foo &amp; bar.mp4"

I also tested target="/home/ddennedy/Videos/tests/foo&bar.mp4" in case the space after & matters

Since I think the name is passed to the FFmpeg libraries, it might depend on its version. I am using version 7.0

[balooii]

Indeed, you could be on to something. All versions i tried use some higher version than 7.0

latest Kdenlive from flathub

laptop% flatpak run --command=/bin/sh org.kde.kdenlive
[📦 org.kde.kdenlive ~]$ ffmpeg -version
ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers

latest Shotcut from flathub

laptop% flatpak run --command=/bin/sh org.shotcut.Shotcut
[📦 org.shotcut.Shotcut ~]$ ffmpeg -version
ffmpeg version 7.1 Copyright (c) 2000-2024 the FFmpeg developers

latest Kdenlive from Arch Linux

laptop% ffmpeg -version
ffmpeg version n7.1 Copyright (c) 2000-2024 the FFmpeg developers

When grabbing the oldest built from flathub for Shotcut (24.02.29) I get

laptop% flatpak run --command=/bin/sh org.shotcut.Shotcut
[📦 org.shotcut.Shotcut ~]$ ffmpeg -version
ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers

and using this old version ... 🥁 ... works! Black&White.mp4 ends up being saved.

Any recommendations what would be next steps? I guess I could try to built mlt and ffmpeg myself to see when/if I can reproduce it?

[ddennedy]

Sorry, I was mistaken. I was on 7.1, but the exact patch version varies based on whether I use my local dev copy or an AppImage, Snap, or Flatpak build of Shotcut. AppImage and Snap uses the 7.1 branch. Flatpak uses the 7.1 release tarball. When I tested previously, it was on my local dev build.

I just tested the Shotcut 25.03 Flatpak, and it reproduced for me. Next, I just tested the Snap (same build as AppImage) 25.04.14 from the Edge channel, and that did not! Same with the 25.03.29 AppImage. So, it seems like something that appeared in 7.1 and then cleared up by March 29. Here are the commits in that branch. https://github.com/FFmpeg/FFmpeg/commits/release/7.1/

[ddennedy]

A workaround is to use + instead of &.

It still reproduced for me with the tip of the FFmpeg 7.1 branch, but it did not using ffmpeg from the same build as Shotcut.

[balooii]

I could be in the completely wrong place here but I added logging after this line in avformat consumer https://github.com/mltframework/mlt/blob/8b0f73e7363a8032a98d769900f8ed382e96b1a4/src/modules/avformat/consumer_avformat.c#L2059C47-L2059C57

It prints out this

/home/balooii/Videos/black&white.webm

While in the MLT XML file I have this:

 <consumer ... target="/home/balooii/Videos/black&amp;white.webm" />

So with my naive understanding I think the problem is that when the xml is parsed it isn't "correctly" unescaping the property. Instead of unescaping this name and converting black&white.webm toblack&white.webm it is converted to black&white.webm which is what ffmpeg sees and writes to this path as is.

Doesn't really explain why you weren't able to reproduce this on an older ffmpeg version 🤔 Maybe they interpreted this name in the past and handled escape sequences or so?

[ddennedy]

A duplicate issue was reported in the Shotcut forum where I noted a possible change in libxml2 behavior https://forum.shotcut.org/t/shotcut-cant-deal-with-in-export-paths-names/48679/4

[ddennedy]

Reopen as this is not working in the latest version of Shotcut that includes this. It works in the older libxml2 in AppImage, portable, and Snap but not in Flatpak or msys2/Windows. Man, I'm just going to have to hard-code in a string replacement in the XML parser.