How to get the (average) video bitrate with mkvinfo?

[pxstein]

Assume I start mkvinfo with parameter -g aand drag&drop a video file "myvideo.mkv"
then the output does NOT show the (average) video (and audio) bitrate (for an H.264 encoded video).

How can I get it otherwise (with mkvinfo or mkvmerge)?

Do I have to append an additional parameter?

[ndjamena]

MKVInfo -t


Or you can look at the BPS tag if it's there (which would be WHY it should be there).

[pxstein]

Ok, thank you.
When I use your "-t" parameter then at first lots of stuff is written to console/command prompt.
At the end (after approx 1-2 minutes) at the bottom the bitrate is shown.

Is there a way to omit all the first thousand info lines and just show the last lines with the "summary" bitrate?

Maybe there is another way of improving the output speed?

[ndjamena]

Without statistic tags there's no way of knowing the properties of any particular stream without reading through the entire file.

If you feel you may need to access the information repeatedly you really ought to remux the file with MKVMerge then look at the tags using FFProbe (MediaInfo is buggy, it removes the BPS tags and assigns the tags to the track NUMBER rather than the track UID, so only works if both NUMBER and UID are the same. MKVMerge output is painful.)

Otherwise the only way to "skip" MKVInfos preliminary output is to filter it out using a script (CMD/Batch, Powershell, Bash etc.)

[ndjamena]

Just a heads up, the latest pre and all future versions of MKVPropEdit have the ability to add Matroska track statistics tags to existing Matroska files. It's a real, more permanent alternative to MKVInfo -t and may be preferable to remuxing the entire file using MKVMerge.

https://mkvtoolnix.download/windows/pre/

MediaInfos processing of Matroska statistics tags has been fixed somewhat, but it still has a nasty tendency to guess information when the tags aren't present while not leaving the slightest clue that that's what it's done. That is where a lot of the resistance to the Matroska Statistics tags came from, people assumed the information was already present and that the tags were redundant, so unless you're sure the file you're looking at has the tags in it, FFProbe is still the best choice for examining them. You'd still need to validate the tags yourself though, and ffprobe only outputs one of the two pieces of information used in the process, but being the exact time of creation down to the second it should be enough none-the-less.

MKVPropEdit can now add Statistics Tags to any Matroska file, either those created with older version of MKVMerge or with more modern versions with statistics tags disabled or files created with FFMPEG (even those that already contain invalid statistics tags) or any other program.

Since the most recent version MakeMKV has begun adding Statistics Tags to all files it produces, so in that case at least, MKVPropEdits new ability may not be needed.

MKVPropEdit --add-track-statistics-tags "FileWithoutTags.mkv"

[jagabo]

Is there a way to omit all the first thousand info lines and just show the last lines with the "summary" bitrate?

Maybe there is another way of improving the output speed?

It's easy to skip the stuff you don't want to see:

mkvinfo -t "filename.mkv" | find "Statistics for track number"

But that won't help the speed, for reasons already pointed out.

[ndjamena]

Actually, it does. Outputting to the console isn't very efficient, it takes almost 5 times longer to watch cmd try to force all the lines onto the screen than it does to sit and wait for find to do its work.

Hmmm, The MKVMerge tags are actually more accurate in a lot of cases. In the case of audio MKVMerge isn't limited to the 1ms timescale and can actually sit and count each of the samples to output a far more accurate duration than MKVInfo is capable of. The situation with video is similar, except in order to account for VFR in an MKV MKVMerge needs to have muxed the stream from the original container in order to produce the more accurate duration. On remuxing an MKV originally created by another program (MakeMKV for instance) MKVMerge has no choice but to obey the time codes, which limits it to 1ms precisions and exposes the possibilities of double roundings or splitting offsets.

We really need a better way of examining the tags though...