FFMpeg对MPEG2 TS流解码的流程分析
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”
恩,很简单吧,就是编码器编出的一组数据,可能是音频的,视频的,或者其他数据
说到着,其实可以对编码器的流程思考一下,无非是执行:采样,量化,编码这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]
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
来处理。
[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 != '' && *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 == '' || (q - proto_str) <= 1) {
file_proto:
strcpy(proto_str, "file");
} else {
*q = '';
}
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;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的过程,待续......
参考:
1.http://en.wikipedia.org/wiki/MPEG_transport_stream
2.ISO/IEC-13818-1
http://hi.baidu.com/bohryan/blog/item/9fac3a920685fa86a877a426.html[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24790158/viewspace-1041569/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24790158/viewspace-1041569/