[FFmpeg-devel] [PATCH] Support for UTF8 filenames on Windows

[Karl Blomster]

M?ns Rullg?rd wrote:
> Karl Blomster <thefluff at uppcon.com> writes:
> 
>> Michael Niedermayer wrote:
>>> On Sat, Jul 18, 2009 at 12:59:27AM -0300, Ramiro Polla wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jul 16, 2009 at 2:55 PM, Karl Blomster<thefluff at uppcon.com> wrote:
>>>>> Ramiro Polla wrote:
>>>>>> On Thu, Jul 16, 2009 at 11:20 AM, Karl Blomster<thefluff at uppcon.com>
>>>>>> wrote:
>>>>>>> Unless I am severely missing something in your updated patch (thanks for
>>>>>>> the
>>>>>>> nice work, by the way!) it will not work with the FFmpeg commandline
>>>>>>> program. If you want an Unicode commandline in Windows you need to use
>>>>>>> wmain() or _tmain() instead of plain old main(), AFAIK. As I said earlier
>>>>>>> my
>>>>>>> original patch was only intended to let the API support Unicode. Working
>>>>>>> it
>>>>>>> into ffmpeg.c would be a lot more work, I think.
>>>>>> How do you test UNICODE support?
>>>>>>
>>>>>> I used attached shell file with msys (sh test_unicode.sh) and it works
>>>>>> as expected (only the unicode filename without FF_WINUTF8 fails). I
>>>>>> also tested with an app that used Find(First,Next)FileA() and passed
>>>>>> the unicode filenames as ascii string to ff_winutf8_open() and it also
>>>>>> worked as expected.
>>>>> Plain old cmd.exe (both with and without the chcp 65001 trick). I can do
>>>>> stuff like notepad.exe <unicode filename> and it'll work fine, but with
>>>>> ffmpeg it just says file not found (and prints a bogus filename). It works
>>>>> fine with mingw's sh; MinGW probably does some kind of black magic there to
>>>>> get Unix apps to work without having to patch in the Windows mess. The API
>>>>> works fine, of course.
>>>> Do you know of any real example where a codepage->utf8 conversion
>>>> fails? I only see some possible theoretical references scattered
>>>> around the web, but no real examples.
>>>>
>>>> I'm tempted to do the following:
>>>> - Always expect filenames in Windows to be passed in UTF8.
>>>> - Always get the Unicode command line and convert it to UTF8.
>>>>
>>>> That way we always convert to UTF-16 and use _wopen when opening
>>>> files, and MultiByteToWideChar() shouldn't fail.
>>>>
>>>> That is all assuming no support for Win9x/WinME.
>>> i do think ffmpeg should be kept be useable om Win9x, because here it
>>> seems you really try to support the more messy/complex MS asshatry while
>>> droping support for the simpler.
>>> just me 2 euro cent ...
>> Last time I brought Win9x support up, Reimar mentioned that he didn't
>> think ffmpeg works on Win9x as it is anyway, I think that's why Ramiro
>> wasn't going to bother with Win9x support.
> 
> It works on DOS, according FATE.  Why wouldn't it work with a GUI
> frontend to DOS (win98)?

Actually it wasn't Reimar who said it (sorry, Reimar!), it was Ramiro himself, 
and I'll just paste what he said:

Ramiro Polla wrote:
 > If it's because of Win9x users, we already have a couple of places
 > that need higher versions of Windows (like a call in getutime in
 > ffmpeg.c and inside vfwcap IIRC). I haven't heard of anyone seriously
 > using FFmpeg in Win9x and before that happens I don't think we should
 > worry about them =)

Of course I haven't tested it myself, I'm just repeating what he said...

Regards,
Karl Blomster