Reference live stream fails to replay correctly in dev

[davemevans]

Environment

• The MPD passes the DASH-IF Conformance Tool on http://dashif.org/conformance.html
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://dashif.org/reference/players/javascript/ and not just on my page
• Link to playable MPD file: http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd
• Dash.js version: dev
• Browser name/version: Chrome 51.0.2704.103
• OS name/version: Windows 7

Steps to reproduce

1. Select: Sample Streams -> LIVE Services -> SegmentTimeline (livesim-dev)
2. Click Load

Observed behaviour

After ten seconds or so, smooth video rendering stops and the player seems to jump between frames, giving the appearance of only displaying key frames. The buffer is not exhausted according to the onscreen metrics, but appears to behave as if it is.

This stream plays correctly in 2.1.1 using the same configuration.

[dsparacio]

Looks like this happens at commit merge of PR #1387
Commit SHA
ec88e7c

Looking into it now.

[dsparacio]

This is the block causing the issue

File
TimelineConverter.js L192

if (!disableSnapToSegmentBoundary) {
    if (availableSegmentsEndTime && end > availableSegmentsEndTime) {
        end = availableSegmentsEndTime;
    }
    if (availableSegmentsStartTime && start < availableSegmentsStartTime) {
        start = availableSegmentsStartTime;
    }
}

[LloydW93]

I think it's possibly the loop here:
ec88e7c#diff-b8462b281fa8a19e82128e2caafb2397R182

It starts at the last calculated segment then walks back - is this expecting an ordering of segments that isn't necessarily the case?

[dsparacio]

@LloydW93 I think you are right.

[dsparacio]

@bbcrddave I see what is going on here just not sure what use case I would break by changing as I was not sure what the original PR is solving. Basically end value is one fragment duration less than start value with the new code in the block I mentioned.

[davemevans]

@LloydW93 can you comment?

[LloydW93]

As this PR has now been reverted, the issue should be resolved in the current 2.2 RC. Can you please verify?

[davemevans]

The referenced stream now plays smoothly and reports a sensible DVR window with the latest RC.