[FFmpeg-devel] [PATCH] avutil/log: in colored_fputs, convert string from utf8 to CP_ACP charset on Windows
zhouzehua at gmail.com
Thu Feb 20 09:22:16 CET 2014
2014-02-20 15:28 GMT+08:00 Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
> On 19.02.2014, at 09:09, ZHOU Zehua <zhouzehuasx at gmail.com> wrote:
>> From: ZHOU Zehua <zhouzehua at gmail.com>
>> The strings in ffmpeg are mostly in utf8 charset, but the default
>> charset of Windows Console is not utf8. As a result, the log output is
>> garbled. This commit adds code to convert string from utf8 to CP_ACP
>> before printed on Windows.
>> Note: If the input string is not in utf8, the conversion is supposed to
>> fail and the original input string will be printed.
> I think this is questionable and actually break things.
> For example if someone redirects the output to a file, they will get everything just in UTF-8 currently.
> After this patch, they instead get the output in a messy mix of local code page (strings that are entirely representable in it) and UTF-8 (those that aren't and where the conversion fails).
> As far as I can tell the proper way to do this is to use WriteConsoleW, but only if there is no redirection.
> I can easily see that we might encounter a few unexpected issues with that though.
In fact, the output is a messy mix before the patch, at least on my computer.
How it happens:
The command line arguments are handled in 'prepare_app_arguments' function of
cmdutils.c, which converts arguments to utf8, so the file name in arguments is
stored in utf8 in ffmpeg. Because of the popularity of Windows, the metadata
in media files is mostly stored in local code page (as far as I observe), and
ffmpeg store metadata without conversion. When file name and metadata are sent
to log, one of them is in utf8 charset and the other is in local code page.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel