[MPlayer-users] ass subtitles, vo gl and amd video

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Sep 24 23:54:24 CEST 2013


On Tue, Sep 24, 2013 at 11:33:38PM +0200, wm4 wrote:
> On Tue, 24 Sep 2013 23:12:55 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > Not sure if I might have made some stupid mistakes, so testing
> > would be good before I try to get it upstream.
> 
> Looks like it could be correct. Is the calloc() still needed? It looks
> like the loop writes all of the nbuffer image now.

It doesn't write everything, since the I kept the stride
(I am not sure about stride requirements, so that seemed safest).
While in theory nothing should use it, it seemed better to
initialise it anyway...

> > For -vo gl it seems to "only" about double the speed, which
> > isn't really good enough.
> 
> With these things, the gaussian blur is usually what slows it down
> most, though I didn't check in this case.

I didn't check with -vf ass properly, so not sure.
With -vo gl it is clearly driver issues, drawing 1000s of objects
using the old API is too costly with non-NVidia drivers.
Btw. we also end up with quite a few 0-sized bitmaps, I think
libass should be throwing away those.
(with -v the cause -vo gl to print loads of "Invalid dimensions OSD for
part!")

> Compared to xy-vsfilter, it's
> inefficient because it blurs each glyph individually instead of whole
> glyph runs, but also because the blur implementation is plain
> inefficient. The first issue is a bit hard to fix (although there's
> someone who wanted to write a patch for it),

Yes, I seem to remember that. It would probably fix the -vo gl issues
for most cases. I don't have high hopes on someone actually doing it
though.

> but the second issue just
> needs someone who is enthusiastic about optimizing gaussian blur.

Not the bottleneck for the cases people complain to me about :-)


More information about the MPlayer-users mailing list