similar to: [PATCH] liboggplay: RGB/RGBA video, and rendering Kate streams 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* - at least it works fine for me

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

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

Hi, I've eventually released the first version of my rendering library for Kate streams, and I've recently been hacking away at adding it to liboggplay. That was the missing "overlay" mode to the browser_plugin patch I sent a while ago. Now, I'm not too sure how to expose those overlays to liboggplay users: the obvious solution is to add a RGBA video type, and expose the

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

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

On 21/04/2008, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > Hi, > > I've added kate support to liboggplay (a prerequisite to getting kate tracks > to work with the mozilla plugin, which I've now got working on Linux). > great! > In addition to the Kate code: > > - a new oggplay-uninstalled.pc file configure.ac:366: required

> There seems to be some inconsistency in the changes to the type of > sample_in_record and its accessor: the field was changed from int to > ogg_int64_t in src/liboggplay/oggplay_callback_info.h, and the return > type of the accessor function was changed from int to long in the > corresponding .c file and public header. Having heard no more about this, I'll make a patch that

2008/4/22 Conrad Parker <conrad at metadecks.org>: > sorry, my bad -- recent releases have been coming out of > http://svn.annodex.net/libfishsound/branches/1.0-stable > The latest version is 0.9.1. > > trunk is mostly up-to-date with that, and has some extra, incomplete, stuff. As this was confusing, I've renamed the libfishsound branches to what anyone would expect:

> I think you forgot to include oggplay-uninstalled.pc.in in the patch :-) Attached, plus the oggplay.pc.in as well, as I added @KATE_CFLAGS@ to both. Also attached is a patch to avoid miscounting the number of active tracks (a bug in my previous patch), and the current patch to the mozilla plugin (still work in progress, the Javascript API will change a little) if anyone feels like

2008/4/23 ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com>: > > I think you forgot to include oggplay-uninstalled.pc.in in the patch :-) > > Attached, plus the oggplay.pc.in as well, as I added @KATE_CFLAGS@ > to both. > Also attached is a patch to avoid miscounting the number of active tracks > (a bug in my previous patch), thanks, applied in

Hi, I've added kate support to liboggplay (a prerequisite to getting kate tracks to work with the mozilla plugin, which I've now got working on Linux). In addition to the Kate code: - a new oggplay-uninstalled.pc file - configure.ac checks for C++ compiler - no check for fishsound version - it wanted 0.8.0, but the svn itself was 0.7.1 !? - don't use imlib2 (nor dump-first-frame) if

Hey, ::: I'm sending a patch for liboggplay for comments. It adds - runtime cpu extension detection - fixed mmx implementation - added sse2 yuv to rgb conversion - added a faster vanilla implementation ::: currently it works fine on unix systems, the MSVC implementation needs a bit of a hacking, but basically you get the concept of the refactoring. If you have any

> 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 I'd added an RGBA type, but if this is going to also carry video, it might be better to merge this with the existing video type, and have a 'type' enum, or just several pointers, only one set being non NULL (makes client code simpler). Would

On Wed, Aug 20, 2008 at 2:27 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > I'd added an RGBA type, but if this is going to also carry video, > it might be better to merge this with the existing video type, and > have a 'type' enum, Right now, OggPlayVideoData is just a struct with three arbitrarily named pointers; it doesn't even know

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

Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: > On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >>> >>> In case anyone's curious about 30bpp framebuffer support, here's the >>> current status: >>> >>>

On 02/05/2018 12:50 AM, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > >

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner <mario.kleiner.de at gmail.com> wrote: > On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >> >> In case anyone's curious about 30bpp framebuffer support, here's the >> current status: >> >> Kernel: >> >> Ben and I have switched the code to using a 256-based LUT for Kepler+, >> and I've also