FFmpeg优化点播延时方案
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FFmpeg优化点播延时方案相关的知识,希望对你有一定的参考价值。
场景要求项目要求点播速度是300到500毫秒之间,现在最长的点播延时是1300毫秒(有的时候甚至无法播放视频),生产环境是RTSP传输h264裸流数据,研究在接收到I帧的时候,开始出来图像,简化FFmpeg的调用逻辑(SPS/PPS已经预先知道,并且分辨率也是固定为1920*1080)
解决方案
1)指定SPS/PPS参数,方便在调用avcodec_open2函数打开解码器的时候,找到正确的视频参数
http://blog.51cto.com/fengyuzaitu/2058138
2)通过指定视频码流格式H264减少探测时间
关键函数是:avformat_open_input和avformat_find_stream_info
http://blog.51cto.com/fengyuzaitu/1573766
http://blog.51cto.com/fengyuzaitu/1982996
3)核心是要求发送端发送的第一帧:强制I帧,根据如下的其他的方案指定码流的格式
相关问题点有待研究
1)avformat_open_input取消问题的优化
在代码中指定如下:
AVInputFormat* pAVInputFormat = av_find_input_format("h264");
pAVFormatContext->iformat = pAVInputFormat;
//if (avformat_open_input(&pAVFormatContext, "", pAVInputFormat, NULL) < 0)
如果不调用avformat_open_input函数实际上,影响到的是av_read_frame(pVideo->m_pAVFormatContext, packet)
出错提示:
No start code is found
Error splitting the input into NAL units
实际上av_read_frame关键作用是从缓冲中拆分出一个个NAL单元(每一个NAL单元都是从00 00 00 01作为开始码,开始的),
目前的解决方案是手动自己进行NAL单元的拆分,然后送到av_send_packet进行分帧解码(从而也取消了
av_read_frame函数的调用),手动拆分出NAL,有点麻烦
正在研究的是avformat_open_input可能会填充pAVFormatContext的URLProtocol协议字段,不过这已经是FFmpeg底层函数,
可能不可访问,正在分析源码
2)non-existing PPS 0 referenced问题
在调用av_read_frame函数的时候,会提示如上错误
non-existing PPS 0 referenced
decode_slice_header error
no frame!
但是实际上,手动添加SPS/PPS的内容到extradata字符串中,
unsigned char sps_pps[] = { 0x00 ,0x00 ,0x01,0x67,0x42,0x00 ,0x2a ,0x96 ,0x35 ,0x40 ,0xf0 ,0x04 ,0x4f ,0xcb ,0x37 ,0x01 ,0x01 ,0x01 ,0x40 ,0x00 ,0x01 ,0xc2 ,0x00 ,0x00 ,0x57 ,0xe4 ,0x01 ,0x00 ,0x00 ,0x00 ,0x01 ,0x68 ,0xce ,0x3c ,0x80, 0x00 };
pAVFormatContext->streams[0]->codecpar->extradata_size = sizeof(sps_pps);
pAVFormatContext->streams[0]->codecpar->extradata = (uint8_t*)av_mallocz(pAVFormatContext->streams[0]->codecpar->extradata_size + AV_INPUT_BUFFER_PADDING_SIZE);
memset(pAVFormatContext->streams[0]->codecpar->extradata, 0, sizeof(sps_pps) + FF_INPUT_BUFFER_PADDING_SIZE);
memcpy(pAVFormatContext->streams[0]->codecpar->extradata, sps_pps, sizeof(sps_pps));
FFmpeg需要通过分析数据来确定输入格式,所有程序启动时,ffmpeg收到的数据最先应该是SPS与PPS的nalu单元,然后是具体的视频数据
相关博客
http://blog.51cto.com/fengyuzaitu/2058138
http://blog.51cto.com/fengyuzaitu/2057885
3)如果知道了码流格式,实际上不需要调用什么探测码流格式的函数,直接调用AVCodecContext解码,就可以
目前在网上没有相关的资料
FFmpeg日志定向输出到文件
http://blog.51cto.com/fengyuzaitu/2053210
avcodec_send_packet函数错误定位
http://blog.51cto.com/fengyuzaitu/2046171
相关资料
1)http://www.yidianzixun.com/news_1eff46dc583b688d33a557b5582745dc
MP4的H264视频数据保存在名为mdata的box当中,MediaRecorder通过socket发送出来的MP4数据包含四部分:填充符、ftyp、mdat、slice。
其中slice就是我们要找的视频数据,slice是mdata的一部分,slice与mdata之间可能存在填充符,而slice与slice之间是连在一起的。
slice由视频数据长度(4字节,前两个字节通常为0)和视频数据组成,其中视频数据是不带起始码的H264 Nalu单元,
不难看出其第一个字节为0x65(关键帧)、0x41等。数据长度描述的是 H264 Nalu单元的长度,这样我们已经找到一帧完成的H264码流数据了,
接下来我们只需将 Nalu单元提取出来前面加上0x00 00 00 01的4字节起始码我们就得到了H264裸数据,这样的数据在播放器上还不能播放,
需在H264裸数据文件的最前端加上SPS与PPS信息(他们也是有起始码的哦),至此,播放器能够正常播放文件了
以上是关于FFmpeg优化点播延时方案的主要内容,如果未能解决你的问题,请参考以下文章
Windows平台下使用ffmpeg和segmenter实现m3u8直播点播