[MPlayer-users] Issue with Unicode file name in the slave mode with Windows binary
Abu Abdullah
falcon.sheep at gmail.com
Thu Mar 7 05:58:40 CET 2013
On Wed, Mar 6, 2013 at 8:17 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Wed, 6 Mar 2013 11:15:07 +0400
> Abu Abdullah <falcon.sheep at gmail.com> wrote:
>
> > I did test the case with another 2 binaries compiled by others:
> > http://code.google.com/p/mplayer-for-windows/
> > http://oss.netfarm.it/mplayer-win32.php
> >
> > The same results they are not working.
> >
> > In addition, I have tested it with mplayer2 (2 binaries compiled by
> > others): http://code.google.com/p/mplayer2-for-windows/
> > http://mplayer2.srsfckn.biz/
> >
> > And they are working fine. so i guess there might be something in
> > mplayer and not in compilation.
>
> Microsoft and MinGW are to blame. Microsoft, because they want you
> to use the non-standard Unicode API (a different set of APIs that only
> accept UTF-16) and don't allow to use the standard C functions with
> UTF-8. MingGW-w64 is to blame that they don't provide transparent
> wrappers to treat char* as UTF-8. (Yet they compensate for other bad
> aspects of the Windows libc, like LFS support or C99 printf...)
>
> We added some extremely disgusting hacks to make it work on Windows:
> https://github.com/mpv-player/mpv/blob/master/osdep/io.h#L52
>
Thanks for the explanation, I did not understand it very well but does that
mean the file name will be called from the command line in a different
encoding than when you call it in the slave mode. The program will use the
same API in both cases, Am I right?
More information about the MPlayer-users
mailing list