1.5 Basic Principles

1.5.1 Groups of primitives

All functional elements can be divided into the following groups of primitives:

  • Server objects - those that implement server functionality and run on the server side.
  • Client objects - those that pull media data from an external server. In case of a local file, it can be called a reader object.
  • Publisher objects - those that push media data to an external server. They can also be called forwarders. In case of a local file, it can be called a writer object.

In addition to that, the following groups are available for most of the supported platforms:

  • Media capture objects - those that capture local media data, e.g., webcam, microphone etc.
  • Media rendering objects - UI controls that are intended for visualizing of media streams to be viewed by users.

1.5.2 Media data flow

VASTreaming library utilizes source/sink pattern for media data flow. Media data flow streams down from a source to a sink like in a pipeline (see Fig. 1) with optional flow processing on the way. A source of media data can be an external streaming server, an IP camera, third-party software, a cloud video, audio, or image file. Local media files may also be used as a media source. In most cases a media sink is an external streaming server distributing media stream over network of end-users, end-users computers or mobile devices, or recorded local video files, or audio files.

Figure 1. Media data stream diagram.

Media data stream diagram

Accordingly, client and media capture objects are implementing IMediaSource interface, and publisher and media rendering objects are implementing IMediaSink interface.

1.5.3 Single protocol streaming server

VASTreaming library provides standalone, protocol specific servers for certain protocols, such as RTMP, RTSP, or WebRTC. These servers incorporate the logic to accept incoming connections, create media sources and sinks, and provide them to a user code. But it is a user who is responsible for implementing media data flow between IMediaSources and IMediaSinks. VASTreaming, however, provides demos showing how to make it work well. See Demos section of this manual for more details.

Figure 2. Single protocol streaming server diagram.

Single protocol streaming server diagram

1.5.4 Multi-protocol streaming server

This server is one of the most complicated components of VASTreaming library. It depends on almost all other modules. In a real production environment, it is often not enough to have a single protocol server; it is usually necessary to utilize several protocols, so a multi-protocol streaming server is a highly demanded element.

Multi-protocol streaming server allows setting up a streaming server that supports all the protocols necessary for a user in a single, easily controllable environment. Multi-protocol streaming server implements the architecture so that protocol-specific data of sources is transformed into an abstract, protocol-independent internal representation, which in its turn, is transformed into a protocol-specific data in each sink again. The server ensures high-performance media data transformation between different protocols allowing serving thousands of incoming and outgoing connections.

Figure 3. Multi-protocol streaming server diagram.

1.5.5 Low latency

All VASTreaming libraries are optimized for minimization of latency and all their components uses low latency mode by default, even if it comes at the expense of reception / transmission / playback smoothness.

Typical latency of VASTreaming library on LAN while using low latency protocol e.g., RTMP, RTSP, or WebRTC, is 200-300 milliseconds.

contact us