Re: Fwd: Log for attempted build of x265_1.4-5 on m68k (dist=unstable)
On 2015-01-13 16:23:58, Thorsten Glaser wrote: libx265.so.35: undefined reference to `__sync_val_compare_and_swap_8' libx265.so.35: undefined reference to `__sync_or_and_fetch_8' Please do not assume all architectures have 64-bit atomics. http://buildd.debian-ports.org/status/fetch.php?pkg=x265arch=m68kver=1.4-5stamp=1421114612 This is fixed upstream and will be included in the 1.5 release. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: (no subject)
Thanks Sebastian. The patch you did provide works fine for me. I made a bug report to upstream: https://bitbucket.org/multicoreware/x265/issue/98/make-cli-work-with-any-bit-depth-version ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: x265-10bit doesn't work
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: x265-10bit doesn't work
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: x265-10bit doesn't work
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: x265-10bit doesn't work
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Fwd: Log for attempted build of x265_1.4-5 on m68k (dist=unstable)
libx265.so.35: undefined reference to `__sync_val_compare_and_swap_8' libx265.so.35: undefined reference to `__sync_or_and_fetch_8' Please do not assume all architectures have 64-bit atomics. http://buildd.debian-ports.org/status/fetch.php?pkg=x265arch=m68kver=1.4-5stamp=1421114612 bye, //mirabilos -- This space for rent. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#775181: x265-10bit doesn't work
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Log for attempted build of x265_1.4-5 on m68k (dist=unstable)
Sebastian Ramacher dixit: Please do not assume all architectures have 64-bit atomics. This is fixed upstream and will be included in the 1.5 release. Cool, thanks! bye, //mirabilos -- This space for rent. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
