similar to: Dumpstream split based time/size

Here is a fix that prevents the encoder from spending too many bits on keyframes. The main problem is that the old code computes the target keyframe bitrate incorrectly. This causes the code that computes the Q for the frame to think that it has tons of bits to spend. It selects a high Q value for the keyframe. Since so many bits were spend on the keyframe the the inter-frames have to use a much

I am using the directshow Theora encoder to compress a live video stream. A dump of the encoder settings is given below. The starred settings have been explicitly configured and the others are defaulted or derived values. These settings produce an even, dark (almost black) recorded result as does any recording with Keyframe Freq <= 32. Keyframe Freq >32 works perfectly. The incoming

I'm new to the list so please excuse me if this has already been rehashed before. There seems to be something very odd about how the PP_INSTANCE::PrevFragments array is handled during keyframes. I'm not a video codec expert so I'm not entirely sure what the reason for keeping a history of blocks updated in the last few previous interframes and adding them to the blocks to be

Folks have noticed that the documentation is semi-silent about how to properly encode the granule position and interleave synchronization of keyframe-based video. The primary reasons for this: a) we at Xiph hadn't had to do it yet b) there are several easy possibilities, and the longer we had to think about it before mandating One True Spec, the better that spec would likely be. The

Here is a patch that fixes distortions that appear during scenes with no motion. Tbe problem was that UpdateFrame() was not being called when a MotionScore of 0 was computed. Since UpdateFrame() was not called the buffer returned by theora_encode_packetout() would be the same buffer that was output for the last frame that had a non-zero MotionScore. This is obviously incorrect behavior. I've

Hello, Today I was benchmarking DV video on a AMD64: skinkie@zwartepiet ~ $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3500+ stepping : 0 cpu MHz : 2210.197 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes

Hello, i have just migrated machine to xen server where only 2 cpus are available. I have copied config from machine where domU was located before. That machine had 4 CPUS (QUADCORE), current machine has 2 CPUS (1 XEON 2cores). I have forgot to change vcpus from 4 to 2 in config, but .. what really surprised me ... machine started . How it is possible? It was really slow alltought and not

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

I have almost finished integration of Theora into our videoconferencing program. Since a videoconferencing program is realtime, it is UDP-based and wraps the Theora stream in RTP (More on that later). The problem here is that most examples I could find, wraps the theora stream in ogg, and used over tcp or files. I send over UDP and clients need to be able to start in the middle of the stream.

4) Subtract 1 from the keyframe, then repeat step 3). 5) Begin reading from the frame discovered in step 4. Drop any packets which are output on the first page. Count down until we reach the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. Steps 4 and 5 are

Hi ! Maybe you could find something with this line in the <mount> section of the icecast.xml file: <dump-file>/tmp/dump-example1.ogg</dump-file> But I prefer to use streamripper which can do this easily on a client side: http://streamripper.sourceforge.net/ http://packages.debian.org/unstable/sound/streamripper yomguy Stefan de Konink wrote: > On Mon, 24 Oct 2005, Jaakko

Hi, When doing a live ogg+theora stream on our server we ran into the following problem: When a client connects we send out the theora header pages followed by the actual live stream pages. The problem is that the first ogg data page does not have the right page number (2), which causes libogg to not want to decode the first _packet_ of that page. Since that first packet happens to contain the

On Feb 11, 2008 9:27 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > > Right. This was, in fact, one of the roles of "chaining" where you'd > > mark such changed components with a chain boundary, at which such > > things are explicitly allowed to change. The drawbacks are the > > overhead of resending all the setup data for

Hello, Does anyone know the answer to this question below? (Note... they're calling the Theora codec "Ogg" below. I know technically it's not correct... but that's what some are calling it.) ---------- Forwarded message ---------- From: Enric <enric.media@gmail.com> Date: Aug 19, 2007 10:13 AM Subject: [show-in-a-box] Re: Ogg To: show-in-a-box@googlegroups.com A

> Right. This was, in fact, one of the roles of "chaining" where you'd > mark such changed components with a chain boundary, at which such > things are explicitly allowed to change. The drawbacks are the > overhead of resending all the setup data for configurable codecs like > vorbis and theora, and the semantic conflict between 'chain boundary > flags an edit

Hello, I'm just totally confused. In my theora streams encoded using ffmpeg2theora (but also when using my own encoder) I have packets with a granulepos of -1 so I can't identify the packet during a seeking operation correctly. I can also see those strange value when I just print the packet granulepos before sending it to the Theora decoder. I know why there are PAGES with granularpos of

<br> 4) Subtract 1 from the keyframe, then repeat step 3).<br> <br> 5) Begin reading from the frame discovered in step 4. Drop any packets<br> which are output on the first page. Count down until we reach the<br> keyframe, dropping packets until then.<br> <br> 6) Continue counting down until we reach the target frame, we are now<br> decoding each

Hi all, First of all a big thank you for your work. I would like to know what is (could be) the best (optimal in a psnr and/or subjectivity sense) maximum distance between keyframes or is theora using a good heuristic change scene detection mecanism? Does it really matter to theora as with mpeg4 part2/10? Thank you and keep up the good work -- Josh

Dear vorbis-dev I tried to split an ogg file which was downloaded as a part of a stream with mplayer -dumpstream -dumpfile file.ogg http://..../stream.ogg. The metadata or headers or what it is is then of course in error. (I hate this problem.) Both vcut (I'd post version if vcut supported a --version or -V option) and oggsplt (= mp3splt (same about version)) (according to this page, they

On Feb 25, 2011, at 1:43 AM, Niv Sardi wrote: > A bit of nitpiking: > > * indentation seems off. What's the convention for this project? It looked like 4 spaces, and I tried to match but might have let some tabs slip through. Someday I should learn how to tweak vim to do this for me. >> --- src/source.c (revision 17873) >> +++ src/source.c (working copy) >> @@