[HEVC] x265.EXE: mingw builds

[LigH.de]

Not from me. I do not own even one AVX capable CPU. But you can read about speedups of small routines separately in the commit remarks in the source repository.

https://bitbucket.org/multicoreware/x265/commits/all

[LigH.de]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 / 5.2.0) (multilib EXE's only) with a changed NUMA pool strategy

[-Habanero-]

It's "Numa numa yay!" Get it right you hapless German fiend.

[LigH.de]

^ reports about a slightly buggy code in the doom9 forum

[-Habanero-]

No more builds from Ligh?

[LigH.de]

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)
x265 1.7+497-975352b2c022 (GCC 5.2.0)

[LigH.de]

After fixing the scene change adaption, here is the new milestone as "merge with stable" build:

x265 1.8+2-55a4a9b920ff (GCC 4.9.2)
x265 1.8+2-55a4a9b920ff (GCC 5.2.0)

[DarrellS]

Which file replaces x265.exe ? I assume x265_ml.exe since it is 15,505kb and x265.exe from 1.7.xxx is 13,338kb or is it x265_main.exe (5,347kb)? Also, can I rename the file to x265.exe or does the .dll expect a certain file name?

[LigH.de]

The x265_ml.exe is the "static multilib build" which does not need any additional DLLs. If you want to reduce the number of files and only encode, use this as your only EXE file with any name you like (most probably x265.exe).

The other files are only included for completeness' sake; e.g. for the case that someone wants to reduce the size of a release archive by omitting some functionality (include only the EXE for one bitdepth per default) and offering additional bitdepths as optional downloadable DLLs, or wants to write a different application which would use the DLLs as pluggable encoders.

• x265_ml.exe = static multilib build, includes 8 + 10 + 12 bit depth encoder (possibly the only one most people need)
• x265_main.exe = only 8 bit depth encoder included; may require x265_main10.dll or x265_main12.dll if used with -D 10 or -D 12
• x265_main10.exe = only 10 bit depth encoder included; may require x265_main.dll or x265_main12.dll if used with -D 8 or -D 12
• x265_main12.exe = only 12 bit depth encoder included; may require x265_main.dll or x265_main10.dll if used with -D 8 or -D 10

If an EXE loads a DLL, it needs to know the filename of the DLL; in the opposite direction, a DLL usually does not know which process uses its functions or resources.

[LigH.de]

Weekly default build with several additional fixes after the milestone stable:

x265 1.8+31-b6156a08b1de (GCC 4.9.2)
x265 1.8+31-b6156a08b1de (GCC 5.2.0)

[DarrellS]

Thanks! I keep all my command line encoders in C:\Tools and try to keep the folder as neat as possible so I have my x265 encoders in C:\Tools\x265 and copy just the files I need to C:\Tools. When an encoder gets obsolete then I'll delete the folder, like C:\Tools\x265\x265_1.7+180-d6c32960b5df etc...

[LigH.de]

Weekly build; contains a linking order bugfix and a new option:

   --intra-refresh               Use Periodic Intra Refresh instead of IDR frames

Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe.

I could imagine that this feature might be incompatible with some consumer devices or authoring standards, who knows ...

x265 1.8+49-f335a9a7b908 (GCC 4.9.2)
x265 1.8+49-f335a9a7b908 (GCC 5.2.0)

[LigH.de]

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2)
x265 1.8+60-6563218ce342 (GCC 5.2.0)

[LigH.de]

Weekly build: A few bug fixes, speed ups, and:

   --[no-]limit-modes            Limit rectangular and asymmetric motion predictions. Default 0

When enabled, limit-modes will limit modes analyzed for each CU using cost metrics from the 4 sub-CUs. When multiple inter modes like --rect and/or --amp are enabled, this feature will use motion cost heuristics from the 4 sub-CUs to bypass modes that are unlikely to be the lowest. This can significantly improve performance when --rect and/or --amp are enabled at minimal compression efficiency loss.

So I believe "Default 0" means: There's no limit!

x265 1.8+76-bd8237a5d782 (GCC 4.9.2)
x265 1.8+76-bd8237a5d782 (GCC 5.2.0)

[-Habanero-]

   --intra-refresh               Use Periodic Intra Refresh instead of IDR frames

Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe.

I don't get it, what will this solve?

[poisondeathray]

   --intra-refresh               Use Periodic Intra Refresh instead of IDR frames

Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe.

I don't get it, what will this solve?

It looks to be same idea as x264's PIR ; ie. it's used for low latency, streaming scenarios .

Periodic Intra Refresh completely eliminates the concept of keyframes: instead of periodic keyframes, a column of intra blocks moves across the video from one side to the other, “refreshing” the image. In effect, instead of a big keyframe, the keyframe is “spread” over many frames. The video is still seekable: a special header, called the SEI Recovery Point, tells the decoder to “start here, decode X frames, and then start displaying the video”–this hides the “refresh” effect from the user while the frame loads. Motion vectors are restricted so that blocks on one side of the refresh column don’t reference blocks on the other side, effectively creating a demarcation line in each frame.

Immediately the previous steps become relevant. Without keyframes, it’s feasible to make every frame capped to the same size. With each frame split into packet-sized slices and the image constantly being refreshed by the magic intra refresh column, packet loss resilience skyrocketed, with a videoconference being “watchable” at losses as absurd as 25%.

No longer does 200ms seem out of reach. If anything, it’s now far more than we need. Because with –tune zerolatency, single-frame VBV, and intra refresh, x264 can achieve end-to-end latency (not including transport) of under 10 milliseconds for an 800×600 video stream.

[LigH.de]

This technique should spread the bitrate burst of I frames across slices in more or less adjacent frames, so the VBV max fillrate won't get hit so hard at one specific frame, and following P/B slices don't need so much degradation to counter the high decoding buffer fill level (reducing a "quantization pumping"); this should be most important in a streaming scenario with smaller bandwidth, and best usable in videos with generally little motion.

It was explained better in the doom9 forum:

Intra-refresh isn't used for high quality encoding for streaming or file-based playback. It's helpful in real-time low latency video applications. Spreading the intra-predicted blocks out across multiple frames means that you don't have one really big I frame followed by smaller P and B frames. In low-latency applications through a fixed channel bandwidth, this is helpful. Of course there are trade offs to overall compression efficiency. With a moving camera or moving subjects prediction suffers as you don't have a single stable reference frame that captured everything. But for fixed-camera low-latency video (like video conferencing), intra-refresh can be beneficial.

[-Habanero-]

Ah, thank you both, I understand now. I remember this I-frame bitrate disparity issue being particularly a problem with very low bitrate encodes I did during my many experiments. The SSIM values would always spike on keyframes and comparing it to other encodes frame-by-frame was hard because of this.
I guess this would be useful for webcams though. In the early 90s MPEG-1 was built for video conferencing on an ISDN line which was 64-128 kb/s and the resolution probably 320x240. I'm guessing the quality sucked.
I wonder if x265 today with this PIR function can produce a high quality webcam session at such low bitrates.

[LigH.de]

PIR will probably be one of the less important features of HEVC why it certainly will look better. Just one reason why there may be less "GOP pumping". I wouldn't be surprised to see HEVC already used in tools like Skype, but I don't have current specs available to point at them.

[LigH.de]

After a longer while without commits, now another build with important changes. This one might be related to the loss of details, as discussed in the doom9 forum:

intra prediction: disable 64x64 analysis

In intra CUs, the predictions are applied for each TU sequentially (and not at the
PU level). This patch turns off all 64x64 intra analysis/modes - to analyse which,
previously, x265 averaged a 64x64 block to 32x32 and then did a prediction search
on this averaged block. This is a bad idea for visual quality, and instead x265
will perform 32x32 predictions sequentially.

x265 1.8+106-e8f9a60d4cd9 (GCC 4.9.2)
x265 1.8+106-e8f9a60d4cd9 (GCC 5.2.0)

[Selur]

Wouldn't it be better if they fixed their prediction algorithms instead of disabling 64x64 analysis all together? Shouldn't this at least for high resolution content make sense?

[LigH.de]

We might guess whether they disabled it mainly for testing if that is really the most important reason. So let's test while we wait for an explanation...

And they disabled not all 64² analysis code, only the one for intra blocks.

[LigH.de]

Some interesting patches still on hold; releasing another "weekly" anyway, since I postponed the last.

x265 1.8+129-e2e507ffe752 (GCC 4.9.2)
x265 1.8+129-e2e507ffe752 (GCC 5.2.0)

[LigH.de]

Current state:

x265 1.8+167-e951ab673b1c (GCC 4.9.2)
x265 1.8+167-e951ab673b1c (GCC 5.2.0)

New documented 'K' frametype ("keyframe", exact type depending on circumstances), several speedups and fixes (mostly in sao).

[LigH.de]

Merry Christmas (or similar holidays) with a current build with updated preset defaults (e.g. limit-modes/refs; please RTFM).

x265 1.8+187-da48f2690076 (GCC 4.9.2)
x265 1.8+187-da48f2690076 (GCC 5.2.0)

[eca2424]

@LigH.de hello, can you please build this https://bitbucket.org/multicoreware/x265/downloads please build and share x265.exe 1.5 and 1.6. I didnt built. please build and share exe
Sory my bad english

[LigH.de]

Doesn't make much sense to mourn about obsolete versions; but as you like ... Happy New Year.

I did not download the tar archives, but downdated my working directory via Mercurial to the commit with the version tag (or closest "merge with stable"). Only 8 and 10 bit separate binaries, I was too lazy to downdate my multilib workflow (and 12 bit may not have existed yet).

[eca2424]

Doesn't make much sense to mourn about obsolete versions; but as you like ... Happy New Year.

I did not download the tar archives, but downdated my working directory via Mercurial to the commit with the version tag (or closest "merge with stable"). Only 8 and 10 bit separate binaries, I was too lazy to downdate my multilib workflow (and 12 bit may not have existed yet).

many many many thanks Can you please 1.8 ?

[LigH.de]

x265 1.8+2-55a4a9b920ff is close enough.

[eca2424]

Okey Thanks.