commit 04de46e0b9364a6908c0fcf8c142d61e1cae019b
author misos1 <30872003+misos1@users.noreply.github.com> Thu Apr 17 19:26:14 2025 +0200
committer GitHub <noreply@github.com> Thu Apr 17 17:26:14 2025 +0000
tree 0b7b278d7b75557420b8910b182da5445f1608e1
parent bbb0e516fb515ac047aceb240d636fa473d46560

[video_player_avfoundation] enable more than 30 fps (#7466)

In the player there was hardcoded 30 fps when setting up video composition. Now it uses timing from source track and also fallback `minFrameDuration` as seems `frameDuration` must be always set to something and it takes over in some situations as is mentioned in documentation about `sourceTrackIDForFrameTiming`. Also video composition setup is skipped when it is not needed when `preferredTransform` is identity.

Function `updatePlayingState` is called often right after `setupEventSinkIfReadyToPlay` but seems it was forgotten in `onListenWithArguments` and also it cannot be called in that way because `setupEventSinkIfReadyToPlay` may finish asynchronously when called again from line `[self performSelector:_cmd onThread:NSThread.mainThread withObject:self waitUntilDone:NO]` so now is `updatePlayingState` called right after `_isInitialized = YES` which is what it needs to even do something.

There was one more obstacle for playing 60 fps videos on 60 hz screen. Seems there are at least two "display links" at play when playing video, one calls function `displayLinkFired` and other one from flutter engine calls `copyPixelBuffer` but only when `textureFrameAvailable` was called previously. But the order in which those two are called is undefined so 16 ms after `displayLinkFired` may be called `copyPixelBuffer` and right after that `displayLinkFired` and so on. But `copyPixelBuffer` steals the newest pixel buffer from video player output and in `displayLinkFired` `hasNewPixelBufferForItemTime` will not report another pixel buffer for time close to that. Then the next frame is not called `copyPixelBuffer` because `textureFrameAvailable` was not called and in this way it skips every second frame so it plays video at 30 fps. There was also a synchronization problem with `lastKnownAvailableTime`. Now pixel buffers are produced and reported just on a single place in `displayLinkFired` and received with correct synchronization in `copyPixelBuffer`. Ideally there would be just a single "display link" from flutter engine if it supported also pulling frames instead of only pushing (which is good enough for a camera where the system is pushing frames to us, but from player video output is needed to pull frames). Calling `textureFrameAvailable` every frame could accomplish that but it looks like this line in flutter engine is calling even when `copyPixelBuffer` returns NULL and it may be expensive (although there is no need to call it in such case):

```
sk_sp<flutter::DlImage> image = [self wrapExternalPixelBuffer:_lastPixelBuffer context:context];
```

Seems there is some bug with the video player using this flutter engine on macos. Looks like the video is playing normally but then it starts "tearing", it looks like it is displaying frames normally but once in a while it shows some frame from the past like some previously cached frame. This is happening on the main branch but rendering on 60 fps exaggerates it (it is not caused by this PR).