Excellent
Anyone have thoughts on how to scale the new bitrates? I’m thinking HEVC bitrates = 2/3 h.264 bitrates
1 Like
Hi Chuck, thanks for helping out.
I am not sure where I can put these variables in my Proxmox LXC config.
This is what it currently looks like in order to get the general hardware decoding and transcoding working. But this does not show the GPU in the dropdown, so I do not get the new HEVC checkboxes.
I have been searching all over the internet for days to figure out a solution but have not found any information yet.
arch: amd64
features: fuse=1,mknod=1,mount=fuse,nesting=1
hostname: nick-plex
memory: 4096
mp0: /nickarray,mp=/nickarray
mp1: /mnt/friends,mp=/mnt/friends
net0: name=eth0,bridge=vmbr0,gw=10.0.0.254,hwaddr=66:DB:E9:99:12:C4,ip=10.0.0.14/24,type=veth
onboot: 1
ostype: ubuntu
rootfs: ssd:107/vm-107-disk-0.raw,size=100G
swap: 0
lxc.hook.pre-start: sh -c '[ ! -f /dev/nvidia-uvm ] && /usr/bin/nvidia-modprobe -c0 -u'
lxc.environment: NVIDIA_VISIBLE_DEVICES=all
lxc.environment: NVIDIA_DRIVER_CAPABILITIES=all
lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 511:* rwm
For me, it was lxc config edit nvidia
Comparable for you would be pct config edit <container_name> ??
Hi Chris,
I’d recommend the following for HEVC:
320-700 Kbps SD
1, 2, 3 Mbps 720p
4, 8, 10 Mbps as 1080p
15, 20, 50 Mbps as UHD
Assuming you want to keep a pattern of 3 options for each raster.
EDIT: 2/3 h.264 bitrates is probably solid, especially as the transcoder is in hardware vs software.
1 Like
I mean I know how to edit the config, but I have no idea how to specify those settings.
I posted the current config of my LXC.
I tried stuff like:
lxc.environment: nvidia.require.cuda: “true”
lxc.environment: nvidia.runtime: “true”
lxc.environment: NVIDIA_REQUIRE_CUDA=“true”
lxc.environment: NVIDIA_RUNTIME=“true”
lxc.environment: NVIDIA_REQUIRE_CUDA=true
lxc.environment: NVIDIA_RUNTIME=true
Trying all variations, none of that makes any difference, the GPU still does not show up in the dropdown.
It’s just frustrating because the GPU is working to do transcoding just fine. It’s just a new requirement now to lock the HEVC checkboxes behind the dropdown which was never needed before for GPU transcoding.
I will keep searching. Hopefully someone can find a solution.
@SirMaster have you tried all 3 settings chuck mentioned in his origonal post?
What do you mean by “tried all 3 settings”?
I feel like you aren’t reading my posts. I have been very detailed about what I have been trying.
You mean:
nvidia.driver.capabilities: all
nvidia.require.cuda: "true"
nvidia.runtime: "true"
I have litterally been talking about these my past few posts.
“nvidia.driver.capabilities: all”
Is clearly already specified in my container config via:
“lxc.environment: NVIDIA_DRIVER_CAPABILITIES=all”
The other 2 I have no idea how to specify in the Proxmox LXC container config. I showed exactly what I tried adding to the config and said those trials did not do anything.
1 Like
Hi Chuck, can you be more explicit with your suggestion? In what file did you add these lines? I have tried adding these to the LXC config file for my Plex container and it throws errors:
unable to parse config: nvidia.driver.capabilities: all
unable to parse config: nvidia.require.cuda: "true"
unable to parse config: nvidia.runtime: "true"
I have also tried setting environment variables for these settings with no luck either:
lxc.environment: NVIDIA_VISIBLE_DEVICES=all
lxc.environment: NVIDIA_DRIVER_CAPABILITIES=all
lxc.environment: nvidia.require.cuda=true
lxc.environment: nvidia.runtime=true
Can you share your PVE containers conf file?
2/3 or even 3/4 could make sense depending on how people felt about the current settings and if they wanted to tip the scale a little higher in quality while still saving bandwidth.
Fibonacci seems actually pretty reasonable:
1 Mb/s 480p
2, 3 Mb/s 720p
5, 8 Mb/s 1080p
13 Mb/s 1440p
21, 34 Mb/s 2160p
-
My Nvidia is on my workstation. LXD / LXC containers
-
This is container config for my Nvidia container.
– I can create a default profile to assign to any container if I want (next to do)
### This is a YAML representation of the configuration.
### Any line starting with a '# will be ignored.
###
### A sample configuration looks like:
### name: instance1
### profiles:
### - default
### config:
### volatile.eth0.hwaddr: 00:16:3e:e9:f8:7f
### devices:
### homedir:
### path: /extra
### source: /home/user
### type: disk
### ephemeral: false
###
### Note that the name is shown but cannot be changed
name: nvidia
description: ""
status: Running
status_code: 103
created_at: 2024-08-29T16:02:41.343634473Z
last_used_at: 2024-09-23T20:55:34.702133585Z
location: none
type: container
project: default
architecture: x86_64
ephemeral: false
stateful: false
profiles:
- default
config:
image.architecture: amd64
image.description: ubuntu 22.04 LTS amd64 (release) (20240821)
image.label: release
image.os: ubuntu
image.release: jammy
image.serial: "20240821"
image.type: squashfs
image.version: "22.04"
nvidia.driver.capabilities: all
nvidia.require.cuda: "true"
nvidia.runtime: "true"
volatile.base_image:
For my Prox box, tell me what to type please (yes, I’m that noobie on Prox)
If this tells you what’s needed for everyone , please share
First off, I’m not going to pretend I know what’s best for any of this stuff, So Im good with whatever the scale is as long its better than x264 for the same amount of bitrate.
But anyway, I’ve been using 4mbps for the longest time because it divides just right (With a nice bit of headroom) between the amount of users I share with & my total upload bandwidth. But since we’re hear making changes to the transcoder 
, Could I be cheeky & possibly request a 6mbps option? The jump from 4-8 is quite big, & a 6mbps HEVC transcode at 2/3 of x264 (9mbps) would be 
Thanks
1 Like
Unfortuantly that would require client changes. We are going to be re-doing how quality is done once the client devs are more free so you will likely need to wait until then for that change.
1 Like
It would be incredible if server operators could just specify a list of bitrates and their associated resolutions.
But this is probably a complete pipe dream…
1 Like
It’s a great idea but there would, unfortunately, be those who don’t have any idea what they’re doing and say things like “Plex looks like CRAP! I set 2Mbps @ 4K”
I can see where updating the current table makes sense (and will happen as Chris stated) but giving free reign is only going to cause chaos and make support a logistics nightmare.
How about we meet in the middle and update the table?
5 Likes
I was about to raise the same issue but after trying ffprobe I’m seeing the same thing - thanks for posting! I wonder if this is related to the issues we’re seeing with the resolution being reported incorrectly based on the transcoded bitrate… As Plex used h.264 previously I guess it was safe to assume that any transcode was going to be 8-bit SDR.
One strange thing is that when I’m transcoding an AV1 HDR10 file I’m only getting hardware encoding, not decoding. This always used to be the case because of the 10-bit to 8-bit conversion but I was hoping with HEVC the full transcode would be done in hardware. When using ffmpeg manually to transcode the same file to HEVC it uses nvdec and nvenc and barely touches the CPU:
ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -c:v av1_cuvid -i input.mkv -c:a copy -c:v hevc_nvenc -b:v 5M output.mkv
I’ve noticed that when transcoding the same video file with PGS subtitles, using AVC encoding leverages hardware-accelerated subtitle burning — a recent optimization from Plex. However, when I switch to HEVC encoding, it seems that subtitle burning reverts to CPU processing instead of being GPU-accelerated.
Not sure I can properly answer but here are my thoughts:
(btw, so glad you found the code that was controlling resolutions and nice to see SwiftPanda16 chiming in too).
I’ve been converting my libraries to HEVC using Handbrake and only CPU (no GPU or iGPU) to optimize quality with lower bitrates. I usually convert audio to AAC (stereo) and AC3 (5.1).
The biggest problem in determining the resulting bitrate of HEVC output is usually video noise.
Now, Plex transcoding comes at it differently than I do. My goal is to reduce file size with acceptable loss of video quality. I’m also trying to balance that with optimizing bitrate for hopeful direct play. So, my simple equation is: smaller file size means less overall data to send in total timespan of movie/episode being played. I shoot for 3-6Mbps bitrates because of my bandwidth limitations, and lower is even better. I’ve found those bitrates quite suitable for 1080p. Plex transcoding, on the other hand, has a proper goal of trying to place a bitrate ceiling (I’m assuming constant bitrate) on a stream and hope for the best in quality.
My movie library contains a large number of pre-1964 movies (“classics”), more than most Plex admins, but my post-1963 is larger than the pre-1964. I tend to run into noise more often because of this.
My Tautulli is reporting these bitrates for most of my content:
<1-1.5 = SD,480p
1.5-2 = 720p
2-3 = 1080p low (low, mid, high are subjective)
3-5 = 1080p mid (this is a great sweet spot between quality and bitrate/file size)
5-8 = 1080p high
8+ = 4K (I do very little 4K)
Some items in my libraries don’t fit these, but again they are usually very noisy.
1/2 to 2/3rds is probably in the ballpark but I haven’t played with constant bitrates much.
Once we all have 500+Mbps upload capabilities on our bandwidth, I don’t think Plex is going to be doing much transcoding. Even 20 simultaneous streams (I come nowhere close to that and am using it as an exaggeration) would still allow 20+Mbps streaming. That should be plenty for decent 4K for your friends to run their 200" movie screens (who should instead have their own Plex servers). 
1 Like
@MUGENG so thats actually expected behavior in some circumstances as none of the hw devices support overlaying on top of 10 bit data so we have to use sw. That being said:
A) I have modified the behavior so this only applies when transcoding to a 10 bit format instead of all HEVC transcodes
B) You will still be able to take advantage of HW encoding, decoding, scaling, tonemapping ect, only the overlay will be sw based
2 Likes
I was always under the impression that a similar-quality HEVC would be about half the size of a 264.
So if the the resolution will still be just a “looks like” ballpark, then keeping the resolutions the same with half the current listed 264 bitrates would seem to make sense.
