MediaCodec的相关数据时间单位为(纳秒/1000),类似610,729,613,772, 倒数第7位代表秒级
描述:写入数据失败
这类错误基本和时间戳有关
现象 | 解决 |
---|---|
吐出时间戳倒退 | 丢弃异常帧(经测试无影响,且量级不大) |
吐出时间戳相等 | 丢弃异常帧(有些机器能接受相等的数据,为了通用性还是丢弃) |
分析问题需要区分音频视频各自的时间戳查看
示例
第二行ts小于第一行的ts,第三行正常
writeSampleData size = 186, ts = 621441165854
writeSampleData size = 186, ts = 621441065854
writeSampleData size = 185, ts = 621441131957
这是错误的音频写入日志,writeSampleData Failed会在第三行写入时候才会爆出来。所以分析此类问题可能需要往前多找几帧,出现问题的帧数据不一定是当前的帧
两个队列管理入队出队,原始数据给到input,通过output吐出来
如果input和output在不同线程,因为两边处理速率不一致,会导致input数据来不及消费,导致部分原始数据被覆盖(丢弃),最终形成的现象就是音频会加快,鬼畜。视频丢弃就会卡顿。
这类问题一般两种情况,时间戳不对,部分数据帧被都丢弃
建议时机:dequeueOutputBuffer返回MediaCodec.INFO_OUTPUT_FORMAT_CHANGED更新MediaMuxer.addTrack, 所有的track完成之后再触发start。
音频:dequeueOutputBuffer返回MediaCodec.INFO_OUTPUT_FORMAT_CHANGED触发新MediaMuxer.addTrack 视频:dequeueOutputBuffer返回MediaCodec.INFO_OUTPUT_FORMAT_CHANGED触发新MediaMuxer.addTrack MediaMuxer:所有track add完成之后触发start
有些机型,音频 or 视频初始化很慢,时间错开,导致另一个通道数据到达之后,因为MediaMuxer没有start,所以这部分数据默认被丢弃了。
一般出现这类问题的场景如下,需要做逻辑保护
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。