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?