使用FFmpeg的-write_bext选项写入UMID时出现异常行为

架构老林

2026-4-20

看起来你遇到的是FFmpeg处理BEXT chunk中UMID字段时的一个潜在问题，我来帮你拆解一下可能的原因和解决思路：

字节符号扩展的潜在bug：你发现被替换成7FFFFFFFFFFFFFFF的片段，对应原UMID里的9C600050E4C00067和8E310CEBB2D3F938。注意到第一个字节0x9C是高位为1的字节（二进制是10011100），如果FFmpeg在处理UMID时错误地把单字节当作有符号整数处理，就会触发符号扩展，导致这部分数据被异常改写。这大概率是旧版本FFmpeg的一个已知问题。
先升级FFmpeg版本：建议你先把FFmpeg升级到最新的稳定版，很多和BEXT元数据、UMID相关的处理bug在近年的版本里已经被修复了。升级后再用同样的命令测试一次，看看问题是否消失。
验证UMID格式合规性：确认你输入的UMID符合BEXT chunk的规范。SMPTE定义的基本UMID是16字节（对应32个十六进制字符），扩展UMID是32字节（64个十六进制字符），你的输入属于扩展UMID。你可以先尝试写入一个短一点的基本UMID测试，看看是否能正常读取，以此排除长度兼容问题。
试试专门的BWF元数据工具：如果升级FFmpeg后问题还存在，推荐用bwfmetaedit这个专门处理BWF文件元数据的工具，它对UMID的处理更贴合规范。比如用下面的命令写入UMID：
```
bwfmetaedit --UMID=0x68753A444D6F12269C600050E4C0006773F8EDBBEA4680008E310CEBB2D3F938 output.wav
```
之后再读取验证，应该能得到正确的UMID。
检查读取工具是否靠谱：另外也要确认你用来读取UMID的工具有没有问题。有些工具对扩展UMID的解析支持不佳，会导致显示异常。你可以直接用FFmpeg自己读取验证：
```
ffmpeg -i output.wav -show_entries format_tags=umid -v quiet -of csv=p=0
```
如果FFmpeg自己读取出来的UMID和你写入的一致，那就是你之前用的读取工具的问题；如果FFmpeg读取也不对，那就是FFmpeg写入环节的bug。