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.