x265 HEVC Encoder

[LigH]

May happen. The autobuild binaries are created with the release of each patch, which may introduce bugs.

[fumoffu]

Can someone explain what --cbqpoffs and --crqpoffs options do? and what is the difference between them?
thanks

[Selur]

from what I understand:
Cb and Cr are blue-and red-difference of chroma components, see: http://en.wikipedia.org/wiki/CbCr
qp = quantization parameter
--cbqpoffs sets an offset for the quantization of the blue-difference of the chroma
--crqpoffs sets an offset for the quantization of the red-difference of the chroma
so basically you can change the compression of red and blue color components through it (positive values -> higher quantizer -> higher rounding losses; negative values -> lower quantizer -> less rounding losses)

[mandarinka]

Same as x264's chroma quantizer offset, but you can tweak it separately for both of the chroma channels (funny idea, you probably don't generally want to do that, but maybe some day somebody will ahve use for the flexibility).

[nakTT]

Good day to you guys.

I can see is that the MeGUI running x265 encoder does not seem to follow ABR (say, 300kbps) that I have set. It will somehow mysteriously go way below that value, even way below 100kbps. I do not know if this is issue with how MeGUI handle the x265 or it is an issue with x265 itself. Please advise.:thanks:

[Selur]

@nakTT: megui issue

[Kurtnoise]

@nakTT: megui issue
why did you say that without real information ? :rolleyes:

@NakTT : you should retry with a more recent x265 build...

[nakTT]

@nakTT: megui issue
Thanks for the reply. Will follow up with MeGUI guru in their thread.

[nakTT]

why did you say that without real information ? :rolleyes:

@NakTT : you should retry with a more recent x265 build...
Thanks for the advise. Currently I am using the latest version that I can get through normal update on MeGUI (Development Update Server). Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?
:thanks:

[Selur]

@Kurtnoise: you are right did some further testing and seems like it is related to the input and the settings used :)

[benwaggoner]

Thanks for the advise. Currently I am using the latest version that I can get through normal update on MeGUI (Development Update Server). Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?
:thanks:
There have been lots of parameter changes. You probably don't want to run x265 if you want to be using recent updates. It looks like even the dev server is using an Nov 12th build, which is eons ago for x265 :).

[Selur]

In Hybrid I'm using '0.5+413-2f5f538d2cbc', which seems to be rather stable,..

[nakTT]

There have been lots of parameter changes. You probably don't want to run x265 if you want to be using recent updates. It looks like even the dev server is using an Nov 12th build, which is eons ago for x265 :).
Thanks for the advice.

Just to share my experience today with the latest x265 rev 0.5+524 (VC12) taken from x265.cc. It seems that for the same CQ setting (say, 27), the file size (bitrate) is a bit smaller (around 13% smaller) compared to the one that come with the rev 0.5+259 that come from MeGUI Development Update Server. And the quality isn't getting worse despite the drop in bitrate. Perhaps it was my eyes perhaps not.

[mandarinka]

B-pyramid has been enabled in the encoder AFAIK. That is probably the reason, although at 13 % bitrate reduction, I suspect the quality has dropped a bit too (more bframes which have higher QPs than pframes).

[nakTT]

B-pyramid has been enabled in the encoder AFAIK. That is probably the reason, although at 13 % bitrate reduction, I suspect the quality has dropped a bit too (more bframes which have higher QPs than pframes).
You maybe right and perhaps it just not really apparent to my untrained eyes.;)

BTW, the input video that I used was HD (resolution: 1280 X 528) and the Encoding Mode: CQ (Constant Quality) at 27 running on x265 rev 0.5+524 (VC12).

Now I am encoding (as we speak) on even latter version of x265: rev 0.5+546 (VC12). Will update here if there is any thing worth mentioning.

[fumoffu]

There seems to be a problem with --frame-skip. When I tried to use it, it just skipped all frames.

ffmpeg.exe -i test.mp4 -an -f yuv4mpegpipe - | x265 --y4m --input-res 1280x720 --fps 29.97 --frame-skip 26000 --frames 777 --no-progress --crf 20 - -o test.hevc
In the console window I saw it was still skipping frames even after 30000 frame...
Also skipping frames is suspiciously cpu intensive. And the limiting factor wasn't ffmpeg but x265 which was saturating 25% of my 4 core CPU - 1core. I guess no one implemented multi-threading for skipping frames ;) probably because it shouldn't really be taking almost any cpu power?

[Selur]

frame skip with pipe input would still require x265 to read all the skipped frames,... -> better limit your ranges through ffmpeg
('--frame-skip' should be a normal input only option,..)

[nakTT]

Hi guys.

Do you guys know any short (very high quality, detail as well as complex) video clip that I can download and use as a sample to test x265? Thank you in advance.
:thanks:

[LigH]

Check the Xiph.org Test Media (http://media.xiph.org/) collection. Many are available losslessly as Y4M (but huge downloads!).

Also I provide some files on MediaFire, e.g. the Sintel trailer encoded with x264 in CRF 6 (http://www.mediafire.com/watch/d2wmzz76d47q838/sintel_trailer_1080_crf06.mkv).

[nakTT]

Also I provide some files on MediaFire, e.g. the Sintel trailer encoded with x264 in CRF 6 (http://www.mediafire.com/watch/d2wmzz76d47q838/sintel_trailer_1080_crf06.mkv).
This is more like it. Smaller size like this one would be better for my broadband quota.
:thanks:

[fumoffu]

frame skip with pipe input would still require x265 to read all the skipped frames,... -> better limit your ranges through ffmpeg
('--frame-skip' should be a normal input only option,..)

thanks I will do that, but still that doesn't explain why it doesn't work :/
well at least it's nothing important

[mandarinka]

Maybe you also could use avisynth instead of ffmpeg, and pipe using avs2yuv.

avs2yuv has -seek and -frames options, and it should only forward those selected frames through the pipe. (Note that I never needed to try that.)

[benwaggoner]

Experimenting with a build from Friday, I accidentally encoded Tears of Steel at 3840x1600p24 at 5 Mbps. It looks actually pretty good! I used crazy high quality encoding settings that ran at 0.19 fps on my 12-core, but still. 5 Mbps UHD!

Keep up the good work, guys.

[x265_Project]

I've posted an updated version of the x265 Evaluator's Guide...

x265 Evaluators Guide Nov 24 2013.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Nov%2024%202013.pdf)

Feedback is welcomed.

Tom

[x265_Project]

I just made a couple of last minute corrections... if you downloaded it already, please download again to get the corrected version.

[nakTT]

Thanks. Will do that.

[caiyuwei]

Megui didn't let us config Andvanced Settings of x265 in x265 configuration dialog yet...

[LigH]

@ caiyuwei:

MeGUI r2422 (http://kurtnoise.free.fr/megui/MeGUI-r2422_x265.7z) within x265 basic support, to play with...Only presets and ABR/CRF/QP modes are available for the moment.

I don't expect this limit to be overcome already, from test build r2422 to official build r2424.

If you are an experienced tester, you may prefer other x265 GUIs or even direct editing of CLI options (e.g. in Batch files).

If you are no tester, don't use x265 at all, yet.

[nakTT]

Experimenting with a build from Friday, I accidentally encoded Tears of Steel at 3840x1600p24 at 5 Mbps. It looks actually pretty good! I used crazy high quality encoding settings that ran at 0.19 fps on my 12-core, but still. 5 Mbps UHD!

Keep up the good work, guys.
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.

Personally, I wouldn't dare to go within 10-feet of the resolution you was using. The highest I have gone so far with my ancient so-called ultrabook (i7-3667U) is just HD resolution.

[fumoffu]

I've posted an updated version of the x265 Evaluator's Guide...

x265 Evaluators Guide Nov 24 2013.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Nov%2024%202013.pdf)

Feedback is welcomed.

Tom

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

[x265_Project]

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]

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]

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]

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.

[x265_Project]

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

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)

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

What do you mean with "regular build"?

[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]

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

erm..

something like the x265.cc (https://x265.cc) web page? :D

[Sagittaire]

erm..

something like the x265.cc (https://x265.cc) web page? :D

exactly ... lol

thx

[nakTT]

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.
:thanks:

[nakTT]

erm..

something like the x265.cc (https://x265.cc) web page? :D
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.:thanks:

[sborho]

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]

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?