negative duration computed problem

[Lirui072037]

Hi,

What causes the emergence of such a log？

thank you！

Lirui

[mangui]

it means that there is a difference between fragments duration exposed the playlist (#EXTINF:...) and the real duration of the fragments (extracted from fragment parsing)

[Lirui072037]

Is the cause of the stream？Can I change it in the code？

[mangui]

it is a stream issue, you can't workaround in the code. flashls can handle small drifts, but accumulated drifts should not exceed one fragment duration (this is what is happening in your case)

[Lirui072037]

But jwplayer won't appear this problem, is the same stream

[mangui]

up to you to use jwplayer, but this stream seems broken. u can eventually share it for confirmation.

[Lirui072037]

this is url： http://hz-vod.cdn.aodianyun.com/m3u8/0x0/kekakik.stream.1441438685/kekakik.stream.1441438685.m3u8

[colejona]

@mangui , is this message accurate? It says there should be some duration drift.

Also, is error level logging appropriate for this? Because if hls.js can handle some drift up to a certain amount, perhaps it can be just a warning?

[mangui]

Hi @colejona well, if computed duration becomes negative, that means that on the overall playlist, you got a cumulated drifts larger than a frag duration. it might not lead to any visible issue, but it is definitely not a good sign

[colejona]

Thanks, @mangui. We're considering converting these error messages into warning messages in our custom logger -- do you think that if we did encounter a visible issue, we would get a different error from hls.js? I wouldn't want to hide the only error that we get when a visible issue occurs..

[mangui]

you can convert to a warning and send a PR.

[colejona]

Will do, thanks!

[colejona]

@mangui I just realized that this is a flashls issue -- we're working with hls.js right now, so it is there that we will submit a pull request for this.