x265 HEVC Encoder

[kolak]

"-vf scale=out_color_matrix=unspecified:"

means Rec.601 by the default is used and this is not what you want for HD.

Are your PNGs really full range or YUV range?

you definitely need out_color_matrix=bt709 and establish correct range in your PNGs.
Other than this I would not use ffmpeg for conversion from RGB to YUV. Swscale seams to be buggy and I would do such a thing in avisynth or vapourysnth where you have access to very good and precise conversion engines, e.g. fmtconv.

[Jamaika]

Are your PNGs really full range or YUV range?
According my opinion it is needed. Examples:
https://www.sendspace.com/filegroup/iYDGoDc0s7Nmv%2F9A5l2PkzVEmDXSPHpJ

[qtwigg]

Hello everyone,

I am sorry for the humongous pics, that was my first posting and was not aware.

Thank you for the replies but we misunderstood each other. Those screens are basic screenshots, PNGs lossless 32bit, made with Video Thumbnails Maker Platinum 9.0. All I did was screen compares with my output v input. I feel my encoded screenshot has off colours, so I played around with my command line and I think I posted all the needed info of what I tried.

Any advice/feedback and criticism is greatly appreciated.

Thanks.

[mandarinka]

Yeah, that looks like bt709/bt601 mismatch to me too (which means, the problem is not in encoding, but in the conversion to RGB). Swscale in FFmpeg likely uses bt601 by default, it is not the only problem with it.

I would stay away from it also for the reason that it only does nearest neighbour chroma upsampling unless you give it some arcane flags that are impossible to memorize (and dunno if even exposed from CLI).

[youli]

I adjusted some settings (as compared with my sample above (http://forum.doom9.org/showthread.php?p=1776850#post1776850)) for better preserve grain at the dark scenes.
--crf 23.5 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40 --aq-mode 3 --aq-strength 0.4
--no-sao --no-deblock --rd 3 --psy-rd 1.7 --b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 --lookahead-slices 6 --qpstep 1
--no-strong-intra-smoothing --no-rskip --no-cutree
Source BD3D (left view) and x265 OverUnder:
http://s020.radikal.ru/i707/1608/ce/5ddc9b3260bft.jpg (http://s020.radikal.ru/i707/1608/ce/5ddc9b3260bf.png) http://s09.radikal.ru/i182/1608/26/548f323a25bdt.jpg (http://s09.radikal.ru/i182/1608/26/548f323a25bd.png) http://s018.radikal.ru/i506/1608/dd/2a1db3864aect.jpg (http://s018.radikal.ru/i506/1608/dd/2a1db3864aec.png) http://s019.radikal.ru/i623/1608/e8/256d36ede1ebt.jpg (http://s019.radikal.ru/i623/1608/e8/256d36ede1eb.png)
http://s019.radikal.ru/i642/1608/65/e25430d7e8c3t.jpg (http://s019.radikal.ru/i642/1608/65/e25430d7e8c3.png) http://s017.radikal.ru/i415/1608/d2/31a0caaa0eddt.jpg (http://s017.radikal.ru/i415/1608/d2/31a0caaa0edd.png) http://s16.radikal.ru/i190/1608/5f/26c66574fccdt.jpg (http://s16.radikal.ru/i190/1608/5f/26c66574fccd.png) http://s017.radikal.ru/i403/1608/b0/840e6786eb57t.jpg (http://s017.radikal.ru/i403/1608/b0/840e6786eb57.png)
http://s018.radikal.ru/i524/1608/b8/ee0ea2b91420t.jpg (http://s018.radikal.ru/i524/1608/b8/ee0ea2b91420.png) http://s017.radikal.ru/i405/1608/58/4ac002940fe8t.jpg (http://s017.radikal.ru/i405/1608/58/4ac002940fe8.png) http://s010.radikal.ru/i312/1608/b5/6b68f001c15ft.jpg (http://s010.radikal.ru/i312/1608/b5/6b68f001c15f.png) http://s017.radikal.ru/i422/1608/0f/273659fa73e2t.jpg (http://s017.radikal.ru/i422/1608/0f/273659fa73e2.png)

x265 log:
x265 [info]: HEVC encoder version 2.0+10-5a0e139e2938
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: Specifying a decoder level with constant rate factor rate-contro
l requires
x265 [warning]: enabling VBV with vbv-bufsize=100000kb vbv-maxrate=100000kbps. V
BV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(68 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 25 / 7 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.4 / 32 / 0
x265 [info]: Rate Control / qCompress : CRF-23.5 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: rd=3 psy-rd=1.70 rdoq=1 psy-rdoq=2.50 early-skip tmvp
x265 [info]: tools: fast-intra lslices=6

x265 [info]: frame I: 2013, Avg QP:21.57 kb/s: 27922.65
x265 [info]: frame P: 37388, Avg QP:22.69 kb/s: 16473.71
x265 [info]: frame B: 131623, Avg QP:22.75 kb/s: 10242.93
x265 [info]: consecutive B-frames: 13.3% 5.7% 6.5% 30.0% 11.6% 18.3% 14.6%

encoded 171024 frames in 72336.41s (2.36 fps), 11813.15 kb/s, Avg QP:22.73
Encoding finished 14.08.2016 5:48:22,71

@brumsky
What's the point of using VBV with such high values? With a value of 100000 Kbps it'll almost never kick in...
Example to your question about VBV. See peak bitrate in the green rectangle at the picture below (about 67 Mbps), and average bitrate for this video is about 8 Mbps only.
http://s41.radikal.ru/i091/1608/55/d37738d2c4f9t.jpg (http://s41.radikal.ru/i091/1608/55/d37738d2c4f9.png)

[burfadel]

I adjusted some settings (as compared with my sample above (http://forum.doom9.org/showthread.php?p=1776850#post1776850)) for better preserve grain at the dark scenes.
[CODE]--crf 23.5 --preset ultrafast --level-idc 5 --high-tier --me umh --subme 7 --scenecut 40 --aq-mode 3 --aq-strength 0.4
--no-sao --no-deblock --rd 3 --psy-rd 1.7 --b-adapt 2 --ctu 32 --min-cu-size 8 --rc-lookahead 40 --bframes 6 --merange 25
--ipratio 1.1 --pbratio 1.0 --qcomp 0.8 --rdoq-level 1 --psy-rdoq 2.5 --lookahead-slices 6 --qpstep 1
--no-strong-intra-smoothing --no-rskip --no-cutree

Mixing ultra fast preset with slow settings? It's a bit askew. Although I don't believe ip and pb ratio's are tweaked ideally (I found 1.28 and 1.38 ideal), setting them as low as you have throws everything else out, as you are still targeting a specific CRF. Setting things like psy-rdoq too high just disproportionally increases bitrate used, you could probably get better results with the same file size using a lower CRF and lower psy-rdoq settings.

[youli]

@burfadel
Ultrafast preset need to disable a harmful options for encoding speed :)
--psy-rdoq 2.5 minimizes the grain blurring effect of dark areas (here (http://forum.doom9.org/showthread.php?p=1776850#post1776850) it was even 3.0) and --aq-strength down to 0.4 too. This video has rate factor 0.116 [ 'Bits-per-second' / ('Pixels-per-frame' * 'frame-rate') ], I think it a very good compression, is really need more... 0,08 or 0,05? ;)
In this case need to use full 2 pass encode instead CRF and up "Avg QP for frame B" to 27-28.

Also you can see grain tune http://x265.readthedocs.io/en/latest/presets.html#film-grain

[Motenai Yoda]

See peak bitrate in the green rectangle at the picture below (about 67 Mbps), and average bitrate for this video is about 8 Mbps only.
vbv works on an interval of 1 sec, peak bitrate can be of only 1 frame (1/fps second), so you can still get 67Mbps with vbv on 10Mbps
btw 67Mbps is still pretty less than 100Mbps, better don't use vbv and level at all if you don't want any vbv degradation

[benwaggoner]

On a different note.

How does everyone else handle video with intentional noise, for example BSG or The Walking Dead? I've found those to have very high bitrates even with the below settings. I've seen it spike to 22000 Kbps! I'd like to target between 2000 - 4000 on average but I don't want to force it across the board by using 2 pass. If a scene needs a little extra that's fine but 10,000 to 20,000 Kbps is to high for my likes...

--crf 20 --profile main10 --output-depth 10 --ctu 32 --bframes 6 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --rect --no-amp
--limit-modes --max-merge 3 --early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 2 --aq-strength 1 --cutree --rd 4 --tu-intra-depth 3
--tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1.28 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

How about just "--crf 20 --profile main10 --preset slower --tune grain" and see how that goes. You're doing a lot of stuff to preserve sharpness, and preserving sharpness in content with a lot of random noise means really high bitrates. With tune grain you can get more preservation of the texture with rate control. So lower bitrates get a little more DCT-ish, but you don't lose the grain or get grain strobing or variance across a frame. You'd probably want to start out with the rest of your tuning (even CRF), since you're starting from a very different place, a lot of stuff doesn't apply any more, and you've got --rc-grain on. The downside is that tune grain turns off all sorts of nice psychovisual stuff, so clean scenes will use a higher bitrate for the same perceptual quality. But if the whole title is mostly noisy, give it a shot.

Setting --vbv-bitrate and --vbv-maxrate to what you want the sane values to be is also a good option. The grainy scenes might not look quite as good, but at the same ABR, the rest of the encode could look a lot better.

And in general, don't expect to see huge file size savings from x265 with content with a lot of random noise. Entropy is entropy. The cleaner the content, the more x265 can do beyond older codecs.

[plane]

Quick question, why does x265 preset doesn't make use of b-adapt 1(fast)?
All presets either use 0(none) or 2(full). Is there anything wrong with 1(fast)?

In my experiences, x265 B-frame is much more mature and good quailty compared to x264, the same is cutree(mbtree in x264). They have start from scratch and rewrite the code.

B-adapt=1 meant to be carefully to use b frames while B-adapt=2 will use whole lots more. I mostly encode real live action video and in the past, I always need to use B-adapt=1 or disable B frames(mbtree is always off too in x264) to get constant quality and less artifacts.

In x265 I found in most cases, B-adapt=2 and cutree=1 is doing good. Only for some really bad shooted real live video, however, disable b frames and cutree still offer overall better quality.

[plane]

"speed" certainly x264.
-
benefit cost (quality + size) = x265 .

I would like to say speed might be on x265 side now. After 2.0 the qualty and speed been improved. I only need to run medium or slow preset and always return me an excellent quailty video, encoding time should still 2x~3x more but file size cut in half and yield better quality.

The most goodies is saved me a lots of testing time bcoz x265 offers a more constant quality and I don't need to do many pre-encoding for any of my important videos which is very time consuming to try every possible options to get the best or balanced quality out, saved me like 10x time here.

[plane]

I went back and played with x264 a bit and I'm shocked to see the quality difference is far more noticeable then I ever remember. I know my tests weren't apples to apples but I tried x265 medium vs x264 slow + slower. In both cases x265 quality was noticeable better even when in motion.

My question, is x265 worth it has been answered! :)


I'm really shocked too when I tried x265 now. My last post on doom9 is like year 2008 ...lol... and after that x264 started mature so I don't go here often again(I don't have as much videos to encode like you guys here, just little random real live action vid stuffs).

I think the current stage of x265 is almost the same x264 in the year 2008 around. Low and medium bitrate should win easily and x264 only better at very high bitrate to keep grains, pretty much the same situation in the old day as x264 vs Xvid.

But things is a bit different here. x264 is a very success codec and being used widely as opposite Xvid was only a toy like codec(mainstream still using MPEG-2 at that time). So, it will take longer time for x265 to replace x264 and I don't see many guys talking x265 on net bcoz people generally still very satisfied with H264.

[Magik Mark]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

[plane]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

By default, x265 been removed quite a lots of grain. If you really need it during encoding, either increase deblock filter level or use a relatively low preset(will throw more noise/grain) should help but the best way always is running an external filter before you encode it, x265 isn't a denoise/grain filter.

[Motenai Yoda]

Guys is there a way to minimize or eliminate video grain during encoding?


Sent from my iPhone using Tapatalk

You can try using --nr-intra and --nr-inter whose cut high frequencies detail in and between frames

[Magik Mark]

You can try using --nr-intra and --nr-inter whose cut high frequencies detail in and between frames



Thanks. What would be an ideal value for light, moderate and heavy for startup?


Sent from my iPhone using Tapatalk

[plane]

Thanks. What would be an ideal value for light, moderate and heavy for startup?


Sent from my iPhone using Tapatalk

Seriously, no one would like to use encoder acting as a filter on doom9. If you are new to encoding stuffs, why not use StaxRip to encode x265? Just click on Filters menu and there are some denoise/grain filter available.

[burfadel]

Seriously, no one would like to use encoder acting as a filter on doom9. If you are new to encoding stuffs, why not use StaxRip to encode x265? Just click on Filters menu and there are some denoise/grain filter available.

It's an extremely light denoiser, if you want to actually denoise a noisy clip using avisynth filters makes sense. However, if you would like to remove just a tad amount of noise without actually impeding on the picture too much, it's useful. In CRF mode you can lower the CRF a bit and maintain a similar file size, the end result can actually be a better picture.

[JohnLai]

In my experiences, x265 B-frame is much more mature and good quailty compared to x264, the same is cutree(mbtree in x264). They have start from scratch and rewrite the code.

B-adapt=1 meant to be carefully to use b frames while B-adapt=2 will use whole lots more. I mostly encode real live action video and in the past, I always need to use B-adapt=1 or disable B frames(mbtree is always off too in x264) to get constant quality and less artifacts.

In x265 I found in most cases, B-adapt=2 and cutree=1 is doing good. Only for some really bad shooted real live video, however, disable b frames and cutree still offer overall better quality.

For animation material, B-adapt=1 only make use up to 6 B-frames for most of time while B-adapt=2 generally can allocate up to 16 B-frames.
The only problem, B-adapt=2 with 16 B-frames cause 30-50% decrease in encoding fps with only 20% better space efficiency.

[burfadel]

I guess for animation you could increase the b-frame bias a bit. By doing so you could have a much greater number of b-frames. Between around 7 b-frames and 16 b-frames on normal bias, I doubt there would be a 20 percent efficiency increase.

[brumsky]

How about just "--crf 20 --profile main10 --preset slower --tune grain" and see how that goes. You're doing a lot of stuff to preserve sharpness, and preserving sharpness in content with a lot of random noise means really high bitrates. With tune grain you can get more preservation of the texture with rate control. So lower bitrates get a little more DCT-ish, but you don't lose the grain or get grain strobing or variance across a frame. You'd probably want to start out with the rest of your tuning (even CRF), since you're starting from a very different place, a lot of stuff doesn't apply any more, and you've got --rc-grain on. The downside is that tune grain turns off all sorts of nice psychovisual stuff, so clean scenes will use a higher bitrate for the same perceptual quality. But if the whole title is mostly noisy, give it a shot.

Setting --vbv-bitrate and --vbv-maxrate to what you want the sane values to be is also a good option. The grainy scenes might not look quite as good, but at the same ABR, the rest of the encode could look a lot better.

And in general, don't expect to see huge file size savings from x265 with content with a lot of random noise. Entropy is entropy. The cleaner the content, the more x265 can do beyond older codecs.

Thanks I'll give it a try and let you know!

[plane]

It's an extremely light denoiser, if you want to actually denoise a noisy clip using avisynth filters makes sense. However, if you would like to remove just a tad amount of noise without actually impeding on the picture too much, it's useful. In CRF mode you can lower the CRF a bit and maintain a similar file size, the end result can actually be a better picture.

Those --nr-intra and --nr-inter will slightly softed the picture but it's a good light denoiser for fastest speed with minimal impact. Personally, I prefer external denoiser bcoz they've got more options to tweak or fft3dfilter for the best quality.

x265 by default been removed quite a lots of grain/noise. I've got some bad shooted real live action video and I don't think I need any denoiser again unlike x264. Completely rip off all grain/noise should futher improve the compression efficiency but may lead to worse visual quality like too much flat area or blocks.

[plane]

For animation material, B-adapt=1 only make use up to 6 B-frames for most of time while B-adapt=2 generally can allocate up to 16 B-frames.
The only problem, B-adapt=2 with 16 B-frames cause 30-50% decrease in encoding fps with only 20% better space efficiency.

It is normal. The higher the value the smaller improvement you got and will increase encode/decode time, pretty much same for all other encoding options.

[burfadel]

Those --nr-intra and --nr-inter will slightly softed the picture but it's a good light denoiser for fastest speed with minimal impact. Personally, I prefer external denoiser bcoz they've got more options to tweak or fft3dfilter for the best quality.

x265 by default been removed quite a lots of grain/noise. I've got some bad shooted real live action video and I don't think I need any denoiser again unlike x264. Completely rip off all grain/noise should futher improve the compression efficiency but may lead to worse visual quality like too much flat area or blocks.

That's why I believe it shouldn't be used by itself. Because it does save a little bitrate I think upping the psy-rdoq (if it's any higher than around 1.28 I found it's not worth upping), or lowering the CRF by a couple of decimal points, you can put that saved bitrate to use elsewhere.

[Magik Mark]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

[LigH]

Once again the same question, already answered several times...

The parallelizability of the HEVC algorithm in general (not specific to x265 as encoder implementation) is limited. There are several steps which have to be finished before other steps can start calculations. These intermediate results make some threads wait for others. This is more obvious when a slower preset takes more efforts. Spending more threads on only one video would be counterproductive, as each thread would then have a more limited scope on smaller parts of the video, reducing the efficiency.

If you have a high number of available cores, the best way to utilize them well is running several instances of the encoder in parallel.

[Magik Mark]

Thank you. My apologies for any redundancy


Sent from my iPhone using Tapatalk

[microchip8]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

have you tried --pme and --pmode ?

[burfadel]

Guys what are your experience on 2pass encoding slow and medium preset, 10bit, aq=3 and "no slow first pass"?

I have a 28 threads xeon cpu and I get the ff:

Medium preset -> undot -> f3dk -> interframe
first pass 34fps (CPU usage 70% to 90%)
second pass 24fps (CPU usage 70% to 90%)

Slow preset-> undot -> f3dk -> interframe
first pass 30fps (CPU usage 70% to 90%)
second pass 7fps (CPU usage is only 50%)

Why is it there's significant difference in speed and CPU usage in slow preset? Maybe it is literally "slow"? How about the CPU usage? It is so underutilized

What resolution are you encoding to?

[benwaggoner]

have you tried --pme and --pmode ?
Pmode seems very likely to help. With 28 threads, pme isn't likely to be much help except with VERY low resolution and frame threading off.

[Magik Mark]

What resolution are you encoding to?



1080p


Sent from my iPhone using Tapatalk

[tebugg]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

[MeteorRain]

abr can almost never beat crf or 2pass. I'd say it's pretty stable on file size when encoding similar contents. So just stick with a good crf number for multiple movies would be a better idea.

[Jamaika]

if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12?
I shouldn't answer, because I'm lost in this thread who wants what.
My guess is that you're thinking about movies FullHD 25-30fps, I don't know only whether the memory stick or bluray. If memory stick is what a impediment ±100MB. There are calculators that calculate of the size file. Maxbitrate and buffer adjusted to the capabilities TV
I wouldn't complain about the ABR. The Speed encoding depends on the processor. More worried banding.
http://3.bp.blogspot.com/-peXsHThHJTk/VAnfLQCGEKI/AAAAAAAABI8/KF8YopmsLj4/s1600/SD%2BCard%2BTypes.PNG

[plane]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

Put it simple. abr(average bitrate) is more likely a constant bitrate. If you use ultra high bitrate(not 5000kb that's small) and prefer a very constant overall picture quality for special reasons, then it's good. If you don't have enough bitrate, crf is better.

crf is variable bitrate and only depened by given quality and the complexity of the source, it won't care about file size. 2pass is also variable bitrate but very stricted by file size manner, if file size limitations is your concern you should use 2pass with --no-slow-firstpass to enable first pass turbo mode.

[JohnLai]

Just asking...does x265 already adapt x264 new b-adapt=1 algorithm code?

http://git.videolan.org/?p=x264.git;a=commitdiff;h=aa26e880bc2cd04cc81c776051d5e21d03fc975a
Changelog
Roughly the same speed as before but with significantly better results,
comparable to --b-adapt 2.

[plane]

Just asking...does x265 already adapt x264 new b-adapt=1 algorithm code?

http://git.videolan.org/?p=x264.git;a=commitdiff;h=aa26e880bc2cd04cc81c776051d5e21d03fc975a
Changelog
Roughly the same speed as before but with significantly better results,
comparable to --b-adapt 2.

There is no need to do that. x265 b frames got better quality and it's safe to use adapt 2 all times.

x264 b frames isn't mature in my opinions, more safely to use adapt 1.

[Jawed]

I've got live action video (688p) encoded using crf 24 and:

--preset very slow --output-depth 10 --merange 38

which causes moving water to be rendered with a glitchy motion.

This preset enables eight B frames. Cutting the video to just a few seconds (the water is shown for about 130 frames) produces:

consecutive B-frames: 11.5% 0.0% 11.5% 11.5% 7.7% 3.8% 3.8% 50.0% 0.0%

If I change the preset to slow, the problem is significantly reduced:

consecutive B-frames: 8.1% 8.1% 8.1% 18.9% 56.8%

Additionally, if I change the encode to:

--preset very slow --output-depth 10 --merange 38 --bframes 4

I get:

consecutive B-frames: 7.7% 17.9% 7.7% 12.8% 53.8%

which solves the problem.

Alternatively, instead of setting --bframes, I have to reduce crf to about 20 before the water stops being glitchy.

So my question: apart from setting -bframes to 4, is there another way to control this behaviour, making x265 less likely to over-use B-frames in a situation like this?

[Motenai Yoda]

Put it simple. abr(average bitrate) is more likely a constant bitrate. If you use ultra high bitrate(not 5000kb that's small) and prefer a very constant overall picture quality for special reasons, then it's good. If you don't have enough bitrate, crf is better.
Nope abr try to arrange datarate around the average value imposed.
It don't give a more constant picture quality than crf, and for sure isn't nearby as a constant bitrate, indeed is a variable bitrate mode.

[microchip8]

x264 b frames isn't mature in my opinions, more safely to use adapt 1.

Bullshit. Got any empirical evidence to back up that claim? And no, "it doesn't look good to me" is not empirical evidence. x264 is a tried-and-tested-in-all-aspects encoder, one of the best around. if it had any B-frames issues, it will suffer quality-wise too and devs will fix it long time ago

[RainyDog]

hello everyone. i've been following this thread for awhile now and i've learned a lot from all of your testing and suggestions. i have a question. if i feed ABR enough bitrate, lets say around 5000kb/s, will ABR produce an encode with blocks or artifacts in x265 v2.0+12? only reason i ask is because abr allows me to control the file size. i've been using crf but i have file size limitations i am using. i am having trouble staying in the ball park of the size with crf. and 2pass takes way too long. i guess what i'm asking is, is x265's ABR a really bad idea?

edit: so i tried abr on a 2 hour movie. holy smokes. the encode took 13 hours. in crf mode that same encode would normally take 6-7 hours. not using abr anymore. but i did check the quality of the encode and i must say it looked very good. just with the eye test it looked as good as crf to me. guess i'll stick with trying to find a crf value per movie that gets to around the file size i want. just wish i knew a decent enough way to try and calculate this.

Tebugg, I always run a quick and dirty CRF encode with x264 first to find out the approx CRF value for my archival x265 encode.

Using me=hex, subme=2 or 3, trellis=0 for speed but keeping other parameters such as number of b-frames, lookahead values, qcomp, weight-p and b etc. the same as my x265 settings to keep things as similar on paper as I can between the two. With those settings, I can get anywhere between 20-35fps on my i7 3770k depending on input and output bitrate. So rarely takes much longer than realtime really.

The majority of the time, the bitrate of my archival x265 encode ends up within +/-20% of the x264 test encode at the same CRF.

[plane]

Bullshit. Got any empirical evidence to back up that claim? And no, "it doesn't look good to me" is not empirical evidence. x264 is a tried-and-tested-in-all-aspects encoder, one of the best around. if it had any B-frames issues, it will suffer quality-wise too and devs will fix it long time ago

No doubt it's only my opinion but I don't think I'm talking bullshit really. x264 b frames done his job but x265 just much more improved in this area. I don't see any conflict or against to x264.

[plane]

I've got live action video (688p) encoded using crf 24 and:


Live action video is very sensitive to b frames, that's what I said x264 b frames isn't as mature as x265 in previous reply. In x264, I usually need to set adapt 1 or disable b frame for live action video. And in x265, yes I'm using four b frames too.

If you still want to use eight b frames, you can set the pbratio to 1.0 or 1.1 should solve the problem but greatly reduced the efficiency of b frames.

[brumsky]

Has anyone messed with --bframe-bias?

I've been considering increasing the bias to get more b frames, hopefully consecutively. The idea being instead of using 8 bframes, just increase the bias to use more in general.

I currently use 6 bframes and see that 3 & 6 bframes general have the highest percentage. I'd like to see something like 5 & 6 consecutive bframes be the highest, for example.

thoughts?

This is from the docs.


--bframe-bias <integer>
Bias towards B frames in slicetype decision. The higher the bias the more likely x265 is to use B frames. Can be any value between -90 and 100 and is clipped to that range. Default 0

[microchip8]

No doubt it's only my opinion but I don't think I'm talking bullshit really. x264 b frames done his job but x265 just much more improved in this area. I don't see any conflict or against to x264.

Stop talking BS about maturity of b-frames in x264, which are very well implemented. What you're talking about is where x264 is placing them, according to b-adapt 1 or 2

[benwaggoner]

The majority of the time, the bitrate of my archival x265 encode ends up within +/-20% of the x264 test encode at the same CRF.
Do you find reliable equivalent quality with the same CRF between x264 and x265? What CRF values and what sort of content are you testing with?

[tebugg]

so if i do the normal 2pass on medium setting way with these as my settings:

--profile main10 --no-sao --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --merange 44 --weightb --aq-mode 2 --aq-strength 1.0 --rd 4 --psy-rd 1.5 --psy-rdoq 3 --rdoq-level 1 --weightp --qcomp 0.8 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

the total time for both passes ends up taking me about 10 hours. i am encoding from 1080p retail bluray source. i have an i7-3770k overclock to 4.5ghz that runs with no issue with cores @ 100% for 10 hours straight. i was tinkering around with the 1pass 2pass setting in megui. i was thinking if i took the x264 approach of lowering settings to get a fast first pass then my own settings on the 2nd pass, how would the quality look. so i lowered the preset to ultrafast for the first pass and only set these in the command line for the first pass:

--profile main10 --no-sao --no-strong-intra-smoothing --ctu 32 --max-tu-size 16 --qg-size 16 --no-rect --no-amp

i get 26-28 fps in the first pass that way. in the second pass i have these as my settings with the preset still on ultrafast:

--profile main10 --no-sao --me 2 --subme 4 --weightb --b-adapt 2 --rd 4 --aq-mode 2 --rc-lookahead 20 --merange 44 --ref 3 --qcomp 0.8 --psy-rdoq 3 --rdoq-level 1 --no-strong-intra-smoothing --psy-rd 1.50

i've done 2 10min clips of 2 diff movies. i must say the quality of them is looking really good. the reason why i keep the second pass at ultrafast is because x265 will error on the second pass if you change the b or p frames number. those 2 have to be the same as the first pass. any other settings you can crank up for the 2nd pass. with this method i'm getting a full movie encode of around 6 hours. much better than 10 hours. i've ran 10min clips of the same frames for the regular 2pass setting and the 1pass 2pass i am doing to see if i notice any quality diffference. to be honest it's hard for me to tell the difference. i have an untrained eye. and even when i pause the clips frame for frame they still look the same to me as far as blocking goes and grain and quality.

have any of you played around with x265 1pass 2pass in this way? if so what were your results?

[plane]

Stop talking BS about maturity of b-frames in x264, which are very well implemented. What you're talking about is where x264 is placing them, according to b-adapt 1 or 2

It is doing fine for anime or movie, not live action video at least in my own opinions. You stop BS, there is no such perfect encoder in the world. If your concept is correct of x264 is already the best encoder for human being that can be achieved, we won't need x265 or any other improvement now. Like I have said it, x264 done his job but x265 just improved. I don't see any wrong here, if you just so love x264 plz leave x265 board.

[LigH]

HEVC is not just "an improvement of AVC", it is a whole new generation with a magnitude higher complexity. Experiences from the x264 development may or may not get adapted easily for the x265 development, differences in the algorithms may require substantially different approaches sometimes. I am no developer, I can't tell you how much B-frame decisions are similar... But I can tell you that personal insults are not welcome here, according to the forum rules.

[microchip8]

It is doing fine for anime or movie, not live action video at least in my own opinions. You stop BS, there is no such perfect encoder in the world. If your concept is correct of x264 is already the best encoder for human being that can be achieved, we won't need x265 or any other improvement now. Like I have said it, x264 done his job but x265 just improved. I don't see any wrong here, if you just so love x264 plz leave x265 board.

I'm not implying nor did I ever mention x264 was perfect, but it is one of the best around. I'm saying that the b-frames implementation in x264 is just fine and has no "immaturity" issues. B-frames are very well implemented. You don't have to take my word on this, look at the code yourself

What you don't seem to get is that you're confusing yourself with the implementation of b-frames (calling them "not mature") but the actual issue lies in where x264 choose to use them, which can be controlled with b-adapt among others

so in the end you're mixing the b-frames implementation with b-frames placement decision, but you blame the b-frames implementation itself not the placement algorithm. Those are two different things, even if they are very much related