[MPlayer-dev-eng] synch to x264 r50 / mencgen

[Loren Merritt]

On Wed, 29 Sep 2004, Guillaume POIRIER wrote:

> Hi,
> Le mer 29/09/2004 à 20:12, Loren Merritt a écrit :
>> Adds a parameter 'scenecut', to control the threshold for inserting extra
>> I-frames.
>
>>  .TP
>> +.B scenecut=<-1\-100>
>> +Controls how aggressively to insert extra I-frames (default: 40).
>> +With small values of scenecut, the codec often has to force an
>> I-frame
>> +when it would exceed keyint.
>> +Good values of scenecut may find a better location for the I-frame.
>> +Large values use more I-frames than necessary, thus wasting bits.
>> +-1 disables scene-cut detection.
>
> In the attempt to provide users the best possible documentation, what is
> suppose to happen is no scene-cut detection is done?
> Are I-frames only inserted each every "keyint" frames?

Yes.

> On a side-note, I'm currently running mencgen on 3000 frames of an anime
> scaled to 704:304, and so far, here are 2 interesting results:
> Best quality (PSNR-wise):
> bframes=1:cabac:deblock:frameref=3:fullinter:idrint=3:keyint=250:qblur=0.5:qcomp=06:subq=5
> PSNR: Y=46.58, Cb=45.95, Cr=45.95, All=46.349
> 257.94 seconds
>
> Fastest withing 1.0 (PSNR wise also):
> bframes=1:cabac:deblock:deblockalpha=1:frameref=3:nofullinter:idrint=3:keyint=250:qblur=0.5:qcomp=06:subq=0
> PSNR: Y=46.1, Cb=45.75, Cr=45.7, All=45.97
> 122.31 seconds

It looks like mencgen is using the "Y", "U", and "V" PSNR fields. Don't. 
They are completely bogus, and will favor bad rate-control decisions.
(I didn't manage to convince the x264 maintainers to remove them, since 
the H.264 reference codec uses the same broken metrics.)
The only correct PSNR value reported is "Global".

Other nitpicks with the current mencgen:
It has two entries for cabacidc=1, and none for cabacidc=2. (Not that I've 
ever seen cabacidc=2 help.)
It doesn't try frameref>3. I see noticeable improvements all the way up 
to frameref=15.

> I'll let this test run during the whole night, it's currently à the 12th
> step of 15 encodes each, so that's 180 different combinations that have
> been explored already... Pffiou! That really eats up LOTS of CPU time!

Heh. I have here a run of 5000 lavc option sets for each of 3 source 
videos...

--Loren Merritt