similar to: broken encoder

Hello, I try to compile player_example.c from http://downloads.xiph.org/releases/theora/libtheora-1.1.1.zip in Visual Studio 2008 on Windows XP. I built and added to the project libogg-1.3.0, libtheora-1.1.1, libvorbis-1.3.2 (http://www.xiph.org/downloads/) and SDL-1.2.15 (http://www.libsdl.org/release/SDL-devel-1.2.15-VC.zip). When I compile player_example.c Visual Studio shows: fatal error

>Also, 'portaudio' doesn't appear to produce a static library at all, so it doesn't appear to be possible to get a working splayer executable on Linux unless there is a 'hidden' way to get the portaudio distribution to build one. ("ldd: -lportaudio not found"). I believe splayer is only intended to be a Win32 executable. Note that it is in a directory

Hi all, Just a heads up to let you know that I've fixed up the Visual C++ project files so that libtheora and the associated experimental programs (dumpvid/encoderwin/splayer/transcoder) builds on Windows again. I also have good news and good news. The bad news is: experimental\splayer doesn't work. It compiles, but segfaults immediately when you try to play any Ogg file. The bug

So, release priorities. I have all of derf's proposed bitstream changes accounted for in the reference encoder, if not supported in the decoder. These are going to be released as alpha 3 to get the new bitstream changes out for wider testing while we work on spec and implementations of the extensions. The remaining issue is the broken buffering in splayer. I'll take care of that

I've just committed an image flip for compatibility with VP3 lossless transcode. Thanks to mau and derf for verifying that this was needed. It's a little hacky on the decode side; suggestions for improvement are welcome. Since this is a bitstream change, and we're still a ways from having a complete spec (which is the gating item for beta 1 and the bitstream freeze) we're

Derf's from-scratch alternate implementation of the theora codec is now publicly available from our subversion repository. http://svn.xiph.org/experimental/derf/theora-exp/ This exciting new codebase promises superiour performance, and the encoder is capable of higher quality output than the current represenation, taking advantage of the bitstream extension we've added to the

Hello all. I've been playing around with theora since it first entered CVS, and I like what I'm seeing. Today I've been fixing xine's theoraplugin to understand theora_info.frame_{width,height} and theora_info.offset_{x,y}. I only got it working after some experimenting and basically copying the code from player_example. A few questions related to this: 1. What are the legal

Hi! I'm having some trouble with theora in windows, I would really appreciate if you could be able to give me a hand with this. First, I was not able to build theora in cygwin, because I built vorbis and ogg perfectly, but when I try to run ./configure with theora it can't find the ogg libs, if I use the --using-ogg-path = ... with /usr/local/lib it runs ok, but then it fails to compile

This is mostly for derf, but others may be interested too. Attached are the warnings (stderr log) from compling theora under gcc 3.2.3 (Debian). There quite a few. Many of them are spurious, but some indicate real bugs. In particular it seems likely we have more unitialized variables since Dan reports differing encoder output depending on the compiler used. In general, we need to go through

the files produced by windows compile vs. Linux are indeed significantly different in size (about 140K vs. 160) However I'm not convinced all the default parameters are set the same way in the two example files. This needs to be verified to see if there really is a bug, or can the two versions produce byte-equal output streams? <p> ___ Dan Miller (++,) Founder, On2 Technologies

hi, ok. i am pretty new to this list, but there seems to be little activity at all. first of all, here is a screenshot: http://greenthumb.jabberstudio.org/video.png - it's screenshot of my buddy list in my jabber client (java based). I have a simple (or not so simple) task to achieve: stream the video from one end through the jabber server to another end and show the stream in my buddy

it appears your encoder/player do not yet reflece the changes rillian introduced wrt theora headers, which have been split into three parts -- header proper, comment, and tables (see toplevel.c). It's strange that your code works at all linked against the new libs; presumably since the tables still have the hard-coded values, if you encode & decode from the same lib compile you won't

Speaking of portability and people more familiar with SDL: The reason we have two example players for theora is that monty wrote the original example around the OSS audio interface used on several free unix-like operating systems, which immediately excludes win32 and MacOS, even though it used SDL to display the frames. SDL also has audio support, and is quite widely ported. splayer replaces

as per yesterday's discussion at #theora -- It has been suggested that we devise a method such that we will be able to add certain features to the bitstream (interlace, exotic color subsampling, clip length flag for download, etc), in such a way as to not obsolete streams encoded previously. Rillian's suggestion, which is pretty much standard practice, is to add a bitstream revision

--- Stephane wrote: VP3 codec uses a lot of CPU for decoding. We will need some optimization because now this codec is way too slow for home uses. --- end of quote --- Actually, the Windows VP3 QuickTime codec runs just fine on a 400MHz Pentium II box, with only occasional glitches on some dodgy Celeron systems. At work, we routinely test 320x240 full-color, full-motion video on low-end boxes.

Win32 builds, encodes, and plays fine for me (as long as it's a 5-second clip of some girl singing out of tune...) My notes: looks like the example players still expect exactly three headers. As discussed I'm hoping we can rework it so unexpected headers do not error out. Everyone will undoubtedly be copping code from example_player.c or splayer.c, so we should try to fix this before

Dan, In reviewing the code, derf came across the DCSearchPoints array in QuadCodeDisplayFragments(), encode.c:696. It looks like it specifies a search order for nearby coded fragments for prediction if there isn't a nearest neighbor. However, the upper search bound is defined as *0*, so the search loop (line 917) is never executed and it always falls back to the last coded fragment.

Monty, Derf and I were discussing some theora bitstream improvements. He was curious about the spare bits in the keyframe header. There's a keyframe type bit which is always DCT_KEY_FRAME aka '0' and two spare bits. You took out a lot of similar extra bits in the VP3 code. Do you remember anything about the motivation for leaving this one in? Given the constant, were there plans

Hi, despite the warnings on the website ;-) I played with the current CVS source of theora on Windows 2000 w/ Microsoft Visual C++. The codec and the "experimental" example programs compiled fine. I also encoded a 33 MB MPEG2 (?) video (3 minute trailer) to a 14 MB .OGG using "mplayer -vo yuv4mpeg -ao pcm" and the "encoderwin" sample program, and play it with the

We're about ready to do a 1.2 alpha release from the ptalarbvorm tree, and as such it's no longer experimental. I've replaced the theora svn trunk with a copy of derf's experimental tree; please do subsequent development toward the release there. The old 1.1.x trunk is available as http://svn.xiph.org/branches/theora-1.1 if you need it. -r