DEV Community: Kun Wu

Sever-Guided Ad Insertion Made Easy.

Kun Wu — Tue, 05 Nov 2024 14:31:04 +0000

In today’s streaming landscape, delivering personalized, seamless ad experiences is key, and Server-Guided Ad Insertion (SGAI) is leading the charge. Unlike traditional Client-Side Ad Insertion (CSAI), where the user’s device manages ads, SGAI centralizes control at the server level. It decides the timing, format, and content of ads based on user data, ensuring ad relevance without relying on the client’s system. By connecting to ad decision servers (ADS), SGAI generates tailored ad breaks in real-time, keeping viewers engaged with ads that suit their preferences and demographics.

How SGAI Works

Servers can schedule interstitials by placing EXT-X-DATERANGE tags in Media Playlists, allowing flexibility in ad placements. These interstitials, which must be VOD assets, can be inserted at any point in a primary asset, whether VOD or live, including Low-Latency HLS streams.

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:11
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:27.853+0100
#EXTINF:4,
fileSequence11.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:31.853+0100
#EXTINF:4,
fileSequence12.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:35.853+0100
#EXTINF:4,
fileSequence13.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:39.853+0100
#EXTINF:4,
fileSequence14.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:43.853+0100
#EXTINF:4,
fileSequence15.ts
#EXT-X-DATERANGE:ID="ad_slot0",CLASS="com.apple.has.interstitial",START-DATE="2024-10-30T12:52:47.207+01:00",DURATION=10,X-ASSET-LIST="http://localhost:3333/interstitials.m3u8?_HLS_interstitial_id=ad_slot0",X-RESTRICT="SKIP,JUMP",X-RESUME-OFFSET=10,X-SNAP="IN,OUT"
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:47.853+0100
#EXTINF:4,
fileSequence16.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:51.853+0100
#EXTINF:4,
fileSequence17.ts
#EXT-X-PROGRAM-DATE-TIME:2024-10-30T12:52:55.853+0100
#EXTINF:4,
fileSequence18.ts

In this playlist, an EXT-X-DATERANGE tag schedules a 10-second ad break to play at the specified time point. The player loads the resource specified by the URL after buffering the primary asset to the scheduled interstitial playback time, and then resumes playback of the primary asset at the live edge. Seeking and scanning forward will be disabled during interstitial playback. It is also possible to include custom attributes to be processed by the client.

{
   "ASSETS":[
      {
         "URI": "http://localhost:3333/interstitials.m3u8?_HLS_interstitial_id=ad_slot0&_HLS_primary_id=40FE1829-438E-49B0-8B3A-A285DD4A8154&_HLS_start_offset=0&_HLS_follow_id=361434bf-05e7-4e17-83ca-690452e1cb33",
         "DURATION":5
      },
      {
         "URI": "http://localhost:3333/interstitials.m3u8?_HLS_interstitial_id=ad_slot0&_HLS_primary_id=40FE1829-438E-49B0-8B3A-A285DD4A8154&_HLS_start_offset=5&_HLS_follow_id=eb805a34-1d61-4217-9632-deab8790c30d",
         "DURATION":5
      }
   ]
}

In this example, the returned JSON object from the X-ASSET-LIST URL includes two 5-second ads. Their URI includes query parameters to identify ad slots, individual ads, and user sessions, making late binding to ad inventory possible and ad personalization easier.

Compared to SSAI and CSAI

SGAI vs. SSAI: Both SGAI and SSAI stitch ads server-side, but SGAI offers finer control over targeting and adapts dynamically to real-time user data. While SSAI lacks some targeting precision, SGAI’s server-level adjustments allow for improved ad personalization.
SGAI vs. CSAI: CSAI places ads on the client side, allowing for tracking data but also making ads prone to blockers and playback glitches. SGAI, on the other hand, provides a seamless experience and improved protection from ad blockers, enhancing both viewer engagement and revenue.

Our SGAI Proxy Tool

As a Proof of Concept, Eyevinn's SGAI Ad Proxy serves as a practical tool that facilitates the integration of ads into HLS content. This lightweight HTTP proxy server intercepts the video stream and inserts ads at defined time points.

Steps to Use the Ad Proxy Tool

Set Up the Environment:
- Create an HLS Stream: Use ffmpeg to set up a basic HLS streaming server.
- Ad Server: Ensure access to a compatible ad server serving VAST-compliant ads.
Choose Ad Insertion Mode:
- Select either static mode (fixed intervals) or dynamic mode (on-demand insertion).
Run the Proxy Server.
To Insert Ads Dynamically:
- Send a GET request to the proxy.
Access the new Stream:
- Use a compatible video player (e.g., AVPlayer) with the proxy URL.

As the streaming landscape evolves, tools like the SGAI Ad Proxy are pivotal in enhancing the viewer experience and driving ad revenue. For more information and setup details, visit the tool’s GitHub repository.

Stream from OBS to Twitch and Preview With SRT-WHEP

Kun Wu — Mon, 28 Aug 2023 10:30:37 +0000

This guide will take you through the step-by-step process of setting up OBS (Open Broadcaster Software) to stream to Twitch and preview the output in browser using our SRT-WHEP tool and Web Player.

Prerequisites

Installed OBS: Download and install OBS from the official website: OBS Project.

Steps

1.Twitch Account Setup:

If you don't have a Twitch account, create one by visiting: Twitch Signup.
Log in to your Twitch account.

2.Install and Run SRT-WHEP:

You need to run the SRT-WHEP application on your computer. You can either build it from source or use the Docker image (for Ubuntu). Detailed building instructions can be found in the GitHub repository.
To run it in listener mode and wait on port 1234, execute the following commands:
- If building from source: srt-whep -i 127.0.0.1:1234 -o 127.0.0.1:8888 -p 8000 -s listener | bunyan
- If using Docker image: docker run --rm --network host eyevinntechnology/srt-whep -i 127.0.0.1:1234 -o 127.0.0.1:8888 -p 8000 -s listener
This will forward the SRT stream to port 8888.

3.Create Input Stream with OBS:

Launch OBS on your computer.
In OBS, go to the "Sources" tab and add a new source (e.g., macOS Screen Capture).
To connect to SRT-WHEP, navigate to the "Settings" menu in OBS and select the "Stream" tab.
Choose "Custom" as your streaming service.
In the "Server" field, enter the input SRT URL: srt://127.0.0.1:1234?mode=caller
Start streaming by clicking the "Start Streaming" button. OBS will begin sending the stream to SRT-WHEP as the caller.
You'll see in the SRT-WHEP console that the stream is received and ready for playback.

4.Stream to Twitch using SRT-RTMP Tool:

Twitch accepts RTMP streams directly but not SRT stream.
We have a tool that accepts SRT stream and outputs as RTMP stream.
Once it's installed, set your Stream Key as environmental variable STREAM_KEY and then run the srt-rtmp application:

export STREAM_KEY=$YOUR_STREAM_KEY

srt-rtmp -i 127.0.0.1:1234 -s listener -o live.twitch.tv/app | bunyan

Here the Stream KEY is the Stream Key from your Twitch account. Find it under Creator Dashboard -> Settings -> Stream -> Primary Stream Key.

5.Preview the Stream in Browser:

To preview the stream, open the WHEP Player in your web browser.
Enter the URL: http://localhost:8000/channel.
Click "Play," and within a few seconds, you should see the OBS stream in your browser.

6.Viewing the Stream on Twitch:

Navigate to your Twitch account dashboard to view your live stream.

7.Ending the Stream:

To stop previewing the stream, click the "Stop" button in the WHEP Web Player.
When you're ready to end your stream, return to OBS and click the "Stop Streaming" button.

Conclusion

Congratulations! You've successfully configured OBS to stream to Twitch and previewed the output using your web browser. Enjoy your seamless streaming experience!

Seamlessly Streaming SRT Content in Web Browsers

Kun Wu — Fri, 25 Aug 2023 11:25:01 +0000

In the ever-evolving realm of content delivery, the convergence of SRT (Secure Reliable Transport) streaming and WebRTC (Web Real-Time Communication) marks a significant milestone. This fusion addresses the complex challenge of delivering content seamlessly across diverse devices and platforms, opening up new avenues for real-time interactions. Our exploration into bridging the gap between SRT streaming and browser playback is a testament to our commitment to solving these challenges.

Background: The Nexus of SRT and WebRTC

RT streaming redefines how video, audio, and data are transmitted across unpredictable networks. Operating on a single UDP socket, SRT seamlessly integrates reliability, ordering, and congestion control, crucial for real-time applications like video conferencing. Its automatic repeat request (ARQ) mechanism ensures content delivery integrity, particularly essential for maintaining seamless real-time interactions.

In contrast, the conventional HLS (HTTP Live Streaming) protocol relies on TCP, which can introduce latency complexities and hinder real-time interactions. However, HLS excels in device compatibility, making it accessible on a wide range of devices without the need for specialized tools. Recognizing the strengths of SRT in terms of reliability and efficiency, coupled with HLS's device compatibility edge, our exploration led us to the world of WebRTC.

Our Endeavor: Forging with Tools and Architecture

Our mission to seamlessly integrate SRT streaming into web browsers relied on a foundation of carefully selected tools and architecture. GStreamer, a versatile open-source multimedia framework, served as the core of our project, enabling efficient processing and streaming of audio and video content. The modularity of GStreamer allowed us to seamlessly integrate various components, optimizing SRT streaming within web browsers.

In terms of coding, we chose the Rust programming language. Renowned for its exceptional performance, memory safety, and cloud deployment suitability, Rust's unique attributes were pivotal in ensuring a robust and efficient solution. Rust's focus on preventing memory-related errors and its concurrency model were instrumental for real-time streaming and interactivity. Furthermore, its inherent cross-platform compatibility aligned seamlessly with our mission. The strategic combination of Rust and GStreamer produced a codebase capable of navigating various operating systems.

Architecture of Seamless Playback

Our application's architecture followed a streamlined workflow familiar in video and audio processing. An input stream, such as an SRT stream, underwent demuxing to reveal metadata and streams. Compressed stream data was decoded, and optional filters were applied to raw frames, such as resizing for optimization. Notably, video streams from MPEG-TS were transmitted directly to WebRTC peers without decoding, leveraging WebRTC's inherent support for H.264 (AVC) video codec. However, audio transcoding from AAC to OPUS was necessary to achieve compatibility with browser peers. This approach caters to use cases like confidence monitoring or content preview, where maintaining unaltered visual fidelity is essential.

Getting Started

For those interested in exploring our solution, two options are available: building from source code or using our Docker images (compatible with Ubuntu systems only). Here, we demonstrate the Docker option.

Generate an SRT test source, for example, using our testsrc Docker container:

docker run --rm -p 1234:1234/udp eyevinntechnology/testsrc

An SRT stream (in listener mode) is then available at srt://127.0.0.1:1234. Then run the srt-whep application:

docker run --rm --network host eyevinntechnology/srt-whep -i 127.0.0.1:1234 -o 127.0.0.1:8888 -p 8000 -s caller

It will connect to the SRT test stream in caller mode as the generated SRT stream is in listener mode.

WHEP endpoint is available at http://localhost:8000/channel. You can then play it for example using our WebRTC Player.

Challenges: Overcoming Hurdles

Our journey to integrate SRT streaming with browser playback encountered several challenges.

Complexity in Tool Compatibility: The intricacies of tool compatibility emerged as we engaged with tools like FFmpeg/FFplay and GStreamer. Despite the apparent simplicity of creating and playing an SRT stream, intricacies arose due to diverse toolsets across platforms. An SRT stream generated using FFmpeg, for instance, might not seamlessly harmonize with GStreamer without precise configuration. Even seemingly minor details, like a missing bitrate parameter, could disrupt streaming unexpectedly.

Browser Support for WebRTC Codecs: Navigating the nuances of browser support for WebRTC codecs presented another challenge. Widely-used video codecs like H.264 and H.265 thrived within tools like ffmpeg. However, aligning these codecs harmoniously with browser prerequisites was a complex endeavor. While the WebRTC standard embraced both H.264 and H.265 video streams, browser compatibility revolved around video profiles. Chrome exhibited versatility, supporting all profiles – baseline, main, and high – catering to diverse developer needs. On the contrary, Safari displayed exclusivity, embracing only the Baseline profile. This diversity necessitated strategic decisions, carefully balancing codec capabilities, WebRTC's potential, and browser preferences for a seamless union of streaming and browsing experiences.

Cross-Platform Compatibility. The pursuit of cross-platform compatibility emerged as a formidable challenge, encompassing devices, operating systems, and browser ecosystems. Seamlessly delivering content across this spectrum required a comprehensive understanding of browser intricacies and interactions with underlying operating systems. Variances in audio and video handling, network conditions, and user behaviors contributed to a complex tapestry.

Realizing cross-platform compatibility demanded a harmonious fusion of technologies – from SRT streaming and WebRTC to GStreamer and Rust. Each component needed to align cohesively to ensure a uniform experience for users, irrespective of their chosen platform.

Summary: The Odyssey of Integration

Our journey to seamlessly integrate SRT streaming with web browsers was rooted in a commitment to effective solutions and adaptability in the face of evolving technology. The convergence of WebRTC for seamless playback, browser-approved codecs, and cross-platform tools encapsulated our approach. This harmonization ensured that processes, testing, and accessibility converged harmoniously, underscoring our dedication to an interactive and universally accessible streaming solution.