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

[Loren Merritt]

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

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.

--Loren Merritt
-------------- next part --------------
Index: DOCS/man/en/mplayer.1
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v
retrieving revision 1.738
diff -u -r1.738 mplayer.1
--- DOCS/man/en/mplayer.1	22 Sep 2004 17:43:39 -0000	1.738
+++ DOCS/man/en/mplayer.1	23 Sep 2004 18:17:11 -0000
@@ -6734,18 +6734,13 @@
 This is required if you want a CBR (constant bitrate) encode.
 .
 .TP
-.B iframe=<value>
-I frame frequency (default: 60)
+.B keyint=<value>
+maximum interval between I-Frames
+Larger values save bits at the cost of seeking precision. (default: 150)
 .
 .TP
-.B frameref=<value>
-Number of previous frames used as predictors in a P-frame (default: 1).
-This may cause tiny changes in bitrate and PSNR.
-Some decoders are unable to deal with large frameref values.
-.
-.TP
-.B idrframe=<value>
-Each <value> I-Frames are IDR-Frames (default: 2).
+.B idrint=<value>
+One in each <value> I-Frames are IDR-Frames (default: 2).
 In H.264, I-Frames do not necessarily bound a closed GOP because it is
 allowable for a P-frame to be predicted from more frames than just the one
 frame before it (also see frameref).
@@ -6754,6 +6749,13 @@
 prior to the IDR-Frame.
 .
 .TP
+.B frameref=<1\-15>
+Number of previous frames used as predictors in a P-frame (default: 1).
+This is effective in Anime, but seems to make little difference in 
+live-action source material.
+Some decoders are unable to deal with large frameref values.
+.
+.TP
 .B bframe=<value>
 number of B-Frames between I- and P-Frames (default: 0)
 .
@@ -6834,6 +6836,7 @@
 .TP
 .B rc_sens=<0\-100>
 ratecontrol sensitivity (default: 4)
+This affects only CBR ratecontrol, not two pass or constant quantizer.
 .
 .TP
 .B ip_factor=<value>
Index: libmpcodecs/ve_x264.c
===================================================================
RCS file: /cvsroot/mplayer/main/libmpcodecs/ve_x264.c,v
retrieving revision 1.5
diff -u -r1.5 ve_x264.c
--- libmpcodecs/ve_x264.c	22 Sep 2004 10:26:21 -0000	1.5
+++ libmpcodecs/ve_x264.c	23 Sep 2004 18:17:11 -0000
@@ -61,7 +61,7 @@
 static int bitrate = -1;
 static int qp_constant = 26;
 static int frame_ref = 1;
-static int iframe = 60;
+static int iframe = 150;
 static int idrframe = 2;
 static int bframe = 0;
 static int deblock = 1;
@@ -90,8 +90,8 @@
     {"bitrate", &bitrate, CONF_TYPE_INT, CONF_RANGE, 0, 24000000, NULL},
     {"qp_constant", &qp_constant, CONF_TYPE_INT, CONF_RANGE, 1, 51, NULL},
     {"frameref", &frame_ref, CONF_TYPE_INT, CONF_RANGE, 1, 100, NULL},
-    {"iframe", &iframe, CONF_TYPE_INT, CONF_RANGE, 1, 24000000, NULL},
-    {"idrframe", &idrframe, CONF_TYPE_INT, CONF_RANGE, 1, 24000000, NULL},
+    {"keyint", &iframe, CONF_TYPE_INT, CONF_RANGE, 1, 24000000, NULL},
+    {"idrint", &idrframe, CONF_TYPE_INT, CONF_RANGE, 1, 24000000, NULL},
     {"bframe", &bframe, CONF_TYPE_INT, CONF_RANGE, 0, 10, NULL},
     {"deblock", &deblock, CONF_TYPE_INT, CONF_RANGE, 0, 1, NULL},
     {"deblockalpha", &deblockalpha, CONF_TYPE_INT, CONF_RANGE, -6, 6, NULL},