x265 HEVC Encoder

[Ma]

After some tests it is a bug in ffmpeg (in my opinion).
Sorry for confusions.

[Jamaika]

If you use -pix_fmt yuv420p or yuv420p10 in ffmpeg it means limited range. Please use yuvj420 or yuv[B]
I know that I use x264, but...
[yuv4mpegpipe @ 000001d226440300] ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats. And using 'strict -1' also yuv444p9, yuv422p9, yuv420p9, yuv444p10, yuv422p10, yuv420p10, yuv444p12, yuv422p12, yuv420p12, yuv444p14, yuv422p14, yuv420p14, yuv444p16, yuv422p16, yuv420p16, gray9, gray10, gray12 and gray16 pixel formats. Use -pix_fmt to select one.
Could not write header for output file #0 (incorrect codec parameters ?): I/O error
Error initializing output stream 0:0 --
or
[Parsed_format_1 @ 000001587211bec0] Invalid pixel format 'yuvj420p10'
[AVFilterGraph @ 00000158714fd980] Error initializing filter 'format' with args 'yuvj420p10'
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0

[Selur]

'yuvj420p10'
try:
-vf zscale=rangein=full:range=full -strict -1 -pix_fmt yuv420p10le
this seems to work for me when using ffmpeg als decoder, but that wouldn't help when using vspipe which poisondeathray tested,..

[poisondeathray]

'yuvj420p10'
try:
-vf zscale=rangein=full:range=full -strict -1 -pix_fmt yuv420p10le
this seems to work for me when using ffmpeg als decoder, but that wouldn't help when using vspipe which poisondeathray tested,..

But you still get problems unless you use lossless, right ?

You can look at histogram classic and there is a big line artifact in the waveform; you wouldn't expect that at low crf values (maybe at high lossy quantizers)

So it's not a pipe or toolchain problem

[Selur]

But you still get problems unless you use lossless, right ?
Not really. (used crf 18 and 8bit)
https://s9.postimg.cc/xjjpx9fl7/compare_x265.png (https://postimg.cc/image/xjjpx9fl7/)
Uploaded my compare script and the files I use to my GoogleDrive (https://drive.google.com/drive/folders/1M4E3CSWSi2cTV66csIPvCKmlYXgYUVkh?usp=sharing)
Argh,.. I used crf 18 and 8bit.
-> will try again with 10bit
You are right there are still 'line artifacts' in the histogram when using 10bit.
https://s9.postimg.cc/mmie8i0jf/compare_x265_10bit_-_0.png (https://postimg.cc/image/mmie8i0jf/)

Cu Selur
Ps.: As a side note: either I'm making something wrong or x264 is totally broken when handling with pc scale video. (see: https://forum.doom9.org/showthread.php?p=1841998)

[poisondeathray]

In case it's a vpy or algorithm issue (you're using zimg/z.lib in vpy to convert back to 8bit to check at 8bit waveform) , I double checked with the vpy only also with nearest neighbor /Point instead of Bicubic - you don't get those artifacts (when going back/forth in the vpy only) ; you only get those artifacts with x264/x265 lossy encoding (and CRF 8 should be near lossless) . Lossless encoding fixes it, so it's definitely not a pipe or "toolchain" issue .

[Selur]

Lossless encoding fixes it, so it's definitely not a pipe or "toolchain" issue .
Not necessarily, lossless should be YUV4:4:4 and not YUV4:2:0.
Atm. my best guess is that these line artifacts are due to the compression, but it might be a but.

[poisondeathray]

Not necessarily, lossless should be YUV4:4:4 and not YUV4:2:0.

No; "lossless" is a relative term with respect to whatever your input is

If you have a YUV4:2:0 source, upscaling to YUV4:4:4 is not lossless (unless you use nearest neighbor to up and downscale back to YUV4:2:0)

[poisondeathray]

Atm. my best guess is that these line artifacts are due to the compression, but it might be a but.


That's what it looks like (because lossless encoding fixes it), but it's very bizarre pattern (look at the classic histogram) . Many errors congregate around a low midtone value, creating a line artifact .

[Selur]

okay, looking at the classic histogram view, I see what you mean, and I guess those might be due to compression artifacts.

[poisondeathray]

You would expect random quantization artifacts to be more random, not coalesce around 1 value.

And you would expect it to be "less lossy" or higher quality, certainly at CRF 8 .

It might have just been a "perfect storm" conditions . But do you have another clip/scene/section from that camera to test ?

[Selur]

But do you have another clip/scene/section from that camera to test ?
Sadly, no. Got it from a Hybrid user who stumbled over the problem. :)
(wrote an email to the user whether he could share some additional footage from that source)

[foxyshadis]

Never heard about it. A few threads further users advise against the use of rawvideo.

I test conveters:
ffmpeg_080518.exe -i "Color Range Test.MOV" -f yuv4mpegpipe -vf scale=1280:720:in_color_matrix=470bg:in_range=full:out_color_matrix=470bg:out_range=full,format=yuv420p10,lutyuv=val:val:val -strict -1 - |
x264-10bit.exe --demuxer y4m --muxer mp4 --input-csp i420 --input-depth 10 --input-range pc --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps 29.970 --keyint 60 --nal-hrd none
--colormatrix bt470bg --colorprim bt709 --transfer bt709 --range pc
--output "x264_420p10le_crf28_1.mp4" -
x264-10bit_2851.exe --muxer mp4 --input-csp i420 --input-depth 8 --input-range pc --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps 29.970 --keyint 60 --nal-hrd none
--colormatrix bt470bg --colorprim bt709 --transfer bt709 --range pc
--output "x264_420p10le_crf28_2.mp4" "Color Range Test.MOV"
bpgenc_0.9.8.exe -v -b 10 -f 420 -c ycbcr_bt709 -e x265 -m 9 -q 28 -o x265_420p10le_crf28.bpg rgba.png

Result of the test:
1)bad range,
2)bad range, no latest version 10bit 2901 (2018),
3)good.

Conclusion:
For me, the problem is in BT470bg.

Rematrixing YUV in swscale goes through an RGB intermediate; it's not supposed to rematrix when you pass the same value in and out, but that's my best guess as to why the histogram gains drastic peaks.

[Ma]

I want to precise -- first command line gives o1.raw with full range inside, second gives o2.raw with limited range inside:
ffmpeg -i "../Color Range Test.MOV" -vf scale=out_range=pc,format=yuv420p -f rawvideo o1.raw
ffmpeg -i "../Color Range Test.MOV" -color_range pc -pix_fmt yuv420p -f rawvideo o2.raw

Is it ffmpeg bug or it should work that way?

[poisondeathray]

I want to precise -- first command line gives o1.raw with full range inside, second gives o2.raw with limited range inside:
ffmpeg -i "../Color Range Test.MOV" -vf scale=out_range=pc,format=yuv420p -f rawvideo o1.raw
ffmpeg -i "../Color Range Test.MOV" -color_range pc -pix_fmt yuv420p -f rawvideo o2.raw

Is it ffmpeg bug or it should work that way?

It's expected

The source is yuvj420p . The "j" means full range, and it's read correctly by ffmpeg

The order matters in ffmpeg. When you use -pix_fmt yuv420p, from a yuvj420p source - that tells ffmpeg to scale full range to limited range

If you were passing 8bit in/out , there is no need for any of it -f rawvideo is enough. It's just decoding to raw video. (But the receiving application might need you to enter parameters if piping raw)

In the earlier example, it was scaling to 10bit. That's why the -vf scale was used with format. (ffmpeg does not have a yuvj420p10le or be equivalent pixel format; the "j" is only for 8bit)

[poisondeathray]

I'm going to call this issue that Selur brought up, the 8bit=>10bit , 10bit encoding a bug. Both x264 , x265 are affected. You can see similar problem on other full range DSLR clips.

This is a test video from an old 7D review
http://www.imaging-resource.com/PRODS/E7D/E7DVIDEO.HTM

Direct Link

https://www.imaging-resource.com/PRODS/E7D/FULLRES/YE7VID_1080_24_P_MVI_1908.MOV


Lossless encoding doesn't exhibit the problem, nor does the scaling to 10 back to 8 to compare in vapoursynth only - so it's not a "tool chain" issue. But as low as crf 8 still clearly shows the coalescing values.

The likelihood that you'd get something like that is extremely low for several different videos (I tested 3 so far). You'd expect some quantization errors to round up, some down, but roughly be close to the original....especially at lower quantizers or crf values... Not redistribute to aggregate around 1 value, causing a line in the waveform. In this example, it was a higher midtone

The loss logic seems the same in x264 and x265, they both exhibit the same behaviour

lossless
https://s31.postimg.cc/av74s7963/lossless.png

x265_crf8
https://s31.postimg.cc/58aru7jcr/x265_crf8.png

[foxyshadis]

I'm going to call this issue that Selur brought up, the 8bit=>10bit , 10bit encoding a bug. Both x264 , x265 are affected. You can see similar problem on other full range DSLR clips.

Another possibility: It could be an artifact of the decoder, or even of the spec. I'd check against Mainconcept, or one of the GPU encoders & decoders. x264/x265 and ffmpeg/libav are so ubiquitous that it's hard to test anything else.

[poisondeathray]

Another possibility: It could be an artifact of the decoder, or even of the spec. I'd check against Mainconcept, or one of the GPU encoders & decoders. x264/x265 and ffmpeg/libav are so ubiquitous that it's hard to test anything else.


The testing routine used by selur converted back to 8bit to compare. A native 10bit waveform does not demonstrate the problem. But it's still a bizarre aggregation, and why this occurs at CRF 8 but not lossless.

I'll swap out and double check the decoders and encoders and do some more tests when I have more time

[Barough]

x265 v2.7+351-d3b714bd5471 (http://www.mediafire.com/file/pp6c8shkc4p2he8/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/all

[Ashok Kumar Mishra]

Version 2.8
===========

Release date - 21/05/2018

New features
-------------
1. :option:`--asm avx512` used to enable AVX-512 in x265. Default disabled.
For 4K main10 high-quality encoding, we are seeing good gains; for other resolutions and presets, we don't recommend using this setting for now.

2. :option:`--dynamic-refine` dynamically switches between different inter refine levels. Default disabled.
It is recommended to use :option:`--refine-intra 4' with dynamic refinement for a better trade-off between encode efficiency and performance than using static refinement.

3. :option:`--single-sei`
Encode SEI messages in a single NAL unit instead of multiple NAL units. Default disabled.

4. :option:`--max-ausize-factor` controls the maximum AU size defined in HEVC specification.
It represents the percentage of maximum AU size used. Default is 1.

5. VMAF (Video Multi-Method Assessment Fusion)
Added VMAF support for objective quality measurement of a video sequence.
Enable cmake option ENABLE_LIBVMAF to report per frame and aggregate VMAF score. The frame level VMAF score does not include temporal scores.
This is supported only on linux for now.

Encoder enhancements
--------------------
1. Introduced refine-intra level 4 to improve quality.
2. Support for HLG-graded content and pic_struct in SEI message.

Bug Fixes
---------
1. Fix 32 bit build error (using CMAKE GUI) in Linux.
2. Fix 32 bit build error for asm primitives.
3. Fix build error on mac OS.
4. Fix VBV Lookahead in analysis load to achieve target bitrate.

[LigH]

x265 2.8+1-478bfe2b7673 (https://www.mediafire.com/file/9ni1v095jkvvhwu/x265_2.8+1-478bfe2b7673.7z) (stable release, GCC 7.3.0, Win32+Win64)

last few fixes in analysis mode

[user1085]

x265 2.8+1-478bfe2b7673 (https://www.mediafire.com/file/9ni1v095jkvvhwu/x265_2.8+1-478bfe2b7673.7z) (stable release, GCC 7.3.0, Win32+Win64)

last few fixes in analysis mode

Do you also have a Linux build?

[Sagittaire]

Version 2.8
5. VMAF (Video Multi-Method Assessment Fusion)
Added VMAF support for objective quality measurement of a video sequence.
Enable cmake option ENABLE_LIBVMAF to report per frame and aggregate VMAF score. The frame level VMAF score does not include temporal scores.
This is supported only on linux for now.


VMAF is objective metric from Netflix:
https://medium.com/netflix-techblog/toward-a-practical-perceptual-video-quality-metric-653f208b9652

Really good idea to impliment this metric. VMAF seem have really good correlation with HVS. Why not include PSNR-HVS-M (seem have really good correlation too)?

Possible to introduce tune profil for VMAF or PSNR-HVS-M like for PSNR and SSIM?

[jd17]

Possible to introduce tune profil for VMAF or PSNR-HVS-M like for PSNR and SSIM?

I would like that too! :)

[Asmodian]

Any tune profile for VMAF should probably be the default, given that it correlates very well with the human visual system. ;)

[user1085]

Anyone know how to build x265 2.8 with AVX512 enabled on Ubuntu?

I built x265 from 2.8 release tarball but x265 -V doesn't show me it's using AVX512 capability on a Intel Xeon

x265 [info]: HEVC encoder version 2.8
x265 [info]: build info [Linux][GCC 7.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

Here's the CPU info

uso@xvmub:~/x265_2.8/build/linux$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Platinum 8168 CPU @ 2.70GHz
Stepping: 4
CPU MHz: 2693.677
BogoMIPS: 5387.35
Virtualization: VT-x
Hypervisor vendor: Microsoft
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 33792K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch pti tpr_shadow vnmi ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves

[LigH]

AVX-512 is only enabled if you explicitly add --cpu avx512 to the command line; without it is not even checked for in CPU capabilities, apparently... so try:

x265 --cpu avx512 -V

Is it reported then?
__

Do you also have a Linux build?

No, I was a) quite confident that Linux users know how to install and use GNU compilers (it's good enough documented on Multicoreware's Bitbucket), and b) not sure how portable one build under one specific distro is. Windows builds are quite portable, and knowledge about compiling from sources is probably not so common among Windows users.

[user1085]

AVX-512 is only enabled if you explicitly add --cpu avx512 to the command line; without it is not even checked for in CPU capabilities, apparently... so try:

x265 --cpu avx512 -V

Is it reported then?
__



No, I was a) quite confident that Linux users know how to install and use GNU compilers (it's good enough documented on Multicoreware's Bitbucket), and b) not sure how portable one build under one specific distro is. Windows builds are quite portable, and knowledge about compiling from sources is probably not so common among Windows users.

No worries I figured out how to compile, didn't see the instructions earlier :)

Re:avx512, this worked for me
./x265 --asm avx512 -V

[LigH]

Oops, should have read the manual, "asm" instead of "cpu".

Thank you for confirming anyway.

[benwaggoner]

VMAF is objective metric from Netflix:
https://medium.com/netflix-techblog/toward-a-practical-perceptual-video-quality-metric-653f208b9652

Really good idea to impliment this metric. VMAF seem have really good correlation with HVS. Why not include PSNR-HVS-M (seem have really good correlation too)?

Possible to introduce tune profil for VMAF or PSNR-HVS-M like for PSNR and SSIM?
VMAF is our least-bad metrics, but it definitely has limitations and blind spots. It doesn't catch banding well, particularly in lower luma. It is only trained on x264 8-bit SDR, and without a lot of different psychovisual tuning, so it doesn't do a great job of discriminating between some kinds of psychovisual tradeoffs. And it's never seen the newer kind of artifacts in HEVC, so it doesn't know about customer preference between them. It doesn't know about <300 Kbps or >1080p. It was only tested against a particular display at 3x screen heights. The temporal comparison base metric is pretty weak.

It's the best thing we've got, but it definitely isn't perfect.

Also, the question of how to go from scores for individual frame to a per-clip score remains unanswered. A file that varies from 30-80 VMAF is going to be perceived as a lot worse than one that varies from 50-60, but the mean of the frames won't show any difference.

That's not a VMAF specific problem; it applies to all metrics where we are trying to figure out quality over time from individual frame metrics.

[jd17]

Wait a minute.... The Amazon video specialist does NOT think Netflix's metric is the holy grail?
I'm shocked! Shocked! :eek:
Kidding of course... I just think someone had to say it. ;)

I do think Netflix abuses VMAF findings though.
Bitrates between 2000kbit/s and 3000kbit/s for 1080p x264 video are just not good. No matter what VMAF tells you...

[LigH]

The main limit is probably a bandwidth cap; restricted VBR. Some scenes will have a demand that can't be satisfied in a streaming usage. But quality tests will often be done for a local playback usage, I guess...

[jd17]

The main limit is probably a bandwidth cap; restricted VBR. Some scenes will have a demand that can't be satisfied in a streaming usage.

Is this a comment on my complaint about the 2000-3000kbit/s?
If that is the case - I do not think bandwidth cap is a factor.
I was referring to the "highest" quality Netflix streams at 1080p for some content. You cannot get more, no matter how high your bandwidth is.
This not only used to be much higher in the past, it still is for some content with more grain.
Additionally, Amazon streams significantly higher 1080p AVC bitrates across the board, so bandwidth can hardly be a limitation...

I think it's just Netflix saving bandwidth, because most people either watch this stuff on smaller screens with a viewing distance too large, or they just do not care / do not see the flaws...
Either way - Netflix abuses it.

[nevcairiel]

The bitrate you target is really not related to the metric you use. You can use a metric to optimize encoding settings for any target bitrate to get the best out of the bits available to you.

[jd17]

You might be misunderstanding what I tried to say...
I know how metrics work.

I merely tried to point out that I think Netflix is abusing their internal VMAF findings to justify streaming at much lower bitrates.
I would argue they lowered their bitrate target (at least partly) as a result of their use of VMAF.

No matter how clean your video is, 1080p x264 will not be good at 2000-3000kbit/s, especially in the backgrounds.

Maybe you understand where I am coming from when you look at this blog:
https://medium.com/netflix-techblog/per-title-encode-optimization-7e99442b62a2

In theory, the arguments in that blog are well reasoned.
Use low bitrates for cartoons and clean video, use high bitrates for lots of movement, grain, and so on...

However, especially within the last year or so (look at recent releases of Netflix series for instance), they have moved to the aforementioned low bitrates as highest 1080p target bitrate. On live action video!

While 2000-3000kbit/s is indeed completely fine for Cartoon, it is not for live action video.

Is that VMAF's fault? Of course not.
But I think Netflix saw that the VMAF scores are not too bad for 1080p video at those bitrates, so they decided to lower their targets accordingly.


Sorry for the long off-topic discussion...
Originally, I just wanted to make a little joke and complain about Netflix's quality in the process...
I did not mean for it to drift so far away from x265! :)

[foxyshadis]

Sorry guys, this was getting way too offtrack. AVX512 vs Threadripper has been moved to the PC Hardware forum. (https://forum.doom9.org/showthread.php?t=175476)

[IgorC]

Also, the question of how to go from scores for individual frame to a per-clip score remains unanswered. A file that varies from 30-80 VMAF is going to be perceived as a lot worse than one that varies from 50-60, but the mean of the frames won't show any difference.


It was solved in HVMAF

https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

About Harmonic mean https://en.wikipedia.org/wiki/Harmonic_mean
Since the harmonic mean of a list of numbers tends strongly toward the least elements of the list, it tends (compared to the arithmetic mean) to mitigate the impact of large outliers and aggravate the impact of small ones.

P.S. It's not news at all. Geometric and harmonic means were in use since forever.

[K.i.N.G]

Hi, I have a possible request/idea.

Wouldn't it be possible to integrate a bitrate multiplier by mask (a greyscale image or video) as source? Preferably with an option to set strength/influence (so pure black doesn't always give 0% :D )
I think this would be quite useful. Not sure how difficult it would be to add.

It's just an idea, I don't want to come over as someone who 'demands' something from open source devs.

[LigH]

x265 2.8+10-a7bd0622ece5 (https://www.mediafire.com/file/3mnslai3miffxl9/x265_2.8%2B10-a7bd0622ece5.7z) (merge with stable)

several bug fixes (build errors, dyn.ref., scaled enc.)

[benwaggoner]

It was solved in HVMAF

https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

About Harmonic mean https://en.wikipedia.org/wiki/Harmonic_mean
Looks like a promising improvement, but this stuff never gets SOLVED.

Averaged over a two hour movie, a harmonic mean can still not catch periods of terrible quality.

[Midzuki]

5. VMAF (Video Multi-Method Assessment Fusion)
Added VMAF support for objective quality measurement of a video sequence.

Enable cmake option ENABLE_LIBVMAF to report per frame and aggregate VMAF score. The frame level VMAF score does not include temporal scores.

This is supported only on linux for now.

Because... ???

[LigH]

I already wondered some time before you ... maybe due to the way how libvmaf is available for and can be installed in the OS; maybe due to the way how the library can be linked.

But since I read that placing VMAF into the encoder may not be the best solution for comparable results with other encoders, I will possibly not include it in my MinGW builds, even if it would ever work at all.

[Barough]

x265 v2.8+13-617590cb8b98 (http://www.mediafire.com/file/hudywji1f680o8o/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.8+19-bcdc610cf5f0 (https://www.mediafire.com/file/7pfbi9ugf0m40ut/x265_2.8%2B19-bcdc610cf5f0.7z)

Support scale factor with analysis-reuse-level 1-6; fix build issue when using icc; add support for chunked encoding*; use the data structure of analysis-save/load for multi-pass-opt-analysis/multi-pass-opt-distortion; add vbv-end tolerance check

--chunk-start <integer> First frame of the chunk. Default 0 (disabled)
--chunk-end <integer> Last frame of the chunk. Default 0 (disabled)

* this seems to allow the output of parts of a GOP, with bitrate control beyond this GOP where required, possibly to support "smart rendering"

[Selur]

@developers: Any insight into chunked encoding and what it is meant to be for would be nice.
@LigH: sounds to me more like something meant for distributed encoding rather than 'smart rendering'.

[LigH]

--chunk-start (https://x265.readthedocs.io/en/default/cli.html?highlight=chunk#cmdoption-chunk-start) <integer>

First frame of the chunk. Frames preceeding this in display order will be encoded, however, they will be discarded in the bitstream. This feature can be enabled only in closed GOP structures. Default 0 (disabled).

--chunk-end (https://x265.readthedocs.io/en/default/cli.html?highlight=chunk#cmdoption-chunk-end) <integer>

Last frame of the chunk. Frames following this in display order will be used in taking lookahead decisions, but, they will not be encoded. This feature can be enabled only in closed GOP structures. Default 0 (disabled).

Distributed encoding can possibly be limited to GOP ranges and VBV level control. Okay, frame exact splitting may be a bonus.

[benwaggoner]

@developers: Any insight into chunked encoding and what it is meant to be for would be nice.
@LigH: sounds to me more like something meant for distributed encoding rather than 'smart rendering'.
That said, the underlying technology can be used in all sorts of way.

Selective reencoding is another obvious application.

[benwaggoner]

Distributed encoding can possibly be limited to GOP ranges and VBV level control. Okay, frame exact splitting may be a bonus.
About the bare minimum useful chunk duration is at least one GOP and practically one (vbv-maxrate+vbv_bufsize)/vbv-maxrate. The second requirement can be loosened if the system will selectively reencode chunks when a sequence of chunks would violate VBV. Short chunks without the ability to reencode means that VERY conservative VBV must be used.

Consider two chunks that are relatively easy to encode except for a big complexity spike at the split point between chunks. Using normal rate control, each chunk would get most of their bits at the split point, since neither chunk knew the other was going to stress the VBV, and so the combination causes a VBV violation.

Cutting vbv-maxrate and vbv-bufsize to half of the "real" maximum values you want can fix the problem, but has obvious quality impact for many use cases.

[Stereodude]

Is there any way to x265 to let Windows know that it's busy encoding to prevent a Windows update from rebooting the PC during an encode? I thought I read before that there's a way for an application to let the OS know it's "busy" so that it won't reboot while the application is crunching away.

Currently Windows 10 will happily reboot mid x264 or x265 encode even if the CPU is pegged at 100%.

[LigH]

This may possibly be solved easier in user interfaces; but I will forward this to the mailing list for you to lead the developers' attention here.

P.S.: I wonder if you could use the ShutdownBlockReasonCreate (https://msdn.microsoft.com/en-us/library/windows/desktop/aa376877%28v=vs.85%29.aspx) function to postpone it.