x265 HEVC Encoder

[benwaggoner]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss? :)
What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

[Boulder]

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.

[Atak_Snajpera]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss? :)

--ctu 32

[benwaggoner]

--ctu 32
Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

[benwaggoner]

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.
Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

[jlpsvk]

What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

I am encoding 2160p, with CRF16.

[Boulder]

--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

This probably affects frame type decision, at least that's what I observed when using four lookahead slices compared to just one.



--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.
Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

It's probably due to the encoder doing deeper analysis as some performance related early skips are avoided. Nevertheless, I got a clip of the scene for my testing toolkit and I can definitely create a ticket for the issue. Maybe there is something there to fix.

[jlpsvk]

i tested, and without pme and pmode, it's faster. :D

[microchip8]

Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them? :)

[jlpsvk]

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them? :)

exactly... my 2160p HDR10 preset currently...any suggestions?

--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star

[microchip8]

exactly... my 2160p HDR10 preset currently...any suggestions?

--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star

I'd set deblock to -1,-1 instead of completely disabling it - deblock has seen a major revision compared to x264.

Also strong-intra-smoothing seems to have a positive effect at keeping noise. Many people are scared by the name but I find it does improve things a bit. It will help reduce banding on very clean scenes too, like skies or other clean textures, by blending a bit instead of keeping the banding

merange has no effect when using HME since the latter has its own range parameters you can adjust with --hme-range

[Boulder]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better :)

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too :devil:

[microchip8]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better :)

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too :devil:

I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1

As for psy-rd/psy-rdoq, they are meant to keep the original energy of the source as much as possible at higher strength. So if you have a (very) noisy sample, the bitrate will shoot up in order to preserve the noise/grain. These two settings are set to high values when using --tune grain (psy-rd is set to 4 and psy-rdoq is set to 10). I personally now use psy-rd of 3.2 and psy-rdoq of 15. I do not mind the increase of bitrate as I aim to preserver the input as much as possible. These two especially have an effect on dark scenes and look better than using AQ mode 2 or 3. I haven't tested AQ mode 4, though

[benwaggoner]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.
I finished making the content but not my comparisons. Thanks for the reminder to take a look again.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.
Maybe throw in some --nr-inter? That tends to reduce grain swirling and lower QPs a bit at the same bitrate.

[benwaggoner]

I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1
The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.

[microchip8]

The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.

I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes

[Boulder]

If you want to try things, I uploaded the sample clip I used to test: https://drive.google.com/open?id=1Ar0sKvjc6ygGtmW6DA5cr6UNO1WjfV7- . Take a look at the flat background in the shots with the cop, it's ugly in the source and gets much worse after encoding.

[benwaggoner]

I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes


Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.

[microchip8]

Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.

I won't be bothered doing this. At the moment I'm quite happy with my own setting for CRF @ 21. I increased some of them by a small amount to give it a bit more headroom. If I can compress a source of say 22-25 GiB down to 5-6 or 7 GiB (with decent quality according to my eyes), I'm a happy camper

[zerowalker]

Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.
And then it looked crap anyway so even if x265 won it didn't really matter (for me).

How is it nowadays (know it's a vague question)?

If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?

I know it sounds like i am saying x265 is crap compared to x264, but that's not what i am trying to say, but it's hard to ask the comparison question without making it sound that way.
I am not denying x265 nor the standard h265, it's obviously made for a good reason and the encoder is surely aiming to be as great as possible compared to what currently exists (either for all or some cases),
i just don't know that much about it except that the standard was made with very high resolutions in mind as h264 breaks down quickly there except with very high bitrates (which is the "throw money at the problem" solution usually;P).

Thanks:)

[MeteorRain]

zerowalker, I can't answer your question but I do have a question for you. Were you using 10-bit and were you comparing 10-bit x265 against 8-bit x264?

We / I switched to x265 simply because we wanted to use 10-bit and AVC High10 had some compatibility issues with hardware players.

[benwaggoner]

If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?

If you're trying to get the best image in a fixed amount of bits, x265 beats x264 in the large majority of scenarios. A big part of this is you can use HEVC at a higher resolution, preserving a lot more detail by preserving more pixels. CRF comparisons are more complex, as it's not a linear relationship. Even just using x264 the same CRF gives different results depending on other parameters.

The biggest problem with x265 years ago was how it handled grain, which is much improved now.

[birdie]

Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.

This is still largely true: x265 is better for resolutions above 1080p and for very low bitrates (which are mostly suitable for streaming anyways).

[LigH]

But the general rule remains: There is no magic. Size reduction requires a loss of quality. It's just a matter how annoying you rate this kind of loss.

[LigH]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

[filler56789]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

1) Thanks for the info *THUMBS UP*

2)

downloading with Mercurial = 35.4 MB, very fast;

downloading with git = 290 MB, very slow;

x265_git\.git\objects\pack\pack*.pack = 276 MB — ¿what the devil is that?

[Boulder]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

I think an initial "git clone" followed by "git pull" every time you need to update would do. You may need to set the branch which you want to follow, I don't have any knowledge on that.

[MeteorRain]

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

If you are not used to Git, I strongly recommend using a GUI to help learning. Personally I love SmartGit the best, but it's a proprietary software (free for non-commercial use).

Pull updates from remote to local is "git fetch".

Pull updates from local to working directory is "git checkout".

Git is much more flexible (and thus harder to use) that's why I always recommend people to use a GUI to get started. There are more concepts in Git than in Hg and it takes time to get used to.

[filler56789]

Just re-checking...

the latest cloned x265/.hg directory = 23.2 MB
Apparently the "conversion" of x265's Hg repository into git included or added some TONS of *garbage*...

[MeteorRain]

I don't understand the point of mentioning the size of the repository.
I use Git not for saving 200MB of space, but for managing the source code.
I'd happily trade a few gigabytes of my "precious?" hard drive space for a tool that works better to me.

To answer your previous question, git object pack is a compressed package of all kinds of objects used by git, including histories, files, deltas, etc.
If network activity is a real concern to you, you can limit the depth of repository to download. You can choose to only download and store the most recent 500 commits, for example, and still work on that as long as you don't need access to history more than 500 commits back.

[qyot27]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?
Easy:
git pull (like was mentioned above)

More exact (like when following more than one upstream HEAD):
git fetch <remote>
git merge <remote>/<branch>

which would look like:
git fetch origin
git merge origin/master (to update the master branch to its current remote state)


If you don't care about being able to recover the file or commit history and just want raw download speed:
git clone --depth 1 https://bitbucket.org/multicoreware/x265_git

Git is, as others have noted elsewhere, basically a time-based file system that happens to work great as a DVCS. Mercurial is just a DVCS.

[filler56789]

...
If you don't care about being able to recover the file or commit history and just want raw download speed:
git clone --depth 1 https://bitbucket.org/multicoreware/x265_git

:goodpost: :thanks:

I don't understand the point of mentioning the size of the repository.
I use Git not for saving 200MB of space, but for managing the source code.
I'd happily trade a few gigabytes of my "precious?" hard drive space for a tool that works better to me.


Because the size of the hg repository is much smaller than the git one?
Because I'm old and therefore much more impatient than you?
Because I think that "huge and cheap" storage space is not an excuse for inefficiency?

To answer your previous question, git object pack is a compressed package of all kinds of objects used by git, including histories, files, deltas, etc.

Then it compresses much worse than hg, or at least it seems so...

If network activity is a real concern to you, you can limit the depth of repository to download. You can choose to only download and store the most recent 500 commits, for example, and still work on that as long as you don't need access to history more than 500 commits back.

Yes, my interest in x265's source-code is only to download and compile its most recent stuff, I have no use for a 300 MB """compressed""" archive that is not the code that I intend to compile.

[MeteorRain]

Then do a shallow clone like we posted.
We are developers and functionality is much more important for us than a few hundred megabytes.
No, huge and cheap storage is not an excuse for inefficiency, however this is not inefficiency, this is only "space" inefficiency.
You don't say ffmpeg is garbage because it's a 60MB binary.

BTW, compared to a few seconds of downloading, the actual compiling is much more time consuming.
I'm too impatient but each time I compile my x265 mod it will take a good 2 hours on a Xeon E5 server.

[LigH]

Since the media-autobuild suite switched to the x265 Git repository, I have trouble retrieving the sources. It seems like git receives all the expected data, but then suddenly handles the closing connection as if it was interrupted in an error. Here from an interactive MSYS2/MinGW console:

$ git clone https://bitbucket.org/multicoreware/x265_git.git x265_git-git
Cloning into 'x265_git-git'...
remote: Counting objects: 88154, done.
remote: Compressing objects: 100% (88115/88115), done.
remote: Total 88154 (delta 2853), reused 85263 (delta 0)
error: RPC failed; curl 56 OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal because this is a curl debug build)
Receiving objects: 100% (88154/88154), 277.47 MiB | 1.58 MiB/s, done.
Resolving deltas: 100% (2853/2853), done.

Retrieving Git repositories from other sources works without error. So I wonder if Bitbucket may handle little details differently. If so ... I may not be able to report this issue to Bitbucket, as I am not the Atlassian customer responsible for the x265 repo.

[LigH]

I'll see if this Windows 7 hotfix (https://support.microsoft.com/en-us/help/981344/an-application-may-receive-the-10054-error-when-the-application-receiv) has any impact...

Oh, it has been discontinued. I need Windows 10 to solve it. :p

Or it is a different one? It's errno 0, not SysCall 10054.

Cloning x264 and dependent ffmpeg/ffms2/lsmash works without abort.

:eek:

After x264 was retrieved (I deleted build/x264-git), now x265 was retrieved too? ... Strange technology. :o

[Barough]

No issues with the change to x265 git. Just running smooth here.

Sent from my SM-G975F via Tapatalk

[foxyshadis]

I'll see if this Windows 7 hotfix (https://support.microsoft.com/en-us/help/981344/an-application-may-receive-the-10054-error-when-the-application-receiv) has any impact...

Oh, it has been discontinued. I need Windows 10 to solve it. :p

Or it is a different one? It's errno 0, not SysCall 10054.

Cloning x264 and dependent ffmpeg/ffms2/lsmash works without abort.

:eek:

After x264 was retrieved (I deleted build/x264-git), now x265 was retrieved too? ... Strange technology. :o

Git is an abominable piece of trash IMHO, but it's what we're stuck with, since hg is rapidly disappearing. (I'm going to have to convert all of my repos, too.) 99% of all git problems are best solved by just deleting the entire folder and cloning from scratch. Sometimes a hard revert will also do the trick, but not as reliably. If you have changes, just try to pull a patch and reapply after.

[LigH]

Cloning was just the problem. Or handling the HTTPS connection.

[MeteorRain]

Try ssh protocol instead?

[LigH]

Well, it suddenly worked once (when I let it clone x264 before x265). Maybe just something on my PC was out of sync.

[filler56789]

x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

regression: fix analysis-save/load commands

http://www.mediafire.com/file/qnc7l7eiohbiejq/x265_3.3_RC1%252B2-e386d3a8a713.rar/file

[nakTT]

x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

regression: fix analysis-save/load commands

http://www.mediafire.com/file/qnc7l7eiohbiejq/x265_3.3_RC1%252B2-e386d3a8a713.rar/file
Any interesting changes from version 3.2?

[Greenhorn]

Any interesting changes from version 3.2?

Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.

[nakTT]

Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.
Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.

[benwaggoner]

Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk

[filler56789]

x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/x265/src/057215961bc4b51b6260a584ff3d506e6d65cfd6/doc/reST/releasenotes.rst

download: http://www.mediafire.com/file/op10k0vpygdq3du/x265_3.3%252B3-c2769ac5fa9d.7z/file

[nakTT]

Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk
Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.

x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/x265/src/057215961bc4b51b6260a584ff3d506e6d65cfd6/doc/reST/releasenotes.rst

download: http://www.mediafire.com/file/op10k0vpygdq3du/x265_3.3%252B3-c2769ac5fa9d.7z/file
Thanks, will give it a try.

[Boulder]

Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.

[benwaggoner]

Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.
Not myself yet. I'm currently at the HPA tech retreat. I should have some physical and CPU time to run some tests next week.

I didn't mention the Adaptive frame duplication feature. This promises some significant efficiency savings and also faster random access for content where there are identical frames. Credits, screen activity, and anime/cel animation seem particularly likely to get improvements.

I wish there was an optional flag that can allow --keyint to limit total encoded frames, so --keyint 240 would mean 240 unique coded frames. Thus, with 24 fps where the animation is at 8 fps (so three duplicate frames in a row), --keyint 240 would yield a GOP covering 30 seconds instead of 10. Not great for adaptive streaming, but could save space for a file without impacting random access.

[benwaggoner]

Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.
Encoders are never done; we're still seeing improvements to MPEG-2 encoding after all these years. Particularly as long as Moore's Law keeps happening, we'll always find ways to take advantage of more MIPS/pixel.

With a codec as complex as HEVC, I would expect we'll be seeing material year-on-year encoder improvements for at least another five years.