x265 HEVC Encoder

[MeteorRain]

I also compile a modded version including various input and output options.

[Selur]

We not only Selur's codecs are also outdated.(GNU 5.3.0)
I normally build fresh versions when:
a. something interesting was committed
b. I release a new Hybrid version
but not sure if I won't stop building myself since the mingw builds keep on randomly crashing on my i7 and on newer Xeons,... (guess there is still something off with MinGW or the way https://github.com/jb-alvarado/media-autobuild_suite builds the binaries,.. MSVC builds seem to work fine)

[Leo 69]

Dear development team,

Has there been any good progress lately? When x265 can be expected to produce as sharp encodes as x264 does?
Thanks a lot!

[microchip8]

Dear development team,

Has there been any good progress lately? When x265 can be expected to produce as sharp encodes as x264 does?
Thanks a lot!

I did recently an encode to test the advancements so far in x265. Honestly, I'm very disappointed when it comes to retaining detail (and a bit of noise).

The same encode done with x264 looks far and I repeat FAR better than the one done with x265.

I usually know what I do when configuring the options, but I wasn't able to match the quality of the x264 encode thus far.

So I'd say it'll probably take 1-2 years for x265 to come on par with x264

[burfadel]

Try some custom options:
--rdoq-level 1
--output-depth 10
--rd 4
--tu-intra-depth 3
--early-skip
--fast-intra
--b-intra
--tskip
--tskip-fast
--limit-modes
--aq-mode 2
--qg-size 16
--me star
--max-merge 3
--weightb
--bframes 6
--ref 6
--rc-lookahead 40

Note the first entry, I use the level 1 despite people saying level 2 produces more ideal results. I agree with the help:
Psy-rdoq is less effective at preserving energy when RDOQ is at level 2, since it only has influence over the level distortion costs.

I find level 1 produces the best results. --tu-intra-depth 3 is good and there is little speed penalty (only on intra, not on inter), setting it higher than 1 on inter has little improvement at the expense of encode speed. --early-skip, --fast-intra, --tskip, --tskip-fast, and --limit-modes are all performance options with little (none for me) discernible difference in picture quality. --b-intra, --aq-mode 2, --qg-size 16, --max-merge 3, --weightb, and --rc-lookahead 40 are all quality and/or efficiency related. --bframes 6 and --ref 6 seem the most ideal for me. Any higher than about 6 b-frames their usage drops very significantly. --me star seems the highest performing motion search algorithm in both quality and is fast. It really makes UMH and even HEX redundant due to the quality of the output and speed.

Note that I have --merange set to 25 for speed at 480P content. If encoding to a higher resolution then a higher merange would be beneficial. I did read there are SAO optimisations etc in the works, they should further improve the results.

Try those settings and see how the output compares. I mean just those settings, nothing else except for stating the CRF. The CRF can also be in decimal form, such as 20.5. These settings seem to work well together for not only a fast encode but great quality ouput. If you're game try say, 400 for --nr-intra and --nr-inter. It might sound counterintuitive for what you intend, but it does reduce the file size a bit such that you can use a slightly lower CRF. The lower CRF then could produce more likeable results. Try it out on a clip, one with both of those set to 0 and another with them both set to 400 but lower the CRF by say, 0.5 and see the output quality and file size. You may be even able to lower the CRF even a tad more than that.

[microchip8]

@burfadel

Thanks for the options. I'll try them but what I used for the test encode is very close to what you provided, except for the *--skip ones which I disabled. I will do some more tweaking here...

[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.

[filler56789]

commit 17c0c875f27d @ http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2450950&viewfull=1#post2450950

Only the x64 binary is "multilib", the x86 one is 8-bit only, and is "XP-compatible" (or at least I think so, I don't have an XP machine anymore).

[Jamaika]

I found a codec creators. I should probably use them.
https://builds.x265.eu/

[hector1980]

Hi everyone i use MeGui for my X264 encoding i was wondering if there is an encoding app like Megui with that much options for Hevc X265?! Is meGui the best in X265 or there are apps with better features for x265?!

[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]

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]

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]

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?p=1767841&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]

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! :D

[x265_Project]

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]

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/posts/1703598466523898?comment_id=1703672846516460&comment_tracking=%7B%22tn%22%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 (https://www.mediafire.com/download/qqkrtwb2sy8vu8e/x265_1.9+227-836a870ba76b.7z): 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?

[pradeeprama]

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

Can you please share your command line for encoding? Also, do you see an improvement in quality?

[shinchiro]

..do you see an improvement in quality?
yes..there's some quality improvement even in low bitrate. kudos for that :D

Cli (626fcbac7ffb):
ffmpeg -i input.mkv -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m --bitrate 500 --preset veryslow --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --me umh --rdpenalty 1 --psy-rd 2.5 --recursion-skip --rc-lookahead 90 --aq-mode 2 --ref 3 --deblock -3:-3 --no-rect --no-amp --no-b-intra --no-weightb --no-psy-rdoq --no-rdoq-level --no-strong-intra-smoothing --no-sao --output output.mkv -

Cli (836a870): (rskip is enabled by default in preset veryslow)
ffmpeg -i input.mkv -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m --bitrate 500 --preset veryslow --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --me umh --rdpenalty 1 --psy-rd 2.5 --rc-lookahead 90 --aq-mode 2 --ref 3 --deblock -3:-3 --no-rect --no-amp --no-b-intra --no-weightb --no-psy-rdoq --no-rdoq-level --no-strong-intra-smoothing --no-sao --output output.mkv -

[Barough]

Have also noticed a speed drop here. Commits compared, 78ffb67 with 836a870. ~7%

Preset : Medium
Custom Command line :
--me 3 --ref 4 --aq-mode 2 --aq-strength 3 --rdoq-level 1 --psy-rdoq 5 --rc-lookahead 80 --no-rskip

[LigH]

Better compare either the same build with one option enabled and disabled, or two builds with both the same options; you may be surprised how much more changed between two releases, and then you can't decide if the reason of an output or speed difference is this one option you changed, or all the other code differences...

In such a case where the meaning of an option changed slightly, one may need to compare four tests (both builds with option enabled and disabled).

[Barough]

I have compared between 2 specific commits using the same options and using the same test files. Have run the tests 3 times each with the commits i mentioned above above and the latest commit is a little slower.

Got a friend 2 do some quick tests also and he say the same thing about the latest commit. It's slower.

[nandaku2]

Yes. At preset veryslow, if you compare the older --recursion-skip and the current --rskip (enabled by default), you will find a small loss in speed, but a huge gain in quality. Essentially, the newer rskip aims to keep the same quality as the older no-recursion-skip, without the 40%+ performance loss.

There should be no impact at medium preset though...

[littlepox]

Yes. At preset veryslow, if you compare the older --recursion-skip and the current --rskip (enabled by default), you will find a small loss in speed, but a huge gain in quality. Essentially, the newer rskip aims to keep the same quality as the older no-recursion-skip, without the 40%+ performance loss.

There should be no impact at medium preset though...

I'm a bit confused here; let's assume we use the newest stable build:

1. At preset veryslow, is --rskip set by default?
2. At preset placebo, is --no-rskip set by default?
3. At preset slower and slow, --rskip gives a huge quality gain with only a little speed decrease, true or false?
4. It is not recommended to set --no-rskip unless one don't care about time but only quality, true or false?

[LigH]

To avoid doubts, you should publish tables of results (build / options / speed), not only interpretations.

[Ma]

I'm a bit confused here; let's assume we use the newest stable build:

1. At preset veryslow, is --rskip set by default?
2. At preset placebo, is --no-rskip set by default?
3. At preset slower and slow, --rskip gives a huge quality gain with only a little speed decrease, true or false?
4. It is not recommended to set --no-rskip unless one don't care about time but only quality, true or false?

1. --rskip is set as default (with exception of placebo preset): https://bitbucket.org/multicoreware/x265/src/d574d3d5b9cf7d06113b49af60448d1de08e0e67/source/common/param.cpp?at=stable&fileviewer=file-view-default#param.cpp-167

2. At preset placebo --no-rskip is as default: https://bitbucket.org/multicoreware/x265/src/d574d3d5b9cf7d06113b49af60448d1de08e0e67/source/common/param.cpp?at=stable&fileviewer=file-view-default#param.cpp-414

[nevcairiel]

1. --rskip is set as default (with exception of placebo preset): https://bitbucket.org/multicoreware/x265/src/d574d3d5b9cf7d06113b49af60448d1de08e0e67/source/common/param.cpp?at=stable&fileviewer=file-view-default#param.cpp-167

2. At preset placebo --no-rskip is as default: https://bitbucket.org/multicoreware/x265/src/d574d3d5b9cf7d06113b49af60448d1de08e0e67/source/common/param.cpp?at=stable&fileviewer=file-view-default#param.cpp-414

To add to that, --no-rskip is also used for --tune grain.

[Barough]

Yes. At preset veryslow, if you compare the older --recursion-skip and the current --rskip (enabled by default), you will find a small loss in speed, but a huge gain in quality. Essentially, the newer rskip aims to keep the same quality as the older no-recursion-skip, without the 40%+ performance loss.

There should be no impact at medium preset though...


Well from my and my m8's tests so is there an impact on the performance when using --no-rskip with Present Medium. The loss on our tests is 3-4 FPS.

Haven't tested with the latest commit, ie a932b43 but the loss is definitely there on 1.9+227.

[littlepox]

Well, the speed loss came from the extra work in 1.9+227, described as
"analysis: compute Inter2Nx2N after merge in analysis mode=load if reuse mode chosen is skip"

[uneedme]

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



might x265 can not receive the y4m stream as a 10bit input

try add -strict -1 to set ffmpeg not to compiling strictly to the limitations.

or even use raw format (need to specify all basic perferences)

ffmpeg -i XXXXXX.XXX -an -q:v 0 -f rawvideo -pix_fmt yuv420p10le -vf scale=out_color_matrix=btX0XX -r XXXXX/100X -s XXXXxXXXX -strict -1 -| (to piping out/stdout?)

replace XXX with your proper values......


-pix_fmt yuv420p12le 12bit? -pix_fmt yuv420p16le 16bit?

[benwaggoner]

might x265 can not receive the y4m stream as a 10bit input

try add -strict -1 to set ffmpeg not to compiling strictly to the limitations.
RAW is a total pain in the arse due to its lack of metadata. Here's an example string I use for 10-bit encoding. And x265 definitely can take 10-bit .y4m input.

http://test-benwagg-materials.s3.amazonaws.com/CES/grd015_sdr_25M_10bit_crf16.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJFI2EXAAIFKNS4UA%2F20141231%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20141231T182706Z&X-Amz-Expires=604793&X-Amz-SignedHeaders=Host&X-Amz-Signature=3e70789fce79c84b390d8a8f03e1e8ec722f27ffa1999bb8fbe3ec6360eca0a0

ffmpeg.exe -i "input.mov" -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265_16bit.exe - --y4m

And you just stick the normal x265 parameters after that.

Note you need to be using a 16-bit build or the multilib build to encode 10-bit.

[uneedme]

RAW is a total pain in the arse due to its lack of metadata. Here's an example string I use for 10-bit encoding. And x265 definitely can take 10-bit .y4m input.

http://test-benwagg-materials.s3.amazonaws.com/CES/grd015_sdr_25M_10bit_crf16.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJFI2EXAAIFKNS4UA%2F20141231%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20141231T182706Z&X-Amz-Expires=604793&X-Amz-SignedHeaders=Host&X-Amz-Signature=3e70789fce79c84b390d8a8f03e1e8ec722f27ffa1999bb8fbe3ec6360eca0a0

ffmpeg.exe -i "input.mov" -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265_16bit.exe - --y4m

And you just stick the normal x265 parameters after that.

Note you need to be using a 16-bit build or the multilib build to encode 10-bit.


LOL...

Should you specify Arguments there is no pain in the Ass, it's in your fingers... lol

[benwaggoner]

LOL...

Should you specify Arguments there is no pain in the Ass, it's in your fingers... lol
...assuming I can remember what each .y4m was in height, width, fps, and color space, and don't mind adjusting my scripts to match those all the times.

Which I don't remember, and do mind :). My napkin estimate for the number of unique combinations we commonly use is... 1440!

[uneedme]

...assuming I can remember what each .y4m was in height, width, fps, and color space, and don't mind adjusting my scripts to match those all the times.

Which I don't remember, and do mind :). My napkin estimate for the number of unique combinations we commonly use is... 1440!

err...... so your napkinS are full of tiny-handwrited-digitS......

err......it is good for your handwriting...... LOL...... Have you finally found out your bank card pin? (I thought you mean that) Sorry, calculated out......

Interpol (or propably FBI) will collect those tissues sercetly and analysis them for the portland local intel for sure...... LOL

Do you recall the guys you meet daily ever with vigilant eyes.......that you feel wired......the FBI is working......

[littlepox]

A beta version of the new --tune film based on the most up-to-date stable 10-bit build:

--ctu 32 --max-tu-size 16 --crf 18 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.9 --rd 5 --psy-rd 2.0 --psy-rdoq 3.0 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing

Tweak the crf between 16~20
Comments and feedback are welcome.

[Ma]

I've updated VS 2015 to update 3 and realize that 12-bit x265 compiled with options
set CXXFLAGS=/arch:AVX /GS- /GL
hangs at beginning (before encoding, illegal instruction). VS 2015 update 2 with the same options works. VS 2015 update 3 with this options works for 8-bit and 10-bit x265.

If I compile by VS 2015u3 in debug mode it works. It could be that update 3 to VS 2015 is not perfect.

[Motenai Yoda]

Comments and feedback are welcome.
I'm not sure some speed/quality parameter like --rd 5 should be changed with a tune
Of which entity is the improvement of --rc-lookahead 80 and --no-strong-intra-smoothing on film based content?
also difference (in quality) between --rdpenalty 1/2 and --ctu 32 --max-tu-size 16?