x265 HEVC Encoder

[MeteorRain]

Originally Posted by Ma

My solution is to switch off Windows Update (before I want encoding):
https://www.easeus.com/todo-backup-r...ly-update.html (Solution 1. Disable Windows Update Service)

AFAIK Windows will try to change it back by itself.
My solution is to add both WUAU and delivery optimization service into Windows Firewall rules, and block all the outgoing traffic.

[RieGo]

adding more offtopic:
best way to prevent windows 10 updates is by disabling automatic installation in group policies (only on win 10 pro i think).
this is an easy and permanent solution.

[LigH]

But some people may not accept the risk of disabling updates and leaving Windows unpatched against new threats...

[Bhavnahari]

Greetings open source enthusiasts!

I am writing on behalf of the x265 developers. We notice that the open source community across the world has been using and experimenting with the x265 encoder and some of these works have been extremely intriguing. We would like to bring such ideas/experiments to the limelight and as an effort, we are reaching out to you to send in non-copyrighted articles that can be posted on the official x265 blog. We urge everyone who has published research papers based on x265 to share short write-ups on your analysis and your recommendations to improve x265. We believe that such contributions have the potential to become the gateway to new and better dimensions of video technology.

Your contributions will be of immense value to the open source fraternity. Looking forward to seeing the fascinating ideas that you all have. Please write to us at <pradeep@multicorewareinc.com> <bhavna@multicorewareinc.com> <vignesh@multicorewareinc.com>

[LigH]

x265 2.8+40-0106f9f2f867

several new AVX(2) assembler routines

[registoni]

sorry if offtop but I am currious what settings amazon is using for encoding TV series in HEVC using x265 encoder.
In the MI there is rc=crf / crf=21.5. Are they using some encoding preset (medium, slow, slower, etc) or some fine tuned own setting? (probably stupid question)

[sneaker_ger]

Do they even use x265? x265 is one of many different H.265/HEVC encoders available on the market.

[LigH]

If you can find CRF in the MI, then it's quite probable that they used x265. Other encoders may not know this mode, and possibly not even store encoder options in MI.

But x265 only stores the internal API level (encoder core relevant) options. They are not equal to CLI options in every case. Selur has a tool which can calculate back which preset and tuning you could use to minimize the options. But you can't know whether a preset and tuning was indeed used. Or if a CLI encoder was used at all (maybe they have their own application using the encoder library via API).

[registoni]

Originally Posted by sneaker_ger

Do they even use x265? x265 is one of many different H.265/HEVC encoders available on the market.

some info from MI:

General
Format                                   : Matroska
Format version                           : Version 4 / Version 2
File size                                : 3.62 GiB
Duration                                 : 59 min 30 s
Overall bit rate                         : 8 696 kb/s
Encoded date                             : UTC 2018-07-02 19:29:19
Writing application                      : mkvmerge v24.0.0 ('Beyond The Pale') 64-bit
Writing library                          : libebml v1.3.6 + libmatroska v1.4.9

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L4@Main
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 59 min 30 s
Bit rate                                 : 8 054 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 0.162
Stream size                              : 3.35 GiB (93%)
Writing library                          : x265 0.0:[Linux][GCC 4.8.2][64 bit] 8bit+10bit+12bit
Encoding settings                        : cpuid=1173503 / frame-threads=1 / wpp / no-pmode / no-pme / psnr / ssim / log-level=2 / csvfn=/apollo/env/YoshiEncodingWorkflowActivitiesLinuxEncoding/var/tmp/62271779/5e5e8977-f266-439e-9262-f5c3dcf1ac15/771fd41e-a6d5-4188-90ed-6d02fb27bab5_video_1080p_9000kbps.csv / csv-log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=40 / 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 / no-open-gop / min-keyint=61 / keyint=120 / bframes=5 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=120 / lookahead-slices=0 / scenecut=0 / 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 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=200 / no-constrained-intra / 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=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=9000 / vbv-bufsize=12000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=2.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=2 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / 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 / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

[LigH]

Yes, quite certainly x265. With some additional information, possibly controlled by RipBot264 or similar tools for network distributed encoding.

[sneaker_ger]

Well, it certainly isn't one of the presets. (e.g. aq-mode 3 is in none of the presets)

https://x265.readthedocs.io/en/default/presets.html

[benwaggoner]

I mistakenly used x264 syntax in a x265 encode, and used --nr 350. But the x265 docs don't even document plain --nr as a command!

Anyone know what it does? --nr-inter 350 --nr intra 350? Just --nr-inter 350? That would match x264's behavior; it doesn't have that kind of intra-block filtering. If it's undefined, I'd recommend that --nr just alias--nr-inter.

[RainyDog]

Is --no-slow-firstpass safe to use for 2-pass encodes? I seem to recall reading a post some time ago which said that a fast/turbo 1st pass can be too unreliable for a slow 2nd pass with much higher settings to use as a basis.

Thanks.

[LigH]

x265 CLI option: slow-firstpass

Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled.

The "turbo" options are indeed quite different from the original options in slow presets. But I don't remember any test showing verbosely how obvious the loss of quality is... the following pass(es) will still use the intended efforts, just the bitrate calculation may be based on a not really optimal reference distribution.

[benwaggoner]

Originally Posted by LigH

x265 CLI option: slow-firstpass

The "turbo" options are indeed quite different from the original options in slow presets. But I don't remember any test showing verbosely how obvious the loss of quality is... the following pass(es) will still use the intended efforts, just the bitrate calculation may be based on a not really optimal reference distribution.

I did some noodling around using the slow-firstpass but reducing subme and a few other low-level things for the first pass. Testing wasn't that complete, but it looked like for a net total encoding time, I could get slightly better results by allowing the second pass to be slower by making the first pass faster. It went to more a 25/75 than 50/50 ratio.

The big problem I see with --no-slow-firstpass is ref=1, which can really impact things with some kinds of content. I would think it is critical to use the same number of reference and b-frames and same badapt mode between passes.


So, using --no-slow-firstpass and then setting --ref to the same as the second pass is likely a good starting point to experiment from

[benwaggoner]

Originally Posted by registoni

sorry if offtop but I am currious what settings amazon is using for encoding TV series in HEVC using x265 encoder.
In the MI there is rc=crf / crf=21.5. Are they using some encoding preset (medium, slow, slower, etc) or some fine tuned own setting? (probably stupid question)

That is not a question I will be answering in any form . Everything I write here is my personal opinion and experience only.

[foxyshadis]

Originally Posted by benwaggoner

That is not a question I will be answering in any form . Everything I write here is my personal opinion and experience only.

I can just see the headlines in six months. "Famed compressionist Ben Waggoner caught in dirty format lies!" "World scoffs as he claims they were true at the time"

As for --nr... I thought that would be a quick find. No, you actually found a bug in getopt, the venerable GNU freaken getopt. It lets you abbreviate options, normally, and has a sanity check in case it matches a second option... but that sanity check only triggers if the shortname (eg, -V) or whether it needs an argument differs. Just in case the developer brain-farted an inserted the same option twice, it wouldn't blow up. But they never bothered to compare the full names!

So yes, entirely by accident, --nr means --nr-intra. I wonder if my getopt.c patch will break anyone's workflow.

[LigH]

I have just noticed a proposed patch in the mailing list that addresses this issue. Was that yours? ... They prefer patch sources in the mail body, not as attachment only.

[RainyDog]

Originally Posted by benwaggoner

I did some noodling around using the slow-firstpass but reducing subme and a few other low-level things for the first pass. Testing wasn't that complete, but it looked like for a net total encoding time, I could get slightly better results by allowing the second pass to be slower by making the first pass faster. It went to more a 25/75 than 50/50 ratio.

The big problem I see with --no-slow-firstpass is ref=1, which can really impact things with some kinds of content. I would think it is critical to use the same number of reference and b-frames and same badapt mode between passes.


So, using --no-slow-firstpass and then setting --ref to the same as the second pass is likely a good starting point to experiment from

Thanks benwaggoner.

Yeah, ref=1 and rd=2 were the two settings in --no-slow-firstpass that I saw as cause for concern too. Especially since I sometimes use rd=5 for the 2nd pass too.

How can I specify --ref 4 and --rd 3 with --no-slow-firstpass?

[LigH]

Just in the same command line.

x265 --preset ... --no-slow-firstpass --ref 4 --rd 3 ...

First the "meta options" which change several parameters at once, then atomic options which override these changes.