忙活了好久，没有更新blog了，总算有点东西能够拿出来show show了。
这段时间主要在忙活把h264+amr_nb的解码器，以前在nokia s60的开发环境下面做的，现在应项目需要，把它移植到moto的a1200上面。根据前面的几篇文章积累下来的图形函数库和基本的操作方法，本次移植还是很顺利的。无非就是数据类型改一下，然后就是用posix的pthread替代原本的active object活动对象，后来在播放的时候遇到了时间的问题，原本的h264解码器是针对定码率10fps左右的QCIF（176x144）大小的视频进行播放的设计，在nokia的手机上采用了time critical的优先级别进行播放。视频和音频的时间同步必须非常准确，否则就会引起音频和视频脱节等问题。在a1200上，我尝试着用了很多方法均以失败告终，很是郁闷。
例如：
sleep()，不行，它是针对于秒级别的；
usleep()也不行，计时精度太差，而且是忙等待，对于手机的资源消耗很大。
而传统的signal+timer的方案也已经用于mp3播放了，此时再用timer会导致系统的稳定性变差，精度也有问题。。。
没有办法了，想到了gettimeofday函数，它据说可以得到微妙级别的计数。于是乎好好研究了一下，确实有所启发，当然了，首先需要包含两个头文件：
#include
#include //这个文件里面有timeval和timezone的结构定义
然后就是gettimeofday的函数定义了：
int gettimeofday ( struct timeval * tv , struct timezone * tz ) ;
函数说明
gettimeofday()会把目前的时间用tv所指的结构返回，当地时区的信息则放到tz所指的结构中。
timeval结构定义为:
struct timeval{
long tv_sec; /* 秒，就是普通的秒 */
long tv_usec; /*微秒，注意是1000000微妙等于1秒喔，1毫秒等于1000微秒！*/
};
timezone 结构定义为:
struct timezone{
int tz_minuteswest; /*和Greenwich 时间差了多少分钟*/
int tz_dsttime; /*日光节约时间的状态*/
};
上述两个结构都定义在/usr/include/sys/time.h文件内（a1200就没有了，呵呵，好在linux是到处都有的）。
tz_dsttime 所代表的状态如下
DST_NONE /*不使用*/
DST_USA /*美国*/
DST_AUST /*澳洲*/
DST_WET /*西欧*/
DST_MET /*中欧*/
DST_EET /*东欧*/
DST_CAN /*加拿大*/
DST_GB /*大不列颠*/
DST_RUM /*罗马尼亚*/
DST_TUR /*土耳其*/
DST_AUSTALT /*澳洲（1986年以后）*/
返回值
成功则返回0，失败返回－1，错误代码存于errno。附加说明EFAULT指针tv和tz所指的内存空间超出存取权限。
范例
#include
#include
main(){
struct timeval tv;
struct timezone tz;
gettimeofday (&tv , &tz);
printf(“tv_sec; %d\n”, tv,.tv_sec) ;
printf(“tv_usec; %d\n”,tv.tv_usec);
printf(“tz_minuteswest; %d\n”, tz.tz_minuteswest);
printf(“tz_dsttime, %d\n”,tz.tz_dsttime);
}
执行
tv_sec: 974857339
tv_usec:136996
tz_minuteswest:-540
tz_dsttime:0
在视频播放过程中，我们只关心两次gettimeofday的结果的差值，每次调用h264解码器设置在100毫秒左右的延时即可(10fps导致的)。可以利用sleep(0)来实现cpu的“空闲”延时：
我测试过sleep(n)代表延时n秒，这里如果n等于0，是不是会暂时释放一下cpu把时钟周期让给系统
别的程序使用呢？呵呵，关于这一点，还希望更多高手来拍砖。
void CM5H264Player::MainPlay()
{
bool play_over = false ;
// 这里是根据fps计算应该延时的长度，并且假设解码和缩放操作只用了1毫秒
int delay_ms = 1000 / (m_pMediaPlayer->GetVideoFPS() + 1) ;
CTimeStat tm_chk ;
tm_chk.ResetMs() ; // 重新设置相对时间起始点
while(!play_over && !m_need_stop) {
m_pContentManager->Update() ;
play_over = m_pMediaPlayer->Update() ;
if(play_over <= -1) {
(*m_callback_func)(m_callback_data) ; // 解码结束的回调函数，做扫尾工作的
break ;
}
// delay for a while nearly 91ms
while((int)(tm_chk.GetMs()) < delay_ms) sleep(0) ;
tm_chk.ResetMs() ;
}
}
这里的tm_chk的GetMs函数的定义如下：
unsigned long CTimeStat::GetMs()
{
unsigned long lft_ms = 0 ;
unsigned long sec_ms = 0 ;
if (m_state == TIME_NONE) return 0 ;
if (m_state == TIME_PAUSE) return 0 ;
if (m_state == TIME_CLOSE) return 0 ;
// 这里就是获取当前的时间了
gettimeofday(&m_curTime, &m_tz) ;
// 判断是否存在跨秒的比较问题，如果存在，则利用
// 已经过去的秒数减一
if(m_preTime.tv_usec > m_curTime.tv_usec) {
m_curTime.tv_usec += 1000000 ;
m_curTime.tv_sec-- ;
}
// 这里是计算毫秒
lft_ms = m_curTime.tv_usec - m_preTime.tv_usec ;
lft_ms /= 1000 ;
// 这里是计算秒，并且把秒转换成毫秒
sec_ms = m_curTime.tv_sec - m_preTime.tv_sec ;
sec_ms *= 1000 ;
// 最后返回结果
return (sec_ms + lft_ms);
}
相信如此一来，大家就对这个延时很了解了吧？通过上面的处理，线程可以基本精确的计时
并且满足多媒体视频播放的要求。网上看到别的大侠说，这样的方法在cpu比较空闲的时候
可能计时精度还可以，如果cpu满负荷，就会直接影响计时精度。我经过a1200的测试，发现
多数情况下是没有问题的，如果出现抢占cpu的情况，还可以酌情提高当前线程的优先级，
以期获得更多的cpu时间。
网上跟别的大侠讨论的结果通常是修改一下linux的驱动，这样可以做到完全准确的定时。然而
既然是给moto a1200开发，归根到底，我还是开发应用的，改了人家的驱动（尽管这也不是什么
mission impossible的事情，现在的linux手机连系统都可以随意刷，里面的包也自然可以随意修改）
似乎于情于理说不过去，还是保留原来的吧，至少可以通过上述办法变通的解决这个问题。
下面是视频播放的a1200真机抓图，在a1200的pxa270强大cpu下面，视频播放效果非常好：
相信不久，5m周刊就会完全在触摸屏的环境下运行起来的！
呵呵，最近iphone的gui给了我非常大的触动，这次在moto a1200手机上面，正好是触摸屏，我要试着实现一下看看，大家拭目以待吧 :P
阅读(5201) | 评论(9) | 转发(0) |
