背景
我编写的代码记录来自网络摄像头的视频剪辑，将它们写入内存流，然后通过套接字连接传输数据，在该连接中数据被重新组合成视频并在媒体元素上播放。
最终目标是创建一个婴儿监视器系统，服务器/摄像头在 Windows IOT Raspberry Pi 上运行，以及我和女朋友可以在手机或笔记本电脑上查看的 UWP 应用程序。除了从房子的另一部分查看摄像头之外，当我们中的一个人不在家时，我们还可以登录，及时我也会连接 PIR 运动传感器和警报系统，但首先要做的事情第一的。
整个系统工作得相当好，视频中有 5 秒的延迟，这是我可以接受的（目前），并且使用 MediaPlaybackList 视频以相当恒定的速率无缝传输（尽可能无缝）现在）视频之间的转换。 MediaPlaybackList 在播放项目时将其删除，从而将内存占用保持在相对恒定的水平。
问题
当视频在客户端播放时，会出现频繁但随机的破碎图像部分。它没有任何图案，无论如何我都找不到，我能描述它的唯一方式是图片的一部分水平分成两半，两半交换，图片的右侧显示在左边，反之亦然。这就像闪烁，因为破碎的位仅显示不到一秒，因为大约一秒后另一位会出现在图片的其他位置。
这是一个例子：
Now, here's a couple of interesting points..
1）在开始使用 MediaPlaybackList 对数据流进行排队之前，我使用的方法是从传入的套接字流中提取每个视频，将其作为 StorageFile 保存到本地磁盘，然后对这些 StorageFile 进行排队，按顺序播放它们然后删除它们（我在源代码管理中仍然有这个代码的一个版本，我可以挖掘出来，但我不喜欢创建和销毁 StorageFiles 的想法，因为它看起来效率低得可怕）。然而，使用这种方法并没有导致我现在看到的破碎的图片......这让我相信视频本身很好，也许这是它被重新组合在一起并流式传输到的方式的问题。媒体元素？
2) 我女朋友的猫在我没有意识到的情况下将网络摄像头（Microsoft Lifecam HD-3000）撞到了一边，直到我运行服务器并注意到图片呈 90 度角时我才意识到。令人费解的是）事情是，交付给客户的图片并没有像我上面描述的那样破裂。我能看到的唯一区别是，图片的分辨率为 480 x 640（来自侧面的相机），而不是标准的 640 x 480。这意味着什么，我不确定......
对问题的思考
Source
以下是我认为可能相关的一些代码片段，完整的解决方案源可以在 GitHub 上找到：视频套接字服务器 .
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);
我想做类似的事情（从 Raspberry Pi 上的 UWP 应用程序流视频/音频），但我一直在使用 Windows 10 SDK 中的简单通信示例，经过一些调整后我已经能够开始工作可靠（示例代码存在线程同步问题）。然而，SDK 示例使用使用媒体扩展的专有协议，并且通过互联网重定向流并不容易，这是我的用例，因此我查看了您的代码并使其正常工作（具有相同的错误）。简单的实时通信
对你的方法的一些评论：
1) RPi 不能很好地处理 Win10 上的视频，因为它不能使用硬件视频编码器，所以一切都在软件中完成。这会导致故障，我发现 CPU 性能显着提高，利用率超过 50%，这意味着至少有一个 CPU 核心正在接近最大值工作，可能是处理视频压缩为 MP4 的核心。不过，我运行了 SDK 示例并获得了无故障查看和大约 70% 的 CPU 利用率，因此您的问题可能出在其他地方。
2) 5 秒的延迟是很重要的。我在实时样本中获得了不到 100 毫秒的延迟，但是当我将流媒体计时器调整到 1 秒时，中断非常严重且无法实现。您是否考虑过更改设计，以便在捕获期间进行流式传输，但我不确定 InMemoryRandomAccessStream 是否允许您这样做。另一种替代方法是捕获预览流并将自定义媒体接收器写入缓冲区（由于不是托管代码，因此很难做到，并且可能无法轻松压缩），就像简单通信示例一样。
3) MP4 是一种容器而不是压缩格式，并且不是为流式传输而构建的，因为必须在开始之前下载整个文件，除非将 moov 元数据记录放置在文件的开头。不确定 UWP 如何处理此问题，可能需要在发送之前关闭流的方法，以确保另一端可以正常播放。
所以这不是一个完整的答案，但希望以上内容有所帮助。