[Theora-dev] Patch that fixes distortions during static scenes

[Ivan Popov]

Hello Aaron,

> > This looks like a perfect behaviour when a keyframe is inserted as the scene
> > changes, but as well very bad during static scenes (causing a burst
> > of artifacts).
> 
> This commonly happens with static scenes because the encoders rate control
> logic doesn't try to store up bits for the keyframe. It just looks at the
> current number of bits it has for the frame and tries to find a Q that
> fits that. In a static scene there are few blocks to update so it computes

ok, I see now.

> The rate control logic needs to have some sort of mechanism to regulate 
> changes in Q so that such drastic events don't happen. I'm planning on 
> looking into a solution for this problem.

It would be great. I think it would noticeably improve the quality.

> > It looks even more strange as it happens when we clearly have a huge
> > excess of unused bits - I ask for 2000 kbit/s and get about 250 kbit/s
> 
> I'm guessing that it is less noticable at this bitrate. Depending on the
> frame size and frame rate this still may not be enough for the encoder to
> think it has enough bits to encode the key frame at the same Q as the
> interframe. Are you seeing this in the Amelie clip? If not send me a link

Yes, I see it on that clip. I am using its first 30 seconds, and
-V 2000 gives about 250 kbit/s average video rate - a small fraction of the
available "bandwidth". Not enough information to encode? :)
For checking i use "mplayer -fs -fps 5" (full screen, 5 frames per second)
It shows regular "bursts" of errors, most noticeable on the text screens,
presumably at each keyframe (about each couple of seconds or so? at 25 fps).
It seems that it is just the keyframe that is worse than the rest
(while single-stepping through the relevant frames).

> > On the third side, I can reduce the probablility of such "error bursts"
> > by tweaking keyframe frequency - yet it feels like a workaround for
> 
> I haven't looked into how the keyframe frequency effects this problem, but
> I'm not suprised that it helps some. I'll take a look at this as well. 

It reduces the problem a lot as most keyframes happen then at scene changes,
where the behavior is very adequate. The first frames after a scene change
may be very bad without affecting the percepted quality.
Still we want to be able to insert a keyframe at an arbitrary point,
don't we?

Regards,
--
Ivan