Understanding bit-rate discrepancies between server and client

So I was doing some tests last month and unfortunately I lost some of the data I recorded, but I was seeing some discrepancies between client and server that I can’t explain and I’m hoping I have enough data here that someone can give me an idea of why I might be seeing these things.

Example/Issue #1
I was streaming via the web client I chose the following from the quality drop down:

  • Original (6.7 Mbps, 1080p HD)

But, when streaming at this quality on the client, the server dashboard reported it was streaming:

  • Remote (XX.XX.XX.212)—11 Mbps. Video - Direct Stream, English - AAC Transcode

When looking at the media bitrate on the file info in Plex it showed the bitrate was ~6700.
So, the question is:

Why does/did the server show it was streaming at 11Mbps when the file itself and the quality selected was original 6.7Mbps?

Example/Issue #2
I see that on Plex’s file info there are multiple places that bitrate is reported.
One is under the “Media” section (a particular file says 6739 kbps) and also there are bitrates listed under the “Codec” section. It appears that the “Media” bitrate is all the “Codec” bitrates added up? Is this correct…? It makes for some misleading/confusing reporting.

I have one episode with a Media bitrate of 10,128 mbps, but if you look at the Codec rates they are like this:

  • H264 (Video) - 5,000 kbps
  • AAC - 128 kbps
  • EIA_608 - 5,000 kbps - Unknown (Closed Captions)

I don’t really understand the EIA track…that much bitrate for CC seems very high, no?
But the overall point is this:

The client will report playback at “Original 10mbps”, but the option the server only shows it playing back at 5mbps.

It would seem that the bitrate given under “Play original quality” is not an accurate number as that would be the bitrate needed to playback *every * track in the file simultaneously, not necessarily the actual tracks being played.

Furthermore if I select the EIA track for playback the client no longer gives me an option for “Original Quality” but instead now lists a “Maximum Quality” option of 10mbps. When I select that the server still only says it is streaming at 8mpbs.

I’m not sure how much of this is my misunderstanding how things work and how much of it are issues with Plex, if even just display bugs.

Hoping someone can enlighten me.

This means the original file has an average bandwidth of 6.7 mbps.
However, no video file has a constant bandwidth.
There are peaks and valleys. Plex is performing a detailed bandwidth analysis (if you let it), where it determines the height and duration of the peaks and thus, the real required bandwidth to stream this file in real time.

See What is Media Analysis & Do I Need It - #8 by OttoKerner for more detail info.

This is a red herring. The EIA_608 closed captions are encoded into the video track in a special way, so that it is impossible to determine their bandwidth separately from the video. (they probably have a bandwidth of a few kilobytes/s)

1 Like

Thanks @OttoKerner for that explanation, some clarification if you don’t mind:

  1. So I understand that the average is 6.7 mbps, but I kept an eye on the dashboard and it never changed from claiming it was streaming at 11 mbps. I could understand your explanation if the dashboard info constantly fluctuated between say 4-15 mbps, but why are the client and server disagreeing so much? IOW, it doesn’t seem that the server is reporting what it actually is playing at (since it never changes from 11), but rather some number that it calculates as an average which is different than what the client shows. After all, when I choose the “Original 6.7 Mbps” from the client, isn’t it getting that from the server data and if so, why doesn’t the server show that number as well?

  2. So can we say that Plex doesn’t necessarily handle EIA tracks well and therefore some display bugs may exists? I’m still curious of the change between being able to select “Original Quality” when not using this track vs only being able to choose “Maximum Quality”. Does this have to do with EIA track having to be transcoded in a way that the file can no longer be considered “Original” as far as directstream/play go?

I’ll read the article you mention (although I believe I previously consulted it I’ll check again)!

Also I’d like to ask if I should still be seeing this if “Perform extensive media analysis during maintenance” is enabled.

It is on my server and while I don’t have specific info on the file I experienced this with on hand, I know for sure this file had sat on my server for weeks prior to me experiencing this issue. Is there a way when I see this discrepancy on the future to determine if extensive analysis was done on this file and if so why it might still report a discrepancy?

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