PlayerView not appropriately sizing content to size of container

[vfutia]

In the last few months, I have started an effort migrating our player to use the media3 version of ExoPlayer instead of the legacy version. Almost everything is complete. However, I am noticing with the new player, the contents of the PlayerView does not seem to appropriately constrain itself to the size of it's parent container.

When a user is viewing content with an adaptive resolution, we give them the option to allow the content to adapt as normal (the default value) based on the network bandwidth. The user can also select a specific resolution if they want it to be fixed. If the user starts at the lowest resolution and changes the resolution to be higher and higher, the container is filled as expected eg. 360p -> 720p -> 1080p.

However, if the user starts at the higher end of the resolution range and goes down, you can see these ghosted looking images of the previous resolutions and the size of the content gets smaller and smaller. See the image below. eg. 1080p -> 720p -> 360p.

Does anyone know why this could be happening and what the potential fix is? I've provided a resize_mode="fit" param to the PlayerView in the XML and that didn't seem to work. I have also tried setVideoScalingMode(VIDEO_SCALING_MODE_SCALE_TO_FIT) when building my ExoPlayer instance and that also did not make a difference.

The container is fixed to a 16:9 aspect ratio. I cannot reproduce this with the old version of the player.

Any help would be appreciated.

[tianyif]

Hi @vfutia,

Thanks for reporting the issue!

I cannot reproduce this with the old version of the player.

Could you please let us know what is the version of ExoPlayer library you previously used, and the version of media3 library you're currently using?

[vfutia]

@tianyif We are currently using version 1.3.1 of the media3 library. Previously, we were using Exoplayer 2.18.2.

[vfutia]

One other piece of information, it seems like this is only happening with HLS. I cannot reproduce it with DASH.

[vfutia]

Another thing...

When I change tracks from 1080p to 360p, I see that the track selection parameters are set to 640 for width and 360 for height, as I would expect. But when the onVideoSizeChanged() callback gets triggered, the video width and height are 1920 and 1080, respectively.

[vfutia]

bump

[vfutia]

@oceanjules any news here?

[MGaetan89]

I didn't managed to reproduce this issue on my side with Media3 1.4.0-alpha02. @vfutia can you check on your side too?

[elfennani]

I still get this issue on from the new release 1.4.0, any workarounds?

[oceanjules]

@vfutia, as @MGaetan89 mentioned, could you please check the behaviour on the most recent release version?

If it does indeed persist, could you confirm that you used to use StyledPlayerView? What was the behaviour of the 1080->720->360 scaling down before? was the outer container scaling back with the background being black?

exo2	media3
PlayerControlView	LegacyPlayerControlView
StyledPlayerControlView	PlayerControlView
StyledPlayerView	PlayerView

In your current situation, do the ghost images remain as the last frame before the scale down? Or are those actually old surfaceViews that still have access to the Player? How do you ensure that the old container is actually destroyed/set to invisible? Rather than just a new one being redrawn on top?

[google-oss-bot]

Hey @vfutia. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@vfutia if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.