BugFix: Fix DV playback if SDR fallback is added to the manifest - #3344
BugFix: Fix DV playback if SDR fallback is added to the manifest#3344ybai001 wants to merge 1 commit into
Conversation
The partial fix in aa5b318 moved HDR and codec score preferences into quality preferences and resolved fallback MIME types, but testing indicates there is still SDR track instead of Dolby Vision track selected on some TV devices. This change fixes the remaining portion of androidx#3135 not addressed by aa5b318. (e.g. Dolby Vision profile 8.1 stream may fail in playback on separate OMX Dolby Vision decoders per profile device). Issue: androidx#3135 Related-commit: aa5b318
| this.resolvedMimeType = resolvedMimeType; | ||
| codecPreferenceScore = getVideoCodecPreferenceScore(resolvedMimeType); | ||
| isHdr = usesPrimaryDecoder && ColorInfo.isTransferHdr(format.colorInfo); | ||
| isHdr = usesPrimaryOrFallbackDecoder && ColorInfo.isTransferHdr(format.colorInfo); |
There was a problem hiding this comment.
The fallback decoder could be HDR too. For example,
- Dolby Vision profile 8.1 content includes a HDR10 compatible HEVC base layer
- Dolby Vision profile 8.4 content includes a HLG compatible HEVC base layer
- Dolby Vision profile 10.1 content includes a HDR10 compatible AV1 base layer
If the target device is not Dolby Vision licensed, HEVC/HEVC/AV1 decoder will be primary decoder. And the corresponding base layer content is still HDR content.
| return MediaCodecUtil.getDecoderInfosSoftMatch( | ||
| mediaCodecSelector, format, requiresSecureDecoder, requiresTunnelingDecoder); | ||
| if (MimeTypes.VIDEO_DOLBY_VISION.equals(format.sampleMimeType)) { | ||
| return MediaCodecUtil.getDecoderInfosSoftMatchFilteredByFormatSupport( |
There was a problem hiding this comment.
We replace getDecoderInfosSoftMatch() with getDecoderInfosSoftMatchFilteredByFormatSupport() to resolve below two issues:
-
Separate OMX Dolby Vision decoders per profile
On some old Dolby Vision licensed devices (e.g. Philips 55OLED910/12), a dedicated OMX Dolby Vision decoder is for each DV profile (e.g. three decoders to support profile 5/8.x/9.x respectively). Assume the played content includes two tracks in manifest: one is DV P8.4, the other is SDR. If we're fortunate, the decoder supporting DV Profile 8.X appears first in the decoder list. In that case, it is treated as the preferred decoder, and Dolby Vision is played back on the device. But, if the first decoder in the list supports a different Dolby Vision profile (e.g. DV P5) than the one being played, it gets marked as isPreferred = false. So it receives a lower score in the Track Selector than an SDR decoder. This leads to incorrect track selection, where SDR is preferred over Dolby Vision even though the device fully supports the Dolby Vision profile being played. -
On the device, there is a single Dolby Vision decoder that supports both profile 5 and profile 8.x (HEVC based). The problem appears with Profile 10 (AV1 based). For example, consider a manifest containing P10.1 + SDR on a Dolby Vision-enabled device that supports P5, P8.x but not for P10.x. At the same time, this device also includes an AV1 decoder. With the current implementation, the SDR track will be selected. This happens because the Dolby Vision decoder is included in decoderInfos even though it does not support the requested Dolby Vision profile (P10.1), since the check is performed only against the MIME type. As a result, when such a decoder appears first in the list and is evaluated through isFormatSupported(), it reports that the format is not supported (i.e. it supports only p5 and p8.x). This triggers a decoder fallback to the AV1 decoder, but it also causes the decoder to be marked as isPreferred = false (which is wrong because the DV decoder shouldn't be on the list). For devices that do not support the requested Dolby Vision profile, the cross-compatible base layer decoder (AV1) should still be considered the preferred decoder - this is the same behavior that we can see on non Dolby Vision devices today.
| if (MimeTypes.VIDEO_DOLBY_VISION.equals(format.sampleMimeType)) { | ||
| return MediaCodecUtil.getDecoderInfosSoftMatchFilteredByFormatSupport( | ||
| context, mediaCodecSelector, format, requiresSecureDecoder, requiresTunnelingDecoder); | ||
| } else { |
There was a problem hiding this comment.
To minimize the risk, we just apply our new method MediaCodecUtil.getDecoderInfosSoftMatchFilteredByFormatSupport() to Dolby Vision only. In theory, we think this method should be applied to other formats too.
2 participants
The partial fix in aa5b318 moved HDR and codec score preferences into quality preferences and resolved fallback MIME types, but testing indicates there is still SDR track instead of Dolby Vision track selected on some TV devices.
Original issue: #3135
Related-commit: aa5b318
This change fixes the remaining portion of #3135 not addressed by aa5b318. (The details can be found in inline comments.)