Log in

View Full Version : Fast Encoding Options in x264


Redhat_doom
22nd May 2009, 00:53
Hi,

I am trying to test the speed of different encoding options in x264.

1-First, I tried to see the effect of the number of reference frames. I got the following results for a 1280x800 video sequence, 25fps, 250 frames:

--ref 1 -> Average PSNR Y=40.79dB, Average fps= 9.7
--ref 2 -> Average PSNR Y=40.41dB, Average fps= 9.2
--ref 3 -> Average PSNR Y=40.80dB, Average fps= 8.8
--ref 4 -> Average PSNR Y=40.76dB, Average fps= 8.6
But it is strange for me. I expect to see higher PSNR values when using more ref frames. Unfortunately I cannot distinguish between the visual quality of the above cases. But what is the reason of it?

2- Is there any option for disabling/Enabling 8x16 and 8x16 macroblock partitions?

3- I used "--no-chroma-me". The encoding speed was increased but the average PSNR was decreased a little!! So, what is the reason of it?
Thanks!

thewebchat
22nd May 2009, 03:37
1) You take PSNR measurements too seriously. PsyOPs work negatively against AQ.

2) No idea.

3) This should be obvious. --no-chroma-me disables checking the chroma during motion estimation, so less accurate motion vectors were found and the quality goes down.

Also: you never posted your settings, particularly your rate control method.

Sharktooth
22nd May 2009, 03:57
the reason is PSNR is not an index of quality. plain and simple.

burfadel
22nd May 2009, 04:30
You haven't shown your other settings! In CRF mode, you should end up with slightly smaller files. In 2-pass mode (one pass CBR should be avoided if possible, its only good for real time streamng as far as I see it), the improved encoding efficiency will be put in to quality. realistically, unless you need it for a compatibility thing around 5 ref frames is a good balance between encoding speed and end file size/quality for most materials. Animation may benefit from using a higher reference frame number.

Redhat_doom
22nd May 2009, 04:42
Here is my settings:

x264 --bitrate 200 --ref x --mixed-ref --psy-rd 0:0 test.yuv -o test.264 1280x800

where x=1,2,3,4 and the video has 250 frames (25fps).

and I got the following results:

--ref 1 -> Average PSNR Y=28.76dB, Average fps= 11.90
--ref 2 -> Average PSNR Y=28.69dB, Average fps= 11.68
--ref 3 -> Average PSNR Y=28.77dB, Average fps= 11.26
--ref 4 -> Average PSNR Y=28.68dB, Average fps= 11.10

We expect to see an increasing trend in PSNR as we increase the number of ref. frames. But as you can see from the above results there is no such a trend! I know that PSNR is not a good metric but we must at least see a little increase in PSNR as we increase the number of ref frames. I also tried other bit rates and I got similar results. But what is the problem?

ajp_anton
22nd May 2009, 05:24
How long is your test clip?

burfadel
22nd May 2009, 05:34
There's not necessarily a problem, see if SSIM changes?... also it depends on the source material!

Redhat_doom
22nd May 2009, 05:36
How long is your test clip?

250 frames, 25 fps.

Redhat_doom
22nd May 2009, 05:56
Regarding SSIM I got the followin results:

--ref 1 -> Average PSNR Y=28.76dB,SSIM=0.9003364, Average fps= 11.90
--ref 2 -> Average PSNR Y=28.69dB,SSIM=0.8999750, Average fps= 11.68
--ref 3 -> Average PSNR Y=28.77dB,SSIM=0.9004882, Average fps= 11.26
--ref 4 -> Average PSNR Y=28.68dB,SSIM=0.9000956, Average fps= 11.10

Now, what is your interpretation?

Redhat_doom
22nd May 2009, 06:20
also it depends on the source material!

OK, someone say that for animated content, more reference frames are useful. But does anyone have a sample animated clip to show this issue in practice? I need a YUV file format. Thanks!

Redhat_doom
22nd May 2009, 08:07
I repeated the same experiments to see the influence of "--partition". Here is the results:

x264 --bitrate 200 --partition "x" --psy-rd 0:0 test.yuv -o test.264 1280x800

where x is a subset of "p4x4,p8x8,i4x4,i8x8". The input video has 250 frames, 25fps.

"p8x8" -> PSNR mean Y: 28.61dB
"i8x8,p8x8"-> PSNR mean Y: 28.61dB
"i4x4,p8x8"-> PSNR mean Y: 28.76dB
"i4x4,i8x8,p8x8"-> PSNR mean Y: 28.76dB
"p4x4,p8x8"-> PSNR mean Y: 28.64dB
"p4x4p,p8x8,i8x8"-> PSNR mean Y: 28.64dB
"p4x4,p8x8,i4x4"-> PSNR mean Y: 28.71dB
"p4x4,p8x8,i4x4,i8x8"-> PSNR mean Y: 28.71dB

Again, I cannot see any significant difference between these options! So weired! What do you think? Thanks.

Irakli
22nd May 2009, 12:46
Again, I cannot see any significant difference between these options! So weired! What do you think? Thanks.

What about the visual differences in quality? Are there any? if you don't see any difference between fast and slow settings, then why not just use fast settings?

Regards,
Irakli

nm
22nd May 2009, 13:09
You are comparing short clips with 1-pass ABR. Did you check the resulting bitrates? For meaningful results, use 2-pass encoding and maybe a bit longer sequences, if possible (1000 frames would be ok).

LoRd_MuldeR
22nd May 2009, 13:45
OK, someone say that for animated content, more reference frames are useful. But does anyone have a sample animated clip to show this issue in practice?

Here is one animated sample:
http://mirror05.x264.nl/Dark/LosslessAzumanga.mkv

It's not YUV, but lossless H.264. So you will need to use Avisynth with FFmpegSource() to feed that into x264.

You may also want to have a look at this sample:
http://forum.doom9.org/showpost.php?p=1288446&postcount=47

ajp_anton
22nd May 2009, 15:08
The random variations due to the 1-pass bitrate mode and the test clip being so short are hiding all quality improvements from better settings.
Use 2-pass and a longer test clip.

Redhat_doom
22nd May 2009, 18:35
Here is one animated sample:
http://mirror05.x264.nl/Dark/LosslessAzumanga.mkv

It's not YUV, but lossless H.264. So you will need to use Avisynth with FFmpegSource() to feed that into x264.

You may also want to have a look at this sample:
http://forum.doom9.org/showpost.php?p=1288446&postcount=47

Thanks! I used the first animated video and I obtained the following results which seem to be a little reasonable:

x264 --bitrate 200 --pass 2 --ref x --mixed-ref test.yuv -o test.264 640x480

where x=1,2,3,4,5,6 and the video has 2695 frames (25fps).

ref 1 -> PSNR mean Y: 36.66dB
ref 2 -> PSNR mean Y: 37.08dB
ref 3 -> PSNR mean Y: 37.53dB
ref 4 -> PSNR mean Y: 37.66dB
ref 5 -> PSNR mean Y: 37.83dB
ref 6 -> PSNR mean Y: 37.95dB

However, I still cannot distingish between the visual quality of the above cases!
1- Do you know any better setting to see this visual quality difference better?

2- Do you know why animated content needs more reference frames?

3- I tried to investigate the effect of "--partition". I think "p8x8" and "p8x8,i8x8" are equall. Right? Because if we use only "p8x8" then x264 must use the default setting for I-frames which is "i8x8" and so cases like "p8x8" and "p8x8,i8x8" are equall. Am I right?

Sagittaire
22nd May 2009, 23:52
the reason is PSNR is not an index of quality. plain and simple.

well like always ... how work ref decision for x264 ... certainely with psnr metric ...

Like always Sharktooth think that x264 work with magical tools ... and like always it's ridiculous ...

more ref with or without psy must optimize the psnr result at same size.

Sagekilla
22nd May 2009, 23:55
If you can't see a difference, then that means a PSNR of 36.66 dB (for luma anyway) is transparent for that source for you. In other words, it means you can use higher refs with lower bitrate to get the same quality but smaller file size.

Redhat_doom
23rd May 2009, 00:03
If you can't see a difference, then that means a PSNR of 36.66 dB (for luma anyway) is transparent for that source for you. In other words, it means you can use higher refs with lower bitrate to get the same quality but smaller file size.

Yes, but the problem is that I used the two pass encoding mode and when I try to use lower bitrates (say 100k instead of 200) it returns this error:

x264 [warning]: Error: 2pass curve failed to converge

or

x264 [error]: requested bitrate is too low. estimated minimum is 101 kbps.

So, what is the wrong?

kemuri-_9
23rd May 2009, 01:02
Yes, but the problem is that I used the two pass encoding mode and when I try to use lower bitrates (say 100k instead of 200) it returns this error:
x264 [warning]: Error: 2pass curve failed to converge
or
x264 [error]: requested bitrate is too low. estimated minimum is 101 kbps.
So, what is the wrong?

from my understanding,
those messages appear whenever ratecontrol can't accept the given bitrate for either of the following reasons:
A. too low bitrate and too low QPmax (can't quantize high enough to make low desired bitrate)
B. too high bitrate and too high QPmin (can't quantize low enough to spend desired high bitrate)

for
A. you need to raise the qpmax
(the default is 51, so if you're running into this, you're really pushing down the bitrate - likely way too much)
B. you need to lower the qpmin
(the default is 10, so if you're running into this, you should be already be in the transparent range and could lower the bitrate instead)

Rumbah
23rd May 2009, 03:40
Well, you are trying to encode at a resolution of 1280x800 with a bitrate of 100kbps? For most sources that is just too low like the error message says.
In that case you would better try to resize your source or change the framerate (skip frames).

Redhat_doom
23rd May 2009, 06:17
Well, you are trying to encode at a resolution of 1280x800 with a bitrate of 100kbps? For most sources that is just too low like the error message says.
In that case you would better try to resize your source or change the framerate (skip frames).

No, I am using higher bit rates but since I cannot see any visual quality difference between different settings (such as the number of the reference frames) at higher bit rates such as 200k, so I decided to use lower bit rates so that I can see this difference better.

LoRd_MuldeR
23rd May 2009, 10:48
That makes sense. But at some point the bitrate is simply too low to see anything (or the encoder will fail to encode at that bitrate).
200 kbps already is a very low bitrate for HD content, like 1280x800. If you don't see the differences yet, there maybe are no significant differences.

Also adding more refs doesn't necessarily help with all sources! And for each source there is the point where adding even more refs won't improve the result any further.
Try to look at x264's output to see how many reference frames it actually used for your current source...

x264 [info]: ref P L0 48.6% 9.0% 8.3% 4.7% 4.3% 3.6% 3.4% 2.4% 1.9% 2.1% 1.8% 1.9% 1.8% 2.6% 1.8% 1.8%
x264 [info]: ref B L0 49.4% 13.3% 8.4% 5.8% 4.7% 3.5% 2.7% 2.0% 1.5% 1.4% 1.6% 2.0% 1.6% 1.4% 0.8%
x264 [info]: ref B L1 90.7% 9.3%

nm
23rd May 2009, 11:00
ref 1 -> PSNR mean Y: 36.66dB
ref 2 -> PSNR mean Y: 37.08dB
ref 3 -> PSNR mean Y: 37.53dB
ref 4 -> PSNR mean Y: 37.66dB
ref 5 -> PSNR mean Y: 37.83dB
ref 6 -> PSNR mean Y: 37.95dB

However, I still cannot distingish between the visual quality of the above cases!
Well, I checked ref 1 and ref 6 encodings with the same source and your settings. I can see a clear difference in some scenes, like the red-yellow logo at the beginning. This was on normal playback, I didn't even watch the two videos at the same time or switch between still frames.

1- Do you know any better setting to see this visual quality difference better?
If you can't see it otherwise, capture every 100th frame or so from all clips and compare by switching between the frames in some image viewer.

2- Do you know why animated content needs more reference frames?
It doesn't need more references, it just benefits more from them. Animation, and especially anime, often has looped elements where the same sequence of images is cleanly repeated few times over. I'd guess that multiple references help encoding these kind of scenes more efficiently.

Redhat_doom
24th May 2009, 02:53
Well, I checked ref 1 and ref 6 encodings with the same source and your settings. I can see a clear difference in some scenes, like the red-yellow logo at the beginning. This was on normal playback, I didn't even watch the two videos at the same time or switch between still frames.

Thanks! I actually see a very little viusal quality difference between the two cases (I compared the red-yellow logo in each case) but not too much!! Did you obtain the same PSNR values?

Redhat_doom
24th May 2009, 03:05
That makes sense. But at some point the bitrate is simply too low to see anything (or the encoder will fail to encode at that bitrate).
200 kbps already is a very low bitrate for HD content, like 1280x800. If you don't see the differences yet, there maybe are no significant differences.

Also adding more refs doesn't necessarily help with all sources! And for each source there is the point where adding even more refs won't improve the result any further.
Try to look at x264's output to see how many reference frames it actually used for your current source...

x264 [info]: ref P L0 48.6% 9.0% 8.3% 4.7% 4.3% 3.6% 3.4% 2.4% 1.9% 2.1% 1.8% 1.9% 1.8% 2.6% 1.8% 1.8%
x264 [info]: ref B L0 49.4% 13.3% 8.4% 5.8% 4.7% 3.5% 2.7% 2.0% 1.5% 1.4% 1.6% 2.0% 1.6% 1.4% 0.8%
x264 [info]: ref B L1 90.7% 9.3%

command:
x264 --bitrate 200 --pass 2 --ref 6 --mixed-ref test.yuv -o test.264 1280x800

Here is the results:

x264 [info]: ref P L0 57.5% 15.5% 11.6% 5.1% 4.7% 5.7%

Now, what is your interpertation? Thanks!

nm
24th May 2009, 10:33
Thanks! I actually see a very little viusal quality difference between the two cases (I compared the red-yellow logo in each case) but not too much!!
Maybe you are just expecting too much. :)

Did you obtain the same PSNR values?
Well, you should be looking at SSIM and Global PSNR, but looks like I got higher values with x264 r1153 (on 64-bit Linux). For example in the ref=1 case:x264 --bitrate 200 --pass 1 --ref 1 --mixed-refs

x264 [info]: SSIM Mean Y:0.9768622
x264 [info]: PSNR Mean Y:37.459 U:43.147 V:42.097 Avg:38.484 Global:35.970 kb/s:200.28


x264 --bitrate 200 --pass 2 --ref 1 --mixed-refs

x264 [info]: SSIM Mean Y:0.9805560
x264 [info]: PSNR Mean Y:37.330 U:42.839 V:41.732 Avg:38.339 Global:36.880 kb/s:201.50

Without psy-rd:
x264 --bitrate 200 --pass 1 --ref 1 --mixed-refs --psy-rd 0:0

x264 [info]: SSIM Mean Y:0.9785656
x264 [info]: PSNR Mean Y:37.859 U:42.614 V:41.562 Avg:38.714 Global:36.250 kb/s:200.40


x264 --bitrate 200 --pass 2 --ref 1 --mixed-refs --psy-rd 0:0

x264 [info]: SSIM Mean Y:0.9821093
x264 [info]: PSNR Mean Y:37.742 U:42.317 V:41.199 Avg:38.583 Global:37.156 kb/s:201.47

LoRd_MuldeR
24th May 2009, 12:04
command:
x264 --bitrate 200 --pass 2 --ref 6 --mixed-ref test.yuv -o test.264 1280x800

Here is the results:

x264 [info]: ref P L0 57.5% 15.5% 11.6% 5.1% 4.7% 5.7%

Now, what is your interpertation? Thanks!

It means that in 85% of all cases x264 used three or less ref-frames for the P-Frames. So when allowing even more than three ref-frames, you can expect only a subtle improvement.

BTW: Any reason why you disabled B-Frames ??? :eek:

Redhat_doom
24th May 2009, 17:38
BTW: Any reason why you disabled B-Frames ??? :eek:

Thanks! Because I am working on a real-time application, and so working with B-frames is not a good idea since they add much more delay to our system. Am I right?

LoRd_MuldeR
24th May 2009, 17:45
Thanks! Because I am working on a real-time application, and so working with B-frames is not a good idea since they add much more delay to our system. Am I right?

Well, allowing up to n consecutive B-Frames requires the encoder to buffer at least n+1 input frames before the first frame can be returned. But x264 needs to buffer frames anyway, if you want to make use multi-threading! Also I think B-Frames speed-up multi-threading and the offer much better compression efficiency...

Redhat_doom
24th May 2009, 18:10
Well, allowing up to n consecutive B-Frames requires the encoder to buffer at least n+1 input frames before the first frame can be returned. But x264 needs to buffer frames anyway, if you want to make use multi-threading! Also I think B-Frames speed-up multi-threading and the offer much better compression efficiency...

Yes, you are right but unfortunately we cannot use B-frames due to some problems :)

One more question: what is the meaning of the following stats?

x264 [info] mb I I16..4: 81.2% 0.0% 18.8%
x264 [info] mb P I16..4: 3.0% 0.0% 1.3% P16..4: 10.8% 2.2% 1.4% 0.0% 0.0% skip:81.3%
Thanks!