当前在Web浏览器中流式传输实时视频的最佳做法? [英] Current best practice to stream live video in web browser?

查看:386
本文介绍了当前在Web浏览器中流式传输实时视频的最佳做法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

We develop an IP camera product which streams H.264/MPEG4/MJPEG video via RTSP/UDP. It has a web interface, currently we use the VLC Firefox plugin to allow viewing of the live RTSP stream in the browser but Firefox are dropping support for NPAPI plugins so that's currently a dead end.

摄像机本身是功率相对较低的ARM SoC(认为是Raspberry Pi级别),因此我们没有足够的备用资源来完成诸如在板上即时进行代码流转换的工作。

The camera itself is a relatively low-powered ARM SoC (think Raspberry Pi level) so we don't have vast spare resource to do things like transcode streams on-the-fly on the board.

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

The main purpose is to check the video stream is working correctly from the web interface, so streaming a new stream (or transcoding it) in some other format/transport/streaming engine is less desirable than being able to somehow play the original RTSP stream directly. In regular use the video is streamed via RTSP into a VMS server so that's not up for alteration.

在理想情况下,解决方案将是开源跨浏览器,发生在HTML5标签中,但是如果它可以在一种或多种最受欢迎​​的浏览器中使用,我们就会采用它。

In an ideal world the solution would be open-source cross-browser and happen inside an HTML5 tag, but if it works in one or more of the most popular browsers we'll take it.

我在这里一直在阅读各种内容以及有关HTML5视频标签,WebRTC,HLS等新奇世界的网络,并且还没有看到任何看起来像一个明智而完整的解决方案,并且没有涉及任何额外的转换/转码/重新流式传输,

I've been reading all sorts of stuff here and around the web about the brave new world of the HTML5 video tag, WebRTC, HLS, etc. and have yet to see anything that looks like a sensible and complete solution that doesn't involve some extra conversion/transcoding/re-streaming, often by some half-supported framework or an extra server in the middle which is not a viable solution.

我还没有找到关于可能或可能发生的情况的正确描述无论是将相同的基本视频流封装成稍微不同的包装,还是有很多开销且一切都不同,都无需将其流转换为html5-video-like。同样,不清楚是否可以使用JS在板载或什至在浏览器内实现转换。

I haven't yet found a proper description of what may or may not be required to "convert" our stream to whatever-html5-video-likes, whether it's just a slightly different wrapper around the same basic video stream or if there's a lot of overhead and everything is different. Likewise it's not clear if the conversion could be achieved either on-board or perhaps even in-browser using JS.

标题的原因是,如果我们有为了改变所有工作的方式,我们可能希望尽可能做最佳实践和合理的面向未来的事情,而不是在下一轮浏览器更新/下一个W3C之后可能无法工作的权宜之计新闻稿...

The reason for the title is that if we've got to change the way it all works we may as well aim to do whatever is considered "best practice" and reasonably future-proof as far as possible rather than some expedient fudge that might not work beyond the next round of browser updates / the next W3C press release...

我感到有点失望(但也许并不奇怪),2017年似乎没有明智的方式实现这一目标。

I find it slightly disappointing (but perhaps not surprising) that in 2017 there seems to be no sensible way of achieving this.

也许最差实践是更合适的术语……

Perhaps "least worst practice" would be more suitable terminology...

推荐答案

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

There are many methods you can use that don't require transcoding.

如果您使用的是RTSP ,您就可以通过WebRTC发送流。

If you're using RTSP, you're much of the way there in sending your streams via WebRTC.

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

WebRTC uses SDP for declaring streams, and RTP for the transport of these streams. There are some other layers you need for setting up the WebRTC call, but none of these require particularly expensive computation. Most (all?) WebRTC clients will support H.264 decoding, many with hardware acceleration in-browser.

最简单的WebRTC入门方法是实现浏览器浏览器客户端。然后,您可以对自己的实现进行更深入的研究。

The easiest way to get started with WebRTC is to implement a browser-to-browser client first. Then, you can go a layer deeper with your own implementation.

WebRTC是我向您推荐的方法。 NAT遍历(大多数情况下)和P2P连接是内置的,因此您的客户不必记住IP地址。只需提供信令服务,您的客户就可以从任何地方直接连接到家里的摄像机。提供TURN服务器,即使两端都经过防火墙保护,它们也可以连接。如果您不希望提供此类服务,则它们是轻量级的,可以像今天一样在相机上直接运行。

WebRTC is the route I recommend to you. NAT traversal (in most cases) and P2P connectivity are built-in, so your customers won't have to remember IP addresses. Simply provide signalling services and your customers can connect directly to their cameras at home from wherever. Provide TURN servers, and they'll be able to connect even if both ends are firewalled. If you don't wish to provide such services, they're lightweight and can run directly on the camera in a mode like you have today.

此方法比WebRTC简单得多,但与您所使用的完全不同现在做。您可以获取H.264流,并将其直接包装在MP4中,而无需进行转码。然后,可以在页面上的< video> 标签中播放它。您必须在代码中实现适当的库,但这是一个FFmpeg示例,该示例输出到STDOUT,您将通过管道将该管道发送给客户端:

This method is much simpler than WebRTC, but totally different than what you're doing now. You can take your H.264 stream, and wrap it directly in an MP4 without transcoding. Then, it can be played in a <video> tag on a page. You'll have to implement the appropriate libs in your code, but here's an FFmpeg example that outputs to STDOUT, which you'd pipe to clients:

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



其他...



在您的情况下,DASH没有任何其他好处。 DASH旨在利用基于文件的CDN进行流传输。您可以控制服务器,因此以类似文件的方式写出文件或处理HTTP请求毫无意义。虽然您当然可以在不进行转码的情况下将DASH与H.264流一起使用,但我认为这是在浪费您的时间。

Others...

In your case, there's no added benefit to DASH. DASH is intended for utilizing file-based CDNs for streaming. You control the server, so there's no point in writing out files or handling HTTP requests in a file-like manner. While you can certainly use DASH with H.264 streams without transcoding, I think it's a waste of your time.

HLS几乎相同。您的流与HLS兼容,但是HLS由于其在编解码器上的灵活性不足而迅速失宠。 DASH和HLS本质上是相同的机制...将一堆媒体片段写入CDN,并创建播放列表或清单以指示它们的位置。

HLS is much the same. Your stream is compatible with HLS, but HLS is dropping out of favor rapidly due to its lack of flexibility on codec. DASH and HLS are essentially the same mechanism... write a bunch of media segments to a CDN and create a playlist or manifest indicating where they are.

这篇关于当前在Web浏览器中流式传输实时视频的最佳做法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆