of(line), zoneFile))
> +{
> +if (*line == '#' || (strcmp(line, "\r\n") == 0))
> +continue;
> +param->rc.zones[i].zoneParam = X265_MALLOC(x265_param, 1);
> +int index = (int)strcspn(line, "
ormat (CR+LF line endings), x265 was in UNIX file
format (only LF line ending). After this patch x265 is in none format -- most
lines ends with LF, some with CR+LF.
Regards,
Mateusz
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
t;hevc-aq enabled, disabling other
> aq-modes\n");
> +}
If hevc-aq doesn't use cuTree, maybe it is better to make sure that
p->rc.cuTree is 0 and simplify condition checking later
[...] = (m_param->rc.cuTree && !m_param->
patch/22290/raw/
applying https://patches.videolan.org/patch/22290/raw/
Mateusz@Mateusz-i7 /f/x265p/build/msys
$ hg diff
diff -r 8f1c154aae5e source/CMakeLists.txt
--- a/source/CMakeLists.txt Sat Dec 29 07:21:21 2018 +0100
+++ b/source/CMakeLists.txt Thu Jan 03 20:38:16 2019 +0100
@@ -5
fix '--dither' option for 10/12-bit and for not default bit depth (fixes
#255)
Mateusz
diff -r 5dbd6a0c8e17 source/x265-extras.cpp
--- a/source/x265-extras.cppMon Mar 28 12:53:40 2016 +0530
+++ b/source/x265-extras.cppSat Apr 02 21:35:11 2016 +0200
@@ -280,9 +280,9 @@
fpr
'--psy-rdoq' default value should be 1.0 according to the documentation
(not 0.0).
Mateusz
diff -r 5b01678f6fb4 source/common/param.cpp
--- a/source/common/param.cpp Sat Apr 02 19:08:49 2016 +0100
+++ b/source/common/param.cpp Fri Apr 08 12:33:58 2016 +0200
@@ -186,7 +186,7 @@
e default value (medium preset) turns off rdoq-level, psy-rdoq is
also turned off by default.
On Fri, Apr 8, 2016 at 4:19 PM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
'--psy-rdoq' default value should be 1.0 according to the
doc
There was applied modified version of this patch that doesn't work for
8-bit.
Command line to reproduce problem for 8-bit x265:
ffmpeg -i 720p50_parkrun_ter.y4m -v warning -strict -1 -pix_fmt
yuv420p16 -f yuv4mpegpipe - | x265 --y4m - --dither w.hevc
Why was the change?
Mateusz
W dniu
Fix VS 2015 warning:
x265\source\common\cpu.cpp(277): warning C4838: conversion from 'int' to
'const char' requires a narrowing conversion
diff -r 5b5374cae60f source/common/cpu.cpp
--- a/source/common/cpu.cpp Fri Apr 08 22:34:39 2016 +0530
+++ b/source/common/cpu.cpp Fri Apr 08 20:53:41
Change displayed info about '--limit-refs' to better understanding by user.
Example: change from
x265 [info]: References / ref-limit cu / depth : 5 / 0 / 1
to
x265 [info]: References / ref-limit cu / depth : 5 / off / on
diff -r 40afead3177d source/common/param.cpp
--- a/source/common/param.c
# HG changeset patch
# User Ma0
# Date 1460743796 -7200
# Fri Apr 15 20:09:56 2016 +0200
# Node ID 97557894ea10152cfa08b080b5e8b6e227b47bb3
# Parent 34a3d35c5f97c7ecf76bbb3311a9bbb66db0d695
cmake: change default arch for 32bit GCC from -march=i686 to
-march=pentium4 -mtune=generic
If som
Hello,
Recently I sent a patch(about 32bit GCC) in the new format -- inline +
"cmake:".
I hope new format is better.
Mateusz
W dniu 2016-04-12 o 21:16, Deepthi Nandakumar pisze:
Hi,
Thanks - please send the patch inline instead of as an attachment.
Also, the commit message doe
# HG changeset patch
# User Ma0
# Date 1461830370 -7200
# Thu Apr 28 09:59:30 2016 +0200
# Node ID 705b7ba5bad5da71f09292a4ee23544e89dac5b5
# Parent 19cced21060f71e8efe5f2544ccb14f9273fd93c
Allows for Unicode filenames in Windows (output and stat files).
Copy of x264 code for processing Un
Due to problem with breaking lines I sent this patch as attachment.
# HG changeset patch
# User Ma0
# Date 1461830370 -7200
# Thu Apr 28 09:59:30 2016 +0200
# Node ID 705b7ba5bad5da71f09292a4ee23544e89dac5b5
# Parent 19cced21060f71e8efe5f2544ccb14f9273fd93c
Allows for Unicode filenames in W
# HG changeset patch
# User Ma0
# Date 1461917775 -7200
# Fri Apr 29 10:16:15 2016 +0200
# Node ID 6a5c3dbd556d9dcc320439a9c601f06523ec79fb
# Parent 00ea3784bd36c164c5f799c998d7a09f2cb244bf
CLI: fix Unicode output in Windows for old mingw-w64
diff -r 00ea3784bd36 -r 6a5c3dbd556d source/co
not with Visual Studio
13(vc12), please can you check it.
encoder log - http://pastie.org/10821782
leak - http://pastie.org/10821781
On Thu, Apr 28, 2016 at 1:45 PM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
Due to problem with breaking lines I sent this patch as a
# HG changeset patch
# User Ma0
# Date 1462272360 -7200
# Tue May 03 12:46:00 2016 +0200
# Node ID 3dc1929c045ce5deefa066a4ba6e11c657466afb
# Parent 00ea3784bd36c164c5f799c998d7a09f2cb244bf
CLI: free memory allocated for utf8 command line in Windows
diff -r 00ea3784bd36 -r 3dc1929c045c so
# HG changeset patch
# User Ma0
# Date 1462446308 -7200
# Thu May 05 13:05:08 2016 +0200
# Node ID e9b1d21b8e32c2bc900d3700997c84bb38982889
# Parent 00ea3784bd36c164c5f799c998d7a09f2cb244bf
cmake: apply -march=i686 for 32bit GCC only if there is no -march in CXXFLAGS
diff -r 00ea3784bd36
# HG changeset patch
# User Ma0
# Date 1462954071 -7200
# Wed May 11 10:07:51 2016 +0200
# Node ID 081f36816156a813af6e3982ffc1dc10c9919e58
# Parent a5362b9533f6a5b77740b4e8f97dba2555b6f929
input: Allow Unicode filenames (input files) in Windows
diff -r a5362b9533f6 -r 081f36816156 source
# HG changeset patch
# User Ma0
# Date 1463269269 -7200
# Sun May 15 01:41:09 2016 +0200
# Node ID 882a67a80f470dc662f04ee3bfd13f1375a3d02e
# Parent e5b5bdc3c154f908706fb75e006f9abf9b3de96f
CLI: allow Unicode filenames (Windows) for '--qpfile' and '--csv'
diff -r e5b5bdc3c154 -r 882a67a80
# HG changeset patch
# User Ma0
# Date 1463338022 -7200
# Sun May 15 20:47:02 2016 +0200
# Node ID 3fb14cfcf331701190b3b71122253c42c77caf94
# Parent e5b5bdc3c154f908706fb75e006f9abf9b3de96f
CLI: new logic for '--pools ' option
For '--pools N' option we create exactly N threads.
For old lo
> Using numNumaNodes * MAX_POOL_THREADS as the upper-bound on the #
threads per numa node isn't the cleanest.
My intention was to use the upper-bound for whole threads number (on all
NUMAs).
This patch is only for case '--pools N' where N is a number, for example
'--pools 55' create exactly
If I use '--pools 6144 -F16' option with this patch on i5 CPU, I get
x265 [info]: Thread pool created using 64 threads
x265 [info]: frame threads / pool features : 16 / wpp(12 rows)
Without this patch I get only 4 threads.
This is the problem that I feared - since the HW
# HG changeset patch
# User Ma0
# Date 1463613567 -7200
# Thu May 19 01:19:27 2016 +0200
# Node ID 15086a8cfed77c0b9ca327e55062f834127a08f6
# Parent 7241944b3893cc7ee6df67ebceec06fa0916319a
CLI: simplify error message for '--frame-threads' option
diff -r 7241944b3893 -r 15086a8cfed7 source
Another fail with Thunderbird & inline patch, sorry.
# HG changeset patch
# User Ma0
# Date 1463613567 -7200
# Thu May 19 01:19:27 2016 +0200
# Node ID 15086a8cfed77c0b9ca327e55062f834127a08f6
# Parent 7241944b3893cc7ee6df67ebceec06fa0916319a
CLI: simplify error message for '--frame-threads
Still wrong, maybe inline + attached...
# HG changeset patch
# User Ma0
# Date 1463613567 -7200
# Thu May 19 01:19:27 2016 +0200
# Node ID 15086a8cfed77c0b9ca327e55062f834127a08f6
# Parent 7241944b3893cc7ee6df67ebceec06fa0916319a
CLI: simplify error message for '--frame-threads' option
dif
W dniu 2016-05-19 o 08:06, Mario *LigH* Rohkrämer pisze:
> Am 19.05.2016, 02:20 Uhr, schrieb Mateusz :
>
>> Still wrong, maybe inline + attached...
>
> As already guessed: I see your inline patch with long lines (client: M2 in
> Opera 12), you sent it as it was created. Y
>> The problem is with line of two chars:
>> [space][enter]
>> which is replaced to one char line:
>> [enter]
>>
>> Now I don't know how to fix this.
>
> Which line do you complain about? This one in the middle?
>
>> }
>> «
>> void x265_param_apply_fastfirstpass(x265_param* param)
Yes, this on
x265 hangs if you specify
x265 -D10 -p0 ducks_take_off_2160p50.y4m --level-idc 5.1 --bitrate 5 -o
w.hevc
It prints
x265 [warning]: lowering target bitrate to High tier limit of 16Kbps
but not set high-tier. Also 50'000 is not bigger than 160'000.
# HG changeset patch
# User Ma0
# Date 1
# HG changeset patch
# User Ma0
# Date 1464349717 -7200
# Fri May 27 13:48:37 2016 +0200
# Node ID 613aed65e8d422558bb8c3b85d55232379d55fe5
# Parent aeade2e8d8688ebffb8455b8948d89d6a72e2c38
threadpool: allow compilation for Windows XP
diff -r aeade2e8d868 -r 613aed65e8d4 source/common/threa
# HG changeset patch
# User Ma0
# Date 1464479547 -7200
# Sun May 29 01:52:27 2016 +0200
# Node ID ef28abdc61591385c52b8ba8324ab326be1df8df
# Parent aeade2e8d8688ebffb8455b8948d89d6a72e2c38
api: change name of 32-bit dll from libx265.dll to libx265-32.dll
diff -r aeade2e8d868 -r ef28abdc615
W dniu 2016-05-30 o 08:26, Mario *LigH* Rohkrämer pisze:
> Am 29.05.2016, 08:51 Uhr, schrieb Mateusz :
>
>> api: change name of 32-bit dll from libx265.dll to libx265-32.dll
>
> So in fact, if one builds separate DLLs depending on the internal bitdepth,
> they will now be
There is a serious bug in threadpool code that prevent working in Windows
XP/Vista.
VS 2015 error when compiling for 32-bit Windows XP:
(ClCompile target) ->
I:\vs\x265\source\common\threadpool.cpp(590): error C3861:
'GetNumaNodeProcessorMaskEx': identifier not found [I:\vs\x265\ma\
8-b\common\
# HG changeset patch
# User Ma0
# Date 1464927637 -7200
# Fri Jun 03 06:20:37 2016 +0200
# Node ID bd6f1daf85852177c0e2893d5edab182335ffb0e
# Parent 6098ba3e0cf16b110cff3b2519ce2d997ecac396
sao: silence warning
diff -r 6098ba3e0cf1 -r bd6f1daf8585 source/encoder/sao.cpp
--- a/source/encoder
This patch should be applied after patch 13312:
https://patches.videolan.org/patch/13312/
# HG changeset patch
# User Ma0
# Date 1466441386 -7200
# Mon Jun 20 18:49:46 2016 +0200
# Node ID 645b07a14c18436aecb1f75bb75a02d878909656
# Parent 354638efc8f5073881d571df4a3da209534e8502
CLI: allow
# HG changeset patch
# User Ma0
# Date 1468955593 -7200
# Tue Jul 19 21:13:13 2016 +0200
# Node ID 88fc302ae8ae5a6191ca6115e371f0777dacc0bb
# Parent 669dc9bfe7ebe40705cc055483d49d82c3fd9977
silence VS 2013 warning about g_scan4x4
diff -r 669dc9bfe7eb -r 88fc302ae8ae source/common/constants.
W dniu 2016-07-21 o 06:08, Pradeep Ramachandran pisze:
>
> On Wed, Jul 20, 2016 at 12:50 AM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
>
> # HG changeset patch
> # User Ma0 mailto:mateu...@poczta.onet.pl>>
> # Date 1468955593 -7200
> #
There are bugs in GCC 6.1 that prevent to compile working 32-bitx265for
Windows(on default options).
This patch adds '-msse' option to default 32-bit build option to avoid
different stack alignment.
# HG changeset patch
# User Ma0
# Date 1469540439 -7200
# Tue Jul 26 15:40:39 2016 +0200
#
misalignment problem
> that you are witnessing? Is there some new change to this option with 6.1
> that I am missing?
>
> Pradeep.
'-march=i686' is without MMX nor SSE, so '-msse' changes a bit. GCC 6.1 is
working OK with '-msse' option (but i
> Since you just want to stack alignment, so -mpreferred-stack-boundary is best
> choice.
> The -msse2 will allow compiler automatic generate SSE2 code, since we use C++
> code, it easy to catch compiler bugs, so I avoid to use these side effect
> option.
> --
> Min
OK, I've prepared new patch
modern so the patch should not change anything
if user set
export CXXFLAGS="-march=pentium4 -mtune=generic"
before it builds 32-bit GCC.
Mateusz
> On Thu, Jul 28, 2016 at 1:26 AM, Mateusz <mailto:mate...@msystem.waw.pl>> wrote:
>
> > Since you just want to stack
This patch fixes issue #282.
# HG changeset patch
# User Ma0
# Date 1476639059 -7200
# Sun Oct 16 19:30:59 2016 +0200
# Node ID f49487ee92a296a36938dfb92b7b51c9fb7f2ff9
# Parent c97805dad9148ad3cddba10a67ed5596508e8f86
CLI: allow 'mono' & 'mono16' color space for y4m input
diff -r c97805da
ffmpeg is going to add gray9/10/12 support to y4m.
This patch supports any one digit or two digits number after 'mono' in y4m
-- it works as in 420pXX case.
Please review.
Mateusz
# HG changeset patch
# User Ma0
# Date 1507448003 -7200
# Sun Oct 08 09:33:23 2017 +0200
---
source/input/y4m.cpp | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/source/input/y4m.cpp b/source/input/y4m.cpp
index 7ab0c22c0..38732643c 100644
--- a/source/input/y4m.cpp
+++ b/source/input/y4m.cpp
@@ -307,23 +307,26 @@ bool Y4MInput::pars
W dniu 2017-10-09 o 06:08, Pradeep Ramachandran pisze:
>
> On Sun, Oct 8, 2017 at 1:53 PM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
>
> MSVC (from VS 2017) gives 6 warnings:
> F:\x265\source\encoder\analysis.cpp(312): warning C4334: '<<
W dniu 2017-10-09 o 05:56, Pradeep Ramachandran pisze:
> On Sun, Oct 8, 2017 at 1:42 PM, Mateusz <mailto:mateu...@poczta.onet.pl>> wrote:
>
> ffmpeg is going to add gray9/10/12 support to y4m.
>
> This patch supports any one digit or two digits number after &
W dniu 03.12.2017 o 22:01, Ashok Kumar Mishra pisze:
> We have similar command line --help. Can you help me understand the purpose
> of introducing new command line --fullhelp.
'--help' shows short list, '--log-level full --help' shows full list but is
hard to remember and hard to write.
'--ful
W dniu 25.05.2017 o 06:46, Pradeep Ramachandran pisze:
>
> On Sun, Apr 30, 2017 at 5:24 PM, Mateusz Brzostek <mailto:mate...@msystem.waw.pl>> wrote:
>
> This patch fixes issue #341 and allows Unicode filenames in Windows.
>
> Please review.
>
> # HG
and it is defined in another file (nobody bother to check the value in another
file).
We could leave the macro MAXPARAMSIZE in param.h (with bigger value than 2000)
but I think that the formula:
bufSize = MAXPARAMSIZE + 16 * zones + length_of_all_remaining_%s
should stay.
Mateusz
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
s one improvement -- in y4m reader there are only two freads per frame
(instead of freads, fgets, freads). This gives tiny speed improvement
(most probable due to eliminate of fgets function and conserve L1 code cache).
Mateusz
>
> On Wed, Jan 10, 2018 at 8:04 PM, Mateusz <mailto:mateu
W dniu 01.02.2018 o 22:13, Mario Rohkrämer pisze:
> 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);
It could be due to outdated hg (mercurial) version. Version 4.4.2 should work
OK.
__
W dniu 07.04.2018 o 04:35, mythr...@multicorewareinc.com pisze:
> # HG changeset patch
> # User Jayashree
> # Date 1522928767 -19800
> # Thu Apr 05 17:16:07 2018 +0530
> # Node ID f6ad2fa637fd3c8f9e2811982b89aa28228e9f6b
> # Parent 876b6e006f2080072c0684dbf75e7cfde974ba79
> x86:AVX512 Set ru
nfo]: build info [Windows][MSVC 1914][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1
Old GCC builds are not affected (probably in GCC sscanf validates if last
argument is NULL).
Mateusz
>
> On Fri, Apr 13, 2018 at 10:05 AM, Mateusz <mailto:mateu...
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
.
I found also mjpeg (yuv4mpeg creator?):
http://mjpeg.cvs.sourceforge.net/viewvc/mjpeg/mjpeg_play/utils/yuv4mpeg.h?revision=1.28&view=markup
-- see line 641.
Mateusz
W dniu 2016-10-25 o 06:18, Pradeep Ramachandran pisze:
>
> On Sun, Oct 16, 2016 at 11:17 PM, Mateusz <mailto:ma
# 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
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
# 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
# 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
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
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
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
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 7b55d81f0677b7cbef5a490d9
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
# 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
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
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
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
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;
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
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
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
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
%
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
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
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
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
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
78 matches
Mail list logo
