similar to: Liboggplay seeking artifacts

Don't say I didn't warn you: http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long Don't get me wrong, I'll be as ecstatic as any of you to see Theora and VP8 succeed, I just see the patent system as far more insidious than I think many of you do. Shayne

Hi, first post on this list. I run a small game development company specializing in casual Windows/Mac games. We've been using Theora for video playback inside our engine for a while, but we always run into performance issues. I've tracked them down to two parts : YUV to RGB decoding (done via software) and uploading the new pixel data to the video card as a texture. For the YUV to RGB

Shayne Wissler <wissler at gmail.com> wrote: > I have a program that is given a random file and needs to determine > whether it is Vorbis or FLAC. For Vorbis, there are various places > where I can infer that I have a bad stream. But for FLAC, when I call > either FLAC__stream_decoder_process_until_end_of_metadata or > FLAC__stream_decoder_process_single, it searches the

Does the reason Theora is relatively safe from patent infringement lawsuit have more to do with it actually not being encumbered, or is it because its use is decentralized? For example, FreeType is not patent-free, nor is Linux, yet they succeed because on the one hand, they are open source, and those who maintain them do not guarantee anything regarding patents, it is up to each individual user

Hello, I have a program that is given a random file and needs to determine whether it is Vorbis or FLAC. For Vorbis, there are various places where I can infer that I have a bad stream. But for FLAC, when I call either FLAC__stream_decoder_process_until_end_of_metadata or FLAC__stream_decoder_process_single, it searches the entire file before giving up. I'd like it to stop searching as soon

Hello, I've written a program loosely based on libtheora-1.0/examples/player_example.c, I would like to add the ability to randomly seek to a particular place in the stream (for starters, skipping forward or backward N seconds at a time). I found some useful information at http://www.xiph.org/ogg/doc/ogg-multiplex.html, but I was wondering if any sample code existed that implemented seeking?

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

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

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

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

> 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

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

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

After some more thought on this, I'm trying to work out whether the back link offset needs precision. Semantically, the only need we have for this is to be able to seek back to a point before the start of the earliest event still active at the time of the original seek. As far as I know, and please correct me if I'm wrong, nothing in Ogg mandates that this backlink actually resolves to a