I have an Arc card so I can hardware transcode an AV1 library for devices that don’t support AV1. There is no expectation of a transparent transcode. Why is Plex targeting a bitrate of 21Mbps for a 1.5Mbps source?
The target bitrates are pretty generic defaults for delivering “good enough” quality at the selected resolution when doing realtime encoding.
It simply doesn’t consider the source bitrate when choosing a target, because the source bitrate is pretty irrelevant. A lower-bitrate source doesn’t imply a lower-bitrate output - if anything, a higher-quality source is more likely to deliver a lower-bitrate output.
So is it your opinion that transcoding a 1080p source to 21 Mbps for remote streaming is a good general default then?
”A lower-bitrate source doesn’t imply a lower-bitrate output - if anything, a higher-quality source is more likely to deliver a lower-bitrate output.” This conflates bitrate with quality though, sorry to nitpick. I’d call these high quality and low bitrate 1080p.
We begged and pleaded for over 5 years to raise the default bandwidth cap in the apps from 4 Mbps. I see now that in other threads it has been suggested that 21Mbps transcoding is a feature and not a bug, and that makes me want the person(s) behind this decision to explain this choice in detail. The more simple explanation is that it is a bug or oversight in low-bitrate AV1 transcoding that is being framed as a choice by folks on the forum without even consulting the person(s) who ‘decided’ this. It seems like an assumption and maybe that is preventing the transcoding team from realizing this issue. We have no ticket system now so the forum is the gatekeeper of bug reports getting to devs?
It would be nice to at least know if they know. They may not be playing AV1 video to devices that need transcoding with a GPU, that may not be on their test bench.
Could we get some kind of confirmation on this from the transcode team, please? And maybe a better explanation?
I tried an AV1 encode that is at 6.7Mbps. Plex chooses to try to transcode to 81.6Mbps.
1.5Mbps AV1 > 21Mbps
6.7Mbps AV1 > 81.6Mbps
I think that assuming this is by design is an insult to the decision making of the devs. I think it would be helpful if there is a consensus that this is a bug and not a feature, it would help to get this in front of the transcoding team. This is likely a very simple thing to fix.
And this is simple.
It was meant to be:
1.5Mbps AV1 > 2.1Mbps
6.7Mbps AV1 > 8.2Mbps
A decimal mistake.
It’s working in a reasonable way already. It just doesn’t make sense to consider source bitrate when choosing a target bitrate.
I have 100Mbps source files that trivially compress to 2Mbps with very little loss of quality. I have 4Mbps AV1 source files that require almost 20Mbps to be watchable as AVC.
Input bitrate doesn’t imply very much about what the transcode output bitrate requirements will be. The assumption that “small AV1 == small transcode” doesn’t hold.
That’s why there are knobs to adjust size and quality at playback time. I wish there were more options, but that’s a different discussion.
1.5 Mbps 1080p to 20Mbps HEVC transcode is not reasonable. I do appreciate the reply. I may make take the time to make screenshots at different bitrates if that would help it get in front of the devs. I am certain of this though, 3-5 years from now I will have these same files and Plex will be transcoding them to 5Mbps or less, by default. There is a decimal error or a bug that is causing the transcode to be 10x intended, and the Plex official documentation supports that view.
So, what should the considerations be? What are the variables that plex is using to decide? Are you suggesting that Plex is assessing perceptual quality score in some way before starting a transcode? I’m interested. The logic would still be obviously broken but I assumed Plex’s transcoding bitrate target decisions is less complex.
https://support.plex.tv/articles/115002178853-using-hardware-accelerated-streaming/
”a good rule of thumb is it will generate the same resolution as a h.264 transcode at 1.5x the bitrate”
This contradicts what you are saying though and I tend to agree with the Plex documentation. The codec and the bitrate of the source, hardware or software transcode, and the target codec are all we can go on to decide target bitrate. I realize the writer of this may be wrong along with me, and I’d still be impressed if Plex has another metric for deciding, like VMAF scores?
I’m at a loss. Someone liked your post other than me, so it seems like they share your opinion. I am still just certain that it’s a bug that people are trying to rationalize.
The rest of that bullet on the support page:
HEVC transcoding will result in a better quality at the same bitrate. For example 1.5 Mbps will result in a 720p video instead of 480p. (a good rule of thumb is it will generate the same resolution as a h.264 transcode at 1.5x the bitrate)
That’s saying that HEVC output can match AVC output quality at lower bitrate, or can deliver higher resolution at the same bitrate.
But it’s only talking about output; it’s making no comparison with input. Nothing on that page discusses input and output bitrate being related.
Remember that transcoding doesn’t mogrify the original file, it’s a shortcut word for “decode, then encode”, two steps.
It first fully decodes the stream into a series of 30 (or whatever) full-quality, full-color, full-resolution pictures per second. It doesn’t matter if the original was 1Mbps or 100Mbps, the decoded stream of pictures is a full-bandwidth, full-quality, absolute firehose of uncompressed pixels in memory.
It then does a completely fresh encoding of that firehose. The encoder is blind and ignorant to how it received the firehose of pixels - perhaps it was freshly recorded, or rendered, or freshly ripped from a disc. Or perhaps it came from a once-compressed stream. But the encoder is configured for an output resolution and output quality or output bitrate, and the encoder gets on with its job.
The transcode log suggests that Plex is targeting a fixed bitrate for the hardware transcoder. I don’t see CRF settings, I see a target bitrate. Is that wrong?
If Plex isn’t considering source bitrate when setting transcode targets, what is it using? A fixed bitrate target regardless of source quality/bitrate could result in either massive waste (transcoding 1.5 Mbps to 21 Mbps) or quality loss (transcoding a 50 Mbps source to the same 21 Mbps default).
Please consider this conflict with some of your arguments: 1.5Mbps AV1 > 21Mbps and 6.7Mbps AV1 > 81.6Mbps. This clearly suggests Plex is considering something about the source, just with what appears to be a 10x+ multiplier. If these were truly resolution-based defaults, you’d expect the same output bitrate for both 1080p sources, no? What is the variable I am missing, Volts?
You’re correct that the encoder receives a “firehose of pixels,” but those pixels contain only as much visual complexity as the 1.5 Mbps AV1 source preserved. “The encoder doesn’t know the source” doesn’t help me when remote streaming requires a 14x bandwidth amplification on my upload.
Either Plex should be using quality-based encoding that adapts to content complexity, or it should have sensible bitrate caps, and with the exception of this case, it does. That is what leads me to believe this is not intended. I have seen no other codec combinations where Plex comes close to deciding on 10-15x bitrate transcodes.
I think that AV1 is still fringe and this passed QA because it works. I think that the transcode team/devs are not aware and that they won’t see this thread. I think I’m just a year or two too early.
I’m seeing the same thing since updating the server (before the update was pulled)
edit - turned off HEVC encoding (experimental) and back to normal with no massive increase in bandwidth
20Mbps from a 1.5 Mbps file is now 1.5 Mbps from that file.
Please consider this conflict with some of your arguments: 1.5Mbps AV1 > 21Mbps and 6.7Mbps AV1 > 81.6Mbps. This clearly suggests Plex is considering something about the source, just with what appears to be a 10x+ multiplier. If these were truly resolution-based defaults, you’d expect the same output bitrate for both 1080p sources, no? What is the variable I am missing, Volts?
Can you share those files with me? I’m curious too. I’m wondering if there’s some other difference in the source files, and if the same behavior happens with software-based transcoding.
Are you seeing the output stream actually IS that high bitrate, or just that the encoding session is configured to allow that much? Software encoders usually won’t just waste bits unnecessarily to fill a target bitrate, but I don’t know how the hardware encoders behave here.
