similar to: Ogg/theora a/v sync issue with 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:

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:

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

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

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

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

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

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:

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.

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

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

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

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

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

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-liboggz-libfishsound.html Thanks to Ralph Giles

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-liboggz-libfishsound.html Thanks to Ralph Giles

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-liboggz-libfishsound.html Thanks to Ralph Giles