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

[crisc82]

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)

[crisc82]

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).

[crisc82]

@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.

[crisc82]

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

[crisc82]

@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.

[crisc82]

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?

[crisc82]

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.