我写了一些逻辑来比较 ffprobe 与 MediaInfo.DLL 的信息。观察和问题：
A) 大多数差异都是各种数值（比特率、持续时间、每秒帧数）较小有效数字的细微变化，但我无法确定哪一个实际上更准确。您对 ffprobe 的输出和 MediaInfo.DLL 的输出之间的细微差异是否重要有任何看法，或者如何评估哪一个更准确？
B) 对于一个 WMV 文件，MediaInfo.DLL 报告的每样本位数为 16。我的理解是 BPS 和位深度只是同一事物的两个不同名称，但 ffProbe 无法确定位深度。我认为 ffProbe 可能是正确的，因为音频编解码器是 wmav2，它显然使用了非常低质量的有损压缩，这可能使位深度变得毫无意义。所以我想知道 MediaInfo.DLL 是否只是看到 WMA 格式并盲目地假设为 16。另一个 (AMR) 文件有类似的东西，其中 MediaInfo.DLL 报告的位深度为 14。（对于此文件，ffProbe 报告的比特率为 9200，而 MediInfo.DLL 报告的比特率为 0）。有没有可靠的方法来确定 MediaInfo.DLL 中的 BPS 是否真的有意义且正确？
C) 对于一个 WEBM 文件，ffProbe 显示视频比特率为 0，音频比特率为 0。此视频比特率似乎与文件属性窗口详细信息选项卡上报告的视频数据速率 0kbs 一致。但是，MediaInfo.DLL 报告的视频比特率为 439316 bps，音频比特率为 64000 bps。在这种情况下，音频比特率与文件属性中报告的比特率相匹配。ffProbe 报告的唯一比特率为 533294（未指定这应该是音频、视频、组合还是其他）。在 MediaInfo.DLL 的“更多信息”视图中，这被报告为总体比特率。它大致相当于音频和视频组合比特率，因此这些速率中的一些或全部可能是“目标”比特率（因为 webm 是有损的）。我将视频流大小除以持续时间（以秒为单位），得到 54,914.439... 同样，对于音频流，结果也是 8000。因此 MediaInfo 显然不只是在计算平均音频和视频比特率。有人知道可能发生了什么吗？或者谁对现实的解释是正确的？
您可以找到我的示例媒体文件这里