「視訊直播技術詳解」系列之三:編碼和封裝
關於直播的技術文章不少,成體系的不多。我們將用七篇文章,更系統化地介紹當下大熱的視訊直播各環節的關鍵技術,幫助視訊直播創業者們更全面、深入地瞭解視訊直播技術,更好地技術選型。
本系列文章大綱如下,想複習之前文章的直接點選直達連結:
(三)編碼和封裝
(四)推流和傳輸
(五)現代播放器原理
(六)延遲優化
(七)SDK 效能測試模型
視訊編碼是視訊直播技術系列文章的第三篇,是本系列一個非常重要的部分,是移動開發必修的基礎課程,本篇文章從理論到實踐一網打盡主流編碼器。
如果把整個流媒體比喻成一個物流系統,那麼編解碼就是其中配貨和裝貨的過程,這個過程非常重要,它的速度和壓縮比對物流系統的意義非常大,影響物流系統的整體速度和成本。同樣,對流媒體傳輸來說,編碼也非常重要,它的編碼效能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的使用者體驗和傳輸成本。
視訊編碼的意義
- 原始視訊資料儲存空間大,一個 1080P 的 7 s 視訊需要 817 MB
- 原始視訊資料傳輸佔用頻寬大,10 Mbps 的頻寬傳輸上述 7 s 視訊需要 11 分鐘
而經過 H.264 編碼壓縮之後,視訊大小隻有 708 k ,10 Mbps 的頻寬僅僅需要 500 ms ,可以滿足實時傳輸的需求,所以從視訊採集感測器採集來的原始視訊勢必要經過視訊編碼。
基本原理
那為什麼巨大的原始視訊可以編碼成很小的視訊呢?這其中的技術是什麼呢?
核心思想就是去除冗餘資訊:
- 空間冗餘:影像相鄰畫素之間有較強的相關性
- 時間冗餘:視訊序列的相鄰影像之間內容相似
- 編碼冗餘:不同畫素值出現的概率不同
- 視覺冗餘:人的視覺系統對某些細節不敏感
- 知識冗餘:規律性的結構可由先驗知識和背景知識得到
視訊本質上講是一系列圖片連續快速的播放,最簡單的壓縮方式就是對每一幀圖片進行壓縮,例如比較古老的 MJPEG 編碼就是這種編碼方式,這種編碼方式只有幀內編碼,利用空間上的取樣預測來編碼。形象的比喻就是把每幀都作為一張圖片,採用 JPEG 的編碼格式對圖片進行壓縮,這種編碼只考慮了一張圖片內的冗餘資訊壓縮,如圖 1,綠色的部分就是當前待編碼的區域,灰色就是尚未編碼的區域,綠色區域可以根據已經編碼的部分進行預測(綠色的左邊,下邊,左下等)。
但是幀和幀之間因為時間的相關性,後續開發出了一些比較高階的編碼器可以採用幀間編碼,簡單點說就是通過搜尋演算法選定了幀上的某些區域,然後通過計算當前幀和前後參考幀的向量差進行編碼的一種形式,通過下面兩個圖 2 連續幀我們可以看到,滑雪的同學是向前位移的,但實際上是雪景在向後位移,P 幀通過參考幀(I 或其他 P 幀)就可以進行編碼了,編碼之後的大小非常小,壓縮比非常高。
可能有同學對這兩張圖片怎麼來的感興趣,這裡用了 FFmpeg 的兩行命令來實現,具體 FFmpeg 的更多內容請看後續章節:
- 第一行生成帶有移動向量的視訊
第二行把每一幀都輸出成圖片
ffmpeg -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4 ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'
除了空間冗餘和時間冗餘的壓縮,主要還有編碼壓縮和視覺壓縮,下面是一個編碼器主要的流程圖:
圖 3、圖 4 兩個流程,圖 3 是幀內編碼,圖 4 是幀間編碼,從圖上看到的主要區別就是第一步不相同,其實這兩個流程也是結合在一起的,我們通常說的 I 幀和 P 幀就是分別採用了幀內編碼和幀間編碼。
編碼器的選擇
前面梳理了一下編碼器的原理和基本流程,編碼器經歷了數十年的發展,已經從開始的只支援幀內編碼演進到現如今的 H.265 和 VP9 為代表的新一代編碼器,就目前一些常見的編碼器進行分析,帶大家探索一下編碼器的世界。
H.264
簡介
H.264/AVC 專案意圖建立一種視訊標準。與舊標準相比,它能夠在更低頻寬下提供優質視訊(換言之,只有 MPEG-2,H.263 或 MPEG-4 第 2 部分的一半頻寬或更少),也不增加太多設計複雜度使得無法實現或實現成本過高。另一目的是提供足夠的靈活性以在各種應用、網路及系統中使用,包括高、低頻寬,高、低視訊解析度,廣播,DVD 儲存,RTP/IP 網路,以及 ITU-T 多媒體電話系統。
H.264/AVC 包含了一系列新的特徵,使得它比起以前的編解碼器不但能夠更有效的進行編碼,還能在各種網路環境下的應用中使用。這樣的技術基礎讓 H.264 成為包括 YouTube 在內的線上視訊公司採用它作為主要的編解碼器,但是使用它並不是一件很輕鬆的事情,理論上講使用 H.264 需要交納不菲的專利費用。
專利許可
和 MPEG-2 第一部分、第二部分,MPEG-4第二部分一樣,使用 H.264/AVC 的產品製造商和服務提供商需要向他們的產品所使用的專利的持有者支付專利許可費用。這些專利許可的主要來源是一家稱為 MPEG-LA LLC 的私有組織,該組織和 MPEG 標準化組織沒有任何關係,但是該組織也管理著 MPEG-2 第一部分系統、第二部分視訊、MPEG-4 第二部分視訊和其它一些技術的專利許可。
其他的專利許可則需要向另一家稱為 VIA Licensing 的私有組織申請,這家公司另外也管理偏向音訊壓縮的標準如 MPEG-2 AAC 及 MPEG-4 Audio 的專利許可。
H.264 的開源實現
- openh264
- x264
openh264 是思科實現的開源 H.264 編碼,雖然 H.264 需要交納不菲的專利費用,但是專利費有一個年度上限,思科把 OpenH264 實現的年度專利費交滿後,OpenH264 事實上就可以免費自由的使用了。
x264 x264是一個採用GPL授權的視訊編碼自由軟體。x264 的主要功能在於進行 H.264/MPEG-4 AVC 的視訊編碼,而不是作為解碼器(decoder)之用。
除去費用問題比較來看:
- openh264 CPU 的佔用相對 x264低很多
- openh264 只支援 baseline profile,x264 支援更多 profile
HEVC/H.265
簡介
高效率視訊編碼(High Efficiency Video Coding,簡稱HEVC)是一種視訊壓縮標準,被視為是 ITU-T H.264/MPEG-4 AVC 標準的繼任者。2004 年開始由 ISO/IEC Moving Picture Experts Group(MPEG)和 ITU-T Video Coding Experts Group(VCEG)作為 ISO/IEC 23008-2 MPEG-H Part 2 或稱作 ITU-T H.265 開始制定。第一版的 HEVC/H.265 視訊壓縮標準在 2013 年 4 月 13 日被接受為國際電信聯盟(ITU-T)的正式標準。HEVC 被認為不僅提升視訊質量,同時也能達到 H.264/MPEG-4 AVC 兩倍之壓縮率(等同於同樣畫面質量下位元率減少了 50%),可支援 4K 解析度甚至到超高清電視(UHDTV),最高解析度可達到 8192×4320(8K解析度)。
H.265 的開源實現
- libde265
- x265
libde265 HEVC 由 struktur 公司以開源許可證 GNU LesserGeneral Public License (LGPL) 提供,觀眾可以較慢的網速下欣賞到最高品質的影像。跟以前基於H.264標準的解碼器相比,libde265 HEVC 解碼器可以將您的全高清內容帶給多達兩倍的受眾,或者,減少 50% 流媒體播放所需要的頻寬。高清或者 4K/8K 超高清流媒體播放,低延遲/低頻寬視訊會議,以及完整的移動裝置覆蓋。具有「擁塞感知」視訊編碼的穩定性,十分適合應用在 3/4G 和 LTE 網路。
專利許可
HEVC Advance 要求所有包括蘋果、YouTube、Netflix、Facebook、亞馬遜等使用 H.265 技術的內容製造商上繳內容收入的 0.5%作為技術使用費,而整個流媒體市場每年達到約 1000 億美元的規模,且不斷增長中,徵收 0.5%絕對是一筆龐大的費用。而且他們還沒有放過裝置製造商,其中電視廠商需要支付每臺 1.5 美元、移動裝置廠商每臺 0.8 美元的專利費。他們甚至沒有放過藍光裝置播放器、遊戲機、錄影機這樣的廠商,這些廠商必須支付每臺 1.1 美元的費用。最無法令人接受的是,HEVC Advance 的專利使用權追溯到了廠商的「」”,意思是之前已經發售的產品依然要追繳費用。
x265 是由 MulticoreWare 開發,並開源。採用 GPL 協議,但是資助這個專案的幾個公司組成了聯盟可以在非 GPL 協議下使用這個軟體。
VP8
簡介
VP8 是一個開放的視訊壓縮格式,最早由 On2 Technologies 開發,隨後由 Google 釋出。同時 Google 也釋出了 VP8 編碼的實做庫:libvpx,以 BSD 授權條款的方式發行,隨後也附加了專利使用權。而在經過一些爭論之後,最終 VP8 的授權確認為一個開放原始碼授權。
目前支援 VP8 的網頁瀏覽器有 Opera、Firefox 和 Chrome。
專利許可
2013 年三月,Google 與 MPEG LA 及 11 個專利持有者達成協議,讓Google 獲取 VP8 以及其之前的 VPx 等編碼所可能侵犯的專利授權,同時 Google 也可以無償再次授權相關專利給 VP8 的使用者,此協議同時適用於下一代 VPx 編碼。至此 MPEG LA 放棄成立 VP8 專利集中授權聯盟,VP8 的使用者將可確定無償使用此編碼而無須擔心可能的專利侵權授權金的問題。
VP8 的開源實現
- libvpx
libvpx 是 VP8 的唯一開源實現,由 On2 Technologies 開發,Google 收購後將其開放原始碼,License 非常寬鬆可以自由使用。
VP9
簡介
VP9 的開發從 2011 年第三季開始,目標是在同畫質下,比 VP8 編碼減少 50%的檔案大小,另一個目標則是要在編碼效率上超越 HEVC 編碼。
2012 年 12 月 13 日,Chromium 瀏覽器加入了 VP9 編碼的支援。Chrome 瀏覽器則是在 2013 年 2 月 21 日開始支援 VP9 編碼的視訊播放。
Google 宣佈會在 2013 年 6 月 17 日完成 VP9 編碼的制定工作,屆時Chrome 瀏覽器將會把 VP9 編碼預設引導。2014 年 3 月 18 日,Mozilla 在 Firefox 瀏覽器中加入了 VP9 的支援。
2015 年 4 月 3 日,谷歌釋出了 libvpx1.4.0 增加了對 10 位和 12 位的位元深度支援、4:2:2 和 4:4:4 色度抽樣,並 VP9 多核心編/解碼。
專利許可
VP9 是一個開放格式、無權利金的視訊編碼格式。
VP9 的開源實現
- libvpx
libvpx 是 VP9 的唯一開源實現,由 Google 開發維護,裡面有部分程式碼是 VP8 和 VP9 公用的,其餘分別是 VP8 和 VP9 的編解碼實現。
VP9 和 H.264 和 HEVC 比較
引用 Comparative Assessment of H.265/MPEG-HEVC, VP9, and H.264/MPEG-AVC Encoders for Low-Delay Video Applications 這篇比較新的論文對,低延遲視訊進行編碼的測試結果。
HEVC 和 H.264 在不同解析度下的比較
跟 H.264/MPEG-4 相比,HEVC 的平均位元率減低值為:
可見位元速率下降了 60% 以上。
- HEVC (H.265) 對 VP9 和 H.264 在位元速率節省上有較大的優勢,在相同 PSNR 下分別節省了 48.3% 和 75.8%。
- H.264 在編碼時間上有巨大優勢,對比 VP9 和 HEVC(H.265) ,HEVC 是 VP9 的6倍,VP9 是 H.264 的將近 40 倍
FFmpeg
談到視訊編碼相關內容就不得不提一個偉大的軟體包 -- FFmpeg。
FFmpeg 是一個自由軟體,可以執行音訊和視訊多種格式的錄影、轉換、流功能,包含了 libavcodec ——這是一個用於多個專案中音訊和視訊的解碼器庫,以及 libavformat ——一個音訊與視訊格式轉換庫。
FFmpeg 這個單詞中的 FF 指的是 Fast Forward。有些新手寫信給 FFmpeg 的專案負責人,詢問 FF 是不是代表 Fast Free 或者 Fast Fourier 等意思,FFmpeg 的專案負責人回信說:「Just for the record, the original meaning of FF in FFmpeg is Fast Forward...」
這個專案最初是由 Fabrice Bellard 發起的,而現在是由 Michael Niedermayer 在進行維護。許多FFmpeg的開發者同時也是 MPlayer 專案的成員,FFmpeg 在 MPlayer 專案中是被設計為伺服器版本進行開發。
FFmpeg 下載地址是 : FFmpeg Download
- 可以瀏覽器輸入下載,目前支援 Linux ,Mac OS,Windows 三個主流的平臺,也可以自己編譯到 Android 或者 iOS 平臺。
- 如果是 Mac OS ,可以通過 brew 安裝
brew install ffmpeg --with-libvpx --with-libvorbis --with-ffplay
我們可以用 FFmpeg 來做哪些有用有好玩的事情呢?通過一系列小實驗來帶大家領略 FFmpeg 的神奇和強大。
FFmpeg 錄屏
通過一個小例子看一下怎麼在 Mac OS 下面使用 FFmpeg 進行錄屏:
輸入:
ffmpeg -f avfoundation -list_devices true -i ""
輸出:
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation video devices:
[AVFoundation input device @ 0x7fbec0c10940] [0] FaceTime HD Camera
[AVFoundation input device @ 0x7fbec0c10940] [4] Capture screen 0
[AVFoundation input device @ 0x7fbec0c10940] [5] Capture screen 1
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation audio devices:
[AVFoundation input device @ 0x7fbec0c10940] [0] Built-in Microphone
給出了當前裝置支援的所有輸入裝置的列表和編號,我本地有兩塊顯示器,所以 1 和 2 都是我螢幕,可以選擇一塊進行錄屏。
檢視當前的 H.264 編解碼器:
輸入:
ffmpeg -codecs | grep 264
輸出:
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb )
檢視當前的 VP8 編解碼器:
輸入:
ffmpeg -codecs | grep vp8
輸出:
DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )
可以選擇用 vp8 或者 h264 做編碼器
ffmpeg -r 30 -f avfoundation -i 1 -vcodec vp8 -quality realtime screen2.webm# -quality realtime 用來優化編碼器,如果不加在我的 Air 上幀率只能達到 2
or
ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4
然後用 ffplay 播放就可以了
ffplay screen.mp4
or
ffplay screen2.webp
FFmpeg 視訊轉換成 gif
有一個特別有用的需求,在網上發現了一個特別有趣的視訊想把它轉換成一個動態表情,作為一個 IT 從業者,我第一個想到的不是下載一個轉碼器,也不是去找一個線上轉換網站,直接利用手邊的工具 FFmpeg,瞬間就完成了轉碼:
ffmpeg -ss 10 -t 10 -i tutu.mp4 -s 80x60 tutu.gif## -ss 指從 10s 開始轉碼,-t 指轉換 10s 的視訊 -s
FFmpeg 錄製螢幕並直播
可以繼續擴充套件例子1,直播當前螢幕的內容,向大家介紹一下怎麼通過幾行命令搭建一個測試用的直播服務:
Step 1:首先安裝 docker: 訪問 Docker Download ,按作業系統下載安裝。
Step 2:下載 nginx-rtmp 映象:
docker pull chakkritte/docker-nginx-rtmp
Step 3:建立 nginx html 路徑,啟動 docker-nginx-rtmp
mkdir ~/rtmp docker run -d -p 80:80 -p 1935:1935 -v ~/rtmp:/usr/local/nginx/html chakkritte/docker-nginx-rtmp
Step 4:推送螢幕錄製到 nignx-rtmp
ffmpeg -y -loglevel warning -f avfoundation -i 2 -r 30 -s 480x320 -threads 2 -vcodec libx264 -f flv rtmp://127.0.0.1/live/test
Step 5:用 ffplay 播放
ffplay rtmp://127.0.0.1/live/test
總結一下,FFmpeg 是個優秀的工具,可以通過它完成很多日常的工作和實驗,但是距離提供真正可用的流媒體服務、直播服務還有非常多的工作要做,這方面可以參考七牛雲釋出的 七牛直播雲服務 。
封裝
介紹完了視訊編碼後,再來介紹一些封裝。沿用前面的比喻,封裝可以理解為採用哪種貨車去運輸,也就是媒體的容器。
所謂容器,就是把編碼器生成的多媒體內容(視訊,音訊,字幕,章節資訊等)混合封裝在一起的標準。容器使得不同多媒體內容同步播放變得很簡單,而容器的另一個作用就是為多媒體內容提供索引,也就是說如果沒有容器存在的話一部影片你只能從一開始看到最後,不能拖動進度條(當然這種情況下有的播放器會話比較長的時間臨時建立索引),而且如果你不自己去手動另外載入音訊就沒有聲音,下面介紹幾種常見的封裝格式和優缺點:
AVI 格式(字尾為 .AVI): 它的英文全稱為 Audio Video Interleaved ,即音訊視訊交錯格式。它於 1992 年被 Microsoft 公司推出。 這種視訊格式的優點是影像質量好。由於無損AVI可以儲存 alpha 通道,經常被我們使用。缺點太多,體積過於龐大,而且更加糟糕的是壓縮標準不統一,最普遍的現象就是高版本 Windows 媒體播放器播放不了採用早期編碼編輯的AVI格式視訊,而低版本 Windows 媒體播放器又播放不了採用最新編碼編輯的AVI格式視訊,所以我們在進行一些AVI格式的視訊播放時常會出現由於視訊編碼問題而造成的視訊不能播放或即使能夠播放,但存在不能調節播放進度和播放時只有聲音沒有影像等一些莫名其妙的問題。
DV-AVI 格式(字尾為 .AVI): DV的英文全稱是 Digital Video Format ,是由索尼、松下、JVC 等多家廠商聯合提出的一種家用數字視訊格式。 數字攝像機就是使用這種格式記錄視訊資料的。它可以通過電腦的 IEEE 1394 埠傳輸視訊資料到電腦,也可以將電腦中編輯好的的視訊資料回錄到數碼攝像機中。這種視訊格式的副檔名也是 avi。電視臺採用錄影帶記錄模擬訊號,通過 EDIUS 由IEEE 1394埠採集卡從錄影帶中採集出來的視訊就是這種格式。
QuickTime File Format 格式(字尾為 .MOV): 美國Apple公司開發的一種視訊格式,預設的播放器是蘋果的QuickTime。 具有較高的壓縮比率和較完美的視訊清晰度等特點,並可以儲存alpha通道。
MPEG 格式(檔案字尾可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4等) : 它的英文全稱為 Moving Picture Experts Group,即運動影像專家組格式,該專家組建於1988年,專門負責為 CD 建立視訊和音訊標準,而成員都是為視訊、音訊及系統領域的技術專家。 MPEG 檔案格式是運動影像壓縮演算法的國際標準。MPEG 格式目前有三個壓縮標準,分別是 MPEG-1、MPEG-2、和MPEG-4 。MPEG-1、MPEG-2 目前已經使用較少,著重介紹 MPEG-4,其制定於1998年,MPEG-4 是為了播放流式媒體的高質量視訊而專門設計的,以求使用最少的資料獲得最佳的影像質量。目前 MPEG-4 最有吸引力的地方在於它能夠儲存接近於DVD畫質的小體積視訊檔案。
WMV 格式(字尾為.WMV .ASF): 它的英文全稱為Windows Media Video,也是微軟推出的一種採用獨立編碼方式並且可以直接在網上實時觀看視訊節目的檔案壓縮格式。 WMV格式的主要優點包括:本地或網路回放,豐富的流間關係以及擴充套件性等。WMV 格式需要在網站上播放,需要安裝 Windows Media Player( 簡稱 WMP ),很不方便,現在已經幾乎沒有網站採用了。
Real Video 格式(字尾為 .RM .RMVB): Real Networks 公司所制定的音訊視訊壓縮規範稱為Real Media。 使用者可以使用 RealPlayer 根據不同的網路傳輸速率制定出不同的壓縮比率,從而實現在低速率的網路上進行影像資料實時傳送和播放。RMVB 格式:這是一種由RM視訊格式升級延伸出的新視訊格式,當然效能上有很大的提升。RMVB 視訊也是有著較明顯的優勢,一部大小為700MB左右的 DVD 影片,如果將其轉錄成同樣品質的 RMVB 格式,其個頭最多也就 400MB 左右。大家可能注意到了,以前在網路上下載電影和視訊的時候,經常接觸到 RMVB 格式,但是隨著時代的發展這種格式被越來越多的更優秀的格式替代,著名的人人影視字幕組在2013年已經宣佈不再壓制 RMVB 格式視訊。
Flash Video 格式(字尾為 .FLV):由 Adobe Flash 延伸出來的的一種流行網路視訊封裝格式。隨著視訊網站的豐富,這個格式已經非常普及。
Matroska 格式(字尾為 .MKV):是一種新的多媒體封裝格式,這個封裝格式可把多種不同編碼的視訊及16條或以上不同格式的音訊和語言不同的字幕封裝到一個 Matroska Media 檔內。它也是其中一種開放原始碼的多媒體封裝格式。Matroska 同時還可以提供非常好的互動功能,而且比 MPEG 的方便、強大。
MPEG2-TS 格式 (字尾為 .ts)(Transport Stream“傳輸流”;又稱MTS、TS)是一種傳輸和儲存包含音效、視訊與通訊協議各種資料的標準格式,用於數字電視廣播系統,如DVB、ATSC、IPTV等等。 MPEG2-TS 定義於 MPEG-2 第一部分,系統(即原來之ISO/IEC標準13818-1或ITU-T Rec. H.222.0)。 Media Player Classic、VLC 多媒體播放器等軟體可以直接播放MPEG-TS檔案。
目前,我們在流媒體傳輸,尤其是直播中主要採用的就是 FLV 和 MPEG2-TS 格式,分別用於 RTMP/HTTP-FLV 和 HLS 協議。
下一期我們將系統講解視訊直播的推流和傳輸,敬請期待~
相關文章
- 「視訊直播技術詳解」系列之四:推流和傳輸
- 「視訊直播技術詳解」系列之五:延遲優化優化
- 「視訊直播技術詳解」系列之七:直播雲 SDK 效能測試模型模型
- 視訊直播技術詳解之採集
- 【經驗分享】RTC 技術系列之視訊編解碼
- 視訊技術詳解:RTMP H5 直播流技術解析H5
- 短視訊技術詳解:Android端的短視訊開發技術Android
- Android視訊編碼和直播推流教程Android
- 各種音視訊編解碼學習詳解
- Protocol Buffer技術詳解(資料編碼)Protocol
- IJKPlayer視訊直播-編譯和使用編譯
- 基於webRTC技術 音訊和視訊,IM解Web音訊
- 視訊直播技術之iOS端推流iOS
- 一、視音訊編解碼技術零基礎(理論總結)音訊
- 擁抱智慧,AI 視訊編碼技術的新探索AI
- RxJS 系列之三 - Operators 詳解JS
- Camera開發系列之四-使用MediaMuxer封裝編碼後的音視訊到mp4容器UX封裝
- 【HEVC學習與研究】9.HEVC視訊編碼技術
- 小程式音視訊能力技術負責人解讀“小程式直播”
- 視訊直播技術:最大限度保障流暢性和清晰度
- 詳解音視訊直播中的低延時
- 詳解愛奇藝ZoomAI視訊增強技術的應用OOMAI
- 短視訊平臺原始碼,取驗證碼 封裝全部封裝好直接呼叫原始碼封裝
- 音訊編碼基礎詳解音訊
- Tomcat系列之Java技術詳解TomcatJava
- iOS - 直播系列一:視訊採集iOS
- Android 音視訊 - MediaCodec 編解碼音視訊Android
- 短視訊 SDK 6大功能技術實現方式詳解
- 【編碼】封裝RedisPubSub工具封裝Redis
- 編解碼再進化:Ali266 與下一代視訊技術
- 關於視訊的編解碼與傳輸技術,你想知道的都在這裡
- 如何選擇糾刪碼編碼引擎 | 糾刪碼技術詳解(上)
- 手遊錄屏直播技術詳解 | 直播 SDK 效能優化實踐優化
- 聲網視訊通話,視訊直播小程式 SDK 初體驗 | 掘金技術徵文
- 聲網:直播和視訊聊天背後的硬核技術公司Agora要上市了Go
- 音影片編解碼技術在直播平臺中是如何運用的?
- 讓Chrome看不了WWDC直播的HLS技術詳解Chrome
- 線上視訊網站加密技術詳解網站加密