Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd May 2009, 00:53   #1  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Fast Encoding Options in x264

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:

Code:
--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!
Redhat_doom is offline   Reply With Quote
Old 22nd May 2009, 03:37   #2  |  Link
thewebchat
Advanced Blogging
 
Join Date: May 2009
Posts: 483
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.
thewebchat is offline   Reply With Quote
Old 22nd May 2009, 03:57   #3  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
the reason is PSNR is not an index of quality. plain and simple.
Sharktooth is offline   Reply With Quote
Old 22nd May 2009, 04:30   #4  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 1,989
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.
burfadel is offline   Reply With Quote
Old 22nd May 2009, 04:42   #5  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Here is my settings:

Code:
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:

Code:
--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?

Last edited by Redhat_doom; 22nd May 2009 at 05:36.
Redhat_doom is offline   Reply With Quote
Old 22nd May 2009, 05:24   #6  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 747
How long is your test clip?
ajp_anton is offline   Reply With Quote
Old 22nd May 2009, 05:34   #7  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 1,989
There's not necessarily a problem, see if SSIM changes?... also it depends on the source material!
burfadel is offline   Reply With Quote
Old 22nd May 2009, 05:36   #8  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Quote:
Originally Posted by ajp_anton View Post
How long is your test clip?
250 frames, 25 fps.
Redhat_doom is offline   Reply With Quote
Old 22nd May 2009, 05:56   #9  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Regarding SSIM I got the followin results:

Code:
--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 is offline   Reply With Quote
Old 22nd May 2009, 06:20   #10  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Quote:
Originally Posted by burfadel View Post
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 is offline   Reply With Quote
Old 22nd May 2009, 08:07   #11  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
I repeated the same experiments to see the influence of "--partition". Here is the results:

Code:
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.

Code:
"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.
Redhat_doom is offline   Reply With Quote
Old 22nd May 2009, 12:46   #12  |  Link
Irakli
Registered User
 
Irakli's Avatar
 
Join Date: Jan 2007
Posts: 185
Quote:
Originally Posted by Redhat_doom View Post
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
Irakli is offline   Reply With Quote
Old 22nd May 2009, 13:09   #13  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,643
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).
nm is offline   Reply With Quote
Old 22nd May 2009, 13:45   #14  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,756
Quote:
Originally Posted by Redhat_doom View Post
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?...6&postcount=47
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 22nd May 2009, 15:08   #15  |  Link
ajp_anton
Registered User
 
ajp_anton's Avatar
 
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 747
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.
ajp_anton is offline   Reply With Quote
Old 22nd May 2009, 18:35   #16  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Quote:
Originally Posted by LoRd_MuldeR View Post
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?...6&postcount=47
Thanks! I used the first animated video and I obtained the following results which seem to be a little reasonable:

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

Code:
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?
Redhat_doom is offline   Reply With Quote
Old 22nd May 2009, 23:52   #17  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,397
Quote:
Originally Posted by Sharktooth View Post
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.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 22nd May 2009, 23:55   #18  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
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.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 23rd May 2009, 00:03   #19  |  Link
Redhat_doom
Registered User
 
Join Date: Jan 2009
Posts: 65
Quote:
Originally Posted by Sagekilla View Post
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:
Code:
x264 [warning]: Error: 2pass curve failed to converge
or

Code:
x264 [error]: requested bitrate is too low. estimated minimum is 101 kbps.
So, what is the wrong?
Redhat_doom is offline   Reply With Quote
Old 23rd May 2009, 01:02   #20  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by Redhat_doom View Post
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)
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:04.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.