Part 2: The Fanless NUC as HTPC (DE3815TYKHE)
In the previous article I told you about the new fanless NUC running a Bay Trail Atom processor, the DE3815TYKHE (Amazon) which is mainly targeted for various embedded systems, digital signage, kiosks, etc. In this article I’m going to have a look if this newcomer would be a decent HTPC. It’s a bit short on horsepower, but a Raspberry Pi is able to run OpenELEC/XBMC after all…
|The Fanless NUC|
I’m going to install the OpenELEC operating system, which is purpose-built for just one task: to run XBMC as your media PC. It’s really easy to install, operate and update. I will install it on the internal 4-gigabyte eMMC disk that is built into the NUC. I can imagine that the integrated storage is appealing for embedded systems, but it will also accommodate the OpenELEC operating system nicely! Of course there won’t be almost any storage for media files, but even for that you’ve got two options: either you stream your content from a network drive (NAS) or you can install a 2.5 inch disk in this NUC.
In order to run OpenELEC on the internal eMMC disk, you will need to use release 4.0.2. That’s the first release that has the MMC support built into the kernel and the installer is also modified to give you the possibility to copy the files to the MMC. A small detail here, it seems only the quick installation method works in 4.0.2, the custom installation did not find the eMMC drive. In general the installation was easy, just press enter a few times and you’ve got a nice fanless HTPC. Remove the USB stick, reboot and OE is up and running.
From the push of the power button, this fanless NUC takes approximately 25 seconds to boot into XBMC. Not as fast as a Haswell NUC booting from an SSD disk, but not too slow either. In the previous article I managed to read a bit over 40 megabytes per second from the eMMC disk. And it’s dead silent…
It seems to work nicely. The interface is slick and everything works pretty much as I’d expect. There doesn’t seem to be a big if any difference between this and my i3 NUC. I changed out of the default Confluence skin to Aeon Nox or Aeon MQ5 that are known to be more CPU intensive, but even they work fine. The supercheap ($5, eBay) AR5B95 WiFi adapter works fine and I download a few addons.
If you have a video playing in the background and you summon the EPG or the menus that are overlaid on the video, the transitions in the menus become slightly jerky.
Full HD playback
I try testing out a few 1920×1080 24p videos and the playback seems to be ok. It’s good to make sure that the following settings are configured in XBMC:
- Video – Playback – Adjust display refresh rate to match video: On start/stop
- Video – Playback – Sync playback to display: Enabled
- Video – Playback – A/V sync method: Video clock (Drop/Dupe audio)
- Video – Acceleration – Decoding method: Hardware accelerated
- Video – Acceleration – Allow hardware acceleration (VDPAU): Disabled
- Video – Acceleration – Allow hardware acceleration (VAAPI): Enabled
- Video – Acceleration – Use Mpeg-2 VAAPI: Enabled
- Video – Acceleration – Use Mpeg-4 VAAPI: Enabled
There are a few very high bitrate test videos at jell.yfish.us that I tried. I tried the 100 Mbps video and even that was fine. Here is a screencapture from the 50 megabit video clip. There were no dropped frames during the playback. There are a few right in the beginning of the playback, but it stabilizes after first second or so. Do note that in real life most of us will not face a video with 50 megabits/s…
|Playback of 50 Mbit/s 24p stream|
Does It Do 24p?
After the problems that Intel GPUs have had with displaying the 24p content another question everyone had was if the NUC can do proper 24p, meaning not 24 frames per second but 23.976 frames per second. And yes, it seems that the Bay Trail GPU gets the check mark.
If you are watching content that is not in 1920×1080 resolution such as a normal SD television, DVD content or even 720p HD content it needs to be scaled up to 1920×1080 resolution by the HTPC. Now comes the bad news, the GPU in this NUC is too slow to support anything except the Bilinear scaling. Bilinear in my opinion is fine for 720p to 1080p scaling, but for SD TV to full HD it produces quite a blocky picture. Especially diagonal lines look bad with bilinear scaling. Note that this is only a concern with SD content, for HD content no scaling is required.
|100% crop from a video where SD content has been upscaled.|
Deinterlacing comes into play if you are watching interlaced content. That is typically live TV content or content recorded by a live TV backend such as Tvheadend. Due to historical reasons TV is often broadcasted in a format where only every other line is drawn on the screen (ie. for 1920x1080i video there’s only 540 lines of information at broadcasted at any given moment). This was fine with CRT screens, but modern LCD screens do not really support interlaced content. Thus it needs to be deinterlaced before it can be shown properly. Deinterlacing can be done in many ways and the more sophisticated ways consume more processing power but also provide a better picture.
The graphics drivers for the Intel HD Graphics on Linux are currently in an unfortunate state and the deinterlacing is not really working as it’s supposed to work. Thus the alternative is to use CPU for performing the deinterlacing. This works ok for SD content, but for content broadcast in interlaced HD format (1080i) the feeble CPU in the NUC is not able to handle the deinterlacing. Only the plain BOB works, but that provides a jittery image.
Another, rather annoying issue with the software deinterlacing is that you need to enable the option Video – Acceleration – Use SW Filter for VAAPI and then you can choose even Yadif as deinterlacing method (Yadif equals to Deinterlace method De-interlace in the settings) which provides the best result and this is fine for the SD content. However, when you try to play non-interlaced 1080p content, the SW filter option will consume CPU even if there is no deinterlacing to be done. Thus you need to switch off that option if starting to watch a 1080p video.
Again, deinterlacing is probably only an issue if you are watching live TV with your HTPC. Almost all streamed content is in progressive mode and does not need to be deinterlaced. It seems that some work is being done to enable hardware accelerated deinterlacing on the Intel GPUs, so this situation might improve in future.
I’ve successfully installed Tvheadend and watching SD live TV content is not a problem. Interlaced HD TV probably is an issue due to the interlacing woes mentioned above.
The fanless NUC DE3815TYKHE surprised me with its lively performance in the menus and good performance when playing full HD videos. It is totally silent and you do not need to add any storage media as there’s an intenal eMMC storage built in. It’s significantly faster than a Raspberry Pi for example (but that’s an unfair comparison) and OpenELEC works smoothly out of the box on it (version 4.0.2 or newer required).
On the other hand both of the Bay Trail NUCs suffer from having only 4 execution units in their GPU. The DE3815TYKHE model reviewed here gets hit even more, as the GPU is only clocked at 400 MHz vs. the 756 MHz that the DN2820FYKH model does. As a result the upscaling and deinterlacing functionality with the current drivers leaves something to be desired. The same situation applies to all Bay Trail motherboards currently.
Considering that the DE3815TYKHE is sold for more or less the same price as the other Bay Trail NUC DN2820FYKH, I’d say unless you really desperately want a fanless system, go for the DN2820FYKH. Better yet, go for an i3 model and you don’t need to ever worry about upscaling or deinterlacing. Don’t get me wrong, this NUC is a fine small PC, but you should be aware of its limitations. Another fanless option is the Gigabyte BRIX with N2807 processor.