問(wèn)題現(xiàn)象
iOS豎屏下，編碼的碼流在Android, Windows的終端解碼偶現(xiàn)右側(cè)出現(xiàn)綠線或黑條苛谷。
問(wèn)題定位
解碼端排查
當(dāng)看到這個(gè)現(xiàn)象只在某些終端出現(xiàn)時(shí)，第一感覺(jué)應(yīng)該是解碼端的問(wèn)題部宿。因此抄腔，我們首先對(duì)解碼端進(jìn)行排查。
第一步理张，保存解碼端收到的碼流赫蛇。
第二步，使用StreamEye分析碼流雾叭，發(fā)現(xiàn)解碼端收到的碼流就存在了綠條悟耘，并且出現(xiàn)綠條的視頻碼流的分辨率為180x320和540x960。
因?yàn)榻獯a端收到的碼流就已經(jīng)有問(wèn)題了织狐，所以問(wèn)題又轉(zhuǎn)到了編碼端來(lái)排查暂幼。
編碼端排查
第一步，保存編碼后的視頻移迫。排除中間服務(wù)器的影響旺嬉，這也是我們定位問(wèn)題的原則，首先確定問(wèn)題是不是在自己的模塊厨埋，不能別人說(shuō)是你的問(wèn)題就是你的問(wèn)題邪媳，要有自己的判斷。
第二步荡陷，使用StreamEye分析碼流雨效，發(fā)現(xiàn)編碼后的碼流確實(shí)也存在綠條。查看編碼參數(shù)的配置废赞，分析哪些可能有關(guān)系徽龟，但是一直未發(fā)現(xiàn)問(wèn)題。接下只能編碼的前一個(gè)模塊走唉地，分析采集模塊了据悔。
第三步传透，保存采集后的yuv數(shù)據(jù)。
第四步屠尊，使用7yuv工具進(jìn)行分析yuv數(shù)據(jù)旷祸，發(fā)現(xiàn)也是有綠條。接下來(lái)就把主要精力放在了采集這個(gè)模塊讼昆。但是排查采集模塊的時(shí)托享，走了很多彎路，但是也收獲了不少浸赫。
采集模塊排查
首先第一感覺(jué)是yuv中為什么會(huì)出現(xiàn)綠條呢闰围？后來(lái)突然想起蘋(píng)果有一個(gè)方法CVPixelBufferGetBytesPerRowOfPlane獲取的值與yuv的寬度不一樣，這個(gè)函數(shù)獲取到數(shù)據(jù)包含了一些填充數(shù)據(jù)既峡，目的是為了內(nèi)存對(duì)齊羡榴。由于之前對(duì)這個(gè)了解的不是很清楚，然后網(wǎng)上搜索了一些關(guān)于這方面的內(nèi)容运敢，得到了一個(gè)跨距（stride）的概念校仑。跨距是指圖像中的一行圖像數(shù)據(jù)所占的存儲(chǔ)空間的長(zhǎng)度传惠，它是一個(gè)大于等于圖像寬度的內(nèi)存對(duì)齊的長(zhǎng)度迄沫。這樣每次讀取的時(shí)候以此為基準(zhǔn)讀取數(shù)據(jù)的時(shí)候就能內(nèi)存對(duì)齊。參考鏈接：http://www.reibang.com/p/68e05ad85490卦方。不同手機(jī)內(nèi)存對(duì)齊的位數(shù)是不一樣的羊瘩，測(cè)試發(fā)現(xiàn)iPhone6是16位對(duì)齊，iPhone6s是64位對(duì)齊盼砍。因此尘吗，yuv的右側(cè)有綠條或黑條也就是正常了，這時(shí)問(wèn)題又陷入了僵局浇坐。
只能猜想是不是系統(tǒng)編碼器內(nèi)部縮放yuv時(shí)睬捶，沒(méi)處理好跨距。現(xiàn)在只能懷疑一切了近刘。因此就想到使用libyuv先自己做縮放然后擒贸，再送人編碼器。
測(cè)試代碼如下：
//縮放yuv到當(dāng)前編碼分辨率
/*
CVPixelBufferLockBaseAddress(imageBuf, kCVPixelBufferLock_ReadOnly);
const uint8_t *src_y = CVPixelBufferGetBaseAddressOfPlane(imageBuf, 0);
int src_stride_y = (int)CVPixelBufferGetBytesPerRowOfPlane(imageBuf, 0);
const uint8_t *src_uv = CVPixelBufferGetBaseAddressOfPlane(imageBuf, 1);
int src_stride_uv = (int)CVPixelBufferGetBytesPerRowOfPlane(imageBuf, 1);
int src_width = (int)CVPixelBufferGetWidth(imageBuf);
int src_height = (int)CVPixelBufferGetHeight(imageBuf);
CVPixelBufferUnlockBaseAddress(imageBuf, kCVPixelBufferLock_ReadOnly);
OSStatus status;
CVPixelBufferRef pixelBuffer = NULL;
int dst_width = _width;
int dst_height = _height;
status = CVPixelBufferCreate(kCFAllocatorDefault, dst_width, dst_height, kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange, NULL, &pixelBuffer);
CVPixelBufferLockBaseAddress(pixelBuffer, kCVPixelBufferLock_ReadOnly);
int dst_stride_y = (int)CVPixelBufferGetBytesPerRowOfPlane(pixelBuffer, 0);
int dst_stride_uv = (int)CVPixelBufferGetBytesPerRowOfPlane(pixelBuffer, 1);
uint8_t *dst_y = CVPixelBufferGetBaseAddressOfPlane(pixelBuffer, 0);
uint8_t *dst_uv = CVPixelBufferGetBaseAddressOfPlane(pixelBuffer, 1);
int ret = NV12Scale(src_y, src_stride_y, src_uv, src_stride_uv, src_width, src_height, dst_y, dst_stride_y, dst_uv, dst_stride_uv, dst_width, dst_height, kFilterBox);
if (ret != 0) {
ILog(@"[%@] encodeFrame scale fail, [%dx%d]->[%dx%d]",self, src_width, src_height, dst_width, dst_height);
}
CVPixelBufferUnlockBaseAddress(pixelBuffer, kCVPixelBufferLock_ReadOnly);
但是跌宛，經(jīng)過(guò)測(cè)試發(fā)現(xiàn)libyuv縮放編碼后仍然有綠條。
問(wèn)題又一次陷入了僵局积仗，沒(méi)有頭緒疆拘。后來(lái)在用7yuv工具分析時(shí)，突然看到縮放前的yuv的真實(shí)數(shù)據(jù)寬度好像是704（其實(shí)是當(dāng)時(shí)看錯(cuò)了）寂曹，并不是720哎迄，這讓問(wèn)題又有了一絲希望回右。
沖著這個(gè)方向，懷疑是不是由于橫豎屏旋轉(zhuǎn)（橫屏情況下是正常的）時(shí)漱挚，導(dǎo)致yuv的真實(shí)數(shù)據(jù)出現(xiàn)了問(wèn)題翔烁。但是通過(guò)啟動(dòng)時(shí)直接設(shè)置為豎屏對(duì)比分析yuv數(shù)據(jù)，也是有問(wèn)題旨涝，故排除了蘋(píng)果內(nèi)部旋轉(zhuǎn)蹬屹。其實(shí)這個(gè)驗(yàn)證是不嚴(yán)謹(jǐn)?shù)模驗(yàn)閟etSessionPreset時(shí)白华，只支持橫屏的格式慨默，比如，AVCaptureSessionPreset1280x720弧腥。而我們只是啟動(dòng)時(shí)將AVCaptureConnection的setVideoOrientation設(shè)置為了AVCaptureVideoOrientationPortrait這個(gè)厦取，其內(nèi)部應(yīng)該還是做了旋轉(zhuǎn)。嚴(yán)謹(jǐn)?shù)姆绞綉?yīng)該是使用libyuv自己做旋轉(zhuǎn)管搪，才能排查虾攻。
但是在這個(gè)過(guò)程中突然發(fā)現(xiàn)yuv的有效數(shù)據(jù)是正常的，就是720寬更鲁，而跨距是768霎箍。開(kāi)始由于對(duì)7yuv工具上邊的標(biāo)尺使用不當(dāng)，后來(lái)發(fā)現(xiàn)點(diǎn)擊標(biāo)尺上的箭頭可以看到當(dāng)前的刻度值是多少岁经，哎朋沮，悲劇呀。
采集模塊出來(lái)的數(shù)據(jù)缀壤，有效數(shù)據(jù)的寬度正確樊拓，有效數(shù)據(jù)到跨距結(jié)束的部分，本來(lái)就應(yīng)該被填充一些無(wú)效數(shù)據(jù)塘慕，可能就是綠色或黑色筋夏。這下問(wèn)題排除是采集模塊的問(wèn)題了，這是只能又轉(zhuǎn)向編碼模塊了图呢。
編碼模塊排查
繼續(xù)用7yuv分析yuv數(shù)據(jù)条篷，發(fā)現(xiàn)一個(gè)細(xì)節(jié)yuv縮放后，180到184這個(gè)段的數(shù)據(jù)是純綠色或純黑色的蛤织，184到192的數(shù)據(jù)是不確定的赴叹，有綠色，有黑色指蚜。且184正好是8的倍數(shù)乞巧。懷疑是不是送入編碼器的有效數(shù)據(jù)需要是8的倍數(shù)呢？
因此摊鸡，嘗試將手動(dòng)縮放的分辯率改為184x320绽媒，即縮放后的yuv是184x320蚕冬，進(jìn)行測(cè)試，發(fā)現(xiàn)編碼后還是存在綠條或黑條是辕。
最后囤热，想起了編碼分辨率需要是8的倍數(shù)的說(shuō)法，嘗試將編碼分辨率改為184x320获三，測(cè)試發(fā)現(xiàn)編碼后的數(shù)據(jù)沒(méi)有綠條了旁蔼。這是由于
編碼h264視頻流的時(shí)候，h264的編碼宏塊大小16x16石窑，幀內(nèi)編碼時(shí)宏塊還拆成8x8子塊牌芋。
總結(jié)
這個(gè)排查過(guò)程中，有以下幾個(gè)收獲：
- 對(duì)跨距的理解更深刻了松逊，之前只是知道一個(gè)yuv真實(shí)數(shù)據(jù)和填充數(shù)據(jù)的事情躺屁。
- 對(duì)編碼器的分辨率寬度設(shè)置一定是8的倍數(shù)或16的倍數(shù)，這個(gè)概念記憶深刻经宏。
- 對(duì)7yuv工具的使用更加熟悉犀暑。
