H264 TS/ES

ES流(Elementary Stream): 也叫基本码流,包含视频、音频或数据的连续码流.

      PES流(Packet Elementary Stream): 也叫打包的基本码流, 是将基本的码流ES流根据需要分成长度不等的数据包, 并加上包头就形成了打包的基本码流PES流.

      TS流(Transport Stream): 也叫传输流, 是由固定长度为188字节的包组成, 含有独立时基的一个或多个program, 一个program又可以包含多个视频、音频、和文字信息的ES流; 每个ES流会有不同的PID标示. 而又为了可以分析这些ES流, TS有一些固定的PID用来间隔发送program和ES流信息的表格: PAT和PMT表.

(在MPEG-2系统中,由视频, 音频的ES流和辅助数据复接生成的用于实际传输的标准信息流称为MPEG-2传送流)

      封装 : 就是捆绑打包, 将画面视频文件和音轨文件打包在一起, 并按照一定规则建立排序和索引, 便于播放器或播放软件来索引播放. 包括AVI / PS(Program Stream)/ TS(Transport Stream)/ MKV(Matroska)等.

 

1. 视频解码的整个流程大致如下:

 

 

 

      说明了视频文件解码的整个过程,而在做s3c6410硬件解码中,我们需要关注的是怎样把一个视频文件(avi/mkv/mp4)拿来,然后做demuxer变成raw video stream,接着就能输入到硬件中:

得到raw video后视频解码的整个过程,在编写过程中主要用到的API以及包含的文件如下图:

单纯的从raw video到播放比较简单,大部分的api都有了根据demo的程序改改,就可以基本解决了。

但还是有很多没搞定的:

1. 解复用demux这部分,我用ffmpeg来分流,avi格式的文件直接获取流以后,

while(av_read_frame(pFormatCtx, &packet) >= 0) 
    { 
        if(packet.stream_index == videoStream) 
        {}}

就可以一帧一帧的把他导入到另外一个文件中,然后就是可以播放的,但是ISO Media的就不行,mkv也不行。不知道是不是跟video container的格式有关。

 

2. 在硬件解码过程中,manual中说了,S3C6410 MFC codec支持两种模式的输入流(LINE_BUF和RING_BUF)。

LINE_BUF是the application needs to fill the input buffer with the video stream of the exact size of one frame.

RING_BUF是the application needs to fill the input buffer with the video stream of the size of PART. The size of PART is determined by the device driver.

但什么时候用RING_BUF什么时候用LINE_BUF我没弄明白。LINE_BUF, RING_BUF支持4种流解码的,而我在样例程序中使用的是LINE_BUF,测试的视频却是m4v, 264, rcv(上表中用ring_buf)。对这两个模式认识非常混乱。有待进一步研究。

感谢:http://qwdu.cublog.cn/

仔细看下MFC的那几个文档就可以了,文件封装的H264可能需要自己做demuxer,那个文档里面里面有提,ring buf模式支持文件封装的数据,我没测试,linebuf只支持标准的es流,我是用mplayer把文件demuxer出来的h264数据送到 linebuf模式的mfc,这样来测试的。 
网络上取H264数据,是rtp/udp还是http?反正都是文件封装的问题,最好用基本的es 流,如果没有文件封装,那需要在本地解析组装NAL

在第二个Q的回答中,我提到了两者区别,ring_buf模式中,mfc使用了自身的一些文件容器的封装,这样就不需要文件容器的解析这一步,line_buf是支持编码的帧数据,这样的数据必须从文件容器中解析才来得到 

TS流的解码过程-ES-PES-DTS-PTS-PCR

TS 流解码过程:

1. 获取TS中的PAT

2. 获取TS中的PMT

3. 根据PMT可以知道当前网络中传输的视频(音频)类型(H264),相应的PID,PCR的PID等信息。

4. 设置demux 模块的视频Filter 为相应视频的PID和stream type等。

5. 从视频Demux Filter 后得到的TS数据包中的payload 数据就是 one piece of PES,在TS header中有一些关于此 payload属于哪个 PES的 第多少个数据包。 因此软件中应该将此payload中的数据copy到PES的buffer中,用于拼接一个PES包。

6. 拼接好的PES包的包头会有 PTS,DTS信息,去掉PES的header就是 ES。

7. 直接将 被拔掉 PES包头的ES包送给decoder就可以进行解码。解码出来的数据就是一帧一帧的视频数据,这些数据至少应当与PES中的PTS关联一下,以便进行视音频同步。

8. I,B,B,P 信息是在ES中的。

 

 

ES 是直接从编码器出来的数据流,可以是编码过的视频数据流,音频数据流,或其他编码数据流的统称。 ES 流经过 PES 打包器之后,被转换成 PES 包。 PES 包由包头和 payload 组成.

 

在 PES 层,主要是在 PES 包头信息中加入 PTS( 显示时间标签 ) 和 DTS (解码时间标签)用于视频、音频同步。 其实, Mpeg-2 用于视音频同步以及系统时钟恢复的时间标签分别在 ES , PES 和 TS 这 3 个层次中。在 ES 层,与同步有关的主要是视频缓冲验证 VBV ( Video Buffer Verifier ),用以防止解码器的缓冲器出现上溢或下溢;在 PES 层,主要是在 PES 头信息里出现的显示时间标签 PTS ( Presentation Time Stamp )和解码时间标签 DTS ( Decoding Time Stamp );在 TS 层中, TS 头信息包含了节目时钟参考 PCR ( Program Clock Reference ),用于恢复出与编码端一致的系统时序时钟 STC ( System Time Clock )。

基本流程如下:首先 MPEG-2 压缩编码得到的 ES 基本流,这个数据流很大,并且只是 I , P , B 的这些视频帧或音频取样信息,然后加入一些同步信息,打包成长度可变长度的数据包 PES ,原来是流的格式,现在成了数据包的分割形式。同时要注意的是, ES 是只包含一种内容的数据流,如只含视频,或只含音频等,打包之后的 PES 也是只含一种性质的 ES, 如只含视频 ES 的 PES, 只含音频 ES 的 PES 等。可以知道, ES 是编码视频数据流或音频数据流,每个 ES 都由若干个存取单元( AU )组成,每个视频 AU 或音频 AU 都是由头部和编码数据两部分组成, 1 个 AU 相当于编码的 1 幅视频图像或 1 个音频帧,也可以说,每个 AU 实际上是编码数据流的显示单元,即相当于解码的 1 幅视频图像或 1 个音频帧的取样。 PEG-2 对视频的压缩产生 I 帧、 P 帧、 B 帧。把帧顺序 I1,P4,B2,B3,P7,B5,B6 帧的编码 ES ,通过打包并在每个帧中插入 PTS/DTS 标志,变成 PES 。在插入 PTS/DTS 标志时,由于在 B 帧 PTS 和 DTS 相等,所以无须在 B 帧多插入 DTS 。而对于 I 帧 和 P 帧,由于经过复用后数据包的顺序会发生变化,显示前一定要存储于视频解码器的从新排序缓存器中,经过从新排序后再显示,所以一定要同时插入 PTS 和 DTS 作为从新排序的依据。

 

其中,有否 PTS/DTS 标志,是解决视音频同步显示、防止解码器输入缓存器上溢或下溢的关键所在。 PTS 表明显示单元出现在系统目标解码器( STD- System Target Decoder )的时间 , DTS 表明将存取单元全部字节从 STD 的 ES 解码缓存器移走的时刻。 视频编码图像帧次序为 I1,P4,B2,B3,P7,B5,B6,I10,B8,B9 的 ES ,加入 PTS/DTS 后,打包成一个个视频 PES 包。每个 PES 包都有一个包头,用于定义 PES 内的数据内容,提供定时资料。每个 I 、 P 、 B帧的包头都有一个 PTS 和 DTS ,但 PTS 与 DTS 对 B 帧都是一样的,无须标出 B 帧的 DTS 。对 I 帧和 P 帧,显示前一定要存储于视频解码器的重新排序缓存器中,经过延迟(重新排序)后再显示,一定要分别标明 PTS 和 DTS 。例如,解码器输入的图像帧次序为 I1,P4,B2,B3,P7,B5,B6,I10,B8,B9 ,依解码器输出的帧次序,应该 P4 比 B2 、 B3 在先,但显示时 P4 一定要比 B2 、 B3 在后,即 P4 要在提前插入数据流中的时间标志指引下,经过缓存器重新排序,以重建编码前视频帧次序 I1,B2,B3,P4,B5,B6,P7,B8,B9,I10 。显然, PTS/DTS 标志表明对确定事件或确定信息解码的专用时标的存在,依靠专用时标解码器,可知道该确定事件或确定信息开始解码或显示的时刻。例如, PTS/DTS 标志可用于确定编码、多路复用、解码、重建的时间。

       PCR   

PCR 是 TS 里面的,即 TS packet 的 header 里面可能会有,他用来指定所期望的该 ts packet 到达 decoder 的时间,他的作用于 SCR 类似。

 

 

DTS, PTS

对于一个 ES 来说,比如视频,他有许多 I,P,B 帧,而 P, B 帧都是以 I , P 帧作为参考。由于 B 帧是前向后向参考,因此要对 B 帧作 decode 的话,就必须先 decode 该 B 帧后面的 帧( P, 或者 I 帧),于是, decode 的时间与帧的真正的 present 的时间就不一致了,按照 DTS 一次对各个帧进行 decode ,然后再按照 PTS 对各个帧进行展现。

有时候 PES 包头里面也会有 DTS , PTS ,对于 PTS 来说,他代表了这个 PES 包得 payload 里面的第一个完整地 audio access unit 或者 video access unit 的 PTS 时间(并不是每个 audio/video access unit 都带有 PTS/DTS ,因此,你可以在 PES 里面指定一个,作为开始)。

PES 包头的 DTS 也是这个原理,需要注意的是:对于 video 来说他的 DTS 和 PTS 是可以不一样的,因为 B 帧的存在使其顺序可以倒置。而对于 audio 来说, audio 没有双向的预测,他的 DTS 和 PTS 可以看成是一个顺序的,因此可一直采用一个,即可只采用 PTS。

时间: 2024-08-31 09:37:52

H264 TS/ES的相关文章

关于对H264码流的TS的封装的相关代码实现

1 写在开始之前              在前段时间有分享一个H264封装ps流到相关文章的,这次和大家分享下将H264封装成TS流到相关实现,其实也是工作工作需要.依照上篇一样,分段说明每个数据头的封装情况,当然,一样也会加上rtp头,方便以后的这方面到需求,如果开发不需要的话,可   以自行屏蔽掉,当然需要主要buffer指针的移动情况   2 封装的各个头到规则要点             整个封装过程也是和ps类似,但是最大到区别在于TS流到数据长度都是固定188大小来传输的,而PS流

ES PES TS

1.流媒体系统结构 ES:elemental stream 基本数据流: PES:packet elemental stream分组的基本数据流: 然后把PES打包成PS ,TS流,PS:program stream;TS:transport stream; DTS(解码时间戳)和PTS(显示时间戳)分别是解码器进行解码和显示帧时相对于SCR(系统参考)的时间戳.SCR可以理解为解码器应该开始从磁盘读取数据时的时间. DTS 2.         在MPEG-2系统中,信息复合/分离的过程称为系

H264码流打包分析(精华)

H264码流打包分析 SODB 数据比特串-->最原始的编码数据 RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit"1")若干比特"0",以便字节对齐. EBSP 扩展字节序列载荷-- >在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要填加每组NALU之前的开始码 StartCodePrefix,如果该NALU对应的slice为一帧的开始则

TS 流解码过程

TS 流解码过程: 1. 获取TS中的PAT 2. 获取TS中的PMT 3. 根据PMT可以知道当前网络中传输的视频(音频)类型(H264),相应的PID,PCR的PID等信息. 4. 设置demux 模块的视频Filter 为相应视频的PID和stream type等. 5. 从视频Demux Filter 后得到的TS数据包中的payload 数据就是 one piece of PES,在TS header中有一些关于此 payload属于哪个 PES的 第多少个数据包. 因此软件中应该将此

关于TS流的解析

TS即是"Transport Stream"的缩写.他是分包发送的,每一个包长为188字节.在TS流里可以填入很多类型的数据,如视频.音频.自定义信息等.他的包的结构为,包头为4个字节,负载为184个字节(这184个字节不一定都是有效数据,有一些可能为填充数据). 工作形式: 因为在TS流里可以填入很多种东西,所以有必要有一种机制来确定怎么来标识这些数据.制定TS流标准的机构就规定了一些数据结构来定义.比如: PSI(Program Specific Information)表,所以解

H264的RTP负载打包的数据包格式,分组,分片

H264的RTP负载打包的数据包格式,分组,分片   1.    RTP数据包格式 RTP报文头格式(见RFC3550 Page12):     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |V=2|P|X| CC   |M|     PT     |       seque

基于RTP的H264视频数据打包解包类

from:http://blog.csdn.net/dengzikun/article/details/5807694 最近考虑使用RTP替换原有的高清视频传输协议,遂上网查找有关H264视频RTP打包.解包的文档和代码.功夫不负有心人,找到不少有价值的文档和代码.参考这些资料,写了H264 RTP打包类.解包类,实现了单个NAL单元包和FU_A分片单元包.对于丢包处理,采用简单的策略:丢弃随后的所有数据包,直到收到关键帧.测试效果还不错,代码贴上来,若能为同道中人借鉴一二,足矣.两个类的使用说

TS数据结构分析

1.TS包得数据结构 2. // Transport packet headertypedef struct TS_packet_header{    unsigned sync_byte                                         :    8;    //同步字节,固定为0x47 ,表示后面的是一个TS分组,当然,后面包中的数据是不会出现0x47的    unsigned transport_error_indicator              :  

c-海康的H264数据做流媒体怎么做

问题描述 海康的H264数据做流媒体怎么做 问题是这样的,我正在开发手机流媒体服务器,海康转码后的H264数据如下49 4d 4b 48 01 01 00 00 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ba 44 1e b6 86 14 01 00 00 03 fe ff ff 00 00 00 00 00 00 01 bc 0