我们开发了一款 IP 摄像机产品，可通过 RTSP/UDP 传输 H.264/MPEG4/MJPEG 视频。它有一个 Web 界面，目前我们使用 VLC Firefox 插件来允许在浏览器中查看实时 RTSP 流，但 Firefox 正在放弃对 NPAPI 插件的支持，因此目前这是一个死胡同。

相机本身是一个功耗相对较低的 ARM SoC（想想 Raspberry Pi 级别），因此我们没有大量的备用资源来执行诸如在板上实时转码流之类的操作。

主要目的是从 Web 界面检查视频流是否正常工作，因此以某种其他格式/传输/流媒体引擎流式传输新流（或对其进行转码）不如能够直接播放原始 RTSP 流更理想。在常规使用中，视频通过 RTSP 传输到 VMS 服务器中，因此无法进行更改。

在理想的情况下，解决方案将是开源的跨浏览器并发生在 HTML5 标记内，但如果它可以在一种或多种最流行的浏览器中运行，我们就会采用它。

我一直在这里和网络上阅读各种关于 HTML5 视频标签、WebRTC、HLS 等勇敢新世界的文章，但还没有看到任何看起来像明智且完整的解决方案，但不涉及一些额外的转换/转码/重新流式传输，通常是由一些半支持的框架或中间的额外服务器完成的，这不是一个可行的解决方案。

我还没有找到正确的描述，说明将我们的流“转换”为任何 html5-video-likes 可能需要或不需要什么，无论它只是围绕相同基本视频流的稍微不同的包装器，还是有很多开销和一切都不同了。同样，尚不清楚转换是否可以在板上实现，甚至可以使用 JS 在浏览器中实现。

标题的原因是，如果我们必须改变一切的运作方式，我们最好尽可能采取任何被认为是“最佳实践”和合理的面向未来的措施，而不是一些可能不会的权宜之计。下一轮浏览器更新/下一个 W3C 新闻稿之外的工作......

我觉得有点令人失望（但也许并不奇怪），2017 年似乎没有明智的方法来实现这一目标。

也许“最差实践”会是更合适的术语......

您可以使用许多不需要转码的方法。

WebRTC

如果您使用 RTSP，则可以通过 WebRTC 发送流。

WebRTC 使用 SDP 来声明流，并使用 RTP 来传输这些流。设置 WebRTC 调用还需要一些其他层，但这些层都不需要特别昂贵的计算。大多数（全部？）WebRTC 客户端将支持 H.264 解码，其中许多具有浏览器内的硬件加速功能。

开始使用 WebRTC 的最简单方法是首先实现浏览器到浏览器客户端。然后，您可以通过自己的实现更深入地进行。

WebRTC是我推荐给你的路线。 NAT 穿越（在大多数情况下）和 P2P 连接是内置的，因此您的客户无需记住 IP 地址。只需提供信号服务，您的客户就可以从家里的任何地方直接连接到他们的摄像机。提供 TURN 服务器，即使两端都设有防火墙，它们也能够连接。如果您不想提供此类服务，它们是轻量级的，可以像您今天这样的模式直接在相机上运行。

HTTP 渐进式 MP4 碎片<video> tag

这种方法比WebRTC简单得多，但与你现在所做的完全不同。您可以获取 H.264 流，并将其直接封装在 MP4 中，无需转码。然后，它可以在一个<video>页面上的标签。您必须在代码中实现适当的库，但这里有一个输出到 STDOUT 的 FFmpeg 示例，您可以将其通过管道传输到客户端：

ffmpeg \
  -i YOUR_CAMERA_HERE \
  -vcodec copy \
  -acodec copy \
  -f mp4 \
  -movflags frag_keyframe+empty_moov \
  -

其他的...

就您而言，DASH 没有任何额外好处。 DASH 旨在利用基于文件的 CDN 进行流式传输。您控制服务器，因此没有必要以类似文件的方式写出文件或处理 HTTP 请求。虽然您当然可以将 DASH 与 H.264 流一起使用而无需转码，但我认为这是浪费您的时间。

HLS 大致相同。您的流与 HLS 兼容，但由于编解码器缺乏灵活性，HLS 正在迅速失宠。 DASH 和 HLS 本质上是相同的机制...将一堆媒体片段写入 CDN 并创建一个播放列表或清单来指示它们的位置。