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

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2011.01.26 at 22:03:33 +0100, Reimar Döffinger wrote next:

> Depends on what you mean. If you mean a texture of the same size as the
> image: in principle that's possible but it has issues like huge
> GPU memory usage, problems with rendering of overlapped parts, probably
> higher CPU usage for simpler things and it simply can't work with PCI
> video cards (at 1080p the current OSD needs maybe 60 MB/s bandwidth,
> whereas that approach would need almost 200 MB/s which without video
> is already more than PCI can do).
> -vo direct3d does it that way if I remember right.
> A similar but better-working approach is what I mention as libass merging
> glyphs, but it is even more effort to implement.
> 
> > (I know i'm a bit shooting at random here, sorry :). By the way I'm
> > using open source radeon driver, even though it lacks behind fglrx in
> > performance greatly, it has much less issues and problems, I'd rather
> > use this "slow" driver than go back to fglrx one)
> 
> I don't think it has worse performance for this use-case.
> It actually has the advantage it could be optimized to also work nicely
> for this kind of workload if someone cared enough.

Reimar, do you remember this conversation about problem with rendering
ssa/ass subtitles and -vo gl? I wondered if you could think about it
once again, because what I'm experiencing right now is somewhat puzzling
(and annoying, though it's less of a problem). Maybe you'll be able to
make something out of this information which could help in fixing this
problem? Because maybe something else plays factor here, like for
example some strangeness in system configuration on my side.

It's about how rendering ssa subtitles slows down -vo gl output.
Before, I gave examples on rendering 1080p video with karaoke effect.
But right now, it's so bad, it slows down even very fast cpu to jerky
video and frame drops on 480p video without any karaoke. Also I
experienced this on 720p video, where just extra line of subtitles
(normal, without any effects) slows down system so much so it can't
render frames at proper rate.

The system in question has very fast CPU, Core i5-2500K, 4 cores at 4.3
Ghz. Video card is Radeon X1900 - while it's definitely an old video
card, it's not weak by any means. From specification, it got PCI-E 16x
interface, 256 bit memory bus w/GDDR4 memory and 46 GB/s bandwith, 10
Gpixles/s and 10 Gtexles/s fillrate. Changing video card from Radeon
X4000 series to this made watching videos in fullscreen quite painful,
and I just can't understand the reason, no matter how I look at specs,
this card should be more than enough for any kind of tricky buffers
copying and such.

System is Fedora 14, with kernel 2.6.38.2 (stock kernel had problems
with supporting onboard ethernet controller).
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on R580
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20

According to kernel, "radeon 2.8.0 20080528" drm is used, Mesa version
is 7.9. Compared to other radeon card which had much less problem, this
one uses "Gallium" driver - I don't know what difference it would make
(though according to phoronix.com reviews, it can make difference on
card/driver performance); though, even R600 and higher cards will be
using Gallium soon (for example, in Fedora it'll happen starting with
Fedora 15).

So, with change card and different driver system started to behave very
poorly. For example: 720p release of Koihime Mousou (h264), there are usually
subtitles on the bottom, but at times there are comments in subtitles on
top. When there are only subtitles on bottom, it works fine, but at the
moment subtitles on top appear, panning scenes become visibly slowed
down for the time when subtitles are rendered - and right as subtitles
at top disappear, panning and whatever is displayed at that point in
video becomes very fast to "compensate" for that slowdown. Turning on
framedrops helps a bit but not completely, while it often reduces this,
some jerkness is still visible, and mplayers prints "YOUR SYSTEM IS TOO
SLOW" warnings from time to time. (and, if it's only a rendering
problem, not decoding, I would've expected framedropping mode to help..)

When playing that without filtering, mplayer has only about 20% cpu
usage in fullscreen when no subtitles are rendered, having subtitles on
bottom can make it 30-50% load, and having subtitles both on top and
bottom makes >100% load and framedrops.

Now what's so funny about this - if mplayer plays this video in window,
load is like 15% without subtitles and no more than 20% even when having
subtitles both on top and bottom. And I mean playing in same resolution
as in fullscreen, i.e. resizing window, or using -xy or other means to
make graphics card render at same resolution as it would've rendered in
fullscreen.

Example of these subtitles (first lines) are here:
http://pastebin.com/yNfvsYQ9

the very last line, 48, shows added subtitle on top which slows whole
thing beyond imagination - but only in fullscreen.


Also looks like this problem doesn't even require rendering HD video or
top+bottom subtitles - for example, in 480p rip of Rozen Maiden during
this line (and many others)

Dialogue: 0,0:18:32.47,0:18:36.68,RozenDefault,,0000,0000,0000,,you are able to see and hear many more things than when you are asleep.

where RozenDefault is
Style: RozenDefault,OldStyle 1 HPLHS,34,&H00CFEFFF,&H00000000,&H0023235D,&H00000000,1,0,0,0,100,115,0,0,1,2,1,2,10,10,10,0

it's enough to make panning ultra slow, with framedrops and >100% cpu
usage. Rendering in window, even of maximum size, never gets CPU above
20%. I'm playing without any filtering, once again. Other mplayer
options, including multi-thread decoding, seem to make no difference.
While it's all more noticeable on panning, framedrops also happen on
low-motion scenes, just not noticeable.


As a side note, I tried your suggestion from other mail, about
sharpening filter of -vo gl instead of unsharp. Results are quite
pleasing, though there are some caveats. First, its filter-strength
works a bit differently, for example unsharp=l3x3:1 is about equivalent
of lscale=4:filter-strength=1.2 or 1.3, hard to tell exactly as pictures
look a bit different. Second, there is (naturally) a caveat of having
sharpening to be last thing done to picture, for example I always use
noise filter to make subtle unnoticeable noise to picture which masks
some problems nicely without affecting any details, for example
noise=10uah:5uah.  But it's done after unsharp filter; if using gl
sharpening, this kind of noise becomes noticable and annoying, so I have
to reduce numbers, having noise=5uah:5uah. (I don't use chroma
sharpening because I don't see any positive effects from it).


-- 

Vladimir