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。