similar to: Question about updated block list history in the encoder

Hi all. I'm here again :) The small leak in my app is gone. I'm going on with it, now I grab a frame from a video device and I encode it with Theora... The debugger ( valgrind ) says: ... ==2782== Invalid read of size 1 ==2782== at 0x1B94B0BD: PixelLineSearch (scan.c:1482) ==2782== by 0x1B94B35A: PixelLineSearch (scan.c:1597) ==2782== by 0x1B94B447: LineSearchScorePixel

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

Hi, I havent posted to this list before, so "hi" I have been experimenting with Theora and noticed it still has the same crash bug that VP3 did. Basically, if you begin compression, and compress a blank black frame more than about twice in a row you get a Div by 0 error. I traced the fault to being in the "RegulateQ" function, and is because YUVAnalyseFrame() returns 0 for

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

Hello, all! I have many questions about tap device architecture. What is a right way to calc mtu on TAP device to avoid fragmentation on real eth device? I suppose TAP MTU = 1500-8(UDP)-20(IP)-18(Ethernet) = 1454. So I'd set 1454 for tap device: "ip link set mtu 1454 dev eth0" I'm not shure about what is the exact size of ethernet frame header, which tap device use in switch

Hi, I checked out the Theora source code for the first time as I figured that's the only way the Theora quirks will get documented (and subsequently re-implemented in libavcodec). I see that most of the code cribs the original VP3 source code, including the misspelled comments. Moving right along, I can't reconcile the way bits are packed in the stream. In VP3, the first byte of an

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

On Sunday, 12 August 2001 at 04:33, Asymmetric wrote: > At 17:05 8/11/2001 -0400, you wrote: > > > >you tell me. Works alright here, except in xmms which has a bug in its > >shoutcast metadata handler. I've submitted a patch at bugs.xmms.org > >for it. > > Hmm.. well with the current version of winamp and the previous two it would > and does skip if I

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

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

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

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.

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 11/06/2010 1:48 p.m., Benjamin M. Schwartz wrote: > On 06/10/2010 09:25 PM, Chris Pearce wrote: >> I looked at Benjamin's proposal, it does indeed produce much better >> compression. However I decided not to use it because I felt it was too >> complex. > For the record, the Skeleton 4.0, as implemented by OggIndex, currently > requires a multi-round iteration to

The theora directshow filter now has basic seeking that doesn't lose sync. It doesn't seek to keyframes however so you get the brief period of mangled video until the next keyframe, but after a seek the audio and video do remain in sync. There is still the occasional crash when seeking in theora. The whole timestamping mechanism has been changed, this has had some slight negative effects

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

Hi, Currently I'm using a pretty dirty way to split streams. I kill the client every hour. But a more decent approach would be setting a time mask for dumpfile. Or an external event making a new file at event time. One problem i see are keyframes. The new file should split after the last 'normal frame' so the new file gets a keyframe first. What would be a proper way to do this?

> 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

<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