2.6-202512 Public Comment Feedback

[hillslatt]

Please comment on this issue with feedback on updates to the OpenRTB updates pertaining to Live Event Signaling in Public Comment

• Addition of value 2 representing Video on Demand conent to the livestream attribute in Object: Content
• Addition of recorded attribute to Object: Content
• Implementation Guidance on use of new attributes to better describe Live programs
• Addition of Table of Contents to Implementation Guidance

Updates are based on Working Group decision per two Public Comment feedback periods commencing on 22-May and 21-Aug 2025.

This Public Comment Period will close on 5-Dec 2025.

[bmayd]

Addition of value 2 representing Video on Demand conent to the livestream attribute in Object: Content

I find livestream as currently defined in the spec:

0 = not live, 1 = content is live (e.g., stream, live blog).

does not reflect the common meaning of the term well and the addition of the new value "2 = Video On Demand (VOD)" doesn't improve things.

What's confusing is that livestream relates to how content is broadcast, not what content is broadcast. Live streams can be broadcast as they happen (e.g., gamers on Twitch, breaking news CNN.com, sports on ESPN.com) or they can be pre-recorded (e.g., Apple WWDC and iPhone introductions) or they can be a mix of both (e.g., Google I/O). The common distinguishing characteristic in all of these cases is that the broadcast was originally scheduled and streamed at a specific point in time.

Things are further complicated by the fact that livestreams are often made available after the fact for on-demand consumption, for example you can watch the livestream of Google I/O on YouTube after the initial broadcast. So it is possible for livestream to be true ("1") and recorded also to be true ("1").

Rather than adding a new value for VOD, I suggest clarifying what livestream signals:

Livestream indicates a broadcast originally streamed at a scheduled point in time.
0 = not a livestream, 1 = originally broadcast as a livestream

And elaborating in the implementation guidance:

Livestream indicates a broadcast originally streamed at a scheduled point in time. A livestream may include content broadcast as it was captured (live sports), content that was recorded prior to broadcast (a music video) or a combination of both (a product announcement). Note: livestreams may be available for on-demand streaming after the original broadcast and in those cases the recorded attribute should be used to signal when that is the case.

[bmayd]

Addition of recorded attribute to Object: Content

I think perhaps rather than signaling whether content was recorded or not, it would be more useful to signal if the content broadcast is scheduled or its on-demand. I assume buyers will use the signal to gauge user attention levels and pre-recorded livestreams (iPhone introductions) are often as compelling as livestreams captured live (sports events).

So, instead of a recorded attribute, include an attribute called vod with description:

An enumeration indicating whether content is being consumed on-demand:
0=linear broadcast, 1=video-on-demand broadcast

[bmayd]

Implementation Guidance on use of new attributes to better describe Live programs

If the above suggestions make sense, the implementation guidance would need to be updated accordingly. In particular, the current guidance assumes livestream indicates whether a broadcast is of content captured live and the above suggested changes focus on how the content is broadcast and not what content is broadcast.

In addition, if there is a desire to signal whether content is a live event captured as it happened, I suggest adding a capturedlive attribute in addition to livestream and vod:

An enumeration indicating whether content is a live, unscripted event captured as it happened:
0=not live, 1=live event

[gmut1]

1. It seems inconsistent to signal VOD content within the livestream attribute. Having VOD defined in two different places will also more than likely lead to confusion, considering already (per current spec):

• when content.context is 1 (video) and livestream is 0, the content is defined as VOD.
• proposing, as Brian suggested, aligning on definition of the livestream attr before we tuck VOD in there; and two, a decision on how content.context would be used moving fwd.

2. From a demand-side pov, can we better understand the use case for buyers wanting a distinction in the method/timing of recording, if any.

• i.e. a live event pre/post recorded by the media publisher, versus recorded by the consumer (dvr playback)?

[lukewithell]

Display and Video 360 would like to offer feedback on the proposed changes to the OpenRTB specification. While we support the goal of providing better signals for live and VOD content, we believe the current proposal could lead to confusion and may not fully address key buying needs.

1. The livestream Attribute is Ambiguous: The proposed definition (0 = not live, 1 = content is live, 2 = Video On Demand) conflates two different concepts: the method of content delivery (e.g., a scheduled stream) and the nature of the content itself (e.g., an event happening in real time). Adding 2 = VOD is also problematic, as VOD is implied when the content is video and livestream is 0.
2. The recorded Attribute Doesn't Capture "Real-Time" Liveness: From a buying perspective, the most critical signal is whether an ad opportunity is part of an event happening in real time, as this is a strong indicator of user attention and engagement. The proposed recorded attribute does not clearly capture this distinction.

Recommendation

To provide clearer and more actionable signals for buyers, we propose redefining the livestream attribute and introducing a new realtime attribute.

Field	Type	Description
livestream	integer	Indicates how the content is being delivered:0 = Content is being delivered on-demand (i.e., VOD).1 = Content is being delivered via a linear stream (e.g., AVOD channels).
realtime	integer	An enumeration indicating if the event is happening in real time while it is being watched:0 = Not happening in real time (e.g., a replay).1 = Yes, happening in real time (e.g., a live sports game).

This approach separates the delivery mechanism (livestream) from the liveness of the event itself (realtime), providing buyers with a more nuanced and accurate understanding of the ad opportunity. We have included a table of scenarios in this document that illustrates how these attributes would apply in practice.

Scenarios	livestream	realtime
Sports game currently happening being streamed as the game is going on	1	1
Replay of past sports game, programmed streaming on an ad-supported channel	0	0
Sports game streaming on-demand (not live)	0	0
International sports coverage (e.g., Olympics, Tour de France, Formula 1) recorded abroad and aired later	0	0
Episodic content with real time tune-in	1	0
Episodic content with on-demand viewing	0	0
Award show being streamed as it is happening	1	1
Replay of award show, programmed streaming on an ad-supported channel	0	0
Award show streaming on-demand after the event has completed	0	0
Real-time news being viewed as it is happening	1	1
News program after the program has completed	0	0
Sitcom rerun, programmed streaming on an ad-supported channel	0	0
Sitcom rerun streaming on-demand	0	0