Comment 12 for bug 620158

(In reply to comment #9)
> Do I understand you correctly that you confirm there is
> no issue in the latest upstream version anymore (whether
> you use -ass or not)?
>

Contrarily to Hanno, I still experience the problem if I do not use the "-ass" argument, with the video I linked to at the end of my previous comment, and mplayer-9999 (r32033 now, from `mplayer -v`). I just retested it again.

(In reply to comment #9)
> Also to clarify: libass is only used for styles etc.
> rendering. So if you do not use the -ass command line
> option, libass is not used in any way, neither internal
> nor external.

So there seems to be a problem with the more basic rendering engine, which is not used, or used differently, when using the "-ass" argument.

However, these problems do not appear for SRT subtitles, as said in comment #3 (there is another small rendering problem though, with the two lines at 00:23:50, "I see. That might be a good idea." and "Um..." from the video I linked to, which are displayed on a single line, instead of two with the ASS subtitle track... with mplayer-9999 back then (r31749), it was displayed on two lines, but the "Um..." stayed on screen forever, even with new subtitles being displayed... now it is back to the mplayer-1.0_rc4_p20100506 behavior, with only a single line, which is less problematic, and possibly a completely different problem, so let's forget about it for this bug report).

I tried mplayer-9999 with USE="-ass", and considering that the mplayer-9999 ebuild always disables the internal ASS library, there should not be any relation to ASS anymore. With the ASS subtitle track from the video I linked to, however, I still have the same problems.

It means that without any ASS library, MPlayer still does read ASS subtitle tracks, but simply strips any styling information, right?

- First, the easiest problem is the timing/label being displayed at 00:23:50, meaning it apparently does not strip it properly. Possibly some extension not supported by MPlayer, which trips the stripping process... probably not just a typo leading to some malformation, as I have seen this in various videos from various sources.

- Second, as some subtitles are displayed too long (until another subtitle is displayed, which I suppose is the default behavior), maybe there is some other extension not supported by MPlayer, which leads MPlayer not to be able to read the end time of some subtitles, or something like this.

All this is bypassed when using the `mplayer -ass x.mkv` argument (with USE="ass" to activate libass), so even these extensions work without problem with it, because libass (both internal and external versions) is simply more advanced.