[HEVC] x265.EXE: mingw builds

[vhelp]

none of the builds are working from yours and LegH's compiles. The last one that has worked for me is 1.9_227 then i skipped to 2.0_016, and from that ver onward, none work. tried both 32 and 64 bit versions (under my dell laptop windows 7 home prem, 64bit, but have not tried on my desktop win xp) I keep getting the error message:

.
.
Complete documentation may be found at http://x265.readthedocs.org/en/default/cli.html
370x265_2.0+045-7f9aeed70c0d.7z_x265ml32.exe: ambiguous option -- log
x265 [info]: HEVC encoder version 2.0+45-7f9aeed70c0d
x265 [info]: build info [Windows][GCC 4.8.5][32 bit] 8bit+10bit+12bit
avs  [info]: Avisynth 2.6+ detected, forcing conversion to YV12
avs [error]: Error occurred while writing frame 0
(Maybe x264_64.exe closed)

and

.
.
Complete documentation may be found at http://x265.readthedocs.org/en/default/cli.html
370x265_2.0+045-7f9aeed70c0d.7z_x265ml64.exe: ambiguous option -- log
x265 [info]: HEVC encoder version 2.0+45-7f9aeed70c0d
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit+10bit+12bit
avs  [info]: Avisynth 2.6+ detected, forcing conversion to YV12
avs [error]: Error occurred while writing frame 0
(Maybe x264_64.exe closed)

and my last log out (from my custom gui4hevc app)

LastParamStringUsed: c:\videos\video.2.0.045.video.A.01.ultrafast.hevc       KB 00:00:00  0.00 avs4x265 -P 370x265_2.0+045-7f9aeed70c0d.7z_x265ml32.exe --preset ultrafast --frames 117 --crf 17 --ssim --log 3 --csv c:\videos\video.2.0.045.video.A.01.ultrafast.csv -o "c:\videos\video.2.0.045.video.A.01.ultrafast.hevc" "C:\tools\vid.avs"
LastParamStringUsed: c:\videos\video.2.0.045.video.A.01.ultrafast.hevc       KB 00:00:00  0.00 avs4x265 -P 370x265_2.0+045-7f9aeed70c0d.7z_x265ml64.exe --preset ultrafast --frames 117 --crf 17 --ssim --log 3 --csv c:\videos\video.2.0.045.video.A.01.ultrafast.csv -o "c:\videos\video.2.0.045.video.A.01.ultrafast.hevc" "C:\tools\vid.avs"

[LigH.de]

Read the error message, and don't blame x265 – but instead the application calling it with outdated parameters:

ambiguous option -- log

Unfortunately, you keep the most important details hidden from us. Cutting a snippet out of a whole log is a bad idea. Let me guess, you are using a tool which reads an AviSynth script and pipes the video output to an x265 encoder; which tool is that (maybe avs2yuv or avs2pipemod or avs4x26x), what is its complete command line?

There is no parameter "--log" for current x265 versions. Therefore x265 halted before the piping tool could send any frame to x265.
__

P.S.: Ah, you posted command lines...

"--log 3" is officially unsupporded for a bit longer already, maybe they just forgot to remove it earlier. There are now the following options:

   --log-level <string>          Logging level: none error warning info debug full. Default full
   --no-progress                 Disable CLI progress reports
   --csv <filename>              Comma separated log file, if csv-log-level > 0 frame level statistics, else one line per run
   --csv-log-level <integer>     Level of csv logging, if csv-log-level > 0 frame level statistics, else one line per run: 0-2

You can select separate log levels for console output and CSV table logs.

[El Heggunte]

commit 67e07065c678

Yes$S, more bugfixes https://bitbucket.org/multicoreware/x265/commits/all

[LigH.de]

And I was just about to publish 2.0+49 ... let's see where we are tomorrow.

[Jamaika]

commit 67e07065c678

Yes$S, more bugfixes https://bitbucket.org/multicoreware/x265/commits/all

Buuuu..., it don't work.

[El Heggunte]

....

Buuuu..., it don't work.

Define "it don't work"

I have just tested both builds, 32-bits and 64-bits... the resulting streams played fine, and the HEVC Analyzer saw no problems in them

[Jamaika]

That here is to define? It's critical error in 64bit.

[El Heggunte]

^ That screen shot is incomplete, and to make things worse, you let the error message window hide important information -.-

[Ma0]

That here is to define? It's critical error in 64bit.

Interesting. Could you share your command line to reproduce this bug?

[Jamaika]

Command line:
http://forum.doom9.org/showthread.php?p=1779998#post1779998

[El Heggunte]

Command line:
http://forum.doom9.org/showthread.php?p=1779998#post1779998

I could reproduce the problem
Removing the switches --vbv-maxrate 40000 and --vbv-bufsize 40000 did let x265 "work normally"

NOTICE: I have never used x265 for encoding with 2-passes, so I don't know whether the problem is in the program, OR in the command-line switches chosen by Jamaika...

[Jamaika]

I have one more question. Is codec X265 can automatically switch on high-tier?
In version 2.0+24 turn on itself. In version 2.0+45 off function.

[Ma0]

Command line:
http://forum.doom9.org/showthread.php?p=1779998#post1779998

Thanks! I can reproduce this bug too. After US Open semis I will start analyze.

[LigH.de]

I remember there was a following patch in the rate control. Maybe it has been fixed already in the commits...

[Ma0]

It was broken at 2.0+50 and it is still broken.
It hangs at line https://bitbucket.org/multicoreware/x265/src/6ee705ecb4332ecd3be35797d270662bfd95f4e2/...ncoder.cpp-278
with trSize = 3, numList = 1 -- table index [3][1].

Interesting that from 2.0+50 there is a special case for first index = 3:
https://bitbucket.org/multicoreware/x265/src/6ee705ecb4332ecd3be35797d270662bfd95f4e2/...nglist.cpp-142
if the first index is 3 then the memory is allocated at second index only with step 3 -- [3][0], [3][3] and so on, there is no allocation for [3][1].

[Ma0]

x265 team is working on the fix. I've prepared unofficial patch:

diff -r 6ee705ecb433 source/common/scalinglist.cpp
--- a/source/common/scalinglist.cpp	Thu Sep 08 17:32:28 2016 +0200
+++ b/source/common/scalinglist.cpp	Fri Sep 09 16:25:45 2016 +0200
@@ -153,6 +153,15 @@
             }
         }
     }
+    for (int listId = X265_MIN(NUM_LISTS - 3, 3); --listId > 0;)
+    {
+        m_scalingListCoef[3][3 - listId] = m_scalingListCoef[3][3 + listId] = m_scalingListCoef[3][3];
+        for (int rem = 0; rem < NUM_REM; rem++)
+        {
+            m_quantCoef[3][3 - listId][rem] = m_quantCoef[3][3 + listId][rem] = m_quantCoef[3][3][rem];
+            m_dequantCoef[3][3 - listId][rem] = m_dequantCoef[3][3 + listId][rem] = m_dequantCoef[3][3][rem];
+        }
+    }
     return ok;
 }

If someone wants to test this patch, I've compiled multilib clean version 2.0+49 and patched version 2.0+52: www.msystem.waw.pl/x265/test7.7z

[Jamaika]

I have a questioned. Is for the first pass=2 is always the default aq-mode=1? Even when I add the aq-mode=0.
#options: 4096x2304 fps=24000/1001 bitdepth=8 wpp ctu=64 min-cu-size=8 max-tu-size=32 tu-intra-depth=4 tu-inter-depth=4 me=3 subme=5 merange=92 rect amp max-merge=5 temporal-mvp no-early-skip no-rskip rdpenalty=0 tskip no-tskip-fast strong-intra-smoothing no-lossless no-cu-lossless no-constrained-intra no-fast-intra no-open-gop no-temporal-layers interlace=0 keyint=48 min-keyint=4 scenecut=40 rc-lookahead=60 lookahead-slices=0 bframes=8 bframe-bias=0 b-adapt=2 ref=5 limit-refs=0 no-limit-modes weightp weightb aq-mode=1 qg-size=32 aq-strength=0.00 cbqpoffs=0 crqpoffs=0 rd=6 psy-rd=2.00 rdoq-level=2 psy-rdoq=1.00 log2-max-poc-lsb=8 no-rd-refine signhide deblock=0:0 sao no-sao-non-deblock b-pyramid cutree no-intra-refresh rc=crf crf=20.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv-maxrate=40000 vbv-bufsize=40000 crf-max=0.0 ipratio=1.40 pbratio=1.30

[Ma0]

Is for the first pass=2 is always the default aq-mode=1?

Yes, if there is stat-file read/write x265 change aq-mode from 0 to 1 in this line:
https://bitbucket.org/multicoreware/x265/src/6ee705ecb4332ecd3be35797d270662bfd95f4e2/...coder.cpp-1718

Good news is that it also set aq-strength to 0.

[Jamaika]

Encoder works. High-tier turns on at VBV 160000 for 4K. Pity that there is no messages about small maxbitrate or bufsize.
There is no such thing as aq-mode 0. If it was removed it shouldn't be his in help.
You should also update the preset options.
http://x265.readthedocs.io/en/default/presets.html

[El Heggunte]

Encoder works. High-tier turns on at VBV 160000 for 4K.

Great!

Pity that there is no messages about small maxbitrate or bufsize.
There is no such thing as aq-mode 0. If it was removed it shouldn't be his in help.
You should also update the preset options.
http://x265.readthedocs.io/en/default/presets.html

http://forum.doom9.org/showthread.php?p=1770798#post1770798

[Jamaika]

PS: Isn't "(now it only enables B GOP structure)" on x265 help outdated ("--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4")? It is the same as version 0.3 when you didn't have b-adapt...

I understand. However, for "ultrafast" this is a joke.

Edit: Now I know what you mean. "aq-mode" works only info is wrong.
x265 (build 94) - 2.0+52-6ee705ecb433:[Windows][GCC 6.2.0][64 bit] 8bit+10bit+12bit - H.265/HEVC codec - Copyright 2013-2015 (c) Multicoreware Inc - http://x265.org - options: 4096x2304 fps=24000/1001 bitdepth=8 wpp ctu=64 min-cu-size=8 max-tu-size=32 tu-intra-depth=1 tu-inter-depth=1 me=3 subme=3 merange=57 rect no-amp max-merge=3 temporal-mvp no-early-skip rskip rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing no-lossless no-cu-lossless no-constrained-intra no-fast-intra no-open-gop no-temporal-layers interlace=0 keyint=48 min-keyint=4 scenecut=40 rc-lookahead=25 lookahead-slices=4 bframes=4 bframe-bias=0 b-adapt=2 ref=4 limit-refs=3 limit-modes weightp no-weightb aq-mode=1 qg-size=32 aq-strength=0.00 cbqpoffs=0 crqpoffs=0 rd=4 psy-rd=2.00 rdoq-level=2 psy-rdoq=1.00 log2-max-poc-lsb=8 no-rd-refine signhide deblock=0:0 sao no-sao-non-deblock b-pyramid cutree no-intra-refresh rc=crf crf=20.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 vbv-maxrate=160000 vbv-bufsize=160000 crf-max=0.0 ipratio=1.40 pbratio=1.30

[Ma0]

The bug with --vbv options hangs is officially fixed by Backed out changeset: 16359da0653e.

About --aq-mode=0 -- if you consider three x265 calls:
x265 --aq-mode=0 --aq-strength=2.37 --no-cutree
x265 --aq-mode=0 --aq-strength=2.37
x265 --aq-mode=1 --aq-strength=2.37

In first case it will be: aq-mode=0 aq-strength=0.00
In second case it will be: aq-mode=1 aq-strength=0.00
In third case it will be: aq-mode=1 aq-strength=2.37

[El Heggunte]

The bug with --vbv options hangs is officially fixed by Backed out changeset: 16359da0653e.

Thanks for the official confirmation

commit e5ca9b210223

[Jamaika]

The bug with --vbv options hangs is officially fixed by Backed out changeset: 16359da0653e.

:thanks:

About --aq-mode=0 -- if you consider three x265 calls:

I wouldn't have guessed. There should be information in the manual.
Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.
0. disabled (only when disable cu-tree)

[LigH.de]

A little late, but as it seems to be a kind of intermediate milestone:

x265 2.0+54-e5ca9b210223 (GCC 5.3.0)
x265 2.0+54-e5ca9b210223 (GCC 6.1.0)

Differences in CLI options since 2.0+16:

   --[no-]slices <integer>       Enable Multiple Slices feature. Default enabled
...
   --[no-]analyze-src-pics       Motion estimation uses source frame planes. Default disable
...
   --qg-size <int>               Specifies the size of the quantization group (64, 32, 16, 8). Default 32
...
   --discard-sei                 Discard SEI packets in bitstream. Default disabled
   --discard-vui                 Discard VUI information from the bistream. Default disabled

--qg-size: Additional size 8.

I wonder how the default of --slices can be "enabled" when it expects an integer parameter. Let's guess the default number is 1?

[El Heggunte]

commit cc77b9922b19

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

[El Heggunte]

commit f837dee98769

Latest changes:

rc: fix inconsistent output with qg-size 8

rc: fix non-IDR slicetype in multi-pass

[LigH.de]

Another milestone has been passed. Triple feature this time: v2.1+2 stable

x265 2.1+2-c0d91c2b4048 (GCC 5.3.0)
x265 2.1+2-c0d91c2b4048 (GCC 6.1.0)
x265 2.1+2-c0d91c2b4048 (GCC 6.2.0)

I guess I can skip GCC 6.1.0 soon?

[El Heggunte]

............

I guess I can skip GCC 6.1.0 soon?

I think so; nevcairiel himself has switched to GCC 6.2 (finally):

https://files.1f0.de/mingw/

[LigH.de]

Just XhmikosR delays...