PMS Can't Detect MKV Audio Bitrate Info

Plex Media Server
1

Server Version#: 1.20.5.3600

MKVToolNix (and possibly FFMPEG) changed the way it formats audio bitrate metadata for the MKV container. It used to format it as such:

Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default)
    Metadata:
      BPS             : 640000
      BPS-eng         : 640000
      DURATION        : 00:00:10.016000000
      DURATION-eng    : 00:00:10.016000000
      NUMBER_OF_FRAMES: 313
      NUMBER_OF_FRAMES-eng: 313
      NUMBER_OF_BYTES : 801280
      NUMBER_OF_BYTES-eng: 801280
      _STATISTICS_WRITING_APP: mkvmerge v19.0.0 ('Brave Captain') 64-bit
      _STATISTICS_WRITING_APP-eng: mkvmerge v19.0.0 ('Brave Captain') 64-bit
      _STATISTICS_WRITING_DATE_UTC: 2019-10-19 07:42:39
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-10-19 07:42:39
      _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

However somewhere along the line it started simply using:

Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default)
    Metadata:
      BPS-eng         : 640000
      DURATION-eng    : 00:01:00.000000000
      NUMBER_OF_FRAMES-eng: 1875
      NUMBER_OF_BYTES-eng: 4800000
      _STATISTICS_WRITING_APP-eng: mkvmerge v38.0.0 ('The Silent Type') 64-bit
      _STATISTICS_WRITING_DATE_UTC-eng: 2019-10-18 18:01:58
      _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Plex has been unable to parse the new metadata format (with no BPS field) for at least the EAC3 and AAC audio codecs (all I’ve tested). This may not seem like a big deal but the “streaming brain” does not handle that blank field well and assumes some kind of default 10,000mbps value anytime the transcoding decision making process is invoked with that blank field

This causes a lot of transcodes that otherwise wouldn’t be necessary. If you have overall or per-stream upload bandwidth limits set it will almost always trigger a transcode. Some Plex clients (Android/Fire TV) also have a hidden device side limit of 200mbps. Not having audio bitrate info triggers an uncessary video transcode on those devices anytime it would otherwise only need to Direct Stream or perform an audio-only transcode

I’ve been troubleshooting this issues since it first appeared in 2018 so I’ve built up a fairly good understanding of how to work around it. I’ve contacted a few employees over that span so I hope it’s already on your guys’ radar. If not I hope this post can serve as a gentle reminder and a PSA for anyone else that may be experiencing transcoding behavior that doesn’t make sense

Edit: @OttoKerner makes a good point that I should have specified that this is with Deep Analysis disabled (or before the nightly maintenance has had a chance to process even if you do have it enabled)

Edit2: If you use FFMPEG (instead of MKVToolNix) it creates an MKV with audio metadata as such:

Stream #0:1: Audio: eac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
    Metadata:
      ENCODER         : Lavc57.107.100 eac3
      DURATION        : 00:00:30.016000000

It is similarly not parsed properly by Plex and also results in a blank “Audio Bitrate” field upon initial analysis. In both cases Mediainfo is indeed able to parse the info correctly. It’s likely just a simple issue of Plex goofing the parsing logic a bit when they switched away from Mediainfo to read the file’s metadata. Hopefully an easy fix :crossed_fingers:

2

That seems like it could be related to the issue discussed here.

'bitrate' value missing in 'media_streams' table for MKV media audio streams since 1.19.3.2852 Update - Causes Content couldn't be Played in Remote Web Player

What’s your workaround?

Edit: From the horse’s mouth:

Reddit - Dive into anything

Interesting! Knowing him, he might add it back if you demonstrated a compatibility reason.

2 Likes
3

That’s exactly the issue! I appreciate the links. Glad to see you were able to get some traction, it makes me optimistic that we’ll finally see a fix

Here’s the now locked thread where I went through a similar troubleshooting process with some other Team Members:

Plex Incorrectly Estimating Required Bandwidth - Forcing a Video Transcode

Tbh my workarounds aren’t great:

  1. Disable the “streaming brain” (Blank out “Upload Speed” in Remote Access Settings and set “Original (No Limit)” for Stream Bitrate Limit)

  2. For Android TV/Fire TV devices that can’t natively decode EAC3- set Passthrough to HDMI and hope your TV can decode it. If you’re TV can’t decode it, replace the device with one that can

I ended up replacing about a dozen Gen 2 Firesticks with 4k Firesticks just to work around this issue :sweat_smile: :stuck_out_tongue_closed_eyes:

Edit: Oh yeah. In case anyone doesn’t already:

  1. Set Remote/Internet Streaming Video Quality to “Maximum” on each of your clients
4

Per MKVToolNix author Moritz’s explanation that it’s a localization issue, I suspect that it’s possible to force MKVToolNix to produce files with BPS instead of BPS-eng. I haven’t tried yet.

Due to a grossly slow server, I’m allergic to transcoding, and I have “Upload Speed” blanked out already. That probably explains why I wasn’t seeing the same consequences as @thantelius in the other thread.

1 Like
5

Oh yeah another workaround is to use MKVToolNix v19 to remux the files. This will produce MKV’s with the old BPS metadata (in addition to BPS-eng). It seemed like a daunting task to go back and remux all my files so I only ever did a few test cases. I was also unsure if there was any downsides to using a really really old version so figured I probably shouldn’t nuke my entire media collection if there were other options

I feel ya on the slow server. I much prefer to use small low-power devices like Raspberry or Atomic Pi’s as my servers. I’m guessing this is why it hasn’t been a widely reported issue since most users seem to have plenty of transcoding power and probably don’t care about a few more random transcodes stressing their rigs

1 Like
6

Hahahah, oh, no. Mine’s not low-power. Just old. :slight_smile:

I wonder if this contributes to the default “Use MP4” recommendation, too.

1 Like
7

Lol No worries. I used to use my old Sandy Bridge Laptop until I realized that a Pi would probably do the job just as well

Also I assume you already do this but just in case, on your web player is Settings > Plex Web > Quality > Video Quality set to “Maximum” ? My setup can’t play files otherwise

8

I almost never use Plex Web. But that might change. Today Plex added support for HEVC playback in Plex Web in Safari. Yay!

I’ll compare with that setting. But it makes sense that you would need “Maximum” if the bitrate estimate wasn’t working.

1 Like
9

Are you allowing Plex server to perform its in-depth analysis?
This should give you detailed bandwidth information of all streams, independently of the container statistics.
(The embedded statistics are only “averaged” anyway, so can deviate by up to factor ~4 in bandwidth peaks in the video stream.)
If you switch off the detailed analysis, the streaming brain cannot work up to its full potential.

example of a video which was muxed with a recent mkvmerge version. It still has all relevant bandwidth info in Plex:

<Media id="1241057" duration="6141408" bitrate="8995" width="1920" height="804" aspectRatio="2.35" audioChannels="6" audioCodec="ac3" videoCodec="h264" videoResolution="1080" container="mkv" videoFrameRate="24p" videoProfile="high">
<Part accessible="1" exists="1" id="1243615" key="/library/parts/1243615/1595495145/file.mkv" duration="6141408" file="E:\Animation2\Onward (2020)\Onward (2020).mkv" size="6795513830" container="mkv" deepAnalysisVersion="4" indexes="sd" requiredBandwidths="20419,16828,13149,11612,11612,11612,11612,11612" videoProfile="high">
<Stream id="2030708" streamType="1" default="1" codec="h264" index="0" bitrate="5588" language="English" languageCode="eng" bitDepth="8" chromaLocation="left" chromaSubsampling="4:2:0" codedHeight="816" codedWidth="1920" colorPrimaries="bt709" colorRange="tv" colorSpace="bt709" colorTrc="bt709" frameRate="23.976" hasScalingMatrix="0" height="804" level="40" profile="high" refFrames="5" requiredBandwidths="16910,13392,9702,8410,8410,8410,8410,8410" scanType="progressive" width="1920" displayTitle="1080p (H.264)" extendedDisplayTitle="1080p (H.264)"/>
<Stream id="2030709" streamType="2" codec="ac3" index="1" channels="6" bitrate="512" language="Deutsch" languageCode="ger" audioChannelLayout="5.1(side)" requiredBandwidths="512,512,512,512,512,512,512,512" samplingRate="48000" displayTitle="Deutsch (AC3 5.1)" extendedDisplayTitle="Deutsch (AC3 5.1)"/>
<Stream id="2030710" streamType="2" selected="1" codec="ac3" index="2" channels="2" bitrate="320" language="English" languageCode="eng" audioChannelLayout="stereo" requiredBandwidths="320,320,320,320,320,320,320,320" samplingRate="48000" title="compressed stereo" displayTitle="English (AC3 Stereo)" extendedDisplayTitle="compressed stereo (English AC3)"/>
<Stream id="2030711" streamType="2" codec="dca" index="3" channels="6" bitrate="2046" language="English" languageCode="eng" audioChannelLayout="5.1(side)" bitDepth="24" profile="hra" requiredBandwidths="2045,2045,2045,2045,2045,2045,2045,2045" samplingRate="48000" displayTitle="English (DTS-HD HRA 5.1)" extendedDisplayTitle="English (DTS-HD HRA 5.1)"/>
<Stream id="2030712" streamType="2" codec="ac3" index="4" channels="2" bitrate="320" language="English" languageCode="eng" audioChannelLayout="stereo" requiredBandwidths="320,320,320,320,320,320,320,320" samplingRate="48000" title="commentary" displayTitle="English (AC3 Stereo)" extendedDisplayTitle="commentary (English AC3 Stereo)"/>

Here is one from a TS container which probably doesn’t carry such detailed bitrate information as MKV. And it has E-AC3 streams as well:

<Part accessible="1" exists="1" id="1260803" key="/library/parts/1260803/1605291720/file.ts" duration="3178519" file="E:\DVRserie\Bares fur Rares (2020)\Season 2020\Bares fur Rares (2020) - 2020-11-13 18 30 00 - Bares fur Rares.ts" size="1522759768" container="mpegts" deepAnalysisVersion="4" packetLength="188" requiredBandwidths="3698,3563,3484,3484,3484,3484,3484,3484" videoProfile="main">
<Stream id="2074939" streamType="1" codec="hevc" index="0" bitrate="2946" bitDepth="8" chromaSubsampling="4:2:0" codecID="HEVC" codedHeight="1080" codedWidth="1920" colorPrimaries="bt709" colorRange="tv" colorSpace="bt709" colorTrc="bt709" frameRate="50.000" height="1080" level="123" profile="main" refFrames="1" requiredBandwidths="3154,3021,2958,2958,2958,2958,2958,2958" streamIdentifier="256" width="1920" displayTitle="1080p (HEVC Main)" extendedDisplayTitle="1080p (HEVC Main)"/>
<Stream id="2074940" streamType="2" selected="1" codec="eac3" index="1" channels="2" bitrate="256" language="Deutsch" languageCode="ger" audioChannelLayout="stereo" requiredBandwidths="256,256,256,256,256,256,256,256" samplingRate="48000" streamIdentifier="257" displayTitle="Deutsch (EAC3 Stereo)" extendedDisplayTitle="Deutsch (EAC3 Stereo)"/>
<Stream id="2074941" streamType="2" codec="eac3" index="2" channels="2" bitrate="128" language="Deutsch" languageCode="ger" audioChannelLayout="stereo" requiredBandwidths="128,128,128,128,128,128,128,128" samplingRate="48000" streamIdentifier="258" displayTitle="Deutsch (EAC3 Stereo)" extendedDisplayTitle="Deutsch (EAC3 Stereo)"/>
<Stream id="2074942" streamType="2" codec="eac3" index="3" channels="2" bitrate="128" language="Multiple Languages" languageCode="mul" audioChannelLayout="stereo" requiredBandwidths="128,128,128,128,128,128,128,128" samplingRate="48000" streamIdentifier="259" displayTitle="Multiple Languages (EAC3 Stereo)" extendedDisplayTitle="Multiple Languages (EAC3 Stereo)"/>
<Stream id="2074943" streamType="3" codec="dvb_subtitle" index="4" bitrate="30" language="Deutsch" languageCode="ger" hearingImpaired="1" requiredBandwidths="33,33,33,33,33,33,33,33" streamIdentifier="260" displayTitle="Deutsch SDH (DVB_SUBTITLE)" extendedDisplayTitle="Deutsch SDH (DVB_SUBTITLE)"/>
</Part>
</Media>
1 Like
10

Hi friend. I recognize that deep analysis would likely fill-in the audio bitrate field (or at least avoid the wonky client behavior). However due to bandwidth reasons (remote storage) as well as personal preference I’d prefer to keep it disabled. I fully understand that the brain will not work to it’s full potential but it’s a compromise I’m willing to make

That said I feel that even though I’m consciously making the compromise to disable deep analysis it is worth investigating and hopefully fixing the bug where audio bitrate metadata is not parsed successfully on the initial “shallow” scan. I appreciate you taking the time to reply and help with this issue regardless and you make a very good point that I should have specified that I have Deep Analysis disabled in my original post :grinning:

Edit: Just to clarify how wonky the behavior is. Almost all my files are 5mbps. With Deep Analysis disabled the brain usually makes a required bandwidth estimate of 10mbps. This is a pretty good ballpark estimate all things considered. However when PMS fails to parse the audio bitrate it makes a required bandwidth estimate of 10,000mbps for a similar 5mbps file

1 Like
11

Are you seeing any other issues ie: no sound at all? This seems to have just started to be an issue for me as of the last 1 or 2 updates.

12

Sorry bud but I haven’t experienced any sound issues or anything like that. Your issue is likely unrelated but you never know :woman_shrugging:

13

No worries. I appreciate your replying :slight_smile:

1 Like
14

I had a buddy look through his libraries as well. Add TRUEHD to the list of audio codecs that have issues with bitrate metadata being parsed properly by Plex when using an MKV container

15

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