x265 HEVC Encoder

[pradeeprama]

Originally Posted by shinchiro

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]

Originally Posted by pradeeprama

..do you see an improvement in quality?

yes..there's some quality improvement even in low bitrate. kudos for that

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]

Originally Posted by 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...

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]

Originally Posted by littlepox

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/...#param.cpp-167

2. At preset placebo --no-rskip is as default: https://bitbucket.org/multicoreware/...#param.cpp-414

[nevcairiel]

Originally Posted by Ma

1. --rskip is set as default (with exception of placebo preset): https://bitbucket.org/multicoreware/...#param.cpp-167

2. At preset placebo --no-rskip is as default: https://bitbucket.org/multicoreware/...#param.cpp-414

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

[Barough]

Originally Posted by 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...

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]

Originally Posted by 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

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]

Originally Posted by uneedme

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.ama...e3ec6360eca0a0

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]

Originally Posted by benwaggoner

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.ama...e3ec6360eca0a0

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]

Originally Posted by uneedme

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]

Originally Posted by benwaggoner

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

Originally Posted by littlepox

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?