Chuck's Cool Reviews and Info

Projects, news and stuff going on. Pictures link is to the right.

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: enter image description here

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.

enter image description here

Reported CPU and bandwidth usage data from Plex during 4 transcode session.

enter image description here

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.

enter image description here

enter image description here

The CPU is pegged and stays pegged during this single software transcode stream.

enter image description here

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.

Required Components:

  1. A reasonably current Intel CPU with Intel Quick Sync Video capabilities. Check your processor capabilities here: https://ark.intel.com/
  2. Plex Pass Subscription

  3. Licensed VMware environment with vCenter. This guide is using ESXi 6.5, but 6.0 will work also. I have not tried other versions. -A setup with the free version of ESXi installed on a standalone host would work here. Check Ebay for cheap vCenter licenses.

Background: I have been running a Plex server for years and never really paid much attention to transcoding in hardware mainly because it was a feature reserved for Plex Pass Subscribers, (which I was not) and I didn't have many friends and family accessing my media. I recently became a Plex Pass user with a lifetime subscription deal that they sent me via email. I always run my Plex servers inside of a VM because I run a home lab and have VM resources always available and ready to do work.

My homelab consists of two I3-6100U processor 6th generation Intel NUC VMware ESXi hosts. These NUCs are perfect for me since they were affordable, low power, quiet, extremely tiny, and easy to add to by stacking on another NUC. Also, if you are in a situation where you are regularly moving apartments, home, dorms, etc. You cannot beat a space optimized home lab. Plus ESXi installs on the 5th gen NUC with no need for additional work. My home lab, like most others is not a big consumer of CPU most of the time.

enter image description here

Home lab shown. The cardboard is there to keep the drive trays from vibrating and making noise. 6x 8TB drives for media storage, 2x 1TB SSD drives for VM datastore storage, unmanaged 8 port gigabit switch, 2x Intel NUC6i3SYK NUCs configured with 32 gigs RAM each.

I did some reading and experimentation with transcoding because I was getting more friends and family hitting my Plex server recently. I felt like I needed to monitor performance and make sure that I had enough resources for this additional load. Most outside users were transcoding due to bandwidth limitations, whereas home users almost always are doing direct play. I was surprised with the results of my testing. Plex has a ton of information about transcoding. I took a look at this page and learned how to enable hardware transcoding, the requirements and how to experiment with forcing transcoding: https://support.plex.tv/articles/115002178853-using-hardware-accelerated-streaming/

To experiment, I began streaming a 1080p movie and watched my Plex VM by logging in and running the HTOP command. (It is an Ubuntu Server VM.)

Direct Play didn't hit the CPU much at all. I then changed to a transcoding resolution and my Plex VM saturated all of the CPUs granted to it (2) for quite some time. The video played just fine, but I need to avoid this saturation if possible. After the initial CPU spike for upwards of 1 minute, it calmed down a bit to about 60% usage during the video playback. I tried giving the VM 4 virtual CPUs since my I3 has two physical CPU and two hyperthreaded virtual cores. As you can imagine, this didn't do much. So now that I knew this was happening, I needed to enable hardware transcoding at all costs, but I didn't want to incur a cost. Plex says in the link above that hardware transcoding is not possible inside of a VM. Damn! But let's not take their word for it, let's try it anyways. I went to Direct Access settings in my host, and I saw the video card available and configured it for access.

enter image description here

enter image description here

This change required a restart of the ESXi host, so I did that. Then I shut down the Plex VM and added the direct access device. Looking good so far.

enter image description here

Upon booting of my Plex VM, I got back into the Plex interface and tried watching the same movie. I made no changes to the Plex VM. I didn't look for drivers nor try to install anything on my Plex VM. I am running Ubuntu Server 18.04 LTS. Direct Play worked as expected, but then I switched to a transcoding resolution and was immediately impressed. It switched over very fast and I saw the indicator that I was transcoding in hardware: (hw) was showing on the Plex web interface server status. Wow. That's it? That was easy.

What does this mean for performance? Huge for me, as I am running on underpowered CPU hardware in the first place. After the change, transcoding took nearly zero CPU resources since it was all being done by the onboard video processor portion of the Intel CPU. There was just a slight hit well under 100% CPU consumption while the video started streaming, and nearly zero hit after the initial spike.

What is the drawback for the VM and general VMware functionality? Well, this is the trade-off. 1. You can't do a live vMotion of the VM because it has direct attached hardware. 2. It requires you to reserve RAM for the VM. Not a ton though. I have 4 gigs RAM allocated to my Plex VM, and it is not using that much. I could probably allocate 2 gigs and be fine. I set a RAM reservation to 4 gigs. 3. You can't do a snapshot of the VM.

For me, these are acceptable trade-offs since I was considering setting up a dedicated NUC for Plex serving to take advantage of the hardware transcoding. This avoids needing to do that and allows me to run additional VMs on this ESXi host like I already was, I just need to shut down the Plex VM if I need to do any ESXi host maintenance.

***Followup on this. I was curious if this will allow me to transcode 4k video. I don't have any 4k content, so I got a sample 1 minute of Elysium from http://4ksamples.com/

Even with transcoding confirmed to be done in hardware now, I could not watch the 1 minute video without the video buffering twice and then crashing. It started strong, but couldn't really make it past 30 seconds. Oh well..... 4k aint no joke.