ogg.k.ogg.k at googlemail.com
2008-Apr-21 10:33 UTC
[ogg-dev] [PATCH] liboggplay - kate support, build fixes, and misc
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 it isn't here (I didn't have this when I started hacking on liboggplay) - frob the CFLAGS/LIBS in Makefile.am to make it build for me (you want to look at this and only pick what seems correct to you, as I'm hazy on that one) - oggplay_set_track_inactive is now exposed in the API (I needed this to switch kate tracks on the fly in the browser plugin) Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: liboggplay-with-kate.diff Type: text/x-patch Size: 25497 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080421/3f72bc69/attachment-0001.bin
Conrad Parker
2008-Apr-21 19:33 UTC
[ogg-dev] [PATCH] liboggplay - kate support, build fixes, and misc
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 fileconfigure.ac:366: required file `oggplay-uninstalled.pc.in' not found I think you forgot to include oggplay-uninstalled.pc.in in the patch :-)> - configure.ac checks for C++ compiler > - no check for fishsound version - it wanted 0.8.0, but the svn itself > was 0.7.1 !?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. (the liboggplay README does however specify the branch, just above the line you added about Kate support ;-)> - don't use imlib2 (nor dump-first-frame) if it isn't here (I didn't > have this when I started hacking on liboggplay) > - frob the CFLAGS/LIBS in Makefile.am to make it build for me (you > want to look at this and only pick what seems correct to you, as I'm > hazy on that one)thanks, you added a missing $(FISHSOUND_CFLAGS) to src/liboggplay/Makefile.am> - oggplay_set_track_inactive is now exposed in the API (I needed this > to switch kate tracks > on the fly in the browser plugin)ok! 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. I've committed (in changeset:3561) everything except: - the changes which reference oggplay-uninstalled.pc - removal of the fishsound version check - the changes to the type of sample_in_record cheers, Conrad. -------------- next part -------------- A non-text attachment was scrubbed... Name: liboggplay-kate-int-long.diff Type: text/x-patch Size: 1985 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080422/92d53b06/attachment.bin
ogg.k.ogg.k at googlemail.com
2008-Apr-22 09:03 UTC
[ogg-dev] [PATCH] liboggplay - kate support, build fixes, and misc
> configure.ac:366: required file `oggplay-uninstalled.pc.in' not found > > I think you forgot to include oggplay-uninstalled.pc.in in the patch :-)Ahem. I must have. I'll send it when I reach my dev machine.> (the liboggplay README does however specify the branch, just above the > line you added about Kate support ;-)Ah, OK. I already had liboggplay svn around from before, so I didn't think of checking this.> 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.Yes, the reason is that all the routines here return a long (I presume so they can be used from Python ?) so that's what I did here. However, the number of samples (here, for me, granules) is an ogg_int64_t, so that's what I put on the structure. Would you settle on long or ogg_int64_t ? While there, a couple questions about the mozilla browser plugin, since this is an annodex project: - would you welcome kate support here too ? - would additional optional dependencies beyond libkate be OK (I have none at the moment, but I'm thinking of fontconfig, and maybe later pango and cairo, though this is more long term) - I've added new Javascript APIs to handle kate streams, and bumped the API version to 1.1 - is there anything I need to be aware of that might break with this API change ? Works fine here in a controlled environment (firefox 2.0.0.8, streaming from icecast). - it seems to say it handles "application/liboggplay", but AFAIU, it can understand all ogg streams (and isn't annodex "application/annodex" anyway ?) so shouldn't that be changed to "application/ogg" ? I know my test stream is a plain Ogg stream, and it works fine. - and would a patch be accepted if there was no implementation of the kate code for mac and windows ? Thanks
ogg.k.ogg.k at googlemail.com
2008-Apr-23 09:35 UTC
[ogg-dev] [PATCH] liboggplay - kate support, build fixes, and misc
> 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 commenting. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: oggplay.pc.in Type: application/octet-stream Size: 343 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: active_track.diff Type: text/x-patch Size: 285 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: oggplay-uninstalled.pc.in Type: application/octet-stream Size: 355 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: browser_plugin-with-kate.diff.gz Type: application/x-gzip Size: 9546 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment-0001.bin
ogg.k.ogg.k at googlemail.com
2008-May-01 09:59 UTC
[ogg-dev] [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 returns ogg_int64_t, and hope Python likes it, is it OK ?
Possibly Parallel Threads
- [PATCH] liboggplay - kate support, build fixes, and misc
- [PATCH] liboggplay - kate support, build fixes, and misc
- [PATCH] liboggplay - kate support, build fixes, and misc
- [PATCH] browser_plugin - kate support, build fixes, and misc
- [PATCH] browser_plugin - kate support, build fixes, and misc