内容来源于官方文档,建议阅读官方文档,我写的不可能比它更好了
Kurento API 暴露的这几个对象需要我们去理解,并且我们的使用也是围绕这几个抽象对象来的。
Media Elements and Media Pipelines
Endpoints
Filters
Hubs
通过暴露的 kurento API 可以达到控制 KMS 的目的。因为目前 kms 是 c++ 的,对于不熟悉 c++ 的或者想要用其它语言来控制 kms 的怎么办?kurento 提供了 js 和 java 的客户端,客户端通过 websocket 与 kms 建立连接,并且采用 json rpc 2.0 协议(描述了怎样去调用远程对象的方法,说简单点就是一种消息格式,你告诉我我应该创建什么对象,那我就创建什么对象,你要调用什么方法,那我就把调用的结果返回给你)来控制 kms 。当然,如果你需要实现其它语言的客户端,就需要好好去读读 kurento 协议了,官网上有这方面的详细介绍。
kurento基于两个概念,它们充当了应用程序开发人员的构建块:
媒体元素:媒体元素是对媒体流执行特定操作的功能单元。媒体元素将功能的实现隐藏了起来,开发人员不需要了解它的底层细节。从抽象层面讲的话,每种媒体元素可以代表一种功能,相当于一个黑盒子。媒体元素能够从其它元素(媒体源)接收媒体,也能够向其它元素(媒体接收器)发送媒体。根据它们的功能,可以将媒体元素分成不同的组:
Composite
的集线器能够将所有的视频输入流合并为唯一的视频输出流。并且所有的输入都会展示在一个网格里。媒体管道:媒体管道是媒体元素链,源元素生成的输出流被输入到一个或多个接收器元素中。因此,管道表示能够在流上执行一系列操作的“管道” ;
注:图片来自官网文档;描述了一个媒体管道的例子,实现了一个交互式多媒体应用程序,该应用程序接收来自WebRtcEndpoint 的媒体,将图像覆盖到检测到的人脸上并返回结果流。
kurento API 是面向对象的。这意味着它基于可以以对象形式实例化的类;这些对象提供了表示kurento服务器内部状态的属性,以及公开服务器可以执行的操作的方法。
WebRtcEndpoint
是一个输入/输出端点,它通过web为实时通信(RTC)提供媒体流。它实现了与浏览器通信的 WebRTC 技术。
RtpEndpoint
是一个输入/输出端点,通过RTP协议与远程网络对等点提供双向内容交付功能。它使用SDP进行媒体协商。
HttpPostEndpoint
是一个输入端点,使用 HTTP POST 请求接收媒体,像HTTP 文件上传功能。
PlayerEndpoint
是一个输入端点,从文件系统、HTTP URL 检索内容并将其注入媒体管道。
RecorderEndpoint
是一个输出端点,提供以可靠模式存储内容的功能(不会丢弃数据)。它包含用于音频和视频的媒体接收器。
下面的类图展示了主要端点类之间的关系:
过滤器是执行媒体处理、计算机视觉、增强现实等功能的媒体元素。
ZBarFilter
过滤器检测视频流中的QR码和条形码。当找到代码时,过滤器会引发一个 CodeFoundEvent
。客户端可以向此事件添加侦听器来执行某些操作。
FaceOverlayFilter
过滤器检测视频流中的人脸,并用可配置的图像覆盖它。
GStreamerFilter
是一个通用的过滤器接口,允许将任何GStreamer
元素注入到Kurento
媒体管道中。但是请注意,GStreamerFilter
的当前实现只允许注入单个元素;一个不能同时表示多个;如果需要同时注入多个元素,请使用多个GStreamerFilters
。
下面的类图展示了主要的过滤器之间的关系:
集线器是负责管理管道中的多个媒体流的媒体对象。集线器有几个集线器端口,其中连接着其他媒体元素。
Composite
是一个集线器,它将其连接的输入的音频流混合在一起,并用它们的视频流构建一个网格。
DispatcherOneToMany
是一个集线器,它将给定的输入发送到所有连接的输出端口。
Dispatcher
是一个集线器,允许在任意输入-输出中心端口对之间进行路由。
下面的类图展示了集线器之间的关系: