Calculated Bandwith vs Required Bandwidth

Hi there,

I have been using Plex for some years now and am now opening up my server to a few remote users (family). I have decided to encode my BD Remux’s to a format that is both device and bandwidth friendly.

I have settled on 720p 4Mbps to encode my library to and am currently testing some files through VidCoder (which I am familiar with) with custom settings.

I am using Constant Quality (testing at CQ1, but will be using CQ16 after testing), but constraining the bitrate via VBV-Bufsize and VBV-Maxrate.

I have encoded one test file with three separate VBV settings, and have managed to keep them all below 4000Kbps according to the “Deep Analysis” requiredBandwidth.

I see, however, when I force a transcode (by lowering either the client or server remote quality setting to say 720p 2Mbps), the server logs and client’s on-screen message display a “calculated bandwidth” different to that of the requiredBandwidth.

This “calculated bandwidth” works out to be (roughly) x1.05 of the requiredBandwidth.
Is this correct?

This leads to a problem, as I wish to set and forget my server setting:
Settings > Remote Access > Limit remote stream bitrate to 720p 4Mbps
but unfortunately, this results in a transcode for the 2nd and 3rd encodes (below), whereas the requiredBandwidth says that it shouldn’t transcode…
Any thoughts?

Isn’t the point of the “Deep Analysis” to calculate the requiredBandwidth. Why is this then being calculated again (x1.05)?

Again, where does “calculated bandwidth” come from and why is it more than requiredBandwidth?


CQ1, vbv-bufsize=3600, vbv-maxrate=3600
Remote message="Calculated bandwidth: 3900kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3744”
XML Media requiredBandwidths="3714,3714,3714,3714,3714,3714,3714,3714"
XML Video requiredBandwidths=“3555,3555,3555,3555,3555,3555,3555,3555”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

CQ1, vbv-bufsize=3700, vbv-maxrate=3700
Remote message="Calculated bandwidth: 4006kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3839”
XML Media requiredBandwidths="3815,3815,3815,3815,3815,3815,3815,3815"
XML Video requiredBandwidths=“3655,3655,3655,3655,3655,3655,3655,3655”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

CQ1, vbv-bufsize=3800, vbv-maxrate=3800
Remote message="Calculated bandwidth: 4110kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3939”
XML Media requiredBandwidths="3914,3914,3914,3914,3914,3914,3914,3914"
XML Video requiredBandwidths=“3754,3754,3754,3754,3754,3754,3754,3754”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

Plex Media Server v1.15.4.919
Plex Android App (Mobile) v7.14.1.9954

It’s applying a “safety margin” on top.
Maybe you could use a target bitrate that’s 10% lower or something.

Hi @OttoKerner, I was hoping you would reply, so thanks!

Can you say exactly what that “safety margin” is? Is it x1.05 of the media requiredBandwidth?

I only wish to know, so that I can reverse the calculations and choose the highest possible VBV kbps. I only want to do the encoding process once, so just trying to squeeze as much into the 4Mbps as possible.

As it stands, the VBV-3800 file should Direct Play, as the requiredBandwidth is > 4000kbps.
But unfortunately, I have to use VBV-3600 to stay within the “safety margin”.

(Technically, VBV-3649 would be the absolute limit, if the “safety margin” is x1.05.)
((3649 + 160) x 1.05 = 3999.45)

As a side note OttoKerner, I know you’ve mentioned in other posts that 5MB is the smallest network buffer, depending on the client device.
What does this mean in terms of buffer time? 1sec, 2 sec, etc?

Sorry, I don’t know the exact number anymore.

I can’t tell you, because of course the playing time which fits into the buffer is depending on the bitrate of the video.
You could estimate it, if your videos were encoded with constant bitrate, but you are using constant quality, which means the actual bitrate of a given part of a video can vary.

Thanks for your answers @OttoKerner!

I notice when using the Plex’s “Optimiser” to encode 720p 4Mbps (for Android or iOS for example), Plex uses CQ16, Bufsize 8000 and Maxrate 4000 at Very Fast.
Could this possibly result in the the bandwidth (either calculated or required) being above 4000kbps? Or does the Very Fast preset mean that it will never reach the full capacity of 8000/4000?
(This doesn’t even take into consideration the addition of the audio track)


I think I’ll pin it at 3600/3600 and call it a day.

I just hope that Plex doesn’t increase the “safety margin” in the future…


Extra question: Would it be safe to double the Bufsize of the Maxrate? 7200/3600? Would this always be Direct Playable by a 5MB buffer device?

The ‘very fast’ can be changed under
Settings - Server - Transcoder - ‘Show Advanced’ - “Background transcoding x264 preset”

If you use CQ, the ‘speed’ influences the bitrate of the encode. On “slower” speeds, the transcoder is given more time to test different encoding strategies. Among which it then can pick the most efficient, with the lowest bitrate.

If you use Plex’s mobile Sync, particularly at lower bandwidth (like for small phone screens) it will influence the quality instead, because it uses Constant Bitrate there.
Example: sync at 1.5 mbps at ‘Fast’ is looking atrocious on my phone
A synced episode at 1.5 mbps and ‘Slow’ is very watchable.

Not sure what you are asking. The buffer size is defined by the hardware or the OS of the client. It isn’t something which Plex can influence.
Plex is merely taking the buffer size into account when it decides whether to transcode or not. Whether the video is exceeding the allotted bandwidth or not.
More details here: What is Media Analysis & Do I Need It - #8 by OttoKerner

Hi @OttoKerner.

Thanks again for your replies :slight_smile:

The extra question I was asking was refereeing to the custom VBV settings I’m using in VidCoder to constrain the bitrate.

Currently I’m using 3600 Maxrate with a x1.0 Bufsize of 3600.
My question was, can I push the Bufsize to x1.5 or even x2.0 (of the Maxrate) as Plex is doing (it’s Optimiser is using 8000 Bufsize and 4000 Maxrate)?
I’ve read tonnes of info on using Bufsize and Maxrate to constrain the bitrate, but I couldn’t find a definitive answer, so I stayed with the “safe” setting of x1.0 (instead of x1.5 or x2.0)


Another observation from my testing…

If I set the following options:
Server - Remote Access - ‘Show Advanced’ - “Limit remote stream bitrate” to “4 Mbps (720p)”
Client’s Quality setting to “Maximum” (both Home and Remote)

(Play from remote network)
The 1st encode Direct Plays, but the 2nd, 3rd and 4th all transcode.
This occurs, because the 1st encodes “calculated bandwidth” (requiredBandwidth x 1.05) does not exceed the 4000Kbps limit, but the 2nd, 3rd and 4th encodes “calculated bandwidth” (requiredBandwidth x 1.05) do exceed the 4000Kbps limit

If, however, I set the following options:
Server - Remote Access - ‘Show Advanced’ - “Limit remote stream bitrate” to “Original (No Limit)”
Client’s Quality setting to “4Mbps, 720p (High)” (both Home and Remote)

(Play from local or remote network)
The 1st, 2nd and 3rd encodes Direct Play, but the 4th transcodes.
This occurs, because the 1st, 2nd and 3rd encodes requiredBandwidth does not exceed the 4000Kbps limit, but 4th encodes requiredBandwidth does exceed the 4000Kbps limit

Is this behavior intended or expected?
I assumed, whether you set the quality at the server side, or client side, the behavior should be the same?


CQ1, vbv-bufsize=3600, vbv-maxrate=3600
Remote message= "Calculated bandwidth: 3900kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3744”
XML Media requiredBandwidths="3714,3714,3714,3714,3714,3714,3714,3714"
XML Video requiredBandwidths=“3555,3555,3555,3555,3555,3555,3555,3555”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

CQ1, vbv-bufsize=3700, vbv-maxrate=3700
Remote message= "Calculated bandwidth: 4006kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3839”
XML Media requiredBandwidths="3815,3815,3815,3815,3815,3815,3815,3815"
XML Video requiredBandwidths=“3655,3655,3655,3655,3655,3655,3655,3655”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

CQ1, vbv-bufsize=3800, vbv-maxrate=3800
Remote message= "Calculated bandwidth: 4110kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“3939”
XML Media requiredBandwidths="3914,3914,3914,3914,3914,3914,3914,3914"
XML Video requiredBandwidths=“3754,3754,3754,3754,3754,3754,3754,3754”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

CQ1, vbvbufsize=3900, vbv-maxrate=3900
Remote message="Calculated bandwidth: 4216kbps"
XML deepAnalysisVersion=“3”
XML Average bitrate=“4041”
XML Media requiredBandwidths="4015,4015,4015,4015,4015,4015,4015,4015"
XML Video requiredBandwidths=“3855,3855,3855,3855,3855,3855,3855,3855”
XML Audio requiredBandwidths=“160,160,160,160,160,160,160,160”

Plex Media Server v1.15.4.919
Plex Android App (Mobile) v7.14.1.9954

The values for requiredBandwidths come from simulating a client’s buffer with a linear playback, constant receive rate, and a certain client-side buffer size. The values there are the absolute minimum receive bitrate that will not cause the buffer to under-run. A larger buffer provides a better smoothing of peaks which is why on your typical VBR media the numbers will decrease across these values. Audio is often constant bitrate which is why it is often the same value.

These numbers do not account for the container which can range from little to a significant overhead (MPEG2 TS being such an example). For lack of a better estimate, the bitrate is increased by 5% to account for this overhead.

Worth noting, your bitrate settings are the video bitrate and doesn’t count the audio nor the container overhead.

2 Likes

Thank you for the explanation @gbooker02 , it’s much appreciated!

I did not know that different containers had different amounts of overheads.
This makes perfect sense of the requiredBandwidth x 1.05 I found.

What it does not explain, though, is why the 5% is only added when the ‘Quality Limit’ is applied server side, and not client side. Any thoughts?

I absolutely understand that I am asking about video bitrate at the moment, and that audio gets added on top to result in the entire file’s “required bandwidth”.
I just did not take into consideration the container overhead.

I am encoding to MP4, so 1 x video stream (burnt subtitles), 1 x audio stream, chapters added.
Do “chapters” embeded in an MP4 take up differing amounts of bitrate, or is it set within the container overhead?

I’m not sure what you are referring to here. Though it’s likely a case where the logic is not perfectly replicated in all clients which is part of the reason why we made the server the final authority in many of this situations (one thing to fix when it is wrong instead of n clients).

MP4 has one of the lower overheads but we don’t take into account different containers ATM in calculating overhead. Chapters are done in the initial read before any significant buffering takes place and they are tiny. They typically only contain a time-code and a title which means all the chapters together likely take up a few kB at most.

I was referring to the below, which I stated earlier.
Would be interested to know your thoughts (perhaps the x1.05 is just not implemented in the Android App as you mentioned yet)…


Thanks for this explanation @gbooker02, I appreciate the details.

Were you trying to play/stream same file if so and it all depends on client and remote connection bandwidth. Even for broadband when wired or wireless netflix takes some time say 1-2 min to get full HD or even UHD.

for your 1-4 if all devices are same and on 4g network service provider. Then it should not transcode . Provided you set upload unlimited then it should not throtle at all. Most countries upload is 1/10th than download say 100Mbps only 5-10Mbps is upload .

I’m not sure why the limit set in the client vs server would be different in that case. I would have to dig into it at some other point but it could be a while before I do. In the mean time, if you could capture:

  • Server logs containing at least the point where the playback is first started to when playback actually starts (this contains the decision process) when you are using the client limit. This will help me to make absolutely certain what the client is sending in this case.
    • Debug level, not verbose.
    • Would be helpful to have this for all four items but not a necessity.
    • Tell me the approximately time (wall clock time to the second if you can) each of your tests are done and which test it is. This ensures I’m looking at the correct playback in the logs.
    • Would be helpful to capture logs when the server is quiescent (no one is playing anything and your tests are the only activity).
  • The full XML info of the four items you are testing with. Since you quoted the requiredBandwidths earlier and that comes from this XML, I assume you know exactly what I’m talking about here.

Hi @gbooker02

I have captured the server logs and wall clock time of playback for each file, as well as the XML. Do I just PM these to you?

I have done these tests on my local network (as I can’t test a real remote network at the moment), but have forced the client out of the LAN by excluding it from: Server - Network - ‘Show Advanced’ - “LAN Networks”
Does this suffice?

PMing them to me would be fine.

That is not related to bandwidth controls. You want the one titled LAN Networks.

Apologies, I meant “LAN Networks” (edited above post).

I set the Server - Remote Access - “Limit remote stream bitrate” to “Original (No Limit)”
I set the client’s Quality - Remote Streaming to “720p HD (High)”

The 1st encode (VBV-3600) was started at 7:37:00 am - Direct Play
The 2nd encode (VBV-3700) was started at 7:38:00 am - Direct Play
The 3rd encode (VBV-3800) was started at 7:39:00 am - Direct Play
The 4th encode (VBV-3900) was started at 7:40:00 am - Transcode

I trimmed the server log. Let me know if you need anything more.
I hope it helps!

I’ll add this to the internal issue. It looks like I have what I need for when I get to it (which will be a while).

Glad I could help @gbooker02

For me, there’s no rush for a fix at all, it was just something I observed.

Can you tell me though, are you planning to make the Android client (and all others) add the 5% on top of the “requiredBandwidth”, or will you be removing the 5% from the server side calc?

Thanks for the reply @Dirtymacho

In this thread, I’m not talking about real-world required bandwidths to make things stream correctly.

I have 1000/500Mpbs internet speeds and my remote users ~12/2Mbps.
So a 720p 4Mbps real-world stream should be no problem.

I am asking specifically about the requiredBandwidth that Plex determines when it carries out it’s “Deep Analysis”. And how this didn’t match the "calculated bandwidth in the server logs. And how this forced a transcode, when it should have direct played.


The end result, was that sometimes (and sometimes not) a 5% “safety margin” is added on top of the “Deep Analysis” requiredBandwidth, which can be the making or breaking of a Direct Play.

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