Software Transcoding Bottleneck

Server Version#: 1.21.0.3616
Player Version#: Web 4.43.4

I know it’s not recommended to transcode 4K HDR content, but I thought I’d try it out with the new tone mapping feature and ran into an odd issue. To explain a bit of background, I’m running Plex Media Server on an Ubuntu 20.04 Virtual Machine on a Hyper-V host. The Hyper-V host has two Intel® Xeon® CPU E5649 @ 2.53GHz. I’ve configured the Plex VM to have access to all 24 threads across both NUMA nodes. The VM has 16GB of RAM assigned to it and the Plex Transcoding directory is on a RAID 10 SSD array.
When transcoding a 4K HDR UHD Blu-Ray rip I’m only getting about 30-40% CPU usage across all cores/threads with no thread being above 70% utilized. (Perhaps this is a misconfiguration with my virtual machine settings.) The problem is transcoding can’t keep up, if I pause and allow the transcoding to buffer I’m able to watch, but real-time transcoding is impossible. Does Plex’s transcoding not use all the available resources? Is this just a non-ideal setup for CPU transcoding? Am I asking the right questions?

Not everything can be parallelized. Although that CPU is very “wide” it isn’t very “fast”.

I wouldn’t expect this to work.

I would expect it to be loud and make a lot of heat, however. :slight_smile:

Transcoding with tone mapping in a VM??

This requires the llvm on the bare metal.

I was under the impression video rendering was one of those tasks that is easily parallelized.

You’ve got that right. :stuck_out_tongue_winking_eye:

I understand it’s not ideal, just working with what I’ve got.
Also, from my understanding a VM really only incurs a performance pentantly of a few percent?

Simple software-based transcoding can be parallelized pretty well. I’m not sure spreading across two CPU dies and letting hyperthreading mix things up is going to buy you very much, though. I bet it’s 95% as fast with a single processor and less churn.

The new computation engine for HDR->SDR tonemapping requires direct access to the hardware, and that isn’t available in a VM. It’s not about the small virtualization penalty for general-purpose computation.

1 Like

I wonder, if you had the right iGPU, if you could pass it through the VM and if the Intel OpenCL stuff would work. But you don’t. (Your CPUs aren’t as old as mine, by the way …)

I also suspect you could add an Nvidia card and pass it through to a Linux guest.

But a modern Core i3 machine would probably outperform either of those as a Plex Server. :slight_smile:

1 Like

Since storage space isn’t an issue I just optimized one of my 4K RIPs to original quality and the server is able to keep up transcoding optimized version easily. With the tone mapping now functional this seems to best way forward without purchasing more hardware.

1 Like

When you Optimized, was HDR preserved?

HDR isn’t preserved, but it is successfully tone mapping.

The input video file:

  • Codec HEVC
  • Bitrate 47415 kbps
  • Language English
  • Bit Depth 10
  • Chroma Subsampling 4:2:0
  • Coded Height 2160
  • Coded Width 3840
  • Color Primaries bt2020
  • Color Range tv
  • Color Space bt2020nc
  • Color Trc smpte2084
  • Frame Rate 23.976 fps
  • Height 2160
  • Level 5.1
  • Profile main 10
  • Ref Frames 1
  • Width 3840
  • Display Title 4K (HEVC Main 10 HDR)
  • Extended Display Title 4K (HEVC Main 10 HDR)

Output video file:

  • Codec H264
  • Bitrate 39206 kbps
  • Language English
  • Bit Depth 8
  • Chroma Location left
  • Chroma Subsampling 4:2:0
  • Coded Height 2160
  • Coded Width 3840
  • Frame Rate 23.976 fps
  • Height 2160
  • Level 5.1
  • Profile main
  • Ref Frames 4
  • Stream Identifier 1
  • Width 3840
  • Display Title 4K (H.264)
  • Extended Display Title 4K (H.264)

I think it’s the fact it’s a H.264 encoded video is why the server is actually able to transcode it in real time.

Edit: file sizes
4K HDR H.265 Original: 49.50 GB
4K SDR H.264 “Optimized”: 40.90 GB

1 Like

I misunderstood - but that’s even better, in some ways.

I’m surprised tone mapping was performed during optimization!

That’s great news, thanks.

I’ve changed the background transcoding option from Medium to Very Slow and now the files appear to be half the size. (Though this could just be how different movies are able to compress differently?)

I haven’t tried watching them on a TV, but on a 27" 1440p monitor they look very good to my eye.

This also makes each movie take over 24 hours to process… :joy:

Different movies compress differently. And the presets make a big difference in output file size.

FFmpeg preset comparison x264 2019; Encode speed and file size

I only spend the extra time if I’m planning to keep the encoding. If it’s temporary … veryfast.

1 Like

I don’t have the hardware for real-time transcoding with tone mapping either.

I also tested Plex’s Optimize... on a couple of sample HDR10 files.

The colors aren’t flat and dead, so it’s a big improvement. Usable in a pinch. Thanks, Plex!

But it’s also not pretty. Colors are nuts and oversaturated, and highlights are badly blown out.

My impression is that it’s not fully implemented and tuned for software-only Optimize....

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.