x265 HEVC Encoder

[dipje]

So the slowdown-bug actually came in the source _AFTER_ 1.7-2 ? That would make LigH's build (as example) still ok, right?

Would be nice if a problem is stated (as now) that there is a link or at least a commit-number or something where the problem crept in (or in this case, what the last known good version was).

It's not clear to me now if the last known good version is in the 1.6 milestone-branch or if there actually is a good '1.7' at all :)

edit: and if the problem is really what Ma is talking about, that means the slowdown is around 1%.. not really making it 'unusable' or anything :)

[x265_Project]

So the slowdown-bug actually came in the source _AFTER_ 1.7-2 ? That would make LigH's build (as example) still ok, right?

Would be nice if a problem is stated (as now) that there is a link or at least a commit-number or something where the problem crept in (or in this case, what the last known good version was).

It's not clear to me now if the last known good version is in the 1.6 milestone-branch or if there actually is a good '1.7' at all :)

edit: and if the problem is really what Ma is talking about, that means the slowdown is around 1%.. not really making it 'unusable' or anything :)
The commit I'm referring to is 61a6bc5 (https://bitbucket.org/multicoreware/x265/commits/61a6bc52debfc21515f6bb4729bb0201c89f196a).

On my Core i7 4700HQ (quad core Haswell) notebook I'm seeing speeds that are average ~ 30% slower than earlier builds. This is just with a simple constant QP sweep, using different performance presets (ultrafast, superfast, veryfast, fast, medium, slow, veryslow). Our engineers weren't able to replicate this on a Haswell desktop (Core i7 4770K). Your feedback on speeds before and after this batch of commits (early Wednesday morning, US time) is appreciated. Is it just me, or can anyone else replicate this issue?

Tom

[Barough]

Desktop PC w/ Core i7-4930K


Preset Medium
ABR 500kbit
Custom Command Line : --me 3 --aq-mode 2 --aq-strength 3


x265_1.6+412-b642b3d8cc1e (LigH)
16 min 5 secs 44,67 FPS


x265_1.7+2-d7b100e51e82 (LigH)
15 min 58 sec 44.96 FPS

[x265_Project]

Thanks Barough. I really appreciate the sanity check.

I found the problem. My local CMAKE config was still pointing to a test repository, and messing up my build. False alarm... crisis averted... situation normal. Sorry for the scare. All is well... nothing to see here... move along.

Tom

[Barough]

YW Tom :)

[dipje]

Even the best make small mistakes :P

[divxmaster]

x265.1.6.360 (meteor_rain) 10.12fps
x265.1.7.37 (meteor_rain) 11.69fps

1000 frames, 480p, crf28.

so good speed increases in this example for me.
Size of 1.7 was .06% smaller.

Cheers,
Divxmaster

[burfadel]

I notice that the info is a little different? What does the following mean?
x265 [info]: References / ref-limit cu / depth : 6 / 0 / 0

I know the 6 is reference frames, I'm referring to the 0's.

[foxyshadis]

Both of those are only set if --limit-refs is used, an option that tries to speed up encoding by only checking references that sort-of matched at 64x64 for the smaller partitions. You can usually use a couple more references for free, considering encoding-speed, for only a tiny loss of efficiency (and a gain if those extra references help enough).

[nandaku2]

x265.1.6.360 (meteor_rain) 10.12fps
x265.1.7.37 (meteor_rain) 11.69fps

1000 frames, 480p, crf28.

so good speed increases in this example for me.
Size of 1.7 was .06% smaller.

Cheers,
Divxmaster

Yes, we're seeing good performance increases at the fast and medium preset, because the early outs are now effective more often (depending on content).

[Ely]

I was recently testing slow vs slower and noticed a big decrease in quality in slower mode. Namely what I would call "ghosting", such as what happens on a cold screen where pixels can't update fast enough during movement.

So I did some digging by enabling all the new functions that appear from slow to slower one by one, and the culprit happens to be rd=5 (from rd=4).
In the 3 frames below, look at the guy with a purple shirt, brown pants and green beer in his hand.

I'm using 1.7+37-dc4fcfc574ade14e - 8-bit

slow - 1 (http://i.imgur.com/wbKoNce.png)
slow - 2 (http://i.imgur.com/myVgGxy.png)
slow - 3 (http://i.imgur.com/zn0uWr4.png)

slow - RD=5 - 1 (http://i.imgur.com/dFkv5aE.png)
slow - RD=5 - 2 (http://i.imgur.com/0IplpQ5.png) <== this is where it happens
slow - RD=5 - 3 (http://i.imgur.com/1cCBbQ4.png)

As you can see, the rd-5 version has severe "ghosting". It may not seem much, but this is repeated several times during this guy's movement, and the video in itself looks very sluggish when played at 24fps.
This is not the only person it happens to, anything with movement basically gets hit (more or less severely) by this artifact in the whole encode.

Can anyone confirm this ?

I'm gonna hold off rd=5 for the moment.

[easyfab]

@Ely

IMHO You should post to the mailing list at x265-devel@videolan.org to acces directly the developpers and have a faster answer or create an issue https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

[Ely]

Aye, I'll create an issue, but since a lot of experienced users & x265 devs visit this thread, I thought it'd be good to post here too :).

[Gravitator]

This phantom can be linked with technology b-frame prediction mode. Similarity in x264 > http://files.neolabs.kz/fl/?id=2092
Original sample > https://mega.co.nz/#!hZl0WBCA!WvwyTWs-VSbcAJ6Km3aCyT7LP5wy7_Tq1TmnXaHaNYg

[zerowalker]

Read before about the "being able to change between bit-depths" and i wonder, can this be adopted in x264?

[uneedme]

This phantom can be linked with technology b-frame prediction mode. Similarity in x264 > http://files.videohelp.com/u/227452/x264%20and%20b-frame%20prediction.7z


:( how to moderate this ghost effect?

[aegisofrime]

Hi, quick question which I think would be very easy to answer.

I'm giving a go at compiling my own x265 (I followed the instructions on the Bitbucket), and to my pleasant surprise it actually worked on the first try. Except for one thing: the exe doesn't report the version number. It reports it as version unknown. What do I need to do so that it would show the version number? Thanks!

[foxyshadis]

Hi, quick question which I think would be very easy to answer.

I'm giving a go at compiling my own x265 (I followed the instructions on the Bitbucket), and to my pleasant surprise it actually worked on the first try. Except for one thing: the exe doesn't report the version number. It reports it as version unknown. What do I need to do so that it would show the version number? Thanks!

The simplest way is to check the source out using Mercurial (hg), which CMake uses to get the version. Otherwise you have to manually define it in the generated makefiles.

[Ajvar]

Could somebody tell me why would 0:02:30 video with 2min, 26 sec of still image and 4 seconds of the same image but text appearing effect would look like cr@p and took over 8000 kbps with Main Still profile selected? While without selecting profile I get 300-400 kbps video with perfect image.
is it a bug?

[dipje]

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

[nevcairiel]

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

Technically the "Still" profile is for "still images", ie. single images encoded as HEVC, so modern jpeg, not even motion-jpeg. But people like to (ab-)use such profiles since they allow for some features they may want... :)

[foxyshadis]

Main Still is Main profile with the added restriction that only a single frame can be encoded, otherwise it's exactly the same. Why would you ever encode video with that?

just guessing here, but isn't the Main Still profile the 'intra only' profile without any frame prediction at all? Basically a modern version of motion-jpeg? :).

That's actually called Main Intra, and maybe that's what x265 switches to in this case, I don't know.

[Ajvar]

Main Still is Main profile with the added restriction that only a single frame can be encoded, otherwise it's exactly the same. Why would you ever encode video with that?
Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

[LigH]

Please try to understand that the most reduction of video bitrate is based on comparing the content of frames, and finding ways to reduce the size of the descriptions of the differences between them. P(redicted) frames store differences to a previous I(ntra = independent) frame, B(idirectionally predicted) frames can even try if the differences to a previous or a following frame can be stored with a smaller size. But the "Main Still" profile does not compare different frames, therefore it cannot use the most efficient ways of reducing the size.
__

You want to encode a "static video" of 2 minutes playing time? Well, many modern video codecs (not only HEVC) should be able to handle this situation pretty well, because nothing (except completely blank content) is easier material to find similarities which can be reduced in size. That's what motion prediction was made for, P and B frames will find perfectly matching motion vectors everywhere, and they are even (0,0), optimally compressible ... in theory.

In practice, though, there is a bunch of psychovisual changes which support scenes with non-zero motion and changes better. Applied to really still scenes, you may instead notice slight problems (like quantization pumping). To avoid these, tweaking specific parameters (like quantization ratios, the consecutive B frame maximum, motion search range, disabling adaptive quantization) may be necessary. Unfortunately, I am not able to tell you "the best parameters". I did not write these encoders, other people know them a lot better than me.

But it may even be possible to avoid encoding the video with as many frames as the playing time would require. Authored media formats shall have a feature to use exactly one encoded frame and hold the video for a given duration. Already the DVD Video is able to use one still video frame for a menu with an additional audio stream of a longer playing time. I believe that the successor technologies will support it still.

[Ajvar]

Please try to understand that the most reduction of video bitrate is based on comparing the content of frames, and finding ways to reduce the size of the descriptions of the differences between them. P(redicted) frames store differences to a previous I(ntra = independent) frame, B(idirectionally predicted) frames can even try if the differences to a previous or a following frame can be stored with a smaller size. But the "Main Still" profile does not compare different frames, therefore it cannot use the most efficient ways of reducing the size.

OK. That's a catch. Not experienced users would believe that picking Still profile is best for Still pictures however on practice (as I believe now) it is just profile hardware requirement: how slow can be hardware player to be able to play still HEVC images, - which is kinda silly because practically any player including mobile phones possibly can do this and not just this anyway.
I repeat, people will just pick Still profile for Still images video because it's most logical, get it?
You want to encode a "static video" of 2 minutes playing time? Well, many modern video codecs (not only HEVC) should be able to handle this situation pretty well, because nothing (except completely blank content) is easier material to find similarities which can be reduced in size. That's what motion prediction was made for, P and B frames will find perfectly matching motion vectors everywhere, and they are even (0,0), optimally compressible ... in theory.

In practice, though, there is a bunch of psychovisual changes which support scenes with non-zero motion and changes better. Applied to really still scenes, you may instead notice slight problems (like quantization pumping). To avoid these, tweaking specific parameters (like quantization ratios, the consecutive B frame maximum, motion search range, disabling adaptive quantization) may be necessary. Unfortunately, I am not able to tell you "the best parameters". I did not write these encoders, other people know them a lot better than me.

But it may even be possible to avoid encoding the video with as many frames as the playing time would require. Authored media formats shall have a feature to use exactly one encoded frame and hold the video for a given duration. Already the DVD Video is able to use one still video frame for a menu with an additional audio stream of a longer playing time. I believe that the successor technologies will support it still.
Sure I managed to encode this video (took 1 frame and did "ffmpeg -loop 1 -r 1 -i 1.png -c:v libx264 -preset medium -tune stillimage -crf 16 -pix_fmt yuv420p -t 155 output.mkv") and then HEVC encode (--keyint 9000 --bframes 16 --ref 1) and it used 3.5 Kbps but just had to use Auto profile.
Starting Main@01:09:09.836:
"--pmode --pme --input - --input-res 1280x720 --fps 2 --no-open-gop --keyint 9000 --bframes 16 --ref 1 --qp 32 --deblock=-3:-3 --colormatrix bt470bg --output "T:\Temp\output.265"
x265 [info]: HEVC encoder version 1.6+239-5c3443546ccc
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)+pmode+pme
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 : 2 / 9000 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CQP-32 / 0.0 / 0
x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong
x265 [info]: tools: deblock(tC=-3:B=-3) sao
x265 [info]: frame I: 1, Avg QP:29.00 kb/s: 872.85
x265 [info]: frame P: 22, Avg QP:32.00 kb/s: 1.19
x265 [info]: frame B: 287, Avg QP:33.92 kb/s: 0.89
x265 [info]: global : 310, Avg QP:33.77 kb/s: 3.73
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 4.3% 0.0% 0.0% 4.3% 0.0% 4.3% 4.3% 0.0% 8.7% 4.3% 0.0% 0.0% 4.3% 4.3% 0.0% 4.3% 56.5%
encoded 310 frames in 7.71s (40.21 fps), 3.73 kb/s
finished after 00:00:07.773

[foxyshadis]

Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

HEVC is not just a video codec, it's also meant to be an image codec.

Main Still is like JPEG, it's for ONE frame. It's to signal to image viewers (like photo frames) that the content isn't a video, it's just a plain picture. Main and its extensions are for all other purposes.

Main Still is a bit pointless, since containers signal that kind of metadata now. Best to ignore it and use standard profiles even for still images, since in the first spec there wasn't even a 10-bit version.

[Gravitator]

:( how to moderate this ghost effect?
It is enough to figure out a coding method adds an RD=5 (and then disable them to identify the culprit).

[dipje]

Hmmm... Maybe because H265 is VIDEO codeck? And it's not weird to be surprised that video of 99% of 1 still picture is encoded 100500 times worse with profile for still image video.


but in this case you clearly picked the wrong settings, disabling (unknowingly) everything that relates to 'multiple frames' bascially :).

Just use 'main profile', it's 'main' for a reason.

Remember, 'profile' is NOT used to tell the video codec what kind of material it is encoding, that's where the tuning options come in. Profiles are meant to tell the _decoding_ devices what kind of videostream to expect.

Just don't use 'main still' and you will be ok.

[divxmaster]

Yes, we're seeing good performance increases at the fast and medium preset, because the early outs are now effective more often (depending on content).

Actually that fps speed increase was on slow preset, so an excellent result.

[MeteorRain]

Also how properly then to encode a video with HEVC so it would take least kbps for still image and 2 minutes long?

A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

1000 frames in still profile is considered as 1000 (completely different) still images, regardless of how similar they are.

[Ajvar]

A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

OK, how to do it on practice? I mean x265 code.

[foxyshadis]

OK, how to do it on practice? I mean x265 code.

Main and its extensions are for all other purposes.

Since you need it spelled out: Main and Main 10, the only other profiles available.

[Ajvar]

Since you need it spelled out: Main and Main 10, the only other profiles available.

Since you need either:
A properly use of still image profile, is to keep only a single frame for the same picture, and use timecode to keep its duration.

OK, how to do it (properly use still image profile to keep 1 single and only lone picture and keep timecode/duration) on practice? I mean step-by-step command line code for x265 exe.
Special to foxyshadis , no, not asking how to encode anything in Main/Main 10 profile, thank you, no need to tell me about that. My concern is if that if there is additional profile than why it's not used or how to.

[LigH]

Probably analogue to how it worked on a DVD Video with one MPEG-2 still frame:

1. Encode one frame to a HEVC raw file.

2. Use this one encoded HEVC frame with a prolonged display duration. That may depend on the authoring tool you will be using later when authoring a media format supporting HEVC as stills, possibly an Ultra-HD Blu-ray disc. On DVD Video, authoring tools used to extend the display of a background MPEG-2 still frame to the playing time of the parallel audio stream automatically in a menu, or manually to a desired length if used in a slide show. I would assume that authoring tools for more modern formats may do something very similar.

[nevcairiel]

OK, how to do it (properly use still image profile to keep 1 single and only lone picture and keep timecode/duration) on practice? I mean step-by-step command line code for x265 exe.

You should not to that, its unlikely to work properly for various reasons, the primary one being that it would be a VFR video, which is badly supported by a whole lot of things. You have been warned. ;)

Still Image profile should only be used for single still images (actual images, like jpg's), not for encoding videos, even if the video contains long "still" images.

I'm not sure why you are insisting on using it, it won't really improve the quality for you either, but of course all the power to you.

[benwaggoner]

You should not to that, its unlikely to work properly for various reasons, the primary one being that it would be a VFR video, which is badly supported by a whole lot of things. You have been warned. ;)
Do we know if that's true for HEVC decoders? Since by definition those will be recent, the bar would be a lot higher. We don't need to worry about VfW HEVC players, I hope!

With only one frame, it could still be CFR, just with the fps set to the reciprocal of the desired duration. So a 10 sec duration would use a fps of 0.1.

Still Image profile should only be used for single still images (actual images, like jpg's), not for encoding videos, even if the video contains long "still" images.

I'm not sure why you are insisting on using it, it won't really improve the quality for you either, but of course all the power to you.
I concur on that. Using Main Still in this case would only reduce compatibility for any scenario I can think of. Main Still is probably most useful as a modern Motion-JPEG or other I-frame only codec equivalent.

[LigH]

Must have forgotten the last one. So today, two releases.

x265 1.7+37-dc4fcfc574ad (https://www.mediafire.com/download/xr350536r8wj5jm/x265_1.7+37-dc4fcfc574ad.7z)
—

[Ajvar]

@LigH , @nevcairiel , @benwaggoner , OK, thanks for babysitting with me. I guess all disadvantages destroy an only advantage of Main Still then. Maybe some day somebody makes it more useable and useful.

[LigH]

A pocket knife is already useful. Just not for cutting down a tree. Use a saw for that purpose.

"Main Still" profile is already useful. Just not for encoding a full frame rate video. Use "Main" profile for that purpose.

[LigH]

x265 1.7+95 removed in favour of 1.7+96:

api: fix for crash in x265_api_query caused by function type casting error

In x265_api_query, after retrieving the function pointer of x265_api_query from external DLL, it is then incorrectly type cast into x265_api_get function, the patch is intended for this fix.

x265 1.7+96-093618ce0b26 (https://www.mediafire.com/download/4l98hadr7d71di3/x265_1.7+96-093618ce0b26.7z)

[dipje]

@LigH , @nevcairiel , @benwaggoner , OK, thanks for babysitting with me. I guess all disadvantages destroy an only advantage of Main Still then. Maybe some day somebody makes it more useable and useful.

I still don't get what advantage you think 'Main Still', I can't think of one

[Motenai Yoda]

Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.

I would point out that the documentation still has not been changed / corrected

[benwaggoner]

I would point out that the documentation still has not been changed / corrected
That suggests that --dither would give you dithering even if converting from yuv420p10le to 10-bit.

I guess it's good to be able to get dithering when going from actual 16-bit to 10-bit, though. But dithering definitely shouldn't be enabled when not changing bit depth.

[Motenai Yoda]

Yep but I still don't know exactly if a 16bit->10bit dithering is done or not.
At the age of that post --dither was applied even for 10bit (when enabled), to the detriment of what documentation sai(d)s , now it doesn't (or at least I got some truncated, 6bit like, output, v1.6+4xx).

also, level's max ref is related with bitdepth too? I notice with level 4 it's lowered to 5(+1) for 8bit, but 4(+1) for 10bit

[foxyshadis]

Yep but I still don't know exactly if a 16bit->10bit dithering is done or not.
At the age of that post --dither was applied even for 10bit (when enabled), to the detriment of what documentation sai(d)s , now it doesn't (or at least I got some truncated, 6bit like, output, v1.6+4xx).

also, level's max ref is related with bitdepth too? I notice with level 4 it's lowered to 5(+1) for 8bit, but 4(+1) for 10bit

That's definitely not correct, every profile has a "FormatCapabilityFactor" that normalizes the memory requirements, main10 being 20% higher than main. At the same frame size, all profiles allow equal numbers of reference frames.

(The 20% more memory to support main10@4 won't let you go up to 4.1 in 8bit, but it might let you sneak in an extra ref, if your player doesn't reject it.)

The dither algorithm hasn't changed, it still dithers down for all greater-than-internal, not just 8-bit.

[Motenai Yoda]

sorry my bad, I mistyped 5 not 4 setting 8bit level-idc...
so how can it be calculated? x265's docs says only 8 is the max, -1 for bframe, -1 for b-piramid, so 6

-1 for the current frame that has to be stored in the dpb too (as wiki says), so 5

but in 2014/10 itu's spec. I found

d) The value of sps_max_dec_pic_buffering_minus1[ HighestTid ] + 1 shall be less than or equal to MaxDpbSize, which is derived as follows:
if( PicSizeInSamplesY <= ( MaxLumaPs >> 2 ) ) MaxDpbSize = Min( 4 * maxDpbPicBuf, 16 )
else if( PicSizeInSamplesY <= ( MaxLumaPs >> 1 ) ) MaxDpbSize = Min( 2 * maxDpbPicBuf, 16 ) (A-2)
else if( PicSizeInSamplesY <= ( ( 3 * MaxLumaPs ) >> 2 ) ) MaxDpbSize = Min( ( 4 * maxDpbPicBuf ) / 3, 16 )
else MaxDpbSize = maxDpbPicBuf
where MaxLumaPs is specified in Table A.4 and maxDpbPicBuf is equal to 6.
again 6 -1 -1 = 4
this seems to comply with x265 restrictions...

anyway
--input-depth 16
http://thumbnails108.imagebam.com/41370/246c0a413695601.jpg (http://www.imagebam.com/image/246c0a413695601)
--input-depth 16 --dither
http://thumbnails108.imagebam.com/41370/918ed6413695504.jpg (http://www.imagebam.com/image/918ed6413695504)

[foxyshadis]

I just made my first encode with --analysis-mode load and while it ran 3 times as fast, the encoded file was completely broken. This is with 10-bit input and output, current git head.

Original command line: x265 --preset veryslow --input pristest.y4m --analysis-mode save --analysis-file pristest.dat --crf 20 -o pristest-q20-veryslow.hevc
Second command line: x265 --preset veryslow --input pristest.y4m (https://dl.dropboxusercontent.com/u/54412753/x265/pristest_30s.7z) --analysis-mode load --analysis-file pristest.dat (https://dl.dropboxusercontent.com/u/54412753/x265/pristest.7z) --crf 24 -o pristest-q24-veryslow.hevc (https://dl.dropboxusercontent.com/u/54412753/x265/pristest-q24-veryslow.hevc)

All I changed was the crf, and I got tons of black blocks and echo blocks, especially beginning around 0:20, as if residuals sometimes weren't being applied at all. MPDN just freezes, other players play with major artifacts.

Aside from that, holy crap is the analysis file huge. It's as large as the y4m; I had to put it on a ntfs compressed folder, where it went from 11gb to 800mb real bytes. (The 7-zip is only 50mb.) Surely x265 can run some sort of compression over it while writing, either xz (lzma2) or at least gzip? When I first attempted to use it from the same drive as my working file, I ended up thrashing the disk so badly that encoding speed was actually halved, until I moved it to my SSD system drive.


Lastly, a suggestion for the docs: --strong-intra-smoothing is barely described. The purpose of it is to prevent macroblocking in smooth areas, primarily ones that look like this:
http://www.webalice.it/f.corriga/temp/ghostingzoomnm1.png
It's banding, but mainly due to zero or near-zero AC coeffs and tends to be larger. In 8-bit mode, strong intra smoothing will at least reduce it to plain jagged banding, and in 10-bit mode it'll render it more invisible. I have no idea if it has any downsides, though.

[mandarinka]

I had problems with wrong motion vectors being used in january (but it wasn't this broken), so I would also say, don't use the dump/analyse feature for serious production...

[littlepox]

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.

[LigH]

Most probably related to better instruction efficiency and AVX2 support (which is heavily used in x265 when available)?