音视频开发术语介绍

视频分辨率

标清、高清、720P…
标清：意思就是“标准清晰度”，是物理分辨率在720p以下的视频格式。所谓标清，英文为“Standard Definition”，是物理分辨率在1280P*720P以下的一种视频格式，是指视频的垂直分辨率为720线逐行扫描。具体的说，是指分辨率在400线左右的VCD、DVD、电视节目等“标清”视频格式，即标准清晰度。
高清：而物理分辨率达到720p以上的格式则称作为高清，英文表述High Definition，简称HD。作为“高清”的入门级标准，720p是指视频的垂直分辨率为720线逐行扫描，也就是说电视的屏幕必须能够同时、完整地显示720条横线。如果用显示器中常见的分辨率A×B的形式来表示，则720p的分辨率至少必须是1280×720，此外常见的1280×1024、1280×768、1280×800等分辨率也都支持720p高清格式。反过来再看标清的分辨率，我们经常接触到的是640×480、720×576或者800×600这些分辨率，它们在垂直分辨率上都不到720线，因此不属于“高清”范畴。那么，是不是只要垂直分辨率达到720线，就能称为高清呢？答案是否定的。关于高清的标准，国际上公认的有两条：视频垂直分辨率超过720p或1080i（p代表逐行扫描，i代表隔行扫描，这个概念和CRT电视基本相同），同时视频宽纵比为16:9。对于垂直分辨率我们已经有了直观的认识，而所谓宽纵比，其实就是视频画面的“长宽比”，如果用一个矩形来表示，那么它的长和宽的比例必须符合16:9——也就是我们俗称的“宽屏”或者“宽银幕”。按照这个比例推算，则720p的分辨率至少为1280×720，这样才符合16:9的要求，因此这也就是720p的标准分辨率。
看最后总结：其实“高清”和“标清”不能简单的比较，它们只是二种不同的视频格式，它们都可以装载各种不同质量的视频信号，因此实际质量与所装载的视频信号质量有很大的关系，这相当于用水缸和茶杯装水，水缸可以装一大缸水，也可以只装一杯水，当只装一杯水的时候就不能说它装的水比茶杯中的一杯水要多了。

视频编码

H.264、H.265…
H.264: 是MPEG-4（MPEG-4是MPEG格式的一个压缩标准）第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）而明确的说明它两方面的开发者。

H.264优点：
1．低码率（Low Bit Rate）：和MPEG2和MPEG4 ASP等压缩技术相比，在同等图像质量下，采用H.264技术压缩后的数据量只有MPEG2的1/8，MPEG4的1/3。
2．高质量的图像：H.264能提供连续、流畅的高质量图像（DVD质量）。
3．容错能力强：H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。
4．网络适应性强：H.264提供了网络抽象层（Network Abstraction Layer），使得H.264的文件能容易地在不同网络上传输（例如互联网，CDMA，GPRS，WCDMA，CDMA2000等）。
H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件的大小如果为88GB，采用MPEG-2压缩标准压缩后变成3.5GB，压缩比为25∶1，而采用H.264压缩标准压缩后变为879MB，从88GB到879MB，H.264的压缩比达到惊人的102∶1。低码率（Low Bit Rate）对H.264的高的压缩比起到了重要的作用，和MPEG-2和MPEG-4 ASP等压缩技术相比，H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是，H.264在具有高压缩比的同时还拥有高质量流畅的图像，正因为如此，经过H.264压缩的视频数据，在网络传输过程中所需要的带宽更少，也更加经济。

H.265: H.265是ITU-T VCEG 继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置.
H.265特点：H.265旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这也意味着，我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。

音频编码

AAC、MP3、AC3…
AAC: 一种专为声音数据设计的文件压缩格式，与MP3不同，它采用了全新的算法进行编码，更加高效，具有更高的“性价比”。利用AAC格式，可使人感觉声音质量没有明显降低的前提下，更加小巧。苹果ipod、诺基亚手机也支持AAC格式的音频文件。
AAC优点：相对于mp3，AAC格式的音质更佳，文件更小。
AAC不足：AAC属于有损压缩的格式，与时下流行的APE、FLAC等无损格式相比音质存在“本质上”的差距。加之，传输速度更快的USB3.0和16G以上大容量MP3正在加速普及，也使得AAC头上“小巧”的光环不复存在了。

MP3: MP3是一种音频压缩技术，其全称是动态影像专家压缩标准音频层面3（Moving Picture Experts Group Audio Layer III），简称为MP3。它被设计用来大幅度地降低音频数据量。利用 MPEG Audio Layer 3 的技术，将音乐以1:10 甚至 1:12 的压缩率，压缩成容量较小的文件，而对于大多数用户来说重放的音质与最初的不压缩音频相比没有明显的下降。
MP3特点：MP3是利用人耳对高频声音信号不敏感的特性，将时域波形信号转换成频域信号，并划分成多个频段，对不同的频段使用不同的压缩率，对高频加大压缩比（甚至忽略信号）对低频信号使用小压缩比，保证信号不失真。这样一来就相当于抛弃人耳基本听不到的高频声音，[1] 只保留能听到的低频部分，从而将声音用1∶10甚至1∶12的压缩率压缩。由于这种压缩方式的全称叫MPEG Audio Player3，所以人们把它简称为MP3。

视频封装格式

TS、m3u8…
经常说的TS流，或者说传一个m3u8地址过来，指的都是视频的封装格式。如果放到浏览器中请求时，就会写成一个流文件，可以打开看，里面就是传的播放视频的帧。也可以把视频封装成TS文件，然后用播放器进行播放。m3u8可以做多码率的适配，根据网络带宽，客户端会选择一个适合自己码率的文件进行播放，保证视频流的流畅。
多媒体播放组件(Android)
MediaPlayer、MediaCodec、OMX、Stagefright
MediaPlayer：播放控制
MediaCodec： 音视频编解码
OMX：多媒体部分采用的编解码标准
Stagefright：一个框架，替代之前的opencore，主要是做了一个OMX层，仅仅是对 opencore的omx-component部分做了引用。stagefright是在MediaPlayerService这一层加入的，和opencore是并列的。Stagefright在 Android中是以shared library的形式存在(libstagefright.so)，其中的module – AwesomePlayer可用来播放video/audio。 AwesomePlayer提供许多API，可以让上层的应用程序(Java/JNI)来调用。（后面文章会详细介绍这个框架）
… …

视频部分相关

分辨率
一帧视频的大小，表示长宽像素个数(720x576, 1280x720, 1920x1080 …)
屏幕图像的精密度，是指一帧视频图像所能显示的像素有多少。由于屏幕上的点、线和面都是由像素组成的，可显示的像素越多，画面就越精细，同样的屏幕区域内能显示的信息也越多，所以分辨率是个非常重要的性能指标之一。可以把整个图像想象成是一个大型的棋盘，而分辨率的表示方式就是所有经线和纬线交叉点的数目。显示分辨率一定的情况下，显示屏越小图像越清晰，反之，显示屏大小固定时，显示分辨率越高图像越清晰。

帧率
每秒钟视频帧数(24/25/30/48/60 FPS)
由于人类眼睛的特殊生理结构，如果所看画面之帧率高于24的时候，就会认为是连贯的，此现象称之为视觉暂留。这也就是为什么电影胶片是一格一格拍摄出来，然后快速播放的。
而对游戏，一般来说，第一人称射击游戏比较注重FPS的高低，如果FPS<30的话，游戏会显得不连贯。所以有一句有趣的话：“FPS（指FPS游戏）重在FPS（指帧率）。
每秒的帧数(fps)或者说帧率表示图形处理器处理场时每秒钟能够更新的次数。高的帧率可以得到更流畅、更逼真的动画。一般来说30fps就是可以接受的，但是将性能提升至60fps则可以明显提升交互感和逼真感，但是一般来说超过75fps一般就不容易察觉到有明显的流畅度提升了。如果帧率超过屏幕刷新率只会浪费图形处理的能力，因为监视器不能以这么快的速度更新，这样超过刷新率的帧率就浪费掉了。

刷新率
刷新频率：即屏幕刷新的速度。
刷新频率越低，图像闪烁、停顿和抖动的就越厉害，眼睛疲劳得就越快。
采用70Hz以上的刷新频率时才能基本消除闪烁，显示器最好稳定工作在允许的最高频率下，一般是85Hz。

编码格式
编码：目的是压缩数据量，采用编码算法压缩冗余数据
MPEG(MPEG-2, MPEG-4)
H.26X(H.263, H.264/AVC, H.265/HEVC)

封装格式
把编码后的音、视频数据以一定格式封装到一个容器
MKV/AVI/TS …

码率
每秒钟视频数据的比特位数(bps)
文件大小(b) = 码率(b/s) * 时长(s)

画质 vs 码率
码率越大，画质越好，视频越流畅吗？(错)
视频质量和码率、编码算法都有关系

音频部分相关

编码格式
有损编码: AAC/MP3/AMR/WMA
无损编码: WAV/FLAC/APE/ALAC
补充：用无损编码压缩的数据是可以完全恢复的，解码后的数据一原始数据完全一致，压缩比较小；有损编码在编码过程中要丢失不易察觉的信息，且丢失的数据不可恢复，压缩比较大

量化精度
可以将模拟信号分成多少个等级,量化精度越高，音乐的声压振幅越接近原音乐.
量化精度的单位是Bit，CD标准的量化精度是16Bit，DVD标准的量化精度是24Bit。
也可理解为一个采样点用多少bit表示(8/16/24/32bit)

采样率
每秒钟音频采样点个数(8000/44100Hz)
采样率单位用Hz(赫兹)表示

声道数目
立体声，5.1，7.1声道
立体声：声音在录制过程中被分配到两个独立的声道，从而达到了很好的声音定位效果。这种技术在音乐欣赏中显得尤为有用，听众可以清晰地分辨出各种乐器来自的方向，从而使音乐更富想象力，更加接近于临场感受。立体声技术广泛运用于自Sound Blaster Pro以后的大量声卡，成为了影响深远的一个音频标准。
5.1声道：其实5.1声音系统来源于4.1环绕，不同之处在于它增加了一个中置单元。这个中置单元负责传送低于80Hz的声音信号，在欣赏影片时有利于加强人声，把对话集中在整个声场的中部，以增加整体效果。杜比AC-3（Dolby Digital）、DTS等都是以5.1声音系统为技术蓝本的。相信每一个真正体验过Dolby AC-3音效的朋友都会为5.1声道所折服。现在广泛用于传统影院和家庭影院。

音频帧
一定数目的采样点数的集合
编码: 基本编码单元
举例: 音频帧的播放时间 = 一个AAC帧对应的采样样本的个数 / 采样频率(单位为s)。
采样率(samplerate)为 44100Hz，表示每秒 44100个采样点,
所以，根据公式,
音频帧的播放时长 = 一个AAC帧对应的采样点个数 / 采样频率
则，当前一帧的播放时间 = 1024 * 1000000/44100= 22.32ms(单位为ms)
48kHz采样率:
则，当前一帧的播放时间 = 1024 * 1000000/48000= 21.32ms(单位为ms)
22.05kHz采样率:
则，当前一帧的播放时间 = 1024 * 1000000/22050= 46.43ms(单位为ms)

RTSP、 RTMP、HTTP的共同点、区别

共同点：

1：RTSP RTMP HTTP都是在应用应用层。

2： 理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

区别：

1：HTTP: 即超文本传送协议(ftp即文件传输协议)。

HTTP:（Real Time Streaming Protocol），实时流传输协议。

HTTP全称Routing Table Maintenance Protocol（路由选择表维护协议）。

2：HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。

RTMP和RTSP协议是流媒体协议。

3：RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。

5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

1、视频编码标准两大系统是什么？

视频编码标准有两大系统：MPEG和ITU-T，如下

视频编码标准

MPEG标准由MPEG制定

MPEG-1 | MPEG-2 | (MPEG-3) | MPEG-4 | MPEG-7 | MPEG-21

ITU-T标准由VCEG制定

H.261 | (H.262) | H.263 | H.263v2 | H.264

2、什么是音视频编码格式？什么是音视频封装格式？

常见的AVI、RMVB、MKV、ASF、WMV、MP4、3GP、FLV等文件其实只能算是一种封装标准。

一个完整的视频文件是由音频和视频2部分组成的。H264、Xvid等就是视频编码格式，MP3、AAC等就是音频编码格式。

例如：将一个Xvid视频编码文件和一个MP3视频编码文件按AVI封装标准封装以后，就得到一个AVI后缀的视频文件，这个就是我们常见的AVI视频文件了。

由于很多种视频编码文件、音频编码文件都符合AVI封装要求，则意味着即使是AVI后缀，也可能里面的具体编码格式不同。因此出现在一些设备上，同是AVI后缀文件，一些能正常播放，还有一些就无法播放。

同样的情况也存在于其他容器格式。即使RMVB、WMV等也不例外，事实上，很多封装容器对音频编码和视频编码的组合方式放的很开，如AVI还可以使用H.264+AAC组合，可以在具体使用中自己体会。尤其是MKV封装容器，基本无论什么样的组合都可以！但一般MKV用的最多的就是H.264+AAC组合，此组合文件体积最小，清晰度最高。因此网上很多MKV视频都是高清晰度的。

因此，视频转换需要设置的本质就是：A设置需要的视频编码、B设置需要的音频编码、C选择需要的容器封装。一个完整的视频转换设置都至少包括了上面3个步骤。

3、平时说的软解和硬解，具体是什么？

硬解就是硬件解码，指利用GPU来部分代替CPU进行解码，软解就是软件解码，指利用软件让CPU来进行解码。两者的具体区别如下所示：

硬解码：是将原来全部交由CPU来处理的视频数据的一部分交由GPU来做，而GPU的并行运算能力要远远高于CPU，这样可以大大的降低对CPU的负载，CPU的占用率较低了之后就可以同时运行一些其他的程序了，当然，对于较好的处理器来说，比如i5 2320，或者AMD 任何一款四核心处理器来说，硬解和软件的区别只是个人偏好问题了吧。　　

软解码：即通过软件让CPU来对视频进行解码处理；而硬解码：指不借助于CPU，而通过专用的子卡设备来独立完成视频解码任务。曾经的VCD/DVD解压卡、视频压缩卡等都隶属于硬解码这个范畴。而现如今，要完成高清解码已经不再需要额外的子卡，因为硬解码的模块已经被整合到显卡GPU的内部，所以目前的主流显卡（集显）都能够支持硬解码技术。

4、何为直播？何为点播？

直播：是一个三方交互(主播、服务器、观众)，这个交互式实时的！尽管会根据选择的协议不同而有一些延迟，但我们仍认为它直播是实时的！—>主播在本地发送音视频给服务器（推流），观众从服务器实时解码（拉流）收看收听主播发送给服务器的音视频（直播内容）。直播是不能快进的
点播：首先一定要明确的一点，点播不存在推流这一过程，你本身你的流已经早就推给服务器了，或者这么说也不对，应该是你的音视频早就上传到了服务器，观众只需要在线收看即可，由于你的音视频上传到了服务器，观众则可以通过快进，快退，调整进度条等方式进行收看！

5、简述推流、拉流的工作流程？

推流：在直播中，一方向服务器发送请求，向服务器推送自己正在实时直播的数据，而这些内容在推送到服务器的这一过程中是以 “流” 的形式传递的，这就是“推流”，把音视频数据以流的方式推送（或上传）到服务器的过程就是“推流”！推流方的音视频往往会很大，在推流的过程中首先按照 aac音频-编码 和 h264视频-编码的标准把推过来的音视频压缩 ，然后合并成 MP4或者 FLV格式，然后根据直播的封装协议，最后传给服务器完成推流过程。

拉流：与推流正好相反，拉流是用户从服务器获取推流方给服务器的音视频的过程，这就是“拉流”！拉流首先aac音频-解码 和 h.264视频-解码的内部把推过来的音视频解压缩，然后合成 MP4或者 FLV 格式，再解封装，最后到我们的客户端与观众进行交互。

6、常见的直播协议有哪些？之间有什么区别？

常见的直播协议有三种 RTMP、HLS、FLV…

1、RTMP：real time messaging protocol~实时传输协议，RTMP协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。

2、FLV：FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。

3、HLS：苹果原生：HTTP Live Streaming，遵循的是 HTTP 超文本传输协议，端口号8080，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS的一般延迟在10-30s左右）。

7、点播中常见的数据传输协议主要有哪些？

常见的点播协议：HLS，HTTP

8、何为Nginx？有什么特点？

Nginx 是一个遵循 HTTP 协议的服务器！内存占用少，并发能力强！ 还有等等的优点，可自行google

9、何为homebrew？你用它安装过什么？常用命令有哪些？

homebrew是一个 Mac系统下所独有的套件管理器，我要做直播，需要 rtmp 和 nginx ，单独安装很复杂，只要在终端里输入简单的安装相应的套件命令即可完成安装，复杂的过程都靠 homebrew 规避掉了！
我用它安装过很多东西，比如nginx 搭建流媒体服务器等。
常用命令：brew install 、brew uninstall、brew search、brew list、brew update、brew help 等~

10、FFmpeg是什么？

FFmpeg是一套用来记录和转换数字音视频，并能将其转化为流的开源计算机程序。拉流和推流离不开 FFmpeg 的帮助！

11、RTMP、HLS协议各自的默认端口号是？

RTMP端口号：1935

HLS端口号 ：8080

12、m3u8构成是？直播中m3u8、ts如何实时更新？

是一个索引地址/播放列表，通过FFmpeg将本地的xxx.mp4进行切片处理，生成m3u8播放列表（索引文件）和N多个 .ts文件，并将其（m3u8、N个ts）放置在本地搭建好的webServer服务器的指定目录下，我就可以得到一个可以实时播放的网址，我们把这个m3u8地址复制到 VLC 上就可以实时观看！
在 HLS 流下，本地视频被分割成一个一个的小切片，一般10秒一个，这些个小切片被 m3u8管理，并且随着终端的FFmpeg 向本地拉流的命令而实时更新，影片进度随着拉流的进度而更新，播放过的片段不在本地保存，自动删除，直到该文件播放完毕或停止，ts 切片会相应的被删除，流停止，影片不会立即停止，影片播放会滞后于拉流一段时间。

13、简述如何在Mac上搭建本地直播服务器？

FFmpeg推流至Nginx：可以推两种流：RTMP流，推流至rtmplive；HLS流，推流至hls；其中，HLS流表现较明显，在nginx的临时目录下，直观的可看到m3u8索引文件和N多个.ts文件。m3u8列表会实时更新，且会动态更改当前播放索引切片（.ts）。这种实时更新的机制，不会使得.ts文件长时间存在于Nginx服务器上，且当推流结束之后，该目录下的内容会被全部清除，这样无形中减缓了nginx服务器的压力。另外，也阐释了HLS这种流媒体播放相较RTMP延时较高的原因。

14、说说你平时在播放过程中做的优化工作

预加载，弱网优化，播放出错重试机制，运营商劫持引起的起播慢，mediaserver的cpu占有率很高，引起播放卡顿。起播时，只保留播放进程，kill 其他进程 。

本文转自： http://blog.csdn.net/hejjunlin/article/details/52431887
http://blog.csdn.net/hejjunlin/article/details/54962205