One of the projects that we had at Oqtacore was implementation of a cross-platform webinar app.
Cross-platform webinar app stack
It was a multi-tenant app, meaning that various authors could have their own setups on the same server.
The main problem we had was achieving flawless playback for thousands of viewers simultaneously.
App framework
We wanted to have one source code for both desktop and mobile platforms. The webinar app needed to be developed very quickly, we have just 2 months to implement the app from scratch until the release. It meant that we had just one month to write the webinar app, and one more month to test it on all possible devices and fix numerous bugs.
Video protocol
We considered three protocols: HTTP, rtmp and rtsp. Some streaming protocols are good with wired connection, but show numerous artifacts with wireless connection. The difference comes from types of packages – UDP vs TCP.
RTMP vs RTSP vs HTTP
Hypertext Transfer Protocol (HTTP) refers to the protocol used to deliver webpages and images across the Internet worldwide. HTTP is an adopted, open standard—the most ubiquitous mode of delivery online. HTTP is a “stateless” protocol; think of it as an airline ticket to anywhere. HTTP can be delivered by a variety of web servers, both commercial and open source
The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between end points. Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server.
Real Time Messaging Protocol (RTMP) was initially a proprietary protocol developed by Macromedia for streaming audio, video and data over the Internet, between a Flash player and a server.
HTTP is less likely to be disallowed by routers, Network Address Translation (NAT), or firewall settings. No ports that are commonly closed by default need to be opened. Content is therefore more likely to get through to the client in more locations and without special settings. HTTP is also supported by more CDNs, a factor that can affect cost in large distribution models. In general, more available hardware and software works unmodified and as intended with HTTP than with RTSP or RTMP.
Expertise in customizing HTTP content delivery using tools such as Hypertext Preprocessor (PHP) is also more widespread. Additionally, for large-scale events, HTTP natively and easily supports mirroring and edge caching, providing for massive-scale expansion when needed for the largest events.
RTSP and RTMP can also be cached, but HTTP does so natively and without the need for proprietary or custom configurations. Access is another consideration.
Can everyone view your content after you make it available? From a site visitor’s point of view, one advantage of using HTTP is access. Many corporate networks use firewalls to block specific content. Popular methods of blocking are protocol and port restrictions. Some firewall rules allow only HTTP content served over port 80. However, this luxury is not always shared with RTMP-delivered Flash Video.
The default port for RTMP connections is 1935—a port that may not be allowed on tight firewalls. If the first attempt of the Flash Player to play video over port 1935 fails, it tries to reconnect using a few different methods.
To summarize, if you do not want to deal with firewalls and proxies, you should consider HTTP. One benefit with RTMP worth mentioning here is its ability to provide multicast support. If you run an enterprise and want to take one stream inside your corporate network and deliver it to many users without initiating a new connection for each user, RTMP is the best technology.
HTTP does not provide this function, nor do CDNs. Security is critical with a lot of content, and if you are a distributor or aggregator, you know the term digital rights management (DRM) all too well.
Can or will you allow your content to be saved locally on a user’s machine? RTMP has broad DRM support, and rights holders are very familiar with the ecosystem.
UDP vs TCP
TCP packages require acknowledgement by the receiving server. For each package A (usually, 64kb), the server expects a return package from the client, in which client says “I received package A”. If the message does not come, the server sends the same message again. Acknowledgement process compromises connection speed, but makes sure that each package arrives. Picture quality with TCP packages is ideal, but may be affected by low connection bandwidth and lag for bufferization.
UDP packages are sent without acknowledgement by client. Server sends each package exactly once and does not expect the client to receive them all. In an ideal environment, client receives all packages. Wired connections are close to ideal. Wireless connections can have very high loss rate (for example, with microwave turned on, we had loss rate of around 60%).
Streaming engine
After we selected the protocol for transmission for our webinar app, we needed a streaming mechanism for our cross-platform webinar app. It was a project based in Russia, and we selected Russian CDN (cloud distribution network) provider Ngenix. They used Wowza streaming engine to stream our mp4 files that we uploaded to their file server. Each stream URL had a timestemp token that was valid for 4 hours.
After that time, the user had to open the stream again. It allowed to secure the video from distribution.
Video player
For video playback of our cross-platform webinar app, we needed something that was available on each platform. An easy selection was to use libvlc – an underlying library of VLC player, known for being omnivorous in terms of various video formats. libvlc is a library built using C++, so it was very easy to integrate with the Qt QML app.
Unfortunately, we couldn’t just take some prebuilt libvlc binaries, as we needed to build our app for 4 different platforms. We used msvc compiler for Windows, xcode for macOS and iOS, and clang compiler for Android. For each of the platforms, libvlc was built from sources using Cmake.
App
The webinar app was cross-platform and we couldn’t have it exactly the same everywhere. It has some differences across platforms, like different file paths, permission systems, and of course, screen size.
The platform that we used, Qt QML, is perfect for handling these issues. It offers great customizability and performance, since the app is written in pure C++
Video protection
One of the important parts was video protection for our webinar app. Our tenants did not want the video viewers to be able to copy the video content, and video piracy in Russia is extremely popular. Most of the education courses only have live content paid, and all the recorded session are always distributed for free, as there is no way to protect it.
Through our app, more than $800k in content was sold, and we never saw a single video distributed through our app in free access.
The security consists of monitoring the apps that are active on the computer and some watermarks that allow to correctly identify the watcher, in case they decide to share their content on the web. It would allow to immediately identify the pirate and take legal action.
With our protection, we fought both screen sharing, screen recording, and video recording using a handycam/mobile phone.
Read about our other projects.
