Only be 'permissive' in decoder resolution check in certain circumstances

[icbaker]

#6551 reported an issue where ExoPlayer was failing to play H264 content because it was passing the 'display resolution' from an HLS manifest to android.media.MediaCodecInfo.VideoCodecCapabilities#areSizeAndRateSupported. In that case the 'display resolution' width was 1129 but the actual samples had a width of 1130. Odd widths are illegal in H264, so the codec reported it couldn't play the content.

The fix (d874656) was to always round video dimensions based on android.media.MediaCodecInfo.VideoCodecCapabilities#getHeightAlignment and getWidthAlignment.

Unfortunately this then caused some confusion in #9103 when a VP8 video with an odd height (405px) failed to decode but the log said format_supported=YES because the height had been rounded to 406px before querying the decoder. Removing the rounding didn't fix the playback error, but it changed the log to say format_supported=NO_EXCEEDS_CAPABILITIES, so it's at least a somewhat 'expected' failure.

Ideally we'd only do the rounding in cases the resolution represents something other than 'sample resolution'. i.e. if it comes from an HLS manifest, we should round. If it comes directly from a media container, we probably shouldn't.

This info probably needs to propagated through Format.

[tidux]

This is currently breaking WebM playback in browsers on the Galaxy S21 line.

[icbaker]

@tidux: I think there's possibly been a slight misunderstanding. This issue is marked low priority because it's tracking a change to ExoPlayer that only affects logging before a playback failure, it won't have an effect on whether playback succeeds or not (see #9103 for more details).

[Pentaphon]

it won't have an effect on whether playback succeeds or not (see #9103 for more details).

It absolutely keeps playback from succeeding. Webms affected by this issue DO NOT play at all and a toast error simply appears.

[icbaker]

It absolutely keeps playback from succeeding. Webms affected by this issue DO NOT play at all and a toast error simply appears.

I'm not disputing the videos with odd dimensions don't play with the c2.android.vp8.decoder codec - I agree with that. I'm saying that the changes covered by this issue won't change that. If we implement the enhancement suggested by this issue then playback of these videos will still fail with this codec. The only difference will be that the format will be logged as format_supported=NO_EXCEEDS_CAPABILITIES instead of the current format_supported=YES so the failure will be less surprising.

The fact that c2.android.vp8.decoder fails to play videos with odd dimensions is not related to ExoPlayer (we don't control the codec implementations). Given the code I found in #9103 (comment) it looks like a deliberate decision not to support odd-dimensioned videos.

[Pentaphon]

The fact that c2.android.vp8.decoder fails to play videos with odd dimensions is not related to ExoPlayer (we don't control the codec implementations). Given the code I found in #9103 (comment) it looks like a deliberate decision not to support odd-dimensioned videos.

if the issue is with an AOSP codec, why is this happening on some phones but not others? Isn't that basic part of AOSP just taken by OEMs and used as is? I doubt an OEM would mess with Google's codec implementation if they want their customers to have a consistent experience.

[icbaker]

if the issue is with an AOSP codec, why is this happening on some phones but not others? Isn't that basic part of AOSP just taken by OEMs and used as is? I doubt an OEM would mess with Google's codec implementation if they want their customers to have a consistent experience.

I'm not aware of any phones that are able to successfully play the video from #9103 with the c2.android.vp8.decoder. Some devices have alternative VP8 decoders, and so are able to successfully play the video using those, but then crash when they are manually ignored. This is what I saw with a Pixel 3a XL - with no modifications it played successfully using the c2.qti.vp8.decoder, but modifying the app to ignore that decoder resulted in it using c2.android.vp8.decoder and crashing: #9103 (comment)

So I think the "happening on some phones but not others" is likely related to whether the phone has an alternative VP8 decoder that is used in preference to c2.android.vp8.decoder.

[tidux]

Would it be possible to mandate decoder fallback to handle broken hardware decoders? IIRC this is how mpv does it on desktop. https://github.com/mpv-player/mpv/blob/master/video/decode/vd_lavc.c

@icbaker hi, whether this issue can fixed soon?

[Pentaphon]

So I think the "happening on some phones but not others" is likely related to whether the phone has an alternative VP8 decoder that is used in preference to c2.android.vp8.decoder.

Do you think there's any way for Exoplayer to "take over" in case an OEM has a buggy decoder (that they might never end up fixing due to short Android update commitments) in order to ensure proper playback across all devices? It seems to me that Google/AOSP/etc has an incentive to come up with a solution for these bad OEM practices since the end user is just going to "blame Android" instead of the OEM when a video doesn't play at all, or in our case, many videos don't play at all since webm is so widely used now.