[MPlayer-dev-eng] [PATCH]can not open ISO file including multibyte file path. on Windows.
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
>> 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 ?
More information about the MPlayer-dev-eng