Comparisons of x265 vs x264 [Archive]

sneaker_ger

5th August 2014, 19:47

Since it has been asked to move comparisons of x265 vs other codecs out of the main x265 thread I'm starting this one.

I used a low quality, grainy, blockbuster source with about 8 Mbit/s as the output bitrate (x265 --crf 21). If you substract some bitrate because of this being a trailer with many scenecuts you come into a region often used for Blu-Ray-rips. This test uses the new psy features of x265 (still experimental). I haven't written down the fps, just believe me when I say it was too slow for encoding complete films.

My subjective conclusion:
x264 is still ahead in this test though both would be transparent under normal viewing conditions. Since they aren't too different I wouldn't be surprised if others were to come to a different conclusion.

Original (dl (https://mega.co.nz/#!tk9RwKIZ!1XAR_PuUEo4C6ld9MfUOfU_nLDCWc5D2Sd4XjBpB6M8))
x264 8bit r2452 --preset placebo --tune grain (2pass) (dl (https://mega.co.nz/#!01MjxRqB!pPllknkKrvOQuO4l9Yg4ZtnoP2WKTKLZjaFGobb9SgA))
x264 10bit r2452 --preset placebo --tune grain (2pass) (dl (https://mega.co.nz/#!FoN3URTT!fGn0k_hj-RgwNaka3O-dFVundgqBkRQy2wXvkJ0s6u8))
x265 1.2.436 10bit --preset placebo --psy-rd 0.5 --psy-rdoq 0.5 --crf 21 (dl (https://mega.co.nz/#!851SmYiK!5EM_0h6_R94tQRbQsEvVDbttVekO-W0Q11XxmYCOmBI))

#64, all B
http://abload.de/img/a_originalvfqkp.png
http://abload.de/img/a_x264_8bit6fq7g.png
http://abload.de/img/a_x264_10bit8eqbr.png
http://abload.de/img/a_x265_10bitapp2t.png

#606, all I
http://abload.de/img/b_original8po9k.png
http://abload.de/img/b_x264_8bit95rif.png
http://abload.de/img/b_x264_10bite3rp5.png
http://abload.de/img/b_x265jho08.png

#1326, all P
http://abload.de/img/c_originaly9rf1.png
http://abload.de/img/c_x2640rpv0.png
http://abload.de/img/c_x264_10bitlxq7h.png
http://abload.de/img/c_x265b6rcy.png

#1472, x264: P, x265: B
http://abload.de/img/d_original3jpl4.png
http://abload.de/img/d_x264vkrw2.png
http://abload.de/img/d_x264_10bitixqwf.png
http://abload.de/img/d_x2658qp01.png

#1610, all B
http://abload.de/img/e_originalhjrxf.png
http://abload.de/img/e_x2647spwg.png
http://abload.de/img/e_x264_10bitwrp38.png
http://abload.de/img/e_x265m2ogi.png

#1831. all B
http://abload.de/img/f_originalbaeaq.png
http://abload.de/img/f_x26458dzb.png
http://abload.de/img/f_x264_10bit8hidb.png
http://abload.de/img/f_x265yqivq.png

#2068, all B
http://abload.de/img/g_originalnzd2x.png
http://abload.de/img/g_x264ssdyg.png
http://abload.de/img/g_x264_10bit6ke1i.png
http://abload.de/img/g_x265b7czq.png

I think for future tests I'll try out higher quality sources and a slightly lower bitrate. The biggest problem I see for x265 is the speed. If it needs the new psy features to compete with x264 it's way too slow (needing at least preset slower to work).

benwaggoner

5th August 2014, 23:01

x264 8bit r2452 --preset placebo --tune grain (2pass) (dl (https://mega.co.nz/#!01MjxRqB!pPllknkKrvOQuO4l9Yg4ZtnoP2WKTKLZjaFGobb9SgA))
x264 10bit r2452 --preset placebo --tune grain (2pass) (dl (https://mega.co.nz/#!FoN3URTT!fGn0k_hj-RgwNaka3O-dFVundgqBkRQy2wXvkJ0s6u8))
x265 1.2.436 10bit --preset placebo --psy-rd 0.5 --psy-rdoq 0.5 --crf 21 (dl (https://mega.co.nz/#!851SmYiK!5EM_0h6_R94tQRbQsEvVDbttVekO-W0Q11XxmYCOmBI))

Why not 2-pass for x265 as well. It should be working now.

sneaker_ger

5th August 2014, 23:06

2pass is kinda experimental as well, last I heard. Plus I didn't want to spend even more time encoding.

x265_Project

5th August 2014, 23:36

2pass is kinda experimental as well, last I heard. Plus I didn't want to spend even more time encoding.
2 Pass is working nicely now. The first pass defaults to a turbo mode.

benwaggoner

5th August 2014, 23:45

2 Pass is working nicely now. The first pass defaults to a turbo mode.
Do you see a measurable quality delta between a turbo and a regular first pass, or is it miniscule like with x264.

pandy

6th August 2014, 16:20

sneaker_ger

6th August 2014, 17:15

They always match except for frame #1472/D. I have added the types into the post.

Daemon404

6th August 2014, 18:31

Sagittaire

6th August 2014, 22:03

Are you sure that frame type is exactly the same for x264 and x265? I found unfair to compare I frame vs B frame and it is hardly to believe that encoders decision make this exactly repeatable but... this is my question - are we compare apples to apples?

x264 and x265 are certainely comparable IFrame decision. The problem is more to compare PFrame vs BFrame vs bFrame.

x264 is still ahead in this test though both would be transparent under normal viewing conditions. Since they aren't too different I wouldn't be surprised if others were to come to a different conclusion.

Really difficult here for me to find the best. Quality level at crf 21 is certainely to high for that. x264 and x265 produce really comparable output here.

I think for future tests I'll try out higher quality sources and a slightly lower bitrate. The biggest problem I see for x265 is the speed. If it needs the new psy features to compete with x264 it's way too slow (needing at least preset slower to work).

IMO here the best compromise for quality/time:

--preset slower --me hex --no-rect --no-amp --rd 4 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 0.2 --bframes 3 --min-keyint 1

foxyshadis

7th August 2014, 00:14

It's fundamentally flawed to compare static screenshots anyway, because rate control is a thing.

Sure, but that's why the streams are provided for anyone who cares enough to look deeper. Although it's obvious which is which (all frames of x265 are slightly softer), it's no longer easy to prefer one over the other, especially in motion. x264 doesn't "pop" that much more like it did just a couple months ago, and I find both equally pleasant.

Of course, equal is a low bar, given the speed penalty, but at least it's not subjectively worse any longer.

benwaggoner

7th August 2014, 02:48

x264 and x265 are certainely comparable IFrame decision. The problem is more to compare PFrame vs BFrame vs bFrame.
The right frame type decision may be different with different codecs, and I think each encoder should be allowed to make its own optimal decisions. I expect that we'll see more divergence in optimal frame type selection as x265 matures.

Really difficult here for me to find the best. Quality level at crf 21 is certainely to high for that. x264 and x265 produce really comparable output here.
I don't know that we should expect the CRF values to be that comparable, particularly with psychovisual optimizations. I think fixed bitrate comparisons at a low enough bitrate that both codecs show visible artifacts are going to be the most interesting way to test right now. with --bitrate, --vbv-bufsize, and --vbv-maxrate all set the same.

IMO here the best compromise for quality/time:
I think comparing at the same encoding time, and comparing without encoding time limit, are both interesting at this point. Full use of HEVC features is always going to be slower than full use of H.264 features, although HEVC has more potential for parallel and GPU acceleration which may eventually close the gap.

Note that none of the presets turn on --weightb at this point, presumably because the feature was added after the presets were finished. That's probably useful to add to the comparison, at least when comparable speed isn't a testing goal. I'm not sure what the speed impact is.

Also, I'm not sure how comparable the motion search ranges are between x264 and x265

sneaker_ger

7th August 2014, 09:36

Sagittaire

7th August 2014, 14:59

I don't know that we should expect the CRF values to be that comparable, particularly with psychovisual optimizations. I think fixed bitrate comparisons at a low enough bitrate that both codecs show visible artifacts are going to be the most interesting way to test right now. with --bitrate, --vbv-bufsize, and --vbv-maxrate all set the same.

crf 25 is in 1000-2000 kbps interval for 1080p real source movie. With this quality level you can expect to have 1080p movie on 1.4 Go with really goog quality. If you want show the real potential for HEVC, it's the way.

Note that none of the presets turn on --weightb at this point, presumably because the feature was added after the presets were finished. That's probably useful to add to the comparison, at least when comparable speed isn't a testing goal. I'm not sure what the speed impact is.

weightb is not really important if you have weightp. Don't expect to have really higher efficeincy with that.

sneaker_ger

7th August 2014, 17:49

A new test with the same source. This time lower bitrate and more concentrated on viable speeds.

x264 8bit r2452 64 bit (8 bit for hardware compatibility)
x265 10bit 1.2.474 64 bit
2209 frames
Core i7-860
all 2pass --bitrate 4000

Original (https://mega.co.nz/#!tk9RwKIZ!1XAR_PuUEo4C6ld9MfUOfU_nLDCWc5D2Sd4XjBpB6M8)

x264 (default) (dl (https://mega.co.nz/#!lp8EjAyZ!qE19BwdF1XtlodR8bv_5uEp0eR3e2iHmy-ewA0tR0GI))
pass 1: 60,52 fps
pass 2: 23,33 fps

x264 --preset veryslow --tune grain (dl (https://mega.co.nz/#!AoVRyCTJ!rZnMpyd7e8RWvBZ9HmSlg6QXpRkK54s_kc9OYQvIkdg))
pass 1: 23,72 fps
pass 2: 4,32 fps

x265 (default) (dl (https://mega.co.nz/#!MwFTWRhA!6zlJvk28h_Snl6_HhcdEDyIceE94NiS2JwT_Pu5vKqc))
pass 1: 445,05s, 4,96 fps
pass 2: 541,47s, 4,08 fps

x265 --preset slow (dl (https://mega.co.nz/#!48VnCTrZ!ioZUtFBppWOjM90I6hCDlkVJ3505meQ2F40103j3oh4))
pass 1: 538,56s, 4,10 fps
pass 2: 1799,03, 1,23 fps

x265 --preset slower --psy-rd 0.5 --psy-rdoq 0.5 (dl (https://mega.co.nz/#!Yo1VTZqC!BVm0sCn0FW2XHoxhA7B-ZQPNvUOAV0t5tbJg_HoFEDM))
pass 1: 2158,99s, 1,02 fps
pass 2: 6530,43s, 0,34 fps

x265 "Sagittaire" --preset slower --me hex --no-rect --no-amp --rd 4 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 0.2 --bframes 3 --min-keyint 1 (dl (https://mega.co.nz/#!1sk1QJLA!yg8BOXgRp9bSZmg0mkJF6YfW1IARx-E74TYZkXDJkzM))
pass 1: 756,51s, 2,92 fps
pass 2: 899,66s, 2,46 fps

#64, all B
http://abload.de/img/a_originalvfqkp.png
http://abload.de//img/a_x264_mediumglusb.png
http://abload.de//img/a_x264_veryslowiquk1.png
http://abload.de//img/a_x265_mediumbiuiz.png
http://abload.de//img/a_x265_slowqeuz4.png
http://abload.de//img/a_x265_sloweru2u0i.png (Ugly artifact here. Not sure if x265 or ffmpeg decoder error.)
http://abload.de//img/a_x265_sagittaireewuwb.png

#606, all I
http://abload.de/img/b_original8po9k.png
http://abload.de//img/b_x264_mediumzfuew.png
http://abload.de//img/b_x264_veryslowyduki.png
http://abload.de//img/b_x265_mediumxju99.png
http://abload.de//img/b_x265_slowzpu1p.png
http://abload.de//img/b_x265_slowerf1ucf.png
http://abload.de//img/b_x265_sagittairebju2t.png

#1326, all P
http://abload.de/img/c_originaly9rf1.png
http://abload.de//img/c_x264_mediumsluha.png
http://abload.de//img/c_x264_veryslowr1u46.png
http://abload.de//img/c_x265_mediumeuuyw.png
http://abload.de//img/c_x265_slowxdun2.png
http://abload.de//img/c_x265_slowerkzu2n.png
http://abload.de//img/c_x265_sagittairefzu10.png

#1610, all B
http://abload.de/img/e_originalhjrxf.png
http://abload.de//img/e_x264_mediumrslu2.png
http://abload.de//img/e_x264_veryslowvxb83.png
http://abload.de//img/e_x265_mediumu7b53.png
http://abload.de//img/e_x265_slow2wbhb.png
http://abload.de//img/e_x265_slowercoym8.png
http://abload.de//img/e_x265_sagittairegoa2t.png

#1831, all B
http://abload.de/img/f_originalbaeaq.png
http://abload.de//img/f_x264_medium85ldo.png
http://abload.de//img/f_x264_veryslow5ub14.png
http://abload.de//img/f_x265_mediumjclox.png
http://abload.de//img/f_x265_slow3sajv.png
http://abload.de//img/f_x265_slower92bsw.png
http://abload.de//img/f_x265_sagittairepbahw.png

#2068, all B
http://abload.de/img/g_originalnzd2x.png
http://abload.de//img/g_x264_mediumyparn.png
http://abload.de//img/g_x264_veryslow2yz2q.png
http://abload.de//img/g_x265_medium9sabc.png
http://abload.de//img/g_x265_slowpjawy.png
http://abload.de//img/g_x265_slowerq0y5q.png
http://abload.de//img/g_x265_sagittaireimac0.png

Sparktank

7th August 2014, 22:19

Rather interesting. I've been curious as to how x265 is coming along.

I will say that for x265 being in early development, it's still not too shabby.
I find the -slower preset to be visually pleasing more than the others, but those encoding speeds...
Sagittaire's comes very close to the slower preset without modifying anything.

Upon a second watch between Sagittaire and Slower, there's virtually little difference.
A reasonable compromise to get a speed boost for encoding.

It's nice to see so many updates for x265 in recent months.

Thanks for the testing.

Sagittaire

7th August 2014, 23:41

A new test with the same source. This time lower bitrate and more concentrated on viable speeds.

x264 8bit r2452 64 bit (8 bit for hardware compatibility)
x265 10bit 1.2.474 64 bit
2209 frames
Core i7-860
all 2pass --bitrate 4000

Here the setting to have symetrical setting with x264 and x265 (x264 with preset "grain" use low ratio for frametype to have more stable quality on I,P,B,b transition and better stability on grain retention). With high ratio for bframe, you have really higher quantizer on Bframe, but lower on Pframe too.

--preset slower --me hex --no-rect --no-amp --rd 4 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 0.2 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1

benwaggoner

8th August 2014, 17:50

A new test with the same source. This time lower bitrate and more concentrated on viable speeds.

x264 8bit r2452 64 bit (8 bit for hardware compatibility)
x265 10bit 1.2.474 64 bit
I think both encodes should use the same bit depth to get source and playback dithering out of the comparison.

2209 frames
Core i7-860
all 2pass --bitrate 4000
Is this a low enough bitrate for the content so there are reasonably visible artifacts in the x264 encode? We want to be testing in the range where bitrate has a clear visible impact on the encodes.

Also, you should be specifying the same --vbv-maxrate and --vbv-bufsize.

Sleepysonic

10th August 2014, 14:18

I'd really like to see a 2000 bitrate comparison!

fumoffu

11th August 2014, 17:45

wait wait wait...
are those comparisons done with the same bitrate? and there isn't really difference in quality and often x264 on default looks better than x265 on slower?
what the hell?!?
I understand that promised 50% reduction isn't always realistic, but come on, what is the point of all this if we can't beat old standard even with much longer encoding and more hardware demanding decoding.
It looks like for now it's better to use 10bit x264, it doesn't have any hardware support either but at least it can give realistic 10% or more bitrate savings.

LoRd_MuldeR

11th August 2014, 17:54

wait wait wait...
are those comparisons done with the same bitrate? and there isn't really difference in quality and often x264 on default looks better than x265 on slower?
what the hell?!?

If they were different bitrates, the whole test would be completely pointless! So I'm pretty sure they are the same ;)

The big question, however, is: Was the bitrate chosen reasonable for what we want to test?

Currently I think there are (at least) two test scenarios:
Bitrates where x264 still looks good. In this scenario, the question is whether x265 can preserve the same amount of details as x264 does (seemed to be a problem for x265 in the past! not quite sure now).
Bitrates low enough that x264 (and H.264 in general) starts getting serious problems. Here we expect x265 (HEVC) to really shine...

I understand that promised 50% reduction isn't always realistic, but come on, what is the point of all this if we can't beat old standard even with much longer encoding and more hardware demanding decoding.

Keep in mind how many years it took until x264 reached the quality and the encoding speed that it provides nowadays. Also, the hardware getting faster over the years certainly helped quite a bit ;)

At the same time HEVC is a relatively new standard and x265 is a relatively young project. So patience!

fumoffu

11th August 2014, 20:47

I understand x265 is a "relatively young project" but from what I understand it's already being licensed to consumers (who believe it will save bitrate).
I'm wondering if maybe x264 got really close to the limits of video compression (I'm simplifying here) and further compression can only be achieved by reducing picture complexity (yes I know x264 as every lossy codec does that too but the question is how much).

btw. Did anyone had the opportunity to test some other commercial HEVC encoders (besides Strongene)? If you google "hevc encoder" there is quite a few and some even real time...

LoRd_MuldeR

11th August 2014, 21:09

I understand x265 is a "relatively young project" but from what I understand it's already being licensed to consumers (who believe it will save bitrate).

"save bitrate" is a rather vague goal. You can save bitrate with any encoder, simply by lowering the bitrate ;)

Consequently the more interesting question is: Can x265 (HEVC) retain "good" quality at bitrates where x264 (H.264) doesn't. And indeed, if you pick a bitrate where x264 (H.264) already shows strong blocking, then x265 (HEVC) will probably deliver a much more decent result at that bitrate. But if you start with some bitrate where x264 (H.264) already gives a good result, then there obviously isn't much that could be gained by using x265 (HEVC). Actually, at those higher bitrates where x264 looks good, it currently may have some advantages compared to x265, because of more sophisticated Psy optimizations. x265 is working on Psy optimizations as well, but they might not be on par with x264 yet in terms of Psy optimizations...

easyfab

11th August 2014, 21:20

x265_Project

12th August 2014, 01:44

IIRC the real slow reference software HM has much better quality ( psnr ) than x264 for the same bitrate.
True. But why single out x264? What you're really saying is that H.265 can deliver higher encoding efficiency than H.264 (which was the goal of the new standard).

x265 is not yet a this quality level (compromise between speed and quality) but real progress is still possible in the next months/years.
That's not accurate. x265 can produce or exceed HM rate distortion curves under many circumstances (it depends on the specific test sequence and settings). We aren't focused on PSNR or SSIM; we're focused on what really matters: visual quality. More importantly, using high quality settings, x265 can exceed HM visual quality at identical bit rates (with encoding times that are orders of magnitude faster).

Sagittaire

12th August 2014, 01:50

IIRC the real slow reference software HM has much better quality ( psnr ) than x264 for the same bitrate.
x265 is not yet a this quality level (compromise between speed and quality) but real progress is still possible in the next months/years.

Well your are really in another world with HEVC. HEVC will be really better than H264 in 1000-2000 Kbps interval for ... 1080p movie.

sneaker_ger

20th August 2014, 21:19

A bit OT:
A few years ago a high quality trailer of "The Island" circulated around doom9. Does anyone still have it? It had quite some grain and decent quality IIRC.

benwaggoner

21st August 2014, 20:53

A bit OT:
A few years ago a high quality trailer of "The Island" circulated around doom9. Does anyone still have it? It had quite some grain and decent quality IIRC.
That was me, and I believe I've got an uncompressed 1080p 8-bit 4:2:0 version lying around somewhere. I'll try to find somewhere I can host it. It is a very interesting and challenging clip, with sections with cuts every 3 frames!

Atak_Snajpera

23rd August 2014, 14:25

My 3 cents ;)
Source -> http://dictaphone.atw.hu/mozdony.MTS

x264 --preset veryslow --pass 2 --bitrate 1024
frame 264 -> http://i.cubeupload.com/BEmHv3.png
frame 500 -> http://i.cubeupload.com/DFdmLu.png

https://mega.co.nz/#!VUUC3TIQ!OKLzGdB2-hzbEFVs2N-d3M72nZdkdEx2YBvNNZPsqak
ENCODING TIME: 1m:09s

x265 --preset medium --pass 2 --bitrate 1024 --rd 4 --psy-rd 1.0 --psy-rdoq 1.0
frame 264 -> http://i.cubeupload.com/eVnu5J.png
frame 500 -> http://i.cubeupload.com/RiTX1r.png

https://mega.co.nz/#!8MUmDCzQ!4xWLh1Q1oFWHubRrFECbOmrJhlEAWHV0SM1BZr4yYFs
ENCODING TIME: 1m:26s

x265_Project

25th August 2014, 18:52

Here is a relevant comparison screenshot...
https://www.facebook.com/x265project/photos/a.1413021475581600.1073741826.1395701047313643/1508982559318824/?type=1&theater

Source= Tears of Steel 1080P (YUV generated from 8 bit lossless PNG image sequence).
x264 command-line ...

set SEQUENCE=TearsClip_1920x800_24.yuv
set CLIP=Tears
set RESOLUTION=1920x800
set FPS=24
set FRAMES=335
set PRESET=veryslow
set BITRATE=400
x264 --input-res %RESOLUTION% --fps %FPS% --frames %FRAMES% -o %CLIP%_%BITRATE%_Pass1_%FPS%fps.264 --bitrate %BITRATE% --preset %PRESET% --ssim --psnr --pass 1 --stats %CLIP%_%BITRATE%_x264stats.log %SEQUENCE%
x264 --input-res %RESOLUTION% --fps %FPS% --frames %FRAMES% -o %CLIP%_%BITRATE%_%FPS%fps.264 --bitrate %BITRATE% --preset %PRESET% --ssim --psnr --pass 2 --stats %CLIP%_%BITRATE%_x264stats.log %SEQUENCE%

x265 command-line...

set SEQUENCE=TearsClip_1920x800_24.yuv
set CLIP=Tears
set RESOLUTION=1920x800
set FPS=24
set FRAMES=335
set PRESET=veryslow
set BITRATE=400
x265 --input %SEQUENCE% --input-res %RESOLUTION% --fps %FPS% --frames %FRAMES% -o %CLIP%_%BITRATE%_Pass1_%FPS%fps.hevc --csv %CSV% --bitrate %BITRATE% -p %PRESET% --ssim --psnr --pass 1 --rd 2 --stats %CLIP%_%BITRATE%_stats.log
x265 --input %SEQUENCE% --input-res %RESOLUTION% --fps %FPS% --frames %FRAMES% -o %CLIP%_%BITRATE%_%FPS%fps.hevc --csv %CSV% --bitrate %BITRATE% -p %PRESET% --psy-rdoq 1.0 --psy-rd 0.6 --ssim --psnr --pass 2 --stats %CLIP%_%BITRATE%_stats.log

x265 wins easily without adding psy-rd or psy-rdoq, but with these tools you can bring out more detail.

LoRd_MuldeR

25th August 2014, 20:20

I'm not really surprised that x265 beats x264 at 400 kbps for 1080p footage :)

BTW: What was the speed of x265 compared to x264?

fumoffu

25th August 2014, 22:09

I'm not really surprised that x265 beats x264 at 400 kbps for 1080p footage :)

People were told to encode a Blu-ray movie with average 400kbps bitrate:
- sane person - "Hmm I'll better resize it to DVD resolution or lower. This shouldn't even take an hour."
- x265 developer - "This is what I have been waiting for all my life! Better start encoding now, so it will be ready tomorrow."
- marketing guy - "Guys can we maybe upscale this to 4K? And can we make it in 3D?"

benwaggoner

26th August 2014, 01:37

People were told to encode a Blu-ray movie with average 400kbps bitrate:
- sane person - "Hmm I'll better resize it to DVD resolution or lower. This shouldn't even take an hour."
- x265 developer - "This is what I have been waiting for all my life! Better start encoding now, so it will be ready tomorrow."
- marketing guy - "Guys can we maybe upscale this to 4K? And can we make it in 3D?"
Content publisher - "I can get 1080p quality at the bitrate I'm using for 720p? That'll be a big upgrade for customers without any increased bandwidth requirements!"

The business is all about how to deliver as good quality as possible in as few bits as possible. Lots of customers are bandwidth constrained, so any technology that makes things look better with "not enough bits" is a win for everyone.

Also, marketing guys stopped asking anything about 3D about three years ago :).

Atak_Snajpera

26th August 2014, 10:33

Content publisher - "I can get 1080p quality at the bitrate I'm using for 720p? That'll be a big upgrade for customers without any increased bandwidth requirements!"

The business is all about how to deliver as good quality as possible in as few bits as possible. Lots of customers are bandwidth constrained, so any technology that makes things look better with "not enough bits" is a win for everyone.

Also, marketing guys stopped asking anything about 3D about three years ago :).

"Youtube" - "Cool! Now we can provide content with the same crappy quality at lower bitrate!"

fumoffu

26th August 2014, 15:12

Content publisher - "I can get 1080p quality at the bitrate I'm using for 720p? That'll be a big upgrade for customers without any increased bandwidth requirements!"

But I'm wondering if this higher resolution brings any additional quality. Will the 1080p video really look better than the 720p encoded with previous codec? Or are we just artificially inflating resolution just for the sake of it.

STaRGaZeR

26th August 2014, 15:22

"Youtube" - "Cool! Now we can provide content with the same crappy quality at lower bitrate!"

If anything, you can bet on that.

x265_Project

26th August 2014, 16:57

But I'm wondering if this higher resolution brings any additional quality. Will the 1080p video really look better than the 720p encoded with previous codec? Or are with just artificially inflating resolution just for the sake of it.
It's very easy to pick a favorite video clip and encode it with x264 and x265 using similar settings, then compare the result. Similarly you can scale the video down from 1080P to 720P, and run additional tests at various bit rates. The difference in encoding efficiency is very easy to see, and it's massive. I posted my command-line above, so anyone can reproduce these results. It's a bit of a pain to download 17620 PNG images from xiph.org (40 GB), converting them to YUV with FFMPEG to produce your Tears Of Steel 1080P 8 bit lossless master, but you don't have to download the whole movie.

The world's video experts spent 10 years researching and developing improvements to H.264, and the best proposals were incorporated into the new H.265 specification. The goal of the new standard was to reduce bit rate by half for a given quality level, and it's generally accepted that they achieved this goal (when you measure the H.265 HM vs the H.264 JM). Subjective testing confirms this (http://www.slideshare.net/touradj_ebrahimi/spie2014-hev-cvsvp9). It's taken us and other HEVC encoder developers many months to produce optimized encoder implementations, with the features and performance that are required for commercial deployment. But we're pretty much at that point now. While there is still room for further improvement, and while your results will vary depending on the content and your settings, for most content at typical bit rates, the quality difference between x264 and x265 is fairly substantial, and we can often produce encodes at half the bit rate of x264 that any viewer would grade higher.

I've posted links to the clips referenced above on our x265 Facebook page... https://www.facebook.com/x265project.

I should point out again that it pains us to compare x265 to x264. We don't want anyone to think that we are criticizing x264. After all, x264 is x265's parent. We love x264, and we're still helping to improve it. But before anyone will consider using a new encoder they want to know how it compares to the encoder that they consider the best - the one that they have been using for years. And that encoder is x264.

Tom

benwaggoner

26th August 2014, 18:22

But I'm wondering if this higher resolution brings any additional quality. Will the 1080p video really look better than the 720p encoded with previous codec? Or are with just artificially inflating resolution just for the sake of it.
I certainly don't. Encoding more pixels takes more time, much more than increasing bitrate. So it's a win-win to use only as many pixels as is optimal for the content and bitrate. If there is a fixed amount of time that can be used for encoding, using a lower resolution allows more MIPS/pixel to be applied, which also shifts the quality advantage to lower bitrates a bit.

Some may feel there's marketing value in getting to "HD" at as a low a bitrate as possible, even if the quality is worse than the same bitrate at a lower frame size. But my inclination is that people watch and care about the actual video way more than they do a "HD" bug that pops up.

And I'm spectacularly annoyed by all the "1440p" YouTube video that is obviously scaled up from 720p or less. That's just immoral compressing :).

fumoffu

26th August 2014, 18:47

It's a bit of a pain to download 17620 PNG images from xiph.org (40 GB), converting them to YUV with FFMPEG to produce your Tears Of Steel 1080P 8 bit lossless master, but you don't have to download the whole movie.
Yes would be great to have something smaller to test...
x264 isn't tuned for such conditions, so I'm wondering how much the result could be improved by for example lowering psy-rd to 0 and adjusting aq. Maybe I'll play with the already compressed version - shouldn't matter much considering...

The world's video experts spent 10 years researching and developing improvements to H.264, and the best proposals were incorporated into the new H.265 specification. The goal of the new standard was to reduce bit rate by half for a given quality level, and it's generally accepted that they achieved this goal (when you measure the H.265 HM vs the H.264 JM). Subjective testing confirms this (http://www.slideshare.net/touradj_ebrahimi/spie2014-hev-cvsvp9). It's taken us and other HEVC encoder developers many months to produce optimized encoder implementations, with the features and performance that are required for commercial deployment. But we're pretty much at that point now. While there is still room for further improvement, and while your results will vary depending on the content and your settings, for most content at typical bit rates, the quality difference between x264 and x265 is fairly substantial, and we can often produce encodes at half the bit rate of x264 that any viewer would grade higher.
I have no doubt that HEVC has great possibilities, I just wonder if x265 has similar efficiency as HM.

x265_Project

26th August 2014, 19:16

Yes would be great to have something smaller to test...
x264 isn't tuned for such conditions, so I'm wondering how much the result could be improved by for example lowering psy-rd to 0 and adjusting aq. Maybe I'll play with the already compressed version - shouldn't matter much considering...

Yeah... downloading 17620 PNGs (or 500 GB of 16 bit TIF images in the case of the 4K lossless version) is a pain. I used an app called HTTrack, but you have to feed it all the urls to download, which also took a bit of time to prepare.

I have no doubt that HEVC has great possibilities, I just wonder if x265 has similar efficiency as HM.
The HM sets the bar high, but it also has every quality feature on in the default config files and it takes minutes per 1080P frame to encode. In my testing the latest builds of x265 with high quality (veryslow + intra and inter-depth at 4), plus the right amount of psy-rd and psy-rdoq produce encodes that are visually better than the HM encoder. Again, your mileage may vary... as with everything visual quality results are highly dependent on the content and the settings (particularly the bit rate you've chosen). For a low bit rate encode like the example above I tested many psy-rd values, and I determined that a psy-rd strength of 0.6 was optimal. I think you'll find that you can use higher psy-rd strength at higher bit rates (although we're now scaling with lambda, and I haven't had a chance to run extensive tests). Then I ran another large batch of tests to find the optimal psy-rdoq strength, which turned out to be 1.0. It's hard to see a lot of difference with small changes in psy-rdoq, so I could just as easily have used a bit more or less. Anyhow, the encodes with psy-rd and psy-rdoq were most certainly better than with default --preset veryslow (improved hair and skin details, for example), and so we're starting to think about turning psy-rd and psy-rdoq on by default (at some modest strength) to insure everyone gets this improvement in their encodes.

Tom

benwaggoner

26th August 2014, 20:29

"Youtube" - "Cool! Now we can provide content with the same crappy quality at lower bitrate!"
Fortunately that's not how it works for adaptive streaming services. The primary bottleneck is getting bits to the customer's playback device. The customers who get bad quality today are bandwidth-limited, and so improved compression efficiency means they get better quality at their available bandwidth.

As for YouTube, they definitely could be using higher bitrates for complex content at each frame size. But they are willing to waste crazy bits on stuff like doing everything in H.264 and VP9, and offering 1440p and 2160p.

fumoffu

26th August 2014, 20:58

foxyshadis

26th August 2014, 23:06

Well, that's more of a technical demonstration of a 32x32 DCT vs 8x8 -- by zeroing out high frequencies, you achieve the exact same result as linear downscaling and upscaling. By concentrating on one little crop of one frame, you probably miss the whole story though.

The reason you'd ever encode high resolution at low bitrates instead of low resolution at normal bitrates, is that the encoder can opt to encode some areas in full resolution and reduce the resolution of others. HEVC in particular has an incredible prediction engine, much better than AVC's which is already much better than most codecs', which translates into more full-res detail for free as long as your encoder finds it. Of course you pay a huge time penalty for that, and if the bitrate is too low, it won't work at all; even if it does, the question of if it's worth it is important. No one can answer that but you (though anyone who spends a couple of days to encode Tears of Steel at 400 kbps is well outside the norm).

Now this bitrate is below the point where AVC breaks up into blocks at high res, so you would want to keep reducing the resolution until that stops, while keeping the same bitrate. 360p is probably too far, but what do I know? It is completely fair to compare different resolutions as well, selecting the best resolution for a given bitrate is just as important as choosing the right filters and encoder options.

x265_Project

27th August 2014, 01:22

Ok I played a bit with the file downloaded from here http://mango.blender.org/download/ - I used this version HD 1920 pixels wide (~700MB, mov, 2.0) - 12min 14sec

My results:
imgur (http://imgur.com/JixrYEb)

oh I think I also used me_range=24 and maybe some other small things, setting used for 360p were similar and I disabled AQ completely.
Those are not some highly tweaked settings - I basically guessed what would help and set it that way, with some testing it probably could be improved.
Well h265 still looks best so that's good but now the huge gap is gone especially between 1080p hevc and 360p x264 not to mention compression time.
I agree that at some point it is better to downscale... but HEVC pushes this point lower. In addition to what foxyshadis pointed out, I would point out that now your example is not comparing apples to apples. To be fair you would need to encode the same downscaled clip with x265 and compare this to the 360P encode with x264. And of course you could repeat the test at various resolutions and bit rates.

a5180007

27th August 2014, 08:47

x264 PSNR usually looks like this:

http://i.imgur.com/sRf28AQ.png
(EDIT : downscale with Repair(Lanczos, Gaussian), upscale with Lanczos)

I find x264 CRF 23 to be a fair rule of thumb for the maximum compression before downscaling -indeed it also depends of the downscaling ratio, in the above example with large steps of 1.5:1, the limit is CRF 25.

So there is little point comparing x265 to x264 for compressions above x264 CRF 23.
I haven't done the same tests for x265 (due to my CPU poor performance :(), but shouldn't the same apply with default x265 CRF ? If not, on what criteria is that default CRF of 28 based ?

sneaker_ger

31st August 2014, 07:56

I have made a new test to compare banding, especially to see if x265 profits as much from 10 bit as x264 does. My conclusion, at least for low bitrates: yes, it does.

The source is a 2 minute lossless film of a lighthouse that was posted to doom9 years ago. (download (https://mega.co.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw), 2 GB, mirror (http://217.160.126.132/lighthouse_lossless.mp4))
Three different settings were used, each with both 8 bit and 10 bit. Bitrate and mode were 2000 kbit/s 2pass.
x264 --preset veryslow --tune film
x265 (default settings)
x265 --preset slower

Binaries used:
x264 64bit r2479 from Videolan.
x265 64bit icl 1.3+57 from Chromashift

Screenshots and output movies in order, frame number first part of file name:

original (http://217.160.126.132/lighthouse_lossless.mp4)
x264 8bit (https://mega.co.nz/#!oxlikKjK!EUp5qVZe8YEovEjvD3uAmYmwu5Ju4H_hqvA7yx15f4g)
x264 10bit (https://mega.co.nz/#!FwEFFQCD!icOW9CG7CeMoc92GRxPFt06s7WPPJ5twEz8NQ5xVY4w)
x265 8bit (https://mega.co.nz/#!wtUW2LLb!arm6OwgjaxxJ3irnmM7wAlt9SrTd7H330a1QQRq-7QM)
x265 10bit (https://mega.co.nz/#!Z0tTSZjY!xBZG2iK4BQl0MuqIcjJZJZ3LadVb2WmF3CtElxJq1P0)
x265 slower 8bit (https://mega.co.nz/#!d5Ny2KyL!ErN7k3-60XgSi6molqHdNv9nPOQ5mcmYO0hCAaGXahE)
x265 slower 10bit (https://mega.co.nz/#!t10TgJjL!wvrViQTwUCeEXM8xs0UumCKxAwWC1jur81wSpOIu6yQ)

http://abload.de/img/70_orgcmslk.png
http://abload.de/img/70_4_8l8k6u.png
http://abload.de/img/70_4_105gqkw.png
http://abload.de/img/70_5_8fbjxs.png
http://abload.de/img/70_5_10l8oc5.png
http://abload.de/img/70_5s_8c9ju6.png
http://abload.de/img/70_5s_10drool.png

http://abload.de/img/290_orgqtsuz.png
http://abload.de/img/290_4_8mvjvm.png
http://abload.de/img/290_4_10pwoqx.png
http://abload.de/img/290_5_8t5k6h.png
http://abload.de/img/290_5_10m0q1f.png
http://abload.de/img/290_5s_87ukal.png
http://abload.de/img/290_5s_10n6qm2.png

http://abload.de/img/1270_orgajst9.png
http://abload.de/img/1270_4_88nkd4.png
http://abload.de/img/1270_4_10zzpto.png
http://abload.de/img/1270_5_83ok38.png
http://abload.de/img/1270_5_10krre6.png
http://abload.de/img/1270_5s_803joo.png
http://abload.de/img/1270_5s_10tipz6.png

http://abload.de/img/1950_orgrjsu8.png
http://abload.de/img/1950_4_86njni.png
http://abload.de/img/1950_4_106es60.png
http://abload.de/img/1950_5_8ufjgj.png
http://abload.de/img/1950_5_10pasp8.png
http://abload.de/img/1950_5s_81ij2f.png
http://abload.de/img/1950_5s_10d2sc7.png

The next thing to test would be banding at higher bitrates.

huhn

31st August 2014, 10:12

I have made a new test to compare banding, especially to see if x265 profits as much from 10 bit as x264 does. My conclusion, at least for low bitrates: yes, it does.

that's very good to hear. the first test I saw show about no difference between 10 and 8 bit (16 bit internal). the screens show a very very huge difference between 10 and 8 bit.

x265_Project

31st August 2014, 20:18

I have made a new test to compare banding...
The challenge here is that most people don't have true 10 bit color support on their PC, through the graphics and the display, and almost nobody has true 10 bit HEVC playback on their system. Unless you have a true 10-bit system, you won't be able to evaluate the difference between these 8 and 10 bit encodes accurately.

We (MulticoreWare) have a true 10 bit HEVC decoder (UHDcode), and we expect 10 bit support to become more widely available, especially in high-end televisions. But PC graphics vendors have traditionally reserved 10 bit /sample (deep color) output for their professional graphics (NVIDIA Quadro, AMD FirePro).

vivan

31st August 2014, 20:29

huhn

1st September 2014, 00:01

The challenge here is that most people don't have true 10 bit color support on their PC, through the graphics and the display, and almost nobody has true 10 bit HEVC playback on their system. Unless you have a true 10-bit system, you won't be able to evaluate the difference between these 8 and 10 bit encodes accurately.

We (MulticoreWare) have a true 10 bit HEVC decoder (UHDcode), and we expect 10 bit support to become more widely available, especially in high-end televisions. But PC graphics vendors have traditionally reserved 10 bit /sample (deep color) output for their professional graphics (NVIDIA Quadro, AMD FirePro).

ok I agree that we can see the full potential of the 10 bit encode on 8 bit screen. but it still doesn't change the fact that 10 bit still looks better with the same settings at least this is the case for x264 and this test show the same effect for x265.

now about 10 bit output on PC.

every consumer GPU can output 10 bit no fireGL quadro card is needed.
we even have a renderer that can do this right now it's the standard EVR with D3D Fullscreen it can output 10 bit right now. to bad it doesn't support 10 bit input like p010 and as far as I know no 10 bit at all. but we have a 10 bit surface for years. all need UHD pc screen are 10 bit or at least 8bit + dither or other tricks to get 10 bit.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/~/10-bit-per-color-support-on-nvidia-geforce-gpus

NVIDIA Geforce graphics cards have offered 10-bit per color out to a full screen Direct X surface since the Geforce 200 series GPUs.

now about accurately.

we don't have accurately at all even with 8 bit.
we usually encode from a YCbCr 4:2:0 source.
so we need chroma upsampling (and correction for mpeg 2 chroma) which creates float point and YCbCr --> RGB conversation which creates float point to. so what the point about accurately if we need rounding or dithering anyway?

and things like madVR accepts p010 and work with it even if the output is dithered 8 bit.

nevcairiel

1st September 2014, 08:18

We (MulticoreWare) have a true 10 bit HEVC decoder (UHDcode)

I don't know what makes a "true" 10 bit HEVC decoder in your book, but ffmpeg and some things based on ffmpeg (ie. my LAV Filters DirectShow decoder) offer true uncompromised 10-bit output from the decoder.

Getting that onto a 10-bit screen untouched is another matter of course, and while in theory possible with DirectX, its not implemented widely anywhere.

benwaggoner

1st September 2014, 18:34

I agree that at some point it is better to downscale... but HEVC pushes this point lower.
Yeah, that's pretty much the story of compression right there :).

Back with Apple and Microsoft Video, we were talking >2 Mbps for 320x240 to look halfway decent, and it was halfway at best. Cinepak made for a reasonably decent 320x240 @ 2 Mbps for most content. MPEG-1 gave us a better 352x240 @ 1.5 Mbps. In the late 90's we had huge innovation with things like Sorenson Video 1 & 2/3, Indeo 5, RealVideo, and Windows Media V7 & 8 which made 320x240 feasible down to maybe 750 Kbps. Last decade saw VC-1 and H.264 emerge, getting us down to a decent Kbps 320x240. Over the last 10 years, further refinement in H.264 (largely psychovisual, but a lot from the Baseline to High transition) got us down to 300 Kbps 320x240 looking pretty good. HEVC can do the same at 200 Kbps, maybe lower. Of course, no one is even doing 320x240 any more.

If I get sufficiently bored, I should dust off all my old tools and encode the same clip using the best codecs of each era to see our progression.

Back when I was encoding for the Grolier's CD ROM encyclopedia around 97-98, I remember how excited I was to get a MPEG-1 (black and white 24p) down to 900 Kbps ABR!

sneaker_ger

1st September 2014, 19:59

I extended the test from post #45, this time with a bitrate of 5000 kbit/s and 8 bit only. The x265 encode didn't show as much improvement as the x264 one initially. Activating psy showed much less banding, though. I should have probably turned it on in the other test as well.

original
x264 --preset veryslow --tune film (https://mega.co.nz/#!pwcVwbpY!l7d9muOvue6dkxKyfu0OC9eelH79RJIxbklySl5ViAk)
x265 --preset slower (https://mega.co.nz/#!E4tgzByB!J0XGg1NQaDPJOWHLHl_bqSmFmdwKHewN7UWVkn8h4wM)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 (https://mega.co.nz/#!Yk9gUbJQ!fZKdTNK0l0Gr2j09BNfxTL6a3PVHg44OpGTsB8NuOKw)

http://abload.de/img/70_orgcmslk.png
http://abload.de/img/70_4_v6stn.png
http://abload.de/img/70_5_w7sqn.png
http://abload.de/img/70_5psy_yfs1o.png

http://abload.de/img/290_orgqtsuz.png
http://abload.de/img/290_4_yls9t.png
http://abload.de/img/290_5_tmszr.png
http://abload.de/img/290_5psy_d9sl3.png

http://abload.de/img/1270_orgajst9.png
http://abload.de/img/1270_4_dusty.png
http://abload.de/img/1270_5_1wset.png
http://abload.de/img/1270_5psy_ydsup.png

http://abload.de/img/1950_orgrjsu8.png
http://abload.de/img/1950_4_2eseq.png
http://abload.de/img/1950_5_goslo.png
http://abload.de/img/1950_5psy_dss3t.png

edison

4th September 2014, 09:54

But PC graphics vendors have traditionally reserved 10 bit /sample (deep color) output for their professional graphics (NVIDIA Quadro, AMD FirePro).

All DX10 GPU support true 10-bit scan-out in DX10 mode via displayport or DB-15. There is a DX10 10-bit scan-out sample in MS DX SDK.
NVIDIA and AMD support DX10 10-bit scan-out in DX10 mode without need professional GPU. But, AMD implement a 1x-bit dithering in their DVI-output since X800 gen, so there is not difference when compare DVI and displayport on AMD GPU running the MS DX SDK 10bit sample.

benwaggoner

4th September 2014, 19:16

All DX10 GPU support true 10-bit scan-out in DX10 mode via displayport or DB-15. There is a DX10 10-bit scan-out sample in MS DX SDK.
NVIDIA and AMD support DX10 10-bit scan-out in DX10 mode without need professional GPU. But, AMD implement a 1x-bit dithering in their DVI-output since X800 gen, so there is not difference when compare DVI and displayport on AMD GPU running the MS DX SDK 10bit sample.
For NVidia, I believe the restriction is that the Quadro drivers are required for 10-bit OpenGL output. Which is what the professional video apps, notably CC, use.

The good news is that the low end Kepler Quadro's are actually pretty reasonable for a content creator. But they'd be lousy for gaming and other enthusiast stuff, so it'd be hard to build a box with a single GPU that did both well.

huhn

5th September 2014, 09:30

For NVidia, I believe the restriction is that the Quadro drivers are required for 10-bit OpenGL output. Which is what the professional video apps, notably CC, use.

The good news is that the low end Kepler Quadro's are actually pretty reasonable for a content creator. But they'd be lousy for gaming and other enthusiast stuff, so it'd be hard to build a box with a single GPU that did both well.

no normal nvidia card can do it for over 5 years.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

you need a quadro for openGL 10 bit like photoshop. but for directx 10 bit nothing special is needed just a normal nvidia card that's not over 6 years old and support DP, HDMI or both.

nevcairiel

5th September 2014, 09:55

no normal nvidia card can do it for over 5 years.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

you need a quadro for openGL 10 bit

Did you read his post? :p
He did mention that the limitation is about 10-bit OpenGL.

huhn

5th September 2014, 10:05

Did you read his post? :p
He did mention that the limitation is about 10-bit OpenGL.

good question... hmm

agressiv

5th September 2014, 22:49

With x265 encodes, am I losing quality with a --preset medium vs --preset veryslow or is it just file size? --crf is 18.

With x264, you lose a bit of quality even with the same crf.

LoRd_MuldeR

5th September 2014, 22:54

With x265 encodes, am I losing quality with a --preset medium vs --preset veryslow or is it just file size? --crf is 18.

With x264, you lose a bit of quality even with the same crf.

If you compare the visual quality of files with different size (and therefore with different bitrate) you won't learn much, because you comparison is flawed. Therefore, always compare files of the same size (bitrate)!

BTW: The same CRF has a different meaning, if you change other influential settings, like switching between "medium" and "veryslow" presets. Don't use CRF for comparisons. Use 2-Pass mode.

agressiv

5th September 2014, 23:17

LoRd_MuldeR

6th September 2014, 01:19

That's the thing, final file size / target bitrate - has never been a goal of mine. I'd rather just have consistent quality, which --crf 18 with x264 has always provided for me. So, doing a 2-pass wouldn't bring me any closer to deciding if veryslow is desirable with --crf 18, or if an extra small amount of file size saves me hours of transcoding time with comparable quality by sticking with medium.

If I compared a 2-pass encode and decided medium is good enough, would that hold true for crf 18 in a 1-pass? To me, that is apples and oranges, no?

CRF is not a "target quality" mode! All you really know about CRF mode is: The same CRF value gives approximately the same quality for different sources (of the same type) as long as you don't change any other settings. Consequently, CRF 18 at preset "veryslow" may give very different quality than CRF 18 at preset "medium". With 2-Pass mode you can verify that "veryslow" preset gives better quality than "medium" preset at the same bitrate. Of course this applies to CRF mode too! Only that in CRF mode you probably will not get the same bitrate for "medium" and "veryslow" preset at a given fixed CRF value (e.g. CRF 18). So when going from "medium" to "veryslow" preset, you will probably need to re-adjust your "usual" CRF value.

sneaker_ger

12th September 2014, 20:32

The next comparison is from the 2K trailer of "Gravity". It is done in 2pass 5000 kbit/s. Source was down-sampled to 4:2:0 8 bit/10 bit using fmtconv (http://forum.doom9.org/showthread.php?t=166504) since 4:2:2 HEVC is still experimental.

Original (2.6 GB) (http://pdl.warnerbros.com/wbmovies/gravity/trailer2/GRAVITY_TRAILER_5-2k.mov)
x264 veryslow film 8 bit (https://mega.co.nz/#!opdykaTY!Xrybcjh8Umds7V1Y7Hjpc2u9blP5wq81maUrSaGz3UU)
x264 veryslow film 10 bit (https://mega.co.nz/#!4gVU2YxD!rAjuWATY5fL6PPeS5syenzETFZekR4PICPWPYU5gMJ4)
x265 default psy-rd 1.0 10 bit (https://mega.co.nz/#!k0dz2SjY!KKzMMhIBwkWpJGIn0GvEAeW5F7-bP2k0GQ_EQXRffAc)
x265 slower psy-rd 1.0 psy-rdoq 1.0 10 bit (https://mega.co.nz/#!gsVwVIQA!kpvXpZYGr2csELFdnH5ivzTabIzuwoTgAuj4cwkAaB4)

x264 r2479 64 bit from Videolan
x265 r1.3+175 icl 64 bit from Chromashift

http://abload.de/img/22507ruhl.png
http://abload.de/img/2250_4_uru68.png P
http://abload.de/img/2250_4_10_zeuwo.png P
http://abload.de/img/2250_5_xnuwt.png B
http://abload.de/img/2250_5s_opu3g.png B

http://abload.de/img/2640ixune.png
http://abload.de/img/2640_4_b4uak.png I
http://abload.de/img/2640_4_10e1u3a.png I
http://abload.de/img/2640_5_e8u6d.png I
http://abload.de/img/2640_5s_0iukh.png B

http://abload.de/img/2677qzull.png
http://abload.de/img/2677_4_2fuk0.png P
http://abload.de/img/2677_4_10_d1uyl.png B
http://abload.de/img/2677_5_gju0y.png B
http://abload.de/img/2677_5s_5ruea.png B

http://abload.de/img/2765bxum3.png
http://abload.de/img/2765_4_t9u7d.png P
http://abload.de/img/2765_4_10_gzudi.png P
http://abload.de/img/2765_5_zruvh.png P
http://abload.de/img/2765_5s_q4uf6.png P

http://abload.de/img/2825ewf9y.png
http://abload.de/img/2825_4_rseqv.png B
http://abload.de/img/2825_4_10_ihc4t.png B
http://abload.de/img/2825_5_lxi4l.png B
http://abload.de/img/2825_5s_kjfei.png B

http://abload.de/img/3030wecu5.png
http://abload.de/img/3030_4_hidwl.png B
http://abload.de/img/3030_4_10_fyitx.png B
http://abload.de/img/3030_5_opezp.png B
http://abload.de/img/3030_5s_0gi4q.png B

http://abload.de/img/3334j6dn8.png
http://abload.de/img/3334_4_o2fhi.png P
http://abload.de/img/3334_4_10_45c50.png P
http://abload.de/img/3334_5_9gdjm.png P
http://abload.de/img/3334_5s_vginz.png P

sneaker_ger

13th September 2014, 17:49

Since I haven't seen any tests yet the next one is with a cartoon/animation Blu-Ray sample. The bitrate was 2500 kbit/s (2pass).

My conclusion:
x265 is the clear winner in this one, even against x264 10 bit. Especially the first screenshot made me question my test setup. In retrospect the bitrate was too low, though.

Original (https://mega.co.nz/#!tk0F3TxZ!-6WkTrqXemhegSyjKwBteGYr9Iow_DRJwG3_d0pKr-4)
x264 veryslow animation 8 bit (https://mega.co.nz/#!EhsFmDjY!ixhVOqEYxD_Unj8BY9O5_ChgLwQtdl29QmmIljj0Ics) (16.65 fps, 3.17 fps)
x264 veryslow animation 10 bit (https://mega.co.nz/#!YsdBWBpR!7KL0HBE8q3SjJhgbtZ_DfO8n3RJx3nrabSPr2b1nKq0) (12.35 fps, 1.78 fps)
x265 default psy-rd 1.0 10 bit (https://mega.co.nz/#!50tUyDSa!FTycXqVpQ0NiS2h98scLkyYHq6KbF_CLYM7ay40l874) (4.71 fps, 4.05 fps)
x265 slower psy-rd 1.0 psy-rdoq 1.0 10 bit (https://mega.co.nz/#!d99WlQSI!3vLlE74M8EOue5Zl3mpimmBW8ysMqBbcda2c6MmOCLg) (3.73 fps, 0.28 fps)

Intel Core i7-860 @ stock
x264 r2479 64 bit from Videolan
x265 r1.3+175 icl 64 bit from Chromashift

all B
http://abload.de/img/60khxt8.png (ignore the "downsampled to 4:2:0" part, that was a forgotten left-over from the previous test)
http://abload.de/img/60_4_pcl9o.png
http://abload.de/img/60_4_10_1xzef.png
http://abload.de/img/60_5_haybt.png
http://abload.de/img/60_5s_nxzs3.png

all P
http://abload.de/img/870qgxi7.png
http://abload.de/img/870_4_8rx9p.png
http://abload.de/img/870_4_10_mfbye.png
http://abload.de/img/870_5_70b6b.png
http://abload.de/img/870_5s_gvbkl.png

all P
http://abload.de/img/1570e2act.png
http://abload.de/img/1570_4_uibrn.png
http://abload.de/img/1570_4_10_kna07.png
http://abload.de/img/1570_5_hub5z.png
http://abload.de/img/1570_5s_zlzhb.png

all B
http://abload.de/img/179313ale.png
http://abload.de/img/1793_4_b8zaf.png
http://abload.de/img/1793_4_10wqyza.png
http://abload.de/img/1793_5_o8abz.png
http://abload.de/img/1793_5s_fbx5j.png

The next test should probably be cartoon/animation taken from within an actual show because this was too action/sfx packed. Cartoons are often still shots with little movement.

sneaker_ger

14th September 2014, 12:49

An extension of the test above, now with 6000 kbit/s. x264 8 bit has been removed, x265 default has been substituted by x265 preset slow.

My conclusion:
x265 (slower) is still the winner in this. Both x264 and x265 lose (different) details here and there but the x265 shows much less artifacts around edges and looks more smooth in general.

original
x264 veryslow animation 10 bit (https://mega.co.nz/#!18ln3IjS!cc2Qf58kLXEdm9MeE-b5wvDwG9GmgLHIdSQSXTE6_ko) (11.06 fps, 1.45 fps)
x265 slow psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!pwUmhCbA!sX1qX4Q_RwlBSrif0RsinTh9zDrf2u81i9Mv3fjtzyw) (4.05 fps, 0.89 fps)
x265 slower psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!xttVhSDD!KaZGE4_mJxVYWyLfm-STGVISJX2Rzd_ypcvV4SC09Rc) (3.09 fps, 0.21 fps)

http://abload.de/img/60khxt8.png
http://abload.de/img/60_4_krbgi.png
http://abload.de/img/60_5_rol23.png
http://abload.de/img/60_5s_fuyzw.png

http://abload.de/img/870qgxi7.png
http://abload.de/img/870_4_4tb58.png
http://abload.de/img/870_5_7caty.png
http://abload.de/img/870_5s_vlx63.png

http://abload.de/img/1570e2act.png
http://abload.de/img/1570_4_j9y18.png
http://abload.de/img/1570_5_featk.png
http://abload.de/img/1570_5s_f6l7i.png

http://abload.de/img/179313ale.png
http://abload.de/img/1793_4_erye1.png
http://abload.de/img/1793_5_icl1d.png
http://abload.de/img/1793_5s_dglkf.png

huhn

14th September 2014, 16:09

Gravitator

14th September 2014, 18:50

i find it very strange that veryslow x264 8 bit gets aliasing but preserve a lot more details compared to default x264 10 bit and has less banding too
10bit is useless / waste bitrate on images with a greater proportion of light areas.

huhn

14th September 2014, 19:29

10bit is useless / waste bitrate on images with a greater proportion of light areas.

no there are multiply test that shows 10 bit helps in all cases.

there is a huge type it is veryslow 8 bit x264 vs default 10 bit x265

Gravitator

14th September 2014, 21:50

no there are multiply test that shows 10 bit helps in all cases.

there is a huge type it is veryslow 8 bit x264 vs default 10 bit x265

Parallel forum for threads x264 vs x265 (http://forum.videohelp.com/threads/365014-x264-vs-x265)

huhn

14th September 2014, 22:56

Parallel forum for threads x264 vs x265 (http://forum.videohelp.com/threads/365014-x264-vs-x265)

sorry its hard to fine useful informations in that thread. a lot of personal things hard to find tests. and the most important part it is pretty old with the last post from 12 july. x265 has matured a lot in the meanwhile.

the first comparison show little effect with 10 bit or 8 this has changed a lot.

and with x264 there is no question that 10 bit has an positive effect on quality.

professor_desty_nova

15th September 2014, 11:58

edit: talking about the 2500 kbit anime test.

i find it very strange that veryslow x264 8 bit gets aliasing but preserve a lot more details compared to default x265 10 bit and has less banding too

veryslow x264 8 bit http://abload.de/img/1570_4_uibrn.png aliased
default x265 10 bit http://abload.de/img/1570_5_hub5z.png more banding missing a lot of details sharper at all

i judge them later with a lot better screen.

X264 has tune for animation (tweaked deblock, Bframes, AQ and psy-rd), and x265 is at default. Maybe tweaking psy-rd, psy-rdoq and AQ might make a difference in detail preservation in animation...

huhn

15th September 2014, 12:35

X264 has tune for animation (tweaked deblock, Bframes, AQ and psy-rd), and x265 is at default. Maybe tweaking psy-rd, psy-rdoq and AQ might make a difference in detail preservation in animation...

as far as I can read no tune was used in these encode.

sneaker_ger

15th September 2014, 13:04

as far as I can read no tune was used in these encode.
"x264 veryslow animation 10 bit" is supposed to mean "x264.exe --preset veryslow --tune animation".

sneaker_ger

15th September 2014, 13:43

New test: non-action packed cartoon/anime, 1000 kbit/s.

My conclusion:
A win for x265 as well which seems to have no problems with edges. x264 on the other always hand shows problems on quite a few of them. I actually did a third pass for x264 because it undershot the bitrate but it couldn't change the result of the match.
Maybe others have better x264 tunings?

Original (https://mega.co.nz/#!AhknDSJQ!Y2Qwi6KivN87sl0ENjxJejPp3jDGjSGjvQiywopHcgU)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!xhcQGQSA!xtdOVDnVl5w4z2g1CKIDzgR2dxSSRyCgjz5l-EZiFM8) (2pass result (https://mega.co.nz/#!dsUUFLBA!nCBqNvpbMh4SvWOO7P3hStBHk8WaxWjevYXRH7lbW-8)) (15.65 fps, 4.15 fps)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!J8NwSKDQ!nBwM5V8kSJ7eA3hYmzDtwjyyMsNqbg71hdrlKF8rYXo) (5.81 fps, 0.77 fps)
x265 --preset slower 10 bit (https://mega.co.nz/#!4o01hKrQ!HJdDaq3D54LoRTh4pJw7OoQfm_XfpQ5pzQCXzJt1Zwo) (6.54 fps, 0.92 fps)

Intel Core i7-860 @ stock
x264 r2479 64 bit from Videolan
x265 r1.3+186 icl 64 bit from Chromashift

http://abload.de/img/118djpdb.png
http://abload.de/img/118_4_14olo.png
http://abload.de/img/118_5_mhqcv.png
http://abload.de/img/118_5_np_xletx.png

http://abload.de/img/2007xojz.png
http://abload.de/img/200_4_fdowr.png
http://abload.de/img/200_5_ssqyx.png
http://abload.de/img/200_5_np_73el8.png

http://abload.de/img/97271q98.png
http://abload.de/img/972_4_esofi.png
http://abload.de/img/972_5_pipcb.png
http://abload.de/img/972_5np_9zeiv.png

http://abload.de/img/1407hdp6o.png
http://abload.de/img/1407_4_93rx3.png
http://abload.de/img/1407_5_wbri4.png
http://abload.de/img/1407_5np_ixf0z.png

Seeing the results x265 might be the new champion for cartoon/animation. These tests were done on clean Blu-Ray sources of modern shows. Maybe older, less "sterile", films yield different results?

lotusgg

15th September 2014, 17:21

sneaker_ger, can you do the tests WITHOUT psy-rd/psy-rdoq on anime sources?
I did some tests with 900bitrate anime and psy-rd seems to be degrading the image.

sneaker_ger

15th September 2014, 18:52

I have added an encode without x265's psy to the last test.

lotusgg

15th September 2014, 22:40

Can you do it in an action/lightning-packed anime?
Like Mahouka or even SNK again.

sneaker_ger

15th September 2014, 23:01

The next test involves old and grainy anime. Bitrate is 7000 kbit/s (2pass).

Conclusion:
x264 does a better job for this noisy source.

x264 r2479 64 bit from Videolan
x265 r1.3+186 icl 64 bit from Chromashift

original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!pwVQjR5I!Bz5G3jdYlBxx8OQzJMfyqB4JobH6F3e-BQO6kxbleis)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!9wNV3bqA!yxaY4z8LiNHSYGrbma9hWNWVV1ZknVnBLGaTXy2rMlU)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!pxVkTJCI!S8JX-KjJvrFsAoRaouIdxZsAzT1fbv0W_OVCD3qFZ2I)

http://abload.de/img/220_btky3.png
http://abload.de/img/220_4a_2akwo.png
http://abload.de/img/220_4g_erohp.png
http://abload.de/img/220_5_jjkrj.png

http://abload.de/img/240_njj10.png
http://abload.de/img/240_4a_qxk0m.png
http://abload.de/img/240_4g_vxqfm.png
http://abload.de/img/240_5_0ykf6.png

http://abload.de/img/770_c7kko.png
http://abload.de/img/770_4a_2gjhx.png
http://abload.de/img/770_4g_lpq7g.png
http://abload.de/img/770_5_gcjbs.png

http://abload.de/img/900_4cjui.png
http://abload.de/img/900_4a_brjp9.png
http://abload.de/img/900_4g_repih.png
http://abload.de/img/900_5_aejol.png

http://abload.de/img/1000_ezjr8.png
http://abload.de/img/1000_4a_u9kwv.png
http://abload.de/img/1000_4g_x8rlw.png
http://abload.de/img/1000_5_npkxg.png

sneaker_ger

15th September 2014, 23:14

Can you do it in an action/lightning-packed anime?
Like Mahouka or even SNK again.
Not that interested right now as x265 already proved itself superior in that test. Since I provided the source file you can easily do it yourself, though. (Also: I don't have every Blu-Ray on earth.)

huhn

16th September 2014, 00:08

I may do a comparison later with a relative new anime that's not from shaft. the animation style from shaft is very compression friendly these days.

I have nearly no experience with 2 pass encodes and I never really used presets too. so it's hard for me to judge what Kbit should be used for the tests.

lotusgg

16th September 2014, 04:14

Try 1000kbit/s and no psy-rd.
If you wish, you can make two tests. One with and other without it.
Just saying, cuz I tested on some non-lossless sources and the non-psyrd ones had less blurring/detail washes and less weird softy blocks inside a nest of grains.

sneaker_ger

16th September 2014, 20:42

Playing around a bit with grain retainment but without any luck (throwing spaghetti at wall). Interested to see if anyone is able to find settings that match x264.

x264 r2479 64 bit from Videolan
x265 r1.3+198 icl 64 bit from Chromashift

Original (from previous test, cropped 22/22 top/bottom, trimmed 634 - 1156)
x264 --preset veryslow --tune grain 8 bit (https://mega.co.nz/#!00cRRI6Z!VJKsdBGD7Rq2pJO4YiytQSyRF70TgYH5Lt_e6GNzAcI)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!Ip0hlbYJ!36QK1_JNS39-xXKQvXMkBG9udpq-RiETZigrXeMg4Io)
x265 --preset veryslow --aq-strength 0.5 10 bit (https://mega.co.nz/#!Fg9xBTgL!QEvx6Hu3j8YJrsG0-40rgdUKvn7_mUZgQHC--k1gphc)
x265 --preset veryslow --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 4.0 10 bit (https://mega.co.nz/#!V4s3mSII!sVrn1h038xHhxGwkcz8gTy4NsesEXNCNGqRpCq6wf3M)
x265 --preset veryslow 10 bit (https://mega.co.nz/#!g0tXhJ7D!xeHIqgYFxoGxZ-eGknVUil4rp14JXskAmTZgh9Nccc0)
x265 --preset veryslow --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!Eh12mChL!r1gV7njbML2WrJMRXSpz8hjR84s1ZoF7rbcvfpk8jZY)
x265 --preset veryslow --aq-strength 1.5 --psy-rd 1.5 --psy-rdoq 5.0 10 bit (https://mega.co.nz/#!940jVZKA!QZpoJPIFyG2rH7BIY2UbLigxC7Wgt4iO8vWkaH6Guck)
x265 --preset veryslow --aq-mode 1 --aq-strength 2 --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!MwlW3QZb!KLERb7cjvqe7ZeeUzcvMknVm2XHBo18nHHdJOsd4PxU)

All 2pass --bitrate 7000. Average 2nd pass fps for x265's preset veryslow was ~0.20 fps vs x264's ~3.2 fps. Watching the clips gives a better idea about the grain than looking at the screenshots.

http://abload.de/img/270_5my3i.png
http://abload.de/img/270_g_igz4x.png
http://abload.de/img/x264_10bitoar34.png
http://abload.de/img/270_1_vdl7g.png
http://abload.de/img/270_2_vdlvs.png
http://abload.de/img/270_3_yha9l.png
http://abload.de/img/270_4_0kzy9.png
http://abload.de/img/270_atak_zvs7k.png
http://abload.de/img/270_destanig_8xsqs.png

/edit Nov 11th 2014:
Added encodes with x265 1.4+55 --preset slower --tune grain:

x265 10 bit (https://mega.co.nz/#!J0VVVCBB!Sbw1OT8_mQ1dVymWcDAbMNHGPFGOkDp7-P07sfcx4LA)
x265 8 bit (https://mega.co.nz/#!kktVjR6A!7loqK-T65T7ODVTwqaY_YiIM3z8VlTHxf2bD41KVVN8)

http://abload.de/img/x265_grain_10_v9uzv.png
http://abload.de/img/x265_grain_8_n3uxj.png

Atak_Snajpera

16th September 2014, 21:55

try aq 1.5 , psyrd 1.5 , psyrdoq 5.

sneaker_ger

16th September 2014, 23:14

Thank you for the suggestion, I have added it to the test above. Can't really say I'm satisfied with the result, though.

destanig

17th September 2014, 12:07

huhn

18th September 2014, 18:04

anime with "rain" in the background at 2mbit

x264-10b-r2479-dd79a61
x265-1.3.198-icl14.0-64

all 2 pass
no lossless source because it is a because it is out of a mainstream from a blu ray
custom: x264_10.exe --ref 6 --bframes 7 --b-adapt 2 --merange 64 --subme 11 --me umh --bitrate 2000 (http://www.file-upload.net/download-9544759/customanimationx264.mkv.html)
veryslow: x264_10.exe --preset veryslow --tune animation --bitrate 2000 (http://www.file-upload.net/download-9544762/veryslowanimeatioonx264.mkv.html)
default x265.exe --bitrate 2000 (http://www.file-upload.net/download-9544760/defaultx265.mkv.html)
slow: x265.exe --preset slow --bitrate 2000 (http://www.file-upload.net/download-9544761/slowx265.mkv.html)

x265 is 8 bit. x264 is 10 bit

frame 27
http://abload.de/img/27hgkhf.png
http://abload.de/img/custom27rckjd.png
http://abload.de/img/veryslow27qek76.png
http://abload.de/img/default276yj86.png
http://abload.de/img/slow27t4kwf.png

frame 166
http://abload.de/img/166h8ycd.png
http://abload.de/img/custom166paa26.png
http://abload.de/img/veryslow166f0xil.png
http://abload.de/img/default1668azb3.png
http://abload.de/img/slow1662rlg0.png

frame 363
http://abload.de/img/363nbydw.png
http://abload.de/img/custom363lnb1w.png
http://abload.de/img/veryslow3631sx0w.png
http://abload.de/img/default363mpz2h.png
http://abload.de/img/slow363ndaes.png

frame 456
http://abload.de/img/456umb8l.png
http://abload.de/img/custom456fwaba.png
http://abload.de/img/veryslow45627lyj.png
http://abload.de/img/default456qbzss.png
http://abload.de/img/slow456shxfi.png

i judge the frames later with a better screen too. but x265 looks better on this bad screen. i guess lavfilter used random dithering on them because i used EVR not madVR and all x264 are 10 bit. i don't used madVr because the dithering always results in huge screens.
all x265 screens are a lot small compared to the x264 screens. i wonder why maybe because I didn't used the highbitdeep version from x265.

sneaker_ger

18th September 2014, 18:48

Yes, I think dithering and 10 bit coding make bigger file sizes when doing PNG on a screenshot. If you enhance the luma plane(?) you'll probably see why. Personally, I don't plan on ever using 8 bit HEVC encoding since we already have hardware support for that so I find it strange that you chose 10 bit x264 vs. 8 bit x265.

As for the results:
They are similar to what we have seen before: x265 does a better job on edges. Preset slow(er) does visibly help.
On the hair at the end x264 some times looks better but it could be a symptom of 8 bit vs 10 bit.

http://abload.de/thumb/456_4_veryslow_aujry.png
x264 very slow 10 bit (http://abload.de/img/456_4_veryslow_aujry.png)
http://abload.de/thumb/456_5_slowukj6x.png
x265 slow 8 bit (http://abload.de/img/456_5_slowukj6x.png)

lwlibavvideosource("veryslowanimeatioonx264.mkv", stacked=true, format="yuv420p16")
DitherPost()
Histogram(mode="luma")
dither_convert_yuv_to_rgb(matrix="709")
lwlibavvideosource("slowx265.mkv")
Histogram(mode="luma")
dither_convert_yuv_to_rgb(matrix="709")

sneaker_ger

18th September 2014, 18:50

You could try --aq-mode 1 --aq-strength 2 --psy-rd 1 --psy-rdoq 1
Switching from auto-variance AQ to constant AQ should do the trick. That's what I've been using for grainy sources though never with 10 bit builds

Thank you for the suggestion - I have added it to the test.

I have done a bunch of additional tests with varying aq and psy options now but so far I've been unable to match x264. Especially in the beginning of the short (not seen in this screenshot) the girl's skirt often turns from grain to uniform in x265's results. I'm giving up for now.

sneaker_ger

18th September 2014, 22:36

One more cartoon test, this time less SFX packed but still some action. Mixed light and dark scenes. 2500 kbit/s 2pass.

Conclusion:
Again a win for x265.

x264 r2479 64 bit from Videolan
x265 r1.3+199 icl 64 bit from Chromashift

original (https://mega.co.nz/#!E1UnBB6D!jhooOYLQWl_IgGsIFDKFdv3lmqk1blJ5NvEjOktJKgA)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!5p1jgKRT!wCWnWqTWq83kKSoSD8c55J3vw08cBA5uLzQnxVYG1uI)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 (https://mega.co.nz/#!h8lxiaQS!YZunFb1XzwjyNPc8isG2o71d_U-vHkNqpUmkaV1M_i8)

http://abload.de/img/550_b5sk3.png
http://abload.de/img/550_4_u8snj.png
http://abload.de/img/550_5_2ksqb.png

http://abload.de/img/1200_wgs6v.png
http://abload.de/img/1200_4_8lsr3.png
http://abload.de/img/1200_5_qasq2.png

http://abload.de/img/1560_gcs7b.png
http://abload.de/img/1560_4_onscv.png
http://abload.de/img/1560_5_bssl8.png

sneaker_ger

18th September 2014, 22:56

A new hollywood-type test. Bitrate 2500 kbit/s 2pass.

Conclusion:
x264 does a much better job on retaining the textures and the grain.

x264 r2479 64 bit from Videolan
x265 r1.3+199 icl 64 bit from Chromashift

original (https://mega.co.nz/#!x5NDlK4I!LTsz-uNPgtqXFw5bIJtvV6-NZwvFVybkBYg_Ftt7oNY)
x264 --preset veryslow --tune film 10 bit (https://mega.co.nz/#!JttDHKaY!LKjsc7KdABWATdNMKQ71r-hQ7KMeBewQd1rh9VXzcYI)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!JltAAIQY!LExTXgQ0WwNrpaY7gnLKYalE0Ug1X32uiyCTq-lzNYI)

http://abload.de/img/220_musv2.png
http://abload.de/img/220_4_5uszy.png
http://abload.de/img/220_5_pwsbg.png

http://abload.de/img/440_2is52.png
http://abload.de/img/440_4_mesr1.png
http://abload.de/img/440_5_kxswf.png

foxyshadis

18th September 2014, 23:02

original
x264 veryslow animation 10 bit (https://mega.co.nz/#!18ln3IjS!cc2Qf58kLXEdm9MeE-b5wvDwG9GmgLHIdSQSXTE6_ko) (11.06 fps, 1.45 fps)
x265 slow psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!pwUmhCbA!sX1qX4Q_RwlBSrif0RsinTh9zDrf2u81i9Mv3fjtzyw) (4.05 fps, 0.89 fps)
x265 slower psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!xttVhSDD!KaZGE4_mJxVYWyLfm-STGVISJX2Rzd_ypcvV4SC09Rc) (3.09 fps, 0.21 fps)

The main thing this test convinced me of is that there's a big benefit to going beyond slow, in terms of very fine detail. Veryslow is probably a small improvement more, at yet another quartering of the speed. Very interesting, that would make more sense for anything resized down.

sneaker_ger

19th September 2014, 19:42

The main thing this test convinced me of is that there's a big benefit to going beyond slow, in terms of very fine detail.
Yes, I though so as well. It's no coincidence I used at least preset slower for all tests after that one.

Veryslow is probably a small improvement more, at yet another quartering of the speed. Very interesting, that would make more sense for anything resized down.
Resizing down might be a good test. x264's smaller blocks might put it at a disadvantage at 1080p and most Blu-Rays don't have that much detail anyways.

sneaker_ger

19th September 2014, 22:01

New test, basically post #88 (http://forum.doom9.org/showpost.php?p=1694097&postcount=88) but downsized to 720p (AviSynth's spline36resize).

Conclusion:
Still a win for x265 overall but the differences are often small.

x265 preset slower vs. x265 preset veryslow: very small differences. Not even sure whether veryslow is better or worse than slower.

x264 r2479 64 bit from Videolan
x265 r1.3+199 icl 64 bit from Chromashift

original
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!Y48wwIRQ!6DbbIs9Jdd0XYkKaZ4UoGhkLHfmhYHlk7Y8lsHiy12o) (2nd pass: ~4fps)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!EktzgZJI!a7JE5ha6v7EpiTWYWUEPmBKvgXtbJ6O785ssu0lWkPo) (2nd pass: ~0.5 fps)
x265 --preset veryslow --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!sh8xQBxQ!7ZST-repEQPy1r1kgdl_CHETG0ML5aS7Gc-6J8QUuto) (2nd pass: ~0.3 fps)

http://abload.de/img/550_r6kle.png
http://abload.de/img/550_4_wkuqp.png
http://abload.de/img/550_5s_d5jrs.png
http://abload.de/img/550_5vs_c9kwk.png

http://abload.de/img/1200_gdkm5.png
http://abload.de/img/1200_4_ptuas.png
http://abload.de/img/1200_5s_uzka2.png
http://abload.de/img/1200_5vs_rrk11.png

http://abload.de/img/1560_41kqs.png
http://abload.de/img/1560_4_0euwn.png
http://abload.de/img/1560_5s_exker.png
http://abload.de/img/1560_5vs_chjqm.png

lotusgg

20th September 2014, 00:54

How can I losslessly capture frames of my choice?
How can I differenciate I from P or B?

Sharc

20th September 2014, 11:08

A new hollywood-type test. Bitrate 2500 kbit/s 2pass.

Conclusion:
x264 does a much better job on retaining the textures and the grain.
.....
original (https://mega.co.nz/#!x5NDlK4I!LTsz-uNPgtqXFw5bIJtvV6-NZwvFVybkBYg_Ftt7oNY)

Perhaps a bit off topic: I took your hollywood clip for a "high compression" test scenario (http://forum.doom9.org/showpost.php?p=1694252&postcount=21171)x264 vs x265, aiming at same PSNR. The file size reduction is amazing (forget about grain retention; still watchable though).

Atak_Snajpera

20th September 2014, 11:18

PSNR is useless for human eyes/brain ;) Higher value does not mean better quality. All psy algos in fact reduce PSNR scores.

Sharc

20th September 2014, 11:37

PSNR is useless for human eyes/brain ;) Higher value does not mean better quality. All psy algos in fact reduce PSNR scores.
Absolutely, but comparing individual frames is also problematic.
For my compression tests I actually disabled all the aq and psy's in order to make the PSNR perhaps more comparable/meaningful. I also watched the clip - with my eyes of course.
I am not aware of any perfect metric for the "quality" rating. The problem is that one often focuses on certain criteria like details, grain, dark scenes, high motion, flat areas, fading scenes, fog .... etc. -- not easy.
My main point was the huge reduction of the original file size, still producing a "watchable" result. :)

lotusgg

20th September 2014, 18:23

Testing with a colorful, bright anime packed with action and also dark scenes at 1000kbit/s.

Don't know how to capture certain frames from a clip, so I will let the sources here and hope someone PM me with a solution.

Lossless (http://www.firedrive.com/file/3EB7AB54091B1A8A) - 2.3gb
x264 10bits CUSTOM --preset placebo --bitrate 1000 --ipratio 1.0 --pbratio 1.0 --aq-mode 2 --me umh --subme 10 --psy-rd 0.00:0 (https://mega.co.nz/#!aNARzART!fa9OkUhQDax8lWwC0z2r8VFml34FuIwFmf4rXqGBrDE) - 25mb - encoding speed: ~1,50fps
x265 10bits CUSTOM --preset medium --weightb --bframes 16 --rc-lookahead 40 --merange 57 --no-open-gop --min-keyint 25 --ipratio 1.0 --pbratio 1.0 --ctu 64 --aq-strength 1 (https://mega.co.nz/#!rFgF1TBS!kAHeINw1KvrEwiJ6rhSpZlUPc2P_D8SLP0bvirSP4aQ) - 25mb - encoding speed: ~3,20fps

x265 was faster than x264.
didn't watched it yet, because it's on the ded's drive and my internet is super lazy today.

Atak_Snajpera

20th September 2014, 18:29

LOL placebo vs medium. No wonder x265 was faster. What a surprise !

lotusgg

20th September 2014, 18:31

B-But it was custom.
Medium is just because I'm lazy to put it on veryslow and remove some params, since I use it ever before 1.1 release.
Also, x264 got reduced some params there.

sneaker_ger

21st September 2014, 08:36

didn't watched it yet, because it's on the ded's drive and my internet is super lazy today.

I did watch it. This is so bitrate-starved that it may come down to what artifacts you prefer. My preference changes from scene to scene.

sneaker_ger

22nd September 2014, 07:54

Crowdrun 1080p50 (https://media.xiph.org/video/derf/y4m/crowd_run_1080p50.y4m) at placebo settings, ~9200 kbit/s.

Nothing new or surprising, x265 blurs details while x264 has other more pronounced artifacts.

x264 r2479 64 bit from Videolan
x265 r1.3+226 icl 64 bit from Chromashift

original (https://media.xiph.org/video/derf/y4m/crowd_run_1080p50.y4m)
x264 --preset placebo --crf 30.1 --keyint infinite --tune film --open-gop 10 bit (https://mega.co.nz/#!g4VACBrA!2wJcCk6Owc7IhySV1R5CaTBrqODOV_KjmeeFtk5F1mU) (0.5 fps)
x265 --preset placebo --crf 40 --keyint -1 --bframes 16 --ref 16 --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!R8cmCB5Q!RIWKvWaziVM9ZPfUQLqAUuK5lw-Oq3QxmerqRkHe8Dc) (0.05 fps)

http://abload.de/img/380_v4ucv.png
http://abload.de/img/380_x264_placebo_y0ut2.png
http://abload.de/img/380_x265_placebo_7uu5z.png

Both used 1 I frame but x264 used 75 P frames while x265 used 125 P frames.

huhn

22nd September 2014, 11:42

is there a good reason why x265 make the picture more dark in general and it looks more red?

foxyshadis

23rd September 2014, 00:08

is there a good reason why x265 make the picture more dark in general and it looks more red?

That's the HEVC decoder, not x265's fault. It's a good idea to always explicitly signal VUI characteristics, since apparently not all of them use the <=540 is BT.601, >540 is BT.709 rule.

vivan

23rd September 2014, 00:28

Then this would be renderer's fault, but this is not the case since we're using madVR.

Probable he is talking about provided screenshots? By default x265 butchers chroma way more, maybe think this why it looks like this (but, honestly, it's the opposite for me - less detailed looks brighter).
U channel from screenshots above:
http://2.firepic.org/2/images/2014-09/23/s2tbnwxklh95.png
http://2.firepic.org/2/images/2014-09/23/91c0hjbmhnrb.png

huhn

23rd September 2014, 03:48

histogram avg color:

x264:
lumi: 90.52
red: 95.18
green: 89.72
blue: 82.04

x265:
lumi: 90.37
red: 95.58
green: 89.34
blue: 81.64

if I look at these histogram data the x265 is not as bright as x264 but the red channel this has a higher value compared to the x264 encode.

I see a red tint in any color in the x265 screenshoot the white looks red compared to x264 screenshoot or the orignal source. even the trees look more red.
I think x265 does something wrong here.

benwaggoner

24th September 2014, 18:54

Personally, I don't plan on ever using 8 bit HEVC encoding since we already have hardware support for that...
Unfortunately there will be a lot of 8-bit only mobile chipsets in devices.

lotusgg

30th September 2014, 20:17

aq-mode 2 and psy vs aq-mode 1 and no psy
http://screenshotcomparison.com/comparison/93743

someone named 'x265' posted it on a chat, credits to him.

huhn

1st October 2014, 02:33

aq-mode 2 and psy vs aq-mode 1 and no psy
http://screenshotcomparison.com/comparison/93743

someone named 'x265' posted it on a chat, credits to him.

hard to judge both are very bad. I don't know the source but looks like aq 2 with psy is a little bit better. CRF 21 is simply not good enough.

lotusgg

8th November 2014, 00:31

Testing RDOQ in anime grain retention.
source is 1080p grainy anime blu-ray. It has digital grain and also scenes without any grain, scenes with high motion, high detail and lots of lightning plays.

x264 lossless (http://zorofiles.com/k4xrgjbubcxh) - 2gb (rename .test to .mp4 or just open with the player of your choice.)

High RDO and low AQ1 method:
x265 crf18 (http://www.solidfiles.com/d/c5209420dd/00000.hevc) settings: http://prntscr.com/543jd1 - 0.43fps - 300mb
x265 crf14 (http://www.solidfiles.com/d/356963ef9b/00000_2.hevc) settings: http://prntscr.com/54h6fx - 0.40fps - 460mb

No psy and high AQ1 method:
x265 crf18 (http://zorofiles.com/23aniq7m87b9) settings: http://prntscr.com/54eqks - 0.38fps - 540mb
x265 crf14 (http://zorofiles.com/9dlqeyb73j52) settings: http://prntscr.com/54eq25 - 0.32fps - 800mb

Will edit with more tests.

microchip8

8th November 2014, 01:43

hard to judge both are very bad. I don't know the source but looks like aq 2 with psy is a little bit better. CRF 21 is simply not good enough.

I prefer the second (aq1 nopsy)

sneaker_ger

11th November 2014, 21:15

Playing around a bit with grain retainment but without any luck (throwing spaghetti at wall). Interested to see if anyone is able to find settings that match x264.
[...]

Added two encodes with x265 1.4 --tune grain to the test. Quite a difference between 10 bit and 8 bit.

lotusgg

12th November 2014, 03:41

lol.
8bits performed better?

sneaker_ger

12th November 2014, 17:29

Yes. x264 10 bit does not have this problem.

Motenai Yoda

19th December 2014, 11:08

x265_Project

20th December 2014, 20:20

Imho x265 performs pretty good on I-frames but bad on P/B frames

x264 (142.2491kmod_8bit_x64) settings: --preset veryslow -p 2 -B 1460 --profile high --level 4.1 --vbv-maxrate 24000 --vbv-bufsize 24000 -f -2:-1 -b 8 -r 5 --tune film --psy-rd 1.1:0.3
x265 (1.4+208_8bit_x64) settings: -p medium --rdpenalty 1 --tu-intra-depth 3 --tu-inter-depth 3 --b-intra --weightb --psy-rd 1.0 --rd 4 --psy-rdoq 1.0 --rc-lookahead 40 --crf 21

Source 038295 http://www.imagebam.com/image/23c7f3373876529
Source 038296 http://www.imagebam.com/image/3afdc0373876667

x264 038295 http://www.imagebam.com/image/61bfbc373876774
x264 038296 http://www.imagebam.com/image/819874373876893

x265 038295 http://www.imagebam.com/image/5b3a3d373876988
x265 038296 http://www.imagebam.com/image/42dd57373877153
Your rate control settings are very different, and they don't seem to make sense. You're setting x264 to an average bit rate of 1460 kbps, using 2 pass rate control. Meanwhile, you're setting x265 to --crf 21.

When I try these settings I get massively different bit rates.

If you want to compare x264 and x265 fairly, I suggest that you don't try to adjust all of the parameters that the performance presets already take care of (GOP structure, # of ref frames, other quality algorithms, profiles, levels, depths, etc.). Try something like...

x264 --preset XXXX --bitrate YYYY
x265 --preset XXXX --bitrate YYYY (or YYYY/2, or somewhere in between)

If you want to add psy-rd to x265, I suggest a nominal amount... --psy-rd 0.2 --psy-rdoq 1.0.

Motenai Yoda

21st December 2014, 16:57

Your rate control settings are very different, and they don't seem to make sense. You're setting x264 to an average bit rate of 1460 kbps, using 2 pass rate control. Meanwhile, you're setting x265 to --crf 21.

I set 1460kbps for x264 (avg quant 28.409) to match the bitrate give me by x265 at --crf 21
also I tryed those settings (depth/psy/rd) to maintain at least some detail/grain (I forgot to remove some parameters for x264, vbv, profile,level)
ps highest x265's presets are too slow on my pc

my point is the washout from I-frames to other frames with x265 while with x264 are still comparable.

benwaggoner

23rd December 2014, 20:46

This is still a prey apples-to-kumquats comparison. What are your dependent and independent variables you are shooting for?

B-intra isn't the first thing I'd add to medium to try to address these issues. --tune-grain might be worth trying for detail preservation as an experiment.

-Ben Waggoner (via TapaTalk)

Boulder

11th January 2015, 19:46

I tried comparing x264 and x265 and came to the conclusion that at least with the default settings of presets, x265 smooths the picture too much. I encoded a short snippet of Hot Fuzz in CRF mode, x264 had CRF18 and x265 needed CRF14.75 to produce about the same final bitrate.

Settings for x264 : --stdin y4m - --sar 1:1 --open-gop --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset veryslow --tune film --crf 18
Settings for x265 : --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset slow --crf 14.75

The high smoothing can easily be seen in frames around 600 or so by looking at the windows in the background. The x265 encodes with a higher CRF would naturally smooth the image even more. Actually it smooths so much that a denoiser would not be necessary anymore and that is something I don't like. However, I see a lot of potential there, I just hope that the promise of improved efficiency is not fulfilled with such tricks :)

I'm also going to encode the same clip at the same CRF with presets slower and veryslow and see if there is any improvement. They are just too slow to use in full-length encodes at the moment (on an i5-4670K at least).

The clips are here to download, I also put the original file there so you can try yourself. Please let me know if this is not a "fair use" case and I'll remove those.

https://drive.google.com/folderview?id=0BzeF_1syecQwQjB2T1N5Mm93dU0&usp=sharing

a5180007

15th January 2015, 13:46

Is it fair to compare smoothness in x264 with psy and x265 without ?

Boulder

15th January 2015, 13:53

Well, I'd expect that most regular users use the default values and as the developers often state: "Use presets unless you have a really good reason not to."

Hiritsuki

16th January 2015, 06:34

--no-sao is good for quality.

Audionut

7th February 2015, 02:07

The last time I used x265 was about 8 months ago, and the quality was to be expected given the development infancy. Just tried again with the latest build by LigH, things have improved immensely, both speed and quality. :)

ducks_take_off_1080p50.y4m

x265_Win64_64bpp.exe -o output.hevc input.y4m
x264_Win64_10bit.exe --crf 31.6 input.y4m output.mkv

https://dl.dropboxusercontent.com/u/34113196/x265.hevc
https://dl.dropboxusercontent.com/u/34113196/x264.mkv

y4m [info]: 1920x1080p 1:1 @ 50/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High 10, level 4.2, 4:2:0 10-bit
x264 [info]: frame I:2 Avg QP:50.35 size: 81802
x264 [info]: frame P:251 Avg QP:52.02 size: 37366
x264 [info]: frame B:247 Avg QP:53.78 size: 6177
x264 [info]: consecutive B-frames: 1.2% 98.8% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.1% 71.8% 22.1%
x264 [info]: mb P I16..4: 0.6% 1.6% 0.1% P16..4: 50.2% 19.2% 10.9% 0.0% 0.0% skip:17.3%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 41.3% 0.6% 0.2% direct: 0.6% skip:57.2% L0:15.6% L1:82.5% BI: 1.8%

x264 [info]: 8x8 transform intra:70.7% inter:74.1%
x264 [info]: coded y,uvDC,uvAC intra: 58.4% 64.7% 35.6% inter: 25.3% 17.1% 0.8%
x264 [info]: i16 v,h,dc,p: 4% 83% 3% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 39% 14% 3% 6% 3% 19% 2% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 52% 12% 3% 5% 2% 12% 1% 8%
x264 [info]: i8c dc,h,v,p: 62% 32% 4% 2%
x264 [info]: Weighted P-Frames: Y:4.8% UV:2.0%
x264 [info]: ref P L0: 90.5% 5.8% 3.6% 0.1%
x264 [info]: ref B L0: 98.0% 2.0%
x264 [info]: kb/s:8854.55

encoded 500 frames, 22.69 fps, 8855.13 kb/s

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 frames 0 - 499 of 500
x265 [info]: HEVC encoder version 1.4+527-d26268f9dc19
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4.1 (Main tier)
x265 [info]: WPP streams / frame threads / pool : 17 / 3 / 8
x265 [info]: Internal bit depth : 10
x265 [info]: CTU size / RQT depth inter / intra : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 psy-rd=0.30 deblock sao signhide tmvp
x265 [info]: frame I: 3, Avg QP:36.35 kb/s: 34836.93
x265 [info]: frame P: 124, Avg QP:36.74 kb/s: 25119.47
x265 [info]: frame B: 373, Avg QP:39.85 kb/s: 3166.34
x265 [info]: global : 500, Avg QP:39.06 kb/s: 8800.74
x265 [info]: Weighted P-Frames: Y:21.0% UV:13.7%
x265 [info]: consecutive B-frames: 1.6% 0.8% 0.0% 97.6% 0.0%

encoded 500 frames in 82.58s (6.06 fps), 8800.74 kb/s

sneaker_ger

12th February 2015, 23:45

Revisiting the old grainy anime test (http://forum.doom9.org/showpost.php?p=1693863&postcount=81) with x265 1.5:

Conclusion: x265 still does away with lots of the grain.

7000 kbit/s 2pass
x264 2525 --preset veryslow --tune grain
x265 1.5.11 --preset slower --tune grain

x264 8 bit (https://mega.co.nz/#!w4cDEa6K!BKU1HWLB3xHrP34e35q8RoAC8-KZjdJFLt7f4Pggweo) (2nd pass: 3.18 fps)
x264 10 bit (https://mega.co.nz/#!c5VG0LKJ!eYHoBLxzpvdmPC_Ld83hoaNV4et_ic9PsyjlWupg3LA) (2nd pass: 1.89 fps)
x265 8 bit (https://mega.co.nz/#!RwNFnIoZ!9oFRdEK8Z5nKoj-QzVFTEr8N-sckE26p_83s9ktSrV8) (2nd pass: 0.56 fps)
x265 10 bit (https://mega.co.nz/#!8t9VXaJZ!Gg1HuJMn50R7PwC518PfNejQEJCA6ZIfqH7EkMiCS6M) (2nd pass: 0.44 fps)
package of screenshots + logs (https://mega.co.nz/#!I40FnKDB!dNJAv0kWHxeUt_89OKPwQcWXJuoXI714nQy9HfNdqxQ)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264g_8bit_nibbh.png
http://abload.de/img/270_x264g_10bit_rsxdp.png
http://abload.de/img/270_x265g_8bit_xgll8.png
http://abload.de/img/270_x265g_10bit_r6xqw.png

/edit:
fixed "original" screenshot

huhn

13th February 2015, 12:34

the original picture is not cropped in the same way as the encode results.

I would say x264 even with 8 bit outperforms x265 10 bit in this case.

x265 is really blurry in this case.

benwaggoner

23rd February 2015, 00:51

So, lots of different opinions about x264 v. x265 out there. There've been a bunch of quality improvements in x265 in the last month or so, so I thought I'd give it all a swing through my standard stress test settings using Tears of Steel. Interestingly, the quality differences weren't that big at my old 3 Mbps CBR rate, so I went down to 2 Mbps (for 1920x800!) so we could really see some differences.

My stress test parameters emulate a classic streaming case.

2 Mbps Constant Bitrate
Max 4 sec Variable Closed GOP
VBV=4 seconds of content, so 8000 Kbps
All quality v. speed knobs turned up to 11
All encoders get the appropriate psychovisual tweaks for the content
2-pass encoding

Here's my x264: https://www.amazon.com/clouddrive/share/fixwjTKQyNIgLxUzTeXz-4b5qpOQ_uhXk81TchNeqc8

And my x265: https://www.amazon.com/clouddrive/share/YSZCWMHmhXYnQgnjCwK4HWGN_8M1OesaDlOf-J6M6BU

x264 parameters: --level 4.0 --preset placebo --pass 2 --bitrate 2000 --stats ".stats" --keyint 96 --min-keyint 8 --vbv-bufsize 8000 --vbv-maxrate 2000 --merange 32 --aud --nal-hrd cbr --colorprim bt709 --transfer bt709 --colormatrix bt709

x265 parameters: --level-idc 40 --pass 2 --preset placebo -F 1 --pmode --cu-lossless --subme 7 --tskip --bframes 16 --ref 6 --keyint 96 --rc-lookahead 96 --no-open-gop --bitrate 2000 --vbv-maxrate 2000 --vbv-bufsize 8000 --colorprim bt709 --transfer bt709 --colormatrix bt709 --repeat-headers --hrd --au

As expected, the x265 was about 8x slower than x264, which isn't crazy. And I'm sure nearly identical quality could have been gained at much higher speed for both.

At this low bitrate, x265 is definitely better than x264 for action and higher motion scenes, although they look pretty darn similar for lower-motion scenes. Man, codecs have come a LONG way!

Anyway, tell me what y'all think.

I'm not sure whether my next test should be at VideoCD bitrates :). It's amazing to think how much better quality we can get, even per-pixel, with 15x more pixels. Not bad for just 20 years!

I'd be happy for VP9/Daala/etcetera experts to provide equivalent clips to the same specs for comparison purposes. I think I'll do a VC-1 test just to shame my former self.

mandarinka

23rd February 2015, 21:54

benwaggoner

23rd February 2015, 21:59

I view WPP as an essential decoder side optimization, so I always use it. I would prefer I the universe forgets that a non-WPP mode ever existed, like all those Baseline-but-not-Main features of H.264.

benwaggoner

23rd February 2015, 22:00

Also, with --pmode I'm still able to get around 50-65% utilization on my 16 core (32 thread) workstation.

foxyshadis

23rd February 2015, 23:30

Not hardcore enough, it still has WPP on :D
But encoding your sample in how many (16?) segments is not fun. But maybe disabling WPP and using more frame threads instead would help quality (probably, I didn't try myself).

WPP is NOT slicing and it'll usually (minimally) increase quality, not decrease it. WPP only changes the way the final lossless compression works, it's not the large quality/speed tradeoff that people associate with x264 slices, although measuring it is pretty complex with RDO. I'd say it's one of the best special-purpose lossless compression methods I've ever seen.

Not using WPP slows both your encode and decode down for no good reason.

xooyoozoo

24th February 2015, 00:34

WPP only changes the way the final lossless compression works

In addition, it should be possible to do a bitstream-level "remuxer" that losslessly transforms a file between non-WPP and WPP.

There's no need for such a thing right now, but for all we know, the next several generations of hardware HEVC encoders could completely ignore WPP.

mandarinka

24th February 2015, 18:36

WPP is NOT slicing and it'll usually (minimally) increase quality, not decrease it. WPP only changes the way the final lossless compression works, it's not the large quality/speed tradeoff that people associate with x264 slices, although measuring it is pretty complex with RDO. I'd say it's one of the best special-purpose lossless compression methods I've ever seen.

Not using WPP slows both your encode and decode down for no good reason.

It is not slices but AFAIK even x265 developers say that it does decrease compression some (more than frame threads do). I wouldn't normally suggest to disable it, but since OP already disabled frame threads...

x265_Project

25th February 2015, 07:49

It is not slices but AFAIK even x265 developers say that it does decrease compression some (more than frame threads do). I wouldn't normally suggest to disable it, but since OP already disabled frame threads...
I hesitate to contradict Foxyshadis. However WPP is not likely to increase compression efficiency. If anything there might be a very slight decrease. See http://x265.readthedocs.org/en/default/threading.html#wavefront-parallel-processing

However, Wavefront Parallel Processing is massively better than using multiple tiles or slices per frame, both in terms of compression efficiency and in terms of parallelism (effective utilization of many-core machines).

benwaggoner

25th February 2015, 15:01

WPP is also what can make pure software or software + GPU decode FASTER than H.264 decode on multicore systems, with Windows 10 and Android L as two major examples.

We should act like HEVC non-WPP doesn't exist in the same way we mainly act like H.264 slices don't exist*.

*With the sad exception of Blu-ray above level 4.0.

sneaker_ger

31st March 2015, 21:25

New sample with grainy film. 5000 kbit/s 2pass.

It becomes harder and harder to find places were x265 loses against x264. I actively have to search for them now instead of just posting random screenshots. One remaining problem is some larger blocks turning flat.

x264 10bit (64) r2538 from Videolan
x265 1.5+452 high bitdepth Chromashift ICL

original (https://mega.co.nz/#!JtFDjaAC!x08kgvwP1dKWRiWTYy1fhmbYy-uzKWjh4X_aNR3ooSM)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!lptCVIaI!miWT43qqMY377Pt8hmoO6VGlZNzq-fUqvYwN2u0Uqm8)
x265 --preset slower --tune grain 10 bit (https://mega.co.nz/#!BocjHDaD!5ljTbNTMAXpDkJePZNUvEU7fFPjaTVwFIVW3aSo47kY)

http://abload.de/img/340_original_fzuqe.png
http://abload.de/img/340_x264_htutj.png
http://abload.de/img/340_x265_8guuf.png
Notice flat blocks on the paper in x265 encode, esp. in the region around the red line

http://abload.de/img/1414_original_h2u7d.png
http://abload.de/img/1414_x264_iwuq4.png
http://abload.de/img/1414_x265_qiucc.png
Notice flat blocks on the walls in the top-left part of the picture in x265 encode (zoom (http://abload.de/img/1414_x265_zoom_e0axq.png))

(encodes with 8 bit and/or rdoq-level 2 available on request)

Boulder

31st March 2015, 22:18

McConaughey's jacket seems to lose texture quite noticably in the x265 screenshot. The bad thing is that if you don't use --tune grain, you are bound to lose even more details :(

I wonder why the door doesn't have the same issue in the same magnitude, or the wall lower from where you have the zoomed image (slight flattening but not as bad as it could be).

sneaker_ger

31st March 2015, 22:27

I don't know. Looks like it's close to some kind of threshold. You will also see more of the blocks on the door if you frame-step through the video. The flat blocks come and go in a seemingly random fashion.

smegolas

1st April 2015, 19:48

New sample with grainy film. 5000 kbit/s 2pass.

It becomes harder and harder to find places were x265 loses against x264.

In those clips it's hard to find places where x265 wins against x264. (yes I can find a few)

x265 encode still looks like it's gone through a bad DNR filter.

http://screenshotcomparison.com/comparison/119588

Sparktank

1st April 2015, 19:57

http://screenshotcomparison.com/comparison/119588

Both look pretty severe.
The x264 shot looks like it got a lot of artificial sharpening while the x265 looks like it got smeared with mud.
The details on his brown coat (the creases) are too much in the x264 and are too little in the x265.

The walls look clean in x265 though.

sneaker_ger

1st April 2015, 20:34

The x264 shot looks like it got a lot of artificial sharpening

I don't really see it.
http://abload.de/img/original_jacket_depfb.png
http://abload.de/img/x264_jacket_crqdk.png
http://abload.de/img/x265_jacket_kfrtp.png

Sparktank

1st April 2015, 20:59

His top-right shoulder looks sharper and at first glance it looks like something completely different.
Maybe I just see what I want to see and take too much time looking at details.

Sitting at the desk sees things differently than I would be if I were looking at it 15 feet away when I normally watch.

The shadows the creases form are more defined, however.

smegolas

1st April 2015, 22:40

Both look pretty severe.
The x264 shot looks like it got a lot of artificial sharpening while the x265 looks like it got smeared with mud.
The details on his brown coat (the creases) are too much in the x264 and are too little in the x265.

The walls look clean in x265 though.

I disagree.

The x264 clip has approximately the same sharpness as the source.

The x265 clip has an entirely different character to the source. If I want a smoothing filter i'll apply it myself.

burfadel

2nd April 2015, 09:06

After a bit of playing around, I came up with the following settings for x265, which is good up to 1080P:
--crf 20 --tu-intra-depth 2 --tu-inter-depth 2 --b-intra --bframes 7 --rc-lookahead 60 --ref 7 --subme 3 --merange 24 --max-merge 5 --weightb --aq-mode 2 --nr-intra 400 --nr-inter 400 --pmode

Try that for speed and quality verses just using --crf 20. Of course, I'm pretty 'enthusiastic' with the reference frames and bframes, you could eliminate those two in trying those settings, or set both to say 4, in the aforementioned speed/quality comparison I suggest you do :). You might want to play around with both of those noise reduction settings as well. Choosing the right values means no perceptible loss of quality but 'noticeably' improved compression. Keep in mind that what you save in bitrate with noise reduction, you could potentially put towards your CRF without ending up with a bigger file. What I mean is, if I had CRF 20 without the noise reduction, I could potentially obtain a similarly sized file with CRF 19 with noise reduction, with the other settings remaining the same.

iSunrise

2nd April 2015, 13:18

Notice flat blocks on the walls in the top-left part of the picture in x265 encode (zoom (http://abload.de/img/1414_x265_zoom_e0axq.png))
Thanks for some of your examples sneaker_ger.

I don't get why the x265 encoder leaves some grainy areas mostly intact, while it seems to suddenly "decide" by random to create large blocks with areas of almost one and the same color in other parts of the picture.

Shouldn't this be quite easy to fix? What exactly is the reasoning for this? This seems more like a bug than anything else to me.

An expected result would be that the encoder dials down (averaging them all out by an amount X) on detailed areas in all of these grainy spots (relative to the available bandwidth it has at it's disposal), but instead it seems to choose completely by random to replace some areas of the picture with almost one colored pixels, which completely kills all picture information that's within the uniformly colored blocks.

That completely doesn't make any sense to me. This should not be hard to fix or I seriously doubt that x265 developers know what they're doing. This may sound a bit harsh, but I would really love an explanation for this, because when I look at this I seriously question the state of the encoder.

x265 in this state is not usable, because it seemingly alters the picture by ways of throwing a dice and this is not what anyone could want from it.

Also, with this behaviour present, x264 will remain visually superior with more grain retention and it's also way more predictable.

I hope the developers know what to look for when they see shots like this.

Boulder

2nd April 2015, 13:24

I'm sure the devs know about these issues but it might not be that easy to fix without large amounts of code. I gave them my test clip by request and posted several screenshots showing the problem but I've not heard anything from them yet.

Tommy Carrot

2nd April 2015, 14:00

iSunrise

2nd April 2015, 14:27

I reported about this problem several months ago. They didn't acknowledge this issue and they insisted the problem is on my side. Since then, this behaviour hasn't been improved even a tiny bit, so don't expect it'll be fixed anytime soon.
The problem is on your side? Did they give any details what exactly they assume your problem is?

Because otherwise, this is just an answer that seems totally ignorant and self-protecting, when in fact they seem unwilling to even attempt to fix obvious bugs that end users invest their time to find and report to them.

I hope this is not their official stance on this matter.

Can we have DS back please? At least I got the impression that he knows what he is doing.

While I fully don't expect that x265 can ever be a lot more effective with really heavy grainy sources compared to x264, I at least expect a predictable behaviour with grainy sources and some savings on bitrate compared to x264 in the future.

Boulder

2nd April 2015, 14:35

Tommy Carrot

2nd April 2015, 14:39

The problem is on your side? Did they give any details what exactly they assume your problem is?

Because otherwise, this is just an answer that seems totally ignorant and self-protecting, when in fact they seem unwilling to even attempt to fix obvious bugs that end users invest their time to find and report to them.

I hope this is not their official stance on this matter.

Well, they immediately assumed i've made some mistakes in my testing method. Since then, i saw claims by them about x265 being better than x264 in all circumstances, and i haven't seen any attempt to improve this behaviour, so i assume they don't acknowledge it as a real issue.

iSunrise

2nd April 2015, 14:44

Well, poking some fun out of the situation: the answers have sometimes been like Spinal Tap's classic "but this goes to eleven". To me it seems that they have chosen the path they wish to proceed and are focusing on the current algorithms and making them faster because most people don't care about the issue as we've seen in many replies.

There is a slight chance that they'll go back to these issues we've reported at some point, but I wouldn't hold my breath while waiting. Fortunately x264 is a very good encoder and there is no urgent need to use anything else :)
Currently x264 serves us well, however, the problem i see with x264 is that bandwidth requirements explode with good and reasonably detailed >=4K sources, also Main10 H.265 is there for a reason. It almost seems like the MPEG2 situation from several years all over again (where at a certain resolution a codec just isn't well fit for anymore).

Let's hope this is not the last word we hear from them.

Well, they immediately assumed i've made some mistakes in my testing method. Since then, i saw claims by them about x265 being better than x264 in all circumstances, and i haven't seen any attempt to improve this behaviour, so i assume they don't acknowledge it as a real issue.
This sounds like they are purely marketing driven. Someone is deciding that they want to follow in x264's footsteps when it comes to quality, while completely ignoring facts and samples that show a completely different state. Not a good sign at all. It's like driving through red lights with heavy street traffic present that should alert you that there's clearly something wrong and you just keep on doing it.

sneaker_ger

2nd April 2015, 14:47

Don't forget: they are investing a lot of money for a software we are using for free. And they have been doing work on psy, created a grain tuning, changed default aq mode and recently introduced rdoq-level option. To me it is proof they are working on improving quality, it just does not happen overnight nor is it trivial. I suggest we keep the aggression and entitlement out of this thread on focus on doing comparisons of current state. Providing undeniable proof of problems is more convincing than finger pointing. Everything else is off-topic and should be taken somewhere else.

iSunrise

2nd April 2015, 14:58

And they have been doing work on psy, created a grain tuning, changed default aq mode and recently introduced rdoq-level option. To me it is proof they are working on improving quality, it just does not happen overnight nor is it trivial.
I don't disagree, but improving quality also means to rethink some basic code that may have bugs and not just try to overshadow that by adding additional features that might mask the underlying problem.

Answers like the above, meaning "you are the problem" and not giving any details in return is not a good way to deal with people in general. But that's just my opinion.

However, I don't have access to their codebase nor do I ignore the fact that it's free software. Therefore I just wanted to point out what I see in your shots. And since I have some background in programming and predictable AI, what I see at least rings an alarm. After all, you have provided your shots for a reason, didn't you? We are discussing the current state, and I think I made my stance pretty clear in only two posts, but everyone should feel free to disagree (some explanations why would be nice, though).

Let's follow how the state of x265 continues. H.265 will hopefully spawn lots of upcoming implementations to compare, so they really can't ignore thinks like that in the long run.

I wish everyone happy easter holidays!

benwaggoner

2nd April 2015, 16:38

I don't disagree, but improving quality also means to rethink some basic code that may have bugs and not just try to overshadow that by adding additional features that might mask the underlying problem.
If anyone feels concern about the pace of progress with x265, a quick visit here is always illuminating:

https://bitbucket.org/multicoreware/x265/commits/all

So many commits on so many days, sustained over many many months. Speed improvements, bug fixes, and yes, quality improvements. Remember that --tune grain itself is only about 6 months old. That made for a huge improvement for very noisy content, and with --rdoq-level 1 and other improvements in the last 1-2 months, grain improvement is a whole lot better. For typical film source content @ UHD resolutions, x265 has seen at least a 1/3rd reduction in ABR required for transparent quality versus last summer.

Also, speed improvements ARE quality improvements. If underlying algorithms improve so we can encode with --preset slower at the same speed that we used to get with --preset slow, that gives us better quality in the same encoding time.

Answers like the above, meaning "you are the problem" and not giving any details in return is not a good way to deal with people in general. But that's just my opinion.
I've certainly never heard any blanket feedback like that from them, publicly or privately. Now, they certainly are open that they're focused on video quality when playing back at speed, not at what you see paused and zoomed in on a single frame, so there are "defects" that get reported that aren't necessarily part of their key goals.

However, I don't have access to their codebase
Of course you do. We all do:
https://bitbucket.org/multicoreware/x265/src

...(some explanations why would be nice, though).
That is quite true.

I wish everyone happy easter holidays!
You too. It's really valuable for everyone to keep finding and providing good examples where x265 isn't doing as well as it should. I think the pace of progress should leave us feeling more optimistic, though. I think net improvements are certainly coming faster than in the first 18 months of x264 development!

Boulder

2nd April 2015, 17:52

I've tried to ask whether it even is possible for x265 to reach the level of x264's details/noise/whatever retention without making it just the same as x264 what comes to compression efficiency, but no answers. That, along with no responses to my two samples, is something that always makes you wonder whether they just ignore you for being critical or actually analyze the issue. I am very keen to help whenever I can but it would be nice to know whether I should redo the same tests every few weeks or not, or is the difference just an accepted fact which is very low on priority.

Tommy Carrot

2nd April 2015, 18:02

I've certainly never heard any blanket feedback like that from them, publicly or privately. Now, they certainly are open that they're focused on video quality when playing back at speed, not at what you see paused and zoomed in on a single frame, so there are "defects" that get reported that aren't necessarily part of their key goals.
The issue we are talking about, the blurriness compared to x264 at high quality range is not a single frame issue, it's very noticable during playback too. It is also not limited to grain, normal details which are continously there for several frames are noticably less preserved compared to x264. Also, despite the claims that quality is the main priority, i've seen no effort trying to improve this behaviour for several months, which is a bit disappointing because, as you said, the development is otherwise very active.

benwaggoner

2nd April 2015, 21:25

I've tried to ask whether it even is possible for x265 to reach the level of x264's details/noise/whatever retention without making it just the same as x264 what comes to compression efficiency, but no answers.
It's definitely possible. It's not like there are important tools that H.264 has that HEVC doesn't.

That, along with no responses to my two samples, is something that always makes you wonder whether they just ignore you for being critical or actually analyze the issue.
I've certainly had good results from them with issues I've found. They don't always get fixed right away, but I've always felt taken seriously.

I am very keen to help whenever I can but it would be nice to know whether I should redo the same tests every few weeks or not, or is the difference just an accepted fact which is very low on priority.
I generally keep my eyes on the Commits and retest things when I see a commit has gone in that seems relevant.

I have no doubt that MCW is committed to making it a great encoder for all relevant scenarios, including for what you've demonstrated. Sometimes a fix requires other foundational work that may be in progress. Sometimes there's lower-hanging fruit or higher priorities.

I don't see an issue filed for this on bitbucket. That's been an effective way to get visibility and feedback for a reproducible issue.

https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

Nevilne

2nd April 2015, 21:40

A good example on why issues like that are not always "just a simple fix", from Daala friends:

https://archive.today/lkABe

Boulder

2nd April 2015, 22:53

I don't see an issue filed for this on bitbucket. That's been an effective way to get visibility and feedback for a reproducible issue.

https://bitbucket.org/multicoreware/x265/issues?status=new&status=openThanks, that's good to know. I'll file something over the Easter unless someone else does that before I do :)

EDIT: and I definitely understand that fixes or adjustments regarding visual output are usually not simple. Even if x265 is based on x264, the changes under the hood are substantial and it might not be too easy to jump to x264-model psy just like that.

x265_Project

3rd April 2015, 18:09

This is a very busy time of year in the video business (pre-NAB). I confess that I wasn't keeping up with this thread. x265 isn't just an open-source project - we have many paying customers who we meet with regularly, and we get FAR more feedback than is visible here, and we are working to respond to all of that feedback. While some of our licensees are public, more than half of our paying customers are under NDA; we can't tell you who they are yet. Our customers use x265 in a variety of very demanding environments, from real-time encoding to high quality offline encoding.

As Ben points out, it is possible for x265 to match x264's detail retention. x265 has all of the coding tools of x264, plus many more capabilities found in the H.265 specification (larger block sizes, more accurate prediction, etc.). Quality is job 1, and we continue to focus on every possible way to improve encoding efficiency (visual quality/bit rate). Soon you will see fine-grained AQ, for example. There are many other quality-focused improvements in our development pipeline, but we operate in a competitive market, so it doesn't make sense to tip our hand too early.

Until recently there was a bug in the 1.5 development branch for 2 pass encoding that was causing some loss of fidelity vs earlier builds. The fix was committed just before the 1.6 tag. But I see you were using CRF.

To anyone who thinks building an HEVC encoder is simple, we say; patches are welcomed. The code is available... dive in... these things are simple, right? 19 external contributors have done just that. x265 has over 10,000 commits, with 1.7 million lines of code in those commits. You could be # 20.

sneaker_ger

4th April 2015, 15:57

New sample with grainy film. 5000 kbit/s 2pass.

Now extended by increasing x265 bitrate in 1000 kbit/s steps from 5000 kbit/s to 20000 kbit/s.
Download of all output files, scripts and screenshots: https://mega.co.nz/#F!o41EUSCL!JIrixxUhJM093c1Zz1zZLQ

Frame #761 full:
Original:
http://abload.de/img/761_original_rcued.png

x264 5000 kbit/s:
http://abload.de/img/761_05000_x264p2o6x.png

x265 from 5000 to 20000:
http://abload.de/img/761_05000_ybrad.png
http://abload.de/img/761_06000_wlbas.png
http://abload.de/img/761_07000_1ezsw.png
http://abload.de/img/761_08000_h8yht.png
http://abload.de/img/761_09000_71aw3.png
http://abload.de/img/761_10000_huzxu.png
http://abload.de/img/761_11000_asbv3.png
http://abload.de/img/761_12000_pqzfk.png
http://abload.de/img/761_13000_kozfd.png
http://abload.de/img/761_14000_l1yen.png
http://abload.de/img/761_15000_p5bum.png
http://abload.de/img/761_16000_p2b1l.png
http://abload.de/img/761_17000_umyyr.png
http://abload.de/img/761_18000_j2x24.png
http://abload.de/img/761_19000_mzbn0.png
http://abload.de/img/761_20000_7axvu.png

Zoom on the jacket:
Original:
http://abload.de/img/original_jacket_depfb.png

x264 5000 kbit/s:
http://abload.de/img/x264_jacket_crqdk.png

x265 from 5000 to 20000:
http://abload.de/img/x265_jacket_kfrtp.png
http://abload.de/img/jacket_06000_5jjep.png
http://abload.de/img/jacket_07000_ilkpb.png
http://abload.de/img/jacket_08000_wzlne.png
http://abload.de/img/jacket_09000_1pjiv.png
http://abload.de/img/jacket_10000_jdjy1.png
http://abload.de/img/jacket_11000_gzjqd.png
http://abload.de/img/jacket_12000_ztk97.png
http://abload.de/img/jacket_13000_4qjj4.png
http://abload.de/img/jacket_14000_nwkbu.png
http://abload.de/img/jacket_15000_e3k1s.png
http://abload.de/img/jacket_16000_izjkf.png
http://abload.de/img/jacket_17000_54l4r.png
http://abload.de/img/jacket_18000_ynzau.png
http://abload.de/img/jacket_19000_sxkpv.png
http://abload.de/img/jacket_20000_sxkba.png

I wanted to measure noise level but had no idea how to do it. I assumed PSNR and SSIM aren't suited? Ended up using x264 lossless encoding and noted down the bitrates but it didn't seem to be very suitable either. I decided to post the results anyways:
original encoded to x264 lossless preset verfast bitrate in kbit/s:
original: 230565.62

x264 encoded to x264 lossless preset verfast bitrate in kbit/s:
5000: 160547.44

x265 encoded to x264 lossless preset verfast bitrate in kbit/s:
5000: 151798.45
6000: 156417.23
7000: 160516.07
8000: 164185.88
9000: 167596.54
10000: 170695.65
11000: 173436.37
12000: 175990.86
13000: 178269.70
14000: 180476.15
15000: 182604.95
16000: 184780.61
17000: 186720.98
18000: 188712.88
19000: 190538.81
20000: 192498.96

/edit: fixed jacket screenshots 8000, 17000, 18000 + 761_original

iSunrise

4th April 2015, 20:09

You too. It's really valuable for everyone to keep finding and providing good examples where x265 isn't doing as well as it should. I think the pace of progress should leave us feeling more optimistic, though. I think net improvements are certainly coming faster than in the first 18 months of x264 development!
Thx benwaggoner.

BTW, do you still happen to have your lagarith "The Island" lossless master somewhere? I tried to access your Skydrive link, but it seems the file has been moved (since MS renamed their service to OneDrive) and is not accessible anymore.

Want to do a few tests on my own, but for tests to make any sense I would love to have access to a real film source that is not pre-compressed.

Would be much appreciated!

benwaggoner

4th April 2015, 21:00

Thx benwaggoner.

BTW, do you still happen to have your lagarith "The Island" lossless master somewhere? I tried to access your Skydrive link, but it seems the file has been moved (since MS renamed their service to OneDrive) and is not accessible anymore.

Want to do a few tests on my own, but for tests to make any sense I would love to have access to a real film source that is not pre-compressed.

Would be much appreciated!

I think I've got a Lagarith version around somewhere. I'll try to find it later and pit it somewhere accessible. So nice to not have a 50 MB per file limit anymore!

Boulder

5th April 2015, 20:41

Thanks, that's good to know. I'll file something over the Easter unless someone else does that before I do :)OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D

benwaggoner

5th April 2015, 21:12

OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D
You've already done a lot more than that :)!

You (and anyone else who's made it this far in this thread) have certainly earned the right to come to my 15th Annual Compressionist Party at NAB on April 14th, if you're at the show.

http://www.evite.com/event/02C7DOTVASHSEA5G2EPE3PFAAV7EHU

iSunrise

5th April 2015, 23:09

OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D
Just as a heads-up, I just clicked on your report and wanted to preview the files. It seems that your sample links have accidentally been truncated. You will need to fix this for them to have a look, too. It seems they have already assigned your report, though, looks promising!

Let's wait and see what they have to say about this.

Boulder

5th April 2015, 23:51

Dang, you're right. I'll have to comment and add correct links there. Thanks for the heads up :)

stax76

6th April 2015, 01:56

I have a question to the testers, how exactly did you make the images? Which tools did you use, could a utility be useful and which features would it need?

Boulder

6th April 2015, 09:27

I always load stuff in Virtualdub (decode in script with FFVideoSource), export a snapshot to clipboard, then paste and save in IrfanView. A utility would be nice, maybe load clips to compare and preview a frame to export. I don't know if you can parse the frame type (I, P or B) but that would be very useful too when comparing.

nikusor665

6th April 2015, 11:16

Is x265 really that bad at retaining detail/grain ? Does that mean that H265 which will be on the 4k BD will not retain grain ? Cause if its so, than thats a disaster. :scared:

birdie

6th April 2015, 13:26

Is x265 really that bad at retaining detail/grain ? Does that mean that H265 which will be on the 4k BD will not retain grain ? Cause if its so, than thats a disaster. :scared:

Currently at low bitrates, yes.

birdie

6th April 2015, 13:27

Boulder

6th April 2015, 14:28

I fixed those in a separate comment, but for some reason you cannot see the comments unless you are logged into Bitbucket.

stax76

6th April 2015, 18:03

I'm building the image grabbing utility into StaxRip now, for every source file opened a tab is created to draw the image on so you can compare directly by switching the tabs, for frame type info it'll rely on a csv file being present which x265 can create, I'll add a checkbox to create it in the x265 dialog, if anybody has special requirements please describe.

I would like to keep it as simple as possible like writing scripts and images in the folder of the source.

What should be drawn on the image? Only the filename?
Is PNG export sufficient and how should the image file names be composed?

Any special AviSynth requirements? So far it generates a very basic script to open the files:

FFVideoSource("test.mkv")
ConvertToRGB(matrix="Rec709")

stax76

7th April 2015, 01:54

The utility is finished, it looks like this:

http://s21.postimg.org/71vly217a/Unbenannt.jpg

First test I made with it at 1000 Kbps and 720p, x265 as usual performing poor:

http://s17.postimg.org/q965vh2jx/2116_nv264.png
http://s17.postimg.org/vymefs8q5/2116_nv265.png
http://s17.postimg.org/twlx1jar1/2116_x264.png
http://s17.postimg.org/c7u69wyzx/2116_x265.png

the utility is available here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

it must be used on top of the last release:

http://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.2.2.1_beta.7z/download

iSunrise

7th April 2015, 10:56

Wow stax76, that is fantastic work!

I have searched ages for a tool that does exactly that, one that does compare the encoding settings I choose without the need to always have to do manual captures, analyze them in a browser (via tabs) and then re-do the same extremely time-consuming process again and again to look for differences.

What would make the tool perfect:

1) Fast/direct access to the encoder options/parameters (so you can change the values directly) and then real-time viewing (as soon as it got encoded with the new settings) of the result (if I understand this correctly, this may already work, since StaxRip is always running in the background anyway, so is this already possible?)

2) A zoom function for specific image coordinates, which then are identical for all tabs

3) Possibility to have one tab as a reference point (the source) so you can also visually compare the encodes to the source without having to leave your utility

Not only does that allow us to do perfectly valid comparisons, but also to find more problems with specific x265 weaknesses (parameters) and report them to the x265 developers, while we would not have to question whether we did something wrong ourselves or someone messed up somewhere in their workflow when presenting the results here.

If it's possible to include all of the above, too, I will happily donate you something for appreciation of your time spent on this.

I really need to make myself more familiar with StaxRip, you seem really talented.

Ajvar

7th April 2015, 12:05

Ligh found that there is new patch b66b0e32d2ff:
Currently adaptive quantization adjusts the QP values on 64x64 pixel CodingTree units (CTUs) across a video frame. The new param option --qg-size will enable QP to be adjusted to individual quantization groups (QGs) of size 64/32/16
Perhaps it is meant to solve these problems?
http://forum.doom9.org/showthread.php?p=1716402#post1716402

stax76

7th April 2015, 14:59

1) Fast/direct access to the encoder options/parameters (so you can change the values directly) and then real-time viewing (as soon as it got encoded with the new settings) of the result (if I understand this correctly, this may already work, since StaxRip is always running in the background anyway, so is this already possible?)

In StaxRip you would reload the project at: main menu > Project > Recent and encode it again without changing the target file name, what's missing is a reload feature in the comparison utility, this should be fairly easy to add.

Also possible would be a option that the utility would always load and reload all files in a given directory, should also be fairly easy to add.

2) A zoom function for specific image coordinates, which then are identical for all tabs

This could be difficult, most simple approach would be performing zooming and cropping with AviSynth letting the user script this but I don't know how the workflow and implementation could exactly look like.

3) Possibility to have one tab as a reference point (the source) so you can also visually compare the encodes to the source without having to leave your utility

You can already open any file.

If it's possible to include all of the above, too, I will happily donate you something for appreciation of your time spent on this.

So far it's 3 hours work and 200 lines (not counting the form designer) so no problem, I'm looking forward using it often, with the Intel H265 encoder and a new vpxenc GUI for VP9 coming soon there will be enough opportunity for comparisons.

Ajvar

7th April 2015, 17:19

I personally use AVSviewer for such job. Open 2 windows with 2 different files (actually launching 2 Hybrids, adding files and clicking Avisynth preview on both), select Info checkbox (frame info) and just Alt+Tab this stuff. But thanks for doing this anyway, that is cool feature for those who use StaxRip and it's more comfortable as it looks.

stax76

7th April 2015, 18:28

Where can I download AVSviewer?

stax76

8th April 2015, 13:45

My codec comparison tool is now more complete and mature.

http://oi57.tinypic.com/aaad01.jpg

A pre-release can be found here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

It must be used with the latest StaxRip release 1.2.2.1:

http://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.2.2.1_beta.7z/download

It can be found in the main menu under Tools/Advanced/Codec Comparison.

I'm looking for sample clips that are great for codec comparisons so if somebody has some link to share that would be awesome.

Ajvar

8th April 2015, 14:36

Where can I download AVSviewer?

Emm, I use the one which came with Hybrid. Like this.
Here is the folder with it (https://mega.co.nz/#!lVokiTiC!wDTcsmQNJJM6BbwU-NpixXShlaE8CEzjS-2aWGcZC74). You can ask Selur where does he take or if it's his own.
And here is screenshot.
http://i.imgur.com/FjKqzmI.png
I think that your addon can be really great if you could use one Key for switching from one pic to another (Left-Right arrows or some one-key) and maybe possibility to create key-combo with KEY - Sequence of image to switch (like switch between 1, 3, 5) by user.

Nic

8th April 2015, 22:07

For those that want to test grain retention with x265, could you try the build up at:
http://nic.pe.hu
and use "-preset nic" (plus whatever rate control you want to use, like --bitrate 7000, etc)

Let me know if that's any better, will put up the source and explanation tomorrow (it's bed time :) )

Cheers,
-Nic

sneaker_ger

8th April 2015, 22:22

If anyone wants to see an encode made with the patch:
https://mega.co.nz/#!ZwFxGRAC!TlFr5ES87TQA90ok3pwrCkCKCovmnmPwxPZHbXTuN1Q

Nic

8th April 2015, 22:33

@sneaker_ger: This is v2 of the mod, so might be better than your tests with v1. Thanks so much for the help!

benwaggoner

8th April 2015, 22:50

dapperdan

10th April 2015, 10:31

A Google team working on WebRTC is trying to create an open source toolchain for objective codec comparisons, they have x264 and x265 included currently:

http://compare-codecs.appspot.com/results/show_result.html?codec1=x264&codec2=x265&criterion=psnr

It's not quite ready for launch as far as I can tell (there's some obvious bugs in the results and TODO's in the text) but I think the idea is very cool and potentially useful. (There's similar stuff going on at Daala's https://arewecompressedyet.com/?x265&x264).

The whole idea is to encourage contributions, so I thought some people here might have the knowledge necessary to make the tool better:

http://compare-codecs.appspot.com/contributing/

https://github.com/google/compare-codecs

(a slight tangent, Ben Waggoner mentions earlier about progress of codecs over time. I notice in github they have code for MJPEG and
H.261 and H.263 but those results aren't currently displayed on the website).

MasterNobody

10th April 2015, 19:08

MoSal

10th April 2015, 20:27

PSNR only codec comparison in 2015? Is it a joke?

No. It's marketing.
Compare x265 with vp9 and you will get the idea.

The team working on Daala is the only one not actively trying to insult our intelligence nowadays, it seems.

dapperdan

10th April 2015, 22:29

I believe they have plans to implement all the objective metrics from the Daala arewecompressedyet.com site (PSNR, SSIM, FastSSIM, PSNR-HVS) and any others that have freely available code to calculate them. I meant to mention that specifically as I thought that might distract from the potential of a shared, repeatable toolchain for objective comparisons, but thought it fell under the general heading of "obvious bugs and TODOs".

Rather than a cycle of people doing half-hearted, one-off comparisons where they don't fully describe their process, or give you access to their inputs, or do any number of silly things that might invalidate the whole process, here's a chance for people to work together to fix the problems, and share the benefits of automating the boring bits while also exploring whatever codecs, tools, test sets, or objective metrics particularly interest them.

If the idea was to bamboozle people with carefully staged benchmarks to favour Google's own codecs, then this level of transparency wouldn't be a particularly smart move on their part.

iSunrise

10th April 2015, 23:35

My codec comparison tool is now more complete and mature.
I've had some time today to test your codec comparison tool and it's really really great for such an early build. It's extremely easy to search and compare certain scenes between different encodes.

Some bugs and suggestions to improve it as follows:

1) Open dialog (after clicking on "Add files to compare") by default only shows *.mkv, *.webm and *.mp4. Can you please add *.m4v and *.png, too?

2) A jump to position/time index xx:xx:xx.xxx would be helpful. The mouse cursor is great for fast searching on scenes throughout the files, but very bad when you want to jump to a specific position/time index instantly.

3) It would be helpful if you could re-order your tabs by clicking a tab and move your mouse left or right while holding the left mouse button.

4) It would be great if you could close a tab by right-clicking it and select "close selected tab". This is currently only accessible when clicking in the actual view window, but not when directly clicking a tab.

5) If you close the very last tab the codec comparison tool throws an exception. This should be easy to fix.

Need more time to test it more thoroughly. Now on to some actual x265 testing.

stax76

11th April 2015, 10:13

@iSunrise

I've copied your post to my todo list.

stax76

13th April 2015, 20:39

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543

Ajvar

15th April 2015, 21:40

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543

Wow! Just tried it at it's really nice tool! Is it possible to add additional mouse keys work as next 100 frames Next/Previous?

iSunrise

20th April 2015, 22:30

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543
Great! Did some comparisons today, astounded by it's usefulness.

One thing though, you seem to have added *.m4a in the open file dialog instead of *.m4v, probably a typing mistake.

stax76

23rd April 2015, 17:01

Wow! Just tried it at it's really nice tool! Is it possible to add additional mouse keys work as next 100 frames Next/Previous?

Just added it.

One thing though, you seem to have added *.m4a in the open file dialog instead of *.m4v, probably a typing mistake.

Thanks, I also changed it to use LSMASHVideoSource for MP4/M4V.

iSunrise

25th April 2015, 19:25

Thanks, I also changed it to use LSMASHVideoSource for MP4/M4V.
Great, where can I download and test? Last available is 1.2.2.2-beta.

I think I've got a Lagarith version around somewhere. I'll try to find it later and pit it somewhere accessible. So nice to not have a 50 MB per file limit anymore!
Ben, did you have time to upload it somewhere, yet? Would really appreciate it!

stax76

25th April 2015, 19:34

l-smash don't load hevc 10-bit so I reverted to ffms2, what I improved in the tool is avs and ffindex files are saved in the system temp dir and cleaned up after usage. The built is here:

http://forum.doom9.org/showthread.php?p=1719130#post1719130

It's based on AviSynth+ 64-Bit as described in the first post of the thread.

sneaker_ger

25th April 2015, 19:52

l-smash don't load hevc 10-bit
It does, you're doing something wrong. See readme about format and stacked parameters.

Can you maybe open a new thread for your tool to keep this one clean?

stax76

25th April 2015, 20:15

You mean I need to pass a argument? We can discuss it in the StaxRip thread.

Ajvar

26th April 2015, 18:09

Just added it.

I would love to try it but for 2 latest days I tried 4 times to download Alphas from dropbox and never got past 15MB for 1.3.0.1 and 30+MB for 1.3.0.0.
Not a big surprise... Microshaft. Never did anything good since Windows 7.

zambelli

30th July 2015, 01:51

x265_Project

30th July 2015, 06:58

Just tested x265 v1.7+374 and noticed that the detail loss issue is still present. x264 @ CRF18 looks sharper than x265 @ CRF15, despite an almost identical file size. Has any progress been made in solving this problem?
Hi Alex,
It would help if you would share the rest of your x265 command line, and ideally, a short clip.

This is an area of ongoing research and it's definitely a priority. x265 has all of the coding tools of x264, plus many more options (larger block sizes, more accurate motion prediction, etc.), so there is no fundamental reason why it shouldn't be able to produce better visual quality at any bit rate. x265 wins easily at low bit rates, but we agree that there are situations at mid-higher bit rates where x265 has cleaner motion and lower noise, but less apparent detail and sharpness than x264. Though x265's picture is objectively more accurate, subjectively people prefer more sharpness and detail. We're looking at a number of things that might contribute to this effect, and I hope to have more to share soon. In the meantime, you can definitely get more detail by increasing the default psy-rd value from 0.3 to something like 0.6.

zambelli

30th July 2015, 09:44

Hi Alex,
It would help if you would share the rest of your x265 command line, and ideally, a short clip.
Absolutely, I'd be happy to.

Here are a few clips I encoded recently:
http://1drv.ms/1IshUCC

The x264 clip was encoded at CRF 18, while the x265 clips were encoded at CRF 16, 17 and 18. I will upload the source file tomorrow when I'm back at the office.

The command lines were very simple:

x264 --preset slow --crf 18
x265 --preset slow --crf 16

Thanks!

x265_Project

30th July 2015, 17:37

Thanks Alex. It's hard to see any differences as you've chosen a very generous bit rate (720P30 @ 10 Mbps). To my eyes, at full speed or frame by frame, the x265 CRF 16 (which is ~ 10% lower bit rate) looks as good or better than the x264 clip. The x265 CRF 17 and CRF 18 clips start to get slightly softer, but it's barely perceptible.

We have a side by side video player (UHDcode Pro Player) that might help you with these comparisons. It can play AVC, HEVC, or YUV - individually or side by side, including over/under with a wipe bar. Email me (tom.vaughan @ multicorewareinc . com) and I'll make this available. That offer stands for any video professional who is evaluating x265 or UHDcode.

zambelli

30th July 2015, 19:36

Thanks, Tom, for the kind offer. I am already comparing the videos frame-by-frame though using Avisynth + LAV Filters + VirtualDub. I typically use the Interleave() function to flip between sources so I can focus on particular areas of the image. The x264 CRF18 clip looks sharper than the x265 CRF16 clip in every single shot that I've compared. I understand the difference might be negligible in real-time viewing, but it still doesn't make sense that HEVC would look softer as its bitrate approaches that of AVC.

Sagittaire

30th July 2015, 22:56

Thanks Alex. It's hard to see any differences as you've chosen a very generous bit rate (720P30 @ 10 Mbps).

Well this bitrate will be like BluRay quality or DVD quality for the size/pixel. At this bitrate MPEG2 and MPEG4 ASP will provide excellent quality too and perhaps even better. Really useless to compare at this quality with HEVC because H264, VP9, VC1, XviD ... will make excellent job with less ressource (encode and decode).

If you want really compare make H264 encoding at 720p30 10 Mbps and HEVC encoding at 1080p30 10 Mbps. Or better 720p30 for MPEG2, 1080p30 for H264 and 2160p30 for HEVC. With this comparison, you make real demonstration for each codec powerfull.

zambelli

31st July 2015, 02:43

Well this bitrate will be like BluRay quality or DVD quality for the size/pixel. At this bitrate MPEG2 and MPEG4 ASP will provide excellent quality too and perhaps even better. Really useless to compare at this quality with HEVC because H264, VP9, VC1, XviD ... will make excellent job with less ressource (encode and decode).
How about I define my own use cases? ;)

My goal for this particular exercise is archival quality - near transparency from source - with at least 25% bitrate savings and equal (or better) quality compared to H.264.

So if I find that x264 CRF17 gives me archival quality (a subjective bar, of course, but a bar nonetheless), for example, I would expect x265 to produce equal or better results at any CRF setting that yields a 25% lower bitrate. Make sense?

What I'm pointing out is that x264 still has better picture quality than x265 even at similar bitrates. That doesn't seem right.

birdie

31st July 2015, 21:54

What I'm pointing out is that x264 still has better picture quality than x265 even at similar bitrates. That doesn't seem right.

It seems just right because x265 hasn't yet matured enough to compete x264, besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).

If your purpose is to preserve the fine details then forget about x265 for at least a year.

littlepox

1st August 2015, 17:30

besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be.

I don't think so. When MPEG4 based Xvid comes out, do we still prefer MPEG2 on VCD contents? And when x264 claimed the AVC era, we then never appreciated Xvid/RealVideo for DVDRips. It's never supposed to be that x265 has all the features of x264 but can only be used at low-end quality encoding.

birdie

1st August 2015, 18:35

Actually Xvid/DivX and most other MPEG-4 codecs were shit plain and simple. Most if not all 700MB/1400MB DVD encodes using MPEG-4 ASP codecs look much worse than their source DVDs, so let's omit MPEG-4 ASP for a while.

The true breakthrough in regard to video compression came in a form of AVC/x264 and even then it didn't happen overnight - x264 was in development for several years before it became a real MPEG2 contender.

It looks like the HEVC standard is simply not enough to beat AVC when we're talking about preserving fine details at relatively high bitrates (>6Mb/sec for FullHD@24fps videos). If you look at marketing materials for HEVC it's usually compared to AVC at ridiculously low bitrates where AVC blockiness looks worse than HEVC blurriness.

Boulder

1st August 2015, 18:40

If you look at marketing materials for HEVC it's usually compared to AVC at ridiculously low bitrates where AVC blockiness looks worse than HEVC blurriness.Which always makes me wonder why transparency is not the key point. Is it just because we nowadays live in a world of mobile stuff and there is no need to have transparent results? What I've been trying to say all the time is that x264 produces results much closer to the source (with all its possible faults etc.) but x265 seems to take a very different point of view regardless of the settings.

birdie

1st August 2015, 19:23

Boulder (http://forum.doom9.org/member.php?u=7925)

When you're trying to cram 4K streams into existing delivery channels you'll realize that probably HEVC is a better solution. ;-) At least with today's bandwidth. ;-)

However for the prosumer HEVC at its current state is not an option even remotely.

Boulder

1st August 2015, 19:43

As I said, they have a different point of view. That is why x265 cannot be considered a true replacement for x264 in its current form, but maybe in the future.

foxyshadis

2nd August 2015, 00:13

With sufficient tweaking -- often, turning off some of x265's best compression features -- you can get a rough equivalent to x264. It'll be slower and hardware support is minimal, so it seems kind of pointless right now. Let them serve different niches for the time being, until someone gets around to optimizing x265 for grain retention. That's not going to pay the bills until UHD Bluray gets traction (if ever).

On the other hand, saying "Wait a few years" is as meaningless as it ever was, it could happen next week or never, and even "Give it time, it'll happen" is false hope. If it happens, it'll be because someone made it happen, not some arbitrary time passing.

benwaggoner

3rd August 2015, 22:27

It seems just right because x265 hasn't yet matured enough to compete x264, besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).
It's entirely untrue to suggest HEVC was only designed for low bitrates or UHD frame sizes, and absolutely is intended to be able to replace H.264 with superior quality at the same bitrate.

If your purpose is to preserve the fine details then forget about x265 for at least a year.
That's an oddly specific prediction. We've seen plenty of improvements here. Did you try --psy-rd 0.6? A build today with --qg-quality on by default and the recent rate control improvements, and raising --psy-rd should yield significant improvements in detail retention compared to a few months ago.

Sulik

3rd August 2015, 23:51

Disabling large transform sizes (using 16x16 CTB size and perhaps limiting max TU size to 8x8) should results in artifacts more similar to x264 (better at preserving grain), but that would eliminate a significant part of the benefits of x265 at really low bitrates...

benwaggoner

4th August 2015, 01:12

Sulik

4th August 2015, 07:51

That's exactly the kind of choice that rate distortion optimizing mode decisions should be making.

When it works :)

birdie

4th August 2015, 08:44

That's an oddly specific prediction. We've seen plenty of improvements here. Did you try --psy-rd 0.6? A build today with --qg-quality on by default and the recent rate control improvements, and raising --psy-rd should yield significant improvements in detail retention compared to a few months ago.

Tried that, no visible improvements so far (at CRF=21 which should be sufficient to preserve the details).

iSunrise

4th August 2015, 11:45

HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).
It's not really contrary, since to be able to optimize for even lower bitrate requirements at a given quality (irregardless of resolution), you would always need to change specific encoder qualities that are working more efficiently towards saving on the precious bits and bytes. The part where it gets interesting is where HEVC actually can make improvements without sacrificing (visible) quality compared to x264. If HEVC could provide even 10-20% bitrate savings and we all had the necessary HW decoders that do it natively, there is no reason not to prefer HEVC, but we are clearly not at that point, yet.

We really need to wait at least to the end of the year for the Ultra HD Blu-rays to arrive which will ultimately accelerate consumer interest and also push it into way more visibility. But don't ever expect a 20mbps HEVC stream that rivals a 100mbps Blu-ray. It's all a compromise. And yes, that means that fine-details will ultimately suffer, because it's harder to compress.

x264 just satisfies an extremely broad range of use cases for internet and also professional use which makes it so hard to beat. Even XVID was only an internet phenomenon (if you don't count DIVX, dumbest idea ever), but x264 (several years later, though) ultimately did become so good at what is does that XVID is already forgotten. And I think no one ever looked back, since.

It remains to be seen whether HEVC is able to do the same, but make no mistake, it will take several years. At least I have not seen anything that proves otherwise.

benwaggoner

4th August 2015, 22:54

Tried that, no visible improvements so far (at CRF=21 which should be sufficient to preserve the details).
I don't know that we can assume that CRF=CRF. We should be comparing same quality at different bitrates, or different quality at the same bitrate.

A rate control fix went in a couple of weeks ago that helps preserve detail, particularly in B-frames.

I wonder if some of this is down to just tuning --psy-rd, -aq-strength, --aq-mode, --qg-size, --rdoq-level, --deblock and --psy-rdoq to taste. That's a lot of psychovisual knobs to tune! x265 doesn't have --tune film or animation equivalent yet, which most people using x265 would probably use. Figuring those out the right tuning may be what's required.

benwaggoner

4th August 2015, 23:03

We really need to wait at least to the end of the year for the Ultra HD Blu-rays to arrive which will ultimately accelerate consumer interest and also push it into way more visibility. But don't ever expect a 20mbps HEVC stream that rivals a 100mbps Blu-ray. It's all a compromise. And yes, that means that fine-details will ultimately suffer, because it's harder to compress.
Note that with 24p film content with a 1/48th of a second motion blur, there really isn't much detail when there's motion. And per-pixel detail at UHD is very different from human perception than 1080p, unless everyone is going to buy a TV with double the diagonal of their old one, or sit half the distance. In practice, very few viewers are going to be able to resolve a single pixel in UHD, particularly with real-world content.

With relatively low-noise content like Tears of Steel, I can get quite transparent at 20 Mbps VBR. Out of whimsy, I got something quite decent from ToS at 5.7 Mbps.

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.

birdie

4th August 2015, 23:04

I wonder if some of this is down to just tuning --psy-rd, -aq-strength, --aq-mode, --qg-size, --rdoq-level, --deblock and --psy-rdoq to taste. That's a lot of psychovisual knobs to tune! x265 doesn't have --tune film or animation equivalent yet, which most people using x265 would probably use. Figuring those out the right tuning may be what's required.

I hate tuning things. My usual encoding strings looks this way:

ffmpeg -i input.mp4 -c:a copy -c:v libx264 -preset veryslow -crf 18 output.mkv

This is what I want from x265: less bitrate for the same quality (I'm not talking about low quality already compressed source video, I'm talking about FullHD clips with at least 25Mb/sec or higher bitrate). Of course, in case of x265 CRF will be different.

benwaggoner

4th August 2015, 23:16

I hate tuning things. My usual encoding strings looks this way:

ffmpeg -i input.mp4 -c:a copy -c:v libx264 -preset veryslow -crf 18 output.mkv

This is what I want from x265: less bitrate for the same quality (I'm not talking about low quality already compressed source video, I'm talking about FullHD clips with at least 25Mb/sec or higher bitrate). Of course, in case of x265 CRF will be different.
Well, at this point of x265's maturity some tuning will be required to get x264-style results. I don't know if it's reasonable to expect that the defaults would ever exactly match, but I think having a preset that gives x264-like results (ala --tune film) makes sense as an eventual goal.

But people really get used to their favorite artifacts, ala MPEG-2 "sizzle." Sometimes artifacts can enhance edges given a subjective increase in sharpness, at a loss of actual accuracy.

foxyshadis

5th August 2015, 09:50

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.

While UHD could conceivably image a tiny bit more grain, given that color grain on 35mm is ~10µm and silver crystals are ~1µm (equivalent of ~2000px and ~20000px horizontal), but several authorities believe that focusing on and amplifying the grain is doing it wrong, and ahistorical as movies have traditionally been viewed in theaters. It's almost fetishistic to amplify grain to highlight the extra punch of higher resolution (in the case of digital grain movies like 300 it truly is), to the point where studios are training consumers to expect more grain instead of more detail. Here's a document describing the difficulty and why it should be done better. (http://cool.conservation-us.org/coolaic/sg/emg/library/pdf/vitale/2007-04-vitale-filmgrain_resolution.pdf)

But instead, I expect studios will make up for exceeding the film grain in scans by generating digital grain on top -- or just upscaling and generating grain, as some do to create Blurays today -- and completely confound the codec.

birdie

5th August 2015, 10:05

Yeah, this sounds crazy considering that most AAA movies nowadays are shot using a 100% digital pipeline (starting with RED cameras), so in theory the movies that have been shot for the past 10 years should be absolutely grain free and it's definitely not the case. So, it's plausible that grain is added in post production as a way to add analogueness and panache to make them look professional and expensive.

Actually my gut feeling was right. Grain is added (http://www.studiodaily.com/2009/01/fine-tuning-the-digital-image-for-benjamin-button/) in post production.

So we unified the look of the picture. We took down the noise and enhanced the pictures to achieve an even amount of sharpness shot to shot. We put an even amount of grain on top so it had a film-grain distribution as opposed to a video-noise distribution. On some occasions, maybe the power supply was funky and they’d end up with flicker in the picture. If you start to really push the camera to its limit in a very, very low-light condition there are patterns that are inherent to the CCDs, and you end up with a screen-door pattern over the image. We have a filter we developed to take out that screen-door CCD pattern.

We did a number of iterations, with tests both to film and digital cinema screenings with David and Peter, to set the look. How much sharpness and how much grain did they want? Once the target had been set, we went through and used those as benchmarks for the aesthetic look. We then noise-reduced the movie, took out all the flicker and artifacts, and then put in an appropriate amount of noise for seamless transitions from shot to shot. This way, you wouldn’t be shocked by a sudden change in quality when it cuts from a slow-motion shot at nighttime to a regular-speed shot in a more well-lit area.

Also there are some techniques to emulate film grain (http://www.theverge.com/2013/11/22/5131598/creating-analog-with-digital-cinematography-of-nebraska-phedon-papamichael). Wow, I didn't know that.

foxyshadis

5th August 2015, 10:35

Another common technique is to shoot an entire reel of film against a grey screen, then scan that and merge it into the final edit. Now that digital algorithms are getting better it isn't used as often, but that's about as genuine you can fake it as you can get.

littlepox

5th August 2015, 14:15

Basically there are 3 concerns about grain keeping:

1. x265 does not only wipe out film grain, but also details/weak edges as small as grain. This is the key point of the problem. If you do some encoding in less grainy, but still rich-of-detail sources like recent anime blu-ray, you will know what I am talking about. In contrast, x264 can do that quite well, keeping all the details destroyed by x265. How are you supposed to "add detail and thin edges" to encoded anime?
2. people's eyes just don't like blurred images. you can sometimes add grain when you play the movie; only sometimes, not always as when you watch it on your smart TV.
3. when x264 can free you from worries with even lower bit-rates and much faster encoding speed, we'd expect x265 to do as well as, if not better than, its predecessor.

iSunrise

6th August 2015, 13:09

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.
While that definitely is something to think about for the remastering process and the decision making when doing all the high-precision scanning and director approved alterations from the original negative, this should not be the scope that the encoder needs to worry about.

The encoder needs to be able to adapt (via tuned settings) for certain content, while still having a better baseline performance for new UHD content (quality<-> bitrate) then e.x. H.264 or x264 for even lower bitrates.

Otherwise all the marketing mumbo-jumbo is just a smokescreen, because when an encoder is not able to capture all the fine details, even with very high bitrates and irregardless of the source resolution, it clearly is in not in a state that I would recommend to use.

It may be perfectly applicable for really clean and low-noise content already, but that is just a workaround for saying that "we can only save on bitrate, if we ignore some fine details, because they are just too bitrate intensive and too hard to compress".

I would consider 10-20mbps x264 as perfectly transparent for 99,9% of all cases and the moment x265 can beat that with an even higher resolution, I will not look back.

foxyshadis

7th August 2015, 00:51

--tune grain should probably set --ctu 32 --max-tu-size 16, maybe even --ctu 16 --max-tu-size 8 --deblock -4,-4 (or --no-deblock) for extreme grain/noise. It's the use of large prediction and especially transform blocks that makes it so difficult to retain grain; sure the block artifacts will rise, but in a grainy picture those are mostly covered up, exactly how x264 gets away with it.

--rdpenalty is a useful hack to make up for their psychovisual rd still being imperfect, but it applies only to intra blocks in inter frames, when the problem is more widespread than that. x265 is just too heavily weighted against dropping down to 8x8 and 4x4 transforms even when the user wants it to, so you have to take a sledgehammer with --ctu & --max-tu-size, because there's no setting to request "damn efficiency, gimme all the grain and texture." If rdpenalty applied more broadly that might not be the case.

x265_Project

7th August 2015, 04:22

littlepox

7th August 2015, 06:34

Interesting suggestions. We're open to discuss more / better tune settings, or options that bias x265 towards smaller block sizes or in other ways that are useful. Message me when you're ready to chat.

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?

shinchiro

7th August 2015, 12:43

I wonder if anyone use aq-factor in astrataro's x264 patched build before? I've used this setting to retain grain very grain anime source (corpse party) with --aq-factor=1.00:1.50:3.00, when default x264 build failed at it no matter which settings I tweaked.

This basically mean give more aq to bframes. This is might be interesting to read about the benefit of it
https://astrataro.wordpress.com/2013/07/07/x264-rev2348704-tmod/#comment-548

sneaker_ger

7th August 2015, 13:41

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?
Please make a thread here so everyone can see and test.

sneaker_ger

7th August 2015, 15:58

--tune grain should probably set --ctu 32 --max-tu-size 16, maybe even --ctu 16 --max-tu-size 8 --deblock -4,-4 (or --no-deblock) for extreme grain/noise.

I applied these to the grainy cartoon test I first did ~11 months ago (http://forum.doom9.org/showpost.php?p=1693749&postcount=77):

Used builds:
x264 r2579 8bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all 2pass bitrate 7000):
original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune grain
x265 --preset slower --tune grain
x265 --preset slower --tune grain --ctu 32 --max-tu-size 16 ("foxy1")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --deblock -4,-4 ("foxy2")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3")
x265 --preset slower --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 ("sag"/"sagittaire")
x265 --preset slower --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --bframes 3 --min-keyint 1 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 --no-open-gop --pmode --pme ("sag1"/"sagittaire1")

(All output files, screens and batch scripts) (https://mega.co.nz/#F!Zx8TUTZJ!sdBhN6FIZ7Q4C6txBMY0-w)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264_0furg.png
http://abload.de/img/270_x265_z2u1x.png
http://abload.de/img/270_foxy1_h4utf.png
http://abload.de/img/270_foxy2_puua3.png
http://abload.de/img/270_foxy3_iku00.png
http://abload.de/img/270_sag_0osyx.png
http://abload.de/img/270_sag1_kcseb.png

x265_Project

7th August 2015, 16:23

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?

Email me. tom.vaughan @ multicorewareinc.com

x265_Project

7th August 2015, 16:33

Please make a thread here so everyone can see and test.
We have private conversations all day long with video experts around the world on the topic of how we can improve x265's visual quality, performance and features. I don't mind chatting here on Doom9, but I also like to meet people 1:1, learn more about what they are doing, and what they need. These conversations can be more productive face to face, or on the phone. In the end, everything we implement is made public - usually along with the rationale for the changes.

sneaker_ger

7th August 2015, 20:18

zambelli

8th August 2015, 00:16

Well, at this point of x265's maturity some tuning will be required to get x264-style results. I don't know if it's reasonable to expect that the defaults would ever exactly match, but I think having a preset that gives x264-like results (ala --tune film) makes sense as an eventual goal.

I think it's entirely reasonable to expect equivalent x264 & x265 tuning presets to yield similar results at a certain bitrate/QP range. The goal should be to eventually make upgrading from x264 to x265 a no-brainer for any compressionist in any scenario (assuming HEVC support is a non-issue) without requiring additional tuning.

x265_Project

8th August 2015, 01:05

He can post their findings here while also having a private chat with you. These things are not mutually exclusive. But by posting here the findings will receive more scrutiny early on and satisfy our curiosity.
Every video professional who interacts with us has the option to do that here, or do so privately. We've got large customers who post here, and sometimes we see feedback on certain things through Doom9 before we hear it from them privately. But it's hard to dive deep on a topic on a public forum while keeping the signal to noise ratio high. And there are always lots of specifics that people would rather (or are required to) keep private. So whenever possible we like to have both channels open.

sneaker_ger

9th August 2015, 18:16

Grainy hollywood-type movie comparison:

Used builds:
x264 r2579 10bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all bitrate 7000):
original
x264 --preset veryslow --tune grain (3 pass)
x265 --preset slower --tune grain (3 pass)
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3", 2 pass)
x265 --preset slower --ctu 32 --max-tu-size 16 --qcomp 0.8 --aq-mode 1 --aq-strength 1.0 --psy-rd 0.7 --psy-rdoq 5.0 --rdoq-level 1 --deblock -2:-2 --qg-size 16 --no-sao --merange 44 --no-rect --no-amp ("littlepox" (http://forum.doom9.org/showthread.php?t=172458), 3pass)
(original and output file(s), screenshot package and batch scripts) (https://mega.co.nz/#F!lot1TBKB!_YjLHI7FpIQo1eoKzg4Inw)

http://abload.de/img/130_org_52akt.png
http://abload.de/img/130_x264_flxnc.png
http://abload.de/img/130_x265_3asj2.png
http://abload.de/img/130_foxy3_35yys.png
http://abload.de/img/130_littlepox_tklos.png

http://abload.de/img/205_org_1vzba.png
http://abload.de/img/205_x264_iebu3.png
http://abload.de/img/205_x265_4hsax.png
http://abload.de/img/205_foxy3_fvaxo.png
http://abload.de/img/205_littlepox_ojxe9.png

http://abload.de/img/635_org_7pb30.png
http://abload.de/img/635_x264_djy46.png
http://abload.de/img/635_x265_2nsiw.png
http://abload.de/img/635_foxy3_yky3y.png
http://abload.de/img/635_littlepox_78x41.png

http://abload.de/img/715_org_qizbc.png
http://abload.de/img/715_x264_dayp4.png
http://abload.de/img/715_x265_r6sy0.png
http://abload.de/img/715_foxy3_djx93.png
http://abload.de/img/715_littlepox_f0aqv.png

http://abload.de/img/1060_org_gqayh.png
http://abload.de/img/1060_x264_jbzlb.png
http://abload.de/img/1060_x265_pzstp.png
http://abload.de/img/1060_foxy3_tal55.png
http://abload.de/img/1060_littlepox_fhxsf.png

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png
http://abload.de/img/1575_littlepox_vtank.png

/edit: replaced x265 2pass by 3pass
/edit2: added "littlepox" (http://forum.doom9.org/showthread.php?t=172458) encode

stax76

9th August 2015, 19:01

@sneaker_ger

Thanks for the comparison, in the first and second scene which are rather dark x265 looked better but in the rest x264 looked better. Both x265 were rather similar. x265 was 5,3 times slower then x264.

sneaker_ger

9th August 2015, 19:23

in the first and second scene which are rather dark x265 looked better but in the rest x264 looked better.
There is a big exception right at the start: http://abload.de/img/first_scene_blurred_cisan.jpg
The area is very blurred in the x265 encode, not just less grainy.
But maybe it's just the ratecontrol having gone wild so early. I did x264 3pass because of a similar problem. I think I will test x265 3pass as well and replace current encode if it fixes that problem.

/edit: replaced now. Fixes that small blurryness at start.

birdie

9th August 2015, 23:15

Frame 1060, the protagonist forehead: x265 - not quite there ;-)

However at least in certain cases x265 looks better than x264. That's something!

smegolas

10th August 2015, 09:50

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png

/edit: replaced x265 2pass by 3pass

x265 still destroying fine detail, softening the image.

Sagittaire

10th August 2015, 10:50

Grainy hollywood-type movie comparison:

Used builds:
x264 r2579 10bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all bitrate 7000):
original
x264 --preset veryslow --tune grain (3 pass)
x265 --preset slower --tune grain (3 pass)
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3", 2 pass)
(original and output file(s), screenshot package and batch scripts) (https://mega.co.nz/#F!lot1TBKB!_YjLHI7FpIQo1eoKzg4Inw)

http://abload.de/img/130_org_52akt.png
http://abload.de/img/130_x264_flxnc.png
http://abload.de/img/130_x265_3asj2.png
http://abload.de/img/130_foxy3_35yys.png

http://abload.de/img/205_org_1vzba.png
http://abload.de/img/205_x264_iebu3.png
http://abload.de/img/205_x265_4hsax.png
http://abload.de/img/205_foxy3_fvaxo.png

http://abload.de/img/635_org_7pb30.png
http://abload.de/img/635_x264_djy46.png
http://abload.de/img/635_x265_2nsiw.png
http://abload.de/img/635_foxy3_yky3y.png

http://abload.de/img/715_org_qizbc.png
http://abload.de/img/715_x264_dayp4.png
http://abload.de/img/715_x265_r6sy0.png
http://abload.de/img/715_foxy3_djx93.png

http://abload.de/img/1060_org_gqayh.png
http://abload.de/img/1060_x264_jbzlb.png
http://abload.de/img/1060_x265_pzstp.png
http://abload.de/img/1060_foxy3_tal55.png

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png

/edit: replaced x265 2pass by 3pass

As always test seem interessing but there are heterogenous result. First picture is by far better with x264 but difficult to conclude for the other.

Explain can be that you don't know if the codec use I, P, B or bframe. If you compare Pframe for x264 and bFrame for x265, x264 will probaly produce better result. Other way must be to use same frame type distibution for x264 and x265 (it's possible to impose that with external txt typeframe file distribution) or constant quantizer mode. Other way introduce Rate Control "Noise", with high variablitity in the conclusion.

Motenai Yoda

11th August 2015, 18:16

I like the foxy3 for the movie (maybe --no-deblock is too much, -2,-2 doesn't seems to smooth too much imho),
also foxy2 for the anime but x265 too (50/50 maybe a litte bit more x265)

nandaku2

18th August 2015, 12:01

Can you make the entire clip available for testing? Thanks in advance.

Sagittaire

18th August 2015, 23:00

I applied these to the grainy cartoon test I first did ~11 months ago (http://forum.doom9.org/showpost.php?p=1693749&postcount=77):

Used builds:
x264 r2579 8bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all 2pass bitrate 7000):
original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune grain
x265 --preset slower --tune grain
x265 --preset slower --tune grain --ctu 32 --max-tu-size 16 ("foxy1")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --deblock -4,-4 ("foxy2")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3")
(All output files, screens and batch scripts) (https://mega.co.nz/#F!Zx8TUTZJ!sdBhN6FIZ7Q4C6txBMY0-w)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264_0furg.png
http://abload.de/img/270_x265_z2u1x.png
http://abload.de/img/270_foxy1_h4utf.png
http://abload.de/img/270_foxy2_puua3.png
http://abload.de/img/270_foxy3_iku00.png

Well for my curisity, I make little test with your source:

ffmpeg.exe -i original.mp4 -an -f rawvideo - | x265.exe --input-res 1920x1080 --fps 24000/1001 - -o crf25aq.265 --bitrate 7000 --pass 3 --stats hp.log --preset veryslow --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --bframes 3 --min-keyint 1 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 --no-open-gop --psnr --ssim --pmode --pme

This x265 setting outperform your x264 file by far for grain retention. Particulary for bframe (bframe are 75% of frame number). x264 with your default setting are really bad bframe quality with really bad grain retention.

nandaku2

24th August 2015, 09:40

Well for my curisity, I make little test with your source:

This x265 setting outperform your x264 file by far for grain retention. Particulary for bframe (bframe are 75% of frame number). x264 with your default setting are really bad bframe quality with really bad grain retention.

Interesting. For grainy videos, it was a tug of war between --rdoq-level 0 (this turns of psy-rdoq) and --rdoq-level 2 and high psy-rdoq.

RDOQ zeroes out (what it deems unnecessary) high frequency coefficients, so it would seem intuitive to turn it off for grainy sources. But I guess if we allow rdoq-level to zero out all possible coefficients, and then psy-rdoq acts to retain the visually perceptible ones, the bitrate distribution is visually more efficient.

benwaggoner

24th August 2015, 18:17

I note there are some film and some cartoon assets being discussed in this thread. There's a very good chance we'll eventually want to wind up with a --tune animation and a --tune film. How is grainy cartoon content normally handled in x264?

sneaker_ger

24th August 2015, 21:47

@Sagittaire
I added your suggestions to the test. They make a strong difference.

may24

28th September 2015, 09:40

Hi all,
I'd like to jum on that topic.
I'm "archiving" a TV series and encode my SAT rip with x265. Now I'm looking for some better settings to preserve more details and keep a sharper image. (check the tuxedo)
I played a bit with the --psy-rdoq and --rdoq-level ... but still the result is below my expectations ;)
I also noted a slight "hint of green" in the encoded picture ...
Unfortunately the source recording is lost and all I have are the screenshots (sorry)
But what are your suggestions - besides lowering the CRF - to preserve more details ?
Adding --tune grain seems to have no (noticeable) effect with these settings ...

"C:\Program Files (x86)\Video Tools\avs2pipemod-0.4.2m\avs2pipemod.exe" -rawvideo "extra.avs"| "C:\Program Files\x265\x265-r1.7_482.exe" --preset slower --crf 19 --psy-rd 2.0 --psy-rdoq 10.0 --no-open-gop --input-res 1280x720 --input-depth 16 --fps 25 --output hol-18.h265 --input -

And here are the screenshots
Original:
http://forum.doom9.org/attachment.php?attachmentid=15042&stc=1&d=1443429492

After encoding:
http://forum.doom9.org/attachment.php?attachmentid=15043&stc=1&d=1443429555

seandarcy

18th October 2015, 22:37

birdie

19th October 2015, 08:25

Moscow State University has released its tenth video codecs comparison:

http://compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf

If I'm reading this correctly, they find that h.265 only gives <20% lower bitrates at constant quality. See graph 6.2.4 .

I realize using "objective" quality metrics is problematic, but still, I'd have expected something like 50% .

sean

For grain free source shot in perfect lighting conditions that can be true (x265 can use CTUs up to 64x64) - unfortunately real world often involves pseudo-artistry (so grain is added more or less artificially into modern movies which are shot digitally) and low quality recording equipment (like smartphones) which adds a huge amount of noise even at perfect lighting conditions.

iwod

9th January 2016, 17:09

Just to add my own conclusion from the thread.

Basically anything below 2000Kbps, x265 will win. Which is basically my target bitrate ( 1000 - 2000kbps )

Will x265 be now focus on tuning the higher end bitrate? Can we consider the lower end tuning be done? Or are there still some low hanging fruits?

Boulder

9th January 2016, 20:32

Making statements based on bitrate is dangerous. Bitrate depends completely on the source.

Jamaika

10th January 2016, 08:53

I also noted a slight "hint of green" in the encoded picture ...

You use new version x265 1.8.0.205.

HarryM

17th January 2016, 17:41

At CRF=23 is x265 quality-comparable to x264. But with 60% filesize.

HerpaDerp

14th March 2016, 13:31

benwaggoner

14th March 2016, 17:06

Is it just me, or does HEVC look worse than x264 in some instances? I feel like HEVC is not really all that impressive. I looked at the hollywood film grain example on the previous page and x264 simply does a better job at preserving the film grain, whereas hevc blurs a lot of that detail out.
A bunch of improvements to --tune grain got checked in last week. They might help a lot.

https://bitbucket.org/multicoreware/x265/commits/all

How does HEVC work with 4k footage compared to x264 at similar bitrate settings? To me, that sounds like that's where HEVC might shine - correct me if I'm wrong.
The larger block/TU sizes available in HEVC gives it a further efficiency advantage at large frame sizes. I'd say it's >50% more efficient at 3840x2160.

Do HEVC encoders still need several years for improvement? I remember x264 went through an ass load of updates over the years before it got to where it is today.
"Need" is subjective. But they've certainly improved a LOT in the last 18 months, in both speed and quality. Certainly x265 has a lot more room for improvement than the rather mature x264. And HEVC is a more complex standard, so there's a lot more ways it can be optimized, particularly psychovisually. So we may be years away from a x265 that hits a quality "steady state" like x264 has been the last couple of years.

SaboraPie

27th March 2016, 19:08

HI, comparing the codecs x264 (r2665 8-Bit) and x265 (1.9+104 10-Bit), in x265 it appears to me this defect in zone of gradients and, apparently, more evident when the original video has high noise.
Why is this? Can be it prevent or blur at bitrates so low (about 750kb)

The config in x264 is present Very Slow (Film) and the x265 idem (Grain), both in two pass mode and about 750Kb. No other changes.

sneaker_ger

27th March 2016, 19:28

Can you try without --tune grain? I have seen a similar defect using it. https://bitbucket.org/multicoreware/x265/issues/250/

SaboraPie

28th March 2016, 11:59

Can you try without --tune grain? I have seen a similar defect using it. https://bitbucket.org/multicoreware/x265/issues/250/

Yes, It's best without --tune grain (It is supposed to keep but deleted it?¿). X264 also still better for static scenes and noisy.

foxyshadis

31st March 2016, 07:36

Yes, It's best without --tune grain (It is supposed to keep but deleted it?¿). X264 also still better for static scenes and noisy.

Without FGM, x265 can't really be better than x264 at film grain; at best it can be the same but slower, but in practice, it's more aggressive about smoothing to save bits. Use x264 for retaining full grain at high bitrates. For lower bitrates with grain smoothed out a bit, x265 always wins hands down.

blublub

28th April 2016, 13:33

What would you consider high/low nitrates for encoding an 720p HDTV source fume fro. Satellite TV ?

I used crf 17 or 16 before but I now have files were I do not need very good quality, so crf if 20 or 21 would suffice - better x264 or 265?

Any suggestions?

asarian

1st May 2016, 00:25

benwaggoner

1st May 2016, 23:10

Yikes! Those distortions are pretty awful! I was just thinking of giving x265 a chance; but, after seeing this, never mind. :)
Remember, tune grain<>film. x264 has a --tune grain as well. x265 needs it's own --tune film for apples-to-apples.

Leo 69

5th May 2016, 19:35

I don't know how you guys but I'm done with x264.
I'm now encoding Alvin and the Chipmunks (source - blu-ray remux) into 10-bit x265 crf=18 with tune=grain (so far we don't have "film" tune so I stick to this to retain detail) and other options maxed out...and I must tell that this is incredible. I have never seen this low bitrate when I tried x264 on this exact film last time. Haven't done a direct comparison between codecs yet, but I can already tell that from .hevc file which is in the Staxrip temp directory (which I can mux into .mkv at any time) - I cannot distinguish the result from the original blu-ray file. I'm now at 60% of encoding and the bitrate is ~5200kbit/s. Of course, the speed is slow as hell (0.95 fps on my i5-3570k@4500Ghz), but the result is well worth it.
Encoding with the latest x265 64-bit GCC build 1.9+150

asarian

5th May 2016, 20:00

asarian

5th May 2016, 20:02

Remember, tune grain<>film. x264 has a --tune grain as well. x265 needs it's own --tune film for apples-to-apples.

You're right about that. So, to the powers that be..... can we have a '--tune film' setting, pretty please?

Leo 69

5th May 2016, 20:09

Haven't given up on it just yet. :)

Skylake is currently the only CPU line I know of that supports hardware acceleration of x265. Without it, your typical i5-based media center is going to suffer (badly).

And what media player out there actually supports 10-bit video?! (Windows Media Player? Kodi?)

Hi,

As for Skylake, I don't care much -- I have Nvidia GTX 960 :p

The best media player for me for the last few years has been Daum PotPlayer. It decodes 10-bit HEVC nicely with built-in codecs (with HW-acceleraction, of course). LAV decoder, as I know, can do the same for any other player.

asarian

5th May 2016, 20:16

Hi,

As for Skylake, I don't care much -- I have Nvidia GTX 960 :p

The best media player for me for the last few years has been Daum PotPlayer. It decodes 10-bit HEVC nicely with built-in codecs (with HW-acceleraction, of course). LAV decoder, as I know, can do the same for any other player.

I have a GTX 980 (and an i7 980X). :p My PC would be able to handle it just fine. My poor i5-based Zbox ID92, however, not so much.

I actually prefer a low-power consumption Zbox-type solution for a media player, with built-in graphics, and hardware accelerated support for your fav codec.

I'll look into that Daum media player you mentioned, though. Thx.

Leo 69

5th May 2016, 20:30

Yep, give a good try to this player. Many people I advised it to literally fell in love with it. I just don't see anything more advanced in terms of how deep you can go with setting it up, user-friendliness and reliability. VLC is not my cup of tea at all, for example, starting from its shortcut.

Leo 69

8th May 2016, 07:57

asarian

8th May 2016, 08:20

Having said all positive about my impression about current state of x265, I should admit that it's still not suitable for very HQ, sharp sources. Washes out detail too much with any settings you'd think of. "Retain grain" helps a bit, but still tiny details go away for good.

And for the 'codec of the future', that's simply unacceptable. Honestly, for what it stands for, and the huge impact on your CPU, it really ought to be *significantly* better than x264.

Still, I shouldn't judge too harshly, as it's (relatively) still in its early stages of development.

While you're at it, could you maybe give me an example command line of the highest quality you're currently outputting? I so happened to decide to play with x265, this very day. :)

Leo 69

8th May 2016, 09:29

Hi mate,

I agree that it could be the "result" of early stages of development. Maybe we have to wait another 3-5 years for it to reach acceptable state and then forget about x264.
Anyway, to the settings for x265 I encoded "Alvin and Chipmunks" (2015), which turned out a very good encode anyway:

Writing library : x265 1.9+150-00ea3784bd36:[Windows][GCC 5.3.0][64 bit] 10bit
Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=7 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=50 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=6 / limit-refs=3 / limit-modes / weightp / weightb / aq-mode=0 / qg-size=64 / cbqpoffs=0 / crqpoffs=0 / rd=5 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock=-6:-6 / sao / no-sao-non-deblock / b-pyramid / no-cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=1 / ipratio=1.40 / pbratio=1.30

asarian

8th May 2016, 09:38

^^ Brilliant! Thx. :)

asarian

8th May 2016, 09:40

Wait, you're running with 'qpmin=0'?!? That's just lossless, right?

Leo 69

8th May 2016, 10:05

No no, it's a default setting, I believe.. meaning qpmin=0 is the start of allowed qp range going up to 51 (qpmax=51).

benwaggoner

9th May 2016, 23:24

You're right about that. So, to the powers that be..... can we have a '--tune film' setting, pretty please?
You can be one of those powers yourself!

This thread was the community trying to figure this out. A good a time as any to revive it.

http://forum.doom9.org/showthread.php?t=172458&highlight=tune+film

ndkamal

13th May 2016, 20:46

I put some pictures x264 R2664 and x265 V19 R165 with / without grain

24 x264 R2664 (2 Mbps) (672x368) :

http://5.t.imgbox.com/vpZ5Rtf2.jpg (http://imgbox.com/vpZ5Rtf2)

24 x265 V19 R165 (1.6 Mbps) (672x368) :

http://t.imgbox.com/XAzSM7AG.jpg (http://imgbox.com/XAzSM7AG)

24 x265 V19 R165 with tune grain (1.6 Mbps) (672x368) :

http://7.t.imgbox.com/3FTv2H9c.jpg (http://imgbox.com/3FTv2H9c)

Alliance x264 R2664 (5 Mbps) (1280x544) :

http://0.t.imgbox.com/9fqh1eQu.jpg (http://imgbox.com/9fqh1eQu)

Alliance x265 V19R165 (4 Mbps) (1280x544) :

http://6.t.imgbox.com/xq9NEPCS.jpg (http://imgbox.com/xq9NEPCS)

Alliance x265 V19R165 with tune grain (4 Mbps) (1280x544) :

http://0.t.imgbox.com/nVoah89N.jpg (http://imgbox.com/nVoah89N)