x265 HEVC Encoder

Originally Posted by fumoffu

Thank you very much!
Question: the --merange default value 60 seems a bit high compared to x264 default 16... I understand it might be necessary for 4K video but if I encode in 720p lowering it to 24 or 32 wouldn't be more optimal? Were there any tests done to determine the default value?
Also why 60 and 124 for placebo and not "round" 64 and 128? ;-)

We've performed many tests to determine the most optimal performance presets (and default values), but there is always room for improvement. We tend to err on the side of quality for each setting, but as you need to run faster, we try to find the right combination of settings that improve encoding speed with the minimal tradeoff in compression efficiency (quality / bitrate). You will see that the fastest performance presets use a smaller motion estimation search range.

We leave 4 pixels at the end of the motion estimation search range to allow room for subpel refinement without causing the encoder to need to retrieve more Coding Units.

Tom

[Selur]

sadly, compiling on Mac OS X 10.6.8 is still broken

[benwaggoner]

Originally Posted by nakTT

That was some hell of a job for your 12-Core. What is the built that you used? Was it 0.5+547 or 546? Any comment if compared with the version that come with MeGUI? For me, I can see that current build produce smaller file size for the same Constant Quality setting.

It was using a daily build from Friday. I'm traveling right now and can't verify the actual build number.

[fumoffu]

Originally Posted by x265_Project

We've performed many tests to determine the most optimal performance presets (and default values), but there is always room for improvement. We tend to err on the side of quality for each setting, but as you need to run faster, we try to find the right combination of settings that improve encoding speed with the minimal tradeoff in compression efficiency (quality / bitrate). You will see that the fastest performance presets use a smaller motion estimation search range.

So I have done some simple tests on 720p, 4 minute long hand-held camera footage - a lot of motion all the time

x265 settings: defaults with --crf 21 --b-adapt 2
merange 60: 4.61fps psnr: 46.402 size: 63719KB
merange 40: 4.86fps psnr: 46.403 size: 63801KB - 5% faster, 0.13% size increase
merange 24: 5.08fps psnr: 46.404 size: 64194KB - 10% faster, 0.74% size increase

With PSNR almost identical, imho it's worth it to decrease the range for 720p sources. I think I will go with merange 32 or 36 in the future.
Would it be against some convention for the encoder to change default merange depending on input resolution? Surely what is optimal for 4K video isn't optimal for SD...
For example, encoder detects (or rather is told) that the input res is:
>=1080p it sets merange to 60
<1080p and >=720p sets merange to 32 or something like that
<720p sets merange to 24
or we could come up with some clever formula that sets merange depending on pixel count in the frame.
Bad idea?

[nakTT]

Originally Posted by benwaggoner

It was using a daily build from Friday. I'm traveling right now and can't verify the actual build number.

Its okay, enjoy your travelling.

I take it that the version you used has B-Pyramid feature. By the way, I can see that mediainfo unable to give us the version number of the x265 encoder (as well as the detail settings that it can give in the case of x264). Is there any other easy way to get it form the x265 encoded video? Right now I only use the hard way to determine it.

Originally Posted by fumoffu

So I have done some simple tests on 720p, 4 minute long hand-held camera footage - a lot of motion all the time

x265 settings: defaults with --crf 21 --b-adapt 2
merange 60: 4.61fps psnr: 46.402 size: 63719KB
merange 40: 4.86fps psnr: 46.403 size: 63801KB - 5% faster, 0.13% size increase
merange 24: 5.08fps psnr: 46.404 size: 64194KB - 10% faster, 0.74% size increase

With PSNR almost identical, imho it's worth it to decrease the range for 720p sources. I think I will go with merange 32 or 36 in the future.
Would it be against some convention for the encoder to change default merange depending on input resolution? Surely what is optimal for 4K video isn't optimal for SD...
For example, encoder detects (or rather is told) that the input res is:
>=1080p it sets merange to 60
<1080p and >=720p sets merange to 32 or something like that
<720p sets merange to 24
or we could come up with some clever formula that sets merange depending on pixel count in the frame.
Bad idea?

Your point is well taken. The optimal setting for merange is certainly related to the resolution of the input video, and we are now getting to the point where we can work on better algorithms for setting these variables, just as you have suggested.

Thanks for your feedback! I appreciate you sharing your test data also.

Tom

[fumoffu]

Is aq mode/strength supposed to work already?
It crashes the encoder for me after about 300 frames and what is encoded has artifacts.
I tried on latest (0.5+571-491fd3ee6fd1) 64bit build from x265.cc both vc12 and mingw.

Also few toughs about my earlier points about merange:
- Not sure how the results would change without b-pyramid (which doesn't work with some GOP structures) because if we skip a frame (meaning it can't be used as reference) it might be harder to find some motion vectors that during this frame moved outside search range.
- If we would optimize merange depending on resolution, it could also be optimized for fps. With 60fps video that is much more fluid we could theoretically decrease the motion search by half without much impact on compression.
- My tests video was amateur hand-held camera footage. I'm not sure how it would compare to feature films where the image for the most part doesn't move as much. I bet the difference is size would be even smaller but maybe the gains in speed would be much less noticeable also.

[Sagittaire]

Someone make regular build for this really good open source project?

[x265.cc]

Using the current megui for x265 is a bad idea*.

It comes with old 16bpp (only) builds from various (32bit) compilers.

*performance and quality wise

e.g.

x265 [info]: HEVC encoder version 0.5+259-9d74638c3640
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64

x265 [info]: HEVC encoder version 0.5+554-fdaa754dfbd4
x265 [info]: build info [Windows][MSVC 1700][32 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64

Originally Posted by nakTT

Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?

Any version should fit. You should use 64 bit, 8bpp build (gcc/vc12)

Originally Posted by Sagittaire

Someone make regular build for this really good open source project?

What do you mean with "regular build"?

[Sagittaire]

Originally Posted by Sagittaire

Someone make regular build for this really good open source project?

"regular" in my french language mean "make regulary build" for user like on x264.nl web page ... ;-)

[x265.cc]

Originally Posted by Sagittaire

"regular" in my french language mean "make regulary build" for user like on x264.nl web page ... ;-)

erm..

something like the x265.cc web page?

[Sagittaire]

Originally Posted by x265.cc

erm..

something like the x265.cc web page?

exactly ... lol

thx

[nakTT]

Originally Posted by x265.cc

Any version should fit. You should use 64 bit, 8bpp build (gcc/vc12)

Currently I am using 32bit version of x265 (VC12) from x265.cc.
Should I decide to use the 64bit version as you recommend, do I need to change any settings (or whatever) in the MeGUI? I love to use 64bit if it is not too much trouble. Thanks.

[nakTT]

Originally Posted by x265.cc

erm..

something like the x265.cc web page?

VC12 0.5+571, 0.5+581 and 0.5+584 all crash on me. The latest version that is not crash is 0.5+554. Please advice.

[sborho]

Originally Posted by Selur

sadly, compiling on Mac OS X 10.6.8 is still broken

If you send an email to the x265-devel@videolan.org mailing list with the full compile error, there's a good chance it will get fixed.

[LigH]

@ Sagittaire:

x265 is regularly built.

But still not for users, only for testers.

[Selur]

@sborho: I hope so would be a shame to only be able to use x265 on Mavericks and up.

[xooyoozoo]

Min Keyinterval is currently set to match max keyint with no cli options for otherwise. However, scene detection / key frame placement seems to work perfectly fine if I modify the source. Is there a reason to avoid letting scene detection do its thing?

[Selur]

@xooyoozoo: Did you check what minimal key int interval gets chosen for "--min-key-int" set to 0 (auto) ? (or did you 'simply' use a fixed value for min-key-int?)

[fumoffu]

Originally Posted by fumoffu

Is aq mode/strength supposed to work already?
It crashes the encoder for me after about 300 frames and what is encoded has artifacts.

Correction it does seem to work only with (crazy slow) --rd 2
Is this how it's supposed to be?