[XviD-devel] Scenechange detection

[Christoph Lampert]

On Wed, 31 Dec 2003, Radek Czyz wrote:
> Come to think of it, this works good for p/b part of the decision - pure 
> black should bias towards a b-frame. 
> For I-frame decision however, pure black should be reasonably neutral
> - it's almost as easy to code in an i-frame as in a p-frame. Perhaps
> we should count the values separatly.

Should it really bias to B? That would mean that letterboxed movies should
always get more B-frames than non-letterboxed. I rather think, the black
bars could be completely ignored, because they are encoded with hardly any
bits, no matter if in I, P or B. Okay, for B-frames, the blocks might need
no bit at all, because the collocated is SKIPed, but those 200 bits
or so more or less per frame won't change anything. At least for multiples
of 16 as height. 

Using B-frames (with high quant) could risky at the edges, if the height
is not a multiple of 16, btw. 
 
> > Ah, okay, I didn't remember those. Still, it had a strange effect in this
> > clip. Btw, do those extra keyframes get removed in second pass if a
> > keyframe within the limit is detected? I think they should, even if the 
> > overhead is small. 
> 
> They are not, and unfortunately it's difficult to tell if a frame became 
> an i-frame because it was definitely a scene change or because the limit 
> decreased the threshold so much (we can expect that from an 298th frame 
> in a row, but we never know for sure)

Okay, yes, because of the threshold lowerin. On the other side, 
if we didn't stop ME after the limit was reached, this shouldn't effect 
speedup more than 0.x%, if at all, and then we would now the real
amount of INTRA in the frame.
I still believe that somehow a "forced" keyframe should get a different
return value than a "detected one. 
 
> > XviD set 42 keyframes. P-frame at nondetected scenechanges were about 
> > same size as I-frames, so no gain or loss from this. I-frames at non-scene
> > changes were of course larger. 
> 
> Yeah I think the current code does that - doesn't care if a scene change 
> which is very close to a keyframe is missed, but rather tries not to 
> make any non-scane-change a keyframe. It appears to work well ;)

For "movie" sizes, yes. For very small frames, maybe not, but maybe that
doesn't matter much for our target users. However, for a "streaming" mode
with many keyframes, it might be worth keeping it in mind. 

gruel