Re: [x265] Issue #545: cmake error: list GET given empty list (multicoreware/x265)

Am 01.05.2020, 19:56 Uhr, schrieb Nikolas 'Nick' Raiser : CMake Error at CMakeLists.txt:623 (list): list GET given empty list CMake Error at CMakeLists.txt:624 (list): list GET given empty list Can you attach the CMakeLists.txt file to your issue? There might be several, not sure,

Re: [x265] Linking multilib binary fails in MSYS2/MinGW

Am 10.01.2020, 15:21 Uhr, schrieb 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)? Sorry, this topic seems to be specific, probably related to the

Re: [x265] Some compiler warnings under Linux

Forgot to mention: This was v3.1.1+1 Am 13.07.2019, 16:41 Uhr, schrieb 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*)’:

Re: [x265] bool should *not* be in a header file

Am 05.03.2019, 22:39 Uhr, schrieb Vittorio Giovara : Any C program including x265.h will fail to build because of this line x265_zone *x265_zone_alloc(int zoneCount, bool isZoneFile); Is it Groundhog Day again? That's not the first bool being complained. -- Fun and success! Mario *LigH*

Re: [x265] Another issue with MSYS2/MinGW windres: Output not writeable

Am 03.01.2019, 20:42 Uhr, schrieb Mateusz : W dniu 03.01.2019 o 18:45, Mario Rohkrämer pisze: Since you published the recent patches (e.g. to fix the version numbers), there was a report in the MABS project that windres failed again (here MinGW64): x265.rc:2: fatal error: when writing

[x265] Another issue with MSYS2/MinGW windres: Output not writeable

Since you published the recent patches (e.g. to fix the version numbers), there was a report in the MABS project that windres failed again (here MinGW64): x265.rc:2: fatal error: when writing output to : Broken pipe I tried that too, my error message is different but similar (here

Re: [x265] MSYS2/MinGW: RC version string syntax error

A patch suggested by wiiaboo, maintainer of media-autobuild_suite: https://0x0.st/s5C6.txt + diff -r 8f1c154aae5e source/CMakeLists.txt --- a/source/CMakeLists.txt Sat Dec 29 07:21:21 2018 +0100 +++ b/source/CMakeLists.txt Tue Jan 01 15:15:23 2019 + @@ -578,7 +578,7 @@ #

[x265] MSYS2/MinGW: RC version string syntax error

ninja log: + [8/91] Building RC object CMakeFiles/cli.dir/x265.rc.obj FAILED: CMakeFiles/cli.dir/x265.rc.obj H:\development\media-autobuild_suite-master\msys64\mingw32\bin\windres.exe -O coff -IH:/development/media-autobuild_suite-master/build/x265-hg/source

Re: [x265] [PATCH 1 of 2] zone: add support to parse zone files

Am 20.12.2018, 12:03 Uhr, schrieb : # HG changeset patch # User Bhavna Hariharan # Date 1544769275 -19800 # Fri Dec 14 12:04:35 2018 +0530 # Node ID 592b83c9068d7f402c85394fcf113b767b58f08d # Parent 1f44f1f1623d677c80469e713ed642f6673af91d zone: add support to parse zone files GCC

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

May be fixed already by the not yet approved patch by Aruna, sorry... to be checked when it's available. -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] zones file

Hi Alex. The use of is a syntax element that encloses descriptive names of variables. You must omit them if you actually use values. The "b" option uses a float value as multiplier of a bitrate calculated by the bitrate control, not an explicit bitrate value in kbps. So your example may

Re: [x265] Passing multiple images to x265 CLI

The current x265 CLI expects exactly one input file name. There is no logic coded to handle a sequence of input files to be processed. You will have to execute the encoder for one input file, wait for it to finish, and then start a new instance if there is more input to be encoded to a

[x265] More CMake warnings of old-style policies

With CMake 3.11, there are now already two deprecated old-style policies being warned: + -- cmake version 3.11.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)

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

o Chicago, IL +1 (773) 747-7546 www.TheLayeredMix.co.nf-Website hosted on Norfolk Island -Original Message- From: Mario *LigH* Rohkrämer Sent: Monday, April 23, 2018 7:55 AM To: Development for x265 Subject: Re: [x265] [PATCH] Add VMAF suppport to report per frame and aggregate VMAF score

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

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

Re: [x265] [PATCH 000 of 307 ] AVX-512 implementataion in x265: breaks 32-bit compilation

Am 07.04.2018, 04:29 Uhr, schrieb : This series of patches enables AVX-512 in x265. USe CLI option --asm avx512 to enable AVX-512 kernels. ___ x265-devel mailing list x265-devel@videolan.org

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

Am 02.04.2018, 14:49 Uhr, schrieb : +When HRD SEI is enabled the HM decoder will through a warning. *throw -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de ___ x265-devel mailing list

[x265] Report of possible issues with L-SMASH multiplexer, v2.7+14/+17

There is a report in the doom9 forum that multiplexing HEVC with L-SMASH's muxer.exe fails since v2.7+14 to v2.7+17; there was a SEI clean-up in between. https://forum.doom9.org/showthread.php?p=1837506#post1837506 -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de

Re: [x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

1 February 2018 at 21:13, Mario Rohkrämer <cont...@ligh.de> wrote: Hmm. Then ... - hg fails determining the version? (I had to clone the sources anew since I got an "unresolved merge" when I tried to update); - GCC 7.3.0 is new and does something wrong? I'd go with "don

Re: [x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

tch didn't touch anywhere near the version code. It's unrelated. On 1 February 2018 at 21:03, Mario Rohkrämer <cont...@ligh.de> wrote: I just built x265 2.6+37-1949157705ce in MSYS2/MinGW with GCC 7.3.0. Printing a full help page reports at first: x265 [info]: HEVC encoder version (null) x

[x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

I just built x265 2.6+37-1949157705ce in MSYS2/MinGW with GCC 7.3.0. Printing a full help page reports at first: x265 [info]: HEVC encoder version (null) x265 [info]: build info (null) A previous version reported e.g.: x265 [info]: HEVC encoder version 2.6+27-2f3c4158cf35 x265 [info]: build

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

Am 23.01.2018, 13:02 Uhr, schrieb Ricardo Constantino : On 16 January 2018 at 17:41, Ricardo Constantino wrote: # HG changeset patch # User Ricardo Constantino # Date 1516124393 0 # Tue Jan 16 17:39:53 2018 + # Node ID

Re: [x265] [PATCH] cli: add new option '--fullhelp'

Probably simply as convenient and x264-compatible shortcut of "--log-level full --help". Am 03.12.2017, 22:01 Uhr, schrieb Ashok Kumar Mishra : We have similar command line --help. Can you help me understand the purpose of introducing new command line

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

Am 15.11.2017, 17:15 Uhr, schrieb Pradeep Ramachandran : On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer wrote: Am 14.11.2017, 11:11 Uhr, schrieb : +.. option:: --copy-pic, --no-copy-pic + + Allow

Re: [x265] x265 encoder

Not quite a question for this mailing list ... But x264 is an encoder only as well. You can find decoders for most usual formats in the libav libraries (libavformats for container formats + libavcodec for content formats), being part of the ffmpeg or the libav project. Am 21.10.2017,

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

It's fixed now. Not sure which patch is responsible, but it's working. Am 18.05.2017, 16:35 Uhr, schrieb 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".

Re: [x265] Problems compiling the HEVC cpp code

om: x265-devel <x265-devel-boun...@videolan.org> on behalf of Mario Rohkrämer <cont...@ligh.de> Sent: Saturday, April 22, 2017 1:23 PM To: Development for x265 Subject: Re: [x265] Problems compiling the HEVC cpp code Hi. Which compiler are you using, exactly? Brand, versio

Re: [x265] [PATCH] cmake: set '-std=gnu++11' for GCC if ENABLE_DYNAMIC_HDR10 is on

Am 20.04.2017, 23:04 Uhr, schrieb Mateusz Brzostek : Current code for HDR10 needs gnu++11 for GCC at least. This patch sets '-std=gnu++11' for GCC only if ENABLE_DYNAMIC_HDR10 is set. Please review. A pity this patch did not make it into milestone 2.4 yet... --

[x265] x265 with Dynamic HDR10 support: Missing line break in full help

https://github.com/jb-alvarado/media-autobuild_suite can build x265 with DHDR10 support using GCC 6.3.0 by patching "-std=gnu++11" into source/CMakeLists.txt (using sed, not the cmake-hdr10.patch by Ma0 from April 20). I noticed a missing line break here in the full help output, in front

Re: [x265] Problems compiling the HEVC cpp code

Hi. Which compiler are you using, exactly? Brand, version? Compiling the sources will require compatibility to a specific C++ language level, usually specified by a year number, e.g. C++98. Am 22.04.2017, 19:12 Uhr, schrieb olsi teta : Hello, Good Afternoon,

[x265] Please try to visualize motion search methods

Only you, as the developers, will know which geometrical shapes the different motion search methods will use, only you can give us a visual impression how many samples in which direction and which distance will be considered for each method. I tried for a long time to find diagrams in the

Re: [x265] hevc_vaapi, jerky encode

Am 21.10.2016, 16:35 Uhr, schrieb Mani Vannan M. : Hi Not sure if this is the place to post regarding an issue with hevc_vaapi, but since i have absolutely no other headway anywhere and this is driving me crazy, posting it here. There is a abnormal behavior when

Re: [x265] Compression gains...results update

Remember, x265 optimizes for psycho-visually convenient results per default, which may look better to many, but may have worse PSNR and SSIM values. If you want to compare SSIM values with another encoder, use "--tune ssim"; if you want to compare PSNR results with another encoder, use

Re: [x265] Ghosting/artifacts even with low CRF

Just a nit: "--crf 0" is not meant to be "lossless", the quantization might still vary; "--qp 0" is certainly lossless, as documented in "x264 --fullhelp". But you should consider your file "quasi-lossless", with no noticeable difference. Am 15.07.2016, 20:25 Uhr, schrieb Rômulo Silva

Re: [x265] Birthday off today

Am 21.06.2016, 06:38 Uhr, schrieb Aarthi Priya Thirumalai : Hi all, I will be taking the day off on the occasion of my birthday. HB2U :) - Luck and health to you. May you receive the required recreation and power to continue afterwards. -- Fun and

[x265] Old issue? Zones in n-pass VBR may not be reliable

I was just surprised by a reply on a post in the doom9 video forum I already forgot due to no reply so far, from July 2015. I had a report in the German doom9/Gleitz forum that a user could not see any impact by zones on the final bitrate in the 2nd pass, only in 1st pass and 1-pass modes.

Re: [x265] [PATCH] presets: Updating presets to improve coding efficiency and speed

Well, I tried and it failed (10/10 rejects). So I have to rely on you. Am 23.12.2015, 06:08 Uhr, schrieb Mario Rohkrämer <cont...@ligh.de>: I don't know how to apply a patch manually, using TortoiseHg; but I will try and see... last chance to have it from me before Christmas is now.

Re: [x265] [PATCH] presets: Updating presets to improve coding efficiency and speed

I don't know how to apply a patch manually, using TortoiseHg; but I will try and see... last chance to have it from me before Christmas is now. Am 22.12.2015, 19:51 Uhr, schrieb Tom Vaughan : It is essentially ready to go. You could apply it to your

Re: [x265] v1.7+282: Multilib EXE doesn't link

Am 03.07.2015, 21:12 Uhr, schrieb Steve Borho st...@borho.org: On 07/03, Mario *LigH* Rohkr??mer wrote: Both 8bit/libx265_main12.a and 8bit/libx265_main10.a do exist. Still, linking to an EXE fails in an MSYS/MinGW environment, with either GCC 4.8.2 or GCC 4.9.2: + [100%] Linking CXX

Re: [x265] [PATCH 6 of 6] asm: upgrade runtime warning to explicit compile error

Am 06.03.2015, 18:07 Uhr, schrieb Steve Borho st...@borho.org: # HG changeset patch # User Steve Borho st...@borho.org # Date 1425661623 21600 # Fri Mar 06 11:07:03 2015 -0600 # Node ID 3eef0fe70475e17f5a671bf0dd522f89fb957b71 # Parent a07ea06f3ee8a5d1edb2edc584934d38f26583d8 asm: upgrade

[x265] Regarding new thread pooling: Low CPU utilization on Dual Xeon

There have been several reports already that the current x265 binaries are not very efficient since a new thread pooling was introduced. One of the members of the German speaking doom9/Gleitz video board - 'Massaguana' - reported a very low utilization, ~25-30% overall, on a dual socket

Re: [x265] Recent Frames/second benchmarks per platform and per clip?

Hi Raul. I am curious about the development of speed and efficiency too. But their use for me is rather marginal, without any AVX capable CPU. Especially recently, there was a lot of speed optimization mainly for AVX2. Way beyond AMD Phenom-II. I can only hope that it doesn't get slower

Re: [x265] patch for faster intra

Am 02.08.2014, 06:50 Uhr, schrieb Steve Borho st...@borho.org: ... But I imagine most presets that use this RDO version of intra will not want a fast scan. But maybe it is useful for a turbo mode. -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de

[x265] Many more warnings by GCC 4.8.2

No panic; I know that many reasons for warnings are less than serious. Just reporting. __ h:/MSYS/home/LigH/x265/source/Lib/TLibCommon/TComWeightPrediction.cpp: In member function 'void x265::TComWeightPrediction::getWpScaling(x265::TComDataCU*, int, int, x265::WeightParam*,

[x265] A few warnings from GCC 4.8.2

level.cpp + h:/MSYS/home/LigH/x265/source/encoder/level.cpp: In function 'void x265::determineLevel(const x265_param, x265::Profile::Name, x265::Level::Name, x265::Level::Tier)': h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array subscript is above array bounds

[x265] x265 0.8+247 (new XP compat.) crashes in single thread mode

I tested a bit in a VirtualBox and found that v0.8+149 (last XP compatible build before introducing the new threading model) works on an Unicore CPU in Windows XP SP3, but 0.8+247 (one 32 bit build which compiles in MSYS with WINXP_SUPPORT enabled again) reports disabled parallelism and

Re: [x265] [PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

According to my tests on an AMD Phenom II X6 1045T, speedup is marginal but probable in the average. -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.deCommand, Date/Time, Elapsed Time, FPS, Bitrate, Y PSNR, U PSNR, V PSNR, Global PSNR, SSIM, SSIM (dB), Version --frames 240

Re: [x265] Unable to encode huge frame sizes

Am 16.03.2014, 06:18 Uhr, schrieb JMK three4tee...@coldmail.nu: Details in the unofficial x265.exe thread at Videohelp: http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2308898viewfull=1#post2308898 Confirming: x265 8KTest.y4m --y4m --preset veryfast --crf 20 -o

Re: [x265] Unclear VUI options

Am 22.02.2014, 00:07 Uhr, schrieb dave dtyx...@gmail.com: by the way, there are other options where bt709 is possible, can that be used to determine range? I don't ecpect this to be easily detectable; instead I would rather assume that TV scale is in general more probable. Even movies

Re: [x265] Adding 64 bit building in MSYS to x265/build in repository ?

Am 14.02.2014, 18:59 Uhr, schrieb Steve Borho st...@borho.org: I've been making 64bit MinGW builds of x265 since the beginning without any toolchain scripts like that. You just need a 64bit MSYS and a 64bit MinGW compiler and use the current build/msys folder as-is. Now I wonder how to

[x265] F.R.: Report number of frame threads in [info] block

Feature Request: Since the number of concurrently encoded frames is per default derived from the available CPU cores, I miss the actual number in the x265 [info] output. It will be useful to know which number has been calculated if it was not enforced by a value different to 0 for

Re: [x265] F.R.: Report number of frame threads in [info] block

. So it is probably correct, just possibly not yet optimal. On Sat, Nov 23, 2013 at 6:48 AM, Mario Rohkrämer cont...@ligh.de wrote: Feature Request: Since the number of concurrently encoded frames is per default derived from the available CPU cores, I miss the actual number in the x265 [info

Re: [x265] Possible architecture specific bug in ~v0.5+439: 32-bit builds crash

Am 22.11.2013, 17:37 Uhr, schrieb Steve Borho st...@borho.org: On Nov 22, 2013, at 6:37 AM, Mario *LigH* Rohkrämer cont...@ligh.de wrote: Am 21.11.2013, 22:55 Uhr, schrieb Steve Borho st...@borho.org: On Thu, Nov 21, 2013 at 2:52 AM, Mario *LigH* Rohkrämer cont...@ligh.dewrote:

Re: [x265] [PATCH] input: read yuv input from stdin if filename is passed as -

Am 25.10.2013, 18:37 Uhr, schrieb Steve Borho st...@borho.org: I don't really care to do auto-detection of the stream type, and right now - always means YUV. Would it be acceptable if -.y4m is used to indicate Y4M on stdin? Probably not; the typical use, a quasi standard, is to have

Re: [x265] [PATCH] input: read yuv input from stdin if filename is passed as -

In x264 style you could have a setting that sets the used 'demuxer' (akin to --demuxer in x264). Some builds of x264 could include libav splitters, supporting a range of input formats directly; x265 is far from that, yet. Naturally the name of the setting could be changed if there are