.環境準備

需要在執行路徑下，準備一個xxx.yuv的文件。然后在qt的命令行這里，輸入如下:

點擊運行，編碼出h264文件。看出來這個壓縮比達到1:87，效果還是不錯的。

下面是一些發幀的時間，編碼時間等信息。

發了很多次數據，才開始編碼成正真的數據packet。

當文件讀取完時，必須要去沖刷編碼器，把更多的緩存packet取出來。

2.FFmpeg編碼視頻流程

從本地讀取YUV數據編碼為h264格式的數據，然后再存?到本地，編碼后的數據有帶startcode。

與FFmpeg ?頻編碼的流程基本?致。

主要API說明：

(1)avcodec_find_encoder_by_name：根據指定的編碼器名稱查找注冊的編碼器。

(2)avcodec_alloc_context3：為AVCodecContext分配內存。

(3)avcodec_open2：打開編解碼器。

(4)avcodec_send_frame：將AVFrame?壓縮數據給編碼器。

(5)avcodec_receive_packet：獲取到編碼后的AVPacket數據。

(6)av_frame_get_buffer: 為?頻或視頻數據分配新的buffer。在調?這個函數之前，必須在AVFame上設置好以下屬性：format(視頻為像素格式，?頻為樣本格式)、nb_samples(樣本個數，針對?頻)、channel_layout(通道類型，針對?頻)、width/height(寬?，針對視頻）。因為這個Buf是根據這些參數來計算。

(7)av_frame_make_writable：確保AVFrame是可寫的，盡可能避免數據的復制。如果AVFrame不是可寫的，將分配新的buffer和復制數據，避免數據沖突。

(8)av_image_fill_arrays:存儲?幀像素數據存儲到AVFrame對應的data buffer。

(9)av_image_get_buffer_size，通過指定像素格式、圖像寬、圖像?來計算所需的內存??。

int av_image_get_buffer_size(enum AVPixelFormat pix_fmt, int width, int height, int align)

重點說明?個參數align:

此參數是設定內存對?的對?數，也就是按多?的字節進?內存對?。

?如設置為1，表示按1字節對?，那么得到的結果就是與實際的內存???樣。

再?如設置為4，表示按4字節對?。也就是內存的起始地址必須是4的整倍數。

(9)av_image_alloc

av_image_alloc()是這樣定義的。此函數的功能是按照指定的寬、?、像素格式來分配圖像內存。

int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt,

int align);

pointers[4]：保存圖像通道的地址。如果是RGB，則前三個指針分別指向R,G,B的內存地址。第四個指針保留不?。

linesizes[4]：保存圖像每個通道的內存對?的步?，即??的對?內存的寬度，此值??等于圖像寬度。

w: 要申請內存的圖像寬度。

h: 要申請內存的圖像?度。

pix_fmt: 要申請內存的圖像的像素格式。

align: ?于內存對?的值。

返回值：所申請的內存空間的總??。如果是負值，表示申請失敗。

(10)av_image_fill_arrays

int av_image_fill_arrays(uint8_t *dst_data[4], int dst_linesize[4], const uint8_t *src, enum

AVPixelFormat pix_fmt, int width, int height, int align);

av_image_fill_arrays()

函數?身不具備內存申請的功能，此函數類似于格式化已經申請的內存，即通過av_malloc()函數申請的內存空間，或者av_frame_get_buffer()函數申請的內存空間。

dst_data[4]： [out]對申請的內存格式化為三個通道后，分別保存其地址。

dst_linesize[4]: [out]格式化的內存的步?（即內存對?后的寬度)。

*src: [in]av_alloc()函數申請的內存地址。

pix_fmt: [in] 申請 src內存時的像素格式

width: [in]申請src內存時指定的寬度

height: [in]申請scr內存時指定的?度

align: [in]申請src內存時指定的對?字節數。

H.264 碼率設置

一般在實際的直播項目中，如果為了匹配不同分辨率，一般都是設置動態緩沖區適配，這樣可以把不同分辨率，不同碼率的延遲降到最低。這就是一個實戰中得出的優化經驗。

什么是視頻碼率？

視頻碼率是視頻數據（包含視頻?彩量、亮度量、像素量）每秒輸出的位數。?般?的單位是kbps。

設置視頻碼率的必要性

在?絡視頻應?中，視頻質量和?絡帶寬占?是相?盾的。通常情況下，視頻流占?的帶寬越?則視頻質量也越?，需要的?絡帶寬也越?，解決這??盾的鑰匙當然是視頻編解碼技術。評判?種視頻編解碼技術的優劣，是?較在相同的帶寬條件下，哪個視頻質量更好；在相同的視頻質量條件下，哪個占?的?絡帶寬更少（?件體積?）。

是不是視頻碼率越?，質量越好呢？

理論上是這樣的。然?在我們?眼分辨的范圍內，當碼率?到?定程度時，就沒有什么差別了。所以碼率設置有它的最優值，H.264（也叫AVC或X264）的?件中，視頻的建議碼率如下：

?機設置碼率建議

通過上?的介紹，結合我做過的?些?機項?，我總結了?套設置碼率的公式，分享給?家如下：

如果1080P，碼率低于2M，實際效果很差。不建議這么做，那樣沒什么意義。

FFmpeg與H264編碼指南

鑒于x264的參數眾多，各種參數的配合復雜，為了使?者?便，x264建議如?特別需要可使?preset和tune設置。這套開發者推薦的參數較為合理，可在此基礎上在調整?些具體參數以符合??需要，?動設定的參數會覆蓋preset和tune?的參數。

使?ffmpeg -h encoder=libx264 命令查詢相關?持的參數。

英?地址：https://trac.ffmpeg.org/wiki/Encode/H.264。內容有?定出?，但是可以借鑒學習。

x264是?個 H.264/MPEG4 AVC 編碼器，本指南將指導新?如何創建?質量的H.264視頻。

對于普通?戶通常有兩種碼率控制模式：CRF（Constant Rate Factor)和Two pass ABR。碼率控制是?種決定為每?個視頻幀分配多少?特數的?法，它將決定?件的??和質量的分配。

如果你在編譯和安裝libx264 ??需要幫助，請查看ffmpeg和x264編譯指南：

http://ffmpeg.org/trac/ffmpeg/wiki/CompilationGuide

CRF

量化?例的范圍為0~51，其中0為?損模式，23為缺省值，51可能是最差的。該數字越?，圖像質量越好。從主觀上講，18~28是?個合理的范圍。18往往被認為從視覺上看是?損的，它的輸出視頻質量和輸?視頻?模?樣或者說相差??。但從技術的?度來講，它依然是有損壓縮。

若CRF值加6，輸出碼率?概減少?半；若CRF值減6，輸出碼率翻倍。通常是在保證可接受視頻質量的前提下選擇?個最?的CRF值，如果輸出視頻質量很好，那就嘗試?個更?的值，如果看起來很糟，那就嘗試?個??點值。

注意：本?所提到的量化?例只適?于8-bit x264（10-bit x264的量化?例 為0~63），你可以使?x264--help命令在Output bit depth選項查看輸出位深，在各種版本中，8bit是最常?的。

preset

預設是?系列參數的集合，這個集合能夠在編碼速度和壓縮率之間做出?個權衡。?個編碼速度稍慢的預設會提供更?的壓縮效率（壓縮效率是以?件??來衡量的)。這就是說，假如你想得到?個指定??的?件或者采?恒定?特率編碼模式，你可以采??個較慢的預設來獲得更好的質量。同樣的，對于恒定質量編碼模式，你可以通過選擇?個較慢的預設輕松地節省?特率。這里后面會根據代碼來設置。

通常的建議是使?最慢的預設。?前所有的預設按照編碼速度降序排列為：

ultrafast

superfast

veryfast

faster

fast

medium – default preset

slow

slower

veryslow

placebo - ignore this as it is not useful (see FAQ)

默認為medium級別。

你可以使?--preset來查看預設列表，也可以通過x264 --fullhelp來查看預設所采?的參數配置。

tune

tune是x264中重要性僅次于preset的選項，它是視覺優化的參數，tune可以理解為視頻偏好（或者視頻類型），tune不是?個單?的參數，?是由?組參數構成-tune來改變參數設置。當前的 tune包括：

film：電影類型，對視頻的質量?常嚴格時使?該選項

animation：動畫?，壓縮的視頻是動畫?時使?該選項

grain：顆粒物很重，該選項適?于顆粒感很重的視頻

stillimage：靜態圖像，該選項主要?于靜?畫??較多的視頻

psnr：提?psnr，該選項編碼出來的視頻psnr?較?

ssim：提?ssim，該選項編碼出來的視頻ssim?較?

fastdecode：快速解碼，該選項有利于快速解碼

zerolatency：零延遲，該選項主要?于視頻直播

如果你不確定使?哪個選項或者說你的輸?與所有的tune皆不匹配，你可以忽略--tune 選項。你可以使?-tune來查看tune列表，也可以通過x264 --fullhelp來查看tune所采?的參數配置。

profile

另外?個可選的參數是-profile:v，它可以將你的輸出限制到?個特定的 H.264 profile。?些?常?的或者要被淘汰的設備僅?持有限的選項，?如只?持baseline或者main。

所有的profile 包括：

baseline profile：基本畫質。?持I/P 幀，只?持?交錯（Progressive）和CAVLC

extended profile：進階畫質。?持I/P/B/SP/SI 幀，只?持?交錯（Progressive）和CAVLC

main profile：主流畫質。提供I/P/B 幀，?持?交錯（Progressive）和交錯（Interlaced），也?持CAVLC 和CABAC 的?持。

high profile：?級畫質。在main Profile 的基礎上增加了8x8內部預測、?定義量化、 ?損視頻編碼和更多的YUV 格式。

想要說明H.264 high profile與H.264 main profile的區別就要講到H.264的技術發展了。JVT于2003年完成H.264基本部分標準制定?作，包含baseline profile、extended profile和main profile，分別包括不同的編碼?具。之后JVT?完成了H.264 FRExt（即：Fidelity Range Extensions）擴展部分（Amendment）的制定?作，包括high profile（HP）、high 10 profile（Hi10P）、high 4:2:2profile（Hi422P）、high 4:4:4 profile（Hi444P）4個profile。

H.264 baseline profile、extended profile和main profile都是針對8位樣本數據、4:2:0格式的視頻序列，FRExt將其擴展到8～12位樣本數據，視頻格式可以為4:2:0、4:2:2、4:4:4，設?了highprofile（HP）、high 10 profile（Hi10P）、high 4:2:2 profile（Hi422P）、high 4:4:4profile（Hi444P） 4個profile，這4個profile都以main profile為基礎

在相同配置情況下，High profile（HP）可以?Main profile（MP）節省10%的碼流量，編碼時間可能更長，?MPEG-2MP節省60%的碼流量，具有更好的編碼性能。根據應?領域的不同：

baseline profile：多應?于實時通信領域

main profile：多應?于流媒體領域

high profile：則多應?于?電和存儲領域

關于profile和level控制，可以參考這篇文章:

https://www.jianshu.com/p/48d723bb2740

低延遲

x264提供了?個 -tune zerolatency 選項。

兼容性

如果你想讓你的視頻最?化的和?標播放設備兼容(?如?版本的的ios或者所有的android 設備），那么你可以這做

-profile:v baseline

這將會關閉很多?級特性，但是它會提供很好的兼容性。也許你可能不需要這些設置，因為?旦你?了這些設置，在同樣的視頻質量下與更?的編碼檔次相?會使?特率稍有增加。

關于profile列表和關于它們的描述，你可以運?x264 --fullhelp

要牢記apple quick time 對于x264編碼的視頻只?持 YUV 420顏?空間，?且不?持任何?于 mian profile編碼檔次。這樣對于quick time 只留下了兩個兼容選項baseline和 main。其他的編碼檔次qucik time均不?持，雖然它們均可以在其它的播放設備上回放。

有些問題，通過解答的形式給出。

兩遍編碼模式能夠?CRF模式提供更好的質量嗎？

不能，但它可以更加精確地控制?標?件??。

為什么 placebo 是?個浪費時間的玩意?？

與 veryslow相?，它以極?的編碼時間為代價換取了?概1%的視頻質量提升，這是?種收益遞減準則，veryslow 與 slower相?提升了3%；slower 與 slow相?提升了5%；slow 與 medium相?提升了5%~10%。

為什么我的?損輸出看起來是?損的？

這是由于rgb->yuv的轉換，如果你轉換到yuv444,它依然是?損的。

顯卡能夠加速x264的編碼嗎？

不，x264沒有使?（?少現在沒有），有?些私有編碼器使?了GPU加快了編碼速度，但這并不意味著它們經過良好的優化。也有可能還不如x264，或許速度更慢。總的來說，ffmpeg到?前為?還不?持GPU。

翻譯注釋：x264在2013版中已經開始?持基于opencl的顯卡加速，?于幀類型的判定。

為Quick time 播放器壓制視頻

你需要使?-pix_fmt yuv420p來是你的輸出?持QT 播放器。這是因為對于H.264視頻剪輯蘋果的Quicktime只?持 YUV420顏?空間。否則ffmpeg會根據你的視頻源輸出與Quick time 不兼容的視頻格式或者不是基于ffmpeg的視頻。

X264參數之zerolatency的分析

加?zerolatency之后，轉碼路數會明顯降低。

我們都知道，加?zerolatency的?的是為了降低在線轉碼的編碼延遲，那么，該參數是如何影響到x264的轉碼性能了呢？

?先，先來看看代碼中編碼延遲的影響因素：

設置zerolatency后，相應的參數配置如下：

下?我們來看?下zerolatency設置中各個參數的意義：

rc_lookahead: Set number of frames to look ahead for frametype and ratecontrol.

該參數為mb-tree碼率控制和vbv-lookahead設置可?的幀數量，最?值為250。對于mbi-tree來說，rc_lookahead值越?，會得到更準確的結果，但編碼速度也會更慢，因為編碼器需要緩存慢rc_lookahead幀數據后，才會開始第?幀編碼，增加編碼延時，因此在實時視頻通信中將其設置為0。

sync_lookahead: 設置?于線程預測的幀緩存??，最?值為250。在第?遍及更多遍編碼或基于分?線程時?動關閉。sync_lookahead = 0為關閉線程預測，可減?延遲，但也會降低性能。

bframes: I幀和P幀或者兩個P幀之間可?的最?連續B幀數量，默認值為3。B幀可使?雙向預測，從?顯著提?壓縮率，但由于需要緩存更多的幀數以及重排序的原因，會降低編碼速度，增加編碼延遲，因此在實時編碼時也建議將該值設置為0。

sliced_threads: 基于分?的線程，默認值為off，開啟該?法在壓縮率和編碼效率上都略低于默認?法，但沒有編碼延時。除?在編碼實時流或者對低延遲要求較?的場合開啟該?法，?般情況下建議設為off。

vfr_input： 與force-cfr選項相對應：

vfr_input= 1時，為可變幀率，使?timebase和timestamps做碼率控制；vfr_input = 0時，為固定幀率，使?fps做碼率控制。

mb_tree: 基于宏塊樹的碼率控制。對于每個MB，向前預測?定數量的幀(該數量由rc_lookahead和keyint中的較?值決定)，計算該MB被引?的次數，根據被引?次數的多少決定為該MB分配的量化QP值。該?法會?成?個臨時stats?件，記錄了每個P幀中每個MB被參考的情況。使?mb_tree的?法能夠節約?概30%的碼率，但同時也會增加編碼延遲，因此實時流編碼時也將其關閉。

詳細可以參考這個:https://slhck.info/video/2017/02/24/crf-guide.html

3.源碼解讀

根據傳參，查找指定編碼器。并分配編碼器上下文。

給編碼器上下文設置相關信息，如，寬高，time_base，B幀個數，gop等。

如果想一直保持I幀進行編碼，就需要設置frame->pict_type設置為AV_PICTURE_TYPE_I, 則忽略gop_size的設置。

這里的time_base與幀率設置為倒數關系即可。一般做直播都是把B幀設置為0，因為b幀會緩存較多，然后會帶來延時。

設置0延遲，畫質效果一般，精細度不夠好。

一般編碼時間與畫質是成一個反比關系，就是說如果使用ultrafast，那畫質可能就差點，使用veryslow，那畫質可能就好點。代碼設置如下:

根據debug結果顯示，ultrafast模式，編碼時間為2270ms，medium模式，編碼時間為5815ms，veryslow模式，編碼時間為19836ms。直播時，一般都設置zerolatency，為0延遲。

從圖中可以看出，當其他參數固定時，選擇不同的preset，對應的碼率和編碼時間都不?樣。

可以使?--preset來查看預設列表，也可以通過x264 --fullhelp來查看預設所采?的參數配置。一般在做直播，可以使用ultrafast、superfast、veryfast，但是就一般不會有特別復雜的算法。

碼率設置，一般需要根據分辨率去配置，也會有一般值，最小值等，當然這跟動態碼率，固定碼率這些有關系。編碼器上下文還可以設置線程數，編碼速度會快，開了多線程后也會導致幀輸出延遲, 需要緩存thread_count幀后再編程，所以直播為了降低延遲，一般是不去開啟多線程。設置AV_CODEC_FLAG_GLOBAL_HEADER，表示只有第一個I幀，具有SPS/PPS信息，此時sps pps需要從codec_ctx->extradata讀取，如果不設置，那就是每個I幀都有sps、pps 、sei。是否設置，根據自己情況去看，一般存儲本地文件時，不要去設置。

如果沒有設置AV_CODEC_FLAG_GLOBAL_HEADER，就可以看到每個I幀都有SPS和PPS，SEI信息。

這個就是SEI信息。

如果設置AV_CODEC_FLAG_GLOBAL_HEADER，存放到本地，PKT里沒有SPS和PPS信息，但是SEI信息。

這時的SPS和PPS信息，是在codec_ctx->extradata，從這里面去獲取。

注意，這個時候，是不會寫到文件里的。

打開輸入和輸出文件。

分配PKT和frame

根據設置的參數，給frame分配buffer。

按照設置的字節對齊，計算出每一幀的數據 = 像素格式 * 寬 * 高

分配了一個yuv_buf，用來讀取文件，存儲使用。

當緩存B幀時，為了防止外面寫數據與緩存沖突， 如果編碼器內部保持了內存參考計數，則需要重新拷貝一個備份。一般如果是X264編碼，一般是不會沖突，這里是為了起一個保險作用。

再把文件中讀取的數據，存到 yuv_buf，然后再去填充到frame里去。這里也有字節對齊設置。

這里就開始設置pts，獲取開始時間。一般pts還是要根據duration去計算比較好，如果實時流，直接從采集端拿到，然后配置下去。

編碼視頻。通過查閱代碼，使用x264進行編碼時，具體緩存幀是在x264源碼進行，不會增加avframe對應buffer的reference。一般能夠播放的h264是帶有startcode，但是從flv里抽出的h264前，是要添加startcode才行。

注意：編碼時，不管是編碼還是解碼，如果有B幀，都是要相互參考，可能輸入多幾幀進去，才會編碼出來一幀。

本篇文章就分析到這里，歡迎關注，點贊，收藏，轉發。如果需要測試代碼，那需要私信。

/ BRIAN DIPERT

原文鏈接 / https://blog.addpipe.com/typical-video-bitrates-with-html-media-capture-and-mediastream-recording-api/

最近有人問我們關于視頻碼率與文件大小的問題：對于低、中、高質量的，比如1分鐘的視頻響應，有典型的文件大小嗎？

我的直接回答是這取決于許多因素，但后來我意識到我應該嘗試挖掘數據。在我們的大型數據集中，我們應該找一些典型碼率，特別是在處理大容量數據時的碼率。

我們已經研究了從用戶那里采集視頻的兩種機制以及它們產生的碼率：

1.MediaStream Recording API：由我們的(內聯)桌面錄制客戶端使用

2.HTML Media Capture：由我們的本地移動錄制客戶端使用

MediaStream Recording API

由于此API允許你從你的攝像頭請求分辨率，我們看了3個典型的分辨率應該支持大多數USB/集成網絡攝像頭:

• 320x240
• 640x480
• 1280x720

我們從數據庫中提取了2021年以該分辨率錄制的第一萬個視頻，然后通過瀏覽器(Chrome 和 Firefox)進一步過濾。

對于分辨率為320x240的視頻：

• 使用 Chrome 錄制的5691個視頻的平均碼率為183 kb/s。
• 使用 Firefox 錄制的超過374個視頻的平均碼率為2 Mb/s。

我懷疑碼率的不同主要是因為Firefox（僅）使用VP8壓縮視頻數據，而Chrome使用的是H.264。

此外，我們沒有所有視頻的用戶代理信息，這就是為什么視頻的數量加起來沒有達到一萬。

對于分辨率為640x480的視頻：

• 使用 Chrome 錄制的超過7501個視頻的平均碼率為589 kb/s。
• 使用 Firefox 錄制的超過181個視頻的平均碼率為2.64 Mb/s。

對于分辨率為1280x720的視頻：

• 使用 Chrome 錄制的超過6956個視頻的平均碼率為1.97 Mb/s。
• 使用Firefox 錄制的超過1265個視頻的平均碼率為2.69 Mb/s。

有了高清錄制，可以對攝像機質量和光線設置帶來的差異留有余地（低光照環境產生的噪聲圖像很難有效編碼）

你會看到兩條平行的鉻線在2Mbits/s標記附近。上面的是Windows上的Chrome，而下面的是macOS上的Chrome。我可能是錯的，但我懷疑他們使用的是不同的H.264編碼器。如果不是這樣的話，那就是每個macOS設備上都有FaceTime攝像頭。

下圖是按操作系統劃分的Chrome數據。

HTML Media Capture

這個API允許依靠操作系統的應用和功能來采集音頻和視頻。它適用于Android和iOS/iPadOS（但不能只用于音頻錄制）。

使用HTML Media Capture不能控制或指定分辨率，但是從以往經驗來看，我們知道:

• 在iOS和iPadOS上，當你在現場錄制時，你可以得到480x360（和它的縱向變化）或當從庫中選擇一個記錄，可以得到1280x720（和它的縱向變化）。
• 在Android上，你可以獲取設備配置的任何記錄(不像在iOS/iPad OS上那樣進行強制壓縮)。

iOS & iPadOS

所以你可以看出：

1.當現場抓拍視頻的時，894kbits/s(和480x360分辨率)

2.當選擇庫中一個預先錄制的視頻時，2.69 Mbits/s(和1280x720)

3.平均1.8 Mbits/s

我們還查看了通過HTML Media Capture從iOS/iPadOS獲得的分辨率不同于480x360、1280x720及其縱向變體的視頻數量。在一萬個視頻中，只有548個有不同的分辨率。

Android

使用Android上的HTML Media Capture，你可以獲得設備上配置的任何內容。因此，我們看到了相當多的4k視頻。因為你不能要求一個特定的分辨率，我們只計算了所有10k視頻的平均分辨率為12.9 Mbits/s。

這是相同的數據，但按碼率排序，可以更好地看到在20 Mbits/s標記附近的分組。

這些數字與來自瀏覽器的數據非常相關。在處理這些文件并對其中一些數據進行轉碼之后，數字可能會有所不同。例如，我們將VP8視頻數據從Firefox轉換為H.264，將Opus音頻數據轉換為AAC。

節跳動視頻編碼器，在MSU 2020賽事中，又獲得了新的好成績。

MSU 2020是俄羅斯莫斯科國立大學舉辦的視頻編碼權威賽事，在近期公布的4K和全高清視頻（1080p）主觀評分兩個項目的角逐中，字節跳動自主研發的視頻編碼器（BVC）獲得了兩大最新成績：

• BVC1，斬獲了4K 8bit項目8項評分標準第一名。
• BVC2，獲評全高清視頻（1080p）主觀評分離線1 fps賽道最佳質量獎，主觀評分及4項客觀評分均為第一名。

加上此前2020年12月公布的全高清視頻（1080p）客觀評分項目1fps賽道的4項評分標準冠軍，BVC系列編碼器在首次參賽、僅用了40天優化的情況下，與視頻領域領先公司同場競技，已經獲得了本屆MSU 2020三個主要比賽項目、累計17項評分標準的第一名。

BVC系列編碼器的主要研發團隊是位于美國San Diego的字節跳動先進視頻團隊，團隊成員畢業于加州大學圣芭芭拉分校、伊利諾伊大學香檳分校等知名學府，全部擁有碩士或博士學歷，已經在國際頂級期刊/會議上發表了超過30篇論文，并獲得全球近100項授權專利。

這支海外團隊的不少成員還在多個國際標準化工作組中擔任重要角色，如VVC、H.265/HEVC、H.264/AVC等多項標準文本主編及編委等。過去兩年間，字節跳動先進視頻團隊累計遞交了260項以上H.266/VVC技術提案，被采納數量超過130項。

隨著5G和高清視頻場景的深入落地，BVC系列編碼器證明自己可以滿足高清晰度場景下的視頻編碼需求，能夠作為推進5G媒體應用的基礎架構產品。

以體現客觀質量的VMAF指標為例，BVC編碼器在VMAF指標上相比其他參賽編碼器領先幅度約為8%-15%。這意味著，同樣質量的視頻內容，使用BVC編碼器能為服務商節約8%-15%的帶寬和存儲成本，用戶端在網速較慢的情況下，使用BVC編碼器轉碼，也能享受更高畫質、更流暢的視頻體驗。

此外，參賽的BVC系列編碼器正在逐步針對企業側用戶集成輸出，服務B端市場的高清視頻編解碼需求。

4K 8bit冠軍

先來看BVC1。

在1fps和30fps的各自四項評分標準中，BVC1均取得了最佳成績：

PSNR avg.MSE（峰值信噪比的一種計算方式），1fps

柱狀圖越短，意味著編碼后文件體積越小、比賽成績越好、用戶使用更省流量

PSNR avg.log（峰值信噪比的另一種計算方式），1fps

SSIM（結構相似性），1fps

VMAF（視頻多方法評價融合指標），1fps

PSNR avg.MSE，30fps

PSNR avg.log，30fps

SSIM，30fps

VMAF，30fps

離線1 fps最佳質量獎

另外，在1080p視頻主觀評判中，也就是從人類評委觀看視頻的主觀感受評判中，字節跳動自研編碼器BVC2獲評離線（1 fps）賽道最佳質量獎。

而在1080p視頻相關的四項客觀標準評分中，BVC2同樣保持了第一名的成績。

PSNR avg.MSE

PSNR avg.log

SSIM

VMAF

首次參加比賽，多個項目冠軍

除了本次公布的兩個比賽項目之外，在2020年底公布的MSU 2020 全高清視頻（1080p）客觀評分項目中，BVC2同樣獲得了4項評分標準第一。

研發BVC系列編碼器的字節跳動先進視頻團隊透露，這一系列編碼器正在持續更新迭代，并推動商業化應用，滿足企業級市場的高清視頻編解碼需求。

參考鏈接：

https://www.compression.ru/video/codec_comparison/hevc_2020/4k_report.html

https://www.compression.ru/video/codec_comparison/hevc_2020/subjective_report.html

https://www.compression.ru/video/codec_comparison/hevc_2020/main_report.html

關注「字節跳動技術范兒」

了解字節跳動更多技術成果

抖音40億播放，娜扎、唐嫣都在玩的春節道具，背后是怎樣的技術