以live555為例來分析H264碼流的打包傳送

NO IMAGE

H.264 視訊 RTP 負載格式

1. 網路抽象層單元型別 (NALU)

NALU 頭由一個位元組組成, 它的語法如下:

      —————
      |0|1|2|3|4|5|6|7|
      – – – – – – – –
      |F|NRI|  Type   |
      —————

F: 1 個位元.
  forbidden_zero_bit. 在 H.264 規範中規定了這一位必須為 0.

NRI: 2 個位元.
  nal_ref_idc. 取 00 ~ 11, 似乎指示這個 NALU 的重要性, 如 00 的 NALU 解碼器可以丟棄它而不影響影象的回放. 不過一般情況下不太關心這個屬性.

Type: 5 個位元.
  nal_unit_type. 這個 NALU 單元的型別. 簡述如下:

  0     沒有定義
  1-23  NAL單元  單個 NAL 單元包.
  24    STAP-A   單一時間的組合包
  25    STAP-B   單一時間的組合包
  26    MTAP16   多個時間的組合包
  27    MTAP24   多個時間的組合包
  28    FU-A     分片的單元
  29    FU-B     分片的單元
  30-31 沒有定義

2. 打包模式

  下面是 RFC 3550 中規定的 RTP 頭的結構.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |                           timestamp                           |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |           synchronization source (SSRC) identifier            |
      = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
      |            contributing source (CSRC) identifiers             |
      |                             ….                              |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

  負載型別 Payload type (PT): 7 bits
  序列號 Sequence number (SN): 16 bits
  時間戳 Timestamp: 32 bits
  
  H.264 Payload 格式定義了三種不同的基本的負載(Payload)結構. 接收端可能通過 RTP Payload 
  的第一個位元組來識別它們. 這一個位元組類似 NALU 頭的格式, 而這個頭結構的 NAL 單元型別欄位
  則指出了代表的是哪一種結構,

  這個位元組的結構如下, 可以看出它和 H.264 的 NALU 頭結構是一樣的.
      —————
      |0|1|2|3|4|5|6|7|
      – – – – – – – –
      |F|NRI|  Type   |
      —————
  欄位 Type: 這個 RTP payload 中 NAL 單元的型別. 這個欄位和 H.264 中型別欄位的區別是, 當 type
  的值為 24 ~ 31 表示這是一個特別格式的 NAL 單元, 而 H.264 中, 只取 1~23 是有效的值.
   
  24    STAP-A   單一時間的組合包
  25    STAP-B   單一時間的組合包
  26    MTAP16   多個時間的組合包
  27    MTAP24   多個時間的組合包
  28    FU-A     分片的單元
  29    FU-B     分片的單元
  30-31 沒有定義

  可能的結構型別分別有:

  1. 單一 NAL 單元模式
     即一個 RTP 包僅由一個完整的 NALU 組成. 這種情況下 RTP NAL 頭型別欄位和原始的 H.264的
  NALU 頭型別欄位是一樣的.

  2. 組合封包模式
    即可能是由多個 NAL 單元組成一個 RTP 包. 分別有4種組合方式: STAP-A, STAP-B, MTAP16, MTAP24.
  那麼這裡的型別值分別是 24, 25, 26 以及 27.

  3. 分片封包模式
    用於把一個 NALU 單元封裝成多個 RTP 包. 存在兩種型別 FU-A 和 FU-B. 型別值分別是 28 和 29.

2.1 單一 NAL 單元模式

  對於 NALU 的長度小於 MTU 大小的包, 一般採用單一 NAL 單元模式.
  對於一個原始的 H.264 NALU 單元常由 [Start Code] [NALU Header] [NALU Payload] 三部分組成, 其中 Start Code 用於標示這是一個

NALU 單元的開始, 必須是 “00 00 00 01” 或 “00 00 01”, NALU 頭僅一個位元組, 其後都是 NALU 單元內容.
  打包時去除 “00 00 01” 或 “00 00 00 01” 的開始碼, 把其他資料封包的 RTP 包即可.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |F|NRI|  type   |                                               |
      – – – – – – – –                                                |
      |                                                               |
      |               Bytes 2..n of a Single NAL unit                 |
      |                                                               |
      |                               – – – – – – – – – – – – – – – –
      |                               :…OPTIONAL RTP padding        |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

  如有一個 H.264 的 NALU 是這樣的:

  [00 00 00 01 67 42 A0 1E 23 56 0E 2F … ]

  這是一個序列引數集 NAL 單元. [00 00 00 01] 是四個位元組的開始碼, 67 是 NALU 頭, 42 開始的資料是 NALU 內容.

  封裝成 RTP 包將如下:

  [ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]

  即只要去掉 4 個位元組的開始碼就可以了.

2.2 組合封包模式

  其次, 當 NALU 的長度特別小時, 可以把幾個 NALU 單元封在一個 RTP 包中.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |                          RTP Header                           |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |                         NALU 1 Data                           |
      :                                                               :
                     – – – – – – – – – – – – – – – – – – – – – – – –
      |               | NALU 2 Size                   | NALU 2 HDR    |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      |                         NALU 2 Data                           |
      :                                                               :
      |                               – – – – – – – – – – – – – – – –
      |                               :…OPTIONAL RTP padding        |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –


2.3 Fragmentation Units (FUs).

  而當 NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包. 也稱為 Fragmentation Units (FUs).
  
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      | FU indicator  |   FU header   |                               |
      – – – – – – – – – – – – – – – –                                |
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               – – – – – – – – – – – – – – – –
      |                               :…OPTIONAL RTP padding        |
      – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

      Figure 14.  RTP payload format for FU-A

   The FU indicator octet has the following format:

      —————
      |0|1|2|3|4|5|6|7|
      – – – – – – – –
      |F|NRI|  Type   |
      —————

   The FU header has the following format:

      —————
      |0|1|2|3|4|5|6|7|
      – – – – – – – –
      |S|E|R|  Type   |
      —————

3. SDP 引數

  下面描述瞭如何在 SDP 中表示一個 H.264 流:

  . “m=” 行中的媒體名必須是 “video”
  . “a=rtpmap” 行中的編碼名稱必須是 “H264”.
  . “a=rtpmap” 行中的時脈頻率必須是 90000.
  . 其他引數都包括在 “a=fmtp” 行中.

  如:

  m=video 49170 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

  下面介紹一些常用的引數.

3.1 packetization-mode:
  表示支援的封包模式. 
  當 packetization-mode 的值為 0 時或不存在時, 必須使用單一 NALU 單元模式.
  當 packetization-mode 的值為 1 時必須使用非交錯(non-interleaved)封包模式.
  當 packetization-mode 的值為 2 時必須使用交錯(interleaved)封包模式.
  這個引數不可以取其他的值.

3.2 sprop-parameter-sets:
  這個引數可以用於傳輸 H.264 的序列引數集和影象引數 NAL 單元. 這個引數的值採用 Base64 進行編碼. 不同的引數集間用”,”號隔開.
  
3.3 profile-level-id:
  這個引數用於指示 H.264 流的 profile 型別和級別. 由 Base16(十六進位制) 表示的 3 個位元組. 第一個位元組表示 H.264 的 Profile 型別, 第

三個位元組表示 H.264 的 Profile 級別:
  
3.4 max-mbps:
  這個引數的值是一個整型, 指出了每一秒最大的巨集塊處理速度.

live555的打包傳送

現有的H264VideoFileServerMediaSubsession中,sink使用了H264VideoRTPSink,source使用了H264VideoStreamFramer,然而這個連線是很複雜的,在這兩個節點間要插入了很多其它的節點,其實際情況是這樣的:
ByteStreamFileSource–>H264VideoStreamParser–>H264VideoStreamFramer–>H264FUAFragmenter–>H264VideoRTPSink.類的作用如下:
ByteStreamFileSource:264資料來源。
H264VideoStreamParser:用來獲取BUF。
H264VideoStreamFramer:獲取一幀資料。
H264FUAFragmenter:分包。
H264VideoRTPSink:得到包資料。
 參考:http://blog.csdn.net/nkmnkm/article/details/7212181

程式碼:

下面是LIVE555打包H264的程式碼

[cpp] view
plain
 copy

  1. void H264FUAFragmenter::doGetNextFrame() {  
  2.   if (fNumValidDataBytes == 1) {  
  3.     // We have no NAL unit data currently in the buffer.  Read a new one:  
  4.     fInputSource->getNextFrame(&fInputBuffer[1], fInputBufferSize – 1,  
  5.                    afterGettingFrame, this,  
  6.                    FramedSource::handleClosure, this);  
  7.   } else {  
  8.     // We have NAL unit data in the buffer.  There are three cases to consider:  
  9.     // 1. There is a new NAL unit in the buffer, and it’s small enough to deliver  
  10.     //    to the RTP sink (as is). 小包  
  11.     // 2. There is a new NAL unit in the buffer, but it’s too large to deliver to  
  12.     //    the RTP sink in its entirety.  Deliver the first fragment of this data,  
  13.     //    as a FU-A packet, with one extra preceding header byte. 大包的頭包  
  14.     // 3. There is a NAL unit in the buffer, and we’ve already delivered some  
  15.     //    fragment(s) of this.  Deliver the next fragment of this data,  
  16.     //    as a FU-A packet, with two extra preceding header bytes. 大包的非頭包  
  17.   
  18.     if (fMaxSize < fMaxOutputPacketSize) { // shouldn’t happen  
  19.       envir() << “H264FUAFragmenter::doGetNextFrame(): fMaxSize (”  
  20.           << fMaxSize << “) is smaller than expected\n”;  
  21.     } else {  
  22.       fMaxSize = fMaxOutputPacketSize;  
  23.     }  
  24.   
  25.     fLastFragmentCompletedNALUnit = True; // by default  
  26.     if (fCurDataOffset == 1) { // case 1 or 2  
  27.       if (fNumValidDataBytes – 1 <= fMaxSize) { // case 1  
  28.     memmove(fTo, &fInputBuffer[1], fNumValidDataBytes – 1);  
  29.     fFrameSize = fNumValidDataBytes – 1;  
  30.     fCurDataOffset = fNumValidDataBytes;  
  31.       } else { // case 2  
  32.     // We need to send the NAL unit data as FU-A packets.  Deliver the first  
  33.     // packet now.  Note that we add FU indicator and FU header bytes to the front  
  34.     // of the packet (reusing the existing NAL header byte for the FU header).  
  35.     fInputBuffer[0] = (fInputBuffer[1] & 0xE0) | 28; // FU indicator  
  36.     fInputBuffer[1] = 0x80 | (fInputBuffer[1] & 0x1F); // FU header (with S bit)  
  37.     memmove(fTo, fInputBuffer, fMaxSize);  
  38.     fFrameSize = fMaxSize;  
  39.     fCurDataOffset  = fMaxSize – 1;  
  40.     fLastFragmentCompletedNALUnit = False;  
  41.       }  
  42.     } else { // case 3  
  43.       // We are sending this NAL unit data as FU-A packets.  We’ve already sent the  
  44.       // first packet (fragment).  Now, send the next fragment.  Note that we add  
  45.       // FU indicator and FU header bytes to the front.  (We reuse these bytes that  
  46.       // we already sent for the first fragment, but clear the S bit, and add the E  
  47.       // bit if this is the last fragment.)  
  48.       fInputBuffer[fCurDataOffset-2] = fInputBuffer[0]; // FU indicator  
  49.       fInputBuffer[fCurDataOffset-1] = fInputBuffer[1]&~0x80; // FU header (no S bit)  
  50.       unsigned numBytesToSend = 2   fNumValidDataBytes – fCurDataOffset;  
  51.       if (numBytesToSend > fMaxSize) {  
  52.     // We can’t send all of the remaining data this time:  
  53.     numBytesToSend = fMaxSize;  
  54.     fLastFragmentCompletedNALUnit = False;  
  55.       } else {  
  56.     // This is the last fragment:  
  57.     fInputBuffer[fCurDataOffset-1] |= 0x40; // set the E bit in the FU header  
  58.     fNumTruncatedBytes = fSaveNumTruncatedBytes;  
  59.       }  
  60.       memmove(fTo, &fInputBuffer[fCurDataOffset-2], numBytesToSend);  
  61.       fFrameSize = numBytesToSend;  
  62.       fCurDataOffset  = numBytesToSend – 2;  
  63.     }  
  64.   
  65.     if (fCurDataOffset >= fNumValidDataBytes) {  
  66.       // We’re done with this data.  Reset the pointers for receiving new data:  
  67.       fNumValidDataBytes = fCurDataOffset = 1;  
  68.     }  
  69.   
  70.     // Complete delivery to the client:  
  71.     FramedSource::afterGetting(this);  
  72.   }  
  73. }