TimeRangeUtils bufferedAheadOf breaks with >1 buffer

[baconz]

Imagine two buffers:

b0: 0 -> 10
b1: 11 -> 20

Given a time of 8, the current code would return a bufferedAhead of 2, when it should return 11.

I think something like this would fix it:

  var buffered = 0;
  var in_range = false;
  for (var i = 0; i < b.length; ++i) {
    if (time + fudge >= b.start(0) && time < b.end(i)) {
      buffered += b.end(i) - time;
      in_range = true;
    } else if (in_range) {
      buffered += b.end(i) - b.start(i)
    }
  }
  return buffered;

[joeyparrish]

I'm sorry, this is working as intended. It was never intended to jump gaps that browsers will not jump at play time.

Would changing this solve a problem for you? I'd be happy to discuss.

[baconz]

Thanks @joeyparrish. I was playing around with some video that had small gaps due to the PTS/DTS bug, and the behavior seemed unexpected. Given that some browsers can recover from small gaps, doesn't it seem like the player should acknowledge media that's buffered past a gap?

Is there an enhancement to be had here? I guess this is related to #180.

[joeyparrish]

Since we don't have any direct way to know how large a gap any given browser will jump, we can't really treat that media as buffered.

StreamingEngine only queries the buffered range when initializing or switching streams, though, so small gaps should not be a problem while streaming. Once streaming begins, segments are fetched and appended in order without examining the buffered range. If a gap can be jumped, it will, and StreamingEngine won't notice.

Where this breaks down is when you enter a buffering state (underflow). We don't exit that buffering state until a certain amount is buffered. Then we're checking the buffered range on an interval, and that condition may never be met due to the gap.

[baconz]

Yeah, this popped up when I seeked to a point just before the start of a period that introduced a gap.

The player would enter a buffering state, and it would never recover because it thought that it had nothing buffered ahead. Worse yet, it would try to buffer the same segments over and over again, which ultimately led to a QUOTA_EXCEEDED_ERROR. @joeyparrish can you think of a way to protect against this? It seems reasonable that somebody might accidentally introduce a gap, and the player shouldn't react by attacking your CDN with segment requests.

Do you see a problem with Shaka behaving optimistically and assuming that the browser will play through the gap? It seems like it should honor GAP_OVERLAP_TOLERANCE and treat buffered ranges with gaps smaller than that value as continuous.

[joeyparrish]

That's a good point. We definitely shouldn't be re-requesting the same segment over and over.

I don't see any reason we couldn't create a separate GAP_TOLERANCE constant in TimeRangesUtils, but give us some time to investigate. We need to make sure there's not some other pathology causing the repeated requests, and we need to make sure that ignoring small gaps will not cause some other problem elsewhere in the system.

[joeyparrish]

@baconz, we believe this is fixed now. Let us know if you have any further issues.

[baconz]

This looks great @joeyparrish. Thanks.

Wouldn't there still be a problem with getting into fetch-loops? Should a gap larger than GAP_TOLERANCE throw an error?

[joeyparrish]

We decided against throwing. There should be no fetch loop now that we have changed the way we compare against buffering goals.

[baconz]

Sweet, sounds good.

[ismena]

Commit that changes buffering goal comparison for reference.