theora dev - Nov 2008 - Question about updated block list history in the encoder

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 updated in the current interframe is, 
but I'm sure there's a good one (perhaps it's to further refine the 
updated fragments). However, the way keyframes are handled in this 
history seems very counter-intuitive to me.

When PrevFragments is initialized in ScanYUVInit(), 
PrevFragments[PrevFrameLimit-1] is set to BLOCK_CODED, which, although 
pointed out in the comments would be what you would expect for the very 
first keyframe if YUVAnalyseFrame() was called when coding the first 
keyframe, I would argue that PrevFragments[1] should have been set 
instead. In either case this seems odd to me, as it would appear to 
force the 2nd frame (presumably an interframe) to require *all* 
fragments to be updated. In practice I suspect that most of those 
fragments get pruned from the list because their DCT ends up being zero, 
but it still seems to me that if PrevFragments is a history of updated 
interframe blocks, then a keyframe should set it to BLOCK_NOT_CODED 
instead (but I could be wrong, since I don't really understand what the 
history is for).

However what is really confusing me is that PrevFragments doesn't seem 
to be updated by any subsequent keyframes. This has the peculiar effect 
of biasing an interframe from a new keyframe to include blocks from 
interframes from the previous keyframe, and this just seems wrong to me. 
Am I missing something here, or is it supposed to work like this? Any 
help would be appreciated.

--John

John Ridges wrote:
> Am I missing something here, or is it supposed to work like this? Any 
> help would be appreciated.
A) I highly doubt it's supposed to work like this
B) It doesn't really matter, since Thusnelda will (hopefully in the not
_too_ distant future) be replacing the old VP3 encoder we're shipping
now. Thusnelda decides when to code or skip blocks by solving a real
optimization problem with a real objective function, rather than using a
bunch of heuristics.