x265 HEVC Encoder

[LigH]

MeGUI did not yet provide a lot of options for x265 because x265 still changes a lot (and its developer seems to be not very active a.t.m.). Other tools like StaxRip x64 and Hybrid may provide more detailed and current GUI options. Also there is MuldeR's Simple x264/x265 launcher; but beware, it will not create any AviSynth script to let x265 read media files.

[hector1980]

So Staxrip and Hybrid gives away best features for X265?!
By the way is there any AVISYNTH for hevc X265 or not??

[LigH]

I don't know which is "the best". Maybe one I did not yet hear of. I use batch files most usually, and I do not even use x265 regularly yet, only for testing.

Unmodified x265 builds can not yet load AviSynth scripts directly, only YUV (raw without, or with YUV4MPEG header); you will usually pipe from a tool which can read AviSynth scripts (e.g. avs4x26x) to x265. But there may be x265 builds modified to include additional input modules.

The x in x265 is lower case. HEVC is all upper case.

[burfadel]

Originally Posted by Motenai Yoda

just use --no-sao --deblock -2:-2 --rdoq-level 2 or 1 --psy-rdoq 1.5 or 2

@burfadel level 1 give better result for the same crf, but also a bigger file, at the same bitrate level 2 generally looks better.
also note, on presets lower than slow, without setting --psy-rdoq it's defaulted to 0 and --rdoq-level don't do anything.

I did some testing, we're both 'right' . Without changing any other settings, --rdoq-level 1 is nicer than 2, but 2 results in smaller file. I increased the -psy-rdoq to 1.28 which equates to generally the same file size (1.3 is fractionally larger), and --rdoq-level 2 was nicer whilst maintaining the same file size as --rdoq-level 1.

So, --rdoq-level 2 by itself isn't ideal, therefore I stand by my previous settings with the following alterations:

--rdoq-level 2 (changed from 1)
--psy-rdoq 1.28 (up from the default of 1.00)

[stax76]

Originally Posted by LigH

MeGUI did not yet provide a lot of options for x265 because x265 still changes a lot (and its developer seems to be not very active a.t.m.). Other tools like StaxRip x64 and Hybrid may provide more detailed and current GUI options. Also there is MuldeR's Simple x264/x265 launcher; but beware, it will not create any AviSynth script to let x265 read media files.

It don't has anything to do with x265 is still changing but rather with GUI building is very tedious.

As example my x264 dialog is about 4000 lines of code for about 100 switches and everything is handcrafted. I had to go to 7 different code locations when I was adding a new switch.

When x265 came up I had better coding skills and better tools available, it was clear I'm not going again into the major trouble of building and maintaining something tedious like my x264 dialog, I had few choices, make only a CLI solution, I toy solution, or think about how can I add full support without 95% of the hassle I dealt in the x264 dialog with. My solution was a GUI framework were the GUI is done from code, that's why all new GUIs look very similar, they are all build without form designer. The second part is a command line framework where the GUI, GUI logic, command line definition, command line logic and command line generation and persistence, is handles, everything is integrated and automated.

This resulted in instead on 7 lines needed to edit for every switch only a single line needed for the majority of switches. The entire x265 dialog has a code size 3-4 time smaller then the x264 dialog while supporting about more 30 switches .

The end result is my definitions look as simple as this:

New OptionParam With {.Switch = "--fps", .Text = "FPS:", .Options = {"Automatic", "24", "24000/1001", "25", "30000/1001", "50", "60000/1001"}},
New NumParam With {.Switch = "--seek", .Text = "Seek:"},
New BoolParam With {.Switch = "--dither", .Text = "Dither (High Quality Downscaling)"})

Building the frameworks took much time but it was also much fun being innovative work instead of drudge work like the x264 dialog, it's also fun to add new codecs and switches, things take now minutes instead of hours.

It don't make sense to add all switches from an encoder because some switches are not relevant for instance audio switches which handles the GUI on it's own, from all switches I think they are relevant StaxRip has a 100% coverage for x265, QSVEncC and NVEnC, it has a automated test built in that analyses x265/QSVEncC/NVEnC help file and source code to detect new, changed and removed switches.

I'm waiting for new codecs to be added because it will take only minutes and will be fun.

[Motenai Yoda]

Originally Posted by burfadel

I increased the -psy-rdoq to 1.28 which equates to generally the same file size

I was rather talking about decrease crf

[burfadel]

I know, I just wrote what looked more effective .

[Grojm]

Seems they are preparing another x265 stable release: https://bitbucket.org/multicoreware/x265/commits/

However, this (major / showstopping) ghosting / flickering bug seems still to be present. The only thing they have provided so far is this placebo "no recursion skip" switch which does not reduce the ghosting / flickering in a significant manner, as I described before: http://forum.doom9.org/showpost.php?...postcount=3713

Seems I have to wait another year until I can replace x264 with x265 for my movie projects...

[LigH]

And we have to hear the same complaints for another year...

But we should already know: Implementing features they get paid for is their priority, and fixing issues you don't really know the reason of takes more time.

I won't lose confidence, though, that issues will be fixed. And it will be easier with more obvious and reproduceable samples.

[nevcairiel]

Originally Posted by Grojm

However, this (major / showstopping) ghosting / flickering bug seems still to be present. The only thing they have provided so far is this placebo "no recursion skip" switch which does not reduce the ghosting / flickering in a significant manner

Did they actually say this is supposed to directly help with that? I didn't read that, but I may have missed it. Otherwise, not everything revolves around one particular issue, that flag probably has a bunch of other uses
Note that --no-recursion-skip was renamed to --no-rskip

[pingfr]

Merge with default; prep for 2.0

It's coming!

Originally Posted by LigH

Implementing features they get paid for is their priority, and fixing issues you don't really know the reason of takes more time.

To be clear, encoding efficiency and quality are our first priority. We cannot afford to come in 2nd place to any other encoder.

[Grojm]

Originally Posted by nevcairiel

Did they actually say this is supposed to directly help with that? I didn't read that, but I may have missed it. Otherwise, not everything revolves around one particular issue, that flag probably has a bunch of other uses
Note that --no-recursion-skip was renamed to --no-rskip

You are right, only some forum users claimed that. The x265 team just claimed that with this switch "visual quality is greatly improved" (without mentioning in which way the quality is improved): https://www.facebook.com/x265project...2%3A%22R%22%7D

[fauxreaper]

Multi-level rskip is a good improvement: has less compression artifacts and better quality than old --rskip.

[LigH]

x265 1.9+227-836a870ba76b: merge with stable

[shinchiro]

I noticed about ~8% speed drop in commit 836a870 compare to 626fcbac7ffb under similar settings. Is rskip going to cost that much speed?

[LigH]

Rather surprising; I would expect skipping a few recursion steps speeding up the encoding instead.

[stax76]

maybe somebody has a idea on following error:

http://pastebin.com/bGKH1yLZ

C:\Stax\Apps\ffmpeg\ffmpeg.exe -i "D:\Video\The Dead Pool 1988_temp\The Dead Pool 1988_new.avs"
-f yuv4mpegpipe -pix_fmt yuv420p -loglevel error - | C:\Stax\Apps\x265\x265_ml.exe --pass 2
--bitrate 1861 --output-depth 10 --aq-mode 3 --bframes 8 --frames 131224 --y4m
--stats "D:\Video\The Dead Pool 1988_temp\The Dead Pool 1988_new.stats"
--output "D:\Video\The Dead Pool 1988_temp\The Dead Pool 1988_new_out.hevc" -

y4m  [info]: 1920x1072 fps 24000/1001 i420p8 unknown frame count
raw  [info]: output file: D:\Video\The Dead Pool 1988_temp\The Dead Pool 1988_new_out.hevc
x265 [info]: HEVC encoder version 1.9+140-34a3d35c5f97
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
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       : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 20 / 8 / 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  : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : ABR-1861 kbps / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao stats-read
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe

[LoRd_MuldeR]

I think the error message "av_interleaved_write_frame(): Broken pipe" originates from the FFmpeg process.

You will usually get this error after the application on the "output" side of the pipe has terminated unexpectedly, so the pipe is now broken and thus FFmpeg (which is on the "input" side of that pipe) now fails to write to the pipe.

My guess would be that the x265 process has crashed. Either that, or it already failed to even start with encoding.

[LigH]

If it happens at the end, I'd wonder if the movie has as many frames as delivered in the command line; if it happens quite immediately, maybe there is something with the stats? And probably somewhere in the middle ... hmm, Selur mentioned unexpected crashes in MinGW builds created by media-autobuild_suite; which x265.exe build do you use?