On 6/11/22 1:01 PM, nil-admir...@mailo.com wrote:
Why not use the AviSynth mechanism that allows to supply a UTF-8 string?
https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852d91dc177d49103c16/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#L844 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 long
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. And while it might work for the fftools themselves, does it
also work for usage of the libraries directly in applications that may
not be console apps?
Barring that, if/else checks to ensure that
A) IsWindowsVersionOrGreater is at least 1903
A1) If yes, go to B
A2) If no, use the existing logic
B) If yes, GetACP to check that it's UTF8
B1) If yes, the Import call stays the same as it is now, no utf8 parameter
B2) If no, that's where things get complicated:
C1) Use the no result to tell it to then force UTF-8 mode with
SetConsoleCP, if that actually works for what we need it to do. Then
don't use the utf8 parameter.
C2) Use avs_get_version to detect an incompatible version of AviSynth
and gracefully exit with a message about upgrading to a supported
version of AviSynth+, before then using the utf8 parameter for real.
C3) Use avs_get_version, but if it's not a new enough version, just fall
back to the logic that exists now, where 2.6 may or may not work just
because the system may or may not be already set to UTF-8.
C2 should really be considered a last resort IMO, because it's an
artificial limit and doesn't actually have anything to do with the
AviSynth API.
The reason is that the utf8 parameter being discussed here is not part
of the AviSynth API, it's an option handed to one of the script-level
functions that avs_invoke (which is the actual API call there) is using.
On the other hand, configure checks for
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L844
die "ERROR: AviSynth+ header version must be >= 3.7.1"
so probably plain AviSynth and AviSynth+ below r2489-MT are already unsupported.
The header version check there isn't because of old versions of
AviSynth(+) being unsupported (as far as the demuxer is concerned,
anyway). 3.7.1 is still API compatible with 2.6 in all the functions
the demuxer uses that are shared between them. The additional
Plus-specific functionality is enabled with runtime checks, so if you
don't use the newer header, it will fail to build, but you can run 2.6
without problems even when using the newer header to compile the demuxer.
_______________________________________________
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".
