Add fallback value definition for initialStartupTime on p18

[tonihei]

The way initialStartupTime is defined currently, it leaves it open which value is assigned if the first playbackStart event is never reached. I guess something like "null" or equivalent, but worth spelling that out.

[tonihei]

In addition to that, the initialStartupTime also needs to be invalidated if a seek or pause event occurs before the first playbackStart event.

[gheikkila]

If a playbackStarted is never reached, I guess this should generate a playbackFailed, at least after some timeout? And yes, no initialStartupTime should be logged for that.

A seek basically will generate a new playbackRequested event, and if content is not already cached (as when seeking a bit backwards) will add some buffering time before a playbackStarted event is generated. If seeking during the inital buffering I guess it's an open question of the delay before any content is shown should be counted as initialStartupTime or just as normal rebuffering time. Current doc use the former.

[tonihei]

And yes, no initialStartupTime should be logged for that

I was talking specifically about this case. The current spec on p18 doesn't define a way to not return a value, to return null or something similar if the requirements are not met.

[tonihei]

guess it's an open question of the delay before any content is shown should be counted as initialStartupTime or just as normal rebuffering time

If the delay is caused by pausing the player during startup, then it could be arbitrary long. It seems it should neither be reported as rebuffering nor as starting up time.

[mlevine84]

WG agrees no initial startup time should be reported if the startup is not successful. In any such event, the implementation of the metric calculation, including any time outs, is left to the analytics agent and vendor.