Regression on streams with timestamp/playlist drift in "0.7.10"

[doublex]

This hls-stream:

http://doppelbauer.name/u/master.m3u8

Works in "0.7.9":

http://streambox.fr/mse/hls.js-0.7.9/demo/?src=http%3A%2F%2Fdoppelbauer.name%2Fu%2Fmaster.m3u8

In "0.7.10" it stops after 46 seconds:

http://streambox.fr/mse/hls.js-0.7.10/demo/?src=http%3A%2F%2Fdoppelbauer.name%2Fu%2Fmaster.m3u8

[radiantmediaplayer]

Can you try with 0.7.11 and fill the issue template so that we can more easily try to reproduce it.

[doublex]

Same (but the regression was between 0.7.9 and 0.7.10)

http://streambox.fr/mse/hls.js-0.7.11/demo/?src=http%3A%2F%2Fdoppelbauer.name%2Fu%2Fmaster.m3u8

[mangui]

introduced by 198922c

there are large enough drifts on this playlist. the hardcoded delay might need to be adjusted or the logic should be reviewed.

[doublex]

@mangui
Thanks a lot!
Does the the "hardcoded delay" mean:
a) A video-encoding property is bad
b) A property of the HLS server is bad
c) An issue in "hls.js"

[mangui]

playlist signals fragments with duration 3s,5s,10s,10s,10s,...
whereas parsed fragments have the following duration : 16.6s,16.6s, 16.6s, ...

in 0.7.11 a specific logic has been introduced to cope with PTS drift : if a drift of more than 10s is observed then timestamp reference is reseted. this does not work with your stream. I might need to review the logic there. but your frag duration signaling is obviously wrong.

[doublex]

@mangui
Thanks a lot!
You are right, the second keyframe comes after 16.6s...
Would it be possible to add a paramter to change the 10s default?

If not, no problem. Should I close this issue?

[mangui]

@doublex it should be fixed. you can grab the last dist and recheck