concat format doesn't allow spaces in file names

[Kyle Repinski]

Summary of the bug:

The concat(dec) format doesn't allow spaces in file names unless the "-safe 0" argument is passed, as it deems spaces to be an "unsafe character". The problem is allowing unsafe file names (by passing the -safe 0 argument) also enables support for absolute paths, whereas "safe" file names may only be relative paths. Spaces are an everyday occurrence in file and folder names and should be allowed by default without having to enable support for absolute file paths.

How to reproduce:

% ffmpeg -f concat -i playlist.txt ... output
ffmpeg version N-83049-ge71b811 (built on 2017/01/11)

Example "unsafe" playlist.txt:

file 01\ .flac
file 02.flac

[Carl Eugen Hoyos]

Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.

[Kyle Repinski]

Replying to cehoyos:

Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.

Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.

I agree this isn't an "accident", the behavior matches the documentation, but it doesn't make any sense. I believe it was overlooked and is a mistake.

[Cigaes]

Spaces in file names is a very bad idea in many situations. The concat demuxer is very conservative by default; implementing fine-grained policies would be way beyond its scope, and not everybody has the same needs as you.

If you get file names from untrusted sources, you need to validate them according to your specific security requirements.

[Carl Eugen Hoyos]

Replying to MWisBest:

Replying to cehoyos:

Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.

Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.

It is not supposed to be used for patches and not for features that you want removed.

I agree this isn't an "accident", the behavior matches the documentation

That's not what I meant.

but it doesn't make any sense. I believe it was overlooked and is a mistake.

In this case, the report is of course valid but wont-fix.

[Kyle Repinski]

Replying to cehoyos:

Replying to MWisBest:

Replying to cehoyos:

Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.

Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.

It is not supposed to be used for patches and not for features that you want removed.

I agree this isn't an "accident", the behavior matches the documentation

That's not what I meant.

but it doesn't make any sense. I believe it was overlooked and is a mistake.

In this case, the report is of course valid but wont-fix.

Alright, that's fair. Thank you for the clarification.