On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote:
Right, I wasn't aware that the -A version would return a
guaranteed-ansi-compatible version of the filename. If that's really the
case, this patch would indeed be a minor step backwards.
Two options are available:
1. fopen() is replaced with avpriv_fopen_utf8(), getenv() is made Unicode-aware
on Windows, and wide version of get_module_filename() is used as it is now.
2. A wrapper around GetModuleFilenameA() created specifically for this case,
only to be replaced later by option one, when avpriv_fopen_utf8() gets
merged.
If option one is chosen, the patch will have to wait for avpriv_fopen_utf8()
patches.
For that, the first option sounds better - that sounds to me more like a
direction forward, not backwards.
The patches for *_fopen_utf8 have already been merged - within the
libraries, you can use avpriv_fopen_utf8, and fftools has got a separate
"fopen_utf8" function it can use.
// Martin
_______________________________________________
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".
