feat(svta): SVTA2053 ad creative signaling - #331
Conversation
New URL option svta_ marks ad-creative windows of the live timeline with an EventStream of scheme urn:svta:advertising-wg:ad-creative-signaling, one Event per creative carrying the SVTA2053 version 2 JSON payload as node data: identifiers, duration, and the tracking URLs to fire while the creative plays. It uses the same break-schedule grammar as sgai_ (svta_30:15,90:15 or svta_p60:20), with ;ads=<n> to split a break into several creatives and ;skip=, ;click=, ;verif=, ;pod=, ;ts= for the rest of the payload. As for sgai_, the video track serves the generated AD BREAK countdown slate inside each window, so the signaled creative is visible. The tracking events use the VAST names (the only ones players map; the spec's alternative progress+offset form is silently dropped by Shaka) and point back at livesim2's own /sgai/beacon endpoint with the session and break ids baked in, since a player fires these URLs verbatim. The whole ad-measurement round trip can then be watched at /sgai/session_status. Verified end to end against a Shaka Player build: impression, start and the quartiles arrive in the session record, attributed per break occurrence. sgai_...;svta=1 additionally puts an SVTA2053 EventStream on every ad Period of the List MPD returned by the ad-decisioning endpoint, describing the creative that Period imports with its real catalog id and duration. Opt-in, since a player acting on both that and the existing callback beacons would report each tracking point twice. The flag rides on the ReplacePresentation @uri so the endpoint stays stateless about the stream configuration. The ad-break schedule (fixed or periodic breaks, the instances signaled in an MPD, and the slate window) moves to AdBreaks in adbreaks.go, shared by sgai_ and svta_; sgai_slate.go becomes adbreak_slate.go. For svta_ the signaled set also keeps breaks that ended but are still inside the timeshift buffer, so a viewer seeking back still sees the signaling.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| if err != nil || n <= 0 { | ||
| return nil, fmt.Errorf("svta ts %q: must be > 0", v) | ||
| } | ||
| cfg.Timescale = uint32(n) |
Please open an issue on Shaka and I'll fix asap.
It's supported since 5.2.0, If you find any errors, please report them and I'll fix them ASAP. |
|
@avelad Thanks for the update. I didn't check towards the latest version. Sorry! Will test with that instead. |
|
@avelad You are right on both counts, and no Shaka issue is needed — I was reading a checkout from
I built current
Happy to open a Shaka issue for either with a one-line livesim2 repro URL — just say the word, The one design question left. Is a DASH-side equivalent something you want in Shaka, and if so what carriage would be most useful |
|
Both sounds a bug on Shaka, please provide me an url to test, and I'll fix it. Don't worry about Shaka's internal implementation :) In my opinion, the correct way to do it is to include SVTA information in each ad, not globally. |
3 participants
Implements SVTA2053 Ad Creative Signaling (payload version 2) in the DASH output, closes #310.
What it does
A new
svta_URL option marks ad-creative windows of the live timeline with anEventStreamofscheme
urn:svta:advertising-wg:ad-creative-signaling, holding oneEventper creative whosenode data is the v2 JSON payload — identifiers, duration, and the tracking URLs to fire while the
creative plays.
It reuses the
sgai_break-schedule grammar:Example:
/livesim2/svta_p60:20;ads=2/testpic_2s/Manifest.mpd?sessionId=alice— two 10 screatives every UTC minute. As for
sgai_, the video track serves the generated AD BREAKcountdown slate inside each window, so the signaled creative is visible.
The tracking URLs point back at livesim2's own
/sgai/beaconendpoint with the session and breakids baked in (a player fires them verbatim, so nothing can add them later), which makes the whole
ad-measurement round trip observable at
/sgai/session_status?sid=<sessionId>— the point of#310: end-to-end ad-measurement testing without an SSAI stack.
sgai_...;svta=1additionally puts an SVTA2053EventStreamon every ad Period of the List MPDreturned by the ad-decisioning endpoint, describing the creative that Period imports with its real
catalog id and duration. Opt-in, because a player acting on both that and the existing callback
beacons would report each tracking point twice.
Decisions worth reviewing
Eventper creative, each with a single-slot payload atstart: 0, per Table 5 of thespec. It also sidesteps a Shaka bug:
svta_ad_manager.jscomputesendTime = region.startTime + slot.duration, which is wrong for any slot withstart > 0.impression,start,firstQuartile,midpoint,thirdQuartile,complete) rather than the spec'sprogress+ offset form, becauseprogressis not inShaka's
createTrackingFromEventsmap and is silently dropped — nothing would fire."as";equivalent for any conformant parser, and a
xml:",cdata"sibling field would duplicate thetext on read-modify-write round trips.
window) is factored out to
AdBreaksinadbreaks.goand shared withsgai_;sgai_slate.gobecomesadbreak_slate.go. Forsvta_the signaled set also keeps breaks thatended but are still inside the timeshift buffer, so a viewer seeking back still sees the
signaling.
Verification
Unit tests for the grammar, the generated events and the JSON payload, plus URL-config, urlgen and
end-to-end MPD tests. Also driven through a real Shaka Player build against
svta_p20:10:ad-cue-points-changed,ad-impressionandad-startedfire, and the beaconsland in the session record with per-occurrence attribution:
Verified against upstream Shaka 5.2.x
Both branches were re-tested against a fresh build of Shaka
main(
v5.2.8-main-10-g7b41cae63) — no forked player required:svta_p20:10;ads=2— both creatives of every break reportimpression,start,firstQuartile,midpoint,thirdQuartile,complete, attributed per creative (svta-ad1,svta-ad2) and per break occurrence (evId).sgai_p20:10;svta=1— the Ed.6 List-MPD ad pod plays in stock Shaka (Linked Periods viaImportedMPDlanded in 5.2.0), with the Annex I query propagated onto the callback beacons.An earlier revision of this description claimed upstream lacked
@uriand List-MPD support; thatwas read from a stale checkout and is wrong. See the comment below for details and for the one
remaining open question about SVTA tracking on DASH interstitials.