Abstract | H.264 視頻流的解析 |
---|---|
Authors | Walter Fan |
Category | learning notes |
Status | WIP |
Updated | 2021-12-10 |
視頻流簡介
以最流行的H.264編碼為例盛卡,對于視頻流的解析要了解視頻幀在RTP包中作為荷載是如何承載和存放的驻售。先回顧一些基礎(chǔ)的背景知識凰荚,再寫一個小程序來分析RTP 視頻流。
視頻就是一幅幅圖片以每秒幾十幅的速度播放,這些圖片稱幀(frame), 播放速度稱為幀率(FPS - Frame Per Second)
準(zhǔn)確地說赴蝇,視頻是由一系列圖像組成的動作序列怨绣,并且該序列中的每個圖像都將在要顯示的動作序列的時間軸中接替前一個圖像。 這些靜止圖像稱為視頻幀杠愧。每個視頻幀之間的時間差越小,刷新率就越高逞壁,并且視頻中的運動表現(xiàn)得越自然流济。
現(xiàn)代視頻編碼將這些幀分為三類
- I-frame 信息幀
信息幀用幀內(nèi)壓縮,用作關(guān)鍵幀
- P-frame
預(yù)測幀 Predictive Frame 用幀間壓縮腌闯,反映之前的 I-frame 的變化
- B-frame
雙向預(yù)測幀 Bidirectional Predictive Frames 使得總體壓縮更高绳瘟, 它參考了之前的 I-frame 和之后的 P-frame
術(shù)語
I-Frame: Info frame 關(guān)鍵信息幀
P-Frame: Predictive Frames 預(yù)測幀
B-Frame: Bidirectional Predictive Frames 雙向預(yù)測幀
GOP: Group of Piciture 一組圖片幀,通常是一個關(guān)鍵幀加上后續(xù)的預(yù)測幀
IDR: Instant Decoder Refresh frames 立即解碼刷新幀姿骏,不需要參考幀, 它通常是 GOP 中的第一幀
GDR: Gradual Decoder Refresh frames 可分割更小的幀以更小的時間間隔發(fā)送
LTRP: Long-Term Reference Picture frames 可供長期參考校正的幀
SPS(Sequence Paramater Set) 序列參數(shù)集”糖声。SPS中保存了一組編碼視頻序列(Coded Video Sequence)的全局參數(shù)。因此該類型保存的是和編碼序列相關(guān)的參數(shù)
PPS (Picture Paramater Set)圖像參數(shù)集。該類型保存了整體圖像相關(guān)的參數(shù)姨丈。
SEI (Supplemental Enhancement Information) 補充增強信息畅卓,提供了向視頻碼流中加入額外信息的方法。
AU(Access Unit):
訪問單元蟋恬,它是一個或者多個NALU的集合翁潘,代表了一個完整的幀。一組 NAL 單元總是包含一個主要的編碼圖片歼争。 除了主要編碼圖片之外拜马,訪問單元還可以包含一個或多個冗余編碼圖片, 或是不包含編碼圖片的切片或切片數(shù)據(jù)分區(qū)的其他NAL單元沐绒。 存取單元的解碼總是產(chǎn)生解碼圖像俩莽。coded video sequence: 編碼的視頻序列
訪問單元序列,按解碼順序由瞬時解碼刷新 (IDR) 訪問單元和零個或多個非 IDR 訪問單元組成乔遮,包括所有后續(xù)訪問單元扮超,直到但不包括任何后續(xù) IDR 訪問單元。
- IDR access unit:
主要編碼圖片為 IDR 圖片的訪問單元蹋肮。
- IDR picture:
僅包含 I 或 SI 類型的slice 的編碼圖片出刷,這會在解碼過程中導(dǎo)致“重置”。 在對 IDR 圖片進(jìn)行解碼之后坯辩,可以根據(jù)在 IDR 圖片之前解碼的任何圖片馁龟,在沒有幀間預(yù)測的情況下,對按照解碼順序的所有后續(xù)編碼圖片進(jìn)行解碼漆魔。
- primary coded picture:
解碼過程使用的圖片的編碼表示坷檩,用于符合 H.264 的比特流。
主要編碼圖片包含圖片的所有宏塊改抡。
- redundant coded picture:
圖片或其中一部分的編碼表示矢炼。 對符合 H.264 的比特流的解碼過程不應(yīng)使用冗余編碼圖片的內(nèi)容。 冗余編碼圖片的內(nèi)容可由解碼過程用于包含錯誤或損失的比特流雀摘。
- VCL NAL unit:
用于指代編碼切片(slice)和編碼數(shù)據(jù)分區(qū)(data partition) 的 NAL 單元的統(tǒng)稱裸删。
- DON: Decoding Order Number 解碼順序號
H.264 視頻流
基于以上的概念, H.264 將這些視頻幀進(jìn)行了分組阵赠,這些組稱為 GOP(Group of Picture), 在這些組中的第一個視頻幀通常都是 I-Frame
以一個視頻通信的應(yīng)用程序為例,視頻編碼程序會將采樣的視頻圖片從 RGB 格式轉(zhuǎn)為 YUV 格式肌稻,再將它們打包為 RTP packet 清蚀,如下圖所示
讓我們從外而內(nèi),看看視頻 RTP 包的結(jié)構(gòu)
RTP header - 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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
針對 H264視頻幀爹谭,RTP 頭中的某些字段有如下設(shè)置
- Marker bit (M): 1 bit
為 RTP 包中時間戳所指示的訪問單元的最后一個數(shù)據(jù)包中設(shè)置 marker=1枷邪,這樣可以用來進(jìn)行有效的播放緩沖區(qū)處理。
在FU-A中的 marker 設(shè)定為只有最后一包才會設(shè)定 marker=1诺凡,其它則為 0
- Sequence number (SN): 16 bits
根據(jù) RFC 3550 的定義來設(shè)置和使用东揣,對于單NALU和非交錯打包模式践惑,序列號用于確定NALU的解碼順序。
- Timestamp: 32 bits
RTP 時間戳設(shè)置為視頻內(nèi)容的采樣時間戳, 必須使用 90 kHz 時鐘頻率嘶卧。
例如 H264的采樣率為 90khz, 幀率 frame rate =15 那么每個包的時間戳 Timestamp 的步長約為 90000/15 = 6000
RTP payload - RTP 包內(nèi)容
RTP 包的荷載中包含 H.264 中的視頻流內(nèi)容尔觉,也就是 NAL 網(wǎng)絡(luò)抽象層
- NAL: Network Abstraction Layer 網(wǎng)絡(luò)抽象層
- VCL: Video Coding Layer 視頻編碼層 VCL Layer 包含圖片切片編碼
NAL Unit
NAL Unit 是 header 和 playload 組成的
NAL Unit Header 就是一個字節(jié),格式如下:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
1) forbidden zero bit
forbidden_zero_bit: 一個比特芥吟, H.264 規(guī)范將值 1 聲明為語法違反規(guī)范侦铜。
2) NRI
NRI 兩個比特,即 nal_ref_idc 稱 NAL 參考索引
值 00 表示 NAL 單元的內(nèi)容不用于重建用于圖片間預(yù)測的參考圖片钟鸵,此類 NAL 單元可以丟棄钉稍,而不會危及參考圖片的完整性。
大于 00 的值表示需要對 NAL 單元進(jìn)行解碼以保持參考圖片的完整性棺耍。
例如:
- 00: the content of the NAL unit is not used to reconstruct reference pictures for inter picture prediction
- 11:
- nal_unit_type=7: SPS(Sequence Parameter Set)
- nal_unit_type=8: PPS(Picture Parameter Set)
- nal_unit_type=5: a coded slice belonging to an IDR picture
H.264 規(guī)定如下的 NAL unit type , 其 NRI 必須為 0
- 6 Additional information (SEI)
- 9 Access unit delimiter
- 10 End of sequence
- 11 End of stream
- 12 Filler data
Table 2. Example of NRI values for coded slices and coded slice
data partitions of primary coded reference pictures
NAL Unit Type Content of NAL Unit NRI (binary)
----------------------------------------------------------------
1 non-IDR coded slice 10
2 Coded slice data partition A 10
3 Coded slice data partition B 01
4 Coded slice data partition C 01
3) NAL Unit Type
NAL 類型以 5 個比特來表示
NAL Type | Definition |
---|---|
0 | Undefined |
1 | Slice layer without partitioning non IDR |
2 | Slice data partition A layer |
3 | Slice data partition B layer |
4 | Slice data partition C layer |
5 | Slice layer without partitioning IDR |
6 | Additional information (SEI) |
7 | Sequence parameter set |
8 | Picture parameter set |
9 | Access unit delimiter |
10 | End of sequence |
11 | End of stream |
12 | Filler data |
13..23 | Reserved |
24..31 | Undefined |
視頻包的種類
為適合于通過 RTP 協(xié)議在網(wǎng)絡(luò)上傳輸贡未, H264 的視頻包大體上分為三種:
Single NAL unit packet 單獨包,一個包就是一個視頻幀, NALU type : 1 ~ 23
-
Aggregation packet 聚合包蒙袍,即一個包中含有多個H264幀
- NALU type 24: Single-Time Aggregation Packet type A (STAP-A) 單一時間聚合包 A
- NALU type 25: Single-Time Aggregation Packet type B (STAP-B) 單一時間聚合包 B
- NALU type 26: Multi-Time Aggregation Packet (MTAP) with 16-bit offset (MTAP16) 即 16 比特位移多時間聚合包
- NALU type 27: Multi-Time Aggregation Packet (MTAP) with 24-bit offset (MTAP24) 即 24 比特位移多時間聚合包
-
Fragmentation unit packet 分片包羞秤,用于將一幀數(shù)據(jù)被分為多個 RTP包, 常用于關(guān)鍵幀
- NALU type 28: FU-A
- NALU type 29: FU-B
在 RFC6184 中有如下規(guī)定
Table 1. Summary of NAL unit types and the corresponding packet
types
NAL Unit Packet Packet Type Name Section
Type Type
-------------------------------------------------------------
0 reserved -
1-23 NAL unit Single NAL unit packet 5.6
24 STAP-A Single-time aggregation packet 5.7.1
25 STAP-B Single-time aggregation packet 5.7.1
26 MTAP16 Multi-time aggregation packet 5.7.2
27 MTAP24 Multi-time aggregation packet 5.7.2
28 FU-A Fragmentation unit 5.8
29 FU-B Fragmentation unit 5.8
30-31 reserved -
在視頻會議中,一般打包模式選擇為非交錯模式左敌,會使用下面三種單元瘾蛋,不使用 STAP-B, FU-B 和 MTAP 單元
單一 NAL 單元 Single NALU:如果一個視頻幀包含1個NALU,可以單獨打包成一個 RTP 包矫限,那么RTP時間戳就對應(yīng)這個幀的采集時間
單一時間聚合 NAL 單元 STAP-A:如果某幀較大不能單獨打包哺哼,但是該幀內(nèi)部單獨的 NALU 比較小,可以使用STAP-A方式合并多個NALU打包發(fā)送叼风,但是這些NALU的時間戳必須一致取董,打包后的RTP時間戳也必須一致
FU-A:如果一個視頻幀的 NALU 過大(超過 MTU)需要拆分成多個包,可以使用无宿, FU-A 方式來拆分并打到不同的 RTP 包里茵汰,那么這幾個包的 RTP 時間戳是一樣的;
Signal NAL Unit packet 單一 NAL 單元包
- Single NALU:如果一個視頻幀包含1個NALU孽鸡,可以單獨打包成一個RTP包蹂午,那么RTP時間戳就對應(yīng)這個幀的采集時間;
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. RTP payload format for single NAL unit packet
STAP 單一時間聚合包
如果某幀較大不能單獨打包彬碱,但是該幀內(nèi)部單獨的 NALU 比較小豆胸,可以使用STAP 方式合并多個NALU打包發(fā)送,但是這些 NALU 的時間戳必須一致巷疼,打包后的 RTP 時間戳也必須一致晚胡,一個 STAP 單元包含多個子單元,每個子單元之前會有一個 NAL unit size 來指明這個子單元的長度, 這里只以 STAP-A 為例估盘, STAP-B 也就是多了一個 DON(Decoding Order Number)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Structure for single-time aggregation unit
例如下面的例子
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. An example of an RTP packet including an STAP-A
containing two single-time aggregation units
FU 分片單元包
如果一個視頻幀的 NALU 過大(超過MTU)需要拆分成多個包瓷患,可以使用 FU 方式來拆分并打到不同的RTP包里,那么這幾個包的RTP時間戳是一樣的遣妥;
以 FU-A 為例 (FU-B 的區(qū)別就是多了一個 DON), 如圖所示
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
其中 FU indicator 字節(jié)的格式如下
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
它就是一個普通的 NAL header, 只是它的 type 等于 28(FU-A) 或 29 (FU-B)
其后的 FU header 字節(jié)的格式如下
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
含義如下
- S: 1 bit 開始位
當(dāng)設(shè)置為 1 時擅编,Start 位指示分片 NAL 單元的開始。 當(dāng)隨后的 FU 有效載荷不是分片 NAL 單元有效載荷的開始時燥透,起始位設(shè)置為零沙咏。
- E: 1 bit
當(dāng)設(shè)置為 1 時,End 位表示分片 NAL 單元的結(jié)束班套,即有效載荷的最后一個字節(jié)也是分片 NAL 單元的最后一個字節(jié)肢藐。 當(dāng)隨后的 FU 有效載荷不是分片 NAL 單元的最后一個片段時,結(jié)束位設(shè)置為零吱韭。
- R: 1 bit 保留位吆豹,始終為0
- Type: 5 bits
實際被分片的 NAL 單元的類型,參見 RFC6184 的 Table 7-1
代碼示例
在 https://github.com/cisco/openh264 中有相關(guān)結(jié)構(gòu)和類型的詳細(xì)定義, 至于聚合包和分片包理盆,openh264 中本身并未定義
在 webrtc 的 video_coding 中有相關(guān)的定義
third_party/webrtc/modules/video_coding/codecs/h264/include/h264_globals.h
// The packetization types that we support: single, aggregated, and fragmented.
enum H264PacketizationTypes {
kH264SingleNalu, // This packet contains a single NAL unit.
kH264StapA, // This packet contains STAP-A (single time
// aggregation) packets. If this packet has an
// associated NAL unit type, it'll be for the
// first such aggregated packet.
kH264FuA, // This packet contains a FU-A (fragmentation
// unit) packet, meaning it is a part of a frame
// that was too large to fit into a single packet.
};
// Packetization modes are defined in RFC 6184 section 6
// Due to the structure containing this being initialized with zeroes
// in some places, and mode 1 being default, mode 1 needs to have the value
// zero. https://crbug.com/webrtc/6803
enum class H264PacketizationMode {
NonInterleaved = 0, // Mode 1 - STAP-A, FU-A is allowed
SingleNalUnit // Mode 0 - only single NALU allowed
};
我自己也寫了一個小例子痘煤,演示如下
- 先啟動一個本地的服務(wù)器,我就寫一個簡單的 UDP server, 將從網(wǎng)絡(luò)端口 8888 接收到的 RTP 包保存起來猿规,代碼很簡單
#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <iostream>
#include <string>
#include "rtputil.h"
#define BUFLEN 5120
#define PORT 8880
#define msg_trace(msg) std::cout<<__FILE__<<","<<__LINE__<<": " << msg <<std::endl
using namespace std;
void exitWithMsg(const char *str)
{
perror(str);
exit(1);
}
int main(int argc, char *argv[])
{
string rtpDumpFile = "rtp_dump.dat";
int nPort = PORT;
int nCount = 10000;
int nRet = 0;
if(argc > 2) {
nPort = atoi(argv[1]);
rtpDumpFile = argv[2];
if(argc > 3) nCount = atoi( argv[3]);
msg_trace("To dump rtp packets to " << rtpDumpFile << " for " << nCount << " packets" << " from udp port " << nPort);
} else {
cout << "usage: " << argv[0] << "<port> <dump_file> [<dump_rtp_count>]" << endl;
return -1;
}
msg_trace("--- udp server as rtp receiver ---");
struct sockaddr_in my_addr, cli_addr;
int sockfd;
socklen_t slen=sizeof(cli_addr);
uint8_t buf[BUFLEN];
if ((sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))==-1)
exitWithMsg("socket error");
else
printf("Server : Socket() successful\n");
bzero(&my_addr, sizeof(my_addr));
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(nPort);
my_addr.sin_addr.s_addr = htonl(INADDR_ANY);
if (::bind(sockfd, (struct sockaddr* ) &my_addr, sizeof(my_addr))==-1)
exitWithMsg("bind error");
else
printf("Server : bind() successful\n");
ofstream ofs;
ofs.open (rtpDumpFile, std::ofstream::out | std::ofstream::app | std::ofstream::binary);
int pktCount = 0;
while(nCount > 0)
{
int pktSize = recvfrom(sockfd, buf, BUFLEN, 0, (struct sockaddr*)&cli_addr, &slen);
if(pktSize == -1) {
exitWithMsg("recvfrom()");
}
printf("The %d packet received %d from %s:%d ", ++pktCount, pktSize, inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port));
if(pktSize > 12) {
cout << dump_rtp_packet(buf, pktSize) <<endl;
dump_rtp_to_file(buf, pktSize, &ofs);
nCount --;
}
}
close(sockfd);
return 0;
}
其中用到的一個工具類 rtputil 源碼就不貼了衷快,參見
編譯運行
git clone git@github.com:walterfan/webrtc_snippets.git
cd media
mkdir bld
cd bld
cmake ..
make
./udpserver 8888 dump.dat 1000
- 將本地的一個 mp4 文件通過 ffmpeg 發(fā)送到這個服務(wù)器的 8888 端口上,命令如下
ffmpeg \
-re \
-i ../../obama_talk.mp4 \
-an \
-c:v copy \
-f rtp \
-sdp_file video.sdp \
"rtp://127.0.0.1:5004"
- 將保存下來的 RTP 文件解析出來姨俩,分析其中保存的 H264 NAL 包
#include <stdio.h>
#include <stdint.h>
#include <iostream>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <sys/time.h>
#include <assert.h>
#include <unistd.h>
#include "MediaUtil.h"
using namespace std;
int main(int argc, char *argv[])
{
msg_trace("--- Walter test program ---");
int nRet = 0;
if(argc > 1) {
msg_trace("--- read media file ---");
string media_file = argv[1];
MediaFileParser* pParser = new MediaFileParser(media_file);
pParser->parse_stream();
delete pParser;
msg_trace("--- byebye ---");
} else {
msg_trace("Usage: " << argv[0] << " <media_file>");
}
return nRet;
}
其中用到的一個工具類 MediaUtil 源碼就不貼了蘸拔,參見
編譯運行
git clone git@github.com:walterfan/webrtc_snippets.git
cd video
mkdir bld
cd bld
cmake ..
make
./media_parser ../../media/bld/dump.dat |more
運行結(jié)果如下,
# ,size, pt, ssrc, m, sn, ts, nalType, subNalType, start, end
1, 1472, 96, 1352798098, 0, 2156, 704725956, 28, 5, 1, 0,
2, 1472, 96, 1352798098, 0, 2157, 704725956, 28, 5, 0, 0,
3, 1472, 96, 1352798098, 0, 2158, 704725956, 28, 5, 0, 0,
4, 1472, 96, 1352798098, 0, 2159, 704725956, 28, 5, 0, 0,
5, 1472, 96, 1352798098, 0, 2160, 704725956, 28, 5, 0, 0,
6, 1472, 96, 1352798098, 0, 2161, 704725956, 28, 5, 0, 0,
7, 1472, 96, 1352798098, 0, 2162, 704725956, 28, 5, 0, 0,
8, 1472, 96, 1352798098, 0, 2163, 704725956, 28, 5, 0, 0,
9, 1472, 96, 1352798098, 0, 2164, 704725956, 28, 5, 0, 0,
10, 1472, 96, 1352798098, 0, 2165, 704725956, 28, 5, 0, 0,
11, 1472, 96, 1352798098, 0, 2166, 704725956, 28, 5, 0, 0,
12, 1472, 96, 1352798098, 0, 2167, 704725956, 28, 5, 0, 0,
13, 1472, 96, 1352798098, 0, 2168, 704725956, 28, 5, 0, 0,
14, 1472, 96, 1352798098, 0, 2169, 704725956, 28, 5, 0, 0,
15, 1260, 96, 1352798098, 1, 2170, 704725956, 28, 5, 0, 1,
16, 1472, 96, 1352798098, 0, 2171, 704729710, 28, 1, 1, 0,
17, 1472, 96, 1352798098, 0, 2172, 704729710, 28, 1, 0, 0,
參考資料
- RFC6184: RTP Payload Format for H.264 Video