Project Structure

Project Structure

Streaming SDK provides reusable components for low-latency streaming applications, as well as sample applications demonstrating how to use them. The code for these components is provided in the source form and is compiled as a single static library, which samples and user applications can simply link to.

All Streaming SDK reusable components are located in the sdk/ directory containing the following subdirectories:

• net/ - base classes for IP networking, such as sockets, basic server and client functionality and session management
• transports/ - an implementation of the Transport layer responsible for transferring video and audio between the server and the client over the network
• transports/transport-common/ - definition of the Transport layer interface and common data elements, such as video frames and audio buffers
• transports/transport-amd/ - an implementation of the sample AMD communication protocol.
• util/ - a collection of auxiliary classes for various purposes, such as base components for multimedia pipelines, quality of service (QoS), encryption and statistics
• video/ - a collection of classes related to video-specific tasks, such as video encoding, decoding, post-processing and interfacing between video pipelines and the Transport Layer.
• audio/ - a collection of classes related to audio-specific tasks, such as audio encoding, decoding, resampling, format conversions and interfacing between audio pipelines and the Transport Layer.
• controllers/ - classes related to input devices, such as keyboard, mouse, touch screen and game controller

Streaming SDK samples are located in the samples/ directory:

• RemoteDesktopServer/ - an implementation of a sample server that captures video from the specified display and audio from the default audio output and streams them to one or several clients, while receiving events from the client's keyboard, mouse and game controller, similar to any remote desktop application, using AMD communication protocol.
• SimpleStreamingClient/ - an implementation of a sample client that streams video and audio from the RemoteDesktopServer server sample using AMD communication protocol.

All Streaming SDK reusable code is compiled into ssdk.lib placed into the bin/ directory along with all other binaries produced by the Streaming SDK build.

External Dependencies

Streaming SDK uses Advanced Media Framework (AMF) and MbedTLS for interfacing with video and audio encoding, decoding, color space conversion, video post-processing and AES encryption. These libraries are included as Git submodules and are mapped to the amf/ and mbedtls/ directories respectively.

Streaming SDK relies only on a small portion of functionality provided by AMF and MbetTLS. To minimize build time and code size, only the parts of these libraries used by Streaming SDK are built. CMakeLists.txt files for these libraries are located in the amf-helper-libs/ and mbedtls-custom/ directories. They do not contain any code aside from the Cmake files. Their output is compiled into amf-public.lib and mbedtls-custom.lib libraries.

Dependency on Ffmpeg

AMF relies on Ffmpeg for audio encoding, decoding, resampling and format conversion. The AMF Github repo includes Ffmpeg binaries compiled from the original Ffmpeg code for various platforms.

Due to limitations of the LGPL License Ffmpeg libraries cannot be linked with and have to be loaded dynamically. Therefore, Ffmpeg shared libraries must be placed alongside the executables, so that they could be loaded at runtime. The amf-helper-libs/amf-component-ffmpeg64/CMakeLists.txt copies the required Ffmpeg shared libraries to the destination binary directory. It also builds a dynamic/shared library amf-component-ffmpeg64.dll which much of the AMF open-source code used in Streaming SDK relies on.

The following dynamic/shared libraries must be distributed with your application:

• amf-component-ffmpeg64.dll
• avcodec*.dll
• avdevice*.dll
• avfilter*.dll
• avformat*.dll
• avutil*.dll
• swresample*.dll
• swscale*.dll

NOTE: AMF appends a version suffix to the Ffmpeg libraries file names. Since AMF switches to the most current version of Ffmpeg version from time to time, the version suffix might also change. It is therefore advisable to write your installation scripts using wildcards to avoid changing these scripts when Ffmpeg version is incremented.

Linking Samples and User Applications

Sample applications and your own applications must link with the following libraries:

• bin/<build-configuration>/amf-public.lib
• bin/<build-configuration>/mbedtls-custom.lib
• bin/<build-configuration>/ssdk.lib

IMPORTANT: Depending on the platform and the toolchain you choose to use, the order in which these libraries appear on the linker's command line may or may not matter. The extensions produced by different toolchains might also be different. For instance, the GNU toolchain would append the .a extension instead of .lib. Also, some linkers are unable to resolve forward references between libraries. To avoid linking problems with such toolchains, these libraries must be listed on the linker's command line in the above order.

It is also possible to build Streaming SDK library as a DLL/shared library. To do so, change the library type from STATIC to SHARED in the add_library() statement in the root CMakeLists.txt file for the ssdk library and in amf-helper-libs/CMakeLists.txt and mbedtls-custom/CMakeLists.txt for amf-public and mbedtls-custom.lib respectively. Your application would need to link with the corresponding import libraries on Windows.