Android v3 player random readyness issue at stream startup

Support
1

Dear Bitmovin community,

Since our recent migration from Bitmovin Android player v2 to v3 we have discovered a random readyness issue of the Bitmovin player, including with latest v3.25.1
When the problem is triggered the player is NOT reporting back “Ready” even with a generous 30s of timeout.
No error is thrown, it is just hanging.

The issue is :

  • not device specific

  • not Android version specific

  • not related to DRM

  • not related to HTTPs

  • not related to specific CDNs (also duplicated with Akamai tears of steel)

  • affecting both Live and VOD streams

  • Manifest got downloaded and parsed correctly

  • Audio and Video 1st chunks got buffered

  • No audio or video got decoded/rendered

  • Affected customers are usually impacted once and then a retry will work.

  • Only tested against DASH Manifests

  • Issue could be duplicated with Bitmovin demo sample running in 10s loop

  • Issue can NOT be duplicated with Exoplayer (same 10s loop, same setup)

  • Bitmovin support cannot duplicate it with emulator or with their device yet.

I could not find similar issue in the community yet. Is-it known somewhere ?
What would be your suggestion to troubleshoot / fix this issue ?

Thanks for your help,
Nicolas

1 Like
2

Hi Nicolas,
We haven’t heard about this issue from any other customer so far. Can you reproduce this with any content? I.e. if you use simply bitmovin-player-android-samples/BasicPlaybackKotlin at main · bitmovin/bitmovin-player-android-samples · GitHub as is (adding your license key and potentially the 10s loop you mention), you can reproduce the problem?

Also, what do you do in the 10s loop, simply reloading the same stream into the player? Or creating a new player instance? Can you share any sample code please?

1 Like
3

Hi Daniel,
Thanks for your feedback, we can duplicate this issue with any content from any CDN, including Bitmovin sample.
We are already using Bitmovin player android samples for this test and we have shared our source code with Alberto Cabaleiro on the ticket 10687.
It seems the problem is now understood by your team (video decoder flush) and a fix is under preparation.
:crossed_fingers:

1 Like
4

True, Alberto and I discussed this internally after my post here, I missed updating this thread. Thanks for the update :+1:

5

Hi Nicolas,

Just a quick clarification here: At this stage we suspect of potential issues at decoder level only on very specific devices such as Swisscom STB (not officially supported by the way), but it hasn’t been confirmed yet and there’s no ongoing fix from our end. As discussed on the ticket you mention, we’re still looking forward to your results when running our modified demo app on your end on Swisscom STB. When running that app on a Swisscom STB on our end, the issue can no longer be reproduced, which points to issues on the way you are/were initializing the player on your app.

Also, I’d like to clarify that the above only applies to Swisscom STB devices. For any other affected device, the investigation is still ongoing.

1 Like
6

Update on this issue: we have applied the recommanded mitigations from Bitmovin support :

  • force initialBandwidthEstimateOverride to 2Mbps to ensure the player will decode SD resolution first and then trigger ABR to HD
  • destroy the player after each usage.
    It’s helping to fix one problem detected in our lab but the field the is still seriously affected by “this player readyness” issue.
    Stay tuned.

Nicolas

1 Like