Stories by OvenMediaEngine on Medium

Low-Latency HLS: The Era of Flexible Low-Latency Streaming

OvenMediaEngine — Mon, 13 Jan 2025 12:40:19 GMT

Through this three-part series, we will explore ultra-low latency streaming with WebRTC in Part 1, various tests with HLS in Part 2, and finally, Low-Latency HLS in the last part.

In a previous post, we explored various ways to achieve low-latency streaming in HTTP Live Streaming (HLS) while maintaining stability and quality, such as adjusting the Segment Duration, examining the impact of Keyframe Interval on quality, and more. While we were able to reach impressive low-latency levels numerically, we concluded that commercializing this approach presents significant challenges. Today, we will dive into Low-Latency HLS (often abbreviated as LL-HLS, though we will refer to it as Low-Latency HLS) and examine how it achieves low-latency streaming while maintaining stability and scalability.

Additionally, using OvenMediaEngine, we focused on the stability, balance, and latency of Low-Latency HLS, achieving a latency of approximately 1 to 4 seconds. In this post, we share the testing process and results.

What is Low-Latency HLS?

Low-Latency HLS is an extension of the HLS protocol that enables low-latency video streaming while maintaining scalability and stability.

Backward Compatibility of HLS

Since Low-Latency extensions are additions rather than replacements, servers should be prepared to support regular-latency playback of HLS to allow clients to fall back to standard playback if they determine that low-latency requirements are not met.

Therefore, it provides backward compatibility, and the usage notes of each version are as follows —

About the EXT-X-VERSION tag | Apple Developer Documentation

You must use an #EXT-X-VERSION:3 or higher if you have floating point #EXTINF duration values.
You must use an #EXT-X-VERSION:6 or higher if you have #EXT-X-MAP in a Media Playlist that does not contain #EXT-X-I-FRAMES-ONLY.
You must use an #EXT-X-VERSION:9 or higher if you have #EXT-X-SKIP.
You must use an #EXT-X-VERSION:10 or higher if you have #EXT-X-SERVER-CONTROL, #EXT-X-PART-INF, #EXT-X-PRELOAD-HINT, #EXT-X-RENDITION-REPORT, and more for Low-Latency.

Although it is officially stated that HLS supports low-latency streaming starting from version 10, Low-Latency HLS has been researched and extended over a long period, so there may be versions other than version 10 that support low-latency streaming depending on the method used.

How Does Low-Latency HLS Reduce Latency?

To achieve low-latency stream playback, backend production tools and content delivery systems must adopt updated protocols and implement additional rules. This article explores the core concepts and mechanisms that enable Low-Latency HLS to achieve reduced latency:

Partial Segments

Low-Latency HLS provides a parallel channel for distributing media at the live edge of the Media Playlist, which divides the media into a larger number of smaller files, such as CMAF Chunks. These smaller files are called HLS Partial Segments. Because each Partial Segment has a short duration, it can be packaged, published, and added to the Media Playlist much earlier than its Parent Segment —

Enabling Low-Latency HTTP Live Streaming (HLS) | Apple Developer Documentation

How It Works:

Partial Segments are created and sent to the Media Playlist shortly after being generated. This means they can reach the viewer much faster than waiting for a full segment to complete.
Moreover, they break away from the traditional rule that HLS segments must always start with a keyframe. If a Partial Segment is marked with the INDEPENDENT=YES tag, playback can begin from that point.
To reduce the bloat of the Playlist, the server removes Partial Segments from the Media Playlist once they’re greater (older) than three target durations from the live edge.

Container: The MPEG-4 Fragment is specified in the ISO Base Media File Format (ISOBMFF), and RFC8216bis provides a detailed definition of Fragmented MP4 (fMP4) as one of the Supported Media Segment Formats. The Common Media Application Format (CMAF) header meets all these requirements. Additionally, according to the RFC8216bis specification, not only CMAF but also MPEG-2 TS can be used for Partial Segments —

HTTP Live Streaming 2nd Edition

Tags and Attributes:

#EXT-X-PART-INF: The EXT-X-PART-INF tag provides information about the Partial Segments in the Playlist.
PART-TARGET: PART-TARGET indicates the Part Target Duration.
#EXT-X-PART: The EXT-X-PART tag identifies a Partial Segment.
URI: The value is a quoted-string containing the URI for the Partial Segment.
DURATION: The value is the duration of the Partial Segment.
INDEPENDENT: The value is YES if the Partial Segment contains an independent frame.
#EXT-X-SERVER-CONTROL: The EXT-X-SERVER-CONTROL tag allows the Server to indicate support for Delivery Directives.
PART-HOLD-BACK: The value indicates the server-recommended minimum distance from the end of the Playlist at which clients should begin to play or to which they should seek when playing in Low-Latency Mode. Its value must be at least twice the Part Target Duration. Its value should be at least three times the Part Target Duration. If different Renditions have different Part Target Durations then PART-HOLD-BACK should be at least three times the maximum Part Target Duration.

For example:

#EXTM3U
#EXT-X-VERSION:10
#EXT-X-TARGETDURATION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.500000
#EXT-X-PART-INF:PART-TARGET=0.500000
...
#EXT-X-PART:DURATION=0.500,URI="part_1_31_0_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.500,URI="part_1_31_1_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.500,URI="part_1_31_2_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
#EXT-X-PART:DURATION=0.500,URI="part_1_31_3_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.500,URI="part_1_31_4_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
...

Playlist Delta Updates

Clients transfer playlists more frequently with Low-Latency HLS. They can request and servers can provide Playlist Delta Updates, which reduce this transfer cost. These updates replace a considerable portion of the Playlist that the client already has with the new #EXT-X-SKIP tag —

Enabling Low-Latency HTTP Live Streaming (HLS) | Apple Developer Documentation

Blocking Playlist Reloads

The Low-Latency HLS Player initially requests the latest Playlist from the Server and subsequently uses special query parameters called Delivery Directives to request specific Playlists containing future Segments. The server then holds onto the request (blocks) until a version of the Playlist containing that segment is available. Because the Server responds immediately after the Playlist is updated, the data is buffered more quickly on the Player side. This mechanism, known as Blocking Playlist Reloads, eliminates the need for Playlist polling and enables efficient client notification of new Media Segments and Partial Segments —

Enabling Low-Latency HTTP Live Streaming (HLS) | Apple Developer Documentation

Tags and Attributes:

#EXT-X-SERVER-CONTROL: The EXT-X-SERVER-CONTROL tag allows the Server to indicate support for Delivery Directives.
CAN-BLOCK-RELOAD: The value is YES if the server supports Blocking Playlist Reload.

For example:

#EXTM3U
#EXT-X-VERSION:10
#EXT-X-TARGETDURATION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.5
#EXT-X-PART-INF:PART-TARGET=0.500000
#EXT-X-MEDIA-SEQUENCEa:24
…

Preload Hints and Blocking of Media Downloads

The Low-Latency HLS Player receives the next Playlist from the Server and uses the #EXT-X-PRELOAD-HINT tag to pre-request upcoming Partial Segments or Media Initialization Sections. A client can issue a GET request for a hinted resource in advance, and the Server holds the request, responding immediately when the media becomes available. This mechanism eliminates unnecessary round trips and supports the delivery of low-latency streams at a global scale, making it particularly effective when playlist download speeds are slow —

Enabling Low-Latency HTTP Live Streaming (HLS) | Apple Developer Documentation

Tags and Attributes:

#EXT-X-PRELOAD-HINT: The EXT-X-PRELOAD-HINT tag allows a Client loading media from a live stream to reduce the time to obtain a resource from the Server by issuing its request before the resource is available to be delivered. The server will hold onto the request (“block”) until it can respond.
TYPE: The value is the type of the hinted resource. If the value is PART, the resource is a Partial Segment.
URI: The value is a quoted-string containing a URI identifying the hinted resource.

For example:

…
#EXT-X-PART-INF:PART-TARGET=0.500000
…
#EXT-X-PART:DURATION=0.500,URI="part_1_31_7_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.500,URI="part_1_31_8_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.500,URI="part_1_31_9_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part_1_31_10_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
…

Rendition Reports

The Rendition Reports feature allows the Player to efficiently switch between renditions by providing direct information about the current playback position in other renditions. Normally, the Player would need to request the Multivariant Playlist (e.g., chunklist_0_video_llhls.m3u8), find the correct playback position, and determine the appropriate _HLS_msn and _HLS_part parameters to request the next Segment or Partial Segment. With Rendition Reports, the #EXT-X-RENDITION-REPORT tag provides the last Media Sequence Number (_HLS_msn) and Partial Segment Number (_HLS_part) for each rendition, allowing the Player to request the required Chunklist and media directly. This streamlines the switch renditions with a minimum number of round trips and minimizes latency during playback transitions —

Enabling Low-Latency HTTP Live Streaming (HLS) | Apple Developer Documentation

Tags and Attributes:

#EXT-X-RENDITION-REPORT: The EXT-X-RENDITION-REPORT tag carries information about an associated Rendition that is as up-to-date as the Playlist that contains it.
URI: The value is a quoted-string containing the URI for the Media Playlist of the specified Rendition.
LAST-MSN: The value specifies the Media SequenceNumber of the last Media Segment currently in the specified Rendition.
LAST-PART: The value indicates the Part Index of the last Partial Segment currently in the specified Rendition whose Media Sequence Number is equal to the LAST-MSN attribute value.

For Example:

…
#EXT-X-PART:DURATION=0.500,URI="part_1_33_6_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
#EXT-X-PART:DURATION=0.500,URI="part_1_33_7_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl",INDEPENDENT=YES
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part_1_33_8_video_vXjbEtmq_llhls.m4s?session=23_0Ec5agfl"
#EXT-X-RENDITION-REPORT:URI="chunklist_0_video_llhls.m3u8?session=23_0Ec5agfl",LAST-MSN=33,LAST-PART=8
#EXT-X-RENDITION-REPORT:URI="chunklist_2_video_llhls.m3u8?session=23_0Ec5agfl",LAST-MSN=33,LAST-PART=8
#EXT-X-RENDITION-REPORT:URI="chunklist_3_video_llhls.m3u8?session=23_0Ec5agfl",LAST-MSN=33,LAST-PART=8

Delivery Directives

A server may provide a set of services to its clients by implementing support for Delivery Directives. These Delivery Directives include —

HTTP Live Streaming 2nd Edition

Tags and Attributes:

_HLS_msn=: Indicates that the server must hold the request until a Playlist contains a Media Segment with Media Sequence Number of M or later.
_HLS_part=: Indicates, in combination with _HLS_msn, that the server must hold the request until a Playlist contains Partial Segment N of Media Sequence Number M or later.

For example:

[Latest Playlist]
https://domain/app/stream1/chunklist_1_video_llhls.m3u8

[Future Playlist]
https://domain/app/stream1/chunklist_1_video_llhls.m3u8?_HLS_msn=31&_HLS_part=3

Low-Latency HLS Optimization and Performance Analysis in OvenMediaEngine

You can configure OvenMediaEngine for Low-Latency HLS to achieve stability, balance, or low latency according to your environment, situation, and objectives. The OvenMediaEngine team conducted various performance tests for Low-Latency HLS by adjusting key parameters —

Low-Latency HLS | OvenMediaEngine

OvenMediaEngine LLHLS Configuration

Partial Segment Duration: This is represented as in the OvenMediaEngine settings. In the tests below, it was set to 0.2–1 seconds.
Segment Duration: This refers to the length of a Segment and is represented as in the OvenMediaEngine settings. While Apple recommends 6 seconds, the tests below used a value of 4 seconds.
Segment Count: This indicates the number of Segments listed in the Playlist and is represented as in the OvenMediaEngine settings. This value has little effect on Low-Latency HLS players, so the tests followed Apple’s recommendation of 10 segments. Do not set below 3. It can only be used for experimentation.
Part Hold Back: This is represented as in the OvenMediaEngine settings and refers to the additional buffer time a Low-Latency HLS player must hold before playback to ensure streaming stability. The Part Hold Back value must be at least 2–3 times the Part Target Duration according to the rules. Based on this, the configuration below was set to 0.6–3 seconds, which is three times the already configured Partial Segment Duration of 0.2–1 seconds.

#01. Configuration — Focus on Stability

Configuration:

Partial Segment Duration (): 1 second
Segment Duration (): 4 seconds
Segment Count (): 10
Part Hold Back (): 3 seconds

This configuration prioritizes stability in environments with high network instability. The longer Part Hold Back time reduces buffering risk but results in increased overall latency.

Result: 112 frames (3.734 seconds) latency
Server Buffer: 0.1 to 0.9 seconds
Part Hold Back: 3 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

#02. Configuration — Focus on Balance

Configuration:

Partial Segment Duration (): 0.5 seconds
Segment Duration (): 4 seconds
Segment Count (): 10
Part Hold Back (): 1.5 second

This balanced configuration aims to achieve moderate streaming stability and low latency, making it suitable for most low-latency streaming services.

Result: 58 frames (1.934 seconds) latency
Server Buffer: 0.1 to 0.5 seconds
Part Hold Back: 1.5 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

#03. Configuration — Focus on Low-Latency

Configuration:

Partial Segment Duration (): 0.2 seconds
Segment Duration (): 4 seconds
Segment Count (): 10
Part Hold Back (): 0.6 seconds

This low-latency configuration achieves the lowest possible latency but increases the risk of buffering in unstable network conditions or under high server load. It may not be suitable for most streaming services where stability is crucial.

Result: 31 frames (1.034 seconds) latency
Server Buffer: 0.1 to 0.2 seconds
Part Hold Back: 0.6 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

Analysis and Insights

Reducing the from 1 second to 0.2 seconds significantly decreased total latency from 3.734 seconds to 1.034 seconds. This is a key benefit of Low-Latency HLS, as it allows the transmission of smaller units of segments.
Reducing the Part Hold Back value decreases latency, but values that are too small can increase the risk of buffering.

Optimal Configuration Selection

Based on the test results, OvenMediaEngine recommends the following Low-Latency HLS settings.

Partial Segment Duration: 0.5 seconds
Segment Duration: 4 to 6 seconds
Segment Count: 10
Part Hold Back: 1.5 seconds

This configuration provides a low latency of 2 to 3 seconds while enabling stable low-latency streaming. From a user experience perspective, if a service can provide streaming in less than 3 seconds, it can be perceived as having sufficiently low latency and can enable interactivity in streaming.

Conclusion

Today, we conducted various tests using Low-Latency HLS with OvenMediaEngine, and as a result, we successfully achieved low latency easily, streaming stably at under 3 seconds (or approximately 3 seconds).

Low-Latency HLS is an extension of HLS designed to address inherent latency challenges while preserving its core strengths of scalability, universality, and compatibility by utilizing features such as Partial Segments, Blocking Playlist Reloads, Preload Hints, Rendition Reports, and more. Notably, Low-Latency HLS does not require replacing existing infrastructure or deploying entirely new servers, as it can utilize the existing infrastructure and CDNs already used with HLS, making it a practical and cost-effective protocol.

OvenMediaEngine leverages Low-Latency HLS to deliver large-scale, high-quality, low-latency streaming suitable for various use cases. As a streaming server, it provides an effective low-latency streaming solution tailored to the needs of modern streaming services. The OvenMediaEngine team is committed to advancing low-latency streaming technology and continually enhancing the streaming experience.

Thank you!

For more information

Rethinking HLS: Is it Possible to Achieve Low-Latency Streaming with HLS?

OvenMediaEngine — Mon, 13 Jan 2025 12:10:34 GMT

While new technologies continue to emerge, HTTP Live Streaming (HLS) remains a stable, universal, and widely supported streaming protocol across the digital ecosystem because HLS was designed with a focus on stability to deliver media on a global scale. This required some level of buffering and latency to ensure a seamless viewing experience. However, with the increasing demand for two-way media services, the need for low-latency streaming has grown significantly.

So then, can low latency be achieved using HLS? Through our tests, we discovered that the minimum achievable latency with HLS, while maintaining quality and stability, is approximately 6 seconds. In this post, media technology experts at OvenMediaEngine explain the experimental process that led us to this conclusion. In Part 3, we will describe how Low-Latnecy HLS reduces latency. Please check out the series below.

Why Does HLS Remain Widely Used in Modern Streaming?

HLS is one of the most widely used streaming protocols in the modern digital ecosystem. HLS delivers audio and video over HTTP, it enables playback on a wide range of devices and platforms. This universality supports stable playback across desktops, mobile devices, smart TVs, and even IoT devices. Also, HLS uses the same protocol that powers the web, allowing content to be distributed through web servers and Content Delivery Networks (CDN). These qualities make it a reliable and widely adopted choice for streaming providers worldwide.

Reducing Latency in HLS: Understanding and Adjusting Segment Duration

Apple recommends a segment duration of 6 seconds for HLS streaming, as outlined in their documentation. This recommendation highlights HLS’s primary focus on stability streaming and playback —

HTTP Live Streaming (HLS) authoring specification for Apple devices | Apple Developer Documentation

According to RFC8216bis-16 (HLS2) 4.4.3.8. EXT-X-SERVER-CONTROL, the HOLD-BACK value must be at least three times the Target Duration (referred to as Segment Duration). As a result, with the Apple-recommended Target Duration of 6 seconds, the minimum delay inherently starts at 18 seconds —

HTTP Live Streaming 2nd Edition

Before conducting our tests, we referred to these references to better understand the causes of HLS’s long latency and discovered that following the recommended guidelines results in a minimum delay of 18 seconds. With this understanding, we hypothesized that reducing the segment duration would naturally decrease latency. Based on this assumption, we decided to adjust the relevant parameters to test its impact on real-time streaming performance.

HLS Tags Used in This Test

#EXT-X-TARGETDURATION: The EXT-X-TARGETDURATION tag specifies the maximum Media Segment duration. It applies to the entire Playlist file.
#EXT-X-SERVER-CONTROL: The EXT-X-SERVER-CONTROL tag allows the Server to indicate support for Delivery Directives. Delivery Directives are transmitted by the Client to the Server as Query Parameters in the Playlist request URIs.
HOLD-BACK: HOLD-BACK is an optional attribute of EXT-X-SERVER-CONTROL. This indicates the server-recommended minimum distance from the end of the Playlist at which clients should begin to play or to which they should seek, unless PART-HOLD-BACK applies. Its value must be at least three times the Target Duration. It may appear in any Media Playlist.
#EXT-X-START: The EXT-X-START tag indicates a preferred point at which to start playing a Playlist. By default, clients should start playback at this point when beginning a playback session.
TIME-OFFSET: TIME-OFFSET is a required attribute of EXT-X-START. In TIME-OFFSET, a positive number indicates a time offset from the beginning of the Playlist. A negative number indicates a negative time offset from the end of the last Media Segment in the Playlist. The absolute value of TIME-OFFSET should not be larger than the Playlist duration.

Explaining the Test Options: Live Encoder and Streaming Server Settings

In this test, below is a breakdown of specific configurations for the live encoder (OBS) and streaming server (OvenMediaEngine) and their roles:

In Live Encoder (OBS) Settings,

Rate Control (CBR): CBR can send a consistent bitrate throughout the stream, which is suitable for live streaming.
Bitrate (2500 Kbps): This specifies the data rate at which the video is streamed.
FPS (30): 30 frames per second provides smooth motion for most streaming while keeping processing and bandwidth requirements manageable.
Keyframe Interval (1 or 2): Keyframe intervals dictate how often a full video frame (I-frame) is encoded.
CPU Usage Preset (ultrafast): The ‘ultrafast’ preset minimizes CPU usage by prioritizing encoding speed over compression efficiency.
Profile (Main): The ‘Main’ profile balances compatibility and quality, making it suitable for most streaming.
Tune (zerolatency): This tuning option optimizes the encoder for low-latency streaming, reducing buffering and improving performance by prioritizing speed over compression.
x264 Options (scenecut=0, bframes=(0, 1, or 2)): Disables scene-cut detection (scenecut=0), enabling more predictable keyframe placement. And controls the number of B-frames (bframes=0, 1, or2) used in the compression for encoding.

In Streaming Server (OvenMediaEngine) Settings,

Video (Pass-through; H264): The server directly forwards the H264-encoded video stream from the encoder without transcoding.
Audio (Pass-through; AAC): Similar to video, the AAC-encoded audio is forwarded without transcoding.

#01. When Setting the Segment Duration to 1 Second to Reduce Latency

Configuration:

Segment Duration (#EXT-X-TARGETDURATION): 1 second
Hold Back (#EXT-X-SERVER-CONTROL:HOLD-BACK): 3 seconds
Keyframe Interval: 1 second
x264 Options: scenecut=0, bframes=0

We conducted tests based on the hypothesis that a shorter Segment Duration would naturally reduce streaming latency. Applying the rule that the Hold Back must be at least three times the Segment Duration, we achieved a result of approximately 3.667 seconds. Since the latency of 3 to 5 seconds is commonly referred to as ‘low latency,’ we confirmed that numerical low latency is achievable by adjusting HLS tags.

Result: 110 frames (3.667 seconds) latency
Server Buffer: 0.1 to 0.9 seconds (time required to create a new segment)
Player Hold-Back: 3 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

#02. When Setting a Negative Time Offset to Further Reduce Latency

Configuration:

Segment Duration (#EXT-X-TARGETDURATION): 1 seconds
Hold Back (#EXT-X-SERVER-CONTROL:HOLD-BACK): 3 seconds
Time Offset (#EXT-X-START:TIME-OFFSET): -1 seconds
Keyframe Interval: 1 seconds
x264 Options: scenecut=0, bframes=0

We previously achieved an impressive result of 3.667 seconds in the test as #01, using HLS with TARGETDURATION:1. Building on that result, we adjusted the START:TIME-OFFSET to a negative value, equal to the Segment Duration, to further reduce latency. This adjustment created a negative offset from the end of the last Media Segment in the Playlist, allowing us to achieve an even more remarkable result of 1.7 seconds. However, this approach violates the HOLD-BACK rule, rendering it incompatible with iOS and Safari.

Result: 51 frames (1.7 seconds) latency
Server Buffer: 0.1 to 0.9 seconds (time required to create a new segment)
Player Hold-Back: 3 seconds
START:TIME-OFFSET: -1 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

Reducing Latency in HLS: Achieving Low Latency in HLS Without Compromising Stability and Quality

In the previous test, we achieved numerically low-latency streaming using HLS but found significant room for improvement in terms of quality. For example, test #01, which used a 1-second Keyframe Interval, resulted in degraded video quality, making it unsuitable for real-world use. Similarly, test #02, where the Time Offset was set to the negative value of the Segment Duration, violated guidelines, rendering it incompatible with iOS and Safari. Even with latency under 2 seconds, a streaming service cannot compromise on critical aspects like video quality and playback stability.

This led us to focus on how the Keyframe Interval, given that HLS segments always start with a keyframe, impacts video quality. While longer Keyframe Intervals generally improve video quality, we could not set this value to something extreme like 10 seconds since our primary goal was to test latency reduction using HLS. To address this, we referred to Video Multimethod Assessment Fusion (VMAF), a video quality evaluation method used by Netflix. According to VMAF, a difference of about 3 or more points is considered a valid threshold for humans to distinguish streaming quality.

References:

THEO Blog Post — How to Optimize LL-HLS for Low Latency Streaming

How to Optimize LL-HLS for Low Latency Streaming

Apple Documentation — HTTP Live Streaming (HLS) Authoring Specification for Apple Devices (Section 1.13)

HTTP Live Streaming (HLS) authoring specification for Apple devices | Apple Developer Documentation

After reviewing various research findings, we discovered that a Keyframe Interval of 2 seconds strikes the best balance between quality and stability. Below are the results of our tests using this configuration.

#03. When Setting the Keyframe Interval to 2 Seconds for Quality

Configuration:

Segment Duration (#EXT-X-TARGETDURATION): 2 seconds
Hold Back (#EXT-X-SERVER-CONTROL:HOLD-BACK): 6 seconds
Time Offset (#EXT-X-START:TIME-OFFSET): -2 seconds
Keyframe Interval: 2 seconds
x264 Options: scenecut=0, bframes=0

Informed by reference materials and recommendations, we learned that a keyframe interval of 2 seconds maintains a reasonable level of quality. The previous tests (#01 and #02), which focused solely on reducing streaming latency, resulted in degraded quality, making them unusable for real-world applications. To address this, we conducted a new test by setting the Keyframe Interval to 2 seconds, which naturally aligned the Segment Duration to 2 seconds. This is because the Segment Duration cannot be smaller than the Keyframe Interval since each segment requires at least one complete Keyframe. We also adjusted the Time Offset to -2 for consistent configuration. This setup achieved an excellent result of 3.067 seconds.

Result: 92 frames (3.067 seconds) latency
Server Buffer: 0.1 to 1.9 seconds (time required to create a new segment)
Player Hold-Back: 6 seconds
START:TIME-OFFSET: -2 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

How much do B-Frames affect streaming quality?

On the left: $ ffmpeg-iinput.mp4-b:v2M-bf1-x264optskeyint=60:min-keyint=60:scenecut=-1-profile:vhigh-g60-r30output.mp4
On the right: $ ffmpeg-iinput.mp4-b:v2M-bf1-codech264_nvenc-profile:vhigh-g60-r30output.mp4

Another factor often mentioned to affect quality is the B-Frame setting, so we conducted a test to verify this. We prepared the same video at bitrates of 2Mbps, 3Mbps, and 5Mbps and inserted B-Frames set to 0, 1, and 2 for each bitrate. The results showed that the highest VMAF score was achieved at 2Mbps with a B-Frame setting of 1, while at 5Mbps, the highest VMAF score was obtained with a B-Frame setting of 0. These results differ from the commonly accepted understanding, indicating that B-Frames do not necessarily guarantee a quality improvement.

#04. When Setting the B-Frame Value to 2 for Quality

Configuration:

Segment Duration (#EXT-X-TARGETDURATION): 2 seconds
Hold Back (#EXT-X-SERVER-CONTROL:HOLD-BACK): 6 seconds
Time Offset (#EXT-X-START:TIME-OFFSET): -2 seconds
Keyframe Interval: 2 seconds
x264 Options: scenecut=0, bframes=2

However, we didn’t stop testing and wanted to gather more conclusive data by comparing it with test #03 (which achieved a latency of 3.067 seconds). Using the same configuration as test #03, we only added the B-Frame setting to 2. As a result, the encoding and decoding of B-Frames introduced additional latency, resulting in a measured latency of 3.534 seconds, checking that B-Frames do impact latency.

From this, we confirmed again that B-Frames do not guarantee quality improvement. Moreover, since B-Frames increased latency, we concluded that there is no reason to use the B-Frame option when the goal is to minimize latency while maintaining a reasonable level of quality. Of course, if the quality had been noticeably better despite the slight increase in latency, we might have considered using the B-Frame option in real-world scenarios. However, that was not the case in our tests.

Result: 106 frames (3.534 seconds) latency
Server Buffer: 0.1 to 1.9 seconds (time required to create a new segment)
Player Hold-Back: 6 seconds
START:TIME-OFFSET: -2 seconds
B-frame Encoding/Decoding: 0.2 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

Stability Issues Discovered with Negative Time Offset

Additionally, in all tests except for test #01, we aimed to reduce latency as much as possible by setting the negative absolute value of the Segment Duration as the Time Offset. However, this approach revealed the following stability issues during testing.

Player Instability

The player reloads the Playlist immediately after the playback of the last Segment ends, downloads the new Segment, and then plays the next Segment. During this process, if the timing of the Playlist Reload and Segment Download is not synchronized, a Jitter may occur.

Playlist Reload? Playlist Reload is the process in HLS (HTTP Live Streaming) where the player periodically re-requests the Playlist file to fetch new segments for playback. The player can fetch the most recent segments in a live stream to keep playback continuous. Without reloading the Playlist, the player would not be aware of new segments, causing playback to stall or freeze during live streaming — https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-6.3.4.

Server Instability

The server’s allowable Jitter range varies depending on the player’s connection timing. For players that request the server 1 second after a new Segment is created, up to 1 second of Jitter is allowed. However, for players that request immediately after the new Segment is created, no Jitter is allowed, and the Playlist must be updated within 2 seconds. If this synchronization process is not properly managed, the streaming experience may degrade.

Factors That Can Cause Jitter

There are many factors that can cause jitter, as shown below:

Variations in Keyframe Interval: Changes in Keyframe Interval due to factors such as Scenecut options or encoder performance.
Frame Drops Issues: Jitter may occur in any situation where frames are dropped.
Issues with Video Sources (Encoder): Problems with video sources, such as encoder performance or configuration issues, can lead to jitter.
Server Transcoding Performance Issues: Insufficient server performance for processing video data may cause jitter.
Network Jitter Between Video Sources and Servers: Instability in the network connection between video sources and servers can significantly contribute to jitter.
Server Performance While Handling Multiple Player Requests: All players must complete Playlist Reload and Segment Download within the Jitter Buffer time, as players receiving data at the end are more likely to experience buffering, which significantly impacts the number of concurrent players the server can handle efficiently.

Of course, setting the Time Offset to a negative value violates the guidelines for iOS and Safari, meaning it would not function properly. Moreover, it poses a broader threat to the stability of HLS in global-scale streaming, making it unsuitable for real-world applications.

Reducing Latency in HLS: Finding Optimal Configuration

#05. When Configured for Quality and Stability

Configuration:

Segment Duration (#EXT-X-TARGETDURATION): 2 seconds
Hold Back (#EXT-X-SERVER-CONTROL:HOLD-BACK): 6 seconds
Keyframe Interval: 2 seconds
x264 Options: scenecut=0, bframes=0

Through various tests, we gained an understanding that the rules defined in HLS, such as the Hold Back being three times the Segment Duration, the absolute value of the Time Offset not exceeding the Playlist Duration, and more, are grounded in ensuring quality and stability. Additionally, we aimed to test based on these rules to achieve optimal results. As a result, we achieved a latency of approximately 6.834 seconds, striking a balance that delivers both quality and stability for a reliable streaming experience.

Result: 205 frames (6.834 seconds) latency
Server Buffer: 0.1 to 1.9 seconds (time required to create a new segment)
Player Hold-Back: 6 seconds
Other factors (Encoder, Ingest, Package, A/V gap, etc.): 0.2 seconds

Conclusion

Through this test, we explored various factors to achieve low-latency streaming using HLS. While we observed measurable successes, we found that significantly reducing latency while maintaining HLS’s core strengths of stability, universality, and scalability was not achievable.

To address these limitations, HLS has extended into Low-Latency HLS. Low-Latency HLS offers a new possibility by fulfilling the demands for low-latency streaming while preserving the strengths of HLS. In the upcoming article, we will dive deeper into Low-Latency HLS and explore its key innovations, such as Partial Segments, Blocking Playlist Reloads, Preload Hints, Blocking of Media Downloads, and Rendition Reports. These mechanisms not only achieve low latency but also enhance the overall streaming experience. Through this, we will gain a deeper understanding of how Low-Latency HLS overcomes the limitations of HLS while preserving its strengths.

Thank you!

For more information

WebRTC: A New Paradigm for Real-Time Web Communication

OvenMediaEngine — Fri, 15 Nov 2024 08:41:00 GMT

In this blog series, we’ll explore how OvenMediaEngine enables faster, more stable streaming experiences. Many of you have asked about the core egress protocols that make this possible, so we’ll be diving into WebRTC, Low Latency HLS (LL-HLS), and Legacy HLS. Whether you’re curious about sub-second latency or optimizing streaming for large audiences, this series will provide the insights you’re looking for.

Join us as we break down the essentials of modern streaming technology!

What is WebRTC?

As web technologies continue to evolve, our online experiences are constantly being redefined. One such groundbreaking technology is WebRTC (Web Real-Time Communication), which allows web browsers to communicate directly in real-time, without needing plugins.

Launched as an open-source project by Google in 2011, this technology enables direct Peer-to-Peer (P2P) communication for video, audio, and data transfer, reshaping online experiences by supporting video conferencing, live chatting, and remote collaboration with ease. With its seamless real-time transmission capabilities, WebRTC has redefined real-time web communication, making immediate and immersive interactions more accessible.

Components of WebRTC

While WebRTC is a powerful and versatile technology, its complexity is carefully structured into key components. Understanding these will allow you to grasp the true capabilities of WebRTC.

WebRTC API: The primary tool for developers, featuring APIs like getUserMedia, RTCPeerConnection, and RTCDataChannel, which facilitate camera and microphone access, establish connections and enable data transfer.
SDP (Session Description Protocol): The ‘Blueprint’ for WebRTC connections, SDP negotiates and decides on formats, codecs, and encryption methods for communication, ensuring compatibility across different systems.
Audio Engine: Centered on the Opus codec, WebRTC’s audio engine delivers high-quality sound with low latency, efficiently adapting to various bitrates.
Video Engine: Supporting diverse codecs such as H.264, VP8, VP9, and AV1, the video engine reduces CPU usage and conserves battery by using hardware acceleration for video processing.
Transport Layer: Combining SRTP, DTLS, ICE, STUN, TURN, and FEC protocols, this layer ensures secure and fast data transmission even in challenging network conditions.

Pros and Cons of WebRTC

WebRTC is a revolutionary web communication technology that aims to deliver data for sub-second latency. Here’s a closer look at WebRTC’s strengths and limitations:

Pros:

Real-Time Communication: WebRTC inherently supports bidirectional communication, making it a significant advantage for real-time interaction applications.
Broad Browser Support: Most major browsers, including Chrome and Firefox, support WebRTC natively, eliminating the need for plugins.

Cons:

Scalability: Since WebRTC is P2P-based, additional architecture design may be required for sending a large stream to a large audience, such as in live streaming.
Firewall/NAT Issues: Establishing connections in some network environments can be challenging due to the need for complex mechanisms like ICE, STUN, and TURN.

While WebRTC’s strengths make it excellent for small-scale real-time communication, its limitations are apparent when applied to large-scale streaming scenarios.

WebRTC Implementation in OvenMediaEngine

OvenMediaEngine takes WebRTC’s limitations in stride, applying a range of technical innovations to overcome them and deliver stable, sub-second latency streaming for large audiences. OvenMediaEngine effectively preserves WebRTC’s real-time capabilities while enabling it to scale.

And, to achieve scalable WebRTC-based streaming, OvenMediaEngine offers a suite of sophisticated features designed to support stability, scalability, and seamless user experience in large-scale environments.

Sub-Second Latency Streaming

By leveraging WebRTC’s real-time capabilities, OvenMediaEngine enables sub-second latency streaming suitable for live commerce, sports broadcasts, gambling, and other applications where immediate interaction is essential.

Various Protocol Input Support

In addition to WebRTC, OvenMediaEngine supports input protocols such as WebRTC, WebRTC/TCP, WHIP, SRT, RTMP, MPEG-2 TS, and RTSP-Push. This makes it simple to integrate with existing streaming infrastructures, allowing different content sources to be repackaged into WebRTC and streamed in real-time to large audiences.

Embedded Live Transcoder

OvenMediaEngine seamlessly ingests various input protocols and converts them to WebRTC, enabling sub-second latency streaming with ease. While WebRTC does not support AAC codec, OvenMediaEngine’s live transcoder automatically encodes audio to Opus for full WebRTC compatibility.
Simulcast is a technology where the source (e.g., video encoder, device) sends multiple streams of different quality to the server. The server then chooses and forwards a stream to viewers based on their network conditions. While this approach can reduce server resource usage, it heavily relies on the source device’s resources and bandwidth, making it unsuitable or unstable in some cases. To address this, OvenMediaEngine’s live transcoder generates multiple quality streams directly on the server. This allows viewers to receive optimized streams based on their network conditions, even if the source device or encoder sends only a single video stream. This results in a more efficient and stable server-side ABR experience.

Adaptive Bitrate Streaming (ABR)

ABR dynamically adjusts stream quality according to network conditions, enabling smooth streaming across a wide range of devices and networks. This is especially beneficial for mobile viewers or those with unstable internet connections.

TCP and UDP Transmission

While WebRTC typically uses UDP for low latency, OvenMediaEngine also supports TCP transport for scenarios where UDP is restricted, maintaining stable connectivity in challenging network environments.

Scalability

For large-scale viewership, OvenMediaEngine distributes traffic across multiple servers using load balancing, reducing individual server load and enhancing stability. This allows OvenMediaEngine to scale horizontally, serving high viewer numbers without compromising on quality or latency.

OvenMediaEngine brings out the best in WebRTC by addressing its core limitations and transforming it into a powerful tool for large-scale, high-definition, and sub-second latency streaming. OvenMediaEngine has turned WebRTC from a peer-to-peer technology into a scalable streaming solution capable of serving massive audiences with real-time precision.

Optimized WebRTC Testing on OvenMediaEngine

We conducted tests in two scenarios to evaluate the WebRTC performance of OvenMediaEngine. The test results clearly demonstrate the real-world performance and efficiency of OvenMediaEngine.

For the test, we used OBS Studio (Open Broadcaster Software), the most widely used open-source live encoder. In both the RTMP and WHIP transmitting scenarios, we applied the same Output Streaming Settings across each setup.

Audio Encoder: FFmpeg AAC
Video Encoder: x264
Rate Control: CBR
Bitrate: 2500 Kbps
FPS: 30
Keyframe Interval: 2s
CPU Usage Preset: ultrafast
Profile: Baseline
Tune: zerolatency
x264 Options: scenecut=0, bframes=0

#01. RTMP to WebRTC using OBS and OvenMediaEngine

The first test scenario involved streaming RTMP input to WebRTC output.

RTMP Ingress URL: rtmp://[:RTMP Listen Port]//
Configure OvenMediaEngine: Encode media sources ingested into OvenMediaEngine to Opus via the embedded live transcoder.

Result: 7 frames (0.234 seconds) latency

The notable result of this test is the very low latency of 0.234 seconds, equivalent to 7 frames of 30fps video. This is highly suitable for real-time communication. Achieving sub-second latency with RTMP input demonstrates OvenMediaEngine’s efficient transcoding and WebRTC implementation.

#02. WHIP to WebRTC using OBS and OvenMediaEngine

The second test involved streaming WHIP (WebRTC-HTTP Ingestion Protocol) input to a WebRTC output. To transmit media sources via WHIP in OBS, you need to change the ‘Service’ option in Stream Settings to WHIP.

WHIP Ingress URL: http[s://[:WebRTC Listen Port]//?direction=whip
Configure OvenMediaEngine: When you select WHIP in OBS, the media source is sent to Opus, so there is no need to set it up separately in OvenMediaEngine.

Result: 5 frames (0.167 seconds) latency

This test showed even more impressive results, with a latency of 0.167 seconds, which is lower than the first test. At 5 frames of 30fps video, it is close to real-time latency. Using WHIP allows WebRTC to be used right at the input stage, reducing overall latency.

These tests demonstrate OvenMediaEngine’s ability to deliver sub-second latency streaming, regardless of the input protocol.

Conclusion

WebRTC delivers outstanding sub-second latency, making it one of the best protocols for real-time streaming. However, when it comes to large-scale and high-definition streaming, WebRTC’s peer-to-peer nature presents inherent scalability challenges that make it difficult to support a vast audience. This is where OvenMediaEngine truly excels, offering a scalable solution that provides stable, sub-second latency even in large-scale and high-definition streaming environments.

However, WebRTC doesn’t integrate seamlessly with existing infrastructure, particularly Content Delivery Networks (CDNs), which are often optimized for HTTP-based protocols like HLS (HTTP Live Streaming). For this reason, most CDNs have not yet adopted WebRTC as part of their streaming infrastructure, as it lacks compatibility with current caching and distribution strategies. Consequently, alternative approaches, like Low Latency HLS (LL-HLS), are often recommended for scalable, low-latency streaming.

To understand LL-HLS, we’ll first need to look at how HLS works and the reasons it has become the standard for content distribution. In our next article, we’ll explore the structure and benefits of traditional HLS and reveal how much delay — typically around 10 to 15 seconds — can be reduced through optimization to support low-latency needs.

Stay tuned for a closer look at HLS, LL-HLS, and the steps to optimize for a latency-optimized streaming experience!

For more information

OvenMediaEngine — Getting Started with OME Docker Launcher

OvenMediaEngine — Mon, 27 May 2024 07:02:20 GMT

OvenMediaEngine — Getting Started with OME Docker Launcher

OvenMediaEngine is an open-source and sub-second latency streaming server capable of handling large-scale and high-definition streams. It can be installed and used in various environments, such as servers, CDNs, and Clouds. Today, we will show you how to easily use OvenMediaEngine by installing Docker on an AWS EC2 instance.

To make this process even smoother, you can minimize the hassle by using our OME Docker Launcher.

The OME Docker Launcher is a tool that simplifies the process of deploying and managing the OvenMediaEngine application using Docker containers. This tool is designed for developers and system administrators who want to quickly deploy and test the OME application in a Docker environment.

Let’s start the OvenMediaEngine quick start guide now!

https://medium.com/media/9b8d066c9b23677ca33927a3a19ea64f/href

Below are the commands and examples used in the video guide.

AWS EC2 Instance Setup

For quick guidance, we opened all TCP ports 0–65535 when creating the EC2 Instance, but the default ports used by OvenMediaEngine are as follows. For more information, please refer to Ports used by default in the Getting Started sub-item of the OvenMediaEngine User Guide.

Ports used by default

API (Manager) is configured to use 8081 (Port)
API (Manager) is configured to use 8082 (TLSPort)
RTMP Provider is configured to use 1935 (Port)
SRT Provider is configured to use 9999 (Port)
WebRTC Provider is configured to use 3333 (Port)
WebRTC Provider is configured to use 3334 (TLSPort)
WebRTC Provider is configured to use 10000–10004/UDP (IceCandidate)
WebRTC Provider is configured to use 3478 (TcpRelay)
OVT Publisher is configured to use 9000 (Port)
LLHLS Publisher is configured to use 3333 (Port)
LLHLS Publisher is configured to use 3334 (TLSPort)
WebRTC Publisher is configured to use 3333 (Port)
WebRTC Publisher is configured to use 3334 (TLSPort)
WebRTC Publisher is configured to use 10000–10004/UDP (IceCandidate)
WebRTC Publisher is configured to use 3478 (TcpRelay)

Installing Docker in EC2

The commands used to install Docker on an EC2 instance in the video guide are as follows:

# Install Dqocker
$sudo yum install docker -y

# Run Docker
$ sudo service docker start

Installing OvenMediaEngine on Docker in EC2

For detailed steps, refer to the Getting Started with OME Docker Launcher guide, accessible under the Getting Started menu in the OME User Guide.

The commands used to install and run OvenMediaEngine in the video guide are as follows:

# Run OME Docker Launcher
$ curl -OL 'https://raw.githubusercontent.com/AirenSoft/OvenMediaEngine/master/misc/ome_docker_launcher.sh' && chmod +x ome_docker_launcher.sh

# Show OME Docker Launcher help message
$ sudo ./ome_docker_launcher.sh -h

# Download the latest Docker image and setup
$ sudo ./ome_docker_launcher.sh setup

# Start a docker container
$ sudo OME_HOST_IP= ./ome_docker_launcher.sh start

Broadcasting with OBS to OvenMediaEngine

If you would like to know how to set up and use protocols that OvenMediaEngine can ingest, please refer to the Live Source subsection in the OvenMediaEngine User Guide.

The RTMP URL pattern used in this video guide is as follows:

rtmp://:1935/app/

And to transmit the media source, I used X264 as an encoder and made detailed settings as follows:

Bitrate: 2500kbps
Keyframe Interval: 1s
CPU Usage Preset: ultrafast
Profile: main
Tune: zerolatency
x264 Options: bframes=0 threads=8

Streaming Playback

When streaming through OvenMediaEngine, you may or may not have a certificate. Please refer to the information below. For more information, refer to the Streaming section in the OvenMediaEngine User Guide.

Without TLS

OvenPlayer Demo: http://demo.ovenplayer.com
WebRTC: ws://:3333/app/
LLHLS: http://:3333/app//llhls.m3u8

With TLS

OvenPlayer Demo: https://demo.ovenplayer.com
WebRTC: wss://:3334/app/
LLHLS: https://:3334/app//llhls.m3u8

Configuring OvenMediaEngine Options

OvenMediaEngine operates according to Server.xml. Therefore, you need to know how to modify Server.xml to use the various functions provided by OvenMediaEngine. For guides for each function, please refer to the OvenMediaEngine User Guide.

# Go to the folder where Server.xml is located
$cd /usr/share/ovenmediaengine/conf/

# Edit Server.xml
$ sudo vi Server.xml

Also, if you modify Server.xml, you always need to turn OvenMediEngine on and off to apply it.

# Stop OvenMediaEngine
$ sudo ./ome_docker_launcher.sh stop

# Start OvenMediaEngine
$ sudo OME_HOST_IP= ./ome_docker_launcher.sh start

TLS Encryption (Certification)

To apply TLS to your OvenMediaEngine you have a domain. If you get a domain, you can easily use a certificate at no cost using Let’s Encrypt. For more information, see TLS Encryption, a subtopic of Configuration in the OvenMediaEngine User Guide.

# Install Certbot
$ sudo yum -y install certbot

# Certificate issuance
$ sudo certbot certonly --standalone -d  -m  --agree-tos  -n

# Check whether the certificate was issued correctly
$ sudo ls -al /etc/letsencrypt/live/

If your TLS certificate was issued properly, you will need to copy the certificate into the OvenMediaEngine directory to match the entry within Server.xml.


  ./cert.crt
  ./cert.key
  ./cert.ca-bundle

Here’s how to copy these:

# Copy and rename cert.pem to cert.crt 
$ sudo cp /etc/letsencrypt/live//cert.pem /usr/share/ovenmediaengine/conf/cert.crt

# Copy and rename privkey.pem to cert.key
$ sudo cp /etc/letsencrypt/live//privkey.pem /usr/share/ovenmediaengine/conf/cert.key

# Copy and rename fullchain.pem to cert.ca-bundle
$ sudo cp /etc/letsencrypt/live//fullchain.pem /usr/share/ovenmediaengine/conf/cert.ca-bundle

Next, check whether the certificate has been properly copied to the OvenMediaEngine directory. If confirmed, restart OvenMediaEngine to apply it.

# Check the certificate has been copied properly
$ sudo ls -al /usr/share/ovenmediaengine/conf

# Stop OvenMediaEngine
$ sudo ./ome_docker_launcher.sh stop

# Start OvenMediaEngine
$ sudo OME_HOST_IP= ./ome_docker_launcher.sh start

To verify that your certificate is working properly, stream using TLS.

OvenPlayer Demo: https://demo.ovenplayer.com
WebRTC: wss://:3334/app/
LLHLS: https://:3334/app//llhls.m3u8

Adaptive Bitrate Streaming (ABR)

The example used in the video guide is below: Please refer to Adaptive Bitrate Streaming (ABR) in the OvenMediaEngine User Guide for detailed information on the function.


 bypass_stream
 ${OriginStreamName}
  
 
  For ABR
  abr
   
   
   true 
  
  
   Bypass
   bypass_video
   bypass_audio
  
  
   FHD
   video_1920
   bypass_audio
  
  
   HD
   video_720
   bypass_audio
  
  
   SD
   video_480
   bypass_audio
  
  
   FHD_Opus
   video_1920
   opus_audio
  
  
   HD_Opus
   video_720
   opus_audio
  
  
   SD_Opus
   video_480
   opus_audio
  
 
  
 
  Change Default
  llhls
  
   HD
   video_720
   bypass_audio
  
  
 
  
   bypass_audio
   true
  
  
   bypass_video
   true
  
  
   opus_audio
   opus
   128000
   48000
   2
  
  
   video_1920
   h264
   1024000
   30
   1920
   1080
   faster
  
  
   video_720
   h264
   724000
   30
   1280
   720
   faster
  
  
   video_480
   h264
   224000
   30
   720
   480
   faster

Now that Server.xml has been modified you must restart OvenMediaEngine.

# Stop OvenMediaEngine
$ sudo ./ome_docker_launcher.sh stop

# Start OvenMediaEngine
$ sudo OME_HOST_IP= ./ome_docker_launcher.sh start

Create a streaming URL pattern as shown below according to the title specified in in and then proceed with the ABR test.

Without TLS

OvenPlayer Demo: http://demo.ovenplayer.com
WebRTC: ws://:3333/app//
LLHLS: http://:3333/app//.m3u8

With TLS

OvenPlayer Demo: https://demo.ovenplayer.com
WebRTC: wss://:3334/app//
LLHLS: https://:3334/app//.m3u8

If the stream plays successfully, hover your mouse over OvenPlayer and click the gear icon at the bottom left of the displayed controller to see if the list you specified in is displayed.

When writing to use ABR, an important point to keep in mind is that if the protocol and codec do not match as listed below, it may not be played due to browser policy:

WebRTC: VP8, H.264, Opus
LLHLS: H.264, AAC

REST API

Please refer to REST API in the OvenMediaEngine User Guide. This guide explains Server.xml items in detail and includes examples.

In this video guide, we uncommented in Server.xml and added 8082/TLS.

 
  
   
    ${env:OME_APIT_PORT:8081}
    ${env:OME_APIT_PORT:8082}
    1
   
  
  ...

And according to the OvenMediaEngine User Guide, I inserted the example under . Afterward, I matched the file name in , entered the ID and password to be used in , and modified to allow all. If you want to use , you have to follow the format ID:Password.

 
  
   
    *
   
   
    ./cert.crt
    ./cert.key
    ./cert.ca-bundle
   
  
  
   ID:Password
   
    *

When you are finished editing Server.xml, restart OvenMediaEngine again so that OvenMediaEngine can read the modified Server.xml.

# Stop OvenMediaEngine
$ sudo ./ome_docker_launcher.sh stop

# Start OvenMediaEngine
$ sudo OME_HOST_IP= ./ome_docker_launcher.sh start

Restart OvenMediaEngine, and in the displayed dashboard, check that the API-related ports are recognized properly.

API (Manager) is configured to use 8081 (Port)
API (Manager) is configured to use 8082 (TLSPort)

Then, let’s call the API according to the API request pattern.

Without TLS

http://:8081/v1/

With TLS

https://:8082/v1/

Please refer to the REST API (v1) section in the OvenMediaEngine User Guide. It is written in detail about API resources, action names, reactions, etc.

Conclusion

With just a few commands, you can build your own fully-featured sub-second latency streaming server. Experience low latency streaming right now. While OvenMediaEngine has an array of features that we couldn’t cover entirely in this video guide, we hope our guide has been helpful to you.

Thank you for watching and reading.

How to transmit Low-Latency Streaming to broader viewers and share securely?

OvenMediaEngine — Wed, 03 Jan 2024 10:05:16 GMT

Do you want to provide stable and low-latency streaming to hundreds of thousands of viewers? Or perhaps, do you wish to share your low-latency stream only with authorized viewers?

These concerns can be addressed by seamlessly integrating OvenStudio LLHLS with AWS CloudFront (CDN) and Signed URL. While traditionally, connecting a streaming server with a CDN requires complexity and specialized knowledge, using OvenStudio LLHLS automates the entire process.

In this blog post, we provide step-by-step instructions on how to effortlessly set up integration with AWS CloudFront in just a few clicks. We also guide you on utilizing features such as the Signed URL, allowing you to share or restrict access as needed. Explore how OvenStudio LLHLS simplifies the integration with AWS CloudFront, making it a breeze.

What is AWS CloudFront?

AWS CloudFront, part of Amazon Web Services (AWS), serves as a Content Delivery Network (CDN) designed to deliver web content rapidly and reliably worldwide. OvenStudio LLHLS currently leverages AWS services (with future support for platforms like Azure), providing an option for expanding your streaming service or distributing traffic efficiently through CDN.

What is CDN (Content Delivery Network)?

A Content Delivery Network (CDN) is a system that efficiently transmits content globally by utilizing servers distributed across different geographical locations. The purpose is to provide users with fast and reliable service by dispersing and distributing web content, be it static (scripts, images) or dynamic (streaming videos, audio).

Advantages of CDN:

Swift Transmission: Caching content at edge locations facilitates rapid content delivery.
Scalability: Easily scales servers to accommodate increased traffic, suitable for large-scale streaming services.
Security: Supports encryption via SSL/TLS, ensuring secure data transmission.
Cost-Efficiency: Efficiently utilizes bandwidth and resources, resulting in cost savings.

Why CDN in Streaming Servers?

CDNs play a crucial role in delivering a consistent, high-quality streaming experience globally. Leveraging CDN services, especially for dynamic content like streaming, ensures users receive a seamless experience regardless of their location. Additionally, content providers can easily respond to increasing traffic through CDN expansion, enabling stable service provision.

In our upcoming blog post, we provide a step-by-step guide on effortlessly integrating OvenStudio LLHLS with AWS CloudFront. Whether you’re looking to enhance your streaming delivery or explore advanced features, OvenStudio LLHLS makes the process user-friendly, saving you time and effort. Stay tuned for our comprehensive guide, and feel free to reach out with any further inquiries.

※ Note: This guide will be updated to accommodate integration with other CDNs besides AWS CloudFront in the future.

What is a Signed URL?

A Signed URL in OvenStudio LLHLS encrypts the URL used for media transmission between the streaming server and the viewer during streaming. This URL is valid for a specific period, and only authenticated users with the appropriate permissions can access the streaming via this URL.

OvenStudio LLHLS administrators can share encrypted URLs valid for a specified time, preventing unauthorized access to the streaming media source and safeguarding against leaks.

Additionally, Using the Signed URL in OvenStudio LLHLS:

Even with expert knowledge, integrating CDN services into a streaming service and managing the associated procedures can be cumbersome and complex. OvenStudio LLHLS simplifies these intricate processes with just a few clicks. You can seamlessly integrate AWS CloudFront (CDN) with OvenStudio LLHLS and leverage its features. Of course, if you wish to integrate other CDNs besides AWS CloudFront, OvenStudio LLHLS makes that possible too. Details will be provided in a future guide update.

How to Utilize the Signed URL Feature?

Closed Live Streaming Service: With the Signed URL, content providers can grant access to video streams exclusively to subscribers, allowing the implementation of a subscription model.
Copyright Protection: Signed URL prevents unauthorized copying and distribution of content, providing a safeguard for copyright protection.
Activities such as Online courses, Live forums, Webinars, Sports broadcasts, Online auctions, Internal previews, and more can benefit from these functionalities.

Setting Up Signed URL in OvenStudio LLHLS:

OvenStudio LLHLS makes it incredibly simple to configure and use the Signed URL feature with AWS CloudFront. Follow these steps:

Connect with AWS CloudFront (Signed URL):

Click the [Settings] icon in the top right corner of OvenStudio LLHLS and select [AWS CloudFront] from the left menu to navigate to the AWS Credentials setup page.

Enter the issued Access Key ID and Secret Access Key into [AWS Credentials] and click [Save Credentials] to apply. Learn how to obtain Access Key ID and Secret Access Key — AWS Identity and Access Management User Guide.

In the [Distribution Information] section on the same page, click the [Refresh] icon to verify and load your AWS CloudFront information. To apply this to the OvenStudio LLHLS system, click [Enable Distribution]. Upon successful connection, the status item will change to ‘Enabled’.

Finally, on the same page, activate the [Signed URL] toggle to transition streaming URLs deployed through OvenStudio LLHLS to Secure URLs.

Renewing Signed URL in Case of Leakage

Signed URLs are valid for a specific period (e.g., 1 hour). Once this period expires, the URL becomes invalid. However, if a URL is leaked while still valid, follow these steps to renew it:

On the main page of OvenStudio LLHLS, click on the streaming box to enter the streaming details view. Then, click on the [URLs] tab.

When comparing the URL before and after refreshing, you can observe a change in the Auth syntax of the Signed Edge URL.

[Refresh] your browser to update the Signed Edge URL.

※ Note: The default expiration time of the Signed URL may be subject to change based on user needs and behavior in the future.

Using the Signed URL via API

You can utilize an API to apply detailed options for individual streaming units with the Signed URL —For more information, please refer to the Access Token in the OvenStudio LLHLS’s User Guide. :

Issuing Access Tokens:

First, access OvenStudio LLHLS, enter the [Settings] screen, and select [REST API] from the left menu.

Under [REST API], in the [Tokens] section, click [Generate new token] to acquire an access token.

Parameter Descriptions:

The Signed URL API is straightforwardly configured — In the OvenStudio LLHLS’s User Guide, detailed content is covered in the section labeled Body Parameters of Signed URL.”

“stream_name” requires the name of the streaming box for which the Signed URL is generated.
“date_less_than” ensures the URL is valid until a specified date and time, and this parameter is mandatory.
“date_grater_than” makes the URL valid from a specified date and time.

Examples:

To create a Signed URL for the streaming named OvenStudio, valid until January 1, 2024, 00:00:00 (UTC).

{
 "stream": {
  "stream_name": "OvenStudio"
 },
 "policy": {
  "date_less_than": "2024-01-01T00:00:00Z"
 }
}

To create a Signed URL for the streaming named OvenStudio_Xmas, valid from December 24, 2023, 00:00:00 to December 26, 2023, 00:00:00 (UTC).

{
 "stream": {
  "stream_name": "OvenStudio_Xmas"
 },
 "policy": {
  "date_less_than": "2023-12-26T00:00:00Z",
  "date_greater_than": "2023-12-24T00:00:00Z"
 }
}

“date_greater_than” is a directive that defines the URL’s validity starting from the specified time. When used as in the example, the URL can be accessed from December 24, 2023, 00:00:00 UTC onwards.

You can find comprehensive details in the OvenStudio LLHLS’s User Guide under the Signed URL section.

Conclusion

OvenStudio LLHLS minimizes cumbersome processes to alleviate your concerns. If you need to distribute your streaming to a wider audience, simply integrate with AWS CloudFront with just a few clicks — OvenStudio LLHLS makes it possible.

Moreover, if you wish to share your streaming with specific individuals only, activate the toggle button to enable the Signed URL. It provides security and flexibility for streaming service providers, enhancing service efficiency by protecting content and allowing access only to valid users.

Always, OvenStudio LLHLS offers the easiest and most effective options to support seamless, secure, and low-latency streaming in your service — Elevate your service with the easiest and most effective options, enabling larger audiences to enjoy a seamless, secure, and low-latency streaming experience. Join us in the future of low-latency streaming with OvenStudio LLHLS.

For more information

How to use ABR Streaming in OvenStudio LLHLS?

OvenMediaEngine — Thu, 07 Dec 2023 11:10:29 GMT

Live streaming has grown rapidly to the point where it has become a part of many people’s daily lives. This growth is further accelerated due to the increasing demand for online media consumption by users.

Consequently, streaming service providers are striving to understand the diverse viewing environments of viewers worldwide in order to provide the best viewing experience while efficiently utilizing bandwidth to reduce server load through technological solutions.

ABR (Adaptive Bitrate) Streaming is one of the responses to these challenges, dynamically adjusting bitrate, resolution, and framerate considering network conditions and user device performance. This allows viewers to experience uninterrupted streaming in any environment while streaming service providers efficiently use bandwidth to cut costs.

Advantages of ABR

Improved User Experience: ABR provides stable streaming tailored to network changes and viewer device performance, offering users a high-quality experience.
Traffic Efficiency: ABR efficiently utilizes bandwidth, optimizing network traffic.
Reaching a Larger Audience: ABR enables streaming in diverse environments, allowing streamed content to reach a broader audience.

Where Can ABR Be Applied?

ABR becomes highly valuable when one or more streamers need to stream to an unspecified large audience within a single session. This is because the streaming environments of numerous viewers can vary significantly. Conditions and variables such as location, weather, network, devices, and browsers are more diverse than you might think.

How Does OvenStudio LLHLS Provide ABR?

Embedded Live Transcoder: OvenStudio LLHLS has embedded a live transcoder that allows encoding of the same media source into various bitrates, resolutions, and frame rates.
ABR Profiles: OvenStudio LLHLS users can choose from multiple encoding presets to enable ABR. These profiles offer presets ranging from low bitrates and resolutions to high bandwidth options, based on collecting various user data. You can easily adjust the viewer experience by selecting the desired presets with just a few clicks.
Dynamic Streaming: OvenStudio LLHLS real-time transforms the media source based on the configured profiles, sending the required LLHLS segments for streaming. If you use OvenPlayer, it continuously monitors viewer network conditions and device performance, requesting the appropriate profile from OvenStudio LLHLS.
Automatic Profile Switching: When changes are detected in network speed and stability, OvenPlayer automatically switches profiles to ensure uninterrupted streaming. Of course, viewers can also select resolutions directly in OvenPlayer.

In summary, OvenStudio LLHLS provides ABR functionality, dynamically adjusting bitrate and resolution based on network conditions and device performance to offer uninterrupted high-quality streaming. We recommend using OvenPlayer, optimized for OvenStudio LLHLS, to provide a smoother streaming experience.

Can’t use ABR with Low-Latency Streaming?

Not at all.

Some users have had concerns that using ABR to deliver multiple profiles could make streaming heavier and prevent low-latency streaming. While this might be the case for some lower-quality streaming servers, OvenStudio LLHLS smoothly delivers ABR with a latency of less than 3 seconds. OvenStudio LLHLS’ ABR feature encodes media sources into multiple bitrates and resolutions, dynamically providing the appropriate profile based on viewer network conditions and device performance. This enhances streaming stability and quality, especially in slow or unstable network environments.

OvenStudio LLHLS’ low-latency streaming minimizes the typical 6–10 seconds of delay found in most live streaming to less than 3 seconds. This allows viewers to enjoy high-quality media streaming while experiencing low-latency live streaming.

In other words, ABR optimizes quality by adjusting resolution, bitrate, frame rate, etc., based on network conditions, while low-latency streaming provides an interactive streaming experience. Therefore, using both technologies together allows you to deliver flexible media quickly. Let’s configure ABR in OvenStudio LLHLS now!

Configuring ABR in OvenStudio LLHLS

To provide ABR functionality, OvenStudio LLHLS has the embedded live transcoder, using video codecs such as VP8, H.264, Pass-through, and audio codecs like Opus, AAC, and Pass-through. Higher-spec instances may be required when using ABR. Here are the steps to configure ABR in OvenStudio LLHLS:

After logging in to OvenStudio LLHLS, click the [Settings] icon in the top right corner of the dashboard to go to the OvenStudio LLHLS settings page.

From there, select the [ABR] tab in the left menu to access the ABR settings page.

On the ABR settings page, choose the encoding presets you want to use from the [Profiles] section. You need to select at least two profiles to enable ABR functionality.
After selecting all the profiles you want to use, please press the [Apply] button to save the settings. Please note that the OvenMediaEngine (streaming engine) being used in OvenStudio LLHLS will restart, so don’t be alarmed if the streaming is momentarily interrupted.

Using ABR in OvenStudio LLHLS

After configuring ABR, use OvenLiveKit, OBS, or other tools to send your media source to OvenStudio LLHLS for streaming. If you’re not sure how to stream, you can refer to this previous post (Low-Latency Streaming to OvenStudio LLHLS using OBS Studio) for guidance.

If the streaming appears correctly in OvenStudio LLHLS, hover your mouse over the OvenPlayer provided on the detailed view page. Click on the [Settings] icon on the right side of the controller bar that appears.
Afterward, try clicking on each profile to check if it plays smoothly. You can also use external players like OvenPlayer Demo. Give it a try now!

Conclusion

Don’t worry about concerns that delivering multiple profiles will prevent low-latency streaming. OvenStudio LLHLS delivers ABR efficiently, providing streaming with a latency of less than 3 seconds while supporting all these benefits. OvenStudio LLHLS is the perfect tool for this. If you have any further questions or need additional information, please feel free to ask about OvenStudio LLHLS.

For more information

Why OvenStudio LLHLS issues Free TLS and Domain?

OvenMediaEngine — Fri, 01 Dec 2023 07:55:01 GMT

Live streaming is rapidly becoming a key component of modern communication and entertainment. However, setting up and operating a streaming server can come with numerous challenges, including security, authentication, and complex configurations.

Now, with OvenStudio LLHLS, you can address these issues effectively. OvenStudio LLHLS automatically provides users with a free TLS (Transport Layer Security) certificate and domain upon their initial connection, simplifying streaming security settings. This policy represents a significant upgrade in terms of security and accessibility, and while there are multiple reasons for issuing TLS, today we’ll explain it in connection with WebRTC Ingress.

Why is TLS Needed for WebRTC Ingress?

WebRTC (Web Real-Time Communication) is a protocol that supports real-time audio, video, and data communication over the web. It is used for implementing applications like voice calls, video chats, video conferencing, and file sharing without the need for plugins in web browsers. Real-time communication via web browsers is a matter of security concern, and the reasons for using TLS in WebRTC are as follows:

Enhanced Security: TLS strengthens communication security. WebRTC supports peer-to-peer (P2P) communication between devices, potentially transmitting sensitive information without one’s knowledge. TLS encrypts data, preventing third parties from intercepting or eavesdropping on the communication.
Authentication and Trust: TLS provides mutual authentication between the server and the client, enabling web applications to verify that they are communicating with the actual server. This helps prevent man-in-the-middle attacks (MitM).
Data Integrity: TLS ensures data integrity by preventing data from being tampered with during transmission, preserving the accuracy of the data.
Browser Security Policy Compliance: Most web browsers require web applications using WebRTC to use TLS, and non-compliance may lead to restrictions or blocking of the web application.
Regulatory Compliance: Web applications handling sensitive personal information, such as medical records or financial data, must adhere to security regulations and compliance requirements. Using TLS helps meet these regulatory requirements.

In summary, using TLS in WebRTC enhances communication security, protects privacy, maintains data integrity, and ensures compliance with browser policies and regulations. Therefore, it has to use TLS when implementing WebRTC.

OvenStudio LLHLS minimizes the complexity of settings, providing an authentication certificate and domain issuance upon the initial connection, enabling anyone to easily set up and deliver low-latency streaming.

For installation and usage instructions, please refer to the Quick Start Guide for OvenStudio LLHLS.

Why Automatic TLS and Domain Setup on Initial Connection in OvenStudio LLHLS?

OvenStudio LLHLS is a streaming server that allows streaming with less than 3 seconds of latency. When users transmit media sources through OvenStudio LLHLS, they may be using WebRTC (if you’re curious about how to Ingress media sources with WebRTC in OvenStudio LLHLS, please refer to our previous post). Therefore, on the initial connection, OvenStudio LLHLS automatically issues TLS certificates and sets up a domain to enhance security, ensure compliance with regulations, and simplify the process by replacing complex IP addresses with user-friendly domains.

To further enhance usability in the future, we plan to add a custom domain feature that allows users to configure certificates and domains directly. This feature not only serves as a branding element but also streamlines usability since OvenStudio LLHLS utilizes the server’s domain for Streaming URLs and Stream Keys. When this feature is released, we anticipate it will make the setup more concise and user-friendly.

The Advantages of OvenStudio LLHLS’s TLS and Automatic Domain Issuance Policy

Simplified Security Configuration: OvenStudio LLHLS streamlines the setup of TLS, providing an automated process for the issuance of free TLS certificates and domains. There’s no need to worry about complex TLS settings.
Increased Reliability: By employing TLS, OvenStudio LLHLS ensures the secure transmission of streaming, contributing to a higher level of overall service reliability.
Regulatory Compliance: The TLS and automatic domain issuance policy helps OvenStudio LLHLS adhere to regulatory standards for Browsers, offering a straightforward approach to compliance.

Conclusion

Automatically setting up free TLS certificates and domains using OvenStudio LLHLS is a crucial step in providing users with enhanced security and increasing the reliability of the streaming server. Through these policies, viewers can enjoy safe and stable streaming, and service providers can meet compliance and security requirements. Elevate your streaming security and deliver a better service to your users with OvenStudio LLHLS. Also, stay tuned for the upcoming custom domain feature in future updates.

For more information

WebRTC to LLHLS Streaming with OvenStudio LLHLS using OvenLiveKit

OvenMediaEngine — Tue, 19 Sep 2023 10:11:28 GMT

If you want to use streaming with a latency of less than 3 seconds but don’t have separate software or hardware to transmit your media source to OvenStudio LLHLS, don’t worry. It comes with OvenLiveKit, which allows you to transmit streams through WebRTC directly from a web browser, without the need for additional software or plugins.

Key Benefits Using OvenLiveKit

Ease of Use and Accessibility: There’s no need to install additional software or plugins. Just open your web browser, capture your webcam/microphone or your current screen, and start your live streaming.
Cross-Browser Compatibility: WebRTC is supported by most major web browsers, making it easy to stream live across various platforms.

In summary, with OvenLiveKit, you can broadcast your screen directly from your browser without the hassle of installing extra software or configuring intricate settings. Here’s a basic guide on how to use OvenLiveKit within OvenStudio LLHLS.

OvenLiveKit?

OvenLiveKit (for Web) is an Open-Source and JavaScript-based Live Streaming Encoder that supports WebRTC optimized for OvenMediaEngine, an Open-Source Sub-Second Latency Streaming Server. However, as you may be aware, OvenStudio LLHLS is developed with it, which means that OvenLiveKit will seamlessly work in OvenStudio LLHLS.

This kit leverages the browser’s WebRTC API, simplifying the process of sending WebRTC streams directly to OvenStudio LLHLS. If you’re interested in learning more, check out the links below.

Using OvenLiveKit in Your Web Browser

OvenLiveKit is provided along with OvenStudio LLHLS. Follow these steps to start WebRTC streaming with it. This guide used the Chrome browser.

1. Create a Streaming Box: Access OvenStudio LLHLS via your web browser and create a streaming box. After that, go to the detailed view page.

2. Start Streaming: Under the player section, you’ll find the [Start Streaming] button. Click it to send your media source to OvenStudio LLHLS. There are two options:

WebCam/Mic

i) Click on the [Start Streaming] button located at the bottom of OvenPlayer and select [WebCam/Mic] from the menu that appears.

ii) In the subsequent WebCam/Mic settings screen, choose your video and audio capture devices. Ensure that your video and audio are displaying correctly. Then, click the [Start Streaming] button to send your media source to OvenStudio LLHLS.

iii) If you encounter issues capturing your screen in the WebCam/Mic settings screen, please check your browser’s permissions.

iv) In the bottom right, compare the latency between the capturing OvenLiveKit and OvenPlayer on the left. It’s really that simple.

Screen Sharing

i) The process for Screen Sharing is just as straightforward as WebCam/MIC. Once you are in the detailed view, click the [Start Streaming] button located at the bottom of OvenPlayer and select [Screen Sharing] from the menu that appears.

ii) In the subsequent Screen Sharing settings, choose the screen you wish to broadcast by selecting either [Select from opened browser tabs — Chrome Tab], [Select from running programs — Window], or [Select entire screen capture — Entire Screen]. Of course, the displayed tab name may vary depending on the browser. Then, click the [Start Streaming] button to send your media source to OvenStudio LLHLS.

iii) Compare the latency between the capturing OvenLiveKit at the bottom right, the selected tab for capture, and OvenPlayer on the left. This option is great for presentations, screen sharing, or demos.

Going Live with Sub-3-Second Latency

Choose your desired option and configure your capture device settings. You can easily stream your captured screen to OvenStudio LLHLS. It accepts WebRTC streams and provides low-latency HLS (LLHLS) streaming to your viewers, with a delay of less than 3 seconds.

Conclusion

This guide demonstrates how you can stream your webcam/microphone or screen capture directly to OvenStudio LLHLS from your web browser. This approach makes web-based live streaming a breeze without the need for additional software or plugins. Try it out to leverage the powerful low-latency streaming capabilities of OvenStudio LLHLS and enhance your interaction with viewers.

For more information

Low-Latency Streaming to OvenStudio LLHLS using OBS Studio

OvenMediaEngine — Thu, 14 Sep 2023 11:34:26 GMT

Content creation and sharing industries are evolving at an unprecedented pace, and video/audio streaming has become an integral part of our daily lives.

For content providers, streamers, and businesses utilizing streaming, finding the right tools to seamlessly broadcast media sources is essential. OvenStudio LLHLS supports various ingress protocols such as WebRTC, WHIP, SRT, and RTMP, allowing you to send media sources to OvenStudio LLHLS using software encoders like OvenLiveKit, OvenStreamEncoder, OBS, Xsplit,

With Software Encoder

or even hardware encoders.

With Hardware Encoder

Open Broadcaster Software (OBS or OBS Studio) is one of the most popular open-source live encoders globally, favored by creators and streamers alike. These encoders enable content to be streamed to a streaming server using various protocols. When using OvenStudio LLHLS as your streaming server, you can reduce the traditional streaming delay of around 10 seconds to less than 3 seconds, providing an interactive experience for your viewers.

In this guide, we’ll walk you through the process of using OBS to send media sources to OvenStudio LLHLS.

OvenStudio LLHLS?

OvenStudio LLHLS is a Low-Latency Streaming Server that operates in a Cloud environment, boasting exceptional performance and scalability. It supports a range of ingress protocols (WebRTC, WHIP, SRT, RTMP, and more), allowing media sources received via these protocols to be streamed as Low Latency HLS (LLHLS) with a streaming delay of less than 3 seconds. If you want to broadcast various content with minimal delay, OvenStudio LLHLS is your solution.

Sending Media Sources to OvenStudio LLHLS

The process of sending media sources to OvenStudio LLHLS using OBS is straightforward and can be summarized in the following steps:

1. OBS Installation: Start by downloading the appropriate version of OBS for your operating system from the official website and install it on your computer. Launch OBS and load the media source you want to broadcast.

2. OBS Settings: Click on the [Settings] button in the bottom right corner of OBS. Here, you can select your desired video and audio devices, and adjust basic settings like resolution, framerate, bitrate, and more.

3. Create a Streaming Box: After logging into OvenStudio LLHLS, click the [+] button on the main page to create a Managed Stream.

4. Choose the Appropriate Streaming Protocol: OBS can transmit a media source with various ingress protocols like WebRTC, WHIP, SRT, and RTMP, among others. Once you’ve created your Managed Stream in OvenStudio LLHLS, click on it to access the details. In the right-hand menu, navigate to the [URLs] tab and copy the Ingress URL (Stream key) for your chosen protocol. Or, on the same page, press the [Start streaming] button at the bottom of the player and select the [Live Encoder] tab from the menu that appears. Using the ingress URL that appears afterward works the same way.

5. Enter Stream Key: Return to the OBS settings screen and enter the Stream key you copied. Then, close the settings window. Then click the [OK] button below to close the settings window.

WebRTC — wss://{domain}:{port}/{app name}/{stream name?direction=send}
WHIP — wss://{domain}:{port}/{app name}/{stream name?direction=whip}
SRT — srt://{domain}:{port}?streamid=srt%3A%2F%2F{domain}%3A{port}%2F{app name}%2F{stream name}
RTMP — rtmp://{domain}:{port}/{app name}/{stream name}

6. Connect and Start Streaming: Once you’ve configured OBS, click the [Start Streaming] button to begin streaming your video to OvenStudio LLHLS.

7. Low-Latency Streaming Monitoring: If your media source is successfully delivered to OvenStudio LLHLS, you can monitor it using the OvenPlayer within OvenStudio LLHLS. You can also use the Origin URL (or Edge URL, depending on your settings) from the [URLs] tab to watch it in LLHLS-compatible players like OvenPlayer, THEO Player, and others.

8. Checking Latency: To ensure your streaming delay is less than 3 seconds, compare the OBS streaming screen to what you see on OvenStudio LLHLS’s player. If your streaming exceeds 3 seconds, check if the [Live Streaming] indicator at the bottom of the OvenStudio LLHLS player is lit in red. If it is, but your streaming delay still exceeds 3 seconds, it might be related to network, system performance, instance location, or instance type issues.

In Conclusion

OvenStudio LLHLS provides easy scalability and delivers reliable low-latency streaming. It can be employed in various interactive content services, including game streaming, sports streaming, entertainment events, online classes, video conferencing, and more — What you can do with OvenStudio LLHLS.

The technological advancements and flexibility offered by OvenStudio LLHLS present content creators and streamers with opportunities to utilize streaming in diverse ways, enhancing interactions with viewers. Enjoy a superior streaming experience with OvenStudio LLHLS!

For more information

How to choose an AWS EC2 Instance for using OvenStudio LLHLS?

OvenMediaEngine — Tue, 12 Sep 2023 05:46:14 GMT

When it comes to deploying OvenStudio LLHLS on the AWS Marketplace, selecting the right EC2 instance type is a critical decision that can significantly impact your streaming performance and cost efficiency. In this blog post, we’ll guide you through the process of choosing the optimal EC2 instance for your OvenStudio LLHLS deployment.

#01. Consider Your Workload and Streaming Requirements

Before diving into EC2 instance types, evaluate your streaming workload and requirements. Factors to consider include:

Concurrent Viewers: Estimate the number of simultaneous viewers you expect. This will impact the CPU, memory, and network resources needed.
Video Quality: Higher quality streams require more resources. Determine the desired video quality (resolution, bitrate, framerate, and more) of your streams.

#02. CPU and Memory Requirements

For OvenStudio LLHLS, CPU and memory are crucial. Here are some EC2 instance families that offer a good balance between CPU and memory:

M5 Instances: These provide a balanced mix of resources, ideal for moderate CPU and memory-intensive workloads.
C5 Instances: Designed for compute-intensive tasks, these instances offer high CPU performance.

#03. Network Performance

Since streaming involves transmitting large amounts of data, network performance matters. EC2 instance types vary in their network capabilities:

Network Performance Levels: Instances like the C4, C5, M4, and M5 families generally offer higher network performance.
Enhanced Networking: Look for instances that support Enhanced Networking, which can improve network throughput and latency.

#04. EC2 Instance Sizing

OvenStudio LLHLS supports a variety of instance types including T2, T3, M4, M5, M6, C4, C5, C6, depending on various usage scenarios. The list of instances that can use OvenStudio LLHLS is shown below:

T2: t2.micro, t2.small, t2.medium, t2.large, t2.xlarge, t2.2xlarge
T3: t3.micro, t3.small, t3.medium, t3.large, t3.xlarge, t3.2xlarge
T3A: t3a.micro, t3a.small, t3a.medium, t3a.large, t3a.xlarge, t3a.2xlarge
M4: m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, m4.10xlarge, m4.16xlarge
M5: m5.large, m5.xlarge, m5.2xlarge, m5.4xlarge, m5.8xlarge, m5.12xlarge, m5.16xlarge, m5.24xlarge, m5.metal
M5A: m5a.large, m5a.xlarge, m5a.2xlarge, m5a.4xlarge, m5a.8xlarge, m5a.12xlarge, m5a.16xlarge, m5a.24xlarge
M5AD: m5ad.large, m5ad.xlarge, m5ad.2xlarge, m5ad.4xlarge, m5ad.8xlarge, m5ad.12xlarge, m5ad.16xlarge, m5ad.24xlarge
M5D: m5d.large, m5d.xlarge, m5d.2xlarge, m5d.4xlarge, m5d.8xlarge, m5d.12xlarge, m5d.16xlarge, m5d.24xlarge, m5d.metal
M5ZN: m5zn.large, m5zn.xlarge, m5zn.2xlarge, m5zn.3xlarge, m5zn.6xlarge, m5zn.12xlarge, m5zn.metal
M6I: m6i.large, m6i.xlarge, m6i.2xlarge, m6i.4xlarge, m6i.8xlarge, m6i.12xlarge, m6i.16xlarge, m6i.24xlarge, m6i.32xlarge, m6i.metal
C4: c4.8xlarge
C5: c5.large, c5.xlarge (Vendor Recommended), c5.2xlarge, c5.4xlarge, c5.9xlarge, c5.12xlarge, c5.18xlarge, c5.24xlarge, c5.metal
C5D: c5d.9xlarge, c5d.12xlarge, c5d.18xlarge, c5d.24xlarge, c5d.metal
C5A: c5a.8xlarge, c5a.12xlarge, c5a.16xlarge, c5a.24xlarge
C5N: c5n.9xlarge, c5n.18xlarge, c5n.metal
C6I: c6i.large, c6i.xlarge, c6i.2xlarge, c6i.4xlarge, c6i.8xlarge, c6i.12xlarge, c6i.16xlarge, c6i.24xlarge, c6i.32xlarge, c6i.metal

If you want to know the performance and features of each instance, you can refer to the guides provided by AWS. Click the links below to see a description of each instance:

Low-cost and General Purpose (T2): Amazon EC2 T2 Instances
Low-cost and General Purpose (T3): Amazon EC2 T3 Instances
General Purpose (M5~M6): Amazon EC2 Instance M-Types
Optimized Computing (C4~C6): Amazon EC2 Instance C-Types

#05. Cost Optimization

Optimizing costs is essential. Choose an instance that meets your requirements without being overprovisioned. AWS offers various pricing options (On-Demand, Spot Instances, Reserved Instances) that can help control costs.

The AWS Marketplace provides calculators to help you figure out your software and instance costs, click HERE for more details.

Conclusion

Selecting the right EC2 instance type for OvenStudio LLHLS enables smooth and efficient streaming performance. By evaluating your workload, and considering CPU, memory, network, and storage requirements, you can make an informed decision that aligns with your streaming goals and budget. For a comprehensive guide on EC2 instance types, performance benchmarks, and hands-on examples, check out our detailed documentation on the OvenStudio LLHLS User Guide.

Tailor your OvenStudio LLHLS to fit your needs by considering your requirements, instance characteristics, specifications, and pricing. For instance, if you want to utilize OvenStudio LLHLS to its full potential and set up medium to large-scale streaming, following our recommendation, you might choose the c5.xlarge instance on a C5 instance family. This instance offers specifications of 4vCPU / 8GiB RAM / Up to 10Gbps (Network Bandwidth) / Up to 4750Mbps (EBS Bandwidth), with an hourly cost of $0.33 (Software: $0.16 per hour, Instance: $0.17 per hour). Plus, with an annual commitment, you can enjoy the software at a discounted rate of $450, which is approximately 68% cheaper.

Moreover, if your streaming requirements grow beyond your current selection, you can consider scaling up by choosing higher-spec instances. Alternatively, leverage OvenStudio LLHLS’s seamless integration with AWS CloudFront to expand your streaming distribution by adding Edge Servers as needed.

Remember, making the right EC2 instance choice sets the foundation for a successful and reliable OvenStudio LLHLS deployment on the AWS Marketplace.