Fix jump-back of needed segment time for text stream after first update of media state failed with unavailable segment

[albertcsm]

Ocassionally, when playing a multiple-period DASH with text stream on and off, I got "Assertion failed: All MediaStates should need the same Period be performing updates." and player stuck after a few seconds.

The log show that there is a jump-back of the "timeNeeded" for text stream. The jump-back was due to resetting of the "resumeAt" variable between updates of the media state. After removing the line that resets "mediaState.resumeAt", the issue was resolved.

19:16:25.582 streaming_engine.js:888 (text:2820) timeNeeded=657.4734833
19:16:25.582 streaming_engine.js:900 (text:2820) update_: playheadTime=645.597443 bufferedAhead=11.8760403
19:16:25.583 streaming_engine.js:924 (text:2820) need Period 44 playheadTime=645.597443 timeNeeded=657.4734833 currentPeriodIndex=43
19:16:25.583 streaming_engine.js:1680 (text:2820) all need Period 44
19:16:25.583 streaming_engine.js:1708 (text:2820) calling onChooseStreams()...
19:16:25.584 player.js:2185 onChooseStreams_ Object {startTime: 657.4734833, textStreams: Array(0), variants: Array(1)}
19:16:25.584 player.js:2201 onChooseStreams_, variants and text streams:  [Object] []
19:16:25.586 streaming_engine.js:1755 (text:2820) calling onCanSwitch()...
19:16:29.677 player.js:2185 onChooseStreams_ Object {startTime: 661.5775833, textStreams: Array(0), variants: Array(1)}
19:16:29.678 player.js:2201 onChooseStreams_, variants and text streams:  [Object] []
19:16:33.769 player.js:2185 onChooseStreams_ Object {startTime: 664.664, textStreams: Array(4), variants: Array(1)}
19:16:33.770 player.js:2201 onChooseStreams_, variants and text streams:  [Object] (4) [Object, Object, Object, Object]
19:16:33.770 player.js:2108 Choosing new streams for (3) ["video", "audio", "text"]
19:16:33.771 player.js:2206 onChooseStreams_, chosen= Object {video: Object, audio: Object, text: Object}
19:16:33.772 streaming_engine.js:1879 (text:4470) updating in 0 seconds
19:16:33.774 streaming_engine.js:888 (text:4470) timeNeeded=664.664
19:16:33.774 streaming_engine.js:900 (text:4470) update_: playheadTime=653.789963 bufferedAhead=3.6835203000000547
19:16:33.775 streaming_engine.js:1054 (text:4470) next position unknown: nothing buffered
19:16:33.775 streaming_engine.js:1094 (text:4470) looking up segment: presentationTime=657.4734833 currentPeriod.startTime=664.664
19:16:33.775 streaming_engine.js:1143 (text:4470) segment is not available: currentPeriod.startTime=664.664 reference.startTime=0.7197344 reference.endTime=2.8028000000000475 availabilityStart=481.93099999427795 availabilityEnd=661.930999994278
19:16:33.776 streaming_engine.js:1879 (text:4470) updating in 1 seconds
19:16:34.777 streaming_engine.js:888 (text:4470) timeNeeded=654.792894
19:16:34.777 streaming_engine.js:900 (text:4470) update_: playheadTime=654.792894 bufferedAhead=2.6805892999999514
19:16:34.777 streaming_engine.js:924 (text:4470) need Period 43 playheadTime=654.792894 timeNeeded=654.792894 currentPeriodIndex=46
19:16:34.778 streaming_engine.js:1665 (text:4470) not all MediaStates need Period 43

[joeyparrish]

I'm not convinced that this is the correct solution to your problem.

resumeAt is meant to override the playhead time when we are switching periods. It's an indirect solution to #715, and was introduced in 2cc68b2.

Once we have consumed resumeAt, it should be reset to 0. It is used like Math.max(playheadTime, resumeAt) to decide what to stream next, so if it is never reset, I think it could cause issues when seeking.

Can you produce a failing unit test that demonstrates the bug you're trying to fix? That might help us understand and fix your issue.

[albertcsm]

I think resumeAt is used to mark the segment time that need to be append to the buffer (aka timeNeeded) rather than the playhead. Please correct me if wrong.

So setting the resumeAt to Math.max(playheadTime, resumeAt=0) would "timeNeeded" jump backward.

[TheModMaker]

@albertcsm You are correct that it indicates the next segment to download; but @joeyparrish is also correct about needing to reset it once we use it. Once we have downloaded a segment, we will download the next segment, not look back at the playhead time.

The problem (I think) is that we are resetting the value too soon in the method. Your logs show that when we tried to fetch the segment from the next Period, it wasn't available yet. So we wait a second and try again. The problem is that now the resumeAt has been reset, so we try at the playhead.

I think the solution should be to move the setting it to 0 to the end of the method where we actually append the segment.

[albertcsm]

@TheModMaker I agree it is better to move the "setting it to 0" to the end, would you like me to update the fix?

[TheModMaker]

I think we will handle the fix so I can include some tests. Thanks for finding this.

[joeyparrish]

The fix for this has been cherry-picked and will be released in v2.1.5.