音视频基础知识、YUV、H264
.html
音视频基础概念：PCM、采样率、位深和比特率
.html
音视频开发成长之路与音视频知识总结
.html
视频封装格式
.html
音频封装格式
.html
ISO：国际标准化组织，官方网址：ISO - International Organization for Standardization。很多音视频协议都可以从这里找到
MPEG：ISO与IEC下属的针对运动图像与语音压缩制定国际标准的组织，全称为运动图像专家组(Moving Picture Experts Group)，官网网址：
MPEG发展历史：
IETF：互联网工程任务组(Internet Engineering Task Force)，官方网址：。常见的网络协议、多媒体通信协议的地址：/
码率，又叫比特率，单位时间内传输的数据量，单位一般为kbps(千位每秒)。需要注意的是，这里b代表bit，而不是Byte，这里乘以8是Byte转成bit。计算公式：平均码率(kbps)=文件大小(kB)*8/时间(s)。动态码率(kbps)=每秒传输数据量(kB)*8。
恒定码率：CBR，码率稳定可控，带宽要求不高，图像变化量比较大时方块效应比较明显。
动态码率：VBR，码率波动较大，带宽要求较高，图像变化量比较大时方块效应有所改善。发生网络抖动时，比较容易丢包，需要重传，或者FEC前向纠错，从而带来延时。
分辨率又称为解析度，分辨率越高，像素越多，图像越清晰
视频分辨率：又称为图像分辨率，由视频的宽高组成，表示形式宽x高，常见的视频分辨率有480P、720P、1080P、2K(2048x1080/2160x1440)、4K(4096x2160/3840x2160)，具体如下表（常见分辨率及其显示模式）所示。
屏幕分辨率：又称为显示分辨率，描述屏幕分辨率的单位是ppi(pixel per inch，每英寸的像素数)。
位分辨率：又称为位深(BitDepth)，每个像素点存储信息的位数。常见的有：8位、16位、24位、32位色彩。Android的Bitmap常见的有ALPHA_8、RGB_565、ARGB_4444、ARGB_8888。
视频帧率：测量显示帧数的量度，单位为每秒显示帧数(FPS，全称为Frame Per Second)。一般视频帧率为24fps，P制(PAL，德国提出，中国、印度、巴基斯坦等国家使用)为25fps，也就是每帧显示40ms，N制(NTSC，美国标准委员会提出，美国、日本、韩国等国家使用)为30fps。有些超高帧率的视频达到60fps。
显示帧率：以帧为单位的位图图像连续出现在显示器的频率，指屏幕每秒画面被刷新的次数也称为刷新速率。刷新率分垂直刷新率和水平刷新率，一般都指垂直刷新率。垂直刷新率表示屏幕上图像每秒重绘的次数，即每秒屏幕刷新的次数。刷新率越高，图像就越稳定，图像显示也就越自然清晰，对眼睛影响也越小。相反如果刷新率低，图像闪烁和抖动就越历害，眼睛越容易疲劳。。Android设备刷新率一般为60Hz，也就是帧率为60fps，每帧为16ms，超过16ms能给人的肉眼带来延迟卡顿的感觉。一般达到80Ｈz以上的刷新率就可以完全消除图像闪烁和抖动。Android11支持120Hz的更高帧率，一般为对帧率要求极高的应用场景，比如互动游戏。
像素格式：像素色彩分量的排列，由每个像素使用的总位数以及各分量的位数决定。图像的像素格式一般是RGBA四个分量通道各占8bits，组成一个32位的像素。其中R代表Red、G代表Green、B代表Blue、A代表Alpha。但是，视频压缩存储的像素格式不是RGBA，而是YUV，其中Y代表亮度(Luma)，U代表色度(Chroma)，V代表对比度(Contrast)。
画质：画面质量，由清晰度、锐度、解析度、色彩纯度、色彩平衡等指标构成。
清晰度：指图像细节纹理及其边界的清晰程度。
锐度：反应图像平面清晰程度，以及图像边缘的锐利程度。
解析度：指像素点的数量，与分辨率对应，分辨率越高，解析度越高。
色彩纯度：指色彩的鲜艳程度。所有色彩都是三原色组成，其他颜色都是三原色混合而成，理论上可以混合出256种颜色。原色的纯度最高。色彩纯度是指原色在色彩中的百分比。
色彩平衡：用来控制图像的色彩分布，使得图像整体达到色彩平衡。
色域：指某种表色模式所能表达的颜色构成的范围区域，色域空间越大，所能表现的颜色越多。
BT709的标准，其全称是ITU-R Recommendation BT.709（全称包括所有字母），是国际电信联盟（ITU）发布的高清晰度数字视频标准，被大多数视频设备制造商接受。
BT709是SDR色域，色域超过100%BT709即为广色域电视
BT2020的全称是ITU-R Recommendation BT.2020，也是由ITU发布的标准之一。这个标准具有更广泛的色彩空间，是HDR（高动态范围）使用的标准。
BT2020是HDR色域，目前顶级的OLED电视大概能覆盖个80%
HDR：High Danamic Range，高动态范围，比普通图像提供更多动态范围和图像细节，能够更好反应真实环境的视觉效果。颜色值经过归一化后，范围一般是[0,1]。而HDR可以表达超出1的颜色值，拥有更大的颜色范围
旋转角度：视频的YUV储存方向。一般的视频旋转角度是0°，对应的是横屏显示。后置摄像头竖屏拍的视频，旋转角度为90°，对应的是竖屏显示。
视频所有图像播放所需要的时间称为视频时长。计算公式：时长(s)=帧数x每帧时长=帧数x(1/帧率)。假设一个视频帧数为1000，帧率为25fps，那么时长为40s
视频帧I、P、B帧。
I帧：表示关键帧，包含完整的画面。
P帧：表示差别帧，即当前帧与前一个关键帧（或Ｐ帧）的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别生成最终画面。Ｐ帧没有完整的画面数据，只有与前一帧的画面差别的数据。
B帧：表示双向差别帧，记录本帧与前后帧的差别。要解码Ｂ帧，不仅要取得之前缓存画面，还要解码之后的画面，最终通过前后画面数据与本帧数据的叠加得到最终的画面。
DTS (Decoding Time Stamp):即解码时间戳，这个时间戳的意义在于告诉播放器该在什么时候解码这—帧的数据。
PTS (Presentation Time Stamp):即显示时间戳，这个时间戳用来告诉播放器该在什么时候显示这—帧的数据
视频的封装格式，由特定格式头+媒体信息+音视频轨(字幕)数据+视频轨索引组成。常见的封装格式有：mp4、mkv、webm、avi、3gp、mov、wmv、flv、mpeg、asf、rmvb等
视频经过解封装得到的视频轨数据，是经过编码的，所以显示视频帧前需要解码。不同编码算法组成不同编码协议，常见的有：H264(AVC，一般使用x264编码)、H265(HEVC，一般使用x265编码)、VP8、VP9、MPEG4、MJPEG、WMV3等
采样率：对声音信号每秒的采样次数，采样率越高，声音的还原越真实。采样率单位为Hz，常见的采样率有：8000Hz、16000Hz、44100Hz、48000Hz。人类一般能够听到的声音范围：20Hz～20000Hz。根据奈奎斯特采样定理：当采样频率大于信号中最高频率的2倍时，采样后的数字信号能够完整保留原始信号的信息
声道：指声音在录制或播放时，在不同空间位置采集或回放的相互独立音频信号。声道数指在录音时的音源数量，或者在播放时的扬声器数量
不同声道数对应不同声道布局。常见的声道布局有单声道(mono)、立体声道(stereo)、四声环绕、5.1声道。
单声道：只有一个声道，优点数据量小，amr_nb和amr_wb默认为单声道，缺点是缺乏对声音位置定位。
立体声道：一般为两个声道，由左声道、右声道组成，改善对声音位置定位的状况。
四声环绕：由前左、前右、后左、后右组成，形成立体环绕。4.1声道是在四声环绕基础上，增加一个低音。
5.1声道：来源于4.1声道，将环绕声道一分为二，分为左环绕和右环绕，中央位置增加重低音效果，杜比AC3就是采用5.1声道，也就是影院宣传的杜比音效
音质：声音的质量，经过编码压缩后的音频信号保真度，由音量、音高和音色组成。
音量：音频的强度，数值范围0-100，静音时为0，最大值为100。
音高：声音的音调，即音频频率或每秒变化次数。
音色：音频泛音，又称为音品，不同声音表现在波形方面与众不同的特性。
音频的封装格式，与视频封装格式类似，由特定格式头+媒体信息+音频轨数据组成。常见的封装格式有：mp3、m4a、ogg、amr、wma、wav、flac、aac、ape等
音频经过解封装得到的音频轨数据，也是经过编码的。常见的音频编码协议有：mp3、aac、amr_nb、amr_wb、ac3、vorbis、opus、flac、wmav2等
采样数，即每帧采样的数量。在FFmpeg的AVFrame中，定义为nb_samples
采样位数，即每个采样占用多少位。在RIFF(Resource Interchange File Format)资源交换文件格式有个字段bits_per_sample表示采样位数，在FFmpeg也是用这个字段表示采样位数
音频的每秒存储空间由：采样率、声道数、每个采样位数。假设采样率为44.1k，声道数为2，采样位数为16。那么，每秒所占存储空间字节数=44100 * 2 * 16 / 8
音频的帧时长=采样数 / 采样率。假设采样率为44.1k，采样数为1024。那么每帧时长约等于23ms
音频的采样格式分为大端存储和小端存储。按照符号划分有：有符号与无符号。按照类型划分有：整型与浮点型。按照存储位数划分有：8位、16位、32位、64位，都是8的倍数。在FFmpeg的AVSampleFormat枚举如下
mp4、mkv、webm、avi、3gp、mov、wmv、flv、mpeg、asf、rmvb
mp3、aac、amr_nb、amr_wb、ac3、vorbis、opus、flac、wmav2
所谓流媒体是指采用流式传输的方式在 Internet 播放的媒体格式。 流媒体又叫流式媒体，它是指商家用一个视频传送服务器把节目当成数据包发出，传送到网络上。用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。流媒体以流的方式在网络中传输音频、视频和多媒体文件的形式。流媒体文件格式是支持采用流式传输及播放的媒体格式。流式传输方式是将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户不必像非流式播放那样等到整个文件全部下载完毕后才能看到当中的内容，而是只需要经过几秒钟或几十秒的启动延时即可在用户计算机上利用相应的播放器对压缩的视频或音频等流式媒体文件进行播放，剩余的部分将继续进行下载，直至播放完毕。
RTP :(Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议.RTP 协议和 RTP 控制协议 RTCP 一起使用，而且它是建立在 UDP 协议上的.
RTP 不像http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。
RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或简写 RTCP)实时传输控制协议,是实时传输协议(RTP)的一个姐妹协议.
注:--:RTP 协议和 RTP控制协议(RTCP) 一起使用，而且它是建立在UDP协议上的（一般用于视频会议）
实时流媒体会话协议,SDP(会话描述协议)，RTP(实时传输协议)。是用来控制声音或影像的多媒体串流协议,RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。媒体数据使用rtp,rtcp协议。一般使用udp 作为传输层。适合IPTV场景。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，比较能容忍网络延迟.
--->:RTSP 与 RTP 最大的区别在于：RTSP 是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当
然，RTSP 可基于 RTP 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性。它时一种类似与http协议
的网络应用层协议.
web端实现流媒体的协议。google刚推出WebRTC的时候巨头们要么冷眼旁观，要么抵触情绪很大。使用RTP协议传输。
RTMP(Real Time Messaging Protocol)Macromedia 开发的一套视频直播协议，现在属于 Adobe。和 HLS 一样都可以应用于视频直播，基于TCP不会丢失。
// 区别是 RTMP 基于 flash 无法在 iOS 的浏览器里播放，但是实时性比 HLS 要好。
实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议.
// iOS 代码里面一般常用的是使用 RTMP 推流，可以使用第三方库 librtmp-iOS 进行推流，librtmp 封装了一些核心的 API 供使用者调用RTMP 协议也要客户端和服务器通过"握手"来建立 RTMP Connection，然后在Connection上传输控制信息。RTMP 协议传输时会对数据格式化，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有 Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据Chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。
HLS:HTTP Live Streaming(HLS)是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，
可实现流媒体的直播和点播 ,主要应用在iOS系统，为iOS设备(如iPhone、iPad)提供音视频直播和点播方案。HLS 点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。相对于常见的流媒体直播协议，例如RTMP协议、RTSP 协议、MMS 协议等，HLS 直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。
HLS 协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件(MPEG-TS格式)，而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。
由此可见，基本上可以认为，HLS 是以>>点播的技术方式来实现直播<<。由于数据通过 HTTP 协议传输，所以完全不用考虑防火墙或者代理的问题,而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
// iOS和 Android 都天然支持这种协议，配置简单，直接使用 video 标签即可
流媒体技术采用一系列的网络协议，包括：
实时传输协议RTP（Real-time Transport protocol）
实时传输控制协议RTCP（Real-time Transport Control protocol）
实时流协议RTSP（Real Time Streaming protocol）
资源预留协议RSVP（Resource Reserve Protocol）
RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。
RTP定义在RFC 1889中。信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准，它可以被用来传输普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。
使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号和检查和。如下图所示，RTP是传输层上的协议,RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。
从应用开发人员的角度来看，可把 RTP 执行程序看成是应用程序的一部分，因为开发人员必需把 RTP 集成到应用程序中。在发送端，开发人员必需把执行 RTP 协议的程序写入到创建 RTP 信息包的应用程序中，然后应用程序把 RTP 信息包发送到 UDP 的套接接口（socket interface），如下图所示；同样，在接收端，RTP 信息包通过 UDP 套接接口输入到应用程序，因此开发人员必需把执行 RTP 协议的程序写入到从 RTP 信息包中抽出媒体数据的应用程序。
RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确，RTP的封装只是在系统端才能看到，中间的路由器并不区分那个IP数据报是运载RTP信息包的。
RTP允许给每个媒体源分配一个单独的RTP信息包流，例如，摄像机或者麦克风。例如，有两个团体参与的电视会议，这就可能打开4个信息包流：两台摄像机传送电视流和两个麦克风传送声音流。然而，许多流行的编码技术，包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流，一个方向就生成一个RTP信息包流。
RTP信息包没有被限制只可应用于单目标广播，它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如，多对多的多目标广播，在这种应用场合下，所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。
RTP标题由4个信息包标题域和其他域组成：有效载荷类型(payload type)域，顺序号(sequence number)域，时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示：
（1）有效载荷类型
RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。
（2）顺序号
顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。（初始是随机的）
（3）时间戳
时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。（由该时间恢复出原始时钟信息，要处理分布式终端的时钟漂移）
（4）同步源标识符
同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。（用于媒体间同步）
实时传输控制协议（Real-time Control Protocol，RTCP）也定义在1996年提出的 RFC 1889 中。多媒体网络应用把RTCP和RTP一起使用，尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时，也就是在RTP会话期间，每个参与者周期性地向所有其他参与者发送RTCP控制信息包，如图所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。
RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来修改传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。
实时流放协议(Real-Time Streaming Protocol，RTSP)是一个刚开始开发的协议，它的设想描述在RFC 2326文件中。RTSP是应用级的实时流放协议，它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能，以及支持不同厂家提供的客户机和服务机之间的协同工作能力。
在RTSP中，每个演示（Presentation）及其所对应的媒体流都由一个RTSP URL标识。整个演示及媒体特性都在一个演示描述（Presentation description）文件中定义，该文件可能包括媒体编码方式、语言、RTSP URLs、目标地址、端口及其它参数。用户在向服务器请求某个连续媒体流的服务之前，必须首先从服务器获得该媒体流的演示描述（Presentation description）文件以得到必需的参数，演示描述文件的获取可采用HTTP、email或其他方法。
RTSP中的所有的操作都是通过服务器和客户方的消息应答来完成的，其消息包括请求（Request）和响应（Response）两种，RTSP正是通过服务器和客户端的消息应答来完成媒体流的创建、初始化（SETUP）、VCR(盒式录像机VideoCassetteRecorder)控制（PLAY、PAUSE）以及拆线（TEARDOWN）等操作的。 在基于Client/Server结构的分布式视频点播系统中，RTSP协议的操作过程如图：
客户机在向视频服务器请求视频服务之前，首先通过HTTP协议从Web服务器获取所请求视频服务的演示描述（Presentation description）文件，利用该文件提供的信息定位视频服务地址（包括视频服务器地址和端口号）及视频服务的编码方式等信息。然后客户机根据上述信息向视频服务器请求视频服务(SETUP)。视频服务初始化完毕，视频服务器为该客户建立一个新的视频服务流，客户端与服务器运行实时流控制协议RTSP，以对该流进行各种VCR控制信号的交换，如播放（PLAY）、停止（PAUSE）、快进、快退等。当服务完毕，客户端提出拆线（TEARDOWN）请求，释放资源。
RSVP协议是一种可以提供音频、视频、数据等混合服务的互联网络综合服务（IIS Internet Integrated service ) [RSVP97,RFC1633]。通过它，主机端可以向网络申请特定的QoS，为特定的应用程序提供有保障的数据流服务。同时RSVP在数据流经过的各个路由器节点上对资源进行预留，并维持该状态直到应用程序释放这些资源。
RSVP对资源的申请是单向的，所以RSVP在申请资源的过程中发送端和接受端是逻辑上完全不同的两个部分。（虽然发送端和接受端可以运行在同一个进程下）。RSVP工作在IPv4或IPv6上，处于 OSI七层协议中的传送层，但是，RSVP并不处理传送层的数据，从本质上看，RSVP更象是网络控制协议，如ICMP（Internet Control Message Protocol），IGMP（Internet Group Management Protocol）或是路由协议。和路由协议及管理协议的实现相同，RSVP的实现通常在后台执行，而不是出现在数据传送的路径上。
RSVP本身并不是路由协议，RSVP是和现在或是将来出现的点对点传播和多点组播协议一起工作的。RSVP进程通过本地的路由数据库来获取路由信息，如在多点组播过程中，主机端送出IGMP报文来加入一个多点组播的组群，然后送出RSVP报文在组群的传送路径上保留网络资源，路由协议决定报文的走向，而RSVP仅关心这些报文在它将走的路径上能否获得满意的服务质量。
为了适应可能出现的大规模组群、动态组群、异类接受端的可能，RSVP采取由接受端发起服务质量（QoS）申请的策略。QoS请求从接受端的应用程序出发交给本地的RSVP驻留进程，再由该RSVP驻留进程将该请求递交给沿数据传送的反向路径（接受端至发送端）上的各个节点（路由器或是主机）进行资源的申请。所以，RSVP协议在资源保留上花费一般是呈对数而不是线形幅度增长。
在客户端与流媒体服务器之间建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，这种传送方式为单播。每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担，响应需要很长时间，甚至停止播放，管理人员也被迫增加硬件和宽带来保证一定的服务质量。
组播技术构建一种具有组播能力的网络，允许路由器一次将数据包复制到多个通道上.采用组播方式，单台服务器能够对几十万台客户机同时发送连续数据而无延时。媒体服务器只需要发送一个信息包，而不是多个，所以发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机，以减少网络上传输的信息包的总量。网络利用率大大提高，成本大大降低。
点播连接是客户端与服务器之间的主动连接。在点播连接中，用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连续提供了对流的最大控制，但这种方式由于每个客户各自连接服务器，就会迅速用完网络带宽。
广播指的是用户被动接受流。在广播过程中，客户端接收流，但不能控制流，例如，用户不能暂停、快进或后退该流。在使用单播发送时，需要将数据包复制多个副本，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个副本将发送给网络上的所有用户，而不管用户是否需要。上述两种传输方式非常浪费网络带宽。
组播吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的的那些用户。
目前有三大主流流媒体系统解决方案，包括RealNetWorks的RealServer、Mirosoft的Windows Media Server、Apple的QuickTime Streaming Server（QTSS）
MPEG全称是Moving Pictures Experts Group，它是“动态图象专家组”的英文缩写，该专家组成立于1988年，致力于运动图像及其伴音的压缩编码标准化工作，原先他们打算开发MPEG1、MPEG2、MPEG3和MPEG4四个版本，以适用于不同带宽和数字影像质量的要求。
目前，MPEG1技术被广泛的应用于VCD，而MPEG2标准则用于广播电视和DVD等。MPEG3最初是为HDTV开发的编码和压缩标准，但由于MPEG2的出色性能表现， MPEG3只能是死于襁褓了。MPEG4于1999年初正式成为国际标准。它是一个适用于低传输速率应用的方案。与MPEG1和MPEG2相比，MPEG4更加注重多媒体系统的交互性和灵活性。
MPEG1、MPEG2技术当初制定时，它们定位的标准均为高层媒体表示与结构，但随着计算机软件及网络技术的快速发展，MPEG1、MPEG2技术的弊端就显示出来了：交互性及灵活性较低，压缩的多媒体文件体积过于庞大，难以实现网络的实时传播。而MPEG4技术的标准是对运动图像中的内容进行编码，其具体的编码对象就是图像中的音频和视频，术语称为“AV对象”，而连续的AV对象组合在一起又可以形成AV场景。因此，MPEG4标准就是围绕着AV对象的编码、存储、传输和组合而制定的，高效率地编码、组织、存储、传输AV对象是MPEG4标准的基本内容。
在视频编码方面，MPEG4支持对自然和合成的视觉对象的编码。（合成的视觉对象包括2D、3D动画和人面部表情动画等）。在音频编码上，MPEG4可以在一组编码工具支持下，对语音、音乐等自然声音对象和具有回响、空间方位感的合成声音对象进行音频编码。
由于MPEG4只处理图像帧与帧之间有差异的元素，而舍弃相同的元素，因此大大减少了合成多媒体文件的体积。应用MPEG4技术的影音文件最显著特点就是压缩率高且成像清晰，一般来说，一小时的影像可以被压缩为350M左右的数据，而一部高清晰度的DVD电影, 可以压缩成两张甚至一张650M CD光碟来存储。对广大的“平民”计算机用户来说， 这就意味着, 您不需要购置 DVD-ROM就可以欣赏近似DVD质量的高品质影像。而且采用MPEG4编码技术的影片，对机器硬件配置的要求非常之低，300MHZ 以上CPU，64M的内存和一个 8M显存的显卡就可以流畅的播放。在播放软件方面，它要求也非常宽松，你只需要安装一个 500K左右的 MPEG4 编码驱动后，用 WINDOWS 自带的媒体播放器就可以流畅的播放了。
AV对象（AVO，Audio Visual Object）是MPEG-4为支持基于内容编码而提出的重要概念。对象是指在一个场景中能够访问和操纵的实体，对象的划分可根据其独特的纹理、运动、形状、模型和高层语义为依据。在MPEG-4中所见的音视频已不再是过去MPEG-1、MPEG-2中图像帧的概念，而是一个个视听场景（AV场景），这些不同的AV场景由不同的AV对象组成。AV对象是听觉、视觉、或者视听内容的表示单元，其基本单位是原始AV对象，它可以是自然的或合成的声音、图像。原始AV对象具有高效编码、高效存储与传输以及可交互性的特性，它又可进一步组成复合AV对象。因此MPEG-4标准的基本内容就是对AV对象进行高效编码、组织、存储与传输。AV对象的提出，使多媒体通信具有高度交互及高效编码的能力，AV对象编码就是MPEG-4的核心编码技术。
MPEG-4不仅可提供高压缩率，同时也可实现更好的多媒体内容互动性及全方位的存取性，它采用开放的编码系统，可随时加入新的编码算法模块，同时也可根据不同应用需求现场配置解码器，以支持多种多媒体应用
H.264是由ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（活动图像编码专家组）联合组建的联合视频组（JVT：joint video team）提出的一个新的数字视频编码标准，它既是ITU-T的H.264，又是ISO/IEC的MPEG-4的第10 部分。 而国内业界通常所说的MPEG-4是MPEG-4的第2部分。H.264标准从1998年1月份开始草案征集，到2003年7月，整套H.264 （ISO/IEC 14496-10）规范定稿。2005年1月，MPEG组织正式发布了H.264验证报告，从各个方面论证了H.264的可用性以及各种工具集的效果，从标准的角度，印证H.264的成熟性。
从标准制定到颁布，H.264一直是ITU、MPEG、DVD、DVB、3GPP等工业化组织共同推进的视频编码国际标准，可以想见，在众多行业巨擘的推动下，H.264技术的应用将迅速进入到视频服务、媒体制作发行、固定及移动运营网络、平台开发、设备终端制造、芯片开发等多个领域。
H.264使图像压缩技术上升到了一个更高的阶段，能够在较低带宽上提供高质量的图像传输，该优点非常适合国内运营商用户量大、接入网/骨干网带宽相对有限的状况。在同等的画质下，H.264比上一代编码标准MPEG2平均节约64％的传输码流，而比MPEG4 ASP要平均节约39％的传输码流。全球很多IPTV业务运营商都将H.264作为编解码格式的标准，包括比利时电信，荷兰KPN，泰国ADC电信，中国电信等等。
根据中国电信上海研究院的实际测试结果表明：国内普遍采用的MPEG-4编码技术在3Mbps的带宽下尚达不到标清的图像质量，而H.264编码技术可以在2M带宽下提供要求的图像效果。因而运营商希望引入更先进的H.264编码技术，在有限的带宽资源下进一步提高图像质量
本文发布于:2024-01-31 18:10:56，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170669585630403.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
