ts文件
ts文件为传输流文件,视频编码主要格式h264/mpeg4,音频为acc/MP3。
ts文件分为三层:ts层Transport Stream、pes层 Packet Elemental Stream、es层 Elementary Stream. es层就是音视频数据,pes层是在音视频数据上加了时间戳等对数据帧的说明信息,ts层就是在pes层加入数据流的识别和传输必须的信息
(1)ts层 ts包大小固定为188字节,ts层分为三个部分:ts header、adaptation field、payload。ts header固定4个字节;adaptation field可能存在也可能不存在,主要作用是给不足188字节的数据做填充;payload是pes数据。
ts header
sync_byte | 8b | 同步字节,固定为0x47 |
transport_error_indicator | 1b | 传输错误指示符,表明在ts头的adapt域后由一个无用字节,通常都为0,这个字节算在adapt域长度内 |
payload_unit_start_indicator | 1b | 负载单元起始标示符,一个完整的数据包开始时标记为1 |
transport_priority | 1b | 传输优先级,0为低优先级,1为高优先级,通常取0 |
pid | 13b | pid值 |
transport_scrambling_control | 2b | 传输加扰控制,00表示未加密 |
adaptation_field_control | 2b | 是否包含自适应区,‘00’保留;‘01’为无自适应域,仅含有效负载;‘10’为仅含自适应域,无有效负载;‘11’为同时带有自适应域和有效负载。 |
continuity_counter | 4b | 递增计数器,从0-f,起始值不一定取0,但必须是连续的 |
ts层的内容是通过PID值来标识的,主要内容包括:PAT表、PMT表、音频流、视频流。解析ts流要先找到PAT表,只要找到PAT就可以找到PMT,然后就可以找到音视频流了。PAT表的PID值固定为0。PAT表和PMT表需要定期插入ts流,因为用户随时可能加入ts流,这个间隔比较小,通常每隔几个视频帧就要加入PAT和PMT。PAT和PMT表是必须的,还可以加入其它表如SDT(业务描述表)等,不过hls流只要有PAT和PMT就可以播放了。
-
PAT表:他主要的作用就是指明了PMT表的PID值。
-
PMT表:他主要的作用就是指明了音视频流的PID值。
-
音频流/视频流:承载音视频内容。
adaption
adaptation_field_length | 1B | 自适应域长度,后面的字节数 |
flag | 1B | 取0x50表示包含PCR或0x40表示不包含PCR |
PCR | 5B | Program Clock Reference,节目时钟参考,用于恢复出与编码端一致的系统时序时钟STC(System Time Clock)。 |
stuffing_bytes | xB | 填充字节,取值0xff |
自适应区的长度要包含传输错误指示符标识的一个字节。pcr是节目时钟参考,pcr、dts、pts都是对同一个系统时钟的采样值,pcr是递增的,因此可以将其设置为dts值,音频数据不需要pcr。如果没有字段,ipad是可以播放的,但vlc无法播放。打包ts流时PAT和PMT表是没有adaptation field的,不够的长度直接补0xff即可。视频流和音频流都需要加adaptation field,通常加在一个帧的第一个ts包和最后一个ts包里,中间的ts包不加。
PAT格式
table_id | 8b | PAT表固定为0x00 |
section_syntax_indicator | 1b | 固定为1 |
zero | 1b | 固定为0 |
reserved | 2b | 固定为11 |
section_length | 12b | 后面数据的长度 |
transport_stream_id | 16b | 传输流ID,固定为0x0001 |
reserved | 2b | 固定为11 |
version_number | 5b | 版本号,固定为00000,如果PAT有变化则版本号加1 |
current_next_indicator | 1b | 固定为1,表示这个PAT表可以用,如果为0则要等待下一个PAT表 |
section_number | 8b | 固定为0x00 |
last_section_number | 8b | 固定为0x00 |
开始循环 | ||
program_number | 16b | 节目号为0x0000时表示这是NIT,节目号为0x0001时,表示这是PMT |
reserved | 3b | 固定为111 |
PID | 13b | 节目号对应内容的PID值 |
结束循环 | ||
CRC32 | 32b | 前面数据的CRC32校验码 |
PMT格式
table_id | 8b | PMT表取值随意,0x02 |
section_syntax_indicator | 1b | 固定为1 |
zero | 1b | 固定为0 |
reserved | 2b | 固定为11 |
section_length | 12b | 后面数据的长度 |
program_number | 16b | 频道号码,表示当前的PMT关联到的频道,取值0x0001 |
reserved | 2b | 固定为11 |
version_number | 5b | 版本号,固定为00000,如果PAT有变化则版本号加1 |
current_next_indicator | 1b | 固定为1 |
section_number | 8b | 固定为0x00 |
last_section_number | 8b | 固定为0x00 |
reserved | 3b | 固定为111 |
PCR_PID | 13b | PCR(节目参考时钟)所在TS分组的PID,指定为视频PID |
reserved | 4b | 固定为1111 |
program_info_length | 12b | 节目描述信息,指定为0x000表示没有 |
开始循环 | ||
stream_type | 8b | 流类型,标志是Video还是Audio还是其他数据,h.264编码对应0x1b,aac编码对应0x0f,mp3编码对应0x03 |
reserved | 3b | 固定为111 |
elementary_PID | 13b | 与stream_type对应的PID |
reserved | 4b | 固定为1111 |
ES_info_length | 12b | 描述信息,指定为0x000表示没有 |
结束循环 | ||
CRC32 | 32b | 前面数据的CRC32校验码 |
(2)pes层
pes层是在每一个视频/音频帧上加入了时间戳等信息,pes包内容很多,我们只留下最常用的。
pes start code | 3B | 开始码,固定为0x000001 |
stream id | 1B | 音频取值(0xc0-0xdf),通常为0xc0 视频取值(0xe0-0xef),通常为0xe0 |
pes packet length | 2B | 后面pes数据的长度,0表示长度不限制, 只有视频数据长度会超过0xffff |
flag | 1B | 通常取值0x80,表示数据不加密、无优先级、备份的数据 |
flag | 1B | 取值0x80表示只含有pts,取值0xc0表示含有pts和dts |
pes data length | 1B | 后面数据的长度,取值5或10 |
pts | 5B | 33bit值 |
dts | 5B | 33bit值 |
pts是显示时间戳、dts是解码时间戳,视频数据两种时间戳都需要,音频数据的pts和dts相同,所以只需要pts。有pts和dts两种时间戳是B帧引起的,I帧和P帧的pts等于dts。如果一个视频没有B帧,则pts永远和dts相同。从文件中顺序读取视频帧,取出的帧顺序和dts顺序相同。dts算法比较简单,初始值 + 增量即可,pts计算比较复杂,需要在dts的基础上加偏移量。
音频的pes中只有pts(同dts),视频的I、P帧两种时间戳都要有,视频B帧只要pts(同dts)。打包pts和dts就需要知道视频帧类型,但是通过容器格式我们是无法判断帧类型的,必须解析h.264内容才可以获取帧类型。
举例说明:
I P B B B P
读取顺序: 1 2 3 4 5 6
dts顺序: 1 2 3 4 5 6
pts顺序: 1 5 3 2 4 6
点播视频dts算法:
dts = 初始值 + 90000 / video_frame_rate,初始值可以随便指定,但是最好不要取0,video_frame_rate就是帧率,比如23、30。
pts和dts是以timescale为单位的,1s = 90000 time scale , 一帧就应该是90000/video_frame_rate 个timescale。
用一帧的timescale除以采样频率就可以转换为一帧的播放时长
点播音频dts算法:
dts = 初始值 + (90000 * audio_samples_per_frame) / audio_sample_rate,audio_samples_per_frame这个值与编解码相关,aac取值1024,mp3取值1158,audio_sample_rate是采样率,比如24000、41000。AAC一帧解码出来是每声道1024个sample,也就是说一帧的时长为1024/sample_rate秒。所以每一帧时间戳依次0,1024/sample_rate,...,1024*n/sample_rate秒。
直播视频的dts和pts应该直接用直播数据流中的时间,不应该按公式计算。
(3)es层
es层指的就是音视频数据,我们只介绍h.264视频和aac音频。
h.264视频:
打包h.264数据我们必须给视频数据加上一个nalu(Network Abstraction Layer unit),nalu包括nalu header和nalu type,nalu header固定为0x00000001(帧开始)或0x000001(帧中)。h.264的数据是由slice组成的,slice的内容包括:视频、sps、pps等。nalu type决定了后面的h.264数据内容。
F | 1b | forbidden_zero_bit,h.264规定必须取0 |
NRI | 2b | nal_ref_idc,取值0~3,指示这个nalu的重要性,I帧、sps、pps通常取3,P帧通常取2,B帧通常取0 |
Type | 5b | 参考下表 |
nal_unit_type | 说明 |
0 | 未使用 |
1 | 非IDR图像片,IDR指关键帧 |
2 | 片分区A |
3 | 片分区B |
4 | 片分区C |
5 | IDR图像片,即关键帧 |
6 | 补充增强信息单元(SEI) |
7 | SPS序列参数集 |
8 | PPS图像参数集 |
9 | 分解符 |
10 | 序列结束 |
11 | 码流结束 |
12 | 填充 |
13~23 | 保留 |
24~31 | 未使用 |
红色字体显示的内容是最常用的,打包es层数据时pes头和es数据之间要加入一个type=9的nalu,关键帧slice前必须要加入type=7和type=8的nalu,而且是紧邻。
aac音频:
打包aac音频必须加上一个adts(Audio Data Transport Stream)头,共7Byte,adts包括fixed_header和variable_header两部分,各28bit。
fixed_header
syncword | 12b | 固定为0xfff |
id | 1b | 0表示MPEG-4,1表示MPEG-2 |
layer | 2b | 固定为00 |
protection_absent | 1b | 固定为1 |
profile | 2b | 取值0~3,1表示aac |
sampling_frequency_index | 4b | 表示采样率,0: 96000 Hz,1: 88200 Hz,2: 64000 Hz,3:48000 Hz,4: 44100 Hz,5: 32000 Hz,6: 24000 Hz,7: 22050 Hz,8: 16000 Hz,9: 12000 Hz,10: 11025 Hz,11: 8000 Hz,12: 7350 Hz |
private_bit | 1b | 固定为0 |
channel_configuration | 3b | 取值0~7,1: 1 channel: front-center,2: 2 channels: front-left, front-right,3: 3 channels: front-center, front-left, front-right,4: 4 channels: front-center, front-left, front-right, back-center |
original_copy | 1b | 固定为0 |
home | 1b | 固定为0 |
variable_header
copyright_identification_bit | 1b | 固定为0 |
copyright_identification_start | 1b | 固定为0 |
aac_frame_length | 13b | 包括adts头在内的音频数据总长度 |
adts_buffer_fullness | 11b | 固定为0x7ff |
number_of_raw_data_blocks_in_frame | 2b | 固定为00 |
mp3音频:
mp3音频不需要加adts头。
6.h264帧类型判断
当nalu type=5或1时,表示后面跟着的数据是视频数据,下面我们只列出前2项。
first_mb_in_slice | Golomb编码 | 一般为0,一个slice为一帧图像 |
slice_type | Golomb编码 | 帧类型,2、4、7、9表示I帧,0、3、5、8表示P帧 ,1、6表示B帧。 |
7.mp4转ts
我们假设mp4格式中的视频编码为h.264,音频编码为aac。我们从mp4中获取的视频信息包括:sps、pps、dts、pts、帧率、帧数据、ticks(每秒滴答数)。音频信息包括:pts、采样频率、声道数、帧数据。mp4文件的dts和ts文件的dts是需要进行换算的,都是初始值 + 增量,但是增量计算是不同的。
视频信息获取:
sps | stsd.avc1.avcC |
pps | stsd.avc1.avcC |
dts | stts |
pts | stts + ctts |
帧率 | 帧个数 / 总时长 |
timescale | trak.mdia.mdhd |
帧数据 | stsc + stco + stsz |
音频信息获取:
pts | stts |
采样频率 | trak.mdia.mdhd |
声道数 | stsd.mp4a |
帧数据 | stsc + stco + stsz |
8.mp4中关于h264和aac的说明
mp4的stsd原子中包含很多关键的音视频编解码元信息。对于视频数据,不同的编解码格式stsd中包含的子原子类型是不同的。MP4的视频H.264封装有2种格式:h264和avc1,只要看到这两个FOURCC(四字节编码)。就可以肯定是h.264编码,区别在于slice是否有起始码。对于音频数据,stsd中包含的子原子只会是mp4a,mp4a又包含了一个子原子esds,判断音频编码格式的是esds中的第十一个字节,如果是0x40则说明是aac编码,如果是0x69则说明是mp3。
-
AVC1 描述:H.264 bitstream without start codes.一般通过ffmpeg转码生成的视频,是不带起始码0×00000001的,但是带有4字节的长度。
-
H264 描述:H.264 bitstream with start codes.一般对于一下HDVD等电影的压制格式,是带有起始码0×00000001的。
除了avc1和h264还可能是下面的FOURCC,只是名字不同而已。
-
MEDIASUBTYPE_AVC1 'AVC1' H.264 bitstream without start codes.
-
MEDIASUBTYPE_H264 'H264' H.264 bitstream with start codes.
-
MEDIASUBTYPE_h264 'h264' Equivalent to MEDIASUBTYPE_H264, with a different FOURCC.
-
MEDIASUBTYPE_X264 'X264' Equivalent to MEDIASUBTYPE_H264, with a different FOURCC.
-
MEDIASUBTYPE_x264 'x264' Equivalent to MEDIASUBTYPE_H264, with a different FOURCC.
H264数据结构
NAL nal_unit_type中的
1(非IDR图像的编码条带)、
2(编码条带数据分割块A)、
3(编码条带数据分割块B)、
4(编码条带数据分割块C)、
7(SPS)、
8(PPS)
2、VCL视频编码层不做解释。
3、NAL nal_unit_type为序列参数集(SPS)、图像参数集(PPS)、增强信息(SEI)。表示后面的数据信息为序列参数集(SPS)、图像参数集(PPS)、增强信息(SEI)。
4、H.264的参数集又分为序列参数集(Sequence parameter set)和图像参数集(Pictureparameterset)。
序列参数集:包括一个图像序列的所有信息,即两个IDR图像间的所有图像信息。
图像参数集:包括一个图像的所有分片的所有相关信息,包括图像类型、序列号等,解码时某些序列号的丢 失可用来检验信息包的丢失与否。多个不同的序列和图像参数集存储在解码器中,编码器依据每个编码分片的头部的存储位置来选择适当的参数集,图像参数集本身也包括使用的序列参数集参考信息。
总结:
1、H.264 码流总体结构:
h264的功能分为两层,视频编码层(VCL)和网络提取层(NAL)。H.264 的编码视频序列包括一系列的NAL 单元,每个NAL 单元包含一个RBSP。一个原始的H.264 NALU 单元常由 [StartCode] [NALU Header] [NALU Payload] 三部分组成,其中 Start Code 用于标示这是一个NALU 单元的开始,必须是"00 00 00 01" 或"00 00 01"。
其中RBPS有分为几种类型:
NAL的解码单元的流程如下:
2、 H.264 NAL Header:
占一个字节,由三部分组成forbidden_bit(1bit),nal_reference_bit(2bits)(优先级),nal_unit_type(5bits)(类型)。
forbidden_bit:禁止位。
nal_reference_bit:当前NAL的优先级,值越大,该NAL越重要。
nal_unit_type :NAL类型。参见下表
几个例子:
1.ADTS是个啥
ADTS全称是(Audio Data Transport Stream),是AAC的一种十分常见的传输格式。
记得第一次做demux的时候,把AAC音频的ES流从FLV封装格式中抽出来送给硬件解码器时,不能播;保存到本地用pc的播放器播时,我靠也不能播。当时崩溃了,后来通过查找资料才知道。一般的AAC解码器都需要把AAC的ES流打包成ADTS的格式,一般是在AAC ES流前添加7个字节的ADTS header。也就是说你可以吧ADTS这个头看作是AAC的frameheader。
ADTS AAC
|
||||||
ADTS_header | AAC ES | ADTS_header | AAC ES |
...
|
ADTS_header | AAC ES |
ADTS 头中相对有用的信息 采样率、声道数、帧长度。想想也是,我要是解码器的话,你给我一堆得AAC音频ES流我也解不出来。每一个带ADTS头信息的AAC流会清晰的告送解码器他需要的这些信息。
一般情况下ADTS的头信息都是7个字节,分为2部分:
adts_fixed_header();
adts_variable_header();
syncword :同步头 总是0xFFF, all bits must be 1,代表着一个ADTS帧的开始
ID:MPEG Version: 0 for MPEG-4, 1 for MPEG-2
Layer:always: '00'
profile:表示使用哪个级别的AAC,有些芯片只支持AAC LC 。在MPEG-2 AAC中定义了3种:
sampling_frequency_index:表示使用的采样率下标,通过这个下标在 Sampling Frequencies[ ]数组中查找得知采样率的值。
There are 13 supported frequencies:
- 0: 96000 Hz
- 1: 88200 Hz
- 2: 64000 Hz
- 3: 48000 Hz
- 4: 44100 Hz
- 5: 32000 Hz
- 6: 24000 Hz
- 7: 22050 Hz
- 8: 16000 Hz
- 9: 12000 Hz
- 10: 11025 Hz
- 11: 8000 Hz
- 12: 7350 Hz
- 13: Reserved
- 14: Reserved
- 15: frequency is written explictly
- 0: Defined in AOT Specifc Config
- 1: 1 channel: front-center
- 2: 2 channels: front-left, front-right
- 3: 3 channels: front-center, front-left, front-right
- 4: 4 channels: front-center, front-left, front-right, back-center
- 5: 5 channels: front-center, front-left, front-right, back-left, back-right
- 6: 6 channels: front-center, front-left, front-right, back-left, back-right, LFE-channel
- 7: 8 channels: front-center, front-left, front-right, side-left, side-right, back-left, back-right, LFE-channel
- 8-15: Reserved
frame_length : 一个ADTS帧的长度包括ADTS头和AAC原始流.
adts_buffer_fullness:0x7FF 说明是码率可变的码流
3.将AAC打包成ADTS格式
如果是通过嵌入式高清解码芯片做产品的话,一般情况的解码工作都是由硬件来完成的。所以大部分的工作是把AAC原始流打包成ADTS的格式,然后丢给硬件就行了。
通过对ADTS格式的了解,很容易就能把AAC打包成ADTS。我们只需得到封装格式里面关于音频采样率、声道数、元数据长度、aac格式类型等信息。然后在每个AAC原始流前面加上个ADTS头就OK了。
贴上ffmpeg中添加ADTS头的代码,就可以很清晰的了解ADTS头的结构:
- int ff_adts_write_frame_header(ADTSContext *ctx,
- uint8_t *buf, int size, int pce_size)
- {
- PutBitContext pb;
- init_put_bits(&pb, buf, ADTS_HEADER_SIZE);
- /* adts_fixed_header */
- put_bits(&pb, 12, 0xfff); /* syncword */
- put_bits(&pb, 1, 0); /* ID */
- put_bits(&pb, 2, 0); /* layer */
- put_bits(&pb, 1, 1); /* protection_absent */
- put_bits(&pb, 2, ctx->objecttype); /* profile_objecttype */
- put_bits(&pb, 4, ctx->sample_rate_index);
- put_bits(&pb, 1, 0); /* private_bit */
- put_bits(&pb, 3, ctx->channel_conf); /* channel_configuration */
- put_bits(&pb, 1, 0); /* original_copy */
- put_bits(&pb, 1, 0); /* home */
- /* adts_variable_header */
- put_bits(&pb, 1, 0); /* copyright_identification_bit */
- put_bits(&pb, 1, 0); /* copyright_identification_start */
- put_bits(&pb, 13, ADTS_HEADER_SIZE + size + pce_size); /* aac_frame_length */
- put_bits(&pb, 11, 0x7ff); /* adts_buffer_fullness */
- put_bits(&pb, 2, 0); /* number_of_raw_data_blocks_in_frame */
- flush_put_bits(&pb);
- return 0;
- }