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

Karl Blomster thefluff
Wed Aug 5 01:35:51 CEST 2009


Ramiro Polla wrote:
> On Tue, Aug 4, 2009 at 8:05 PM, Karl Blomster<thefluff at uppcon.com> wrote:
>> Karl Blomster wrote:
>>> Ramiro Polla wrote:
>>>> On Tue, Jul 28, 2009 at 1:32 AM, Ramiro Polla<ramiro.polla at gmail.com>
>>>> wrote:
>>>>> On Wed, Jul 22, 2009 at 10:11 PM, Ramiro Polla<ramiro.polla at gmail.com>
>>>>> wrote:
>>>>>> On Tue, Jul 21, 2009 at 7:22 PM, Diego Biurrun<diego at biurrun.de> wrote:
>>>>>>> On Tue, Jul 21, 2009 at 05:20:51PM -0300, Ramiro Polla wrote:
>>>>>>>> Ok, then, I need someone to take a look at the build system part (I
>>>>>>>> used FF_EXTRA_OBJS but there are some other combinations with less
>>>>>>>> underscores and I can't tell which one is best). Also another look at
>>>>>>>> the documentation is always welcome.
>>>>>>> Please resend the latest version.
>>>>>> Attached.
>>>>>> Changed UNICODE to Unicode and added a LocalFree() I had forgotten.
>>>>>>
>>>>>> There's a #undef __STRICT_ANSI__ in winmain.c because I need the
>>>>>> definitions of __argc and __argv and they're under #ifdef
>>>>>> __STRICT_ANSI__. I could also re-declare as extern.
>>>>> Newer patch that should take care of WinCE.
>>>>> Karl, could you please
>>>>> test the patch to make sure it does what you need?
>>>> ping
>>>
>>> Here, getenv() always returns NULL even if the variable exists, and so the
>>> UTF8 opening path never gets evaluated.
>> Whoops, I'm wrong, it turns out the variable wasn't set after all. getenv()
>> does work and so does the rest of the patch, but I still don't like having
>> to set the environment variable.
> 
> Hmm, I thought this is what had been agreed on in this thread. What
> was your suggestion?

Well, I did (and still do) agree that the environment variable solution is one 
of the least bad ones, especially when compared to subtly breaking the API. But 
in my opinion this should really be a compile time option. No one sane uses a 
shared ffmpeg on Windows; or at least not a version that is actually shared with 
more than one program (because it inevitably leads to DLL hell since you don't 
have a package manager or anything that can keep track of what version the 
different programs using the shared library depends on). People who do build 
shared ffmpeg's just ship their own shared version with their program, so it 
really shouldn't be a problem. I don't really see why it needs to be 
configureable at runtime anyway.

In either case it's your patch now and you're the maintainer, so do what you 
feel is best; for my own very personal needs I would like the default to be UTF8 
just for laziness reasons. But I guess it's trivial to patch so it doesn't 
really matter.

Thanks for all your work on this anyway,
Karl Blomster



More information about the ffmpeg-devel mailing list