Opened 9 years ago

Last modified 9 years ago

#1801 new defect

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

Reported by: h.mth@… Owned by: reimar
Priority: normal Component: vo
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

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

Attachments (3)

mplayer_vdpau-hack.diff (9.1 KB) - added by h.mth@… 9 years ago.
vdpau eosd efficiency hack
mplayer_vdpau-surface.diff (8.5 KB) - added by h.mth@… 9 years ago.
use only one surface
mplayer_vdpau-surface.2.diff (10.1 KB) - added by h.mth@… 9 years ago.
generate only a few vdpau bitmap surfaces

Download all attachments as: .zip

Change History (17)

comment:1 Changed 9 years ago by 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. :)

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by h.mth@…

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

comment:4 Changed 9 years ago by 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

comment:5 Changed 9 years ago by 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.

Changed 9 years ago by h.mth@…

vdpau eosd efficiency hack

comment:6 Changed 9 years ago by h.mth@…

comment:7 Changed 9 years ago by 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. :)

Changed 9 years ago by h.mth@…

use only one surface

comment:8 Changed 9 years ago by 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. :(

comment:9 Changed 9 years ago by 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).

comment:10 Changed 9 years ago by 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. ;)

comment:11 Changed 9 years ago by 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).

comment:12 Changed 9 years ago by 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.

Changed 9 years ago by h.mth@…

generate only a few vdpau bitmap surfaces

comment:13 Changed 9 years ago by h.mth@…

  • attachments.isobsolete changed from 0 to 1, 1

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

comment:14 Changed 9 years ago by h.mth@…

  • attachments.description changed from generate only few a few vdpau bitmap surfaces to generate only a few vdpau bitmap surfaces
Note: See TracTickets for help on using tickets.