Black Screen flicker on first quality upswitch

[matamegger]

Version

Media3 1.4.1

More version details

Also reproduced on 1.5.0

Devices that reproduce the issue

Some Android TV devices:

• Multiple Sony Bravia
• Sharp 4K Android TV

Devices that do not reproduce the issue

No phone has been identified.
Android TVs:

• NVIDIA Shield
• Xiaomi Mi Box

Reproducible in the demo app?

Yes

Reproduction steps

1. Play an affected asset
2. Make sure to start with a low resolution (< HD track)
3. Switch from low resolution to the highest resolution (>= HD track)
   • Observable for ABR initiated switches, as well as "forced" switches

Expected result

Last frame of the previous track is hold by the surface and next frame is of the high resolution track

Actual result

On the first switch form the low to high resolution track:

• Last frame of the previous track is held in the surface for a moment
• Surface is black for a noticeable duration (in the order of ~250ms)
• Playback starts again and frames of the higher resolution is rendered as expected

If switching down and up again later on, the black "flicker" is not present in the same playback session.

More context and insights:

We initially noticed the behaviour on a DRM protected streams, where the track switch also included a DRM key switch (i.e. it's a multi DRM-Key stream). We could find a non-protected stream (shared via e-mail) with the same observable behaviour i.e. black screen on switching from low to high resolution and working around the issue with the same workarounds.

Workarounds that work:

• Forcing the player to start with a high resolution track will avoid the black screen for the playback session (at the potential cost of higher VST of course)
• When using a TextureView instead of a SurfaceView, the black flicker is not observed.

Workarounds that do not work:

• Forcing codec reusing (reusing with/without reconfiguration/flushing)
• For the DRM asset: Prefetching the second DRM session before the switch

Media

Media link and bugreport send via email.

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[tonihei]

The black screen itself is something we've seen on a number of devices when re-creating a secure codec or switching from a secure to a non-secure codec. The exact behavior of the switch is unfortunately not enforced or defined. See for example #1158 and google/ExoPlayer#8568 and others (internal ref: b/189441635). The usual workaround is to ensure the secure codec can be kept and doesn't need to be recreated. We had a bug that was fixed in 1.4.0 where codec re-creation was accidentally caused by diferences in color profiles (#1158), but given you observe this on 1.4.1 and 1.5.0, the codec may be recreated for other reasons.

Having said that, it looks like the codec in your bugreport is just flushed, not recreated. The fact that this happens on the fist upswitch makes me wonder though if the codec internally recreates some buffers that haven't been allocated in the right size for the larger resolution or similar. And then in wrongly clears the visible output while doing that. None of the codec logs in the bugreport looks particularly suspicious to me.

Have you tried reporting it to MStar (for the OMX.MS.AVC.Decoder) or Sony? They may be able to provide fixes for the decoder.

[There is also an internal bug b/249249589 where the same codec was reported to show frames on another device, unfortunately without a proper investigation or resolution from the manufacturer]