The recorded video files are empty on API 28, 29

[ursar]

Description
Video files in folder "build/reports/marathon/video" is empty (size zero bytes)

Steps to Reproduce
Steps to reproduce the behaviour:

1. Edit in Marathonfile "screenRecordConfiguration"
   preferableRecorderType: "VIDEO"
2. Run AVD api 28, 29
3. Run tests
4. Open folder "build/reports/marathon/video"

Expected Results
There are video files with a recording of the test run, the file size is not empty.

Actual Results
Video is empty (size zero bytes)
Logs has messages
[AndroidDevice - execution - 127.0.0.1:5037:emulator-5554-2 @coroutine#1692] <AndroidDevice> screenrecord output: ShellCommandResult(stdout=[69, 110, 99, 111, 100, 101, 114, 32, 102, 97, 105, 108, 101, 100, 32, 40, 101, 114, 114, 61, 45, 51, 56, 41, 10], exitCode=218)

Devices (please complete the following information):
Reproduced on: Android API 28-39
Not reproduced on: Android API 30+
Marathon: 0.8.2
Android Emulator: 32.1.14.
AVD images: Google Play(arm64)

Additional context
Add any other context about the problem here.

[Malinskiy]

Hey @ursar

So stdout=[69, 110, 99, 111, 100, 101, 114, 32, 102, 97, 105, 108, 101, 100, 32, 40, 101, 114, 114, 61, 45, 51, 56, 41, 10] is decimal encoded message from your device that stands for

Encoder failed (err=-38)

It's a device problem and Marathon can't do anything about this. You can try using screenshots instead of a video to mitigate this problem when running on such Android devices.

[Malinskiy]

I don't see any response, I will close the issue. Please reopen if you think something can be done here from Marathon's side.

[kartik1o]

@Malinskiy just wondering if we can do anything from marathon side to handle this for the situation where we want to rely on the video instead of screenshots. when running screenrecord FILE_NAME --size widthxheight , with width and height lower than device configuration seems to mitigate this failure. Is there any way to get rid of this completely ?

[Malinskiy]

@kartik1o open to suggestions. This is an issue with screenrecord binary and the underlying codec implementations which are device-specific. A proper way for this to be solved is to ask screenrecord for a list of supported sizes with bitrates in a form of discovery, but this will break as soon as you devices have different screen since marathon doesn't support different screen size recording. Maybe a discovery with some predefined quality presets like low, medium, high. But this has to be implemented from the Android's side first.

[kartik1o]

Thanks for clarification @Malinskiy. When setting screenRecordConfiguration in marathon config, we have to set the RecorderType, which is either of type VIDEO or SCREENSHOT. so, lets say the we have RecorderType set as video, which we prefer and when running the tests, when screenrecord command fails with above error code i.e. Encoder failed (err=-38). Marathon can switch RecorderType to Screenshot and generate the screenshot .gif for us instead of video, that way we make sure that files(videos or screenshots) are not missing for the tests from the HTML reports. We can keep the preferableRecorderType as VIDEO but when screenrecord fails, we fallback to screenshots. The issue I had is that as this error is specific to some devices, so for those devices I don't want to go ahead and set preferableRecorderType as Screenshots, then whole test suite runs would be using the screenshots, if there would be some fallback mechanism, that would be great for handling these cases. I am not sure how feasible it would be to implement or is this something that I can use with current implementation as well ? I had a thought. so, wanted to reach out and clarify.

[Malinskiy]

By the time screenrecord returns failure the test might already be done with. If it's not then there will be questions around the missing time in the beginning of the test. My current thinking is that this should be solved in a similar way to how logcat capturing works: stream the media and only actually write it when needed. This does mean that marathon needs something else then screenrecord though i.e. scrcpy.

If the check for supporting screenrecord would be done during setup of the device though then it's definitely feasible. Support for additional verifications can be added to https://github.com/MarathonLabs/marathon/blob/develop/vendor/vendor-android/src/main/kotlin/com/malinskiy/marathon/android/BaseAndroidDevice.kt#L177

[kartik1o]

By the time screenrecord returns failure the test might already be done with. If it's not then there will be questions around the missing time in the beginning of the test. My current thinking is that this should be solved in a similar way to how logcat capturing works: stream the media and only actually write it when needed. This does mean that marathon needs something else then screenrecord though i.e. scrcpy.

If the check for supporting screenrecord would be done during setup of the device though then it's definitely feasible. Support for additional verifications can be added to https://github.com/MarathonLabs/marathon/blob/develop/vendor/vendor-android/src/main/kotlin/com/malinskiy/marathon/android/BaseAndroidDevice.kt#L177

Thank you @Malinskiy for the suggestion. I will explore this suggestion and will let you know. Adding to this, I found one open issue in the google Issue Tracker , which I think might be related to the above issue, as I am having this issue in specific Android API AVD (arm64) images and mentioned observation https://issuetracker.google.com/issues/240463801#comment2 and might be related to having arm64 images and should not be the case with x86 emulator images.

marathon/vendor/vendor-android/src/main/kotlin/com/malinskiy/marathon/android/BaseAndroidDevice.kt

Line 181 in 230315c

val videoSupport = hasScreenRecord && manufacturer != "Genymotion"

here in this line, we are also checking for device manufacturer Genymotion.I executed tests with marathon and was able to record videos on genymotion device and later found that the prop ro.product.manufacturer output to GenyMobile and having variable evaluates to true and therefore video was successfully recorded. Just wanted to confirm is there any specific reason we are having this check in place & can I get rid of this if this is not required.

[Malinskiy]

Genymotion historically didn't allow recording videos using screen record binary. Last time I checked this was around 2019, I'm not a user of genymotion anymore though so maybe this functionality was brought back.

In any case proper detection of supported video sizes and bitrates would solve this problem, but it can only be done via direct access to libstagefright if I remember how AOSP works correctly

[akexorcist]

Genymotion historically didn't allow recording videos using screen record binary. Last time I checked this was around 2019, I'm not a user of genymotion anymore though so maybe this functionality was brought back.

Using Marathon with Genymotion Device Image on AWS EC2 (ARM-based instance). It's work fine, got screen record files from the device.

[kartik1o]

Genymotion historically didn't allow recording videos using screen record binary. Last time I checked this was around 2019, I'm not a user of genymotion anymore though so maybe this functionality was brought back.

Using Marathon with Genymotion Device Image on AWS EC2 (ARM-based instance). It's work fine, got screen record files from the device.

I had observed that the genymotion devices images running recents android versions has manufacturer name as "GenyMobile". Hence, this condition doesn't prevent from recording videos on those devices. For other device, even though they have screen record capability, the above condition doesn't allow recording on those. since, it has "Genymotion" has device manufacturer property.