ffmpeg中MPEG2 TS 流解碼的流程分析
1、FFMPEG 中MPEG2 TS 流解碼的流程分析 數組
說道具體的音頻或者視頻格式，一上來就是理論，那是國內混資歷的所謂教授的作爲，
對於咱們，不合適，仍是用本身的方式理解這些晦澀不已的理論吧。
其實MPEG2 是一族協議，至少已經成爲ISO 標準的就有如下幾部分:
ISO/IEC－13818－1：系統部分；
ISO/IEC－13818－2：視頻編碼格式；
ISO/IEC－13818－3：音頻編碼格式；
ISO/IEC－13818－4：一致性測試；
ISO/IEC－13818－5：軟件部分；
ISO/IEC－13818－6：數字存儲媒體命令與控制；
ISO/IEC－13818－7：高級音頻編碼；
ISO/IEC－13818－8：系統解碼實時接口；
我不是很想說實際的音視頻編碼格式，畢竟協議已經很清楚了，我主要想說說這些部分
怎麼組合起來在實際應用中工做的。
第一部分(系統部分)很重要，是構成以MPEG2 爲基礎的應用的基礎. 很繞口，是吧，
我簡單解釋一下:好比DVD 其實是以系統部分定義 的PS 流爲基礎，加上版權管理等其
他技術構成的。而咱們的故事主角，則是另外 種流格式，TS 流，它在現階段最大的應用
是在數字電視節目 的傳輸 存儲上，所以，你能夠理解TS 其實是 種傳輸協議， 實
際傳輸的負載關係不大，只是在TS 中傳輸了音頻，視頻或者其餘數據。先說一下爲何會
有這兩種格式的出現，PS 適用於沒有損耗的環境下面存儲，而TS 則適用於可能出現損耗或
者錯誤的各類物理網絡環境，好比你在公交上看 的電視，頗有可能就是基於TS 的DVB-T
的應用:)
咱們再來看MPEG2 協議中的一些概念，爲理解代碼作好功課:
l ES(Elementary Stream):
wiki 上說An elementary stream (ES) is defined by MPEG communication protocol is
usually the output of an audio or video encoder」
恩，很簡單吧，就是編碼器編出的 組數據，多是音頻的，視頻的，或者其餘數據。
說到着，其實能夠對編碼器的流程思考一下，無非是執行：採樣，量化，編碼這3個步驟中
的編碼而已(有些設備可能會包含前面的採樣和量化) 。關於視頻編碼的基本理論，仍是請
參考其它的資料。
l PES(Packetized Elementary Stream):
wiki 上說allows an Elementary stream to be divided into packets」
其實能夠理解成，把 個源源不斷的數據(音頻，視頻或者其餘)流，打斷成 段 段，
以便處理.
l TS(Transport Stream):
l PS(Program Stream):
這兩個上面已經有所說起，後面會詳細分析TS,我對PS 格式興趣不大.
步入正題
才進入正題，恩，看來閒話太多了:(,直接看Code.
前面說過，TS 是 種傳輸協議，所以，對應 FFmpeg,能夠認爲他是 種封裝格式。 網絡
所以，對應的代碼應該先去libavformat 裏面找，很容易找 ，就是mpegts.c:)。仍是逐步看
過來: 數據結構
[libavformat/utils.c]
框架
int av_open_input_file(AVFormatContext **ic_ptr, const char *filename,
AVInputFormat *fmt,
int buf_size,
AVFormatParameters *ap)
{
int err, probe_size;
AVProbeData probe_data, *pd = &probe_data;
ByteIOContext *pb = NULL;
pd->filename = "";
if (filename)
pd->filename = filename;
pd->buf = NULL;
pd->buf_size = 0;
################################################################################
【1】這段代碼實際上是爲了針對不須要Open文件的容器Format 的探測,其實就是使用
AVFMT_NOFILE標記的容器格式單獨處理，如今只有使用了該標記的Demuxer不多，
只有image2_demuxer，rtsp_demuxer，所以咱們分析TS時候能夠不考慮這部分
################################################################################
if (!fmt) {
/* guess format if no file can be opened */
fmt = av_probe_input_format(pd, 0);
}
/* Do not open file if the format does not need it. XXX: specific
hack needed to handle RTSP/TCP */
if (!fmt || !(fmt->flags & AVFMT_NOFILE)) {
/* if no file needed do not try to open one */
#########################################################################
【2】這個函數彷佛很好理解，無非是帶緩衝的IO的封裝，不過咱們既然此了，
不妨跟蹤下去，看看別人對帶緩衝的IO 操做封裝的實現:)
#########################################################################
if ((err=url_fopen(&pb, filename, URL_RDONLY)) < 0) {
goto fail;
}
if (buf_size > 0) {
url_setbufsize(pb, buf_size);
}
for(probe_size= PROBE_BUF_MIN; probe_size<=PROBE_BUF_MAX && !fmt; probe_size<<=1){
int score= probe_size < PROBE_BUF_MAX ? AVPROBE_SCORE_MAX/4 : 0;
/* read probe data */
pd->buf= av_realloc(pd->buf, probe_size + AVPROBE_PADDING_SIZE);
#######################################################################
【3】真正將文件讀入 pd 的buffer的地方，實際上最終調用FILE protocol
的file_read(),將內容讀入 pd 的buf，具體代碼若是有興趣能夠本身跟蹤
#######################################################################
pd->buf_size = get_buffer(pb, pd->buf, probe_size);
memset(pd->buf+pd->buf_size, 0, AVPROBE_PADDING_SIZE);
if (url_fseek(pb, 0, SEEK_SET) < 0) {
url_fclose(pb);
if (url_fopen(&pb, filename, URL_RDONLY) < 0) {
pb = NULL;
err = AVERROR(EIO);
goto fail;
}
}
#####################################################################
【4】此時的pd已經有了須要分析的原始文件，只須要查找相應容器format
的Tag 比較，以判斷讀入的究竟爲何容器格式，這裏
#####################################################################
/* guess file format */
fmt = av_probe_input_format2(pd, 1, &score);
}
av_freep(&pd->buf);
}
/* if still no format found, error */
if (!fmt) {
err = AVERROR_NOFMT;
goto fail;
}
/* check filename in case an image number is expected */
if (fmt->flags & AVFMT_NEEDNUMBER) {
if (!av_filename_number_test(filename)) {
err = AVERROR_NUMEXPECTED;
goto fail;
}
}
err = av_open_input_stream(ic_ptr, pb, filename, fmt, ap);
if (err)
goto fail;
return 0;
fail:
av_freep(&pd->buf);
if (pb)
url_fclose(pb);
*ic_ptr = NULL;
return err;
}
【2】帶緩衝IO的封裝的實現 [liavformat/aviobuf.c] int url_fopen(ByteIOContext **s, const char *filename, int flags)
{
URLContext *h;
int err;
err = url_open(&h, filename, flags);
if (err < 0)
return err;
err = url_fdopen(s, h);
if (err < 0) {
url_close(h);
return err;
}
return 0;
}
能夠看 ，下面的這個函數，先查找是不是FFmpeg支持的protocol的格式，若是文件
名不符合，則默認是FILE protocol 格式，很顯然，這裏protocol判斷是以URL的方式判讀
的，所以基本上全部的IO接口函數都是url_xxx的形式。
在這也能夠看 ，FFmpeg 支持的protocol 有：
/* protocols */
REGISTER_PROTOCOL (FILE, file);
REGISTER_PROTOCOL (HTTP, http);
REGISTER_PROTOCOL (PIPE, pipe);
REGISTER_PROTOCOL (RTP, rtp);
REGISTER_PROTOCOL (TCP, tcp);
REGISTER_PROTOCOL (UDP, udp);
而大部分狀況下，若是你不指明相似file://xxx,http://xxx 格 式，它都以FILE protocol
來處理。 tcp
[liavformat/avio.c]
ide
int url_open(URLContext **puc, const char *filename, int flags)
{
URLProtocol *up;
const char *p;
char proto_str[128], *q;
p = filename;
q = proto_str;
while (*p != '\0' && *p != ':') {
/* protocols can only contain alphabetic chars */
if (!isalpha(*p))
goto file_proto;
if ((q - proto_str) < sizeof(proto_str) - 1)
*q++ = *p;
p++;
}
/* if the protocol has length 1, we consider it is a dos drive */
if (*p == '\0' || (q - proto_str) <= 1) {
file_proto:
strcpy(proto_str, "file");
} else {
*q = '\0';
}
up = first_protocol;
while (up != NULL) {
if (!strcmp(proto_str, up->name))
#################################################################
很顯然，此時已經知道up，filename，flags
#################################################################
return url_open_protocol (puc, up, filename, flags);
up = up->next;
}
*puc = NULL;
return AVERROR(ENOENT);
}
[libavformat/avio.c] int url_open_protocol (URLContext **puc, struct URLProtocol *up,
const char *filename, int flags)
{
URLContext *uc;
int err;
##########################################################################
【a】? 爲何這樣分配空間
##########################################################################
uc = av_malloc(sizeof(URLContext) + strlen(filename) + 1);
if (!uc) {
err = AVERROR(ENOMEM);
goto fail;
}
#if LIBAVFORMAT_VERSION_MAJOR >= 53
uc->av_class = &urlcontext_class;
#endif
##########################################################################
【b】? 這樣的用意又是爲何
##########################################################################
uc->filename = (char *) &uc[1];
strcpy(uc->filename, filename);
uc->prot = up;
uc->flags = flags;
uc->is_streamed = 0; /* default = not streamed */
uc->max_packet_size = 0; /* default: stream file */
err = up->url_open(uc, filename, flags);
if (err < 0) {
av_free(uc);
*puc = NULL;
return err;
}
//We must be carefull here as url_seek() could be slow, for example for
//http
if((flags & (URL_WRONLY | URL_RDWR)) || !strcmp(up->name, "file"))
if(!uc->is_streamed && url_seek(uc, 0, SEEK_SET) < 0)
uc->is_streamed= 1;
*puc = uc;
return 0;
fail:
*puc = NULL;
return err;
}
上面這個函數不難理解，但有些地方頗值得玩味，好比上面給出問號的地方，你明白
爲何這樣Coding麼？很顯然，此時up->url_open()實際上調用的是 file_open()
[libavformat/file.c]，看完這個函數，對上面的內存分配，是否恍然大悟:)
上面只是分析了url_open()，尚未分析url_fdopen(s, h);這部分代碼，也留給有好
奇心的你了:)恩，爲了追蹤這個流程，走得有些遠，但不是全然無用:)
於來了【4】，咱們來看MPEG TS格式的偵測過程，這其實才是咱們今天的主角
4. MPEG TS格式的探測過程 模塊化
[liavformat/mpegts.c]
函數
static int mpegts_probe(AVProbeData *p)
{
#if 1
const int size= p->buf_size;
int score, fec_score, dvhs_score;
#define CHECK_COUNT 10
if (size < (TS_FEC_PACKET_SIZE * CHECK_COUNT))
return -1;
score = analyze(p->buf, TS_PACKET_SIZE * CHECK_COUNT, TS_PACKET_SIZE, NULL);
dvhs_score = analyze(p->buf, TS_DVHS_PACKET_SIZE *CHECK_COUNT, TS_DVHS_PACKET_SIZE, NULL);
fec_score= analyze(p->buf, TS_FEC_PACKET_SIZE*CHECK_COUNT, TS_FEC_PACKET_SIZE, NULL);
// av_log(NULL, AV_LOG_DEBUG, "score: %d, dvhs_score: %d, fec_score: %d \n", score, dvhs_score, fec_score);
// we need a clear definition for the returned score otherwise things will become messy sooner or later
if(score > fec_score && score > dvhs_score && score > 6)
return AVPROBE_SCORE_MAX + score - CHECK_COUNT;
else if(dvhs_score > score && dvhs_score > fec_score && dvhs_score > 6)
return AVPROBE_SCORE_MAX + dvhs_score - CHECK_COUNT;
else if(fec_score > 6)
return AVPROBE_SCORE_MAX + fec_score - CHECK_COUNT;
else
return -1;
#else
/* only use the extension for safer guess */
if (match_ext(p->filename, "ts"))
return AVPROBE_SCORE_MAX;
else
return 0;
#endif
}
之因此會出現3種格式，主要緣由是：TS標準是188Bytes,而小日本本身又弄了個
192Bytes的DVH-S格式，第三種的204Bytes則是在188Bytes的基礎上，加上16Bytes的
FEC(前向糾錯).
static int analyze(const uint8_t *buf, int size, int packet_size, int *index)
{
int stat[packet_size];
int i;
int x=0;
int best_score=0;
memset(stat, 0, packet_size*sizeof(int));
##########################################################################
因爲查找的特定格式至少3 個Bytes，所以，至少最後3 個Bytes 不用查找
##########################################################################
for(x=i=0; i<size-3; i++){
######################################################################
參看後面的協議說明
######################################################################
if(buf[i] == 0x47 && !(buf[i+1] & 0x80) && (buf[i+3] & 0x30)){
stat[x]++;
if(stat[x] > best_score){
best_score= stat[x];
if(index)
*index= x;
}
}
x++;
if(x == packet_size)
x= 0;
}
return best_score;
}
這個函數簡單說來，是在size大小的buf中，尋找知足特定格式，長度爲packet_size
的packet的個數，顯然，返回的值越大越多是相應的格式(188/192/204)，其中的這個特
定格式，其實就是協議的規定格式：
Syntax No. of bits Mnemonic
transport_packet(){
sync_byte 8 bslbf
transport_error_indicator 1 bslbf
payload_unit_start_indicator 1 bslbf
transport_priority 1 bslbf
PID 13 uimsbf
transport_scrambling_control 2 bslbf
adaptation_field_control 2 bslbf
continuity_counter 4 uimsbf
if(adaptation_field_control=='10' || adaptation_field_control=='11'){
adaptation_field()
}
if(adaptation_field_control=='01' || adaptation_field_control=='11') {
for (i=0;i<N;i++){
data_byte 8 bslbf
}
}
｝
其中的sync_byte 固定爲0x47,即上面的: buf[i] == 0x47
因爲transport_error_indicator 爲1 的TS Packet 實際有錯誤，表示攜帶的數據無心義,
這樣的Packet 顯然沒什麼意義，所以: !(buf[i+1] & 0x80)
對於adaptation_field_control，若是爲取值爲0x00,則表示爲將來保留，如今不用，所以：
buf[i+3] & 0x30
這就是MPEG TS的偵測過程，很簡單吧:)
後面咱們分析如何從mpegts文件中獲取stream 的過程。
5.漸入佳境
恩，前面的基礎因該已近夠了，有點像手剝洋蔥頭的感 ，咱們來看看針對MPEG TS
的相應解析過程。咱們後面的代碼，主要集中在[libavformat/mpegts.c]裏面，毛爺爺說：集
中優點兵力打圍殲，恩，開始吧，螞蟻啃骨頭。
static int mpegts_read_header(AVFormatContext *s,
AVFormatParameters *ap)
{
MpegTSContext *ts = s->priv_data;
ByteIOContext *pb = s->pb;
uint8_t buf[1024];
int len;
int64_t pos;
......
/* read the first 1024 bytes to get packet size */
#####################################################################
【1】有了前面分析緩衝IO 的經歷，下面的代碼就不是什麼問題了:)
#####################################################################
pos = url_ftell(pb);
len = get_buffer(pb, buf, sizeof(buf));
if (len != sizeof(buf))
goto fail;
#####################################################################
【2】前面偵測文件格式時候其實已經知道TS 包的大小了，這裏又偵測 次，其實
有些多餘，估計是由於解碼框架的緣由，已近偵測的包大小沒能從前面被帶過來，
可見框架雖好，卻也會帶來或多或少的 些不利影響
#####################################################################
ts->raw_packet_size = get_packet_size(buf, sizeof(buf));
if (ts->raw_packet_size <= 0)
goto fail;
ts->stream = s;
ts->auto_guess = 0;
if (s->iformat == &mpegts_demuxer) {
/* normal demux */
/* first do a scaning to get all the services */
url_fseek(pb, pos, SEEK_SET);
#########
【3】
#########
mpegts_scan_sdt(ts);
#########
【4 】
#########
mpegts_set_service(ts);
#########
【5】
#########
handle_packets(ts, s->probesize);
/* if could not find service, enable auto_guess */
ts->auto_guess = 1;
#ifdef DEBUG_SI
av_log(ts->stream, AV_LOG_DEBUG, "tuning done\n");
#endif
s->ctx_flags |= AVFMTCTX_NOHEADER;
} else {
......
}
url_fseek(pb, pos, SEEK_SET);
return 0;
fail:
return -1;
}
這裏簡單說一下MpegTSContext *ts，從上面能夠看 ，其實這是爲了解碼不一樣容器格式所使用的私有數據，
只有在相應的諸如mpegts.c文件纔可使用的，這樣，增長了這個庫的模塊化，而模塊化的最大好處，
則在於把問題集中了個很小的有限區域裏面，若是你本身構造程序時候，不妨多參考其基本思想--這樣的化，
你以後的代碼，還有你以後的生活，都將輕鬆許多。
【3】【4】其實調用的是同個函數：mpegts_open_section_filter() 咱們來看看意欲何爲。
static MpegTSFilter *mpegts_open_section_filter(MpegTSContext *ts, unsigned int pid,
SectionCallback *section_cb,
void *opaque,
int check_crc)
{
MpegTSFilter *filter;
MpegTSSectionFilter *sec;
#ifdef DEBUG_SI
av_log(ts->stream, AV_LOG_DEBUG, "Filter: pid=0x%x\n", pid);
#endif
if (pid >= NB_PID_MAX || ts->pids[pid])
return NULL;
filter = av_mallocz(sizeof(MpegTSFilter));
if (!filter)
return NULL;
ts->pids[pid] = filter;
filter->type = MPEGTS_SECTION;
filter->pid = pid;
filter->last_cc = -1;
sec = &filter->u.section_filter;
sec->section_cb = section_cb;
sec->opaque = opaque;
sec->section_buf = av_malloc(MAX_SECTION_SIZE);
sec->check_crc = check_crc;
if (!sec->section_buf) {
av_free(filter);
return NULL;
}
return filter;
要徹底明白這部分代碼，其實須要分析做者對數據結構的定義：
依次爲：
struct MpegTSContext;
|
V
struct MpegTSFilter;
|
V
+---------------+---------------+
| |
V V
MpegTSPESFilter MpegTSSectionFilter 測試
其實很簡單，就是struct MpegTSContext；中有NB_PID_MAX(8192)個TS 的Filter，而
每一個struct MpegTSFilter 多是PES 的Filter 或者Section 的Filter。
咱們先說爲何是8192,在前面的分析中：
給出過TS 的語法結構： ui
Syntax No. of bits Mnemonic
transport_packet(){
sync_byte 8 bslbf
transport_error_indicator 1 bslbf
payload_unit_start_indicator 1 bslbf
transport_priority 1 bslbf
PID 13 uimsbf
transport_scrambling_control 2 bslbf
adaptation_field_control 2 bslbf
continuity_counter 4 uimsbf
if(adaptation_field_control=='10' || adaptation_field_control=='11'){
adaptation_field()
}
if(adaptation_field_control=='01' || adaptation_field_control=='11') {
for (i=0;i<N;i++){
data_byte 8 bslbf
}
}
}
而8192,則是2^13=8192(PID)的最大數目，而爲何會有PES 和Section 的區分，請參
考ISO/IEC-13818-1,我實在不太喜歡重複已有的東西.
可見【3】【4】,就是掛載了兩個Section 類型的過濾器,其實在TS 的兩種負載中，section
是PES 的元數據，只有先解析了section,才能進 步解析PES 數據，所以先掛上section 的
過濾器。
掛載上了兩種 section 過濾器，以下：
==================================================================
PID Section Name Callback
==================================================================
SDT_PID(0x0011) ServiceDescriptionTable sdt_cb
PAT_PID(0x0000) ProgramAssociationTable pat_cb
既然自是掛上Callback，天然是在後面的地方使用，所以，咱們仍是繼續
【5】處的代碼看看是最重要的地方了，簡單看來：
handle_packets()
|
+->read_packet()
|
+->handle_packet()
|
+->write_section_data()
read_packet()很簡單，就是去找sync_byte(0x47),而看來handle_packet()纔會是咱們真正
因該關注的地方了:)
這個函數很重要，咱們貼出代碼，以備分析：
/* handle one TS packet */
static void handle_packet(MpegTSContext *ts, const uint8_t *packet)
{
AVFormatContext *s = ts->stream;
MpegTSFilter *tss;
int len, pid, cc, cc_ok, afc, is_start;
const uint8_t *p, *p_end;
##########################################################
獲取該包的PID
##########################################################
pid = AV_RB16(packet + 1) & 0x1fff;
if(pid && discard_pid(ts, pid))
return;
##########################################################
是不是PES 或者Section 的開頭(payload_unit_start_indicator)
##########################################################
is_start = packet[1] & 0x40;
tss = ts->pids[pid];
##########################################################
ts->auto_guess 此時爲0，所以不考慮下面的代碼
##########################################################
if (ts->auto_guess && tss == NULL && is_start) {
add_pes_stream(ts, pid, -1, 0);
tss = ts->pids[pid];
}
if (!tss)
return;
##########################################################
代碼說的很清楚，雖然檢查，但不利用檢查的結果
##########################################################
/* continuity check (currently not used) */
cc = (packet[3] & 0xf);
cc_ok = (tss->last_cc < 0) || ((((tss->last_cc + 1) & 0x0f) == cc));
tss->last_cc = cc;
##########################################################
跳 adaptation_field_control
##########################################################
/* skip adaptation field */
afc = (packet[3] >> 4) & 3;
p = packet + 4;
if (afc == 0) /* reserved value */
return;
if (afc == 2) /* adaptation field only */
return;
if (afc == 3) {
/* skip adapation field */
p += p[0] + 1;
}
##########################################################
p已近 達TS 包中的有效負載的地方
##########################################################
/* if past the end of packet, ignore */
p_end = packet + TS_PACKET_SIZE;
if (p >= p_end)
return;
ts->pos47= url_ftell(ts->stream->pb) % ts->raw_packet_size;
if (tss->type == MPEGTS_SECTION) {
if (is_start) {
###############################################################
針對Section，符合部分第 個字節爲pointer field，該字段若是爲0,
則表示後面緊跟着的是Section的開頭，不然是某Section的End部分和
另 Section 的開頭，所以，這裏的流程實際上由兩個值is_start
(payload_unit_start_indicator)和len(pointer field)起來決定
###############################################################
/* pointer field present */
len = *p++;
if (p + len > p_end)
return;
if (len && cc_ok) {
########################################################
1).is_start == 1
len > 0
負載部分由A Section 的End 部分和B Section 的Start 組成，把A 的
End 部分寫入
########################################################
/* write remaining section bytes */
write_section_data(s, tss, p, len, 0);
/* check whether filter has been closed */
if (!ts->pids[pid])
return;
}
p += len;
if (p < p_end) {
########################################################
2).is_start == 1
len > 0
負載部分由A Section 的End 部分和B Section 的Start 組成，把B 的
Start 部分寫入
或者：
3).
is_start == 1
len == 0
負載部分僅是 個Section 的Start 部分，將其寫入
########################################################
write_section_data(s, tss, p, p_end - p, 1);
}
} else if (cc_ok) {
########################################################
4).is_start == 0
負載部分僅是 個Section 的中間部分部分，將其寫入
########################################################
write_section_data(s, tss, p, p_end - p, 0);
} else {
##########################################################
若是是PES 類型，直接調用其Callback，但顯然，只有Section 部分
解析完成後纔可能解析PES
##########################################################
tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start);
}
}
write_section_data()函數則反覆收集buffer中的數據，指導完成相關Section的重組過
程，而後調用以前註冊的兩個section_cb:
後面咱們將分析以前掛在的兩個section_cb
2、mpegts.c文件分析
1 綜述
ffmpeg 框架對應MPEG-2 TS 流的解析的代碼在mpegts.c 文件中，該文件有兩個解復
用的實例：mpegts_demuxer 和mpegtsraw_demuxer，mpegts_demuxer 對應的真實的TS 流格
式，也就是機頂盒直接處理的 TS 流，本文主要分析和該種格式相關 的代碼；
mpegtsraw_demuxer 這個格式我沒有碰見過，本文中不作分析。本文針對的ffmpeg 的版本是
0.5 版本。
2 mpegts_demuxer 結構分析
AVInputFormat mpegts_demuxer = {au
"mpegts", //demux 的名稱
NULL_IF_CONFIG_SMALL("MPEG-2 transport stream format"),// 若是定義了
ONFIG_SMALL 宏，該域返回NULL，也就是取消long_name 域的定義。
sizeof(MpegTSContext),//每一個demuxer 的結構的私有域的大小
mpegts_probe,//檢測是不是TS 流格式
mpegts_read_header,//下文介紹
mpegts_read_packet,//下文介紹
mpegts_read_close,//關閉demuxer
read_seek,//下文介紹
mpegts_get_pcr,//下文介紹
.flags = AVFMT_SHOW_IDS|AVFMT_TS_DISCONT,//下文介紹
};
該結構經過av_register_all 函數註冊 ffmpeg 的主框架中，經過mpegts_probe 函數來
檢測是不是TS 流格式，而後經過mpegts_read_header 函數找路音頻流和路視頻流（注
意：在該函數中沒有找全全部的音頻流和視頻流），最後調用mpegts_read_packet函數將找
的音頻流和視頻流數據提取出來，經過主框架推入解碼器。
3 mpegts_probe 函數分析
mpegts_probe被av_probe_input_format2調用，根據返回的score來判斷那種格式的可
能性最大。mpegts_probe調用了analyze函數，咱們先分析一下analyze函數。
static int analyze(const uint8_t *buf, int size, int packet_size, int *index)
{
int stat[TS_MAX_PACKET_SIZE];//積分統計結果
int i;
int x=0;
int best_score=0;
memset(stat, 0, packet_size*sizeof(int));
for(x=i=0; i<size-3; i++){
if(buf[i] == 0x47 && !(buf[i+1] & 0x80) && (buf[i+3] & 0x30)){
stat[x]++;
if(stat[x] > best_score){
best_score= stat[x];
if(index)
*index= x;
}
}
x++;
if(x == packet_size)
x= 0;
}
return best_score;
}
analyze 函數的思路：
buf[i] == 0x47 && !(buf[i+1] & 0x80) && (buf[i+3] & 0x30)是TS 流同步開始的模式，
0x47 是TS 流同步的標誌，(buf[i+1] & 0x80 是傳輸錯誤標誌，buf[i+3] & 0x30 爲0 時表示爲
ISO/IEC 將來使用保留，目前不存在這樣的值。記該模式爲TS 流同步模式」
stat 數組變量存儲的是TS 流同步模式」在某個位置出現的次數。
analyze 函數掃描檢測數據，若是發現該模式，則stat[i%packet_size]++(函數中的x 變
量就是用來取模運算的，由於當x==packet_size時，x就被歸零)，掃描完後，天然是同步
位置的累加值最大。
mpegts_probe函數經過調用analyze函數來得 相應的分數，ffmpeg框架會根據該分
數判斷是不是對應的格式，返回對應的AVInputFormat 實例。
4 mpegts_read_header函數分析
下文中省略號表明的是和mpegtsraw_demuxer相關的代碼，暫不涉及。
<pre class="cpp" name="code">static int mpegts_read_header(AVFormatContext *s,
AVFormatParameters *ap)
{
MpegTSContext *ts = s->priv_data;
ByteIOContext *pb = s->pb;
uint8_t buf[5*1024];
int len;
int64_t pos;
......
//保存流的當前位置，便於檢測操做完成後恢復 原來的位置,
//這樣在播放的時候就不會浪費 段流。
pos = url_ftell(pb);
//讀取 段流來檢測TS 包的大小
len = get_buffer(pb, buf, sizeof(buf));
if (len != sizeof(buf))
goto fail;
//得 TS 流包的大小，一般是188bytes,我目前見過的都是188 個字節的。
//TS 包的大小有三種：
//1) 一般狀況下的188 字節
//2) 日本弄了個192Bytes 的DVH-S 格式
//3)在188Bytes 的基礎上，加上16Bytes 的FEC(前向糾錯),也就是204bytes
ts->raw_packet_size = get_packet_size(buf, sizeof(buf));
if (ts->raw_packet_size <= 0)
goto fail;
ts->stream = s;
//auto_guess = 1, 則在handle_packet 的函數中只要發現 個PES 的pid 就
//創建該PES 的stream
//auto_guess = 0, 則忽略。
//auto_guess 主要做用是用來在TS 流中沒有業務信息時，若是被設置成了1 的話，
//那麼就會將任何 個PID 的流當作媒體流創建對應的PES 數據結構。
//在mpegts_read_header 函數的過程當中發現了PES 的pid，但
//是不創建對應的流,只是分析PSI 信息。
//相關的代碼見handle_packet 函數的下面的代碼：
//tss = ts->pids[pid];
//if (ts->auto_guess && tss == NULL && is_start) {
// add_pes_stream(ts, pid, -1, 0);
// tss = ts->pids[pid];
//}
ts->auto_guess = 0;
if (s->iformat == &mpegts_demuxer) {
/* normal demux */
/* first do a scaning to get all the services */
url_fseek(pb, pos, SEEK_SET);
//掛載解析SDT 表的回調函數 ts->pids 變量上， //這樣在handle_packet 函數中根據對應的pid 找 對應處理回調函數。
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
//同上，只是掛上PAT 表解析的回調函數
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
//探測 段流，便於檢測出SDT，PAT，PMT 表
handle_packets(ts, s->probesize);
/* if could not find service, enable auto_guess */
//打開add pes stream 的標誌，這樣在handle_packet 函數中發現了pes 的
//pid，就會自動創建該pes 的stream。
ts->auto_guess = 1;
dprintf(ts->stream, "tuning done\n");
s->ctx_flags |= AVFMTCTX_NOHEADER;
} else {
......
}
//恢復檢測前的位置。
url_fseek(pb, pos, SEEK_SET);
return 0;
fail:
return -1;
}
</pre>
<pre></pre>
<p> </p>
<p> 下面介紹被 mpegts_read_header直接或者間接調用的幾個函數： mpegts_open_section_filter， handle_packets，handle_packet 5 mpegts_open_section_filter 函數分析 這個函數能夠解釋mpegts.c 代碼結構的精妙之處，PSI 業務信 息表的處理 都是經過該函數掛載 MpegTSContext 結構的pids 字段上的。這樣若是你 想增長別的業務信息的表處理函數只要經過這個函數來掛載便可，體現了
軟件設計的著名的開閉」原則。下面分析一下他的代碼。 </p>
<pre class="cpp" name="code">static MpegTSFilter *mpegts_open_section_filter(MpegTSContext *ts, unsigned int pid,
SectionCallback *section_cb, void *opaque,
int check_crc)
{
MpegTSFilter *filter;
MpegTSSectionFilter *sec;
dprintf(ts->stream, "Filter: pid=0x%x\n", pid);
if (pid >= NB_PID_MAX || ts->pids[pid])
return NULL;
//給filter 分配空間，掛載 MpegTSContext 的pids 上
//就是該實例
filter = av_mallocz(sizeof(MpegTSFilter));
if (!filter)
return NULL;
//掛載filter 實例
ts->pids[pid] = filter;
//設置filter 相關的參數，由於業務信息表的分析的單 是段，
//因此該filter 的類型是MPEGTS_SECTION
filter->type = MPEGTS_SECTION;
//設置pid
filter->pid = pid;
filter->last_cc = -1;
//設置filter 回調處理函數
sec = &filter->u.section_filter;
sec->section_cb = section_cb;
sec->opaque = opaque;
//分配段數據處理的緩衝區，調用handle_packet 函數後會調用
//write_section_data 將ts 包中的業務信息表的數據存儲在這兒，
//直 個段收集完成才交付上面註冊的回調函數處理。
sec->section_buf = av_malloc(MAX_SECTION_SIZE);
sec->check_crc = check_crc;
if (!sec->section_buf) {
av_free(filter);
return NULL;
}
return filter;
}
</pre>
<p><br>
6 handle_packets 函數分析 <br>
handle_packets 函數在兩個地方被調用， 個是mpegts_read_header 函數中， <br>
另外 個是mpegts_read_packet 函數中，被mpegts_read_header 函數調用是用 <br>
來搜索PSI 業務信息，nb_packets 參數爲探測的ts 包的個數；在mpegts_read_packet <br>
函數中被調用用來搜索補充PSI 業務信息和demux PES 流，nb_packets 爲0，0 不 <br>
是表示處理的包的個數爲0。 </p>
<pre class="cpp" name="code">static int handle_packets(MpegTSContext *ts, int nb_packets)
{
AVFormatContext *s = ts->stream;
ByteIOContext *pb = s->pb;
uint8_t packet[TS_PACKET_SIZE];
int packet_num, ret;
//該變量指示 次handle_packets 處理的結束。
//在mpegts_read_packet 被調用的時候，若是發現完 個PES 的包，則
// ts->stop_parse = 1 ，則當前分析結束。
ts->stop_parse = 0;
packet_num = 0;
for(;;) {
if (ts->stop_parse>0)
break;
packet_num++;
if (nb_packets != 0 && packet_num >= nb_packets)
break;
//讀取 個ts 包，一般是188bytes
ret = read_packet(pb, packet, ts->raw_packet_size);
if (ret != 0)
return ret;
handle_packet(ts, packet);
}
return 0;
}
</pre>
<p><br>
</p>
<p>7 handle_packet 函數分析 <br>
能夠說handle_packet 是mpegts.c 代碼的核心，全部的其餘代碼都是爲 <br>
這個函數準備的。 <br>
在調用該函數以前先調用read_packet 函數得到個ts包（一般是188bytes）， <br>
而後傳給該函數，packet參數就是TS包。</p>
<pre class="cpp" name="code">static int handle_packet(MpegTSContext *ts, const uint8_t *packet)
{
AVFormatContext *s = ts->stream;
MpegTSFilter *tss;
int len, pid, cc, cc_ok, afc, is_start;
const uint8_t *p, *p_end;
int64_t pos;
//從TS 包得到包的PID。
pid = AV_RB16(packet + 1) & 0x1fff;
if(pid && discard_pid(ts, pid))
return 0;
is_start = packet[1] & 0x40;
tss = ts->pids[pid];
//ts->auto_guess 在mpegts_read_header 函數中被設置爲0，
//也就是說在ts 檢測過程當中是不創建pes stream 的。
if (ts->auto_guess && tss == NULL && is_start) {
add_pes_stream(ts, pid, -1, 0);
tss = ts->pids[pid];
}
//mpegts_read_header 函數調用handle_packet 函數只是處理TS 流的
//業務信息，由於並無爲對應的PES 創建tss，因此tss 爲空，直接返回。
if (!tss)
return 0;
/* continuity check (currently not used) */
cc = (packet[3] & 0xf);
cc_ok = (tss->last_cc < 0) || ((((tss->last_cc + 1) & 0x0f) == cc));
tss->last_cc = cc;
/* skip adaptation field */
afc = (packet[3] >> 4) & 3;
p = packet + 4;
if (afc == 0) /* reserved value */
return 0;
if (afc == 2) /* adaptation field only */
return 0;
if (afc == 3) {
/* skip adapation field */
p += p[0] + 1;
}
/* if past the end of packet, ignore */
p_end = packet + TS_PACKET_SIZE;
if (p >= p_end)
return 0;
pos = url_ftell(ts->stream->pb);
ts->pos47= pos % ts->raw_packet_size;
if (tss->type == MPEGTS_SECTION) {
//表示當前的TS 包包含 個新的業務信息段
if (is_start) {
//獲取pointer field 字段,
//新的段從pointer field 字段指示的位置開始
len = *p++;
if (p + len > p_end)
return 0;
if (len && cc_ok) {
//這個時候TS 的負載有兩個部分構成：
//1)從TS 負載開始 pointer field 字段指示的位置;
//2)從pointer field 字段指示的位置 TS 包結束
//1)位置表明的是上 個段的末尾部分。
//2)位置表明的新的段開始的部分。
//下面的代碼是保存上 個段末尾部分數據，也就是
//1)位置的數據。
write_section_data(s, tss, p, len, 0);
/* check whether filter has been closed */
if (!ts->pids[pid])
return 0;
}
p += len;
//保留新的段數據，也就是2)位置的數據。
if (p < p_end) {
write_section_data(s, tss, p, p_end - p, 1);
}
} else {
//保存段中間的數據。
if (cc_ok) {
write_section_data(s, tss, p, p_end - p, 0);
}
}
} else {
int ret;
//正常的PES 數據的處理
// Note: The position here points actually behind the current packet.
if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
pos - ts->raw_packet_size)) < 0)
return ret;
}
return 0;
}
</pre>
<p><br>
8 write_section_data 函數分析 <br>
PSI 業務信息表在TS流中是以段爲單傳輸的。 </p>
<pre class="cpp" name="code">static void write_section_data(AVFormatContext *s, MpegTSFilter *tss1,
const uint8_t *buf, int buf_size, int is_start)
{
MpegTSSectionFilter *tss = &tss1->u.section_filter;
int len;
//buf 中是 個段的開始部分。
if (is_start) {
//將內容複製 tss->section_buf 中保存
memcpy(tss->section_buf, buf, buf_size);
//tss->section_index 段索引。
tss->section_index = buf_size;
//段的長度，如今還不知道，設置爲-1
tss->section_h_size = -1;
//是否 達段的結尾。
tss->end_of_section_reached = 0;
} else {
//buf 中是段中間的數據。
if (tss->end_of_section_reached)
return;
len = 4096 - tss->section_index;
if (buf_size < len)
len = buf_size;
memcpy(tss->section_buf + tss->section_index, buf, len);
tss->section_index += len;
}
//若是條件知足，計算段的長度
if (tss->section_h_size == -1 && tss->section_index >= 3) {
len = (AV_RB16(tss->section_buf + 1) & 0xfff) + 3;
if (len > 4096)
return;
tss->section_h_size = len;
}
//判斷段數據是否收集完畢，若是收集完畢，調用相應的回調函數處理該段。
if (tss->section_h_size != -1 && tss->section_index >= tss->section_h_size) {
tss->end_of_section_reached = 1;
if (!tss->check_crc ||
av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1,
tss->section_buf, tss->section_h_size) == 0)
tss->section_cb(tss1, tss->section_buf, tss->section_h_size);
}
}
</pre>
<p><br>
</p>
<pre></pre>
<pre></pre>
相關文章
- 1. TS 流解碼的流程分析
- 2. ffmpeg解析TS流(轉)
- 3. TS碼流格式分析
- 4. ffmpeg對mpeg2-TS解析的最詳細分析
- 5. ffmpeg轉碼MPEG2-TS的音視頻同步機制分析
- 6. TS流解析
- 7. ffmpeg轉TS流
- 8. TS流分析
- 9. 分析FFMPEG中H264編碼流程
- 10. MPEG1和MPEG2碼流結構分析
- 更多相關文章...
- • Hibernate的運行流程 - Hibernate教程
- • Lua 流程控制 - Lua 教程
- • Scala 中文亂碼解決
- • Git五分鐘教程
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. TS 流解碼的流程分析
- 2. ffmpeg解析TS流(轉)
- 3. TS碼流格式分析
- 4. ffmpeg對mpeg2-TS解析的最詳細分析
- 5. ffmpeg轉碼MPEG2-TS的音視頻同步機制分析
- 6. TS流解析
- 7. ffmpeg轉TS流
- 8. TS流分析
- 9. 分析FFMPEG中H264編碼流程
- 10. MPEG1和MPEG2碼流結構分析