如果转载,请尊重原创,注明 yuedl1@163.com 谢谢!
mdiaplayer 在android7.0 到android 7.1 ,一直在改变着,这也许就是google的精神吧,一直在迭代。要不我们也就没事情干了。公司最近事情比较少,就对这个mediaserver 学习了下。呵呵。废话少说,今天就来介绍下meidaplayer 在android 7.1 上的实现;
mediaserver 被拆分
这主要是为了安全,每个进程的功能单一化了,每个进程的权限和crash 影响就小了很多;
在setdatasource的时候,mediaplayer和meidaplayerservice 建立了联系,创建了client。 创建了genericsource 。 在prepare 的时候创建了具体的extractor ,并获取到了metadata。 获取到了mediasource 。 在start的时候创建了decoder和render 。 这样就完成了 mediaplayer 播放的整体架构; mediasource,decoder ,和render 。mediabuffer和mediabuffergroup 在这些进程之间数据交换启动很重要的作用。可以具体看下这个东西,目前在android7.1 上有个和它有关的bug。后面我们再说它的使用;
那么就看omx的流程了:
从图中可以看出来,omx 会给codec 发送两个数据处理的事件: empty_buffer_done 和 fill_buffer_done 。而codec 给omx的命令: empty_buffer 和fill_buffer 。 这样数据就可以不间断的发送给omx处理;在mediaplayer 中驱动数据处理的也是这个模型了。
输出端的:
onOMXFillBufferDoneàkWhatDrainThisBufferàMediaCodec::onOutputBufferAvailable()àCB_OUTPUT_AVAILABLEàhandleAnOutputBufferàmRenderer->queueBuffer(mIsAudio, buffer, reply); àRenderer::onQueueBufferàpostDrainAudioQueue_l/postDrainVideoQueue 这里维护者一个mAudioQueue/mVideoQueue;àonDrainAudioQueueàwritten = mAudioSink->write() àkWhatRenderBufferàDecoder::onRenderBufferàMediaCodec::onReleaseOutputBuffer
之后回收或者释放buffer,然后会回复一个kWhatOutputBufferDrained给Acodec ;àonOutputBufferDrainedà发送命令fillbuffer给omx;
输入端的:
Decoder::handleAnInputBuffer à onRequestInputBuffers à doRequestBuffers à fetchInputData à mSource->dequeueAccessUnit(mIsAudio, &accessUnit)
完成读数据,读完数据会给Acodec 发送一个kWhatInputBufferFilled à onInputBufferFilled à mCodec->mOMX->emptyBuffer ;
这样数据循环就开始了。 只是简单的说明一下大概,后续有时间再慢慢详述。 android 8 马上要来了,看google的计划,omx 要被google抛弃了。codec这块会更强大。期待android 8.0 吧