[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