[MPlayer-dev-eng] [PATCH] synch to new x264 revision

[Loren Merritt]

On Thu, 23 Sep 2004, Guillaume POIRIER wrote:
> Le jeu 23/09/2004 à 20:31, Loren Merritt a écrit :
>> In mpeg[124], there is no reference DCT; each codec uses a slightly
>> different implementation of DCT (there's 9 to choose from in lavc).
>> If the encoder and the decoder use different versions, they get out of
>> synch, and it looks bad no matter how many bits you spend. In practice,
>> the drift can be limited to unnoticeable levels by forcing an I-frame
>> every few seconds (lavc defaults to 250 frames = 10 sec). With a bad
>> decoder, you might want an even smaller interval.
>> In H.264, there's no such problem: It uses a well-defined integer
>> version of DCT, and all compliant decoders must be bit-wise identical.
>
> So does that mean that in h264, there can't be any keyframe "jumps"? I
> don't think it's the right technical term, but I talking about the
> artifact where you can _see_ that the scene has been refreshed and all
> the "crap" drift had gone away?

Well, if you do experience DCT drift, it will be visibly cleared when you 
get to a I-frame. And that one kind of garbage won't show up in H.264.
But most of the time, garbage is just due to too low bitrate, not DCT 
drift.
The problem is that at low bitrates, I-frames and P-frames contain 
different kinds of errors: I-frames have blocking and ringing, while 
P-frames have motion-smeared versions of the previous frame's errors. 
The motion-smeared errors aren't necessarily any lower PSNR than the 
I-frames, but they look worse because they are temporally coherent 
structure that isn't supposed to be there.
Also, in both H.264 and MPEG4, it seems to help global PSNR to use 
slightly lower quantizers on I-frames than on P. This may cause a visible 
jump in quality at low bitrates, if the I-frame is in the middle of a 
low-motion scene.

>> So you never gain quality in H.264 by forcing I-frames. The only
>> remaining purposes of I-frames are:
>> * More efficient coding of frames in which essentailly all blocks are I.
>> This is handled by scene-change detection.
>> * Error resilience. Useful for streaming over an unreliable channel,
>> but normally I prefer to save bits while encoding and use them for an
>> optional external form of error recovery (e.g. PAR2).
>> * Seeking. If you need to be able to seek with 2 second precision to
>> non-scene-changes, then an I-frame interval of 60 is ok. Otherwise, it
>> just wastes bits.
>
> So I guess setting it to 250 and higher should be ok then? ...

Yes.

--Loren Merritt