Video and audio bit rate is missing from mediainfo (mkv encoded x265)

[crisc2000]

Description of the problem

Hello, when a MKV/x265 file is encoded to another MKV/x265 with smaller video and audio bit rate, the mediainfo is missing video and audio bite rate information from the resulted file encoded with Handbrake.
Handbrake seem to not write that information in the metadata.

Mediainfo:
General:
Overall bit rate: OK

Video:
Bit rate: MISSING (only showed in the Encoding settings data)

Audio:
Bit rate: MISSING

Steps to reproduce the problem

Open a higher bit rate mkv with x265 codec, encode it.

1. Open the resulted file with Media player classic Home cinema -> Properties -> MediaInfo.
2. Or use https://mediaarea.net/en/MediaInfo , Open file->View->Text

HandBrake version

1.1.2 - 64bit

Operating system and version

Windows 7 64bit

Error message text or screenshot

That bit rate in mediainfo is presented when encoded with other encoder software.

[woodstockathbf]

Mediainfo is looking at meta data to show bit rate, and handbrake does not pass that through right now.

It has been discussed before (issue #1114) ; even with tracks that are passed through unchanged, without the meta data, mediainfo is lost.

[fireattack]

See also: https://gitlab.com/mbunkus/mkvtoolnix/wikis/Meta-data-fields-like-bitrate-lost (from another discussion before)

[crisc2000]

I don't think that has to do anything with the mkv muxer. I demuxed the video track from the mkv, open with mediainfo and it has the same problem.

[JeromeMartinez]

It's not about the MKV muxer,

It is.

it's about the MKV format itself.

It isn't. The lack of support of 1 Matroska feature by a specific muxer does not mean the format has a problem, it just mean that the muxer did not implement something.

It doesn't even have meta tag fields for average bitrate.

It does.
Matroska statistic tags

Calculate such info on-the-go and then store it in tags (mostly this)

So they have meta tag fields, you said a thing and its opposite ;-). Just not pure Matroska elements and not mandatory.

As mentioned above, the bitrate info just doesn't exist, as they're not mandatory for either MKV

It was existing in the source file. No mandatory does not mean no existing.

because the info was stored as MKV tags.

Right. But it is not the reason it disappeared (actually source bitrate tags are no more relevant, as they are about the old stream), the reason it disappeared is that the muxer you used does not write optional bitrate info, so the one to blame is the muxer you use, which did not implement such optional metadata, that's all.

---

Summary: the only issue there is that the muxer used by HandBrake (FFmpeg) did not implement the support of the statistic tags (it is a muxer issue, and only that), and the solution for fixing this issue is to have a patch for statistic metadata support in FFmpeg Matroska muxer.
As a workaround, you can use e.g. mkvmerge for remuxing the streams (so you keep the compression settings from HandBrake, just not the Matroska stuff) after having used HandBrake, and bitrate will be displayed in MediaInfo.

[fireattack]

@JeromeMartinez

I think we pretty much agree on most of things, just that my wordings are pretty poor (English is not my first language, sorry about that!), which causes your confusion. For example, when I say "It doesn't even have meta tag fields", I meant to say "no header fields" (in contrast to optional tags).

I deleted my original comment as it's indeed confusing. Basically I'm just stating the reason MKVs encoded by HB doesn't have bitrate for streams is because it's not mandatory in MKV format (that's what I meant when I say "it's about the format").

But again, it's definitely possible and will be very nice to have.

The only thing I want to repeat again is that OP said "I demuxed the video track from the mkv, open with mediainfo and it has the same problem."; this is not a proof of problem either way. Because if you demux a MKV file with stream bitrate info, likely the resulted HEVC/AVC file will NOT have bitrate info in mediainfo either (it is the case for the batch of MKV files I tested at least).

[crisc2000]

@JeromeMartinez

Summary: the only issue there is that the muxer used by HandBrake (FFmpeg) did not implement the support of the statistic tags (it is a muxer issue, and only that)

It's logical what you say. But I have a curiosity. Why the "overall bit rate" is present? Maybe that one is calculated by MediaInfo? (like @fireattack suggested)

and the solution for fixing this issue is to have a patch for statistic metadata support in FFmpeg Matroska muxer.

So can anyone open an issue ticket to FFmpeg?
If the developers of FFmpeg won't add this future, there is the solution to make Handbrake use a different muxer like mkvmerge https://mkvtoolnix.download/doc/mkvmerge.html , or after muxed with FFmpeg to use mkvpropedit https://mkvtoolnix.download/doc/mkvpropedit.html with parameter with "--add-track-statistics-tags" parameter?

@fireattack

But again, it's definitely possible and will be very nice to have.

That info is important especially for anyone who want to re-encode the file (encoded with Handbrake). Let's say you want to make the MKV file smaller, you need to chose a smaller bit rate for video and audio. But if that info is missing you must manually calculate the bit rate of your source file from each track size & lenght (I don't even tested if it's possible to easily see the track size without demux).

[JeromeMartinez]

But I have a curiosity. Why the "overall bit rate" is present? Maybe that one is calculated by MediaInfo?

Easy to calculate (overall duration is provided, so just file size divided by duration). Difficulty is to know per stream as file size if for all streams.

mkvpropedit https://mkvtoolnix.download/doc/mkvpropedit.html with parameter with "--add-track-statistics-tags" parameter?

Oops, I wanted to talk about mkvpropedit instead of mkvmerge.

(I don't even tested if it's possible to easily see the track size without demux).

the only possibility is to scan the whole file. MediaInfo has some features for parsing the whole file but not tested and implemented for bitrate info of MKV tracks (on the todo-list, but not a priority). Demux and check file size (so you can divide by duration from the MKV) is a workaround.

[crisc2000]

So i see 4 possible solutions for Handbrake to fix this problem

1. The most simple: use mkvpropedit to generate track statistics after muxing the file with ffmpeg
2. Switch from ffmpeg to another muxer like mkvmerge/libmatroska (how other software like StaxRip or MeGui are doing)
3. Make a specific ffmpeg patch for Handbrake (i have seen that they are already some patches https://github.com/HandBrake/HandBrake/tree/master/contrib/ffmpeg)
4. Open an enhancement ticket to the original ffmpeg library ... I already done it: https://trac.ffmpeg.org/ticket/7467#ticket

[crisc2000]

@JeromeMartinez

Oops, I wanted to talk about mkvpropedit instead of mkvmerge.

Actually I made more tests, and it you were right first time.

I used something like
mkvpropedit.exe -handbrake_output.mkv --add-track-statistics-tags
and this one will not generate proper MediaInfo. The media info will look like this:

There is some kind of bitrate info there, but with a different tag name, in a different place, and without a measurement unit. I don't like the results.

After that I tested your first suggestion. Demuxed the tracks with gMKVExtractGUI (mkvextract) , remuxed with MKVToolNix GUI (mkvmerge).

Finally the correct MediaInfo is there for both video and audio!!

[sr55]

Why is it important that you have this? It's not necessary to have in the file and I don't see it being particularly useful.

I'm not super inclined to spend any time on this. There are much more important things that we can spend time working on. Wouldn't necessarily turn down a patch if someone was really interested in this but it really doesn't add much value

Does ffmpeg on it's own exhibit the same behaviour? May not be an ffmpeg issue at all. If not it may be simply that we don't tell it to write the optional tags.

[crisc2000]

Why is it important that you have this? It's not necessary to have in the file and I don't see it being particularly useful.
I'm not super inclined to spend any time on this. There are much more important things that we can spend time working on. Wouldn't necessarily turn down a patch if someone was really interested in this but it really doesn't add much value

This is a quote from a previous post:
That info is important especially for anyone who want to re-encode the file (encoded with Handbrake). Let's say you want to make the MKV file smaller, you need to chose a smaller bit rate for video and audio. But if that info is missing you must manually calculate the bit rate of your source file from each track size & lenght (I don't even tested if it's possible to easily see the track size without demux).

Does ffmpeg on it's own exhibit the same behavior? May not be an ffmpeg issue at all. If not it may be simply that we don't tell it to write the optional tags.

I did not tested ffmpeg muxer, however I studied their command line docs https://ffmpeg.org/ffmpeg-formats.html and I did not find anything to suggest that they are some supplementary options to write this kind of statistical tags that mkvmerge (libmatroska) is doing.

[sr55]

Marking as an enhancement request for now. It's not something I'd invest time in but if someone wants to contribute a patch we can take a look.

Not 100% sure at this point whether it's an ffmpeg change, or simply we need to set some tags but ultimately, these are optional and don't necessarily reflect what's actually going on in the file anyway so it's not something I'd personally invest time into.

[passat1]

It is not limited only to x265, all output MKV files are without that info.
All MP4 output files do have that info, and MKV does not.
It is ONLY reason why I use MP4 for output.
Specially if I use CRF or CQ, which I do, so I can quickly see what I have done.
If such file is re-muxed with MKVTolnix, it's output file has all that info, but then new problem emerges if MP4 output is used because MKVTolnix does not read subtitle tracks from MP4, and they should be extracted (or directly re-muxed) from source MKV.
It can always be solved some other way and sometime it's good brain exercise, but mostly it is big waste of time.
There are many users that need "one button" encoding solution (probably best for them) never knowing how and what was done, but also many users that would like to use this great program in semi-professional way and get from it little more, knowing that it is possible.
For those users this information is very important.

[cehoyos]

If this is such an important issue, why does nobody add the necessary information to make the FFmpeg ticket valid?

[crisc2000]

I just ran into this problem. Why does nobody add the necessary info to make the ticket valid indeed. My guess is laziness and stupidity. Seems appropriate.

I really don't have any idea what to say to ffmpeg developers to take that problem seriously . For me that problem was clear like the day. I don't understand why they closed the ticket and what was "invalid" about it.

If someone has better idea how to put the problem to make the ffmpeg developers wheels start spinning please open another ticket with this issue.

[JeromeMartinez]

@crisc82 as a developer having often such "criticism", I am sure of one thing: moaning about the lack of "seriousness" or saying "clear like the day" is the opposite of succeeding in convincing people about your own seriousness, as you demonstrate that you don't take seriously the fact that nobody is interested in this enhancement enough for doing it for free.

Handbrake or FFmpeg (or me) don't take that "problem" seriously because it is actually not a problem for them.

Developers already know that you wish this enhancement, it is just not their priority.
You may just accept the fact that this is a "nice to have" but not the priority for any developer working on Handbrake or FFmpeg as an hobby.

A suggestion: if this enhancement is really important to you, having a valid ticket will not be enough (the ticket can be considered as valid but maybe nobody will be interested in working on it for free, I personally have a couple of tickets marked as valid on FFmpeg tracker and not fixed, and I know that the issue is on my side, the issues are not important enough for me for spending time or money on them), you may try to work on a crowdfunding campaign for paying someone for implementing it.

[sr55]

Highlighting the relevant part of the closed ffmpeg ticket:

Please reopen this ticket if the issue is reproducible with current FFmpeg git head and if you can provide the command line you tested together with the complete, uncut console output.
Please do not use external resources except for necessary large input files.

Now, I don't know if this is a problem in ffmpeg or not since I've done no investigation into this but if you are able to reproduce with ffmpeg, then you can make that ticket relevant by posting the information they requested.

Since you provided no information other than "This doesn't work in HandBrake". It's no real surprise it got closed. There are no reproduction steps for creating this issue with ffmpeg.

[jstebbins]

Tags in matroska are written by ffmpeg when the track is initialized (i.e. before any muxing has been done and before the duration or size of the track data is known). This means that HandBrake can't add this tag since the necessary information isn't available at the time we initialize the track.

ffmpeg could write it without intervention from HandBrake with a bit of effort. ffmpeg currently reserves a location for the track "DURATION" tag (which isn't listed in matroska official tags btw) when the track is initialized and goes back and updates it when the duration is known at the end. It could do the same for the "BPS" official matroska tag. Of coarse code would have to be added to track the total size of the track not counting matroska track overhead so that bps can be computed at the end.

[gendalv]

I've never had this issue with media coder - it always writes mediainfo with kbit per stream. I'm always using this information to determine and search for (with some regex and TC plugins) files with bloated bitrate for example, often it's just one of the tracks in a file - which an overall information won't reveal obviously.

[Miko36110]

So... is this ever gonna get fixed? I don't like re-muxing the file on MKVToolNix because it takes extra steps and time consuming especially for tv shows/series.

[t0ma5]

What puzzles me is why the problem only appears sometimes, notably when using AAC audio. Never seen this happening with an AC-3 pass-through Handbrake encode, for example. Does it use another muxer in that case, or...?

[JeromeMartinez]

What puzzles me is why the problem only appears sometimes, notably when using AAC audio. Never seen this happening with an AC-3 pass-through Handbrake encode, for example.

Don't care much about the audio format. In MediaInfo, check the line "Bitrate mode" (constant or variable).
And imagine maths.
X = Y + Z
You have only X, can you guess Y? No.
You have X and Z, can you guess Y? Yes.

With constant bitrate (e.g. AC-3 or DTS), you have X (file size so overall bitrate) and Z (audio bitrate, indicated in the audio bitstream, fine with only one frame as the frames promises that it is constant) so you can guess Y (video bitrate)
With variable bitrate (e.g. AAC, or DTS MA or TrueHD...), you have X (file size so overall bitrate) and that's all so you can not guess Y (video bitrate).

So... is this ever gonna get fixed?

When someone is motivated to send a patch to FFmpeg or organize a crowdfunding for paying someone to do it if nobody is interested in doing it for free. You are not obliged to be only a spectator complaining about the quality of what you get for free, you can decide to be actor of the change. It will be fixed when you really decide that it needs to, if nobody decides before you.

[matty-fb]

In case anyone here finds it useful, I wrote a bash script to batch-remux my encodes with mkvmerge. It's crude, but it makes remuxing a folder of 20+ TV episodes much less tedious. Requires trash-cli, and has only been tested on Xubuntu. It prints a list of mkvs that will be remuxed, and gives you an opportunity to abort. The files are remuxed to a new file (name + caret), the original file is moved to the trash, and the new file is renamed to remove the caret.

#!/bin/bash
readarray -d '' files_array < <(find . -name "*.mkv" -print0);
IFS=$'\n' files_sorted=($(sort <<<"${files_array[*]}"))
unset IFS

for file in "${files_sorted[@]}"
do
        basename "$file";
done

read -p "Do you wish to remux these files? (y/n) " -n 1 -r
echo "";

if [[ ! $REPLY =~ ^[Yy]$ ]]
then
        echo "Operation aborted";
else
        for file in "${files_sorted[@]}"
        do
                new_file="${file%.*}^.mkv";
                mkvmerge -o "$new_file" = "$file";
                trash-put "$file";
                mv "$new_file" "$file";
        done
fi

[bbepis]

@cehoyos

If this is such an important issue, why does nobody add the necessary information to make the FFmpeg ticket valid?

Consider this done. I ran into this problem trying to compare audio bitrates of MKV files. I had originally thought it was a limitation of the AAC codec within matroska, until I stumbled upon this issue on google.

@sr55

Now, I don't know if this is a problem in ffmpeg or not since I've done no investigation into this but if you are able to reproduce with ffmpeg, then you can make that ticket relevant by posting the information they requested.

Since you provided no information other than "This doesn't work in HandBrake". It's no real surprise it got closed. There are no reproduction steps for creating this issue with ffmpeg.

This is indeed an ffmpeg-specific issue as I ran into it using only the CLI. You can probably close this ticket as being unrelated, but I don't use Handbrake so I'm not sure if Handbrake has no additional issues either in regards to this.

[rado84-github]

I just found a file with the same problem. But no need to panic - I also found an easy wasy to calculate video and audio bitrates for both video and audio tracks. I'm posting it here in case anyone else comes across this problem with missing bitrates.

If you use "file size" in megabytes (Windows megabytes), the result for Bitrate will be in kilobits per second (kbps), which is what mediainfo would display, if the metadata were intact.

File size = bitrate * number of minutes * 0.0075.
Bitrate = file size / (number of minutes * 0.0075).
Number of minutes = file size / (bitrate * 0.0075).

[crisc2000]

I don't see the file size for video and audio is present in the mediainfo, so the file size is probably not added into the metadata. And it's logical is not added given what @jstebbins had said "Tags in matroska are written by ffmpeg when the track is initialized (i.e. before any muxing has been done and before the duration or size of the track data is known)"
https://user-images.githubusercontent.com/1497398/46242547-e6f27d00-c3d2-11e8-8718-e4baacbab9c0.jpg
When the track is initialized and if bitrate is variable you can't determine the filesize, only after the whole process is completed.
So that info probably need to be calculated and written in the metadata before muxing the video and audio

To determine audio and video size without demux probably need to learn the mvk container format specifications, and see the bouderies where the components are. mkvpropedit already can do that probably using this logic.

[wpwentzell]

Thanks, everyone, especially @bbepis for doing the nitty-gritty work to find the root of the issue. I fail to see how this is a handbrake-centric issue, other than handbrake relies on ffmpeg, and as such, is affected.

[sr55]

Closing for now. Upstream issue tracked at: https://trac.ffmpeg.org/ticket/7467#ticket

If upstream changes this will come down to us the next time we do a library update. If we need to make code changes to accommodate then someone can ping us and we can re-open the ticket.

[Bardmaster2]

Use VidCoder and choose this for your Picker

:

[Spaarpott]

I was reading this thread, because my output files with 2-Pass Avg Bitrate encoding, did not show any bitrates in MediaInfo, which I find annoying.
I read the post of @Bardmaster2, and got it working in Handbrake. The adding of the statistics happens in mere seconds, depending on the size of the file. After each encode completes, a command window opens briefly in which mkvpropedit updates the statistics of the just finished file. In MediaInfo the output file shows the audio and video bitrate.

It currently works in Handbrake (tested in v1.5.1) by enabling post encoding in mkvpropedit, which is part of mkvtoolnix.
Set it in Preferences in the tab "When Done" under "Encode Completed"
Link the "send file to:" to your mkvpropedit location, and fill in the arguments line: {destination} --add-track-statistics-tags

Here is a screenshot of how it's working.

[t0ma5]

Set it in Preferences in the tab "When Done" under "Encode Completed"
Link the "send file to:" to your mkvpropedit location, and fill in the arguments line: {destination} --add-track-statistics-tags

This works perfectly. Thanks a lot for this workaround @Spaarpott

[ip3t3r]

I found even better solution, with a proper bitrate entry in the media info.
To do that, use MKVToolNIX and just run your video file through the multiplexer, with no changes to your video settings... just copy everything as it is.
It takes only a couple of seconds to process it, and the output file will have a proper bitrate info in "media info". It will also add info about Bits/(Pixel*Frame) and Stream size.

Note: the output file will be slightly smaller, by just 1MB or 2MB, dont know why.

[t0ma5]

I found even better solution, with a proper bitrate entry in the media info. To do that, use MKVToolNIX and just run in through the multiplexer, with no changes to your video... just copy everything as it is. It takes only a couple of seconds to process it, and the output file will have a proper bitrate info in "media info". It will also add info about Bits/(Pixel*Frame) and Stream size.

Thanks for the alternative but it means extra manual steps and double muxing, I like @Spaarpott 's workaround better with a simple line of text in the settings and you can forget about it.

Note: the output file will be slightly smaller, by just 1MB or 2MB, dont know why.

Most likely because subtitles are compressed by default by MKVToolNIX, you can manually choose "no compression" and the final MUX will be exactly the same size as the resulting encode from handbrake

BTW, Will this issue be "fixed" by handbrake anytime in the future?

[ip3t3r]

I have selected "no extra compression" for all subtitle track(s), but still... the final file size was a bit smaller. Have you managed to get the same size for the output file ?