When I updated to 16.0.0 of Pigeon, found a bug: flutter/flutter#141499

When I updated to 16.0.0 of Pigeon, found a bug: flutter/flutter#141499

Thanks, that should probably be an easy fix.

FYI we're generally moving away from dartHostTestHandler in favor of just mocking/faking the host API itself, as we've generally found over time that it makes the tests simpler.

@stuartmorgan I have no idea why the tests are timing out. They are working fine locally.

@stuartmorgan I have no idea why the tests are timing out. They are working fine locally.

We have an ongoing problem in our Windows CI where some kinds of failures (even compile failures in at least some cases) somehow cause the CI to think something is still running and then they time out without much output, which unfortunately makes identifying the cause of a CI failure difficult. I'll try running the tests on my machine later today and see if I see any failures locally.

Went through most of the comments and fixed most of the issues.

• I'm getting logging from the engine about an event being sent from a non-platform thread. I'm going to see if I can quickly track that down.

Looks like this is the event_sink_ call in VideoPlayer::SendInitialized, which is coming from MFWorkItem::Invoke on a thread called (if I'm reading this VS UI correctly) ntdll.dll thread.

And then also VideoPlayer::SetBuffering on the same thread, from MediaEngineCallbackHelper::EventNotify

• Resizing the window pretty reliably crashes

Running this under the debugger, in one case I saw an assertion failure in MediaEngineWrapper::EnsureTextureCreated; as with the earlier crash, it's texture_.put() being non-null.

But the actual crash seems to be an abort coming from deep in the Flutter engine on the raster thread. I don't have a debug engine on Windows so I don't have more detail. Given that it's resize, I'm guessing that the most likely situation is that a buffer is being destroyed while the engine is still using it.

I created a generic RunOnMainThread method, that adds a delegate to a queue, registers a top-level Window Proc Delegate, which dequeues the delegate and run it. This solved these issues, but I think other plugins might benefit from this, as there is an equivalent in Android and iOS.

This solved these issues, but I think other plugins might benefit from this, as there is an equivalent in Android and iOS.

flutter/flutter#134346 has some related discussion; we've considered, rejected, and now are reconsidering building that into the plugin APIs.

Your input there would be welcome as a significant stakeholder :)

Hello, I've found an issue with video_player_windows. It throws an error when playing a locally stored video file with a filename containing Chinese characters.

The error log is as follows:

 #0      WindowsVideoPlayerApi.create (package:video_player_windows/src/messages.g.dart:89:7)
 <asynchronous suspension>
 #1      WindowsVideoPlayer.create (package:video_player_windows/src/windows_video_player.dart:56:27)
 <asynchronous suspension>
 #2      VideoPlayerController.initialize (package:video_player/video_player.dart:434:19)

@FZY456 You've only included the stack there, not the actual error.

@FZY456 You've only included the stack there, not the actual error.

PlatformException(uri_load_failed, , null, null)

From triage: What's the current status of this PR? Is it just waiting for an updated review?

No, review is probably still updated, but there is work on my end. I just didn't have time to do yet. My bad.

From triage: @azchohfi Is this still something you're planning to come back to?

Unfortunately, I do not have time right now to look at this. I would say that most of the code works but it needs some tweaking to make it production ready. Feel free to work on top of this to get it merged.

As there isn't a planned timeline to finish this PR, I'm going to go ahead and close it to reflect the fact that it's not active. The issue has been marked as having a partial PR, and we encourage anyone in the community interested in this functionality to pick up the work from here.

For whoever willing to take the work from here, some observations on choppiness:

If you run the example app and switch to "Asset" tab, the butterfly video will start playing in a very choppy manner. Try making the window smaller by re-sizing it slowly and at some threshold the video starts playing smoothly.

On my machine, when the VideoPlayer size was 607.2 x 341.55 the video was playing smoothly and when the size was 608 x 342 the video became very choppy.

You can try it yourself by wrapping the VideoPlayer widget inside _ButterFlyAssetVideo with a LayoutBuilder:

LayoutBuilder(
  builder: (context, constraints) {
    print('VideoPlayer size: ${constraints.maxWidth} x ${constraints.maxHeight}');
    return VideoPlayer(_controller);
  },
),