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

Ramiro Polla ramiro.polla
Sat Jul 18 23:52:29 CEST 2009

On Sat, Jul 18, 2009 at 2:11 PM, Karl Blomster<thefluff at uppcon.com> wrote:
> Ramiro Polla wrote:
>> 1 - lavf takes in UTF-8. lavf users must convert. No environment
>> variables. API breakage.
>> 2 - lavf takes in UTF-8 by default, with environment variable to
>> select system codepage. ffmpeg always overrides that variable to use
>> UTF-8. API breakage. This would be a nuisance to lavf users who want
>> to pass filenames from system codepage.
>> 3 - lavf takes in system codepage by default, with environment
>> variable to select UTF-8. ffmpeg always overrides that variable to use
>> UTF-8. No API breakage. This would be a nuisance for lavf users who
>> want to pass UTF-8 filenames.
>> They're all better than the current "0 - no unicode support".
>> I'm thinking now of aiming towards 3.
> Yeah, 3 would be my preference as well, especially since 1 and 2 would lead
> to a rather subtle API breakage: it won't result in something obvious like
> your application failing to compile against the new ffmpeg, but rather it'll
> just mysteriously fail to open certain files.

New patch attached.

Taking Michael's comment in consideration:
> 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.

In this patch, ffmpeg/ffplay test for win9x. If that is the case, the
current behavior continues (no unicode). We could support unicode in
win9x through MSLU, but that's a whole lot more work and I don't think
it's worth it. As a bonus this allows getutime to work properly
instead of returning random values.

And Reimar's:
> I don't mind much, it just seems a bit unfortunate that a user might set this
> variable to make one application that is aware of it work with Unicode while
> at the same time completely confusing some older app that wasn't update to even
> know about this new feature (thus libavformat and the app disagreeing which file
> a certain URL refers to).

I think with this patch's approach this is not so much of an issue.
lavf users still get what they used to get (system codepage).
libavformat minor is raised so lavf users can test if the feature is
there. This will only be a nuisance for users that expect a certain
program to magically start working with unicode files as soon as they
manually update libavformat.dll.

> Also, I think this will not work with drag-and-drop (e.g. drop a file on ffplay.exe),
> for that you would have to call the GetCommandLineW or what it is called function,
> which gives you the command argc/argv as UTF-16 and convert that to UTF-8 (this
> is IMO the less ugly way, instead of using a _wmain instead of main).

drap-and-drop for ffplay already works and with this patch it works
with unicode files as well.

Ramiro Polla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winutf8_2.diff
Type: application/octet-stream
Size: 10839 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090718/c3aed395/attachment.obj>

More information about the ffmpeg-devel mailing list