SurfaceView inside Compose AndroidView often shown stretched/cropped on API 34 #1237

MykolaKosianchuk · 2024-04-02T12:53:27Z

Version

Media3 main branch

More version details

1.3.0, 1.2.1, 1.1.1

Devices that reproduce the issue

Pixel running on Android 14 with updated to 5 March 2024 (important)

Devices that do not reproduce the issue

Pixel running on Android 14 without updated to 5 March 2024

Reproducible in the demo app?

Not tested

Reproduction steps

Here is code that could help to reproduce.

class MainActivity : ComponentActivity() {
    @OptIn(UnstableApi::class)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            val context = LocalContext.current

            val exoPlayer = remember { ExoPlayer.Builder(context).build() }

            DisposableEffect(Unit) {
                onDispose {
                    exoPlayer.release()
                }
            }

            Box(
                modifier = Modifier
                    .fillMaxWidth()
                    .fillMaxHeight(0.5f) //important to have
//                    .height(500.dp) - also reproducible
                    .background(Color.Black),
                contentAlignment = Alignment.Center
            ) {
                AndroidView(
                    factory = { ctx ->
                        PlayerView(ctx).apply {
                            useController = false
                            resizeMode = AspectRatioFrameLayout.RESIZE_MODE_ZOOM
                        }
                    },
                    update = {
                        it.player = exoPlayer
                        exoPlayer.setMediaItem(
                            MediaItem.fromUri("https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4")
                        )
                        exoPlayer.playWhenReady = true
                        exoPlayer.prepare()
                    },
                )
            }
        }
    }
}

Expected result

Media should be visible correctly

Actual result

Media shows with a wrong aspect ratio

Media

Here is how it looks

Bug Report

You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

The text was updated successfully, but these errors were encountered:

phcannesson · 2024-04-03T08:53:00Z

+1 this
We've spent days trying to understand issues we have with Android 14 devices recently.
Going back to our previous app versions doesn't fix anything, so we came up with the same conclusion as @MykolaKosianchuk , it's probably related to a recent Android patch.

MykolaKosianchuk · 2024-04-03T08:56:57Z

@phcannesson Yes, we found this issue and tried to reproduce it on the device without the last patch but we can't. However, once we updated the phone, the issue appeared.

harry248 · 2024-04-03T14:12:48Z

We have the same problem. We had already observed this in the QPR but unfortunately did not create an issue. Interestingly, we "only" have the problem if we use the AndroidView (which creates the PlayerView) in an if block, i.e. the composable is not called immediately.

icbaker · 2024-04-08T07:34:26Z

Reproducible in the demo app?

Not tested

Please can you test this? It would help us to debug if we know whether it can be reproduced in the demo app.

Interestingly, we "only" have the problem if we use the AndroidView (which creates the PlayerView) in an if block, i.e. the composable is not called immediately.

Is this true for everyone else that has commented on this bug? Is everyone else experiencing this only in Compose contexts, or also in conventional views? This looks like it might be a duplicate of #1123 but it's interesting to hear that the behaviour changes between Android 14 before the March 5th update and after it.

phcannesson · 2024-04-08T07:42:03Z

Reproducible in the demo app?

Not tested

Please can you test this? It would help us to debug if we know whether it can be reproduced in the demo app.

Interestingly, we "only" have the problem if we use the AndroidView (which creates the PlayerView) in an if block, i.e. the composable is not called immediately.

Is this true for everyone else that has commented on this bug? Is everyone else experiencing this only in Compose contexts, or also in conventional views? This looks like it might be a duplicate of #1123 but it's interesting to hear that the behaviour changes between Android 14 before the March 5th update and after it.

On our side we're using Compose.
We did not test with conventional views.

promanowicz · 2024-04-08T08:10:01Z

I have faced exact same issue, except I was using resizeMode with fixed height.
I addition I have noticed that the video gets right aspect ratio after I switched orientation to landscape and then back to portrait.

MykolaKosianchuk · 2024-04-08T08:14:16Z

@icbaker It is not reproducible in the demo app
Looks like it is related to the compose

speedclaud · 2024-04-11T10:18:12Z

Hi @icbaker , I was also not able to reproduce the issue on your demo app on Pixel 7, Android 14, march 5th update, but we have the issue in our compose app using AndroidView. The issue is present in this sample app that uses compose, (press on the "Exo PlayerView" button):

compose-media.zip

This is what it looks like:

phcannesson · 2024-04-11T11:50:05Z

On our side, after some testing, we've detected that it seems to be related to the way the frame layout gets notified of changes in the player.
We've successfully "fixed" the issue by adding some delay before displaying the AndroidView.
That apparently allows the player to be fully ready when the view is loaded.

speedclaud · 2024-04-11T12:20:10Z

On our side, after some testing, we've detected that it seems to be related to the way the frame layout gets notified of changes in the player. We've successfully "fixed" the issue by adding some delay before displaying the AndroidView. That apparently allows the player to be fully ready when the view is loaded.

I've tried adding a delay to the sample app above (with a boolean mutable state and a LaunchedEffect), but the stretch is still present when It shows.

speedclaud · 2024-04-11T13:12:03Z

I found a "fix", the stretch is gone when using app:surface_type="texture_view". So I assume there's something wrong with app:surface_type="surface_view" inside AndroidView on the latest android?

Is it true that texture_view drains more battery?

icbaker · 2024-04-11T14:02:34Z

Thanks for the repro app in #1237 (comment). I ran this on a Pixel 7a running lynx-userdebug AP1A.240405.002 and observed the problematic behaviour shown in your screenshot nearly every time (the first time i launched the app it seemed to work OK, but the subsequent ~10 times it shows the problem - even after swiping the app away from recents, and clearing app data).

I added an EventLogger (https://developer.android.com/media/media3/exoplayer/debug-logging) and grabbed the logcat filtered to EventLogger of a problematic repro.

I then flashed my device back to before the March feature release, to lynx-userdebug UQ1A.240205.002 and installed the app. The first time I launched the video it played fine. I grabbed the same filtered logcat, and diffed it against the problematic behaviour. Then subsequent launches of the video (without dismissing the app) showed the problem (and I grabbed the logcat). Swiping the app away and re-launching it seems to allow the playback to work correctly once, then subsequent launches are problematic.

I observed the following in logcat right at the start of playback in the problematic case on AP1A.240405.002:

timeline [eventTime=0.02, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
mediaItem [eventTime=0.02, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
state [eventTime=0.02, mediaPos=0.00, window=0, BUFFERING]
surfaceSize [eventTime=0.06, mediaPos=0.00, window=0, 0, 0]
surfaceSize [eventTime=0.08, mediaPos=0.00, window=0, 1080, 1080]
timeline [eventTime=0.09, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
positionDiscontinuity [eventTime=0.10, mediaPos=0.00, window=0, reason=REMOVE, PositionInfo:old [mediaItem=0, period=0, pos=0], PositionInfo:new [mediaItem=0, period=0, pos=0]]
mediaItem [eventTime=0.10, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
loading [eventTime=0.11, mediaPos=0.00, window=0, true]
timeline [eventTime=0.11, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [?]
  window [?, seekable=false, dynamic=false]
]
timeline [eventTime=1.15, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [634.40]
  window [634.40, seekable=true, dynamic=false]
]
videoEnabled [eventTime=1.16, mediaPos=0.00, window=0, period=0]
tracks [eventTime=1.16, mediaPos=0.00, window=0, period=0
  group [
    [X] Track:0, id=1, mimeType=video/av01, res=854x480, fps=29.999998, supported=YES
  ]
]
downstreamFormat [eventTime=1.16, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoDecoderInitialized [eventTime=1.20, mediaPos=0.00, window=0, period=0, c2.google.av1.decoder]
videoInputFormat [eventTime=1.21, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoSize [eventTime=1.33, mediaPos=0.00, window=0, period=0, 854, 480]
renderedFirstFrame [eventTime=1.34, mediaPos=0.00, window=0, period=0, Surface(name=null)/@0xe4d0ed2]
surfaceSize [eventTime=1.35, mediaPos=0.00, window=0, period=0, 1080, 607]
state [eventTime=1.36, mediaPos=0.02, window=0, period=0, READY]
isPlaying [eventTime=1.36, mediaPos=0.02, window=0, period=0, true]
loading [eventTime=1.91, mediaPos=0.56, window=0, period=0, false]
loading [eventTime=3.42, mediaPos=2.08, window=0, period=0, true]
loading [eventTime=3.48, mediaPos=2.14, window=0, period=0, false]

The same part of logcat in the working case on UQ1A.240205.002:

timeline [eventTime=0.03, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
mediaItem [eventTime=0.03, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
state [eventTime=0.03, mediaPos=0.00, window=0, BUFFERING]
surfaceSize [eventTime=0.07, mediaPos=0.00, window=0, 1080, 1080]
timeline [eventTime=0.09, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
positionDiscontinuity [eventTime=0.09, mediaPos=0.00, window=0, reason=REMOVE, PositionInfo:old [mediaItem=0, period=0, pos=0], PositionInfo:new [mediaItem=0, period=0, pos=0]]
mediaItem [eventTime=0.09, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
loading [eventTime=0.11, mediaPos=0.00, window=0, true]
timeline [eventTime=0.11, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [?]
  window [?, seekable=false, dynamic=false]
]
timeline [eventTime=1.26, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [634.40]
  window [634.40, seekable=true, dynamic=false]
]
videoEnabled [eventTime=1.45, mediaPos=0.00, window=0, period=0]
tracks [eventTime=1.46, mediaPos=0.00, window=0, period=0
  group [
    [X] Track:0, id=1, mimeType=video/av01, res=854x480, fps=29.999998, supported=YES
  ]
]
downstreamFormat [eventTime=1.46, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoDecoderInitialized [eventTime=1.49, mediaPos=0.00, window=0, period=0, c2.google.av1.decoder]
videoInputFormat [eventTime=1.49, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoSize [eventTime=1.52, mediaPos=0.00, window=0, period=0, 854, 480]
surfaceSize [eventTime=1.52, mediaPos=0.00, window=0, period=0, 1080, 607]
renderedFirstFrame [eventTime=1.53, mediaPos=0.00, window=0, period=0, Surface(name=null)/@0xb940abd]
state [eventTime=1.53, mediaPos=0.00, window=0, period=0, READY]
isPlaying [eventTime=1.53, mediaPos=0.00, window=0, period=0, true]
loading [eventTime=2.29, mediaPos=0.76, window=0, period=0, false]
loading [eventTime=3.61, mediaPos=2.08, window=0, period=0, true]
loading [eventTime=3.67, mediaPos=2.15, window=0, period=0, false]

And finally, the problematic case on UQ1A.240205.002:

timeline [eventTime=0.02, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
mediaItem [eventTime=0.02, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
state [eventTime=0.02, mediaPos=0.00, window=0, BUFFERING]
surfaceSize [eventTime=0.06, mediaPos=0.00, window=0, 0, 0]
surfaceSize [eventTime=0.07, mediaPos=0.00, window=0, 1080, 1080]
loading [eventTime=0.08, mediaPos=0.00, window=0, period=0, true]
timeline [eventTime=0.08, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [?]
  window [?, seekable=false, dynamic=false]
]
timeline [eventTime=0.08, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
positionDiscontinuity [eventTime=0.08, mediaPos=0.00, window=0, reason=REMOVE, PositionInfo:old [mediaItem=0, period=0, pos=0], PositionInfo:new [mediaItem=0, period=0, pos=0]]
mediaItem [eventTime=0.08, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
timeline [eventTime=0.09, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [?]
  window [?, seekable=false, dynamic=false]
]
timeline [eventTime=1.30, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [634.40]
  window [634.40, seekable=true, dynamic=false]
]
videoEnabled [eventTime=1.31, mediaPos=0.00, window=0, period=0]
tracks [eventTime=1.31, mediaPos=0.00, window=0, period=0
  group [
    [X] Track:0, id=1, mimeType=video/av01, res=854x480, fps=29.999998, supported=YES
  ]
]
downstreamFormat [eventTime=1.31, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoDecoderInitialized [eventTime=1.36, mediaPos=0.00, window=0, period=0, c2.google.av1.decoder]
videoInputFormat [eventTime=1.36, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, fps=29.999998]
videoSize [eventTime=1.51, mediaPos=0.00, window=0, period=0, 854, 480]
renderedFirstFrame [eventTime=1.51, mediaPos=0.00, window=0, period=0, Surface(name=null)/@0x4a7b0d3]
surfaceSize [eventTime=1.53, mediaPos=0.00, window=0, period=0, 1080, 607]
state [eventTime=1.53, mediaPos=0.02, window=0, period=0, READY]
isPlaying [eventTime=1.54, mediaPos=0.02, window=0, period=0, true]
loading [eventTime=2.21, mediaPos=0.70, window=0, period=0, false]
loading [eventTime=3.60, mediaPos=2.08, window=0, period=0, true]
loading [eventTime=3.67, mediaPos=2.15, window=0, period=0, false]

There are two key differences between the working and problematic cases:

The problematic cases both have an additional surfaceSize [eventTime=0.06, mediaPos=0.00, window=0, 0, 0] before surfaceSize [eventTime=0.07, mediaPos=0.00, window=0, 1080, 1080]
The problematic cases both see renderedFirstFrame before surfaceSize [eventTime=1.52, mediaPos=0.00, window=0, period=0, 1080, 607], whereas in the working case the surfaceSize arrives before renderedFirstFrame.

phcannesson · 2024-04-11T15:42:18Z

I found a "fix", the stretch is gone when using app:surface_type="texture_view". So I assume there's something wrong with app:surface_type="surface_view" inside AndroidView on the latest android?

Is it true that texture_view drains more battery?

I can confirm that it seems to fix.

I've created a public repo to reproduce and play with the configuration :
https://github.com/phcannesson/AspectFrameLayoutDemo

The player with app:surface_type="texture_view" works well.

phcannesson · 2024-04-12T07:14:56Z

While digging in AOSP code, I've noticed this change :
https://cs.android.com/android/_/android/platform/frameworks/base/+/1b152e712159c0b82831a7567ce2f3c49cdc11bf
It apparently modified how SurfaceView is clipped.

It seemed to have been released in Android 14 QPR2.

It's a wild guess, but I thought it was worth mentioning.

icbaker · 2024-04-12T09:24:01Z

Trying the same video in the main ExoPlayer demo app on the same device + build (lynx-userdebug UQ1A.240205.002), I see the 'problematic sequence' in logcat (surfaceSize(0,0) near the start, and then renderedFirstFrame before surfaceSize), but not the problematic symptoms.

This is perhaps obvious, but it adds more weight to the theory that the problem is related to how AspectRatioFrameLayout (or perhaps SurfaceView) behaves specifically in a Compose context.

Full logcat:

playWhenReady [eventTime=0.00, mediaPos=0.00, window=0, true, USER_REQUEST]
surfaceSize [eventTime=0.00, mediaPos=0.00, window=0, 0, 0]
timeline [eventTime=0.00, mediaPos=0.00, window=0, periodCount=1, windowCount=1, reason=PLAYLIST_CHANGED
  period [?]
  window [?, seekable=false, dynamic=true]
]
mediaItem [eventTime=0.01, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
state [eventTime=0.01, mediaPos=0.00, window=0, BUFFERING]
surfaceSize [eventTime=0.04, mediaPos=0.00, window=0, 1080, 2219]
loading [eventTime=0.04, mediaPos=0.00, window=0, period=0, true]
timeline [eventTime=0.04, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [?]
  window [?, seekable=false, dynamic=false]
]
timeline [eventTime=0.77, mediaPos=0.00, window=0, period=0, periodCount=1, windowCount=1, reason=SOURCE_UPDATE
  period [634.40]
  window [634.40, seekable=true, dynamic=false]
]
videoEnabled [eventTime=0.79, mediaPos=0.00, window=0, period=0]
tracks [eventTime=0.79, mediaPos=0.00, window=0, period=0
  group [
    [X] Track:0, id=1, mimeType=video/av01, res=854x480, color=BT709/Limited range/SDR SMPTE 170M/8/8, fps=29.999998, supported=YES
  ]
  Metadata [
    TSSE: description=null: values=[Google]
    Mp4Timestamp: creation time=0, modification time=0, timescale=1000
  ]
]
downstreamFormat [eventTime=0.81, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, color=BT709/Limited range/SDR SMPTE 170M/8/8, fps=29.999998]
videoDecoderInitialized [eventTime=0.84, mediaPos=0.00, window=0, period=0, c2.google.av1.decoder]
videoInputFormat [eventTime=0.84, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/av01, res=854x480, color=BT709/Limited range/SDR SMPTE 170M/8/8, fps=29.999998]
videoSize [eventTime=1.07, mediaPos=0.00, window=0, period=0, 854, 480]
renderedFirstFrame [eventTime=1.07, mediaPos=0.00, window=0, period=0, Surface(name=null)/@0x12990bc]
surfaceSize [eventTime=1.09, mediaPos=0.00, window=0, period=0, 1080, 607]
state [eventTime=1.09, mediaPos=0.01, window=0, period=0, READY]
isPlaying [eventTime=1.10, mediaPos=0.02, window=0, period=0, true]
loading [eventTime=1.78, mediaPos=0.70, window=0, period=0, false]
loading [eventTime=3.17, mediaPos=2.09, window=0, period=0, true]

harry248 · 2024-04-12T09:32:56Z

While digging in AOSP code, I've noticed this change : https://cs.android.com/android/_/android/platform/frameworks/base/+/1b152e712159c0b82831a7567ce2f3c49cdc11bf It apparently modified how SurfaceView is clipped.

It seemed to have been released in Android 14 QPR2.

It's a wild guess, but I thought it was worth mentioning.

With QPR2 our QA also started to report the issue, so very likely related.

fpitterstv2 · 2024-04-17T10:54:44Z

We are seeing this now when migrating to compose :(
Using RESIZE_MODE_FIT inside a fillMaxSize composable

jdelga · 2024-04-17T11:06:22Z

This seems a duplicate of #1123

fpitterstv2 · 2024-04-18T08:27:31Z

Also reproducible on an emulator using VanillaIceCream

icbaker · 2024-04-19T13:12:52Z

I have filed an issue internally to ask for assistance from the Window Manager team (who own SurfaceView) and Compose folks: b/334901521

icbaker · 2024-06-14T16:42:22Z

I've done a bit more testing on different Android versions. This is on Pixel 7a and Pixel Fold (folded). My observations:

I haven't managed to repro on Android 13
On Android 14 before the March 2024 update (specifically I tested UP1A.231005.007 (the first stable Android 14 build) and UQ1A.240205.002.B1 (just before the March release))
- I observe the issue at a high repro rate (~90%)
- As soon as you tap on the playback to make the controls appear, the issue is resolved
On Android 14 after the March 2024 update (specifically I tested AP1A.240305.019.A1)
- The repro rate appears to be about the same
- Tapping the playback to make the controls appear doesn't resolve the issue

I suspect this may be why the issue has become more obvious since the March 2024 release. Before this point it was quickly resolved as soon as something else changed (in this case the controls appearing), but after this the problem persists.

This workaround is only applied on API 34, because the problem isn't present on API 33 and it is fixed in the platform for API 35 onwards. Issue: #1237 #cherrypick PiperOrigin-RevId: 644729909

icbaker · 2024-06-19T13:30:15Z

I've updated the title of this issue to reflect that this isn't specific to AspectRatioFrameLayout, and it's more related to SurfaceView inside a Compose AndroidView on Android 14.

With the support of the graphics team, I've also submitted a workaround (linked above) to PlayerView, which resolves this issue for users of this class. This will be included in 1.4.0-rc01. I'm going to close this issue, since that should resolve the issue for users of media3's UI components. Those who have written their own UI components may be able to adopt a similar workaround.

Previously we assumed that `surfaceSyncGroupV34` was always non-null on API 34, but this isn't true in edit mode. Instead we add an explicit null-check before accessing it. We don't need to null-check it at the other usage site because we are already null-checking `surfaceView` (via `instanceof` check). Issue: #1237 #cherrypick PiperOrigin-RevId: 645008049

This workaround is only applied on API 34, because the problem isn't present on API 33 and it is fixed in the platform for API 35 onwards. Issue: #1237 #cherrypick PiperOrigin-RevId: 644729909 (cherry picked from commit 968f72f)

Previously we assumed that `surfaceSyncGroupV34` was always non-null on API 34, but this isn't true in edit mode. Instead we add an explicit null-check before accessing it. We don't need to null-check it at the other usage site because we are already null-checking `surfaceView` (via `instanceof` check). Issue: #1237 #cherrypick PiperOrigin-RevId: 645008049 (cherry picked from commit 9980306)

kotya341 · 2024-07-29T13:57:43Z

Hello folks,
just want to share with you some updates.
after updating to the stable version of 1.4.0 I can still reproduce my problem from this ticket

devno44 · 2024-07-30T03:32:07Z

Is there any workaround for older versions ?
We can not change the ExoPlayer version right now, and can not use TextureView instead of SurfaceView.

icbaker · 2024-07-30T07:42:58Z

@devno44 In order to backport the code change to an older version of the library you will need to build your chosen version locally (media3 instructions, ExoPlayer 2.19.0 instructions), and then apply the changes in 968f72f and 9980306 to your local copy of the code (note that in the exoplayer2, the equivalent of media3's PlayerView is StyledPlayerView.

kotya341 · 2024-07-30T11:29:39Z

@oceanjules
could you please reopen our thread, I can't reply on it
This conversation has been locked and limited to collaborators.

icbaker · 2024-07-30T12:17:40Z

@kotya341 Looks like @tonihei has unlocked the thread and you should be able to reply - apologies for missing that when I re-opened it.

phcannesson · 2024-07-30T13:19:48Z

Should we also reopen this one or does 1.4.0 contain a valid fix ?

icbaker · 2024-07-30T13:49:07Z

@phcannesson This issue is fixed in 1.4.0-rc01. If you're experiencing similar problems on that version or later, please open a new issue with details & repro steps.

Omkar-Amberkar · 2024-08-02T19:48:53Z

@icbaker how would we be able to replicate your fix when we aren't using the PlayerView directly but instead use the AspectRatioFrameLayout and SurfaceView inside the AndroidView. I have created something similar in compose for our use case as below. let me know if this looks good

const val RESIZE_MODE_FIT = 0
const val RESIZE_MODE_FIXED_WIDTH = 1
const val RESIZE_MODE_FIXED_HEIGHT = 2
const val RESIZE_MODE_FILL = 3
const val RESIZE_MODE_ZOOM = 4

private const val MAX_ASPECT_RATIO_DEFORMATION_FRACTION = 0.01f

@Composable
fun Surface(
    modifier: Modifier = Modifier,
    aspectRatio: Float = 16f / 9f,
    resizeMode: Int = RESIZE_MODE_FIT,
    onSurfaceCreated: (SurfaceView) -> Unit = {},
    onSurfaceDestroyed: (SurfaceView) -> Unit = {},
) {
    val mainLooperHandler = remember { Handler(Looper.getMainLooper()) }
    val surfaceSyncGroupV34 = remember {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
            SurfaceSyncGroupCompatV34()
        } else {
            null
        }
    }
    AspectRatioLayout(
        aspectRatio = aspectRatio,
        resizeMode = resizeMode,
        modifier = modifier
            .drawWithContent {
                // Draw the existing content
                drawContent()

                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
                    surfaceSyncGroupV34?.maybeMarkSyncReadyAndClear()
                }
            },
    ) {
        Box {
            AndroidExternalSurface(
                content = { context, state ->
                    SurfaceView(context).apply {
                        state.onSurface { surface, width, height ->
                            onSurfaceCreated(this@apply)
                            surface.onChanged { width, height ->
                                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
                                    surfaceSyncGroupV34?.postRegister(
                                        mainLooperHandler,
                                        this@apply,
                                        this@apply::invalidate
                                    )
                                }
                            }
                            surface.onDestroyed {
                                onSurfaceDestroyed(this@apply)
                            }
                        }
                        holder.addCallback(state)
                    }
                }
            )
        }
    }
}

@Composable
private fun AspectRatioLayout(
    modifier: Modifier,
    aspectRatio: Float,
    resizeMode: Int,
    content: @Composable () -> Unit,
) {
    if (aspectRatio <= 0) return
    Layout(
        content = content,
        modifier = modifier
    ) { measurables, constraints ->
        var width = constraints.maxWidth
        var height = constraints.maxHeight
        val viewAspectRatio = width.toFloat() / height
        val aspectDeformation = aspectRatio / viewAspectRatio - 1
        if (abs(aspectDeformation) > MAX_ASPECT_RATIO_DEFORMATION_FRACTION) {
            when (resizeMode) {
                RESIZE_MODE_FIXED_WIDTH -> height = (width / aspectRatio).toInt()
                RESIZE_MODE_FIXED_HEIGHT -> width = (height * aspectRatio).toInt()
                RESIZE_MODE_ZOOM -> if (aspectDeformation > 0) {
                    width = (height * aspectRatio).toInt()
                } else {
                    height = (width / aspectRatio).toInt()
                }

                RESIZE_MODE_FIT -> if (aspectDeformation > 0) {
                    height = (width / aspectRatio).toInt()
                } else {
                    width = (height * aspectRatio).toInt()
                }
            }
        }

        layout(width, height) {
            val childConstraints = constraints.copy(
                minWidth = 0,
                minHeight = 0,
                maxWidth = width,
                maxHeight = height
            )
            measurables.forEach { measurable ->
                val placeable = measurable.measure(childConstraints)
                placeable.placeRelative(0, 0)
            }
        }
    }
}


@RequiresApi(34)
private class SurfaceSyncGroupCompatV34 {
    private var surfaceSyncGroup: SurfaceSyncGroup? = null

    fun postRegister(
        mainLooperHandler: Handler,
        surfaceView: SurfaceView,
        invalidate: Runnable
    ) {
        mainLooperHandler.post {
            val rootSurfaceControl = surfaceView.rootSurfaceControl ?: return@post
            surfaceSyncGroup = SurfaceSyncGroup("exo-sync-b-334901521")
                .apply { add(rootSurfaceControl) {} }
            invalidate.run()
            rootSurfaceControl.applyTransactionOnDraw(SurfaceControl.Transaction())
        }
    }

    fun maybeMarkSyncReadyAndClear() {
        surfaceSyncGroup?.markSyncReady()
    }
}

icbaker · 2024-08-05T14:17:10Z

Heads up for those subscribed to this thread: We have received a report (#1594) that the workaround we introduced in 30cb762 has introduced a regression in the behaviour of Shared Element Transitions. We are currently investigating this, and will update #1594 when we have more info.

@Omkar-Amberkar Does it work? That's probably the best/first test. In general we don't have the capacity for 1:1 code review, and we are also not the experts in these graphics APIs - so I'm afraid not best placed to debug your integration with them, if you're unable to adapt our published workaround to your needs.

Omkar-Amberkar · 2024-08-05T17:38:22Z

@icbaker yes it does but wanted to check in with you guys to see if that seems correct when using compose.

efemoney · 2024-08-09T19:55:13Z

@Omkar-Amberkar it is correct. It does the exact same thing. I have the same workaround in my code.

icbaker · 2024-09-04T14:54:29Z

I'm afraid that due to the unintended side-effects of the workaround reported in #1594 (for non-Compose use-cases), I've had to make the workaround opt-in (rather than automatically enabled) in 87bd9ba.

This means that those of you using PlayerView inside AndroidView will need to call playerView.setEnableComposeSurfaceSyncWorkaround(true) to enable the workaround. This change will probably go live in 1.5.0-beta01.

The workaround causes issues with XML-based shared transitions, so we can't apply it unilaterally. Issue: androidx#1594 Issue: androidx#1237 PiperOrigin-RevId: 670960693

MykolaKosianchuk added bug needs triage labels Apr 2, 2024

rohitjoins assigned icbaker Apr 7, 2024

icbaker added need more info and removed needs triage labels Apr 8, 2024

google-oss-bot added needs triage and removed need more info labels Apr 8, 2024

icbaker removed the needs triage label Apr 19, 2024

promanowicz mentioned this issue Apr 20, 2024

Video is cut on the edge when using Compose and uses RESIZE_MODE_ZOOM - Only Android 14 #1123

Closed

1 task

StaehliJ mentioned this issue Apr 29, 2024

Video doesn't fit when PlayerSurface size changed on Android Pixels devices SRGSSR/pillarbox-android#515

Closed

1 task

This was referenced May 8, 2024

A few video in a list overlap each other #1107

Open

Controlls position in a horizontal orientation with RESIZE_MODE_FILL #1120

Closed

MDXDave mentioned this issue Jun 14, 2024

Exo Player Video is cutoff when user switches to Full Screen Portrait Mode #1270

Closed

1 task

ryanw-mobile mentioned this issue Jun 14, 2024

Media 3 Exoplayer bug fix (Android 14 / API 34) ryanw-mobile/video-player-app#44

Closed

icbaker changed the title ~~AspectRatioFrameLayout problem~~ SurfaceView inside Compose AndroidView often shown stretched/cropped on API 34 Jun 19, 2024

icbaker closed this as completed Jun 19, 2024

calren mentioned this issue Jun 20, 2024

[Bug]: Transformer Demo video is initially clipped after export android/platform-samples#172

Closed

2 tasks

androidx locked and limited conversation to collaborators Aug 19, 2024

icbaker mentioned this issue Aug 29, 2024

[PlayerView] Shared element transitions not work on 1.4.0 #1594

Closed

1 task

androidx unlocked this conversation Sep 4, 2024

androidx locked and limited conversation to collaborators Sep 5, 2024

SurfaceView inside Compose AndroidView often shown stretched/cropped on API 34 #1237

SurfaceView inside Compose AndroidView often shown stretched/cropped on API 34 #1237

Comments

MykolaKosianchuk commented Apr 2, 2024 • edited Loading

Version

More version details

Devices that reproduce the issue

Devices that do not reproduce the issue

Reproducible in the demo app?

Reproduction steps

Expected result

Actual result

Media

Bug Report

phcannesson commented Apr 3, 2024

MykolaKosianchuk commented Apr 3, 2024

harry248 commented Apr 3, 2024 • edited Loading

icbaker commented Apr 8, 2024

Reproducible in the demo app?

phcannesson commented Apr 8, 2024

Reproducible in the demo app?

promanowicz commented Apr 8, 2024

MykolaKosianchuk commented Apr 8, 2024

speedclaud commented Apr 11, 2024 • edited Loading

phcannesson commented Apr 11, 2024 • edited Loading

speedclaud commented Apr 11, 2024

speedclaud commented Apr 11, 2024 • edited Loading

icbaker commented Apr 11, 2024

phcannesson commented Apr 11, 2024

phcannesson commented Apr 12, 2024

icbaker commented Apr 12, 2024

harry248 commented Apr 12, 2024

fpitterstv2 commented Apr 17, 2024

jdelga commented Apr 17, 2024

fpitterstv2 commented Apr 18, 2024

icbaker commented Apr 19, 2024

icbaker commented Jun 14, 2024

icbaker commented Jun 19, 2024

kotya341 commented Jul 29, 2024

devno44 commented Jul 30, 2024

icbaker commented Jul 30, 2024

kotya341 commented Jul 30, 2024 • edited Loading

icbaker commented Jul 30, 2024

phcannesson commented Jul 30, 2024

icbaker commented Jul 30, 2024

Omkar-Amberkar commented Aug 2, 2024 • edited Loading

icbaker commented Aug 5, 2024

Omkar-Amberkar commented Aug 5, 2024

efemoney commented Aug 9, 2024

icbaker commented Sep 4, 2024

MykolaKosianchuk commented Apr 2, 2024 •

edited

Loading

harry248 commented Apr 3, 2024 •

edited

Loading

speedclaud commented Apr 11, 2024 •

edited

Loading

phcannesson commented Apr 11, 2024 •

edited

Loading

speedclaud commented Apr 11, 2024 •

edited

Loading

kotya341 commented Jul 30, 2024 •

edited

Loading

Omkar-Amberkar commented Aug 2, 2024 •

edited

Loading