Quoting Niklas Haas (2022-03-04 16:03:06) > From: Niklas Haas <g...@haasn.dev> > > I arbitrarily decided to use the syntax 'opt=@filename' to match e.g. > `curl -Ffield=@filename`, and also because @ is not a valid hex > character, nor does it conflict with any other common shell or ffmpeg > syntax. > > This is arguably somewhat clunky because it does not round-trip with > av_opt_get - you will get back a hex interpretation of the loaded file, > rather than the filename it was loaded from. It also implies a (perhaps > unnecessary) memcpy from mapped file memory into a allocated memory. > This is unfortunately necessary because there's no way for us to know > whether av_free or av_file_unmap is needed to clean up previous option > values. > > The motivating use case was the introduction of several new binary > options for vf_libplacebo, but other filters that currently rely on > manual file-path loading could benefit from it as well.
Sorry, I think having an arbitrary file loader in the options parser will be an endless security nightmare. The alternative I had in mind was having ffmpeg.c itself do the file loading. This will be require some modification of the options parsing code in cmdutils.c and also extending the mechanisms we use to pass options to filters. I can try to make a POC in a few days. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".