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

Tadashi Ando ando at je-pu-pu.jp
Sat Mar 25 17:55:02 EET 2017

>> 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 ...

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

Tadashi Ando

More information about the MPlayer-dev-eng mailing list