8000 Crop mode (VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING) not applied on first loop · Issue #2344 · androidx/media · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Crop mode (VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING) not applied on first loop #2344

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

Open
1 task
aneesh1122 opened this issue Apr 16, 2025 · 4 comments
Open
1 task

Comments

@aneesh1122
Copy link

Version

Media3 main branch

More version details

No response

Devices that reproduce the issue

Mi 11x Android 12

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

  1. Set up an ExoPlayer instance with videoScalingMode = VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING.

  2. Set repeatMode = Player.REPEAT_MODE_ONE so the video loops.

  3. Assign the player to a PlayerView with resizeMode = RESIZE_MODE_FILL.

  4. Provide a standard MP4 video that is vertical (e.g., 9:16), but does not match the device’s screen aspect ratio.

  5. Observe playback:

  6. On the first loop, the video appears stretched or not cropped correctly.

  7. On the second loop and onwards, the video suddenly displays properly (cropped as expected).

Note: My player supports both HLS and MP4, but this issue is being seen specifically with an MP4 file.

Expected result

The video should be cropped correctly (zoomed and centered) to fill the PlayerView from the very first loop, honoring both VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING and RESIZE_MODE_FILL.

There should be no difference in video display between the first loop and subsequent loops.

Actual result

On the first loop, the video appears stretched, misaligned, or not cropped properly — as if the scaling or aspect ratio hasn’t been applied yet.

From the second loop onwards, the video suddenly displays correctly, cropped and zoomed as expected.

Example setup:

Inside a Jetpack Compose app, create an ExoPlayer instance using:
exoPlayer.videoScalingMode = C.VIDEO_SCALING_MODE_SCALE_TO_FIT_WITH_CROPPING

Set repeat mode:
exoPlayer.repeatMode = Player.REPEAT_MODE_ONE

Assign the player to a PlayerView inside an AndroidView, and set:
playerView.resizeMode = AspectRatioFrameLayout.RESIZE_MODE_FILL

Use an .mp4 source video that is vertical (e.g., 9:16), but does not match the device’s screen aspect ratio, such as 9:20.

Media

Not applicable

Bug Report

@oceanjules
Copy link
Contributor

I think there is quite a lot going on. Let's start with:

  • You mention "Jetpack Compose app" and "PlayerView" - so you are using AndroidView to wrap PlayerView which was not optimised to be used with Compose. However, we've had examples where people got it to work, so we can definitely investigate.
  • RESIZE_MODE_FILL is documented to be "ignoring the aspect ratio". Is this what you were actually going for?
    /** The specified aspect ratio is ignored. */
    public static final int RESIZE_MODE_FILL = 3;
  • The repeat mode should have no effect on the aspect ratio, so let's eliminate it from the minimal repro
  • I am not sure why you are using ExoPlayer's videoScalingMode? From what I can see in the code, that goes into codecs and renderers and you probably just want to FIT your video in the parent container. I suggest you start with removing the videoScalingMode setup and trying RESIZE_MODE_FIT and RESIZE_MODE_ZOOM resize modes on PlayerView.
  • Another thing to mention is that you could take some inspiration from our Compose demo app to see how even with a natively Compose component, there might still be this "stretching" flicker on the first Composition. One solution is to cover the surface with a solid shutter and uncover it when the rendering is ready (see: PresentationState.coverSurface). You can also read more about why we get the video size "slightly too late" to ensure the container is the correct aspect ratio here: Support Player$Listener.onVideoSizeChanged() to be called before Player.setVideoSurface() or Player.setsetVideoTextureView() #2066.

@aneesh1122
Copy link
Author
  • You mention "Jetpack Compose app" and "PlayerView" - so you are using AndroidView to wrap PlayerView which was not optimised to be used with Compose. However, we've had examples where people got it to work, so we can definitely investigate.

Yes

  • RESIZE_MODE_FILL is documented to be "ignoring the aspect ratio". Is this what you were actually going for?

Not really but I'm forced to use this. More details below

  • The repeat mode should have no effect on the aspect ratio, so let's eliminate it from the minimal repro

I just included that info because the video is cropped properly in the second loop

  • I am not sure why you are using ExoPlayer's videoScalingMode? From what I can see in the code, that goes into codecs and renderers and you probably just want to FIT your video in the parent container. I suggest you start with removing the videoScalingMode setup and trying RESIZE_MODE_FIT and RESIZE_MODE_ZOOM resize modes on PlayerView.

I initially used RESIZE_MODE_ZOOM but I'm using this player inside a horizontal pager and the video being played in the page was bleeding to the adjacent pages so I decided to crop the video first and use RESIZE_MODE_FIT.

@oceanjules
Copy link
Contributor

I just included that info because the video is cropped properly in the second loop

Oh, sorry, I get it now! I thought by "loop" you meant "recomposition" rather than a repeat loop. That's actually pretty weird..

I'm using this player inside a horizontal pager and the video being played in the page was bleeding to the adjacent pages

This is actually an important detail because we've been having some issues with AspectRatioFrameLayout inside AndroidView which is also inside horizontal pager or LazyColumn/LazyRows due to some reusing of the surface on their side. Maybe quite similar to: #1107 and #2018

What is strange is that you are experiencing it on Android 12 whereas it should only be Android 14 glitch. Can I ask you to try your code on some other devices with API levels of 30, 31, 33, 35 first.

If it still doesn't work, please send us a MainActivity.kt with as minimal of a setup as possible and we will try to locally reproduce and look into it.

@google-oss-bot
Copy link
Collaborator

Hey @aneesh1122. 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants
0