只有tcp 没有rtsp

RTSP is a simple signaling protocol which they cannot replace with anything for many years already, and it has to be admitted that they don't try really hard.

RTSP是一种简单的信令协议，它们已经很多年不能替换任何东西，必须承认它们并没有真正努力。

For example, we have an IP camera that supports RTSP. Anyone who has ever tested the traffic with a Sharkwire cable will tell you that first there comes DESCRIBE, then PLAY, and then the traffic begins to pour directly via RTP or wrapped in the TCP channel for instance.

例如，我们有一个支持RTSP的IP摄像机。 曾经用Sharkwire电缆测试过流量的任何人都会告诉您，首先是DESCRIBE，然后是PLAY，然后流量开始直接通过RTP倒入或包装在TCP通道中。

A typical scheme of establishing a RTSP connection looks like this:

建立RTSP连接的典型方案如下所示：

It is conceivable that the RTSP protocol support is unnecessary for browsers and of about as much use as the fifth wheel, therefore browsers are not in a hurry to implement it on a massive scale, and that will hardly ever happen. On the other hand, browsers could create direct TCP connections, and that would solve the task, but now it bumps up against security issues: have you ever seen a browser that would allow a script to use transport protocols directly?

可以想象，RTSP协议支持对于浏览器来说是不必要的，其用途与第五轮差不多。因此，浏览器并不急于大规模实现它，而且这种情况几乎不会发生。 另一方面，浏览器可以创建直接的TCP连接，并且可以解决该任务，但是现在它遇到了安全问题：您见过一款允许脚本直接使用传输协议的浏览器吗？

But the people demand that streams be available in “any browser without installing any additional software”, and startuppers write on their websites, “you don’t have to install anything, it will work in all browsers out of the box”, when they want to show a stream from an IP camera.

但是人们要求流在“任何浏览器中都可以安装而不安装任何其他软件的情况下可用”，并且初学者在他们的网站上写道：“您无需安装任何东西，它就可以在所有浏览器中正常使用”，当他们想要显示来自IP摄像机的流。

In this article we are going to explore how this can be achieved. And as the upcoming year contains a round figure, let’s add some topicality to our article and stick a label with 2020 to it, especially as it is really so.

在本文中，我们将探讨如何实现这一目标。 而且由于即将到来的一年包含一个整数，所以让我们在文章中添加一些话题性，并在其上贴上2020年的标签，尤其是事实如此。

So, which video display technologies for a web page have to be forgotten in the year of 2020? It’s Flash in the browser. It is dead. It doesn’t exist anymore, cross it off the list.

那么，到2020年，必须忘记哪种网页视频显示技术？ 它是浏览器中的Flash。 死了 它不再存在，将其从列表中删除。

三种有用的方法 (Three useful methods)

The tools which will allow you to watch a video stream in your browser today are:

现在，可用于在浏览器中观看视频流的工具有：

1. WebRTCWebRTC
2. HLSHLS
3. Websocket + MSEWebsocket + MSE

WebRTC有什么问题 (What is wrong with WebRTC)

In two words: it is resource-intensive and complicated.

简而言之，这是资源密集型且复杂的。

You will wave it away, “What do you mean by resource-intensive?”, as the CPUs are powerful nowadays, the memory is cheap, so what’s the problem? Well, firstly, it is compulsory encryption of all the traffic even if you do not need it. Secondly, WebRTC is a complicated two-way connection and peer-to-peer feedback exchange about the channel quality (peer-to-server, in this case): at every moment of time there is bitrate calculated, packet losses detected, decisions on their redirecting taken, and audio-to-video synchronization is calculated with regard to all of that, the so-called lipsync, that makes the speaker’s lips coincide with their words. All these calculations, as well as the incoming traffic on the server, allocate and free gigabytes of the RAM in real time, and if anything goes wrong a 256-gigabyte server with a 48-core CPU will go into a tail-spin easily despite all the gigaherzs, nanometers, and DDR 10 on board.

您会挥霍它，“您所说的资源密集型意味着什么？”，由于当今CPU功能强大，内存价格便宜，所以出了什么问题？ 好吧，首先，它是对所有流量的强制加密，即使您不需要它也是如此。 其次，WebRTC是一个复杂的双向连接和关于信道质量的对等反馈交换(在这种情况下，是对等服务器)：在每时每刻都计算比特率，检测到丢包，做出决定。进行重定向，并针对所有这些计算音频到视频的同步，即所谓的lipsync，它使说话者的嘴唇与他们的单词重合。 所有这些计算以及服务器上的传入流量都会实时分配和释放GB的RAM，如果出现任何问题，带有48核CPU的256 GB服务器将很容易陷入尾旋状态，尽管板载所有千兆赫，纳米和DDR 10。

So, it’s kind of hunting squirrels with an Iskander missile. All we need to suck out is a RTSP stream, and then display it, and what WebRTC says is, “Yes, c’mon, but you’ll have to pay for it.”

因此，这是一种用伊斯坎德尔导弹猎杀松鼠的游戏。 我们需要吸收的只是一个RTSP流，然后显示它，WebRTC所说的是：“是的，来吧，但您必须为此付费。”

为什么WebRTC很好 (Why WebRTC is good)

The latency. It is really low. If you are ready to sacrifice the performance and complexity for the low latency, WebRTC is the most suitable variant for you.

延迟时间。 真的很低。 如果您准备牺牲低延迟的性能和复杂性，则WebRTC是最适合您的变体。

为什么HLS好 (Why HLS is good)

In two words: it can work everywhere

用两个词来说：它可以在任何地方工作

HLS is a slow off-roader in the world of displaying live content. It can work everywhere due to two things: the HTTP-transport and Apple’s patronage. Indeed, the HTTP protocol is omnipresent, I can feel its presence even when I’m writing these lines. So, no matter where you are and what ancient tablet you use to surf the net, HLS (HTTP Live Streaming) will get to you and deliver the video to your screen sure enough.

HLS在显示实时内容的世界中是一个缓慢的越野车。 由于以下两点，它可以在任何地方工作：HTTP传输和Apple的支持。 确实，HTTP协议无处不在，即使我在编写这些行时也能感觉到它的存在。 因此，无论您身在何处以及使用哪种古老的平板电脑上网，HLS(HTTP实时流)都将带给您并将视频足够可靠地传递到屏幕上。

It’s all good enough, but...

一切都很好，但是...

为什么HLS不好 (Why HLS is bad)

The latency. There are, for example, projects of construction site video surveillance. A facility is under construction for years, and during all that time the poor camera records videos of the construction site day and night, 24/7. This is an example of a situation where the low latency is not needed.

延迟时间。 例如，有建筑工地视频监控项目。 一个设施正在建设中多年，在这段时间里，可怜的摄像机全天候24/7记录着建筑工地的视频。 这是不需要低等待时间的情况的示例。

Another example is boars. Real boars. Ohio's farmers suffer from an invasion of wild boars which feed on the crops and trample them down like locusts, therefore posing a threat to the financial well-being of the farms. Enterprising startuppers have launched a system of video surveillance from RTSP cameras which monitors the grounds in real time and triggers a trap when the intruders invade. In this case the low latency is critically important, and if HLS is used (with a 15-second latency), the boars will run away before the trap is activated.

另一个例子是公猪。 真正的野猪。 俄亥俄州的农民遭受野猪的入侵，这些野猪以农作物为食并像蝗虫一样被践踏，因此对农场的财务状况构成了威胁。 进取的创业者已经启动了一个RTSP摄像机的视频监视系统，该系统可以实时监视地面并在入侵者入侵时触发陷阱。 在这种情况下，低延迟至关重要，如果使用HLS(延迟时间为15秒)，公猪将在激活陷阱之前逃跑。

Here is one more example: video presentations where someone demonstrates a product to you and expects a prompt response. In the case of a high latency, they will show the product to you on the camera, then ask, “So how do you like it?”, and that will reach you only in 15 seconds. Within 15 seconds, the signal may travel to the Moon and back 12 times. No, we don’t want such latency. It rather looks like a pre-recorded video than Live. But pre-recorded video, as this is how HLS works: it records portions of a video on a disc or to the server’s memory, and the player downloads the recorded portions. This is how HTTP Live works which isn’t Live at all.

这是另一个示例：视频演示，其中有人向您演示产品并期望得到快速响应。 在高延迟的情况下，他们会在相机上向您展示产品，然后问：“您感觉如何？”，这只会在15秒内到达您的手中。 在15秒钟内，信号可能传播到月球并返回12次。 不，我们不希望这样的延迟。 它看起来更像是预录制的视频，而不是实时的。 但是预录制的视频(这就是HLS的工作方式)：它将视频的一部分记录在光盘上或服务器的内存中，然后播放器下载记录的部分。 这就是HTTP Live的工作方式，而根本不存在。

Why does it happen? The HTTP protocol’s global presence and its simplicity results in its sluggishness as HTTP was not initially intended for quick downloading and displaying of thousands of large video fragments (HLS segments). They are of course downloaded and played with high quality, but very slowly: it takes those 15 seconds or more for them to be downloaded, buffered, and decoded.

为什么会发生？ HTTP协议的全球存在及其简单性导致其速度缓慢，因为HTTP最初并不旨在快速下载和显示数千个大型视频片段(HLS段)。 当然，它们的下载和播放质量很高，但速度却很慢：下载，缓冲和解码它们需要15秒钟或更长时间。

It has to be noted here that Apple announced its HLS Low Latency in autumn of 2019, but that’s a different story already. Let’s take a more detailed look at their results later. And now we also have MSE in stock.

必须注意的是，苹果于2019年秋季宣布了HLS Low Latency，但这已经是另一回事了。 稍后让我们更详细地查看它们的结果。 现在，我们也有MSE库存。

为什么MSE不错 (Why MSE is good)

Media Source Extension is native support of playing packet videos in the browser. It can be called a native player for H.264 and AAC, which you can feed video segments to, and which is not bound to a transport protocol, unlike HLS. For this reason, you can choose the transport via the Websockets protocol. In other words, the segments will not be downloaded using the ancient Request-Response (HTTP) technology anymore but pouring readily via the Websockets connection which is almost a direct TCP channel. This is of great help in regards to decreasing the delays which can become as low as 3-5 seconds. Such latency is not fantastic but suitable for most projects which do not require a hard real-time. The complexity and resource-intensity are relatively low as well because a TCP channel is opened, and almost the same HLS segments pour through it, which are collected by the player and sent to be played.

Media Source Extension是在浏览器中播放分组视频的本机支持。 可以将其称为H.264和AAC的本机播放器，与HLS不同，您可以将其输入视频段，并且不绑定传输协议。 因此，您可以通过Websockets协议选择传输方式。 换句话说，将不再使用古老的请求-响应(HTTP)技术下载这些段，而是通过几乎是直接TCP通道的Websockets连接轻松倒入这些段。 这对于减少延迟(可以降低到3-5秒)很有帮助。 这样的延迟并不理想，但是适用于大多数不需要硬实时的项目。 复杂度和资源强度也较低，这是因为打开了TCP通道，并且几乎相同的HLS段从中流过，这些段由播放器收集并发送给播放。

为什么MSE不好 (Why MSE is bad)

It cannot work everywhere. The same as with WebRTC, its penetration into browsers is lower. iPhones (iOS) have an especially remarkable history of failure to play MSE, which makes MSE hardly suitable as the sole solution for a startup. It is fully available in the following browsers: Edge, Firefox, Chrome, Safari, Android Browser, Opera Mobile, Chrome for Android, Firefox for Android, UC Browser for Android.

它不能在任何地方工作。 与WebRTC相同，它在浏览器中的渗透率较低。 iPhone(iOS)在无法运行MSE方面有着特别出色的历史，这使得MSE几乎不适合作为初创企业的唯一解决方案。 它在以下浏览器中完全可用：Edge，Firefox，Chrome，Safari，Android浏览器，Opera Mobile，Chrome for Android，Firefox for Android和UC Browser。

Limited support of MSE appeared in iOS Safari quite a short time ago, starting with iOS 13.

从iOS 13开始，iOS Safari不久就出现了对MSE的有限支持。

RTSP腿 (RTSP leg)

We have discussed the delivery in the video server > browser direction. Besides that, you will also need these two things:

我们已经讨论了视频服务器>浏览器方向的交付。 除此之外，您还需要这两件事：

1) To deliver your video from the IP camera to the server. 2) To convert the video into one of the formats / protocols described above.

1)将视频从IP摄像机传送到服务器。 2)将视频转换为上述格式/协议之一。

This is where the server side comes in.

这是服务器端出现的地方。

Ta-dah… Meet Web Call Server 5 (or simply WCS for friends). Someone has to receive the RTSP traffic, de-packetize the video correctly, convert it into WebRTC, HLS or MSE, preferably without being overcompressed by the transcoder, and send it towards the browser in presentable shape, not corrupted with artifacts and freezes.

Ta-dah…与Web Call Server 5见面(或者对朋友来说只是WCS)。 必须有人来接收RTSP流量，正确地对视频进行解包，将其转换为WebRTC，HLS或MSE(最好不要被转码器过度压缩)，然后以可呈现的形状将其发送到浏览器，而不会被伪影和冻结损坏。

The task is not complicated at a first glance, but there can be so many hidden pitfalls, Chinese cameras, and conversion nuances lying behind it that it’s really horrible. It isn’t possible without hacks as a matter of fact, but it works, and works well. In production.

这项任务乍一看并不复杂，但是背后隐藏着许多隐藏的陷阱，中文摄像机和转换细微差别，这真的很可怕。 事实上，没有黑客是不可能的，但是它行之有效。 在生产中。

交付方案 (The delivery scheme)

As the result, a complete scheme of RTSP content delivery with conversion on an intermediate server begins to take shape.

结果，在中间服务器上进行转换的RTSP内容交付的完整方案开始形成。

One of the most frequently asked questions from our Indian colleagues is, “Is it possible? Directly, without a server?”. No, it isn’t; you will need the server side that will do the work. In the cloud, on hardware, on corei7 in your balcony, but you cannot do without it.

我们印度同事最常问的问题之一是：“有可能吗？ 直接地，没有服务器？”。 不，不是；不是。 您将需要服务器端来完成工作。 在云中，在硬件上，在阳台上的corei7上，但是没有它，您就无法做到。

让我们回到2020年 (Let’s get back to our year 2020)

So, here’s the recipe for cooking a RTSP in your browser:

因此，以下是在浏览器中烹饪RTSP的方法：

1. Take a fresh WCS (Web Call Server).

   换一个新的WCS(Web呼叫服务器) 。

2. Add WebRTC, HLS or MSE to taste. 添加WebRTC，HLS或MSE进行品尝。

3. Serve them on the web page.

   服务他们在网页上。

   Enjoy your meal!

   请享用！

不，还不是全部。 (No, this isn’t all yet.)

The inquiring neurons will definitely want to ask this question, “How? Really, how can this be done? What will it look like in the browser?”

询问神经元肯定会问这个问题：“如何？ 真的，这怎么办 ？ 在浏览器中会是什么样？”

We would like to bring to your attention the minimalistic WebRTC player assembled as a kitchen-table effort.

我们希望引起您的注意，将简约的WebRTC播放器组装成厨房工具。

1) Connect the main API script flashphoner.js and the script my_player.js, which we are going to create a bit later, to the web page.

1)将主要API脚本flashphoner.js和我们稍后要创建的脚本my_player.js连接到网页。

<script type="text/javascript" src="../../../../flashphoner.js"></script>
<script type="text/javascript" src=my_player.js"></script>

2) Initialize API in the body of the web page

2)在网页正文中初始化API

<body onload="init_api()">

3) Add div, which will serve as a container for the videos, to the page. Set the sizes and the boundary for it.

3)在页面上添加div，它将作为视频的容器。 设置大小和边界。

<div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div>

4) Add the Play button, the clicking on which will initialize connection to the server and start playing the video

4)添加播放按钮，单击将初始化与服务器的连接并开始播放视频

<input type="button" onclick="connect()" value="PLAY"/>

5) Now let’s create the script my_player.js which will contain the main code of our player. Describe the constants and variables

5)现在，我们创建脚本my_player.js，其中将包含播放器的主要代码。 描述常量和变量

var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS;
var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS;
var session;

6) Initialize API when a HTML page is loaded

6)加载HTML页面时初始化API

function init_api() {console.log("init api");Flashphoner.init({});
}

7) Connect to the WCS server via WebSocket. For everything to function correctly, replace "wss://demo.flashphoner.com" with your WCS address

7)通过WebSocket连接到WCS服务器。 为使一切正常运行，请用您的WCS地址替换“ wss：//demo.flashphoner.com”

function connect() {session = Flashphoner.createSession({urlServer: "wss://demo.flashphoner.com"}).on(SESSION_STATUS.ESTABLISHED, function(session){    console.log("connection established");playStream(session);});
}

8) After that, transmit the following two parameters, “name” and “display”, where “name” is the RTSP URL of the stream being played, and “display” is the element of myVideo which our player will be installed into. Set the URL of your stream here as well, instead of ours.

8)之后，传输以下两个参数，“名称”和“显示”，其中“名称”是正在播放的流的RTSP URL，“显示”是将安装我们的播放器的myVideo元素。 在此处(而不是我们的位置)也设置您的流的URL。

function playStream() {var options = {name:"rtsp://b1.dnsdojo.com:1935/live/sys2.stream",display:document.getElementById("myVideo")};  var stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {console.log("playing");});stream.play();
}

Save the files and try to launch the player. Is your RTSP stream played?

保存文件，然后尝试启动播放器。 是否播放过RTSP流？

When we tested it, this one was played: rtsp://b1.dnsdojo.com:1935/live/sys2.stream.

当我们对其进行测试时 ，播放了该文件：rtsp：//b1.dnsdojo.com：1935 / live / sys2.stream。

And this is what it looks like:

这是它的样子：

The player before the Play button is clicked on

单击播放按钮之前的播放器

The player with a video launched

播放视频的播放器

There is not much code at all:

根本没有太多代码：

HTML

HTML

<!DOCTYPE html>
<html lang="en">
<head>   <script type="text/javascript" src="../../../../flashphoner.js"></script><script type="text/javascript" src=my_player.js"></script>
</head><body onload="init_api()">
<div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div>
<br/><input type="button" onclick="connect()" value="PLAY"/>
</body>
</html>

JavaScript

JavaScript

//Status constants
var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS;
var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS;//Websocket session
var session;//Init Flashphoner API on page load
function init_api() {console.log("init api");Flashphoner.init({});
}//Connect to WCS server over websockets
function connect() {session = Flashphoner.createSession({urlServer: "wss://demo.flashphoner.com"}).on(SESSION_STATUS.ESTABLISHED, function(session){       console.log("connection established");playStream(session);});
}//Playing stream with given name and mount the stream into myVideo div element
function playStream() {var options = {"rtsp://b1.dnsdojo.com:1935/live/sys2.stream",display:document.getElementById("myVideo")};    var stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {console.log("playing");});stream.play();
}

demo.flashphoner.com is used as the server side. The full code of the example is available below, at the foot of the page containing the links. Have a pleasant streaming!

demo.flashphoner.com用作服务器端。 该示例的完整代码位于下面包含链接的页面的底部。 祝您流媒体愉快！

链接 (Links)

Player code on github

github上的播放器代码

Integration of an RTSP player into a web page or mobile application

将RTSP播放器集成到网页或移动应用程序中

翻译自: https://habr.com/en/company/flashphoner/blog/479008/

只有tcp 没有rtsp