Today, we're going to try to run as many 1080p videos as possible from a Plex
Media Server to see how well Plex's hardware transcoding performs on Intel's
Quick Sync, which is built into the onboard GPU of
Intel's processors. Since hardware transcoding is a paid
feature of Plex, you will need Plex Pass if you'd like to
replicate the testing on your end. The test itself will start off by
running a Plex web player in a Brave browser window,
but i won't stop at just one. I'll run not two...
not four... not eight, sixteen or thirty-two... but sixt... well not that many.
I'll have around eighteen instances of Brave on one screen,
each playing a unique video from the Plex server. To explain how I've set up
the test, let me show you a diagram. Here's the
Plex Media Server, which resides on a machine with Linux Ubuntu Desktop
version 20.04, running on a a ninth generation Intel Core
i5-9400, mounted on a Gigabyte B365M-DS3H
motherboard with 32 GB of memory, where I'm using an Elgato HD60
to capture its resource monitor. The client machine where I have the 18
browser windows is a run-of-the-mill Ryzen 5 2400 desktop, and I'm using
Camtasia to capture the video. The media itself
is located on a Qnap NAS unit to which the Plex server is pointing.
Finally, I have a couple other laptops that are simply monitoring the Plex
dashboard so I can show you the graphs and video statistics,
captured using OBS Studio. Everything is connected with wired gigabit ethernet.
A quick note about GPU transcoding: you could use something like an Nvidia
graphics card to offload the transcoding, but I decided to use Intel's Quick Sync
solution because their later generation Core CPUs
have improved so much in decoding and encoding quality than
earlier generations. If you don't have any GPU or if you
don't have Plex Pass, then all transcoding would be done on
the CPU itself, which would limit the number of
simultaneous Plex streams. So back to the test - I have three columns
of six browsers open. I'm just gonna go down each column,
starting each video one by one, and see how far I can get. On
the right side, I have the Plex dashboard, monitoring the CPU, memory and network
bandwidth as well as Ubuntu's resource monitor on
the Plex server itself, which monitors the same three pieces of
information, albeit with slightly different representations.
For instance, here it's tracking each core on the CPU,
and it also reports the inbound and outbound network traffic.
Below the statistics, there's an empty area right now because nothing's playing,
but I'll show the Now Playing section of the Plex dashboard here.
To avoid any copyright issues, I'll be playing my own access random videos,
which I've added to the Plex server temporarily for the express purpose of
this experiment. All of my videos are encoded as mp4s at
30 frames per second with a variable bitrate
averaging about seven to eight megabits per second for each video.
Audio is AAC at 192 kilobits per second. In order to guarantee that every stream
is transcoded, I'm going to go into the Plex server
settings in the Brave browser, tab over to Quality, and uncheck the box
for using recommended settings under home streaming. I'll keep it at the
default of four megabits per second and 720p
which forces the player to transcode my 1080p
videos on the home network. If I go back to my account,
you can see I have a lifetime Plex Pass account, which is necessary for the
server to transcode on Intel's Quick Sync.
Going back to my composite screen, there's a little chatter on the network
graph already without any any videos running, and that's
probably because of the Plex dashboard itself
sending information to the client where I'm capturing the graphs.
Let's hit play on the first window and start the first stream.
It starts up pretty smoothly - to see if it's transcoding properly through
hardware and not software, you can see an "hw" in parentheses in the
Now Playing section, next to both the resolution for decoding
the original file, and the output resolution to which it
encodes, which indicates that it is indeed using Intel's Quick Sync for
hardware transcoding. If the playback is successful, it'll
report a "playing" status, as you can see here.
Otherwise, you'd see a "buffering" status. The bandwidth on the network spiked a
bit as it spun up, but settled down. You can see a small
spike in the CPU, but then it drops down again. Let's start
the second video and see the results. Again, it spins up without
any buffering. It is hardware transcoding, according to
the stats from the Plex server, and we see the same kind of pattern
where CPU and network usage spikes up momentarily, but then settles down.
Memory use hasn't really changed at all. Since we've observed the behavior of one
or two streams, I'm now just going to start the entire
column, so that I have six videos running at the same time.
Let me start video number three... and I'll wait for the stats to catch up after
each start... that's number four... that's the fifth one.
And finally, here's number six. At this point, it's getting a little loud...
It's getting a little loud in here, so I'm going to mute the audio. That voice was a little annoying.
So far, all have spun up pretty well and each one has hardware transcoding.
The CPU has sloped up to a steady state of about 30 or 35 percent,
network bandwidth follows the same pattern again, and memory usage hasn't
really been a factor at all so far. I'm going to start the next three videos
one by one. Here's video number seven... and I'll wait a little bit for it to
spin up completely... That is number eight...
...and video nine. Smooth sailing so far, with CPU and RAM usage holding steady,
with the normal increase, then decrease, in network
bandwidth. Let's batch up the next three, and start number ten... which has a little
hesitation to take off... but it's not too bad. Let's start video
11... I can see it struggling a bit...
but it eventually spins up. And at the bottom of the second column is video
number 12, which again is a little slow on the draw...
However, with the 12 streams going, you can see we have no lag or buffering,
with the stats telling us that everything is being hardware transcoded,
and a gradual increase in the CPU, memory, and bandwidth usage. Now I'm going
to slow down a bit, and start the next few videos one at a
time. Let's start lucky number 13 - and hopefully we won't run out of luck.
As expected, it takes a little more time to warm up...
but the good news is that all of the previous streams are going strong
without any hiccups. I don't see anything particularly
unusual happening in the graphs, so let's move on to the next one.
Subjectively, I feel like we're almost reaching the maximum number of streams,
because I do notice some slight skipping of frames in some of the other windows.
But once we get over that hump, it looks like we do have 14 hardware transcodes
with no buffering. Let's start video number 15.
I'm seeing the spinning hourglass a little longer than I'd like,
and there's some noticeable frame jumps in some of the other browser windows...
Now we're starting to get into trouble, because I'm definitely seeing the
hourglass in several of the other videos. It looks like we've probably reached our
limit. Based on some previous experimentation,
I've found that minimizing some of the browsers will actually eliminate the
buffering and things eventually go back to normal.
The Now Playing stats prove that Quick Sync on the server itself can process
the decoding and encoding of each and very video,
but the client - where we have the 18 browser windows -
may be having problems rendering that many outputs.
That's just my theory, but if you have an alternative explanation,
please bring it up in the comments. One way to improve the testing may be to use
multiple client machines with a limited number of streams on each client,
so I may try that in the future. I don't think it's a network issue,
as we're nowhere near the saturation point of one gigabit,
but it is possible there's a network bottleneck somewhere - perhaps a bad cable
or port. I'll go ahead and start the last three
streams, starting with video number 16. I'm going to compress the video to speed
things up, but in real time it takes about 13 seconds from the time I hit the
play button to the time it actually rolls the video.
Let's hit play on video number 17. The hourglass spins longer than a disco ball
on Saturday night, before it starts the video
at about 16 seconds. And finally here's the last video...
Taking longer than a fidget spinner made with stainless steel bearings,
the hourglass finally stops spinning in about 20 seconds.
Eventually we have all 18 going on the server side,
with each one transcoding properly using Quick Sync. If I restore the six screens
that I minimized earlier, I suspect we're going to run into problems again.
Let's see if my theory holds... and as you can see,
some of the windows are starting to lag. Again I might change the experiment
by using multiple hardware clients and not so many Plex players on one client.
If you have any suggestions on improving this experiment, or if you've performed
one yourself, please leave a comment below. With that
said this is by no means a real world test.
If you have 10 or 20 devices on your local area network,
and you have that many people watching your Plex movies at the same time, with
each device requiring a transcoded video and/or
audio, then yes, you you could use this test to
determine the approximate number of streams your Plex server can handle.
This is assuming that every stream is being transcoded. If you have Plex
clients that can natively handle the codecs and direct play the video,
then you should be able to have even more simultaneous video playbacks.
I'm not sure what to make of this, but as I've been speaking,
things have settled down now, and it looks like all 18 are streaming pretty
well with little to no buffering. Here are the final stats for the
dashboard... and a final peek at the Now Playing
section. In my previous videos I'd always run Plex Media Server on
Windows. If you're interested in visiting my Plex
tutorials, I've placed a link to a playlist in the description,
as well as in the upper right-hand corner. I've recently migrated the
metadata and my libraries from Windows to Linux successfully,
so if that's something you're interested in for a future video tutorial, please let me know.
I hope you enjoyed! - Thanks for watching.