Tunneling support on API >= 23 does not start renderer

[thasso]

Issue description

Tunneled playback does not start on (at least some) API >= 23 Devices and the player stays in buffering state.

It looks to me like the MediaCodec.OnFrameRenderedListener that is used on API >=23 to trigger maybeNotifyRenderedFirstFrame() is not triggered if the AudioTrack is not started. That in turn causes video render to report that it is not ready since isReady() relies on the renderedFirstFrame when in tunneling mode, causing the renders not to be enabled, which means the AudioTrack is never started and the player stays in buffering state.

An easy fix to confirm the issue was to use the < 23 behaviour and call maybeNotifyRenderedFirstFrame() in onQueueInputBuffer of the MediaCodecVideoRenderer, i.e:

  @Override
  protected void onQueueInputBuffer(DecoderInputBuffer buffer) {
    if (tunneling) {
      maybeNotifyRenderedFirstFrame();
    }
  }

Please note that with the fix above, the attached OnFrameRenderedListener is indeed triggered, so it's not that the listener is not working at all, it just seems that on the devices I tested, the tunneling implementation is indeed waiting for the first AV sync header on the AudioTrack before rendering the first frame and triggering the listener, hence it seems like this can not be used reliably as a first frame indicator.

Maybe I missed something or maybe there is a better workaround, but to me it would make sense to remove the listener approach and fallback to the <23 behaviour and trigger the first frame notification when input is queued and tunneling is enabled. I'd appreciate any thoughts on this and I'm happy to prepare a PR for any potential fix.

Reproduction steps

Enable tunneling in the Demo Application and try to play any of the demo content on an API >= 23 device.

Link to test content

Can be reproduced with any of the demo content

Version of ExoPlayer being used

Tested and reproduces with 2.4.2 and dev-v2 commit 8af77ac

Device(s) and version(s) of Android being used

The devices I could reproduce this with is a Sony Bravia 4K 2015 (API 23) and a Technicolor Skipper (API 23).

A full bug report captured from the device

Happy to send one if it is required for this issue

[thasso]

Quick addition, an alternative patch might be to include tunnling in the isReady() conditions:

  @Override
  public boolean isReady() {
    if (super.isReady() && (renderedFirstFrame || (dummySurface != null && surface == dummySurface)
        || getCodec() == null || tunneling)) {
      // Ready. If we were joining then we've now joined, so clear the joining deadline.
      joiningDeadlineMs = C.TIME_UNSET;
      return true;
    }
    ....
  }

[zhanghuicuc]

got the same problem on some android tv devices using MStar6A938 chip

[MizzleDK]

I've been experiencing the same issue on Sony and Philips TVs running Android TV 6.0. Funnily enough, it worked on Nvidia Shield TV, both the 2015 and 2017 versions.

[andrewlewis]

Thanks for reporting this. Your suggested fix to isReady() looks good. I'll submit the same change and this issue will be updated when it's pushed.

[ojw28]

We've merged a fix into dev-v2. Please verify if possible.