HTTP Live Streaming (HLS) is a technology to play streaming video via the HTTP protocol developed by Apple. An HLS video stream is encoded to H.264 and AAC and is played on any compatible device, browser or player.
Web Call Server converts to HLS video received from other supported sources of broadcasting such as web cameras and professional video capturing device, SIP calls and so on.
Supported platforms and browsers
- Video: H.264
- Audio: AAC
- The browser connects to the server via the Websocket protocol and sends the publish command.
- The browser captures the microphone and the camera and sends the WebRTC stream to the server.
- The second browser establishes a connection via HTTP.
- The second browser receives the HLS stream and plays this stream on the page.
Quick manual on testing
Publishing of a video stream on the server and playing it via HLS in a browser
1. For the test we use:
- WCS server;
- the Two Way Streaming web application to publish the stream
- the HLS Player Minimal web application to publish the stream
2. Open the Two Way Streaming web application. Click Connect, then Publish. Copy the identifier of the stream:
3. open the HLS Player Minimal web application. In the Stream field paste the identifier of the stream and click Play. The stream starts playing:
Below is the call flow when using the HLS Player Minimal example to play a stream via HLS
1. Querying the server and playing.
Configuring the HLS URL.
Starting the playback.
2. Receiving the HLS stream from the server
HLS playback authentication using REST hook
A client authentication for HLS playback can be setup if necessary. To do this, the following parameter should be set in flashphoner.properties file
At client side,
token parameter must be added to HLS URL to pass to WCS server a token obtained for example from backend server:
REST hook /playHLS must be implemented on backend server. WCS server will send query to backend with token received from client
Backend server should return 200 OK if token is checked successfully, and 403 Forbidden if token is wrong. In its turn, client will receive either HLS stream or 401 Unauthorized.
defines token caching interval in seconds (10 seconds by default). /playHLS queries with certain token will not be sent to backend until the token is in cache i.e. either there is stream subscriber with tis token or caching interval is not expired. If caching interval parameter is set to 0
/playHLS queries are sent to backend on every HTTP GET request from client.
HLS authentication setting can be changed without server restart. In this case
hls_auth_enabled affects existing subscribers and
hls_auth_token_cache affects new subscribers only.
Adding cross-domain access control HTTP headers for HLS playback
By default, the followin access control headers are added to 200 OK response to HTTP GET request:
If necessary, for example, if HLS content and HLS player page are in different domains, custom access control headers can be added using the following parameter in flashphoner.properties file:
In this case, the headers listed in the parameter will be added to 200 OK response:
Using nginx as reverse proxy for HLS playback
In some cases nginx web server can be used as reverse proxy for HLS playback from WCS server. Usually, it may require if HTTP headers adding does not help to workaround cross domain request restrictions in some browsers.
For example, if browser requires HLS player page and HLS stream to be in the same domain your.domain and on the same port 443 (HTTPS), nginx should be set up as follows:
It also may be useful to cache HLS stream. In this case nginx should be additionally set up as follow:
http section of /etc/nginx.conf settings file proxy cache parameters are set
server section of site settings file caching of HLS segments is set, playlist should not be cached:
Returning of static HTML pages on HLS port
Another way to workaround cross domain requests restrictions in browser is to return a static content, player page for example, on the same port that returns HLS content. To enable this feature, the following parameter should be set in flashphoner.properties file
The p;ayer page should be in directory defined by the following parameter
In this case (by default) the path to the player page files is set relative to WCS installation directory. A full path may also be set, for example
If static content returning is enabled, browser will display the HLS player page by URL . If this feature is disabled, server will return 404 Not found error by such URL.
1. Non-recoverable freize of HLS stream played in iOS Safai through a CDN
Symptoms: one minute after publishing start image stops, sound continues to play
b) enable transcoding on server using the following option in flashphoner.properties file
b) if transcoding is undesirable, set the following option in flashphoner.properties file
In this case, clicks are possible in audio, but video will not stop.
2. HLS segments writing stops when playing stream published in Firefox browser.
Symptoms: a few minutes after playback start HLS segments stop writing, in that case the stream directoty in hls directory is not deleted, and messages in server log continue to appear
Publisher must publish stream again to recover.
Solution: use another browser to publish the stream which supposed to be played via HLS.