> if the path later is going to end up in a codepath that expects it to be UTF8 > (please do check!), then we should go that way instead
I checked. datadir ends up in (cmdutils.c:2104) base[2] = datadir; and base[*] are later used in (cmdutils.c:2112 or 2116) snprintf(filename, filename_size, "%s%s/%s.ffpreset", base[i], i != 1 ? "" : "/.ffmpeg", preset_name); f = fopen(filename, "r"); On Windows fopen expects ANSI encoded strings, so we cannot change the encoding to UTF-8 without rewriting the rest of the function. I've also overlooked something from your previous comment. > unless passing them to an external API Previous version of the manifest (https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293109.html) included <ws2019:activeCodePage>UTF-8</ws2019:activeCodePage> which makes CP_ACP the same as CP_UTF8. Unfortunately external APIs must also opt in for such a change, otherwise they won't be able to decode the strings FFmpeg sent them. A new version of the manifest without code page changes is at https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/293168.html. _______________________________________________ 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".