國內(nèi)應(yīng)用比較多的開源流媒體服務(wù)器nginx-rtmp-module一直存在功能少、集群化難度大等問題。在LiveVideoStack線上分享中，PingOS 開源項(xiàng)目組開發(fā)工程師、UCloud RTC研發(fā)工程師朱建平詳細(xì)介紹了基于nginx-rtmp-module的PingOS流媒體服務(wù)器在http-flv、http-ts、hls+、多進(jìn)程、轉(zhuǎn)推、回源以及集群化部署方面的技術(shù)實(shí)現(xiàn)細(xì)節(jié)。

文 / 朱建平

整理 / LiveVideoStack

直播回放https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=006643cdea15499d96f19ab676924e88

1. Nginx流媒體擴(kuò)展：http-flv、http-ts、hls+

最初始的nginx-rtmp-module相關(guān)模型與包括SRS在內(nèi)的多數(shù)流媒體服務(wù)器實(shí)際上是一樣的（1個(gè)生產(chǎn)者，n個(gè)消費(fèi)者）。Nginx存一個(gè)問題：它僅僅做了RTMP的消費(fèi)模型，如果想擴(kuò)展 http-flv或http-ts的形式會(huì)較為困難。由于rtmp-session僅供RTMP協(xié)議使用，如果想擴(kuò)展http-flv，首先我們需要了解其基礎(chǔ)分發(fā)模型（如上圖所示）：所有的生產(chǎn)者與消費(fèi)者都會(huì)被掛載到同一個(gè)stream中，生產(chǎn)者負(fù)責(zé)從網(wǎng)絡(luò)端接收數(shù)據(jù)，消費(fèi)者從buffer中獲取數(shù)據(jù)對(duì)外發(fā)送。

如果是發(fā)送flv數(shù)據(jù)，那么可以保留原有rtmp-session，當(dāng)服務(wù)器收到一個(gè)HTTP請(qǐng)求時(shí)，創(chuàng)建一個(gè)rtmp-session，此session與網(wǎng)絡(luò)不相關(guān)，僅僅是邏輯上的session。然后將這個(gè)session注入stream當(dāng)中，如果是以消費(fèi)者的角色注入進(jìn)stream當(dāng)中，則可以實(shí)現(xiàn)獲取數(shù)據(jù)并往外分發(fā)。假如此時(shí)服務(wù)器收到的是http-flv的請(qǐng)求，就可以創(chuàng)建一個(gè)邏輯上的session，并把它注入stream中，此時(shí)理論上我們可以獲得的是rtmp的數(shù)據(jù)。但我們需要的是flv的數(shù)據(jù)，由于flv數(shù)據(jù)與rtmp數(shù)據(jù)相似，我們可以通過tag-header的方式非常簡單的將rtmp數(shù)據(jù)還原成flv數(shù)據(jù)。根據(jù)上述思路，在生產(chǎn)者和消費(fèi)者模型中，消費(fèi)者可以通過創(chuàng)建http-fake-session的形式來復(fù)用以前的分發(fā)流程并實(shí)現(xiàn)http-flv協(xié)議。我們對(duì)其進(jìn)行擴(kuò)展，創(chuàng)建一個(gè)http-fake-session作為生產(chǎn)者，并讓http-fake-session與一個(gè)http client進(jìn)行關(guān)聯(lián)，關(guān)聯(lián)之后http client負(fù)責(zé)從遠(yuǎn)程服務(wù)器端下載數(shù)據(jù)傳遞給生產(chǎn)者，生產(chǎn)者就可以把這些數(shù)據(jù)通過分發(fā)模型分發(fā)給下面的rtmp-session。這樣也就間接實(shí)現(xiàn)了一個(gè)http回源的功能。通過上述思路我們就能夠快速地實(shí)現(xiàn)http-flv的播放與拉流。同樣，我們可以根據(jù)上述思路繼續(xù)擴(kuò)展協(xié)議。假如我們?cè)谑盏揭粋€(gè)http請(qǐng)求之后，創(chuàng)建一個(gè)同樣的rtmp-fake-session（邏輯上的session，與網(wǎng)絡(luò)不相關(guān)），我們把它以消費(fèi)者的角色插入到 stream當(dāng)中。這樣就可以從stream當(dāng)中獲取到需要向下分發(fā)的數(shù)據(jù)。需要注意的是：stream中最初保存的是rtmp數(shù)據(jù)而不是ts數(shù)據(jù)，無法直接獲取ts數(shù)據(jù)。

1.1 http-flv在Nginx中的實(shí)現(xiàn)

基于Nginx實(shí)現(xiàn)http-flv需要注意以下幾點(diǎn)細(xì)節(jié)：首先該實(shí)現(xiàn)復(fù)用了Nginx的分發(fā)模型以及http功能模塊。（Nginx對(duì)http協(xié)議棧的支持更加完善，包括http1.0、http1.1協(xié)議）在部分線上業(yè)務(wù)中，客戶可能需要在下載http-flv時(shí)添加后綴，按照以往的實(shí)踐邏輯我們會(huì)在代碼當(dāng)中過濾后綴。如果遇見更為復(fù)雜，如修改是否需要開啟http chunked編碼的需求，我們就只能修改代碼。而如果是基于Nginx通過復(fù)用http的現(xiàn)有模塊來實(shí)現(xiàn)http-flv，我們就可以通過nginx-http-rewrite功能來實(shí)現(xiàn)這些操作。因此使用nginx-http的原生功能來開發(fā)http-flv可以帶來更多好處，如顯著降低代碼量。

在這里我曾經(jīng)看到過一種情況：即復(fù)用了http模塊，但沒有復(fù)用rtmp的分發(fā)流程。這樣就會(huì)導(dǎo)致我們需要將分發(fā)流程在http-flv中重新再做一遍，對(duì)業(yè)務(wù)的控制就會(huì)變得非常復(fù)雜。

舉個(gè)例子，假如此時(shí)有人請(qǐng)求播放，需要將消息通知給業(yè)務(wù)服務(wù)器。此時(shí)，如果rtmp與http-flv兩種協(xié)議的實(shí)現(xiàn)是分開的，那么意味著如果兩者都被觸發(fā)，就需要分別向業(yè)務(wù)服務(wù)器進(jìn)行匯報(bào)。于是我們就需要付出雙倍的代碼與邏輯維護(hù)工作，這無疑會(huì)顯著增加開發(fā)與維護(hù)成本。因此，最簡單的實(shí)現(xiàn)方案就是flv不做任何與業(yè)務(wù)相關(guān)的處理，僅在下發(fā)的時(shí)候進(jìn)行格式轉(zhuǎn)換，相當(dāng)于rtmp分發(fā)時(shí)只發(fā) rtmp格式的數(shù)據(jù)，而flv分發(fā)時(shí)只需要將rtmp的數(shù)據(jù)打上flv的tag-header，然后再進(jìn)行下發(fā)，這樣就省去了業(yè)務(wù)層的開發(fā)。

http-flv播放實(shí)現(xiàn)

圖中展示的是rtmp的緩存對(duì)于rtmp和http-flv這兩個(gè)協(xié)議的支持。http-flv和rtmp二者共用一套緩存，其實(shí)rtmp本身傳輸?shù)木褪莊lv的數(shù)據(jù)，只不過是把tag-header給拋掉了。

http-flv的下發(fā)與rtmp的下發(fā)唯一的區(qū)別點(diǎn)在于send函數(shù)不同：http-flv調(diào)用的是http的send函數(shù)，rtmp下發(fā)時(shí)調(diào)用的是原生的send函數(shù)，在下發(fā)前需要添加各自的協(xié)議頭。二者共用一塊內(nèi)存可以達(dá)到節(jié)省內(nèi)存的效果，并且實(shí)現(xiàn)業(yè)務(wù)統(tǒng)一，降低開發(fā)成本。

http-flv回源的實(shí)現(xiàn)

圖中展示的是http-flv回源在nginx中的實(shí)現(xiàn)。http-flv回源實(shí)現(xiàn)的思路與http-flv的播放實(shí)現(xiàn)思路類似：即在需要回源的時(shí)候創(chuàng)建一個(gè)http client，http client所做的事情就是把http數(shù)據(jù)下載到本地。在下載數(shù)據(jù)到本地之前http client需要先創(chuàng)建一個(gè)rtmp fake session并將其作為生產(chǎn)者注入stream當(dāng)中。而后http client開始從網(wǎng)絡(luò)上下載數(shù)據(jù)并且將下載到的fIv數(shù)據(jù)拆成rtmp數(shù)據(jù)。為什么要拆成rtmp數(shù)據(jù)？這是因?yàn)閞tmp的推流過來的緩存數(shù)據(jù)類型是rtmp，因此從網(wǎng)上下載到的flv數(shù)據(jù)需要做一次拆分，拆成rtmp的數(shù)據(jù)，然后放入緩存。最終根據(jù)實(shí)際要求將數(shù)據(jù)轉(zhuǎn)成rtmp或flv的格式。這樣按照http-flv播放中rtmp fake session的邏輯，也就能夠快速的實(shí)現(xiàn)http-flv的回源操作。

1.2 http-ts在Nginx中的實(shí)現(xiàn)

圖中展示的是http-ts在Nginx中的實(shí)現(xiàn)。其實(shí)現(xiàn)思想與http-flv的實(shí)現(xiàn)基本一致，僅僅是在操作上有所不同，不同點(diǎn)在于http-ts需要一個(gè)獨(dú)立的buffer進(jìn)行緩存。由于http-ts與http-flv的數(shù)據(jù)格式相差較大，對(duì)于flv數(shù)據(jù)到rtmp來說，只需要將數(shù)據(jù)拆成一個(gè)個(gè)小塊，并在前面添加一個(gè)header。即使flv數(shù)據(jù)的最一幀或者一個(gè)分塊缺少也不用補(bǔ)齊。

但是ts數(shù)據(jù)不同，它的要求比較嚴(yán)格，每一分塊必須為188字節(jié)，其中包括ts header以及有效載荷部分。并且如果數(shù)據(jù)庫大小不足188個(gè)字節(jié)，則需要補(bǔ)齊。而rtmp的數(shù)據(jù)塊沒有嚴(yán)格固定要求其長度大小。對(duì)于ts數(shù)據(jù)來說，要想將flv數(shù)據(jù)轉(zhuǎn)成ts數(shù)據(jù)，這個(gè)過程是需要消耗一些計(jì)算量的。由于ts數(shù)據(jù)和flv的數(shù)據(jù)格式相差太大，因此在這里我們將ts的buffer與rtmp的buffer完全獨(dú)立開。但此操作并不是默認(rèn)開啟的，需要在服務(wù)器中進(jìn)行配置。

開啟配置后，才會(huì)將rtmp的buffer生成一份鏡像的ts數(shù)據(jù)，這一部分的ts數(shù)據(jù)僅會(huì)供http-ts和hls兩個(gè)協(xié)議使用。服務(wù)器中還涉及到一個(gè)原生的hls服務(wù)，在這里我們沒有做任何的改動(dòng)，而是加入了hls+的服務(wù)來使用這個(gè)buffer。無論是ts還是hls+，它們都注冊(cè)了自己的fake session，這樣做的目的是為了統(tǒng)一業(yè)務(wù)。例如在有播放請(qǐng)求進(jìn)入時(shí)，我們需要讓業(yè)務(wù)服務(wù)器知道當(dāng)前有請(qǐng)求產(chǎn)生。

類似這種網(wǎng)絡(luò)通知、事件通知的接口，在開發(fā)的過程中大家都希望只需要編寫一份業(yè)務(wù)數(shù)據(jù)，而不是說做hls協(xié)議要針對(duì)hls播放寫一個(gè)通知，做ts協(xié)議還要針對(duì)ts再寫一份通知，這樣業(yè)務(wù)代碼會(huì)越來越龐大，最后導(dǎo)致服務(wù)幾乎就很難維護(hù)。

因此fakesession的作用是非常大的，其會(huì)把網(wǎng)絡(luò)層與業(yè)務(wù)層完全隔離開。即使服務(wù)器本身的下發(fā)協(xié)議不是rtmp，創(chuàng)建一個(gè)rtmp-session并掛載到業(yè)務(wù)服務(wù)器中即可。總的來說，http-ts與http-flv唯一實(shí)現(xiàn)區(qū)別就是獲取buffer的位置不同。http-flv需要從rtmp buffer獲取，http-ts則是從ts buffer中獲取。如果能理解http-flv的協(xié)議流程，那么也就不難理解http-ts的實(shí)現(xiàn)流程。

1.3 hls+在Nginx中的實(shí)現(xiàn)

圖中展示的是hls+在nginx中的實(shí)現(xiàn)。hls+與傳統(tǒng)hls不同，傳統(tǒng)hls在服務(wù)端沒有狀態(tài)，服務(wù)端包含大量碎數(shù)據(jù)，客戶端在不斷執(zhí)行下載，而hls+則會(huì)記錄每一個(gè)客戶端的狀態(tài)。對(duì)于如何記錄每個(gè)客戶端的狀態(tài)，之前我曾嘗試通過對(duì)hls+的連接創(chuàng)建一個(gè)虛擬連接用來記錄狀態(tài)。但是發(fā)現(xiàn)業(yè)務(wù)會(huì)比較復(fù)雜，并且后期會(huì)存在很多問題，包括代碼量、bug以及維護(hù)成本等。于是更換另外一種思路，還是用fake session的方式來實(shí)現(xiàn)。利用fake session作為消費(fèi)者放入，根據(jù)每次進(jìn)入的http，連接，通過session ID進(jìn)行綁定。

由于第1次發(fā)送hls請(qǐng)求時(shí)客戶端是不知道sessionID的，如果服務(wù)器獲取到一個(gè)沒有session ID的連接，則認(rèn)為此客戶端為第1次進(jìn)入。客戶端會(huì)接收到一個(gè)302的回復(fù)，302回復(fù)中會(huì)告訴客戶端一個(gè)新的地址，其中包含一個(gè)session ID。客戶端得到session ID之后，再次請(qǐng)求m3u8時(shí)，會(huì)加入session ID，服務(wù)器就可獲取相應(yīng)session ID并對(duì)客戶端進(jìn)行身份區(qū)分。這樣就能夠通過session ID記錄每一個(gè)客戶端的播放狀態(tài)。為什么要記錄這個(gè)狀態(tài)？這主要是因?yàn)榉?wù)器不是將數(shù)據(jù)直接寫入硬盤而是放進(jìn)內(nèi)存，它需要知道每一個(gè)用戶、每一個(gè)客戶端的下載進(jìn)度，并根據(jù)不同的進(jìn)度從內(nèi)存中定位ts數(shù)據(jù)。

hls+和http-ts它們共用了一個(gè) ts buffer，并且hls+是實(shí)時(shí)的從buffer中定位ts內(nèi)容。所以對(duì)于hls+來說，并沒有真正的ts數(shù)據(jù)產(chǎn)生，只是記錄每一個(gè)文件在內(nèi)存里面的偏移量。因此hls+不存在讀寫的問題，在做hls服務(wù)時(shí)，以前可能會(huì)遇到過一個(gè)問題——讀寫硬盤的瓶頸。機(jī)械硬盤的讀寫速度比較慢，普遍的解決思路就是掛載一個(gè)虛擬硬盤，將內(nèi)存映射到目錄中進(jìn)行讀寫。

如果采用的是hls+的方案，就可以省去掛載的操作，對(duì)于內(nèi)存也并沒有太多的消耗。而且如果同時(shí)有hls+以及 http-ts的需求，此時(shí)對(duì)于內(nèi)存的利用率是非常高的。

2. 靜態(tài)推拉流

靜態(tài)推拉流主要是為了滿足集群化的需求。如果單臺(tái)服務(wù)器不足以支撐服務(wù)的高并發(fā)量，那么我們就需要考慮服務(wù)器的擴(kuò)展性。除此之外如果用戶分散在全國各地，還需要進(jìn)行服務(wù)器之間的打通。但是如果業(yè)務(wù)沒有那么復(fù)雜就可以選擇使用靜態(tài)推拉流。

靜態(tài)推拉流服務(wù)配置如上圖所示，首先看靜態(tài)拉流：首先存在一個(gè)目標(biāo)源站，如果使用靜態(tài)回源，那么目標(biāo)地址會(huì)被配置在配置文件當(dāng)中，目標(biāo)源站能隨意更改。

圖中展示的是一個(gè)簡單的靜態(tài)拉流模型：如果來自主播的數(shù)據(jù)被推流到源站A，那么我們需要保證服務(wù)器A的地址不會(huì)改變。

除此之外，如果想要構(gòu)建一套完善的流媒體系統(tǒng)，則需要包含靜態(tài)拉流與靜態(tài)推流。假如有觀眾向服務(wù)器C請(qǐng)求播放，那么服務(wù)器C就會(huì)向服務(wù)器A拉流，無論服務(wù)器A是否存在視頻流，服務(wù)器C都會(huì)拉取。因此該模型只適用于較為簡單的業(yè)務(wù)場景。

3. 動(dòng)態(tài)控制：動(dòng)態(tài)回源、動(dòng)態(tài)轉(zhuǎn)推、鑒權(quán)

相對(duì)于靜態(tài)推拉流的“無腦”推拉流，更適用于多數(shù)人需求的則是動(dòng)態(tài)推拉流。

Nginx的RTMP服務(wù)針對(duì)每一項(xiàng)功能都做了不同的觸發(fā)階段。以oclp_play為例，當(dāng)有人啟動(dòng)播放時(shí)會(huì)觸發(fā)play消息，play消息會(huì)攜帶一項(xiàng)start參數(shù)。

在播放過程中，play消息依舊會(huì)被觸發(fā)，只不過此時(shí)還會(huì)攜帶update參數(shù)。在play結(jié)束時(shí)也會(huì)觸發(fā)一個(gè)play消息，所攜帶的參數(shù)是down。借助這些參數(shù)，我們可以實(shí)現(xiàn)向業(yè)務(wù)服務(wù)器通知請(qǐng)求播放以及播放的具體階段。

3.1 動(dòng)態(tài)回源

推流過程也存在類似操作，推流中存在publish，同樣分為三個(gè)階段，play和publish主要應(yīng)用在鑒權(quán)操作中。如果在start階段，業(yè)務(wù)服務(wù)器返回了一個(gè)404或者非200的結(jié)果，服務(wù)器就會(huì)中斷當(dāng)前的play請(qǐng)求，publish亦是如此。除此之外， pull與push主要應(yīng)用于動(dòng)態(tài)拉流階段。當(dāng)服務(wù)器接收到play請(qǐng)求，并且發(fā)現(xiàn)當(dāng)前服務(wù)器里面沒有目標(biāo)流，也就是說publish的流不存在，就會(huì)觸發(fā)pull的start階段。在發(fā)送start請(qǐng)求之后如果業(yè)務(wù)服務(wù)器返回結(jié)果為302，并且在location中又寫了一個(gè)新的rtmp地址或http-flv地址，這臺(tái)服務(wù)器就會(huì)向標(biāo)記的那一臺(tái)目標(biāo)服務(wù)器拉取rtmp流或fIv流，這個(gè)過程就被稱為動(dòng)態(tài)拉流。

3.2 動(dòng)態(tài)轉(zhuǎn)推

與動(dòng)態(tài)拉流相對(duì)應(yīng)的是動(dòng)態(tài)推流，其理解方式與動(dòng)態(tài)拉流大致相同。如果你向服務(wù)器推流，服務(wù)器會(huì)向配置好的目標(biāo)地址發(fā)送start請(qǐng)求。如果在返回結(jié)果當(dāng)中加入一個(gè)新的rtmp地址，這一臺(tái)媒體服務(wù)器就會(huì)向新的rtmp地址推流，這也就是動(dòng)態(tài)推流的操作。這一切的前提是返回302的結(jié)果，如果不想將流推出，那么反饋給服務(wù)器400或其他非200，該流就會(huì)被中斷。

Oclp_stream用的比較少，僅僅在這路流創(chuàng)建與消失時(shí)被觸發(fā)。不管是play還是publish，如果只有play或publish存在，都會(huì)認(rèn)為這路流的生命周期還沒有結(jié)束，只有當(dāng)二者全部消失時(shí)才會(huì)被認(rèn)定該路流生命周期已結(jié)束。

同樣的，如果一路流沒有被發(fā)布過而是僅僅第一次有人請(qǐng)求，此時(shí)也會(huì)觸發(fā)start并認(rèn)為是該路流被創(chuàng)建，只不過沒有生產(chǎn)者而已。這種場景的應(yīng)用比較少，只有對(duì)業(yè)務(wù)要求比較高的系統(tǒng)可能會(huì)用到這一條消息。

上圖展示了一個(gè)配置事例，主要包括查詢服務(wù)器的IP、查詢服務(wù)器play操作希望支持哪些階段等。

集群化部署依賴業(yè)務(wù)（調(diào)度）服務(wù)器，如果有回源需求則讓邊緣服務(wù)器B在oclp_hold階段向業(yè)務(wù)服務(wù)器查詢，此時(shí)業(yè)務(wù)服務(wù)器會(huì)告訴邊緣服務(wù)器B一個(gè)302地址，其中包含源地址。邊緣服務(wù)器B就會(huì)從標(biāo)記出來的這一臺(tái)（媒體服務(wù)器A）拉流，從而實(shí)現(xiàn)動(dòng)態(tài)回源。

動(dòng)態(tài)轉(zhuǎn)推主要是為了把本地的流推出去。在CDN的服務(wù)中，不同集群負(fù)責(zé)不同的職能。例如有些集群負(fù)責(zé)錄制，有些則僅負(fù)責(zé)轉(zhuǎn)碼，此時(shí)我們希望核心機(jī)器能夠把這些需要轉(zhuǎn)碼或需要錄制的流按照需求轉(zhuǎn)接到相應(yīng)集群。動(dòng)態(tài)轉(zhuǎn)推非常重要，如果業(yè)務(wù)中包含這些不同的類型，就需要添加配置oclp_push去實(shí)現(xiàn)動(dòng)態(tài)轉(zhuǎn)推。

3.3 鑒權(quán)

鑒權(quán)操作中，我們只會(huì)對(duì)publish或play進(jìn)行鑒權(quán)。

如果play的時(shí)候反饋200就是允許播放，如果反饋403就是不允許播放，publish也是如此，通過業(yè)務(wù)服務(wù)器控制客戶某一次服務(wù)請(qǐng)求是否能被允許。

前端進(jìn)行play或者是進(jìn)行publish時(shí)，如何把鑒權(quán)的token帶過來？

主要通過變量：args=k=v&pargs=$pargs在向外發(fā)送play查詢時(shí)，如果加入args=k=v&pargs=$pargs ，發(fā)請(qǐng)求時(shí)會(huì)帶上這些參數(shù)，這樣就可以將rtmp的全部自定義參數(shù)傳遞過來。

4. 多進(jìn)程：進(jìn)程間回源

多進(jìn)程問題在原生的nginx rtmp中有很多bug，現(xiàn)在的做法是通過共享內(nèi)存記錄下每個(gè)進(jìn)程上的stream列表。如果play的進(jìn)程沒有流，則查詢stream列表，并通過unix socket向目標(biāo)進(jìn)程回源拉流。除此之外，進(jìn)程間的回源不會(huì)觸發(fā)ocl_playoclp_publish oclp_pull消息。

5. 更多操作說明

PingOS：https://github.com/im-pingo/pingos

【線上分享預(yù)告】大規(guī)模互動(dòng)直播與在線視頻用戶體驗(yàn)優(yōu)化實(shí)踐

伴隨疫情突發(fā)，在線教育、視頻會(huì)議、互動(dòng)直播與在線視頻需求被推上風(fēng)口，如何在大規(guī)模、高并發(fā)視頻需求下為用戶提供更流暢、更高清、低延遲的直播與視頻觀看體驗(yàn)？如何為線上教育賦予電子白板功能優(yōu)化用戶學(xué)習(xí)體驗(yàn)與教學(xué)效果？如何激發(fā)用戶在線視頻觀看興趣、提升用戶視頻交互體驗(yàn)？

3月29日19:00，LiveVideoStack攜手UCloud RTC首席架構(gòu)師王立飛、學(xué)而思網(wǎng)校資深架構(gòu)師趙文杰、嗶哩嗶哩資深研發(fā)工程師唐君行，共同探索大規(guī)模互動(dòng)直播與在線視頻背后的底層技術(shù)架構(gòu)，分享用戶體驗(yàn)優(yōu)化實(shí)踐經(jīng)驗(yàn)。

• 《URTC萬人連麥直播的優(yōu)化實(shí)踐》 王立飛 UCloud RTC首席架構(gòu)師
• 《線上/線下教育中白板技術(shù)優(yōu)化》 趙文杰 學(xué)而思網(wǎng)校資深架構(gòu)師
• 《高能進(jìn)度條：視頻交互體驗(yàn)優(yōu)化》 唐君行 嗶哩嗶哩資深研發(fā)工程師

公開課預(yù)約入口：

大規(guī)模互動(dòng)直播與在線視頻用戶體驗(yàn)優(yōu)化實(shí)踐-LiveVideoStack&UCan公開課第21期?mudu.tv

總結(jié)

以上是生活随笔為你收集整理的ts获取服务器数据_基于Nginx的媒体服务器技术-线上公开课的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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