mplayer vs. polish subtitles

Typically, when I start seeing a film, I only have enough time to quickly get some subtitles, try to make them more-or-less work with the film at hand and ... that's it.
So, lots of repetitive, rushed fixes but no long-term solutions.

But this time I got sick of it and tried to get to understand the problem. Which is: Polish subtitles don't work with mplayer, or at least not with the mplayer built with MacPorts' mplayer-devel port, which uses mplayer's SVN HEAD.

The option -subcp cp1250 does select the codepage (cp1250 is variously called Windows Latin 2 or Windows Central European encoding, which seems to be the typical encoding used by polish subtitles on the net)

The option -subcp enca should auto-detect the encoding, but the port disables enca at configure time, and provides no way to enable it. I'll try to send a patch for that.
In the meantime, enca -L pl -i file by itself works nicely (enca is provided by a port). For difficult cases when enca fails, the chardet module for python should work; didn't try it yet.

So now we have subtitles with the right encoding. Next problem: the displayed subtitles have some polish letters missing! (not all, which is strange. ć and ł do work, but ż and ą don't)

-fontconfig, -font don't seem to do anything. -font in particular doesn't seem to mind what kind of file I feed it, or even if it exists, and -msglevel all=9 doesn't show anything. Looks like -nofontconfig is needed for -font to start having any effect. Which sounds logical given that the fontconfig project seems to be all about autoconfiguring font management, but the mplayer docs say pretty little about all of this.
So, with -nofontconfig present, -font does accept .ttf files, but also .desc files.

(I have a pack of fonts for mplayer called font-arial-cp1250, which contains some variations of some arial font consisting on sets of .raw files with a main font.desc file. I seem to remember that I downloaded it from some forum. The files are dated from 2003. The font.desc files can be feed to mplayer with the -font option. And they don't work, or rather only seem to work when the encoding is NOT correctly selected with the -subcp option. So this is a dead end, probably outevolved by mplayer in these last 8 years. So better forget this.)

My ~/.mplayer directory also contains a subfont.ttf file, which seems to work fine with the -font option. I have tried a couple of other fonts and they seem to lack the polish characters, so not every .ttf will be OK.

(I don't know if that subfont.ttf is standard. This .mplayer subdirectory has probably followed me through maybe 4 or 5 OS X versions, 4 computers and 2 architectures. Which means, no idea where it came from. The current mplayer port doesn't seem to include such a thing, which is to be expected since MacPorts makes some effort to install things only in well defined places. But I remember having played with other versions of mplayer, from fink to some binaries. Who knows.)

So, to summarize: with -subcp goodencoding -nofontconfig -font goodfont.ttf we should be OK.

And yet, it can be better. At some moment I discovered that the -ass option works. -ass uses libass, which is not covered by any port, so I didn't expect it to work; but mplayer seems to have its own internal version of the library (seen at the configure stage with something like port install -d mplayer-devel, or in the configure.log if macports has not been configured to --clean after installation). And -ass is amazing. -nofontconfig nor -font again don't seem to work, and I don't know where mplayer is getting its fonts now, but it is a good font with all the polish characters. And not only that, but configuration commands contained in some subtitles (.txt files, with not only the subtitles but commands that look like {y:b}{c:$0000ff}; RTF? CSS?) do work, so instead of the occasional rubbish now the subtitles render beatifully, with colors and bolds and italics, oh my.

So, to re-summarize: the best option is something like mplayer vidfile.avi -sub subfile.txt -subcp cp1250 -ass  
(and if I manage to send the patch for enabling enca, it should be something like -subcp enca:pl:cp1250)

Keeping in mind that all of this is for MacPorts' mplayer-devel, which builds the SVN head. So all of this might be quite temporal. Which sucks. Hard.

(Why not use VLC and forget about all of this? Because VLC allows very little control, and most any change means having to stop and start again. That's OK if the film and subtitles are perfectly matched, but that's not usually my case. Meanwhile, in mplayer one can tune lots of things, even while watching the film: go forward and backward in the subtitles and synchronise them to the video / sound; set say 90% speed (VLC only allows 66%, 50%, ...); move subtitles on the screen, even render the film with more black space on the bottom should one want the subtitles to not overlap the image. And then of course is mencoder...)