Qualcomm QTV Player

1 QTV Architecture

QTV的高通的音视频解码方案，来自packetvideo的PV:Player。Architecture如下:

(1)QCT Mediaplayer Application:为OEM提供的播放器，使用Brew API；通常若OEM移植上自己的UI后，不会使用原生的播放器。而是调用IMedia API实现自己的播放器。
(2)IMedia API：Brew API的一部分,如IMEDIA_RegisterNotify,IMEDIA_SetMediaParam,IMEDIA_GetMediaParam,IMEDIA_Play,IMEDIA_Stop等等。相关接口的声明在文件AEEMedia.h中。

其中Create Media根据文件格式和码流格式，创建Media示例；AEEMediaData是Data Source/Sink（输入输出）的封装。

(3)QTV Player（MPEG4 Video Engine）:是最核心的部分，包括：Streaming协议--基于TCP的RTSP/SDP，基于UDP的RTP/RTCP;MPEG4 playback；码流解析；音视频同步。

(4)QTV Audio/Video Codec API:Audio API--CMX；Video API—QTV Decoder API。CMX API要通过snd ，vocoder，qdsp，驱动dsp来获取到解码后的数据。

(5)QTV Audio/Video Codec:ARM负责huffman、shape、texture；DSP负责运动补偿，IDCT,后处理。后处理实质使用的是MDP。

2 QTV Tasks

QTV包含7个Sub Task，他们按任务优先级从高到底排列是：Player，Audio Player，Streamer，Renderer，Decoder，Timed Text，Parser，其中Streamer仅在播放网络流时会被创建，其他在创建qtv实例时总是被创建。高通推荐不要去改变这些任务的相对优先级，并且把他作为一个整体放在最低优先级（仅高于sleep task）。具体原因可去参考《LINUX内核设计与实现》中I/O消耗性任务和CPU消耗性任务的定义和优先级安排。

下面说明一下相对比较复杂，与data service相关的PV:Streamer。Streamer task运行时，其调用流程如下：

Scheduler负责维护一个结构体队列，结构体中包含函数指针。队列的初始状态和成员，由brew注册。当队列成员删除或增加时，调用的函数会相应改变。比如退出VOD播放时，Scheduler会删除当前运行的成员，执行队列中下一个成员，进行断开网络close session等动作。

在函数NetInput::recvFrom中，对调用一个指向data service的函数指针，该函数指针指向的函数去获取输入的TCP或者UDP包。在双模手机上，获取不同网络的数据，该指针就会指向不同的data service函数。

3 Real-Time Protocol

(1)Protocol简介：RTP/RTCP/RTSP/SIP/SDP

(2)Qualcomm 网络数据传输

4 QTV输出视频帧的显示

QTV由Brew调用，QTV的视频输出也由Brew进行控制。相应的Brew API为IDisplay，在文件AEEDisp.h中。

5 QTV的heap管理

QTV的heap分配使用OEM Heap Manager。