Re: [x265] [PATCH] Increase BBAQ windows and enable masking after I frames

[Mario *LigH* Rohkrämer]

Niranjan Bala schrieb am 11.12.2022 um 17:15:

 From d6b6c195aca2037c0e141efda899f22368ec7555 Mon Sep 17 00:00:00 2001
From: Niranjan Kumar <mailto:niran...@multicorewareinc.com>>

Date: Fri, 4 Nov 2022 14:56:35 +0530
Subject: [PATCH] Increase BBAQ windows and enable masking after I frames


I hope the format of the "scenecut qp config file" will be documented 
verbosely (with examples) in


https://x265.readthedocs.io/en/master/cli.html

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 14/14] Cleanup and Fix warnings

[Mario *LigH* Rohkrämer]

Hi Snehaa.

Yes, I already noticed, and MABS got an update immediately to include 
this patch ( 
https://bitbucket.org/multicoreware/x265_git/pull-requests/9 ) even 
before you commited it to the x265 repo.


https://github.com/m-ab-s/media-autobuild_suite/commit/ad156e6f545b6d2ed4a4efbee1adc5e0cf4eabf4

I started it a little while ago, and MABS passed all compilations, so I 
can tell you it was successful. Safe to be committed, I guess.



Snehaa Giridharan schrieb am 26.10.2022 um 13:54:

Hi Mario
     I have shared a fix patch(Fix build error with multilib) for the 
warnings and linker error that we faced earlier.
Multilib build is clean at our end with this fix, hope it's the same at 
your end too.


/Thanks and Regards,/
/*Snehaa.G*/


On Fri, Oct 21, 2022 at 7:24 PM Snehaa Giridharan 
mailto:sne...@multicorewareinc.com>> wrote:


Hi Mario
    We are working on fixing these warnings.

/Thanks and Regards,/
/*Snehaa.G*/



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 14/14] Cleanup and Fix warnings

[Mario *LigH* Rohkrämer]

::init(x265_param const*)'
; 
CMakeFiles/x265-shared.dir/objects.a(temporalfilter.cpp.obj):temporalfilter:(.text+0x410): 
first defined here
G:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(temporalfilter.cpp.obj):temporalfilter:(.text+0x4a0): 
multiple definition of `TemporalFilter::createRefPicInfo(Tempora
lFilterRefPicInfo*, x265_param*)'; 
CMakeFiles/x265-shared.dir/objects.a(temporalfilter.cpp.obj):temporalfilter:(.text+0x4a0): 
first defined here
G:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(temporalfilter.cpp.obj):temporalfilter:(.text+0x7170): 
multiple definition of `TemporalFilter::destroyRefPicInfo(Tempo
ralFilterRefPicInfo*)'; 
CMakeFiles/x265-shared.dir/objects.a(temporalfilter.cpp.obj):temporalfilter:(.text+0x61d0): 
first defined here

collect2.exe: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/x265-shared.dir/build.make:253: libx265.dll] 
Error 1
make[1]: *** [CMakeFiles/Makefile2:228: CMakeFiles/x265-shared.dir/all] 
Error 2

make: *** [Makefile:136: all] Error 2
G:\MABS\msys64\mingw32\bin\strip.exe: 'libx265.dll': No such file
G:\MABS\msys64\mingw32\bin\strip.exe: 'x265.exe': No such file

+

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Wrong version info?

[Mario *LigH* Rohkrämer]

It would be wrong, though, if Roger compiled for 64 bit but this binary 
reports "[32 bit][noasm]" when running. Is this the case?


chen schrieb am 11.03.2022 um 07:38:

Hi Roger,

Both version number looks right.
The branch stable is 1 commit ahead of Tag 3.5, and branch master ahead 
more.

So the version number is 3.5+1 and 3.5+34, the other part is git hash

Regards,
Min Chen

At 2022-03-11 12:41:44, "Roger Pack"  wrote:

Hello.
As a note if I cross compile "for windows" from origin/master 64 bit,
I get this:

x265.exe --version
x265 [info]: HEVC encoder version 3.5+34-7a5709048
x265 [info]: build info [Windows][GCC 10.2.0][32 bit][noasm] 8bit+10bit+12bit

From origin/stable I get:

x265.exe --version
x265 [info]: HEVC encoder version 3.5+1-ce882936d
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 8bit+10bit+12bit

Which is right.

This is using cmake ex:  -DCMAKE_C_COMPILER=${cross_prefix}gcc etc.
https://github.com/rdp/ffmpeg-windows-build-helpers/blob/ff1f2e9337fc81675f6fcc3d16d01778b3688ae8/cross_compile_ffmpeg.sh#L554

Thanks!
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] missing files while compile x265-devel

[Mario *LigH* Rohkrämer]

yehuda marko schrieb am 13.09.2021 um 14:23:

Memory.h
Stdint.h
Sys/time.h


These look like some of the most basic header files, their 
implementations depending on your hardware and OS, which should have 
been provided by the C/C++ compiler of your choice. Which is it?


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [ANN] x265 v3.5 is out!

[Mario *LigH* Rohkrämer]

Aruna Matheswaran schrieb am 16.03.2021 um 15:47:

Hi all,

x265 version 3.5 is out with new features and encoder enhancements. 
...


Bug fixes
-
1. Incorrect VBV lookahead in :option:`--analysis-load` + 
:option:`--scale-factor`.

2. Encoder hang when VBV is used with slices.
3. QP spikes in the row-level VBV rate-control when WPP enabled.
4. Encoder crash in :option:`--abr-ladder`.

Happy compressing!!

--
Regards,
*Aruna Matheswaran,*
Video Codec Engineer,
Media & AI analytics BU,




___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



Bugs not yet fixed:

  * NASM 2.15.05 multi-line macro warnings

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH]Add: Forward and Backward masking

[Mario *LigH* Rohkrämer]

Niranjan Bala schrieb am 11.12.2020 um 15:29:

+H1("   --masking-strengthComma separated values which specifies 
the duration and offset for the QP increment for inter-frames");


Missing \n at the end of the string.

 +H1("   --masking-strengthComma separated values 
which specifies the duration and offset for the QP increment for 
inter-frames\n");


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH]Add: Forward and Backward masking

[Mario *LigH* Rohkrämer]

A little unimportant warning in MSYS2/MinGW, GCC 10.2:


E:/MABS/build/x265_git-git/source/encoder/ratecontrol.cpp: In member 
function 'double x265::RateControl::forwardMasking(x265::Frame*, double)':
E:/MABS/build/x265_git-git/source/encoder/ratecontrol.cpp:3195:12: 
warning: unused variable 'bwdRefQpDelta' [-Wunused-variable]

 3195 | double bwdRefQpDelta = double(m_param->bwdRefQpDelta);
  |^
E:/MABS/build/x265_git-git/source/encoder/ratecontrol.cpp:3196:12: 
warning: unused variable 'bwdNonRefQpDelta' [-Wunused-variable]

 3196 | double bwdNonRefQpDelta = double(m_param->bwdNonRefQpDelta);
  |^~~~



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] x265 download mirrors

[Mario *LigH* Rohkrämer]

ebals...@pm.me schrieb am 23.11.2020 um 23:33:

I found this page https://bitbucket.org/multicoreware/x265_git
This shows version 3.5 is released, but the download page only has 
tarballs through 3.3.


Well, the recommended method is:

Use git to download the current state of this repository to your local 
working directory. Don't rely on tarballs.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] NASM 2.15.03 (MYS2/MinGW) throws a huge amount of macro warnings

[Mario *LigH* Rohkrämer]

Not as simple as thought?


Nomis101 schrieb am 04.09.2020 um 20:43:

Hi Min,

thanks for looking into it. My patch is just a plain copy of that what 
was done for x264
https://code.videolan.org/videolan/x264/-/merge_requests/31/diffs?commit_id=d78c1e83a1a9d34857eb53294282b3fbca3aba18 


and for FFmpeg
https://github.com/FFmpeg/FFmpeg/commit/bb3490e7f9645babab4cf84fdb2b2dd4922d81a6 



And then I checked that it builds. If you need some modifications, I 
hope somebody can help out here, because I'm not such an ASM person. :-(


Regards



Am 04.09.20 um 01:45 schrieb chen:

Hi,


I fast review the patch, it looks DEFINE_ARGS_INTERNAL can be modify 
other than remove and inline, the other part have similar issue.



btw: the latest macro parameters included all of parameter left after 
that.


For example

%macro test 1-3+


%3 will be included %4 and after


Regards,

Min Chen


At 2020-09-03 23:56:13, "Nomis101"  wrote:

Am 03.09.20 um 15:28 schrieb Mario *LigH* Rohkrämer:

In the meantime, MSYS2 provides NASM 2.15.04; same output.



I had a patch for this in this list. Maybe you could try if this 
patch will fix the issue for you.

https://mailman.videolan.org/pipermail/x265-devel/2020-July/013062.html

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] fix: help for rskip cli option to avoid make errors

[Mario *LigH* Rohkrämer]

Srikanth Kurapati schrieb am 16.09.2020 um 15:36:
+        H0("   --rskip              Enable recurison skip for 
early exit.



Typo: recuri<=>son

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] How to use the abr-ladder option on ffmpeg

[Mario *LigH* Rohkrämer]

Hi Diego.

Every codec specific option not separately exposed by ffmpeg is 
available as pass-through parameter to the general codec specific 
option. In case of x265, it is


-x265-params abr-ladder=filename[:key1=value1[:key2=value2[...]]]


Diego Pasqualin schrieb am 15.09.2020 um 14:53:
Hi there, I'm sorry if this is off-topic, but I'm trying to find out how 
to use the latest --abr-ladder option on ffmpeg, but: (1) I'm not sure 
if it is already available on ffmpeg or how to find it out, and if it is 
available (2) how to specify the input/output inside the configuration 
file, because ffmpeg complains that required parameters are missing from 
the command line.


Could anyone help with any of the points? Thank you very much in advance.

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] NASM 2.15.03 (MYS2/MinGW) throws a huge amount of macro warnings

[Mario *LigH* Rohkrämer]

In the meantime, MSYS2 provides NASM 2.15.04; same output.

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Invitation: [PATCH] cli.rst: Updating reference_scaling and DC... @ Mon Aug 31, 2020 7pm - 7:30pm (IST) (x265-devel@videolan.org)

[Mario *LigH* Rohkrämer]

Somehow I doubt you wanted to invite everyone reading this mailing list...

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] NASM 2.15.03 (MYS2/MinGW) throws a huge amount of macro warnings

[Mario *LigH* Rohkrämer]

/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: 
warning: improperly calling multi-line macro `ALLOC_STACK' with 0 
parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: 
warning: dropping trailing empty parameter in call to multi-line macro 
`DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: 
warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 
0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: 
warning: improperly calling multi-line macro `ALLOC_STACK' with 0 
parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: 
warning: dropping trailing empty parameter in call to multi-line macro 
`DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: 
warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 
0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: 
warning: improperly calling multi-line macro `ALLOC_STACK' with 0 
parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... 
from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: 
warning: dropping trailing empty parameter in call to multi-line macro 
`DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... 
from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... 
from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... 
from macro `PROLOGUE' defined here

+

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Possibly truncated output with HDR10+ metadata

[Mario *LigH* Rohkrämer]

https://forum.doom9.org/showthread.php?p=1918371#post1918371

> when encoding 1917 with HDR10+ metadata, encode gets only 171168 
frames instead of 171176. when encoding without HDR10+ metadata json, 
everything is OK. using latest LigH's build (3.4+9).

>
> EDIT: used the same JSON with NVENC and all good... so probably x265 
problem???


Unfortunately no sample uploaded. Please request in the forum if you 
need more details from the reporting user, 'jlpsvk'.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Edge Aware Quad Tree Establishment

[Mario *LigH* Rohkrämer]

srikanth.kurap...@multicorewareinc.com schrieb am 19.02.2020 um 07:45:

@@ -457,7 +457,9 @@

> ...

+H0("   --rskip Set mode for early exit from recursion. 
Mode 1: exit using rdcost. Mode 2: exit using edge density. Mode 3: exit using edge density 
with forceful skip for small sized CU's."
+   "  Mode 0: disabled. Default 
%s\n", OPT(param->enableRecursionSkip));


Mode is integer (0..3).

Help page reports "Default enabled" where I would expect a number 
instead of a boolean.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Edge Aware Quad Tree Establishment

[Mario *LigH* Rohkrämer]

srikanth.kurap...@multicorewareinc.com schrieb am 19.02.2020 um 07:45:

@@ -457,7 +457,9 @@
...
+H0("   --rskip Set mode for early exit from recursion. 
Mode 1: exit using rdcost. Mode 2: exit using edge density. Mode 3: exit using edge density 
with forceful skip for small sized CU's."


Misses a \n at the end of the line.

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Trouble cloning x265_git.git under MSYS2

[Mario *LigH* Rohkrämer]

Mario *LigH* Rohkrämer schrieb am 06.02.2020 um 13:44:
Since the media-autobuild suite switched to your 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.


This is a strange issue. May be temporary, may depend on unobvious 
details ... nobody else reported it yet. And after I just made the 
media-autobuild suite clone x264 together with ffmpeg/ffms2/lsmash, 
right afterwards x265 was cloned without this error as well.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Trouble cloning x265_git.git under MSYS2

[Mario *LigH* Rohkrämer]

Since the media-autobuild suite switched to your 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.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [ANN] x265 is migrating to Git!

[Mario *LigH* Rohkrämer]

Ah, sorry, I should then read instead:

https://bitbucket.org/multicoreware/x265_git/wiki/Home


Mario *LigH* Rohkrämer schrieb am 05.02.2020 um 13:38:

This change will require to update the compiling instructions on

https://bitbucket.org/multicoreware/x265/wiki/Home


Aruna Matheswaran schrieb am 04.02.2020 um 14:40:

Hi all,

As we all know, bitbucket, our primary hosting source is removing 
support for Mercurial repositories from June 1, 2020 - 
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket.


At this right time, we are migrating x265 project to Git. Get access 
to our Git repo @ https://bitbucket.org/multicoreware/x265_git/


We'll ensure to keep the Mercurial repo in sync with the Git repo on 
an alternate host and continue to accept Hg patches at least until the 
end of 2020.


Happy Compressing!!

--
Regards,
*Aruna Matheswaran,*
Video Codec Engineer,
Media & AI analytics BU,





___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel







--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [ANN] x265 is migrating to Git!

[Mario *LigH* Rohkrämer]

This change will require to update the compiling instructions on

https://bitbucket.org/multicoreware/x265/wiki/Home


Aruna Matheswaran schrieb am 04.02.2020 um 14:40:

Hi all,

As we all know, bitbucket, our primary hosting source is removing 
support for Mercurial repositories from June 1, 2020 - 
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket.


At this right time, we are migrating x265 project to Git. Get access to 
our Git repo @ https://bitbucket.org/multicoreware/x265_git/


We'll ensure to keep the Mercurial repo in sync with the Git repo on an 
alternate host and continue to accept Hg patches at least until the end 
of 2020.


Happy Compressing!!

--
Regards,
*Aruna Matheswaran,*
Video Codec Engineer,
Media & AI analytics BU,





___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Linking multilib binary fails in MSYS2/MinGW

[Mario *LigH* Rohkrämer]

Is this a regression? Or did parameters in a build script have to change 
recently and I didn't notice (still using build scripts which worked a 
month ago)?


MinGW32:

...
[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/x265-shared.dir/build.make:229: libx265.dll] 
Error 1
make[1]: *** [CMakeFiles/Makefile2:87: CMakeFiles/x265-shared.dir/all] 
Error 2

make: *** [Makefile:130: all] Error 2
mv: cannot stat 'libx265.a': No such file or directory
libx265_main.a: No such file or directory
E:\MABS\msys64\mingw32\bin\ar.exe: E:\MABS\msys64\mingw32\bin\strip.exe: 
'libx265.dll': No such file

E:\MABS\msys64\mingw32\bin\strip.exe: 'x265.exe': No such file


MinGW64:

[ 85%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_ssse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse41(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_ssse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse41(x265_12bit::EncoderPrimitives&)'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/x265-shared.dir/build.make:227: libx265.dll] 
Error 1
make[1]: *** [CMakeFiles/Makefile2:119: CMakeFiles/x265-shared.dir/all] 
Error 2

make: *** [Makefile:130: all] Error 2
mv: cannot stat 'libx265.a': No such file or directory
libx265_main.a: No such file or directory
E:\MABS\msys64\mingw64\bin\ar.exe: E:\MABS\msys64\mingw64\bin\strip.exe: 
'libx265.dll': No such file

E:\MABS\msys64\mingw64\bin\strip.exe: 'x265.exe': No such file


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [x265 Patch] Fix: MinGW\GCC 9.2 Warnings In Histogram Based Scene Cut Detection

[Mario *LigH* Rohkrämer]

Reported - tested - confirmed yesterday.

Srikanth Kurapati schrieb am 29.11.2019 um 08:52:

# HG changeset patch
# User Srikanth Kurapati
# Date 1574946473 -19800
#      Thu Nov 28 18:37:53 2019 +0530
# Node ID 47e02b577ac17e29a9d0c4c33efe46cc79d0bf66
# Parent  4a29e0c5bfaf30aaed2c5224bcba1f464d68de83
Fix: gcc 9.2 warnings in encoder.cpp

diff -r 4a29e0c5bfaf -r 47e02b577ac1 source/encoder/encoder.cpp
--- a/source/encoder/encoder.cpp Fri Nov 08 15:30:50 2019 +0530
+++ b/source/encoder/encoder.cpp Thu Nov 28 18:37:53 2019 +0530
@@ -878,8 +878,10 @@

      if (m_param->bHistBasedSceneCut)
      {
-        if(m_edgePic != NULL)
-           X265_FREE_ZERO(m_edgePic);
+        if (m_edgePic != NULL)
+        {
+            X265_FREE_ZERO(m_edgePic);
+        }
      }

      for (int i = 0; i < m_param->frameNumThreads; i++)

--
*With Regards,*
*Srikanth Kurapati.*


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] MinGW/GCC 9.2: multistatement macros warning in encoder.cpp

[Mario *LigH* Rohkrämer]

[ 80%] Building CXX object encoder/CMakeFiles/encoder.dir/encoder.cpp.obj
In file included from E:/MABS/build/x265-hg/source/encoder/encoder.cpp:27:
E:/MABS/build/x265-hg/source/encoder/encoder.cpp: In member function 
'void x265::Encoder::destroy()':
E:/MABS/build/x265-hg/source/common/common.h:222:37: warning: macro 
expands to multiple statements [-Wmultistatement-macros]

  222 | #define X265_FREE_ZERO(ptr) x265_free(ptr); (ptr) = NULL
  | ^
E:/MABS/build/x265-hg/source/encoder/encoder.cpp:882:12: note: in 
expansion of macro 'X265_FREE_ZERO'

  882 |X265_FREE_ZERO(m_edgePic);
  |^~
E:/MABS/build/x265-hg/source/encoder/encoder.cpp:881:9: note: some parts 
of macro expansion are not guarded by this 'if' clause

  881 | if(m_edgePic != NULL)
  | ^~

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] GCC 9.2.0: implicit fall-through warnings in analysis.cpp

[Mario *LigH* Rohkrämer]

Solved, possibly due to the "Cleanup".


Mario *LigH* Rohkrämer schrieb am 17.09.2019 um 13:39:

Compiling in MSYS2/MinGW with GCC 9.2.0 reports warnings:

+
Scanning dependencies of target encoder
[ 67%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.obj
E:/MABS/build/x265-hg/source/encoder/analysis.cpp: In member function 
'void x265_10bit::Analysis::recodeCU(const x265_10bit::CUData&, const 
x265_10bit::CUGeom&, int32_t, int32_t)':
E:/MABS/build/x265-hg/source/encoder/analysis.cpp:2498:54: warning: this 
statement may fall through [-Wimplicit-fallthrough=]
  2498 | case 3: mvpSelect[2] = 
mode.amvpCand[list][ref][!(mode.cu.m_mvpIdx[list][pu.puAbsPartIdx])];
   | 
~^~ 


E:/MABS/build/x265-hg/source/encoder/analysis.cpp:2499:33: note: here
  2499 | case 2: mvpSelect[1] = mvp;
   | ^~~~
[ 69%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
E:/MABS/build/x265-hg/source/encoder/search.cpp: In member function 
'void x265_10bit::Search::predInterSearch(x265_10bit::Mode&, const 
x265_10bit::CUGeom&, bool, uint32_t*)':
E:/MABS/build/x265-hg/source/encoder/search.cpp:2276:42: warning: this 
statement may fall through [-Wimplicit-fallthrough=]

  2276 | mvpIdxSel[2] = !mvpIdx;
   | ~^
E:/MABS/build/x265-hg/source/encoder/search.cpp:2277:21: note: here
  2277 | case 2: mvpSel[1] = 
interMode.amvpCand[list][ref][mvpIdx];

   | ^~~~
E:/MABS/build/x265-hg/source/encoder/search.cpp:2278:42: warning: this 
statement may fall through [-Wimplicit-fallthrough=]

  2278 | mvpIdxSel[1] = mvpIdx;
   | ~^~~~
E:/MABS/build/x265-hg/source/encoder/search.cpp:2279:21: note: here
  2279 | case 1: mvpSel[0] = 
interDataCTU->mv[list][cuIdx + puIdx].word;

   | ^~~~
+----




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] MSYS2/MinGW - ccache hook probably not well supported

[Mario *LigH* Rohkrämer]

Solved by borrowing the toolchain files from the CMake call in MABS.


Mario *LigH* Rohkrämer schrieb am 17.09.2019 um 13:17:
The media-autobuild suite recently added experimental support for ccache 
(provided by MSYS2 as mingw-w64-x86[_64]-ccache 3.7.2-1).


The configuration step for x265 seems to fail requesting its feature set 
correctly, I even doubt it is aware of its presence at all, and its 
hooking into compiler calls might have unwanted side effects.


An example from the configuration in an MSYS2-64/MinGW32 compilation:

+
-- cmake version 3.15.2
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
   The OLD behavior for policy CMP0025 will be removed from a future 
version

   of CMake.

   The cmake-policies(7) manual explains that the OLD behaviors of all
   policies are deprecated and that a policy should be set to OLD only 
under

   specific short-term circumstances.  Projects should be ported to the NEW
   behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy):
   The OLD behavior for policy CMP0054 will be removed from a future 
version

   of CMake.

   The cmake-policies(7) manual explains that the OLD behaviors of all
   policies are deprecated and that a policy should be set to OLD only 
under

   specific short-term circumstances.  Projects should be ported to the NEW
   behavior and not rely on setting a policy to OLD.


-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Check for working C compiler: E:/MABS/msys64/mingw32/bin/ccache.exe
-- Check for working C compiler: E:/MABS/msys64/mingw32/bin/ccache.exe 
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/MABS/msys64/mingw32/bin/ccache.exe
-- Check for working CXX compiler: E:/MABS/msys64/mingw32/bin/ccache.exe 
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - found
-- Performing Test CC_HAS_NO_STRICT_OVERFLOW
-- Performing Test CC_HAS_NO_STRICT_OVERFLOW - Success
-- Performing Test CC_HAS_NO_NARROWING
-- Performing Test CC_HAS_NO_NARROWING - Success
-- Performing Test CC_HAS_NO_ARRAY_BOUNDS
-- Performing Test CC_HAS_NO_ARRAY_BOUNDS - Success
-- Performing Test CC_HAS_FAST_MATH
-- Performing Test CC_HAS_FAST_MATH - Success
-- Performing Test CC_HAS_STACK_REALIGN
-- Performing Test CC_HAS_STACK_REALIGN - Success
-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG
-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG - Success
E:/MABS/msys64/mingw32/bin/ccache.exe: unknown option -- d
Usage:
     ccache [options]
     ccache compiler [compiler options]
     compiler [compiler options]  (via symbolic link)

Common options:
     -c, --cleanup delete old files and recalculate size 
counters

   (normally not needed as this is done
   automatically)
     -C, --clear   clear the cache completely (except 
configuration)
     -F, --max-files=N set maximum number of files in cache to N 
(use 0

   for no limit)
     -M, --max-size=SIZE   set maximum size of cache to SIZE (use 0 
for no
   limit); available suffixes: k, M, G, T 
(decimal)
   and Ki, Mi, Gi, Ti (binary); default 
suffix: G

     -p, --show-config show current configuration options in
   human-readable format
     -s, --show-stats  show summary of configuration and statistics
   counters in human-readable format
     -z, --zero-stats  zero statistics counters

     -h, --help    print this help text
     -V, --version print version and copyright information

Options for scripting or debugging:
     --dump-manifest=PATH  dump manifest file at PATH in text format
     -k, --get-config=K    print the value of configuration key K
     --hash-file=PATH  print the hash (-) of the file 
at PATH
     --print-stats print statistics counter IDs and 
corresponding

   values in machine-parsable format
     -o, --set-config=K=V  set configuration item K to value V

See also <https://ccache.dev>.
-- Found nasm: E:/MABS/msys64/mingw32/bin/nasm.exe (found version 
"2.14.02")

-- Found Nasm 2.14.02 to build assembly primitives
E:/MABS/msys64/mingw32/bin/ccache.exe: unknown option -- d
Usage:
     ccache [options]
     ccache compiler [compiler options]
     compiler [compiler options]  (via symbolic link)

Common options:
     -c, --cleanup delete old files and recalculat

Re: [x265] MinGW/GCC: Unsupported intrinsics in Win32/8bit compilation?

[Mario *LigH* Rohkrämer]

I borrowed the toolchain files from the CMake call in MABS, now it 
builds again.



Mario *LigH* Rohkrämer schrieb am 17.09.2019 um 14:07:
Triple the errors for Win64 target, where all precisions have assembler 
routines:


+
[ 85%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_ssse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse41(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_ssse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse41(x265_12bit::EncoderPrimitives&)'

+

Mario *LigH* Rohkrämer schrieb am 17.09.2019 um 13:25:
I tried to build a multilib encoder for Win32 in MSYS2/MinGW32 with 
GCC 9.2.0. The librraries for 10 and 12 bit precision passed (without 
any Assembler optimization). The linking for the 8 bit precision 
library failed:


+
[ 82%] Built target common
Scanning dependencies of target x265-shared
[ 83%] Building RC object CMakeFiles/x265-shared.dir/x265.rc.obj
[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'

+

Please note that it compiled despite some ccache warnings. I don't 
know if ccache has any impact here. I read in the patch notes when 
media-autobuild suite introduced experimental ccache support that it 
"needs to run at least once to have any effect", but that may only be 
related to speed-up effects in subsequent compilations?








--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] MinGW/GCC: Unsupported intrinsics in Win32/8bit compilation?

[Mario *LigH* Rohkrämer]

Triple the errors for Win64 target, where all precisions have assembler 
routines:


+
[ 85%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_ssse3(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main10.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_10bit::setupIntrinsicDCT_sse41(x265_10bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x31): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x3e): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_ssse3(x265_12bit::EncoderPrimitives&)'
E:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
.\libx265_main12.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x55): 
undefined reference to 
`x265_12bit::setupIntrinsicDCT_sse41(x265_12bit::EncoderPrimitives&)'

+

Mario *LigH* Rohkrämer schrieb am 17.09.2019 um 13:25:
I tried to build a multilib encoder for Win32 in MSYS2/MinGW32 with GCC 
9.2.0. The librraries for 10 and 12 bit precision passed (without any 
Assembler optimization). The linking for the 8 bit precision library 
failed:


+
[ 82%] Built target common
Scanning dependencies of target x265-shared
[ 83%] Building RC object CMakeFiles/x265-shared.dir/x265.rc.obj
[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'

+

Please note that it compiled despite some ccache warnings. I don't know 
if ccache has any impact here. I read in the patch notes when 
media-autobuild suite introduced experimental ccache support that it 
"needs to run at least once to have any effect", but that may only be 
related to speed-up effects in subsequent compilations?





--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] GCC 9.2.0: implicit fall-through warnings in analysis.cpp

[Mario *LigH* Rohkrämer]

Compiling in MSYS2/MinGW with GCC 9.2.0 reports warnings:

+
Scanning dependencies of target encoder
[ 67%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.obj
E:/MABS/build/x265-hg/source/encoder/analysis.cpp: In member function 
'void x265_10bit::Analysis::recodeCU(const x265_10bit::CUData&, const 
x265_10bit::CUGeom&, int32_t, int32_t)':
E:/MABS/build/x265-hg/source/encoder/analysis.cpp:2498:54: warning: this 
statement may fall through [-Wimplicit-fallthrough=]
 2498 | case 3: mvpSelect[2] = 
mode.amvpCand[list][ref][!(mode.cu.m_mvpIdx[list][pu.puAbsPartIdx])];
  | 
~^~

E:/MABS/build/x265-hg/source/encoder/analysis.cpp:2499:33: note: here
 2499 | case 2: mvpSelect[1] = mvp;
  | ^~~~
[ 69%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
E:/MABS/build/x265-hg/source/encoder/search.cpp: In member function 
'void x265_10bit::Search::predInterSearch(x265_10bit::Mode&, const 
x265_10bit::CUGeom&, bool, uint32_t*)':
E:/MABS/build/x265-hg/source/encoder/search.cpp:2276:42: warning: this 
statement may fall through [-Wimplicit-fallthrough=]

 2276 | mvpIdxSel[2] = !mvpIdx;
  | ~^
E:/MABS/build/x265-hg/source/encoder/search.cpp:2277:21: note: here
 2277 | case 2: mvpSel[1] = 
interMode.amvpCand[list][ref][mvpIdx];

  | ^~~~
E:/MABS/build/x265-hg/source/encoder/search.cpp:2278:42: warning: this 
statement may fall through [-Wimplicit-fallthrough=]

 2278 | mvpIdxSel[1] = mvpIdx;
  | ~^~~~
E:/MABS/build/x265-hg/source/encoder/search.cpp:2279:21: note: here
 2279 | case 1: mvpSel[0] = 
interDataCTU->mv[list][cuIdx + puIdx].word;

  | ^~~~
+

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] MinGW/GCC: Unsupported intrinsics in Win32/8bit compilation?

[Mario *LigH* Rohkrämer]

I tried to build a multilib encoder for Win32 in MSYS2/MinGW32 with GCC 
9.2.0. The librraries for 10 and 12 bit precision passed (without any 
Assembler optimization). The linking for the 8 bit precision library failed:


+
[ 82%] Built target common
Scanning dependencies of target x265-shared
[ 83%] Building RC object CMakeFiles/x265-shared.dir/x265.rc.obj
[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): 
undefined reference to 
`x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): 
undefined reference to 
`x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: 
CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): 
undefined reference to 
`x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'

+

Please note that it compiled despite some ccache warnings. I don't know 
if ccache has any impact here. I read in the patch notes when 
media-autobuild suite introduced experimental ccache support that it 
"needs to run at least once to have any effect", but that may only be 
related to speed-up effects in subsequent compilations?


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] MSYS2/MinGW - ccache hook probably not well supported

[Mario *LigH* Rohkrämer]

mpletely (except 
configuration)
-F, --max-files=N set maximum number of files in cache to N 
(use 0

  for no limit)
-M, --max-size=SIZE   set maximum size of cache to SIZE (use 0 
for no
  limit); available suffixes: k, M, G, T 
(decimal)
  and Ki, Mi, Gi, Ti (binary); default 
suffix: G

-p, --show-config show current configuration options in
  human-readable format
-s, --show-stats  show summary of configuration and statistics
  counters in human-readable format
-z, --zero-stats  zero statistics counters

-h, --helpprint this help text
-V, --version print version and copyright information

Options for scripting or debugging:
--dump-manifest=PATH  dump manifest file at PATH in text format
-k, --get-config=Kprint the value of configuration key K
--hash-file=PATH  print the hash (-) of the file 
at PATH
--print-stats print statistics counter IDs and 
corresponding

  values in machine-parsable format
-o, --set-config=K=V  set configuration item K to value V

See also <https://ccache.dev>.
-- hg found at E:/MABS/msys64/usr/bin/hg.bat
-- x265 version 3.1+20-f5d756344566
-- Looking for strtok_r
-- Looking for strtok_r - found
-- Configuring done
-- Generating done
...
+

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Add option to enable slice-based SAO filter

[Mario *LigH* Rohkrämer]

redbtn in the doom9 forums reported an issue in source/common/param.cpp:

po...@multicorewareinc.com schrieb am 11.09.2019 um 19:18:

@@ -1971,6 +1984,7 @@
  BOOL(p->bEnableSAO, "sao");
  BOOL(p->bSaoNonDeblocked, "sao-non-deblock");
  s += sprintf(s, " rd=%d", p->rdLevel);
+s += sprintf(s, "selective-sao=%d", p->selectiveSAO);
  BOOL(p->bEnableEarlySkip, "early-skip");
  BOOL(p->bEnableRecursionSkip, "rskip");
  BOOL(p->bEnableFastIntra, "fast-intra");


A missing space causes the embedded parameter string to be invalid.

-s += sprintf(s, "selective-sao=%d", p->selectiveSAO);
+s += sprintf(s, " selective-sao=%d", p->selectiveSAO);

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Use cases for aq-mode=4

[Mario *LigH* Rohkrämer]

Akil schrieb am 08.08.2019 um 08:57:

videos with high edge contents


That yells for testing with cartoons... ;-)

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Release version 3.1.2

[Mario *LigH* Rohkrämer]

Aruna Matheswaran schrieb am 01.08.2019 um 15:21:



On Wed, Jul 31, 2019 at 7:21 PM Mario *LigH* Rohkrämer <mailto:cont...@ligh.de>> wrote:


Aruna Matheswaran schrieb am 31.07.2019 um 07:52:
 > Hi all,
 >
 > Version 3.1.2 of x265 is released with the fix for issue #498
 >

<https://bitbucket.org/multicoreware/x265/issues/498/31rc-library-hangs-during-encoder_close>.

 > Check out our downloads page
 > <https://bitbucket.org/multicoreware/x265/downloads/>for the tarball.
 >
 > Looking forward to your feedback.
 > --
 > Regards,
 > Aruna
 >
 >
 > ___
 > x265-devel mailing list
 > x265-devel@videolan.org <mailto:x265-devel@videolan.org>
 > https://mailman.videolan.org/listinfo/x265-devel

I might be wrong, but ... tagging without merging may result in two
parallel branches: "default" with the code and "release" with the tags.
And if you are unlucky (like right now), the "tip" points to the newest
tag with outdated code.


Mario, We have implemented a new release process in v3.1. The plan is to 
maintain a separate branch for every release of x265.  All the bug fixes 
specific to release "X.X" will be pushed to "Release_X.X" with a tag 
"X.X.X" and the fix will be grafted to all the succeeding release 
branches as well into default. This way the integrating application will 
have the freedom to pick whichever version of x265 it wants as all the 
bug fixes specific to that version will be available in the release 
branch unlike earlier where all the bug fixes go into the tip of stable 
and the user is forced to use the recent release of x265.


Stable will get periodic merges from default and once an ample amount of 
work goes into stable we'll create a new release branch and tag the new 
version.



-- 


Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de <mailto:maito%3acont...@ligh.de>
___
x265-devel mailing list
x265-devel@videolan.org <mailto:x265-devel@videolan.org>
https://mailman.videolan.org/listinfo/x265-devel



--
Regards,
Aruna


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



Thank you, Aruna. This way you will keep track of bugfixes.

But it seems to me that the development of new features in the "default" 
branch will not be available in releases until you explicitly merge 
them. So testers will have either "unfixed" builds with new features or 
fixed builds with old features only ... until the fixed "release" branch 
may be merged with the experimental "default" branch once in a while.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Release version 3.1.2

[Mario *LigH* Rohkrämer]

Aruna Matheswaran schrieb am 31.07.2019 um 07:52:

Hi all,

Version 3.1.2 of x265 is released with the fix for issue #498 
<https://bitbucket.org/multicoreware/x265/issues/498/31rc-library-hangs-during-encoder_close>. 
Check out our downloads page 
<https://bitbucket.org/multicoreware/x265/downloads/>for the tarball.


Looking forward to your feedback.
--
Regards,
Aruna


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel


I might be wrong, but ... tagging without merging may result in two 
parallel branches: "default" with the code and "release" with the tags. 
And if you are unlucky (like right now), the "tip" points to the newest 
tag with outdated code.


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Windows CPU core affinity vs. NUMA pools

[Mario *LigH* Rohkrämer]

No opinions and thoughts yet?


Mario *LigH* Rohkrämer schrieb am 15.07.2019 um 13:36:

Currently being discussed in the doom9 forum:

Is it possible to control the affinity to a subset of available CPU 
cores via x265 parameters (like --pools) so that multiple instances of 
x265 can be restricted to specific cores on a multi-core CPU?


Example: One instance of x265 may be bound to core 1-4, another to core 
5-8 ... of a 16-core CPU.


Despite trying to set the affinity via parameter in a "start" CLI 
command, x265 selects its own set, the affinity would have to be 
manually changed in a task manager after the process started, which is 
very inconvenient.


https://forum.doom9.org/showthread.php?p=1879195#post1879195



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Windows CPU core affinity vs. NUMA pools

[Mario *LigH* Rohkrämer]

Currently being discussed in the doom9 forum:

Is it possible to control the affinity to a subset of available CPU 
cores via x265 parameters (like --pools) so that multiple instances of 
x265 can be restricted to specific cores on a multi-core CPU?


Example: One instance of x265 may be bound to core 1-4, another to core 
5-8 ... of a 16-core CPU.


Despite trying to set the affinity via parameter in a "start" CLI 
command, x265 selects its own set, the affinity would have to be 
manually changed in a task manager after the process started, which is 
very inconvenient.


https://forum.doom9.org/showthread.php?p=1879195#post1879195

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Some compiler warnings under Linux

[Mario *LigH* Rohkrämer]

Ubuntu 18.04 LTS + GCC 9.0


/home/ligh/x265/source/encoder/ratecontrol.cpp: In member function ‘int 
x265::RateControl::writeRateControlFrameStats(x265::Frame*, 
x265::RateControlEntry*)’:
/home/ligh/x265/source/encoder/ratecontrol.cpp:2867:21: warning: passing 
argument 1 to restrict-qualified parameter aliases with argument 3 
[-Wrestrict]
 2867 | sprintf(deltaPOC, "%s%d~", deltaPOC, 
rpsWriter->deltaPOC[i]);

  | ^~~~   
/home/ligh/x265/source/encoder/ratecontrol.cpp:2868:21: warning: passing 
argument 1 to restrict-qualified parameter aliases with argument 3 
[-Wrestrict]

 2868 | sprintf(bUsed, "%s%d~", bUsed, rpsWriter->bUsed[i]);
  | ^   ~
/home/ligh/x265/source/encoder/ratecontrol.cpp:2867:36: warning: ‘~’ 
directive writing 1 byte into a region of size between 0 and 127 
[-Wformat-overflow=]
 2867 | sprintf(deltaPOC, "%s%d~", deltaPOC, 
rpsWriter->deltaPOC[i]);

  |^
/home/ligh/x265/source/encoder/ratecontrol.cpp:2867:20: note: ‘sprintf’ 
output between 3 and 140 bytes into a destination of size 128
 2867 | sprintf(deltaPOC, "%s%d~", deltaPOC, 
rpsWriter->deltaPOC[i]);
  | 
~~~^
/home/ligh/x265/source/encoder/ratecontrol.cpp:2868:33: warning: ‘~’ 
directive writing 1 byte into a region of size between 0 and 39 
[-Wformat-overflow=]

 2868 | sprintf(bUsed, "%s%d~", bUsed, rpsWriter->bUsed[i]);
  | ^
/home/ligh/x265/source/encoder/ratecontrol.cpp:2868:20: note: ‘sprintf’ 
output between 3 and 42 bytes into a destination of size 40

 2868 | sprintf(bUsed, "%s%d~", bUsed, rpsWriter->bUsed[i]);
  | ~~~^~~~~~~~



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] how to build x265 that supports both 8bit and 10bit

[Mario *LigH* Rohkrämer]

Regarding no optimization: You can generate cmake files with the option 
"-DENABLE_ASSEMBLY=OFF", which happens for High Bit Depth builds for a 
32 bit target anyway. Then it contains only C/C++ code.



qw schrieb am 17.05.2019 um 13:00:

How to build x265 without any optimization and with debug information?

Thanks!

Regard

Andrew



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] how to build x265 that supports both 8bit and 10bit

[Mario *LigH* Rohkrämer]

More or less:

3.0 = general version tag

"RC" = "Release Candidate" = *almost* done

"Au" = "Gold version" = big milestone


qw schrieb am 17.05.2019 um 10:23:


what's the difference between 3.0, 3.0_Au, and 3.0_RC?

Thanks!

Regards

Andrew



--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] how to build x265 that supports both 8bit and 10bit

[Mario *LigH* Rohkrämer]

One rather easy solution for Windows users with little compiler 
experience is


https://github.com/jb-alvarado/media-autobuild_suite

which installs an MSYS2 environment and compiles (depending on its 
configuration) ffmpeg with many linked codecs and additionally separate 
encoders; x265 is specifically supported in different configurations, 
including multilib builds.



chen schrieb am 17.05.2019 um 05:38:

Hi,

Could you please try it with multilib.bat
It is Steve's idea, we build lib two times with different bit_depth and 
combine these libs into one multiple feature lib.


Regards,
Min Chen

At 2019-05-17 11:06:13, "qw"  wrote:

hi,

I read x265 source code, and find one function, as shown below:


int x265_param_apply_profile(x265_param *param, const char *profile)
{
     if (!param || !profile)
         return 0;

     /* Check if profile bit-depth requirement is exceeded by
internal bit depth */
     bool bInvalidDepth = false;
#if X265_DEPTH > 8
     if (!strcmp(profile, "main") || !strcmp(profile,
"mainstillpicture") || !strcmp(profile, "msp") ||
         !strcmp(profile, "main444-8") || !strcmp(profile,
"main-intra") ||
         !strcmp(profile, "main444-intra") || !strcmp(profile,
"main444-stillpicture"))
         bInvalidDepth = true;
#endif
#if X265_DEPTH > 10
     if (!strcmp(profile, "main10") || !strcmp(profile,
"main422-10") || !strcmp(profile, "main444-10") ||
         !strcmp(profile, "main10-intra") || !strcmp(profile,
"main422-10-intra") || !strcmp(profile, "main444-10-intra"))
         bInvalidDepth = true;
#endif
#if X265_DEPTH > 12
     if (!strcmp(profile, "main12") || !strcmp(profile,
"main422-12") || !strcmp(profile, "main444-12") ||
         !strcmp(profile, "main12-intra") || !strcmp(profile,
"main422-12-intra") || !strcmp(profile, "main444-12-intra"))
         bInvalidDepth = true;
#endif

     if (bInvalidDepth)
     {
         x265_log(param, X265_LOG_ERROR, "%s profile not supported,
internal bit depth %d.\n", profile, X265_DEPTH);
         return -1;
     }

It seems that the logic will report error, when x265 is built with
X265_DEPTH = 10 and profile is of 8bit.

How to make x265 support both 8bit and 10bit?

    Thanks!

Regards

Andrew









___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Error x265 2.9+1: frame type not compatible with keyframe interval

[Mario *LigH* Rohkrämer]

Hi.

Just a guess: Are you possibly reusing a 1st-pass statistics file from a 
different encode, or did you change parameters between 1st and 2nd pass 
which affect the GOP size limits or scene detection sensitivity?


Just to exclude the most obvious first, before digging deeper if there 
was a known GOP type bug for this version specifically.


Posting the whole command lines for both passes would certainly be helpful.


Zero Un schrieb am 17.03.2019 um 13:17:

Hello i have this mistake many times on a encode

x265 [warning]: specified frame type (5) at 77330 is not compatible with 
keyframe interval

x265 [error]: slice=I but 2pass stats say B


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel


--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] (NASM for Win32) pixel-a.asm: error: symbol `r7d' undefined

[Mario *LigH* Rohkrämer]

E:\MABS\msys64\mingw32\bin\nasm.exe -f win32 -DPREFIX -DARCH_X86_64=0 -I 
E:/MABS/build/x265-hg/source/common/../common/x86/ 
-DHAVE_ALIGNED_STACK=1 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -DX265_NS=x265 
-o common/CMakeFiles/common.dir/x86/pixel-a.asm.obj 
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:15955: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:15983: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16002: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16026: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16045: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16083: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16102: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16166: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16185: error: symbol 
`r7d' undefined
E:/MABS/build/x265-hg/source/common/x86/pixel-a.asm:16301: error: symbol 
`r7d' undefined



Archive of diagnostic files, if required: https://0x0.st/zo0t.zip

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Less FPS

[Mario *LigH* Rohkrämer]

Hi Sunil.

Just a general note: AVX512 is not certainly faster than AVX2 on every 
CPU model. There have been a few tests e.g. in the doom9 video forum. So 
don't expect miracles.


Knowing your exact CPU model may help estimating if there can be a 
speedup, or if it is a model which may e.g. throttle too much to avoid 
overheating.


But wait for more experienced replies than mine...


Sunil Kumar schrieb am 28.02.2019 um 09:17:

Hi,
I am new to media encoding, I have heard that x265 is a very efficient 
encoding tool on Intel's platform with avx512 enabled. But I am not able 
to get good FPS with avx512 enable. Can you please help me improving the 
performance?


1) I have tried with core pinning but it seems like using more cores is 
not beneficial, even reducing the FPS, How can we decide the no. of 
cores for best FPS in multi socket system.


2) Can suggest the command for efficient performance like the best 
command line parameters or performance parameters (if we use preset then 
it will compromise with the quality of video and same with CRF, help in 
deciding best thing).


3) How can I run in parallel or in multi pass (2 pass) please give an 
command example.

the command i was using is:

./x265 --input  --input-res 1920x1080 --fps 50 --output 
out.hevc  --max-merge 3 --no-tskip --no-rect --frame-threads 16 --pools 
"+,-" --bitrate 16000 --asm avx512


how can we decide the --fps for input video? max-merge, no-tskip, 
fram-threads etc.

Please give command so that it will help me out.
Thanks,
Sunil


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] MinGW, GCC: Shadow declaration of type 'byte' in rpuParser, x265 CLI

[Mario *LigH* Rohkrämer]

[ 97%] Building CXX object CMakeFiles/cli.dir/x265.cpp.obj
H:/development/media-autobuild_suite-master/build/x265-hg/source/x265.cpp: 
In function 'int rpuParser(x265_picture*, FILE*)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/x265.cpp:575:13: 
warning: declaration of 'byte' shadows a global declaration [-Wshadow]

 uint8_t byte;
 ^~~~
In file included from 
H:/development/media-autobuild_suite-master/msys64/mingw32/i686-w64-mingw32/include/wtypes.h:8:0,
 from 
H:/development/media-autobuild_suite-master/msys64/mingw32/i686-w64-mingw32/include/winscard.h:10,
 from 
H:/development/media-autobuild_suite-master/msys64/mingw32/i686-w64-mingw32/include/windows.h:97,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/threading.h:32,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/output/reconplay.h:29,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/x265.cpp:33:
H:/development/media-autobuild_suite-master/msys64/mingw32/i686-w64-mingw32/include/rpcndr.h:63:25: 
note: shadowed declaration is here

   typedef unsigned char byte;
 ^~~~

--

Fun and success!

Mario *LigH* Rohkrämer
maito:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Several warnings (MSYS2/MinGW, GCC 8.2.0, CMake 3.12.1)

[Mario *LigH* Rohkrämer]

Attached: almost complete output of a multi-lib build (a base directory 
was substituted with '§' to save space)
-- cmake version 3.12.1
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
  The OLD behavior for policy CMP0025 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy):
  The OLD behavior for policy CMP0054 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Detected x86_64 target processor
-- Found Nasm 2.13.03 to build assembly primitives
-- hg found at H:/development/media-autobuild_suite-master/msys64/usr/bin/hg.bat
-- x265 version 2.8+72-bbad4e55b51a
-- Configuring done
-- Generating done
-- Build files have been written to: §/x265-hg/build/msys64_hdr10_ml/12bit
Scanning dependencies of target clean-generated
Built target clean-generated
-- cmake version 3.12.1
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
  The OLD behavior for policy CMP0025 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy):
  The OLD behavior for policy CMP0054 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Detected x86_64 target processor
-- Found Nasm 2.13.03 to build assembly primitives
-- hg found at H:/development/media-autobuild_suite-master/msys64/usr/bin/hg.bat
-- x265 version 2.8+72-bbad4e55b51a
-- Configuring done
-- Generating done
-- Build files have been written to: §/x265-hg/build/msys64_hdr10_ml/12bit
Scanning dependencies of target common
[  1%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/pixel-a.asm.obj
[  2%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/const-a.asm.obj
[  3%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/cpu-a.asm.obj
[  5%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ssd-a.asm.obj
[  6%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/mc-a.asm.obj
[  7%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/mc-a2.asm.obj
[  8%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/pixel-util8.asm.obj
[ 10%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/blockcopy8.asm.obj
[ 11%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/pixeladd8.asm.obj
[ 12%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/dct8.asm.obj
[ 13%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/seaintegral.asm.obj
[ 15%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/sad16-a.asm.obj
[ 16%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/intrapred16.asm.obj
[ 17%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/v4-ipfilter16.asm.obj
[ 18%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/h4-ipfilter16.asm.obj
[ 20%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/h-ipfilter16.asm.obj
[ 21%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/ipfilter16.asm.obj
[ 22%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/loopfilter.asm.obj
[ 24%] Building CXX object 
common/CMakeFiles/common.dir/x86/asm-primitives.cpp.obj
[ 25%] Building CXX object 
common/CMakeFiles/common.dir/vec/vec-primitives.cpp.obj
[ 26%] Building CXX object common/CMakeFiles/common.dir/vec/dct-sse3.cpp.obj
[ 27%] Building CXX object common/CMakeFiles/common.dir/vec/dct-ssse3.cpp.obj
[ 29%] Building CXX object common/CMakeFiles/common.dir/vec/dct-sse41.cpp.obj
[ 30%] Building CXX object common/CMakeFiles/common.dir/winxp.cpp.obj
[ 31%] Building CXX object common/CMakeFiles/common.dir/primitives.cpp.obj
[ 32%] Building CXX object common/CMakeFiles/common.dir/pixel.cpp.obj
[ 34%] Building CXX object common/CMakeFiles/common.dir/dct.cpp.obj
[ 35%] Building CXX object common/CMakeFiles/common.dir/lowpassdct.cpp.obj
[ 36%] Building CXX object common/CMakeFiles/common.dir/ipfilter.cpp.obj
[ 37%] Building CXX object 

Re: [x265] Original C++ code used for sad functions' assembly code in COST_MV?

[Mario *LigH* Rohkrämer]

Jeffrey Chen schrieb am 04.09.2018 um 23:57:
Hi, I would like to configure the sad function in COST_MV for another 
platform. However, the assembly code would not be supported on the other 
platform. Where can I find the original programming language code that 
was made into the assembly language code?


Hi Jeffrey.

I'm not a developer, just guessing:

source/encoder/motion.cpp line 234 #defines a loop.
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Several warnings (MSYS2/MinGW, GCC 8.2.0, CMake 3.12.1)

[Mario *LigH* Rohkrämer]

Possibly different default warnings enabled in GCC 8.2.0, compared to 
GCC 7.3.0


12 bit encoder, 64 bit build:


[ 56%] Building CXX object common/CMakeFiles/common.dir/frame.cpp.obj
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.cpp: 
In constructor 'x265_12bit::Frame::Frame()':
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.cpp:47:42: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265_12bit::Lowres'; use assignment or 
value-initialization instead [-Wclass-memaccess]

 memset(_lowres, 0, sizeof(m_lowres));
  ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.h:29,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.cpp:26:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/lowres.h:107:8: 
note: 'struct x265_12bit::Lowres' declared here

 struct Lowres : public ReferencePlanes
^~

[ 77%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp: 
In member function 'void 
x265_12bit::Search::predInterSearch(x265_12bit::Mode&, const 
x265_12bit::CUGeom&, bool, uint32_t*)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp:2173:36: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265_12bit::Search::MergeData'; use assignment 
or value-initialization instead [-Wclass-memaccess]

 memset(, 0, sizeof(merge));
^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp:30:
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.h:414:12: 
note: 'struct x265_12bit::Search::MergeData' declared here

 struct MergeData
^
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp: 
In member function 'void 
x265_12bit::Search::encodeResAndCalcRdInterCU(x265_12bit::Mode&, const 
x265_12bit::CUGeom&)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp:2760:50: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265_12bit::Search::TUInfoCache'; use 
assignment or value-initialization instead [-Wclass-memaccess]

 memset(_cacheTU, 0, sizeof(TUInfoCache));
  ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.cpp:30:
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/search.h:388:12: 
note: 'struct x265_12bit::Search::TUInfoCache' declared here

 struct TUInfoCache
^~~


[ 82%] Building CXX object 
encoder/CMakeFiles/encoder.dir/frameencoder.cpp.obj
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.cpp:33:
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.h: 
In member function 'void x265_12bit::CTURow::init(x265_12bit::Entropy&, 
unsigned int)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.h:108:46: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265_12bit::FrameStats'; use assignment or 
value-initialization instead [-Wclass-memaccess]

 memset(, 0, sizeof(rowStats));
  ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.cpp:28:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/framedata.h:41:8: 
note: 'struct x265_12bit::FrameStats' declared here

 struct FrameStats
^~
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.cpp: 
In constructor 'x265_12bit::FrameEncoder::FrameEncoder()':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.cpp:64:47: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265_12bit::RateControlEntry'; use assignment 
or value-initialization instead [-Wclass-memaccess]

 memset(_rce, 0, sizeof(RateControlEntry));
   ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.h:40,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.cpp:33:
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/ratecontrol.h:66:8: 
note: 'struct x265_12bit::RateControlEntry' declared here

 struct RateControlEntry
^~~~

[x265] Several compiler warnings in MSYS2/MinGW64 with GCC 8.2.0

[Mario *LigH* Rohkrämer]

MSYS2 recently updated MinGW64 with GCC 8.2.0 (MinGW32 will keep GCC 
7.3.0 due to some internal compiler errors in v8.2.0).


Here are some of the reported warnings (the compilation still passes):

+
[ 80%] Building CXX object encoder/CMakeFiles/encoder.dir/encoder.cpp.obj
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:36:
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.h: 
In member function 'void x265::CTURow::init(x265::Entropy&, unsigned int)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/frameencoder.h:108:46: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265::FrameStats'; use assignment or 
value-initialization instead [-Wclass-memaccess]

 memset(, 0, sizeof(rowStats));
  ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:30:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/framedata.h:41:8: 
note: 'struct x265::FrameStats' declared here

 struct FrameStats
^~
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp: 
In member function 'void 
x265::Encoder::readAnalysisFile(x265_analysis_data*, int, const 
x265_picture*, int)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:3190:43: 
warning: 'void* memcpy(void*, const void*, size_t)' copying an object of 
non-trivial type 'struct x265::MV' from an array of 'x265_analysis_MV' 
{aka 'struct x265_analysis_MV'} [-Wclass-memaccess]

 memcpy(val, src, (size * readSize));\
   ^
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:3382:21: 
note: in expansion of macro 'X265_FREAD'
 X265_FREAD(mv[i], sizeof(MV), depthBytes, 
m_analysisFileIn, interPic->mv[i]);

 ^~
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/lowres.h:30,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.h:29,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:29:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/mv.h:37:8: 
note: 'struct x265::MV' declared here

 struct MV
^~
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp: 
In member function 'void 
x265::Encoder::readAnalysisFile(x265_analysis_data*, int, const 
x265_picture*, int, x265::cuLocation)':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:3468:43: 
warning: 'void* memcpy(void*, const void*, size_t)' copying an object of 
non-trivial type 'struct x265::MV' from an array of 'x265_analysis_MV' 
{aka 'struct x265_analysis_MV'} [-Wclass-memaccess]

 memcpy(val, src, (size * readSize));\
   ^
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:3707:21: 
note: in expansion of macro 'X265_FREAD'
 X265_FREAD(mv[i], sizeof(MV), depthBytes, 
m_analysisFileIn, interPic->mv[i]);

 ^~
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/lowres.h:30,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/frame.h:29,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:29:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/mv.h:37:8: 
note: 'struct x265::MV' declared here

 struct MV
^~
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp: 
In member function 'bool x265::Encoder::computeSPSRPSIndex()':
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:4583:61: 
warning: 'void* memset(void*, int, size_t)' clearing an object of 
non-trivial type 'struct x265::RPS'; use assignment or 
value-initialization instead [-Wclass-memaccess]

 memset(rpsInSPS, 0, sizeof(RPS) * MAX_NUM_SHORT_TERM_RPS);
 ^
In file included from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/framedata.h:28,
 from 
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/encoder.cpp:30:
H:/development/media-autobuild_suite-master/build/x265-hg/source/common/slice.h:45:8: 
note: 'struct x265::RPS' declared here

 struct RPS
^~~
[ 81%] Building CXX object encoder/CMakeFiles/encoder.dir/api.cpp.obj
H:/development/media-autobuild_suite-master/build/x265-hg/source/encoder/api.cpp: 
In function 'const x265_api* 

[x265] Issues with sprintf format strings and x265 access violation

[Mario *LigH* Rohkrämer]

Report in the doom9 forum: x265 crashing in StaxRip from v2.8+49 on, 
using VS2017 AVX2 builds from waw.pl


https://forum.doom9.org/showthread.php?p=1847783#post1847783

+
Error Video encoding using x265 2.8+56 (1.7.0.6)

Video encoding using x265 2.8+56 failed with exit code: -1073741819 
(0xC005)


The exit code might be a system error code: The instruction at 0xp 
referenced memory at 0xp. The memory could not be s.

+

It's not really obvious to me whether this misinterpreted format string 
is part of x265 or StaxRip, though...


I'd suggest to wait for more replies in this forum thread for now, the 
original reporter shall test different builds, preferably on a raw 
console instead of inside a GUI.

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] getopt_long() lets through ambiguous arguments like --nr

[Mario *LigH* Rohkrämer]

Joshua Bowman schrieb am 11.07.2018 um 06:36:
GNU getopt allows abbreviated options, but it really SHOULD blow up when 
an argument short-matches a name twice; instead it just merrily takes 
the first one. It seems to be designed to allow a developer to brain 
fart and insert the exact same argument twice without error, and this 
patch will still allow that, but it WILL prevent something like --nr 
that matches both --nr-intra and --nr-inter from just silently using the 
first match. For some reason, no one ever thought to compare the actual 
argument names.


This doesn't patch the -W path. No one cares about POSIX -W.


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel


"Thank you on behalf", Joshua. Just a general remark: The developers 
prefer patches also to be displayed in the normal mail body, for easier 
reviewing.

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] FR: Postpone Windows 10 update reboots during encodes by signaling "busy"?

[Mario *LigH* Rohkrämer]

No opinion yet?


Mario *LigH* Rohkrämer schrieb am 13.06.2018 um 08:35:

Request by 'Stereodude' in the doom9 forum:

https://forum.doom9.org/showthread.php?p=1844407#post1844407

+
Is there any way to x265 to let Windows know that it's busy encoding to 
prevent a Windows update from rebooting the PC during an encode? I 
thought I read before that there's a way for an application to let the 
OS know it's "busy" so that it won't reboot while the application is 
crunching away.


Currently Windows 10 will happily reboot mid x264 or x265 encode even if 
the CPU is pegged at 100%.

+

I wonder if you could use the ShutdownBlockReasonCreate function to 
postpone it:


https://msdn.microsoft.com/en-us/library/windows/desktop/aa376877%28v=vs.85%29.aspx 



And which window handle would you use for a CLI application?
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel


___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] FR: Postpone Windows 10 update reboots during encodes by signaling "busy"?

[Mario *LigH* Rohkrämer]

Request by 'Stereodude' in the doom9 forum:

https://forum.doom9.org/showthread.php?p=1844407#post1844407

+
Is there any way to x265 to let Windows know that it's busy encoding to 
prevent a Windows update from rebooting the PC during an encode? I 
thought I read before that there's a way for an application to let the 
OS know it's "busy" so that it won't reboot while the application is 
crunching away.


Currently Windows 10 will happily reboot mid x264 or x265 encode even if 
the CPU is pegged at 100%.

+

I wonder if you could use the ShutdownBlockReasonCreate function to 
postpone it:


https://msdn.microsoft.com/en-us/library/windows/desktop/aa376877%28v=vs.85%29.aspx

And which window handle would you use for a CLI application?
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Missing numa.h under Linux in 8-bit pass

[Mario *LigH* Rohkrämer]

Mario *LigH* Rohkrämer schrieb am 22.05.2018 um 15:21:


Did I forget to install a package (e.g. libnuma sources)?

I believe libnuma-dev was useful.

And "either multilib or libvmaf" is a different topic...
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Missing numa.h under Linux in 8-bit pass

[Mario *LigH* Rohkrämer]

Out of curiosity, I upgraded my VirtualBox to Ubuntu MATE 18 LTS, 
installed all requirements for the Guest Applications and x265, then let 
my custom build script run which builds a sequence required for a 
multilib executable.


12-bit and 10-bit encoder passes are successful. Then, the 8-bit pass fails:

+
-- cmake version 3.10.2
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
  The OLD behavior for policy CMP0025 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Detected x86_64 target processor
-- libnuma found, building with support for NUMA nodes
-- Found Nasm 2.13.02 to build assembly primitives
-- hg found at /usr/bin/hg
-- x265 version 2.8+2-cc2c5e46f3c8
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/ligh/x265/build/linux_hdr10_ml/8bit

Scanning dependencies of target common
[  1%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/pixel-a.asm.o
[  2%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/const-a.asm.o

[  3%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/cpu-a.asm.o
[  4%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ssd-a.asm.o
[  5%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/mc-a.asm.o
[  6%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/mc-a2.asm.o
[  7%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/pixel-util8.asm.o
[  8%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/blockcopy8.asm.o
[ 10%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/pixeladd8.asm.o

[ 11%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/dct8.asm.o
[ 12%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/seaintegral.asm.o

[ 13%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/sad-a.asm.o
[ 14%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/intrapred8.asm.o
[ 15%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/intrapred8_allangs.asm.o
[ 16%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/v4-ipfilter8.asm.o
[ 17%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/h-ipfilter8.asm.o
[ 18%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/ipfilter8.asm.o
[ 20%] Building ASM_NASM object 
common/CMakeFiles/common.dir/x86/loopfilter.asm.o
[ 21%] Building CXX object 
common/CMakeFiles/common.dir/x86/asm-primitives.cpp.o
[ 22%] Building CXX object 
common/CMakeFiles/common.dir/vec/vec-primitives.cpp.o

[ 23%] Building CXX object common/CMakeFiles/common.dir/vec/dct-sse3.cpp.o
[ 24%] Building CXX object common/CMakeFiles/common.dir/vec/dct-ssse3.cpp.o
[ 25%] Building CXX object common/CMakeFiles/common.dir/vec/dct-sse41.cpp.o
[ 26%] Building CXX object common/CMakeFiles/common.dir/primitives.cpp.o
[ 27%] Building CXX object common/CMakeFiles/common.dir/pixel.cpp.o
[ 28%] Building CXX object common/CMakeFiles/common.dir/dct.cpp.o
[ 30%] Building CXX object common/CMakeFiles/common.dir/lowpassdct.cpp.o
[ 31%] Building CXX object common/CMakeFiles/common.dir/ipfilter.cpp.o
[ 32%] Building CXX object common/CMakeFiles/common.dir/intrapred.cpp.o
[ 33%] Building CXX object common/CMakeFiles/common.dir/loopfilter.cpp.o
[ 34%] Building CXX object common/CMakeFiles/common.dir/constants.cpp.o
[ 35%] Building CXX object common/CMakeFiles/common.dir/cpu.cpp.o
[ 36%] Building CXX object common/CMakeFiles/common.dir/version.cpp.o
[ 37%] Building CXX object common/CMakeFiles/common.dir/threading.cpp.o
[ 38%] Building CXX object common/CMakeFiles/common.dir/threadpool.cpp.o
/home/ligh/x265/source/common/threadpool.cpp:68:10: fatal error: numa.h: 
Datei oder Verzeichnis nicht gefunden

 #include 
  ^~~~
compilation terminated.
common/CMakeFiles/common.dir/build.make:734: recipe for target 
'common/CMakeFiles/common.dir/threadpool.cpp.o' failed

make[2]: *** [common/CMakeFiles/common.dir/threadpool.cpp.o] Error 1
CMakeFiles/Makefile2:448: recipe for target 
'common/CMakeFiles/common.dir/all' failed

make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
+

Did I forget to install a package (e.g. libnuma sources)?
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add VMAF suppport to report per frame and aggregate VMAF score

[Mario *LigH* Rohkrämer]

Mario Rohkrämer schrieb am 12.04.2018 um 18:25:

Am 12.04.2018, 13:13 Uhr, schrieb :


+.. Note::
+
+    When setting ENABLE_LIBVMAF cmake option to ON, it is recommended to
+    also set ENABLE_SHARED to OFF to prevent build problems.
+    We only need the static library from these builds.
+
+    Binaries build with windows will not have VMAF support.



Can you explain why support for Windows builds is not (yet?) possible?

I do remember that MABS is able to compile ffmpeg including VMAF, and 
also I do remember that it compiled only for x86-64 architecture due to 
some specific EMMS intrinsics. But, of course, MABS pulls the whole 
libvmaf source to do so. You will probably not want to require that. But 
it might not be too hard in MSYS/MinGW64 if an experienced user does it 
manually?



Still curious...
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 000 of 307 ] AVX-512 implementataion in x265

[Mario *LigH* Rohkrämer]

Pradeep Ramachandran schrieb am 12.04.2018 um 16:11:
On the average we see 18% improvement for 4K main10 high quality 
encoding; for other resolutions and presets, the improvement isn’t 
significant.
There are already a few reports in the doom9 forum: An intel Core i9 can 
accelerate the encoding especially with slower presets, while a Xeon was 
reported to be slower when AVX-512 was enabled, probably mostly due to 
the temperature related throttling.

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Support for HLG-graded content and pic_struct

[Mario *LigH* Rohkrämer]

Ashok Kumar Mishra schrieb am 12.04.2018 um 14:21:
+       H0("   --pic-struct         Set the picture structure 
and emits it in the picture timing SEI message. Values in the range 
0..12. See D.3.3 of the HEVC spec. for a detailed explanation.");


Missing a new line at the end.

Furthermore, another very very long CLI help output line (190 chars)...
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] introduce new CLI single-sei to write all SEI messages in one single NAL

[Mario *LigH* Rohkrämer]

But it is not yet listed in the full help.
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] CMake: blacklist mingw implicit link libraries

[Mario *LigH* Rohkrämer]

May be a bit late; this caused an "unresolved merge" in my MSYS2  
environment.



Am 01.02.2018, 14:38 Uhr, schrieb Ashok Kumar Mishra  
<as...@multicorewareinc.com>:



On Mon, Jan 29, 2018 at 12:29 AM, Ashok Kumar Mishra <
as...@multicorewareinc.com> wrote:




On Sun, Jan 28, 2018 at 4:00 PM, Ricardo Constantino <wiia...@gmail.com>
wrote:




On 28 January 2018 at 06:45, Mario Rohkrämer <cont...@ligh.de> wrote:

Am 23.01.2018, 13:02 Uhr, schrieb Ricardo Constantino  
<wiia...@gmail.com

>:

On 16 January 2018 at 17:41, Ricardo Constantino <wiia...@gmail.com>

wrote:

# HG changeset patch

# User Ricardo Constantino <wiia...@gmail.com>
# Date 1516124393 0
#  Tue Jan 16 17:39:53 2018 +
# Node ID 5dbc1653fba42507f44fac6034aa3598fb2816cd
# Parent  3712d13c09bf3b9db105c7f97188bcc11b8f83cd
CMake: blacklist mingw implicit link libraries

These also aren't meant to be in pkg-config's Libs.Private.

diff -r 3712d13c09bf -r 5dbc1653fba4 source/CMakeLists.txt
--- a/source/CMakeLists.txt Sat Jan 13 02:47:30 2018 +0100
+++ b/source/CMakeLists.txt Tue Jan 16 17:39:53 2018 +
@@ -647,7 +647,9 @@
 endforeach()
 if(PLIBLIST)
 # blacklist of libraries that should not be in Libs.private
-list(REMOVE_ITEM PLIBLIST "-lc" "-lpthread")
+list(REMOVE_ITEM PLIBLIST "-lc" "-lpthread" "-lmingwex"
"-lmingwthrd"
+"-lmingw32" "-lmoldname" "-lmsvcrt" "-ladvapi32"
"-lshell32"
+"-luser32" "-lkernel32")
 string(REPLACE ";" " " PRIVATE_LIBS "${PLIBLIST}")
 else()
 set(PRIVATE_LIBS "")



ping



Hoping for a soon review and commit too...



Maybe it would add to the urgency that not fixing this very horribly
breaks MinGW static linking with any upstream using x265.

_______
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




Thank you for sending this patch, will commit it asap.



Pushed to default.



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 2 of 2] x86: Change assembler from YASM to NASM

[Mario *LigH* Rohkrämer]

d971aeaff20b095fd9
-x11: ddq 0x77d410d5c42c882d89b0c0765892729a
-x12: ddq 0x24b3c1d2a024048bc45ea11a955d8dd5
-x13: ddq 0xdd7b8919edd427862e8ec680de14b47c
-x14: ddq 0x11e53e2b2ac655ef135ce6888fa02cbf
-x15: ddq 0x6de8f4c914c334d5011ff554472a7a10
-n7:   dq 0x21f86d66c8ca00ce
-n8:   dq 0x75b6ba21077c48ad
-n9:   dq 0xed56bb2dcb3c7736
-n10:  dq 0x8bda43d3fd1a7e06
-n11:  dq 0xb64a9c9e5d318408
-n12:  dq 0xdf9a54b303f1d3a3
-n13:  dq 0x4a75479abd64e097
-n14:  dq 0x249214109d5d1c88
+x6:  dq 0x1a1b2550a612b48c,0x79445c159ce79064
+x7:  dq 0x2eed899d5a28ddcd,0x86b2536fcd8cf636
+x8:  dq 0xb0856806085e7943,0x3f2bf84fc0fcca4e
+x9:  dq 0xacbd382dcf5b8de2,0xd229e1f5b281303f
+x10: dq 0x71aeaff20b095fd9,0xab63e2e11fa38ed9
+x11: dq 0x89b0c0765892729a,0x77d410d5c42c882d
+x12: dq 0xc45ea11a955d8dd5,0x24b3c1d2a024048b
+x13: dq 0x2e8ec680de14b47c,0xdd7b8919edd42786
+x14: dq 0x135ce6888fa02cbf,0x11e53e2b2ac655ef
+x15: dq 0x011ff554472a7a10,0x6de8f4c914c334d5
+n7:  dq 0x21f86d66c8ca00ce
+n8:  dq 0x75b6ba21077c48ad
+n9:  dq 0xed56bb2dcb3c7736
+n10: dq 0x8bda43d3fd1a7e06
+n11: dq 0xb64a9c9e5d318408
+n12: dq 0xdf9a54b303f1d3a3
+n13: dq 0x4a75479abd64e097
+n14: dq 0x249214109d5d1c88
%endif

SECTION .text
@@ -70,14 +70,14 @@
;---
--
cglobal checkasm_stack_clobber, 1,2
 ; Clobber the stack with junk below the stack pointer
-%define size (max_args+6)*8
-SUB  rsp, size
-mov   r1, size-8
+%define argsize (max_args+6)*8
+SUB  rsp, argsize
+mov   r1, argsize-8
.loop:
 mov [rsp+r1], r0
 sub   r1, 8
 jge .loop
-ADD  rsp, size
+ADD  rsp, argsize
 RET

%if WIN64
@@ -156,7 +156,11 @@
     mov  r9, rax
 mov r10, rdx
 lea  r0, [error_message]
+%if FORMAT_ELF
+call puts wrt ..plt
+%else
 call puts
+%endif
 mov  r1, [rsp+max_args*8]
 mov  dword [r1], 0
 mov  rdx, r10
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] analysis.cpp, compressInterCU_rd5_6 - parentheses warning (GCC 7.2.0, Win32)

[Mario *LigH* Rohkrämer]

Probably just to avoid ambiguity:

[ 12%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.obj
H:/dev/mabs/build/x265-hg/source/encoder/analysis.cpp: In member function  
'x265_12bit::SplitData x265_12bit::Analysis::compressInterCU_rd5_6(const  
x265_12bit::CUData&, const x265_12bit::CUGeom&, int32_t)':
H:/dev/mabs/build/x265-hg/source/encoder/analysis.cpp:2003:43: warning:  
suggest parentheses around '&&' within '||' [-Wparentheses]
 if (mightNotSplit && !md.bestMode && !bCtuInfoCheck ||  
(m_param->bMVType && (m_modeFlag[0] || m_modeFlag[1])))

 ~~^~~~~~~~~


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

[Mario *LigH* Rohkrämer]

Am 14.11.2017, 11:11 Uhr, schrieb <kavi...@multicorewareinc.com>:


+.. option:: --copy-pic, --no-copy-pic
+
+	Allow encoder to copy input x265 pictures to internal frame buffers.  
When disabled,
+	x265 will not make an internal copy of the input picture and will work  
with the
+	application's buffers. While this allows for deeper integration, it is  
the responsbility
+	of the application to (a) ensure that the allocated picture has extra  
space for padding
+	that will be done by the library, and (b) the buffers aren't recycled  
until the library
+	has completed encoding this frame (which can be figured out by  
tracking NALs output by x265)

+
+   Default: enabled


I wonder how this is supposed to work with a CLI executable in a separate  
process.


When an application integrates x265 as a DLL or linked-in library, I can  
imagine that there are memory pointers to application buffers with frame  
contents which can be used by the encoder.


But when calling x265 as a separate process, how does it get the frame  
contents provided? Possibly as a pipe via STDIN or physical file. Means to  
me, via file handles, allocated by the OS.


Which means of controlling any RAM frame buffers are then available to a  
calling application?


In other words: Does it even make sense to expose these options to the CLI?

I'm curious about a usage example.

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Cosmetics: missing line break in CLI help for --refine-inter 1

[Mario *LigH* Rohkrämer]

You may also prefer to break at the end of the first sentence, just like  
--refine-intra 1 (except you have an agreement about a sensible maximum  
line width, which would be far beyond 78 characters anyway).



+
   --refine-intra <0..3> Enable intra refinement for encode that  
uses analysis-reuse-mode=load.
- 0 : Forces both mode and depth from  
the save encode.
- 1 : Functionality of (0) + evaluate  
all intra modes at min-cu-size's depth when current depth is one smaller  
than min-cu-size's depth.
- 2 : Functionality of (1) +  
irrespective of size evaluate all angular modes when the save encode  
decides the best mode as angular.
- 3 : Functionality of (1) +  
irrespective of size evaluate all intra modes.

Default:0
   --refine-inter <0..3> Enable inter refinement for encode that  
uses analysis-reuse-mode=load.
- 0 : Forces both mode and depth from  
the save encode.
- 1 : Functionality of (0) + evaluate  
all inter modes at min-cu-size's depth when current depth is one smaller  
than   min-cu-size's depth. When  
save encode decides the current block as skip(for all sizes) evaluate  
skip/merge.
- 2 : Functionality of (1) +  
irrespective of size restrict the modes evaluated when specific modes are  
decided as the best mode by the save encode.
- 3 : Functionality of (1) +  
irrespective of size evaluate all inter modes.

Default:0
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Future note: cmake_policy CMP0025 deprecates (CMake 3.9.x)

[Mario *LigH* Rohkrämer]

No urgent issue, just to have it mentioned for future changes...

Running a "make clean-generated" displays the following warning:

+
-- cmake version 3.9.2
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
  The OLD behavior for policy CMP0025 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 2 of 4] add new CLI refine-mv-type

[Mario *LigH* Rohkrämer]

A CLI help line is yet missing, even in full output level.

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add vbv-end to denote VBV emptiness after inserting all the frames into it

[Mario *LigH* Rohkrämer]

The new help lines lack of closing newline characters, the result is:

   --vbv-init Initial VBV buffer occupancy (fraction of  
bufsize or in kbits). Default 0.90
   --vbv-end  Final VBV buffer emptiness (fraction of  
bufsize or in kbits). Default 0 (disabled)   --vbv-end-fr-adj
Frame from which qp has to be adjusted to achieve final decode buffer  
emptiness. Default 0   --passMulti pass rate  
control.

   - 1 : First pass, creates stats file
   - 2 : Last pass, does not overwrite  
stats file

   - 3 : Nth pass, overwrites stats file


Am 06.11.2017, 07:12 Uhr, schrieb <ar...@multicorewareinc.com>:


diff -r aa9649a2aa8c -r 8a121d8cc134 source/x265cli.h
--- a/source/x265cli.h  Mon Nov 06 09:43:36 2017 +0530
+++ b/source/x265cli.h  Mon Nov 06 11:32:04 2017 +0530
@@ -147,6 +147,8 @@
 { "vbv-maxrate",required_argument, NULL, 0 },
 { "vbv-bufsize",required_argument, NULL, 0 },
 { "vbv-init",   required_argument, NULL, 0 },
+{ "vbv-end",required_argument, NULL, 0 },
+{ "vbv-end-fr-adj", required_argument, NULL, 0 },
 { "bitrate",required_argument, NULL, 0 },
 { "qp", required_argument, NULL, 'q' },
 { "aq-mode",required_argument, NULL, 0 },
@@ -443,6 +445,8 @@
 H0("   --vbv-maxrateMax local bitrate (kbit/s).  
Default %d\n", param->rc.vbvMaxBitrate);
 H0("   --vbv-bufsizeSet size of the VBV buffer  
(kbit). Default %d\n", param->rc.vbvBufferSize);
 H0("   --vbv-init Initial VBV buffer occupancy  
(fraction of bufsize or in kbits). Default %.2f\n",  
param->rc.vbvBufferInit);
+H0("   --vbv-end  Final VBV buffer emptiness  
(fraction of bufsize or in kbits). Default 0 (disabled)");
+H0("   --vbv-end-fr-adj   Frame from which qp has to be  
adjusted to achieve final decode buffer emptiness. Default 0");

 H0("   --passMulti pass rate control.\n"
"   - 1 : First pass, creates  
stats file\n"
"   - 2 : Last pass, does not  
overwrite stats file\n"



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Trying to migrate MSYS MinGW32 toolchain to MSYS2 MinGW32/64 of MABS

[Mario *LigH* Rohkrämer]

Greetings developers and contributors...

Because my usual provider of MSYS environments (XhmikosR) doesn't update  
regularly, and the original MSYS (Win32) project as such may be a bit  
obsolete already, I thought of moving to


https://github.com/jb-alvarado/media-autobuild_suite/

as a regularly self-updating MSYS2 x86-64 environment (using pacman) which  
provides both MinGW32 and MinGW64 launchers.


Of course, media-autobuild suite (MABS) builds its own Win32 and Win64  
binaries of x265. Still, I would like to manually build them on demand  
with my own options, and also keep the libx265 DLL's generated in parallel  
to the EXE's (which MABS does not save back).


So I tested a bit, tried to understand make and cmake errors, tuned my  
shell scripts building the HDR10+ versions ... but I hit my threshold when  
it came to editing the toolchain file for cross compilation  
(build/msys/toolchain-x86_64-w64-mingw32.cmake as template).


In the MSYS2 MinGW32 environment of MABS, the Win64 c.c. versions are not  
named "x86_64-w64-mingw32-*" but "i686-w64-mingw32-*" ... well, I guess I  
could have learned sed to patch this while copying the file to my own  
structure.


But furthermore, a Win64 c.c. version of windres seems to be completely  
missing (only the native windres.exe in msys64/mingw32/bin), and ranlib is  
gcc-ranlib (i686-w64-mingw32-gcc-ranlib.exe); and before copying files  
from one end to the other, I gave up here, using the workaround to start  
MinGW32 and MinGW64 separately now, for compiling a Win32 build and a  
Win64 build of x265 natively instead, without c.c. toolchain files.


If anyone cares, I wonder if toolchain files for an MSYS2 environment with  
MinGW32 or MinGW64, based on MABS, could be provided from the x265 project  
one day ... just an idea, no demand. But one or the other of you will  
probably be much more experienced than me, finding an elegant solution.


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] intra: skip RD analysis when sum of sub CUsplitcostbigger than non-split cost

[Mario *LigH* Rohkrämer]

Am 18.08.2017, 14:34 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@ligh.de>:

Am 11.08.2017, 21:32 Uhr, schrieb Ximing Cheng  
<chengximing1...@foxmail.com>:



splitrd-skip


Does not appear in the list of CLI commands in the help output.  
Intentional or forgotten?



My mistake. "--log-level full" disappeared from my script which logs help  
files of all built versions ... this is an advanced parameter, only  
documented in a verbose help output.


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] intra: skip RD analysis when sum of sub CUsplitcostbigger than non-split cost

[Mario *LigH* Rohkrämer]

Am 11.08.2017, 21:32 Uhr, schrieb Ximing Cheng  
<chengximing1...@foxmail.com>:



splitrd-skip


Does not appear in the list of CLI commands in the help output.  
Intentional or forgotten?


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Introduce refine-inter levels 2 and 3

[Mario *LigH* Rohkrämer]

Am 10.08.2017, 09:16 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@ligh.de>:



Online CLI documentation does not yet contain these parameters at all:

http://x265.readthedocs.io/en/default/cli.html?highlight=refine



Sorry, my mistake, something slipped in my browser.

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Introduce refine-inter levels 2 and 3

[Mario *LigH* Rohkrämer]

Online CLI documentation does not yet contain these parameters at all:

http://x265.readthedocs.io/en/default/cli.html?highlight=refine


Am 10.08.2017, 08:50 Uhr, schrieb Pradeep Ramachandran  
<prad...@multicorewareinc.com>:



On Wed, Aug 9, 2017 at 6:11 PM, <bha...@multicorewareinc.com> wrote:


# HG changeset patch
# User Bhavna Hariharan <bha...@multicorewareinc.com>
# Date 1500881283 -19800
#  Mon Jul 24 12:58:03 2017 +0530
# Node ID 81f17d9c7c273e4b282be66bf8bcd193e25a1d2e
# Parent  d11482e5fedbcdaf62ee3c6872f43827d99ad181
Introduce refine-inter levels 2 and 3



Pushed both patches to default branch


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] CMake output skipped while building sub-target dynamicHDR10

[Mario *LigH* Rohkrämer]

This gap still occurs to me on two different PCs with MSYS, CMake 3.8.2,  
GCC 7.1.0, being updated rather regularly.


...
[ 51%] Building CXX object common/CMakeFiles/common.dir/quant.cpp.obj
[ 53%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.obj
[ 53%] Built target common
	{ -- Missing "Scanning dependencies of target dynamicHDR10" and  
subsequent compilation details here -- }

[ 62%] Built target dynamicHDR10
Scanning dependencies of target encoder
[ 64%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.obj
[ 66%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
...

A file "8bit\dynamicHDR10\CMakeFiles\dynamicHDR10.dir\progress.make" was  
created anew. But neither  
8bit\dynamicHDR10\CMakeFiles\dynamicHDR10.dir\*.obj nor  
8bit\libhdr10plus.dll are rebuilt.


Building for Linux AMD64 (Ubuntu MATE v16 LTS, CMake 3.5.1, GCC 5.4.0-6)  
after a longer time without updates displays this section as expected;  
it's possibly that this branch had updates in the meantime.


...
[ 64%] Building CXX object common/CMakeFiles/common.dir/quant.cpp.obj
[ 65%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.o
[ 65%] Built target common
Scanning dependencies of target dynamicHDR10
[ 66%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/json11/json11.cpp.o
[ 68%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/JsonHelper.cpp.o
[ 69%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/metadataFromJson.cpp.o
[ 70%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/SeiMetadataDictionary.cpp.o
[ 72%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/api.cpp.o

[ 72%] Built target dynamicHDR10
Scanning dependencies of target encoder
[ 73%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.o
[ 74%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.o
...

But building it right again (not updating sources, only "make  
clean-generated" after the previous "make"), it's skipped as well:


...
[ 44%] Building CXX object common/CMakeFiles/common.dir/quant.cpp.o
[ 45%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.o
[ 65%] Built target common
[ 72%] Built target dynamicHDR10
Scanning dependencies of target encoder
[ 73%] Building CXX object encoder/CMakeFiles/encoder.dir/analysis.cpp.o
[ 74%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.o
...

So, while "make clean-generated" causes rebuilding all sub-targets, it  
does not for the sub-target "dynamicHDR10".



A question that still remains for me is:

What is the difference between (and the distinct purpose of each) "make  
clean" and "make clean-generated"?


Only this will be able to explain whether a) not building "dynamicHDR10"  
after "make clean-generated" is wrong, or b) rebuilding everything else  
(despite not having updated sources) may be.


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add csv feature into libx265

[Mario *LigH* Rohkrämer]

Am 12.06.2017, 11:47 Uhr, schrieb Divya Manivannan  
<di...@multicorewareinc.com>:



Add csv feature into libx265



May fit better to use "move" instead of "add" in the title...

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] dynamicHDR10 branch probably not cleaned?

[Mario *LigH* Rohkrämer]

I mean "make clean-generated", not "make clean".

I am not sure which difference between them is intended. All I can tell is  
that executing the sequence


make clean-generated
make

rebuilds all the sub-targets ("encoder", "common", "cli") apparently  
completely, only the sub-target "dynamicHDR10" seems to build only changed  
files; you can see that ~5% are skipped. So I wonder if either CMake  
builds too little for dynamicHDR10, or too much for the rest, in case of  
this sequence. Depends on the intended meaning of this target.




Am 06.06.2017, 11:34 Uhr, schrieb Bhavna Hariharan  
<bha...@multicorewareinc.com>:



On Mon, May 29, 2017 at 3:43 PM, Mario *LigH* Rohkrämer <cont...@ligh.de>
wrote:


I believe that the "dynamicHDR10" sub-target is not yet included in the
"clean-generated" rule, causing previously compiled files not to be  
deleted

in this directory branch when a cleanup was desired.

+
Scanning dependencies of target dynamicHDR10
[  1%] Building CXX object dynamicHDR10/CMakeFiles/dynami
cHDR10.dir/metadataFromJson.cpp.obj
+
# missing many more files here which are not built because their
compilation result probably still exists, despite a previous "make
clean-generated"



What are the files that aren't getting cleaned? I tried reproducing the
issue, all the dhdr10 files are being deleted after "make clean" and they
are re-generated after "make".



+
[  6%] Built target dynamicHDR10
Scanning dependencies of target encoder
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel





Regards,

Bhavna Hariharan



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] dynamicHDR10 branch probably not cleaned?

[Mario *LigH* Rohkrämer]

I believe that the "dynamicHDR10" sub-target is not yet included in the  
"clean-generated" rule, causing previously compiled files not to be  
deleted in this directory branch when a cleanup was desired.


+
Scanning dependencies of target dynamicHDR10
[  1%] Building CXX object  
dynamicHDR10/CMakeFiles/dynamicHDR10.dir/metadataFromJson.cpp.obj

+
# missing many more files here which are not built because their  
compilation result probably still exists, despite a previous "make  
clean-generated"

+
[  6%] Built target dynamicHDR10
Scanning dependencies of target encoder
+----

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] CMake output skipped while building sub-target dynamicHDR10

[Mario *LigH* Rohkrämer]

Plus:

There is also no bold pink line "Scanning dependencies of target  
dynamicHDR10", like it is reported for targets "encoder" and "common".


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] CMake output skipped while building sub-target dynamicHDR10

[Mario *LigH* Rohkrämer]

That's not the reason. I always run a "make clean-generated" before a  
"make".


All other sub-targets do report one line per source file.


Am 18.05.2017, 16:15 Uhr, schrieb Mateusz Brzostek  
<mate...@msystem.waw.pl>:


Maybe if you compile to empty/new folders everything is compiled, if you  
recompile -- only new components. dHDR10 was without changes from some  
time.



W dniu 2017-05-18 o 14:38, Mario *LigH* Rohkrämer pisze:


Out of curiosity, I just updated a former Ubuntu MATE 15 installation  
in a VBox to 16 LTS, re-installed required packages, and updated my  
build scripts to native Linux AMD64 compilation. Compiling works well  
so far... it has only GCC 5.4.0 pre-installed yet. Here the compilation  
of the sub-target dynamicHDR10 displays one green line per source file.



Am 16.05.2017, 16:10 Uhr, schrieb Mario *LigH* Rohkrämer  
<cont...@ligh.de>:


Nothing serious, just a bit confusing while watching the building  
progress:


All sub-targets of the CMake progress write an output line per  
compiled source file (in green), only the sub-target dynamicHDR10 does  
not (MSYS environemnt, GCC 6.3.0).


I wonder if it may be related to re-arranging blocks in the CMake  
structure to maintain support of GCC < 6 (0f5d890).


+
...
[ 67%] Built target common
[ 74%] Built target dynamicHDR10
...
+







___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] CMake output skipped while building sub-target dynamicHDR10

[Mario *LigH* Rohkrämer]

Out of curiosity, I just updated a former Ubuntu MATE 15 installation in a  
VBox to 16 LTS, re-installed required packages, and updated my build  
scripts to native Linux AMD64 compilation. Compiling works well so far...  
it has only GCC 5.4.0 pre-installed yet. Here the compilation of the  
sub-target dynamicHDR10 displays one green line per source file.



Am 16.05.2017, 16:10 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@ligh.de>:

Nothing serious, just a bit confusing while watching the building  
progress:


All sub-targets of the CMake progress write an output line per compiled  
source file (in green), only the sub-target dynamicHDR10 does not (MSYS  
environemnt, GCC 6.3.0).


I wonder if it may be related to re-arranging blocks in the CMake  
structure to maintain support of GCC < 6 (0f5d890).


+
...
[ 67%] Built target common
[ 74%] Built target dynamicHDR10
...
+




--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] CMake output skipped while building sub-target dynamicHDR10

[Mario *LigH* Rohkrämer]

Nothing serious, just a bit confusing while watching the building progress:

All sub-targets of the CMake progress write an output line per compiled  
source file (in green), only the sub-target dynamicHDR10 does not (MSYS  
environemnt, GCC 6.3.0).


I wonder if it may be related to re-arranging blocks in the CMake  
structure to maintain support of GCC < 6 (0f5d890).


+
...
[ 67%] Built target common
[ 74%] Built target dynamicHDR10
...
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Question about NUMA and core/thread use

[Mario *LigH* Rohkrämer]

Am 04.05.2017, 10:58 Uhr, schrieb Michael Lackner  
<michael.lack...@unileoben.ac.at>:



Still wondering why not 32, but ok.


x265 will calculate how many threads it will really need to utilize the  
WPP and other parallelizable steps, in relation to the frame dimensions  
and the complexity. It may not *need* more than 30 threads, would not have  
any task to give to two more. Possibly. Developers know better...


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Question about NUMA and core/thread use

[Mario *LigH* Rohkrämer]

Just a brief reply:

First, I compiled and linked against libnuma to build myself a  
NUMA-aware version. Then I

tried to encode some 8K content with wpp, pmode and pme.


Try as well without pmode or pme. These can easily have side effects, are  
only useful in specific cases. I would guess that WPP can work more  
efficiently without in most use cases, I just don't remember the  
explanation why (I know it had been discussed with Selur in the doom9  
forum before).


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] cmake: switch to c++11 for Clang and GCC

[Mario *LigH* Rohkrämer]

Am 27.04.2017, 15:27 Uhr, schrieb Mateusz Brzostek  
<mate...@msystem.waw.pl>:



After speed test:
GCC 7.0.1 and GCC 8.0.0 generates identical EXEs with -std=c++11 and  
-std=gnu++11.

The rest relative encoding time (to GCC 6.3 gnu++11)

x265c48 101,16%
x265g48 101,15%
x265c49 100,67%
x265g49 100,92%
x265c54 101,50%
x265g54 101,49%
x265c63 99,95%
x265g63 100,00%



Easily within statistical alienation. Just a few hardware interrupts or  
swap file accesses more or less during one or the other test in the pair  
of the same compiler version. I see no reason in comparing the "best of n  
results" to reduce this effect, with such low differences.


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Negative integer shifts

[Mario *LigH* Rohkrämer]

Hi.

Ma0 already submitted a patch on April 20th, which handles this issue by  
casting them to unsigned. I guess it was not yet committed.


By the way, Multicoreware prefers patches in plain text in the message  
body for easier review.



Am 26.04.2017, 16:54 Uhr, schrieb Andrey Semashev  
<andrey.semas...@gmail.com>:



Hi,

While compiling 2.4 I'm seeind lots of warnings like this:

.../source/common/ipfilter.cpp: In instantiation of ‘void
{anonymous}::interp_horiz_ps_c(const pixel*, intptr_t, int16_t*,
intptr_t, int, int) [with int N = 8; int width = 4; int height = 4;
pixel = unsigned char; intptr_t = long int; int16_t = short int]’:
.../source/common/ipfilter.cpp:417:5:   required from here
.../source/common/ipfilter.cpp:126:36: warning: left shift of negative
value [-Wshift-negative-value]
  int offset = -IF_INTERNAL_OFFS << shift;
   ~~^~~~

Left-shifting negative signed intehers is undefined behavior in C++.
I've attached a patch that resolves the warnings. The patch assumes 2's
complement signed integers and that the shift does not introduce an
arithmetic overflow.



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Dynamic HDR10 routines don't compile in GCC 6.3.0, missing C++11 compatibility

[Mario *LigH* Rohkrämer]

 {}
 ^~~~
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/json11/json11.h:107:5:  
error: with 'template json11::Json::Json(const T&)'

 Json(const T & t) : Json(t.to_json()) {}
 ^~~~
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/json11/json11.h:117:38:  
error: 'enable_if' in namespace 'std' does not name a template type

 template h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/json11/json11.h:117:47:  
error: expected '>' before '<' token

 template make[2]: ***  
[dynamicHDR10/CMakeFiles/dynamicHDR10.dir/json11/json11.cpp.obj] Error 1

make[1]: *** [dynamicHDR10/CMakeFiles/dynamicHDR10.dir/all] Error 2
make: *** [all] Error 2
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Dynamic HDR10 routines don't compile in GCC 6.3.0, missing C++11 compatibility

[Mario *LigH* Rohkrämer]

What more than "GCC 6.3.0" do you need to know? My build environment is  
based on:


http://xhmikosr.1f0.de/tools/msys/

with some customized scripts based on your build/msys shell scripts.

Maybe I should clean and clone freshly, not to accidently miss any changes.

Or did you not try to add "-DENABLE_DYNAMIC_HDR10=ON" to the CMake calls  
for 10 bit depth builds? Without this, there was just the shadowing  
warning. But with this addition, all the JSON sources (exclusive to  
dynamicHDR10 supporting builds) could not be built due to a lack of C++11  
compatibility.



Am 20.04.2017, 16:32 Uhr, schrieb Pradeep Ramachandran  
<prad...@multicorewareinc.com>:


What compiler are you trying with? We have seen some warnings, but most  
of

them are harmless. I haven't seen any errors yet though.
Pradeep.

On Thu, Apr 20, 2017 at 1:06 AM, Mario *LigH* Rohkrämer <cont...@ligh.de>
wrote:


When I add "-DENABLE_DYNAMIC_HDR10=ON" to my cmake calls, a huge load of
warnings and errors appears. Most are related to missing compatibility  
with

C++11.

Few examples:


In file included from h:/MSYS-GCC630/home/Entwicklun
g/x265/source/dynamicHDR10/BasicStructures.cpp:26:0:
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/BasicStructures.h:34:30:
warning: non-static data member initializers only available with  
-std=c++11

or -std=gnu++11
 float averageLuminance = 0.0;
  ^~~

In file included from h:\msys-gcc630\mingw\x86_64-w6
4-mingw32\include\c++\6.3.0\initializer_list:36:0,
 from h:/MSYS-GCC630/home/Entwicklun
g/x265/source/dynamicHDR10/json11/json11.h:57,
 from h:/MSYS-GCC630/home/Entwicklun
g/x265/source/dynamicHDR10/json11/json11.cpp:22:
h:\msys-gcc630\mingw\x86_64-w64-mingw32\include\c++\6.3.0\bits\c++0x_warning.h:32:2:
error: #error This file requires compiler and library support for the  
ISO

C++ 2011 standard. This support must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
 #error This file requires compiler and library support \
  ^


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel




--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Dynamic HDR10 routines don't compile in GCC 6.3.0, missing C++11 compatibility

[Mario *LigH* Rohkrämer]

When I add "-DENABLE_DYNAMIC_HDR10=ON" to my cmake calls, a huge load of  
warnings and errors appears. Most are related to missing compatibility  
with C++11.


Few examples:


In file included from  
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/BasicStructures.cpp:26:0:
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/BasicStructures.h:34:30:  
warning: non-static data member initializers only available with  
-std=c++11 or -std=gnu++11

 float averageLuminance = 0.0;
  ^~~

In file included from  
h:\msys-gcc630\mingw\x86_64-w64-mingw32\include\c++\6.3.0\initializer_list:36:0,
 from  
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/json11/json11.h:57,
 from  
h:/MSYS-GCC630/home/Entwicklung/x265/source/dynamicHDR10/json11/json11.cpp:22:
h:\msys-gcc630\mingw\x86_64-w64-mingw32\include\c++\6.3.0\bits\c++0x_warning.h:32:2:  
error: #error This file requires compiler and library support for the ISO  
C++ 2011 standard. This support must be enabled with the -std=c++11 or  
-std=gnu++11 compiler options.

 #error This file requires compiler and library support \
  ^


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 3 of 5] sei clean up

[Mario *LigH* Rohkrämer]

h:/MSYS-GCC630/home/Entwicklung/x265/source/encoder/sei.cpp: In member  
function 'void x265::SEI::write(x265::Bitstream&, const x265::SPS&)':
h:/MSYS-GCC630/home/Entwicklung/x265/source/encoder/sei.cpp:51:18:  
warning: declaration of 'type' shadows a previous local [-Wshadow]

 uint32_t type = m_payloadType;
  ^~~~
h:/MSYS-GCC630/home/Entwicklung/x265/source/encoder/sei.cpp:41:14: note:  
shadowed declaration is here

 uint32_t type = m_payloadType;
  ^~~~

Am 20.04.2017, 07:47 Uhr, schrieb <bha...@multicorewareinc.com>:


diff -r e2eb86dce7f4 -r 9c3ae5906579 source/encoder/sei.cpp
--- a/source/encoder/sei.cppWed Apr 19 16:36:59 2017 -0700
+++ b/source/encoder/sei.cppTue Mar 28 10:53:31 2017 +0530
@@ -38,24 +38,38 @@
  * in bitstream bs */
 void SEI::write(Bitstream& bs, const SPS& sps)
 {
+uint32_t type = m_payloadType; // <== #1
+m_bitIf = 
 BitCounter count;
-m_bitIf = 
+bool hrdTypes = (m_payloadType == ACTIVE_PARAMETER_SETS ||  
m_payloadType == PICTURE_TIMING || m_payloadType == BUFFERING_PERIOD);

+if (hrdTypes)
+{
+m_bitIf = 
+/* virtual writeSEI method, write to bit counter to determine  
size */

+writeSEI(sps);
+m_bitIf = 
+uint32_t type = m_payloadType; // <== #2
+for (; type >= 0xff; type -= 0xff)
+WRITE_CODE(0xff, 8, "payload_type");
+    }




--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Improved sao implementation by limiting sao types

[Mario *LigH* Rohkrämer]

Am 07.04.2017, 12:34 Uhr, schrieb <as...@multicorewareinc.com>:


diff -r 08a05ca9fd16 -r 195ae8f499fc doc/reST/cli.rst
--- a/doc/reST/cli.rst  Mon Mar 27 12:35:20 2017 +0530
+++ b/doc/reST/cli.rst  Mon Apr 03 16:02:07 2017 +0530
@@ -1690,6 +1690,12 @@
disabled, SAO analysis skips the right/bottom boundary areas.
Default disabled
+.. option:: --limit-sao, --no-limit-sao
+Limit SAO filter computation by early terminating SAO process based
+on inter prediction mode, CTU spatial-domain correlations, and  
relations

+between luma and chroma.
+Default disabled
+



(originally reported by stax76 in the doom9 forum)

This part of the patch causes issues in the rendered documentation  
(comparing to a  in HTML: as if you forgot  before ):


  * definition terms and descriptions apparently need to be separated from  
each other by empty lines in reST sources
  * for consistency, descriptions should probably be prepended by one tab  
instead of four spaces


See: http://x265.readthedocs.io/en/latest/cli.html#cmdoption-limit-sao


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] memory consumption when encoding 8K video

[Mario *LigH* Rohkrämer]

-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel





--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Use of ssim-rd not reported in x265 CLI [info] block

[Mario *LigH* Rohkrämer]

Reported by Motenai Yoda:

https://forum.doom9.org/showthread.php?p=1802058#post1802058

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Interested in fast popcnt substitute below SSE4.2?

[Mario *LigH* Rohkrämer]

Apparently not interesting...


Am 23.02.2017, 10:05 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@ligh.de>:


Another point of view on this matter:

http://danluu.com/assembly-intrinsics/

Seems to relativate the impact.

I don't know if you already knew about all this before...


Am 22.02.2017, 13:39 Uhr, schrieb Mario *LigH* Rohkrämer  
<cont...@ligh.de>:



http://wm.ite.pl/articles/sse-popcount.html

May even be faster than the popcnt instruction implemented in a  
supporting CPU!


Found via a German "conspiracy news" blog (no, that's not at all meant  
seriously) which sometimes also mentions computer security issues and  
interesting programming challenges: https://blog.fefe.de/?ts=a653b91f








--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 2 of 8] cli: add option to support multiple level of analysis mode refinement

[Mario *LigH* Rohkrämer]

# typo: analy»s«is

@@ -423,6 +424,7 @@
 H0("   --[no-]strict-cbr Enable stricter conditions and  
tolerance for bitrate deviations in CBR mode. Default %s\n",  
OPT(param->rc.bStrictCbr));
 H0("   --analysis-mode <string|int>  save - Dump analysis info into  
file, load - Load analysis buffers from the file. Default %d\n",  
param->analysisMode);
 H0("   --analysis-file Specify file name used for  
either dumping or reading analysis data.\n");
-H0("   --refine-level <1..5> Level of analyis refinement  
indicates amount of info stored/reused in save/load mode,  
1:least5:most. Default %d\n", param->analysisRefineLevel);
+H0("   --refine-level <1..5> Level of analysis refinement  
indicates amount of info stored/reused in save/load mode,  
1:least5:most. Default %d\n", param->analysisRefineLevel);
 H0("   --aq-modeMode for Adaptive Quantization -  
0:none 1:uniform AQ 2:auto variance 3:auto variance with bias to dark  
scenes. Default %d\n", param->rc.aqMode);
 H0("   --aq-strength  Reduces blocking and blurring in  
flat and textured areas (0 to 3.0). Default %.2f\n", param->rc.aqStrength);
 H0("   --[no-]aq-motion  Adaptive Quantization based on  
the relative motion of each CU w.r.t., frame. Default %s\n",  
OPT(param->bOptCUDeltaQP));



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Interested in fast popcnt substitute below SSE4.2?

[Mario *LigH* Rohkrämer]

Another point of view on this matter:

http://danluu.com/assembly-intrinsics/

Seems to relativate the impact.

I don't know if you already knew about all this before...


Am 22.02.2017, 13:39 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@ligh.de>:


http://wm.ite.pl/articles/sse-popcount.html

May even be faster than the popcnt instruction implemented in a  
supporting CPU!


Found via a German "conspiracy news" blog (no, that's not at all meant  
seriously) which sometimes also mentions computer security issues and  
interesting programming challenges: https://blog.fefe.de/?ts=a653b91f





--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Interested in fast popcnt substitute below SSE4.2?

[Mario *LigH* Rohkrämer]

http://wm.ite.pl/articles/sse-popcount.html

May even be faster than the popcnt instruction implemented in a supporting  
CPU!


Found via a German "conspiracy news" blog (no, that's not at all meant  
seriously) which sometimes also mentions computer security issues and  
interesting programming challenges: https://blog.fefe.de/?ts=a653b91f


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] complexAnalysis: clean up

[Mario *LigH* Rohkrämer]

I believe the constant 4 in the string should as well be changed to the  
variable X265_MAX_ANALYSIS_STRENGTH ?


Am 30.01.2017, 06:20 Uhr, schrieb <bha...@multicorewareinc.com>:


-CHECK(param->complexAnalysis < 0 || param->complexAnalysis > 4,
+CHECK(param->complexAnalysis < 0 || param->complexAnalysis >  
X265_MAX_ANALYSIS_STRENGTH,

 "Complex analysis strength must be between 0 and 4");

--------^

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Please try to visualize motion search methods

[Mario *LigH* Rohkrämer]

Am 05.12.2016, 05:53 Uhr, schrieb Pradeep Ramachandran  
<prad...@multicorewareinc.com>:


A recent post on doom9 points to this post that shows HEX/DIA/FULL  
search.

http://forum.doom9.org/showthread.php?p=693742


After collecting several sources, I made a post with several images  
(CC-BY: feel free to use for your web documentation, but first check if  
they are correct):


http://forum.doom9.org/showthread.php?p=1789660#post1789660

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Please try to visualize motion search methods

[Mario *LigH* Rohkrämer]

Am 05.12.2016, 05:53 Uhr, schrieb Pradeep Ramachandran  
<prad...@multicorewareinc.com>:


A recent post on doom9 points to this post that shows HEX/DIA/FULL  
search. http://forum.doom9.org/showthread.php?p=693742


Yes, there are a few examples. But I don't just ask for me alone. I ask  
for everyone who would be interested in understanding HEVC in general and  
x265 specifically. So I hope you will be able to display such images (and  
possibly even animations or color-layered images in cases of UMH and SEA?)  
on your web documentation (readthedocs).


If I already understood them all, I would even volunteer to create them.  
Unfortunately, I do not yet. But I can imagine that it will help imagining  
the tradeoffs between speed and quality, in relation to the probability of  
motion directions and coverage of a neighborhood of a currently discovered  
pixel/macroblock/CU ... I am already unsure about the base unit. Well,  
certainly not pixel.


--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] x265 patch(Store commonly-used RPS in SPS)

[Mario *LigH* Rohkrämer]

Am 24.10.2016, 08:57 Uhr, schrieb Zheng Wang <zh...@multicorewareinc.com>:

+ H0(" --[no-]multi-pass-opt-rps Enable storing commonly RPS in SPS in  
multi pass mode. Default %s\n", OPT(param->bMultiPassOptRPS));


Missed the "used" in "commonly *used* RPS".

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel