x265 HEVC Encoder

[sneaker_ger]

OK here is a good demo about x265's max-tu-size 16 bug:
Is this a regression of 2.0? It reminds me of the problems with tune grain. Wondering if they are related.

http://forum.doom9.org/showthread.php?p=1762253#post1762253

[brumsky]

@brumsky

Can you provide a problematic sample? I'd be glad to play with it.

Hey Leo 69, thanks for the offer it turns out to be faulty hardware. It started doing the same thing in everything.

[bin.n2f]

--tune film Update:

--crf 18 --ctu 32 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.9 --rd 4 --psy-rd 2.5 --psy-rdoq 4.0 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --limit-modes

Reintroduce --ctu 32 since further tests suggest the buggy term is --max-tu-size 16, while --ctu 32 is innocent.
Increase psy 2.0:3.0 to 2.5:4.0 which should further reduce blurriness, enhancing visual quality. (bit-rate should increase as well, but worthy)
Add --limit-modes in case someone enables --rect at preset medium (which I strongly DISRECOMMEND; --rect should only be used at preset slower or above)

At the same time, here we go for a --tune animation:

--crf 18 --ctu 32 --ref 4 --bframes 6 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.8 --rd 4 --psy-rd 1.8 --psy-rdoq 1.5 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --limit-modes

hi,sir
thanx :thanks: for your recommendations
what would you suggest for less than HD 720p resolution?
greetings for all doom9rs, x265 developers & Staxrip

[gamebox]

@divxmaster: Thanks for sharing your experience with pre-sharpening. :) I've browsed the complete list of AviSynth sharpening plugins/scripts, and will test some to see the results on both sharpening and resulting bitrate (whether image complexity increases as well). For now, "adaptive" sharpening seems to me as the most appropriate direction to go. I've started using Lanczos4resize which improves sharpness (though it introduces halo as well, unlike Lanczos3). Also, decreased deblock from -1 to -2, and am currently testing -3 as image quality improved after I discarded qg size 16 parameter and artifacts stopped "accumulating" in smaller image blocks containing sharp, pronounced details where they were overly visible.

I compress using modified "slower" profile - me star, subme 7, rd 6, ref 6, bframes 9, aq-mode 2/strength 2, psy rd 2, psy rdoq 1, no rskip, rect, no sao, no strong intra smoothing. Speedup options are limit modes, limit refs 3, no weightb, no amp, max merge 2.

[littlepox]

hi,sir
thanx :thanks: for your recommendations
what would you suggest for less than HD 720p resolution?
greetings for all doom9rs, x265 developers & Staxrip

No idea, never tested that case.

[youli]

Source (BD3D) info:
DISC INFO:

Disc Title: AVATAR (Ext-3D-2D)
Disc Size: 51*965*373*624 bytes
Protection: AACS
BD-Java: No
Extras: Blu-ray 3D
BDInfo: 0.5.8

PLAYLIST REPORT:

Name: 00000.MPLS
Length: 2:57:57.083 (h:m:s.ms)
Size: 51*965*054*976 bytes
Total Bitrate: 38,94 Mbps

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-4 AVC Video 21857 kbps 1080p / 23,976 fps / 16:9 / High Profile 4.1
MPEG-4 MVC Video 10966 kbps

AUDIO:

Codec Language Bitrate Description
----- -------- ------- -----------
DTS-HD Master Audio Russian 4096 kbps 5.1 / 48 kHz / 4096 kbps / 24-bit (DTS Core: 5.1 / 48 kHz / 1509 kbps / 24-bit)

SUBTITLES:

Codec Language Bitrate Description
----- -------- ------- -----------
Presentation Graphics Russian 0,847 kbps

BDRip OverUnder HEVC/H.265 mediainfo:
General
Unique ID : 253356374572038614152649260802854783875 (0xBE9AA9AFD08939C68C293ACFBDDE8B83)
Complete name : E:\temp\Avatar (2009) 1080p HEVC 3D-ab.mkv
Format : Matroska
Format version : Version 3 / Version 2
File size : 22.1 GiB
Duration : 2 h 57 min
Overall bit rate : 17.8 Mb/s
Movie name : Avatar (2009) 3D Full-T&B (x265)
Encoded date : UTC 2016-07-21 19:26:29
Writing application : mkvmerge v9.2.0 ('Photograph') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
MultiView_Count : 2
MultiView_Layout : Top-Bottom (left eye first)
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 57 min
Bit rate : 15.9 Mb/s
Width : 1 920 pixels
Height : 2 160 pixels
Display aspect ratio : 0.889
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.160
Stream size : 19.8 GiB (90%)
Title : 3D Full-T&B (x265)
Writing library : x265 2.0+2-70581d6cd065:[Windows][GCC 5.3.0][64 bit] 10bit
Encoding settings : wpp / ctu=64 / min-cu-size=16 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=2 / subme=7 / merange=25 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=24 / lookahead-slices=6 / bframes=6 / bframe-bias=0 / b-adapt=2 / ref=1 / limit-refs=0 / no-limit-modes / no-weightp / no-weightb / aq-mode=3 / qg-size=32 / aq-strength=0.60 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.90 / rdoq-level=1 / psy-rdoq=2.50 / no-rd-refine / no-signhide / no-deblock / no-sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=23.0 / qcomp=0.80 / qpmin=0 / qpmax=51 / qpstep=4 / vbv-maxrate=100000 / vbv-bufsize=100000 / crf-max=0.0 / ipratio=1.10 / pbratio=1.00
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 2 h 57 min
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 spf)
Bit depth : 24 bits
Compression mode : Lossy
Delay relative to video : 21 ms
Stream size : 1.88 GiB (8%)
Title : Russian (DTS 5.1 48KHz)
Language : Russian
Default : Yes
Forced : No
x265 encode log:
Encoding movie in 3D
Movie: Avatar (2009)
Encoding started 20.07.2016 15:45:02,70

E:\temp\Avatar (2009)\00000>"D:\Install\MKV\BD3D\BD3D2MK3D v0.92\toolset\avs2yuv
.exe" "__ENCODE_3D_MOVIE.avs" -frames 255994 -o - | "D:\Install\MKV\BD3D\B
D3D2MK3D v0.92\toolset\x265_10bit_x64.exe" --crf 23 --preset ultrafast --lev
el-idc 5 --high-tier --me umh --subme 7 --scenecut 40 --aq-mode 3 --aq-strength
0.6 --no-sao --no-deblock --rd 3 --psy-rd 0.9 --b-adapt 2 --ctu 64 --min-cu-size
16 --rc-lookahead 24 --bframes 6 --merange 25 --ipratio 1.1 --pbratio 1.0 --qco
mp 0.8 --rdoq-level 1 --psy-rdoq 2.5 --lookahead-slices 6 --sar 2:1 --range li
mited --colorprim bt709 --qpfile chapters_3D.qpfile --frames 255994 --fps 24000/
1001 --output "00000_3D.265" --y4m -
__ENCODE_3D_MOVIE.avs: 1920x2160, 24000/1001 fps, 255994 frames
y4m [info]: 1920x2160 fps 24000/1001 i420p8 sar 2:1 unknown frame count
raw [info]: output file: 00000_3D.265
x265 [info]: HEVC encoder version 2.0+2-70581d6cd065
x265 [info]: build info [Windows][GCC 5.3.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-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High 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 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 24 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.6 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=0.90 rdoq=1 psy-rdoq=2.50 early-skip rskip tmvp
x265 [info]: tools: fast-intra strong-intra-smoothing lslices=6

x265 [info]: frame I: 2774, Avg QP:21.94 kb/s: 44087.67
x265 [info]: frame P: 65676, Avg QP:22.51 kb/s: 29397.44
x265 [info]: frame B: 187544, Avg QP:23.86 kb/s: 11273.49
x265 [info]: consecutive B-frames: 10.2% 5.7% 14.1% 50.6% 9.4% 9.4% 0.7%

encoded 255994 frames in 101320.68s (2.53 fps), 16278.82 kb/s, Avg QP:23.50
Encoding finished 21.07.2016 19:53:44,00
Screenshots comparisions BD3D and BDRip:
http://s018.radikal.ru/i509/1607/e3/086643543ab5t.jpg (http://s018.radikal.ru/i509/1607/e3/086643543ab5.png)
http://s009.radikal.ru/i309/1607/ca/44ffdf6646c7t.jpg (http://s009.radikal.ru/i309/1607/ca/44ffdf6646c7.png)
http://s020.radikal.ru/i709/1607/95/95cdd8a2db32t.jpg (http://s020.radikal.ru/i709/1607/95/95cdd8a2db32.png)
http://s020.radikal.ru/i712/1607/74/2661e61ea390t.jpg (http://s020.radikal.ru/i712/1607/74/2661e61ea390.png)
http://s017.radikal.ru/i441/1607/03/1764895f471et.jpg (http://s017.radikal.ru/i441/1607/03/1764895f471e.png)
http://s014.radikal.ru/i327/1607/a2/48a4e3759bfdt.jpg (http://s014.radikal.ru/i327/1607/a2/48a4e3759bfd.png)
http://s019.radikal.ru/i643/1607/d8/412c4aa3724dt.jpg (http://s019.radikal.ru/i643/1607/d8/412c4aa3724d.png)
http://s16.radikal.ru/i190/1607/0e/048360b88d3et.jpg (http://s16.radikal.ru/i190/1607/0e/048360b88d3e.png)
http://s019.radikal.ru/i609/1607/3b/8c411059cb90t.jpg (http://s019.radikal.ru/i609/1607/3b/8c411059cb90.png)
http://s010.radikal.ru/i313/1607/a8/cbac7b64a26et.jpg (http://s010.radikal.ru/i313/1607/a8/cbac7b64a26e.png)
http://s017.radikal.ru/i443/1607/d2/26f7a67c9304t.jpg (http://s017.radikal.ru/i443/1607/d2/26f7a67c9304.png)
http://s018.radikal.ru/i510/1607/38/a248b124a853t.jpg (http://s018.radikal.ru/i510/1607/38/a248b124a853.png)
http://s016.radikal.ru/i335/1607/95/5f13e83c4aa1t.jpg (http://s016.radikal.ru/i335/1607/95/5f13e83c4aa1.png)
http://s018.radikal.ru/i519/1607/ce/48feb32099bat.jpg (http://s018.radikal.ru/i519/1607/ce/48feb32099ba.png)
http://s015.radikal.ru/i332/1607/c9/b6344e51979dt.jpg (http://s015.radikal.ru/i332/1607/c9/b6344e51979d.png)
http://s017.radikal.ru/i416/1607/d7/ad75aafc690ft.jpg (http://s017.radikal.ru/i416/1607/d7/ad75aafc690f.png)

P.S. Playable on UHD TV LG 55UF85xx-Zx

[brumsky]

--tune film Update:

--crf 18 --ctu 32 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.9 --rd 4 --psy-rd 2.5 --psy-rdoq 4.0 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --limit-modes

Reintroduce --ctu 32 since further tests suggest the buggy term is --max-tu-size 16, while --ctu 32 is innocent.
Increase psy 2.0:3.0 to 2.5:4.0 which should further reduce blurriness, enhancing visual quality. (bit-rate should increase as well, but worthy)
Add --limit-modes in case someone enables --rect at preset medium (which I strongly DISRECOMMEND; --rect should only be used at preset slower or above)

At the same time, here we go for a --tune animation:

--crf 18 --ctu 32 --ref 4 --bframes 6 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.8 --rd 4 --psy-rd 1.8 --psy-rdoq 1.5 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --limit-modes

littlepox, What are the affects of the different aq-modes on speed?

While I haven't done many encodes using aq-mode 2 or 3 - it seems to be 25-35% slower.

thanks,

[Magik Mark]

Im looking for a software that would display what encoding parameters were used. Can someone recommend one? Sometimes mediainfo doesn't show what parameters were used. Or this was intentionally deleted by the encoder?

[birdie]

Im looking for a software that would display what encoding parameters were used. Can someone recommend one? Sometimes mediainfo doesn't show what parameters were used. Or this was intentionally deleted by the encoder?

Any hex editor will do.

[littlepox]

littlepox, What are the affects of the different aq-modes on speed?

While I haven't done many encodes using aq-mode 2 or 3 - it seems to be 25-35% slower.

thanks,

It should not be that large, during the test we did not even notice anything about their speed.

Furthermore, it is important to point out that larger bitrate itself means slower encode, when you have more bits for CABAC entropy encoding.

[LigH]

^ littlepox: And decoding higher bitrates can be slower too (compared with otherwise similar complexity).
_

@ Magic Mark: Not all encoders of the same target format may support storing encoding parameters as auxiliary data; there are more HEVC encoders than just x265. Also you can disable x265 writing them into the video stream (--no-info).

Some parameters could be analyzed from headers or GOP attributes. But others would be hard to discover from the video stream only.

[aymanalz]

No. It's 'my' compiles made through media-autobuild suite.

Sent from my Samsung Galaxy S7 edge via Tapatalk

I think there is some error in your compile, for the last binary you uploaded (2.0 - 8). Using it, I kept getting an error towards the end of the 2nd pass. (Error writing trailer of pipe.) Googling it suggests that it somehow relates to ffmpeg. But I don't get that error with the binary from x265.eu. (I've only tried 2.0 - 5.) Same settings and same media file, of course.

[aymanalz]

I notice that I am getting vastly improved encoding speeds with version 2.0, than I was with 1.9. Is this true for everybody?

[Barough]

I think there is some error in your compile, for the last binary you uploaded (2.0 - 8). Using it, I kept getting an error towards the end of the 2nd pass. (Error writing trailer of pipe.) Googling it suggests that it somehow relates to ffmpeg. But I don't get that error with the binary from x265.eu. (I've only tried 2.0 - 5.) Same settings and same media file, of course.

Haven't got any errors myself with it. Works fine with CRF though. Will check if there is an updated version of the media-autobuild suite available.

[Barough]

x265-v2.0++9-2737c6ff5f80 (http://www33.zippyshare.com/v/8vm5LbrT/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Ma]

x265-v2.0++9-2737c6ff5f80 (http://www33.zippyshare.com/v/8vm5LbrT/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

The 32-bit version hangs. It was reported some time ago https://bitbucket.org/multicoreware/x265/issues/270/32bit-gcc-61-builds-of-x265-hangs-at

Solution for 32-bit GCC 6.1:
export CXXFLAGS="-march=pentium4 -mtune=generic"
*** build 32-bit x265 ***
export CXXFLAGS=

[Barough]

Thnx for the info Ma, but it looks like that issue was set to 'Resolved' a couple of days after it was reported.

EDIT
Ahh..... It's a GCC 'issue'. Don't have a clue on how 2 fix that in the media-autobuild_suite.

[easyfab]

@Barough

see last message here : https://github.com/jb-alvarado/media-autobuild_suite/issues/358

It give you an example how to do this

[Barough]

@ easyfab

Thnx for the info/reply.

I had a look @ it but i've never done any modifying like that. I have basically no knowledge when it comes to that kinda stuff. That's why i went for the media-autobuild_suite.

[Ma]

I've attached workaround for 32-bit GCC (it sets "-march=pentium4 -mtune=generic" as default for 32-bit GCC).

To apply this patch in x265 folder you can:
save attached '32bit.txt' to x265 source file folder on your HDD;
from x265 folder you can execute:
patch -p1 <32bit.txt
exclusive or (if you don't have patch command):
hg import --no-commit 32bit.txt

To clean x265 source code (from this patch for example) you can execute:
hg update -C

[divxmaster]

@divxmaster: Thanks for sharing your experience with pre-sharpening. :) I've browsed the complete list of AviSynth sharpening plugins/scripts, and will test some to see the results on both sharpening and resulting bitrate (whether image complexity increases as well). For now, "adaptive" sharpening seems to me as the most appropriate direction to go. I've started using Lanczos4resize which improves sharpness (though it introduces halo as well, unlike Lanczos3). Also, decreased deblock from -1 to -2, and am currently testing -3 as image quality improved after I discarded qg size 16 parameter and artifacts stopped "accumulating" in smaller image blocks containing sharp, pronounced details where they were overly visible.

I compress using modified "slower" profile - me star, subme 7, rd 6, ref 6, bframes 9, aq-mode 2/strength 2, psy rd 2, psy rdoq 1, no rskip, rect, no sao, no strong intra smoothing. Speedup options are limit modes, limit refs 3, no weightb, no amp, max merge 2.

@gamebox, have you tried using vapoursynth64 instead of avisynth? its much faster. sharpening options seem limited though. Best seems to be awarpsharp2, but this is the only dll I cannot get to work at all in vapoursynth. off to the forums I suppose. back on topic, I see you use bframes 9, I seem to remember reading anything over 5 is pointless. this may have changed.

[LigH]

The 32-bit version hangs. It was reported some time ago https://bitbucket.org/multicoreware/x265/issues/270/32bit-gcc-61-builds-of-x265-hangs-at

Solution for 32-bit GCC 6.1:

Is this an issue for GCC 5.3 too?

x265 2.0+9-2737c6ff5f80 (https://www.mediafire.com/download/t4u12ppclpesbjd/x265_2.0+9-2737c6ff5f80.7z) was built with an older MSYS/MinGW package by XhmikosR.

[Ma]

Is this an issue for GCC 5.3 too?

x265 2.0+9-2737c6ff5f80 (https://www.mediafire.com/download/t4u12ppclpesbjd/x265_2.0+9-2737c6ff5f80.7z) was built with an older MSYS/MinGW package by XhmikosR.

GCC 5.3 works OK. The problem is with stack alignment. In Windows and ancient CPU the stack alignment was 4 which is too small for SSE2 functions. GCC needs to analyze code and realign the stack in functions that calls SSE2 functions -- GCC 6.1 works wrong in this area.

If I add option '-mincoming-stack-boundary=2' to encoder/slicetype.cpp in 32-bit GCC 6.1, it works without '-march' option. I need some time to detailed analyze...

By the way, if you add line in your build script:
export CXXFLAGS="-march=pentium4 -mtune=generic"
before part that build 32-bit x265, it will be much faster version of 32-bit x265.

[gamebox]

@divxmaster: Using more than 6 B-frames indeed gives little benefit, in my experience only about 2-3% of B-frame "rows" contain 7 frames, for example. But, I also haven't noticed any significant speedup reducing B-frame count to 6, and that's the reason I kept it at 9 - for medium/low bitrate encoding any improvement counts.

I've tested many sharpening filters yesterday and discarded Adaptive Sharpen, as it smooths out less pronounced details slightly. The best combination I've come up is Sharpen (AviSynth built-in filter) at value 0.2, followed by Msharpen at threshold 10 and strength 20. For the time being, performance of AviSynth is not an issue as my new octo-core AMD FX CPU "Bulldozes" through data quite nicely.

[katzenjoghurt]

Hey,

somebody got a hint for me how to reduce the seek time in VLC?
I'm using Staxrip, x265 Main10 with OpenGOP deactivated. (No other settings)

[Selur]

tried vlc nightly? tried mkv as container?

[katzenjoghurt]

tried vlc nightly? tried mkv as container?

Hey Selur,

I didn't try the VLC Nightly yet. Though neither MKV, MP4 nor using Handbrake instead of Staxrip seemed to make a real difference.
The only thing that helped was deactivating OpenGOP... But I still got seek times of roundabout 5sec with a 1080p video on my Xeon 1241v3.

[microchip8]

Hey Selur,

I didn't try the VLC Nightly yet. Though neither MKV, MP4 nor using Handbrake instead of Staxrip seemed to make a real difference.
The only thing that helped was deactivating OpenGOP... But I still got seek times of roundabout 5sec with a 1080p video on my Xeon 1241v3.

Have you tried lowering the keyframe value during encoding?

[Selur]

The only thing that helped was deactivating OpenGOP...
I thought you already had it deactivated, since you wrote:
I'm using Staxrip, x265 Main10 with OpenGOP deactivated. (No other settings)
-> try the nightly, it should work with opengop deactivated.

[sneaker_ger]

-> try the nightly, it should work with opengop deactivated.
and activated. It always worked with deactivated.

Make sure StaxRip isn't outdated, older mp4box had some nasty bugs.

[littlepox]

--keyint 150

This shall help you with the seek time

ps, try MPC-HC 64bit. Currently LAV 64bit is the most efficient decoder.

[katzenjoghurt]

Ahh... thx guys.

The VLC Nightly helped... as did the --keyint 150 parameter.


I thought you already had it deactivated, since you wrote:
I had it activated... I was just still not happy with the result.

[filler56789]

To whom this may interest:

I've decided to share my new (MSYS2-based) MinGW_w64 toolchain.
The directory includes CMake, Git and Mercurial.

https://www.mediafire.com/?3ib29yauv5kdw

NOTICE:

when calling the .SH scripts, you (may) need to add a ./ to the command-line —

for example, "./multi64.sh" instead of simply "multi64.sh".

[jlpsvk]

the GCC 6.1.0 x64 build of 2.0+9 seems to be much faster than GCC 5.3.0 x64.

[LigH]

Hard to believe if >90% of the relevant code is in assembler, optimized for several different levels of supported instruction set extensions. Without details and numbers, "much faster" won't mean anything.

[jlpsvk]

Command:
--crf 20 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier

GCC 5.3.0 - 9.82fps average
GCC 6.1.0 - 12.28fps average

Movie - Batman v Superman.

The rest is the same: StaxRip, DirectShowSource, LAV filters CPU decoding, Core i7-4790K CPU, 8GB RAM, Windows 7 x64.

OK... taking back..... Now realised,that I haven't turned on --me star, like with GCC 5.3.0. :( Running new test. :)

[LigH]

:eek: Wow... and which CPU, which instruction sets reportedly used?

[jlpsvk]

LigH, as i wrote...running new test with --me star, as wih GCC 5.3.0... :) So will report new speed then.

x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

PS: What is the benefit os ME STAR over default ME in MEDIUM?

[LigH]

The search for motion vectors in different ME modes is more or less exhaustive; "star" will probably prefer vertical and horizontal directions, but won't search as far in diagonal directions, I believe. I never saw descriptive diagrams yet, though... But fewer directions means faster speed, obviously.

[LigH]

XhmikosR recently released an MSYS / MinGW / GCC 6.1.0 package (2016-07-08); so I built x265 binaries for you to cross-compare compilers and linking types of mostly the same generic options, just including the pentium4/generic flag pair Ma suggested for Win32 builds (at least I hope I did it right, please check).

x265 2.0+10-5a0e139e2938 (GCC 5.3.0) (https://www.mediafire.com/download/bwv0iiyye5qz0y1/x265_2.0+10-5a0e139e2938.GCC530.7z)
x265 2.0+10-5a0e139e2938 (GCC 6.1.0) (https://www.mediafire.com/download/srytnqt61y7l76u/x265_2.0+10-5a0e139e2938.GCC610.7z)

[Ma]

XhmikosR recently released an MSYS / MinGW / GCC 6.1.0 package (2016-07-08); so I built x265 binaries for you to cross-compare compilers and linking types of mostly the same generic options, just including the pentium4/generic flag pair Ma suggested for Win32 builds (at least I hope I did it right, please check).

Everything works OK.
Speed comparison of 32-bit builds on i5 3450S (AVX), input file file 1920x800, no special options:

bits | GCC 5.3 | GCC 6.1
8bit | 95.37s (7.86 fps)| 83.15s (9.02 fps)
10bit | 435.44s (1.72 fps)| 328.79s (2.28 fps)
12bit | 436.29s (1.72 fps)| 328.16s (2.29 fps)

GCC 5.3 builds with option "-march=pentium4 -mtune=generic" should be also faster (and at 10/12 bit faster than GCC 6.1).

[jlpsvk]

The search for motion vectors in different ME modes is more or less exhaustive; "star" will probably prefer vertical and horizontal directions, but won't search as far in diagonal directions, I believe. I never saw descriptive diagrams yet, though... But fewer directions means faster speed, obviously.

In terms of visual quality, should they be the same? It's only compressibility thing? I think so.

What are you thinking about some using LimitedSharpenFaster or LSFmod to slightly sharpen the image....

And...what's better/faster in x265? me UMH or STAR?

[LigH]

@ Ma:

I think I used your additional options for the GCC 5.3.0 build as well. That was on another PC... Maybe compare with v2.0+9 which certainly did not have these options set; the changes to v2.0+10 should be small or not relevant in this case, IIRC.
_

@ jlpsvk:

When motion search does not find a good enough match to inter-code a block, it has to be intra-coded, which requires more space and reduces the efficiency. Therefore, a more exhaustive search may improve the efficiency of an encode. Depending on the material. If there are almost only short or perpendicular motions, star would be efficient enough. Could you know beforehand?

Artifical sharpening usually worsens the compressibility. It requires spending more bits for high frequency parameters to be encoded without noticeable artifacts.

[jlpsvk]

@ Ma:

I think I used your additional options for the GCC 5.3.0 build as well. That was on another PC... Maybe compare with v2.0+9 which certainly did not have these options set; the changes to v2.0+10 should be small or not relevant in this case, IIRC.
_

@ jlpsvk:

When motion search does not find a good enough match to inter-code a block, it has to be intra-coded, which requires more space and reduces the efficiency. Therefore, a more exhaustive search may improve the efficiency of an encode. Depending on the material. If there are almost only short or perpendicular motions, star would be efficient enough. Could you know beforehand?

Artifical sharpening usually worsens the compressibility. It requires spending more bits for high frequency parameters to be encoded without noticeable artifacts.

Encoding mainly blurays. Starting converting all my BD's to HEVC (as I have VU+ Solo 4K DVB-S2 receiver, which plays 10bit HEVC also, so I will spare lot of space on my RAID). Right now my selected settings:
--crf 19 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --me umh --rc-lookahead 60 --ref 4 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier

Looking for balance speed/quality/size.

[microchip8]

Encoding mainly blurays. Starting converting all my BD's to HEVC (as I have VU+ Solo 4K DVB-S2 receiver, which plays 10bit HEVC also, so I will spare lot of space on my RAID). Right now my selected settings:
--crf 19 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --me umh --rc-lookahead 60 --ref 4 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier

Looking for balance speed/quality/size.

I would disable --sao if I was you. seems to blur too much. it will also speed things a little bit up. Also, bump up psy-rdoq if you have (lots of) noise and want to preserve it. I use a value of 6.0 and psy-rd of 3.5

[jlpsvk]

I will disable --sao if I was you. seems to blur too much

--no-sao ???

[LigH]

By "material", I rather mean rather little or much action, rather random or regular motion, short or far range. The fact that they are stored on Blu-ray is less relevant...

If you focus on Hollywood blockbusters, you will probably have to expect much random and rather far motion, therefore a more exhaustive search may be more efficient for the quality/size ratio, but cost some speed. In case of nature documentaries, there are different attributes...

[microchip8]

--no-sao ???

yes, and you can also do a --no-amp, will up the performance a bit with no visual degradation. But keep --rect

[Boulder]

Is the scenechange detection essentially the same as in x264? I just encoded the exact same video with both and x264 produced 1411 I-frames while the x265 encode has 1611 I-frames. The length of the source (Zootropolis) is 156147 frames.

[brumsky]

What is everyone's opinion of x265? Is it worth the longer encoding time compared to x264?

[aymanalz]

By "material", I rather mean rather little or much action, rather random or regular motion, short or far range. The fact that they are stored on Blu-ray is less relevant...

If you focus on Hollywood blockbusters, you will probably have to expect much random and rather far motion, therefore a more exhaustive search may be more efficient for the quality/size ratio, but cost some speed. In case of nature documentaries, there are different attributes...

Which is the more exhaustive search, umh or star?

[Rogatti]

What is everyone's opinion of x265? Is it worth the longer encoding time compared to x264?

X265 (anime 1.2GB)
-
http://i1292.photobucket.com/albums/b570/Bispo_Guerra/x265_zpsltqiur3d.png
-
-
X264 (anime 4.7GB)
-
http://i1292.photobucket.com/albums/b570/Bispo_Guerra/x264_zpsgclhgsvt.png

[Khun_Doug]

You surely asked a good question aymanalz, and one that I have pondered abundantly lately. For the time being I have decided to stay with x264 until the speed of x265 gets some serious attention. The price of disk is cheap. I added 5TB USB for just over $100. With x264 I usually encode at CRF 20, but sometimes as low as CRF 15. For my HD media I usually go 2 pass with nothing short of 10,000 kbit. I did some test encodes with x265 and calculated the encode time for a full movie would be in excess of 48 hours of solid machine time. The same film encodes in under 5 hours in x264. I don't care that the encoded film is 8 GB in x264 and may be les sin x265. I don't have 48 hours or more of dedicated machine time to use for single encodes.

I can revisit using x265 seriously for my video library once the speed issue is resolved. In the meantime, I am enjoying testing and evaluating it. I feel there is great promise and progress forthcoming.

[LigH]

Which is the more exhaustive search, umh or star?

Hmm, now that I read the docs (http://x265.readthedocs.io/en/default/cli.html#cmdoption--me) again ... I believe we need explanations (and even diagrams!) from a person with more insight.

The description of "star" mode sounds as if it is quite adaptive and can be fast if it finds a good match already in the first star pattern search, but will take more time if the other two steps are required in case of a bad match. Speculations. :o

[aymanalz]

You surely asked a good question aymanalz, and one that I have pondered abundantly lately. For the time being I have decided to stay with x264 until the speed of x265 gets some serious attention. The price of disk is cheap. I added 5TB USB for just over $100. With x264 I usually encode at CRF 20, but sometimes as low as CRF 15. For my HD media I usually go 2 pass with nothing short of 10,000 kbit. I did some test encodes with x265 and calculated the encode time for a full movie would be in excess of 48 hours of solid machine time. The same film encodes in under 5 hours in x264. I don't care that the encoded film is 8 GB in x264 and may be les sin x265. I don't have 48 hours or more of dedicated machine time to use for single encodes.

I can revisit using x265 seriously for my video library once the speed issue is resolved. In the meantime, I am enjoying testing and evaluating it. I feel there is great promise and progress forthcoming.

I said the same thing, when x265 was at version 1.7. My computer at the time was getting about 1.5 FPS! The developers then stated (on this thread, I believe) that they had speed improvements planned for the future, but that they had other priorities to address first. Version 1.8 brought quite a bit of speed improvement, and in my experience, version 2.0 has also made it faster. (Not sure if everybody else has experienced speed improvement with 2.0)

But you are right, they do need to further speed it up, if it is possible to do so. And I really hope it is possible, because as you state, x265 shows tremendous promise over previous codecs. I see that with every encode I make - the quality of output is far better than x264, at similar bitrates. But the encoding speed is still drearily slow for those of us who don't have professional level hardware. Which is why I'm also holding back on re-encoding a ton of HD home videos for now.

[aymanalz]

Hmm, now that I read the docs (http://x265.readthedocs.io/en/default/cli.html#cmdoption--me) again ... I believe we need explanations (and even diagrams!) from a person with more insight.

The description of "star" mode sounds as if it is quite adaptive and can be fast if it finds a good match already in the first star pattern search, but will take more time if the other two steps are required in case of a bad match. Speculations. :o

The manual states:

Generally, the higher the number the harder the ME method will try to find an optimal match.

That line suggests that star is more exhaustive, since the "number" is 3 for star and 2 for umh. But it is far from clear, and several posts here gave me the opposite impression.

I hope this gets clarified soon. Isn't it one of the more important determiners of quality?

[LigH]

It has an impact to the quality/size ratio, but it is not necessarily responsible for better quality in general. If you don't care much about the size, remember: if motion search doesn't find a good enough match for inter coding (motion vector + difference), intra coding (independent newly coded content) is used, which just requires more space, but if the output size is not restricted directly, quality can still be convenient.

Quality gets only worse if you have a limited average or maximum bitrate, which could only be achieved by coarser quantization if too many intra blocks take too much of the overall bitrate. Fortunate motion search matches could have spared bitrate, and finding them requires a more or less thorough search for them.

[shinchiro]

Since it has been 3 years x265 under development, is there any news about gpu acceleration? :)

[LigH]

I doubt x265 development will ever consider GPU support. The complexity of HEVC encoding can easily surpass the limits of most available GPU architecture.

[nakTT]

XhmikosR recently released an MSYS / MinGW / GCC 6.1.0 package (2016-07-08); so I built x265 binaries for you to cross-compare compilers and linking types of mostly the same generic options, just including the pentium4/generic flag pair Ma suggested for Win32 builds (at least I hope I did it right, please check).

x265 2.0+10-5a0e139e2938 (GCC 5.3.0) (https://www.mediafire.com/download/bwv0iiyye5qz0y1/x265_2.0+10-5a0e139e2938.GCC530.7z)
x265 2.0+10-5a0e139e2938 (GCC 6.1.0) (https://www.mediafire.com/download/srytnqt61y7l76u/x265_2.0+10-5a0e139e2938.GCC610.7z)
Thanks. It works fine.

I'm using the 64bit version of the GCC 6.1.0 build.

Based on my limited testing, it seems that the 8bit version is close to 75% faster than the 12bit version. Both using Very Slow preset.

Thanks for the executables and hope you would release a new executibles as the encoder get updated.:thanks:

[LigH]

I will. Once in a while. Especially when important updates were published.

[brumsky]

X265 (anime 1.2GB)
-
http://i1292.photobucket.com/albums/b570/Bispo_Guerra/x265_zpsltqiur3d.png
-
-
X264 (anime 4.7GB)
-
http://i1292.photobucket.com/albums/b570/Bispo_Guerra/x264_zpsgclhgsvt.png


Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.

[brumsky]

You surely asked a good question aymanalz, and one that I have pondered abundantly lately. For the time being I have decided to stay with x264 until the speed of x265 gets some serious attention. The price of disk is cheap. I added 5TB USB for just over $100. With x264 I usually encode at CRF 20, but sometimes as low as CRF 15. For my HD media I usually go 2 pass with nothing short of 10,000 kbit. I did some test encodes with x265 and calculated the encode time for a full movie would be in excess of 48 hours of solid machine time. The same film encodes in under 5 hours in x264. I don't care that the encoded film is 8 GB in x264 and may be les sin x265. I don't have 48 hours or more of dedicated machine time to use for single encodes.

I can revisit using x265 seriously for my video library once the speed issue is resolved. In the meantime, I am enjoying testing and evaluating it. I feel there is great promise and progress forthcoming.

Disk space is pretty cheap. However, I do like the lower bitrate for streaming media.

[gamebox]

While changing some random setting in Media Player Classic I noticed something awkward. My Output filter is set to "Enhanced Video Renderer", and below that is a setting for "resizer" where "Bilinear" was selected by default. After I changed it to one of "Bicubic" settings offered, image sharpness in full-screen mode improved dramatically (I use a Full-HD display and mostly play content encoded below that resolution)!

Could that be the stupid cause for "unexplainable" image softness most people notice with HEVC? When playing H.264 many systems (mine included) use built-in GPU decoders through DXVA, where software resize options might not have influence at all.

Which software do you use for playing HEVC videos?

[Barough]

I mainly use MPC-BE with default settings. Haven't bothered with tweaking the settings since im pleased with how it looks.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[brumsky]

I have dual E5-2670 v1 which only have AVX. Anyone here with an equivalent setup with AVX2? What speeds are you averaging given your settings of course.

I use a slightly modified version of littlepox's settings. I'm trying to keep the bitrate down a bit for archival. I average 4.5 - 5.5 FPS with these settings.

--profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 1 --merange 25 --subme 3 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip --b-intra
--no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.8 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2.0 --psy-rdoq 2.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65
--no-strong-intra-smoothing --deblock -1:-1 --qg-size 32

I'm curious what a E5-2640 v3 might get on average compared to my setup. They are the same speed 2.6ghz...

[aymanalz]

It has an impact to the quality/size ratio, but it is not necessarily responsible for better quality in general. If you don't care much about the size, remember: if motion search doesn't find a good enough match for inter coding (motion vector + difference), intra coding (independent newly coded content) is used, which just requires more space, but if the output size is not restricted directly, quality can still be convenient.

Quality gets only worse if you have a limited average or maximum bitrate, which could only be achieved by coarser quantization if too many intra blocks take too much of the overall bitrate. Fortunate motion search matches could have spared bitrate, and finding them requires a more or less thorough search for them.

Right, when I said "quality", I meant quality at a certain bitrate. I should have specified that. When doing 2-pass encodes at a certain average bitrate, isn't the choice of motion estimation method be one of the more important determiners? If I need to encode at a certain bitrate, what other setting would have significant impact on the quality/size ratio? How important in ME method, and what other factors are important?

(For me, it's mostly high definition movies and HD home videos, all in x264, which I want to re-encode at about 30% of original bitrate.)

[divxmaster]

30% of the original bitrate? You wont get that, but you may get 30% reduction in bitrate. That is what I am seeing. I am currently reencoding ds9, and the latest x265 is excellent, but only with no-sao. Bitrate is about 60% of x264, and the quality is better. Admittedly some of that is that I now have run smdegrain over it.

Ok, now time for something weird. The ultimate x265 low bitrate test. As per previous posts, I have encoded sg1, 480p, low bitrate for mobile devices. I took a 1.36MB chunk of an episode, 1min 7 seconds, and copied it on to a FLOPPY DISK. And guess what, it played it no problem! buffered for 16 seconds and then played the remaining 51 seconds fine. In fact it finished reading the disk after it had played 30 seconds, so the floppy disk transfer rate was too fast! So a great testament to how good x265 is at low bitrates. What about bluray from floppy disk? lets see now...

[aymanalz]

30% of the original bitrate? You wont get that, but you may get 30% reduction in bitrate. That is what I am seeing. I am currently reencoding ds9, and the latest x265 is excellent, but only with no-sao. Bitrate is about 60% of x264, and the quality is better. Admittedly some of that is that I now have run smdegrain over it.



As I said, I'm using 2-pass encode, so I can choose the bitrate. I don't mind a slight degradation in quality, which is why I'm encoding at 30%-50% of original bitrate. But I'd like to know how I can get maximum possible quality, for the target bitrate I choose.

About SAO that you mention, that's an aspect I'd like to know as well. Are others too experiencing noticeable loss of quality due to SAO? The developers have stated that SAO was improved in 2.0.

[divxmaster]

Yes, the testing of the 'new' SAO in 2.0 is one thing I have to get around to doing. But as far as fixed bitrate goes, for me I wouldn't do that. The bitrate required is way to variable. In crf mode, I have some 576p that uses a bitrate of 450-500, but other 576p uses a bitrate of 1000-1200! And the 450-500 looks better in this instance.

[burfadel]

Output bitrate depends on the quality of the source. A poor quality source means you also encode the poor quality elements. A lot of these are random so increases encode complexity.

[MeteorRain]

Yuuki Asuna Mod
x265-Yuuki-2.0M+9-g457336f+14.7z (https://down.7086.in/x265-Yuuki-Asuna/x265-Yuuki-2.0M%2B9-g457336f%2B14.7z)
x265-Asuna-2.0+2-ge16e208+14.7z (https://down.7086.in/x265-Yuuki-Asuna/x265-Asuna-2.0%2B2-ge16e208%2B14.7z)

[dipje]

Since it has been 3 years x265 under development, is there any news about gpu acceleration? :)

I thought they had that pretty much from the start, but in the commercial license stuff, not the opensource x265 stuff.

Does x264 have decent gpu acceleration after all those years?? :). OpenCL lookaheads came eventually - very late - and contribute not much.. I don't expect much to change for x265.

Pretty much accelerated hevc encoding already exist on the recent GPUs and there are commandline tools to use it, but you have to do with the quality it provides, not much to improve upon.

[JohnLai]

I thought they had that pretty much from the start, but in the commercial license stuff, not the opensource x265 stuff.

Does x264 have decent gpu acceleration after all those years?? :). OpenCL lookaheads came eventually - very late - and contribute not much.. I don't expect much to change for x265.

Pretty much accelerated hevc encoding already exist on the recent GPUs and there are commandline tools to use it, but you have to do with the quality it provides, not much to improve upon.

Perhaps they could offload motion estimation section, after all, both Intel and Nvidia (no AMD) support external motion estimation mode only. Then again........it probably will be rejected in the name of 'open source' where there is no room for proprietary code or maybe there isn't any speed gain from it....or nobody is willing to work on it....pick one ~.~

[aegisofrime]

Perhaps they could offload motion estimation section, after all, both Intel and Nvidia (no AMD) support external motion estimation mode only. Then again........it probably will be rejected in the name of 'open source' where there is no room for proprietary code or maybe there isn't any speed gain from it....or nobody is willing to work on it....pick one ~.~

So is there no possible way to offload some of the processing to the fixed function units on Intel and AMD chips?

Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.

I used to be on the same boat as you. But one thing that you have to understand is that the presets of x264 and x265 are not comparable. For me, x265's medium is roughly comparable in quality and speed as x264's slow, but with smaller file size of course.

[JohnLai]

So is there no possible way to offload some of the processing to the fixed function units on Intel and AMD chips?


It is possible, an excerpt from NVENC documentation :

NVENC can be used as a hardware accelerator to perform motion search and generate motion vectors and mode information only. The resulting motion vectors or mode decisions can used, for example, in motion compensated filtering or for supporting other codecs not fully supported by NVENC or simply as motion vector hints for a custom encoder.

Sample code from nvenc :

/**
* Motion vector structure per CU for HEVC motion estimation.
*/
typedef struct _NV_ENC_HEVC_MV_DATA
{
NV_ENC_MVECTOR mv[4]; /**< up to 4 vectors within a CU */
uint8_t cuType; /**< 0 (I), 1(P), 2 (Skip) */
uint8_t cuSize; /**< 0: 8x8, 1: 16x16, 2: 32x32, 3: 64x64 */
uint8_t partitionMode; /**< The CU partition mode
0 (2Nx2N), 1 (2NxN), 2(Nx2N), 3 (NxN),
4 (2NxnU), 5 (2NxnD), 6(nLx2N), 7 (nRx2N) */
uint8_t lastCUInCTB; /**< Marker to separate CUs in the current CTB from CUs in the next CTB */
} NV_ENC_HEVC_MV_DATA;

/**
* Creation parameters for output motion vector buffer for ME only mode.
*/
typedef struct _NV_ENC_CREATE_MV_BUFFER
{
uint32_t version; /**< [in]: Struct version. Must be set to NV_ENC_CREATE_MV_BUFFER_VER */
NV_ENC_OUTPUT_PTR mvBuffer; /**< [out]: Pointer to the output motion vector buffer */
uint32_t reserved1[255]; /**< [in]: Reserved and should be set to 0 */
void* reserved2[63]; /**< [in]: Reserved and should be set to NULL */
} NV_ENC_CREATE_MV_BUFFER;

/** NV_ENC_CREATE_MV_BUFFER struct version*/
#define NV_ENC_CREATE_MV_BUFFER_VER NVENCAPI_STRUCT_VERSION(1)


Of course, there are lotta lines of code before ME step, such as buffer creation + reference frame + buffer locking + buffer pointer location and finally the last step buffer destruction + release.

Questions are.....how to port the code for x265 or can it be done in first place? Who will do it for free? Is there any licensing issue?

[burfadel]

I have dual E5-2670 v1 which only have AVX. Anyone here with an equivalent setup with AVX2? What speeds are you averaging given your settings of course.

I use a slightly modified version of littlepox's settings. I'm trying to keep the bitrate down a bit for archival. I average 4.5 - 5.5 FPS with these settings.

--profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 1 --merange 25 --subme 3 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip --b-intra
--no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.8 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2.0 --psy-rdoq 2.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65
--no-strong-intra-smoothing --deblock -1:-1 --qg-size 32

I'm curious what a E5-2640 v3 might get on average compared to my setup. They are the same speed 2.6ghz...

Those settings are all over the place. try the following:
--output-depth 10 --rd 4 --tu-intra-depth 3 --rdoq-level 2 --early-skip --fast-intra --b-intra --tskip --tskip-fast --limit-modes --aq-mode 2 --qg-size 16 --me star --merange 25 --max-merge 3 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --psy-rdoq 1.38

The merange of 25 is good performance, but it depends on what resolution you are encoding. I have found that the ideal number is the vertical resolution you are encoding to, divided by 1080, multiplied by 57.

So:
480
---- x 57
1080

Equals 25.33, which is why 25 seems to be optimal for 480P If you are doing 720P, likewise:

480
---- x 57
1080

Equals 38. Now in effect, the 25 and 38 takes you to the equivalent point in the picture, since there are more pixels between the two points at 720P than 480P. For b-frames, I found around 6 is ideal for normal content, but maybe 8 for animation. Setting this too high just leads to more encode time with little efficiency benefit. In the stats at the end of the encode, you can see the percentages for the consecutive b-frames. The first number is 0, so if there are 7 numbers the seventh one relates to 6 consecutive b-frames. You will see the percentages can be quite low at the top end, any less than a few percent it wouldn't be worth the extra encode time. Instead of a B frame in that instance, a P frame would be used instead.

For example, for a few recent recent encodes (x265 2.0+11) I got:
x265 [info]: consecutive B-frames: 8.6% 3.0% 6.1% 37.1% 15.3% 23.4% 6.5%
x265 [info]: consecutive B-frames: 6.3% 1.8% 4.5% 35.4% 22.3% 21.4% 8.4%
x265 [info]: consecutive B-frames: 9.7% 5.2% 10.1% 33.7% 13.2% 21.0% 7.1%

The 6.5%, 8.4%, and 7.1% relate to the 6th b-frame. I found no matter what the source, if I selected 7 or higher for testing the 7th and so on frame percentage was very low. That is why I settled on 6 b-frames as optimal.

The other options are a balance of speed and quality. Also note I set --tu-intra-depth 3 as this shows benefits for little peformance cost, however I did not option --tu-inter-depth 3, as it didn't show any noticeable quality or compression improvements, and just slowed down the encode.
The settings -early-skip --fast-intra --tskip --tskip-fast --limit-modes are all performance related, they noticeably improve speed when all used together but really don't impact the quality of the output. Give the settings I listed a go exactly as written apart from the --merange calculation (no other changes) and see how the speed compares to quality.

EDIT:
Forgot to mention, the above is solely the options on the command line. That is, not using any other preset as a basis. The crf (not stated) should be set to the desired amount. I would suggest maybe something a little lower than the default but within what would give you a desirable end file size. You can use decimals, so you could set it to 21.2 if you wanted (for example).

[JohnLai]

Quick question, why does x265 preset doesn't make use of b-adapt 1(fast)?
All presets either use 0(none) or 2(full). Is there anything wrong with 1(fast)?

[Rogatti]

Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.

"speed" certainly x264.
-
benefit cost (quality + size) = x265 .

[divxmaster]

As I said, I'm using 2-pass encode, so I can choose the bitrate. I don't mind a slight degradation in quality, which is why I'm encoding at 30%-50% of original bitrate. But I'd like to know how I can get maximum possible quality, for the target bitrate I choose.

About SAO that you mention, that's an aspect I'd like to know as well. Are others too experiencing noticeable loss of quality due to SAO? The developers have stated that SAO was improved in 2.0.

got around to testing sao in 2.0. same problem, still blurs way too much. and the no-sao test was *smaller* than the sao one! 1000 frames.

[burfadel]

got around to testing sao in 2.0. same problem, still blurs way too much. and the no-sao test was *smaller* than the sao one! 1000 frames.

I don't find it blurred with the settings I use...

[divxmaster]

I don't find it blurred with the settings I use...

Hmmm, odd, by mostly coincidence, my settings are virtually the same as yours, except I use rdoq 1.1, and qg-size 32. I presume you are using staxrip video comparison to compare? It may be due to input source quality, I am currently testing sg1, ntsc.

[Leo 69]

I'm seeing a significant bitrate reduction when encoding in 12-bit mode compared to 10-bit (around 20% less). The source is 8-bit.
Why?

[brumsky]

Those settings are all over the place. try the following:


The merange of 25 is good performance, but it depends on what resolution you are encoding. I have found that the ideal number is the vertical resolution you are encoding to, divided by 1080, multiplied by 57.

So:
480
---- x 57
1080

Equals 25.33, which is why 25 seems to be optimal for 480P If you are doing 720P, likewise:

480
---- x 57
1080

Equals 38. Now in effect, the 25 and 38 takes you to the equivalent point in the picture, since there are more pixels between the two points at 720P than 480P. For b-frames, I found around 6 is ideal for normal content, but maybe 8 for animation. Setting this too high just leads to more encode time with little efficiency benefit. In the stats at the end of the encode, you can see the percentages for the consecutive b-frames. The first number is 0, so if there are 7 numbers the seventh one relates to 6 consecutive b-frames. You will see the percentages can be quite low at the top end, any less than a few percent it wouldn't be worth the extra encode time. Instead of a B frame in that instance, a P frame would be used instead.

For example, for a few recent recent encodes (x265 2.0+11) I got:


The 6.5%, 8.4%, and 7.1% relate to the 6th b-frame. I found no matter what the source, if I selected 7 or higher for testing the 7th and so on frame percentage was very low. That is why I settled on 6 b-frames as optimal.

The other options are a balance of speed and quality. Also note I set --tu-intra-depth 3 as this shows benefits for little peformance cost, however I did not option --tu-inter-depth 3, as it didn't show any noticeable quality or compression improvements, and just slowed down the encode.
The settings -early-skip --fast-intra --tskip --tskip-fast --limit-modes are all performance related, they noticeably improve speed when all used together but really don't impact the quality of the output. Give the settings I listed a go exactly as written apart from the --merange calculation (no other changes) and see how the speed compares to quality.

EDIT:
Forgot to mention, the above is solely the options on the command line. That is, not using any other preset as a basis. The crf (not stated) should be set to the desired amount. I would suggest maybe something a little lower than the default but within what would give you a desirable end file size. You can use decimals, so you could set it to 21.2 if you wanted (for example).


@burfadel,

Thanks for all of the info! I really appreciate the detailed response.

I ran a quick test of your settings compared to mine. Here are a couple of screenshots.

Your settings + medium profile: 6068 Kpbs
https://s32.postimg.org/co84sapq9/287_Dexter_Season_5_t03_test_doom9_settings.png (https://postimg.org/image/co84sapq9/)



I took another look at my previous settings, I use those for older video or that I'm trying to get through a little faster.


--crf 21 --profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 3 --merange 27 --subme 5 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip
--b-intra --no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.9 --cutree --rd 4
--tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2 --psy-rdoq 2 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 32

My settings + Medium profile: 9773 Kbps
https://s32.postimg.org/d29grw9tt/287_Dexter_Season_5_t03_test_new.png (https://postimg.org/image/d29grw9tt/)


I admit your setting do offer a lower bit rate, I used crf 21 for both encodes. Your settings were almost twice as fast as mine. I did a couple of quick comparisons purely for speed by adjusting b frames, tu-inter-depth, me. I noticed the about .2-.3 more fps when I removed tu-inter-depth. The others were .1ish.

Regarding me range - I read a post from x265Project regarding how they determine their default number of 57, as it pertains to their profiles. It would take me sometime to find it. They took the ctu size 64 and subtracted 7 for varies reasons. I don't recall of the reasons that were stated. I essentially applied the same logic to a ctu size of 32. 32 - 7 = 25. :) I recently upped it to 27.

With that said I admit watching the two encodes side by side I could barely see a difference. It was only with the screenshots that I could easily identify the differences. I will need to reevaluate some of my settings from a speed perspective.

@Rogatti

I went back and played with x264 a bit and I'm shocked to see the quality difference is far more noticeable then I ever remember. I know my tests weren't apples to apples but I tried x265 medium vs x264 slow + slower. In both cases x265 quality was noticeable better even when in motion.

My question, is x265 worth it has been answered! :)

@littlepox

Why is ctu 32 in your recommended film tune?


@ anyone willing to help :)

Would anyone be willing to help me adjust my settings? I'd like to increase or maintain the quality of my settings while trying to remove the options that are slowing my encodes down with little to no benefit. The idea being I can increase/decrease crf to achieve the ideal bitrate/file size.

On a side note. I'd like to thank the community as a whole for being awesome. I've never been a forum that is as willing to help and most importantly nice about it as doom9.:D

[burfadel]

@burfadel,

Thanks for all of the info! I really appreciate the detailed response.

I ran a quick test of your settings compared to mine. Here are a couple of screenshots.

Your settings + medium profile: 6068 Kpbs
https://s32.postimg.org/co84sapq9/287_Dexter_Season_5_t03_test_doom9_settings.png (https://postimg.org/image/co84sapq9/)



I took another look at my previous settings, I use those for older video or that I'm trying to get through a little faster.


--crf 21 --profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 3 --merange 27 --subme 5 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip
--b-intra --no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.9 --cutree --rd 4
--tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2 --psy-rdoq 2 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 32

My settings + Medium profile: 9773 Kbps
https://s32.postimg.org/d29grw9tt/287_Dexter_Season_5_t03_test_new.png (https://postimg.org/image/d29grw9tt/)


I admit your setting do offer a lower bit rate, I used crf 21 for both encodes. Your settings were almost twice as fast as mine. I did a couple of quick comparisons purely for speed by adjusting b frames, tu-inter-depth, me. I noticed the about .2-.3 more fps when I removed tu-inter-depth. The others were .1ish.

As a result of the lower bitrate with my suggested settings, you can use an even lower CRF. Between 5058 kbps and 9773 bbps is a big jump, that's 61 percent more bandwidth used, so your settings should look better. Higher bandwidth like that usually will. It is surprising how much more bandwidth your settings used though, it's very much to the point where regardless of whether you like the result there's definitely a lot of bitrate wasting somewhere in your settings. The key concept is that you don't have to stick to a particular CRF. If you want to improve the quality of the settings I suggested, just simply lower the CRF. Normally you do compare CRF to CRF, but you have to take into account encode time and file size as well. I believe comparing based on quality relating to bitrate used would be a far better metric for this comparison.

Another 'trick' to save a bit of bitrate, which in turn means you can lower the CRF slightly is to use:
--nr-intra 400 --nr-inter 400
or whatever decent size number you choose. Don't go too high too low though, otherwise you defeat the purpose :). This cleans up a little of the low-level noise. It shouldn't be used by itself though, you need to combine it with reducing the CRF a bit. You save a bit of bitrate by setting NR, in turn you an use this recovered bitrate to improve the quality of the encode.

Maybe you could try the encode again, using similar to what I listed before but with the addition of the NR and a lower CRF. Note also the lookahead range, I don't know why I wrote 40 before since I use 50! Seeing as you are using 1920x1080, I would suggest a higher ME. Say 57, but let's for argument sakes say 40:
--crf 18 --output-depth 10 --rd 4 --tu-intra-depth 3 --rdoq-level 2 --early-skip --fast-intra --b-intra --tskip --tskip-fast --limit-modes --aq-mode 2 --qg-size 16 --me star --merange 40 --max-merge 3 --weightb --bframes 6 --rc-lookahead 50 --ref 6 --psy-rdoq 1.38 --nr-intra 400 --nr-inter 400

Why the use of --ctu 32 (faster but lower encode efficiency), --bframes 8 (slower) --limit-refs 0 (slower than default of 3), --subme 5 (much slower than default 2, only fractional gains over default 2), --no-early-skip (slower than early skip), --no-sao (why?) --aq-mode 3 (I've gone back to 2 after further testing) --aq-strength 0.9 (default of 1.0 is fine in mode 2), --no-strong-intra-smoothing, --qg-size 32 (I think 16 is better for detail).

Can you explain your reasons for the above settings :). Yes quality is the goal, but that needs to be balanced with speed and output size. Your output size is a little high, you should be able to achieve similar results with a lower CRF based on the settings I suggested.

[brumsky]

As a result of the lower bitrate with my suggested settings, you can use an even lower CRF. Between 5058 kbps and 9773 bbps is a big jump, that's 61 percent more bandwidth used, so your settings should look better. Higher bandwidth like that usually will. It is surprising how much more bandwidth your settings used though, it's very much to the point where regardless of whether you like the result there's definitely a lot of bitrate wasting somewhere in your settings. The key concept is that you don't have to stick to a particular CRF. If you want to improve the quality of the settings I suggested, just simply lower the CRF. Normally you do compare CRF to CRF, but you have to take into account encode time and file size as well. I believe comparing based on quality relating to bitrate used would be a far better metric for this comparison.

Another 'trick' to save a bit of bitrate, which in turn means you can lower the CRF slightly is to use:
--nr-intra 400 --nr-inter 400
or whatever decent size number you choose. Don't go too high too low though, otherwise you defeat the purpose :). This cleans up a little of the low-level noise. It shouldn't be used by itself though, you need to combine it with reducing the CRF a bit. You save a bit of bitrate by setting NR, in turn you an use this recovered bitrate to improve the quality of the encode.

Maybe you could try the encode again, using similar to what I listed before but with the addition of the NR and a lower CRF. Note also the lookahead range, I don't know why I wrote 40 before since I use 50! Seeing as you are using 1920x1080, I would suggest a higher ME. Say 57, but let's for argument sakes say 40:


Why the use of --ctu 32 (faster but lower encode efficiency), --bframes 8 (slower) --limit-refs 0 (slower than default of 3), --subme 5 (much slower than default 2, only fractional gains over default 2), --no-early-skip (slower than early skip), --no-sao (why?) --aq-mode 3 (I've gone back to 2 after further testing) --aq-strength 0.9 (default of 1.0 is fine in mode 2), --no-strong-intra-smoothing, --qg-size 32 (I think 16 is better for detail).

Can you explain your reasons for the above settings :). Yes quality is the goal, but that needs to be balanced with speed and output size. Your output size is a little high, you should be able to achieve similar results with a lower CRF based on the settings I suggested.

Several of my settings come from littlepox's most recent film tune.

--ctu 32: comes from varies posts on Doom9. The short version is that ctu 64 causes the bitrate to increase to compensate for the increased compression. I've also read that there is increased quality. It is also in littlepox's suggested film tune.

--bframe 8: Looking for increased compression with minimal increase in encoding time. Littlepox again.

--limit-ref 0: looking for increased compression.

--no-early-skip: Fear of decreased compression. I have changed to --early-skip for increased performance.

--subme 5: Better motion est. I've been bouncing back and forth between 3 & 5 though. >=3 includes chroma residual cost...

--no-sao: I've heard it called the blur all objects option. haha

--no-strong-intra-smoothing: blurs

--aq-mode 3: pulled from littlepox's tune film. I've been back and forth on this one as well.

--qg-size 32: I've changed to 16 as well. I did some testing and show a minimal savings compared to 16. 16 does appear to be sharper.

--me-range 25: x265 docs state the following.

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.

64 - 4 - 2 - 1 = 57

I applied the same logic to a CTU of 32.

32 - 4 - 2 - 1 = 25

I made the change to avoid the additional CTU row of latency.

Your settings have given me a lot to think about and test. I spent several hours testing and tweaking my settings compared to yours. I'm currently using these.

--crf 21 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 0 --me 3 --merange 26 --subme 3 --no-rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 1
--psy-rd 2 --psy-rdoq 1.5 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

I plan on tweaking limit-refs next.

Take your settings and add --ctu 32 --merange 25 and give it a go. I did and found ctu 32 give a slightly smaller file size. My 60 second test clip is 182 MB.

Using your settings it comes out to 46.5 MB.

Add --ctu 32, 44.8 MB. Nothing crazy I know but it encodes about 1 - 1.5 fps faster for a 3.5% smaller file.

[gamebox]

@bromski: Can you repeat the last test you talked about, but adding: --rect, --amp, --no-early-skip, and --tu-inter-depth 3 options when encoding with --ctu 64?

It defies logic that a video encoded with a limiting option like --ctu 32 results in smaller file. All these options I suggested replacing should enable the encoder to analyze bigger CUs more thoroughly, and reuse more material from them.

[brumsky]

@bromski: Can you repeat the last test you talked about, but adding: --rect, --amp, --no-early-skip, and --tu-inter-depth 3 options when encoding with --ctu 64?

It defies logic that a video encoded with a limiting option like --ctu 32 results in smaller file. All these options I suggested replacing should enable the encoder to analyze bigger CUs more thoroughly, and reuse more material from them.

I took the original settings burfadel suggested and added the options you suggested.

--crf 21 --output-depth 10 --rd 4 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 2 --rect --amp --no-early-skip
--fast-intra --b-intra --tskip --tskip-fast --limit-modes --aq-mode 2 --qg-size 16 --me star --merange 25 --max-merge 3 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --psy-rdoq 1.38

Result: 187MB test clip -> 35.7MB - 4553 Kbps
https://s32.postimg.org/jcgxndvch/287_Dexter_Season_5_t03_test_new_rect_amp_ctu.png (https://postimg.org/image/jcgxndvch/)



--crf 21 --output-depth 10 --rd 4 --ctu 32 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 2 --rect --amp --no-early-skip --fast-intra
--b-intra --tskip --tskip-fast --limit-modes --aq-mode 2 --qg-size 16 --me star --merange 25 --max-merge 3 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --psy-rdoq 1.38

Result: 187MB test clip -> 44.1MB - 5737 Kbps
https://s32.postimg.org/slj3xi48h/287_Dexter_Season_5_t03_test_new.png (https://postimg.org/image/slj3xi48h/)

CTU 64 is about 19.1% smaller. Each encode was about 50-60% slower than before. If you compare the pics I actually see more detail in the ctu 32 pic. Look around the mouth and chin, it is noticeable more blurred in the ctu 64 pic.

I was never trying to say that ctu 64 can never be smaller. Just that compared to burfadels original settings adding ctu 32 was faster and smaller.

Burfadels original settings - > 46.5MBs - 6068 Kbps

I'm admittedly trading size for speed.

For comparison here are my current settings with CRF 22. I'm trying to get closer to the size and bitrate of the ctu 64 with amp rect settings.

--crf 22 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3
--merange 26 --subme 3 --no-rect --no-amp --limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree
--rd 4 --tu-intra-depth 3 --tu-inter-depth 1 --psy-rd 2 --psy-rdoq 1.38 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16


Results: 187MB -> 37.7 MB - 4835 Kbps
https://s31.postimg.org/idl87j0h3/287_Dexter_Season_5_t03_test_new.png (https://postimg.org/image/idl87j0h3/)


To my eye my settings look a little better then both encodes and I averaged closer to 7 fps...

I shouldn't use the term "my settings' as those are largely Burfadels suggestions with a few minor tweaks. --no-sao --no-strong-intra-smoothing --ctu 32

[gamebox]

Hey, brumsky, thanks a lot :)

That test meant a lot to me, as I could verify that --ctu 64 option can indeed give noticeably more efficient encoding, however - it also brings an unexpectedly big speed penalty. My logic tells me that difference in speed should get significantly reduced with further x265 optimizations, as biggest CUs are present in low detail areas, not many get created because of their large size, and I expect them to "crumble down" to smaller blocks fast.

Also, could there be some sort of bug in x265 logic when using --ctu 64, since your first encode has extremely reduced details, and big reduction in bitrate - as if you encoded using completely different settings? I wouldn't expect to have that many largest CUs in a frame you showed.

--amp is probably the most useless option quality wise of the ones I recommended. It is also, highly probably, slowing down process the most.
--rect is more useful for quality and brings less speed penalty.
--no-early-skip influenced speed dramatically in my tests, but likewise had large influence on quality too.
--tu-inter/intra-depth 3 are the options I recently added to my encodes, as they did prove to increase quality. I lost about 10-15% speed.
I encode using slightly modified slower profile.

[brumsky]

Hey, brumsky, thanks a lot :)

That test meant a lot to me, as I could verify that --ctu 64 option can indeed give noticeably more efficient encoding, however - it also brings an unexpectedly big speed penalty. My logic tells me that difference in speed should get significantly reduced with further x265 optimizations, as biggest CUs are present in low detail areas, not many get created because of their large size, and I expect them to "crumble down" to smaller blocks fast.

Also, could there be some sort of bug in x265 logic when using --ctu 64, since your first encode has extremely reduced details, and big reduction in bitrate - as if you encoded using completely different settings? I wouldn't expect to have that many largest CUs in a frame you showed.

--amp is probably the most useless option quality wise of the ones I recommended. It is also, highly probably, slowing down process the most.
--rect is more useful for quality and brings less speed penalty.
--no-early-skip influenced speed dramatically in my tests, but likewise had large influence on quality too.
--tu-inter/intra-depth 3 are the options I recently added to my encodes, as they did prove to increase quality. I lost about 10-15% speed.
I encode using slightly modified slower profile.

I copied burfadel's settings exactly and only changed the ones you mentioned. rect, amp, ctu 64, no-early-skip. I stopped using rect and amp months ago because of the speed penalty.

burfadel had --tskip --tskip-early --fast-intra, those could be responsible for the decreased visual quality. Although, they were in both the ctu 64 and 32 tests - yet the 32 looked better to me. I don't use those.

These were my old settings.

--profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 1 --merange 25 --subme 3 --no-rect --no-amp --limit-modes
--max-merge 4 --no-early-skip --b-intra
--no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.8 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 3
--psy-rd 2.0 --psy-rdoq 2.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65
--no-strong-intra-smoothing --deblock -1:-1 --qg-size 32

Using those settings with my test clip, I'd average about 1.8 - 2.2 fps. With burfadel's modified settings, I average 3x faster encodes - >6.5 fps average.

I can't tell a difference between my old settings and the new ones. I use staxrip's video comparison and they are indistinguishable to me. I'd imagine a trained pro could pick out the changes but I can't.

Try burfadel's recommendation, --tu-inter-depth 1 --intra-depth 3. I couldn't tell a difference and gained .5 - .75 fps.

Also, I tested limit-refs a bit. 3 is obviously the fastest, with little to no discernable difference - to my eyes. 2 was slower than 1, 0 was the slowest of course. My guess is limiting the depth, 1, is faster than limiting the CU,2. I'm sticking with 3 for now, I may consider testing 1 further from a quality perspective.

Try these setting and let me know what you think. Change the crf to meet your ideal bitrate. Based on my testing I'd rather up crf then go with ctu 64...

--crf 19.75 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3
--merange 26 --subme 3 --no-rect --no-amp --limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 1 --psy-rd 2
--psy-rdoq 1.38 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[burfadel]

Yeah the settings --tskip --tskip-early --fast-intra are purely a speed consideration. If you want to balance out a slightly lower bitrate for comparison you could use --crf 21.7 for example :). Also try a small amount of inter and intra noise reduction, like 400, and make up the lower output size with a lower crf. Since I put 21.7 above, try 21.2. It's about trying to maximise efficiency.

[burfadel]

I just did some further testing. When I originally did my testing with --t-skip, --t-skip-fast, and --fast-intra they were beneficial speed wise. However, x265 has undergone improvements since then and I am no longer seeing the speed increase. Things like recursion skip etc were added. Of course, a lot of that could be dependent on the source material.

Don't forget that any setting that changes the output can also affect the speed of the encode. For instance, even if --fast-intra does the processing of that particular area faster because the output has changed it affects other areas of the encode. Now that there have been changes in other areas such as --limit-modes, recursion skip, limit references etc., I found in some cases it was actually faster without the speed settings! It's all about synergy of settings. This synergy also applies to the noise reduction argument keeping in mind the noise reduction in x265 is very mild. I don't suggest using it by itself, for benefit you need to use it in conjunction with reducing the CRF. If you are using a CRF of 16 or something it probably wouldn't be worth it, but at a higher CRF it is. In the last lost of testing I did, without 400 noise reduction on intra and inter I got almost the same file size at 22 as I did with testing with both inter and intra NR on (400) at a CRF of 21.2. As I said, you don't have to go 400, you could test with 200 on both Inter and Intra, and a CRF of say, 21.6, or whatever the bitrate equivalency is, and work out the balance that best suits. I do believe though that you can achieve a higher output quality once you take into account the ability to use a lower CRF for a given bitrate.

I also testing without --early-skip, I only used one clip for this, but the speed drop was 21 percent. That is quite a lot so I don't recommend it, I only tried it out to see exactly how much slower it actually is.

If you are okay with the speed loss of --early-skip for quality, then you probably wouldn't mind --rd 5 and using --rd-refine. The picture quality is much nicer when you do a direct comparison, it retains picture texture very well, but is slow.

So, my new settings:
--crf 21.4 --output-depth 10 --rd 4 --tu-intra-depth 3 --rdoq-level 2 --early-skip --b-intra --limit-modes --aq-mode 2 --qg-size 16 --nr-intra 400 --nr-inter 400 --me star --merange 26 --max-merge 3 --weightb --bframes 6 --rc-lookahead 50 --ref 6 --psy-rdoq 1.38
(the decimal CRF is lowered from 22 from using 400 on the noise reduction).

If you want to try something that isn't practical speed wise, but gives a nicer picture for roughly the same file size (it retains flat areas well):
--crf 21.4 --output-depth 10 --rd 5 --rd-refine --tu-intra-depth 3 --rdoq-level 2 --early-skip --b-intra --limit-modes --aq-mode 2 --qg-size 16 --nr-intra 400 --nr-inter 400 --me star --merange 26 --max-merge 3 --weightb --bframes 6 --rc-lookahead 50 --ref 6 --psy-rdoq 1.38

If the development team could work out a fast method of achieving --rd 5 and --rd-refine without being too much slower than --rd 4, it would probably solve all these problems with flat textures etc that people are mentioning. The fast method I mean is like an early-skip pass or something. Even if it worked only half as well as --rd 5 and --rd-refine with say, a 10 percent speed loss, it would be an option I'd recommend straight away:). You need to compare the actual picture and not the metrics, I think you'll be surprised. First try comparing with the settings I have above, and then again with yours (but the second time use --rd 5 and --rd-refine). The reason for the dual testing is because it retains detail even on large flat areas much better, you really need to test it with the default settings for ctu and smoothing, that is not use --ctu 32 and --no-strong-intra-smoothing.

[divxmaster]

@burfadel,
what are you using to compare videos, are you using stackhorz/stackvert or are you using staxrip video comparison tool?

Cheers
Divxmaster

[burfadel]

I use the Staxrip video comparison tool, but I also just play it in Windows Media Player and compare them that way as well as it includes motion. I use WMP because if I used MPC-HC with the custom madVR settings I have it would throw out any comparison.

[gamebox]

brumsky: I haven't encoded using main10 so far. My target playback hardware are some future STBs, TVs, built-in GPU decoders - namely, the cheapest decoding hardware available, and I'm concerned about compatibility. Besides, I don't have a powerful hardware, so speed matters to an extent, and sometimes the quality of my sources is not the best as well.

I use these:
--bframes 9, as I hadn't noticed significant reduction in speed over 6, so kept it for maximum coding efficiency
--ref 6
--rect, as it improved quality slightly without hurting speed too much, unlike amp which brings slight improvement (if any) at a very high cost
--no-sao, --no-strong-intra-smoothing, --deblock -2 (-3)
--early-skip brought obvious quality loss despite big gains in speed, so I discarded it in some of previous tests
--max-merge 2, --limit-modes, --limit-refs 3 --no-weightb, all chosen for speed

--qg-size 16 was accumulating artifacts in blocks containing "important" details to my eyes, so I discarded it to allow the encoder to reduce quality of largest CUs as well. However, I also use --no-cutree, as my encodes are of a kind where quality of the background is not that important, unlike areas of intense movement and changes in foreground. So, even options that reduce encoding efficiency, by discarding some of the textures in such areas, can seem "optimal" for me, as motion estimation tends to blur retained visual material. Precise motion estimation algorithms avoiding harsh and "blocky" look, and well defined edges - especially ones with lower contrast, mean most to me. Most encoders (x264 included) tend to "dissolve" less pronounced edges, so they almost become like gradients. Only well defined objects keep their outlines, while everything else becomes smoothed.

For comparing images I use "old school methods". Save frames for comparison as BMP using MPC (preferably B-frames), then open both in full screen in separate image viewer windows, and alternate between them.

[K.i.N.G]

got around to testing sao in 2.0. same problem, still blurs way too much. and the no-sao test was *smaller* than the sao one! 1000 frames.

Same here...

[kuchikirukia]

--bframes 9, as I hadn't noticed significant reduction in speed over 6, so kept it for maximum coding efficiency

My experience with x264 is that b-frame usage falls off a cliff after 6 with live action. I find there's generally less than 1% compression gain to be found between that and 16. With anime, you can find a couple percent more up to 10 b-frames. If x265's b-frame calculations are similar in nature, you're looking at adding encoding time for pretty much no gain. With x264, b-frames aren't massively expensive, but they're not trivial, either.
So you might want to take a look at your logs to see what the b-frame usage actually is, and do some runs to see what the penalty is. I haven't done any work with x265 so I don't know if the increased computational complexity overshadows the b-frame computation or if it adds to them.

[LigH]

Long range B-frames also decrease compatibility with consumer players. The more consecutive B-frames may exist between I or P frames, the more frames the decoder will have to handle until a GOP is done, especially when B-frame pyramid and references among B-frames are used, that may go beyond hardware limits.

[gamebox]

@ kuchikirukia, Ligh:

In my logs, indeed, B-frame usage falls off sharply after 6 or 7. Over 6 I generally see only 1-2 %. I might reconsider that option soon.

I'm currently struggling with increased encoding time after I added --tu-intra/inter-depth 3. Quality did increase considerably, but encoding time seems to have suffered more than I previously estimated in tests. I'll try lower depths and different combinations, aiming to preserve most of the quality gain. --no-rskip also proved useful, but increased encoding time as well. I hope to offset the slowdown with new RAM planned for my system - 1866MHz DDR3. I'm temporarily using 1333MHz modules from previous configuration. CPU is AMD FX-8320, octo-core, AVX capable.

[burfadel]

I did some more tests, seems it is not only a nicer picture without SAO, but it is faster as others have found. This faster is by several percent and repeatable, so it's not a margin of error thing! SAO is probably not a bad thing in theory, just the internal smoothing amount is probably too high?

I did some further testing out of interest, regarding a couple of key things that directly affect output quality.
--ipratio 1.35
--pbratio 1.25
--bframe-bias 35

The ipratio (between I frames and P frames) by default is 1.40. I tried lowering this slightly to 1.35 meaning higher quality P frames. This of course affects the I frame and B frame bitrate as well, and you also have to remember because the I to P frame ratio is lower, the P to B amount also changes because the ratio of the P to B frame is based off the P frame's ratio to I.

I ended up with a smaller file as a result on the clip I used!... yes, when I thought about it, because of it affecting everything else this can happen.

I then thought I'd try upping the quality of the B frames a bit. Default is 1.30, I tried 1.25. I then thought about the b-frame usage beyond 6 frames, this is easily adjusted with using the --bframe-bias option. Yes, 35 is probably fairly high, but I did manage to be able to select a much higher number of bframes, I tested 9, and still got double digit b-frames at the 9th consecutive, whereas by default 6 seems to be the limit. Even if you still had 6, the b-frame usage would be higher. Of course, b-frames are lower quality, but if you adjust the ratio's and work it out properly :). By that I mean much less extreme changes. If the file size in the end is smaller than an encoded clip without these changes, if the drop is significant enough try dropping the CRF by 0.1.

So I didn't go into fully testing with these settings, but I believe small tweaking of these could help with some of the smoothing issues. The current ratios just seem to be pulled from x264, and there's nothing to say those ratio's were perfected either. That said, because this was pulled from x264, it's probably much more off in x265.

Now there's some testing for you to do! Try small variation for a start, and things like 1.20 for the ipratio probably wouldn't be helpful. I am referring more to say, between 1.34 and 1.42. Likewise with the pbratio. If the pbratio is adjusted then a slight b-frame bias can be applied since the b-frames will be higher quality.

So the fine tuning fun isn't over yet!

[burfadel]

To my liking, probably ipratio 1.38 and pbratio 1.28, along with the other settngs including --no-sao.

Do an encode with your normal settings, and one with the two options above. Let me know what you think :).

[foxyshadis]

SAO really seems more designed for low bitrate than high, it's tremendously useful when every bit counts, where banding is terrible, and entirely useless when you want grain. Even at medium bitrates (where you accept some degradation) it's very questionable, especially for 10+bit. My completely unsubstantiated guess is that x265's thresholds for SAO are just way too high, and since there are no knobs to turn, you have to either accept it or disable it.

It should be noted that SAO doesn't really get a lot of love, outside of big speedups and occasional bug fixes. The last noticeable change was 5 months ago (using the CU's QP instead of the whole slice's), which was relatively small, and before that, the last real algorithmic change was probably in the original HM that x265 was based on. Don't get me wrong, fixing incorrect output is important, but since development of SAO pretty much ended when HEVC was standardized, there's probably room for some improvement, or at least some tweaking. I wish I had time for that.

[mandarinka]

I hope to offset the slowdown with new RAM planned for my system - 1866MHz DDR3. I'm temporarily using 1333MHz modules from previous configuration. CPU is AMD FX-8320, octo-core, AVX capable.

Memory frequency is not likely to help encoding speed much if any. You might get some small boost if the latency (in nanoseconds) goes down, but still, encoding is not RAM-bound, it is almost solely CPU-bound type of task. The only way up is in faster CPU/OC.

I got to say that the point of using x265 is IMHO in getting better quality than from x264, and to fully realize that goal, you mostly have to turn most of the knobs into the slow territory. So IMHO chasing speed might be contra-productive...
you go into HEVC to get some compression/quality boost over x264, but then loose half of that benefit (if not more), by chasing speed? :)

[burfadel]

SAO really seems more designed for low bitrate than high, it's tremendously useful when every bit counts, where banding is terrible, and entirely useless when you want grain. Even at medium bitrates (where you accept some degradation) it's very questionable, especially for 10+bit. My completely unsubstantiated guess is that x265's thresholds for SAO are just way too high, and since there are no knobs to turn, you have to either accept it or disable it.

It should be noted that SAO doesn't really get a lot of love, outside of big speedups and occasional bug fixes. The last noticeable change was 5 months ago (using the CU's QP instead of the whole slice's), which was relatively small, and before that, the last real algorithmic change was probably in the original HM that x265 was based on. Don't get me wrong, fixing incorrect output is important, but since development of SAO pretty much ended when HEVC was standardized, there's probably room for some improvement, or at least some tweaking. I wish I had time for that.

I think the issue is it's probably set too strongly as well. Maybe it's probably too code complex as well, or it could be incorporated to some extent in other functions, and optimised using AVX etc for improved speed?

[Motenai Yoda]

My completely unsubstantiated guess is that x265's thresholds for SAO are just way too high, and since there are no knobs to turn, you have to either accept it or disable it.

maybe it will can be tuned with deblock ones

[benwaggoner]

@ kuchikirukia, Ligh:
In my logs, indeed, B-frame usage falls off sharply after 6 or 7. Over 6 I generally see only 1-2 %. I might reconsider that option soon.
High bitrates and higher grain retention tend to reduce the number of b-frames. For really low bitrates where grain isn't an issue, I see longer series of consecutive b-frames. For ultra low bitrates, I've tried 16, and seen >1% usage for that 16th. It obviously wasn't good looking video, but it was better looking video for that bitrate than with fewer b-frames.

Of course the use cases of "as good as possible within X bitrate" and "as a low a bitrate as possible with X quality" are quite different, and require different tunings. x265 has certainly been evolving so that stock settings are better at both cases (night and day compared to the fall 2014 builds!).

The first web video I ever did, back in late 1997 (I think), was something like 192x144p10 30 Kbps beta RealVideo. we have certainly come a LONG way from there. It was for the Peter Jacobson golf tournament, and the shaft of the club would vanish whenever it was swung - strong bias against high frequency diagonals! 320x240p24 @ 30 Kbps is leaps and bounds beyond was possible then. Although people's expectations have grown proportionally - analog 480i isn't the "broadcast" quality" Big Rock Candy Mountain.

[benwaggoner]

CPU is AMD FX-8320, octo-core, AVX capable.
AVX2 yield big improvements for x265. I think we're now seeing a >50% improvement going from Sandy Bridge to Haswell, due to AVX2 and also microarchitectural improvements.

For 1080p and below, my 4-core Skylake 6700 outperforms my 16-core Sandy Bridge workstation. That's AVX2 and microarchitecture for you. And it's nearly twice as fast as my 4-core Haswell "portable workstation" laptop which has AVX2 and the same cores.

I'm not sure how the fastest Skylake compares to the new Broadwell-based i7's, which are available with lots of cores. But per-core performance is really important. And for ultimate quality encodes, you can gain some quality by reducing frame parallelism (although it's not nearly as big a deal as six months ago), which also makes single-core performance relatively more important.

[mandarinka]

For 1080p and below, my 4-core Skylake 6700 outperforms my 16-core Sandy Bridge workstation. That's AVX2 and microarchitecture for you.

You should probably stress more that it's because (a) the 16core would not nearly be utilizing all cores well or at all and (b) higher frequency on the Skylake. Because you know internet, people are going to misinterpret :)
The per-GHz and per-core performance of course haven't improved 4x,I'd roughly guess the IPC improved 25% for x264 and maybe up to 40% for x265 (not that sure there).

http://www.anandtech.com/bench/product/1554?vs=287
Note that while both chips have the same base clock, i7-6700 probably gets much higher real frequency due to turbo, which will be activating more aggressive bins than on the old 32nm and quite hot-running i7-2600K.

[aymanalz]

AVX2 yield big improvements for x265. I think we're now seeing a >50% improvement going from Sandy Bridge to Haswell, due to AVX2 and also microarchitectural improvements.

For 1080p and below, my 4-core Skylake 6700 outperforms my 16-core Sandy Bridge workstation. That's AVX2 and microarchitecture for you. And it's nearly twice as fast as my 4-core Haswell "portable workstation" laptop which has AVX2 and the same cores.


I have experienced the huge leap in performance with Haswell, as compared to Ivy bridge, on my two 4-core laptops. That is probably attributable to AVX2. But what explains the twice-as-fast performance increase of your Skylake over Haswell? Is it, as the poster above postulates, due to much higher frequency on the Skylake? Was the Skylake a desktop CPU, as opposed to the "Mobile workstation's" Haswell? That would obviously make a big difference. Or are there architectural improvements in Skylake that produce this result?

[gamebox]

@benwaggoner
Ever since I did my first video encode (back in 2001) I tend to chose "borderline" bitrates for each technology. I chase that thin line where bitrate is "just sufficient" for "everyday quality" video and picture is not far from obviously falling apart. For HEVC, I've found that bitrate to be approximately 1,2 Mbps for 480p video, 2 Mbps for 720p.

FX-8320 was my only choice for the moment. At 90eur secondhand (30 for mobo) it was far cheaper than anything comparable a monopolist rival makes. AVX (it's resulting speedup, to be precise) was also an "enabling" feature of this processor, making difference between video encoding that was just (barely) "possible" and encoding whose speed comes closer to meeting real-life needs. I've left behind two AMD non-AVX quads which proved useless for (quality) HEVC encoding, despite my optimism. One of mobos in those systems supports early bulldozers, and I already drew a plan to buy another cheap AVX CPU to split encoding load. Electricity consumption is an issue, but secondary, as most of my video encoding takes place in off-peak electricity interval, and I plan all my systems having that amount of utilization in mind (if I used my current CPU 24/7, I wouldn't need another system).

[kuchikirukia]

High bitrates and higher grain retention tend to reduce the number of b-frames. For really low bitrates where grain isn't an issue, I see longer series of consecutive b-frames. For ultra low bitrates, I've tried 16, and seen >1% usage for that 16th.

Yup, but that 1% doesn't correspond to 1% greater compression, so while it's good to keep in mind that lower quality might mean more b-frames and to run a test to see if it might be worth it to push it out 1 or 2 more, going to 16 is generally going to be pretty far down the list of sensible places to spend CPU time.

[mandarinka]

AVX (it's resulting speedup, to be precise) was also an "enabling" feature of this processor, making difference between video encoding that was just (barely) "possible" and encoding whose speed comes closer to meeting real-life needs. I've left behind two AMD non-AVX quads which proved useless for (quality) HEVC encoding, despite my optimism. One of mobos in those systems supports early bulldozers, and I already drew a plan to buy another cheap AVX CPU to split encoding load.

You don't really need AVX, which is mainly set for floating point data. The pitfall with K10 ("non-AVX") AMD chips is not lack of AVX, but lack of SSSE3 and SSE4.1/SSE4.2, which x265 absolutely needs, because that is the target its hand-written assembly SIMD uses.

K10 like Phenoms still only had SSE2 as its SIMD instruction extension, and x265 only has small fraction of its SIMD covered for SSE2 target. For that reason, the speed of x265 on K10 is cut to about 1/3 of its theoretical possibilities. This also affects other chips that lack SSE4, like 65nm Core 2 duos/quads and Celerons/Pentiums before Sandy Bridge.

[gamebox]

Thanks, Mandarinka, I didn't know that :)

I liked AMD K10 core's performance in x264, so I thought four of those, working together, would create a fairly decent data crunching "machinery" for x265. Truth is that, with my settings, an overclocked K10 quad working at 3,2GHz (RAM at nearly 1500 MHz), with nearly 100% CPU load, takes as much as 70 hours to encode a 1,5 hour long SD video! About 5 times longer than FX-8320, although encoding SD content occupies about 70% of that CPU.

[brumsky]

@ kuchikirukia, Ligh:

In my logs, indeed, B-frame usage falls off sharply after 6 or 7. Over 6 I generally see only 1-2 %. I might reconsider that option soon.

I'm currently struggling with increased encoding time after I added --tu-intra/inter-depth 3. Quality did increase considerably, but encoding time seems to have suffered more than I previously estimated in tests. I'll try lower depths and different combinations, aiming to preserve most of the quality gain. --no-rskip also proved useful, but increased encoding time as well. I hope to offset the slowdown with new RAM planned for my system - 1866MHz DDR3. I'm temporarily using 1333MHz modules from previous configuration. CPU is AMD FX-8320, octo-core, AVX capable.

--tu-inter-depth adds a descent amount of encoding time. Also, I'd suggest allowing rskip. You get better grain retention with psy-rd settings compared to most other changes. I'd suggest increasing psy-rd and psy-rdoq levels.

On another note:

I've been toying with --early-skip --limit-modes and --rect --amp. If I'm reading the x265 docs correctly, early skip only kicks in when no motion or not enough motion is detected. Once it detects enough motion it processes normally. I added rect and only noticed about a .5 fps decrease, rect + amp sees a total decrease of about 1.5 fps when early-skip and limit-modes are used together.

The idea being use early skip so you don't waste time when there isn't enough or no motion at all. Then allow the encoder to spend more time when motion is detected by using rect and/or amp.

Also, note that rect implies an additional tu-inter-depth automatically. I believe that means using --tu-inter-depth 1 with early-skip will prevent a lot of wasted time when no motion is detected. Then when motion is detected, rect kicks in and gives you an effective --tu-inter-depth 2 only in the spots that need it. Limit-modes just allows rect and amp to be more selective in its tests.

Here are my current settings.

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[burfadel]

Try adding:
--ipratio 1.38 --pbratio 1.28

It might seem a slight adjustment, but it does seem to be nicer. Adjusting these too much won't be beneficial.

[x265_Project]

I have experienced the huge leap in performance with Haswell, as compared to Ivy bridge, on my two 4-core laptops. That is probably attributable to AVX2. But what explains the twice-as-fast performance increase of your Skylake over Haswell? Is it, as the poster above postulates, due to much higher frequency on the Skylake? Was the Skylake a desktop CPU, as opposed to the "Mobile workstation's" Haswell? That would obviously make a big difference. Or are there architectural improvements in Skylake that produce this result?

A key improvement in Skylake is the internal ring bus, which has double the memory bandwidth of the previous CPU generation (Haswell/Broadwell). The internal ring moves data inside the CPU, from cache memory to logic units in each core, and back again. Our performance profiling shows that x265 performance is often constrained by the memory bandwidth of Haswell generation cores which is about 20 GB/sec. Skylake cores have about 40 GB/sec bandwidth, removing this bottleneck.

Skylake CPUs have a number of other architectural improvements that they reviewed in a presentation (SPCS001) at the Intel Developer Forum last year. See http://www.overclock.net/t/1570069/idf-pdf-skylake-microarchitecture-details for copies of some key slides...

Segment optimization
• Dedicated server and client IP configurations
Improved front-end
• Higher capacity, improved Branch Predictor
• Wider Instruction supply with deeper buffers
• Faster prefetch
Deeper Out-of-Order buffers
• Extract more instruction parallelism
Improved execution units
• Shorter latencies
• More units
• Power down when not in use
More load/store bandwidth
• Prefetcher improvements
• Deeper store buffer, fill buffer and write-back buffer
• Improved page miss handling
• Better L2 cache miss bandwidth
• New instructions for better cache management
Improved Hyper-Threading
• Wider retirement

[aymanalz]

A key improvement in Skylake is the internal ring bus, which has double the memory bandwidth of the previous CPU generation (Haswell/Broadwell). The internal ring moves data inside the CPU, from cache memory to logic units in each core, and back again. Our performance profiling shows that x265 performance is often constrained by the memory bandwidth of Haswell generation cores which is about 20 GB/sec. Skylake cores have about 40 GB/sec bandwidth, removing this bottleneck.


Ah I see, thanks for the info. I may have erred in buying a Haswell machine recently, instead of going for Skylake.

Could you tell us which is a more exhaustive motion search, umh or star?

[mandarinka]

Ah I see, thanks for the info. I may have erred in buying a Haswell machine recently, instead of going for Skylake.

Local improvements like that don't have nearly as huge impact in the overall performance of the chip - just look at the benchmarks.

IIRC according to reviews, Core i7-6700K was beating i7-4790K (comparable chip, both have base clock of 4,0 GHz) by just 10 % in video encoding. Which was a relatively good result, because outside encoding, the per-MHz/per-core improvements were lower, just 2-5% IIRC.

So basically Skylake brings improvements, but if you have Haswell already, you don't need to cry - the cores are close to each other: http://www.anandtech.com/bench/product/1260?vs=1543

[benwaggoner]

Local improvements like that don't have nearly as huge impact in the overall performance of the chip - just look at the benchmarks.

IIRC according to reviews, Core i7-6700K was beating i7-4790K (comparable chip, both have base clock of 4,0 GHz) by just 10 % in video encoding. Which was a relatively good result, because outside encoding, the per-MHz/per-core improvements were lower, just 2-5% IIRC.

So basically Skylake brings improvements, but if you have Haswell already, you don't need to cry - the cores are close to each other: http://www.anandtech.com/bench/product/1260?vs=1543

One other big difference is you don't get nearly as much thermal throttling when heavily making use of AVX2 like with earlier microarchitectures. Since x265 uses AVX2 so extensively, you almost always got a significant clock speed drop pre-Skylake.

I suspect x265 is probably an extreme case for per-core performance gains with Skylake. Which has been generally true for x264/x265 for most new microarchitecture revisions, honestly.


Sent from my iPhone using Tapatalk

[pradeeprama]

One other big difference is you don't get nearly as much thermal throttling when heavily making use of AVX2 like with earlier microarchitectures. Since x265 uses AVX2 so extensively, you almost always got a significant clock speed drop pre-Skylake.

I suspect x265 is probably an extreme case for per-core performance gains with Skylake. Which has been generally true for x264/x265 for most new microarchitecture revisions, honestly.


Sent from my iPhone using Tapatalk

Yes, you are right. We are seeing performance improvements of approximately 2X when encoding 4K videos on a quad-core Skylake system, when compared to a quad-core Haswell system. The bandwidth improvements inside the cache and the ability of Skylake to support DDR4 is hugely beneficial to x265 that really stresses the system's performance knobs.

[mandarinka]

Those are the fast and faster+ presets, I assume?

[x265_Project]

Those are the fast and faster+ presets, I assume?

For 4K encoding on a quad-core desktop, we see a memory bandwidth bottleneck on Haswell processors with our fastest presets (ultrafast, superfast). Under this condition, Skylake can outperform Haswell by more than 2x.

[mandarinka]

I guess that makes sense. My "10%" (with older versions of x265 though) figure was for normal slow encoding where stuff is just CPU execution-bound. Since that is what matters to me...

[gamebox]

@brumsky:
Yesterday I've decided to put --ctu 32 back to use again, at least for SD. Quantizers did increase slightly (when comparing stats files), but I started having issues with 64x64 blocks containing letters or anything sharp - they leave big areas, often geometrically shaped (square), filled with mosquito noise. Apart from that, areas with less details (like human skin) get encoded with rather obvious alternating smooth (big) and sharp (smaller) blocks - though that difference in sharpness could be AQ-related as well. CTUs of 32 helped me a lot with parallelism and saturated all my 8 cores, so 2hrs long 480p video gets encoded with 3.5-4 fps instead of 2 fps.

I'll follow your advice and test --early-skip again in some time. I did most of my image quality tests "the fast and dirty way" - i.e. setting bitrate in 2-pass mode, doing full fast first pass on both videos, and encoding just a hundred or so frames in second passes, so I get some material for comparison as soon as possible. I expect more "final" and "trusty" results by comparing in CRF mode.

[brumsky]

@x265_project:

Can you go into more detail regarding --early-skip and how it interacts with rect and amp, if at all?

I'd like to know if my logic below is applicable or not...

--tu-inter-depth adds a descent amount of encoding time. Also, I'd suggest allowing rskip. You get better grain retention with psy-rd settings compared to most other changes. I'd suggest increasing psy-rd and psy-rdoq levels.

On another note:

I've been toying with --early-skip --limit-modes and --rect --amp. If I'm reading the x265 docs correctly, early skip only kicks in when no motion or not enough motion is detected. Once it detects enough motion it processes normally. I added rect and only noticed about a .5 fps decrease, rect + amp sees a total decrease of about 1.5 fps when early-skip and limit-modes are used together.

The idea being use early skip so you don't waste time when there isn't enough or no motion at all. Then allow the encoder to spend more time when motion is detected by using rect and/or amp.

Also, note that rect implies an additional tu-inter-depth automatically. I believe that means using --tu-inter-depth 1 with early-skip will prevent a lot of wasted time when no motion is detected. Then when motion is detected, rect kicks in and gives you an effective --tu-inter-depth 2 only in the spots that need it. Limit-modes just allows rect and amp to be more selective in its tests.

Here are my current settings.

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[benwaggoner]

@x265_project:

Can you go into more detail regarding --early-skip and how it interacts with rect and amp, if at all?

I'd like to know if my logic below is applicable or not...
In general, features in the presets are turned on based on whether their quality/performance is right for a given speed/quality tradeoff, based on a whole lot of automated testing. In general it probably makes sense to follow those ladders when tuning in speed/quality. For example, some of the skip modes are turned off at pretty fast presets (quality hit is big relative to speed increase) and others only at the slowest presets (smaller quality gain relative to larger performance hit).

[benwaggoner]

@brumsky:
Yesterday I've decided to put --ctu 32 back to use again, at least for SD. Quantizers did increase slightly (when comparing stats files), but I started having issues with 64x64 blocks containing letters or anything sharp - they leave big areas, often geometrically shaped (square), filled with mosquito noise. Apart from that, areas with less details (like human skin) get encoded with rather obvious alternating smooth (big) and sharp (smaller) blocks - though that difference in sharpness could be AQ-related as well. CTUs of 32 helped me a lot with parallelism and saturated all my 8 cores, so 2hrs long 480p video gets encoded with 3.5-4 fps instead of 2 fps.

I'll follow your advice and test --early-skip again in some time. I did most of my image quality tests "the fast and dirty way" - i.e. setting bitrate in 2-pass mode, doing full fast first pass on both videos, and encoding just a hundred or so frames in second passes, so I get some material for comparison as soon as possible. I expect more "final" and "trusty" results by comparing in CRF mode.
What's your full command line? Are you using --qg-size? Did you increment the --tu-*-depth values by one? If you increase CU size, you'll need to correspondingly increase depth to make sure your minimum block size remains the same. That can help a lot in getting high detail regions to use smaller blocks.

With the new improved --rskip, the performance isn't as bad when doing my tu depth, and the results are a lot better.

[brumsky]

Hey Ben,

Thanks for the quick reply. Since I am running an old sandy bridge CPU I'm just trying to find the best balance between speed and quality. I guess I'm hoping that early skip is only used when no motion or very little motion is detected vs the majority of the time. If so areas that aren't in motion wouldn't be worth the encoding time.

In general, features in the presets are turned on based on whether their quality/performance is right for a given speed/quality tradeoff, based on a whole lot of automated testing. In general it probably makes sense to follow those ladders when tuning in speed/quality. For example, some of the skip modes are turned off at pretty fast presets (quality hit is big relative to speed increase) and others only at the slowest presets (smaller quality gain relative to larger performance hit).

[brumsky]

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

[gamebox]

@benwaggoner

I encode using "Simple x264 Launcher" by Mulder. 64-bit 8-bit encoder, slower preset, and this commandline (some switches are redundant):

--rd 6 --no-weightb --ref 6 --me star --subme 7 --merange 24 --b-intra --keyint 300 --min-keyint 50 --bframes 9 --aq-mode 2 --psy-rd 2.0 --psy-rdoq 1.0 --deblock=-2 --no-cutree --limit-refs 3 --limit-modes --rect --no-amp --aq-strength 2 --no-sao --no-strong-intra-smoothing --max-merge 2 --no-rskip --no-slow-firstpass --tu-inter-depth 3 --tu-intra-depth 3

I eliminated qg-size switch, as I wanted the encoder to alter quantizers in all types of blocks. Areas with background scenery are not that important in this case - in a typical Hollywood movie, or a documentary, background/static blocks would matter and I would use --cutree, and probably --qg-size 16 too. My previous encodes (if I remember well) were at tu-intra/inter-depth 2, enforced by preset.

[burfadel]

Don't forget to try:
--ipratio 1.38
--pbratio 1.28

Since you are using --rd 6, also try --rd-refine

I think to make rd 5/6 worth it you need to combine it with --rd-refine.

[youli]

x265 log:
x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=2.50 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I: 2296, Avg QP:22.68 kb/s: 36715.43
x265 [info]: frame P: 45621, Avg QP:23.68 kb/s: 26433.02
x265 [info]: frame B: 170292, Avg QP:24.34 kb/s: 17242.93
x265 [info]: consecutive B-frames: 13.7% 5.6% 5.6% 23.9% 9.6% 21.4% 20.2%

encoded 218209 frames in 111542.06s (1.96 fps), 19369.20 kb/s, Avg QP:24.19
Encoding finished 10.08.2016 21:08:00,73
Settings:
--crf 23 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40
--aq-mode 3 --aq-strength 0.5 --no-sao --no-deblock --rd 3 --psy-rd 1.5
--b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5
--lookahead-slices 6 --qpstep 1 --no-strong-intra-smoothing --no-rskip

Source BD3D (left view) and x265 OverUnder:
http://s019.radikal.ru/i642/1608/80/9cd78a657fb1t.jpg (http://s019.radikal.ru/i642/1608/80/9cd78a657fb1.png) http://s019.radikal.ru/i643/1608/22/ef076ea1fb87t.jpg (http://s019.radikal.ru/i643/1608/22/ef076ea1fb87.png)
http://s020.radikal.ru/i722/1608/1c/019b8591e6e3t.jpg (http://s020.radikal.ru/i722/1608/1c/019b8591e6e3.png) http://s012.radikal.ru/i319/1608/d2/4b42916fbbc4t.jpg (http://s012.radikal.ru/i319/1608/d2/4b42916fbbc4.png)
http://s019.radikal.ru/i618/1608/df/59b00b489d20t.jpg (http://s019.radikal.ru/i618/1608/df/59b00b489d20.png) http://i053.radikal.ru/1608/06/d520ba9c69f8t.jpg (http://i053.radikal.ru/1608/06/d520ba9c69f8.png)
http://s019.radikal.ru/i635/1608/9f/83df1ea811c3t.jpg (http://s019.radikal.ru/i635/1608/9f/83df1ea811c3.png) http://i069.radikal.ru/1608/8a/b48141b93c1bt.jpg (http://i069.radikal.ru/1608/8a/b48141b93c1b.png)
http://s020.radikal.ru/i723/1608/a1/a296b21f95d0t.jpg (http://s020.radikal.ru/i723/1608/a1/a296b21f95d0.png) http://s018.radikal.ru/i505/1608/a2/aff566e08019t.jpg (http://s018.radikal.ru/i505/1608/a2/aff566e08019.png)

[RainyDog]

--crf 23 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40
--aq-mode 3 --aq-strength 0.5 --no-sao --no-deblock --rd 3 --psy-rd 1.5
--b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5
--lookahead-slices 6 --qpstep 1 --no-strong-intra-smoothing --no-rskip

Impressive results based on the comparisons. I usually encode at CRF 23 with qcomp 0.8 too as I find that higher CRF values (22-25) combined with higher qcomp gives better results than lower CRF (say 19-22) and qcomp 0.6 with most content.

But note that --psy-rdoq doesn't work with --rd 3. You need RD level 4 and above for psy rdoq to kick in.

[burfadel]

I believe changing the ipratio and bpratio too much isn't really beneficial when using CRF mode. That's why I recommended 1.28 and 1.38 respectively as the results were seemingly 'better' (cautiiously using that word on here!), however choosing anything much lower than that actually made things worse. Because it does affect everything in the encode, the small changes of 0.02 do make a difference.

[RainyDog]

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

Increase CRF. Not all content needs the same CRF value for 'equal' quality, far from it.

I'm not afraid to go up to CRF 25 or even 26 for extremely grainy content, though this is with qcomp 0.8 so in your case probably 23 or 24 at default qcomp. But even then you'll still end up with overall bitrates of 6-7mbps on occasions unless you do some pre denoising. Though personally I've always found the results of denoising undesirable whenever I've tried it, be it externally or just using x264/5's built in --nr commands.

What I do is test a couple of 5 min segments from each film first to find the suitable CRF value. Which can be anywhere from CRF 20-22 for bitrates of 2-3mbps or CRF 25-26 for bitrates of up to 6-7mbps. The average target I'm happy with is CRF 23 with qcomp 0.8 at about 4mbps so that's where I always start. If tests come in around that then away we go with the full encode. But if CRF 23 is giving me too low (say 1-1.5mbps or less) or too high (7mbps+) a bitrate then I'll adjust along the CRF scale from there.

Is obviously more effort and time but worth it for me. I also quite enjoy doing it too so... :)

[youli]

But note that --psy-rdoq doesn't work with --rd 3. You need RD level 4 and above for psy rdoq to kick in.

I'm not sure...

--rd 3 and above need for work --psy-rd (http://x265.readthedocs.io/en/default/cli.html#cmdoption--psy-rd)

and

--rdoq-level is 1 or 2 need for work --psy-rdoq (http://x265.readthedocs.io/en/default/cli.html#cmdoption--psy-rdoq)

I think rd and rdoq are independent methods. Or not?

[youli]

Source BD3D (left view) and x265 OverUnder:
http://s017.radikal.ru/i412/1608/fa/3f426035ee29t.jpg (http://s017.radikal.ru/i412/1608/fa/3f426035ee29.png) http://s019.radikal.ru/i628/1608/54/a848aa509ceft.jpg (http://s019.radikal.ru/i628/1608/54/a848aa509cef.png)
http://s019.radikal.ru/i608/1608/c9/413e05b5a5d7t.jpg (http://s019.radikal.ru/i608/1608/c9/413e05b5a5d7.png) http://s017.radikal.ru/i430/1608/64/2b9894ea5133t.jpg (http://s017.radikal.ru/i430/1608/64/2b9894ea5133.png)
http://s008.radikal.ru/i304/1608/e2/518734f53638t.jpg (http://s008.radikal.ru/i304/1608/e2/518734f53638.png) http://s020.radikal.ru/i700/1608/96/8629436f2d56t.jpg (http://s020.radikal.ru/i700/1608/96/8629436f2d56.png)
http://s014.radikal.ru/i327/1608/32/c909fb5cf3f9t.jpg (http://s014.radikal.ru/i327/1608/32/c909fb5cf3f9.png) http://s018.radikal.ru/i520/1608/42/c05f5a4658f2t.jpg (http://s018.radikal.ru/i520/1608/42/c05f5a4658f2.png)
http://s013.radikal.ru/i325/1608/53/945196b7b48et.jpg (http://s013.radikal.ru/i325/1608/53/945196b7b48e.png) http://s018.radikal.ru/i505/1608/d2/ff31ab6a803ft.jpg (http://s018.radikal.ru/i505/1608/d2/ff31ab6a803f.png)
http://s019.radikal.ru/i641/1608/5c/b4103d9816f2t.jpg (http://s019.radikal.ru/i641/1608/5c/b4103d9816f2.png) http://s013.radikal.ru/i324/1608/d1/6daa59a8c2f1t.jpg (http://s013.radikal.ru/i324/1608/d1/6daa59a8c2f1.png)

Settings: same as my sample above (http://forum.doom9.org/showthread.php?p=1776813#post1776813), just --psy-rdoq up from 2.5 to 3.0.

x265 log:
x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.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-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=3.00 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I: 1478, Avg QP:22.63 kb/s: 46945.52
x265 [info]: frame P: 26825, Avg QP:23.66 kb/s: 23953.38
x265 [info]: frame B: 89359, Avg QP:24.56 kb/s: 11553.90
x265 [info]: consecutive B-frames: 13.5% 4.1% 8.4% 35.4% 11.0% 20.4% 7.0%

encoded 117662 frames in 47406.91s (2.48 fps), 14825.35 kb/s, Avg QP:24.33
Encoding finished 11.08.2016 11:29:31,81

[brumsky]

Source BD3D (left view) and x265 OverUnder:
http://s017.radikal.ru/i412/1608/fa/3f426035ee29t.jpg (http://s017.radikal.ru/i412/1608/fa/3f426035ee29.png) http://s019.radikal.ru/i628/1608/54/a848aa509ceft.jpg (http://s019.radikal.ru/i628/1608/54/a848aa509cef.png)
http://s019.radikal.ru/i608/1608/c9/413e05b5a5d7t.jpg (http://s019.radikal.ru/i608/1608/c9/413e05b5a5d7.png) http://s017.radikal.ru/i430/1608/64/2b9894ea5133t.jpg (http://s017.radikal.ru/i430/1608/64/2b9894ea5133.png)
http://s008.radikal.ru/i304/1608/e2/518734f53638t.jpg (http://s008.radikal.ru/i304/1608/e2/518734f53638.png) http://s020.radikal.ru/i700/1608/96/8629436f2d56t.jpg (http://s020.radikal.ru/i700/1608/96/8629436f2d56.png)
http://s014.radikal.ru/i327/1608/32/c909fb5cf3f9t.jpg (http://s014.radikal.ru/i327/1608/32/c909fb5cf3f9.png) http://s018.radikal.ru/i520/1608/42/c05f5a4658f2t.jpg (http://s018.radikal.ru/i520/1608/42/c05f5a4658f2.png)
http://s013.radikal.ru/i325/1608/53/945196b7b48et.jpg (http://s013.radikal.ru/i325/1608/53/945196b7b48e.png) http://s018.radikal.ru/i505/1608/d2/ff31ab6a803ft.jpg (http://s018.radikal.ru/i505/1608/d2/ff31ab6a803f.png)
http://s019.radikal.ru/i641/1608/5c/b4103d9816f2t.jpg (http://s019.radikal.ru/i641/1608/5c/b4103d9816f2.png) http://s013.radikal.ru/i324/1608/d1/6daa59a8c2f1t.jpg (http://s013.radikal.ru/i324/1608/d1/6daa59a8c2f1.png)

Settings: same as my sample above (http://forum.doom9.org/showthread.php?p=1776813#post1776813), just --psy-rdoq up from 2.5 to 3.0.

x265 log:
x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.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-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.5 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-23.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.50 rdoq=1 psy-rdoq=3.00 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I: 1478, Avg QP:22.63 kb/s: 46945.52
x265 [info]: frame P: 26825, Avg QP:23.66 kb/s: 23953.38
x265 [info]: frame B: 89359, Avg QP:24.56 kb/s: 11553.90
x265 [info]: consecutive B-frames: 13.5% 4.1% 8.4% 35.4% 11.0% 20.4% 7.0%

encoded 117662 frames in 47406.91s (2.48 fps), 14825.35 kb/s, Avg QP:24.33
Encoding finished 11.08.2016 11:29:31,81


What's the point of using VBV with such high values? With a value of 100000 Kbps it'll almost never kick in. Plus when it does it using an extreme denoise to bring the bitrate down and blurs the shit out of it. I tried this with several test clips, it looks like shit when it kicks in. My VBV value was significantly less then yours on purpose, 4096 - 4608. My test clips are intentional noisy.

Your encodes are not even coming close to the limit you have set.

They do look great by the way!

Also, do you think subme 7 is necessary? the Placebo preset only goes up to 5. I've also read that me-range star is optimized more than umh...

[brumsky]

Increase CRF. Not all content needs the same CRF value for 'equal' quality, far from it.

I'm not afraid to go up to CRF 25 or even 26 for extremely grainy content, though this is with qcomp 0.8 so in your case probably 23 or 24 at default qcomp. But even then you'll still end up with overall bitrates of 6-7mbps on occasions unless you do some pre denoising. Though personally I've always found the results of denoising undesirable whenever I've tried it, be it externally or just using x264/5's built in --nr commands.

What I do is test a couple of 5 min segments from each film first to find the suitable CRF value. Which can be anywhere from CRF 20-22 for bitrates of 2-3mbps or CRF 25-26 for bitrates of up to 6-7mbps. The average target I'm happy with is CRF 23 with qcomp 0.8 at about 4mbps so that's where I always start. If tests come in around that then away we go with the full encode. But if CRF 23 is giving me too low (say 1-1.5mbps or less) or too high (7mbps+) a bitrate then I'll adjust along the CRF scale from there.

Is obviously more effort and time but worth it for me. I also quite enjoy doing it too so... :)

Thanks Rainydog, that's what I've been doing. Just thought there might be another way.

I did mess with VBV and the results look like shit. Seriously, blurry and very ugly! I'd much rather let the bitrate spike then enable VBV haha!

[RainyDog]

I'm not sure...

--rd 3 and above need for work --psy-rd (http://x265.readthedocs.io/en/default/cli.html#cmdoption--psy-rd)

and

--rdoq-level is 1 or 2 need for work --psy-rdoq (http://x265.readthedocs.io/en/default/cli.html#cmdoption--psy-rdoq)

I think rd and rdoq are independent methods. Or not?

Sorry, I wasn't entirely clear. It's RD=4 or above that you need to set for --psy-rdoq to be active. At RD=3 or below psy-rdoq is disabled even if you set a value for it.

[RainyDog]

Thanks Rainydog, that's what I've been doing. Just thought there might be another way.

I did mess with VBV and the results look like shit. Seriously, blurry and very ugly! I'd much rather let the bitrate spike then enable VBV haha!

Well I set a vbv maxrate and buffer size too brumsky but can't say I've ever noticed any nasty looking frames because of it. I've seen bitrates spike way higher than the source at 1080p with qcomp 0.8 otherwise.

[youli]

@brumsky
Encoder enabling VBV automatically if level-idc and tier has been specified. I have nothing to do with this.
UMH is a very good choice for x264, so maybe for x265 too :)
STAR works slowly just like ESA or TESA for x264.
For x264 I always use subme 11, for x265 only 7.. why not? probably it is the compensation for "no-weightp" and "no-weightb".

Sorry, I wasn't entirely clear. It's RD=4 or above that you need to set for --psy-rdoq to be active. At RD=3 or below psy-rdoq is disabled even if you set a value for it.
Where can i read about it? thanks.

[LigH]

@ brumsky:

What's the point of a space wasting fullquote (including all images)? Please try to reduce the quoted part to the relevant part...

But the warning starts one line above. CRF combined with a decoder level would require a VBV limitation which may not be present in the command line. So it appears to be not specifically optimized for consumer players.

[Motenai Yoda]

Sorry, I wasn't entirely clear. It's RD=4 or above that you need to set for --psy-rdoq to be active. At RD=3 or below psy-rdoq is disabled even if you set a value for it.

as the umpteenth time NO rd 4 is the SAME as rd 3
rdoq is disabled (rdoq-level 0) on any preset lower than slow and enabled (rdoq-level 2) on slow and higher

[burfadel]

Does it work off the base profile people select, or as a result of another setting? With just the settings I listed, in fact even with much fewer settings it works. Based on what you just said it would suggest x265 is broken for allowing it and having it work effectively!

[brumsky]

Well I set a vbv maxrate and buffer size too brumsky but can't say I've ever noticed any nasty looking frames because of it. I've seen bitrates spike way higher than the source at 1080p with qcomp 0.8 otherwise.

That would make sense given how high you have VBV set. Try just for shits and giggles setting it to something like 10000.

This is from the x265 docs.

Note that when VBV is enabled (with a valid --vbv-bufsize), VBV emergency denoising is turned on. This will turn on aggressive denoising at the frame level when frame QP > QP_MAX_SPEC (51), drastically reducing bitrate and allowing ratecontrol to assign lower QPs for the following frames. The visual effect is blurring, but removes significant blocking/displacement artifacts.

[qtwigg]

Hello everyone.

Has any one been experiencing off colours?
Seems to have been happening since 2.0

Problem 1
Source
https://is04.ezphotoshare.com/2016/08/09/cgeqe.png
Encode
https://is04.ezphotoshare.com/2016/08/09/cXV1D.png

Problem 2
Source
https://cdn.discordapp.com/attachments/213375923263635456/213547910661406720/Source_2.png
Encode
https://cdn.discordapp.com/attachments/213375923263635456/213548512997015552/aq3_deblock.mkv.0000.png
Other methods tried
Encode
https://cdn.discordapp.com/attachments/213375923263635456/213549774794653706/Main422-intra.mkv.0000.png
Encode
https://cdn.discordapp.com/attachments/213375923263635456/213550171194261504/Merange.mkv.0000.png
Encode
https://cdn.discordapp.com/attachments/213375923263635456/213563397797707776/main444-10.mkv.0000.png

Problem 3
Source
https://is03.ezphotoshare.com/2016/08/11/i1z2n.png
Encode
https://is04.ezphotoshare.com/2016/08/11/i10A1.png

The following info pertains to problem 2 only, prob 1 and 3 have very much similar settings, but we focused on problem 2 mainly.
This is the basic Command line we used :
--ctu 32 --max-tu-size 16 --weightb --lookahead-slices 0 --preset veryslow --crf 19 --profile main10 --rd 5 --limit-refs 3 --no-rect --no-amp --no-limit-modes --aq-mode 3 --subme 5 --me 3 --bframes 8 --rc-lookahead 80 --ref 6 --no-strong-intra-smoothing --no-constrained-intra --high-tier --rdoq-level 1 --psy-rd 0.8 --psy-rdoq 7.0 --no-sao --deblock -1:-1 --qcomp 0.7 --cbqpoffs -3 --crqpoffs -3

The Variations I've tried go like this, I used the same above template of settings and then tried various variations of each setting one a time... :

aq-mode 2,3 (found 3 to be better for overall detail)
psyrdoq 2,5,7
psy-rd 0.5,0.8,1.1
cb and cr offsets 0:0,-3:-3,-4:-4,-6:-6
merange 57,80,120 (slight improvement in 80 for the color thing)
profiles main10,main422-10-intra,main422-10,main444-10,mian444-10-intra (some of it was better in 422 chroma subsampling)
deblock -1:-1,-2:-2,-3:-3

Thinking maybe it was the AviSynth Filter's fault I tried DirectShowSource, FFMS2 and LAV but the problem persisted still.

The main issue : In certain regions of the encodes the Greens are stronger than the source and the Reds and Blues are lighter than the source... Leading to certain dark shades to become brighter infecting even the details in some regions....

:)

[LigH]

The usual "first guess without looking" will probably be a wrong colorimetry (Rec.601 vs. Rec.709)... not sure if they should be explicitly flagged with CLI options.

BTW, showing such huge images inline hurts the readability of your post, thumbnails with links to the originals would have been sufficient.

[littlepox]

How did you convert these video to RGB screenshots?

[Jamaika]

@littlepox normally
ffmpeg.exe -i "image%%003d.png" -f yuv4mpegpipe -s 1920x1080 -c:v wrapped_avframe -pix_fmt yuv420p - | x265 ...
ffmpeg.exe -i input.mts -f image2 -c:v png -ss 00:00:00.xxx -frames:v 1 -pix_fmt rgb24 "image001.png"
ffmpeg.exe -i input.mts -f image2 -c:v png -ss 00:00:00.xxx -t 00:00:00.yyy -frames:v 100 -pix_fmt rgb24 "image%%003d.png"

The main issue : In certain regions of the encodes the Greens are stronger than the source and the Reds and Blues are lighter than the source... Leading to certain dark shades to become brighter infecting even the details in some regions....
Sources are slightly brighter.
In Example 3 is difficult to determine. Frames disagree. There is a considerable loss of sharpness on the headscarf. Colormatrix on the appearance of images on the PC isn't affected because it is "undef". Unfortunately this erroneous way of conceiving. Change to bt709 because it is a standard. Otherwise it is more yellow.

Edit:
When we convert using ffmpeg with rgb24 to yuv420p is always changing color_range. The film is faded. To align the gamma must be -vf scale=out_color_matrix=bt709:out_range=full:flags=lanczos+accurate_rnd+full_chroma_int+full_chroma_inp

[kolak]

"-vf scale=out_color_matrix=unspecified:"

means Rec.601 by the default is used and this is not what you want for HD.

Are your PNGs really full range or YUV range?

you definitely need out_color_matrix=bt709 and establish correct range in your PNGs.
Other than this I would not use ffmpeg for conversion from RGB to YUV. Swscale seams to be buggy and I would do such a thing in avisynth or vapourysnth where you have access to very good and precise conversion engines, e.g. fmtconv.

[Jamaika]

Are your PNGs really full range or YUV range?
According my opinion it is needed. Examples:
https://www.sendspace.com/filegroup/iYDGoDc0s7Nmv%2F9A5l2PkzVEmDXSPHpJ

[qtwigg]

Hello everyone,

I am sorry for the humongous pics, that was my first posting and was not aware.

Thank you for the replies but we misunderstood each other. Those screens are basic screenshots, PNGs lossless 32bit, made with Video Thumbnails Maker Platinum 9.0. All I did was screen compares with my output v input. I feel my encoded screenshot has off colours, so I played around with my command line and I think I posted all the needed info of what I tried.

Any advice/feedback and criticism is greatly appreciated.

Thanks.

[mandarinka]

Yeah, that looks like bt709/bt601 mismatch to me too (which means, the problem is not in encoding, but in the conversion to RGB). Swscale in FFmpeg likely uses bt601 by default, it is not the only problem with it.

I would stay away from it also for the reason that it only does nearest neighbour chroma upsampling unless you give it some arcane flags that are impossible to memorize (and dunno if even exposed from CLI).

[youli]

I adjusted some settings (as compared with my sample above (http://forum.doom9.org/showthread.php?p=1776850#post1776850)) for better preserve grain at the dark scenes.
--crf 23.5 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40 --aq-mode 3 --aq-strength 0.4
--no-sao --no-deblock --rd 3 --psy-rd 1.7 --b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 --lookahead-slices 6 --qpstep 1
--no-strong-intra-smoothing --no-rskip --no-cutree
Source BD3D (left view) and x265 OverUnder:
http://s020.radikal.ru/i707/1608/ce/5ddc9b3260bft.jpg (http://s020.radikal.ru/i707/1608/ce/5ddc9b3260bf.png) http://s09.radikal.ru/i182/1608/26/548f323a25bdt.jpg (http://s09.radikal.ru/i182/1608/26/548f323a25bd.png) http://s018.radikal.ru/i506/1608/dd/2a1db3864aect.jpg (http://s018.radikal.ru/i506/1608/dd/2a1db3864aec.png) http://s019.radikal.ru/i623/1608/e8/256d36ede1ebt.jpg (http://s019.radikal.ru/i623/1608/e8/256d36ede1eb.png)
http://s019.radikal.ru/i642/1608/65/e25430d7e8c3t.jpg (http://s019.radikal.ru/i642/1608/65/e25430d7e8c3.png) http://s017.radikal.ru/i415/1608/d2/31a0caaa0eddt.jpg (http://s017.radikal.ru/i415/1608/d2/31a0caaa0edd.png) http://s16.radikal.ru/i190/1608/5f/26c66574fccdt.jpg (http://s16.radikal.ru/i190/1608/5f/26c66574fccd.png) http://s017.radikal.ru/i403/1608/b0/840e6786eb57t.jpg (http://s017.radikal.ru/i403/1608/b0/840e6786eb57.png)
http://s018.radikal.ru/i524/1608/b8/ee0ea2b91420t.jpg (http://s018.radikal.ru/i524/1608/b8/ee0ea2b91420.png) http://s017.radikal.ru/i405/1608/58/4ac002940fe8t.jpg (http://s017.radikal.ru/i405/1608/58/4ac002940fe8.png) http://s010.radikal.ru/i312/1608/b5/6b68f001c15ft.jpg (http://s010.radikal.ru/i312/1608/b5/6b68f001c15f.png) http://s017.radikal.ru/i422/1608/0f/273659fa73e2t.jpg (http://s017.radikal.ru/i422/1608/0f/273659fa73e2.png)

x265 log:
x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.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-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.4 / 32 / 0
x265 [info]: Rate Control / qCompress : CRF-23.5 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.70 rdoq=1 psy-rdoq=2.50 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I: 2013, Avg QP:21.57 kb/s: 27922.65
x265 [info]: frame P: 37388, Avg QP:22.69 kb/s: 16473.71
x265 [info]: frame B: 131623, Avg QP:22.75 kb/s: 10242.93
x265 [info]: consecutive B-frames: 13.3% 5.7% 6.5% 30.0% 11.6% 18.3% 14.6%

encoded 171024 frames in 72336.41s (2.36 fps), 11813.15 kb/s, Avg QP:22.73
Encoding finished 14.08.2016 5:48:22,71

@brumsky
What's the point of using VBV with such high values? With a value of 100000 Kbps it'll almost never kick in...
Example to your question about VBV. See peak bitrate in the green rectangle at the picture below (about 67 Mbps), and average bitrate for this video is about 8 Mbps only.
http://s41.radikal.ru/i091/1608/55/d37738d2c4f9t.jpg (http://s41.radikal.ru/i091/1608/55/d37738d2c4f9.png)

[burfadel]

I adjusted some settings (as compared with my sample above (http://forum.doom9.org/showthread.php?p=1776850#post1776850)) for better preserve grain at the dark scenes.
[CODE]--crf 23.5 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40 --aq-mode 3 --aq-strength 0.4
--no-sao --no-deblock --rd 3 --psy-rd 1.7 --b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 --lookahead-slices 6 --qpstep 1
--no-strong-intra-smoothing --no-rskip --no-cutree

Mixing ultra fast preset with slow settings? It's a bit askew. Although I don't believe ip and pb ratio's are tweaked ideally (I found 1.28 and 1.38 ideal), setting them as low as you have throws everything else out, as you are still targeting a specific CRF. Setting things like psy-rdoq too high just disproportionally increases bitrate used, you could probably get better results with the same file size using a lower CRF and lower psy-rdoq settings.

[youli]

@burfadel
Ultrafast preset need to disable a harmful options for encoding speed :)
--psy-rdoq 2.5 minimizes the grain blurring effect of dark areas (here (http://forum.doom9.org/showthread.php?p=1776850#post1776850) it was even 3.0) and --aq-strength down to 0.4 too. This video has rate factor 0.116 [ 'Bits-per-second' / ('Pixels-per-frame' * 'frame-rate') ], I think it a very good compression, is really need more... 0,08 or 0,05? ;)
In this case need to use full 2 pass encode instead CRF and up "Avg QP for frame B" to 27-28.

Also you can see grain tune http://x265.readthedocs.io/en/latest/presets.html#film-grain

[Motenai Yoda]

See peak bitrate in the green rectangle at the picture below (about 67 Mbps), and average bitrate for this video is about 8 Mbps only.
vbv works on an interval of 1 sec, peak bitrate can be of only 1 frame (1/fps second), so you can still get 67Mbps with vbv on 10Mbps
btw 67Mbps is still pretty less than 100Mbps, better don't use vbv and level at all if you don't want any vbv degradation

[benwaggoner]

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

How about just "--crf 20 --profile main10 --preset slower --tune grain" and see how that goes. You're doing a lot of stuff to preserve sharpness, and preserving sharpness in content with a lot of random noise means really high bitrates. With tune grain you can get more preservation of the texture with rate control. So lower bitrates get a little more DCT-ish, but you don't lose the grain or get grain strobing or variance across a frame. You'd probably want to start out with the rest of your tuning (even CRF), since you're starting from a very different place, a lot of stuff doesn't apply any more, and you've got --rc-grain on. The downside is that tune grain turns off all sorts of nice psychovisual stuff, so clean scenes will use a higher bitrate for the same perceptual quality. But if the whole title is mostly noisy, give it a shot.

Setting --vbv-bitrate and --vbv-maxrate to what you want the sane values to be is also a good option. The grainy scenes might not look quite as good, but at the same ABR, the rest of the encode could look a lot better.

And in general, don't expect to see huge file size savings from x265 with content with a lot of random noise. Entropy is entropy. The cleaner the content, the more x265 can do beyond older codecs.

[plane]

Quick question, why does x265 preset doesn't make use of b-adapt 1(fast)?
All presets either use 0(none) or 2(full). Is there anything wrong with 1(fast)?

In my experiences, x265 B-frame is much more mature and good quailty compared to x264, the same is cutree(mbtree in x264). They have start from scratch and rewrite the code.

B-adapt=1 meant to be carefully to use b frames while B-adapt=2 will use whole lots more. I mostly encode real live action video and in the past, I always need to use B-adapt=1 or disable B frames(mbtree is always off too in x264) to get constant quality and less artifacts.

In x265 I found in most cases, B-adapt=2 and cutree=1 is doing good. Only for some really bad shooted real live video, however, disable b frames and cutree still offer overall better quality.

[plane]

"speed" certainly x264.
-
benefit cost (quality + size) = x265 .

I would like to say speed might be on x265 side now. After 2.0 the qualty and speed been improved. I only need to run medium or slow preset and always return me an excellent quailty video, encoding time should still 2x~3x more but file size cut in half and yield better quality.

The most goodies is saved me a lots of testing time bcoz x265 offers a more constant quality and I don't need to do many pre-encoding for any of my important videos which is very time consuming to try every possible options to get the best or balanced quality out, saved me like 10x time here.

[plane]

I went back and played with x264 a bit and I'm shocked to see the quality difference is far more noticeable then I ever remember. I know my tests weren't apples to apples but I tried x265 medium vs x264 slow + slower. In both cases x265 quality was noticeable better even when in motion.

My question, is x265 worth it has been answered! :)


I'm really shocked too when I tried x265 now. My last post on doom9 is like year 2008 ...lol... and after that x264 started mature so I don't go here often again(I don't have as much videos to encode like you guys here, just little random real live action vid stuffs).

I think the current stage of x265 is almost the same x264 in the year 2008 around. Low and medium bitrate should win easily and x264 only better at very high bitrate to keep grains, pretty much the same situation in the old day as x264 vs Xvid.

But things is a bit different here. x264 is a very success codec and being used widely as opposite Xvid was only a toy like codec(mainstream still using MPEG-2 at that time). So, it will take longer time for x265 to replace x264 and I don't see many guys talking x265 on net bcoz people generally still very satisfied with H264.

[Magik Mark]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

[plane]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

By default, x265 been removed quite a lots of grain. If you really need it during encoding, either increase deblock filter level or use a relatively low preset(will throw more noise/grain) should help but the best way always is running an external filter before you encode it, x265 isn't a denoise/grain filter.

[Motenai Yoda]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

You can try using --nr-intra and --nr-inter whose cut high frequencies detail in and between frames

[Magik Mark]

You can try using --nr-intra and --nr-inter whose cut high frequencies detail in and between frames



Thanks. What would be an ideal value for light, moderate and heavy for startup?


Sent from my iPhone using Tapatalk

[plane]

Thanks. What would be an ideal value for light, moderate and heavy for startup?


Sent from my iPhone using Tapatalk

Seriously, no one would like to use encoder acting as a filter on doom9. If you are new to encoding stuffs, why not use StaxRip to encode x265? Just click on Filters menu and there are some denoise/grain filter available.

[burfadel]

Seriously, no one would like to use encoder acting as a filter on doom9. If you are new to encoding stuffs, why not use StaxRip to encode x265? Just click on Filters menu and there are some denoise/grain filter available.

It's an extremely light denoiser, if you want to actually denoise a noisy clip using avisynth filters makes sense. However, if you would like to remove just a tad amount of noise without actually impeding on the picture too much, it's useful. In CRF mode you can lower the CRF a bit and maintain a similar file size, the end result can actually be a better picture.

[JohnLai]

In my experiences, x265 B-frame is much more mature and good quailty compared to x264, the same is cutree(mbtree in x264). They have start from scratch and rewrite the code.

B-adapt=1 meant to be carefully to use b frames while B-adapt=2 will use whole lots more. I mostly encode real live action video and in the past, I always need to use B-adapt=1 or disable B frames(mbtree is always off too in x264) to get constant quality and less artifacts.

In x265 I found in most cases, B-adapt=2 and cutree=1 is doing good. Only for some really bad shooted real live video, however, disable b frames and cutree still offer overall better quality.

For animation material, B-adapt=1 only make use up to 6 B-frames for most of time while B-adapt=2 generally can allocate up to 16 B-frames.
The only problem, B-adapt=2 with 16 B-frames cause 30-50% decrease in encoding fps with only 20% better space efficiency.

[burfadel]

I guess for animation you could increase the b-frame bias a bit. By doing so you could have a much greater number of b-frames. Between around 7 b-frames and 16 b-frames on normal bias, I doubt there would be a 20 percent efficiency increase.

[brumsky]

How about just "--crf 20 --profile main10 --preset slower --tune grain" and see how that goes. You're doing a lot of stuff to preserve sharpness, and preserving sharpness in content with a lot of random noise means really high bitrates. With tune grain you can get more preservation of the texture with rate control. So lower bitrates get a little more DCT-ish, but you don't lose the grain or get grain strobing or variance across a frame. You'd probably want to start out with the rest of your tuning (even CRF), since you're starting from a very different place, a lot of stuff doesn't apply any more, and you've got --rc-grain on. The downside is that tune grain turns off all sorts of nice psychovisual stuff, so clean scenes will use a higher bitrate for the same perceptual quality. But if the whole title is mostly noisy, give it a shot.

Setting --vbv-bitrate and --vbv-maxrate to what you want the sane values to be is also a good option. The grainy scenes might not look quite as good, but at the same ABR, the rest of the encode could look a lot better.

And in general, don't expect to see huge file size savings from x265 with content with a lot of random noise. Entropy is entropy. The cleaner the content, the more x265 can do beyond older codecs.

Thanks I'll give it a try and let you know!

[plane]

It's an extremely light denoiser, if you want to actually denoise a noisy clip using avisynth filters makes sense. However, if you would like to remove just a tad amount of noise without actually impeding on the picture too much, it's useful. In CRF mode you can lower the CRF a bit and maintain a similar file size, the end result can actually be a better picture.

Those --nr-intra and --nr-inter will slightly softed the picture but it's a good light denoiser for fastest speed with minimal impact. Personally, I prefer external denoiser bcoz they've got more options to tweak or fft3dfilter for the best quality.

x265 by default been removed quite a lots of grain/noise. I've got some bad shooted real live action video and I don't think I need any denoiser again unlike x264. Completely rip off all grain/noise should futher improve the compression efficiency but may lead to worse visual quality like too much flat area or blocks.

[plane]

For animation material, B-adapt=1 only make use up to 6 B-frames for most of time while B-adapt=2 generally can allocate up to 16 B-frames.
The only problem, B-adapt=2 with 16 B-frames cause 30-50% decrease in encoding fps with only 20% better space efficiency.

It is normal. The higher the value the smaller improvement you got and will increase encode/decode time, pretty much same for all other encoding options.

[burfadel]

Those --nr-intra and --nr-inter will slightly softed the picture but it's a good light denoiser for fastest speed with minimal impact. Personally, I prefer external denoiser bcoz they've got more options to tweak or fft3dfilter for the best quality.

x265 by default been removed quite a lots of grain/noise. I've got some bad shooted real live action video and I don't think I need any denoiser again unlike x264. Completely rip off all grain/noise should futher improve the compression efficiency but may lead to worse visual quality like too much flat area or blocks.

That's why I believe it shouldn't be used by itself. Because it does save a little bitrate I think upping the psy-rdoq (if it's any higher than around 1.28 I found it's not worth upping), or lowering the CRF by a couple of decimal points, you can put that saved bitrate to use elsewhere.

[Magik Mark]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

[LigH]

Once again the same question, already answered several times...

The parallelizability of the HEVC algorithm in general (not specific to x265 as encoder implementation) is limited. There are several steps which have to be finished before other steps can start calculations. These intermediate results make some threads wait for others. This is more obvious when a slower preset takes more efforts. Spending more threads on only one video would be counterproductive, as each thread would then have a more limited scope on smaller parts of the video, reducing the efficiency.

If you have a high number of available cores, the best way to utilize them well is running several instances of the encoder in parallel.

[Magik Mark]

Thank you. My apologies for any redundancy


Sent from my iPhone using Tapatalk

[microchip8]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

have you tried --pme and --pmode ?

[burfadel]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

What resolution are you encoding to?

[benwaggoner]

have you tried --pme and --pmode ?
Pmode seems very likely to help. With 28 threads, pme isn't likely to be much help except with VERY low resolution and frame threading off.

[Magik Mark]

What resolution are you encoding to?



1080p


Sent from my iPhone using Tapatalk

[tebugg]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

[MeteorRain]

abr can almost never beat crf or 2pass. I'd say it's pretty stable on file size when encoding similar contents. So just stick with a good crf number for multiple movies would be a better idea.

[Jamaika]

if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12?
I shouldn't answer, because I'm lost in this thread who wants what.
My guess is that you're thinking about movies FullHD 25-30fps, I don't know only whether the memory stick or bluray. If memory stick is what a impediment ±100MB. There are calculators that calculate of the size file. Maxbitrate and buffer adjusted to the capabilities TV
I wouldn't complain about the ABR. The Speed encoding depends on the processor. More worried banding.
http://3.bp.blogspot.com/-peXsHThHJTk/VAnfLQCGEKI/AAAAAAAABI8/KF8YopmsLj4/s1600/SD%2BCard%2BTypes.PNG

[plane]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

Put it simple. abr(average bitrate) is more likely a constant bitrate. If you use ultra high bitrate(not 5000kb that's small) and prefer a very constant overall picture quality for special reasons, then it's good. If you don't have enough bitrate, crf is better.

crf is variable bitrate and only depened by given quality and the complexity of the source, it won't care about file size. 2pass is also variable bitrate but very stricted by file size manner, if file size limitations is your concern you should use 2pass with --no-slow-firstpass to enable first pass turbo mode.

[JohnLai]

Just asking...does x265 already adapt x264 new b-adapt=1 algorithm code?

http://git.videolan.org/?p=x264.git;a=commitdiff;h=aa26e880bc2cd04cc81c776051d5e21d03fc975a
Changelog
Roughly the same speed as before but with significantly better results,
comparable to --b-adapt 2.

[plane]

Just asking...does x265 already adapt x264 new b-adapt=1 algorithm code?

http://git.videolan.org/?p=x264.git;a=commitdiff;h=aa26e880bc2cd04cc81c776051d5e21d03fc975a
Changelog
Roughly the same speed as before but with significantly better results,
comparable to --b-adapt 2.

There is no need to do that. x265 b frames got better quality and it's safe to use adapt 2 all times.

x264 b frames isn't mature in my opinions, more safely to use adapt 1.

[Jawed]

I've got live action video (688p) encoded using crf 24 and:

--preset very slow --output-depth 10 --merange 38

which causes moving water to be rendered with a glitchy motion.

This preset enables eight B frames. Cutting the video to just a few seconds (the water is shown for about 130 frames) produces:

consecutive B-frames: 11.5% 0.0% 11.5% 11.5% 7.7% 3.8% 3.8% 50.0% 0.0%

If I change the preset to slow, the problem is significantly reduced:

consecutive B-frames: 8.1% 8.1% 8.1% 18.9% 56.8%

Additionally, if I change the encode to:

--preset very slow --output-depth 10 --merange 38 --bframes 4

I get:

consecutive B-frames: 7.7% 17.9% 7.7% 12.8% 53.8%

which solves the problem.

Alternatively, instead of setting --bframes, I have to reduce crf to about 20 before the water stops being glitchy.

So my question: apart from setting -bframes to 4, is there another way to control this behaviour, making x265 less likely to over-use B-frames in a situation like this?

[Motenai Yoda]

Put it simple. abr(average bitrate) is more likely a constant bitrate. If you use ultra high bitrate(not 5000kb that's small) and prefer a very constant overall picture quality for special reasons, then it's good. If you don't have enough bitrate, crf is better.
Nope abr try to arrange datarate around the average value imposed.
It don't give a more constant picture quality than crf, and for sure isn't nearby as a constant bitrate, indeed is a variable bitrate mode.

[microchip8]

x264 b frames isn't mature in my opinions, more safely to use adapt 1.

Bullshit. Got any empirical evidence to back up that claim? And no, "it doesn't look good to me" is not empirical evidence. x264 is a tried-and-tested-in-all-aspects encoder, one of the best around. if it had any B-frames issues, it will suffer quality-wise too and devs will fix it long time ago

[RainyDog]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

Tebugg, I always run a quick and dirty CRF encode with x264 first to find out the approx CRF value for my archival x265 encode.

Using me=hex, subme=2 or 3, trellis=0 for speed but keeping other parameters such as number of b-frames, lookahead values, qcomp, weight-p and b etc. the same as my x265 settings to keep things as similar on paper as I can between the two. With those settings, I can get anywhere between 20-35fps on my i7 3770k depending on input and output bitrate. So rarely takes much longer than realtime really.

The majority of the time, the bitrate of my archival x265 encode ends up within +/-20% of the x264 test encode at the same CRF.

[plane]

Bullshit. Got any empirical evidence to back up that claim? And no, "it doesn't look good to me" is not empirical evidence. x264 is a tried-and-tested-in-all-aspects encoder, one of the best around. if it had any B-frames issues, it will suffer quality-wise too and devs will fix it long time ago

No doubt it's only my opinion but I don't think I'm talking bullshit really. x264 b frames done his job but x265 just much more improved in this area. I don't see any conflict or against to x264.

[plane]

I've got live action video (688p) encoded using crf 24 and:


Live action video is very sensitive to b frames, that's what I said x264 b frames isn't as mature as x265 in previous reply. In x264, I usually need to set adapt 1 or disable b frame for live action video. And in x265, yes I'm using four b frames too.

If you still want to use eight b frames, you can set the pbratio to 1.0 or 1.1 should solve the problem but greatly reduced the efficiency of b frames.

[brumsky]

Has anyone messed with --bframe-bias?

I've been considering increasing the bias to get more b frames, hopefully consecutively. The idea being instead of using 8 bframes, just increase the bias to use more in general.

I currently use 6 bframes and see that 3 & 6 bframes general have the highest percentage. I'd like to see something like 5 & 6 consecutive bframes be the highest, for example.

thoughts?

This is from the docs.


--bframe-bias <integer>
Bias towards B frames in slicetype decision. The higher the bias the more likely x265 is to use B frames. Can be any value between -90 and 100 and is clipped to that range. Default 0

[microchip8]

No doubt it's only my opinion but I don't think I'm talking bullshit really. x264 b frames done his job but x265 just much more improved in this area. I don't see any conflict or against to x264.

Stop talking BS about maturity of b-frames in x264, which are very well implemented. What you're talking about is where x264 is placing them, according to b-adapt 1 or 2

[benwaggoner]

The majority of the time, the bitrate of my archival x265 encode ends up within +/-20% of the x264 test encode at the same CRF.
Do you find reliable equivalent quality with the same CRF between x264 and x265? What CRF values and what sort of content are you testing with?

[tebugg]

so if i do the normal 2pass on medium setting way with these as my settings:

--profile main10 --no-sao --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --merange 44 --weightb --aq-mode 2 --aq-strength 1.0 --rd 4 --psy-rd 1.5 --psy-rdoq 3 --rdoq-level 1 --weightp --qcomp 0.8 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

the total time for both passes ends up taking me about 10 hours. i am encoding from 1080p retail bluray source. i have an i7-3770k overclock to 4.5ghz that runs with no issue with cores @ 100% for 10 hours straight. i was tinkering around with the 1pass 2pass setting in megui. i was thinking if i took the x264 approach of lowering settings to get a fast first pass then my own settings on the 2nd pass, how would the quality look. so i lowered the preset to ultrafast for the first pass and only set these in the command line for the first pass:

--profile main10 --no-sao --no-strong-intra-smoothing --ctu 32 --max-tu-size 16 --qg-size 16 --no-rect --no-amp

i get 26-28 fps in the first pass that way. in the second pass i have these as my settings with the preset still on ultrafast:

--profile main10 --no-sao --me 2 --subme 4 --weightb --b-adapt 2 --rd 4 --aq-mode 2 --rc-lookahead 20 --merange 44 --ref 3 --qcomp 0.8 --psy-rdoq 3 --rdoq-level 1 --no-strong-intra-smoothing --psy-rd 1.50

i've done 2 10min clips of 2 diff movies. i must say the quality of them is looking really good. the reason why i keep the second pass at ultrafast is because x265 will error on the second pass if you change the b or p frames number. those 2 have to be the same as the first pass. any other settings you can crank up for the 2nd pass. with this method i'm getting a full movie encode of around 6 hours. much better than 10 hours. i've ran 10min clips of the same frames for the regular 2pass setting and the 1pass 2pass i am doing to see if i notice any quality diffference. to be honest it's hard for me to tell the difference. i have an untrained eye. and even when i pause the clips frame for frame they still look the same to me as far as blocking goes and grain and quality.

have any of you played around with x265 1pass 2pass in this way? if so what were your results?

[plane]

Stop talking BS about maturity of b-frames in x264, which are very well implemented. What you're talking about is where x264 is placing them, according to b-adapt 1 or 2

It is doing fine for anime or movie, not live action video at least in my own opinions. You stop BS, there is no such perfect encoder in the world. If your concept is correct of x264 is already the best encoder for human being that can be achieved, we won't need x265 or any other improvement now. Like I have said it, x264 done his job but x265 just improved. I don't see any wrong here, if you just so love x264 plz leave x265 board.

[LigH]

HEVC is not just "an improvement of AVC", it is a whole new generation with a magnitude higher complexity. Experiences from the x264 development may or may not get adapted easily for the x265 development, differences in the algorithms may require substantially different approaches sometimes. I am no developer, I can't tell you how much B-frame decisions are similar... But I can tell you that personal insults are not welcome here, according to the forum rules.

[microchip8]

It is doing fine for anime or movie, not live action video at least in my own opinions. You stop BS, there is no such perfect encoder in the world. If your concept is correct of x264 is already the best encoder for human being that can be achieved, we won't need x265 or any other improvement now. Like I have said it, x264 done his job but x265 just improved. I don't see any wrong here, if you just so love x264 plz leave x265 board.

I'm not implying nor did I ever mention x264 was perfect, but it is one of the best around. I'm saying that the b-frames implementation in x264 is just fine and has no "immaturity" issues. B-frames are very well implemented. You don't have to take my word on this, look at the code yourself

What you don't seem to get is that you're confusing yourself with the implementation of b-frames (calling them "not mature") but the actual issue lies in where x264 choose to use them, which can be controlled with b-adapt among others

so in the end you're mixing the b-frames implementation with b-frames placement decision, but you blame the b-frames implementation itself not the placement algorithm. Those are two different things, even if they are very much related

[yup]

Hi all!
I am testing x265 for my VHS capture archive and I can speak that x265 save half space without quality degradation if comparing to x264.
I am deinterlace source (720x576i 25) and upscale to 960x720p 50, picture not sharp.
May be exist special approach for choose some setting?
yup.

[LigH]

@ froggy1 + plane:

In other words:

a) There is an algorithm to encode B frames in general. This implementation appears to be technically correct.

b) There is an algorithm to decide when to use a B frame in the video stream. This implementation appears to be improvable, more or less subjectively.

Am I correct here?
__

@ yup:

VHS is not sharp anyway. And upscaling it further... depends already on the deinterlacing / bobbing filter you used. Possibly QTGMC? You may combine that with an EDI algorithm (upscaling with edge directed interpolation, usually by powers of 2 as factor, then downscaling to the desired final resolution with usual resizers).

But this is not a matching question in this thread, because it is not related to details of the x265 encoder. This topic fits better in the "AviSynth usage" subforum.

[yup]

[QUOTE=
@ yup:

VHS is not sharp anyway. And upscaling it further... depends already on the deinterlacing / bobbing filter you used. Possibly QTGMC? You may combine that with an EDI algorithm (upscaling with edge directed interpolation, usually by powers of 2 as factor, then downscaling to the desired final resolution with usual resizers).

But this is not a matching question in this thread, because it is not related to details of the x265 encoder. This topic fits better in the "AviSynth usage" subforum.[/QUOTE]

Ligh! Small misunderstanding!
I am interesting for X265 setting for encoding my source (not script writing), because one have some specific. Now I am using preset only and increase quntity B frames up to 10, because footage is lecture with static background.
May be some advice?
yup.

[Barough]

x265-v2.0+16-215eedc9ecc0 (http://www102.zippyshare.com/v/Ac0Mki24/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[microchip8]

@LigH

yes, you are correct. it's also the reason why b-adapt=1 was recently improved in latest x264. There's nothing to improve in the b-frames implementation as it's decently done. b-adapt (especially, b-adapt=1) was suboptimal and that's what the devs improved recently. So you can't blame b-frames being "not mature" while in fact you're talking about the decision x264 uses when to use them

[JohnLai]

@LigH

yes, you are correct. it's also the reason why b-adapt=1 was recently improved in latest x264. There's nothing to improve in the b-frames implementation as it's decently done. b-adapt (especially, b-adapt=1) was suboptimal and that's what the devs improved recently. So you can't blame b-frames being "not mature" while in fact you're talking about the decision x264 uses when to use them

Which is why I asked if x265 already adapted the newer b-adapt=1 code.....b-adapt=2 is too slow at determining 16 bframes placement although it is better.

[LigH]

x265 2.0+16-215eedc9ecc0 (GCC 5.3.0) (https://www.mediafire.com/download/lk6kgl89b353duw/x265_2.0+16-215eedc9ecc0.GCC530.7z)
x265 2.0+16-215eedc9ecc0 (GCC 6.1.0) (https://www.mediafire.com/download/27oehkyfh7d51lk/x265_2.0+16-215eedc9ecc0.GCC610.7z)

New CLI options:

--qpmin <integer> sets a hard lower limit on QP allowed to ratecontrol. Default 0
--qpmax <integer> sets a hard upper limit on QP allowed to ratecontrol. Default 69
...
--log2-max-poc-lsb <integer> Maximum of the picture order count
--[no-]sei-dump Emit SEI packets in bitstream. Default enabled

[x265_Project]

x265 2.0+16-215eedc9ecc0 (GCC 5.3.0) (https://www.mediafire.com/download/lk6kgl89b353duw/x265_2.0+16-215eedc9ecc0.GCC530.7z)
x265 2.0+16-215eedc9ecc0 (GCC 6.1.0) (https://www.mediafire.com/download/27oehkyfh7d51lk/x265_2.0+16-215eedc9ecc0.GCC610.7z)

New CLI options:

--qpmin <integer> sets a hard lower limit on QP allowed to ratecontrol. Default 0
--qpmax <integer> sets a hard upper limit on QP allowed to ratecontrol. Default 69
...
--log2-max-poc-lsb <integer> Maximum of the picture order count
--[no-]sei-dump Emit SEI packets in bitstream. Default enabled
We're going to change the syntax of --sei-dump to --discard-sei. This option enables encodes that create SEI messages, consider their size as part of the bit rate (as usual), but discard them instead of writing them to the bitstream. This allows a user to encode an identical bitstream as they would have when SEI messages were included, but without SEI. It's not something most users would ever need.

[x265_Project]

IBM has contributed a set of files containing POWER optimizations. Although this is not in proper patch format, I'm guessing that any competent developer familiar with IBM POWER 8 servers can build and run the optimized version of x265. The x265 team will review, test and commit these improvements as soon as possible, but it may take some time as we've got every developer and then some spoken for right now. So any test or code review feedback from the community of x265 developers would be welcomed. Thanks to IBM for contributing to x265!

Files were uploaded to https://bitbucket.org/multicoreware/x265/downloads

Tom

[Selur]

what's the min/max for log2-max-poc-lsb ?

[x265_Project]

FYI - Netflix has posted on their Tech Blog, notifying people about a large study they have completed comparing x264, x265 and VP9 (libvpx). The results will be published Wednesday morning Pacific time.
http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html


We ran a large-scale comparison of x264, x265 and libvpx to see for ourselves whether this 50% bandwidth improvement is applicable to our use case. Most codec comparisons in the past focused on evaluating what can be achieved by the bitstream syntax (using the reference software), applied settings that do not fully reflect our encoding scenario, or only covered a limited set of videos. Our goal was to assess what can be achieved by encoding with practical codecs that can be deployed to a production pipeline, on the Netflix catalog of movies and TV shows, with encoding parameters that are useful to a streaming service. We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair, we generated more than 200 million encoded frames. We applied six quality metrics - PSNR, PSNRMSE, SSIM, MS-SSIM, VIF and VMAF - resulting in more than half a million bitrate-quality curves. This encoding work required significant compute capacity. However, our cloud-based encoding infrastructure, which leverages unused Netflix-reserved AWS web servers dynamically, enabled us to complete the experiments in just a few weeks.

What did we learn?
Here’s a snapshot: x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.

Want to know more?
We will present our methodology and results this coming Wednesday, August 31, 8:00 am PDT at the SPIE Applications of Digital Image Processing conference, Session 7: Royalty-free Video. We will stream the whole session live on Periscope and YouTube: follow Anne for notifications or come back to this page for links to the live streams. This session will feature other interesting technical work from leaders in the field of Royalty-Free Video. We will also follow-up with a more detailed tech blog post and extend the results to include 4K encodes.

[Motenai Yoda]

It is something like Thursday night at 22/23/24 in Europe

- I'm a full thrust idiot it is Wednesday night not Thursday

[Atak_Snajpera]

We applied six quality metrics - PSNR, PSNRMSE, SSIM, MS-SSIM, VIF and VMAF - resulting in more than half a million bitrate-quality curves.
Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

[x265_Project]

Looks like another useless codec comparision. As We know codec with lower PSNR, SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.
The research team at Netflix know what they're doing. They understand that subjective quality is more important than objective quality measurements. But subjective testing is very time consuming and expensive, and it wouldn't be feasible to cover a wide range of content at a wide range of bit rates and picture sizes (pixel resolutions). Netflix has also been researching better objective quality metrics, with the goal of correlating more closely to subjective visual quality measurements.

[smok3]

What could applying
8 quality levels per configuration-resolution pair
mean?

[x265_Project]

We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair, we generated more than 200 million encoded frames.

3 Codecs - x264, x265, and VP9
2 Configurations - I'm assuming that a "configuration" means a rate control mode (CRF, or 2 pass ABR), or a performance preset. But we'll see.
8 quality levels - CRF value or target bit rate. You need multiple quality levels in order to generate a rate-distortion curve. You need a rate-distortion curve in order to compare codec efficiency.


5000 clips x 12 seconds x 24 frames/sec x 3 codecs x 2 configurations x 3 resolutions x 8 quality levels = 207,360,000 frames.

[LigH]

:scared: Better you have a "render park" available...

[x265_Project]

:scared: Better you have a "render park" available...
As they explained, they do...
However, our cloud-based encoding infrastructure (http://techblog.netflix.com/2015/12/high-quality-video-encoding-at-scale.html), which leverages unused Netflix-reserved AWS web servers dynamically (http://techblog.netflix.com/2015/09/creating-your-own-ec2-spot-market.html), enabled us to complete the experiments in just a few weeks.

[littlepox]

Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

The sad part is that people loves numbers and graphs.
Whatever reasonably looking numbers are true and reliable
Whoever publish them are professional and fair.

If I'd claim, according to my own eyes to compare visual quality, x265 saves 30% bitrate to x264 while libvpx only saves 10%, those crappy hevc/vp9 encoders perform even worse than x264. Who's going to trust me?

On this basis, then you have to acknowledge, although far from perfect, SSIM remains one of the most powerful indicators for visual quality, and PSNR for distortion measure.

[Motenai Yoda]

Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

Yep but when a codec has better PSNR and SSIM is a good hint, and if it's the same on a large number of clips and with many better metrics like PSNRMSE, MS-SSIM, VIF and the newest VMAF too is a big hint.
also on comparing high quality/bitrate encodes metrics are more realiable than on mid/low quality ones.

also in many mid/low bitrate cases vp9 overtake x265 by a bit

inversely to what I said months ago on VP9, x265 looks me to try to preserve too much fine detail (new psy-rd and rdoq defaults?), I proposed about an year ago to dynamically decrease aq and psys at high quantizers (indeed at very low and very high ones)

[x265_Project]

Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/

[tebugg]

Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/

"Proposal To accelerate HEVC adoption, I propose that HEVC patent licensors agree to the following principles;

All HEVC patent holders should make their patents available through a patent pool
Ideally, all patent holders should join one patent pool
Only one reasonable royalty should be paid per device
Software decoding on consumer devices must be royalty free
Software encoding on consumer devices must be royalty free
Content distribution must be royalty free
There must be a reasonable cap on total royalties owed for HEVC implementations"


would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?

[x265_Project]

...would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?
There is no part of the HEVC standard that hasn't made it to x265 due to patent limitations. We license x265 to commercial companies without patent coverage (we explicitly require licensees to identify obtain all necessary patents). Of course, if HEVC patents are too expensive or difficult to license, it hurts our commercial business, and that isn't good for open source adopters, as we won't be able to continue to grow our development team and invest in x265.

[x265_Project]

Netflix presented the results of their large-scale study, comparing x265 to x264 and VP9 (libvpx)...
https://www.youtube.com/watch?v=wi1BefrfTos&feature=youtu.be&t=1h25s

Naturally, if you don't use --tune ssim, results are worse when measured using SSIM. When they avoided --tune psnr and --tune ssim their own visual quality metric showed that x265 delivered the best visual quality. Similarly, when tuned for objective metrics, x265 is the clear winner when measured with objective metrics.

[mariush]

I also noticed that they used 8 bit content (they had higher bit content but they brought it down to 8 bit before passing to encoders) and they used the 8bit encoders - i would have loved to see 10 bit x264 encodings compared to the others.
Also, they didn't mention anything about using -tune animation or something like that when encoding cartoons / anime / whatever with x26* (they said they did apply psycho visual tunings but didn't say in detail what)

Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ... it would make sense to lower some parameters at the very least, to get something that's not quite placebo.

[x265_Project]

Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ...
Why do you say that?

[Jamaika]

Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?

[x265_Project]

Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?

It means they didn't use --tune psnr or --tune ssim, or turn off psy-rd or psy-rdoq. If you watch the presentation, you'll see the explanation.

Also check out my explanation here... http://forum.doom9.org/showthread.php?p=1779649#post1779649

And check out http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=113346

[NikosD]

The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.

[JohnLai]

The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.

Now that explain why I3-4330 3.5ghz encoding speed is almost similar to overclocked 4.2Ghz I5-3570k....

[GigaWatt]

Hi. I'm new to this forum, but I've been following doom9's threads and posts for years. I've been playing around with encoding video and I've found most of my answers in some thread on doom9, but for a few months now, I've been having a problem that I haven't been able to solve by myself.

I've been using x265 as my primary encoder for about a year now with MeGUI and Simple x264/x265 Launcher as frontends. My interests are aimed towards lower bitrates (to about 1000, maybe a little more)... basically, I'm interested in lowering the bitrate as much as possible (in combination with some filters and tuning, mostly grain) and tuning the psychovisual enhancements to achieve maximum subjective quality of the encode. The resolution of the encoded videos is 720p (8 bit sources and encodes). For indexing, I'm using L-SMASH (2 pass encodes). So, basically, I do everything in MeGUI except the encode, which is done in Simple x264/x265 Launcher.

OK, now, let's get to the actual problem. It seems that the --tune grain command in the newer versions of x265 doesn't seem to be working as well as the older ones... at least subjectively. For example, the older versions (to about 1.9+3, that's the last one that was bundled with Simple x264/x265 Launcher and worked "correctly") blured the video at lower bitrates, thus subjectively giving the audience the perception that "this is just how the video was shot/edited". Newer versions (1.9+3 and above) don't seem to do this quite as good as the previous versions, i.e. the video is just more pixelated (not blured).

At first, I thought that it might be a problem with MeGUI or/and Simple x264/x265 Launcher (I'm using the development update server of MeGUI), but apparently, this is not the case.

I haven't done a changelog analysis of x265 (mostly because it's time consuming, something that I don't have much of lately), but I did see some new commands being added in the 2.0 versions of x265 (have no idea if they where there after 1.9+3 and before 2.0x). For example, there is a new CLI command in the analysis chain, --[no-]rskip, which I though might be the culprit so I disabled it (added --no-rskip to CLI). It didn't give me the result I was hoping for. The encode was slightly better, but... not as blured as with the 1.9+3 version. So I tried another approach. Even though --rc-grain is enabled when encoding with --tune grain, I tried adding it in the CLI, just in case. Subjectively, this had no effect on the end result, which probably means that the --tune grain parameter is working correctly and enabling --rc-grain. So, I tried adding --no-slow-firstpass (apparently, --slow-firstpass is enabled by default after 1.9+3), which I thought might "dumb down" the analysis during the first pass and (hopefully) blur the encode. Again, subjectively, there was some improvement, but, not what I was hoping for. So, I tried adding all three commands as custom CLI parameters... as I thought, it didn't help me get the result I was hoping for.

So, my question is, what has changed in the --tune grain parameter since 1.9+3 and how do I get back to doing the encodes the way I want to (blurry, not pixelated).

[LigH]

Welcome.

A lot has changed in the "grain" tuning, partially quite deep inside the encoder. Because it was supposed to preserve the grain, not to remove it. You may find all the details in the x265 commit log, but they will be very technical... Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.

3e53004 (https://bitbucket.org/multicoreware/x265/commits/3e530043698b9df0f9aba7eefbb381ac6cc79421): grain: improve grain handling settings / Turn off SAO, increase psychovisual settings to better retain high frequency

305a127 (https://bitbucket.org/multicoreware/x265/commits/305a1272a412e6da50544c151820631b319de1cc): rc: fix Rate Control for grainy content / optimize params for tune grain, reduce frequent qp fluctions to prevent grain loss

(Probably a few more...)

To return to the old blurring behaviour, you will certainly not use "--tune grain" anymore. But what instead ... may be too much for me to be able to summarize that. Most probably you would keep SAO enabled, I remember that this feature was most frowned upon by those who preferred to preserve the grain.

[GigaWatt]

Thanks for the welcome ;). Glad to "officially" be a part of doom9's forum ;).

Well, the "--tune grain" parameter was the only thing actually gave "good" (blurry) results for me. I didn't mention this before, but I was using it even if the video didn't contain any grain (subjectively) just so that I could get a better psychovisual experience of the video at lower bitrates.

I would say that this is something to think about... adding a new tune parameter in x265? Perhaps "--tune blur" or something similar? I know it's a lot to ask for at this stage of the development (have no idea if that is even in conformance with the HEVC standards), but not everyone is after better quality and preserving grain (although, yes, I have to admit that that would be the goal of any development, making something better, not worse). I think that many web developers will also find a feature like this very handy in online content (save bandwidth and storage, get the same user experience... psychovisually ;)).

Anyhow, here is what x265 2.0+2 "long help" says about SAO:

Loop filters (deblock and SAO):
--[no-]deblock Enable Deblocking Loop Filter, optionally specify tC:Beta offsets Default enabled
--[no-]sao Enable Sample Adaptive Offset. Default enabled
--[no-]sao-non-deblock Use non-deblocked pixels, else right/bottom boundary areas skipped. Default disabled

Basically, it says that it's enabled. Does "--tune grain" disable SAO or has no effect on SAO (stays enabled)? Or, as you suggested, I don't use any tune parameters, just enable all loop filters (--deblock --sao --sao-non-deblock)?

Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.

I was afraid I'd get that answer :S. I was hoping to avoid that, but hey, on the plus side, I'll probably learn a lot ;).

Thanks for your help ;).

[divxmaster]

I've been getting great results firstly using
QTGMC filter and then smdegrain filter. This does however require a knowledge of avisynth/vapoursynth,
with vapoursynth being much more preferable. I taught myself vapoursynth from scratch/google so perhaps
you can also?

used on 576p, so far ds9, sg1, voyager, the results are incredible. bit rates are 400-600 range. it is super sharp
though when seen up close, but is great at a normal viewing distance.

Note that QTGMC does enhance the picture, even if its not interlaced, in some situations.
I see you use 8bit encodes. If you can, try and use 10 bit. More and more hardware now has 10 bit decode,
including the new kaby lake processor.
You don't need SAO if you use the above filters, and in fact it blurs the picture quite a bit.

Cheers,
Divxmaster

[GigaWatt]

I also didn't mention in my first post that I'm familiar with AviSynth scripts and I usually edit the scripts in the end (after being generated with MeGUI). I have't tried VapourSynth at all, but from what I've read, it seems like it's next logical step, so I will try to get into it soon.

I also had great results with MosquitoNR (32, 0 settings), so I used it in combination with "--tune grain" in x265. I haven't tried QTGMC and smdegrain though, but will, thanks for the suggestion ;). Also, I was afraid of encoding at anything larger than 8-bit, mostly because of the lack of hardware (and, in some cases, also software) support, but I haven't been in pace with the changes in this area, so I wasn't aware that things are not what they used to be in this area. Again, thanks for the input and will try a 10-bit encode ;).

One problem though. You're encoding at 576p at 400-600. I was getting good results at 700-1000 at 720p with "--tune grain" and MosquitoNR. I dind't have to use --tune grain and MosquitoNR at 900-1000, but with any bitrate below, say... 800 or 850, I used both of them. It also depended on the source. If there was not a lot of movement in the scenes of the video and if the source required black bar cropping (end resolution = 1280 x 534, 536...), the end result would be great even at 700 without "--tune grain" or MosquitoNR. As I said, it depends on the source.

Anyhow, I will try to do an encode with no tune parameters (SAO disabled) and the filters you suggested ;). Will post with subjective results :D.

[x265_Project]

Pradeep gave an update on x265 at VideoLan Developer Days...
https://www.youtube.com/watch?v=oT8HueAQZ4w

[K.i.N.G]

Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?

[LoRd_MuldeR]

Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?

Not "official", but anyway:
https://forum.doom9.org/showthread.php?p=1778529#post1778529

[LigH]

I keep posting irregularly, here and in the VideoHelp forum. Here is an archive on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC), all 7-zip files contain 32-bit and 64-bit builds both as 3-in-1 multilib EXE and as separate EXE and DLL files per bitdepth. It is not "official", just plain, compiled from the Mercurial source repository by GCC in an MSYS/MinGW environment, no additional patches.

[x265_Project]

Help us share the good news on Slashdot! Old school techies deserve to know. Vote for this story here... https://slashdot.org/submission/6278679/netflix-finds-x265-20-more-efficient-than-vp9

Edit: We made the front page of Slashdot! Thanks for your help.

[Gravitator]

@x265_Project
Asking you to encode my sample with their highest settings at a bitrate of 6800kbit/s (2-pass desirable).

https://mega.nz/#!dFdjlL5Q!X-39N69mg22VEH-eX9tvnDBHGmKVyEDgAX6o74k2G78

[dipje]

I'm going to guess you're going to get a 'you can do it yourself' reply.

[Leo 69]

@Gravitator

Since I saw you were trying Selur's Hybrid, that's a nice tool to make a HEVC encode at the highest setting.
In the encoding settings of x265 select preset "Placebo", 2-pass, 6800 kbps. That should meet your needs.

[K.i.N.G]

Not "official", but anyway:
https://forum.doom9.org/showthread.php?p=1778529#post1778529
I keep posting irregularly, here and in the VideoHelp forum. Here is an archive on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC), all 7-zip files contain 32-bit and 64-bit builds both as 3-in-1 multilib EXE and as separate EXE and DLL files per bitdepth. It is not "official", just plain, compiled from the Mercurial source repository by GCC in an MSYS/MinGW environment, no additional patches.

Thanks LoRd_MuldeR & LigH!!!
:thanks:

[microchip8]

@ dipje @ Leo 69

I think he wants the x265 people to test their encoder with his sample, as it may be problematic

[Jamaika]

CRF isn't a linear function of the bitrate.
One film ex. CRF=24 4K 23.976fps time will bitrate 700kbps, for another of the same framerate and frame size is 6000kbps. It depends on the dynamics of the film.

[filler56789]

x265.exe build 2.0+51 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2458958&viewfull=1#post2458958

[Barough]

x265-v2.0+54-e5ca9b210223 (http://www71.zippyshare.com/v/MXhVqx8x/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[RainyDog]

x265-v2.0+54-e5ca9b210223 (http://www116.zippyshare.com/v/nO2B2mnq/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

Thanks for the new build again Barough.

[LigH]

A question came up in the mailing list about the implementation of tiles. According to the Wikipedia, HEVC supports different parallel processing tools (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Parallel_processing_tools), x265 implemented WPP (Wavefront Parallel Processing) first, but is just implementing slices as well (imaginable as horizontal stripes of possibly different heights, IIRC), and tiles would even allow to split video frames into a grid of rectangular sub-frames.

I hope someone has the knowledge and the time to compare these tools a bit more in depth. I believe they have important differences in parallelizability and encoding efficiency (also regarding possible quality limits due to a restricted scope).

[Jamaika]

A question came up in the mailing list about the implementation of tiles. According to the Wikipedia, HEVC supports different parallel processing tools (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Parallel_processing_tools), x265 implemented WPP (Wavefront Parallel Processing) first, but is just implementing slices as well (imaginable as horizontal stripes of possibly different heights, IIRC), and tiles would even allow to split video frames into a grid of rectangular sub-frames.

I read that this isn't true.
http://image.slidesharecdn.com/hevcvideocodecvinayagammariappan-160607083744/95/hevc-video-codec-by-vinayagam-mariappan-56-638.jpg?cb=1465288787
main profile doesn't allow tiles + wpp compilation

[LigH]

Those will be the restrictions we shall know well. If we have to decide between either one or another technique, we better know good reasons which to prefer in which case.

I never claimed that two of them could be used in conjunction. I just mentioned that they are implemented one after another: WPP already was, slices are being, and tiles may be implemented in x265.

This diagram explains the WPP dependencies well, IMHO. It appears to prefer top and left prediction, and each additional thread has to wait for more finished partial results.

[Jamaika]

I don't know how it is.:stupid:
For example in the widely quoted blog post by Ronald Bultje (https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/), “all forms of threading/tiling/slicing/wpp were disabled”. I didn't notice this until after comments were closed, so I didn't have a chance to respond. As most of you know, x265 is highly multi-threaded, and it uses frame parallelism and Wavefront Parallel Processing by default. These features have minimal impact on quality, but a massive positive impact on performance. WPP is an integral part of the HEVC standard, and we expect most HEVC video to use WPP, as it makes both encoding and decoding run faster and more efficiently. So, I would love to see this test repeated this test using settings that are more rational.

[LigH]

From the x265 commits (https://bitbucket.org/multicoreware/x265/commits/all): Introduction of patches to implement slices started in 2016-09-06 (last week). Consider it "experimental", it may work well only under certain conditions.

[Leo 69]

Guys, have there been any changes in the code lately, which affect quality in any way?
Also, the question of the day - when will the SAO issue be fixed? I can't seem to include this option to all my encodes, it visually blurs so much. Oh, to an untrained eye it certainly not noticeable, but we all know what we're talking about, right?

Thanks a lot to the development team for all their efforts. As soon as I have some money (for now I'm completely broke :)), I'll consider making a donation.

[burfadel]

I think SAO is just set way too strong. Probably even 50 percent of what it is currently would be too strong, I would think more like 20 percent.

[LigH]

A little late, but as it seems to be a kind of intermediate milestone:

x265 2.0+54-e5ca9b210223 (GCC 5.3.0) (https://www.mediafire.com/download/rjdjp9textb73bp/x265_2.0+54-e5ca9b210223.GCC530.7z)
x265 2.0+54-e5ca9b210223 (GCC 6.1.0) (https://www.mediafire.com/download/w9xgmwnb3k3kb4f/x265_2.0+54-e5ca9b210223.GCC610.7z)

Differences in CLI options since 2.0+16:

--[no-]slices <integer> Enable Multiple Slices feature. Default enabled
...
--[no-]analyze-src-pics Motion estimation uses source frame planes. Default disable
...
--qg-size <int> Specifies the size of the quantization group (64, 32, 16, 8). Default 32
...
--discard-sei Discard SEI packets in bitstream. Default disabled
--discard-vui Discard VUI information from the bistream. Default disabled

--qg-size: Additional size 8.

I wonder how the default of --slices can be "enabled" when it expects an integer parameter. Let's guess the default number is 1?

[Barough]

x265-2.0+58-cc77b9922b19 (https://1fichier.com/?9n5zszd1od) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[x265_Project]

I wonder how the default of --slices can be "enabled" when it expects an integer parameter. Let's guess the default number is 1?

Apparently our documentation for this feature is also "experimental". Yes, the default is 1 slice/frame.

[Motenai Yoda]

for research purpose, which is more compatible with tablet, tv and boxset, a main10 level 4.0 high tier or a main10 level 4.1 main tier?

[benwaggoner]

for research purpose, which is more compatible with tablet, tv and boxset, a main10 level 4.0 high tier or a main10 level 4.1 main tier?
Probably 4.1 Main Tier. But there's a lot of tablets and some TVs that aren't 10-bit compatible at all.

8-bit Main Level 4.0 is going to be the most compatible option.

[Barough]

x265-2.0+65-d20b78d6d138 (http://www45.zippyshare.com/v/zhN1DAFX/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[EDIT]
Updated to x265-2.0+65

[brumsky]

I recently upgraded my computer and therefore have some extra encoding power. I've been thinking about making one of the following changes.

RD 5
Rect
Rect & Amp

Now, I admit I don't fully understand the low level details of the options above - just the bits I can gather from the docs. What is RDO predictions? It is listed as the change to RD 5. It seems to have a very large impact on encoding speed.

Here are my current settings.

--profile main10 --output-depth 10 --ctu 64 --bframes 6 --bframe-bias 5 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 57 --subme 3 --no-rect --no-amp --limit-modes
--max-merge 3 --no-early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 1 --aq-strength 1 --cutree --rd 4
--tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 1 --psy-rdoq 1 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing

On another note, how can I identify the differences/benefits of the three options above? As in - what should I look for? I generally use staxrip's video comparison tool but I don't know where to look for the differences.

Thanks in advance!

[Jawed]

This is how I do it:

--preset medium --rd 5

versus

--preset medium

To compare encodes I use a script like:


a=FFVideoSource() # original before encoding
b=FFVideoSource() # encoded

c=subtract(a,b)
c=c.lumalevels(133,149)

interleave(a,b,c)

return last

function LumaLevels(clip source, int "black", int "white", float "sat")
{
black=default(black,16) # PCLevels
white=default(white,235) # PCLevels
sat =default(sat,1)

Cont = 255/float(white-black)
Bright = -int(float((black-16)*Cont+16.5))
Tweak(source,bright=Bright, cont=Cont, coring=false, sat=sat)
}


This helps me to identify where in the frame there are differences. I can then decide whether I care about those differences.

For my own encodes I'm currently using:

--crf 20 --preset medium --output-depth 10 --rd 6

--crf 24 --preset medium --output-depth 10 --bframes 2 --rd 6

--crf 28 --preset medium --output-depth 10 --bframes 2 --rd 6

I think medium with --rd 6 is better than slow and it's the same encode speed or a little faster than slow. Slow uses --rd 4. Medium uses --rd 3. So --rd 6 is a significant difference for the medium preset.

Yes, I know that --rd 6 is currently the same as 5 - when 6 arrives, I'm ready!

I decided to focus on --rd due to:

http://forum.doom9.org/showpost.php?p=1779902&postcount=4237

[x265_Project]

I recently upgraded my computer and therefore have some extra encoding power. I've been thinking about making one of the following changes.

RD 5
Rect
Rect & Amp

Now, I admit I don't fully understand the low level details of the options above - just the bits I can gather from the docs. What is RDO predictions? It is listed as the change to RD 5. It seems to have a very large impact on encoding speed.

RD = Rate Distortion Optimization level
At the core of x265 (and most video encoders) is an algorithm that figures out the best way to encode each block of video. This algorithm weighs the distortion of each candidate "mode" against the bits used (the rate). To do this rate distortion optimization as accurately as possible, the encoder has to accurately calculate the bits that each candidate mode would use. In other words, it has to fully encode the candidate mode, calculating the residual error after prediction (the difference between the inter or intra-predicted block and the source pixels), performing a discrete cosine transform on the residual error, quantizing the residual error, and entropy coding the predicted block plus the residual error. This method is used for RD level 5. For lower RD levels, x265 weighs the bits used by each candidate mode, but it doesn't go through all of the above steps (it will skip entropy coding, for example). Lower levels are roughly accurate when it comes to choosing the best mode, but not as accurate as the highest rd level. Note that there are a number of decisions in x265 that can be rd optimized. More decisions are rd optimized at higher rd level, to a higher degree of precision.

RECT = allow x265 to evaluate and code rectangular blocks (CUs). Each CTU (usually a 64x64 pixel block, but this depends on your --ctu setting) is analyzed to find the optimal way to encode the pixels in the CTU, partitioning the CTU into smaller CUs. For example, a 64x64 pixel CTU might be encoded as four 32x32 CUs, or sixteen 16x16 pixel CUs. HEVC supports rectangular CUs. For example, a 32x32 pixel block could be encoded as two 16x32 CUs, or two 32x16 CUs. Rectangular CUs allow the partitioning to more ideally match the video content, but of course the more possibilities the encoder wants to evaluate, the longer it takes to evaluate all of the possibilities.

AMP = allow x265 to evaluate asymmetric partitions. Asymmetric partitions are rectangular CUs that have a ratio of 1:4, 3:4, 4:1 or 4:3. For example, a 32x32 pixel block can be encoded as a 8x32 pixel block plus a 24x32 pixel block. Again, these additional possibilities can allow for a more accurate fit, but more possibilities = more time needed to evaluate all possibilities.

[burfadel]

AMP seems to have a much less of an impact on performance compared to RECT.

[benwaggoner]

AMP seems to have a much less of an impact on performance compared to RECT.

And --limit-refs and --limit-modes can make the perf cost of each or both a lot smaller while retaining most of the gains.

[burfadel]

And --limit-refs and --limit-modes can make the perf cost of each or both a lot smaller while retaining most of the gains.

Yes, that too!

[benwaggoner]

For my own encodes I'm currently using:

--crf 20 --preset medium --output-depth 10 --rd 6

--crf 24 --preset medium --output-depth 10 --bframes 2 --rd 6

--crf 28 --preset medium --output-depth 10 --bframes 2 --rd 6
Why only 2 b-frames?

[Jawed]

Why only 2 b-frames?
I found that motion in live action tended to become jittery (sort of as though it were half-rate: "anime" in feel).

http://forum.doom9.org/showpost.php?p=1777880&postcount=4189

I actually found the same source suffered the same fate with x264 at crf 24 (using settings that are almost equivalent to preset very slow in speed). But in x264 I historically did not use crf as high as 24 - principally because blocking/banding with 8-bit encodes becomes unbearable.

So the same source in both x264 and x265 (both 10-bit) produced the same problem, which disappears with crf 20. In x264, setting --tune grain also solved the problem (doubled the bitrate for the water test sequence too...).

So when I started my x265 experiments I started to investigate crf, pushing far beyond 21 which was my limit with x264 8-bit. 10-bit, it transpires, makes x264 blocking/banding a non-issue, which was a good reason to see what I thought of higher crf values. Along the way I stumbled into this problem at crf 24.

(In fact I found the problem back in April and was so dismayed that I just forgot about my x265 experiments and did other things - not realising at the time that it was b-frames causing the problem.)

On the water sequence I reported 4 b-frames as a solution. But in other testing I found that rapidly turning faces (small in the frame) in low contrast (think "a steamy room") the problem recurred (horrible jumps, like anime). So 2 b-frames it is.

I decided not to evaluate CRFs between 20 and 24 to see how the problem arises. It just seems that at crf 24, b-frames (with x264 or x265 both on very slow preset) are too unreliable. I hadn't noticed in the past with x264 because I hadn't used such a high value for crf.

[Dclose]

I think medium with --rd 6 is better than slow and it's the same encode speed or a little faster than slow. Slow uses --rd 4. Medium uses --rd 3. So --rd 6 is a significant difference for the medium preset.
I'm testing that right now. --rd 5 is "better" than 4, but it's so slow. And on my current live action test sample, it looks like Medium + --rd 5 is more susceptible to reference frames than Slow + --rd 4.

3,4 frames it is more detailed than Slow + 4, but there's more blocking/artifacts. I changed the frames to 4,4 and that helped, though Slow + 4 is still more consistent even at 3,4 frames. (but Medium + rd5 still has more detail).

And now I increased frames to 5,7. I didn't notice that helping Slow + rd4, but it sure looks to have helped the artifacts/blocking of Medium + rd5. Slow + rd4 is still better in that regard, though.

This is with using most of the common(?) settings for more detail. Maybe those detail settings are too much for Medium and rd5 and 23-24 CRF.

Are there differences between presets that can't be changed? Right now, I think I'm basically changing Sub-Pixel Precision to be able to run --rd 5 at a decent speed. Medium, rd 5, Sub-Pixel Precision 2 vs. Slow, rd 4, Sub-Pixel Precision 3.

[Jawed]

Check the presets page:

http://x265.readthedocs.io/en/latest/presets.html

[LigH]

Another milestone has been passed. Triple feature this time: v2.1+2 stable

x265 2.1+2-c0d91c2b4048 (GCC 5.3.0) (https://www.mediafire.com/file/9ydeug4nzruvmm9/x265_2.1+2-c0d91c2b4048.GCC530.7z)
x265 2.1+2-c0d91c2b4048 (GCC 6.1.0) (https://www.mediafire.com/file/sdz65g1cwajjy39/x265_2.1+2-c0d91c2b4048.GCC610.7z)
x265 2.1+2-c0d91c2b4048 (GCC 6.2.0) (https://www.mediafire.com/file/93utcu99s2hvn0p/x265_2.1+2-c0d91c2b4048.GCC620.7z)

I guess I can skip GCC 6.1.0 soon?

[brumsky]

Thanks for the reply and info Jawed. I did watch that video when it was released. Based on your suggestion, I decided to take a 30 second clip with high motion and a significant amount of rain then encode it using different settings.

The main goal of this was to determine the extra encoding time required for a variety of settings. This is by no means an exhaustive analysis of all the settings - just a select few.

Please note that I am comparing the additional settings against my base config - see below.

--profile main10 --output-depth 10 --crf 22 --ctu 32 --bframes 6 --bframe-bias 5 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --no-rect --no-amp
--limit-modes --max-merge 4 --no-early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 1 --aq-strength 1
--cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --qg-size 16


Using the settings above I began making the following changes then running the encode, and documenting the results.

Here is the link to my dropbox folder, it contains all the videos, images, and excel doc I used.

I will only post a few select images, if you wish to see them all please download from dropbox.

https://www.dropbox.com/sh/mv9jhnoez7u6hcc/AAAlPMAi3E90GbBI7v60IVlZa?dl=0

First off I'd like to say that I selected this clip for two reasons.

It was the best clip I had at the time. ;)
I wanted a clip that would be difficult to encode, lots of motion and rain. The idea being to try and kick x265 in the pants.


Before I post the images I'd like to mention I couldn't tell the difference between any of the encodes when watching the video. The only way I could see a difference was to go frame by frame.

I'd suggest playing the encodes at random to see if you can see a difference.

Source:
https://s22.postimg.org/u7l3o0uh9/637_Vikings_S03_E05_The_Usurper_test.png (https://postimg.org/image/u7l3o0uh9/)

My settings: 4.8 FPS - 2:25 encoding time
https://s10.postimg.org/6z788wclh/637_Vikings_S03_E05_The_Usurper_test_reg.png (https://postimg.org/image/6z788wclh/)

My settings plus RD 6: 3.135 FPS, 3:42 encoding time
https://s10.postimg.org/n3tn24fyd/637_Vikings_S03_E05_The_Usurper_test_rd_6.png (https://postimg.org/image/n3tn24fyd/)

Slow: 2.513 FPS, 4:37 encoding time
https://s10.postimg.org/ww0wlig91/637_Vikings_S03_E05_The_Usurper_test_Slow.png (https://postimg.org/image/ww0wlig91/)

Very Slow: 0.919 FPS, 12:37 encoding time
https://s10.postimg.org/wyks8cjwl/637_Vikings_S03_E05_The_Usurper_test_very_slo.png (https://postimg.org/image/wyks8cjwl/)

Placebo: 0.250 FPS, 46:24 encoding time
https://s10.postimg.org/c0a0wiuo5/637_Vikings_S03_E05_The_Usurper_test_Placebo.png (https://postimg.org/image/c0a0wiuo5/)


If you look closely at the highlighted areas below you can see the areas I was specifically comparing.

https://s21.postimg.org/fn35e019v/637_Vikings_S03_E05_The_Usurper_test_Location.png (https://postimg.org/image/fn35e019v/)

Using my default settings you will see that the areas are less crisp and generally fussy. Especially the hair I highlighted. It has noticeable more distortion then any of the other encodes. The only way I was able to get rid of the distortion was by enabling RD6 - yes 5 & 6 are the same right now. With the exception of preset slow, which is RD 4.

I was actually quiet puzzled by this, I tried adding rect & amp or tu-inter-depth 3 & rect to remove the distortion. Neither of them worked, the images and videos are in dropbox for those encodes. I'm guessing at this point that since the slow preset uses SAO and strong-intra-smoothing, those are responsible for the reduced distortion observed.

It shouldn't be a surprise that the higher the settings used the better the quality. ;) The question is, is the extra encoding time worth the extra quality?

I'd suggest downloading the excel doc now to view all of the results.

Taking the encoding time into account, my opinion is that adding RD 6 gives the best quality increase per extra encoding time. That single option was able to remove a significant amount of the distortion I mentioned above with the smallest increase in encoding time. If you're looking at the doc the column Magnitude difference, for the life of me I couldn't think of a better term, shows the multiple/factor of encoding time increase. Meaning if you take your FPS and divide it by the corresponding value, it should give you a reasonable idea of your fps rate.

Yes I know it will vary, the point is it will at least give you a good ballpark range.

I've decided to have a bit of a rolling scale. Meaning if a particular video is less important to me I'll use by default settings. As the importance of the content increases so will my settings.

On a scale of 1 - 10:
1-4 - my default settings
5-7 - Add RD6
8-10 - add RD 6 rect & amp

Adding at least rect gives the benefit of tu-inter-depth 2 for at least the blocks that use rect or amp, per the docs.

With all of that said, I don't think I'll ever use Placebo or Very Slow presets. Placebo is up to 19x slower than my settings and Very Slow is over 5X slower. While they did produce better encodes, obviously, the increased quality wasn't enough to justify the encode times...

Now if you've actually looked at the excel doc you'll notice I ran the encodes on two different systems. One with AVX2 and one without.

Please Note: I only ran the tests once, so YMMV.

System A:
Dual E5-2670 v1 8c/16t 2.6GHz @ 2.9Ghz No AVX2
This is a Sandy Bridge chip and thus does not down clock when running AVX instructions. This means it can run at the 2.9GHZ all core turbo setting.

System B:
Single E5-2683 v4 16c/32t 2.0GHz @ 1.9Ghz With AVX2.
This is a Broadwell chip and does down clock when running AVX2 instructions.

Despite the 1GHZ difference in clock speed when encoding, the Broadwell chip is up to 25% faster depending upon the settings. If you are running CTU 64 it is up to 25% faster. With CTU 32 it is approximately equal.

At first glance this may not appear that impressive but keep in mind we are comparing two 115 watt chips versus a single 120 watt chip. At the vary least they are equal in speed for approximately half the power usage and heat generated - up 25% faster with CTU 64!!

EDIT:

I forgot to mention that to-intra-depth has little to no impact on performance. My default settings now include --tu-intra-depth 4.

[brumsky]

RD = Rate Distortion Optimization level
At the core of x265 (and most video encoders) is an algorithm that figures out the best way to encode each block of video. This algorithm weighs the distortion of each candidate "mode" against the bits used (the rate). To do this rate distortion optimization as accurately as possible, the encoder has to accurately calculate the bits that each candidate mode would use. In other words, it has to fully encode the candidate mode, calculating the residual error after prediction (the difference between the inter or intra-predicted block and the source pixels), performing a discrete cosine transform on the residual error, quantizing the residual error, and entropy coding the predicted block plus the residual error. This method is used for RD level 5. For lower RD levels, x265 weighs the bits used by each candidate mode, but it doesn't go through all of the above steps (it will skip entropy coding, for example). Lower levels are roughly accurate when it comes to choosing the best mode, but not as accurate as the highest rd level. Note that there are a number of decisions in x265 that can be rd optimized. More decisions are rd optimized at higher rd level, to a higher degree of precision.

RECT = allow x265 to evaluate and code rectangular blocks (CUs). Each CTU (usually a 64x64 pixel block, but this depends on your --ctu setting) is analyzed to find the optimal way to encode the pixels in the CTU, partitioning the CTU into smaller CUs. For example, a 64x64 pixel CTU might be encoded as four 32x32 CUs, or sixteen 16x16 pixel CUs. HEVC supports rectangular CUs. For example, a 32x32 pixel block could be encoded as two 16x32 CUs, or two 32x16 CUs. Rectangular CUs allow the partitioning to more ideally match the video content, but of course the more possibilities the encoder wants to evaluate, the longer it takes to evaluate all of the possibilities.

AMP = allow x265 to evaluate asymmetric partitions. Asymmetric partitions are rectangular CUs that have a ratio of 1:4, 3:4, 4:1 or 4:3. For example, a 32x32 pixel block can be encoded as a 8x32 pixel block plus a 24x32 pixel block. Again, these additional possibilities can allow for a more accurate fit, but more possibilities = more time needed to evaluate all possibilities.

Thank you for the detailed answer!

Is RDO predictions the Entropy coding you mentioned?

[trip_let]

Is RDO predictions the Entropy coding you mentioned?
I'm not x265_Project and not that familiar with video encoding, but unless entropy coding means something different in this context, usually that just refers to general lossless encoding of information bits by essentially making a more efficient representation using codewords, representing more common patterns with fewer bits and less common patterns with more bits. So this process is not about predictions. Some information used in aiding rate distortion optimization with rd 5 is entropy coded.

Rate distortion optimization is about figuring out which lossy representation is acceptably close to the original. At a high level there are more calculations with higher rd levels to increase accuracy of predictions of what might be the best candidate of choices/modes to use by the encoder.



By the way, does anybody know an easy way to compare what's different between versions? I'm not much of a coder and don't really know platforms like bitbucket etc. I know you can look at the commits but that's a bit low level. Kind of looking for the equivalent of a changelog between stable builds. Maybe you can compare documentation versions? But on readthedocs they have latest, stable, 1.7, 1.6 on down, but no 2.0. Can some other snapshot be accessed? Or perhaps any feature labeled "experimental" might be new?

[x265_Project]

Thank you for the detailed answer!

Is RDO predictions the Entropy coding you mentioned?

The general sequence of video encoding (simple version)...

Prediction -> Calculate Residual Error after Prediction -> Discrete Cosine Transform the Residual Error -> Quantize the Transformed Residual Error -> Entropy Code the Prediction and the Transformed, Quantized Residual Error

Entropy coding is lossless compression (think of it like zip file compression). HEVC uses CABAC entropy coding. This is the last step for encoding each block.

When you're doing rate-distortion optimization (RDO), and you want to weigh the relative bit rate of multiple encoding candidates for a block of video, you have to do all of the above steps if you want the actual number of bits. This is very time consuming, of course, because you are doing a full transform, quant and entropy coding on every candidate, and you'll throw out all but the best candidate. So for faster settings, we just look at the # of bits for each candidate without doing the entropy coding. It's roughly accurate, but not as accurate.

[RainyDog]

I forgot to mention that to-intra-depth has little to no impact on performance. My default settings now include --tu-intra-depth 4.

Yeah I've noticed this too brumsky. I used to run --tu-inter-depth 2 and --tu-intra-depth 2 but realised that there was no difference in speed by upping intra to 3.

In fact, I wonder if intra actually does anything at certain resolutions as --tu-inter-depth 2 / --tu-intra-depth 3 versus --tu-inter-depth 2 / --tu-intra-depth 1 resulted in practically identical bitrates and file sizes if I recall when I tested them.

[Jawed]

So brumsky, since your encode parameters are so slow, perhaps you can use --rd 6 to replace other of your parameters that are "slow".

Perhaps you can get back to approximately the same quality as your default parameters (without --rd 6) and maybe gain performance :eek:

The parameters (including --rd 6) you provided are very impressive on that clip - I'd say close to, if not as good as, crf 18 slow (and about 1/4 the bitrate).

That's really going some. But the nature of the clip could be biasing such an assessment. In my experience useful conclusions come from many test clips (and single frames are ignored)...

I wonder if the x265 project will, at some point, completely overhaul their presets. It would appear that they've been chosen too early in the development cycle.

One of the things that concerns me with the presets is that higher quality presets often lead to increased bitrate. This is the opposite of what's seen with x264. To me that indicates the presets are pretty immature.

[x265_Project]

I wonder if the x265 project will, at some point, completely overhaul their presets.
We take a look at this every so often. We've updated our presets several times already, and we'll certainly do it again as we make improvements to different algorithms, or develop new algorithms. We don't want to do it too often, as we think people like to develop a favorite recipe, and when we change presets it changes things for everyone using x265 (except those who specify every option manually).

[Dclose]

I've been running tests for days and for my current test sample of 5000 Kbps live-action 720p video, I agree with various proposed settings such as CTU 32. Other standard disabled things are SAO, intra-smoothing, etc. Early Skip really hurts quality imo, but maybe it will do better with higher bitrate, less action, or with more extreme settings I'm just starting to test such as RD5 with --subme 7.

Anyway, it's hard to do a search on this because I'm not sure what I'm looking for. x265 has always looked 2-D and flat and less "alive" to me than x264, and I thought it was a lack of grain and too much motion blur thing. I've been trying to tune those out of x265, but...

I think the 2-D thing is because x265 limits the lighting or color range. With x264, there seems to be more dynamic lighting. x265 seems to tone down bright light shining on someone's face. Or like someone having highlights in their hair. Or how the sun shines on a green pine tree and the edges or certain other parts of the tree have a shine. x265 seems to dull the lighting and or color.

Is there a known correction for what I'm talking about?

[LigH]

Please search for "sao" (smooth all objects) and see if it is related...

[sneaker_ger]

I think the 2-D thing is because x265 limits the lighting or color range. With x264, there seems to be more dynamic lighting. x265 seems to tone down bright light shining on someone's face. Or like someone having highlights in their hair. Or how the sun shines on a green pine tree and the edges or certain other parts of the tree have a shine. x265 seems to dull the lighting and or color.

Is there a known correction for what I'm talking about?
Post a sample with screenshots that show what you are talking about and your x264/x265 command-lines. Most often this is a user error resulting in wrong color conversion between YUV and RGB (BT.601 vs BT.709) or range (limited/full).

[brumsky]

So brumsky, since your encode parameters are so slow, perhaps you can use --rd 6 to replace other of your parameters that are "slow".

Perhaps you can get back to approximately the same quality as your default parameters (without --rd 6) and maybe gain performance :eek:

The parameters (including --rd 6) you provided are very impressive on that clip - I'd say close to, if not as good as, crf 18 slow (and about 1/4 the bitrate).

That's really going some. But the nature of the clip could be biasing such an assessment. In my experience useful conclusions come from many test clips (and single frames are ignored)...

I wonder if the x265 project will, at some point, completely overhaul their presets. It would appear that they've been chosen too early in the development cycle.

One of the things that concerns me with the presets is that higher quality presets often lead to increased bitrate. This is the opposite of what's seen with x264. To me that indicates the presets are pretty immature.

I know the test was limited and a single clip and frame is not indicative of every possible outcome. It was a simple test to verify your statement about RD 5/6, which I ended up agreeing with.

I also wanted to get a better idea of the performance impact vs quality of a variety of settings.

I've seen the opposite with the preset, generally they provide lower bitrates. My test clip isn't a good example because it is high motion.

[Dclose]

Please search for "sao" (smooth all objects) and see if it is related...
lol, x265 is frustrating compared to x264. I've ran 100+ test samples the past few days, and taking some screenshots now, I guess it is a grain/blur thing not a color or lighting thing. Well, I suppose those are related since blurring diffuses highlights/color along with resolution.

I guess it's mostly during movement that x265 looks 2-D and dull, which is practically all the time in modern media with either a person moving or the camera moving.

Early on, I tried the Grain setting, but it was excessive so I didn't think about it anymore. Looking at it again, objects do have more "energy" on screen and look more alive, and I now see Grain's settings disable SAO.

I tried x265 a year ago but gave up on it quickly due to so much blur even at higher resolution/bitrate. Trying it again to see how small in file size a video could get, it is impressive over x264 at very low bitrate, but it still was so blurry at higher bitrates until I happened to turn off SAO. And then reading mentions of SAO in this thread was evidence I wasn't just seeing things and that maybe x265 has more hidden potential.

Very Slow with my test video encodes at 2fps or less. I don't know what Very Slow is trying to do to the video since the settings I'm gravitating towards from my tests look as good or better to me and encode at least 2+ times as fast. My settings are similar to the ones mentioned in the last 20 or so pages that other people are mostly agreeing on. Still working on fine-tuning, of course.

[Dclose]

May as well post some screenshots. Maybe other people can see things that make the x265 presets look better. The modded setting below has a lot of room left since it encodes much faster than x265 preset Very Slow. I only used that for this since I already had it saved as a profile and it's a decent baseline.
A thing not seen well from screenshots is the blur during motion I mentioned. In the scene, she moves her head just a bit, and x265 presets want to blur her hair, making it look clumped up and flat instead of looking 3-D and alive.

original
http://i64.tinypic.com/28jxna9.jpg

x265 Slower
http://oi64.tinypic.com/24pmq7k.jpg

x265 Very Slow
http://oi66.tinypic.com/120iiw1.jpg

x264 Very Slow
http://oi67.tinypic.com/zwxbwz.jpg

x265 modified
http://oi67.tinypic.com/2qxb4lu.jpg

x265 --preset slow --input - --y4m --ctu 32 --qg-size 16 --merange 25 --no-strong-intra-smoothing --crf 23.50 --qpfile
GENERATED_QP_FILE --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 2.00 --deblock=-2:-2 --no-sao --range full --colormatrix bt709
--ipratio 1.38 --pbratio 1.28

[Jamaika]

It is difficult to say anything, because you added the sceenshot aren't identical. Lacking the "aq-mode 3". Lacking the "zone". Otherwise, the beginning and the end film will be of poor quality (~500 frames).

[Dclose]

It is difficult to say anything, because you added the sceenshot aren't identical. Lacking the "aq-mode 3". Lacking the "zone". Otherwise, the beginning and the end film will be of poor quality (~500 frames).
I didn't notice half of the shots were slightly different since they all read the same frame number in PotPlayer when I saved the screenshot. It looks like the first two x265 are the same, and the x264 and last x265 are the same. Even still, there's some obvious differences there.

I copied and pasted what Hybrid showed in its configuration area. Lacking the "aq-mode 3?" They're the preset settings except for the last one, which is a modded Slow and so uses the same as umodded Slow.

It's not meant to be a big technical comparison. Just that I was taking screenshots so figured I'd post some. And to show that I think the presets are doing x265 a disservice in showing its potential.

[Barough]

x265-2.1+12-11bfa0ae9710 (http://www109.zippyshare.com/v/BRqVdrNG/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Jawed]

We take a look at this every so often. We've updated our presets several times already, and we'll certainly do it again as we make improvements to different algorithms, or develop new algorithms. We don't want to do it too often, as we think people like to develop a favorite recipe, and when we change presets it changes things for everyone using x265 (except those who specify every option manually).
Thanks for explanation. I'm glad to hear to hear that the presets are not sacrosanct.

[benwaggoner]

Thanks for explanation. I'm glad to hear to hear that the presets are not sacrosanct.
Are any :)?

Certainly the x265 presets have had many years less tuning than x264's, and don't include --tune animation or film. Plus HEVC is a much more complex codec than H.264, so there are a lot more axes for tuning.

Also (and fortunately) x265 is in MUCH more active development than x264. This also means that settings that worked well 6-12 months ago might now work as well now. In a lot of cases, special settings for special content are less necessary as x265 does a better job adapting to the content by default (for example --rskip is way better now, so --no-rskip isn't nearly as necessary). Also, the quality/perf tradeoff of different parameters have changed a lot, and we have new parameters like --limit-refs and --limit-modes that allow us to use higher --refs and advanced features like --amp and --rect with much lower CPU cost.

And for really grainy/noisy content, we have --tune-grain with its whole grain-tuned rate control mode.

Exciting stuff is coming (via the changelog), like support for non-IDR I-frames mid-GOP.

[x265_Project]

Are any :)?

Certainly the x265 presets have had many years less tuning than x264's, and don't include --tune animation or film. Plus HEVC is a much more complex codec than H.264, so there are a lot more axes for tuning.

Also (and fortunately) x265 is in MUCH more active development than x264. This also means that settings that worked well 6-12 months ago might now work as well now. In a lot of cases, special settings for special content are less necessary as x265 does a better job adapting to the content by default (for example --rskip is way better now, so --no-rskip isn't nearly as necessary). Also, the quality/perf tradeoff of different parameters have changed a lot, and we have new parameters like --limit-refs and --limit-modes that allow us to use higher --refs and advanced features like --amp and --rect with much lower CPU cost.

And for really grainy/noisy content, we have --tune-grain with its whole grain-tuned rate control mode.

Exciting stuff is coming (via the changelog), like support for non-IDR I-frames mid-GOP.

Thanks Ben. To clarify a couple of points, we last updated our presets in December, and we incorporated limit-refs and limit-modes into the presets at that time.

Support for scene change detection within fixed GOPs is coming, but this will be on by default for all presets.

Right now we're looking at how presets might be optimized for different picture sizes (certain settings that work well for 4K might not be as optimal for 480P and below).

[eclipse98]

Hi All,

Suppose I encode (x265) at CR26 and get a 5mbps bit rate. Then I encode at 3 pass with 5mbps target rate. Will there be any difference in quality ? Logic says it shouldn't be, just wanted to confirm with experts !

Thanks for your help.

Cheers !

[microchip8]

Hi All,

Suppose I encode (x265) at CR26 and get a 5mbps bit rate. Then I encode at 3 pass with 5mbps target rate. Will there be any difference in quality ? Logic says it shouldn't be, just wanted to confirm with experts !

Thanks for your help.

Cheers !

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass

[eclipse98]

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass

Thanks, just what I thought, appreciate your help !

[cojj]

Thanks Ben. To clarify a couple of points, we last updated our presets in December, and we incorporated limit-refs and limit-modes into the presets at that time.

Support for scene change detection within fixed GOPs is coming, but this will be on by default for all presets.

Right now we're looking at how presets might be optimized for different picture sizes (certain settings that work well for 4K might not be as optimal for 480P and below).

First of all, thank you for such a great open-source project.

Now my question: Persoanlly, do you think this change is worth waiting for? I've starting re-encoding all my videos but I could wait bit longer if its worth.

[x265_Project]

First of all, thank you for such a great open-source project.

Now my question: Persoanlly, do you think this change is worth waiting for? I've starting re-encoding all my videos but I could wait bit longer if its worth.
You're welcome. You should not be using fixed GOP length (keyint = min-keyint). If you use our default presets and you don't mess with key interval settings, or turn off scene detection, x265 will create a new GOP at the start of each scene. This will give you the best encoding quality.

Fixed GOP length is never desirable from a quality (compression efficiency) standpoint. Unfortunately, for some scenarios, the system designers chose to use a fixed GOP length for convenience, to simplify streaming or broadcasting. Using variable GOP length for video means that you need to segment audio and metadata into the same varying chunk sizes, which makes the broadcasting or streaming server/client design more complex.

[benwaggoner]

there will be small, mostly unnoticeable quality difference, due to difference in distribution of bits. Also, 3-pass will gain you no more quality than 2-pass, and is mostly used when 2-pass misses the target file size, which can happen only rarely.
I saw some rare cases where a 3rd pass actually made things slightly better at a few points where the encode was VBV constrained, mainly in cases where a fast first pass was used, or when the VBV was really constrained. I think those were only in 2015, though.

Rule of thumb is: if you aim for specific quality, use CRF. If you aim for a specific target file size, use 2-pass
Quite right!

[mzso]

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

[microchip8]

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

I haven't read of any... care to provide a sample of the issue?

[mzso]

Here are examples of aliasing I saw with x265 encodes:
https://drive.google.com/open?id=0ByfdfPvnoDuzNUdidHRRenMyQlE

https://drive.google.com/open?id=0ByfdfPvnoDuzVk5IakRzZDd0eVk

Does anyone have a clue why it happens?

[littlepox]

It's due to the very distinct pattern on his face after down-scaling.
Technically it is called "Moiré pattern".
It has nothing to do with the encoder unless the encoder performs a blur filter before encoding.

[x265_Project]

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

It looks like something went wrong in a processing step prior to encoding... probably in scaling, or chroma subsampling.

[Ma]

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

[trip_let]

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

[Ma]

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

Thanks!

It looks like newest M$ compilers emit AVX2 only instruction with /arch:AVX option. I will try to report this bug.

[Barough]

x265 v2.1+20-c64393b415ad (http://www50.zippyshare.com/v/2oAFG6Oa/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

x265 2.1+20-c64393b415ad (GCC 5.3.0) (https://www.mediafire.com/file/mk3ixj5iric4gbc/x265_2.1+20-c64393b415ad.GCC530.7z)
x265 2.1+20-c64393b415ad (GCC 6.2.0) (https://www.mediafire.com/file/ooasvtcipb8og4v/x265_2.1+20-c64393b415ad.GCC620.7z)

CLI changes since v2.1+2:

+ --limit-tu <integer> Enable early exit from TU recursion for inter coded blocks. Default 0

- --discard-sei Discard SEI packets in bitstream. Default disabled
- --discard-vui Discard optional VUI information from the bistream. Default disabled
+ --[no]-vui-timing-info Discard optional VUI timing information from the bistream. Default enabled
+ --[no]-vui-hrd-info Discard optional HRD timing information from the bistream. Default enabled

^ The small syntax typo will surely be corrected soon... ([no-]... instead of [no]-...).

The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

P.S.: Don't try --limit-tu >2.

Invalid limit-tu option, limit-TU must be 0, 1 or 2

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

[fauxreaper]

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

limit-tu only works with tu-inter-depth>1.

[benwaggoner]

x265 2.1+20-c64393b415ad (GCC 5.3.0) (https://www.mediafire.com/file/mk3ixj5iric4gbc/x265_2.1+20-c64393b415ad.GCC530.7z)
x265 2.1+20-c64393b415ad (GCC 6.2.0) (https://www.mediafire.com/file/ooasvtcipb8og4v/x265_2.1+20-c64393b415ad.GCC620.7z)
The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.
I have a few more --limit-tu questions as well.


What does the default of 0 do? Is it the same as --no-limit-tu?
Is the expectation that 2 is faster and potentially lower quality than 1?

[brumsky]

@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please? :)

[easyfab]

I wonder how much speed gain will be possible without a noticable additional loss of quality.
.

according to this https://mailman.videolan.org/pipermail/x265-devel/2016-October/010702.html

it seems there is no significant loss of quality for a good gain of speed with slower presets

[LigH]

limit-tu only works with tu-inter-depth>1.

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear... :o

[stevendj]

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.
Using builds from builds.x265.eu I narrowed the change I'm talking about down to be between the following versions:
1.9+217 (https://builds.x265.eu/x265-64bit-8bit-2016-06-30.exe)-626fcbac7ffb
1.9+223 (https://builds.x265.eu/x265-64bit-8bit-2016-07-01.exe)-17c0c875f27d

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

These commits can currently be found at the fourth page of the commits list on Bitbucket.
I also attached a screenshot of the 6 commits that could have caused this slowdown.

The new recursion skip a.k.a. --rskip seems like something big that could have caused the different encoding time, so I tried --no-rskip, but that (logically) only further increased the encoding time.

Could some other people perhaps test if they see a significant slow down between these versions too?

Thanks in advance

[Ma]

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

Could you specify your encoding settings?

[Motenai Yoda]

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear... :o
virtually they can change preset defaults to use tu-inter 2/3 on faster presets with limit-tu 2/1 w/o sensible speed impact

also as the doc says
--limit-tu <0|1|2>
Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU's depth, limits recursion of other split subTUs.
Default: 0

so testing anything over 2 has no sense

[brumsky]

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.

This will explain the performance difference you are seeing.

http://forum.doom9.org/showpost.php?p=1779902&postcount=4237

At least it should. :)

[stevendj]

Could you specify your encoding settings?

I can reproduce the difference with just preset slower & crf 23.
I also tried preset medium, but the issue seems non-existent there.

It seems especially reproducible when encoding animated content, less so with 'real-life footage'.
Now that I've done some more testing, I do see a quality increase in the 'real-life footage' encodes (so good job x265 team!),
but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..

[benwaggoner]

but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..
Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

[stevendj]

Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

Tried it, and even tried raising it by 6:
There is a small quality increase, but a ~30% slower encode by my testing. (I only ran 1 test with this higher crf, on animation)

Dear x265 Team, if in the future you would want to optimise x265 for animated content, I guess you should also look into how --rskip behaves on animation.

Edit: all you hard & good work is much appreciated, though!

[Ma]

I can reproduce the difference with just preset slower & crf 23.

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.

[pingfr]

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.

So, does this means we should stick to x265 1.9+217 for an everyday "mainstream" use?

[burfadel]

Don't forget quality improvements and preset changes will likely affect encode speed.

[Ma]

So, does this means we should stick to x265 1.9+217 for an everyday "mainstream" use?

New versions are slower but with better quality.

Example of 10-bit encoding with options "-p slower --crf 16":
original sample www.msystem.waw.pl/x265/uhd177.y4m
x265 1.9+217 www.msystem.waw.pl/x265/u217.mkv
x265 1.9+223 www.msystem.waw.pl/x265/u223.mkv
x265 2.1+21 --limit-tu 1 www.msystem.waw.pl/x265/u1.mkv

x265 2.1+21 produces the same output as 1.9+223.

In this sample there is no details, it is only for check of smooth move. The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural. From version 1.9+223 is much better (with --limit-tu 1 or 2 is also better).

[pingfr]

New versions are slower but with better quality.

Example of 10-bit encoding with options "-p slower --crf 16":
original sample www.msystem.waw.pl/x265/uhd177.y4m
x265 1.9+217 www.msystem.waw.pl/x265/u217.mkv
x265 1.9+223 www.msystem.waw.pl/x265/u223.mkv
x265 2.1+21 --limit-tu 1 www.msystem.waw.pl/x265/u1.mkv

x265 2.1+21 produces the same output as 1.9+223.

In this sample there is no details, it is only for check of smooth move. The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural. From version 1.9+223 is much better (with --limit-tu 1 or 2 is also better).

I have to agree the playback from 1.9+217 is twitchy, jerky, messy.

However the other samples are hard to make a difference given the source's resolution, I mean 340x160 feels like we're back at the stone age.

Could use a 720p source to begin with. :)

[benwaggoner]

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.
You might want to try --tu-inter 4 --tu-intra 4 so that there are more tu depths to check. Preset slower defaults to only 2. I hope that faster tu checking can enable deeper tu size searches to improve detail retention with reasonable performance.

[benwaggoner]

However the other samples are hard to make a difference given the source's resolution, I mean 340x160 feels like we're back at the stone age.

Could use a 720p source to begin with. :)
Yeah, HEVC's low-bitrate performance is good enough that I can't imagine a scenario where I'd want to use 340x160, even at <<100 Kbps. Even moreso than H.264, HEVC tends to get soft rather than blocky/ringy when bits-per-pixel drops "too low" in the hardest bits of video, so it's safer to use higher resolutions. It's a long way from MPEG-2, where content could look fine 95% of the time and horrible 5% of the time, with such a sharp threshold where complexity @ bitrate made it unwatchable.

Also, we should be using at LEAST mod8 resolutions, right :)? and at that low resolution, the upscaling artifacts can be quite distracting, and a major source of visual defects that'll vary between players.

That said, there is tons of SD-only content in this world, and defects are easier to see in SD and encoding is certainly faster. I'd be happy to have test results at 640x360, certainly.

[Jawed]

The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural.
Wow what an excellent test clip.

A while ago I talked about problems at crf 24 due to the number of b-frames with higher quality presets. This test clip reveals the same kind of problem I witnessed.

Encoding this clip at crf 24 preset slow with version 2.1+2-c0d91c2b4048 the judder on the lead vehicle is truly spectacular.

As I reduce b-frames count using 2, then 1 and 0, the results get better. 1 is far from perfect, but the reduction in judder with each reduction in b-frame count is pretty clear. 0 produces no judder on the vehicles, but there is some judder on the clouds of dust. I think that judder is actually just blocking artefacts as the problem extends into the ground.

I haven't played with --limit-tu yet.

[Barough]

x265 v2.1+22-c97805dad914 (http://www117.zippyshare.com/v/5kpmu8gP/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Winston_Smith_101]

Hi! I would like to (re-)encode my original very high bitrate 1080p h.264 movies to x265 to save space on my nas. My goal is to maintain the picture quality nearly as well as possible, but to save a good amount of space at the same time. At the moment i use the newest x265 version 2.1+21 and Staxrip.

I use a Windows 10 Machine with 2x 14 Core Intel Xeon E5 2683v3 CPUs.

So far I made good experiences with the following settings for the first CPU:
"--crf 18 --preset veryslow --output-depth 10 --pools "+,-" --pmode --pme --no-sao"

and: "--crf 18 --preset veryslow --output-depth 10 --pools "-,+" --pmode --pme --no-sao" for the 2nd CPU.

Would you suggest other settings or do you have tweaks to optimize my result? In the end, i would be happy with a picture quality of 80-90% compared to a optically lossles encoding. Encoding time is not a primary sector.

Thank you!

[HWK]

I would take out --pme option it offer little to no benefit
From docs

Parallel motion estimation. When enabled the encoder will distribute motion estimation across multiple worker threads when more than two references require motion searches for a given CU. Only recommended if x265 is not already saturating CPU cores. --pmode is much more effective than this option, since the amount of work it distributes is substantially higher. With –pme it is not unusual for the overhead of distributing the work to outweigh the parallelism benefits.–pme will increase utilization on many core systems with no effect on the output bitstream.

[brumsky]

I use a Windows 10 Machine with 2x 14 Core Intel Xeon E5 2683v3 CPUs.

So far I made good experiences with the following settings for the first CPU:
"--crf 18 --preset veryslow --output-depth 10 --pools "+,-" --pmode --pme --no-sao"

and: "--crf 18 --preset veryslow --output-depth 10 --pools "-,+" --pmode --pme --no-sao" for the 2nd CPU.

Would you suggest other settings or do you have tweaks to optimize my result? In the end, i would be happy with a picture quality of 80-90% compared to a optically lossles encoding. Encoding time is not a primary sector.

Thank you!


I agree with HWK drop --pme, it isn't worth it. Also, I'd drop --pmode as well. I have actually seen fps drop with it. I'm running dual e5-2683 v4 16 cores.

I also use --no-strong-intra-smoothing, helps to keep things a littler sharper.

If you are running x265 v2.1+20 or newer you can use --limit-tu 1 or 2. It'll speed up your encoding with virtually no quality loss. You could also try --limit-refs 3 since you are running very slow preset it sets that to 1.

Based on my testing the option that gives the best quality increase is --rd 5/6, they are the same right now. Which Very Slow defaults to rd 6, so you've already got it.

So you spend\waste a lot of time with limit-refs < 3 and limit-tu 0.

Edit:
Just noticed that --rskip is removed in veryslow as well. I'd suggest enabling that as well.

[LigH]

New CLI options:

--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled

GCC 6.2.0 only is sufficient from now on.

x265 2.1+25-0e9e52640546 (https://www.mediafire.com/file/4co4tji043zovjl/x265_2.1+25-0e9e52640546.7z)

[Boulder]

As it's been a while since I last tried x265 - are there any new recommended encoder settings to test to compare with x264 and --tune film? I've got three seasons of Star Trek TOS to encode and the HD transfers are quite far from perfect at least in the first season. It might be useful to see if x265 will produce better output around the same bitrate. I usually downsize (with some sharpening to compensate) and encode at 720p with CRF 18 using x264 and the preset veryslow.

[Selur]

Can anyone give some inside into the whole hdr processing?
I thought --master-display ... and --max-cll ... were used to add the timing informations that --opt-qp-pps and --opt-ref-list-length-pps remove,...

[nevcairiel]

Can anyone give some inside into the whole hdr processing?
I thought --master-display ... and --max-cll ... were used to add the timing informations that --opt-qp-pps and --opt-ref-list-length-pps remove,...

Those options add additional HDR SEI metadata into the stream, it has nothing to do with the HRD timings.

Don't mix up HRD with HDR - HRD stands for Hypthetical Reference Decoder, and its a different metadata block. Its generally related to various compliance checks, VBV etc. Not sure decoders typically even read this, which is why they may opt to remove it by default.

[Jawed]

As it's been a while since I last tried x265 - are there any new recommended encoder settings to test to compare with x264 and --tune film? I've got three seasons of Star Trek TOS to encode and the HD transfers are quite far from perfect at least in the first season. It might be useful to see if x265 will produce better output around the same bitrate. I usually downsize (with some sharpening to compensate) and encode at 720p with CRF 18 using x264 and the preset veryslow.

I suggest you avoid the spaghetti soup of options some people offer up and stick with:

--preset medium --output-depth 10 --merange 38 --rd 5

this will be about the same speed or a little bit faster than x264 very slow. It'll also be at least as good in picture quality. And it'll produce a file that's about 60% as large.

--merange 38 is for 720p encodes. If you encode 1080p material, then remove this option as the default motion search range is configured for 1080p.

--output-depth 10 will prevent the encoder from introducing banding. Don't use if you are trying to play back your encodes on something other than a PC.

The documentation here is useful:

http://x265.readthedocs.io/en/latest/cli.html

There is no tuning for film. In my opinion at crf 18 you're going to lose some noise and some acuity in your source material (just like with x264) but you'll find x265 is extremely consistent, much better than x264.

Finally, presets in x265 change over time. It's still effectively in alpha, since not all published options are actually implemented. e.g. --rd 6 is actually the same as --rd 5.

[sneaker_ger]

New CLI options:

--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled
Gotta love these totally not confusing documentations. Always gotta take a moment to wrap my head around them.

[Selur]

Don't mix up HRD with HDR
Ahhh, totally read HDR :)

Discard optional HRD timing information from the bistream. Default enabled
So by default the timing information is put in the bitstream,... right?

[sneaker_ger]

No. Only there with --opt-qp-pps + --hrd + --vbv-maxrate + --vbv-bufsize

(Not sure about implications of --uhd-bd)

[Selur]

okay, does --vui-hrd-info play into this somehow?

[Boulder]

I suggest you avoid the spaghetti soup of options some people offer up and stick with:

--preset medium --output-depth 10 --merange 38 --rd 5

this will be about the same speed or a little bit faster than x264 very slow. It'll also be at least as good in picture quality. And it'll produce a file that's about 60% as large.What I'm looking for is still the retention of details (or noise), but based on a very quick test with a frame by frame comparison, it seems to me that x265 still eats those for breakfast. I'll really have to do a proper viewing test too see if it's noticable in motion. I also noticed a shift in colors that some other people have mentioned. It doesn't occur in the x264 sample.

[Motenai Yoda]

Finally, presets in x265 change over time. It's still effectively in alpha, since not all published options are actually implemented. e.g. --rd 6 is actually the same as --rd 5.
this is bs, they explained many times those rd modes exists in previous versions and they mantain rd 4 and rd 6 to not broke existing users's scripts and code

@Boulder try with no-sao and rdoq 2 both will reduce detail/grain loss, but most of the x264 "details" come from its microblocking and aren't real ones

[Jamaika]

Ahhh, totally read HDR :)
So by default the timing information is put in the bitstream,... right?
HRD (Hypothetical Reference Decoder) is only an additional signal streaming in the header frames GOP. It doesn't change the recording HEX in file HEVC. It is the wrong description. HDR is off by default.
I wonder about changes in the function of high-tier.
No matter whether I enable or disable the vbv 160000kbps, tier is always high for crf. If the function is always automatic that is superfluous.

[WhatZit]

What I'm looking for is still the retention of details (or noise), but based on a very quick test with a frame by frame comparison, it seems to me that x265 still eats those for breakfast.

When they announced improvements to "--tune grain" in v2.0, they weren't kidding! Combine this with 10/12-bit encoding, and the results are, I think, magic.

Prior to this, I was also chasing all manner of CLI arguments to retain detail. Now, I use the same ludicrously simple command line for practically everything.

--preset (as slow as you can stand) --crf 21 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing

With the above, the slower the preset, the more detail retention you get. In fact, speed is the only change you need to make to improve (or reduce) quality, as it should be.

Tuning for grain greatly reduces psychovisual artifacts from moving picture elements, and cuts out almost all of the high-frequency "breathing" caused by wayward quant fluctuations.

Of course, encoding in 10 (or 12) bits obviates banding.

Deblock is at the weakest setting rather than turn it off completely (--no-deblock), and who wants strong smoothing when you want to retain detail?

Just for laughs, why don't you try a preset of "superfast"? I call that the "x264 emulator".

[Boulder]

When they announced improvements to "--tune grain" in v2.0, they weren't kidding! Combine this with 10/12-bit encoding, and the results are, I think, magic.After some testing, I have to admit that --tune grain is a helluva lot better than it used to be. Earlier the bitrate skyrocketed but now it's possible to use a lower bitrate than with x264 and detail is retained quite nicely, at least with the Star Trek samples I've encoded.

EDIT: What about --rd-refine, has anyone tested it? I've not seen any mentions about it.

[Barough]

x265 v2.1+25-0e9e52640546 (http://www50.zippyshare.com/v/crmBmKE7/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Dclose]

Can anyone explain the effects of --tu-inter-depth and --tu-intra-depth in layman terms for me please?

I'm currently encoding old ish TV series from DVD whilst experimenting with some settings in the process. It's been a while since I last tried x265 and I'm pleasantly surprised by what speeds I can get on my i7 3770k with a bit of settings juggling.

But I've just stumbled across that increasing both --tu-inter-depth and --tu-intra-depth from 1 to 2 causes a 15% reduction in bitrate with all other settings left the same. Is really that much of an efficiency gain or is it actually having a negative impact somewhere? The DVD's are PAL 720x576 so is resolution a factor? Perhaps 1 is best for SD, 2 for HD and 3 is for 4k? Going from 2 to 3 barely has any effect but the reduction in bitrate and file size when increasing from 1 to 2 is quite alarming!

Speed doesn't seem much different when set to 1, 2 or 3 but that might be because it's chugging along at a lower bitrate when set to 2 or 3.

Main settings I've settled on otherwise (for 576p resolution) are preset medium but with the following tweaks :-

--CRF 21 --ctu 16 --max-tu-size 8 --qg-size 16 --early-skip --b-intra --limitmodes --weightb --me star --merange 25 --max-merge 3 --subme 3 --ref 5 --bframes 5 --rc-lookahead 40

Thanks.
I haven't seen a layman's answer to what intra and inter tree unit depth do. It looks like it's just supposed to help make the file smaller, but...

While encoding a 1080 cartoon, Max Intra 2 looks to be more blurry than Max Intra 1. I don't think 1 is sharper than the source; just that 2 is blurrier. On my test sample, 1 has a smaller file size.

So, I'm not sure what Intra (or Inter) are supposed to be doing. Maybe they do something different on live action, which I haven't tested that specifically yet.

Btw, Coding Unit size of 64 is already said to be blurrier than 32, and on my current cartoon sample it's very noticeable. It's interesting in that 64 and Intra 2 do help add fluidity and a "3-D" quality to the 2-D cartoon, but they make me want to rub my eyes thinking my eyes can't quite focus. 64 is a bigger file than 32 too, on this particular sample.

[gamebox]

@Dclose

I've noticed the same issue with blurriness when increasing inter/intra depth. Basically, bigger value for tu-inter/intra-depth means encoder will try harder to find visual material that can be reused from previously encoded frames. That also means more parts of the image will stay on screen for longer, and be more "degraded" because of subtle transformations from motion compensation they are subjected to. This is especially true if encoder is allowed to use many consecutive B-frames. So, the bottom line is - if areas with lots of movement are important in video (anime, sport, porn), try decreasing these options to get better defined edges and less blur. For general purpose encoding, Hollywood motion pictures, documentaries, etc, where scenery is as important as the action itself, feel free to use larger values to get smaller files.

[Winston_Smith_101]

I am not a programmer and do not know methods of software optimization. My questions are, is it possible that x265 could become noticeable faster in the future, or are there any realistic possibilities for optimizing the program code? Do people optimize the speed of x265 in this phase of development? And is it thinkable that x265 in future can use the computational power of a modern graphics card as a teammate together with the cpu?

[LigH]

To disappoint you slightly, x265 is already pretty optimized, regarding the usage of highly specialized CPU instruction sets, most important the AVX family. New and more efficient instruction sets will probably be used in the future as well, when the CPU supports it and the developers learn to use them.

But the HEVC technology in general is not perfectly parallelizable. It is limited by a lot of dependencies between several intermediate results. There is no magic to circumvent such dependencies. And there are more of them when you try to achieve more efficient encoding to spare bitrate and preserve more quality per bitrate.

[Dclose]

I've noticed the same issue with blurriness when increasing inter/intra depth.

So, the bottom line is - if areas with lots of movement are important in video (anime, sport, porn), try decreasing these options to get better defined edges and less blur. For general purpose encoding, Hollywood motion pictures, documentaries, etc, where scenery is as important as the action itself, feel free to use larger values to get smaller files.

My current test sample barely has any motion in it, and the file is bigger with 2 Intra than with 1 Intra. Maybe the small amount of motion on the screen draws my attention to the blur more, but even when only a character's mouth is moving, the entire video makes me want to rub my eyes of a haze.

The difference between Intra 1 and 2 isn't as pronounced as between Coding Unit 32 and 64. I encoded many hours of (animated) video at 1fps using CU64 to then watch it and think my media player had a blur filter turned on.

You said such Intra/Inter effects are more pronounced with higher b-frames, and most of my testing was with 8 or 10 b-frames. Though, again, my current video has little action. I've done plenty of testing of other video with CRF of 23-33 to try to maximize file reduction vs. "tolerable" quality, but this is with CRF of 16-18, so I can't blame that.

Previous live-action video I encoded I used 10 b-frames since it was obvious to me at the CRF 23+ I was using that the image was simply "tighter." Perhaps more easily noticed during action such as someone walking, but even during no action there is still usually at least slight movement on the screen from an actor or the camera movement.

Actually, for this cartoon, most of my testing was with 10 b-frames, but I dropped that down to 8 since 10 seemed slightly sharper (or maybe just less "fluid" during motion) than the source video. 6 b-frames seems to make the motion blurrier than the source. Perhaps mainly/only during motion. As if the black edges of the drawn characters have thicker black edges during motion.

That coincides with your saying more Intra/Inter tries to re-use material from previous frames and keep it on screen longer.

From my previous tests, even more b-frames helped sharpen the video, but the diminishing returns of encoding time vs. quality gain was too much for me. And I suppose maybe "10 b-frames almost never matters" might be other people's way of saying, "It helps but isn't worth the encoding time to me."

I know some will say most video only usually has x number of b-frames in a row or whatever, but I consider my eyes to be an impartial judge since I couldn't give a technical description for "b-frame" or "b-pyramid" or "weighted-b-frame" if I tried and am only going by what I see. And it's not like I want to increase encoding time by using more b-frames. It'd be great if 2 b-frames was better since it encodes faster.

[Dclose]

Max Merge Candidates.

The setting for that increases with slower presets, but I haven't seen much if any discussion about what it does to the quality. A higher setting does help "concentrate" and "focus" the video with the low bitrates I've mainly tested it on, but it seems like a smoothing filter in that it makes bad video more watchable but removes detail, and so maybe isn't the best setting to turn up if trying to preserve detail.

I stopped using x265 for a long time because the presets, (or the x265 build at the time), would destroy detail compared to x264 -- regardless of CRF setting or bitrate.

Just thought I'd mention it since I've seen little discussion of it.

[gamebox]

@Dclose

Max merge has something to do with neighboring blocks, that is - including them in analysis of currently encoded one. I haven't experimented much around that option.

Deblock -3 helps me preserve more sharpness and detail, and I also try to keep as high resolution as possible and "reasonable" (576p for SD content, for example). Since decoding is done in software, I looked at the options there too - for example, I've found that Media Player Classic uses bad resize algorithm during playback by default, to scale video to fullscreen resolution of monitor (Bilinear, so I've set it to Bicubic). And, of course, newest version of encoder is a must, options like no rskip helped a lot with the quality, even if they increased encoding time significantly as well.

[Boulder]

A question regarding recursion skip: it is disabled in --tune grain. How big a difference would it theoretically make (i.e. how important it is in keeping grain) compared to enabling it? It makes a really big difference performance-wise at least in --preset slower.

[MeteorRain]

I am not a programmer and do not know methods of software optimization. My questions are, is it possible that x265 could become noticeable faster in the future, or are there any realistic possibilities for optimizing the program code?

Only if there are some new instructions specifically optimized for HEVC encoding, and x265 can use them.

Another way to make it run faster, is to get a better CPU -- Yes I'm talking about expensive-as-hell E5s.

[aymanalz]

I am not a programmer and do not know methods of software optimization. My questions are, is it possible that x265 could become noticeable faster in the future, or are there any realistic possibilities for optimizing the program code? Do people optimize the speed of x265 in this phase of development? And is it thinkable that x265 in future can use the computational power of a modern graphics card as a teammate together with the cpu?

Hehe, I asked the exact same question over a year ago, on this very thread. At that time, the latest version was 1.6, and the developers replied that they did have some plans to improve the speed. And they were right - by version 1.9, encoding was significantly faster.

Perhaps it is time to ask that question again - is there a roadmap to make the encoding noticeably faster in future? From a couple of responses to your question, apparently not. Which would be a shame, because I can see that x265 is significantly better in quality than any previous encoder - and yet, I can't help feeling that the encoding time is still too slow for most people.

If it is true, as selur and another poster have said, that x265 has already been optimized to the maximum possible extent for today's hardware, then I get a gut feeling that x265 would not be able to dethrone x264 as the reigning monarch of compressed video. (Especially for storing home video, or for streaming websites like Youtube.)

*******************************

The second part of your question is very pertinent to me - about the use of graphics cards. I hope that in future it would be possible to use my otherwise idle GPU to take part in the encoding process. If some calculations can be offloaded to the GPU, and that can make a 20% difference to the encoding time, that would be a significant shot in the arm for x265 adoption.

[LigH]

"Home video" with resolutions up to FullHD at most is not the main market for HEVC. You may be able to spare a bit more bitrate, especially when tuning for sharpness and grain gets improved more. But the main target are UHD resolutions where HEVC can draw its trumps: bigger coding units and more flexible partitioning of them.

My samples (https://www.mediafire.com/folder/ldwl20fppplbx/samples) are already quite old; but the "in_to_tree" videos give a good hint where x264 could not compete with x265 already in April 2014. The resolutions are "only" 1080p, but in this sample you can compare a low bitrate HEVC result (CRF 30) with about the same, 2x, 3x, and 4x the bitrate in AVC, and decide how much was required to let x264 handle the sky above the trees good enough not to throw the towel... Of course, this example appears to be quite academic. I believe we should repeat this test now with current versions and see if x265 fixed a few flaws in the meantime, handling the challenge of lots of leaves even better now with grain tuning or similar options.

[x265_Project]

I am not a programmer and do not know methods of software optimization. My questions are, is it possible that x265 could become noticeable faster in the future, or are there any realistic possibilities for optimizing the program code? Do people optimize the speed of x265 in this phase of development? And is it thinkable that x265 in future can use the computational power of a modern graphics card as a teammate together with the cpu?

Yes. We're always working on 2 things...
1 - improve compression efficiency (achieve the highest possible visual quality at any given bit rate; or, stated differently, achieve the lowest possible bit rate for any target level of visual quality).
2 - improve performance (without compromising compression efficiency, make x265 go faster). We can improve performance algorithmically, through smarter decisions that avoid unnecessary computations, and we are always looking to optimize x265 for the platforms it runs on (avoiding any bottlenecks).

Of course, x265 will benefit from advances in CPU performance from Intel, AMD, IBM and ARM. For example, the next generation of Intel Xeon chips (the Skylake Xeons, code-named Purley) will include AVX3 instructions which operate on 512 bits of data per clock cycle. But there are other possible ways to accelerate x265, and we're working on them.

[Boulder]

A question regarding recursion skip: it is disabled in --tune grain. How big a difference would it theoretically make (i.e. how important it is in keeping grain) compared to enabling it? It makes a really big difference performance-wise at least in --preset slower.One more thing in addition to this: what about deblocking, does disabling it reduce the smoothing effect or will it cause ill effects elsewhere? I've been unable to determine it by a frame-by-frame comparison.

[CruNcher]

Yes. We're always working on 2 things...
1 - improve compression efficiency (achieve the highest possible visual quality at any given bit rate; or, stated differently, achieve the lowest possible bit rate for any target level of visual quality).
2 - improve performance (without compromising compression efficiency, make x265 go faster). We can improve performance algorithmically, through smarter decisions that avoid unnecessary computations, and we are always looking to optimize x265 for the platforms it runs on (avoiding any bottlenecks).

Of course, x265 will benefit from advances in CPU performance from Intel, AMD, IBM and ARM. For example, the next generation of Intel Xeon chips (the Skylake Xeons, code-named Purley) will include AVX3 instructions which operate on 512 bits of data per clock cycle. But there are other possible ways to accelerate x265, and we're working on them.

Hopefully they will be better then your decoder optimizations on release ;)

[gamebox]

@Boulder:

Deblocking filter in HEVC, in my opinion, should always be set lower than what you've been using in H264. For example, I used values of -1 (sometimes -2) in H264, but now use -2 and also, often, -3 in HEVC. Reducing strength of this filter does increase visibility of coding artifacts like blocking and (even more pronounced) ringing, but they seem to be less disturbing and present in smaller areas than in H264, possibly because of different block sizes. I also prefer sharper, detail-rich image with some artifacts better than completely smooth one, especially as newer kind of video content (HD) is often recorded differently than older media and it helps reducing visibility of artifacts (objects in foreground in modern media content are very sharp/focused with a smooth/unfocused/simplified background (that means lower visual complexity and better optimization for low bitrate encoding)). I haven't tried encoding with deblock filter completely off, and some people advised to keep it on at all times anyway, but set to lowest value (-6) if desired.

[brumsky]

My current test sample barely has any motion in it, and the file is bigger with 2 Intra than with 1 Intra. Maybe the small amount of motion on the screen draws my attention to the blur more, but even when only a character's mouth is moving, the entire video makes me want to rub my eyes of a haze.


Just a shot in the dark here but are the sources interlaced? I've seen the same thing when the source is not properly deinterlaced.

[Barough]

x265 v2.1+36-d216cb9b3b47 (http://www109.zippyshare.com/v/9vWVNhQd/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

Me too:

x265 2.1+36-d216cb9b3b47 (https://www.mediafire.com/file/eogh5j4zkoq2oi8/x265_2.1+36-d216cb9b3b47.7z) (MSYS/MinGW, GCC 6.2.0, 32 + 64 bit, 8+10+12 bit single EXE + DLL and multi-lib EXE)

More advanced options:

--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]multi-pass-opt-rps Enable storing commonly RPS in SPS in multi pass mode. Default disabled

[Dclose]

Just a shot in the dark here but are the sources interlaced? I've seen the same thing when the source is not properly deinterlaced.

Nope. And I went through part of it frame by frame.

Also, as for size, I've been doing testing with 1 minute from The Matrix lately. People mostly standing around talking, lots of fine textures and a decent amount of grain.

Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.

[brumsky]

Nope. And I went through part of it frame by frame.

Also, as for size, I've been doing testing with 1 minute from The Matrix lately. People mostly standing around talking, lots of fine textures and a decent amount of grain.

Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.

It's hard to say, it's most likely getting more fine detail. Can you share a small sample file of the motion blur you are talking about? Maybe of the source as well, I'd like to see if I get the same effects.

Also, what are you full settings?

[nandaku2]

A question regarding recursion skip: it is disabled in --tune grain. How big a difference would it theoretically make (i.e. how important it is in keeping grain) compared to enabling it? It makes a really big difference performance-wise at least in --preset slower.

Since it was first introduced, rskip has now been optimized significantly to prevent loss of detail. It is definitely worth testing to see if we could re-enable it in tune grain and improve speed.

[Kavitha]

@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please? :)


TU node in quad tree is traversed by depth first search process to find the best TU partition.
Aim of limit-tu feature is to limit the depth search range. By limiting the depth search range, the encoder can early exit thus improving the performance with minimal compromise in quality.
In limit tu 1, the depth search is limited using breath first search traversing. Here all partitions of current depth are processed before deciding if next depth should be traversed
In limit tu 2, depth search is limited by allowing the first partition to recurse fully to maximum allowed depths
(--tu-inter/intra-depth value determines the maximum TU depth the encoder is allowed to traverse) and limits the depth search of other partitions by reusing the maximum best depth that the first partition chooses.
Since --tu-inter-depth 1 allows the encoder to traverse only upto current depth, limit-tu has no scope to optimize the depth range. Hence limit-tu is enabled only if tu-inter-depth > 1
From the test results:
performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2

[Selur]

Is 'multi-pass-opt-rps' only needed during the 1st pass of a 2pass encoding?

[benwaggoner]

The difference between Intra 1 and 2 isn't as pronounced as between Coding Unit 32 and 64. I encoded many hours of (animated) video at 1fps using CU64 to then watch it and think my media player had a blur filter turned on.
Note that your --ctu size implicitly sets the max tu size, and thus the starting point for further recursion to smaller tu sizes set by tu-inter/intra.

So, the difference between ctu 64 tu-inter/intra 2 and ctu 32 tu inter-intra 1 is that the first gives the option of a 32x32 tu. Both can down to 16x16 and 8x8.

I strongly suspect that some of the benefit of a smaller ctu with faster presets is that they allow smaller tu sizes. The default CTU 64 an tu inter/intra of 1 only gives the option of 32x32 and 16x16 tu sizes. Comparing ctu size impact on its own merits should probably use tu-inter 4 and tu-intra 4 to make sure that the minimum tu size is always 4x4.

[benwaggoner]

Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite.
Comparing quality and ABR changes together is quite challenging. To really understand the impact of quality changes from parameters, I strongly recommend use of a 2-pass VBR encode with the alternate encodes parameters all using the same --bitrate, --vbv-maxrate, and, --vbv-buffsize. That way we are only comparing the quality @ bitrate. Once we figure out optimal settings for that, we can then work back to the right CRF.

It is completely predictable that different parameters can have different optimal CRF values to hit the same perceptual quality or the same ABR.

[benwaggoner]

@Boulder:

Deblocking filter in HEVC, in my opinion, should always be set lower than what you've been using in H264. For example, I used values of -1 (sometimes -2) in H264, but now use -2 and also, often, -3 in HEVC. Reducing strength of this filter does increase visibility of coding artifacts like blocking and (even more pronounced) ringing, but they seem to be less disturbing and present in smaller areas than in H264, possibly because of different block sizes. I also prefer sharper, detail-rich image with some artifacts better than completely smooth one, especially as newer kind of video content (HD) is often recorded differently than older media and it helps reducing visibility of artifacts (objects in foreground in modern media content are very sharp/focused with a smooth/unfocused/simplified background (that means lower visual complexity and better optimization for low bitrate encoding)). I haven't tried encoding with deblock filter completely off, and some people advised to keep it on at all times anyway, but set to lowest value (-6) if desired.
Note that this is really an alpha/beta pair, and that using different numbers is supported and often effective. I've seen some promising results with --deblock -1:1 for example. That reduces the strength of the deblocking (-1) but increases how much it gets used (+1).

[benwaggoner]

One more thing in addition to this: what about deblocking, does disabling it reduce the smoothing effect or will it cause ill effects elsewhere? I've been unable to determine it by a frame-by-frame comparison.
It can be complex. Less deblocking means less compression efficiency, so at the same bitrate, it will push up QP, which might trigger more SAO. Turning off both may reduce smoothness but increases QP. Thus at low-moderate bitrates true details can be lost, perhaps psychovisually balanced by the increased false detail of DCT "sizzle" (mild ringing and maybe blocking).

Again, I recommend making these comparisons at fixed ABR, or even CBR, since using CRF is going to yield simultaneous changes in ABR and perceptual quality, and we're better off understanding first how changes impact quality at the same bitrate.

[brumsky]

TU node in quad tree is traversed by depth first search process to find the best TU partition.
Aim of limit-tu feature is to limit the depth search range. By limiting the depth search range, the encoder can early exit thus improving the performance with minimal compromise in quality.
In limit tu 1, the depth search is limited using breath first search traversing. Here all partitions of current depth are processed before deciding if next depth should be traversed
In limit tu 2, depth search is limited by allowing the first partition to recurse fully to maximum allowed depths
(--tu-inter/intra-depth value determines the maximum TU depth the encoder is allowed to traverse) and limits the depth search of other partitions by reusing the maximum best depth that the first partition chooses.
Since --tu-inter-depth 1 allows the encoder to traverse only upto current depth, limit-tu has no scope to optimize the depth range. Hence limit-tu is enabled only if tu-inter-depth > 1
From the test results:
performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2

Thank you for the explanation, that was exactly what I was looking for!

[Boulder]

Since it was first introduced, rskip has now been optimized significantly to prevent loss of detail. It is definitely worth testing to see if we could re-enable it in tune grain and improve speed.I did some tests with the noisy, blocky Star Trek TOS stuff, resized to 720p. I cannot tell which one looks better what comes to comparing to the original, because it seems to depend on the frame. I might even say that with rskip it's generally better and considering the cost in heavily increased encoding time, I'll use rskip also with --tune grain.

However, I need to make some more tests with a better source such as The Hobbit.

While I'm writing, I'd like to thank for the much improved encoder and --tune grain. It now looks like I can switch to x265 for good. Hopefully I can get me an Intel NUC that supports HW decoding of 10-bit HEVC soon :)

[Boulder]

Note that this is really an alpha/beta pair, and that using different numbers is supported and often effective. I've seen some promising results with --deblock -1:1 for example. That reduces the strength of the deblocking (-1) but increases how much it gets used (+1).Thanks, I ended up using -6:1 to make only light deblocking but more often than with -6:-6.

[burfadel]

performance : limit-tu 2 > limit-tu 1
quality : limit-tu 1 > limit-tu 2

How different is the quality between 1 and 2, at least in regards to your reckoning? Is using 2 worth it over none, and over 1?

[Blue_MiSfit]

Damn. --tune grain is amazing.

With a very grainy movie I was able to achieve a 2:1 reduction versus x264 with no quality loss visible during motion. Still frame a:b comparison reveals differences, but nothing earth shattering.

[jlpsvk]

Hi....what would be faster in encoding?? Core i7-4790K or 2xXeon E5-2670 (with ASUS Z9PE-D8 WS motherboard and 64GB DDR3 RAM)?

[microchip8]

Hi....what would be faster in encoding?? Core i7-4790K or 2xXeon E5-2670 (with ASUS Z9PE-D8 WS motherboard and 64GB DDR3 RAM)?

obviously the latter...

[jlpsvk]

even if Xeon E5-2670 is missing AVX2.0?

[hajj_3]

even if Xeon E5-2670 is missing AVX2.0?

those xeons have 8 cores each. 16 slower cores will provide much more performance than a single quad core cpu.

[microchip8]

even if Xeon E5-2670 is missing AVX2.0?

Don't get fooled in thinking that all you need for x265 is AVX2.0 CPU. Yes, AVX2.0 provides a performance boost for x265, but it isn't all and everything. The more cores you can throw at x265, the faster things will get, AVX2.0 or not. Obviously if you can throw as many cores with AVX2.0 you can get, that'll be great. But you're comparing here 16 cores to 4 cores

As your core count increases, it may be time to enable --pmode (and possibly --pme)

[Boulder]

Would it be possible to have some more statistics after the encoding has finished? I'm talking about things like number of refs used, percentages of CTU and TU sizes etc.

[x265_Project]

Would it be possible to have some more statistics after the encoding has finished? I'm talking about things like number of refs used, percentages of CTU and TU sizes etc.
Have you tried "--csv statlogfile.csv --csv-log-level 2"? This tracks the CU types used by prediction type (inter or intra) and size category (lumping rectangles and asymmetric partitions into the larger square partition size category).

If this doesn't give you everything you want - technically, of course, with respect to gathering and reporting statistics, anything is possible. Someone just has to write the code to gather and report the additional info to the console or to the csv log file. Contributions are welcomed.

[Barough]

x265 v2.1+46-583fc74fc0a2 (http://www96.zippyshare.com/v/uEW322FS/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Selur]

--[no-]multi-pass-opt-rps

Enable storing commonly RPS in SPS in multi pass mode. Default disabled.

Can someone elaborate on this. I mean:
- is it only meant to be used during the 1st pass of a 2pass encoding?
- what should be the effects of this when enabled? (should it optimize frame placement?)

[benwaggoner]

those xeons have 8 cores each. 16 slower cores will provide much more performance than a single quad core cpu.
For lower resolutions (720p and below), my 6700K Skylake beats my 16 core Sandy Bridge in encoding speed for a single stream at a time with some specific high quality settings. It depends on what you're doing.

[jlpsvk]

nevermind... :)

Going for i7-6700K with NZXT Kraken X61 + 32GB DDR4 RAM + GeForce GTX 1060, so I'm gonna test the HEVC 10bit NVENC also. :)

[pradeeprama]

Can someone elaborate on this. I mean:
- is it only meant to be used during the 1st pass of a 2pass encoding?
- what should be the effects of this when enabled? (should it optimize frame placement?)

This option should be enabled in both 1st and 2nd pass of encoding.

When enabled, it optimizes bitrate in the 2nd pass by storing the 64 most common RPSes from each GOP into the SPS that is emitted at the start of the GOP. This way, slice headers may just signal an index in the RPSes held in the SPS instead of sending the entire RPS; if the slice's RPS isn't in the SPS, then it needs to signal its own RPS in its header. This would result in bit-rate savings in the 2nd pass, without any change to visual quality.

[pradeeprama]

nevermind... :)

Going for i7-6700K with NZXT Kraken X61 + 32GB DDR4 RAM + GeForce GTX 1060, so I'm gonna test the HEVC 10bit NVENC also. :)

In the Maxwell generation, we noticed that nvenc didn't support B-frames. Is this fixed with Pascal?

I hope you will be sharing some of your findings in this comparison on this forum..

[Selur]

@pradeeprama: Thanks for the explanation.

[Barough]

x265 v2.1+47-a378efc939e3 (http://www20.zippyshare.com/v/pWUGdhWB/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[cojj]

Quick question - Reading through x265 documentation, I'm seeing alot of reference to NxN. What does N reference to?

e.g. Enable analysis of rectangular motion partitions Nx2N and 2NxN (50/50 splits, two directions).

[Jamaika]

Unless there is a problem with yuv420p10le, but the yuv422p10le is much larger banding and the film is darker. (colormatrix bt2020, colorrange full). Decoder LAVFilters + madVR. I don't know why it is like that.

[jlpsvk]

Ok. Did some test with X-Men - Apocalypse bluray with GeForce GTX 1060 GPU (Pascal) to HEVC 10bit.

Screens:
http://www101.zippyshare.com/v/IMP3zy2H/file.html

NvEncC64 (3.01) encode settings in latest StaxRip Nightly:
--cqp I:P:B --codec h265 --ref 4 --gop-len 240 --max-bitrate 160000 --aq --colormatrix bt709 --colorprim bt709 --transfer bt709 --cabac --no-deblock --fullrange --output-depth 10 --enable-ltr --lookahead 32

Did test with I:P:B: 18:20:24, 19:21:25: 20:22:26.
Screens from untouched BD also included.

B-frames are generally useless, as Pascal supports B-frames in AVC/h264 only. So no B-frames for HEVC. :( Indeed, I think that Pascal is doing very good job in terms of speed/quality. I am getting encoding speed around 220fps.

Resulting bitrates:
Bluray - 23.4Mbit/s
18:20:24 - 5.9Mbit/s
19:21:25 - 4.7Mbit/s
20:22:26 - 3.9Mbit/s

Hoping in some opinions.

[Motenai Yoda]

Quick question - Reading through x265 documentation, I'm seeing alot of reference to NxN. What does N reference to?

e.g. Enable analysis of rectangular motion partitions Nx2N and 2NxN (50/50 splits, two directions).

replace N with 4,8,16,32 and 2N with 8,16,32,64
I'm not sure it split 4x4 MB too

[JohnLai]

Ok. Did some test with X-Men - Apocalypse bluray with GeForce GTX 1060 GPU (Pascal) to HEVC 10bit.

Screens:
http://www101.zippyshare.com/v/IMP3zy2H/file.html

NvEncC64 (3.01) encode settings in latest StaxRip Nightly:
--cqp I:P:B --codec h265 --ref 4 --gop-len 240 --max-bitrate 160000 --aq --colormatrix bt709 --colorprim bt709 --transfer bt709 --cabac --no-deblock --fullrange --output-depth 10 --enable-ltr --lookahead 32

Did test with I:P:B: 18:20:24, 19:21:25: 20:22:26.
Screens from untouched BD also included.

B-frames are generally useless, as Pascal supports B-frames in AVC/h264 only. So no B-frames for HEVC. :( Indeed, I think that Pascal is doing very good job in terms of speed/quality. I am getting encoding speed around 220fps.

Resulting bitrates:
Bluray - 23.4Mbit/s
18:20:24 - 5.9Mbit/s
19:21:25 - 4.7Mbit/s
20:22:26 - 3.9Mbit/s

Hoping in some opinions.

Wait...Pascal only 220fps for 1080p hevc encoding? Sound like CPU decoding bottleneck. Did you use hardware accelerated decoding? It is located at Basic-->Decoder-->nvencc (Native).

*Did you know one can use high quality resizer through --vpp-resize option? (assuming if you resize the video) Need to extract NPP stuff to nvencc location for cubic_bspline, cubic_catmull, cubic_b05c03, super, lanczos, bilinear, spline36 usage.

*Nvenc only make use of single reference frame for hevc encoding. It doesn't matter how many ref you specified.

*There is slight quality issue with CQP mode. It is hard to explain, so... nah, most people won't notice it anyway. Lazy to explain.

[jlpsvk]

just about CPU... i7-3930K (6-core with HT) is about 15% slower in encoding with x265 2.1+47 to HEVC 10bit 3840x1600 than i5-6600 (4-cores, no HT).

[davidsama]

2.1+55-67e980e is out now. Try that and see if it is any faster for you.

[CruNcher]

Wait...Pascal only 220fps for 1080p hevc encoding? Sound like CPU decoding bottleneck. Did you use hardware accelerated decoding? It is located at Basic-->Decoder-->nvencc (Native).

*Did you know one can use high quality resizer through --vpp-resize option? (assuming if you resize the video) Need to extract NPP stuff to nvencc location for cubic_bspline, cubic_catmull, cubic_b05c03, super, lanczos, bilinear, spline36 usage.

*Nvenc only make use of single reference frame for hevc encoding. It doesn't matter how many ref you specified.

*There is slight quality issue with CQP mode. It is hard to explain, so... nah, most people won't notice it anyway. Lazy to explain.

Hmm sounds indeed a little slow for Pascal HEVC depending on the bitrate and fps he talks about the 220 fps standing for :)

GM204 1080p PAL 25 FPS target 4 MBits

encoded 51445 frames, 137.58 fps, 3973.15 kbps, 974.65 MB
encode time 0:06:13 / CPU Usage: 5.48%

frame type IDR 206
frame type I 206, avgQP 24.41, total size 15.43 MB
frame type P 51239, avgQP 26.87, total size 959.22 MB

[Jawed]

Can we keep other encoders off this thread?

[Barough]

x265 v2.1+55-67e980e22c43 (http://www21.zippyshare.com/v/QAiqyE4J/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[pradeeprama]

just about CPU... i7-3930K (6-core with HT) is about 15% slower in encoding with x265 2.1+47 to HEVC 10bit 3840x1600 than i5-6600 (4-cores, no HT).

This is a very interesting comparison. The i7-3930K has 12 threads overall while the i5-6600 has only 4 threads. (Full spec comparison at http://ark.intel.com/compare/88188,63697.) Despite this, the fact that the i5-6600 achieves 15% over i7-3930K is rather impressive! The reason is because of improved single-thread performance because of AVX2 code in x265, by better pre-fetching to reduce latency, and better memory bandwidth response in the 6th gen cpu.

My bet is that with the Skylake generation (6th gen), the # HW threads where memory limits x265's performance will be much more than the # HW threads where memory limits in the Sandybridge generation (3rd gen) as x265 really benefits from all the improvements in memory bandwidth that Skylake has to offer.

[jlpsvk]

Hehe... will do the comparison with i7-6700K as soon as it will come from warranty claim.. :)

[filler56789]

x265 v. 2.1+59 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467483#post2467483

[x265_Project]

Some progress on the HEVC patent licensing! This means that applications like VLC and Handbrake, as well as web browsers and mobile apps with HEVC software implementations are royalty free with respect to HEVC Advance.
HEVC Advance Software Policy (http://epdf.hevcadvance.com/pdf/embed?hash=84f7cae5df5424fcfbc82fb2d83fbca5)

HEVC Advance Presentation Explaining Software Policy (http://epdf.hevcadvance.com/pdf/embed?hash=d8d319a061a2c345707db25f6c9cefc5#7)

[sneaker_ger]

VLC and HandBrake also make use of HEVC hardware decoders/encoders.

[dipje]

But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right?

edit:
Just to make clear, it's great news of course! Not trying to be negative here :P.
Does this also mean that making official binaries is on the table or are there other techniques / patens / library-parts that may not be redistributed in binary form?

[x265_Project]

VLC and HandBrake also make use of HEVC hardware decoders/encoders. That's OK. They can only make use of a hardware encoder/decoder that has already been enabled (with the necessary driver) on the device. In that situation, the device manufacturer was already liable to pay the HEVC Advance royalty when they sold or later enabled the hardware encoder/decoder. Software that looks for hardware HEVC encoders/decoders, and uses them when they are present, isn't subject to a separate royalty.

[nevcairiel]

VLC and HandBrake also make use of HEVC hardware decoders/encoders.

The hardware maker would pay the licenses for that, then. Or so I would assume. They make the decoder afterall, software just accesses it.

[x265_Project]

But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right? Correct.

The point here is that HEVC Advance is looking for one royalty per device. Prior to this new policy, every software application that included an HEVC software implementation would have been liable for a separate "device royalty". This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties. The caveats you see in the policy are designed to not allow device OEMs (HP, Dell, Apple, Samsung, etc.) to use the policy to avoid paying that one royalty on a device that they sell as being HEVC capable.

[Boulder]

x265 v. 2.1+59 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467483#post2467483I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.

[dev84]

Hi

This is what i get:

https://s13.postimg.org/xsri3epk3/vlcsnap_2016_11_22_22h00m05s203.png (https://postimg.org/image/xsri3epk3/)

Here are the logs of input and output file and log from MeGui

http://www.filedropper.com/x265logs

And here is the encoded video

http://www.filedropper.com/c0005-muxed


Any idea why is this happening?

[sneaker_ger]

Plays fine here both using VLC and MPC-HC. Try latest versions of both and try software decoding.

If it still errors try ffplay. If that has error too report to ffmpeg bug tracker.

[dev84]

hmmm
have no idea i use VLC 2.2.4
i did system restore on the weekend something must be wrong with cfg, but im lost as to what :(

but this helps me a lot checking the video on other pc

thx

[WhatZit]

This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties.

Currently, any AVC vs HEVC comparisons are the subject of specialised forums such as this one, which have limited visibility.

Taking the lead-time for commercial editing/encoding software development into account, this change means that we will FINALLY start seeing a plethora of "x264 vs x265" articles appearing in the mainstream.

This can only be a very good thing for the fostering of HEVC demand.

[nevcairiel]

This is just HEVC Advanced though, how is the MPEG-LA's stance on this?

[x265_Project]

This is just HEVC Advanced though, how is the MPEG-LA's stance on this?

At the moment, there is no change in their license program. I'm optimistic that the companies who have pooled their HEVC patents in MPEG LA's license program will recognize the wisdom of adopting this policy enabling most software implementations to be royalty free.

[burfadel]

I did a quick test with the revised -tu-limit settigs in 2.1+59. I had both inter and intra TU levels set at 4. No point using anything less since the whole point of this is to be able to make use of a higher inter TU without the performance penalty, right? So 4 makes sense, and likewise therefore 4 for intra as well.

What I found was --limit-tu 3 appeared the nicest to look at without any penalty of file size worth mentioning. I redid the tests with PSNR and SSIM stats enabled. Yes I know that with psy etc this isn't exactly a good way of testing, but --limit-tu 3 had better PSNR and SSIM, which matched what I saw visually. Do take into mind that I did the subjective visual test first without seeing the results.

[LigH]

x265 2.1+59-a895b6344a82 (https://www.mediafire.com/file/q63pahl3why2fm0/x265_2.1+59-a895b6344a82.7z)

CLI changes:
(new)
--scenecut-bias <0..100.0> Bias for scenecut detection. Default 5.00

(changed descr.)
--[no-]vui-timing-info Emit VUI timing information in the bistream. Default enabled
--[no-]vui-hrd-info Emit VUI HRD information in the bistream. Default enabled
--[no-]opt-qp-pps Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
--[no-]opt-ref-list-length-pps Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

[burfadel]

x265 2.1+59-a895b6344a82 (https://www.mediafire.com/file/q63pahl3why2fm0/x265_2.1+59-a895b6344a82.7z)

CLI changes:
(new)
--scenecut-bias <0..100.0> Bias for scenecut detection. Default 5.00

(changed descr.)
--[no-]vui-timing-info Emit VUI timing information in the bistream. Default enabled
--[no-]vui-hrd-info Emit VUI HRD information in the bistream. Default enabled
--[no-]opt-qp-pps Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
--[no-]opt-ref-list-length-pps Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

Plus there's --limit-TU 3 and 4, although command line help doesn't show it. The information is available with the full x265 documentation though: http://x265.readthedocs.io/en/default/cli.html#cmdoption--limit-tu

--limit-tu <0..4>

Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU’s depth, limits recursion of other split subTUs.
Level 3 - based on the average depth of the co-located and the neighbor CUs’ TU depth, limits recursion of the current CU.
Level 4 - uses the depth of the neighbouring/ co-located CUs TU depth to limit the 1st subTU depth. The 1st subTU depth is taken as the limiting depth for the other subTUs.

Default: 0

Not quite a direct quote as I think it is easier to read like above instead of all being in one paragraph. I simply changed it so each level is represented as a new line.

As I said previously, I believe 'level 3' which I bolded above gives the most favourable results IMO.

[Gravitator]

Megablock very bad impact on the formation of each of the second frame (wood edge demonstrates). > test(p-b).mkv (http://files.videohelp.com/u/227452/test(p-b).mkv)

[Barough]

x265 v2.1+59-a895b6344a82 (http://www66.zippyshare.com/v/T5jgAbsH/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[pradeeprama]

I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?

[Boulder]

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?Sure, here's the command line I used to test:

vspipe.exe --y4m "c:\x265\hotfuzz.vpy" - | C:\sources\x265\build\vc14-x86_64\Release\x265.exe --input - --y4m --input-depth 16
--dither --sar 1:1 --profile main10 --keyint 480 --ref 5 --rskip --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slower --rc-lookahead 60 --deblock -3:-1 --no-strong-intra-smoothing --limit-refs 3 --limit-modes --limit-tu 0
--tu-inter-depth 4 --tu-intra-depth 4 --merange 38 --tune grain --crf 21 --csv q:\hotfuzz_limittu0.csv --csv-log-level 2 --output "q:\hotfuzz_limittu0.hevc"

Here are the csv logfiles from my five encodes at different values for --limit-tu : https://drive.google.com/open?id=0BzeF_1syecQwRHJLdVNfRDdNbWM

In my tests, the bitrate and encoding speed was as follows:

--limit-tu 0 : 4875.60 kbps, 1.64 fps
--limit-tu 1 : 4899.45 kbps, 1.84 fps
--limit-tu 2 : 4990.49 kbps, 1.93 fps
--limit-tu 3 : 5037.98 kbps, 1.99 fps
--limit-tu 4 : 5044.37 kbps, 2.02 fps

The black mattes were cropped and the result downsized to 1280x544. The original source clip is here: https://drive.google.com/open?id=0BzeF_1syecQwakhsX3RuZGhWcjA

[burfadel]

Which did you find looked better?

[Boulder]

Which did you find looked better?

It's really hard to tell. I could even say that there is no clear winner there, especially if you don't use still frames to compare.

[K.i.N.G]

Hi anyone know if it is possible to use the x265 encoder on android devices?

I've got a Nvidia Shield (Tegra X1 cpu) which encodes x264 pretty well (via the plex app).
So since x264 works on it, I 'assume' x265 is possible aswell?

I googled it a few times and searched in the play store but I can't find any apps/tools available (yet)..

[sneaker_ger]

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

[LigH]

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

[filler56789]

x265 v. 2.1+60

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467866&viewfull=1#post2467866

[K.i.N.G]

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

Yeah that's what I thought but the presets they use are exactle named as the x264 ones... so I later 'assumed/hoped' it could be x264.
Plex also runs on multiple platforms which many aren't intel and/or nvidia related (windows, unix, my NAS, etc...)

anyway, you're right about contacting them. Wil do so.

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

its not really a portable device though and its cpu/gpu got some more punch (still not close to an i7 or i5 naturally)...
And the reason I want to use it for encoding is exactly the point you bring up: time & power...
I dont need the power of my media station as much as I need my work station :)
I wouldnt mind if it needs a whole week. As long as I can set it as a lower priority task so i can watch a movie from time to time in between.

[LigH]

OK, so I maybe confused the "controller tablet" with the host on one hand, and CPU with GPU on the other, when I first read another source of technical facts.

According to the English Wikipedia, the Tegra X1 has a Dual QuadCore structure (four ARM Cortex-A57 cores and four ARM Cortex-A53 cores in big.LITTLE configuration). And this "big.LITTLE" architecture may cause some issues (http://www.mono-project.com/news/2016/09/12/arm64-icache/), as I recently read: Threads can be shifted between either kind of CPU, depending on their processing power demand, and must always be aware of whether they run on a CPU with a small or a large cache line. And efficient use of cache lines is a very important speed optimization strategy.

My conclusion for now would be that x265 developers would need to double-check strategies to support this architecture class. They would neither wish to get their threads shifted to a low-power core, nor would they enjoy data corruption due to false assumptions about cache line capacities in an unfortunate moment.

[K.i.N.G]

Well,... I looked again and it's indeed using the x264 encoder.
Don't know why I missed the obvious the last time I checked... oh well :p

http://i.imgur.com/lHuLE9J.jpg

And got a reply in the plex forums aswell (yes, i'm feeling stupid now)
:
"Yes, it is the x.264 library in a highly customized version of ffmpeg."
So how hard would it be to include x265?

[LigH]

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

[K.i.N.G]

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

Ok, so if I get it correctly the already heavily modified ffmpeg they have already (to make x264 work on it) would not be enough?
To support x265 they need to heavily re-adjust it again? Too much difference between x264 and x265?

Sounds like you're pretty sure it wont happen anytime soon... :(
I think it will happen eventually at some point though...

[LigH]

I don't know how "heavily" PLEX had to modify ffmpeg. I just assume they did not include libx265, like libx264. Possibly because there is no certain support for your platform (OS and CPUs) yet. Because x265 depends a lot on optimal use of the available CPU architecture, it would be a very bad idea to compile it without any assembler optimization; yet, it may be possible. But in this case, expecting a week per movie is not unrealistic. Nevertheless, the mentioned problems with the big.LITTLE architecture may also happen for code generated by C/C++ compilers only, this is a general risk factor.

[K.i.N.G]

Ok, thank you for your patience and the great explanation :thanks:

[Kavitha]

I did a quick test with the revised -tu-limit settigs in 2.1+59. I had both inter and intra TU levels set at 4. No point using anything less since the whole point of this is to be able to make use of a higher inter TU without the performance penalty, right? So 4 makes sense, and likewise therefore 4 for intra as well.

What I found was --limit-tu 3 appeared the nicest to look at without any penalty of file size worth mentioning. I redid the tests with PSNR and SSIM stats enabled. Yes I know that with psy etc this isn't exactly a good way of testing, but --limit-tu 3 had better PSNR and SSIM, which matched what I saw visually. Do take into mind that I did the subjective visual test first without seeing the results.



yes, on testing limit-tu options with several videos observed that limit-tu 4 gives the best SSIM and visually limit-tu 1 and 3 are good

[filler56789]

x265_2.1+63 (commit 5ae077d7053d)

SEA motion search Implementation 0_o

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2468451&viewfull=1#post2468451

[LigH]

And again, and again, over and over: Could anyone please, pretty please, show me diagrams of different motion search ranges, so I can visually imagine their difference? In this topic, I am out of luck using Google (including their image search engine).

[MoSal]

(Using x265 2.1)

I did two encodes from the same source(BD 1080i + w3fdif).
The first output is 60fps.
The second is 30fps (roughly dropping every other frame).
All other settings are equal including crf and keyint.

The 2nd encode ended up with a larger bitrate (~11.3Mb/s vs. ~9.7Mb/s).
QP values used for I/P/B frames are also significantly lower in the 2nd encode.

Is this intended behavior?


ffmpeg -i sample.mkv -vf w3fdif -c:v hevc -preset slower -crf 19 -x265-params keyint=500:psy-rd=3:psy-rdoq=6:sao=0:qcomp=0.72:ipratio=1.18:pbratio=1.23:deblock=-2,-2 60.mkv

ffmpeg -i sample.mkv -vf w3fdif -c:v hevc -preset slower -crf 19 -x265-params keyint=500:psy-rd=3:psy-rdoq=6:sao=0:qcomp=0.72:ipratio=1.18:pbratio=1.23:deblock=-2,-2 -r 30 30.mkv

I can upload the sample if needed.

[Magik Mark]

x265_2.1+63 (commit 5ae077d7053d)

SEA motion search Implementation 0_o

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2468451&viewfull=1#post2468451

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

[filler56789]

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

I don't know 0_o I just compile x265.exe and share my builds. I don't even do minimal encoding tests anymore.

[ispano]

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

From x265 docs:

SEA is similar to FULL search; a three step motion search adopted from x264: DC calculation followed by ADS calculation followed by SAD of the passed motion vector candidates, hence faster than Full search.

0. dia
1. hex (default)
2. umh
3. star
4. sea
5. full

[Jamaika]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

[LigH]

Anyone please visualize them!

[jlpsvk]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

encode times and bitrates?

[microchip8]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

why you use --sao on the first but disable it on the second? Why pbratio of 1.5 on the first but 1.1 on the second?

[Jamaika]

There is no reasonable good response.
The problem of the quality of my dissatisfaction relates to frames B.
So for that particular codec visually better for me it was the pbratio 1.5.
From my investigation I found that adding sao will not impair the quality of the video. Only convert film lasts longer.
I couldn't improve sao and pbratio. The film had anyway visually better quality.
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L4.1@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1 min 2 s
Source duration : 1 min 2 s
Bit rate : 4 278 kb/s
Maximum bit rate : 8 589 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.069
Stream size : 31.7 MiB (96%)
Source stream size : 33.0 MiB (100%)
Encoded date : UTC 2016-11-30 17:45:01
Tagged date : UTC 2016-11-30 17:45:01
Color range : Full
Color primaries : BT.2020
Transfer characteristics : BT.2020
Matrix coefficients : BT.2020 non-constant

ffmpeg.exe -loglevel verbose -i "yabadu20.avi" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le -strict -1 - |
x265.exe --y4m --input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --fps 29.970 --keyint 60 --no-info --no-open-gop --no-hrd --high-tier --me sea --aq-mode 0 --no-cutree --ipratio 1.0
--pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip --vbv-bufsize 40000 --vbv-maxrate 40000 --colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 --limit-ref 0 --range full --output "x265_422p10le_crf28.h265" -

[microchip8]

it's not a fair comparison, then. You should use exact same options for both, only for the first one --me sea and for the second one --me star. It doesn't matter what you're dissatisfied with since we're comparing the "raw motion estimation" and everything else should be the same to make a fair comparison. Also keep in mind that --sao will blur and smooth and I suspect that is why the first (with --sao enabled) doesn't have such banding like the second with --sao off

[CruNcher]

I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

Please specify especially for H.264 or H.265 their shouldn't be virtually any decoding differences

[Jamaika]

it's not a fair comparison, then. You should use exact same options for both, only for the first one --me sea and for the second one --me star. It doesn't matter what you're dissatisfied with since we're comparing the "raw motion estimation" and everything else should be the same to make a fair comparison. Also keep in mind that --sao will blur and smooth and I suspect that is why the first (with --sao enabled) doesn't have such banding like the second with --sao off
What was I thinking?
http://forum.doom9.org/showthread.php?p=1788180#post1788180

[microchip8]

What was I thinking?
http://forum.doom9.org/showthread.php?p=1788180#post1788180

it doesn't matter what you were thinking. As I said, if you fairly want to compare two different MEs, the only thing that should differ is the MEs themselves. No other options should be touched, regardless if you think this or that doesn't look good so let's go tweak a bit but leave the other out

[Jamaika]

Now added the two films with the same parameters with me star and sea. You can see the differences in the pictures sendspace.

[Barough]

x265 v2.1+64-e44b7b50f24c (http://www69.zippyshare.com/v/mUKK5NVp/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Selur]

Anyone please visualize them!
-> @LigH: see http://forum.doom9.org/showthread.php?p=693742 for diamond, hex, umh, exhaustive
or
diamond, hex: http://www.ijser.org/paper/OVERVIEW-OF-MOTION-ESTIMATION-IN-VIDEO-COMPRESSION.html
star, diamond; http://www.ntu.edu.sg/home/ekkma/1_Publications_files/A%20NEW%20STAR%20SEARCH%20ALGORITHM%20FOR%20FAST%20BLOCK%20MATCHING,%20International%20Workshop%20on%20Very%20Low%20Bit%20Rate%20Video%20Coding%20(VLBV'98),%20Urbana,%20Illinois,%20USA,%208-9%20October%201998,%20pp.%20173%20-%20176..PDF
umh: http://www.cnblogs.com/TaigaCon/p/3788984.html
No clue how to visualize something like sea,... (would probably need some animation or multiple images for an example case)

[LigH]

Knowing that SEA means "Successive Elimination Algorithm", I found some links to scientific papers. It appears to be parallelizable rather easily, having a tree structure.

One brief summary at IEEE Xplore (http://ieeexplore.ieee.org/abstract/document/1367351/).

Possible display: eSilicon Labs HEVC slide, images 79 and 93 of 159 (http://www.slideshare.net/VinayagamMariappan1/video-codecs-62801463)? Links to single images (with descriptions) are below the slide.
_

In general, it will be important to understand that the search for the optimal motion vector will usually start in the neighborhood of the last known motion vector of each (block / macroblock / coding unit ?), assuming a usually continuous linear motion per scene. In case of a next P frame, that would probably be a repeated last P frame MV. In case of a B frame, that would probably be the fraction of the last P frame MV, in relation to its position in between.

[filler56789]

x265.exe v. 2.1+66

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2469269&viewfull=1#post2469269

[Barough]

x265 v2.1+66-b2d360143d96 (http://www2.zippyshare.com/v/lxB6AgDb/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[filler56789]

x265 v. 2.1+69

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2469617&viewfull=1#post2469617

[LigH]

x265 2.1+69-c97c64ab8b8e (https://www.mediafire.com/file/p18wa7lm9tdbaiw/x265_2.1+69-c97c64ab8b8e.7z)

As mentioned above: SEA motion search implemented, several fixes and optimizations in addition.

[Majorlag]

x265 is coming together rather well. I have finally decided to switch over from x264,

Only one thing is still bothering me, and it only started recently. x265_2.1+59 seemed to be a great improvement over previous builds in my encodes, but in +59 and +69, the encoding settings show stats-file= location. x265_2.1+36 and below did not seem to show as much detail. I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Keep up the Great work.

[LoRd_MuldeR]

I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Judging from the code, doesn't look so:
char *x265_param2string(x265_param* p, int padx, int pady)
{
[...]
if (p->rc.rateControlMode == X265_RC_ABR || p->rc.rateControlMode == X265_RC_CRF)
{
[...]
if (p->rc.bStatRead || p->rc.bStatWrite)
s += sprintf(s, " stats-file=%s", p->rc.statFileName);

(If RC mode is either ABR or CRF and if a stats file is read or written, then the stats file location will be logged)

[aymanalz]

What is the general opinion on SAO now? Does it still blur too much, or cause much loss of detail? Is it generally recommended to be used in most cases?

[gnol009]

Hello guys. Here my cmd line settings:

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 1 --stats ".stats" --bframes 8 --aq-strength 0.9 --b-intra --no-amp --no-strong-intra-smoothing --no-sao -o NUL 2> pass12.log

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 2 --stats ".stats" --preset slower --ctu 32 --no-amp --aq-mode 3 --deblock -3:-3 --cbqpoffs -3 --crqpoffs -3 --aq-strength 0.9 --rd 4 --psy-rd 4.0 --psy-rdoq 10.0 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --no-sao --ipratio 1.3 --pbratio 1.2 -o "T3.hevc" 2> pass22.log

And here media info encode setting:

x265 2.1+69-c97c64ab8b8e:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=2129 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=35 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=2 / subme=3 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=3.00 / psy-rdoq=10.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=-3 / crqpoffs=-3 / rc=abr / bitrate=9000 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=.stats / cplxblur=20.0 / qblur=0.5 / ipratio=1.35 / pbratio=1.25 / aq-mode=3 / aq-strength=0.90 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05

Does anyone know why media info show rc=abr?

[Boulder]

Because you are doing a 2-pass encode which means ABR.

[Ma]

[...] if there is an option to turn off only stats-file= information from the encodes.

Like LoRd_MuldeR wrote, there isn't, but all OpenSource projects have one super option -- you can change what you want.

If you don't want to modify source code by yourself, you can download modified and compiled version: www.msystem.waw.pl/x265/x265-2.1+69-c97c64a_Win34-no-stats.7z

Inside the archive there is diff file from original sources and Windows binaries compiled by VS 2017 (and GCC 5/6/7 with names x265gccN.exe).

[sneaker_ger]

I don't think it is a good idea. It has the potential to leak personal information, e.g. if your Windows user name equals your real name and the stats file is somewhere in your user directory. Some GUIs might have their working directory there so you wouldn't even notice. I also wonder if it could lead to problems with long path names. I vaguely remember a program crashing when the custom SEI became too long.

Question:
Why stats-read=2? Is there a "1"?

[Ma]

Why stats-read=2? Is there a "1"?

No, it is 0 or 2, see source:
OPT("pass")
{
int pass = x265_clip3(0, 3, atoi(value));
p->rc.bStatWrite = pass & 1;
p->rc.bStatRead = pass & 2;
}

For pass 2 and pass 3 it is '2', for pass 1 and no pass it is '0'.

[x265_Project]

x265 is coming together rather well. I have finally decided to switch over from x264,

Only one thing is still bothering me, and it only started recently. x265_2.1+59 seemed to be a great improvement over previous builds in my encodes, but in +59 and +69, the encoding settings show stats-file= location. x265_2.1+36 and below did not seem to show as much detail. I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Keep up the Great work.

Thanks for your feedback. I agree that we shouldn't write the stats file info... it's a potential privacy issue, and it isn't really useful a part of the info. I'll ask the developer who made the last patch to revert this.

Tom

[x265_Project]

Hello guys. Here my cmd line settings:

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 1 --stats ".stats" --bframes 8 --aq-strength 0.9 --b-intra --no-amp --no-strong-intra-smoothing --no-sao -o NUL 2> pass12.log

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 2 --stats ".stats" --preset slower --ctu 32 --no-amp --aq-mode 3 --deblock -3:-3 --cbqpoffs -3 --crqpoffs -3 --aq-strength 0.9 --rd 4 --psy-rd 4.0 --psy-rdoq 10.0 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --no-sao --ipratio 1.3 --pbratio 1.2 -o "T3.hevc" 2> pass22.log

And here media info encode setting:

x265 2.1+69-c97c64ab8b8e:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=2129 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=35 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=2 / subme=3 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=3.00 / psy-rdoq=10.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=-3 / crqpoffs=-3 / rc=abr / bitrate=9000 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=.stats / cplxblur=20.0 / qblur=0.5 / ipratio=1.35 / pbratio=1.25 / aq-mode=3 / aq-strength=0.90 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05

Does anyone know why media info show rc=abr?

When you use the --bitrate command, you're engaging x265's ABR (Average Bit Rate) rate control mode, as opposed to constant QP or CRF rate control, which are fundamentally different.

[Selur]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)

[Jamaika]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)
Maybe high time to give yourself a peace of MP4Box.

[Ajvar]

Knowing that SEA means "Successive Elimination Algorithm", I found some links to scientific papers. It appears to be parallelizable rather easily, having a tree structure.

Possible display: eSilicon Labs HEVC slide, images 79 and 93 of 159 (http://www.slideshare.net/VinayagamMariappan1/video-codecs-62801463)? Links to single images (with descriptions) are below the slide.

SEA is "lossless" searching method with "compression".
Exhaustive = 8x8 square = 64 searching points and 196 sp for 14x14.
SEA = 8+9+9 = 26 sp (27 if analize starting pixel in center) while fully covering same 14x14 square. Pretty easy to get once you look at page 79. 3 steps search: 4 pixel long, then 2, then 1.

[LigH]

So it is indeed quite similar to UMH: Progressive precision, narrowing down to the optimum in several passes.
__

P.S.:

I hope I understood them all good enough to display them correctly and comprehensibly... added to the thread Motion Search Method (http://forum.doom9.org/showthread.php?p=1789660#post1789660) (sorry for necro, but there is the optimal place).

[NikosD]

Just a quick bench using latest StaxRip x64 v1.4.0.0 which has x265 v2.1+69 inside, this time in 10bit HEVC.

So, using the default settings of Medium preset on the same source I got these results:

Core i3-4170
494.20s (1.01 fps)

Core i5-2400
524.81s (0.95 fps)

A Haswell Core i3 at 3.7GHz with 8GB DDR3-1600MHz-CL9 which is a 2C/4T CPU (~2C + ~40%) is a little faster than a Sandybridge Core i5 at 3.2GHz (using Turbo) with 12GB DDR3-1333MHz-CL9 which is a 4C/4T CPU, both under the same OS (Win 10 x64 latest) using significantly less power consumption (35W vs 54W measured consuption).

Impressive.

Of course in a few months a new star will be born - AMD RyZen 8C/16T CPU - which according to the yesterday's Live Show using Handbrake, is a tad faster than Broadwell-E Core i7-6900K.

This is even more impressive when you see that RyZen has 95W TDP and the Core i7-6900K has 140W TDP.

[Magik Mark]

Does anyone knows which version of x265 is being used by adobe media encoder 2017?


Sent from my iPhone using Tapatalk

[sneaker_ger]

A Haswell Core i3 at 3.7GHz with 12GB DDR3-1333MHz-CL9 which is a 2C/4T CPU (~2C + ~40%)
40% is probably an over-estimate but AVX 2.0 also plays a big role for x265. It is the combination of higher clock, higher IPC and AVX 2.0 plus the HT making up a bit for 2 less cores.

[sneaker_ger]

Does anyone knows which version of x265 is being used by adobe media encoder 2017?
Do they use x265 at all? "Adobe" is listed as a reference on the Mainconcept website.

[NikosD]

40% is probably an over-estimate but AVX 2.0 also plays a big role for x265. It is the combination of higher clock, higher IPC and AVX 2.0 plus the HT making a bit up for 2 less cores.

Exactly.
This is why I posted the results in order to show the big difference of AVX2.

Your post revealed that I wrote the memory configuration reversed, so I corrected RAM configuration.
The 12GB DDR3-1333MHz is for Sandy of course and 8GB DDR3-1600MHz is for Haswell.

The main question, one of a few important actually, is how come RyZen with half AVX2 speed of Haswell and onwards CPUs can match Broadwell-E in HandBrake ?

I haven't seen the details of the benchmarks used in the live show of RyZen but I think it could be x264 after all.

Or RyZen has some secret weapons.

[nevcairiel]

Or they used open-source software for benchmarks so they could write specifically optimized versions first, they didn't exactly elaborate on any of the numbers, just showed them fully without background. Independent reviews is when it'll be interesting.

PS:
The handbrake demo in AMDs presentation used x264, not x265 (ie. they said the ipod target or something like that, which is h264). Not sure how huge AVX2 is for x264.

[NikosD]

I think their secret lies in this:

"Moreover, AMD claims to have plenty of processing power left on tap, thanks to a host of efficiency tweaks it's dubbed SenseMI (Machine Intelligence). The first is "Pure Power," which is a set of temperature, clock speed, and voltage sensors that promise more efficient power delivery to the CPU. "Precision Boost" takes that information and uses it to adjust the clock speed on-the-fly "without halts or queue drains" in small 25MHz increments.

This ties into "Extended Frequency Range" (XFR), which AMD claims will boost the clock speed of Ryzen outside of the (as yet unspecified) typical range if a user has suitably robust cooling. Those running big air coolers, all-in-one liquid coolers, or full watercooling loops will apparently see a big improvement compared to a stock cooler. The process is entirely automated, so even those without any overclocking skills can gain a performance boost. That said, fully manual overclocking is still supported for power users.

The final two tweaks—"Neural Net Prediction" and "Smart Prefetch"—help to shuffle data through the CPU more effectively. AMD claims there's a "true artificial network" and "learning algorithms" inside Ryzen that are able to predict future decisions, pre-load instructions, and learn application data access patterns in order to improve performance. That's aided by a beefy 4MB of L2 cache and 16MB of L3 cache.

[x265_Project]

Do they use x265 at all?

They don't.

[LigH]

x265 2.1+70-78e1e1354a25 (https://www.mediafire.com/file/2dkjjg82gi2t7wi/x265_2.1+70-78e1e1354a25.7z) – "merge with stable" build; prepare for v2.2 "soon™"!

[Barough]

x265 v2.1+71-e8152da7aa0e (http://www79.zippyshare.com/v/jazWkifH/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[CruNcher]

llittle oftopic: Anyone found the Bitstream that was used for the Handbrake Transcoding Demo SU talked about making publicly available on AMD.com which destination was best.mp4 ;) ?

[dipje]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)

Did a 10bit 4:2:0 test with the latest LigH build. Works just fine here.

As I read that bug-report page it's likely an interplay between your x265 settings and mp4box having an issue with it. If you use 'normal' command line parameters it appears there is no issue

[Selur]

@dipje: from the issue tracke, the current state is that you can either use '--opt-qp-pps --opt-ref-list-length-pps' or '--repeat-headers' - but not both at the same time - if you want to use MP4Box.
So, yes. Depending on your settings you might never encounter this problem, but that is probably true for most of the bugs in source code out there. :D

[dipje]

Just don't use any of those 3 switches. You have a reason for really wanting them ?

[brumsky]

llittle oftopic: Anyone found the Bitstream that was used for the Handbrake Transcoding Demo SU talked about making publicly available on AMD.com which destination was best.mp4 ;) ?

Sure haven't, they even said we'd be able to download it and to run the test... If you find it please share it!

[Selur]

You have a reason for really wanting them ?
--opt-qp-pps --opt-ref-list-length-pps are enabled by default in newer builds and they give a small compression gain,...

[dipje]

Later than that latest ligh build ? It was the one prepping for 2.2... It was .70, your report is from before that.
Or are they enabled by default if you go towards veryslow or placebo presets or something ?

[Selur]

These two options ( '--opt-qp-pps' and '--opt-ref-list-length-pps') are enabled by default since 2016-10-17 (304116f4cd41bc4fd610d5b16c6f447a50b8df02). :)
(btw. the problem is on a good way to get resolved, see bug tracker)

[filler56789]

What to expect from a team (namely: GPAC) which still refuses to support VC-1 and DTS in the MP4 container?

Only more rationalization, more lame excuses, more lies.

[sneaker_ger]

GPAC refused to accept your VC-1 and DTS patches?

[dipje]

@selur still weird that I don't have any problems at all and according to what you're saying I should have it as well.

[Selur]

@dijpe: Not weird since it also only happens with some sources. A few users of Hybrid mentioned the problem to me and I couldn't reproduce it until one of them shared a sample with me that allowed me to reproduce the issue and share it with the x265&mp4box devs which are now really active. :D
Personally I'm pretty pleased with the general feedback I get as user from those two development teams.

[LigH]

Santa was here...

x265 version 2.2 has been released. This release contains new algorithms to limit the search of optimal transform units, a new motion search method, and optimizations to the bitstream. With this release, x265 also supports POWERPC platforms, with key functions optimized by using ALTIVEC kernels.

The latest version can be downloaded from here (https://bitbucket.org/multicoreware/x265/downloads/x265_2.2.tar.gz) (MD5 sum = 36161843a70e4d46af1fa38cf221d0f3). Full documentation is available at http://x265.readthedocs.io/en/stable/.

Release Notes for 2.2
================

Encoder enhancements
----------------------------------
1. Enhancements to TU selection algorithm with early-outs for improved speed; use --limit-tu to exercise.
2. New motion search method SEA (Successive Elimination Algorithm) supported now as –me 4
3. Bit-stream optimizations to improve fields in PPS and SPS for bit-rate savings through --[no-]opt-qp-pps, --[no-]opt-ref-list-length-pps, and --[no-]multi-pass-opt-rps.
4. Enabled using VBV constraints when encoding without WPP.
5. All param options dumped in SEI packet in bitstream when info selected.
6. x265 now supports POWERPC-based systems. Several key functions also have optimized ALTIVEC kernels.

API changes
-------------------
1. Options to disable SEI and optional-VUI messages from bitstream made more descriptive.
2. New option --scenecut-bias to enable controlling bias to mark scene-cuts via cli.
3. Support mono and mono16 color spaces for y4m input.
4. --min-cu-size of 64 no-longer supported for reasons of visual quality (was crashing earlier anyways.)
5. API for CSV now expects version string for better integration of x265 into other applications.

Bug fixes
--------------
1. Several fixes to slice-based encoding.
2. --log2-max-poc-lsb‘s range limited according to HEVC spec.
3. Restrict MVs to within legal boundaries when encoding.

Enjoy!
Pradeep.

New "merge with stable milestone" build:

x265 2.2+2-998d4520d1cf (http://www.mediafire.com/file/fll25auuucv1i85/x265_2.2+2-998d4520d1cf.7z)

[Barough]

x265 v2.2+5-e40db0bdde4a (http://www8.zippyshare.com/v/vvCRqXqk/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[need4speed]

Thanks but the sea mse is really so slow or it is just me?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[need4speed]

Same everything, 720p encode 15 fps to 6?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Barough]

Thanks but the sea mse is really so slow or it is just me?

Inviato dal mio GT-N7100 utilizzando Tapatalk
It's slow......

Sent from my Samsung Galaxy S7 edge via Tapatalk

[need4speed]

It's slow......

Sent from my Samsung Galaxy S7 edge via Tapatalk
Thanks, just checking really. Output file seems to be a bit better but IMHO and in my own case not worth it.
Is it compatible with tune grain or any issue?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Barough]

Thanks, just checking really. Output file seems to be a bit better but IMHO and in my own case not worth it.
Is it compatible with tune grain or any issue?

Inviato dal mio GT-N7100 utilizzando Tapatalk
Im short on test files..... had a HD failure but It seems yo give ya a little better output but i don't know how it works with tune grain.....

The loss of speed vs quality gain is not worth it at all imo.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[LigH]

At least SEA is faster than the trivial exhaustive search (every sample in the motion range). But it will probably be about as slow as UMH.

There are several motion search algorithms, though, which may miss the optimal vector when it is quite far away from a predicion, and then an intra coded block or a quite coarse match are required, which would reduce the bitrate/quality ratio. Diamond and Hexagonal will only test a small range around the predicted vector. Of course this will be a lot faster. But it may fail for quite random and wide (shaky) motion.

Different motion search algorithms cannot be incompatible to any other part of the encoding, IMHO. They either are able to find the optinal motion vector, or a suboptimal match has to be encoded and needs to spend more bitrate than minimally required in case of an optimal match.

[pradeeprama]

Thanks, just checking really. Output file seems to be a bit better but IMHO and in my own case not worth it.
Is it compatible with tune grain or any issue?

Inviato dal mio GT-N7100 utilizzando Tapatalk

Don't expect any compatibility issues between tune grain and SEA

[need4speed]

Don't expect any compatibility issues between tune grain and SEA
Thank you all for the reply.
Been playing around for almost two years now with hevc and the improvements have been terrific.
The main issue was and somehow still is grain and detail retention but slowly we're getting there.
Im not a pixel peeper hence at the moment with latest updates I have settled for
Medium, crf 19, main10, output10, ctu32, max tu 16, early skip, limit modes, qcomp 075, me star, no Sao, no strong intras, range limited, deblock - 6-6,tune grain.
This is my setup for TV shows 1920 to 720 and works very well and fast.
Really satisfied but still looking for fine tuning since details are still a bit of an issue. A lot better but still not there.
10-14 fps and really glad about final video.
Any suggestion here to improve details retention?
Thanks again!

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Boulder]

--tune grain works wonders when detail and grain retention are important.

[need4speed]

--tune grain works wonders when detail and grain retention are important.
Tune grain has been a real surprise, and it works wonders.
Again, not a pixel peeper and have tried a lot of fine tuning over there past two years. There is still room for improvement in the detail game but with my preset can't almost tell the difference between avc and hevc.
Speed for quality is my personal goal and, to be honest, messing around with a lot of settings wasn't really any help or difference. Except for tune grain, again.
My biggest concern about hevc is that I don't know anything about some parameters, in terms of how messing around with one can break or spoil another.
The forum is a huge help, a lot of technical details and explanations for each item but not much about how one can influence another and how.
So it's a try and go but, again, a terrific improvement along these two years.
So thanks again for all the hard work!

Inviato dal mio GT-N7100 utilizzando Tapatalk

[aymanalz]

Thanks but the sea mse is really so slow or it is just me?

Inviato dal mio GT-N7100 utilizzando Tapatalk

In my testing, I'm getting about 12-14 FPS with umh and star, and 4 fps with sea, all other settings being the same.

So yes, it is slow, at least for my test clips and parameters.

[LigH]

SEA being a lot slower than UMH surprises me. I expected it to narrow down the square to test more thoroughly in each step. Did you use very large motion search ranges in your test? Or does SEA really test more than narrowing down only the best quadrant so far?

I visualized how I imagine them (http://forum.doom9.org/showthread.php?p=1789660#post1789660) and explained why I see UMH and SEA rather close up (http://forum.doom9.org/showthread.php?p=1789870#post1789870). Unfortunately, no developer with real insight confirmed or corrected yet.

Even the idea by 708145 of adaptively selecting motion search methods (by gathered statistics about the amount of motion, or by assumptions about the efficiency depending on frame prediction types - close B frames may be estimated well with faster methods already) sounds interesting.

[aymanalz]

SEA being a lot slower than UMH surprises me. I expected it to narrow down the square to test more thoroughly in each step. Did you use very large motion search ranges in your test? Or does SEA really test more than narrowing down only the best quadrant so far?

I visualized how I imagine them (http://forum.doom9.org/showthread.php?p=1789660#post1789660) and explained why I see UMH and SEA rather close up (http://forum.doom9.org/showthread.php?p=1789870#post1789870). Unfortunately, no developer with real insight confirmed or corrected yet.

Even the idea by 708145 of adaptively selecting motion search methods (by gathered statistics about the amount of motion, or by assumptions about the efficiency depending on frame prediction types - close B frames may be estimated well with faster methods already) sounds interesting.

I know, and I was rather surprised too, since I had read your explanations earlier.

My experience has always been that umh and star usually have the same speed, within 10% of each other. Neither has been much faster or slower than the other in any of my tests so far.

I just tested a few clips with sea yesterday, and I tried merange of the default 57, and then 40. In both cases, sea was three times slower than umh or star.

I'll wait for more people to report their findings on the question of speed. (Did you test any with sea, btw?)

[LigH]

My mistake about UMH may be that it first checks the narrow neighborhood around the predicted position, and only extends to the wide multi-hex pattern with recursive refinement if the narrow range did not yet find a good match. If it works this way, then it can indeed be about as fast as hex or star when motion is mainly regular and well predicted.

[Przemek_Sperling]

Well, I have to say that x265, in general, behaves different from x264, and I cannot explain it. I have three computers (Intel Core 2 Duo and Sandy Bridge laptops and a AMD Rana powered desktop). I noticed that x265 likes Intel architectures, and I do not write about the Sandy but also about my both old computers. My desktop (AMD Athlon x3 435 oc'ed to 3.71 Ghz) is around twice faster than my laptop (Core 2 Duo 2.4 GHz) if I code DVDs with x264 but only ~50% faster when I switch to x265 (I use VidCoder).
On the other hand both my Intel CPUs are far more vulnerable if I change some settings. Sea slow them down but sea has a minor impact on my AMD CPU.

[HWK]

Well, I have to say that x265, in general, behaves different from x264, and I cannot explain it. I have three computers (Intel Core 2 Duo and Sandy Bridge laptops and a AMD Rana powered desktop). I noticed that x265 likes Intel architectures, and I do not write about the Sandy but also about my both old computers. My desktop (AMD Athlon x3 435 oc'ed to 3.71 Ghz) is around twice faster than my laptop (Core 2 Duo 2.4 GHz) if I code DVDs with x264 but only ~50% faster when I switch to x265 (I use VidCoder).
On the other hand both my Intel CPUs are far more vulnerable if I change some settings. Sea slow them down but sea has a minor impact on my AMD CPU.

Raw speed is not only factor which determine how fast encoder will run, there are other factor such as extension available from host cpu.

[brumsky]

Tune grain has been a real surprise, and it works wonders.
Again, not a pixel peeper and have tried a lot of fine tuning over there past two years. There is still room for improvement in the detail game but with my preset can't almost tell the difference between avc and hevc.
Speed for quality is my personal goal and, to be honest, messing around with a lot of settings wasn't really any help or difference. Except for tune grain, again.
My biggest concern about hevc is that I don't know anything about some parameters, in terms of how messing around with one can break or spoil another.
The forum is a huge help, a lot of technical details and explanations for each item but not much about how one can influence another and how.
So it's a try and go but, again, a terrific improvement along these two years.
So thanks again for all the hard work!

Inviato dal mio GT-N7100 utilizzando Tapatalk


A while back I went through testing a number of settings and combinations of settings. I found that -rd 5 gives the biggest improvement in quality with the least impact in speed. IMHO, it's the best bang for the buck.

[LigH]

@ Przemek_Sperling:

Different avialable instruction set extensions (SSE4+, AVX+) and architecture details (e.g. CPU internal cache strategy, instruction pipelining, etc.) speed up several parts of the encoding differently. Their relation to each other will change with the whole architecture, and you may notice a bottleneck on one CPU architecture in one part of the whole encoding algorithm, and on another CPU architecture in a different one.

There is even a noticable difference among different generations of intel processors.

[need4speed]

A while back I went through testing a number of settings and combinations of settings. I found that -rd 5 gives the biggest improvement in quality with the least impact in speed. IMHO, it's the best bang for the buck.
Will try for sure,thanks!
Still testing with samples from different sources and bitrate. Again, can't see any difference in files with sea or star. Maybe it's just me really, but at this stage wondering what good sea might be.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[birdie]

Well, I have to say that x265, in general, behaves different from x264, and I cannot explain it. I have three computers (Intel Core 2 Duo and Sandy Bridge laptops and a AMD Rana powered desktop). I noticed that x265 likes Intel architectures, and I do not write about the Sandy but also about my both old computers. My desktop (AMD Athlon x3 435 oc'ed to 3.71 Ghz) is around twice faster than my laptop (Core 2 Duo 2.4 GHz) if I code DVDs with x264 but only ~50% faster when I switch to x265 (I use VidCoder).
On the other hand both my Intel CPUs are far more vulnerable if I change some settings. Sea slow them down but sea has a minor impact on my AMD CPU.

Without numbers your comment looks like utter BS.

1) Encoding time for the same source given the same encoder, encoding settings and OS load
2) Throttling data (throttling or not)
3) Frequency data

Then you forget that most recent AMD CPUs have 40-50% lower IPC than most recent Intel CPUs, so naturally Intel CPUs must be faster. Test again after you buy/assemble a PC based on the AMD Ryzen arch. Also mind that AMD CPUs of today don't support the AVX2 instruction set and their AVX implementation leaves a lot to be desired.

Last but not least I am pretty sure most programmers optimize/profile/compile for the most prevalent CPU architecture and that happens to be the Intel's ones.

Instead of a thousand of words:

http://images.anandtech.com/graphs/graph10705/83862.png

The top AMD CPU featuring 4 cores is as fast as Intel's i3 CPU featuring 2 cores.

[Motenai Yoda]

The top AMD CPU featuring 4 cores is as fast as Intel's i3 CPU featuring 2 cores.
AMD's Cpus don't sports 4 core, but 2 core each with 2 ipu/logic modules and a single fpu module.

[mandarinka]

Seems there are two interesting patched on ML, that could bring quality improvements.

https://mailman.videolan.org/pipermail/x265-devel/2016-December/010852.html ("AQMotion")
https://mailman.videolan.org/pipermail/x265-devel/2016-December/010853.html ("SSIM based RDO for mode selection")

@Yoda
That's not really correct, they are way more close to cores than not in their characteristics, including performance. It is just that the per-MHz performance ("IPC") of these cores is very low. If you disable the second thread in each pair, you will only get very low speedup (5-10 % usually).

I mean, you are right that elements including FPU (SIMD unit) are shared. But it is still more correct to call them cores than anything else.

[Atak_Snajpera]

Then you forget that most recent AMD CPUs have 40-50% lower IPC than most recent Intel CPUs, so naturally Intel CPUs must be faster. Test again after you buy/assemble a PC based on the AMD Ryzen arch. Also mind that AMD CPUs of today don't support the AVX2 instruction set and their AVX implementation leaves a lot to be desired.

Too be honest AMD FX does not even have "full" AVX256 like Intel. Proof is here
http://i.cubeupload.com/byOi6P.png

[LigH]

x265 2.2+15-a18ab7656c30 (https://www.mediafire.com/file/wh752cnzrnm994t/x265_2.2+15-a18ab7656c30.7z)

Speedups in multipass encoding (reusing of more 1st-pass data); SSIM based RDO for mode selection; and some bugfixes.

[jlpsvk]

Yay.. :) Getting more than 7fps with RipBot "distributed encoding" on 14-cores together (3 PC's) with setting:
--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp
--cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --rskip
--crqpoffs -3 --high-tier --limit-tu 3 --qg-size 8

Any suggestion for quality increase (not highering bitrate too much).

[pradeeprama]

Yay.. :) Getting more than 7fps with RipBot "distributed encoding" on 14-cores together (3 PC's) with setting:
--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp
--cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --rskip
--crqpoffs -3 --high-tier --limit-tu 3 --qg-size 8

Any suggestion for quality increase (not highering bitrate too much).

If you don't mind the impact to speed, then you can try disabling rskip (--no-rskip), and limit-tu (just remove limit-tu from your command line). You can also try other ME search modes, and increasing subme for better quality.

[shinchiro]

Tried aq-motion setting but there's more noise around edges compared to when disabled

[jlpsvk]

If you don't mind the impact to speed, then you can try disabling rskip (--no-rskip), and limit-tu (just remove limit-tu from your command line). You can also try other ME search modes, and increasing subme for better quality.

What SUBME are you recommending? ME search "higher" than star is slowing down significantly... :(

[LoRd_MuldeR]

SEA being a lot slower than UMH surprises me. I expected it to narrow down the square to test more thoroughly in each step.

I'm not surprised at all :p

To my understanding SEA – this is what x264 uses in "ESA" mode¹, and form there it apparently was ported to x265 – is supposed to be a full search. It is mathematically equivalent to a simple "brute force" search on the whole search space, but considerably faster than that, because it eliminates candidates that certainly can't win. UMH, on the other hand, is not a full search. "UMH is much more aggressive than SEA at removing candidates without even looking at them".

See also:
* https://forum.doom9.org/showthread.php?t=141568
* https://x265.readthedocs.io/en/default/cli.html#cmdoption--me


[1] If you look at the x264 source, you'll see that the case block for (T)ESA mode also implements a brute-force search (aka "plain old exhaustive search"), but that code is disabled by a hard #if 0 in favor of SEA (aka "successive elimination by comparing DC before a full SAD")

[LigH]

Then we still have to know how the elimination works, and which steps are calculated in which order.

I imagined SEA as separating the whole motion search range into quadrants, and selecting the 1/4 quadrant with the best match, then separating this quadrant again with sub-quadrants, until they are only one square-sample wide (even when a quite good match is found early, just to ensure there is no better). That would mean a constant complexity related to the dual logarithm of the number of samples in the motion search range. No lucky best case.

For UMH instead, there are 3 different patterns: 4 samples star, 6 samples narrow hex, and 48 samples wide hex. My mistake was probably to believe that UMH always searches the wide pattern first. But that would mean a constant high complexity. Instead, looking at the "ASCII art" sample by akupenguin (https://forum.doom9.org/showthread.php?p=693742#post693742) again, I believe now that the wide pattern is only tried if the star and hex steps were considered not successful enough. If this strategy is correct, then there is no more surprise that UMH can be much faster when motion is often well-predicted.

[LoRd_MuldeR]

Then we still have to know how the elimination works, and which steps are calculated in which order.

I think it eliminates candidates which, by looking at the DC alone, cannot be better than the best candidate found so far.

For those "cannot win anyway" candidates, computing a full SAD is avoided and thus CPU time is saved. Simply put, you first have a quick look at each candidate, and you do the "accurate" (expensive) check only when it's actually worth it.

Also, whenever you actually do find a better candidate than your previous best one, even more of the remaining (i.e. not yet checked in-depth) candidates may be dropped. That's the "successive elimination" part, I suppose.

But, in contrast to other methods (e.g. UMH), you never discard any candidate that possibly (though unlikely) might have been the winner. For that reason, even though SEA is faster than "plain old exhaustive search", it's still relatively slow.

The SEA optimization is possible "...because sum(abs(diff)) >= abs(diff(sum))". If you really want to understand it in all detail, you'll probably have to study the source code:
http://git.videolan.org/?p=x264.git;a=blob;f=encoder/me.c;h=cafdfbe5995c882cf944f47a01ef0a13a360cb14;hb=HEAD#l632

[LigH]

I hoped for someone who was involved in implementing them to explain them; that was too optimistic, so far... :(

[Motenai Yoda]

--[no-]aq-motion
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame.
The more the relative motion of the block, the more quantization is used. Default disabled.

Requires AQ Mode to be on.
IIRC this should be roughtly the same as mb-tree/cu-tree?

--cutree, --no-cutree
Enable the use of lookahead's lowres motion vector fields to
determine the amount of reuse of each block to tune adaptive
quantization factors. CU blocks which are heavily reused as motion
reference for later frames are given a lower QP (more bits) while CU
blocks which are quickly changed and are not referenced are given
less bits. This tends to improve detail in the backgrounds of video
with less detail in areas of high motion. Default enabled

[Selur]

Refine analysis in 2 pass based on analysis information from pass 1
--multi-pass-opt-analysis doesn't support refining analysis through multiple-passes; it only reuses analysis from the second-to-last pass to the last pass.Disabling reading
To use '--multi-pass-opt-analysis' during which passes to I need to set the option? (during all? only during the last pass?)

Cu Selur

Ps.: Happy New Year!

[CruNcher]

Hmm did somebody do a test on the efficiency of x265 retranscoding other Encoder results (2nd Generation) and how the end complexity on the Decoding side turns out ?

and put that into compare vs 264 and its encoding/decoding complexity ?

i mean you only find test that talk about the encoding efficiency but how encoding/decoding goes through the roof nobody really seems to be interested looking at the overall efficiency and how that plays out visually.

Especially in current 10 Bit Encoder/Decoder states.

[Leo 69]

Can someone elaborate what ssim-rd does exactly?

[LigH]

Not yet in the online documentation...

It uses the more elaborate, but also visually quite human-like SSIM metric to optimize the rate distortion in the mode decision step. From the source:

/* SSIM based RDO, based on residual divisive normalization scheme. Used for mode
* selection during analysis of CTUs, can achieve significant gain in terms of
* objective quality metrics SSIM and PSNR */

Remember, SSIM is still an objective metric – means, a computer can calculate numbers to compare against other methods and options; but the human image recognition is, in contrast, subjective – it does not certainly produce the best-looking results for every person watching and judging the video. Different people may rate the same quality loss differently annoying.

[Barough]

x265 v2.2+17-a2fe29ca5c6c (http://www64.zippyshare.com/v/UD0c4Ki3/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Leo 69]

Not yet in the online documentation...

It uses the more elaborate, but also visually quite human-like SSIM metric to optimize the rate distortion in the mode decision step. From the source:

/* SSIM based RDO, based on residual divisive normalization scheme. Used for mode
* selection during analysis of CTUs, can achieve significant gain in terms of
* objective quality metrics SSIM and PSNR */

Remember, SSIM is still an objective metric – means, a computer can calculate numbers to compare against other methods and options; but the human image recognition is, in contrast, subjective – it does not certainly produce the best-looking results for every person watching and judging the video. Different people may rate the same quality loss differently annoying.

Thank you, but I still don't get it. :) When I switch it on, psy-rd automatically switches off. I understand to get proper SSIM figures, we always turn off all psychovisual enhancements. But I can't understand the mechanics of this option in case of normal encoding.

Has anyone had any chance to test aq-motion, is it any good?

[LigH]

Looks like you have either Psy-DR opt, or SSIM-RD opt, or no RD opt.

Has anyone had any chance to test aq-motion, is it any good?

If it does no good ... why implement it? In theory, when you see a lot of motion, you can't recognize details easily. So scenes with more motion are quantized more coarse, and this spares bitrate for scenes with less motion where you have the time to look for quality loss.

[Magik Mark]

Guys,

Experimented with the new CLis

--aq-motion
--ssim-rd
--multi-pass-opt-analysis
--multi-pass-opt-distortion

x265 2.2+17-a2fe29ca5c6c:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=5 / numa-pools=28 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=154345 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=0.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=2991 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion


I get a lot of blocks of pixel jumping from frame to frame. Can you help which among the new CLI is causing this?

http://i.imgur.com/ju8iFkS.png

[Ma]

Experimented with the new CLis

--aq-motion
--ssim-rd
--multi-pass-opt-analysis
--multi-pass-opt-distortion

I get a lot of blocks of pixel jumping from frame to frame. Can you help which among the new CLI is causing this?

I can confirm this. The simplest options to reproduce are:
-D10 --bitrate 3000 --ssim-rd

In my sample with -D8 (instead of -D10) options the quality is OK. Strange...

[Magik Mark]

I can confirm this. The simplest options to reproduce are:
-D10 --bitrate 3000 --ssim-rd

In my sample with -D8 (instead of -D10) options the quality is OK. Strange...

Are you saying that it is only --ssim-rd causing this? How about the other CLIs I have mentioned?

Thanks for prompt response!

[Ma]

Are you saying that it is only --ssim-rd causing this? How about the other CLIs I have mentioned?

If I use all your options without --ssim-rd, it is OK.
-D8 --ssim-rd is also OK (crf & bitrate).
-D10 --ssim-rd is wrong (crf & bitrate).

[Magik Mark]

Thanks ma for confirming!

D10 means 10bit encoding right?

[pradeeprama]

Thank you, but I still don't get it. :) When I switch it on, psy-rd automatically switches off. I understand to get proper SSIM figures, we always turn off all psychovisual enhancements. But I can't understand the mechanics of this option in case of normal encoding.


ssim-rd uses SSIM as an additional distortion metric on top of SSE. Since ssim doesn't capture noise introduced in the picture as a result of lossy encoding, we continue to use SSE instead of completely replacing it with SSIM. We first would like to experiment exhaustively with ssim-rd before enabling psy-rd along with ssim-rd as they may have some interesting implications on each other; that is the reason why psy-rd is turned off right now when using ssim-rd.

[pradeeprama]

Thanks ma for confirming!

D10 means 10bit encoding right?

Thanks for the test - we will look into this.

[pradeeprama]

--[no-]aq-motion
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame.
The more the relative motion of the block, the more quantization is used. Default disabled.

Requires AQ Mode to be on.
IIRC this should be roughtly the same as mb-tree/cu-tree?

--cutree, --no-cutree
Enable the use of lookahead's lowres motion vector fields to
determine the amount of reuse of each block to tune adaptive
quantization factors. CU blocks which are heavily reused as motion
reference for later frames are given a lower QP (more bits) while CU
blocks which are quickly changed and are not referenced are given
less bits. This tends to improve detail in the backgrounds of video
with less detail in areas of high motion. Default enabled

aq-motion is attempting to look only for relative motion of a block wrt to the frame that this block is a part of to increase QP and save some bits. cutree is looking at how this block is referenced by future blocks to give more bits to those blocks that are referenced more. They therefore can work orthogonal to each other, IMO

[CruNcher]

Thanks for the test - we will look into this.

Interesting saw similar issues on early Ateme 10 Bit Titan bitstreams as well but their the pixels where white instead black :D

[Atak_Snajpera]

I'm shocked how AVX2 and FMA3 optimization can provide such high speed boost for SkyLake!

command line: x265_x64.exe [crowd_run_1080p50.yuv+ducks_take_off_1080p50.yuv+in_to_tree_1080p50.yuv+old_town_cross_1080p50.yuv+park_joy_1080p50.yuv] --frames 2500 --min-keyint 50 --keyint 500 -o NUL

Intel Xeon E5-2690 @ 3.2GHz ( 8C / 16T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 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 / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 151.70s (16.48 fps), 7025.74 kbps, Avg QP:37.21

Intel Core i7-6700K @ 4.5GHz ( 4C / 8T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 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 / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 110.45s (22.63 fps), 7025.74 kbps, Avg QP:37.21


If we normalize results in this way FPS/GHz/Logical Processors this is what we get

SkyLake -> 0.63
SandyBridge -> 0.32

Basically SkyLake architecture is two times more efficient in x265 than SandyBridge!

[dipje]

it's the bit-by-bit increase in IPC (2nd gen core i7 vs 6th gen core i7) also I think, and it already has been stated that x265 is pretty hungry on memory bandwidth and skylake got pretty big changes in the memory department.

[ShogoXT]

Thanks for all the hard work you guys been putting into it. I have a couple questions.

A: If I want to update the x265 on Staxrip, would you recommend the stable or nightly releases? I noticed most of the nightly releases have been bug fixes lately.

B: I am currently using a Core i7 920 OCed that has no AVX. It currently is encoding at a painful 6-7fps for my projects. Soon il finally get a new computer. Is Ryzen or Kaby Lake looking to be the way to go?
Cores vs instructions I guess?

Thanks again.

[littlepox]

Thanks for all the hard work you guys been putting into it. I have a couple questions.

A: If I want to update the x265 on Staxrip, would you recommend the stable or nightly releases? I noticed most of the nightly releases have been bug fixes lately.

B: I am currently using a Core i7 920 OCed that has no AVX. It currently is encoding at a painful 6-7fps for my projects. Soon il finally get a new computer. Is Ryzen or Kaby Lake looking to be the way to go?
Cores vs instructions I guess?

Thanks again.

A: Unless you are the developer, or you are helping the developers to address bugs/feedbacks, better stick with the stable builds.

B. The Intel CPU is the way to go, most likely. However you do wish to wait for Ryzen to see whether Intel decides to go for some discount.

[Asmodian]

For x265/4 Ryzen might offer very competitive performance/price. We expect higher core counts at each price point with Ryzen and the IPC is looking similar to Haswell, with reasonable clock speeds too. x265 likes cores a lot. :)

It is hard to know much for sure at this point but there is supposed to be an official Ryzen preview on the 5th of this month. :D

It will be a long time before we get a 6/8/10 core Kaby Lake. :(

[NikosD]

x265 gains a lot from AVX2 (not FMA3 - FMA3 is for floating point only which is irrelevant with x265)

RyZen has slower AVX2 units, but x265 gains also a lot from multiple cores, which RyZen has plenty of them.

The CPU comparison will be very interesting after RyZen's official release and I should definitely wait for that.

Besides AVX2, multicores and memory bandwidth you have to consider power consumption (TDP) and last but not least, price (for most of the users that care about it)

[hajj_3]

zen+ is rumoured to have AVX512. Only xeon processors have AVX512 currently so that would be cool if it was true. Does anyone know if AVX512 helps over AVX2 for x265?

[littlepox]

For those who argue Zen would be favourable for x265, do you know how did they dream of Bulldozer when they were using x264?

[NikosD]

Very strong argument, comparing RyZen with Bulldozer.

[LigH]

Does anyone know if AVX512 helps over AVX2 for x265?

I do remember that Multicoreware already discussed taking advantage of some AVX512 instructions.

[Ma]

Does anyone know if AVX512 helps over AVX2 for x265?

Currently x265 doesn't use AVX-512. In the future it should help if the CPU has AVX-512BW extension (Byte and Word Instructions).

AVX-512 is divided into a number of extensions and only AVX-512F (AVX-512 Foundation) is required in all CPUs. AVX-512F is not enough for x265.

[Atak_Snajpera]

For x265/4 Ryzen might offer very competitive performance/price. We expect higher core counts at each price point with Ryzen and the IPC is looking similar to Haswell, with reasonable clock speeds too. x265 likes cores a lot. :)

It is hard to know much for sure at this point but there is supposed to be an official Ryzen preview on the 5th of this month. :D

It will be a long time before we get a 6/8/10 core Kaby Lake. :(

x265 likes cores to some point. According to documentation it cannot use more than 16 threads (--frame-threads).
According to my tests 16 is sometimes to low to saturate my Xeon E5-2690. I notice occasional drops to 70%-80% in cpu usage. Only if scene is very complex cpu usage goes to 90-95%.

[sneaker_ger]

Not more than 16 frames at the same time. It can use more cores than that, though.

[Magik Mark]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps

Nice work!

[pradeeprama]

Not more than 16 frames at the same time. It can use more cores than that, though.

Note that in addition to frame-level parallelism (specified by -F option), we also have threads for wpp that can be allocated in a socket-aware manner (specified with the --pools option).

From what I've seen so far, the # HW threads that x265 can saturate depends also on the preset as the amount of work done is very different across different presets. We can easily saturate up to 22-25 HW threads when encoding 4K videos (reasonably complex content), but going beyond that with a single instance of x265 is hard due to the amount of serial dependence introduced from our strict quality restrictions.

[LigH]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

[Magik Mark]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

What are these others? In layman's term pls

Thanks for the work! Will give it a try asap

[LigH]

Memory leaks, build warnings, SEA details ...

x265 commit log (https://bitbucket.org/multicoreware/x265/commits/all)

[Magik Mark]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

ssim rd is running smoothly. However, it slowed down the encoding. Turning it off speeds back everything. Can't see difference when its off or on.

Where should I be focusing to see the difference?

[LigH]

No need for a full-quote every time, even if it is small...

There is never a guarantee that the achieved difference in visual quality is as remarkable as the difference in efforts taken. One may have to visualize the loss against the original material in both cases to be able to point at it.

[JohnLai]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps

Nice work!

Hmm? How does enabling --aq-motion increase your encoding speed if it perform more analysis?

[Atak_Snajpera]

Can somebody with multi-socket machine run this benchmark? One of my users reported that despite 5 simultaneously running x265_x64.exe encoders CPU usage is only 75%-80% on his 2 x Intel Xeon E5-2670 @ 2.59GHz ( 8C / 16T ) [Windows 7 Ultimate]
Benchmark log
2 x Intel Xeon E5-2670 0 @ 2.59GHz ( 8C / 16T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool 0 using 16 threads on numa nodes 0
x265 [info]: Thread pool 1 using 16 threads on numa nodes 1
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 6 / wpp(17 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 / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 102.07s (24.49 fps), 7025.74 kbps, Avg QP:37.21

http://i.cubeupload.com/qX2JPa.png
http://www.mediafire.com/file/nm5n7xg2nb22zl7/x265_FHD_Benchmark.7z

[Ma]

Cool benchmark. On Intel Core i5-3450S @ 2.8GHz ( 4C / 4T ) the score was (3 runs): 8.78, 8.80, 8.80
After replacing x265_x64.exe to VS 2017 AVX build (also 2.2+15) the score was: 9.19, 9.20, 9.18

[OldiesManiac]

@ Atak_Snajpera

I use a dual Xeon E5-2690v4 28 physical cores system and even with 1 x265 encode I am near to 80 % mean.

With 2 simultaneaous encodes it's near 100 %.

Using Win10 x64.

CPU Usage:
https://extraimage.net/image/2STX

rgds

[Atak_Snajpera]

But do you see the same high cpu usage in benchmark? I'm asking because I use default x265 settings (--preset medium) with 1920x1080 test samples. I know that x265 can pretty easily max out many cores with 3840x2160 and some slower presets.

[ndkamal]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps


How did you use these options in command line in two pass for example ?

Thanks for avance.

[Motenai Yoda]

--pmode?

[jlpsvk]

is --no-rskip so benefical to picture quality or compression efficiency? because with --no-rskip the encode is about 2.5fps slower...

--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion

vs

--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion --no-rskip

[LoRd_MuldeR]

is --no-rskip so benefical to picture quality or compression efficiency? because with --no-rskip the encode is about 2.5fps slower...

It disables a speed optimization ("early exit from CU depth recursion") that slightly degrades quality - in theory.

So, no surprise that it makes your encode run slower. But whether quality (compression efficiency) is actually improved is up for debate/testing ;)

(Note: All presets below "veryslow" keep --rskip enabled)

[jlpsvk]

I know what it does...but I just wanted to know, if somebody tested it...because 2.5fps speed drop is huge. ;) I personally don't think, it's worth it....

[LoRd_MuldeR]

...because 2.5fps speed drop is huge. ;)

Well, whether a 2.5 fps speed drop is huge or negligible depends on what FPS you got before ;)

but I just wanted to know, if somebody tested it... [...] I personally don't think, it's worth it....

The fact that the developers added --no-rskip only to the "veryslow" and "placebo" presets indicates that they don't think the quality/speed trade-off is usually worth it.

...unless you don't care about speed anyway.

[jlpsvk]

i've got 6-8fps...depending on the source.. :) so 2.5fps if 30% slower.. :(

[burfadel]

i've got 6-8fps...depending on the source.. :) so 2.5fps if 30% slower.. :(

Then don't use it! The quality difference is probably in effect, non-existent or at least, so minute you'd really have to be looking closely at the right point on a the right frame zoomed in enough to be able to see there. There are a lot of other settings that you can use that are more beneficial, or save bitrate that benefits ABR video (target being size) or results in a smaller file (target quality). In the latter, you can decrease the CRF (remember decimals are allowed, such as 19.8) to get the equivalent approximate file size, which naturally means the output should be better quality.

[jlpsvk]

Then don't use it! The quality difference is probably in effect, non-existent or at least, so minute you'd really have to be looking closely at the right point on a the right frame zoomed in enough to be able to see there. There are a lot of other settings that you can use that are more beneficial, or save bitrate that benefits ABR video (target being size) or results in a smaller file (target quality). In the latter, you can decrease the CRF (remember decimals are allowed, such as 19.8) to get the equivalent approximate file size, which naturally means the output should be better quality.

I ended up with this and getting around 6fps encoding speed:
--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion

[burfadel]

I am currently using
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --amp --early-skip --fast-intra --b-intra --limit-modes --aq-mode 2 --ipratio 1.38 --pbratio 1.28 --me star --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd

using the latest 'nightly' build (2.2+22). It gets very decent encode speed, and decent output! If I really wanted to sacrifice encode speed but get better quality, I would only change --rd 4 to --rd 6, and IMPORTANTLY :) add --rd-refine which you can only use on --rd 5 and --rd 6. This slows down --rd 6 even further, but actually makes IMO --rd 6 worth the actual speed loss, if you find the slower encoding speed acceptable.

The thing is to find the right balance of encode speed and quality for your needs, and also choose settings that 'make sense'. I should point out that you have set --psy-rdoq to 10, which IMO is very high, but it doesn't matter anyway since it isn't effective without --rdoq-level.

The settings I chose work well for me and to my liking, and performs really well.

[jlpsvk]

I am currently using
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --amp --early-skip --fast-intra --b-intra --limit-modes --aq-mode 2 --ipratio 1.38 --pbratio 1.28 --me star --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd

using the latest 'nightly' build (2.2+22). It gets very decent encode speed, and decent output! If I really wanted to sacrifice encode speed but get better quality, I would only change --rd 4 to --rd 6, and IMPORTANTLY :) add --rd-refine which you can only use on --rd 5 and --rd 6. This slows down --rd 6 even further, but actually makes IMO --rd 6 worth the actual speed loss, if you find the slower encoding speed acceptable.

The thing is to find the right balance of encode speed and quality for your needs, and also choose settings that 'make sense'. I should point out that you have set --psy-rdoq to 10, which IMO is very high, but it doesn't matter anyway since it isn't effective without --rdoq-level.

The settings I chose work well for me and to my liking, and performs really well.

--psy-rdoq 10 is in effect, as I am using --preset slow and in that --rdoq-level 2 is by default, so no need to set it up. :)

will try --rd-refine speed loss. :)

edit: tried --rd-refine is cool... :) no such speed loss, but about 400kbps bitrate drop...from 3430 to 3003kbps...and the picture is better i thinks.

@burfadel: tried your settings...my preset is much better quality and detail retention....GTX 1060 can do HEVC 10bit encode at that quality with MediaCoder HQ preset with speed about 130fps. :)

[Magik Mark]

Guys,

I'm getting this warning:

x265 [warning]: Cannot use Analysis load/save option and multi-pass-opt-analysis/multi-pass-opt-distortion together,Disabling Analysis load/save and multi-pass-opt-analysis/multi-pass-opt-distortion

I only have " multi-pass-opt-analysis" activated the other one is off

HEVC encoder version 2.2+22-20217c8af8ac

[LigH]

The meaning is: You can't use either multi-pass-opt* option together with analysis load or save. If you want to load and save the analysis data, you can't optimize it at the same time.

[jlpsvk]

one small question.. :) which AQ-MODE you would recommend to use generally for bluray movies backuping? 1,2,3? :) (x265 2.2+22 and up)

[Magik Mark]

one small question.. :) which AQ-MODE you would recommend to use generally for bluray movies backuping? 1,2,3? :) (x265 2.2+22 and up)



Ad mode = 3 retains very good black level. Encodes a little bit longer though


Sent from my iPhone using Tapatalk

[Barough]

If u do 8-bit encodes so do i recommend you to always use --aq-mode 3 otherwise do is 2 enough. For more info, check the x265 documentation.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[Magik Mark]

If u do 8-bit encodes so do i recommend you to always use --aq-mode 3 otherwise do is 2 enough. For more info, check the x265 documentation.

Sent from my Samsung Galaxy S7 edge via Tapatalk



The doc says:

"This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking."

May I ask how do we define low bit rate? I do anywhere between 1500 to 4000. Do these values fall on low bit rate definition?


Sent from my iPhone using Tapatalk

[birdie]

May I ask how do we define low bit rate? I do anywhere between 1500 to 4000. Do these values fall on low bit rate definition?

At what resolution? FPS? What's your desired picture quality? Do you like your encodes to look indistinguishable from the original?

[Vesdaris]

Guys, what settings would you recommend for a somewhat fast encoding(medium preset) but trying to maintain as much details (and not get all blurry) as x264 can?

[microchip8]

Guys, what settings would you recommend for a somewhat fast encoding(medium preset) but trying to maintain as much details (and not get all blurry) as x264 can?

no SAO, no Strong Intra Smoothing, lower deblock filter to -2 or even -3, CTU of 32, AQ mode to 3

if you have grainy source, migh give the grain tuning a try. Apparently it produces very good results (haven't tried it myself but I've seen claims of that)

[jlpsvk]

no SAO, no Strong Intra Smoothing, lower deblock filter to -2 or even -3, CTU of 32, AQ mode to 3

if you have grainy source, migh give the grain tuning a try. Apparently it produces very good results (haven't tried it myself but I've seen claims of that)

for what is "--no-strong-intra-smoothing" good? do I need it/is it worth with my preset? :)

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4
--amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao
--high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3

[microchip8]

for what is "--no-strong-intra-smoothing" good? do I need it/is it worth with my preset? :)

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4
--amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao
--high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3

intra smoothing blurs. If you want to keep as much details as possible, disable it

[jlpsvk]

intra smoothing blurs. If you want to keep as much details as possible, disable it

and what about psy-rd?

[microchip8]

and what about psy-rd?

psy-rd is beneficial and is not related to intra smoothing. I find a value of 3.5 to be "optimal"

[jlpsvk]

psy-rd is beneficial and is not related to intra smoothing. I find a value of 3.5 to be "optimal"

interesting....with --psy-rd 3.5 the encode is actualy about 1fps faster...wonder why...

[LigH]

1 fps faster than ... 2 fps or 20 fps without? Please get used to percentages.

[qtwigg]

ME's 3, 4, and 5 compared.

Commands used:
--crf 22 --preset slow --tune ssim --profile main10 --output-depth 10 --min-cu-size 16 --ctu 32 --no-strong-intra-smoothing --no-constrained-intra --ssim

Star

encoded 4329 frames in 1138.22s (3.80 fps), 4239.98 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778734 (16.551 dB)

Start: 8:13:58 PM
End: 8:32:57 PM
Duration: 00:18:58

HEVC : 91.3 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

SEA

encoded 4329 frames in 3069.85s (1.41 fps), 4236.64 kb/s, Avg QP:26.58, SSIM Mean Y: 0.9778637 (16.549 dB)

Start: 2:55:52 PM
End: 3:47:03 PM
Duration: 00:51:10

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Full

encoded 4329 frames in 15629.88s (0.28 fps), 4237.87 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778782 (16.552 dB)

Start: 3:51:22 PM
End: 8:11:53 PM
Duration: 04:20:30

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Sample Clips
Star - https://mega.nz/#!t8tAVIxB!ymjIIy21Ul2fgxJWc3SyXQATQs1I9ZO_4JS1U2P1ZwM
SEA - https://mega.nz/#!og80HBia!gpV7atvaBIJeg9gVcVh23-qq1M7AAbHZANPw7dFV2TU
Full - https://mega.nz/#!J48T3YaR!QSm3uVZTNiVT3KcvGLbBMiDJICalmBPWwl3ZbnxCLaU

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.

[jlpsvk]

1 fps faster than ... 2 fps or 20 fps without? Please get used to percentages.

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop --colorprim bt709
--colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3 --no-strong-intra-smoothing

This command gives me about 3.9fps encode speed. With --psy-rd 3.5 it's about 1fps faster. :) So about 20-25% faster. Don't really know why. :)

[littlepox]

ME's 3, 4, and 5 compared.

Commands used:
--crf 22 --preset slow --tune ssim --profile main10 --output-depth 10 --min-cu-size 16 --ctu 32 --no-strong-intra-smoothing --no-constrained-intra --ssim

Star

encoded 4329 frames in 1138.22s (3.80 fps), 4239.98 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778734 (16.551 dB)

Start: 8:13:58 PM
End: 8:32:57 PM
Duration: 00:18:58



HEVC : 91.3 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

SEA

encoded 4329 frames in 3069.85s (1.41 fps), 4236.64 kb/s, Avg QP:26.58, SSIM Mean Y: 0.9778637 (16.549 dB)

Start: 2:55:52 PM
End: 3:47:03 PM
Duration: 00:51:10

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Full

encoded 4329 frames in 15629.88s (0.28 fps), 4237.87 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778782 (16.552 dB)

Start: 3:51:22 PM
End: 8:11:53 PM
Duration: 04:20:30

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Sample Clips
Star - https://mega.nz/#!t8tAVIxB!ymjIIy21Ul2fgxJWc3SyXQATQs1I9ZO_4JS1U2P1ZwM
SEA - https://mega.nz/#!og80HBia!gpV7atvaBIJeg9gVcVh23-qq1M7AAbHZANPw7dFV2TU
Full - https://mega.nz/#!J48T3YaR!QSm3uVZTNiVT3KcvGLbBMiDJICalmBPWwl3ZbnxCLaU

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.


impressive, would you please add the comparison for umh?

[burfadel]

I found the same thing. I'm currently encoding so won't do another comparison, but from the testing I did a while back STAR was beneficial over UMH in quality and the speed difference was very minimal. You almost get Full search quality at an encode speed similar to UMH. In theory you would expect SEA to be better than STAR. I also did some tests comparing the subpel refinement. Basically for the clip tested 2 was the ideal choice.

Level of RDO is an area for improvement I think. I use 4 because it has a good speed/quality tradeoff (yes I know 4 is basically the same as 3 currently). RD level 5 produces nice results but there is a massive performance hit. Combine --rd 5 with --rd-refine and --opt-cu-delta-qp and it produces a nice result. --rd-refine and --opt-cu-delta-qp are only available in RD 5 and 6.

I'm assuming it's possible to shortcut the extra calculations in --rd 5 as has been done with TU intra and enabled with --limit-tu 3 (for example), and like with --limit-modes and using --amp (which then has a negligible performance impact). I think if something along those lines could be done with --rd 5 and made the new -rd 4, it would be great. Likewise, using --rd-refine and --opt-cu-delta-qp as default options in this mode. The --rd-refine I'm assuming could also be shortcut (and use the shortcut from the rd level). By shortcut I mean like --limit-modes, --limit-refs etc.

I believe this new --rd 4 level if it could be achieved with minimal performance penalty over --rd 3 would be great!

Also a much more mild Sample Adaptive Offset loop filter would be good because currently (as discussed previously by others and myself) it loses detail with no real benefit. I can see in theory it should be better to have enabled, I think having it at a strength of say, 30 percent of what it currently is would be good. Hey, why not give the option to specify a strength, with 1.0 being the current strength and 0.3 (or whatever is found to be the most subjectively appealing) being the default strength?

Another idea is --strong-intra-smoothing. The help states 'This flag performs bi-linear interpolation of the corner reference samples for a strong smoothing effect.'. How about bicubic interpolation?

[Winston_Smith_101]

Can we expect some large steps in terms of x265 encoding quality in general and necessary bitrate for a given visual quality in the coming months? I ask because I have a lot of material to encode and would like to choose a good moment for that. :) Is there an overview of the improvements in the x265 codec in form of a graph or a chart? With build "a" bitrate "xxxx" was required to reach quality level "q"... and so on?

[LigH]

How do you measure visual quality?

[jlpsvk]

anybody can explain, why the same command with psy-rd is 20% faster the the same without psy-rd?

[sneaker_ger]

How much did the bitrate in your encode change? Entropy coding could be a factor.

[jlpsvk]

about 1mbit/s more (from 3100 to 4100kbps - so about 33% more...with CRF20. with CRF21 i am back at CRF20 bitrate without psy-rd...but image is better i think...can post screenshots) with --psy-rd 3.5. clean BD source without grain (miss peregrin's home for peculiar children).

[WhatZit]

Can we expect some large steps in terms of x265 encoding quality in general and necessary bitrate for a given visual quality in the coming months?

http://x265.readthedocs.io/en/default/releasenotes.html

Stable releases come, on average, every 6 months. Every one brings some sort of "quality" improvement, especially v2.0. If you don't like x265's output now, wait 6 months.

I ask because I have a lot of material to encode and would like to choose a good moment for that.

Using the absolute latest x265 build, run some short test encodes of different sources at a simple baseline of CRF20, Preset Medium, Profile Main10, Tune Grain and see what you get.

Don't like the quality? Try CRF19 Preset Slow.

Don't like the size? Try CRF21 Preset Fast.

Don't like any of it? Wait 6 months.

Only YOU can decide what you want.

[jlpsvk]

Any reason to be PSY-RD by default 0.0?

[x265_Project]

http://x265.readthedocs.io/en/default/releasenotes.html

Stable releases come, on average, every 6 months.

We're on our 22nd release in about 44 months. We've been slower to tag new versions in the last 2 years, but we are striving to get back to a new version every 2 months.

[jlpsvk]

Can anybody explain please? According to x265 online documentation, psy-rd is 2.0 by default.

But with:
--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop --colorprim bt709
--colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3 --no-strong-intra-smoothing

I am getting psy-rd=0.0 in MediaInfo....

Writing library : x265 2.2+22-20217c8af8ac:[Windows][GCC 6.2.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1024 /
interlace=0 / total-frames=1429 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers
/ no-open-gop / min-keyint=24 / keyint=240 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64
/ min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra
/ no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao
/ no-sao-non-deblock / rd=6 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=0.00 / psy-rdoq=10.00 / rd-refine / analysis-mode=0
/ no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=8 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree /
zone-count=0 / no-strict-cbr / qg-size=8 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 /
display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps
/ scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion

[LigH]

No certain explanation, just a guess ... the "encoding settings" are a plain text string. So the reason is most probably either in a wrong assignment of a default value, or a wrong conversion of the current float value to the text contained in this string. If it appears correctly when you add a custom value for this parameter, then it is probably a mistake in the defaults for the specific preset(s). Or it is overridden by a following parameter.

[jlpsvk]

When I was testing --psy-rd 3.5, it appears correctly.

[nevcairiel]

--ssim-rd sets --psy-rd to 0.0

[burfadel]

Forget my post if you already read it, I just remembered what nevcairiel said. For now it is disabled with --ssim-rd whilst an experimental feature, but at least you can set it manually!

[aymanalz]

ME's 3, 4, and 5 compared.

...

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.

To second another person above's request, could you please try ME 2 (umh) and add the results to the comparison?

[aymanalz]

^^ To answer my own request, I did encodes using the same settings that @qtwigg did, and here are the results:

UMH:

Final size: 87.433 MB
Bitrate: 6419.42 kb/s
Avg QP:26.42
FPS: 2.36

STAR:

Final size: 87.491 MB
Bitrate: 6423.67 kb/s
Avg QP:26.42
FPS: 3.34

SEA:

Final size: 87.5992 MB
Bitrate: 6431.62 kb/s
Avg QP:26.41
FPS: 0.72

Did not do Full.

Is there a GUI tool that can measure SSIM for clips encoded with 10 bit x265? I'd like to add that info as well. Visually, I can't tell the difference between any of the above.

[littlepox]

looks like star is still the best way to go.

[Motenai Yoda]

Is there a GUI tool that can measure SSIM for clips encoded with 10 bit x265? I'd like to add that info as well. Visually, I can't tell the difference between any of the above.
--ssim --psnr to x265 command line

[ChaosKing]

I get some kind of strange banding with the latest x265 version.
input/output is 10bit. It is a high motion scene and the difference in bitrate/filesize is about 16% (the x265 encode is smaller)
But this "banding" appears also (less visible) in static scenes where is no movement.

Is there something to reduce the "banding"?

x265 2.2+22-20217c8af8ac:[Windows][GCC 6.3.0][64 bit] 10bit
--crf 18 --no-strong-intra-smoothing --rd 6 --rd-refine --psy-rd 2.6 --aq-motion --me star --psy-rdoq 2 --opt-cu-delta-qp --tu-inter-depth 4 --tu-intra-depth 4 --preset veryslow --output-depth 10 --deblock -3:-3 --qpstep 6 --min-keyint 1 --ref 6 --bframes 12 --subme 5 --limit-refs 3 --aq-mode 3 --aq-strength 0.8 --ctu 64 --min-cu-size 8 --rect --amp

http://i.imgur.com/gL8hyOV.png






It's also visible with --medium, but also very blurry compared to the x264 version on the left.

--crf 18 --preset medium --output-depth 10 --input-depth 10
http://i.imgur.com/HkxjvjX.png

[LigH]

These images are huge. Please try to link them via thumbnails, or URLs only...

If this issue appears suddenly, from a specific version on, it may be a regression or a newly introduced bug to be investigated.

But your command line is a bit nonsensical. First of all, if you start with simple parameters, and then use a preset meta-parameter in the middle, this will probably override several previous simple parameters with preset defaults. Furthermore, why so many, do you need a preset at all if you define more or less every single option? And their relation to each other and the video content ... you mostly disable smoothing to retain details – for anime content?! That's paradox.

In this case, your nickname is quite matching ... :sly:

[ChaosKing]

Yes some are redundant bcs I started without the preset parameter. :D
I'm still testing out different parameters.
Not all animes look like cartoons and x265 tends to smooth the image/details.

I will test out an older version and report back.

[sneaker_ger]

I have seen this kind of banding happen for a long time. Sometimes it looks like an oil painting. Don't know any solution, unfortunately.

[Leo 69]

@ChaosKing --can you give me a link to the source via PM or provide a link to a problematic sequence? I'd like to test it with my settings, since I don't see much added banding in my own encodes even at higher CRF.

[ChaosKing]

I tested with some older build 2.2+7 & 2.1+74, but I can see banding artefacts here too. I used just the --preset veryslow paramter (10bit) & then slightly increased rsy-rd and rdoq.
It seems that the higher rd-psy/rdoq is set, the sharper the image looks and the more banding is visible. (But it was just a quick test, will make furher tests with different scenes)

@Leo 69 I've send you a pm.

[LigH]

Sounds rather credible to me... psychovisual RD enhancements were described as taking energy from some areas with higher energy (edges and other details) and distributing it to the surrounding areas with lower energy (little detail). For cartoons, this would probably mean to take the energy from the edges of black lines and distribute it into the flat color areas. So they get undesired stripes in the same direction as close black lines.

As useful as a feature may be for natural video content, as inadequate it may turn out for artifical content. There is never one perfect set of parameters for all video content.

[littlepox]

Even worse, those worm-like colour bandings are encouraged by high psy values coz they are considered with "high visual complexity"

[LigH]

I believe that cartoons should prefer rather higher than lower deblocking parameters, and rather enabled smoothing. But that will have to be tested. There is no "animation tuning" yet. But I believe there have been proposals already...?

[ChaosKing]

I did some more testing, but still have some banding in my encodes.

x264 bitrate ~6000 kb/s
--preset veryslow --crf 18 --psy-rd 0.7 --aq-mode 3

x265 bitrate ~5750 kb/s
--preset veryslow --crf 15 --psy-rd 0.5 --aq-mode 3

result:
http://i.imgur.com/AyO8lHu.png



I also tried ssim-rd, 5777kb/s
--preset veryslow --crf 15.5 --rd 6 --ssim-rd --aq-mode 3
http://i.imgur.com/D1bJDGb.png

with more contrast for whose with bad monitors :D
http://i.imgur.com/dH4c99b.png
(http://i.imgur.com/dH4c99b.png)
@LigH From that I read in all the threads and forums -> use -1,-2 or -3 deblocking and higher psy values, so that the image will remain sharp similar to x264 encodes. (also for animes)

[microchip8]

ChaosKing,

I think you are obsessing at this point. These are barely visible. Do you watch your anime frame by frame or do you sit back and enjoy?

[ChaosKing]

No I'm not obsessed. I just want to show which "problems" I found so maybe the devs can look into it and hopefully fix or improve it.
I just find it a bit strange what a bit higher psy/rdoq values causes visible worm/banding like artifacts. ok, perhaps the paramter is also just very sensitive, but I just think there is room for improvement.

Maybe it is not that much visible on your screen, but on my Dell U2515H (factory calibrated) I can clearly see them. Of course much less than in my first encode with higher psy settings.

The thing is I was so happy with the quality at first, because it looked very good and the image was not blurry at all, like in my previous encode (compared to x264). But after watching some minutes I saw weird looking edges and color gradients ...

[Leo 69]

ChaosKing,

I think you are obsessing at this point. These are barely visible. Do you watch your anime frame by frame or do you sit back and enjoy?

HEVC has to be on par in visual quality with AVC, requiring less bitrate. That's, I assume, what development team is working on.

Your point is ridiculous.

[aymanalz]

--ssim --psnr to x265 command line

I added that, where can I see the result? The program "Hybrid"'s log file does not give that info.

Sorry if the question is noobish.

[microchip8]

No I'm not obsessed. I just want to show which "problems" I found so maybe the devs can look into it and hopefully fix or improve it.
I just find it a bit strange what a bit higher psy/rdoq values causes visible worm/banding like artifacts. ok, perhaps the paramter is also just very sensitive, but I just think there is room for improvement.

Maybe it is not that much visible on your screen, but on my Dell U2515H (factory calibrated) I can clearly see them. Of course much less than in my first encode with higher psy settings.

The thing is I was so happy with the quality at first, because it looked very good and the image was not blurry at all, like in my previous encode (compared to x264). But after watching some minutes I saw weird looking edges and color gradients ...

Report the problem to the x265 bug tracker, then. x265 devs don't fully follow everything in here

[Selur]

The program "Hybrid"'s log file does not give that info.
you could simply enable 'x265->Misc->Metrics->PSNR' and 'x265->Misc->Metrics->SSIM' (or add the options under 'x265->Misc->Custom command line addition') both work fine here, if it doesn't for you create a proper bug report inside the Hybrid thread,...

[Magik Mark]

Guys,

I just would like to confirm if I need to turn off cutree if I'll be using and of the ff CLI:

--multi-pass-opt-rps
--multi-pass-opt-analysis
--multi-pass-opt-distortion

[burfadel]

Here's the results of my comparison test. I used pretty much my standard settings for the test, but with SSIM and PSNR stats enabled. I realise that psy-rd etc affects the SSIM and PSNR stats such that they become 'invalid', but I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off). Differences in the motion estimation will affect all things down stream from it, such as AQ, psy-rd etc, by leaving them enabled even though the results are 'inaccurate' it does potentially show how changes in the settings affect these features.

Settings used, apart from the ME, and where applicable the ME range:
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --b-intra --limit-modes --aq-mode 2 --nr-intra 400 --nr-inter 400 --ipratio 1.38 --pbratio 1.28 --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --keyint 600 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd --psy-rd 2.00 --ssim --psnr

No avisynth filters were used for the comparison apart from the source filter.

HEX
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5382.71 PSNR Mean: Y:46.296 U:49.536 V:50.818 SSIM Mean: 0.982813 (17.648dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1342.77 PSNR Mean: Y:45.543 U:49.001 V:49.778 SSIM Mean: 0.982113 (17.475dB)
x265 [info]: frame B: 1493, Avg QP:25.19 kb/s: 225.04 PSNR Mean: Y:45.006 U:48.783 V:49.559 SSIM Mean: 0.980893 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 73.53s (27.20 fps), 575.05 kb/s, Avg QP:23.75, Global PSNR: 46.176, SSIM Mean Y: 0.9812134 (17.262 dB)

STAR
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5377.76 PSNR Mean: Y:46.294 U:49.532 V:50.819 SSIM Mean: 0.982812 (17.648dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1340.51 PSNR Mean: Y:45.545 U:49.001 V:49.772 SSIM Mean: 0.982131 (17.479dB)
x265 [info]: frame B: 1493, Avg QP:25.19 kb/s: 225.26 PSNR Mean: Y:45.010 U:48.782 V:49.552 SSIM Mean: 0.980912 (17.192dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 89.92s (22.24 fps), 574.59 kb/s, Avg QP:23.75, Global PSNR: 46.177, SSIM Mean Y: 0.9812321 (17.266 dB)

STAR24 for interest, me range changed to 24 from default 57
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5374.91 PSNR Mean: Y:46.289 U:49.532 V:50.813 SSIM Mean: 0.982800 (17.645dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1344.30 PSNR Mean: Y:45.558 U:49.008 V:49.782 SSIM Mean: 0.982175 (17.490dB)
x265 [info]: frame B: 1493, Avg QP:25.20 kb/s: 226.28 PSNR Mean: Y:45.018 U:48.789 V:49.563 SSIM Mean: 0.980951 (17.201dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 76.64s (26.09 fps), 576.20 kb/s, Avg QP:23.76, Global PSNR: 46.186, SSIM Mean Y: 0.9812714 (17.275 dB)

STAR35 as above, but 35
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5380.92 PSNR Mean: Y:46.297 U:49.528 V:50.828 SSIM Mean: 0.982821 (17.650dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1343.05 PSNR Mean: Y:45.550 U:48.998 V:49.775 SSIM Mean: 0.982151 (17.484dB)
x265 [info]: frame B: 1493, Avg QP:25.20 kb/s: 225.62 PSNR Mean: Y:45.014 U:48.781 V:49.559 SSIM Mean: 0.980931 (17.197dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 82.48s (24.25 fps), 575.52 kb/s, Avg QP:23.76, Global PSNR: 46.181, SSIM Mean Y: 0.9812514 (17.270 dB)

UMH
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5374.79 PSNR Mean: Y:46.290 U:49.529 V:50.821 SSIM Mean: 0.982806 (17.646dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1341.79 PSNR Mean: Y:45.541 U:48.998 V:49.775 SSIM Mean: 0.982107 (17.473dB)
x265 [info]: frame B: 1493, Avg QP:25.19 kb/s: 224.90 PSNR Mean: Y:45.007 U:48.781 V:49.558 SSIM Mean: 0.980894 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 100.11s (19.98 fps), 574.58 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812131 (17.261 dB)

SEA
x265 [info]: frame I: 33, Avg QP:17.37 kb/s: 5378.57 PSNR Mean: Y:46.289 U:49.529 V:50.817 SSIM Mean: 0.982796 (17.644dB)
x265 [info]: frame P: 474, Avg QP:19.67 kb/s: 1341.23 PSNR Mean: Y:45.539 U:49.005 V:49.779 SSIM Mean: 0.982106 (17.473dB)
x265 [info]: frame B: 1493, Avg QP:25.19 kb/s: 224.58 PSNR Mean: Y:45.005 U:48.785 V:49.561 SSIM Mean: 0.980891 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%
encoded 2000 frames in 245.39s (8.15 fps), 574.27 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812103 (17.261 dB)

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%

Of course, with the figures being different in each encode.

[aymanalz]

you could simply enable 'x265->Misc->Metrics->PSNR' and 'x265->Misc->Metrics->SSIM' (or add the options under 'x265->Misc->Custom command line addition') both work fine here, if it doesn't for you create a proper bug report inside the Hybrid thread,...

I'm getting values reported when I tick those options.

I'll run tests with those checked and report back.

[mandarinka]

Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.

[Barough]

x265 v2.2+23-58dddcf01b7d (http://ge.tt/50BOQTi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Motenai Yoda]

I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off).
[...]
Settings used, [...] --ssim-rd

but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...

[davidsama]

This is the AVX2 build (https://tinyvpn.net/d/6/e/d6ed65b615780e5de03008921986e600.7z)

[burfadel]

but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...

ssim-rd does disable psy-rd, it does this by using a default of 0.00, at least during testing. If you specify it manually*you can still use it. I use 400 for nr*as it isn't really noticeable but saves bitrate. I can therefore use a lower CRF*so the result is higher quality output.

[greenfountain]

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%

Of course, with the figures being different in each encode.

Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.

[Midzuki]

x265 2.2+25-3737c70c3308

add support for aq-motion even when aq-mode is disabled

http://www.mediafire.com/file/4npramvjya92aj4/x265_2.2+25-3737c70c3308.7z

[jlpsvk]

is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier... :(

[x265_Project]

Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.

Anything is possible with enough time, money and motivation. The question of whether to start with the reference or with x265 depends on your software development philosophy. We like to use an agile software development methodology, which stresses the need to always have a stable build that works. With a new coding standard, the reference encoder gives you a stable build that works (can encode valid bitstreams for that standard). So we would likely start there, and then slowly replace every piece of the reference encoder with our own code, just as we did with x265.

[Midzuki]

x265.exe 2.2+26-d1f6d9b8d6be

Add filler bits when frame bits < vbv target in strict-cbr

http://www.mediafire.com/file/j1ouckq9j70wss2/x265_2.2+26-d1f6d9b8d6be.7z

[cojj]

is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier... :(

According to the documentation:
"high-tier allows the support of high tier at that level. The encoder will first attempt to encode at the specified level, main tier first, turning on high tier only if necessary and available at that level."

Pretty self-explanatory => even if you set the flag, it will attempt main tier first and only use high-tier if necessary.

[burfadel]

Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.

That makes sense :).*STAR seems the most efficient,*it would be interesting to know whether it could be improved further.

[LigH]

x265 2.2+29-2f075fe8d4c5 (https://www.mediafire.com/file/8r5k5wmg1o65lkl/x265_2.2+29-2f075fe8d4c5.7z)

--complex-analysis <0..4.0> Strength of complex analysis, 0 to disable. Default 0.0

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

A developers' functionality test runs with strength 1.53, FYI.

[burfadel]

x265 2.2+29-2f075fe8d4c5 (https://www.mediafire.com/file/8r5k5wmg1o65lkl/x265_2.2+29-2f075fe8d4c5.7z)

--complex-analysis <0..4.0> Strength of complex analysis, 0 to disable. Default 0.0

A developers' functionality test runs with strength 1.53, FYI.

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea :).

[LigH]

How do I? TortoiseHg Workbench does not report any changes since. The commit log on bitbucket (https://bitbucket.org/multicoreware/x265/commits/all) neither.

[burfadel]

Probably not committed to the development branch yet, patches are here:

https://patches.videolan.org/project/x265-devel/list/

[x265_Project]

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea :).
Sure, we can extend this technique to wider applications. This initial function was developed for those who use "capped VBR" rate control (CRF, with VBV). In this scenario, quality is constant until you reach a place where VBV kicks in to enforce decoder parameters. In these places, quality will take a dip. To counteract that, we allow x265 to dynamically increase encoding efficiency in these areas (similar to using a slower, higher quality performance preset). But yes, the concept could be extended to general ABR or CRF encoding.

[x265_Project]

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.


We probably should have said "Increases the RD level at points where quality drops due to VBV rate control enforcement." I'll ask our team to improve the documentation.

[Selur]

Effective for RD levels 4 and below.
+
if (m_param->complexAnalysis && (!bIsVbv || !p->rc.aqMode || p->rdLevel > 4))
{

p->complexAnalysis = 0;

x265_log(p, X265_LOG_WARNING, "Complex-analysis disabled, requires RD > 4, VBV and aq-mode enabled\n");

}

=> 'requires RD > 4' should be 'requires RD <= 4'

[Motenai Yoda]

+
if (m_param->complexAnalysis && (!bIsVbv || !p->rc.aqMode || p->rdLevel > 4))
{

p->complexAnalysis = 0;

x265_log(p, X265_LOG_WARNING, "Complex-analysis disabled, requires RD > 4, VBV and aq-mode enabled\n");

}

=> 'requires RD > 4' should be 'requires RD <= 4'
more "Effective for RD levels 4 and below." should be "Effective for RD levels 5 and over. "

[Selur]

@MontenaiYoda: the code I posted disables complexAnalysis when rdLevel > 4, so "Effective for RD levels 5 and over. " seems strange to me.

Cu Selur

[LigH]

I'd agree to Selur's opinion, it seems to match the documentation: complex analysis "Increases the RD level at points where quality drops due to VBV rate control enforcement", therefore it should be more effective when it was initially rather low. It compensates a bit of the loss in fast presets.

[Motenai Yoda]

@MontenaiYoda: the code I posted disables complexAnalysis when rdLevel > 4, so "Effective for RD levels 5 and over. " seems strange to me.

Cu Selur

KK I misread 0 as 1

[MonoS]

Hi, i do my encode with a command line like this
vspipe.exe -y script.vpy - | ffmpeg.exe -i - -c:v libx265 -preset veryslow -crf 22 ...
Often my script produce a 16bit output due to scaling or denoising, is it best to dithering the input in vapoursynth, pass the clip undithered as i'm doing or use the parameter --dither of x265 in the command line?
If i should dither it on the script side, what kind of dither is it best for this kind of parameters, if i'm not mistaken ordered dither should be the best when reaching for low bitrate target in every case
rect=0:amp=0:cutree=0:early-skip=0:limit-refs=3:aq-mode=3:limit-modes=1:level-idc=4:me=2:fast-intra=1:max-merge=3:rd=4:rdoq-level=0:psy-rd=1.1:aq-strength=1.9:deblock=-1,-1

Thanks for the attention

[Midzuki]

x265 2.2+30-fa52b516f5ff

complexAnalysis: clean up

http://www.mediafire.com/file/6vj4jym5p37dojn/x265_2.2+30-fa52b516f5ff.7z

[Magik Mark]

Is there a way to convert bt2020 to bt709 color matrix?

[Barough]

x265 v2.2+30-fa52b516f5ff (http://ge.tt/2bFZbai2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

x265 2.2+30-fa52b516f5ff (https://www.mediafire.com/file/9g689q9w9jwyhny/x265_2.2+30-fa52b516f5ff.7z) (GCC 6.2.0)

I hope XhmikosR will release updates MSYS packs...

[benwaggoner]

Is there a way to convert bt2020 to bt709 color matrix?
Not with x265. And not well without some high-end tone mapping technologies.

[Midzuki]

x265 2.2+30-fa52b516f5ff (https://www.mediafire.com/file/9g689q9w9jwyhny/x265_2.2+30-fa52b516f5ff.7z) (GCC 6.2.0)

I hope XhmikosR will release updates MSYS packs...

You can safely replace GCC 6.2 with the GCC 6.3 build compiled by nevcairiel:

https://files.1f0.de/mingw/

OR go the MSYS2 way...

Word about MPC-HC was in a dire need of developers was published back in '12. (https://mpc-hc.org/2012/09/24/open-call-for-contributors/)
At the moment only XhmikosR and kasper93 are semi active, you know ... LIFE has happened and not everyone has spare time anymore. Official statement will be drafted and published on MPC-HC's website when the time is right and when there are news to report.

So, perhaps XhmikosR will release a new MSYS1 package only when GCC 7 is out...

[youli]

Hi! Is anybody knows, how to display graphic chart of bitrate distribution for H.265 stream? I mean, just like "Bitrate Viewer" for H.264:

http://s020.radikal.ru/i706/1702/04/71f32da53278.png

[LigH]

Did you try whether this Bitrate Viewer fails when you have HEVC multiplexed in a supported container? It may just not support a raw video stream as long as there is no matching source filter.

An alternative may be to let x265 write a verbose CSV log (csv-log-level > 0), import it into a spreadsheet calculator, sort it to display order (that's a bit tricky e.g. in Excel alone), and let this draw a graph.

[birdie]

Hi! Is anybody knows, how to display graphic chart of bitrate distribution for H.265 stream? I mean, just like "Bitrate Viewer" for H.264:

http://s020.radikal.ru/i706/1702/04/71f32da53278.png

https://github.com/zeroepoch/plotbitrate

[youli]

LigH, ApTeM thanks a lot for your advices, but.. it will difficult ways for me.

In the both cases for AVC and HEVC I use mkv container. With AVC in mkv "Bitrate Viewer" works perfect, but with HEVC in mkv I got error "Codec not found".
http://s018.radikal.ru/i503/1702/bb/824ec218c590.png
LAV Filters 0.69 was installed.

[LigH]

Oh, I think I remember that this Bitrate Viewer (http://www.videohelp.com/software/Bitrate-Viewer-2) was built upon some ffmpeg version which is quite outdated today... It will not use LAV Filters. No source available. No longer developed.

Here (https://forum.doom9.org/showthread.php?p=1718367#post1718367) was the forum thread with my old complaint... The author updated only a Mac OS X version, but not a Windows version.

You will find some more tools there, but they are command line tools, not so user friendly without mouse support.

[youli]

Oh, thanks! I used CheckBitrate from https://onedrive.live.com/?authkey=%21AKcPpJfIHBiTBk0&id=6BDD4375AC8933C6%214230&cid=6BDD4375AC8933C6 and got csv-file.
Chart it in Excel
http://s008.radikal.ru/i303/1702/08/231533c8ea9d.png

[x265_Project]

Did you try whether this Bitrate Viewer fails when you have HEVC multiplexed in a supported container? It may just not support a raw video stream as long as there is no matching source filter.

An alternative may be to let x265 write a verbose CSV log (csv-log-level > 0), import it into a spreadsheet calculator, sort it to display order (that's a bit tricky e.g. in Excel alone), and let this draw a graph.

No need to sort in display order. The decoder is going to have to decode in decode order, which is the real bit rate.

[davidsama]

2.2+31-2014112 avx2 version https://tinyvpn.net/a/c/b/acbdfccb48760b159389f78919834ebc.7z

[CruNcher]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

of course coming from the Vice President of Marketing

[MonoS]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better kind of press release"

Basically, we are better because we have patents, proprietary algorithm and sell our product for K$, x265 sucks because doesn't care about broadcaster and can't use patented software.

Interesting point of view.

[Midzuki]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

Very-interesting :)

[CruNcher]

Basically, we are better because we have patents, proprietary algorithm and sell our product for K$, x265 sucks because doesn't care about broadcaster and can't use patented software.

Interesting point of view.

Yeah when he was at VUDU he surely wrote releases like "why x264 is better then proprietary software"

though he just tried to protect nothing else he knows exactly that most of those things are either already existing internally somewhere or being worked on as he spoke out that's called fear.

This is also funny as hell


"One note, we are aware that x265 supports these features via FFMPEG. However in the case that a user is not able to use FFMPEG, the fact that V.265 supports them directly is a benefit."


Who in the industry would employ people on the tech team not able to use FFMPEG for resizing some input :D

[x265_Project]

Very-interesting :)
Mark's first draft was so full of factual errors, I had to write to them. Then they posted this "corrected" version, which is still full of errors, and lots of unsubstantiated claims.

I just find the title kind of funny. "Before you evaluate x265"... as if there is a chance that anyone interested in evaluating HEVC encoder software libraries won't include x265 in their evaluation.

We're honored to be the gold standard by which all other HEVC encoders are compared. x265 is open and available for all to evaluate. If other encoders are truly better, why don't they make their encoder available publicly, so that anyone could run a test and publish the results?

[CruNcher]

Hehe or become at least part in the MSU evaluation ;)
else bog bog booog pick bog pick boooog bog ;)

And you absolutely right

"Before you evaluate x265, read this!"

he took his course in manipulation but i guess his writing charisma wont even subvert the dumbest decision makers in totally blindly buying his product and believing everything written and then you really have to ask the question who is he actually targeting ;)

the same old Vanguard with a new Name trimmed for the Visual Perception era by the Beamr PQ IP (BBCQ) ontop going against the likes of V-Nova in the Future ;)

[Barough]

x265 v2.2+31-20141129537b (http://ge.tt/1ngZ3hi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+31-20141129537b
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+31-20141129537b
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[littlepox]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

of course coming from the Vice President of Marketing

A short summary on this article for doom9 users:

Our encoder produces something like s***, however we can solve a lot of problems you will never come across to or you can easily solve by yourself.

[Midzuki]

x265.exe 2.2+33-0729b3a4a0cc

cli: Enable new --hdr option to force signaling HDR parameters

Useful when there is a desire to signal --max-cll 0,0 in the bitstream.


http://www.mediafire.com/file/mce2ct21oc5a1v0/x265_2.2+33-0729b3a4a0cc.7z

[Barough]

x265 v2.2+33-0729b3a4a0cc (http://ge.tt/9B6Zxji2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+33-0729b3a4a0cc
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+33-0729b3a4a0cc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[CruNcher]

A short summary on this article for doom9 users:

Our encoder produces something like s***, however we can solve a lot of problems you will never come across to or you can easily solve by yourself.

Easily solve nahh actually partly they are solved already in a Framework by Multicorewave themselves called UHDkit ;)

Some are very specific and many are fighting here against the excellence of Ateme and that's a hard bread to beat Intel is on it's way todo that ;)

Though most are really unusable for AVG users though when we talk about Live Game streaming then it looks a little different and also AVG consumer could benefit from it but overall the complexity would need even those to build very beefy systems to even come into the direction to need them at all ;)

Different tuning scenario with different requirements with a very big focus on latency and multiple stream transmission stability and performance (resilience).


Multicorewave extensions it as the commercial part of the Encoder inside UHDkit a normal Strategy obviously our Beamr Marketing Vice President loses no word about it which is crazy it would be a viable attack vector for him.

[LigH]

x265 2.2+35-fe2f2dd96f8c (https://www.mediafire.com/file/n9eg73nqeswwlz6/x265_2.2%2B35-fe2f2dd96f8c.7z)

--complex-analysis is now --dynamic-rd, and you can now manually control HDR SEI packets

[Barough]

x265 v2.2+36-9b975fec584a (http://ge.tt/53eOnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[LigH]

Why do you never summarize the difference to the previous version, Barough? Shall every user check the commit log on their own?

Meh. Let's dump the v2.2+35 I just uploaded; v2.2+36 is a merge with stable.
_

OK, slight issue: "tip" is in the "stable" branch here, not in the "default" branch. My update script always updates to the last commit in the "default" branch, if not specified otherwise, so missed the merge...

Once again.
_

x265 2.2+36-9b975fec584a (https://www.mediafire.com/file/m4sp9c3b2uiihk4/x265_2.2+36-9b975fec584a.7z)

[nakTT]

x265 v2.2+36-9b975fec584a (http://ge.tt/53eOnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

Thanks for the update. The executable size is smaller than other builds but it works.:thanks:

[Midzuki]

Thanks for the update. The executable size is smaller than other builds but it works.:thanks:

Barough applies UPX upon x265.exe, there is no sorcery involved :D

[LigH]

That may produce smaller individual files; but to compress several very similar files in a tight archive for a smaller download, it may be better not to pre-compress them, so that archivers can find more identical parts between different files. 7-zip is quite good at that with large dictionary sizes... After unpacking the archive, you may decide on your own whether it is useful to UPX either EXE.

[FlipFlops2001]

http://msystem.waw.pl/x265/

Builds using MS Visual Studio 2017, GCC 6.3 and GCC 7.0 include: AVX2, AVX, SSSE3 or SSE2fast (or below) SIMD dedicated support.

Current version as of this posting: x265-2.2+35-fe2f2dd.

New CLI: --hdr, --no-hdr; used in conjunction with --max-cll. Currently running an encode using --hdr. Has anybody tried this yet?

x265 command line options documented @: http://x265.readthedocs.io/en/default/cli.html

These following parameters have been working very well for me:
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L3.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 43 min 45 s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Writing library : x265 2.2+35-fe2f2dd96f8c:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1280x720 / interlace=0 / total-frames=62946 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=1 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=5 / limit-refs=3 / no-limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / weightp / no-weightb / analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=1.50 / psy-rdoq=1.50 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=3 / crqpoffs=3 / rc=crf / crf=24.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.50 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / hdr
Language : English
Default : Yes
Forced : No
Color range : Full

Any suggestions?

[Barough]

@LigH

That's a simple answer. When ever i run the 'media-autobuild_suite' and it gives me new EXE's so do i just share 'em. The only time i look into the changes etc. is when im about to use 'em myself.

[LigH]

That may mean that you publish even new builds when they don't change the code at all (e.g. only update the documentation)... this would be too often for my taste. :)

[Barough]

Could be so..... ;)

I don't have a special scheme when i run the 'media-autobuild_suite'.... it just happens when i feel like it, ie. when i fire up the laptop i have the suite installed on.

[birdie]

I wonder why no one has posted comparisons lately, e.g. x264 vs x265 at various bitrates, or maybe various versions of x265.

[LigH]

Spending energy in repeating the same comparisons again doesn't sound useful to everyone. It may require a specific reason to do some new ones.

If you need one: Try to show us which impact dynamic-rd can have.

[hajj_3]

I wonder why no one has posted comparisons lately, e.g. x264 vs x265 at various bitrates, or maybe various versions of x265.

It has been quite some time since big improvements were made in x265 compression so there wouldn't be much difference to quality, speed has improved quite a bit though.

[birdie]

No significant changes between 1.7 and 2.2? How's that even possible? ;-)

[Khun_Doug]

If you need one: Try to show us which impact dynamic-rd can have.


I took a look at dynamic-rd. First I discovered that VBV buffer size and VBV fillrate need to be non-zero. My initial test used a BD clip with CRF 19 preset Slow. The X265 file has a bitrate of 6900 kb/sec, file size 214.3 MB. To get a video clip that was the same clarity and sharpness I ended up using VBV buffer 4000 and VBV fillrate 1000. I tested VBV buffer 2000 and VBV fillrate 500, but the output lacked the sharpness. With the VBV 4000 settings and dynamic-rd set to 0, the bitrate dropped to 3336 kb/sec, file size 103.4 MB. I then tested dynamic-rd with a value of 2,3 and 4. I didn't bother with testing 1. Results:

0: file size 103.4, bitrate 3336 kb/sec
2: file size 103.6, bitrate 3341 kb/sec
3: file size 103.5, bitrate 3338 kb/sec
4: file size 105.6, bitrate 3340 kb/sec

Visually, the clip looks the same across all VBV test cases. I would expect that more scrupulous eyes would see noticeable changes between the clip without any VBV and the various test cases. I saved the film clips if anyone wants to see sample frames.

All this brings up a question. What are reasonable VBV settings? Are there better options when using VBV than using a CRF value?

[Magik Mark]

I have 24 cores 28 threads CPU. What would be an optimum value for --slices?

[Selur]

Not sure what the optimum is but from some tests I did on my old dual Xeon E5640 system, corecount/2 seems to give the best speed.

[pradeeprama]

I have 24 cores 28 threads CPU. What would be an optimum value for --slices?

It really depends on what your goal is. Slice-based parallelism is a performance/efficiency trade-off. On the one hand, you may get better performance with fewer frame threads (-F option), while on the other, there is some loss in visual quality at the boundary of the slices. I would encourage you to play with a combination of the -F and --slices options.

[Magik Mark]

Not sure what the optimum is but from some tests I did on my old dual Xeon E5640 system, corecount/2 seems to give the best speed.

How was the quality compared to default and corecount/2

[Selur]

I didn't compare the quality seriously, that is why I wrote 'give the best speed'.
I just checked tested a few sources (HD, UHD and SD) with different '--slices' values; tested different pools a frame-thread values, but those didn't really help with the speed at all.
Once I found the slices value I simply looked at the output to see if I could spot any problems, since I didn't see a problem I stopped my testing.
There might still be problems quality wise with using slices that weren't present with my sources or I simply didn't spot at the time.

Cu Selur

[qtwigg]

Anyone been experiencing very low bitrates at low CRF numbers? 20 usually been working for 3.5 to 5GB depending but lately I needed to use 18 but with 18 barely breaking 3k to 4k in bitrate and now I have one CRF 14, 1.7GB. I know all the parameters and differences in all material and how everything is a variable but this is or has been an average lately and only been lately. I usually never had to go below 20 or they file would be enormous but not anymore. Any ideas?

[Selur]

Wild guess: material is darker than the previous content

[nakTT]

Barough applies UPX upon x265.exe, there is no sorcery involved :D
Thank you so much for the info. I thought there was a sorcery involved.:D

By the way, anyone here has any idea that in general, how many percent the Placebo setting has the advantage over the VerySlow setting in term of quality at the same bitrate.

Thank you in advance.

[Selur]

Side note: Assuming the compression efficiency between 'very slow' and 'placebo' was anything worth speaking of wouldn't that make the developers morons to name the preset that way?

[LigH]

Life would be so easy if we could measure "quality" directly. Unfortunately, it is subjective, thus related to personal opinions of different people looking at the result. We can measure differences, and we can weight them with metrics resembling some psychovisual rules. Still, different people may have different opinions about how annoying these differences feel, and whether they notice them at all.

See preset "veryslow" as a sensible maximum, and "placebo" as a theoretical but nonsensical limit. Other projects named such a preset "insane" instead.

[nakTT]

Side note: Assuming the compression efficiency between 'very slow' and 'placebo' was anything worth speaking of wouldn't that make the developers morons to name the preset that way?

Life would be so easy if we could measure "quality" directly. Unfortunately, it is subjective, thus related to personal opinions of different people looking at the result. We can measure differences, and we can weight them with metrics resembling some psychovisual rules. Still, different people may have different opinions about how annoying these differences feel, and whether they notice them at all.

See preset "veryslow" as a sensible maximum, and "placebo" as a theoretical but nonsensical limit. Other projects named such a preset "insane" instead.
Thank you so much for the reply.

I do understand that it is not a straightforward kind of affair. The reason I ask because last time I did ask the same question to Dark Shikari about x264 and she did give me an answer/estimation (less than 2%, IIRC).

Thus this time around I thought someone who is really knowledgeable in x265 could share some sort of answer/estimation.

Thanks again and sorry for any inconvenience caused.

:thanks:

[LigH]

less than 2%

Without testing, I would assume that the difference for x265 will usually be just as small. Mainly because the encoder already works very thoroughly in "veryslow" preset, and would only waste more time with most improbable tests in "placebo".

[pradeeprama]

Thank you so much for the reply.

I do understand that it is not a straightforward kind of affair. The reason I ask because last time I did ask the same question to Dark Shikari about x264 and she did give me an answer/estimation (less than 2%, IIRC).

Thus this time around I thought someone who is really knowledgeable in x265 could share some sort of answer/estimation.

Thanks again and sorry for any inconvenience caused.

:thanks:

Since x265 is tuned for visual quality, I don't think quoting a number would be straight forward. If you can afford the time for the placebo encodes, they will definitely perform better (efficiency wise) making the jump worth it.

[pradeeprama]

x265 version 2.3 has been released. This release contains new algorithms that improve visual quality, encoding efficiency, and performance.

The latest version can be downloaded from here (MD5 sum = 18716a7e0c6f6ebd2a1035b82cec30de). Full documentation is available at http://x265.readthedocs.io/en/stable/.

Release Notes for 2.3
================

Encoder enhancements
----------------------------------
1. New SSIM-based RD-cost computation for improved visual quality, and efficiency; use --ssim-rd to exercise.
2. Multi-pass encoding can now share analysis information from prior passes (in addition to rate-control information) to improve performance and quality of subsequent passes; to your multi-pass command-lines that use the --pass option, add --multi-pass-opt-distortion to share distortion information, and --multi-pass-opt-analysis to share other analysis information.
3. A dedicated thread pool for lookahead can now be specified with --lookahead-threads.
4. --dynamic-rd dynamically increase analysis in areas where the bitrate is being capped by VBV; works for both CRF and ABR encodes with VBV settings.
5. The number of bits used to signal the delta-QP can be optimized with the --opt-cu-delta-qp option; found to be useful in some scenarios for lower bitrate targets.
6. Experimental feature option:–aq-motion adds new QP offsets based on relative motion of a block with respect to the movement of the frame.

API changes
-------------------
1. Reconfigure API now supports signalling new scaling lists.
2. x265 application’s csv functionality now reports time (in milliseconds) taken to encode each frame.
3. --strict-cbr enables stricter bitrate adherence by adding filler bits when achieved bitrate is lower than the target; earlier, it was only reacting when the achieved rate was higher.
4. --hdr can be used to ensure that max-cll and max-fall values are always signaled (even if 0,0).

Bug fixes
--------------
1. Fixed incorrect HW thread counting on MacOS platform.
2. Fixed scaling lists support for 4:4:4 videos.
3. Inconsistent output fix for --opt-qp-pss by removing last slice’s QP from cost calculation.
4. VTune profiling (enabled using ENABLE_VTUNE CMake option) now also works with 2017 VTune builds.

Happy compressing!

[Selur]

Sadly 4:2:2 encoding causes x265 to crash and 4:4:4 encoding still produces artifacts when fed through ffmpeg (to be frank this one is more ffmpegs fault).

[Boulder]

x265 version 2.3 has been released. This release contains new algorithms that improve visual quality, encoding efficiency, and performance.

1. New SSIM-based RD-cost computation for improved visual quality, and efficiency; use --ssim-rd to exercise.


I was wondering, is this observation based on metrics or visual comparison? Also what about --tune grain, would this option have adverse effects there?

[Selur]

"SSIM-based RD-cost computation" -> sounds like metrics based ;)

[Boulder]

I was wondering about the "improved visual quality" -statement as it's generally considered a fact that visual comparison is needed in addition to any metrics :)

[LigH]

New milestone (stable merge build): x265 v2.3

x265 2.3+2-912dd749bdb5 (https://www.mediafire.com/file/45icnx8fa0nk3ba/x265_2.3%2B2-912dd749bdb5.7z) (mostly identical to v2.2+36)
_

Of course, SSIM-RD uses the SSIM metric to optimize rate distortion. The previously used metric will have been simpler than that, though, so chances are good that many people would agree with improved quality. But don't hesitate to organize a mass ABX test ;)

[Sagittaire]

@ dev team

x265 introduce specifical optimisation for new AMD Rysen CPU?

[x265_Project]

@ dev team

x265 introduce specifical optimisation for new AMD Rysen CPU?

We're still in the early phase of evaluating and optimizing performance on Ryzen. Nothing that I can report at this time. :)

[Selur]

What does 'analyze-src-pics' do?
Enalbe motion estimation with source frame pixels, in this mode, motion estimation can be computed independently.
Didn't really help in whether this is more of a testing feature, whether this is should boost compressibility,...

[Barough]

x265 v2.3+6-db913efb1a59 (http://ge.tt/2OycKqi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+6-db913efb1a59
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[mandarinka]

We're still in the early phase of evaluating and optimizing performance on Ryzen. Nothing that I can report at this time. :)

In case you are adding AMD core detection for Ryzen, could you also add a detection for Excavator?
Currently that core suffers about 4% performance hit due to using AVX2 which is available but slow on it. I think all you would need to do is add a condition to the CPU detection code that disables AVX2 use if both AVX2 and and AMD XOP instruction extensions are detected on the CPU. (Zen doesn't have XOP supposedly.) Or there might be other ways to check for Excavator more intelligently, I'm no expert by far :)

"SSIM-based RD-cost computation" -> sounds like metrics based ;)

I was wondering about the "improved visual quality" -statement as it's generally considered a fact that visual comparison is needed in addition to any metrics :)

Guys.... duh. Every encoder decision, including the current Psy RDO in x264 and x265, has to use some metric. Encoder being a computer program has no other way to do it. The difference is just that the current metrics were less complex, SSIM is probably replacing difference calculating tools like SAD/SATD.
To check the visual results and decide if you like them is your job, the program can't do it for you.

[littlepox]

If someone wish to use a method not being any metric, you must do the following:

1. the encoder encodes a block in several ways, then present the pictures to you;
2. you evaluate the quality of the pictures and assign them some marks
3. the encoder takes you evaluation and compute rate/distortion trade-off
4. go back to 1 with another block to encode


This is then a true "Human-eyes tuned rd"

[Boulder]

Guys.... duh. Every encoder decision, including the current Psy RDO in x264 and x265, has to use some metric. Encoder being a computer program has no other way to do it. The difference is just that the current metrics were less complex, SSIM is probably replacing difference calculating tools like SAD/SATD.
To check the visual results and decide if you like them is your job, the program can't do it for you.I was more or less interested in whether the devs had already had some visual comparison done or if the comparisons are purely based on metrics. I'm more than happy to accept the opinion of the majority what comes to visual quality, that's why I use presets :) But what that option actually does to --tune grain concerning keeping noise/grain is a bit unclear as I'm not that deep into the technical things.

[x265_Project]

What does 'analyze-src-pics' do?

Didn't really help in whether this is more of a testing feature, whether this is should boost compressibility,...

This is a test feature. It allows us to run experiments. It will hurt compression efficiency, so it shouldn't be used for any production encoding.

Normally, when the encoder performs inter-prediction (also known as motion compensated prediction), it must wait until the reference frames that it wants to use for frame #x are finished encoding before it can start encoding frame #x (or, with Wavefront Parallel Processing, it must wait until the first rows of the reference frames are completed before it can start). This feature tells the encoder to use the original source frames as reference frames, breaking that dependency. This would allow an encoder to run faster, especially for file-based encoding, as it has the dependent data (the source frames), and so it can start encoding each frame right away. But the source frames are not what the decoder will have when it is decoding. The actual decoded reference frames will be different (except for a lossless encode). So the inter-prediction won't be nearly as accurate when you use source frames as reference frames.

[Midzuki]

So, perhaps XhmikosR will release a new MSYS1 package only when GCC 7 is out...

Not true, fortunately. :) His MSYS_MinGW-w64_GCC_630_x86-x64_Full.7z went out of the oven yesterday:

http://xhmikosr.1f0.de/tools/msys/

[LigH]

Hooray! Thank you, XhmikosR! I'll start updating.

[Rinzler0x7BB]

Hi,

the last months i made a lot of tests with x265 and now I want to share my experience I made with one issue I had with small moving objects.

From the description of "Jawed" some months ago it seems that he saw a similar issue:

I found that motion in live action tended to become jittery (sort of as though it were half-rate: "anime" in feel).

http://forum.doom9.org/showpost.php?p=1777880&postcount=4189

I actually found the same source suffered the same fate with x264 at crf 24 (using settings that are almost equivalent to preset very slow in speed).
But in x264 I historically did not use crf as high as 24 - principally because blocking/banding with 8-bit encodes becomes unbearable.

So the same source in both x264 and x265 (both 10-bit) produced the same problem,
which disappears with crf 20. In x264, setting --tune grain also solved the problem (doubled the bitrate for the water test sequence too...).

So when I started my x265 experiments I started to investigate crf, pushing far beyond 21 which was my limit with x264 8-bit. 10-bit, it transpires,
makes x264 blocking/banding a non-issue, which was a good reason to see what I thought of higher crf values. Along the way I stumbled into this problem at crf 24.

(In fact I found the problem back in April and was so dismayed that I just forgot about my x265 experiments and did other things -
not realising at the time that it was b-frames causing the problem.)

On the water sequence I reported 4 b-frames as a solution.
But in other testing I found that rapidly turning faces (small in the frame) in low contrast (think "a steamy room") the problem recurred (horrible jumps, like anime).
So 2 b-frames it is.

I decided not to evaluate CRFs between 20 and 24 to see how the problem arises.
It just seems that at crf 24, b-frames (with x264 or x265 both on very slow preset) are too unreliable.
I hadn't noticed in the past with x264 because I hadn't used such a high value for crf.

My description
This is still visible with the current builds of x265 with lower crf values.
I describe it like a judder in front or the back of the object in the direction of the movement.
At first I thought that it is only visible with crf values lower than 21. But with a closer look it is also visible with crf 20.

How to reproduce
I found a video on youtube with which it was easy to reproduce this behavior.
"Loop 610 & U.S. 290 Interchange - Houston Construction - March 6, 2015 - 4K HD"
https://www.youtube.com/watch?v=Ax90e-F0z_M

This video has a lot of small cars which makes it perfect to see the judder on small cars.
To make it easier to see them i downscaled to 720p.
Enocde the video with --preset medium and --crf 22

My tests
I made a lot of Tests to reduce the judder. At first I started to use higher values which influence the motion estimation like --me star or higher --subme values.
But It helped only very little.

Then I found the setting which helped the most. --rd 5/6 did all the magic.
My problem with --rd 5/6 is the very low speed as I still wanted to have reasonable encoding times.
I also liked the better quality but together with --rdoq-level 2 and higher --psy-rdoq values which we need for high detail encodes it is too slow for me.

My solution
With another bunch of test encodes I found out that --rect helped nearly the same like --rd 5/6.
Then it is not necessary to use --rd 5/6 to have smooth motion on small moving objects.
--rect makes the encode also slower but there is a big difference to --rd 5/6.

My question
Is this a bug?. I did not recognize this behavior with x264.
Maybe there is a way to reduce this judder without the use of --rect or --rd 5 and have a faster encoding speed.

My low quality settings
I ended up in these settings which i use for my low quality encodes:
--profile main10 --output-depth 10 --preset medium --crf 22 --ctu 32 --aq-mode 3 --aq-strength 0.9 --aq-motion
--rc-lookahead 25 --no-sao --level-idc 4.1 --high-tier --rd 4 --psy-rd 2.1 --psy-rdoq 2.5 --rdoq-level 2
--bframes 6 --no-strong-intra-smoothing --b-intra --rect --limit-modes

My high quality settings
Finally these are my high quality settings I currently use:
--profile main10 --output-depth 10 --preset medium --crf 20 --ctu 32 --pbratio 1.22 --subme 3 --aq-mode 3 --aq-strength 0.9
--qcomp 0.64 --rc-lookahead 35 --no-sao --level-idc 4.1 --high-tier --rd 4 --psy-rd 2.5 --psy-rdoq 3.5 --rdoq-level 2
--bframes 8 --no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

[Sagittaire]

I was more or less interested in whether the devs had already had some visual comparison done or if the comparisons are purely based on metrics. I'm more than happy to accept the opinion of the majority what comes to visual quality, that's why I use presets :) But what that option actually does to --tune grain concerning keeping noise/grain is a bit unclear as I'm not that deep into the technical things.

well codec use by definition always metric. Tune grain use "complexity" metric too. all the decision in all codec use always metric. SSIM are by definition an HVS metric.

and you have generaly good correlation with metric and eye in all serious bench.

[aymanalz]

Using V2.3, with 2 pass encoding I am getting significantly higher speed for 2nd pass, than for first pass. Previously, they used to go at the same rate. I am guessing this is due to the Analysis and QP refinement enhancements? I don't use "fast first pass".

[Jamaika]

Not true, fortunately. :) His MSYS_MinGW-w64_GCC_630_x86-x64_Full.7z went out of the oven yesterday:
Buuuu, Windows 10 delete files EXE.
Trojan:Win32/Kandelo.B!cl

[LigH]

@ aymanalz:

I believe to remember that 1st pass statistics contain more reusable data than before, so the 2nd pass may be able to spare more calculations?

@ Jamaika:

Which AV possibly reports false alarms for which files? I'm still downloading (crappy rural connection); should be cross-checked with multi-engine AV web services like VirusTotal or malwr.

[Jamaika]

Well. I will not be risked. I take advantage of other software.:(

[LigH]

No warnings in MSSE.

MBAM scanning now... — No suspicious files found in this branch.

It would help us all a lot if you could show us a list which files your AV found to be suspicious.

BTW, you should always exclude the directory branch from resident AV scanners where binaries are being compiled to; incomplete binary files are easily mis-reported as suspicious.

[aymanalz]

@ aymanalz:

I believe to remember that 1st pass statistics contain more reusable data than before, so the 2nd pass may be able to spare more calculations?


That's my guess. The release notes say something about sharing info with the subsequent pass. If that is indeed the reason, then there is a very significant speed boost. I have only tested two clips so far, and the second pass was about 30% and 18% faster respectively in each.

[Midzuki]

Buuuu, Windows 10 delete files EXE.
Trojan:Win32/Kandelo.B!cl

Windows 10 is the root of all evil.
Just uninstall it, problem solved :sly:

[LigH]

x265 2.3+7-c15f8bce9f4b (https://www.mediafire.com/file/0sr5xqkkb3pb609/x265_2.3%2B7-c15f8bce9f4b.7z) [Windows][GCC 6.3.0][32+64 bit] 8bit+10bit+12bit

Luma/Chroma(fixed) offsets for HDR/WCG content, and some more Unicode support for filenames in Windows builds. New CLI parameters:

--capture-csp <string> Specify color primaries from bt709, p3d65, bt2020 for the capture device. Default bt709
--[no-]hdr-opt Add luma and chroma offsets for HDR/WCG content. Default disabled

[Selur]

'--capture-csp' <- shouldn't the default be 'undef' of something similar, in case there was no capture device ?

[Barough]

x265 v2.3+7-c15f8bce9f4b (http://ge.tt/5zTMDri2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit Multilib EXE's)

x265 [info]: HEVC encoder version 2.3+7-c15f8bce9f4b
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[NikosD]

There is no doubt that in a week or so with the first official reviews of RyZen CPUs, x265 is going to play a significant role evaluating the performance of those CPUs in a very popular app - a SW HEVC encoder.

But on the other hand, RyZen CPUs are going to play a significant role evaluating x265 software too, regarding different kind of optimizations after years of continuous development.

What I mean is that we are going to see if x265 is more optimized in ILP (instruction level parallelism) taking advantage of vector instructions like AVX2, than scale out optimizations with multicore/ multithreaded CPUs.

If there was a poll/ bet which CPU is going to be faster Kabylake Core i7 7700K or RyZen 1800X using x265 at default clocks, I would put my money on RyZen 1800X

[Atak_Snajpera]

Something tells me that Ryzen may not have great performance in AVX2(FMA).

RyZen (128bit FADD + 128bit FMUL + 128bit FADD +128bit FMUL)
https://www.purepc.pl/image/news/2017/02/10_amd_zen_mnostwo_szczegolow_dotyczacych_nowej_architektury_12.jpg

SandyBridge (256bit FADD + 256bit FMUL)
http://images.anandtech.com/reviews/cpu/intel/Haswell/Architecture/snbexec.png

Haswell (FMA 256bit FADD + FMA 256 FMUL)
http://images.anandtech.com/reviews/cpu/intel/Haswell/Architecture/haswellexec.png

I think that history will repeat itself. AVX2 will probably be again 2 times slower than in Intel.
http://i.imgsafe.org/7222342d9c.png

[NikosD]

Nice tables, very old news.

AMD designed ZEN architecture with that trade-off.

To sacrifice SIMD AVX/AVX2 performance in order to gain much lower TDP, many more cores (double at least) and higher clocks.

We will all see if that bet is like bulldozer or an Intel's HEDT killer.

[CruNcher]

Especialy it will be interesting how that plays out at 65/35W vs KabyLake at those 14nm between Globalfoundries and Intel :)

It is the first time Intel lost their shrinking advantage 11nm products still will take a little :)

and we see how much better TSMC did partly vs GF allready between Polaris and Paxwell and that 16nm vs 14nm

Though Polaris is overall slightly more complex especially through it's ACE.

[mandarinka]

Something tells me that Ryzen may not have great performance in AVX2(FMA).

That's known, but the 256bit units and data paths in Intel archs cost a lot in active power usage and silicon die area. It is likely that Zen can clock it's 128bit infrastructure higher thanks to keeping it more narrow. So the theoretical hit from not getting fast AVX2 might be mitigated by raised overall performance (and higher number of cores the architecture allowed).

I suspect that this effect might be even a net gain in x264, which only draws limited boost from AVX2. For x265, there is going to be overall loss and relative performance against Skylake is going to be worse in Zen, compared to situation in x264. But the hit might be lesser than expected as said above.

[Atak_Snajpera]

The lack of efficient AVX2 may hurt a lot in x265
https://i.imgsafe.org/83ceca5cee.png

Intel Xeon E5-2690 @ 2.9GHz (8c / 16t) [NO AVX2] 16.4 fps -> 16.4 / 3.2GHz (Turbo boost) / 16t = 0.32
Intel Core i7-6700K @ 4.5GHz (4c / 8t) [AVX2] 22.6 fps -> 22.6 / 4.5GHz / 8t = 0.63

[nevcairiel]

This thread should really stick to discussing the x265 encoder itself, there is a hardware section on the forums you can discuss Ryzen and other CPUs. :)

[NikosD]

Are you talking to yourself ?

Because you posted your opinion regarding RyZen and Intel's HEDT CPUs in VP9 thread


Ryzen doesn't have a iGPU.

Ryzen is at a point between Intels consumer models and the HEDT platform. It offers 8 cores at a price somewhere in the HEDT range (ie. latest rumors put EU prices at ~600€ for the 1800X, which is slightly above a i7 6850k, or the 1700X for ~470€ which sits similar to a 6800k), but on the other hand it doesn't have some of the HEDT features like extra PCIe lanes for multi-GPU.

So you can write about RyZen in VP9 thread,but we can't write about RyZen in x265 thread.

A little hypocritical, don't you think ?

[CruNcher]

It's moderators normal logic to brake up the discussion flow of off-topic, it is a strange thing because nothing is really off-topic if it interconnects in some way for a short time only if the timespan is way to long i personally can understand it to interfere in the discussion flow (making aware of it and moving it), i never gonna accept this strict idea of some moderators of offtopicsm but you get forced too obey that logic of off topic, or you risk to be punished at the hardest consequence.
But im especially against the punishment reaction of some moderators instead of taking appropriate actions in that case.

[pingfr]

Hey guys,

At the moment all I have on my hands is an i7-6700 (non K, locked at 3.7GHz) and while running a quick test encode, I am experiencing encoding speeds which I find "abysmal" to say the least.

I have two questions:

1) With the identical parameters: --crf 18 --aq-mode 3 --deblock -3:-3 --no-strong-intra-smoothing --no-sao while using the --preset slow, the encoder reports an average speed of 3.86 fps, encoding the clip in 647.09s.

However when using the same parameters but instead switching from --preset slow to --preset veryslow, the speed drops to a measly 0.30 fps, and that is of course while using an i7-6700 which is the 6th generation from Intel, that can't be right, can it? Could anyone here tell me which of the parameters included in the --preset veryslow compared to the --preset slow is the "culprit" here? the idea is to retain most of the "quality improvements" from the veryslow preset while retaining the "merely acceptable" encoding speeds yield by the slow preset.

2) In my testings, it appears switching from the default aq-mode which I believe is 1.0, to aq-mode 3.0 would decrease the encoding speeds by another 1fps, given at the best I would get a 4fps~ encoding speed, the use of an --aq-mode 3 would drop it from a solid 4fps to 3fps, that's a relative 25% performance hit right there, is this intended and does anyone here have an explanation in that regard?

Thanks.

Sample console output below in --preset slow for reference, neither running it as --preset slower or veryslow for now though, that would take over an hour to encode this 2500 frames clip.

C:\x26x>avs4x265.exe --preset slow --crf 18 --aq-mode 3 --deblock -3:-3 --no-strong-intra-smoothing --no-sao x264\SVT_1080p50.mkv.avs -o slow.hevc
avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 50/1
avs [info]: Video framecount: 2500
avs4x265 [info]: "x265" - --frames 2500 --fps 50/1 --input-res 1920x1080 --input-csp i420 --preset slow --crf 18 --aq-mode 3 --deblock -3:-3 --no-strong-intra-smoothing --no-sao -o slow.hevc
yuv [info]: 1920x1080 fps 50/1 i420p8 unknown frame count
raw [info]: output file: slow.hevc
x265 [info]: HEVC encoder version 2.3+7-c15f8bce9f4b
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 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 / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp lslices=4 deblock(tC=-3:B=-3)
x265 [info]: frame I: 10, Avg QP:19.26 kb/s: 167732.56
x265 [info]: frame P: 593, Avg QP:20.62 kb/s: 109843.70
x265 [info]: frame B: 1897, Avg QP:26.18 kb/s: 23832.23
x265 [info]: Weighted P-Frames: Y:4.2% UV:3.0%
x265 [info]: consecutive B-frames: 0.7% 1.7% 5.1% 67.5% 25.0%

encoded 2500 frames in 647.09s (3.86 fps), 44809.76 kb/s, Avg QP:24.83

Also noticed an odd behavior, the encoded result file is much larger than the source, what gives?

Source: 181.288.067 bytes.
Encode (slow preset): 280.072.779 bytes.

Wasn't the whole intent and philosophy behind x265 "smaller encoded file size due to better compression over x264 at the cost of more CPU cycles?", the result is 100MBytes larger than it's sources counterpart...

[WhatZit]

2) In my testings, it appears switching from the default aq-mode which I believe is 1.0, to aq-mode 3.0 would decrease the encoding speeds by another 1fps, given at the best I would get a 4fps~ encoding speed, the use of an --aq-mode 3 would drop it from a solid 4fps to 3fps, that's a relative 25% performance hit right there, is this intended and does anyone here have an explanation in that regard?

Your settings strongly suggest that fine detail preservation is a priority for your encodes.

From my own testing, I've found that --aq-mode 3 is a poor substitute (quality-wise) for --tune grain. Whilst it is slightly faster, it somehow manages to retain less overall detail (according to my eyes) whilst using a larger bitrate than grain does.

Also noticed an odd behavior, the encoded result file is much larger than the source, what gives?


Firstly, is the source noisy or grainy, with high-contrast detail, or has it otherwise been artificially post-sharpened (excessive peak edging)?

These are the worst types of source for x265 to compress when you start weighting the encoder for detail preservation. It is entirely normal for x265's efficiency to barely exhibit any improvement over x264 in those cases, and you can easily go backwards depending on source ("sharpened" sources especially so).

Secondly, when you have x265 set to preserve detail, the slower speed settings will, indeed, preserve more detail, hence produce larger file sizes. The same settings (i.e. --tune grain) will produce a 25% larger file at --preset slow than they will at --preset fast.

Wasn't the whole intent and philosophy behind x265 "smaller encoded file size due to better compression over x264 at the cost of more CPU cycles?", the result is 100MBytes larger than it's sources counterpart...

x265's lossy compression efficiency isn't magic. It is simply more aggressive (or clever, depending on your point of view) than x264 with what visual data it chooses to include in the encoded bitstream, and it can accordingly decode watchable scenes from much less data than x264. In other words, by default, it leaves out as much visual information as possible during an encode because it doesn't need as much during a decode.

When you use custom high-frequency settings to force the inclusion of visual information that would otherwise have been excluded, you are effectively changing the "philosophy" behind x265. That's a harsh way of putting it, but you asked the question.

x265 can follow x265's philosophy if you let it do it's own thing, or it can operate like any other encoder if you want to manipulate the settings yourself.

Regardless, I've personally found that x265 always has some efficiency improvement over x264, even if it's only marginal due to bothersome sources, and that improvement definitely increases with higher resolutions.

[Kotatsu]

I frames dose not increase if --scenecut 40 over.

C:\x265\x265.exe --preset slow --crf 17 --scenecut 0 "C:\x265\testvideo.y4m" -o null
frame I: 3, Avg QP:18.35 kb/s: 22734.00 frame P: 288, Avg QP:18.40 kb/s: 15331.26 frame B: 429, Avg QP:22.63 kb/s: 4139.60

C:\x265\x265.exe --preset slow --crf 17 --scenecut 5 "C:\x265\testvideo.y4m" -o null
frame I: 19, Avg QP:15.76 kb/s: 32103.99 frame P: 283, Avg QP:18.48 kb/s: 14309.48 frame B: 418, Avg QP:22.67 kb/s: 4075.80

C:\x265\x265.exe --preset slow --crf 17 --scenecut 10 "C:\x265\testvideo.y4m" -o null
frame I: 20, Avg QP:15.77 kb/s: 32639.96 frame P: 282, Avg QP:18.47 kb/s: 14221.44 frame B: 418, Avg QP:22.67 kb/s: 4075.99

C:\x265\x265.exe --preset slow --crf 17 --scenecut 15 "C:\x265\testvideo.y4m" -o null
frame I: 20, Avg QP:15.77 kb/s: 32639.96 frame P: 282, Avg QP:18.47 kb/s: 14221.44 frame B: 418, Avg QP:22.67 kb/s: 4075.99

C:\x265\x265.exe --preset slow --crf 17 --scenecut 20 "C:\x265\testvideo.y4m" -o null
frame I: 21, Avg QP:15.78 kb/s: 32707.41 frame P: 281, Avg QP:18.48 kb/s: 14169.16 frame B: 418, Avg QP:22.68 kb/s: 4075.12

C:\x265\x265.exe --preset slow --crf 17 --scenecut 25 "C:\x265\testvideo.y4m" -o null
frame I: 21, Avg QP:15.78 kb/s: 32707.41 frame P: 281, Avg QP:18.48 kb/s: 14169.16 frame B: 418, Avg QP:22.68 kb/s: 4075.12

C:\x265\x265.exe --preset slow --crf 17 --scenecut 40 "C:\x265\testvideo.y4m" -o null
frame I: 22, Avg QP:15.81 kb/s: 32495.99 frame P: 281, Avg QP:18.47 kb/s: 14124.01 frame B: 417, Avg QP:22.68 kb/s: 4064.71

C:\x265\x265.exe --preset slow --crf 17 --scenecut 60 "C:\x265\testvideo.y4m" -o null
frame I: 22, Avg QP:15.81 kb/s: 32495.99 frame P: 281, Avg QP:18.47 kb/s: 14124.01 frame B: 417, Avg QP:22.68 kb/s: 4064.71

C:\x265\x265.exe --preset slow --crf 17 --scenecut 80 "C:\x265\testvideo.y4m" -o null
frame I: 22, Avg QP:15.81 kb/s: 32495.99 frame P: 281, Avg QP:18.47 kb/s: 14124.01 frame B: 417, Avg QP:22.68 kb/s: 4064.71

C:\x265\x265.exe --preset slow --crf 17 --scenecut 100 "C:\x265\testvideo.y4m" -o null
frame I: 22, Avg QP:15.81 kb/s: 32495.99 frame P: 281, Avg QP:18.47 kb/s: 14124.01 frame B: 417, Avg QP:22.68 kb/s: 4064.71

[pingfr]

Could anyone here tell me which of the parameters included in the --preset veryslow compared to the --preset slow is the "culprit" dropping encoding speeds from 4fps to 0.30fps?

The idea is to retain most of the "quality improvements" from the veryslow preset while retaining the "merely acceptable" encoding speeds yield by the slow preset. There has to be some kind of middle grounds between both presets.

Thanks.

[Leo 69]

This is close to hq middle ground you want:

x265.exe --preset veryslow --crf 18 --aq-mode 3 --ctu 32 --qg-size 8 --deblock -1:-1 --no-strong-intra-smoothing --no-sao --tu-intra-depth 4 --tu-inter-depth 2 --limit-tu 1 --no-b-intra --no-amp --bframes 6 --no-rskip

[pingfr]

This is close to hq middle ground you want:

x265.exe --preset veryslow --crf 18 --aq-mode 3 --ctu 32 --qg-size 8 --deblock -1:-1 --no-strong-intra-smoothing --no-sao --tu-intra-depth 4 --tu-inter-depth 2 --limit-tu 1 --no-b-intra --no-amp --bframes 6 --no-rskip

Thank you for that.

Is it optimum settings for 1080p Blu-Ray source content?

And which settings would you recommend for resizing to 720p from Blu-Ray source content?

Thanks.

[pingfr]

@Lego69: Unbearable 0.76 fps encoding speeds. No thanks. ;)

[Leo 69]

For me these are optimum settings for 1080p encodes, yes. For 720p you might want only add --merange 38. That's all.

Edit: add/change --tu-intra-depth 3 --tu-inter-depth 1 --no-weightb --max-merge 3 to the initial line I proposed.

[pingfr]

@Leo 69: What about the speeds you're experiencing during 1080p encoding?

[Leo 69]

@pingfr

This was the last setting I encoded a 1920x800 movie in:

x265.exe --crf 19.3 --preset placebo --output-depth 10 --ctu 32 --no-rect --no-amp --no-b-intra --aq-strength 0.5 --qcomp 0.7 --cbqpoffs -3 --ipratio 1.3 --pbratio 1.2 --subme 6 --merange 57 --bframes 6 --no-strong-intra-smoothing --deblock -1:-1 --psy-rd 3.5 --psy-rdoq 7 --no-sao --qg-size 8 --limit-tu 1 --crqpoffs -3 --no-rskip

This gave me ~1FPS on an old Ivy Bridge 3570K@4400Mhz (no AVX2, of course). I don't touch noisy sources with x265, the blu-ray source was crystal clear.

[pingfr]

avs4x265 [info]: "x265" - --frames 2500 --fps 50/1 --input-res 1920x1080 --input-csp i420 --preset veryslow --crf 18 --aq-mode 3 --ctu 32 --qg-size 8 --deblock -1:-1 --no-strong-intra-smoothing --no-sao --tu-intra-depth 3 --tu-inter-depth 1 --no-weightb --max-merge 3 --limit-tu 1 --no-b-intra --no-amp --bframes 6 --no-rskip -o out.hevc

Average speed 1.01 fps. That's just terrible.

[pingfr]

avs4x265 [info]: "x265" - --frames 2500 --fps 50/1 --input-res 1920x1080 --input-csp i420 --crf 19.3 --preset placebo --output-depth 10 --ctu 32 --no-rect --no-amp --no-b-intra --aq-strength 0.5 --qcomp 0.7 --cbqpoffs -3 --ipratio 1.3 --pbratio 1.2 --subme 6 --merange 57 --bframes 6 --no-strong-intra-smoothing --deblock -1:-1 --psy-rd 3.5 --psy-rdoq 7 --no-sao --qg-size 8 --limit-tu 1 --crqpoffs -3 --no-rskip -o test.hevc

That's 0.49 fps. Unacceptable.

[pingfr]

avs4x265 [info]: "x265" - --frames 2500 --fps 50/1 --input-res 1920x1080 --input-csp i420 --crf 19.3 --preset slow --output-depth 10 --ctu 32 --no-rect --no-amp --no-b-intra --aq-strength 0.5 --qcomp 0.7 --cbqpoffs -3 --ipratio 1.3 --pbratio 1.2 --subme 6 --merange 57 --bframes 6 --no-strong-intra-smoothing --deblock -1:-1 --psy-rd 3.5 --psy-rdoq 7 --no-sao --qg-size 8 --limit-tu 1 --crqpoffs -3 --no-rskip -o slow.hevc

2.98 fps.

[Leo 69]

I'm sorry, maybe someone else has a better idea to improve your speed without hitting quality too much.

[pingfr]

Well at least you've tried. Much kudos for that.

[Boulder]

--limit-refs 3 --limit-modes --limit-tu 3 --rskip are ones to add. --rskip will boost the encoding speed considerably.

[pingfr]

@Boulder: So --limit-refs 3 --limit-modes --limit-tu 3 --rskip only with a given preset or with other args added as well?

[Boulder]

I use them with --preset slower --tune grain. They could be incorporated in the preset as well but they are basically the best bang for buck what comes to performance and encoding time.

[pingfr]

avs4x265 [info]: "x265" - --frames 2500 --fps 50/1 --input-res 1920x1080 --input-csp i420 --preset slower --tune grain --limit-refs 3 --limit-modes --limit-tu 3 --rskip -o boulder.hevc

1.50fps at the best, 1.30fps at the lowest. :/

[Leo 69]

Try this line. How many FPS do you get?

--preset veryslow --crf 18 --aq-mode 3 --ctu 32 --qg-size 8 --deblock -1:-1 --no-strong-intra-smoothing --no-sao --tu-intra-depth 3 --tu-inter-depth 1 --no-weightb --max-merge 3 --limit-tu 3 --limit-refs 3 --no-b-intra --no-amp --no-rect --bframes 6 --rskip

[pingfr]

1.58fps at the best, 1.54fps at the worst.

[Boulder]

I wouldn't say 1.5 fps at preset slower is bad for 1080p.. x265 is much slower than x264, there's no way around it due to the added complexity of things.

--no-rect and/or --no-amp can give a slight boost. I keep them enabled as they should help retain detail better.

[Leo 69]

I wouldn't say 1.5 fps at preset slower is bad for 1080p.. x265 is much slower than x264, there's no way around it due to the added complexity of things.

Absolutely.

--no-rect and/or --no-amp can give a slight boost. I keep them enabled as they should help retain detail better.

I never saw that switching on rectangular and asymmetric partitions would improve visual quality. I can't tell the difference whether they're on or off on any encodes.

[aymanalz]

I wouldn't say 1.5 fps at preset slower is bad for 1080p.. x265 is much slower than x264, there's no way around it due to the added complexity of things.


Yes, but with his i7-6700, I think he should definitely be getting faster encodes.

@pingfr : Are you sure there is nothing bottlenecking your system? Have you checked out your CPU usage during encoding? Is it always above 90%?

Reducing the maximum CU size to 32 can give a big speed boost. For resolutions less than 1080p, the difference in quality may not be significant. Same with merange.

Edit: I noticed that you are already using CTU 32. I'm pretty sure something is off, if you are only getting the speeds you say. Is hyperthreading turned on, are you using the appropriate values for threads/pools etc?

[pingfr]

Yes, but with his i7-6700, I think he should definitely be getting faster encodes.

@pingfr : Are you sure there is nothing bottlenecking your system? Have you checked out your CPU usage during encoding? Is it always above 90%?

Reducing the maximum CU size to 32 can give a big speed boost. For resolutions less than 1080p, the difference in quality may not be significant. Same with merange.

Edit: I noticed that you are already using CTU 32. I'm pretty sure something is off, if you are only getting the speeds you say. Is hyperthreading turned on, are you using the appropriate values for threads/pools etc?

Everything seems normal to me: http://imgur.com/a/fYSy4

Also note this is a regular non-K, non unlocked i7-6700.

According to ARK, it's base frequency is 3.4GHz with a alleged Turbo Boost to 4.00GHz but for some reason throttles to 3.7GHz while under 100% load, it can however reach 4.0GHz on a single core.

https://ark.intel.com/products/88196/Intel-Core-i7-6700-Processor-8M-Cache-up-to-4_00-GHz

[Dclose]

I never saw that switching on rectangular and asymmetric partitions would improve visual quality. I can't tell the difference whether they're on or off on any encodes.
I have. I never turn rectangle off after doing some tests of it. Sometimes I turn asymmetric off to increase speed since asymm is a worse quality/speed ratio than rectangle, but when I'm going for better quality I turn it on since it does help tighten up the picture a little more.

I easily noticed the difference again the other day when doing some tests. I was doing quality comparisons by watching the video play from four feet away on a 40" screen. Some people may think that's too close, while some people around here do their comparisons by zooming in on screenshots and analyzing pixels.

The biggest speed boost is probably Early Skip. The quality difference is generally quite obvious to me, but the speed increase is even more obvious. I'd say the higher the resolution (and bitrate), the less Early Skip hurts quality.

The more bitrate used, the less the quality settings matter. I'm usually dropping bitrate below what most people would think is acceptable, so the different quality settings tend to show differences more, so I rarely use speed boosts like Early Skip, and things like Max Merge can have a very noticeable difference on video quality.

[pradeeprama]

Could anyone here tell me which of the parameters included in the --preset veryslow compared to the --preset slow is the "culprit" dropping encoding speeds from 4fps to 0.30fps?

The idea is to retain most of the "quality improvements" from the veryslow preset while retaining the "merely acceptable" encoding speeds yield by the slow preset. There has to be some kind of middle grounds between both presets.

Thanks.

I suspect the top culprits for why fps drops so significantly with veryslow, when compared to slow preset is because of increased rd-level, increased subme, +1 reference frames, and enabling more TU search (--tu-inter 3 --tu-intra 3 in veryslow instead of --tu-inter 1 --tu-intra 1 that slow has).

I would recommend increasing --limit-ref and --limit-modes, enabling --limit-tu 4 and trying if that helps contain the drop in fps. There is another feature called --dynamic-rd that dynamically increases rd-level to 5 when you start with 4, but this works only when VBV parameters are used and they clip the quality due to excessive bits.

[aymanalz]

@pingfr : Maybe I'm missing it, but I cannot see a value for CPU load in the CPU-Z screenshot you provided. I only see info about the CPU itself. Open task manager (Win+shift+esc) to see how much of your CPU is being used. If the x265 executable is not using more than 90% all the time, you can be sure that there is a bottleneck somewhere.

Your rd-level is 6; that is definitely a major factor in speed. Reducing it to 4 can improve speed considerably. (Will quality loss be tolerable, I cannot say - you will have to test it out.) If I'm not mistaken, limit ref depth and CU only works for rd-level below 5. Those options give significant speed boost with little quality loss, but they are automatically disabled because your rd-level is too high.

[Midzuki]

x265 2.3+8-cfaff341e350

SAO: avoid negative indexes in 'x265_lambda2_tab' table

http://www.mediafire.com/file/0857vp1pcuvgw80/x265_2.3+8-cfaff341e350.7z

[ShogoXT]

I think I am going to be getting one of the new 8 core Ryzen CPUs.

From the rumors ive been hearing about, its main weakness will be AVX.

Would it be worthwhile to benchmark and compare its speed on different instructions vs intel CPUs with the use of -asm using x265?

Thanks

[Midzuki]

According to commit 820f4327ddac... ,

CLI: Remove redundant cli option 'capture-csp'

OK, but now, ¿when MCW is going to finally correct the information shown below?

--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

[Ma]

[...] ¿when MCW is going to finally correct the information shown below?

--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

This change will be OK?
diff -r 820f4327ddac source/x265cli.h
--- a/source/x265cli.h Mon Feb 20 17:18:53 2017 +0530
+++ b/source/x265cli.h Tue Feb 21 20:48:09 2017 +0100
@@ -391,7 +391,7 @@
H0(" --rc-lookahead <integer> Number of frames for frame-type lookahead (determines encoder latency) Default %d\n", param->lookaheadDepth);
H1(" --lookahead-slices <0..16> Number of slices to use per lookahead cost estimate. Default %d\n", param->lookaheadSlices);
H0(" --lookahead-threads <integer> Number of threads to be dedicated to perform lookahead only. Default %d\n", param->lookaheadThreads);
- H0(" --bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default %d\n", param->bframes);
+ H0("-b/--bframes <0..16> Maximum number of consecutive b-frames. Default %d\n", param->bframes);
H1(" --bframe-bias <integer> Bias towards B frame decisions. Default %d\n", param->bFrameBias);
H0(" --b-adapt <0..2> 0 - none, 1 - fast, 2 - full (trellis) adaptive B frame scheduling. Default %d\n", param->bFrameAdaptive);
H0(" --[no-]b-pyramid Use B-frames as references. Default %s\n", OPT(param->bBPyramid));

[Midzuki]

This change will be OK?
diff -r 820f4327ddac source/x265cli.h
--- a/source/x265cli.h Mon Feb 20 17:18:53 2017 +0530
+++ b/source/x265cli.h Tue Feb 21 20:48:09 2017 +0100
@@ -391,7 +391,7 @@
H0(" --rc-lookahead <integer> Number of frames for frame-type lookahead (determines encoder latency) Default %d\n", param->lookaheadDepth);
H1(" --lookahead-slices <0..16> Number of slices to use per lookahead cost estimate. Default %d\n", param->lookaheadSlices);
H0(" --lookahead-threads <integer> Number of threads to be dedicated to perform lookahead only. Default %d\n", param->lookaheadThreads);
- H0(" --bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default %d\n", param->bframes);
+ H0("-b/--bframes <0..16> Maximum number of consecutive b-frames. Default %d\n", param->bframes);
H1(" --bframe-bias <integer> Bias towards B frame decisions. Default %d\n", param->bFrameBias);
H0(" --b-adapt <0..2> 0 - none, 1 - fast, 2 - full (trellis) adaptive B frame scheduling. Default %d\n", param->bFrameAdaptive);
H0(" --[no-]b-pyramid Use B-frames as references. Default %s\n", OPT(param->bBPyramid));

Thanks for asking.
Well, that's almost good. THIS is the right way to do it.
H0("-b/--bframes <0..16> Maximum number of consecutive B-frames. Default %d\n", param->bframes);

H1(" --bframe-bias <integer> Bias towards B-frame decisions. Default %d\n", param->bFrameBias);

H0(" --b-adapt <0..2> 0 - none, 1 - fast, 2 - full (trellis) adaptive B-frame scheduling. Default %d\n", param->bFrameAdaptive);

H0(" --[no-]b-pyramid Use B-frames as references. Default %s\n", OPT(param->bBPyramid));


Because consistency matters.

[youli]

Options test: --aq-motion and --dynamic-rd.
Bitrate decrease about 3,5%.
Encoded 178944 frames in 107297.17s (1.67 fps), 18252.68 kb/s, Avg QP:24.23

MediaInfo:
Writing library : x265 2.2+36-9b975fec584a:[Windows][GCC 6.2.0][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x2160 / interlace=0 / total-frames=178944 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=2 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=4.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=3 / subme=7 / merange=25 / temporal-mvp / weightp / weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=3.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=24.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / vbv-maxrate=100000 / vbv-bufsize=100000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.10 / pbratio=1.10 / aq-mode=3 / aq-strength=0.60 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=51 / qpmin=0 / sar=16 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / no-hdr

Bitrate distribution:
http://img11.lostpic.net/2017/02/22/e39e13d4eba1f1e418e73b29631c6267.th.png (http://lostpic.net/image/Q8n6)

Screenshots comparison:
Source BD3D (left eye) and Blu-Ray Rip Top-Bottom (left eye first) at 4914 second with bitrate 76592 kbps (maximum for this video).
http://s018.radikal.ru/i525/1702/04/895a3cbbdc0bt.jpg (http://radikal.ru/fp/vvjsvne2qhtf2) http://s018.radikal.ru/i510/1702/09/760d6c8d0f7ft.jpg (http://radikal.ru/fp/64e29031dw6yq)

[NikosD]

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

[pingfr]

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

Would love to see some substantial evidences. ;)

[Atak_Snajpera]

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

Sound reasonable. AVX2 is about ~1.6x faster than AVX. Thanks to 2xAVX256+FMA Intel can still compete against 8c/16t CPU.
http://images.anandtech.com/reviews/cpu/intel/Haswell/Architecture/flops.jpg?_ga=1.88542875.1424348284.1464096708
http://i.imgsafe.org/afb986b279.png

[pingfr]

@Atak_Snajpera: You've got the screenshots I've sent you earlier this week in PM? :p

[NikosD]

Sound reasonable. AVX2 is about ~1.6x faster than AVX. Thanks to 2xAVX256+FMA Intel can still compete against 8c/16t CPU.
http://images.anandtech.com/reviews/cpu/intel/Haswell/Architecture/flops.jpg?_ga=1.88542875.1424348284.1464096708
http://i.imgsafe.org/afb986b279.png
FMA has nothing to do with x265, because AFAIK x265 uses integers and FMA is for floating point numbers.

Integer AVX2 makes the difference, will see how much.

[Atak_Snajpera]

x264 and x265 use FMA3. See encoder's output 'using cpu capabilities'

[NikosD]

It doesn't matter if it lists CPU capabilities.

It really matters what exactly instructions x265 can use.

It would be a huge surprise if it could use FMA3 in a large extent or at all.

[pingfr]

It doesn't matter if it lists CPU capabilities.

It really matters what exactly instructions x265 can use.

It would be a huge surprise if it could use FMA3 in a large extent or at all.

See encoder's output 'using cpu capabilities'

Using:

verb (used with object), used, using.
1.
to employ for some purpose; put into service; make use of:
to use a knife.

Source: http://www.dictionary.com/browse/using?s=t

[NikosD]

Age ? 15 ?

[pingfr]

Age ? 15 ?

*shrug*

[LigH]

*sigh* How much energy for development is wasted in ego wars instead. :(

[troica]

Hello guys can anyone help me? I'm trying to code in visual studios wherein I want to produce a text file that reports the changes after encoding a YUV video. The text file consists of the frame #, slice #, CTU# etc. Thank you for any help.

[LigH]

What kind of changes do you mean? Differences according to metrics like PSNR or SSIM? Absolute differences per YUV channel?

x265 can already produce a CSV log file per frame.

--csv <filename> Comma separated log file, if csv-log-level > 0 frame level statistics, else one line per run
--csv-log-level <integer> Level of csv logging, if csv-log-level > 0 frame level statistics, else one line per run: 0-2

[birdie]

Ryzen supports AVX2, so let's hope for the best and expect the worst. :-)

[LigH]

You probably mean it similar to the support of SSE3 by Phenom-II, which is considered too slow by x264/x265 to be enabled? :rolleyes:

[NikosD]

The developers of x265 can tell us for sure if and how FMA3 is used.

Because nobody here disagrees that integer AVX2 is used a lot by x265.

Usually a floating point division or some other single floating point instruction could be used in projects like x264 or x265 but nothing more than that regarding floating point support.

SSEx is very fast in RyZen, it's as fast as Kabylake.

AVX/AVX2 is supported, but it's about half speed.

[Ma]

The developers of x265 can tell us for sure if and how FMA3 is used.

FMA3 (nor FMA4) is not used in x265. It could be used for example in
https://bitbucket.org/multicoreware/x265/src/820f4327ddac44decb4328602ca63e84197ab473/source/common/x86/mc-a2.asm?at=default&fileviewer=file-view-default#mc-a2.asm-1120
but the speed up is only a few CPU cycles in function that is not important for whole encoding time. It is OK to use MUL and ADD instead of one FMA.

[troica]

What kind of changes do you mean? Differences according to metrics like PSNR or SSIM? Absolute differences per YUV channel?

x265 can already produce a CSV log file per frame.

--csv <filename> Comma separated log file, if csv-log-level > 0 frame level statistics, else one line per run
--csv-log-level <integer> Level of csv logging, if csv-log-level > 0 frame level statistics, else one line per run: 0-2

I mean like what kind of config you have before and after encoding..

If I encoded using 10 frames it will show 10 frames etc and record the quantization parameters per CTU etc

[LigH]

So you are looking for an API that will trigger even more detailed reports than the CSV log with level 2, even a per-CTU log... I believe there is none yet, only per-file and per-frame logs (see: x265-extras.h).

[troica]

So you are looking for an API that will trigger even more detailed reports than the CSV log with level 2, even a per-CTU log... I believe there is none yet, only per-file and per-frame logs (see: x265-extras.h).

If so, how do access thex265-extras? Sorry for being a noob at encoders.

And is there anything I can code in visual studios to report the per CTU log?

[LigH]

I assume you already used Mercurial to clone the whole x265 source repository? Apart from that, you can look at the source here:

https://bitbucket.org/multicoreware/x265/src / source / x265-extras.h (as well as x265-extras.cpp)

[troica]

How do you access the source files?

[birdie]

Intel got scared: http://wccftech.com/intel-amd-price-war-ryzen-processors/

Hopefully you haven't bought any Intel CPUs lately 'cause it's time to kick yourself in the balls.

Lovely!

[LigH]

@ troica:

Always read the documentation (https://bitbucket.org/multicoreware/x265/wiki/Home) first...

[troica]

Okay sorry. I really don't know how to start using HEVC and how to simulate a wireless video transmission between visual studios and the ns3 program. It's where my thesis will start so sorry if I got a lt oof questions. Btw, is this x265 the HM model?

[Barough]

x265 v2.3+9-820f4327ddac (http://www82.zippyshare.com/v/XdCFQwng/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Sagittaire]

I was told by an Intel fanboy and RyZen 7 reviewer that you need a Core i7 7700K@4.8GHz to catch the performance of RyZen 7@4.0GHz at x265 2nd pass or you could see the same thing reversed.

Will see...

No, Rysen 7 1800X 8C/16T at 500$ will be certainely on par with i7 6900K 8C/16T at 1000$ for x264/x265 encoding. You must use certainely something like O/C at 6 Ghz (nitrogen!!!) with i7 7700K (400$) or even more to have the same performance than R7 1700 (350$) at stock frequency.

[NikosD]

x264 is a lot different than x265 due to AVX2 optimizations.

Yes, I agree that using x264 RyZen is going to have a party.

But x265 has a lot of AVX2 optimizations and it's not possible for RyZen 7 to catch the performance of an Intel 8C/16T.

[Motenai Yoda]

No, Rysen 7 1800X 8C/16T at 500$ will be certainely on par with i7 6900K 8C/16T at 1000$ for x264/x265 encoding. You must use certainely something like O/C at 6 Ghz (nitrogen!!!) with i7 7700K (400$) or even more to have the same performance than R7 1700 (350$) at stock frequency.

I'd not be so enthusiast about Ryzen, as the only public comparison is still the amd charts one, and as bulldozer and its derivates are nothing better than intel's ones.

Also 7700k cost now about 340€ (maybe 320/300€ with the 10/15$ prices cut), sure not 400$, and 1700x is (yep) an esacore, but with castrated avx2 and few/no compiler optimizations.

6900k is the actual not plus ultra for a consumer pc so it's baldly overvalued.

[Sagittaire]

I'd not be so enthusiast about Ryzen, as the only public comparison is still the amd charts one, and as bulldozer and its derivates are nothing better than intel's ones.

Also 7700k cost now about 340€ (maybe 320/300€ with the 10/15$ prices cut), sure not 400$, and 1700x is (yep) an esacore, but with castrated avx2 and few/no compiler optimizations.

6900k is the actual not plus ultra for a consumer pc so it's baldly overvalued.

There are here in France exclusive test on "CPC hardware magazine" since one month. The test CPU model is 3.15/3.3/3.5 Ghz 8C/16T sample (will be like R7 1700).

Overall benchmark for x264 HB encodaging 2K, x265 HB encodaging 4K, WPrime, PovRay, Blender, 3DMax 2015/Mental Ray, Coronna Benchmark

i7 6900K: 193.4
R7 3.15/3.3/3.5 Ghz: 168.7
i7 6800K: 152.5
i7 6700K: 137.3
i7 4790K: 127.7
FX-8370: 105.2
i5 6600K: 100.0

Make scaling for R7 1800X at 3.6/3.8/4.0 Ghz by yourself ... ;-)

[Sagittaire]

x264 is a lot different than x265 due to AVX2 optimizations.

Yes, I agree that using x264 RyZen is going to have a party.

But x265 has a lot of AVX2 optimizations and it's not possible for RyZen 7 to catch the performance of an Intel 8C/16T.

Rysen seem to have really good AVX/AVX2 implementation too ... Almost as good as Kaby lake

[NikosD]

I certainly don't believe that.

[nevcairiel]

Rysen seem to have really good AVX/AVX2 implementation too ... Almost as good as Kaby lake

Even AMD documentation says that AVX/AVX2 is implemented using 128-bit processing units (and not 256-bit), so they have about half the throughput as Intel - which would have quite a strong impact on x265 performance.

Anyway, we'll see actual believable results in a week or so, not "leaked" results or AMD marketing results.

[birdie]

March the 2nd is really close, it's just four days from now. I guess we can all stop and wait for the official benchmarks. Also, there are rumors that AMD has already shipped a million Ryzen CPUs so we'll have a lot of data to chew on.

[LigH]

I'll be curious too. AMD used to be "notorious" for well optimized die designs vs. "brute force" preferred by intel. And even if RyZen is not as powerful as people may hope for, we still have to thank AMD for pushing intel (and Nvidia?) back to a solid ground, regarding price management ... :rolleyes: — Thanks birdie for the link a page ago.

[pingfr]

Anyone could take a quick peek at these settings and tell me if I'm missing a tweak here and there, thanks?

C:\x26x>x265.exe --crf 18 --aq-mode 1 --ctu 64 --qg-size 32 --deblock -1:-1 --me star --bframes 6 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 92 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 0 --limit-modes --tskip --rect --amp --max-merge 5 --subme 7 --b-intra source.y4m -o out.hevc

Thanks!

Edit: Also what about --cutree ?

[aymanalz]

Anyone could take a quick peek at these settings and tell me if I'm missing a tweak here and there, thanks?

C:\x26x>x265.exe --crf 18 --aq-mode 1 --ctu 64 --qg-size 32 --deblock -1:-1 --me star --bframes 6 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 92 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 0 --limit-modes --tskip --rect --amp --max-merge 5 --subme 7 --b-intra source.y4m -o out.hevc

Thanks!

Edit: Also what about --cutree ?

merange 92 is insanely high. What is the video resolution?

[divxmaster]

Anyone could take a quick peek at these settings and tell me if I'm missing a tweak here and there, thanks?

C:\x26x>x265.exe --crf 18 --aq-mode 1 --ctu 64 --qg-size 32 --deblock -1:-1 --me star --bframes 6 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 92 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 0 --limit-modes --tskip --rect --amp --max-merge 5 --subme 7 --b-intra source.y4m -o out.hevc

Thanks!

Edit: Also what about --cutree ?

I would add
--rskip --no-sao --no-open-gop
and I prefer
--psy-rdoq 1.1

Cheers,
Divxmaster

[troica]

Hello guys is this x265 and HM reference model the same?

[Selur]

they both implement the same standard, but x265 has lot of optimizations.
HM = example on how it could be done for academic purposes
x265 = real world implementation which is a lot faster and usable

[WhatZit]

Anyone could take a quick peek at these settings and tell me if I'm missing a tweak here and there, thanks?

I'm constantly amazed why people keep pursing gigantic strings of parameters to try and solve a problem that's already been solved.

--tune grain, along with its built-in rc-grain algorithm, fundamentally changes the encoding decisions x265 makes by weighting towards quality over compression (aka high-frequency retention).

The settings contained in these presets...

http://i66.tinypic.com/ka495x.jpg

...retain more detail the slower you go. So much so that you can easily drop your non-grain CRF's BACK one or two notches at the slower presets.

I suspect that most people who don't understand tunegrain have just left the rest of their options at "veryslow CRF18" when "slow CRF20" would probably produce comparable visual quality, faster encodes and smaller filesizes.

This is my current command line, which replaced something 20+ parameters long:

--profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing

Note that I haven't included the CRF or preset? That's because preset+CRF is ALL I change to adjust speed/filesize whilst still retaining quality for ANY encode, depending on the source.

Now, I'll admit that tunegrain could still undergo some tweaks for speed, and others have suggested the parameters to do that. Myself, I couldn't be happier about ditching the pursuit of endless quality experiments with this-command-line and that-command-line.

[troica]

they both implement the same standard, but x265 has lot of optimizations.
HM = example on how it could be done for academic purposes
x265 = real world implementation which is a lot faster and usable

Are they both programmable using visual studios? My thesis is about wireless video transmission using HEVC with HM, but I dont really know how to start using visual studios :(

[Selur]

not sure what you understand under 'programmable', but both can be compiled with MSVC and iirc both have an API and can be compiled as libraries.
-> no clue how to best start

[troica]

Thanks. I wanted to do generate a log file using HM model that takes the difference in the SNR, quantization parameter etc per frame, ctu, and slice number. Is there such a thing, or should I code manually to do such thing?

[Boulder]

Now, I'll admit that tunegrain could still undergo some tweaks for speed, and others have suggested the parameters to do that. Myself, I couldn't be happier about ditching the pursuit of endless quality experiments with this-command-line and that-command-line.

This. What I've done is choose --preset slower --tune grain --CRF 21 as the baseline, then picked some recommended settings to tune performance (--limit-refs 3 --limit-tu 3 --rskip) and some quality-related ones from the bottom two presets (--tu-inter-depth 4 --tu-intra-depth 4 --max-merge 4). Produces 10-30% smaller files than x264 with my preferred settings at CRF 18, and seems to keep detail better.

[pingfr]

merange 92 is insanely high. What is the video resolution?

1920x1080.

[pingfr]

I would add
--rskip --no-sao --no-open-gop
and I prefer
--psy-rdoq 1.1

I suppose --rskip stands for the "recursion skip", however both veryslow and placebo presets have the value set at 0. I suppose that means they are kind of --no-rskip?

Also I would assume --no-sao disables SAO setting it to 0, whereas every preset excepted for ultrafast and superfast have the value set to 1, makes me to actually WANT the SAO.

Now can some kind soul explain what is the rdoq-level? why is it set at 2 and how to make sure to keep it set at 2 from the command line args?

Thanks.

[microchip8]

@pingfr

you don't want SAO. It blurs things so if you want to preserve detail as much as possible, disable it and disable strong-intra-smoothing as well

[pingfr]

@froggy1: Noted. Any idea why the "best presets" have it enabled then?

[microchip8]

@froggy1: Noted. Any idea why the "best presets" have it enabled then?

The presets of x265 are optimized for (very) low bitrate where at those levels, blur is preferred over other compression artifacts. That's why most have SAO and intra smoothing enabled. Also the x265 presets haven't been optimized in a long time. If you want to squeeze out as much detail as possible, you'll need to tweak manually (IMHO)

[pingfr]

The presets of x265 are optimized for (very) low bitrate where at those levels, blur is preferred over other compression artifacts.

That's not my case here, quite the contrary, I'm trying to optimize for top-notch quality at a 10%~15% size/compression efficiency over x264, bitrate isn't an issue and never will be.

That's why most have SAO and intra smoothing enabled.

Gotcha.

Also the x265 presets haven't been optimized in a long time.

Not really helpful now is it?

If you want to squeeze out as much detail as possible, you'll need to tweak manually (IMHO)

That's exactly what I'm doing as we speak.

Speaking of quality or should we rather call it "detail retention", I see everyone coming up with different custom deblocking values.

Some are like -1:-1 where as others recommend as far as -6:-6, is there a "best" and a "safe" value? or when is actually too much deblocking... well... "too much"?

My latest test settings are:

x265.exe --crf 21 --aq-mode 1 --ctu 64 --qg-size 32 --deblock -6:-6 --me star --bframes 8 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 92 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 0 --limit-modes --tskip --rect --amp --max-merge 5 --subme 7 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing in.y4m -o out.hevc

[microchip8]

your line looks good, except for the, IMHO, too high merange value. Even for UHD, that's overkill. As to deblocking, there's no magic value and different people prefer different values. I'm fine with -3 and even -2. also, if you're mostly encoding HD/FHD, a CTU of 32 is slightly preferred

[pingfr]

your line looks good, except for the, IMHO, too high merange value. Even for UHD, that's overkill.

Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?

As to deblocking, there's no magic value and different people prefer different values. I'm fine with -3 and even -2.

If you were asked to justify your choices of a -3 or -2 values, how would you do so? :)

also, if you're mostly encoding HD/FHD, a CTU of 32 is slightly preferred

I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.

Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.

[microchip8]

Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?

it will have a slight impact on speed. As to quality, it will be difficult to spot the difference, unless you really "stick your nose" into the picture with a microscope.

The reason I said that 97 is overkill is because with that value, the encoder may select a motion vector that's not necessarily the best one. It is a similar situation with x264 where values above 32 can actually in some cases hurt quality instead of improving it.



If you were asked to justify your choices of a -3 or -2 values, how would you do so? :)


Simply, I prefer a slightly "soft" picture instead of one that jumps at me



I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.


Keep in mind that the presets, as I said, are optimized for 2 things. One I already mentioned (very low bitrates) while the other is at least UHD resolutions. At these resolutions, a larger CTU makes sense


Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.

I don't think it has one yet

[ChaosKing]

Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?


You can always test it yourself with a short sample and compare the results...

Yes the filesize will be a little bit smaller or the quality a little bit better, but it will be so small that it's not really worth it. That's why it is in the placebo preset, bcs it's sloooow ;)

[aymanalz]

1920x1080.

Then I repeat, merange of 92 is insanely high. Even the default of 57 is very high.

[aymanalz]

Will lowering the --merange 92 back to a saner --merange 57 value have any significant impacts on either resulting quality (better/worse looking?) and/or compression speed (faster/slower?) and/or compression efficiency (bigger/smaller filesize?)?



If you were asked to justify your choices of a -3 or -2 values, how would you do so? :)



I'm tackling with 1080p/720p encodes from Blu-Ray disc sources at the moment, however it appears all the presets recommend using a --ctu 64. I think I'll stick to that at least for now.

Edit: Also I can't find the command line switch to set a custom lookahead-slices arg.


1) Lowering the merange to 57 will significantly boost your encoding speed, and it is very unlikely (read, impossible) that you will notice any quality degradation.

2) CTU of 32 is good enough for 1080p, and that too will give you significant speed increase. Only much higher resolutions will benefit from CTU 64.

A couple of pages back, you were complaining about slow encoding speed, so I'm wondering why you would set these unhelpfully large values for merange especially, and CTU.

[littlepox]

--ssim-rd seems to be another detail killer. May I know how to use it in near-transparent encoding?

[pingfr]

Then I repeat, merange of 92 is insanely high. Even the default of 57 is very high.

Back to 57 then I guess. Thanks! ;)

[pingfr]

1) Lowering the merange to 57 will significantly boost your encoding speed, and it is very unlikely (read, impossible) that you will notice any quality degradation.

57 it is then. Case settled.

2160p = 92 merange.
1080p = 57 merange.
720p = ?? merange.

2) CTU of 32 is good enough for 1080p, and that too will give you significant speed increase. Only much higher resolutions will benefit from CTU 64.

2160p = CTU 64.
1080p = CTU 32.
720p = CTU ??.

A couple of pages back, you were complaining about slow encoding speed, so I'm wondering why you would set these unhelpfully large values for merange especially, and CTU.

Because... these values were the ones taken directly from the placebo presets? :D

[LigH]

But "placebo" means "you have to believe in it to see any advantage over sensible presets". Or in other words: Rather a waste of time and energy than a visible advantage.

[sneaker_ger]

Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...

[pingfr]

Even 57 is probably overkill for 1080p. x264 preset placebo uses 24...

Isn't comparing x264 and x265 values more or less equals comparing oranges to eggs? :)

[aymanalz]

Because... these values were the ones taken directly from the placebo presets? :D

There is a reason they call it placebo! :D

Placebo: Anything of no direct benefit which nevertheless makes people feel better or benefit psychologically.

[Boulder]

I did a small test concerning CTU 64 and 32. The source was a short scene from the first The Hobbit movie, mattes cropped and scaled down to 1280x544 with some sharpening to compensate and then very light denoising. This is what I mostly do to the material that I put on my media server.

With my default settings, which also means CTU 64, the bitrate was 3983.05 kbps and average speed 2.38 fps. With CTU 32, the bitrate was 4092.48 kbps and the average speed 2.76 fps.

I really didn't expect the bitrate to change that much at such a low resolution but it's there. The scene itself is fairly detailed, but there's also some sky etc. which could give the 64-pixel CTU something to work on.

[pingfr]

Latest changes:

Increased --crf 18 to --crf 21.
Lowered --ctu 64 to --ctu 32.
Lowered --bframes 8 to --bframes 4.
Lowered --merange 92 to --merange 57.
Lowered --rd 6 to --rd 4.
Lowered --subme 7 to --subme 5.

I'm getting an average of 1.16 fps, my current goal is 2.00 fps.

The remaining values that are untouched are:

--qg-size 32
--deblock -6:-6
--rc-lookahead 60
--tu-intra-depth 4
--tu-inter-depth 4
--scenecut 40
--limit-ref 0
--limit-modes
--max-merge 5

Anything else I could tweak at this point to increase crunching speed without hurting either the efficiency or the quality resulted?

[Boulder]

--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.

[pingfr]

--tu-intra-depth 3
--tu-inter-depth 3
--limit-refs 3
--max-merge 3

You won't see a visible difference but the encoding will go faster.

Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.

[aymanalz]

Tested the suggested values, while it is true it encoded much faster at 2.48 fps and even exceeded my expectations, the water ripples from my sample clip were blocky. That's a no-go for me.

Thanks.


Try just the limit refs 3.

And if blocking is the only issue you saw, increase the deblocking to -3,-3 or higher. Lowering deblocking by so much from default values, probably causes...blocking.

[pingfr]

Try just the limit refs 3.

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -6:-6 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing %1 -o %~n1.hevc

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 tskip signhide tmvp
x265 [info]: tools: b-intra lslices=6 deblock(tC=-6:B=-6)
x265 [info]: frame I: 3, Avg QP:22.55 kb/s: 28882.40
x265 [info]: frame P: 141, Avg QP:23.75 kb/s: 19361.90
x265 [info]: frame B: 456, Avg QP:28.24 kb/s: 6027.66
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 80.6% 18.8%

encoded 600 frames in 276.47s (2.17 fps), 9275.48 kb/s, Avg QP:27.15

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 20s 0ms
Bit rate : 9 097 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.146
Stream size : 21.7 MiB (98%)
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-6:-6 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt
Default : Yes
Forced : No

Hard to tell.

[darksiderg]

i m using x265 2.3+1-7e225ae stable version. during 720p encode i noticed that my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

[pingfr]

Try just the limit refs 3.

And if blocking is the only issue you saw, increase the deblocking to -3,-3 or higher. Lowering deblocking by so much from default values, probably causes...blocking.

Trying now with a -3,-3. Will return in a bit with the results.

[Boulder]

Try just the limit refs 3.Or leave the settings as they are and try --rskip. I could never tell if it was better on or off, but encoding is much faster enabled. It will probably increase the bitrate though.

[pingfr]

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -3:-3 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing %1 -o %~n1.hevc

x265 [info]: HEVC encoder version 2.3+9-820f4327ddac
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=2.00 tskip signhide tmvp
x265 [info]: tools: b-intra lslices=6 deblock(tC=-3:B=-3)
x265 [info]: frame I: 3, Avg QP:22.55 kb/s: 28882.40
x265 [info]: frame P: 141, Avg QP:23.75 kb/s: 19287.13
x265 [info]: frame B: 456, Avg QP:28.23 kb/s: 6014.92
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 80.6% 18.8%

encoded 600 frames in 264.24s (2.27 fps), 9248.22 kb/s, Avg QP:27.15

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 20s 0ms
Bit rate : 9 071 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.146
Stream size : 21.6 MiB (98%)
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt
Default : Yes
Forced : No

Gained a speed increase of 0.10 fps, resulted file 60KB smaller and saw no differences, these nasty blocks in the water are still there.

Should I try with a -1:-1 deblocking value?

[Boulder]

Try the suggestions one by one and see which one causes the issue.

[pingfr]

Try the suggestions one by one and see which one causes the issue.

It's hard to tell, these "blocks" might as well be present on the source used, but it's in .y4m format I have no software that can open these at all other than x265 itself.

Source is YachtRide from here:

http://ultravideo.cs.tut.fi/#testsequences

[Boulder]

You could encode as lossless and use that to check the frames.

[darksiderg]

i m using x265 2.3+1-7e225ae stable version. during 720p encode i noticed that my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

[pingfr]

You could encode as lossless and use that to check the frames.

Lossless? is there like a --preset lossless? :)

[sneaker_ger]

--lossless

But there are players that can play .y4m, e.g. MPC-HC + LAV.

[pingfr]

@sneaker_ger: MPC-HC is a clear no-go for me.

https://drdump.com/UploadedReport.aspx?DumpID=13569359&SecondVisit=1

[divxmaster]

Lossless? is there like a --preset lossless? :)

yes, great for comparisons, I create a --lossless sample and a --crf16 sample and compare to the rip I am doing at the time.
Lol, your command line a few posts back is now virtually identical to mine. I use a slightly lower --merange for 1080p
and --aq-mode 2, but apart from that, it is the same.
Also for *some* ultra clean sources, even crf 22 suffices, and is virtually indistinguishable to the crf16 comparison, and not distinguishable at normal viewing distances (48 inch screen, 102 inch screen)

:)

Divxmaster

[aymanalz]

@sneaker_ger: MPC-HC is a clear no-go for me.

https://drdump.com/UploadedReport.aspx?DumpID=13569359&SecondVisit=1

BTW, is there a reason you are not encoding at 10 bits? That improves quality, although it might slow down the encode.

[LigH]

... my cpu usage was fluctuating from 40% to 80% vice versa. but it never reached 100. i used slow preset. is it normal?

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

[pingfr]

Lol, your command line a few posts back is now virtually identical to mine. I use a slightly lower --merange for 1080p and --aq-mode 2, but apart from that, it is the same.

What would be the benefits of switching to -aq 2?

:)

[pingfr]

BTW, is there a reason you are not encoding at 10 bits? That improves quality, although it might slow down the encode.

Backwards compatibility with "exotic" devices. :)

[divxmaster]

What would be the benefits of switching to -aq 2?

:)

well primarily better quality. Although I haven't tried --aq 1 in recent versions of x265.
Ah, I see you do 8 bit encodes. I only do 10 bit encodes, but I see you use decoding hw that requires 8 bit.

Also, add --no-open-gop, or you *may* have seeking issues.

Cheers,
Divxmaster

[darksiderg]

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

thanks :)

[aymanalz]

Quite normal, yes. The HEVC algorithm as such has only a limited parallelizability. Parts of the encoding need to wait for other parts to finish first. This has been discussed many times before.

This may be true for CPUs with many cores, but four normal 2 or 4 core processors, I think x265 should saturate all the cores. Especially at the "slow" preset, which is what he is using.

IIRC, the previous discussions were about 12/16 cores, or multiple CPUs not being fully utilized.

@darksiderg : What CPU are you using?

[benwaggoner]

What would be the benefits of switching to -aq 2?

AQ 2 will decrease QP (increasing quality) in dark regions. This increases bitrate some, but helps the blocking-in-black issues, particularly on LCD displays will elevated blacks.

Note only for use with SDR gamma content. It's not appropriate for HDR PQ content, which has many more code values in dark, better matching human perception.

[pingfr]

This increases bitrate some.

--aq 1:

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.43 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

--aq 2:

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 4.77 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

TL;DR:

--aq 1: 2.43 MiB
--aq 2: 4.77 MiB

That's an almost 100% file size increase, what the flux? :eek:

[Barough]

x265 v2.3+17-6e348252e902 (http://ge.tt/4bua44j2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+17-6e348252e902
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.3+17-6e348252e902 (https://www.mediafire.com/file/hipmkgfb61m7y0c/x265_2.3%2B17-6e348252e902.7z)

Now even finer!

--refine-level <1..10> Level of analyis refinement indicates amount of info stored/reused in save/load mode, 1:least....10:most. Default 5

^typo (analy»s«is) already reported...

Not available anymore:

--capture-csp <string> Specify color primaries from bt709, p3d65, bt2020 for the capture device. Default bt709

[benwaggoner]

TL;DR:

--aq 1: 2.43 MiB
--aq 2: 4.77 MiB

That's an almost 100% file size increase, what the flux? :eek:
Sorry, I was talking about aq-mode 2 versus 3.

CRF values aren't going to be particularly consistent across aq-modes, and you can (with a bucket full of caveats) generally raise CRF with more advanced AQ at similar subjective quality.

[Dclose]

Speaking of quality or should we rather call it "detail retention", I see everyone coming up with different custom deblocking values.

Some are like -1:-1 where as others recommend as far as -6:-6, is there a "best" and a "safe" value? or when is actually too much deblocking... well... "too much"?
There definitely can be too much deblocking. Set both to +6 and it can be like putting vaseline on the picture.

That's at low bitrate though. At high bitrate it probably doesn't use it much so it probably doesn't matter much.

Messing with different settings comes into play more with CQs in the mid-20s and higher. When people use CQ of like 18 or less, that has a lot bigger margin of error.

There is a reason they call it placebo! :D

Placebo: Anything of no direct benefit which nevertheless makes people feel better or benefit psychologically.
Placebo on x264 is noticeable to me. I'm guessing the main reason is the sub-pixel precision goes to 11.

I haven't tested Placebo on x265 since the other presets didn't seem overly tuned anyway, (as numerous people have criticized in the past).

CRF values aren't going to be particularly consistent across aq-modes, and you can (with a bucket full of caveats) generally raise CRF with more advanced AQ at similar subjective quality.
I was doing some tests on that recently, and AQ1 at CQ 21 was very close in size to CQ 22.5 AQ2 on those files. AQ3 adds so much bitrate it seems to have a mind of its own so I stopped trying.

I've been doing A LOT of grain tests with psyrdo and things, and AQ1 seems just plain more consistent. (As expected, I guess.) It's harder to get consistent texture/grain/quality on people's faces etc with AQ2. On a face close-up when someone's talking, the mouth and cheeks have a lot of different color and depth and detail going on, and it's easy to make them look all sorts of wrong.

[brumsky]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...

http://screenshotcomparison.com/comparison/202364

My settings are below which I pulled from MediaInfo.

cpuid=1173503 / frame-threads=6 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=1470 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=5 / rc-lookahead=40 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=3 / rdoq-level=2 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=2 / limit-modes / me=3 / subme=3 / merange=26 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=2.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / no-hdr / no-hdr-opt / Capture-colorprim=3

A side from the coloring I've tried to improve pic quality without just throwing more bits at it. I've tried dozens of tweaks rd, max merge, ref, rect, amp, aq mode, limit-tu, et cetera.

Even when I increase the CRF from 21 -> 20 or even 19, it doesn't improve much...

Thanks in advance!

[pingfr]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...

http://screenshotcomparison.com/comparison/202364



While I must admit I don't have a solution to your color issue... I must say the loss of details specially on his shoulders is astoundingly awfully bad.

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.

The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

[brumsky]

The only proper way to retain detail is to use --tune grain. That's just the way it is :)

I'll give it a try! :)

[LoRd_MuldeR]

Discussion about Ryzen has been split into a separate thread:
https://forum.doom9.org/showthread.php?t=174383

[Jawed]

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...
I remember when I looked at the encodes/screenies from:

https://forum.doom9.org/showpost.php?p=1781745&postcount=4275

The Y, U and V planes all showed very small "errors" (typically "1"). The error varies from frame to frame, too.

I did some experiments of my own and also compared with x264. I discovered that these errors are "normal". x264 does the same. You have to use very high quality settings (CRF 16 or better, if I remember right) to eliminate these shifts.

I can't remember, but I think B frames also contribute.

I decided: "life's too short".

[amayra]

i have notified my encoding speed decrease for no apparent reason with same some settings after i updated to 2.3.17
Is there any reason for that ?

[brumsky]

I remember when I looked at the encodes/screenies from:

https://forum.doom9.org/showpost.php?p=1781745&postcount=4275

The Y, U and V planes all showed very small "errors" (typically "1"). The error varies from frame to frame, too.

I did some experiments of my own and also compared with x264. I discovered that these errors are "normal". x264 does the same. You have to use very high quality settings (CRF 16 or better, if I remember right) to eliminate these shifts.

I can't remember, but I think B frames also contribute.

I decided: "life's too short".

Ok thanks good to know. I agree, life's too short. ;)

[WhatZit]

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.

The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

Already done as of 13th July 2016!: http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0 and http://x265.readthedocs.io/en/default/presets.html#tunings

Maybe if MulticoreWare renamed "--tune grain" to "--tune quality", and dumbed-down the manual's explanation of its unique (as in, if you don't use it, you don't get it) rate control and frequency biasing algorithms, more people striving for quality would stop second-guessing the developers over preset construction and start building useful command lines around "--tune quality".

So far, the only other person I've seen here who "gets it", is Boulder, and kudos to him for that!

[pingfr]

Already done as of 13th July 2016!: http://x265.readthedocs.io/en/default/releasenotes.html#version-2-0 and http://x265.readthedocs.io/en/default/presets.html#tunings

Maybe if MulticoreWare renamed "--tune grain" to "--tune quality", and dumbed-down the manual's explanation of its unique (as in, if you don't use it, you don't get it) rate control and frequency biasing algorithms, more people striving for quality would stop second-guessing the developers over preset construction and start building useful command lines around "--tune quality".

So far, the only other person I've seen here who "gets it", is Boulder, and kudos to him for that!

Really? Like... really??? Okay, I'll bite the bullet.

Let's see what we have here:

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -1:-1 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 2.43 MiB
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+9-820f4327ddac:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 / tu-intra-depth=3 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt

File-size: 2.44MB.

Now let's try the same command line but let's add the --tune grain switch shall we?

x265.exe --crf 21 --aq-mode 1 --ctu 32 --qg-size 32 --deblock -3:-3 --me star --bframes 4 --rc-lookahead 60 --ref 5 --b-adapt 2 --tu-intra-depth 4 --tu-inter-depth 4 --merange 57 --weightp --weightb --scenecut 40 --rd 4 --limit-ref 3 --limit-modes --tskip --rect --amp --max-merge 5 --subme 5 --b-intra --no-rskip --no-sao --no-strong-intra-smoothing --tune grain

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 10.7 MiB
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=3 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

File-size: 10.7MB.

So what do we have here? A 2.44MB file for only 300 encoded frames vs. a ~11MB file encode with the --tune grain? :eek:

I guess I'll stick to not using --tune grain for now and look for optimized cookie-cutter settings until the resulted file size can be shaved off by a good 50% margin with --tune grain.

My 2 cents.

Edit: For what it's worth, the only differences here are 2.3+9 with -1:-1 deblocking values vs. 2.3+17 with -3:-3 deblocking but if you insist I can run the same encodes again with the same revision and the same deblocking values.

[WhatZit]

Now let's try the same command line but let's add the --tune grain switch shall we?

You don't "add" --tune grain to an existing command line.

You replace your entire command line with --tune grain (preset/crf/sharpening tweaks aside). That's because --tune grain does NOT operate with the default algorithms (it's in the manual link I posted)!

And remember, --tune grain is so good at retaining detail that you can drop both CRF & preset back from whatever your reworked preset parameters required previously.

Ultimately, you're going to have to decide what's MOST important to you: speed, size or quality. So far, you're meandering between all of them.

You never even mentioned the quality of the output, only size. Besides, none of us can tell what you think "quality" is, anyway. They're your eyes.

You want a compromise between all three? Grain can do that too, using nothing more than preset & crf.

The very first thing I did when I read "massive improvements to --tune grain" from the press release last year was to encode scenes from 1080p Samsara with:

--preset superfast --crf 28 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing

SUPERFAST 28! What do you think that looked like? You'd be WRONG!

I realised that if --tune grain could help make output that "good" ("not awful" is more accurate) at settings that SHOULD have produced genuinely awful results, then the only way was up.

EDIT: A picture (or two) is worth a thousand words. Go here: http://screenshotcomparison.com/comparison/202693

Yes, that's the 4k Yacht Ride sample from http://ultravideo.cs.tut.fi/#testsequences

I used my exact "low quality" command line from above.

Comparison #1 is the Raw YUV against x265 Superfast CRF28 --tune grain

Comparison #2 is the Raw YUV against x265 Superfast CRF28 without --tune grain (the only change)

If that doesn't demonstrate not only everything I've been saying, but everything the manual has been saying for the past 9 months, then I don't know what else to say, except...

There are effectively TWO x265's: the default one that biases Compression-Over-Quality, and the --tune grain one that biases Quality-Over-Compression. Like it or not, that's the way it is, and the "quality" problem you're complaining about was solved 9 months ago.

[Khun_Doug]

So is it the case, then, that using --tune grain invokes internal code that is not otherwise accessible by using sane and personalized options based on the specific content?

For example: I have a lot SD discs and sets that are not available in HD, and some of those have film from the 70's. In my experiments I have found that I was looking at options such deblock -3:-3, no-sao, and AQ 3. I have no trouble choosing slow or slower, and a CRF of 18. So would it then be the case that by choosing --tune grain I probably wouldn't need to toy with these options, or any of the other myriad of options that are available, because --tune grain uses different routines, not just a different baseline of settings?

[WhatZit]

So is it the case, then, that using --tune grain invokes internal code that is not otherwise accessible by using sane and personalized options based on the specific content?

Yep: http://x265.readthedocs.io/en/default/presets.html#tunings

Basically, grain265 (need a shorthand way of saying it) "thinks" differently than the default regime.

Whether --rc-grain can actually be used outside of the tuning is something I've never experimented with. The developers "highly recommend" against it.

Sure, you can still fiddle with traditional options, but, as a starting point for producing quality encodes, you simply can't go past grain.

[pingfr]

There are effectively TWO x265's: the default one that biases Compression-Over-Quality, and the --tune grain one that biases Quality-Over-Compression. Like it or not, that's the way it is, and the "quality" problem you're complaining about was solved 9 months ago.

x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: grainsuperfast.hevc
x265 [info]: HEVC encoder version 2.3+17-6e348252e902
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=4.00 early-skip signhide tmvp fast-intra
x265 [info]: tools: lslices=6 deblock(tC=-1:B=-1)
x265 [info]: frame I: 3, Avg QP:21.33 kb/s: 28086.08
x265 [info]: frame P: 149, Avg QP:23.05 kb/s: 10469.61
x265 [info]: frame B: 448, Avg QP:23.05 kb/s: 3873.64
x265 [info]: consecutive B-frames: 0.7% 1.3% 0.7% 97.4%

encoded 600 frames in 26.86s (22.33 fps), 5632.71 kb/s, Avg QP:23.04

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 13.4 MiB
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=10 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / no-weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=2 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=600 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=10 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / no-weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=2 / early-skip / no-rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5

13.4MB... no thanks! :eek:

[Khun_Doug]

Then I am inclined to agree that it would have been better named --tune quality, and definitely more emphasis indicating that internal controls for quality are invoked. So now on to a new set of test encodes! :)

[WhatZit]

x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc

13.4MB... no thanks! :eek:

So, it's SIZE you care about, not quality.

Try CRF28.

EDIT: I made a CRF21 version of the YachtRide sample, only changing my "low quality" command line above from --crf 28 to --crf 21:

CRF21 = 26.7Mb
CRF28 = 10.7Mb

The CRF21 version is subjectively 5-10% better quality than the CRF28 version, which is not worth the 250% file size. Or, is it...?

So, yes, you need to rethink how presets & CRF work under grain265.

[pingfr]

So, it's SIZE you care about, not quality.

Not exactly, I am archiving commercial Blu-Ray discs. So quality matters, has to be "on par" with what an encode would be in x264.

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.

While I'm trying not to derail the thread or turn this into a "x264 vs x265" debate, here are the settings of my last x264 1080p encode:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 38mn
Bit rate : 8 072 Kbps
Width : 1 920 pixels
Height : 808 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.217
Stream size : 5.39 GiB (82%)
Writing library : x264 core 148 r2744 b97ae06
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=8072 / 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
Language : English
Default : Yes
Forced : No

As you can see, the bitrate is about 8072 kbits, typical for a 1080p encode.

[LigH]

You cannot judge quality by reading numbers. Only by looking at the video. Just look at it and decide: Is the quality loss negligible? Don't care about bitrates other encoders used with other encoding options. And don't try to find average values; there are too different movies out there. You can probably find one that needs only a tenth of the bitrate of another, and still "looks better".

[WhatZit]

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.

If you have to hit bitrate targets AND maintain quality, then that sounds like a perfect job for ABR!

Here's my old 1080p x265 2-pass batch file, that I used to use for grainy sources:
@Echo Off

If [%1]==[] Goto Usage

REM stats file = .\x265_2pass.log

:Pass_1
Echo =========== PASS 1
Echo.
ffmpeg -i %1 -f yuv4mpegpipe - | x265 --preset medium --bitrate 6500 --pass 1 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.
Echo.

:Pass_n
Goto Pass_2
REM Don't do this!
Echo =========== PASS n
Echo.
ffmpeg -i %1 -f yuv4mpegpipe - | x265 --preset medium --bitrate 6500 --pass 3 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.
Echo.

:Pass_2
Echo =========== PASS 2
Echo.
ffmpeg -i %1 -f yuv4mpegpipe - | x265 --preset medium --bitrate 6500 --pass 2 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.


Goto END

:Usage
Echo USAGE: %0 SOURCE_VIDEO [extra params]
Echo.
Echo Converts the SOURCE_VIDEO file into an x265 2-Pass ABR6500 .hevc stream (for later MKVMerging with original audio)
Echo.

:END

With that, I was able to turn this high-complexity IMAX demo:
General
Unique ID : 185273360177734801790310909616562081404 (0x8B6259E9F86865D08A2BEE3E4BA78E7C)
Format : Matroska
Format version : Version 4 / Version 2
File size : 84.1 MiB
Duration : 30 s 37 ms
Overall bit rate : 23.5 Mb/s
Encoded date : UTC 2016-02-06 15:48:41
Writing application : mkvmerge v8.8.0 ('Wind at my back') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 30 s 42 ms
Width : 1 920 pixels
Height : 1 038 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 142 r2431+42 c69a006 tMod [8-bit@all X86_64]
Encoding settings : cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.85:0.10 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=72 / rc=crf / mbtree=1 / crf=14.0000 / qcomp=0.70 / qpmin=0:0:0 / qpmax=69:69:69 / qpstep=4 / vbv_maxrate=24000 / vbv_bufsize=33000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 / aq-sensitivity=10.00 / aq-factor=1.00:1.00:1.00 / aq2=0 / aq3=0
Language : English
Default : Yes
Forced : No

into this:
General
Unique ID : 235329403967803183918623951386027792481 (0xB10ACB6A3A0256CD96DFD7E451449861)
Format : Matroska
Format version : Version 4 / Version 2
File size : 23.6 MiB
Duration : 30 s 0 ms
Overall bit rate : 6 607 kb/s
Encoded date : UTC 2017-03-07 08:14:21
Writing application : mkvmerge v9.8.0 ('Kuglblids') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 30 s 0 ms
Bit rate : 6 603 kb/s
Width : 1 920 pixels
Height : 1 038 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.138
Stream size : 23.6 MiB (100%)
Writing library : x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1038 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=-6:-6 / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=6500 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5
Language : English
Default : Yes
Forced : No

with the x265 damn-well looking "identical" to the x264, according to me and my eyes. Once again, --tune grain is integral to maintaining quality.

I'll bet you could probably go well below 6000kbps and maintain "transparent" quality quite easily with --preset slow.

Speaking of which, I stopped using ABR because it was too slow, and it used the average bitrate even when it didn't need to. This might change if I ever get myself a Kaby Lake or, dare I say it, Ry--- no, I dare not say it.

NOTE: there are additional --multi-pass* options which improve speed/quality, but I've never investigated them.

[pingfr]

If you have to hit bitrate targets AND maintain quality, then that sounds like a perfect job for ABR!

I'll bet you could probably go well below 6000kbps and maintain "transparent" quality quite easily with --preset slow.

One of the few gripes I always have had with x265 over x264 is that there is no way to really calculate or estimate the following values:

1) What does "equal" 4000kbits for a 720p and 8000kbits for a 1080p in the x264 in the x265 world?

It seems to me that 4000kbits x264 =! 4000kbits x265, likewise for the 8000kits x264 =! 8000kbits x265.

2) The CRF values are "off" as well, in the x264 world whenever I've had to use CRF; a sane value was 17 or 18, but there again a CRF 18 in the x264 world does not equal a CRF value of 18 in the x265 world.

It is clear that CRF 18 x264 =! CRF 18 x265.

If only there was a calculator, a .pdf or .xls or online doc of roughly translations back and forth between both encoders... :(

[LigH]

AVC and HEVC are different algorithms. There is no "equal quality", as long as quality is subjective, and even any kind of measurable difference depends a lot on the video content (because both standards use partially different techniques to spare bitrate). It's like expecting two master painters to paint "the same painting": They will always differ in style, no matter how realistic and exact their results will be.

You will not be able to create a reliable relation without efforts that would rival corporational MMO gold farmers: Hundreds of different movies encoded with dozens of different parameter combinations, and eventually, hundreds of people judging each of these results in ABX tests.

[Boulder]

Some observations from me since I was mentioned :)

Don't set any specific bitrate limits in your mind. The average bitrate is entirely dependent on the source. For example, I just processed the first season of Mr. Robot, and the episodes required very, very few bits at 720p. I'm talking about less than 1 Mbps! Then I processed the first season of The X-Files, and the bitrate almost shot through the roof using almost the same VapourSynth script.

As I've mentioned, I basically use --tune grain --preset slower --no-strong-intra-smoothing --deblock -3:-1 --crf 21 with some added things from slower presets, such as --bframes 10 --ref 5 --tu-inter-depth 4 --tu-intra-depth 4 --max-merge 4 and some speedups like --limit-refs 3 --limit-modes --limit-tu 3 --rskip --merange xx (xx = 38 for 720p, 25 for 480/576p). I have compared --tune grain against my default x264 settings which were based on Level 4.1 @ CRF 18 and found out that x265 will perform better and end up with a lower bitrate. I came up with CRF 21 for x265 after making a series of encodes with varying CRF and comparing still frames to the original one. I found out that CRF 21 is enough to my eyes, CRF 22 was causing things I didn't like in the image.

The difference in bitrate has generally been 10-30%. You should also note that the 10-bit encode with x264 will require less bits than the 8-bit one but with x265 it's the other way around. So the difference in performance is even more substantial. For quality reasons, you should encode at 10 bits unless the devices you use require otherwise. As far as I know, 10-bit HEVC should be HW decoded in many cases already. For what it's worth, my Celeron-based Chromebox has been able to decode 720p HEVC stuff in software as well.

I've criticized x265 heavily in the past for destroying the details, and it is true if you don't use --tune grain. It is a unique setting which is a must for me, otherwise I would still be using x264 for my encodes.

[WhatZit]

If only there was a calculator, a .pdf or .xls or online doc of roughly translations back and forth between both encoders... :(

You will not be able to create a reliable relation without efforts that would rival corporational MMO gold farmers: Hundreds of different movies encoded with dozens of different parameter combinations, and eventually, hundreds of people judging each of these results in ABX tests.

Which is exactly why this (https://forum.doom9.org/showthread.php?t=170236) thread from 3 years ago fizzled out.

Plus, everyone simply got used to the idea of x265 being a totally different kettle of fish than x264.

[LigH]

OK, not "totally" :o ... but already different enough in different resolutions due to different Coding Unit sizes and partitions, etc. Hard to simplify without a lot of constraints.

[aymanalz]

Is this a universal opinion here, that for quality, you need "tune grain"? For all sources, including non-grainy ones?

[Boulder]

Quality is in the eye of the beholder :) --tune grain is the only one biased toward keeping detail - and detail in this context is "real" detail, grain, noise etc. Some people prefer a clean image for which --tune grain is probably not a perfect choice.

[LigH]

Maybe less "opinion", rather "experience"? :o ... HEVC usually has a habit of rather blurring the material than revealing artifacts, which is often more appreciated by the people when the bitrate supply is not that generous, and has a different impact in UHD resolutions. I could imagine that you may enjoy the default behaviour as well for cartoons or computer generated movies which are very clean per se, or get an advantage from cleaning out low-detail areas. After all, there is also a matter of taste involved... :rolleyes:

[sneaker_ger]

I have seen --tune grain produce bad effects in the past. It can hurt quality. It's not something I would blindly use for all sources.

https://forum.doom9.org/showthread.php?p=1762253#post1762253 ff

[Boulder]

That's almost a year-old thing. Has anyone made a new test since x265 has developed quite a bit since then?

[pingfr]

This is an endless charade in my opinion.

No disrespect but... one of the main developers (and I said a dev, not a PR person or a salesman) from MulticoreWave needs to step up for once and all and thoroughly explain us the full logic/philosophy along with the benefits and drawbacks of using specific --presets linked with specific --tuning parameters and how they all interact with each other.

It is no genius the average x265 user wants one thing: retain maximum subjective quality at the smallest achievable resulting file-size (at the cost of encoding time and CPU cycles), according to wikipedia, the initial x265 release was 4 years ago and despite the fact it is undeniable we've come a long way and made a lot of progress and improvements since commit 09fe406 on the 2013/03/07 there is IMHO (and with a grain of salt) still progress to do in that field.

[CruNcher]

Maybe less "opinion", rather "experience"? :o ... HEVC usually has a habit of rather blurring the material than revealing artifacts, which is often more appreciated by the people when the bitrate supply is not that generous, and has a different impact in UHD resolutions. I could imagine that you may enjoy the default behaviour as well for cartoons or computer generated movies which are very clean per se, or get an advantage from cleaning out low-detail areas. After all, there is also a matter of taste involved... :rolleyes:

Could you see SAO amplifying the blurring ?

[Zebulon84]

Not exactly, I am archiving commercial Blu-Ray discs. So quality matters, has to be "on par" with what an encode would be in x264.

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.


x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc
[...]

encoded 600 frames in 26.86s (22.33 fps), 5632.71 kb/s, Avg QP:23.04
[...]
Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
[...]

13.4MB... no thanks! :eek:

If x265 --crf 21 --tune grain gives you 30% smaller file than your usual x264 encodes, why do you reject it without any comment on the quality, just the file size ?

[pingfr]

If x265 --crf 21 --tune grain gives you 30% smaller file than your usual x264 encodes, why do you reject it without any comment on the quality, just the file size ?

Because I don't have a technical way to judge/assess/comment the quality with any other tools than my "bare eyes"?

And because my complicated encode string without --tune grain yields an encode that is 5 times smaller as a comparison point?

2MB file vs. 13MB file.

[Rinzler0x7BB]

Is this a universal opinion here, that for quality, you need "tune grain"? For all sources, including non-grainy ones?

No, I made a different experience. I encoded a low noise source one time with "tune grain" and one time with "--pbratio 1.2 --psy-rd 2.4 --psy-rdoq 5.0 --rdoq-level 2".
The "tune grain"-version had less details and was also a little bigger.

Tune grain does disable aq and cu-tree. This is one reason the resulting file is typically significantly bigger.

Parameters I used with tune grain:
--crf 20 --profile main10 --output-depth 10 --ctu 32 --tune grain --qcomp 0.65 --rc-lookahead 30 --no-sao --level-idc 4.1 --high-tier --rd 4 --bframes 8
--no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

Parameters I used without tune grain:
--crf 20 --profile main10 --output-depth 10 --ctu 32 --pbratio 1.21 --aq-mode 3 --aq-strength 0.8 --qcomp 0.65 --psy-rd 2.4 --psy-rdoq 5.0 --rdoq-level 2
--rc-lookahead 30 --no-sao --level-idc 4.1 --high-tier --rd 4 --bframes 8 --no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

It is always a tradeoff in quality, speed and encoding efficiency. For me all three are important. And everyone needs to find his suitable settings. I like tune grain as it produces are more constant quality also in high motion. But as the size is important for me too I needed to find settings with a better encoding efficiency. So I ended up in the settings above without tune grain.

[LoRd_MuldeR]

If you compare quality of files with different size (i.e. different average bitrate), you are comparing apples and oranges. Such comparison would inherently be biased.

Also, the same CRF value gives the same quality, roughly, for different sources, provided that no other options are changed. Changing other options, such as the "tuning" option, changes the meaning of CRF values!

There is no reason to assume that a specific CRF value still produces the same quality with "tune grain" that it did with "default" settings, or any other particular settings. And, therefore, comparing file sizes this way is not meaningful.

Conclusion:
- If you want to compare quality in a "fair" meaningful way, you have to compare files of identical size, i.e. identical average bitrate. This is most easily achieved by using 2-Pass mode.
- If you want to compare file size (i.e. average bitrate) in a "fair" meaningful way, you have to compare files of identical quality. This can be achieved by adjusting CRF value of each file until the "perceived" quality matches.

The latter clearly is much more difficult to achieved, which is why you probably want to do the former.

Also be sure that the average bitrate chosen for a quality comparison isn't too high. If the bitrate is chosen too high, then both files will look flawless and thus the (not very helpful) conclusion will be that there is no difference...

(And, of course, choosing the average bitrate too low is deceptive too. If both files look like a mess you don't learn much either)

[nevcairiel]

retain maximum subjective quality at the smallest achievable resulting file-size (at the cost of encoding time and CPU cycles)

Clearly that is every video codecs target. Best quality at smallest file size. The question is what do you favor, size? quality? And to what degree? Only one answer to those questions can be the "default" behavior, which apparently for x265 seems to favor size more then absolute quality.

The presets mostly influence the speed/quality trade-off, so that leaves the size/quality ratio up to the remaining settings. Primarly thats of course the bitrate/crf, but a lot of other options on top, which many people coming from x264 are likely not used to, since it had different defaults that favored keeping more quality by default.

Looking at what options tune grain modifies can be a good starting point, and some additional tune's or better documentation could definitely help - but its certainly something we as the community could easily create, a set of settings that generally keep more quality, but not focused on grain directly.
The presets and tune parameters are not "magic", they just modify a fixed set of the options you could also manually modify, and you can just look those up in the sources if the documentation doesn't list them.

I'm not sure anyone here on doom9 can really speak for an "average" x265 user without knowing anything about the userbase of x265 outside of this forum, however.

[Zebulon84]

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.
The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

[elahn]

its certainly something we as the community could easily create, a set of settings that generally keep more quality, but not focused on grain directly.

I would love that! I struggle to understand many of the parameters and I feel like it'll be a long time over many sources before I do, if ever.

[Majorlag]

elahn,
I would look over at http://x265.readthedocs.io/en/default/cli.html and read up on what each option does. This is where I went back to, through many iterations of encodes. I found that there is nothing like trial and error to see what options are worth enabling and others disabling.

The defaults are generally set for a reason, to give an all around acceptable quality for the time it takes to encode at the users desired bitrate. Use a short 24 minute episode to try different settings. Too short of a clip will not show some fine tuning. and long clips will be forever to decide if things like that --preset plecebo was worth it.

Don't get caught up in the chasing options forever and enabling or changing everything, presets are there for a reason, then apply small changes for your needs.

~Majorlag

[LigH]

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

a) That would be off-topic here.

b) They all are HEVC encoders, so they all behave in a similar way, and none does miracles. Bitrate is usually spared by decisions which details can be reduced with little annoyance. Such decisions can be more or less appropriate, depending on both the video material and the person looking at it.

[benwaggoner]

Quality is in the eye of the beholder :) --tune grain is the only one biased toward keeping detail - and detail in this context is "real" detail, grain, noise etc. Some people prefer a clean image for which --tune grain is probably not a perfect choice.
Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

[pingfr]

Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

Not to throw oil on the fire but... finally someone who has a clue and common sense!

--tune grain is for grainy content as the name implies... duh!

--tune grain is not, never was and never will be a "cookie cutter all-around" parameter to always consider when doing encodes. It is not the "always 100% right" solution as others have wrongly implied in the past 3 pages of this thread.

[Boulder]

For what it's worth, the encoder cannot tell grain from actual detail or noise. What we --tune grain users have been saying is that the tuning tends to bias towards keeping things as they are in the source; be it grain, detail or noise. It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

As always, everything depends on what you personally seek - you must test things yourself and then use whatever looks best to your eyes. We are only spoon-feeding you options to test.

EDIT: Earlier I posted some sample screenshots here: https://forum.doom9.org/showthread.php?p=1734222#post1734222 when I compared x264 and "non-tune-grain" settings of x265 more. I have made short tests after that with more recent builds of x265 every now and then, but the problem of vanishing details is still there unless I use --tune grain.

[pingfr]

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

[Boulder]

As I mentioned earlier, my encodes with x265 have generally been 10-30% smaller than the ones with x264 with at least similar visual (subjective) quality.

[WhatZit]

--tune grain is for grainy content as the name implies... duh!

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

[LoRd_MuldeR]

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

You need to keep in mind that you have a limited bit budget. And, therefore, any bits you spent for one thing will be missing for something else.

Consequently, the more bits you spend on retaining "more high frequency components", the less bits will be available for the lower frequency components, of course. It's all a trade-off!

At high enough target bitrate that may be okay, but at medium to lower bitrates it can definitely cause problems.

Surely, you can just crank up the bitrate when using "tune grain" - which in CRF mode happens kind of "automatically" - but then again you end up with files of different size (i.e. different average bitrate).

If the file with "tune grain" is allowed to use more bits than the file with "default" settings (without "tune grain"), then any quality comparison of those files will inherently be biased/unfair.

[WhatZit]

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

Wait a minute... wasn't it YOU who said THIS: (https://forum.doom9.org/showthread.php?p=1798758#post1798758)

I'm trying to optimize for top-notch quality at a 10%~15% size/compression efficiency over x264, bitrate isn't an issue and never will be.

Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

[aymanalz]

Wait a minute... wasn't it YOU who said THIS: (https://forum.doom9.org/showthread.php?p=1798758#post1798758)



Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

You don't want to be throwing accusations of trolling etc, when you are solely responsible for the confusion and misinformation over the last two pages. It was your suggestion that "tune grain" should be renamed to "tune quality", with the implication that it is a universal silver bullet for quality. I specifically had to ask everybody else's opinion becaue of your statement, and clearly, the consensus is that "tune grain" is best used for grainy or other noisy sources.

The point of the codec is to get maximum quality at lower bitrates than previous gen codecs. For maximum quality per bitrate, tune grain is suboptimal for non grainy or non noisy sources. As the name implies, it is meant to preserve detail (grain, noise) in grainy sources.

[aymanalz]

Do I have a different interpretation of this section of the manual than everyone else?


To begin with, you have a different interpretation of the name itself than everybody else. "Tune grain" means precisely that - a preset to retain grain in grainy sources. That is why the developers named it so, instead of as "tune quality", as you suggested.

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.


Nope. High frequency = grain. That's a grain algorithm. Or more generally, to spend more bits on high frequency components alone. Which works well to retain grain, but not other kinds of detail.


EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

If you want to compare quality, do so at the same bitrate/filesize.

[LigH]

Nope. High frequency = grain.

Not exclusively. High frequencies are also useful for more or less regular patterns, as well as sharp edges.

That's the main problem of "noise filters": They can't "see" whether an area contains desired structure or undesired noise.

[pingfr]

They can't "see" whether an area contains desired structure or undesired noise.

Clearly not an expert on the subject but isn't what chroma and luma analysis per "area" of a given frame are for?

I mean they could be used to help the encoder "see" whether an area is a background with less details where less details/less bitrate can be spent over a foreground area where details/higher grain retention is more crucial because that's the area of the frame our eyes are focused on?

[WhatZit]

High frequency = grain.

You know what ELSE is high frequency?

Hair, textiles, vegetation, dirt, architecture, fur, water, eyelashes, fences, cobblestones, cliff-faces, bulletholes, control panels, spoked wheels, wood... basically, anything which needs to be represented by hard edges.

Now, what would you call those picture elements? I'd call them detail.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

In fact, you wouldn't see the same quality improvement with a simple application of more bits, because the default x265 removes detail even at low CRF's. You'd have to manipulate a dozen or more options to even come close to the single --tune grain option, or ABR it.

That was the purpose of the demonstration, in fact that's all I'm going on about: to show how one single option can produce output that is the same quality (subjectively) as 20 individually specified options. Yes, different sizes because different regimes. But I don't starve my encodes of bits, so I never run into any "suboptimal" situations.

I've used --tune grain ubiquitously for 100's of encodes in the last 9 months. It never leaves the command line. A year ago, my x265 options stretched for 3 lines! Some people think that makes themselves an elite special snowflake. To me, it was annoying to maintain.

Now, I only vary the preset & crf as required for light, dark, high-motion, high-detail, grainy, clean or any other type of content you care to name, because I have the experience to know what to use. For me, it DOES work as a quality silver bullet, probably because I never starve my encodes of bits. Quality is number one.

Naturally, if you simply don't like it, don't use it. If quality is also not number one for you, definitely don't use it.

[pingfr]

Some people think that makes themselves an elite special snowflake.

Uuuuhhhhh... okay? :mad:

[Romario]

Can someone, please, tell me how can I retain details in 720p and 1080p encodes, bitrate around 1000 for 720p and about 1650 for 1080p

Gesendet von meinem GT-I9295 mit Tapatalk

[LigH]

bitrate around 1000 for 720p and about 1650 for 1080p

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).

[Romario]

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).
No, you don't understand me good. I meant which encoding settings are best, slowest preset or custom insane settings?

I want as much detail as possible at these bitrate.

Yes, it's landscape. And one or two talk shows.

Gesendet von meinem GT-I9295 mit Tapatalk

[pingfr]

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.

[LigH]

I can only agree: For optimal detail retention, enough bitrate is the most important detail. You seem to have missed the last 2 pages of this thread, it just mentioned "--tune grain" shifting the weight towards higher frequencies, but away from the lower frequencies which are more important for the overall image.

"Insane" is never good. And "placebo" requires you to believe in its advantage. "Enough bitrate" is the only universal active ingredient. You will know the analogy to cars: No spoiler will substitute more cylinder capacity.

[Romario]

Ok I understand that, but I don't want too big files for my encodes. That's unacceptable for me.

I don't know how is fine tune working. I have bought x265 encoder and decoder directly from x265 site, with gui.

Can you please explain me better what I need to know?

I make always two pass encodes, of course.

I also plan, on sumer, to buy Ryzen 1800x and to overclock him on 4.2 Ghz.

Gesendet von meinem GT-I9295 mit Tapatalk

[WhatZit]

I want as much detail as possible at these bitrate.

As has been pointed out, your target bitrates are extremely limited.

BUT... just to prove a point, I have exactly the solution you want.

Copy the batch file from this post: https://forum.doom9.org/showthread.php?p=1799950#post1799950

Replace all instances of "--bitrate 6500" with "--bitrate 1650", and all instances of "--preset medium" to "--preset slow".

Run your files through it (this will take quite a while), and mux the audio with MKVMerge.

I was able to turn a 23500kbps source into a 1694kbps quite watchable encode. I wouldn't say its good, but here's a juicy screenshot comparison for you to decide for yourself:

http://screenshotcomparison.com/comparison/202908

[Romario]

As has been pointed out, your target bitrates are extremely limited.

BUT... just to prove a point, I have exactly the solution you want.

Copy the batch file from this post: https://forum.doom9.org/showthread.php?p=1799950#post1799950

Replace all instances of "--bitrate 6500" with "--bitrate 1650", and all instances of "--preset medium" to "--preset slow".

Run your files through it (this will take quite a while), and mux the audio with MKVMerge.

I was able to turn a 23500kbps source into a 1694kbps quite watchable encode. I wouldn't say its good, but here's a juicy screenshot comparison for you to decide for yourself:

http://screenshotcomparison.com/comparison/202908
Wow, thanks. That's very nice from you.

Unfortunately I also have compressed sources, so it's not always so easy... I have couple of old MPEG2 sources in HD and Full HD.

What is here recommended?

Gesendet von meinem GT-I9295 mit Tapatalk

[benwaggoner]

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.
Bits per pixel requirements go down as resolution goes up. The classical rule of thumb was "to the power of 3/4ths", so going from 720 to 1080 would increase total pixels by 2.25x, bitrate would need to increase by around 1.8x (2.25^0.75) to yield similar quality.

The actual value is probably somewhat less than 0.75 for HEVC due to its greater relative efficiency at encoding higher resolutions. But still, it is just a rule of thumb, and will vary widely with content.

But, assuming full screen playback, more pixels means any given error is spatially smaller and thus less objectionable. Also, visually relevant frequencies are generally lower, so with more pixels, content can be quantized more aggressively and still retain the same amount of visually relevant information.

tl;dr - bbp requirements go down as frame size goes up. The degree varies with content, but a constant bbp across frame sizes isn't appropriate for real-world content.

[microchip8]

@pingfr

at this point in time, x265 is not on-par with x264's detail retention, and no amount of knobs tweaking will change that. Sorry to say it, but you'll have to accept this for the moment. Also, it's not very clear to me what you exactly want. First you say you want very good (equal?) quality compared to x264, then you complain about file sizes

[x265_Project]

Video professionals - MulticoreWare's x265 development team will be attending and exhibiting at the National Association of Broadcasters convention in Las Vegas, April 24-27. We'll have lots of interesting and exciting things to announce and demonstrate. Message us if you need a registration code, or to schedule a meeting. Or just come visit us in the South Hall, Upper, booth SU14604.

[WhatZit]

Unfortunately I also have compressed sources, so it's not always so easy... I have couple of old MPEG2 sources in HD and Full HD.

I don't usually deal with such low bitrates, so I'm having to make educated guesses here.

One thing I will tell you is that, under --tune grain, the slower the preset, the more detail x265 will try to retain. This means that ABR will become more and more bit-starved the more detail you preserve, producing artifacts like the "blotchy" sunrays.

In these cases, you can dial back the speed preset to tune the amount of detail preservation, which will allow ABR to more evenly distribute the bitrate among all picture elements.

To demonstrate clearly what I mean, here's another screenshot comparison (I wish there was a non-WaReZ version of this site):

http://screenshotcomparison.com/comparison/202948

This compares the --preset slow setting I told you about above to a --preset fast setting (no other changes). You can see that there is less detail retained (look at the sunbeams), but overall a "cleaner"/smoother image.

Which you prefer is a matter of taste. The key is to find what works for you.

With your other Full HD sources, you may have to drop the preset speed back to get an "acceptable" picture due to the presence of noise or grain, or the simple light properties of the film.

ffmpeg, which is used to pipe to x265 in the batch file, should be able to read most of the compressed filetypes you have.

EDIT: For such low bitrates, you should also change the deblock from -6:-6 to something like 2:-5. Deblock is, in practice, a strange beast, but it works as a pair, which I've interpreted as in the form of (how_much) : (how_often). In other words, the first offset is what type of deblocking to apply, and the second is when to use it.

The x265 manual itself is not very clear on how this loop filter operates, but you can read about HEVC Deblock theory here: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

Ripped off from that submission:

"The first number (tC) controls the selection between the normal and strong filter and determines the maximum absolute value of modifications that are allowed for the pixel values for a certain QP for both normal and strong filtering operations. This helps adaptively limit the amount of blurriness introduced by the deblocking filtering."

"The second number (β) controls what edges are filtered, controls the selection between the normal and strong filter, and controls how many pixels from the block boundary are modified in the normal filtering operation. One can observe that the value of β increases with QP. Therefore, deblocking is enabled more frequently at high QP values compared to low QP values, high QP values correspond to coarse, and low QP values correspond to fine quantization."

At 1080P 1650kbps, you will get significant blocking in high-motion elements, so raising the (how_much) higher than the default strength of 0 will help blend those out. However, since you don't want any of your detail smoothed out in static elements, you have to tell (how_often) to restrict when it chooses to blend. I think -5 will limit the decisions to only high-motion scenes.

Regardless, this is DEFINITELY something that you'll need to experiment with yourself if you want to employ those extremely low bitrates for general use.

[need4speed]

Hi all, great improvements lately with newer versions, so thanks for starters.
Have a question; tried different settings and tweaks but still having issues with crf. Basically I am encoding avc TV series, 1080p mkv, so to save disk space. I know it's not a good practice but, still...
Ok so I am dealing mainly with 5000 to 13000 kbs mkv video rate, trying to save say 40% in terms of final video size.
First tried 2pass Abr, 4000kbs,tune grain and aq motion. Other settings are mainly default, except for nosao, no strong intrasmoothing, no Deb lock and me star.
Results are pretty good for my needs. A bit too slow so I tried to move on to crf.
I often get too low final bitrate, results nice but not satisfactory.
So question is: there is any way to set minimum bitrate in crf mode? Can't really find it. Ideally would like to set a proper range, say 3000 min 4500 max and distribute bitrate in a smart way, so to speak.
Many thanks for any idea or suggestions!

Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

CRF means: The encoder will try to guarantee that the quality loss will stay below a certain level. But it will only take as much bitrate as it really needs to preserve enough quality. Requesting more bitrate would only waste space without additional value. Clinging to a bitrate range is usually not optimal; it does not reflect the diversity of video material (e.g. talk shows or landscape stills with little motion need a lot less bitrate to preserve the same quality, compared to action movies).

So the other direction may be suitable: Decrease your preferred CRF value a bit to preserve better quality, but limit the maximum bitrate. This is usually achieved best by specifying VBV limits.

[Romario]

CRF means: The encoder will try to guarantee that the quality loss will stay below a certain level. But it will only take as much bitrate as it really needs to preserve enough quality. Requesting more bitrate would only waste space without additional value. Clinging to a bitrate range is usually not optimal; it does not reflect the diversity of video material (e.g. talk shows or landscape stills with little motion need a lot less bitrate to preserve the same quality, compared to action movies).

So the other direction may be suitable: Decrease your preferred CRF value a bit to preserve better quality, but limit the maximum bitrate. This is usually achieved best by specifying VBV limits.
Can you tell me one example, so that I see how that work? Thanks in advance.

Other thing now.

Can I use denoise filter, make that any sense? To have better quality encodes, of course.

And which denoise filter is best?

Gesendet von meinem GT-I9295 mit Tapatalk

[aymanalz]

Can you tell me one example, so that I see how that work? Thanks in advance.

Other thing now.

Can I use denoise filter, make that any sense? To have better quality encodes, of course.

And which denoise filter is best?

Gesendet von meinem GT-I9295 mit Tapatalk

x265 has an internal denoiser that you can apply, and it works very fast. But if you want high quality denoising, you should apply avisynth scripts like nlmeans or knlmeans.

For the x265 noise reduction, use command line --nr-inter <integer> and --nr-intra <integer>.

[WhatZit]

So question is: there is any way to set minimum bitrate in crf mode? Can't really find it. Ideally would like to set a proper range, say 3000 min 4500 max and distribute bitrate in a smart way, so to speak.

Have a read through this: x265 Quality, Rate Control & Rate Distortion Options (http://x265.readthedocs.io/en/default/cli.html#quality-rate-control-and-rate-distortion-options)

You might like to experiment with the --crf-max option. EDIT: Doesn't work in CRF mode unless you enable VBV, apparently! (https://bitbucket.org/multicoreware/x265/issues/61/vbv-crf-min-max-level-profile-tier) Ditto for below.

Can you tell me one example, so that I see how that work? Thanks in advance.

Make sure you understand the consequences described in that manual section when combining video buffer verification with constant rate factors.

Without using VBV, LigH's CRF suggestion above would be something like --crf 19 --crf-min 17

[need4speed]

Have a read through this: x265 Quality, Rate Control & Rate Distortion Options (http://x265.readthedocs.io/en/default/cli.html#quality-rate-control-and-rate-distortion-options)

You might like to experiment with the --crf-min option.



Make sure you understand the consequences described in that manual section when combining video buffer verification with constant rate factors.

Without using VBV, LigH's CRF suggestion above would be something like --crf 19 --crf-max 17
Many thanks to you and light, have gone through the whole white papers reading and was/am still somehow confused about all parameters and, above all, dependencies.
Still, have tried in the meantime some other tweaks with crf and, to recap:
Two pass Abr works better than crf.
I know this is all personal perception and its OK. BUT two pass is really too slow,guess I'll have to cope with that.
Will try crf min.
Thanks again!
BTW, have tried crf 19, aqmotion and rskip,me star. What is weird is that out of two tests the final result is totally spoiled. 1,6 gigs turned into 125 megs. Totally wrong! Just for the record really but wondering if I did anything wrong since rskip gave me a totally acceptable fps conversion speed.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[WhatZit]

BUT two pass is really too slow,guess I'll have to cope with that.

That's the main reason why I stopped using it. In fact, my original .bat used 3-pass, with little improvement for the extra time spent.

Still, the new processors on the market may change the ABR situation for the better...

Will try crf min

I don't use those CRF min/max options, but I do remember experimenting with them once and noticed no difference. Hope you have better luck.

EDIT: Found something interesting about the seemingly non-functional crf min/max: https://bitbucket.org/multicoreware/x265/issues/61/vbv-crf-min-max-level-profile-tier

Used only for ABR/VBV? The Feb 17, 2017 manual still hasn't clarified this.

[x265_Project]

We've been experimenting with new lambda tables, which are the set of constants that are used to determine the relative importance given to bit rate vs. distortion, as candidate modes and motion vectors are evaluated for each block of video. We think there is an opportunity for improvement, but as with everything we do, we care only about subjective visual quality and not objective measures of quality (PSNR, SSIM, etc.). So, this means we have a lot of testing to do, with a wide variety of video test content, at a wide range of quality levels. Since x265 is open source, we can crowd-source some of the testing and feedback.

If you're interested, we would welcome your feedback with one of our candidate lambda tables.

Use the attached file, removing the .txt from the file name to save as a Comma Separated Value (.csv) file.

Then, run an 8 bit encode using the default x265, and run a 2nd encode using --lambda-file x265-NewLambdaTable.csv (pointing to this new csv file). Note that a constant QP or CRF encode will probably be larger than your default encode, so to fairly evaluate the new lambda table you need to do 2 pass encodes in both cases (you can use --no-slow-firstpass in --pass 1, to speed things up). If you're used to heavily modifying your command line, we would suggest that you don't for these tests (stick with a --preset).

Compare the visual quality of x265 today with x265 with the new lambda table, and let us know which one you prefer.

Again... this is for 8 bit encodes only. Bit rates of --qp or --crf encodes will be affected, so use 2 pass encodes to produce A/B test encodes of equal file size that you can compare.

Thanks.

[need4speed]

If you're interested, we would welcome your feedback with one of our candidate lambda tables.

Simply copy and paste the values below into a spreadsheet application, then save as a Comma Separated Value (.csv) file. Or you can use a text editor, putting a comma between each value.



Again... this is for 8 bit encodes only. Bit rates of --qp or --crf encodes will be affected, so use 2 pass encodes to produce A/B test encodes of equal file size that you can compare.

Thanks.

[/CODE]

Hi, will try in few minutes when I get some confirmations:
This is my line in Staxrip, can you please check if anything wrong?

--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --lambda-file "C:\Users\zione\Desktop\lamba.csv" --no-sao --no-slow-firstpass --aq-motion

[x265_Project]

Hi, will try in few minutes when I get some confirmations:
This is my line in Staxrip, can you please check if anything wrong?

--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --lambda-file "C:\Users\zione\Desktop\lamba.csv" --no-sao --no-slow-firstpass --aq-motion

Stick with --preset fast, and drop the --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --no-sao --aq-motion

To do 2 pass encodes, you need to run 2 separate encoding passes.

1st pass: x265 [input options, bitrate, preset] --pass 1 --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2

I haven't used Staxrip, so I may not be the best advisor here.

[need4speed]

Stick with --preset fast, and drop the --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --no-sao --aq-motion

To do 2 pass encodes, you need to run 2 separate encoding passes.

1st pass: x265 [input options, bitrate, preset] --pass 1 --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2

I haven't used Staxrip, so I may not be the best advisor here.

Thanks, to be honest have tried with my seetings and 2pass, new file as suggested. There is quite a difference and it is not remarkable but quite indicative, both in terms of encoding speed (dont know if this is supposed to happen, about 12-15%) and final perceived quality. I am not a pixel peeper but checking some screenshots I see a difference, not really big but noticeable.

Will try to stick to presets as suggested but need some help on how to set up staxrip as requested, especially setting pass1 and pass2 differently.
Thanks again

[x265_Project]

Updated the lambda table above... please give this a try.

[need4speed]

Updated the lambda table above... please give this a try.
Will in a couple of hours, would it be possible to have the command line to input for fast and bitrate 4000?
TIA

Inviato dal mio GT-N7100 utilizzando Tapatalk

[need4speed]

Updated the lambda table above... please give this a try.

hmm..something wrong here.
Same everything, was workins ok with old values, here's what I get when updated csv file:

***************************************

Error Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit

Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit failed with exit code: 2 (0x2)

The exit code might be a system error code: STATUS_WAIT_2

The exit code might be a system error code: Impossibile trovare il file specificato.

y4m [info]: 1912x1072 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.3+8-cfaff341e350
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [error]: lambda file contains too many values
x265 [error]: failed to open encoder
avs2pipemod[info]: writing 27960 frames of 24000/1001 fps, 1912x1072,
sar 0:0, YUV-420-planar-8bit progressive video.
avs2pipemod[info]: finished, wrote 1 frames [0%].
avs2pipemod[info]: total elapsed time is 0.016 sec.
avs2pipemod[error]: only wrote 1 of 27960 frames.



StaxRip.ErrorAbortException: Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit failed with exit code: 2 (0x2)

The exit code might be a system error code: STATUS_WAIT_2

The exit code might be a system error code: Impossibile trovare il file specificato.

y4m [info]: 1912x1072 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.3+8-cfaff341e350
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [error]: lambda file contains too many values
x265 [error]: failed to open encoder
avs2pipemod[info]: writing 27960 frames of 24000/1001 fps, 1912x1072,
sar 0:0, YUV-420-planar-8bit progressive video.
avs2pipemod[info]: finished, wrote 1 frames [0%].
avs2pipemod[info]: total elapsed time is 0.016 sec.
avs2pipemod[error]: only wrote 1 of 27960 frames.


in StaxRip.Proc.Start() in D:\Projekte\VS\VB\StaxRip\General\Proc.vb:riga 240
in StaxRip.x265Encoder.Encode(String passName, String batchCode, ProcessPriorityClass priority) in D:\Projekte\VS\VB\StaxRip\Encoding\x265.vb:riga 74
in StaxRip.x265Encoder.Encode() in D:\Projekte\VS\VB\StaxRip\Encoding\x265.vb:riga 43
in StaxRip.MainForm.Encode() in D:\Projekte\VS\VB\StaxRip\Forms\MainForm.vb:riga 2245
in StaxRip.MainForm.RunJobRecursive() in D:\Projekte\VS\VB\StaxRip\Forms\MainForm.vb:riga 3506

[x265_Project]

hmm..something wrong here.
Same everything, was workins ok with old values, here's what I get when updated csv file:

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.

[need4speed]

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.

Thanks, was revising the two original files and in the second one there was an additional line.
Will try newer file in a sec.
UPDATE: file is working ok now, encoding.
Btw, could I add nosao nodebloock nostrongintrasmoothing to the preset fast at present time? The file encoded with original table was somehow more defined and blurred at the same time..cant really explain without adding screenshots (maybe later) but the signs and writings etc were more defined and clearer, somehow faces were more blurred than usual. Hard to explain but this was something I have noticed immediately. MY PERSONAL OPINION of course!

[sneaker_ger]

Then, run an 8 bit encode using the default x265, and run a 2nd encode using --lambda-table x265-NewLambdaTable.csv (pointing to this new csv file).
It's --lambda-file, not --lambda-table.

[need4speed]

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.
Ok,
I have run some tests with a 20mins tv episode mkv, just to check main differences as for the encoding sessions I usually run.
The attached file is producing better results than the former one, fast profile as is and adding only no slow firstpass.
Anywyas the best outcome is adding some additional tweaks as for one of my previous messages, specifically:
--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --aq-motion --no-strong-intra-smoothing --no-deblock --lambda-file "C:\Users\zione\Desktop\x265-NewLambdaTable.csv" --no-sao --no-slow-firstpass
This is really making a difference, not huge but it works great for my needs.
Usually I encode in 10bits, is or will this be possible?
So far thanks for your tweaks, in case I can upload samples with different settings if needed.
For the record I7 3700 is now about 15 fps, definitely good.
Again, I am not a pixel peeper and am not interested in a "perfect" result but these settings and your file is giving out really nice files.
Will try again with some files encoded originally 13/15 mbs avc.
I am still using staxrip 1407 and no issues so far,together with HEVC encoder version 2.3+8-cfaff341e350

[x265_Project]

It's --lambda-file, not --lambda-table.
Good catch. Fixed. Thanks.

[x265_Project]

The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

[need4speed]

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

As for detail retention and AVC files I have no complains, meaning that my only goal is keeping as much quality as possible and decrease file size, so I fully understand limitations.
Still, the perceived quality with new table is higher than the old values, hence this is something that definitely helps x265 improvement. I assume the benefits will be similar for better material as well.
Will be waiting for the 10bits tables, but for the time being keep up with the good job 'cause we definitely have something here!
Thanks again!

[sneaker_ger]

I did a short lambda test. Had to search a bit for frames with some pronounced differences. New lambda was a bit better.

https://abload.de/img/source_yvu0k.png
https://abload.de/img/default_69ul1.png
https://abload.de/img/newtable_jiu1w.png

[brumsky]

The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

I can't wait for the 10 it tables!! Thanks and great job as always!

[x265_Project]

If you have heavily customized your x265 encoding parameters in order to improve the level of detail, I would suggest trying a 2 pass encode with the new lambda table with your favorite --preset, comparing it to a 2 pass encode without the new lambda table. Some of the tendencies of x265 that you may have been trying to correct for may be addressed by this new lambda table. We look forward to your feedback.

[x265_Project]

I did a short lambda test. Had to search a bit for frames with some pronounced differences. New lambda was a bit better.

https://abload.de/img/source_yvu0k.png
https://abload.de/img/default_69ul1.png
https://abload.de/img/newtable_jiu1w.png
Thanks for your feedback. The differences are pretty subtle, since you're obviously using a decent bit rate. The difference between the old lambda table and the new one are easier to see at lower bit rates.

[Magik Mark]

I'm sorry what is the syntax for lamda? Any parameters?


Sent from my iPhone using Tapatalk

[LigH]

@ Magic Mark:

Mixing replies from x265_Project (https://forum.doom9.org/showthread.php?p=1800669#post1800669) and need4speed (https://forum.doom9.org/showthread.php?p=1800796#post1800796):

1st pass: x265 [input options, bitrate, preset] --pass 1 --lambda-file x265-NewLambdaTable.csv --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2 --lambda-file x265-NewLambdaTable.csv

[Magik Mark]

Thanks. How do I do this in staxrip? Where can I get the lamda file? Which version of x265 is supported?


Sent from my iPhone using Tapatalk

[need4speed]

@ Magic Mark:

Mixing replies from x265_Project (https://forum.doom9.org/showthread.php?p=1800669#post1800669) and need4speed (https://forum.doom9.org/showthread.php?p=1800796#post1800796):

1st pass: x265 [input options, bitrate, preset] --pass 1 --lambda-file x265-NewLambdaTable.csv --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2 --lambda-file x265-NewLambdaTable.csv
Thanks Ligh, I stick to Staxrip and first pass is OK, checking logs second pass is not picking up the specified settings, can you point me to the rifmght direction please?
I have no problem switching to cli a nd, guess ffmpeg but need some directions here as well.
Have read some white papers but can't figure it out

Inviato dal mio GT-N7100 utilizzando Tapatalk

[sneaker_ger]

You should be able to use --no-slow-firstpass on all passes if your GUI does not support different options for different passes. If should just be ignored in the 2nd pass, then.

Thanks. How do I do this in staxrip? Where can I get the lamda file?
https://forum.doom9.org/showpost.php?p=1800604&postcount=4957
In StaxRip's "Other 2" x265 option you can choose the lambda file.

[need4speed]

Thanks Ligh, I stick to Staxrip and first pass is OK, checking logs second pass is not picking up the specified settings, can you point me to the rifmght direction please?
I have no problem switching to cli a nd, guess ffmpeg but need some directions here as well.
Have read some white papers but can't figure it out

Inviato dal mio GT-N7100 utilizzando Tapatalk
Basically in Staxrip where can I specify settings for second pass?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[pradeeprama]

The updated lambda2 table for 8-bit are pushed in now into the default branch. You can build at changeset db5e22b856f5 to get the updated encoder.

Feedback from more testing is welcome!

[stax76]

Thanks. How do I do this in staxrip? Where can I get the lamda file?

All codec dialogs have a search input box at the bottom of the dialog.

The Search input field can be used to search for options, it searches in the switch, the label and the help. Multiple matches can be cycled by pressing enter.

[Midzuki]

x265.exe 2.3+22-db5e22b856f5

http://www.mediafire.com/file/ak31a1i5oj2o9rj/x265_2.3+22-db5e22b856f5.7z

[pingfr]

@Midzuki: Thanks for the precompiled binary!

@x265_Project & @LigH: Any newer parameters we should pass to the 2.3+22 build in order to benefit on the new improved subjective visual quality algorithm?

[x265_Project]

@Midzuki: Thanks for the precompiled binary!

@x265_Project & @LigH: Any newer parameters we should pass to the 2.3+22 build in order to benefit on the new improved subjective visual quality algorithm?

Just try it with your favorite default preset first. Do a 2 pass encode, to match the bit rate to one of your earlier encodes, and then compare the quality.

[pingfr]

Just try it with your favorite default preset first. Do a 2 pass encode, to match the bit rate to one of your earlier encodes, and then compare the quality.

So no point running any tests when using CRF?

Thanks for your replies.

[x265_Project]

So no point running any tests when using CRF?

Thanks for your replies.
If you run CRF, the new build will generate larger files. There's no point in trying to compare the visual quality of 2 encodes that have different bit rates. So, you would have to experiment to figure out a higher CRF value that produces the same file size as before. If you went through that trouble, you could then make a valid comparison.

[ndkamal]

Originally Posted by x265_Project View Post
The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.



I've made some tests with the new lambda table, and the results are great, there are more details with the the last build.

Greats works !!!!

[Magik Mark]

Guys

Pls advise us if lamda file or 10bit is available

[LigH]

As you can read, this lambda2 file is for 8-bit encoding only. I believe it is now already default in a current build (v2.3+22)? commit db5e22b (https://bitbucket.org/multicoreware/x265/commits/db5e22b856f53b4024a5933a1ca4f1f977a016ba)

[shinchiro]

I tried testing on anime material. While the new lambda generally better in all cases, in lots of motion scene(bframes?) noises is more noticeable in new build. I guess this is normal?

[Stephen R. Savage]

How was the new coefficient table calculated?

[need4speed]

I tried testing on anime material. While the new lambda generally better in all cases, in lots of motion scene(bframes?) noises is more noticeable in new build. I guess this is normal?
Same feeling. TV series, dark scenes and fast motion.
Noticeable improvements generally speaking but there seems to be more noise, especially in dark scenes.
Will check and compare screenshots later.
X265 last posted version, Staxrip, preset fast, two pass, Abr 4000, no Sao no deblock, no strong is, aq motion, no slow first pass.
I assume new lambda table is default?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

How was the new coefficient table calculated?
Trade secret.

No, seriously... part theoretical, part experimental. We calculated a better theoretical curve, and then we experimented with variations on this curve until we were satisfied that we found the optimal curve. [The values in the lambda table are an exponential function... forming a straight line if you plot them exponentially]. This is not the optimal curve with respect to objective quality metrics like SSIM and PSNR... it's the optimal curve with respect to subjective visual quality.

Psy-rd, psy-rdoq, AQ and cu-tree may all need to be slightly tuned now, and we're looking at this. The starting few seconds of ABR rate control (--bitrate) will also need to be recalibrated.

[HWK]

Just to confirm if you have multi build, lambda 2 table is used if input and output depth both are at 8 bit.

[brumsky]

So what's the story with rdoq-level 1 vs 2? I've been toying around with it and it seems that 1 is "sharper" but it might not be as true to the source compared with 2.

I also noticed rdoq-level 2 is used in the higher presets.

[x265_Project]

Just to confirm if you have multi build, lambda 2 table is used if input and output depth both are at 8 bit.
It only depends on output depth. If input depth is greater than output depth, x265 truncates the samples to the internal depth (the output depth). It will dither the last bit if you add --dither. So if you have 10 bit content but you want an 8 bit encode, x265 will use 8 bits for all calculations, and it will use the 8 bit lambda table.

[CruNcher]

x265_Project

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception ?

and at which QP this merges currently depending on the overall Preset Setup in x265 or does it explicitly need AQ enabled, and how this shifts between Generations ?

Or do you know some papers this was discussed about in General @ HEVC at conferences primarily maybe by Ateme, Dolby, Technicolor, Sony, Samsung ?

[x265_Project]

x265_Project

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception ?

and at which QP this merges currently depending on the overall Preset Setup in x265 or does it explicitly need AQ enabled, and how this shifts between Generations ?

Or do you know some papers this was discussed about in General @ HEVC at conferences primarily maybe by Ateme, Dolby, Technicolor, Sony, Samsung ? Uhhh... No.