FFMpeg对MPEG2 TS流解码的流程分析
2012-12-07 14:24
387 查看
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<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) 其中的这个特定格式,其实就是协议的规定格式:
由于 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
收藏到:
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_1.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_2.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_3.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_4.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_5.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_6.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_7.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_8.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_9.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_10.gif)
![](http://image40.360doc.com/DownloadImg/2011/10/1814/18573688_11.gif)
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;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,待续...... |
相关文章推荐
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析--一
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- FFMpeg对MPEG2 TS流解码的流程分析
- ffmpeg中MPEG2 TS 流解码的流程分析
- ffmpeg中MPEG2 TS 流解码的流程分析
- ffmpeg中MPEG2 TS 流解码的流程分析
- ffmpeg中MPEG2 TS 流解码的流程分析
- ffmpeg架构和解码流程分析
- ffmpeg 解码流程分析
- FFMpeg的output_example.c例子分析 (解码流程)