Am Sa., 2. Mai 2020 um 23:16 Uhr schrieb Rick Maschmann <[email protected]>: > > 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 _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
