Repository navigation
MediaTek OMX.MTK.VIDEO.DECODER.HEVC fails with vendor error 0x90000008 on non-DRM HEVC content (Philips Android TV, MT5887) #3447
Description
Version
Media3 1.11.1 (also reproduced against a local build of main)
Devices that reproduce the issue
Philips 58PUS8545/12 (internal platform TPM191E, product PH9M_EA_5599), chipset MediaTek MT5887 (TV SoC), Android 12 (API 31).
Build fingerprint: Philips/PH9M_EA_5599/PH9M_EA_5599:12/STT2.230526.001/4215:user/release-keys
Reproduction steps
Play a local HEVC 1080p (x265) MKV file (profile hvc1.1.2.L120, 1920x808) via direct play. The hardware decoder reliably fails. In one session it failed consistently at a fixed point (around 48 minutes) into the file, after over 45 minutes of successful decoding. In a later session it failed immediately from the start of the same file instead. Once it fails, it continues to fail immediately on every retry within the same app session: observed 3 consecutive fresh decoder initializations within 4 seconds, each failing identically.
Expected result
HEVC content decodes normally via the hardware decoder.
Actual result
MediaCodec.CodecException: Error 0x90000008 / Codec reported err 0x90000008, actionCode 0, while in state 6/STARTED, thrown shortly after videoDecoderInitialized. Content is not DRM-protected.
Logs
E/ACodec: [OMX.MTK.VIDEO.DECODER.HEVC] ERROR(0x90000008)
E/MediaCodec: Codec reported err 0x90000008, actionCode 0, while in state 6/STARTED
E/MediaCodecVideoRenderer: Video codec error
android.media.MediaCodec$CodecException: Error 0x90000008
Caused by: androidx.media3.exoplayer.video.MediaCodecVideoDecoderException: Decoder failed: OMX.MTK.VIDEO.DECODER.HEVC
Related
Likely the same decoder-family issue as #2711 (MediaTek Dimensity HEVC black-screen), though that one is a silent freeze with no error reported, and affects phone/tablet Dimensity chips rather than this TV-specific MT5887 SoC. This report has a loud, specific error code and a clean non-DRM repro, which several #2711 reporters struggled to provide.
We've proposed a library-level mitigation for the general class of this bug in #3421 / #3422 (exclude a decoder that fails at runtime and fall back to another one), but that doesn't fix the underlying vendor decoder issue itself.
cc @rrfrias since you're already coordinating with MediaTek on #2711, in case this additional device/chipset/error-code data point is useful.
Activity
tonihei commentedon Oct 9, 2026
Thanks for reporting!
This is likely unrelated as this case is not about Widevine L1 playback at all.
We could try to report it to Philips or MediaTek, but given this particular chipset is probably end of life by now, it's unlikely we'd get an retroactive fix for it. If you know of any other devices showing this issue (particularly on newer OS levels), then it's more likely we can resolve the root cause.
This means the best course of action is a Media3 workaround that falls back during runtime failures as suggested in #3421 / #3422.
Assigning to @microkatz in case he has other suggestions.