[ogg-dev] liboggplay and overlay video

ogg.k.ogg.k at googlemail.com ogg.k.ogg.k at googlemail.com
Mon Aug 18 10:00:23 PDT 2008

> I think libkate should be able to render in the yuv colour space. A

I thought of that a while ago, but there are various problems that would
crop up and need some kind of solution.

I use Cairo and Pango for rendering, and these use RGBA. I do not
think (though this isn't based on experimentation) that passing in YUV
colors in RGB values would work well. Additionally, YUV typically uses
downsampled UV, another thing which would not play nicely with Cairo
and Pango.

I briefly added YUV palettes to kate_palette, but reverted due to those.
Besides, I'd need YUVA, which is less commonly found. Also, alpha
doesn't usually play nice with subsampled planes as colors tend to
bleed (or so I hear).

Which brings me to an interesting idea I had: instead of placing bitmaps
(or text) in regions, I could have placed a Theora video - YUV. Since
the mapping for this is already done and the streams muxed in, it could
be quite easy to not render the videos, but for libtiger to pull the images
so they could have all the xforms that kate regions can have.

To make this really useful, I'd need to actually get around to implementing
continuations though (essentially adding to an event's motions from data
in subsequent packets), and this has been moved to the back burner. But
you could manipulate videos in 2D, switching them on and off, etc.

Anyway, I do ramble.

> lot of players use hardware accelerated colour space conversion and
> scaling, so in addition to your point about saving unneccesary
> conversions, they are likely to be able to offload the compositing
> step as well. This means that libtiger should also be able to do the
> compositing in yuv.

Yes, I did not really think of hardware acceleration here.

> I think adding an RGB/RGBA frame type to liboggplay should *also*
> happen. yuv2rgb is tedious at best and hard to get right at worst, so
> being able to get frames (even theora frames) in sRGB is something I
> think we should provide. Many 2D graphics libraries handle alpha
> compositing, but only in RGB space; anyone using one of those for
> overlay would want this.

oggplay_yuv2rgb is a testament to this :)

Which makes me remember - I had to #if 0 the MMX/SSE/etc code in
liboggplay, it didn't build for me i686-pc-linux-gnu, x86_64-pc-linux-gnu.
I could send the (pages of) errors, this had slipped my mind.


More information about the ogg-dev mailing list