文章目录

02FFmpeg-音视频基本概念
- 基本概念
- 音、视频编解码 ---- 编码
- - 视频
  - 音频
- 音、视频编解码 ---- 转码
- - 视频
  - 音频
- 音、视频编解码 ---- 封装-解封装
- - 封装（mux）
  - 解封装（demux）
- 音视频的各种流
- - ES流
  - PES流
  - TS流
  - rtsp流：
  - - RTSP
    - RTP
    - 注： RTSP和RTP的区别
  - rtmp/rtmps
  - hls流：
  - 其他流： RTCP SRTP & SRTCP SDP mms
  - - RTCP
    - SRTP & SRTCP
    - SRTP & SRTCP
    - SDP
    - mms
  - http协议
  - 服务端-客户端-流媒体
  - 推模式--拉模式--实时流
- 视频概念
- image概念
- I、P、B 帧
- DTS、PTS 的概念
- 音视频的同步
- - PCM文件格式简单介绍

02FFmpeg-音视频基本概念

基本概念

编码（encode）

减少字节的算法======> 通过特定的压缩算法，将某个视频的视频流格式转换成另一种视频格式的视频流方法
解码（decode）

压缩后的是一堆数据，将数据还原程未编码前前的格式，=====>通过特定的解压缩技术，将某个视频格式的视频流转换为另一种视频格式的视频流格式
转码（transcode）

高清摄像机1080p原始转化为VGA—640*480,让视频的占用率更小 ========>通过特定的解压缩技术，将某个视频格式的视频流转换为另一种视频格式的视频流格式

音、视频编解码 ---- 编码

视频

左侧为图片的输入（frame 帧）---->右侧为图片的输出
video编码一般是针对一个图片序列，输出是一个H264的图片流
YUV420/422—>H264(算法的名字)
RGB888/RGB565–>H264
YUV420–>H263

音频

PCM（原始）—>AAC
PCM(原始)—>G726
PCM(原始)—>G711
解码之后是原始的PCM格式的，其他的都是编码之后的格式

编码输入的是一张图片（各种格式），由各种像素点组成，图片可以抽象成像素的集合，（矩阵表示），人眼可以识别

音、视频编解码 ---- 转码

视频

改变分辨率（resolution） 1920x1280 ==>640x480 原始的图片的分辨率（宽*高）
改变帧率（frame rate） 1s改变25帧，一般是15帧以上看起来是流畅的，大于25帧或30帧之后无法分辨
改变比特率（bit rate）（存放为文件的话改变大小，视频传输的话影响带宽）等编码参数

音频

改变采样率（sample rate）采样率为8000，则1s有8000个采样点，音频为连续的信号，需要量化，则通过采样点来量化音频信号
改变通道数（channels）单通道—多通道等，通道转化与融合
改变位宽（sample format） 8位，24位的，精确度不一样，表达的颜色范围不一样

音、视频编解码 ---- 封装-解封装

封装（mux）

复用，按格式组织原始音视频流—当流传输或存储的时候总是需要一定的文件格式，封装的头内包含视频的开始结束，视频的时间长度，有多少包等，在原始的视频流上加上额外信息描述视频

解封装（demux）

解复用，按照一定格式（封装格式等）解析出原始的音视频流

音视频的各种流

IP数据报有首部和数据两部分组成的，首部的前一部分是固定长度20字节，是所有IP数据报必须具有的。首部包括：总长度、标识、MF、DF、片偏移

ES流

原始流，直接从编码器出来的数据流，没有额外的信息，包含视频、音频或数据的连续码流。

PES流

ES形成的分组成为PES分组，打包的基本码流，是将基本的码流ES流根据需要分成长度不等的数据包，并加上包头就形成了打包的基本码流PES流。

TS流

TS流：也叫传输流，是由固定长度为188字节的包组成，含有独立时基的一个或多个program, 一个program又可以包含多个视频、音频、和文字信息的ES流; 每个ES流会有不同的PID标示. 而又为了可以分析这些ES流, TS有一些固定的PID用来间隔发送program和ES流信息的表格: PAT和PMT表。适用于误码较多的环境。
特点：可以被任意截断

TS流（TransportStream）即在MPEG-2系统中，由视频，音频的ES流和辅助数据复接生成的用于实际传输的标准信息流称为MPEG-2 传送流。
信息复合/分离的过程称为系统复接/分接，据传输媒体的质量不同，MPEG-2中定义了两种复合信息流：传送流（TS）和节目流（PS：ProgramStream）

注：TS流与PS流的区别
1、TS流的包结构是固定长度的，而PS流的包结构是可变长度。
2、PS包与TS包在结构上的这种差异—是否具有固定长度的包结构
TS码流由于采用了固定长度的包结构，当传输误码破坏了某一TS包的同步信息时，接收机可在固定的位置检测它后面包中的同步信息，从而恢复同步，避免了信息丢失。
而PES包由于长度是变化的，一旦某一PS包的同步信息丢失，接收机无法确定下一包的同步位置，就会造成失步，导致严重的信息丢失。

3、实用环境
在信道环境较为恶劣，传输误码较高时，一般采用TS码流；而在信道环境较好，传输误码较低时，一般采用PS码流，由于TS码流具有较强的抵抗传输误码的能力，因此目前在传输媒体中进行传输的MPEG-2码流基本上都采用了TS码流的包。

rtsp流：

RTSP（real time streaming protocol）RFC2326,实时流传输协议，是TCP/IP协议体系中的一个应用层协议

RTSP

是由Real Networks和Netscape共同提出的。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，
传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，
它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。
而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。
因为与HTTP1.1的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，并因RTSP具有重新导向功能，
可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTP

RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。
RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。
RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。

注： RTSP和RTP的区别

RTSP与RTP最大的区别在于：
RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。
当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。
它时一种类似与http协议的网络应用层协议。
目前碰到的一个应用：服务器端实时采集、编码并发送两路视频，客户端接收并显示两路视频。由于客户端不必对视频数据做任何回放、倒退等操作，可直接采用UDP+RTP+组播实现。

2，RTSP协议
（1）是流媒体协议。
（2）RTSP协议是共有协议，并有专门机构做维护。.
（3）RTSP协议一般传输的是 ts、mp4 格式的流。
（4）RTSP传输一般需要 2-3 个通道，命令和数据通道分离。

rtmp/rtmps

rtmp/rtmps ： Real Time Messaging Protocol（实时消息传输协议），是adobe公司的协议

RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
它有三种变种：

1)工作在TCP之上的明文协议，使用端口1935；
2)RTMPT封装在HTTP请求之中，可穿越防火墙；
3)RTMPS类似RTMPT，但使用的是HTTPS连接；

  RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上.RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

1，RTMP协议

（1）是流媒体协议。
（2）RTMP协议是 Adobe 的私有协议，未完全公开。
（3）RTMP协议一般传输的是 flv，f4v 格式流。
（4）RTMP一般在 TCP 1个通道上传输命令和数据。

hls流：

HLS是Apple的动态码率自适应技术，主要用于PC和Apple终端的音视频服务，包括一个m3u8的索引文件，TS媒体分片文件

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。

根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点

1、采集视频源和音频源的数据
2、对原始数据进行H264编码和AAC编码
3、视频和音频数据封装为MPEG-TS包
4、HLS分段生成策略及m3u8索引文件
5、HTTP传输协议

其他流： RTCP SRTP & SRTCP SDP mms

RTCP

实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。
RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

SRTP & SRTCP

安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC3711发布。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；
安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。
唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

SRTP & SRTCP

SDP

会话描述协议（SDP）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。
会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。
SDP 的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但 SDP 不支持会话内容或媒体编码的协商。
在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web）进行发送。

SDP 文本信息包括：

会话名称和意图；
会话持续时间；
构成会话的媒体；
有关接收媒体的信息（地址等）。
协议结构
SDP 信息是文本信息，采用 UTF-8 编码中的 ISO 10646 字符集。SDP 会话描述如下：（标注 * 符号的表示可选字段）：
v = （协议版本）
o = （所有者/创建者和会话标识符）
s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b = * （带宽信息）

一个或更多时间描述（如下所示）：

z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
0个或多个媒体描述（如下所示）

时间描述

t = （会话活动时间）
r = * （0或多次重复次数）

媒体描述
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）
a = * （0 个或多个会话属性行）

mms

MMS (Microsoft Media Server Protocol)，中文“微软媒体服务器协议”，用来访问并流式接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播内容。MMS 是连接 Windows Media 单播服务的默认方法。若观众在 Windows Media Player 中键入一个 URL 以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。MMS的预设埠（端口）是1755

当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。

如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。
若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。例如：mms://windows_media_server/LiveEvents。这里 windows_media_server 是 Windows Media 服务器名，而 LiveEvents 是发布点名

http协议

3，HTTP协议
（1）不是是流媒体协议。
（2）HTTP协议是共有协议，并有专门机构做维护。
（3）HTTP协议没有特定的传输流。
（4）HTTP传输一般需要 2-3 个通道，命令和数据通道分离。

服务端-客户端-流媒体

实例：一个收费站有100个摄像头，每天采集大量的视频数据，我想在公司访问这些摄像头数据，在家访问，在手机端访问等等，需求各异，所以需要将摄像头采集的视频存储在一个公共的地方，我们把这个地方称之为服务器

服务端
一个公共的地方，大家都可以访问，为大家服务的地方：服务端为客户端服务，向客户端提供资源（音视频资源），并保存客户端的数据

客户端
用户端，与服务器端对应，为客户端提供本地服务的应用程序（比如： android手机端，Apple手机端等）

流媒体
（本质：传输音视频流的–转发，存储，转码等等）采用流式传输方式在internet播放的媒体格式

推模式–拉模式–实时流

推模式
当通知消息来之时，把所有相关信息通过参数的形式“推给”观察者（将数据直接打包，发给你，比如抖音，将拍的视频发送到抖音的服务器上，服务器端不知道你什么时候发）

拉模式
当通知消息来时，通知的函数不带任何相关的信息，需要观察者主动去“拉”消息，（比如你要看服务器端的视频，主动去要）

实时流
Real Time Stream 实时传输的音视频流（比如世界杯，NBA，录像回放等等）

视频概念

视频的播放过程可以简单理解为一帧一帧的画面按照时间顺序呈现出来的过程，
就像在一个本子的每一页画上画，然后快速翻动的感觉。

image概念

但是在实际应用中，并不是每一帧都是完整的画面，因为如果每一帧画面都是完整的图片，
那么一个视频的体积就会很大，这样对于网络传输或者视频数据存储来说成本太高，
所以通常会对视频流中的一部分画面进行压缩（编码）处理。
由于压缩处理的方式不同，视频中的画面帧就分为了不同的类别，其中包括：I 帧、P 帧、B 帧。

I、P、B 帧

I 帧、P 帧、B 帧的区别在于：
I 帧（Intra coded frames）：

I 帧图像采用帧内编码方式，即只利用了单帧图像内的空间相关性，而没有利用时间相关性。
I 帧使用帧内压缩，不使用运动补偿，由于 I 帧不依赖其它帧，所以是随机存取的入点，同时是解码的基准帧。
I 帧主要用于接收机的初始化和信道的获取，以及节目的切换和插入，I 帧图像的压缩倍数相对较低。
I 帧图像是周期性出现在图像序列中的，出现频率可由编码器选择。

P 帧（Predicted frames）：

P 帧和 B 帧图像采用帧间编码方式，即同时利用了空间和时间上的相关性。
P 帧图像只采用前向时间预测，可以提高压缩效率和图像质量。
P 帧图像中可以包含帧内编码的部分，即 P 帧中的每一个宏块可以是前向预测，也可以是帧内编码。

B 帧（Bi-directional predicted frames）：

B 帧图像采用双向时间预测，可以大大提高压缩倍数。
值得注意的是，由于 B 帧图像采用了未来帧作为参考，因此 MPEG-2 编码码流中图像帧的传输顺序和显示顺序是不同的。

简单总结：

一个 I 帧可以不依赖其他帧就解码出一幅完整的图像，而 P 帧、B 帧不行。
P 帧需要依赖视频流中排在它前面的帧才能解码出图像。
B 帧则需要依赖视频流中排在它前面或后面的帧才能解码出图像。

这就带来一个问题：
在视频流中，先到来的 B 帧无法立即解码，需要等待它依赖的后面的 I、P 帧先解码完成，
这样一来播放时间与解码时间不一致了，顺序打乱了，那这些帧该如何播放呢？
这时就需要我们来了解另外两个概念：DTS 和 PTS。

DTS、PTS 的概念

DTS（Decoding Time Stamp）：即解码时间戳，这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。
PTS（Presentation Time Stamp）：即显示时间戳，这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

需要注意的是：虽然 DTS、PTS 是用于指导播放端的行为，但它们是在编码的时候由编码器生成的。
当视频流中没有 B 帧时，通常 DTS 和 PTS 的顺序是一致的。
但如果有 B 帧时，就回到了我们前面说的问题：解码顺序和播放顺序不一致了。

比如一个视频中，帧的显示顺序是：I B B P，现在我们需要在解码 B 帧时知道 P 帧中信息，因此这几帧在视频流中的顺序可能是：I P B B，这时候就体现出每帧都有 DTS 和 PTS 的作用了。
DTS 告诉我们该按什么顺序解码这几帧图像，PTS 告诉我们该按什么顺序显示这几帧图像。顺序大概如下：
PTS: 1 4 2 3
DTS: 1 2 3 4
Stream: I P B B

音视频的同步

上面说了视频帧、DTS、PTS 相关的概念。
我们都知道在一个媒体流中，除了视频以外，通常还包括音频。
音频的播放，也有 DTS、PTS 的概念，但是音频没有类似视频中 B 帧，不需要双向预测，所以音频帧的 DTS、PTS 顺序是一致的。

音频视频混合在一起播放，就呈现了我们常常看到的广义的视频。
在音视频一起播放的时候，我们通常需要面临一个问题：怎么去同步它们，以免出现画不对声的情况。

要实现音视频同步，通常需要选择一个参考时钟，参考时钟上的时间是线性递增的，
编码音视频流时依据参考时钟上的时间给每帧数据打上时间戳。
在播放时，读取数据帧上的时间戳，同时参考当前参考时钟上的时间来安排播放。
这里的说的时间戳就是我们前面说的PTS。
实践中，我们可以选择：同步视频到音频、同步音频到视频、同步音频和视频到外部时钟。

PCM文件格式简单介绍

PCM文件：**模拟音频信号经模数转换（A/D变换）直接形成的二进制序列，该文件没有附加的文件头和文件结束标志。**Windows的Convert工具能够把PCM音频格式的文件转换成Microsoft的WAV格式的文件。
将音频数字化。事实上就是将声音数字化。最常见的方式是透过脉冲编码调制PCM(Pulse Code Modulation) 。

运作原理例如以下:首先我们考虑声音经过麦克风，转换成一连串电压变化的信号。例如以下图所看到的。这张图的横座标为秒。纵座标为电压大小。要将这种信号转为 PCM 格式的方法，是使用三个參数来表示声音。它们是：声道数、採样位数和採样频率。

採样频率：**即取样频率,指每秒钟取得声音样本的次数。採样频率越高,声音的质量也就越好,声音的还原也就越真实，但同一时候它占的资源比較多。因为人耳的分辨率非常有限,太高的频率并不能分辨出来。
在16位声卡中有22KHz、44KHz等几级,当中，22KHz相当于普通FM广播的音质，44KHz已相当于CD音质了，眼下的经常使用採样频率都不超过48KHz。

採样位数：**即採样值或取样值（就是将採样样本幅度量化）。它是用来衡量声音波动变化的一个參数。也能够说是声卡的分辨率。
它的数值越大，分辨率也就越高。所发出声音的能力越强。

声道数：**非常好理解，有单声道和立体声之分，单声道的声音仅仅能使用一个喇叭发声（有的也处理成两个喇叭输出同一个声道的声音）。立体声的PCM 能够使两个喇叭都发声（一般左右声道有分工），更能感受到空间效果。

以下再用图解来看看採样位数和採样频率的概念。让我们来看看这几幅图。图中的黑色曲线表示的是PCM 文件录制的自然界的声波，红色曲线表示的是PCM 文件输出的声波。横坐标便是採样频率；纵坐标便是採样位数。

这几幅图中的格子从左到右，逐渐加密，先是加大横坐标的密度，然后加大纵坐标的密度。显然，当横坐标的单位越小即两个採样时刻的间隔越小。则越有利于保持原始声音的真实情况，换句话说，採样的频率越大则音质越有保证；同理，当纵坐标的单位越小则越有利于音质的提高。即採样的位数越大越好。

在计算机中採样位数一般有8位和16位之分。但有一点请大家注意，8位不是说把纵坐标分成8份，而是分成2的8次方即256份；同理16位是把纵坐标分成2的16次方65536份；而採样频率一般有11025HZ（11KHz），22050HZ（22KHz）、44100Hz（44KHz）三种。

那么，如今我们就能够得到PCM文件所占容量的公式：存储量 = (採样频率*採样位数*声道)*时间/8(单位：字节数).
比如，数字激光唱盘(CD－DA。红皮书标准)的标准採样频率为44.lkHz。採样数位为16位，立体声(2声道)，能够差点儿无失真地播出频率高达22kHz的声音，这也是人类所能听到的最高频率声音。

激光唱盘一分钟音乐须要的存储量为：

(44.1*1000*l6*2)*60/8=10。584。000(字节)=10.584MBytes

这个数值就是PCM声音文件在硬盘中所占磁盘空间的存储量。
计算机音频文件的格式决定了其声音的品质，日常生活中电话、收音机等均为模拟音频信号。即不存在採样频率和採样位数的概念，我们能够这样比較一下：

44KHz，16BIT的声音称作：CD音质；
22KHz、16Bit的声音效果近似于立体声（FM Stereo）广播。称作：广播音质；
11kHz、8Bit的声音，称作：电话音质。

微软的WAV文件就是PCM编码的一种,在后面我会具体介绍.

上述内容摘自很多博客和王纲老师的音视频教程，由于时间悠久，记不得具体的来源，原作看到请见谅，如果错误请留言…