[FFmpeg-devel] [PATCH v2] avformat: add a concat protocol that takes a line break delimited list of resources

[James Almer]

On 6/27/2021 4:00 PM, Nicolas George wrote:
> James Almer (12021-06-27):
>> How is it not accurate enough?
> 
> Which characters must be escaped? Is it legal to escape another
> character? Does it support single quotes like the other escaping
> functions? Can you use byte or Unicode numbers?

Only line breaks need to be escaped. I said as much and even suggested 
to make it more explicit in the documentation.
Every other character will be read and added verbatim into a string used 
as uri for a given resource that ffurl_open_whitelist() will then handle.

Create a text file with the following four entries

foo\
bar.h264
foo'bar.h264
foo\bar.h264
foobar.h264

Where only the line break is escaped to ensure it's not interpreted as a 
resource name delimiter, and they will all be read and open if they exist.

> 
> Various escaping syntax have subtle differences about these points, and
> this is something users need to know about, especially for scripts.
> 
> Anyway, our escaping syntax should be documented once well, with links
> to it everywhere where needed, the description must not be duplicated
> all over the place.
> 
>> I can add a line to the documentation stating that no other character needs
>> to be escaped if that will make it more clear.
> 
> Make it a link to the unique good documentation of escaping.

There's no need for any escaping other than the delimiter character, so 
wouldn't it be misleading linking to a document that will make you write 
your entries in the file in a way that will not work?
Said documentation will tell you that if you want to load foo'bar.h264 
you will need to write it as foo\'bar.h264, but that's not true here and 
will only make it attempt to load a file with all those characters as 
part of its name.

> 
> If we do not have an unique good documentation of escaping, the it needs
> to be written, and this is a good occasion. But I think we have it.
> 
>> The existing de-escaping functions will just remove backslashes, and the
>> line break character will be parsed as a delimiter, which is why i wrote the
>> above to ensure it is read as part of the filename.
>>
>> The contents of the file are meant to be taken as is, and if you want the
>> delimiter character to be part of the filename, you need to let the parser
>> know about it. Every other character in the text file doesn't need to be
>> escaped since this is not the command line where they could be interpreted
>> as something else.
> 
> I know what the existing de-escaping functions do, and I know what they
> can be used for, and I repeat: you can the parsing correctly with them
> by reading the whole file at once.
> 
> But as it is, this code duplication is a big no.

Wont your request to use escaping functions result in the need for the 
entries in the text file to start pointlessly escaping characters like 
quotes, backslashes and others for no reason, as if this were bash?

The protocol right now supports line breaks as part of the filename if 
you escape it like you asked me to support, alongside every other 
character without doing anything for them. What you're now asking from 
me is to require it to parse more characters than necessary as if this 
was the command line, when there's no reason to.

> 
> Regards,
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>