[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