dlna测试遇到的第二个问题

转自 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秒左右就能退出这个循环，所以能够播放，不用规避。