Home > Allwinner H-Series, Debian, Hardware, Linux, Video > Accelerated 3D Graphics, Hardware Video Decoding, and Network Performance on Orange Pi One Board (Video)

Accelerated 3D Graphics, Hardware Video Decoding, and Network Performance on Orange Pi One Board (Video)

I’ve just written Getting Started Guide for Orange Pi One, a $10 development board based on Allwinner H3 quad core Cortex A7 processor, where I explain how to install and configure Armbian distribution on the board. As promised, I’ve also tested 3D graphics acceleration, and hardware video decoding, and also included some Ethernet benchmarks.

Orange Pi One Running Iceweasel, es2gears, and mpv - Click to Enlarge

Orange Pi One Running Iceweasel, es2gears, and mpv – Click to Enlarge

Since ARM Mali-400 GPU found in Allwinner H3 is only capable of OpenGL ES, as in most ARM SoCs, you can test 3D graphics acceleration by using es2gears (and not glxgears as I’ve seen some other do in the past):

The log shows the utility is using Linux-r3p0 Mali driver, and the gears are display at a high frame rate close to 300 fps. If I switch to full screen, the frame rate drops to about 43 fps, which should still be acceptable.

CedarX is the infamous closed source and GPL violating media library released by Allwinner, but the community has worked on an open source alternative dubbed Cedrus, which armbian is using. It has some limitations, but it did a good enough job with Big Buck Bunny 720p and 1080p H.264 videos using mpv to play from a USB flash drive:

Again the log clearly shows hardware video decoding is enabled, and you can see the actual results in the demo video below.

So while es2gears rendering window was very smooth, I found CPU usage to be very high, mostly due to Iceweasel, but even after exiting the web browser, I found it was still fairly high. You will also have noticed a massive lag when moving the browser window around. The system could however handle both es2gears and playing a 720p video at the same time. The 1080p video started with some frame drops, but overall played smoothly, so that’s a positive. Sadly H.265 reverts to software decoding, despite both Cedrus and Allwinner H3 supporting the new codec.

Finally, I tested the network performance of the 100m Ethernet interface using a full duplex transfer with iperf -t 60 -c server_ip -d command:

The download could basically fill the maximum bandwidth, but the upload was limited to 30 Mbps when both occur at the same time.

  1. sky770
    March 16th, 2016 at 21:00 | #1

    interesting.. Thanks!
    Keep up the good work!

  2. March 16th, 2016 at 21:21 | #2

    Awesome tutorial, worth to read.
    Is the upload speed through Ethernet is limited to 30 Mbps in every Allwinner H3 based SBC ? Or there is a glitch in Orange Pi One hardware design ? possibly to cut down the cost.

  3. tkaiser
    March 16th, 2016 at 21:43 | #3

    You get ~95 Mbits/sec in each direction individually with our default settings. When you switch to performance governor you get better results (current CPU clockspeed affects network throughput as with most other ‘tablet grade’ ARM SoCs). Then it looks like:

    But in every normal situation you max. out Fast Ethernet bandwidth. Don’t expect that any Armbian dev looks into this issue since it has no relevance (at least for us). The mainline Ethernet drivers have been updated yesterday evening and I let an Armbian test build create just 2 hours later (kernel 4.5), unfortunately still not ready for prime time but I would suspect it’s just a few days then we will also roll out Armbian images with mainline kernel.

  4. Nobody of Import
    March 16th, 2016 at 21:56 | #4

    It should be noted that iperf is not really a good litmus test for anything other than peak available on the link. It was written as a quick and dirty test for supercompute clusters to validate proper configuration of ultra-high speed links between nodes in a cluster and to help with the initial steps on diagnosing problems.

    The problem with using it solely to base judgement and belief on performance is that it’s blindingly simple in nature and doesn’t reflect the reality of things like database, FTP, etc. servers running on these devices. iperf can saturate a link (is designed to be simple enough for most devices to be able to do so), but real applications will not match expectations out of iperf.

  5. Nobody of Import
    March 16th, 2016 at 22:03 | #5


    The limitation isn’t the hardware or the driver. As I said in my previous post, iperf’s not a good judge of speed. Wasn’t designed for that and I wish people would quit using it for that, claiming “ethernet performance” when they post iperf or similar results. You’re measuring the absolute theoretical peak of the device with it and nothing else.

    Now, it should be observed that *most* of the “tablet grade” ARM SoC’s can’t handle more than a bit above 100Mbit bi-directionally, because the CPU can’t drive it much faster than that. Back when they started rolling out 1Gbit on pretty much every PC, it was a because they could reason, not because the machine needed or could USE it. It’s no different on this story. I keep cringing when people point to boards in this class that sport GigE and claim it’s “better”- which is more “maybe” than anything else. Most cases, no, you’re not even close to being anything other than hoodwinked as evidenced by this discrepancy you’ve noted here. You’re being marketed to on those cases. You’re better off with the OrangePi or the RPi3B (If you can lay hands on it…) than many of the boards in this class…because the GigE buys you nothing (as does the “native SATA”) The machine can’t take advantage of it.

  6. March 16th, 2016 at 22:05 | #6

    Excellent work @cnxsoft! Do we know if the Pi Camera is compatible with this board?

  7. tkaiser
    March 16th, 2016 at 22:28 | #7

    @Nobody of Import
    Agreed, iperf is clearly the wrong tool to measure ‘real world’ network performance. But that’s also true for nearly all other ‘common’ tools the average user (and unfortunately also ‘Pros’) uses, takes the results for granted and decides then based on ‘numbers without meaning’.

    Regarding CPU usage you’re fortunately wrong: http://kaiser-edv.de/tmp/sItUhs/ (~20% max when dealing with Fast Ethernet on OPi PC, on the One it might be 23% then since we don’t allow it to be clocked that high as PC). Since adjusting CPU clockspeeds influences the performance it must be a simple tweak somewhere so get full speed in both directions (but as already written: none of us devs cares about 3.4.x that much and it’s Fast Ethernet anyway).

    Regarding GbE (and also SATA) and tablet grade SoCs : http://linux-sunxi.org/Sunxi_devices_as_NAS (with appropriate settings and mainline kernel old boring SoCs like A20 can really shine — at least for the price. And what most if not all benchmarks don’t cover: Random I/O is way better with SATA unless you can benefit from UASP)

  8. cortex-a72
    March 16th, 2016 at 22:39 | #8

    so, “hardware acceleration”… which still loads the cpu a lot (apart of loading the vpu 100% of course), overheating, melting down, whith lags, jerkings and overall wasting of all expectations. no, this is not about this particular device, this is an observation on overall hardware “acceleration” rush. (to be honest, I have never ever seen a linux machine of any architecture, not loading cpu high, so it’s maybe not the fail of the “acceleration” itself, but again, did anybody a comparison of how power consumption relates when a board does “software” decoding, thus on the cpu and “hardware” decoding, thus with those “magic” vpu’s? because many people seem believe in this vpu “advantages” so blindly, so maybe someone did an actual analyzis. intereststing to know. though I understand, these tiny SoC’s arm cores might not take it at all, at least on linux) btw, not for flame, just for contrast, my old P4, PC does software decoding of the 1K h264 on Windows without any “vpu” and you know what – the load is not higher than ~4% (average load is even lesser, ~1-2%). So maybe these are not relevant expectations?

  9. tkaiser
    March 16th, 2016 at 23:04 | #9

    I did not really test but at least looked into it. Just playing a HEVC movie (jellyfish-90-mbps-hd-hevc.mkv (324MB in size, 90 Mbps bitrate, 1920×1080, HEVC, Main profile, Level 5.0, Tier: high) HW accelerated with H3 means a few degrees more and 0.8W more in the first part of the movie and ~0.3/0.4W the last seconds (less motion I would suspect). According to RPi forums this is something you need already overclocking and a heatsink on RPi 3 since there HEVC decoding isn’t HW accelerated:


    Disclaimer: I’ve no idea why Jean-Luc experienced high CPU utilisation in this situation and I’m a video NOOB. We just packaged what members of the great linux-sunxi community (reverse) engineered and are aware that there is still a lot of room for improvements in this area. But most of us at Armbian lack both skills and interest regarding ‘GUI stuff’

  10. pmos69
    March 17th, 2016 at 03:41 | #10

    CPU usage on OrangePI PC with jernej’s openelec port decoding H265 1080p (cedarx-h265):
    Mem: 440556K used, 383844K free, 6060K shrd, 40648K buff, 195696K cached
    CPU0: 1.4% usr 0.8% sys 0.0% nic 96.8% idle 0.0% io 0.0% irq 0.8% sirq
    CPU1: 1.4% usr 0.6% sys 0.0% nic 97.9% idle 0.0% io 0.0% irq 0.0% sirq
    CPU2: 2.2% usr 0.6% sys 0.0% nic 96.8% idle 0.0% io 0.0% irq 0.2% sirq
    CPU3: 0.6% usr 3.6% sys 1.2% nic 94.2% idle 0.0% io 0.0% irq 0.2% sirq
    Load average: 3.23 3.31 2.37 2/114 2207
    594 589 root S 582m 71.9 2 3.4 /usr/lib/kodi/kodi.bin –standalone -fs –lircdev /run/lirc/lircd

  11. cortex-a72
    March 17th, 2016 at 04:42 | #11

    ok, this is a much better picture, totally different of what is seen in the overview above, but this is CedarX working, right? The Cpu isn’t totally offloaded still, but the picture is way better, I agree. But we all know, not only CPU part consumes power, all modules do! And I strongly doubt VPU is “lightweight” in this. How about power consumption during its work? How do you think? Is it more or less power hungry than the cpu (on the same work)? Didn’t you measure it? SoC temperature? Is it really “offloaded”? I heard about other board when vpu is working, the SoC gets melt down. I mean, what benefits of using a vpu are if it still draws alot power, heats the SoC (maybe even more than cpu)? The only reason could be the CPU which isn’t capable to handle the task by itself. Isn’t it really? This question isn’t clear, because it looks like we cannot check its full potential with partially functioning mediocre current video decoding software on the linux. After all you saw the video in the overview. That state of support is not usable.

  12. memeka
    March 17th, 2016 at 08:52 | #12

    r3p0 wow that’s old
    but having cedarx vdpau working is cool
    @cnxsoft – the window moving slowly is from the window manager – you can try “sudo apt-get install metacity”, then run in a terminal “metacity –replace” and you’ll get faster windows moving around.

  13. March 17th, 2016 at 09:17 | #13

    @Nobody of Import
    Usually Gigabit Ethernet is about 1.5 to 2 times faster than Fast Ethernet for copying a large file from a SAMBA share to the internal storage in Android TV boxes. If instead I copy files to a USB drive, I can get up to around 25 MB/s transfer rates with GbE + USB 2.0, or about 3 times faster than Fast Ethernet (~8MB/s in best case).

  14. Harley
    March 18th, 2016 at 14:07 | #14

    I would still never recommend Allwinner for a media player that will be decoding video. At least not until Allwinner gets their act together and start make libraires compatible with GPL.

  15. Douglas G. Oechsler
    March 1st, 2017 at 03:38 | #15

    How are you?

    I have opi pc plus with armbian ubuntu xenial. I want to use it as pc station / thin client. I need to run youtube videos. I tried by firefox and chromium but it rund without good quality. I tried to install kodi but it does not run, give only errors. Please! How do you make run vídeos from opi? Thank you atrenton and help.

  16. March 1st, 2017 at 09:19 | #16

    @Douglas G. Oechsler
    Playing videos in a web browser will be a struggle.
    Kodi might have worked, but Android might be a good option.
    To play YouTube videos in Linux, you may
    1. Download the videos with a script before playing them: http://www.cnx-software.com/2016/09/20/how-to-download-youtube-4k-videos-with-youtube-dl-script/
    2. Try to play them from SMPlayer. See demo with Orange Pi mini 2 board @ http://www.cnx-software.com/2015/09/02/debian-8-on-orange-pi-mini-2-board-video/

  1. No trackbacks yet.