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

[Reimar Döffinger]

On 11.03.2017, at 22:55, Tadashi Ando <ando at je-pu-pu.jp> wrote:

> > I think you are actually converting from UTF-8 to the local
> > 8-bit code-page (which usually isn't actually ANSI).
> 
> 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.

> > It also means that while it's an improvement, it won't be
> > able to open files where the filename cannot be represented
> > in the local 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.

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

Kind regards,
Reimar