Apple HTTP Live Streaming is a widespread technology for delivering video to mobile devices that relies on simplicity, versatility and cross-country ability. As the delivery protocol, the simplest, most affordable and tested Internet protocol is HTTP, which allows you to deliver video to almost any device or software on the network.

Below, under the cat, an alternative is considered - Websocket Streaming for iOS Safari and the testing process is described in detail.

Winning versatility, HLS technology is inferior in the speed of delivery and video display. The video stream is divided into fragments (chunks) that are downloaded via HTTP as regular files, buffered and collected in the video on the player side. The main disadvantage is the large delay in video playback - 5 seconds or more.

If you have a video surveillance system or playback of a pre-recorded video, 5-10 seconds of delay are not important for you. For example, if the video displays a parking view in which nothing happens, then 10 seconds does not matter, unless you see the same picture 10 seconds later.

Similarly with a pre-recorded video: 10 seconds of buffering will not affect anything.

Another thing is when an event is broadcast in real time, for example, a webinar where the presenter receives questions from the audience and answers them. Here the additional delay may cause some discomfort.



Here's what the HLS player looks like on iOS Safari: The



video is full screen and there is no way to prevent this. The HLS player is launched separately from the browser, and the video stream is played in it. Such a display is quite convenient for watching videos - turned on and watch.

Inconvenience arises when some interactivity is required from a web application. The following requirements may apply to such applications:

• playing video directly on the HTML page in the browser;
• other elements, for example, chat, can be placed on the same page.

Basically, such web applications include webinars, video chats and broadcasts with the possibility of simultaneous discussion in the chat (for example, a sports event).

At first glance, the simplest solution is to make an iOS application for such a task, for example, broadcast + chat and send users to download the application. However, as practice shows, not all users love / know how to make additional gestures: go to the App Store, be puzzled by security settings, download the application, launch it and, finally, watch the broadcast. Much easier and shorter in this case is the path “click on the link in Safari” - “view the broadcast directly in the browser”.

So, we have two requirements for iOS Safari:

1. video should be played with minimal delay;
2. The video should play directly in the browser using HTML5.

The best solution would be to support WebRTC technology. Indeed, the application of WebRTC technology would solve the problem of delay and allow playing the stream directly in the browser in the way it works, for example, in Android Chrome. Unfortunately, there is no WebRTC support in iOS Safari and the prospects for such support are currently very vague.

As usual, when there is no support from the official manufacturer, there are alternatives,
one of which is the delivery of video to iOS Safari via Websockets and rendering this video stream using a browser.

Websockets is in this case the only protocol available in iOS Safari that can provide fast video stream delivery. The protocol works on the basis of TCP as well as HTTP, but, unlike the latter, it is much better suited for transmitting streaming data due to the fact that binary data is transmitted inside an already established connection and there are no unnecessary HTTP headers when transmitting them.

In this article, we will compare the classical approach using HLS with broadcasting the same live stream via Websocket to iOS Safari, for this we will configure and test both technologies.

The iOS Safari browser is not random. IE and Mac Safari support Flash, Chrome, FF and Opera support WebRTC. And only iOS devices are limited to using HLS, an alternative to which is discussed in this article.

Video streaming through Websocket is called VoW (Video over Websockets), and the player that plays this stream is VoW-Player.

We will describe in detail the testing of HLS and VoW, including the installation of all the necessary tools.

HLS - Apple HTTP Live Streaming

We create two droplets.

For the purity of the experiment, we use two different virtual servers Centos 6.5 64 bit, 1 GB RAM on digitalocean .



We go to oracle.com, download, unpack and install the JDK.

Oracle JDK can be downloaded here .

You could install RPM, but just copying the folder also works.

tar -xvzf jdk-8u45-linux-x64.tar.gz
mkdir /usr/java
mv jdk1.8.0_45 /usr/java
ln -sf /usr/java/jdk1.8.0_45 /usr/java/default
ln -sf /usr/java/default/bin/java /usr/bin/java
java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

Download Wowza

Wowza will receive an RTMP stream and give it as HLS. Download from wowza.com . After that, you will need to get a free developer license .

Install Wowza The

installer will ask for the administrator login and password, which can later be used to enter the admin panel.

chmod +x WowzaStreamingEngine-4.1.2.tar.bin
./WowzaStreamingEngine-4.1.2.tar.bin

We start Wowza

The server and the administrative interface are launched separately.

service WowzaStreamingEngine start
service WowzaStreamingEngineManager start

Go to the Wowza admin interface.

After a successful launch, the admin panel is available on port 8088. The
login and password were set during installation.



We allow connections in the live> Incoming Security

settings. By default, RTMP-Publishing is allowed only with a password. Allow everyone to publish streams - the option 'no authentication required'. It will be easier to test this way, and later we will always have time to close access.



Download Wirecast Live Encoder

The choice of Wirecast was due to the fact that it encodes sound well in AAC. For example, FMLE (Flash Media Live Encoder) under Windows 8 does not know how to do this. FMLE for Mac is able to encode AAC, but the Mac was not at hand.

Unfortunately, with Wirecast it was not possible to capture video from a webcam on Windows 8.1 64 bit, so I had to stream the video. The following is a description of the process. At the time of writing, the version of Wirecast-6.0.4-64-bit was used .

Download sample.mp4 file from the WowzaStreamingEngine / content directory on the server

A video about the hare in MPEG4 format is included with Wowza. Download it to the computer where Wirecast Encoder is installed.



Open the sample.mp4 file in Wirecast.

Add the video to Wirecast by simply selecting it in the file system.



We start the playback of sample.mp4 in Wirecast.

To put the video on playback, you need to click the button with the image of the right arrow, which is located directly under the hare. See screenshot below.



Configure Output Settings

Now we set the encoding settings. With these settings, the video will be transcoded and sent to the network using the RTMP protocol.

We encode for H.264 + AAC mobile devices, set the resolution to 320x240.



Configure the address of the RTMP server

Here we specify the address of the droplet on which Wowza is installed. Stream Name: myStream.



We start the stream broadcasting

Press the 'Stream' button to start the process of transcoding the video and sending the RTMP stream to the server. A green connection indicator appears in the upper right corner.



Open Wowza admin panel in iOS Safari, live application

If you open the admin panel not in iOS Safari, then when you try to get URLs for playback via HLS, an error 'Your device does not support HLS' or something similar will be displayed, so go to the admin panel in iOS Safari, select the 'live' application and click on the button 'Test Players'.





We click on the HLS url and start playing in Apple iPhone Safari.

There was no player there, just an HTTP URL from which you can pick up video via HLS. The iOS Safari browser opens this URL and enables the internal HLS Player for video playback. We get an HLS movie that streams Wirecast in Live mode.

Note that the playback delay is about 25 seconds. Surely, this can be tuned somewhere, but out of the box we have what we have.



Thus, we obtain the following HLS broadcast scheme:

The scheme is quite simple: send the video via RTMP and distribute it via HLS.

VoW - Video over Websockets

Install the JDK on the second droplet in the same way as for Wowza

tar -xvzf jdk-8u45-linux-x64.tar.gz
mkdir /usr/java
mv jdk1.8.0_45 /usr/java
ln -sf /usr/java/jdk1.8.0_45 /usr/java/default
ln -sf /usr/java/default/bin/java /usr/bin/java

Install and configure Web Call Server 4

Download and install the WCS4 server

wget http://flashphoner.com/download-wcs4-server.tar.gz
tar -xvzf download-wcs4-server.tar.gz
cd FlashphonerWebCallServer-4.0.1212
./install.sh

The installer will ask for the IP address twice.
You must specify the IP address of the droplet both times.

The IP address is determined for example by the ifconfig command.



In our case, it is 46.101.139.106.

We get a free license and activate it after installation

cd /usr/local/FlashphonerWebCallServer-4.0.1212/bin
./activation.sh

We add support for the AAC codec in the settings and RTSP interleave mode

AAC is mpeg4-generic. We add the 'Interleave mode' in case the Wowza server has been configured to operate RTSP via TCP.

mc -e /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties

codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,h263,h263p,mpv
rtsp_interleaved_mode=true

We start the server

The server has been running for quite some time on the virtual machine. We are waiting for 1 minute. Before starting, it is advisable to register the server IP address and hostname (hostname) in / etc / hosts. Without this, there may be problems with the launch.

hostname
wcs

service webcallserver start

Install and run Apache

Apache will give a page with a test player.

yum install httpd
service httpd start

Deploying the VoW Player Example in the Web Directory

cd /var/www/html/
wget http://flashphoner.com/download-wcs4-client.tar.gz
tar -xvzf download-wcs4-client.tar.gz

Specify the URL to connect to the server and the stream to be picked up

mc -e /var/www/html/examples/min/vow-player-min.js

We connect to the server through Websocket:

var url = "ws://46.101.139.106:8080";

Take the stream from Wowza to RTSP:

var streamName = "rtsp://46.101.139.105:1935/live/myStream";

Open the player in iOS Safari

A simple HTML page opens : 46.101.139.106/examples/min/vow-player-min.html

The page has a video display area, two buttons and a display area of ​​the current playback status.



Start playback

Press 'Play' to start playback. We see that the internal iOS player does not connect and the video is played directly in the body of the HTML page. The controls 'Play' and 'Pause', as well as the status block, remain in place.





This is how a video stretched out full screen with your fingers looks like:



If you open the same page in Google Chrome and apply Developer Tools, you can see HTML5 canvas - the element into which the video is drawn.



If you dig deeper and look at the 'Network' tab, you can see many Websocket Binary Frames arriving at high speed - this is the video stream that we see on the HTML5 Canvas element.



Playback delay is fundamentally different from HLS and is only about 3 seconds. The picture is clearly visible. No artifacts. Audio and video act out synchronously without visible flaws.

As a result, we have the following broadcasting scheme:



It would also be interesting to conduct battery consumption tests. There is reason to believe that with VoW the battery runs out faster than with regular use of the HLS player, if only because with HLS hardware video decoding is possible, and in the VoW player the video is decoded using JavaScript.

As a result, we will draw a sign of the differences in the data of broadcast technologies.



Here, the complexity of the setup is understood as the input of an additional link (WCS server) and the VoW-Player itself, which accordingly increases the time and complexity of the system setup.

Below I leave demo urls with a video about a hare for those who wish to test on their own.

HLS (iOS Safari)

VoW (iOS Safari, Windows Google Chrome) I

do not guarantee uninterrupted operation of urls .

Special thanks to the hare Big Buck Bunny. Without it, such a colorful narrative would not have come out.