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

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

Re: [x265] Piping very large frames to x265 fails

W dniu 2017-05-11 o 15:21, Michael Lackner pisze: > Hello, > > Hate to nag you people again, but I ran into something interesting. I've been > piping a 24p > 10-bit video in 8192x3428 to x265 from ffmpeg. Works fine. > > Now I tried with 16:9 content, so a larger 8192x4608 resolution. Works fine

[x265] [PATCH] cmake: restore order of options changed by commit d00f2f5 (important for GCC < 6)

For GCC 5.4, 4.9 and 4.8 option '-std=gnu++11' must be more in front of rest of options. Sorry that I didn't check this earlier. I propose to move 'option(ENABLE_DYNAMIC_HDR10 ...' before we check if ENABLE_DYNAMIC_HDR10 is ON -- now it is not important, but in the future it might be ON by defa

[x265] [PATCH] input: change from ifstream to stdio stream

This patch fixes issue #341 and allows Unicode filenames in Windows. Please review. # HG changeset patch # User Ma0 # Date 1493552587 -7200 # Sun Apr 30 13:43:07 2017 +0200 # Node ID 0c7e08be80975e4b52f6c8aabe95d3b817d6723d # Parent 5bc5e73760cdb61d2674e74cc52149fa0603af8a input: change fr

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

% x265c63 99,95% x265g63 100,00% For GCC 4.8.5 and GCC 5.4 -- gnu++11 wins, for GCC 4.9.4 and GCC 6.3 -- c++11 wins. I think it is OK to set -std=c++11 for GCC. W dniu 2017-04-26 o 12:27, Mateusz Brzostek pisze: > I will make speed test -std=c++11 vs. -std=gnu++11 (in the ni

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

04/25/2017 04:43 PM, Stephen Hutchinson wrote: >> On 4/25/2017 4:25 AM, Mateusz Brzostek wrote: >>> After tests with GCC from 4.8 to 8.0 I think it is OK to change to c++11 >>> from c++98 (for >>> -DENABLE_DYNAMIC_HDR10=ON and OFF). >>> >>> Selur (Hy

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

After tests with GCC from 4.8 to 8.0 I think it is OK to change to c++11 from c++98 (for -DENABLE_DYNAMIC_HDR10=ON and OFF). Selur (Hybrid author) wrote that for Clang it should be c++11 instead of gnu++11, so we can set for Clang c++11, for GCC gnu++11. Please review. # HG changeset patch # U

[x265] [PATCH] CLI: small fixes for dhdr10

There is missing enter in '--help' with dhdr10 (and it should be TOOLOPT instead of TOOLVAL). # HG changeset patch # User Ma0 # Date 1492724724 -7200 # Thu Apr 20 23:45:24 2017 +0200 # Node ID 36996838a99ff5fa75221fde6c3a91d1b108d9d2 # Parent 2c6e6c9c3da72aaddb33565d7031918fb5a37097 CLI: s

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

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. # HG changeset patch # User Ma0 # Date 1492721872 -7200 # Thu Apr 20 22:57:52 2017 +0200 # Node ID 4fb381f7332d4efac82b55bccbbf8de78c622110 # Pa

[x265] [PATCH] silence MSVC warning C4334 and GCC warnings for '-std=gnu++11'

This patch fixes issue #329 for MSVC and if someone wants to compile with GCC for '-std=gnu++11' instead of default gnu++98, there will be no f:/x265p/source/common/ipfilter.cpp:212:36: warning: left shift of negative value [-Wshift-negative-value] int offset = -IF_INTERNAL_OFFS << shift;

[x265] [PATCH] CLI: informs if '--ssim-rd' is used

There are complaints about no information if '--ssim-rd' option is used or not (reported by Motenai Yoda and LigH). # HG changeset patch # User Ma0 # Date 1491872880 -7200 # Tue Apr 11 03:08:00 2017 +0200 # Node ID 0ef56c154e54d9d4eb684b92281e85172b7a3866 # Parent c7b7c736696f67d990d4c7736

[x265] [PATCH] fix maxSlices limit checking

In message [x265] x265 crashes/gets stuck when giving more than '--slices 16' there is description of crash. You can reproduce this crash by: x265 --slices 17 ducks_take_off_1080p50.y4m out.hevc This small patch avoid the crash. Please review. # HG changeset patch # User Ma0 # Date 1489188353 -3

[x265] [PATCH] CLI: fix '--seek' option for pipe input

This small patch is to fix issue #324. Please review. # HG changeset patch # User Ma0 # Date 1489176787 -3600 # Fri Mar 10 21:13:07 2017 +0100 # Node ID 2b53475eb1916eceed880276b9ca368387badd4c # Parent 88fd9082764c7d7b4668e30763a93215980efd70 CLI: fix '--seek' option for pipe input diff

[x265] [PATCH] doc: update info about bframes in help

# HG changeset patch # User Ma0 # Date 1487708192 -3600 # Tue Feb 21 21:16:32 2017 +0100 # Node ID e411b24877eb8e3b382186d120e0f5c0129cc7f8 # Parent 820f4327ddac44decb4328602ca63e84197ab473 doc: update info about bframes in help diff -r 820f4327ddac -r e411b24877eb source/x265cli.h --- a/so

Re: [x265] [PATCH] SAO: avoid negative indexes in 'x265_lambda2_tab' table

W dniu 2017-02-16 o 03:54, Pradeep Ramachandran pisze: > > On Thu, Feb 16, 2017 at 12:11 AM, Mateusz Brzostek <mailto:mate...@msystem.waw.pl>> wrote: > > This patch fixes issue #323 -- crash when encoding to 422. The 'qpCb' > index is -2 on Selur's

[x265] [PATCH] SAO: avoid negative indexes in 'x265_lambda2_tab' table

This patch fixes issue #323 -- crash when encoding to 422. The 'qpCb' index is -2 on Selur's sample file and options. Please review. Mateusz # HG changeset patch # User Ma0 # Date 1487183578 -3600 # Wed Feb 15 19:32:58 2017 +0100 # Node ID 7b55d81f0677b7cbef5a490d90bd9cbbf96127cb # Parent

Re: [x265] silence GCC 7 warnings

Sorry for previous patch (problems with spaces). Proper patch in attachment. Mateusz # HG changeset patch # User Ma0 # Date 1486838752 -3600 # Sat Feb 11 19:45:52 2017 +0100 # Node ID 4501964283cf57c636f33c8978ee0297b1af1592 # Parent fe2f2dd96f8cf9fb88a720a96aab4ff5b21768df silence GCC 7

Re: [x265] update the year in output stream header

Sorry for previous patch which was too short by one space. # HG changeset patch # User Ma0 # Date 1486830205 -3600 # Sat Feb 11 17:23:25 2017 +0100 # Node ID 44b7392e2eef01673c5c064a443b2ab5682eb04c # Parent fe2f2dd96f8cf9fb88a720a96aab4ff5b21768df update the year in output stream header d

[x265] silence GCC 7 warnings

There are GCC 7 warnings: f:/x265p/source/encoder/ratecontrol.cpp: In member function 'double x265::RateControl::rateEstimateQscale(x265::Frame*, x265::Ra teControlEntry*)': f:/x265p/source/encoder/ratecontrol.cpp:1899:39: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-cont

[x265] update the year in output stream header

# HG changeset patch # User Ma0 # Date 1486830205 -3600 # Sat Feb 11 17:23:25 2017 +0100 # Node ID 44b7392e2eef01673c5c064a443b2ab5682eb04c # Parent fe2f2dd96f8cf9fb88a720a96aab4ff5b21768df update the year in output stream header diff -r fe2f2dd96f8c -r 44b7392e2eef source/encoder/encoder.c

[x265] CLI: allow Unicode filenames (Windows) for 'scaling-list', 'lambda-file' and 'analysis-file'

# HG changeset patch # User Ma0 # Date 1486827593 -3600 # Sat Feb 11 16:39:53 2017 +0100 # Node ID b0942b7ef3b4c6085e70aa1cc8ab3686118ed297 # Parent fe2f2dd96f8cf9fb88a720a96aab4ff5b21768df CLI: allow Unicode filenames (Windows) for 'scaling-list', 'lambda-file' and 'analysis-file' diff -r

[x265] Move XSTR macro to common.h

In common/version.cpp it is a macro XSTR. We could move the macro to common.h and use it for error/warning messages like LigH pointed in 'complexAnalysis: clean up' thread. # HG changeset patch # User Ma0 # Date 1485793398 -3600 # Mon Jan 30 17:23:18 2017 +0100 # Node ID f3cfc60b1011ca006bb

[x265] update the year in output stream header

# HG changeset patch # User Ma0 # Date 1478471056 -3600 # Sun Nov 06 23:24:16 2016 +0100 # Node ID a378efc939e37f13ec1673fda055b1c3d0632e68 # Parent 583fc74fc0a29f330187dbd78151c30a3e03d5a7 update the year in output stream header diff -r 583fc74fc0a2 -r a378efc939e3 source/encoder/encoder.c

Re: [x265] CLI: allow 'mono' & 'mono16' color space for y4m input

I've based on FFmpeg -- if you execute wrong pixel format for y4m, for example: ffmpeg -i 720p50_parkrun_ter.y4m -pix_fmt monow -f yuv4mpegpipe w.y4m you can see error message: ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats. And using 'strict -1' also y

Re: [x265] [PATCH] Fix bug in reading 32x32 scalinglists

For command x265 --vbv-maxrate 1 --vbv-bufsize 1 720p50_parkrun_ter.y4m w.hevc in function Encoder::create() in line #278 double start = quantF / (m_scalingList.m_quantCoef[trSize][numList][QP_MAX_SPEC % 6][i]); trSize is 0, 1, 2 and 3 numList is 1 so with trSize == 3 && numList == 1 there