Flussonic UGC Implementation Guideline

This guideline explains how to build a UGC service or platform with a Flussonic Media Server. Flussonic Media Server is a multi-purpose software solution for launching a high-load video streaming service of any scale. This document is intended for people who are willing to create their own UGC service or platform, are curious to learn how to build one, or are already taking their first steps in that direction. This document doesn't include information about installing or configuring the Flussonic Media Server. For information on installing Flussonic Media Server and getting started with it, see Installation and Quick Start.

"Introduction to UGC platforms" gives a brief overview of what UGC platform is, its features and application. In "Basic architecture design of UGC platform", we discuss the basic architecture design of a UGC platform/service, its components, intercommunication between the components, and ways to make your system resilient and scalable. A real-life project is examined in "Plan and Deploy: Real-Life Example".

Table of contents:

1. Introduction to UGC platforms
2. Basic architecture design of UGC platform
   2.1. Components
   2.1.1. Ingest server
   2.1.2. Transcoding server (optional)
   2.1.3. DVR server (optional)
   2.1.4. Origin server
   2.1.5. Creator control panel
   2.1.6. Viewer control panel
3. Workflow
4. Making a reliable service
   4.1. Several Publishing Points
   4.2. Loadbalanced Transcoding Cluster
   4.3. DVR Cluster
   4.4. CDN
5. Plan and Deploy: Real-Life Example
   5.1. Analysis Stage
   5.1.1. Step 1. Define a Niche
   5.1.2. Step 2. Define Your Target Audience
   5.1.3. Step 3. Define the Type of Content and Profiles of Creators
   5.1.4. Step 4. Define the Key Features

Introduction to UGC platforms

User-generated Content (UGC) is any form of content (videos, images, reviews, posts, etc.) created by people and published online.

UGC is a great marketing method for promoting products and services. It helps to build a brand community, gain consumers' trust, raise awareness, and engage with the audience. Encouraging consumers to share their experiences and thoughts about the product or service helps to establish an online presence, build the brand reputation, and boost conversion.

You can come across plenty of examples of user-generated content on the Internet. We watch it on a daily basis: video game walkthroughs, smartphone reviews, podcasts about finance and investing, recipes, style tips, etc. Webcam broadcasts can also be considered as UGC. For instance, webcam in the docks can show ships passing by. Webcam on the beach shows the current weather, surf conditions, and beach activity. There are even websites where you can watch what is happening in a particular part of the world in real time.
The amount of user-generated content is growing every day, as is the number of web resources where this content can be published. UGC platforms are required to gather, manage, explore and arrange this content.

User-generated content (UGC) platform is a software-as-a-service (SaaS) solution that is used to collect and manage the content shared by consumers.

UGC platforms may focus more on a particular form of content, like reviews, comments, ratings, visuals, etc. We will focus on live streaming and broadcasts — UGC streaming platforms, for instance, Twitch. Such platforms are used to stream and host videos for various purposes: from video game live streaming to business events.

The range of applications of UGC-platforms is limited only by the Internet availability. Today UGC-platforms are used in:

• gaming (live broadcasts of tournaments and competitions in cybersports, walkthroughs and reviews of video games, etc.)
• sports (live broadcasts and recordings of tournaments and competitions in various kinds of sports)
• education (live broadcasts and recordings of lectures, seminars, webinars, etc., recordings of courses and specializations)
• religion (live broadcasts and recordings of worship services)
• events (presentation of a new smartphone model, broadcasts of cultural events, etc.)

Here are some of the features UGC platforms/services offer to their customers:

• Streaming to multiple platforms
• Monetization (subscriptions)
• Live and VOD streaming
• Pre-recorded live streams
• Recording and storing streams
• Live to VOD
• Rewinding, and more.

Basic architecture design of a UGC platform

Let's dive into an architectural level of a UGC platform to see what is happening under the hood. In this section, you will discover:

• stream journey from the author to the viewer
• what elements make a UGC platform
• how do these elements connect
• how to make your system resilient and scalable

The diagram below shows a recommended UGC platform architecture design which, in our experience, allows you to build the most effective system:

Pic 1. UGC platform architecture design

First, we will have a look at the key components that keep UGC platforms up and running.

Key components

Here are the key components that are used to build up a UGC platform/service:

• Ingest server
• Transcoding server (optional)
• DVR server (optional)
• Origin server
• Creator control panel
• Viewer control panel

We will explore every one of them more in depth.

Ingest server

Ingest server is required to receive a stream from a streaming software or a web browser. An ingest server takes an RTMP, SRT or WebRTC stream in and then transports it to either the transcoding server (if required) or the origin server.

You can multistream the content as-is to multiple streaming platforms, such as YouTube or Twitch, to increase your reach. This way, you provide viewers with the opportunity to choose the best streaming platform for watching.

Flussonic Media Server can receive streams from various sources and of different formats. For more information about the types of sources and their configuration in Flussonic, see Data source types.

To learn how to push the stream from OBS to Flussonic Media Server, see Publishing a stream from OBS Studio to Flussonic Media Server.

We summarized all the information in the table below:

Transcoding server (optional)

A transcoding server is essential, if you want your content to reach as many viewers as possible. Transcoding server takes the incoming stream from the ingest server and transcodes it into an array of streams at different resolutions and bitrates. It is used for adaptive bitrate streaming to deliver the content that matches the viewers’ available bandwidths and devices.

Let's look into what transcoding is and what it is not.

Transcoding implies both decoding and encoding. Decoding is a process of decompressing compressed data into a raw format. Encoding is a process of compressing raw uncompressed data to be sent over the Internet. During encoding, various video parameters, such as resolution, bitrate, and type of compression, are determined. Both encoder and decoder rely on codec — an algorithm of video/audio compression. A video codec affects file size and image quality. H.264 and AAC are the most commonly used video and audio codecs for live streaming.

So transcoding is a process of decoding the stream, performing some kind of modifications to the video and/or audio parameters of the content, and then re-encoding the stream to be transmitted over the Internet.
Transcoding is commonly referred to as an umbrella term for the following media tasks:

• Transcoding

Transcoding refers to a process of changing a video and/or audio codec, or a type of compression. For instance, you can take MPEG2 video and convert it to H.264 video.

• Transsizing

Transsizing refers to a process of resizing a video frame and modifying resolution, such as bringing down 3840×2160 (4K) resolution to 1920×1080p and/or 1280×720p, 640×480p, etc.

• Transrating

Transrating refers to a process of lowering bitrates, such as taking a 4K video at 45 Mbps and converting it to one or more lower-bitrate streams: 4K at 15 Mbps, Full HD (1080p) at 5 Mbps, HD (720p) at 2 Mbps, 480p at 1 Mbps, etc.

One or a combination of the preceding tasks refers to transcoding.

Pic 2. Example of transcoding

After the video and audio streams are compressed with codec, they are packed into a container — a wrapper that stores the video stream, audio stream, and metadata (bitrate, resolution, subtitles, etc.). At this point, it makes a video file that can be further delivered via a streaming protocol, like HLS, MPEG-DASH, etc.

A process of changing container and streaming protocol without modifying the actual video and/or audio content is called transmuxing (also referred to as packetizing, repackaging, or rewrapping). Receiving an RTMP stream from an IP camera and transforming it to an HLS stream for playback is an example of transmuxing.

Transcoding ≠ transmuxing as they operate on different levels (transcoding — content/data, transmuxing — container and streaming protocol) and should not be confused.

Transcoding is a computationally expensive process, and it puts a heavy workload on the CPU and GPU, unlike transmuxing, which takes much fewer resources.

Suppose you want to stream a cyber sport event online in 4K at 45 Mbps using H.264 codec and SRT encoder. If you attempt to deliver such a stream to your viewers directly as it is, your audience will have trouble playing the stream. Here is why:

• Not every device supports 4K resolution. Some displays do not support 4K resolution, which results in an inability to play the content.
• Lack of available bandwidth to watch 4K. Unstable/poor internet connectivity or insufficient bandwidth can cause 4K chunks of data to load for a long time (or not load at all). It results in constant buffering for a player.

Consequently, without transcoding you will cut out almost everyone with slower internet speeds, tablets, mobile phones, gaming consoles, and STBs. Transcoding ensures your stream is watchable on lower-speed internet connections and various devices.

With Flussonic, you can do all the necessary transcoding and transmuxing operations to the video and audio streams.

For more information about transcoding and supported codecs and protocols, see Transcoding and Supported protocols and codecs.

To sum up:

DVR server (optional)

DVR server takes all incoming video streams and archives them for the VOD system. DVR server provides your viewers an opportunity to pause, rewind, fast-forward, re-watch, and record any live stream and watch it at a later time.

Flussonic Media Server provides a wide range of features to work with the archive, such as recording and saving live streams as a VOD file, i. e. live-to-VOD feature, broadcasting in different time zones, i. e. timeshift, etc.

For more information about DVR and its features, see: DVR.

DVR is optional in a UGC platform's workflow. If you do not want to provide the live-to-VOD feature for your viewers, then you can skip the DVR. However, nowadays, it is hard to imagine a UGC service without the rewinding feature.

In conclusion:

Origin server

Origin server delivers the content directly to the viewers. Origin server captures the streams from the transcoding server or the ingest server and viewers fetch streams directly from the streaming origin server.

Then:

Creator control panel

Creator control panel is an orchestration system that manages stream configuration, creator's authentication and authorization.

Before a creator starts streaming, they have to request a URL and a key from the streaming platform. Here is when the creator control panel comes into play. It verifies the creator's identity and if they have permission to stream. Once the author passes the authentication and authorization stages, control panel returns the URL and stream key.
The creator control panel uses the system management database. System management database stores the pipeline configuration, stream configurations, stream keys for creators, and session keys for viewers. The creator control panel calculates the configuration for the servers in the pipeline based on the pipeline configuration and available hardware resources and provisions the stream configurations to this pool of servers. Provisioning is a process of providing a server with configuration to run a piece of hardware resource in runtime. Provisioning is the process of turning the desired configuration into a real one and uploading it to a server.

Summarizing the above:

Viewer control panel

Viewer control panel is a system that manages viewer's play sessions, viewer's authentication and authorization.

To watch a live stream viewers should retrieve a playback URL. To do so, viewers request a playback URL from the viewer control panel. The viewer control panel then requests a session key for the streaming session from the system management database. If a viewer is allowed to access the stream, the system then returns a playback URL that can be opened in a browser or media player to watch the stream contents.

To sum up:

Workflow

In this chapter, we will delve into how the UGC platform works, specifically, what steps the content goes through to get to the viewer's screen.

Let's get back to our diagram of a UGC platform:

1. Creator <-> Creator control panel

The communication between the creator and the creator control panel is bidirectional and is based on a request-response model. And here is how it goes:

1. Requesting a URL and a stream key

Before the start of streaming, a creator needs to set up streaming software. And to finish that setup, a creator needs a URL and a stream key. The URL and the stream key let the software know where to send the content to (publishing point). So the creator requests the URL and the stream key from the streaming platform.

1. Saving the stream configs

The creator control panel calculates the configuration for an incoming stream based on the pipeline configuration and available hardware resources. Once the stream configuration is calculated, it is saved to the system management database.

1. Returning the URL and the stream key

Then the creator control panel returns the URL and the stream key to access the publishing point.

2. Creator control panel <-> Ingest server, origin server

Having saved the stream configuration in the system management database, the creator control panel provisions the static stream configuration to all the servers in the pipeline. It creates the publishing point of the ingest server to receive the incoming stream.

3. Creator -> Streaming software or Web Browser

Then the creator provides the URL and the stream key to the streaming software or a browser to start streaming.

4. Streaming software or Web Browser -> Ingest server

As the software setup is finished, the creator can start streaming. The stream is pushed to an ingest server via WebRTC (for browser), RTMP, or SRT (for streaming software).

5. Ingest server -> Transcoding server (optional)

The ingest server also multistream to socials and other platforms, like YouTube, LinkedIn, etc.

Repackaging the incoming stream to the proprietary Flussonic-to-Flussonic M4S protocol, the ingest server pushes the stream to the transcoder, DVR, or origin server, depending on the pipeline.

6. Transcoding server -> DVR server (optional)

A transcoding server receives the M4S stream and unpacks and decodes it, getting to the raw video and audio. Then it creates multiple renditions of the same stream at different bitrates and resolutions.

DVR server ingests M4S streams from the transcoding server and stores the copies of those streams.

7. DVR server -> Origin server (optional)

The origin server ingests M4S streams from the DVR server.

8. Viewer <-> Viewer control panel

The communication between the viewer and the viewer control panel is bidirectional and is based on a request-response model (same as between the creator and the creator control panel) and looks as follows:

1. Requesting a URL to watch a streaming session

To watch the stream, a viewer needs a URL. So a viewer requests this information from a viewer control panel.

1. Returning the URL

After the playback URL is created, the viewer control panel returns it to a viewer.

9. Viewer control panel <-> Creator control panel

The viewer control panel requests a session key (PLAY_KEY) from the system management database in the creator control panel to create a playback URL.

10. Players, Web Browsers <-> Origin server

Finally, the origin server delivers the streams to players and/or web browsers. Depending on the application, the viewer can open a URL in a browser or media player.

Making a reliable service

This section provides architecture design ways to build your system so that it can handle failures and scale in response to changes in workloads and user demands. It is essential for a reliable service to keep responding to customer requests in spite of a high demand on the service or a maintenance event. The following features of Flussonic Media Server will help you to create a stable system so that your service won't suddenly fail and stays available on every stage of a content delivery pipeline.

Several Publishing Points

To ensure the system is reliabe and functions effectively when accepting the publishing of streams, publishing point redundancy is needed.

The redundancy of publishing points implies allocating a separate pool of servers to receive publishing streams based on server load or the creator's geographical location. Here is how we have implemented the mechanism of publishing point redundancy in Flussonic Cloud:

We use at least two DNS entries so that the creator always connects to at least one active server. We also have a separate sub-domain for each project. This way, we can provide a pool of servers based on server load or, for example, the creator's geographical location.

As a result:

• multiple DNS entries for redundancy
• a separate domain for each project to balance requests for publishing streams more accurately and allocate resources.

Loadbalanced Transcoding Cluster

To create a redundant architecture for failover of transcoding server instances clustering mechanism is used. In case one transcoding server instance fails, other instances should be able to start the processes on their end and perform the transcoding. This way the service will keep working as expected.

To learn how to configure a redundant transcoding cluster in Flussonic, see Redundant transcoder configuration with cluster ingest.

The requests of ingest server instances should be loadbalanced between the cluster of transcoding server instances to prevent the overload. See Load balancing in Flussonic to learn how to configure loadbalancing in Flussonic.

DVR Cluster

It is critical for a reliable service to backup a DVR archive and to avoid the data loss because of a sudden outage, system failure or any other issue.

Flussonic provides a wide range of tools to backup a DVR archive and keep it available at all times, such as:

• replication

A DVR archive is stored on two or more server instances, where one is a primary server and the others are secondary servers. Streams are pulled from the source and stored on the primary server to then be replicated to the secondary server.

To learn more about replication and its configuration, see Replication

• cross-replication

Two servers, a primary and a secondary one, are used to record the archive. Both of these servers can access the source and retrieve streams from it, as well as retrieve the archive from each other. Cross-replication allows you to restore missing parts of the archive after the temporary unavailability of one of the servers and synchronize data between them. Thus, continuous availability of the archive and data redundancy is ensured.

Refer to DVR Cross Replication to learn more about cross replication and its configuration in Flussonic.

• Flussonic RAID

Flussonic RAID is an application-level RAID (Redundant Array of Independent Disks) offering high reliability, efficiency, and convenience when writing video data to dozens of disks, creating a single array. RAID allows you to increase performance and data redundancy of a system as well as increase storage capacity.

To learn more about Flussonic RAID, its features and configuration, see Flussonic RAID for DVR.

• cluster DVR and segmented cache

To record the archive several DVR-servers are used, one of which is the primary, and the others are secondary. According to statistics, up to 90% of all views of live broadcast recordings occur in the next 24 hours after the live stream, so when broadcasting large-scale events it is necessary to use SSD to reduce the load from HDD. Flussonic can use a separate segmented cache on the SSD to take the load off the HDD. You can use the segment cache on a secondary server to store the DVR, but the primary server will actually manage the entire archive.

To learn more, see Cluster DVR.

CDN

With the increasing number of viewers and amount of output traffic, at some point one server becomes incapable of handling the delivery of streams anymore. As the viewers from all over the world tune in, it becomes challenging to provide them with a good and reliable service. It makes it overwhelming for an origin server to serve more and more requests at a time.

Here comes CDN (Content Delivery Network). Having multiple servers distributed across various geographic locations, CDN provides an efficient delivery of the content worldwide, narrowing the distance between the edge server and the viewer and, hence, minimizing latency and allowing faster access to the content. CDN caches the content in different PoPs (points of presence) to deliver it directly to the viewer. CDN also improves the overall streaming performance by distributing the workload over multiple servers and unloading the origin server to keep it up and running.

Thus, CDN provides availability, reliability, scalability and efficiency, while delivering the content to the viewers.

To learn more about setting up CDN in Flussonic, see Setting up CDN. Flussonic also works with other CDNs, like Akamai, refer to Example: pushing a stream to the Akamai CDN to learn more.

Plan and Deploy: Real-Life Example

This chapter is devoted to developing a strategy for a small UGC streaming service — a virtual event platform. You will explore the business analysis stage as well as the technical requirements for the service.

Analysis Stage

In the analysis stage, you'll figure out what you're going to do, for whom, and how. Let's move step-by-step:

Step 1. Define a Niche

The first step in building your own UGC streaming service or platform is to choose the kind of market area your service will serve to. Is it going to be health & fitness, online learning, arts and crafts or gaming, and so on? Will it cover only one use case or several ones? Defining your niche is crucial for a UGC streaming service or platform to know the main purpose of your service.

The example platform that will be created along the line is focused on virtual events like virtual conferences and summits, webinars, online workshops, virtual corporate events, and so on for both big and small companies.

Step 2. Define Your Target Audience

Once the niche is found, you need to define who your audience is and what they want. You have to answer the questions like:

• What do your viewers have in common?
• What does your audience get from watching the content (education, entertainment, sport, etc.)?
• How do viewers prefer to consume it (laptop, mobile phone, and so on)?

By answering these questions, you will get a better understanding of your audience and what they expect from your UGC streaming service or platform.

For the virtual events platform, the audience depends on the type of hosted event. If it is a corporate event, then the audience includes employees, stakeholders, board members, or even clients and customers.

Step 3. Define the Type of Content and Profiles of Creators

As the niche is found and you know what your target audience is, it is time to determine what type of content you want to provide and who will be creating this content. Determine what your target audience needs and their preferences to define what content they will watch.

Let's consider Twitch, for example. Twitch was initially created as a live streaming platform for gamers. So the primary types of content are video game live streaming and eSports competitions. In this case, gamers and tournament organizers are the content creators.

Virtual event platform is focused on various virtual or online events: from conferences and webinars to corporate parties. The content creators are the ones who host events — separate employees, companies, or groups of companies.

Step 4. Define the Key Features

When creating a service or a platform, you must provide features for your customers that meet their needs and demands.

Below are some of the features of UGC platforms:

• support for using VMix, OBS, Atemi, HDMI-RTMP converters, video editing consoles, and various browsers to publish streams to the server
• recording live streams and storing them
• multistreaming to social media
• failover and backup
• preparing multi-bitrate streams
• scalability and load balancing
• accessibility from any device and browser
• data and analytics
• embedded media player
• uploading pre-recorded streams
• authorizatoin system
• monetization
• subscription system, and so on.

Depending on the goals and objectives of the platform/service, allocated budget, and available hardware and software resources, the set of features will vary.

For example, our virtual event platform will:

• support VMix, OBS,
• record live streams and store them so the viewers can watch them later
• provide failover and backup to keep the platform/service up and running if any issues occur
• prepare multi-bitrate streams to ensure viewers with slow internet connection can still watch the stream
• manage the available resources efficiently at uneven server loads
• make watching the content accessible from any mobile devices and browsers
• provide statistics of a system performance
• authenticate and authorize viewers and creators.