[HEVC] x265.EXE: mingw builds

[LigH.de]

Comparing SSIM values in Decibels might be a little more intuitive (similar to Sone as subjective loudness).

[Mephesto]

x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.

How is a difference of 0.0024 15% percent?

Since the SSIM values are nearly identical. (scaling differences can make small difference look a lot larger then they are )
What about the file sizes? (Clearly with the same SSIM values, the file with the lower file size would be preferable)

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?

Don't know, I haven't looked at them side by side yet.

@Detmek: Doh, thanks! I always forget that 0.98 is twice as good as 0.96 and that that looks x% better is not really that objective.

"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...

Comparing SSIM values in Decibels might be a little more intuitive (similar to Sone as subjective loudness).

I don't find SSIM unintuitive at all. The rule of thumb is 0.99000+ is good quality and for cartoons/linear graphics 0.99500 is mandatory. Anything below 0.98000 can safely be dismissed as garbage which means you only need to double the bitrate to achieve 0.99000 perfection.

[p-v-p]

I've done another quality test, the first since I tried 1.0 back in May with disappointing results. 1.3 has really changed the game.

With the 720x320 music video, x265 beat x264 with an SSIM of 0.98374 vs x264's 0.98134, making it about 15% better objective quality.
The revolution is here, brothers and sisters. x265 has finally outclassed x264. Dunno if I'll be using it yet though, the speed was 1 fps for a 720x320 video. Jeez. 13 times slower. When I first got this i7 in 2010 it was a mother f**ing godsend that enabled me to encode 720p in realtime. No way in hell I'm going back to that mess I had with that Pentium D that was slow as shit despite being 4 GHZ.

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.

[Mephesto]

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.

[Gravitator]

it's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.

Hi,
HD ~15%, FHD ~30%, UHD ~50%.

[x265]

It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.

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

[Gravitator]

Here are the actual encoded video files...
Tears_400_x264.mp4
Tears_400_x265.mp4

Very cool and presentable

[Mephesto]

It's a good start but no regular guy will notice any quality improvements until x265 achieves 50% better efficiency.

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.

[x265]

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.

[Mephesto]

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)?

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,

Highly compressed? Nah, it's 5000 kb/s 1920x1080. About average I'd say.

I'll be glad to give any other information you need, including the videos themselves and the SSIM .CSVs.

[LigH.de]

Let's start with complete command line options for each encoder.

[LigH.de]

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.

[Gravitator]

Used x265_1.3+59 (x64) - Slices are still coming from the future.
Original sample > park_joy (mega.co.nz).

[Gravitator]

Who has the original sample "Kristen and Sara" ?

[El Heggunte]

Who has the original sample "Kristen and Sara" ?

I've sent you a P.M.

[Mephesto]

Let's start with complete command line options for each encoder.

Mine? x265:

avs2yuv exgf.avs -o - | x265 --y4m --crf 22.6 --preset veryslow --psy-rd 0.8 --psy-rdoq 1.0 -o exgf.hevc -

For x264 I don't have the commandline because this was done back in Nov. 2013. But as you can see, maximum settings except 8 refs, 16 merange and umh ME.

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

[El Heggunte]

build 1.3+95-93db2f53fe57

[El Heggunte]

build 1.3+114-795878af3973

[LigH.de]

RealDoll?

[El Heggunte]

RealDoll?

Nope, that's a CandyGirl:

http://en.wikipedia.org/wiki/CandyGirl

Saber Marionettes F.T.W. \o/

[LigH.de]

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.

[El Heggunte]

build 1.3+165-3fc141aa74b5

[Gravitator]

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" )

[LigH.de]

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-2fb61cc75152

[Gravitator]

So I wonder why you are complaining about what is a feature on purpose ...

So this is a problem in my settings or it is a feature of x265 crooked build frames?

[Gravitator]

x265 1.3+185-2fb61cc75152 - also not the right construction;
frame №87 (B) - shows a part of the umbrella comes from future frames.
Original sample > park_joy (mega.co.nz).

[LigH.de]

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.

[Gravitator]

But it makes me wonder if the original video already has interlacing or blending.

I always turn off the deinterlace mode: Auto (to encode a bit faster).

[Gravitator]

up to 16 cons. B frames, 16 Ref. frames

Maximum free choice for the encoder.

I:P ratio 1.7, P:B ratio 1.7

Just my eye pleasant.

[LigH.de]

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.