ffmpeg mkv muxer missing track statistics

[eliz82]

Summary of the bug:
This ticket is coming from original post written here:
​https://github.com/HandBrake/HandBrake/issues/1609

It seems Handbrake encoding app is using ffmpeg as a muxer for mkv files (?)
Some statistics (like video & audio bit rate) will be missing from the metadata of the resulted mkv file.

Other encoding apps that are using libmatroska to mux have those statistics (see printscreen in my original post).

Here is the source code of the matroska lib that generate track stats:
​https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/track_statistics.cpp
​https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/track_statistics.h

[Carl Eugen Hoyos]

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.

[Richard]

This issue is not specific to Handbrake, as it occurs within regular usage of FFmpeg as well.

I have created a sample mp4 file using ffmpeg named input.mp4, containing a H264 and AAC stream. When analyzed in FFprobe, this file shows the correct bitrates for both data streams.

However after remuxing input.mp4 to a matroska file named output.mkv, FFProbe does not show the bitrate for the individual streams; only for the container itself. Attempting to retrieve the bitrate for both streams using an alternate FFprobe format output results in the value being "N/A".

The issue resides in avformat's matroska encoder not writing the stream metadata tags required for FFprobe / other applications to determine the bitrate of each stream.
mkvtoolnix / mkvpropedit with the "--add-track-statistics-tags" argument add the required tags for this to work, and therefore the stream bitrates show up in FFprobe after being processed with these tools.

Here is the output from running FFprobe on output.mkv. The FFmpeg conversion log and FFprobe log for input.mp4 is attached as they are too large to post as text.

output.mkv

ffprobe started on 2021-01-22 at 18:28:48
Report written to "ffprobe-20210122-182848.log"
Log level: 48
Command line:
ffprobe -report output.mkv
ffprobe version 2021-01-20-git-2021dbe1d6-full_build-www.gyan.dev Copyright (c) 2007-2021 the FFmpeg developers
  built with gcc 10.2.0 (Rev6, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora   libavutil      56. 63.101 / 56. 63.101
  libavcodec     58.117.101 / 58.117.101
  libavformat    58. 65.101 / 58. 65.101
  libavdevice    58. 11.103 / 58. 11.103
  libavfilter     7. 96.100 /  7. 96.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
[NULL @ 000001f63c6bac00] Opening 'output.mkv' for reading
[file @ 000001f63c6d2180] Setting default whitelist 'file,crypto,data'
[matroska,webm @ 000001f63c6bac00] Format matroska,webm probed with size=2048 and score=100
st:0 removing common factor 1000000 from timebase
st:1 removing common factor 1000000 from timebase
[matroska,webm @ 000001f63c6bac00] Before avformat_find_stream_info() pos: 965 bytes read:32768 seeks:0 nb_streams:2
[h264 @ 000001f63c6d6580] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 000001f63c6d6580] nal_unit_type: 8(PPS), nal_ref_idc: 3
[h264 @ 000001f63c6d6580] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 000001f63c6d6580] nal_unit_type: 8(PPS), nal_ref_idc: 3
[h264 @ 000001f63c6d6580] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 000001f63c6d6580] nal_unit_type: 5(IDR), nal_ref_idc: 3
[h264 @ 000001f63c6d6580] Format yuv420p chosen by get_format().
[h264 @ 000001f63c6d6580] Reinit context to 512x384, pix_fmt: yuv420p
[h264 @ 000001f63c6d6580] no picture 
[matroska,webm @ 000001f63c6bac00] All info found
[matroska,webm @ 000001f63c6bac00] After avformat_find_stream_info() pos: 1900 bytes read:32768 seeks:0 frames:6
Input #0, matroska,webm, from 'output.mkv':
  Metadata:
    COMPATIBLE_BRANDS: isomiso2avc1mp41
    MAJOR_BRAND     : isom
    MINOR_VERSION   : 512
    ENCODER         : Lavf58.65.101
  Duration: 00:04:17.00, start: 0.000000, bitrate: 943 kb/s
    Stream #0:0, 4, 1/1000: Video: h264 (High), yuv420p(progressive), 512x384, 30 fps, 30 tbr, 1k tbn, 60 tbc (default)
    Metadata:
      HANDLER_NAME    : VideoHandler
      VENDOR_ID       : [0][0][0][0]
      DURATION        : 00:04:17.000000000
    Stream #0:1, 2, 1/1000: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
    Metadata:
      HANDLER_NAME    : SoundHandler
      VENDOR_ID       : [0][0][0][0]
      DURATION        : 00:04:16.069000000
[h264 @ 000001f63c6da700] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 000001f63c6da700] nal_unit_type: 8(PPS), nal_ref_idc: 3
[AVIOContext @ 000001f63c6dac40] Statistics: 32768 bytes read, 0 seeks

[Richard]

Zip file containing CLI logs specified in the ticket / second comment

[Kevin]

This anomaly appears to persist. Is there any further information available concerning it?

[Kevin]

Just to be clear, as Richard states above:

"This issue is not specific to Handbrake, as it occurs within regular usage of FFmpeg as well."