Emby Server is incorrectly calculating the bitrate

[echoxxzz 22]

Emby Server is incorrectly calculating the bitrate and this is forcing videos to be transcoded because the max bitrate has been exceeded when in fact it hasn't.

 

For my test I used an mkv file with 3 streams.

Mediainfo reported that the file contained the following three streams and the overall bitrate was 4247 kbps.

 

Stream 1: HEVC Video @ 1226 kbps

Stream 2: DTS Audio @1509 kbps

Stream 3: DTS Audio @ 1509 kbps

 

If I examine the Emby server log, the reported overall bitrate of the mkv file is 7319 kpbs, which is WRONG!!! 

I believe Emby is calling ffprobe at this point but I have no idea how it came up with this number.

 

If I then examine the transcode log file, ffpmeg correctly reports the overall bitrate as 4247 kpbs.

 

I have attached the output from mediainfo and my server and transcode log files for analysis.

 

 

mediainfo.txt

server-63647365498.txt

ffmpeg-transcode-eff777cb-0f8f-4ba5-b04d-93cf9449c131.txt

[echoxxzz 22]

So I deleted ffprobe.exe from the Emby Server system folder and I still get bit rate misreports.

I conclude that Emby Server 3.2.40.0 isn't using ffprobe to detect the bitrate as I thought it did at one time.

[Luke 42080]

We are using ffprobe. That's what it tells us.

[echoxxzz 22]

After a bit more testing I have figured how Emby Server is incorrectly calculating the bitrate.

 

It seems that Emby Server takes that video bitrate and adds twice the audio bitrate for each audio stream.

 

For example:

==========

 

An HEVC video encoded at 1226 kpbs with three DTS audio streams encoded at 1509 kps has a correct total bitrate equal to approximately 5753 kbps.

 

Emby reports this video having a bitrate equal to 10400 kpbs.

 

Using my formula this works out to 1226 + (2 x 1509) + (2 x 1509) + (2 x 1509) which equals 10280 kbps which is very, very close to the reported value 10400 kbps.

 

 

Why does Emby Server need to double the size of each audio stream when it calculates the overall video bit rate and is there anyway to fix this?

[Luke 42080]

We don't do that. We get the overall container bitrate from ffprobe.

[echoxxzz 22]

You're definitely NOT using ffprobe.

 

I deleted ffprobe from the Emby Server system folder and it still incorrectly reports the bit rate according to the formula I posted above. 

[Luke 42080]

Deleting ffprobe won't change anything for existing titles in your library

[ryandavidg 30]

I had issues in the past where the metadata was incorrect on a file, and (apparently) Mediainfo and some other tools were reporting this incorrect metadata. Not saying that's the case here (esp assuming you made the test rip/file yourself) but I no longer rely on it when I have problems and rather investigate the file further.

Edited November 27, 2017 by ryandavidg

[echoxxzz 22]

My server is still pulling ffmpeg and ffprobe from the ../ffmpeg/20170308 folder not the Emby system folder so that would explain why things kept working after I deleted the ffprobe.exe file.

At one time you could set the location of ffmpeg in the transcoding section but this option seems to be gone in 3.2.40.0.

 

So I ran the exact ffprobe,exe command that is recorded in the server log file and it gave me a value of 5757 kbps for the container bit rate which is correct.

Yet when I play the same video in the server log the video is reported as having a bit rate of 10400 kbps.

 

Server.log:

========

2017-11-27 11:05:06.929 Info App: Profile: Unknown Profile, Path: M:\TV Shows\Fargo\Season 02\Fargo.S02E10.mkv, isEligibleForDirectPlay: True, isEligibleForDirectStream: False

2017-11-27 11:05:06.929 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.10.10, IsInLocalNetwork: True

2017-11-27 11:05:06.929 Info App: Bitrate exceeds DirectStream limit: media bitrate: 10365046, max bitrate: 5000001

2017-11-27 11:05:06.929 Info App: Profile: Unknown Profile, Path: M:\TV Shows\Fargo\Season 02\Fargo.S02E10.mkv, isEligibleForDirectPlay: True, isEligibleForDirectStream: False

2017-11-27 11:05:06.968 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.10.10, IsInLocalNetwork: True

 

Output from ffprobe:

===============

C:\>C:\Users\emby\AppData\Roaming\Emby-Server\ffmpeg\20170308\ffprobe.exe -i file:"M:\TV Shows\Fargo\Season 02\Fargo.S02E10.mkv" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format

ffprobe version N-83781-g3016e91 Copyright © 2007-2017 the FFmpeg developers

  built with gcc 6.3.0 (GCC)

  configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib

  libavutil      55. 48.100 / 55. 48.100

  libavcodec     57. 82.102 / 57. 82.102

  libavformat    57. 66.103 / 57. 66.103

  libavdevice    57.  3.100 / 57.  3.100

  libavfilter     6. 74.100 /  6. 74.100

  libswscale      4.  3.101 /  4.  3.101

  libswresample   2.  4.100 /  2.  4.100

  libpostproc    54.  2.100 / 54.  2.100

{

Input #0, matroska,webm, from 'file:M:\TV Shows\Fargo\Season 02\Fargo.S02E10.mkv':

  Metadata:

    encoder         : libebml v1.3.5 + libmatroska v1.4.8

    creation_time   : 2017-11-27T14:11:51.000000Z

  Duration: 00:51:22.58, start: 0.000000, bitrate: 5757 kb/s

    Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709), 1920x1080 [sAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

 

 

I then ran the same ffprobe command using the ffprobe.exe contained in the system folder and I got the same results.

 

I have tested at least a dozen mkv files and except those with no audio streams, all of them are reported incorrectly using the formula I posted above.

[Luke 42080]

Try refreshing the title from the web app detail screen.

[echoxxzz 22]

Yes, I made the test files myself using MKVTOOKNIX and I am 100% confident that each DTS audio stream is  encoded at 1509 kbps as that is the standard bitrate for DTS audio.

[Luke 42080]

Can you provide a sample video for testing? thanks.

[echoxxzz 22]

I've been doing Refreshes every time I add/delete or modify a file but it makes no difference.

Emby Server still records the incorrect bit rate using the formula I posted above.

 

What format are the Emby database files in? 

Can I examine the contents to see what value is being stored for the bitrate?

[Luke 42080]

The value in the database matches what you see in the web app. There's no benefit to going in there directly. Again if you can please provide a sample file i will test it personally. thanks.

[echoxxzz 22]

I created two mkv files using the mkvtoolnix-gui tool from two sources called testfile.hevc and testfile.dts.

The bitrate of the hevc file is 1226 kbps and the bitrate of the dts audio file is 1509 kpbs

 

The testfile1.mkv file includes the hevc video and two copies of dts audio stream. ffprobe reports an overall bitrate of 5202 kbps.

The testfile2.mkv file includes the hevc video and three copies of dts audio stream. ffprobe reports an overall bitrate of 6712 kbps.

 

When I play back testfile1.mkv, emby server reports that the bitrate of the file is 8274 kbps and testfile2 has a reported bitrate of 11320 kbps.

 

I have zipped and attached the two source files, the two mkv testfiles, the output from ffprobe for each test file and my server log.

 

 

 

testfiles.zip

[echoxxzz 22]

Hey Luke, did you get a chance to try the test files I sent you to confirm that my findings are correct?

[echoxxzz 22]

I found another way to show the error. I created four small mkv files using the exact same video and audio stream.

 

testfile1: No audio

testfile2: One Audio Stream

testfile3: Two Audio Streams

testfile4: Three Audio Streams

 

In the Emby Web Client when I open each test file and display the properties of the files it is correctly reporting the number of audio streams and bit rates for the audio files but the bit rate of the video stream gets larger with each additional audio stream by approximately the bit rate of the additional audio stream.

 

In the case of my four test files, Emby Web Client is reporting that the video bitrate for the four test files to be:

 

testfile1: 2490 kbps

testfile2: 3692 kbps

testfile3: 5202 kbps

testfile4: 6712 kbps

 

 

There is no way the video stream should be changing since the four mkv files where all created from the exact same hevc video stream.

 

With just 2 or 3 audio files the error in the overall container bit rate is quite significant.

 

Can any member please confirm my findings using the attached test files?

 

I'd really like to see the developers fix this.

 

Unlike most I tend to have movies with multiple audio languages and this is forcing transcoding (because the max bitrate has been exceeded) to occur when it really isn't needed.

 

 

 

testfiles.zip

[echoxxzz 22]

So I examined the SQLITE database library.db and when I queried the mediastreams table for each test mkv file I found one record for each audio/video stream.

For the audio streams you are correctly saving the bitrate that ffprobe returns.

But for the video stream you're saving the overall container bitrate that ffprobe returns and not the actual bitrate of the video stream.

I guess that's because ffprobe doesn't actually return a bitrate for the video stream (not sure why).

This is fine so long as you only use that value to calculate the overall bitrate when deciding to transcode the video but Emby is adding up the values of the bitrate field for all the records.

[Luke 42080]

It's resolved for the next release. You'll need to refresh affected titles. Thanks for the report.

[mastrmind11 722]

well done @@echoxxzz