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

[Nicolas George]

Le quartidi 4 fructidor, an CCXIV, Uoti Urpala a écrit :
> So this format is something you made up just now, and which is not
> currently used anywhere?

Alas, yes. I am not aware of an existing syntax for similar tags. The best
solution would have been the animate features of SVG, but none of the
libraries I tried implements it, and these features are too complex for me
to implement them as part of this vf_svg project.

> +    return(0);
> 
> Return is not a function, you don't need parentheses there.

I know; I picked up that habit a long time ago, and I find it slightly more
consistent, so I keep it as part of my coding style.

> +    unsigned *od, *od2; /* FIXME: Cairo documentation is not very accurate
> +			   on the actual memory layout of its data, but
> +			   unsigned is the type it internally use. */
> 
> +    od = (unsigned *)cairo_image_surface_get_data(s);
> 
> The cast is useless since that's the type of the variable it's being
> assigned to. However whether it's really the right type seems
> questionable - the cairo.h on my system has
> unsigned char * cairo_image_surface_get_data(cairo_surface_t *surface);

That is really an issue of Cairo API: the returned data is partially
intended to be used as char * (for example, the stride values is in char),
and partially intended to be used as "32-bit quantity". Which makes little
sense with regard to the C standard; the most likely interpretation is that
it is a pointer to an array of uint32_t cast to a pointer to char. I
actually used unsigned instead of uint32_t because it is what actually is
used in Cairo source code; still, it should be exactly the same on all
architectures Cairo is running.

Life would have been easier with CAIRO_FORMAT_A8, but I did not feel like
dropping the color.

> Requiring conversion to RGB will hurt performance in most cases, as most
> video codecs produce YUV and xv can display that without conversion.

Yes, I am aware of that. Unfortunately, Cairo only handles RGB surfaces. At
first, I had Cairo directly draw on the mp_image_t, which only works for
little-endian, but is quite simpler to write.

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.

Of course, the best solution would be if Cairo had support for YUV
colorspaces, and conversion took place only when changing the brush color.
But it is not possible yet.

Thanks for these remarks.


Le quartidi 4 fructidor, an CCXIV, Richard S. a écrit :
> Hi, if you are interested in using SVG for subtitles, MPEG 4 could be
> interesting in the next time.
<snip>

That is indeed very interesting.

Unfortunately, it seems to be a long way before these features are available
in MPlayer or any everyday video player, doesn't it?

My vf_svg, on the other hand, is much more limited, but it actually works
with today's mplayer fresh from SVN. I dare say it makes one point for it.


By the way, I forgot to ask in my first mail: what are the fonts in the
MPlayer logo?


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/20060821/ee7acbc1/attachment.pgp>