详解Enhanced-RTMP支持H.265

Enhanced-RTMP H.265
2024年1月15日

详解Enhanced-RTMP支持H.265

2024-01-06 12:19·LiveVideoStack

编者按：很长时间以来，国内CDN都是通过“CodecID=0xC”的设置来实现H.265支持，但这未能彻底解决CodecID只有4个bits的尴尬，未来RTMP无法支持更多的编码标准。Enhanced-RTMP会彻底解决这一问题。如果你有兴趣分享自己的经验和思考，可以通过contribute@livevideostack.com联系我们。

文 / 小新快跑


千呼万唤使出来，rtmp/flv算是有统一支持H.265的国际版本。本文将介绍：

  • 现存rtmp/flv支持H.265的方式;

  • Enhanced-RTMP协议如何支持H.265;

  • ffmpeg/obs/srs/media-server各个开源的实现;

  • 国内方案与国外方案的兼容性问题。


1. rtmp/flv封装视频方式

准确的说，RTMP是传输协议，传输协议内部的封装是flv格式，其实我们所说的支持H.265，是在flv封装格式里面支持H.265编码数据。

flv对视频的封装格式, 原有VideoTagHeader定义如下: 

------------------------------------------------------------------------------------| FrameType(4bits) | CodecID(4bits) | AVCPacketType(8bits)| CompositionTime(24bits)|------------------------------------------------------------------------------------


其中：

  • FrameType: 4个bits, 1: keyframe, 也就是I帧; 2: inter frame, 非I帧，B帧或P帧；

  • CodecID: 4个bits,


1：JPEG (currently unused);

2：Sorenson H.263;

3：Screen video;

4：On2 VP6;

5：On2 VP6 with alpha channel;

6：Screen video version 2;

7：AVC;

这里如果是H.264，就是7。

  • AVCPacketType: 8个bits，也就是一个字节，0: AVC sequence header; 1: AVC NALU

  • CompositionTime: 3个字节(24bits)，表示pts与dts的差值；


举例:

  1. 如果视频数据是H.264的sequence header(也就是包含sps/pps的Avcc Header)，就应该是0x17 00;

  2. 如果视频数据是H.264的Iframe，就应该是0x17 01;

  3. 如果视频数据是H.264的非Iframe，就应该是0x27 01

  4. flv的标准中，只设定了H.264的codecId为7，之后的flv标准就没在针对video的codecId进行增加，这也就是导致后面rtmp/flv没有支持H.265的标准。


1.1. 国内rtmp/flv对H.265的支持

随着国内前10年移动互联网对直播需求的增加，对高清画质的需求与日俱增，支持H.265直播的需求很早就在各家CDN和云厂商成为top需求。

因此，国内云厂商和CDN厂商对H.265很早就支持，支持的方式比较简单，就是自定义H.265的CodecID=0xC，也就是CodecID值为12。

1: JPEG (currently unused);

2: Sorenson H.263;

3: Screen video;

4: On2 VP6;

5: On2 VP6 with alpha channel;

6: Screen video version 2;

7: AVC;

12: H.265(国内自定义H265的CodecID);

这样的自定义的好处：迅速解决了国内统一rtmp/flv支持H.265的格式标准；国内的CDN厂家的服务都遵循CodecID=12来实现rtmp/flv直播服务。

举例:

  • 如果视频数据是H.265的sequence header，就应该是0x1c 00;

  • 如果视频数据是H.265的Iframe，就应该是0x1c 01;

  • 如果视频数据是H.265的非Iframe，就应该是0x2c 01


国内的多个开源也都遵循国内的H.265标准：

  • SRS(https://github.com/ossrs/srs)

  • media-server(git@github.com:ireader/media-server.git)

  • ffmpeg_rtmp_h265 自定义补丁(https://github.com/runner365/ffmpeg_rtmp_h265)


但是，同样有其局限性：CodecID是自定义的，并且对CodecID只有4个bits的局限性没能解决，后面对新增的编码方式无法适用，如新增VP8，VP9, AV1，或未来的H.266，扩展会很难。

国外为准的流媒体开源，并未支持CodecId=12为H.265，如：

  • ffmpeg: 未支持CodecId=12为H.265;

  • obs: 未支持CodecId=12为H.265;


2. Enhanced-RTMP

Enhanced-Rtmp公布支持H.265的标准(
https://github.com/veovera/enhanced-rtmp)，彻底解决在rtmp/flv支持H.265的编码。

2.1 Enhanced-Rtmp规范

Enhanced-Rtmp规范（
https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp.pdf）

flv对视频的封装格式, 原有VideoTagHeader定义如下: 

------------------------------------------------------------------------------------| FrameType(4bits) | CodecID(4bits) | AVCPacketType(8bits)| CompositionTime(24bits)|------------------------------------------------------------------------------------


而Enhanced-RTMP对上面的格式进行修改：

首先FrameType第一个bit变为IsExHeader，如下 

-------------------------------------| IsExHeader(1bit)FrameType(3bits) |-------------------------------------

也就是在原FrameType的最高位加了1bit的IsExHeader标志位，如果IsExHeader使能，表示Enhanced-RTMP格式使能，后面的定义是Enhanced-Rtmp格式；否则还遵循之前的rtmp/flv传统规范。

格式的具体逻辑如下，UB代表bit的站位符(举例: UB[4]表示站位4bits) 

IsExHeader = (UB[4] & 0b1000 != 0) ? true : false;
FrameType = UB[4] & 0b0111; //1 = key frame, 2 = inter frameif (IsExHeader == 0)
{    //如果IsExHeader未使能， 还遵循之前的rtmp/flv传统规范
    CodecId = UB[4];//4bits的codecId，H.264的值为7.
    AVCPacketType = UB[8];//8bits的AVCPacketType， 0: sequence header; 1: NALU
    CompositionTime = UB[24];//24bits的CompositionTime，表示pts与dts的差值

    DATA = [H264 NALU]; //后续数据为常规的视频数据}else // IsExHeader使能，表示Enhanced-Rtmp格式使能{
    PacketType = UB[4];// 0 = PacketTypeSequenceStart
                       // 1 = PacketTypeCodedFrames
                       // 2 = PacketTypeSequenceEnd
                       // 3 = PacketTypeCodedFramesX
                       // 4 = PacketTypeMetadata
                       // 5 = PacketTypeMPEG2TSSequenceStart
    FourCC = UB[32];// 4字节的FourCC，如下字符表示对应的视频CodecId
                    // AV1 = { 'a', 'v', '0', '1' }
                    // VP9 = { 'v', 'p', '0', '9' }
                    // HEVC = { 'h', 'v', 'c', '1' }, 也就是h265

    // 如果类型是HEVC， 也就是H265，后续规范如下
    if (FourCC == HEVC)
    {        if (PacketType == PacketTypeSequenceStart)
        {            //如果PacketType是PacketTypeSequenceStart，表示后续H265的数据内容是DecoderConfigurationRecord，也就是常说的sequence header;
            DATA = [HEVCDecoderConfigurationRecord]
        }        else if (PacketType == PacketTypeCodedFrames || PacketType == PacketTypeCodedFramesX)
        {            if (PacketType == PacketTypeCodedFrames)
            {                //如果PacketType是PacketTypeCodedFrames，就是pts与dts有差值
                CompositionTime = UB[24];//24bits，表示pts与dts的差值
            }            else //如果PacketType是PacketTypeCodedFramesX
            {                //无CompositionTime，节省3字节的空间
            }            //随后是正常的H265数据
            DATA = [HEVC NALU]
        }
    }
}


2.2 ffmpeg6.1实现Enhance RTMP

ffmpeg在version6.1中正式支持Enhance RTMP，以此支持H.265 in rtmp/flv。这里介绍其对应的实现。

首先下载对应的ffmpeg6.1版本源码： 

git clone https://git.ffmpeg.org/ffmpeg.git ffmpegcd ffmpeggit fetch origin release/6.1git checkout release/6.1


flv封装的实现，对应文件: libavformat/flvenc.c 

static int flv_write_packet(AVFormatContext *s, AVPacket *pkt) {    //......
    // 如果编码格式是H265, 使用如下的实现
    if (par->codec_id == AV_CODEC_ID_HEVC) {        // 如果报文pts和dts不一样，packettype为PacketTypeCodedFrames；
        // 否则packettype为PacketTypeCodedFramesX
        int pkttype = (pkt->pts != pkt->dts) ? PacketTypeCodedFrames : PacketTypeCodedFramesX;        // 第一个字节，最高bit位写入FLV_IS_EX_HEADER；
        // 第一个字节，最高的第3, 4bits写入FLV_FRAME_KEY或FLV_FRAME_INTER
        // 第一个字节，最低2bits位，写入PacketTypeCodedFramesX或PacketTypeCodedFrames
        avio_w8(pb, FLV_IS_EX_HEADER | pkttype | frametype); // ExVideoTagHeader mode with PacketTypeCodedFrames(X)

        // 后4个字节，写入FourCC，写入4个字符: "hvc1"
        avio_write(pb, "hvc1", 4);        // pkttype为PacketTypeCodedFrames，写入3个字节的pts与dts的差值
        if (pkttype == PacketTypeCodedFrames)
            avio_wb24(pb, pkt->pts - pkt->dts);
    }    // 写入H.264的数据
    avio_write(pb, pkt->data, pkt->size);    // ......}


2.3 OBS实现Enhance RTMP

OBS在Release 29版本正式支持Enhance RTMP，实现H.265 in rtmp/flv的直播推流。

获取版本: 

git clone git@github.com:obsproject/obs-studio.gitcd obs-studiogit fetch origin release/29.1git checkout release/29.1


具体实现在:
plugins/obs-outputs/rtmp-stream.c 

enum packet_type_t {
PACKETTYPE_SEQ_START = 0, //表示报文序列开始PACKETTYPE_FRAMES = 1,    //表示该帧dts与pts有差值PACKETTYPE_SEQ_END = 2,   //flv文件最后一帧#ifdef ENABLE_HEVC
PACKETTYPE_FRAMESX = 3,   //表示该帧dts == pts#endif
PACKETTYPE_METADATA = 4};//函数flv_packet_ex的最后一个参数type为packet_type_t的取值范围void flv_packet_ex(struct encoder_packet *packet, enum video_id_t codec_id,   int32_t dts_offset, uint8_t **output, size_t *size, int type){// ........
    // packet ext header
    // 第一个字节，最高bit位写入1, FRAME_HEADER_EX = 8 << 4;
    // 第一个字节，最高的第3, 4bits写入FLV_FRAME_KEY或FLV_FRAME_INTER
    // 第一个字节，最低2bits位，写入PacketTypeCodedFramesX或PacketTypeCodedFrames, dts与pts相等或不等；
    //                       或写入PACKETTYPE_SEQ_START，或PACKETTYPE_SEQ_ENDs_w8(&s,
     FRAME_HEADER_EX | type | (packet->keyframe ? FT_KEY : FT_INTER));    // 后4个字节，写入FourCC，写入4个字符: "hvc1"s_w4cc(&s, codec_id);#ifdef ENABLE_HEVC// hevc composition time offsetif (codec_id == CODEC_HEVC && type == PACKETTYPE_FRAMES) {        // PacketType为PACKETTYPE_FRAMES，写入3个字节的pts与dts的差值s_wb24(&s, get_ms_time(packet, packet->pts - packet->dts));
}#endif

    // 写入h265的帧数据s_write(&s, packet->data, packet->size);
}


2.4 SRS实现Enhance RTMP

SRS是国内最流行的流媒体服务器，支持多种直播协议RTMP, httpflv, HLS，支持WebRTC，也支持安防协议28181。SRS也率先支持Enhance RTMP，服务端能够接受Enhance RTMP的推流，同时也兼容国内CodecId=12的H.265的rtmp方案。

但是在rtmp或httpflv拉流方向，是应用国内CodecId=12的H.265的rtmp方案。

SRS的github地址:
https://github.com/ossrs/srs.git, 当前支持分支develop。

实现主要在srs_kernel_codec.cpp这个文件中。 

srs_error_t SrsFormat::video_avc_demux(SrsBuffer* stream, int64_t timestamp) {
    uint8_t frame_type = stream->read_1bytes();    bool is_ext_header = frame_type & 0x80;    //判断Rtmp Enhance是否支持，从而获取到编码类型
    if (!is_ext_header) {        // 如果不是Rtmp Enhance，用传统的方式判断
        codec_id = (SrsVideoCodecId)(frame_type & 0x0f);
        frame_type = (frame_type >> 4) & 0x0f;
    } else {        // 如果使能Rtmp Enhance，获取packet_type和frame_type
        packet_type = (SrsVideoAvcFrameTrait)(frame_type & 0x0f);
        frame_type = (frame_type >> 4) & 0x07;        // 读取4个字节的FourCC，判断是否是HEVC.
        uint32_t four_cc = stream->read_4bytes();        if (four_cc == 0x68766331) { // 'hvc1'=0x68766331
            codec_id = SrsVideoCodecIdHEVC;
        }
    }    //判断Rtmp Enhance是否支持，从而获取到composition_time(dts与pts的差值)
    if (!is_ext_header) {        // 如果是传统的Rtmp，读取1个字节的packet_type，和3个字节的composition_time
        packet_type = (SrsVideoAvcFrameTrait)stream->read_1bytes();
        composition_time = stream->read_3bytes();
    } else {        // 如果使能Rtmp Enhance，当packet_type==1的时候，dts才与pts不一致，才读取3个字节的composition_time，
        // 否则没有composition_time字段；
        if (packet_type == 1) {
            composition_time = stream->read_3bytes();
        }
    }
}


2.5 media-server实现Enhance RTMP

media-server是国内开源库中实现音视频格式和流媒体类型最全的开源之一，支持flv, mp4, mkv, hls, mpeg, rtmp, rtp, rtsp, sip等音视频格式和流媒体协议，并且在各种封装中支持的codec非常丰富，如H.264, H.265, AV1, H.266都有支持。其采用C语言开发，兼容性好，同时适合服务器和嵌入式的开发。

media-server的github地址:
https://github.com/ireader/media-server

media-server的Flv模块同时支持demuxer和muxer，对Enhance RTMP支持比较全，同时支持AV1, H.265, H.266。(居然还支持H.266，并且有H.266 annexb to mp4和H.266 mp4 to annexb的代码)

Enhance RTMP的实现主要在flv-header.c这个文件中, 关键的对应代码如下: 

// demuxerint flv_video_tag_header_read(struct flv_video_tag_header_t* video, const uint8_t* buf, size_t len) {    // 如果第一个bit是1，则Enhance Rtmp使能
    if (len >= 5 && 0 != (buf[0] & 0x80)) {
video->keyframe = (buf[0] & 0x70) >> 4; //获取到是否keyframevideo->avpacket = (buf[0] & 0x0F); //获取packettypevideo->cts = 0; // default

        switch(FLV_VIDEO_FOURCC(buf[1], buf[2], buf[3], buf[4]))
        {    case FLV_VIDEO_FOURCC_AV1:
      video->codecid = FLV_VIDEO_AV1;      return 5;    case FLV_VIDEO_FOURCC_HEVC:    case FLV_VIDEO_FOURCC_VVC:
            {                if (video->avpacket == 1) //如果packettype==1，则dts与pts的差值存在
                {
                    video->cts = ((uint32_t)buf[5] << 16) | ((uint32_t)buf[6] << 8) | buf[7];
                }                return 5;
            }
        }
    }    //否则走传统flv的解析流程
    //....}// muxer: 通过编译宏控制int flv_video_tag_header_write(const struct flv_video_tag_header_t* video, uint8_t* buf, size_t len)
{#ifdef FLV_ENHANCE_RTMPbuf[0] = 0x80 | (video->keyframe << 4) /*FrameType*/;
buf[0] |= (0 == video->cts && FLV_AVPACKET == video->avpacket) ? FLV_PACKET_TYPE_CODED_FRAMES_X : video->avpacket;switch (video->codecid)
{case FLV_VIDEO_AV1:
        SetFourCC(&buf[1], FLV_VIDEO_FOURCC_AV1);return 5;case FLV_VIDEO_H265:
        SetFourCC(&buf[1], FLV_VIDEO_FOURCC_HEVC);if (len >= 8 && FLV_AVPACKET == video->avpacket && video->cts != 0)
{
            SetCTS(&buf[5], video->cts);return 8;
}return 5;case FLV_VIDEO_H266:
        SetFourCC(&buf[1], FLV_VIDEO_FOURCC_VVC);if (len >= 8 && FLV_AVPACKET == video->avpacket && video->cts != 0)
{
SetCTS(&buf[5], video->cts);return 8;
}return 5;default:break; // fallthrough}#endif

    //否则走传统flv的muxer流程}


3. 国内RTMP支持H.265与Enhance RTMP的兼容性问题

因为国内之前支持H.265的方案是CodecID=12，现在存在的兼容性其实有两个方向：

  • 推流方向(上行)

  • 拉流方向(下行)


3.1 推流方向

推流方向的兼容性，主要取决于服务端的兼容性，也就是说服务端必须同时能支持：

  • 国内CodecID=12的H.265方案

  • Enhance Rtmp的H.265方案


先说结论，上行推流方向的兼容性是没有问题，只需要在服务端做好兼容性，同时支持国内外的两种方案。

具体我们以SRS服务为例，只需要判断第一bit位是否使能，就能得知后面应该走RTMP Enhance流程，还是走传统的RTMP流程 

    bool is_ext_header = frame_type & 0x80;    //判断Rtmp Enhance是否支持，从而获取到编码类型
    if (!is_ext_header) {        // 如果不是Rtmp Enhance，用传统的方式判断
    } else {        // 如果使能Rtmp Enhance，获取packet_type和frame_type
        // 如果packet_type == 1，获取composition_time(3字节，dts与pts的差值)
    }


因为第一个bit位就能判断后续的代码处理流程，所以推流上行做兼容性是比较容易的；

上行解包后，形成数据结构的对象，将其传到下行拉流处，因为视频帧数据部分已经去掉flvTagHeader头，所以该对象传递到下行处理。

以下为伪码: 

class SrsVideoFrame{public:
    SrsVideoAvcFrameType frame_type; // 帧类型: I/非I
    SrsVideoAvcFrameTrait avc_packet_type;// 是否sequenche header等类型public:    int nb_samples; // 帧个数，
    SrsSample samples[SrsMaxNbSamples];// 帧数组，每个SrsSample是一个视频帧数据};


SrsVideoFrame中的SrsSample数据，是去掉flvTagHeader的视频帧数据，这样传递到下行后，可以根据需要再次打包flvTagHeader，下行可以再次打包成传统的CodecId=12的H.265格式，也可以打包成Enhance RTMP格式(因为下行的兼容性问题，不推荐下行打包成Enhance RTMP格式，下一节会说明原因)


3.2 拉流方向

拉流方向的兼容性，主要取决于客户端的兼容性，也就是rtmp或http-flv拉流播放器端的兼容性。

因为之前国内的大多数已有的播放器，都支持CodecId=12的H.265方案，现存市场很多播放器是没能支持Enhanche RTMP，也就是说即使服务端下行方向支持Enhance RTMP，把Enhance RTMP流推给客户端，客户端可能存在不能识别的情况。对于大量存量的rtmp/http-flv播放器(仅仅支持CodecId=12的H.265方案)，向下的流推送只能继续采用CodecId=12的H.265方案。

所以，当前国内大多数云服务商和CDN在下行方向，都仅仅支持CodecID=12的国内H.265方案。

总结

简单一句话总结兼容性：上行推流国内外两种推流都能兼容，但是下行仅仅提供CodecID=12的国内H.265方案支持。


还可输入800字
全部评论
作者介绍

文章

粉丝

视频
相关文章
阅读排行
  • 2周
  • 4周
  • 16周
热门视频

「线上分享」采用Zynq系列FPGA实现NDI AV over IP 应用

/

「线上分享」基于AMD MPSoC的AV over IP创新解决方案

/

「线上分享」AMD面向8K UHD应用解决方案

/

活动推荐
更多
  • 联系我们
  • 企业合作：sales@livevideostack.com
  • 内容合作：editor@livevideostack.com
  • 电话：010-59601402

@2017-2024 LiveVideoStack版权所有. 京ICP备20010033号-1 京公网安备 11010502042092号