Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
OvenMediaEngine supports multiple protocols for input from various live sources, without compromising basic usability. This allows you to publish a variety of live sources with sub-second latency. See the sub-page for more information.
The OME Docker Launcher is a tool that simplifies the process of deploying and managing the OvenMediaEngine (OME) application using Docker containers. This tool can be used by developers and system administrators who want to quickly deploy and test the OME application in a Docker environment.
The OME Docker Launcher provides a set of commands that allow users to easily manage the OME Docker container. These commands include:
This command pulls the OME Docker image(airensoft/ovenmediaengine:latest) from the Docker registry and copies the necessary configuration files to a specified location. This command needs to be run before starting the OME Docker container.
This command creates and starts the Docker container. Once the container is started, the OME application can be accessed through a web browser using the container's IP address.
This command launches a bash shell inside the running OME Docker container, allowing users to execute commands and interact with the container.
This command displays the status of the running OME Docker container, including information such as the container name, and running status.
This command stops the running OME Docker container.
This command stops and then starts the OME Docker container.
Using the OME Docker Launcher, you can easily set up and manage an OME Docker container, without having to manually configure and manage the Docker container. This can save time and effort, especially for users who are not familiar with Docker or who do not want to spend time manually setting up and configuring the OME application.
Run the following command in your Linux shell.
Below is an example of execution:
OME Docker Launcher can be executed in the following format:
setupThe setup command pulls the OME Docker image from the Docker registry and copies the necessary configuration files to the host's /usr/share/ovenmediaengine directory. Additionally, it initializes the log path and crash dump path that will be mounted into the container when it is run.
This command prepares the host environment for running the OME Docker container and sets up the necessary directories and configurations for the container to run correctly.
If you run the "setup" command, the following files and directories will be created:
/usr/share/ovenmediaengine/conf
This directory contains the OME configuration files and is mounted into the container when it is run.
/usr/share/ovenmediaengine/logs
This directory is the log path for OME and is mounted into the container when it is run. Log files generated by OME will be stored in this directory.
/usr/share/ovenmediaengine/dumps
This directory is the crash dump path for OME and is mounted into the container when it is run. Crash dumps generated by OME will be stored in this directory.
If you want to change the configuration of OME, you can edit the /usr/share/ovenmediaengine/conf/Server.xml file. This file contains the server configuration settings for OME, such as the server's IP address, port, and SSL settings. Once you have made changes to this file, you will need to restart the OME Docker container for the changes to take effect. You can do this by running the restart command provided by the OME Docker Launcher.
To install a certificate in OvenMediaEngine, copy the certificate files to /usr/share/ovenmediaengine/conf with the following names:
Certificate
cert.crt
Private Key
cert.key
CA Bundle
cert.ca-bundle
If you want to change the file names, you can modify Server.xml.
startOnce the setup phase is complete, you can use the start command to run the OME Docker container. The start command creates and starts the Docker container, enabling the OME application to receive stream packets using protocols such as RTMP and SRT. Before running the start command, ensure that the necessary configuration files have been copied to the host's /usr/share/ovenmediaengine directory by running the setup command.
shThe sh command allows you to enter into the shell of the running container. You can use this command for troubleshooting purpose. Once you enter into the container's shell, you can execute any commands just like you do in a normal Linux shell. This allows you to inspect the container's internal state and debug any issues that you might be facing with the container or the application running inside it.
statusThe status command shows the current execution status of the container. If the container is running, it displays the ID and name of the container. This command helps you to verify whether the container is up and running or not. If the container is not running, you can use the start command to start the container.
stopThe stop command stops the running container and removes it from the list of Docker containers.
restartThe restart command restarts the container. This is useful when you need to apply changes to the Server.xml.
If you encounter any problems during the execution, try using the -d option in the [OPTIONS] to view detailed logs. This option shows the command sets and their results that are executed internally.
If OME terminates abnormally, providing the crash dump to the OME team can be helpful. The crash dump is stored in the /usr/share/ovenmediaengine/dumps directory, which is created during the setup phase. You can find the dump file named crash_<yyyymmdd>.dump in this directory.
Sharing those log and dump file would be greatly appreciated and helpful for the development of OME.
OvenMediaEngine (OME) is a Sub-Second Latency Live Streaming Server with Large-Scale and High-Definition. With OME, you can create platforms/services/systems that transmit high-definition video to hundreds-thousand viewers with sub-second latency and be scalable, depending on the number of concurrent viewers.
OvenMediaEngine can receive a video/audio, video, or audio source from encoders and cameras such as OvenLiveKit, OBS, XSplit, and more, to WebRTC, SRT, RTMP, MPEG-2 TS, and RTSP as Input. Then, OME transmits this source using LLHLS (Low Latency HLS) and WebRTC as output. Also, we provide OvenPlayer, an Open-Source and JavaScript-based WebRTC/LLHLS Player for OvenMediaEngine.
Our goal is to make it easier for you to build a stable broadcasting/streaming service with sub-second latency.
Ingest
Push: WebRTC, WHIP, SRT, RTMP, MPEG-2 TS
Pull: RTSP
Scheduled Channel (Pre-recorded Live)
Multiplex Channel (Duplicate stream / Mux tracks)
Adaptive Bitrate Streaming (ABR) for HLS, LLHLS and WebRTC
Low-Latency Streaming using LLHLS
DVR (Live Rewind)
Dump for VoD
ID3v2 timed metadata
DRM (Widevine, Fairplay)
Sub-Second Latency Streaming using WebRTC
WebRTC over TCP (with embedded TURN server)
Embedded WebRTC Signaling Server (WebSocket based)
Retransmission with NACK
ULPFEC (Uneven Level Protection Forward Error Correction)
VP8, H.264
In-band FEC (Forward Error Correction)
Opus
HLS (version 3) Streaming support for legacy devices
MPEG-2 TS Container
Audio/Video Muxed
DVR (Live Rewind)
Embedded Live Transcoder
Video: VP8, H.264, H.265(Hardware encoder only), Pass-through
Audio: Opus, AAC, Pass-through
Clustering (Origin-Edge Structure)
Monitoring
Access Control
AdmissionWebhooks
SignedPolicy
File Recording
Push Publishing using SRT, RTMP and MPEG2-TS (Re-streaming)
Thumbnail
REST API
We have tested OvenMediaEngine on platforms, listed below. However, we think it can work with other Linux packages as well:
Ubuntu 18+
Rocky Linux 9+
AlmaLinux 9+
Fedora 28+
Please read Getting Started chapter in the tutorials.
Thank you so much for being so interested in OvenMediaEngine.
We need your help to keep and develop our open-source project, and we want to tell you that you can contribute in many ways. Please see our Guidelines, Rules, and Contribute.
We always hope that OvenMediaEngine will give you good inspiration.
Test Player
Without TLS: http://demo.ovenplayer.com
With TLS: https://demo.ovenplayer.com
OvenMediaEngine is licensed under the AGPL-3.0-only. However, if you need another license, please feel free to email us at contact@airensoft.com.
OvenMediaEngine can work with a variety of open-sources and libraries. First, install them on your clean Linux machine as described below. We think that OME can support most Linux packages, but the tested platforms we use are Ubuntu 18+, Fedora 28+, Rocky Linux 9+, and AlmaLinux 9+.
You can build the OvenMediaEngine source using the following command:
The default configuration uses the following ports, so you need to open it in your firewall settings.
You can open firewall ports as in the following example:
You can set the following environment variables.
When you need to install a certificate in OME or apply a complex configuration, you can do it by following the procedure below to modify Server.xml inside Docker.
OvenMediaEngine docker container loads configuration files from the following path.
There are many ways to change files inside a Docker container, but this document describes how to change them using Docker's bind mounts.
The command below will make your OvenMediaEngine docker container run with $OME_DOCKER_HOME/conf/Server.xml and $OME_DOCKER_HOME/conf/Logger.xml files on your host. It will also create $OME_DOCKER_HOME/logs/ovenmediaengine.log file.
OvenMediaEngine has an XML configuration file. If you start OvenMediaEngine with systemctl start ovenmediaengine, the config file is loaded from the following path.
If you run it directly from the command line, it loads the configuration file from:
If you run it in Docker container, the path to the configuration file is:
The Server is the root element of the configuration file. The versionattribute indicates the version of the configuration file. OvenMediaEngine uses this version information to check if the config file is a compatible version.
The IP address is OvenMediaEngine will bind to. If you set *, all IP addresses of the system are used. If you enter a specific IP, the Host uses that IP only.
PrivacyProtection is an option to comply with GDPR, PIPEDA, CCPA, LGPD, etc. by deleting the client's personal information (IP, Port) from all records. When this option is turned on, the client's IP and Port are converted to xxx.xxx.xxx.xxx:xxx in all logs and REST APIs.
OvenMediaEngine needs to know its public IP in order to connect to the player through WebRTC. The server must inform the player of the IceCandidates and TURN server addresses when signaling, and this information must be the IP the player can connect to. However, in environments such as Docker or AWS, public IP cannot be obtained through a local interface, so a method of obtaining public IP using stun server is provided (available from version 0.11.1).
If OvenMediaEngine obtains the public IP through communication with the set stun server, you can set the public IP by using * or ${PublicIP} in IceCandidate and TcpRelay.
The Bind is the configuration for the server port that will be used. Bind consists of Providers and Publishers. The Providers are the server for stream input, and the Publishers are the server for streaming.
The meaning of each element is shown in the following table:
VirtualHosts are a way to run more than one streaming server on a single machine. OvenMediaEngine supports IP-based virtual host and Domain-based virtual host. "IP-based" means that you can separate streaming servers into multiples by setting different IP addresses, and "Domain-based" means that even if the streaming servers use the same IP address, you can split the streaming servers into multiples by setting different domain names.
VirtualHostsconsist of Name, Host, Origins, SignedPolicy, and Applications.
The Domain has Names and TLS. Names can be either a domain address or an IP address. Setting * means it allows all domains and IP addresses.
Origins (also we called OriginMap) are a feature to pull streams from external servers. It now supports OVT and RTSP for the pulling protocols. OVT is a protocol defined by OvenMediaEngine for Origin-Edge communication. It allows OvenMediaEngine to relay a stream from other OvenMediaEngines that have OVP Publisher turned on. Using RTSP, OvenMediaEngine pulls a stream from an RTSP server and creates a stream. RTSP stream from external servers can stream by WebRTC, HLS, and MPEG-DASH.
The Origin has Location and Pass elements. Location is a URI pattern for incoming requests. If the incoming URL request matches Location, OvenMediaEngine pulls the stream according to a Pass element. In the Pass element, you can set the origin stream's protocol and URLs.
<Application> consists of various elements that can define the operation of the stream, including Stream input, Encoding, and Stream output. In other words, you can create as many <Application> as you like and build various streaming environments.
<Application> needs to set <Name> and <Type> as follows:
<Name> is used to configure the Streaming URL.
<Type> defines the operation of <Application>. Currently, there is only a live type.
<OutputProfile> is a configuration that creates an output stream. Output stream name can be set with <OutputStreamName>, and transcoding properties can be set through <Encodes>. If you want to stream one input to multiple output streams, you can set multiple <OutputProfile>.
Providers ingest streams that come from a media source.
You can configure the Output Stream operation in <Publishers>. <ThreadCount> is the number of threads used by each component responsible for the <Publishers> protocol.
OvenMediaEngine currently supports WebRTC, Low-Latency DASH, MEPG-DASH, and HLS. If you don't want to use any protocol then you can delete that protocol setting, the component for that protocol isn't initialized. As a result, you can save system resources by deleting the settings of unused protocol components.
Finally, Server.xml is configured as follows:
Most browsers can't load resources via HTTP and WS (WebSocket) from HTTPS web pages secured with TLS. Therefore, if the player is on an HTTPS page, the player must request streaming through "https" and "wss" URLs secured with TLS. In this case, you must apply the TLS certificate to the OvenMediaEngine.
You can set the port for TLS in TLSPort. Currently, LLHLS and WebRTC Signaling support TLS.
Add your certificate files to as follows:
To enable HTTP for HLS and WebRTC signaling servers, you must enable the TLS element and install the certificate file in PEM format. This involves indicating a server certificate through the CertPath, as well as a private key file through the KeyPath. These paths can be specified as either absolute or relative paths from the executable. However, if the server certificate was issued using an intermediate certificate, some browsers may raise concerns about the certificate's authenticity. To address this, a bundle of chained certificates provided by a Certificate Authority can be set in the ChainCertPath.
Starting from version OME v0.15.1, IPv6 is supported.
To use IPv6, you need to change the settings of the Server.xml file as follows:
You can use /Server/IP to support IPv6. In versions prior to v0.15.0, only one /Server/IP setting could be specified, but in versions after v0.15.1, multiple settings can be specified. That is, if you add an /Server/IP element for IPv6 to the existing configuration as follows, you can accept IPv6 requests from clients:
OME listens to the 1935 port for RTMP as follows:
OME listens to the 1935 port for RTMP as follows:
OME listens to the 1935 port for RTMP as follows:
IceCandidates (for WebRTC)When you specify IPv6 interface /Server/IP, most Providers/Publishers will work with IPv6, but WebRTC will not. While the WebSocket server used as the WebRTC Signalling server works well with the above setting, but more setting is required for ICE Candidates that actually transmit/receive data.
To use IPv6 ICE Candidate, you need to add an IPv6 IceCandidate to /Server/Bind/(Providers|Publishers)/WebRTC/IceCandidates.
By setting up as above, OME is ready to use ICE Candidates for IPv6 as well as IPv4. The ICE Candidate generated here can be viewed in the signaling step of the web browser.
<Origin>Now you can set up the OME edge to look at an origin with an IPv6 IP address. To do this, you can set /Server/VirtualHosts/VirtualHost/Origins/Origin/Pass/Urls/Url as follows:
This configuration creates a stream that refers an RTSP source provided on port 1234 of an origin which has an IPv6 address of 1:2:3:4:5:6:7:8.
<AdmissionWebhooks>You can also specify an IPv6 address for the server that AdmissionWebhooks is using. To do this, set the value of /Server/VirtualHosts/VirtualHost/AdmissionWebhooks/ControlServerUrl as follows:
The above configuration asks whether the client has the permission to publish or playback using http://[1:2:3:4:5:6:7:8]:7000/a/b/c.
OvenMediaEngine provides Docker images from AirenSoft's Docker Hub (airensoft/ovenmediaengine) repository. You can easily use OvenMediaEngine server by using Docker image. See for details.
If the prerequisites.sh script fails, try to run sudo apt-get update and rerun it. If it's not enough proceed with the .
if systemctl start ovenmediaengine fails in Fedora, SELinux may be the cause. See .
To use TLS, you must set up a certificate. See for more information.
OvenMediaEngine provides the Docker image from (airensoft/ovenmediaengine) repository. After installing , you can simply run the following command:
If a certificate is not installed in OvenMediaEngine, some functions (WebRTC Ingest, LLHLS playback) may not work due to the browser's security policy. Please refer to section to install the certificate.
Copy your PEM certificate files to the path below if you need to enable TLS. The destination file names must match if using the default configuration. If you want to change the file name, you can do so by editing the Server.xml configuration file. See for details.
SignedPolicy is a module that limits the user's privileges and time. For example, operators can distribute RTMP URLs that can be accessed for 60 seconds to authorized users, and limit RTMP transmission to 1 hour. The provided URL will be destroyed after 60 seconds, and transmission will automatically stop after 1 hour. Users who are provided with a SingedPolicy URL cannot access resources other than the provided URL. This is because the SignedPolicy URL is authenticated. See the chapter for more information.
To run the Edge server, Origin creates application and stream if there isn't those when user request. For more learn about Origin-Edge, see the chapter.
For more information about the OutputProfiles, please see the chapter.
If you want to get more information about the <Providers>, please refer to the chapter.
If you want to learn more about WebRTC, visit the chapter. And if you want to get more information on Low-Latency DASH, MPEG-DASH, and HLS, refer to the chapter on .
Assuming the certificate settings are correctly configured, WebRTC streaming can then be played via the wss://url protocol, while LLHLS streaming can be accessed via .
1935/TCP
RTMP Input
9999/UDP
SRT Input
4000/UDP
MPEG-2 TS Input
9000/TCP
Origin Server (OVT)
3333/TCP 3334/TLS
LLHLS Streaming * Streaming over Non-TLS is not allowed with modern browsers.
3333/TCP 3334/TLS
WebRTC Signaling (both ingest and streaming)
3478/TCP
WebRTC TCP relay (TURN Server, both ingest and streaming)
10000 - 10009/UDP
WebRTC Ice candidate (both ingest and streaming)
OME_HOST_IP
*
OME_ORIGIN_PORT
9000
OME_RTMP_PROV_PORT
1935
OME_SRT_PROV_PORT
9999/udp
OME_MPEGTS_PROV_PORT
4000/udp
OME_LLHLS_STREAM_PORT
3333
OME_LLHLS_STREAM_TLS_PORT
3334
OME_WEBRTC_SIGNALLING_PORT
3333
OME_WEBRTC_SIGNALLING_TLS_PORT
3334
OME_WEBRTC_TCP_RELAY_PORT
3478
OME_WEBRTC_CANDIDATE_PORT
10000-10004/udp
Server.xml
/opt/ovenmediaengine/bin/origin_conf/Server.xml
Logger.xml
/opt/ovenmediaengine/bin/origin_conf/Logger.xml
Server Certificate
/opt/ovenmediaengine/bin/origin_conf/cert.crt
Server certificate file in PEM format. The intermediate certificate must not be included.
Private Key
/opt/ovenmediaengine/bin/origin_conf/cert.key
This is the private key file of the certificate.
CA Bundle
/opt/ovenmediaengine/bin/origin_conf/cert.ca-bundle
A file containing root and intermediate certificates.
<Managers><API>
REST API Server port
RTMP
RTMP port for incoming RTMP stream.
SRT
SRT port for incoming SRT stream
MPEG-TS
MPEGTS ports for incoming MPEGTS/UDP stream.
WebRTC
Port for WebRTC. If you want more information on the WebRTC port, see the WebRTC Ingest and WebRTC Streaming chapters.
OVT
OVT port for an origin server.
OVT is a protocol defined by OvenMediaEngine for Origin-Edge communication. For more information about Origin-Edge, see the Origin-Edge Clustering chapter.
LLHLS
HTTP(s) port for LLHLS streaming.
Providers ingests streams that come from a media source. OvenMediaEngine supports RTMP protocol. You can set it in the configuration as follows:
When a live source inputs to the <Application>, a stream is automatically created in the <Application>. The created stream is passed to Encoder and Publisher.
If you set up a live stream using an RTMP-based encoder, you need to set the following in Server.xml:
<BlockDuplicateStreamName> is a policy for streams that are inputted as overlaps.
<BlockDuplicateStreamName> works with the following rules:
If you want to publish the source stream, you need to set the following in the Encoder:
URL RTMP://<OvenMediaEngine IP>[:<RTMP Listen Port>]/<App Name]>
Stream Key Stream Name
If you use the default configuration, the <RTMP><ListenPort> is 1935, which is the default port for RTMP. So it can be omitted. Also, since the Application named app is created by default in the default configuration, you can enter app in the [App Name]. You can define a Stream Key and use it in the Encoder, and the Streaming URL will change according to the Stream Key.
Moreover, some encoders can include a stream key in the URL, and if you use these encoders, you need to set it as follows:
URL RTMP://<OvenMediaEngine IP>[:<RTMP Listen Port>/<App Name>/<Stream Name>
If you are using the default configuration, press the URL button in the top right corner of OvenStreamEnoder, and enter the URL as shown below:
Also, <App name> and <Stream name> can be changed and used as desired in the configuration.
If you use the default configuration, set the OBS as follows:
You can set the Stream Key to any name you like at any time.
true
Default Rejects the new stream inputted as overlap and maintains the existing stream.
false
Accepts a new stream inputted as overlap and disconnects the existing stream.
Secure Reliable Transport (or SRT in short) is an open source video transport protocol and technology stack that optimizes streaming performance across unpredictable networks with secure streams and easy firewall traversal, bringing the best quality live video over the worst networks. We consider SRT to be one of the great alternatives to RTMP, and OvenMediaEngine can receive video streaming over SRT. For more information on SRT, please visit the SRT Alliance website.
SRT uses the MPEG-TS format when transmitting live streams. This means that unlike RTMP, it can support many codecs. Currently, OvenMediaEngine supports H.264, H.265, and AAC codecs received by SRT.
Set the SRT listen port as follows:
SRT input can be turned on/off for each application. As follows Setting enables the SRT input function of the application.
There are various encoders that support SRT such as FFMPEG, OBS Studio, and srt-live-transmit. Please check the specifications of each encoder on how to transmit streams through SRT from the encoder. We describe an example using OBS Studio.
OvenMediaEngine classifies each stream using SRT's streamid. This means that unlike MEPG-TS/udp, OvenMediaEngine can receive multiple SRT streams through one port. For more information on streamid, see Haivision's official documentation.
Therefore, in order for the SRT encoder to transmit a stream to OvenMediaEngine, the following information must be included in the streamid as percent encoded.
streamid = percent_encoding("srt://{host}[:port]/{app name}/{stream name}[?query=value]")
The streamid contains the URL format, so it must be percent encoded****
OBS Studio 25.0 or later supports SRT. Please refer to the OBS official documentation for more information. Enter the address of OvenMediaEngine in OBS Studio's Server as follows: When using SRT in OBS, leave the Stream Key blank.
srt://{full domain or IP address}:port?streamid=srt%3A%2F%2F{full domain or IP address}[%3APort]%2F{App name}%2F{Stream name}&latency=2000000
The streamid has to be the urlencoded address of the server name as specified in the ome server configuration plus the app name and the stream name, each separated by /. The latency configures the size of the server-side recive buffer and the time limit for SRT in nanoseconds. Typical value for latency are 150000 (150ms) for stremaing to a server in the local network, 600000 (600ms) for streaming to a server over the internet in the local region, and 2000000 (2 seconds) when stremaing over long distance.
For configuring a Blackmagic Web Presenter, ATEM Mini Pro or similar device to stream to OvenMediaEngine over SRT, choose the "Custom URL H264/H265" platform option with the following syntax:
The default streaming profiles work well, and there are more advanced configuration options available if you edit the streaming.xml settings file
You can configure SRT's socket options of the OvenMediaEngine server using <Options>. This is particularly useful when setting the encryption for SRT, and you can specify a passphrase by configuring as follows:
For more information on SRT socket options, please refer to https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#list-of-options.
This page provides the fastest way to check playback of WebRTC and LLHLS using OvenMediaEngine. For installation and detailed settings, please refer to other pages.
Run docker with the command below. OME_HOST_IP must be an IP address accessible by the player.
Publish your live stream to OvenMediaEngine using a live encoder like OBS.
The RTMP publishing address is :
Server rtmp://Your.Docker.Host.IP:1935/app
Stream Key stream
The settings below are recommended for ultra-low latency.
Keyframe Interval
1s (DO NOT set it to 0)
CPU Usage Preset
ultrafast
Profile
baseline
Tune
zerolatency
Open the installed OvenPlayer Demo page in your browser.
http://Your.Docker.Host.IP:8090/
Add ws://Your.Docker.Host.IP:3333/app/stream to the Playback URL and click the ADD SOURCE and LOAD PLAYER button to play the live stream with WebRTC.
Add http://Your.Docker.Host.IP:3333/app/stream/llhls.m3u8 to the Playback URL and click the ADD SOURCE and LOAD PLAYER button to play the live stream with LLHLS.
We provide online demos of OvenPlayer(WebRTC/LLHLS Player) and OvenLiveKit(WebRTC Live Encoder) so that users can easily test out OvenMediaEngine.
To connect to your OvenMediaEngine in the online demo, you will need to install a certificate and use either the HTTPS or WSS protocol. Unsecured HTTP or WS protocols could not work in online demos due to browser security policies.
Site URL
Description
OvenPlayer demo (TLS not enabled)
OvenPlayer demo
OvenLiveKit (WebRTC Live Encoder) demo
OvenSpace offers a fast and easy way to experience the powerful tools of OvenMediaEngine, OvenPlayer, and OvenLiveKit in action.
With OvenSpace, you can quickly and easily stream content with sub-second latency using WebRTC technology, or take advantage of Apple's LLHLS specification to deliver low-latency live streaming. The platform allows you to stream from various sources, including your webcam, microphone, screen, or an external live encoder that supports RTMP and SRT.
OvenSpace is available online, so you can try it out for yourself at https://space.ovenplayer.com/. You'll get a hands-on experience of how OvenMediaEngine, OvenPlayer, and OvenLiveKit work together seamlessly to deliver top-quality streaming, whether you're a developer looking to build a media service or someone who wants to experience sub-second or low-latency streaming firsthand.
OvenSpace is also available on Github as open source. It will be a good reference when developing media services using OvenMediaEngine, OvenPlayer and OvenLiveKit.
From version 0.10.4, MPEG-2 TS input is supported. The supported codecs are H.264, AAC(ADTS). Supported codecs will continue to be added. And the current version only supports basic MPEG-2 TS with 188 bytes packet size. Since the information about the input stream is obtained using PAT and PMT, the client must send this table information as required.
To enable MPEG-2 TS, you must bind the ports fist and map the bound ports and streams.
To use multiple streams, it is necessary to bind multiple ports, so we provide a way to bind multiple ports as in the example below. You can use the dash to specify the port as a range, such as Start port-End port, and multiple ports using commas.
First, name the stream and map the port bound above. The macro ${Port} is provided to map multiple streams at once. Check out the example below.
This is an example of publishing using FFMPEG.
OvenMediaEngine can pull RTSP Stream in two ways. The first way is to use the Stream creation API, and the second way is to use OriginMap or OriginMapStore. The supported codecs are H.264, AAC(ADTS). Supported codecs will continue to be added.
You can create a stream by pulling an RTSP stream using the Stream Creation API. For more information on using the REST API, check out that chapter.
If OriginMapStore is configured and Redis Server provides an rtsp URL, OvenMediaEngine pulls the RTSP URL when a playback request comes in. Check out OriginMapStore for more details.
RTSP Pull is provided through OriginMap configuration. OriginMap is the rule that the Edge server pulls the stream of the Origin server. Edge server can pull a stream of origin with RTSP and OVT (protocol defined by OvenMediaEngine for Origin-Edge) protocol. See the Clustering section for more information about OVT.
For example, in the above setup, when a player requests "ws://ome.com/app_name/rtsp_stream_name" to stream WebRTC, it pulls the stream from "rtsp://192.168.0.200:554" and publishes it to WebRTC.
If the app name set in Location isn't created, OvenMediaEngine creates the app with default settings. The default generated app doesn't have an OPUS encoding profile, so to use WebRTC streaming, you need to add the app to your configuration.
Pulling type providers are activated by streaming requests from publishers. And by default, the provider is automatically disabled after 30 seconds of no client playback. If you want to change this setting, check out the Clustering chapter.
When a playback request comes in from the following URL, RTSP pull starts working according to Origins settings.
Protocol
URL
WebRTC
ws[s]:://host.com[:port]/app_name/rtsp_stream_name
LLHLS
http[s]://host.com[:port]/app_name/rtsp_stream_name/llhls.m3u8
Scheduled Channel that allows you to create a live channel by scheduling pre-recorded files has been added to OvenMediaEngine. Other services or software call this Pre-recorded Live or File Live, but OvenMediaEngine plans to expand the function to organize live channels as a source, so we named it Scheduled Channel.
To use this feature, activate Schedule Provider as follows.
MediaRootDir
Root path where media files are located. If you specify a relative path, the directory where the config file is located is root.
ScheduleFileDir
Root path where the schedule file is located. If you specify a relative path, the directory where the config file is located is root.
Scheduled Channel creates/updates/deletes streams by creating/editing/deleting files with the .sch extension in the ScheduleFileDir path. Schedule files (.sch) use the following XML format. When a <Stream Name>.sch file is created in ScheduleFileDir, OvenMediaEngine analyzes the file and creates a Schedule Channel with <Stream Name>. If the contents of <Stream Name>.sch are changed, the Schedule Channel is updated, and if the file is deleted, the stream is deleted.
Stream (required)
This is the stream information that the Channel needs to create.
Stream.Name (optional)
It's the stream's name. This is a reference value extracted from the file name for usage. It's recommended to set it same for consistency, although it's for reference purposes.
Stream.BypassTranscoder (optional, default: false)
Set to true if transcoding is not desired.
Stream.VideoTrack (optional, default: true)
Determines whether to use the video track. If VideoTrack is set to true and there's no video track in the Item, an error will occur.
Stream.AudioTrack (optional, default: true)
Determines whether to use the audio track. If AudioTrack is set to true and there's no audio track in the Item, an error will occur.
FallbackProgram (optional)
It is a program that switches automatically when there is no program scheduled at the current time or an error occurs in an item. If the program is updated at the current time or the item returns to normal, it will fail back to the original program. Both files and live can be used for items in FallbackProgram. However, it is recommended to use a stable file.
Program (optional)
Schedules a program. The name is an optional reference value. If not set, a random name will be assigned. Set the start time in ISO8601 format in the scheduled attribute. Decide whether to repeat the Items when its playback ends.
Program.Item (optional)
Configures the media source to broadcast.
The url points to the location of the media source. If it starts with file://, it refers to a file within the MediaRootDir directory. If it starts with stream://, it refers to another stream within the same OvenMediaEngine. stream:// has the following format: stream://vhost_name/app_name/stream_name
For 'file' cases, the start attribute can be set in milliseconds to indicate where in the file playback should start.
duration indicates the playback time of that item in milliseconds. After the duration ends, it moves to the next item.
Both 'start' and 'duration' are optional. If not set, start defaults to 0, and duration defaults to the file's duration; if not specified, the media file will be played until its full duration.
This function is a scheduling channel, but it can be used for applications such as creating a permanent stream as follows.
This channel normally plays default/app/input, but when live input is stopped, it plays the file in FallbackProgram. This will last forever until the .sch file is deleted. One trick was to set the origin program's schedule time to year 2000 so that this stream would play unconditionally.
You may experience some buffering when going from file to live. This is unavoidable due to the nature of the function and low latency. If this is inconvenient, buffering issues can disappear if you add a little delay in advance by setting PartHoldBack in LLHLS to 5 or more. It is a choice between delay and buffering.
ScheduledChannel can also be controlled via API. Please refer to the page below.
User can send video/audio from web browser to OvenMediaEngine via WebRTC without plug-in. Of course, you can use any encoder that supports WebRTC transmission as well as a browser.
OvenMediaEngine supports self-defined signaling protocol and WHIP for WebRTC ingest.
You can set the port to use for signaling in <Bind><Provider><WebRTC><Signaling>. <Port> is for setting an unsecured HTTP port, and <TLSPort> is for setting a secured HTTP port that is encrypted with TLS.
For WebRTC ingest, you must set the ICE candidates of the OvenMediaEnigne server to <IceCandidates>. The candidates set in <IceCandate> are delivered to the WebRTC peer, and the peer requests communication with this candidate. Therefore, you must set the IP that the peer can access. If the IP is specified as *, OvenMediaEngine gathers all IPs of the server and delivers them to the peer.
<TcpRelay> means OvenMediaEngine's built-in TURN Server. When this is enabled, the address of this turn server is passed to the peer via self-defined signaling protocol or WHIP, and the peer communicates with this turn server over TCP. This allows OvenMediaEngine to support WebRTC/TCP itself. For more information on URL settings, check out WebRTC over TCP.
WebRTC input can be turned on/off for each application. As follows Setting enables the WebRTC input function of the application. The <CrossDomains> setting is used in WebRTC signaling.
OvenMediaEnigne supports self-defined signaling protocol and WHIP for WebRTC ingest.
The signaling URL for WebRTC ingest uses the query string ?direction=send as follows to distinguish it from the url for WebRTC playback. Since the self-defined WebRTC signaling protocol is based on WebSocket, you must specify ws[s] as the scheme.
ws[s]://<host>[:signaling port]/<app name>/<stream name>?direction=send
For ingest from the WHIP client, put ?direction=whip in the query string in the signaling URL as in the example below. Since WHIP is based on HTTP, you must specify http[s] as the scheme.
http[s]://<host>[:signaling port]/<app name>/<stream name>?direction=whip
WebRTC transmission is sensitive to packet loss because it affects all players who access the stream. Therefore, it is recommended to provide WebRTC transmission over TCP. OvenMediaEngine has a built-in TURN server for WebRTC/TCP, and receives or transmits streams using the TCP session that the player's TURN client connects to the TURN server as it is. To use WebRTC/TCP, use transport=tcp query string as in WebRTC playback. See WebRTC/tcp playback for more information.
ws[s]://<host>[:port]/<app name>/<stream name>?direction=send&transport=tcp
http[s]://<host>[:port]/<app name>/<stream name>?direction=whip&transport=tcp
To use WebRTC/tcp, <TcpRelay> must be turned on in <Bind> setting.
If <TcpForce> is set to true, it works over TCP even if you omit the ?transport=tcp query string from the URL.
We provide a demo page so you can easily test your WebRTC input. You can access the demo page at the URL below.
The getUserMedia API to access the local device only works in a secure context. So, the WebRTC Input demo page can only work on the https site **** https://demo.ovenplayer.com/demo_input.html. This means that due to mixed content you have to install the certificate in OvenMediaEngine and use the signaling URL as wss to test this. If you can't install the certificate in OvenMediaEngine, you can temporarily test it by allowing the insecure content of the demo.ovenplayer.com URL in your browser.
To create a custom WebRTC Producer, you need to implement OvenMediaEngine's Self-defined Signaling Protocol or WHIP. Self-defined protocol is structured in a simple format and uses the same method as WebRTC Streaming.
When the player connects to ws[s]://host:port/app/stream?direction=send through a web socket and sends a request offer command, the server responds to the offer sdp. If transport=tcp exists in the query string of the URL, iceServers information is included in offer sdp, which contains the information of OvenMediaEngine's built-in TURN server, so you need to set this in RTCPeerConnection to use WebRTC/TCP. The player then setsRemoteDescription and addIceCandidate offer sdp, generates an answer sdp, and responds to the server.
Most browsers and players prohibit accessing other domain resources in the currently running domain. You can control this situation through Cross-Origin Resource Sharing (CORS) or Cross-Domain (CrossDomain). You can set CORS and Cross-Domain as <CrossDomains> element.
CrossDomain settings are available for HTTP-based APIs, HLS, LLHLS, and Thumnail.
You can set it using the <Url> element as shown above, and you can use the following values:
*
Allows requests from all Domains
domain
Allows both HTTP and HTTPS requests from the specified Domain
http://domain
Allows HTTP requests from the specified Domain
https://domain
Allows HTTPS requests from the specified Domain
You can respond with custom HTTP headers via <CrossDomains>. You can use them by adding multiple <Header><Key> and <Header><Value> as in the example above.
OvenMediaEngine has a built-in live transcoder. The live transcoder can decode the incoming live source and re-encode it with the set codec or adjust the quality to encode at multiple bitrates.
Video
VP8, H.264, H.265
Audio
AAC, Opus
Video
VP8
vp8
H.264
h264 (Automatic Codec Selection)
x264
h264_x264
OpenH264
h264_openh264
NVIDIA Hardware
h264_nvenc
Intel Hardware
h264_qsv
Xilinx Hardware
h264_xma
NetInt Hardware
h264_nilogan
H.265
h265 (Automatic Codec Selection)
NVIDIA Hardware
h265_nvenc
Intel Hardware
h265_qsv
Xilinx Hardware
h265_xma
NetInt Hardware
h265_nilogan
Audio
AAC
aac
Opus
opus
Image
JPEG
jpeg
PNG
png
The <OutputProfile> setting allows incoming streams to be re-encoded via the <Encodes> setting to create a new output stream. The name of the new output stream is determined by the rules set in <OutputStreamName>, and the newly created stream can be used according to the streaming URL format.
According to the above setting, if the incoming stream name is stream, the output stream becomes stream_bypassand the stream URL can be used as follows.
WebRTC ws://192.168.0.1:3333/app/stream_bypass
LLHLS http://192.168.0.1:8080/app/stream_bypass/llhls.m3u8
HLS http://192.168.0.1:8080/app/stream_bypass/ts:playlist.m3u8
You can set the video profile as below:
The meaning of each property is as follows:
Codec*
Specifies the vp8 or h264 codec to use
Bitrate*
Bit per second
Name*
Encode name for Renditions
Width
Width of resolution
Height
Height of resolution
Framerate
Frames per second
KeyFrameInterval
Number of frames between two keyframes (0~600) default is framerate (i.e. 1 second)
BFrames
Number of B-frames (0~16) default is 0
Profile
H264 only encoding profile (baseline, main, high)
Preset
Presets of encoding quality and performance
ThreadCount
Number of threads in encoding
Lookahead
Number of frames to look ahead default is 0 x264 is 0-250
nvenc is 0-31 xma is 0-20
* required
Table of presets
A table in which presets provided for each codec library are mapped to OvenMediaEngine presets. Slow presets are of good quality and use a lot of resources, whereas Fast presets have lower quality and better performance. It can be set according to your own system environment and service purpose.
slower
QP( 10-39)
p7
No Support
best
slow
QP (16-45)
p6
No Support
best
medium
QP (24-51)
p5
No Support
good
fast
QP (32-51)
p4
No Support
realtime
faster
QP (40-51)
p3
No Support
realtime
References
https://trac.ffmpeg.org/wiki/Encode/VP8
https://docs.nvidia.com/video-technologies/video-codec-sdk/nvenc-preset-migration-guide/
You can set the audio profile as below:
The meaning of each property is as follows:
Codec*
Specifies the opus or aac codec to use
Bitrate*
Bits per second
Name
Encode name for Renditions
Samplerate
Samples per second
Channel
The number of audio channels
* required
It is possible to have an audio only output profile by specifying the Audio profile and omitting a Video one.
You can set the Image profile as below:
The meaning of each property is as follows:
Codec
Specifies the jpeg or png codec to use
Width
Width of resolution
Height
Height of resolution
Framerate
Frames per second
The image encoding profile is only used by thumbnail publishers. and, bypass option is not supported.
You can configure Video and Audio to bypass transcoding as follows:
You need to consider codec compatibility with some browsers. For example, chrome only supports OPUS codec for audio to play WebRTC stream. If you set to bypass incoming audio, it can't play on chrome.
WebRTC doesn't support AAC, so if video bypasses transcoding, audio must be encoded in OPUS.
If the codec or quality of the input stream is the same as the profile to be encoded into the output stream. there is no need to perform re-transcoding while unnecessarily consuming a lot of system resources. If the quality of the input track matches all the conditions of BypassIfMatch, it will be Pass-through without encoding
Codec (Optional)
eq
Compare video codecs
Width (Optional)
eq, lte, gte
Compare horizontal pixel of video resolution
Height (Optional)
eq, lte, gte
Compare vertical pixel of video resolution
SAR (Optional)
eq
Compare ratio of video resolution
* eq: equal to / lte: less than or equal to / gte: greater than or equal to
Codec (Optional)
eq
Compare audio codecs
Samplerate (Optional)
eq, lte, gte
Compare sampling rate of audio
Channel (Optional)
eq, lte, gte
Compare number of channels in audio
* eq: equal to / lte: less than or equal to / gte: greater than or equal to
To support WebRTC and LLHLS, AAC and Opus codecs must be supported at the same time. Use the settings below to reduce unnecessary audio encoding.
If a video track with a lower quality than the encoding option is input, unnecessary upscaling can be prevented. SAR (Storage Aspect Ratio) is the ratio of original pixels. In the example below, even if the width and height of the original video are smaller than or equal to the width and height set in the encoding option, if the ratio is different, it means that encoding is performed without bypassing.
If you want to transcode with the same quality as the original. See the sample below for possible parameters that OME supports to keep original. If you remove the Width, Height, Framerate, Samplerate, and Channel parameters. then, It is transcoded with the same options as the original.
To change the video resolution when transcoding, use the values of width and height in the Video encode option. If you don't know the resolution of the original, it will be difficult to keep the aspect ratio after transcoding. Please use the following methods to solve these problems. For example, if you input only the Width value in the Video encoding option, the Height value is automatically generated according to the ratio of the original video.
The software decoder uses 2 threads by default. If the CPU speed is too low for decoding, increasing the thread count can improve performance.
For use cases without video (re)encoding, OME can be set to only decode the keyframes of incoming streams. This is a massive performance increase when all you are using the encoder for is generating thumbnails.
To set OME to only decode keyframes, all of your encoder Output Profiles must be set to true set true.
Supported since OvenmediaEngine version 0.18.0
From version 0.14.0, OvenMediaEngine can encode same source with multiple bitrates renditions and deliver it to the player.
As shown in the example configuration below, you can provide ABR by adding <Playlists> to <OutputProfile>. There can be multiple playlists, and each playlist can be accessed with <FileName>.
The method to access the playlist set through LLHLS is as follows.
http[s]://<domain>[:port]/<app>/<stream>/<FileName>.m3u8
The method to access the playlist set through HLS is as follows.
http[s]://<domain>[:port]/<app>/<stream>/<FileName>.m3u8?format=ts
The method to access the Playlist set through WebRTC is as follows.
ws[s]://<domain>[:port]/<app>/<stream>/<FileName>
Note that <FileName> must never contain the playlist and chunklist keywords. This is a reserved word used inside the system.
To set up <Rendition>, you need to add <Name> to the elements of <Encodes>. Connect the set <Name> into <Rendition><Video> or <Rendition><Audio>.
In the example below, three quality renditions are provided and the URL to play the abr playlist as LLHLS is https://domain:port/app/stream/abr.m3u8 and The WebRTC playback URL is wss://domain:port/app/stream/abr
Even if you set up multiple codecs, there is a codec that matches each streaming protocol supported by OME, so it can automatically select and stream codecs that match the protocol. However, if you don't set a codec that matches the streaming protocol you want to use, it won't be streamed.
The following is a list of codecs that match each streaming protocol:
WebRTC
VP8, H.264, Opus
LLHLS
H.264, H.265, AAC
Therefore, you set it up as shown in the table. If you want to stream using LLHLS, you need to set up H.264, H.265 and AAC, and if you want to stream using WebRTC, you need to set up Opus.
Also, if you are going to use WebRTC on all platforms, you need to configure both VP8 and H.264. This is because different codecs are supported for each browser, for example, VP8 only, H264 only, or both.
However, don't worry. If you set the codecs correctly, OME automatically sends the stream of codecs requested by the browser.
Beta
HLS is still in development and some features such as SignedPolicy and AdmissionWebhooks are not supported.
HLS based on MPEG-2 TS containers is still useful because it provides high compatibility, including support for older devices. Therefore, OvenMediaEngine decided to officially support HLS version 7+ based on fragmented MP4 containers, called LL-HLS, as well as HLS version 3+ based on MPEG-2 TS containers.
To use HLS, you need to add the <HLS> elements to the <Publishers> in the configuration as shown in the following example.
HLS is ready when a live source is inputted and a stream is created. Viewers can stream using OvenPlayer or other players.
HLS Publisher basically creates a playlist.m3u8 Playlist using the first video track and the first audio track. When you create a stream, as shown above, you can play HLS with the following URL:
http[s]://domain[:port]/<app name>/<stream name>/ts:playlist.m3u8
If you use the default configuration, you can start streaming with the following URL:
https://domain:3334/app/<stream name>/ts:playlist.m3u8
HLS can deliver adaptive bitrate streaming. OME encodes the same source with multiple renditions and delivers it to the players. And HLS Player, including OvenPlayer, selects the best quality rendition according to its network environment. Of course, these players also provide option for users to manually select rendition.
HLS Publisher basically creates a playlist.m3u8 Playlist using the first video track and the first audio track. If you want to create a new playlist for ABR, you can add it to Server.xml as follows:
You can create as long a playlist as you want by setting <DVR> to the HLS publisher as shown below. This allows the player to rewind the live stream and play older segments. OvenMediaEngine stores and uses old segments in a file in <DVR><TempStoragePath> to prevent excessive memory usage. It stores as much as <DVR><MaxDuration> and the unit is seconds.
OvenMediaEngine supports GPU-based hardware decoding and encoding. Currently supported GPU acceleration devices are Intel's QuickSync and NVIDIA. This article explains how to install the drivers for OvenMediaEngine and set up the configuration to use your GPU.
Please refer to the link for how to build and run.
To use hardware acceleration, set the HardwareAcceleration option to true under OutputProfiles. If this option is enabled, a hardware codec is automatically used when creating a stream, and if it is unavailable due to insufficient hardware resources, it is replaced with a software codec.
The codecs available using hardware accelerators in OvenMediaEngine are as shown in the table below. Different GPUs support different codecs. If the hardware codec is not available, you should check if your GPU device supports the codec.
D : Decoding, E : Encoding
SignedPolicy is a module that limits the user's privileges and time. For example, operators can distribute RTMP URLs that can be accessed for 60 seconds to authorized users, and limit RTMP transmission to 1 hour. The provided URL will be destroyed after 60 seconds, and transmission will automatically stop after 1 hour. Users who are provided with a SignedPolicy URL cannot access resources other than the provided URL. This is because the SignedPolicy URL is authenticated.
SignedPolicy URL consists of the query string of the streaming URL with Policy and Signature as shown below. If SignedPolicy is enabled in the configuration of OvenMediaEngine, access to URLs with no signature or invalid signature is not allowed. Signature uses HMAC-SHA1 to authenticate all URLs except signature.
Policy is in json format and provides the following properties.
The URL entered into HMAC to generate the Signature must include :port.
When creating a signature, you cannot omit the default port such as http port 80, https port 443, or rtmp port 1935. This is because when OvenMediaEngine creates a signature for checking the signature, it is created by putting the port value.
When using SignedPolicy with SRT providers, only use the streamid portion of the URL, e.g. srt://myserver:9999?streamid=srt://myserver:9999/app/stream?policy=abc123
To enable SignedPolicy, you need to add the following <SignedPolicy> setting in Server.xml under <VirtualHost>.
We provide a script that can easily generate SignedPolicy URL. The script can be found in the path below.
Here's how to use this script:
For example, you can use it like this:
Policy encoded with Base64URL is added as a query string to the existing streaming URL. (The query string key is set in Server.xml.)
Signature hashes the entire URL including the policy in HMAC (SHA-1) method, encodes it as Base64URL, and includes it in the query string.
Create a hash using the secret key (1kU^b6 in the example) and the URL above using HMAC-SHA1.
If you include it as a signature query string (query string key is set in Server.xml), the following SignedPolicy URL is finally generated.
Generate SignedPolicy URL with the script.
Separate the URL based on "app" as shown in the example below and enter all the parts under the stream in the Stream Key.
Now with Multiplex Channel, you can configure ABR by combining multiple input streams into one, or duplicate external streams and send them to other applications.
Multiplex Channel takes tracks from other local streams and organizes them into its own tracks. This will pull in tracks that have already been encoded, which can be useful if you want to change codecs or adjust the quality once again. And the Multiplex Channel is sent to the publisher, unconditionally bypassing the encoder.
To use this feature, enable Multiplex Provider in Server.xml.
Multiplex Channels are created through .mux files or API. MuxFilesDir is the path where the .mux files are located and can be set to an absolute system path or relative to the path where the Server.xml configuration is located.
The Multiplex Provider monitors the MuxFilesDir path, and when a mux file is created, it parses the file and creates a multiplex channel. When the mux file is modified, the channel is deleted and created again, and when the mux file is deleted, the channel is deleted.
mux files can be created or deleted while the system is running. This works dynamically. The mux file has the format below.
OutputStream
This is information about the stream to be newly created. It must be the same as the file name. <stream name>.mux
SourceStreams
Specifies the internal stream to be muxed. You can also load streams from other VHosts or applications in the format stream://<vhost name>/<app name>/<stream name>. Because multiple streams are muxed into one stream, track names may be duplicated. Therefore, it is necessary to change the Track name for each SourceStream through <TrackMap>. <SourceTrackName> is either <OutputProfile><Encodes><Video><Name> or <OutputProfile><Encodes><Audio><Name>.
Playlist
The same format as <OutputProfile> must be used, and the Playlist must be constructed using the newly mapped Track name in SourceStreams' TrackMap. The Playlist configured here exists only in this stream. The Playlist's FileName must be unique throughout the application.
MultiplexChannel can also be controlled via API. Please refer to the page below.
Safari Native Player only provides the Seek UI if #EXT-X-PLAYLIST-TYPE: EVENT is present. Since it is specified that nothing can be removed from the playlist when it is of type EVENT, you must call the to switch to VoD or terminate the stream before MaxDuration is exceeded if you use this option. Otherwise, unexpected behavior may occur in the Safari Player.
If your input stream is already h.264/aac, you can use the input stream as is like below. If not, or if you want to change the encoding quality, you can do .
We have prepared a test player that you can quickly see if OvenMediaEngine is working. Please refer to the for more information.
See the section for how to configure renditions.
For information on CrossDomains, see chapter.
If you are using an NVIDIA graphics card, please refer to the following guide to install the driver. The OS that supports installation with the provided script are CentOS 7/8 and Ubuntu 18/20 versions. If you want to install the driver in another OS, please refer to the manual installation guide document.
CentOS environment requires the process of uninstalling the nouveau driver. After uninstalling the driver, the first reboot is required, and a new NVIDIA driver must be installed and rebooted. Therefore, two install scripts must be executed.
How to check driver installation
After the driver installation is complete, check whether the driver is operating normally with the nvidia-smi command.
If you have finished installing the driver to use the GPU, you need to reinstall the open source library using Prerequisites.sh . The purpose is to allow external libraries to use the installed graphics driver.
Please refer to the NVIDIA Driver installation guide written previously.
To use GPU acceleration in Docker, you need to install NVIDIA drivers on your host OS and install the NVIDIA Container Toolkit. This toolkit includes container runtime libraries and utilities for using NVIDIA GPUs in Docker containers.
A Docker Image build script that supports NVIDIA GPU is provided separately. Please refer to the previous guide for how to build
If you are using an Intel CPU that supports QuickSync, please refer to the following guide to install the driver. The OSes that support installation using the provided scripts are CentOS 7/8 and Ubuntu 18/20 versions. If you want to install the driver on a different OS, please refer to the Manual Installation Guide document.
When the Intel QuickSync driver installation is complete, the OS must be rebooted for normal operation.
How to check driver installation
After the driver installation is complete, check whether the driver operates normally with the Matrix Monitor program.
If you have finished installing the driver to use the GPU, you need to reinstall the open source library using Prerequisites.sh . The purpose is to allow external libraries to use the installed graphics driver.
Please refer to the Netint documentation to install XCODER.
How to check driver installation
After the driver installation is complete, check if the libxcoder exist: the CLI must return something like libxcoder_logan.so (libc6,x86-64) => /usr/local/lib/libxcoder_logan.so
If you have finished installing the driver to use the VPU, you need to reinstall the open source library using Prerequisites.sh . The purpose is to allow external libraries to use the installed graphics driver. You also have to unzip the ffmpeg patch provide by netint in a specfic path
NVIDIA NVDEC Video Format :
NVIDIA NVENV Video Format :
CUDA Toolkit Installation Guide :
NVIDIA Container Toolkit :
Quick Sync Video format support:
Xilinx Video SDK :
Signature is generated by HMAC-SHA1 encoding all URLs except signature query string. The generated Signature is encoded using and included as a query string of the existing URL.
We hope to provide SignedPolicy URL Generator Library in various languages. If you have created the SignedPolicy URL Generator Library in another language, please send a Pull Request to our . Thank you for your open source contributions.
In order to include the policy in the URL, it must be encoded with .
Delivery
HTTP/1.1 HTTP/2
Security
TLS (HTTPS)
Container
MPEG-2 TS (Only supports Audio/Video muxed)
Codecs
H.264
AAC
Bind
Set the HTTP ports to provide HLS.
SegmentDuration
Set the length of the segment in seconds. Therefore, a shorter value allows the stream to start faster. However, a value that is too short will make legacy HLS players unstable. Apple recommends 6 seconds for this value.
SegmentCount
The number of segments listed in the playlist. 5 is recommended for HLS players. Do not set below 3. It can only be used for experimentation.
CrossDomains
Control the domain in which the player works through <CorssDomain>. For more information, please refer to the CrossDomain section.
DVR
Enable You can turn DVR on or off.
EventPlaylistType Inserts #EXT-X-PLAYLIST-TYPE: EVENT into the m3u8 file.
TempStoragePath Specifies a temporary folder to store old segments.
MaxDuration Sets the maximum duration of recorded files in milliseconds.
QuickSync
D / E
D / E
-
-
NVIDIA
D / E
D / E
-
-
Docker on NVIDIA Container Toolkit
D / E
D / E
-
-
Xilinx U30MA
D / E
D / E
url_expire
(Required)
<Number> Milliseconds since unix epoch
The time the URL expires Reject on request after the expiration
url_activate
(Optional)
<Number> Milliseconds since unix epoch
The time the URL activates Reject on request before activation
stream_expire
(Optional)
<Number> Milliseconds since unix epoch
The time the Stream expires Transmission and playback stop when the time expires
allow_ip
(Optional)
<String> IPv4 CIDR
Allowed IP Address Range
Check the IP address of the client connected to the server
real_ip (Optional)
<String> IPv4 CIDR
Allowed IP Address Range
Check the IP address of the client forwarded by the proxy server
PolicyQueryKeyName
The query string key name in the URL pointing to the policy value
SignatureQueryKeyName
The query string key name in the URL pointing to the signature value
SecretKey
The secret key used when encoding with HMAC-SHA1
Enables
List of providers and publishers to enable SignedPolicy. Currently, SignedPolicy supports rtmp among providers, and among publishers, WebRTC, LLHLS, Thumbnail are supported.
OvenMediaEngine can generate thumbnails from live streams. This allows you to organize a broadcast list on your website or monitor multiple streams at the same time.
Thumbnails are published via HTTP(s). Set the port for thumbnails as follows. Thumbnail publisher can use the same port number as HLS and DASH.
In order to publish thumbnails, an encoding profile for thumbnails must be set. JPG and PNG are supported as codec. And framerate and resolution can be adjusted. Framerate is the number of thumbnails extracted per second. We recommend 1 as the thumbnail framerate. Thumbnail encoding uses a lot of resources. Therefore, if you increase this value excessively, it can cause a failure due to excessive use of system resources. The resolution can be set as desired by the user, and if the ratio is different from the input image, it is stretched. We plan to support various ratio modes in the future.
Declaring a thumbnail publisher. Cross-domain settings are available as a detailed option.
When the setting is made for the thumbnail and the stream is input, you can view the thumbnail through the following URL.
Method
URL Pattern
GET
http(s)://<ome_host>:<port>/<app_name>/<output_stream_name>/thumb.<jpg|png>
For information on CrossDomains, see CrossDomains chapter.
OvenMediaEngine supports clustering and ensures high availability (HA) and scalability. For this we provide the OriginMap and OriginMapStore features. OriginMap is a method of configuring Origin server information in each Edge server, and OriginMapStore is a method for Origin servers and Edge servers to dynamically share information through Redis Server.
The OvenMediaEngine running as edge pulls a stream from an external server when a user requests it. The external server could be another OvenMediaEngine with OVT enabled or another stream server that supports RTSP.
The OVT is a protocol defined by OvenMediaEngine to relay stream between Origin-Edge and OVT can be run over SRT and TCP. For more information on the SRT Protocol, please visit the SRT Alliance site.
OvenMediaEngine provides OVT protocol for passing streams from the origin to the edge. To run OvenMediaEngine as Origin, OVT port, and OVT Publisher must be enabled as follows :
The role of the edge is to receive and distribute streams from an origin. You can configure hundreds of Edge to distribute traffic to your players. As a result of testing, a single edge can stream 4-5Gbps traffic by WebRTC based on AWS C5.2XLarge. If you need to stream to thousands of people, you can configure and use multiple edges.
The edge supports OVT and RTSP to pull stream from an origin. In the near future, we will support more protocols. The stream pulled through OVT is bypassed without being encoded.
To run OvenMediaEngine as Edge, you need to add Origins elements to the configuration file as follows:
The <Origin>is a rule about where to pull a stream from for what request.
The <Origin>has the ability to automatically create an application with that name if the application you set in <Location> doesn't exist on the server. If an application exists in the system, a stream will be created in the application.
NoInputFailoverTimeout (default 3000)
NoInputFailoverTimeout is the time (in milliseconds) to switch to the next URL if there is no input for the set time.
UnusedStreamDeletionTimeout (default 60000)
UnusedStreamDeletionTimeout is a function that deletes a stream created with OriginMap if there is no viewer for a set amount of time (milliseconds). This helps to save network traffic and system resources for Origin and Edge.
For a detailed description of Origin's elements, see:
Location
Origin is already filtered by domain because it belongs to VirtualHost. Therefore, in Location, set App, Stream, and File to match except domain area. If a request matches multiple Origins, the top of them runs.
Pass
Pass consists of Scheme and Url.
<Scheme> is the protocol that will use to pull from the Origin Stream. It currently can be configured as OVTor RTSP.
If the origin server is OvenMediaEngine, you have to set OVTinto the <Scheme>.
You can pull the stream from the RTSP server by setting RTSPinto the<Scheme>. In this case, the <RTSPPull> provider must be enabled. The application automatically generated by Origin doesn't need to worry because all providers are enabled.
Urls is the address of origin stream and can consist of multiple URLs.
ForwardQueryParams is an option to determine whether to pass the query string part to the server at the URL you requested to play.(Default : true) Some RTSP servers classify streams according to query strings, so you may want this option to be set to false. For example, if a user requests ws://host:port/app/stream?transport=tcp to play WebRTC, the ?transport=tcp may also be forwarded to the RTSP server, so the stream may not be found on the RTSP server. On the other hand, OVT does not affect anything, so you can use it as the default setting.
The final address to be requested by OvenMediaEngine is generated by combining the configured Url and user's request except for Location. For example, if the following is set
If a user requests http://edge.com/edge_app/stream, OvenMediaEngine makes an address to ovt: //origin.com: 9000/origin_app/stream.
OriginMapStore is designed to make it easier to support autoscaling within a cluster. All Origin Servers and Edge Servers in the cluster share stream information and origin OVT URLs through Redis. That is, when a stream is created on the Origin server, the Origin server sets the app/stream name and OVT url to access the stream to the Redis server. Edge gets the OVT url corresponding to the app/stream from the Redis server when the user's playback request comes in.
This means that existing settings do not need to be updated when extending Origin servers and Edge servers. Therefore, all Origins can be grouped into one domain, and all Edges can be bundled with one domain. OriginMapStore allows you to expand Origins or Edges within a cluster without any additional configuration.
OriginMapStore functionality has been tested with Redis Server 5.0.7. You can enable this feature by adding the following settings to Server.xml of Origin and Edge. Note that must be set in Server.xml of the Origin server. This is used when Origin registers its own OVT url, so you just need to set a domain name or IP address that can be accessed as an OVT publisher.
It is either impossible or very cumbersome for edge servers to pre-configure all applications. So OriginMap and OriginMapStore have the ability to dynamically create an application if the application does not exist when creating the stream. They create a new application by copying the application configuration with <Name>*</Name>. That is, the special application with the name * is a dynamic application template.
When you are configuring Load Balancer, you need to use third-party solutions such as L4 Switch, LVS, or GSLB, but we recommend using DNS Round Robin. Also, services such as cloud-based AWS Route53, Azure DNS, or Google Cloud DNS can be a good alternative.
TranscodeWebhook allows OvenMediaEngine to use OutputProfiles from the Control Server's response instead of the OutputProfiles in the local configuration (Server.xml). OvenMediaEngine requests OutputProfiles from the Control Server when streams are created, enabling the specification of different profiles for each individual stream.
Enable (required) You can enable or disable TranscodeWebhook settings.
ControlServerUrl (required) It's the URL of the Control Server, and it supports both HTTP and HTTPS.
SecretKey (optional) This is the Secret Key used to pass authentication for the Control Server. To pass security authentication, an HMAC-SHA1 encrypted value of the HTTP Payload is added to the HTTP Header's X-OME-Signature. This Key is used for generating this value.
Timeout (optional, default: 1500) This is the Timeout value used when connecting to the Control Server.
UseLocalProfilesOnConnectionFailure(optional, default: true) This determines whether to use the OutputProfiles from Local settings in case of communication failure with the Control Server. If it's set to "false," a communication failure with the Control Server will result in a failure to create the Output stream.
UseLocalProfilesOnServerDisallow (optional, default: false) When the Control Server responds with a 200 OK, but "allowed" is set to "false," this policy is followed.
UseLocalProfilesOnErrorResponse (optional, default: false) When the Control Server responds with error status codes such as 400 Bad Request, 404 Not Found, 500 Internal Error, OvenMediaEngine follows this policy.
OvenMediaEngine sends requests to the Control Server in the following format.
The Control Server responds in the following format to specify OutputProfiles for the respective stream.
The "outputProfiles" in the JSON is identical to the configuration in Server.xml, and the format is as follows.
AdmissionWebhooks are HTTP callbacks that query the control server to control publishing and playback admission requests.
Users can use the AdmissionWebhook for a variety of purposes, including customer authentication, tracking published streams, hide app/stream names, logging and more.
AdmissionWebhooks can be set up on VirtualHost, as shown below.
ControlServerUrl
The HTTP Server to receive the query. HTTP and HTTPS are available.
SecretKey
The secret key used when encrypting with HMAC-SHA1
Timeout
Time to wait for a response after request (in milliseconds)
Enables
Enable Providers and Publishers to use AdmissionWebhooks
AdmissionWebhooks send HTTP/1.1 request message to the configured user's control server when an encoder requests publishing or a player requests playback. The request message format is as follows.
The message is sent in POST method and the payload is in application/json format. X-OME-Signature is a base64 url safe encoded value obtained by encrypting the payload with HMAC-SHA1 so that the ControlServer can validate this message. See the Security section for more information on X-OME-Signature.
Here is a detailed explanation of each element of Json payload:
client
Information of the client who requested the connection.
address
IP address of the client connected to the server
port
Port number of the client connected to the server
real_ip
IP address of the client forwarded by the proxy server
user_agent (optional)
Client's User_Agent
request
Information about the client's request
direction
incoming : A client requests to publish a stream
outgoing : A client requests to play a stream
protocol
webrtc, srt, rtmp, llhls, thumbnail
status
opening : A client requests to open a stream
closing : A client closed the stream
url
url requested by the client
new_url (optional)
url redirected from user's control server (status "closing" only)
time
time requested by the client (ISO8601 format)
The control server may need to validate incoming http requests for security reasons. To do this, the AdmissionWebhooks module puts the X-OME-Signature value in the HTTP request header. X-OME-Signature is a base64 url safe encoded value obtained by encrypting the payload of an HTTP request with the HMAC-SHA1 algorithm using the secret key set in <AdmissionWebhooks><SecretKey> of the configuration.
As shown below, the trigger condition of request is different for each protocol.
WebRTC
When a client requests Offer SDP
RTMP
When a client sends a publish message
SRT
LLHLS
When a client requests a playlist (llhls.m3u8)
The engine in the closing state does not need any parameter in response. To the query just answer with empty json object.
ControlServer must respond with the following Json format. In particular, the "allowed" element is required.
allowed (required)
true or false
Allows or rejects the client's request.
new_url (optional)
Redirects the client to a new url. However, the scheme, port, and file cannot be different from the request. Only host, app, and stream can be changed. The host can only be changed to another virtual host on the same server.
lifetime (optional)
The amount of time (in milliseconds) that a client can maintain a connection (Publishing or Playback)
0 means infinity
HTTP based streaming (HLS) does not keep a connection, so this value does not apply.
reason (optional)
If allowed is false, it will be output to the log.
new_url redirects the original request to another app/stream. This can be used to hide the actual app/stream name from the user or to authenticate the user by inserting additional information instead of the app/stream name.
For example, you can issue a WebRTC streaming URL by inserting the user ID as follows: ws://domain.com:3333/user_id It will be more effective if you issue a URl with the encrypted value that contains the user ID, url expiration time, and other information.
After the Control Server checks whether the user is authorized to play using user_id, and responds with ws://domain.com:3333/app/sport-3 to new_url, the user can play app/sport-3.
If the user has only one hour of playback rights, the Control Server responds by putting 3600000 in the lifetime.
Apple supports Low-Latency HLS (LLHLS), which enables low-latency video streaming while maintaining scalability. LLHLS enables broadcasting with an end-to-end latency of about 2 to 5 seconds. OvenMediaEngine officially supports LLHLS as of v0.14.0.
LLHLS is an extension of HLS, so legacy HLS players can play LLHLS streams. However, the legacy HLS player plays the stream without using the low-latency function.
Delivery
HTTP/1.1 HTTP/2
Security
TLS (HTTPS)
Container
fMP4
Codecs
H.264
H.265 AAC
To use LLHLS, you need to add the <LLHLS> elements to the <Publishers> in the configuration as shown in the following example.
Bind
Set the HTTP ports to provide LLHLS.
ChunkDuration
Set the partial segment length to fractional seconds. This value affects low-latency HLS player. We recommend 0.2 seconds for this value.
SegmentDuration
Set the length of the segment in seconds. Therefore, a shorter value allows the stream to start faster. However, a value that is too short will make legacy HLS players unstable. Apple recommends 6 seconds for this value.
SegmentCount
The number of segments listed in the playlist. This value has little effect on LLHLS players, so use 10 as recommended by Apple. 5 is recommended for legacy HLS players. Do not set below 3. It can only be used for experimentation.
CrossDomains
LLHLS can deliver adaptive bitrate streaming. OME encodes the same source with multiple renditions and delivers it to the players. And LLHLS Player, including OvenPlayer, selects the best quality rendition according to its network environment. Of course, these players also provide option for users to manually select rendition.
See the Adaptive Bitrates Streaming section for how to configure renditions.
For information on CrossDomains, see CrossDomains chapter.
LLHLS is ready when a live source is inputted and a stream is created. Viewers can stream using OvenPlayer or other players.
If your input stream is already h.264/aac, you can use the input stream as is like below. If not, or if you want to change the encoding quality, you can do Transcoding.
When you create a stream, as shown above, you can play LLHLS with the following URL:
http[s]://domain[:port]/<app name>/<stream name>/llhls.m3u8
If you use the default configuration, you can start streaming with the following URL:
https://domain:3334/app/<stream name>/llhls.m3u8
We have prepared a test player that you can quickly see if OvenMediaEngine is working. Please refer to the Test Player for more information.
You can create as long a playlist as you want by setting <DVR> to the LLHLS publisher as shown below. This allows the player to rewind the live stream and play older segments. OvenMediaEngine stores and uses old segments in a file in <DVR><TempStoragePath> to prevent excessive memory usage. It stores as much as <DVR><MaxDuration> and the unit is seconds.
ID3 Timed metadata can be sent to the LLHLS stream through the Send Event API.
You can dump the LLHLS stream for VoD. You can enable it by setting the following in <Application><Publishers><LLHLS>. Dump function can also be controlled by Dump API.
TargetStreamName
The name of the stream to dump to. You can use * and ? to filter stream names.
Playlists
The name of the master playlist file to be dumped together.
OutputPath
The folder to output to. In the OutputPath you can use the macros shown in the table below. You must have write permission on the specified folder.
${VHostName}
Virtual Host Name
${AppName}
Application Name
${StreamName}
Stream Name
${YYYY}
Year
${MM}
Month
${DD}
Day
${hh}
Hour
${mm}
Minute
${ss}
Second
${S}
Timezone
${z}
UTC offset (ex: +0900)
${ISO8601}
Current time in ISO8601 format
OvenMediaEngine supports Widevine and Fairplay in LLHLS with simple setup since version 0.16.0.
Currently, DRM is only supported for H.264 and AAC codecs. Support for H.265 will be added soon.
To include DRM information in your LLHLS Publisher configuration, follow these steps. You can set the InfoFile path as either a relative path, starting from the directory where Server.xml is located, or as an absolute path.
The separation of the DRMInfoFile is designed to allow dynamic changes to the file. Any modifications to the DRMInfoFile will take effect when a new stream is generated.
Here's how you should structure your DRM Info File:
Multiple <DRM> can be set. Specify the VirtualHost, Application, and StreamName where DRM should be applied. StreamName supports wildcard regular expressions.
Currently, CencProtectScheme only supports "cbcs" since FairPlay also supports only cbcs. There may be limited prospects for adding other schemes in the near future.
KeyId, Key, Iv and Pssh values are essential and should be provided by your DRM provider. FairPlayKeyUrl is only need for FairPlay and if you want to enable FairPlay to your stream, it is required. It will be also provided by your DRM provider.
OvenPlayer now includes DRM-related options. Enable DRM and input the License URL. Your content is now securely protected.
Pallycon is no longer supported by the Open Source project and is only supported in the Enterprise version. For more information, see this article.
OvenMediaEngine integrates with Pallycon, allowing you to more easily apply DRM to LLHLS streams.
To integrate Pallycon, configure the DRMInfo.xml file as follows.
Set DRMProviderto Pallycon. Then, set the necessary information as shown in the example. KMSUrl and KMSToken are values provided by the Pallycon console. ContentId can be created using VHostName, AppName, and StreamName macros.
OvenMediaEngine uses WebRTC to provide sub-second latency streaming. WebRTC uses RTP for media transmission and provides various extensions.
OvenMediaEngine provides the following features:
Delivery
RTP / RTCP
Security
DTLS, SRTP
Connectivity
ICE
Error Correction
ULPFEC (VP8, H.264), In-band FEC (Opus)
Codec
VP8, H.264, Opus
Signalling
Self-Defined Signalling Protocol and Embedded Web Socket-Based Server
If you want to use the WebRTC feature, you need to add <WebRTC> element to the <Publishers> and <Ports> in the Server.xml configuration file, as shown in the example below.
WebRTC uses ICE for connections and specifically NAT traversal. The web browser or player exchanges the Ice Candidate with each other in the Signalling phase. Therefore, OvenMediaEngine provides an ICE for WebRTC connectivity.
If you set IceCandidate to *: 10000-10005/udp, as in the example above, OvenMediaEngine automatically gets IP from the server and generates IceCandidate using UDP ports from 10000 to 10005. If you want to use a specific IP as IceCandidate, specify a specific IP. You can also use only one 10000 UDP Port, not a range, by setting it to *: 10000.
OvenMediaEngine has embedded a WebSocket-based signalling server and provides our defined signalling protocol. Also, OvenPlayer supports our signalling protocol. WebRTC requires signalling to exchange Offer SDP and Answer SDP, but this part isn't standardized. If you want to use SDP, you need to create your exchange protocol yourself.
If you want to change the signaling port, change the value of <Ports><WebRTC><Signalling>.
The Signalling protocol is defined in a simple way:
If you want to use a player other than OvenPlayer, you need to develop the signalling protocol as shown above and can integrate OvenMediaEngine.
Add WebRTC element to Publisher to provide streaming through WebRTC.
Timeout
ICE (STUN request/response) timeout as milliseconds, if there is no request or response during this time, the session is terminated.
30000
Rtx
WebRTC retransmission, a useful option in WebRTC/udp, but ineffective in WebRTC/tcp.
false
Ulpfec
WebRTC forward error correction, a useful option in WebRTC/udp, but ineffective in WebRTC/tcp.
false
JitterBuffer
Audio and video are interleaved and output evenly, see below for details
false
WebRTC Streaming starts when a live source is inputted and a stream is created. Viewers can stream using OvenPlayer or players that have developed or applied the OvenMediaEngine Signalling protocol.
Also, the codecs supported by each browser are different, so you need to set the Transcoding profile according to the browser you want to support. For example, Safari for iOS supports H.264 but not VP8. If you want to support all browsers, please set up VP8, H.264, and Opus codecs in all transcoders.
WebRTC doesn't support AAC, so when trying to bypass transcoding RTMP input, audio must be encoded as opus. See the settings below.
If you created a stream as shown in the table above, you can play WebRTC on OvenPlayer via the following URL:
WebRTC Signalling
ws://<Server IP>[:<Signalling Port]/<Application name>/<Stream name>
Secure WebRTC Signalling
wss://<Server IP>[:<Signalling Port]/<Application name>/<Stream name>
If you use the default configuration, you can stream to the following URL:
ws://[OvenMediaEngine IP]:3333/app/stream
wss://[OvenMediaEngine IP]:3333/app/stream
We have prepared a test player to make it easy to check if OvenMediaEngine is working. Please see the Test Player chapter for more information.
OvenMediaEnigne provides adaptive bitrates streaming over WebRTC. OvenPlayer can also play and display OvenMediaEngine's WebRTC ABR URL.
You can provide ABR by creating a playlist in <OutputProfile> as shown below. The URL to play the playlist is ws[s]://domain[:port]/<app name>/<stream name>/<playlist file name>
<Playlist><Rendition><Video> and <Playlist><Rendition><Audio> can connected using <Encodes><Video><Name> or <Encodes><Audio><Name>.
It is not recommended to use a <Bypass>true</Bypass> encode item if you want a seamless transition between renditions because there is a time difference between the transcoded track and bypassed track.
If <Options><WebRtcAutoAbr> is set to true, OvenMediaEngine will measure the bandwidth of the player session and automatically switch to the appropriate rendition.
Here is an example play URL for ABR in the playlist settings below. wss://domain:13334/app/stream/abr
See the Adaptive Bitrates Streaming section for more details on how to configure renditions.
WebRTC can negotiate codecs with SDP to support more devices. Playlist can set rendition with different kinds of codec. And OvenMediaEngine includes only renditions corresponding to the negotiated codec in the playlist and provides it to the player.
If an unsupported codec is included in the Rendition, the Rendition is not used. For example, if the Rendition's Audio contains aac, WebRTC ignores the Rendition.
In the example below, it consists of renditions with H.264 and Opus codecs set and renditions with VP8 and Opus codecs set. If the player selects VP8 in the answer SDP, OvenMediaEngine creates a playlist with only renditions containing VP8 and Opus and passes it to the player.
There are environments where the network speed is fast but UDP packet loss is abnormally high. In such an environment, WebRTC may not play normally. WebRTC does not support streaming using TCP, but connections to the TURN (https://tools.ietf.org/html/rfc8656) server support TCP. Based on these characteristics of WebRTC, OvenMediaEngine supports TCP connections from the player to OvenMediaEngine by embedding a TURN server.
You can turn on the TURN server by setting <TcpRelay> in the WebRTC Bind.
Example : <TcpRelay>*:3478</TcpRelay>
OME may sometimes not be able to get the server's public IP to its local interface. (Environment like Docker or AWS) So, specify the public IP for Relay IP. If * is used, the public IP obtained from <StunServer> and all IPs obtained from the local interface are used. Port is the tcp port on which the TURN server is listening.
WebRTC players can configure the TURN server through the iceServers setting.
You can play the WebRTC stream over TCP by attaching the query transport=tcp to the existing WebRTC play URL as follows.
OvenPlayer automatically sets iceServers by obtaining TURN server information set in <TcpRelay> through signaling with OvenMediaEngine.
If you are using custom player, set iceServers like this:
When sending Request Offer in the signaling phase with OvenMediaEngine, if you send the transport=tcp query string, ice_servers information is delivered as follows. You can use this information to set iceServers.
The REST APIs provided by OME allow you to query or change settings such as VirtualHost and Application/Stream.
There are some limitations/considerations.
If you add/change/delete the settings of the App/Output Profile by invoking the API, the app will be restarted. This means that all sessions connected to the app will be disconnected.
VirtualHost settings in Server.xml cannot be modified through API. This rule also applies to Application/OutputStream, etc. within that VirtualHost. So, if you call a POST/PUT/DELETE API for VirtualHost/Application/OutputProfile declared in Server.xml, it will not work with a 403 Forbidden error.
By default, OvenMediaEngine's API Server is disabled, so the following settings are required to use the API.
In order to use the API server, you must configure <Managers> as well as port binding.
In <Names>, set the domain or IP that can access the API server. If * is set, any address is used. In order to access using the TLS Port, a certificate must be set in <TLS>.
API Server uses Basic HTTP Authentication Scheme to authenticate clients. An AccessToken is a plaintext credential string before base64 encoding. Setting the AccessToken to the form user-id:password per RFC7617 allows standard browsers to pass authentication, but it is not required.
For more information about HTTP Basic authentication, refer to the URL below.
To enable CORS on your API Server, you can add a setting. You can add * to allow all domains. If contains a scheme, such as https://, only that scheme can be allowed, or if the scheme is omitted, such as *.airensoft.com, all schemes can be accepted.
API endpoints are provided in the following format.
Method http://API.Server.Address[:Port]/v1/Resource
Method https://API.Server.Address[:TLSPort]/v1/Resource
OvenMediaEngine supports GET, POST, and DELETE methods, and sometimes supports PATCH depending on the type of resource. For detailed API specifications, please check the subdirectory of this chapter.
In OvenMediaEngine's REST API, action is provided in the following format.
POST http://host/v1/resource:{action name}
For example, an action to send an ID3 Timedmeta event to an LLHLS stream is provided by the endpoint below.
POST http://-/v1/vhosts/{vhost}/apps/{app}/streams/{stream}:sendEvent
In this API reference document, the API endpoint is described as follows. Note that scheme://Host[:Port] is omitted for all endpoints.
Responses from API endpoints are provided in the following format.
OvenMediaEngine supports Push Publishing function that can restreaming live streams to other systems. The protocol supports widely used protocols such as SRT, RTMP, and MPEGTS.
The StreamMap feature has been added, and it now automatically restreaming based on predefined conditions. You can also use the Rest API to control and monitor it.
To use Push Publishing, you need to declare the <Push> publisher in the configuration. <StreamMap> is optional. It is used when automatic push is needed.
<StreamMap> is used for automatically pushing content based on user-defined conditions. The XML file path should be specified relative to <ApplicationPath>/conf.
<StreamName> is used to match output stream names and supports the use of wildcard characters. <VariantNames> can be used to select specific tracks. Multiple variants can be specified using commas (','). The <Protocol> supports rtmp, mpegts, and srt. You enter the destination address in the <Url> and <StreamKey> field, where macros can also be used.
Push can be controlled using the REST API. Please refer to the documentation below for more details.
Batch reload certificates of all Virtual Hosts. In case of failure, the existing certificate will continue to be used.
Request
Responses
Reload the certificate of the specified Virtual Hosts. In case of failure, the existing certificate will continue to be used.
Request
Responses
OvenMediaEngine can record live streams. You can start and stop recording the output stream through REST API. When the recording is complete, a recording information file is created together with the recorded file so that the user can perform various post-recording processing.
To enable recording, add the <FILE> publisher to the configuration file as shown below. <FilePath> and <InfoPath> are required and used as default values. <FilePath> is the setting for the file path and file name. <InfoPath>is the setting for the path and name of the XML file that contains information about the recorded files. If there is no file path value among parameters when requesting recording through API, recording is performed with the set default value. This may be necessary if for security reasons you do not want to specify the file path when calling the API to avoid exposing the server's internal path. <<RootPath> is an optional parameter. It is used when requesting with a relative path is required when requesting an API. also, it is applied to <FilePath> and <InfoPath> as in the example below.
You must specify .ts or .mp4 at the end of the FilePath string to select a container for the recording file. We recommend using .ts unless you have a special case. This is because vp8 and opus codecs are not recorded due to container limitations if you choose .mp4.
For control of recording, use the REST API. Recording can be requested based on the output stream name (specified in the JSON body), and all/some tracks can be selectively recorded. And, it is possible to simultaneously record multiple files for the same stream. When recording is complete, an XML file is created at the path specified in InfoPath. For a sample of the recorded file information XML, refer to Appendix B.
For how to use the API, please refer to the link below.
Provides a way to automatically start and stop recording upon input stream that matches your file-based settings. In the above settings, the XML file path is specified in StreamMap.Path. You can create the XML file at the specified path and configure automatic recording as follows.
Split recording methods provide SegmentInterval and SegmentSchedule. The interval method splits files based on the accumulated recording time. The Schedule method then splits files according to scheduling options based on system time. The scheduling option is the same as the pattern used in crontab. However, only three options are used: seconds/minutes/hour. You can set the SegmentRule parameter to determine whether the start timestamp of the separated recording files will start anew from 0(discontinuity) or continue from where the previous file left off(continuity).
Various macro values are supported for file paths and names as shown below.
The following is a sample of an XML file that expresses information on a recorded file.
For more information, see .
When a client send a
Control the domain in which the player works through <CorssDomain>. For more information, please refer to the section.
The API server's port can be set in <Bind><Managers><API>. <Port> is an unsecured port and <TLSPort> is a secured port. To use TLSPort, TLS certificate must be set in the .
${Application}
Application name
${SourceStream}
Source stream name
${Stream}
Output stream name
${TransactionId}
Unique ID for the recording transaction. It is automatically created when recording starts. and is released when recording is stopped. In case of split recording, it is distinguished that it is the same transaction.
${Id}
User-defined identification ID
${StartTime:YYYYMMDDhhmmss}
Recording start time
YYYY - Year
MM - Month
DD - Days
hh : Hours (023)
mm : Minutes (0059)
ss : Seconds (00~59)
${EndTime:YYYYMMDDhhmmss}
Recording end time
YYYY - Year
MM - Month
DD - Days
hh : Hours (023)
mm : Minutes (0059)
ss : Seconds (00~59)
${VirtualHost}
Virtual host name
${Application}
Application name
${SourceStream}
Source stream name
${Stream}
Output stream name
${Sequence}
Sequence value that increases when splitting a file in a single transaction
Get all stream names in the {vhost name}/{app name} application.
Request
Responses
Create a stream by pulling an external URL. External URL protocols currently support RTSP and OVT.
Request
Responses
Get detailed information of stream.
Request
Responses
Delete Stream. This terminates the ingress connection.
The sender can reconnect after the connection is terminated. To prevent reconnection, you must use AccessControl.
Request
Responses
List all application names in the virtual host.
Request
Responses
Create application in the virtual host
Request
Responses
Request
Responses
Modify application settings. If this request succeeds, the Application will be restarted.
Request
Responses
Request
Responses
Start push publishing the stream with SRT, RTMP or MPEG2-TS. If the requested stream does not exist on the server, this task is reserved. And when the stream is created, it automatically starts push publishing.
Request
Responses
Request
Responses
Request
Responses
The Push Publishing task has the state shown in the table below. You can get the state in the Start Push Publishing and Get Push Publishing State API response.
ready
Waiting for the stream to be created.
connecting
Connecting to destination
pushing
Connected and streaming
stopping
Disconnection / stop in progress
stopped
Push is disconnected / stopped
error
Push encountered an error
Request
Responses
Add an Output Profile to the Application. If this request succeeds, the application will be restarted.
Request
Responses
Request
Responses
Delete output profile settings. If this request succeeds, the Application will be restarted.
Request
Responses
Start recording the stream. If the requested stream does not exist on the server, this recording task is reserved. And when the stream is created, it automatically starts recording.
Request
Responses
Request
Responses
Request
Responses
The Recording task has the state shown in the table below. You can get the state in the Start Recording and Get Recording State API response.
Ready
Preparing to start or waiting for the stream to be created.
Started
In Progress
Stopping
Is stopping
Stopped
Stopped
Error
Error
For live streaming of certain events, it may be necessary to immediately stop the HLS live stream and switch to VoD after the HLS live broadcast ends. This API transitions to VoD by stopping segment updates for LL-HLS and HLS streams and inserting #EXT-X-ENDLIST. By using this API with a Scheduled Channel, you can implement additional application services.
Request
Responses
The LLHLS Dump feature can be controlled with this API.
Request
Responses
Request
Responses
The info file is continuously updated after the dump file is written. It is in XML format and is as follows. will continue to be added.
To monitor the OvenMediaEngine, you can view in real-time the log files generated by itself. You can configure a log type and level by creating the Logger.xml configuration file in the same location as Server.xml.
You can set up Logger.xml as shown in the following example: OvenMediaEngine prints logs separated by many tag names and levels. Set <Tag name=".*" level="debug"> to have OvenMediaEngine print all logs and read the logs. And then it's better to disable tags that you don't need.
OvenMediaEngine generates log files. If you start OvenMediaEngine by systemctl start ovenmediaengine, the log file is generated to the following path.
If you run it directly from the command line, it will be generated to the following location:
If you run it in the Docker container, the log file is in the following path:
Following is the example of real logs.
OvenMediaEngine collects the following metrics for each host, application, and stream.
Bytes in/out by protocol
Connections by protocol
Maximum connections and time
Time is taken to connect to origin
You can get the current statistics using the REST API. See Stat API for the statistics REST API.
Files such as webrtc_stat.log and hls_rtsp_xxxx.log that were previously output are deprecated in the current version. We are developing a formal stats file, which will be open in the future.
Using MultiplexChannel, you can combine multiple internal streams into one ABR stream, or duplicate the stream and send it to another application.
MultiplexChannel can be controlled by API or file. See below for more information about MultiplexChannel.
The body of the API all has the same structure as the mux file.
Get all multiplex channels in the {vhost name}/{app name} application.
Request
Responses
Create a multiplex channel.
Request
Responses
Get detailed information of multiplex channel. It also provides information about the currently playing program and item.
Request
Responses
Delete Multiplex Channel
Request
Responses
ScheduledChannel allows you to create a live channel by scheduling pre-recorded files has been added to OvenMediaEngine. Other services or software call this Pre-recorded Live or File Live, but OvenMediaEngine plans to expand the function to organize live channels as a source, so we named it Scheduled Channel.
ScheduledChannel can be controlled by API or file. For more information about ScheduledChannel, see below.
The body of the API all has the same structure as the ScheduledChannel schedule file.
Get all scheduled channels in the {vhost name}/{app name} application.
Request
Responses
Create a Scheduled channel.
Request
Responses
Update the schedule. <Stream> cannot be PATCHed.
Request
Responses
Get detailed information of scheduled channel. It also provides information about the currently playing program and item.
Request
Responses
Delete Scheduled Channel
Request
Responses
Alert is a module that can detect anomalies and patterns of interest in a stream or system and send notifications to users. Anomalies and patterns of interest can be set through predefined , and when detected, the module sends an HTTP(S) request to the user's notification server.
Alert can be set up on <Server>, as shown below.
Url
The HTTP Server to receive the notification. HTTP and HTTPS are available.
Secretkey
The secret key used when encrypting with HMAC-SHA1
Timeout
Time to wait for a response after request. (in milliseconds)
Rules
Anomalies and patterns of interest to be detected.
Ingress
MinBitrate
Detects when the input stream's bitrate is lower than the set value.
MaxBitrate
Detects when the input stream's bitrate is greater than the set value.
MinFramerate
Detects when the input stream's framerate is lower than the set value.
MaxFramerate
Detects when the input stream's framerate is greater than the set value.
MinWidth
Detects when the input stream's width is lower than the set value.
MaxWidth
Detects when the input stream's width is greater than the set value.
MinHeight
Detects when the input stream's height is lower than the set value.
MaxHeight
Detects when the input stream's height is greater than the set value.
MinSamplerate
Detects when the input stream's samplerate is lower than the set value.
MaxSamplerate
Detects when the input stream's samplerate is greater than the set value.
LongKeyFrameInterval
Detects when the input stream's keyframe interval is too long (exceeds 4 seconds).
HasBFrames
Detects when there are B-frames in the input stream.
Here is a detailed explanation of each element of JSON payload:
sourceUri
URI information of the detected source.
It consists of #<vhost>#<application>/<stream>.
messages
List of messages detected by the Rules.
sourceInfo
Detailed information about the source at the time of detection. It is identical to the response of the REST API's source information query for the detected source.
type
It represents the format of the JSON payload. The information of the JSON elements can vary depending on the value of the type.
Currently, the value is fixed as INGRESS.
INGRESS_BITRATE_LOW
The ingress stream's current bitrate (%d bps) is lower than the configured bitrate (%d bps)
INGRESS_BITRATE_HIGH
The ingress stream's current bitrate (%d bps) is higher than the configured bitrate (%d bps)
INGRESS_FRAMERATE_LOW
The ingress stream's current framerate (%.2f fps) is lower than the configured framerate (%.2f fps)
INGRESS_FRAMERATE_HIGH
The ingress stream's current framerate (%f fps) is higher than the configured framerate (%f fps)
INGRESS_WIDTH_SMALL
The ingress stream's width (%d) is smaller than the configured width (%d)
INGRESS_WIDTH_LARGE
The ingress stream's width (%d) is larger than the configured width (%d)
INGRESS_HEIGHT_SMALL
The ingress stream's height (%d) is smaller than the configured height (%d)
INGRESS_HEIGHT_LARGE
The ingress stream's height (%d) is larger than the configured height (%d)
INGRESS_SAMPLERATE_LOW
The ingress stream's current samplerate (%d) is lower than the configured samplerate (%d)
INGRESS_SAMPLERATE_HIGH
The ingress stream's current samplerate (%d) is higher than the configured samplerate (%d)
INGRESS_LONG_KEY_FRAME_INTERVAL
The ingress stream's current keyframe interval (%.1f seconds) is too long. Please use a keyframe interval of 4 seconds or less
INGRESS_HAS_BFRAME
There are B-Frames in the ingress stream
The control server may need to validate incoming http requests for security reasons. To do this, the AdmissionWebhooks module puts the X-OME-Signature value in the HTTP request header. X-OME-Signature is a base64 url safe encoded value obtained by encrypting the payload of an HTTP request with the HMAC-SHA1 algorithm using the secret key set in <Alert><SecretKey> of the configuration.
The engine in the closing state does not need any parameter in response. To the query just answer with empty JSON object.
We will update this document as we gather troubleshooting examples. (Written in Nov 04, 2021)
prerequisites.sh Script FailedIf you have problems with the prerequisites.sh the script we have provided, please install it manually as follows.
systemctl start ovenmediaengine failedIf SELinux is running on your system, SELinux can deny the execution of OvenMediaEngine.
You can choose between two methods of adding a policy to SELinux or setting SELinux to permissive mode. To add a policy, you must apply the SELinux policy file for the OvenMediaEngine service to your system as follows:
Setting SELinux to permissive mode is as simple as follows. But we don't recommend this method.
WebRTC does not support b-frame of H.264. But if your encoder sends b-frames the video will be stuttered in the player. In this case, you can solve the problem by disabling the b-frame function in your encoder. For OBS, you can set bframes=0 option as below.
Or by activating the encoding options in OvenMediaEngine.
In this case, you are probably trying to stream with UDP in an environment where packet loss is high due to network performance, connection problems, etc., the interruption during stream playback may more and more worsen. This problem can be solved simply by playing with WebRTC/TCP.
If you want to monitor packet loss in your Chrome browser, you can access it by typing 'chrome://webrtc-internals' in the address bar.
Also, if the device's network speed, which is running the player, isn't fast enough to accommodate the stream's BPS, the stuttering during streaming won't resolve and will eventually drop the connection. In this case, there is no other way than to speed up your network.
If the Origin server uses excessive CPU/Memory/Network, all players may experience stuttering during streaming.
When you see Origin is CPU intensive on your Origin-Edge structure, the transcoding options in the OvenMediaEngine may be the primary cause. That is, you may have set the quality of the input stream too high, or the output stream to exceed the capabilities of your hardware significantly. In this case, it can be solved by enabling the hardware encoder in OvenMediaEngine.
If the edge server excessively uses CPU/Memory/Network, the player connected to that Edge may experience stuttering during streaming. In this case, it can be solved by expanding Edge.
When you see a specific thread overuses the CPU, the video may not stream smoothly. Please refer to the manual below for more information on this.
The Linux kernel, which is set by default, cannot handle 1Gbps output, so put it as follows:
The mobile environment used by many people uses a wireless network. It has a high network speed but, conversely, can cause high packet loss.
Look, CUBIC, the Congestion Control set by default in your Linux, adjusts the TCP Window by packet loss, so it is not suitable to provide stable streaming in such an environment.
So our suggestion is to use Google's BBR. This setting is even more important if you mainly provide WebRTC services to mobile users who use a wireless network. Change the Congestion Control from CUBIC to BBR on your Linux.
If you try to access OvenMediaEngine's WebRTC URL starting with ws:// (Non-TLS) from an HTTPS (HTTP/TLS) site, the connection may be rejected due to a mixed content problem depending on the browser.
In this case, you can solve this by installing a certificate in OvenMediaEngine and trying to connect with the wss:// (WebSocket/TLS) URL.
As of October 2021, most browsers have enforced the CORS policy, and CORS errors often occur when requesting access to other domains if it is not a TLS site. In this case, you can solve the problem by installing a certificate on the site that loads the player.
At some point, when the message "Too many open files" is output in your OvenMediaEngine log, it may not be able to handle any more player connections. In this case, you can solve the problem by setting it as follows:
If you use Transcoding as Bypass in OvenMediaEngine and set a long keyframe interval in the encoder, the WebRTC player cannot start streaming until a keyframe is an input.
In this case, you can solve this by setting the keyframe interval in the encoder to 1-2 seconds,
Or by enabling the encoding options in OvenMediaEngine.
A/V may not be input evenly from the encoder. There are some encoders with policies for reliable streaming that they decide, for example, sending audio first and video very later, or video first and audio very late.
OvenMediaEngine outputs the input received from the encoder as-is for sub-second latency streaming. The WebRTC player also streams the received input as-is, so the A/V sync may not match during the initial playback due to the policy of specific encoders.
However, this can be resolved naturally as the player will sync A/V while streaming based on Timestamp. Still, if this work looks like an error, you can also solve it by enabling JitterBuffer in OvenMediaEngine.
Also, suppose you are using a transcoder in OvenMediaEngine and trying to input with b-frames of H264. Audio is encoded fast, but a video is buffered at the decoder because of b-frames. Therefore, there is a time difference at the start of each encoding, which may cause the A/V to be out of sync. Even in this case, enabling JitterBuffer will solve this problem.
There may be cases where the A/V sync is not corrected even after a certain amount of time has elapsed after playback. This problem is caused by small internal buffers in some browsers such as Firefox, which causes the player to give up calibration if the A/V sync differs too much. But this can also be solved by enabling JitterBuffer.
Nevertheless, if the A/V sync is not corrected, you should suspect an error in the original video file, which can be checked by playing as HLS.
However, if A/V sync is well during streaming with HLS, this is OvenMediaEnigne's bug. If you find any bugs, please feel free to report them to OvenMediaEngine GitHub Issues.
WebRTC supports Opus, not AAC, as an audio codec. Because RTMP and other protocols mainly use and transmit AAC as the audio codec, you may not have set up Opus, but WebRTC cannot output audio without Opus. This can be solved by setting Opus in OvenMediaEnigne.
If you are using video encoding in OME, the video bitrate may be set low. In this case, the video quality can be improved by increasing the unit of video bitrate.
However, since OvenMediaEngine has the default to the fastest encoding option for sub-second latency streaming, the video quality may not be as good as the set video bitrate. In this case, OvenMediaEngine provides an output profile preset that can control the quality, so you can choose to solve it.
Since the encoder is transmitting video to OvenMediaEngine in low quality, you can solve it by increasing the input quality in the encoder settings.
OvenMediaEngine provides P2P Delivery to be able to distribute Edge Traffic to Player. This feature is currently the Preview version, and if you want to use it, you need only to use OvenPlayer. Moreover, we plan to perform more experiments in various real-world and then upgrade it to the full version in OvenMediaEngine.
First of all, we have rules. The peer that sends the Traffic in the P2P network is called a Host Peer, and the peer that receives the Traffic from the Host Peer is called a Client Peer. Also, P2P Delivery in OvenMediaEngine doesn't designate the Client Peer as the Host Peer again. In other words, it only operates as 1 Depth.
According to our experiments so far, P2P Delivery provides the best performance and stability when using 1 Depth to connect between Players and connecting up to two Players to one Player.
In other words, P2P Delivery has distributed two-thirds of existing Traffic. So, this means that it can expand the Capacity of the Edge Network by three times and reduce Traffic costs by two-thirds.
You can use the P2P function of OvenMediaEngine by adding the <P2P> element as the following settings:
Also, If you want to use P2P Delivery when your OvenMediaEngine is running in Origin-Edge Cluster-Mode, you need to apply this setting to all the Edges. You can instantly test P2P Delivery with OvenPlayer.
<MaxClientPeersPerHostPeer> sets the number of Client Peers connecting to one Host Peer.
When OvenMediaEngine receives a WebRTC connection request from a new player, it determines the Host Peer or Client Peer according to the following rules:
The device isn't Mobile
OS isn't Linux
Browser isn't MS Edge Browser
Browser isn't Unknown Browser
One of the Host Peers uses the same kind of browser
Host Peer is vacant
If you have a better idea, we hope that you improve our code and contribute to our project. Please visit OvenMediaEngine GitHub.
For more information, see .
OvenMediaEngine provides a tester for measuring WebRTC performance called OvenRtcTester. It is developed in Go language and uses the pion/webrtc/v3 and gorilla/websocket modules. Many thanks to the pion/webrtc and gorilla/websocket teams for contributing this wonderful project.
Since OvenRtcTester is developed in Go language, Go must be installed on your system. Install Go from the following URL: https://golang.org/doc/install
OvenRtcTester was tested with the latest version of go 1.17.
You can simply run it like this: -url is required. If the -life option is not used, it will run indefinitely until the user presses ctrl+c.
You can also use go build or go install depending on your preference.
OvenRtcTester must test OvenMediaEngine 0.12.4 or higher as the target system. OvenMediaEngine versions below 0.12.4 have a problem with incorrectly calculating the RTP timestamp, so OvenRtcTester calculates the Video Delay value incorrectly.
Linux has various tools to monitor CPU usage per thread. We will check the simplest with the top command. If you issue the top -H -p [pid] command, you will see the following screen.
You can use OvenRtcTester to test the capacity of the server as shown below. When testing the maximum performance, OvenRtcTester also uses a lot of system resources, so test it separately from the system where OvenMediaEngine is running. Also, it is recommended to test OvenRtcTester with multiple servers. For example, simulate 500 players with -n 500 on one OvenRtcTester, and simulate 2000 players with four servers.
Building and running OvenMediaEngine in debug mode results in very poor performance. Be sure to test the maximum performance using the binary generated by make release && make install .
If the OvenMediaEngine's capacity is exceeded, you will notice it in OvenRtcTester's Summary report with Avg Video Delay and Avg Audio Delay or Packet loss.
On the right side of the above capture screen, we simulate 400 players with OvenRtcTester. <Summary> of OvenRtcTester shows that Avg Video Delay and Avg Audio Delay are very high, and Avg FPS is low.
And on the left, you can check the CPU usage by thread with the top -H -p command. This confirms that the StreamWorker threads are being used at 100%, and now you can scale the server by increasing the number of StreamWorker threads. If OvenMediaEngine is not using 100% of all cores of the server, you can improve performance by tuning the number of threads.
This is the result of tuning the number of StreamWorkerCount to 8 in config. This time, we simulated 1000 players with OvenRtcTester, and you can see that it works stably.
The WorkerCount in <Bind> can set the thread responsible for sending and receiving over the socket. Publisher's AppWorkerCount allows you to set the number of threads used for per-stream processing such as RTP packaging, and StreamWorkerCount allows you to set the number of threads for per-session processing such as SRTP encryption.
Thread name
Element in the configuration
AW-XXX
<Application><Publishers><AppWorkerCount>
StreamWorker
<Application><Publishers><StreamWorkerCount>
SPICE-XXX
<Bind><Provider><WebRTC><IceCandidates><TcpRelayWorkerCount>
<Bind><Pubishers><WebRTC><IceCandidates><TcpRelayWorkerCount>
SPRtcSignalling
<Bind><Provider><WebRTC><Signalling><WorkerCount>
<Bind><Pubishers><WebRTC><Signalling><WorkerCount>
SPSegPub
<Bind><Pubishers><HLS><WorkerCount>
<Bind><Pubishers><DASH><WorkerCount>
SPRTMP-XXX
<Bind><Providers><RTMP><WorkerCount>
SPMPEGTS
<Bind><Providers><MPEGTS><WorkerCount>
SPOvtPub
<Bind><Pubishers><OVT><WorkerCount>
SPSRT
<Bind><Providers><SRT><WorkerCount>
Type
Value
Default
1
Minimum
1
Maximum
72
With AppWorkerCount, you can set the number of threads for distributed processing of streams when hundreds of streams are created in one application. When an application is requested to create a stream, the stream is evenly attached to one of created threads. The main role of Stream is to packetize raw media packets into the media format of the protocol to be transmitted. When there are thousands of streams, it is difficult to process them in one thread. Also, if StreamWorkerCount is set to 0, AppWorkerCount is responsible for sending media packets to the session.
It is recommended that this value does not exceed the number of CPU cores.
Type
Value
Default
8
Minimum
0
Maximum
72
It may be impossible to send data to thousands of viewers in one thread. StreamWorkerCount allows sessions to be distributed across multiple threads and transmitted simultaneously. This means that resources required for SRTP encryption of WebRTC or TLS encryption of HLS/DASH can be distributed and processed by multiple threads. It is recommended that this value not exceed the number of CPU cores.
If a large number of streams are created and very few viewers connect to each stream, increase AppWorkerCount and lower StreamWorkerCount as follows.
If a small number of streams are created and a very large number of viewers are connected to each stream, lower AppWorkerCount and increase StreamWorkerCount as follows.
