similar to: [PATCH] liboggplay - kate support, build fixes, and misc

> 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

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

> 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

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

2008/4/30 ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com>: > > > Let me know if this works for you or not; eg. it may be necessary to > > > also put X_EXTRA_LIBS etc. in src/Makefile.am. > > > > will try this. > > It worked fine for me, with no need to add anything to Makefile.am. > good > > > > - bad pointer

where is the latest javascript api documented? it does not look like http://wiki.xiph.org/index.php/OggPlayJavascriptAPI has been updated recently. I had trouble getting oggplay to run at all on my machine ubuntu (7.10) But I would be interested in revisiting the issue... --michael Conrad Parker wrote: > 2008/5/1 ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com>: >

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

Hi, The following url is being played with incorrect a/v sync in Firefox: http://195.10.10.216/flumotion/videodemo/med.ogg?token=c965dab73e5ed982821e01174e87925a4bb3134e4bb9aaec (it is time limited, but should work a few days, I could provide) Tested with 3.6.3pre on Linux (with and without PulseAudio) and Firefox 3.6 on Windows XP. Looking at firefox source code, I found the library that is

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

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:

> > - kate support (what else) - this bumps the Javascript API to 1.1 > > I've not yet committed this to trunk. It does sound pretty cool Can you let me know the reasons (eg, wanting to test first, concerns over the substance of the changes, or other) ? There were no comments so far about the changes to the Javascript API, so I'll assume people have no problem with those ?

OggPlay 0.0.1 Release --------------------- liboggplay is a C library providing a simple programming interface for reading, decoding and playing back Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format. This release is available as a source tarball at:

OggPlay 0.0.1 Release --------------------- liboggplay is a C library providing a simple programming interface for reading, decoding and playing back Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format. This release is available as a source tarball at:

Hi, this patch adds: - kate support (what else) - this bumps the Javascript API to 1.1 - a few build fixes (note that the adding of -L/usr/X11/lib -lX11 looks suspect to me, that shouldn't be needed, so you may want to leave it out if you think so as well - it's odd as X11 using programs do configure fine on that box) - bad pointer dereference fix (mouse callback) - avoid the input

> 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

Is anyone working on liboggplay, and if so, is there any plan to support keyframe-based seeking? I found this, but seems to me that the feature ought to be part of liboggplay: http://pearce.org.nz/2009/05/video-seeking-improvements.html Is there a more appropriate list to post to regarding liboggplay? Shayne Wissler -------------- next part -------------- An HTML attachment was scrubbed...

> 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've tried to separate out the general bugfixes from the new > implementation work in this patch: Sorry, I should have done that, I do tend to fix stuff I find while coding and neglect splitting up afterwards. Bad me. > I've not yet committed this to trunk. It does sound pretty cool > though. I don't see any problem with adding pango etc. support, it's > pretty

I'm starting with the theora player_example.c. I want to be able to determine the duration of the audio/video ahead of time, to be able to display it somewhere. I can't see anything obvious in ogg.h, theora.h, or vorbis.h for this. Can anyone help me with the right place to look to do this? Thanks, Ken Larson FMJ project, fmj.sourceforge.net