similar to: Simple player and encoder binaries for Windows

Well, I've been slamming my head against this all night, so it's time to ask for help... Having gotten together a reasonably decent port of what I thought was the whole API to the Ogg Way, complete with Ogg mem management and bitpacking, I started digging deeper in the code... only to find that it looks like I only have a middle stream handler. The encode and decode code both assume that

First, an introduction: I work in a group that makes educational software. In the coming months, we're planning to release our entire Mac/Windows runtime under the GPL. We currently encode our audio with MP3 and our video with VP3. For playback, we rely on QuickTime 5 on MacOS and Windows. In the short run, we'd like to help maintain the VP3 QuickTime codecs, preferably without

--- "Tabuleiro" wrote: Hi, guys. I was working with the VP3 code, planning to integrate it with Ogg for a self-contained solution for video playback, platform independant, no installation required, no QT, no AVI runtimes. My main interest is CD-based work using local files and portability/performance, not really into streaming or anything fancy (network error correction, prediction,

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

Question: is it permissible to put more than one frame packet into a page? At 30 fps, Ogg page overhead is on the order of 8 - 10 kbits/sec. At low datarates, this is going to be unacceptable. If I shove a few frames into a page, how does this affect the granulepos stuff? ___ Dan Miller (++,) Founder, On2 Technologies <p>--- >8 ---- List archives: http://www.xiph.org/archives/

pls let me know if/when you have theora compiling & running on Windows. -----Original Message----- From: Tabuleiro [mailto:beta@tabuleiro.com] Sent: Tue 10/22/2002 3:13 PM To: theora-dev@xiph.org Cc: Subject: [theora-dev] compglobals.c I believe this file is no longer used and contains functions that are no

Okay, thanks to some stubbornness on my part and helpfulness on the part of people on this mailing list, I got the Ogg Theora alpha compiled up and installed and running. Yesterday, I went to the Prelinger archives (the public-domain video archive at www.archive.com) to find a high-quality original to re-encode as a test. The encoder worked just fine, and playback as well, and I thought I'd

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

All the notes you mention for VC are in vp32_build.html in the release, but thanks for reiterating. Last time I built for Mac I believe I did the os9 version in CW6 and the OsX version in CW8, but I can't think why they shouldn't both compile in CW8. <p>-----Original Message----- From: Tabuleiro [mailto:beta@tabuleiro.com] Sent: Thu 9/5/2002 4:25 PM To: theora-dev@xiph.org Cc:

good question. I would think beta means the bitstream is more or less stable. Monty? >If June is the goal for public release, is the second milestone the first beta/rc1? Guess what I'm asking is, whats a good estimate for when the codec will be frozen as far as backwards compatability.. -----Original Message----- From: Arc [mailto:arc@indymedia.org] Sent:

[standard disclaimer about my mail format] in ftp.vp3.com/theora user: vp3 pass: vp3dev theora_dbm_5-28.zip this implements a bitstream change; the header now contains a compressed huffman tree rather than the frequency counts (as discussed) pardon my inability to use diff correctly. The change in toplevel.c is trivial (new function names & params) huffman.c is the important one. I

As I understand it the current plan is to make it possible to losslessly transcode VP3 video to Theora video. In my experience, one of the "features" of VP3 is it drops frames in the event that there is little/no movement in a frame, or if "drop frames" is enabled, to drop frames if the data rate is getting too high. I understand that the way that VP3 does this in

ok now I see why we need another packet in the header. The first one is basically for ID purposes (theora_decode_header()). I've jammed my huffman trees in there but it sucks because I need them later on when I actually build the huffman tree structs (theora_decode_init, calls InitHuffmanSet()). At that point the original header packet is gone so I've been keeping it around in a buffer.

Hi all, > One problem I see with your proposed implementation is that it does not > specify how audio and video would be synchronized, since there are no > absolute time stamps for the video frames. So it is difficult to account > for > audio latency on different systems, much like when you play an AVI file. > Ideally it would be wonderful to have timestamps that could be used

Hi, So it took a little while to get here but VP3 through ffmpeg is finally starting to achieve viewable results. It partially works right now. Keyframes only. And monochrome. Oh, and the picture is upside down (something I did not realize about VP3 until I let it fly just now). Anyway, here is a picture of ffmpeg's VP3 decoder in action using xine:

some of you may find this helpful: I've uploaded a short (5 second) raw clip in yuv4mpeg format, associated audio, and batch files to exercise the encoder & decoder examples. In addition I've included the file as compressed (test.ogg), and a longer version as well to test playback sync. Notes: to use MPlayer with the -vo yuv4mpeg option, you need to get the latest release and compile

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

I found out about vp3 from the new winamp and coincidentally i also happen to be trying to find a suitable solution to broadband streaming. I have used flaskmpeg to create a 17mb .avi file from an 82mb Mpeg 1 file and it looks great it took about twenty minutes to encode. It runs for eight minutes and the audio is also fantastic using the lame encoder. However when I try to do the same in

My understanding -- Monty or Emmett, feel free to chime in if you think this is incorrect -- is as follows: www.theora.org is the home for all new releases of the Theora video codec (formally known as VP3). This includes the main OGG/Vorbis integration product, which Monty is working on personally, as well as the QT and Windows codecs, both legacy VP3 versions and new versions reflecting any

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