Multiple time ranges getting buffered.

[sanbornhilland]

I'm running into a problem with the same content that was used to reproduce #112. Around the middle of the video (2:53) playback stops and the assertion on line 515 of stream.js fails: 'Multiple time ranges should not be buffered!'. It is possible that there is a problem with this manifest that is causing it but I thought I would open this here in case you guys recognize what the problem is.

Update: This does not happen consistently at 2:53 but it happens consistently in the time range. After seeking 2 minutes into the video I had the same problem at 3:11.

[sanbornhilland]

I can't figure out what is going wrong with this. @joeyparrish if you have time can you guys try to reproduce this to see why multiple time ranges are getting buffered.

[sanbornhilland]

Update: This problem doesn't happen in 1.3.2, only 1.4.0

[tdrews]

I can't seem to repro on ToT. I've tried starting playback and letting it play through, seeking to 2:00 manually, and also using setPlaybackStartTime(120) without any luck.

How many ranges are buffered when that assert hits?

[sanbornhilland]

There are 2. And then this assertion gets triggered 4 or 5 times and then playback and buffering just stops and nothing happens but nothing is being logged so I can't see what has failed.

[sanbornhilland]

Which content are you using?

[tdrews]

It is the content that you shared with @joeyparrish for #112.

[tdrews]

If you turn verbose logging on (;v query parameter), what do you see before the assert hits?

[sanbornhilland]

Fetching segment s…a.m…a.SegmentReference {startTime: 228.88, endTime: 232.44, startByte: 0, endByte: null, url: g…g.Uri}
fetch
Estimated bandwidth: 1.98 Mbps
Fetch done.
Buffering goal reached.
Estimated bandwidth: 2.75 Mbps
Fetch done.
Assertion failed: Multiple time ranges should not be buffered!
Fetching segment s…a.m…a.SegmentReference {startTime: 232.44, endTime: 236, startByte: 0, endByte: null, url: g…g.Uri}
fetch
Buffering goal reached.
Estimated bandwidth: 2.99 Mbps
Fetch done.
Buffering goal reached.
Buffering goal reached.
Buffering goal reached.
Buffering goal reached.
Buffering goal reached (repeated over and over).

[sanbornhilland]

Also, the player says it has 15 seconds buffered ahead but pressing play does nothing.

[tdrews]

Hmm, what browser version?

[sanbornhilland]

Chrome 43.0.2357.132 (64-bit)

[tdrews]

Chrome for Linux?

Also, can you repro if you disable bandwidth estimation?

[sanbornhilland]

Chrome on Mac.

How can I disable bandwidth estimation?

[tdrews]

You can call player.configure({'enableAdaptation': false}), ideally prior to player.load(), but it can be called at any time.

[sanbornhilland]

If I turn off adaptation in your sample app then the problem goes away.

[tdrews]

Ah, I'm thinking that a particular segment from one Representation is not aligned ideally with another segment from another Representation (although MSE should be robust against this), or one of the Representations has an actual encoding issue (that Chrome can't handle).

I may not be able to repro because I'm not streaming the same bitrate stream as you. I'll try each bitrate stream to see if I can repro. If I am still unable to, then the problem is probably dependent on the order of segment insertions and timing of switches (all dependent on network conditions), in which case I'll need to get some additional debug logs from you.

[tdrews]

I still can't repro from my end. Can you add the following log to shaka.media.SourceBufferManager.prototype.assertSingleRange

if (this.sourceBuffer_.buffered.length > 1) {
  for (var i = 0; i < this.inserted_.length; ++i) {
    var r = this.inserted_[i];
    console.log(
        'r[' + i + ']:',
        'start=', r.startTime,
        'end=', r.endTime,
        'stream=', r.url.toString().split('/').slice(-1)[0]);
  }
}

This will output URL suffixes, if you don't want to share those here, please feel free to share the logs with me privately (contact info in CONTRIBUTORS).

[tdrews]

We determined that this issue can be caused by Representations' segments not being aligned with their corresponding segment indexes (which may be caused by drift, see section 7.2.1 of ISO/IEC 23009-1).

For example, given a SegmentTimeline that specifies the following segments for an SD stream and an HD stream,
1: start=0, end=10
2: start=10, end=20
3: start=20, end=30
If the SD segments actually (i.e., the timestamps in the actual media content) have the following
start and end times,
1: start=0, end=9
2: start=9, end=19
3: start=19, end=29
then switching to the HD stream after segment 1 is fetched and inserted will cause a gap in the buffer since the SD segment ends at 9 (incorrectly) and the HD segment starts at 10 (correctly).

Some small discrepancies can be tolerated by MSE, and Shaka will also handle an arbitrary constant offset between a segment index and the timestamps in the actual media content so long as all Representations have the same offset.

If you are encountering this issue then you should ensure that the segment index (i.e., SegmentTimeline or SegmentList or SIDX, etc.) for each Representation is accurate; for example, specifying a separate SegmentTimeline for each Representation instead of for the entire AdaptationSet may resolve the issue. This issue may be caused by content creation tools (e.g., DASH packagers or encoders).

This issue did not manifest itself in v1.3.x as the stream switch implementation unintentionally handled content with unaligned segments...

The 1.3 implementation switches by first splicing in a chunk of new segments into the buffer before the old segments in the buffer end. It then changes what gets inserted in the update loop. The splice step overwrites any potential gap in the buffer; for example, if the old segments are supposed to end at 10 seconds but actually end at 8, it doesn't matter, since the new segments get spliced in before 8 seconds.

The 1.4 implementation switches simply by changing what gets inserted in the update loop, it doesn't splice in anything beforehand. In this way it never overwrites what's in the buffer, unless the next new segment starts before the last old segment ends. The 1.4 design saves bandwidth, but more importantly allows for quick switching between bitrates; for example, the 1.4 implementation can be playing 720p, insert one 480p segment, and then switch back to 720p without overwriting anything in the buffer or re-downloading any segments.

With f08fbba the player will now attempt to recover from unaligned segments by re-buffering.

Closing this issue as it is being caused by the content itself. However, if we find that this is a common problem with content creation tools then we can start looking at some other mechanisms to better handle this type of content.

[ghost]

Hi Team,
I am also facing similar issue.
I am using mp4box with following command-
-rap -url-template -frag 2000 -mpd-title ""{1}"" -dash 10000 -out ""{0}"" -sample-groups-traf -profile onDemand ""{2}"""
The output only consist of initmp4 file and mpd file, hence there are no individual m4s files produced.

How do I check segmenttime line of my content, My MPD contains following lines-

113440_928_dashinit.mp4

and this is same for all bitrates.

[joeyparrish]

@tsinghal18 What version of Shaka Player are you using? What specific symptoms are you seeing?