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?