kurento学习进阶一（源码库依赖关系）_kurento-tutorial-node turn.json-CSDN博客

本文链接：https://blog.csdn.net/liuweihui521/article/details/79928459

Developer Guide ¶

This section is a comprehensive guide for development of Kurento itself. The intended reader of this text is any person who wants to get involved in writing code for the Kurento project, or to understand how the source code of this project is structured.

If you are looking to write applications that make use of Kurento, then you should read Writing Kurento Applications.

Table of Contents

Introduction ¶

Kurento offers a multimedia framework that eases the task of building multimedia applications with the following features:

Dynamic WebRTC Media pipelines: Kurento allows custom media pipelines connected to WebRTC peers like web browsers and mobile apps. These media pipelines can be composed by players, recorders, mixers, etc. and can be changed dynamically when the media is flowing.
Client/Server Architecture: Apps developed with Kurento follow a client/server architecture. Kurento Media Server (KMS) is the server and offers a WebSocket interface implementing the Kurento Protocol, which allows Client Applications to define pipeline topologies.
Java and JavaScript Client Applications: The typical use case of a KMS deployment consists of a three-layer architecture, where the user’s browser interacts with the KMS server by means of an intermediate Client Application. There are several official Kurento Client Libraries, supporting the use of Java and JavaScript for the Client Applications. Clients for other languages can be easily implemented following the WebSocket protocol.
Third party Modules: KMS has an extensible architecture based on plugins, which allows third parties to implement modules that can be combined with other built-in or third party modules in the same pipeline. For example, there are modules for Computer Vision with features such as face detection, barcode reading, etc.

This document contains a high level explanation of how to become a KMS developer. Development of Kurento Client Applications is out of the scope for this document, and won’t be explained here.

Development tools ¶

This is an overview of the tools and technologies used by KMS:

The code is written in C and C++ languages.
The code style is heavily influenced by that of Gtk and GStreamer projects.
CMake is the construction tool.
The source code is versioned in several GitHub repositories.
The officially supported platforms are Ubuntu LTS distributions: 14.04 (Trusty) and 16.04 (Xenial).
The heart of KMS is the GStreamer multimedia framework.
In addition to GStreamer, KMS uses other libraries like boost, jsoncpp, libnice, etc.

Source code repositories ¶

Kurento source code is stored in several GitHub repositories at https://github.com/Kurento. Each one of these repositories has a specific purpose and usually contains the code required to build a shared library of the same name.

There are several types of repositories:

Fork Repositories: KMS depends on several open source libraries, the main one being GStreamer. Sometimes these libraries show specific behaviors that need to be tweaked in order to be useful for KMS; other times there are bugs that have been fixed but the patch is not accepted at the upstream source for whatever reason. In these situations, while the official path of feature requests and/or patch submit is still tried, we have created a fork of the affected libraries. The repositories that contain these forked libraries are called “Fork Repositories”.
These are the current Fork Repositories, as of KMS version 6.7:
- gstreamer (libgstreamer1.5)
- gst-plugins-base
- gst-plugins-good
- gst-plugins-bad
- gst-plugins-ugly
- gst-libav
- jsoncpp
- libsrtp
- libnice (gstreamer1.0-nice, gstreamer1.5-nice)
- openwebrtc-gst-plugins
- openh264
- usrsctp
Main Repositories: The core of KMS is located in Main Repositories. As of version 6.7, these repositories are:
- kurento-module-creator: It is a code generation tool for generating code scaffolding for plugins. This code includes KMS code and Kurento client code. It has mainly Java code.
- kms-cmake-utils: Contains a set of utilities for building KMS with CMake.
- kms-core: Contains the core GStreamer code. This is the base library that is needed for other libraries. It has 80% C code and a 20% C++ code.
- kms-elements: Contains the main elements offering pipeline capabilities like WebRtc, Rtp, Player, Recorder, etc. It has 80% C code and a 20% C++ code.
- kms-filters: Contains the basic video filters included in KMS. It has 65% C code and a 35% C++ code.
- kms-jsonrpc: Kurento protocol is based on JsonRpc, and makes use of a JsonRpc library contained in this repository. It has C++ code.
- kurento-media-server: Contains the main entry point of KMS. That is, the main() function for the server executable code. This application depends on libraries located in the above repositories. It has mainly C++ code.
Omni-Build Repository: The kms-omni-build repository is a dummy umbrella for the other KMS Main Repositories. It has no actual code; instead, it only has the required CMake code to allow building the whole KMS project in one go. For this, it gets a copy of the required repositories via Git submodules.
Module Repositories: KMS is distributed with some basic GStreamer pipeline elements, but other elements are available in form of modules. These modules are stored individually in Module Repositories. Currently, we have the following ones:
Client Repositories: Client Applications can be developed in Java, JavaScript with Node.js, or JavaScript directly in the browser. Each of these languages have their support tools made available in their respective repositories.
Tutorial or demo repositories: There are several repositories that contain sample code for developers that use Kurento or want to develop a custom Kurento module. Currently these are:

A KMS developer must know how to work with KMS Fork and Main Repositories and understand that each of these have a different development life cycle. The majority of development for KMS will occur at the KMS Main Repositories, while it’s unusual to make changes in Fork Repositories except for updating their upstream versions.

Module dependency graph ¶

This graph shows the dependencies between all modules that form part of Kurento:

$digraph dependencies_all { bgcolor = 'transparent'; fontname = 'Bitstream Vera Sans'; fontsize = 8; size = '12,8'; rankdir = 'RL'; // Kurento external libraries 'gstreamer'; 'libsrtp'; 'openh264'; 'usrsctp'; 'jsoncpp'; 'gst-plugins-base' -> 'gstreamer'; 'gst-plugins-good' -> 'gst-plugins-base'; 'gst-plugins-ugly' -> 'gst-plugins-base'; 'gst-plugins-bad' -> {'gst-plugins-base' 'libsrtp' 'openh264'}; 'gst-libav' -> 'gst-plugins-base'; 'openwebrtc-gst-plugins' -> {'gstreamer' 'gst-plugins-base' 'usrsctp'}; 'libnice' -> 'gstreamer'; // KMS main components 'kurento-module-creator'; 'kms-cmake-utils'; 'kms-jsonrpc' -> {'jsoncpp' 'kms-cmake-utils'}; 'kms-core' -> {'gstreamer' 'gst-plugins-base' 'gst-plugins-good' 'gst-plugins-ugly' 'gst-libav' 'gst-plugins-bad' 'kms-cmake-utils' 'kms-jsonrpc' 'kurento-module-creator'}; 'kms-elements' -> {'openwebrtc-gst-plugins' 'libnice' 'kms-core'}; 'kms-filters' -> 'kms-elements'; 'kurento-media-server' -> {'kms-core' 'kms-elements' 'kms-filters'}; // KMS extra modules 'kms-chroma' -> {'kms-core' 'kms-elements' 'kms-filters'}; 'kms-crowddetector' -> {'kms-core' 'kms-elements' 'kms-filters'}; 'kms-datachannelexample' -> {'kms-core' 'kms-elements' 'kms-filters'}; 'kms-platedetector' -> {'kms-core' 'kms-elements' 'kms-filters'}; 'kms-pointerdetector' -> {'kms-core' 'kms-elements' 'kms-filters'}; }$

All dependency relationships¶

Module dependency list ¶

As the dependency graph is not strictly linear, there are multiple possible ways to order all modules into a linear dependency list; one possible order would be this one:

Externals: