ogg dev - Aug 2008 - liboggplay and overlay video

> fancy with unions, but since RGB/RGBA is generally chunked and YUV is
> generally planar, having two separate types makes more sense. There's
OK
> typedef struct {
>   unsigned char *data; /* may be RGB or RGBA */
>   unsigned char *mask; /* may be NULL if RGBA */
> } OggPlayVideoRGBData;
That's what I have at the moment - two types and something like
the above, except that :

typedef struct {
  unsigned char *rgb; /* may be NULL if alpha */
  unsigned char *rgba; /* may be NULL if no alpha */
} OggPlayOverlayData;

(I think it's probably faster to keep RGBA in one plane, so memcpy
works if needed, etc, though no hard numbers to back it up).

If I go this way, I think the question of whether the API is supposed
to be not changed is moot, so it's all good.

Cheers

Here's the current state of the changes (not meant to apply yet, but
more or less there in terms of functionality). Comments welcome.

New APIs to request conversion from YUV, use libtiger to render,
and overlay a Kate stream to a video.

It obviously requires libtiger and libkate for the Kate specific stuff:
http://libkate.googlecode.com/
http://libtiger.googlecode.com/

Something which I'm not sure about is RGB/BGR issues. These are
always a pain. Also speed issues, as it's all plain C, but since the
current case (piping YUV out) doesn't change, it doesn't really
matter now.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liboggplay-with-tiger.diff
Type: text/x-patch
Size: 35024 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080825/266a5579/attachment-0001.bin

> Here's the current state of the changes (not meant to apply yet, but
> more or less there in terms of functionality). Comments welcome.
No comments, so I assume there is no opposition to the way the
RGB format is handled ?
I'll finish/clean this off this weekend if so.