dlna测试遇到的第二个问题
2014-12-18 11:25
162 查看
转自 http://blog.sina.com.cn/foreverlovelost
问题背景:一个将近300M的adts音频文件,通过服务器共享给手机终端,手机终端使用dlna应用进行播放,发现缓冲了半个小时还不能播放。
另外不能播放对应的服务器采用的是Content-Length这种编码格式,而采样chunked这种编码方式的服务器却能够正常播放。
打log发现,在MediaExtractor中构造AACExtractor时一直没有返回,所以直接到AACExtractor构造函数中去看了。
有下面这样一段代码:
if(mDataSource->getSize(&streamSize)== OK) {
while (offset <streamSize) {
if((frameSize = getAdtsFrameLength(source, offset, NULL)) == 0){
return;
}
mOffsetVector.push(offset);
offset +=frameSize;
numFrames++;
}
// Round up and get the duration
mFrameDurationUs = (1024 * 1000000ll + (sr - 1))/ sr;
duration = numFrames * mFrameDurationUs;
mMeta->setInt64(kKeyDuration,duration);
}
前面一篇博客已经看过这个if条件,如果服务器指明了文件的大小,getSize将返回OK,而且文件的大小会保存在streamSize中,不能播放的服务器指明了文件的大小,所以会进入这个if条件。
adts文件也是由一个一个frame组成,while循环在这里的作用就是从文件开始一直到文件末尾,数一共有多少个frame(numFrames),最终通过下面的公式计算出这个音频文件的时长:
duration = numFrames *mFrameDurationUs;
总时长 = 帧数 * 每一帧的时长
问题就出现在这里,在通过流媒体来播放的时候,读取文件需要以字节的方式一个字节一个字节的从网上读取,当文件比较小的时候,这种过程我们还可以忍受范围之内,但是在这次测试中,一个音频文件有300M,这个无法忍受了,正常下载一个300M的文件都要半天,打log发现,十分钟过去了,才完成了五分之一,正是这个while循环一直不能退出,导致了不能播放。
而采用chunked编码的http协议,由于不能进入到这个if条件,所以直接跳过了这段代码,最终却能正常播放,其实这段代码也就是简单的计算时长的作用,不进来只会影响进度条右边的总时长显示为零。
最终我们解决(规避)这个问题的方法是:如果是流媒体文件且文件大小超过100M,我们就不进这个while循环了。
PS:由于放在本地播放,从内存直接拷贝数据较快,缓冲20秒左右就能退出这个循环,所以能够播放,不用规避。
问题背景:一个将近300M的adts音频文件,通过服务器共享给手机终端,手机终端使用dlna应用进行播放,发现缓冲了半个小时还不能播放。
另外不能播放对应的服务器采用的是Content-Length这种编码格式,而采样chunked这种编码方式的服务器却能够正常播放。
打log发现,在MediaExtractor中构造AACExtractor时一直没有返回,所以直接到AACExtractor构造函数中去看了。
有下面这样一段代码:
if(mDataSource->getSize(&streamSize)== OK) {
while (offset <streamSize) {
if((frameSize = getAdtsFrameLength(source, offset, NULL)) == 0){
return;
}
mOffsetVector.push(offset);
offset +=frameSize;
numFrames++;
}
// Round up and get the duration
mFrameDurationUs = (1024 * 1000000ll + (sr - 1))/ sr;
duration = numFrames * mFrameDurationUs;
mMeta->setInt64(kKeyDuration,duration);
}
前面一篇博客已经看过这个if条件,如果服务器指明了文件的大小,getSize将返回OK,而且文件的大小会保存在streamSize中,不能播放的服务器指明了文件的大小,所以会进入这个if条件。
adts文件也是由一个一个frame组成,while循环在这里的作用就是从文件开始一直到文件末尾,数一共有多少个frame(numFrames),最终通过下面的公式计算出这个音频文件的时长:
duration = numFrames *mFrameDurationUs;
总时长 = 帧数 * 每一帧的时长
问题就出现在这里,在通过流媒体来播放的时候,读取文件需要以字节的方式一个字节一个字节的从网上读取,当文件比较小的时候,这种过程我们还可以忍受范围之内,但是在这次测试中,一个音频文件有300M,这个无法忍受了,正常下载一个300M的文件都要半天,打log发现,十分钟过去了,才完成了五分之一,正是这个while循环一直不能退出,导致了不能播放。
而采用chunked编码的http协议,由于不能进入到这个if条件,所以直接跳过了这段代码,最终却能正常播放,其实这段代码也就是简单的计算时长的作用,不进来只会影响进度条右边的总时长显示为零。
最终我们解决(规避)这个问题的方法是:如果是流媒体文件且文件大小超过100M,我们就不进这个while循环了。
PS:由于放在本地播放,从内存直接拷贝数据较快,缓冲20秒左右就能退出这个循环,所以能够播放,不用规避。
相关文章推荐
- 测试membership遇到的问题
- 标题如何使用Cassini,我在测试Cassini时遇到的问题
- 服务器压力测试中遇到的问题.
- linux eclipse下配tomcat7 第一个测试程序遇到的问题及解决
- 测试的时候浏览出现 "WebDev.WebServer.exe 遇到问题需要关闭。我们对此引起的不便表示抱歉。
- hibernate测试遇到的问题org.apache.commons.lang.exception.NestableException
- 项目中遇到问题就是增加aranda(图片存储)测试环境依赖报错解决进行中
- 通过plsql 测试存储过程遇到的问题和学习到的一些基础知识整理
- 学VC++遇到的第二个问题
- Jmeter做性能测试遇到的问题及解决办法
- WatiN和Nunit合用测试WEB时遇到的问题
- LoadRunner在性能测试工作中遇到的问题以及解决办法小结
- IBM服务器以及本地PC机安装suse linux,oracle测试,遇到的问题有:
- 帮助测试人员搭建Mercury Quality Center 9.0遇到的问题
- 全程测试,从需求到设计到代码,集中人力来解决每个环节遇到的问题
- 用MyEclipse+struts+hibernate测试时遇到的问题
- 测试过程中遇到字符集问题小结
- 部署测试网站遇到的问题总结
- Loadrunner 进行SOCKET并发测试遇到问题
- 在windows下利用firewatir搭建测试框架时遇到的编码问题和解决方法