PDA

View Full Version : encode with some profilesand Which file I should choose ?


thuongshoo
30th July 2006, 11:31
I encoded a file with some profiles by Megui. This is my result
--cfr 26
psnr bitrate filesize time(second)
default 40.725 1573kb/s 35.840MB 2969
default-qmin1 40.725 1573kb/s 35.840MB 2979
default-qmin1-subme6-me.umh 40.772 1508kb/s 34.365MB 4174
default-qmin1-subme7-me.umh 40.292 1496kb/s 34.077MB 4840



profile1 0 0 0
profile2 0 0% +0.003%
profiles2 +0.115% -4.115% +40.5%
profiles3 +1.06% -4.919% +63.017%
Should I choose last file to save on harddisk ? its psnr is the lowest. I have just also tested another file. I found that subme7 and me.umh give me a smaller file but psnr also smaller ( 0.3dB) , time need to encode will increase 40-60%.
*A question:
if x264 says that 50 dB, does it mean that quality of encoded file is smaller than orginal file by 2 times ?
Thanks !

GodofaGap
30th July 2006, 12:42
if x264 says that 50 dB, does it mean that quality of encoded file is smaller than orginal file by 2 times ?
No, PSNR is a logarithmic scale. A perfect score would be infinite. You cannot scale a PSNR score to subjective scores like great, good or reasonable, at best you could use it to say if something is really bad or not. Neither can you use PSNR to say A is X times better than B.

foxyshadis
30th July 2006, 13:41
A crf 26 file will usually never even use 10 - for instance, on a crf 26 file I have here, the lowest used is q15, on a run of pure black frames. So qmin 1 is pointless, it's something you raise, not lower, but it's worth trusting x264 over.

A general rule of thumb is that a 1db psnr difference is visible, but psnr is such a bad metric that it's hardly reliable. At the least, use ssim.

Comparing identical frames with psnr, btw, is 100db.

Manao
30th July 2006, 13:43
psnr = 10 * log( 255 * 255 / ( average_error * average_error ) ).

That means that a PSNR of 50 dB amount to an average error of 0.8 ( ie, if you take the original video, and add on all pixels either +0.8 or -0.8, you'd get a PSNR of 50 dB ). That's considered to be a very good quality. For example, transparency is around 55 dB. 50 dB means you might notice a small loss of grain / detail, but you wouldn't know that the video wasn't the original if you didn't have the original.

Milestones for PSNR are roughly :
- 55 dB : transparency
- 50 dB : very good ( imho an overkill, you shouldn't target such a quality, it's a waste of bits )
- 40-45 dB : quality that ought to be targetted for most cases. Only reason not to do so would be a strong bitrate constraint ( or having really too much space )
- 35 : low quality
- 30 : barely watchable

However, some things are important to remember :
- the bigger the resolution, the lower the PSNR can be for the quality to be acceptable
- the more detailed the video, the lower the PSNR can be for the quality to be acceptable ( that's less obvious, but lots of details means it'll be difficult to render them properly. Yet, the eyes mostly won't notice that details is not exactly where it should have been, or how it should have been - as long as they don't compare too closely to the original ). Some highly detailed videos will have a good quality with a PSNR 35 for example. However, those cases scarcely happen, especially when you consider DVD ripp ( DVD aren't detailed imho ).

Finally, thuongshoo, I can't emphasize enough that when you try some settings to see which ones are the most interesting, you must take both quality ( psnr / eyes ) and bitrate into account. Bitrate alone won't say if the option you tried is worthy enough. Most options have an effect both on bitrate on quality, and though some manage the reduce the bitrate and increase the quality ( which is good ), most of them either reduce the bitrate / reduce the quality or increse the bitrate / increase the quality. You must, as much as possible, manage to make either the quality or the bitrate a constant in your tests. And the only way to do so is to do a two passes encoding, to get a constant filesize ( you can't make quality a constant with x264 ).

And since the difference in quality when you enable / disable an option is quite small, only PSNR will be able to tell you the difference, the eyes won't. So, even though PSNR isn't reliable because hardly related to what the eyes perceive, it's still the "best" tool to check whether an option is worthy or not/

Comparing identical frames with psnr, btw, is 100db.That's because somewhere in the code, there's a "if average error == 0, psnr = 100".

thuongshoo
1st August 2006, 09:58
Thank All ! Now, I havenot known all words yet but I will read all .
I often use --cfr 26 . Quality of encoded file is often acceptable . I have also some mpeg file which can't encode with 26 . Quality of these file aren't good . I can see the difference easily. Yes ! psnr is about 37dB but some are good but some aren't good

Sharktooth
2nd August 2006, 04:35
use --crf 24 or lower (filesize will grow though)

thuongshoo
3rd August 2006, 17:59
I have just done ssim. ssim of small file is smaller than big file , 82.3 < 84 84.8 .
Perhaps using bframe , subme and me.umh if we want to have small files and in regardless of quality and time . Right ?

thuongshoo
7th August 2006, 12:59
my conclusion:
- multihex and subme 7 will decrease psnr and take us a lot of times
- refrenceref 16 is better than ref5 but speed will decrease 2 times

my hope:
- all options which take me time will give me a smaller file and higher psnr :)

Edit : reference frame 16 is better than ref5 but speed will increase 2 times

thuongshoo
14th August 2006, 11:18
my new discovery :
- multihex and subme 7 is actually useful if source is mpeg . If source file is wmv, these option only waste my time