Subtitles stay on screen until next subtitles are shown

[Fabien Tassin]

Binary package hint: mplayer

In maverick, mplayer recently started to show sticky subtitles (they stay on screen until next subtitles are shown).

Looks similar to http://bugs.gentoo.org/show_bug.cgi?id=326351

[Hanno Zysik (h.mth)]

Well, like the summary says, the subtitles stay on screen instead of disappearing after a delay. media-video/mplayer-1.0_rc4_p20100612 introduced it and version 9999 still has it as of today. I wonder if anyone can reproduce this?!

Removing useflag [custom-cpuopts] and changing CFLAGS to "-O2 -pipe" does not help.

Here is my configuration:

___
[ebuild U ] media-video/mplayer-1.0_rc4_p20100612 [1.0_rc4_p20100506] USE="X a52 alsa custom-cpuopts dts dvd dvdnav encode faac faad gif iconv ipv6 jpeg jpeg2k mad mmx mmxext mp3 opengl png quicktime rtc shm sse sse2 ssse3 theora truetype unicode vdpau vorbis x264 xinerama xscreensaver xv xvid -3dnow -3dnowext -aalib (-altivec) -amr -ass -bidi -bindist -bl -bs2b -cddb -cdio -cdparanoia -cpudetection -debug -dga -dirac -directfb -doc -dv -dvb -dxr3 -enca -esd -fbcon -ftp -ggi -gmplayer -jack -joystick -ladspa -libcaca -lirc -live -lzo -md5sum -mng -nas -network -nut -openal -osdmenu -oss -pnm -pulseaudio -pvr -radio -rar -real -samba -schroedinger -sdl -speex (-svga) -tga -toolame -tremor -twolame -v4l -v4l2 (-vidix) -vpx% (-win32codecs) -xanim -xvmc -zoran" VIDEO_CARDS="-mga -s3virge -tdfx -vesa"

___
Portage 2.2_rc67 (default/linux/amd64/10.0/no-multilib, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-gentoo x86_64)
=================================================================
System uname: Linux-2.6.34-gentoo-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.0.1
Timestamp of tree: Wed, 30 Jun 2010 13:45:01 +0000
app-shells/bash: 4.1_p7
dev-java/java-config: 2.1.11
dev-lang/python: 2.6.5-r2, 3.1.2-r3
dev-util/cmake: 2.8.1-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc: 0.6.1-r1
sys-apps/sandbox: 2.2
sys-devel/autoconf: 2.13, 2.65-r1
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils: 2.20.1-r1
sys-devel/gcc: 4.4.4-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.10
virtual/os-headers: 2.6.34
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA dlj-1.1 AdobeFlash-10"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -mtune=core2 -march=core2 -pipe -fomit-frame-pointer -funswitch-loops"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -mtune=core2 -march=core2 -pipe -fomit-frame-pointer -funswitch-loops -fvisibility-inlines-hidden"
DISTDIR="/mnt/data/distfiles"
FEATURES="assume-digests distlocks fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--sort-common"
LINGUAS="de en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-fi...

[Mathieu-aosekai (mathieu-aosekai)]

I have the same problem.

Another associated problem is subtitle labels and timings being shown on screen, when the subtitle author set them to be shown at specific screen positions with special styles (the problem thus mostly appear for lyrics, credits, and translation notes, in the videos I watch, and is not too problematic for now, but still annoying).

Both problems happened when I updated from mplayer_p20100213 to mplayer_p20100612 and ffmpeg-0.5_p21602 to ffmpeg-0.5_p22846 (and still a problem in ffmpeg-0.6)

I tried to update libass-0.9.8 to libass-0.9.9 without change (well, it happens with various videos, they may not even always use it anyway, I'm not sure).

I have no such problems in VLC 1.0.6, for comparison (although I don't know precisely what they may or may not have in common).

My USE flags:

media-libs/libass-0.9.9 USE="enca fontconfig png"

media-video/ffmpeg-0.6 USE="-3dnow -3dnowext X alsa (-altivec) amr -bindist -cpudetection -custom-cflags -debug dirac doc encode faac faad gsm hardcoded-tables -ieee1394 -jack jpeg2k mmx mmxext mp3 network -oss -pic rtmp schroedinger sdl speex ssse3 -test theora threads v4l v4l2 vaapi -vdpau vorbis vpx x264 xvid zlib" VIDEO_CARDS="-nvidia"

media-video/mplayer-1.0_rc4_p20100612 USE="-3dnow -3dnowext X a52 aalib alsa (-altivec) amr ass bidi -bindist -bl bs2b cddb cdio cdparanoia -cpudetection -custom-cpuopts -debug -dga dirac directfb doc dts dv dvb dvd dvdnav -dxr3 enca encode -esd faac faad fbcon ftp ggi gif -gmplayer iconv ipv6 -jack joystick jpeg jpeg2k ladspa libcaca -lirc live lzo mad md5sum mmx mmxext mng mp3 nas network nut openal opengl osdmenu -oss png pnm -pulseaudio pvr quicktime radio rar real rtc -samba schroedinger sdl shm speex sse sse2 ssse3 -svga tga theora -toolame tremor truetype twolame unicode v4l v4l2 -vdpau -vidix vorbis vpx win32codecs x264 xanim -xinerama xscreensaver xv xvid xvmc -zoran" VIDEO_CARDS="-mga -s3virge -tdfx vesa"

media-video/vlc-1.0.6 USE="X a52 aac aalib alsa (-altivec) -atmo -avahi bidi cdda cddax cddb cdio dbus -dc1394 -debug dirac directfb dts dvb dvd fbcon ffmpeg flac fluidsynth fontconfig gcrypt ggi gnome gnutls hal -httpd id3tag -ieee1394 -jack kate libass libcaca -libnotify libproxy -libsysfs libtiger libv4l2 -lirc live lua matroska mmx modplug mp3 mpeg -mtp musepack ncurses -nsplugin ogg opengl -optimisememory -oss (-pda) png -pulseaudio pvr qt4 -remoteosd rtsp -run-as-root -samba schroedinger sdl sdl-image -shine shout skins speex sse stream svg -svga taglib theora truetype twolame udev -upnp v4l v4l2 vcdinfo vcdx vlm vorbis win32codecs -wma-fixed x264 -xcb -xinerama xml xosd xv zvbi"

# emerge --info
Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.34-gentoo-r1 i686)
=================================================================
System uname: Linux-2.6.34-gentoo-r1-i686-Intel-R-_Core-TM-2_Duo_CPU_E6750_@_2.66GHz-with-gentoo-2.0.1
Timestamp of tree: Thu, 15 Jul 2010 09:30:01 +0000
ccache version 2.4 [disabled]
app-shells/bash: 4.0_p37
dev-java/java-config: 2.1.10
dev-lang/python: 2.6.5-r2, 3.1.2-r3
dev-util/ccache: 2.4-r7
dev-util/cmake: 2.6.4-r3
sys-apps/baselayout: 2.0.1
sys-apps/openrc...

[Reimar Döffinger (reimar-doeffinger)]

Somebody had reported this on the MPlayer lists, but when I asked to reproduce with the latest version (since I couldn't) he didn't succeed. So I guess this is fixed in MPlayer SVN, even though I don't know when or how...

[Mathieu-aosekai (mathieu-aosekai)]

(In reply to comment #2)

I just emerged mplayer-9999 (MPlayer r31749), and I still have the two same problems.

For example, I have a video with both ASS and SRT bundled subtitles.

With ASS subtitles, I still get subtitles staying on screen until the next one even though it should disappear before, and sometimes timings/labels (e.g. "Dialogue: 0,0:23:50.35,0:23:51.05,Default-alt,Fuuko,0000,0000,0000,,Um...", for a "Um..." piece of dialog).

With SRT subtitles, normal subtitles disappear normally, and I do not have timings/labels anymore. However, the subtitles which showed timings/labels with ASS, now stay on screen, apparently indefinitely (even when the same character speaks, supposedly with the same labels).

With version 1.0_rc4_p20100612 (it says MPlayer r30554, but the number is set in the ebuild, and it is the same as 1.0_rc4_p20100506, so I suppose it has not been updated...), no other package change, same video, I have the same problems, except that for SRT subtitles, even the subtitles which showed timings/labels with ASS are removed correctly (however, it is displayed at the end of the line of the previous dialog, while it was correctly on a new line with r31749).

I tested with 1.0_rc4_p20100506 (MPlayer r30554 with `mplayer -v`...), there is no problem at all. I note that there was apparently some changes with seeking, as when I seek with this version, with both ASS and SRT subtitles, the current subtitle is not shown (I have to go back to the time at which it starts showing, for it to show), while with 1.0_rc4_p20100612 and 9999, the current subtitle is properly shown. I thus suppose there has been some direct changes to subtitle handling between 1.0_rc4_p20100506 and 1.0_rc4_p20100612, which may have caused the problems we are seeing.

I know I should post these details upstream, but I don't have enough time, and will bear with it for now.

[Mathieu-aosekai (mathieu-aosekai)]

(Note that 1.0_rc4_p20100506 is apparently r31140, and 1.0_rc4_p20100612 is apparently r31371... I checked them out and did not find any difference with the two Gentoo tarballs... however, I strangely could not compile them with the mplayer-9999 ebuild after having added the revision after the repository URL using '@' -some compilation errors in "stream/stream.c"-, so I cannot test other revisions to find the problematic revision... I'll open a new bug report for the revision number problem in Gentoo ebuilds of MPlayer...)

[Overture2112 (overture2112)]

I'm also having these issues with mplayer svn r32025.

[Reimar Döffinger (reimar-doeffinger)]

Should be fixed by upstream SVN r32032.
And once again this would have been fixed faster if any of you had sent a proper bug report, in particular including a command line.
I am still completely unclear on who used the -ass commandline-option and who didn't. Since some people here talked about libass I assumed all issues were with -ass, but I can't reproduce any issue then.
If you weren't using -ass, libass is not used at all.

[Mathieu-aosekai (mathieu-aosekai)]

(In reply to comment #6)
> I am still completely unclear on who used the -ass
> commandline-option and who didn't. Since some people
> here talked about libass I assumed all issues were
> with -ass, but I can't reproduce any issue then.
>

I never used it "-ass", and it's not in my system/user configuration file. At first I talked about libass because I didn't think there was an internal version.

However, with mplayer-9999, "--disable-ass-internal" is used, so the external library is always used. Note updating to libass-0.9.11 didn't seem to change anything.

The problem being that with mplayer-9999, I cannot use "mplayer -ass x.mkv", as it says "Error parsing option on the command line: -ass". Without "-ass", with the latest 32032 revision (`mplayer -v`), I still get the same problems.

If I modify mplayer-9999 to use "--enable-ass-internal", or in fact, if I simply use mplayer-1.0_rc4_p20100612 (r31371), with "mplayer -ass x.mkv", it now uses embedded fonts/styles, and there is no problem with subtitles staying on screen, nor timings/labels being displayed...

If "mplayer -ass x.mkv" only switches to external libass, why the problem still appears when "--disable-ass-internal" is used (and why isn't there any use of embedded fonts/styles without "-ass"?)?

Sorry for the confusion, I'm just a simple MPlayer user.

Anyway, I will simply use "-ass" from now on, so as far as I'm concerned, there is no more problem. Thanks for the tip.

But there is still some problems with the basic rendering of ASS subtitle tracks. Maybe ass=yes should be added to /etc/mplayer/mplayer.conf, so other people, who don't know about "-ass", do not run into this problem, if it's ok to always activate it?

(For people reading this bug report, you can of course put it in ~/.mplayer/config instead).

(In reply to comment #6)
> And once again this would have been fixed faster if
> any of you had sent a proper bug report

I couldn't find any sample MKV video with an ASS subtitle tracks. If you don't mind downloading anime fansubs, you can test the original problem with "http://www.megaupload.com/?d=T4Y8KCZO".

At 00:00:20, "Why? We'll get things done faster if you meet her, too", the text stays on indefinitely with the first subtitle track, without using "-ass", even with r32032.

At 00:23:50, "I see. That might be a good idea. Dialogue: 0,0:23:50.35,0:23:51.05,Default-alt,Fuuko,0000,0000,0000,,Um...", timings/labels are displayed.

Again, no problem at all if I use "mplayer -ass x.mkv".

[Hanno Zysik (h.mth)]

o well, anyway, SVN trunk fixed my problems. both, subtitles that stay on screen that should not as well as the strange:

(comment #7)
> At 00:23:50, "I see. That might be a good idea. Dialogue:
> 0,0:23:50.35,0:23:51.05,Default-alt,Fuuko,0000,0000,0000,,Um...",
> timings/labels are displayed.
>
> Again, no problem at all if I use "mplayer -ass x.mkv".

I do not use the '-ass' cli option nor 'ass=yes' in the configuration file.

so, thanks! ;)

[Reimar Döffinger (reimar-doeffinger)]

Do I understand you correctly that you confirm there is no issue in the latest upstream version anymore (whether you use -ass or not)?
Also to clarify: libass is only used for styles etc. rendering. So if you do not use the -ass command line option (not the use flag, that's something else entirely), libass is not used in any way, neither internal nor external.
And I don't blame anyone for not knowing these things, I just want to make sure you know that such seemingly irrelevant things like copy-and-pasting the exact command used and its output can and often are essential for resolving issues quickly!

[Hanno Zysik (h.mth)]

(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)?

Yes, as well as 'ass=yes' in configuration file does work.

> And I don't blame anyone for not knowing these things, I just want to make sure
> you know that such seemingly irrelevant things like copy-and-pasting the exact
> command used and its output can and often are essential for resolving issues
> quickly!

Well, they are default ones here, but for video out and xineramascreen, which seemed quite unrelated. :)

With this I am out of this and the bugreport may be closed as fixed upstream.

Well, feel free to discuss other issues here or in a new bugreport since this initial bugreport is fixed.

[Mathieu-aosekai (mathieu-aosekai)]

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

[Reimar Döffinger (reimar-doeffinger)]

Ok, let me summarize the latest SVN status: Everything should work again for SRT subtitles in MKV. For ASS subtitles in MKV you have to either use the -ass option or -demuxer mkv to avoid this issue.
I hope the latter issue will be fixed soonish as well, but it will take some time since I need to discuss with the libavformat demuxer maintainer first.

[Guido-genbugs (guido-genbugs)]

The bug is still present exactly as described in media-video/mplayer-1.0_rc4_p20101219 and media-video/mplayer-1.0_rc4_p20101114.

[Rlucca (rlucca)]

I have this bug in media-video/mplayer-1.0_rc4_p20101114 too.
But mplayer works fine when informed '-ass'.

[Hanno Zysik (h.mth)]

What about version 20110322? If there is no reply, I will close this. Cleaning my bugreports.