Skip to content
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

[BUG]: startPosition behaves differently on iOS vs Android when cropStart is used #4102

Open
giodevcoding opened this issue Aug 20, 2024 · 3 comments
Labels
Accepted Issue is confirmed and accepted by maintainers team bug

Comments

@giodevcoding
Copy link

Version

6.4.5

What platforms are you having the problem on?

iOS, Android

System Version

iOS 17.5, Android 14

On what device are you experiencing the issue?

Real device, Simulator

Architecture

New architecture with interop layer

What happened?

When adding a source object to the video player, I expected the startPosition property be consistently based on the actual start of the video file or based on the cropStart property. So if I specify a cropStart value of 60000 (ms) and a startPosition value of 30000, startPosition should always be equivalent to either the 90 second mark of the video (ideal) or the 30 second mark (less ideal, since before cropStart).

What I found was is, in the previously given scenario, on Android, the startPosition would be offset by the specified cropStart value, starting at the 90 second mark. However, on iOS, the startPosition would not be offset by the specified cropStart value, starting at the 30 second mark, which in this example is before the cropStart value. While the startPosition being able to start the video before the given cropStart value is less ideal, my expectation is that the behavior would be consistent between platforms, but it is not, requiring me to do something similar to the following:

const cropStart = 60000 // 60 seconds
const startPositionBase = 30000 // 30 seconds

const startPosition = Platform.select({
  android: startPositionBase,
  ios: cropStart + startPositionBase, // Manually creating the offset for iOS
  default: startPositionBase
})

const source = {
  uri: "...",
  cropStart,
  startposition
}

The only exception is when the specified startPosition = 0, which will start the video at the cropStart mark on both platforms.

It seems that the behavior should be consistent across platforms and this is some sort of bug.

Reproduction

No response

Reproduction

Step to reproduce this bug are:

  1. Render Video component with the given source object:
    <Video
      source={{
        uri: "https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4",
        cropStart: 60000,
        startPosition: 30000
      }}
    />
  2. On iOS, the video should start at the 30 second mark of the video, before the specified cropStart time. Visually, the progress bar will be stuck at 1:00 since the point in the video being played is before the cropStart time until the progress has passed that 1:00 mark.
  3. On Android, the video should start at the 90 second mark, offset by the specified cropStart time, which will visually look like 30 seconds into the video on the progress bar.
@moskalakamil
Copy link
Member

Hi, thanks for reporting the issue!

@freeboub freeboub added the Accepted Issue is confirmed and accepted by maintainers team label Aug 29, 2024
@freeboub
Copy link
Collaborator

but cropStart doesn't have the same behavior on ios and android 🤔
On android I cannot seek before the cropStart
On ios I can seek before the cropStart ...
Let's start with this issue I think ...

@freeboub
Copy link
Collaborator

I went into details of the implementation, and we cannot achieve the same behavior than on android (need to be added into documentation).
On android we can directly inform exoplayer to crop the content then the player completely hide content before cropStart and after cropEnd.
On Ios, everything is done manually (initial seek, duration truncation) and this is a bit buggy. The main side effect of this issue is that full screen will still display the full length of the video, and this is not something we can fix.

I will try to enhance the behavior a bit, but I am afraid to make regressions, so I will go step by step and clean a bit the code...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Issue is confirmed and accepted by maintainers team bug
Projects
None yet
Development

No branches or pull requests

3 participants