EasyPlayer延迟再优化策略

移动开发 waitig 678℃ 百度已收录 0评论

EasyPlayer延迟再优化策略

EasyPlayer是一款专门针对RTSP协议进行过优化的播放器.其中两个我们引以为傲的的优点就是起播快和低延迟.最近我们遇到一些需求,其对延迟要求非常苛刻,于是我们再把代码捡起来,针对之前的播放策略进行再优化,果然又发现一些可以更改的地方,于是又对性能进行了一次压榨,再一次降低了延迟.

主要优化内容如下:

  • 提高解码线程的优先级.

    一个不容忽视且容易被人忽略的事实,就是安卓层在一些低优先级的线程上面,线程休眠时间要比sleep时间要长.比如下面一段代码,在一个线程优先级为BACKGROUND的线程里,我们sleep 100毫秒,然后打印实际上线程暂停的时间.

    new Thread(new Runnable() {
              @Override
              public void run() {
                  Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                  long millis = System.currentTimeMillis();
                  try {
                      Thread.sleep(100);
                  } catch (InterruptedException e) {
                      e.printStackTrace();
                  }
                  Log.d(TAG,"thread sleep :" + (System.currentTimeMillis() - millis));
              }
          }).start();

    然后打印输出如下内容:

    thread sleep :148

    我们发现线程居然sleep了148毫秒.

    如果把线程优先级设置高一些,如果使用默认的优先级,那打印结果如下:

    thread sleep :102

    可见优先级对线程的睡眠时间影响很大.我们这里需要严格控制休眠时间,所以我们需要将线程优先级设置高一些,设置成Audio级别.

    Process.setThreadPriority(Process.THREAD_PRIORITY_AUDIO);
  • 对于音频播放,使用AudioTrack的非阻塞模式写入.

    EasyPlayer在渲染视频轨和音频轨的时候,是分别在不同的线程进行的.但是由于有音视频同步策略,如果某一个线程速度慢了,那另外一个线程就也会放慢下来等待它.而音频渲染就是这样一个容易”慢下来”的线程.

    音频数据是由AudioTrack来进行渲染的,我们将PCM数据由AudioTrack的write接口写入,就可以播放出声音.但是这个write函数是阻塞的,假设某段时间由于网络抖动,没有音频数据过来,过会又突然来了一大块数据,把这些数据都write到AudioTrack,会阻塞一段时间.这样就会导致不可避免的延迟.

    在Android 6.0,AudioTrack提供了一个非阻塞的写入方式,我们在6.0以上的安卓系统,使用非阻塞方式写入,这样大块数据也能很快写入音频设备,就不会因此而导致延迟了.

  • 优化追帧策略.

    上面说了,由于网络抖动,可能一段时间内都没有收到媒体数据,过一会又突然来了一大块数据.这时候已经有延迟产生了.那怎么办呢?我们可以让播放器稍微快速点播放.通过控制视频线程的sleep时间便可实现.当缓冲区内缓存帧数比较大时,可以以一定比例降低sleep时间,这样播放器便可更快地消耗掉缓存帧数,将已经存在的延迟逐步追上.


本文由【waitig】发表在等英博客
本文固定链接:EasyPlayer延迟再优化策略
欢迎关注本站官方公众号,每日都有干货分享!
等英博客官方公众号
点赞 (0)分享 (0)