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.