[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