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

[Måns Rullgård]

Ramiro Polla <ramiro.polla at gmail.com> writes:

> On Fri, Jun 26, 2009 at 11:07 AM, Karl Blomster<thefluff at uppcon.com> wrote:
>> M?ns Rullg?rd wrote:
>>> Karl Blomster <thefluff at uppcon.com> writes:
>>>> Ramiro Polla wrote:
>>>>> On Thu, Jun 25, 2009 at 8:59 AM, Michael
>>>>> Niedermayer<michaelni at gmx.at> wrote:
>>>>>> On Sat, Jun 20, 2009 at 11:56:37PM +0200, Kalle Blomster wrote:
>>>>>>> Currently, ffmpeg on Windows does not support opening files whose
>>>>>>> names
>>>>>>> contain characters that cannot be expressed in the current locale,
>>>>>>> because
>>>>>>> on Windows you can't pass UTF8 in a char* to _open() and have it work.
>>>>>>> You
>>>>>>> have to convert the filename to UTF16 and use _wopen(), which takes a
>>>>>>> wchar_t instead.
>>>>>>>
>>>>>>> I have attached a patch that attempts to solve the problem with a
>>>>>>> rather
>>>>>>> ugly hack. It Works For Me(tm) under mingw at least. Comments are
>>>>>>> appreciated.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Karl Blomster
>>>>>>> ?os_support.c | ? 17 +++++++++++++++++
>>>>>>> ?os_support.h | ? ?5 +++++
>>>>>>> ?2 files changed, 22 insertions(+)
>>>>>>> 9afa6887f1f6998c37d75efaae5d589918dc752b ?ffmpeg_win_utf8_paths.patch
>>>>>>> Index: libavformat/os_support.c
>>>>>>> ===================================================================
>>>>>>> --- libavformat/os_support.c ?(revision 19242)
>>>>>>> +++ libavformat/os_support.c ?(working copy)
>>>>>>> @@ -30,6 +30,23 @@
>>>>>>> ?#include <sys/time.h>
>>>>>>> ?#include "os_support.h"
>>>>>>>
>>>>>>> +#ifdef HAVE_WIN_UTF8_PATHS
>>>>>>> +#define WIN32_LEAN_AND_MEAN
>>>>>>> +#include <windows.h>
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +#ifdef HAVE_WIN_UTF8_PATHS
>>>>>
>>>>> Where is HAVE_WIN_UTF8_PATHS defined?
>>>>
>>>> Nowhere, right now. My thought is to let configure set it with some
>>>> --enable parameter, or you just pass -DHAVE_WIN_UTF8_PATHS in your
>>>> CFLAGS. The point was that I thought it might be a good idea to let
>>>> the user compile with it disabled, if he wanted to, like if someone
>>>> wanted to build on Win9x (heh) or something where unicode support
>>>> might not be available.
>>>
>>> Can we simply test for the existence of _wopen()? ?Is there any reason
>>> to disable this if the function exists?
>>
>> That may be dangerous. It will always exist in the MinGW includes/libraries,
>> but that doesn't mean it's implemented and works in the runtime libraries
>> you end up using. See also below.
>
> It this something from msvcrt or from the MinGW runtime libraries?
> FFmpeg already expects minimum mingw-rt and w32api versions.
>
> 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 =)

Agree.

>> +#ifdef HAVE_WIN_UTF8_PATHS
>> +int winutf8_open(const char *filename, int oflag, int pmode)
>> +{
>> + ? ?wchar_t wfilename[MAX_PATH * 2];
>
> Isn't sizeof(wchar_t) == 2?

Yes, but you might need to use those dreaded surrogate pairs.

> I think you could also use wchar_t wfilename[strlen(filename) + 1]
> instead of malloc if we are going to try and pass paths larger than
> MAX_PATH.

Careful, you might blow your stack.

-- 
M?ns Rullg?rd
mans at mansr.com