Unicode file names support about mp4v2

[GoogleCodeExporter]

I'm going to fix this--there are a few options:

- Change all the filename parameters in mp4v2 to const wchar_t* (along with 
required
file system call changes)
- Add sibling "XyzUtf8" version of functions that take const char* so that 
existing
calls expecting the "local 8 bit" didn't break on other people unexpectedly, 
and then
use UTF-8 for file names, converting to wchar_t and unicode where needed.
- Same thing as 2nd, but just change existing functions to mean utf-8 when they 
pass
const char* 

This is unfortunately a complicated problem, and particularly so because the 
POSIX
implementation uses fstream.open, which has different meanings depending on the
platform.  Under OSX, it's implied that fstream.open accepts a UTF8 string, but 
that
isn't the case with gcc or most windows compilers.

Anyone have any thoughts on this?

By the way, an easy way to reproduce this issue is simply name a file 
"Nàáâãåæmé 姓名
测试 зиøù Tửst.mp4," and MP4v2 probably will not be able to open the 
file.  Rename it
to something in your local 8-bit code page and I think you're okay.

Original comment by [email protected] on 1 Apr 2010 at 2:26

[GoogleCodeExporter]

Hmm...in doing a bit more research, another option (I think?) is to use
MP4CreateProvider.  Might look into that more--it may be that the best solution 
is a
completely separate file provider than the ones the default library provides. 

If I go this route, it'll probably be something based on Qt's QFile

Original comment by [email protected] on 1 Apr 2010 at 2:30

[GoogleCodeExporter]

A provider unfortunately isn't an option due to the calls in 
FileSystem_win32.cpp,
which reference the ASCII versions of all the primitive functions.  Doh.

e.g.:

bool
FileSystem::getFileSize( string path_, File::Size& size_ )
{
    size_ = 0;
    WIN32_FILE_ATTRIBUTE_DATA data;
    if( !GetFileAttributesExA( path_.c_str(), GetFileExInfoStandard, (LPVOID)&data ))
        return true;
    size_ = ((File::Size)data.nFileSizeHigh << 32) | data.nFileSizeLow;
    return false;
}

...also, these should really be part of the file provider interface.  I'm not 
sure
why file provider doesn't encompass all of this.

Original comment by [email protected] on 1 Apr 2010 at 6:50

[GoogleCodeExporter]

Issue 55 has been merged into this issue.

Original comment by [email protected] on 2 Apr 2010 at 12:46

[GoogleCodeExporter]

r375 should fix this issue, at least on win32.  On *nix and OSX, there may be 
more
work to do.  I ended up going with option #3 (change existing functions to mean 
utf-8
when they pass const char*); if anyone has feedback on the implementation, I'd
welcome that.

closing this.

Original comment by [email protected] on 2 Apr 2010 at 8:19

• Changed state: Fixed