search for: liboggplay

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: http://w...

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: http://w...

To all you great C programmers out there who have been looking for a chance to take on a really cool open source project in video: liboggplay is a library that vastly simplifies the decoding and playback of Ogg encapsulated audio-visual content for programmers. It does everything apart from the actual display of audio and video and has thus been selected as the thinnest library to provide support for Ogg Theora/Vorbis in Firefox's ne...

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

To all you great C programmers out there who have been looking for a chance to take on a really cool open source project in video: liboggplay is a library that vastly simplifies the decoding and playback of Ogg encapsulated audio-visual content for programmers. It does everything apart from the actual display of audio and video and has thus been selected as the thinnest library to provide support for Ogg Theora/Vorbis in Firefox's ne...

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

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 render of this, which the client can then overlay onto the vid...

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 file `oggplay-uninstalled.pc.in' not found I thin...

...5dab73e5ed982821e01174e87925a4bb3134e4bb9aaec (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 supposed to do a/v sync for ogg is liboggplay. glut-player, compiled from git master (3901c1c38), shows the same a/v sync issue. I ran oggplay-info and noticed that the theora overrun histogram is quite important. Theora: Track 0 Worst overrun: 271 frames Average overrun: 263.202 frames Histogram bucket size: 13.550...

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-libog...

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-libog...

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-libog...

Hi, A week or two ago Viktor Gal migrated the liboggplay source repo to git.xiph.org, and this week I moved the liboggz and libfishsound repositories. You can see the git repositories available via gitweb at http://git.xiph.org/ I wrote some brief news about the move, and instructions for getting the code: http://blog.kfish.org/2009/04/liboggplay-libog...

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

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

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

...tuff. As this was confusing, I've renamed the libfishsound branches to what anyone would expect: the currently released code is now in "trunk" (r3592) and what was the previous trunk has been renamed to something much less enticing: "branches/pcm-types" (r3591). > (the liboggplay README does however specify the branch, ... also updated to now refer to libfishsound trunk (r3593). cheers, Conrad.

as subject says - cast to long long as ogg_int64_t is %ld on 64 bit archs. -------------- next part -------------- A non-text attachment was scrubbed... Name: liboggplay-64bit.diff Type: text/x-patch Size: 2109 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080520/04b7a838/attachment.bin

> Besides, this is something that is very easy to implement for > systems which aren't C99. Good point. > IMO, its less ugly than the cast, but only just. Fair enough, maybe I can just parse casts as second nature, which is a scary thought :) I'll post an updated patch soon with the C99 macros instead.

...ccelerated 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 libraries handle alpha compositing, but only in RGB space; anyone using one of those for overlay would w...