本次分享將圍繞以下幾部分進行：
下圖展示的是直播與點播的技術框架。
互動直播伺服器會對這些資料做合成/推流處理，傳輸至融合cdn流**伺服器，由流**伺服器推送資料給**互動直播的普通觀眾。
上圖展示的是實時音訊的簡單框架執行緒模型，這裡需要提醒的是，其中的解碼主要由客戶端完成，實時音的服務端不參加解碼而是把來自各端的資料報篩選之後傳遞給其他端。
我們以**教學場景為例，學生與老師正在上課，此時來自學生的音訊訊號被其移動終端採集模組採集，經過混音消除、降噪、自動增益控制等音訊的前處理過程，由音訊編碼器進行編碼。
在硬體層面，終端製造商對音訊處理流程中所需要的硬體都有一套同一切完善的引數調整經驗，例如麥克風的採集幀率、拾音距離、回聲延遲等都有統一規範；而考慮軟體層面的實時音訊則需面臨裝置數量龐大的難題，我們需要統一海量裝置與不同平台的複雜資料輸入並且考慮到軟體層面的不可預知性，也就是我們需要乙個完善的音訊處理系統，優化各模組之間的協同工作並保證演算法的穩定性。因此在這裡我向大家展示一下webrtc執行緒模型的設計和資料驅動方式：不同的顏色代表不同的執行緒。
首先，音訊資料被採集模組採集後進行音訊前處理，之後經由交付buffer被交至音訊codec進行編碼。（這裡強調的是，我們不把音訊buffer和codec放在乙個執行緒的原因是音訊codec的實時性計算量要求較高，需要單獨的乙個執行緒執行。而經過網路傳送時一般網路執行緒是直接將資料傳輸至audio jitter buff-er，audio jitter buffer獲取資料後會在網路執行緒上接收資料報，並更新網路統計和策略，而playback的callback請求往上**至audio jitter buffer請求資料過程是執行在playback的callbac**程上。
捕捉到的音訊資料會進入audio 3a處理。其中audio 3a由aec、ans、agc組成。不同的應用場景三者的處理順序也不同，如在webrtc中音訊資料回依次經過aec和ns 或者 ns 與aecm（aecm 是webrtc專門為移動端打造的演算法，計算量低，而aec 是為pc打造的）。
其中aagc的主要作用是通過系統的採集音量設定介面調整輸入訊號（大多用於pc端，移動端一般沒有輸入音量的系統介面），如借助windows上的的api調整採集音量等引數。aagc可為輸入的音訊資料帶來明顯的質量優化，如提高訊雜比，避免輸入訊號溢位等。但由於我們服務的跨平台要求，我們需要構建乙個面向多平台裝置的框架，在不同的輸入平台和裝置都會有不同的輸入音量，dagc可以根據對輸入訊號的跟蹤，盡量的調整訊號到達期望大小(幅值或能量)，從而避免不同裝置採集帶來的音量差異過大。完成agc處理的音訊資料，即可進入audio encode進行編碼操作。
因此我們需要乙個抵抗抖動的buffer來抵抗網路抖動的衝擊，從對delay要求高、平滑穩定過渡的角度考慮我們希望選擇較長的buffer，而從實時性出發我們又希望盡可能縮短buffer。
音訊指紋的演算法 飛利浦解決方案
這個音訊指紋暫時用來做同源音訊聚類，判斷歌曲是否是同一源的，這裡先介紹下飛利浦的方案 a highly robust audio fingerprinting system，這個演算法是在他上面的優化，幀 一段固定時間的音訊資訊，ts 相鄰兩個幀 兩個幀重疊時間域為 31 32,通過能量差分的關係，...
場景解決方案 附近的人
實現思路 想要不拖垮資料，要做到能走索引。就是跟你無關的點，不要掃瞄。減少掃瞄行數來實現減輕資料庫的壓力。那麼減少掃瞄行數肯定要想到索引。可是經緯度有兩個字段，且查詢條件無論怎麼寫都沒辦法走索引。那麼唯一能想到的就是二維變一維。geohash基本原理是將地球理解為乙個二維平面，將平面遞迴分解成更小的...
kafka在高併發場景下的解決方案
在我們現在開發的專案中，經常會用到kafka訊息中介軟體。一般情況下，單執行緒 單分割槽 的配置已經可以滿足需求，但是在某些大資料和資料併發量要求較高的應用場景下經常會遇到訊息來不及處理，出現訊息積壓的情況。因此，該文章主要針對這種應用場景提供了乙個多執行緒消費的解決方案 自己在平時使用kafka訊...