Shaka-player: Conditionally abort requests when downgrading

[kuznetcoff777]

Have you read the FAQ and checked for duplicate issues: yes

What version of Shaka Player are you using: latest master

Can you reproduce the issue with our latest release version: yes

Can you reproduce the issue with the latest code from master: yes

Are you using the demo app or your own custom app: custom

If custom app, can you reproduce the issue using our demo app: hard to me to check it on demo

What browser and OS are you using:chrome

What are the manifest and license server URIs: sent to gmail
(you can send the URIs to [e-mail] instead, but please use GitHub and the template for the rest)

What did you do?Opened stream, watched highest bitrate, then in chrome console made network 450 kbit/s

What did you expect to happen? Player should turn to SD content and not to stall

What actually happened? Player attempted to download the highest bitrate fragment, it was very slow, up to 15-20 seconds. In our confiuration (fragments=10seconds, suggestet presentation delay is 20, minbuffertime=10, buffering goal=10, rebufferinggoal=2). When we watch live content, with this configuration we have 30 seconds buffer ahead (am i correctly undestand that it equal "suggestet presentation delay" + "buffering goal"?). If i fall bandwith to 450kbit here is what happens:
-player have 30 seconds of buffer ahead
-10 secodns passed and player attempts to download new segment (20 seconds of buffer left)
-ABR did not get that speed is very slow and still try to download highets bitrate fragment, so it takes more then 10 seconds
-At tenth second of downloading fragment there is in buffer left 10 seconds of playable content and it reached minbuffertime=10, so player stalls in buffering, as i remember only next frament is downloaded as SD.

Is there any way to improve ABR? Maybe it is necessary to look how in DASHif its made (at least they have abandon rule and i also described how to imrpove their rule https://github.com/Dash-Industry-Forum/dash.js/issues/1382)

P.s. In FAQ https://github.com/google/shaka-player/blob/master/docs/tutorials/faq.md there is mention about "Why does it take so long to switch to HD?", defaultBandwidthEstimate is 500kbit in our case, but in this case it does not help anyway, because player have enough info about bandwith.

[joeyparrish]

Shaka Player, for simplicity, does not have a way to abandon in-flight requests when switching resolutions. Our bandwidth estimate is also based on the time to download full segments, so AbrManager may not recognize the need to switch until after a request has completed very slowly.

To improve that, we would need to:

• build bandwidth estimate based on progress events during transfer
  
  
  
  • but we'd have to be careful about how this affects #829 for switching from XHR to Fetch API
  
  
• abort requests when switching to a lower bitrate stream
  
  
  
  • but we'd have to be careful about the conditions for aborting a request. We could perhaps estimate the time needed to complete the request and factoring that into the decision. Aborting at 99% complete, for example, may hurt buffering overall.
  
  

As a side note, presentation delay has no bearing on the buffering goal. In your scenario, you would buffer ahead a minimum of 10 seconds. If the number falls to 9.9999..., we would fetch another segment. Given the 10-second segment size, at any given time, you may have up to 20 seconds buffered.

[joeyparrish]

Renamed and scheduled for v2.4 as an enhancement. Thanks for filing!

[kuznetcoff777]

" In your scenario, you would buffer ahead a minimum of 10 seconds. If the number falls to 9.9999..., we would fetch another segment. "
If the number falls to 9.9999 - do you mean if segment size changed from 10 seconds to 9.9999?

Anyway i dont get what buffergoal is doing in our case? We attempted to change it to 100, but still no change, bufferered about 30 seconds ahead, it seems to that in live content some other rule persist.

[joeyparrish]

No, I mean if the amount of media buffered ahead of video.currentTime is less than 10, we fetch another segment.

The effect of presentation delay is to say that "this amount of content exists on the server, but don't show it to the user yet." So a delay of 20 means there are 20 seconds of content past the user-visible "live edge" that could be buffered ahead of time. This is why you can't buffer more than 30 seconds ahead, no matter how large your buffering goal is. Content beyond that in the live stream isn't available to the client yet.

[kuznetcoff777]

So buffer ahead is only configurable via suggested presentation delay, right? Negative side of it - is that we go far from live, as i understand.

So i still dont get why presentation delay is 20 sec, but we can buffer up to 30 seconds, is it related to your words about 9.9999?

[joeyparrish]

Correct. In a live stream, you can't buffer ahead at the edge more than 1 segment + presentation delay, because nothing else is available.

I'd have to analyze your content to see why you are getting 30 seconds. If that is concerning, please open a separate issue for that. I'd like to leave this one focused on the enhancement in https://github.com/google/shaka-player/issues/1051#issuecomment-334221660 about aborting requests when switching resolutions. Thanks!

[joeyparrish]

Things to do:

• Get progress events from XHR in NetworkingEngine plugin
• Get progress events from Fetch in NetworkingEngine plugin
  
  
  
  • If there's no progress events in Fetch yet, we need to stop preferring it to XHR and file a spec bug
  
  
• StreamingEngine needs to abort segment requests in progress if the video bandwidth is downgraded
  
  
  
  • We might need some policy to decide when to abort. For example, if we're 99% done with a request when we downgrade, better to finish downloading that segment. The best behavior would be to have an ETA for each request, and compare that to bufferedAhead to decide whether or not to abort.
  
  

[joeyparrish]

First part of the implementation landed. Quoting @TheModMaker from an internal review, we still need to add tests to verify that:

• XHR (and eventually fetch) plugins raise progress events
• Calling the callback from the plugin calls the function that is given to NetworkingEngine constructor
• Calling the progress handler for non-SEGMENT requests does nothing
• NetworkingEngine will call the progress handler if it doesn't get any calls from the plugin