x265 HEVC Encoder

[jhughy2010]

Handbrake.

I've been using three samples which I splitted of using MKVToolnix (keeping only video) from the original extracted from my Blurays using MakeMKV.
The GoT intro (probably on YT, haven't checked)
S01E02 00:37:00-00:39:30 ("static scene", decent amount of detail and crisp hair and so on.)
S01E05 00:51:00-00:53:00 (Eddard vs Jaime sword fight, can be found on YT).

I could put the original samples I use in my Dropbox but in total they're a little under a gigabyte so may take sometime for you to download depending on your connection.
And I don't know exactly what's considered a sample and this is copyrighted content after all so..

E: And I hope you didn't get my "even RF20 looks impressively good" as a "oh dear lord, RF20 looks so good it's almost transparent" statement. If I do end up archiving some of my GoT bluray's with Handbrake 0.10.2 using it's current x265 version along with the medium preset, RF setting I'd use would be either 17 or 18.
The file size using RF16 got real close to what my x264 encode at RF20 and custom settings got to while encoding speed wasn't all that different.

I feel like RF18 via x265 is at "least" as high of quality as RF20 via x264. The encode speed is drastically slower however. I've averaged around 14 frames per second with x265 at medium preset, RF18, AC3 5.1 for a full rip BD. With x264 I was in the 40+ FPS.

x265 is what I use exclusively for archiving my BD collection. I'll need to try the nightly build if the x265 encoder is really superior.

[birdie]

I feel like RF18 via x265 is at "least" as high of quality as RF20 via x264. The encode speed is drastically slower however. I've averaged around 14 frames per second with x265 at medium preset, RF18, AC3 5.1 for a full rip BD. With x264 I was in the 40+ FPS.

x265 is what I use exclusively for archiving my BD collection. I'll need to try the nightly build if the x265 encoder is really superior.

RF? You mean CRF?

For transparent results most people here use CRF=18 or lower for x264 (with "veryslow" encoding), which means roughly CRF=16 for x265.

I cannot believe your whole videos aren't totally washed out and blurry with your settings (medium/CRF18). Please post your screenshots (including the source) because what is "good" for you seems to far from transparent in terms of picture quality.

Last but not least at very high bitrates/transparent quality x265 still hasn't reached parity with x264.

[jhughy2010]

RF? You mean CRF?

For transparent results most people here use CRF=18 or lower for x264 (with "veryslow" encoding), which means roughly CRF=16 for x265.

I cannot believe your whole videos aren't totally washed out and blurry with your settings (medium/CRF18). Please post your screenshots (including the source) because what is "good" for you seems to far from transparent in terms of picture quality.

Last but not least at very high bitrates/transparent quality x265 still hasn't reached parity with x264.

No I don't mean CRF. I am talking about Constant Quality: 18 RF.

I use the x265 preset medium.

Medium RF18 for x265 looks as good if not better than medium RF20 for x264. I haven't played with a slower preset for x264.

I tried to upload the screen shot but the file size was 5MB and it exceeded the max file size. Compressing it will only lower the quality so it would ultimately make it pointless.

[foxyshadis]

CRF, RF, and Constant Quality are different names for the same thing. (Constant Quant being something else entirely.)

[LigH]

RF = "Rate Factor" is a quotient from the interna of the encoding algorithm used to "measure" the quality loss.

CRF = "Constant Rate Factor" just emphasizes the fact that this mode tries to keep the rate factor as constant as possible, staying below a threshold of quality loss.

The expression "Constant Quality" is not really exact. The resulting video won't have a constant subjective visual quality, just a more or less constant degradation.

[Tyler Pruitt]

What data format is the Mastering Display's RGB primaries in? Example:

--master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0"

I would have though it would be in xyY or XYZ.

[nevcairiel]

the first 3 pairs are the xy chromaticity coordinates of GBR respectively, WP the xy coordinates of the white point, all in increments of 0.00002, and L is the max display luminance in 0.0001 units.

Or to quote the spec:

display_primaries_x[ c ] and display_primaries_y[ c ] specify the normalized x and y chromaticity coordinates, respectively, of the colour primary component c of the mastering display in increments of 0.00002, according to the CIE 1931 definition of x and y as specified in ISO 11664-1 (see also ISO 11664-3 and CIE 15). For describing mastering displays that use red, green and blue colour primaries, it is suggested that index value c equal to 0 should correspond to the green primary, c equal to 1 should correspond to the blue primary and c equal to 2 should correspond to the red colour primary (see also Annex E and Table E.3). The values of display_primaries_x[ c ] and display_primaries_y[ c ] shall be in the range of 0 to 50 000, inclusive.

white_point_x and white_point_y specify the normalized x and y chromaticity coordinates, respectively, of the white point of the mastering display in normalized increments of 0.00002, according to the CIE 1931 definition of x and y as specified in ISO 11664-1 (see also ISO 11664-3 and CIE 15). The values of white_point_x and white_point_y shall be in the range of 0 to 50 000.

max_display_mastering_luminance and min_display_mastering_luminance specify the nominal maximum and minimum display luminance, respectively, of the mastering display in units of 0.0001 candelas per square metre. min_display_mastering_luminance shall be less than max_display_mastering_luminance.

[Chainmax]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2) (https://www.mediafire.com/download/vx21tk5hqla3h22/x265_1.7+470-86e9bd7dd192.GCC492.7z)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0) (https://www.mediafire.com/download/1dwbk5t22kac176/x265_1.7+470-86e9bd7dd192.GCC520.7z)

I tried the following settings:

x265_main12 --input ep1interm.avi --input-res 1280x720 --fps 29.97 --output Ep1.hevc --preset veryslow --tune grain --crf 40

On the first episode of a Yale lecture I filtered and upscaled to 720p. I then muxed the .hevc file and original .mp4 audio in MKVToolnix. Neither VLC nor MPC-HC with LAV could render the resulting file. Have I done something wrong, or is 12bit not decodable yet?

[LigH]

I am just quite surprised that you are feeding an AVI as input... since when does x265 support AVIs? I only know of raw YUV and YUV4MPEG (with simple header).

Usually I don't multiplex HEVC and audio to MKV, rather to MP4; the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.

[sneaker_ger]

x265 12 bit -> mkvtoolnix -> LAV (nightly) works for me.

the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.
I don't trust mp4box. There was (or still is?) a problem in connection with the MPC-BE splitter which L-Smash does not have.

[Motenai Yoda]

x265 [info]: HEVC encoder version 1.7+481-5dde4773fcef
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 12bit
x265 [info]: lowering VBV max bitrate to 12000Kbps
x265 [info]: lowering VBV buffer size to 12000Kb
x265 [info]: Main 12 profile, Level-4 (Main tier)

IIRC Main 12 L4.0 VBVs should be 18000kbps (also k should be lowercase IINW)

[foxyshadis]

I am just quite surprised that you are feeding an AVI as input... since when does x265 support AVIs? I only know of raw YUV and YUV4MPEG (with simple header).

Usually I don't multiplex HEVC and audio to MKV, rather to MP4; the MP4 support for HEVC video streams in MP4Box existed earlier and was quite reliable right away.

x265 will assume a raw YUV stream and produce garbage video in this case, but at least it should still play.

[Ma]

IIRC Main 12 L4.0 VBVs should be 18000kbps (also k should be lowercase IINW)

Confirmed, table https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels#Levels

[LazyNcoder]

Hi guys,
How can we get a clearer/sharper image? I know there's nr-inter nr-intra which make the oppsite results. I tried no-deblock + qblur 0 + cplxblur 0, but it didn't give me what I've been looking for. I feel x265 makes the image blur regardless of which bitrate/crf it uses.

Also, I read a lot about the banding issue in x265 in this topic. some users said aq-mode 1 would help it but I don't get a noticeable results with it. also I thing dither switch won't do anything in this matter. what's the best thing to do to make banding less without using 10/12bit encoding.

Thanks

[LoRd_MuldeR]

Hi guys,
How can we get a clearer/sharper image? I know there's nr-inter nr-intra which make the oppsite results. I tried no-deblock + qblur 0 + cplxblur 0, but it didn't give me what I've been looking for. I feel x265 makes the image blur regardless of which bitrate/crf it uses.

Also, I read a lot about the banding issue in x265 in this topic. some users said aq-mode 1 would help it but I don't get a noticeable results with it. also I thing dither switch won't do anything in this matter. what's the best thing to do to make banding less without using 10/12bit encoding.

Thanks

Why are you messing with the "--qblur" and "--cplxblur" options? Those are related to temporally blurring the quantizers, in order to limit quantizer fluctuations. It's probably not a good idea to set them to zero (or to change them at all). Just because there is "blur" in the name, doesn't mean they are going the blur the image! Also, turning off the deblocking filter completely (--no-deblock) probably isn't the best idea either. You can tune the "strength" of the deblocking filter via "--deblock=x:y" option. Some negative deblock offsets may be helpful here. Finally, to improve detail preservation, the Psy options (psychocisual optimizations) "--psy-rd" and "--psy-rdoq" probably are your best bet. Setting those options to a higher value should preserve more details (instead of blurring), but setting them too high is going to causes other problems! Note that Psy-RD is only effective at "--rd 3" or higher. And that Psy-RDOQ requires "--rdoq-level 1" or higher.

[x265_Project]

We were sent the final report today, and I'm happy to report that x265 was shown to be the best overall HEVC encoder. x265 was particularly strong in the universal and ripping (high quality) use-cases. http://x265.org/wp-content/uploads/2015/09/Figure-145-Ripping.png

http://x265.org/wp-content/uploads/2015/09/Figure-146-Overall.png

We're not allowed to share the whole report, but we are allowed to share selected graphs, as long as we link to www.compression.ru/video

[poisondeathray]

Congrats!

But that 1% lead over Intel in the "overall" category isn't much of a buffer for the lead - start working harder already or Intel might come back with a vengeance next time (joking :) )

I realize this isn't the final public version, but any reason why VP9 isn't represented on the "overall" category when it was on the previous graph ?

[foxyshadis]

I know VP9 is terribly slow, but how fast was the Intel software encoder relative to the x265 settings used? Also, did they release any actual streams or screenshots from them, so you could judge visual quality trade-offs?

[NikosD]

x264 is still very strong and taking into account encoding speed it is very attractive too.

@x265_Project

Is your ultimate goal to reach 50% of avg bitrate of x264, getting close to theoretical 50% bitrate of H265 compared to H264 ?

At what encoding speed ?

[Jamaika]

How is the result in this chart of HEVC Cyberlink?
I'm not convinced. It isn't known what settings were used for individual companies.

[LigH]

There have been only few commits during the last weeks. But today there is a nice bunch again. Also with some merges from the stable branch in between. So let's publish another package.

x265 1.7+497-975352b2c022 (GCC 4.9.2) (https://www.mediafire.com/download/cdo9c8yg5j9b0fp/x265_1.7+497-975352b2c022.GCC492.7z)
x265 1.7+497-975352b2c022 (GCC 5.2.0) (https://www.mediafire.com/download/be9fcq3ff0bsuzp/x265_1.7+497-975352b2c022.GCC520.7z)

[Parabola]

Isn't Y-SSIM a luminance-only metric thus favouring encoders that don't care about chroma? In previous comparisons, MSU methodology left me with cause for concern (even as a neutral observer). Nevertheless, nice work, Tom and team - looking forward to full report.

[nevcairiel]

Isn't Y-SSIM a luminance-only metric thus favouring encoders that don't care about chroma?

It is, they want you to buy the full report to get access to the full comparisons with combined luma and chroma scores.

[LigH]

Yay, another "clickbaiter" ... :mad: Reminds me on the first "exclusive news preview for iOS 9 users only" # (http://ptrace.fefe.de/applenews.png). The value of man is equal to their ability of being a consumer.

[x265_Project]

I know VP9 is terribly slow, but how fast was the Intel software encoder relative to the x265 settings used? Also, did they release any actual streams or screenshots from them, so you could judge visual quality trade-offs?

There were 3 use-cases... fast transcoding, universal and ripping, and all 3 tests were run on a desktop Core i7 and a dual Xeon server. Intel's accelerated encoder showed the best efficiency in the fast transcoding test, but had issues with rate control. We've made many improvements in both speed and real-time encoding algorithms (adding limit-refs, min-cu, etc.) since we submitted x265 to MSU back in March, so I think we should be able to do much better on this test today. We showed the best compression efficiency for the universal and ripping use-cases. We generally demonstrated better rate control than the rest.

They didn't share any bitstreams or screen shots for comparison, nor did they do any subjective video quality analysis. We have given them a number of suggestions for improving their test design, and a focus on subjective visual quality would be at the top of the list.

[aymanalz]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

[burfadel]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

I think to an extent it depends on the source material and resolution.

[CruNcher]

If intel can push the same results via Quicksync in the near Future it would be a pretty nice achievement for them i see neither Nvidia/AMD seemed to have participated with their Encoder Cores nor Ateme or even Mainconcept/DivX did this time :(

VP9 so far shows really nice promising results especially on the Decoding side Balance :)

[foxyshadis]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?

Star is used in everything slower than medium, so it's not that bad. Full (esa) probably isn't worthwhile for anything but testing, it's not even used in placebo. me-range and lots of refs are other big ones that get less meaningful as they increase. An HEVC-specific barely-worth-it is subdividing the CUs into even more TUs (tu-inter/tu-intra).

"Worth it" is a loaded question, of those without a hard time budget many people have settled on medium preset as their optimal time/size/quality tradeoff, but some use the slower presets. It comes down to what feels right for you: An hour? A day? A week? I'm usually OK with a day or so per movie, despite knowing that the difference between that and a few hours is barely going to be noticeable, if at all.

[aymanalz]

Star is used in everything slower than medium, so it's not that bad. Full (esa) probably isn't worthwhile for anything but testing, it's not even used in placebo. me-range and lots of refs are other big ones that get less meaningful as they increase. An HEVC-specific barely-worth-it is subdividing the CUs into even more TUs (tu-inter/tu-intra).


What puzzles me is that none of the presets use umh at all. Superfast to medium use hex, and slow uses star. Is that an indication that umh is not ideal for a speed-time tradeoff?

[aymanalz]

"Worth it" is a loaded question, of those without a hard time budget many people have settled on medium preset as their optimal time/size/quality tradeoff, but some use the slower presets. It comes down to what feels right for you: An hour? A day? A week? I'm usually OK with a day or so per movie, despite knowing that the difference between that and a few hours is barely going to be noticeable, if at all.

I don't use presets, I manually tune each option. I agree that what is worth it is subjective. I asked the question because with x264, handbrake (or was it x264 itself?) used to warn that the compression gain will be very tiny in going from umh to esa, but the encode will be much slower. I was wondering if such a statement could be made for x265.

For instance, if going from umh to star provides only a 2% increase in quality, but takes twice as long to encode...something like that.

[shinchiro]

From my bitrate test on one of my samples, star is more faster from umh (about ~1.5 fps). The final size is almost same for both star and umh. The quality very closely on a par with --me umh. umh is slightly better at preserving details than star

[Jamaika]

Is there a particular motion estimation method, at which the gain in compression from the one just below it would not justify the time spent in encoding? With x264, all the documentation suggested that going from umh to esa would only yield a negligible improvement in compression, but comes with a huge performance penalty. What is the comparable point for x265, if there is one? Is it umh to star?
There are two directions to minimal lost of quality. In a first bitrate, or the size of the movie. Secondly features 2-pass or stillImage for x264. The scale preset is for older computers. The fastest is me=dia, but the quality decreases, especially for dynamic movies.
In the settings motion estimation algorithm (dia, hex, umh, star) isn't only important to the quality of single frames from the original, but as the film is liquidity. Are there marked differences between frames (other texture, spots, vibration)? Doesn't the film seem too blur?
Descriptions of the conversion in the comments movies:
https://www.sendspace.com/filegroup/VcBRjHh6FpxzWdzolF2bUb1WuJA1z0TUnsRJ43LQ3kM
Edit: Conversion with "umh" better looking than with "star" for X265.
I think to an extent it depends on the source material and resolution.
This is the most important thing.

[burfadel]

So UMH looks less bad (not going to use one of the doom9's naughty words) than Star, subjectively (again, covering myself!). How does Star fair against Hex? There doesn't seem to be much speed difference between Hex and Star for me which is surprising, so if Star could be the more subjectively 'congruent to the original' option where people are looking for a little more supposed efficiency over the original, I'd probably use that from now on.

Sure I can see for myself, but I would like second and third opinions etc. I'm using CRF.

[CruNcher]

@x265_Project

Did Multicorewave analyzed V-Novas Perseus Patent fillings yet ?

https://www.google.com/patents/US8531321
https://www.google.com/patents/US20130294704
https://www.google.com/patents/US8977065

there are really a heavy bunch in all areas from replacing CABAC with lower complexity to supersampling reconstruction

More bandwith efficient SVC Partly Thomsons FGM seems to come back in full force this time

[x265_Project]

@x265_Project

Did Multicorewave analyzed V-Novas Perseus Patent fillings yet ?

https://www.google.com/patents/US8531321
https://www.google.com/patents/US20130294704
https://www.google.com/patents/US8977065

there are really a heavy bunch in all areas from replacing CABAC with lower complexity to supersampling reconstruction

More bandwith efficient SVC Partly Thomsons FGM seems to come back in full force this time
Interesting from a technology standpoint, but I wouldn't want to offer any legal analysis or opinions on the Doom9 forums.

When you license an encoder implementation like x265, you get the right to use that implementation, but the license doesn't cover patents, which must be licensed separately from the patent holders (MPEG-LA).

There is always a better coding standard in development. The next standard always promises significant gains over previous standards. Implementing a standard and getting a good % of the world to adopt your standard so that it is truly "standard" (supported by any device or platform that you want to use it on) are two different things. It's easier to do the first part than the second part. It's also easy to argue about why one standard is better than another, but in the end, individual companies and people vote by adopting or not adopting each standard.

For example - take a look at the survey that streamingmedia.com just did (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Encoding-2020-Experts-Predict-the-Future-of-Video-Encoding-106619.aspx).

Even though we run a business that is largely based on HEVC today, we don't have "codec religion". We're always ready to look at implementing new coding standards if there is a sustainable opportunity.

[Nintendo Maniac 64]

For example - take a look at the survey that streamingmedia.com just did (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Encoding-2020-Experts-Predict-the-Future-of-Video-Encoding-106619.aspx)

Wait, how do some of those numbers work when HEVC + HTML5 doesn't even seem to be on any browser maker's radar? (maybe except for Apple or Gstreamer-enabled Linux browsers) Obviously you don't need to worry about that for native apps on mobile and TV, but the HEVC + HTML5 thing seems like a bit of an elephant in the room to me...

[CruNcher]

Also they seem to fulfill one of the key promises HEVC was to introduce (Massive Parallelism) with their Nvidia announcement recently

which Multicorewave couldn't do fully efficient with OpenCL and only @ the Lookahead on x264 and no sign of anything x265 related yet

“Whereas legacy codecs are highly serialized, PERSEUS is able to harness all of the
processing power of NVIDIA GPUs. PERSEUS’ ability to distribute processing load across the entire GPU.

It's pretty crazy they come out of nowhere and have everything ready (they worked totally in Secret alongside the HEVC Standardization for years now)

This must be mainly the work of one of the Ex Argonaut Games GPU Developer working there

https://en.wikipedia.org/wiki/Argonaut_Games
https://en.wikipedia.org/wiki/Super_FX

[littlepox]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

[MeteorRain]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

Correction for you, it's between 1.7+436~437 and the commit was even in stable branch. Will probably post this to maillist as well.

[LigH]

Interesting from a technology standpoint...

V-Nova Perseus (http://forum.doom9.org/showthread.php?p=1715792) appears to be a kind of "noise modeller" (similar to a video version of "Spectral Band Replication" as used in audio formats like mp3PRO or HE-AAC), now that there are more details available. You may be casually interested in the implementation in a custom x264 build (http://forum.doom9.org/showthread.php?p=1741387#post1741387), provided I understood the very brief summary of CruNcher correctly... :sly:

[CruNcher]

Exactly that is what i read out of the patents so far a mp3PRO/HE-AAC approach

[kotuwa]

There is a bug after patch 10912, version 1.7+418-d56b2466c044+12@894fdf30a295:

The scene-cut scheme fails so that the IDR length is always equal to keyint.
This is found @ 10bit-encoding. Is anybody aware of this issue?

Me too...

In version 1.7, the scene-cut is much different from 1.6.
I encoded the same sample using 1.6 and 1.7.
In 1.6, the keyframes are there in proper positions.
In 1.7, they are in insane positions, in the middle of the scenes…
And the whole video looks low quality compared to 1.6

While ago posted in http://x265.ru, as a comment, no reply there though...
:|

[microchip8]

Me too...

In version 1.7, the scene-cut is much different from 1.6.
I encoded the same sample using 1.6 and 1.7.
In 1.6, the keyframes are there in proper positions.
In 1.7, they are in insane positions, in the middle of the scenes…
And the whole video looks low quality compared to 1.6

While ago posted in http://x265.ru, as a comment, no reply there though...
:|

And why do you expect a reply there? Post on the x265 mailing list or open a ticket at https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

[Ma]

Post on the x265 mailing list or open a ticket at https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

You can test this nandaku2 patch first
https://www.mail-archive.com/x265-devel@videolan.org/msg08591.html
and open a ticket if it doesn't work.

[LigH]

This issue is already being addressed.

# HG changeset patch
# User Deepthi Nandakumar <deepthi@multicorewareinc.com>
# Date 1444115344 -19800
# Tue Oct 06 12:39:04 2015 +0530
# Branch stable
# Node ID aaf7fe7452b5c46e564d32ff52f2730a79ebaea1
# Parent 98ac099a766fc3eb6333fd5676b87a5933e1e3d0
slicetype: fix bugs in scenecut and slicetype decision

The default value of bScenecut had changed to false (instead of true) and this
was not accounted for correctly.

I guess we will soon have a fixed build. I will delay my weekly release for it.

[Motenai Yoda]

This issue is already being addressed.

# HG changeset patch
# User Deepthi Nandakumar <deepthi@multicorewareinc.com>
# Date 1444115344 -19800
# Tue Oct 06 12:39:04 2015 +0530
# Branch stable
# Node ID aaf7fe7452b5c46e564d32ff52f2730a79ebaea1
# Parent 98ac099a766fc3eb6333fd5676b87a5933e1e3d0
slicetype: fix bugs in scenecut and slicetype decision

The default value of bScenecut had changed to false (instead of true) and this
was not accounted for correctly.

I guess we will soon have a fixed build. I will delay my weekly release for it.

Seems fixed with a85011719ea1, it isn't?

[LigH]

Probably. But I'm missing a "merge with stable" commit, so I am not sure if a "tip" build would miss a few last changes in the "default" branch right now...

[Motenai Yoda]

I tried with a85011719ea1
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:21.640000 I
0:00:31.640000 I
0:00:41.640000 I
0:00:48.720000 I
0:00:49.560000 I
0:00:55.440000 I
0:00:55.840000 I
0:00:58.920000 I
0:01:03.880000 I
0:01:07.760000 I
0:01:12.280000 I
0:01:14.880000 I
0:01:18.440000 I
0:01:19.960000 I
0:01:20.520000 I
0:01:22.200000 I

and with edited f8b8ebdc545
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:21.640000 I
0:00:31.640000 I
0:00:41.640000 I
0:00:48.720000 I
0:00:49.560000 I
0:00:55.440000 I
0:00:55.840000 I
0:00:58.920000 I
0:01:03.880000 I
0:01:07.760000 I
0:01:12.280000 I
0:01:14.880000 I
0:01:18.440000 I
0:01:19.960000 I
0:01:20.520000 I
0:01:22.200000 I

1.7+417 for comparison
0:00:00.000000 I
0:00:10.000000 I
0:00:20.000000 I
0:00:30.000000 I
0:00:40.000000 I
0:00:50.000000 I
0:01:00.000000 I
0:01:10.000000 I
0:01:20.000000 I

Looks like this was introduced by 4992f03 seems like a mistype
but I don't get why was added a new if statement instead of just adding m_param->bFrameAdaptive
in front the condition expression, as
if (m_param->bFrameAdaptive && m_param->scenecutThreshold && scenecut(frames, 0, 1, true, origNumFrames))
It will be Short-circuit_ed anyway, but I have no idea what I'm talking about.

[x265_Project]

Me too...
While ago posted in http://x265.ru, as a comment, no reply there though...
:|
That will get you nowhere. There are many ways to get in touch with us. For bugs, the best way is to file an issue on our Bitbucket issues tracker (https://bitbucket.org/multicoreware/x265/issues).