我们开发了一种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等新世界的内容，并且还没有看到任何看似合理且完整的解决方案这并不涉及一些额外的转换/转码/重新流，通常是由一些半支持的框架或中间的额外服务器，这不是一个可行的解决方案。
我还没有找到适当的描述，可能需要或不需要转换＆＃34;我们的流媒体到了什么-html5-video-like，它是否只是围绕同一基本视频流的一个稍微不同的包装器，或者是否有很多开销和一切都不同。同样，不清楚是否可以使用JS在板上或甚至在浏览器中实现转换。
标题的原因在于，如果我们必须改变它的运作方式，我们也可以瞄准做任何考虑的事情＆＃34;最佳实践＆＃34;尽可能合理地面向未来，而不是在下一轮浏览器更新/下一轮W3C新闻发布之后可能无效的一些权宜之计......
我觉得有点令人失望（但也许并不奇怪），2017年似乎没有明智的方法来实现这一目标。
也许＆＃34;最差的做法＆＃34;会是更合适的术语......
答案 0 :(得分：9)
您可以使用许多不需要转码的方法。
如果您正在使用RTSP，那么您通过WebRTC发送流的方式非常多。
WebRTC使用SDP来声明流，使用RTP来传输这些流。设置WebRTC调用需要一些其他层，但这些层都不需要特别昂贵的计算。大多数（所有？）WebRTC客户端都支持H.264解码，其中很多都是在浏览器中进行硬件加速。
开始使用WebRTC的最简单方法是首先实现浏览器到浏览器的客户端。然后，您可以使用自己的实现更深层次。
WebRTC是我推荐给您的路线。 NAT遍历（在大多数情况下）和P2P连接是内置的，因此您的客户不必记住IP地址。只需提供信号服务，您的客户就可以从任何地方直接连接到家中的摄像头。提供TURN服务器，即使两端都是防火墙，它们也能够连接。如果您不想提供此类服务，那么它们非常轻便，可以像您今天一样直接在相机上运行。
<video>标记这种方法比WebRTC简单得多，但与你现在所做的完全不同。您可以使用H.264流，并将其直接包装在MP4中而无需转码。然后，它可以在页面上的<video>标记中播放。您必须在代码中实现适当的库，但这是一个FFmpeg示例，它输出到STDOUT，您将管道传输到客户端：
ffmpeg \
-i YOUR_CAMERA_HERE \
-vcodec copy \
-acodec copy \
-f mp4 \
-movflags frag_keyframe+empty_moov \
-
在您的情况下，DASH没有额外的好处。 DASH旨在利用基于文件的CDN进行流式传输。您可以控制服务器，因此以类似文件的方式写出文件或处理HTTP请求毫无意义。虽然你可以在没有转码的情况下使用带有H.264流的DASH，但我认为这是浪费你的时间。
HLS大致相同。您的流与HLS兼容，但由于编解码器缺乏灵活性，HLS正在迅速失宠。 DASH和HLS本质上是相同的机制......将一堆媒体段写入CDN并创建一个播放列表或清单，指明它们的位置。
答案 1 :(得分：1)
好吧，当我回到树莓派3时，我必须做同样的事情。我们使用pi上的ffmpeg对其进行了即时转码，并使用https://github.com/phoboslab/jsmpeg来流式传输mjpeg。然后在浏览器/离子应用程序上播放。
var canvas = document.getElementById('video-canvas');
this.player = new JSMpeg.Player(this.button.url ,{canvas: canvas});
我们在Pis上管理多达4个并发流，最小延迟<2-5秒。
但是一旦我们转到React Native，我们就在电话上使用了RN VLC包装器