Plex Server Version#: 1.41.0.8939
Proxmox: 8.2.4
Hardware Passthrough: Intel Arc 380
VM OS; Ubuntu 24.04.01
VM Kernel: 6.8.0-41-generic
I have been testing transcoding performance in this configuration and have gotten fantastic results transcoding 4K high bitstream HDR 10+ (with Atmos) movies to a whole variety of different 1080 / 720 / 480 formats using tonemapping. I have tested the system to 20 simultaneous HW transcodes and have hit the limit in the gui:
I was wondering how anyone couldāve missed that, so I went to check, and that drop-down box has a limit of 20 items, lol. So, if someone previously set it to 20, the unlimited option is not shown (you have to scroll up).
No. I put the system together and I want to know what it can do. I dont really expect that I will ever have more than 5 or so running simultaneously. Call it; morbid tech curiosity.
High bitrate input video (4K @ 25+ Mbps) transcoded to something small (720 @ 2 Mbps) * Edited this line to correct the stated bitrate
When I did the initial test, it was a mix of higher bitrate videos kicked out to mostly 720 / 1080p at a mix of bitrates. All of the videos had 7.1 TrueHD audio. I think all of that transcoding happens on the CPU.
Yeah. It was an dumb miss. Maybe a UI suggestion would be to move the Unlimited to the bottom of the list below 20? To be fair, itās a nit. I should have seen it. I was hoping that I could bump it to like 35 or something and that was the context of my question.
It looks like the limit of this setup may be about 20. Things are getting slower as I started the last movie. (CPUs?)
I am getting close to maxing out the CPUs and I think this is the Audio transcoding happening. I have more cores to throw at it and I may increase the number I am throwing at this VM later just to see if that changes anything. Iāll leave it as it is for the test youāve asked for.
I am quite happy with the cost / performance of this Arc 380 as a transcoding device. I didnāt think it would be capable of this for $115
Another limit I may run into soon is my NAS. Itās a 4 disk NAS that stores my videos attached via NFS. It does have a couple of SSDs in it for faster read / writes but the sustained output this test requires probably is forcing the reads from the mechanical disks mostly
Iāll run the test you defined as soon as I can tear this one down and start another.
Note for folks reading this:
I am just a dude that works in tech that was curious about how far I could push this setup. My main objectives were to Proxmox Passthrough a Video card to a VM to offload the transcodes so my kids could watch the 4k videos in my library. Iām happy to answer questions about my setup if you have them. I am not an expert in video transcoding though.
If Iāve understood your question correctly: All of the source files were 4k in that test. I was transcoding them down to a variety of resolutions and bitrates under the assumption that one would be likely to see users using different rates depending upon the device they view on.
Thank you for that but itās not what I asked for.
I had requested the SAME FILE be used multiple times.
Using this method, it would be easy to calculate actual input and output bit rates as well as CPU load for audio conversion.
Using various files and reporting āaverageā tells us nothing.
Based on card specs, I can only estimate youāre probably seeing about 120 Mbps video processing capability. How you slice up that 120 Mbps does not matter. It could be 60 sessions at 2 Mbps for all it cares.
I had hoped weād have real-world performance with PMS so others can gauge
If you do get chance to run it⦠When it does fail, See where it stammers ā Which limit is it butting up against. Video, Render, Open/CL ?
The closest file I have to what you are asking for is 43.3 Mbps HEVC. Here are the details:
Test Media Data
Duration 1:32:24
Bitrate 43378 kbps
Width 3840
Height 1608
Aspect Ratio 2.35
Video Resolution 4K
Container MKV
Video Frame Rate 24p
Video Profile main 10
Audio Codec TruHD
Audio Channels 7.1
Codec HEVC
Bit Depth 10
File Size 37.79 GB
I performed the test you asked with that file:
Test Setup
Rebooted System (Guest VM)
Source file 43.38 Mbps - HEVC, HDR
Tone mapping enabled
Start a playback session which transcodes to 20 Mbps 1080p
Wait 20 seconds (get past the opening credits)
Start another session with the same file.
Repeat until the output starts getting jittery / laggy
Test 2 - Results:
everything ran perfectly through 7 simultaneous Transcodes
At 8 - I started to get occasional and very brief pausing and short waits (1-5 seconds). The video would automatically restart. This settled out after a minute and things began to run smoothly without further issues.
Adding a 9th stream increased pausing and caused occasional hangs, forcing a shuffle or transcoder bitrate change to get them re-started. This would then result in another stream pausing.
Comments & Observations:
Simultaneous Transcodes: I would say the effective limit in this set of test conditions is clearly 7 transcodes as adding additional would begin to impact the user experience
IO: Using the same file for all streams in the test removes disk IO as a concern as that files caches to SSDs on the array
CPU: utilization remained low throughout this test and was of no concern that I could tell
Network: Network bandwidth averaged ROUGHLY: In 325 Mbps - Out: 155 Mbps Network wasnāt stressed and the data rates seem in-line with what I would expect
Scenario: It seems that mixed bitrate streams is a more likely real world scenario (at least for my library) and will increase the number of effective simultaneous transcodes as my previous test seems to indicate.
Added Later - Additional Comments on LIMITS:
Limits: Looking at the output of āintel_gpu_topā the limit appears to be in āvideoā
āvideo enhanceā utilization appears roughly 20% below āvideoā in the output
ārenderā & ācomputerā are not indicating as utilized in the output
āVideo0 & 1ā appear to be running at an average of 55% when running 7 streams
Starting new streams jumps these (video) both to 100% for about 15/20 seconds (Assuming this is the engine filling the buffers of clients)
Adding an 8th stream in this test condition causes video0&1 (On intel_gpu_top) to persistently spike to 90%+ with occasional holds at 100% (We appear to be at the limit here)