How MOQ Meets the Technical Demands of In-Play Betting

In Part 1, we looked at why MOQ is about more than ultra-low latency. We explored live sports betting as an important use case for synchronized media and metadata, and looked at the broader implications of MOQ for primary distribution.

But what does an in-play betting service actually need from the underlying streaming technology? And how can MOQ address those requirements?

The requirements for betting

In-play betting requires the betting operator to close a market once the outcome of an event is known. The operator then has to decide which bets arrived before any bettor could have learned the outcome.

Two timestamps settle the question. The first, T, marks the moment the event happens. The second, W, marks the earliest moment when any person can learn the outcome and pass it to a bettor.

The bet rejection limit impacts the size of the betting business. In theory, the operator should accept every bet that arrives before W. However, in practice, rejecting all bets after T is the safe choice, since it needs no measurement and leaves no room for cheating. Unfortunately, the safe choice also throws away every bet placed between T and W. Therefore, the operator would want to optimize W to minimize the number of rejected bets from fair bettors.

There are two potential configurations, depending on the relationship between T and W:

A live public event

A live public event lets the operator set W equal to T. Any spectator in the venue sees the event with no delay, so the two moments are close enough to treat as one. The rejected interval is easy to determine. A bettor can fairly place bets until the video shows the event at a time L, which is equal to T plus the glass-to-glass streaming latency. Yet, the operator rejects every bet placed between T and L.

This is why betting operators chase ultra-low latency: the lower the latency, the smaller the window for last-second rejected bets.

An unwitnessed event

An unwitnessed event disconnects W from T. For example, a recorded race, a match behind closed doors, or a remote esports final hides the outcome from every observer until the video delivers it.

W is then defined by another mechanism: the moment when the first viewer sees the event on screen. It is possible to implement in-play betting on a recorded event, but it requires more precision.

The first viewer - the first person to see the event in the streamed video - sets W, because this earliest bettor is the first witness of the event and could pass that information on to viewers who receive the stream later.

Consequently, the operator is interested in keeping the gap between all viewers as small as possible to reduce the number of rejected bets.

Enter MOQ

MOQ provides the properties required by both configurations. A betting service needs sub-second latency, a bounded gap between viewers, media time carried inside the media itself, and a record of what each session received.

Latency and synchronization carry the most weight, since both the witnessed and the unwitnessed configurations depend on them:

• Latency between 250 milliseconds and one second. With MOQ, the operator picks a point within the range depending on the picture quality the service guarantees. A cloud deployment stays below one second. A hardware encoder combined with a dedicated pipeline can achieve 500 milliseconds end-to-end while maintaining high quality. Dropping to 250 milliseconds requires the operator to relax the quality guarantee.
• Synchronized playback across the audience. Every viewer references the same object numbering, which turns the gap between two viewers into a measured quantity. A published paper and a public demonstration have shown the mechanism maintaining skew near 100 milliseconds. Closing the gap depends on the group duration, the buffer policy, and the client control loop.

MOQ then carries the timing information the operator needs to place a bet on the media timeline:

• Media and event timelines. The media timeline binds media presentation time, object position, and encoder wall clock. The event timeline carries metadata records. Each record is attached either to a wall-clock instant or to a media presentation time. The operator therefore places an event on the same timeline that the bettor watches.
• A timestamp in every object. MOQ carries the presentation timestamp as an object property. A relay reads the timestamp without opening the media container. Media time therefore travels inside the media itself.
• Delivery records at the relay. The relay records which objects it forwards to which session, and when it forwarded them. The operator can then establish what each bettor received, without relying on information reported by the client.

The requirements of large-scale streaming

A betting service also depends on three properties that any large-scale, high-quality streaming service requires. The MOQ working group is actively working on these:

• Relay caching. Relays forward objects and cache groups, which gives MOQ the distribution economics of a CDN.
• An adaptive bitrate mechanism. A client switches quality at group boundaries. A bettor on a weak connection therefore maintains a usable picture.
• Hardware content protection. CMAF packaging applies Common Encryption, so decryption runs inside the Content Decryption Module. The service can then carry premium sports rights under the same conditions as a broadcast platform.

The bigger picture

For in-play betting, MOQ brings together the low latency, synchronized playback, media and event timelines, timestamps and delivery records needed to manage the timing of bets. Its support for relay caching, adaptive bitrate and content protection also addresses the requirements of delivering high-quality media at scale.