[FFmpeg-devel] [PATCH 0/9] DCA (DTS) decoder optimisations for ARMv6

Ben Avison bavison at riscosopen.org
Thu Jul 18 21:59:53 CEST 2013

Hi Michael,

On Wed, 17 Jul 2013 14:57:37 +0100, Michael Niedermayer wrote:
> With this patch i get:
[a series of build failures]

In case you haven't noticed, Martin Storsjö has kindly taken it upon
himself to fix the issues with building for Thumb, and has posted a
series of updated patches over on the libav mailing list. Rather than
duplicate the effort, I'd suggest having a go with his patches instead.

>> Well, this is strange. Those both pass for me. The ones I'm having
>> trouble with are
>> fate-aac-al07_96
>> fate-aac-al15_44
>> fate-aac-aref-encode
>> fate-aac-ln-encode
> they pass with qemu

At the moment, this is looking like it's mostly likely due to a bug in
the kernel I'm running, so it's not worth worrying about this further.

>> * perhaps qemu doesn't emulate short vectors?
>> I have put together a quick test program below to see if short vectors
>> are working. I would appreciate it if you could give it a quick try for
>> me. It prints "Success" on my physical ARM11.
> segfaults:

Looks like an ARM/Thumb interworking issue to me: CPSR indicates it's in
Thumb mode and the backtrace address isn't 4-byte aligned, but the
disassembly is clearly of ARM code ("bx lr" would have been a 16-bit
instruction in Thumb mode, for a start). Try sticking a ".thumb" directive
at the top of the assembly source file. (I'm a little surprised that
GAS doesn't change the default instruction set to match the way GCC is
configured, but I guess it is the way it is.)

Having said that, Martin reckons he's found the reason for the fate test
failures you experienced as well, so it's now mainly of academic
interest whether qemu supports short vectors or not. :)


More information about the ffmpeg-devel mailing list