-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Video freeze when seekTo is called after midroll ads #10274
Comments
Can you provide a little more information about your setup? Specifically:
|
DRM creation
MediaSource creation
AdsMediaSource creation
our AdsMediaSourceFactory
|
Are you able to try depending on ExoPlayer locally? If so please try applying this patch on top of r2.17.1 and see if it fixes the issue. We think there's a theoretical problem with the way we handle seeking after a format switch (like ad -> content) in DRM content - but we've not been able to reproduce a problem at all in our demo app. We're reluctant to submit the fix to the library without being able to directly see it fix something - so since you seem to have a repro case it would be great if you could report back with your findings (either to let us know that it worked, or that it didn't make a difference (or that it made things worse!)). Thanks! |
`codecDrainAction` is set to `DRAIN_ACTION_NONE` in 3 places in `MediaCodecRenderer`: * The constructor (so there's no prior state to worry about) * `updateDrmSessionV23()`: Where `mediaCrypto` is reconfigured based on `sourceDrmSession` and `codecDrmSession` is also updated to `sourceDrmSession`. * `resetCodecStateForFlush()`: Where (before this change) the action is unconditionally set back to `DRAIN_ACTION_NONE` and so any required updated implied by `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` is not done. This change ensures that `flushOrReleaseCodec()` handles `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` before calling . This probably also resolves Issue: google/ExoPlayer#10274 #minor-release PiperOrigin-RevId: 454114428
`codecDrainAction` is set to `DRAIN_ACTION_NONE` in 3 places in `MediaCodecRenderer`: * The constructor (so there's no prior state to worry about) * `updateDrmSessionV23()`: Where `mediaCrypto` is reconfigured based on `sourceDrmSession` and `codecDrmSession` is also updated to `sourceDrmSession`. * `resetCodecStateForFlush()`: Where (before this change) the action is unconditionally set back to `DRAIN_ACTION_NONE` and so any required updated implied by `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` is not done. This change ensures that `flushOrReleaseCodec()` handles `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` before calling . This probably also resolves Issue: #10274 #minor-release PiperOrigin-RevId: 454114428
I'm closing this because I hope it's fixed with the commit linked above, which will be included in the next release. |
@icbaker I sent a build for our qa team, but unfortunately, they haven't checked it yet as they have a lot of other work to do. They will be able to test it only next week. Please don't close the ticket now, I will write an update later. |
`codecDrainAction` is set to `DRAIN_ACTION_NONE` in 3 places in `MediaCodecRenderer`: * The constructor (so there's no prior state to worry about) * `updateDrmSessionV23()`: Where `mediaCrypto` is reconfigured based on `sourceDrmSession` and `codecDrmSession` is also updated to `sourceDrmSession`. * `resetCodecStateForFlush()`: Where (before this change) the action is unconditionally set back to `DRAIN_ACTION_NONE` and so any required updated implied by `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` is not done. This change ensures that `flushOrReleaseCodec()` handles `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` before calling . This probably also resolves Issue: #10274 #minor-release PiperOrigin-RevId: 454114428 (cherry picked from commit c736a72)
`codecDrainAction` is set to `DRAIN_ACTION_NONE` in 3 places in `MediaCodecRenderer`: * The constructor (so there's no prior state to worry about) * `updateDrmSessionV23()`: Where `mediaCrypto` is reconfigured based on `sourceDrmSession` and `codecDrmSession` is also updated to `sourceDrmSession`. * `resetCodecStateForFlush()`: Where (before this change) the action is unconditionally set back to `DRAIN_ACTION_NONE` and so any required updated implied by `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` is not done. This change ensures that `flushOrReleaseCodec()` handles `DRAIN_ACTION_FLUSH_AND_UPDATE_DRM_SESSION` before calling . This probably also resolves Issue: google/ExoPlayer#10274 #minor-release PiperOrigin-RevId: 454114428 (cherry picked from commit 222faa9)
@icbaker I've received info from ous QAs. The bug is not reproducible with this approach. Thanks! |
@icbaker Could you tell me when the next release will be? |
Our QA team observes the same bug - #7161
When we call Player.seekTo() method a video freezes and the player doesn't react to any media event. It's very hard to reproduce, on my devices it happens 1 time out of 1000.
We use the latest 2.17 version of the Player. There are no deprecated classes in our code. Timeouts are set by default.
It happens for any ads, even for ads from this list https://developers.google.com/interactive-media-ads/docs/sdks/html5/client-side/tags
Do you have any ideas about what can be a root cause? Any possible fix or workaround?
The text was updated successfully, but these errors were encountered: