google/android-riscv64

Question about video play

Closed this issue · 11 comments

rayeh5 commented

When I play video, the output color seems wrong?
Please refer to the attachment.
Thanks for your time.

video_pic

what format of video? played with what?

rayeh5 commented

the video file is as attachment.
I push into the cuttlefish, then use mouse to click it to play this file.
https://github.com/google/android-riscv64/assets/5005947/9f10b7c7-7966-4f3e-8742-48bac769d5ff

negge commented

Hi @rayeh5, I see in #38 (comment) that a fix for libyuv was cherrypicked into AOSP. Can you rebuild and check if this fixes the issue for you?

rayeh5 commented

Thanks for the information.
I think the repo is up to date now, but the problem is still existed.
Any idea?
By the way, the video file's format is mp4.

commit 01fadae8618ea360608cc52c823a022c48f855b5 (HEAD -> change-2622518)
Author: Vignesh Venkatasubramanian vigneshv@google.com
Date: Mon Jun 12 21:28:09 2023 +0000

libyuv: Update to r1871 (2a6cb743)

Changes from upstream:
https://chromium.googlesource.com/libyuv/libyuv/+log/d53f1bee..2a6cb743

The intention of the CL is to import the functions necessary to
enable AV1 (and AVIF) 12-bit color conversion.

rayeh5 commented

Any comment for this issue? It seems the "Blue" color is missing when play video file.

rayeh5 commented

I build aosp_cf_x86_64_phone-userdebug, aosp_cf_riscv64_phone-userdebug and aosp_cf_arm64_phone-userdebug by using the same source, the output color of video is correct for x86_64 version, the arm64 and riscv64 are the same with wrong color.
Any comment?

@rayeh5: Could you share more information about how you are launching the Cuttlefish instances, about the enviroment the Cuttlefish instances are running in (mostly just interested in whether or not you are using the default --gpu_mode=auto and whether or not it is detecting acceleration support), and about how you are interacting with the Cuttlefish instances (which VNC client)?

image

^ This is aosp_cf_arm64_phone-userdebug using cvd start --gpu_mode=guest_swiftshader --vm_manager=qemu_cli and interacting with the instance via TightVNC.

rayeh5 commented

The following test is for riscv64 version, I believe it's same for arm64.
The problem should be caued by "--gpu_mode=drm_virgl".
By using "--gpu_mode=guest_swiftshader" and TightVNC, the "black and white" video is normal.
Use "scrcpy" program to connect to Cuttlefish, the video is normal.
But with color video, the TightVNC has problem to show correct color.
The TightVNC shows the following message:

Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name "QEMU (cvd-1)"
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Same machine: preferring raw encoding

Ack, thanks for the info. I might not get to looking at this until next week.

Checking in to Ack again. I think we can move further discussion to https://issuetracker.google.com/issues/297192837 and close this issue on Github since it does not appear to be riscv specific (affects both arm64 and riscv64 per rayeh5's comment above) and is likely a Cuttlefis/VirglRenderer interaction issue.

rayeh5 commented

got it and thanks!