-
Playback is truncated when using a MediaPlayer with an http URL. This is due to a bug in WmfMediaSession where it explicitly stops the session when it receives the MEEndOfPresentation event. However this event means that that all data has been read from the source but not necessarily played yet. According to the documentation, playback is done when the MESessionEnded event is sent.
-
In our configuration the MediaPlayer URL has request parameters. The WmfMedia module checks file extensions to determine if it supports the media type. However that code doesn’t handle URLs with request parameters. And presumably it should check the mime-type rather than the file extension in such cases.
Hey iktomi,
Thank you for taking the time to investigate this issue and report your findings. I am going to share this post with some other developers who might be able to use this information to benefit the progression of the feature. If you have any other further comments or questions please let me know.
Regards,
Thanks Andrew,
I’m not sure if this plugin is in your future plans but I should point out that there are a few other serious problems that are exposed when you call MediaPlayer::OpenUrl more than once. The audio use case is one such as a music play list, or podcast list where you play subsequent tracks by calling OpenUrl on the next track. Besides the above mentioned problems, the engine class FXAudio2SoundSource has state handling bugs such that it continuously requests input even when the editor isn’t the focused window and when it is paused. When you switch tracks the new track won’t be heard until the entirety of this buffered output is played. Since it’s at the OS layer even if you stop the level and restart it - the previous buffered output still plays. Those requests are sent to the MediaSoundWave class which itself has a pair of in-memory queues of sound samples - which are again not purged when a MediaPlayer is closed.
Hey iktomi,
I have shared this information with our developers and we actually ask that if users are apt enough to make changes they can do so through GitHub, as this feature is open source.
We also have another Media Player plugin that is open source you could take a look at as well. It is also still in its early stages, so there are some issues with its playback but it has a wider range of video compatibility.
https://github.com/EpicGames/UnrealEngine/pull/1173
Take a look at our GitHub to submit a pull request to integrate the changes you want to make to the Media Player feature. You seem to have a good handle on what needs to be changed in order to improve the functionality of the feature, and we appreciate you taking the time to communicate these issues to us.
Regards,
iktomi, those are all good finds. I’m currently knee deep in other projects, but as said, if you could submit pull requests on GitHub, that would greatly accelerate the process of getting these fixed. Thanks!
I can cook up a pull request however I’d describe my changes more as “workarounds” than fixes. A couple of other issues to mention:
- SourceResolver::CreateObjectFromURL is a blocking call that makes network requests in the case of HTTP urls - however it’s called on the main thread. The OpenUrl API in general cannot be synchronous - why not use a LatentAction for it? For that matter, at least on windows the same can be said for the rest of the media player api.
- MediaSoundWave doesn’t work correctly (at least to my thinking) with passive soundmix triggers. As far as the soundmix is concerned the MediaSoundWave is always playing - pausing, completion of the media, and or changing the url has no effect,
Audio is not supported yet. See the forum for the roadmap.
As for OpenURL, that can probably be fixed easily with TAsync. Might require some additional callbacks in the API for success/failures. I’ll think about it.
You can use LatentAction and have ufunctions to check the result (IsOpen()). It would be nice if the LatentAction mechanism allowed returning a result - then you’d have one-shot continuations - i.e futures in blueprints.
No, this needs to work in plain C++ as well.
I was speaking of the blueprint api. Obviously in C++ there are no limitations. Binding events as callbacks in blueprints isn’t very nice.
Actually, I spoke to soon. It seems you can implement one-shot continuations with the current blueprints implementation. See this gist
Microsoft has an async API Begin/EndCreateObjectFromURL But you’ll still need any subsequent commands (Play, SetRate, Etc) to wait until it completes
- which is why imo the whole api needs to be async - the user can then chain calls together with futures in c++ and also in blueprints as shown above, without ever blocking the main thread which is obviously crucial for sound quality.
I fixed the issue with MEEndOfPresentation today in GitHub commit.
The issue with the URLs not being handled correctly in the WmfMedia plug-in was fixed about a month ago in GitHub commit.
I started implementing asynchronous media source resolving using the Begin/End functions, but it got a little more involved than I expected, and I’m not sure if I’ll be able to finish it this week due to other tasks I need to work on. I will post an update here when it’s done.
As for the Blueprint related suggestions, I will look into those, but most likely not before September.
I managed to implement OpenUrlAsync as described in my fork. I ended up incorporating this MS code in WmfMediaSession and removing most of the existing state handling. You can take a look in the 4.8 branch here. I left the rest of the API synchronous for now as this fork is only for a demo we’re doing. Also I guess I spoke too soon about C++ futures - they seem to be degenerate (i.e don’t have a monadic join (aka “flatMap”)). Anyway, at least it works great with blueprints.