[MPlayer-users] ssa/ass rendering uses lots of cpu with -vo gl

[Vladimir Mosgalin]

Hello everybody.

I just noticed some strange thing; rendering .ass with effects consumes
insane amount of processing power with -vo gl target (i'm using -vo
gl:yuv=2, but any -vo gl mode has problems)

I'm talking about fansubbed anime, which uses karaoke effects in
opening. 1920x1080 resolution, this file was unplayable in some moments
on my older Core 2 Duo 3.6 Ghz system with -vo gl, but was completely
playable with -vo xv

I see this either as bug in mplayer (maybe in -vo gl, or eosd, or ass
filter, i don't know), or maybe problem with video driver or mesa, let
me explain why.

Trying this file on twice more powerful Core i5 with -vo xv, I get
numbers when playing with subtitles turned off
A:  20.9 V:  20.9 A-V:  0.000 ct:  0.042   0/  0 31%  3%  6.5% 0 0 32% 
when turning on subtitles (displaying english/japanese karaoke)
A:  21.0 V:  21.0 A-V:  0.000 ct:  0.042   0/  0 30%  8%  5.7% 0 0 32% 
So, subtitle rendering took 5% more CPU, fine.

Now with -vo gl:yuv=2
A:  19.8 V:  19.8 A-V:  0.002 ct:  0.041   0/  0 29%  5%  5.5% 0 0 31% 
with subtitles
A:  25.3 V:  25.3 A-V:  0.000 ct:  0.042   0/  0 28% 22%  4.7% 0 0 31% 
That's 17% cpu usage increase when rendering subtiles. This made this
file unplayable on my older system.


Now, I know that gl offers high quality subtitle rendering by doing it
at high resolution disregard video resolution, and it must consume more
CPU - but here, we are talking about 1080p video, subtitles look exactly
as sharp with -vo xv, and obviously -vo xv renders them at high
resolution too, and this shouldn't explain such huge differences in
resource usage.

Video card: radeon 4870,
xorg ati driver 6.13.1-0.3.20100705git37b348059, Mesa 7.9, kernel 2.6.37
with DRM "radeon 2.7.0 20080528", Fedora 14 system, latest svn mplayer.

I can give link to .torrent with that file or upload opening (~300 mb)
or .ass subtitle file that's used, if it's needed. For starters,
however, I'd like to check if there is really some bug causing very high
cpu usage, or it's expected from -vo gl.

-- 

Vladimir