[MPlayer-dev-eng] [PATCH]can not open ISO file including multibyte file path. on Windows.

[Tadashi Ando]

>> We should call it "Local Windows code page" ?
>
> That is a reasonable term I'd say.
> Part of the point is that it's not one specific encoding, but it is different for different regional Windows editions.

OK. I use term "Local Windows code page".

>> CreateFileA() expect "Local Windows code page" as file path.
>> But current MPlayer using UTF-8. It is completely wrong, logically.
>> ( In most multibyte environments, the "Local Windows code page" and UTF-8 do not match. )
>>
>> Is my understanding of this correct ?
>> ( and if so, I think my patch is not best, but better than current. )
>
> Yes, I agree (I did write it is an improvement), I just was a bit confused by your patch description and not sure you were aware it is a partial solution.

Thank you for confirmation.
I understand. My patch is a partial solution.

>>> IMO a "proper" solution would be to make DVDOpen support UTF-8
>>> file names,
>>
>> "Ideally", I also think it is best.
>> Thank you for your advice.
>>
>>> or alternatively add a new DVDOpen variant that support
>>> wchar_t input (then the stream_file code should be possible to
>>> reuse).
>>
>> I don't think it is good idea that implement DVDOpen() variant in MPlayer.
>> Because it is via external libraries. How do you think ?
>> In the DVDOpen(), actualy, file is opening in win2k_open() of libdvdcss external library.
>
> I agree, to go that way (or even the UTF-8 support) it would need to be added to the libdvdread libraries, there'd probably need to be a feature test to check if it's available etc.
> So quite some effort. So I can't blame you if you'd rather leave it at the approach your patch uses.
> Just simplifying it by avoiding the dynamic symbol lookups and possibly sharing code with either the ffmpeg or stream_file implementation (have not checked if possible) is a must if you want my ok on it (even though I admit that the stream_file code certainly is not any better, I will need to put cleaning it up on the TODO).

Yes. It is hard to fix libdvdread.
I don't fix libdvdread for now.

I will fix my patch.
(1). I clean code of dynamic symbol lookups.
(2). I will share the encoding conversion code with stream_file etc.

I have a question about (2).
Where should the shared code be placed ?

I will add functions like the following ...
win32_convert_utf8_to_wide_char()
win32_convert_wide_char_to_local_windows_code_page()
win32_convert_utf8_to_local_windows_code_page()
...

For these functions, should I create a new file somewhere ?
Or is there already a suitable file ?


-- 
Tadashi Ando