Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

@googlebot I fixed it!

@stuartmorgan / @creativecreatorormaybenot I've realized that while this modification fixes the playback speed issue it causes a negative side-effect. When an unbuffered range of the video stream is played back, the video player can lose volume (go mute) and become unstable. Once it gets in this state it does not recover. Therefore looks like there's still more work, unfortunately.

@alexagat if you take a look at my PR (#3404), it does fix the issue. Can we not just perform the same action on the native side?

Because at the end of the day, I am only making a method channel call..

When an unbuffered range of the video stream is played back, the video player can lose volume (go mute) and become unstable.

Does setting it back only for playbackLikelyToKeepUpContext work better, or is that already the only place it was being called in practice?

@alexagat if you take a look at my PR (#3404), it does fix the issue.

It is very likely that your approach would racily have the same behavior. There's no guarantee that some fraction of 500ms is enough time to create sufficient buffer to avoid an overrun.

@creativecreatorormaybenot you are correct your PR does fix this issue on the iOS platform and does not add any of the negative side-effects the native fix above introduced. I played around for a bit but didn't come up with a native-only solution here. For now I've added your code to my fork so we can patch this issue for users.

@alexagat yeah, that is what we are also doing in production, using our own fork of the plugin.

If there's no way to automatically handle this in the plugin that doesn't have the potential to cause playback issues, the other option would be to add an event that would report playback speed changes back to the Dart side, so that UIs could update, and users could change it back themselves.

But I would expect that there's a way to determine the relevant state to handle this correctly. Does observing timeControlStatus give any indication as to what's happening?

@stuartmorgan I have one concern with this part:

If there's no way to automatically handle this in the plugin that doesn't have the potential to cause playback issues, the other option would be to add an event that would report playback speed changes back to the Dart side, so that UIs could update, and users could change it back themselves.

You were saying that my fix was a hack. But your proposal is not? If I look at this from a different perspective, this means that users of the problem would need to integrate the hack (changing the playback speed after the change has been reported to the Dart side).
I see how this would be better in some odd way, but then again I really feel like this is even worse than just using the not-so-great fix because it also makes for a very bad API IMHO.

But I would expect that there's a way to determine the relevant state to handle this correctly.

That would be my preferred choice as well..

You were saying that my fix was a hack. But your proposal is not?

There are two possibilities here:

1. There is a reliable programatic way to determine when it is safe to automatically set the playback rate back to the desired value. If there is, we should do that.
2. There is no reliable way to do it automatically, such that any attempt to do so may break playback in the way described above. In this case I don't see any alternative to simply communicating the state back to the UI so that users can control it.

Your PR was sort of attempting to do 1, but in a very hacky way. I'm saying that either we need to do 1 correctly, or if 1 is impossible we should do 2. If 2 is the only option it's not a hack, it a reflection of the limitations of the platform that the plugin is wrapping.

@alexagat Are you still planning on updating this PR based on the discussion above?

@stuartmorgan I am not planning to update this PR and it should probably be closed. I never got the iOS implementation to work as desired and ended up using the code change from #3404 to resolve the bug.

Which is why is still think it should be merged 👍 It is not perfect but the best from a cost <> value perspective.

Closing per the above; thanks for the investigation so far. This should serve as a good starting point for future attempts to fix the issue.