国土安全吧:FFMpeg对MPEG2 TS流解码的流程分析

落鹤生 时间:2010-04-20 23:10 点击:1016次
FFMpeg对MPEG2 TS流解码的流程分析 1.引子 gnxzzz广告都打出去了，不能没有反应.现在写东西很少了，一是年纪大了，好奇心少了 许多，；二则是这几天又犯了扁桃体炎，每天只要是快睡觉或刚起床，头晕脑涨，不过功 课还是的做的，是吧:) 2. 从简单说起 说道具体的音频或
          
TAG: FFMPEG  MPEG2  视频解码  IPTV  MPEG2TS
1.引子
gnxzzz广告都打出去了，不能没有反应.现在写东西很少了，一是年纪大了，好奇心少了许多，；二则是这几天又犯了扁桃体炎，每天只要是快睡觉或刚起床，头晕脑涨，不过功课还是的做的，是吧:)
2. 从简单说起
说道具体的音频或者视频格式，一上来就是理论，那是国内混资历的所谓教授的做为，对于我们，不合适，还是用自己的方式理解这些晦涩不已的理论吧。
其实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协议中的一些概念，为理解代码做好功课:
ES(Elementary Stream):
wiki上说“An elementary stream (ES) is defined by MPEG communication protocol is usually the output of an audio or video encoder”
恩，很简单吧，就是编码器编出的一组数据，可能是音频的，视频的，或者其他数据，也即俗称的MPEG2裸码流
说到这，其实可以对编码器的流程思考一下，无非是执行：采样，量化，编码这3个步骤中的编码而已(有些设备可能会包含前面的采样和量化)。关于视频编码的基本理论，还是请参考其它的资料。
PES(Packetized Elementary Stream):
wiki上说“allows an Elementary stream to be divided into packets”
其实可以理解成，把一个源源不断的数据(音频，视频或者其他)流，打断成一段一段，以便处理.
TS(Transport Stream):通常可以理解成实时流
PS(Program Stream):通常可以理解成文件流
这两个上面已经有所提及，后面会详细分析TS,我对PS格式兴趣不大.
3. 步入正题
才进入正题，恩，看来闲话太多了:(,直接看Code.前面说过，TS是一种传输协议，因此，对应到FFmpeg,可以认为他是一种封装格式。因此，对应的代码应该先去libavformat里面找，很容易找到，就是mpegts.c:)
还是逐步看过来:
[libavformat/utils.c]
#########################################################################
【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来处理。
[liavformat/avio.c]
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######################################################################
参看后面的协议说明
######################################################################
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;idata_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的过程，待续......
参考：
1.http://en.wikipedia.org/wiki/MPEG_transport_stream
2.ISO/IEC－13818－1
当前位置: 主页>音视频技术>音视频编解码>
FFMpeg对MPEG2 TS流解码的流程分析[2]
落鹤生 时间:2010-04-20 23:18 点击:839次
5.渐入佳境 恩，前面的基础因该已近够了，有点像手剥洋葱头的感觉，我们来看看针对MPEG TS的相 应解析过程 我们后面的代码，主要集中在[libavformat/mpegts.c]里面，毛爷爷说：集中优势兵力打 围歼，恩，开始吧，蚂蚁啃骨头。 static int mpegts_read_header(AVFormatCo
          
TAG: FFMPEG  TS流  MPEG2  视频解码  IPTV  MPEG2TS
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的语法结构：
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;idata_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，待续......
本站遵循Creative Commons Attribution 3.0 License，所有文章欢迎任何形式的转载，但请注明作者及出处，尊重他人劳动成果！
文章转载自：罗索工作室 [http://www.rosoo.net]
本文标题：FFMpeg对MPEG2 TS流解码的流程分析[2]
本文作者：bohryan 本文来源:百度博客
本文地址：http://www.rosoo.net/a/201004/9193.html