2

I'm using Mencoder on a Raspberry Pi B (1st gen) with modernized raspbian (i.e. the new builds that work on RP2) to make timelapse films. In general it works well, but i wanted to add x264 codec support. I compiled it following these instructions:

https://www.mplayerhq.hu/MPlayer/DOCS/HTML/en/codec-installation.html

It compiled successfully with 'sudo ./configure', but the resulting binary appears to be non-optimal. GCC showed this at compile time (sample of the GCC output):

gcc -Wshadow -O3 -ffast-math  -Wall -I. -I. -std=gnu99 -mcpu=cortex-a8 -mfpu=neon -fomit-frame-pointer -fno-tree-vectorize   -c -o encoder/lookahead.o encoder/lookahead.c

The resulting code "runs" with beautiful results, but VERY slowly:

Pos:  32.4s    971f (46%)  **0.02fps** Trem: 1397min  34mb  A-V:0.000 [4230:0]]

Last I checked, the Raspberry Pi 1st generation doesn't support NEON or cortex-a8. So i found some flags optimized for it's older ArmV6 CPU:

sudo ./configure --extra-cflags="-march=armv6zk -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"

./configure yields no warnings, but this will not compile/make correctly. Numerous .o files are created with the new flags, but it fails on (insert file) with the error:

    gcc -Wshadow -O3 -ffast-math  -Wall -I. -I. -march=armv6zk -mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -std=gnu99 -fomit-frame-pointer -fno-tree-vectorize   -c -o encoder/slicetype-cl.o encoder/slicetype-cl.c
gcc -I. -I. -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/cpu-a.o common/arm/cpu-a.S
gcc -I. -I. -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/pixel-a.o common/arm/pixel-a.S
gcc -I. -I. -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/mc-a.o common/arm/mc-a.S
gcc -I. -I. -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/dct-a.o common/arm/dct-a.S
gcc -I. -I. -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/quant-a.o common/arm/quant-a.S
common/arm/quant-a.S: Assembler messages:
common/arm/quant-a.S:362: Error: selected processor does not support ARM mode `rbit r1,r1'
common/arm/quant-a.S:363: Error: selected processor does not support ARM mode `rbit r1,r1'
Makefile:217: recipe for target 'common/arm/quant-a.o' failed
make: *** [common/arm/quant-a.o] Error 1

Any idea's? I wish I could live with the sub-optimal code, but it runs at a net deficit (needs to run once every 24 hours, but takes ~35 hours to run the x264 compression). Previously I was using mencoder's default lavc MPEG4 option; it's A LOT FASTER.

Should I cross-compile instead? I don't think i'm running out of memory on the Pi during compilation.

Thank you.

5
  • 2
    "i found some flags optimized for it's older ArmV6 CPU" -> Don't expect stuff like this to make an overwhelming (or generally any) difference even if you do figure out which switch is the problem. If you have a specific reason for using them, great, but if it is just "I read this would make my car super fast" no, it will not. Your existing code is not "sub optimal", it's the pi itself. It is not a fast car, period. Put another way, you might as well accept what you have. Cross-compiling will not improve performance either.
    – goldilocks ♦
    Jan 3, 2016 at 15:40
  • 1
    Also note that most of those flags are part of the default for the compiler on the system anyway.
    – goldilocks ♦
    Jan 3, 2016 at 15:44
  • So, it's okay to use this code with 'cortex-a8' and 'neon'? It's performance is alarmingly worse than the binaries that shipped with mencoder (i.e. the lavc MPEG4 binary encodes at ~5fps, not 0.02fps like my compiled code). It must be running in a degenerate mode (like soft float integer calculations or similar). I might start looking at the hardware accelerated x.264 encoder (though it's results are worse than software encode).
    – etronz
    Jan 3, 2016 at 15:58
  • Hmmm -- did you try just compiling it on the ARMv6 pi with no architecture flags? I guess it is odd that the format alone would make this much difference, but I'm not an expert on that kind of thing. If mencoder shipped with a distro, e.g., raspbian, there almost certainly is a way to find out what flags were used to compile it. You could ask about that WRT Debian packaging over on Unix & Linux. If not, you could try contacting whoever did compile it, it is a simple, straightforward question.
    – goldilocks ♦
    Jan 3, 2016 at 16:05
  • i compiled with no flags. It defaulted to 'cortex-a8' and 'neon' at run time. I cannot believe the code works at all on this armv6. I'm going to keep looking into this. If i find a solution, i'll post back.
    – etronz
    Jan 3, 2016 at 20:40

1 Answer 1

Reset to default
1

I was able to compile with:

./configure --disable-asm --extra-cflags="-march=armv6 -mfloat-abi=hard -mfpu=vfp" --extra-ldflags="-march=armv6 -mfloat-abi=hard -mfpu=vfp"

--disable-asm allowed GCC to build with armv6 architecture specified.

The resulting GCC compiled code is about 10% slower than the default "-mcpu=cortex-a8 -mfpu=neon" flags on this Raspberry Pi B. Two pass x.264 encodes are still running at 0.02FPS (about 35 hours for ~100 second two pass 8Mbps 720p videos).

I'm going to play around with the encode setting and try to make this faster. As long as it runs within 24 hours, I'll be okay.

I might be looking at OpenMAX hardware accelerated H.264 encoding after all...

4
  • Yea.. It seems like you are using the unforked x264 repository (sorry that link to tutorial wont open on my side) - You don't want to be using that, it is completely out of date, slow and rubbish. You want to use the Pi specific ones
    – Piotr Kula
    Jan 13, 2016 at 9:16
  • Yes, it's I pulled source from VideoLAN and compiled from there. There are Pi specific builds? Where can I find them?
    – etronz
    Jan 14, 2016 at 15:38
  • I've been playing around with encoding settings and managed to get a high quality profile down to 20 hours for a ~180 second 720p video. The encoding scripts will now run on time and it slowly working through the backlog. I still haven't found an optimized x.264 binary for the Raspberry Pi. This is still better than using the lousy GPU hardware encoder. Saving bandwidth is paramount for my application and x.264 in software is light years ahead. I'm actually appalled at how poor the resulting videos are on the GPU encoder.
    – etronz
    Jan 21, 2016 at 5:17
  • I am having similar problems with codecs optimized using thumb instruction set. How do you get Arm6 to compile on the pi b when it is Arm7?
    – PaulF8080
    Jan 30, 2017 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.