RTSP has been the de facto protocol for IP cameras for over two decades. Almost every CCTV, IP camera, and network video device on the market speaks RTSP natively. It works well on dedicated NVR appliances and desktop clients. But the moment you try to bring those streams into a modern web or mobile dashboard, the cracks start to show.

The Hidden Cost of Always-On Streaming​

Browsers do not speak RTSP. Neither do mobile devices. To make an RTSP feed playable on a web page, you need to convert it. The most efficient way to do that, with sub-second latency and no plugins, is WebRTC.

So far, so straightforward. The real problem starts when you scale.

A typical surveillance deployment has hundreds, sometimes thousands of cameras. A traditional VMS or media gateway pulls every single RTSP stream the moment the server boots, decodes them, and keeps them flowing, whether anyone is watching or not. Multiply that by a few hundred cameras, and you are looking at racks of servers just to keep streams available, not even being viewed.

But here is the truth about surveillance: operators rarely watch every camera at once. They watch a wall of four, sixteen, maybe thirty-two tiles. The rest of the cameras are sitting idle, consuming CPU, RAM, and bandwidth for no one.

That waste is what On-Demand Live streaming eliminates.

How On-Demand Live Works​

OvenMediaEngine (OME) works differently. Instead of pulling every RTSP stream continuously, OME pulls a camera only when someone asks to watch it.

• When a viewer requests a WebRTC stream for a specific camera, OME pulls the RTSP feed from that camera.
• While viewers are connected, OME re-encodes and forwards the stream over WebRTC with sub-second latency.
• When the last viewer disconnects, OME stops pulling. The RTSP connection is closed. The resources are released.
• If a second viewer joins while the stream is already running, OME serves them from the existing stream. No duplicate pull, no extra CPU.

The result: idle cameras cost nothing. You can register hundreds of cameras on a single OME Origin server, and the actual load on the server is determined by how many cameras are being watched right now, not how many exist in your catalog.

For a real surveillance workload, where operators watch a small subset at any given time, this changes the infrastructure economics entirely.

Three Ways to Configure On-Demand Live RTSP​

OME provides three ways to define the mapping between a WebRTC stream URL and the underlying RTSP camera. Pick the one that fits how your camera inventory is managed.

1. OriginMap: static configuration in Server.xml​

The simplest option. Define each camera as an <Origin> entry inside your VirtualHost:

<VirtualHosts>
  <VirtualHost>
    <Origins>
      <Properties>
        <NoInputFailoverTimeout>3000</NoInputFailoverTimeout>
        <UnusedStreamDeletionTimeout>60000</UnusedStreamDeletionTimeout>
      </Properties>
      <Origin>
        <Location>/app/rtsp_camera1</Location>
        <Pass>
          <Scheme>rtsp</Scheme>
          <Urls><Url>cctv1.com:9000/camera</Url></Urls>
          <ForwardQueryParams>true</ForwardQueryParams>
        </Pass>
      </Origin>
      <Origin>
        <Location>/app/rtsp_camera2</Location>
        <Pass>
          <Scheme>rtsp</Scheme>
          <Urls><Url>cctv2.com:9000/camera</Url></Urls>
          <ForwardQueryParams>true</ForwardQueryParams>
        </Pass>
      </Origin>
    </Origins>
  </VirtualHost>
</VirtualHosts>

Two properties worth noting:

• NoInputFailoverTimeout — how long OME waits for input before declaring the source unavailable.
• UnusedStreamDeletionTimeout — how long OME keeps an idle stream alive after the last viewer disconnects. This is what makes On-Demand Live work. Once the timeout passes with no viewers, the stream is torn down and resources are released.

When a client connects to wss://ome.server.com:3334/app/rtsp_camera1, OME pulls from the configured RTSP URL on demand and streams it back over WebRTC.

Full configuration options are available in the Clustering documentation.

2. OriginMapStore: dynamic mapping with Redis​

If your camera list changes often, hardcoding URLs in Server.xml is not practical. OriginMapStore lets you keep the mappings in a Redis server, where OME looks them up at request time.

<VirtualHost>
  ...
  <OriginMapStore>
    <RedisServer>
      <Host>192.168.0.160:6379</Host>
      <Auth><your-redis-password></Auth>
    </RedisServer>
  </OriginMapStore>
  ...
</VirtualHost>

Register cameras as Redis keys, where the key is the stream path and the value is the RTSP URL:

127.0.0.1:6379> set app/rtsp_camera1 rtsp://cctv1.com:9000/camera
OK
127.0.0.1:6379> get app/rtsp_camera1
"rtsp://cctv1.com:9000/camera"

Adding, updating, or removing a camera is now a one-line Redis operation. No OME restart required.

3. REST API: integration with external systems​

If you already have a camera management platform, VMS, or asset inventory, the REST API is the cleanest path. Create streams programmatically:

POST https://ome-server.com/v1/vhosts/default/apps/app/streams

{
  "name": "rtsp_camera1",
  "urls": ["rtsp://192.168.0.160:553/app/stream"],
  "properties": {
    "persistent": false,
    "noInputFailoverTimeoutMs": 3000,
    "unusedStreamDeletionTimeoutMs": 60000,
    "ignoreRtcpSRTimestamp": false
  }
}

The "persistent": false setting is the key. It tells OME to release resources when no one is watching, exactly the On-Demand Live behavior we want. Set it to true only if you genuinely need the stream to be always-on (for recording or relay purposes).

Beyond a Single Server​

A single OME Origin can handle a very large camera catalog, because idle cameras cost nothing. But concurrent viewers are a different story. WebRTC sessions are real connections with real CPU and bandwidth cost.

When the number of operators viewing streams grows beyond what one server can handle, OME scales horizontally without architectural change. Place multiple OME servers behind an L4 load balancer or DNS round-robin, and each incoming WebRTC request lands on one of them. Whichever server receives the request will pull the RTSP feed and serve the client. The same OriginMap, OriginMapStore, or REST API configuration works across all of them.

Servers are stateless, and cameras are pulled only when needed. No central state to coordinate, no message bus to operate.

What Else You Get for Free​

Because OME ingests RTSP through its full media pipeline, every other OME feature works on these streams out of the box:

• ABR (Adaptive Bitrate) — transcode each camera into multiple resolutions, so a tablet on cellular and a 4K control room display get the appropriate quality without changing the camera.
• Codec conversion — cameras often output H.264 profiles or audio settings that are not WebRTC-friendly. OME normalizes them automatically.
• Video-only or audio-only profiles — strip audio for bandwidth-sensitive deployments, or vice versa.
• Access control & authorization — SignedPolicy and AdmissionWebhooks let you decide which operator can view which camera, on a per-request basis.

None of this requires extra components. It is the same pipeline.

Closing the Loop​

Surveillance has always been about scale: more cameras, more sites, more operators. The traditional answer was to throw more servers at the problem. On-Demand Live streaming flips the equation. You stop paying for what you are not watching, and the size of your camera inventory stops driving the size of your infrastructure.

OvenMediaEngine makes this practical with a few lines of configuration and the same WebRTC pipeline that already serves sub-second latency to browsers and mobile devices worldwide.

For Mission-Critical Surveillance​

Surveillance is an environment where streams cannot drop. Running hundreds of cameras unattended requires GUI-based management, and anomalies must reach operators instantly. SI projects and solution deployments also need to clear the licensing question.

OvenMediaEngine Enterprise is built for these operational requirements.

• Web Console — a GUI dashboard to monitor and manage hundreds of cameras and streams at a glance. Operators no longer need to edit configuration files or hit APIs for routine tasks.
• Enhanced Alert — stream and system anomalies are detected with configurable rules and sent to external monitoring systems via HTTP callbacks in real time.
• Commercial License — no AGPLv3 source disclosure obligation. Free to use in SI projects, solution deliverables, and proprietary services.
• Pre-Built Package — verified LTS builds available as DEB, RPM, and Docker images for fast deployment. Suitable for air-gapped and on-premise environments.
• Direct-to-Engineer Support — technical support directly from OvenMediaEngine's core engineers.

If you are evaluating Enterprise for your deployment, reach out at contact@ovenmedialabs.com or learn more on the OvenMediaEngine Enterprise page.

Want to test first?​

You can launch OvenMediaEngine Enterprise from AWS Marketplace starting at $0.19 per hour, suitable for validation before full deployment.

Detailed configuration and operations guides are available in the OME Enterprise documentation and the OME open-source documentation.

The OvenMedia Labs blog is now hosted directly on our own domain. Going forward, deep dives into sub-second latency live streaming, OvenMediaEngine release notes, and field-tested guidance will all land here first.

What changes​

• The blog moves from Medium to ovenmedialabs.com/blog.
• Existing Medium posts will be migrated with their original publish dates preserved.
• Old Medium URLs will redirect to their new home so links you've shared still work.
• RSS feed updates to ovenmedialabs.com/blog/rss.xml.

What stays the same​

• The same engineers writing about the same problems they're solving in production.
• Open-source first.
• No marketing-flavored fluff — practical insights about live streaming infrastructure.

If you're building real-time media services, subscribe to the new feed and follow us on GitHub for everything else.

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.

• [Part1] WebRTC: A New Paradigm for Real-Time Web Communication
• [Part2] HLS: IS it Possible to Achieve Low-Latency Streaming with HLS?
• [Part3] Low-Latency HLS: The Era of Flexible Low-Latency Streaming

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=<M>: 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=<N>: 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 <ChunkDuration> 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 <SegmentDuration> 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 <SegmentCount> 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 <PartHoldBack> 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 **(<ChunkDuration>): 1 second
• **Segment Duration **(<SegmentDuration>): 4 seconds
• Segment Count (<SegmentCount>): 10
• **Part Hold Back **(<PartHoldBack>): 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 **(<ChunkDuration>): 0.5 seconds
• **Segment Duration **(<SegmentDuration>): 4 seconds
• Segment Count (<SegmentCount>): 10
• **Part Hold Back **(<PartHoldBack>): 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 **(<ChunkDuration>): 0.2 seconds
• **Segment Duration **(<SegmentDuration>): 4 seconds
• Segment Count (<SegmentCount>): 10
• **Part Hold Back **(<PartHoldBack>): 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 <ChunkDuration> 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​

• OvenMediaEngine Website
• OvenMediaEngine GitHub
• OvenMediaEngine User Guide

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.

• [Part1] WebRTC: A New Paradigm for Real-Time Web Communication
• [Part2] HLS: IS it Possible to Achieve Low-Latency Streaming with HLS?
• [Part3] Low-Latency HLS: The Era of Flexible Low-Latency Streaming

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​

• OvenMediaEngine Website
• OvenMediaEngine GitHub
• OvenMediaEngine User Guide

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.

• [Part1] WebRTC: A New Paradigm for Real-Time Web Communication
• [Part2] HLS: IS it Possible to Achieve Low-Latency Streaming with HLS?
• [Part3] Low-Latency HLS: The Era of Flexible Low-Latency Streaming

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://<OvenMediaEngine IP>[:RTMP Listen Port]/<App Name>/<Stream Name>
• **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://<OvenMediaEngine IP>[:WebRTC Listen Port]/<App Name>/<Stream Name>?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 Website
• OvenMediaEngine GitHub
• OvenMediaEngine User Guide

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!

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=<Instance_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://<Instance_IP>:1935/app/<Stream_Name>

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://<Instance_IP>:3333/app/<Stream_Name>
• LLHLS: http://<Instance_IP>:3333/app/<Stream_Name>/llhls.m3u8

With TLS​

• OvenPlayer Demo: https://demo.ovenplayer.com
• WebRTC: wss://<Domain>:3334/app/<Stream_Name>
• LLHLS: https://<Domain>:3334/app/<Stream_Name>/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=<Instance_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 <Domain> -m <Email> --agree-tos  -n

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

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

<TLS>
  <CertPath>./cert.crt</CertPath>
  <KeyPath>./cert.key</KeyPath>
  <ChainCertPath>./cert.ca-bundle</ChainCertPath>
</TLS>

Here’s how to copy these:

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

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

# Copy and rename fullchain.pem to cert.ca-bundle
$ sudo cp /etc/letsencrypt/live/<Domain>/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=<Instance_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://<Domain>:3334/app/<Stream_Name>
• LLHLS: https://<Domain>:3334/app/<Stream_Name>/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.

<OutputProfile>
 <Name>bypass_stream</Name>
 <OutputStreamName>${OriginStreamName}</OutputStreamName>
 <!--LLHLS URL : https://domain/app/stream/abr.m3u8 --> 
 <Playlist>
  <Name>For ABR</Name>
  <FileName>abr</FileName>
  <Options> <!-- Optinal -->
   <!-- 
   Automatically switch rendition in WebRTC ABR 
   [Default] : true
   -->
   <WebRtcAutoAbr>true</WebRtcAutoAbr> 
  </Options>
  <Rendition>
   <Name>Bypass</Name>
   <Video>bypass_video</Video>
   <Audio>bypass_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>FHD</Name>
   <Video>video_1920</Video>
   <Audio>bypass_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>HD</Name>
   <Video>video_720</Video>
   <Audio>bypass_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>SD</Name>
   <Video>video_480</Video>
   <Audio>bypass_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>FHD_Opus</Name>
   <Video>video_1920</Video>
   <Audio>opus_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>HD_Opus</Name>
   <Video>video_720</Video>
   <Audio>opus_audio</Audio>
  </Rendition>
  <Rendition>
   <Name>SD_Opus</Name>
   <Video>video_480</Video>
   <Audio>opus_audio</Audio>
  </Rendition>
 </Playlist>
 <!--LLHLS URL : https://domain/app/stream/llhls.m3u8 --> 
 <Playlist>
  <Name>Change Default</Name>
  <FileName>llhls</FileName>
  <Rendition>
   <Name>HD</Name>
   <Video>video_720</Video>
   <Audio>bypass_audio</Audio>
  </Rendition>
 </Playlist> 
 <Encodes>
  <Audio>
   <Name>bypass_audio</Name>
   <Bypass>true</Bypass>
  </Audio>
  <Video>
   <Name>bypass_video</Name>
   <Bypass>true</Bypass>
  </Video>
  <Audio>
   <Name>opus_audio</Name>
   <Codec>opus</Codec>
   <Bitrate>128000</Bitrate>
   <Samplerate>48000</Samplerate>
   <Channel>2</Channel>
  </Audio>
  <Video>
   <Name>video_1920</Name>
   <Codec>h264</Codec>
   <Bitrate>1024000</Bitrate>
   <Framerate>30</Framerate>
   <Width>1920</Width>
   <Height>1080</Height>
   <Preset>faster</Preset>
  </Video>
  <Video>
   <Name>video_720</Name>
   <Codec>h264</Codec>
   <Bitrate>724000</Bitrate>
   <Framerate>30</Framerate>
   <Width>1280</Width>
   <Height>720</Height>
   <Preset>faster</Preset>
  </Video>
  <Video>
   <Name>video_480</Name>
   <Codec>h264</Codec>
   <Bitrate>224000</Bitrate>
   <Framerate>30</Framerate>
   <Width>720</Width>
   <Height>480</Height>
   <Preset>faster</Preset>
  </Video>
 </Encodes>
</OutputProfile>

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=<Instance_IP> ./ome_docker_launcher.sh start

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

Without TLS​

• OvenPlayer Demo: http://demo.ovenplayer.com
• WebRTC: ws://<Instance_IP>:3333/app/<Stream_Name>/<FileName>
• LLHLS: http://<Instance_IP>:3333/app/<Stream_Name>/<FileName>.m3u8

With TLS​

• OvenPlayer Demo: https://demo.ovenplayer.com
• WebRTC: wss://<Domain>:3334/app/<Stream_Name>/<FileName>
• LLHLS: https://<Domain>:3334/app/<Stream_Name>/<FileName>.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 <Rendition> is displayed.

When writing <OutputProfile> 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 <Bind> in Server.xml and added 8082/TLS.

 <Bind>
  <Managers>
   <API>
    <Port>${env:OME_APIT_PORT:8081}</Port>
    <TLSPort>${env:OME_APIT_PORT:8082}</TLSPort>
    <WorkerCount>1</WorkerCount>
   </API>
  </Managers>
  ...
 </Bind>

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

 <Managers>
  <Host>
   <Names>
    <Name>*</Name>
   </Names>
   <TLS>
    <CertPath>./cert.crt</CertPath>
    <KeyPath>./cert.key</KeyPath>
    <ChainCertPath>./cert.ca-bundle</ChainCertPath>
   </TLS>
  </Host>
  <API>
   <AccessToken>ID:Password</AccessToken>
   <CrossDomains>
    <Url>*</Url>
   </CrossDomains>
  </API>
 </Managers>

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=<Instance_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://<Instance_IP>:8081/v1/<Resource>

With TLS​

• https://<Domain>:8082/v1/<Resource>

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.

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​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

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​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

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​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

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​

1. 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.
2. 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.

• OvenLiveKit GitHub
• OvenSpace Demo

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​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

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​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

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.

For more information​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

OvenStudio LLHLS, a low-latency streaming server designed for the cloud, is built upon the open-source sub-second latency streaming server, OvenMediaEngine. Despite the availability of technology that can achieve sub-1-second latency for streaming, OvenStudio LLHLS has chosen to adopt a technology that achieves sub-3-second latency.

Why?​

While leveraging WebRTC output could potentially expand the application scope of OvenStudio LLHLS, there is no CDN service that supports WebRTC, and involves setting up and operating an edge cluster yourself. This can be complex and specialized, which is why many people still opt for traditional CDN services when using (LL)HLS. The ease of configuration and management is a key factor.

Furthermore, WebRTC is primarily focused on near-real-time streaming and does not support Digital Rights Management (DRM). Thus, for services requiring DRM support, implementing WebRTC can be challenging. OvenStudio LLHLS has plans to support DRM in the near future, so if DRM is essential for your service, stay tuned for the upcoming updates.

There are certainly cases where sub-second latency is important, such as ‘near-real-time events’. Please read the examples we present below. If you need this technology, you need OvenMediaEngine.

Live Event Streaming​

• News Updates: OvenMediaEnigne powers live news broadcasts, enabling audiences to stay connected with breaking news and unfolding events as they happen. Whether it’s a live report from the scene or a breaking story, OvenMediaEngine enables viewers to receive up-to-the-minute updates at sub-second latency.
• Interactive Games: Sub-second latency streaming technology through OvenMediaEngine turns gaming sessions into thrilling and immersive experiences, making the gameplay interactions truly captivating when the interaction between game streamers and viewers.
• Online Gambling: OvenMediaEngine enhances the online gambling experience by delivering near-real-time event and outcome updates from virtual casinos. This enables gamblers to stay informed about the latest developments, making their betting experience more engaging and dynamic.
• Horse Racing and Sports Betting: For platforms offering horse racing and sports betting, OvenMediaEngine enables instantaneous updates on ongoing events and outcomes. This sub-second latency streaming empowers bettors to make informed decisions quickly.
• Financial and Stock Markets: In the world of finance and stock trading, where every second counts, streaming with less than 1 second of delay becomes mission-critical. OvenMediaEngine allows you to deliver streams of financial transactions and market updates with sub-second latency. This near-real-time advantage can potentially translate into significant financial gains, making it a game-changer for traders and investors.
• Online Auctions: OvenMediaEngine finds applications in online auction platforms, enabling bidders to receive near-real-time updates on the bidding process. This enables participants to stay informed about the latest bids and auction progress, contributing to a competitive and engaging experience.

If you want to easily extend your service to millions of viewers globally through CDN integration while enjoying sub-3-second latency, OvenStudio LLHLS is the perfect fit. Certainly, providing the mentioned ‘Live Event Streaming’ use cases with streaming delays of less than 3 seconds is entirely feasible.

Now, OvenStudio LLHLS brings forth a low-latency streaming technology that finds application in diverse scenarios across various industries. Let’s delve into some prominent use cases where OvenStudio LLHLS’s cutting-edge streaming technology offers exceptional performance and reliability, contributing to the advancement of these industries.

Entertainment Streaming​

• Sports Coverage: From sports (and e-sports) matches to athletic events, OvenStudio LLHLS’s low-latency streaming enables viewers to experience the thrill of every moment, keeping up with the action as if they were present on the field.
• Live Concerts: OvenStudio LLHLS empowers the entertainment industry by enabling live concert streaming. Fans can enjoy the performance at low latency, while artists can interact with their audience, creating an immersive and engaging experience.
• Fan Engagement Platforms: OvenStudio LLHLS facilitates direct interaction between artists and fans through live streaming. Quick responses from artists during live sessions enhance fan engagement, making fans feel more connected to their favorite artists.

Educational Streaming​

• Remote Education: In the realm of remote learning, OvenStudio LLHLS supports low-latency delivery of lectures, enabling educators and students to interact seamlessly. Live Q&A sessions and low-latency discussions foster an engaging learning environment.
• Conferences: OvenStudio LLHLS finds application in conferences, allowing speakers to deliver their presentations in low latency while engaging with the audience through live Q&A sessions. This enriches the conference experience and encourages active participation.
• School Events: OvenStudio LLHLS supports low-latency interaction between teachers, students, and parents during school events. Whether it’s a parent-teacher streaming meeting or a school assembly, OvenStudio LLHLS enhances communication and engagement.
• Religious Services: OvenStudio LLHLS powers live streaming of religious events, enabling clergy members to connect with their congregation at low latency. This technology fosters a sense of community among worshippers, even in streaming settings.

Online Collaboration Tools​

• Online Screenings: By utilizing OvenStudio LLHLS for low-latency streaming, you can set up online screenings, enabling interaction between media and the audience. This provides a groundbreaking tool for film production companies, broadcasting networks, event planners, lecturers, and other content creators to innovate and execute engaging online premieres and screenings.
• Remote Meetings: OvenStudio LLHLS enhances remote meetings by providing low-latency response and communication among participants. This enables discussions to flow seamlessly, even when participants are geographically distant.
• Remote Work: OvenStudio LLHLS supports remote work scenarios by enabling low-latency collaboration and communication among team members. Whether it’s brainstorming sessions or project updates, OvenStudio LLHLS enables efficient and effective collaboration.

The diverse use cases mentioned above, which we will continuously enhance with input from our clients, will offer rapid responsiveness and interactivity with sub-3-second streaming latency. This will strengthen the bond between content creators and viewers or users, opening up a wide range of business opportunities.

Thank you for reading.

For more information​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

We are living in an era where anyone can easily broadcast content. In the past, broadcasting was limited to television stations, but now, with the power of smartphones and computers, anyone can effortlessly stream their content to the world. Streaming platforms and services have revolutionized the way we consume media, offering creators a convenient and fast way to share their creations with the world.

From YouTubers and streamers to artists and educators, people from various fields are using streaming to share their passions and talents with a global audience. Even businesses have embraced streaming to launch products, host events, and conduct meetings on a global scale.

However, to make all this streaming magic happen, we need Streaming Servers. Streaming servers play a crucial role in delivering various types of content, such as videos, music, and events, to viewers in a stable and reliable manner. Without a properly functioning streaming server, streaming platforms and services may encounter difficulties in smooth operations.

Let’s explore more about streaming servers in the following article!

What is a Streaming Server?​

A streaming server plays a crucial role in transmitting media content, such as video and audio (media sources), to users. It enables users to watch (stream) video or audio on web browsers, mobile apps, or other devices.

The most significant role of a streaming server is to deliver media data to users reliably. The technical reliability of the streaming server directly impacts the overall service stability. Additionally, the streaming server efficiently manages internet bandwidth and ensures a consistent streaming experience across various devices and platforms.

What is LLHLS Streaming Server?​

The Low Latency HLS (LLHLS) streaming server is designed for low-latency streaming. LLHLS is an advanced version of the streaming protocol HLS, originally developed by Apple. While conventional HLS typically uses segment lengths of 6 to 10 seconds, LLHLS significantly reduces segment lengths to minimize latency. This enables faster responsiveness, making it ideal for near-real-time interactive applications such as events, game streaming, online conferences, and video meetings.

LLHLS is mainly supported by web-based players and mobile apps. As most modern browsers and devices support LLHLS streaming, users can experience smooth streaming without the need for additional plugins.

How to Build an LLHLS Streaming Server?​

OvenStudio LLHLS is the best choice for quickly and easily building an LLHLS streaming server. With OvenStudio LLHLS, you can set up a low-latency streaming server in just a few minutes without the need for complex installation processes. The platform offers a user-friendly interface and powerful features, enabling efficient management of your streaming workflow. By choosing OvenStudio LLHLS, you can enhance user engagement and interaction with near-real-time updated content, providing more effective communication and a better user experience.

1. OvenStudio LLHLS enables low-latency streaming with a delay of under 3 seconds. For near-real-time content delivery, minimizing latency is crucial. To achieve this, OvenStudio LLHLS leverages cutting-edge technologies and the LLHLS protocol, providing stable and low-latency streaming.
2. OvenStudio LLHLS supports high-quality media content delivery with low latency. It efficiently handles the resources required for streaming high-quality media sources, ensuring stable delivery. Moreover, with CDN integration and scaling options, it can serve a larger audience with low-latency high-definition content.
3. OvenStudio LLHLS offers Adaptive Bitrate Streaming (ABR) support. This feature automatically adjusts the bitrate of content based on viewers’ network conditions and device capabilities, delivering an optimal viewing experience for each viewer.
4. OvenStudio LLHLS provides valuable statistics and data for analyzing viewers’ watching patterns and behavior. Content creators and service providers can gain insights into viewers’ preferences, identify areas for improvement, and enhance service quality.

OvenStudio LLHLS is designed to deliver and share high-quality media content in near-real-time. By choosing OvenStudio LLHLS on your AWS Cloud, you can operate your streaming platform or service more effectively.

For more information​

• OvenStudio LLHLS Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide

The pandemic has forced people to stay indoors, significantly changing today’s digital content consumption patterns. Many individuals have become aware of the latency issues in traditional streaming services and are now seeking digital content that can provide immediate responses.

Near-real-time events, game streaming, online lectures, and other fields require fast responsiveness and minimal delays. To meet these demands, the Low Latency HTTP Live Streaming (LLHLS) approach has gained attention. In this article, we will explore the concept, importance, implementation, and the OvenStudio LLHLS solution for low-latency streaming.

What is LLHLS Low-Latency Streaming?​

Low-Latency HLS (LLHLS) streaming is an advanced version of Apple’s HTTP Live Streaming (HLS) protocol designed to minimize latency in near-real-time streaming. By significantly reducing the segment length compared to traditional HLS, LLHLS enables the implementation of near-real-time events and content, allowing for interactive services. Viewers can now participate in various online events in near-real-time, such as live commerce, game streaming, and online conferences.

Why is LLHLS Low-Latency Streaming Needed?​

LLHLS streaming plays a crucial role in various platforms and services that require near-real-time content delivery. By reducing the typical 6–15 seconds latency of traditional streaming to approximately under 3 seconds, LLHLS allows viewers to actively engage with the live-streamed content in near-real-time.

As a result, LLHLS streaming provides immediate interactivity and a more differentiated experience to a large audience. It caters to users familiar with traditional streaming, offering them unique and valuable content in areas like live commerce, sports broadcasting, game streaming, online education, and gambling. Simultaneously, it attracts new viewers with captivating online experiences.

How to Implement LLHLS Low-Latency Streaming?​

To implement low-latency streaming using LLHLS protocol, it is crucial to faithfully adhere to Apple’s HLS specifications. While Legacy HLS could be adequately delivered using a regular HTTP server after segment packaging, LLHLS requires more complex server-side techniques such as Preload Hint, Blocking of Media Downloads, and HLS Delivery Directives for achieving low latency. Therefore, utilizing a dedicated streaming server is highly recommended to ensure successful implementation. If you are interested in detailed information about the LLHLS protocol, please refer to the Apple Developer Documentation.

OvenStudio LLHLS seamlessly integrates with existing infrastructures and systems, using WebRTC, WHIP, RTMP, SRT, and other ingress protocols to receive media sources. It leverages the LLHLS protocol to achieve low-latency transmission. To enhance streaming stability across different browsers, the built-in live transcoder encodes the media sources for low-latency streaming. Moreover, it supports various Output Profiles, allowing you to utilize the Adaptive Bit-Rate (ABR) feature as needed.

Advantages of Using OvenStudio LLHLS:​

1. Interactive Content: OvenStudio LLHLS leverages low-latency streaming technology to support near-real-time updating content. Whether it’s live commerce, sports broadcasting, game streaming, online education, or gambling, viewers can actively participate in near-real-time events with minimized delays.
2. Enhanced User Experience: With OvenStudio LLHLS, you can provide high-quality streaming with reduced latency, offering viewers a remarkable streaming experience.
3. Differentiated Service: By offering lower latency compared to other services, OvenStudio LLHLS can deliver unique value to viewers accustomed to traditional streaming. Providing a differentiated service with lower delay can help you gain a competitive edge.
4. Scalability to Reach More Viewers: LLHLS low-latency streaming enables you to deliver high-quality near-real-time streaming to a large audience. This is particularly beneficial for scenarios like event broadcasting, large-scale online lectures, and horse racing coverage, where a significant number of viewers tune in simultaneously. LLHLS low-latency streaming can handle massive traffic and accommodate many concurrent viewers.

In summary, OvenStudio LLHLS can help you quickly and easily set up a low-latency streaming server, offering your audience the best streaming experience possible.

For more information, please refer to the following links:​

• OvenStudio LLHLS Official Website
• OvenStudio LLHLS on AWS Marketplace
• OvenStudio LLHLS User Guide
• Support and Inquiries

Thank you for taking the time to read this article. If you have any further questions or need more information, feel free to ask.

We are thrilled to announce the launch of OvenStudio LLHLS. This groundbreaking Low Latency HLS (LLHLS) streaming server brings together the power of auto configure-ability, streaming for Low-Latency, Large-Scale, High-Definition quality, and Adaptive Bitrate. This LLHLS server is designed to quick the way you deliver your content to viewers across the globe. From now on, your streaming service can deliver Low-Latency and High-Definition streaming to Large-Scale viewers!

With OvenStudio LLHLS, setting up your streaming infrastructure has never been easier. The auto-configurable feature takes care of the complex installation and configuration process, allowing you to focus on creating exceptional streaming experiences for your audience because it empowers you to effortlessly deploy and scale your streaming services with just a few clicks.

Experience the true potential of large-scale streaming with OvenStudio LLHLS. Built to handle the demands of millions of concurrent viewers, this server can smooth playback and uninterrupted streaming even during peak traffic with Content Delivery Networks (CDN). Certainly, integrating with the CDN (AWS CloudFront) in OvenStudio LLHLS can be easily automated.

Also, it enables the seamless delivery of high-definition videos while leveraging the benefits of low-latency streaming. So viewers can experience smooth streaming without sacrificing video quality.

Adaptive bitrate streaming is another standout feature of OvenStudio LLHLS. This technology automatically adjusts the quality of the stream based on the viewer’s network conditions, providing a seamless and optimized viewing experience across different devices and network environments. Your viewers can enjoy your content without interruptions, regardless of their connection speed or device capabilities.

We understand the importance of low-latency streaming in today’s fast-paced digital world. With OvenStudio LLHLS, you can deliver live content with minimal delay, creating an immersive and interactive experience for your viewers. Whether it’s live sports events, gaming tournaments, or real-time webinars, your audience will feel fully engaged and connected.

OvenStudio LLHLS is the ultimate solution for content creators, media companies, and businesses looking to elevate their streaming capabilities. With its comprehensive feature set and user-friendly interface, you can streamline your streaming workflows, manage your content effortlessly, and gain valuable insights through advanced analytics.

Don’t miss out on the future of streaming. With OvenStudio LLHLS, start your streaming revolution today and captivate your audience like never before.

Thank you!

• OvenStudio LLHLS Website
• OvenStudio LLHLS AWS Marketplace
• OvenStudio LLHLS Getting Started

This article is from Digital 365 (Vol. 20), and we have translated it. If you would like to view the original version, please click HERE (Korean).

IT technology is rapidly transforming the world. In the ever-evolving landscape of the software industry, where global companies transcend national boundaries in endless competition and failure to adapt to technological innovation and market changes leads to obsolescence, there are industry leaders striving to realize a powerful media world by continuously harnessing their potential.

AirenSoft has developed an Open-Source Streaming Server with Sub-Second Latency Large-Scale, and High-Definition to meet the challenges of the dynamic media ecosystem. AirenSoft aims to make complex and demanding media technology more accessible to everyone and has been developed significantly reducing latency in live streaming and enabling stable high-quality broadcasts regardless of viewer growth.

I had the opportunity to meet Jeheon Han, the CEO of AirenSoft, who leads the company with his extensive understanding and experience in streaming, along with his future insights into the field of media technology.

Q. I kindly request an introduction to the company AirenSoft, along with an overview of the Sub-Second Latency (or Ultra-Low Latency) Large-Scale Live Streaming Server and the OvenMediaEngine.

A. The company name AirenSoft derives its meaning from the first five letters of “A-I-R-E-N” representing the Air Engine used in hot air balloons. It signifies a company dedicated to researching and developing software as the core driving force behind media services.

OvenMediaEngine is an Open-Source Streaming Server that significantly reduces the latency time from the Broadcaster (or Steamer) to the Viewer to less than one second, compared to the typical delay of over eight to fifteen seconds. It has been successfully applied in notable cases such as the “2022 FIFA World Cup Mobile Broadcast” by SBS and the mobile live commerce platform “Shoppy Live” by GS Shop. With OvenMediaEngine, viewers can cheer together in real-time during mobile 2022 FIFA World Cup streaming, hearing their neighbors’ cheers simultaneously with the goal scenes. It also enables true bidirectional live broadcasting in live commerce, where hosts can instantly respond to viewers’ chat questions, resolving any product-related inquiries.

Jeheon Han, CEO of AirenSoft, was happy to be interviewed

Q. I’m curious about the background and motivation behind the development of these media solutions. And I would like to know about the biggest challenges the company has faced so far and the key insights or turning points that have helped overcome them.

A. Since its establishment in 2010, AirenSoft has quietly grown in the B2B market, developing various core solutions for media, including Media Players, Media Conversion Systems (Transcoder), and Online Video Platforms (OVP). Among them, the ultra-low latency live streaming solution requires high technical expertise and years of media technology experience. Recognizing the opportunity to gain a competitive edge by fully leveraging its capabilities, AirenSoft embarked on research and development in this field in 2018.

The biggest challenge the company faced was the technical issues that arose during the service development process. However, the developers have overcome these challenges through extensive experimentation and research, resolving problems, and accumulating valuable experience. Building on this experience, AirenSoft is dedicated to continuous efforts in developing even better media solutions in the future.

AirenSoft, leveraging its accumulated technical expertise in the media B2B solutions market, launched a B2C service called OvenCloud in 2015, providing personal video storage space in the cloud. The service underwent over a year of research and development and involved significant infrastructure investments. It gained significant popularity, once achieving the top position in downloads on the Google Play Store, by offering services such as converting old VHS videotapes into digital files and automatically recording gameplay screens in League of Legends (LOL) to store in the cloud. However, the service had to be discontinued due to fierce competition from global IT giants like Google, Amazon, Naver, and Baidu, who offered aggressive promotions with free storage space of up to 1TB. This experience became a crucial turning point in identifying our strengths, weaknesses, opportunities, and threats, leading us to refocus on B2B solutions based on our technical capabilities.

Q. Howard Love, an American entrepreneur, has represented the growth model of startups using the J-curve, which consists of six stages — Create, Release, Morph, Model, Scale, and Harvest. AirenSoft, founded in 2010, is currently in which stage?

A. The OvenMediaEngine is currently in the early stage of Model-Optimization. Our partners, while the primary needs for adopting OvenMediaEngine may be similar across different domains, the specific architecture, features, and performance requirements vary. It’s applied to various domains such as Cloud-based CCTV, Content Delivery Networks (CDN), Live Commerce, Sports Broadcasting, Online Gambling, and Live Black-box, and it has been continuously innovated and upgraded to offer a wide range of functionalities and options. The business model has also evolved from simple package sales to include technical support and partnership models, reflecting a shift in business strategy.

Jeheon Han has explained more about OvenMediaEngine

Q. I’d love to hear about your strategy and business plan for sustainable growth, and how you’ve overcome the death valleys that startups often face.

A. B2B media solutions like OvenMediaEngine often require fine-tuning and dedicated support to optimize their performance for each specific website or platform they are required to and applied to, so offering a single service alone would limit the potential for growth. To overcome this, we have made significant investments to ensure flexibility in adapting to various environments. We have established partnerships with both domestic and international platform companies, enabling us to effectively collaborate and expand our business. Additionally, to address growth limitations, we have automated and packaged our solutions based on the most common use cases, making them readily available on cloud platforms. This strategy allows us to overcome growth constraints and provide scalable and adaptable solutions to our clients.

Since its inception, AirenSoft has released various media solution products. However, OvenMediaEngine is the product that the company has focused all its capabilities on. AirenSoft did not initially adopt the typical high-risk, high-return strategy commonly associated with startups. Instead, the company chose to develop half of its resources into desired media solution products while undertaking media technology-related service projects for survival. Through accumulated experience in the media technology industry, AirenSoft identified an item with the potential for sustained growth and, after eight years, successfully developed a sub-second latency streaming solution that is not easily replicable. As a result, we have not experienced the valley of death typically associated with startups. However, it did take a considerable amount of time for us to reduce the proportion of service projects for the sake of the company’s survival.

Q. When I visit AirenSoft’s website, I will notice that it is primarily focused on the title OvenMediaEngine, with the company introduction divided into three stages — Original Technology, Development, and Business. Could you provide an explanation regarding the content featured on the website?

A. In fact, the field of streaming servers is a highly specialized area that can be challenging for even engineers to understand in detail, let alone the general public. Since our primary customers are developers and engineers in the media industry, it may be difficult for the average person to comprehend the website content easily.

The concept of OvenMediaEngine and its detailed specifications, performance, and features are explained under the category of Original Technology. Through consultations with our clients, we also engage in the task of integrating OvenMediaEngine into their existing systems, which falls under the category of Development. Additionally, our business activities involve establishing partnerships with platform companies and technology/business collaborations, which are covered under the category of Business.

Q. What is the meaning of the company logo and the significance of the orange logo color?

A. As for our company logo, it is a representation of the Air Engine used in hot air balloons and its fire. It symbolizes the Air Engine, while the color orange represents both the color of the engine and passion. Please note that the above explanation provides a general understanding and may not cover all the specific details of AirenSoft’s website and logo.

Q. Even if you have a great business idea and excellent technology, it can be challenging to survive if there is no market response. What differentiating public relations methods and marketing strategies does AirenSoft use both domestically and internationally?

A. Streaming servers are the core software of media services because any failure in the streaming server implies a failure in the entire media service. Therefore, companies strive to adopt highly reliable streaming servers, and to ensure this reliability, they require diverse references and a good reputation. From the beginning, AirenSoft has been focused on open-sourcing the OvenMediaEngine, running a global community, and building its technology and credibility.

Many media services worldwide have adopted and are using the OvenMediaEngine. From the perspective of user companies, open-source offers the advantage of being free and having access to the source code, allowing them to handle the worst-case scenarios independently. However, AirenSoft offers paid technical support to ensure the stability of its services, including long-term support (LTS) packages, rapid bug fix deployment, guaranteed updates for the subscription period, and the provision of RPM or Docker images. And we generate revenue by offering commercial software derived from the OvenMediaEngine.

NAB Show 2023

The open-source software and the open-source community, we already have, is the most powerful and differentiating marketing strategy to build trust and showcase our skills. Beyond that, we also regularly attend international exhibitions like NAB and IBC to meet contributors in our community and hear their feedback, all of which are outreach efforts to move us forward.

As part of its marketing and promotion efforts, AirenSoft has been consistently participating in competitions like the Korea Software Awards since last year.

Q. In 2023, there are anticipated to be significant changes in the domestic and international IT industry due to an unprecedented global economic slowdown. What are the trends of competitors in developing streaming services such as OvenMediaEngine in the global market, what are AirenSoft’s comparative advantages and global competitiveness compared to other companies at home and abroad, and what are the strategies for overseas expansion, threats to opportunities, and things to watch out for?

A. Live streaming services are not only essential for platforms like YouTube and Twitch for live broadcasting or Zoom and Google Meet for online meetings but also have a wide range of applications in various fields. For example, recently, there has been a significant rise in the demand for services that stream and monitor the live footage from commercial vehicles’ black boxes, which has legal and insurance implications. We are currently in discussions with top companies in Southeast Asia and Europe regarding related solutions.

The pandemic has brought about significant changes in our lifestyles. Video conferencing and Remote work are no longer unfamiliar experiences. Overseas online zoo startups are collaborating with us to reduce the latency in their live broadcasts.

Jeheon Han has spoken about the vision and goals of AirenSoft

In the global market, the size of the ultra-low latency live streaming server market is relatively small, with only a few products available. While there have been numerous server solutions targeting small-scale groups for online conferences, the number of products being developed specifically for large-scale and high-definition broadcasting is extremely limited, with less than five options available. In Asia, OvenMediaEngine by AirenSoft stands as one of the few choices, making it nearly unique in the region.

The global economic downturn is expected to reduce the overall market size by dampening investments. However, in the live-streaming industry, competition is already limited due to the scarcity of competing companies. Additionally, AirenSoft, being a small and flexible organization, as well as a specialized development company, is relatively less affected by economic downturns.

The biggest threats to streaming servers are service outages, low reputation regarding stability issues, and compatibility with existing systems. However, OvenMediaEngine, being based on open-source technology, benefits from a global open-source community where users worldwide test it in various environments. This enables rapid improvements in stability and performance, resulting in high reliability. Additionally, open-source solutions have a low entry barrier as they can be adopted during the proof-of-concept stage for media services. Once implemented, commercial media services require technical support and maintenance, which can be incorporated into a viable business model.

Q. Congratulations! OvenMediaEngine won the Grand Prize in the Multimedia S/W category and the Prime Minister’s Award at the 2022 Korea Software Award, hosted by the Ministry of Science and ICT (MSIT) and The Federation of Korean Information Industries (FKII). What is the significance of the award and how does it make you feel, what are the challenges ahead, and do you have any ideas or advice for media technology startups?

A. Winning the Prime Minister’s Award has provided us with the confidence that our direction is on the right track and has boosted our reputation in the business area. While we have received positive feedback from engineers in the open-source community and international exhibitions regarding the technical aspects, receiving significant attention and response from the judges allowed us to showcase our product with even greater confidence, leading to several significant contracts. Going forward, we plan to actively sell paid products and services based on the foundation of the open-source community.

Korea Software Awards 2022

As a result of this award, we would like to share industry-specific knowledge with professionals in the same field, both domestically and internationally, and exchange valuable ideas. If needed, we are willing to share and consult on the media technology we possess. We will respond sincerely to any interested companies who reach out to us.

Thank you.

AirenSoft will exhibit at the 2023 NAB Show. This show, taking place at the Las Vegas Convention Center from April 15–19, is an unrivaled exhibition for broadcast, media, and technology.

Our booth is located at W4048 in West Hall. If you are thinking of coming to the show, please stop by W4048.

Also, we are preparing to show you OvenMediaEngine, a sub-second latency streaming solution using LLHLS and WebRTC, and give you a chance to experience the OvenMediaEngine Enterprise Demo.

Finally, if you need to get your Exhibit Pass, register using our FREE code (LV85499) when registering.

Thank you!

Seoul Broadcasting System (SBS), one of the leading South Korean television and radio broadcasters, introduces OvenMediaEngine to provide Low-Latency Qatar WorldCup 2022 Live!

SBS provided a service with a latency of about 15 seconds by using HLS as a streaming protocol. Still, applying OvenMediaEngine’s LLHLS reduced latency by more than 10 seconds, enabling real-time access to World Cup matches with minimal delay.

It is the first time in Korea to broadcast the World Cup through low-latency live streaming, and it will be one of the few cases worldwide.

During the World Cup, experience low-latency streaming using the SBS web and app. If you press Live provided in the SBS web/app and turn on the low-latency switch on the bottom right, it automatically applies to low-latency streaming mode.

Thank you!

OvenMediaEngine, Open-Source Sub-Second Latency Streaming Server using LLHLS and WebRTC, gets Good Software Level 1 certified by the Telecommunications Technology Association (TTA).

The Good Software (GS) Certification began in 2001 in order to improve the quality of software products and promote the spread of high-quality products.​

To certify that it is good quality software, TTA performs systematic testing and evaluates it based on international standards, ISO/IEC 25023, 25051, and 25041.

So, OvenMediaEngine has passed all functional compatibility, performance efficiency, usability, reliability, and security based on international standards. As a result, it has been certified as the highest-quality software.

Thank you!