x265 HEVC Encoder

[MeteorRain]

"Express file" - server of information exchange.

To receive access to information by key you can use the form below.

Nope I can't download these files. Would you mind using mega or mediafile or some others?

[MeteorRain]

Will use MEGA now.

And, I tried different version, at least 439 445 448 and they produced exact the same result file (apart from the header, since they change every time)

Would you please also share your CPU info?

[Ajvar]

Nope I can't download these files. Would you mind using mega or mediafile or some others?

Will use MEGA now.
https://mega.co.nz/#!kMh0ERrI!OUi1gfaDFPoMphHIjeb5vOVOpK2kH0TLSGg8MZM8q3k
2 pass 8000kbps.
All files encoded by 444 and up don't play on LAV 0.64 with enabled CUDA decoding

[MeteorRain]

All files encoded by 444 and up don't play on LAV 0.64 with enabled CUDA decoding

Reproduced.

Would you please tell us how you produce the "MKV" file? From RAW output to MKV?

And could you please try to encode to MKV directly using my build (-full)? And also try to encode to MP4 directly using my build (-full) then remux into MKV?

As far as I can tell, it's due to the "MKV" part.

[Ma]

I also put my mod in my signature for those who want. Compiled with lavf and l-smash.

I decided to test new builds on 1080p file with my current settings.
Test file http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

But there is a problem with yours build -- the result line your build outputs to stderr instead of normal stdout and I have no 2nd time of your build. You can see my test-park-1080p.bat (attached in 7z). Why are you changed this?

[LoRd_MuldeR]

But there is a problem with yours build -- the result line your build outputs to stderr instead of normal stdout

It's a common practice to write all textual output to the stderr stream, so that the stdout stream remains "clean" for piping the actual output data to the next process in the chain.

Imagine you would be running x265 to write the encoded H.265 bitstream to stdout, because you want to process the H.265 stream in another process, but then some status messages get "mixed" into the resulting stream... Bad idea :devil:

[Ajvar]

Reproduced.

Would you please tell us how you produce the "MKV" file? From RAW output to MKV?

And could you please try to encode to MKV directly using my build (-full)? And also try to encode to MP4 directly using my build (-full) then remux into MKV?

As far as I can tell, it's due to the "MKV" part.

Yes, I also noticed yesterday that RAW hevc plays fine. Also Win10 plays it fine too. But my main OS is Windows 7.
I used multiple mkv toolnix versions and result is the same.
EDIT: OK, i managed to mux in MP4 and it plays but... I will tet and describe everything in couple minutes.

[Ma]

It's a common practice to write all textual output to the stderr stream, so that the stdout stream remains "clean" for piping the actual output data to the next process in the chain.

Thanks for the info. I will rewrite my *.bat file (maybe original x265 will be print all text to stderr).

[Ma]

Can't mux in mp4, I am GUI guy and YAMB doesn't let me mux it for some reason.

I downloaded your mkv-file and remuxed to mp4
http://msystem.waw.pl/x265/445-bug.mp4

I don't have nVidia graphics card, so in my system all your files work.

[Ajvar]

I don't have nVidia graphics card, so in my system all your files work.

Yes, Did you notice that Mediainfo says that Heigh of mkv video is 1920x1088 instead of 1920x1080?
I also managed to mux to mp4 and then remux to mkv again and it now works... but I believe that is because after muxing to mp4 Heigh is fixed to 1080.
Now I have to understand why that happened and whose fault: mine, muxer or encoder.
EDIT: Also please check if RAW x265 file was chaged after muxing to mp4 (check checksumms).

[Ma]

Yes, Did you notice that Mediainfo says that Heigh of mkv video is 1920x1088 instead of 1920x1080?
I also managed to mux to mp4 and then remux to mkv again and it now works... but I believe that is because after muxing to mp4 Heigh is fixed to 1080.
Now I have to understand why that happened and whose fault: mine, muxer or encoder.

In my tests your original mkv file works, then I demuxed video and audio and muxed to mp4 -- it works too (1920x1088). But if I mux directly demuxed video & audio to new mkv file, it is only sound (not works). If I "add" to mmg.exe muxed mp4 file and save as new mkv file, everything is OK. Strange...

[Ajvar]

In my tests your original mkv file works, then I demuxed video and audio and muxed to mp4 -- it works too (1920x1088). But if I mux directly demuxed video & audio to new mkv file, it is only sound (not works). If I "add" to mmg.exe muxed mp4 file and save as new mkv file, everything is OK. Strange...

So such behavior may say that there is something with encoded file meaning the way it was encoded.
May I ask you to download original file (https://mega.co.nz/#!lVwiHbJD!FEJPulHQDK29diNhQPP9KFXy3SSFN5tKF1gg7i8CIJE) which is 1920x1080 and encode with the same settings I encode and tell me if such behavior persists (1920x1088 and mux troubles)? Something tells me that it might be due to --min-cu-size 16 because 16x68=1088 but perhaps that is just a shot in the dark.
--pmode --input - --input-res 1920x1080 --fps 30 --no-high-tier --min-cu-size 16 --no-open-gop --crf 22.7 --no-rdoq-level --no-psy-rdoq --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --colormatrix bt470bg

[Ma]

May I ask you to download original file (https://mega.co.nz/#!lVwiHbJD!FEJPulHQDK29diNhQPP9KFXy3SSFN5tKF1gg7i8CIJE) which is 1920x1080 and encode with the same settings I encode and tell me if such behavior persists (1920x1088 and mux troubles)?

I downloaded and encoded via MeGUI. Result http://msystem.waw.pl/x265/t.7z

MediaInfo shows 'Height' 1088 and 'Original height' 1080.

[Ajvar]

I downloaded and encoded via MeGUI. Result http://msystem.waw.pl/x265/t.7z

MediaInfo shows 'Height' 1088 and 'Original height' 1080.

Yep, thank you very much. Problem found: if you set --min-cu-size 16 then frame size will be scewed (1088 instead of 1080) and that will bring a crash on LAV 0.64 if file encoded by x265 1.5+444 and up.

WOW! That was very tricky to find. Not sure if it is a bug or just evolution of x265 encoder/LAV decoder.

[sneaker_ger]

I think it's a bug in mkvmerge. I will make a report.

/edit:
reported: https://github.com/mbunkus/mkvtoolnix/issues/1152

/edit2:
Mosu has fixed the issue for mkvtoolnix 7.9.0. You can test the pre-version:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (687 or newer)

[Ajvar]

I think it's a bug in mkvmerge. I will make a report.

/edit:
reported: https://github.com/mbunkus/mkvtoolnix/issues/1152

/edit2:
Mosu has fixed the issue for mkvtoolnix 7.9.0. You can test the pre-version:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (687 or newer)

Yes, thank you, I would never report this bug in such way with documentation and formulas.
It really fixed MediaInfo information about Height, but funny or not, it still crashes my player the same way if I mux in mkv, but plays fine if I mux in mp4:)

Even more! As I see those crashes have nothing with min-cu-size 16 because I just tested it with both settings! It is another bug in MkvToolnix because if I remux streams from affected video file or encode directly to MP4 and then remux to MKVToolnix (direct drop MP4 into the window) then and only then it works!

This is just hilarious. I spent all day, found 2 bugs in 2 different software (forced --min-cu-size 16 instead of 8 in Hybrid and crop in mkv toolnix) but STILL suffer from crashes by unidentified bug!:scared:
Samples here (https://mega.co.nz/#!NRAjjYrB!GVTsic5cED4lwXxIf8J334AmJVCPOirYRa-5EYrsNhE): working MP4 with LAV 0.64-CUDA and 2 non-workiing MKV with min blocks 8 and 16.

Long story short: encodes by x265 >=1.5+444 muxed in MKV will crash trying to play with LAV 0.64 and CUDA decoding.
And could you please try to encode to MKV directly using my build (-full)?
As far as I can tell, it's due to the "MKV" part.

Could you please give me command line for that so I would just edited source?

[Ma]

Long story short: encodes by x265 >=1.5+444 muxed in MKV will crash trying to play with LAV 0.64 and CUDA decoding.

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

[Ajvar]

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

I found it. It's about setting vbv-max rate.
This line works fine:
x265 --preset slower --pools 8 --pmode --pme --input - --input-res 1920x1080 --fps 30 --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 7 --crf 22.7 --qpfile GENERATED_QP_FILE --psy-rd 0.5 --psy-rdoq 1 --deblock=-1:-1 --output "T:\Temp\output.265"
This crashes.
x265 --preset slower --pools 8 --pmode --pme --input - --input-res 1920x1080 --fps 30 --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 7 --crf 22.7 --qpfile GENERATED_QP_FILE --psy-rd 0.5 --psy-rdoq 1 --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --output "T:\Temp\output.265"
And all became after 444+ encoder.
Now WHY is that? - That's the question. 439 is OK, 444 is NOT so it's narrow window.
HOW is that connected with LAV 0.64 with CUDA decoding - that's too. But this may be not the only symptom.
WHY only MKV but MP4 plays fine? - another mystery.
But I finally found this bug and... feel stupid that spent so much time on it:) But if it will be fixed, I will feel somewhat better:)
Here are samples, check yourself (https://mega.co.nz/#!wdJhjJzK!KqDAg8_4D3PYz8Fe7AYl14etbVugYIOcLheb7MZRfjM).

[sneaker_ger]

I think Ma was hinting at the size of the custom SEI x265 writes. With more parameters (esp. long ones like --vbv) it becomes longer and maybe it triggers a crash in LAV/CUVID because of that. Try to recreate your latest crash sample but with "--no-info". Either way, it's unclear where the bug is. Since it crashed in the Nvidia software I think they are to blame.

[Ajvar]

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

I think Ma was hinting at the size of the custom SEI x265 writes. With more parameters (esp. long ones like --vbv) it becomes longer and maybe it triggers a crash in LAV/CUVID because of that. Try to recreate your latest crash sample but with "--no-info". Either way, it's unclear where the bug is. Since it crashed in the Nvidia software I think they are to blame.

Emm, it worked! It. Really. Worked!:thanks:

Now I go sleep, too tired

[LazyNcoder]

Guys let me get this straight. 10bit videos bring better color range(like, they remove banding) but they make the details/quality lower at the same bitrate as 8bit vids. Am I right?
I mean, encoder has to store 10bit pictures in same size/bitrate as 8bit pictures.
I did two encodes, one was x265 8bit version and the other was 10bit. it looks like the 10bit version could use a little higher CRF/bitrate to look the same as 8bit version.

Also, Noob question, what is the difference between main 10 profile and 10bit encoder? isn't it better just to use main 10 profile instead of 10bit encoder?

[MeteorRain]

Could you please give me command line for that so I would just edited source?

You can try

x265-Xbit-full -o test.mkv source.mkv --YOUR --OTHER --PARAM --HERE

- or, use -

-o test.mp4

to produce MP4 files.

This way it'll use Haali MKV Muxer / L-SMASH MP4 Muxer to mux your hevc data on the fly when writing files.

You can also use --opts 1 to skip writing all the param string into hevc header and still keep the SEI segment, While the --no-info option will completely remove the SEI.

I suspect that there's still a bug inside mkvmerge.

[Ma]

Emm, it worked! It. Really. Worked!:thanks:

Now I go sleep, too tired

Mkvmerge add extra one SEI if mux raw HEVC stream, not add extra one if remux from MP4. x265 1.5+444 gives longer SEI (because --rdoq-level and deblock). If longer SEI is doubled, it crash with nVidia decoder.

My software LAV decoder stop working with your example after the SEI was tripled -- in your original MKV it was doubled, I demux video track and mux again to MKV (2 + 1 = 3).

Workaround to this mkvmerge bug: first mux to MP4 and then to MKV not works with large files -- I try with 6 GB HEVC stream and mkvmerge crashes when remuxing from MP4.

If you take v1.hevc file with nonempty SEI and execute:
mkvmerge -o v2.mkv v1.hevc
mkvextract tracks v2.mkv 0:v2.hevc
mkvmerge -o v3.mkv v2.hevc
mkvextract tracks v3.mkv 0:v3.hevc
mkvmerge -o v4.mkv v3.hevc
mkvextract tracks v4.mkv 0:v4.hevc
mkvmerge -o v5.mkv v4.hevc
mkvextract tracks v5.mkv 0:v5.hevc
mkvmerge -o v6.mkv v5.hevc
mkvextract tracks v6.mkv 0:v6.hevc
...

The number of SEI in the files should be equal the number in filename.

[MeteorRain]

Guys let me get this straight. 10bit videos bring better color range(like, they remove banding) but they make the details/quality lower at the same bitrate as 8bit vids. Am I right?
I mean, encoder has to store 10bit pictures in same size/bitrate as 8bit pictures.
I did two encodes, one was x265 8bit version and the other was 10bit. it looks like the 10bit version could use a little higher CRF/bitrate to look the same as 8bit version.

Also, Noob question, what is the difference between main 10 profile and 10bit encoder? isn't it better just to use main 10 profile instead of 10bit encoder?

Higher precision leads to less quality loss. 10bit encoding uses 25% more bitrate to store the same amount of pixels, but the benefits are more than 25% so that if you decrease the bitrate to the same level (thus higher CRF), it should still maintain better quality.

At least this is true on x264. With x265 there are still rooms for improvement. Let's see.

To your second question. Main10 is a profile that also covers lower profile such as Main. It's the highest complexity a video can be. Thus with Main profile, the video can only be 8 bit, while with Main10, it can be 8 up to 10 bit. And with the coming Main 12 profile, it can be 8 up to 12 bit.

[stax76]

I released a new beta version with some video encoder improvements and made a snapshot of both the help page and the code file that contains the defaults so later I can use a diff tool to catch all changes.


Added GUI for NVEncC (tool for NVIDIA H.264/H.265 GPU encoding)
Added GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Added x265 option --pools
Added x265 option --frame-threads
Added x265 option --min-cu-size
Added x265 option --log-level frame and updated help for --log-level
Updated x265 to version 1.5+370
Updated QSVEncC (tool for Intel H.264 GPU encoding) to version 1.32


http://sourceforge.net/projects/staxmedia/?source=navbar

[LazyNcoder]

Higher precision leads to less quality loss. 10bit encoding uses 25% more bitrate to store the same amount of pixels, but the benefits are more than 25% so that if you decrease the bitrate to the same level (thus higher CRF), it should still maintain better quality.

At least this is true on x264. With x265 there are still rooms for improvement. Let's see.

To your second question. Main10 is a profile that also covers lower profile such as Main. It's the highest complexity a video can be. Thus with Main profile, the video can only be 8 bit, while with Main10, it can be 8 up to 10 bit. And with the coming Main 12 profile, it can be 8 up to 12 bit.
Thanks a lot.

so, using main 10 profile is better than forcing the video to be 10bit(for lower crf/bitrate videos). Am I right?


I released a new beta version with some video encoder improvements and made a snapshot of both the help page and the code file that contains the defaults so later I can use a diff tool to catch all changes.


Added GUI for NVEncC (tool for NVIDIA H.264/H.265 GPU encoding)
Added GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Added x265 option --pools
Added x265 option --frame-threads
Added x265 option --min-cu-size
Added x265 option --log-level frame and updated help for --log-level
Updated x265 to version 1.5+370
Updated QSVEncC (tool for Intel H.264 GPU encoding) to version 1.32


http://sourceforge.net/projects/staxmedia/?source=navbar

Correct me if I'm wrong. since v1.5 of x265, --aq-mode 1 is default. but in StaxRip it's still --aq-mode 2. I mean you can only change it to --aq-mode 1 or 0 or default which is --aq-mode 1. so no --aq-mode 2 until you write it in "Custom Switches".
Selecting auto-variance removes the --aq-mode switch and let the encoder uses the default value which is not auto-variance.

[LigH]

Another weekly, stable merge build.

x265 1.5+448-22a312799bb0 (GCC 4.8.2 EXE + DLL) (https://www.mediafire.com/download/auas2wib54x9nxi/x265_1.5+448-22a312799bb0.7z)
x265 1.5+448-22a312799bb0 (GCC 4.9.2 UPX-EXE) (https://www.mediafire.com/download/ogq99y9vl285w0y/x265_1.5+448-22a312799bb0.GCC492.7z)

It seems that the x265 project will allow easier configuring for native architecture optimized builds. If I would enable this feature, my builds would probably still be generated for SSE2 or SSE3, using AMD K10 architecture (Phenom-II). I did not yet change my workflow.

[stax76]

@LazyNcoder

Thanks, I've missed it, here is a fix: https://www.dropbox.com/s/n5q0jhukdkrt6jm/StaxRip_2015.03.30.7z?dl=0

You should download EXE + DLL, drop the content in the x265 folder and run the batch file located in the x265 folder, I hope LigH unifies it.

[MeteorRain]

Thanks a lot.

so, using main 10 profile is better than forcing the video to be 10bit(for lower crf/bitrate videos). Am I right?


No it's not. Put 8 bit video inside Main 10 means you are driving away any decoders that can't properly decode 10 bit video. You are more likely "forcing a profile" in this situation.

It's like you are looking for a driver to drive a personal sedan car but claim to require a commercial driving license, thus kicking away those who don't have one, and it's unnecessary.

That's why we use the lowest profile that fits the video to increase compatibilities.

[LigH]

..., I hope LigH unifies it.

What do you want me to do? Please explain more verbosely.

The GCC 4.8.2 package contains both static EXE and DLL versions because the default scripts by Multicoreware create both. If you intend to use only the EXE, omit the DLL; the DLLs are included only for developers who prefer to link them instead of calling the EXE.

The GCC 4.9.2 package was compiled by the media-autobuild_suite which does not provide a DLL, only the EXE. I would not be able to change this script accordingly. Most GUI developers use the EXE only, anyway. I wonder if I should also disable UPX, the uncompressed EXE are easier to pack by 7-zip (more similarities among them).

[stax76]

What do you want me to do? Please explain more verbosely.

The GCC 4.8.2 package contains both static EXE and DLL versions because the default scripts by Multicoreware create both. If you intend to use only the EXE, omit the DLL; the DLLs are included only for developers who prefer to link them instead of calling the EXE.

The GCC 4.9.2 package was compiled by the media-autobuild_suite which does not provide a DLL, only the EXE. I would not be able to change this script accordingly. Most GUI developers use the EXE only, anyway. I wonder if I should also disable UPX, the uncompressed EXE are easier to pack by 7-zip (more similarities among them).

use identical folder and file names, StaxRip expects different names so I included a batch file everybody can use, expanding the batch file to handle both packages might also work, at the moment it looks like this:

Rename Win32_8bpp "32-Bit 8-Bit"
Rename Win32_16bpp "32-Bit 10-Bit"
Rename Win64_8bpp "64-Bit 8-Bit"
Rename Win64_16bpp "64-Bit 10-Bit"

[sneaker_ger]

Mkvmerge add extra one SEI if mux raw HEVC stream, not add extra one if remux from MP4. x265 1.5+444 gives longer SEI (because --rdoq-level and deblock). If longer SEI is doubled, it crash with nVidia decoder.[...]

I have written an answer in the the mkvtoolnix thread (http://forum.doom9.org/showthread.php?p=1715328#post1715328). We should take the discussion there, it's not a problem of x265.

[Ajvar]

You can try
x265-Xbit-full -o test.mkv source.mkv --YOUR --OTHER --PARAM --HERE
- or, use -o test.mp4 to produce MP4 files.
This way it'll use Haali MKV Muxer / L-SMASH MP4 Muxer to mux your hevc data on the fly when writing files.

You can also use --opts 1 to skip writing all the param string into hevc header and still keep the SEI segment, While the --no-info option will completely remove the SEI. I suspect that there's still a bug inside mkvmerge.
Thank's for sharing, will use it later. I believe this will be better than toolnix then.
I have written an answer in the the mkvtoolnix thread (http://forum.doom9.org/showthread.php?p=1715328#post1715328). We should take the discussion there, it's not a problem of x265.
You are like a moderator but better:) Taking all info, drying it out to get the most important and make right conclusions... and even continue digging, thank you! I see that mkvtoolnix' author is not going to change that, oh well... will mux in mp4 then or use direct mkv muxing as told above.

[Ma]

I made new fprofiled builds of 10-bit x265 and compare them to my normal build with "-O2 -march=corei7-avx" options.

Win7 64-bit, i5 3450S, test video http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

Warriors:
x265-AVX -- compiled with options "-static -s -O2 -march=corei7-avx -mtune=corei7-avx"

x265-AVXp-O2 -- compiled with options:
"-static -s -O2 -march=corei7-avx -mtune=corei7-avx -fprofile-generate" for first pass
"-static -s -O2 -march=corei7-avx -mtune=corei7-avx -fprofile-use -fprofile-correction" for second pass

x265-AVXp-O3n -- compiled with options:
"-static -s -O3 -fno-tree-vectorize -march=corei7-avx -mtune=corei7-avx -fprofile-generate" for first pass
"-static -s -O3 -fno-tree-vectorize -march=corei7-avx -mtune=corei7-avx -fprofile-use -fprofile-correction" for second pass

Result:
x265-AVX | 413.45s | 1.22 fps | 100.0%
x265-AVXp-O2 | 408.58s | 1.23 fps | 98.8%
x265-AVXp-O3n | 409.15s | 1.23 fps | 99.0%

Accuracy: +/- 1.23s = +/- 0.3%

Full result, builds and test.bat -- http://msystem.waw.pl/x265/test3.7z

[x265_Project]

Until now, HEVC has been a technology for experts and hard-core video enthusiasts only. We have a fast, reliable HEVC decoder, called UHDcode, but we needed to find a way to make this available for everyone to try. x265 was available in source code form, but we didn't have an application available directly from the x265 team.

To make it easier for anyone to try x265 and experience the benefits of HEVC, today we're launching the x265 HEVC Upgrade (https://x265.com). We've created a new Windows 64 bit application that lets you convert MP4 files to HEVC. There is a new Basic Mode which anyone non-technical person should be able to use. In Advanced Mode we expose the full feature set of x265.

The x265 Encoder application is bundled with our UHDcode HEVC decoder, packaged as a Windows DirectShow filter; a plug-in for Windows Media Player. This upgrades Windows Media Player (64 bit) to play back HEVC video files (raw bitstreams or MP4 files with HEVC).

The MSRP of the x265 HEVC Upgrade is $29.95, but for a limited time you can download for free at www.x265.com (https://x265.com). We hope you find these applications valuable.

[stax76]

How does the free download work?

[benwaggoner]

How does the free download work?
You need to set up an account, but don't need to give any financial information. Make sure to hit the "Apply Coupon" button (which has the code pre-filled) to make it $0.

Took me about 90 seconds from clicking the link to having it installed.

[NikosD]

I'm doing the procedure from the mobile phone and although it gave me a discount, it had already charged me with a quantity of 2, so I had to pay 29.95$

I cancelled the order and tried to put a new one with quantity 1, but there is no discount now.

I see no coupon.

Obviously I'm doing something wrong...

[x265_Project]

I'm doing the procedure from the mobile phone and although it gave me a discount, it had already charged me with a quantity of 2, so I had to pay 29.95$

I cancelled the order and tried to put a new one with quantity 1, but there is no discount now.

I see no coupon.

Obviously I'm doing something wrong...
I'll PM you a link to the download and a key Nikos. For others... make sure your shopping cart has a quantity of 1 before you check out. The coupon code should be filled out already. The coupon code can only be used once by each person.

[stax76]

You need to set up an account, but don't need to give any financial information. Make sure to hit the "Apply Coupon" button (which has the code pre-filled) to make it $0.

Took me about 90 seconds from clicking the link to having it installed.

Try this kick as Firefox plugin, next time you might make 85. :D

https://addons.mozilla.org/en/firefox/addon/smartfill

[Gravitator]

This plugin supports playback of non-standard B16 frames?

[stax76]

@x265_Project

Which font size is the x265 GUI using? It looks like 7 which is kind of challenging for old man like me.

[x265_Project]

This plugin supports playback of non-standard B16 frames?
I don't know... you would have to try it. We test UHDcode against a wide range of spec-compliant HEVC bitstreams, but as far as I know, it is also designed to decode any bitstream regardless of whether it fits a legal profile (we don't ask questions, we just decode). Of course, our main objective is to make sure that any possible legal bitstream can be decoded quickly and accurately. We look forward to your feedback.

[x265_Project]

@x265_Project

Which font size is the x265 GUI using? It looks like 7 which is kind of challenging for old man like me.
I don't know. As you know, it's challenging to squeeze all the advanced options in a single UI. Expect ongoing improvement in this area.

[LigH]

Will this project still exist the day after tomorrow? ;) ;)

[x265_Project]

Will this project still exist the day after tomorrow? ;) ;)
Now why do you have to go and say a thing like that? You of all people. :)

Of course it will. The x265 HEVC Upgrade is a straightforward product that enables and delivers of two of our core technologies; x265 and UHDcode.

[stax76]

I don't know. As you know, it's challenging to squeeze all the advanced options in a single UI. Expect ongoing improvement in this area.

I know but for me it's different since my GUI is built from code (no form designer) resulting in not more then one option per "line" in most cases.

[LigH]

Just funny to see projects announced around the 1st of April. But okay, it appears to be more credible than systemd forking the Linux kernel (resistance is futile)...

[LigH]

Building x265 with GCC now supports STATIC_LINK_CRT to include minimal Windows GUI API support, as yet linked from the basic MSVCRT.DLL; would you rate this option useful / important / irrelevant? This DLL will probably be present in quite any Windows version, I believe; linking it statically may not be as important as when someone would compile using MS Visual Studio, but rather add redundant code to the distributed binaries, I guess?

[uneedme]

Just funny to see projects announced around the 1st of April. But okay, it appears to be more credible than systemd forking the Linux kernel (resistance is futile)...

not april fool?

truly?

[grumpy]

$29.95, Does that make it more plausible or less plausible? What is this about? I don't get it.

[LigH]

I did not yet try this software, instead I (personally) will try to rely on freeware in the future too; but for these users who prefer it simple and specific, it is a limited time offer to "purchase" it with a 100% discount, you will only have to register to obtain a bundle of an "MP4 to HEVC"* converter plus a DirectShow HEVC decoder.

*I guess the result will be HEVC video + supported audio again in an MP4 container. But I have seen a modified x265 including L-SMASH as MP4 multiplexer already. And I can multiplex raw HEVC into MP4 later too, with MP4Box or L-SMASH. If you can handle our known-good free converters (like MeGUI, Hybrid, StaxRip), you may have little need for "x265 HEVC Update".

[NikosD]

Since there is no UHDcode plugin HEVC decoder thread yet, I have evaluated the decoder in my thread.
For anyone interested it's here:
http://forum.doom9.org/showthread.php?p=1715668#post1715668

[LigH]

Enabling the STATIC_LINK_CRT cmake option does not (yet) generate a Windows executable with statically linked CRT. I believe it is just "prepared support" for when it will be implemented...

[Kurtnoise]

Until now, HEVC has been a technology for experts and hard-core video enthusiasts only. We have a fast, reliable HEVC decoder, called UHDcode, but we needed to find a way to make this available for everyone to try. x265 was available in source code form, but we didn't have an application available directly from the x265 team.

To make it easier for anyone to try x265 and experience the benefits of HEVC, today we're launching the x265 HEVC Upgrade (https://x265.com). We've created a new Windows 64 bit application that lets you convert MP4 files to HEVC. There is a new Basic Mode which anyone non-technical person should be able to use. In Advanced Mode we expose the full feature set of x265.

The x265 Encoder application is bundled with our UHDcode HEVC decoder, packaged as a Windows DirectShow filter; a plug-in for Windows Media Player. This upgrades Windows Media Player (64 bit) to play back HEVC video files (raw bitstreams or MP4 files with HEVC).

The MSRP of the x265 HEVC Upgrade is $29.95, but for a limited time you can download for free at www.x265.com (https://x265.com). We hope you find these applications valuable.
Activation does not work for me...I got an ERR_NETWORK message. Probably because I'm behind a proxy ?

[Ma]

Enabling the STATIC_LINK_CRT cmake option does not (yet) generate a Windows executable with statically linked CRT. I believe it is just "prepared support" for when it will be implemented...

You can unpack attached ma.7z to build folder and use "./ma.sh" for native toolchain or "./ma-c.sh" for cross-compile toolchain. It works in "build/ma" folder instead of "build/msys".

If it works you can patch cmake updating one file from cmake-mod.7z -- it removes default -O3 optimize option which is added at the end of compiler options and unable to specify any option below -O3.

[grumpy]

So partially crippled decoder, a limited x.265 GUI, an installer that messes with file association requires activation and God knows what else, and a cart system that is iffy and requires email registration. Also little information for where this is going.

[x265_Project]

So partially crippled decoder, a limited x.265 GUI, an installer that messes with file association requires activation and God knows what else, and a cart system that is iffy and requires email registration. Also little information for where this is going.
Grumpy,
As you know, most consumers only have 8 bit capable graphics chips/drivers, and displays. True 10 bit capable systems tend to be rather expensive and uncommon. UHDcode automatically accelerates on AMD OpenCL capable graphics (latest generation), including both APUs and discrete GPUs. We're working to extend this acceleration to Intel and NVIDIA graphics. I'm not sure why we didn't fare so well in a head to head with LAV, but I suspect that the problem is in the DirectShow communication. Our DShow filter decodes frames and gets them ready for the player, which requests them as needed. It wasn't built for benchmarking (decode as fast as you can... don't wait for the player). I'm just speculating... I'll definitely check into this.

We'll be happy to address any concerns about how the x265 HEVC upgrade sets file associations. I'll take this up with our dev team.

What limitations are you referring to in the x265 Encoder UI?

Our cart system doesn't require email registration (it doesn't make you confirm your email address before it lets you get the product). You can put a fake email address in, and still get the product. However, you won't be able to log into the cart later to see your order or retrieve your key if you use a fake email address.

Our license activation server suffered some hiccups yesterday, and our team has taken care of it. We'll keep an eye on this. In the meantime, if anyone had a problem, PM me the email you used when you checked out, and I can check into it. I can send you another key if needed.

I think we've been fairly open about what this is, and isn't, and I'm happy to shed more light on where it's going. It's a useful ready-to-use implementation of our HEVC libraries. We're not heading down a path of competing with companies that build complete video encoding systems (our customers). We simply wanted to make x265 and UHDcode more accessible to the average person. If you're a power user who is already happy with our command-line interface, or one of the many applications that incorporates x265, this is probably not for you.

[vivan]

As you know, most consumers only have 8 bit capable graphics chips/drivers, and displays. True 10 bit capable systems tend to be rather expensive and uncommon.So what? 10-bit encoding benefits (perfect gradients) are obvious not only on 8 bit displays, but even on cheap 6-bit displays - as long as real dithering is used.

I'm not sure why we didn't fare so well in a head to head with LAV, but I suspect that the problem is in the DirectShow communication. Our DShow filter decodes frames and gets them ready for the player, which requests them as needed. It wasn't built for benchmarking (decode as fast as you can... don't wait for the player). I'm just speculating... I'll definitely check into this.If low perfomance was caused by DS stalling then CPU load would be low. Which isn't true.
Please don't say that you never tested your "fastest in the world" claim against the most popular decoder, this is just silly.

[huhn]

it doesn't matter if you don't have a 10 bit display. it is well know that encoding in 10 bit is more efficient and a common practice these days. even the nvidia 960 GTX can do ASIC 10 bit HEVC and of cause it can even public broadcast is 10 bit.

BTW. nearly all directx 10 GPUs can output 10 bit or more using DP/HDMI by using a directx fullscreen surface.

[MeteorRain]

Grumpy,
As you know, most consumers only have 8 bit capable graphics chips/drivers, and displays. True 10 bit capable systems tend to be rather expensive and uncommon.

Simple thing. Japan UHD broadcasting is HEVC 10 bit. Period.

[benwaggoner]

Simple thing. Japan UHD broadcasting is HEVC 10 bit. Period.
And AFAIK, all UHD Smart TVs support 10-bit decode. At least all the ones I've been involved with.

[Motenai Yoda]

So what? 10-bit encoding benefits (perfect gradients).
10bit don't assures you to get "perfect gradients", is only much less prone to visible banding at sane bitrate/crf (eg under 30).

@LigH have you tried to compile ffmpeg as shared to get x265's dll?
also which ver do you use, 3.5 doesn't work at all for me.

@x265_Project I noticed crf 22 is much faster than others values it's right?
and the -f (-f/--frames) switch seems do nothing, but --frames works.

[Ajvar]

If you want 10 bit then HEVC Upgrade is for differen't audience. It's for those who doesn't see anything wrong with "convert mp4 to HEVC" albeit still that phrase should be changed I think.
Those who got it for free got it for feedback purpose but it should be constructive.

[LigH]

@LigH have you tried to compile ffmpeg as shared to get x265's dll?

I won't build x265 regularly with GCC 4.9.2 via media-autobuild_suite, too many dependencies which could update to a failing state.

also which ver do you use, 3.5 doesn't work at all for me.

Which version of ... what? :confused: I don't remember anything having version 3.5 at the moment.

[burfadel]

I mentioned something along this line in the Staxrip thread...

I was thinking about the --merange, and how the default is 57. This makes sense with UHD material, but if you are encoding lower resolution material, this value is 'too high' for standard encoding. Effectively, the lower the resolution, proportionally the higher the merange of the image as a whole, so such a value becomes pointless at lower resolutions. Even at 1080P, 24 seems good with hardly an efficiency loss, and is signficantly faster. If encoding 720P or even 480P like many people, having a merange of 24 is very beneficial in terms of speed, and on the faster presets even a value of 16 would probably make sense at 480P or lower.

I think an effective 'solution' to this would be an auto option as default. Under auto, it would encode at say, 16 range at less than 480P source material, 24 range at up to 1080P, then scale it towards 57 up to UHD material. Maybe even re-evaluating 57 as a target range at UHD under the standard preset. I hope that makes sense! Just I don't see a 'one-size-fits-all' as appropriate since a merange of 57 at 720x480P is considerably greater than 57 at 3840x2160.

[Ajvar]

@burfadel, if I recall correct devs increased ME-range on faster presets because it didn't affect speeds.

[littlepox]

Agreed on the criticism about me_range. I'm currently using me_range=25 for 1080p, which is about 2% larger in size, but with 30% speed improvement, and I don't see any noticeable visual quality loss.

However, --rect and --amp are the two parameters I believe to be least useful. they double your encoding time with zero gain; I don't see any change for the output, neither quality-wise nor size-wise. Maybe they bring you slightly better psnr/ssim, whatever.

[burfadel]

Agreed on the criticism about me_range. I'm currently using me_range=25 for 1080p, which is about 2% larger in size, but with 30% speed improvement, and I don't see any noticeable visual quality loss.

However, --rect and --amp are the two parameters I believe to be least useful. they double your encoding time with zero gain; I don't see any change for the output, neither quality-wise nor size-wise. Maybe they bring you slightly better psnr/ssim, whatever.

Exactly my point :). A setting of 57 would fall more in the very slow preset range, at least at 1080P. I can understand it at 2160P, but without native (not upscaled) source material at that resolution I can't guarantee that. In any case, for 'normal' preset the difference in speed doesn't warrant the performance decrease.

Also try using the following settings (rest as default, except for including your --merange 25), and see what you think versus standard settings.

--tu-inter-depth 2
--b-intra
--rc-lookahead 80
--max-merge 5
--weightb
--aq-mode 2
--nr-intra 400
--nr-inter 400
--bframes 5
--ref 5

Interestingly enough, --fast-intra is fractionally slower, at least for me, than not using it at all...

I believe the noise reduction noticeably reduces output size, doesn't really affect encoding speed, and doesn't affect the visual quality noticeably (especially at 400). I believe it removes 'high-level' noise from the picture? This of course will affect SSIM since it's a change from the original picture, but if lowering the SSIM is always bad, then psy-rd is bad (which it isn't) ;).

[x265_Project]

x265 1.6 has been released. The changes from the 1.5 release are mostly performance oriented, with heavy improvements for AVX2 capable platforms (Haswell and later Intel CPUs) and work efficiency improvements for multiple-socket machines.

= API changes =

--threads N replaced by --pools N,N and --lookahead-slices N --[no-]rdoq-level N - finer control over RDOQ effort --min-cu-size N - trade-off compression for performance --max-tu-size N - trade-off compression for performance --[no-]temporal-layers - code unreferenced B frames in temporal layer 1 --[no-]cip aliases added for --[no-]constrained-intra

Added support for new color transfer functions "smpte-st-2084" and "smpte-st-428

--limit-refs N was added, but not yet implemented

Deprecated x265_setup_primitives() was removed from the public API and is no longer exported DLLs

See the online documentation for full descriptions:

http://x265.readthedocs.org/en/1.6/


= Threading changes =

The x265 thread pool has been made NUMA aware. The --threads parameter, which used to specify a global pool size, has been replaced with a --pools parameter which allows you to specify a pool size per NUMA node (aka CPU socket or package). The default is still to allocate one pool worker thread per logical core on the machine, but with --pools one can isolate those threads to a given socket.

Other than socket isolation, the biggest visible change in the NUMA aware thread pools is the increase in work efficiency. The total utilization will generally decrease but the performance will increase since worker threads spend less time context switching. Also, the threading of the lookahead was made more work-efficient. Each lookahead job is a much larger piece of work.

Before (1.5):

disable thread pool: --threads 1
default thread pool: --threads 0
restrict to 4 threads: --threads 4

After (1.6):

disable thread pools: --pools 0
default thread pools: --pools *
restrict to 4 threads: --pools 4
restrict to 4 threads on socket 1: --pools -,4 restrict to all threads on socket 0: --pools +,-


= Multi-lib interface =

In order to support runtime selection of a libx265 shared library, we have introduced an x265_api structure and an x265_api_get() function.
Applications which use this interface to acquire the libx265 functional interface will be able to use shim libraries to bind a particular build of libx265 at run time. See the API documentation for full details.

[stax76]

I think an effective 'solution' to this would be an auto option as default. Under auto, it would encode at say, 16 range at less than 480P source material, 24 range at up to 1080P, then scale it towards 57 up to UHD material. Maybe even re-evaluating 57 as a target range at UHD under the standard preset. I hope that makes sense! Just I don't see a 'one-size-fits-all' as appropriate since a merange of 57 at 720x480P is considerably greater than 57 at 3840x2160.

I could add it like so:

Property MErange As New NumParam With {
.Switch = "--merange",
.Text = "ME Range (0=auto):",
.Help = "Motion search range. The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames. Range of values: an integer from 0 to 32768.",
.MinMaxStep = {0, 32768, 1},
.ArgsFunc = Function() If(MErange.Value = 0, " --merange " & CInt(Calc.GetYFromTwoPointForm(480, 16, 2160, 57, p.TargetHeight)), If(MErange.Value <> MErange.defaultvalue, " --merange " & CInt(MErange.Value), ""))}


This would behave exactly like before except when you enter 0 it would use your suggested calculation:

Calc.GetYFromTwoPointForm(480, 16, 2160, 57, p.TargetHeight)

[x265_Project]

I could add it like so:

Property MErange As New NumParam With {
.Switch = "--merange",
.Text = "ME Range (0=auto):",
.Help = "Motion search range. The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames. Range of values: an integer from 0 to 32768.",
.MinMaxStep = {0, 32768, 1},
.ArgsFunc = Function() If(MErange.Value = 0, " --merange " & CInt(Calc.GetYFromTwoPointForm(480, 16, 2160, 57, p.TargetHeight)), If(MErange.Value <> MErange.defaultvalue, " --merange " & CInt(MErange.Value), ""))}


This would behave exactly like before except when you enter 0 it would use your suggested calculation:

Calc.GetYFromTwoPointForm(480, 16, 2160, 57, p.TargetHeight)
First, we've got one more week before we head to the NAB show in Las Vegas, so we're pretty busy, focused on finishing up certain things that we're working on. So thanks for your patience if I don't read/respond to every thread every day.

We're certainly willing to look at this. There are 2 schools of thought on dynamic/variable values. One group would say you should never do this, because the user won't know (remember) what setting they would be getting. The other group (me included) would say that it's OK - do whatever it takes to automatically get the best speed vs quality at any preset. Besides, the user can always manually set any option.

Feel free to share any test data you have on the effects on performance and quality when you vary merange at each picture size. The recent change in merange was prompted by testing a large batch of 1080P clips, where we noticed that merange 57 had slightly better quality with no tradeoff in speed. But we can never do as much testing as the whole x265 community, and as an open source project, we love the benefit of being able to extend our own R&D by crowd-sourcing some of the tuning / performance presets. This feedback is very valuable.

[Atak_Snajpera]

Under auto, it would encode at say, 16 range at less than 480P source material, 24 range at up to 1080P, then scale it towards 57 up to UHD material. Maybe even re-evaluating 57 as a target range at UHD under the standard preset. I hope that makes sense!
Ok what you say makes sense but why exactly 24 for 1920x1080? I think "correct" value would be 28.

In delphi code I would use this simple formula
x265_auto_merange := Trunc( Height * Width / (3840 * 2160) * 57 * 2 );

[1.77:1] 3840x2160 => 57
[1.85:1] 3840x2076 => 54
[2.35:1] 3840x1632 => 43
[2.40:1] 3840x1600 => 42
[1.33:1] 2880x2160 => 42

[1.77:1] 1920x1080 => 28
[1.85:1] 1920x1038 => 27
[2.35:1] 1920x816 => 21
[2.40:1] 1920x800 => 21
[1.33:1] 1440x1080 => 21

[1.77:1] 1280x720 => 12
[1.85:1] 1280x692 => 12
[2.35:1] 1280x544 => 9
[2.40:1] 1280x534 => 9
[1.33:1] 960x720 => 9

Ofcourse the question is should we calculate this on total number of pixels or just on width or height?

[x265_Project]

Ok what you say makes sense but why exactly 24 for 1920x1080? I think "correct" value would be 28.

In delphi code I would use this simple formula
x265_auto_merange := Trunc( Height * Width / (3840 * 2160) * 57 * 2 );

[1.77:1] 3840x2160 => 57
[1.85:1] 3840x2076 => 54
[2.35:1] 3840x1632 => 43
[2.40:1] 3840x1600 => 42
[1.33:1] 2880x2160 => 42

[1.77:1] 1920x1080 => 28
[1.85:1] 1920x1038 => 27
[2.35:1] 1920x816 => 21
[2.40:1] 1920x800 => 21
[1.33:1] 1440x1080 => 21

[1.77:1] 1280x720 => 12
[1.85:1] 1280x692 => 12
[2.35:1] 1280x544 => 9
[2.40:1] 1280x534 => 9
[1.33:1] 960x720 => 9

Ofcourse the question is should we calculate this on total number of pixels or just on width or height?
The ideal merange setting can't be calculated theoretically. An optimization like this should be based on lots of actual test data, showing the ideal setting given the speed vs. quality tradeoff at the affected performance presets (presumably, only at faster presets). A large basket of test content (with a variety of content types) would need to be used at every picture size.

[burfadel]

My observations of merange was kind of like littlepox's, it did show a very noticeable speed difference with a lower value without much impact on the file size. Mind you, it could settings based as well, and where other bottlenecks exist etc.

My observations were based on the following settings, which were based on the standard preset.
--tu-inter-depth 2
--b-intra
--rc-lookahead 60
--max-merge 5
--aq-mode 2
--nr-intra 400
--nr-inter 400
--bframes 5
--ref 5

The --tu-inter-depth 2 gave small gains with negligible performance loss, this was not the case with --tu-intra-depth 2. So, I used 2 for the tu-inter-depth, and the standard 1 for the tu-intra-depth. I used a rc-lookahead value of 60 (mistakenly thought it was 80 before this edit), because it seemed to provide some benefit over 20. I would have presumed the rc-lookahead should be at least a little higher than the minimum keyframe interval?...

The max-merge of 5 (maximum) was because again it showed some improvement with negligible performance loss, although this may not be the case at higher resolutions. Reference frames and b-frames are at 5 because that seems to be the ideal speed/file size tradeoff numbers for me. I noticed the number of consecutive b-frames in the different test clips were reasonable numbers up until 5, after which the percentages were very low (such as 1.5 percent), so 5 became my preferred setting. In reading the stats, I realise the first number is actually '0' consecutive b-frames, as the first b-frame isn't consecutive as it has nothing to be consecutive to. Therefore, there are six numbers when consecutive B-frames is set to 5 :) (just in case people aren't aware of that).

The last three settings I chose all affect SSIM, so using SSIM to determine whether these are any good doesn't really mean much. The aq-mode 2 is a little harder to quantify since it's purely a perceptive thing, I believe it is beneficial over 1. This has been improved upon in x264 recently with the addition of -aq-mode 3. This is the same as --aq-mode 2, but biases dark scenes. I would probably choose -aq-mode 3 if it was available!

The noise reduction settings are a real impact on SSIM, since they purposefully 'change' the picture. Having 400 set for both (for inter and intra) is because it seems to reduce the final file size a noticeable amount, and perceptively it doesn't affect the picture. Of course, that may be different for person to person. A figure higher than 400 gives diminishing file size benefits. Probably a key thing to take away from the noise reduction is whether you can actually get a better image at the same file size, since you can lower the CRF (the lower the CRF the better the quality) to make up for the file size difference!

I've dropped --weightb from my earlier decision (default is disabled anyway) as it turned out it wasn't beneficial.

So, that's why I've chosen the settings I've chosen, with good speed vs quality in mind.

[Motenai Yoda]

x265_1.6+64-335c728bbd62_x64_gcc4.9.2 (UPX-EXE) (http://www.mediafire.com/download/3br6idwnwvxxfcv/x265_1.6+64-335c728bbd62_x64_gcc4.9.2.zip)

[benwaggoner]

it doesn't matter if you don't have a 10 bit display. it is well know that encoding in 10 bit is more efficient and a common practice these days. even the nvidia 960 GTX can do ASIC 10 bit HEVC and of cause it can even public broadcast is 10 bit.
Do we actually know that HEVC is more efficient at 10-bit than 8-bit? We know H.264 and x265 are more efficient coding 8-bit content in 10-bit mode since the higher precision quantization yield smaller rounding errors and you wind up with fewer "1" values scattered in the lower right of the quant tables.

But I don't know if that's been demonstrated with HEVC in general. I know that x265 was less efficient in 10-bit than 8-bit mode a while back, although that gap has at least closed.

BTW. nearly all directx 10 GPUs can output 10 bit or more using DP/HDMI by using a directx fullscreen surface.
The tricky part is figuring out which players will actually DO that. The most reliable way I've found to get 10-bit output is to use the Adobe Creative Suite products out to a monitor with 10-bit DisplayPort support. However, the Adobe products require OpenGL to do 10-bit output, and with NVidia 10-bit OpenGL requires a Quadro GPU.

Does anyone have a good mechanism to get 10-bit HEVC playback to a 10-bit screen in all 10 bits?

[huhn]

Do we actually know that HEVC is more efficient at 10-bit than 8-bit? We know H.264 and x265 are more efficient coding 8-bit content in 10-bit mode since the higher precision quantization yield smaller rounding errors and you wind up with fewer "1" values scattered in the lower right of the quant tables.

But I don't know if that's been demonstrated with HEVC in general. I know that x265 was less efficient in 10-bit than 8-bit mode a while back, although that gap has at least closed.
this here is an old test which said clearly yes 10 bit is way more efficient:
http://forum.doom9.org/showpost.php?p=1691801&postcount=45

examples:
http://abload.de/img/70_5s_10drool.png
http://abload.de/img/70_5s_8c9ju6.png
http://abload.de/img/70_orgcmslk.png

The tricky part is figuring out which players will actually DO that. The most reliable way I've found to get 10-bit output is to use the Adobe Creative Suite products out to a monitor with 10-bit DisplayPort support. However, the Adobe products require OpenGL to do 10-bit output, and with NVidia 10-bit OpenGL requires a Quadro GPU.

Does anyone have a good mechanism to get 10-bit HEVC playback to a 10-bit screen in all 10 bits?
MPDN can send 8, 10 and 16 bit to the GPU driver. i don't have a screen with 10 bit so i can't make sure if it works.

http://forum.doom9.org/showthread.php?t=171120

and in the end we get float point data with a YCbCr source so we need to dither this data down anyway. so a 8 bit panel is not that bad to judge such things.

[sneaker_ger]

There's also this on 8 bit vs 10 bit:
http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=7417

How much this holds true for current x265 I cannot say.

[benwaggoner]

There's also this on 8 bit vs 10 bit:


http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=7417





How much this holds true for current x265 I cannot say.



I don't know how relevant a 10-bit PSNR is in this comparison. It'll catch lots of invisible differences, since only 25% of 8-bit values have a matching 10-bit value.

[LazyNcoder]

Not much related to what is going on here, but I did some test and here is the results:

x265 [info]: HEVC encoder version 1.5
x265 [info]: build info [Windows][GCC 4.9.0][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

--pmode 1 --pme 1 --threads 16 --frame-threads 16
average encoding speed: 8.823878 fps

--pmode 1 --frame-threads 16
average encoding speed: 7.477486 fps



x265 [info]: HEVC encoder version 1.6
x265 [info]: build info [Windows][GCC 4.9.0][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

--pmode 1 --pme 1 --frame-threads 16
average encoding speed: 10.062576 fps

--pmode 1 --frame-threads 16
average encoding speed: 10.709824 fps

Seems like --pme is slowing me down now in v1.6 :confused:

[benwaggoner]

Seems like --pme is slowing me down now in v1.6 :confused:


Totally expected for normal use cases. You need a high threads/rows ratio before --pme starts being helpful. I think I found an improvement doing 384x288 with 16 threads once, but it wasn't huge.

[Ajvar]

Not much related to what is going on here, but I did some test and here is the results:

x265 [info]: HEVC encoder version 1.5
x265 [info]: build info [Windows][GCC 4.9.0][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

--pmode 1 --pme 1 --threads 16 --frame-threads 16
average encoding speed: 8.823878 fps

--pmode 1 --frame-threads 16
average encoding speed: 7.477486 fps



x265 [info]: HEVC encoder version 1.6
x265 [info]: build info [Windows][GCC 4.9.0][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

--pmode 1 --pme 1 --frame-threads 16
average encoding speed: 10.062576 fps

--pmode 1 --frame-threads 16
average encoding speed: 10.709824 fps

Seems like --pme is slowing me down now in v1.6 :confused:
Why didn't you use --pools 16 in the 1.6 version?

[benwaggoner]

Why didn't you use --pools 16 in the 1.6 version?



For myself, I use pools to specify which socket to use, and use --pools "+,-" and --pools "-,+" for a dual-socket system.



Also, why the super-high frame-threads? That's also impacting performance, and is way above optimal for speed/perf.

[sneaker_ger]

He has two CPUs and probably does not want to use "--pools 16" because it would only allocate one pool if I understand correctly. Most interesting would be how fast default settings would be.

For myself, I use pools to specify which socket to use, and use --pools "+,-" and --pools "-,+" for a dual-socket system.
That's not how I understand the docs.

http://x265.readthedocs.org/en/latest/cli.html#cmdoption--pools

/edit:
Or do you actually want to use only a single socket at a time?

[BadFrame]

x265 1.6 has been released.

Looks like another great release.

I sure don't envy you guys, a lot of people seem to think x264 became as good as it is today in no time at all (memory sure is subjective), it took many many years (it's over ten years old if I recall correctly) for it to reach what is now the pinnacle of what h264 can offer, x265 is an infant project by comparison (what is it, two years?).

[kolak]

Yes, but x264 code is out there and can be 'applied' to x265. Still disappointed about x265 and grain/details retention.

Yes, it's better at very low bitrates, but if we think about 4K Blu-ray it may end up that using x264 may give better quality, which would be 'crazy ':)

[vivan]

and in the end we get float point data with a YCbCr source so we need to dither this data down anyway. so a 8 bit panel is not that bad to judge such things.Also 10 bit YCbCr holds only ~9 bit of valid RGB data (for TV range BT.709 only 172122707 values are valid (result in RGB in 0..1 range), log2 (values) / 3 = 9.12).
Also chroma is subsampled, 2x2 block gives 4 values (+2 bits of precision). But luma is not, so 2*2/3 = +4/3 bit of display precision.
So when you don't scale 8 bit display is enough to cover all unique 10-bit 4:2:0 values (they give unique result or something).

But once you add floating point conversions (that had to be performed), chroma scaling (and image scaling) and, most importantly, dithering - it stops to make any sense to compare video and display bitdepth.
Higher display bitdepth (refresh rate and resolution) gives less noise. E.g. 2160p 8-bit display should be comparable to 10-bit 1080p display.
Higher video bitdepth gives better gradients. People that know what they are doing (in contrary to the professionals that don't and get (http://i.imgur.com/rZV2Aod.png) payed (http://i.imgur.com/PkHiQaZ.png) for (http://i.imgur.com/Ksrb443.png) doing (http://i.imgur.com/2Xn8acd.png) this (http://i.imgur.com/InppoFB.png)) proved it long time ago and only now we're starting to get 10-bit HW decoders.

x265 is an infant project by comparison (what is it, two years?).Don't forget that they took all the x264 experience/codebase and also x264 name (for all the false (http://forum.doom9.org/showpost.php?p=1677487&postcount=635) advertising (https://x265.com/) they do to their commerical consumers).

[Motenai Yoda]

Also 10 bit YCbCr holds only ~9 bit of valid RGB data (for TV range BT.709 only 172122707 values are valid (result in RGB in 0..1 range), log2 (values) / 3 = 9.12).
Err, if I'm not wrong that "9.12" should be the minimum number of bits to display all those values, so it isn't "10 bit YCbCr holds only ~9 bit of valid RGB data" but "To holds all valid RGB data in YCbCr at least > 9.12 bits are needed" (w/o put into that should be added ~0.66 bit cos 16/235 restrictions).
Also I don't get the chroma downsample part (booth of them are 420, and bitdepth or reproducible values aren't related to chroma downscaling).

And yep a 10bit1080p and a 8bit2160p display can be comparable but only regarding how many colors can be archieved (10bit vs 8bit+dither), a 2160p display is better on many other aspects.
Finally those banded pics show only the fail of not to dither when converting to 8 bit.

I don't know how relevant a 10-bit PSNR is in this comparison. It'll catch lots of invisible differences, since only 25% of 8-bit values have a matching 10-bit value.
Imho psnr is too sensible to grain/noise and not optimal to valutate a dithered picture vs not dithered, they should at least dedither first (or use ssim).

[Nevilne]

professionals that don't and get (http://i.imgur.com/rZV2Aod.png) payed (http://i.imgur.com/PkHiQaZ.png) for (http://i.imgur.com/Ksrb443.png) doing (http://i.imgur.com/2Xn8acd.png) this (http://i.imgur.com/InppoFB.png)

Is that Crunchyroll stuff? lol.

[vivan]

Err, if I'm not wrong that "9.12" should be the minimum number of bits to display all those values, so it isn't "10 bit YCbCr holds only ~9 bit of valid RGB data" but "To holds all valid RGB data in YCbCr at least > 9.12 bits are needed" (w/o put into that should be added ~0.66 bit cos 16/235 restrictions).Well, yes, but since videos are supposed to be shown on RGB displays going off range is wasting bitrate...
I'm not sure were you got 0.66 bits, log2 (880 / 1024) = -0.22.
With fullrange 10-bit I got 259728971, which is around 9.32 bpp.

Also I don't get the chroma downsample part (booth of them are 420, and bitdepth or reproducible values aren't related to chroma downscaling).It's dithering (maybe even without it just bilinear upsampling will do something similar) and like 1080p @ 10 -> 2160p @ 8 analogy. You have 2x2 pixel block that have do display 1 sample. It could display (in a unique way) sample with 2 bit higher bitdepth.

Finally those banded pics show only the fail of not to dither when converting to 8 bit.They just show terrible production and encoding that professionals (crunchyroll) do. Guess what other professionals (funimation) do? They serve fullrange (http://i.imgur.com/u4wFb4p.png) videos tagged as limited range (http://i.imgur.com/dy4BIOn.png), which, of course, screws even their own players :rolleyes:
With proper encoding banding is less severe, but still quite noticeable. You can get rid of it only by adding noise, which inflates bitrate.

[MeteorRain]

Yes, but x264 code is out there and can be 'applied' to x265.
Can you demonstrate how to just "apply" that? And then we all can save years on developing x265.

:script:

[vivan]

Can you demonstrate how to just "apply" that? And then we all can save years on developing x265.

:script:While it's not "just", inventing and porting are completely different things. Psy, aq, etc. - even other H.264 encoders are terrible at them.

[MeteorRain]

While it's not "just", inventing and porting are completely different things. Psy, aq, etc. - even other H.264 encoders are terrible at them.

True. But that still takes time. So many commits on the repo everyday and I believe they will (eventually) port these to x265 when they are happy with the speed optimization.;)

[Ajvar]

I would be happy with opencl on Nvidia 6xx series and Ivy processor but that doesn't happen close time.

Anyone else is worried about where is Ma? His latest build is 1.6+3 and which is more important he misses oportunity with bench comparison of 1.6 vs 1.5 on AVX CPU. That is disturbing.

@x265, if you want to become real popular then create fancy benchmark for all geeks who have powerfull hardware which isn't nearly loaded by games. Introduce X265 BMARK. Fire around those letters.
Important rules:
- results must be consistent on same machine;
- database with online graphs where someone already has insane results (but possible to outperform on heavily OCed 6-core 4770K).
Not a joke. 4 minute test and at the end user watches played video which was encoded for that time (longer=better score) and at the beginning user can click button to play original video (at insane mbps, 30-60 fps, preferably PC game scenes in one with epic dragon teaser at the end and lighting X265 letters so users would want to get better score to see 2nd half which may be show only as score result.
And 2 modes: 360p at ultralow bitrate but still better than x264 comparison and 720p with good bitrate OR 240p and 480p.

[kolak]

Yes, but x264 code is out there and can be 'applied' to x265. Still disappointed about x265 and grain/details retention.

Yes, it's better at very low bitrates, but if we think about 4K Blu-ray it may end up that using x264 may give better quality, which would be 'crazy ':)

Not a programmer, but you can apply the same ideas or adjust them. Saves years of development- exactly. Looks like many ideas have been already adjusted and put into x256, but even so it's disappointing in some scenarios.

How do you explain this:

http://forum.doom9.org/showpost.php?p=1716059&postcount=159

other than disappointing?

[MeteorRain]

Not a programmer, but you can apply the same ideas or adjust them. Saves years of development- exactly. Looks like many ideas have been already adjusted and put into x256

No. That only saves you years of thinking and testing, not developing. Hugh differences are there between these two, especially on the code design. Adapting all the ideas takes time, bro.

[huhn]

How do you explain this:

http://forum.doom9.org/showpost.php?p=1716059&postcount=159

other than disappointing?
a bug? not yet good optimized?
the x265 decoder is simply not perfect yet

[kolak]

No. That only saves you years of thinking and testing, not developing. Hugh differences are there between these two, especially on the code design. Adapting all the ideas takes time, bro.

Yes, but at least half job is done, so it's easier than starting from scratch.
Even so x265 is very disappointing in preserving details and grain.

20mbit to have same details as 5mbit x264? Looks like room for improvements is huuuuge :)
H265 is designed to “make money“, not deliver good quality, but this is standard these days :)
4K Blu-ray will delivery relatively waaay worse video than current HD Blu-ray. At the moment it's not looking promising at all for those who want to watch movies at very good quality at home. If 4K BD standard would be released today I don't see a single h265 encoder which could deliver reference encodes- you would be way better with x264 :) This is not about x265 itself, but h265 standard overall.

[huhn]

it's not like all BD are created with x264. there is a high chance they are created with encoder not as powerful as x264 in the first place.

and now the next thing. yeah sneaker_ger found some serious issue with 1000 5000 and 20000 but even 20000 is low for a BD.
and as a reminder: http://forum.doom9.org/showpost.php?p=1715578&postcount=134

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

x265 doing pretty darn well for the time it exist and they have more than 3 month to fix this issue

[Sagittaire]

Yes, but at least half job is done, so it's easier than starting from scratch.
Even so x265 is very disappointing in preserving details and grain.

20mbit to have same details as 5mbit x264? Looks like room for improvements is huuuuge :)
H265 is designed to “make money“, not deliver good quality, but this is standard these days :)
4K Blu-ray will delivery relatively waaay worse video than current HD Blu-ray. At the moment it's not looking promising at all for those who want to watch movies at very good quality at home. If 4K BD standard would be released today I don't see a single h265 encoder which could deliver reference encodes- you would be way better with x264 :) This is not about x265 itself, but h265 standard overall.

Well it's completely false. I heard the same crap when the x264 started vs XviD (from Koepi for exemple). And today x264 outperform XviD and all the other MPEG4 ASP codec even for detail and noise. Kolak, your judgment is completely wrong because you can do with H265, stream really close to H264, in compliance term. H265 codec is an H264 codec with additional functionality. Detail and noise retention are purely an HVS problem approch and many H264 implemetation fails today with that.

[kolak]

Almost no A class BD titles are done with x264- it's mainly Cinemacraft HDe, which at BD bitrates outperforms x264- better bitrate distribution between frames and over the frame.

I'm going to have a nice material for x265- some Samsung 4K TVs showcase. Last time I've done it x265 lost against x264- I hope this time it will be x265. These will be 10bit x265 files encode from prestine sources.

[benwaggoner]

Err, if I'm not wrong that "9.12" should be the minimum number of bits to display all those values, so it isn't "10 bit YCbCr holds only ~9 bit of valid RGB data" but "To holds all valid RGB data in YCbCr at least > 9.12 bits are needed" (w/o put into that should be added ~0.66 bit cos 16/235 restrictions).
Also I don't get the chroma downsample part (booth of them are 420, and bitdepth or reproducible values aren't related to chroma downscaling).

And yep a 10bit1080p and a 8bit2160p display can be comparable but only regarding how many colors can be archieved (10bit vs 8bit+dither), a 2160p display is better on many other aspects.
Finally those banded pics show only the fail of not to dither when converting to 8

It's also dangerous to assume that the 8-bits of a display match the 8-bits of whatever gamma or PQ is curve is being used in the video. Because they aren't, not since the CRT era.



-Ben Waggoner (via TapaTalk)

[benwaggoner]

Not a programmer, but you can apply the same ideas or adjust them. Saves years of development- exactly. Looks like many ideas have been already adjusted and put into x256, but even so it's disappointing in some scenarios.



You've convinced me -you are not a programmer :).

Seriously, some algorithms match up well,smoke don't. X264 doesn't have any code for 16x16 and 32x32 blocks, let alone how to make good. Sure, you could say "just don't DO >8x8 blocks." But those are critical to get good efficiency at UHD frame sizes, which is a core scenario for x265, but wasn't something that x264 ever got much specific tuning for.

It's most important at this stage for x265 to be better than x264 at SOME important things than for it to be as good at everything. We still have x264 for the stuff x264 is exceptionally good at!



-Ben Waggoner (via TapaTalk)

[huhn]

It's also dangerous to assume that the 8-bits of a display match the 8-bits of whatever gamma or PQ is curve is being used in the video. Because they aren't, not since the CRT era.



-Ben Waggoner (via TapaTalk)


we have BT 1886 for this.

[vivan]

True. But that still takes time. So many commits on the repo everyday and I believe they will (eventually) port these to x265 when they are happy with the speed optimization.;)And don't forget who they are - they are not couple guys doing it in their free time, they're they are the company that works fulltime one it and getting payed.
How many commits there're so far? How many years it took x264 to get to that number of commits? That would be a good estimate.

Seriously, some algorithms match up well,smoke don't. X264 doesn't have any code for 16x16 and 32x32 blocks, let alone how to make good. Sure, you could say "just don't DO >8x8 blocks." But those are critical to get good efficiency at UHD frame sizes, which is a core scenario for x265, but wasn't something that x264 ever got much specific tuning for.Maybe that's why http://forum.doom9.org/showthread.php?p=1710496#post1710496 this happens? ;)

[MeteorRain]

Almost no A class BD titles are done with x264- it's mainly Cinemacraft HDe, which at BD bitrates outperform x264- better bitrate distribution between frames and over the frame.

At BD bitrate - Yes.
At Internet streaming bitrate - No.

[Ma]

Anyone else is worried about where is Ma? His latest build is 1.6+3 and which is more important he misses oportunity with bench comparison of 1.6 vs 1.5 on AVX CPU. That is disturbing.

I've watched the movie which I encoded with parameters "--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709" with 10-bit x265 ver. 1.5+365. Result line "encoded 207826 frames in 504048.14s (0.41 fps), 6272.50 kb/s".

Quality was surprisingly good -- source BD movie was high quality without grain. I'm so shocked that I found an older movie with little/medium grain, I've changed parameters to "--crf 17.5" (the rest without change) and now I encode with 10-bit x265 ver. 1.6+3. I want to check if x265 is already good quality codec or if there is only good source (without grain) effect.

My build procedure is time-consuming (profiling) so the new builds I will update Tuesdays and Fridays.

[benwaggoner]

Okay all, anyone who's made it to Page 106 of this thread is definitely enough a Compression Nerd to deserve and invite to the 15th Annual Ben Waggoner Compressionist's Party at NAB on April 14th. If you're going to be at the show and have time, sign up here:

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

I imagine HEVC and HDR are going to be the two biggest topics around the myriad tables.

[jlpsvk]

I've watched the movie which I encoded with parameters "--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709" with 10-bit x265 ver. 1.5+365. Result line "encoded 207826 frames in 504048.14s (0.41 fps), 6272.50 kb/s".

Quality was surprisingly good -- source BD movie was high quality without grain. I'm so shocked that I found an older movie with little/medium grain, I've changed parameters to "--crf 17.5" (the rest without change) and now I encode with 10-bit x265 ver. 1.6+3. I want to check if x265 is already good quality codec or if there is only good source (without grain) effect.

My build procedure is time-consuming (profiling) so the new builds I will update Tuesdays and Fridays.


Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

[kolak]

Well it's completely false. I heard the same crap when the x264 started vs XviD (from Koepi for exemple). And today x264 outperform XviD and all the other MPEG4 ASP codec even for detail and noise. Kolak, your judgment is completely wrong because you can do with H265, stream really close to H264, in compliance term. H265 codec is an H264 codec with additional functionality. Detail and noise retention are purely an HVS problem approch and many H264 implemetation fails today with that.

Sounds convincing. I will know more next week when I try it in real project on high quality footage. Last time x265 was no near x264 (50mbit UHD)- it was 6 months or so ago.

[BadFrame]

Yes, but x264 code is out there and can be 'applied' to x265. Still disappointed about x265 and grain/details retention.

Yes, it's better at very low bitrates, but if we think about 4K Blu-ray it may end up that using x264 may give better quality, which would be 'crazy ':)

Yes they have access to the x264 code, but that obviously it only gets them so far.

HEVC is aimed at being very efficient at very large resolutions, so I really doubt x264 would end up being better there, however I could certainly imagine x264 remaining very competitive at lower resolutions (720, 480).

It took x264 some ten years or so to show us the best h264 had to offer, given that x265 can build on x264 to some extent it shouldn't take ten years for it to show us the best HEVC can offer, but as we can see it will take more than two years.

[kolak]

I don't think it was ten years. Last years didn't bring anything special- just small tweaks. x264 was already very good few years ago, so maybe it was 6 years or so.
It will take whatever is needed, I don't think many other companies are any further in h265 implementation, so everyone has to wait. It's just 'bit funny' to read that it's 2x more efficient, as at the moment it's clearly not.
It should say- potentially/theoretically 2x more efficient. There may be implementation which will be 2x more efficient, but in the same time this may never happen. At the moment x265 started matching x264 for random sources and with low bitrate cases it's clearly better.
As I said- it's designed for broadcast to deliver 2x more channels at even relatively lower quality than current h264 transmission.

[Ajvar]

1. At some point it is even good how it clears noise. It's like aWarsharp filter but light.
2. Yeah, in many cases it overblurrs a lot, like bad focus.

For future: let's compare 2pass vs 2pass because crf looks different (your cap) and default profiles, no tune grain. It's marazm to compare something with case where better compression codeck is worse destination quality (crf 22) but same bitrate as less compression one but with higher destination quality (crf 18). That means something already.

[Boulder]

CRF is not constant quality. Using a 2-pass to match the same bitrate that some certain CRF encode produces is unnecessary at least with x264. The quality should be the same, that's what the x264 devs have confirmed a long time ago.

[Ma]

Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

I decide to compare your options with my two:
SR: --preset slower --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288
VS: --preset veryslow --rdoq-level 1 --psy-rd 0.5 --deblock -1 --keyint 288

Your | SR | VS | comment
--tu-intra-depth 2 | 2 | 3 | I leave as is in presets
--rdoq-level 1 | 1 | 1 | we both want more details
--bframes 5 | 8 | 8 | I leave as is in presets
--rc-lookahead 60 | 30 | 40 | I think this not affect quality but only efficiency
--min-keyint 23 | 23 | 23
--keyint 240 | 288 | 288 | not affect quality
--merange 25 | 57 | 57 | my gives better quality (theoretically)
--max-merge 5 | 3 | 4 | TODO: I will try this "--max-merge 5"
--pme | no | no | my gives better quality (theoretically)
--deblock -3:-3 | -1:-1 | -1:-1 | TODO: I will try "--deblock -2" (-3 is too extreme for me)
--psy-rd 0.5 | 0.4 | 0.5

So there are no big differences, I will try update my VS settings with "--max-merge 5" or/and "--deblock -2".

[BadFrame]

It's just 'bit funny' to read that it's 2x more efficient, as at the moment it's clearly not.
It should say- potentially/theoretically 2x more efficient. There may be implementation which will be 2x more efficient, but in the same time this may never happen

I've always taken any '2x more efficient' statements with a large grain of salt, as it most likely pertains to video clips tailored to the strengths of the HEVC algorithms.

As such I'm not expecting 'miracles' :)

[jlpsvk]

I decide to compare your options with my two:
SR: --preset slower --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288
VS: --preset veryslow --rdoq-level 1 --psy-rd 0.5 --deblock -1 --keyint 288

Your | SR | VS | comment
--tu-intra-depth 2 | 2 | 3 | I leave as is in presets
--rdoq-level 1 | 1 | 1 | we both want more details
--bframes 5 | 8 | 8 | I leave as is in presets
--rc-lookahead 60 | 30 | 40 | I think this not affect quality but only efficiency
--min-keyint 23 | 23 | 23
--keyint 240 | 288 | 288 | not affect quality
--merange 25 | 57 | 57 | my gives better quality (theoretically)
--max-merge 5 | 3 | 4 | TODO: I will try this "--max-merge 5"
--pme | no | no | my gives better quality (theoretically)
--deblock -3:-3 | -1:-1 | -1:-1 | TODO: I will try "--deblock -2" (-3 is too extreme for me)
--psy-rd 0.5 | 0.4 | 0.5

So there are no big differences, I will try update my VS settings with "--max-merge 5" or/and "--deblock -2".

Higher --merange is giving better efficiency (aka compression), not quality, I believe. And higher than 25 slows down encoding with no big bitrate difference. 25 shoud be OK for 1080p, 57 would be for UHD. Also try -3 deblock. Preserves sharpness and maybe details also better???

[divxmaster]

Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

I certainly agree with jlpsvk re crf 20, on 1080p sources anyway. Testing with Iron Man 3, frame by frame stacked comparison: (code added for newbies)

video1=FFVideoSource("d:\h265\x265\ironman3.m2ts",fps=23.976).crop(0,260,0,560)
video2=FFVideoSource("d:\h265\x265\ironman3.crf20.mp4",fps=23.976).crop(0,120,0,560)
StackVertical(video1,video2)

For this source anyway, the x265 and source bluray are indistinguishable. However my tests on 576p dvd are very different, extreme blur at even crf20. Crf10 loses no detail, must get around to
testing the interim from crf10 up to crf20 to see what it needs.

Cheers,
Divxmaster

(although this is my first post, I have been encoding a long, long time - anyone remember flaskmpeg, m4c and idm4c? :) )

[LigH]

Belated Happy Easter:

x265 1.6+85-e0523096bb21 (https://www.mediafire.com/download/8l565eqahaxs99b/x265_1.6+85-e0523096bb21.7z) (stable merge)
x265 1.6+117-095ed87526e5 (https://www.mediafire.com/download/hikaauhtfu6aa6a/x265_1.6+117-095ed87526e5.7z) (with "implementation of fine grained adaptive quantization")

Furthermore, some spring-cleaning (removing v1.3 archives).

[jlpsvk]

@LigH
What "implementation of fine grained adaptive quantization" means? :)

[LigH]

I am no developer ... but as described for 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

Means, you may allow x265 now to vary the quantization also for smaller CTUs than 64×64 pixels only. I can't tell you if that shall enhance detail retention or avoid banding, or has a different expected purpose, though.

[Ajvar]

CRF is not constant quality. Using a 2-pass to match the same bitrate that some certain CRF encode produces is unnecessary at least with x264. The quality should be the same, that's what the x264 devs have confirmed a long time ago.

"Should be" doesn't mean "is". If we compare something then it is better to do it with more science.
Just my 2c.

[Boulder]

"Should be" means "is" with x264. I don't recall any confirmation regarding the rate control of x265 but I am assuming that it is very close to what x264 does.

[LigH]

Apropos "should be": trying to add --qgsize 16 to the parameter set, I get only a syntax help page as error result, instead of an encode.

P.S.: My fault, insert another hyphen: --qg-size

[Ajvar]

"Should be" means "is" with x264. I don't recall any confirmation regarding the rate control of x265 but I am assuming that it is very close to what x264 does.

One man told very good phraze: "You see no difference between rumor/educated guess and a fact."
What you say is educated guess, no more. x265's rc lookahead is 20-30 on different presets while x264's is twice as that. Which may lead to something. This is my educated guess.
So unless you know something for the fact, why not to decrease specter of fluctuation's reasons?

[Boulder]

Believe me, I have also made a 2-pass encode compare between the codecs. The result is still the same, x265 doesn't retain the details like x264 does. Besides, I will not be doing multipass encodes for my own purposes so there's little use for me to test them.

[Boulder]

I also wouldn't say that the ratecontrol is the key to solving the issue. It might be if the problem appeared only in some frames but it is rather constant.

[Ajvar]

Believe me, I have also made a 2-pass encode compare between the codecs. The result is still the same, x265 doesn't retain the details like x264 does. Besides, I will not be doing multipass encodes for my own purposes so there's little use for me to test them.

Believe me, I don't thing than x265 retains as much details, I just think that it would be just right thing to do. You never encode 2 samples for comparison and 3-rd with CRF14 for example to use it as source comparison. You actually use source file instead, right?
Well, someone could tell you smth like "Believe me, CRF14 has no visible difference...". Source file is source file. Comparison should be as much identical settings too.

[Boulder]

Believe me, I don't thing than x265 retains as much details, I just think that it would be just right thing to do. You never encode 2 samples for comparison and 3-rd with CRF14 for example to use it as source comparison. You actually use source file instead, right?
Well, someone could tell you smth like "Believe me, CRF14 has no visible difference...". Source file is source file. Comparison should be as much identical settings too.Why would I compare to anything else than the source? My goal is to make my encodes look as close to the original as possible while consuming as little diskspace as possible. If you are looking for something else, even better because the devs can then have a different point of view of the performance of their codec.

The x265 devs had no problems with my samples with CRF encodes for both codecs, they just asked me to try without --tune grain which I of course did. I expect that they know their codecs behaviour very well and would have asked for a 2-pass if it made any real difference.

[Ajvar]

- Why would I compare to anything else than the source?
- The x265 devs had no problems with my samples with CRF encodes for both codecs, they just asked me to try without --tune grain which I of course did. I expect that they know their codecs behaviour very well and would have asked for a 2-pass if it made any real difference.

- That was analogy. Why you compare to something else than same settings?
- Devs would ask you if that would made major or meaningful difference in comparison to the difference/detail retain flaws between x264 and x265. I see that there are easily seen difference in picture anyway.
But tell me. When devs asked you to delete key --tune-grain, when you had to encode anyways once more time, why not to encode same 2-pass then?
And call me ignorant if you want but I doubt that devs know exact percentage or percentile of difference between CRF and 2pass. I mean they surely know how it should be but I doubt that they did additional all over videos type tests - they are too busy for that I believe.
P.S. Just to be clear because you look too defensive. I don't say you must reencode something. What I say is that 2pass vs 2pass comparison is the best by all ways than crf vs 2pass even if it has tiny effect. And that this should be meaningful in the future like for cases where you need to reencode anyways..

[Boulder]

Well, I really do not like being told how to test if I have many times stated that I test as if I was going to replace x264 by x265. Simple as that :)

I have one question regarding this issue and then I shall not argue it anymore:

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.

[benwaggoner]

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.
Because bits==bits but x264 CRF~x265 CRF. Testing with crf is comparing both rate control AND internal quality metrics at the same time.

[sneaker_ger]

You're assuming he did comparison at identical CRF which he didn't. He chose CRF values so bitrate matches.

[Boulder]

I'd like to hear what the devs say about the differences - is x265's CRF model built upon x264's? I would expect that they are not trying to reinvent the wheel. Using 2-pass to produce the same final bitrate as a CRF encode results in causes negligible quality differences in x264 according to Dark Shikari.

EDIT: just for the heck of it, I encoded an x265 clip in CRF mode with "--preset slow --rdoq-level 1 --qg-size 16 --merange 24 --rc-lookahead 125". The CRF required in x265 is almost the same as what x264 used (18.25 for x265, 18.5 for x264). I don't have any visual comparisons yet.

EDIT2: Heavy smoothing still visible :(

x264 : https://drive.google.com/open?id=0BzeF_1syecQwLWJnMjZ0VXhwVm8&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwUFgycndfTlRPUVU&authuser=0

[STaRGaZeR]

Can we get any info on the "aq: implementation of fine-grained adaptive quantization" patch? Does it improve anything?

[Motenai Yoda]

--gp-size 16 or not I get no difference at all for grain retention, but some improvements(?) between 16.0.64 and 16+133, only on non-keyframes(?)...

070 http://www.imagebam.com/image/018f88402334515
203 http://www.imagebam.com/image/24bf89402334654
329 http://www.imagebam.com/image/47177c402334836

+64 --crf 22.0
070 http://www.imagebam.com/image/e639cd402333258
203 http://www.imagebam.com/image/0a643b402333353
329 http://www.imagebam.com/image/041f5c402333496
+133 --crf 22.0
070 http://www.imagebam.com/image/11733f402333645
203 http://www.imagebam.com/image/527536402333736
329 http://www.imagebam.com/image/6af60b402333801
+133 --crf 22.0 --gp-size 16
070 http://www.imagebam.com/image/58f7ca402333879
203 http://www.imagebam.com/image/c01af1402333962
329 http://www.imagebam.com/image/499b9d402334043

[LigH]

This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...

[Ajvar]

Well, I really do not like being told how to test if I have many times stated that I test as if I was going to replace x264 by x265. Simple as that :)

I have one question regarding this issue and then I shall not argue it anymore:

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.

Because CRF-CRF is "comparing both rate control AND internal quality metrics " unless you do "chose CRF values so bitrate matches" where actually it can't match bit per bit so we come back here again: 2pass-2pass is the best by all means (no matter how small advantages) which I gave as feedback in general: not bringing as a wishlist workload for you personal but for general comparing methodologies:sly:
This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...

Sad. In pictures comparison above I liked 133 way more.

[MeteorRain]

Sad. In pictures comparison above I liked 133 way more.

Be patient. After they solve the problem it will come back.

[x265_Project]

This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...
We hope to have the improved AQ integrated this week.

[x265_Project]

Can we get any info on the "aq: implementation of fine-grained adaptive quantization" patch? Does it improve anything?
Sure. Adaptive Quantization allows x265 to change the quantization parameter (QP) on a block-by-block basis in each video frame. All blocks aren't equal - some contain very little visual detail, and some contain more detail. Without AQ, the QP value would be the same for every block in a frame. When you change the QP, you change 2 things; the lambda value - a constant that is used in the basic rdcost equation (which determines the best encoding method for the CU, weighing the bits used against the measured distortion); and the amount of quantization (reduction) of frequency components in the residual error after prediction. By raising the QP value for certain blocks, x265 can reduce the number of bits needed to encode that block with minimal impact to visual quality. By reducing the QP value for some blocks, x265 can reduce distortion (improve quality), with some additional cost in bits.

Until now, x265's adaptive quantization would change the quantization parameter on a CTU by CTU basis (64x64 pixel blocks, or whatever --ctu is set to... 32x32 pixel blocks for the fastest presets). The HEVC specifications allow us to adapt quantization with finer granularity - at the CU level (the sub-partitions within a CTU). There is a cost (in bits) to signaling a change in QP, and so our improved AQ must determine when the benefits outweigh the cost. But this improvement has the potential to further improve visual quality at any target bit rate.

[Motenai Yoda]

Also, if I'm not wrong, different CTU size has different frequency domain, so 64x64 get rid of low freq. (edges), 32x32 refine for mid freq. (detail) and 16x16 for hi freq. (noise/grain), but I'm not sure if, when there is/are 32x32 or 16x16 CTUs, freq. covered by small CTU will be skipped/ignored/zeroed in larger CTU (a sort of tri-band quantization) or maintained and just refined later by smaller CTU...

[x265_Project]

Also, if I'm not wrong, different CTU size has different frequency domain, so 64x64 get rid of low freq. (edges), 32x32 refine for mid freq. (detail) and 16x16 for hi freq. (noise/grain), but I'm not sure if, when there is/are 32x32 or 16x16 CTUs, freq. covered by small CTU will be skipped/ignored/zeroed in larger CTU (a sort of tri-band quantization) or maintained and just refined later by smaller CTU...

I think you meant to say CUs instead of CTUs. Blocks of pixels are encoded in a structure called a Coding Tree Unit (https://en.wikipedia.org/wiki/Coding_tree_unit), or CTU. As a CTU is analyzed in the motion compensated prediction phase, it is partitioned into one or more CUs. Prediction is encoded in PUs, residual error is encoded in TUs.

So, typically, x265 uses 64x64 CTUs, and these are partitioned into smaller CUs according to what produces the most efficient encode. I don't think that you can think of each CU size as having a particular spatial frequency domain.

Video quality mainly depends on the ability of the encoder to do accurate motion compensated prediction. If the video source is high quality, with a steady camera, low noise, and not too much motion + detail (confetti dropping, ripples on water, trees with millions of leaves blowing in the wind) in the scene, video encoders can work efficiently. If the source video has too much spatial detail which changes from frame to frame, motion compensated prediction doesn't produce a good predicted picture, and there will be a lot of residual error with a lot of spatial detail left to encode after prediction.

Residual error is first transformed (using discrete cosine transform, or DCT), and the strongest spatial frequencies are encoded in the TU. The less dominant frequencies are dropped in the quantization process. If the residual error is low enough, it won't be encoded at all (the TU is skipped with certain merge and skip modes).

Certainly there are differences in how larger CUs might look when the residual error is heavily quantized or skipped, versus smaller CUs. But the analysis process must choose wisely when partitioning the CTU, to only use larger CUs when it makes sense.

[Ajvar]

@x265_Project, I have a question about CRF in x265. With CRF value X --vbv-maxrate at some scenes may be overflow which brings to a very good picture at first and then very blocky/blurred picture next second at some scene. I saw that you just set vbv-buffer to a double of maxrate in x265 Upgrade but will 2pass CRF decrease maxrate overflows or CRF encodes just don't use stats information at all?
Thank you.

P.S. I deleted that video where was high bitrate scene so can't test it for now.

[x265_Project]

@x265_Project, I have a question about CRF in x265. With CRF value X --vbv-maxrate at some scenes may be overflow which brings to a very good picture at first and then very blocky/blurred picture next second at some scene. I saw that you just set vbv-buffer to a double of maxrate in x265 Upgrade but will 2pass CRF decrease maxrate overflows or CRF encodes just don't use stats information at all?
Thank you.

P.S. I deleted that video where was high bitrate scene so can't test it for now.
There's no such thing as 2 pass CRF (there is only 2 pass ABR).

CRF is a rate control mode that doesn't care about the bit rate... it only cares about the quality level. So, when you encounter complex content, the bit rate can soar. Some people use VBV with CRF (a combination known as capped VBR) to cap the bit rate at some reasonable maximum during periods of complex content. This is tricky, as you first have to have some idea of the average bit rate you will get from your CRF setting with your content, and then set the VBV maxrate at a level that is reasonably higher than the average bit rate you will get from your CRF value. Setting a reasonably large VBV bufsize just gives VBV more memory to do it's thing without difficult constraints. I think that 2x the maxrate is a good value to use.

[LigH]

A VBV controlled cap is not a certain limit for the bitrate, as it is related to a filling level and filling/freeing speed of a decoding buffer. It is possible that a bitrate limit is exceeded for a brief time, and bitrate may be reduced over a slightly longer time to compensate for that. Even a large lookahead may not avoid that certainly, I believe... but developers of the rate control will know that better.

[nevcairiel]

Bitrate is always defined over time, unless you go for extremely strict CBR where every frame has the exact same size. VBV just lets you configure the bitrate fluctuation over a defined period.

[LigH]

This period is probably related to the allowed GOP length, because decoding buffers need to store at least all surrounding referenced frames to decode each predicted frame in it. On DVD Video, it used to be at most half a second (with attempts to expand that); on Blu-ray, it may be up to one or even two seconds (with different specified constraints).

[benwaggoner]

This period is probably related to the allowed GOP length, because decoding buffers need to store at least all surrounding referenced frames to decode each predicted frame in it. On DVD Video, it used to be at most half a second (with attempts to expand that); on Blu-ray, it may be up to one or even two seconds (with different specified constraints).
These days the VBV period (VBV/maxrate) can be pretty different than GOP duration. 2 sec GOP 5 sec VBV and 5 sec GOP 1 sec VBV are both things I've seen recently.

All things being equal, it's good to have buffer duration>=GOP duration, so that a IDR frames's higher bitrate can be spread over the buffer. Otherwise you can get bit starvation at the start of each GOP.

[Atak_Snajpera]

We hope to have the improved AQ integrated this week.

That's a good news because x265 on default settings still blurs too much in dark areas.

x265 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/hQF1Ui.png

x264 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/m1JemQ.png

[x265_Project]

That's a good news because x265 on default settings still blurs too much in dark areas.

x265 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/hQF1Ui.png

x264 --2pass --bitrate 1024 --preset medium
http://i.cubeupload.com/m1JemQ.png
I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

[burfadel]

I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

Is the AQ modified from x264? If so, what about the recently added mode 3 added to x264?
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=d72a85b549acd981a8dae3dc5b71920ab2aeea4f

[Atak_Snajpera]

I'm curious for those that feel that x265 isn't allocating bits optimally across different scenes (blurring in areas you care about)... have you tried varying AQ strength, and have you tried using AQ mode 2? AQ mode 2 with higher AQ strength (2 to 3) might produce a better encode in this situation.

x265 --2pass --bitrate 1024 --aq-mode 2 --aq-strength 2
http://i.cubeupload.com/SQOWTh.png

[Ajvar]

There's no such thing as 2 pass CRF (there is only 2 pass ABR).

CRF is a rate control mode that doesn't care about the bit rate... it only cares about the quality level. So, when you encounter complex content, the bit rate can soar. Some people use VBV with CRF (a combination known as capped VBR) to cap the bit rate at some reasonable maximum during periods of complex content. This is tricky, as you first have to have some idea of the average bit rate you will get from your CRF setting with your content, and then set the VBV maxrate at a level that is reasonably higher than the average bit rate you will get from your CRF value. Setting a reasonably large VBV bufsize just gives VBV more memory to do it's thing without difficult constraints. I think that 2x the maxrate is a good value to use.

OK, got it, thanks.

[burfadel]

In addition to the new AQ mode I mentioned above in x264, there is this non-committed patch which I believe some people find useful for film grain retention:
http://komisar.gin.by/old/2538/p/x264_fgo_DS.2377.diff

I thought I mention those two since they are for issues people mentioned in x265, I'm sure they could be ported (or the principle ported) to x265 :).

How about scene fade, any issues there?
http://komisar.gin.by/old/2538/p/x264_fadecomp.2208.diff

[x265_Project]

The NAB show starts Monday. We have a private suite where we'll have some great demos of our latest capabilities including real-time 4K encoding, high quality offline encoding, and decoding on a variety of platforms including tablets. We look forward to discussing our product roadmap with all of our customers and partners, and learning more about their plans and requirements.

If you're going to the NAB show, and you'd like to meet up, email me (tom.vaughan at multicorewareinc dot com). The x265 team's meeting schedule is nearly packed from 8 am to 6 pm every day, but we have a couple of slots open on Tuesday and Wednesday. I'll also be at Ben's Compressionist's party Tuesday night, but it looks like I'll get there a bit late.

[Gravitator]

On this show come the guys from V-Nova (http://www.v-nova.com/en/press.html).
There and will be held fights PERSEUS vs HEVC :D

[burfadel]

I guess that's a 'no' to the AQ question I had earlier :D all good!

[x265_Project]

Is the AQ modified from x264? If so, what about the recently added mode 3 added to x264?
http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=d72a85b549acd981a8dae3dc5b71920ab2aeea4f

Yes, our dev team is looking at this.

[x265_Project]

In addition to the new AQ mode I mentioned above in x264, there is this non-committed patch which I believe some people find useful for film grain retention:
http://komisar.gin.by/old/2538/p/x264_fgo_DS.2377.diff

I thought I mention those two since they are for issues people mentioned in x265, I'm sure they could be ported (or the principle ported) to x265 :).

How about scene fade, any issues there?
http://komisar.gin.by/old/2538/p/x264_fadecomp.2208.diff
We're always open to reviewing contributions. We're going to be very busy this week, so don't expect fast or thorough responses to open questions. But I definitely look forward to learning more about these patches.

[burfadel]

I apologise for sounding a bit impatient :). Thanks for the work being done on x265!

[mandarinka]

Oh, it is a port of FGO to x265? That thing was a pure hack and probably not too efficient, so dunno if it makes sense to include it upstream, unless it gives really good results...
The fade compensate one was a bit less messy though, IIRC, that might be a usable thing.

[nandaku2]

I apologise for sounding a bit impatient :). Thanks for the work being done on x265!

Sorry for the delay in checking in fine grained AQ. We're looking into a hash error bug in a YUV422 test case, and will check it in as soon as this is resolved.

[zerowalker]

Read about the VBV thing not being what i thought it was, i use it as a cap as i was sure it was just "Birate up to this point".
This is with x264 though, here is my settings: preset=superfast crf=18 vbv-bufsize=40000

So this is actually bad?
I just wanted it to try to limit to around 40mbps in case of some super complex scene as normally it's around 20-35mbps.

(Off topic sorry).

[Motenai Yoda]

Read about the VBV thing not being what i thought it was, i use it as a cap as i was sure it was just "Birate up to this point".
This is with x264 though, here is my settings: preset=superfast crf=18 vbv-bufsize=40000

So this is actually bad?
I just wanted it to try to limit to around 40mbps in case of some super complex scene as normally it's around 20-35mbps.

(Off topic sorry).

I think u mean --vbv-maxrate
http://forum.doom9.org/showthread.php?p=1292411#post1292411

[zerowalker]

Oh, that make sense.
So maxrate is then, more of a constant that tells "This is the limit", not "we can only accept this much data cause of speed limits"?

EDIT: Okay doesn't seem to be the case either;P

[x265_Project]

Oh, that make sense.
So maxrate is then, more of a constant that tells "This is the limit", not "we can only accept this much data cause of speed limits"?

EDIT: Okay doesn't seem to be the case either;P
VBV models how a decoder works. You can think of it as a leaky bucket. The size of the bucket is the bufsize. VBV maxrate is the maximum rate that the bucket can be filled... the maximum rate that the decoder will be able to receive the HEVC bitstream (the channel bandwidth). If the decoder can only be "filled" with data at a limited speed, it limits the peaks and valleys that you can allow in the instantaneous bit rate (a moving average of a small # of frames), otherwise the bucket (buffer) will overflow or underflow.

See https://www.doom9.org/showthread.php?p=1690632

[zerowalker]

Complicated, get it kinda, Buffer tells it how much it can throw as long as it keeps the steady rate, so if it has been low, it can push high awhile to run ahead.
Though maxrate as you explain it makes it sound like a peak limit, which it's not if i get it correctly, hard stuff.

But i guess buffer/maxrate is the closest thing one can get to constrained crf?

Thanks

[LigH]

The bitrate constraining devices may be drives reading from source media, but also networks or broadcasts with a bandwidth limit. Limiting the (per-GOP or per-second) video bitrate to a hard threshold is neither as useful nor as necessary as keeping the predicted decoding buffer filling level in the valid range. The buffer dimensions are designed for some overhead. And even more interesting, high peaks are sometimes less an issue than longer lasting low bitrate scenes (which might fill a decoding buffer with more frames than a GOP has).

[Sleepysonic]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

Will my current processor ever be able to complete this conversion in even just twice realtime (As in, 44 minutes video done in 1.5 hours)?
Currently with these settings, it seems things are 13.8 x real-time. so a 44 minute video would take... almost 10.5 hours to convert... Even if I had 20% faster cores + double as many cores (8) it is still 5.5x realtime.

That means, in a magical world where more cores = more performance, I still wouldn't get realtime even with 40 cores.

[LigH]

Encoding performance will be improved further, especially for AVX2 capable CPUs. Still, the complexity of the HEVC encoding algorithm is a lot higher than the one of AVC, so if you are interested in realtime encoding, don't insist on "slower" presets...
__

x265 1.6+174-4cccf22b00ee (https://www.mediafire.com/download/fnkm1a9k21bcxob/x265_1.6+174-4cccf22b00ee.7z)

Supports a switch for the "Annex B" format internally, which may be interesting for builds supporting already multiplexed outputs. Raw HEVC video shall always be formatted according to Annex B, I was told.

Coming builds may require a decision to be either compatible to Vista without — or to Win7+ with support for NUMA thread pools. May my Win32 builds be XP compatible (and without much use for multi-socket encoding anyway), but my Win64 builds will then probably prefer Win7+ compatibility with NUMA support.

[MeteorRain]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

...

Since when can we do 2-pass slower 720p within 2x realtime?

In the 3rd year after x264 was released, the fastest processor we have is Core 2 Duo, or if you are an AMD fan, Athlon X2 7750. I doubt you can get that speed with latest x264 on these platforms, even on 480p.

== Edit ==

I did a quick encoding test on my desktop. I limited x264 on a single core to emulate an old CPU.
My 4770 has a passmark score of 2238 on single core, the Athlon 7750 has a passmark score of 1576 on all cores.
Encoding a 640x480 on x264 0.147.2538 with --preset slower --tune film --crf 21 gives me 16.5 fps in average.
You can imagine how fast it was in the year 2009.

[burfadel]

Can anyone tell me their predictions in what kind of encoding efficiency is possible in the near future? Excuse my ignorance.
Currently, in handbrake, I have a 2-pass "slower" 720p 711kbps conversion taking place on my stock i7 4.0ghz 4790k. It is saying roughly 1.5 hours to encode 6.5 minutes of video.
Is this encoding efficiency going to get a lot better soon, or is this what we will be working with for some time? Is turbo 1st pass in the works at least?

Will my current processor ever be able to complete this conversion in even just twice realtime (As in, 44 minutes video done in 1.5 hours)?
Currently with these settings, it seems things are 13.8 x real-time. so a 44 minute video would take... almost 10.5 hours to convert... Even if I had 20% faster cores + double as many cores (8) it is still 5.5x realtime.

That means, in a magical world where more cores = more performance, I still wouldn't get realtime even with 40 cores.

Unless you require a specific end file size, it might be better to use CRF. If encoding TV shows, by having a fixed end file size the quality of each episode will vary. This is because some episodes require more bitrate than others for the same quality.

Now, in terms of the presets, you need to play around with the settings and work out what works best for you. Start with a CRF of say, 22 and go from there (based on the final file size of a test encode).

For the options, many of them result in significantly more processing time required with little gain in quality.

Try the following settings on the normal preset, it's what I use:
--tu-inter-depth 2
--b-intra
--aq-mode 2
--nr-intra 400
--nr-inter 400
--subme 3
--max-merge 5
--bframes 6
--rc-lookahead 90
--ref 6

Try --me-range 24 or 25 for 720P stuff.


Note that --tu-inter-depth 2 gave benefits for me, but intra didn't. The --nr-intra/inter settings are for noise reduction. I tried to choose a value that works for me. The noise reduction it does is very light (hasn't really affected the encodes), but it improves encoding efficiency. You could always get rid of it, or try a value of 200 or 300 (400 is about the limit of where it is beneficial for encoding efficiency).

So, try those settings and see how you go :). I'm not saying they're right or right for every purpose etc, just that they work for me and provide the best performance/quality tradeoff. The quality loss and file size increase is extremely minimal over settings that make it many times slower.

[x265_Project]

Complicated, get it kinda, Buffer tells it how much it can throw as long as it keeps the steady rate, so if it has been low, it can push high awhile to run ahead.
Though maxrate as you explain it makes it sound like a peak limit, which it's not if i get it correctly, hard stuff.

But i guess buffer/maxrate is the closest thing one can get to constrained crf?

Thanks
You just have to think of how a decoder works in a real-world situation. Keep in mind...
- Hardware decoders have a fixed memory buffer size.
- A decoder may receive the video bitstream from a medium with a fixed, limited bandwidth (read from a storage medium, or receive through a network).
- The number of bits for each frame varies quite a bit, and if too many large frames are trying come to the decoder in sequence, they may not be able to fit through the channel in time.

[Atak_Snajpera]

devs what do you think about OpenCL 2.0 ? More usefull for x265 or not really?

[Ma]

I've made another speed test of 10-bit x265. There are new versions of GCC -- 5.0.1 and 6.0.0.

Builds: I've prepared 8 builds of 10-bit x265 -- GCC 4.9.2, 4.9.3, 5.0.1 and 6.0.0 each in 2 optimize variants -- O2 and O3. All builds with option "-march=corei7-avx". Source code version 1.6+185.

Test movie: http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

Platform: Windows 7 64-bit, i5 3450S.

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

Result:
492-O2 | 463.57s | 0.43 fps | 100.0%
492-O3 | 468.73s | 0.43 fps | 101.1%
493-O2 | 470.43s | 0.43 fps | 101.5%
493-O3 | 467.71s | 0.43 fps | 100.9%
501-O2 | 534.50s | 0.37 fps | 115.3%
501-O3 | 522.02s | 0.38 fps | 112.6%
600-O2 | 533.66s | 0.37 fps | 115.1%
600-O3 | 520.11s | 0.38 fps | 112.2%

Full result and builds: www.msystem.waw.pl/x265/test4.7z

GCC 6.0.0 is fractionally faster than 5.0.1.
-O3 optimize option is better than -O2 for GCC 6.0.0, 5.0.1 and 4.9.3 (this is new behavior of GCC 4.9.3)

So they don't improve GCC 5.0.1 but they destroy GCC 4.9.3 (with -O2 option). Sad...

[Motenai Yoda]

I've made another speed test of 10-bit x265. There are new versions of GCC -- 5.0.1 and 6.0.0.
Can u compare this too? I've simply made it with the build batch and last yasm (1.3.0.6.x).

http://bit.ly/1aQPqVy

@zerowalker u can alway set --vbv-bufsize to 500, but it give me some buffer underflow error, and don't go up to 12000k setted as maxrate, just a bit under 3000k..

[MeteorRain]

I even observed fractionally slower on pgo version compared to the regular one.

[Ma]

Can u compare this too? I've simply made it with the build batch and last yasm (1.3.0.6.x).

http://bit.ly/1aQPqVy

Your build is not working on my CPU -- you probably have AVX2 CPU and you made native build.

[LigH]

Just be careful with new GCC versions, wouldn't be the first time that overly aggressive optimization may lead to invalid binaries (e.g. removing loops which were detected to have no purpose, because their side effects were not recognized).

[Motenai Yoda]

Your build is not working on my CPU -- you probably have AVX2 CPU and you made native build.

Nop I have a Bloomfield one and made with build batch with vs2013 comunity mode "Relase" (was yet setted in cmake)

[Ajvar]

So they don't improve GCC 5.0.1 but they destroy GCC 4.9.3 (with -O2 option). Sad...

As long as your GCC 4.9.2 builds work for me I'm fine. But I guess GCC is like Windows - breaking old which worked fine and building new just because it's new.

[Kurtnoise]

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

why this kind of value for the keyint switch ?

[Ma]

why this kind of value for the keyint switch ?

288 for keyint when I test only 200 frames is quite strange. For normal encodings I use --keyint 288 for better compression (at given crf). 12 s * 24 fps = 288 (this test video is 50 fps, but normally I encode 23.976 fps sources).

[Ma]

Nop I have a Bloomfield one and made with build batch with vs2013 comunity mode "Relase" (was yet setted in cmake)

So it should work, but it doesn't. I see inside the .exe that it needs MSVCP120.dll and MSVCR120.dll -- but if I execute your build there is no error message. Strange...

It could be the reason because I have only 32-bit version of these dll. Could you compile this build with static linking?

[burfadel]

So it should work, but it doesn't. I see inside the .exe that it needs MSVCP120.dll and MSVCR120.dll -- but if I execute your build there is no error message. Strange...

It could be the reason because I have only 32-bit version of these dll. Could you compile this build with static linking?

Install this:
https://db.tt/pLDXUkxh

It removes existing Visual C++ runtimes and installs the latest versions available (some of these are even later than the ones you specifically download from Microsoft as standalones).

It includes the 32-bit and 64-bit runtimes for 2005, 2008, 2010, 2012, and 2015, as well as some key older runtimes.

[Motenai Yoda]

luckily I still have dd45 archive https://1fichier.com/?9qcyeprobh
Note that isn't compiled with test option coz it give me a warning.
CMake Warning (dev) at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/CMakeASMInformation.cmake:35 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.

Quoted variables like "ASM" will no longer be dereferenced when the policy
is set to NEW. Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
cmake/CMakeASM_YASMInformation.cmake:63 (include)
test/CMakeLists.txt:1 (enable_language)
This warning is for project developers. Use -Wno-dev to suppress it.

[NikosD]

Install this:
https://db.tt/pLDXUkxh

It removes existing Visual C++ runtimes and installs the latest versions available (some of these are even later than the ones you specifically download from Microsoft as standalones).

It includes the 32-bit and 64-bit runtimes for 2005, 2008, 2010, 2012, and 2015, as well as some key older runtimes.

I think the script is about Office Updates, not Visual C++ runtimes.

[Ma]

luckily I still have dd45 archive https://1fichier.com/?9qcyeprobh

Now I can test. I take only 1.6+200 version. I add my generic GCC 4.9.3 builds (with -O2 option) and generic profiled (in 10 minutes) GCC 4.9.2.

Test movie: http://media.xiph.org/video/derf/y4m...oy_1080p50.y4m

Platform: Windows 7 64-bit, i5 3450S.

Options: --preset slower --crf 22 --rdoq-level 1 --psy-rd 0.5 --deblock -2 --keyint 288 --seek 300

Result:
10b-492-P | 464.76s | 0.43 fps | 100.0%
10b-493-O2| 465.50s | 0.43 fps | 100.2%
10b-msvc18| 467.52s | 0.43 fps | 100.6%
------------------------------------------------
8b-492-P | 393.19s | 0.51 fps | 100.0%
8b-493-O2| 393.52s | 0.51 fps | 100.1%
8b-msvc18| 395.38s | 0.51 fps | 100.6%

Full result and builds: www.msystem.waw.pl/x265/test5.7z

All builds are pretty equal.

[Ma]

As long as your GCC 4.9.2 builds work for me I'm fine. But I guess GCC is like Windows - breaking old which worked fine and building new just because it's new.

I've made stupid test -- I've compiled x265 with profile procedure but without movies -- x265 runs, displays
x265 [error]: unable to open input file
and exits. This build was much slower than normal (without profiling). So it looks like bad profiled build is worse than not profiled.

Last build I profiled with settings:
./x265.exe --preset slower --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 1920x800-hob.y4m -o NUL ; ./x265.exe --preset veryslow --crf 17 --rdoq-level 1 --psy-rd 0.5 --deblock -2 1920x800-ret.y4m -o NUL ; ./x265.exe --preset slow --crf 22 --ssim --psnr --pme 720p50_parkrun_ter.y4m -o NUL ; ./x265.exe --preset placebo --bitrate 12000 --rdoq-level 1 --psy-rd 0.4 --deblock -1 -f 150 1920x800-hob.y4m -o NUL ;

Do you use any option that is missing in my profile procedure?

[Ajvar]

build was much slower than normal (without profiling). So it looks like bad profiled build is worse than not profiled.
Do you use any option that is missing in my profile procedure?
Not a big surprise for any kind of optimizations. I encode like this but last time I encoded was since 1.6+3 or so, latest downloaded is +174 though.
x265 --preset slower --crf 22.7 --psy-rd 0.5 --psy-rdoq 1 --deblock=-1:-1 --pmode --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 5 --bframe-bias 1 --vbv-maxrate 8000 --vbv-bufsize 16000

[burfadel]

I think the script is about Office Updates, not Visual C++ runtimes.

Oops, wrong link :D.

Here's the correct one:
https://db.tt/9ZYc08hk

[littlepox]

To x265 team:

Currently, I'm sort of disappointed by the grain retention of x265. After hundreds of tests, we conclude that for grainy sources, we'd better use x264 --tune film --qcomp 0.7 if we are trying to encode in middle~high quality. We hope to see improvements soon.

However, for less grainy sources, e.g., anime, we do find that x265 is very capable of providing extremely high quality with low bit-rate. It can easily beat x264 with quality up to x264_crf=16 level.

Our tests focus on 4 paramters: crf, qcomp, rd+rdoq, and aq. Experiences from x264 tell us that these parameters can alter RC behaviors a lot and should be adjusted according to the source-type and quality-expectation; Meanwhile, you don't need to sacrifice the encoding time like using slower ME options.

When you start from a set of parameters and you wish to increase the bit-rate for better quality, one choice is to lower crf. However, increasing qcomp, rd+rdoq or aq can have the similar effect. So which choice is the best given the source and quality-level? That's what is to be tested.

Our tests showed such a combination best suit 1080p anime encoding in middle-high quality:

--qcomp 0.78 (lower crf, higher qcomp. recommend to use values in 0.75~0.8)
--rd 5 --psy-rd 1.0 --psy-rdoq 10.0 --rdoq-level 1
--aq-strength 1.0 (lower crf, higher aq. recommend to use values in 0.8~1.1)
--deblock -2:-2
--rd-penalty 2 --no-sao --no-strong-intra-smoothing (These are parameters we believe to have negative effects on middle-high bit-rate)
--me_range 25 --no-rect --no-amp (These are parameters we believe to be wasting the time under 1080p with almost 0 gain in quality)

We believe this may be a good draft for --tune animation


Important tips from the tests:

1. We use 10-bit x265.
2. We compare the quality with our eyes, NOT psnr/ssim. Parameters favoring psnr/ssim give you nothing but heavily blurred images; we believe that's why currently x265 is poor with grain retention.
3. We think that currently the rc scheme of x265 is not optimized for lower crf values like x265_crf=17. It may do a good job for default x265_crf=28, but certainly there are people wish to set much lower crf. We can have access to qcomp/psy/aq, but there must be dozens of other varible/constants we cannot tweak, and they are the bottleneck under high bit-rate. We hope the team can identify them and come up with some solutions, for example, give us more options to tweak and tell us their behaviors.


Here are some pairs of comparison (right click on the image and open it in a new tab to see the full-size one)
Source_________________________10 bit HEVC encode

https://nmgspw.bn1301.livefilestore.com/y2plKC6Yx6G-AtkCwHdjSPDewBfHCGvkpjQuGknFvthHsJYMsKrrRXoXnDTrX-lUvnTNadQ4CnDIpR8jg40RllYnw16l_WheXBCGbhseBiODpOSi5-eQk2t4V_UEsjAeRxUnBlIrLOlnBM0M9TYwSTGDA/2116s.png (https://nmgspw.bn1301.livefilestore.com/y2pgyhXjttleHnFyfxmmOMqY42x4nsSgwvwRUjdm-R3nQhtXvsM0I0focsGIs3TEza-GqEoDKAjdQgIjie2qQ3uocAQ39xVRYLeud8k_JGHoVQTH-QDVZe4Hxsz9nJqz9IWJKMjRq5DtDG6kul93fSEWw/2116.png) https://nmgspw.bn1301.livefilestore.com/y2plKC6Yx6G-AtkCwHdjSPDewBfHCGvkpjQuGknFvthHsJYMsKrrRXoXnDTrX-lUvnTNadQ4CnDIpR8jg40RllYnw16l_WheXBCGbhseBiODpOSi5-eQk2t4V_UEsjAeRxUnBlIrLOlnBM0M9TYwSTGDA/2116s.png (https://nmgspw.bn1301.livefilestore.com/y2p6_MxGR-Ox9iPzeHfT-h1MUmcqihtlh6h4jjQz8GX3bvfR6Ttl0Bmom01bjhtJE__kxWt9bKVdwBUSYYXGS0ssh_-9cWQlPe_gxfvgBgBt3v_mruEwot12SXiL92FltBcTD2GvRlUJWrvBYqUrlBKgA/2116v.png)
https://nmgspw.bn1301.livefilestore.com/y2peC7pqlRZEYORYJnkxzCP88CCYSI1l5BufVUkN4nEMi3cK6GGtxg5LBxWnQx1NsvUtSxDZLCN709RyVlvv5DYQsJ-unxLYtI5ZHMa7pJaIvGoNrpcODs_a3LRMc6wf-T6YwpvfPr5sNTyxk0TXdMzZA/3092s.png (https://nmgspw.bn1301.livefilestore.com/y2pdb4rIDpmaoKdWvH6TOel8orSAAr327WeXTQKjTYg0J8mqDV74V_kHQ6EGFdr9n20UT3H5aUTZAl9u_cr7N2kKm9A73DnhiN4R7hShab9RXaqkQHzwYippUUh-DVBU48lQQCMdURVp4OSl9L68sJhJg/3092.png) https://nmgspw.bn1301.livefilestore.com/y2peC7pqlRZEYORYJnkxzCP88CCYSI1l5BufVUkN4nEMi3cK6GGtxg5LBxWnQx1NsvUtSxDZLCN709RyVlvv5DYQsJ-unxLYtI5ZHMa7pJaIvGoNrpcODs_a3LRMc6wf-T6YwpvfPr5sNTyxk0TXdMzZA/3092s.png (https://nmgspw.bn1301.livefilestore.com/y2pdqhWC18fdn9r8aYYaMorkCrh266Kz0ZqyNRyzKuESrvvzgOCYW8wb0FQ7akA_lmA_v4CXzTpOqtYxJnaaFeePz-ySumMyFSLexxW97lRve80BSxQGrXz3OC6W-Ul6-GzO3nAJxAAtGSQHfXkVVFWqg/3092v.png)
https://nmgspw.bn1301.livefilestore.com/y2pUwJFsWQ5W1JioN1acx2AoSsy9vfNGzlKFHI43Ydr3H1RGvqdwffJo89J7swp0EHnElL8cAfpuMXsOcVf8JJY-PvOWQad4D1snTAmRuwMBvMO8oW3mpkRRnVul-6kB_9dXY1Btpb6ndL1rBL7khRZLw/5436s.png (https://nmgspw.bn1301.livefilestore.com/y2p3dmhvNeZz0GUnZpawmNwsZdofPSeu18D9-HXqjO1pQ6okN8TU-BZRUUuHweHhScgiLKSa-LIPtmXxrjHSf_RSmp9bex6uoZrMaeWrE_Uh_R_B2X0Nua_r0aNh1UjpimtzxKi-j9_3GVz0jgGQ4_lvQ/5436.png) https://nmgspw.bn1301.livefilestore.com/y2pUwJFsWQ5W1JioN1acx2AoSsy9vfNGzlKFHI43Ydr3H1RGvqdwffJo89J7swp0EHnElL8cAfpuMXsOcVf8JJY-PvOWQad4D1snTAmRuwMBvMO8oW3mpkRRnVul-6kB_9dXY1Btpb6ndL1rBL7khRZLw/5436s.png (https://nmgspw.bn1301.livefilestore.com/y2p_8Fh8-q8fBTUWvwB1dK6SQCqhZ29gkhpcTiFptY-S2tbZrzb63vbB3p6UfPW7FEKi9CHEb4FdgTw8pLuo1tPt-54WNDa5A6e7Rfe_SDswl8925Sy8cCOs19g7FRIQT82xchuEK4vf81POwMW8cIDig/5436v.png)
https://nmgspw.bn1301.livefilestore.com/y2pl-tV1QJv4uKt6QLKFQ0wtBGLAT0yl13GY1LNr_QnjwHRkCYr2ckEXTzcIO1MWz2e0I9UopEpGivHqcIrYB1yNPQVTabpclPnksAaAK8QATPy3WO2ZK6DmXjtFuk771VQxMnIKvglLRrm-LwL8KCsCg/7454s.png (https://nmgspw.bn1301.livefilestore.com/y2pHzTd4ok4rdGYBAOfqKzlE7X8wOBzIt4XD3zsoEwhq54g33COaTbgMscJvM7LbNbZgOPZnMOqjzL5iubgAQtgiXK85mL4XZbuGopffSkH2lQRMphz2Uf9jHTC-OuC_2Q23Olp92kFFRWXxhyv7_t_gg/7454.png) https://nmgspw.bn1301.livefilestore.com/y2pl-tV1QJv4uKt6QLKFQ0wtBGLAT0yl13GY1LNr_QnjwHRkCYr2ckEXTzcIO1MWz2e0I9UopEpGivHqcIrYB1yNPQVTabpclPnksAaAK8QATPy3WO2ZK6DmXjtFuk771VQxMnIKvglLRrm-LwL8KCsCg/7454s.png (https://nmgspw.bn1301.livefilestore.com/y2pQGRZ4yxOmInAd8jlM6BKdJjT1yclHxKNotGts1csBSGU6p38zy_KmhRgnlZtH8oQRSwxc76-9yopjpyh9K7zaXWif5Mcrvgx_DSbwE7LxJxzjzZwPHalIiT-CybzGoxo0RVq4OhPtzA_nBNOZPzQoQ/7454v.png)
https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pvEy7c8rSooPbJf14Ev12QmNJtrqBIRigUJgFn9_9hiQEVHpRpDBaYa2zRXilj5le6Vs8UfQuc8TLFgMGlnX2y8f8rc6I1yfWvZBDAaZa8L0m_ZBfHLSw7NFrFtFTsR592GPdvIhwYSYANNR5bmSYqQ/10806.png) https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pB3kclUn0Oia767B8rpbK7VYn95n_GUH_YDsquRd4LygpXmsfKKpBiPZa3Tqaw0TeK0B-4sTg7kE8YxUvf6OWq2Xli2Py7lrMLAnWGkBPaOGv0t1W1yxAmm6po5j2qhItjXQfGn2EZat9RBEkwjHwCA/10806v.png)
https://nmgspw.bn1301.livefilestore.com/y2pLj7iJIdMaZKWB-O5IaycJnSOZbWO0cv5C2V90tVqvO02TR0dOEImxPgPplYGxjwYyAviicaWrTMfajKaZTY1dBDjnuDpZ5C3eIRwdHaQxu2cJJq6dRA-kIc3YBezAFtIvignF0vFoB8xJI8bhbfFKg/13214s.png (https://nmgspw.bn1301.livefilestore.com/y2prHNMpF-sy4Ie-3eOLlXF1doCq6qVheFIDnSu-j03tM96ofWTE3OEufJoDB639-k8EY3nVCO0r77HAehafe53YuRuNz2KasPq4C5SbdWPOA0Bdfe6H71gMJLskYnVYnbfhveBz-DAFUdIYBAcYRJZUg/13214.png) https://nmgspw.bn1301.livefilestore.com/y2pLj7iJIdMaZKWB-O5IaycJnSOZbWO0cv5C2V90tVqvO02TR0dOEImxPgPplYGxjwYyAviicaWrTMfajKaZTY1dBDjnuDpZ5C3eIRwdHaQxu2cJJq6dRA-kIc3YBezAFtIvignF0vFoB8xJI8bhbfFKg/13214s.png (https://nmgspw.bn1301.livefilestore.com/y2pweddQr7lLZQsUIV0ce5U4kMMV0r218FLi49L3fPWXQznBeezdX0S25fzWwnxC_i1fn37W8XcHbvQhylkm-cJviArVWTxMz_9xOyRKAkx5YOx7tuSJXQWER2q1a3XoR66O92uQZvITA-sOGG3xRYLBg/13214v.png)
https://nmgspw.bn1301.livefilestore.com/y2pWfsn2eOjYu0bCKqAIaEdBcD92zeO9EeJ3uEXLDuAxwBiWJYN9zetnjhs4oMaR8ytY-c0Sgy_h0gXvYRVdmrZZMlUAsaehQ_FQI_3AhDeL-SOVbBd3z31BwIMmkgycasj5DZ3sXz3ypGLj4epJktkcA/15525s.png (https://nmgspw.bn1301.livefilestore.com/y2peCKj65zWibV-R01-J1H9ucqC14DW0LnnkfLLVVVQIdhrte_OGzJ8bpKkcS9U9jPFpypCEdKrx8HxaxSgCuiRRvJbsa0EFSdHakyjhDuUKkS7UoaodhuAfn1R0pJExCekPYCW5FARKiL6nCEYIE9Ppw/15525.png) https://nmgspw.bn1301.livefilestore.com/y2pWfsn2eOjYu0bCKqAIaEdBcD92zeO9EeJ3uEXLDuAxwBiWJYN9zetnjhs4oMaR8ytY-c0Sgy_h0gXvYRVdmrZZMlUAsaehQ_FQI_3AhDeL-SOVbBd3z31BwIMmkgycasj5DZ3sXz3ypGLj4epJktkcA/15525s.png (https://nmgspw.bn1301.livefilestore.com/y2p0a5Ile0o9I_mX9QPukBCGfx78eg3cuZGud3Otb8Md3rBrwMBpFdvSpilZVFuKV63zxdE2V8DNCEqCH_HC8O3iK3krmJV7pkHqNhgwsiVurINJG7ZrJwEylj-ljbZUvcMoLsHOgk9pDoi6l4Xh1BCtA/15525v.png)
https://nmgspw.bn1301.livefilestore.com/y2pHo9clAptcdfAYvlFv6uJoiIh9uh-zc0S_RxFfDuTqGkerF0cHb_jzA_es8dFlYNUOU5xRNm85CRkh7pFp_rmGQRfp25DJdhISpxRGAGG4wpVnYegTY8MaUfXls3wl6iHSRAzQpYLGLpYYSNK_25qMQ/23207s.png (https://nmgspw.bn1301.livefilestore.com/y2pVihdXOST2Up-Bp0f__j71TYTQZUEGabmJpa9M9WxrF9NpMByx2nlMi3MlrdKiUnPqlFcCGZkUCtjNcxHNKeo-O5vYjNua-s-X_N89CnWPADHHkB0aVT-5NnOLK-akbeqxcr4zV5DyiUGfDzFuYXFog/23207.png) https://nmgspw.bn1301.livefilestore.com/y2pHo9clAptcdfAYvlFv6uJoiIh9uh-zc0S_RxFfDuTqGkerF0cHb_jzA_es8dFlYNUOU5xRNm85CRkh7pFp_rmGQRfp25DJdhISpxRGAGG4wpVnYegTY8MaUfXls3wl6iHSRAzQpYLGLpYYSNK_25qMQ/23207s.png (https://nmgspw.bn1301.livefilestore.com/y2pDqgDAp3oNg913uWqpcRCFuzsX6W6-5eU212ZxfaywZDvf6fkyptn8NfKCbWowvyU_uLkBt_wKzJF63LfNgXzO1yB1WUePQBr9PcZmvGKPECNGqYI8FYMdxUKSI8W9KIm1fsX4QEgtmHjb2v7ba0o_A/23207v.png)
https://nmgspw.bn1301.livefilestore.com/y2pn3SRa50k8mN_BtAA_lc4xbP_2YOE1yBo4RrrFQo7DM16hlDj7m7Xpe0kDFAQu28g3RNaxXThCNAFDtM_1oS3McQKN_GRz1HsCLGZOuP-_WzuMNUprSTJYdq88DU_Zsnm6b34rh8TeDAr08WOrXPw1w/23370s.png (https://nmgspw.bn1301.livefilestore.com/y2p3Z3ZQfRSIibK1vVD7-wdnQsDWg5pTKq8OSPsr3VV2CzsHNl43RmeaTQ9A5D10zB0mZJH30jtb5FPI4Ha_r5tu_hZ-2yBE7ClnTsQCd5U-yYuvG2W3afhSl1mJ1u-IPtl0hHPAg4APsTVl0tONSY3bw/23370.png) https://nmgspw.bn1301.livefilestore.com/y2pn3SRa50k8mN_BtAA_lc4xbP_2YOE1yBo4RrrFQo7DM16hlDj7m7Xpe0kDFAQu28g3RNaxXThCNAFDtM_1oS3McQKN_GRz1HsCLGZOuP-_WzuMNUprSTJYdq88DU_Zsnm6b34rh8TeDAr08WOrXPw1w/23370s.png (https://nmgspw.bn1301.livefilestore.com/y2pyqYrIaPdi3QXRBsTkBGYdzke_qio8bXr4pMTQnUEiHe7BpWexJhN-YlZ2I2lcVMcwlwlU2EPme-rB9cGDvtNm0Gefs7nlsSPaAtkeiIRjJDAVlCsYZWrwS3PcX8fAfpFIQQKPyUX_7LbneQBhjP2HA/23370v.png)
https://nmgspw.bn1301.livefilestore.com/y2p2UaZcOuG5K2FSDmAL0OZFeiEDTKc3nR2-JCPiSp0RL6PK3xfMiBoZ1AH5BV0pRX_2tZtmNDSxr0S6MrwyRvKQCRmh96fH-PytLpFSa8jVwABiL9BFEM7jO4tOwm0cWBogATdLE9j-vpOASyb1yzjdg/30177s.png (https://nmgspw.bn1301.livefilestore.com/y2pBDrt8Jacl1hlhDoZL4-JvC5AScLBUlGNlpNOqleS1ads5VLDOdhRzDhgmjlBsdw8l30N6BvTCI0Ckiw0JXhB4HdH5JYB4BblfGfcLGUJNc6u_THzdvns5jYbMFVtUw9XcpWvXtiDODwAbUD0jkjdog/30177.png) https://nmgspw.bn1301.livefilestore.com/y2p2UaZcOuG5K2FSDmAL0OZFeiEDTKc3nR2-JCPiSp0RL6PK3xfMiBoZ1AH5BV0pRX_2tZtmNDSxr0S6MrwyRvKQCRmh96fH-PytLpFSa8jVwABiL9BFEM7jO4tOwm0cWBogATdLE9j-vpOASyb1yzjdg/30177s.png (https://nmgspw.bn1301.livefilestore.com/y2ptrnysgDPzuoTAV_K0U2sS1RFctAb3qWjy4_MypYDM32IeXo4S3yHaKyNd1u6u4Hm04vEIuyHYXLR4k2vg7Iqky-Oa5qukvvMWDi-Zyz4BvSjM64PxwivvZ2SGtVceFd_NHo4T6ypxu8QPIr-vU1J5A/30177v.png)

parameters used for this project: --preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2

[Motenai Yoda]

I think merange 25 is too low for 1080p, with negible gain, and bframes over 5 don't worth it
also rdoq-level for my test 2 give better results than 1 for anime content for the same bitrate (test on crf range 20~25)
at mid-crf (17~23) I'd use a bit less qcomp (.7/.75) aq (.8/.85) and deblock (-1,-1 / -1,0)
and even in your screen there is still a very little bit of detail loss

but those are almost no grain new anime, I'd like to see what u get with old fashioned heavy grained anime too.

ps psnr will be high sensitive to grain retention (at high quality) also most of your settings will increase ssim a lot.

[littlepox]

I think merange 25 is too low for 1080p, with negible gain, and bframes over 5 don't worth it
also rdoq-level for my test 2 give better results than 1 for anime content for the same bitrate (test on crf range 20~25)
at mid-crf (17~23) I'd use a bit less qcomp (.7/.75) aq (.8/.85) and deblock (-1,-1 / -1,0)
and even in your screen there is still a very little bit of detail loss

but those are almost no grain new anime, I'd like to see what u get with old fashioned heavy grained anime too.

ps psnr will be high sensitive to grain retention (at high quality) also most of your settings will increase ssim a lot.

Thanks for the reply.

For me, I've been testing with crf=15~19, that's why I set the parameters more aggressively.

I'd review your recommendations for --bframes and --me_range; would you explain how your tests support your idea? I mean have you tested them and compared the quality/statistics?

For this anime, I performed some slight de-noise on non-edge areas to reduce the bit-rate; so the clean background is expected ONLY on non-edge areas.

I've made the comparison with x264-10bit preset=veryslow crf=16 mbtree=1 qcomp=0.8 aq=3:0.8, They are almost at the same quality; over dozens of screenshot pairs, I cannot conclude which one is definitely better than the other, but the HEVC ver reduces 20% size of the AVC ver, claiming its victory(1.2GB vs 1.5GB). Using x264-10bit crf=17.0 qcomp=0.75 gives similar file-size to HEVC, but the quality is considerably worse.

I've also made some other encodes like SAO II, shirobako, Saenai Heroine no Sodatekata, ...... All of them are "almost no grain new anime", and HEVC can do better than the 10bit-AVC's ver. However, on grainy sources, I'm afraid we should stick on with x264, unless you are a grain-hater and you perform de-grain before encoding.

[RBX]

I have no idea if this works according to resolution, but I encode only 720p videos, and bframes 9 works well for anime, 5 for film content, and 0-3 for videos recorded with cell phone.

[mandarinka]

https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pvEy7c8rSooPbJf14Ev12QmNJtrqBIRigUJgFn9_9hiQEVHpRpDBaYa2zRXilj5le6Vs8UfQuc8TLFgMGlnX2y8f8rc6I1yfWvZBDAaZa8L0m_ZBfHLSw7NFrFtFTsR592GPdvIhwYSYANNR5bmSYqQ/10806.png) https://nmgspw.bn1301.livefilestore.com/y2p0d4ryu2JbNe59pYXJz15En3H6AGNin3eEzGFuVOuJt8ZTB955dWyXEbjXHvE5bWN6dd3wXbTlIT9YkHkWKmEpCRNbK2JEcLIiVoEqQTYM3bwCbZuw6eumOxEedPlUzTnTjta9phY5vwu-PmS0z-eFQ/10806s.png (https://nmgspw.bn1301.livefilestore.com/y2pB3kclUn0Oia767B8rpbK7VYn95n_GUH_YDsquRd4LygpXmsfKKpBiPZa3Tqaw0TeK0B-4sTg7kE8YxUvf6OWq2Xli2Py7lrMLAnWGkBPaOGv0t1W1yxAmm6po5j2qhItjXQfGn2EZat9RBEkwjHwCA/10806v.png)

You have some weird large block-boundary discontinuities in this frame - around the girl, it's fairly visible if you switch back and forth. Did you use the dump/load analysis data option when doing these tests? I've seen similar trouble with that feature.

[Motenai Yoda]

I get some test with well known test clips 720p, with x264, show no gain over merange 24, 1080p with 32 get a little gain specially on park_run and park_joy (tracking shots), also x265 should aim for 4k.
With x265 park_joy 1080p50 --crf 18 I get those results
merange 24 - 2.91fps, 51765.78kbps, psnr 35.228, ssim 12.801
merange 57 - 3.02fps??, 51685.29kbps, psnr 35.227, ssim 12.801

For this anime, I performed some slight de-noise on non-edge areas to reduce the bit-rate; so the clean background is expected ONLY on non-edge areas.
Yep on non-edge areas there is a bit of loss, source's screenshot are yet denoised? I also notice an artefact near chest on #5 (edit preceded by mandarinka)

unless you are a grain-hater and you perform de-grain before encoding
Sometimes I have to remove (did u see Urusei Yatsura?), sometimes I have to add..

I hope they port aq3 and aq4, or something like triaq...

[littlepox]

You have some weird large block-boundary discontinuities in this frame - around the girl, it's fairly visible if you switch back and forth. Did you use the dump/load analysis data option when doing these tests? I've seen similar trouble with that feature.

Oops, I forgot to mention something important, it is about the defects in psy that I'd like to inform the x265 team:

large psy values can cause this to happen. In high-motion scenes, you can easily find blocks with most of the picture static and only a very small portion, like the background, changing in motion. These blocks are likely to be coded skipped, with the residual unhandled. That's why I actually set the psy values lower than recommended, but still it may happen, as appeared on those screenshots selected randomly.

However, such artifacts can only be found in high-motion scenes; it may not affect normal watching a lot, if you don't watch it frame by frame.

There is no way to completely avoid this unless you disable psy——That would be a disaster since psy is the primary weapon to fight blurring. using lower crf and lower psy generally reduces the possibility. You can find similar problems in x264, but far less serious; it only happens @ very low bit-rate and insanely high psy values.

[littlepox]

merange 24 - 2.91fps, 51765.78kbps, psnr 35.228, ssim 12.801
merange 57 - 3.02fps??, 51685.29kbps, psnr 35.227, ssim 12.801


Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.


Yep on non-edge areas there is a bit of loss, source's screenshot are yet denoised?

The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.


I also notice an artefact near chest on #5 (edit preceded by mandarinka)


see my reply above



Sometimes I have to remove (did u see Urusei Yatsura?), sometimes I have to add..

I hope they port aq3 and aq4, or something like triaq...

Yep. Pre-processing should be considered on individual basis, and generally I would say, the more grain you wish to keep, the less recommended you use x265.

I'm also looking forward to some improvements. I hope I'd use x265 to encode some movies, concerts @ near-transparent level, but it really disappointed me to show its incompetence after hundreds of tests.

[Lyris]

The NAB show starts Monday. We have a private suite where we'll have some great demos of our latest capabilities including real-time 4K encoding, high quality offline encoding, and decoding on a variety of platforms including tablets. We look forward to discussing our product roadmap with all of our customers and partners, and learning more about their plans and requirements.

If you're going to the NAB show, and you'd like to meet up, email me (tom.vaughan at multicorewareinc dot com). The x265 team's meeting schedule is nearly packed from 8 am to 6 pm every day, but we have a couple of slots open on Tuesday and Wednesday. I'll also be at Ben's Compressionist's party Tuesday night, but it looks like I'll get there a bit late.

Aaack! If I'd known about either of those events I'd have loved to have stopped by. Next year?

[LigH]

x265 1.6+239-5c3443546ccc (https://www.mediafire.com/download/dvqgap641qfbq2h/x265_1.6+239-5c3443546ccc.7z)

News: Support for SMPTE ST 2086 (HDR / Wide Gamut display metadata) and piping reconstructed video to a Y4M viewer.

[RBX]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

[benwaggoner]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.


I would expect that lookahead would be particularly helpful with anime, as you'll get cu-tree, the equivalent of x264's mbtree. MBtree was a HUGE win for anime when it came out, as it was able to figure out what parts of a frame were reused in future frames, and make sure that bits went to making them high quality back in the IDR they first apperared.

Even if the size varies some, you should visually verify you're getting the same visual quality.

If long lookahead is actually harmful, you should file an issue with a repro over at the x265 bitbucket.


-Ben Waggoner (via TapaTalk)

[Motenai Yoda]

Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.

Indeed I was testing with me hex and subme 2, not me star and subme 5.


The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.
Yep but may seem like a sneaky behavior lead to reference screenshots from non denoised source vs denoised encode ones, especially when you're complaining about x265's grain retention. ;)

[foxyshadis]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

CRF comparisons are only meaningful when you don't change anything else. If you do, you have to adjust CRF to get the same file size and look at the visual quality, unless you're capable of judging visual quality vs file size. Sorry, there are no shortcuts to actually watching.

If you aren't willing to watch and compare, there's not much choice but to accept the results. My gut feeling is that the larger size is balanced out by better quality, but I don't know that for sure.

[benwaggoner]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size

[x265_Project]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size
Me too... but I think it still needs fine tuning. In my initial tests I see lots of things that I like (with respect to visual quality), and some things that I'm less sure of. More testing and tuning is needed before fine-grained AQ can be incorporated into our default settings with confidence. Feedback on combinations of AQ mode, AQ strength and QG Size that seem to work best would be welcomed from the x265 community.

[divxmaster]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster

[x265_Project]

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster
The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

[divxmaster]

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH :) can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

[MeteorRain]

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH :) can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

If you don't mind, you can give my build a shoot.

[divxmaster]

If you don't mind, you can give my build a shoot.

@MeteorRain, thanks will give it a try

While waiting for the fine grained AQ patch, Ive been doing some testing in the other direction, which
is creating x265 for mobile devices, seeing how low a bitrate can be used, but still with good quality.
Note this is for mobile devices, screen sizes I have are 4-10.1 inch.

Using params (thanks @burfadel):
--crf 28 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --pmode --deblock -1:-1

The resultant bit rates can only be described as incredible (all 10 bit x265):

sg1 s03e06 720x480 ntsc Bitrate 116kbps! *tivtc and qtgmc via 64bit vapoursynth
sg1 s03e07 720x480 ntsc Bitrate 241kbps
sg1 s03e08 720x480 ntsc Bitrate 173kbps
Irobot DVD 712x440 pal Bitrate 233kbps
k9 Pi DVD 712x552 pal Bitrate 162kbps

Quality is great on small screen sizes, and more importantly file size is miniscule, which is needed
for current microsd card sizes. These bitrates would mean all 10 seasons of sg1 would fit in
12-15gb!.

Cheers,
Divxmaster

[divxmaster]

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.


I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

[LoRd_MuldeR]

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

As always: If you want to compare different settings, then you have to ensure that the files come out at the same size. If you visually compare files of different size, your comparison will be biased! For example, if one of the files comes out larger, but also looks better, what do you learn? Did the particular setting that you were testing with this file actually improve something? Or does the file just look better because it ended up using more bits? Well, you just don't know!

Note that you can always improve quality, simply by increasing the bitrate - or vice versa. No need to change any settings (except the target bitrate) for that! The whole point about testing different settings is to figure out whether a particular setting improves quality at the same bitrate (same file size). Or, equivalently, whether it can retain the same quality at a lower bitrate (smaller file size). But the latter is more difficult to test, which is why we compare files of identical size.

[foxyshadis]

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

[x265_Project]

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

Yes, we are still working on fine-grained AQ, and we are working to see if we can improve all AQ modes. QG-size is still experimental.

[divxmaster]

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

@foxyshadis & @x265_project,
ah, ok, thanks, that explains what is going on. Well let the testing begin. fine grained aq shows promise already for my low bitrate encodes detailed a few posts up. Visual comparison of specific 'hard to encode' areas, that I noted when fine tuning the params, look visually the same using qgsize32, but @ 3% smaller size.

Edit: looking at the samples on a bigger screen, the qgsize32 is actually better. Some obvious banding in one area under qg64 is gone under qg32. nice.

Cheers,
Divxmaster

[stax76]

avs reading support would be great for AviSynth+ 64-Bit users and tool makers.

[shinchiro]

For me QG-size 32 looks better more safer in most of scene (in anime, 720p). But for complex detail like this (http://prntscr.com/6y84ox), QG-size 16 looks more better

What is interesting, increasing me-range to 100-200 does not slowing encoding (in a certain case, it can speed up encode) :)

[aegisofrime]

Hi, I have a question about the future of x265...

I think we can agree that video encoding can be described by 3 parameters: Speed, quality and size.

An increase in one parameter requires a decrease in one or 2 of the other parameters.

My question is, will x265 do better than x264 in the above ratio in the future?

For example, assuming that quality and file size stays the same, will encoding speed increase in x265 over x264? Or will x265 always be slower than x264?

Hopefully I'm making sense, and sorry if this has been asked before!

[burfadel]

As far as size vs quality is concerned, x265 will be ahead of x264 just by the nature of h.265 vs h.264. However, the encoding efficiency largely depends on the quality of the source. When you re-encode something, you are also re-encoding the 'defects' introduced by the original compression, which lowers the encoding efficiency of the subsequent encoding.

x265 is getting a lot of AVX2 work it seems, so that will benefit Haswell+/Zen+ processors. Additionally, there are new instruction sets for 2016/2017 etc that may be beneficial for encoding. So, x265 may greatly excel upon x264 in terms of speed vs quality vs size. This is of course, assuming x264 doesn't get the same instruction treatment. Additionally, there is the possibility of efficient APU/IGP utilisation in the future, seeing as Intel are working on better incorporating their graphics, and AMD are likely, for consumers, to have APU's even in the 'enthusiast' range for the Zen CPU's. Now that DirectX 12 is upon us, this is actually advantageous as proper use of DirectX 12 will allow graphics processing to be distributed to the APU/IGP and discrete card accordingly. Furthermore, AMD are rumoured to further on this with even better combination of performance between their APU's and discrete cards in the future. This is relevant as if all consumer CPU's in the future also include graphics capability (and complete unification as has been discussed with HSA etc), it would potentially benefit encoding. Currently encoding hasn't benefited too much from this integration, but the integration discussed for the future it should do.

So, for the same level of development, x265 is likely to always surpass x264 in the future, but this largely depends on the future development of x264 and the instruction features utilised.

[stax76]

The poll made it clear where things are right now, next year might be x265's breakthrough, there might as well be another encoder or another codec, only time can tell.

[shinchiro]

Will x265 have something like MBtree in future?

[mandarinka]

Will x265 have something like MBtree in future?

It is already there and is on by default. Because HEVC calls its blocks CUs, it is called CUtree.

[Ajvar]

OpenCL is very expected. Nowadays Medium preset is 7-8 times faster than slower and that's why additional power would be very useful.

[divxmaster]

For me QG-size 32 looks better more safer in most of scene (in anime, 720p). But for complex detail like this (http://prntscr.com/6y84ox), QG-size 16 looks more better

What is interesting, increasing me-range to 100-200 does not slowing encoding (in a certain case, it can speed up encode) :)

Must be a strange quirk of anime, - If I change from default merange of 57 to 100, the fps goes from 12fps to 8.5fps (4770k@3.9)

Cheers,
Divxmaster

[MeteorRain]

avs reading support would be great for AviSynth+ 64-Bit users and tool makers.

Suggest using avs4x26x

[stax76]

Great, why working with AviSynth+ 64-Bit and direct avs support if you can continue with AviSynth 32-Bit and piping. :(

[x265_Project]

Hi, I have a question about the future of x265...

I think we can agree that video encoding can be described by 3 parameters: Speed, quality and size.

An increase in one parameter requires a decrease in one or 2 of the other parameters.

My question is, will x265 do better than x264 in the above ratio in the future?

For example, assuming that quality and file size stays the same, will encoding speed increase in x265 over x264? Or will x265 always be slower than x264?

Hopefully I'm making sense, and sorry if this has been asked before!
Video encoders can be characterized the tradeoff between 2 qualities: compression efficiency, and computational complexity.

Compression efficiency = visual quality at the desired average bit rate

Computational Complexity = the compute power required to run the encoder at a desired speed + setting on a target platform.

Once you pick a target encoding platform and setting, you could say the 2 important qualities of an encoder are compression efficiency and speed.

H.265 encoders use a more efficient coding standard, but the increased encoding efficiency is achieved only by increasing the complexity (increasing the required compute power). So, it's reasonable to expect x265 to be significantly more efficient than x264, using similar settings (a given preset, for example).

Today, x265 --preset medium runs faster on many systems than x264 --preset veryslow, and the encoding efficiency of x265 in this scenario is significantly better. Is this a valid comparison? For some, maybe. Others may be using x264 with a faster preset, and on their hardware x265 is not yet practical.

Any advanced instruction sets that x265 takes advantage of can be used to accelerate x264 (although there are many differences in the functions found in x264 vs x265).

[foxyshadis]

Great, why working with AviSynth+ 64-Bit and direct avs support if you can continue with AviSynth 32-Bit and piping. :(

What's stopping you from piping Avs+ 64-bit? Why is piping such a problem?

[stax76]

Why is piping such a problem?

The question should be: Why is avs such a problem?

[nandaku2]

@foxyshadis & @x265_project,
ah, ok, thanks, that explains what is going on. Well let the testing begin. fine grained aq shows promise already for my low bitrate encodes detailed a few posts up. Visual comparison of specific 'hard to encode' areas, that I noted when fine tuning the params, look visually the same using qgsize32, but @ 3% smaller size.

Edit: looking at the samples on a bigger screen, the qgsize32 is actually better. Some obvious banding in one area under qg64 is gone under qg32. nice.

Cheers,
Divxmaster

Thanks for all the interest in fine grained AQ. A few points.

1. Yes, the fine grained AQ patches change outputs even when qg-size is set to default. This is because I have now added rate-distortion optimization to deltaQP bits. Every time QP is changed within a frame (AQ/CUTree/VBV is enabled), deltaQP bits need to be encoded. This was not being accounted for earlier in the RD-lambda equation. With fine grained AQ, deltaQP bits need to be absolutely accounted for, else we could end up shooting ourselves in the foot, where too many bits are being used up by deltaQP, negating any improvements from efficient bit redistribution.

2. Because of deltaQP bits, the efficacy of qg-size varies heavily on video content. If you had a lot of skip blocks and low residual in the remaining blocks, changing qg-size may not yield much, there are few bits to redistribute, and deltaQP may hike up the final bitcount as well. However, high motion with lots of residual blocks will generally show improvements with qg-size. Our testing has shown qg-size 32 is pretty much consistently better than the default 64.

3. We're working on an optimization where we avoid changing QP (based naively on AQ calculations alone), instead weight QP changes based on residual energy and/or magnitude difference in QP. This should reduce cases of the first kind in point 2.

[nandaku2]

@littlepox

Thank you for the very detailed and informative writeup. We're overdue with a tune anime setting. And we're also reviewing x265 visual quality at very high bitrates - I believe this is very similar to the issue you've reported at low crf. There is also an open issue on the issue tracker that rdoq-level 1 does bad things to grainy videos.

[qyot27]

The proposed LAVF input patch is *almost* able to support AviSynth (if you add *.avs to the allowed extensions list), which would make it cleaner than porting x264's AVS input module. I was able to get a simple Version() script to encode, but if I tried loading real video through FFMS2, it would hang. I'm guessing it's because loading plugins is tripping it up somehow (or it's a Linux-only quirk specific to AvxSynth; I haven't got my cross-compile environment set up yet to test with Windows builds).

Otherwise, just using FFmpeg itself with libx265 linked in works too.

[stax76]

For me this would be never used bloat, StaxRip is currently a +70 MB package including two LAVF powered source filters.

[LigH]

x265 1.6+298-4a7176bab742 (https://www.mediafire.com/download/z3r9ly5cz5ax5a6/x265_1.6+298-4a7176bab742.7z)

New published parameter:

--qpstep <integer> The maximum single adjustment in QP allowed to rate control. Default 4

[Kurtnoise]

The question should be: Why is avs such a problem?
what do you mean ? There is no pb for me...

[MeteorRain]

For me this would be never used bloat, StaxRip is currently a +70 MB package including two LAVF powered source filters.

Have you tried put *.avs into LAVF allowed extension list and give it a shoot?
I've never tried that, but having AVS support might be a good idea.

[LigH]

As far as I remember, AviSynth scripts can be loaded with two different main APIs: Either via the "very compatible" (and almost obsolete) AviFile interface, or via the native AviSynth interface. Does LAVF implement the latter? If LAVF uses a fallback to load unsupported formats in AVIs via Video for Windows, and AviSynth scripts just along with it, it may rather be the former.

[nevcairiel]

LAVF was changed some time ago to use the native AviSynth API.

[stax76]

I'm probably the only one still using ancient AviFile API. :cool:

[Kurtnoise]

Hi Yuuki,

https://bitbucket.org/msg7086/x265-yuuki

Just some cosmetic mod, and (buggy?) l-smash / haali mkv muxer patch after heavy hacking on the core.
It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?

[RBX]

CRF comparisons are only meaningful when you don't change anything else. If you do, you have to adjust CRF to get the same file size and look at the visual quality, unless you're capable of judging visual quality vs file size. Sorry, there are no shortcuts to actually watching.

If you aren't willing to watch and compare, there's not much choice but to accept the results. My gut feeling is that the larger size is balanced out by better quality, but I don't know that for sure.
I did another comparison with the latest build (lookahead 20 vs 72). 72 took less time, and produced larger size. Most of the screeshots I took were identical, but some with Lookahead 72 were larger and contained visual artefacts. I was using AQ mode 2 for these, and switching to mode 1 removed atrefacts in those particular frames but 72 still produced a bit larger size.


Also, edges get distorted in the encodes. Is there a known reason for this, or should I keep experimenting with the settings?

P.S. I use x265 16bpp.

[qyot27]

It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?
I'm the one that mentioned that it kinda-sorta works, there wasn't anything to suggest that the builds as they are now were set up that way.



1) Configure FFmpeg with --enable-avisynth (a stripped-down build* that also disables the encoders and muxers will cut down on space, but is optional). Build.
2) Adjust the allowed extensions list in the qcloned repo's source/input/input.cpp #ifdef ENABLE_LAVF block to include *.avs. Adjust source/CMakeLists.txt by adding all the non-avcodec/avformat/avutil libs needed by the FFmpeg build to the linker list since the patch's ENABLE_LAVF option uses APPEND PLATFORM_LIBS rather than building the linker list by querying libavformat's, et al., pkg-config files. Build.
...
3) Possibly watch it explode if you try to load video through a source plugin, but see it work fine for Version(). Although like I mentioned before, the hanging with real video sources could be a quirk of the LAVF input source patch interacting specifically with dlopen and thus it may not happen on Windows.

*for example (albeit for 32-bit, and cross-compiled):
./configure \
--prefix=$HOME/win32_build \
--cross-prefix=i686-w64-mingw32- \
--enable-gpl \
--enable-version3 \
--disable-w32threads \
--enable-avresample \
--disable-encoders \
--disable-muxers \
--disable-doc \
--disable-debug \
--disable-devices \
--disable-avdevice \
--disable-filters \
--disable-avfilter \
--enable-avisynth \
--extra-cflags='-DPTW32_STATIC_LIB' \
--target-os=mingw32 \
--arch=x86

[ndkamal]

Which CLI I must use for -qg --size, I tested this one and I don't see any difference in visual quality :

x265 test.y4m --presets Slow --qg -size 32 test.hevc

I use x265 v1.6 298.

[LigH]

You are not expected to see any difference in every case. They may even be subtle in academic cases. No panic.

[ndkamal]

If I use the x265 Nic Mod V2, the fine grained adaptive quantization works well and the picture is near from what we can see in x264, but when I use --qg -size 32, I don't see any differences, below two pictures, the first with x265 v1.6 298 --qg -size 32 and the second with x265 Nic Mod V2.


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

x265 Test.y4m --preset slow --qg -size 32 Test.hevc --bitrate 2000



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

x265.exe Test.y4m -o Test.hevc --preset nic --bitrate 2000

[MeteorRain]

Adjust source/CMakeLists.txt by adding all the non-avcodec/avformat/avutil libs needed by the FFmpeg build to the linker list since the patch's ENABLE_LAVF option uses APPEND PLATFORM_LIBS rather than building the linker list by querying libavformat's, et al., pkg-config files.

I'm no expert on CMake. Would you mind share something about how to query that instead of using append platform_libs? I was quite worrying about this method but I don't have much idea how to solve it.

Patch welcomed on CMakeLists.txt:thanks:

[divxmaster]

If I use the x265 Nic Mod V2, the fine grained adaptive quantization works well and the picture is near from what we can see in x264, but when I use --qg -size 32, I don't see any differences, below two pictures, the first with x265 v1.6 298 --qg -size 32 and the second with x265 Nic Mod V2.


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

x265 Test.y4m --preset slow --qg -size 32 Test.hevc --bitrate 2000



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

x265.exe Test.y4m -o Test.hevc --preset nic --bitrate 2000


As Ligh mentioned, you wont see visual difference in every case. Are the output file sizes different? Every test I have done, qgsize32 is smaller. Also, are you using '--qg -size 32'?? I should be '--qg-size 32' No space before -size, although it should report an error with the wrong parameter.
I see you have preset slow in one screenshot and preset nic in the other? Are you using the same version of x265 for both tests? I think the best way to test it is to use the exact same parameters, but vary only --qg-size 32/64.

Cheers,
Divxmaster

[qyot27]

I don't have much experience with writing/modifying CMake systems either (I've been meaning to), but I did find this:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Piggybacking_on_pkg-config

And the example directly below that seems to make use of it via pkg_check_modules. Whether it needs special handling to deal with a pkg-config --static situation I don't know.



EDIT: And a cursory Google search brings up FindFFmpeg.cmake modules others have already written, like this one which seems to be relatively complete (it's missing AVFilter and SWResample/AVResample):
http://www.morethantechnical.com/2013/08/23/finding-ffmpeg-with-cmake/

[MeteorRain]

I don't have much experience with writing/modifying CMake systems either (I've been meaning to), but I did find this:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Piggybacking_on_pkg-config


https://gist.github.com/msg7086/b949e7af71b238527b73

But I'm still not quite sure if I'm doing this correctly. On MSYS2 I have to specify -DCMAKE_PREFIX_PATH="//mingw64" to force a relative path to find the .pc files.

Please share your ideas :thanks:

[MeteorRain]

Hi Yuuki,

It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?

This is what I'm using for release.

./configure \
--disable-parser=opus \
--disable-decoder=opus,libopus \
--disable-encoders --disable-muxers \
--disable-devices --disable-avdevice \
--disable-hwaccels \
--disable-swresample --disable-swscale \
--disable-ffplay --disable-ffserver \
--disable-network --disable-bzlib --disable-lzma --disable-iconv --disable-zlib --disable-xlib \
--enable-gpl \
--arch=x86_64 --target-os=mingw32 --prefix=/mingw64


To me, 64bit avisynth lacks quite a lot filters, and thus for now I'd rather stay with 32bit avs. VapourSynth might be a good replacement, let's see.

[ndkamal]

Thanks for jour answer, I made an another test with x265 v16 without --qg-size 32, and the result is the same. The size of the files are not the same, the video with --qg-size is smaller.

[Kurtnoise]

This is what I'm using for release.

Thanks to you and qyot27. Finally, that's succeeded :

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p
Framerate : 24/1
Timebase : 1/24
Duration : 0:00:41
lavf [info]: 1598x1826 fps 24000/1000 i420p8 frames 0 - 1000 of 1001
raw [info]: output file: C:\temp\out.avs.h265
x265 [info]: HEVC encoder version 1.6+321-13290abce29209be
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(29 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 15 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 0
x265 [info]: Rate Control : CRF-28.0
x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao

x265 [info]: frame I: 5, Avg QP:14.84 kb/s: 23377.82
x265 [info]: frame P: 196, Avg QP:20.30 kb/s: 50.53
x265 [info]: frame B: 800, Avg QP:22.19 kb/s: 42.16
x265 [info]: global : 1001, Avg QP:21.78 kb/s: 160.36
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.5% 0.0% 0.0% 0.0% 99.5%

encoded 1001 frames in 142.79s (7.01 fps), 160.36 kb/s

[uneedme]

x265 1.6+298-4a7176bab742 (https://www.mediafire.com/download/z3r9ly5cz5ax5a6/x265_1.6+298-4a7176bab742.7z)

New published parameter:

--qpstep <integer> The maximum single adjustment in QP allowed to rate control. Default 4

The maximum single adjustment in QP allowed to rate control. Default 4............

:confused:

What function is this parameter adjusted?

[LigH]

I believe it is a kind of dampening for the rate control, so that the difference of quantization factors between adjacent or dependent frames (B frames in relation to their referred I and P frames) is not too big, to avoid an annoyingly noticeable – because repetitive – "flickering" of compression artifacts in only a few frames, a.k.a. "quantization pumping". It will probably also limit expectable heavy fluctuations caused by very short scenes with a lot of detail (imagine dramatic flashbacks of a victim remembering an incident for parts of a second), they would need a brief raise of the bitrate, causing the following scene to drop the bitrate to avoid exceeding bitrate limits...

Just guessing. More details from a developer, possibly...

[foxyshadis]

I believe it is a kind of dampening for the rate control, so that the difference of quantization factors between adjacent or dependent frames (B frames in relation to their referred I and P frames) is not too big, to avoid an annoyingly noticeable – because repetitive – "flickering" of compression artifacts in only a few frames, a.k.a. "quantization pumping". It will probably also limit expectable heavy fluctuations caused by very short scenes with a lot of detail (imagine dramatic flashbacks of a victim remembering an incident for parts of a second), they would need a brief raise of the bitrate, causing the following scene to drop the bitrate to avoid exceeding bitrate limits...

Just guessing. More details from a developer, possibly...

Pretty much that, though that it also applies to the per-row QP changes needed to keep VBV happy. I suppose you could break VBV with it, if you really wanted to. It doesn't apply to AQ, though. Like most ratecontrol options, you should envision a giant flaming HERE THERE BE DRAGONS sign before you mess with it.

When you talk about B frame ratios, that would be the allowed difference after the base ratio is already calculated. (Normally 1.3:1 to P frames.)

Oddly enough, it's been in there for a while, it just wasn't listed in the help screen.

[mandarinka]

Pretty much that, though that it also applies to the per-row QP changes needed to keep VBV happy. I suppose you could break VBV with it, if you really wanted to. It doesn't apply to AQ, though. Like most ratecontrol options, you should envision a giant flaming HERE THERE BE DRAGONS sign before you mess with it.

When you talk about B frame ratios, that would be the allowed difference after the base ratio is already calculated. (Normally 1.3:1 to P frames.)

Oddly enough, it's been in there for a while, it just wasn't listed in the help screen.

It is taken over from x264 AFAIK, it has that parameter too (same default I think).

[Minamiya]

I have a funny problem with libx265 and ffmpeg.

if I give this line, directly:

wine avs2yuv_mod ./test.avs -o - | ffmpeg -i - -c:v libx265 -preset medium -pix_fmt yuv422p10le -crf 19 -x265-params "deblock=0:-1:rdoq-level=1:psy-rd=0.40:psy-rdoq=10.0:aq-mode=2:aq-strength=1.2:bframes=6:ref=6:rd=5:tu-intra-depth=4:tu-inter-
depth=4:me=3:max-merge=5:subme=6:merange=25:keyint=240:rc-lookahead=80:b-adapt=2:rect:amp:no-sao:no-open-gop:no-cutree:no-tskip:no-tskip-fast:weightp:weightb:no-strong-intra-smoothing" -y anime_01_x265.hevc

If he takes over to me no parametres from deblock etc.

x265 [info]: HEVC encoder version 1.6+360-bca33880585ax265 [info]: build info [Linux][GCC 4.9.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Internal bit depth : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
x265 [info]: Rate Control : CRF-19.0
x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

If I take, however, the Red marked lines out, he takes over the parametres suddenly, then grumbles though for the orange line, but then, otherwise, he takes over everything. With what does this lie that he does not take from me the lines?

x265 [info]: HEVC encoder version 1.6+298-4a7176bab742x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Internal bit depth : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 6 / 5
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 80 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 6
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.2 / 64 / 1
x265 [info]: Rate Control : CRF-19.0
x265 [info]: tools: rd=5 psy-rd=0.40 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

FFmpeg I have built thus:

./configure --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree
--enable-postproc --enable-version3 --enable-x11grab --enable-librtmp --enable-libxvid --enable-libass --enable-libx265

and x265

cmake -G "Unix Makefiles" -D HIGH_BIT_DEPTH:BOOL=ON ../../source
make -j4
./make-Makefiles.bash
make
checkinstall --pkgname=x265 --pkgversion="3:$(./version.sh | \
awk -F'[" ]' '/POINT/{print $4"+git"$5}')" --backup=no --deldoc=yes --fstrans=no --default

[easyfab]

And with rect=1:amp=1:no-sao=1.....

[foxyshadis]

You broke the argument list with the unparsable :-1:. Use :deblock=0,-1:rdoq-... for ffmpeg.

[benwaggoner]

Quick verification. For chroma offsets in x265, cbqpoffs and crqpoffs work like chroma-qp-offset does in x264, So negative values reduce QP for chroma and thus increasing chroma quality relative to luma, right? And positive values would shift bits and quality away from chroma towards luma?

--cbqpoffs <integer>
Offset of Cb chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12
--crqpoffs <integer>
Offset of Cr chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12

[Ely]

Hi everyone,

I'm having some trouble encoding animation movies as I encounter "glitches" around any character's movement.

Here's an example with an episode of family guy. Between the source and the x265 files, please take a look at the blonde's woman shoulders in the background :

source - frame 1 (http://i.imgur.com/fOOOvr9.png)
source - frame 2 (http://i.imgur.com/qu5XL8c.png)
source - frame 3 (http://i.imgur.com/FWNXEcN.png)

x265 - frame 1 (http://i.imgur.com/my75rU3.png)
x265 - frame 2 (http://i.imgur.com/1nPhkvs.png)
x265 - frame 3 (http://i.imgur.com/93mO1Hy.png)

To encode this part, I used x265 1.6+57f8246, default settings + preset slower.

Obviously the quality is worse than the source, but I wasn't expecting it to be _that_ worse. Plus, the decrease in quality seems more like glitches rather than just a simple blurring.

Soo.. Am I doing something wrong ? Should I tune further an important setting for animation ? Is x265 actually glitchy for this kind of content right now ?

Or is my CRF setting (28) simply too high ?

Thanks !

[Ma]

Soo.. Am I doing something wrong ? Should I tune further an important setting for animation ? Is x265 actually glitchy for this kind of content right now ?

You can try 10-bit x265 (if you used 8-bit) -- after fast check at preset slower & crf 28 on anime source I can't watch 8-bit x265 output. 10-bit is much better.

[RBX]

Are frame comparisons valid with psy settings on? I encoded an anime clip and in a certain frame I can see elements from next frame as well.

[nandaku2]

Quick verification. For chroma offsets in x265, cbqpoffs and crqpoffs work like chroma-qp-offset does in x264, So negative values reduce QP for chroma and thus increasing chroma quality relative to luma, right? And positive values would shift bits and quality away from chroma towards luma?

--cbqpoffs <integer>
Offset of Cb chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12
--crqpoffs <integer>
Offset of Cr chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12

Ben,
Correct. Positive offsets shift bits away from chroma. Here's roughly what the code looks like.

qpChroma = qpLuma + slice.m_pps->chromaQpOffset[0];

[foxyshadis]

Are frame comparisons valid with psy settings on? I encoded an anime clip and in a certain frame I can see elements from next frame as well.

If there are corruption artifacts, then definitely. Posting a short video sequence and command line that leads to artifacts would be the best of all. Also, what is your processor, just in case it's related to a particular instruction set?

[LigH]

@ Ely:

Indeed, there is a very obvious sample of a lack of good references and a possible intra encoding with heavy ringing (like Gibb's phenomenon). Another less obvious, but still typical place to spot them is in the ... what is that, a wooden arm? ... to the right of the blonde woman.

I guess if the developers had the original material available to recreate this glitch and test what happens exactly, they may find a way to avoid it getting as heavy as in the shoulder; unfortunately, HD cartoons with a cooperative license are hard to find.

[Ely]

You can try 10-bit x265 (if you used 8-bit) -- after fast check at preset slower & crf 28 on anime source I can't watch 8-bit x265 output. 10-bit is much better.

I did use 8bit x265. Can anyone explain to me what's the difference between 10-bit and 8-bit ? What kind of information is stored on 10 instead of 8 bits ?
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

@LigH okay, thanks for the information.

I did do another encode with CRF 23 (x265 8-bit), and the result was much better, all artifacts gone.

[LigH]

In general, not only for HEVC encoding: An encoder stores internal data (mainly the frequency parameters of the coding units, like "macro blocks") with a specific maximum precision (already many MPEG-2 encoders offered a DC precision of 8..11 bits). And when their values are quantized, they lose even more precision. This leads to rounding errors, but is also the usual way to reduce the diversity of values to be compressed by an entropy encoder (e.g. Huffman, Arithmetic Coding, etc. - depending on the video format), the usual method to reduce bitrate.

The 8 bit version of x265 provides an internal resolution of 8 bit = only 1 byte, which is quite easy to implement and often convenient; furthermore, many hardware decoders may only support 8 bit precision.

The "high bit depth" version of x265 currently provides routines for 10 bit resolution (more precision, like 12 bit, is also possible), which need 2 bytes each, therefore a lot more RAM, and a more complex implementation of internal calculations. It can store encoded values more exactly, but this means that they are less compressible because they are more diverse, therefore the required bitrate may be higher ... but does not have to. There is material which is even better compressible in higher parameter resolutions. Cartoons are known to profit from a higher bit depth.

[MeteorRain]

What kind of information is stored on 10 instead of 8 bits ?
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

Every channel of pixels will be encoded as 10 bit data.
10 bit is 25% larger than 8 bit, but it provides much more accurate value during computation. Think about the difference between 3.14159 and 3.1415926.

Besides, 8 bit YUV can barely represent ~6 bit RGB while 10 bit YUV can do ~8 bit RGB.

[Ma]

I did use 8bit x265. [...]
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

You can take 10-bit x265 and encode exactly like before -- preset slower & crf 28. Encoding time will be longer (not much), file size the same, quality you can evaluate your own eyes.

In theory 8-bit encoding is a little worse than 10-bit (assuming good encoder), but in practice x265 adds its imperfections and the result is very bad. 10-bit x265 is probably as bad as 8-bit x265 at 2 least significant bits, but if you decode 10-bit hevc you simply ignore these 2 bits and the result is OK.

[LigH]

Another weekly: x265 1.6+332-c4d9ee2cef03 (https://www.mediafire.com/download/8ks8af1c81smk4m/x265_1.6+332-c4d9ee2cef03.7z)

[Barough]

Another weekly: x265 1.6+332-c4d9ee2cef03 (https://www.mediafire.com/download/8ks8af1c81smk4m/x265_1.6+332-c4d9ee2cef03.7z)

Thnx 4 the new compile :)

[RBX]

If there are corruption artifacts, then definitely. Posting a short video sequence and command line that leads to artifacts would be the best of all. Also, what is your processor, just in case it's related to a particular instruction set?
I won't be able to post the video, but here is the frame I came across. http://screenshotcomparison.com/comparison/125530

The petal stays in the position for exactly 1 frame, so the difference isn't really visible during playback.

I used x265 1.6.298 16bpp compiled with ICC15. The CPU was i7-2630QM, and settings were preset:slow, tune:off, rc-lookahead:144, bframes:16, qg-size:16, crf:24
The video had few seconds of grainy scenes, and I was testing the effect of qg-size.

[Ely]

Okay, thank you all for clearing up high bit depth builds vs 8-bit builds.

As far as the sources are concerned, looks like x265 doesn't support any 10+bit YUV formats anyway, don't know why I was fixated on that.

Cheers

[LigH]

As far as I know, you can feed "DeepColor" video into x265. But I never did, so I don't have a matching workflow available to explain. I remember, though, that it has been discussed. I believe avs4x26x will help you, detecting such scripts and handling the pipe accordingly (e.g. using half the doubled size, because AviSynth has to stack the lsb and msb planes of 8 bit depth each).

[foxyshadis]

Okay, thank you all for clearing up high bit depth builds vs 8-bit builds.

As far as the sources are concerned, looks like x265 doesn't support any 10+bit YUV formats anyway, don't know why I was fixated on that.

Cheers

Why would you think that? x265 supports up to 16-bit YUV or Y4M input; if using YUV, you just have to specify --input-depth, and it'll always be converted to whatever depth the x265 build internally uses.

[burfadel]

I think they (as in the ITU and MPEG groups) should have made it as part of the h265 spec that 10-bit encoding is a requirement, and drop 8-bit all together. Why? Well, for 'standard' resolutions it looks better and is more efficient, and for encoding in 2160P it seems pointless if you're only using 8-bit. No point having 2160P resolution if you have banding or whatever!

For now, the wider the use of 10-bit, the more pressure will be on hardware makers to support it.

[littlepox]

Agreed. YUV-8bit has its native weakness in precision, resulting in a lot of banding.
It might not be obvious if you encode grainy sources, e.g., most movie clips; but they become extremely annoying if you are encoding anime, CG, or whatever clean-and-dark sources.
This cannot be overcome by any improvement in encoding technique. Some tricks, like adding noise, may help a little, but YUV-10bit is the true solution.

[Ely]

Why would you think that? x265 supports up to 16-bit YUV or Y4M input; if using YUV, you just have to specify --input-depth, and it'll always be converted to whatever depth the x265 build internally uses.

Oh indeed ! My bad (again) :-) .

[burfadel]

Agreed. YUV-8bit has its native weakness in precision, resulting in a lot of banding.
It might not be obvious if you encode grainy sources, e.g., most movie clips; but they become extremely annoying if you are encoding anime, CG, or whatever clean-and-dark sources.
This cannot be overcome by any improvement in encoding technique. Some tricks, like adding noise, may help a little, but YUV-10bit is the true solution.

If you're encoding an 8-bit source to 10-bit, I think it's also good to run a good deband and dither filter over it. It may seem counter-intuitive, but if you don't, you are actually encoding the banding. I find flash3kyuu to be exceptionally good at this (I'm using the 02 May 2015 2.0 prerelease). Works wonders :). The only option I use is f3kdb(dither_algo=2) despite algo_3 being supposedly better. The reason for this is number 2 encodes much better (unless you set a very low CRF or very high bitrate), and still looks vastly superior to not having it at all. It doesn't seem to affect bitrate either on 2 with CRF mode :).

Encoding an 8-bit source to 10-bit is still advantageous even if the source is banding and you don't use a filter. Even though you are encoding the banding, you are limiting the introduction of new banding and other associated artifacts. Ideally though, you get rid of the banding so you're not reencoding those artifacts.

[plonk420]

is there an issue with --tu-intra-depth 2 (and tu-inter) and decoders? or just a specific version? using MeGUI version 1.5+21 (LigH). i'm getting blocks flying all over in both CCCP+Lav but also VLC 2.2.1

i get the crazy blocks if i do --preset slower, but not if i do --preset slower --tu-intra-depth 1 --tu-inter-depth 1

http://i1.minus.com/i62UkijzwKkGL.png

[Santa]

I want to encode a 4k 16bpc png sequence to HEVC 4k 8bit 420

with x264 i was able to use a %04d.png as input, but with x265 it doesn't seem to work.
how do you input image sequences?

[sneaker_ger]

The standard x265 builds only support raw YUV input (with and without y4m headers). You cannot directly input any compressed formats. You need to find a different program that can input png and output to a pipe readable by x265. (Look for ffmpeg, VapourSynth, AviSynth).
Example: ffmpeg -i %04d.png -f yuv4mpegpipe -pix_fmt 420p - | x265 - --y4m -o output.265
(watch out for the colors, not sure how ffmpeg handles them)

There are patched x265 builds but I don't know if they offer the same functionality as x264 regarding

[burfadel]

Yeah, it would be nice to use x265 directly instead of using a pipe.

[feisty2]

Any news about main 444 16 intra and high throughput 444 16 intra?

[Ely]

Yeah, it would be nice to use x265 directly instead of using a pipe.

ffmpeg supports using x265 through "-vcodec libx265". It has to be compiled with the correct option "--enable-libx265" though.

[feisty2]

whatever clean-and-dark sources.

or just play with curves, pick another transfer, bt470 bg (L' = L^0.36 0 <= L <= 1) feels okay to me, it should kill the shit annoys you under 8bits precision.

[nandaku2]

is there an issue with --tu-intra-depth 2 (and tu-inter) and decoders? or just a specific version? using MeGUI version 1.5+21 (LigH). i'm getting blocks flying all over in both CCCP+Lav but also VLC 2.2.1

i get the crazy blocks if i do --preset slower, but not if i do --preset slower --tu-intra-depth 1 --tu-inter-depth 1

http://i1.minus.com/i62UkijzwKkGL.png

Something bad happening here. Can you please report this issue in our issue tracker (https://bitbucket.org/multicoreware/x265/issues) with exact commandlines and source (or mention a freely available clip) so that we can reproduce this at our end?

Thanks,

[LigH]

v1.5+21 is not quite a most recent version; testing "foreman" with v1.6+332 in all presets, no issues for all presets.

P.S.: Similar issues in the VideoHelp forum (http://forum.videohelp.com/threads/371670-What-is-the-reason-for-such-effects?p=2389378); Zathor, you may have to update x265 for MeGUI.

[foxyshadis]

The standard x265 builds only support raw YUV input (with and without y4m headers). You cannot directly input any compressed formats. You need to find a different program that can input png and output to a pipe readable by x265. (Look for ffmpeg, VapourSynth, AviSynth).
Example: ffmpeg -i %04d.png -f yuv4mpegpipe -pix_fmt 420p - | x265 - --y4m -o output.265
(watch out for the colors, not sure how ffmpeg handles them)

There are patched x265 builds but I don't know if they offer the same functionality as x264 regarding

x265 --y4m --colorprim bt601 --transfer bt601 - -o output.hevc

ffmpeg always converts using 601, so you have to flag that. If you want 709, you need:

ffmpeg -i "%1" -pix_fmt yuv420p16le -strict -1 -vf colormatrix=bt601:bt709 -vcodec rawvideo -f yuv4mpegpipe | x265 --y4m --colorprim bt709 --transfer bt709 - -o output.hevc

And if you want bt2020 with ffmpeg, you're plum out of luck. Kept in HBD so that the colormatrix operation doesn't lose much precision; x265 will dither it down.

ffmpeg is generally lousy at working with rgb and high bit depth formats. Imagemagick is lousy at working with yuv. Vapoursynth or Avisynth are generally your best option for converting with maximum quality.

[kolak]

Last ffmpeg versions (from 2.2 I think) can be forced to use Rec.709. Rec.601->Rec.709 is not optimal way.

You need to add this:
-vf scale=out_color_matrix=bt709 and your RGB sources will be converted through Rec.709.
There is small issue (very small red tint) for 8bit+ sources. Looks like this is related to conversion precision or some coefficients bug. Would be nice if someone can report it.

[foxyshadis]

-vf scale=out_color_matrix=bt709

Thanks, that's handy. I thought vf colormatrix was just shorthand for vf scale, but the debug output says scale options are applied to the initial conversion, whereas colormatrix is always a separate op. Good to know.

[kolak]

You can also control input colo matrix and black level.
Example:
"scale=in_range=full:in_color_matrix=bt601:out_range=tv:out_color_matrix=bt709"

Not sure how to avoid emoticons shortcuts (: out, with no space)

[sneaker_ger]

There's a "disable smilies in text" option when you post. (Need to "Go Advanced", though)

You can also control input colo matrix and black level.
Example:
"scale=in_range=full:in_color_matrix=bt601:out_range=tv:out_color_matrix=bt709"

[filler56789]

...
Not sure how to avoid emoticons shortcuts (: out, with no space)

By making the colons bold, for example;

:o ≠ :o

HTH :)

[kolak]

Thx, fixed.

[LoRd_MuldeR]

Not sure how to avoid emoticons shortcuts (: out, with no space)

https://forum.doom9.org/misc.php?do=bbcode#noparse

[plonk420]

Something bad happening here. Can you please report this issue in our issue tracker (https://bitbucket.org/multicoreware/x265/issues) with exact commandlines and source (or mention a freely available clip) so that we can reproduce this at our end?

Thanks,

it was just the video from Atlantis (the first, 2 Disc R1 release). checks out okay with VirtualDub, and even said settings (--preset slower --tu-intra-depth 1 --tu-inter-depth 1 ... as well as --preset slow), just not --preset slower

LoadPlugin("C:\mm\MeGUI_2028_x86\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\Atlantis_US_Col_feat\VIDEO_TS\VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 16~9 - Letterboxed.d2v", info=3)
LoadPlugin("C:\mm\MeGUI_2028_x86\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
crop(8, 56, -8, -64)
trim(7500,7600)

i cut it down to 500 frames since i was tired of waiting for the encode.

i tried MOD16, didn't help.

eventually, i tried 1.6+295 (i don't like straying too far from versions included with software), and it worked.

edit: wonky clip https://mega.co.nz/#!LB4xmBza!sekieIiwjFeUQzBZFRF2KfvEdsfwnFJVDGHCshXBJeE
edit2: not sure if this is SIMPLY --preset slow, or if i tweaked it: https://mega.co.nz/#!DY4E0SwZ!nCqDxPVwowvHc__NncVQzLKNsf4pROX5aPm7Yak__tw

[foxyshadis]

MeGUI is showing signs of abandonment lately, so updating x265 manually might be the only choice going forward. Hopefully that changes and it gets a 1.7 update, because QG-size is a very significant improvement, but otherwise more since-fixed bug reports can probably be expected.

[LigH]

A new "merge with stable" to prepare a coming v1.7 era: x265 1.6+412-b642b3d8cc1e (https://www.mediafire.com/download/xpmr0uv091u0mq6/x265_1.6+412-b642b3d8cc1e.7z)

Also support for "content light level" (HDR SEI info).

[Kurtnoise]

Compilation failed w/ the "DETAILED_CU_STATS" settings enabled...

c:/multicoreware-x265-3700169eb622/source/encoder/slicet
ype.cpp: In member function 'virtual void x265::PreLookaheadGroup::processTasks(
int)':
c:/multicoreware-x265-3700169eb622/source/encoder/slicet
ype.cpp:790:30: error: 'm_preLookaheadElapsedTime' was not declared in this scop
e
ProfileLookaheadTime(m_preLookaheadElapsedTime, m_countPreLookahead);
^
c:/multicoreware-x265-3700169eb622/source/encoder/slicet
ype.cpp:38:71: note: in definition of macro 'ProfileLookaheadTime'
#define ProfileLookaheadTime(elapsed, count) ScopedElapsedTime _scope(elapsed);
count++
^
c:/multicoreware-x265-3700169eb622/source/encoder/slicet
ype.cpp:790:57: error: 'm_countPreLookahead' was not declared in this scope
ProfileLookaheadTime(m_preLookaheadElapsedTime, m_countPreLookahead);
^
c:/multicoreware-x265-3700169eb622/source/encoder/slicet
ype.cpp:38:81: note: in definition of macro 'ProfileLookaheadTime'
#define ProfileLookaheadTime(elapsed, count) ScopedElapsedTime _scope(elapsed);
count++

^
make[2]: *** [encoder/CMakeFiles/encoder.dir/slicetype.cpp.obj] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2

[LigH]

Best posted to the x265 Developers Mailing List, I'd suggest...

This is a boolean cmake option (-D)?

Ah, yes, I can confirm.

[LigH]

x265 1.6+417-f2081ef64fd2 (https://www.mediafire.com/download/i6msp4p0svl74j3/x265_1.6+417-f2081ef64fd2.7z) publishes a switch to select the output (and internal) bit depth at run time:

-D/--output-depth 8|10 Output bit depth (also internal bit depth). Default {8|10}

Default depth depends on the compile options.

Now I wonder: If a 64 bit executable should support both 8 and 10 bit depths, shouldn't the building process create "more or less identical" binaries containing both code groups, so that switching between 8 and 10 bit depths at run time is at all possible? But normal and HBD builds still differ (DLLs as well as EXEs). I doubt this works as desired (but not tested yet...).

This package has also DETAILED_CU_STATS enabled.
__

P.S.: The documentation reads like it doesn't have to. If a specific depth is unsupported (because not linked in), it seems to fall back to a supported one. I guess that a dynamic EXE linking both 8 and 10 bit DLLs would be an easier way to make a CLI encoder supporting both at run time?

[MeteorRain]

Now I wonder: If a 64 bit executable should support both 8 and 10 bit depths, shouldn't the building process create "more or less identical" binaries containing both code groups, so that switching between 8 and 10 bit depths at run time is at all possible? But normal and HBD builds still differ (DLLs as well as EXEs). I doubt this works as desired (but not tested yet...).

P.S.: The documentation reads like it doesn't have to. If a specific depth is unsupported (because not linked in), it seems to fall back to a supported one. I guess that a dynamic EXE linking both 8 and 10 bit DLLs would be an easier way to make a CLI encoder supporting both at run time?

I'll look into it and probably can work out a custom patch to implement this.

EDIT:

Alright, this is what I can do for now.
Since cli heavily relies on the core (e.g. x265_malloc() / free() / log() / param.cpp etc), I can only keep the library inside cli while support dynamically load either dll at run time, for now. Maybe I can take sometime and rip the dependent code out of the core.

That is to say, (cli+lib) as the cli, while 8-bit lib and 10-bit lib in separate dll files. Depending on the param, it will either load 8-bit dll or 10-bit dll, completely ignore the internal one.

[Ma]

[...] If a specific depth is unsupported (because not linked in), it seems to fall back to a supported one.

For 8-bit x265.exe put in the same folder 10-bit *.dll with name "libx265_main10.dll".

For 10-bit x265.exe put in the same folder 8-bit *.dll with name "libx265_main.dll".

The names of *.dll are important.

[GodRealm]

For 8-bit x265.exe put in the same folder 10-bit *.dll with name "libx265_main10.dll".

For 10-bit x265.exe put in the same folder 8-bit *.dll with name "libx265_main.dll".

The names of *.dll are important.

Working perfect! Thank you!

[benwaggoner]

I'll look into it and probably can work out a custom patch to implement this.

EDIT:

Alright, this is what I can do for now.
Since cli heavily relies on the core (e.g. x265_malloc() / free() / log() / param.cpp etc), I can only keep the library inside cli while support dynamically load either dll at run time, for now. Maybe I can take sometime and rip the dependent code out of the core.

That is to say, (cli+lib) as the cli, while 8-bit lib and 10-bit lib in separate dll files. Depending on the param, it will either load 8-bit dll or 10-bit dll, completely ignore the internal one.
Are you implementing api_get?

http://x265.readthedocs.org/en/default/api.html#multi-library-interface

That's the recommended way to handle multiple .dll bit depth versions from a single app.

[LigH]

And ffmpeg is going to implement it as well:

[PATCH] avcodec/libx265: use x265 Multi-library Interface to query the API (http://ffmpeg.org/pipermail/ffmpeg-devel/2015-May/172773.html)

[stax76]

For 8-bit x265.exe put in the same folder 10-bit *.dll with name "libx265_main10.dll".

For 10-bit x265.exe put in the same folder 8-bit *.dll with name "libx265_main.dll".

The names of *.dll are important.

That makes it a bit easier for me. :goodpost:

[MeteorRain]

Are you implementing api_get?

http://x265.readthedocs.org/en/default/api.html#multi-library-interface

That's the recommended way to handle multiple .dll bit depth versions from a single app.

Yes, but my goal is to completely separate these two components.

[nandaku2]

That is to say, (cli+lib) as the cli, while 8-bit lib and 10-bit lib in separate dll files. Depending on the param, it will either load 8-bit dll or 10-bit dll, completely ignore the internal one.

So, depending on the param, it will check if the internal lib (the one the CLI was compiled with) matches the param, if so, use it. If not, it will load the dll with requested depth.

[LigH]

The "dynamic build" I imagined would have no internal library, only be a CLI stub, always loading external libraries depending on a default or parameter value. Would that be less preferable?

[foxyshadis]

I prefer a static build, so I don't have to deal with paths. As long as building a static library is possible, though, linking cli to it is easy enough.

[nevcairiel]

I agree, a single binary build is a feature that should not be made impossible with all these changes.
Personally, I don't really see the advantage of having .exe + 2x dll over .exe (with included library) + 1x dll

[qyot27]

From the way it read, it does seem to allow a main static build for one of the bittages, but I haven't tried it yet.

I figure on Linux or OSX this is handled differently, e.g. by LD_LIB_PREFIX or whatever the environment variable is. Having an option in the CMake install recipe to handle the DLL naming would be nice, though (if it's not already there).

[qyot27]

While it works with x265.exe and the -D option, I haven't been able to get the multi-lib to work with FFmpeg. I tried symlinking libx265_main10.dll into the directory with FFmpeg, and even resorted to a real copy of the .dll. No dice: if you pass an >8-bit source to it (or use -pix_fmt yuv4**p10le to fake it), libx265 won't use the 16bpp dll. And FFmpeg was linked against the exact same 8-bit libx265 as the x265.exe that works with the .dll uses. So I'm stumped.

EDIT: with 1.7+16 FFmpeg works, so this resolved itself.

[Motenai Yoda]

The only option I use is f3kdb(dither_algo=2) despite algo_3 being supposedly better.
Indeed I don't like f3kdb's defaults coz it adds too much grain and remove some subtle details/edges, also I'm not sure how well it works on 16bit without input_mode=1 and output_mode=1.
Actually I prefer gradfun3(0.1, lsb=true, lsb_in=true).Dither_add_grain16(0.3, 0.3)

btw there are restriction about how low --qg-size can be to keep hw decoding capability?

[x265_Project]

btw there are restriction about how low --qg-size can be to keep hw decoding capability?
No. Fine-grained adaptive quantization (at the CU level, and not just at the CTU level), is supported by the HEVC specifications, and any compliant HEVC decoder must support this.

[stax76]

Is it already possible to output either 8 or 10 bit by merely choosing --profile? This and avs reader would make it much easier for users and GUI authors, sorry for repeating myself, I just think it's very important.

[Kurtnoise]

Is it already possible to output either 8 or 10 bit by merely choosing --profile?
-D switch

This and avs reader would make it much easier for users and GUI authors, sorry for repeating myself, I just think it's very important.
look at the previous pages...there is already a patch for that.

[LigH]

@ Kurtnoise: stax76 wonders if it would be preferable to derive the result of the -D (output depth) switch from a selected output profile (e.g. "--profile main10" implies "-D 10").

[stax76]

look at the previous pages...there is already a patch for that.

Is there a binary already?

@ Kurtnoise: stax76 wonders if it would be preferable to derive the result of the -D (output depth) switch from a selected output profile (e.g. "--profile main10" implies "-D 10").

Yes, I could live with -D but only using --profile would be a much better solution for everybody I believe.

[Kurtnoise]

Is there a binary already?
locally, yes..., publicly, I dont think so.

Yes, I could live with -D but only using --profile would be a much better solution for everybody I believe.
well...that might be problematic because some Profiles have a range of bit depths allowed, not 1 or 2 values available.

[x265_Project]

Yes, I could live with -D but only using --profile would be a much better solution for everybody I believe.
We had to consider all of the various combinations of input-depth, internal-depth and output-depth. What really matters when choosing the right x265 library is the internal depth, which is generally tied to the output depth.

[stax76]

Thanks, I'll just add --output-depth then, are there already builds supporting this?

[Ma]

Thanks, I'll just add --output-depth then, are there already builds supporting this?

Yes, you can try my builds (1.6+451 support --output-depth):
www.msystem.waw.pl/x265/

You can also take last LigH build and rename *.dll.

[stax76]

Thanks, great that it's ready. I don't know exactly how to support it in StaxRip unfortunately, problem is profiles are not really well documented, not in the x265 documentation and not in the wikipedia HEVC article, or maybe I just don't understand it.

[Ma]

Thanks, great that it's ready. I don't know exactly how to support it in StaxRip unfortunately, problem is profiles are not really well documented, not in the x265 documentation and not in the wikipedia HEVC article, or maybe I just don't understand it.

About profiles in x265 I found:
http://x265.readthedocs.org/en/default/cli.html#profile-level-tier

About profiles in HEVC I found (page 17):
http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Overview.pdf

Can you describe what do you want to do (example)?

Edit: I'll try to guess. You are using 10-bit LigH build and you make HEVC 'main10' profile by default. If you want to make HEVC 'main' profile, add 'libx265.dll' from 'Win64_8bpp' folder in LigH archive to your x265.exe and rename 'libx265.dll' to 'libx265_main.dll'. Then you can add '-D 8' option to your command line and there will be 'main' profile. This works only with the latest LigH build.

[stax76]

Thanks, this pdf is very helpful, it's much clearer now. I need to expose a GUI option for both --profile and --output-depth, problem solved.

[Ma]

Scenario:
10-bit x265.exe + 8-bit libx265_main.dll
Command line: x265 -P main in.y4m out.hevc
x265 output:
x265 [error]: main profile not supported, compiled for Main10.

My proposition: if there is 8-bit dll and user ask for 'main' profile, x265 should switch to 8-bit and encode to 'main' profile instead of abort with error message.

[x265_Project]

x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.

Full documentation at: http://x265.readthedocs.org/en/1.7/

This release simplifies the multi-library support introduced in version 1.6. Any libx265 can now forward API requests to other installed libx265 libraries (by name) so applications like ffmpeg and the x265 CLI can select between 8bit and 10bit encodes at runtime without the need of a shim library or library load path hacks. See --output-depth, and http://x265.readthedocs.org/en/1.7/api.html#multi-library-interface

For quality, x265 now allows you to configure the quantization group size smaller than the CTU size (for finer grained AQ adjustments). See --qg-size.

x265 now supports limited mid-encode reconfigure via a new public method: x265_encoder_reconfig()

For HDR, x265 now supports signaling the SMPTE 2084 color transfer function, the SMPTE 2086 mastering display color primaries, and the content light levels. See --master-display, --max-cll

x265 will no longer emit any non-conformant bitstreams unless --allow-non-conformance is specified.

The x265 CLI now supports a simple encode preview feature. See --recon-y4m-exec.

The AnnexB NAL headers can now be configured off, via x265_param.bAnnexB This is not configurable via the CLI because it is a function of the muxer being used, and the CLI only supports raw output files. See --annexb

Misc:
* --lossless encodes are now signaled as level 8.5
* --profile now has a -P short option
* The regression scripts used by x265 are now public, and can be found at: https://bitbucket.org/sborho/test-harness
* x265's cmake scripts now support PGO builds, the test-harness can be used to drive the profile-guided build process.

[LigH]

On the occasion of the new milestone:

x265 1.7+2-d7b100e51e82 (https://www.mediafire.com/download/fwdd59oxx2rq5m5/x265_1.7+2-d7b100e51e82.7z)

Please note: Contains different file names, starting with v1.7, to be more easily compliant with the new Multi-library Interface (http://x265.readthedocs.org/en/1.7/api.html#multi-library-interface).

[Barough]

Thnx for the new compile LigH :)

[LigH]

P.S.: Additional MSYS2-64 GCC 4.9.2 build (http://www.mediafire.com/download/77fynsk4i536v9v/x265_1.7+2-d7b100e51e82.GCC492.7z), each one pair only (8-bit EXE + 10-bit DLL), as built with media-autobuild_suite by jb_alvarado

[Ma]

There is something wrong with new GCC compilers and x265. First I thought that new GCC compilers are weak, but I've made new speed test, and now I don't know what's going on.

Win7 64-bit, i5 3450S, test video https://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

Options: "--preset slow -D 10 --crf 20 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709 -f 120"

Warriors:
All builds are for generic CPU with default -O3 optimize option.
x265-492-no-asm -- GCC 4.9.2, assembly OFF
x265-600-no-asm -- GCC 6.0.0, assembly OFF
x265-492 -- GCC 4.9.2, assembly ON
x265-600 -- GCC 6.0.0, assembly ON

Result:
x265-492-no-asm | 112.91s | 1.06 fps | 100.0%
x265-600-no-asm | 106.26s | 1.13 fps | 94.1%
-------------------------------------------------------
x265-492 | 33.60s | 3.57 fps | 100.0%
x265-600 | 35.49s | 3.38 fps | 105.6%

Without asm GCC 6.0.0 crushes GCC 4.9.2, with asm there is quite opposite. The result are similar for GCC 5.1 (it is not so fast without asm). This is quite strange to me...

Full result and builds -- http://msystem.waw.pl/x265/test6.7z

[Kurtnoise]

x265 1.7 (http://www.mediafire.com/download/9n1uyn4cm378ccn/x265_1.7.7z) w/ YUV, Y4M, AVS, AVI, MKV, MOV, MP4, FLV files support as input and MP4, MKV as output...for testing of course.

[stax76]

x265 1.7 (http://www.mediafire.com/download/9n1uyn4cm378ccn/x265_1.7.7z) w/ YUV, Y4M, AVS, AVI, MKV, MOV, MP4, FLV files support as input and MP4, MKV as output...for testing of course.

Thanks, I'm gonna test it.

[shinchiro]

I tested chromashift's msvc build with gcc build before and notice msvc slightly faster than gcc. So between gcc, icl and msvc compiler, which one give more speed in windows for anyone?

[Ma]

So between gcc, icl and msvc compiler, which one give more speed in windows for anyone?

My observations:
MSVC is good for 10-bit encoding, worse for 8-bit,
ICL is slow and gives strange results (output file differs from MSVC/GCC output),
GCC for slow/slower/veryslow presets is OK when you are making native builds with -O2 optimize option (there is very small L1 cache in my i5 3450S CPU -- only 32 KB),
GCC for faster presets are OK with -O3 optimize option, native build + PGO.

[shinchiro]

Thanks. Look like I'll stick with MSVC build since I regularly encoding in 10bit :)
btw just curious, how you do benchmark speed for different compiled build?
Is there any huge gain when specify optimize option like -march=core-avx2, -O3 when compiling?

[Ma]

btw just curious, how you do benchmark speed for different compiled build?

I take part of the movie which I want to encode, for example:
ffmpeg.exe -ss 7693 -i movie.mkv -filter:v "crop=1920:800:0:140" -an -sn -frames 750 -pix_fmt yuv420p -f yuv4mpegpipe 1920x800-hob.y4m

Then I rename different builds to unique names and use my test.bat file (you can find one in test6.7z couple post above). First I try with only 20 frames (-f 20 with options) and I estimate how many frames I need to about 100 s for fast compare, 300 s for good compare and 500 s for very good compare. In the evening I close all apps, unplug network cable, start test.bat and go to sleep. In the morning I can read result file -- last result file I attached to this message as example.

Is there any huge gain when specify optimize option like -march=core-avx2, -O3 when compiling?

I have only AVX CPU (AVX2 builds hangs on my system). If we say that my native build encoding time is 100.0%, then generic build encoding time is 101.5% (from last test).

[MeteorRain]

x265 1.7 (http://www.mediafire.com/download/9n1uyn4cm378ccn/x265_1.7.7z) w/ YUV, Y4M, AVS, AVI, MKV, MOV, MP4, FLV files support as input and MP4, MKV as output...for testing of course.

Please take extra care on timestamps, e.g., vfr / timebase / fps. I'm not so sure they are 100% working so be careful.

[x265_Project]

The current default build has a bug that is causing it to be quite a bit slower than previous builds (like the 1.7 stable build). Ironically, this bug was caused by a new analysis method that is designed to make x265 faster. Our team will get this ironed out soon. In the meantime, you're better off sticking with earlier builds.

[dipje]

Just to be clear, the slow-ness bug is in the 1.7-2 LigH build for example?

[LigH]

Probably yes, this is (related to the source versioning, not the compile time) the very first "v1.7 stable" build (the +2 patches are marginal, after declaring the v1.7 milestone).

[Ma]

Due to last night results (attached) there is slowdown from 1.7+2 to 1.7+37 version:
---------- |- 1.7+2 -|- 1.7+37 | slowdown
10b-AVX | 330.52s | 333.72s | +1.0%
10b-GEN | 335.37s | 337.29s | +0.6%

The code is slower and bigger. In 1.7+2 AVX version (with -O2 optimize option) the generated code was small enough for 32 KB L1 cache, in GEN (generic CPU) version was too big, but in 1.7+37 the code is too big for L1 cache in AVX & GEN builds.

[dipje]

So the slowdown-bug actually came in the source _AFTER_ 1.7-2 ? That would make LigH's build (as example) still ok, right?

Would be nice if a problem is stated (as now) that there is a link or at least a commit-number or something where the problem crept in (or in this case, what the last known good version was).

It's not clear to me now if the last known good version is in the 1.6 milestone-branch or if there actually is a good '1.7' at all :)

edit: and if the problem is really what Ma is talking about, that means the slowdown is around 1%.. not really making it 'unusable' or anything :)

[x265_Project]

So the slowdown-bug actually came in the source _AFTER_ 1.7-2 ? That would make LigH's build (as example) still ok, right?

Would be nice if a problem is stated (as now) that there is a link or at least a commit-number or something where the problem crept in (or in this case, what the last known good version was).

It's not clear to me now if the last known good version is in the 1.6 milestone-branch or if there actually is a good '1.7' at all :)

edit: and if the problem is really what Ma is talking about, that means the slowdown is around 1%.. not really making it 'unusable' or anything :)
The commit I'm referring to is 61a6bc5 (https://bitbucket.org/multicoreware/x265/commits/61a6bc52debfc21515f6bb4729bb0201c89f196a).

On my Core i7 4700HQ (quad core Haswell) notebook I'm seeing speeds that are average ~ 30% slower than earlier builds. This is just with a simple constant QP sweep, using different performance presets (ultrafast, superfast, veryfast, fast, medium, slow, veryslow). Our engineers weren't able to replicate this on a Haswell desktop (Core i7 4770K). Your feedback on speeds before and after this batch of commits (early Wednesday morning, US time) is appreciated. Is it just me, or can anyone else replicate this issue?

Tom

[Barough]

Desktop PC w/ Core i7-4930K


Preset Medium
ABR 500kbit
Custom Command Line : --me 3 --aq-mode 2 --aq-strength 3


x265_1.6+412-b642b3d8cc1e (LigH)
16 min 5 secs 44,67 FPS


x265_1.7+2-d7b100e51e82 (LigH)
15 min 58 sec 44.96 FPS

[x265_Project]

Thanks Barough. I really appreciate the sanity check.

I found the problem. My local CMAKE config was still pointing to a test repository, and messing up my build. False alarm... crisis averted... situation normal. Sorry for the scare. All is well... nothing to see here... move along.

Tom

[Barough]

YW Tom :)

[dipje]

Even the best make small mistakes :P

[divxmaster]

x265.1.6.360 (meteor_rain) 10.12fps
x265.1.7.37 (meteor_rain) 11.69fps

1000 frames, 480p, crf28.

so good speed increases in this example for me.
Size of 1.7 was .06% smaller.

Cheers,
Divxmaster

[burfadel]

I notice that the info is a little different? What does the following mean?
x265 [info]: References / ref-limit cu / depth : 6 / 0 / 0

I know the 6 is reference frames, I'm referring to the 0's.

[foxyshadis]

Both of those are only set if --limit-refs is used, an option that tries to speed up encoding by only checking references that sort-of matched at 64x64 for the smaller partitions. You can usually use a couple more references for free, considering encoding-speed, for only a tiny loss of efficiency (and a gain if those extra references help enough).

[nandaku2]

x265.1.6.360 (meteor_rain) 10.12fps
x265.1.7.37 (meteor_rain) 11.69fps

1000 frames, 480p, crf28.

so good speed increases in this example for me.
Size of 1.7 was .06% smaller.

Cheers,
Divxmaster

Yes, we're seeing good performance increases at the fast and medium preset, because the early outs are now effective more often (depending on content).

[Ely]

I was recently testing slow vs slower and noticed a big decrease in quality in slower mode. Namely what I would call "ghosting", such as what happens on a cold screen where pixels can't update fast enough during movement.

So I did some digging by enabling all the new functions that appear from slow to slower one by one, and the culprit happens to be rd=5 (from rd=4).
In the 3 frames below, look at the guy with a purple shirt, brown pants and green beer in his hand.

I'm using 1.7+37-dc4fcfc574ade14e - 8-bit

slow - 1 (http://i.imgur.com/wbKoNce.png)
slow - 2 (http://i.imgur.com/myVgGxy.png)
slow - 3 (http://i.imgur.com/zn0uWr4.png)

slow - RD=5 - 1 (http://i.imgur.com/dFkv5aE.png)
slow - RD=5 - 2 (http://i.imgur.com/0IplpQ5.png) <== this is where it happens
slow - RD=5 - 3 (http://i.imgur.com/1cCBbQ4.png)

As you can see, the rd-5 version has severe "ghosting". It may not seem much, but this is repeated several times during this guy's movement, and the video in itself looks very sluggish when played at 24fps.
This is not the only person it happens to, anything with movement basically gets hit (more or less severely) by this artifact in the whole encode.

Can anyone confirm this ?

I'm gonna hold off rd=5 for the moment.

[easyfab]

@Ely

IMHO You should post to the mailing list at x265-devel@videolan.org to acces directly the developpers and have a faster answer or create an issue https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

[Ely]

Aye, I'll create an issue, but since a lot of experienced users & x265 devs visit this thread, I thought it'd be good to post here too :).

[Gravitator]

This phantom can be linked with technology b-frame prediction mode. Similarity in x264 > http://files.neolabs.kz/fl/?id=2092
Original sample > https://mega.co.nz/#!hZl0WBCA!WvwyTWs-VSbcAJ6Km3aCyT7LP5wy7_Tq1TmnXaHaNYg

[zerowalker]

Read before about the "being able to change between bit-depths" and i wonder, can this be adopted in x264?

[uneedme]

This phantom can be linked with technology b-frame prediction mode. Similarity in x264 > http://files.videohelp.com/u/227452/x264%20and%20b-frame%20prediction.7z


:( how to moderate this ghost effect?

[aegisofrime]

Hi, quick question which I think would be very easy to answer.

I'm giving a go at compiling my own x265 (I followed the instructions on the Bitbucket), and to my pleasant surprise it actually worked on the first try. Except for one thing: the exe doesn't report the version number. It reports it as version unknown. What do I need to do so that it would show the version number? Thanks!

[foxyshadis]

Hi, quick question which I think would be very easy to answer.

I'm giving a go at compiling my own x265 (I followed the instructions on the Bitbucket), and to my pleasant surprise it actually worked on the first try. Except for one thing: the exe doesn't report the version number. It reports it as version unknown. What do I need to do so that it would show the version number? Thanks!

The simplest way is to check the source out using Mercurial (hg), which CMake uses to get the version. Otherwise you have to manually define it in the generated makefiles.

[Ajvar]

Could somebody tell me why would 0:02:30 video with 2min, 26 sec of still image and 4 seconds of the same image but text appearing effect would look like cr@p and took over 8000 kbps with Main Still profile selected? While without selecting profile I get 300-400 kbps video with perfect image.
is it a bug?

[dipje]

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

[nevcairiel]

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

Technically the "Still" profile is for "still images", ie. single images encoded as HEVC, so modern jpeg, not even motion-jpeg. But people like to (ab-)use such profiles since they allow for some features they may want... :)

[foxyshadis]

Main Still is Main profile with the added restriction that only a single frame can be encoded, otherwise it's exactly the same. Why would you ever encode video with that?

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

That's actually called Main Intra, and maybe that's what x265 switches to in this case, I don't know.

[Ajvar]

Main Still is Main profile with the added restriction that only a single frame can be encoded, otherwise it's exactly the same. Why would you ever encode video with that?
Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

[LigH]

Please try to understand that the most reduction of video bitrate is based on comparing the content of frames, and finding ways to reduce the size of the descriptions of the differences between them. P(redicted) frames store differences to a previous I(ntra = independent) frame, B(idirectionally predicted) frames can even try if the differences to a previous or a following frame can be stored with a smaller size. But the "Main Still" profile does not compare different frames, therefore it cannot use the most efficient ways of reducing the size.
__

You want to encode a "static video" of 2 minutes playing time? Well, many modern video codecs (not only HEVC) should be able to handle this situation pretty well, because nothing (except completely blank content) is easier material to find similarities which can be reduced in size. That's what motion prediction was made for, P and B frames will find perfectly matching motion vectors everywhere, and they are even (0,0), optimally compressible ... in theory.

In practice, though, there is a bunch of psychovisual changes which support scenes with non-zero motion and changes better. Applied to really still scenes, you may instead notice slight problems (like quantization pumping). To avoid these, tweaking specific parameters (like quantization ratios, the consecutive B frame maximum, motion search range, disabling adaptive quantization) may be necessary. Unfortunately, I am not able to tell you "the best parameters". I did not write these encoders, other people know them a lot better than me.

But it may even be possible to avoid encoding the video with as many frames as the playing time would require. Authored media formats shall have a feature to use exactly one encoded frame and hold the video for a given duration. Already the DVD Video is able to use one still video frame for a menu with an additional audio stream of a longer playing time. I believe that the successor technologies will support it still.

[Ajvar]

Please try to understand that the most reduction of video bitrate is based on comparing the content of frames, and finding ways to reduce the size of the descriptions of the differences between them. P(redicted) frames store differences to a previous I(ntra = independent) frame, B(idirectionally predicted) frames can even try if the differences to a previous or a following frame can be stored with a smaller size. But the "Main Still" profile does not compare different frames, therefore it cannot use the most efficient ways of reducing the size.

OK. That's a catch. Not experienced users would believe that picking Still profile is best for Still pictures however on practice (as I believe now) it is just profile hardware requirement: how slow can be hardware player to be able to play still HEVC images, - which is kinda silly because practically any player including mobile phones possibly can do this and not just this anyway.
I repeat, people will just pick Still profile for Still images video because it's most logical, get it?
You want to encode a "static video" of 2 minutes playing time? Well, many modern video codecs (not only HEVC) should be able to handle this situation pretty well, because nothing (except completely blank content) is easier material to find similarities which can be reduced in size. That's what motion prediction was made for, P and B frames will find perfectly matching motion vectors everywhere, and they are even (0,0), optimally compressible ... in theory.

In practice, though, there is a bunch of psychovisual changes which support scenes with non-zero motion and changes better. Applied to really still scenes, you may instead notice slight problems (like quantization pumping). To avoid these, tweaking specific parameters (like quantization ratios, the consecutive B frame maximum, motion search range, disabling adaptive quantization) may be necessary. Unfortunately, I am not able to tell you "the best parameters". I did not write these encoders, other people know them a lot better than me.

But it may even be possible to avoid encoding the video with as many frames as the playing time would require. Authored media formats shall have a feature to use exactly one encoded frame and hold the video for a given duration. Already the DVD Video is able to use one still video frame for a menu with an additional audio stream of a longer playing time. I believe that the successor technologies will support it still.
Sure I managed to encode this video (took 1 frame and did "ffmpeg -loop 1 -r 1 -i 1.png -c:v libx264 -preset medium -tune stillimage -crf 16 -pix_fmt yuv420p -t 155 output.mkv") and then HEVC encode (--keyint 9000 --bframes 16 --ref 1) and it used 3.5 Kbps but just had to use Auto profile.
Starting Main@01:09:09.836:
"--pmode --pme --input - --input-res 1280x720 --fps 2 --no-open-gop --keyint 9000 --bframes 16 --ref 1 --qp 32 --deblock=-3:-3 --colormatrix bt470bg --output "T:\Temp\output.265"
x265 [info]: HEVC encoder version 1.6+239-5c3443546ccc
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)+pmode+pme
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 2 / 9000 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CQP-32 / 0.0 / 0
x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong
x265 [info]: tools: deblock(tC=-3:B=-3) sao
x265 [info]: frame I: 1, Avg QP:29.00 kb/s: 872.85
x265 [info]: frame P: 22, Avg QP:32.00 kb/s: 1.19
x265 [info]: frame B: 287, Avg QP:33.92 kb/s: 0.89
x265 [info]: global : 310, Avg QP:33.77 kb/s: 3.73
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 4.3% 0.0% 0.0% 4.3% 0.0% 4.3% 4.3% 0.0% 8.7% 4.3% 0.0% 0.0% 4.3% 4.3% 0.0% 4.3% 56.5%
encoded 310 frames in 7.71s (40.21 fps), 3.73 kb/s
finished after 00:00:07.773

[foxyshadis]

Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

HEVC is not just a video codec, it's also meant to be an image codec.

Main Still is like JPEG, it's for ONE frame. It's to signal to image viewers (like photo frames) that the content isn't a video, it's just a plain picture. Main and its extensions are for all other purposes.

Main Still is a bit pointless, since containers signal that kind of metadata now. Best to ignore it and use standard profiles even for still images, since in the first spec there wasn't even a 10-bit version.

[Gravitator]

:( how to moderate this ghost effect?
It is enough to figure out a coding method adds an RD=5 (and then disable them to identify the culprit).

[dipje]

Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.


but in this case you clearly picked the wrong settings, disabling (unknowingly) everything that relates to 'multiple frames' bascially :).

Just use 'main profile', it's 'main' for a reason.

Remember, 'profile' is NOT used to tell the video codec what kind of material it is encoding, that's where the tuning options come in. Profiles are meant to tell the _decoding_ devices what kind of videostream to expect.

Just don't use 'main still' and you will be ok.

[divxmaster]

Yes, we're seeing good performance increases at the fast and medium preset, because the early outs are now effective more often (depending on content).

Actually that fps speed increase was on slow preset, so an excellent result.

[MeteorRain]

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

1000 frames in still profile is considered as 1000 (completely different) still images, regardless of how similar they are.

[Ajvar]

A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

OK, how to do it on practice? I mean x265 code.

[foxyshadis]

OK, how to do it on practice? I mean x265 code.

Main and its extensions are for all other purposes.

Since you need it spelled out: Main and Main 10, the only other profiles available.

[Ajvar]

Since you need it spelled out: Main and Main 10, the only other profiles available.

Since you need either:
A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

OK, how to do it (properly use still image profile to keep 1 single and only lone picture and keep timecode/duration) on practice? I mean step-by-step command line code for x265 exe.
Special to foxyshadis , no, not asking how to encode anything in Main/Main 10 profile, thank you, no need to tell me about that. My concern is if that if there is additional profile than why it's not used or how to.

[LigH]

Probably analogue to how it worked on a DVD Video with one MPEG-2 still frame:

1. Encode one frame to a HEVC raw file.

2. Use this one encoded HEVC frame with a prolonged display duration. That may depend on the authoring tool you will be using later when authoring a media format supporting HEVC as stills, possibly an Ultra-HD Blu-ray disc. On DVD Video, authoring tools used to extend the display of a background MPEG-2 still frame to the playing time of the parallel audio stream automatically in a menu, or manually to a desired length if used in a slide show. I would assume that authoring tools for more modern formats may do something very similar.

[nevcairiel]

OK, how to do it (properly use still image profile to keep 1 single and only lone picture and keep timecode/duration) on practice? I mean step-by-step command line code for x265 exe.

You should not to that, its unlikely to work properly for various reasons, the primary one being that it would be a VFR video, which is badly supported by a whole lot of things. You have been warned. ;)

Still Image profile should only be used for single still images (actual images, like jpg's), not for encoding videos, even if the video contains long "still" images.

I'm not sure why you are insisting on using it, it won't really improve the quality for you either, but of course all the power to you.

[benwaggoner]

You should not to that, its unlikely to work properly for various reasons, the primary one being that it would be a VFR video, which is badly supported by a whole lot of things. You have been warned. ;)
Do we know if that's true for HEVC decoders? Since by definition those will be recent, the bar would be a lot higher. We don't need to worry about VfW HEVC players, I hope!

With only one frame, it could still be CFR, just with the fps set to the reciprocal of the desired duration. So a 10 sec duration would use a fps of 0.1.

Still Image profile should only be used for single still images (actual images, like jpg's), not for encoding videos, even if the video contains long "still" images.

I'm not sure why you are insisting on using it, it won't really improve the quality for you either, but of course all the power to you.
I concur on that. Using Main Still in this case would only reduce compatibility for any scenario I can think of. Main Still is probably most useful as a modern Motion-JPEG or other I-frame only codec equivalent.

[LigH]

Must have forgotten the last one. So today, two releases.

x265 1.7+37-dc4fcfc574ad (https://www.mediafire.com/download/xr350536r8wj5jm/x265_1.7+37-dc4fcfc574ad.7z)
—

[Ajvar]

@LigH , @nevcairiel , @benwaggoner , OK, thanks for babysitting with me. I guess all disadvantages destroy an only advantage of Main Still then. Maybe some day somebody makes it more useable and useful.

[LigH]

A pocket knife is already useful. Just not for cutting down a tree. Use a saw for that purpose.

"Main Still" profile is already useful. Just not for encoding a full frame rate video. Use "Main" profile for that purpose.

[LigH]

x265 1.7+95 removed in favour of 1.7+96:

api: fix for crash in x265_api_query caused by function type casting error

In x265_api_query, after retrieving the function pointer of x265_api_query from external DLL, it is then incorrectly type cast into x265_api_get function, the patch is intended for this fix.

x265 1.7+96-093618ce0b26 (https://www.mediafire.com/download/4l98hadr7d71di3/x265_1.7+96-093618ce0b26.7z)

[dipje]

@LigH , @nevcairiel , @benwaggoner , OK, thanks for babysitting with me. I guess all disadvantages destroy an only advantage of Main Still then. Maybe some day somebody makes it more useable and useful.

I still don't get what advantage you think 'Main Still', I can't think of one

[Motenai Yoda]

Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.

I would point out that the documentation still has not been changed / corrected

[benwaggoner]

I would point out that the documentation still has not been changed / corrected
That suggests that --dither would give you dithering even if converting from yuv420p10le to 10-bit.

I guess it's good to be able to get dithering when going from actual 16-bit to 10-bit, though. But dithering definitely shouldn't be enabled when not changing bit depth.

[Motenai Yoda]

Yep but I still don't know exactly if a 16bit->10bit dithering is done or not.
At the age of that post --dither was applied even for 10bit (when enabled), to the detriment of what documentation sai(d)s , now it doesn't (or at least I got some truncated, 6bit like, output, v1.6+4xx).

also, level's max ref is related with bitdepth too? I notice with level 4 it's lowered to 5(+1) for 8bit, but 4(+1) for 10bit

[foxyshadis]

Yep but I still don't know exactly if a 16bit->10bit dithering is done or not.
At the age of that post --dither was applied even for 10bit (when enabled), to the detriment of what documentation sai(d)s , now it doesn't (or at least I got some truncated, 6bit like, output, v1.6+4xx).

also, level's max ref is related with bitdepth too? I notice with level 4 it's lowered to 5(+1) for 8bit, but 4(+1) for 10bit

That's definitely not correct, every profile has a "FormatCapabilityFactor" that normalizes the memory requirements, main10 being 20% higher than main. At the same frame size, all profiles allow equal numbers of reference frames.

(The 20% more memory to support main10@4 won't let you go up to 4.1 in 8bit, but it might let you sneak in an extra ref, if your player doesn't reject it.)

The dither algorithm hasn't changed, it still dithers down for all greater-than-internal, not just 8-bit.

[Motenai Yoda]

sorry my bad, I mistyped 5 not 4 setting 8bit level-idc...
so how can it be calculated? x265's docs says only 8 is the max, -1 for bframe, -1 for b-piramid, so 6

-1 for the current frame that has to be stored in the dpb too (as wiki says), so 5

but in 2014/10 itu's spec. I found

d) The value of sps_max_dec_pic_buffering_minus1[ HighestTid ] + 1 shall be less than or equal to MaxDpbSize, which is derived as follows:
if( PicSizeInSamplesY <= ( MaxLumaPs >> 2 ) ) MaxDpbSize = Min( 4 * maxDpbPicBuf, 16 )
else if( PicSizeInSamplesY <= ( MaxLumaPs >> 1 ) ) MaxDpbSize = Min( 2 * maxDpbPicBuf, 16 ) (A-2)
else if( PicSizeInSamplesY <= ( ( 3 * MaxLumaPs ) >> 2 ) ) MaxDpbSize = Min( ( 4 * maxDpbPicBuf ) / 3, 16 )
else MaxDpbSize = maxDpbPicBuf
where MaxLumaPs is specified in Table A.4 and maxDpbPicBuf is equal to 6.
again 6 -1 -1 = 4
this seems to comply with x265 restrictions...

anyway
--input-depth 16
http://thumbnails108.imagebam.com/41370/246c0a413695601.jpg (http://www.imagebam.com/image/246c0a413695601)
--input-depth 16 --dither
http://thumbnails108.imagebam.com/41370/918ed6413695504.jpg (http://www.imagebam.com/image/918ed6413695504)

[foxyshadis]

I just made my first encode with --analysis-mode load and while it ran 3 times as fast, the encoded file was completely broken. This is with 10-bit input and output, current git head.

Original command line: x265 --preset veryslow --input pristest.y4m --analysis-mode save --analysis-file pristest.dat --crf 20 -o pristest-q20-veryslow.hevc
Second command line: x265 --preset veryslow --input pristest.y4m (https://dl.dropboxusercontent.com/u/54412753/x265/pristest_30s.7z) --analysis-mode load --analysis-file pristest.dat (https://dl.dropboxusercontent.com/u/54412753/x265/pristest.7z) --crf 24 -o pristest-q24-veryslow.hevc (https://dl.dropboxusercontent.com/u/54412753/x265/pristest-q24-veryslow.hevc)

All I changed was the crf, and I got tons of black blocks and echo blocks, especially beginning around 0:20, as if residuals sometimes weren't being applied at all. MPDN just freezes, other players play with major artifacts.

Aside from that, holy crap is the analysis file huge. It's as large as the y4m; I had to put it on a ntfs compressed folder, where it went from 11gb to 800mb real bytes. (The 7-zip is only 50mb.) Surely x265 can run some sort of compression over it while writing, either xz (lzma2) or at least gzip? When I first attempted to use it from the same drive as my working file, I ended up thrashing the disk so badly that encoding speed was actually halved, until I moved it to my SSD system drive.


Lastly, a suggestion for the docs: --strong-intra-smoothing is barely described. The purpose of it is to prevent macroblocking in smooth areas, primarily ones that look like this:
http://www.webalice.it/f.corriga/temp/ghostingzoomnm1.png
It's banding, but mainly due to zero or near-zero AC coeffs and tends to be larger. In 8-bit mode, strong intra smoothing will at least reduce it to plain jagged banding, and in 10-bit mode it'll render it more invisible. I have no idea if it has any downsides, though.

[mandarinka]

I had problems with wrong motion vectors being used in january (but it wasn't this broken), so I would also say, don't use the dump/analyse feature for serious production...

[littlepox]

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.

[LigH]

Most probably related to better instruction efficiency and AVX2 support (which is heavily used in x265 when available)?

[mandarinka]

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.

Wow, that's a huge difference. Was it with frequency locked, or with turbo enabled (in that case, Haswell might have been helped by higher boost states reached)?

[littlepox]

Wow, that's a huge difference. Was it with frequency locked, or with turbo enabled (in that case, Haswell might have been helped by higher boost states reached)?

It was locked @ 4.0GHz and we monitored that using CPU-Z. Therefore none of the participants takes any advantage by turbo boost.

[benwaggoner]

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.
That's a nice boost!

Which build of x265 was it, and what sort of settings?

[littlepox]

That's a nice boost!

Which build of x265 was it, and what sort of settings?

We used the v1.7+51, MSVC build, 64bit - highbitdepth ver.

Settings are made as follow(the one we use to encode animes):

--preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2 --qg-size 32


pretty much a heavy setting.

Participants include:

Core i7 2700K
Core i7 3770K
Core i7 4790K
Core i7 3930K
Core i7 4930K
Core i7 5820K

Results from the quad-core group are fairly consistent with results from the hex-core group.

[burfadel]

Are the speed improvements due to AVX2 a result of being better over SSE2/SSE3/SSSE3/SSE4.2? Or is it because there are AVX2 versions of the C code that do not have SSE2/SSE3/SSSE3/SSE4.2 versions? Looking at the latest commits after v1.7+51, the performance gap is probably even wider now.

[mandarinka]

Are the speed improvements due to AVX2 a result of being better over SSE2/SSE3/SSSE3/SSE4.2? Or is it because there are AVX2 versions of the C code that do not have SSE2/SSE3/SSSE3/SSE4.2 versions? Looking at the latest commits after v1.7+51, the performance gap is probably even wider now.

The SSE* SIMD should have a full coverage, so it is not matter of going from C to AVX2. The AVX2 paths that exist are going to be faster than SSE* on Haswell though, so it does give a speedup.

But Haswell should be faster clock-for-clock even in the code that only has SSE* version and no AVX2 version yet, thanks to microarchitecture improvements. These two things combine together.

[littlepox]

Just a side comparison:
For x264-10bit, haswell is 17% faster than ivy, and 24% faster than SNB.

x264 takes care of old CPUs more than x265 since it spent much of its life time without haswell. The performance gap is narrower, even though x264 is heavily optimized for haswell too.

Most would agree that haswell itself gains advantage of 5~10% faster than ivy, if you use benchmarks without AVX2 opt.

[benwaggoner]

We used the v1.7+51, MSVC build, 64bit - highbitdepth ver.

Settings are made as follow(the one we use to encode animes):

--preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2 --qg-size 32
That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths. Also, it's make comparing to x264 like comparing apples to wombats.

What are those settings optimized for anyway? Anime? Ultrasounds?

[littlepox]

That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths. Also, it's make comparing to x264 like comparing apples to wombats.

What are those settings optimized for anyway? Anime? Ultrasounds?

Anime. See this for more info:
http://forum.doom9.org/showthread.php?p=1717888#post1717888

Anyway, no matter this test is accurate or biased, we do enjoy the benefit of the opts along x265's development. half a year ago it usually took us 50+% more time for an encode than today, so good job x265 team. However, I do hope they can make some break though in the quality, especially @ high bit-rates. We won't spend months testing out our own settings if we are satisfied with built-in tunes and presets.

[nandaku2]

The SSE* SIMD should have a full coverage, so it is not matter of going from C to AVX2. The AVX2 paths that exist are going to be faster than SSE* on Haswell though, so it does give a speedup.

But Haswell should be faster clock-for-clock even in the code that only has SSE* version and no AVX2 version yet, thanks to microarchitecture improvements. These two things combine together.

Thanks for the test results. You can use --asm=avx or --asm=sse4.2 to restrict x265 to use those instruction sets only. That will help separate out the benefits of AVX2 code and improved Haswell microarchitecture.

[mandarinka]

Just a side comparison:
For x264-10bit, haswell is 17% faster than ivy, and 24% faster than SNB.

x264 takes care of old CPUs more than x265 since it spent much of its life time without haswell. The performance gap is narrower, even though x264 is heavily optimized for haswell too..

The performance gap is narrower probably because AVX2 has less opportuinities to be useful in H.264 - the format has smaller blocks, smaller transforms, and due to that it can't be SIMDed to wide vector sizes like AVX2's 256bits as much as HEVC, which is more (large) SIMD friendly generally.

That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths.
I don't think it is such an serious issue. Most of those parameters are influencing rate-control (except PME I guess), so it won't really change codepaths. What the speed options could do is changing the balance of CPU cycles spent in various regimes (MC, interpolation, DCT, loopfilter, RDO, etc), but that is not that bad IMHO. It is the same problem as is posed by the existence of different presets: which is the proper preset for speed testing - ultrafast, placebo, medium? Whatever is default? Whatever is most usable? At that point, custom settings aren't that much troublesome.

[easyfab]

A quick test on sintel trailer :

CPU : I3-4000M
X265 1.7+93 --preset fast --crf 23

With AVX2 : x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

encoded 1253 frames in 71.16s (17.61 fps), 611.00 kb/s

With --asm AVX : x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

encoded 1253 frames in 89.66s (13.98 fps), 611.00 kb/s

In this case AVX2 FMA3 LZCNT BMI2 instructions give 26% more speed.

[soresu]

Should be interesting to see what performance gains Carrizo will see over Kaveri with AVX2 in Excavator. Unless of course there are already equivalent gains from XOP instructions in x265?

[Ma]

Some time ago I wrote bad words about new GCC 5.1 & 6.0 -- x265 is very slow when it is build with new versions of GCC.

After investigation it is all right with new GCC, there are bugs in x265 sources. I've created issue #143
https://bitbucket.org/multicoreware/x265/issue/143/x265-is-slow-when-it-is-build-with-gcc-51

So I take back all the bad things I have written about a new versions of GCC.

[aegisofrime]

Some time ago I wrote bad words about new GCC 5.1 & 6.0 -- x265 is very slow when it is build with new versions of GCC.

After investigation it is all right with new GCC, there are bugs in x265 sources. I've created issue #143
https://bitbucket.org/multicoreware/x265/issue/143/x265-is-slow-when-it-is-build-with-gcc-51

So I take back all the bad things I have written about a new versions of GCC.

Out of curiosity, what's the speed when your fixes are applied?

[Ma]

Out of curiosity, what's the speed when your fixes are applied?

10-bit encoding speed on i5 3450S, input file 1920x800 23.976 fps, common options: "--crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709".
Builds:
x265-492 -- my normal 10-bit build with -march=corei7-avx option,
x265-510 -- 10-bit GCC 5.1 build with -march=corei7-avx option + patch,
x265-510old -- 10-bit GCC 5.1 build with -march=corei7-avx option (without patch),
x265-snow -- 10-bit snowfag build.

Raw numbers -- encoding time in seconds:

-----------|- fast -|- medium |-- slow -|- slower | veryslow| placebo
x265-492 --| 94,72s | 135,76s | 161,78s | 164,33s | 161,66s | 165,89s
x265-510 --| 94,29s | 134,78s | 161,23s | 163,86s | 161,26s | 164,77s
x265-510old| 100,68s| 145,78s | 167,31s | 180,14s | 173,28s | 174,19s
x265-snow -| 95,31s | 137,06s | 162,65s | 165,77s | 163,56s | 166,64s


Percentage comparison (x265-492 encoding time == 100.0%):

-----------|- fast | medium|- slow | slower|veryslow| placebo
x265-492 --| 100,0%| 100,0%| 100,0%| 100,0%| 100,0% | 100,0%
x265-510 --| 99,5% | 99,3% | 99,7% | 99,7% | 99,8% -| 99,3%
x265-510old| 106,3%| 107,4%| 103,4%| 109,6%| 107,2% | 105,0%
x265-snow -| 100,6%| 101,0%| 100,5%| 100,9%| 101,2% | 100,5%


Result file and batch used to this test is attached.

x265-492 & x265-510 you can download from www.msystem.waw.pl/x265/
x265-snow you can download from http://builds.x265.eu/

[benwaggoner]

Say, has anyone built a x265 into a DirectShow or QuickTime codec? Sometimes it sure would be nice to be able to export directly from my favorite GUI video software instead of having to render out an intermediate which I then decode with ffmpeg and pipe into x265.exe. An uncompressed 10-bit intermediate file for a full-length UHD feature is >>1 TB. And can take hours to write out in After Effects or other pro video tools.

I suppose this is part of the broader challenge of getting encoders from ffmpeg or etcetera into Windows/Mac codecs/plugins instead of standalone apps. I still remember my bitterness when I discovered ffdshow was playback only. We've had extensible media file writer APIs for a couple of decades now, but somehow they never seem to intersect with the open source codec world.

Or am I missing some incredibly powerful and widely used thing on SourceForge that everyone else knows about? Alternatively, a new secret thing I can know about :)?

[LigH]

Since the encoder is available as DLL, it would probably be possible to write "bridges" using it. But I doubt that the API is already final. Furthermore, I don't remember any free software using DirectShow based encoders; not enough hens laying not enough eggs?

[LigH]

Current builds appear to be really a lot bigger, especially 16bpp binaries (EXE: 3.3 => 4.6 MB; DLL: 2.9 => 4.1 MB; each about +1.2 MB). Furthermore, the "full help" output shrunk to 70% of its previous amount.

x265 1.7+166-32590b25678b (https://www.mediafire.com/download/4q9c5w6eokv9u97/x265_1.7+166-32590b25678b.7z)

P.S.: Compressed with 7-zip 15.05 beta; please check if you can unpack even with slightly older versions (but min. 9.20 beta).

[benwaggoner]

Since the encoder is available as DLL, it would probably be possible to write "bridges" using it. But I doubt that the API is already final. Furthermore, I don't remember any free software using DirectShow based encoders; not enough hens laying not enough eggs?
The API has actually been pretty stable for a while, and the Windows .dll is successfully being used with commercial and open-source apps.

Its a mystery why open source stuff doesn't make it to DirectShow. It seems there's more clamoring for VfW plugins, which is a terrible API that was deprecated, sheesh 16 years ago? Back when DirectShow was introduced as ActiveMovie. There's already a DirectShow .mp4 writer and AAC encoder, so all it needs is a DST wrapper for x265.dll.

Well, anyway, if someone wants me to owe them a Big Favor, a good sustainable solution for this would certainly earn that.

[nevcairiel]

What apps do actually exist that can use DShow encoders and muxers?
Its probably not too impossible to write a simple wrapper around the encoder, even if it just gives you a textbox where you can put it in the CLI option syntax. =p

[LigH]

Apart from GraphStudio? ... Possibly expensive commercial video editors I can't afford, if at all; but it is hard to search for it, I was not yet lucky.

As I already mentioned, I never heard of any freeware supporting it. Wikipedia's chapter about End-user tools (https://en.wikipedia.org/wiki/DirectShow#End-user_tools) is ... brief.

I wonder if it is at all the purpose of DS encoders to be freely usable as plugins; I would be afraid that applications supporting DS encoders may need to provide their own configuration dialogs for a few specifically known encoders.

There is a bold offer by visioforge, a collection of DS encoders/muxers, as trial version, partially containing freeware.
__

P.S.: Ancient NLE found which appears to support DS encoders, according to screenshots: in-sync Speed Razor (2001, abandoned).
__

P.P.S.: There is a "Multipurpose DirectShow Encoder" which executes an LGPL ffmpeg inside a DirectShow filter graph. Connect it to your preferred source filters and render. If you are able to use a current ffmpeg build, you may abuse it to encode with libx265. But it appears to be a bridge to a pipe. A solution which "takes us all around the houses".
__

One more: BluffTitler seems to be a 3D text titling software supporting DS encoders.
__

Canopus ProCoder 2 (http://forum.doom9.org/showthread.php?t=74379) must have supported any DirectShow encoder filter... so there is a chance that current GrassValley software may still do.

[LigH]

Because "merge with stable":

x265 1.7+180-d6c32960b5df (https://www.mediafire.com/download/i81278eq2e7tveu/x265_1.7+180-d6c32960b5df.7z)

[foxyshadis]

Save/load analysis is fixed in hg! (Old saves can even be reused.) This will save me so much time, I can restart my quest for the perfect options.

[Atak_Snajpera]

Quick question regarding reusing stat file in second pass with different target bitrate.
Let's say I have generated stat file in first pass with target bitrate of 1024. What will happen if in second pass I reuse this stat file but I change target bitrate. Instead of 1024 I use 2048 or 512. Will this be a big problem for x265/x264 encoder?

[LigH]

Weekly (with a just even fixed typo in the XP compatible X265 Name Space refactoring):

x265 1.7+207-83a7d8244424 (https://www.mediafire.com/download/uaalnuesnx0gulu/x265_1.7+207-83a7d8244424.7z)

[Atak_Snajpera]

Weekly (with a just even fixed typo in the XP compatible X265 Name Space refactoring):

x265 1.7+207-83a7d8244424 (https://www.mediafire.com/download/uaalnuesnx0gulu/x265_1.7+207-83a7d8244424.7z)

x265 sometimes creates corrupted stat file
Two examples
http://pastebin.com/KBeCMgyi
http://pastebin.com/8UKx43Lc

http://i.cubeupload.com/Dp2PuQ.png

[Ma]

x265 sometimes creates corrupted stat file

You have CPU with lots of threads and the corruption is at the end of stat file. It looks like there is needed thread synchronization at the end of encoding with stat file write.

[ShamisOMally]

So entirely depressing. Spend 60 hours doing a 10bit X265 PSNR encode for a movie at CRF 18, file size came out at 980MB. Quality was so-so for static area's, but high motion area's it was amazingly terrible causing severe banding/corruption/macroblocking

Then did a 10-bit x264 PSNR encode at CRF 18, file size came out at 2GB and it looked literally the same as source, even high motion area's were perfectly clear.

Wish I saved the 10-bit x265 export but I was entirely unimpressed at the time length vs quality I got. According to everything I read the last 2 days on this issue comes to the conclusion that 10-bit x265 is bad/unstable ATM? Does anybody have similar results?

[burfadel]

So entirely depressing. Spend 60 hours doing a 10bit X265 PSNR encode for a movie at CRF 18, file size came out at 980MB. Quality was so-so for static area's, but high motion area's it was amazingly terrible causing severe banding/corruption/macroblocking

Then did a 10-bit x264 PSNR encode at CRF 18, file size came out at 2GB and it looked literally the same as source, even high motion area's were perfectly clear.

Wish I saved the 10-bit x265 export but I was entirely unimpressed at the time length vs quality I got. According to everything I read the last 2 days on this issue comes to the conclusion that 10-bit x265 is bad/unstable ATM? Does anybody have similar results?

Isn't PSNR mode designed not for actual practical encoding? How about trying standard settings (non-PSNR) at CRF 18 and see if the same result occurs? Even if this is a clip that contains both static and high motion scenes. With that clip, try also with x265 (non PSNR) at CRF 18.

All you did by disabling PSNR in x265 is to disable adaptive quant, psy-rd, and cutree.

Try default settings in x265, but in addition:
--qg-size 16
--psy-rd 0.8
--weightb
--subme 3
--b-intra
--aq-mode 2
--ref 5
--bframes 6

You could even try a lower CRF, like 17.

For example.

[Ajvar]

Did anyone compare x265 encode performance on Linux vs Windows? Linux Mint on Ubuntu for instance?

[LigH]

It shouldn't hurt to let encoders report PSNR or SSIM values. Just don't tune for metrics if you don't intend to encode for benchmarking metrics; for visually pleasing results, use defaults or content related tunings.

Furthermore, if your source is interlaced, and you don't configure the encoder to focus on fields rather than frames, a bad quality even with CRF 18 is not surprising. With progressive sources, CRF 18 should certainly not return displeasing results, neither with x264 nor with x265.

[Ely]

Could somebody explain how --vbv-bufsize and --vbv-maxrate work ? I understand they're to limit the maximum bitrate and simulate a "fake bandwidth cap", but why are there 2 options for that ? Why not just one option to specify the maximum bitrate ?

Let's say I want a max bitrate of 5000kbps, should I set this value to both options ?

[Boulder]

@ShamisOMally, burfadel: I redid my comparisons of x265 against x264 and there's no change what comes to x265 smoothing all the detail from certain frames. They probably have not concentrated on that at this point.

[LigH]

@ Ely:

This topic is too complex to fit in a thread specifically about the x265 encoder. It is not even specific to any codec, it was already interesting in times of (S)VCD and DVD. And to no surprise, it has been discussed many times already in the last decade.

Imagine the decoding buffer like an open rain barrel with a rusty faucet. The faucet has a maximum output; if there is too heavy rain, the barrel will overflow because it fills faster (video bitrate) than it gets emptied (decoding speed). But if there is only little rain, the barrel will run dry because it also has a minimum output, you can't close it as tight as you like. The bigger the barrel, the longer you can stand a dry phase before the barrel is empty.

You need to know both the capacity of the decoding buffer and the maximum fill rate (which is limited by the bitrate the source media can be read with) to produce video streams which will neither fill the buffer too fast (and make it "overflow") nor fill the buffer too slowly for a long time (and make it "run dry").

The Profile@Level limits are related to playback devices with different limits for video buffer sizes and meda reading speeds. But to support a specific device perfectly, it may be an advantage to know both VBV limits as exactly as possible, to allow the encoder to use them for optimal bitrate adaption.

By the way, the source medium may also be a network broadcast with a limited bandwidth, a.k.a. "video stream".

[Ma]

Let's say I want a max bitrate of 5000kbps, should I set this value to both options ?

Yes, you can set for n kbps:
--vbv-bufsize n --vbv-maxrate n
or (even better)
--vbv-bufsize 2*n --vbv-maxrate n

In first case you will have no less than 1 second buffer, in second case -- 2 seconds.

Why do you want a max bitrate of 5000kbps? (maybe --bitrate 5000 is enough?)

[Ely]

Thank you both for answering. I'm encoding videos which have a fairly low complexity overall, but sometimes they have incredibly complex short scenes which make the bitrate momentarily go sky high (using crf). I'd like to limit that effect, and I thought using vbv-maxrate might be the solution. But maybe 2-pass ABR is better ?

@Ma I'm pretty sure I meant 5000 kbps, aka 5mbps. 5000 b/s would be really low wouldn't it ?

[Ma]

I'm encoding videos which have a fairly low complexity overall, but sometimes they have incredibly complex short scenes which make the bitrate momentarily go sky high (using crf). I'd like to limit that effect, and I thought using vbv-maxrate might be the solution.

Yes, vbv-maxrate + small vbv-bufsize "helps" -- it will be visible quality loss. Big vbv-bufsize can to push through short complex scene without quality loss. So for you it is OK --vbv-bufsize 5000 --vbv-maxrate 5000.

[Ajvar]

x265 team set vbv-buff size to twice size the vbv-maxrate. When I set equal size (1x) I saw visible degradation in quality on costly scenes.

[Ma]

x265 sometimes creates corrupted stat file

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

[foxyshadis]

Unless you know the bufsize, you should never touch maxrate, otherwise you're just feeling around in the dark to get some effect. Buffer size is a hard number, while maxrate (maximum decoding rate, not the maximum streaming rate) is a little softer -- some chips might be a little better with CABAC, others with MC, some might have more threads for better wavefront support, so the character of the stream affects it and the stated maximum decoding rate tends to be rather conservative -- but it's still something you should measure on an actual hardware target before you go setting it willy-nilly.

[nandaku2]

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

Thank you. We're looking at this issue as well as at your proposed patch. In the meantime, I would highly encourage you to sign our CLA at Downloads (https://bitbucket.org/multicoreware/x265/downloads), and send us your patch through the mailing list (read Contribute (https://bitbucket.org/multicoreware/x265/wiki/Contribute))

[Ma]

Thank you. We're looking at this issue as well as at your proposed patch.

I'm not sure if this patch is necessary. The fprintf function from present-day compilers should be atomic
http://stackoverflow.com/questions/22539282/is-msvcrts-implementation-of-fprintf-thread-safe

Atak_Snajpera uses x265 build with ancient compiler and this may be the reason.

[Atak_Snajpera]

I'm not sure if this patch is necessary. The fprintf function from present-day compilers should be atomic
http://stackoverflow.com/questions/22539282/is-msvcrts-implementation-of-fprintf-thread-safe

Atak_Snajpera uses x265 build with ancient compiler and this may be the reason.

I can confirm that builds from http://chromashift.org/x265_builds/ work fine. So it looks like that GCC 4.8.2 is a problem like MA already mentioned.

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

This patched build works fine as well.

[Ma]

I can confirm that builds from http://chromashift.org/x265_builds/ work fine. So it looks like that GCC 4.8.2 is a problem like MA already mentioned.

I found some historic words about MinGW
https://en.wikipedia.org/wiki/MinGW#Programming_language_support
and it looks like there was problem with printf function and posix threading (which MinGW-w64 resolved). So maybe LigH uses GCC 4.8.2 with posix threading and old MinGW headers/crt.

I believe in what is written in Wikipedia but we should double check this. Could you test clean (without any patches) builds of x265 made by GCC with actual MinGW-w64 headers/crt? There are two builds: with posix threading and with win32 threading. The win32 threading version should work, but I'm not so sure about posix threading version.
www.msystem.waw.pl/x265/test2-Atak.7z

[Atak_Snajpera]

I found some historic words about MinGW
https://en.wikipedia.org/wiki/MinGW#Programming_language_support
and it looks like there was problem with printf function and posix threading (which MinGW-w64 resolved). So maybe LigH uses GCC 4.8.2 with posix threading and old MinGW headers/crt.

I believe in what is written in Wikipedia but we should double check this. Could you test clean (without any patches) builds of x265 made by GCC with actual MinGW-w64 headers/crt? There are two builds: with posix threading and with win32 threading. The win32 threading version should work, but I'm not so sure about posix threading version.
www.msystem.waw.pl/x265/test2-Atak.7z

I will surprise you ;) None of them work.

[LigH]

My current build environment is the MSYS / MinGW-Win32 with GCC 4.8.2 which was once released by XhmikosR, possibly years ago?

I guess I should try to abandon this era and use a current MSYS / MinGW-Win64 with GCC 4.9.2 (http://xhmikosr.1f0.de/tools/msys/) instead in the future. Speed advantages have been documented already. If there are now even reliability issues, it appears convincing.
__

Now I wonder if the linking issues (https://mailman.videolan.org/pipermail/x265-devel/2015-June/008672.html) of "multilib" builds are also caused by this old environment, or if people with a modern build environment can't link libx265_main10.a to x265.exe either.

[Ma]

I will surprise you ;) None of them work.

Thanks for testing. It is time to dig deeper...

[Ma]

If there are now even reliability issues, it appears convincing.

I don't know what's going on, but it is not your GCC fault.

Now I wonder if the linking issues of "multilib" builds are also caused by this old environment, or if people with a modern build environment can't link libx265_main10.a to x265.exe either.

Now I use GCC from site www.drangon.org/mingw/ (GCC 5.1 from http://mingw-w64.org/ is not fully compiled -- they made 6 of 8 versions and stop). There is no problem with strtok_r with current GCC/MinGW-w64, but I have another problem with linking. I must add -DSTATIC_LINK_CRT=ON to cmake command and when I add additionally -DEXTRA_LIB=x265_main10.a -DEXTRA_LINK_FLAGS=-L. the file CMakeFiles\cli.dir\linklibs.rsp is wrong:
libx265.a -Wl,-Bstatic -lx265_main10 -Wl,-Bdynamic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

[birdie]

IMO limiting bitrate is perhaps only suitable for streaming/burning to optical media.

For all other purposes CRF is the best choice.

[ShamisOMally]

@ShamisOMally, burfadel: I redid my comparisons of x265 against x264 and there's no change what comes to x265 smoothing all the detail from certain frames. They probably have not concentrated on that at this point.

You should see how much X265 mangles my Blu-ray of Atlantis: The Last Empire.

The scene with the fireflies with X265 10bit turns into an absolute sea of artifact soup, same with 8bit.

[ShamisOMally]

Isn't PSNR mode designed not for actual practical encoding? How about trying standard settings (non-PSNR) at CRF 18 and see if the same result occurs? Even if this is a clip that contains both static and high motion scenes. With that clip, try also with x265 (non PSNR) at CRF 18.

All you did by disabling PSNR in x265 is to disable adaptive quant, psy-rd, and cutree.

Try default settings in x265, but in addition:
--qg-size 16
--psy-rd 0.8
--weightb
--subme 3
--b-intra
--aq-mode 2
--ref 5
--bframes 6

You could even try a lower CRF, like 17.

For example.

I find enabling PSNR for encodes of my blu-rays I want to stick into my collection absolutely destroys quality due to the encoder emphasizing things incorrectly, like spending more bitrates doing definitions of Text rather than the whole scene.

I actually get more macroblock artifacts with PSNR turned on, most noticeably dark area's like like a sea of dark crap, PSNR turned off the encoder works far better for me

[foxyshadis]

I find enabling PSNR for encodes of my blu-rays I want to stick into my collection absolutely destroys quality due to the encoder emphasizing things incorrectly, like spending more bitrates doing definitions of Text rather than the whole scene.

I actually get more macroblock artifacts with PSNR turned on, most noticeably dark area's like like a sea of dark crap, PSNR turned off the encoder works far better for me

That's normal. PSNR is virtually meaningless for video encoding, it's only useful for micro-optimizations. The tuning only exists to maximize a meaningless number for people who care about that number for historical reasons.

You should see how much X265 mangles my Blu-ray of Atlantis: The Last Empire.

The scene with the fireflies with X265 10bit turns into an absolute sea of artifact soup, same with 8bit.

Are you able to cut out 60s or so of this scene and upload them somewhere? I always appreciate new torture samples. You should be able to use mkvmerge to split just a fragment of the video track.

[ShamisOMally]

That's normal. PSNR is virtually meaningless for video encoding, it's only useful for micro-optimizations. The tuning only exists to maximize a meaningless number for people who care about that number for historical reasons.



Are you able to cut out 60s or so of this scene and upload them somewhere? I always appreciate new torture samples. You should be able to use mkvmerge to split just a fragment of the video track.

Sure, I'll pull out my blu-ray and do a quick redo of the firefly scene

x264 10-bit PSNR turned off
http://i.imgur.com/lIQy69r.jpg

x265 10-bit PSNR turned off
http://i.imgur.com/rMm4s4q.jpg

x265 10-bit PSNR turned on
http://i.imgur.com/OdcOxUB.jpg

[benwaggoner]

The scene with the fireflies with X265 10bit turns into an absolute sea of artifact soup, same with 8bit.
Are you doing preprocessing? If not, I don't recommend changing color depth when reencoding. HEVC doesn't get the same sort of gain as H.264 from encoding in 10-bit.

[benwaggoner]

x265 team set vbv-buff size to twice size the vbv-maxrate. When I set equal size (1x) I saw visible degradation in quality on costly scenes.
That's pretty predictable if the maxrate isn't super high. Presumably you're using >1 sec GOPs. With only a 1 sec buffer, the encoder is limited in its ability to shift bits to a highly detained IDR frame.

I generally prefer to have my bufsize = maxrate * keyint / fps.

Also, maxrate and bufsize are limited by your profile and level in all codecs. For example, Level 4.0 (for 1080p30 and down) has a limit of 12000 Kbps for maxrate and 12000 Kb for bufsize. I'm a strong believer in making compliant streams, so I can yell at someone else if they don't work, so I always specify a level, maxrate, and bufsize in my encodes. They're often high enough to not have a material impact on quality, but I feel better knowing the stream is playable by any compliant decoder.

I still have nightmares from x264 not properly limiting reference frames, and seeing 1080p streams flagged Level 4.0 but with 8 reference frames. The existence of those ~4 years ago is why media apps on Xbox 360 that use Microsoft's official Smooth Streaming component are limited to only 720p.

Which was a bad solution to in my strong opinion. And a good example of why I don't work at Microsoft anymore...

[ShamisOMally]

As you can see with above, when I turn on PSNR it starts defining the edges of lines/objects, which I guess is good? but it washes out the rest of the scene because its allocating bitrate for them.

Problem is it completely loses all detail elsewhere, the number of fireflies that vanish when PSNR is turned on is rather drastic, look around the two men's hands and the far right side, PSNR turned on a great deal of them vanish into artifacts

[ShamisOMally]

That's pretty predictable if the maxrate isn't super high. Presumably you're using >1 sec GOPs. With only a 1 sec buffer, the encoder is limited in its ability to shift bits to a highly detained IDR frame.

I generally prefer to have my bufsize = maxrate * keyint / fps.

Also, maxrate and bufsize are limited by your profile and level in all codecs. For example, Level 4.0 (for 1080p30 and down) has a limit of 12000 Kbps for maxrate and 12000 Kb for bufsize. I'm a strong believer in making compliant streams, so I can yell at someone else if they don't work, so I always specify a level, maxrate, and bufsize in my encodes. They're often high enough to not have a material impact on quality, but I feel better knowing the stream is playable by any compliant decoder.

I still have nightmares from x264 not properly limiting reference frames, and seeing 1080p streams flagged Level 4.0 but with 8 reference frames. The existence of those ~4 years ago is why media apps on Xbox 360 that use Microsoft's official Smooth Streaming component are limited to only 720p.

Which was a bad solution to in my strong opinion. And a good example of why I don't work at Microsoft anymore...

I have buffer at absolute min because I do in home viewing and not web streaming, I'll encode the scene again with buffer set to max to see if it changes anything with x265 10bit

*EDIT* If I had any real input on the development on codecs, I would ask why x264/x265 is absolutely TERRIBLE with blue <--> purple transitions and why its not been fixed/adjusted for it.

I mean, wow, every encode I've ever done, its the first place render artifacts come up.

[nandaku2]

As you can see with above, when I turn on PSNR it starts defining the edges of lines/objects, which I guess is good? but it washes out the rest of the scene because its allocating bitrate for them.

Problem is it completely loses all detail elsewhere, the number of fireflies that vanish when PSNR is turned on is rather drastic, look around the two men's hands and the far right side, PSNR turned on a great deal of them vanish into artifacts

Tune psnr disables AQ, psy-rd and psy-rdoq. This is to be used only if you're interested in objective PSNR measurements, as PSNR hates it when bits are redistributed across a frame.

Since you care about subjective visual quality, please try the default settings.

[foxyshadis]

I mean, can you upload the actual original blu-ray version of the firefly scene? Otherwise I can rent the disc and find it, it's not that big of a deal. There's something really, really wrong with the way x265 treats that scene.

[ShamisOMally]

x265 10-bit PSNR off 16000Kbit buffer
http://i.imgur.com/oJBh8x0.jpg

Massive quality increase, but image is still not as good as x264 which was only using a buffer of 64kbit buffer

@Foxy: I'd rather not upload clips, as I'd likely get in shit from some law crap or what not for doing so

[benwaggoner]

x265 10-bit PSNR off 16000Kbit buffer
http://i.imgur.com/oJBh8x0.jpg

Massive quality increase, but image is still not as good as x264 which was only using a buffer of 64kbit buffer

@Foxy: I'd rather not upload clips, as I'd likely get in shit from some law crap or what not for doing so



Can you share your complete command lines for x264 and x265? Note that there isn't a --tune animation for x265 yet, although there are recommended anime settings floating around.

[ShamisOMally]

Can you share your complete command lines for x264 and x265? Note that there isn't a --tune animation for x265 yet, although there are recommended anime settings floating around.

x265 settings:

x265_10bpp --preset veryslow --profile main10 --level-idc 50 --tune psnr --pmode --pme --no-open-gop --keyint 250 --scenecut 40 --wpp --lft --sao --vbv-maxrate 70000 --vbv-bufsize 16000 --crf 18 - "$(DestFile)"

x264 settings:

x264_10bpp --no-progress --profile high10 --preset veryslow --tune psnr --keyint 500 --min-keyint 1 --no-dct-decimate --no-deblock --non-deterministic --no-psy --vbv-maxrate 70000 --vbv-bufsize 64 --crf 18 --sar 1:1 --threads 18 -o "$(DestFile)" -

*EDIT* If you guys want me to make a sample recording of a game etc I can do that and I'll throw whatever settings you want at it, just built a new encoding server for lets plays.

*EDIT2* I never tune for animation, I find it ruins small details and just enhances edges

[sneaker_ger]

Same crf comparisons are useless, you need to do same bitrate. Watch for x264 bufsize error, 64 is too low to fit one frame so x264 will increase automatically. Watch for x265 maxrate error. (You've already been told not to use --tune-psnr)

--lft is not in doc, is it deprecated?

[ShamisOMally]

--lft is not in doc, is it deprecated?

*shrugs* I'm just trying to solve a mystery, I only really know x264 settings, not x265.

Also you've lost me on the whole "CRF is not a good indication of performance" because I thought x265's strength was it was supposed to be near half bitrate for same quality. And I was getting that, x265 CRF 18 was outputting at half the file size of x264. Well, until I cranked vbuffer up to insanity levels, but it still didn't get the same quality.

*EDIT* BBL after a sleep, taking parents to doctors tomorrow

[sneaker_ger]

CRF is not an absolute metric for quality. You cannot set x264 --crf 18 and x265 --crf and expect identical quality. You even confirmed it yourself: qualities varied even though you always used --crf 18.

I thought x265's strength was it was supposed to be near half bitrate for same quality.
Irrelevant (and often wrong)

[LigH]

--lft is not in doc, is it deprecated?

It is.

x265cli.h
{ "no-lft", no_argument, NULL, 0 }, /* DEPRECATED */
{ "lft", no_argument, NULL, 0 }, /* DEPRECATED */

param.cpp
OPT("lft") p->bEnableLoopFilter = atobool(value); /* DEPRECATED */

@ ShamisOMally: Do yourself a favour to use only parameters you understand; especially only if you are really sure that they must override preset defaults.
__

A first release with "multilib" EXE: x265 1.7+234-b1af4c36f48a (https://www.mediafire.com/download/m4464m18pk44o8b/x265_1.7+234-b1af4c36f48a.7z)

[ShamisOMally]

@ ShamisOMally: Do yourself a favour to use only parameters you understand; especially only if you are really sure that they must override preset defaults.


I use Mediacoder as the front end, it was something on I didn't know was on.

*EDIT1* Also more new to x265 than I am to VP9, which I've had months playing with perfecting its use/quality

[stax76]

A first release with "multilib" EXE: x265 1.7+234-b1af4c36f48a (https://www.mediafire.com/download/m4464m18pk44o8b/x265_1.7+234-b1af4c36f48a.7z)

This is very helpful because it removes the need of picking the right files and renaming the exe, also the compressed size is slightly smaller.

[LigH]

I'll still include DLLs in case anyone prefers to link them in an application... theoretically... does anyone?

I guess 7-zip will compress them all together good enough. If you want to ship only one EXE, decide for yourself whether or not to UPX it. And yes, UPX will probably have an easy job compressing two very similar libraries in one EXE.

[Atak_Snajpera]

Thanks for testing. It is time to dig deeper...

Can you at least compile whole set (x86/x64/8bit/10bit) of binaries with your patch?

[Barough]

A first release with "multilib" EXE

Thnx for the "multilib" EXE's. :)

[Ma]

Can you at least compile whole set (x86/x64/8bit/10bit) of binaries with your patch?

I did so in version 1.7+234
www.msystem.waw.pl/x265/

But I made only one EXE for 8 & 10-bit encoding -- multilib.

[Atak_Snajpera]

I did so in version 1.7+234
www.msystem.waw.pl/x265/

But I made only one EXE for 8 & 10-bit encoding -- multilib.

Is Main10 also supported?

http://i.cubeupload.com/Zzt6SD.png

[Ma]

Is Main10 also supported?

Yes, please add -D 10 option.

[LigH]

Yes, with the output depth parameter (-D 8|10).

I just ran a test with a high-res video (Tears of Steel, 60 seconds action) with almost the parameters of ShamisOMally:

--preset slow -D 10 --crf 18 --vbv-maxrate 70000 --vbv-bufsize 16000

To be honest ... I cannot imagine ***ing up parameters so badly that x265 would produce such a mess at CRF 18. Whatever these screenshots belong to, I doubt they belong to the documented parameter sets. My result of ToS was "visually transparent".

I wish I had a good cartoon scene to check it with. But still, I don't know any copyleft cartoon source with little quality loss.

[x265_Project]

x265 settings:

x265_10bpp --preset veryslow --profile main10 --level-idc 50 --tune psnr --pmode --pme --no-open-gop --keyint 250 --scenecut 40 --wpp --lft --sao --vbv-maxrate 70000 --vbv-bufsize 16000 --crf 18 - "$(DestFile)"

x264 settings:

x264_10bpp --no-progress --profile high10 --preset veryslow --tune psnr --keyint 500 --min-keyint 1 --no-dct-decimate --no-deblock --non-deterministic --no-psy --vbv-maxrate 70000 --vbv-bufsize 64 --crf 18 --sar 1:1 --threads 18 -o "$(DestFile)" -

*EDIT* If you guys want me to make a sample recording of a game etc I can do that and I'll throw whatever settings you want at it, just built a new encoding server for lets plays.

*EDIT2* I never tune for animation, I find it ruins small details and just enhances edges

The main problem: --vbv-maxrate 70000 --vbv-bufsize 16000

The artifacts you're seeing are related to rate control, specifically, VBV raising QP very high to limit the bit rate in order to comply with your VBV parameters. You are setting vbv-bufsize too low in comparison to vbv maxrate, and to a CRF 18 encode. The VBV algorithm has no room to work, and it's going to crush your video in complex scenes. VBV is meant to be used to limit peak bit rates in order to enable hardware decoders to function properly. If you're decoding your H.265 content on a PC (in software), you probably don't need to use VBV to limit bit rate peaks. If you really want to use VBV for your encodes, set VBV maxrate to some reasonable number (at least 1.5x, but more likely 2x your average bit rate), and VBV bufsize to a value that is greater than VBV maxrate (2x the maxrate is a good value).

When you use VBV maxrate and bufsize values that are out of line with your other settings, you will get bad results. If you want to see what's happening, turn on frame level logging (--csv logfilename.csv --csv-log-level 2), and you will see the QP values and frame sizes. Do this first for a CRF encode without VBV, then repeat the process with VBV, and you'll see the effect that VBV has on your encodes, frame by frame. You can plot the QP values on a spreadsheet to see when VBV takes effect, and you can plot the frame sizes or a moving average bit rate to see the effect on bit rate in complex scenes.

As others have mentioned, you should never use --tune psnr for any actual encodes that you intend to watch. This should only be used for PSNR measurements when you want to compare x265 PSNR measurements to another encoder.

[benwaggoner]

Yeah, strip everything out of those command lines other than preset and no-open-gop. They'll look a lot better and encode faster, particularly x265. Even on an 18-core/36-thread system pmode can slow things down and pme definitely will. The rest of the stuff in both either makes for invalid comparisons, hurts quality, or is already on by default at very slow.



Since you are running at 1080p, Level 4.0 is probably appropriate, and ample for perfect anime reproduction.



Comparing at the same bit rate is a good start. Using CBR (bitrate=maxrate, bufsize set 12000 in x265 and 31250 in x264) would be a good start since you can see local variance more easily. X265 does have the advantage of a bigger bufsize by the design. Maybe try 1000, 2000, 4000, and 8000?



Also, since you have an 8-bit source, I'd start with encoding 8-bit directly from the source decor (yuv420p in and out), which is easier to preview and gets preprocessing out of the equation.



There is additional quality tuning that can be done for each, but the above would be a good baseline without any content-specific tweaks.

[ShamisOMally]

Yes, with the output depth parameter (-D 8|10).

I just ran a test with a high-res video (Tears of Steel, 60 seconds action) with almost the parameters of ShamisOMally:

--preset slow -D 10 --crf 18 --vbv-maxrate 70000 --vbv-bufsize 16000

To be honest ... I cannot imagine ***ing up parameters so badly that x265 would produce such a mess at CRF 18. Whatever these screenshots belong to, I doubt they belong to the documented parameter sets. My result of ToS was "visually transparent".

I wish I had a good cartoon scene to check it with. But still, I don't know any copyleft cartoon source with little quality loss.

Actually, MOST of the movie was amazingly watchable, but that firefly scene, god damn it just turned into soup

*EDIT* If you guys are looking for something comparable to test with the same degree of "AHHH" in about 2 hours I'll do some high end 1080p 60FPS raw video samples of L4D2 Dark Carnival Stage 5, the fireworks going off on stage is probably the most brutal thing I've ever had to encode for youtube/webm's etc without raising the bitrate to insane levels to compensate, tons of white/yellow/red firework sparks in a dark stadium

*EDIT2* Sorry, going to be at least 3-4 hours. Encoding some lets play footage

[Ma]

I will surprise you ;) None of them work.

Good news is that I'm able to reproduce this bug on my 4-threads CPU. Normally x265 uses on my CPU only 2 frame threads, on your CPU -- 5. If I add -F 5 option, the stat file is corrupted.

Edit: After deep digging: the x265 source code is OK, GCC is OK, the bug is in MinGW-w64 fprintf function implementation. We can make workaround for this bug (restrict threads or use atomic function like fputs for example). I informed MinGW-w64 team about this issue
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/55520785/

[Selur]

Seeing that '--output-depth' over at https://x265.readthedocs.org/en/latest/cli.html?highlight=#cmdoption--output-depth only states 8 and 10 I was wondering if 12 and 16 bit encoding was abandoned.

[LigH]

Why abandoned? Rather not yet started; but why document an unimplemented feature? Someone could try to use it and complain that it does not yet exist, even though it was mentioned in the documentation... so better not even mention it as long as its implementation hasn't even started yet.

[Selur]

12bit and 16bit encoding did work last time I tested it, only the asm optimizations weren't up-to-date,...

[Ma]

x265 sometimes creates corrupted stat file

Finally I've made ultimate fix of this bug -- without any changes in source code. I turn off MINGW_ANSI_STDIO and link to msvcr120.dll (without MinGW extension use of msvcrt.dll is danger). It is working without any patches! So there is no bug.

www.msystem.waw.pl/x265/test3-Atak.7z

[LigH]

That means you created a new dependency to the Microsoft Visual C++ Runtime in a specific version, which people would have to install, even though the executable was not built by Visual Studio?

[stax76]

Atak could verify the VC++ 2013 runtime dependency in his installer like he does for Java and ffdshow, I do something similar. The original AviSynth+ installer includes both VC++ 2013 x64 and x86, I removed them both from my customized AviSynth+ installer and verify VC++ like all external tools and dependencies. With tweaks like this I brought my download size from 90 MB down to below 60 MB. There is a high chance that VC++ 2013 is already installed as it's currently the most popular version and if it's missing a app can easily guide the user to install it assuming the app can start without it, in case something is missing StaxRip shows it's apps dialog asking to install it:

http://thumbnails108.imagebam.com/41765/f9b9bb417643505.jpg (http://www.imagebam.com/image/f9b9bb417643505)

[Ma]

That means you created a new dependency to the Microsoft Visual C++ Runtime in a specific version, which people would have to install, even though the executable was not built by Visual Studio?

Yes, I replaced msvcrt.dll dependency to msvcr120.dll (they both are MSVC runtimes). msvcrt.dll start with Win95 OSR2 and it not even support C99 standard. It is a source of the problem.

I don't know which path is better: fix mingw-w64 and stay with msvcrt.dll or switch to msvcr100/110/120.dll.

[LigH]

Or third: Implement a custom stats file output routine to circumvent it... shooting sparrows with cannons?

[foxyshadis]

12bit and 16bit encoding did work last time I tested it, only the asm optimizations weren't up-to-date,...

Check again, >10bit doesn't exist in x265 yet, barring a couple of experimental builds for rExt. Are you sure you're not thinking of --input-depth, which dithers down to 10bit?

[Atak_Snajpera]

Ma Your earlier patch works fine so no need to mess with compiler options. x265 team should implement your workaround because without it gcc builds are semi broken. However it is iteresting why non gcc builds work fine...

[LigH]

@ Selur + foxy:

That's why I halted my reply so far. I knew there are routines for Main (8 bit) and Main10 (10 bit) HEVC profiles. I am not sure if there are finer resolutions for internal encoding parameters mentioned in HEVC specs, I only heard about it in theory so far but couldn't remember any specific implementation (of course not in assembler, but not even in C), and I also wondered if this would be even another HEVC profile if "Main10" is already so specific in its name.

@ Ma + Atak:

It would be a pity if non-Microsoft builds would require Microsoft DLLs. And this is only a workaround for Windows; what would you have to substitute if there were a similar issue only with GCC builds on Linux, assuming there are also other Linux compilers? I would hope for a mostly compiler independent solution which will certainly require understanding of the reason. But I fear it may require severe efforts and background knowledge in thread-safe development. A reply from the team will be welcome.

[sneaker_ger]

I also wondered if this would be even another HEVC profile if "Main10" is already so specific in its name.

Indeed there are lots of specific profiles.
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

[LigH]

So we can conclude: Only profiles "Main" and "Main 10" are implemented (to some extent) in x265 so far; implementation of other profiles (like "Main 12") is possible (and probably anticipated during the development of currently selected profiles), but not yet available.

Correct so far?

[x265_Project]

12 bit support is on our near-term roadmap.

I'm curious - do any of you have any real need for 12 bit HEVC (and do you have source video content that has at least 12 bits/color sample precision)? Or are you just interested in trying it?

[LigH]

Hey, there are also completely confident users of "placebo" presets. If I ever want to top that, I'll call my custom preset "homeopathic" (= "placebo forte"). :rolleyes:

No, getting real, I would not recommend to spend too much time on 12 bit precision now, as long as people still mourn about e.g. detail loss in hopelessly low bitrates.

[x265_Project]

Hey, there are also completely confident users of "placebo" presets. If I ever want to top that, I'll call my custom preset "homeopathic" (= "placebo forte"). :rolleyes:

No, getting real, I would not recommend to spend too much time on 12 bit precision now, as long as people still mourn about e.g. detail loss in hopelessly low bitrates.

I hear you, but we have paying customers who insist that we focus on certain things in our development roadmap, and one of these things is support for 12 bit precision. This isn't for consumer video applications. It's needed for storing or delivering pro video in the highest possible quality.

For consumers, HEVC with more than 10 bits of precision might be applicable for still image compression.

[kolak]

12 bit support is on our near-term roadmap.

I'm curious - do any of you have any real need for 12 bit HEVC (and do you have source video content that has at least 12 bits/color sample precision)? Or are you just interested in trying it?

You can find footage which was shot/processed and final delivered at 12bit. It will be mainly some film content, but even this quite often ends up just 10bit. Current film pipes are based on 32bit float EXR format, so if source comes from very good camera than there may be real 12bit info in final master, but someone could question it. High-end cameras store raw data at 10-16bit, but it's not that obvious that data there has real 12bit. Viewing it is yet another story.

[MeteorRain]

I'm curious - do any of you have any real need for 12 bit HEVC (and do you have source video content that has at least 12 bits/color sample precision)? Or are you just interested in trying it?

Interested in how much more efficiency 12 bit can bring us, especially on animations.

[foxyshadis]

12- and 16-bit are more for video grading, medical imaging, that sort of application, where you want the flexibility to wildly change the dynamic range between the captured and the final version. In video, ProRes all but owns this space right now, with its 12-bit 444+4 codec, like Cineform and DNxHD before it, so there's still a very substantial market to crack into. For deep images, JPEG2000 is still the dominant format.

For fully graded end-user video, the size or quality difference between 10- and 12-bit would be vanishingly small. Your monitor is the limiting factor.

[benwaggoner]

Interested in how much more efficiency 12 bit can bring us, especially on animations.
I doubt any 8-bit was at about the perceptual threshold, and sometimes not enough. For Rec. 709, 10-bit is ample.

Also, very little cel animation has been created at >10-bit anyway. Maybe a few films from the last decade, and recent remasters of old film sources.

Maybe if there is HDR animation some day, a 12-bit PQ curve would be better than 10-bit PQ. But I've never heard even a rumor of anyone even contemplating high dynamic range cel animation.

[nandaku2]

@ Selur + foxy:

That's why I halted my reply so far. I knew there are routines for Main (8 bit) and Main10 (10 bit) HEVC profiles. I am not sure if there are finer resolutions for internal encoding parameters mentioned in HEVC specs, I only heard about it in theory so far but couldn't remember any specific implementation (of course not in assembler, but not even in C), and I also wondered if this would be even another HEVC profile if "Main10" is already so specific in its name.

@ Ma + Atak:

It would be a pity if non-Microsoft builds would require Microsoft DLLs. And this is only a workaround for Windows; what would you have to substitute if there were a similar issue only with GCC builds on Linux, assuming there are also other Linux compilers? I would hope for a mostly compiler independent solution which will certainly require understanding of the reason. But I fear it may require severe efforts and background knowledge in thread-safe development. A reply from the team will be welcome.

Ma had identified the root cause of the issue on the issue tracker - fprintf is not thread safe as implemented on MingW. We will replace this with sprintf and fputs. POSIX requires stdio to be atomic, and MSVCRT file operations are also always thread safe. So, this problem is restricted to MingW afaik.

[LigH]

Weekly: x265 1.7+257-483c85f83f07 (https://www.mediafire.com/download/8903gq836zvpc8c/x265_1.7+257-483c85f83f07.7z) (as usual: MSYS/MinGW, GCC 4.8.2)

[hector1980]

hi i was wondering that what app is the best for encoding hevc x265 and offers more settings and abilities like for example what MEgui is doing for x264 i will appreciate if you could help me... tnq

[stax76]

hi i was wondering that what app is the best for encoding hevc x265 and offers more settings and abilities like for example what MEgui is doing for x264 i will appreciate if you could help me... tnq

StaxRip and Hybrid have a rich x265 GUI and generally many advanced options.

[mandarinka]

Hey, there are also completely confident users of "placebo" presets. If I ever want to top that, I'll call my custom preset "homeopathic" (= "placebo forte").

You know, at least in x264, placebo isn't really *placebo* at all. You can test it with metrics and it will give you better results than veryslow.

For example, --no-fast-pskip IIRC only gets used in preset placebo, and just that option has noticeable impact visually. Not saying you will spot it when playing back, but comparing stills I think it is fairly conclusive that it helps.

Not sure --me tesa helps much (and --subme 11 probably doesn't), but just going --preset placebo --me umh --subme 10 is going to be better than veryslow and I would recommend it when slower speed is not a problem.

(You can probably get some real improvement when going to parallel --threads 1 encodes over a single encode with automatic thread count on a machine with lots of cores and HT - say 36 threads on a 1280x720 video is probably fairly suboptimal. But that is beyond the scope of presets.)

[LigH]

If you know exactly why, then go on and use all the parameters you like. But if you believe that more efforts automatically mean more quality, then you are probably just wasting time and energy, and will enlarge your CO2 footprint. :rolleyes:

[kolak]

I doubt any 8-bit was at about the perceptual threshold, and sometimes not enough. For Rec. 709, 10-bit is ample.

Also, very little cel animation has been created at >10-bit anyway. Maybe a few films from the last decade, and recent remasters of old film sources.

Maybe if there is HDR animation some day, a 12-bit PQ curve would be better than 10-bit PQ. But I've never heard even a rumor of anyone even contemplating high dynamic range cel animation.

There are some animation based projects in progress from big boys and these are one of the first which may have special HDR version. Of course I can't say more. Dolby is working hard to push their HDR technology- not only for pro, but home market also.

[LigH]

"Merge with stable" and working CPU features identification for alternative encoder libraries (i.e. -D 10 -V warns about "noasm" option for Win32 builds in multilib EXE as well as 8-bit EXE with 10-bit DLL):

x265 1.7+266-68d089360477 (GCC 4.8.2) (https://www.mediafire.com/download/ykww46evv72k606/x265_1.7+266-68d089360477.GCC482.7z)
x265 1.7+266-68d089360477 (GCC 4.9.2) (https://www.mediafire.com/download/omxapjqcgoa2m2q/x265_1.7+266-68d089360477.GCC492.7z)

[ShamisOMally]

Shit, I got hyper distracted by IRL shit (Friends dying) I lost track of making the exports of raw footage for L4D2 for encode examples.

I'll do that in a few hours. Sorry guys!.

*EDIT* https://www.mediafire.com/?58huw703ap5o0c6 Fireworks scene in L4D2, probably one of the best sources I ever found for testing video compression quality

[LigH]

My condolences.

And thank you for the useful material. Game recordings are special.

[LigH]

12bit and 16bit encoding did work last time I tested it, only the asm optimizations weren't up-to-date,...

Meanwhile, some first patches to prepare a future 12-bit encoder implementation got submitted ... To me, they appear only like some sort of placeholders yet; but there is a beginning.

[ShamisOMally]

https://www.mediafire.com/?5o49wbitxjei681

Ok last raw file example, this one of Planetside 2

This is yet another game I find that if I encode it at the typical 7-8K bitrate that youtube puts out, it gets absolutely mangled quality wise

This and L4D2 seem to have the biggest issues when it comes to clarity and encoding bitrates vs other games

I hope you guys find these useful, both games I use in order to test stream settings/youtube encode settings for uploads

[dipje]

just as a quick-n-dirty test to see how it went, tried that Fireworks source ('source', 40mbps h264? From NVENC or something?) through x264.

Just a simple 'core.ffm2.Source' vapoursynth script into x264 8bit, crf 23 quickly ended up being 23mbps. (--preset slow --tune animation --crf 23).

Added a dirty 'anti alias' method (surely not perfect) to get rid of a bit of the extreme sharpness from captured game footage (although having 420-8bit-40mbps as source it probably lost a lot already).

nnedi3_rpow2 to scale up, sangnommod, transpose, sangnomod, transpose, bilinear size back to 1920x1080.

Encoding that into x264 (--preset slow --tune animation --crf 32) at _32_ CRF finally ended up being an average of 6mbps at the end and it's good watchable. I would not call it mangled at all, although in still frames it will probably show it's ugly face.
Doing a crf-30 now to see if that ends up being roughly at the 8mbps average 'challenge' point.

Challenging footage to be sure, I wonder what x265/hevc will make it of it at end. Will do some tests next.

[ShamisOMally]

Its from an ElgatoHD 60, and it actually handles L4D2 quite well at 40MBit

Planetside 2 however? Absolutely exhausts 40Mbit, just look at the sky and the macroblock artifacts banding between blue/purple. But then again, Blue/purple transition has been encodings achilles heel since day one.

You can easily spot it running out of bandwidth when you look through the night vision scope, the bands of macroblock errors in the purple/blue there.

Again these are the only two games I've ever had look less than perfect with the ElgatoHD 60, but you can see by the weirdly insane amount of random detailing on screen its no wonder why.

[LigH]

WARNING! HIGHLY EXPERIMENTAL!

By manually patching the file linklibs.rsp I was able to build x265 v1.7+282 not only as separate specific EXE and DLL files, but also as a multilib EXE (which is untested except for the point that it reports a meaningful version string) with 8 bit, 10 bit, and 12 bit encoders.

:scared: — :cool:

Now I wonder if I should release it at all...

[dipje]

I ended up with a simple --preset slow --tune animation --crf 30 for x264 with a filtered version of your source (filtered as I described early, upscale, sangnommod, rotate, sangnommod, rotate back, bilinear scale back to full-hd).
The videostream ended up being +/- 7600 kbps average at the end (crf is of course not comparable to the constant 8mbps Youtube probably does :)).

Not being up2date on current x265 settings and the like, took LigH's latest compile (1.7+266) with --preset slow --crf 26, nothing else on the command line. Videostream ended up being +/- 8700 kbps and to be honest, I think I enjoy the x264 version more. With the sudden jerky gameplay action they are both very watchable though.

Both handle the fireworks well and keep it pretty detailed / good in motion, but the bits spent on the fireworks mean detail is lost somewhere else. The other most important parts of gameplay footage I think are the HUD and the gun/item held in first person in front of the player. Both versions do fine. But I keep noticing that x264 manages to keep more 'detail' on the face of Coach around the 2-second mark (where he pulls / reloads his guns) while the x265 version has more noticeable blur there, even in high 60fps motion.

Like I said, I'm not up2date on the latest settings that are best for this kind of thing and the bitrates aren't matched very well, so this is NOT a fair shoot out or anything close :). But it does show that x265 has some problems with this footage that x264 does better. It's not about detail retention directly, both handle the fireworks well. But x265/hevc seems to have too little bits left over on some other parts. Well, it's CRF so it can use all the bits it wants. So x265/hevc seems to think the head of Coach at the early point is not detail worth saving or something.

[LigH]

With so little "bitrate per pixel and frame", both encoders need to suppress a lot of information. Which approach appears more or less annoying to you, is specific to you. But yes, it may depend on the material as well. You are probably right that the fireworks effect draws a lot of bitrate from the rest of the content. How much from where, will be the difference between AVC and HEVC in general already.
_

P.S.: New samples (https://www.mediafire.com/folder/ldwl20fppplbx/samples) with a downscaled "L4D2 Fireworks" clip (640x360) in 8 (https://www.mediafire.com/download/305tak1cu7uvdem/Fireworks_360_medium.hevc.mp4) / 10 (https://www.mediafire.com/download/biljcp8rc51p8rj/Fireworks_360_medium.10bit.hevc.mp4) / 12 (https://www.mediafire.com/download/xvx3ktu13d2b3lg/Fireworks_360_medium.12bit.hevc.mp4) bit encoding resolution.

LAV Filters can't play the 12 bit sample correctly. I guess it is not yet supported?

And here the experimental build: x265 1.7+282-1867f1703846 (https://www.mediafire.com/download/2d9kjgc5cbtx032/x265_1.7+282-1867f1703846.GCC492_EXP.7z) (GCC 4.9.2)

[ShamisOMally]

Yeah that's the same conclusion I keep coming to when I do my HEVC encodes, having since gone back to X264 for my own personal collection. Yeah its bigger but when it comes to things as fine detail AVC tends to keep fine details far better, even if HEVC on average is far smaller.

But like I saw like Dipje saw in order to do high motion scenes with insanely high amounts of detail HEVC needs a lot more bitrate to compensate, and still doesn't do as good a job.

The reason I remembered these two games and how they get butchered by encodings is from days ago with my Atlantis: The Last Empire findings a few days ago, where HEVC just destroyed the firefly scene. It only worked after I gave it an insanely high buffer to play with.

[qyot27]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.

[nevcairiel]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.

Should be able to remove it by now I would think. I'll inquire!

[Ma]

Ma Your earlier patch works fine so no need to mess with compiler options. x265 team should implement your workaround because without it gcc builds are semi broken. However it is iteresting why non gcc builds work fine...

The earlier patch is wrong because it change not buggy code.

We should patch code that is really buggy -- mingw-w64 stdio implementation (see attached diff file). With the newest patch all mingw printf functions (printf, vfprintf, fprintf, ...) are atomic and threads safe.

You can test sample x265 builds with patched mingw_pformat.c file (linked to old msvcrt.dll):
www.msystem.waw.pl/x265/test4-Atak.7z

[qyot27]

I kind of wonder when the -strict -1 restrictions on encoding 4:2:2 or 4:4:4 with libx265 through FFmpeg will go away, since x265 CLI no longer throws the warning about it.
I realize I made a slight typo. It's actually -strict -2 (experimental), not -strict -1. I was confusing it with the extended y4m restrictions when piping into x265.

Although the point that it's restricted at all still stands.

[Ma]

https://www.mediafire.com/?58huw703ap5o0c6 Fireworks scene in L4D2, probably one of the best sources I ever found for testing video compression quality

I encoded this sample to 12-bit HEVC with options:
--preset slower --crf 27.0 -D12 --no-asm --deblock -2

It is smaller (68.2 MB instead of 116 MB) and still watchable.

It looks like that without --no-asm option x265 12-bit encoding is pure crap.

[LigH]

Interesting. So the assembler routines for the encoder are probably not correct yet. I'll check that too and then mention it in the developer mailing list. Still ... a reference decoder or internal reconstruction will possibly be more reliable than usual players?

[foxyshadis]

Cool, no more need to make the dll on windows; the exe now exports the full library as well. (The commit message says to change the filename to do so, but LoadLibrary() doesn't care what it's named.)

[LigH]

In theory, it would be very convenient to have one "All In One" binary; in practice, I did not yet manage to build it. With v1.7+298, I still get either a DLL with export chapter, or an EXE without export chapter (at least Microsoft PE Scanner can't find any; PE Tools' readpe also reports: "export directory not found").

[foxyshadis]

It works for me, but I think you have to enable cli and shared (so the dll still gets built even though the exe has the exports).

[LigH]

I did so, even explicitly. PE Scanner (http://sourceforge.net/projects/pescanner/) detects "Export(fn)" (see bottom) only in the DLL, but not in the EXE. The tool "readpe" in pev (http://sourceforge.net/projects/pev/) logs the PE structure to stdout and reports several exports from the DLL (even though the names appear wrong) but prints "export directory not found" on stderr while analyzing the EXE.

I had to modify the sample script from the x265 project slightly: It did not care about a 32 bit build requiring to disable assembly for HBD libraries, and did not care about using the cross-compile toolchain for x64 target on x86 MSYS/MinGW32 either. In addition, I prefer to clean the project from generated files because I usually need to rebuild it completely.

multilib32.sh
#!/bin/sh

mkdir -p 8bit 10bit 12bit

cd 12bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=OFF -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=OFF -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DWINXP_SUPPORT=ON -DENABLE_ASSEMBLY=ON -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF\
-DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make ${MAKEFLAGS}
# linebreak escape for forum layout saving only!

multilib64.sh
#!/bin/sh

mkdir -p 8bit 10bit 12bit

cd 12bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON
make ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make clean-generated
cmake -G "MSYS Makefiles" ../../../source -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF\
-DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make ${MAKEFLAGS}
# linebreak escape for forum layout saving only!

Did I make a mistake with the explicit sets of parameters?

Would you like to have my binaries to compare?

P.S.: Did you use MSVC? It may be possible that linking EXE with exports currently works only with MSVC the way it was implemented, but not with GCC. Investigating further...

[LigH]

It appears that export definitions via x265.def were provided only if MSVC was used. Expanding this clause in the CMakeLists.txt template to (MSVC OR GCC) enabled GCC to build an EXE with exported funcions too.
__

Here are the first "All-In-One" x265.exe v1.7+298 which could also be linked as if they were DLLs (in theory yet, to be tested):

x265 1.7+298-523540864864 AIO (GCC 4.8.2) (https://www.mediafire.com/download/mo0338nxxlc77f6/x265_1.7+298-523540864864_AIO.GCC482.7z)
x265 1.7+298-523540864864 AIO (GCC 4.9.2) (https://www.mediafire.com/download/w5w91t6c833b35e/x265_1.7+298-523540864864_AIO.GCC492.7z)

[Ma]

I compare x265 builds linked to old msvcrt.dll with linked to new msvcr120.dll.

265-AVX means build linked to old msvcrt.dll with option -march=corei7-avx
AVX-120 means build linked to new msvcr120.dll + option -march=corei7-avx
265-GEN means generic build linked to old msvcrt.dll
GEN-120 means generic build linked to new msvcr120.dll

Platform: Win 7 64-bit, CPU i5 3450S
Options: -D10 --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709

Result (encode time in seconds):

fast medium slow slower verysl placebo
265-AVX 93,71 139,66 163,27 163,39 161,46 165,18
AVX-120 93,43 138,94 162,57 161,89 160,76 163,88
265-GEN 94,09 140,47 163,51 163,97 161,87 166,05
GEN-120 93,64 139,95 163,20 163,89 161,13 165,25


There is interesting that builds linked to new msvcr120.dll are faster even with slow presets. There is close battle between 265-AVX vs. GEN-120.

Full results & batch file used to test attached.

[Ely]

Have you guys figured out good parameters for high quality sources such as 1080p blurays ? From my tests, 6mbps seems to be a threshold after which x264 -tune film will be better overhaul than x265 with the same bitrate. For now I have much better results with "aq-strength=1.2:qcomp=0.5:psy-rd=0.5:deblock=-1", but it still doesn't match x264.

[benwaggoner]

Have you guys figured out good parameters for high quality sources such as 1080p blurays ? From my tests, 6mbps seems to be a threshold after which x264 -tune film will be better overhaul than x265 with the same bitrate. For now I have much better results with "aq-strength=1.2:qcomp=0.5:psy-rd=0.5:deblock=-1", but it still doesn't match x264.

Can you share your full command lines for both x264 and x265 for this comparison?

Try adding --qf-mode 32 --aq-mode 2 --aq-strength 2.0. Sometimes --ipratio 1.3 --pbratio 1.2 can help.

I think a good community project would be to figure out recommended --tune film and --tune animation presets for x265. We already have grain, zerolatency, and fastdecode.

[Boulder]

There are still the old problems pointed out by several of us, the x265 devs have not yet addressed them. My old bug report is on "major" priority but I think they have some more urgent (=sponsor demands) matters to handle first.

https://bitbucket.org/multicoreware/x265/issues/122/loss-of-details-compared-to-x264

[stax76]

Sponsor demands were mentioned before but think about it, there could be several other reasons.

[Ely]

Can you share your full command lines for both x264 and x265 for this comparison?

Try adding --qf-mode 32 --aq-mode 2 --aq-strength 2.0. Sometimes --ipratio 1.3 --pbratio 1.2 can help.

I think a good community project would be to figure out recommended --tune film and --tune animation presets for x265. We already have grain, zerolatency, and fastdecode.

Sure. X265 :

ffmpeg -i input.mkv -t 10 -vcodec libx265 -preset veryslow -b:v 7M -x265-params pass=1:colorprim=bt709:colormatrix=bt709:transfer=bt709 -an -f hevc NUL
ffmpeg -i input.mkv -t 10 -vcodec libx265 -preset veryslow -b:v 7M -x265-params pass=2:colorprim=bt709:colormatrix=bt709:transfer=bt709 -an out-x265-vanilla.mkv

X264 :

ffmpeg -i input.mkv -t 10 -vcodec libx264 -preset veryslow -tune film -b:v 7M -pass 1 -x264-params colorprim=bt709:colormatrix=bt709:transfer=bt709 -an -f h264 NUL
ffmpeg -i input.mkv -t 10 -vcodec libx264 -preset veryslow -tune film -b:v 7M -pass 2 -x264-params colorprim=bt709:colormatrix=bt709:transfer=bt709 -an out-x264-film.mkv

Here's a screenshot comparison between x264 and x265's outputs from the above commands :

http://screenshotcomparison.com/comparison/134774

Source is a Luther 1080p25 bluray I own, which I ripped without re-encoding.

I then added the following to x265 :

aq-strength=1.5:qcomp=0.5:psy-rd=1.0:deblock=-1:aq-mode=2

And here is a screenshot between x265-vanilla and x265-tuned :

http://screenshotcomparison.com/comparison/134776

It's a bit better but still far from the x264 output. I tried setting qg-size=32 and aq-strength=2.0 like you said, but the result doesn't look any different really.. The lines on the girl's shirt are still as blurry for example.

[RainyDog]

Here's a screenshot comparison between x264 and x265's outputs from the above commands :

http://screenshotcomparison.com/comparison/134774

Source is a Luther 1080p25 bluray I own, which I ripped without re-encoding.

And here is a screenshot between x265-vanilla and x265-tuned :

http://screenshotcomparison.com/comparison/134776

It's a bit better but still far from the x264 output. I tried setting qg-size=32 and aq-strength=2.0 like you said, but the result doesn't look any different really.. The lines on the girl's shirt are still as blurry for example.

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

[Ely]

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

The shirt definitely looks much better in the x264 version (imho). It's so much sharper and detailed (again, imho :) ).

Same goes with the hair, the eyelashes, her face..

I'll do a deblock -3 and keep you updated.. I'll also post a comparison with the source.

EDIT :

Source vs x264 : http://screenshotcomparison.com/comparison/134805
Source vs x265 : http://screenshotcomparison.com/comparison/134807
Source vs x265 deblock -3 : http://screenshotcomparison.com/comparison/134809

deblock -3 doesn't seem to cut it either I'm afraid. I didn't notice at first, but x264 applies kind of a light sharpen filter over the source.. I still prefer that to x265's blurring though.

EDIT 2 :

Soo.. I went ahead and applied a light sharpen filter before encoding with x265 (vanilla settings).

Source vs sharpen/x265 : http://screenshotcomparison.com/comparison/134812
x265 vanilla vs sharpen/x265 : http://screenshotcomparison.com/comparison/134813

I really like the results here ! I've found a good compromise for my encodes.

[Barough]

In the end so is it always up to each person to say what they think looks best in the end but it's always good to get feedback/input into settings etc.

A friend of mine is working in the video encoding business and he have tried 2 help me with a good general custom command line to get the final 'tweaks' in there but it's not easy since sometimes we think different things looks good etc. Then there is the case of what monitor etc. you viewing your encode on. There is many aspects in the end that have to be counted in.

[CruNcher]

But which is closer to the source?

I'm not really seeing any alarming differences between the the x264 and x265 outputs really. Certainly wouldn't call the x265 output far from x264 nor the girl's shirt blurry as such.

If anything, I'd say the x264 just looks slightly rougher with more blocking and banding and x265 looks like it's applying more aggressive deblocking. Which may or may not be a good thing depending on the source I suppose.

Can you try setting deblock to -3 in x265?

Really nice to see x264 HVS tuneing still holding up so amazingly (for now) especially if you count the decoding complexity Ratio :)

The shirt definitely looks much better in the x264 version (imho). It's so much sharper and detailed (again, imho :) ).

Same goes with the hair, the eyelashes, her face..

I'll do a deblock -3 and keep you updated.. I'll also post a comparison with the source.

EDIT :

Source vs x264 : http://screenshotcomparison.com/comparison/134805
Source vs x265 : http://screenshotcomparison.com/comparison/134807
Source vs x265 deblock -3 : http://screenshotcomparison.com/comparison/134809

deblock -3 doesn't seem to cut it either I'm afraid. I didn't notice at first, but x264 applies kind of a light sharpen filter over the source.. I still prefer that to x265's blurring though.

EDIT 2 :

Soo.. I went ahead and applied a light sharpen filter before encoding with x265 (vanilla settings).

Source vs sharpen/x265 : http://screenshotcomparison.com/comparison/134812
x265 vanilla vs sharpen/x265 : http://screenshotcomparison.com/comparison/134813

I really like the results here ! I've found a good compromise for my encodes.

I would say the additional CPU cycles you threw in for the additional external sharpening pass wasn't really worth it, the difference is so marginal i doubt that even in motion you would realize the difference in anyway ;)

[birdie]

I for one prefer x264/x265_with_sharpening - everything looks sharper and clearer. Not meaning to sound harsh or offensive but are you eyes and displays OK? Cause the difference is humongous.

[CruNcher]

Yeah see the difference now noscript blocked the js

http://screenshotcomparison.com/comparison/134833

what predicts the uncompressed source input the most accurate (not the blu-ray source) is the question ;)

looking @ the deconvolution effect on the Depth of Field you can start to argue here ;)


http://screenshotcomparison.com/images/1436688946_3760491582.png
http://screenshotcomparison.com/images/1436702963_1364025978.png
http://screenshotcomparison.com/images/1436702962_8761439502.png


@Ely

Could you upload a sample of both results x264/x265 before the Depth of Field, when she gets down to the baby and most probably the DOF sets in and then after the Baby scene a bit (she moves up again ?) thx

My Personal Preference for the spatial result would be the x264 one even with that small deconvolution on the DOF which might be even a good thing, that we don't know exactly :)

http://screenshotcomparison.com/images/1436702963_1364025978.png

Though we don't watch Video/Movies spatial but temporal and in the end only the superiority in motion and how that is overall perceived really count's

[Ely]

Yeah see the difference now noscript blocked the js so nice would be also comparing x264 plain hvs vs sharpen h.265 ;)

What do you mean by "x264 plain hvs" ?

Could you upload a sample of both results x264/x265 before the Depth of Field, when she gets down to the baby and most probably the DOF sets in and then after the Baby scene a bit (she moves up again ?) thx

I'll try to get it up when I'm home :) .

[benwaggoner]

If you want sharper, you could try increasing psy-rdoq. That can increase apparent noise and detail retention. Too much can wast a lot of bits. A little --nr-inter can help improve detail at a given bitrate by shifting bits from random noise to static or predicted edges.


-Ben Waggoner (via TapaTalk)

[LigH]

Another "comprehensive" weekly build:

x265 1.7+338-8023786c5247 (GCC 4.8.2) (https://www.mediafire.com/download/982yaxtz6w62mkx/x265_1.7+338-8023786c5247.GCC482.7z)
x265 1.7+338-8023786c5247 (GCC 4.9.2) (https://www.mediafire.com/download/en2zcc8du27afp7/x265_1.7+338-8023786c5247.GCC492.7z)

[CruNcher]

Im currently testing Nvidias HEVC Encoder vs x265

i really wonder if Nvidias SIP Core is based on Vanguards IP http://www.vanguardvideo.com/

Not officially

[Ely]

Im currently testing Nvidias HEVC Encoder vs x265

Would love to see some results ! Their HEVC encoder on the Tegra X1 can do 4K30 in real time, probably gonna be the same with the encoder on their graphics cards. I have a feeling the quality won't be that good though, as with any hardware encoder..

Sorry about the screens I didn't post, there weren't the scenes you talked about and I've moved on to other things ^^ .

[benwaggoner]

Would love to see some results ! Their HEVC encoder on the Tegra X1 can do 4K30 in real time, probably gonna be the same with the encoder on their graphics cards. I have a feeling the quality won't be that good though, as with any hardware encoder.
Yeah, I'd be interested in seeing this. x265 was able to do 2160p30 on a dual-socket Broadwell system several months ago, so we could have a quality comparison. I think Elemental has already demoed 2160p60 live as well.

[LigH]

@ foxy etc.: Can you confirm that zones don't work for n-pass, --pass 3|2?

[RainyDog]

If you want sharper, you could try increasing psy-rdoq. That can increase apparent noise and detail retention. Too much can wast a lot of bits. A little --nr-inter can help improve detail at a given bitrate by shifting bits from random noise to static or predicted edges.

Is psy-rdoq basically the equivalent of x264 psy-rdo?

Was thinking that the sharper x264 image between the x264/x265 comparison Ely made could be partly attributed to --tune film being used which adds psy-trellis in x264. And even a tiny amount of psy-trellis increases sharpness quite a bit.

[CruNcher]

It's a combination of different things the visual impression doesn't just come from 1 specific setting ;)

Nvidias H.265 Hardware Encoder isn't that bad @ all and they still working on more features it looks much better then the begining of their H.264 FreXt Encoder and Performance is comparable to the H.264 Hardware part so the Parallel Redesing seems to have really helped here :)
It still loses High Frequency Details of course a lot and bitrate doesn't really matter in that case @ all.

I guess it would be absolute Game Recording Ready even in it's current state.

Especially hard it becomes to further compress down VC-1 with adaptive deadzones and it's nice Grain Retention ;)

Also Nvidia has revealed that they can programm this thing partly it's not entirely fixed function :)

they revealed the underlying firmware that is loaded by the driver ;)

Also that a external Motion Compensation mode will be released for utilization of their Hardware Motion Estimation :)

[Marsu42]

I hope one of you encoding wizards is nice enough to answer a simple usability question :-) ...

... I want to *limit* the threads x265 uses (default 2 physical cores w/ hyperthreading) to prevent my laptop burning a hole into my desk. Unfortunately, the docs (https://x265.readthedocs.org/en/default/threading.html) are way over my head other than the simpler x264 parameters of the olden days :-o

Question: How do I limit the threads used to (mostly) 2?. Some less cpu intensive lookahead or the like can use the other 2 cores, but I want to limit the hardcore encoding work that maxes out the cpu.

Disclaimer: I know there are other ways of doing this like affinity, but I'd like a nice command line approach I can feed to handbrake.

Thanks for any hints!

[x265_Project]

I hope one of you encoding wizards is nice enough to answer a simple usability question :-) ...

... I want to *limit* the threads x265 uses (default 2 physical cores w/ hyperthreading) to prevent my laptop burning a hole into my desk. Unfortunately, the docs (https://x265.readthedocs.org/en/default/threading.html) are way over my head other than the simpler x264 parameters of the olden days :-o

Question: How do I limit the threads used to (mostly) 2?. Some less cpu intensive lookahead or the like can use the other 2 cores, but I want to limit the hardcore encoding work that maxes out the cpu.

Disclaimer: I know there are other ways of doing this like affinity, but I'd like a nice command line approach I can feed to handbrake.

Thanks for any hints!
You can do this by adding --pools 2 to your command line. See http://x265.readthedocs.org/en/default/cli.html#cmdoption--pools

[Marsu42]

You can do this by adding --pools 2 to your command line.

Right, thanks - I've read the docs, but you did your very best to make it as generic (i.e. complicated) as possible and I didn't get the pools are equivalent to threads for a non-numa non-whatever system :-p

[Ely]

Also Nvidia has revealed that they can programm this thing partly it's not entirely fixed function :)

From what I heard, at least on the Tegra X1, the encoder uses cuda cores and most of the "intelligence" is done in software.

[CruNcher]

it would clash with the 3D rendering (D3D,OpenGL) but it doesn't in terms of latency it's always the same it is a separated engine but not as fixed as a normal DSP architecture they can split tasks they have more headrooms same for Intel (Quicksync) or AMD (VCE)

the CUDA Shader based H.264 Encoder still works and it clashes with the 3D Rendering i will look more closely @ which nodes get actually utilized for both, especialy looking what happens using both @ the same time ;)

[x265.cc]

my buildbot is back (automated GCC 5.2.0 / YASM 1.3.0 builds):


https://encoder.pw/x265/


webfrontend will be back soon too.

As always: don't trust any foreign binaries.

need something more experimental? https://encoder.pw/daala/

[Ely]

it would clash with the 3D rendering (D3D,OpenGL) but it doesn't in terms of latency it's always the same it is a separated engine but not as fixed as a normal DSP architecture they can split tasks they have more headrooms same for Intel (Quicksync) or AMD (VCE)

the CUDA Shader based H.264 Encoder still works and it clashes with the 3D Rendering i will look more closely @ which nodes get actually utilized for both, especialy looking what happens using both @ the same time ;)

You're right, my source for this info wasn't 100% trustworthy so it was probably at least half-wrong ^^ . Wouldn't surprise me that *some* cuda cores are used but there's definitely some silicium dedicated to the encoder.

[Parabola]

Yeah, I'd be interested in seeing this. x265 was able to do 2160p30 on a dual-socket Broadwell system several months ago, so we could have a quality comparison. I think Elemental has already demoed 2160p60 live as well.

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?

Fraunhofer HHI showed proprietary real-time 2160p50 8-bit last year at IBC on standard server architecture. They admitted coding performance falling short of HM.

Nvidia / HW encoding is a very welcome addition to the ecosystem but precedent suggests it may underperform.

[benwaggoner]

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?
I don't remember the exact specifics. MultiCoreWare should have the info. I'm sure things have gotten faster since then.
[/QUOTE]

[x265_Project]

Interesting - are these 8-bit or 10-bit? How far off the compression performance asymptote do you have to go to get this throughput? Preset ultra fast? BD-rate loss perhaps worse than best H.264 performance on same hardware?

The demo we gave at NAB used an application that we (MulticoreWare) have built called UHDkit. This application utilizes the same x265 HEVC encoder library that is available to everyone under the GPL v2, but it has additional capabilities at the application layer. The demo involved 4K, 10 bit encoding at 10 Mbps, using the ultrafast preset, on a dual Xeon E5-2699 v3 (18 cores, 36 threads) @ 2.3 GHz. To achieve higher effective utilization and overall throughput on a 36 core, 72 thread machine, UHDkit was running multiple instances of x265 in parallel. We achieved 88 FPS+, but that was with an older version of x265 (1.6+184). We can achieve higher throughput today, and we're still working hard to improve performance.

As far as the encoding efficiency of x265 vs. x264, anyone can run tests to compare subjective visual quality or rate distortion curves. Using the ultrafast preset, objective quality measurements usually show something comparable to x264's best (veryslow) encoding quality, but this varies quite a bit, depending on the content. Ultrafast is a go-fast preset which trades efficiency for speed in almost every way possible. Our goal for real-time encoding scenarios is to provide the performance required to enable customers to use higher quality settings while maintaining real-time frame rates (for example, our medium, fast or faster presets).
http://www.multicorewareinc.com/wp-content/uploads/2015/04/x265_88FPS.jpg

[708145]

The demo involved 4K, 10 bit encoding at 10 Mbps, using the ultrafast preset, on a dual Xeon E5-2699 v3 (18 cores, 36 threads) @ 2.3 GHz.[/IMG]

What frequency did the Xeon run at during the encode? I assume during heavy AVX2 work it doesn't clock much higher, but we've seen some surprises in our tests with a 2x18core Haswell: It went up to 3.6GHz during node.js tests, averaging 3.4GHz.

If your scaling is memory bandwidth limited try deactivating selected cores. The chip will use the headroom automatically and increase minimum frequency.

[LigH]

NUMA, NUMA, yeah!

[LigH]

Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).

x265 1.7+371-24c1ee516d13 (GCC 4.8.2) (https://www.mediafire.com/download/p507695nox57zl2/x265_1.7+371-24c1ee516d13.GCC482.7z)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2) (https://www.mediafire.com/download/kybwwdvv1a12r87/x265_1.7+371-24c1ee516d13.GCC492.7z)

And some results to compare:

8 bit (https://www.mediafire.com/download/dvdbaspl6cv5oqy/tos_60s_720p_main.hevc.mp4) | 10 bit (https://www.mediafire.com/download/01r7znyrcmuus42/tos_60s_720p_main10.hevc.mp4) | 12 bit (https://www.mediafire.com/download/b823w1rhu1hb8zd/tos_60s_720p_main12.hevc.mp4) (each ~6..7 MB, only default parameters except bit depth)

[shinchiro]

I'm not sure if this is bug or not but I can see "warping" effect when panning in certain scene.
For example, try encoding this clip with x265 (--crf 24 --preset medium). Pay attention to the shirt near to border when panning
http://www.solidfiles.com/d/b189f87909/

The effect more noticeable if you use aq-mode 2. I dont get this problem when encoding this clip in x264

[Ma]

For example, try encoding this clip [...]

In what sense this anime.mkv.exe is a clip? Can you explain?

[shinchiro]

In what sense this anime.mkv.exe is a clip? Can you explain?
Dont click the big button download button. Click "direct download link"

[Ma]

Dont click the big button download button. Click "direct download link"

Confirmed, now there is a clip. Thanks for explanation.

After encoding I see that all new parts of the image that appear from the bottom of the screen are in much worse quality than "old" parts of the image. For me it is a bug in x265.

[LigH]

You possibly mean the slightly noisy structure the codec is trying to keep as stable as possible? This is certainly caused by the very low details in the rather flat colored part where the codec finds no reason to prefer a linear upwards motion vector over a zero motion vector, therefore the harder contrast to the upper black line of the shoulder leaves a trail of quantization errors.

[shinchiro]

You possibly mean the slightly noisy structure the codec is trying to keep as stable as possible?
Yeah..I can't find right word for that :p

Here is another anime clip involving panning to right. Pay attention to tv logo ("BS11") in the top-upper-right
Source: http://www.solidfiles.com/d/9f18cb8565/

If you encode it with --crf 35 in x265, you can see leftover of the tv logo as it trailing the panning. Aside that, it seem harder to maintain the tv logo shape

In x264, even I encode it with --crf 35, I cant see leftover of the tv logo. It stabilize & maintain the shape well while panning

[sneaker_ger]

Don't compare at same crf, compare at same bitrate. I did encode at same bitrate (8bit x265 --crf 35 vs 8bit x264 --crf 51) and the x264 version is so bad the logo is gone for large parts of the clip! At these ultra-low bitrates x265 will eat x264 for breakfast.

https://www.sendspace.com/file/q0lfau

[foxyshadis]

Don't compare at same crf, compare at same bitrate. I did encode at same bitrate (8bit x265 --crf 35 vs 8bit x264 --crf 51) and the x264 version is so bad the logo is gone for large parts of the clip! At these ultra-low bitrates x265 will eat x264 for breakfast.

https://www.sendspace.com/file/q0lfau

Wow. I used to stress test x264 for bottom-of-the-barrel mobile encodes (that segment YIFY has made a career out of) and I'm blown away by what x265 can do there. A q51 pure-predicted encode is still quite watchable for simple scenes like this, and smaller than I thought possible.

[sneaker_ger]

I assume the large blocks do a lot of the work. Any sane person would of course downscale before encoding using x264 at these bitrates.

[Atak_Snajpera]

Eventually, new builds from me, I waited a bit longer, but it was worth it: Main12 now supports some degree of assembler optimization completely (at least up to SSE2-4 and AVX1), and just recently got a new table of "lambda" values (no clue what it means, but it seems to be important for a sane bitrate control).

x265 1.7+371-24c1ee516d13 (GCC 4.8.2) (https://www.mediafire.com/download/p507695nox57zl2/x265_1.7+371-24c1ee516d13.GCC482.7z)
x265 1.7+371-24c1ee516d13 (GCC 4.9.2) (https://www.mediafire.com/download/kybwwdvv1a12r87/x265_1.7+371-24c1ee516d13.GCC492.7z)

And some results to compare:

8 bit (https://www.mediafire.com/download/dvdbaspl6cv5oqy/tos_60s_720p_main.hevc.mp4) | 10 bit (https://www.mediafire.com/download/01r7znyrcmuus42/tos_60s_720p_main10.hevc.mp4) | 12 bit (https://www.mediafire.com/download/b823w1rhu1hb8zd/tos_60s_720p_main12.hevc.mp4) (each ~6..7 MB, only default parameters except bit depth)

Sorry to say that but your builds are still broken in 2-pass mode on CPU with many threads (stat file is messed up at the end). Could you compile with MA's patch?

[nevcairiel]

Sorry to say that but your builds are still broken in 2-pass mode on CPU with many threads (stat file is messed up at the end). Could you compile with MA's patch?

You should get the patch integrated into mainline if you think its required for proper functionality, then it'll show up in everyones build.

PS:
Also actually linking a patch when asking someone to build with it would help to find it. :D

[Atak_Snajpera]

https://bitbucket.org/multicoreware/x265/issues/147/corrupted-stat-file-on-cpu-with-many#comment-20273155

[qyot27]

That patch is for MinGW-w64 itself, not x265. To integrate it you'd have to rebuild the entire toolchain (erring on the side of caution would mean MinGW-w64 AND GCC in this case).

But there's no indication in the comments whether this issue exists in some arbitrary version of MinGW-w64 as provided by X or Y package management system (the decrepit mingw-get system/MSYS1, Cygwin, MSys2, a Linux distro's provided version), or if it's still present in the latest stable tarball or git HEAD, so even something as feasibly simple as 'apply this patch to MinGW-w64' is unclear. Because there's also no indication of which version of MinGW-w64 was used to build the failing binaries in this case. The compiler is what everyone might fixate on, but it's not like you're only restricted to the newest version of MinGW-w64 when you build newer versions of GCC.

[Atak_Snajpera]

I was thinking about this patch

*** ratecontrol-o.cpp Sat Jun 27 07:48:04 2015
--- ratecontrol.cpp Sat Jun 27 08:00:51 2015
***************
*** 2213,2219 ****
char cType = rce->sliceType == I_SLICE ? (rce->poc > 0 && m_param->bOpenGOP ? 'i' : 'I')
: rce->sliceType == P_SLICE ? 'P'
: IS_REFERENCED(curFrame) ? 'B' : 'b';
! if (fprintf(m_statFileOut,
"in:%d out:%d type:%c q:%.2f q-aq:%.2f tex:%d mv:%d misc:%d icu:%.2f pcu:%.2f scu:%.2f ;\n",
rce->poc, rce->encodeOrder,
cType, curEncData.m_avgQpRc, curEncData.m_avgQpAq,
--- 2213,2223 ----
char cType = rce->sliceType == I_SLICE ? (rce->poc > 0 && m_param->bOpenGOP ? 'i' : 'I')
: rce->sliceType == P_SLICE ? 'P'
: IS_REFERENCED(curFrame) ? 'B' : 'b';
! #if _WIN32 && __GNUC__
! static Lock lockFile;
! lockFile.acquire();
! #endif
! int fprintfRet = fprintf(m_statFileOut,
"in:%d out:%d type:%c q:%.2f q-aq:%.2f tex:%d mv:%d misc:%d icu:%.2f pcu:%.2f scu:%.2f ;\n",
rce->poc, rce->encodeOrder,
cType, curEncData.m_avgQpRc, curEncData.m_avgQpAq,
***************
*** 2222,2228 ****
curFrame->m_encData->m_frameStats.miscBits,
curFrame->m_encData->m_frameStats.percent8x8Intra * m_ncu,
curFrame->m_encData->m_frameStats.percent8x8Inter * m_ncu,
! curFrame->m_encData->m_frameStats.percent8x8Skip * m_ncu) < 0)
goto writeFailure;
/* Don't re-write the data in multi-pass mode. */
if (m_param->rc.cuTree && IS_REFERENCED(curFrame) && !m_param->rc.bStatRead)
--- 2226,2236 ----
curFrame->m_encData->m_frameStats.miscBits,
curFrame->m_encData->m_frameStats.percent8x8Intra * m_ncu,
curFrame->m_encData->m_frameStats.percent8x8Inter * m_ncu,
! curFrame->m_encData->m_frameStats.percent8x8Skip * m_ncu);
! #if _WIN32 && __GNUC__
! lockFile.release();
! #endif
! if (fprintfRet < 0)
goto writeFailure;
/* Don't re-write the data in multi-pass mode. */
if (m_param->rc.cuTree && IS_REFERENCED(curFrame) && !m_param->rc.bStatRead)

[LigH]

Unfortunately, I have only little experience, I am already glad that I can update and compile in a batch. Additionally applying a patch and reverting it before the next update ... I'd better bet on seeing this patch submitted to the x265 developers mailing list to have it commited.
__

P.S.: Steve Borho replied this patch will a) slow down all the stats writing, and b) probably not ensure the last few entries to be correct.

[Rogatti]

http://blog.streamingmedia.com/2015/07/new-patent-pool-wants-share-of-revenue-from-content-owners.html
-
Can this apply retroactively to all the content already encoded with H.265?

[x265_Project]

Wow. I used to stress test x264 for bottom-of-the-barrel mobile encodes (that segment YIFY has made a career out of) and I'm blown away by what x265 can do there. A q51 pure-predicted encode is still quite watchable for simple scenes like this, and smaller than I thought possible.
Thanks for the demo, sneaker_ger. This is a great example of motion compensated prediction in action.

[Stacey Spears]

There is a typo on the x265 documentation http://x265.readthedocs.org/en/default/cli.html?highlight=display%20master#cmdoption--master-display

Example for P65D3 1000-nits:
G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

The P65D3 should probably be D65P3. The D and Ps are swapped.

[Ma]

But there's no indication in the comments whether this issue exists in some arbitrary version of MinGW-w64 as provided by X or Y package management system (the decrepit mingw-get system/MSYS1, Cygwin, MSys2, a Linux distro's provided version), or if it's still present in the latest stable tarball or git HEAD, so even something as feasibly simple as 'apply this patch to MinGW-w64' is unclear.

The bug is in all versions of Mingw-w64. I attached patched mingw_pformat.c file from release versions 3.3.0, 4.0.2 and from current trunk version.

Release Mingw-w64 versions are in this directory
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/

Current trunk version you can get by
git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64

You can rebuild Mingw-w64 (after replacing mingw_pformat.c file) by the command -- for 64-bit CRT:
configure --host="x86_64-w64-mingw32" --build="x86_64-w64-mingw32" --enable-lib64 --disable-lib32 CFLAGS="-O2 -g" CXXFLAGS="-O2 -g"
make install
and for 32-bit CRT:
configure --host="i686-w64-mingw32" --build="i686-w64-mingw32" --enable-lib32 --disable-lib64 CFLAGS="-O2 -g" CXXFLAGS="-O2 -g"
make install

If you want smaller libs (without debug data) you can don't add -g option in configure step.

If you rebuild the same version as is in your GCC toolchain, you can simply take only libmingwex.a from your local/lib folder and replace your original libmingwex.a file in x86_64-w64-mingw32/lib folder in your mingw compiler (i686-w64-mingw32/lib for 32-bit version).

Mingw-w64 team rewrite this patch -- current working version is like in this message
http://sourceforge.net/p/mingw-w64/mailman/message/34308686/

[x265.cc]

The bug is in all versions of Mingw-w64.


JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.

[mchartier]

JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.

Too bad there are no 10bit builds though...

[LigH]

How can I check which MinGW versions my current build environments use?

[Jamaika]

JFYI: builds from https://encoder.pw/x265/ shouldn't be affected, at least the newer ones.
It is better, much better. :)
x265.exe --input-depth 10 --input-csp i420 --input-res 1920x1080 --output-depth 10 --preset slow --fps 120.000 --bitrate 4000 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 30 --min-keyint 1 /
--open-gop --ref 1 --bframes 0 --me dia --output "x265_420p10le.h265" -
X265.cc 1.7.0.380
http://i57.tinypic.com/1584fwg.png
X265.ru 1.7.0.374
http://i58.tinypic.com/4jb6on.png
Original
http://i57.tinypic.com/s46kuq.png

PS. Streaks are more visible on the screenshot of the original 1920x1080. It drives me crazy time differences when taking screenshot of FFmpeg {ss} for movies 10 depth. For movies 8bit there is no problem between RAW and H265.

Edit: How to look not only pass 2 looks better. http://www.sendspace.com/filegroup/H0igQXOxB6mIcSOBbLqUDFxPp9ZNQNyD9wKTbBZuD50 Y4M doesn't matter.

[LigH]

X265.cc 1.7.0.380
http://i57.tinypic.com/1584fwg.png
X265.ru 1.7.0.374
http://i58.tinypic.com/4jb6on.png
Original
http://i57.tinypic.com/s46kuq.png

Do not attempt to deeplink to "images" which are replaced by whole ad-packed HTML pages by the hoster.

To compare encoded with original material, you may prefer to use a reconstructed Y4M from the x265 encoder.

[Ma]

How can I check which MinGW versions my current build environments use?

You can read !components.txt file in your msys folder (section GCC version, component mingw-w64).

You can also look at the description on this page:
http://files.1f0.de/mingw/

[nevcairiel]

You can read !components.txt file in your msys folder (section GCC version, component mingw-w64).

You can also look at the description on this page:
http://files.1f0.de/mingw/

Thats assuming he uses one of my builds, or one of the packages that include one of them. There are other sources for mingw-w64 builds out there. ;)

[Ma]

Thats assuming he uses one of my builds, or one of the packages that include one of them.

Yes, he uses your builds: r10 & r13.

[LigH]

Yes, an old GCC 4.8.2 package and one rather current GCC 4.9.2 package downloaded from http://xhmikosr.1f0.de/tools/msys/ (several years ago and about 1-2 months ago).

So I assume I would have to get the matching MinGW sources package and recompile to apply the patch... but I am not really so experienced, would not be sure if I did that correctly. Support is welcome...

[Ma]

My patch works, but is not perfect.

Mingw-w64 team rewrites printf family functions, but puts function for example is directly call to msvcrt.dll. So if we make the best possible lock to mingw-w64 code and we mix this code with call to msvcrt functions we will fail -- our functions are atomic against our functions, MS functions are atomic against MS functions but if we mix stdio functions -- there will be mixed output (wrong).

So the only reasonable solution is to make exactly the same lock as MS did in msvcrt.dll. Then we can mix new code with msvcrt.dll calls without problems. So I copy MS source code to mingw_pformat.c file and all work perfect.

I attached new patch (+ MS sources if someone wants to check if I exactly copy _lock_file & _unlock_file functions). I attached also test file that calls printf & puts functions from many threads -- my previous patch fail at this test.

New patch is to mingw-w64 release version 4.0.2.
Nevcairiel could you make (test) GCC toolchain with this patch?

[Ma]

Support is welcome...

I compiled libmingwex.a for nevcairiel GCC 4.9.2 and 5.2 with latest patch. I think that nevcairiel uses some -march/-mtune options especially for 32-bit GCC 4.9.2 -- I use only -O2 option. You can replace original libmingwex.a with new from this archive:
www.msystem.waw.pl/x265/gcc-492-520-lib.7z

[LigH]

Alright - time to abandon GCC 4.8.2 now.
__

BTW, please excuse a little off-topic: How do I set up a different codepage in the MSYS console? Localized tools, e.g. hg, detect German language, but Umlauts are displayed incorrectly.

$ hg clone https://bitbucket.org/multicoreware/x265
Zielverzeichnis: x265
Fordere alle ─nderungen an
F³ge ─nderungssõtze hinzu
F³ge Manifeste hinzu
F³ge Dateiõnderungen hinzu
F³gte 10860 ─nderungssõtze mit 25234 ─nderungen an 715 Dateien hinzu
Aktualisiere auf Zweig default
238 Dateien aktualisiert, 0 Dateien zusammengef³hrt, 0 Dateien entfernt, 0 Dateien ungel÷st

[nevcairiel]

I compiled libmingwex.a for nevcairiel GCC 4.9.2 and 5.2 with latest patch. I think that nevcairiel uses some -march/-mtune options especially for 32-bit GCC 4.9.2 -- I use only -O2 option. You can replace original libmingwex.a with new from this archive:
www.msystem.waw.pl/x265/gcc-492-520-lib.7z

I don't specify any special CFLAGS, just use whatever the configure script sets as default.

[LigH]

New builds with MinGW-w64 patch for multi-threaded stats file output:

x265 1.7+382-7c83f7755422 (GCC 4.9.2) (https://www.mediafire.com/download/wojl2gb8iholy6e/x265_1.7+382-7c83f7755422.GCC492.7z)
x265 1.7+382-7c83f7755422 (GCC 5.2.0) (https://www.mediafire.com/download/qae6d64dn30vukr/x265_1.7+382-7c83f7755422.GCC520.7z)

[x265.cc]

New patch is to mingw-w64 release version 4.0.2.

my buildbot is now using your patch (v2). :thanks:

[ARRYMatie]

Man x265 still too crap compared to x264.

I tried play around with multiple settings but seems like there's always inconsistent color blotches in certain areas and banding in other areas.

Both of which would look smooth and uniform if encode in x264.

[LigH]

And who shall take this "complaint" serious without a proof, including all required details to recreate it?

[foxyshadis]

Man x265 still too crap compared to x264.

I tried play around with multiple settings but seems like there's always inconsistent color blotches in certain areas and banding in other areas.

Both of which would look smooth and uniform if encode in x264.

You're doing it wrong if you get banding with x265. Either switch up to 10-bit or add some grain, but I just don't believe you that x264 would look uniform where x265 doesn't at the same bitrate and bit depth.

[LigH]

How do I set up a different codepage in the MSYS console? Localized tools, e.g. hg, detect German language, but Umlauts are displayed incorrectly.

As the default shell is sh.exe, I assume I would have to edit ~/.inputrc somehow (if I could find a verbose specification for it)?

Or maybe sh.exe does not even support codepage configuration at all, and I should try to prefer mintty instead?

[MeteorRain]

Please excuse me if someone has mentioned this before.

In x264-10bit, the CRF value actually results in average qp near CRF+12 to maintain similar visual quality. For example, CRF 20 on 10 bits encoding actually results CRF "32".

In x265 high bit depth encoding, have we already applied the same mechanism? Or should we manually adjust the CRF value to ~+12 on 10 bits or even more on 12 bits to get a similar visual quality level?

[ARRYMatie]

You're doing it wrong if you get banding with x265. Either switch up to 10-bit or add some grain, but I just don't believe you that x264 would look uniform where x265 doesn't at the same bitrate and bit depth.

Been there, tried that. Was using 10bit in the beginning, even tried 12 and 16bit. But it looks like x265 does not process colors/grain as well as x264.

The banding problem could be solved if I added grain manually but then it'll require even more bitrate than the x264 version just to cover the flaws. If that's the case, might as well stick to x264.

x265 also has some discoloration errors here and there that cause color splots where as on x264 it'll be uniform.

[foxyshadis]

Been there, tried that. Was using 10bit in the beginning, even tried 12 and 16bit. But it looks like x265 does not process colors/grain as well as x264.

The banding problem could be solved if I added grain manually but then it'll require even more bitrate than the x264 version just to cover the flaws. If that's the case, might as well stick to x264.

x265 also has some discoloration errors here and there that cause color splots where as on x264 it'll be uniform.

Are you sure this isn't the effects of a crappy 6-bit TN monitor? Because all of my experience with x265 so far is exactly the opposite, and I've never seen a 10-bit encode that's anything but banding-free unless the input already had a ton of banding.

[burfadel]

Are you sure this isn't the effects of a crappy 6-bit TN monitor? Because all of my experience with x265 so far is exactly the opposite, and I've never seen a 10-bit encode that's anything but banding-free unless the input already had a ton of banding.

Yes that's true. A TN panel will naturally band, the only reason why it doesn't seem to is because of dithering done by the monitor itself.

The encode can only be ever as good as the input to the encoder. If the input has banding, the encoder will actually encode that banding as information which is why you see it in the output file.

[littlepox]

Are you sure this isn't the effects of a crappy 6-bit TN monitor? Because all of my experience with x265 so far is exactly the opposite, and I've never seen a 10-bit encode that's anything but banding-free unless the input already had a ton of banding.

It can also be the case where he is using a poor video player. I've seen such case, where potplayer's default settings actually give you a heavily banding output:

1. The internal ffmpeg decoder decodes 10bit HEVC and then convert it to 8bit output
2. EVR render converts that to RGB under 8bit precision
3. Video card then "enhance" the video once again in poor precision. AMD products enable this by default.

[LigH]

Just compared my last builds with brief benchmarks (best of 3, foreman.y4m in PAL CIF) on a legacy CPU (AMD Phenom-II X4, max. used SIMD = SSE2); for slow preset, I got a relation of ~5.0 fps (GCC 4.9.2) : ~5.5 fps (GCC 5.2.0), that should be significant.

[dipje]

BTW, please excuse a little off-topic: How do I set up a different codepage in the MSYS console? Localized tools, e.g. hg, detect German language, but Umlauts are displayed incorrectly.

Just thinking out loud here, but I know that with certain Git-for-windows installs (GitExtensions for one) that is the install-time option to change a Windows registry setting somewhere to enable Unicode and UTF-8 on the console.

So I'm thinking that your shell is outputting the correct codes for Umlauts and stuff, but Windows is just forcing the console window to something ancient (or the font that is used to display the console isn't an unicode-compatible font, stuff like that).

[qyot27]

The way this tends to work on Windows is that you're *not* dealing with the actual Bourne shell (or bash, or dash, etc.), but with (ba|da)sh running under cmd.exe. And even forcing it into UTF-8 with chcp 65001 before launching sh doesn't seem to really do anything, as far as I can recall.

If, however, you're using mintty (MSys2 does this) as the host for the shell, then you can just change the codepage to whatever you want in the Options dialog. Although I don't necessarily know how this reacts on other OS codepage settings, but mintty is set on en.US and UTF-8 and it correctly prints eszett and umlauted characters just fine (and o with stroke, and ñ, and thorn, etc.). Not that I think the en.US part is doing anything, that's simply because I am under the English OS codepage here. I'm sure that it's simply because mintty actually does honor the UTF-8 setting.

[LigH]

I switched to mintty as shell by calling "msys.bat --mintty"; this is a quite advanced shell window application and supports locales and codepages (and Windows CP1252 is the correct one here). No need to try to force sh-in-cmd into something possibly not really supported.

[LoRd_MuldeR]

Getting Unicode (UTF-8) strings to show up properly in a Console window on the Windows platform can be quite challenging ;)

First of all, you have to avoid the the stdio-layer of the C-Runtime mangles your UTF-8 strings. This is going to happen by default! With Visual C++, you have to use the non-standard _setmode() function, with _O_U8TEXT or _O_BINARY flag, so that your strings get passed though undistorted. Not sure about MinGW. But you can always skip the stdio-layer altogether and use Win32 API functions, like WriteConsole(), directly. This avoids one source of string distortion.

But even if you manage that your UTF-8 string actually arrives at the Console undistorted, you still have to ensure the Console will interpret it correctly. You have to call SetConsoleOutputCP() with CP_UTF8. Last but not least, the default Console font on Windows (called "Consolas") is not Unicode-aware! You explicitly have to change the font to "Lucidia Console" to make things works. Not sure the font issue can be solved pragmatically. Maybe with some Registry hack...

[LigH]

So I guess mintty does a conversion here. The required changes are minimal, the result is satisfying, and on top I get some fancy gadgets (e.g. a translucent plain or even the "Aero Glass" blurry background).

[foxyshadis]

Last but not least, the default Console font on Windows (called "Consolas") is not Unicode-aware! You explicitly have to change the font to "Lucidia Console" to make things works. Not sure the font issue can be solved pragmatically. Maybe with some Registry hack...

Consolas is missing CJK, other East Asian characters, and Arabic, but it has all Latin and Cyrillic characters, at least. So it has some Unicode support.

[LigH]

How about "DejaVu Sans Mono"? I believe it contains a large subset of Unicode too.

[x265.cc]

My patch works, but is not perfect.

mingw-w64 4.0.4 is out. AFAIK this problem is not fixed. am i right? =(

It may be more elaborate, but you may want to build the multilib executables to combine 8 + 10 + 12 bit encoder routines into one EXE. Don't forget to strip, that saves a few MB. And 7-zip will compress such large 3-in-1 files a lot more efficiently than ZIP with its small LZ window (only 32 or 64 KB, I believe).

I'm not able to cross-compile a multilib x265.exe on linux. I really want to but i lack of intelligence.
I dont use 7-zip because its not bundled with windows.


Maybe i will automatically build 10 and 12 bit binaries too soon or will manage to build the multilib pe file.

//edit: 10-bit and 12-bit binaries are now build automatically too (for x86-64)

./libx265_main12.a(level.cpp.obj): could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
CMakeFiles/cli.dir/build.make:360: recipe for target 'x265.exe' failed
make[2]: *** [x265.exe] Error 1
CMakeFiles/Makefile2:99: recipe for target 'CMakeFiles/cli.dir/all' failed
make[1]: *** [CMakeFiles/cli.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2


[ 22%] Built target encoder
[ 83%] Built target common
[ 85%] Built target x265-static
[ 86%] Linking CXX executable x265.exe
libx265.a(param.cpp.obj): could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
CMakeFiles/cli.dir/build.make:360: recipe for target 'x265.exe' failed
make[2]: *** [x265.exe] Error 1
CMakeFiles/Makefile2:99: recipe for target 'CMakeFiles/cli.dir/all' failed
make[1]: *** [CMakeFiles/cli.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

[qyot27]

I'm not able to cross-compile a multilib x265.exe on linux. I really want to but i lack of intelligence.
https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L1131

Dependency: x265
================

# Any options with [] around them are optional

cd ~/mpv-build-deps

# Supporting both 8bit and higher bit depths requires an out-of-tree build:
mkdir -p x265-build/12bit x265-build/10bit x265-build/8bit
cd x265-build
hg clone https://bitbucket.org/multicoreware/x265

# Build 12-bit:
cd 12bit
cmake ../x265/source -G "Ninja" -DCMAKE_INSTALL_PREFIX="$HOME/x265_build/x265-12bit" \
-DCMAKE_TOOLCHAIN_FILE="/usr/i686-w64-mingw32/toolchain-i686-w64-mingw32.cmake" \
-DCMAKE_CXX_FLAGS="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3" \
-DHIGH_BIT_DEPTH:bool=on -DMAIN12:bool=on -DENABLE_SHARED:bool=off \
-DENABLE_ASSEMBLY:bool=off -DEXPORT_C_API:bool=off -DENABLE_CLI:bool=off [-DWINXP_SUPPORT:bool=on]
ninja
sudo checkinstall --pkgname=x265-main12-mingw --pkgversion="$(grep X265_VERSION \
build.ninja | sed 's/X265_VERSION=/\t/' | cut -f2 | sed 's/ /\t/g' | cut -f1)-$(date \
--rfc-3339=date | sed 's/-//g')-hg" --backup=no --deldoc=yes --delspec=yes \
--deldesc=yes --strip=yes --fstrans=no --default cp libx265.a /usr/i686-w64-mingw32/lib/libx265_main12.a

# Build 10-bit:
cd 10bit
cmake ../x265/source -G "Ninja" -DCMAKE_INSTALL_PREFIX="$HOME/x265_build/x265-10bit" \
-DCMAKE_TOOLCHAIN_FILE="/usr/i686-w64-mingw32/toolchain-i686-w64-mingw32.cmake" \
-DCMAKE_CXX_FLAGS="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3" \
-DHIGH_BIT_DEPTH:bool=on -DENABLE_SHARED:bool=off -DENABLE_ASSEMBLY:bool=off \
-DEXPORT_C_API:bool=off -DENABLE_CLI:bool=off [-DWINXP_SUPPORT:bool=on]
ninja
sudo checkinstall --pkgname=x265-main10-mingw --pkgversion="$(grep X265_VERSION \
build.ninja | sed 's/X265_VERSION=/\t/' | cut -f2 | sed 's/ /\t/g' | cut -f1)-$(date \
--rfc-3339=date | sed 's/-//g')-hg" --backup=no --deldoc=yes --delspec=yes \
--deldesc=yes --strip=yes --fstrans=no --default cp libx265.a /usr/i686-w64-mingw32/lib/libx265_main10.a

# Only the .a files from 12-bit and 10-bit are installed to the system,
# to reduce the chances of conflicts.

# Build 8-bit:
cd ../8bit
cmake ../x265/source -G "Ninja" -DCMAKE_INSTALL_PREFIX="/usr/i686-w64-mingw32" \
-DCMAKE_TOOLCHAIN_FILE="/usr/i686-w64-mingw32/toolchain-i686-w64-mingw32.cmake" \
-DCMAKE_CXX_FLAGS="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3" \
-DENABLE_SHARED:bool=off -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT:bool=on -DLINKED_12BIT:bool=on \
-DEXTRA_LIB="/usr/i686-w64-mingw32/lib/libx265_main10.a;/usr/i686-w64-mingw32/lib/libx265_main12.a" \
[-DWINXP_SUPPORT:bool=on]
ninja
sed -i 's/lx265/lx265 -lx265_main10 -lx265_main12/' x265.pc
sudo checkinstall --pkgname=x265-mingw --pkgversion="$(grep X265_VERSION \
build.ninja | sed 's/X265_VERSION=/\t/' | cut -f2 | sed 's/ /\t/g' | cut -f1)-$(date \
--rfc-3339=date | sed 's/-//g')-hg" --backup=no --deldoc=yes --delspec=yes \
--deldesc=yes --strip=yes --fstrans=no --default ninja install

# 32-bit builds with HIGH_BIT_DEPTH enabled also require the use of
# -DENABLE_ASSEMBLY:bool=off.

# Enabling Windows XP support now requires using the -DWINXP_SUPPORT:bool=on
# option, because the API default is now Win7.

The sed line in the 8-bit instructions is only so FFmpeg can link against the combined static lib. For only x265.exe itself, that's not necessary.

Also, you'll notice some of that stuff is very specific to my own environment (32-bit, PIII compiler opts, XP support), so adapt as needed.

[Ma]

mingw-w64 4.0.4 is out. AFAIK this problem is not fixed. am i right? =(

Yes, you're right. It is not fixed even on trunk. The last response from mingw-w64 team was 2015-08-02:
Personally, I think the patch is nearly OK, but the lock/unlock
functions should go into its own files, not something hard to correct.

Kai, anything?

I sent new version of patch 2015-08-03 and there is silence. I was so irritated that I've installed VS 2015.

[Barough]

I sent new version of patch 2015-08-03 and there is silence. I was so irritated that I've installed VS 2015.


Any chance we could see and 32-bit VS 2015 complies from you also or?

[Ma]

Any chance we could see and 32-bit VS 2015 complies from you also or?

Depends of speed results. When I tested 64-bit versions of 10-bit x265 for AVX-CPU, the result was very close with asm turned on (depends of Windows mood, sometimes vs2015 build was the fastest).

But for this options:
--no-asm --preset slower --crf 17.5 --rdoq-level 1 --deblock -1 -f 200 1920x800-hob.y4m w.hevc
GCC 5.2 linked to msvcr120.dll encoded in 676.90s (0.30 fps) and vs2015 -- in 807.63s (0.25 fps). And 107% of best result is 1.07*676.90s = 724.283s. It means that vs2015 (without asm) result is not within 107% of fastest time.

32-bit versions of 10-bit x265 are without asm, so I assumed that vs2015 builds could be disqualified due to 107% rule. I will make speed test and take a look at real numbers.

[Barough]

Not interested in any 10/12-bit encodes here

The VS2015 x64 compiles sure is faster on my i7 so a x86 complie would be nice see 4 making compares 2 ur normal x86 binaries

[Ma]

The VS2015 x64 compiles sure is faster on my i7 so a x86 complie would be nice see 4 making compares 2 ur normal x86 binaries

OK, for tests:
www.msystem.waw.pl/x265/test_Win32-vs2015.7z

VS2015 uses /arch:SSE2 as default option even for Win32 (which is unsporting behavior). In root folders there are builds with /arch:IA32 option.

[nevcairiel]

I wouldn't want to run x265 on a CPU which doesn't even have SSE2. =p

[x265_Project]

As some of you noticed, we determined that a small subset of the AVX2 optimized functions in x265 were not providing a real performance benefit. AVX and AVX2 SIMD instructions can get much more work done per clock cycle, but there are some tradeoffs in setting up data to be operated on in bigger chunks, and some effects on processor clock frequencies that have to be considered. Expect another round or two of adjustments as we fine-tune to get the best possible performance. You should notice that an updated development build today is noticeably faster than builds from last week.

[burfadel]

I'm guessing that only applies to AVX2 processors, seeing as the new algorithm etc only applies to AVX2?

[x265_Project]

I'm guessing that only applies to AVX2 processors, seeing as the new algorithm etc only applies to AVX2?
That's right.

AVX2 is only supported in Intel Haswell, Broadwell and Skylake generation processors (also known as 4th, 5th and 6th generation Core Processors). This includes most Intel Core i3, i5 and i7 processors sold in the last 2 years, and Intel Xeon v3 (E3, E5 and E7) and v4 (E3) processors.

[shinchiro]

VS2015 uses /arch:SSE2 as default option even for Win32 (which is unsporting behavior). In root folders there are builds with /arch:IA32 option.

Hmm, did you need manually edit .vcxproj files to add the /arch options?

and I thought compiling with vs2015 will get error based on this issue #162 (https://bitbucket.org/multicoreware/x265/issues/162/compile-with-visual-studio-2015-failed)?

[burfadel]

That's right.

AVX2 is only supported in Intel Haswell, Broadwell and Skylake generation processors (also known as 4th, 5th and 6th generation Core Processors). This includes most Intel Core i3, i5 and i7 processors sold in the last 2 years, and Intel Xeon v3 (E3, E5 and E7) and v4 (E3) processors.

Ah okay, I've got an Ivy Bridge i5. Literally the only benefit I'd have from upgrading is AVX2, performance otherwise for generations 3 through 6 has relatively stagnated. Seems it will be this way for Kaby Lake as well next year.

I'm holding out for AMD Zen :).

[x265_Project]

Ah okay, I've got an Ivy Bridge i5. Literally the only benefit I'd have from upgrading is AVX2, performance otherwise for generations 3 through 6 has relatively stagnated. Seems it will be this way for Kaby Lake as well next year.

I'm holding out for AMD Zen :).

New generation processors include more than just support for new SIMD instructions like AVX2... memory bandwidth is generally improved, and instruction execution is increased in a number of ways. For example Haswell added a 4th Integer Arithmetic Logic Unit (the part of the CPU that actually processes the instructions).

See http://www.hotchips.org/wp-content/uploads/hc_archives/hc25/HC25.80-Processors2-epub/HC25.27.820-Haswell-Hammarlund-Intel.pdf

[Ma]

Hmm, did you need manually edit .vcxproj files to add the /arch options?

I use set CXXFLAGS=[options] for extra options, for exampleset CXXFLAGS=/arch:AVX

and I thought compiling with vs2015 will get error based on this issue #162 (https://bitbucket.org/multicoreware/x265/issues/162/compile-with-visual-studio-2015-failed)?

Yes, in this issue there is a solution to the problem. If you want to make exactly the same build as I did, copy x265-1.7+399.diff from source folder in archive to your x265 folder and apply command (from x265 folder):hg import --no-commit x265-1.7+399.diff

Then you can set CXXFLAGS for special options and use my (attached) 1-32.bat for build.

[shinchiro]

Thats helpful. Thanks :)

[foxyshadis]

That's one way. I just edit the CMakeLists.txt in /source to add:
add_definitions(/GL) # whole program opt
add_definitions(/GS-) # no buffer security check
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /LTCG /INCREMENTAL:NO /OPT:ICF /OPT:REF")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} /LTCG /INCREMENTAL:NO /OPT:ICF /OPT:REF")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} /LTCG /INCREMENTAL:NO /OPT:ICF /OPT:REF")
then it doesn't matter how you build it. Buffer check removal and link-time code gen doesn't add much speed (I should be profiling each build, but ain't nobody got time for that), but ICF and REF cut down the final size a bit.

[Barough]

OK, for tests:
www.msystem.waw.pl/x265/test_Win32-vs2015.7z


Thnx for the 32bit binary. I've made a couple of test encodes and it's a bit faster then the normal build.

[Ma]

Thnx for the 32bit binary. I've made a couple of test encodes and it's a bit faster then the normal build.

In my 10-bit encodes with option --preset slow the result is:
stable_1.7+6
GCC core2-CPU 108.89s (4.63 fps)
GCC nehalem-CPU 109.13s (4.62 fps)
vs2015 AVX-CPU 120.29s (4.19 fps)

Thanks to foxyshadis tips I made some new builds and the best was with option /arch:AVX /GS- 119.77s (4.21 fps) and even faster was after PGO 119.70s (4.21 fps).

default_1.7+399
GCC nehalem-CPU 289.19s (1.74 fps)
GCC core2-CPU 328.48s (1.53 fps)
vs2015 AVX-CPU 569.36s (0.89 fps)

So there will be no 32-bit vs2015 builds on my page (107% rule), but I definitely add /GS- option to 64-bit vs2015 builds.

Edit: According to nevcairiel remark I updated Win32 builds -- now it starts from SSE2 and in my tests 8-bit VS 2015 builds are slower than GCC 5.2 (in SSE2 category & AVX category).

[LigH]

Due to a merge to prepare the coming v1.8 milestone:

x265 1.7+399-cbdefdfca877 (GCC 4.9.2) (https://www.mediafire.com/download/pwav1pablp7wq9n/x265_1.7+399-cbdefdfca877.GCC492.7z)
x265 1.7+399-cbdefdfca877 (GCC 5.2.0) (https://www.mediafire.com/download/3ld1k29h74wyfrh/x265_1.7+399-cbdefdfca877.GCC520.7z)

[Ma]

Thnx for the 32bit binary. I've made a couple of test encodes and it's a bit faster then the normal build.

After test Win32 versions of 8-bit encoders on 1920x800 file with options --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709
GCC 5.2 msvcr120 vs. VS 2015 -- encoding time in seconds:

fast medium slow slower verysl placebo
GC-SSE2 108,63 167,77 148,07 205,83 193,88 184,19
VS-SSE2 108,72 168,13 163,19 220,91 210,15 200,94

GCC-neh 108,03 167,11 147,54 205,81 193,16 182,92

GCC-AVX 107,04 165,38 147,12 204,22 191,81 180,95
VS-AVX 107,78 166,54 162,67 218,91 208,07 199,52


Starting on slow preset the VS 2015 builds are out of pace. VS-AVX build wins with GCC-SSE2 & GCC-nehalem @ fast & medium preset.

[burfadel]

I see that it is GCC 5.2+msvcr120. msvcr120 is from Visual Studio 2013, is it possible to have GCC 5.2+msvcr140? (msvcr140 is from Visual Studio 2015).

[Ma]

I see that it is GCC 5.2+msvcr120. msvcr120 is from Visual Studio 2013, is it possible to have GCC 5.2+msvcr140? (msvcr140 is from Visual Studio 2015).

In theory I don't know. In practice there is no libmsvcr140.a in current trunk version of mingw-w64, so it is not easy.

[ale_x]

Hi, I have question.

Is there any way to find how to get the right level for X265 by use HEVC table of levels , because X265 levels are more than X264, I know how to do for X264 from this website :
http://wiki.serviio.org/doku.php?id=get_h264_level

thanx.

[Motenai Yoda]

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels#Levels

[ale_x]

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels#Levels

thanx! ^^
I know this reference, but I want to know is there any calculation method to bring out value of level?! :D

[LigH]

By the way, the encoders use a lowercase "x". And the ITU standards an uppercase "H" and a dot.

You will usually not set the level a priori; except you need to limit it because you know that a playback device won't support any higher level.

If you are certain that the devices which will play your encodes can do that easily, don't limit the level. Let the encoder guess and take all the freedom it requires to distribute the bitrate optimally.

[ale_x]

By the way, the encoders use a lowercase "x". And the ITU standards an uppercase "H" and a dot.

You will usually not set the level a priori; except you need to limit it because you know that a playback device won't support any higher level.

If you are certain that the devices which will play your encodes can do that easily, don't limit the level. Let the encoder guess and take all the freedom it requires to distribute the bitrate optimally.

Good advice. :thanks:

[Rogatti]

http://imgbox.com/BL7R1dRk
http://imgbox.com/BW7l0SQP
http://imgbox.com/Nwiyskni
http://imgbox.com/gVnnS3PE

[vivan]

thanx! ^^
I know this reference, but I want to know is there any calculation method to bring out value of level?! :DLigh is right and you really shouldn't bother with it.
But just in case: number of maximum reference frames is based (1) on how much target resolution is lower than profile's max resolution (2). And it must be either 6, 8, 12 or 16.
For example:
960x720 at Level 4: 6 * 2228224 / (960 * 720) = 19,3 -> 16
1440x1080 at Level 4: 6 * 2228224 / (1440 * 720) = 8,6 -> 8.
(1) http://i.imgur.com/VpWz18T.png
(2) http://i.imgur.com/Zee1cSc.png

[ale_x]

Ligh is right and you really shouldn't bother with it.
But just in case: number of maximum reference frames is based (1) on how much target resolution is lower than profile's max resolution (2). And it must be either 6, 8, 12 or 16.
For example:
960x720 at Level 4: 6 * 2228224 / (960 * 720) = 19,3 -> 16
1440x1080 at Level 4: 6 * 2228224 / (1440 * 720) = 8,6 -> 8.
(1) http://i.imgur.com/VpWz18T.png
(2) http://i.imgur.com/Zee1cSc.png

Thanx vivan ;)

[nevcairiel]

Note that there are strong diminishing returns for more than 8 reference frames in HEVC. A single frame cannot use more than 8 active references, so keeping more than 8 is likely not going to be beneficial and only increase strain on the decoder.

[LigH]

Another "merge with stable":

x265 1.7+424-996ebce8c874 (GCC 4.9.2) (https://www.mediafire.com/download/mjj4mypsyyut9ig/x265_1.7+424-996ebce8c874.GCC492.7z)
x265 1.7+424-996ebce8c874 (GCC 5.2.0) (https://www.mediafire.com/download/okhpf8b5e5hac58/x265_1.7+424-996ebce8c874.GCC520.7z)

[Ma]

After latest commits I can't encode in 2-pass mode. Default branch ver. 1.7+424 is working, ver. 1.7+425 doesn't work.

Error at beginning of second pass:x265 [error]: CU-tree frametype 0 doesn't match actual frametype 2.

Options for first pass:--frames 641 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --pass 1 --bitrate 3000 --stats F:\m\v\0001.mkv.stats -F 5 --output NUL

Options for second pass:--frames 641 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --pass 2 --bitrate 3000 --stats F:\m\v\0001.mkv.stats -F 5 --output F:\m\v\0001.mkv.hevc

I attached stats files.

[LigH]

I'll report this to the developer mailinglist.

[Ma]

I'll report this to the developer mailinglist.

Thanks! Now is working even with original mingw-w64.

[LigH]

Weekly build, "merge with stable".

x265 1.7+433-60f30d2ead26 (GCC 4.9.2) (https://www.mediafire.com/download/1t9y8h21jqnodh9/x265_1.7+433-60f30d2ead26.GCC492.7z)
x265 1.7+433-60f30d2ead26 (GCC 5.2.0) (https://www.mediafire.com/download/9pm3dzp2z1bnz79/x265_1.7+433-60f30d2ead26.GCC520.7z)

[jhughy2010]

I'm wondering if someone could post their "optimal" settings for Handbrake? When I check the "use advanced tab" under x265 there is no advanced tab that appears.

I'm re-encoding some BD rips and want the best quality with decent file size. I want two audio tracks... one stereo and another 5.1

With that said, what would you do?

[LigH]

This is a thread about the x265 backend (encoder), not about the Handbrake frontend (GUI). Don't blame x265 for Handbrake not providing advanced options (except for being still in an often changing development state, so that the Handbrake developers may not yet feel like supporting too many advanced options, because they may change "tomorrow").

The x265 encoder is not yet in a development phase where options get tuned for the convenience of the user. Options recommendable today may not be valid anymore next month, or next year, who knows... There are already presets for different relations of encoding speed vs. encoding thoroughness, but their details may still change; and the tunings are not yet as balanced as for x264, either.

In general, I would not yet recommend to use x265 for archiving copies of whole movies. It will take several times the encoding time of x264, anyway. But if you insist ... you may use the constant quality mode like you would for x264, just the CRF values will be a bit different, you may have to discover your optimum by encoding several movies several times (which may take days, if not weeks, at the current speed of x265). In case you need to fill a medium with a tightly limited capacity, you can use 2-pass encoding as well. The recommendable container to multiplex HEVC with AC3 audio tracks is MP4, alternatively maybe MKV or M2TS.

Also take into account that not many consumer devices already support the playback of HEVC video; apart from PCs, mainly TV sets which are already prepared for UHD broadcasts.

Again: For practical use, I'd prefer x264; I would not recommend x265 for home users yet to encode a copy of a whole movie.

[jhughy2010]

This is a thread about the x265 backend (encoder), not about the Handbrake frontend (GUI).

Ok I didn't realize there was a difference. I'm new to encoding and have been using Handbrake for only a few months.

In general, I would not yet recommend to use x265 for archiving copies of whole movies. It will take several times the encoding time of x264, anyway. But if you insist ... you may use the constant quality mode like you would for x264, just the CRF values will be a bit different, you may have to discover your optimum by encoding several movies several times (which may take days, if not weeks, at the current speed of x265). In case you need to fill a medium with a tightly limited capacity, you can use 2-pass encoding as well. The recommendable container to multiplex HEVC with AC3 audio tracks is MP4, alternatively maybe MKV or M2TS.

Ok perfect that is what I will try (and what I recently experimented with). Seems a constant quality of 18 is pretty comparable to a 20 with x264. Although dark scenes with x265 seem really blocky (I don't know how else to describe it).

Also take into account that not many consumer devices already support the playback of HEVC video; apart from PCs, mainly TV sets which are already prepared for UHD broadcasts.

I mostly watch on HTPC. I have noticed that an x265 movie didn't play well on my Samsung S5. It was a bit choppy.

[NikosD]

An interesting comparison of HW encoders (HEVC, H.264) vs SW encoders (x265, x264) in terms of performance and quality using QSVEncC v2.11

It looks like that on Skylake both QSV H.264 modes - PG and FF - have the same speed and QSV HEVC encoding has half speed of QSV H.264.

Compared to SW encoders, QSV HEVC is 2x faster than x264 and 12x (!) faster than x265.

Quality pictures and performance numbers here:
http://rigaya34589.blog135.fc2.com/blog-entry-673.html

[LigH]

Well, hardware accelerated AVC and HEVC encoding may be fast ... but not very efficient. You better have plenty of bitrate or you will clearly see the disadvantages compared to elaborate software encoders.

[Atak_Snajpera]

Anime? Show me results with some killer samples like parkjoy , crowdrun and so on and then we will talk about encoding speed and image quality.

[aegisofrime]

Well, hardware accelerated AVC and HEVC encoding may be fast ... but not very efficient. You better have plenty of bitrate or you will clearly see the disadvantages compared to elaborate software encoders.

This is just a guess but probably a hybrid approach might be doable? Offload some stuff to the fixed function hardware on Skylake (I think they have fixed function motion estimation stuff) and do the rest in software. Since they are sitting on the same die there won't be much latency like with moving stuff between CPU and GPU in GPU encoding.

[LigH]

The result, if this is possible at all, may not be "x265" anymore; but even if it is possible, I don't think it would speed up the process remarkably, because there is an overhead in exchanging data between CPU and GPU, and the CPU would still do the most complex parts of the algorithm (searching for optimal matches across several reference frames), gaining only little from what the GPU could take off, I believe...

[sneaker_ger]

The biggest question is if Intel gives you access to specific parts of its encoding functions (like e.g. motion estimation) or if it's just a black box taking in raw frames and spewing out AVC/HEVC from a programmers point of view. In the worst case you'd have to let it do a full encoding and then extract e.g. motion vectors from the final bitstream. At the end of the day speed or quality might not be up to par.

[foxyshadis]

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.

[x265_Project]

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.
We think about how to accelerate x265 constantly. But as LiGH and Foxyshadis noted, we don't want x265 to simply call someone else's encoder, or part of another encoder. Where there are fixed function capabilities in new hardware HEVC encode pipelines that we can leverage, we will.

We don't feel like we compete with proprietary encoder APIs. While we don't disagree that it makes sense for semiconductor companies to offer their own proprietary encoder APIs, customers worldwide vastly prefer the quality, features, flexibility and cross platform capability of open source encoder libraries like x264 and x265. It makes sense for semiconductor companies to give us access to the full power of their new architectures. Unfortunately, these hardware pipelines aren't designed as a set of addressable fixed function units that we can quickly and efficiently access. But we're investigating all of the possibilities.

[LigH]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2) (https://www.mediafire.com/download/vx21tk5hqla3h22/x265_1.7+470-86e9bd7dd192.GCC492.7z)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0) (https://www.mediafire.com/download/1dwbk5t22kac176/x265_1.7+470-86e9bd7dd192.GCC520.7z)

[divxmaster]

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

[jhughy2010]

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.

[LigH]

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

This is mainly UHDcode, a quite fast and comprehensive HEVC decoder as DirectShow filter, along with a basic recoder for AVC-in-MP4 source files. Not really necessary for most cases, LAV Filters have a good decoder implementation as well, and there are free converters in all different flavours.

[x265_Project]

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.
The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

[divxmaster]

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

Trend continued, an entire encode was 13.49fps for 382 and 13.35fps for 470. The 470 file was a little bigger. Seems somewhat odd, but just an observation.

Cheers,
Divxmaster

[downloadhub]

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB

[jhughy2010]

The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

Ok thanks. You mentioned transcoding. So the windows application does on the fly transcoding but does it re-encode like Handbrake? Does it accept MKV files?

How does the application compare to Handbrake? If it is as functional and/or better I would be will to pay (heck I'd pay for Handbrake if it wasn't free).

[LigH]

@ downloadhub:

1. "anybody"

2. There are no miracles. And there are no crystal balls. Good quality requires a minimum bitrate per image area. If you need a small size, reduce the resolution. Use a 2-pass encoding method to bring your copy down to a desired target size. And stay with H.264 (AVC) for mobile devices, because H.265 (HEVC) requires much more computing power and will drain your battery faster. For better help, post more details; but not in this thread, this is about the development of x265, not a beginners' guide how to use any converter.
__

@ jhughy2010:

I did not use it yet, but according to the description: MP4 to MP4 only. And probably no filters, just straight video conversion with audio pass-through, certainly not as flexible as Handbrake or StaxRip or MeGUI or Hybrid.

[Jamaika]

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB
I think you can use Cyberlink Powerdiector 13. Editor AVC decoder is poor, but when you use Cineform codec you can get an interesting result HEVC output.
HEVC FullHD 4500kbps i420 8bit 30fps progressive High Quality

[LigH]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 (https://www.mediafire.com/download/0pl8r4cg0glv3tz/x265_1.7+474-e1adac00dce8.GCC492.7z) / 5.2.0 (https://www.mediafire.com/download/ntmn27dm6d5qm7d/x265_1.7+474-e1adac00dce8.GCC520.7z)) (multilib EXE's only) with a changed NUMA pool strategy

[x265.cc]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 (https://www.mediafire.com/download/0pl8r4cg0glv3tz/x265_1.7+474-e1adac00dce8.GCC492.7z) / 5.2.0 (https://www.mediafire.com/download/ntmn27dm6d5qm7d/x265_1.7+474-e1adac00dce8.GCC520.7z)) (multilib EXE's only) with a changed NUMA pool strategy

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)

[benwaggoner]

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)



I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.



Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

[Ma]

Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

I think that code generated by GCC 5.2 is faster but bigger. Size of code does matter because L1 cache is very small (32 KB) and there are huge speed differences between L1/L2/L3 cache/memory access.

For GCC 4.9 there is a problem that MS gives VS 2015 for free and code generated by VS 2015 is smaller than code generated by GCC 4.9.

GCC 4.9 build will be probably slower than the fastest build from GCC 5.2 & VS 2015.

[burfadel]

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

[Ma]

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

At AVX level (i5 3450S) there was: VS 2015 builds was faster in 8 and 10-bit encoding, much slower in 12-bit encoding.

After x265 team turn off AVX assembly code that was 10% faster than SSE4, VS 2015 builds are at the same speed in 8 & 10-bit encoding, much slower in 12-bit encoding.

I try to make tables for tomorrow @ AVX level and SSSE3 level.

[benwaggoner]

I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.
Looks like a fix should be coming today:

https://bitbucket.org/multicoreware/x265/commits/e1adac00dce8e5641cbe9aec3d50a72261c308d9#general-comments:
Pradeep Ramachandran author
Thanks. I see the error in my logic. I'll push in a fix tomorrow.

[Ma]

Speed test VS 2015 build vs. GCC 5.2.

Platform: Win7 64-bit, i5 3450S
Options: --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709
Builds: 1.7+473 from site www.msystem.waw.pl/x265

Encoding time in seconds (first table 8-bit, second 10-bit, third 12-bit):

fast medium slow slower verysl placebo
vs2015-AVX 69,69 108,21 274,78 368,5 393,92 400,4
msvcr120-AVX 70,3 108,24 274,73 371,23 396,06 403,91
gcc52-AVX 70,14 108,41 274,7 374,19 396,14 405,53
msvcr120-SSSE3 70,71 109,39 298,93 374,42 398,36 407,44
vs2015-SSE2 70,66 110,11 277,19 375,48 399,6 404,15

vs2015-AVX 87,89 132,82 413.04 515.14 552.64 574.87
msvcr120-AVX 88,83 133,81 413.77 518.28 555.17 580.92
gcc52-AVX 89,33 134,45 415.41 519.76 556.77 582.68
msvcr120-SSSE3 89,34 135,18 416.71 521.65 557.83 581.81
vs2015-SSE2 88,89 134,67 413.64 517.96 555.26 576.48

msvcr120-AVX 109,19 168,07 455,76 574,88
gcc52-AVX 109,69 168,56 457,26 576,78
msvcr120-SSSE3 111,96 172,47 461,8 585,26
vs2015-AVX 166,03 250,06 714,95
vs2015-SSE2 167,82 253,73 719,64


Unfortunately I took to many binaries to compare and too long samples and didn't finish. There was only 1 repeat and my Win7 in the night like to do something which affect results. Anyway vs2015-AVX build is the fastest @ 8-bit & 10-bit.

On CPU with only SSSE3 result was (encoding time in seconds, first table 8-bit, second 10-bit):

msvcr120-SSSE3 487,42 716,34 991,49 1068,54 1055,51 985,84
gcc52-SSSE3 490,43 729,44 991,58 1055,89 1057,93 983,03
gcc52-SSE2 498,47 768,78 1003,16 1053,75 1194,48 1010,54
vs2015-SSE2 608,29 873,99 1181,09 1267,78 1255,51 1153,93

msvcr120-SSSE3 618,49 899,64
gcc52-SSSE3 620,4 895,69
gcc52-SSE2 647 915,41
vs2015-SSE2 707,55 1004,47


On weak CPU vs2015 build is slow.

[NikosD]

Any test with Intel C Compiler ?

[Ma]

Any test with Intel C Compiler ?

On my i5 3450S ICC builds were very slow (months ago). Maybe it is time to make new test...

[burfadel]

Wow, VS2015 fastest with AVX, but slowest without it!

[NikosD]

On my i5 3450S ICC builds were very slow (months ago). Maybe it is time to make new test...
That would be very useful to have the 3 most common and most intelligent compilers compared to each other.

My very restricted experience with recompilations favored Intel using ICC, but I think that all three are very close (even looking your results) and is up to the specific code to have a winner.

[foxyshadis]

So much is done by yasm now that it hardly matters what compiler you use, 1% isn't so bad. I wonder what's wrong with VS2015 12-bit, though? Nearly twice as slow as the other compilers, something must not be building correctly. (Kind of amazing that they've otherwise so quickly made it to parity with 10-bit though.)

[Ma]

So much is done by yasm now that it hardly matters what compiler you use, 1% isn't so bad.

Yes, for AVX & AVX2 CPU @ 8/10-bit most important functions are in asm.

I wonder what's wrong with VS2015 12-bit, though? Nearly twice as slow as the other compilers, something must not be building correctly. (Kind of amazing that they've otherwise so quickly made it to parity with 10-bit though.)

x265 team turn off asm functions that doesn't work @ 12-bit so it is half asm half C++ solution. VS 2015 doesn't vectorize loops (for that is ICC) so it loses heavily to GCC. Maybe in the future x265 team write missing asm functions and VS 2015 builds will be fast @ 12-bit.

For 10-bit there was some action from Win7 that slow down encoding -- the results are just not right.

[Ma]

I downloaded ICC build from site http://x265.ru/en/builds/ and compared speed with VS 2015 AVX build 1.7+478 (only preset slower, 10-bit). ICC build encoding time is 105% of VS 2015 AVX build. I attached used *.bat and result file.

[LigH]

A tolerance of 5% is still marginal to me. So in general, the sources are quite portable, and the results quite reliable. Great business at MCW. :thanks:

[NikosD]

I downloaded ICC build from site http://x265.ru/en/builds/ and compared speed with VS 2015 AVX build 1.7+478 (only preset slower, 10-bit). ICC build encoding time is 105% of VS 2015 AVX build. I attached used *.bat and result file.

Thanks!

But you tested only one preset for only one encoding (10bit) and you compared that to the faster compiler of that particular test.

Looking at the first table of 10bit encodings, it seems that VS2015-SSE2 is extremely fast, sometimes faster than VS2015-AVX (!) like "slow" and "very slow" and particularly for "slow" preset is even faster almost than any other compiler at that particular test.

Are you sure ?

[Ma]

But you tested only one preset for only one encoding (10bit) and you compared that to the faster compiler of that particular test.

Yes, I was curious if the ICC build suits my favorite preset @ 10-bit -- the answer is not. For me (i5 3450S, 10-bit encoding) the best build is VS 2015 AVX. For other CPU the fastest build could be different, for example my second computer has only SSSE3 CPU and this build doesn't work at all, the fastest is GCC 5.2 SSSE3.

Looking at the first table of 10bit encodings, it seems that VS2015-SSE2 is extremely fast, sometimes faster than VS2015-AVX (!) like "slow" and "very slow" and particularly for "slow" preset is even faster almost than any other compiler at that particular test.

Are you sure ?

Numbers are copied from result file (enclosed), but my Win7 likes after long user inactivity defragment HDD or index files which highly affects the result. I will repeat this test for 10-bit and preset from slow to placebo and I will correct the table (tomorrow).

[burfadel]

Yes, I was curious if the ICC build suits my favorite preset @ 10-bit -- the answer is not. For me (i5 3450S, 10-bit encoding) the best build is VS 2015 AVX. For other CPU the fastest build could be different, for example my second computer has only SSSE3 CPU and this build doesn't work at all, the fastest is GCC 5.2 SSSE3.

Numbers are copied from result file (enclosed), but my Win7 likes after long user inactivity defragment HDD or index files which highly affects the result. I will repeat this test for 10-bit and preset from slow to placebo and I will correct the table (tomorrow).

Just had a quick look at the results. Using 12-bit, VS2015, and b-frames is broken!

For example, non-VS2015 12-bit results show under slow preset:

x265 [info]: frame P: 185, Avg QP:20.38 kb/s: 27554.99
x265 [info]: frame B: 562, Avg QP:25.83 kb/s: 3833.29

and VS2015 12-bit slow preset results in:
x265 [info]: frame P: 185, Avg QP:20.30 kb/s: 35750.58
x265 [info]: frame B: 562, Avg QP:25.76 kb/s: 12286.57

P frames also are much bigger in the VS2015 builds. The I-frames are pretty much the same size (although they're supposed to be the same across the different compilers).

[Ma]

Just had a quick look at the results. Using 12-bit, VS2015, and b-frames is broken!

Thanks! After fast check with ver. 1.7+478, command + result line:
GCC 5.2 build

x265-gc -D12 720p50_parkrun_ter.y4m wgc.hevc
encoded 504 frames in 35.80s (14.08 fps), 3168.26 kb/s, Avg QP:38.01

x265-gc -D12 --no-asm 720p50_parkrun_ter.y4m wgc-no.hevc
encoded 504 frames in 71.30s (7.07 fps), 3170.11 kb/s, Avg QP:37.99


VS 2015 build

x265-vs -D12 720p50_parkrun_ter.y4m wvs.hevc
encoded 504 frames in 52.23s (9.65 fps), 7189.06 kb/s, Avg QP:38.48

x265-vs -D12 --no-asm 720p50_parkrun_ter.y4m wvs-no.hevc
encoded 504 frames in 141.68s (3.56 fps), 14806.31 kb/s, Avg QP:38.96


So there is something wrong with 12-bit, asm output differs from no-asm, VS 2015 differs from GCC 5.2.

[x265_Project]

We're attending IBC this week. I'm here with Deepthi, manager of the x265 development team. If you are interested in meeting with us, please email me... tom.vaughan at multicorewareinc.com.

Tom

[lagittaja]

I've been evaluating x265 using HB 10.2 for a few days now.
Seriously impressed with what x265 can achieve! Thank you to all the devs working on this!

I won't be switching over from x264 just yet but I'm eager to go ahead and archive some of my Game of Thrones bluray's using x265.

Which is what I've been testing using x265. x265 on Main using medium preset, even RF20 looks impressively good either in static scenes and sword fighting scenes while achieving 70-90% compression. :eek:

So, getting to my point.
I figure that 10.2 uses version 1.5 built on GCC 4.9?
The latest version appears to be 1.7.
I guess what I'm trying to ask here is should I wait for a newer release of HB using newer version of x265?
Generally speaking, going from 1.5 what HB uses to 1.7, are there really noticeable gains in any aspect? Speed or quality or compression?

I'm encoding on OC'd Ivy Bridge i7 which doesn't have AVX2, in case that information matters.

[Jamaika]

I've been evaluating x265 using HB 10.2 for a few days now.
What is HB 10.2?
Which is what I've been testing using x265. x265 on Main using medium preset, even RF20 looks impressively good either in static scenes and sword fighting scenes while achieving 70-90% compression.
Examples please. Best not on a dark background. For me codec X265 is still a beta version.

[lagittaja]

What is HB 10.2?

Examples please. Best not on a dark background. For me codec X265 is still a beta version.

Handbrake.

I've been using three samples which I splitted of using MKVToolnix (keeping only video) from the original extracted from my Blurays using MakeMKV.
The GoT intro (probably on YT, haven't checked)
S01E02 00:37:00-00:39:30 ("static scene", decent amount of detail and crisp hair and so on.)
S01E05 00:51:00-00:53:00 (Eddard vs Jaime sword fight, can be found on YT).

I could put the original samples I use in my Dropbox but in total they're a little under a gigabyte so may take sometime for you to download depending on your connection.
And I don't know exactly what's considered a sample and this is copyrighted content after all so..

E: And I hope you didn't get my "even RF20 looks impressively good" as a "oh dear lord, RF20 looks so good it's almost transparent" statement. If I do end up archiving some of my GoT bluray's with Handbrake 0.10.2 using it's current x265 version along with the medium preset, RF setting I'd use would be either 17 or 18.
The file size using RF16 got real close to what my x264 encode at RF20 and custom settings got to while encoding speed wasn't all that different.

[Bigmango]

I figure that 10.2 uses version 1.5 built on GCC 4.9?
The latest version appears to be 1.7.


That's the problem with handbrake and why I use Ripbot.

Ripbot is updated regularly with more recent versions of x265 and you can always replace the x265.exe with a newer one in the Ripbot tools directory.

[luigizaninoni]

HB nightlies use x265 1.7. They are very stable

[Bigmango]

HB nightlies use x265 1.7. They are very stable
Good to hear, thanks for the feedback.

[lagittaja]

That's the problem with handbrake and why I use Ripbot.

Ripbot is updated regularly with more recent versions of x265 and you can always replace the x265.exe with a newer one in the Ripbot tools directory.

Thanks for the suggestion. I'll have a look at it tomorrow. But I'm not gonna lie to you, I've grown quite fond of Handbrake.

HB nightlies use x265 1.7. They are very stable

Oh, nice. Thank you sir! Almost had completely forgotten the nightlies, looks they have resumed them couple weeks ago.

[jhughy2010]

Handbrake.

I've been using three samples which I splitted of using MKVToolnix (keeping only video) from the original extracted from my Blurays using MakeMKV.
The GoT intro (probably on YT, haven't checked)
S01E02 00:37:00-00:39:30 ("static scene", decent amount of detail and crisp hair and so on.)
S01E05 00:51:00-00:53:00 (Eddard vs Jaime sword fight, can be found on YT).

I could put the original samples I use in my Dropbox but in total they're a little under a gigabyte so may take sometime for you to download depending on your connection.
And I don't know exactly what's considered a sample and this is copyrighted content after all so..

E: And I hope you didn't get my "even RF20 looks impressively good" as a "oh dear lord, RF20 looks so good it's almost transparent" statement. If I do end up archiving some of my GoT bluray's with Handbrake 0.10.2 using it's current x265 version along with the medium preset, RF setting I'd use would be either 17 or 18.
The file size using RF16 got real close to what my x264 encode at RF20 and custom settings got to while encoding speed wasn't all that different.

I feel like RF18 via x265 is at "least" as high of quality as RF20 via x264. The encode speed is drastically slower however. I've averaged around 14 frames per second with x265 at medium preset, RF18, AC3 5.1 for a full rip BD. With x264 I was in the 40+ FPS.

x265 is what I use exclusively for archiving my BD collection. I'll need to try the nightly build if the x265 encoder is really superior.

[birdie]

I feel like RF18 via x265 is at "least" as high of quality as RF20 via x264. The encode speed is drastically slower however. I've averaged around 14 frames per second with x265 at medium preset, RF18, AC3 5.1 for a full rip BD. With x264 I was in the 40+ FPS.

x265 is what I use exclusively for archiving my BD collection. I'll need to try the nightly build if the x265 encoder is really superior.

RF? You mean CRF?

For transparent results most people here use CRF=18 or lower for x264 (with "veryslow" encoding), which means roughly CRF=16 for x265.

I cannot believe your whole videos aren't totally washed out and blurry with your settings (medium/CRF18). Please post your screenshots (including the source) because what is "good" for you seems to far from transparent in terms of picture quality.

Last but not least at very high bitrates/transparent quality x265 still hasn't reached parity with x264.

[jhughy2010]

RF? You mean CRF?

For transparent results most people here use CRF=18 or lower for x264 (with "veryslow" encoding), which means roughly CRF=16 for x265.

I cannot believe your whole videos aren't totally washed out and blurry with your settings (medium/CRF18). Please post your screenshots (including the source) because what is "good" for you seems to far from transparent in terms of picture quality.

Last but not least at very high bitrates/transparent quality x265 still hasn't reached parity with x264.

No I don't mean CRF. I am talking about Constant Quality: 18 RF.

I use the x265 preset medium.

Medium RF18 for x265 looks as good if not better than medium RF20 for x264. I haven't played with a slower preset for x264.

I tried to upload the screen shot but the file size was 5MB and it exceeded the max file size. Compressing it will only lower the quality so it would ultimately make it pointless.

[foxyshadis]

CRF, RF, and Constant Quality are different names for the same thing. (Constant Quant being something else entirely.)

[LigH]

RF = "Rate Factor" is a quotient from the interna of the encoding algorithm used to "measure" the quality loss.

CRF = "Constant Rate Factor" just emphasizes the fact that this mode tries to keep the rate factor as constant as possible, staying below a threshold of quality loss.

The expression "Constant Quality" is not really exact. The resulting video won't have a constant subjective visual quality, just a more or less constant degradation.

[Tyler Pruitt]

What data format is the Mastering Display's RGB primaries in? Example:

--master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0"

I would have though it would be in xyY or XYZ.

[nevcairiel]

the first 3 pairs are the xy chromaticity coordinates of GBR respectively, WP the xy coordinates of the white point, all in increments of 0.00002, and L is the max display luminance in 0.0001 units.

Or to quote the spec:

display_primaries_x[ c ] and display_primaries_y[ c ] specify the normalized x and y chromaticity coordinates, respectively, of the colour primary component c of the mastering display in increments of 0.00002, according to the CIE 1931 definition of x and y as specified in ISO 11664-1 (see also ISO 11664-3 and CIE 15). For describing mastering displays that use red, green and blue colour primaries, it is suggested that index value c equal to 0 should correspond to the green primary, c equal to 1 should correspond to the blue primary and c equal to 2 should correspond to the red colour primary (see also Annex E and Table E.3). The values of display_primaries_x[ c ] and display_primaries_y[ c ] shall be in the range of 0 to 50 000, inclusive.

white_point_x and white_point_y specify the normalized x and y chromaticity coordinates, respectively, of the white point of the mastering display in normalized increments of 0.00002, according to the CIE 1931 definition of x and y as specified in ISO 11664-1 (see also ISO 11664-3 and CIE 15). The values of white_point_x and white_point_y shall be in the range of 0 to 50 000.

max_display_mastering_luminance and min_display_mastering_luminance specify the nominal maximum and minimum display luminance, respectively, of the mastering display in units of 0.0001 candelas per square metre. min_display_mastering_luminance shall be less than max_display_mastering_luminance.

[Chainmax]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2) (https://www.mediafire.com/download/vx21tk5hqla3h22/x265_1.7+470-86e9bd7dd192.GCC492.7z)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0) (https://www.mediafire.com/download/1dwbk5t22kac176/x265_1.7+470-86e9bd7dd192.GCC520.7z)

I tried the following settings:

x265_main12 --input ep1interm.avi --input-res 1280x720 --fps 29.97 --output Ep1.hevc --preset veryslow --tune grain --crf 40

On the first episode of a Yale lecture I filtered and upscaled to 720p. I then muxed the .hevc file and original .mp4 audio in MKVToolnix. Neither VLC nor MPC-HC with LAV could render the resulting file. Have I done something wrong, or is 12bit not decodable yet?

[LigH]

I am just quite surprised that you are feeding an AVI as input... since when does x265 support AVIs? I only know of raw YUV and YUV4MPEG (with simple header).

Usually I don't multiplex HEVC and audio to MKV, rather to MP4; the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.

[sneaker_ger]

x265 12 bit -> mkvtoolnix -> LAV (nightly) works for me.

the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.
I don't trust mp4box. There was (or still is?) a problem in connection with the MPC-BE splitter which L-Smash does not have.

[Motenai Yoda]

x265 [info]: HEVC encoder version 1.7+481-5dde4773fcef
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 12bit
x265 [info]: lowering VBV max bitrate to 12000Kbps
x265 [info]: lowering VBV buffer size to 12000Kb
x265 [info]: Main 12 profile, Level-4 (Main tier)

IIRC Main 12 L4.0 VBVs should be 18000kbps (also k should be lowercase IINW)

[foxyshadis]

I am just quite surprised that you are feeding an AVI as input... since when does x265 support AVIs? I only know of raw YUV and YUV4MPEG (with simple header).

Usually I don't multiplex HEVC and audio to MKV, rather to MP4; the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.

x265 will assume a raw YUV stream and produce garbage video in this case, but at least it should still play.

[Ma]

IIRC Main 12 L4.0 VBVs should be 18000kbps (also k should be lowercase IINW)

Confirmed, table https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels#Levels

[LazyNcoder]

Hi guys,
How can we get a clearer/sharper image? I know there's nr-inter nr-intra which make the oppsite results. I tried no-deblock + qblur 0 + cplxblur 0, but it didn't give me what I've been looking for. I feel x265 makes the image blur regardless of which bitrate/crf it uses.

Also, I read a lot about the banding issue in x265 in this topic. some users said aq-mode 1 would help it but I don't get a noticeable results with it. also I thing dither switch won't do anything in this matter. what's the best thing to do to make banding less without using 10/12bit encoding.

Thanks

[LoRd_MuldeR]

Hi guys,
How can we get a clearer/sharper image? I know there's nr-inter nr-intra which make the oppsite results. I tried no-deblock + qblur 0 + cplxblur 0, but it didn't give me what I've been looking for. I feel x265 makes the image blur regardless of which bitrate/crf it uses.

Also, I read a lot about the banding issue in x265 in this topic. some users said aq-mode 1 would help it but I don't get a noticeable results with it. also I thing dither switch won't do anything in this matter. what's the best thing to do to make banding less without using 10/12bit encoding.

Thanks

Why are you messing with the "--qblur" and "--cplxblur" options? Those are related to temporally blurring the quantizers, in order to limit quantizer fluctuations. It's probably not a good idea to set them to zero (or to change them at all). Just because there is "blur" in the name, doesn't mean they are going the blur the image! Also, turning off the deblocking filter completely (--no-deblock) probably isn't the best idea either. You can tune the "strength" of the deblocking filter via "--deblock=x:y" option. Some negative deblock offsets may be helpful here. Finally, to improve detail preservation, the Psy options (psychocisual optimizations) "--psy-rd" and "--psy-rdoq" probably are your best bet. Setting those options to a higher value should preserve more details (instead of blurring), but setting them too high is going to causes other problems! Note that Psy-RD is only effective at "--rd 3" or higher. And that Psy-RDOQ requires "--rdoq-level 1" or higher.

[x265_Project]

We were sent the final report today, and I'm happy to report that x265 was shown to be the best overall HEVC encoder. x265 was particularly strong in the universal and ripping (high quality) use-cases. http://x265.org/wp-content/uploads/2015/09/Figure-145-Ripping.png

http://x265.org/wp-content/uploads/2015/09/Figure-146-Overall.png

We're not allowed to share the whole report, but we are allowed to share selected graphs, as long as we link to www.compression.ru/video

[poisondeathray]

Congrats!

But that 1% lead over Intel in the "overall" category isn't much of a buffer for the lead - start working harder already or Intel might come back with a vengeance next time (joking :) )

I realize this isn't the final public version, but any reason why VP9 isn't represented on the "overall" category when it was on the previous graph ?

[foxyshadis]

I know VP9 is terribly slow, but how fast was the Intel software encoder relative to the x265 settings used? Also, did they release any actual streams or screenshots from them, so you could judge visual quality trade-offs?

[NikosD]

x264 is still very strong and taking into account encoding speed it is very attractive too.

@x265_Project

Is your ultimate goal to reach 50% of avg bitrate of x264, getting close to theoretical 50% bitrate of H265 compared to H264 ?

At what encoding speed ?

[Jamaika]

How is the result in this chart of HEVC Cyberlink?
I'm not convinced. It isn't known what settings were used for individual companies.

[LigH]

There have been only few commits during the last weeks. But today there is a nice bunch again. Also with some merges from the stable branch in between. So let's publish another package.

x265 1.7+497-975352b2c022 (GCC 4.9.2) (https://www.mediafire.com/download/cdo9c8yg5j9b0fp/x265_1.7+497-975352b2c022.GCC492.7z)
x265 1.7+497-975352b2c022 (GCC 5.2.0) (https://www.mediafire.com/download/be9fcq3ff0bsuzp/x265_1.7+497-975352b2c022.GCC520.7z)

[Parabola]

Isn't Y-SSIM a luminance-only metric thus favouring encoders that don't care about chroma? In previous comparisons, MSU methodology left me with cause for concern (even as a neutral observer). Nevertheless, nice work, Tom and team - looking forward to full report.

[nevcairiel]

Isn't Y-SSIM a luminance-only metric thus favouring encoders that don't care about chroma?

It is, they want you to buy the full report to get access to the full comparisons with combined luma and chroma scores.

[LigH]

Yay, another "clickbaiter" ... :mad: Reminds me on the first "exclusive news preview for iOS 9 users only" # (http://ptrace.fefe.de/applenews.png). The value of man is equal to their ability of being a consumer.

[x265_Project]

I know VP9 is terribly slow, but how fast was the Intel software encoder relative to the x265 settings used? Also, did they release any actual streams or screenshots from them, so you could judge visual quality trade-offs?

There were 3 use-cases... fast transcoding, universal and ripping, and all 3 tests were run on a desktop Core i7 and a dual Xeon server. Intel's accelerated encoder showed the best efficiency in the fast transcoding test, but had issues with rate control. We've made many improvements in both speed and real-time encoding algorithms (adding limit-refs, min-cu, etc.) since we submitted x265 to MSU back in March, so I think we should be able to do much better on this test today. We showed the best compression efficiency for the universal and ripping use-cases. We generally demonstrated better rate control than the rest.

They didn't share any bitstreams or screen shots for comparison, nor did they do any subjective video quality analysis. We have given them a number of suggestions for improving their test design, and a focus on subjective visual quality would be at the top of the list.

[aymanalz]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

[burfadel]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

I think to an extent it depends on the source material and resolution.

[CruNcher]

If intel can push the same results via Quicksync in the near Future it would be a pretty nice achievement for them i see neither Nvidia/AMD seemed to have participated with their Encoder Cores nor Ateme or even Mainconcept/DivX did this time :(

VP9 so far shows really nice promising results especially on the Decoding side Balance :)

[foxyshadis]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

Star is used in everything slower than medium, so it's not that bad. Full (esa) probably isn't worthwhile for anything but testing, it's not even used in placebo. me-range and lots of refs are other big ones that get less meaningful as they increase. An HEVC-specific barely-worth-it is subdividing the CUs into even more TUs (tu-inter/tu-intra).

"Worth it" is a loaded question, of those without a hard time budget many people have settled on medium preset as their optimal time/size/quality tradeoff, but some use the slower presets. It comes down to what feels right for you: An hour? A day? A week? I'm usually OK with a day or so per movie, despite knowing that the difference between that and a few hours is barely going to be noticeable, if at all.

[aymanalz]

Star is used in everything slower than medium, so it's not that bad. Full (esa) probably isn't worthwhile for anything but testing, it's not even used in placebo. me-range and lots of refs are other big ones that get less meaningful as they increase. An HEVC-specific barely-worth-it is subdividing the CUs into even more TUs (tu-inter/tu-intra).


What puzzles me is that none of the presets use umh at all. Superfast to medium use hex, and slow uses star. Is that an indication that umh is not ideal for a speed-time tradeoff?

[aymanalz]

"Worth it" is a loaded question, of those without a hard time budget many people have settled on medium preset as their optimal time/size/quality tradeoff, but some use the slower presets. It comes down to what feels right for you: An hour? A day? A week? I'm usually OK with a day or so per movie, despite knowing that the difference between that and a few hours is barely going to be noticeable, if at all.

I don't use presets, I manually tune each option. I agree that what is worth it is subjective. I asked the question because with x264, handbrake (or was it x264 itself?) used to warn that the compression gain will be very tiny in going from umh to esa, but the encode will be much slower. I was wondering if such a statement could be made for x265.

For instance, if going from umh to star provides only a 2% increase in quality, but takes twice as long to encode...something like that.

[shinchiro]

From my bitrate test on one of my samples, star is more faster from umh (about ~1.5 fps). The final size is almost same for both star and umh. The quality very closely on a par with --me umh. umh is slightly better at preserving details than star

[Jamaika]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?
There are two directions to minimal lost of quality. In a first bitrate, or the size of the movie. Secondly features 2-pass or stillImage for x264. The scale preset is for older computers. The fastest is me=dia, but the quality decreases, especially for dynamic movies.
In the settings motion estimation algorithm (dia, hex, umh, star) isn't only important to the quality of single frames from the original, but as the film is liquidity. Are there marked differences between frames (other texture, spots, vibration)? Doesn't the film seem too blur?
Descriptions of the conversion in the comments movies:
https://www.sendspace.com/filegroup/VcBRjHh6FpxzWdzolF2bUb1WuJA1z0TUnsRJ43LQ3kM
Edit: Conversion with "umh" better looking than with "star" for X265.
I think to an extent it depends on the source material and resolution.
This is the most important thing.

[burfadel]

So UMH looks less bad (not going to use one of the doom9's naughty words) than Star, subjectively (again, covering myself!). How does Star fair against Hex? There doesn't seem to be much speed difference between Hex and Star for me which is surprising, so if Star could be the more subjectively 'congruent to the original' option where people are looking for a little more supposed efficiency over the original, I'd probably use that from now on.

Sure I can see for myself, but I would like second and third opinions etc. I'm using CRF.

[CruNcher]

@x265_Project

Did Multicorewave analyzed V-Novas Perseus Patent fillings yet ?

https://www.google.com/patents/US8531321
https://www.google.com/patents/US20130294704
https://www.google.com/patents/US8977065

there are really a heavy bunch in all areas from replacing CABAC with lower complexity to supersampling reconstruction

More bandwith efficient SVC Partly Thomsons FGM seems to come back in full force this time

[x265_Project]

@x265_Project

Did Multicorewave analyzed V-Novas Perseus Patent fillings yet ?

https://www.google.com/patents/US8531321
https://www.google.com/patents/US20130294704
https://www.google.com/patents/US8977065

there are really a heavy bunch in all areas from replacing CABAC with lower complexity to supersampling reconstruction

More bandwith efficient SVC Partly Thomsons FGM seems to come back in full force this time
Interesting from a technology standpoint, but I wouldn't want to offer any legal analysis or opinions on the Doom9 forums.

When you license an encoder implementation like x265, you get the right to use that implementation, but the license doesn't cover patents, which must be licensed separately from the patent holders (MPEG-LA).

There is always a better coding standard in development. The next standard always promises significant gains over previous standards. Implementing a standard and getting a good % of the world to adopt your standard so that it is truly "standard" (supported by any device or platform that you want to use it on) are two different things. It's easier to do the first part than the second part. It's also easy to argue about why one standard is better than another, but in the end, individual companies and people vote by adopting or not adopting each standard.

For example - take a look at the survey that streamingmedia.com just did (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Encoding-2020-Experts-Predict-the-Future-of-Video-Encoding-106619.aspx).

Even though we run a business that is largely based on HEVC today, we don't have "codec religion". We're always ready to look at implementing new coding standards if there is a sustainable opportunity.

[Nintendo Maniac 64]

For example - take a look at the survey that streamingmedia.com just did (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Encoding-2020-Experts-Predict-the-Future-of-Video-Encoding-106619.aspx)

Wait, how do some of those numbers work when HEVC + HTML5 doesn't even seem to be on any browser maker's radar? (maybe except for Apple or Gstreamer-enabled Linux browsers) Obviously you don't need to worry about that for native apps on mobile and TV, but the HEVC + HTML5 thing seems like a bit of an elephant in the room to me...

[CruNcher]

Also they seem to fulfill one of the key promises HEVC was to introduce (Massive Parallelism) with their Nvidia announcement recently

which Multicorewave couldn't do fully efficient with OpenCL and only @ the Lookahead on x264 and no sign of anything x265 related yet

“Whereas legacy codecs are highly serialized, PERSEUS is able to harness all of the
processing power of NVIDIA GPUs. PERSEUS’ ability to distribute processing load across the entire GPU.

It's pretty crazy they come out of nowhere and have everything ready (they worked totally in Secret alongside the HEVC Standardization for years now)

This must be mainly the work of one of the Ex Argonaut Games GPU Developer working there

https://en.wikipedia.org/wiki/Argonaut_Games
https://en.wikipedia.org/wiki/Super_FX

[littlepox]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

[MeteorRain]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

Correction for you, it's between 1.7+436~437 and the commit was even in stable branch. Will probably post this to maillist as well.

[LigH]

Interesting from a technology standpoint...

V-Nova Perseus (http://forum.doom9.org/showthread.php?p=1715792) appears to be a kind of "noise modeller" (similar to a video version of "Spectral Band Replication" as used in audio formats like mp3PRO or HE-AAC), now that there are more details available. You may be casually interested in the implementation in a custom x264 build (http://forum.doom9.org/showthread.php?p=1741387#post1741387), provided I understood the very brief summary of CruNcher correctly... :sly:

[CruNcher]

Exactly that is what i read out of the patents so far a mp3PRO/HE-AAC approach

[kotuwa]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

Me too...

In version 1.7, the scene-cut is much different from 1.6.
I encoded the same sample using 1.6 and 1.7.
In 1.6, the keyframes are there in proper positions.
In 1.7, they are in insane positions, in the middle of the scenes…
And the whole video looks low quality compared to 1.6

While ago posted in http://x265.ru, as a comment, no reply there though...
:|

[microchip8]

Me too...

In version 1.7, the scene-cut is much different from 1.6.
I encoded the same sample using 1.6 and 1.7.
In 1.6, the keyframes are there in proper positions.
In 1.7, they are in insane positions, in the middle of the scenes…
And the whole video looks low quality compared to 1.6

While ago posted in http://x265.ru, as a comment, no reply there though...
:|

And why do you expect a reply there? Post on the x265 mailing list or open a ticket at https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

[Ma]

Post on the x265 mailing list or open a ticket at https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

You can test this nandaku2 patch first
https://www.mail-archive.com/x265-devel@videolan.org/msg08591.html
and open a ticket if it doesn't work.

[LigH]

This issue is already being addressed.

# HG changeset patch
# User Deepthi Nandakumar <deepthi@multicorewareinc.com>
# Date 1444115344 -19800
# Tue Oct 06 12:39:04 2015 +0530
# Branch stable
# Node ID aaf7fe7452b5c46e564d32ff52f2730a79ebaea1
# Parent 98ac099a766fc3eb6333fd5676b87a5933e1e3d0
slicetype: fix bugs in scenecut and slicetype decision

The default value of bScenecut had changed to false (instead of true) and this
was not accounted for correctly.

I guess we will soon have a fixed build. I will delay my weekly release for it.

[Motenai Yoda]

This issue is already being addressed.

# HG changeset patch
# User Deepthi Nandakumar <deepthi@multicorewareinc.com>
# Date 1444115344 -19800
# Tue Oct 06 12:39:04 2015 +0530
# Branch stable
# Node ID aaf7fe7452b5c46e564d32ff52f2730a79ebaea1
# Parent 98ac099a766fc3eb6333fd5676b87a5933e1e3d0
slicetype: fix bugs in scenecut and slicetype decision

The default value of bScenecut had changed to false (instead of true) and this
was not accounted for correctly.

I guess we will soon have a fixed build. I will delay my weekly release for it.

Seems fixed with a85011719ea1, it isn't?

[LigH]

Probably. But I'm missing a "merge with stable" commit, so I am not sure if a "tip" build would miss a few last changes in the "default" branch right now...

[Motenai Yoda]

I tried with a85011719ea1
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:21.640000 I
0:00:31.640000 I
0:00:41.640000 I
0:00:48.720000 I
0:00:49.560000 I
0:00:55.440000 I
0:00:55.840000 I
0:00:58.920000 I
0:01:03.880000 I
0:01:07.760000 I
0:01:12.280000 I
0:01:14.880000 I
0:01:18.440000 I
0:01:19.960000 I
0:01:20.520000 I
0:01:22.200000 I

and with edited f8b8ebdc545
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:21.640000 I
0:00:31.640000 I
0:00:41.640000 I
0:00:48.720000 I
0:00:49.560000 I
0:00:55.440000 I
0:00:55.840000 I
0:00:58.920000 I
0:01:03.880000 I
0:01:07.760000 I
0:01:12.280000 I
0:01:14.880000 I
0:01:18.440000 I
0:01:19.960000 I
0:01:20.520000 I
0:01:22.200000 I

1.7+417 for comparison
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:30.000000 I
0:00:40.000000 I
0:00:50.000000 I
0:01:00.000000 I
0:01:10.000000 I
0:01:20.000000 I

Looks like this was introduced by 4992f03 seems like a mistype
but I don't get why was added a new if statement instead of just adding m_param->bFrameAdaptive
in front the condition expression, as
if (m_param->bFrameAdaptive && m_param->scenecutThreshold && scenecut(frames, 0, 1, true, origNumFrames))
It will be Short-circuit_ed anyway, but I have no idea what I'm talking about.

[x265_Project]

Me too...
While ago posted in http://x265.ru, as a comment, no reply there though...
:|
That will get you nowhere. There are many ways to get in touch with us. For bugs, the best way is to file an issue on our Bitbucket issues tracker (https://bitbucket.org/multicoreware/x265/issues).

[x265_Project]

The team is working to fix the scene detection bug. We'll update you when a fix is available. This fix is required before we apply the v1.8 tag.

[LigH]

I'll keep checking for commits during the next days more regularly then. :)

[LigH]

x265 version 1.8 has been released. This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.

Full documentation is available at http://x265.readthedocs.org/en/stable/

=================================== API Changes ========================================================
Experimental support for Main12 is now enabled. Partial assembly support exists.
Main12 and Intra/Still picture profiles are now supported. Still picture profile is detected based on x265_param::totalFrames.
Three classes of encoding statistics are now available through the API.
x265_stats - contains encoding statistics, available through x265_encoder_get_stats()
x265_frame_stats and x265_cu_stats - contains frame encoding statistics, available through recon x265_picture
--csv
x265_encoder_log() is now deprecated
x265_param::csvfn is also deprecated
--log-level now controls only console logging, frame level console logging has been removed.
Support added for new color transfer characteristic ARIB STD-B67
================================== New Features ========================================================
limit-refs
This feature limits the references analysed for individual CUS.
Provides a nice tradeoff between efficiency and performance.
aq-mode 3
A new aq-mode that provides additional biasing for low-light conditions.
An improved scene cut detection logic that allows ratecontrol to manage visual quality at fade-ins and fade-outs better.
=============================== Preset and Tune Options ===================================================
tune grain
Increases psyRdoq strength to 10.0, and rdoq-level to 2.
qg-size
Default value changed to 32.

After fixing the scene change adaption, here is the new milestone as "merge with stable" build:

x265 1.8+2-55a4a9b920ff (GCC 4.9.2) (https://www.mediafire.com/download/qc8hxld632d8lo7/x265_1.8+2-55a4a9b920ff.GCC492.7z)
x265 1.8+2-55a4a9b920ff (GCC 5.2.0) (https://www.mediafire.com/download/hse8exx6qa1b6xz/x265_1.8+2-55a4a9b920ff.GCC520.7z)

[Barough]

Thnx for the new v1.8 compile LigH :)

[birdie]

So has version 1.8 been released or not?

http://ftp.videolan.org/pub/videolan/x265/ doesn't have it
https://bitbucket.org/multicoreware/x265/downloads no sign of it here.

[nandaku2]

So has version 1.8 been released or not?

http://ftp.videolan.org/pub/videolan/x265/ doesn't have it
https://bitbucket.org/multicoreware/x265/downloads no sign of it here.

Just uploaded to Bitbucket. The Videolan folks should be manually okaying the upload soon, I guess....

[LigH]

I "monitored" the source repository (checking each few hours) and compiled as soon as the sources were commited with a "merge with stable". Releasing binaries will take a while for every provider until they notice the new sources and start the compilation...

[x265.cc]

1.8+28-f8ad1ff7074a now at https://encoder.pw (New builds every ~15 minutes)

[foxyshadis]

Changes pushed since 1.8 was tagged include: 10-bit overflow fixes for rd and psy-rd, big speedups in SAO (~5% faster total encode when it's used), more 12-bit assembly, and a few misc little speedups. Most of them had been on hold while the scenecut bug was being fixed, it's pretty good to see the hard work still going into this.

[birdie]

Is 1.8 any better than 1.7 at details retention or we're not yet there?

[xxxxx]

Is 1.8 any better than 1.7 in banding (aq-mode 3) or we're not yet there? :)

[LigH]

Test it, tell us. :)

[littlepox]

Currently for high-quality ripping, I believe x265 is better than DivX or EasyRealProducer(rm/rmvb encoder), but still worse than x264 for detail retention.

[Barough]

x265 still have a bit to go on the detail retention part comparing to x264. Did a test with the 'aq-mode 3' enabled on a rather dark movie (Blade Runner) and the result was rather nice imo. But the video size increased with ~35% comparing to when using 'aq-mode 2'.

Something i really hope that will be improved soon is the encoding speed in general for x265.

[birdie]

On my low quality very dark source (17Mbit AVC video)

-preset veryslow -x265-params keyint=600:min-keyint=30:bframes=16:crf=17.5

1.8 improves 1.23% sizewise, IOW x265 1.8 encodes slightly more efficiently than v1.7. I haven't compared the resulting video clips yet.

Edit: v1.8 output is quite different however x265 still blurs everything out vs. x264 at comparable bitrate (which is in my case circa 3.2Mbit/sec for 720p@30fps quite static very dark video containing a lot of noise).

[LigH]

Check the recent changes related to "--tune grain", may be interesting to know which paramters need tweaks to retain noise.

I believe the main reason for detail reduction is the difference between AVC and HEVC algorithms in general... to be proven wrong, some day. ;)

[edison]

Does it support RGB lessloss mode now ?

[foxyshadis]

It's supported RGB lossless since... 1.1? 1.2? At least a year ago. Just use --colormatrix GBR, or for better compression, convert to 10-bit YCoCg and use --colormatrix YCgCo.

[Nazgul]

x265 still have a bit to go on the detail retention part comparing to x264. Did a test with the 'aq-mode 3' enabled on a rather dark movie (Blade Runner) and the result was rather nice imo. But the video size increased with ~35% comparing to when using 'aq-mode 2'.

Something i really hope that will be improved soon is the encoding speed in general for x265.

Which raises one obvious question, how aq-mode 3 looks compared to the other aq modes when the file sizes are normalized, either by adjusting the crf value or by doing 2-pass encodes at the same bitrate.

[benwaggoner]

Which raises one obvious question, how aq-mode 3 looks compared to the other aq modes when the file sizes are normalized, either by adjusting the crf value or by doing 2-pass encodes at the same bitrate.
Yeah, since aq-mode 3 reduces quantization in dark regions, it makes sense that it would raise file size at the same CRF with dark content. However, for dark content it should also raise the CRF required to look good, since it will reduce banding and blocking in dark regions.

[Nintendo Maniac 64]

Compression.ru's 2015 video encoder test results were released:

http://compression.ru/video/code...son/hevc_2015/

Included are x265, and x264, and VP9 along with other HEVC encoders.

[mariush]

The proper link is this one: http://compression.ru/video/codec_comparison/hevc_2015/

[littlepox]

The proper link is this one: http://compression.ru/video/codec_comparison/hevc_2015/

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

[LigH]

Weekly default build with several additional fixes after the milestone stable:

x265 1.8+31-b6156a08b1de (GCC 4.9.2) (https://www.mediafire.com/download/sv9x87fc9z16wyf/x265_1.8+31-b6156a08b1de.GCC492.7z)
x265 1.8+31-b6156a08b1de (GCC 5.2.0) (https://www.mediafire.com/download/4bdvlk9w5n336qb/x265_1.8+31-b6156a08b1de.GCC520.7z)

[birdie]

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

In short they were biased towards HEVC so they chose the parameters to improve its standing.

[littlepox]

Yeah, since aq-mode 3 reduces quantization in dark regions, it makes sense that it would raise file size at the same CRF with dark content. However, for dark content it should also raise the CRF required to look good, since it will reduce banding and blocking in dark regions.

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.

[benwaggoner]

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.
Ah. I was speaking about 8-bit encoding, not 10-bit. In 10-bit, the low-luma blocking and banding is much less of a problem in the first place.

[littlepox]

Ah. I was speaking about 8-bit encoding, not 10-bit. In 10-bit, the low-luma blocking and banding is much less of a problem in the first place.

For 8bit, our test suggest x264 is a far better choice with techniques involving adding ordered dither noise. Ordered dither noise is famous for its resilience to DCT-based lossy compression, so you may add a little (just a little, not much, not even visible) noise on the dark site and then feed it to x264, tweaking parameters of aq/psy-trellis/fgo to keep the noise pattern. You can get very a nice, band-less result even in a low bit-rate, and the cost is surprisingly cheap. In short, with certain well-designed techniques, x264-8bit can do almost as good as 10bit.

However, such technique fails on x265 miserably because x265 just washes the noise away, leaving a clean, banded dark-site, no matter how hard you tweak the parameters, daydreaming to keep the noise pattern.

[nandaku2]

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.

@littlepox: can you share a link to your source, and the commandlines you have used.

When we ported aq-mode 3 from x264, we did a bunch of tests tweaking for HEVC encodes, (also implementing some new Just Noticeable Distortion biases). Would it be useful to post these patches - I'm sure we could use some crowd-testing help for the visual quality problems.

[littlepox]

@littlepox: can you share a link to your source, and the commandlines you have used.


Due to the forum rules we are not supposed to share the source here (they are mostly Blu-Ray sources); but we did test them on multiple sources, from anime to movie.

Sources are usually in very good quality(as expected from BD), very little grain (so it makes sence to try x265).

For anime, the parameters are:

--preset slower --crf 16.0 --ctu 32 --max-tu-size 16 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1/3 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16

or you can change crf to npass, but make sure the output is about at a similar bit-rate and quality.

For films, the parameters are:

--preset slower --crf 19.7 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1/3 --aq-strength 1.0 --rd 5 --psy-rd 0.7 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.8 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

These custom settings are the ones we explored as --tune animation and --tune film. We don't bother do do the test on default settings or tuning since the output is so outperformed.

[~ VEGETA ~]

anyone tried encoding in 12-bit? like anime episode or something similar to see the effectiveness of using 12-bit HEVC. How about playback?

[Nintendo Maniac 64]

The free report for Compression.ru's 2015 video encoder tests are now available.

Here's the URL again for your convenience:
http://compression.ru/video/codec_comparison/hevc_2015/

Note that some encoders are only included in the "Ripping" section, such as f265 and VP9.

[CruNcher]

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

VP9 can have very beautiful detail retention and temporal grain/noise reproduction

bultje and dark shikari had a lot of discussion about that seems it inspired bultje to keep on track of x264s psy results ;)

https://people.gnome.org/~rbultje/vp9/etv5k-vp9-b5000.webm (also nice for generational transcoding tests)

https://people.gnome.org/~rbultje/vp9/etv5k.png
http://i2.sendpic.org/t/ez/ez0kjYthGP5AKGkK4C3c9Gpc0AN.jpg (http://sendpic.org/view/2/i/1wvva6E5yBdAp9EIKN710o2ltC1.png)

https://people.gnome.org/~rbultje/vp9/etvbr.png

[Motenai Yoda]

VP9 can have very beautiful detail retention and temporal grain/noise reproduction

bultje and dark shikari had a lot of discussion about that seems it inspired bultje to keep on track of x264s psy results ;)

IMHO vp9 try to retain grain a bit too much

[Boulder]

Isn't the idea of an Holy Grail-type encoder to try to represent the source as it is with the lowest possible bitrate? The user will then have all the power to remove things that don't please him beforehand.

[nevcairiel]

Isn't the idea of an Holy Grail-type encoder to try to represent the source as it is with the lowest possible bitrate? The user will then have all the power to remove things that don't please him beforehand.

The holy grail is to discard that information that the user won't notice anyway - since you need to throw away something, or you're a lossless codec. :)

[Boulder]

The holy grail is to discard that information that the user won't notice anyway - since you need to throw away something, or you're a lossless codec. :)Yes, should have clarified "represent the source visually as it is" :)

[littlepox]

2 problems with x265's loss of grain:

1. If we are encoding at a very low bit-rate where all we care is a watchable visual quality, then we are happy if x265 throws away the unimportant grain and focuses on actual details. However, if we allow more bit-rate for a better quality, film grains do play a role in maintaining the visual similarity between source and encode. It's not the most important measure, but still it has a seat.

2. Its predecessor, x264, can free us from worries without raising bit-rates or encoding time. One may argue that the washed image from x265 gives a better PSNR/SSIM output or whatever test metric, but we just don't care.

[foxyshadis]

It's more that x265's shepherds are a bit stymied on how to maximize quality without removing all the gains HEVC gives. There's tune-grain already, and that helps a lot, but it also hurts a lot bitrate-wise, to the point that you wonder why not stick with x264. The main sin seems to be that it doesn't tune more toward grain as the rate goes up, because HEVC should always be able to match x264 at any bitrate, even if it has to mostly restrict itself to AVC's capabilities. The bigger the transform you use, the more low-frequency detail you get but the less high-frequency (grain or noise); AVC uses 4x4 or sometimes 8x8 while HEVC has to select from 4x4, 8x8, 16x16, or 32x32, and somehow balance grain, and while it does the job very well for pretty much all of its video-conferencing customers, the logic is still too complex for satisfying us hardcore home users.

I mean, when it comes right down to it, noise is inherently incompressible, and grain is nearly so... despite the hype, you can't expect much improvement if you want to keep grain.

Still, I hope that someday someone will devise an elegant way to tradeoff noisy and clean, and no one will have to worry about the technical workings anymore.

[CruNcher]

Perseus can give this advantage that HEVC alone misses currently, it's the cherry on top ;)

[benwaggoner]

It's more that x265's shepherds are a bit stymied on how to maximize quality without removing all the gains HEVC gives. There's tune-grain already, and that helps a lot, but it also hurts a lot bitrate-wise, to the point that you wonder why not stick with x264. The main sin seems to be that it doesn't tune more toward grain as the rate goes up, because HEVC should always be able to match x264 at any bitrate, even if it has to mostly restrict itself to AVC's capabilities. The bigger the transform you use, the more low-frequency detail you get but the less high-frequency (grain or noise); AVC uses 4x4 or sometimes 8x8 while HEVC has to select from 4x4, 8x8, 16x16, or 32x32, and somehow balance grain, and while it does the job very well for pretty much all of its video-conferencing customers, the logic is still too complex for satisfying us hardcore home users.

I mean, when it comes right down to it, noise is inherently incompressible, and grain is nearly so... despite the hype, you can't expect much improvement if you want to keep grain.

Still, I hope that someday someone will devise an elegant way to tradeoff noisy and clean, and no one will have to worry about the technical workings anymore.
I think the key is not to encode the grain you have, but the grain you want. Give the same visual experience in a much more compressible way. I don't think x264 is doing a better job of accurately representing the actual source grain, but with mbtree and film grain optimization, it keeps the feel of the original grain better. But you'll see the grain move a lot less from frame to frame; it's more of a texture than completely temporally random noise. And the grain particles themselves will be somewhat softer, while the non-grain retains its sharpness.

[CruNcher]

I like Atemes HEVC Encoder results they seem already pretty stable in Temporal Grain Retention but Bitrate is obvious very high in all the Encoder results :)

ATEME Titan KFE 3.5.1 (4.5.1.0) (older results)


http://i1.sendpic.org/t/6h/6hBhtWQwjChJ91CYzz1lIZWpA8.jpg (http://sendpic.org/view/1/i/2TeJwHvgmTBOKc5gmx8NUoSGPSs.png)
http://i2.sendpic.org/t/9F/9FS5eKHSlwuS32932OWoPwYZlK7.jpg (http://sendpic.org/view/2/i/3fqdiun2qkVqSYZkTrzTCaxj3dg.png)
http://i1.sendpic.org/t/A0/A0pD4w1bqLIX0vQcSP8U5BI2L8b.jpg (http://sendpic.org/view/1/i/cDLnsK2mlYjJMbsO67TaN4DYDog.png)
http://i1.sendpic.org/t/jL/jLI2LWSKFNm3ziRCitvwKBZFNtS.jpg (http://sendpic.org/view/1/i/lVunEEzi3uE1B2BiILok02p4aH9.png)
http://i1.sendpic.org/t/y8/y8EQFGA9NM2009J2WTD2zXAu2Uq.jpg (http://sendpic.org/view/1/i/w56yBGE1Gmx1oDPTOOJw2s15AdS.png)



http://i1.sendpic.org/t/rS/rSikeffL2WmYQOqa8b7IAE0VPgv.jpg (http://sendpic.org/view/1/i/UgUoEs3AY4cLYpmtMw8HJlhUKO.png)

http://i1.sendpic.org/t/mr/mrTD2dsmuwZEm6ejuS98BXfup0U.jpg (http://sendpic.org/view/1/i/vmdk5n7fQ6I50ANKbQch8IjRNWp.png)

http://i1.sendpic.org/t/jh/jhtST3ClasCHH9ouc1AOlEoZbyK.jpg (http://sendpic.org/view/1/i/2N9JgmwxnA5fNKJFTC2YT2GRBGP.png)

http://i1.sendpic.org/t/rN/rNRIA9AhlqmM3vHpmEcycSW3iYm.jpg (http://sendpic.org/view/1/i/qz2ardTCXCPNRIbqxacMVhF8v33.png)

http://i2.sendpic.org/t/mq/mqZ9NHfqLl1IKWWQBpYIhwmwlZZ.jpg (http://sendpic.org/view/2/i/v62HFlmoUb6e4rdakgWMrGIAmL3.png)

http://i1.sendpic.org/t/cO/cO6oF0n8TMPjoNCgI8ehI7D3Qqd.jpg (http://sendpic.org/view/1/i/gQcCvugZFLAjQGJoep7sYtKrq8D.png)

Samsung seems to almost uniquely position the Encoder in Koreas Broadcast Environment also

As we all know Atemes Engineers where the only ones that conquered x264s psy and overall efficiency and they contributed to HEVC after that as well ;)

Whats really nice and Bad the Viewers gonna realize CGI Post Studio (Artificial) Grain and it's use per Scene for the first time much heavier, it will be really interesting how they gonna react when Scenes change their amount of Grain so heavily, are they gonna start and realize this inconsistency while watching ? :D

From extreme Grain to virtually no Grain @ all but Crystal Clear Digital IMAX 3D and CGI Render Results, everything for the Viewers eyes to enjoy or get disturbed with ? ;)

These Encoder results are though already outdated

[Audionut]

They should stop adding grain to the source. Make it a specific playback option, complete with decoder flags and the whole shebang.

So your content creator can specify in the flags that the playback system adds grain 2.3, which specifies the playback device to add a specific type of grain at playback.
Then the source becomes significantly easier to code within a limited bandwidth, the delivered product to the consumer becomes significantly easier to encode for people like us at this forum, and the grain in all it's glory gets added at playback.

Heck, the encoders could even be made aware of the grain being added at playback, and use this information to further improve encoding efficiency.

[LigH]

Weekly build; contains a linking order bugfix and a new option:
--intra-refresh Use Periodic Intra Refresh instead of IDR frames
Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe.
I could imagine that this feature might be incompatible with some consumer devices or authoring standards, who knows ...

x265 1.8+49-f335a9a7b908 (GCC 4.9.2) (https://www.mediafire.com/download/88u8tht6bzuxw1u/x265_1.8+49-f335a9a7b908.GCC492.7z)
x265 1.8+49-f335a9a7b908 (GCC 5.2.0) (https://www.mediafire.com/download/c4rap3f995kc4fq/x265_1.8+49-f335a9a7b908.GCC520.7z)

[CruNcher]

They should stop adding grain to the source. Make it a specific playback option, complete with decoder flags and the whole shebang.

So your content creator can specify in the flags that the playback system adds grain 2.3, which specifies the playback device to add a specific type of grain at playback.
Then the source becomes significantly easier to code within a limited bandwidth, the delivered product to the consumer becomes significantly easier to encode for people like us at this forum, and the grain in all it's glory gets added at playback.

Heck, the encoders could even be made aware of the grain being added at playback, and use this information to further improve encoding efficiency.

Some smart people thought long way back of how this could be achieved on the playout side ;)
What you imagine is existing already developed by Thomson and part of the AVC Standard ;)

https://hopa.memberclicks.net/assets/documents/thomson_fgt_hpa2006.PDF

[sneaker_ger]

It's also in the HEVC specs but no one uses it, not least since it's optional for decoders. It's not in-loop.

[Stacey Spears]

Some comments about the x265 docs w/r/t --master-display. (http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--master-display)

1st. The example provided says it is for P3. Here is what is presented: G(13200,34500)B(7500,3000)R(34000,16000) The G value is incorrect, 13200 produces 0.264. The G value should be 13250, which produces 0.265.

The next question I have is for the L value. From the x265 docs: L(%u,%u)” where %u are unsigned 32bit integers. From table 5 of CEA-861.3: Data Bytes 19 – 20 specify a value for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m2... This is the same as the primaries and white point. Everything is using UINT16 per 863.1.

edit: Looks like the HEVC spec is calling for UINT32.

[x265_Project]

Some comments about the x265 docs w/r/t --master-display. (http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--master-display)

1st. The example provided says it is for P3. Here is what is presented: G(13200,34500)B(7500,3000)R(34000,16000) The G value is incorrect, 13200 produces 0.264. The G value should be 13250, which produces 0.265.

The next question I have is for the L value. From the x265 docs: L(%u,%u)” where %u are unsigned 32bit integers. From table 5 of CEA-861.3: Data Bytes 19 – 20 specify a value for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m2... This is the same as the primaries and white point. Everything is using UINT16 per 863.1.

edit: Looks like the HEVC spec is calling for UINT32.
Hi Stacey,
We'll take a look at this. In the future, the best place for experts like you (or anyone who is reasonably sure they know what they are talking about) to report bugs is our x265 Issues Tracker (https://bitbucket.org/multicoreware/x265/issues).

Tom

[x265_Project]

Intra-refresh isn't used for high quality encoding for streaming or file-based playback. It's helpful in real-time low latency video applications. Spreading the intra-predicted blocks out across multiple frames means that you don't have one really big I frame followed by smaller P and B frames. In low-latency applications through a fixed channel bandwidth, this is helpful. Of course there are trade offs to overall compression efficiency. With a moving camera or moving subjects prediction suffers as you don't have a single stable reference frame that captured everything. But for fixed-camera low-latency video (like video conferencing), intra-refresh can be beneficial.

[sneaker_ger]

I was answering to the posts about the grain modeling, not talking about periodic intra refresh.

[x265_Project]

I was answering to the posts about the grain modeling, not talking about periodic intra refresh.
Ahh... my mistake.

[Sagittaire]

Bug Report

x265 v. 1.849 report intra refresh problem in multipass mode between first and second pass. But I don't touch intra-refresh setting between first and second pass.


x265.exe --input hp.yuv --output crf23.265 --input-res 720x304 --fps 25 --bitrate 450 --qcomp 0.75 --pass 1 --stats hp.log --preset veryslow --aq-mode 0 --aq-strength 0.0 --psy-rd 0 --rdoq-level 0 --psy-rdoq 0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim

x265.exe --input hp.yuv --output crf23.265 --input-res 720x304 --fps 25 --bitrate 450 --qcomp 0.75 --pass 3 --stats hp.log --preset veryslow --aq-mode 0 --aq-strength 0.0 --psy-rd 0 --rdoq-level 0 --psy-rdoq 0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim

[Ma]

x265 v. 1.849 report intra refresh problem in multipass mode between first and second pass.

Reported: https://bitbucket.org/multicoreware/x265/commits/1bcfea4372d90ceca3db6c262eaaf191#comment-2434983

If you can't wait for patch, find "intra_refresh" in source/encoder/ratecontrol.cpp and replace with "intra-refresh".

[jlpsvk]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

[~ VEGETA ~]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

you mean encoding without having banding? I have interest in that too. H.264 10-bit does GREAT job in that, but I need to know if HEVC 10-12 bit can do similar job with less size.

BTW, anyone knows if 12 bit gives smaller size that 10 bit? any page that explains this?

[LigH]

I believe the developers already explained that 12-bit encoding is rather meant for encoding of higher original component precision (like medical images), it may not have much more advantage over "10-bit compared to 8-bit depth" for common video sources (means, you may recognize a difference between 8 and 10 bit easily, but between 10 and 12 bit hardly). And it may require more bitrate. 10 bit encodes being more efficient than 8 bit in many cases is rather lucky, but you should not extrapolate: The more diverse values an entropy encoder (like Huffman or Arithmetic Coding) has to process, the worse the compression usually gets.

[~ VEGETA ~]

I believe the developers already explained that 12-bit encoding is rather meant for encoding of higher original component precision (like medical images), it may not have much more advantage over "10-bit compared to 8-bit depth" for common video sources (means, you may recognize a difference between 8 and 10 bit easily, but between 10 and 12 bit hardly). And it may require more bitrate. 10 bit encodes being more efficient than 8 bit in many cases is rather lucky, but you should not extrapolate: The more diverse values an entropy encoder (like Huffman or Arithmetic Coding) has to process, the worse the compression usually gets.

well, 12 bit requires more bitrate than 10 bit? I didn't think it is like this because 8 vs 10 was different. Do you have some reliable source?

I don't care about how much difference would exist between 10 and 12 as long as it is better (12)... as I don't care about encoding speed and stuff like that.

[LigH]

I said "it may", not "it does always". It will probably depend a lot on the material; 10 bit depth encoding more efficiently than 8 bit will probably not always be true either, I mainly know such reports from cartoon content. In theory, quantizing to at most 1024 instead of 256 different values (ignoring the limits of "TV range") should be harder to compress because there can be 4 times as many different values to compress. And with 12 bit, there are 4096 different values per component, so once again 4 times the amount. So why should it get even smaller in general?

But "smaller size at the same quality" is nonsense anyway. You can't measure absolute quality. Quality is relative (always compared to another sample) and subjective (depends on the viewer). Size is objective. You can measure file size. You can try to make three videos with almost the same size as good as it gets, then compare which has the best quality in your personal opinion. And you can ask hundreds of people to do the same, and gather statistics how many of them preferred which clip.

By the way, how many tests did you make on your own before asking?

[jlpsvk]

yeah...i meant banding...

[LigH]

Banding is often a result of quantization limits reducing the accuracy of the bitdepths of color components even further. A higher bitdepth increases the accuracy first, but the quantization needs to reduce it even more then to reduce the diversity of values for the entropy encoding ... tl;dr: maths – getting more accurate first gives a little better chance to not loose as much accuracy later, so increasing the bitdepth from 8 to 10 bit is useful to avoid banding. But that may be enough ... increasing further to 12 bit may not support accuracy noticably anymore, just worsen the compressibility, I guess. To be tested with a lot of different material ...

[~ VEGETA ~]

But "smaller size at the same quality" is nonsense anyway

Perhaps you didn't get me right. I meant using the exact same settings like --crf 17 --aq-mode 3 ....etc, using 8-bit and 10-bit. Here, 10-bit gives less file size with better quality, especially with the banding and some details. Perhaps "same quality" is a bad word choice.

As you know, 10 bit allow more accuracy (more values) than 8 bit (color values...), so when you say use Dither to filter the stupid banding, it gives lots of values that you must store! using the same crf, 8 bit has less values than 10 bit which will allow 10 bit to give a better result always. If you want the same quality with 8 bit, you must lower the crf, which will give a bigger file size always. Tl;DR: you can conserve details and get good quality in 10-bit without lowering CRF. In 8 bit, you must. Which gives a smaller size in 10bit.

BTW, file size is subjective too. One may find 400mb too small and someone else find it a lot. So, by the same concept, you can not say "my encode gives small size". However, nowadays people can tolerate 400-600mb per episeode (720p-BD-10bit), so it is not really important.

By the way, how many tests did you make on your own before asking?

Many... but with x264. I didn't use x265 yet as I can not now... that is why I am asking. What got my interest is the 10 vs 12 bit in terms of quality and file size, which I did not get satisfying answer to it yet.

[LigH]

Well, so you did never read the warnings about CRF: "never compare results with the same CRF but different options otherwise" ... "--crf 17 -D 10" may cause a similar size as "--crf 17 -D 8", or not, who knows. The development of the relation between rate factor and size with different CRF values is probably different for 8 bit depth and 10 bit, imagine curves with a different slope: You can't find one scale factor that will make match both for more than a small range.

And no, file size is objective. Two files of the same size have the same size on any PC. Independent of the content. What is subjective about videos with a specific size, is if this size is enough for a satisfying quality. Of course, different movies have a different demand of bitrate to provide "enough quality to be satisfied".

[foxyshadis]

Anyone can easily see 8-bit banding on even a terrible monitor. It takes a high-end studio monitor and well-trained eyes to spot banding on 10-bit, so visible quality will not increase by moving to 12-bit. Further, the raw efficiency increase due to better matches for increasing the bit-depth is logarithmic; the increase from 6 to 8 bits would be enormous, from 8 to 10 bits slightly noticeable, from 10 to 12 bits minuscule, and lost in the noise. And that's for relatively clean sources. With enough bits, the increase always eventually stalls and goes backwards, as there's more detail/noise in the low bits to attempt to record in most sources.

12-bit is designed more for archival, so that more bits can be put to good use to preserve little shadow and color detail for later re-grading, that would otherwise be lost. That's what high-depth jpeg2000 and motion-jpeg2000 are already used for.

I gave it a couple of tests, but unlike 10-bit, I see no reason to ever move to it unless I'm archiving my own personal projects.

[xxxxx]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

I did a few test recently, unfortunatelly there is no impovment at all. The new aq-mode 3 just add more bitrate the dark areas wich can help a very little but overall i had the same terrible banding as always. Also, can't see any significant improvment in detail preserve. This 2 issue exists from the beginning, seems developers just ignore them.
I'll check again a year later...

[LigH]

... seems developers just ignore them.

Such insults may be a reason to stop public testing... :angry:

Don't demand miracles for free. Be grateful for the development progress already shared with you. And don't complain that they prefer to develop first the tasks they get paid for...

The developers already stated that they would return to investigating detail loss further when they completed 12-bit encoding and related tasks requested by their commercial partners.

[~ VEGETA ~]

Well, I am convinced that quality gained from 12 bit is very little compared to 10 bit. However, if someone has a powerful encoding machine and doesn't give a damn about encoding/releasing time (like me), it is always good to encode in 12 bit. Especially that moderate devices these days (core i3) runs 1080p-12bit-HEVC very nicely.

I guess this is what you meant by archiving, except that it will be a real release.. because some people are too old for weekly fansubbing &___&, thus they release once/month or something very lazy.


If you tried enough, will encoding in 12 bit be less size than 10 bit while having the exact same settings and source (and everything)?

[MeteorRain]

If you tried enough, will encoding in 12 bit be less size than 10 bit while having the exact same settings and source (and everything)?

12 bit, by the number itself, will cost 20% more bitrate than 10 bit. After that, you start stripping the information encoded to reduce the bitrate back to the same level as 10 bit. So it's hard to say 12 bit will always be more efficient than 10 bit, but we'll see.

And, for the same QP (I'm not saying CRF because it's a flexible concept), 12 bit will be bigger than 10 bit. (And the same applies to 8 bit vs 10 bit.)

[Sagittaire]

12 bit, by the number itself, will cost 20% more bitrate than 10 bit. After that, you start stripping the information encoded to reduce the bitrate back to the same level as 10 bit. So it's hard to say 12 bit will always be more efficient than 10 bit, but we'll see.

And, for the same QP (I'm not saying CRF because it's a flexible concept), 12 bit will be bigger than 10 bit. (And the same applies to 8 bit vs 10 bit.)


Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

Anayway like Ligh say, comparison must be to do always at the same size . It's not subjective condition. It's really easy to make encoding at same crf or quantizer with really different size (use different quantizer matrix for exemple). Crf and quantizer doesn't mean anything for quality. crf at 17 with all coef at 255 in quantizer matrix will produce less quality than crf at 30 with all coef at 4.

[nevcairiel]

Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

The main reason why this was so efficient for H264 does not apply to HEVC anymore though, so the gains should be smaller, and moving from 8 to 10 will still have considerably more benefit than going from 10 to 12 (for native 8-bit content).

On top of that, there is the argument that many decoders may not be very well optimized for 12-bit decoding. But then, since when did Anime folks care about that, huh.
Personally I would stay away from 12-bit, unless your source is that high bitdepth already.

[~ VEGETA ~]

Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

Anayway like Ligh say, comparison must be to do always at the same size . It's not subjective condition. It's really easy to make encoding at same crf or quantizer with really different size (use different quantizer matrix for exemple). Crf and quantizer doesn't mean anything for quality. crf at 17 with all coef at 255 in quantizer matrix will produce less quality than crf at 30 with all coef at 4.

By using the same source and settings we can see the difference, and it is a good comparison. I don't use per-defined bitrate, only CRF.

Comparing 2 encodes using the same settings is always a good choice if not the best. The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

This theory applies to 10 vs 12 too, regardless of the real visible difference. If my post has mistakes, please show them to me.

[LigH]

The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

Well, now this is illogical. Did you ever try to understand "entropy encoding" using the works of Claude Shannon, Robert Fano and David A. Huffman? ... Maybe too complex for someone not graduated in Computer Science; let's have a look at the Morse code table, even though it is not binary but has even four different states (short and long signal, short and long break).

Which letters have the shortest Morse codes? The most commonly used letters in English language: E and T. The more less commonly used letters you take into account, the longer their codes get. And when even numbers and specific telegraphy states where added, they already required 5 elements.

I hope it gets obvious that the more different entities have to be encoded, the longer the required code words get, the harder the data is compressible. The exception for 8 vs. 10 bit depth is that both get quantized before compression. Quantization means losing precision, losing quality.

Imagine, the compression is done on 7 bit precision in both cases to achieve a similar size after encoding; then the 8 bit encode loses 1 bit, the 10 bit encode loses 3 bit. So why may it still give better quality? ... Because calculating YUV values out of RGB samples in only 8 bit already lost some precision, it did a kind of "quantization before quantization". And this was done regardless of the available bitrate, regardless of frequency components after the transformation from samples to visual frequency spectrums per (macro-) block.

Converting 8 bit RGB values to YUV values with only 8 bit precision was "content independent quantization". Reduction of psychovisually relevant frequency components is content dependent quantization, thus more subjectively satisfying. Converting 8 bit RGB to 12 bit YUV would not give you much more useful precision for a later quantization of frequency components, compared to 10 bit YUV values, because both will lose a considerable amount of precision (and both will lose more precision than the already rather coarse 8 bit results) when their frequency component values will be quantized later.

[Sagittaire]

By using the same source and settings we can see the difference, and it is a good comparison. I don't use per-defined bitrate, only CRF.

Comparing 2 encodes using the same settings is always a good choice if not the best. The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

This theory applies to 10 vs 12 too, regardless of the real visible difference. If my post has mistakes, please show them to me.

No simply that like you say, 8 bits and 10 bits are not same setting by definition. If you want make comparison, you must use same bitrate. Crf and quantizer are not absolute quality level.

Anyway if your conclusion is "10 bits produce more quality and less bitrate than 8 bits at same crf", certainely that advantage for 10 bits will be higher at same size. Make comparison at same crf (and different bitrate) don't show the real difference (negative or positive here).

[gonzales3]

Hello to everybody. My question is about Tenth MSU Video Codecs Comparison. How it is possible that in ripping mode two different results are present. From what I've read the parameters of compression were both the same for "Destkop" and "Server" configuration.

http://114.imagebam.com/download/9A-jxmQQ4LfijoLHc0eiGg/44301/443009367/msu1.png

http://113.imagebam.com/download/cqCVlhsRLowUcHz7V6wfaA/44301/443009371/msu2.png

[littlepox]

Hello to everybody. My question is about Tenth MSU Video Codecs Comparison. How it is possible that in ripping mode two different results are present. From what I've read the parameters of compression were both the same for "Destkop" and "Server" configuration.



The reason is that multi-threading in video encoding sometimes have to be coupled with efficiency sacrifice.

For example, x264 uses --threads which is set to 1.5 * No. of logic cores BY DEFAULT. The more threads it is allowed to use, the less efficient the coding shall be.

Most of the time you won't spot any noticeable difference if it is <=18, e.g, your CPU has no more than 12 logic cores. But for the "server" they use, which is equipped with E5 2697v3(14C28T), the threads for x264 will be set to 28*1.5=42. The difference will at least be demonstrable by objective benchmark.

Luckily HEVC got some optimize on multi-threading with little or no pain, for example, the WPP feature. So it is as expected to see that for server settings, x265 enjoys a slight advantage comparably.

[mandarinka]

WPP does have some "pain", actually. AFAIK it has even been stated in this thread that while it should be under 1% hit or so, it is probably higher impact than just using frame threading as x264 does.

[~ VEGETA ~]

@LigH: isn't entrocopy encoding meant for lossless? can you explain why 10-bit gives better quality and less bitrate consumption? I already explained why in my point of view.

I admit, you are more technically aware than me in this thing. I tried to say the stuff you just said about quantization but didn't succeed obviously. I still think my explanation is correct, as it is tried numerous times. Having 2 bits more yet smaller size and better quality is not normal or expected given the 2 additional bits. However, I talked about visible quality of 2 encodes (8 and 10), 10 gives smaller size for that quality than 8 bit. If 8 bit wants to give the same quality, it needs more bitrate and thus bigger size.

you mentioned quantization and quantization before quantization... this is where 10 bit excels, where it has more accurate processing than 8 bit, but storing bitstream is done in 8 bit (I guess, not very sure). Decoder converts it back to 10 later on.

@Sagittaire

Hmmm yes that was my conclusion after testing stuff back when H.264 10-bit appeared (others has the same too). My whole point was like you put in quotation marks... 10 bit gives better quality and less size at the same CRF. I still think using the same x264 settings and the same CRF is fair method for comparison. Of course, comparing at the same bitrate is valid too.

[~ VEGETA ~]

Entropy coding itself is 100% lossless. And the entropy coding stage is where the encoder actually "saves" bits. Simply put, the idea is that we use few bits to code the likely "symbols" (input values), and many bits to code the unlikely "symbols" (input values). However, the data that enters the entropy coding stage must be "suitable" for entropy coding, if you want to achieve a noteworthy bit saving. For example, applying an entropy coder on "random" data (where every input symbol may appear with equal probability, regardless of what symbols we have seen before) would not save any bits at all! So, everything that happens before entropy coding, such as quantization, serves one goal: Make the data more "adequate" for entropy coding, and thus save more bits in the entropy coding stage. It's the quantization stage (not the entropy coding stage) that makes the whole process lossy. Still, they are closely related.

nice explanation, is there good tutorials or texts to read in this subject?

[LoRd_MuldeR]

@LigH: isn't entrocopy encoding meant for lossless? can you explain why 10-bit gives better quality and less bitrate consumption? I already explained why in my point of view.

Entropy coding itself is 100% lossless. And the entropy coding stage is where the encoder actually "saves" bits. Simply put, the idea is that we use few bits to code the likely "symbols" (input values), and many bits to code the unlikely "symbols" (input values). However, the data that enters the entropy coding stage must be "suitable" for entropy coding, if you want to achieve a noteworthy bit saving. For example, applying an entropy coder on "random" data (where every input symbol may appear with equal probability, regardless of what symbols we have seen before) would not save any bits at all! So, everything that happens before entropy coding, such as quantization, serves one goal: Make the data more "adequate" for entropy coding, and thus save more bits in the entropy coding stage. It's the quantization stage (not the entropy coding stage) that makes the whole process lossy. Still, these two stages are closely related.

Now, whether the input value has a precision of 8-Bit, 10-Bit or 12-Bit is pretty much unrelated to how many bits we need to spend to store it in the encoded bitstream, i.e. after entropy coding stage! If a certain symbol/value is very likely to appear, then the entropy coder may be able to encode this particular symbol/value with a single bit - or even less than a single bit (which is actually possible with arithmetic coding). At the same time, symbols/values that are very unlikely to appear may require a large number of bits to encode. Whether the symbol is an 8-Bit, 10-Bit or 12-Bit number - or something completely different - doesn't matter here. For the entropy coder, the input value is just some symbol out of a certain alphabet.

[LoRd_MuldeR]

nice explanation, is there good tutorials or texts to read in this subject?

For entropy coding, I suggest you start with Huffman coding:
https://en.wikipedia.org/wiki/Huffman_coding

Also I suggest that you read the Wikipedia article on JPEG to get an idea how lossy compression works:
https://en.wikipedia.org/wiki/JPEG#Encoding

Yes, JPEG is only about still images, but many fundamental concepts are pretty much the same for video encoding. Especially the "transformation → quantization → entropy coding" data flow!

[LigH]

A few additions:

JPEG and MPEG-1/2 Video use a 2D "Discrete Cosine Transform" to calculate frequency spectrum parameters from pixel / color component values; this is a finite variant of the Fourier series. AVC and HEVC will prefer a partially different transform function, but with the same purpose: To describe rather the structure of a color ramp across a square / rectangle of few pixels than each pixel on its own. A blurry, little structured area needs only a few parameters of low frequency parts of the 2D spectrum to be encoded with sufficient precision. If there is video content with only little motion or even static content, then the difference between two frames will have very little structure, so P and B frames hardly need to store any relevant differential frequency parameters in such still parts.

[foxyshadis]

We're getting way off from a discussion of x265 itself, though. The biggest gain from 8->10 bit is visually; the efficiency is minimal (<1%), especially in HEVC. AVC gains more, but still only a little. Any efficiency gain from 10->12 would be 1/4 whatever the first transition will be at most, the overhead of extra bits might even reduce that some. There is no visual gain since I know you can't see a difference between 10 and 12-bit YUV even without dithering.

You can spend your sweet time encoding to that, at more than twice the time, and completely eliminate the possibility of ever playing it back on anything but a PC software decoder, or just stick with the main10 that was designed specifically for everyone who wants much better than 8-bit but full hardware compatibility. Moving to a higher bit-depth is not something do to lightly, or because you have some feelings about it, but because you need it.

The only reason I'd ever go off-main for anything but archival would be to use the screen-coding rext tools, which x265 doesn't have.

[Jamaika]

Does anyone know when will be added High profile with the codec X265?

[foxyshadis]

HEVC high tier just means a higher bitrate, and x265 can support any bitrate. What are you looking for? There are many profiles, but HEVC doesn't have a high profile the way AVC did.

[LigH]

There is no "High profile" in the HEVC specification. See: Wikipedia: High Efficiency Video Coding – Profiles (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles) (v2 introduced many specific profiles, still most of them are named based on "Main").

[Jamaika]

HEVC high tier just means a higher bitrate, and x265 can support any bitrate. What are you looking for? There are many profiles, but HEVC doesn't have a high profile the way AVC did.
There is no "High profile" in the HEVC specification. See: Wikipedia: High Efficiency Video Coding – Profiles (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles) (v2 introduced many specific profiles, still most of them are named based on "Main").
Umh..., well, I understand that my suggest is nonsense. However, I don't know what to think about exceptions.
https://www.sendspace.com/filegroup/olhPsjIRXQFwcsxSO3JkCQ

[vivan]

That file is main profile high tier. And x265 supports that (https://x265.readthedocs.org/en/default/cli.html#cmdoption--high-tier).

[Jamaika]

OK, http://i60.tinypic.com/jzctxk.jpg
The funktion --high-tier for me doesn't work for X265 and displays communique:
x265 [info]: Main profile, Level-5 (Main tier)
I don't know how to use it. :(

[vivan]

It works fine here http://i.imgur.com/XduTssT.png
Did you even read what I linked? It says If --level-idc has not been specified, this argument is ignored.

In the description manual PowerDirector doesn't have the word "tier".Use MediaInfo.

[Jamaika]

If --level-idc has not been specified, this argument is ignored.
Let me ask ex. --level-idc 4.1 and what's next? What must other functions be switched on?

Edit: I already know.
x265 [info]: Rate Control / qCompress : ABR-20000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 45000 / 20000 / 0.900

[LigH]

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

[~ VEGETA ~]

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

where to download compiled versions of the encoder? plus, is there any mods right now like tmod or something? especially those who has aq-mode 3.

:D

[LigH]

:scared: What do you think is inside these 7-zip archives? — Yes, binaries! :o

And why mods? The "vanilla" builds already contain "--aq-mode 3". And to use x265 with other video sources than YUV or Y4M files, there are already many solutions (VirtualDub 1.10+ external encoder; avs4x26x; StaxRip; MeGUI; Hybrid; ...). The x265 developers still have tight focus on encoder core features, the time for convenience additions has not yet come.

[stax76]

they could probably add AviSynth and VapourSynth support in no time, it should only be a matter of copy and paste little code from other open source encoders like QSVEncC, many users and tool makers would be thankful.

[~ VEGETA ~]

:scared: What do you think is inside these 7-zip archives? — Yes, binaries! :o



Duh I know! it is very obvious. I asked about a certain site that automatically compile and upload new versions (like some x264 ones) rather than looking in a forum post to see one post out of hundreds that has a downloadable binaries. :(

[Ma]

I asked about a certain site that automatically compile and upload new versions

The list of sites with x265 binaries:
http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

For CPU with SSE4.2 or better quite fast are VS 2015 builds:
www.msystem.waw.pl/x265/

[Jamaika]

Does the site https://encoder.pw/ has been blocked?

[LigH]

Blocked where against what? It requires a rather strong HTTPS cipher, but with a recent browser I can access it (Opera 12 is obsolete here). Most should have TLS 1.x enabled and SSL 3 disabled already.

[cengizhan]

Blocked where against what? It requires a rather strong HTTPS cipher, but with a recent browser I can access it (Opera 12 is obsolete here).

sec_error_revoked_certificate with firefox 41

[LigH]

Well, that's another issue. It seems that Mozilla either does not trust the Certificate Authority (COMODO RSA Domain Validation Secure Server CA) anymore which granted the certificate of this website, or the certificate to this server has been revoked by the CA. In this case, probably the latter.

You might disable the use of the Online Certificate Status Protocol (OCSP) in the advanced security options of Firefox, but this is usually enabled for a good reason. So you may have to wait until the maintainer of this website will buy another certificate (if he agrees to pay that money).

Qualys SSL Labs analysis (https://www.ssllabs.com/ssltest/analyze.html?d=encoder.pw)

[foxyshadis]

Someone must have stolen the private key or hijacked the server. Ouch. Good idea to wait until the situation is cleared up.

[x265.cc]

Someone must have stolen the private key or hijacked the server. Ouch. Good idea to wait until the situation is cleared up.

I've revoked it my self. As you can see i switched from 4096 bit RSA to 384 bit ECC (~7680 bit RSA) certificate.

Actually i was a bit slow with replacing it on my nginx, so you saw the "revoked" message.

Sorry for the inconvenience

It requires a rather strong HTTPS cipher

Yep, thats true. If somebody uses an outdated browser* he cant access my site(s).


*Chrome =< 29 / Firefox =< 26 / IE =< 10 / Opera =< 17 / Safari =< 6

[MeteorRain]

Duh I know! it is very obvious. I asked about a certain site that automatically compile and upload new versions (like some x264 ones) rather than looking in a forum post to see one post out of hundreds that has a downloadable binaries. :(

I compile modified versions, every couple days.

You can find patched version in my signature.
And you can find the patches on my bitbucket repo.

(And since I'm using the latest version of Opera 12, the ssl cipher is still RSA based.)

[need4speed]

Hi,
sorry for jumping in and hoping this is the right place to ask: been messing around with HEVC since awhile and using staxrip since dont have much time to learn all tricks for command line (sorry...).
I'm mainly using HEVC to recode and store tv series, from different sources but the idea is to spare some disk space.
Basically I tend to recode in 720p, keeping quality as high as possible.
HEVC is working great, and staxrip is a big help being very intuitive.
Question now would be:
At the moment staxrip is still relying on HEVC version 1.7.something, and reading around here there are several newer releases, 1.8.etc
So how can I update HEVC (x265) in staxrip?
As for codec there's a folder with the executable only, but in the7z files downloaded from here (thanks a ton for the hard work btw) there are also some dll's file I'm not quite sure with to do with.
Launching Staxrip the task log reports the 1.8.whatever version as expected (swapping exe file in the proper folder) but I'm quite puzzled sinc haven't done anything with DLL's.
ANY help welcome and thanks in advance!
A.
PS Aplogies for my english, hope si intelligible

[LigH]

As long as there are no fundamental changes in the command line options set, you may indeed just replace the x265.exe any GUI would use.

Which replacement to use, has been asked in another forum recently, so I will quote here the verbose reply:

The x265_ml.exe is the "static multilib build" which does not need any additional DLLs. If you want to reduce the number of files and only encode, use this as your only EXE file with any name you like (most probably x265.exe).

The other files are only included for completeness' sake; e.g. for the case that someone wants to reduce the size of a release archive by omitting some functionality (include only the EXE for one bitdepth per default) and offering additional bitdepths as optional downloadable DLLs, or wants to write a different application which would use the DLLs as pluggable encoders.

x265_ml.exe = static multilib build, includes 8 + 10 + 12 bit depth encoder (possibly the only one most people need)
x265_main.exe = only 8 bit depth encoder included; may require x265_main10.dll or x265_main12.dll if used with -D 10 or -D 12
x265_main10.exe = only 10 bit depth encoder included; may require x265_main.dll or x265_main12.dll if used with -D 8 or -D 12
x265_main12.exe = only 12 bit depth encoder included; may require x265_main.dll or x265_main10.dll if used with -D 8 or -D 10


tl;dr: Use x265_ml.exe (no additional DLLs required) as your new x265.exe (preferably the 64-bit version if applicable).

[need4speed]

As long as there are no fundamental changes in the command line options set, you may indeed just replace the x265.exe any GUI would use.

Which replacement to use, has been asked in another forum recently, so I will quote here the verbose reply:



tl;dr: Use x265_ml.exe (no additional DLLs required) as your new x265.exe (preferably the 64-bit version if applicable).

Got it.
Thanks for the quick reply.
Already done that, although had to rename the exe file (64bit folder).
Would love to use handbrake or CL on my main linux system but Handbrake has no available triggers for advanced settings in HEVC and have no idea how to use CL on linux (and how to install/compile codec itself).
Any tutorial or howto available for linux systems?
Basically trying to get rid of windows once and for all!

many thanks again!
BTW; there's no 12bit option available (staxrip) with newer exe version. 8 or 10 only in deph filed. Or am I doing something wrong?

[LigH]

StaxRip may have restricted its GUI to offer only 8 or 10 bit, because 12 bit precision should have little relevance in "amateur" cases and used to be "experimental" for a longer time.

The x265 project has a compiling guide on BitBucket (https://bitbucket.org/multicoreware/x265) which is also their Hg (Mercurial - a git variant) server. In general, "clone" the sources, change into the subdirectory of the "build" directory which matches your environment, and use the shell scripts there. I customized these a bit for my workflow, but in general, they are pure source builds without additional patches.

To use x265 on the command line, you may better use a feature-rich ffmpeg build including libx265, or you would have to pipe YUV4MPEG (or raw YUV, in conjunction with more CLI parameters) into x265 as separate encoder, it doesn't support any other input yet. Maybe try Selur's "Hybrid" converter, it is multi-platform for the portable features.

[stax76]

@need4speed
@LigH

Next StaxRip release will have the 12 bit option and a few other x265 improvements.

[RBF]

BIG TEST VP9 / x264 / x265 (http://blog.cherepovets.ru/serovds/2015/10/27/bigtest_vp9_264_265/)

[~ VEGETA ~]

what does Yuuki mod add to the encoder?

plus,

x265_ml.exe = static multilib build, includes 8 + 10 + 12 bit depth encoder (possibly the only one most people need)

where to download this version? and if it includes 8,10, and 12 bit encoding in the same exe... what is the command line to use each of them?

[stax76]

what does Yuuki mod add to the encoder?

plus,



where to download this version? and if it includes 8,10, and 12 bit encoding in the same exe... what is the command line to use each of them?

LigH posts binary links regularly, the static multilib build is called x265_ml.exe and the switch is --output-depth, -D 8|10|12

http://x265.readthedocs.org/en/latest/cli.html#cmdoption--output-depth

[MeteorRain]

what does Yuuki mod add to the encoder?
lavf input
mp4/mkv output muxer
--tune lp by littlepox optimized for animation
some other cosmetic stuff

[need4speed]

@need4speed
@LigH

Next StaxRip release will have the 12 bit option and a few other x265 improvements.

Good news, many thanks!
Really it's out of curiosity, 10bit seems to work ok although using some tweaks it's about 8fps which seems to be a bit slow but not such a big deal.
What is not really clear is the subpel refinement in the motion search panel. sorry, I don't mean to ask a lot of questions but the more I read about some settings the less I understand :)
A lot of different opinions and a lot of tests done but there seems to be no final word on a lot of settings. Again, have tried myself and, aside from encoding fps rate, cant really tell the difference.
In my own case it's
1) Re-encoding 1080p tv shows to 720p to save some disk space.
2) re-encoding BR tv series iso.

Thanks again for the help and the big effort!!

Btw, here's my settings for 1080p->720p tv shows

x265 [info]: HEVC encoder version 1.8+60-6563218ce342
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: Specifying a decoder level with constant rate factor rate-control requires
x265 [warning]: enabling VBV with vbv-bufsize=10000kb vbv-maxrate=10000kbps. VBV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(45 rows)
x265 [info]: Coding QT: max CU size, min CU size : 16 / 8
x265 [info]: Residual QT: max TU size, max depth : 16 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 15 / 3 / 1
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 2 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 16 / 1
x265 [info]: Rate Control / qCompress : CRF-16.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 10000 / 10000 / 0.900
x265 [info]: tools: rd=3 psy-rd=0.70 rdoq=1 psy-rdoq=5.00 signhide tmvp
x265 [info]: tools: fast-intra strong-intra-smoothing deblock(tC=-1:B=-1)

[LigH]

where to download this version?

They are inside the 7-zip archives (usually recommendable version in bold green):

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

Listing archive: x265_1.8+60-6563218ce342.GCC520.7z

--
Path = x265_1.8+60-6563218ce342.GCC520.7z
Type = 7z
Physical Size = 3650115
Headers Size = 510
Method = LZMA2:26 LZMA:20 BCJ2
Solid = +
Blocks = 1

Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520\Win32
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520\Win64
2015-10-27 12:49:50 ....A 3094229 3649605 1.8+60-6563218ce342.GCC520\Win32\libx265_main.dll
2015-10-27 12:49:50 ....A 1379541 1.8+60-6563218ce342.GCC520\Win32\libx265_main10.dll
2015-10-27 12:49:50 ....A 1378005 1.8+60-6563218ce342.GCC520\Win32\libx265_main12.dll
2015-10-27 12:49:50 ....A 3843258 1.8+60-6563218ce342.GCC520\Win32\x265_main.exe
2015-10-27 12:49:50 ....A 2132666 1.8+60-6563218ce342.GCC520\Win32\x265_main10.exe
2015-10-27 12:49:50 ....A 2131130 1.8+60-6563218ce342.GCC520\Win32\x265_main12.exe
2015-10-27 12:49:51 ....A 6291642 1.8+60-6563218ce342.GCC520\Win32\x265_ml.exe
2015-10-27 12:49:52 ....A 4703872 1.8+60-6563218ce342.GCC520\Win64\libx265_main.dll
2015-10-27 12:49:52 ....A 5388928 1.8+60-6563218ce342.GCC520\Win64\libx265_main10.dll
2015-10-27 12:49:53 ....A 5393024 1.8+60-6563218ce342.GCC520\Win64\libx265_main12.dll
2015-10-27 12:49:51 ....A 5485665 1.8+60-6563218ce342.GCC520\Win64\x265_main.exe
2015-10-27 12:49:52 ....A 6170721 1.8+60-6563218ce342.GCC520\Win64\x265_main10.exe
2015-10-27 12:49:52 ....A 6174817 1.8+60-6563218ce342.GCC520\Win64\x265_main12.exe
2015-10-27 12:49:54 ....A 15927393 1.8+60-6563218ce342.GCC520\Win64\x265_ml.exe
------------------- ----- ------------ ------------ ------------------------
2015-10-27 13:27:40 69494891 3649605 14 files, 3 folders

Sometimes I wonder ... you seem to talk about the content of my archives one day, but seem to never have looked into them the other day?! :confused:

[Rogatti]

Got it.

Any tutorial or howto available for linux systems?
Basically trying to get rid of windows once and for all!


Install X265 - 10bit
hg clone https://bitbucket.org/multicoreware/x265 x265
cd x265/build/linux/
cmake -G "Unix Makefiles" -D HIGH_BIT_DEPTH:BOOL=ON ../../source
make -j4
sudo make install

Down FFMPEG
git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg


sudo apt-get install libfaac-dev libmp3lame-dev libtheora-dev libvorbis-dev libopencore-amrnb-dev libopencore-amrwb-dev libgsm1-dev zlib1g-dev libgpac-dev libx264-dev libxvidcore-dev libass-dev libfdk-aac-dev....

via synaptic## libvpx-dev - libopus-dev....

Configuring ffmpeg
$ ./configure --prefix=/usr/local --enable-gpl --enable-version3 --enable-nonfree --enable-shared --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfaac --enable-libfdk_aac --enable-libgsm --enable-libmp3lame --enable-libass --enable-libvpx --enable-libtheora --enable-libvorbis --enable-ffplay --enable-libx264 --enable-libxvid --enable-libx265 --enable-libfreetype --enable-libopus --enable-x11grab --enable-libfdk-aac
$ make -j4
$ sudo make install
$ sudo ldconfig -v
***************************
$ which ffmpeg
$ ffmpeg -encoders|grep -E "mp3|xvid|aac|gsm|amr|x264|x265|theora|vorbis"

voilà....

[need4speed]

Install X265 - 10bit
hg clone https://bitbucket.org/multicoreware/x265 x265
cd x265/build/linux/
cmake -G "Unix Makefiles" -D

voilà....
Ugh, thanks a ton!
Will try on a vm first. Not too sure I've grabbed all the steps but for sure will give it a go.
Just one point: once a newer codes version is out how can I update?
Many many thanks again.
Btw: since I'm setting up a vm to test any specific choice as for distro?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

Instead of making only the 10 bit binary, you may prefer running the build/linux/multilib.sh to have the "Holy Trinity" ;) of 8+10+12 bit encoders packed into one common libx265.a to be installed.

To stay up to date in the "default" development branch (updated more often with fixes, sporadically merged with the "stable" branch):

hg pull --cwd x265 -u -r default

from the directory where your x265 working directory is contained (possibly your '~' home).

[birdie]

BIG TEST VP9 / x264 / x265 (http://blog.cherepovets.ru/serovds/2015/10/27/bigtest_vp9_264_265/)

x264 > x264 grain > vp9 > x265 > x265-grain

From what my eyes can see. x265 is the blurriest of them all, VP9 looks decent and sometimes it produces a better picture than x264, but overall x264 is the best, especially at high bitrates.

[Jamaika]

x265 is the blurriest of them all,...
x265 can sharpen (http://forum.doom9.org/showthread.php?t=172778) but then you need to have a super fast computer.
...VP9 looks decent and sometimes it produces a better picture than x264, but overall x264 is the best, especially at high bitrates.
It's a matter of taste. VP9 isn't a preserved bitrate.

[foxyshadis]

x265 can sharpen but then you need to have a super fast computer.

Did you look at the comparison? x265 was given 5-8 times as long to run as x264, with preset veryslow. How much more do you want to slow it down?

Something is very off about x265 tune grain, in several comparisons it's significantly blurrier than the non-grain. I think more care should have been taken to select a frame that was a P frame across all encodes, although tune grain is specifically supposed to reduce the ratio between P and B frames, but it shouldn't be that much worse.

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.

[LigH]

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion.

I compared a tight bitrate encode of a probably quite easily compressible scene in x265 (CRF 30) with the same, 2x, 3x, and even 4x the bitrate of the x265 result in x264 already quite some time ago. May have to repeat that with the current encoders...

My samples on MediaFire (https://www.mediafire.com/#ldwl20fppplbx) – compare in_to_tree_1080p50.x265-crf30.mp4 with in_to_tree_1080p50.x264_br~x265-crf30[_x?].mp4

IMHO, x265 was able to smooth out the sky quite conveniently, while x264 surprised with rather annoying blocking. I'll be curious which tuning may improve these results.

[nandaku2]

Did you look at the comparison? x265 was given 5-8 times as long to run as x264, with preset veryslow. How much more do you want to slow it down?

Something is very off about x265 tune grain, in several comparisons it's significantly blurrier than the non-grain. I think more care should have been taken to select a frame that was a P frame across all encodes, although tune grain is specifically supposed to reduce the ratio between P and B frames, but it shouldn't be that much worse.

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.

The comparisons are interesting; an English webpage would be helpful.
The expectations from tune grain are very different from whats its designed to do. tune grain is not designed to retain detail, tune grain is not designed to give a sharper image. x265's tune grain (which was initially ported from x264, but then modified substantially), is designed to work on sources with film grain, and aims at preserving some of the grain as uniformly as possible through the sequence for all slicetypes. Using it on fairly clean sources like parkjoy and crowdrun is unwarranted.

[foxyshadis]

The comparisons are interesting; an English webpage would be helpful.
The expectations from tune grain are very different from whats its designed to do. tune grain is not designed to retain detail, tune grain is not designed to give a sharper image. x265's tune grain (which was initially ported from x264, but then modified substantially), is designed to work on sources with film grain, and aims at preserving some of the grain as uniformly as possible through the sequence for all slicetypes. Using it on fairly clean sources like parkjoy and crowdrun is unwarranted.

My expectation for tune grain is that if there isn't any grain, it won't lose any detail, within reason. Indeed, it seems to work exactly that way in parkjoy; the exact image is different but the sharpness is identical between default and tune grain. (Even if the group's detail loss is staggering either way.)

It just seems like tune grain leads to unnecessarily soft detail everywhere in the other encodes, even though it doesn't seem to contribute to additional detail. My guess is that with tune grain the sky is just sucking up all the bits in both sequences, leaving the details in the rest of the frame starved; the sky in each is very noisy. In quite a few movies shot on cheap film stock, the sky is where the worst of the grain is by far, while also being the least interesting part of the frame. I guess that puts you in a hard spot if you want to keep grain generally without wasting so much of your bit budget on the sky (and yet not stealing so much from it that it creates banding, either).

[Jamaika]

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.
Test extreme noise retention Jamaika
https://www.sendspace.com/filegroup/aFL0OnfrO01atCMw5pUiagQ7fsfOJAuF
PS. Comparative test is useless. For codec VP9 at bitrates equal to 4000 kbps it amounts to 7378 kbps. What I can in this case compare?

Edit: Equating to 4700 kbps bitrate for pass=1
https://www.sendspace.com/filegroup/gqoofCSILpxL5KAWh2YIw59xgsBJMvH4
VP9 1.4-1351 {good/cpu-used=1/sharpness=2/aq-mode=1/tune-content=screen/threads=4/bitrate=2600}
http://i65.tinypic.com/29zxze9.png
X264 2638 komisar {deblock=-3:-3/psy-rd=2.00:0.7/aq-strength=1.2/me=umh/preset veryslow/threads=4/bitrate=4700}
http://i66.tinypic.com/107rt5v.png
X265 1.8.0.71 x265.cc {no-b-intra/no-sao/rect/no-amp/no-temporal-mvp/no-signhide/no-strong-intra-smoothing/rd=6/psy-rd=0.3/rdoq-level=2/psy-rdoq=50.0/me=umh/aq-strength=1.0/deblock=-3:-3/preset veryslow/no-open-gop/no-hrd/bitrate=4700}
http://i66.tinypic.com/4hsj7t.png
original
http://i66.tinypic.com/30x7x2w.png

[x265_Project]

Hey everyone. It's time to refresh our default performance presets. Our team is reviewing and testing everything, but I thought we should reach out here to get feedback from more experts. Behold, the power of open source development. It's unbeatable.

First, let's make it clear what our requirements are for our 10 performance presets. Basically, these are 10 points along the speed versus compression efficiency curve. Compression efficiency = subjective visual quality / bit rate. We want these 10 presets to be points where (for most video content, at any reasonable bit rate) you would get the maximum visual quality at a given bit rate and performance level. Stated another way, at one of these presets you would get the maximum speed for the desired level of efficiency.

Some key presets... and the way we think of them...
Ultrafast = speed at all costs. Efficiency will be low, but not unreasonable. For the most part, we don't recommend using Ultrafast, but it's there for people who really need speed.
Superfast = fastest possible speed with ok quality. One of our "realtime" presets. If you are doing real-time encoding, we would like you to be able to use superfast or veryfast and be pleased with the efficiency.
Veryfast = a higher quality "realtime" preset.
Fast = one of two midpoint presets (along with medium). Slightly faster than medium, but with efficiency that is almost as good.
Medium = our default preset. This should produce very good efficiency (rough estimate is ~ 10% higher bit rate than veryslow), while running at a reasonable speed.
Veryslow = our highest quality preset without requiring a sanity check. Veryslow should produce the highest reasonably possible quality.
Placebo = as the name suggests, this preset is for people who enjoy the placebo effect. You'll believe that you're getting higher quality than veryslow, but the difference in quality is expected to be very small. This preset will run EXTREMELY slow. As speed is not a priority, we will turn on every possible capability of x265.

We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.

After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).

On the subject of "softness", we have developers looking at improvements to Sample Adaptive Offset (SAO) in order to minimize any loss of detail from this algorithm. We're looking at a number of other possible algorithmic improvements, but your feedback (as we've already seen on this thread) is helpful. We're not talking about your suggestions for --tune grain... let's start with optimal quality and detail retention for all x265 presets, and then we can look at how to handle grainy content afterwards.

Thanks,
Tom

[Jamaika]

Some key presets... and the way we think of them...
Ultrafast = speed at all costs. Efficiency will be low, but not unreasonable. For the most part, we don't recommend using Ultrafast, but it's there for people who really need speed.
Superfast = fastest possible speed with ok quality. One of our "realtime" presets. If you are doing real-time encoding, we would like you to be able to use superfast or veryfast and be pleased with the efficiency.
Veryfast = a higher quality "realtime" preset.
Faster = ....
Fast = one of two midpoint presets (along with medium). Slightly faster than medium, but with efficiency that is almost as good.
Medium = our default preset. This should produce very good efficiency (rough estimate is ~ 10% higher bit rate than veryslow), while running at a reasonable speed.
Slow = ....
Slower = ....
Veryslow = our highest quality preset without requiring a sanity check. Veryslow should produce the highest reasonably possible quality.
Placebo = as the name suggests, this preset is for people who enjoy the placebo effect. You'll believe that you're getting higher quality than veryslow, but the difference in quality is expected to be very small. This preset will run EXTREMELY slow. As speed is not a priority, we will turn on every possible capability of x265.
And it is good that the codecs are ten point of quality for X264/X265. Anyone can set it so that the computer will be able to work or perhaps some we want to achieve quality. You want to have a better quality it uses --pass 1,2,3, ...:D

PS. In the X264 always I set veryslow even for YouTube, Vimeo.
For placebo options don't trust, sometimes I see the quality is worse than veryslow.
After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).
We look forward humbly to new solutions.:cool:

[x265_Project]

For placebo options don't trust, sometimes I see the quality is worse than veryslow.
This could be attributed to the reverse-placebo effect. :)

[LigH]

There may also be a discrepancy between objective quality retention (measurable with mathematical metrics) and subjective quality impression (related to psychovisual effects). Or brief: Less perfection may look better to some.

[need4speed]

Thanks for all the efforts. Just starting some additional tests for TV shows 1080p to 720p and BR to 720p.
My own personal opinion is no matter the bitrate the final image is still too much blurred.
One question about SAO: I disable it, always. Is this wrong? I mean, 5 minutes samples don't show any significative difference. Sao enabled or disabled. There are other settings to work together with as for Sao?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.
Foxyshadis makes a good point here - one that's obvious in the still images posted by Jamaika... that the "detail" that is apparently retained by x264 is inaccurate (spatial accuracy, versus the actual source picture). This issue isn't noticeable if you are looking at an object that has some random texture (leaves on a tree, grass, etc.). Who would notice if some of the leaves on the tree are in slightly different positions than the original picture, or if groups of leaves don't wave smoothly in the breeze? But take a look at the faces of the runners. Accurately capturing the position and shape of the eyes, nose and mouth is important. Every runner in the picture looks significantly better in the x265 frame. We don't want more detail, whether it's accurate detail or not. We only want accurate detail, and accurate motion.

[Jamaika]

This is true. I emphasize only that you need a super fast computer. I noticed again that in the aforementioned record commands for X265, I have a problem with the cuts in the film. There are turmoil pixels.

[LigH]

Weekly build: A few bug fixes, speed ups, and:

--[no-]limit-modes Limit rectangular and asymmetric motion predictions. Default 0

When enabled, limit-modes will limit modes analyzed for each CU using cost metrics from the 4 sub-CUs. When multiple inter modes like --rect and/or --amp are enabled, this feature will use motion cost heuristics from the 4 sub-CUs to bypass modes that are unlikely to be the lowest. This can significantly improve performance when --rect and/or --amp are enabled at minimal compression efficiency loss.

So I believe "Default 0" means: There's no limit! (https://www.youtube.com/watch?v=RkEXGgdqMz8)

x265 1.8+76-bd8237a5d782 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+76-bd8237a5d782 (GCC 5.2.0) (https://www.mediafire.com/download/8lfmcbw72it48mo/x265_1.8+76-bd8237a5d782.GCC520.7z)

[Barough]

Thnx 4 the weekly build LigH :)

[shinchiro]

I waited for --rd-refine option to be finalized/pushed. :) Last time I tried, it brings noticeable quality improvement but the tradeoff with speed isnt really worth

[Jamaika]

We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.
For limit-modes film FullHD 11s converted 13min,
Without limit-modes film FullHD 11s converted 16min.
:thanks:
PS I see that there is a problem with the initial movie playback. They are jerks.

[benwaggoner]

For limit-refs film FullHD 11s converted 13min,
Without limit-refs film FullHD 11s converted 16min.
:thanks:

Anyone try --limit-modes yet?

[benwaggoner]

Hey everyone. It's time to refresh our default performance presets. Our team is reviewing and testing everything, but I thought we should reach out here to get feedback from more experts. Behold, the power of open source development. It's unbeatable.

...We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.

After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).
You've already identified the low-hanging fruit from my perspective. One question I've had is if slower shouldn't have --amp or --rect, or if slow should add --weightb. It seems like weighted b-frames helps real world content more at a lower CPU hit. However, if --limit-modes makes amp/rect a lot cheaper, maybe they should be on by default at lower levels.

Enabling more refs via --limit-refs 3 sounds great for >slow. Certainly placebo and perhaps veryslow should use the maximum supported refs per level restrictions.

Also, it seems like --frame-threads is often higher than needed to saturate processors, and can cause quality issues with noisy content. So looking for how to reduce that to the minimum needed for maximum throughput might make sense. And certainly they should be lower for the faster presets, perhaps with --pmode turned on in some cases to recapture some speed.

Automatically turning on --pmode with lots of cores and lower frame sizes could also help speed, with the cost of some determinism.

Adding --qg-size 32 for the slower presets is probably good.

[Jamaika]

Anyone try --limit-modes yet?
For limit-refs=3 and limit-modes film FullHD 11s converted 9min. (Core i5 2500K, Windows 10)
https://www.sendspace.com/filegroup/EMduvLXLfVdmbCcfMqj4RM1yF7z3wAq8O7CAh2qCfTeRw7tjELSNXo5HU09GsFOhVE36zC0sJ4I
PS They aren't jerks. That's great!

[benwaggoner]

For limit-refs=3 and limit-modes film FullHD 11s converted 9min.


PS They aren't jerks. That's great!


From 16 min to 9 min? If there really is minimal.quality loss, that's a big win! That'd allow going up around one preset level

[x265_Project]

Note that limit-modes is only useful for presets that used --rect and --amp. Here are our performance test results on a Haswell processor (Core i7 4770K I believe... will double check today) with and without limiting refs and modes with the veryslow preset...


Before
x265_b.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc
encoded 504 frames in 223.08s (2.26 fps), 3596.14 kb/s, Avg QP:37.29, Global PSNR: 30.707, SSIM Mean Y: 0.8688587 ( 8.823 dB)

After
x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-modes 1
encoded 504 frames in 186.35s (2.70 fps), 3610.14 kb/s, Avg QP:37.35, Global PSNR: 30.692, SSIM Mean Y: 0.8687821 ( 8.820 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1
encoded 504 frames in 188.32s (2.68 fps), 3604.27 kb/s, Avg QP:37.31, Global PSNR: 30.712, SSIM Mean Y: 0.8689656 ( 8.826 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1 --limit-modes 1
encoded 504 frames in 165.63s (3.04 fps), 3610.51 kb/s, Avg QP:37.34, Global PSNR: 30.691, SSIM Mean Y: 0.8686912 ( 8.817 dB)

----------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc
encoded 500 frames in 795.40s (0.63 fps), 9513.58 kb/s, Avg QP:37.92, Global PSNR: 30.459, SSIM Mean Y: 0.8214006 ( 7.481 dB)

After
x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-modes 1
encoded 500 frames in 556.86s (0.90 fps), 9553.70 kb/s, Avg QP:37.92, Global PSNR: 30.458, SSIM Mean Y: 0.8214283 ( 7.482 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1
encoded 500 frames in 625.53s (0.80 fps), 9518.09 kb/s, Avg QP:37.91, Global PSNR: 30.457, SSIM Mean Y: 0.8213568 ( 7.480 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1 --limit-modes 1
encoded 500 frames in 513.12s (0.97 fps), 9564.23 kb/s, Avg QP:37.92, Global PSNR: 30.457, SSIM Mean Y: 0.8213727 ( 7.481 dB)

---------------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc --bitrate 6000
encoded 504 frames in 273.06s (1.85 fps), 5097.33 kb/s, Avg QP:35.53, Global PSNR: 31.691, SSIM Mean Y: 0.8935050 ( 9.727 dB)

After
x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-refs 1
encoded 504 frames in 231.13s (2.18 fps), 5094.89 kb/s, Avg QP:35.54, Global PSNR: 31.687, SSIM Mean Y: 0.8933111 ( 9.719 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1
encoded 504 frames in 228.21s (2.21 fps), 5099.24 kb/s, Avg QP:35.60, Global PSNR: 31.671, SSIM Mean Y: 0.8932938 ( 9.718 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 1
encoded 504 frames in 199.34s (2.53 fps), 5098.16 kb/s, Avg QP:35.61, Global PSNR: 31.667, SSIM Mean Y: 0.8931659 ( 9.713 dB)


----------------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc --bitrate 6000
encoded 500 frames in 659.57s (0.76 fps), 6054.60 kb/s, Avg QP:40.14, Global PSNR: 29.542, SSIM Mean Y: 0.7802421 ( 6.581 dB)

After
x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-refs 1
encoded 500 frames in 524.01s (0.95 fps), 6053.17 kb/s, Avg QP:40.15, Global PSNR: 29.537, SSIM Mean Y: 0.7800589 ( 6.577 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1
encoded 500 frames in 469.41s (1.07 fps), 6056.95 kb/s, Avg QP:40.18, Global PSNR: 29.535, SSIM Mean Y: 0.7798592 ( 6.573 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 1
encoded 500 frames in 433.19s (1.15 fps), 6058.14 kb/s, Avg QP:40.19, Global PSNR: 29.529, SSIM Mean Y: 0.7796667 ( 6.569 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 3
encoded 500 frames in 340.68s (1.47 fps), 6057.80 kb/s, Avg QP:40.19, Global PSNR: 29.519, SSIM Mean Y: 0.7789705 ( 6.555 dB)

[x265_Project]

From 16 min to 9 min? If there really is minimal.quality loss, that's a big win! That'd allow going up around one preset level
Yes, we think so. As you can see from the test data above, with --preset veryslow --limit-refs 3 --limit-modes, you get 2x the speed of --veryslow, with fairly minimal quality impact. So anyone who was previously using --preset slower would probably get a better result using --preset veryslow, --limit-refs 1,2 or 3, and --limit-modes.

[nandaku2]

Also, it seems like --frame-threads is often higher than needed to saturate processors, and can cause quality issues with noisy content. So looking for how to reduce that to the minimum needed for maximum throughput might make sense. And certainly they should be lower for the faster presets, perhaps with --pmode turned on in some cases to recapture some speed.

Hmm, dial down framethreads, raise looakhead-slices, this might be worth trying, although at the below-medium presets, the gains from lookahead-slices aren't as significant.

Automatically turning on --pmode with lots of cores and lower frame sizes could also help speed, with the cost of some determinism.

pmode has been tricky that way, while utilization shoots up, we havent seen any speed gains from it yet. The cost of duplicating and sharing context across threads destroys any utilization benefits.

Adding --qg-size 32 for the slower presets is probably good.

This has been turned on for a while.

[littlepox]

For preset testing, probably we can rely heavily on objective metrics like psnr/ssim. for example, if ref=5/umh/25 has a better psnr/ssim than ref=3/star/57, with almost equal or even faster speed, then we'd probably recommend ref=5/umh/25 in any suitable condition.

However for tunings --tune film/grain/animation, where we need to focus on speed-irrelevant parameters like aq/psy/qcomp/crf, the only reliable metric is the human eyes, even at high bit-rate.

Currently I agree that --preset shall be studied before --tune, because this benefits future tests time-wisely.

[Boulder]

Is it possible to build x265 with Visual Studio 2015 Express? Or is the 2013 the latest supported edition without having to edit the configuration files?

[Motenai Yoda]

what about scaling-list off (default) vs default (no default) ?

[Ma]

Is it possible to build x265 with Visual Studio 2015 Express? Or is the 2013 the latest supported edition without having to edit the configuration files?

For VS 2015 there are no build scripts, so you should modify scripts from vc12* folders.

I attached my builds scripts for example. They works in subdirectory of x265 folder (I created 'x265\ma' folder) with cmake, mercurial, yasm and 7z on path.

[Motenai Yoda]

For VS 2015 there are no build scripts, so you should modify scripts from vc12* folders.
just copy vc12-x86_64, rename it as vc14-x86_64
open each one bat with notepad, replace all 12 with 14, then all 14b with 12b, save, done.

[Boulder]

just copy vc12-x86_64, rename it as vc14-x86_64
open each one bat with notepad, replace all 12 with 14, then all 14b with 12b, save, done.Thanks to both of you, I ended up using this trick which worked fine :)

[zbutsam]

I ran a few tests comparing the encoding speed using the new switches --limit-modes and --limit-refs 3.

I got a 8-10% improvement in preset medium and 60-70% improvement in preset slow both in SD and HD sources. I used --crf 20 and I run the test on an Intel 2500K. I didn't run any slower presets but the results seem promising. Also, I didn't notice any quality degradation.

[Barough]

I ran a few tests comparing the encoding speed using the new switches --limit-modes and --limit-refs 3.

I got a 8-10% improvement in preset medium <snip>

Got around 15 % speed improvement here on Preset Medium and didn't noticed any quality reduction.

[x265_Project]

what about scaling-list off (default) vs default (no default) ?
What about it? What effect do you observe on speed and visual quality when using --scaling-list default? What presets would you suggest that we change?

[mandarinka]

I did tests of x265 for several times so far over last year+, but I keep hitting one quality issue - when encoding somewhat grainy/noisy or textured footage (in my case it is hand-drawn film/cel animation, the noise isn't necessarily very strong), there are areas where the grain or texture gets wiped out.

These areas are square and when I checked them in a stream analyzer several months ago, they seemed to align with block boundaries. These areas looked like they have almost no residual (the blocks look flat) as opposed to their neightbours which show a noise/grain pattern. Basically it seems to me that x265 does keep grain/noise in some CUs/CTUs, but removes it almost completely in others.

I didn't find any way to prevent that, does anybody have any advice about how to get the frames' look to be uniform? I'm trying this at high bitrates (15-20 megabits at 1440x1080p24) so I would expect it to be possible to get close to transparent quality.

Here is a comparison (http://screenshotcomparison.com/comparison/150244/picture:0) (frames 2, 37, 154) showing uncompressed and compressed frames that suffer from this effect.


Source video (http://ulozto.net/x4xd3Bw8/source-ll-mkv) (200 frames), encode (http://ulozto.net/xCzY5Atn/encode-test-doom9-hevc) (20094 kbps).

commandline:

x265_main_1.8+76-bd8237a5d782.GCC520.exe - --input-res 1440x1080 --fps 24000/1001 --preset placebo --subme 7 --ref 6 --aq-mode 1 --qg-size 16 --rd 6 --psy-rd 1.0 --psy-rdoq 1.0 --rdoq-level 1 --crf 14

(I used 64bit build from this post (http://forum.doom9.org/showpost.php?p=1745333&postcount=2882), 8bit mode, run on Windows 10 64, AMD A10-6800K, fed through avs2yuv).


Looking at the analyzer (assuming it isn't broken) seems to show that these flat-residual blocks happen when a 64x64 CU is used.
Screenshots: just residual (http://i.imgur.com/1DVNLkT.png), with the TU grid shown (http://i.imgur.com/FsOWqFU.png). When I tried to use --ctu, the effect was lessened, but it seems to me that some of the smaller blocks in these ares keep being smoothed/denoised. Perhaps it is blocks that have an strong outline/edge running through them (here is image of the same frame with --ctu 16 (http://i.imgur.com/Q3WViVH.png))?

------------------------------------------------------------
P.S.
x265 crashed on me with the same commandline and --ctu 16 ( --preset placebo --subme 7 --ref 6 --aq-mode 1 --qg-size 16 --rd 6 --psy-rd 1.0 --psy-rdoq 1.0 --rdoq-level 1 --crf 14 --ctu 16). I had to manually set --tu-inter-depth 1 and --tu-intra-depth 1, these should probably be set automatically when ctu is limited?

[nandaku2]

@Mandarinka,

Thank you for your test case. I ran the exact commandline, and opened the residual in an analyzer. At 95%+ of the places where bad blocks showed up, the mode chosen was intra DC.

[Motenai Yoda]

What about it? What effect do you observe on speed and visual quality when using --scaling-list default? What presets would you suggest that we change?

Nothing special, it reminds me an h.263 cqm, seems to thrown away high freq but this didn't help at all with rl stuffs (at least not crowd_run or park_joy) even with >30 crf...
But seems to be in pair with some animation ones, somewhere better, somewhere worst.
at the same bitrate metrics (avg qp, ssim, psnr) looks better but visually it isn't, maybe is a bit faster (+5%)

[x265_Project]

Here is an updated look at the improvement that --limit-refs and --limit-modes can make to encoding speed...
http://x265.org.s3.amazonaws.com/img/LimitRefs&LimitModes2.png
Testing was done with 2 clips each at 720P (3 Mbps), 1080P (6 Mbps), and 4K (15 Mbps) on an Intel Core i7 6700K system, using --preset veryslow.

[D3C0D3R]

The main reason why this was so efficient for H264 does not apply to HEVC anymore though, so the gains should be smaller, and moving from 8 to 10

Name this reason, please.

[mandarinka]

Probably referring to the bias in biprediction and interpolation, that was leading to off by 1 errors in prediction that needed to be corrected by coeficients in residual. IIRC H.264 had such problem (and HEVC supposedly not). If I am recalling this wrong or making up non-existent stuff then somebody please correct me.

[LigH]

After a longer while without commits, now another build with important changes. This one might be related to the loss of details, as discussed here by mandarinka and nandaku2:

intra prediction: disable 64x64 analysis

In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.

x265 1.8+106-e8f9a60d4cd9 (GCC 4.9.2) (https://www.mediafire.com/download/822v2kqltv4dulg/x265_1.8+106-e8f9a60d4cd9.GCC492.7z)
x265 1.8+106-e8f9a60d4cd9 (GCC 5.2.0) (https://www.mediafire.com/download/cqqgr4sepimrh9f/x265_1.8+106-e8f9a60d4cd9.GCC520.7z)

[littlepox]

After a longer while without commits, now another build with important changes. This one might be related to the loss of details, as discussed here by mandarinka and nandaku2:

intra prediction: disable 64x64 analysis

In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.

x265 1.8+106-e8f9a60d4cd9 (GCC 4.9.2) (https://www.mediafire.com/download/822v2kqltv4dulg/x265_1.8+106-e8f9a60d4cd9.GCC492.7z)
x265 1.8+106-e8f9a60d4cd9 (GCC 5.2.0) (https://www.mediafire.com/download/cqqgr4sepimrh9f/x265_1.8+106-e8f9a60d4cd9.GCC520.7z)

what is the difference between this change and --ctu 32 ?

[Barough]

Thnx for the new compiles LigH :)

[Boulder]

After a longer while without commits, now another build with important changes. This one might be related to the loss of details, as discussed here by mandarinka and nandaku2:

intra prediction: disable 64x64 analysis

In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.Looks like I need to do some comparisons again. Last time I did those a week ago or so, x265 was much closer to x264 than earlier. I did notice that some flat areas were punished quite heavily while neighbouring areas were spared. Brighter uniform areas with grain didn't suffer as much as darker areas.

[foxyshadis]

what is the difference between this change and --ctu 32 ?

It only applies to intra CUs. Inter CUs in P/B frames still get 64x64 tested, since they never used the speed hack intra 64x64 did. I'm wondering why the hack was removed entirely instead of being restricted to fast presets. (Without the hack, true 64x64 analysis is prohibitively slow. Maybe a candidate for veryslow or placebo preset?)

[x265_Project]

It only applies to intra CUs. Inter CUs in P/B frames still get 64x64 tested, since they never used the speed hack intra 64x64 did. I'm wondering why the hack was removed entirely instead of being restricted to fast presets. (Without the hack, true 64x64 analysis is prohibitively slow. Maybe a candidate for veryslow or placebo preset?)

We weren't happy with the design of the 64x64 Intra implementation, so it was removed, and for the moment 64x64 Intra analysis is off entirely. I agree that our highest quality presets should analyze every possibility.

Tom

[mandarinka]

After a longer while without commits, now another build with important changes. This one might be related to the loss of details, as discussed here by mandarinka and nandaku2:

intra prediction: disable 64x64 analysis

In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.

x265 1.8+106-e8f9a60d4cd9 (GCC 4.9.2) (https://www.mediafire.com/download/822v2kqltv4dulg/x265_1.8+106-e8f9a60d4cd9.GCC492.7z)
x265 1.8+106-e8f9a60d4cd9 (GCC 5.2.0) (https://www.mediafire.com/download/cqqgr4sepimrh9f/x265_1.8+106-e8f9a60d4cd9.GCC520.7z)

:thanks:

I'll test this soon (currently celebrating the aniversary of November 1989).

Edit: From cursory look I think this change really helped with look of those blocks. I think one can still spot thatt ehy differ from source when comparing, but they look more uniform and aren't smoothed (I guess because the encoder is now inter predicting those areas?). Ideally I should make a before/after comparison to really tell, but I think this really improved the ability to achieve transparent quality, with this kind of soruce at least.

Oh, and thanks again for looking into the sample, Nandaku2!

[x265_Project]

:thanks:

I'll test this soon (currently celebrating the aniversary of November 1989).

Edit: From cursory look I think this change really helped with look of those blocks. I think one can still spot thatt ehy differ from source when comparing, but they look more uniform and aren't smoothed (I guess because the encoder is now inter predicting those areas?). Ideally I should make a before/after comparison to really tell, but I think this really improved the ability to achieve transparent quality, with this kind of soruce at least.

Oh, and thanks again for looking into the sample, Nandaku2!
Thanks for your feedback! We are continuing to work on this, but I think we're on the right track.

[nandaku2]

It only applies to intra CUs. Inter CUs in P/B frames still get 64x64 tested, since they never used the speed hack intra 64x64 did. I'm wondering why the hack was removed entirely instead of being restricted to fast presets. (Without the hack, true 64x64 analysis is prohibitively slow. Maybe a candidate for veryslow or placebo preset?)

So, this hack is not ideal because it does an extra 64x64 analysis (for sa8d), but proper 32x32 TU RDO for final decision. The new patch biases away from blurry modes by removing an extra analysis - without increasing bits.

[LigH]

Interesting proposed patch:

rc: implement 2 pass CRF, when vbv is enabled.

Allow CRF with VBV in 2nd pass to increase the quality of capped CRF in the first pass.

I guess that could be useful for HQ movies getting close to the transfer rates of USB 2 devices (like bigger but not very fast readable Flash sticks) or WLAN with not optimal signal quality and reduced speed? Or is there a different specific purpose to implement such a refining bitrate control mode as "least possible quality loss below a bitrate cap"?

[sneaker_ger]

Are you really asking what the purpose of a function to minimize quality loss is? ;)

But of course doing a second pass of a complete movie is a lot of time to invest. Would be more interesting if it would be limited to affected scenes only.

[LigH]

No, I know why someone would want to minimize loss under the constraint of a maximum bitrate. But I wonder which are the most common usage cases where 2-pass CRF+VBV would be preferred over both 1-pass CRF (without VBV constraint) and 2-pass VBR (with target size ... OK, the latter is only necessary when you have a target capacity as constraint, which you don't have for CRF, with or without VBV constraint).

VBV maximum bitrate constraints are important when the reading speed is not much higher than the decoding speed. "Slow" networks or media are a common reason to apply VBV max rate constraints. I am curious if there are other cases in the minds of the developers as reason to develop this mode than the ones I could imagine.

[benwaggoner]

No, I know why someone would want to minimize loss under the constraint of a maximum bitrate. But I wonder which are the most common usage cases where 2-pass CRF+VBV would be preferred over both 1-pass CRF (without VBV constraint) and 2-pass VBR (with target size ... OK, the latter is only necessary when you have a target capacity as constraint, which you don't have for CRF, with or without VBV constraint).

VBV maximum bitrate constraints are important when the reading speed is not much higher than the decoding speed. "Slow" networks or media are a common reason to apply VBV max rate constraints. I am curious if there are other cases in the minds of the developers as reason to develop this mode than the ones I could imagine.
VBV constraints are also required to be compliant with a particular Level. Thus they are pretty critical when targeting hardware decoders, and also can cap worst-case decoder complexity for software decoding as well.

I always use VBV for any encode I want to be playable on arbitrary decoders, for the same reason I always follow max refs and other constraints.

[Motenai Yoda]

But 1pass crf yet can be vbv restricted, what should do a 2 pass one?

- do a 1st analysis pass then a 2nd encoding pass where the quality reduction is spreaded in a more large range and forward too?

- do a classical 1st crf w/o vbv encode pass and saving a log for the 2nd pass which encode ex novo only those gop around critical sections/zones and copy the others?

why not add instead a lookahead bitrate estimation to work with the usual crf+vbv?
(but this can not work so well)

[x265_Project]

CRF is a great "mode" for x265, but it's really not "rate control", it's constant quality. It's a form of variable bit rate (VBR) encoding. The bit rate can vary as widely as needed in order to maintain a target level of quality. If the video in some places is especially complex (lots of detail + lots of motion), the bit rate will be very high.

CRF can produce very efficient encodes in a single pass. Commercial companies need video encoders that meet real-world conditions (understanding channel bandwidth and the real constraints of hardware decoders). So CRF is often used with VBV to insure that the bit rate meets real-world requirements. This combination is sometimes called capped VBR.

The downside of capped VBR is that while for most of the title you're able to get constant quality, in the sections where VBV kicks in to enforce the VBV parameters, the quality is lower. This new 2 pass CRF feature in development allows for selective re-encoding of the sections where VBV impacted the quality in order to minimize the severity of the quality impact.

[foxyshadis]

That's pretty cool! How far back does it rewind time when it hits a VBV limit? Just to the beginning of the frame, or multiple frames, or will that be adjustable?

[x265_Project]

That's pretty cool! How far back does it rewind time when it hits a VBV limit? Just to the beginning of the frame, or multiple frames, or will that be adjustable?
It will analyze and, if it makes sense, re-encode the affected GOP and the previous GOP. The 2nd pass runs similarly to 2 pass ABR, but it only re-encodes affected areas where it's able to make a difference (essentially reducing quality/bit rate a bit prior to the area of high complexity where VBV kicked in, saving more bits for the area where VBV clamps down, lessening the severity of the quality hit caused by VBV).

[LigH]

From my time in a DVD authoring studio, I remember a similar technique from MPEG-2 encoders trying to create DVD Video compliant results. Even some hardware encoders used such a short distance recoding technique. If I'm not completely wrong, also HCenc may do so, or did once?

[Boulder]

Yes, that's what HCEnc does. It will re-encode the GOP to meet the VBV demands.

[Boulder]

That's my bug report right there :) I must say that there has been improvement recently, but I haven't had the time to test the most recent changes which should also help with the issue. I suggest that you run some tests yourself and see what you can come up with.

[x265_Project]

I would note that in my limited testing, recent development builds of x265 seem to tolerate much higher psy-rd settings without producing strange artifacts. So you should be able to increase detail retention even further with higher psy-rd strength. Feedback from the community on this would be welcomed.

Tom

[Boulder]

@Boulder: What kind of improvements are you specifically refering to?Detail (=grain etc.) is not as heavily blurred, or at least not in all cases. Some further changes were made after I tested the last time, you can read the last few pages to see what they have been working on when some evidence came up.

[Boulder]

If you have the time to spare, --preset veryslow with some low CRF value is a very good option (don't ask me what's low, you'll have to find the level which suits your needs). Maybe experiment with the options mentioned in this post (http://forum.doom9.org/showthread.php?p=1746714#post1746714) to find a good quality/speed tradeoff. Chances are that you won't notice a thing if you enable --limit-refs 3 and --limit-modes.

[LigH]

The encoder will use more elaborate search methods, taking more time to search for the perfect match to have the smallest difference to compress (which usually results in smaller compressed data). But if it does not spent so much efforts, does not find the optimum, it only has to compress bigger differences and generate a bigger video stream, but can still retain the same quality ... at least in CRF mode without restraining the bitrate. CRF tries to guarantee a quality loss threshold. If your rate factor value is small enough, enough quality will be retained. Just at the cost of bigger results.

Try for yourself with a small video clip and compare for yourself how few percent or even permille the results differ in size, and if the difference in encoding time is more relevant. In either case, if your rate factor was small enough, you will be satisfied with the quality retention, no matter how elaborate the encoder tries to reduce the size of the result by more efficient encoding.

[LigH]

Compare to car tuning:

The only reliable way to gain horsepower is by increasing the cylinder capacity. Everything else is minor tuning. But then you will have more fuel consumption as price.

The only reliable way to get "visually transparent" copies is to aim for a small enough rate factor. Everything else is minor tuning. But then you will have more bitrate as price.

You may try to increase the psychovisual parameters (just this week I read that their range of values became more tolerant), then you may get a convenient result already with a bigger CRF (16 is already quite small for x265, it's not the same as in x264, I guess around 20 can be enough). And if your source is grainy, try a large NR parameter (>100).

[nandaku2]

@pingfr: what was the difference in settings between your 2 encodes; you mentioned 155MB larger - than what?

[foxyshadis]

Well to decrease the size you just increase CRF. If you can't tell the difference between two encodes then they're larger than they need to be, and you should test higher crf. There's a hard limit to how much you can compress film grain (without generating it, which nothing can really do yet), so the more film grain you have and want to keep, the less useful more advanced compression gets. Aside from that, don't mess with me and subme after setting a preset, that's the whole point of using a preset in the first place. Just use medium instead of slow if you want it faster.

psy-rd can reasonably be 0.5-1.0 without causing trouble, higher the grainier your video is; the default 0.3 just hasn't been updated yet.

[sneaker_ger]

What is it with --tune grain and flattening blocks? Take a look at the sky:

x265 10bit 1.8+120

Source (287 MB) (https://mega.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc) ( Trim(634,1156), crop(0, 24, 0, -24) )
encodes and screenshot package (https://mega.nz/#F!g913GRKZ!wMmEbi1EN2f35xIdXJtUbw)

settings: --preset medium/slow/slower (--tune grain) --limit-refs 3 --limit-modes --bitrate 7000 --pass 1/2

Original:
http://abload.de/img/140_original_gqsiy.png

Without tuning:
http://abload.de/img/140_medium_pssye.png
http://abload.de/img/140_slow_x3snt.png
http://abload.de/img/140_slower_xes31.png

With tuning:
http://abload.de/img/140_medium_grain_8msrl.png
http://abload.de/img/140_slow_grain_y9szd.png
http://abload.de/img/140_slower_grain_zist4.png

[LigH]

I would guess that "--tune grain" requires a lot more bitrate now, so the general quantisation got worse.

[x265_Project]

Pingfr - it would help if you show us your results, and not just your settings. If you use the --csv option with --ssim and --psnr, you could see the relative objective quality measurements for each test encode. While ssim and psnr are far from perfect, they are fine for an understanding of the relative quality between different encodes - especially when you're doing things that trade off quality vs speed.

[LigH]

They will write technical internal values into a log file in CSV format which you can load into a calculation application (spreadsheet, e.g. Excel) and compare graphs. Much smaller, easier to download, and tells tech-savvy people quite a bit before even watching the video.

Furthermore, the content of log files only is certainly not copyrighted ... I don't know which video you uploaded until I download it.

[LigH]

You have an AviSynth script as source? Then try avs4x26x (http://forum.doom9.org/showthread.php?t=162656) instead of ffmpeg, much simpler, it will handle piping raw video and forwarding resolution and framerate parameters on its own.

avs4x26x -L x265_x64.exe --preset slow --crf 19 --csv crf19.csv -o crf19.265 source.mkv.avs

Do not put files into C:\ - this should be a UAC protected directory; always create a separate subdirectory (and if you have more than one HDD, preferably on a different internal drive than your Windows system).

Apart from that, the "--csv filename" parameter looks not bad, but read also about adjacent parameters, e.g. "--csv-log-level #"; level 0 will only report a summary per encode, level 1 will write a verbose log with per-frame details (ensure to use separate csv filenames per setting), and level 2 even with some performance statistics.

avs4x26x -L x265_x64.exe --preset slow --crf 19 --csv crf19.csv --csv-log-level 2 -o crf19.265 source.mkv.avs

[LigH]

Well, my big respect to your efforts, you certainly invested more time into gaining experience than several other people "demanding the best options".
:helpful:
You will find your personal optimum this way. And sharing the results will hopefully add value to the development.
:goodpost:
For Christmas, I wish more users like you! :cool:

[foxyshadis]

Note that the only reason to use --limit-refs and --limit-modes is as a speed-up option. I have a feeling they'll probably be incorporated into the presets at some point, but with them you can use more references without the speed hit (you only pay the memory cost now). However, --preset slow is already 3 refs, so --limit-refs 3 isn't actually doing anything in that case. (Unless B-frames count as an automatic ref, like in x264? Not sure.)

The quality of --limit-refs 3 is somewhere between just 3 references and the full reference count, closer to full, but about the same speed as ref 3. You can see how useful it can be with more references.

[LigH]

Average Quantization P..?: CRF gives a kind of quantizer target, but the encoder (x264 or x265) may already stay below the desired threshold of quality loss at a bigger quantizer for scenes with little detail and little motion. CRF doesn't waste precision where not much precision is required to reconstruct the video good enough.

If you had a preset or a custom command line where you allow at most 8 references per frame, but try to limit references to 3, then "full" would be all 8 references (which is hardly ever necessary).

[foxyshadis]

Ignore what I said, I was confusing it with an older experimental where only X references were considered... totally forgot that the actual implementation applies the same no matter how many refs you have. Sorry.

[LigH]

So what's "best" a high or a low value? should I be "worried" or "concerned" in any ways at all? :)

Just in parallel to CRF, a smaller quantizer gives a better quality but a less efficient compression. Imagine it like an integer divisor: Thousands of different values (frequency domain parameters you can hardly imagine as a human) are divided to become only a few hundreds of different values to be compressed; during decoding, they are multiplied again with the quantizer to return to their original magnitude, but are then steps of this quantizer apart from each other (multiples of this quantizer).

Very simplified, you may interpret CRF like: "In the worst case, use a quantizer as low as this, but if you discover that a bigger quantizer is good enough, that's even better". Of course, it's a bit more complex.

Interpreting your logs can take some time. We may have jobs, you know ... patience. :)

[nandaku2]

Ok - will try to answer.

limit-refs (1/2/3) - this option uses heuristics to determine the best reference to be used for a block. Basically, limit-refs 3 combines the heuristics used in limit-refs 1 and 2 (think bitflags, it has nothing to do with actual number of references). Essentially, this means the encoder finds the best reference faster. For fast moving videos, more references is better for compression efficiency. So, turning on limit-refs will enable the user to increase the number of references (--ref) without the speed penalty. And if you compare commandlines with --ref N, and another with --ref N --limit-refs 3, you will find a small drop in SSIM, but visually nothing at all - and of course, the latter will be significantly faster like you found.

@foxyshadis: Indeed, we are just winding up our new preset testing, which will increase --ref and turn on limit-refs for better quality. Early next week.

CRF indicates a certain quality level for that particular sequence- the encoder can use any quantizer (determined by frame complexity) with the only objective being maintaining constant visual quality.

[Boulder]

What comes to hardware decoding, what kind of limits are there regarding the number of refs? I don't know if there's a simple table to look at like there is for MPEG-4 AVC at Wikipedia.

[nandaku2]

The maxDpbSize column here indicates the maximum number of references that a decoder conforming to a specific level will support.
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

[Motenai Yoda]

IIRC x265 can use up to 16 ref, but HEVC specs allow only up to 8 ref/DpbSize.
And you have to take in account as DpbSize 1 frame for bframes and 1 frame for b-piramidal, so it should be 6.

the paper says:
The value of sps_max_dec_pic_buffering_minus1[ HighestTid ] + 1 shall be less than or equal to MaxDpbSize, which is derived as follows:
if( PicSizeInSamplesY <= ( MaxLumaPs >> 2 ) )
MaxDpbSize = Min( 4 * maxDpbPicBuf, 16 )
else if( PicSizeInSamplesY <= ( MaxLumaPs >> 1 ) )
MaxDpbSize = Min( 2 * maxDpbPicBuf, 16 ) (A-2)
else if( PicSizeInSamplesY <= ( ( 3 * MaxLumaPs ) >> 2 ) )
MaxDpbSize = Min( ( 4 * maxDpbPicBuf ) / 3, 16 )
else
MaxDpbSize = maxDpbPicBuf

where MaxLumaPs is specified in Table A.4 and maxDpbPicBuf is equal to 6.
but this seems don't work well, ie with a 1280x768 input and level 4 x265 will reduce ref to 7 but "issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless"
x265 [info]: Lowering max references to 7 to meet numPocTotalCurr requirement
x265 [warning]: level 4 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: non-conformant bitstreams not allowed (--allow-non-conformance)
x265 [error]: failed to open encoder
avs [error]: Error occurred while writing frame 2

[Vesdaris]

Guys, what changes should I make to a medium preset that would allow me to greatly reduce blur and keep as much detail as possible without sacrificing much encoding speed?

Cheers

[foxyshadis]

IIRC x265 can use up to 16 ref, but HEVC specs allow only up to 8 ref/DpbSize.
And you have to take in account as DpbSize 1 frame for bframes and 1 frame for b-piramidal, so it should be 6.

the paper says:

but this seems don't work well, ie with a 1280x768 input and level 4 x265 will reduce ref to 7 but "issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless"
x265 [info]: Lowering max references to 7 to meet numPocTotalCurr requirement
x265 [warning]: level 4 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: non-conformant bitstreams not allowed (--allow-non-conformance)
x265 [error]: failed to open encoder
avs [error]: Error occurred while writing frame 2

It should probably be setting anything out-of-spec to level 8.5, which is now the designated "unrestricted" level, although a warning that it's not supported in the base spec is useful.

I don't think that NumPicTotalCurr is the actual maximum size of the DPB, because it's never used in the derivation of the reference picture set, but rather the maximum that any one ref list can include. The DPB for 1280x720 @ L4.0 would be 12 pics. When a DPB is larger than 8, at least 4 pics would then be placed in the RefPicSetStFoll in the RPS (unavailable to the current picture but still available to future frames), without having to be marked "unused for reference" (unavailable for good). I'm trying to sort out from the spec whether it's also possible for B-frames to have completely different frames in each list, meaning all 16 can be referenced at once, but I'm not certain.

I don't think x265's test for conformance is correct here.

[x265_Project]

Guys, what changes should I make to a medium preset that would allow me to greatly reduce blur and keep as much detail as possible without sacrificing much encoding speed?

Cheers
Increase --psy-rd strength to a value higher than the current default (0.3). You can start with 1.0, and see if this produces any visible artifacts (ghosting around objects, or strange motion artifacts). If not, you can try even higher values. If so, reduce psy-rd strength. Do short tests (limited number of --frames) until you figure out what seems to work best for your content and settings.

[qidin]

Hello all!

I am a newbie coder. I need the opinion that these settings are optimal in terms of quality. I want to transcode my collection of anime. My PC is not a deamon. Its only i5 4210h (2/4).

Need optimal setings to have ~~3-4 fps. Thx for your all comments and best regards.

I think that there is still room to improve this settings but for now im lack of knolage.

--bframes 6 --ref 3 --rc-lookahead 40 --merange 24 --aq-mode 2 --aq-strength 1.1 --psy-rd 0.80 --psy-rdoq 4.00 --rd 6 --deblock -2:-2 --keyint 720 --qcomp 0.60 --me hex --output-depth 10 --limit-refs 3

PSNR: ON
Preset: Medium

[LigH]

For the joy of nitpicking: There is no optimum for every movie – just one per movie.

Reducing the in-loop deblocking for cartoons is suspicious. Usually a softer deblocking helps reducing possible artefacts in low detail color ramps. I'd recommend you to read about "--tune *" details.

PSNR is unimportant, nobody should care about this simple technical metric a lot.

[vivan]

You could start with a base value of a 1.00 = a flawless copy of the source. At 0.95 = you could estimate there is a 0.05% degradation between the original frame and the encoded ones, At 0.90 = there's a 0.10% degradation from the original and so forth.That's how objective quality metrics work (and how most comparisons are made, except all of this is done in 1-2 steps. In fact you've done this already with your csvs). The main problem is defining that "degradation". If you choose to use simple difference, that will be PSNR (simple but has low correlation with Human Vision System aka what we think good/bad quality is). SSIM is better, but still far from perfect.

As for marking difference - it's easy to do this with avisynth, for pixels that would be Subtract (http://avisynth.nl/index.php/Subtract) with some tweaking, for blocks that will be a bit harder.

[Motenai Yoda]

As you will encode frames from different scenes 98% you'll get all keyframes, so the comparison will be invalid.

but you can get some short clip with selectrangeevery() in avisynth
all others points can be done with an avs script (maybe the "cell" thing can be a bit slow), but on an lossy encode easely most of the pixel somehow differ from the source.
Also surely ssim, avgQP and maybe psnr too will do a better job to estimate the "loss".

[vivan]

As you will encode frames from different scenes 98% you'll get all keyframes, so the comparison will be invalid.He never said that he's going to use frames for different scenes, he just said "Cut out a 60 seconds sample"...

@vivan: do you have a guide on how to do that with existing open-source tools?You can start here (http://avisynth.nl/index.php/Main_Page) to learn about avisynth - tool that most of us use to process/inspect video.

Okay, let's say you want to measure PSNR (get PSNR value per frame) using avisynth Compare (http://avisynth.nl/index.php/Compare). Install:
1) avisynth (http://avisynth.nl/index.php/Main_Page) (v.2.6.0 ST, 32-bit)
2) AvsPmod (http://forum.doom9.org/showthread.php?t=153248) (to view script output)
3) ffmpegsource (http://avisynth.nl/index.php/FFmpegSource) (plugin to open your video in avisynth, put it into "plugin" folder in the avisynth's install directory)

Write s = ffvideosource ("source.mkv")
e = ffvideosource ("encode.mkv")
Compare (s, e) into text file, change it's extension to .avs, open it with AvspMod. It will show PSNR value.

Change last line to Interleave (s, e, Subtract(s, e).levels(122,1,132,0,255))to see per-pixel differences.
(If you will have questions about avisynth, please ask them in the avisynth subforum)

When I was thinking of cells earlier, I had something like this in mind; http://www.streameye.elecard.com/images/trash/screen_other2.jpg

Not exactly that, but it's getting close enough, I would just have added a color filter on top of each grid cell based on the "distortion" compared from original and encoded bits.I don't remember seeing anything like this, so I guess asking here (http://forum.doom9.org/forumdisplay.php?f=33) for a script that will do what you want (compare 2 videos and tint all blocks depending on psnr value of that block) is what you need.

[LigH]

I remember a comparison tool "Fritz Framalyzer", but never used it, so don't know if it matches your expectations.

Always remember, metrics only calculate a value related to a difference between two videos, but there is no metric which can calculate how pleasant or annoying a specific loss of quality looks to you, specifically.

[benwaggoner]

I note a probable typo in the x265.readthedocs for --lookahead-slices (http://x265.readthedocs.org/en/default/cli.html?highlight=lookahead#cmdoption--lookahead-slices)

Default: 8 for ultrafast, superfast, faster, fast, medium 4 for slow, slower disabled for veryslow, slower

That presumably should end in "veryslow, placebo"

...which I was looking up as I'm wondering what sort of degradation that using lookahead-slices might cause. Using frame-threads could cause bad problems with high-noise content, but didn't seem to have much impact on "normal" content. Would lookahead-slices impact the same scenarios? Or does it only impact I/P/B/b decisions?

[x265_Project]

I note a probable typo in the x265.readthedocs for --lookahead-slices (http://x265.readthedocs.org/en/default/cli.html?highlight=lookahead#cmdoption--lookahead-slices)



That presumably should end in "veryslow, placebo"
Yes. We'll fix this. Note that anyone can submit "patches" to our online documentation, as they are in Restructured Text format (.rst) files which are part of the source code.

...which I was looking up as I'm wondering what sort of degradation that using lookahead-slices might cause. Using frame-threads could cause bad problems with high-noise content, but didn't seem to have much impact on "normal" content. Would lookahead-slices impact the same scenarios? Or does it only impact I/P/B/b decisions?
As you know, the lookahead function does a quick pseudo-encode based on 1/4 resolution frames. The function of the lookahead is to estimate the cost (# of bits) of encoding each frame, and to make slice type (I/P/B/b) decisions. Parallelizing the lookahead by using multiple slices per frame has an extremely minimal negative effect on encoding efficiency, but in certain cases (especially 4K encoding on many-core servers) a big positive effect on performance. This is easy to experiment with, just by doing a couple of test encodes with various --lookahead-slices values, including 0.

[littlepox]

As you know, the lookahead function does a quick pseudo-encode based on 1/4 resolution frames. The function of the lookahead is to estimate the cost (# of bits) of encoding each frame, and to make slice type (I/P/B/b) decisions.

That's probably the issue here. Down-scaling to 1/4 resolution is likely to wipe out the noise, which later makes the estimation biased towards inadequate bit-rates. Normal scenes are less affected by the down-scaling.

If that is the case, possible solutions may be a manual bias favored for the noisy scenes, adding a 1/4 cropped clip as a second predictor, or enabling full resolution look-ahead in some presets and turnings.

[x265_Project]

That's probably the issue here. Down-scaling to 1/4 resolution is likely to wipe out the noise, which later makes the estimation biased towards inadequate bit-rates. Normal scenes are less affected by the down-scaling.

If that is the case, possible solutions may be a manual bias favored for the noisy scenes, adding a 1/4 cropped clip as a second predictor, or enabling full resolution look-ahead in some presets and turnings.
We've made various improvements to the lookahead function over the life of the project and we are currently investigating a number of possible ways to improve the accuracy of lookahead predictions. Full resolution lookahead is one possibility, but the idea behind the lookahead function is to perform some pre-analysis with low computational cost (for example, lookahead might be 2% of the total compute cost). If you try to do too much, the costs could outweigh the benefits. Essentially you could just end up with 2 pass encoding, where the lookahead is like a fast first pass (a fairly accurate predictor of the actual per-frame cost that a 2nd pass can use to allocate bits). Of course we already support 2 pass encoding, which is great for high quality variable bit rate encoding. So, the challenge is to improve the lookahead so that can continue to be used as it is today - as a fast pre-analysis function running ahead of the actual encoder.

[littlepox]

If you try to do too much, the costs could outweigh the benefits.

Understandable, and that's why I'm only suggesting it to be applied for certain preset and tunings, for example adding a center-cropped clip as a second predictor in --veryslow and use full resolution in --placebo.

Furthermore, 2 suggestions for the --presets:

1. --ctu 32 --max-tu-size 16 for presets slower and below. Our tests suggest a ~5% speed increase and a BETTER visual quality @ the same bit-rate.

2. auto-adjusted me-range for different resolutions. Probably 25 for 720p and 41 for 1080p; as from our tests. When --umh/--star/--esa are deployed, me-range affects the speed dramatically, so it make sense to seek some affordable discount, especially if combined with the 1st suggestion which affects the derivation of the current merange=57.

[Vesdaris]

Increase --psy-rd strength to a value higher than the current default (0.3).

http://i.imgur.com/b6MWSnY.jpg

Just psych-visual rdo? Should I leave RDO Quantization level disabled?

[LigH]

Turn up the signal
wipe out the noise
:sly:
_

Some interesting patches still on hold; releasing another "weekly" anyway, since I postponed the last.

x265 1.8+129-e2e507ffe752 (GCC 4.9.2) (https://www.mediafire.com/download/yb4zxb4340l6mbv/x265_1.8+129-e2e507ffe752.GCC492.7z)
x265 1.8+129-e2e507ffe752 (GCC 5.2.0) (https://www.mediafire.com/download/skyf5d7s9tck2zc/x265_1.8+129-e2e507ffe752.GCC520.7z)

[x265_Project]

http://i.imgur.com/b6MWSnY.jpg

Just psych-visual rdo? Should I leave RDO Quantization level disabled?
Adjust psy-rd (Psycho-Visual RDO) only to start. When you have determined the best psy-rd strength, you could experiment with different psy-rdoq strengths.

[Aurelio]

Has anybody tried to play x.265 encoded video file via ffmpeg on a mobile device? I have some strange issues on my Samsung Galaxy S5 (SM-G900F)

If I use a 2-pass encode, the video does not show a preview picture in the gallery / own files. It shows only the icon of the player.

If I use single pass ABR or CRF mode, a preview picture is shown.

I'm using a self compiled ffmpeg version:
ffmpeg version N-76970-ge1057ba Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.2.0 (GCC)
x265 [info]: HEVC encoder version 1.8+2-1f0d4dee7e3b
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit

These are the command lines I use on a windows system:

2-pass

ffmpeg.exe -y -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:pass=1:stats="'mylog.log'"" -c:a libfdk_aac -b:a 384k -f mp4 NUL
ffmpeg.exe -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:pass=2:stats="'mylog.log'"" -c:a libfdk_aac -b:a 384k -f mp4 "title.mp4"

-------------

1-pass

ffmpeg.exe -i "title.mov" -c:v libx265 -preset medium -s 1280x720 -aspect 16:9 -x265-params "bitrate=2000:keyint=60:scenecut=0:log-level=4" -c:a libfdk_aac -b:a 384k -f mp4 "title.mp4"


Videos source does not matter. Can reproduce this with any file. e.g. Big Buck Bunny.

However the MX Player does shows the preview picture in the overview.


The other issue I have:

I have some files which play fine with these settings on the device and others which start to play but then suddenly the video picture freezes and the player skips some frames.

If I changing scenecut setting (e.g. use default) the video freezes at other scenes. Lowering bitrate and/or resolution fixes this.

I'm not sure if this is a hardware limitation or video player issue (tested 2 different ones with same results) or a ffmpeg / x.265 issue. Not sure on what the players choke on.

[Blowis]

Hi, sorry for my English

After encode several films x265 I stay x264. The last movie I can see that encoded on the X265 lacks detail compared to x264.
I tried Whelk test for X265 detail but no it does not x264. I tried with Psy-rd: 0.30 to 2.0, RDOQ Level: 1-2, Psy RDOQ: 0.30 to 2.0, Deblock: -1 to -5, AQ Strength: 0.30 to 1.20. Usually I use the preset Medium but I also tested slow and very slow.

Here x264 encoding with this setting:
cabac=1 / ref=10 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=3031 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Here the encoding image: http://hpics.li/779de15

Here the X265 encoding with this parameter:
wpp / ctu=32 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=2 / tu-inter-depth=2 / me=2 / subme=3 / merange=48 / no-rect / no-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=25 / lookahead-slices=4 / bframes=6 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / weightb / aq-mode=3 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=0.80 / rdoq-level=1 / psy-rdoq=1.00 / signhide / deblock=-2:-2 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Here the encoding image: http://hpics.li/057ed69

We can see that there's less detail on all over the face on the side the beard, on the neck.
After he remains the encoding time is very long compared to x264 example encodings I gave 6 hours for the x265 against 5 Hours to x264. If I make the 2pass x265 takes 9 hours.
I won with the X265 500MB for a film but for now I'll stick with the x264. But continue testing with the new updated the X265.

[x265_Project]

Chennai India is experiencing record-breaking rainfall and flooding. Offices are closed, power and Internet service outages are widespread. Although some of us are in the US, most of the MulticoreWare x265 development team is in Chennai.

Of course the safety and well-being of our employees and their families comes first. While it's been difficult reaching everyone, so far our team members are reporting that they are safe, but dealing with flooding in their homes and neighborhoods. They are doing their best to cope with the situation, working from home when they have power, and communicating when they have Internet or phone service. A number of employees are temporarily relocating to other parts of India.

The weather forecast is for more rain through the next week, so it may be another week before the floods recede and we're able to re-open our office. So, please understand that response times to issues and questions may be a bit longer in the coming days.

Thanks,
Tom

[LigH]

Sounds like a little desaster. I can partially understand, witnessed some flood in eastern Germany years ago, but will probably have to imagine a whole magnitude larger. So, best wishes for little loss and soon subsiding.

[ndkamal]

@x265_Project : I hope they are all safe and good health.

[x265_Project]

Thanks everyone. We've heard from our managers, and although our team is dealing with various difficulties, including homes and cars being flooded, power, phone and Internet outages, and difficulty obtaining food, water and gasoline, they are getting through it.

I found this video on YouTube, showing the basement in the office complex (DLF IT Park) filling up with water. https://www.youtube.com/watch?v=CF2NXVmZvjg (https://www.youtube.com/watch?v=CF2NXVmZvjg) Two levels of the basement are filled with water, but our offices on the first floor were not flooded.

[undfeatable]

Sorry to hear about the flooding, hope the team comes out okay.

I figured this was the right place to post this, really bad timing, but figured I should point it out. Im new to all this... coding in general...this forum... and am having an issue when running h265.

It took forever for me to learn enough to set the program up, but I have it running now and encoding correctly on my Macbook Pro. Im running the linux build and doing test encodes for HDR.

Here is my issue, for some reason, the program will only run 50% of the time. I set it all up, hit enter, and it gives me a Segmentation Fault 11. I just keep trying to rerun it until it eventually goes through. Any ideas on why this would be? Which files would you need to debug this / how to get those if you need them. Completely understand any delay with the flooding.

[x265_Project]

Sorry to hear about the flooding, hope the team comes out okay.

I figured this was the right place to post this, really bad timing, but figured I should point it out. Im new to all this... coding in general...this forum... and am having an issue when running h265.

It took forever for me to learn enough to set the program up, but I have it running now and encoding correctly on my Macbook Pro. Im running the linux build and doing test encodes for HDR.

Here is my issue, for some reason, the program will only run 50% of the time. I set it all up, hit enter, and it gives me a Segmentation Fault 11. I just keep trying to rerun it until it eventually goes through. Any ideas on why this would be? Which files would you need to debug this / how to get those if you need them. Completely understand any delay with the flooding.
You can build x265 for MacOS. This will probably work better. than a Linux build. Try the nightly build of Handbrake... https://handbrake.fr/nightly.php

[smok3]

The one with in static ffmpeg seems to work fine as well (No idea on how to switch to 10 bit thought)
http://evermeet.cx/ffmpeg/

[nima2010]

i have a little problem with x265, when i encode with x265 i cant see media info of encoded file!!

i update my k-lite codec even used different ver. of mkvmerge but still cant see media info :(
any suggestion how i can fix it?

[LigH]

Another K-Lite victim ... Nobody should need codec packs. LAV Filters handle most common formats without burdening the system with too much ballast. And furthermore, a codec pack is absolutely irrelevant for both the x265 encoder and the MediaInfo analysis; it doesn't matter if it is installed, so it doesn't matter if it is updated.

What do you mean by "cant see media info of encoded file"? Do you miss the auxiliary information about the x265 internal encoding parameters, this huge string? Well, that may depend on the MediaInfo DLL used by the player (looks like you are using an MPC variant to look at the file info). Is the player (with its MediaInfo component) up to date? And how did you encode with x265, did you use a tool which may disable the storage of this auxiliary parameter string?

[nima2010]

Another K-Lite victim ... Nobody should need codec packs. LAV Filters handle most common formats without burdening the system with too much ballast. And furthermore, a codec pack is absolutely irrelevant for both the x265 encoder and the MediaInfo analysis; it doesn't matter if it is installed, so it doesn't matter if it is updated.

What do you mean by "cant see media info of encoded file"? Do you miss the auxiliary information about the x265 internal encoding parameters, this huge string? Well, that may depend on the MediaInfo DLL used by the player (looks like you are using an MPC variant to look at the file info). Is the player (with its MediaInfo component) up to date? And how did you encode with x265, did you use a tool which may disable the storage of this auxiliary parameter string?

i use last ver of mpc hc and mpc be both cant show media info of my encode but i can others encode too!!
too odd
the fun part is before i update my x265 i could saw media info
see

[nima2010]

i use last ver of mpc hc and mpc be both cant show media info of my encode but i can others encode too!!
too odd
the fun part is before i update my x265 i could saw media info
see

this screen shot is from other encoder with x265 ,i can see their setting

[LigH]

Well, interesting. So please tell us all the details about your new x265 you can gather. It is always possible that a "regression" happened (a bug was introduced while fixing another) which makes x265 in the newest versions believe it should omit the auxiliary strings.

Please try to post an output of "x265 --ver", and the whole command line used for your encode (except the filenames).

[Selur]

as a small side note: x265 has an option to omit the SE info (--no-info)
+ may be updating mkvtoolnix might also help

[benwaggoner]

Furthermore, 2 suggestions for the --presets:

1. --ctu 32 --max-tu-size 16 for presets slower and below. Our tests suggest a ~5% speed increase and a BETTER visual quality @ the same bit-rate.
At what frame size and ABR? I anticipate you'd lose a lot of efficiency for UHD with those limitations.

2. auto-adjusted me-range for different resolutions. Probably 25 for 720p and 41 for 1080p; as from our tests. When --umh/--star/--esa are deployed, me-range affects the speed dramatically, so it make sense to seek some affordable discount, especially if combined with the 1st suggestion which affects the derivation of the current merange=57.
I'm not sure that the me-range actually scales linearly to frame size. At least in x264, it was the refinement range from the initial predicted matches from the lookahead. So Even in UHD, the 57 pixel search range could start a thousand pixels away from the block being matched to.

It might be helpful to plot the PSNR/SSIM/RF and speed impact of different me-range values at a few different frame sizes.

They probably could be smaller for very low frame sizes

[undfeatable]

You can build x265 for MacOS. This will probably work better. than a Linux build. Try the nightly build of Handbrake... https://handbrake.fr/nightly.php

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.

I'm pretty sure I have it built for MacOS, at least inside my CMake application I go CMake.app -> Contents -> MacOS -> x265 -> build -> linux
I have the processors set up properly too. Here is an example of what it does:

yuv [info]: 3840x2160 fps 24000/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: TestC1.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11


Like I said though, it looks exactly the same whether it fails or goes through.

[x265_Project]

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.
Why would it matter whether a command-line interpreter or a graphical user interface called x265? x265 doesn't care.

I run x265 from the command line very frequently, but won't hesitate to use a GUI application.

We can have our team look at this segmentation fault error if it persists. In the meantime, make sure you follow the instructions on BitBucket for compiling x265 for MacOS. https://bitbucket.org/multicoreware/x265/wiki/Home

[nima2010]

as a small side note: x265 has an option to omit the SE info (--no-info)
+ may be updating mkvtoolnix might also help

yeah , i update mkvtoolnix to ver 8.6.1 now i can see media info of my x265 encode
there is something i want to ask , how i can decrease encoding time without losing quality? i dont care file size become the as x642 or bigger, i use x264 alot and encoding speed is good but for x265 is 1 fps ,it takes too much time to encode even for 720p file i decide to change setting but didnt use x265 alot and some setting are different with x264 or i didnt care to change them but for x265 i think situation is different ,by the way i just re-encode anime ,and i'm looking for good setting for big display ,like 40 inch TV ,plz guide me
is it necessary to update x265 when ver released? i barely update x264 but dont know about x265

[LigH]

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

[smok3]

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/79532365/x265_10bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like
x265 in.y4m --crf 21 out.mp4
and it didn't seqfault.

[nima2010]

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

how i can findout tune animation added or not?
also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?

[sneaker_ger]

how i can findout tune animation added or not?
In doubt just test it and see if there is an error message or look into the documentation (http://x265.readthedocs.org). (--tune animation does not exist)

also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?
Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?p=1746714&postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

If it's still too slow do the obvious and switch to preset "slow", "medium", "fast" etc. That's the reason they exist.

[Motenai Yoda]

@vivian my bad, but it's always a sample, isn't rappresentative of the entire video
btw what pingfr want to do make me think about an absolute signal-noise difference percentile

@nima2010 it isn't
try with more reference and limit-ref 3 and limit-mode

[FranceBB]

@nima2010... basically what a codec does is removing spacial redundancy and, to do that, it uses a transform to transform "blocks of pixels" into coefficients (that's why you see blocking artifacts with low-bitrate: the transform is not applied to the whole picture because of a complexity matter; they tried with JPEG2000). Then, these coefficients are passed to the quantiser in order to get rid of high frequencies (that are not important for the human vision) and to save space.
The better transform available in terms of compression efficiency is the KLT (Karhunen–Loève transform), but its drawback is that it's an highly complexity transform, so they decided to use the DCT (Discrete Cosine transform) in x264 because it has a relatively good compression efficiency.
What x265 does, instead, is using both DCT and KLT (NOT simultaneously: it automatically switch between DCT and KLT depending on which blocks it has to encode) in order to compress images in a better way than the DCT alone, without increasing complexity too much.
That said, it's pretty normal that x265 takes more time to encode than x264 with the same settings.
Anyway, x265 is able to use multiples processors and its development is going on actively, so I strongly suggest to keep it update.
Besides, x265 is a way better than x264 in terms of compression and the initial designed target of a 50% bitrate reduction has been fulfilled.
As soon as I'll have time, I'm gonna run an encode on a xeon phi coprocessor using both x264 and x265 in order to see if x265 will be able to fully use all the cores and to demonstrate that, probably, x264 will not be able to use them.

[x265_Project]

Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?p=1746714&postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

Yes. limit-refs and limit-modes will be added to updated presets as soon as we are able to complete our testing (delayed a week due to flooding in Chennai).

[undfeatable]

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/79532365/x265_10bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like
x265 in.y4m --crf 21 out.mp4
and it didn't seqfault.

Negative, it still happens randomly
yuv [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11

I just download Handbrake, won't be able to test much for at least a week or so, but Ill let y'all know.

[benwaggoner]

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.
I can't speak to Handbreak specifically (it's more of a heartbreak for me whenever I've tried to us it for anything mildly interesting :)).

But there are a bunch of somewhat esoteric parameters that need to be set for a proper HDR-10 bitstream. Looking at a test file I did a few months ago:
--colorprim bt2020
--transfer 16
--colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0)"
--max-cll "1000,274"
--chromaloc 2
And, of course, you'll need to know what your master-display, MaxCLL, and MaxFALL values are for your content.

And you'll need to have a >=10-bit source that's already in the SMPTE 2084 PQ space, not gamma.

Also, I note you're targeting Level 5.1. AFAIK, there aren't any existing HEVC Main10 decoders that support beyond Level 5.1. Which can do 2160p60 :)!

[Ma]

Negative, it still happens randomly
yuv [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
...


If the same binary works with SSE4.2 CPU and hangs with AVX2 CPU, you can add '--asm AVX' option or '--asm SSE4.2' option and retest.

[Vesdaris]

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

[luigizaninoni]

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

[LigH]

*TILT*

With so many single options, does any "preset" still make sense, or are all contained options superseded anyway?

And could you explain for each of them why they would be better than the preset defaults?

[Vesdaris]

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

Thanx but I guess I forgot to mention one important detail. Encoding speed mustn't be that of a dying turtle lol as in 6-8fps is a min.(3770k@4.5)
PS crf17.5? Even lower than x264 to get supposedly the same quality? I'm testing these settings on a sample file and judging by the bitrate the file size will be too close(4700-4800 vs 5200+) to x264 hi10p size. So, no point, especially taking into account absolutely ridiculous encoding speed....even if I set crf higher than 17.5 encoding speed won't change.

[luigizaninoni]

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

[burfadel]

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

I totally agree about rect, amp, and merange. A while ago I mentioned to Stax to put in a variable merange into Staxrip, which was done (at a basic level). Maybe the same thing could be done with x265. That is, if the input resolution is say, 864x480 that the merange is set to say, 25, and scale that up to 57 the higher the resolution you go, or at least to a value that gives you the best quality without penalty of encode time.

At the moment if you think of it, at least the way I see it, having a fixed rate of 57 means that it is actually significantly greater at SD resolution (and effectively be 'placebo' at 57) than it is at UHDTV resolution.

I also agree with the psy-rd statement (not so sure about psy-rdoq). I have mine set at 0.5 which I think is better. Realistically though, even 0.5 may be too conservative.

With these settings:
--crf 21 --output-depth 10 --limit-refs 1 --tu-intra-depth 3 --early-skip --b-intra --aq-mode 3 --qg-size 16 --subme 3 --me star --merange 25 --max-merge 5 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --keyint 600

I am currently getting around 26-28 fps encoding material of 1280x720 to 864x480. That is actually what it is getting running in the background as I type this. This is using Staxrip with the latest 1.8+132 x265, latest ffmpeg, AVX build, using the latest l-smash-works, avisynth+, and the filters vinverse2, deveed, f3kdb, and using blackmanresize with 8 taps.

This is on a i5-3570K at 4.3 GHz, so isn't using AVX2.

I found that setting --tu-intra-depth 3 gave slightly better quality with no noticeable performance penalty. I also found adding --early-skip gave noticeably better performance without a quality or file size hit (or so fractionally slight the speed gain far outweighed any 'loss'). --max-merge 5 is probably overkill, but setting it higher than default I believe gives a small quality/and or file size improvement with only a small penalty in performance. Basically --qg-size 16 is a must, and I believe --aq-mode 3 is as well :). Adding --limit-refs 1 was certainly worth it, I did try the higher ones but the performance gains were only small compared to --limit-refs 1, I didn't see the need to use anything higher.

I found --me-star to be quite surprisingly good both quality an speed wise, at least for what I've been encoding at non-UHDTV resolutions. The setting --me-star actually kind of makes hex and umh modes redundant seeing as your get hex speeds with what appears to be umh quality.

So, with those settings I not only get better quality than the default settings, but I believe it is also faster!

[Blowis]

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

After several tests I managed to approach the x264.
To do that I use medium profile I change ctu = 16 psy-rd = 1.00 rdoq-level = 2 psy-rdoq = 1.10.