kurento 6.14.0文件翻譯第九章 編寫Kurento應用程式

qazxcvbnm2000發表於2020-11-16

目錄

         編寫Kurento應用程式

         全域性架構

                   通訊客戶端，伺服器和Kurento

  1. 媒體協商階段（信令）
  2. 媒體交換階段

使用實時的WebRTC應用

媒體平面

9.1全域性架構

可以按照網路的架構原理使用Kurento，即建立一個基於kurento的多媒體應用，與使用任何流行的Web開發框架建立Web應用程式類似的體驗。

在最高抽象級別上，Web應用程式的體系結構由三個不同的層組成：

  1. 表示層（客戶端）：在這裡，我們可以找到負責與終端使用者進行互動的所有應用程式程式碼，以便以全面的方式表示資訊。這經常是在HTML頁面使用javascript程式碼。
  2. 應用邏輯（服務端）：該層負責實現應用程式執行的特定功能.
  3. 服務層（服務或網際網路端）：這層通過應用程式的邏輯提供像資料庫，通訊，加密等功能。這些服務可以與應用程式託管在同一伺服器上邏輯，或者可以由外部各方提供

遵循這種並行性，使用Kurento建立的多媒體應用程式也可以採用相同的架構來實現：

  1. 表示層（客戶端）：負責多媒體表示和多媒體捕獲。它通常是基於客戶端的特定內建功能，比如當建立一個基於瀏覽器的應用，這個表示層將使用html的<video>標籤或者WebRTC javascript API.
  2. 應用邏輯（服務端）：這層提供特定的多媒體邏輯，換句話說這層負責建立一個適當的管道（通過連結所需的媒體元素）應用中涉及的多媒體流將需要遍歷.
  3. 服務層:這層提供多媒體服務支援像媒體錄製、媒體加密等應用邏輯，KMS（即Media Elements的特定Media Pipeline）負責這一層。

討論的有趣之處在於與web開發一樣，Kurento應用程式可以將表示層放在客戶端，將服務層放在伺服器。所有情況下的應用邏輯都可以位於任一側，甚至可以分佈在它們之間，下圖表示了這個想法：

這意味著Kurento開發人員可以選擇在客戶端（包括使用合適的Kurento客戶端或直接與kurento協議一起）包含建立其應用程式所需的特定媒體管道的程式碼，也可以將其放置在伺服器端。

兩種選擇都是可以的，但是它們是不同的開發方式，話雖如此，需要注意的是，在Web開發人員中，通常傾向於儘可能簡化客戶端程式碼，將更多的邏輯放在服務上，重現這種開發經驗是使用Kurento的最常用方法。

提示：在以下各節中，所有Kurento處理都在伺服器端完成。它也是更多通用的使用kurento方法，需要注意的是所有的多媒體邏輯都可以使用kurento javascript客戶端在客戶端實現

9.2 應用架構

Kurento作為大多數多媒體通訊技術。使用兩層（稱為平面）構建，以抽象所有互動式通訊系統中的關鍵功能：

  1. 信令平面：這個系統的部分負責管理通訊，這個模組提供媒體談判，QoS引數化，呼叫建立，使用者註冊，使用者保持等功能。被認為是信令平面的一部分。
  2. 媒體平面：媒體傳輸，媒體加碼、解碼和媒體處理功能叫著媒體平面，負責處理媒體，區別來自語音處理和元資訊（如音調，計費等）處理之間的電話區別。

下圖顯示了Kurento的高階體系結構的概念性表示：

圖片的右側顯示了應用程式，該應用程式負責信令平面，幷包含正在部署的特定多媒體應用程式的業務邏輯和聯結器，它可以構建不同的程式語言像java、node.js、php、.net等，應要可以使用成熟的技術像HTTP、SIP Servlet、web服務，資料庫連結，訊息服務等。由於這個該平面提供對最終客戶端常用的多媒體信令協議（例如SIP、RESTful、基於HTTP的原始格式、SOAP RMI CORRA或JMS）的訪問，這些信令協議被應用程式的客戶端用於命令媒體會話的建立並代表它們協商所需的特性。因此這是體系結構的一部分，與應用程式開發人員聯絡，因此，需要在設計時追求簡單性和靈活性。

在左側，我們有KMS它實現了媒體平面的能力提供訪問低層級的媒體特性：媒體傳輸，媒體編碼/解碼，媒體轉碼、媒體混淆，媒體處理等，KMS必須要以最小延遲和最大的吞吐量管理多媒體流，因此KMS必須優化效率

9.2.1通訊客戶端，伺服器和Kurento

如下圖所示，Kurento應用程式涉及三個主要模組之間的互動：

客戶端應用：涉及客戶端平臺的本機多媒體功能以及特定的客戶端應用程式邏輯，它可以使用專為客戶端平臺設計的Kurento客戶端（例如Kurento JavaScript 客戶）。

應用服務：涉及應用伺服器和服務端應用邏輯，它可以使用專為服務端平臺設計的Kurento（例如Kurento java 客戶端，和kurento node.js）。

Kms:接收命令建立特別的多媒體能力（如：應用所需要的特定的管道介面卡），這些模組之間維護的互動取決於每個應用程式的細節，但是，總的來說，對於大多數應用，可以簡化為以下概念方案：

  1. 媒體協商階段（信令）

在第一階段，客戶端（計算機中的瀏覽器，移動應用程式等）嚮應用程式發出一條訊息，請求某種多媒體功能。這個訊息可以使用任何協議（HTTP、WebSocket、SIP等）例如該請求可以要求對給定視訊片段進行視覺化

當應用接收到請求，如果可以，它將執行特定的伺服器端應用程式邏輯，可以包含認證方式，授權和帳戶， CDR生成，消耗某種型別的Web服務等

之後，應用處理請求和根據開發人員程式設計的特定說明, 命令KMS例項化合適的媒體元素並將它們連結在合適的媒體管道中，當管道建立成功，KMS做出相應響應，並且

應用程式將成功的響應轉發給客戶端，向其展示如何以及在何處可以訪問媒體服務。

 

在上述步驟中，實際上沒有交換任何媒體資料，所有互動的目的都是就媒體交流的方式，方式，地點和時間進行協商。所以我們叫它媒體協商階段，在此階段僅涉及信令協議。

  1. 媒體交換階段

信令部份之後，一個新的階段開始目的是進行實際的媒體交流，客戶端使用在協商階段收集的資訊將媒體請求傳送給Kurento媒體伺服器

在上面提到的視訊剪輯視覺化示例之後，瀏覽器將傳送一個GET請求到獲取剪輯的KMS的IP地址和埠，以及HTTP響應包含媒體的資訊將被接收。

接下來討論這個簡單的例子，有人可能想為什麼這麼複雜的方案只是為了播放視訊。大多數常用方案是客戶端傳送一個請求到適當的視訊URL並不需要任何協商，這個回答是直截了當的，kurento是為了媒體應用涉及複雜的媒體處理，所以我們需要去建立兩段機制在媒體交換前啟用協商。需要付出的代價是，簡單的應用程式（例如僅下載視訊的應用程式）也需要完成這些階段。但是，這樣做的好處是，在建立更多高階服務時，將保持相同的簡單原理。例如我們想要新增擴增實境或機器視覺功能到視訊剪輯中，我們只需要在協商階段建立合適的管道即可儲存所需的媒體元素，之後，從客戶的角度處理過的剪輯將像其他任何視訊一樣被接收。

9.2.2使用kurento實時WebRTC應用

客戶通過SDP請求/應答協商傳達其所需的媒體功能，因此kurento可以例項化適當的WebRTC端點並要求其根據自己的資訊生成SDP應答功能和SDP請求，當獲得SDP應答，它將交回給客戶端，媒體交換可以開始。下圖總結了不同模組之間的互動：

應用開發人員可以建立想要的管道在談判階段，所以實時的多媒體流根據應用需求進行相應處理。

根據這個例子，想象一下，您想建立一個WebRTC應用程式來記錄從客戶端接收到的媒體並對其進行擴充，以便在發現人臉時在其上方渲染一頂帽子。 下圖示意性地顯示了該管道，我們假設過濾器元素能夠檢測面部並新增帽子：

9.3媒體層面

從應用程式開發人員的角度，媒體元素像樂高積木：你只需要拿到應用中需要的元素並組裝它們，接下來所需的拓撲，在Kurento行話，連線的媒體元素圖叫著媒體管道，因此當建立一個管道，開發者需要確定使用的能力（媒體元素）和確定拓撲，媒體元素提供的與其他媒體元素（連線）連線的媒體

連線是通過在所有Kurento Client API上公開的connect原語控制的。

始終在充當源的元素中呼叫此原語，並按照以下方案將接收器元素作為引數：

sourceMediaElement.connect(sinkMediaElement)

例如，如果你想建立一個應用記錄WebRTC媒體流到檔案中，你需要兩個媒體元素：WebRtcEndpoint 和 RecorderEndpoint，當一個客戶端連線這個應用，你癬需要例項化兩個媒體元素使得流通過WebRtcEndpoint(有能力接收WebRTC流)接收，它將被饋送到RecorderEndpoint（能夠將媒體流記錄到檔案系統中）。最後，您將需要連線它們，以便將前者接收的流傳輸到後者：

WebRtcEndpoint.connect(RecorderEndpoint)

簡化客戶端中WebRTC流的處理，kurento提供一個工具叫著WebRtcPeer，不過標準的WebRTC API（(getUserMedia, RTCPeerConnection等）也可以用於連線WebRtcEndpoint有關更多資訊，請訪問“教程”部分（ps：第六章）

相關文章