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:
- Introduction to UGC platforms
- Basic architecture design of UGC platform
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.1. Creator <-> Creator control panel
3.2. Creator control panel <-> Ingest server
3.3. Creator -> Streaming software or Web Browser
3.4. Streaming software or Web Browser -> Ingest server
3.5. Ingest server -> Transcoding server (optional)
3.6. Transcoding server -> DVR server (optional)
3.7. DVR server -> Origin server (optional)
3.8. Viewer <-> Viewer control panel
3.9. Viewer control panel <-> Creator control panel
3.10. Players, Web Browsers <-> Origin server
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.
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 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:
|Inputs||RTMP, WebRTC, SRT streams|
|Features||1. receiving streams
2. sending streams to the transcoding or origin server
3. multistreaming to other streaming platforms and socials
|Outputs||RTMP, WebRTC, SRT, M4S* streams|
M4S is a real-time streaming protocol for transmitting the video between Flussonic servers only. It is a codec-agnostic protocol, which means it supports any codec. Refer to M4F and M4S protocols to learn more about M4S.
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.
Remember that different protocols support different containers and codecs.
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 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 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 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.
To sum up:
|Inputs||RTMP, WebRTC, SRT, M4S streams|
|Features||1. changing audio and video parameters (codec, bitrate, container, etc.)
2. creating a multi-bitrate stream
3. overlaying logo
4. transporting streams via private IP network (M4S protocol highly recommended)
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.
|Inputs||1. streams from the ingest server (if transcoding server is not used)
2. transcoded streams (if transcoding server used)
|Features||1. recording and storing copies of incoming streams
2. working with the archive and its features (live-to-VOD, timeshift, etc.)
3. playing streams from the archive (rewind, watching the current live stream from the beginning)
|Outputs||1. transcoded streams (for live viewers)
2. copies of transcoded streams (for VOD users)
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.
|Inputs||1. transcoded streams (for live viewers)
2. copies of transcoded streams (for DVR users)
3. streams from the ingest server (if no transcoding and/or DVR server used)
|Features||delivering content to viewers|
|Outputs||HLS, MPEG-DASH, MSS, RTMP, LL-HLS, WebRTC|
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:
|Inputs||1. requests for URLs and stream keys from creators
2. requests for session keys from viewer control panel
3. requests for stream configuration from the servers in the pipeline
|Features||1. calculating stream configurations
2. provisioning stream configurations to the servers in the pipeline
3. providing stream keys for creators and session keys for viewers
|Outputs||1. URLs and stream keys for creators
2. session keys for viewers
3. stream configurations for a pool of servers in the pipeline
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:
|Inputs||requests for session keys|
|Features||providing session keys for viewers|
|Outputs||session keys for viewers|
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:
In the diagram above, we present our recommended UGC platform layout, which, in our experience, works most effectively.
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:
- 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.
- 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.
- 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.
One of the major features of Flussonic is that every time the Flussonic Media Server receives a stream, the stream is unpacked and then packetized again. If the input stream has minor issues, Flussonic makes the output stream more stable and the end-users happier with the QoE while playing the stream.
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:
- 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.
- 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 any stage of a content delivery pipeline: ingest, transcoding, DVR, origin.
Balanced Ingest Cluster
A reliable service must have no single point of failure to stay available. And to ensure that a system will keep working if one server fails and stops working a clustering mechanism is used. In Flussonic it is called cluster ingest.
Cluster ingest is a redundancy mechanism for ingesting streams in Flussonic. It involves duplicating the server instances to take over the streams if any of the active server instances go down. If a number of received streams is quite large, the streams will be evenly distributed among the server instances to prevent the overload. As soon as a failed server instance becomes available again, all the streams from that server will be restarted on that same server.
To learn more about ingesting streams in Flusssonic cluster, see Video Ingest in a Cluster.
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.
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:
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
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.
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.