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 頭的結構(12位元組).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequencenumber |
| 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 頭結構是一樣的.
字段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 分片的單元
可能的結構類型分别有:
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 01 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NALunit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...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 包中.
| RTPHeader |
|STAP-A NAL HDR| NALU 1Size | NALU 1HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data |
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2Size | NALU 2 HDR |
| NALU 2 Data |
2.3 Fragmentation Units (FUs).
而當NALU 的長度超過MTU 時,就必須對NALU 單元進行分片封包.也稱為Fragmentation Units (FUs).
| FU indicator | FUheader | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FU payload |
| :...OPTIONAL RTP padding |
Figure 14. RTP payload format for FU-A
The FUindicator octet has the following format:
The FU headerhas the following format:
|S|E|R| Type |
3. SDP 參數
下面描述了如何在SDP 中表示一個H.264 流:
. "m=" 行中的媒體名必須是"video"
. "a=rtpmap" 行中的編碼名稱必須是"H264".
. "a=rtpmap" 行中的時鐘頻率必須是 90000.
. 其他參數都包括在"a=fmtp" 行中.
如:
m=video 49170 RTP/AVP98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
下面介紹一些常用的參數.
3.1packetization-mode:
表示支援的封包模式.
當packetization-mode 的值為 0 時或不存在時,必須使用單一NALU 單元模式.
當packetization-mode 的值為 1 時必須使用非交錯(non-interleaved)封包模式.
當packetization-mode 的值為 2 時必須使用交錯(interleaved)封包模式.
這個參數不可以取其他的值.
3.2sprop-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:
這個參數的值是一個整型,指出了每一秒最大的宏塊處理速度.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
一、NALU打包成RTP的方式有三種：
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.
還記得前面nal_unit_type的定義吧，0~23是給H264用的，24~31未使用，在rtp打包時，如果一個NALU放在一個RTP包裡，可以使用NALU的nal_unit_type，但是當需要把多個NALU打包成一個RTP包，或者需要把一個NALU打包成多個RTP包時，就定義新的type來辨別。
Type Packet Typename
---------------------------------------------------------
0 undefined -
1-23 NAL unit Single NAL unit packet perH.264
24 STAP-A Single-timeaggregation packet
25 STAP-B Single-timeaggregation packet
26 MTAP16 Multi-time aggregationpacket
27 MTAP24 Multi-time aggregationpacket
28 FU-A Fragmentationunit
29 FU-B Fragmentationunit
30-31 undefined
二、三種打包方式的具體格式
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 包即可.
|F|NRI| type | |
如有一個 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 組合封包模式
其次, 當 NALU 的長度特别小時, 可以把幾個 NALU 單元封在一個 RTP 包中.
| RTP Header |
: :
3 FragmentationUnits (FUs).
而當 NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包. 也稱為 Fragmentation Units (FUs).
| FU indicator | FUheader | |
Figure 14. RTPpayload format for FU-A
FU indicator有以下格式：
FU訓示位元組的類型域 Type=28表示FU-A。。NRI域的值必須根據分片NAL單元的NRI域的值設定。
FU header的格式如下：
S: 1 bit
當設定成1,開始位訓示分片NAL單元的開始。當跟随的FU荷載不是分片NAL單元荷載的開始，開始位設為0。
E: 1 bit
當設定成1, 結束位訓示分片NAL單元的結束，即, 荷載的最後位元組也是分片NAL單元的最後一個位元組。當跟随的FU荷載不是分片NAL單元的最後分片,結束位設定為0。
R: 1 bit
保留位必須設定為0，接收者必須忽略該位。
Type: 5 bits
1、單個NAL包單元
12位元組的RTP頭後面的就是音視訊資料，比較簡單。一個封裝單個NAL單元包到RTP的NAL單元流的RTP序号必須符合NAL單元的解碼順序。
2、FU-A的分片格式
資料比較大的H264視訊包，被RTP分片發送。12位元組的RTP頭後面跟随的就是FU-A分片：
FU indicator有以下格式：
S: 1 bit
當設定成1,開始位訓示分片NAL單元的開始。當跟随的FU荷載不是分片NAL單元荷載的開始，開始位設為0。
E: 1 bit
當設定成1, 結束位訓示分片NAL單元的結束，即, 荷載的最後位元組也是分片NAL單元的最後一個位元組。當跟随的FU荷載不是分片NAL單元的最後分片,結束位設定為0。
R: 1 bit
NAL單元荷載類型定義見下表
表1. 單元類型以及荷載結構總結
Type Packet Typename
0 undefined -
1-23 NALunit Single NAL unit packet per H.264
24 STAP-A Single-time aggregation packet
25 STAP-B Single-time aggregation packet
26 MTAP16 Multi-time aggregation packet
27 MTAP24 Multi-time aggregation packet
28 FU-A Fragmentation unit
29 FU-B Fragmentationunit
30-31 undefined -
3、拆包和解包
拆包：當編碼器在編碼時需要将原有一個NAL按照FU-A進行分片，原有的NAL的單元頭與分片後的FU-A的單元頭有如下關系：
原始的NAL頭的前三位為FU indicator的前三位，原始的NAL頭的後五位為FU header的後五位，FUindicator與FU header的剩餘位數根據實際情況決定。
解包：當接收端收到FU-A的分片資料，需要将所有的分片包組合還原成原始的NAL包時，FU-A的單元頭與還原後的NAL的關系如下：
還原後的NAL頭的八位是由FU indicator的前三位加FU header的後五位組成，即：
nal_unit_type = (fu_indicator & 0xe0) | (fu_header & 0x1f)
4、代碼實作
從RTP包裡面得到H264視訊資料的方法：
// 功能：解碼RTP H.264視訊
// 參數：1.RTP包緩沖位址 2.RTP包資料大小 3.H264輸出位址 4.輸出資料大小
// 傳回：true:表示一幀結束 false:FU-A分片未結束或幀未結束
#define RTP_HEADLEN 12
bool UnpackRTPH264( void * bufIn, int len, void ** pBufOut, int * pOutLen)
{
* pOutLen = 0 ;
if (len < RTP_HEADLEN)
{
return false ;
}
unsigned char * src = (unsigned char* )bufIn + RTP_HEADLEN;
unsigned char head1 = * src; // 擷取第一個位元組
unsigned char head2 = * (src + 1 ); // 擷取第二個位元組
unsigned char nal = head1 & 0x1f; // 擷取FU indicator的類型域，
unsigned char flag = head2 & 0xe0 ; // 擷取FU header的前三位，判斷目前是分包的開始、中間或結束
unsigned char nal_fua = (head1 & 0xe0 ) | (head2 & 0x1f); // FU_A nal
bool bFinishFrame = false ;
if (nal == 0x1c ) // 判斷NAL的類型為0x1c=28，說明是FU-A分片
{ // fu-a
if (flag== 0x80 ) // 開始
{
* pBufOut = src - 3 ; // lostyears: 本人覺得，這裡應該-4，就是給留給startcode的4個位元組
* (( int * )( * pBufOut)) = 0x01000000 ; // zyf:大模式會有問題, lostyears: 這裡的value就是startcode
* ((char * )( * pBufOut) + 4 ) = nal_fua; // lostyears: 第五個位元組即nal head
* pOutLen = len - RTP_HEADLEN + 3 ; // lostyears: 這裡就應該+4了，因為startcode是4個位元組（如果是3個位元組，那中間兩行代碼就得改一下）
}
else if (flag == 0x40 ) // 結束
* pBufOut = src + 2 ; // lostyears: 去掉FU indicator 和 FU header兩個位元組
* pOutLen = len - RTP_HEADLEN - 2 ;
else // 中間
* pBufOut = src + 2 ;
else // 單包資料
* pBufOut = src - 4 ;
* (( int * )( * pBufOut)) = 0x01000000 ; // zyf:大模式會有問題
* pOutLen = len - RTP_HEADLEN + 4 ;
unsigned char * bufTmp = (unsigned char* )bufIn;
if (bufTmp[ 1 ] & 0x80 )
bFinishFrame = true ; // rtp mark
}
else
bFinishFrame = false ;
return bFinishFrame;
}
從RTP包裡面得到AAC音頻資料的方法：
//功能：解RTP AAC音頻包，聲道和采樣頻率必須知道。
//參數：1.RTP包緩沖位址 2.RTP包資料大小 3.H264輸出位址 4.輸出資料大小
//傳回：true:表示一幀結束 false:幀未結束 一般AAC音頻包比較小，沒有分片。
bool UnpackRTPAAC(void * bufIn, int recvLen, void** pBufOut, int* pOutLen)
unsigned char* bufRecv = (unsigned char*)bufIn;
//char strFileName[20];
unsigned char ADTS[] = {0xFF, 0xF1, 0x00, 0x00, 0x00, 0x00, 0xFC};
int audioSamprate = 32000;//音頻采樣率
int audioChannel = 2;//音頻聲道 1或2
int audioBit = 16;//16位 固定
switch(audioSamprate)
case 16000:
ADTS[2] = 0x60;
break;
case 32000:
ADTS[2] = 0x54;
case 44100:
ADTS[2] = 0x50;
case 48000:
ADTS[2] = 0x4C;
case 96000:
ADTS[2] = 0x40;
default:
ADTS[3] = (audioChannel==2)?0x80:0x40;
int len = recvLen - 16 + 7; // lostyears: 12個位元組是RTP head，還有4個位元組是表示占兩位元組的AU_HEADER_LENGTH+占兩位元組的AU_HEADER
//AAC封裝RTP比較簡單
//将AAC的ADTS頭去掉
//12位元組RTP頭後緊跟着2個位元組的AU_HEADER_LENGTH,
//然後是2位元組的AU_HEADER(2 bytes: 13 bits = length of frame, 3 bits = AU-Index(-delta)))，之後就是AAC payload。
//是以要得到AACpayload
//payLen= （UINT16）usAuheader >> 3;（這裡要注意usAuheader的值，RTP中是網絡序的，要轉成主機序）
len <<= 5;//8bit * 2 - 11 = 5(headerSize 11bit)
len |= 0x1F;//5 bit 1
ADTS[4] = len>>8;
ADTS[5] = len & 0xFF;
*pBufOut = (char*)bufIn+16-7;
memcpy(*pBufOut, ADTS, sizeof(ADTS));
*pOutLen = recvLen - 16 + 7;
unsigned char* bufTmp = (unsigned char*)bufIn;
bool bFinishFrame = false;
if (bufTmp[1] & 0x80)
//DebugTrace::D("Marker");
bFinishFrame = true;
else
bFinishFrame = false;
return true;
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
ADTS全稱是(Audio Data Transport Stream)，是AAC的一種十分常見的傳輸格式。
記得第一次做demux的時候，把AAC音頻的ES流從FLV封裝格式中抽出來送給硬體解碼器時，不能播;儲存到本地用pc的播放器播時，我靠也不 能播。當時崩潰了，後來通過查找資料才知道。一般的AAC解碼器都需要把AAC的ES流打包成ADTS的格式，一般是在AAC ES流前添加7個位元組的ADTS header。也就是說你可以吧ADTS這個頭看作是AAC的frameheader。
ADTS AAC
ADTS_header
AAC ES
...
ADTS 頭中相對有用的資訊 采樣率、聲道數、幀長度。想想也是，我要是解碼器的話，你給我一堆得AAC音頻ES流我也解不出來。每一個帶ADTS頭資訊的AAC流會清晰的告送解碼器他需要的這些資訊。
一般情況下ADTS的頭資訊都是7個位元組，分為2部分：
adts_fixed_header();
adts_variable_header();
syncword ：同步頭 總是0xFFF, all bits must be 1，代表着一個ADTS幀的開始
ID：MPEG Version: 0 for MPEG-4, 1 for MPEG-2
Layer：always: '00'
profile：表示使用哪個級别的AAC，有些晶片隻支援AAC LC 。在MPEG-2 AAC中定義了3種：
sampling_frequency_index：表示使用的采樣率下标，通過這個下标在 Sampling Frequencies[ ]數組中查找得知采樣率的值。
There are 13 supported frequencies:
0: 96000 Hz
1: 88200 Hz
2: 64000 Hz
3: 48000 Hz
4: 44100 Hz
5: 32000 Hz
6: 24000 Hz
7: 22050 Hz
8: 16000 Hz
9: 12000 Hz
10: 11025 Hz
11: 8000 Hz
12: 7350 Hz
13: Reserved
14: Reserved
15: frequency is written explictly
channel_configuration: 表示聲道數
0: Defined in AOT Specifc Config
1: 1 channel: front-center
2: 2 channels: front-left, front-right
3: 3 channels: front-center, front-left, front-right
4: 4 channels: front-center, front-left, front-right, back-center
5: 5 channels: front-center, front-left, front-right, back-left, back-right
6: 6 channels: front-center, front-left, front-right, back-left, back-right, LFE-channel
7: 8 channels: front-center, front-left, front-right, side-left, side-right, back-left, back-right, LFE-channel
8-15: Reserved
frame_length : 一個ADTS幀的長度包括ADTS頭和AAC原始流.
adts_buffer_fullness：0x7FF 說明是碼率可變的碼流
通過對ADTS格式的了解，很容易就能把AAC打包成ADTS。我們隻需得到封裝格式裡面關于音頻采樣率、聲道數、中繼資料長度、aac格式類型等資訊。然後在每個AAC原始流前面加上個ADTS頭就OK了。
貼上ffmpeg中添加ADTS頭的代碼，就可以很清晰的了解ADTS頭的結構：
int ff_adts_write_frame_header(ADTSContext *ctx,
uint8_t *buf, int size, int pce_size)
{
PutBitContext pb;
init_put_bits(&pb, buf, ADTS_HEADER_SIZE);
/* adts_fixed_header */
put_bits(&pb, 12, 0xfff); /* syncword */
put_bits(&pb, 1, 0); /* ID */
put_bits(&pb, 2, 0); /* layer */
put_bits(&pb, 1, 1); /* protection_absent */
put_bits(&pb, 2, ctx->objecttype); /* profile_objecttype */
put_bits(&pb, 4, ctx->sample_rate_index);
put_bits(&pb, 1, 0); /* private_bit */
put_bits(&pb, 3, ctx->channel_conf); /* channel_configuration */
put_bits(&pb, 1, 0); /* original_copy */
put_bits(&pb, 1, 0); /* home */
/* adts_variable_header */
put_bits(&pb, 1, 0); /* copyright_identification_bit */
put_bits(&pb, 1, 0); /* copyright_identification_start */
put_bits(&pb, 13, ADTS_HEADER_SIZE + size + pce_size); /* aac_frame_length */
put_bits(&pb, 11, 0x7ff); /* adts_buffer_fullness */
put_bits(&pb, 2, 0); /* number_of_raw_data_blocks_in_frame */
flush_put_bits(&pb);
return 0;
}
二. ADIF：
Audio Data Interchange Format 音頻資料交換格式。這種格式的特征是可以确定的找到這個音頻資料的開始，不需進行在音頻資料流中間開始的解碼，即它的解碼必須在明确定義的開始處進行。故這種格式常用在磁盤檔案中。
AAC的ADIF格式見下圖：
三. faad解碼aac
iRet = pcmRender.init(2, 44100, 16, NULL);
static unsigned char frame[FRAME_MAX_LEN];
unsigned long samplerate;
unsigned char channels;
NeAACDecHandle decoder = 0;
size_t data_size = 0;
size_t size = 0;
NeAACDecFrameInfo frame_info;
unsigned char* input_data = buffer;
unsigned char* pcm_data = NULL;
static int iFlag = 0;
int iRead = 0;
while (m_iThreadFlag && (data_size = ReadData(NULL, buffer+iRead, BUFFER_MAX_LEN-iRead)))
#if 1
data_size += iRead;
if (0 == iFlag)
if(get_one_ADTS_frame(buffer, data_size, frame, &size, &iRead) < 0)
continue ;
decoder = NeAACDecOpen();
//initialize decoder
NeAACDecInit(decoder, frame, size, &samplerate, &channels);
printf("samplerate %d, channels %d\n", samplerate, channels);
iFlag = 1;
input_data = buffer;
while(m_iThreadFlag && get_one_ADTS_frame(input_data, data_size, frame, &size, &iRead) == 0)
//decode ADTS frame
pcm_data = (unsigned char*)NeAACDecDecode(decoder, &frame_info, frame, size);
if(frame_info.error > 0)
printf("%s\n",NeAACDecGetErrorMessage(frame_info.error));
else if(pcm_data && frame_info.samples > 0)
static FILE *fp1 = NULL;
if (NULL == fp1)
fp1 = fopen("F:\\6.pcm", "wb");
if (fp1)
fwrite(pcm_data, 1, frame_info.samples * frame_info.channels,fp1);
fflush(fp1);
Player((char*)pcm_data, frame_info.samples * frame_info.channels);
}
data_size -= size;
input_data += size;
}
#endif
NeAACDecClose(decoder);