各位老铁们，大家好，今天由我来为大家分享视频转发服务器，以及媒体转发服务器是什么的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
一、做一个视频通话给自己用吧
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011年 6月 1日开源并在 Google、Mozilla、Opera支持下被纳入万维网联盟的 W3C推荐标准。
首先，他即是 API也是协议。
其次，他是浏览器进行音频与视频通话的 API，其实还有屏幕共享的功能。
最后，它现在已经处于 W3C标准，各大浏览器厂商已经对他进行兼容了。
但是如果我们想使用好 webrtc，就得先了解 websocket。而对于 websocket，大家应该都比较熟悉了，比如社交聊天、多人游戏、协同编辑、视频会议、基于位置的应用(地图)、等等需要高实时的场景。我们比较常用的、QQ、某些直播软件等等也都是基于 websocket实现消息与信令的转发。大家看到这里可能在信令这里迟疑了，接着看。
webrtc是 P2P的一种技术，什么是 P2P？其实就是端对端，就说是你的音频、视频流不经过服务器中转，由一端发送到另一端。
不经过服务器中转，也就说时候，如果通过过程中服务器突然崩溃，是不是通话还能继续？
是的！但是发送音频视频流前，一定是需要建立 P2P连接的，建立连接前一定需要服务器进行信令转发，这个信令就是通话两端的标识。
而如果想用 webrtc实现通话，就得先中转信令、建立连接。而建立连接的话最好是要用 websocket进行信令转发的。大家都知道，websocket是个通道，在这个通道的所有端，都可以收到任意一端的消息流，包括发消息的本人。
为什么不经过服务器就可以获取到对方的视频音频流呢？是因为建立了 P2P通道，这个 P2P在中转信令的时候就已经通了，传输视频音频流的时候还要啥服务器啊。这个时候，肯定有小伙伴表示怀疑，音频视频流可以不通过服务器？是的，我骗了大家，确实要经过服务器，但是只是线上需要服务器转发，如果我们是本地两台或者多台同一局域网的端进行 webrtc音频视频流的转发，确实不需要中转服务器，但是线上有可能需要，也有可能不需要，这里又涉及到了一个打洞的概念。
我们平常可能会听到比较牛 x的词汇，什么打洞、内网穿透、NAT穿越，各种高大上的东西，其实也是蛮好理解的。大家都知道，两个不同网络下的两台主机不可以进行通信，而是需要走公网或者说各自的网关。打洞、内网穿透、NAT穿越其实就是一个意思，就是使用 udp让我们两台非同一网络的主机互联，不走公网，实现连接。有玩过花生壳的同学一定能理解内网穿透这个概念。
本地开发的话，两台主机连同一局域网，根本不需要内网穿透，就可以通信。
线上开发的话，如果能够 STUN打洞成功，也不需要中转服务器。但是，有打洞不成功的概率，为什么呢，因为没有走公网，没有给运营商带来收益却带来通信成本，肯定要限制。国外打洞成功的概率在 70%，但是国内 50%都不到。
所以，为了防止打洞不成功的情况，我们使用 TURN中转服务器转发流媒体数据进行一个最后保障。此外还有一种方式为逆向连接，也可以帮助我们实现 P2P建立，他的原理是必须是一方走公网，也是有局限*的。
coturn中继服务器由两部分组成 STUN与 TURN，STUN帮助我们打洞，TURN帮助我们转发流媒体数据。
##连接过程
以下所有 API截止到 2021.12.06为最新
##我有疑问
给大家看看 sdp的本质，就是自身的媒体信息和编解码信息
一个 offer，一个 answer，我们彼此都知道对方的媒体信息与编解码信息，这样我们才能好好协商，我这边该用什么方式对你的视频音频流进行解码、渲染。
过程有些繁杂，具体流程小伙伴们可以看这篇文章 WebRTC TURN协议初识及 turnserver实践。
了解 webrtc的音视频采集、桌面采集；
了解 websocket和 webrtc的整个链路建立过程；
实现 1V1文字传输、视频通话、语音通话、屏幕共享；
实现视频通话、语音通话、屏幕共享过程中的截图、录音、录屏及截图、录音、录屏的在线播放与;
将以上功能部署上线；
在这里，我们要对音视频建立过程画一个基本的流程图。
基本流程图
对于这些信令，我们使用 websocket进行转发，这里大家会问，为什么不使用 ？
首先，我们的要实现的 demo本来就含有发送普通文本消息的功能，就是使用 websocket。(长短轮询太老了，*能太差)
其次，第一点可以忽略，的请求会打回原路，A向服务器请求，绝对不会传向 B。
但是如果我们要使用 websocket转发信令，就要清楚的了解，在同一管道的所有端都会收到这条消息。所以，对于上面流程图来说，其实所有的小箭头都是双向的。
这时候，我们可以在 node服务中来控制推送消息的方向，也可以在客户端来控制，这里我选择在 AB端来控制。
其次，我们在本地开发，如果使用一台电脑，两个浏览器的形式，websocket文字消息是可以的。但是音视频通话不行，因为不管是传输通道还是音视频设备(麦克、扬声器等)都是冲突的。所以，我们可以通过同一局域网，使用两台电脑解决这个问题。并且，因为 webrtc的安全限制，必须使用 s(不管是线上还是本地)与域名，我们可以通过线上配置 s与域名，本地设置浏览器忽略 s与配置 host文件映射来解决这个问题。
接下来，我们使用 vue和 nodejs，可以最快最简单的实现 demo。
废话少说，我们开撕！
展示部分代码
这里我使用 socket.io这个第三方包，快速的首发消息，转发信令。(建议大家使用 vue-socket.io)可以在组件中收发消息与信令。
将 socket-io的 websocket建立连接与接收消息，接收信令放到 vuex中。
同样，我们在 node服务中，也是使用 socket-io这个包
对于视频、音频、及屏幕共享来说，代码都是类似的。所以，举例视频采集。
通过使用 getUserMedia，我们可以采集到音视频双轨的媒体流，我们传入一个参数 constraints，这个参数可以配置(控制采集音频还是视频)
将采集到的动态媒体流赋值给 video标签，我们自己的画面就显示在网页上了。
同样，如果是音频采集，只需要配置参数 constraints中的 audio为 false即可。
电脑屏幕采集，只需要将 getUserMedia这个 API替换为 getDisplayMedia即可。
此时视频端发起端，采集到了媒体流后，需要发送 ly信令给接收端。这个信令是询问接收端是否接起视频通话。
如果接起，接收端会采集自己的音视频双轨的媒体流，并且初始化 peerconnection，将媒体流放入此管道，监听 ICE候选信息如果收集到，就发送给对方，并将自己的同意信令 reply，回复给视频发起端。
如果拒绝接起，接收端会回复一个拒绝的信令给视频发起端。
接收端此时收到拒绝，会关闭视频音频流的采集。
接收端此时收到接起，会初始化 peerconnection，并将自己的媒体流放入此管道，监听 ICE候选信息如果收集到，就发送给对方。并且创建一个 offer(此 offer包含 sdp)，将 offer放到本地后，发送 offer给视频接收端。
视频接收端接收到 offer，放到自己的远端，并且创建一个 answer，将 answer放到本地后，发送给视频发起方。
视频发起方接收到 answer，将 answer放到远端。
此时，接收和发起端都在监听 ICE候选信息如果收集到，就发送给对方。一但监听到了就将对方的动态媒体流赋值给 B，播放出来。
截图：我们可以使用 canvas利用相关方法 getContext("2d").drawImage，实现 web层面的图片截取。
录音/录像/录屏：使用 MediaRecorder将我们的媒体流或者对方的媒体流保存到数组中。
只需要将保存的静态媒体流赋值给 video标签
同理，我们可以将音视频流下来。
部署 webrtc重要的两个条件：域名与 s，我们需要配置这两块。
我们的 node服务不仅是 s+域名，websocket也需要更为安全的 wss协议，我们需要给我们的 websocket配置 wss。
在前面我们也提过，本地开发之所以能够成功，并且有效果，是因为内网是通信的，并没有走公网，也就没有实现内网穿透。
如果我们想要在线上实现这个功能，我们必须配置 coturn中转服务器。centos内核的配置文章可以参考这篇，ubuntu内核的配置参考这篇。
在开发和上线后能够发现以下几个问题。
环境、设备、信号溢出、算法不兼容产生的噪音、声学与线路产生的回音、网络拥塞及数据包传输速率不稳定产生的延迟。
我们可以通过接入一些算法及提高硬件设备质量，来减少噪音回音，降低延迟。
对于噪音，采集音频时可以设置 noiseSuppression: true，可以降低一些环境及设备的噪音。
对于回声，采集音频时可以设置 echoCancellation: true，可以去除回声。
剩下的交给算法、设备和网络来处理了。
在这方面的探索，我就到此为止了，大家可以接着研究 WebRTC传输是如何保证音视频服务质量，研究一下成熟应用是如何解决这三大难点的。
大家在视频通话过程中，可以使用多种特效。美颜、贴纸等等。
然而在 webrtc的 web端领域，视频特效领域是非常潜的。造成这种情况的原因是 js的*能问题。
比较简单的方法就是使用 canvas画布，对我们的视频图象加一层滤镜，但是在本质上并没有改变媒体流。传输到远端仍然是没有特效的。当然，我们可以通过 websocket控制远端的视频特效，但是由于视频流没有改变，对方如果视频流的话，播放出来仍然是没有特效的。
另一种方案如下，这里我就不做赘述，大家可以思考一下是如何实现的(以下为简单特效与贴纸)。
需要创建 n-1个 PeerConnection连接，因为我们要与 n-1个人进行视频共享，每个人都是这样。但是这里会涉及谁主动发 offer的问题。我们可以让新加入的成员向其他 n-1个成员发送 offer，也可以使 n-1个成员向新加入的成员发送 offer。这里我们可以用遍历的方式生成 PeerConnection和 offer。当然多人通话就看你服务器顶不顶的住了。
这里我们就不知情的使用了多端通信的知名通信方案——Mesh，Mesh就是两两通信从而形成网状结构。除了 Mesh这种通信方案，还有 MCU，MCU方案主要是将同一房间的所有终端的音视频流进行混合然后发向各个终端，这样服务器的压力其实是非常巨大的。另外还有 SFU通信方案，中转服务器收到某终端音视频流后，单一转发到其他终端。
经过上面一系列的理解、思考、构建、开发、部署等等，我们对 webrtc有了一些初步的了解及认识。对于这方面的研究与探索我们都要继续继续深入下去。因为满足我们的好奇心与求知欲，提升我们的这一领域的技术，丰富我们整体的知识体系，何乐而不为呢。
最后，以上所有的内容都来源于资料、个人实验及个人总结，文中有错的地方希望大家及时指正。
二、手机视频监控的服务器和端口怎么设置
第一步：DVR本地设置，确认以下几点是否全部填写：\x0d\x0aa）进入网络配置-【基本配置】，将自动获取ip的勾取消，手动给硬盘录像机分配局域网“IP”，“子网掩码”，“网关”和“DNS服务器（建议填写8.8.8.8）”。\x0d\x0ab）进入【upnp】，将启用upnp的钩取消，不启用。\x0d\x0ac）进入【更多配置】，将rtsp端口改为1554。\x0d\x0a第二步：路由器端口映射\x0d\x0a提醒：在进行路由器端口映射之前，请务必关闭设备UPNP功能。\x0d\x0a登陆路由器的配置界面，找到虚拟服务器/端口映射/转发规则，进行映射端口的操作。\x0d\x0aa)设备80、8000、1554三个端口，缺一不可。\x0d\x0ab)若在同一台路由器上有多台监控设备，请使用不同的端口号来区分，不能重复使用。\x0d\x0a第三步：配置自定义域名\x0d\x0aa）主菜单—系统配置—网络配置—DDNS，勾选启用DDNS，设置设备域名和手机号码。\x0d\x0a设备域名自定义，请以小写字母开头，且整个域名中仅包含小写字母和数字。\x0d\x0a备注：配置界面中如有用户名密码，无须设置。\x0d\x0ab）当设备状态显示在线时可以使用自动生成的访问来访问设备。
三、代理服务器如何影响视频观看
代理服务器如何影响视频观看？
代理服务器如何影响视频观看？
代理服务器是一种网络服务器，用于充当客户端和服务器之间的中间层，从而可以实现一些特殊的功能。在视频观看过程中，代理服务器可以对视频的加载、速度、清晰度等方面产生重要的影响。
代理服务器可以带来的好处包括：提高网站安全*、提高网站速度、过滤网络流量、减轻服务器负载等。但是，在视频观看方面，代理服务器可能会对观看体验产生负面影响。
首先，代理服务器可能影响视频加载速度。当用户通过代理服务器请求视频时，代理服务器需要从目标服务器上获取视频资源，并将其转发给用户。这个过程可能需要更长的时间，这样就会使视频观看的等待时间变长。此外，由于代理服务器可能会在服务器和用户之间强制缓存已经获取的数据，这也会使视频加载速度变慢，因为代理服务器需要重新检查缓存内容。
其次，代理服务器可能会影响视频的清晰度。代理服务器有可能在传输时重新压缩视频，从而降低视频的清晰度。这种情况通常发生在代理服务器带宽受限或服务器之间的距离过大时。对于高清或超清视频，这种压缩可能会非常明显，导致观看体验质量下降。
此外，代理服务器还可能破坏视频流的连续*。这主要是因为代理服务器无法处理实时的视频，可能会强制刷新、更改和实时缓存流媒体内容。这种场景通常见于代理服务器使用的流缓存技术会根据其自身策略刷新流的某些部分，这可能会导致视频随机跳动，无法实现流畅播放。
综上所述，代理服务器在一定程度上可以影响视频观看，尤其是在缓存、加载速度以及流连续*方面。因此，在选择代理服务器时，需要选择服务器品质及合适的技术，以确保最佳观看体验。
四、腾讯的天王卡用开视频是不是免流量
1、目前腾讯天王卡使用的免流情况如下：
（1）朋友圈转发朋友自已发起的视频、图片或自己在朋友圈发送的小视频、图片免专属流量。
（2）的朋友圈中发送、转发的文章，打开文章后下拉网页，网页顶端如结尾显示为 qq.免专属流量。
（3）中的“按住说话”属于语音留言免专属流量。
（4）使用在线或离线传送文件及图片免专属流量。
（5）中的“语音聊天”和“视频聊天”属于专属流量。
2、不免流量情况：
（1）观看朋友圈分享的视频为第三方提供，则不在专属流量免费范围。
（2）朋友圈转发第三方的内容，如视频、音乐等不在专属流量免费范围。当中，访问第三方网站不在专属流量免费范围，例如：使用扫一扫、位置功能。
（2）在无线上网卡、移动WIFI、MIFI、平板电脑（如ipad）等设备使用。将手机号码作为手机热点使用。
3、您可进入【王卡助手】公众号自助查询腾讯王卡的免流范围，【王卡助手】入口：
1.服务-客服中心-免流特权；
2.特权-免流应用中心-免流说明。
以上路径以查询页面实际显示信息为准。
五、SIP网关***媒体转发服务器是什么
SIP网关就是就是语音网关。
流媒体服务器是一台可以独立组网的网络视频监控系统核心设备，兼容DVR、DVS、IPC等多种品牌和编码类型的网络视频编码设备联网通讯，为内网和外网的多用户网络并发访问提供服务，满足C/S和B/S架构的联网监控需求。
多个用户并发访问同一个视频源时，流媒体服务器与视频编码设备建立单路连接，将图像分发给请求服务的设备，既可消除因上传带宽不足导致网络阻塞，又可避免视频编码设备网传*能不足导致无法访问等现象，提高网络资源利用率。可保障系统正常运行，并支持大量用户网络访问，共享监控信息资源。