代码改变世界

iOS VideoToolBox decoder解码失败(-12909和-12911)问题解决

2018-09-02 20:21  jiayayao  阅读(4687)  评论(0编辑  收藏  举报

    对于任何H.264解码器而言,都要将SPS和PPS信息传递给解码器。FFmpeg内部做了设置,所以没有显示设置。但是对于硬件解码器来讲,开发者必须手动设置。另外,使用FFmpeg解码出来的视频帧是以YUV格式存储于内存中的,但是对于硬件解码器来讲,一般都是直接解码到显存,便于后续的处理与渲染。H.264有两种封装格式,一种是Annexb封装,另外一种是mp4(AVCC)封装。输入数据给解码器时需要特定的格式。VTB decoder要求的是mp4(AVCC)格式的输入,而MediaCodec要求的是Annexb格式的输入。但是FFmpeg解封装出来的AVPacket通常是mp4(AVCC)格式的。

    最近被拉去解决一个iOS VTB解码失败的问题,现象是省流模式下DecodeFrame时返回-12911,callback里返回-12909,标清以上没有这个问题。

问题分析:

1. 视频源有没有问题?省流模式下H.264的profile是baseline,是否跟这个有关系?

iOS系统播放器播放正常,所以跟baseline无关;PC VLC播放正常,所以视频源没有什么问题。

2. 是否是SPS/PPS等参数设置有问题?

仔细查看SPS/PPS设置的字节数和内容,其中H.264的extradata的格式有做转换,但是仔细分析,确实没有问题。另外如果有问题,标清模式以上应该也有这个问题。

3. 传入的数据包有无区别?

最开始分析的是省流和标清模式传递的数据包有无区别,仔细分析后,发现一切正常,传入的字节数跟具体内容都是正确的。

    网上搜索-12909和-12911提示的都是传入的数据包有误,但是分析下来,确实没发现什么问题。这时候只能对比其他开源软件的做法了。编译了ijkplayer的demo,传入省流的url,断点分析其VTB代码逻辑。这里主要是因为VTB有几套API,我们的程序跟ijkplayer用的API还不完全一致,一开始以为是API调用错误导致的,后来对齐API后,问题还是没有解决。然后接着分析了SPS/PPS传递逻辑和传递的第一个数据包,注意,一定要是第一个AVPacket,才能排除其他外界因素的干扰。

问题定位:

    对比ijkplayer,我们送入的第一个AVPacket要比ijkplayer多了十几个字节,这十几个字节实际上存储了MPEG格式的streamID。但是ijkplayer调用了av_packet_split_side_data将读取到的pkt的最后的side_data去除了,而我们的程序没有去除side_data。去除side_data后,首帧解码成功,问题解决。

思考:

    这个问题的诡异就在于同样的程序标清以上解码是ok的,省流解码就有问题,导致一开始查问题的思路偏了,猜测这应该与VTB的内部实现有关。另外一点就是问题总是能解决的,不仅仅是不断试错,还需要不断克服一次次试错时的沮丧心理。