$50 Odroid-C4 Raspberry Pi 4 Competitor Combines Amlogic S905X3 SoC with 4GB RAM
cnx-software.com
cnx-software.com
(Had those interfaces on two laptops and I sighed deeply when I saw that the RPi 4 had them as well)
But, I dont have one to test - it certainly might ship with a weird hacked up bootloader or something. I do have a board based on an earlier generation Amlogic SoC that I'm quite happy with. Worked well out of the box and has continued to do so.
The raspberry pi was that way regarding power consumption in the beginning, but it uses way too much power these days. It also has an infamously slow and unreliable sdcard interface.
Still no ARM board with a decently powerful CPU, SATA3, NVME, PCI-E x16, USB3.2, and DDR4 slots.
It looks like ARM boards are pretty much the same, unless you want them for a pretty niche application.
Also, software support is not quite the best.
Or if Apple made an A13 SBC. They'd make a killing.
The CPU would be cheaper than x86 but not dirt-cheap. It should be reasonably fast to make sense for sata3 or nvme. This implies fast RAM, too.
If anything, the economy of scale won't be in favor of this board either, unless it's produced in millions.
It would be a matter of making a proper breakout board. It could be a hobbyist project, like so many available. Order the board yourself and solder everything yourself.
But nobody has bothered. I do wonder why.
My intuition is that everybody is waiting for a friendly RISC-V SoC to do this with. That is, that nobody actually wants to support the ARM ecosystem. E.g. I used to like ARM when it was an UK-based company. This changed as it got bought, and I do even actively dislike them ever since their "get the facts" campaign against RISC-V.
Ampere eMag would me more suited as an ARM workstation.
So far I had no issues with DSLRKIT's third-party hats, though!
Or is it an external binary that, for example, Kodi is using to decode?
In practice, these cheap boards will have a cheap eMMC soldered in that can't do these fancy things anyways. It's not going to be same quality chip like in flagship phones.
Once that cheap eMMC fails, the device is bricked.
Edit: SD card standards still can't go past 1 GB/s, max 985 MB/s. Either way, plenty for cheap SBCs.
https://en.m.wikipedia.org/wiki/SD_card
SD Express can do up to 985 MB/s.
SD UHS-II @300MB/s would be plenty for most SBCs.
While it would technically be correct, no one says new USB standard X is USB in name only.
Perhaps every data transfer interface standard eventually adopts a PCI-e lane. :-)
https://www.hardkernel.com/shop/odroid-c4/
They sell their eMMC chips here
I'm not sure you can make that "assumption" safely - plenty of SD cards have been bricked/trashed that way.
Of course wouldn't say no to M.2 slot (or similar) either. :-)
UHS-3 doubles the LVDS speed, and SD Express turned them into a PCIe lane. I haven’t kept up to see what MMC standards have been added lately, if any, but my impression is that it has been stagnant for a while.
Q: The SD-card speed increase is very welcome! Was an eMMC or M.2 slot considered?
A: We don't think there's a compelling advantage to socketed eMMC over SD. M.2 would have been fun, but we didn't like the form factor considerations, and had no spare PCIe lanes. I think USB 3.0 SSDs are the way to go for high-performance storage.
https://www.tomshardware.com/reviews/raspberry-pi-eben-upton...
Something that people would buy over the pi 4 will have to be a later generation A7X cpu without being more than double the price.
The better the CPU, the closer it comes to a lightweight desktop replacement, child computer, TV computer, router replacement etc. The pi 4 is already getting into that territory.
It might be my personal ignorance, but I just don't see why you couldn't take any of the more recent SoCs and throw at least 8GB on there? Do some of these SoC vendors limit the address space or something..?
Right now this model is a nuanced alternative to the Rpi4B; a model with more RAM would be a new segment in the market unlocking new possibilities.
The power efficiency is certainly competitive. Very competitive.
Raspberry Pi has a lot of justifying to do, regarding its much elevated power consumption, as the benchmarks do elucidate it actually doesn't have the performance to show fort it.
The A55 is claimed to be 15% more power efficient than the A53 while the A72 is 3-4 times as fast.
The source for Odroid power consumption is the specs mentioned in the article we're discussing.
You can check Raspberry Pi's consumption values from this table: https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications
As for performance benchmarks, the one I've seen is here: https://forum.odroid.com/viewtopic.php?f=29&t=38555
I expect more will pop up in due time.
I could use this to re-encode my video collection without having to have my main pc running for days/weeks.
Because of that, any hardware encoder needs to be tested thoroughly before you start encoding on it. It could be awesome, or you might not care about the larger filesizes than CPU, but you need to do your research. However, at $50, what do you have to lose? I'm just saying the odds of this board's ARM CPU being better than NVIDIA's not-great encoder is slim.
The only other thing I'd point out is that Graphics Drivers for ARM are a very, very mixed bag. Just because it supports H.265/H.264 encode does not mean the software support is there. I remember a few years ago when the first Chinese Pi clones started coming to market. They bragged about how the hardware supported H.264 4K Decode - but didn't mention that the drivers to support hardware acceleration of even basic GUI functions weren't there. Again, do your research, but $50 is probably a good experiment.
h264 is obsolete and h265 is a poor choice anyway. I would wait for AV1 encoding acceleration.
I think there's a widely-held misconception that the codec is the defining characteristic for video compression performance, that the codec is like a step-by-step procedure that all the encoders and decoders implement, so the choice of codec is the most important choice and different codecs are better or worse than others.
This mostly isn't the case.
You can think of a codec as something more like HTML + CSS + JS: there are some standards that define what your program can write and how it should be interpreted by other programs that read it. For a particular end-goal, there are many ways you could go about it. For example given a mock from a designer for a static webpage, you could produce a working copy by writing it up with clean HTML and CSS, with dirty HTML and CSS or you could just make a HTML page with a single <img> element. All of these could produce the same result but they go about it in vastly different ways that perform very differently.
The same is true of video codecs. Different encoders, given similar parameters and the same inputs, can produce vastly different results, with vastly different performance characteristics. This is especially true of encoders with odd constraints, like hardware encoders, which are usually forced to do things very differently due to not having the same amount working memory, being power-constrained (especially on phones and SBCs) or not having enough space on the physical silicon to implement certain approaches.
You can see benchmarks for some modern HEVC and AV1 encoders from MSU [0]. To see how different things can get, have a look at the 4K chart [1] and switch the "Plot Type" to "Speed/Quality". You can see that on one end, the Bytedance V265 encoder gives a 20% bitrate saving relative to x264 while taking half the time. On the other hand, the x265 encoder only gives a 13% bitrate saving despite taking 28% longer than x264. This is despite both V265 and x265 encoding the same codec.
As for hardware encoders, reliable benchmarks are usually sparse but in general, there are two classes:
- The kind used in embedded devices (phones, cameras, SBCs etc.) - these are usually built as accelerators so that the device's low-power CPU doesn't have to perform the computationally-intensive (and therefore energy/thermal-intensive) task of encoding video. They're usually built to handle realtime video, maybe slow-motion video and in terms of compression, they're not great.
- The kind used in less power-constrained environments (e.g. as part of a dedicated PCI-e video encoder card used in a video workstation, or the kind added to a GPU or CPU) - these are also built as accelerators but they're no longer anywhere near as constrained by thermal and energy considerations. They're usually not able to reach the same kind of compression as a software encoder due to some techniques just being entirely out of the question but they're able to process video very very fast. NVIDIA's NVENC encoder is the best that I've tested here.
If you really want to re-encode your library, I'd recommend getting a modern NVIDIA graphics card (recency matters a lot more than power) and using that instead of the SBC. It should be a lot faster than the SBC and the compression will be a lot better.
EDIT: Also, I forgot to address the "and different codecs are better or worse than others" comment near the start of the post. What I was getting at here was mostly the widely-held belief that AV1 is "slower" or more computationally-expensive than HEVC. This isn't the case but I believe originates from comparisons of the unoptimized reference encoder to more mature HEVC encoders. If you look at [1], you'll see that SVT-AV1 performs very well. It's not yet beating Bytedance V265 but it does handily beat just about everything else on speed/quality, including x264.
But that kinda ignores the main takeaway: the main thing you need to compare and judge is the encoder, not the codec. AV1 isn't slow, libaom is slow. HEVC doesn't compress better than H264, HEVC adds more tools, so that V265 can compress better than x264.
[0]: http://www.compression.ru/video/codec_comparison/hevc_2019/
[1]: http://www.compression.ru/video/codec_comparison/hevc_2019/d...
There is only one other cheap computer with ARMv8.2-A: Khadas VIM3L (a little more expensive, less DRAM, WiFi included, another variant of the same processor, no USB hub but PCI-E on an expansion connector).
C4 comes with a large heatsink. Rpi4 doesn't despite the much higher power consumption, forcing you to add one.
My conclusion: The RPI4 is an unreliable, poorly engineered toy (like every other RPI in the past). The C4 is rugged and a good choice to base projects on, like every Odroid has been to date.
My experience is the opposite. The raspberry pi ecosystem is low quality and full of quirks and annoyances.
All the alternatives I have used (mostly sunxi-based) have been a much smoother experience.
The ARM boards make sense only if you have power and size restrictions.
Power and Size restriction can be a bigger deal than you've made it sound, though. I can fit ten Pis in a carry-on without concern if needed, and I have needed to do so in the past. For noise reduction, fanless is better than muffling a fan, though one does need to make sure the heat sink is big enough.
This is great. If you absolutely do not care about power efficiency, physical size, noise or reliability.
They aren't even comparable. And even if you claim to care about raw performance, I'd like to see how well that i3 does in a direct benchmark. It might not turn out the way you think it is.
It is not easy to pass EMC tests if you want to embed these boards into some device without proper grounding.
Might be a good accessory to sell.
good fun though
2) Raspberry Pi has much better official and (especially) community software support than other SBCs. Things like bluetooth or wifi are usually supported better there, with fewer quirks and breakage, and software's usually more up to date generally. You're rolling the dice with anything else if you're looking for something you won't have to spend a bunch of time fiddling with or fixing all the time.
I also read somewhere that RK3399 for emulation should also be a good choice, therefore I considered the Rockpi 10N as well.
I disagree, as my experience has been the opposite of this. RPis are always a quirky mess, where doing anything but using turnkey appliance-like solutions is painful, and even these turnkey solutions suffer from poor quality.
It's a low-effort, low-quality ecosystem, and my experience has been better with each and every one of the alternatives I've used.
They have excellent community and Mainline Linux support:
https://linux-sunxi.org/Linux_mainlining_effort
Support in BSDs is similarly very good.
I'd pick among the boards that use the A20 (ARMv7) or the A64 (ARMv8 aarch64), as these are the better supported chips.
Amlogic, iMX6, iMX8 and rockchip also have good reputation, from what I hear from my acquaintances. But I haven't tried these myself.
Broadcom (used in RPI) is infamous, and it's a much deserved infamy. I've had nothing but trouble with them, be it SoCs used on RPIs or other chips made by them.
Being cheap and widely available still does a lot for the Raspberry Pi for DIY purposes IMHO, but I would be wary to base a product on it.
The 3B and 4B have their own different hacks needed to get normal Linux distros running under 64bit, and it's nothing you can expect an average hobbyist user to figure out even with the resources put out by people in the community who have succeeded (unless they just flash some unsigned image containing god knows what uploaded out by some rando on a forum).
You’ll just find tons of things that don’t work when you use anything but rpi.
My experience has been the opposite of this.
RPIs have always been the hardest boards to get working.
[1]: https://www.raspberrypi.org/blog/vulkan-raspberry-pi-first-t...
[0] https://developer.arm.com/ip-products/graphics-and-multimedi... [1] https://developer.arm.com/solutions/graphics-and-gaming/apis...
Google 'armbian vulkan.' armbian is an OS that these Pi clones often run.
If you download your youtube videos beforehand using youtube-dl and play using omxplayer, the result is virtually glitch free.
A better option is to install the YouTube extension on top of Kodi on Raspbian. You might also need to disable the new OpenGL driver as well. Once that is done, Kodi (which has Pi GPU patches in place) can play YouTube at 1080p30 beautifully.
Yup, that was how I watched Youtube videos for years (although Kodi was on LibreElec). Now unfortunately all Kodi extensions using Google APIs require registration, which of course is a huge privacy violation since I'm (still) not forced to do that on browsers.
When I tried via a web browser a while ago I couldn't get it to work well, iirc I had to install a plugin from somewhere too.
Edit: I own Odroid N2, spent several weeks trying to make it working well. At the end I've given up and got an Intel NUC device.
A55 is a 2-wide decode in-order architecture with 2 execution ports and 2.65 DMIPS.
A72 is a 3-wide decode out-of-order architecture with 8 execution ports and 4.72 DMIPS.
Obviously something is wrong here, so let's examine what it could be.
To get it out of the way, Mali G31 MP1 is theoretically slightly less performance (20.8GFLOPS vs 24GFLOPS), but my money would be on the Mali being much more efficient (the VideoCore architecture has been notoriously slower than it's theoretical numbers would indicate).
Cache is another consideration. The Pi 4 uses 1mb of L2. I can't find anything about the 905 except that it has L3 cache. The maximum L2 for A55 is 256kb. L3 can go up to 4MB. The s922x launched middle of last year and seems to have had 1mb of cache on it's A73 cores, so I would guess at less than that for a lower-end chip. In any case, I'd put cache as equal at best.
Pi 4 uses 1-4gb LPDDR4-3200 vs some DDR4-1320 on the odroid. No matter how you slice it though, something weird is going on here.
There is a default clockspeed difference (1.5GHz vs 2.0GHz), but it isn't nearly as large as the actual performance per clock difference. Since the 905 is apparently rated to run at 1.9GHz, I suspect they slightly overclocked the chips in their devices. I'd note that overclocking the Pi 4 to 2.0GHz is easily doable, but I wouldn't expect them to do that as it can lower the life expectancy of the chip (given the 8-stage A55 pipeline, I doubt that the 905 has much overclocking overhead).
On paper, the Pi 4 should be way faster at most of these things, so it must be elsewhere.
The first stop is data storage. SD cards suck. They suck so much that a spinning drive can usually get better performance. They desperately need to launch a new Pi with a SATA port or PCIe port for a faster drive. eMMC is a much better default option. The Pi loading benchmarks get 2-4x faster (sometimes more) when a USB3 SSD is used. On the flip side though, if a benchmark sits in RAM, you aren't going to notice a difference unless their benches are including load time. That may be fine for a few things, but it should be stated and it simply doesn't apply to a lot of real-world uses (for example, loading a browser may be a little slower, but opening and using web pages will not).
The next question is thermals. The 28nm Pi with larger cores definitely gets hotter and throttles more than the 12nm smaller A55 cores. If they shoved the pi into the default enclosure without a heatsink, it would definitely throttle hard which would affect benchmarks significantly. I fully expect this to be responsible for a large percentage of the performance disparity over what would be expected. Testing the raw Pi would be much more fair. A small heatsink would be more than fair and a fan would be overly-generous (seriously, pi foundation needs to recommend and sell a heatsink and redo their case design to accommodate a fan). I'd love for this to also be disclosed.
The next issue is insidious and veers much closer to evil. Using the same OS when possible should be a prerequisite for fair comparisons. Ubuntu team did some great work and fixed the major bugs that were hurting 64-bit usage (USB issues and 2-3GB RAM limit). I switched from Rasbian and there was a very noticeable increase in performance. Those fixes have been available for almost 6 months and there's no reason not to use it for their testing other than cooking the benches. We aren't talking small amounts either. 10% faster memory, 50% higher dhrystone, 15% faster audio encoding, 2x faster network performance, etc. I'm almost positive that they used Rasbian instead.
https://medium.com/@matteocroce/why-you-should-run-a-64-bit-...
No matter how you slice it though, they legit won the encryption benchmark by a landslide. Broadcom didn't include the armv8 crypto extensions. It was a dumb decision and one more thing that needs to be fixed on the next generation pi.