[HEVC] x265.EXE: mingw builds

[Selur]

seems like adaptive quantization is broken,.. calling

.. | x265-16bit --pmode --pme --input - --input-depth 10 --input-res 704x480 --fps 25 --profile main10 --no-high-tier --no-open-gop --qpfile "H:\Temp\test_07_39_23_1110_06.qp" --aq-strength 1.5 --cu-lossless --colormatrix bt470bg --output "H:\Temp\test_07_39_23_1110_07.265"

x265 crashes after ~80 frames and the only way to fix this is to remove the '--aq-strength 1.5' or the '--cu-lossless'-part

[LigH.de]

For a quick response, this should rather be posted in the mailing list; and I doubt it is very mingw specific...

[LigH.de]

{wrong place}

[Selur]

posted it to the bug-tracker (not a mailing list guy), just posted here to let the other users know,..

[LigH.de]

Is it already fixed in v1.4+382? There was a fix for lossless CUs in patch +381.

[Selur]

Yes, seems to be working again.

[LigH.de]

Another weekly build: x265 1.4+424-2b93cf2a5ac8

[LigH.de]

One of the last x265 v1.4 before v1.5 will start: x265 1.4+465-e2c958ff874e

Because they are fast enough in assembler, Psy-RD and Psy-RDOQ are enabled by default now (if applicable, based on the RD mode). Return codes are documented.

[LigH.de]

x265 1.4+515-cd4117a34a19

Now with temporal layering (--[no-]temporal-layers), which allows video streams with up to 2 layers of temporal resolutions.

IIUC, a slower decoder may use the base layer only to decode with a reduced framerate; the sub-layer will consist of B frames which are unreferenced, to be inserted as higher rate frames when a decoder is fast enough to use them.

[LigH.de]

x265 1.4+527-d26268f9dc19

Psy-RD default is now 0.3; adaptive limit based on quantization and block sizes. Disabling with --no-psy-rd[oq] added.

[LigH.de]

x265 1.4+544-f52d723d8c46: Mostly small bug fixes, improvements and source nits (if I didn't miss any important change).

[LigH.de]

Ladies and gentlemen, this is x265 v1.5:

x265 1.5+9-7a42ca02d198

Time to clean my archive from v1.2 builds...

[DarrellS]

Thanks! Was waiting for a 1.5 release. There were noticeable gains in processing speed in the 1.4 releases.

[El Heggunte]

Minor update...

build 1.5+11-9ab104096834

Changes since commit 7a42ca0

Santhoshini S    9590baa     CLI: remove wrong short option given to max-tu-size

Steve Borho      9ab1040     api: drop fast-cbf option

[LigH.de]

Double-fixed and merged: x265 1.5+21-16e9b6f5aa85

[El Heggunte]

build 1.5+34-039ea966d5eb

Changes since commit c5e50d7

Santhoshini S   324ce36   api: allow minimum CU size to be configured

Steve Borho     8324154   api: nit reorder of defines for better clarity

Steve Borho     3cec180   api: introduce --no-mixed-refs type feature interface

Santhoshini S   37ebb49   cli: add new option --min-cu-size

Steve Borho     910143d   analysis: cleanup load/save member variables

Steve Borho     fce3db4   stats: define a new macro which only increments a counter
                          (no elapsed time)

Steve Borho     039ea96   analysis: remove redundant skip flag check

[LigH.de]

The new builds support NUMA thread pools (enjoy your "render farm")

x265 1.5+77-87173d41df87

[LigH.de]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc

[Jamaika]

Hi
I would like to ask if there are any calculators video that would show pictures/frame posted compression bitrate for a given codec X265.
My example of writing and results for WQHD 10bit i420:

x265_16bpp_v1.5+151.exe "3840x2160_120fps_420_10bit_YUV.yuv" --no-open-gop --input-depth 10 --input-csp i420 --input-res 3840x2160 --fps 120.000 --preset slower --bitrate <10000-30000> --vbv-bufsize 73000 --vbv-maxrate 70000 --bframes 0 --ref 1 --keyint 30 --me star --colormatrix undef --colorprim undef --transfer undef --range limited --pass 2 --output "jockey.h265" 

--bitrate 10000kbps

--bitrate 20000kbps

--bitrate 30000kbps

[Selur]

Have you tried HevcVisa Cloud, CodecVisa, Zond 265, Elecard HEVC Analyzer, or other H.265 analyzers?

[Jamaika]

Thanks for the reply. These are probably paid programs.
The more I thought something in the cloud. As for the photo BPG:
http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&jpg=s&bpg=s

[Gravitator]

The first image shows how large blocks 64 instead positive demonstrates detrimental effect (stairs instead of the horse's legs).


Developers on this project Daala predicted losing HEVC (impasse).
They went on a promising / innovative thorny path of development (not to step on a rake).

http://wiki.xiph.org/Daala

Daala is the code-name for a new video compression technology.
The effort is a collaboration between the Mozilla Foundation, the Xiph.Org Foundation and any other contributors that wish to help.
The goal of the project is to provide a free-to-implement, -use and -distribute digital media format
and reference implementation with technical performance superior to H.265.

http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml

The next-generation VP9 and HEVC codecs are the latest incremental refinements of a basic codec design that dates back 25 years to h.261. This conservative, linear development strategy evolving a proven design has yielded reliable improvement with relatively low risk, but the law of diminishing returns is setting in. Recent performance increases are coming at exponentially increasing computational cost.

Daala tries for a larger leap forward— by first leaping sideways— to a new codec design and numerous novel coding techniques. In addition to the technical freedom of starting fresh, this new design consciously avoids most of the patent thicket surrounding mainstream block-DCT-based codecs. At its very core, for example, Daala is based on lapped transforms, not the traditional DCT.

[Jamaika]

Thanks for the info. All very well, but where you can download these codecs Daala? How are they different from advertising XHEVC, Elecard, Mainconcept or LEADTOOLS? Everyone says that it is better than previous only you can not see it because it is expensive programs.
https://forum.videohelp.com/threads/365788-Create-a-theme-Daala-vs-HEVC
The second thing is, what are the time of conversion. For X265 v1.5 at 600 frames WQHD 120fps 2-pass was on my old computer i5 2500k 25min.
For DivX265 1-pass 60fps only 8min, two times less frames, but the quality is much better at 10000kbps. What is wrong?

[Gravitator]

All very well, but where you can download these codecs Daala?

Daala has in alpha form (can be found on the forum doom9.org).

How are they different from advertising XHEVC, Elecard, Mainconcept or LEADTOOLS?

No clue.

-------
I have already asked about the use of the analyzer for the study of such problems:

> theory 1
> theory 2

What happens on the first picture ... I have already raised this issue And suspicions lead to:

1. Smoothing pushes pixels (located on the edge of the block) outside of the block. The lower bits in the block, the greater the likelihood that the edge pixels will fall out.
- This is the direction you need to do to improve (try to keep the extreme / corner pixels).

2. After smoothing in the block edge pixels fall on the neighboring block (become a foreign body); Strips of wood.
- It's interesting.

The second thing is, what are the time of conversion. For X265 v1.5 at 600 frames WQHD 120fps 2-pass was on my old computer i5 2500k 25min.
For DivX265 1-pass 60fps only 8min, two times less frames, but the quality is much better at 10000kbps. What is wrong?

Expect that DivX265 more uniform smoothing, and therefore better at visual (small difference between the blocks avoids not pleasant contours / joints).
And frames at DivX265/60 against x265/120 DivX265 has a restriction profile UHD@60fps (restriction is lifted soon because the advent of hardware decoders).

------

Basically, the problem of low settings, and combinations thereof. Since the demonstration videos only pleasing to the eye
> http://demo-uhd3d.com/
> http://www.elecard.com/ru/download/clips.html (Elecard representative DivX).

[LigH.de]

If you want to advertize for Xiph Daala, why do you post in a thread about MinGW builds of x265? Make your own instead.

[Jamaika]

Sorry. Information about my the test Daala is here: https://forum.videohelp.com/threads/365788-Create-a-theme-Daala-vs-HEVC

[Selur]

Please and it would be nice if further discussions of other stuff could take place inside another thread. (Getting email notifications about totally off-topic content is kind of annoying!)

Thanks!

[LigH.de]

After some compiling issues due to removing assembler optimization from 32 bit code with 16 bit depth, I finished another package today: x265 1.5+200-726fe4088f31

There is a rather new option --rdoq-level (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets use value 2 from "slow" on, else 0.

[Selur]

strange, didn't see any commit which contained something about rdo-level in it's summary,...

[LigH.de]

9626 (79d9a1489616)

"api: make RDOQ level externally configurable, make two levels visible"