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

[Xidorn Quan]

On Sun, Sep 23, 2012 at 4:18 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> On Sat, Sep 22, 2012 at 09:05:19PM +0200, Clément Bœsch wrote:
> > On Sat, Sep 22, 2012 at 09:01:40PM +0200, Reimar Döffinger wrote:
> > > On Sat, Sep 22, 2012 at 08:02:36PM +0800, Xidorn Quan wrote:
> > > > The patch attached is a new ASS renderer which is optimized for
> > > > subtitles with few effects. For me, this new renderer is nearly
> > > > 2x faster on average than the current one for those subtitles.
> > > >
> > > > I found that most subtitles keep unchanged across several frames,
> > > > while vf_ass renders them over and over again for every images in it.
> > > >
> > > > This new renderer renders that images to one image with alpha channal
> > > > when subtitle changes, then it simply does pixel weighted addition
> for
> > > > new frame and the image. The second step is very fast, cache-friendly
> > > > and easy to be further optimized, for example, by using SIMD.
> > > >
> > > > In this patch, I moved get_image, blank, and prepare_image from
> > > > vf_ass.c to ass_common.c and color converting macros to ass_common.h
> > > > so that I can reuse them in vf_ass2.
> > > >
> > > > To use this new renderer, just add "-vf ass2" to the comand line.
> > >
> > > I strongly dislike both having and having to maintain two solutions
> > > to the same problem.
> > > One solution would be to switch between the methods based on some
> > > heuristics from e.g. the previous frames.
> > > I also kind of wonder what the use case is, where does ASS rendering
> > > speed make a relevant difference (while also none of the
> > > hardware-accelerated implementations are used)?
> >
> > I'd unfortunately say that ASS performance is relevant when rendering
> > complex karaoke or stuff like that, where the subtitles change all the
> > time.
>
> Maybe, but the filter will not (at least not by default) be used if you
> use any of gl, vdpau, direct3d drivers.
> While the others still have their uses in some cases, I wouldn't exactly
> recommend them any more for general use.
> If this is just an optimization "because it can be done better" that is
> of course still a good reason, but if the purpose is to solve a
> real-world problem I'd like to understand it.
>

Well, I found that the ASS processing in vo_gl is actually a lite
version. It didn't seem to process ASS effects, did it?

Yes this is just an optimization, which do exactly the same things
with the current one but speed the work up for some cases.