Several customers have ran into this error during a live event, some had refreshed the page and recovered. We looked at the upstream CDN/packaging service and there were no error from them. What can cause this error?
VIDEOJS:,WARN:,Segment with index 9 from playlist 0-index_131.m3u8 has a duration of
95449.7176888889 when the reported duration is 6 and the target duration is 6. For HLS
content, a duration in excess of the target duration may result in playback issues. See
the HLS specification section on EXT-X-TARGETDURATION for more details:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.3.1
There are some reference to this error on VideoJS open issues page. I couldn't reproduce the error.
Looking at the code the duration is retrieved from audioTimingInfo: segmentInfo.audioTimingInfo, videoTimingInfo: segmentInfo.videoTimingInfo, does that mean encoder has sent a incorrect timing info?
Player version: 7.20.3
Your Transport Stream timestamps have wrapped around.
Transport Stream timestamps are 33 bit 90kHz counters, and
log2((95449.7176888889-6) * 90000) = 33
This wrap around happens at 2^33 / 90000 seconds, or ~26.5hrs.
Was yours a very long live stream?
As has been pointed out on SO this is perfectly normal, and you need to keep the wrapping nature of the timestamps in mind when interpreting them (ffmpeg does this well, sometimes too well).
The log output tells us that video.js is incorrectly interpreting TS timestamps, and in fact, searching for timestamps on video.js's issues page turns up this.
There's a bunch of "me too"s on there, but no progress and the issue has been marked as stale.
Pity, it shouldn't be too hard to fix.
UPDATE It's actually the responsibility of a video.js sub-package called http-streaming and it has similar, tantalising issues