Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[Steve Langasek]

Package: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch autopkgtest

Dear maintainers,

The latest release of ffmpeg enables NEON support by default when building
on armhf; however, NEON support is not a standard part of the ARMv7 ABI, and
Debian supports running armhf on chips that do not implement NEON.

Using NEON based on runtime detection of support for it is fine, but the
existing ffmpeg implementation doesn't appear to do this, instead using NEON
based on build-time configuration with no fallback.

This issue was noticed in Ubuntu only because the autopkgtests for ffmpeg
and x264 triggered an unaligned access in the NEON code, which is *also* not
a portable assumption on armhf; however, if the NEON code had not had any
unaligned access, the fact that NEON was used would have gone unnoticed on
Ubuntu infrastructure.

  http://autopkgtest.ubuntu.com/packages/f/ffmpeg/artful/armhf
  http://autopkgtest.ubuntu.com/packages/x/x264/artful/armhf

(And if upstream does fix their code to support runtime detection of NEON
support, then there will be a different bug for us to worry about fixing!)

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ffmpeg-3.3.3/debian/rules ffmpeg-3.3.3/debian/rules
--- ffmpeg-3.3.3/debian/rules   2017-08-01 07:33:41.0 -0700
+++ ffmpeg-3.3.3/debian/rules   2017-08-03 17:43:44.0 -0700
@@ -127,6 +127,14 @@
--enable-libiec61883
 endif
 
+# upstream does not implement runtime detection of NEON support at runtime;
+# therefore NEON must be disabled at build time.  (This also works around
+# the fact that the NEON implementation does unaligned access, which is not
+# a portable assumption for armhf.)
+ifeq ($(DEB_HOST_ARCH),armhf)
+   CONFIG += --disable-neon
+endif
+
 # Some build-dependencies are not installable on some architectures.
 ifeq (,$(filter $(DEB_HOST_ARCH),powerpcspe))
CONFIG_extra += --enable-netcdf
___
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#870668: handbrake: Could this be "Architecture: any"?

[Edmund Grimley Evans]

Source: handbrake
Version: 1.0.7+ds1-2
User: debian-...@lists.debian.org
Usertag: arm64

Could this be "Architecture: any"? It seems to build on arm64.

___
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: Version 0.35.2-2 of guitarix is marked for autoremoval from testing on 2017-07-30.

[Ross Gammon]

Hi Hermann,

On 03/08/17 20:54, Hermann Meyer wrote:
> Am 22.07.2017 um 06:34 schrieb Hermann Meyer:
>>
>> Hi
>>
>> It is affected by RC bug #866641 .
>>
>> Please consider to update guitarix to the latest version 0.35.5, which
>> fix this "bug".
>>

Thanks for being so fast to deal with this bug.


> Really, no one?
> 
> It's a pity to see guitarix in debian in such a bad shape. I've tried to
> contact Víctor Cuadrado Juan, who is the current maintainer from the
> (Debian Multimedia Maintainers
> )
> team, for guitarix in debian, but get no response.


Please be a little patient. Victor maybe on holiday, travelling with
work, ill, or have a broken computer. The bug was only reported just
over a month ago, and that is not so long.

> 
> For me , as upstream maintainer, the current situation is a real pity.
> Guitarix is in debian since 2013 05 05 and I'm, as upstream maintainer
> have all the time full-fill any request of debian maintainers.
> Next removal is date is  2017-08-13.
> Seeing that it is for a "bug" witch is currently unrelated for
> debian-testing, is a way more annoying.
> 

Guitarix is not being removed from Debian, only from unstable, which is
not what most users are running.

> Are the debian multimedia maintainers been in such a bad shape to let it
> go and leaf me, as upstream maintainer alone?
> 
> regards
> hermann

I was considering looking after Guitarix before Victor stepped in. If I
find some time over the next few weeks, and noone else has stepped in
(maybe Victor?), I will see if I can help out.

-- 
Regards,

Ross Gammon

___
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: Version 0.35.2-2 of guitarix is marked for autoremoval from testing on 2017-07-30.

[Hermann Meyer]

Am 22.07.2017 um 06:34 schrieb Hermann Meyer:


Hi

It is affected by RC bug #866641 .

Please consider to update guitarix to the latest version 0.35.5, which 
fix this "bug".



regards

hermann




Really, no one?

It's a pity to see guitarix in debian in such a bad shape. I've tried to 
contact Víctor Cuadrado Juan, who is the current maintainer from the 
(Debian Multimedia Maintainers 
) 
team, for guitarix in debian, but get no response.


For me , as upstream maintainer, the current situation is a real pity.
Guitarix is in debian since 2013 05 05 and I'm, as upstream maintainer 
have all the time full-fill any request of debian maintainers.

Next removal is date is  2017-08-13.
Seeing that it is for a "bug" witch is currently unrelated for 
debian-testing, is a way more annoying.


Are the debian multimedia maintainers been in such a bad shape to let it 
go and leaf me, as upstream maintainer alone?


regards
hermann

___
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#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

[peter green]

On 03/08/17 14:07, James Cowgill wrote:

Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org

Hi,

I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz

It fails with SIGBUS when running the h264 tests.


(gdb) bt
#0  0xf6456e12 in ff_h264_idct_add_neon () at 
src/libavcodec/arm/h264idct_neon.S:24
#1  0xf6456f3c in ff_h264_idct_add16_neon () at 
src/libavcodec/arm/h264idct_neon.S:118
#2  0xf659c88c in hl_decode_mb_idct_luma (p=, dest_y=, 
linesize=, block_offset=, pixel_shift=0, transform_bypass=0, 
simple=1,
 mb_type=, sl=, h=) at 
src/libavcodec/h264_mb.c:778
#3  hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=) at 
src/libavcodec/h264_mb_template.c:349
#4  0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00, 
sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
#5  0xf65b3670 in decode_slice (avctx=, 
arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
#6  0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at 
src/libavcodec/h264_slice.c:2728
#7  0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "", 
h=0xaab6ea00) at src/libavcodec/h264dec.c:715
#8  h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70, got_frame=0xaab38a2c, 
avpkt=) at src/libavcodec/h264dec.c:1016
#9  0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at 
src/libavcodec/pthread_frame.c:199
#10 0xf61895e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) print $pc
$1 = (void (*)()) 0xf6456e12 
(gdb) disassemble
Dump of assembler code for function ff_h264_idct_add_neon:
0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
0xf6456e14 <+4>: vmov.i16q15, #0 ; 0x
0xf6456e18 <+8>: vswpd1, d2
0xf6456e1c <+12>:vst1.16 {d30-d31}, [r1 :128]!

Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.

Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:


--- h264idct_neon-binutils-2.28-5   2017-08-03 12:48:07.560036237 +
+++ h264idct_neon-binutils-2.29-3   2017-08-03 12:47:43.666083113 +
@@ -89,8 +89,8 @@
   118:  f04f 0e00   movne.w lr, #0
   11c:  f1be 0f00   cmp.w   lr, #0
   120:  bf14ite ne
- 122:  f2af 0e7f   subwne  lr, pc, #127; 0x7f
- 126:  f2af 1e27   subweq  lr, pc, #295; 0x127
+ 122:  f2af 0e7e   subwne  lr, pc, #126; 0x7e
+ 126:  f2af 1e26   subweq  lr, pc, #294; 0x126
   12a:  47f0blx lr
   12c:  f1bc 0c01   subs.w  ip, ip, #1
   130:  f101 0120   add.w   r1, r1, #32

[...]

Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.

While I haven't looked at the source the LSB of a code pointer indicates 
whether the system is in arm mode or thumb mode. It looks like in the old 
binary is performing a mode switch while in the new binary is not.

___
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#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

[James Cowgill]

Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org

Hi,

I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz

It fails with SIGBUS when running the h264 tests.

> (gdb) bt 
> #0  0xf6456e12 in ff_h264_idct_add_neon () at 
> src/libavcodec/arm/h264idct_neon.S:24
> #1  0xf6456f3c in ff_h264_idct_add16_neon () at 
> src/libavcodec/arm/h264idct_neon.S:118
> #2  0xf659c88c in hl_decode_mb_idct_luma (p=, 
> dest_y=, linesize=, block_offset= out>, pixel_shift=0, transform_bypass=0, simple=1,
> mb_type=, sl=, h=) at 
> src/libavcodec/h264_mb.c:778
> #3  hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=) at 
> src/libavcodec/h264_mb_template.c:349
> #4  0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00, 
> sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
> #5  0xf65b3670 in decode_slice (avctx=, 
> arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
> #6  0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at 
> src/libavcodec/h264_slice.c:2728
> #7  0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "", 
> h=0xaab6ea00) at src/libavcodec/h264dec.c:715
> #8  h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70, 
> got_frame=0xaab38a2c, avpkt=) at src/libavcodec/h264dec.c:1016
> #9  0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at 
> src/libavcodec/pthread_frame.c:199
> #10 0xf61895e8 in start_thread () from 
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6

> (gdb) print $pc
> $1 = (void (*)()) 0xf6456e12 

> (gdb) disassemble
> Dump of assembler code for function ff_h264_idct_add_neon:
>0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
>0xf6456e14 <+4>: vmov.i16q15, #0 ; 0x
>0xf6456e18 <+8>: vswpd1, d2
>0xf6456e1c <+12>:vst1.16 {d30-d31}, [r1 :128]!

Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.

Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:

> --- h264idct_neon-binutils-2.28-5   2017-08-03 12:48:07.560036237 +
> +++ h264idct_neon-binutils-2.29-3   2017-08-03 12:47:43.666083113 +
> @@ -89,8 +89,8 @@
>   118:  f04f 0e00   movne.w lr, #0
>   11c:  f1be 0f00   cmp.w   lr, #0
>   120:  bf14ite ne
> - 122:  f2af 0e7f   subwne  lr, pc, #127; 0x7f
> - 126:  f2af 1e27   subweq  lr, pc, #295; 0x127
> + 122:  f2af 0e7e   subwne  lr, pc, #126; 0x7e
> + 126:  f2af 1e26   subweq  lr, pc, #294; 0x126
>   12a:  47f0blx lr
>   12c:  f1bc 0c01   subs.w  ip, ip, #1
>   130:  f101 0120   add.w   r1, r1, #32
[...]

Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.

Thanks,
James



signature.asc
Description: OpenPGP 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