EasyPlayer延迟再优化策略

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时间,这样播放器便可更快地消耗掉缓存帧数,将已经存在的延迟逐步追上.