RTMP 直播 H265 推流适配总结

1、在iOS11的系统之上，苹果逐渐放开H265硬编硬解的能力，硬解码的能力只要升级到iOS11之后，iPhone6+以上的机型就支持了（印象中）；

　 H265硬编码的能力对设备要求较高，不仅要求系统版本在iOS11以上，并且设备在iPhone8以上（目前验证到），部门ipad设备在调用系统API检测是否支持HEVC编码的时候，

　 虽然返回True，但是依然编码返回错误。

　 所以我使用了一段真实的硬编代码进行测试机器到底是否支持硬编码：

　　

//尝试创建H265硬编码器检测是否支持H265
bool SurpportHW265()
{
    if (@available(iOS 11.0, *)) {
        if(VTIsHardwareDecodeSupported(kCMVideoCodecType_HEVC))
        {
            VTCompressionSessionRef _encodingSession = nil;
            CFMutableDictionaryRef sessionAttributes = CFDictionaryCreateMutable(
                                                                                 NULL,
                                                                                 0,
                                                                                 &kCFTypeDictionaryKeyCallBacks,
                                                                                 &kCFTypeDictionaryValueCallBacks);
            // 创建编码
            OSStatus status = VTCompressionSessionCreate(kCFAllocatorDefault,
                                                         (int32_t)640,
                                                         (int32_t)1136,
                                                         kCMVideoCodecType_HEVC,
                                                         sessionAttributes,
                                                         NULL,
                                                         NULL,
                                                         NULL,
                                                         NULL,
                                                         &_encodingSession);
            
            NSLog(@"H264: VTCompressionSessionCreate %d", (int)status);
            
            if (status == 0)
            {
                VTCompressionSessionCompleteFrames(_encodingSession, kCMTimeInvalid);
                // End the session
                VTCompressionSessionInvalidate(_encodingSession);
                CFRelease(_encodingSession);
                _encodingSession = NULL;
                return true;
            }
        }
    }
    return false;
}

　　

2、RTMP推流 扩展支持 H265

　RTMP协议是基于TCP协议的，RTMP协议中推流中目前广泛使用了一种类似FLV Tag的格式，FLV的格式相对非常简单，从开始到结束一般分为

　FLV FILE HEADER + FLV FILE BODY

   其中  FLV FILE HEADER 一般9个字节，标记了后面的FLV数据中是否包含音频或者视频的一些信息；头三个字节对应FLV的ascii码

　其中  FLV FILE BODY 又分为下面的结构

   prev_tag_size + NextTagHeader + NextTagData | prev_tag_size + NextTagHeader + NextTagData | prev_tag_size + NextTagHeader + NextTagData | 。。。。

　以上的结构不停循环

　prev_tag_size 为4个字节，标记前面一个TagHeader + TagData 的大小， 第一个Tag因为之前没有，所以四个字节为0，这里4个字节为大端序

   NextTagHeader 一般为11个字节，里面包含 tag类型，时间戳， 数据大小等等

   NextTagData 是真正的数据，也就是H264或者H265的NALU的裸数据（去掉开始码）

3、一个完整的FLV 结构类型

　　一个推流完整的FLV ，在RTMP建立连接之后会：

　　先发一个 MetaData的包，这个包对应TagType 为 Script Tag

　　发一个 Video SequenceHeader 的Tag， 这个Tag 在RTMP的payload 对应的帧类型和编码类型【是17或者27】 + 【NALU类型是00】+【000000】（三个字节无意义）+ ConfigurationRecord（二进制数据）

　　发一个 Video 视频数据的Tag， 这个Tag 在RTMP的payload 对应的帧类型和编码类型【是17或者27】 + 【NALU类型是01】+【000000】（三个字节无意义）+ 【nalu size】（四个字节）+ 【nalu data】　

　　注意上面音视频的格式不一样，视频数据的封包头多了4个字节标记每个NALU的大小；如果视频中payload包含多个NALU，那么每个NALU前面都需要加上 【nalu size】（四个字节）

　

5、推H265和H264做了哪些改变

　　1、音频保持不变

　　2、视频的metadata 的 script tag中有一个编码类型，H264的时候为7 ， H265的时候需要改成自定义类型

　　3、视频的 Video SequenceHeader 的Tag 中的  ConfigurationRecord 需要更新为 HEVCDecoderConfigurationRecord 类型，这个结构体是公开的

　　4、 Video 视频数据的Tag 中， 帧类型和编码类型【是17或者27 后四个比特，标记编码类型，需要自己制定类型

6、一些经验

　　因为FLV目前没有兼容H265的标准，所以建议在VideoTag中每个关键帧的数据之前加上 VPS NALU| PPS_NALU|SPS_NALU|VIDEO_NALU 格式；每个NALU = NALU Size（4个字节）+ NALU Raw Data

　　H265相比H264更省带宽，而且编码输出的质量更高，相等码率下面的流，H265明显比H264清晰