[MPlayer-dev-eng] [PATCH] SVG overlay

[Nicolas George]

Le quartidi 4 fructidor, an CCXIV, Nicolas George a écrit :
> Now that I use an intermediary overlay buffer, it would probably best to
> convert it to YUV instead of converting the image I apply it on to RGB.
> Unfortunately, none of MPlayer's builtin converters is likely to handle
> Cairo image format, so I will have to write my own, which will not use MMX
> or SSE.
> 
> But that is definitely something I intend to try in order to improve speed.

I implemented that, and did some benchmarks, and the result is both
satisfactory and unsatisfactory.

The updated patch is available there:

http://www.eleves.ens.fr/home/george/info/prg/mplayer-svg/
http://www.eleves.ens.fr/home/george/info/prg/mplayer-svg/mplayer-svg-20060825.diff

I added documentation, and a srt2svg script.

Now the benchmark results. There are two operations that must be timed
separately: the applying of the overlay, which must be done for each frame,
and the preparation of the overlay, which must be done when the overlay
changes.

With a prepared overlay in the RGB colorspace, the preparing of the overlay
is extremely variable, depending on the overlay complexity; I saw times from
15% to 200% (of the mean frame rendering time) overhead. The applying of the
overlay gives a 200% overhead.

With direct drawing in the MPlayer image, the preparing of the overlay is
quite cheap, and the applying costs between 135% and 300%, depending on the
overlay complexity.

With a prepared overlay in the YUV12 colorspace, the applying of the overlay
is quite cheap, no more than 25% overhead. But the preparing is very
expensive, between 540% and more than 700%.

Since reasonable overlays will probably change less than once every ten
frame on the average, this is globally better. But, with the current design,
the preparing must be done in the time between two frames. I had in mind an
option to do the preparing in advance in a separate thread: in that case we
get the 25%- overhead of applying the overlay, and the preparing averaged on
a long period of time.


Yet, I believe that the patch as is is already quite usable, with small
enough videos and/or powerful enough hardware. I would like to know if there
is possibility for it to be included. Since it is only one more video
filter, it is very unlikely it would break anything.


Le quartidi 4 fructidor, an CCXIV, 陆然 a écrit :
> Maybe this is the reason why the variable parts does not work:
> 
> http://svn.mplayerhq.hu/mplayer/trunk/mencoder.c?r1=18336&r2=18418
> 
> The change was made for the pre8 release, but never reversed.

Yes, that looks exactly like it. That means I did nothing wrong on that
account at least. Thanks.


Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060825/f5239b01/attachment.pgp>