[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec mpegvideo.c, 1.503, 1.504 mpegvideo.h, 1.234, 1.235 h263.c, 1.298, 1.299

Corey Hickey bugfood-ml
Sat Feb 4 01:47:55 CET 2006


Corey Hickey wrote:
>>>>Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
>>>>In directory mail:/var2/tmp/cvs-serv26933
>>>>
>>>>Modified Files:
>>>>	mpegvideo.c mpegvideo.h h263.c 
>>>>Log Message:
>>>>fixing bframe strategy 2
>>>> bits vs. bytes factor of 8 error
>>>> 16 byte offset error
>>>> some other minor things
>>>
>>>
>>>This shows a large improvement over my previous vb_strategy=2 tests and
>>>nets a significant (but a bit varied) improvement. First, my base command:
>>>
>>>for i in 1:turbo 2 ; do
>>> mencoder matrix.vob -aid 128 -oac copy -vf \
>>>crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc -lavcopts \
>>>vcodec=mpeg4:vbitrate=581:psnr:vpass=$i:mbd=2:mv0:trell:cbp:\
>>>precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\
>>>last_pred=2:vqcomp=0.6:qpel:sc_factor=6 -ofps 24000/1001 -o test.avi
>>>done
>>
>>
>>could you rerun the vmax_b_frames=2 vb_strategy=0 and 2 brd_scale=0 without
>>turbo mode? the reason why that could be interresting is that the b frame
>>decission is done only in first pass
> 
> 
> Ok, here are some results without turbo. You can compare them to the
> ones with turbo I sent previously.
> 
> ----
> vmax_b_frames=2:vb_strategy=0
>   pass 1:
> PSNR: Y:41.30, Cb:44.86, Cr:45.29, All:42.23
> user    190m14.814s
>   pass 2:
> PSNR: Y:42.16, Cb:45.20, Cr:45.92, All:43.02
> user    187m23.822s
> frame counts: I:   3461  1%  P:  61895 31%  B: 130710 66%
> average qps:  I: 2.619763    P: 2.876145    B: 5.117818
> 
> Removing turbo gives this +0.05 dB PSNR and, on average, a very very
> slight visual quality improvement. Nothing looked significantly better
> or significantly worse.
> 
> 
> ----
> vmax_b_frames=2:vb_strategy=2:brd_scale=0
>   pass 1:
> PSNR: Y:41.44, Cb:44.89, Cr:45.36, All:42.35
> user    482m23.198s
>   pass 2:
> PSNR: Y:42.23, Cb:45.21, Cr:45.94, All:43.08
> user    183m23.120s
> frame counts: I:   3450  1%  P:  71906 36%  B: 120710 61%
> average qps:  I: 2.655072    P: 3.014825    B: 5.098998
> 
> This encode gets +0.04 dB PSNR. The visual quality improvement is slight
> but substantial; aside from a few frames, this one looks consistantly
> better. Of course, the first-pass encoding time is rather drastic. An
> interesting thing to note is that this encode uses 5% more B-frames than
> the one with turbo did. The number of I-frames is almost the same (6
> frames more without turbo).
> 
> 
> ----
> vmax_b_frames=3:vb_strategy=0
>   pass 1:
> PSNR: Y:41.17, Cb:44.85, Cr:45.27, All:42.12
> user    200m11.908s
>   pass 2:
> PSNR: Y:42.07, Cb:45.20, Cr:45.93, All:42.96
> user    198m23.891s
> frame counts: I:   3449  1%  P:  45569 23%  B: 147048 74%
> average qps:  I: 2.514642    P: 2.810090    B: 5.057750
> 
> This one gets +0.07 dB PSNR. It looks a lot better than the counterpart
> encode without turbo, but not quite as good as
> vmax_b_frames=2:vb_strategy=0:turbo.
> 
> 
> ----
> vmax_b_frames=3:vb_strategy=2
>   pass 1:
> PSNR: Y:41.45, Cb:44.92, Cr:45.40, All:42.37
> user    729m40.550s
>   pass 2:
> PSNR: Y:42.25, Cb:45.24, Cr:45.99, All:43.11
> user    188m33.290s
> frame counts: I:   3424  1%  P:  65680 33%  B: 126962 64%
> average qps:  I: 2.607185    P: 3.043849    B: 5.030922
> 
> This one takes the crown PSNR-wise, with a +0.07 dB increase over using
> turbo. Compared to vmax_b_frames=2:vb_strategy=2:brd_scale=0 (without
> turbo), though, it doesn't really look better. Some parts looked a bit
> better and some looked worse, but, on average they both looked about the
> same.

*sigh*

The "ondemand" CPU frequency governor seems to be giving me trouble; it
stuck my CPU at a lower frequency even during 100% CPU usage. It did
this once before....

Anyway, the user times I reported for the tests with vmax_b_frames=2 are
incorrect. I did the tests with vmax_b_frames=3 first, so they weren't
affected.

In order to keep the numbers within their proper context, I've adjusted
the user times listed above in the quoted part of this email.

-Corey





More information about the ffmpeg-cvslog mailing list