ExoPlayer: HEVC Crashing on Chromecast with Google TV via AVR

Environment

  • ExoPlayer r2.13.1 and above (including r2.14.2).
  • Chromecast with Google TV, connected to an AVR or soundbar (without the AVR or soundbar HEVC videos play correctly).
  • Android 10.
  • HEVC Main 10 video seems to be the common culprit.

Reproducing

  • Play the attached video in the ExoPlayer demo application, or any HEVC Main 10 video.

Actual Behaviour

  • Notice the video freezes randomly, frames are dropped or the device crashes and partially reboot (this takes a number of play throughs to replicate).
  • Null pointer dereference error occurs from the surfaceflinger process: Unable to handle kernel NULL pointer dereference at virtual address 00000000, this then causes the device to partially reboot - it seems more like an OS reboot rather than a full device reboot.

Expected Behaviour

Playback is smooth without frame freezes or drops, and without rebooting the device.

Sample + Recorded Video

https://drive.google.com/drive/folders/1hpLZnBSBvF89MxOXtbOPMgfg_t-4k898

  • HEVC 10 - EAC3 Atmos - Crash Sample.mkv is the sample video that can be played to replicate the behaviour.
  • ExoPlayer v2.14.2 Demo on Chromecast with Google TV.mp4 provides a video recording showing the behaviour on the ExoPlayer r2.14.2 demo application (shows the video freezing and frames being dropped).
  • adb bugreport is also zipped up in the folder.

Notes

Sounds like more of a device related issue rather than an issue with ExoPlayer, however the problem started occurring in ExoPlayer r.13.1. In r2.12.1 HEVC plays back smoothly on a Chromecast with Google TV device.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 67
  • Comments: 36 (8 by maintainers)

Most upvoted comments

I do have some updates on this issue:

  1. The GoogleTV team and SOC vendor are now both able to reproduce the issue(s), including the stretched video issue and the kernel panic (reboot). It’s unclear at this point whether they’re related, but it seems likely.
  2. The SOC vendor observed that the Plex app appears to be doing something unusual between the first and second playbacks. In particular, switching playback from non-tunnelled to tunnelled mode (background reading, if you’re interested in what this means). It’s thought that this is triggering an underlying bug in the SOC vendor provided part of the platform. The unusual nature of what the Plex app appears to be doing may explain why we’ve not received many reports of other applications being affected by the same issue.
  3. I was able to reproduce the stretched video issue (but not the kernel panic) directly with the ExoPlayer demo app, by modifying it to toggle between non-tunnelled and tunnelled mode.
  4. Plex can work around the issue in the short term by disabling tunnelled mode on GoogleTV. There may also be other workarounds that allow continued use of tunnelled mode, but this is the simplest short term fix. Plex have provided guidance here that the workaround will be included in their v8.26 beta release, which they’re aiming to release next week. They’ve also provided an APK in the same post, if you’re keen to try the fix before then.

We will keep this issue open to track the continued investigation into the underlying platform issue.

It shouldn’t be possible for the application layer (which is where ExoPlayer lives) to cause a device reboot, so the fact this is occurring indicates an issue in the underlying platform. I have requested an update and increased the priority of the issue that we previously filed on the relevant team.

I can confirm this behavior with a direct TV connection (no AVR)

Not sure how much use it will be, but there are a lot more posts about this over on the Plex forums, as a whole bunch of us originally thought this was an issue with plex, but after looking into it they’ve pointed the finger here.

https://forums.plex.tv/t/plex-restarts-new-google-tv-chromecast/711966

Regarding the underlying platform issues:

  1. A fix for the stretched video issue has been identified, and will be included in future updates to GoogleTV devices.
  2. The kernel panic issue is still under investigation.

I can produce this 100% reliably on demand (every single next episode button press on plex app on the chromecast) if you’d like me to provide any data? It plays with the top left quarter of the image ‘zoomed in’ filling the screen, and sometimes crashes and reboots on exiting the episode, not often though.

Happy to carry out troubleshooting if it will assist. Just lmk what you would like me to do / provide and I’ll get on it.

Versions: App; com.plex.android 8.23.1.28053 Android TV OS 10 Kernel version 4.9.180 Android TV OS build: QTS1.210311.008.350836

File: Video;1910x1080 -23fps 2.1 Mbps - HEVC 150 main 10 Audio; English - Opus - Stereo - 101kbps 48000khz

All available updates installed.

Also using a Yamaha YAS-107 soundbar interestingly.

I do understand this may be outside the scope of the ExoPlayer team but what actual action is being taken here?

The internal issue was routed to the SOC manufacturer, who was unable to reproduce the issue and routed it back to the Google TV team. It’s currently on the Google TV team pending next steps. We’re continuing to escalate the issue with that team to try and get some more movement on it.

Chiming in to say I see this same issue without an AVR as well as odd skipping behavior. Overall poor experience and been this way for months now 😑

I have four Chromecast with GoogleTV units. Three are connected to the TV only, one is connected to the TV with a bluetooth connection for audio. Every single unit has the same stretching/rebooting issue mentioned above when autoplaying the [next] HEVC video in a series on PLEX. The first video always plays fine, but continuing onto another one will produce this bug EVERY. SINGLE. TIME. This fault has only occurred since version 8.16.0 of ExoPlayer was incorporated into PLEX and every version since.

Please look at what changed in this version from the previous to try and narrow down the cause as these GoogleTV devices are pretty much useless for everybody that bought them specifically to run PLEX.

It shouldn’t be possible for the application layer (which is where ExoPlayer lives) to cause a device reboot, so the fact this is occurring indicates an issue in the underlying platform. I have requested an update and increased the priority of the issue that we previously filed on the relevant team.

This is a critical observation. To date, this exceptional case has been provided no observable action by the Google development team even where they own the entire environment. I do understand this may be outside the scope of the ExoPlayer team but what actual action is being taken here?

@ojw28 It has been a couple weeks since the last update, anything new to report? Thanks.

@ojw28 Can you provide us an update on this issue? If you look at the original issue post on the Plex forum, this is getting frustrating to a great number of people: https://forums.plex.tv/t/plex-restarts-new-google-tv-chromecast/711966

I have the auto play issue, as well as enabling any subtitles crashes the entire google tv with chromecast.

THIS IS NOT DEVICE DEPENDANT : i tried with 2 differents setup : one on direct connection to the TV and one with an Onkyo AVR.

Also can confirm nothing to do with an AVR, was happening on two separate TVs for me. One with a soundbar, and one directly connected.

I’ve asked the relevant team to take a look and will update here if/when we learn more. Thanks.

I’m going to hide posts here that add no useful technical information to this thread (you can still expand them to read them, if you wish to do so). They’re just making it harder to find the actual useful updates.

Please also consider that we (the ExoPlayer team) are effectively clients of the underlying platform, just as Plex is, and just as you are as a consumer. This issue is frustrating for us as well, since it’s affecting the stability of our library on a popular device. Complaining to the people who are trying to help you, with scattered use of the caps lock, is not constructive and will do nothing to help resolve this issue faster. Thanks.