之前讀了ijkPlayer的代碼鲜棠，然后跟著寫(xiě)了整個(gè)流程赖淤，也可以播放了苫费。最近想把音視頻的知識(shí)總結(jié)規(guī)整下被环，所以想著從頭開(kāi)始寫(xiě)一個(gè)播放器楼雹，憑記憶寫(xiě)逼争，遇到問(wèn)題再去查优床，盡量不去看成熟的大段的代碼。只有這樣才能把那些不懂的地方暴露出來(lái)誓焦，就跟你看著參考答案是永遠(yuǎn)不會(huì)解題的胆敞。
寫(xiě)完后着帽，很幸運(yùn)，視頻一下就可以了移层，但是音頻卻是“莎莎莎”的仍翰，只能聽(tīng)到非常微小的原聲。
- AV_SAMPLE_FMT_FLTP
一開(kāi)始我是想先測(cè)一下观话，就沒(méi)有管格式里的帶plane的予借，然后播放之后就看了下，解碼后的音頻格式是AV_SAMPLE_FMT_FLTP频蛔。FFmpeg的音頻格式定義在AVSampleFormat里,后綴里帶P的都是Planar類型灵迫。
音頻分多個(gè)聲道，每個(gè)聲道的數(shù)據(jù)可能在一起晦溪，也可能是分離的瀑粥。這個(gè)屬性跟iOS里AudioStreamBasicDescription的NonInteractive(非交錯(cuò)的)是一個(gè)概念。
AAC解碼后默認(rèn)就是AV_SAMPLE_FMT_FLTP三圆，所以就加入了planar的支持狞换。但還是播放失敗。
- 畫(huà)圖
音頻這種東西舟肉，耳朵聽(tīng)得出來(lái)有問(wèn)題修噪，但是你不知道哪里有問(wèn)題。感覺(jué)就是混入了雜音路媚，不斷的有一些點(diǎn)很響黄琼。
沒(méi)辦法了就畫(huà)圖，就那種音波圖整慎，把采樣點(diǎn)的數(shù)值轉(zhuǎn)化成高度顯示出來(lái)适荣，就像這種：
然后發(fā)現(xiàn)有些地方數(shù)值很小，而且是一段一段的院领，然后突然想這錯(cuò)誤的一段是不是剛好對(duì)應(yīng)一次音頻數(shù)據(jù)填充弛矛，然后把畫(huà)圖的顏色改成交替的，就是一段黃一段黑比然。果然是這樣丈氓，然后在代碼里留下log標(biāo)記，這種程序調(diào)試也就靠log了强法。
再用系統(tǒng)的解碼器+audioUnit播放万俗，是正確的，也把圖畫(huà)出來(lái)饮怯，然后對(duì)比闰歪。
還有這時(shí)已經(jīng)換成1個(gè)聲道的44100采樣率的caf文件，caf內(nèi)存就是純的pcm沒(méi)有編碼蓖墅。這樣我就把解碼和重采樣的因素移除了库倘。
發(fā)現(xiàn)是memcpy(buffer, dataBuffer, needReadSize);的問(wèn)題临扮，buffer是要播放的緩沖區(qū)，dataBuffer是AVFrame的數(shù)據(jù)或者resample后的源數(shù)據(jù)教翩，needReadSize是讀取大小杆勇。
看起來(lái)好像沒(méi)錯(cuò)，可實(shí)際dataBuffer的類型是uint8_t **,它和AVFrame的extended_data一樣饱亿，代表是多個(gè)Plane的內(nèi)存蚜退，對(duì)每層的數(shù)據(jù)是dataBuffer[i],這才是真實(shí)有效的數(shù)據(jù)。而我是分plane處理的彪笼，所以這里正確的寫(xiě)法是memcpy(buffer, dataBuffer[i], needReadSize);,i是plane的索引钻注。
總結(jié)：
- 貼近內(nèi)存的編程，
void*是個(gè)危險(xiǎn)的東西配猫，你傳給它指針還是指針的指針队寇，它都不會(huì)報(bào)錯(cuò)。 - 移除干擾因素章姓，把AAC的視頻播放改成s16pcm+1channel+44.1k的純音頻,移除解碼和重采樣的可能錯(cuò)誤。
- 找到正確的對(duì)比：一個(gè)是畫(huà)成圖识埋，眼睛可以很直觀的看出來(lái)凡伊，而且播放完，圖還保留窒舟，可以慢慢對(duì)比系忙。一個(gè)是用了正確的播放手段得到正確的結(jié)果來(lái)對(duì)比。人都說(shuō)經(jīng)驗(yàn)重要惠豺，但其實(shí)成功的經(jīng)驗(yàn)才是最重要的!一個(gè)成功的银还，一個(gè)失敗的，才能找到問(wèn)題的關(guān)鍵洁墙，到不了成功的那一邊蛹疯，永遠(yuǎn)不知道問(wèn)題在哪里。
但到頭來(lái)热监，這本質(zhì)是一個(gè)愚蠢的代碼錯(cuò)誤捺弦，甚至不會(huì)帶來(lái)什么技術(shù)上的深刻理解，就是思維的錯(cuò)誤
- AAC的播放
解決上面的問(wèn)題孝扛，pcm的播放沒(méi)問(wèn)題了列吼，但是AAC的還是有問(wèn)題。有了上一個(gè)問(wèn)題的經(jīng)驗(yàn)苦始，我猜想問(wèn)題最可能還是出在了我的代碼里寞钥。所以我把代碼再檢查了一邊，尼瑪沒(méi)什么問(wèn)題陌选。
再看看音波圖理郑，看不出什么規(guī)律蹄溉，就是好像變粗了，
上一張是正確效果香浩，對(duì)比比較明顯的只有每個(gè)音柱變粗了类缤，波長(zhǎng)變大了。但耳朵聽(tīng)來(lái)好像差別不大邻吭，然后我去查“音頻波長(zhǎng)對(duì)聽(tīng)感有什么影響餐弱？”“變音的原理是什么？”囱晴「囹荆可惜沒(méi)查出什么。
然后逐步排查畸写，先看重采樣：swr_convert驮瞧。看輸入的nb_samples枯芬，分配的buffer大小有沒(méi)有影響论笔。可惜沒(méi)什么用千所，不過(guò)倒是把swr_convert的各個(gè)細(xì)節(jié)給摸透的狂魔。
最后，想著我是用AudioUnit寫(xiě)的音頻播放淫痰，把之前學(xué)ijkPlayer時(shí)的AudioQueue的播放器拿來(lái)試一試有沒(méi)有區(qū)別最楷。
然后迎來(lái)了轉(zhuǎn)機(jī)：我把采樣率調(diào)成48000，這個(gè)跟音頻源一樣待错，然后AudioQueue和AudioUnit最大的一個(gè)區(qū)別是籽孙，緩沖區(qū)的大小是自己設(shè)的，這決定了每一次讀取緩沖區(qū)的大小火俄，然后正好填了一個(gè)和音頻源的frame在resample之后的一樣的大小犯建。
產(chǎn)生的效果就是：每次AudioQueue讀取音頻數(shù)據(jù)都剛好是一個(gè)frame的。然后雜音都消失了瓜客，激動(dòng)疤タ妗！有了成功的經(jīng)驗(yàn)忆家，找到問(wèn)題就不遠(yuǎn)了犹菇！
然后我把緩沖區(qū)調(diào)大一倍，這樣的效果是每次音頻讀取芽卿，正好需要兩個(gè)frame揭芍，然后就出現(xiàn)了下面的音波圖：
很明確了，只有前一半的數(shù)據(jù)拿到了卸例，另一半都是0称杨。
然后使用打印內(nèi)存的手段肌毅，一步步的定位錯(cuò)誤的位置。打印內(nèi)存就是：
#define TFMPPrintBuffer_S16(buffer, start, length)\
signed short *checkP = ((signed short*)buffer)+start;\
for(int i = 0; i<length;i++){\
printf("%d ",*checkP);\
checkP++;\
}\
printf("\n-------------\n");
因?yàn)椴シ攀莝16格式的音頻姑原，所以使用SInt16悬而，就是signed short。
只要打印出來(lái)都是00000000的那就是出問(wèn)題的位置了锭汛。
最后定位到問(wèn)題：
memcpy(buffer, dataBuffer, linesize);笨奠，buffer是播放的緩沖區(qū)，dataBuffer是單層數(shù)據(jù)唤殴，linesize是單層的大小般婆。
也算比較隱蔽，問(wèn)題出在buffer朵逝，如果之前已經(jīng)拷貝了一段內(nèi)存蔚袍，那么之后拷貝的位置就該延后，否則就會(huì)把之前的覆蓋了配名，之前的丟失啤咽，現(xiàn)在的也錯(cuò)位了。而buffer我竟然沒(méi)有做偏移渠脉。
所以上面的現(xiàn)象就是宇整，第一個(gè)frame把內(nèi)存拷貝進(jìn)去，然后后一個(gè)frame的內(nèi)存有覆蓋在了第一個(gè)內(nèi)存上连舍，所以后半段是空的了。
正確的是：
memcpy(buffer+(oneLineSize - needReadSize), dataBuffer, linesize);
oneLineSize是總長(zhǎng)度涩哟，needReadSize是剩余長(zhǎng)度索赏。或者在每次memcpy后贴彼，都把buffer前移拷貝的內(nèi)存大小潜腻。
然后各種播放都好了，sampleRate器仗、bufferSize融涣、channel修改都不受影響。
總結(jié)：
- 不幸的是第二個(gè)問(wèn)題還是一個(gè)愚蠢的代碼錯(cuò)誤精钮。
- 需要做測(cè)試威鹿，單元測(cè)試。兩個(gè)問(wèn)題都是在
fillAudioBuffer函數(shù)里轨香，也就是外層播放器需要音頻數(shù)據(jù)了忽你，使用這個(gè)函數(shù)來(lái)獲取數(shù)據(jù)。如果我做一個(gè)測(cè)試：輸入模擬的AVFrame臂容，然后查看輸出的音頻buffer是否符合科雳。不要全部一樣根蟹，只要查某個(gè)offset的數(shù)值就可以。 - 之所以能找出問(wèn)題糟秘，是因?yàn)榇a走了某些特殊的分支简逮，測(cè)試需要覆蓋每種不同的分支。很多時(shí)候是你的某個(gè)分支代碼塊是對(duì)的尿赚，某些事錯(cuò)的散庶，然后混在一起，導(dǎo)致結(jié)果看起來(lái)更難分辨吼畏。
最重要的督赤，不要太相信眼睛看+腦子里的邏輯想象，需要實(shí)際的輸入+輸出的測(cè)試泻蚊！
