引言 通过此文更加深入的总结NAT穿透技术，其中涉及到NAT，STUN协议，TURN协议，ICE协议。 NAT NAT概念 在计算机网络中，网络地址转换(Network Address Translation，缩写为NAT)，也叫做网络掩蔽或者IP掩蔽(IP masquerading)，是一种在IP数据包通过路由器或防火墙时重写来源IP地址或目的IP地址的技术。这种技术被普遍使用在有多台主机但只通过一个公有IP地址访问因特网的私有网络中。1990年代中期，NAT是作为一种解决IPv4地址短缺以避免保留IP地址困难的方案而流行起来的。 NAPT概念 NAT虽然名为网络地址转换，但是常见的工作模式实际上是NAPT(网络地址端口转换)。这种方式支持端口的映射，并允许多台主机共享一个公网IP地址。 支持端口转换的NAT又可以分为两类：源地址转换和目的地址转换。前一种情形下发起连接的计算机的IP地址将会被重写，使得内网主机发出的数据包能够到达外网主机。后一种情况下被连接计算机的IP地址将被重写，使得外网主机发出的数据包能够到达内网主机。实际上，以上两种方式通常会一起被使用以支持双向通信。NAPT维护一个带有IP以及端口号的NAT表，结构如下： | 内网IP&Port | 外网IP&Port | |-------------------|----------------------| | 192.168.1.55:5566 | 219.152.168.222:9200 | | 192.168.1.59:80 | 219.152.168.222:9201 | | 192.168.1.59:4465 | 219.152.168.222:9202 | 不同类型的NAT 完全圆锥形NAT Full cone NAT(即一对一NAT): 一旦一个内部地址(iAddr:iPort)映射到外部地址(eAddr:ePort)，所有发自(iAddr:iPort)的包都经由(eAddr:ePort)向外发送。任意外部主机都能通过给(eAddr:ePort)发包到达(iAddr:iPort)。 ![32f061712c34487698c4b07343bf892c](https://qiniu.qjos.cn/32f061712c34487698c4b07343bf892c.jpe...

一、什么是ONVIF？ 1.1形成 2008年5月，由安讯士（AXIS）联合博世（BOSCH）及索尼（SONY）公司三方宣布携手共同成立一个国际开放型网络视频产品标准网络接口开发论坛，取名为ONVIF（OpenNetwork Video Interface Forum，开放型网络视频接口论坛），并以公开、开放的原则共同制定开放性行业标准。ONVIF标准将为网络视频设备之间的信息交换定义通用协议，包括装置搜寻、实时视频、音频、元数据和控制信息等。截止到2011年3月，已有279个公司加入ONVIF成为会员。 2008年11月，论坛正式发布了ONVIF第一版规范。 2010年11月，论坛发布了ONVIF第二版规范。规范涉及设备发现、实时音视频、摄像头PTZ控制、录像控制、视频分析等方面。 1.2规范作用 ONVIF规范描述了网络视频的模型、接口、数据类型以及数据交互的模式。并复用了一些现有的标准，如WS系列标准等。ONVIF规范的目标是实现一个网络视频框架协议，使不同厂商所生产的网络视频产品（包括摄录前端、录像设备等）完全互通。 ONVIF规范中设备管理和控制部分所定义的接口均以WebServices的形式提供，设备作为服务提供者为服务端。ONVIF规范涵盖了完全的XML及WSDL的定义。每一个支持ONVIF规范的终端设备均须提供与功能相应的WebService。服务端与客户端的数据交互采用SOAP协议。ONVIF中的其他部分比如音视频流则通过RTP/RTSP进行。 1.3规范优势 协同性：不同厂商所提供的产品，均可以通过一个统一的“语言”来进行交流。方便了系统的集成。 灵活性：终端用户和集成用户不需要被某些设备的固有解决方案所束缚。大大降低了开发成本。 质量保证：不断扩展的规范将由市场来导向，遵循规范的同时也满足主流的用户需求。 由于采用WSDL+XML模式，使ONVIF规范的后续扩展不会遇到太多的麻烦。XML极强的扩展性与SOAP协议开发的便捷性将吸引更多的人来关注和使用ONVIF规范。 ONVIF组织日益扩大，与同领域的PSIA，HDCCTV相比，占据了绝对的人员优势。会员企业不乏国内外著名的设备制造商与集成商。一套规范、协议的生命周期，与市场占有率是息息相关的。而ONVIF规范的发展则正是由市场来导向，由用户来充...

一、现象 通话中语音断断续续，视频卡顿或丢失画面，造成这些现象的一个重要原因是数据包在传输过程中出现丢失，在后端处理中，可以通过一些算法对缺失的数据进行预估，减轻一些影响，例如视频可以用I帧、P帧预估一些丢失的P帧，语音可以添加舒适噪音数据，但效果较好的办法还是降低丢包率。 二、原因 丢包的原因是媒体数据传输为了保证实时性，使用了UDP作为传输层的RTP协议，UDP只提供尽量送达的服务，数据传输过程经过网络中众多的交换机、路由器等设备有很多情况会导致数据包丢失。 三、处理办法 1、NACK 丢包首选想到的解决办法就是让发送端重发，那就需要接收端告诉发送端丢了那些包。NACK也就是no ack，接收端发送NACK给发送端，告诉丢了那些包，发送端重发。voice使用NackTracker类存丢包的sequence_number信息，而vodie使用NackModule类。 voice的NACK算法： 当收到一个包时，与上次收到的包比较序列号IsNewerSequenceNumber，如果序列号大，那上次收到包到本次收到的包之间缺失的包，可以看做包延时或丢失，定义一个常量nack_threshold_packets_，规定本次收到包之前的临近的nack_threshold_packets_个包是延时，其余的包认为丢失，并更新NackList，对丢失的包SendNACK给发送端。 vodie的NACK算法： 与voice的原理差不多，视频的数据量大，I帧最重要的特点，算法需要尽量重传关键数据，定义常量kMaxPacketAge，规定本次收到包的临近的kMaxPacketAge个包有机会重传，定义kMaxNackPackets，规定当nack_list_超过kMaxNackPackets时，清楚nack_list_中的某些非关键帧，再将恢复帧也去除，在GetNackBatch函数内根据规定判断是包丢失还是包延时。 缺点及改进： 当网络拥塞严重时，延时包会增多，延时时长也会增加，算法可能会将很多延时包当做丢包，进而发NACK，这样会进一步增加网络拥塞，可以根据网络延时情况、网络丢包情况控制发NACK包的量（做个分段函数之类的），网络情况在计算jitterbuffer大小时有相关计算，可以引用。 2、FEC 丢包另一个解决办法是增加冗余，...

一、数字化音频原理 声音其实是一种能量波，因此也有频率和振幅的特征，频率对应于时间轴线，振幅对应于电平轴线。通常人耳可以听到的频率在20Hz到20KHz的声波称为为可听声，低于20Hz的成为次声，高于20KHz的为超声，多媒体技术中只研究可听声部分。 可听声中，话音信号的频段在80Hz到3400Hz之间，音乐信号的频段在20Hz-20kHz之间，语音（话音）和音乐是多媒体技术重点处理的对象。 由于模拟声音在时间上是连续的，麦克风采集的声音信号还需要经过数字化处理后才能由计算机处理。通常我们采用PCM编码（脉冲代码调制编码），即通过采样、量化、编码三个步骤将连续变化的模拟信号转换为数字编码。 1、采样 采样，就是每隔一段时间间隔读一次声音的幅度。单位时间内采样的次数称为采样频率。显然采样频率越高，所得到的离散幅值的数据点就越逼近于连续的模拟音频信号曲线，同时采样的数据量也越大。 为了保证数字化的音频能够准确(可逆)地还原成模拟音频进行输出，采样定理要求：采样频率必须大于等于模拟信号频谱中的最高频率的2倍。 常用的音频采样率有：8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz。 例如:话音信号频率在0.3～3.4kHz范围内，用8kHz的抽样频率（fs），就可获得能取代原来连续话音信号的抽样信号，而一般CD采集采样频率为44.1kHz。 2、量化 量化，就是把采样得到的声音信号幅度转换成数字值，用于表示信号强度。 量化精度：用多少个二进位来表示每一个采样值，也称为量化位数。声音信号的量化位数一般是 4,6,8,12或16 bits 。 由采样频率和量化精度可以知道，相对自然界的信号，音频编码最多只能做到无限接近，在计算机应用中，能够达到最高保真水平的就是PCM编码，通常PCM约定俗成了无损编码。 3、编码 一个采样率为44.1kHz，量化精度为16bit，双声道的PCM编码输出，它的数据速率则为 44.1K×16×2 =1411.2 Kbps，存储一秒钟需要176.4KB的空间，1分钟则约为10.34M，因此，为了降低传输或存储的费用，就必须对数字音频信号进行编码压缩。 到目前为止，音频信号经压缩后的数码率降低到32至256kbit/s，语音可以低至8kbit/s以下。 对数字音频信息的...

方案一: H5 + websocket_rtsp_proxy 实现视频流直播 Streamedian 提供了一种“html5_rtsp_player + websock_rtsp_proxy”的技术方案，可以通过html5的video标签直接播放RTSP的视频流。 整个架构如下图所示，分为服务器端和浏览器端两部分：  方案二：RTSP转RTMP到RTMP服务器，转http-flv，播放端用flv.js播放 flv.js在获取到FLV格式的音视频数据后将 FLV 文件流转码复用成 ISO BMFF（MP4 碎片）片段，再通过Media Source Extensions API 传递给原生HTML5 Video标签进行播放。 flv.js 是使用 ECMAScript 6 编写的，然后通过 Babel Compiler 编译成 ECMAScript 5，使用 Browserify 打包。 flv.js 从服务器获取FLV再解封装后转给Video标签的原因如下： 兼容目前的直播方案：目前大多数直播方案的音视频服务都是采用FLV容器格式传输音视频数据。 flv格式简单，相比于MP4格式转封装简单、性能上也占优势，解析起来更快更方便。 方案三：RTSP转RTMP到RTMP服务器，转hls，播放端用video.js播放 Video.js是一款web视频播放器，支持html5和flash两种播放方式。更有自定义皮肤，插件，组件，语言还有丰富的选项配置。 方案四：VLC或者SmartPlayer第三方插件播放 VLC不再多说，几乎做流媒体的开发者都知道，SmartPlayer是大牛直播SDK (Github) 的播放插件，延迟和功能体验更好。 插件形式的优点是无需二次转换，直接通过ActiveX控件的形式播放，延迟非常低，缺点是只支持IE浏览器。  方案五：RTSP转WebRTC...

RTMP是Real Time Messaging Protocl（实时传输消息协议）的缩写，它是有Adobe 公司为了Flash播放器和服务器之间进行音频、视频等实时传输而开发的协议；作为一套标准的未加密的实时传输协议，RTMP的默认的传输端口是1935，如果在连接中，未指定传输端口，flash客户端会自动尝试连接其他端口，按照顺序，一次连接1935、443、80等，该协议是建立在TCP或者轮询HTTP协议的基础上的。 RTMPT协议是RTMP协议的变种，此协议的传输是建立在HTTP协议的基础上的，默认端口是80. RTMPS协议是经过SSL加密的RMTP协议，增强了数据通信的安全性。 RTMPE 协议也是一个加密版的RTMP协议，不过与RTMPS不同，它采用的不是SSL加密方式，其加密速度快于SSL，且不需要进行认证管理。 RTMPTE协议是一个经过加密通道连接的RTMPE协议，默认端口号是80.

方案一: H5 + websocket_rtsp_proxy 实现视频流直播 Streamedian 提供了一种“html5_rtsp_player + websock_rtsp_proxy”的技术方案，可以通过html5的video标签直接播放RTSP的视频流。 方案二：RTSP转RTMP到RTMP服务器，转http-flv，播放端用flv.js播放 flv.js在获取到FLV格式的音视频数据后将 FLV 文件流转码复用成 ISO BMFF（MP4 碎片）片段，再通过Media Source Extensions API 传递给原生HTML5 Video标签进行播放。 flv.js 是使用 ECMAScript 6 编写的，然后通过 Babel Compiler 编译成 ECMAScript 5，使用 Browserify 打包。 flv.js 从服务器获取FLV再解封装后转给Video标签的原因如下： 兼容目前的直播方案：目前大多数直播方案的音视频服务都是采用FLV容器格式传输音视频数据。 flv格式简单，相比于MP4格式转封装简单、性能上也占优势，解析起来更快更方便。 方案三：RTSP转RTMP到RTMP服务器，转hls，播放端用video.js播放 Video.js是一款web视频播放器，支持html5和flash两种播放方式。更有自定义皮肤，插件，组件，语言还有丰富的选项配置。 方案四：VLC或者SmartPlayer第三方插件播放 VLC不再多说，几乎做流媒体的开发者都知道，SmartPlayer是大牛直播SDK (Github) 的播放插件，延迟和功能体验更好。 插件形式的优点是无需二次转换，直接通过ActiveX控件的形式播放，延迟非常低，缺点是只支持IE浏览器。 方案五：RTSP转WebRTC播放 浏览器对webrtc的支持良好，特别是在H264编码方面几个主流的浏览器都已经支持了。webrtc使用srtp进行媒体数据的传输，那么我们只需要将rtp中的负载数据通过webrtc通道发送给浏览器，而浏览器端只需要通过video标签播放即可，目前RTSP转WebRTC对浏览器的适配比较好，延迟也比较低。

下面简单说一下这几种协议的优劣： 协议名称 优势 劣势 rtmp ● 实时性高：一般能做到3秒内。 ● 支持加密：rtmpe和rtmps为加密协议。 ● 稳定性高：在PC平台上flash播放的最稳定方式是rtmp，如果做CDN或者大中型集群分发，选择稳定性高的协议一定是必要的。 ● 一般主流编码器都支持该协议。 ● 协议复杂：开发者写起来累，效率也不行。 ● Cache麻烦：流协议做缓存不方便。 http ● 性能很高：http的性能好，协议简单，高性能服务器也完善。如果分发的量特别大，譬如点播视频网站，没有直播的实时性要求，http协议是最好选择。 ● 没有碎片：http相比hls没有碎片。 ● 穿墙：http协议是互联网唯一肯定会开放的协议，所以不存在封端问题。 ● 实时性差：延迟10s起步。 ● 原生支持不好：PC上flash对于http流支持还可以，但是移动端对于http的支持不是很完善 hls ● 性能好：和http一样。 ● 穿墙：和http一样。 ● 原生支持很好：iOS上支持完美，Android上支持差些。PC/flash上现在也有各种as插件支持HLS。 ● 实时性差：与ts切片长度有关，大约3个切片长度时间的延迟，基本上HLS的延迟在10秒以上。 ● 文件碎片：若分发HLS，码流低，切片较小时，会导致太多的文件碎片 rtsp ● 延迟低，一般都能够做到500ms。 ● 带宽好，时效率高。 ● 倍速播放，主要是回放的时候提供的功能。 ● 控制精准，任意选择播放点。 ● 服务端实现复杂。 ● 代理服务器弱：数量少，优化少。 ● 无路由器防火墙穿透 ● 管流分离：需要1-3个通道。 看了以上这些协议，想必各位都注意到了一个问题，那就是“延迟”。所有的协议里都有延迟，延迟最低的也有500ms。 webRTC 然而基于WebRTC的标准或自有协议，在含有“互动”的直播场景已经突破到了400毫秒以内的延迟边界，对于常规的社交感，这已经非常低了。越低延时当然观看体验就越好，但是不是所有的直播都要选WebRTC这种技术来达到最小的延时效果呢，这就不一定了。 在说这个问题之前，我们先了解一下为什么会有延时这个问题。 信息的传递需要介质，而介质其实就是一个载体，打个比方，你要从深圳到北京，需要选择飞机、高铁等交通工具，而这...

前言 目前市面上有很多开源的流媒体服务器解决方案，常见的有 SRS、EasyDarwin、ZLMediaKit 和 Monibuca 等，我们应该怎么选择呢？ 正文 今天这篇文章主要介绍 SRS、EasyDarwin、ZLMediaKit 和 Monibuca 的一些对比情况，可以作为日后调研选型的参考文档。 SRS SRS 目前已经更新到 3.0，功能和稳定性较之前的版本都有非常大的提升，新入门的同学可以考虑直接从 3.0 上手。接下来，我们从使用、配置、功能几个方面介绍 SRS。 使用步骤 我们自己可以非常方便的搭建一套 SRS 服务器，具体的配置步骤如下： 1. 获取源码 srs 地址：https://github.com/ossrs/srs 具体命令如下： git clone https://gitee.com/winlinvip/srs.oschina.git srs &&cd srs/trunk && git remote set-url origin https://github.com/ossrs/srs.git && git pull 2. 编译 srs ./configure && make 其中，configure 文件是支持可配置的。 3. 运行 srs ./objs/srs -c conf/srs.conf 其中，srs.conf 文件是支持可配置的，针对不同功能模块，还有单独对应的配置文件。比如，rtmp 模块对应的配置文件是 rtmp.conf。 另外，我们还可以直接运行现有的 docker 镜像，命令： srs docker run -p 1935:1935 -p 1985:1985 -p 8080:8080 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:3 主要功能 SRS 作为当前非常普遍的运营级解决方案，具备非常全面的功能，包括集群、协议网关、CDN 功能等，主要功能如下： 1. SRS 定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。 2. SRS 提供了丰富的接入方案将 RTMP 流接入 SRS， 包括推送 RTMP 到 SRS

一场疫情将直播推上了风口，直播平台抓住机遇，让直播行业扶摇直上，尤其是直播带货更是走进了千家万户。直播最重要的功能就是直播带货功能，要想让视频可以在不同的用户端流畅播放，就要选择合适的音视频编码。那么在自己搭建直播平台时，可以使用哪些音视频编码呢。 一、视频编码 1、H.264 H.264是由两个组织联合制定的视频编码格式，H.264的视频压缩比可以比MPEG-2和MPEG-4高2倍左右，同时还能保持图像的高画质，拥有更高的编码效率和更低的码率，传输时可以节省直播平台的带宽和时间，缩短直播平台用户的下载时间。 2、H.265 H.265是在H.264的基础上推出的视频编码格式，可以说是H.264的升级版，支持超高清的视频。H.265拥有比H.264更高的画质，传输时占用的带宽更小、传输时间更短，而且可以降低延迟，对于自己搭建直播平台来说是很好的选择。 二、音频编码 1、AAC AAC又称高级音频编码，在1997年是想被用于替代MP3格式，在MPEG-2基础上的进行制定的，在当时又被称为MPEG－2 AAC，2000年的MPEG-4格式的出现让AAC又采用了其他编码技术，出现了MPEG-4 AAC。AAC是一种音频有损压缩技术，压缩的文件更小，解码效率更高，支持多声道，可以保持更高的音质，多用于直播平台的搭建。 2、MP3 MP3也是采用了有损压缩方式的音频编码格式，同时MP3使用了感官编码技术，可以有效的保留声音真实度。MP3拥有较好的压缩比率，可以在保留音质的同时将文件压缩成一个较小的文件，但是在一定的比特率下，会明显的出现高频丢失，不适合直播平台的搭建，一般用于音乐编码。 说到MP3，那接着说一下MP4吧。MP4属于MPEG-4的一部分。是一种多媒体容器格式，MP4可以容纳的编码格式比较多，普遍认为它可以嵌入各种格式的音视频编码，所以在直播平台搭建时，通常会将H.265封装成MP4格式。 3、WMA格式 WMA格式是由微软推出的一种音频格式，压缩率比较高，比MP3编码生成的文件小了几乎一半，可以有效的防止盗版，但是渲染能力比较差，对于直播平台的搭建来说不是一个好的选择。 音视频编码技术不仅有文中所说的几种，并且随着技术的发展，音视频编码技术肯定还有会有新的突破，就现...

基本概念 编解码 　　编解码器（codec）指的是一个能够对一个信号或者一个数据流进行变换的设备或者程序。这里指的变换既包括将 信号或者数据流进行编码（通常是为了传输、存储或者加密）或者提取得到一个编码流的操作，也包括为了观察或者处理从这个编码流中恢复适合观察或操作的形式的操作。编解码器经常用在视频会议和流媒体等应用中。 容器 　　很多多媒体数据流需要同时包含音频数据和视频数据，这时通常会加入一些用于音频和视频数据同步的元数据，例如字幕。这三种数据流可能会被不同的程序，进程或者硬件处理，但是当它们传输或者存储的时候，这三种数据通常是被封装在一起的。通常这种封装是通过视频文件格 式来实现的，例如常见的 .mpg, .avi, .mov, .mp4, .rm, .ogg or .tta. 这些格式中有些只能使用某些编解码器，而更多可以以容器的方式使用各种编解码器。 　　FourCC全称Four-Character Codes，是由4个字符（4 bytes）组成，是一种独立标示视频数据流格式的四字节，在wav、avi档案之中会有一段FourCC来描述这个AVI档案，是利用何种codec来 编码的。因此wav、avi大量存在等于“IDP3”的FourCC。 　　视频是现在电脑中多媒体系统中的重要一环。为了适应储存视频的需要，人们设定了不同的视频文件格式来把视频和音频放在一个文件中，以方便同时回放。视频档实际上都是一个容器里面包裹着不同的轨道，使用的容器的格式关系到视频档的可扩展性。 参数介绍 采样率 　　采样率（也称为采样速度或者采样频率）定义了每秒从连续信号中提取并组成离散信号的采样个数，它用赫兹（Hz）来表示。采样频率的倒数叫作采样周期或采样时间，它是采样之间的时间间隔。注意不要将采样率与比特率（bit rate，亦称“位速率”）相混淆。 　　采样定理表明采样频率必须大于被采样信号带宽的两倍，另外一种等同的说法是奈奎斯特频率必须大于被采样信号的带宽。如果信号的带宽是 100Hz，那么为了避免混叠现象采样频率必须大于200Hz。换句话说就是采样频率必须至少是信号中最大频率分量频率的两倍，否则就不能从信号采样中恢复原始信号。 　　对于语音采样： 8,000 Hz 电话所用采样率, 对于人的说话已经足够 11,025 Hz 22,050

ehome协议介绍 ehome协议又称智能住宅，在国外常用Smart Home表示。与智能家居含义近似的有家庭自动化（Home Automation）、电子家庭（Elecctronic Home、E-home）、数字家园（Digital Family）、家庭网络（Home Net/Networks for Home）、网络家居（Network Home）、智能家庭/建筑（Intelligent Home/Building），在我国香港和台湾等地区，还有数码家庭、数码家居等称法。 智能家居是以住宅为平台，利用综合布线技术、网络通信技术、安全防范技术、自动控制技术、音视频技术将家居生活有关的设施集成，构建高效的住宅设施与家庭日程事务的管理系统，提升家居安全性、便利性、舒适性、艺术性，并实现环保节能的居住环境。 智能家居是一个居住环境，是以住宅为平台安装有智能家居系统的居住环境，实施智能家居系统的过程就称为智能家居集成。 智能家居集成是利用综合布线技术、网络通信技术、安全防范技术、自动控制技术、音视频技术将家居生活有关的设备集成。由于智能家居采用的技术标准与协议的不同，大多数智能家居系统都采用综合布线方式，但少数系统可能并不采用综合布线技术，如电力载波，不论哪一种情况，都一定有对应的网络通信技术来完成所需的信号传输任务，因此网络通信技术是智能家居集成中关键的技术之一。安全防范技术是智能家居系统中必不可少的技术，在小区及户内可视对讲、家庭监控、家庭防盗报警、与家庭有关的小区一卡通等领域都有广泛应用。自动控制技术是智能家居系统中必不可少的技术，广泛应用在智能家居控制中心、家居设备自动控制模块中，对于家庭能源的科学管理、家庭设备的日程管理都有十分重要的作用。音视频技术是实现家庭环境舒适性、艺术性的重要技术，体现在音视频集中分配、背景音乐、家庭影院等方面。 1、始终在线的网络服务，与互联网随时相连，为在家办公提供了方便条件。 2、安全防范：智能安防可以实时监控非法闯入、火灾、煤气泄露、紧急呼救的发生。一旦出现警情，系统会自动向中心发出报警信息，同时启动相关电器进入应急联动状态，从而实现主动防范。 3、家电的智能控制和远程控制，如对灯光照明进行场景设置和远程控制、电器的自动控制和远程控制等。 4、交互式智能控制：可以通过语音识别技术实现智能家电的声控功能；通过...

1.图像 1.1 什么是图像 什么是图像？简单说图像就是很多带有颜色的点组成的，这些点就是像素点。而像素，也是图像显示的基本单位。 我们通常提到的一张图片是1920 1080，意思是说长度为1920个像素点，宽度为1080个像素点，1920 1080 = 2073600，也就是说这张图片总共有200多万个像素点，也就是我们通常说的200万像素。 1.2 图像有多大 想要搞清楚图像有多大，就得先搞清楚一个像素点是多少个比特（bit），而想搞清楚一个像素点是多少个bit，就要从颜色开始说起。 我们知道任何颜色都可以用红色、绿色、蓝色按照一定的比例调配出来，而这三种颜色也被称为三原色。 而在计算机里，颜色是用数字来表示的，R、G、B被称为“基色分量”，他们的值分别是从0到255，一种256个等级。因此，任何颜色都可以用R、G、B的三个值的组合来表示。通过RGB的方式，我们可以表达256 256 256 = 16777216种颜色，这种表示方式，也称为1600万色。 刚才提到，RGB三原色中每一个颜色有256个数值，正好是2的8次方，我们知道在计算机里一个数字是1bit，那么用8位的二进制数来表达，刚好能表达256个数值，那么刚好就是8bit可以表达一个原色，也就是说RGB三原色每个颜色占用8bit，三个颜色就是24bit，这种方式表达的颜色也被称为24位色。 以1080p的图片为例，像素点是2073600个，用24位色表示，每张图片就是 2073600 24 bit = 49766400 bit。 结合上一节课的知识，我们得到49766400 / 8 / 1024 / 1024 = 5.9MB，就是说这张图片的大小是5.9MB。 2.视频 2.1 什么是视频 我们提到的视频，其实就是若干张图片连续播放的结果，通常的视频有如下的几张格式： 视频格式 长宽比 分辨率 像素 720p 16:9 1280 720 921600 1080p 16:9 1920 1080 2073600 2K 16:9 1920 1080 82073600 4K 16:9 3840 2160 8294400 8K 16:9 7680 4320 33177600 好的，我们继续回到视频，那么多张图片通常要怎么样去连续的播放呢，这就涉及...

码流 码流（Data Rate）是指视频文件在单位时间内使用的数据流量，也叫码率、取样率、码流率，是视频编码中画面质量控制中最重要的部分，一般我们用的单位是Kb/s或者Mb/s。一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内取样率越大，数据流精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。 VBR（可变码流） VBR编码指的是编码器的输出码率（或者解码器的输入码率）可以根据编码器的输入源信号的复杂度自适应的调整，目的是达到保持输出质量保持不变而不是保持输出码率保持不变。VBR适用于存储（不太适用于流式传输），可以更有效地利用有限的存储空间：用比较多的码字对复杂度高的段进行编码，用比较少的码字对复杂度低的段进行编码。 帧率 一帧就是一副静止的画面，连续的帧就形成动画，如电视图象等。我们通常说帧数，简单地说，就是在1秒钟时间里传输的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次，通常用fps（Frames Per Second）表示。每一帧都是静止的图象，快速连续地显示帧便形成了运动的假象。高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数 (fps) 愈多，所显示的动作就会愈流畅。 分辨率 视频分辨率是指视频成像产品所成图像的大小或尺寸。常见的视像分辨率有352×288，176×144，640×480，1024×768。在成像的两组数字中，前者为图片长度，后者为图片的宽度，两者相乘得出的是图片的像素，长宽比一般为4：3. 目前监控行业中主要使用Qcif(176×144）、CIF(352×288）、HALF D1(704×288）、D1(704×576）等几种分辨率。 D1是数字电视系统显示格式的标准，共分为以下5种规格： D1：480i格式（525i）：720×480（水平480线，隔行扫描），和NTSC模拟电视清晰度相同，行频为15.25kHz，相当于我们所说的4CIF(720×576) D2：480P格式（525p）：720×480（水平480线，逐行扫描），较D1隔行扫描要清晰不少，和逐行扫描DVD规格相同，行频为31.5kHz D3：1080i格式（1125i）：1920×1080（水平1080线，隔行扫描），高清方式采用最...