search for: libtiger

Hi, This is an updated patch, replacing the previous one. It allows rendering Kate streams using libtiger (itself using Pango and Cairo). It allows video to be converted to RGB, and overlaying of a Kate stream onto a video. While there, there are various fixes/tweaks (the asm versions of the YUV to RGB converters would move the data pointer, so anyone using those at a later time would access bad memor...

Hi ogg.k ogg.k, some drive by comments on the patch from a quick look. Should these be wrapped in HAVE_KATE? Same with the definition of the functions on oggplay.c? If I'm not building with Kate support it would prevent dead code from being around. -----------------8<--------------------------- OggPlayErrorCode oggplay_get_kate_category(OggPlay *me, int track, const char** category);

> Should these be wrapped in HAVE_KATE? Same with the definition of the > functions on oggplay.c? If I'm not building with Kate support it would > prevent dead code from being around. They could, but would change the API, and the implementation just returns a "not implemented" error currently if HAVE_KATE is undefined, (and a couple checks for validity) so it's not much

Hi, the attached patch adds rendering of Kate streams using libtiger. To do so, it adds a new type of RGBA video. One can request the incoming video (in YUV) to be sent in RGBA (ie, asking liboggplay to do the conversion in the first place). The large changes in the GLUT player also include fixes for crash-on-no-sound, mono sound, and locking fixes (I *think* - at...

...nd expose the render of this, which the client can then overlay onto the video. I've done that, and it works (modulo bugs). However, it's slow, both because of the two renders (once to render the overlay in liboggplay, the second to overlay it onto the video in the client code), and because libtiger (my rendering lib) only draws what's needed, whereas liboggplay exposes a full size buffer (would need at least a bounding rectangle). Another solution would be to let liboggplay overlay Kate tracks onto the video directly - but this would seem contrary to the design, where each track feeds da...

> 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,

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...

I think libkate should be able to render in the yuv colour space. A 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. 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 l...