『音視頻技術開發(fā)周刊』由LiveVideoStack團隊出品，專注在音視頻技術領域，縱覽相關技術領域的干貨和新聞投稿，每周一期。點擊『閱讀原文』，瀏覽第76期內(nèi)容，祝您閱讀愉快。

架構

基于WebRTC、Kurento的一種低延遲架構實現(xiàn)

在音視頻領域，低延遲交互一直是一個非常重要的需求。而直播大多基于RTMP協(xié)議，其存在1到3秒左右的延遲，基本無法勝任低延遲交互的需求；另外在游戲領域、語音聊天、教育領域，低延遲也是一個非常重要的議題。本文以直播的連麥架構的設計來簡單介紹下整個架構設計的演進流程。

使用級聯(lián)SFU改善媒體質量和規(guī)模

在多用戶視頻會議媒體服務器的部署中采用級聯(lián)結構可有效降低端到端的媒體延遲，改善媒體質量。來自Jitsi團隊的Boris Grozev深入描述了級聯(lián)SFU問題，并展示了他們的方法以及他們遇到.LiveVideoStack對文章進行了翻譯，感謝的WebRTC專家劉連響的技術審校。

深入刨析網(wǎng)絡流媒體協(xié)議之——RTSP協(xié)議

RTSP(Real-Time Stream Protocol)協(xié)議是一個基于文本的多媒體播放控制協(xié)議，屬于應用層。 是由Real Network和Netscape共同提出的如何有效地在IP網(wǎng)絡上傳輸流媒體數(shù)據(jù)的應用層協(xié)議。

雷輝：讓視頻會議conferencing like TV

伴隨視頻會議技術不斷成熟，其功能已不局限于早期僅僅滿足異地會議的需求，打破硬件的桎梏，提供白板、多媒體播放、文檔協(xié)同等更多功能，如何為視頻會議賦予更強大功能、實現(xiàn)更好體驗、滿足更多辦公需求成為一個新的課題。LiveVideoStack邀請到以色列視頻會議專家TeeVid CEO雷輝，一同分享他在實踐中遇到的技術難題與解決思路以及對未來技術趨勢的展望。

Demuxed：編解碼器和壓縮的未來

Demuxed視頻工程師年會生產(chǎn)了來自Akamai、YouTube、Mux和其它許多人必看的演講內(nèi)容，資深多媒體技術咨詢師Jan Ozer對會議中感興趣的部分內(nèi)容進行了回顧與總結。LiveVideoStack對文章進行了翻譯。

Android音頻開發(fā)之OpenSL ES

OpenSL ES 全稱是Open Sound Library for Embedded Systems , 即嵌入式音頻加速標準。OpenSL ES 是開源免費、跨平臺、針對嵌入式系統(tǒng)優(yōu)化的硬件音頻加速API。它為開發(fā)者提供了標準化、高性能、低響應時間的音頻功能實現(xiàn)方法。

如何搭建WebRTC服務器系列之一：Janus WebRTC Server

WebRTC服務器有很多，janus/kurento/licode/mediasoup/jitsi，各有優(yōu)缺。評價較好是janus。

音頻/視頻技術

封裝bilibili播放器 , 仿抖音視頻播放效果

本文中的項目使用的播放器是ijkplay, 并且進行封裝和修改。主要功能包括：1.重新編輯ijkplay的so庫, 使其更精簡和支持https協(xié)議；2.自定義MediaDataSource, 使用okhttp重寫網(wǎng)絡框架, 網(wǎng)絡播放更流暢3.實現(xiàn)視頻緩存, 并且自定義LRUCache算法管理緩存文件；4.全局使用一個播放器, 實現(xiàn)視頻在多個Activity之前無縫切換, 流暢播放；5.加入更多兼容性判斷, 適配絕大數(shù)機型。

RTP解析音視頻幀

RTSP中音視頻是通過RTP傳輸?shù)?#xff0c;本文記錄從RTP解析出H264、AAC的過程。協(xié)議介紹可參考 https://blog.csdn.net/lostyears/article/details/51374997拿到RTP數(shù)據(jù)后，先去除12字節(jié)RTP頭部，然后進行下面處理。

4K視頻在WebRTC中的實時傳輸

人們對音視頻體驗的追求是不斷在增長的，當1080P已經(jīng)逐漸成為主流分辨率的情況下，追求更高品質的畫面，將會是音視頻工作者需要提前去研究的。最近對4K視頻（分辨率 4096x2160 / 3840x2160）在WebRTC中的采/編/解/渲染進行了一次嘗試，總的來說還不錯。

一步步實現(xiàn)windows版ijkplayer系列文章之三——Ijkplayer播放器源碼分析之音視頻輸出——音頻篇

這篇文章的ijkplayer音頻源碼研究我們還是選擇Android平臺，它的音頻解碼是不支持硬解的，音頻播放使用的API是OpenSL ES或AudioTrack。

編解碼

iOS FFmpeg+x264 編碼

本文介紹iOS下使用FFmpeg+x264進行軟編碼。x264是一個開源的H.264/MPEG-4 AVC視頻編碼函數(shù)庫，我們可以直接使用x264的API進行編碼，也可以將x264編譯到FFmpeg中，使用FFmpeg提供的API進行編碼。

使用GPAC封裝MP4

在我的另一篇博客《使用mp4v2封裝MP4》中，發(fā)現(xiàn)mp4v2只支持H264封裝成MP4，這里使用gpac完成對H265的封裝。

Netty 源碼深度解析(八) - 解碼

Netty 提供了多種組件，簡化了為了支持廣泛 的協(xié)議而創(chuàng)建自定義的編解碼器的過程

例如，如果你正在構建一個基于 Netty 的郵件服務器，那 么你將會發(fā)現(xiàn) Netty 對于編解碼器的支持對于實現(xiàn) POP3、IMAP 和 SMTP 協(xié)議來說是多么的寶貴

ijkplayer如何使用FFmpeg 4.0內(nèi)核？

ijkplayer是基于FFmpeg作為內(nèi)核。上層ijkplayer封裝的東西，改動性沒有那么大，出問題，也都是在底層FFmpeg修改。如Demux，Codec等，還有各種協(xié)議。

AI智能

Android:Camera2開發(fā)詳解(下)：實現(xiàn)人臉檢測功能并實時顯示人臉框

本篇文章是在上篇文章的基礎之上，在預覽的時使用Camera2自帶的人臉檢測功能實時檢測人臉位置，并通過一個自定義view顯示在預覽畫面上

MSRA視覺組可變形卷積網(wǎng)絡升級！更高性能，更強建模能力

微軟亞洲研究院視覺計算組又一個令人拍案叫絕的操作：可變形卷積網(wǎng)絡v2版！DCNv2方法簡單，結果更好，在COCO基準測試中比上個版本提升了5個點。

3D實時換臉又有新進展！中科院博士生提出改進版本，每張圖推理只需0.27毫秒

此前，中科院自動化所的一篇論文《所有姿態(tài)范圍內(nèi)的面部替換：3D解決方案》引起廣泛關注。近日，中科院的一位博士生對“3D實時換臉”論文PyTorch實現(xiàn)改進版，使得每張圖的推理時間只需0.27毫秒，同時還增加了實時培訓等功能。

MIT研究人員提出新方法，可從單張圖片實現(xiàn)未知物體的三維外形重建

對于具有豐富的日常經(jīng)驗的人類來說，我們可以通過單一的圖像推斷出物體的三維形貌，甚至對從未見過的物體也能夠通過單一視角的圖像對其形狀有八九不離十的感官認知，但這對計算機來說卻是一個巨大的挑戰(zhàn)。目前從單一視圖重物體的三維形貌極大地受到了訓練數(shù)據(jù)的影響，對于未知物體的重建依然存在著一系列問題。

圖像

OpenCV 實踐——人臉檢測與人臉圖像提取

人臉對比是現(xiàn)在比較常用的功能，比如出租車司機人臉與司機駕照照片對比，門禁系統(tǒng)中進入者的人臉與人臉庫中的人臉進行對比。要實現(xiàn)人臉對比，首先要實現(xiàn)的是人臉檢測，在攝像頭拍攝到的一張圖片中，正確的檢測到人臉的位置，并且將人臉提取出來。考慮到免費開源，OpenCV 就可以很好的實現(xiàn)這個功能。

總結

以上是生活随笔為你收集整理的音视频技术开发周刊 76期的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。