• [技术干货] IPC邀约一段时间后,视频拉流播放出现花屏情况,可以重新注册设备解决
    以前有遇到过如下问题:IPC在VIS成功邀约,持续正常使用几天后,从VIS拉取的视频流出现花屏的现象,经排查非本地网络问题后,通过下述方式解决。但是经服务侧排查未发现服务端有问题,而是IPC端给服务侧返回不可用的响应导致,通过IPC下线后重新注册即可解决。1. 在本地登录IPC的配置界面,如下以大华设备为例2. 使设备下线后重新上线    修改“SIP服务器IP”为一个不可用的IP,比如192.0.0.1(或者修改"SIP服务器端口"为一个不可用的端口,比如:5005)。点击确认,提示修改成功后,在VIS的console查看对应设备的状态变成:已下线。    然后再将“SIP服务器IP”修改为正确的IP值,点确认,生效后,再VIS的console查看对应的设备状态为:已上线。重新邀约后观察视频质量是否恢复正常。
  • [技术干货] RTSP/RTMP/SRT/RTP/HLS协议之间的特点
    RTP协议(Real-time Transport Protocol)是一个网络传输协议,是一种实时传输协议技术,RTP协议常用于流媒体系统(配合RTSP协议)视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP实时传输协议为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。RTSP协议是最早的视频传输协议,RTSP是实时流传输协议,是TCP/IP协议体系中的一个应用层协议,RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。RTSP还提供了一个可扩展框架,使实时数据,如音频与视频的受控点播成为可能,数据源包括现场数据与存储在剪辑中数据。RTSP协议优势在于可以控制到视频帧,因此可以承载实时性很高的应用。RTMP协议是(Real Time Messaging Protocol)实时消息传输协议,该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。RTMP是为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议。RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的。HLS协议 (HTTP Live Streaming)是Apple的动态码率自适应技术,主要用于PC和Apple终端的音视频服务。HLS协议的小切片方式会生成大量的文件,存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移,索引量将会是个巨额数字,并明显影响请求速度。因此,HLS协议对存储I/O要求相当苛刻。HLS只请求基本的HTTP报文,与实时传输协议(RTP)不同,HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。SRT协议是(Secure Reliable Transport)的简称,SRT由Haivision和Wowza合作成立的,管理和支持SRT协议开源应用的组织,这个组织致力于促进视频流解决方案的互通性,以及推动视频产业先驱协作前进,实现低延时网络视频传输。SRT是允许直接在信号源和目标之间建立连接,这与许多现有的视频传输系统形成了鲜明对比,这些系统需要一台集中式服务器从远程位置收集信号,并将其重定向到一个或多个目的地。基于中央服务器的体系结构有一个单点故障,在高通信量期间,这也可能成为瓶颈。通过集线器传输信号还增加了端到端信号传输时间,并可能使带宽成本加倍,因为需要实现两个链接:一个从源到中心集线器,另一个从中心到目的地。通过使用直接从源到目的地的连接,SRT可以减少延迟,消除中心瓶颈,并降低网络成本。       SRT协议它在UDT 的基础上进行了一些扩展和定制, 具备网络传输丢包检测/延迟控制/视频加密功能。
  • [技术干货] 新一代直播传输协议SRT
    SRT协议是基于UDT的传输协议,保留了UDT的核心思想和机制,抗丢包能力强,适用于复杂的网络。在LiveVideoStack线上分享中,新浪音视频架构师 施维对SRT协议的原理、优缺点特性以及在流媒体中的应用进行了详细解析。1. 为什么选择SRT?毋庸置疑,现今存量最大的直播协议是RTMP,但随着新技术的不断发展与使用场景的不断拓展,继续使用RTMP会令人感到有些力不从心。RTMP协议的缺陷主要有以下四个方面:RTMP协议缺陷首先,RTMP协议太老,且最后一次更新是在2012年;同时HEVC/H.265/AV1等视频格式都没有官方定义,以至于需要国内CDN厂商自行定义。RTMP连接过程较长,由于RTMP基于TCP(TCP存在三次握手),除此之外,其本身又存在c0/s0到c2/s2的三次握手,再加上connection,createstream,play/publish,总地来说RTMP完成一次建连需要进行9次会话,用于PC端勉强能够接受,对于移动端网络质量的要求则很高。RTMP的拥塞控制完全依赖传输层,即完全依赖于TCP传输层的拥塞控制算法来进行拥塞管理,几乎没有什么优化;RTMP本身基于TCP传输,无法提供带宽自适应的算法。在此背景下,众多厂商开始着手提供一些新的直播协议供行业参考。如QUIC、SRT等。本次我们将重点讲述SRT的特点与应用。SRT协议的特点Haivision联手Wowza在UDT的基础上针对音视频实时性提出了SRT协议。SRT是基于UDT的协议(UDT协议是基于UDP的传输协议,在IETF已经提交了4个版本),具有非常良好的丢包重传机制,丢包重传的控制消息非常丰富,同时支持ACK、ACKACK、NACK。我们都知道音视频对于时间这一点非常在意,而SRT基于时间的报文发送,使其具有良好的防止流量突发的能力。SRT对上层提供了丰富的拥塞控制统计信息,包括RTT、丢包率、inflight、send/receive bitrate等。利用这些丰富的信息,我们可以实现带宽预测,并根据带宽的变化在编码层去做自适应动态编码与拥塞控制。2. SRT协议原理分析2.1 SRT基本思想上图可以涵盖SRT的基本思想:对比编码后的视音频码流(左侧绿色折线“Source”)与经过公网传输后的码流(红色折线“NetworkTransmission”),可以看到编码后的源视音频码流具有固定的帧间隔与一定特性的可变比特率,但经过公网传输后的码流,其帧间隔变得不固定且码率特性也被完全改变,解码这样的信号是一项十分艰巨的挑战,甚至根本无法解码。而如果使用加入纠错的SRT协议进行公共互联网传输,尽管编码后的视音频码流经过公网传输帧间隔变得不固定,但由于SRT协议封装中包含精准的时间戳,解码接收端可以通过该时间戳重现固定的帧间隔。更重要的是,通过规定延时量,同时划定了send buffer(发送端缓冲区)与receive buffer(接收端缓冲区),来自接收端的反馈信号(可以理解为后向纠错)通过一系列的设置、纠错、流量控制,使编码后的视音频码流拥有与原码流几乎一样的码率特性。Encoder编码器处理完成的数据会被输入send buffer,send buffer会对数据进行时间校验,也就是按照一定的时间顺序编码并通过internet发送至receivebuffer,receive buffer按照报文上的时间戳一点点处理,确保生成的数据与源码流基本一致。整个SRT协议的思想基于编码,具有抗丢包、抗拥塞、抗抖动等特性。2.2 SRT报文基础交互过程SRT的报文基础也就是其交互过程依次为以上五个步骤:握手(Handshake)、重要信息(Capability)、媒体(Media)、控制信息(Control)与关闭(Shutdown)。与RTMP的九次握手不同,SRT的建连过程仅需两个RTT。也就是Handshake Request与Capability Announce。Caller与Listener之间的进行的Handshake Request是一个简化版的握手,用以提高效率;握手之后Caller与Listener间进行重要信息的交换,整个SRT的第一项关键步骤就是Caller与Listener在这里交换了延时量与缓冲区的大小;随后Caller与Listener之间开始媒体数据的传输,同时也传输了为恢复帧间隔而封装的精准时间戳;SRT的第二项关键步骤是Listener向Caller同步控制信息,用以对抗公网中的抖动、丢包等一系列突发状况;最后,待至媒体数据传输完毕之后关闭传输。数据报文 SRT的报文格式较为简单,分为数据报文与控制报文。上图展示了数据报文的数据结构,观察结构我们可以发现上方两层为UDP部分,而在这之下是UDT部分。如果初始化为0,则认为其是数据报文。FF表示报文的序列, 0b10是分片的第一个报文,0b00是分片的中间报文,0b01是分片的最后一个报文,0b11表示单个报文并没有分片。KK表示是否加密,R表示是否属于重传报文,Timestamp表示时间戳,Destination Socket ID是SRT自定义的一个socket id。由该数据结构我们可以看出:SRT的数据报文拥有精准的32位时间戳,package sequence number绝对够用,且结构非常简单。下图展示的则是控制报文的数据结构,右侧表格展示了控制报文的常规类型,其中值得重点关注的有ACK、NACK、ACKACK等。控制报文2.3 SRT丢包重传2.3.1 Send/Receive BufferSRT在接收和发送端都有receive buffer与send buffer,send Buffer严格按照时间戳间隔来发送,定时器默认10毫秒。 2.3.2 ACK丢包重传最常见的便是ACK机制。以上图为例,假设发送端缓冲区发送五个数据包:1、2、3、4、5给接收端缓冲区,接收端缓冲区成功接收到这些数据包之后会向发送端缓冲区发送ACK——肯定应答已表示数据包被成功接收,发送端接收到ACK——肯定应答之后回收空间,删除1、2、3、4、5这五个数据包并准备发送数据包6。send buffer完全按照时间戳间隔处理数据,在确定的间隔(与ACKs,ACKACKs 和 Round Trip Time相关),接收方发送ACK给发送方,使得发送方把收到ack的packet从sender buffer中移除,其在buffer中的空间点将被回收。接收端的receivebuffer中存在Latency Window也就是延迟窗口,其作用为按照时间戳一点点上送数据。并严格按照时间戳检测,检测周期默认为10毫秒。2.3.3 ACK/ACKACK/RTT接收端在收到数据包后会向发送端反馈表示成功接收的ACK,例如上图左侧,接收端在收到第十一个数据包后向发送端反馈ACK(11),而发送端在收到来自接收端的ACK(11)之后会向对端再发送一个ACKACK用以表示收到ACK(11)。这一过程最大的意义在于可让接收端计算出RTT,ACK发送的时间与对应ACKACK收到的时间之差就是RTT——Round Trip Time(RTT)是时间的度量,表示报文一个来回的耗时。SRT不能测量单方向的耗时,所以只能用RTT/2来表示单方向耗时。一个ACK(从接收方)会触发ACKACK(从发送方)的发送,几乎不带其他延时。RTT可评估当前网络质量,RTT高表示整个网络的延迟很大,RTT低则说明网络延迟较低。RTT由接收端计算而出,计算得出的RTT会通过ACK发送至发送端,发送端就可获知当前网络的质量如何。带宽情况是不断变化的,因此RTT也是一个随网络环境不断变化的实时动态值。2.3.4 ACK信息ACK报文包含了丰富的关键信息。其中Last Acknowledge Packet Sequence Number表示当前收到第几个包,RTT信息便于发送端评估网络的质量,RTT的变化表示网络变化情况。Available Buffer Size表示接收端缓存可用率,SRT是可以用作文件传输的,Available Buffer Size对文件传输的拥塞控制非常有用。当文件传输过快时接收端的内存缓存无法成功接收,此时发送端除了考虑网络还需要考虑接收端的性能与缓存是否有足够的空间与能力在短时间内接收庞大的文件。Packets Receiving Rate表示每秒钟的收包率,这里统计的是包的个数;而ReceivingRate表示接收包的比特率。总而言之,接收端以10毫秒为周期向发送端发送ACK,其中包括网络RTT信息、接收端缓存信息、接收端比特率等关键数据,其中以上三个数据至关重要,直接反映出发送端到接收端之间的网络环境状态。2.3.5 NACK常规情况下QUIC或TCP仅提供ACK方式,也就是接收端向发送端反馈哪些包成功接收;而WebRTC的RTP或RTCP常用选择NACK,也就是接收端向发送端反馈哪些包没有成功接收。NACK回传的是接收端没收到的数据包的列表。SRT同时支持ACK与NACK,这样设定的原因在我看来是带宽抢占的强势。例如,接收端向发送端发送ACK表示该数据包已经成功接收,不排除该ACK报文本身丢失,导致发送端以为数据报文丢失而要超时重发,实际接收端对该数据包已经成功接收了。还有一种情况是:NACK的周期性发送可能会造成发送端多发报文,例如发送端成功发送5号与6号数据包,却一直未收到来自接收端的ACK消息,当达到重发的时间时发送端再次发送5号与6号数据包,在此之后发送端收到了来自接收端的NACK消息,表示接收端未成功接收5号数据包与6号数据包;于是发送端第三次发送5号数据包与6号数据包。一个周期下来,发送端发了两次数据包。从协议原理角度分析,我们发现 SRT在丢包过程中对带宽的消耗比QUIC与其他协议要高。 一旦出现丢包,SRT的重传要多于其他协议,SRT以此来抢占带宽从而达到音视频的同步效果。2.4 SRT基于时间发送按时间发送是一个标准的音视频传输特性。我们知道编码器发送是以编码器的速度向外发送数据,但有时编码器会太乐观,完全按照编码输出向外发送会导致输出超过预期过高的比特率。在这种情况下SRT Packet就不会足够快地输出,因为SRT会最终被过低的错误配置影响到。2.5 可配置比特率SRT中包含三个配置选项:INPUTBW表示编码器输入带宽,MAXBW表示最大带宽,以及OVERHEAD(%)表示过载率,配置原则如上图所示:如果不配置INPUTBW与OVERHEAD(%)而仅配置MAXBW,则当前编码器输出的比特率是<mbw>也就是MAXBW;如果不配置MAXBW与INPUTBW而仅配置OVERHEAD(%),则当前编码器输出的比特率是<smpinpbw>(1080+<oh>)/100,默认为25%;第三种情况是不配置MAXBW而配置OVERHEAD(%)与INPUTBW,最大输出比特率便为<ibw>(100+<oh>)/100。SRT最大的特点便是可配置。在有配置的情况下按照配置来做,在无配置的情况下按实际测量的比特率来做。常规情况下我们不选择进行配置,尤其是针对互联网而言,因为单一配置无法保证能够在不同时段应对不同境况的网络。通常我们选择使用实际测量出的编码比特率计算:<smpinpbw>*(1080+<oh>)/100。2.6 SRT简单拥塞控制——简单,太简单接下来我们讨论一下SRT的流控。我们知道在丢包重传机制下,如果报文在网络传输中丢失,则发送端会重新发送。例如在某网络环境下发送端与接收端之间的带宽仅有1M,现在由于背景流量与噪声等影响,原来1M的带宽减少100k变成了900k,此时就会出现10%的丢包;发送端未收到来自接收端的ACK或者收到NACK认为出现丢包,于是尝试重传这10%的数据;但实际上发送端与接收端之间的带宽就剩下900k了,而加上丢包重传的发送量是1.1M,带宽变窄发送的流量不降反增,就会导致网络情况越来越糟糕,最后造成网络拥塞卡顿频繁,最后网络崩溃。SRT单纯地丢包重传不能解决网络拥塞的问题,出现网络拥塞的最好解决方案是限流,降低带宽流量压力。SRT的拥塞控制过于简单,仅在congctrl.cpp中实现。其包括以下几个变量:M_iFlowWindowSize表示接收方的缓存大小,m_dCWndSize等于1秒内发送的bytes数据 / (RTT + 10),sendbufer表示发送方未发送buffer大小。其中这里的1秒内发送的bytes数据,具体是指一个RTT内发送的数据。总结算法如下:m_iFlowWindowSize用以衡量接收方缓存是否耗尽,同时监测发送方每RTT发送数据size是否大于发送buffer大小。接收方缓存一般在传输文件时起作用。在我看来,SRT在拥塞控制方面做得还远远不够。2.7 SRT协议总结SRT在快速连接方面有明显优势,两次握手成功即可建连;SRT的丢包重传策略出色,ACK、ACKACK、NACK等提供了丰富的控制消息,还有RTT、Receive比特率等。但是同时我们经过测试也发现SRT在丢包时,发送数据的带宽占用率还是有些大,丢包率越高发送带宽占用越大。SRT按照时间发送音视频数据,根据实际的编码比特率来发送音视频数据;但SRT的拥塞控制过于简单,只针对接收方缓存是否有能力接收与编码比特率是否发送过快。 内容来自LiveVideoStack  作者:高阳链接:https://www.livevideostack.cn/news/新一代直播传输协议srt/如有疑问可联系删除
  • [技术研讨] 企业智慧屏会议协议
    已了解不管是welink还是cloudlink ,会议终端如TE系列均采用激活码方式,激活码获取方式为将设备SN注册华为云会议平台后发放。 智慧屏也是激活码但获取方式为购买。 企业智慧屏也可作为会议终端,与传统会议终端的原理有不同吗
  • [问题求助] 【物联网知识竞赛】+Profile协议可以在哪些协议的上层?
    Profile协议可以在哪些协议的上层?
  • [问题求助] 【物联网知识竞赛】Huawei LiteOS的互联框架能够提供哪些完整的协议栈?
    【物联网知识竞赛】Huawei LiteOS的互联框架能够提供哪些完整的协议栈?
  • [问题求助] 【物联网知识竞赛】+5G手机上,上网的数据解码协议与通话的数据解码协议不一样,那么以后开发版也会多种协议同时连接吗?
    5G手机上,上网的数据解码协议与通话的数据解码协议不一样,那么以后开发版也会多种协议同时连接吗?
  • [问题求助] 【物联网知识竞赛】+终端之间通信协议复杂多样,华为IoT推出的工业IoT网关如何解决这件事情,解决这事情的同时是否会增加程序处理
    终端之间通信协议复杂多样,华为IoT推出的工业IoT网关如何解决这件事情,解决这事情的同时是否会增加程序处理时间?
  • [Atlas 500] 如何修改海康威视摄像头的ip地址
    海康威视摄像头连接到网线后,使用设备网络搜索软件可以搜索到摄像头,然后使用账号密码可以修改ip地址。https://www.hikvision.com/cn/download_more_393.html#prettyPhoto
  • [问题求助] 智能水表适合CoPA协议吗
    智能水表适合CoPA协议吗
  • [问题求助] 【物联网知识竞赛】在设备管理中,SP Portal通过什么协议下发消息给DM Server?
    在设备管理中,SP Portal通过什么协议下发消息给DM Server?
  • [问题求助] 【物联网知识竞赛】COAP协议是怎么做安全的呢?
    COAP协议是怎么做安全的呢?
  • [问题求助] 【物联网知识竞赛】COAP 请求响应Response代码和HTTP协议类似吗?
    COAP协议是基于消息的双向通信(M2M),请求响应Response代码和HTTP协议类似吗?具体响应内容有哪些呢?
  • [问题求助] 【物联网知识竞赛】COAP协议可以实现可靠消息传输吗?
    大家都知道,UDP是一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,COAP协议通信是通过在UDP上传输消息,COAP协议是怎么实现可靠传输的呢?
  • [问题求助] 【物联网知识竞赛】共享单车采用的协议到底是什么?
    如题和图,为什么正确答案是使用coap协议的包括了共享单车?共享单车的原理图基本如下:共享单车不是基于MQTT协议的开锁指令与设备收到指令完成开锁的吗??