Why TextTrackCue's endTime is Inifnity On Safari?

[valletgood]

When playing HLS live content in Safari, the subtitles continue to be displayed and are not disappearing. When checking the activeCues through the Web API textTracks, it was found that some cues have an endTime of Infinity. When playing the same live content in Chrome, the issue does not occur. What is the reason for assigning the value of Infinity to endTime when processing the received startTime and endTime of the subtitles from the server in Safari? The first screenshot shows the data received from the server, and the second screenshot shows the data obtained through the textTracks API. The server continuously sends time data, but Safari is not able to process it properly. What could be the reason for this?

(https://user-images.githubusercontent.com/116650048/232930905-c284406e-67aa-464d-92e5-69f16b41e6f1.png)
(https://user-images.githubusercontent.com/116650048/232930936-d3d6264a-86d3-4892-953f-4e082f803f21.png)

[gkatsev]

This is likely an implementation detail after VTTCue was updated to allow endTime to be Infinity (#493). Probably if the endTime of the cue matches the live edge of the video (or if it's later), the cue will have endTime set to Infinity, but it should update to a finite number once the end time of the cue is within the seekable range.

This seems to be the case for me in my test stream. I can see cues start with endTime being Infinity and then after a bit transition to be a finite value.

[valletgood]

Thank you for your response.
If so, does the reason why the endTime of the cue is set to Infinity occurs when the endTime of the cue is the same value as or after the live edge of the video? In order to prevent endTime from becoming Infinity, should the server allocate the endTime of the cue to a value smaller than the live edge of the video? Or is there another way?

[gkatsev]

I would recommend adjusting your code to work with endTime being Infinity rather than adjusting the captions to try and avoid this.

[valletgood]

Is that possible? Isn't the endTime of the captions handled and returned in Safari's browser code? I'm sorry, but could you give an example, please?

[eric-carlson]

When playing HLS live content in Safari, the subtitles continue to be displayed and are not disappearing. When checking the activeCues through the Web API textTracks, it was found that some cues have an endTime of Infinity. When playing the same live content in Chrome, the issue does not occur. What is the reason for assigning the value of Infinity to endTime when processing the received startTime and endTime of the subtitles from the server in Safari? The first screenshot shows the data received from the server, and the second screenshot shows the data obtained through the textTracks API. The server continuously sends time data, but Safari is not able to process it properly. What could be the reason for this?

WebKit uses the AVPlayerItemLegibleOutput API to get cues from an in-band text track (a text track in a media file). A quirk of this API is that the client is called with the cue data and its start time, but not the end time. A cue's end time is implied by the delivery of the next cue or empty sample. WebKit gives the cue an end time of Infinity initially, and updates the end time when it is known.

[marcoscaceres]

Should this be reflected in the spec?

[eric-carlson]

Should this be reflected in the spec?

While Infinity is a valid cue endTime (#493), I think it would be helpful for the spec to note that the endTime may be updated.