Timed Metadata coming from Wowza is late by one event

[berrutti]

Description

We use Wowza to generate HLS streams that we later consume with the video.js player.

These streams have timed metadata injected into them. We later parse that metadata and we use it to sync presentation slides.
This setup worked fine until we updated video.js to version 8.5.2.

After the update, we noticed that the slides were always "late" by one, and that the first event never fired.
This happens on Chrome and Firefox. It looks like the activeCues are not properly updated at some point.
When checking all the cues, not only the active ones, the metadata can be seen.

If we try the same stream with the previous video.js, version 8.3.0, the timed metadata arrives at the right time.

In this codepen you can find a very stripped down version of that code:
https://codepen.io/Blublublublbulbublub/pen/LYMXrrQ

You can see that there's both versions of video.js there, and you can comment / uncomment to compare both versions working side by side.

Unfortunately, the test stream in that codepen doesn't really reproduce the issue, but at least I can see at least some differences when comparing both video.js versions. Please see this screenshot:

On the left side 8.5.2, on the right side 8.3.0

As you can see, at one point there's a new cue with empty data, and the cue start and end times differ.
I'm not sure if this is the same issue or if it's something different, but it seems it could be related somehow.

Sources

You can use the source in the codepen. If this is not enough to reproduce the issue, we can organize a call and I can show you with the live wowza stream.
I'm also trying to see if we can record a wowza stream with injected metadata to reproduce this issue, but it will take a few days.

Steps to reproduce

1. Load an HLS live source
2. Listen for timed metadata
3. Print the timed metadata

Results

Expected

The timed metadata shows the right metadata.

Error output

No errors.

Additional Information

videojs-http-streaming version

videojs-http-streaming 3.5.3

videojs version

video.js 8.5.2

Browsers

what browsers are affected? please include browser and version for each

• Chrome
• Firefox

Platforms

what platforms are affected? please include operating system and version or device and version for each

• macOs

Other Plugins

are any other videojs plugins being used on the page? If so, please list them with version below.

• none

Other JavaScript

are you using any other javascript libraries or frameworks on the page? if so please list them below.

• none

[mister-ben]

Perhaps related to #1411

[berrutti]

I'm afraid I tried the pre-release version of video.js, 8.6.1 and the issue still persists.
Our backend team is working on creating a Wowza recording of live stream, so maybe that way I will be able to share a "broken" stream with injected metadata.

[berrutti]

I'm checking the changes in the library since I still see this issue and the only change I see related to tracks is these commits:
d258fae
12acbdd

The function removeDuplicateCuesFromTrack was refactored.
Do you think that this new method is removing something that it shouldn't?
There's also a new condition now that says:

// If we have no frames, we can't create a cue.
if (!metadata.frames || !metadata.frames.length) {
  return;
}

Do you think that maybe some of these changes could impact in some way on why the active cues do not have the same info now?
Sorry for asking again but this is blocking us to udpate video.js 😢. The last working version we have is 8.3.0, which is failing us when we try to ran yarn upgrade because of some hoisting issue, so we are pretty much stuck like this.
Thanks a lot for your support

[berrutti]

Ok, I checked these two commits locally, meaning, I brought back the code to how it was before these two commits and those don't seem to be related to the issue.

I also brought back the old version of http-streaming (3.3.0) to the latest of video.js and the issue still persists (had some errors because of the code changes, but I could clearly see that the event is "late" by one).
So to be honest I'm lost in what could be the root cause of this problem.
Do you have any idea how can I test this in a better way? I'm not even sure that this issue is in the right place now, since it could be part of video.js itself or from another library like mux?
I'll try to record a stream for you guys where I can reproduce this issue but I'm afraid that the record wont present this problem for whatever reason...
I'll keep you updated. Thanks

[mister-ben]

This may be addressed by the fix in #1448. Would you be able to test against that?

[robert-schurig-mi]

I updated to the latest version of videojs 8.6.1 and the issue still exists.

I started an investigation and found out that the cue-point on the track has in version 8.3.0 an endTime of "Infinity" and in version 8.6.1 the property is "0".

I also created an interval on the activeCues (getter)... but the cue is never visible in this array.

[robert-schurig-mi]

@mister-ben
I checked the history of the file "src/util/text-tracks.js".
I can see that the code was modified different time. To sum it up:

The endTime of a cue was set to Infinity. Then someone set it to "0" and now in the latest version of http-streaming (v3.8.0) the endTime is set to the startTime in case the video is not Infinit ( what is the case of a live stream ).

videojs/http-streaming v3.8.0:

If the endTime is Infinity or start and endTime are set to the same.. not sure why it was changed... but it breaks the code. And the cue doesn't get active (track.activeCues stays empty)

[robert-schurig-mi]

This may be addressed by the fix in #1448. Would you be able to test against that?

@mister-ben I have tested it again and the results you can see one post above. :/

[robert-schurig-mi]

@mister-ben
Still an issue. Tested with video.js version 8.17.2. Is it possible to create a PR ? Can I contribute to this project ? Thank you.

[mister-ben]

Any PR or contribution would be welcome!