vdpau: eosd: subtitle characters are white block sometimes with MKV videos

[h.mth@…]

Example: $ mplayer -xineramascreen 1 k-on/\[Frostii\]_K-On\!\!_-_06_\[EF7D2B0B\].mkv

From: ​http://frostii.com/tracker/torrents/%5BFrostii%5D_K-On!!_-_06_%5BEF7D2B0B%5D.mkv.torrent

...
[vdpau] EOSD: error when creating surface: The system does not have enough resources to complete the requested operation at this time.
[vdpau] EOSD: putbits failed: An invalid handle value was provided.
[vdpau] EOSD: error when creating surface: The system does not have enough resources to complete the requested operation at this time.
[vdpau] EOSD: putbits failed: An invalid handle value was provided.
[vdpau] EOSD: error when creating surface: The system does not have enough resources to complete the requested operation at this time.
[vdpau] EOSD: putbits failed: An invalid handle value was provided.
[vdpau] EOSD: error when creating surface: The system does not have enough resources to complete the requested operation at this time.
[vdpau] EOSD: putbits failed: An invalid handle value was provided.
...

No idea what component to put this. vo or libass, or ...

[h.mth@…]

Well, to be honest, when that white blocks appear, the whole playback seems to stop for a blink of an eye, sometimes.

So it could be the nvidia-driver, vdpau library or something in mplayer.
I updated the nvidia-driver and vdpau library recently, so ...

I just keep an eye on it. :)

[reimar]

You are probably running out of memory on your graphics card.
VDPAU on its own needs a lot of memory, and ass rendering is implemented suboptimal, plus NVidia always had some trouble handling memory fragmentation.

[h.mth@…]

Just for reference,
the grafics card is an Asus EN210 G/DI LP ( GeForce 210, 512mb ram )

[h.mth@…]

Even resetting pixmap and glyph cache by

'nvidia-settings -a PixmapCache=0 -a GlyphCache=0'

shows no difference. VDPAU has an interesting memory management.

( Yes, this is the infamous error 23. )

nvidia-driver version: 260.19.06
vdpau library version: 0.4.1

[h.mth@…]

Okay, the efficiency patch from
​http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-February/060640.html

helps. No more white blocks on a quick look. Though, now there are spurious, but harmless, errors like:

[h264_vdpau @ 0x7f37bbd2e3c0]mmco: unref short failure

Since this hack helps more than it breaks I add a patch that applies to trunk.
Just in case someone else has this and wants to have the glyphs shown.

This patch is not meant for inclusion into mplayer in any way.

[h.mth@…]

vdpau eosd efficiency hack

[h.mth@…]

What I wonder about is why there is a surface for each glyph created. Why not just create one and write all glyphs into that?

I hacked a bit the generate_eosd function, got all glyphs shown in one surface but the black borders of the characters are missing. And the other side-effect for now is that the subtitles stay until new ones appear. Well, I guess that can be identified.

Is that approach with one surface just wrong?
Like wrt the borders of the characters missing.

This way I have no out-of-memory problem either. :)

[h.mth@…]

use only one surface

[h.mth@…]

Well, this patch has a minimum of changes to create only one surface.
So, this patch could take quite a good cleanup.

The problem with this is that the vdp_bitmap_surface_putbits_native function overwrites the pixel value that is already in the surface with the new bitmap data.

And this hurts only if the new value is plain alpha, erasing "more important" data already in surface.

I wonder if this behaviour could be changed to ignore plain alpha values.
Otherwise I guess bad luck. :(

[reimar]

Is that approach with one surface just wrong?

No, but your approach fails completely in far, far too many corner cases.
See vo_gl.c:genEOSD for a method that is well tested and should never be significantly worse.
Note that only a patch that avoids duplicating code as far as reasonable will be accepted.
Also not that performance-wise, drawing all parts that are using the same surface/texture in one bunch would be better, I just didn't have the motivation yet (on desktop GPUs it is fast enough either way, and I don't have access to an embedded GPU).

[h.mth@…]

That is why I said that that patch was with a minimum of changes. It surely is nothing but raw. But it works(no crash, no obvious memory leak) so far.

The gl code pushes each glyph in a texture to the graphics card.
Doing so with a bitmap surface for each glyph in vdpau ends in this failure.

I only see that one cannot stress vdpau with that many(although that are not that many) bitmap surfaces which ends here.

Therefore I will try another way to manage one or a handful surface(s) since plain alpha bits overwrite data. And only as many targets as necessary.
The code will not be worse than what is in already. Just different, yes.

Sad, that one cannot use the bitmap surface of vdpau with more than one bitmap per region.

Well, some aid would be cool to get something in but feel free to ignore it. ;)

[reimar]

The gl code pushes each glyph in a texture to the graphics card.

No it doesn't. It only falls back to this if there are too many or too large glyphs (in which case AFAICT your patch just seems to fail completely).

[h.mth@…]

vdpau eosd failed before, too. Simply pushed through but surface and putbits checks. I did not change that logic. No check for invalid width, height nor stride. And I am happy to get any failing (corner) case to debug and fix.

Well, good news: with a little change I got it working. :)
Now to some design ideas and cleanup work.

[h.mth@…]

generate only a few vdpau bitmap surfaces

[h.mth@…]

This patch:

• adds a basic 'invalid glyph' check
• manages far less vdpau bitmap surfaces
• utilizes the maximum width of a vdpau bitmap surface to store as many glyphs as possible
• only if the maximum width of a vdpau bitmap surface is reached a new surface is created
• generates only as many glyph targets as glyphs are actually used
• fixes the 'white block' problem by relaxing the vdpau bitmap surface creation/destruction stress (error 23 simply misleads)

Well, this is an alternative approach to manage glyphs with vdpau. :)

There may be room for improvements ...