音视频基础知识

简易版音视频图解如下

音视频基础知识_第1张图片

对于一个实时音视频应用共包括:采集、编码、前后处理、传输、解码、缓冲、渲染等环节。每个环节还有更细分的技术模块。比如,前后处理环节有美颜、滤镜、回声消除AEC、噪声抑制NS、静音控制VAD、自动增益控制AGC等,采集有麦克风阵列等,编解码有VP8、VP9、H.264、H.265等。

典型的实时音视频应用数据流转过程如下

音视频基础知识_第2张图片

更详细图解如下:

音视频基础知识_第3张图片

整个图包含了音视频数据从打包、编解码、传输、推拉流、播放等整个过程,这里边包含了很多音视频基础知识。

一个APP直播功能的架构如下:

音视频基础知识_第4张图片

CDN(内容分发网络)构成

  • 边缘结点:用户会先从边缘结点获取服务;
  • 二级结点(主干结点):主要是用于缓存,减轻源站的压力。如果边缘结点没有服务,会先从主干结点上拉取缓存的数据到边缘结点,然后用户再从边缘结点获取数据;
  • 源站:(会有多个源节点)内容提供商会将内容放在源站上。如果边缘结点和主干结点都没有获取到服务,则会访问源站。

音频三要素

  • 音调(音频)
  • 音量
  • 音色(跟材质有关)

声道数:是指支持能不同发声(注意是不同声音)的音响的个数。

单声道:1个声道
双声道:2个声道
立体声道:默认为2个声道
立体声道(4声道):4个声道

软解码:就是指利用CPU的计算能力来解码,通常如果CPU的能力不是很强的时候,一则解码速度会比较慢,二则手机可能出现发热现象。但是,由于使用统一的算法,兼容性会很好。

硬解码:指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多,但是由于硬解码由各个厂家实现,质量参差不齐,非常容易出现兼容性问题。

音视频名词解释

  1. 音频采样率:是指录音设备在单位时间内对模拟信号采样的多少,采样频率越高,机械波的波形就越真实越自然
  2. 码率:影响体积,与体积成正比:码率越大,体积越大;码率越小,体积越小。码率就是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps即千位每秒。也就是取样率(并不等同与采样率,采样率的单位是Hz,表示每秒采样的次数),单位时间内取样率越大,精度就越高,处理出来的文件就越接近原始文件,但是文件体积与取样率是成正比的,所以几乎所有的编码格式重视的都是如何用最低的码率达到最少的失真,围绕这个核心衍生出来cbr(固定码率)与vbr(可变码率), “码率”就是失真度,码率越高越清晰,反 之则画面粗糙而多马赛克。
    码率计算公式:码率 = 采样率 * 位深度 * 声道          文件大小 = 码率 * 时长
  3. 帧率(FPS):影响画面流畅度,与画面流畅度成正比:帧率越大,画面越流畅;帧率越小,画面越有跳动感。如果码率为变量,则帧率也会影响体积,帧率越高,每秒钟经过的画面越多,需要的码率也越高,体积也越大。

    几种帧:

    I帧:又叫关键帧,也就是一组帧中的第一帧;
    P帧:向前参考帧,也就是说,他只参考它的前一帧,存的是和前一帧不同的地方,属于帧间压缩;
    B帧:双向参考帧,它会参考它的前一帧和它的后一帧,存的是前后帧都没有的,不适合实时互动场景
    GOP:一组帧,在一组帧的前面会有SPS(Sequence Parameter Set,序列参数集)和PPS(Picture Parameter Set,图像参数集)


    tips:码率影响图像质量,帧率影响视频流畅度
     
  4. 分辨率:影响图像大小,与图像大小成正比:分辨率越高,图像越大;分辨率越低,图像越小。
  5. 清晰度:

    在码率一定的情况下,分辨率与清晰度成反比关系:分辨率越高,图像越不清晰,分辨率越低,图像越清晰。

    在分辨率一定的情况下,码率与清晰度成正比关系,码率越高,图像越清晰;码率越低,图像越不清晰。

    码率不是越大越好

    如果不做码率大小上的限制,那么分辨率越高,画质越细腻;帧率越高,视频也越流畅,但相应的码率也会很大,因为每秒钟需要用更多的数据来承载较高的清晰度和流畅度。

    帧率不要超过24

    如果限定一个码率,比如800kbps,那么帧率越高,编码器就必须加大对单帧画面的压缩比,也就是通过降低画质来承载足够多的帧数。如果视频源来自摄像头,24FPS已经是肉眼极限,所以一般20帧的FPS就已经可以达到很好的用户体验了。有些玩过3D游戏的朋友可能会说,游戏的帧率越高越流畅。这里要注意一定不要混淆场景:游戏追求高帧率的目的是为了尽可能让3D模型渲染出来的运动效果更加接近真实运动轨迹,所以帧率越高越好。但对摄像头而言,它要采集的目标是真实世界的物体,真实世界本来就没有刷新率的说法,所以这个理论不适用。

    分辨率不盲目攀高

    如果限定一个码率,比如800kbps,那么分辨率越高就会让编码器越“为难" ,可以想象,它必须拆东墙补西墙,通过减少色彩信息或者引入马赛克这种“鱼目混珠”的手段来承载足够多的像素点。所以,同样的是2G的一个电影文件,1080p画质的版本可能不如720p画质的版本看起来更清晰。

视频花屏和卡顿的原因:

            花屏主要是有帧的丢失:比如P帧或者是I帧丢失了;
            卡顿主要是为因为为了解决避免花屏的情况,就把丢失的那一组帧全部扔掉,然后就会卡屏了;

色彩空间:

  • RGB:RGB的颜色模式应该是我们最熟悉的一种,在现在的电子设备中应用广泛。通过R G B三种基础色,可以混合出所有的颜色;
  • YUV:这里着重讲一下YUV,这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。

早期的电视都是黑白的,即只有亮度值,即Y。有了彩色电视以后,加入了UV两种色度,形成现在的YUV,也叫YCbCr。

  • 1)Y:亮度,就是灰度值。除了表示亮度信号外,还含有较多的绿色通道量;
  • 2)U:蓝色通道与亮度的差值;
  • 3)V:红色通道与亮度的差值。

采用YUV的优势:

人眼对亮度敏感,对色度不敏感,因此减少部分UV的数据量,人眼却无法感知出来,这样可以通过压缩UV的分辨率,在不影响观感的前提下,减小视频的体积。

编码器分类:

名字 特点
x264/x265 x264的性能更好,x265的压缩比高,但是CPU占用也高,不适合直播
openH264 是使用的svc,比如说把一帧分成3层(小中大),当网络较差的时候,只发送内核层,较好的时候,多发送异常,这样以此类推,多一层,画质就会更清晰一些
vp8/vp9 是goole推出的,vp8是基于x264,vp9是基于x265的

直播、互动直播、实时音视频、旁路直播有什么区别?

直播:(一对多,RTMP/HLS/HTTP-FLV,CDN)直播是一种非常典型的流媒体系统,通常会分为推流端(Pusher)、拉流端(或者叫播放端,Player)以及直播流媒体中心(直播源站),通常会使用CDN进行直播的分发,因此大部分情况下使用的是通用标准的协议,如RTMP,而经过CDN分发后,播放时一般可以选择RTMP、HTTP-FLV或HLS(H5支持)等方式。直播的特点是只有一个推流端,以及多个的观看端。

实时音视频:(双人/多人通话,UDP私有协议,低延时)实时音视频(Real-Time Communication, RTC)主要应用场景是音视频通话,技术关注点是低延时通信,因而使用基于UDP的私有协议,其延迟可低于100ms,适用于双人通话或是多人群组群话,除了iOS/Android/Windows/mac之后,还支持小程序以及 WebRTC 互通,并且支持通过云端混流的方式将画面旁路直播出去。当业务对延迟敏感,通话场景要求比较高,或是需要小程序或者 H5 场景下的双人或多人音视频通话可以选择实时音视频 TRTC。

互动直播:(连麦,二对多/多对多,私有协议+标准协议,DC/OC+CDN)互动直播是在实时音视频的基础上,将实时音视频某个房间中的画面经云端混流后,通过旁路直播的方式直播出来。因此,互动直播主播与连麦者之间延迟与实时音视频一致,而主播/连麦者与普通观众之间的延时则与普通直播相同。

旁路直播(关键词:云端混流,转推,CDN)将主/副播实时音视频通话时的整个房间的画面复制一份到云端进行云端混流,并将混流后的画面推流给直播系统的工作方式。 因为混流后的视频数据流和主/副播通话房间实际上并不是同一路流,而是在另外平行的一路,因而称为旁路,即不在主路。云端录制时,录制的流也是通过旁路的方式从流媒体中心引出,存到COS(云对象存储服务)中。

你可能感兴趣的:(音视频)