x265 HEVC Encoder

[x265]

This is a complete command line (preset medium):
--threads 0 --frame-threads 0 --no-wpp --ctu 64 --tu-intra-depth 1 --tu-inter-depth 1 --me umh --subme 7 --merange 16 --max-merge 1 --no-early-skip --no-fast-cbf --rdpenalty 0 --no-tskip --no-strong-intra-smoothing --no-constrained-intra --open-gop --keyint 240 --min-keyint 0 --bframes 3 --weightb --b-intra --b-adapt 2 --b-pyramid --ref 4 --weightp --rc-lookahead 60 --scenecut 40 --bitrate 800 --cbqpoffs 0 --crqpoffs 0 --ipratio 1.4 --pbratio 1.3 --nr 0 --rd 5 --psy-rd 0 --psy-rdoq 0 --signhide --aq-mode 2 --aq-strength 1 --cutree --no-cu-lossless --vbv-maxrate 16000 --vbv-bufsize 16000 --vbv-init 0.9 --no-lft --no-repeat-headers

If i change the version of HEVC (after 1.2.436) with the same command line, the program use dia instead umh

Why are you limiting --merange to 16? I doubt that this will provide any performance improvement, and it will hurt quality. I suggest that you leave --merange at the default (57). Limiting --merange to 16 while using --subme 7 is especially confusing.

Why --threads 0 --frame-threads 0 --cutree --no-cu-lossless? These are defaults.

Why --no-wpp? This will slow down your encode with no measurable benefit.

Why --no-lft? This will hurt quality. You're using a very high rd level, but turning off the loop filter? I'm confused.

You don't need to add --psy-rd or --psy-rdoq to your command line. These are off by default.

My suggestion would be to use default settings for everything except rate control, and see how this works. Then try different command-line adjustments to see the effect on speed and quality.

[NOiZE]

Hi,
thanks for reply. Now, i'm using the default comand line with Megui. But i've not resolve the problem. This is a logs.

1 pass with HEVC encoder version 1.2+518-d43e9a6a7cce:
---[Information] [13/08/2014 10:12:10] yuv [info]: 848x360 fps 5000000/208333 i420p8 unknown frame count
---[Information] [13/08/2014 10:12:10] x265 [info]: HEVC encoder version 1.2+518-d43e9a6a7cce
---[Information] [13/08/2014 10:12:10] x265 [info]: build info [Windows][GCC 4.8.1][64 bit] 8bpp
---[Information] [13/08/2014 10:12:10] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [13/08/2014 10:12:10] x265 [info]: WPP streams / pool / frames : 6 / 4 / 2
---[Information] [13/08/2014 10:12:10] x265 [info]: Main profile, Level-4 (High tier)
---[Information] [13/08/2014 10:12:10] x265 [info]: CU size : 64
---[Information] [13/08/2014 10:12:10] x265 [info]: Max RQT depth inter / intra : 1 / 1
---[Information] [13/08/2014 10:12:10] x265 [info]: ME / range / subpel / merge : dia / 57 / 2 / 1
---[Information] [13/08/2014 10:12:10] x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
---[Information] [13/08/2014 10:12:10] x265 [info]: Lookahead / bframes / badapt : 60 / 3 / 2
---[Information] [13/08/2014 10:12:10] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1
---[Information] [13/08/2014 10:12:10] x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-800 kbps / 1.0 / 1
---[Information] [13/08/2014 10:12:10] x265 [info]: VBV/HRD buffer / max-rate / init : 16000 / 16000 / 0.900

2 pass with HEVC encoder version 1.2+518-d43e9a6a7cce:

---[Information] [13/08/2014 10:13:27] yuv [info]: 848x360 fps 5000000/208333 i420p8 unknown frame count
---[Information] [13/08/2014 10:13:27] x265 [info]: HEVC encoder version 1.2+518-d43e9a6a7cce
---[Information] [13/08/2014 10:13:27] x265 [info]: build info [Windows][GCC 4.8.1][64 bit] 8bpp
---[Information] [13/08/2014 10:13:27] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [13/08/2014 10:13:27] x265 [info]: WPP streams / pool / frames : 6 / 4 / 2
---[Information] [13/08/2014 10:13:27] x265 [info]: Main profile, Level-4 (High tier)
---[Information] [13/08/2014 10:13:27] x265 [info]: CU size : 64
---[Information] [13/08/2014 10:13:27] x265 [info]: Max RQT depth inter / intra : 1 / 1
---[Information] [13/08/2014 10:13:27] x265 [info]: ME / range / subpel / merge : umh / 57 / 7 / 1
---[Information] [13/08/2014 10:13:27] x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
---[Information] [13/08/2014 10:13:27] x265 [info]: Lookahead / bframes / badapt : 60 / 3 / 2
---[Information] [13/08/2014 10:13:27] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 4
---[Information] [13/08/2014 10:13:27] x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-800 kbps / 1.0 / 1
---[Information] [13/08/2014 10:13:27] x265 [info]: VBV/HRD buffer / max-rate / init : 16000 / 16000 / 0.900

Instead with a HEVC encoder version 1.2+436-ed49f875ab20:

1 pass with HEVC encoder version 1.2+436-ed49f875ab20:

---[Information] [13/08/2014 10:24:32] yuv [info]: 848x360 fps 5000000/208333 i420p8 unknown frame count
---[Information] [13/08/2014 10:24:32] x265 [info]: HEVC encoder version 1.2+436-ed49f875ab20
---[Information] [13/08/2014 10:24:32] x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
---[Information] [13/08/2014 10:24:32] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [13/08/2014 10:24:32] x265 [info]: WPP streams / pool / frames : 6 / 4 / 2
---[Information] [13/08/2014 10:24:32] x265 [info]: Main profile, Level-4 (High tier)
---[Information] [13/08/2014 10:24:32] x265 [info]: CU size : 64
---[Information] [13/08/2014 10:24:32] x265 [info]: Max RQT depth inter / intra : 1 / 1
---[Information] [13/08/2014 10:24:32] x265 [info]: ME / range / subpel / merge : umh / 57 / 7 / 1
---[Information] [13/08/2014 10:24:32] x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
---[Information] [13/08/2014 10:24:32] x265 [info]: Lookahead / bframes / badapt : 60 / 3 / 2
---[Information] [13/08/2014 10:24:32] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 4
---[Information] [13/08/2014 10:24:32] x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-800 kbps / 1.0 / 1
---[Information] [13/08/2014 10:24:32] x265 [info]: VBV/HRD buffer / max-rate / init : 16000 / 16000 / 0.900

2 pass with HEVC encoder version 1.2+436-ed49f875ab20:

---[Information] [13/08/2014 10:30:07] yuv [info]: 848x360 fps 5000000/208333 i420p8 unknown frame count
---[Information] [13/08/2014 10:30:07] x265 [info]: HEVC encoder version 1.2+436-ed49f875ab20
---[Information] [13/08/2014 10:30:07] x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
---[Information] [13/08/2014 10:30:07] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [13/08/2014 10:30:07] x265 [info]: WPP streams / pool / frames : 6 / 4 / 2
---[Information] [13/08/2014 10:30:07] x265 [info]: Main profile, Level-4 (High tier)
---[Information] [13/08/2014 10:30:07] x265 [info]: CU size : 64
---[Information] [13/08/2014 10:30:07] x265 [info]: Max RQT depth inter / intra : 1 / 1
---[Information] [13/08/2014 10:30:07] x265 [info]: ME / range / subpel / merge : umh / 57 / 7 / 1
---[Information] [13/08/2014 10:30:07] x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
---[Information] [13/08/2014 10:30:07] x265 [info]: Lookahead / bframes / badapt : 60 / 3 / 2
---[Information] [13/08/2014 10:30:07] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 4
---[Information] [13/08/2014 10:30:07] x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-800 kbps / 1.0 / 1
---[Information] [13/08/2014 10:30:07] x265 [info]: VBV/HRD buffer / max-rate / init : 16000 / 16000 / 0.900
---[Information] [13/08/2014 10:30:07] x265 [info]: tools: rd=5 lft sao-lcu signhide stats-read

With a HEVC encoder version 1.2+436 the first and the second pass are identical, while with a HEVC encoder version 1.2+518 the first and the second pass are not identical (change ref from 4 to 1,subme from 7 to 2 and umh to dia in the first pass!!). The comand line is the same!!Why?

[Selur]

The comand line is the same!!Why?

2pass 1st pass - fast first pass

[LigH.de]

Sooo ... hooray, you discovered the "1st pass turbo" changes in the recent builds?

[NOiZE]

The comand line is the same!!Why?

2pass 1st pass - fast first pass

"2 days ago Aarthi Thirumalai rc: set rdlevel to 2 in fast first pass for multipass encode".
Ok. I have understand now!!
Thanks

[vhelp]

--stats parameter - holds important information about the encoded video.

maybe i am missunderstanding the usefulness of this function and what it returns and what benefit it could serve me.

currently, this function is only encluded if the { --pass 1 } is detected in the parameter list. if i exclude it, the .stats file is not generated. i understand that this info is used for the 2nd pass video, but rather than resort to external tools to provide the same or similar detail ? could it still be useful in a standalone encode as well, say for instance if i encode crf 17 ? the purpose of this query is because i am considering the idea of including graphs to help describe something about a video and i want to enclude whatever graphs that can be useful. i am hoping to stay away from external utilities (tappdecoder) that may provide this and other useful info, if possible. and since x265 already includes .stats detail, why not provide an option to include it (and other useful details) if the user desires it and is not concirned with a slight speed penalty. this information may prove useful in determining best encoding parameters.

--nr parameter - is not found in the parameter list after extraction from the SEI bitstream section.

when looking back on previous encodes done by different builds, i can not assertain whether noise reduction (--nr) was enabled (and used) in that video's encode. the parmeter list does not include that detail, and there is no evidense of a possible combination of parameters: i was trying to determine through a method of reviewing the parameters, to see if there were slight changes in some of the values that might give me a clue that, for instance, --nr 100 or --nr 150 was used. therefore, it seems that noise reduction is something internal and dynamically computed during encoding in the x265 encoder. and without this information, comparison will be skewed due to this missing parameter info since there is no evidense of noise reduction used, per the stored parameter list.

--[no]-fast-intra - i see no info on the webistes for this new paramater.

i searched for this info on the website, but did not see anything. i was wondering, when new parameters are introduced, when are they finally written down in the command parameter list, website and encoder ?

thank you.

[Selur]

", when new parameters are introduced, "
https://bitbucket.org/multicoreware/x265/commits/all -> yesterday: https://bitbucket.org/multicoreware/x265/commits/213f17c1492c5bf96c3f382e7beffe0c871a563c were some changes added, 3 days ago was the initial commit:
https://bitbucket.org/multicoreware/x265/commits/d22dfb9df30f4ff298978560109ebb5fb8153196

[x265]

--stats parameter - holds important information about the encoded video.

maybe i am missunderstanding the usefulness of this function and what it returns and what benefit it could serve me.

currently, this function is only encluded if the { --pass 1 } is detected in the parameter list. if i exclude it, the .stats file is not generated. i understand that this info is used for the 2nd pass video, but rather than resort to external tools to provide the same or similar detail ? could it still be useful in a standalone encode as well, say for instance if i encode crf 17 ? the purpose of this query is because i am considering the idea of including graphs to help describe something about a video and i want to enclude whatever graphs that can be useful. i am hoping to stay away from external utilities (tappdecoder) that may provide this and other useful info, if possible. and since x265 already includes .stats detail, why not provide an option to include it (and other useful details) if the user desires it and is not concirned with a slight speed penalty. this information may prove useful in determining best encoding parameters.

x265 provides a --csv log file function that is more useful for the purpose you describe above. --stats is really only for the encoder to use for multi-pass encoding.

--nr parameter - is not found in the parameter list after extraction from the SEI bitstream section.

when looking back on previous encodes done by different builds, i can not assertain whether noise reduction (--nr) was enabled (and used) in that video's encode. the parmeter list does not include that detail, and there is no evidense of a possible combination of parameters: i was trying to determine through a method of reviewing the parameters, to see if there were slight changes in some of the values that might give me a clue that, for instance, --nr 100 or --nr 150 was used. therefore, it seems that noise reduction is something internal and dynamically computed during encoding in the x265 encoder. and without this information, comparison will be skewed due to this missing parameter info since there is no evidense of noise reduction used, per the stored parameter list.

Sounds like a bug. All encoding parameters should be included. I'll let the team know.

--[no]-fast-intra - i see no info on the webistes for this new paramater.

i searched for this info on the website, but did not see anything. i was wondering, when new parameters are introduced, when are they finally written down in the command parameter list, website and encoder ?

thank you.

Generally, yes. This was contributed by an external developer [thank you Dave... you're awesome!], and we didn't want to beat him up over the documentation while he was still working to perfect the algorithm. Features like this that are exposed in the development branch but experimental (off by default) may lag behind in documentation at times.

[vhelp]

i can see that --nr is posted in the --csv file at least. will wait for the SEI fix.

graphing statistics about a video encode--

i thought that the --csv log would have similiar exhaustive details down to the frame level, like the .stats file, but to my surprise, it doesn't. only the average of i/p/b/bitrate.
currently, the only way to get exhaustive info is by using tappdecode, or ffprobe (for bitrate only) or maybe there are other "free" methods of data extractions that i'm not aware of.
i would like to incorporate graphs together to inlcude i/p/b and other such, if only the --csv log could include such. this could become very valuable to those wanting to incorporate into their gui's, as statisical information, which is what i am trying to do now and also add into x265 infotool if possible through the .stats file, etc. etc.. maybe add another level to --csv log could be incorporated to include this info in the distant future.


* this was a quick and crude graph, ffprobe/excel. but i would like to include more graphs that might help explain
* different parts of videos and/or the encoded parameters.

maybe i will improve upon this graph/idea, later.

[x265]

i can see that --nr is posted in the --csv file at least. will wait for the SEI fix.

graphing statistics about a video encode--

i thought that the --csv log would have similiar exhaustive details down to the frame level, like the .stats file, but to my surprise, it doesn't. only the average of i/p/b/bitrate.
currently, the only way to get exhaustive info is by using tappdecode, or ffprobe (for bitrate only) or maybe there are other "free" methods of data extractions that i'm not aware of.
i would like to incorporate graphs together to inlcude i/p/b and other such, if only the --csv log could include such. this could become very valuable to those wanting to incorporate into their gui's, as statisical information, which is what i am trying to do now and also add into x265 infotool if possible through the .stats file, etc. etc.. maybe add another level to --csv log could be incorporated to include this info in the distant future.

You can get frame by frame statistics in a --csv log file if you use --log 3 or --log 4. We use these log files to plot moving average bit rates, QP values, etc. all the time, just as you are trying to do. Add --psnr or --ssim if you want these values in your log file.

[LigH.de]

The *.stats is for the encoder, it doesn't have to contain more than necessary for a 2nd pass CRF optimization.

The *.csv is for the human developer or tester.

[x265]

Heads up!! We're going to adjust Psy-RD and Psy-RDOQ strength scaling to provide a more typical range of values. Although both of these algorithms are off by default, if you are using them, you will need to adjust your strength values going forward.

Steve has pushed some (what we hope to be) final tunings of the two new psycho-visual optimization features. The features are still disabled by default, but the recommended values are now 1.0 for both.

http://x265.readthedocs.org/en/stable/cli.html#psycho-visual-options

Please try Psy-RD and Psy-RDOQ out and give us your feedback. The stable branch has been merged with default in preparation of a 1.3 tag, which should happen early this week.

[vhelp]

the new insight on the --csv and --log info definately helps! thank you.

also, any chance on updating the webpage (below) to include a date stamp for when you last updated it ?
it would be a big help for those of us that frequent the page for the latest info.

http://x265.readthedocs.org/en/default/cli.html

[x265]

the new insight on the --csv and --log info definately helps! thank you.

also, any chance on updating the webpage (below) to include a date stamp for when you last updated it ?
it would be a big help for those of us that frequent the page for the latest info.

http://x265.readthedocs.org/en/default/cli.html

You're welcome. I'm not sure if there is a way to do what you're asking, but since the reStructured Text (reST) documents are part of the source code, it's easy to see when they are changed, as this is done through the same source control system as the rest of the code. This allows our developers to easily update documentation when they update x265, and it allows anyone to easily contribute improvements to the documentation (as a patch through the development mailing list). The ReadTheDocs site simply displays these documents.
You can see a list of the actual reST docs, along with the date they were last updated here: https://bitbucket.org/multicoreware/x265/src/866f21378d94c5c6c998e5d83a391dace0230ea7/...ST/?at=default

[x265]

We are pleased to announce that we have reached version 1.3.

The primary changes in this release are the completion and tuning of the psycho-visual optimizations and new support for multiple pass encoding.

--psy-rd and --psy-rdoq are now completed and scaled such that their recommended initial values are 1.0.

Multipass encodes are now possible with --pass N and --stats FNAME

As usual, full documentation is at: http://x265.readthedocs.org/en/1.3/

= API Changes =

* param.bEmitInfoSEI, --[no-]info
include an SEI identifying the encoder and encoding options.

* param.bHighTier --high-tier
specify tier (used in conjunction with --level-idc)

* param.bEnableFastIntra --[no-]fast-intra
Use a gradient descent to scan angular intra modes

* param.totalFrames
optional indicator of total frame count, may improve rate control

* param.scalingLists
specify custom quantization matrices, "default" or filename

* param.psyRdoq
Psycho-visual optimizations for quantization

* param.bEnableSlowFirstPass
The first pass of multi-pass encodes will run in *turbo* mode unless this option is enabled.

[Selur]

Nice.
Has anyone checked if the file name of the stats element is properly handled in case of a wild mix of characters like:

F:\TöÄßstCl§ps&èéøÞǽлљΣæčaィ\マンデイ 第\Администратор.stats

?
(will test myself on the weekend if nobody has tested it yet)

--psy-rdoq prevents RDOQ from blurring all of the encoding options which psy-rd has to chose from.

psy-rdoq is hindering itself from blurring the encoding option psy-rd has to chose from? (What?)

[El Heggunte]

For the notes, and from the mailing list:

[x265] bug in sao.cpp

Dzung Hoang Thu, 28 Aug 2014 17:00:39 -0700
A bug was introduced with revision 02ec546246ad with the aim of fixing compiler
warnings.

In the function SAO::processSaoUnitAll() in sao.cpp,

int i;
uint32_t edgeType;

was changed to

uint32_t i;
uint32_t edgeType;

This change caused a segmentation fault (on a particular test case) here:

for (i = 0; i < (1 << X265_DEPTH); i++)
offsetBo[i] = m_clipTable[i + offset[m_tableBo[i]]];

The problem is that the expression "i + offset[m_tableBo[i]" is converted to
unsigned type by the compiler. When this expression would otherwise be
negative, the conversion results in a very big positive number, which causes
the segmentation fault.

The lesson is to be very careful when changing between signed and unsigned
types when the compiler displays a warning. Editing code to remove warnings
sometimes do more harm than good. Perhaps the better approach to fixing type
mismatch warnings is to convert the unsigned variables to signed or with type
casting.

Similar code exists in SAO::processSaoUnitRow() so the same fix should be
applied to this function as well.

Best regards,
- Dzung Hoang

[NOiZE]

Hi,
in megui i have this log"level 5 detected, but NumPocTotalCurr (total references) is non-compliant".
What means?
Thanks

PS:I'm using the last version of x265

[LigH.de]

A larger part of the MeGI log, including the generated command line with complete options, would be preferable.

[NOiZE]

---[Information] [31/08/2014 22:50:46] yuv [info]: 1280x544 fps 24024/1001 i420p8 unknown frame count
---[Information] [31/08/2014 22:50:46] x265 [info]: HEVC encoder version 1.3+53-b18ae1fe86b8
---[Information] [31/08/2014 22:50:46] x265 [info]: build info [Windows][GCC 4.8.1][64 bit] 8bpp
---[Information] [31/08/2014 22:50:46] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [31/08/2014 22:50:46] x265 [info]: WPP streams / pool / frames : 9 / 4 / 2
---[Warning] [31/08/2014 22:50:46] x265 [warning]: level 5 detected, but NumPocTotalCurr (total references) is non-compliant
---[Information] [31/08/2014 22:50:46] x265 [info]: NONE profile, Level-NONE (Main tier)
---[Information] [31/08/2014 22:50:46] x265 [info]: CU size : 64
---[Information] [31/08/2014 22:50:46] x265 [info]: Max RQT depth inter / intra : 1 / 1
---[Information] [31/08/2014 22:50:46] x265 [info]: ME / range / subpel / merge : umh / 57 / 7 / 1
---[Information] [31/08/2014 22:50:46] x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
---[Information] [31/08/2014 22:50:46] x265 [info]: Lookahead / bframes / badapt : 60 / 3 / 2
---[Information] [31/08/2014 22:50:46] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 12
---[Information] [31/08/2014 22:50:46] x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-1820 kbps / 1.0 / 1
---[Information] [31/08/2014 22:50:46] x265 [info]: VBV/HRD buffer / max-rate / init : 16000 / 16000 / 0.900
---[Information] [31/08/2014 22:50:46] x265 [info]: tools: rd=5 psy-rd=1.00 psy-rdoq=1.00 lft sao-lcu signhide stats-read

Maybe the problem is the reference b frames 12, with no level (autodetect,default). My encode is 720p. What is the optimal value for "ref" in a 720p encode?

[LigH.de]

I asked for the x265 command line for a good reason: Did you only use "high level" parameters (which may set up a whole subset of low level parameters, foremost "--preset") or also "low level" parameters (which have a direct equivalent in the video stream metadata, e.g. "--ref 12" explicitly)? A partially over-specific parameter set is probably risky when it clashes with automatic choices in rare cases.

[NOiZE]

I asked for the x265 command line for a good reason: Did you only use "high level" parameters (which may set up a whole subset of low level parameters, foremost "--preset") or also "low level" parameters (which have a direct equivalent in the video stream metadata, e.g. "--ref 12" explicitly)? A partially over-specific parameter set is probably risky when it clashes with automatic choices in rare cases.

--ctu 64 --tu-intra-depth 1 --tu-inter-depth 1 --me umh --subme 7 --merange 57 --max-merge 1 --no-strong-intra-smoothing --keyint 240 --min-keyint 0 --bframes 3 --weightb --b-adapt 2 --ref 12 --rc-lookahead 60 --scenecut 40 --rd 5 --aq-mode 2 --aq-strength 1 --vbv-maxrate 16000 --vbv-bufsize 16000 --vbv-init 0.9 --psy-rd 1 --psy-rdoq 1

[x265]

I asked for the x265 command line for a good reason: Did you only use "high level" parameters (which may set up a whole subset of low level parameters, foremost "--preset") or also "low level" parameters (which have a direct equivalent in the video stream metadata, e.g. "--ref 12" explicitly)? A partially over-specific parameter set is probably risky when it clashes with automatic choices in rare cases.

--ctu 64 --tu-intra-depth 1 --tu-inter-depth 1 --me umh --subme 7 --merange 57 --max-merge 1 --no-strong-intra-smoothing --keyint 240 --min-keyint 0 --bframes 3 --weightb --b-adapt 2 --ref 12 --rc-lookahead 60 --scenecut 40 --rd 5 --aq-mode 2 --aq-strength 1 --vbv-maxrate 16000 --vbv-bufsize 16000 --vbv-init 0.9 --psy-rd 1 --psy-rdoq 1

HEVC Tiers and Levels are described here... https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Tiers_and_levels For 720P60 your encode should be compliant with Level 4, using up to 12 reference pictures in the Decoded Picture Buffer. Still, I would not advise you to specify so many reference pictures. I don't think it is going to buy you anything (except making the bitstream harder to encode and decode).

Other settings that don't seem to make sense...
Too low for good quality: --max-merge 1
Unnecessarily high: --me umh --subme 7 --ref 12

Have you tried one of the standard performance presets? I would recommend starting with a simple --preset. Use the slowest preset that gets the job done in the time you have patience for. You can tweak your command-line from there (add psy-rd and psy-rdoq, try different AQ mode or strength). We configured these settings to gradually make the tradeoff between speed and encoding efficiency. Drastically changing one of these options but not the rest (or worse yet, modifying some options to achieve better efficiency while changing other options to reduce efficiency/improve speed) is not likely to get you the best possible result for the time you're willing to let your encode run.

I hope this helps you.

[NOiZE]

Thanks for reply!!
I'll try it as soon as...possible!!

Ligh.de do you like my slang? lol

[LigH.de]

Possible.

[LigH.de]

According to my current brief test, x265 v1.3+145 became noticably faster now, especially for presets faster than "fast". Unfortunately, it became slower than v1.1-v1.2 for presets slower than "slow". This belongs to a Phenom-II X4, without AVX. Most introduced speedups address AVX2, though, which I can't offer.

[kotuwa]

Zones

Is there any switch or method in x265 to specify zones, like --zones in x264 ?

!?

[Selur]

not atm.

[Selur]

spam?

<img title="[lifehealthus.com]" style="max-width: 100%; border: 1px solid rgb(255, 204, 204); background-repeat: no-repeat; background-position: center center; background-image: url(&quot;data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9gMFRANL5LXnioAAAJWSURBVDjLnZI/ixtXFMV/972ZNzPSrmTtalexlsWBGMfEYOzaVciXyKdIkW/hFKnS22WafIDUxk0g2AQSgm0csIPWK42ktaSRNPP+pRBK5SLOqS7cew7ccw4xxrPJ+8XdHx4+7AE8e3Cj++zLm71fvrqT8x+QAK35dJr2n/x89urTa+eDm/cS+eI2y3eT+Lx/bt8u1vNqfDH++teXdk/6ThAfUUBIgL9ku75z/8WL7LOlhXIGJ0Pyw75wMcnGv//xSQ2DH4ddu9k01dXWsWzcofhYaiiViLjiWi9UWQa1gzcjWF7hgfzzW5ydnXB62JLjg0PTLfJertNepnQSIA+gE4Cs03UuNYYQYP4e5jPogmSG9vA6rrjC+0AxN2i5Qk0DpXVJhCQB0EVRrzqdFgB1DZfvCDHixiV2NqO6LHHKIKnQMoaWbFBgIrQVgIXaDc+JCHgP5QRZr4jzGWFbo6yncRYviiiQKUhBRch3Lyix4bgPWsAkcDkmZAV2OiE0DaI1WoEShRKF3sWnmt01pFBnJydEpZDEwHSGt47lYsls43AIXjTWV9R1Qx0DGahqLyAhbqrj0/ib0nRzXNoyCo0Kkor2llV0eKOwdUMg4pSQA7JPQXvnJv1B+GlwOvrGlaXB6fV2lb5t6qOtike56DSJgYDGBQcOAsQAfueBMeHR48fhadb1j/58HWARdt6yBv7+/vpBe2o5OogxlcaKdt5aKCNsk309W0WxKQjmQ33/9mJVAdWHdmo/tNvtRZIkfCz+ZQwGg6rT6Zj/LTAajTbD4bD5WIF/AAseEisPFO8uAAAAAElFTkSuQmCC&quot;);" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" alt="" border="0" height="50" width="50">

[LigH.de]

Announced in the mailing list, quoted in the doom9 forum, yet forgotten here:

This feature will distribute the motion estimations for each CU that has
more than 2 references. Its effectiveness is proportional to the number
of references, but this feature can often be a net performance loss as
the overhead of involving other CPU cores is often more expensive than
the parallelism benefit.

The output of the encode is completely unaffected by --pme.

Both --pme and --pmode are only useful when x265 is otherwise unable to
fully saturate the CPU cores, and both can also at times result in lower
performance on multi-socket machines (depending on the situation) since
we are not yet keeping work localized to neighbor CPUs.

= Also in 1.4 =

As a result of the refactor work, none of the original HM classes or
source files remain in x265.

Temporal motion vector predictions (previously hard-coded to always be
enabled) are now runtime selectable (param.bEnableTemporalMvp) but still
default to being enabled in all presets.

Frame based SAO analysis was removed (frame based SAO signaling did not
make it into the final HEVC spec), and --sao-lcu-bounds=<0|1> was
renamed to --[no-]sao-non-deblock (param.bSaoNonDeblocked)

Some inconsistencies in the analysis logic were fixed. --amp is now
respected in RD levels 2, 3, and 4 (previously only in 5 and 6).
--b-intra is now respected in all RD levels. --fast-cbf, which has only
ever effective at RD levels 5 and 6, is no longer enabled uselessly in
the fastest presets.

--weightb is now enabled by default at presets slower, veryslow, and
placebo.

--cu-lossless was changed to only attempt a lossless encode of the best
lossy encode method. This made --cu-lossless a much less expensive
encode option to have enabled, and hopefully made the feature more
robust and maintainable.

The upper threshold for --psy-rdoq was raised to 50 (from 10) since the
higher values were found to be beneficial for sources with high
frequency noise (film grain).

The default thread pool size logic was updated to account for the
addition of --pmode and --pme (if WPP is disabled but --pmode or --pme
are enabled, a thread pool is still allocated).

In 1.4 there also appeared an incomplete analysis re-use feature. This
will be completed and further improved in the coming weeks.