直播框架圖
引入HEVC編碼，涉及到的變動部分，上圖中的紅色字體已標注：
1.編碼模塊：需要支持HEVC格式的編解碼，該部分不屬于本文的介紹范疇，可自行查閱;
2.封裝/傳輸模塊：RTMP、HTTP-FLV流媒體協議需要增加對HEVC視頻編碼格式的支持，這一部分是本文介紹的重點。
廣大音視頻開發(fā)者對于FFmpeg并不陌生，由于它有著能在多媒體處理上提供強大功能、開源易于修改維護的特性，使得其被廣泛應用于各類音視頻軟件中。由于Adobe暫停了對RTMP/FLV標準的更新，所以目前標準中沒有支持HEVC視頻編碼格式。為避免各終端和服務器間的兼容性問題，FFmpeg也沒有在RTMP/FLV的協議實現中進行HEVC的相關擴展。CDN聯盟制定了相關的協議擴展規(guī)范，并在FFmpeg中完成了相關代碼實現。
FFmpeg簡析
開源程序FFmpeg發(fā)展至今，功能日益強大，很多初學者都被其眾多的源文件、龐大的結構體和復雜的算法打消了繼續(xù)學習的念頭。我們先從總體上對FFmpeg進行解析。
FFmpeg包含如下類庫：
libavformat – 用于各種音視頻封裝格式的生成和解析，包括獲取解碼所需信息、讀取音視頻數據等功能。各種流媒體協議代碼(如rtmpproto.c等)以及音視頻格式的(解)復用代碼(如flvdec.c、flvenc.c等)都位于該目錄下。
libavcodec – 音視頻各種格式的編解碼。各種格式的編解碼代碼(如aacenc.c、aacdec.c等)都位于該目錄下。
libavutil – 包含一些公共的工具函數的使用庫，包括算數運算，字符操作等。
libswscale – 提供原始視頻的比例縮放、色彩映射轉換、圖像顏色空間或格式轉換的功能。
libswresample – 提供音頻重采樣，采樣格式轉換和混合等功能。
libavfilter – 各種音視頻濾波器。
libpostproc – 用于后期效果處理，如圖像的去塊效應等。
libavdevice – 用于硬件的音視頻采集、加速和顯示。
如果之前沒有閱讀FFmpeg代碼的經驗，建議優(yōu)先閱讀libavformat、libavcodec以及l(fā)ibavutil下面的代碼，它們提供了音視頻開發(fā)的基本功能，應用范圍也最廣。
常用結構
FFmpeg里面最常用的數據結構，按功能可大致分為以下幾類(以下代碼行數，以branch: origin/release/3.4為準)：
1.封裝格式
AVFormatContext – 描述了媒體文件的構成及基本信息，是統(tǒng)領全局的基本結構體，貫穿程序始終，很多函數都要用它作為參數;
AVInputFormat – 解復用器對象，每種作為輸入的封裝格式(例如FLV、MP4、TS等)對應一個該結構體，如libavformat/flvdec.c的ff_flv_demuxer;
AVOutputFormat – 復用器對象，每種作為輸出的封裝格式(例如FLV,?MP4、TS等)對應一個該結構體，如libavformat/flvenc.c的ff_flv_muxer;
AVStream – 用于描述一個視頻/音頻流的相關數據信息。
2.編解碼
AVCodecContext – 描述編解碼器上下文的數據結構，包含了眾多編解碼器需要的參數信息;
AVCodec – 編解碼器對象，每種編解碼格式(例如H.264、AAC等)對應一個該結構體，如libavcodec/aacdec.c的ff_aac_decoder。每個AVCodecContext中含有一個AVCodec;
AVCodecParameters – 編解碼參數，每個AVStream中都含有一個AVCodecParameters，用來存放當前流的編解碼參數。
3.網絡協議
AVIOContext – 管理輸入輸出數據的結構體;
URLProtocol – 描述了音視頻數據傳輸所使用的協議，每種傳輸協議(例如HTTP、RTMP)等，都會對應一個URLProtocol結構，如libavformat/http.c中的ff_http_protocol;
URLContext – 封裝了協議對象及協議操作對象。
4.數據存放
AVPacket – 存放編碼后、解碼前的壓縮數據，即ES數據;
AVFrame – 存放編碼前、解碼后的原始數據，如YUV格式的視頻數據或PCM格式的音頻數據等;
上述結構體的關系圖如下所示(箭頭表示派生出)：
FFmpeg結構體關系圖
代碼結構
下面這段代碼完成了讀取媒體文件中音視頻數據的基本功能，本節(jié)以此為例，分析FFmpeg內部代碼的調用邏輯。
const char *url = “http://192.168.1.105/test.flv”;
AVPacket pkt;
int ret = 0;
//注冊復用器、編碼器等
av_register_all();
avformat_network_init();
//打開文件
AVFormatContext *fmtCtx = avformat_alloc_context();
ret = avformat_open_input(&fmtCtx, url, NULL, NULL);
ret = avformat_find_stream_info(fmtCtx, NULL);
//讀取音視頻數據
while(ret >= 0)
{
ret = av_read_frame(s, &pkt);
}
1.注冊
av_register_all函數的作用是注冊一系列的(解)復用器、編/解碼器等。它在所有基于FFmpeg的應用程序中幾乎都是第一個被調用的，只有調用了該函數，才能使用復用器、編碼器等。
static void register_all(void)
{
avcodec_register_all();
/* (de)muxers */
……
REGISTER_MUXDEMUX(FLV, flv);
……
}
REGISTER_MUXDEMUX實際上調用的是av_register_input_format和av_register_output_format，通過這兩個方法，將(解)復用器分別添加到了全局變量first_iformat與first_oformat鏈表的最后位置。
編/解碼其注冊過程相同，此處不再贅述。
2.文件打開
FFmpeg讀取媒體數據的過程始于avformat_open_input，該方法中完成了媒體文件的打開和格式探測的功能。但FFmpeg是如何找到正確的流媒體協議和解復用器呢？可以看到avformat_open_input方法中調用了init_input函數，在這里面完成了查找流媒體協議和解復用器的工作。
static int init_input(AVFormatContext *s, const char *filename, AVDictionary **options)
{
int ret;
……
if ((ret = s->io_open(s, &s->pb, filename, AVIO_FLAG_READ | s->avio_flags, options)) < 0)
return ret;
if (s->iformat)
return 0;
return av_probe_input_buffer2(s->pb, &s->iformat, filename,
s, 0, s->format_probesize);
}
(1)s->io_open實際上調用的就是io_open_default，它最終調用到url_find_protocol方法。
static const struct URLProtocol *url_find_protocol(const char *filename)
{
const URLProtocol **protocols;
……
protocols = ffurl_get_protocols(NULL, NULL);
if (!protocols)
return NULL;
for (i = 0; protocols[i]; i++) {
constURLProtocol *up = protocols[i];
if (!strcmp(proto_str, up->name)) {
av_freep(&protocols);
return up;
}
if (up->flags & URL_PROTOCOL_FLAG_NESTED_SCHEME && !strcmp(proto_nested, up->name)) {
av_freep(&protocols);
return up;
}
}
av_freep(&protocols);
return NULL;
}
ffurl_get_protocols可以得到當前編譯的FFmpeg支持的所有流媒體協議，通過url的scheme和protocol->name相比較，得到正確的protocol。例如本例中URLProtocol最終指向了libavformat/http.c中的ff_http_protocol。
(2)av_probe_input_buffer2最終調用到av_probe_input_format3，該方法遍歷所有的解復用器，即first_iformat鏈表中的所有節(jié)點，調用它們的read_probe()函數計算匹配得分，函數最終返回計算找到的最匹配的解復用器。本例中AVInputFormat最終指向了libavformat/flvdec.c中的ff_flv_demuxer。
3.數據讀取
av_read_frame作用是讀取媒體數據中的每個音視頻幀，該方法中最關鍵的地方就是調用了AVInputFormat的read_packet()方法。AVInputFormat的read_packet()是一個函數指針，指向當前的AVInputFormat的讀取數據的函數。在本例中，AVInputFormat為ff_flv_demuxer，也就是說read_packet最終指向了flv_read_packet。
FLV文件結構解析
FLV(FLASH VIDEO)，是一種常用的文件封裝格式，目前國內外大部分視頻分享網站都是采用的這種格式。其標準定義為《Adobe Flash Video File Format Specification》。RTMP協議也是基于FLV視頻格式的。
FLV的文件格式在該規(guī)范中已闡述清楚，本章節(jié)不再重復描述，而是結合下面的示例具體闡述如何分析FLV文件。
FLV文件結構示例1
FLV文件結構示例2
FLV文件的分析工具有很多，這里給大家推薦FLV Parser這個小軟件，通過它可以很容易的看到文件的組成結構。
文件結構
從整個文件上看，FLV是由Header和File Body組成，如下圖所示：
FLV文件總體結構
1.FLV Header – 長度為9，其結構的標準定義參見標準定義見E.2 The FLV header;
2.FLV File Body – 由一連串的PreviousTagSize + Tag構成。previousTagSize是4個字節(jié)的數據，表示前一個tag的size。標準定義參見E.3 The FLV File Body。
以FLV文件結構示例1這張圖為例，分析整體結構：
1.位置0x00000000 – 0x00000008, 共9個字節(jié)，為FLV Header，其中：
0x00000000 – 0x00000002 : 0x46 0x4C 0x56分別表示字符’F”L”V’，用來標識這個文件是FLV格式的。在做格式探測的時候，如果發(fā)現前3個字節(jié)為“FLV”，就認為它是FLV文件;
0x00000003 : 0x01, 表示FLV版本號;
0x00000004 : 0x05, 轉換為2進制是0000 0101，其中第0位為1，表示存在video，第2位為1，表示存在audio;
0x00000005 – 0x00000008 : 0x00 0x00 0x00 0x09，轉十進制為9，表示FLV header的長度，當FLV 版本號為1時，該值通常為9。
2.位置0x00000009 – ，為FLV File Body：
0x00000009 – 0x0000000C : 0x00 0x00 0x00 0x00 PreviousTagSize0，轉十進制為0，該值永遠為0;
0x0000000D – 0x00000209 : 0x12 … 0x09，共509個字節(jié)，為Tag1的具體內容;
0x0000020A – 0x0000020D : 0x00 0x00 0x01 0xFD，轉十進制為509，表示它前面的Tag，即Tag1的長度為509;
0x0000020E – ：按照Tag + PreviousTagSize的結構依次遞推，此處不再舉例說明。
Tag定義
FLV File Body是由一系列的PreviousTagSize + Tag組成，其中PreviousTagSize的長度為4個字節(jié)，用來表示前一個Tag的長度;Tag里面的數據可能是video、audio或者scripts，其定義參見E.4.1 FLV Tag，結構如下：
FLV Tag 結構
以圖3. FLV文件結構示例1為例分析Tag結構：
1.位置0x0000020E : 0x08, 二進制為0000 1000，第5位為0, 表示為非加擾文件;低5位01000為8，說明這個Tag包含的數據類型為Audio;
2.位置0x0000020F – 0x00000211 : 0x00 0x00 0x04，轉十進制為4，說明Tag的內容長度為4，與該tag后面的previousTagSize(15) – 11相同;
3.位置0x00000212 – 0x00000214 : 0x00 0x00 0x00，轉十進制為0，說明當前Audio數據的時間戳為0;
4.位置0x00000215 : 0x00，擴展時間戳為0，如果擴展時間戳不為0，那么該Tag的時間戳應為：Timestamp | TimestampExtended<<24;
5.位置0x00000216 – 0x00000218 : 0x00 0x00 0x00，StreamID，總是0;
6.StreamID之后的數據每種格式的情況都不一樣，下面會依次進行詳細解讀。
Audio Tags
如果TAG包中的TagType等于8，表示該Tag中包含的數據類型為Audio。StreamID之后的數據就是AudioTagHeader，其定義詳見E.4.2.1?AUDIODATA。結構如下：
FLV Audio Tag結構
需要說明的是，通常情況下AudioTagHeader之后跟著的就是AUDIODATA數據了，但有個特例，如果音頻編碼格式為AAC，AudioTagHeader中會多出1個字節(jié)的數據AACPacketType，這個字段來表示AACAUDIODATA的類型：
0 = AAC sequence header
1 = AAC raw。
以FLV文件結構示例這張圖為例，分析AudioTag結構：
1.位置0x00000219 : 0xAF, 二進制表示為1010 1111：
高4位為1010，轉十進制為10，表示Audio的編碼格式為AAC;
第3、2位為11，轉十進制為3，表示該音頻的采樣率為44KHZ;
第1位為1，表示該音頻采樣點位寬為16bits;
第0位為1，表示該音頻為立體聲。
2.位置0x0000021A : 0x00，十進制為0，并且Audio的編碼格式為AAC，說明AACAUDIODATA中存放的是AAC sequence header;
3.位置0x0000021B – 0x0000021C : AUDIODATA數據，即AAC sequence header。
AudioSpecificConfig
AAC sequence header中存放的是AudioSpecificConfig，該結構包含了更加詳細的音頻信息，《ISO-14496-3 Audio》中的1.6.2.1 章節(jié)對此作了詳細定義。
通常情況下，AAC sequence header這種Tag在FLV文件中只出現1次，并且是第一個Audio Tag，它存放了解碼AAC音頻所需要的詳細信息。
有關AudioSpecificConfig結構的代碼解析，可以參考ffmpeg/libavcodec/mpeg4audio.c中的avpriv_mpeg4audio_get_config方法。
為什么AudioTagHeader中定義了音頻的相關參數，我們還需要傳遞AudioSpecificConfig呢？
因為當SoundFormat為AAC時，SoundType須設置為1(立體聲)，SoundRate須設置為3(44KHZ)，但這并不意味著FLV文件中AAC編碼的音頻必須是44KHZ的立體聲。播放器在播放AAC音頻時，應忽略AudioTagHeader中的參數，并根據AudioSpecificConfig來配置正確的解碼參數。
Video Tag
如果TAG包中的TagType等于9，表示該Tag中包含的數據類型為Video。StreamID之后的數據就是VideoTagHeader，其定義詳見E.4.3.1 VIDEODATA，結構如下：
FLV Video Tag結構
VideoTagHeader之后跟著的就是VIDEODATA數據了，但是和AAC音頻一樣，它也存在一個特例，就是當視頻編碼格式為H.264的時候，VideoTagHeader會多出4個字節(jié)的信息，AVCPacketType和CompositionTime。
AVCPacketType用來表示VIDEODATA的內容。
CompositonTime相對時間戳，如果AVCPacketType=0x01，為相對時間戳，其它均為0;
以FLV文件結構示例2這張圖為例，分析VideoTagHeader結構：
1.位置0x0000022C : 0x17, 二進制表示為0001 0111：
高4位為0001，轉十進制為1，表示當前幀為關鍵幀;
低4位為0111，轉十進制為7，說明當前視頻的編碼格式為AVC。
2.位置0x0000022D : 0x00，十進制為0，并且Video的編碼格式為AVC，說明VideoTagBody中存放的是AVC sequence header;
3.位置0x0000022E – 0x00000230 : 轉十進制為0，表示相對時間戳為0;
4.位置0x00000231 – 0x0000021C : VIDEODATA數據，即AVC sequence header。
AVCDecoderConfigurationRecord
AVC sequence header中存放的是AVCDecoderConfigurationRecord，《ISO-14496-15 AVC file format》對此作了詳細定義。它存放的是AVC的編碼參數，解碼時需設置給解碼器后方可正確解碼。
通常情況下，AVC sequence header這種Tag在FLV文件中只出現1次，并且是第一個Video Tag。
有關AVCDecoderConfigurationRecord結構的代碼解析，可以參考中的ff_isom_write_avcc方法。
CompositionTime(相對時間戳)
相對時間戳的概念需要和PTS、DTS一起理解：
DTS : Decode Time Stamp，解碼時間戳，用于告知解碼器該視頻幀的解碼時間;
PTS : Presentation Time Stamp，顯示時間戳，用于告知播放器該視頻幀的顯示時間;
CTS : Composition Time Stamp，相對時間戳，用來表示PTS與DTS的差值。
如果視頻里各幀的編碼是按輸入順序依次進行的，則解碼和顯示時間相同，應該是一致的。但在編碼后的視頻類型中，如果存在B幀，輸入順序和編碼順序并不一致，所以才需要PTS和DTS這兩種時間戳。視頻幀的解碼一定是發(fā)生在顯示前，所以視頻幀的PTS，一定是大于等于DTS的，因此CTS=PTS-DTS。
FLV Video Tag中的TimeStamp，不是PTS，而是DTS，視頻幀的PTS需要我們通過DTS + CTS計算得到。
為什么Audio Tag不需要CompositionTime呢？
因為Audio的編碼順序和輸入順序一致，即PTS=DTS，所以它沒有CompositionTime的概念。
Script Data Tags
如果TAG包中的TagType等于18，表示該Tag中包含的數據類型為SCRIPT。
SCRIPTDATA 結構十分復雜，定義了很多格式類型，每個類型對應一種結構，詳細可參考E.4.4 Data Tags
onMetaData是SCRIPTDATA中一個非常重要的信息，其結構定義可參考E.5 onMetaData。它通常是FLV文件中的第一個Tag，用來表示當前文件的一些基本信息: 比如視音頻的編碼類型id、視頻的寬和高、文件大小、視頻長度、創(chuàng)建日期等。
HEVC在RTMP中的擴展
為推進HEVC視頻編碼格式在直播方案中的落地，經過CDN聯盟討論，并和主流云服務廠商達成一致，規(guī)范了HEVC在RTMP/FLV中的擴展，具體修改內容見下。
FLV規(guī)范擴展
HEVC為視頻編碼格式，因此對FLV規(guī)范的擴展，只集中在Video Tag，其它部分，無任何改動。
支持HEVC的VideoTagHeader
擴展后的VideoTagHeader如下圖所示(紅色字體為新增內容)：
支持HEVC的FLVTagHeader
修改點如下：
1.CodecID – 定義HEVC格式的值為12;
2.HEVCPacketType – 當CodecID == 12時，AVCPacketType為HEVCPacketType：
如果HEVCPacketType為0，表示HEVCVIDEOPACKET中存放的是HEVC sequence header;
如果HEVCPacketType為1，表示HEVCVIDEOPACKET中存放的是HEVC NALU;
如果HEVCPacketType為2，表示HEVCVIDEPACKET中存放的是HEVC end of sequence，即HEVCDecoderConfigurationRecord;
3.CompositionTime – 當CodecID == 12時，同樣需要CompositionTime。
支持HEVC的VideoTagBody
當CodecID為12時，VideoTagBody中存放的就是HEVC視頻幀內容。
擴展后的VideoTagBody如下圖所示(紅色字體為HEVC新增內容)：
支持HEVC的VideoTagBody
FFmpeg中的修改
我們已在FFmpeg的各個版本上提供相關的完整修改，具體參見：https://github.com/ksvc/FFmpeg，完整patch獲取及相關說明見：https://github.com/ksvc/FFmpeg/wiki。
由第二章節(jié)的闡述可知，FLV的解復用和復用功能代碼分別在libavformt/flvdec.c和libavformat/flvenc.c中，擴展后的修改也都集中在這兩個文件。本節(jié)將在FFmpeg3.3的基礎上，說明修改的關鍵點。
編碼類型定義
libavformat/flv.h中按照VideoTagHeader中的CodecID定義了一組視頻編碼格式的枚舉值，擴展后的枚舉定義如下：
enum {
FLV_CODECID_H263 = 2,
FLV_CODECID_SCREEN = 3,
FLV_CODECID_VP6 = 4,
FLV_CODECID_VP6A = 5,
FLV_CODECID_SCREEN2 = 6,
FLV_CODECID_H264 = 7,
FLV_CODECID_REALH263= 8,
FLV_CODECID_MPEG4 = 9,
FLV_CODECID_HEVC = 12,
};
FLV demux
在解復用過程中，flv_read_packet方法是整個過程的核心，它里面完成了對每個Tag的讀取和解析。
上面提到，如果HEVCPacketType為0時，表示HEVCVIDEOPACKET中存放的是HEVC sequence header，也就是HEVCDecoderConfigurationRecord，解碼時需設置HEVCDecoderConfigurationRecord方能正確解碼。
HEVC與AVC視頻幀在FLV中的存放格式相同，所以只需在讀取Video Tag的地方增加AV_CODEC_ID_HEVC的判斷條件即可，調整后的代碼如下：
if (st->codecpar->codec_id == AV_CODEC_ID_AAC ||
st->codecpar->codec_id == AV_CODEC_ID_H264 ||
st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
int type = avio_r8(s->pb);
size–;
if (st->codecpar->codec_id == AV_CODEC_ID_H264 ||
st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
// sign extension
int32_t cts = (avio_rb24(s->pb) + 0xff800000) ^ 0xff800000;
pts = dts + cts;
if (cts< 0) { // dts might be wrong
if (!flv->wrong_dts)
av_log(s, AV_LOG_WARNING,
“Negative cts, previous timestamps might be wrong.\n”);
flv->wrong_dts = 1;
} else if (FFABS(dts – pts) > 1000*60*15) {
av_log(s, AV_LOG_WARNING,
“invalid timestamps %”PRId64″ %”PRId64″\n”, dts, pts);
dts = pts = AV_NOPTS_VALUE;
}
}
if (type == 0 &&(!st->codecpar->extradata ||
st->codecpar->codec_id == AV_CODEC_ID_AAC ||
st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
st->codecpar->codec_id == AV_CODEC_ID_H264)) {
AVDictionaryEntry *t;
if (st->codecpar->extradata) {
if ((ret = flv_queue_extradata(flv, s->pb, stream_type, size)) < 0)
return ret;
ret = FFERROR_REDO;
goto leave;
}
if ((ret = flv_get_extradata(s, st, size)) < 0)
return ret;
……
}
}
AVCDecoderConfigurationRecord和HEVCDecoderConfigurationRecord都是存放在AVStream->AVCodecParameter->extradata中。
FLV mux
FLV mux的修改相對較多、header、packet、trailer中均有涉及。
flv_write_header中主要完成了以下工作：
1.寫入FLV Header;
2.寫入Metadata;
3.如果音頻編碼格式為AAC，則寫入第一個Audio Tag，其AudioTagBody中存放的是AAC sequence header;
4.如果視頻編碼格式為AVC，則寫入第一個Video Tag，其中VideoTagBody中存放的是AVC sequence header。
同樣，當視頻編碼格式HEVC時，也要寫入第一個VideoTag，其中VideoTagBody中存放的是HEVCDecoderConfigurationRecord，修改點如下：
avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
avio_w8(pb, 0); // AVC sequence header
avio_wb24(pb, 0); // composition time
if (par->codec_id == AV_CODEC_ID_HEVC)
ff_isom_write_hvcc(pb, par->extradata, par->extradata_size, 0);
else
ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
ff_isom_write_hvcc的作用是將extradata轉為HEVCDecoderConfigurationRecord結構并寫入。
flv_write_packet的作用是寫入音視頻幀，其中有關寫入video數據的地方，都需要加上AV_CODEC_ID_HEVC的判斷條件，修改內容如下：
else if (par->codec_id == AV_CODEC_ID_HEVC ){
if (par->extradata_size> 0 && *(uint8_t*)par->extradata != 1)
if ((ret = ff_hevc_annexb2mp4_buf(pkt->data, &data, &size, 0, NULL)) < 0)
return ret;
}
ff_hevc_annexb2mp4_buf方法的作用是將Annex-B格式的HEVC視頻幀轉為HVCC格式。
AnnexB與AVCC/HVCC(ISO/IEC14496-15中所定義，通常也稱為MPEG-4格式)的區(qū)別在于參數集與幀格式，AnnexB的參數集sps、pps以NAL的形式存在碼流中(帶內傳輸)，以startcode分割NAL。而HVCC 的參數集存儲在extradata中(帶外傳輸)，使用NALU長度(固定字節(jié)，通常為4字節(jié)，從extradata中解析)分隔NAL。
結束時需要寫入HEVC end of sequence，其格式與AVC end of sequence相同，直接復用即可，flv_write_trailer的修改內容如下：
if (par->codec_type == AVMEDIA_TYPE_VIDEO &&
(par->codec_id == AV_CODEC_ID_H264 || par->codec_id == AV_CODEC_ID_HEVC || par->codec_id == AV_CODEC_ID_MPEG4))
put_avc_eos_tag(pb, sc->last_ts);
總結
本文對如何在FFmpeg中擴展rtmp協議，從而支持HEVC編碼格式進行了介紹。如果將HEVC應用于直播整體方案，除了推流端和播放端需要提供相應能力以外，包括源站、CDN、轉碼服務，均需要提供這種能力。目前，作為視頻云行業(yè)的領跑者，金山云的所有視頻服務已完全支持HEVC視頻編碼格式，歡迎大家使用。對于直播、短視頻與HEVC的更多技術問題，我們會在接下來的系列文章中與大家繼續(xù)探討。
