Unexpected Video Stream API Events

In the process of developing a group watch feature I have observed unexpected API events from the player:

  1. Within a fraction of a second after the initial play event, a seeked event usually fires at player.currentTime around 0.08 seconds.

  2. When the user seeks forward or backwards while the player is already playing, there’s a sequence of events starting with a seemingly extraneous pause followed quickly by a redundant play, then finally the expected seeked event.

  3. When the video ends, there is a pause event followed 1ms later by the ended event.

Are these behaviors all normal or could any of them be considered bugs?

I did not notice any of this when I first starting using the API, but then I did just a couple days ago, which leads to the question of whether the API version changed and whether there could be future changes that break my code since the only URL I’m aware of is this one:

https://embed.videodelivery.net/embed/sdk.latest.js

Is it possible to specify a version number to maintain compatibility with my code?

If not, does sdk.latest.js do anything about browser caching?

Tested in Firefox and Chrome for Ubuntu and here is my CodePen with output to the browser console:

Hey, there! The events are all being fired by the native <video /> element, and the SDK just proxies them up to the host page.

Regarding each of these:

  1. I suspect this might be caused by a misalignment between the audio and video timestamps in the first segment of this video. We’ll look into this further, thanks for reporting!
  2. This is due to the behavior implemented in our player of pausing the video while the user drags the seek thumb then resuming when they release, and is expected.
  3. This is also expected and can be reproduced on the MDN docs page for the video element by adding onended="console.log('ended')" onpause="console.log('pause')" attributes on the video element.

We do not support pinning versions of the SDK at this time, and we set a relatively short (3 minutes) cache-control: max-age header.

Hope this helps!