Only be 'permissive' in decoder resolution check in certain circumstances
- Dominant language
- Java
- Stars
- 21.9k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
https://github.com/google/ExoPlayer/issues/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`](https://developer.android.com/reference/android/media/MediaCodecInfo.VideoCapabilities#areSizeAndRateSupported(int,%20int,%20double)). 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 (https://github.com/google/ExoPlayer/commit/d874656e8a7668a83c6702413f094f6a1f509070) was to **always** round video dimensions based on [`android.media.MediaCodecInfo.VideoCodecCapabilities#getHeightAlignment`](https://developer.android.com/reference/android/media/MediaCodecInfo.VideoCapabilities#getHeightAlignment()) and [`getWidthAlignment`](https://developer.android.com/reference/android/media/MediaCodecInfo.VideoCapabilities#getWidthAlignment()).
Unfortunately this then caused some confusion in https://github.com/google/ExoPlayer/issues/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`.
Contributor guide
Assessment
This issue has not been assessed yet.