Currently, the iOS implementation of video_player uses a display link to unconditionally drive engine textureFrameAvailable: calls. There's no reason to expect that every time the display link fires the video has a new frame available, however, and when adding macOS support I found that we were getting a lot of flickering from doing the same thing on macOS because there was in fact no frame. It appears (I haven't dug into this on the engine side to confirm and see why) that the iOS engine implementation handles a NULL frame return by continuing to show the previous frame, and video_player is depending on that, whereas on macOS the observed behavior was that if we returned NULL the texture would blank, causing extremely bad flickering.

To avoid that, the macOS implementation only calls textureFrameAvailable: if there's actually a new frame when the display link fires (which isn't by itself enough, but helps a lot; there are other mitigations to try to further prevent null frames).

However, to avoid changing iOS behavior while bringing macOS online I added a skipBufferAvailabilityCheck to the newly-shared code to bypass that logic on iOS, preserving the iOS behavior of calling unconditionally. We should remove that flag and make iOS use the same conditional logic as macOS, after testing that it still works as expected, since there's no reason to be calling the engine when there's no frame.