Bug#775181: x265-10bit doesn't work

2015-01-13 Thread Fabian Greffrath 
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 8-bit binary would not work with the 10-bit library,
right?

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775181: x265-10bit doesn't work

2015-01-13 Thread Fabian Greffrath 
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 that x265_max_bit_depth was a constant
that is set at build time to either 10 or 8 depending on the
HIGH_BIT_DEPTH macro being #defined or not. And param-internalBitDepth
is a symbol exported by the lib, right?

So, how can the eqsuation be true for the 8-bit library
(param-internalBitDepth = 8) and the frontend from the 10-bit build
(x265_max_bit_depth = 10)?

I am puzzled.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775181: x265-10bit doesn't work

2015-01-13 Thread Sebastian Ramacher 
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 following output:
 
 Hm, I was under the impression that x265_max_bit_depth was a constant
 that is set at build time to either 10 or 8 depending on the
 HIGH_BIT_DEPTH macro being #defined or not. And param-internalBitDepth
 is a symbol exported by the lib, right?

 So, how can the eqsuation be true for the 8-bit library
 (param-internalBitDepth = 8) and the frontend from the 10-bit build
 (x265_max_bit_depth = 10)?

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.

I hope this clears things up.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#775181: x265-10bit doesn't work

2015-01-13 Thread Sebastian Ramacher 
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 that only differ in this check.
 
 Nevertheless, the 8-bit binary would not work with the 10-bit library,
 right?

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:

$ x265-10bit /tmp/patched-x265/x265 --bitrate 10 /tmp/riverbed_1080p25.y4m -o 
/tmp/r10.out
y4m  [info]: 1920x1080 fps 25/1 i420p8 sar 1:1 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.4
x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 17 / 2 / 4
x265 [info]: Internal bit depth  : 10
x265 [info]: CTU size / RQT depth inter / intra  : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut   : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-10 kbps / 1.0 / 1
x265 [info]: tools: rd=3 lft sao signhide tmvp
^C
$ /tmp/patched-x265/x265 --bitrate 10  /tmp/riverbed_1080p25.y4m -o /tmp/r8.out
y4m  [info]: 1920x1080 fps 25/1 i420p8 sar 1:1 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.4
x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 17 / 2 / 4
x265 [info]: CTU size / RQT depth inter / intra  : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut   : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-10 kbps / 1.0 / 1
x265 [info]: tools: rd=3 lft sao signhide tmvp
^C

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#775181: x265-10bit doesn't work

2015-01-13 Thread Fabian Greffrath 
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 see. This is what happens in
source/common/param.cpp:x265_param_default():

param-internalBitDepth = x265_max_bit_depth;

Now it gets clear to me. ;)

Thanks!

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775181: x265-10bit doesn't work

2015-01-12 Thread djcj 

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 -o /dev/null 
test.y4m

x265 [error]: Only bit depths of 8 are supported in this build

You have to build the CLI together with the library.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775181: x265-10bit doesn't work

2015-01-12 Thread Sebastian Ramacher 
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 -o /dev/null
 test.y4m
 x265 [error]: Only bit depths of 8 are supported in this build
 
 You have to build the CLI together with the library.

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.

diff --git a/source/x265.cpp b/source/x265.cpp
--- a/source/x265.cpp
+++ b/source/x265.cpp
@@ -659,19 +659,11 @@
 return true;
 }
 
-#if HIGH_BIT_DEPTH
-if (param-internalBitDepth != 10)
+if (param-internalBitDepth != x265_max_bit_depth)
 {
-x265_log(param, X265_LOG_ERROR, Only bit depths of 10 are supported 
in this build\n);
+x265_log(param, X265_LOG_ERROR, Only bit depths of %d are supported 
in this build\n, x265_max_bit_depth);
 return true;
 }
-#else
-if (param-internalBitDepth != 8)
-{
-x265_log(param, X265_LOG_ERROR, Only bit depths of 8 are supported in 
this build\n);
-return true;
-}
-#endif // if HIGH_BIT_DEPTH
 
 InputFileInfo info;
 info.filename = inputfn;

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature