[FFmpeg-devel] [PATCH] avutil/log: in colored_fputs, convert string from utf8 to CP_ACP charset on Windows

[周泽华]

A new patch is attached with following modification:

1. Add function check of MultiByteToWideChar and WideCharToMultiByte in
configure, and change the condition macros to HAVE_* . I am not sure if it
is the right way.

2. Remove unneeded code.

3. The conversion is done *ONLY* when the log is *NOT* redirected. So
the effect of the patch is minimized.


The thought of the patch is to satisfy normal users as much as possible. I
think that the behaviors of a normal user are:

a. He/She will use Windows Console instead of MSYS or Cygwin shells, and will
view the output in console instead of redirection. (Anyway, because of the
modification 3, ffmpeg will work correctly with MSYS, Cygwin Shells and
redirection.)

b. The font of Windows Console is left the default one, which does not support
utf8 characters. (So it is not good to change the code page of Windows Console
to utf8.)


I did some quick tests with MSYS, Cygwin shells, with media files that have
metadata in utf8 or local code page, ffmpeg works well in all conditions.


Following is a copy of the commit log of the patch, for your reference.

 avutil/log: in colored_fputs, try to convert strings to local code
page on Windows

    The string of file name in ffmpeg is in utf8 charset, the strings of
    metadata are in utf8 or local code page or other charsets depending on
    the charset of media files. On Windows, the default charset of Console
    is local code page. When the strings in ffmpeg are logged to Console,
    the output is messy or a mix of readable and unreadable strings.

    The codes in this commit try to convert strings in ffmpeg to local code
    page when stderr is NOT redirected, and if the conversion is successful,
    log the converted strings to Console.

    How this commit affects ffmpeg: If the metadata is in utf8, the output
    in Console is messy before the commit, and is good with high probability
    after this commit. If the metadata is in local code page, the output is
    a mix of unreadable file name and readable metadata before the commit,
    the output is good at high probability or a mix of readable file name
    and unreadable metadata at low probability after the commit. If the
    metadata is in other charsets, the output is always messy before or
    after the commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avutil-log-in-colored_fputs-try-to-convert-strings-t.patch
Type: application/octet-stream
Size: 5022 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140221/89e7c709/attachment.obj>