Wanted to share a recent success. As the subject line says - 25 simultaneous hardware transcodes of videos with an average bitrate of ~10mbps encoded in h.264 with aac audio, on-the-fly transcoded to an average bitrate of ~2mbps. No dropped frames, and CPU utilization averaged below 30%. Here’s a screenshot:
Once it went above 25 simultaneous hardware transcodes, to 30 and 35 simultaneous transcodes, the CPU utilization across all 12 vCPUs started violently fluctuating between ~50% and ~95%, and frames started dropping.
This is really impressive. Kudos to the Plex team, and to Intel, for how bitchin’ QuickSync is, and how well it works in Plex, and on linux, and in Docker (more on that below). This NUC is the size of a pancake, and it’s capable of serving everyone in a person’s circle of friends and family at the same time. I figure direct streams could probably reach into the 50’s or more before having issues. Just, wow. Old early intel core i7 macbooks can barely handle 3-5 streams like this.
Here’s more info on the server’s underlying architecture and config:
The NUC10i7FNK and the slightly taller NUC10i7FNH are basically the same in all the ways that matter related to computing. The one referenced here happens to be the FNH variety, but the FNK would perform identically.
This NUC has a 10th gen Intel Comet Lake hexacore i7, which the OS sees as being 12 vCPUs.
It has 2x8GB of 2666hz DDR4 Ram
The server’s OS is stock Ubuntu Server 20.04, which has native support for quicksync on 10th gen intel cpus - no messing with video card drivers and vaapi or media-drivers - it just works (even inside docker containers with the help of a special device parameter in the docker-compose.yml file).
Ubuntu is installed and booting from a 1TB Sabrent Rocket 4 NVMe M.2 SSD
The server has Docker v1.19 and Docker-Compose v1.25 installed on it
The plex install is fronted by the best home reverse proxy - Nginx Proxy Manager.
Nginx Proxy Manager is also in a docker container, automatically pulling letsencrypt certs for plex (and every other container on the machine).
All communication between plex and the nginx reverse proxy are via http. All communication from the reverse proxy to the user is over https.
The actual library files themselves are stored on a Synology DS418play
The DS418play has four HGST Deskstar 6TB 7200RPM drives
The 4 drives are configured in RAID 5 (~16TB usable), running the BTRFS file system
The files on the DS418play are being shared via NFSv4.1
The AutoFS package is installed on the ubuntu server in order to keep the NFS share mounted at all times, and to auto-re-mount it in the event of a disruption in the connectivity the server and the nas (very, very rare, but nice to have automated all the same)
The server and the nas are both connected via gigabit ethernet, with a Google Wifi router doing the switching for the local network and port forwarding only port 80 and 443 to the server (the reverse proxy handles interpreting requests on various subdomains and passing those on to the specific ports the various services are operating on, but that’s inside the docker’s internal network.
I love it. Unfortunately, all my content has 10 bit colors so I wont get to utilize it just yet, but Im plannning on getting an i7 8700T for this purpose so its nice to know how well it performs
8th & 10th gen CPUs both support decoding of HEVC 10-bit video in hardware.
Look at Datasheet, Volume 1, Section 2.4 Processor Graphics for each processor family. You’ll see tables & additional details on which codecs are supported by Intel Quick Sync Graphics.
@RockStar - for what it’s worth, I can anecdotally confirm what @FordGuy61 said, that the 10th gen cpu in NUCi7FNH is capable of transcoding HEVC 10-bit out of the box, here’s a bit of proof:
I realize the chip is capable, but Plex transcodes to 8 bit AVC and doesnt support tonemapping. So the chips capabilities doesnt really help until plex decides to either implement mapping or choose to retain the 10 bit colors / transcode to hvec
@RockStar a month ago I hadn’t experienced the issue you described with tonemapping - I’d only ever had x264 content, and none of it had HDR, it appears. Well, since I created this thread, and have fully re-downloaded my entire Library with x265 versions that have HDR, I’m now quite painfully aware of what you were describing. Here’s a random comparative sample:
Any video with HDR that needs to be transcoded by plex will look desaturated/washed out/obviously wrong/objectively gross.
Given that plex has had tone mapping in their backlog for years, and as far as I can tell, still isn’t prioritizing it, I’m trying to figure out what to do now…
Buy a new TV/monitor that supports HDR
Blow up my entire current collection and re-re-download at x264 again (thus no HDR)
Leave the plex platform, maybe try Jellyfin or an alternative that handles HDR tonemapping
I would keep the HDR content. It looks better once you eventually get a TV that supports it. In the mean time, you can always get a client to tonemap for you. Like the Apple TV. And turn transcoding off in PMS to make sure it doesnt bastardize your files.
@RockStar disabling transcoding isn’t an option. I have dozens of family members with old tvs that require it. Thus, I find myself in a situation where I must have a server that supports tonemapping of HDR content. Thoughts?
I dont know any alternatives to Plex that will transcode HDR content. Emby say they are close, but they are not there yet.
Right now, as far as I know, your options are limited to:
Make your users update their clients (the Apple TV 4K will tonemap and scale when connected to a 1080/SDR display). If your users value using your server, its not a very big investment.
Best practice right now is keeping a HDR file and a non HDR.
It would be so much easier, if Plex allowed transcoding with tonemapping. It doesn’t even have to be real-time. It would be so much easier, if we could just create optimized tone-mapped copies within Plex for remote playback. That way I could convert all the 4k HDR movies I have to 1080p/SDR for remote viewing.
Excellent post! While I’m not using an NUC, I built a SFF server into an InWin Chopin to keep the footprint small, and also use QuickSync to transcode. Similar to you, Plex runs in an LSIO container, and media is served via an FSTAB mount from a 110TB FreeNAS server. Everything is served out via my own domain, which- like you, uses NGINX/Let’s-Encrypt to serve as a reverse proxy (although unlike you, I’m rolling an “apt install nginx” instance/not a docker image, due to having wanted to implement TLS 1.3 before the stable/docker versions were ready- I also use a wildcard cert, which isn’t something the docker container does).
So here’s where I want to pick your brain- or maybe open your eyes…
Let’s discuss Content Security Policy for your NGINX proxy. If you haven’t already, run your TLDN through SSL Server Test and, specifically, Mozilla Observatory. Obviously if you rolled your eyes at my suggestion of discussing Content Security Policy, you already know where your reverse proxy’s security stands, and there would be no need to run these tests .
If you look at both the HTTP Observatory & the third-party results for the " HTTP Headers & Content Security" entry, you’ll most likely notice that you’re entirely missing the Content Security Policy & Feature Policy Headers.
A quick search for “Plex Content Security Policy” on google reveals a few Reddit posts, and a single Plex Forums post. Essentially, in order to enable CSP Headers for your own TLD, you would need to pull sha-256 hashes each time a new server update is releases, which is crazy (from an implementation standpoint).
So, getting to the question/pick-your-brain portion of this long-winded post: Do you have a successful Content Security Policy in place for your your selfhosted plex instance/TLD?
.