1、音视频基础
一个简单的音视频链路如下：
1）采集，音视频经过采集后分别生成音频流和视频帧，音频是流式的物理上没有帧的概念，但为了数据处理的方便实际数据处理中引入了音频帧的概念，一般中间插入静音数据。 视频是由一幅幅图像组成，可以理解为一幅图就是一帧。
2）采样/量化，声音本质上是振动产生的声波，然后通过媒介传输到达耳朵。
声音三要素：
a、响度：波的振幅体现为响度；
b、音调：波的频率体现音调，人耳能听到的声音频率范围：20Hz - 2万Hz
c、音色：波的形状体现音色；
声音强度定义为声压，用分贝为单位描述。
自然界中的声音是一个模拟信号，需要采样和量化后转化为数字信号才能被计算机处理。
3）编码：简单理解为将原始的音视频数据压缩处理并增加媒体数据描述。视频的压缩可以大量减少数据大小， 视频的原始数据 = 1像素所占大小 x 每张图像的像素数量 x 帧数。视频原始帧一般为YUV格式，见01 YUV 颜色编码 详解 。
4）封装：简单理解为将音视频合并在一起，MP4格式是一种封装格式，H264是一种视频编解码规范。
5）传输：通过网络讲媒体数据量传递到远端，涉及的协议也比较多比如HTTP、RTMP、HLS等
实际音视频的业务场景远比上面一条播放链路复杂，拿媒体播放场景来说，需要处理各种传输协议、媒体格式、封装格式、异常处理，播放状态时序管理，多端状态同步和控制，音频焦点管理等，这些都会增加复杂度。
一般的开发模式都是基于或大量借鉴开源实现，比较重要的有FFMPEG实现了大部分的音视频编解码协议， WEBRTC实现了音视频编解码处理和远程视频流以及网络管理。
2、Media3
2.1、官方简介
引用Google官网描述：
“Jetpack Media3 is the new home for media libraries that enables Android apps to display rich audio and visual experiences. Media3 offers a simple architecture with powerful customization, reliability, and optimizations based on device capabilities to abstract away the complexity that comes with fragmentation.”
可以简单解读下：
1、是Jetpack的一部分，是一个新的媒体库，以可以提供更丰富的音视频体验；
2、更简单的架构，更好的定制化、可靠性、优化能力，降低了碎片化带来的复杂度；
官方链接：https://developer.android.google.cn/guide/topics/media/media3?hl=zh-cn
2.2、MediaSession
媒体会话提供了一种多端媒体播放状态同步和控制的能力。可以通过通知、控制中心媒体面板、Google语音助手、遥控器方式控制媒体播放状态。
这样看来，和自研的媒体中心功能比较类似，媒体中心多了状态保持，歌词同步等功能。原始Mediasession支持定制的命令通道可以实现类似扩展功能。
2.3、媒体架构
1）针对视频应用，因为视频在前台才能播放，官方的建议是在单个activity中播放：
2）针对音频应用，官方的建议是在后台服务中播放：
2.4、媒体组件
Media3开始，ExoPlayer仓库合并到media中，Exoplayer独立的仓库后续不再更新和发布，ExoPlayer是Media3其中的一个组件。
大概可以作如下分类：
1、ExoPlayer组件
播放器核心组件，负责媒体数据的获取、处理和渲染，也包括了一些流媒体协议：
"androidx.media3:media3-exoplayer"
"androidx.media3:media3-exoplayer-dash"
"androidx.media3:media3-exoplayer-rtsp"
"androidx.media3:media3-exoplayer-ima"
"androidx.media3:media3-exoplayer-midi"
"androidx.media3:media3-exoplayer-workmanager"
"androidx.media3:media3-exoplayer-smoothstreaming"
DASH（MPEG-DASH）：是 Dynamic Adaptive Streaming over HTTP的缩写，基于HTTP的动态自适应的比特率流技术；
RTSP(Real-Time Stream Protocol)： RTSP在体系结构上位于RTP和RTCP之上, 它使用TCP或RTP完成数据传输；
IMA(互动式媒体广告 )：连接广告服务器和进行数据处理；
MIDI（Musical Instrument Digital Interface）：是一个工业标准的电子通信协议，为电子乐器等演奏设备（如合成器）定义各种音符或弹奏码；
Workmanager: 后台的操作支持jetpack的workmanager；
Smoothstreaming：Microsoft Smooth Streaming (MSS) ， 是IIS的媒体服务扩展，用于支持基于HTTP的自适应流。
2、Session组件
"androidx.media3:media3-session"
Media session管理组件。
3、UI组件
"androidx.media3:media3-ui"
媒体播放UI组件，包括视频的surfaceview和播控UI。PlayerView类持有Player接口完成播放。
4、Datasource组件
"androidx.media3:media3-datasource"
"androidx.media3:media3-datasource-cronet"
"androidx.media3:media3-datasource-okhttp"
"androidx.media3:media3-datasource-rtmp"
Exoplayer需要指定datasource来进行数据解析。
Cronet：基于Chromium网络引擎的网络库；
OkHttp：大家所熟知的；
RTMP：（Real-Time Messaging Protocol，实时消息传输协议）是一种用于低延迟、实时音视频和数据传输的双向互联网通信协议。
5、媒体编辑相关的组件
"androidx.media3:media3-transformer"
"androidx.media3:media3-extractor"
"androidx.media3:media3-effect"
提供媒体格式转换、内容提取、渲染效果编辑接口。
6、cast组件
"androidx.media3:media3-cast"
Google投屏相关的组件。
3、Media各个版本对比
3.1、System media session service
SystemServer中实现了一个MediaSessionService，和Media3的sessionservice类名一样。
系统中的媒体播放会连接此服务向外暴露媒体会话。
public class MediaSessionService extends SystemService
Client可以通过
(MediaSessionManager) context.getSystemService(Context.MEDIA_SESSION_SERVICE)
获取会话管理接口。
这些会话会暴露给SystemUI在媒体面板上显示。
3.2、V4 Media
v4 support包中的媒体组件，包路径为android.support.v4.media。
MediaBrowserCompat支持浏览媒体，通过MediaSessionCompat管理会话，需要应用实现MediaBrowserServiceCompat服务，action为android.media.browse.MediaBrowserService。
除了媒体共享之外没有提供其他能力，早期的版本了解即可，最新的Media3兼容此方案。
3.3、Media2
media2和exoplayer是独立，两个仓库迭代开发和发布。
问题：
1）两者有较多的重复的模块，如下图所示：
2）播放器和会话之间的接口不一样，需要进行连接转换，超过50%的top应用因此产生一些问题。
3.4、Media3
1）将media2和exoplayer整合了，公共的模块合并：
2）client和server端都实现相同的接口Player，mediacontroller和exoplayer都实现了Player接口：
3）将MediaBrowserService拆分，MediaSessionService负责播放中会话管理，MediaLibraryService负责播放文件树暴露：
4）增加了一些媒体编辑的组件，前面已有介绍的。
4、统一播放器方案设计
自研的各个音乐和视频播放器都各自实现，没有统一的方案，使用的player类型和版本不一致，版本比较老旧。比如本地多媒体项目中USB播放器使用的Media3 ExoPlayer + Media session， Media session是拷贝源码方式集成，作了部分自定义修改；杜比音乐项目中有使用旧的Exoplayer2;
播放器方案见：通用MediaPlayer优化方案V1.0
5、统一播放器接入
见统一媒体播放器接入指南
)
