-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bandwidth rate restriction cannot be applied after playback started. #1533
Comments
"Hard" restrictions (the type you are setting with those example configuration calls) are applied at the following times:
They are only use by the player, and not by the They aren't, as far as I can tell, applied by default when configuration changes. If I am reading On another note, I'm not sure why the sample code you provided helps with the problem? |
Thank you for providing very detailed feedback. I really appreciated. To be honest, I did not really take too much attention on abr.restrictions since I was mainly using 'hard' restrictions to configure the player. However, it sounds a bit code redundancy for me. If the abrManager already restricts the variants, I am curious why do you keep 'hard' restrictions? First I thought it may be a reason that shaka player cannot revert restrictions due to the the periods are already filtered. However, this should not be the case. Otherwise, my workaround would not have worked. Then, I checked some comments. Based on this explanation and this one , I may see that you do not want to interrupt playback even though the restrictions filtered out all variants. For this case, shaka player can still filtered out all restricted variants and keep one variants which is playable. Or you can only keep one restriction configuration and you may add a Anyway, I still think 'hard' restrictions should be applied during the playback. However, it is not a big deal since I am able to apply 'soft' restrictions, but I believe this might be confusing for other users in the future. As for my solution, I thought some variables which are Thank you. |
For more information on restrictions, you can see the docs for player configuration. The short version is that the "soft" restrictions aren't as absolute; for instance, if you apply a "soft" restriction to bandwidth that is below the bandwidth of every variant, the abr manager will just default to picking the lowest-bandwidth variant, even though it's technically restricted. If that was a "hard" restriction, on the other hand, the player would be completely unable to pick a stream, and would error. Sometimes that behavior is desirable, sometimes it's not, so we retain both types of restrictions. Maybe I should add an FAQ entry about how restrictions work? It's a pretty confusing distinction. One interesting thing to note is that the |
I'm also curious about the purpose of soft restrictions in ed0f37b . Why allow ABR to pick a variant if all are restricted? |
@chrisfillmore We should, probably, rename them to preferences or something.
The data savers thing references in the commit msg is basically "if the data saving mode is on, make every attempt to play lower bandwidth video before going for higher res and wasting precious data". |
It used to be the case (I think) that restrictions would be reapplied when the config changed. So this may be a regression. Also, to clarify an earlier discussion, "soft" ABR restrictions only apply to ABR logic. Tracks restricted at that level can still be selected manually via |
I attempted to cherry-pick this bug fix to v2.4.5, but the merge conflicts were too complex to fix up. So this bug fix will not appear in a release until v2.5.0-beta2. We apologize for the inconvenience. |
Released in v2.5.0-beta2. |
Have you read the FAQ and checked for duplicate open issues?:
Yes
What version of Shaka Player are you using?:
latest master or 2.4.3
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?:
demo app
If custom app, can you reproduce the issue using our demo app?:
What browser and OS are you using?:
chrome and macOS
What are the manifest and license server URIs?:
Does not matter. You may check tears of steel(widevine) sample.
What did you do?
I did set max bandwidth rate after playback started. However, the restrictions cannot be applied to abrManager even though restrictions applied to configuration object.
For instance, call before playback.
shakaDemo.localPlayer_.configure({ restrictions: { maxBandwidth: 500000 } });
Then play the content and call:
shakaDemo.localPlayer_.configure({ restrictions: { maxBandwidth: Infinity } });
What did you expect to happen?
The restriction should be applied to abrManager.
What actually happened?
The restriction could not be applied and abrManager only played variants by restricted of the previous value.
Note: The issue is fixed if I add this change at this block
I don't mind to create a PR if this change is appropriate for this fix. Thank you.
The text was updated successfully, but these errors were encountered: