level 1
最新版的视骏解码器不行吗？我试过mp4封的HM可以正常播放
2013年07月26日 08点07分
level 12
level 1
level 4
确定是MP4Box生成的CTTS表有问题。
我估计问题是这样产生的（猜测）：
由于有B帧，显示时间戳会回退；ISO14496-12规定stts表（TimeToSampleBox）中记录的是每帧的Duration，由这个表算出解码时间戳，另外ctts表（CompositionOffsetBox）用来存储显示时间戳和解码时间戳的差距offset，用来计算显示时间戳，但是规范规定CTTS表中存储的offset是无符号整数，这就导致打包程序必须确定一个显示时间戳最大回退量，并加到所有的CTTS表项上，否则可能导致CTTS表项为负数，不符合规范。
在这个具体的例子中，MP4Box确定的显示时间戳最大回退值为1700，换算成毫秒是680ms，这个1700被加到计算出来的Offset上，结果就是CTTS，这就导致整个视频的所有帧的显示时间戳都增大680ms。而音频帧可能没有这个问题，也没有做相应的调整，导致音视频不同步！
以上只是猜测，不过确定此问题应该是MP4Box的问题，可以提交Bug了。
2013年07月27日 07点07分
4
我估计问题是这样产生的（猜测）：
由于有B帧，显示时间戳会回退；ISO14496-12规定stts表（TimeToSampleBox）中记录的是每帧的Duration，由这个表算出解码时间戳，另外ctts表（CompositionOffsetBox）用来存储显示时间戳和解码时间戳的差距offset，用来计算显示时间戳，但是规范规定CTTS表中存储的offset是无符号整数，这就导致打包程序必须确定一个显示时间戳最大回退量，并加到所有的CTTS表项上，否则可能导致CTTS表项为负数，不符合规范。
在这个具体的例子中，MP4Box确定的显示时间戳最大回退值为1700，换算成毫秒是680ms，这个1700被加到计算出来的Offset上，结果就是CTTS，这就导致整个视频的所有帧的显示时间戳都增大680ms。而音频帧可能没有这个问题，也没有做相应的调整，导致音视频不同步！
以上只是猜测，不过确定此问题应该是MP4Box的问题，可以提交Bug了。
gpac/src/media_tools/media_import.c 5448行开始
2013年07月27日 07点07分
我不太清楚这个问题最好的解决办法是什么，不同的解决办法可能需要修改不同的地方； 有一个办法是直接向CTTS中写入PTS-DTS的值，而不增加一个最大回退量，这样会导致CTTS表中大部分为负数，虽然不符合规范，但是我发现大部分（我接触到的所有）播放器都可以正常播放。这也是最简单的解决办法。
2013年07月27日 08点07分
如果非要严格符合规范，那恐怕要调整音频时间戳，或者在音频Track头部增加一个EditBox来将音频Track向后偏移一定时间。
2013年07月27日 08点07分
回复 hugeice :H264同样有B参考，为何并没有类似的问题。我觉得解决办法不是从音频上入手
2013年07月27日 08点07分
