ID3 cues can have negative start time near PTS wraparound

[JPeMu]

Description

Playing a live stream which has ID3 tags embedded in a separate discontinuity group with very different PTS values can sometimes result in the cues having negative startTime values. As a result, they are never presented in activeCues, and never removed from the cues array.

This seems to happen when segments from the currently playing group have large PTS (>32 bit) and the group containing the ID3 metadata has low PTS value. The cuechange event does trigger, but the cues are not presented in activeCues.

However... after some more time, as the large PTS approaches the rollover value, the cues do sometimes start to be transferred to activeCues, but with incorrect startTime values.

As an example, the segment being played has the following timestamps in the PES header:
PTS: 8019923008
DTS: 8019915808

But the segment following this (with the ID3 track) has the following timestamps:
PTS: 2106000
DTS: 2098800

This produces a cue point with a negative startTime

Sources

Can provide a Charles capture if necessary

Steps to reproduce

1. Play a live HLS stream which has multiple discontinuity groups. Each rendition of the stream would be constructed in the following style:

[Segments containing large PTS values, but no ID3 track]
#EXT-X-DISCONTINUITY
[Segments containing small PTS and ID3 track]
#EXT-X-DISCONTINUITY
[Segments containing large PTS values and no ID3 track (continuation of first block)]
etc.

2. Add event listener for "addtrack" to the textTracks(). When this fires, add event listener to the track for "cuechange".

3. Observe that when the cuechange fires, activeCues is empty (or contains 1 or more incorrect cues only). Observe that there are a large number of cues in the cues array which have negative startTime.

4. As the PTS rollover approaches, observe that the cuechange event presents activeCues array containing the wrong cues.

5. Following the PTS rollover, observe that everything works as expected.

Results

Expected

Cues should be presented in the activeCues array at the correct time. startTime should not be negative.

Additional Information

videojs-contrib-hls version

videojs-contrib-hls 5.3.3

videojs version

video.js 5.18.4

Browsers/Platforms

Observed on Windows 8.1
Firefox: 52.0 (32-bit)
Chrome: 57.0.2987.98

[mjneil]

Hi @JPeMu Do you have a publicly available source I can use to look into this?

[JPeMu]

You can use one of our test streams (I have seen the fault on this specific stream):
http://csm-e.cds1.yospace.com/csm/extlive/yospace02,sampledroid.m3u8?yo.ac=true

This is a continuous-running live stream with very frequent discontinuities (for ad insertion). Unfortunately, this means that most of the time you won't see this problem as the PTS continuously rolls (and wraps). Only when it gets to a large value will the problem appear, and that only happens for a relatively short window every ~25 hours or so.

I have also uploaded 2 sample TS segments here:
http://demo.yospace.com/tony/110611066.ts
http://demo.yospace.com/tony/yospace02.ts

As examples of the issue. The first (110611066) plays prior to the discontinuity and the second plays after the discontinuity. It is the second ts which contains ID3 metadata whose cue startTimes end up being negative.

Hope this helps - let me know if you need anything else. Thx.

[mjneil]

Thanks for helping solve this issue! This should be fixed in v5.4.1.