首先,你需要捕獲與像Directshow,AVFoundation ,或v4l,這取決於您的平臺。
接下來,您需要使用編解碼器將原始幀轉換爲實際可通過實際網絡發送的內容。原始視頻數據非常龐大,因此需要編解碼器才能對該數據進行有損壓縮。在基本級別上,編解碼器將在幀之間進行重複數據刪除,以便每幀不會發送任何不真正改變的內容。編解碼器比這更先進,使用基於我們實際感知的技術(例如優先考慮顏色變化的亮度變化),以減少需要發送的數據量。您不需要編寫編解碼器......這樣的任務不是一件小事,而且非常複雜。有許多現有的編解碼器可供選擇。平臺選擇和兼容性通常會給你一個或兩個選項。
現在,您需要一個傳輸協議。大多數視頻流實際上都是通過TCP完成的,確保了流暢的視頻流。 (UDP數據包始終會重新排序,並且很容易丟失。)實時應用程序(如視頻會議)通常使用UDP,因爲延遲問題遠不止質量流。丟幀可以接受,並在實時對話中偶爾出現小故障。例如,在電影中出現這樣的故障是不可接受的,或者甚至是延遲並不重要的單向實時流。
您使用的應用程序協議通常會決定您是否使用TCP或UDP。 RTSP是一個選項,還有很多其他的。但是,如果想要在瀏覽器中查看流,則需要使用帶有Flash,WebRTC的RTMP或基於HTTP的協議,如直接HTTP漸進式,DASH或HLS。
DASH和HLS是分段流式的形式,通常通過記錄幾秒鐘並將靜態文件寫入磁盤來實現,它們由普通的HTTP服務器提供服務。清單或播放列表文件用於向客戶端指示所有這些文件在哪裏。 (如果您願意,您可以直接從您的應用程序提供相同的資源。)
WebRTC旨在用於在以對等方式連接的兩個客戶端之間流式傳輸數據和媒體流。可以構建一個像這些客戶端一樣的服務器。我不知道有任何開源代碼可以讓你發送媒體流。但是,它已經在商業上完成了。
HTTP漸進式是您簡單地將輸出流式傳輸到客戶端的地方。並非所有格式都可以通過這種方式傳輸。 MJPEG可以這樣工作。 (MJPEG通常被安全攝像機使用,質量低,但易於實現,並且可以在大多數瀏覽器中按原樣工作)。
如果我今天在做這個項目,我會使用帶有VP8或VP9的DASH作爲視頻編解碼器(取決於兼容性)以及用於音頻的Opus。您需要在客戶端頁面上使用DASH.js以方便使用媒體源擴展加載DASH片段。這是獲得體面質量流的最兼容的方式。
謝謝你的描述性信息!它有很大幫助! –