【发布时间】：2020-04-20 00:16:37
【问题描述】：
我正在尝试构建一个简单的应用程序，该应用程序将使用浏览器将视频从相机流式传输到远程服务器。
对于从浏览器访问相机，我发现了一个很棒的WebRTC API: getUserMedia。
现在要将其流式传输到服务器 IIUC，最好的方法是使用一些 WebRTC_API 进行传输，然后使用一些服务器端库来处理它。
但是，起初我采用了一些不同的方法：
我有用户 MediaRecorder 基于来自相机的流。然后我将MediaRecorder.start() 的时间片设置为几百女士，例如200. 我在 wrt MediaRecorder 中有一些假设与我观察到的不一致：
我观察到了奇怪的行为（不符合我对 MediaRecorder 的假设）：
- 如果只有 1 个块上传到服务器 -> 它打开就好了。
- 如果有多个块 -> 它们都没有正确加载，它们会给出错误：
Could not determine type of stream。但是，如果我使用ffmpeg连接所有块 - 生成的文件就可以了。如果我在客户端连接MediaRecorder.ondataavailable中的blobs，也会发生同样的情况。
因此问题：
理论上这些块可以是独立的视频文件吗？或者这不是MediaRecorder 的设计目的？如果不是 - 那么为什么我们甚至可以选择在其 start() 方法中提供 timeslice 参数？
额外问题
如果我们将timeslice 设置得比较小，例如10 毫秒 -> 发送到MediaRecorder.ondataavailable 的大量数据块的大小为 0。在哪里可以找到我们可以使用的最小 timeslice 的某种保证/规范，以便数据块有意义？
在文档中有以下内容：
如果时间片不是未定义的，那么一旦收集了最少时间片毫秒的数据，或者 UA 施加的某个最小时间片，以较大者为准，开始将数据收集到新的 Blob blob 中，并将任务排队，使用 DOM 操作任务源，它在带有 blob 的记录器上触发名为 dataavailable 的 blob 事件。
所以，我的猜测是它在某种程度上与某些大小为 0 的数据块有关。 “UA 强加的某个最小时间片”是什么意思？
附言
如果需要，很乐意提供代码。但问题不在于某些特定代码。这是为了了解MediaRecorder API 背后的假设以及它们存在的原因。
【问题讨论】：