对于任何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的内部实现有关。另外一点就是问题总是能解决的，不仅仅是不断试错，还需要不断克服一次次试错时的沮丧心理。