On 8/18/2025 18:45 PM, Mike Kaganski wrote: > FYI, a brute force approach in Player::InitializeWindow, like
> > static const BOOL sync = o3tl::IsRunningUnitTest() ? TRUE : FALSE; > > if (SUCCEEDED(hr)) > > hr = > > g_pPlayer->CreateMediaItemFromURL(o3tl::toW(maURL.getStr()), sync, 0, > > nullptr); > works for me. It indeed is wrong, does not receive the synchronously > created media item , ... but the tests pass. Yes, it can work, thanks, Mike. Tests also pass on my local Windows. Yes, the CreateMediaItemFromURL() call can be sync and async: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/api/mfplay/nf-mfplay-imfpmediaplayer-createmediaitemfromurl In this case we will not create any IMFPMediaItem object, but we do not need it for these unit tests anyway, so we can temporarily disable it for creating media player and media item objects for unit tests. https://gerrit.libreoffice.org/c/core/+/189886 Best regards, Balázs Mike Kaganski <mikekagan...@gmail.com> ezt írta (időpont: 2025. aug. 18., H, 18:45): > On 8/6/2025 12:49 PM, Balázs Varga wrote: > > >>>Probably the Player object, inside its dispose() method, or its > > destructor, needs to wait until the CreateMediaItemFromURL call > completes. > > >>> We do similar stuff for child threads and > > asynchronous vcl PostUserEvent callbacks. > > > > Yes, probably something like that can help on this. Fyi > > loading/importing those simple unit test docs works well because we > > create the Player objects and then create the Media items with async > > calls like, > > CreateMediaItemFromURL and SetMediaItem and we finish with them before > > any closing or disposing call (which does not have until we delete the > > media file or close the doc), against of these unit test where > > we closed the doc before we would have done with those calls.... > > FYI, a brute force approach in Player::InitializeWindow, like > > > static const BOOL sync = o3tl::IsRunningUnitTest() ? TRUE : FALSE; > > if (SUCCEEDED(hr)) > > hr = > > g_pPlayer->CreateMediaItemFromURL(o3tl::toW(maURL.getStr()), sync, 0, > > nullptr); > > works for me. It indeed is wrong, does not receive the synchronously > created media item , ... but the tests pass. > > > > > > Noel Grandin <noelgran...@gmail.com> ezt írta (időpont: 2025. aug. 6., > > Sze, 9:21): > > > > > > > > On Wed, 6 Aug 2025 at 09:13, Balázs Varga > > <balazs.varga...@gmail.com> wrote: > > > > we make these calls and we InitializeWindow, so we create a > > MFPCreateMediaPlayer, CreateMediaItemFromURL with the tmp > > media file (avi): file:///C:/cygwin64/tmp/tesB70A.tmp, > > which methods (CreateMediaItemFromURL) completes > > asynchronously. When it does, MFPlay sends an > > MFP_EVENT_TYPE_MEDIAITEM_CREATED event, but before it could > > have finished, > > we dispose and Clear everything (also hwnd windows) related to > > MediaWindow/Player and I guess this happened (second call > > stack) > > MFPlay.dll!CMFPInnerPlayer::NotifyMediaItemCreatedEvent(struct > > IMFAsyncResult *) Unknown > > > > > > > > Probably the Player object, inside its dispose() method, or its > > destructor, needs to wait until the CreateMediaItemFromURL call > > completes. > > We do similar stuff for child threads and > > asynchronous vcl PostUserEvent callbacks. > > > > > > -- > > Best regards, > > Mike Kaganski > >
