freescale video decoder need output surface workaround

[zmafox]

Hi:
When I run gts test with on android board with freescale decoder, i found that MediaCodec#setOutputSurface will cause that video decoder could not dequeue buffer from surface.
com.google.android.exoplayer.gts.DashTest#testH264AdaptiveWithRendererDisabling
com.google.android.exoplayer.gts.DashTest#testH265AdaptiveWithRendererDisabling

the test will call MediaCodec#setOutputSurface twice.
as freescale decoder do not support storingMetadataInDecodedBuffers()
all output buffers of decoder are allocated from the surface when ACodec::configureCodec() called.
each time ACodec::handleSetSurface called, it will attach all buffers to the new surface.
when setSurface called the first time, all buffers are attached to Dummy surface.
when it called the second time, all buffers should be attached from dummy surface to playback surface.
however, this operation is cross-compile and graphic buffer handle changed after Surface::attachBuffer() called. Then the graphic handle dequeued from native window is not equal to previous handle that attached.
and ACodec could not get any surface buffer to queue into decoder component.

I checkout to dev-v2 branch and found a function named codecNeedsSetOutputSurfaceWorkaround() in MediaCodecVideoRenderer.java
qualcomm and MTK have added their decoder name to the function, then they can skip the test.
Please add freescale decoder name to that function. These decoders have same behavior on any product model.

Decoder name list:
OMX.Freescale.std.video_decoder.avc.v3.hw-based
OMX.Freescale.std.video_decoder.soft_hevc.sw-based
OMX.Freescale.std.video_decoder.hevc.hw-based

log.txt

related issue:
#3236
#3355

[ojw28]

MediaCodec.setOutputSurface is a public Android API, so it really needs to work properly. I don't think we're going to add anything to codecNeedsSetOutputSurfaceWorkaround that will give certain decoders a free pass indefinitely.

The existing passes in that method are for specific devices that have already shipped and are known to have the problem, and the workaround is needed in that case to prevent bad behavior on these devices. The passes do not permit the same issue to be shipped on any new devices.

If there are devices that have already shipped with these decoders, please could you provide a code snippet that we can use to target just the affected devices, but not devices that have yet to ship? For devices that have not shipped yet, I think the decoders will need to be implemented in a way that allows proper support for MediaCodec.setOutputSurface.

[zmafox]

The chipset has been released for years, and not all features are supported by decoder due to hardware limitation. The issue is just found when test with latest gts package, old gts package has no such issue.
I do not know the detailed device name because I am not working for certain device.
I am afraid this issue may happen with many devices with old hardware and some one will contact to you later for detailed product.

[ojw28]

Is it possible to provide an API level cut-off, in that case? It would be fine to target at the combination of the decoder name and an SDK_INT <= X check, for some value of X.

[zmafox]

the API level is also increased when upgrade android version.

[ojw28]

Well yes. But there's going to be some cut-off. Are any devices with the problematic decoder likely to ever receive Oreo, for example? What's the most recent version of Android that any of the affected devices currently runs?

[saiyamd]

Hello @ojw28, I am facing a similar issue, please check #3902. Is there any resolution for this? Our device is running Android 7.1.1 on Freescale i.MX6 platform.

[ojw28]

Let's use #3902 to track issues with the Freescale platform, however ultimately it's up to the platform provider to investigate and fix these problems (or explain to us why they believe our test is doing something invalid, as opposed to the platform being broken).

[benjaminjrood]

Hello @saiyamd and @ojw28 ,

I confirm that we are having the same issue using the Freescale/NXP i.MX6Q. I would also like to report that NXP has shipped the following BSPs for Android:

1. 5.1.1
2. 6.0
3. 7.1.1
4. 7.1.2
5. 8.0.0

And this issue is present in their codecs for all BSPs that we have tested. We discovered this issue recently since we received the GMS package and access to the GTS tool. The Freescale codecs pass the CTS test cases but fail the GTS ExoPlayer DASH/Widevine tests because of the issue described above. Since the issue has been present for quite some time in Freesscale/NXP codebase, it is unlikely that they are going to fix it quickly, and this will affect any devices running Android on a Freescale/NXP i.MX6 platform.