[theora-dev] [OT] Just saying hi!

Dan Miller dan at on2.com
Wed Mar 26 08:35:40 PST 2003



It's not a bad idea (and I think something like that was in previous versions of the code), but at this point I can't recommend any bitstream changes for version 1.0.  Regardless of how simple it sounds, it would require reasonably extensive testing with a modified encoder to be considered stable.

<p> ___  Dan Miller
(++,) Founder, CTO, On2 Technologies 

> -----Original Message-----
> From: Christoph Lampert [mailto:chl at math.uni-bonn.de]
> Sent: Wednesday, March 26, 2003 10:52 AM
> To: theora-dev at xiph.org
> Subject: Re: [theora-dev] [OT] Just saying hi!
> 
> 
> Hi,
> 
> this thread has passed away long ago, but I just came up with an small
> idea I'd like to ask you about: 
> 
> On Wed, 26 Feb 2003, Mike Melanson wrote:
> > * Golden frame: VP3 calls its keyframes "golden frames". 
> The codec needs
> > to maintain the last golden frame in addition to the 
> previous decoded
> > frame since motion vectors can be predicted from either.
> 
> Why did you fix this to be the last keyframe? The image could/will be
> outdated after a few moving frames, and then never be useful again. 
> 
> Instead it might be helpful to let the encoder decide which 
> frame should
> be put into this extra buffer. A one bit flag in bitstream (or
> different header ID) could tell that the current frame should replace
> previous golden frame when it would normally be discarded. 
> E.g. sometimes it might be helpful to always buffer the last 
> 2 frames, 
> or to have a frame from about 1 second ago available, to reconstruct
> background behind moving objects. 
> It's perfectly simple to be made backwards compatible (if the flag is
> never set, only the keyframes are buffered), it's no waste of bits, 
> the decoder doesn't have to be changed much (essentially one extra
> memcpy), and if the encoder doesn't know about it, it doesn't matter,
> either, everything stays as it is now. 
> But if the encoder is clever, it might really save some bitrate. 
> Later versions can extend it to n buffers (FIFO style), again without
> extra overhead, except for mildly higher memory consumption. 
> 
> Christoph
> 
> -- 
> Christoph H. Lampert chl at math,uni-bonn,de | Diese Signature 
> ist maschinell
> Beringstr. 6, Zi. 15, 53115 Bonn, Germany | erstellt und auch 
> ohne Unter-
> Tel. (0228) 73-4708  Fax. +49 228 73-7916 | schrift wirksam.  
>     AZ 27B/6
> 
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 
> 'theora-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No 
> subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
> 
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Theora-dev mailing list