SEI(Supplemental Enhancement Information)

流媒體是採用流式傳輸方式在網絡上播放的媒體格式,視頻網站內容、短視頻、在線直播這些視頻形態,均屬於流媒體的不同分支。流媒體大致包含三個層級:碼流、封裝和協議。從音視頻編碼器輸出的碼流,經過某種封裝格式後,經過特定的協議傳輸、保存,構成了流媒體世界的基礎功能。

在直播應用的開發過程中,如果把主播端消息事件傳遞到觀衆端,一般會以Instant Messaging(即時通訊)的方式傳遞過去,但因爲消息分發通道和直播通道是分開的,因此消息與直播音視頻數據的同步性就會出現很多問題。那麼有沒有在音視頻內部傳遞消息的方法呢?答案是SEI

1. SEI的介紹

補充增強信息(Supplemental Enhancement Information)是碼流範疇裏面的概念,提供了向視頻碼流中加入信息的辦法,是H.264/H.265 視頻壓縮標準的特性之一。SEI 有基本的特徵:

  1. 並不是解碼過程的必須項;
  2. 有可能對解碼過程(容錯、糾錯)有幫助;
  3. 集成在視頻碼流中;

這意味着視頻編碼器在輸出視頻碼流的時候,可以不提供SEI信息 。同時我們也要清楚:視頻傳輸過程、解封裝、解碼環節,都可能因爲某種原因丟棄SEI

在視頻內容的生成端、傳輸過程中,都可以插入SEI 信息。插入的信息,和其他視頻內容一起經過傳輸鏈路到達了消費端。那麼在SEI 中可以添加哪些信息呢?這裏舉幾個例子,用戶場景可以任意擴展:

  1. 傳遞編碼器參數;
  2. 傳遞視頻版權信息;
  3. 傳遞攝像頭參數;
  4. 傳遞內容生成過程中的剪輯事件(引發場景切換);

1.1 NAL unit類型

網絡抽象層(Network Abstract Layer)簡稱爲NAL。在H.264/AVC視頻編碼標準中,整個系統框架被分爲了兩個層面:視頻編碼層面(Video Coding Layer - VCL)和網絡抽象層面(Network Abstraction Layer - NAL)。VCL負責表示有效視頻數據的內容,NAL 負責格式化數據並提供頭信息,以保證數據適合各種信道和存儲介質上的傳輸。NAL unitNAL的基本語法結構,它包含一個字節的頭信息(NAL header)和一系列來自VCL的原始數據字節流(RBSP)。

1.1.1 H.264/AVC 中的情況

NAL unit type儲存在NAL header中,在H.264/AVC標準中,可用的NAL unit type一共有17種,其中值爲6時表徵SEI 內容。比較常見的類型如下表所示:

NAL unit type NAL unit content
1 非IDR圖像,且不採用數據劃分的片段
5 IDR圖像
6 補充增強信息(SEI)
7 序列參數集(SPS)
8 圖像參數集(PPS)
11 流結束符

《ISO/IEC 14496-10:2014》是MPEG專家組爲AVC編解碼器制定的標準,H.264/AVCNAL unit類型完整定義都在該標準的7-1表中,標準一共預留了32種類型,所以在NAL header裏面,用5 bits表徵NAL unit type

如下圖所示,8 bits的NAL header裏面:

  1. 第0位是禁止位0,值爲1時表示語法出錯;
  2. 第1~2位爲參考級別(NRI,NAL ref idc);
  3. 第3~7爲是NAL unit type;

nal_unit_type in H.264/AVC

NRI取值爲 "00" (二進制)時,表徵NAL unit不參與重建參考圖像,這時的NAL unit是可以丟棄的。大於 "00"(二進制)時,NAL unit 不能被丟棄。

1.1.H.265/HEVC 中的情況

《ISO/IEC 23008-2:2015》是MPEG專家組爲HEVC編解碼器制定的標準,H.265/HEVCNAL unit類型完整定義都在該標準的7-1表中,可用的NAL unit type一共有40種之多,其中39和40都表徵SEI內容。因爲標準一共預留64種類型,所以在NAL header裏面,用6 bits表徵NAL unit type

如下圖所示,16 bits的NAL header裏面:

  1. 第0位是禁止位0,值爲1時表示語法出錯;
  2. 第1~6位是NAL unit type
  3. 第7~12位是NUH layer id
  4. 第13~15位是temporal_id

nal_unit_type in H.265/HEVC

1.2 SEI 類型

H.264/AVC視頻編碼標準中,並沒有規定SEI payload type的範圍,所以表徵payload type的字節數是浮動的。
語法分析如下所示,當開始解析類型爲SEINAL時,持續讀取8bit,直到非0xff爲止,然後把讀取的數值累加,累加值即爲SEI payload type

sei_message(){
  payloadType = 0
  while( next_bits(8) == 0xFF){
    ff_byte
    payloadType += 255
  }
  last_payload_type_byte
  payloadType += last_payload_type_byte
}

讀取SEI payload sizepayload type邏輯類似,仍然是讀取到0xff爲止,這樣可以支持任意長度的SEI payload添加。

sei_message(){
  payloadSize = 0
  while( next_bits(8) == 0xFF){
    ff_byte
    payloadSize += 255
  }
  last_payload_size_byte
  payloadSize += last_payload_size_byte
}

當獲取了SEI payload類型和大小後,就進入了實際的SEI內容讀取。
當前《ISO/IEC 14496-10:2014》Annex D.1.1提供了最大到181的payload類型處理規範,由於類型可以指定任意大小,給SEI的添加、處理創造了很大的自由空間。
其中SEI payload類型值爲5時,指定的處理方法叫user_data_unregistered(),字面含義爲未註冊的用戶數據,常用於存儲編碼器的編碼參數信息,是比較常見的payload類型。

讀取payload type爲5時,具體的語法解析流程如下:

user_data_unregistered(payloadSize){
  uuid_iso_iec_11578
  for( i=16; i< payloadSize; i++)
    user_data_payload_byte
}

其中uuid_iso_iec_11578的詳細定義在《
ISO/IEC 11578:1996》Annex A中,大致規定了使用128bits(16個字節)來指定UUID。此處UUID可以表徵寫入SEI payload的角色ID,或者表徵其他業務用途。剩下的payloadSize -16字節,即是業務層傳遞的具體內容了。
通過user_data_unregistered()語法解析可以看出,當使用SEI payload type爲5時,注意事項如下:

  1. payload size應該大於16;
  2. uuid可能出現0x000000/0x000001/0x000002,需要插入0x03做防競爭處理;

構成RBSP時,都需要做RBSP拖尾處理。拖尾處理對所有SODB方式都一致。rbsp_trailing_bits()語法邏輯如下:

rbsp_trailing_bits( ){
  rbsp_stop_one_bit
  while( !byte_aligned( ) )
    rbsp_alignment_zero_bit
}

1.3 SEI例子

video.js的示例中下載oceans.mp4並提取出H.264碼流如下:

bitstream from oceans.mp4

NAL header

起始碼(暗紅底色)"0x00000001"分割出來的比特流即是NAL unit,起始碼緊跟的第一個字節(墨綠底色)是NAL header。上圖“NAL header”一共出現了四個數值:

  • "0x06",此時NRI爲"00B",NAL unit type爲SEI類型。
  • “0x67”,此時NRI爲“11B”,NAL unit type爲SPS類型。
  • “0x68”,此時NRI爲“11B”,NAL unit type爲PPS類型。
  • “0x65”,此時NRI爲“11B”,NAL unit type爲IDR圖像。

SEI payload type

"0x06"後一個字節爲“0x05”(淡黃底色)是SEI payload type,即表徵SEI payload分析遵循user_data_unregistered()語法。

SEI payload size

“0x05”後一個字節爲“0x2F”(淡藍底色)是SEI payload size,此時整個payload是47個字節。

SEI payload uuid

"0x2F"隨後的16個字節即爲uuid,此時uuid爲

dc45e9bd-e6d9-48b7-962c-d820d923eeef

SEI payload content

由於payload size是47個字節,除去16字節的uuid,剩下31個字節的content。由於content是字符串,所以有結束符"0x00",有效的30個字符內容是:

Zencoder Video Encoding System

rbsp trailing bits

47個payload字節後的"0x80"(灰底色)即是rbsp trailing bits,在user_data_unregistered()裏面都是按字節寫入的,所以此時的NAL unit結尾寫入的字節一定是0x80

2. SEI的生成

生成SEI的方式很多,大致可以有:

  1. 對已有碼流做filter,插入SEI NAL
  2. 視頻編碼時生成SEI
  3. 容器層寫入時插入SEI

以下代碼示例來自於FFmpeg origin/master 分支。

2.1 bsf

BitStream Filter(碼流過濾)的縮寫即爲bsf,在不做碼流解碼的前提下,對已經編碼後的比特流做特定的修改、調整。

bsf h264_metadata的調用

The ff* tools have a -bsf option applied per stream, taking a comma-separated list of filters, whose parameters follow the filter name after a ’=’.
使用ffmpeg工具時,可以使用比特流過濾器。基本的filter調用格式如下:

ffmpeg -i INPUT -c:v copy -bsf:v filter1[=opt1=str1:opt2=str2][,filter2] OUTPUT

從上文提到的mp4文件中提取出h.264碼流oceans.h264,可以使用* h264_metadata比特流過濾器添加SEI*。下面示例命令添加了類型爲未註冊的用戶數據的SEI,其中uuid爲"086f3693-b7b3-4f2c-9653-21492feee5b8",payload內容爲"hello":

./ffmpeg  -I oceans.h264 -c:v copy -bsf:v h264_metadata=sei_user_data='086f3693-b7b3-4f2c-9653-21492feee5b8+hello' oceans.sei.h264

其中oceans.h264已經有一個SEI和28個SPS。輸出的oceans.sei.h264碼流中,共有28個SEI,其中第一個與輸入保持一致,剩下27個爲新插入的SEI

bsf h264_metadata的代碼分析

具體代碼位於:libavcodec/h264_metadata_bsf.c中。

// 函數int h264_metadata_filter(AVBSFContext *bsf, AVPacket *out)
if (ctx->sei_user_data && (has_sps || !ctx->sei_first_au)) {
        H264RawSEI *sei;
        H264RawSEIPayload *payload;
        H264RawSEIUserDataUnregistered *udu;
        int sei_pos, sei_new;

        ctx->sei_first_au = 1;

        for (i = 0; i < au->nb_units; i++) {
            if (au->units[i].type == H264_NAL_SEI ||
                au->units[i].type == H264_NAL_SLICE ||
                au->units[i].type == H264_NAL_IDR_SLICE)
                break;
        }
        sei_pos = i;

        if (sei_pos < au->nb_units &&
            au->units[sei_pos].type == H264_NAL_SEI) {
            sei_new = 0;
            sei = au->units[sei_pos].content;
        } else {
            sei_new = 1;
            sei = &ctx->sei_nal;
            memset(sei, 0, sizeof(*sei));
       }
}

以上代碼是h264_metadata添加SEI的判斷邏輯,當指定了sei_user_data時,滿足以下條件之一即可以處理:

  • 讀取的access units是第一個au;
  • 當前au包含sps;
    滿足插入SEI邏輯後,具體處理過程中:
  • 如果發現第一個NAL已經是SEI,則該au不做插入SEI 處理;
  • 如果au包含了IDR幀或者非IDR未分區的幀,則在其前面插入SEI 信息。

基於以上代碼,oceans.sei.h264碼流中新插入27個新的SEI 符合處理邏輯。
具體構造SEI NAL Unit代碼如下:

        sei->nal_unit_header.nal_unit_type = H264_NAL_SEI;
        err = ff_cbs_insert_unit_content(ctx->cbc, au,
                                             sei_pos, H264_NAL_SEI, sei);
        if (err < 0) {
             av_log(bsf, AV_LOG_ERROR, "Failed to insert SEI.\n");
             goto fail;
        }
        payload = &sei->payload[sei->payload_count];
        payload->payload_type = H264_SEI_TYPE_USER_DATA_UNREGISTERED;
        udu = &payload->payload.user_data_unregistered;
        for (i = j = 0; j < 32 && ctx->sei_user_data[i]; i++) {
            int c, v;
            c = ctx->sei_user_data[i];
            if (c == '-') {
                continue;
            } else if (av_isxdigit(c)) {
                c = av_tolower(c);
                v = (c <= '9' ? c - '0' : c - 'a' + 10);
            } else {
                goto invalid_user_data;
            }
            if (i & 1)
                udu->uuid_iso_iec_11578[j / 2] |= v;
            else
                udu->uuid_iso_iec_11578[j / 2] = v << 4;
            ++j;
        }
        if (j == 32 && ctx->sei_user_data[i] == '+') {
            sei_udu_string = av_strdup(ctx->sei_user_data + i + 1);
            if (!sei_udu_string) {
                err = AVERROR(ENOMEM);
                goto sei_fail;
            }
            udu->data = sei_udu_string;
            udu->data_length = strlen(sei_udu_string);
            payload->payload_size = 16 + udu->data_length;
        }

代碼完整解釋了上文提到的SEI規範,其中"H264_SEI_TYPE_USER_DATA_UNREGISTERED"值爲5,對應的即是未註冊的用戶信息。在解析"ffmpeg"工具輸入過程中,將"+"號前面的字符串轉換成二進制寫入uuid,"+"後內容使用字符串寫入payload。

2.2 x264

libx264支持多種SEI類型數據寫入,常用的仍然是SEI_USER_DATA_UNREGISTERED,具體的寫入函數x264_sei_version_write()位於libx264/encoder/set.c中。

int x264_sei_version_write( x264_t *h, bs_t *s )
{
    static const uint8_t uuid[16] =
    {
        0xdc, 0x45, 0xe9, 0xbd, 0xe6, 0xd9, 0x48, 0xb7,
        0x96, 0x2c, 0xd8, 0x20, 0xd9, 0x23, 0xee, 0xef
    };
    char *opts = x264_param2string( &h->param, 0 );
    char *payload;
    int length;

    if( !opts )
        return -1;
    CHECKED_MALLOC( payload, 200 + strlen( opts ) );

    memcpy( payload, uuid, 16 );
    sprintf( payload+16, "x264 - core %d%s - H.264/MPEG-4 AVC codec - "
             "Copy%s 2003-2018 - http://www.videolan.org/x264.html - options: %s",
             X264_BUILD, X264_VERSION, HAVE_GPL?"left":"right", opts );
    length = strlen(payload)+1;

    x264_sei_write( s, (uint8_t *)payload, length, SEI_USER_DATA_UNREGISTERED );

    x264_free( opts );
    x264_free( payload );
    return 0;
fail:
    x264_free( opts );
    return -1;
}

libx264提供的uuid和上文舉例的uuid一致,payload中主要記錄了相關參數和版權信息。以上函數完成了SEI參數的構造,下面的函數x264_sei_write完成了具體語法的寫入:

void x264_sei_write( bs_t *s, uint8_t *payload, int payload_size, int payload_type )
{
    int i;

    bs_realign( s );

    for( i = 0; i <= payload_type-255; i += 255 )
        bs_write( s, 8, 255 );
    bs_write( s, 8, payload_type-i );

    for( i = 0; i <= payload_size-255; i += 255 )
        bs_write( s, 8, 255 );
    bs_write( s, 8, payload_size-i );

    for( i = 0; i < payload_size; i++ )
        bs_write( s, 8, payload[i] );

    bs_rbsp_trailing( s );
    bs_flush( s );
}
以上寫入的代碼邏輯和標準語法說明保持一致。

3. SEI的解析

3.1 解析SEI

FFmpeg在讀取和解碼NAL unit,都有相同的邏輯處理SEI
讀取或者解碼數據時,會調用下面函數進行碼流的解碼,其中buf包含具體的二進制流,buf_size是當前碼流長度。函數內部會解析碼流並實例出具體的NAL對象:

//Locate in libavcodec/h264dec.c
int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size)

如果NAL對象類型是SEI 時,將調用以下函數解碼:

//Locate in libavcodec/h264_sei.c
int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
                       const H264ParamSets *ps, void *logctx)

函數內部會判斷SEI payload type進行不同的函數調用,如果是未註冊的用戶數據,則調用以下函數:

 int decode_unregistered_user_data(H264SEIUnregistered *h, GetBitContext *gb,void *logctx, int size)
{
    uint8_t *user_data;
    int e, build, i;

    if (size < 16 || size >= INT_MAX - 16)
        return AVERROR_INVALIDDATA;

    user_data = av_malloc(16 + size + 1);
    if (!user_data)
        return AVERROR(ENOMEM);

    for (i = 0; i < size + 16; i++)
        user_data[i] = get_bits(gb, 8);

    user_data[i] = 0;
    e = sscanf(user_data + 16, "x264 - core %d", &build);
    if (e == 1 && build > 0)
        h->x264_build = build;
    if (e == 1 && build == 1 && !strncmp(user_data+16, "x264 - core 0000", 16))
        h->x264_build = 67;

    av_free(user_data);
    return 0;
}

可以看到,根據SEI語法標準,在解析了SEI payload typelength後,對未註冊用戶數據的提取,跳過了uuid的分析,只嘗試提取了x264的build信息。總體上,並未利用SEI_USER_DATA_UNREGISTERED傳遞過來的其他相關參數信息。
從解碼器邏輯看,H264SEIUnregistered結構體只有一個x264_build屬性,並未返回實質有效數據。上層業務如果需要提取SEI_USER_DATA_UNREGISTERED,仍然需要自己提取。提取邏輯,請參考下一小節(ffplay)。

3.2 ffplay

ffplay是一個簡單、常用的FFmpeg接口示例工具,常用於測試解碼、播放效果。如果在ffplay中示例跑通SEI提取功能,可以很方便的移植到其他平臺。
ffplay工具中,通過av_read_frame(ic, pkt);可以快速拿到當前讀到的NAL unit,位於pkt->data中,可以從此取出NAL unit type,如果是SEI且是用戶未註冊數據類型(payload type值爲5),則可以參考SEI語法繼續讀取UUID和其後傳遞的字符串。

4. 總結

限於篇幅,本文主要對H.264碼流中涉及用戶未註冊數據的SEI進行了分析。總體而言,SEI只是視頻標準裏面很小的一部分,但在應用過程中,比如直播問答項目中SEI承載的信息,就極大提升了直播觀看和答題操作的整體用戶體驗。所以說,從SEI的例子中,我們就會發現,視頻標準裏面還有很多金礦等待着大家的挖掘,這就是多媒體技術的魅力。



作者:金山視頻雲
鏈接:https://www.jianshu.com/p/4d9120dfcd69
來源:簡書
簡書著作權歸作者所有,任何形式的轉載都請聯繫作者獲得授權並註明出處。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章