Exoplayer: Capabilities: Video "exceeds capabilities" (but plays fine if forced)

[nikdroid]

Environment :

Device Samsung GT-S7262
android version 4.1.2, RAM 512MB

install the exo player demo app and start playing "YouTube DASH
Google Glass(MP4,H264)" video, _we have observed following issue only on this particular device:_

Behaviour with Exo player library version : r2.0.4 :

Video is not rendered. Everything else works fine. (You can hear audio, and see the video controllers)
We have attached the log file bug_report_log.txt which shows the failure log.

Behaviour with Exo player library version : r1.5.9 :
Everything works fine.

Above issue occurs on this particular device only.
And it happens with all url given in demo app except for mp4 url.

As you can observe, exoplayer demo app ( library r1.5.9) works where as the one with newer
library (r2.0.4) has issues; on the same device, same environment.

As we are using r2.0.4 in our app, we are facing this issue. Pl provide a fix or a workaround!

[xander-lw]

I have the same problem, more or less. From my own logs, which can also be seen in the log OP posted, this one seems to be the culprit:

Track:0, id=1, mimeType=video/avc, res=750x1334, supported=NO_EXCEEDS_CAPABILITIES

No real clear reason why it "exceeds capabilities"... I haven't tested the file with Exoplayer v1, but I can play the file using a VideoView. In my case I'm playing a local file though.

For me, it happens on Android 5.1 and on a HTC One m7 device (GPE edition). I also tested on a Moto X running Android 6, which plays the video without problems.

Finally, some codec information about the file I'm trying to play:
https://gist.github.com/Xanderrr/e9ab68d5d5c443cc757546267ccecde6

[ojw28]

The device is indicating that it doesn't support the media you're attempting to play. It's likely the device is under-reporting its capabilities, given your observations. We'll need to get hold of a device and have a look.

[nikdroid]

@ojw28 @Xanderrr Thanks for your replay. But the main issue is, as mentioned, it works fine with old library i.e. r1.5.9 but fails to do so on r2.0.4!!

[ojw28]

V2 performs more checks than V1 did, so that isn't inconsistent with the diagnosis. We don't want to revert the additional checks because they prevent playback failures on other correctly functioning devices.

[xuxucode]

Yes, v2 does more checks, I modified MediaCodecAudioRenderer to fix a problem with audio/mpeg-L2. You could modify MediaCodecVideoRenderer as a workaround to fix your problem.

[ojw28]

I don't think disabling the additional checks is a good solution in the general case. What we'll do is:

1. Add some additional logging that indicates exactly which check is failing and why, so that we can see this in future bug reports.
2. For each report received we'll add a corresponding device specific workaround, if appropriate.

I suspect we'll pretty squash out the most common cases (and I'd be surprised if there are a huge number of cases required; most likely the majority of these issues are with older, possibly lower end devices).

[xuxucode]

I am working on playing MPEG2 TS on Amlogic Tv Box S905X (android version 6.0.1), the tracks:

Tracks [
  Renderer:0 [
    Group:0, adaptive_supported=N/A [
      [X] Track:0, id=null, mimeType=video/mpeg2, res=720x576, supported=YES
    ]
  ]
  Renderer:1 [
    Group:0, adaptive_supported=N/A [
      [ ] Track:0, id=null, mimeType=audio/mpeg-L2, channels=2, sample_rate=48000, supported=NO_EXCEEDS_CAPABILITIES
    ]
  ]
]

The stream has 2 audio channels that exceeds the device capability.

This is a device specific issue, the workaround works for my case, maybe not for others.

[rlatapy-gpsw]

Hi,
Is there a way to bypass the video size check ?
At the moment I'm modify isVideoSizeSupportedV21 method to return true based on device model and resolution to be able to play high res video with galaxy Note 4.

  public boolean isVideoSizeSupportedV21(int width, int height) {
      if(width <= 3840 && height <= 1920 && android.os.Build.MODEL.equalsIgnoreCase("SM-N910F"))
          return  true;
...

Is there a cleaner way to do that ?

[ojw28]

Please could anyone encountering this issue:

1. Check out the latest dev-v2 code.
2. Try and play the affected video.
3. Paste the output of adb logcat -s "MediaCodecInfo" here. You should see a bunch of lines containing "FalseCheck" the detail exactly why the stream wasn't played.

Thanks!

[rlatapy-gpsw]

/com.google.android.exoplayer2.demo D/MediaCodecInfo: FalseCheck [size.support, 3840x1920] [OMX.qcom.video.decoder.avc, video/avc] [trlte, SM-N910F, samsung, 23]

[ojw28]

The change ref'd above will have helped with vertical videos (i.e. where height > width). We're still working on ways to mitigate this issue for other videos.

[hameno]

We also have a video which is not working (no video, only audio) with ExoPlayer v2 but works in a simple VideoView. Using the latest dev-version (e56cf49) we get the following output in the logs:

11-28 12:03:26.072 D/MediaCodecInfo: NoSupport [size.support, 1280x720] [OMX.Exynos.mpeg4.dec, video/mp4v-es] [gts210wifi, SM-T810, samsung, 23]

The video has the following settings:

General
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 7.57 MiB
Duration : 57s 942ms
Overall bit rate mode : Variable
Overall bit rate : 1 096 Kbps
Encoded date : UTC 2016-09-21 15:02:58
Tagged date : UTC 2016-09-21 15:02:58
Writing application : HandBrake 0.10.2 2015061100

Video
ID : 1
Format : MPEG-4 Visual
Format profile : Simple@L1
Format settings, BVOP : No
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : 20
Duration : 57s 880ms
Bit rate : 961 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.042
Stream size : 6.63 MiB (88%)
Writing library : Lavc55.34.1
Encoded date : UTC 2016-09-21 15:02:58
Tagged date : UTC 2016-09-21 15:02:58

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 57s 942ms
Bit rate mode : Variable
Bit rate : 132 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 928 KiB (12%)
Title : Stereo / Stereo
Language : English
Encoded date : UTC 2016-09-21 15:02:58
Tagged date : UTC 2016-09-21 15:02:58

[ojw28]

Thanks! We'll shortly be pushing a change that will allow you to enable exceeding of reported decoder capabilities. It will be off by default, but it will be possible to enable it with a single line of code.

Once this change has landed you'll be able to enable the option to get back to what V1 did. We'll then consider either:

1. Enabling the option described above by default.
2. Writing a list of known overrides into the code as problematic cases are reported.
3. Writing a list of common-sense overrides into the code to achieve the same result, but hopefully more broadly than device specific overrides. For example we may put an override in place that assumes devices are able to decode H.264 at least up to their own display resolution (this is nearly always, if not completely 100%, true). That kind of override would solve the case immediately above this post, since the display resolution of the device is 2048 x 1536.

[ojw28]

Fixed in dev-v2.