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)?