rtp延时最高多少，vlc播放rtp封装的h264延时很大是什么原因

来源：整理时间：2023-03-08 03:48:50 编辑：亚灵电子网手机版

1，vlc播放rtp封装的h264延时很大是什么原因

这是正常的，H264是H263的发展，除了263的优点外，还有更高的压缩比，有更好的图象质量。这也就意味着，同样码流情况下，264能够产生更好的视觉效果。

vlc播放rtp封装的h264延时很大是什么原因

2，RTPRTCP的2工作流程

RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流(H.263格式)发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：(1)打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。(2)创建一个UDP套接字并将其绑定到所提供服务的地址之上。(3)反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线程;对已经在服务中的客户则根据RTCP报告的内容调整服务。RTP实时服务线程1：初始化客户列表和RTP首部。RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。RTP实时服务线程3：更新RTP首部和统计数据。RTP实时服务线程4：计算延时，重复第二步。RTCP实时服务线程1：初始化RTCP首部。RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。RTCP实时服务线程3：计算延时，重复第二步。RTP文件服务线程1：初始化RTP首部。RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。

RTPRTCP的2工作流程

3，摄像头视频采集压缩及传输基本原理

摄像头视频采集压缩及传输引言：摄像头基本的功能还是视频传输，那么它是依靠怎样的原理来实现的呢？所谓视频传输: 就是将图片一张张传到屏幕，由于传输速度很快，所以可以让大家看到连续动态的画面，就像放电影一样。一般当画面的传输数量达到每秒24帧时，画面就有了连续性。下边我们将介绍摄像头视频采集压缩及传输的整个过程。一．摄像头的工作原理（获取视频数据）摄像头的工作原理大致为：景物通过镜头（LENS）生成的光学图像投射到图像传感器表面上，然后转为电信号，经过 A/D （模数转换）转换后变为数字图像信号，再送到数字信号处理芯片（DSP）中加工处理，再通过 USB接口传输到电脑中处理，通过显示器就可以看到图像了。下图是摄像头工作的流程图：注1：图像传感器（SENSOR）是一种半导体芯片，其表面包含有几十万到几百万的光电二极管。光电二极管受到光照射时，就会产生电荷。注2：数字信号处理芯片DSP（DIGITAL SIGNAL PROCESSING）功能：主要是通过一系列复杂的数学算法运算，对数字图像信号参数进行优化处理，并把处理后的信号通过USB等接口传到PC等设备。 1. ISP（image signal processor）（镜像信号处理器） 2. JPEG encoder（JPEG图像解码器） 3. USB device controller（USB设备控制器）而视频要求将获取的视频图像通过互联网传送到异地的电脑上显示出来这其中就涉及到对于获得的视频图像的传输。在进行这种图片的传输时，必须将图片进行压缩，一般压缩方式有如H.261、JPEG、MPEG等，否则传输所需的带宽会变得很大。大家用RealPlayer不知是否留意，当播放电影的时候，在播放器的下方会有一个传输速度250kbps、400kbps、1000kbps…画面的质量越高，这个速度也就越大。而摄像头进行视频传输也是这个原理，如果将摄像头的分辨率调到640×480，捕捉到的图片每张大小约为50kb左右，每秒30帧，那么摄像头传输视频所需的速度为50×30/s＝1500kbps＝1.5Mbps。而在实际生活中，人们一般用于网络视频聊天时的分辨率为320×240甚至更低，传输的帧数为每秒24帧。换言之，此时视频传输速率将不到300kbps，人们就可以进行较为流畅的视频传输聊天。如果采用更高的压缩视频方式，如MPEG-1等等，可以将传输速率降低到200kbps不到。这个就是一般视频聊天时，摄像头所需的网络传输速度。二．视频压缩部分视频的压缩是视频处理的核心，按照是否实时性可以分为非实时压缩和实时压缩。而视频传输（如QQ视频即时聊天）属于要求视频压缩为实时压缩。下面对于视频为什么能压缩进行说明。视频压缩是有损压缩，一般说来，视频压缩的压缩率都很高，能够做到这么高的压缩率是因为视频图像有着非常大的时间和空间的冗余度。所谓的时间冗余度指的是两帧相邻的图像他们相同位置的像素值比较类似，具有很大的相关性，尤其是静止图像，甚至两帧图像完全相同，对运动图像，通过某种运算（运动估计），应该说他们也具有很高的相关性；而空间相关性指的是同一帧图像，相邻的两个像素也具备一定的相关性。这些相关性是视频压缩算法的初始假设，换句话说，如果不满足这两个条件（全白噪声图像，场景频繁切换图像等），视频压缩的效果是会很差的。去除时间相关性的关键算法是运动估计，它找出当前图像宏块在上一帧图像中最匹配的位置，很多时候，我们只需要把这个相对坐标记录下来，就够了，这样就节省了大量码字，提高了压缩率。视频压缩算法中，运动估计永远是最关键最核心的部分。去除空间相关性是通过DCT变换来实现的，把时域上的数据映射到频域上，然后对DCT系数进行量化处理，基本上，所有的有损压缩，都会有量化，它提高压缩率最明显。图像的原始文件是比较大的，必须经过图像压缩才能够进行快速的传输以及顺畅的播放。而压缩比正是来衡量影像压缩大小的参数。一般来说，摄像头的压缩比率大都是5:1。也就是说，如果在未压缩之前30秒的图像的容量是30MB，那么按照摄像头5:1的压缩比率来对图像进行压缩以后，它的大小就变成了6MB了。主要的视频压缩算法包括：M-JPEG、Mpeg、H.264、Wavelet（小波压缩）、JPEG 2000、AVS。基本上视频压缩的核心就这些。三．视频传输部分为了保证数字视频网络传输的实时性和图像的质量，传输层协议的选择是整个设计和实现的关键。Internet在IP层上使用两种传输协议：一种是TCP(传输控制协议)，它是面向连接的网络协议；另一种是UDP(用户数据报协议)，它是无连接的网络协议。 TCP 传输：TCP（传输控制协议）是一种面向连接的网络传输协议。支持多数据流操作，提供流控和错误控制，乃至对乱序到达报文的重新排序，因此，TCP传输提供了可靠的数据传输服务。使用TCP传输的一般的过程：客户机向服务器发出连接的请求后，服务器接收到后，向客户机发出连接确认，实现连接后，双方进行数据传输。 UDP 传输： UDP（用户数据报协议）是一种无连接的网络传输协议。提供一种基本的低延时的称谓数据报的传输服务。不需要像TCP传输一样需预先建立一条连接。UDP无计时机制、流控或拥塞管理机制。丢失的数据不会重传。因此提供一种不可靠的的应用数据传输服务。但在一个良好的网络环境下如局域网内，使用UDP传输数据还是比较可靠，且效率很高。 IP 组播技术：组播技术是一种允许一个或多个发送者发送单一或多个发送者的数据包到多个接收者的网络技术。组播源把数据报发送到特定的组播组，而只有加入到该组播组的主机才能接收到这些数据包。组播可大大节省网络宽带，因为无论有多少个目标地址，在整个网络的任何一条链路上只船送单一的数据包。 1.TCP/IP 协议和实时传输 TCP/IP协议最初是为提供非实时数据业务而设计的。IP协议负责主机之间的数据传输，不进行检错和纠错。因此，经常发生数据丢失或失序现象。为保证数据的可靠传输，人们将TCP协议用于IP数据的传输，以提高接收端的检错和纠错能力。当检测到数据包丢失或错误时，就会要求发送端重新发送，这样一来就不可避免地引起了传输延时和耗用网络的带宽。因此传统的TCP/IP协议传输实时音频、视频数据的能力较差。当然在传输用于回放的视频和音频数据时，TCP协议也是一种选择。如果有足够大的缓冲区、充足的网络带宽，在TCP协议上，接近实时的视音频传输也是可能的。然而，如果在丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信几乎是不可能的。 TCP和其它可靠的传输层协议如XTP不适合实时视音频传输的原因主要有以下几个方面： 1 .TCP的重传机制我们知道，在TCP/IP协议中，当发送方发现数据丢失时，它将要求重传丢失的数据包。然而这将需要一个甚至更多的周期（根据TCP/IP的快速重传机制，这将需要三个额外的帧延迟），这种重传对于实时性要求较高的视音频数据通信来说几乎是灾难性的，因为接收方不得不等待重传数据的到来，从而造成了延迟和断点（音频的不连续或视频的凝固等等）。 2 . TCP的拥塞控制机制 TCP的拥塞控制机制在探测到有数据包丢失时，它就会减小它的拥塞窗口。而另一方面，音频、视频在特定的编码方式下，产生的编码数量（即码率）是不可能突然改变的。正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或图像幅面的大小等等。 3 . TCP报文头的大小 TCP不适合于实时视音频传输的另一个缺陷是，它的报文头比UDP的报文头大。TCP的报文头为40个字节，而UDP的报文头仅为12个字节。并且，这些可靠的传输层协议不能提供时间戳（Time Stamp）和编解码信息（Encoding Information），而这些信息恰恰是接收方（即客户端）的应用程序所需要的。因此TCP是不适合于视音频信息的实时传输的。 4 . 启动速度慢即便是在网络运行状态良好、没有丢包的情况下，由于TCP的启动需要建立连接，因而在初始化的过程中，需要较长的时间，而在一个实时视音频传输应用中，尽量少的延迟正是我们所期望的。由此可见，TCP协议是不适合用来传输实时视音频数据的，为了实现视音频数据的实时传输，我们需要寻求其它的途径。 2.RTP 协议适合实时视音频传输 RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一种应用型的传输层协议，它并不提供任何传输可靠性的保证和流量的拥塞控制机制。它是由IETF（Internet Engineering Task Force）为视音频的实时传输而设计的传输协议。RTP协议位于UDP协议之上，在功能上独立于下面的传输层（UDP）和网络层，但不能单独作为一个层次存在，通常是利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输。 UDP是一种无连接的数据报投递服务，虽然没有TCP那么可靠，并且无法保证实时视音频传输业务的服务质量（QoS）,需要RTCP实时监控数据传输和服务质量，但是，由于UDP的传输延时低于TCP，能与音频和视频流很好地匹配。因此，在实际应用中，RTP/RTCP/UDP用于音视频媒体，而TCP用于数据和控制信令的传输。总结：如果接收端和发送端处于同一个局域网内，由于有充分的带宽保证，在满足视频传输的实时性方面，TCP也可以有比较好的表现，TCP和基于UDP的RTP的视频传输性能相差不大。由于在局域网内带宽不是主要矛盾，此时视频数据传输所表现出来的延时主要体现为处理延时，它是由处理机的处理能力以及采用的处理机制所决定的。但是当在广域网中进行视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TCP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TCP传输的视频数据，在接收端重建、回放时，断点非常明显，体现为明显的断断续续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。四．视频图像的异地显示当压缩过的视频通过互联网传输到异地的时候，对于互联网传输过来的视频信息，首先是要进行解码，然后才是显示。解码的芯片有一定的性能要求，比编码器低些，但是毕竟是视频数据处理，通用的芯片（不支持MMX等多媒体指令）可能会比较吃力。显示设备主要有电视、监视器和显示器，他们的信号接口是不一样的，电视监视器是模拟的电信号，显示器的输入应该是数字信号。以上是摄像头如何获取图像数据及获取的数据存放在什么地方，如何压缩和传输及如何在异地释放和播放出来的整个过程

摄像头视频采集压缩及传输基本原理