当wpf MediaElement的Source是https uri时如何播放

Question

在wpf独立应用程序（.exe）中，我在MainWindow中包含了MediaElement

<Window x:Class="Media.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Main Window" Height="350" Width="525">
    <Grid>
        <MediaElement x:Name="Player" Stretch="Uniform" LoadedBehavior="Manual" UnloadedBehavior="Stop"/>
    </Grid>
</Window>

并从后面的代码中将其Source设置为任何https Uri：

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        var source = new Uri("https://stream_which_can_be_opened_with_windows_media_player.com", UriKind.Absolute);
        Player.Source = source;
        Player.Play();
    }
}

调用Play()方法时，将引发NullReferenceException而不是播放媒体内容。 初始化MediaElement ，从Play()方法引发NullReferenceException ，请参见下文。

可以在Windows Media Player中打开视频的同一Uri（文件->打开Url）。

问题似乎出在MediaPlayerState.OpenMedia方法（ MediaElement内部使用的对象）中，该方法试图检查从SecurityHelper.ExtractUriForClickOnceDeployedApp检索的appDeploymentUri是否具有方案HTTPS。 该应用程序未使用ClickOnce部署（它具有独立的安装程序），并且appDeploymentUri为null，因此为NullReferenceException 。

这来自PresentationFramework.dll，System.Windows.Media.MediaPlayerState.OpenMedia

    if (SecurityHelper.AreStringTypesEqual(uriToOpen.Scheme, Uri.UriSchemeHttps))
    {
        // target is HTTPS. Then, elevate ONLY if we are NOT coming from HTTPS (=XDomain HTTPS app to HTTPS media disallowed)

        //source of the issue
        Uri appDeploymentUri = SecurityHelper.ExtractUriForClickOnceDeployedApp();
        //appDeploymentUri is null
        if (!SecurityHelper.AreStringTypesEqual(appDeploymentUri.Scheme, Uri.UriSchemeHttps))

任何人都没有解决方法/解决方案以使其正常工作吗？

Answer 1

我使用MediaElement已有好几次了，老实说，这比我遇到的任何其他WPF组件都要糟，而且有更多的错误。 它不仅存在错误，而且缺少Silverlight具有的许多功能。 HTTPS与Silverlight一起使用。

我遍历了代码，但没有找到更改它的方法。 也许有一些MAD反射黑客可以使您做到这一点，但这是黑客，我不建议这样做。 附言，这似乎是一个真正的错误，也许会让Microsoft伙计们知道。

最简单的解决方案是使用OWIN制作“内存Web服务器”。 然后，您可以流过http://localhost:1337并包装基础https：//内容。 不过，https内容仍然是安全的，因为您是从“内存Web服务器”流式传输它的，并且从未进行过“真正的” web请求。 它仍然应该是高效且安全的。