Contact Us
Secure Video Conferencing LiveSwitch Cloud
Secure Video Conferencing LiveSwitch Cloud

Extend LiveSwitch Server applications with these top community developer tools

by Michelle Chen, on January 25, 2021

LiveSwitch Tools Cover - Server-1

When we set out to share LiveSwitch with the world, we had one vision in mind: to provide WebRTC developers and DevOps teams with the most flexible live video solution for the widest range of use cases.

In addition to regular LiveSwitch SDK releases for the incredible range of platforms and languages we support, we have also now made several open-source developer and DevOps tools available to the public. This blog post will discuss everything you need to know about LiveSwitch Connect, LiveSwitch Mux, and LiveSwitch Hammer and how to get started with them this year.

1. LiveSwitch Connect

LiveSwitch Connect can be used by developers to extend their WebRTC-based projects to capture media from non-standard sources (i.e. IP cameras, hardware capture cards, local media files, local screen capture, OBS studio) and also render and stream media out in other protocols (i.e. RTMP to YouTube). 

LiveSwitch Connect - Developer Tools For IP Device ConnectivityInfographic about LiveSwitch Connect Community Tool - For Linux, Windows, and MacOS

2. LiveSwitch Connect: HLS Demo

An example of LiveSwitch Connect is the open-source LiveSwitch HLS demo that establishes HLS (HTTP Live Streaming) with your LiveSwitch-based application.

What is HLS (HTTP Live Streaming)?

HLS (HTTP Live Streaming) is an adaptive bitrate streaming communications protocol originally developed by Apple for its iOS and macOS clients that was later extended to other platforms, browsers, and devices. HLS streaming can conveniently distribute video and audio streams across a content delivery network (CDN) and ensure that these streams are playable on virtually every device today. The wide-spread adoption of HLS streaming, despite its drawbacks and common criticisms about latency, has ensured its relevance in many broadcasting use cases.

HTTP streaming operates by splitting media recording into smaller chunks, measured in seconds, and transcoding them into a range of bitrates. The client's media player downloads these individual chunks over HTTP and, based on the client's network connectivity, will select the optimal bitrate for each chunk.

How Does HLS Streaming Work With LiveSwitch? 

LiveSwitch HLS listens for new connections using LiveSwitch webhooks and converts the connections into conventional latency HLS streams that can be played/paused/rewound in most HTML5 video players. LiveSwitch HLS is a convenient, open-source tool that provides developers the ability to switch on HLS streaming as they need it.

LiveSwitch HLS Streaming to HTML5 Player with ffmpeg

This demo documentation provides LiveSwitch developers the instructions to establish HLS streaming within their application. It is a Visual Studio project built using Node.js and TypeScript. After entering your LiveSwitchConsole and creating an application level webhook to detect client connection events, you are able to connect the media sources to LiveSwitch Connect and LiveSwitch HLS for subsequent output to an HTML5 player. Additionally, if the application is hosted on LiveSwitch Server, simply update the GatewayURL in the app.ts file to point to your LiveSwitch Gateway and follow the demo documentation to make it happen.

3. LiveSwitch Mux

LiveSwitch Mux is a media muxing tool that combines individual raw streams in a Media Server's file system into a single file (eg. MP4, MPG, AVI, MKV) once per LiveSwitch session. It scans recordings in your directory and looks for completed sessions to combine. Sessions are recordings of streams that use the same channel ID and application ID over the same time window.

Sessions are considered complete when:

  1. There are no active streaming connections associated with that particular application and channel ID (the session is considered inactive) and,

  2. there are no overlapping recordings. If a recording overlaps but it is active, the session is considered incomplete and will not be included.

LiveSwitch Server - Video and Audio Multiplexing Tool on GitHub

When do you need to use LiveSwitch Mux?

When audio and video streams are received by the LiveSwitch Media Server, the raw streams are recorded and written to separate files by default. This process is the most efficient for the server: data is written onto the disk with as little overhead as possible, ensuring that all available Media Server resources are allocated towards maintaining the highest quality live streaming possible for the client(s).

In other words, the audio and video encodings retain their original encoding format. For example, when a broadcasting client sends Opus & VP8 encoded streams to the Media Server, the Media Server will write the broadcast media as Opus & VP8 into a Matroska container format that is then stored in the file system.

However, creating a combined single file containing all media tracks from a completed session for viewing post-streaming is a different challenge altogether. Using our example above, merging multiple Opus audio and VP8 video tracks into a container file such as an MP4 file for playback requires a multiplexer (muxer for short).

Video Multiplexing - Use Cases

Subtitles, Closed Captioning, and Webcast Presentations

Combining raw media tracks from a LiveSwitch hosted Media Server into a playable output file opens up a new dimension of live video streaming. Media tracks that our customers have asked to be multiplexed in the past include 1) closed captioning, 2) subtitles, and 3) screen shared presentations. 

LiveSwitch Mux - Video Multiplexing Output File Layouts, JavaScript SolutionsLiveSwitch Mux serves as an extremely effective tool for media track mixing. However, as the possibilities of video multiplexing are endless, developers may arrive at scenarios where advanced muxing solutions can be a better, optimal fit for their use case. In those circumstances, our professional developers can help you achieve the desired results. 

Overall, LiveSwitch Mux enables developers to create fully customizable recordings from their raw audio and video streams for post-session viewing. With LiveSwitch Mux, developers can ensure that broadcasters can conveniently share the streamed content from their platform to session participants to replay on their compatible devices, while maintaining control over the characteristics of the output file.

4. LiveSwitch Hammer

Application testing is a critical step towards providing clients with the best possible streaming experience on a virtual event platform or application. Participants commonly decide whether they will enjoy their virtual fan experience based on first impressions. Lag, video and audio quality drops, and device connectivity errors can all detract from the participant’s experience. As a result, Frozen Mountain has released LiveSwitch Hammer, an open-source community tool for LiveSwitch DevOps engineers to augment their workflows.

What is LiveSwitch Hammer?

LiveSwitch Hammer allows DevOps engineers to run automated laboratory-style tests against a LiveSwitch Server deployment and confidently scale Media Servers with the knowledge that they are all operating correctly.

LiveSwitch Hamer - Global WebRTC Media Server Deployment, Monitoring, and Automated Scaling

Teams managing globally distributed LiveSwitch Media Servers can speed up testing, perform repeatable tests across all Media Server instances, and automate performance health scans of their Media Servers to ensure virtual platforms run smoothly.

WebRTC DevOps - Deploying LiveSwitch Hammer, Media Flow & Stream Connectivity Testing

The Three Types of Tests LS Hammer Can Perform:

LiveSwitch Hammer can perform three types of tests on a LiveSwitch Media Server.

  1. Scenarios that invoke clustering edge cases: Difficult, hard-to-reproduce edge cases can be tested and verified by repeatable, laboratory-style tests to ensure consistent client streaming experiences.

  2. Parallel and sequential load scenarios: DevOps engineers can use LiveSwitch Hammer to test the performance of different server shapes (instance types) using small, highly concurrent, consistent, opinionated, and repeatable load tests.

  3. Individual Media Servers for connectivity and media flow:
    Media Servers can be scanned continuously to ensure that connectivity can be established across all advertised options. Automating this as part of your infrastructure helps to immediately identify firewall misconfigurations and expiring TURNS certificates.

LiveSwitch Hammer requires .NET Core 3.1 or newer and LiveSwitch Server 1.11.1 or newer.

The Scan Verb - What Is It And What It Does

LiveSwitch Hammer’s scan verb is a fantastic addition to the LiveSwitch Hammer tool that enables DevOps teams to evaluate and diagnose the health of LiveSwitch Media Servers. The LiveSwitch Hammer tool provides an additional layer of security and confidence that the Media Servers are operational. In other words, we provide DevOps engineers with the flexibility to run additional checks as required.

LiveSwitch Hammer - Scanning Media Server Health, Automated Performance Scans, WebRTC Monitoring

Wrapping It Up

In the spirit of making LiveSwitch the most flexible live video platform & API out there, we have released a series of community developer tools. LiveSwitch Connect, LiveSwitch HLS, LiveSwitch Mux, and LiveSwitch Hammer empower software developers and DevOps engineers to customize their LiveSwitch-powered applications beyond what is possible. For full, advanced customizations and project build outs that extend beyond the scope of these community tools, start the conversation with our Professional Services team to make your dream platform a reality.

Topics:LiveSwitch
Michelle Chen

Michelle Chen

Michelle is a Marketing Communications Associate at Frozen Mountain Software. As a digital marketing professional, she’s constantly seeking opportunities to connect live video streaming application developers with the solutions offered through Frozen Mountain’s suite of live video SDKs.