Re: [MPlayer-dev-eng] [PATCH]can not open ISO file including multibyte file path. on Windows.
- Date: Sun, 26 Mar 2017 00:55:02 +0900
- From: Tadashi Ando <ando@xxxxxxxxxxx>
- Subject: Re: [MPlayer-dev-eng] [PATCH]can not open ISO file including multibyte file path. on Windows.
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
"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 ?
MPlayer-dev-eng mailing list