Background: The Atomic Pi is a $35 single board computer with an Intel Atom Z8350 quad core processor. This processor comes with a graphics core that doesn't specify Intel Quick Sync, but based on the video processor details I thought it was a feature that was available, but not advertised.
-Chuck Update From the Future: 1-27-2021
I actually ran this as my primary Plex server at my home for a couple of weeks. It ran fine when it was running, but I had stability problems. I was running Ubuntu server 20.04 and Plex from a USB attached SSD drive and for some reason it would randomly disconnect, bringing things to a halt. It happened occasionally but enough that it was a problem, so I tested swapping cables with the same result and eventually scrapped this effort and went back to my tried and true fanless Kodlix Intel Celeron N4100 based Plex server.
I'd previously been running an Intel NUC with an i3-3100U as my Plex server and it was great too, but it had some slight fan noise and the Kodlix was sitting around doing nothing so I put it to work.
Wanna know more about this board? Head over to the Atomic Pi subreddit.
I set out to run Plex on the Atomic Pi to see if it would do hardware transcoding of videos. Plex transcodes out of the box with no modifications if you are using an Intel CPU with the Quick Sync feature. (And have purchased a Plex Pass subscription.)
I don't expect the Atomic Pi to be a world beating Plex server option, but for $35 if it can manage a couple of transcoded streams it would be very impressive.
Test Details: -Wiped the Atomic Pi's onboard storage and installed Ubuntu Server 18.04.2 LTS with all patches up to date as of 5-13-19. One thing worth noting, you will want to use a powered USB hub if you are installing Ubuntu from a USB DVD drive. I cracked my head on this one for a bit because the Bios would see the DVDROM but the board would not boot from it. I eventually just installed Ubuntu Server from a USB flash drive with the install files on it since I didn't have a powered USB hub handy.
-Installed Plex Server quickly and simply by running the command: sudo snap install plexmediaserver
-Configured the Plex server via its web interface and be sure to tick the box under the transcoding section to do hardware transcoding and I left the transcoder quality setting to the default of auto.
-Downloaded the Big Buck Bunny 1080p Surround .avi file to test with and copied it to the Atomic Pi local storage.
Here are the results:
I was able to run 4 transcodes of various qualities before things started maxing out. You can see the (hw) was activated on each streaming session. I would say that 4 is the max for this video and 3 would be ideal. It could probably manage some non transcoded direct streams as well here since they don't impact the device much at all. Depending on your user load, you could actually use this as your primary Plex server.
If you have 2 direct streams and 2 transcodes happening at the same time and depending on the video it might just be able to do it. It could certainly do it with this video.
Reported CPU and bandwidth usage data from Plex during 4 transcode session.
Here's the result from the python utility: s-tui running on the Atomic Pi during the 4 transcode session. You can see that it was putting in work, but the graph is similar to what Plex saw also. Some spikes to 100% CPU, but it was by no means fully saturated. It also shows the frequency of the CPU, and thanks to that monster heatsink, the CPU was not throttling due to overheating.
Well, that's it. I hope this helps you understand the kick ass deal that these boards are.
Bonus Content: I figured someone might wonder what transcoding looks like on this board without the hardware box checked in Plex and just done via software against the CPU.
Here are the graphs. It is possible, but only a single stream.
The CPU is pegged and stays pegged during this single software transcode stream.
Linux utility agrees. It is flat out, but is actually making less heat and consuming less power. The hardware video processor onboard does take some power to do its work during hardware transcodes apparently. Seems logical.