x265 HEVC Encoder

[Stacey Spears]

Yeah, how would one even do that? Convert the HLG into PQ and do a new analysis pass in Resolve or something, then encode UHD BD compliant Profile 5 or 7 from that?

UHD BD only supports Profile 7.

[Stacey Spears]

Our of curiosity, how are the new iPhones recording?
I saw the "Dolby Vision" announcement days ago, but it was rather vague. Is it H.265 10bit UHD HDR HLG 60p with metadata? Does it have the FULL HD 10bit additional layer with info to make the 12bit final result? Or perhaps it's still one layer in 8bit? And most importantly, given that most mobile phones have a ridiculously tiny sensor whose stops are low, does all this even make sense? I mean, I read that it can achieve up to 12 stops, but I think that it's not gonna get even close. SDR in BT709 100 nits is 6 stops, if they manage to get 9 stops out of that it would already be a miracle...

They use Profile 8.3, which is HLG + Dolby's dynamic metadata. If you have an LG C9 or CX, it will play in Dolby Vision. If you have an older LG, then it plays as HLG.

Profile 5 and 8 are single layer 10-bit profiles. Profile 7 has the additional full enhancement layer for addition bit-depth. Profile 5 uses ICtCp while Profile 7 and 8 use YCbCr.

The reason the iPhone went with Profile 8.3 was so they would not have to tone map for the SDR version.

[nakTT]

New upload: x265 3.4+30-g6722fce1f (https://www.mediafire.com/file/sk7nni880d16eo8/x265_3.4+30-g6722fce1f.7z/file)

Thanks for the upload.

[Blue_MiSfit]

The reason the iPhone went with Profile 8.3 was so they would not have to tone map for the SDR version.

That makes sense, but FWIU HLG is only actually "backwards compatible" in terms of dynamic range, not color gamut (since rec2020 / p3d65 / WCG -> rec709 is hard to do well automatically).

So, from a backwards compatibility standpoint, you can either use WCG (and thus only be really backwards compatible with SDR WCG displays of which there aren't too many AFAIK) or use standard 709 gamut and thus be only HDR and not WCG which won't take advantage of modern HDR displays that are all WCG.

Do I have that wrong?

[benwaggoner]

That makes sense, but FWIU HLG is only actually "backwards compatible" in terms of dynamic range, not color gamut (since rec2020 / p3d65 / WCG -> rec709 is hard to do well automatically).

So, from a backwards compatibility standpoint, you can either use WCG (and thus only be really backwards compatible with SDR WCG displays of which there aren't too many AFAIK) or use standard 709 gamut and thus be only HDR and not WCG which won't take advantage of modern HDR displays that are all WCG.

Do I have that wrong?
That was certainly how HLG was originally intended to work by the BBC. But the de facto HLG has drifted somewhat; after all, essentially no devices shipped with Rec 2020 and NOT PQ. It must be using 709 primaries or else it wouldn't be backwards compatible.

My take on HLG has been "it may work in practice, but it definitely doesn't work in theory!"

[benwaggoner]

Yeah, how would one even do that? Convert the HLG into PQ and do a new analysis pass in Resolve or something, then encode UHD BD compliant Profile 5 or 7 from that?
Yes, pretty much. Of course, while in Resolve, additional color work could be done to get to >1000 nits, use more saturated colors, etcetera.

Profile 8.3 isn't great, but it makes for a substantially better HDR source than anything 709 would be. The 12 Pro Max with its improved optics will probably lead to some interesting student and experimental HDR (and HFR) titles. Biggest question is how clean the HEVC encoding will be. I need to finally order mine.

[FranceBB]

That was certainly how HLG was originally intended to work by the BBC. But the de facto HLG has drifted somewhat; after all, essentially no devices shipped with Rec 2020 and NOT PQ. It must be using 709 primaries or else it wouldn't be backwards compatible.

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...


My take on HLG has been "it may work in practice, but it definitely doesn't work in theory!"


lol
My take is: most users are too "inexpert" to notice...
(and with the term "inexpert" I've been very kind)

[benwaggoner]

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...
HLG's whole premise is the same set of code values will encode two different creative intents on two very different EOTFs, without metadata. So it's fundamentally pretty nuts. I don't know that they're using 709, but I can't imagine what else it would be. Viewing 2020 as 709 looks weird and brown.

My take is: most users are too "inexpert" to notice...
(and with the term "inexpert" I've been very kind)
HLG is mainly being boosted for live broadcast scenarios, where there aren't colorists anyway. Premium content (movies and scripted TV) creatives and technologists aren't fans.

[FranceBB]

I don't know that they're using 709, but I can't imagine what else it would be. Viewing 2020 as 709 looks weird and brown.

I guess we're gonna have to wait 'till someone will upload a sample, then...

[benwaggoner]

I guess we're gonna have to wait 'till someone will upload a sample, then...
Yeah, I need to actually go and buy mine!

[excellentswordfight]

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...
HLG is mainly being boosted for live broadcast scenarios, where there aren't colorists anyway. Premium content (movies and scripted TV) creatives and technologists aren't fans.
I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.

[FranceBB]

I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.

I know exactly what you mean as I use HLG all the times at work to air in BT2020nc + color curve. The compromise is simple: the closer you get to HDR, the worse it looks on SDR BT2020 compatible monitors, the closer you get to SDR BT2020, the less dynamic range you have on those with an HDR compatible TV.
Since HLG is not a purely logarithmic curve its lower part resembles the one of an SDR curve like the Linear BT2020nc SDR 100 nits, but as it gets to the higher values (whites) it resembles more and more a logarithmic curve and therefore introduces dynamic range, hence it doesn't offer many details in the blacks, but it does offer them in the mid-white and therefore it avoids the sky to be clipped out etc. As I said, the problem is that the TVs that don't understand any color curve, but do understand BT2020 are not gonna interpret those things, hence displaying the lower values correctly but not the highlights. Of course, this is intended and it's what the BBC made it for, in fact we've been airing like this for years now.

Here's a comparison of an HDR HLG BT2020nc 600 nits shot.

On a TV which interprets both the color matrix (BT2020nc) and the color curve (HLG) and displays it as intended:
https://i.imgur.com/T7I2bRK.png

On an SDR TV 100 nits which does interpret the color matrix (BT2020nc) but totally ignores the color curve (the "not so bad" fallback as intended by the BBC specs):
https://i.imgur.com/W9TViA6.png

On an SDR TV 100 nits which has no clue about both the color matrix and the color curve and ignores them both (totally wrong display, not acceptable, never should happen):
https://i.imgur.com/sXNb8CI.png


The first image is what we see in our monitors and it's how the whole content is graded and how it should be visualized by people at home. It's HDR, it has a dynamic range of 600 nits.
The second image is what people at home who have an old 4K TV which doesn't support HDR are gonna see. Ignoring the color curve and just interpreting the matrix isn't so bad and it's what the BBC guys were thinking about. The fact that the color curve is ignored makes the image look ok in the lower values/blacks ('cause the HLG is essentially like the Linear BT2020 SDR on the lower part) and "dull"/greyish in the higher values/whites ('cause as it goes up it embraces its logarithmic part).
Lastly, we have something that should never happen and that it's not part of the specs as not only it ignores the color curve, but it wrongly translates the values of the BT2020 so it's totally wrong. This is what happens if you try to watch a BT2020nc HLG stream on a BT709 aware only monitor (so don't do it).


My remarks:
as I said countless times in other topics here on Doom9 before, overall, the result of HLG on BT2020nc only aware monitors is not so bad and HLG makes its fair share to keep things not so unwatchable compared to PQ. In fact, while HLG can be watched on SDR BT2020 monitors, PQ can't and if you attempt to recreate a similar experiment you would get this on an HDR PQ BT2100 aware display:

https://i.imgur.com/pUAUNkb.png

and this crap on an SDR BT2020nc only aware display:

https://i.imgur.com/FVHOeYz.png

This is because PQ is a truly logarithmic curve, so blacks start very high and the "trick" doesn't work...
Of course there are caveats in HLG as not only is limited to 1000 nits maximum, but there's no added benefit for the blacks compared to a BT2020 SDR stream, while the PQ not only can achieve up to 10'000 nits but it does offer a wide range in the blacks as well (although it breaks BT2020 SDR compatibility). On top of this, the example above is done with a 600 nit file, but as we go up, the SDR picture will look more and more grey as we will be essentially pushing mid-tones up and up, so it will look worse (this is what I said at the very beginning "the closer we get to HDR, the worse it will look on BT2020 SDR monitors").
I discussed these things several times both in "General" and in "Development" with Derek and the others and I can say that I'm not too disappointed with HLG as it just works and it allows broadcasters like us to save a lot of bandwidth, especially on our beloved overcrowded Hot Bird where it's pricey.

[nakTT]

Wonder why there's no activity since a little over a month ago. Anyone here know the reason why, or did I missed something. Thank you in advance.

https://bitbucket.org/multicoreware/x265_git/commits/

[LigH]

That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.

[benwaggoner]

I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.
Yeah, HLG seems to give you one of decent SDR OR decent HDR. If you want both, you get mediocre SDR and mediocre HDR.

HLG + dynamic metadata could help that a LOT. One of the key goals/limitations of HLG was that it not require any metadata, because preserving metadata in broadcast is a massive PITA.

[nakTT]

That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.
Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.

[Boulder]

Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.

Based on the mailing list, there's nothing amazing in the pipeline. I think it's safe to say that the application is in a stable status with not much active development going on. The active developers and QA people from the early days have moved on a long time ago.

[LigH]

Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings... :o

[Boulder]

Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings... :o

I'm not sure they possess the proper knowledge, based on what I've seen and tested myself :devil:

[FranceBB]

HLG + dynamic metadata could help that a LOT.

Ahhh!! Dynamic Metadata!! *screams out in pain*

https://media4.giphy.com/media/3o7budXjKD1lTHx7m8/source.gif


Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...

[Boulder]

Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...

Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11 :p

[benwaggoner]

Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11 :p
Oh, all that loudness boost stuff gets applied to the ad's audio source. Then CALM act loudness limitation gets applied to the whole audio channel. It's a weird tech arms race. CALM helped a lot at first, but once the algorithm was codified, working around it became a valuable feature.

[quietvoid]

Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/pipermail/x265-devel/2020-December/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/x265_git/commits/cdb9477e8aa63a763694487f62ff4f5f6e617a30

[vpupkind]

Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/pipermail/x265-devel/2020-December/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/x265_git/commits/cdb9477e8aa63a763694487f62ff4f5f6e617a30

The reason for two-pass is that it messes up with VBV rate control in single pass.

[LigH]

New uploads: x265 32-g57e0b0382 (https://www.mediafire.com/file/tyrhk9miefp978e/x265_3.4+32-g57e0b0382.7z/file)

CLI changes since x265 3.4+30-g6722fce1f:

--scenecut-aware-qp <0..3> Enable increasing QP for frames inside the scenecut window around scenecut. Default disabled
0 - Disabled
1 - Forward masking
2 - Backward masking
3 - Bidirectional masking
--masking-strength <string> Comma separated values which specifies the duration and offset for the QP increment for inter-frames
replaces
--[no-]scenecut-aware-qp Enable increasing QP for frames inside the scenecut window after scenecut. Default disabled
--scenecut-window <0..1000> QP incremental duration(in milliseconds) when scenecut-aware-qp is enabled. Default 500
--qp-delta-ref <0..10> QP offset to increment with base QP for inter-frames. Default 5.000000
--qp-delta-nonref <0..10> QP offset to increment with base QP for non-referenced inter-frames. Default 6.500000

[quietvoid]

The reason for two-pass is that it messes up with VBV rate control in single pass.

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)

[benwaggoner]

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)
Isn't this exactly the sort of thing that --rc-lookahead is for? Plus --gop-lookahead, --lookahead-slices, and --lookahead-threads are all doing "so, what's happening with upcoming frames" stuff.

Seems like an oversight or an upcoming feature. No hard 2-pass requirement for this approach.

[Stereodude]

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?

[stax76]

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?

Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.

[LigH]

Best chance: ffmpeg. Although it may not pass all x265 params.

[qyot27]

Best chance: ffmpeg. Although it may not pass all x265 params.
CLI params, up in the air. API params, it can access all of them using the -x265_params option.

FFmpeg has the advantage that the bit depth you put in is the bit depth you get out. Unlike x265 CLI sampling everything down to 8-bit unless you use --output-depth.

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?
There's a standalone AviSynth+ input now, which takes precedence over LAVF (https://github.com/msg7086/x265-Yuuki-Asuna/commit/0bbb886cbbcf5264c78c93cb96aab72c6873fe0f).

But anyway, here's a build of from November 1st (which means it's just missing the three latest commits from MCW/x265_git) with most* of the x265-Yuuki patches applied onto it:
https://www.mediafire.com/file/2f0k0k0rhrzzo69/x265_3.4%252B53-ge4afbd100.7z/file

*I remember I had to skip some of them because it was complicating the rebase process, or needed updating, or something. But the AviSynth demuxer is there, as is 8+10+12 on both.

[Stereodude]

There's a standalone AviSynth+ input now, which takes precedence over LAVF (https://github.com/msg7086/x265-Yuuki-Asuna/commit/0bbb886cbbcf5264c78c93cb96aab72c6873fe0f).

But anyway, here's a build of from November 1st (which means it's just missing the three latest commits from MCW/x265_git) with most* of the x265-Yuuki patches applied onto it:
https://www.mediafire.com/file/2f0k0k0rhrzzo69/x265_3.4%252B53-ge4afbd100.7z/file

*I remember I had to skip some of them because it was complicating the rebase process, or needed updating, or something. But the AviSynth demuxer is there, as is 8+10+12 on both.
Okay, I'm using AVS+. But that still requires special builds, not something that's in the mainline x265 right?

[qyot27]

LAVF support isn't in mainline x265 either.

[stax76]

Is there a default value for --qp-delta-nonref (https://x265.readthedocs.io/en/master/cli.html#cmdoption-qp-delta-nonref)?

[quietvoid]

The offset is computed from --qp-delta-ref when it is not explicitly specified.
So probably 5 as well.
Edit: It's actually the ref offset * 0.3 apparently.

[Stereodude]

LAVF support isn't in mainline x265 either.
I know, I was just confirming whether I would find the new AVS+ input capability in the mainline or not. Thanks for the build! :thanks:

[vpupkind]

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)
If you increase the QP (i.e., consume less bits), the single-pass VBV RC would lower the QP's onwards because it still has some bits to spare.

[quietvoid]

That sounds like sane behavior to me, what point are you getting at?
I did notice improvements in frames after the scenecut higher QP ones, where there's a benefit in using --scenecut-aware-qp compared to not.
Usually that meant saving around 500 kbps using --detla-ref-qp 2 and the quality was sometimes much better after the scenecut window.

Also this is for 1 pass CRF, not 1 pass CBR.
I still see no reason the feature should be restricted to multi pass.

[Kurtnoise]

Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.
https://github.com/DJATOM/x265-aMod

[Boulder]

That sounds like sane behavior to me, what point are you getting at?
I did notice improvements in frames after the scenecut higher QP ones, where there's a benefit in using --scenecut-aware-qp compared to not.
Usually that meant saving around 500 kbps using --detla-ref-qp 2 and the quality was sometimes much better after the scenecut window.

Also this is for 1 pass CRF, not 1 pass CBR.
I still see no reason the feature should be restricted to multi pass.

There is absolutely no reason for the restriction. In case of a CRF encode without any VBV settings, there is nothing requiring a second pass.

I wonder if the feature could be enabled just by removing some basic check from the code, or is there more inside the various functions?

[quietvoid]

I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.

[Boulder]

I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.

Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.

[stax76]

https://github.com/DJATOM/x265-aMod

Didn't know it, thanks.

[quietvoid]

Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.

Edit: The patch seems to work just fine.
I don't really understand the concept of the non-ref inter frames, because it's increasing the QP on the same frames, except enabling non-ref strength makes it even higher QP (in my test it goes from +4 to +8 when both are set to 10).
Unfortunately, the QP increase seems to be different from the first implementation (apparently it was wrong), setting --masking-strength 500,1,0 is increasing QP by 6, according to the csv log while 10 increases by 8..

Anyways, I fixed it by allowing the offset to be set to 0 (was defaulting to 6.5..). Patch updated.
Seems to be varying the offset depending on the distance from the scenecut frame, where the closest inter frames have higher QP than the ones at the end of the window (allowing negative offset at the end).

Using --masking-strength 500,2,0 makes the offset vary between -1 to +3.5 while 500,2,2 varies between +1.1 to +4.2.
So without using non-ref offset, quality can be increased near the end of the scene cut window while still lowering bitrate a little (in my test this is a 400 kb/s difference). :)

The original x265 patch was pretty incomplete, so anyone feel free to send this upstream. Who knows if it's acceptable.

On top of it all, the last commit "Fix version information reporting for x265 git archival" breaks CMake's version detection. Always returns unknown.
Now this is an actual issue. Someone might want to let them know.

[Boulder]

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.

Edit: The patch seems to work just fine.
I don't really understand the concept of the non-ref inter frames, because it's increasing the QP on the same frames, except enabling non-ref strength makes it even higher QP (in my test it goes from +4 to +8 when both are set to 10).
Unfortunately, the QP increase seems to be different from the first implementation (apparently it was wrong), setting --masking-strength 500,1,0 is increasing QP by 6, according to the csv log while 10 increases by 8..

Anyways, I fixed it by allowing the offset to be set to 0 (was defaulting to 6.5..). Patch updated.
Seems to be varying the offset depending on the distance from the scenecut frame, where the closest inter frames have higher QP than the ones at the end of the window (allowing negative offset at the end).

Using --masking-strength 500,2,0 makes the offset vary between -1 to +3.5 while 500,2,2 varies between +1.1 to +4.2.
So without using non-ref offset, quality can be increased near the end of the scene cut window while still lowering bitrate a little (in my test this is a 400 kb/s difference). :)

The original x265 patch was pretty incomplete, so anyone feel free to send this upstream. Who knows if it's acceptable.

On top of it all, the last commit "Fix version information reporting for x265 git archival" breaks CMake's version detection. Always returns unknown.
Now this is an actual issue. Someone might want to let them know.
Thank you for the patch, I'll try find the time to test it during the Christmas period. Do you feel that the default window of 500 ms is suitable considering subjective quality in motion?

[quietvoid]

Probably, I've used 550 in the past to save a bit more. It's better now that the offset isn't fixed for the whole window.
I can't really notice a difference after ~300 ms (before that the offset is pretty high, but the quality change shouldn't be noticeable) when comparing still shots.

Also the new code avoids selecting scenecuts that are still within a previous window, so in motion it wouldn't be constantly resetting to high QP.

[Barough]

x265 v3.4+33-606265ac7 (https://www.mediafire.com/file/ulla7o5ezjmm43v/x265-3.4%252B33-606265ac7_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[vpupkind]

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.


Are you going to submit it?

[quietvoid]

I don't even know how mailing lists work :)

[Boulder]

I don't even know how mailing lists work :)

I think you can just send your patch in an email to x265-devel@videolan.org. I recall that you have to "sign" some sort of a document but they'll probably tell you where it is located if so.

https://bitbucket.org/multicoreware/x265_git/wiki/Contribute