文 / Jeff Gong, Sahil Dhanju, Chih-Chiang Lu, Yueshi Shen

編者按：超過220萬創(chuàng)作者在Twitch發(fā)布海量的視頻，這對(duì)實(shí)時(shí)轉(zhuǎn)碼業(yè)務(wù)造成了巨大壓力，Twitch團(tuán)隊(duì)通過優(yōu)化多線程的轉(zhuǎn)碼服務(wù)以及Intel QuickSync的支持，實(shí)現(xiàn)了比FFmepg性能提升65%，并降低80%總體擁有成本。Twitch團(tuán)隊(duì)通過博客介紹了這一實(shí)現(xiàn)，LiveVideoStack對(duì)本文進(jìn)行了摘譯，點(diǎn)擊『閱讀原文』訪問英文博客。同時(shí)，Yueshi Shen將在12月8-9日的ArchSummit 2017北京大會(huì)上詳細(xì)介紹實(shí)現(xiàn)過程。

FFmpeg的1-in-N-out流水線。為什么它無法處理前面討論的技術(shù)問題？

FFmpeg如何以編程方式處理需要單個(gè)輸入來生成多個(gè)轉(zhuǎn)碼和（或）轉(zhuǎn)封裝輸出的實(shí)例？ 我們可以通過直接剖析FFmpeg最新3.3版的源代碼，來了解其線程模型和轉(zhuǎn)碼流水線。

在頂層ffmpeg.c文件中，transcode()函數(shù)（第4544行）不斷循環(huán)并重復(fù)調(diào)用transcode_step()函數(shù)（第4478行），直到其輸入信息被完全處理，或用戶中斷執(zhí)行為止。Transcode_step()函數(shù)封裝了主要的流水線，并在許多其他即時(shí)步驟之間編排諸如文件I / O、過濾、解碼和編碼等動(dòng)作。

在初始設(shè)置階段，init_input_threads()（第4020行）函數(shù)被調(diào)用，并將根據(jù)輸入文件的數(shù)量，產(chǎn)生一些新的線程來處理這些輸入。

if (nb_input_files == 1) {
?return 0;
}
for (i = 0; i < nb_input_files; i++) {
?...
?ret = av_thread_message_queue_alloc(&f->in_thread_queue, f->thread_queue_size, sizeof(AVPacket)); ? ?// line 4033
}

在第4033行中（如上所示），我們看到產(chǎn)生的線程數(shù)量完全由輸入的數(shù)量決定。也就是說，這意味著FFmpeg將只使用一個(gè)線程來處理1-in-N-out的場(chǎng)景。

在get_input_packet（）函數(shù)（第4055行）中，只有當(dāng)輸入文件的數(shù)量大于1時(shí)，才會(huì)調(diào)用多線程伴隨函數(shù)get_input_packet_mt（）（第4047行）。get_input_packet_mt（）函數(shù)可以以非阻塞的方式從消息隊(duì)列中讀取輸入幀。否則的話，我們需要使用av_read_frame（）（第4072行）來每次讀取并處理一個(gè)幀。

#if HAVE_PTHREADS
?if (nb_input_files > 1) {
? ? get_input_packet_mt(f, pkt);
?}
#endif
?return av_read_frame(f->ctx, pkt);

如果我們跟蹤幀數(shù)據(jù)一直到流水線結(jié)束，我們發(fā)現(xiàn)它進(jìn)入到process_input_packet（）函數(shù)（行2591）中，該函數(shù)對(duì)幀數(shù)據(jù)進(jìn)行解碼并通過所有適用的過濾器進(jìn)行處理。時(shí)間戳校準(zhǔn)和字幕處理的工作也在這個(gè)函數(shù)中進(jìn)行。最后，在函數(shù)返回之前，已解碼的幀被復(fù)制到每個(gè)相關(guān)的輸出流。

for (i = 0; pkt && i < nb_output_streams; i++) {
?... ?// check constraints
?do_streamcopy(ist, ost, pkt); ? ?// line 2756
}

最后，transcode_step（）函數(shù)調(diào)用reap_filters（）函數(shù)（第1424行）來循環(huán)遍歷每個(gè)輸出流。reap_filters（）函數(shù)的for循環(huán)負(fù)責(zé)收集緩沖區(qū)中待處理的幀，并將這些幀進(jìn)行解碼，然后封裝到一個(gè)輸出文件中。

// reap_filters line 1423
for (i = 0; i < nb_output_streams; i++) { // loop through all output streams
?... ?// initialize contexts and files
?OutputStream *ost = output_streams[i];
?AVFilterContext *filter = ost->filter->filter;
?AVFrame filtered_frame = ost->filtered_frame;
?while (1) { // process the video/audio frame for one output stream
? ? ... ?// frame is not already complete
? ? ret = av_buffersink_get_frame_flags(filter, filtered_frame, …);
? ? if (ret < 0) {
? ? ? ?... ?// handle errors and logs
? ? ? ?break;
? ? }
? ? switch (av_buffersink_get_type(filter)) {
? ? case AVMEDIA_TYPE_VIDEO:
? ? ? ?do_video_out(of, ost, filtered_frame, float_pts);
? ? case AVMEDIA_TYPE_AUDIO:
? ? ? ?do_audio_out(of, ost, filtered_frame);
? ? }
? ? ...
}

通過跟蹤這條流水線，我們知道這些幀是如何通過單個(gè)線程的上下文順序進(jìn)行處理的，從中我們能看到一些冗余。我們可以得出結(jié)論，既然1-in-N-out的轉(zhuǎn)碼流模型對(duì)我們來說是最有價(jià)值的，那么FFmpeg僅使用單線程來輸出結(jié)果則可能并不理想。FFmpeg文檔也建議我們?cè)趯?shí)際用例中，并行地啟動(dòng)多個(gè)FFmpeg實(shí)例或?qū)⒏幸饬x。在這里，我們關(guān)鍵的一點(diǎn)認(rèn)識(shí)是，既然此工具（FFmpeg）沒有提供多線程功能，它就無法滿足Twitch流媒體服務(wù)的嚴(yán)格需求，那么我們就無法隨心所欲地使用它。

基準(zhǔn)測(cè)試

TwitchTranscoder是我們?yōu)榻鉀Q前面討論的技術(shù)問題而開發(fā)的內(nèi)部軟件。它已被廣泛運(yùn)用于我們的生產(chǎn)中，每天24小時(shí)地處理數(shù)萬個(gè)并發(fā)直播流。

為了確定TwitchTranscoder每天在轉(zhuǎn)碼任務(wù)上的表現(xiàn)是否會(huì)優(yōu)于FFmpeg，我們進(jìn)行了一系列基本的基準(zhǔn)測(cè)試。在我們的測(cè)試中，我們對(duì)兩個(gè)工具使用相同的Twitch直播流以及有相同預(yù)設(shè)、配置文件、比特率和其他標(biāo)志的1080p60視頻文件。每個(gè)視頻源都被轉(zhuǎn)碼成我們通常使用的典型的720p60,720p30,480p30,360p30和160p30。

我們的假設(shè)是，FFmpeg對(duì)于輸入文件的轉(zhuǎn)碼速度比TwitchTranscoder要慢，甚至可能無法跟上直播的速度。

圖9,10和11中的結(jié)果比較了TwitchTranscoder與FFmpeg的執(zhí)行時(shí)間。實(shí)驗(yàn)表明，即使在我們處理相同及更多（除了上面指定的棧之外，還提供僅音頻轉(zhuǎn)碼，縮略圖生成等等）任務(wù)的情況下，我們的轉(zhuǎn)碼器對(duì)于離線轉(zhuǎn)碼一直有絕對(duì)優(yōu)勢(shì)。

對(duì)于輸出單個(gè)版本的720p60，FFmpeg稍快，這是因?yàn)門witchTranscoder要處理如上所述的更多任務(wù)。當(dāng)版本的數(shù)量增加時(shí)，TwitchTranscoder的多線程模型表現(xiàn)出更大的優(yōu)勢(shì)，這些優(yōu)勢(shì)幫助它超越了FFmpeg。觀察Twitch完整的ABR梯度，與FFmpeg相比，TwitchTranscoder節(jié)省了65％的執(zhí)行時(shí)間。

圖9：TwitchTranscoder與FFmpeg轉(zhuǎn)碼時(shí)間比較，實(shí)驗(yàn)1

圖10：TwitchTranscoder與FFmpeg轉(zhuǎn)碼時(shí)間比較，實(shí)驗(yàn)2

圖11：TwitchTranscoder與FFmpeg轉(zhuǎn)碼時(shí)間比較，實(shí)驗(yàn)2

我們通過比較在出問題前，一臺(tái)機(jī)器上最多能夠運(yùn)行多少個(gè)FFmpeg的并行實(shí)例來進(jìn)行實(shí)時(shí)流轉(zhuǎn)碼測(cè)試。這里可能發(fā)生的問題包括幀丟失、視頻偽影等。在我們的生產(chǎn)服務(wù)器中，我們能夠支持多個(gè)通道同時(shí)進(jìn)行轉(zhuǎn)碼，同時(shí)，更多的通道被轉(zhuǎn)封裝。不幸的是，運(yùn)行多個(gè)FFmpeg實(shí)例會(huì)導(dǎo)致一系列影響轉(zhuǎn)碼輸出的錯(cuò)誤，并且需要更高的CPU利用率（請(qǐng)參見圖12中的屏幕截圖）。

圖12：FFmpeg運(yùn)行多個(gè)實(shí)例時(shí)的錯(cuò)誤消息

結(jié)論

在本文中，我們將FFmpeg作為實(shí)時(shí)流RTMP- to-HLS的轉(zhuǎn)碼器進(jìn)行了研究，并提供了有關(guān)如何操作該工具的信息。該解決方案部署起來很簡(jiǎn)單，但有一些技術(shù)問題值得注意，比如段錯(cuò)位、不必要的性能損失，以及缺乏支持我們產(chǎn)品功能的靈活性等。因此，我們實(shí)現(xiàn)了自己內(nèi)部的轉(zhuǎn)碼器軟件棧TwitchTranscoder，它運(yùn)行在一個(gè)定制的線程模型中，并可以在一個(gè)進(jìn)程中輸出N個(gè)處理版本。

LiveVideoStack招募全職技術(shù)編輯和社區(qū)編輯

LiveVideoStack是專注在音視頻、多媒體開發(fā)的技術(shù)社區(qū)，通過傳播最新技術(shù)探索與應(yīng)用實(shí)踐，幫助技術(shù)人員成長(zhǎng)，解決企業(yè)應(yīng)用場(chǎng)景中的技術(shù)難題。如果你有意為音視頻、多媒體開發(fā)領(lǐng)域發(fā)展做出貢獻(xiàn)，歡迎成為L(zhǎng)iveVideoStack社區(qū)編輯的一員。你可以翻譯、投稿、采訪、提供內(nèi)容線索等。

通過contribute@livevideostack.com聯(lián)系，或在LiveVideoStack公眾號(hào)回復(fù)『技術(shù)編輯』或『社區(qū)編輯』了解詳情。

總結(jié)

以上是生活随笔為你收集整理的Twitch如何实现转码比FFmpeg性能提升65%？（下）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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