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

[Guillaume POIRIER]

Hi,
Le jeu 23/09/2004 à 20:31, Loren Merritt a écrit :
> On Thu, 23 Sep 2004, Guillaume POIRIER wrote:
> 
> > Le jeu 23/09/2004  15:59, Jan Knutar a crit :
> >> On Thursday 23 September 2004 15:32, Guillaume POIRIER wrote:
> >>
> >>> I frame frequency (default: 60)
> >>> +Raising their frequency usually improves quality.
> >>
> >> I frame interval,surely?
> >
> > Well, since frequency = 1/interval, I guess increasing the number of
> > i-frames should indeed increase quality, shouldn't it?
> 
> No. Increasing the number of I-frames will always reduce quality.
> (Unless you're encoding at constant quantizer, in which case it will 
> increase bitrate instead.)

Yeah, I figured that out, unfortunately, after I sent that mail.
 

> 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?


> 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? ... 

> Also, it wastes more bits in H.264 than in mpeg4, because you not only 
> use an inefficient coding for the forced I-frame, you also clear 
> CABAC contexts (if using CABAC), and clear previous reference frames so 
> they can't be used to predict future inter-frames (if frameref>1).
> 
> So I propose this patch.

As far as the documentation change, I do like your descriptions and the
idea to have same options name in different codecs (keyint), other than
that, I can't say much about modifying ve_x264.c.

Thanks for the enlightenment,

Regards,
Guillaume