Thanks to a very responsive development team we now have not only ARM32 but also ARM64 builds for Linux and now Android too. For those of you wondering why this is desirable, this is because both they tend to do better than Intel Core ix systems in terms of both performance per watt and performance per dollar. ARM SOC boards - the Raspberry Pi 3 being the most famous example - are typically extremely cheap, starting at around $40, usually only use a few Watts of power, are are often fan-free/silent. This may be appealing to a many people.
I’ve been testing them across multiple systems from the $46 ODroid-C2 to the $240 HiKey 960, and given some limitations I’m impressed. First, some warnings:
-
CPU performance: ARM-based systems are almost always underpowered in terms of raw CPU performance compared with Intel systems except for Atom-based ones. The most capable tend to be comparable to Celeron systems, although they are rapidly catching up, thanks to excellent multi-core scalability. This means that commercial scanning and transcoding will be considerably slower than on most intel-based systems unless you have one of the rare system with integrated hardware transcoding.
-
Drive access: Most ARM SOCs have limited drive options: either eMMC or micro-SD onboard storage, or USB-2 external drives. eMMC or Micro-SD at 512 GByte is expensive. USB-2 is slow, but it seems to be sufficient for TV recording, and so is a reasonable solution as long as you’re not trying to record from >>4 tuners. Exceptions to this rule are coming onto the market, but they’re mostly at the higher end of the market (>~$80).
-
Network access: An alternative to local drive access is to use network storage. However, many ARM SOCs lack Gigabit ethernet, limiting network drive access speeds, which could impact both NAS performance and the ability to write whilst recording multiple streams from HDHomeRun tuners. Even over Gigabit ethernet, throughput is often bad, especially to NAS system, and can be difficult to get working at speeds necessary to support many parallel streams. I recommend systems with Gigabit networking as a minimum, but you will be able to have limited functionality (maximum number of simultaneous streams) with slower connections.
-
Many ARM SOCs have extremely limited amounts of RAM, typically 0.5-4 GByte, which can be limiting for working with videos. I would personally avoid anything with <2 GByte, as from experience I know that this causes a bottleneck for x264 transcoding (real-time or other) of 1080i, unless you tweak it a lot. That being said, you might be able to work with 1 GByte which is much more common.
That being said, part of the strength of the Channels DVR system is that transcoding is non-essential, so i’ve been testing out the latest build on a few ARM boards running Ubuntu 16.04. These systems are similar to the Raspberry Pi 3, but with faster processors, 2-4 GB rather than 1 GB RAM and Gbit rather than 100 Mbit ethernet.
All of my comments about performance will be based on the experience of only having run this before on a 2011 Mac Mini with dual core-i5 processors.
Observations of performance on ARM 64-bit boards
-
The ones I have tested all work! This applies to the ODroid C2, both hacked and unhacked NVidia Shield TV and the Firefly RK3399. Setup is much the same as on any other linux or mac-based system. Recording, the most important thing IMO, has so far run without major issues. Note, however, that most of these systems are “cutting edge”, and so typically require a little more work than a PC.
-
The Apple TV interface responsiveness is comparable to when I was running the server on my Mac.
-
Live streaming through the web interface simply doesn’t work on the systems tested, even at 240p, at least if your source is in HD. The system is too under-powered. If hardware transcoding could be implemented in FFMPEG, then it might be possible, but even those systems I tried that on paper had hardware transcoding, sometimes implementable through the difficult-to-use gstreamer software, did not have the software support for it. If you want to transcode from mpeg-2 streams, my recommendation is to do so overnight with an x264-based transcoder (e.g. Handbrake, ffmpeg), using the veryfast encoder preset, and direct stream with something like Plex. I have provided a script for Mac and Linux users that should work for this: https://community.getchannels.com/t/linux-mac-script-for-transcoding-and-adding-to-plex/912/6. The script does not (currently) work with Android systems.
-
Watching a show while you are recording to a NAS (whether NFS, AFP or SMB) is problematic for some systems; It just didn’t seem to get going at all on my ODroid C2 system with a 1st Gen WD My Cloud Mirror. This does not seem to apply to watching a pre-recorded show, and certainly not to watching a stream directly (which I think still bi-passes the server). I suspect this is because of limitations of NAS reading and writing streams in parallel. I tried tweaking my NAS performance, and even though with a single-stream write the bandwidth should have been sufficient (about 20 MBytes/sec) I couldn’t get it to work. Your mileage may vary here, and certainly benchmarking your network drive speeds is critical. Just bear in mind that these RAM-limited systems are not so good at buffering if your bandwidth is erratic.
-
The performance of a USB-2 connected drive (many do now have USB-3), despite being clearly way slower than state-of-the-art, is far more compelling. Even my very basic ODroid C2 was reading and writing at around 35 MBytes/sec, and doing so pretty consistently somewhat independently of how many streams are being utilized; At no time did my net throughput drop below 20 MBytes/sec, which is ~8x faster than the maximum bandwidth of an ATSC HD broadcast (19.4 Mbits/sec, or 2.425 MBytes/sec). I was more than once able to record 4 streams in parallel and watch one of them from the recording all at the same time, and the system remained responsive, although I don’t think I’d have liked to push it any further. As a result, I would say that high speed drive access via SATA or USB-3 is not the top priority for this purpose alone, although if you’re using the system for other purposes you may wish to consider it.
-
Every once in a while a show gets glitchy on the ODroid C2 system, most of the time on ABC, and I’m not sure if this is a software, hardware or local transmission/antenna issue; I’ll report back once I know more, but so far it hasn’t happened on the Firefly RK3399, but that may be due to lack of time using the system.
-
The Gigabit network speed, on the ODroid C2 at least, is more of a bottleneck than the USB read/write speeds, but still sufficient. In tests, I found that it tended to hover in the 16-24 MBytes/sec range, depending on a number of factors, which is disappointing but sufficient. The ODroid-C2 ethernet and USB interfaces appear to be shared, much like it is on the Raspberry Pi, which may provide the explanation; Certainly transfer speeds are well below Gigabit, but also far above 100 Mbps (12.5 MBytes/sec). In any case, you might be pushing your luck if you want to deal with any more than say 4-5 streams at once. Ethernet speeds on the Firefly RK3399 and Nvidia Shield were fine, both for wifi and wired connections, although I would not recommend wifi with HDHomeRun tuners unless you have a fast, little-utilized 802.11ac system and really know what you’re doing.
-
Commercial skipping on the ODroid C2 is far slower than on an Intel system, maybe 1-3x better than realtime. A 1-hr 1080i show took ~30 minutes for me, although there was a lot more going on in that drive. On the Firefly RK3399 with a USB-3 drive it’s much faster; just a few minutes. As a result, you might expect a significant delay after a show has recorded before those commercial marks are in there, and if you use the comskip results for transcoding you might wish to add a significant delay. This appears to be because the implemented version of comskip is only ever running on one core, which is never a good thing on an ARM system which relies on using multiple (typically 4-8) cores for performance. That being said, if, like me, you rarely watch TV on the same night as it’s recorded it is more than ample to avoid a backlog.
Recommendations for people wanting to start with ARM SOCs
-
Do not expect these to work out of the box as you want. Anticipate having to put in some time to getting them to work, especially if you want to do more than basic play + stream. Also, despite some being advertised as having hardware transcoding capabilities, these are often absent from being supported in reality within Linux/Android, and are specifically unsupported by Channels DVR.
-
Avoid systems with <2 Gbytes, especially if you want to run Plex or Kodi as well. [I’ve recently discovered that using the veryfast encoder preset reduces the memory footprint, and so 1 GByte may be sufficient, but you might get bottlenecks.]
-
Avoid slower systems with older cores. My ODroid C2 system uses 4x Cortex A53 cores at 1.5 GHz (although I have found it useful to under clock to 1.3GHz with my transcoding script), which I’d say is barely sufficient; Higher performance A15 (32-bit), A17 (32-bit), A57 (64-bit), A72 (64-bit) and A73 (64-bit) cores are preferable. The Firefly RK3399, for instance, has 2 A72s and 4 A53s, which is far better. You can get some estimate of the relative performance of other systems here: http://www.cnx-software.com/2015/04/09/relative-performance-of-arm-cortex-a-32-bit-and-64-bit-cores/
-
The web transcoder, or indeed any kind of live transcoder, will almost certainly not work, even with external solutions (e.g. Plex or Kodi), unless you have hardware transcoding that is supported (on ARM systems this is only the Nvidia Shield running Android right now). This is likely to remain the case until ARM GPU transcoding support is more unified under Linux, although some of the newest 8-core systems might stand a chance in the near future. Transcoding over night and then watching them DirectStreamed (again with e.g. Plex) is a better solution for the time being.
-
For the OS + basic software + Channels DVR, I’ve found that a 16 GB eMMC (or SD card) is sufficient as long as you store recordings externally. If you’re running something like Plex too, and have a large database of recordings, I’d consider upgrading to 32 GBytes or putting the database on an external drive, as it can take up a fair amount of space. Again, you’ll need to store the recordings elsewhere, in my case on an external USB-3 4 TB drive. If you’re running into problems running Plex on such a system, turn off “generate video preview thumbnails”, “generate chapter thumbnails”.
-
As far as specific hardware suggestions are concerned, together with VERY ROUGH estimates of capability to software transcode relative to the Raspberry Pi 3 (marked as e.g. 3.0X, and for reference typical Intel Core-ix based systems come it at around 2.5-8.0X):
-
(i) Raspberry Pi produces the most popular and well known systems, including the Raspberry Pi 3 (1x). It is adequate for many users, but due to the limited 100 Mbits/sec ethernet and only USB-2 connectivity, it will almost certainly give issues for those who do not need to record/play 3+ or 4+ streams at the same time. You will probably run into issues playing back shows while recording them. In theory it has hardware transcoding to h.264 implemented, but in practice this is unsupported by Channels DVR, and most users report issues with HD streams (both quality and reliability).
-
(ii) ODroid produces some good 2 GB systems. I found the fanless $46 ODroid-C2 (1.25X), to be adequate for my purposes. It also has a similar form factor to the Raspberry Pi 3, so should fit well into a Pi case. You may need to underclock it to e.g. 1.3 GHz to use it fanless (the default), depending on your ambient conditions and whether you’re transcoding locally or not. For those of you that have other software requirements, the $59 ODroid-XU4 (3X) 32-bit board might be a better system given its better throughout (USB-3, better ethernet performance), better software support (32-bit ARM has a larger community than 64-bit) and faster processor speed, including single-core (~2.5x faster comskip compared with C2). It does have a fan, which is not silent, but they now sell fanless alternatives. http://ameridroid.com/ is a good US supplier for both. Finally, the forthcoming ODroid N1, discussed below under RK3399-based systems, looks like it will provide an even greater boost in performance and capability.
-
(iii) Rockchip RK3288-based systems may be slower (2.2X) on paper than the ODroid-XU4, but some (e.g. the Firefly RK3288 Reload ) also come with a SATA port makes it attractive for file I/O, although those are generally not cheap (>$100). A cheaper (~$45) variant is the Asus Tinker Board (2.2X), which has good specs on paper in terms of pure performance per dollar or watt, and does have Gbit ethernet, but lacks SATA or USB-3 support. Despite being 32-bit the should outperform some more common A53 chipsets. As with all Rockchip-based solution, drivers, including graphics, are open source. Gstreamer now supports hardware encoding, although compiling it to work can be challenging unless you have a cutting edge Linux distribution. Unfortunately hardware encoding is still not possible with FFMPEG, and so current solutions for Channels DVR do not presently work for live transcoding.
-
(iv) Rockchip RK3399-based systems are becoming increasingly common, and offer a much wider range of features. Personally I am using a Firefly RK3399 (3.2X) as my main system. It has a typical price of close to $200 ($150 at the moment), which might not be worth it for some, but it does come as part of a full devkit with basic case, cables, PSU, etc… The addition of M2, USB-C and USB-3 ports is particularly compelling, and for an extra $16 you can get an M2 to 2x SATA adapter that makes adding hard drives really easy. The single-core performance is among the best available for ARM systems (estimated 4x faster comskip than the C2). The one downside is the fan, which is far from silent, and does not have the capability to respond to CPU temperatures, meaning that it’s on full power all the time. I have experimented with passive heatsinks (both a regular one, and simply unplugging the power from the stock cooler), and the performance hit for intensive tasks is around 20-25%, with CPU temperatures peaking at around 74 C (acceptable for that chipset). I then tried mounting a much quieter fan on a makeshift case, pointing it at the cooler, and that did a really nice job. Several other manufacturers are starting to bring RK3399 systems to market, and I expect the cost and availability to plummet by the middle of the year. Keep an eye in particular on the ODroid N1 with 4GB RAM and 2x SATA ports at $110, and the Pine64 RockPro64 at 2-4 GM RAM and a PCIe x4 port at $59-$79. The growth of these systems significantly increases the probability that hardware encoding on ffmpeg might soon become a reality, and with some (a lot?) of effort it is possible outside of Channels DVR with gstreamer.
-
(v) Nvidia has been producing the fastest ARM-based boards for a while, which incorporate versions of their graphics cards. All versions of the Nvidia Shield TV (3.75x) with an attached USB-3 hard drive work out of the box now, and is recommended if you do not need to do software transcoding; It also integrates nicely with Plex. If you want to use Linux, then you’ll need the expensive ($600) Jetson TX1 Tegra (also 3.75X) development board or to hack the Nvidia Shield TV (instructions online, but it may void your warranty), and neither offer hardware transcoding of video. Technically there is a version of gstreamer (not ffmpeg, which is used by Channels DVR) on Linux4Tegra that should be able to handle transcoding, but not via FFMPEG which is what Channels DVR uses, and so it would require a fair bit of work to get that running. Right now I do not recommend it.
-
(vi) LeMaker produces some good quality boards, and are also signed up to the 96boards standardization project, which may improve cross-board implementations. In particular, the HiKey 960 shows a lot of potential and on paper at least should be pretty fast, with 3GB RAM, USB-3, and 8 cores - 4x A74 at 2.4 GHz and 4x A53 at 1.8 GHz - which taken together should give Intel Core i3/i5-like performance. At the moment only Android is supported, although it is mainline, which means it should work out of the box without requiring specially compiled versions. Early reports are that the Android kernel (pre-installed) is very non-optimized, and it is falling way short of performance expectations, but given that it only came out this month that’s not completely surprising; Some users have reported significant (if still imperfect) performance gains from flashing with a more recent version. Unfortunately the lack of advancement on Linux support means that I cannot recommend this board yet, and the price ($240) is somewhat prohibitive.
I’ll try to answer any queries people have. It’s the least I can do, given how responsive the Channels DVR devs have been!
-Karl