鉴于TS包的独立解码特性,HLS协议引入了TS格式作为传输单元。HLS协议的实现原理是对一个大的媒体分片,并将分片后的文件路径记录于m3u8文件,客户端依据该m3u8文件即可获取对应的分片列表,再依次播放分片内容。每个TS分片都以SPS与PPS等配置帧开头,其中指定了视频的规格信息及其编码参数,因此每个TS片段都能正常解析播放。关于SPS与PPS的详细说明参见之前的文章《解析H.264码流中的SPS帧和PPS帧》。
上述的分片文件便是一个个以TS格式封装的视频资源,那么当直播源来自一个MP4文件的时候,流媒体服务器又是怎么把MP4文件转化为一个个TS分片的呢?
以SRS为例,它在组装TS包时做了特殊处理,在每个TS包的开头位置,就自动插入SPS与PPS等配置帧。具体代码在SRS框架的trunk/src/main/srs_main_ingest_hls.cpp,查看该源码的SrsIngestHlsOutput::on_ts_video函数,找到以下的代码片段,可见程序在写入H.264流时,先写入SPS帧和PPS帧,再写入I帧、P帧和B帧。
找到write_h264_sps_pps函数的定义代码如下,发现函数内部在封装序列头时依次输入了SPS帧和PPS帧:
进一步跟踪mux_sequence_header的定义来源,详细的定义代码在SRS框架的trunk/src/protocol/srs_protocol_raw_avc.cpp,查看该源码的SrsRawH264Stream::mux_sequence_header函数,找到以下的代码片段,可见程序依据ISO_IEC_14496-15的文档规范,先后写入了sequenceParameterSet的NAL单元(即SPS帧),以及pictureParameterSet的NAL单元(即PPS帧)。
由此可见,SRS在每个TS包头都写入了SPS帧和PPS帧,确保TS包是拥有SPS和PPS的完整H.264分片。只有加上SPS与PPS,客户端才能正常拉流解析数据,才能正常渲染视频画面。
更多详细的FFmpeg开发知识参见