FFmpeg優(yōu)化點播延時方案

場景要求
?? ?????????項目要求點播速度是300到500毫秒之間，現(xiàn)在最長的點播延時是1300毫秒（有的時候甚至無法播放視頻），生產(chǎn)環(huán)境是RTSP傳輸h364裸流數(shù)據(jù)，研究在接收到I幀的時候，開始出來圖像，簡化FFmpeg的調(diào)用邏輯（SPS/PPS已經(jīng)預(yù)先知道，并且分辨率也是固定為1920*1080）

解決方案
1）指定SPS/PPS參數(shù)，方便在調(diào)用avcodec_open2函數(shù)打開×××的時候，找到正確的視頻參數(shù)
https://blog.51cto.com/fengyuzaitu/2058138

2）通過指定視頻碼流格式H264減少探測時間
關(guān)鍵函數(shù)是：avformat_open_input和avformat_find_stream_info
https://blog.51cto.com/fengyuzaitu/1573766
https://blog.51cto.com/fengyuzaitu/1982996


3）核心是要求發(fā)送端發(fā)送的第一幀：強制I幀,根據(jù)如下的其他的方案指定碼流的格式

4）用戶新加入流媒體轉(zhuǎn)發(fā)隊列，流媒體推送用戶的第一幀，不一定是I幀（這一幀之前的SPS/PPS不能少），用戶需要等待一段時間才能看到畫面，直到I幀的出現(xiàn)隨著GOP的增大，時間可能更長。為了解決問題，需要緩存整一個GOP的圖像序列，單純保存I幀，沒有效果，因為每一個P幀都會依賴之前的P幀，類似于后面的圖片是前面圖片效果的疊加。新增加的用戶，先發(fā)送緩存的GOP序列，然后才發(fā)送剩下接收的數(shù)據(jù)

相關(guān)問題點有待研究
1)avformat_open_input取消問題的優(yōu)化
在代碼中指定如下：?? ??? ?
AVInputFormat* pAVInputFormat = av_find_input_format("h364");
pAVFormatContext->iformat = pAVInputFormat;
//if (avformat_open_input(&pAVFormatContext, "", pAVInputFormat, NULL) < 0)
如果不調(diào)用avformat_open_input函數(shù)實際上，影響到的是av_read_frame(pVideo->m_pAVFormatContext, packet)
出錯提示：
No start code is found
Error splitting the input into NAL units
實際上av_read_frame關(guān)鍵作用是從緩沖中拆分出一個個NAL單元（每一個NAL單元都是從00 00 00 01作為開始碼，開始的），
目前的解決方案是手動自己進行NAL單元的拆分，然后送到av_send_packet進行分幀解碼（從而也取消了
av_read_frame函數(shù)的調(diào)用），手動拆分出NAL，有點麻煩

正在研究的是avformat_open_input可能會填充pAVFormatContext的URLProtocol協(xié)議字段，不過這已經(jīng)是FFmpeg底層函數(shù)，
可能不可訪問，正在分析源碼

2）non-existing PPS 0 referenced問題
在調(diào)用av_read_frame函數(shù)的時候，會提示如上錯誤
non-existing PPS 0 referenced
decode_slice_header error
no frame!

但是實際上，手動添加SPS/PPS的內(nèi)容到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需要通過分析數(shù)據(jù)來確定輸入格式，所有程序啟動時，ffmpeg收到的數(shù)據(jù)最先應(yīng)該是SPS與PPS的nalu單元，然后是具體的視頻數(shù)據(jù)

相關(guān)博客
https://blog.51cto.com/fengyuzaitu/2058138
https://blog.51cto.com/fengyuzaitu/2057885

3）如果知道了碼流格式，實際上不需要調(diào)用什么探測碼流格式的函數(shù)，直接調(diào)用AVCodecContext解碼，就可以
目前在網(wǎng)上沒有相關(guān)的資料


FFmpeg日志定向輸出到文件
https://blog.51cto.com/fengyuzaitu/2053210
avcodec_send_packet函數(shù)錯誤定位
https://blog.51cto.com/fengyuzaitu/2046171

相關(guān)資料
1）http://www.yidianzixun.com/news_1eff46dc583b688d33a557b5582745dc
MP4的H264視頻數(shù)據(jù)保存在名為mdata的box當中，MediaRecorder通過socket發(fā)送出來的MP4數(shù)據(jù)包含四部分：填充符、ftyp、mdat、slice。
其中slice就是我們要找的視頻數(shù)據(jù)，slice是mdata的一部分，slice與mdata之間可能存在填充符，而slice與slice之間是連在一起的。
slice由視頻數(shù)據(jù)長度（4字節(jié)，前兩個字節(jié)通常為0）和視頻數(shù)據(jù)組成，其中視頻數(shù)據(jù)是不帶起始碼的H264 Nalu單元，
不難看出其第一個字節(jié)為0x65（關(guān)鍵幀）、0x41等。數(shù)據(jù)長度描述的是 H264 Nalu單元的長度，這樣我們已經(jīng)找到一幀完成的H264碼流數(shù)據(jù)了，
接下來我們只需將 Nalu單元提取出來前面加上0x00 00 00 01的4字節(jié)起始碼我們就得到了H264裸數(shù)據(jù)，這樣的數(shù)據(jù)在播放器上還不能播放，
需在H264裸數(shù)據(jù)文件的最前端加上SPS與PPS信息（他們也是有起始碼的哦），至此，播放器能夠正常播放文件了