音视频基础

TV标准

模拟电视有NTSC、PAL和SECAM三种标准

数字电视有三种标准：

• 欧洲的DTV（Digital Video Broadcasting 数字视频广播)
• 美国的ATSC（Advanced Television System Committee先进电视制式委员会）
• 日本的ISDB（(Integrated Services Digital Broadcasting 综合业务数字广播）

DVB（digital video broadcast）数字视频广播

#由“DVB Project”维护的一系列为国际所承认的数字电视公开标准
#数字电视广播标准(ATSC:北美ISDB-T:南美DTMB:我国DVB-T:其他地区)

reference:

DVB-C\DVB-S\DVB-T知识介绍

1. DVB框架结构

   • 音频编码层：使用MPEG1、2等多项标准对模拟音视频信号进行采样和压缩。
   • 服务信息层：使用DVB SI标准产生PSI、SI和EPG等信息服务。
   • 基带传输层：使用ASI（异步串行）、SPI（同步并行）、SSI（同步串行）接口。
   • 信道编码层：使用各种DVB-S、DVB-C、DVB-T信道编码。
   • 射频层： 使用卫星、CATV（有线电视网）、SFN（单频网）、Internet等进行信号传送。
     1.1 发送端模型：编码、复用、调制、发送
     输入音视频信号—encoder----es流 //编码
     es流—packetliser----pes流 //打包
     pes流----multiplexer----ts流 //复用
     ts流----modulation----射频信号 //调制（QPSK,COFDM,QAM）
     射频信号-----DVB-S/T/C
     1.2 接收端模型：相反过程。
     输入：射频信号。
     输出：图形/声音

2. DVB系统组成
   #按照信号传播顺序分为

   • 前端系统（节目生产部门-电视台，广播站）
     #根据作用和功能不同分为
     转播数字前端
     存储数字前端
   • 传输系统（信道）
     DVB-C cable，数字有线电视系统
     DVB-S satellite，数字卫星电视系统
     DVB-T terrestrial，数字地面电视广播系统
   • 终端系统（用户设备-机顶盒）

3. 数字电视

4. 模拟电视

5. 音视频基础
   5.0 基本构成
   内容 编码格式
   图像–编码-----H.264-------
   ----添加元信息---------MP4，Ts。。。
   音频–编码-----AAC---------
   5.1 音视频封装格式（AVI,MP4,TS,FLV,MKV,RMVB）
   #将视频码流和音频码流按照一定的格式编码存储在一个文件中。
   #封装格式分析tools：elecard format analyzer
   AVI 微软 Bt下载
   MP4 MPEG 互联网视频
   TS MPEG IPTV，数字电视
   FLV adobe 互联网视频
   MKV corecodec 互联网视频
   RMVB real networks Bt下载影视
   5.2 视频编码格式—视频码流格式（HEVC,H264,MPEG4,MPEG2,VP9,VP8,VC-1）
   #将像素数据（RGB,YUV）压缩成码流，降低数据量
   5.3 音频编码格式—音频码流格式（AAC,AC-3,MP3,WMA）
   #将音频采样数据（PCM）压缩成音频码流，降低数据量

   5.4 音视频播放流程
   - 解协议（http,rtsp,rtmp,mms）
   #将流媒体协议的数据，解析为标准的相应的音视频封装格式数据。
   #视音频在网络上传播的时候，常常采用各种流媒体协议，例如HTTP，RTMP，或是MMS等等。
   #流媒体协议在传输视音频数据的同时，也会传输一些信令数据。
   #这些信令数据包括对播放的控制（播放，暂停，停止），或者对网络状态的描述等。
   #解协议的过程中会去除掉信令数据而只保留视音频数据。
   #例如，采用RTMP协议传输的数据，经过解协议操作后，输出FLV格式的数据。
   - 解封装
   #将打包起来的音视频数据分离，分离成为音频编码数据和视频编码数据
   - 解码

​ -音视频同步

### 链接：

https://www.cnblogs.com/lifan3a/articles/6000661.html

国际上音视频编解码标准主要两大系列：

• ISO/IEC JTC1制定的MPEG系列标准；
  MPEG1、MPEG2、MPEG4

• ITU[国际电联]针对多媒体通信制定的H.26x系列视频编码标准和G.7系列音频编码标准。
  H.261、H.263、H.264、H.265

MPEG4==H.264。由两个组织共同完成

H.264

别名：AVC，MPEG-4

H.265

别名：HEVC

High Efficiency Video Coding高效率视频编码，优势在于，在不降低画质的情况下视频体积相比H.264降低一半

av时间戳同步：

1. 生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）
2. 在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。

多媒体引擎

高性能移动端多媒体引擎架构

简单来说，多媒体引擎主要负责视频的采集和后期处理，其功能分为拍摄和编辑。拍摄包括滤镜、美颜、美妆、AI特效等功能，编辑包括了剪辑、转场和贴纸等功能。

Media

reference:

android音视频播放器

Android在实现mediaplayer过程中是分为两个进程来实现的，一个是java进程（app–>jni–>framework）：具体就是从一个实际的媒体播放器应用，调用jni，jni调用framework层。这一部分属于java使用so文件实现的一个java进程。另一个是native进程（framework–>native）：mediaplayerservice的实现就是属于这一部分。这一部分属于c++依赖linux实现的本地进程。这两个不同的进程通过binder机制实现从mediaplayer进程调用mediaplayerservice进程，进而间接操纵mediaplayerservice中本地播放器nuplayer或awesomeplayer进行实际工作。

Audio

1. Android音频框架

https://blog.csdn.net/dahailinan/article/details/24294655

---

audio framework层：

相信大家可以马上想到MediaPlayer和MediaRecorder，因为这是我们在开发音频相关产品时使用最广泛的两个类。实际上，Android也提供了另两个相似功能的类，即AudioTrack和AudioRecorder，MediaPlayerService内部的实现就是通过它们来完成的,只不过MediaPlayer/MediaRecorder提供了更强大的控制功能，相比前者也更易于使用。我们后面还会有详细介绍。除此以外，Android系统还为我们控制音频系统提供了AudioManager、AudioService及AudioSystem类。这些都是framework为便利上层应用开发所设计的

• AudioTrack

  播放声音可以使用 MediaPlayer 和 AudioTrack，两者都提供 Java API 给应用开发者使用。两者的差别在于：MediaPlayer 可以播放多种格式的音源，如 mp3、flac、wma、ogg、wav 等，而 AudioTrack 只能播放解码后的 PCM 数据流。从上面 Android 音频系统架构图来看：MediaPlayer 在 Native 层会创建对应的音频解码器和一个 AudioTrack，解码后的数据交由 AudioTrack 输出。所以 MediaPlayer 的应用场景更广，一般情况下使用它也更方便；只有一些对声音时延要求非常苛刻的应用场景才需要用到 AudioTrack。

audio libraries层：

我们知道，framework层的很多类，实际上只是应用程序使用Android库文件的“中介”而已。因为上层应用采用java语言编写，它们需要最直接的java接口的支持，这就是framework层存在的意义之一。而作为“中介”，它们并不会真正去实现具体的功能，或者只实现其中的一部分功能，而把主要重心放在库中来完成。比如上面的AudioTrack、AudioRecorder、MediaPlayer和MediaRecorder等等在库中都能找到相对应的类。

这一部分代码集中放置在工程的frameworks/av/media/libmedia中，多数是C++语言编写的。

除了上面的类库实现外，音频系统还需要一个“核心中控”，或者用Android中通用的实现来讲，需要一个系统服务(比如ServiceManager、LocationManagerService、ActivityManagerService等等)，这就是AudioFlinger和AudioPolicyService。它们的代码放置在frameworks/av/services/audioflinger，生成的最主要的库叫做libaudioflinger。

音频体系中另一个重要的系统服务是MediaPlayerService，它的位置在frameworks/av/media/libmediaplayerservice。

因为涉及到的库和相关类是非常多的，建议大家在理解的时候分为两条线索。

其一，以库为线索。比如AudioPolicyService和AudioFlinger都是在libaudioflinger库中;而AudioTrack、AudioRecorder等一系列实现则在libmedia库中。

其二，以进程为线索。库并不代表一个进程，进程则依赖于库来运行。虽然有的类是在同一个库中实现的，但并不代表它们会在同一个进程中被调用。比如AudioFlinger和AudioPolicyService都驻留于名为mediaserver的系统进程中;而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder一样实际上只是应用进程的一部分，它们通过binder服务来与其它系统进程通信。

在分析源码的过程中，一定要紧抓这两条线索，才不至于觉得混乱。

AudioFlinger服务常用接口：

Filter	Interface	Description
硬件设备配置信息	sampleRate	获取硬件设备的采样率
	format	获取硬件设备的音频格式
	frameCount	获取硬件设备的周期帧数
	latency	获取硬件设备的传输延迟
音量调节	setMasterVolume	调节主输出设备的音量
静音操作	setMasterMute	静音主输出设备
	setStreamVolume	调节指定类型的音频流的音量，这种调节不影响其他类型的音频流的音量
	setStreamMute	静音指定类型的音频流
	setVoiceVolume	调节通话音量
	setMicMute	静音麦克风输入
音频模式切换	setMode	切换音频模式：音频模式有 4 种，分别是 Normal、Ringtone、Call、Communicatoin
音频参数设置	setParameters	设置音频参数：往下调用 HAL 层相应接口，常用于切换音频通道
	getParameters	获取音频参数：往下调用 HAL 层相应接口
输入输出流设备管理	openOutput	打开输出流：打开输出流设备，并创建 PlaybackThread 对象
	closeOutput	关闭输出流：移除并销毁 PlaybackThread 上面挂着的所有的 Track，退出 PlaybackThread，关闭输出流设备
	openInput	打开输入流：打开输入流设备，并创建 RecordThread 对象
	closeInput	关闭输入流：退出 RecordThread，关闭输入流设备
音频流管理	createTrack	新建输出流管理对象： 找到对应的 PlaybackThread，创建输出流管理对象 Track，然后创建并返回该 Track 的代理对象 TrackHandle
	openRecord	新建输入流管理对象：找到 RecordThread，创建输入流管理对象 RecordTrack，然后创建并返回该 RecordTrack 的代理对象 RecordHandle

audio hal层

https://blog.csdn.net/zjli321/article/details/52424401

从上图可以看出，HAL层下面使用TiniAlsa（Android下一个简约的Alsa版本）。audio的HAL层分为两部分，一部分为各种音频设备（a2dp,usb,promary），每种音频设备由一个独立的库文件实现：如audio.a2dp.default.so（管理蓝牙a2dp音频），audio.usb.default.so（管理usb外接的音频），audio.primary.default.so（管理设备上的大部分音频）。另一部分为厂家自己实现的音频策略，Android下提供了默认一套音频策略，当厂家有特殊的音频策略时，可以在这部分修改实现。

HAL层上面就是音频系统的核心AudioFlinger，这里实现了各种输入、输出音频流的管理，管理实时可用的音频通道，为各种音频流选择音频通道，实现多个音频流的混音等。

这里只介绍HAL中各种音频设备（a2dp,usb,promary）的管理，如何确定各种音频设备支持哪些输入、输出音频等，对音频策略不做讲解。AudioFlinger在加载音频设备库文件时，从/system/lib/hw/下查找以audio开头的库，同时根据audio_policy.conf中定义的音频设备名（如a2dp、usb、primary）作为库的第二部分名称，对于没有特别指定的，库的第三部分名称就是default，所以加载音频设备库的名称就可以确定了，如：audio.a2dp.default.so。每个音频库的实现接口都是一样的，这样就可以让AudioFlinger使用相同的接口调用不同音频设备。

【https://www.cnblogs.com/hellokitty2/p/10943199.html】

从设计上来看，硬件抽象层是AudioFlinger直接访问的对象。这说明了两个问题，一方面AudioFlinger并不直接调用底层的驱动程序;另一方面，AudioFlinger上层(包括和它同一层的MediaPlayerService)的模块只需要与它进行交互就可以实现音频相关的功能了。因而我们可以认为AudioFlinger是Android音频系统中真正的“隔离板”，无论下面如何变化，上层的实现都可以保持兼容。

音频方面的硬件抽象层主要分为两部分，即AudioFlinger和AudioPolicyService。实际上后者并不是一个真实的设备，只是采用虚拟设备的方式来让厂商可以方便地定制出自己的策略。

抽象层的任务是将AudioFlinger/AudioPolicyService真正地与硬件设备关联起来，但又必须提供灵活的结构来应对变化——特别是对于Android这个更新相当频繁的系统。比如以前Android系统中的Audio系统依赖于ALSA-lib，但后期就变为了tinyalsa，这样的转变不应该对上层造成破坏。因而Audio HAL提供了统一的接口来定义它与AudioFlinger/AudioPolicyService之间的通信方式，这就是audio_hw_device、audio_stream_in及audio_stream_out等等存在的目的，这些Struct数据类型内部大多只是函数指针的定义，是一些“壳”。当AudioFlinger/AudioPolicyService初始化时，它们会去寻找系统中最匹配的实现(这些实现驻留在以audio.primary.*,audio.a2dp.*为名的各种库中)来填充这些“壳”。

根据产品的不同，音频设备存在很大差异，在Android的音频架构中，这些问题都是由HAL层的audio.primary等等库来解决的，而不需要大规模地修改上层实现。换句话说，厂商在定制时的重点就是如何提供这部分库的高效实现了。

audio hal层是AudioFlinger直接访问的对象，AudioFlinger的使用者（native层的AudioTrack，AudioRecorder，MediaplayerService）通过AudioFlinger来间接操作音频，而AudioFlinger存在的目的就是为各种音频流选择正确的音频通道。而audio的hal层为了让AudioFlinger使用统一的接口来调用不同的音频设备实现，就在该层抽象出audio_hw_device,audio_stream_in,audio_stream_out让AudioFlinger来调用，而这几个结构内部大多只是函数指针，不同的音频输出设备（usb，a2dp）会填充不同的指针。

---

audio_hw_hal.cpp：向上AudioFlinger提供接口的函数
audioHardwareInterface.cpp：向厂商制定访问硬件接口的函数
audioHardware.cpp：厂商实现的访问声卡硬件的文件

蓝牙

 HSP（手机规格，Head-Set-Profile）
 HFP（免提规格，Hands-Free-Profile）
 A2DP（高质量音频数据传输协议， Advanced Audio Distribution Profile）
 AVRCP（音频/视频遥控规格，Audio/Video Remote Control Profile）

蓝牙音频编码 - SBC、AAC、AptX、LDAC、LHDC

A2DP蓝牙协议规定，实现该协议的必须支持SBC编码

-Profile）
HFP（免提规格，Hands-Free-Profile）
A2DP（高质量音频数据传输协议， Advanced Audio Distribution Profile）
AVRCP（音频/视频遥控规格，Audio/Video Remote Control Profile）

[外链图片转存中...(img-9zmvtHlV-1617162062217)]

**蓝牙音频编码 - SBC、AAC、AptX、LDAC、LHDC**

A2DP蓝牙协议规定，实现该协议的必须支持SBC编码