c# - UWP - 通过套接字将网络摄像头流式传输到 MediaElement - 图片损坏？

Question

背景

我编写的代码记录来自网络摄像头的视频剪辑，将它们写入内存流，然后通过套接字连接传输数据，在此处将数据重新组合成视频并在媒体元素上播放。

最终目标是创建一个婴儿监视器系统，服务器/摄像头运行在 Windows IOT Raspberry Pi 上，还有一个 UWP 应用程序，我和我的女朋友可以在我们的手机或笔记本电脑上查看。除了从房子的另一部分查看摄像头外，我们还可以在我们中的一个人出门在外时登录，我会及时连接 PIR 运动传感器和警报系统，但首先要做的是首先。

整个系统工作得很好，视频有 5 秒的延迟，我可以接受(目前)，并且使用 MediaPlaybackList 视频以相当恒定的速率流式传输，并且无缝(像这样无缝现在可以得到)视频之间的过渡。 MediaPlaybackList 在播放项目时将其移除，从而使内存占用量保持相对恒定。

问题

当视频在客户端播放时，会出现频繁但随机的碎图片段。它没有模式，反正我也找不到，我能描述的唯一方式是图片的一部分水平分成两半，两半左右交换，图片的右侧显示在左边，反之亦然。这就像一个闪烁，因为 splinter 的位只显示几分之一秒，因为另一位在一秒钟左右之后出现在图片的其他地方。

这是一个例子:

现在，这里有几个有趣的点..

1) 在开始使用 MediaPlaybackList 对数据流进行排队之前，我使用的方法是从传入的套接字流中提取每个视频，将其作为 StorageFile 保存到本地磁盘，然后将这些 StorageFile 排队，播放他们按顺序删除它们(我在源代码管理中仍然有这个代码的一个版本，我可以挖掘出来，但我不喜欢创建和销毁 StorageFiles 的想法，因为它看起来非常低效)。然而，使用这种方法并没有导致我现在看到的破损图片……这让我相信视频本身很好，而且可能是它被放回一起并流式传输到的方式有问题媒体元素？

2) 我女朋友的猫在我没有意识到的情况下将网络摄像头(Microsoft Lifecam HD-3000)撞到了一边，直到我运行服务器并注意到图片呈 90 度角时我才意识到......有趣(和令人费解)的是，交付给客户的图片并没有像我上面描述的那样分解。我在这里看到的唯一区别是图片随后以 480 x 640(来自侧面的相机)而不是标准的 640 x 480 显示。这意味着什么，我不确定...

对问题的思考

• 与视频的大小/尺寸有关(它的侧面播放效果很好，所以与此有关)吗？
• 与比特率有关吗？
• 与字节在客户端重新组装的方式有关吗？
• 与流的编码有关吗？

来源

这里有一些我认为可能相关的代码片段，完整的解决方案源可以在 GitHub 上找到: Video Socket Server.

服务器

while (true)
{
    try
    {
        //record a 5 second video to stream
        Debug.WriteLine($"Recording started");
        var memoryStream = new InMemoryRandomAccessStream();
        await _mediaCap.StartRecordToStreamAsync(MediaEncodingProfile.CreateMp4(VideoEncodingQuality.Vga), memoryStream);
        await Task.Delay(TimeSpan.FromSeconds(5));
        await _mediaCap.StopRecordAsync();
        Debug.WriteLine($"Recording finished, {memoryStream.Size} bytes");

        //create a CurrentVideo object to hold stream data and give it a unique id
        //which the client app can use to ensure they only request each video once
        memoryStream.Seek(0);
        CurrentVideo.Id = Guid.NewGuid();
        CurrentVideo.Data = new byte[memoryStream.Size];

        //read the stream data into the CurrentVideo  
        await memoryStream.ReadAsync(CurrentVideo.Data.AsBuffer(), (uint)memoryStream.Size, InputStreamOptions.None);
        Debug.WriteLine($"Bytes written to stream");

        //signal to waiting connections that there's a new video
        _signal.Set();
        _signal.Reset();
    }
    catch (Exception ex)
    {
        Debug.WriteLine($"StartRecording -> {ex.Message}");
        break;
    }
}

连接

//use the guid to either get the current video, or wait for the 
//next new one that's added by the server
Guid guid = Guid.Empty;
Guid.TryParse(command, out guid);
byte[] data = _server.GetCurrentVideoDataAsync(guid);
if (data != null)
    await _socket.OutputStream.WriteAsync(data.AsBuffer());

客户端应用

byte[] inbuffer = new byte[10000000];

//block on the input stream until we've received the full packet,
//but use the Partial option so that we don't have to fill the entire buffer before we continue.
//this is important, because the idea is to set the buffer big enough to handle any packet we'll receive,
//meaning we'll never fill the entire buffer... and we don't want to block here indefinitely
result = await socket.InputStream.ReadAsync(inbuffer.AsBuffer(), inbuffer.AsBuffer().Capacity, InputStreamOptions.Partial);

//strip off the Guid, leaving just the video data
byte[] guid = result.ToArray().Take(16).ToArray();
byte[] data = result.ToArray().Skip(16).ToArray();
_guid = new Guid(guid);

//wrap the data in a stream, create a MediaSource from it,
//then use that to create a MediaPlackbackItem which gets added 
//to the back of the playlist...
var stream = new MemoryStream(data);
var source = MediaSource.CreateFromStream(stream.AsRandomAccessStream(), "video/mp4");
var item = new MediaPlaybackItem(source);
_playlist.Items.Add(item);

Answer 1

我想做类似的事情(从 Raspberry Pi 上的 UWP 应用流式传输视频/音频)，但我一直在使用 Windows 10 SDK 中的简单通信示例，经过一些调整后我已经能够可靠地工作(示例代码存在线程同步问题)。然而，SDK 示例使用使用媒体扩展的专有协议(protocol)，并且通过互联网重定向流并不容易，这是我的用例，所以我查看了您的代码并让它工作(具有相同的错误)。 Simple Real Time communication

关于您的方法的几点评论:

1) RPi 不能很好地处理 Win10 上的视频，因为它不能使用硬件视频编码器，所以一切都在软件中。这将导致故障，我看到 CPU 性能显着提高，利用率超过 50%，这意味着至少有一个 CPU 内核正在接近最大工作，可能是处理视频压缩到 MP4 的内核。然而，我运行了 SDK 示例并获得了无故障的查看和大约 70% 的 CPU，因此您的问题可能在其他地方。

2) 5 秒的延迟很重要。我得到的实时样本延迟不到 100 毫秒，但是当我将您的流式传输计时器调低到 1 秒时，中断很明显且不可行。您是否考虑过更改设计以使其在捕获期间流式传输，但是我不确定 InMemoryRandomAccessStream 是否会让您这样做。另一种替代方法是像简单通信示例那样捕获预览流并将自定义媒体接收器写入缓冲区(因为没有托管代码更难做到并且可能无法轻松压缩)。

3) MP4 是一种容器而不是一种压缩格式，它不是为流式传输而构建的，因为整个文件必须在开始之前下载，除非 moov 元数据记录位于文件的开头。不确定 UWP 如何处理此问题，可能需要您在发送前关闭流的方法，以确保另一端可以正常播放。

所以不是一个完整的答案，但希望以上内容有所帮助。