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

Ramiro Polla ramiro.polla
Wed Aug 5 03:06:16 CEST 2009


On Tue, Aug 4, 2009 at 8:35 PM, Karl Blomster<thefluff at uppcon.com> wrote:
> 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.

Ok, I prefer having all the functionality in every build. Just
remember to distribute the patched sources with your program...

Ramiro Polla



More information about the ffmpeg-devel mailing list