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, only HLS, DASH, and WebRTC Signaling support TLS.
Add your certificate files to as follows:
To configure HTTPs for HLS, DASH, and WebRTC Signalling servers, the TLS element must be enabled. The CertPath has to indicate a server certificate and the KeyPath has to indicate a private key file. They can be set to absolute paths or relative paths from the executable. If the server certificate is issued using an intermediate certificate, some browsers may complain about a certificate. In this case, you should set a bundle of chained certificates provided by a Certificate Authority in ChainCertPath.
If you set up TLS, you can't set IP or * into <Name>. You can only set Domains that the certificate contains. If you have a certificate for *.host.com
, it means you can set domains such as aaa.host.com
, bbb.host.com
, and *.host.com
.
If the certificate settings are completed correctly, WebRTC streaming can be played wss://url
with HLS and DASH streaming https://url
.
The current version of OvenMediaEngine doesn't yet support SNI. This means that you can't set multiple TLS. So currently OvenMediaEngine can only set TLS on the first VirtualHost. We will support SNI in the next version.
OvenMediaEngine supports HTTP based streaming protocols such as HLS, MPEG-DASH(Hereafter DASH), and Low-Latency MPEG-DASH with CMAF(Hereafter LLDASH).
OvenMediaEngine will support Low-Latency HLS in the near future. We are always keeping an eye on the decision from Apple inc.
To use HLS, Dash and LLDash, you need to add the <HLS>
and<DASH>
elements to the <Publishers>
in the configuration as shown in the following example.
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.
You can set it using the <Url>
element as shown above, and you can use the following values:
LLDASH, DASH, and HLS Streaming are ready when a live source is inputted and a stream is created. Viewers can stream using OvenPlayer or other players.
Also, you need to set H.264 and AAC in the Transcoding profile because MPEG-DASH and HLS use these codecs.
When you create a stream, as shown above, you can play LLDASH, DASH, and HLS through OvenPlayer with the following URL:
If you use the default configuration, you can start streaming with the following URL:
https://[OvenMediaEngine IP]:443/app/<stream name>_o/playlist.m3u8
http://[OvenMediaEngine IP]:80/app/<stream name>_o/playlist.m3u8
https://[OvenMediaEngine IP]:443/app/<stream name>_o/manifest.mpd
http://[OvenMediaEngine IP]:80/app/<stream name>_o/manifest.mpd
https://[OvenMediaEngine IP]:443/app/<stream name>_o/manifest_ll.mpd
http://[OvenMediaEngine IP]:80/app/<stream name>_o/manifest_ll.mpd
We have prepared a test player that you can quickly see if OvenMediaEngine is working. Please refer to the Test Player for more information.
Title
Functions
Delivery
HTTP for HLS and DASH HTTP 1.1 chunked transfer for LLDash
Security
TLS (HTTPS)
Format
TS for HLS
ISOBMFF for DASH
CMAF for LLDASH
Codec
H.264, AAC
Element
Decscription
Bind
Set the HTTP port to provide HLS and DASH. LLDASH and DASH are provided on the same port, and DASH and HLS can be set to the same port.
SegmentDuration
Set the length of the segment in seconds. The shorter the <SegmentDuration>
, the lower latency can be streamed, but it is less stable during streaming. Therefore, we are recommended to set it to 3 to 5 seconds.
SegmentCount
Set the number of segments to be exposed to *.mpd
. The smaller the number of <SegmentCount>
, the lower latency can be streamed, but it is less reliable during streaming. Therefore, it is recommended to set this value to 3.
It doesn't need to set SegmentCount for LLDASH because LLDASH only has one segment on OvenMediaEngine.
CrossDomains
Control the domain in which the player works through <CorssDomain>
. For more information, please refer to the CrossDomain section.
Url Value
Description
*
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
Protocol
URL format
LLDASH
http://<Server IP>[:<DASH Port>]/<Application Name>/<Stream Name>/manifest_ll.mpd
Secure LLDASH
https://<Domain>[:<DASH TLSPort>]/<Application Name>/<Stream Name>/manifest_ll.mpd
DASH
http://<Server IP>[:<DASH Port>]/<Application Name>/<Stream Name>/manifest.mpd
Secure DASH
https://<Domain>[:<DASH TLSPort>]/<Application Name>/<Stream Name>/manifest.mpd
HLS
http://<Server IP>[:<HLS Port>]/<Application Name>/<Stream Name>/playlist.m3u8
Secure HLS
https://<Domain>[:<HLS TLSPort>]/<Application Name>/<Stream Name>/playlist.m3u8
OvenMediaEngine uses WebRTC to provide sub-second latency streaming. WebRTC uses RTP for media transmission and provides various extensions.
OvenMediaEngine provides the following features:
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.
WebRTC Publisher's <JitterBuffer>
is a function that evenly outputs A/V (interleave) and is useful when A/V synchronization is no longer possible in the browser (player) as follows.
If the A/V sync is excessively out of sync, some browsers may not be able to handle this or it may take several seconds to synchronize.
Players that do not support RTCP also cannot A/V sync.
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.
Some browsers support both H.264 and VP8 to send Answer SDP to OvenMediaEngine, but sometimes H.264 can't be played. In this situation, if you write the VP8 above the H.264 code line in the Transcoding profile setting, you can increase the priority of the VP8.
Using this manner so that some browsers, support H.264 but can't be played, can stream smoothly using VP8. This means that you can solve most problems with this method.
If you created a stream as shown in the table above, you can play WebRTC on OvenPlayer via the following URL:
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.
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.
If * is used as the IP of TcpRelay and IceCandidate, all available candidates are generated and sent to the player, so the player tries to connect to all candidates until a connection is established. This can cause delay in initial playback. Therefore, specifying the ${PublicIP} macro or IP directly may be more beneficial to quality.
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 <TcpForce>
is set to true, it will force a TCP connection even if ?transport=tcp
is not present. To use this, <TcpRelay>
must be set.
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.
Title
Functions
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
Option
Description
Default
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
Protocol
URL format
WebRTC Signalling
ws://<Server IP>[:<Signalling Port]/<Application name>/<Stream name>
Secure WebRTC Signalling
wss://<Server IP>[:<Signalling Port]/<Application name>/<Stream name>