[MPlayer-dev-eng] [PATCH] A new ASS renderer

[wm4]

On Sun, 23 Sep 2012 15:30:54 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> I disagree. Only libass can e.g. look ahead and pool glyphs by how
> often they will be used in the future just as an example.
> It also can speed up libass itself by reducing allocations/frees if it
> pools the glyphs.

libass does cache glyphs. Actually, you could say libass is one big
cache: libass parses/layouts/renders subtitle events every frame again.
But it's fast, because expensive operations (rendering fonts to
bitmaps) are cached.

libass provides minimal change detection to mplayer, and returns
whether the frame has not changed. libass implements this by comparing
the new image list with the previous one. Now, if a rasterizer like
vf_ass wants to have fine grained information about which sub-images
have changed from the previous frame, libass could in theory export
this information. All what's needed is there internally; it just needs
an interface for that. For example, it could assign every sub-image a
unique ID, so that vf_ass knows what exactly has been moved/reused, and
so on.

But I think in conclusion, all of this is relatively worthless. Even
with very complicated subtitles, the time spent in the freetype
renderer is much higher than that in vf_ass or on the GPU.

> Only libass can e.g. look ahead

You could easily request a frame from the future from libass, provided
libass has received all necessary subtitle packets. The rendering
interface takes a time value.