Ad Insertion

[fluffy]

How does insertion of advertisements work and do we need any changes in MoQT to support that ?

[fluffy]

@wilaw thoughts ?

[ianswett]

We're at the point this is an important topic to discuss, but I'm not an expert on it. It's possible we don't need to do anything special for MoQ transport to enable this, but I'm not sure.

[kixelated]

I don't have a good answer for this.

HLS makes it "easy" to perform ad insertion because there's a decoupling of the manifest and edge server. You can run a custom manifest server that, on a per segment basis, instructs viewers the URL of the next segment. This doesn't require any cooperation with the CDN that actually serves the segments.

However due to the subscription-based nature of MoQ... it's more complicated. The only idea I have is to create a new track at possible ad insertion points and force the viewer to resubscribe, consulting the ad server for the name of the new track. It's kind of gross but it could work.

[wilaw]

I have though about this a bunch because support for advertising is crucial for the commercial viability of MOQT-based streaming formats. I had a side meeting with Yospace CTO David Springall a few months back to talk through some conceptual ideas. He provided this diagram of how MOQ might integrate into a low latency ad insertion workflow:

The OTT ad industry is moving towards server-guided ad insertion, a mode of insertion which the client performs the insert but using instructions provided by a server.

There are some key points in all of this:

1. We need the concept of a playback session. Luckily, we have a good proxy for this with our Wt or QUIC session establishment. We assign this session a random ID and it registers itself, either via HTTP or MOQT (I am in favor of the latter) with an ad backend. This backend will understand the previously registered broadcast and then be able allocate ad placement opportunties to each individual session.
2. Interstitial ads are VOD content, even when placed into live streams. This means we can FETCH them.
3. MOQT encoders will need to be SCTE compliant, as those markers are the dominant placement signaling mechanism in use today. In my draft design of a timeline track, I showed how an off-the-shelf SCTE-35 marker could be embedded.
4. It is important that we are compliant with existing ad inventory. This is almost universally stored as ISOBMFF or TS files. It would be possible to create a proxy gateway to these ad systems which vend MOQT track variants of these assets, including trans-packaging to LOC or other container formats.
5. We can use catalogs to instruct clients on when to insert ads. In order to provide user-personalized advertising, we need to be able to generate unique catalogs for each user. This must be done at the edge. To enable this, we should introduce the concept of an application layer at the outermost relay server. This app layer will provide functionality similar to the serverless edge compute offered with HTTP today. It will be able to subscribe to a base catalog and then modify it for each connection. It should also be able to modify Objects themselves. We can use this for many customization features (per-session watermarking, codec/format restrictions based on device type, content offering suggestions etc).

MOQT offers some benefits for advertising that we don't have in the HTTP workflow:

1. Having millions of client report ad playback quartiles during synchronized ad placements means that the ad reporting services need to be highly scalable. Today this is done with separate data collection networks. The directional nature of MOQT connections means that client-side ad reporting can be made though the same distribution network which is serving the media. This affords much richer, reliable and easily scalable reporting.
2. The parallel nature of MOQT means that more flexible ad displays can be implemented. Overlays are possible MOQT can also carry image assets for advertising, it does not need to be A/V.

Yospace have signaled interest in participating in some early proofs-of-concept to start exploring these ideas.

[kota-yata]

What about SSAI? MoQT principle of not modifying stream content on the path and SSAI doesn't seem to fit together. I'm thinking something like this for SSAI-like insertion, but I don't feel like this is efficient or viable for personalization

[wilaw]

@kota-yata - what I had in mind is explained in the diagram below. The original publisher would publish a catalog (or equivalent list of tracks). This would include the audio and video content as well as a timeline track. The timeline track describes the history of the audio and video from that publisher and its common for all subscribers, so I don't want to put any ad related data in it. For that, we add a new track which I'm calling an 'Ad insertion track". It will be filled with a list of instructions of which ads to insert and when. This ad insertion track is not coming from the original media publisher (green), but from another original publisher I'm calling the "MOQ compliant ad decisioning system" (blue). When the client subscribes to this ad track, it appends its userID to the subscription. This allows the ad decisioning system to customize an ad pod for that user. The track returns a set of insertion instructions of which ads to insert and when. This ad content is provided by a third original publisher I'm terming the "advertising content origin" (purple).

This architecture allows the same catalog to be consumed by all end-users (good for scale) while allowing the ad insertion instructions to be customized for each end user based on their identifier which makes it compatible with current interstitial solutions (good for interop and to leverage existing ad inventory and decisioning systems).

Let me know if you have opinions.

[kota-yata]

Thanks.
To support ad insertion at dynamic timings like the end of an inning in a baseball game, the decisioning system needs a mechanism where the ad insertion track delivers the ad content in advance, while the exact timing for insertion (i.e., timeline placement) is notified later. This way the content could be preloaded and ready, and the actual insertion point can be determined in real time based on the state of the live event or stream.

[kota-yata]

I'm thinking of the situation where the ad decisioning system is in the production studio, and there is an operator that clicks "Insert Ad" button to dynamically insert ad for certain period of time.

[gwendalsimon]

@wilaw your solution requires the client to explicitly subscribe to the ad tracks. It is not SSAI, is it?

@kota-yata in my understanding, SSAI should be implemented by an "intermediary" (see #1107), i.e. an entity that is both a Publisher and a Subscriber, but is not a Relay.

What I have in mind is something as follow (which mixes both your approaches): When it is time for ads, the Original Publisher adds a marker in the "timeline" track. The Intermediary has subscribed to the "regular video" track and the "timeline" track. When it detects the marker in the timeline track, the Intermediary subscribes to the "MoQ compliant ad decisioning system" with the Subscriber track Id=1234. It gets the "Ad timeline" track. Then it subscribes to the Ad track #1 and subsequently Ad track #2. And finally, the intermediary publishes the Objects of both Ad tracks into the "regular video" track toward the end-subscriber.

[wilaw]

@wilaw your solution requires the client to explicitly subscribe to the ad tracks. It is not SSAI, is it?

Indeed. It's Server Guided Ad Insertion (SGAI) which is where the OTT ad industry is moving with both Interstitials in HLS and AlternativeMPD in DASH. This has shown to be flexible and scalable. I think MOQ should both inherit this evolution (i.e not spend time with CSAI and SSAI) and be interoperable with existing SGAI ad systems and inventory.

[riedlse]

SO I still think SSAI still makes a lot of sense over SGAI at least in Paramount sense and the way our stitcher works and scales. I was c hatting with ChatGPT about having individual timelines and it was quite optimistic. I'm happy to have any of the esteemed folks on this chat tell me where it started hallucinating as I am told it can do time to time...

MoQ is not only useful when “everyone watches the same moment.” It was designed to support both live fan-out and individualized timelines, including pause, rewind, and “off-timeline” playback, without dropping out of MoQ.
Here’s the sharper breakdown:

1. Independent timelines (pause/rewind/DVR) are built into MoQ
   MoQ’s core transport lets a subscriber FETCH arbitrary ranges of past media (“Standalone Fetch”), and—crucially—“Joining Fetch” lets a client backfill from the past and then flow straight back into the live subscription contiguously and without overlap. That’s exactly what you need for pause/DVR time-shift. (IETF Datatracker)
   Clients also choose Group Order (ascending or descending) per subscription/fetch, which is handy for “catch up” behavior (e.g., newest-first to close a gap). (IETF Datatracker)
   Net: With a live SUBSCRIBE + periodic JOINING FETCH (relative or absolute), you can implement pause, replay 30s, or join-midstream catch-up entirely over MoQ. No HLS/DASH manifest gymnastics required. (IETF Datatracker)
2. Personalized ads do not require leaving MoQ
   MoQ is publish/subscribe by track name/namespace; a server “stitcher” can publish a per-viewer track (or a shared program track + personalized ad objects) and the client just stays subscribed. The protocol makes no assumption that all viewers get identical bytes; that’s an application choice. (IETF Datatracker)
   If you want server-side SSAI that’s indistinguishable to the client (your goal), you simply interleave ad objects at Group boundaries on the same track. The client never switches protocols or tracks. (Operational note: like per-user HLS SSAI, personalization reduces cache dedupe; that’s an economics/architecture trade-off, not a MoQ limitation.) (IETF Datatracker)
3. Where HLS/DASH are still strong (and why you may pick them)
   The HLS/DASH ecosystem is mature for pure VoD, very long DVR windows, offline/downloads, and deep CDN cache leverage; tooling and players are everywhere. If you don’t need sub-second or interactive latency, they’re a safe, boring choice. (nanocosmos, Streaming Media Magazine)
   But for low-latency live with time-shift and individualized experiences, MoQ gives you a single transport with built-in catch-up (Joining Fetch) and per-subscription scheduling/priority—no manifest surgery. (IETF Datatracker)
4. Practical MoQ patterns for “independent viewing” you asked about
   Pause/DVR: Keep a live SUBSCRIBE to video/main + audio/main. When the user seeks back 30s, issue Relative Joining Fetch for N groups behind the live edge; when done, let playback run back to the subscription’s live edge seamlessly (the draft defines this contiguity explicitly). (IETF Datatracker)
   Late join catch-up: Start a SUBSCRIBE in Descending group order for the last few groups to fill the buffer quickly, then switch to normal playback order. (IETF Datatracker)
   SSAI on one track: Stitch ads at Group (GOP) boundaries in the same track; no client switch, no protocol switch. (If you also mirror ad cues via a tiny “events” track using DATAGRAMs, beacons fire on time but the media still stays on one MoQ track.) (IETF Datatracker)

Bottom line
MoQ ≠ “broadcast-only.” It supports individualized timelines (pause/rewind) with FETCH + Joining Fetch, per-subscription ordering, and deadlines/priorities. (IETF Datatracker)
You don’t need to “go off MoQ” for personalized ads. Your stitcher can publish a per-viewer stitched track; the client stays on the same MoQ subscription. The trade-offs are about caching/ops, not protocol capability. (IETF Datatracker)

[afrind]

It went a little off the rails in step 2:

The protocol makes no assumption that all viewers get identical bytes; that’s an application choice

A given Track MUST have identical bytes for all subscribers. So this idea:

a shared program track + personalized ad objects

only works if the shared program track contains insertion points and perhaps a common Location in all personalized ad Tracks (play ad 1 now). Each subscriber could subscribe to two tracks, the common track and the personalized ad track which would have different ads.

[WendyLi0926]

Hi @wilaw , I saw a lot of diagrams in this issue, thus I'd like to confirm some MOQT naming model concepts here (which might be not that relevant though). Let me know if there's any relevant issues which are more proper to comment. Thank you very much!
Below is my understanding about the concepts of Track Namespace, Track, Group and Subgroup. I'd like to know whether my understanding is correct or not.
Some briefs are:

• Track Namespace is a live event/channel
• Track is video/audio in different languages/subtitle
• Group is the timeline division of each track
• Subgroup is used to gain some concurrency within a group while eliminating HOL problem.
• If it's about ABR algorithms, it should be the switch among Subgroups.
  Do I understand these concepts correctly and thank you!