Kurento是否可以讓客戶端選擇不同的實時監控視頻？

01-23

Kurento是webRTC流媒體伺服器。
視頻監控廠商無法提供web監控畫面，所以才不得不自己開發這樣的功能。
想知道，Kurento是否能實現，讓客戶去看實時的監控畫面？
有樣例代碼嗎？想知道，實時監控畫面的流怎樣與之對應呢？

謝邀，目前看來，三種方案：

第一，最傳統的方案，動用瀏覽器插件，並指定客戶使用特定瀏覽器特定版本。

優點：技術成熟，廠商自帶軟體。

缺點：技術落伍（未來瀏覽器不支持插件），部署困難，兼容性差，不適合消費級應用。

第二，使用 HLS 或 flv 直播流傳送視頻，web 前端使用 flash 或者 js 播放庫播放。

優點：技術比較成熟，有開源方案。跨桌面/移動/微信比較方便。

缺點：

1，由於協議缺陷，延時問題很難解決。秒級延時無法滿足商用安防需求。

2，後台有一定開發工作量，不僅是協議轉換，還有報警控制等信令服務的改寫。

// 這裡我把很長用的 rtmp 方案給忘了，這也是個很實用的方案，不過瀏覽器端依賴 flash。

第三，使用 webRTC 傳輸視頻，瀏覽器使用原生 api 播放。

優點：面向未來的方案，客戶端端性能最優、代碼最簡單。

缺點：最主要的缺點是開發工作量太大，需要解決的問題太多，包括但不限於——

1，RTC gateway 問題。至少國內廠商一般是沒這個東西的，需要自己寫（就是你想做的事情）。編寫一個穩定、易伸縮的流媒體服務軟體，並不容易。而且，如果你不是特別重要的客戶，國內廠商的打包格式你是要不到的。SDK可控性太差了。

2，udp 打洞問題。最近我沒關注 webRTC 新進展，不知道現在新版瀏覽器對於 RTP via TCP 支持的怎麼樣了？反正以前是不行。所以必須 udp 打洞。但是安防系統面對的網路，情況比較複雜，有的適合架設打洞服務，有的不適合，反正各種情況都有。

3，瀏覽器兼容問題。越新的瀏覽器兼容越好，但是老的不行。而且這裡有個很大的坑，就是編碼。chrome 支持 vp 系列不支持 h264，IE 支持 h264 不支持 vp 系列（現在還是這樣嗎？可能消息過時了），這就讓後台服務很為難了，轉碼是不現實的。

4，其他連帶問題，比如，加密怎麼搞，廠商自有的擴展幀怎麼辦（主要是智能識別信息和動態 OSD 信息什麼的，小應用可能用不到），等等。不是不能解決，但是沒有現成的方案。

綜上，如果是消費級應用，能接受秒級延時，推薦方案二，和 websocket 結合可以實現的非常優雅。方案三可以作為大公司預研項目，推向市場似乎是不太合適。

如果是平安城市級的大項目，別考慮這些了，採用方案一，跟著國標 GBT 28281 走。

說實話，企業級、城市級的安防系統，本身並不是一個適合 web 化的領域，之所以搞 web 化，一方面是為了大集成，和增刪改查互相嵌入（無意義的居多）。另一方面也是為了滿足領導們「隨時隨地想看就看」的快感。那些真正天天看監控的人，是不在乎打開的是軟體還是瀏覽器的。

ps：我發現我對安防是真有感情，看到有意思的問題就想答……

樓上 @欲三更對方向和行業的解讀非常精準。當然我這裡忍不住介紹下我們的解決方案了——其實，國內我們公司做了完全兼容WebRTC的媒體伺服器——MCU，SFU和自研的TURN伺服器，有授權API，也有SDK，也在公網上有自己的雲，技術上非常紮實。只是公司小，人微言輕，因此有些行內的朋友都不了解我們的解決方案。

本鏈接（首頁 - 實時貓媒體伺服器技術演示Demo）是實時貓 WebRTC Media Server (SFUMCU) 的演示。

頁面中可以看出，『多人視頻控制』功能的本質是SFU，適合硬體計算能力低，視頻發布者數量少，可切換連接，靈活性需求高的場景。『多人語音會議』則是完全混音的MCU，適合好硬體，全混屏。

總之，樓上提到WebRTC方案面對的問題，正是我們的主要解決目標：RTC gateway由我們的媒體伺服器解決；WebRTC協議兼容是我們的強項；UDP打洞我們有純自研的TURN以及多年在公司網路打洞的經驗和測試工具包；加密既可以在信令層做，也可以改RFC3711的SRTP機制。只剩下瀏覽器兼容方面搞不定IE，有些企業應用場景可以通過(a)指定瀏覽器，(b)封裝成Hybrid應用跑在目標平台，或(c)使用我們的Windows SDK開發客戶端來解決。

最後，借這個問題，我想多聊幾句對WebRTC在企業應用的前景的個人理解，

1. WebRTC是一項有差異化優勢的新技術，並不能看做 Just another communication standard 。其對瀏覽器的兼容，快速嵌入已有場景的能力，高實時，協議棧中各層次的可擴展性，開源社區的支持，都會打開不少視頻應用的新場景新局面，解決新的行業和業務問題。而這些問題是傳統技術無法解決的。

2. 從通信標準到行業產品，有很長的路要走，但一定能走完。 WebRTC做為一個正在討論的點對點通信標準，在現階段距最終產品的確很遠。在解決好SDK，媒體伺服器，網路等幾道大難題後，距離最終的應用就更近了。從這個意義上講，Janus，Kurento, http://Callstats.io 等企業為我們做了大量有意義的工作，使標準越來越接近實用。

——事實也是如此，在研發層面，我們的公有雲客戶能在很短時間用我們的SDK解決通信問題，私有雲客戶我們能通過 Docker+Kubernetes 快速解決複雜的網路部署、穿透、映射，一般情況下甚至可以遠程解決。企業級產品研發人員可以深度使用SDK的底層介面來實現更複雜的通信系統和軟硬體。這雖然還都需要一定量的工作，但普遍比購買靈活性更差的私有技術，或使用過時的技術有優勢。在產品層面，美國的CafeX已經通過WebRTC的企業化產品打入的多國的銀行市場，並開始和Avaya等方案對接——私有雲/混合雲基礎上的通信類行業產品，哪怕在國內都是有一定接受度的，而且市場規模在快速擴大。

3. 因此，我理解的WebRTC應用大方向有以下幾個，個人意見：

(1) 擴展已有通信方案和形態的能力，打存量市場。如會議、通信、監控等市場的系統升級，客戶端種類擴展，客戶端的場景融入，協議間互通業務；

(2) 提供行業軟體/方案，解決高支付能力的垂直行業中，非WebRTC不可的使用場景；（這樣的場景很多很多）

(3) 在物聯網，跨平台，嵌入式等等終端種類多，終端靈活性要求高的領域發揮合作優勢，尤其要找市場佔有率第一的行業企業合作；

(4) 與有大量網路和伺服器資源的通信企業/系統集成商合作，成為其上游鏈條之一，為其資源和產品的增值提供基礎。

以我的理解，國內的企業級軟通信的市場需求才剛剛開始有起來的苗頭，上面的路子，擇一二重點發展，都是可以較快較可靠地做成一家企業的。

至於公有雲，做不到市場老大肯定死，做到市場老大也不一定能靠公有雲活，這基本是業內人士的共識了。

可以的。

具體參考Kurento/kurento-tutorial-node

方案有二，1）presentor可以直接熱替換成其他的WebRTCendpoint源。2）用dispatcher 切換

你為什麼不去看提供方的SDK。。。