[FFmpeg-user] Using -bitexact option to avoid File Explorer bug when creating Matroska files

[Carl Eugen Hoyos]

Am Sa., 2. Mai 2020 um 23:16 Uhr schrieb Rick Maschmann
<Rick.Maschmann at outlook.com>:
>
> I discovered and logged a bug with Windows File Explorer related to the matroska files and the metadata fields "Data rate" (for video track) and "Bit rate" (for audio track).  The matroska muxer generates a random number for Track UID and when that number happens to be greater than the max value for Int64, the related BPS matroska metadata field fails to appear in File Explorer under Data rate or Bit rate.  The matroska muxer writes a UInt64 into the Track UID field, per the matroska spec.

I wonder if our new matroska maintainer would accept a patch
avoiding values >int64_max.

> I found that the ffmpeg -bitexact advanced option flag causes the muxer to create sequential Track UID values instead of generating random numbers, which avoids the File Explorer bug.  The FFmpeg documentation for -bitexact doesn't say much about this flag (I only found out about it by tracing matroska muxer source code).
>
> What are the consequences or negative side effects from using the -bitexact flag?

That strictly speaking the output files are not compliant.
But for your use-case, this seems of little relevance.
In addition, future FFmpeg version will not be able to
work-around bugs in current FFmpeg if you use bitexact.

Carl Eugen