做有意思的事情

转自：Android智能手机上的音频浅析Android智能手机中各种音频场景下的audio data path1. 硬件下图是Android智能手机中目前主流的跟音频相关的硬件框图。上图中AP是应用处理器（application processor），现在用的最多的是ARM的处理器，在上面主要运行的是操作系统（OS，例如android）和应用程序。CP是通信处理器（communication processor），也叫基带处理器（baseband processor，BP）或者modem，上面

前言通俗点说，NuPlayer是AOSP中提供的多媒体播放框架，能够支持本地文件、HTTP（HLS）、RTSP等协议的播放，通常支持H.264、H.265/HEVC、AAC编码格式，支持MP4、MPEG-TS封装。在实现上NuPlayer基于StagefrightPlayer的基础类构建，利用了更底层的ALooper/AHandler机制来异步地处理请求，ALooper列队消息请求，AHandler中去处理，所以有更少的Mutex/Lock在NuPlayer中。NuPlayer中利用了Acodec。

前言MeidaCodec API: https://developer.android.com/reference/android/media/MediaCodecMediaCodec是一个Codec，通过硬件加速解码和编码。它为芯片厂商和应用开发者搭建了一个统一接口。MediaCodec几乎是所有安卓播放器硬解的标配，要深入分析一个播放器的源码，如NuPlayer, ijkplayer，有必要了解其基础的使用方法。先来看看MediaCodec在NuPlayer中的位置：同样，我们想要深入了解Me

前言这里的代码分析流程就是《15. Android MultiMedia框架完全解析 - Render流程分析》中的代码流程，上次主要关注的是buffer的交互流程，这次主要分析的是音视频同步，即AVsync。1. 音视频同步概念与方法音视频同步是一个播放器要处理的基本问题，音视频同步的好坏直接影响到播放效果。解码后的音频片段和视频片段，都分别带有 pts 时间戳信息。回放时需要做的，就是尽量保证 apts（音频时间戳）和 vpts（视频时间戳），之间的差值是最小的。为了达到这个目的，就需要在 au

前言之前的文章中，已经多次分析过ACodec，但是我仍然认为有必要单独拿出来一节分析其中的一些机制与流程，下面先来看看ACodec在整个NuPlayer架构中的位置：1. ACodec消息机制ACodec有一个BaseState和派生出来的其他State，如 UninitializedState,LoadedToIdleState, ExecutingState等。当有消息过来时，如果派生类有重写的方法，则会调到重写的方法，如果没有，则会调到BaseState的方法。ACodec继承自AHiera

前言上一篇文章中详细分析了MediaCodec，以及由它向下的内容，但是在MediaCodec外面包裹的是一层NuPlayerDecoder，这里就看看它们两者之间是如何沟通的。从理论上来讲，既然NuPlayerDecoder包裹在MediaCodec外层，所以它相对于MediaCodec也可以理解为App，它调用MediaCodec的API来完成一些任务。下面就详细看看这个流程1. 解码顺序的启动过程实际的解码是从setRenderer开始，在NuPlayer::onStart()函数中，mVi

前言之前的文章中，讲了那么多细节的东西，已经对概况没有一个大致的了解，所以这里缕一下整体的流程，同时也分析MediaCodec，ACodec与OMX Plugin之间的状态切换关系。1. 初始化过程（从NuPlayer开始）：1.1 NuPlayer::start()NuPlayer::start()时产生一个kWhatStart，在消息处理函数中如果是暂停后的开始就调用NuPlayer::onResume()【只需mSource->resume()和mRenderer->resu

还是从mediaplayer.cpp开始分析，看start函数的实现：status_t MediaPlayer::start(){ mPlayer->setLooping(mLoop); mPlayer->setVolume(mLeftVolume, mRightVolume); mPlayer->setAuxEffectSendLevel(mSendLevel); mCurrentState = MEDIA_PLAYER_STARTED; ret =

先来看看MediaExtractor所处的位置：1. 创建流程在GenericSource.cpp的NuPlayer::GenericSource::initFromDataSource()函数中调用了：extractor = MediaExtractor::Create(mDataSource, mimeType.isEmpty() ? NULL : mimeType.string());NuPlayer会为每个播放的文件，创建一个MediaExtractor

Android中Native层抽象出来MediaMuxer类和MediaExtractor类，MediaMuxer类主要用于将音频和视频数据进行混合生成多媒体文件（如：mp4文件），而MediaExtractor则刚好相反，主要用于多媒体文件的音视频数据的分离，即解封装（又叫解复用）。而在文件播放中，首先需要做的就是解封装， 所以在播放过程中，NuPlayer使用了这个MediaExtractor类，先来看看MediaExtractor在NuPlayer框架中所处的位置：1. 使用下面给出一个And

还是从mediaplayer.cpp文件开始分析：status_t MediaPlayer::prepareAsync(){ ALOGV("prepareAsync"); Mutex::Autolock _l(mLock); return prepareAsync_l();}基本没做什么，设置了一个自动锁，然后就直接跳到MediaPlayer::prepareAsync_l中去执行了：status_t MediaPlayer::prepareAsync_l(){

前言先解决NuPlayer与NuPlayerDriver的通信过程，在之前的文章中，都说了NuPlayerDriver是NuPlayer的一个Wrapper，上层的指令发送给NuPlayerDriver后，NuPlayer作为NuPlayerDriver的一个成员变量，NuPlayerDriver想调用NuPlayer的话，就相当简单。当NuPlayer完成一个指令后，如何通知NuPlayerDriver呢？下面我们就以setVideoSurfaceTexture为例来讲解一下（虽然这个函数的历程还没有追

前言经过前面的分析，我们大概知道了一些概念，但是这个StageFright在整个playback的位置是什么样的：Android Media这一块的知识杂乱，而且有深度，有广度。深度的话，从app->JNI->C+±>底层的OMX驱动，广度的话，每个播放器在播放的时候，会执行seek操作，快进，快退，暂停等等操作，同时，需要涉及读取源文件（从网络读取，从文件读取），解码（软解，硬解），Render等到一系列的操作，光听我这么说，就感觉很乱。如果一味的追求深度，从app开始追代码的执

在Android中大量使用到了C/S架构来实现应用层和底层服务交互，而Binder机制无处不在。同样MediaPlayer也使用了这种机制，MediaPlayer在运行的时候，同样可以分为Client/Server两个部分，他们分别在不同的进程中运行，不同进程间的通信使用Binder机制，架构图如下：1）如果从功能角度看，最上层是java层MediaPlayer的API， 然后通过JNI层到C++层之间的IPC通信，最下边就是palyer的具体实现了（StageFrightPlayer，NuPlaye

前言在之前文章中说到mediaplayer最终会利用工场模式通过打分选择Nuplayer。这里插讲一下厂商定制Player的过程，可以参考NuPlayer的创建过程，通过这个过程，也能够对MediaPlayerFactory类有个比较深入的理解。定制首先来看这个class MediaPlayerFactory，它定义在MediaPlayerFactory.h文件中，里面包含一个IFactory类和其他的功能函数，如注册工厂类函数：registerFactory等等操作。而这个IFactory类，就是