x265 HEVC Encoder

[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/qnc7l7...8a713.rar/file

[nakTT]

Originally Posted by 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/qnc7l7...8a713.rar/file

Any interesting changes from version 3.2?

[Greenhorn]

Originally Posted by nakTT

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]

Originally Posted by Greenhorn

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]

Originally Posted by nakTT

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/...leasenotes.rst

download: http://www.mediafire.com/file/op10k0...c5fa9d.7z/file

[nakTT]

Originally Posted by benwaggoner

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.

Originally Posted by filler56789

x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/...leasenotes.rst

download: http://www.mediafire.com/file/op10k0...c5fa9d.7z/file

Thanks, will give it a try.

[Boulder]

Originally Posted by benwaggoner

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.

[HolyWu]

https://www.mediafire.com/file/uth0n...32737d.7z/file

x265 [info]: HEVC encoder version 3.3+1-f94b0d32737d
x265 [info]: build info [Windows][Clang 9.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.38.101)
x265 [info]: (libavcodec  58.70.100)
x265 [info]: (libavutil   56.41.100)

[benwaggoner]

Originally Posted by Boulder

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]

Originally Posted by nakTT

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.

[Boulder]

Originally Posted by benwaggoner

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 just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames .. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.

[LigH]

How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.

[Greenhorn]

Originally Posted by LigH

How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.

All 3 branches appear to be at version 3.3+1 with different commit numbers; the two patches after 3.3+1 consisted solely of merging the Master branch with the Stable and Release_3.3 branches.

(IDK anything about any VCS, so I have no idea if this is as expected or not-- but my point being, the latest files at the moment will be tagged 3.3+1.)

[benwaggoner]

Originally Posted by Boulder

I just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames .. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.

Have you looked at where the cuts are relative to the IDR frames? Is it sticking IDRs in the middle of shots?

Sent from my SM-T837V using Tapatalk

[LigH]

Let's assume those are the tiny differences between Git and Mercurial, regarding the counting of version numbers and patch increments. Hard to compare "the same build" then ...
_

PS:

In previous versions I was used to reading only CMake output on the console while x265 is built. Now, suddenly, make clutters the output by reporting verbosely that it is e.g. entering and leaving directories. May that be a new default behaviour of make, of the shell, or of the media-autobuild suite having set an environment variable in a way that it changes the output also in interactive shell mode?


x265 3.3+1-g396395b2b

[filler56789]

LigH's latest build of x265.exe says:

version = 3.3+1-g396395b2b

whereas the latest build of x265.exe by http://msystem.waw.pl/x265/ says:

version = 3.3+1-g554c887ac

But according to the page https://bitbucket.org/multicoreware/x265/commits/ ,
those commit numbers don't exist.

[LigH]

You are looking in the Mercurial repository, while I got the sources via Git instead (the hash has a g prefix). Try: https://bitbucket.org/multicoreware/x265_git/commits/ (note the x265_git)

Apparently, merges don't increase the patch count for Git; they did in Mercurial, though.

[filler56789]

Yeah, git is a total mess.

Mercurial apparently is less messy.

x264, for example, doesn't add the prefix "g" to the commit number.

x264 0.159.2991 1771b55