MediaPlayerFlakyNetworkTests failing with CTS 5.1_r7 release

[stephenmiskovet]

Our platform which is based off the SabreSD imx6q reference platform started failing these 6 CTS tests with the release of CTS version 5.1_r7 (currently Google is on version 5.1_r8 for Lollipop 5.1):

android.media.cts.MediaPlayerFlakyNetworkTest#test_S1P000005

android.media.cts.MediaPlayerFlakyNetworkTest#test_S2P00001

android.media.cts.MediaPlayerFlakyNetworkTest#test_S3P00001

android.media.cts.MediaPlayerFlakyNetworkTest#test_S4P00001

android.media.cts.MediaPlayerFlakyNetworkTest#test_S5P00001

android.media.cts.MediaPlayerFlakyNetworkTest#test_S6P00002

Our release is based upon the first SabreSD IMX6_L5.1.1_2.0.0 GA (LMY47V). Both IMX6_L5.1.1_2.0.0 and IMX6_L5.1.1_2.1.0 GAs fail these CTS tests on the SabreSD reference board.

The first M release on the SabreSD reference board also fails these tests in the MediaPlayerFlakyNetworkTest package (IMX6_M6.0.1_1.0.0). The second release (IMX6_M6.0.1_2.0.0 from June 23, 2016) passes these tests. It looks like much of NXP's SoC/device specific code has been heavily patched/changed between these two releases.

We are looking for a solution for Lollipop, preferably on IMX6_L5.1.1_2.0.0, that passes CTS version 5.1_r8 specifically all the MediaPlayerFlakyNetworkTests.

[tonyzheng]

Hi,

Can you reproduce it on reference board?

In additon, MediaPlayerFlakyNetworkTest executes a range of tests on MediaPlayer while streaming a video from an HTTP server over a simulated "flaky" network. NXP has done no modification about this test case. It may be a Android original issue.

[stephenmiskovet · Accepted solution]

Hi Tao,

Yes, as my original post states, we see these failures on a SabreSD reference board with these software versions: IMX6_L5.1.1_2.0.0, IMX6_L5.1.1_2.1.0, and IMX6_M6.0.1_1.0.0.

There have been changes to the constantly evolving CTS which introduce these failures with the release of v5.1_r7 on the reference board.

We have found a solution through nearly a dozen changes in the OpenMAXIL and lib_ffmpeg source code. In the OpenMAXIL code, we increased the sleeps to be longer while decreasing the number of retries, if applicable. Timeouts in the HttpsProtocol.cpp were also increased as the old values didn't seem to make sense. We also slowed retries down in avio.c an order of magnitude as 1ms retries seem to be much too fast.

[jamesbone]

Dear Stephen,

Our Apps team it is looking into your request,  as soon as possible they are going to provide a response.