音视频基础

简介: 音视频基础

1.1音视频录制原理

麦克风->采样帧->音频处理->采样帧队列->音频编码->音频包队列->

    时钟                        复用器(音视频封装)->文件

摄像头->图像帧->图像处理->图像帧队列->视频编码->视频包队列->

1.2音视频播放原理

                 ->音频包队列->音频解码->采样帧队列—>音频处理->扬声器

媒体文件->解复用器(音视频解封装)                同步控制

                 ->视频包队列-> 视频解码->图像帧队列—>图像处理->显示器

1.3图像表示RGB-YUVV

(1)图像基础概念

 ◼ 像素:像素是一个图片的基本单位,pix是英语单词picture的简写,加上英

语单词“元素element”,就得到了“pixel”,简称px,所以“像素”有“图像元素”

之意。

 ◼ 分辨率:是指图像的大小或尺寸。比如1920x1080。

 ◼ 位深:是指在记录数字图像的颜色时,计算机实际上是用每个像素需要的

位深来表示的。比如红色分量用8bit。

 ◼ 帧率:在1秒钟时间里传输的图片的帧数,也可以理解为图形处理器每秒钟

能够刷新几次。比如25fps表示一秒有25张图片。

 ◼ 码率:视频文件在单位时间内使用的数据流量。比如1Mbps。

 ◼ Stride:指在内存中每行像素所占的空间。为了实现内存对齐每行像素在内存中所占的空间并不一定是图像的宽度。

(2)RGB、YUV深入理解

 ◼ RGB:红R、绿G、蓝B三基色。

     通常的图像像素是按RGB顺序进行排列,但有些图像处理要转成其他顺序,比如OpenCV经常转成BGR的排列方式。

 ◼ YUV:“Y”表示明亮度(Luminance或Luma),也就是灰阶值,“U”和“V”表示的则是色度(Chrominance或Chroma)。

     a.解决了彩色电视与黑白电视的兼容问题;还可以降低色度的采样率而不会对图像质量影响太大,降低了视屏信号传输时对频宽(带宽)的要求。

     b.排列方式

     (i)打包(packed)格式:将每个像素点的Y、U、V分量交叉排列并以像素点为单元连续的存放

     (ii)在同一数组中,通常几个相邻的像素组成一个宏像素(macro-pixel)平面(planar)格式:使用三个数组分开连续的存放Y、U、V三个分量,即Y、U、V分别存放在各自的数组中。

     (iii)采样表示法:YUV采用A:B:C表示法来描述Y,U,V采样频率比例,下图中黑点表示采样像素点Y分量,空心圆表示采样像素点的UV分量。主要分为 YUV 4:4:4、YUV 4:2:2、YUV 4:2:0 这几种常用的类型

      - 4:4:4 表示色度频道没有下采样,即一个Y分量对应着一个U分量和一个V分量。

      - 4:2:2 表示 2:1 的水平下采样,没有垂直下采样,即每两个Y分量共用一个U分量和一个V分量。

      - 4:2:0 表示 2:1 的水平下采样,2:1 的垂直下采样,即每四个Y分量共用一个U分量和一个V分量。

(3) RGB和YUV的转换

      通常情况下RGB和YUV直接的相互转换都是调用接口实现,比如Ffmpeg的swscale或者libyuv等库,主要转换标准是 BT601 和 BT709

      8bit位深的情况下

      - TV range是16-235(Y)、16-240(UV) , 也叫Limited Range

      - PC range是0-255,也叫Full Range

      - 而RGB没有range之分,全是0-255

      从YUV 转到 RGB 如果值小于0要取0,如果大于255要取255

1.4视频主要概念

视频码率:kb/s,是指视频文件在单位时间内使用的数据流量,也叫码流率。码率越大,说明单位时间内取样率越大,数据流精度就越高。


视频帧率:fps,通常说一个视频的25帧,指的就是这个视频帧率,即1秒中会显示25帧。帧率越高,给人的视觉就越流畅。


视频分辨率:分辨率就是我们常说的640x480分辨率、1920x1080分辨率,分辨率影响视频图像的大小。


I 帧(Intra coded frames):I帧不需要参考其他画面而生成,解码时仅靠自己就重构完整图像;

                                             I帧图像采用帧内编码方式;

                                             I帧所占数据的信息量比较大;

                                             I帧图像是周期性出现在图像序列中的,出现频率可由编码器选择;

                                             I帧是P帧和B帧的参考帧(其质量直接影响到同组中以后各帧的质量);

                                             I帧是帧组GOP的基础帧(第一帧),在一组中只有一个I帧;

                                             I帧不需要考虑运动矢量;


P 帧(Predicted frames):根据本帧与相邻的前一帧(I帧或P帧)的不同点来压缩本帧数据,同时利用了空间和时间上的相关性。

P帧属于前向预测的帧间编码。它需要参考前面最靠近它的I帧或P帧来解码。


B 帧(Bi-directional predicted frames):B 帧图像采用双向时间预测,可以大大提高压缩倍数。


1.5物理音频和数字音频

声音的物理性质:振动、波形、频率、振幅


数字音频:计算机并不直接使用连续平滑的波形来表示声音,它是每隔固定的时间对波形的幅值进行采样,用得到的一系列数字量来表示声音。

数字音频-采样频率:根据Nyguist采样定律,要从采样中完全恢复原始信号波形,采样频率必须至少是信号中最高频率的两倍。人耳能听到的频率范围是[20H~20kHz],所以采样频率一般为44.1Khz,这样就能保证声音到达20Khz也能被数字化,从而使得经过数字化处理之后,人耳听到的声音质量不会被降低。

数字音频-采样量化:采样是在离散的时间点上进行的,而采样值本身在计算机中也是离散的。采样值的精度取决于它用多少位来表示,这就是量化。例如8位量化可以表示256个不同值,而CD质量的16位量化可以表示65 536个值,范围为[-32768, 32767]。

1.6音频编码原理简介

数字音频信号如果不加压缩地直接进行传送,将会占用极大的带宽。例如,一套双声道数字音频若取样频率为44.1KHz,每样值按16bit量化,则其码率为:

244.1kHz16bit=1.411Mbit/s

数字音频压缩编码在保证信号在听觉方面不产生失真的前提下,对音频数据信号进行尽可能大的压缩,降低数据量。数字音频压缩编码采取去除声音信号中冗余成分的方法来实现。所谓冗余成分指的是音频中不能被人耳感知到的信号,它们对确定声音的音色,音调等信息没有任何的帮助。


冗余信号包含人耳听觉范围外的音频信号以及被掩蔽掉的音频信号等。例如,人耳所能察觉的声音信号的频率范围为20Hz~20KHz,除此之外的其它频率人耳无法察觉,都可视为冗余信号。


此外,根据人耳听觉的生理和心理声学现象,当一个强音信号与一个弱音信号同时存在时,弱音信号将被强音信号所掩蔽而听不见,这样弱音信号就可以视为冗余信号而不用传送。这就是人耳听觉的掩蔽效应,主要表现在频谱掩蔽效应和时域掩蔽效应。


一个频率的声音能量小于某个阈值之后,人耳就会听不到。当有另外能量较大的声音出现的时候,该声音频率附近的阈值会提高很多,即所谓的掩蔽效应。


当强音信号和弱音信号同时出现时,还存在时域掩蔽效应。即两者发生时间很接近的时候,也会发生掩蔽效应。时域掩蔽过程曲线如图所示,分为前掩蔽、同时掩蔽和后掩蔽三部分。时域掩蔽效应可以分成三种:前掩蔽,同时掩蔽,后掩蔽。前掩蔽是指人耳在听到强信号之前的短暂时间内,已经存在的弱信号会被掩蔽而听不到。同时掩蔽是指当强信号与弱信号同时存在时,弱信号会被强信号所掩蔽而听不到。后掩蔽是指当强信号消失后,需经过较长的一段时间才能重新听见弱信号,称为后掩蔽。这些被掩蔽的弱信号即可视为冗余信号。


对每一个音频声道中的音频采样信号:

将它们映射到频域中,这种时域到频域的映射可通过子带滤波器实现。每个声道中的音频采样块首先要根据心理声学模型来计算掩蔽门限值;

由计算出的掩蔽门限值决定从公共比特池中分配给该声道的不同频率域中多少比特数,接着进行量化以及编码工作;将控制参数及辅助数据加入数据之中,产生编码后的数据流。


推荐一个零声学院项目课,个人觉得老师讲得不错,分享给大家:

零声白金学习卡(含基础架构/高性能存储/golang云原生/音视频/Linux内核)

https://xxetb.xet.tech/s/VsFMs


相关文章
|
1月前
|
编解码 移动开发 安全
FFmpeg开发笔记(五十)聊聊几种流媒体传输技术的前世今生
自互联网普及以来,流媒体技术特别是视频直播技术不断进步,出现了多种传输协议。早期的MMS由微软主导,但随WMV格式衰落而减少使用。RTSP由网景和RealNetworks联合提出,支持多种格式,但在某些现代应用中不再受支持。RTMP由Adobe开发,曾广泛用于网络直播,但因HTML5不支持Flash而受影响。HLS由苹果开发,基于HTTP,适用于点播。SRT和RIST均为较新协议,强调安全与可靠性,尤其SRT在电视直播中应用增多。尽管RTMP仍占一定市场,但SRT等新协议正逐渐兴起。
81 8
FFmpeg开发笔记(五十)聊聊几种流媒体传输技术的前世今生
|
1月前
|
编解码 监控 网络协议
如何用魔法般的步骤实现RTSP推送H.264与H.265(HEVC),打造震撼视听盛宴,让每一帧都充满魔力!
【9月更文挑战第3天】实现RTSP流媒体服务推送H.264和H.265编码视频是现代视频监控及直播平台的关键技术。本文详细介绍环境搭建、编码配置及服务器与客户端实现方法。首先,通过FFmpeg捕获视频并编码成RTSP流,接着使用VLC等工具接收播放。此外,还提供了C++示例代码,演示如何利用libv4l2和FFmpeg自定义服务器端实现。希望本文能帮助读者成功搭建RTSP视频流系统。
79 1
|
2月前
|
编解码 监控 网络协议
【绝密技巧】揭秘!如何用魔法般的步骤实现RTSP推送H.264与H.265(HEVC),打造震撼视听盛宴,让每一帧都充满魔力!
【8月更文挑战第15天】本文详述了如何使用RTSP流媒体服务推送H.264及H.265编码视频,适用于视频监控和直播平台。首先需确保环境支持这两种编码格式,可通过FFmpeg实现。在Ubuntu上安装FFmpeg后,可配置从摄像头捕获视频并推流至RTSP服务器。针对H.265编码,只需更改视频编码器为`libx265`。客户端可使用VLC播放器接收流。此外,还提供了C++示例代码用于自定义服务器实现,包括初始化上下文、打开编码器和循环编码视频帧。此教程旨在助力实现RTSP推送目标。
35 0
|
2月前
|
Web App开发 网络协议 Android开发
### 惊天对决!Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【8月更文挑战第14天】随着移动互联网的发展,实时音视频通信已成为移动应用的关键部分。本文对比分析了Android平台上WebRTC、RTMP与RTSP三种主流技术方案。WebRTC提供端到端加密与直接数据传输,适于高质量低延迟通信;RTMP适用于直播场景,但需服务器中转;RTSP支持实时流播放,但在复杂网络下稳定性不及WebRTC。三种方案各有优劣,WebRTC功能强大但集成复杂,RTMP和RTSP实现较简单但需额外编码支持。本文还提供了示例代码以帮助开发者更好地理解和应用这些技术。
128 0
|
5月前
|
编解码 vr&ar 计算机视觉
音视频基础
音视频基础
|
5月前
|
编解码 算法 容器
音视频基础知识
音视频基础知识
77 0
|
5月前
|
存储 编解码 算法
ffmpeg笔记(一)音视频基础
ffmpeg笔记(一)音视频基础
148 0
|
Web App开发 网络虚拟化
使用 WebRTC 构建简单的视频聊天室(1)
使用 WebRTC 构建简单的视频聊天室(1)
417 0
|
开发框架 开发工具
使用融云SDK在APICloud 平台实现单人多人音频通话
使用融云SDK在APICloud 平台实现单人多人音频通话,使用之前必须先获取 token、init、connect,同时需要到融云后台开通音视频通话功能(开通或者关闭 30 分钟后生效)。单人通话逻辑比较简单,主要会用到 didReceiveCall、didConnect、didDisconnect 等三个事件。
225 0
|
开发工具
使用融云SDK在APICloud平台实现单人多人音频通话
使用之前必须先获取token、init、connect,同时需要到融云后台开通音视频通话功能(开通或者关闭30分钟后生效)。单人通话逻辑比较简单,主要会用到didReceiveCall、didConnect、didDisconnect等三个事件。多人通话逻辑复杂一点,并且只能应用在群组或者讨论组,会用到didReceiveCall、didConnect、remoteUserDidJoin、remoteUserDidLeft、remoteUserDidInvite、didDisconnect等六个事件。
176 0
使用融云SDK在APICloud平台实现单人多人音频通话