摄像头获取视频后如何将实时画面通过网线传输给局域网内的另外一台电脑。

Posted 2023-04-26

场景是这样的：和无线视频玩具小车一样，遥控器可以看到小车上摄像头所拍摄到的视频画面。这个过程怎么实现？
我现在在弄一个课程设计。USB摄像头连接到Arm开发板上，在所连接的板子上已经可以显示视频画面。我想将此视频画面传输到另外一个Arm开发板上，并且进行显示。打算使用Wifi进行传输。传输和接收的具体细节我现在没有一点儿头绪。望指点迷津。
如果是使用Mjpeg-streamer这个软件，很容易就实现了我要的功能。但是视频传输的实时性不好，延迟比较严重。我就打算使用TCP或者UDP进行传输，如果可以，对视频进行压缩之后再传输也可以。总之，接收端只要卡顿的不严重就行了

问题已经解决。（2014年3月2日 09:54:58）

源代码可在 百问网论坛 的 100ask.org/bbs/forum.php?mod=viewthread&tid=11371 获取

现在有倒车后视技术在用这种类似的方案，不过没研究过他们是用的WAFI还是蓝牙在进行传输，这都不是大问题，现在最主要的是你得有一套传输和接收协议，这个我不会。 参考技术A 给你一个思路：推送，从此端推送到彼端，有大量app可供参考，反编译修改下就可用。 参考技术B 同问，求楼主怎么解决的，邮箱:[e-mail] 参考技术C 使用实时传输协议 rtmp、rtsp或者其他的直播协议，技术细节需要自行搜索了。 参考技术D 同样有这个问题，请问楼主最后怎么实现解决的呢？

摄像头视频采集压缩及传输

摄像头视频采集压缩及传输
引言：
摄像头基本的功能还是视频传输，那么它是依靠怎样的原理来实现的呢？所谓视频传输:

就是将图片一张张传到屏幕，由于传输速度很快，所以可以让大家看到连续动态的画面，就像放电影一样。一般当画面的传输数量达到每秒24帧时，画面就有了连续性。

下边我们将介绍摄像头视频采集压缩及传输的整个过程。

一．摄像头的工作原理（获取视频数据）

摄像头的工作原理大致为：景物通过镜头（LENS）生成的光学图像投射到图像传感器表面上，然后转为电信号，经过A/D（模数转换）转换后变为数字图像信号，再送到数字信号处理芯片（DSP）中加工处理，再通过USB接口传输到电脑中处理，通过显示器就可以看到图像了。下图是摄像头工作的流程图：

注1：图像传感器（SENSOR）是一种半导体芯片，其表面包含有几十万到几百万的光电二极管。光电二极管受到光照射时，就会产生电荷。

注2：数字信号处理芯片DSP（DIGITAL SIGNAL PROCESSING）功能：主要是通过一系列复杂的数学算法运算，对数字图像信号参数进行优化处理，并把处理后的信号通过USB等接口传到PC等设备。

DSP结构框架:

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等多媒体指令）可能会比较吃力。显示设备主要有电视、监视器和显示器，他们的信号接口是不一样的，电视监视器是模拟的电信号，显示器的输入应该是数字信号。

以上是摄像头如何获取图像数据及获取的数据存放在什么地方，如何压缩和传输及如何在异地释放和播放出来的整个过程