[MPlayer-dev-eng] Re: [MP] Re: [MP] [PATCH] "turbo" mode

[Loren Merritt]

On Fri, 17 Sep 2004, Guillaume POIRIER wrote:

> Le jeu 16/09/2004 à 23:34, Matthias Wieser a écrit :
>> Am Mittwoch, 15. September 2004 22:01 schrieb Guillaume POIRIER:
>>> How do I do that?
>>
>> Add "psnr" to your lavc options. Then you will find a file named like
>> "psnr_342234.log". This file contains psnr numbers for each individual
>> frame. You could plot those numers, calculate differences between
>> different passes/options/... and so on.
>
> Ok, I didn't think about having a look at the psnr log (though I always
> add psnr to lavc options)
> Having a quick look at the log files, on the one hand, I saw that around
> 2/3 of quantizers are the same, which seem to be a good point, on the
> other hand pretty much all psnr per frames are different.
> If I plot with main/TOOLS/plotpsnr.pl both psnr, the global psnr curve
> is quite similar, although with "turbo" there some "outliers" (quants
> are [2-8] with turbo, whereas without they are [2-7]).
> Those outliers aren't many, but they exist, which means _if I understand
> rate-control quite alright_ that at some point the rate-control had a
> bitrate shortage, and had to raise some quants.
>
> Now, this analysis is only based on quants.

Quants are a pretty coarse measure. The actual parameter output by 
rate control is lambda (lagrange multiplier), which is continuous. so you 
might have a frame that wanted quant=1.6 (rounded to 2) on one pass, and 
2.4 (rounded to 2) on the other. But you can't see the actual lambda 
unless you modify mencoder to output another divx2pass.log on the second 
pass (attached).

> If I want to do a mathematical analysis of the frame-by-frame psnr
> difference, am I supposed to plot the difference, the absolute
> difference, the mean absolute difference?? I'm quite puzzled here...
> And if the mean absolute difference is relevant, what would be an
> acceptable mean psnr difference?
> (sorry if I ask too many questions, I just wanna to things right)

I would use mean squared difference (possibly with a bias to care more 
about low-PSNR frames), and an acceptable difference might be the same 
order of difference as between a 2 pass and a 3 pass encode, whatever 
number that happens to be.

>>> How may that be reverent ? Do you mean that given
>>> that the statistics are not as good, maybe say, first frames lack/have
>>> too much bits?
>>
>> Maybe a normally good looking scene gets even more bits. Then the PSNR of
>> the frames of that scene would be higher but there would be nearly no
>> visual difference. But those bits are not available anymore for scenes
>> that would need them. So maybe the mean PSNR would be the same but the
>> visual appearence could be worse.
>
> Got that. I figured it out anyway, not looking at the video (I can't see
> much difference) but just as I for me it just makes sense that the
> statistics being gathered differently produce a slightly different
> result.
> ... but is that all that important if the difference is very small?
> Will the end-user notice such a small difference? I guess they are
> likely to afford a slightly different PSNR if it reduce encoding time by
> 40-45% ?

The question is, using the same total amount of time, can you improve 
quality by using turbo on the first pass and slower settings on the second 
pass? I'm betting yes.

--Loren Merritt
-------------- next part --------------
--- libmpcodecs/ve_lavc.c.orig	2004-08-21 12:31:00.000000000 -0700
+++ libmpcodecs/ve_lavc.c	2004-09-17 09:11:50.520309425 -0700
@@ -185,7 +185,7 @@
 	{"vqblur", &lavc_param_vqblur, CONF_TYPE_FLOAT, CONF_RANGE, 0.0, 1.0, NULL},
 	{"vb_qfactor", &lavc_param_vb_qfactor, CONF_TYPE_FLOAT, CONF_RANGE, -31.0, 31.0, NULL},
 	{"vmax_b_frames", &lavc_param_vmax_b_frames, CONF_TYPE_INT, CONF_RANGE, 0, FF_MAX_B_FRAMES, NULL},
-	{"vpass", &lavc_param_vpass, CONF_TYPE_INT, CONF_RANGE, 0, 2, NULL},
+	{"vpass", &lavc_param_vpass, CONF_TYPE_INT, CONF_RANGE, 0, 3, NULL},
 	{"vrc_strategy", &lavc_param_vrc_strategy, CONF_TYPE_INT, CONF_RANGE, 0, 2, NULL},
 	{"vb_strategy", &lavc_param_vb_strategy, CONF_TYPE_INT, CONF_RANGE, 0, 10, NULL},
 	{"vb_qoffset", &lavc_param_vb_qoffset, CONF_TYPE_FLOAT, CONF_RANGE, 0.0, 31.0, NULL},
@@ -635,15 +635,8 @@
     if(!stats_file) {
     /* lavc internal 2pass bitrate control */
     switch(lavc_param_vpass){
-    case 1: 
-	lavc_venc_context->flags|= CODEC_FLAG_PASS1; 
-	stats_file= fopen(passtmpfile, "wb");
-	if(stats_file==NULL){
-	    mp_msg(MSGT_MENCODER,MSGL_ERR,"2pass failed: filename=%s\n", passtmpfile);
-            return 0;
-	}
-	break;
     case 2:
+    case 3:
 	lavc_venc_context->flags|= CODEC_FLAG_PASS2; 
 	stats_file= fopen(passtmpfile, "rb");
 	if(stats_file==NULL){
@@ -661,6 +654,18 @@
 	    mp_msg(MSGT_MENCODER,MSGL_ERR,"2pass failed: reading from filename=%s\n", passtmpfile);
             return 0;
 	}        
+	if(lavc_param_vpass == 2)
+	    break;
+	else
+	    fclose(stats_file);
+	    /* fall through */
+    case 1: 
+	lavc_venc_context->flags|= CODEC_FLAG_PASS1; 
+	stats_file= fopen(passtmpfile, "wb");
+	if(stats_file==NULL){
+	    mp_msg(MSGT_MENCODER,MSGL_ERR,"2pass failed: filename=%s\n", passtmpfile);
+            return 0;
+	}
 	break;
     }
     }