實時流媒體：node-media-server + Dash.js 配置為實時低延遲
[英]Live streaming: node-media-server + Dash.js configured for real-time low latency
問題描述
我們正在開發一款應用程序，可以實時監控您的后院。 每個客戶端都有一個連接到互聯網的攝像頭，流式傳輸到我們的公共 node.js 服務器。
我正在嘗試使用 node-media-server 發布一個 MPEG-DASH（或 HLS）流，以便我們的應用程序客戶端在世界各地的不同網絡、帶寬和分辨率上可用。
我們的目標是盡可能接近“實時”生活，以便您可以立即監控后院發生的事情。
已經完成的技術流程是：
我們服務器上的 ffmpeg 進程處理傳入的相機流（每個相機的單獨子進程）並通過本地機器上的 RTSP 發布流以供節點媒體服務器用作“輸入”（我們還保存分段文件，生成縮略圖等）。 負責的 ffmpeg 命令是：
-c:v libx264 -preset ultrafast -tune zerolatency -b:v 900k -f flv rtmp://127.0.0.1:1935/live/officenode-media-server 正在使用我發現的“實時流媒體”的默認配置運行
private NMS_CONFIG = { server: { secret: 'thisisnotmyrealsecret', }, rtmp_server: { rtmp: { port: 1935, chunk_size: 60000, gop_cache: false, ping: 60, ping_timeout: 30, }, http: { port: 8888, mediaroot: './server/media', allow_origin: '*', }, trans: { ffmpeg: '/usr/bin/ffmpeg', tasks: [ { app: 'live', hls: true, hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]', dash: true, dashFlags: '[f=dash:window_size=3:extra_window_size=5]', }, ], }, },};
據我了解，開箱即用的 NMS（節點媒體服務器）以多種輸出格式發布它獲得的輸入流：flv、mpeg-dash、hls。 對於這些格式的各種在線播放器，我可以使用本地主機上的 url 訪問和流。 使用 mpeg-dash 和 hls，我得到了 10-15 秒的延遲，甚至更多。
我現在的目標是實現一個本地客戶端 mpeg-dash 播放器，使用 dash.js 並將其配置為盡可能接近生活。
我的代碼是：
<!doctype html> <html> <head> <title>Dash.js Rocks</title> <style> video { width: 640px; height: 480px; } </style> </head> <body> <div> <video autoplay="" id="videoPlayer" controls=""></video> </div> <script src="https://cdnjs.cloudflare.com/ajax/libs/dashjs/3.0.2/dash.all.min.js"></script> <script> (function(){ // var url = "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd"; var url = "http://localhost:8888/live/office/index.mpd"; var player = dashjs.MediaPlayer().create(); // config targetLatency = 2.0; // Lowering this value will lower latency but may decrease the player's ability to build a stable buffer. minDrift = 0.05; // Minimum latency deviation allowed before activating catch-up mechanism. catchupPlaybackRate = 0.5; // Maximum catch-up rate, as a percentage, for low latency live streams. stableBuffer = 2; // The time that the internal buffer target will be set to post startup/seeks (NOT top quality). bufferAtTopQuality = 2; // The time that the internal buffer target will be set to once playing the top quality. player.updateSettings({ 'streaming': { 'liveDelay': 2, 'liveCatchUpMinDrift': 0.05, 'liveCatchUpPlaybackRate': 0.5, 'stableBufferTime': 2, 'bufferTimeAtTopQuality': 2, 'bufferTimeAtTopQualityLongForm': 2, 'bufferToKeep': 2, 'bufferAheadToKeep': 2, 'lowLatencyEnabled': true, 'fastSwitchEnabled': true, 'abr': { 'limitBitrateByPortal': true }, } }); console.log(player.getSettings()); setInterval(() => { console.log('Live latency= ', player.getCurrentLiveLatency()); console.log('Buffer length= ', player.getBufferLength('video')); }, 3000); player.initialize(document.querySelector("#videoPlayer"), url, true); })(); </script> </body> </html>
使用在線測試視頻（ https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd ）我看到實時延遲值接近 2 秒（但我無法實際確認它。這是一個視頻文件流式傳輸。在我的辦公室里，我有一個攝像頭，所以我實際上可以比較現實生活和我得到的流之間的延遲）。 然而，當我在本地使用我的 NMS 時，這個值似乎不想低於 20-25 秒。
難道我做錯了什么？ 我忘記了播放器（客戶端 html）上的任何配置？ 或者我應該在服務器端 (NMS) 添加缺少的配置？
2 個解決方案
解決方案1
7 已采納 2020-02-14 11:17:29
HLS 和 MPEG DASH 作為標准延遲並不是特別低，您得到的數字並不罕見。
公開可用的 DASH 論壇文檔（鏈接如下）中的一些示例包括：
鑒於其中一些組織的資源，您取得的成果還不錯！
目前流媒體行業非常關注實現更低的延遲，目標是盡可能接近傳統的廣播延遲。
分塊自適應比特率（ABR，請參閱此答案了解更多信息： https : //stackoverflow.com/a/42365034/334402 ）延遲的一個關鍵組成部分是播放器需要接收和解碼一個或多個片段視頻在它可以顯示之前。 傳統上，播放器必須先接收整個片段，然后才能開始解碼和顯示它。 下面第一個鏈接的開源參考中的圖表說明了這一點：
低延遲 DASH 和 HLS 利用 CMAF，即“通用媒體應用程序格式”，它將段（例如，可能是 6 秒長）分成每個段內的較小“塊”。 這些塊旨在允許播放器在收到完整片段之前解碼並開始播放它們。
典型實時流中的其他延遲來源包括從一種格式到另一種格式的任何轉碼，以及流媒體服務器從網絡攝像頭接收提要的任何延遲，以及對其進行編碼和打包以進行流媒體傳輸。
目前有很多關於低延遲流媒體的好信息來自標准機構和開源討論，我認為這將真正幫助您了解這些問題（在撰寫本文時所有鏈接都是最新的）。 來自開源和標准討論：
- https://dashif.org/docs/Report%20on%20Low%20Latency%20DASH.pdf（DASH焦點）
- https://github.com/video-dev/hlsjs-rfcs/pull/1 。 （HLS 重點）
來自供應商：
- https://bitmovin.com/cmaf-low-latency-streaming/
- https://websites.fraunhofer.de/video-dev/dash-js-low-latency-streaming-with-cmaf/
- https://aws.amazon.com/blogs/media/alhls-apple-low-latency-http-live-streaming-explained/
注意 - 廣播界經常引用的一個常見用例是，觀看比賽等現場賽事的人可能會在他們自己看到之前聽到他們的鄰居慶祝進球或達陣，因為他們的提要比他們的鄰居有更高的延遲。 雖然這是低延遲的驅動因素，但這確實是一個同步問題，如果目標是“完美”同步解決方案，則需要其他解決方案。
正如您所看到的，低延遲流式傳輸並不是一個簡單的挑戰，您可能需要根據用例的詳細信息考慮其他方法，包括您擁有多少訂閱者，如果公平權衡，是否會出現一些質量損失更低的延遲等。正如@user1390208 在評論中所提到的，像 WebRTC 這樣更加實時的視頻通信技術可能更適合您所針對的解決方案。
如果您想提供一種既提供生活流媒體又提供錄音的服務，您可能需要考慮使用實時協議進行實時流媒體視圖和 HLS/DASH 流媒體，以便在延遲可能不重要但質量重要的任何人回顧錄音時可能更關鍵。
解決方案2
1 2021-07-07 09:53:57
曾從事過類似的任務 - 盡可能接近實時。 在研究過程中發現，DASH 並不是實現實時翻譯的最快方式。 通過對合作伙伴的媒體服務器端和 FFmpeg 進行一些重大調整，我們可以獲得 6 秒的延遲。 對於系統的用戶查看部分，這對我們來說已經足夠了。 但對於翻譯版主和管理員，我們希望更加實時。 但是還有另一種解決方案，我們使用它。 Websockets/WebRTC。 我們主要使用 Wowza 流引擎作為企業解決方案，並通過一些調整，我們實現了 2 秒的 WebRTC 延遲。
但是在 NMS 的情況下，有一種方法可以讓 websocket-flv 流也開箱即用。 只是為了測試，通過在他們的github 站點上使用他們的播放器解決方案，我現在只實現了 4-4.5 秒的延遲。 也許這些信息會有用。
將視頻從 OBS 流式傳輸到在 heroku 上運行並使用 node-media-server 的 rtmp 服務器
[英]Streaming video from OBS to rtmp server running on heroku and using node-media-server
Node.js中的異步查詢是否有助於克服實時數據流中的延遲？
[英]Do Asynchronous Queries In Node.js Help Overcome Latency In Real-Time Data Stream?
在Localhost上實時更新數據，但不在Live Server上實時更新（Node js + MongoDB）
[英]Data Updating In Real Time On Localhost But Not On Live Server (Node js + MongoDB)
瀏覽器和服務器之間用於實時模型同步的node.js框架是什么？
[英]What are the node.js frameworks for real-time model synchronization between browser and server?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.