[FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c: Remove MAX_PATH limit

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Stephen Hutchinson
> Sent: Sunday, June 12, 2022 4:15 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c:
> Remove MAX_PATH limit
> 
> On 6/11/22 1:01 PM, nil-admirari at mailo.com wrote:
> >> Why not use the AviSynth mechanism that allows to supply a UTF-8
> string?
> >>
> >>
> https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852
> d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481
> >
> > Was not aware such a mechanism exists.
> >
> > Commit dates back to 10 April 2017, first release supporting it is,
> apparently, Avisynth+ r2487-MT:
> https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT.
> >
> > A remark in
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L
> 844 says:
> >
> > /* On Windows, FFmpeg supports AviSynth interface version 6 or
> higher.
> >   * This includes AviSynth 2.6 RC1 or higher, and AviSynth+ r1718
> or higher,
> >   * and excludes 2.5 and the 2.6 alphas. */
> >
> > Support for plain AviSynth will have to be dropped.
> 
> Presumably, the original manifest idea, parsed down to only using it
> to
> force FFmpeg into UTF-8, would be sufficient for this, right?  As

This is a change that would affect ffmpeg behavior at a global level,
just for the sake of accommodating for a single 3rd party library 
(and even: only some ancient versions of it).

> as AviSynth inherits that from FFmpeg, UTF-8 strings would be
> pervasive
> and both A) the utf8 parameter would not need to be used and B) 2.6
> would work just fine with it, transparently.
> The Windows API does have a SetConsoleCP function.  If that
> accomplishes
> the same effect as the manifest idea, that would be simpler, but it
> probably would need to be located somewhere *other* than the AviSynth
> demuxer.  

ffmpeg does not interact with AviSynth via console interface.
AFAIU, it uses AviSynth in-process loading it via an API instead:

    val = avs_library.avs_invoke(avs->env, "Import", arg, 0);

Those functions like SetConsoleCP and SetConsoleOutputCP, have no effect
on the current process, it's only about console pipe communication with 
child (cli) processes.
The manifest approach is too invasive IMO, as laid out before.


At least with regards to AviSynthPlus versions since two years ago, 
we're not talking about long paths anymore.
AviSynthPlus is using the same prefixing approach for long paths
that we have employed in ffmpeg as well, now.

The only question is whether we supply the script/path argument to
AviSynthPlus as Ansi or UTF-8 string.
It will handle long paths in both cases. The only difference is that
when we're converting a UTF-8 path to an Ansi codepage, it might
become an invalid path when the projection would be ambiguous. 
It's been like that all the time before - nothing new about it.

There are functions available to check the version:
avs_get_version, avs_check_version,

So - in case that requiring AviSynthPlus from 2020 as a minimum
would be undesirable, it should be possible to find out at
runtime whether the loaded AviSynth supports the UTF8 parameter
or not and set the invoke parameters accordingly.

Best regards,
softworkz