Description
Have you read the FAQ and checked for duplicate open issues?
Yes.
If the problem is related to FairPlay, have you read the tutorial?
not applicable
What version of Shaka Player are you using?
4.14.1+
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from main?
Yes
Are you using the demo app or your own custom app?
Custom
If custom app, can you reproduce the issue using our demo app?
Not readily, since it requires pre-roll ads with DASH EventStream events
What browser and OS are you using?
Chrome MacOS
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Various devices exhibit the issue
What are the manifest and license server URIs?
Not readily available
What configuration are you using? What is the output of player.getNonDefaultConfiguration()?
default config will exhibit this issue
What did you do?
A stream with timed metadata in manifest and first Event with PTS 0.1 was played with a start time of 0.
What did you expect to happen?
Event with PTS 0.1 to emerge from shaka player via TimelineRegionEnter event
What actually happened?
Event is variably emitted, i.e., sometimes emerges, sometimes not.
ISSUE
For certain Google DAI SSAI contexts, metadata conveyed in a DASH (.mpd) EventStream node is required for client-side ad verification beacons. For example:
<EventStream schemeIdUri="urn:google:dai:2018" timescale="1000">
<Event presentationTime="100" duration="0" id="0" messageData="google_7546424159311290670"/>
...
</EventStream>
We've had reports of variably 'missing' default ad impressions, for pre-roll ads only, on numerous platforms. (The beacons directly impact ad monetization). The event corresponding to the pre-roll "default impression" is like that shown above, with a near-zero PTS (often 0.1).
APPARENT CAUSE
We have identified that in cases where the impression is missing, shaka's TimelineRegionEnter event does not fire for the metadata at PTS 0.1. Other observations indicate that this is a consequence of gap jumping being initiated at video start within gap_jumping_controller.
In cases where, at startup, the detected gap exceeds 100 ms, the event for the zero-duration region will not be emitted, since this results in establishing a "seeking" context provided to RegionObserver and other observers.
In region_observer, we see entry into the if (seeking) clause shown below, and the event is ignored.
{
weWere: BEFORE_THE_REGION,
weAre: AFTER_THE_REGION,
invoke: (region, seeking) => {
if (seeking) {
this.onEvent_('skip', region, seeking);
} else {
// This is the case of regions whose duration is smaller than the
// resolution of our polling.
this.onEvent_('enter', region, seeking);
this.onEvent_('exit', region, seeking);
}
},
Although "seeking" and "gap jumping" are mechanically identical, they are conceptually distinct. In a "true" seek, where viewer / application intent drives a playhead change, metadata in skipped regions should of course be ignored. We believe that in a gap jump, such metadata really should have been encountered, and although technically the playhead is engaged in a "seek", that this metadata shouldn't be ignored.
Are you planning to send a PR to fix it?
This one could require some discussion...
(@littlespex ; @dsparacio )