Am Montag, den 12.01.2015, 17:53 +0100 schrieb Sebastian Ramacher:
To me it looks like the check in the x265 should just check against
x265_max_bit_depth. Maybe something like the following patch could be
used instead of shipping two binaries that only differ in this check.
Nevertheless, the
On 2015-01-13 08:56:49, Fabian Greffrath wrote:
Am Montag, den 12.01.2015, 17:53 +0100 schrieb Sebastian Ramacher:
To me it looks like the check in the x265 should just check against
x265_max_bit_depth. Maybe something like the following patch could be
used instead of shipping two binaries
Am Dienstag, den 13.01.2015, 12:41 +0100 schrieb Sebastian Ramacher:
Why wouldn't it? The binary only parses command line options and writing
stats files. Everything else is passed to the library. Also, note the
Internal bit depth: 10 in the following output:
Hm, I was under the impression
On 2015-01-13 13:28:26, Fabian Greffrath wrote:
Am Dienstag, den 13.01.2015, 12:41 +0100 schrieb Sebastian Ramacher:
Why wouldn't it? The binary only parses command line options and writing
stats files. Everything else is passed to the library. Also, note the
Internal bit depth: 10 in the
Am Dienstag, den 13.01.2015, 13:34 +0100 schrieb Sebastian Ramacher:
Yes, x265_max_bit_depth is a constant defined in that way, but it is
exported by the library. So you get x265_max_bit_depth == 8 if you use
the 8 bit library and x265_max_bit_depth == 10 if you use the 10 bit
library.
Ah, I
Control: tags -1 confirmed patch
On 2015-01-12 11:08:34, djcj wrote:
Package: x265
Version: 1.4-5
Running the x265 binary with the 10 bit library version preloaded (which is
what the x265-10bit wrapper script does) does not work:
$ LD_PRELOAD=./libx265.so.35 ./x265 --pass 1 --bitrate 10
