原微信小程序视频播放,当微信进入后台,再返回前台时,直播视频停止播放问题解决 .
在视频标签上加入 onpause="this.play();" 即可.
如下
<video playsinline autoplay controls style="width: 1600px;height: 920px;" onpause="this.play();" id="videoid"></video>
…
网络摄像头RTSP视频流WEB端实时播放实现方案
IPC视频流怎么实时在WEB浏览器播放，视频流格式是RTSP。
下面我整理了自己实现的方案以及网上看到的一些方案
…下面我整理了自己实现的方案以及网上看到的一些方案
一、FFmpeg + nginx 将转 hls 通过 video.js 在支持h5浏览器播放（我实现的）
参见：Nginx+FFmpeg实现rtsp流转hls流，在WEB通过H5 video实现视频播放
不足：hls延迟较rtmp、http-flv大
二、FFmpeg + nginx-rtmp-module + h5 video，rtsp转rtmp播放
https://blog.csdn.net/gui66497/article/details/78590190
https://blog.csdn.net/LLittleF/article/details/81111713
注：通过video.js播放rtmp流。需要将代码放到服务器，本地windows电脑无法播放
不足：需要浏览器开启flash
三、FFmpeg + nginx-http-flv-module + flv.js，rtsp转rtmp，直接播放flv格式
基于nginx-rtmp-module，通过配置将rtmp转为flv，最后通过flv.js播放。
https://github.com/winshining/nginx-http-flv-module/blob/master/README.CN.md
https://segmentfault.com/a/1190000016043297
https://blog.csdn.net/qq_22633333/article/details/96288603#comments
这种方式是最理想的，我目前找到的方案。当然单指不想花钱买收费方案的。
四、WebRTC
https://github.com/lulop-k/kurento-rtsp2webrtc
https://www.jianshu.com/p/1ddfa72de165
五、streamedian
原音频降噪音，回声消除，自动增益代码示例
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
<style>
html, body{
height: 100%;
width: 100%;
}
#video{
height: 300px;
width: 300px;
}
</style>
<script>
$(() => {
var constraints = {
audio: {
echoCancellationType: 'system',//browser|system
echoCancellation: true,
noiseSuppression: … 原html5调用摄像头代码
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Display Webcam Stream</title>
<style>
#container {
margin: 0px auto;
width: 500px;
height: 375px;
border: 10px #333 solid;
}
#videoElement {
width: 500px;
height: 375px;
background-color: #666;
}
</style>
</head>
<body>
<div id="container">
<video autoplay="true" … 34 | 如何使用Nginx搭建最简单的直播服务器？
在前面三篇文章中，我们介绍了传统直播系统架构、HLS 协议、RTMP 协议相关的知识，那今天我们就来具体实操一下，根据前面所学到的知识搭建出一套最简单的音视频直播系统。
今天我们要搭建的这套直播系统相较于《31 | 一对多直播系统 RTMP/HLS，你该选哪个？》一文中介绍的直播系统要简单得多。该系统不包括客户端、没有 CDN 分发，只包括最基本的推流、转发及拉流功能。虽然它简单了一点，但麻雀虽小五脏俱全，通过这样一个实战操作，我们就可以将前面讲解的理论与实际结合到一起了。
当然，作为一个直播系统来说，客户端是必不可少的。但由于时间和篇幅的原因，我们只能借助一些现成的或者开源的客户端对我们的直播系统进行测试了，所以客户端的界面可能会简陋一些。也正因为如此，我才没有将它们算作咱们这个直播实验平台之中。
实际上，我们完全可以以这个直播系统实验平台为原型，逐步地将一些功能添加进去，这样很快就可以构建出一套商业可用的传统直播系统了。
直播系统架构
在正式开始实战之前，我们先来简要介绍一下这个直播系统的架构，如下图所示：
最简单的直播系统
这个直播架构非常简单，由两部分组成，即媒体服务器和客户端。
媒体服务器有两个功能：
推流功能，可以让客户端通过 RTMP 协议将音视频流推送到媒体服务器上；
拉流功能，可以让客户端从媒体服务器上拉取 RTMP/HLS 流。
实际上，这个架构与我们前面介绍的传统直播架构相比是有变化的，减少了信令服务器，同时将 CDN 网络变成了一台流媒体服务器。但理解了整个直播架构的原理后，我们就可以快速地将这个简单的直播架构恢复成一个正式的、可商用的直播系统。
那对于我们这个简化的直播系统来说，如何实现架构中的媒体服务器呢？
这里我们使用了目前最流行的 Nginx 来实现它。之所以选用 Nginx 主要出于以下两方面的原因：
Nginx 的性能是很优越。在众多的
33 | FLV：适合录制的多媒体格式
虽然苹果拒绝使用 RTMP 协议并推出了自己的 HLS 技术，但大多数用户仍然还是使用 RTMP 协议作为传统直播系统的传输协议。在 Adobe 宣布不再对 RTMP 技术进行支持的情况下，仍然还有这么多用户在使用它，说明 RTMP 协议具有其他协议不可比拟的优势。
这里我们做个对比，你就知道 RTMP 协议的优势在哪里了。
首先，与 HLS 技术相比，RTMP 协议在传输时延上要比 HLS 小得多。主要原因在于 HLS 是基于切片（几秒钟视频的小文件）、然后缓存的技术，这种技术从原理上就比直接进行数据传输慢很多，事实也证明了这一点。
其次，相对于 RTP 协议，RTMP 底层是基于 TCP 协议的，所以它不用考虑数据丢包、乱序、网络抖动等问题，极大地减少了开发人员的工作量；而使用 RTP 协议，网络质量的保障都需要自己来完成。
最后，与现在越来越火的 WebRTC 技术相比，RTMP 也有它自己的优势。虽然在实时传输方面 WebRTC 甩 RTMP 技术几条街，但对于实时性要求并没有那么高的传统直播来说，RTMP
32 | HLS：实现一对多直播系统的必备协议
不过，随着 Chrome 浏览器宣布不再对 Flash 插件提供支持、Adobe 公司停止对 RTMP 协议更新以及苹果公司声称 iOS 上不允许使用 RTMP 协议等一系列事件的发生，我们可以断定 RTMP 协议已失去了未来。
而 HLS 协议则恰恰相反，它在未来会有更广阔的应用前景。我们可以通过以下几点来得到这个结论：
HLS 是苹果开发的协议，苹果产品原生支持此协议；
HLS 是基于 HTTP 的，可以不受防火墙限制，所以它的连通性会更好；
HLS 还能根据客户的网络带宽情况进行自适应码率的调整，这对于很多用户来说是非常有吸引力的。
基于以上原因，我们有必要从 HLS 直播架构、FFmpeg 生成
31 | 一对多直播系统RTMP/HLS，你该选哪个？
近年来，随着智能手机的普及以及移动互联网的飞速发展，音视频技术在各个行业得到了广泛的应用。尤其是娱乐直播在前几年着实火了一把，像映客、斗鱼这类以展示才艺为主的直播产品非常受大家的欢迎。
从技术角度来讲，映客、斗鱼这类娱乐直播与在线教育、音视频会议直播有着非常大的区别。在线教育、音视频会议这类直播属于实时互动直播，主要考虑传输的实时性，因此一般使用 UDP 作为底层传输协议；而娱乐直播对实时性要求不高，更多关注的是画面的质量、音视频是否卡顿等问题，所以一般采用 TCP 作为传输协议。我们称前者为实时互动直播，后者为传统直播。
本专栏的前两个模块都是介绍实时互动直播的，而从今天开始我们会讲解传统直播技术。
传统直播技术使用的传输协议是 RTMP 和 HLS。其中，RTMP 是由 Adobe 公司开发的，虽然不是国际标准，但也算是工业标准，在 PC 占有很大的市场；而 HLS 是由苹果公司开发的，主要用在它的 iOS 平台，不过 Android 3 以后的平台也是默认支持 HLS 协议的。
接下来，我们先看一下传统音视频直播系统的基本架构，让你对传统直播架构的“内幕”有一个初步的了解。
传统直播基本架构
商业级直播系统的规模、结构是非常复杂的，除了最核心的音视频直播外，还包括用户管理、认证系统、直播间管理、打赏、红包、私信等很多功能，不过这些更多的是一些业务逻辑，在本文中我们不会对它们进行讲解，而是聚焦在最核心的音视频直播技术上。
我们先来看一下传统直播的基本架构图，如下图所示：
传统直播基本架构图
从图中可以看出，传统直播架构由直播客户端、信令服务器和 CDN
24 | 多人音视频实时通讯是怎样的架构？
在前面的章节里，我们通过大量的篇幅介绍了 WebRTC 在浏览器上对实时通信的各种支持。WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看，Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。
如果你想要通过 WebRTC 实现多对多通信，该如何做呢？其实，基于 WebRTC 的多对多实时通信的开源项目也有很多，综合来看，多方通信架构无外乎以下三种方案。
Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向
21 | 如何保证数据传输的安全（上）？
数据安全越来越受到人们的重视，尤其是一些敏感数据，如重要的视频、音频等。在实现音视频通信的过程中，如果在网络上传输的音视频数据是未加密的，那么黑客就可以利用 Wireshark 等工具将它们录制下来，并很容易地将它们播放出来并泄漏出去。
如果这些音视频的内容涉及到股票交易或者其他一些更敏感的内容的话，很可能会造成不可挽回的损失。
对于浏览器更是如此，在全球至少有几亿用户在使用浏览器，这么大的用户量，如果通过浏览器进行音视频传输时，没有对音视频数据进行安全保护的话，那将会产生灾难性的后果。
既然数据安全这么重要，那接下来我将带你了解一下数据安全方面的相关概念。只有将这些基本概念搞清楚了，你才知道 WebRTC 是如何对数据进行防护的。
非对称加密
目前对于数据的安全保护多采用非对称加密，这一方法在我们的日常生活中被广泛应用。那什么是非对称加密呢？下面我就向你简要介绍一下。
在非对称加密中有两个特别重要的概念，即公钥与私钥。它们起到什么作用呢？这里我们可以结合一个具体的例子来了解一下它们的用处。
有一个人叫小 K，他有一把特制的锁，以及两把特制的钥匙——公钥和私钥。这把锁有个非常有意思的特点，那就是：用公钥上了锁，只能用私钥打开；而用私钥上的锁，则只能公钥打开。
这下好了，小 K 正好交了几个异性笔友，他们在书信往来的时候，难免有一些“小秘密”不想让别人知道。因此，小 K 多造了几把公钥，给每个笔友一把，当笔友给他写好的书信用公钥上了锁之后，就只能由小 K 打开，因为只有小 K 有私钥（公钥上的锁只有私钥可以打开），这样就保证了书信内容的安全。
从这个例子中，你可以看到小 K 的笔友使用公钥对内容进行了加密，只有小 K 可以用自己手中的私钥进行解密，这种对同一把锁使用不同钥匙进行加密 / 解密的方式称为非对称加密，而对称加密
近期评论