Comparing SSIM values in Decibels might be a little more intuitive (similar to Sone as subjective loudness).
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1,651 to 1,680 of 2222
Thread
-
-
Hah, Detmek beat me to it. It's great to see so many Russian speakers and someone from Serbia here btw. Welcome to the nuthouse, Detmek.
The file sizes are virtually the same so I didn't include them. But if you need to know, the music video is 6,600KB for the x264 output and 6564KB for x265, 1440 frames, 23.976 fps.
1948 and 1967 KB for the second vid. 2333 frames, 60 fps.
Also is there anything easy noticable different to the frames/scenes where x265 looses SSIM wise?
"Objective" means that it can be measured, not that the measurements mean anything important. Evaluating the quality visually would be the subjective quality analysis.
Yes, it's ******* confusing. The less accurate method is 'objective' while the better way is 'subjective' as if it's meaningless. The joys of the English language...
Originally Posted by Ligh.deLast edited by Mephesto; 28th Aug 2014 at 20:13.
-
I know it's shameless self-promotion basically, but that's why I created this in the first place. Give it a go and let me know what you think. Current release lacks of psy-rdoq, but it's on my to do list. Not exactly swarming with requests to add it.
Last edited by p-v-p; 29th Aug 2014 at 10:56.
-
p-v-p, I only use one computer so I don't need your program. Either way, my old Pentium D and Pentium 4 would only offer a 20% boost combined which isn't worth the double amount of power consumption.
Now that I got a look at the videos I can somewhat answer Selur's question. Frame 139 was the frame with the worst SSIM value difference, x265 getting 0.945 and x264 getting 0.962. I posted all 3 below. You decide what's better quality as I can't tell.
x264 preserved more high frequency details at the expense of the rest of the spectrum which left a lot of flat areas. x265 did not prioritize the high frequency details but preserved the low and medium frequency textures better, appearing somewhat more blurry than x264 but at the same time retaining distortion-free edges.
I think this is more a problem of x265 misallocating proper bitrate to some areas that might need it.
In general, x265 output throughout the video looks a little better, sort of like a good wavelet codec actually. There is none of the typical macroblock artifacts and noise/distortion around edges as with x264 so it's more pleasant on the eyes. The imperfections are difficult to spot without the source for comparison. With x264 they're obvious.
It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency. -
Last edited by Gravitator; 30th Aug 2014 at 10:07.
-
Mephesto,
What is your x265 command-line? I recommend using --preset slow, slower or veryslow preset. Add --psy-rd 0.8 --psy-rdoq 1.0 for low bit rates. You can increase these values for higher bit rates. For x264 I just use --preset veryslow. We regularly produce x265 encodes that look better than x264 encodes at twice the bitrate.
For example, here is an encode I did last week of "Tears of Steel" (1080P lossless YUV encoded from lossless PNG image sequence). The settings used are shown here.
Here are the actual encoded video files...
Tears_400_x264.mp4
Tears_400_x265.mp4
-
That is indeed impressive, but I did exactly what you said just now and the x265 output scored a little better in SSIM but visually they still only marginally outclass x264. This video is only 720x320 though so maybe it isn't as efficient here. But H264 was designed for 720p and above when it came out but it still competed with XVID at half the bitrate on any resolution. So I pray x265 will be great for things besides UHD as well.
I'd test HD stuff too but I'm only getting 1 fps on this 320p video so I seriously don't have the patience. -
We would need to know more information in order to help you. Can you tell us more about your source video (bit rate, quality, type of content, etc.)? Can you share your full command-line, and your results (bit rate, speed, PSNR or SSIM measurements)?
If your source is already highly compressed, I'm guessing that you want x265 to shrink your video further (maybe by half) without a noticeable loss in quality. For this your best bet would either be constant rate factor (CRF) mode, or 2 pass ABR. Each delivers similar quality. CRF (with veryslow preset) is slightly faster than 2 pass ABR . 2 pass ABR has the advantage of giving you the ability to specify a target bit rate. So you can set --bitrate in x265 to half the value of your source video, and you'll probably be happy with the result. -
I already posted all that information in the prior posts.
What I didn't mention was that the first video was sourced from a 1080p x264-compressed video. That is why I resized it to 720x320. I would never use an already-compressed video as a valid source.
If your source is already highly compressed,
I'll be glad to give any other information you need, including the videos themselves and the SSIM .CSVs. -
Let's start with complete command line options for each encoder.
-
x265 1.3+58-c5624effb73c backed out a possibly incomplete bugfix regarding B-frame bitrate prediction in VBV, causing problems in CBR mode, but re-enabled and fixed --cu-lossless.
-
Mine? x265:
Code:avs2yuv exgf.avs -o - | x265 --y4m --crf 22.6 --preset veryslow --psy-rd 0.8 --psy-rdoq 1.0 -o exgf.hevc -
Code:cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=11 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=240 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00
-
Last edited by El Heggunte; 6th Sep 2014 at 09:53.
-
After so many recent patches with speed-ups and fixes, now is probably a good time to release another build: x265 1.3+145-44cb33846e0e
Unfortunately, most speed-ups seem to be relevant only for AVX2 supporting CPUs, which I don't own... but a few are also rather generic. -
Earlier I wrote about the remark of contact with pieces of frames from the following frames > Slices of the future
- Similar description for the codec VP9 > @zerowalker ("green pig" ) -
In general, it is not wrong for B frames to have slices with references to future P or I frames. That's exactly the purpose of B frames: To optimize size by referencing most similar sources with bidirectional prediction. So I wonder why you are complaining about what is a feature on purpose ... except it goes wrong in a way that it introduces annoying compression artefacts, then it would be a bug to be fixed.
__
P.S.:
Another "merge with stable" plus a few fixes — x265 1.3+185-2fb61cc75152Last edited by LigH.de; 15th Sep 2014 at 03:55.
-
-
I'll have to analyze your original video first and check if I can reproduce such artefacts... But it makes me wonder if the original video already has interlacing or blending. If x265 works correctly, then it should calculate that this is not a best-matching refrence.
Your complete x265 command line may be useful to reproduce it.
I see a pink flickering at the end of your MKV sample. A good hint that this is not intended.
__
P.S.: I am not good at interpreting a Hybrid preset; but the bits I do understand make me wonder if you are going for a codec overkill: up to 16 cons. B frames, 16 Ref. frames, I:P ratio 1.7, P:B ratio 1.7 ... yes, you are trying to force many B frames. But what is it good for?
__
OK, tested a bit.
Only 6800 kbps for 1080p is little. It provokes quantization factors around 40 sometimes. With so much pressure, the encoder has no chance but to use even vaguely similar parts, even of future scenes, to spare bitrate, and thus has no choice but messes with the chrominance.
This test is way too extreme.Last edited by LigH.de; 15th Sep 2014 at 07:20.
-
-
up to 16 cons. B frames, 16 Ref. frames
I:P ratio 1.7, P:B ratio 1.7 -
Hey, even preset "placebo" uses only max. 8 consecutive B frames and max. 5 references to choose from. Your set is even more a waste of time, way too much choice for the encoder, yet too little bitrate to be able to reproduce the original video satisfyingly.
Your set is the proof that no combination of any other options can substitute enough bitrate.
__
P.S.:
What you call "future references" seems to me like a preference of weighted B frames (generating blends) over motion vectors. Now that is indeed a point to discuss with the developers. The reconstruction appears to have blends which don't exist in the original video.
By the way, Derf's 1080p Y4M source is a lot more detailed than the ProRes file. But also has a longer playing time (the ProRes MOV only has the last 2 of 10 seconds from the Y4M), a download of 1483 MB.Last edited by LigH.de; 15th Sep 2014 at 07:54.
Similar Threads
-
help - how to compile latest "nightly" ffmpeg for win32 (XP) with mingw
By hydra3333 in forum ProgrammingReplies: 32Last Post: 20th May 2017, 00:33 -
x265 vs x264
By deadrats in forum Video ConversionReplies: 71Last Post: 10th Jan 2016, 06:14 -
ffdcaenc (an upgrade to dcaenc)
By El Heggunte in forum AudioReplies: 22Last Post: 9th Dec 2014, 06:09 -
MulticoreWare Annouces x265/HEVC Mission Statement
By enim in forum Latest Video NewsReplies: 4Last Post: 9th Aug 2013, 22:09 -
New PC Build(s)
By thedeificone in forum ComputerReplies: 6Last Post: 25th May 2010, 16:57