Displaying 8 results from an estimated 8 matches for "libtig".
Did you mean:
littig
2008 Sep 22
0
[PATCH] liboggplay: RGB/RGBA video, and rendering Kate streams with 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 mem...
2008 Dec 16
0
liboggplay: RGBA overlay video, rendering with libtiger
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);
2008 Dec 16
1
liboggplay: RGBA overlay video, rendering with libtiger
> 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
2008 Dec 15
3
liboggplay: RGBA overlay video, rendering with libtiger
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* - a...
2008 Aug 18
3
liboggplay and overlay video
...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...
2008 Aug 20
2
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,
2008 Aug 25
0
liboggplay and overlay video
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'...
2008 Aug 18
0
liboggplay and overlay video
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...