X265 decoding broken on Android (green screen)

ROCK 5 Series
1

Hello,

As a continuation of this thread, as it’s really off the previous topic: [ROM] ROCK 5B Android 12.1 rkr10 GoogleTV I wanted to do some more investigation about the files in which HEVC decoding on Android is borked (green screen bug). It seems to happen both on the Android version by @thc013 from the linked thread, as well as Radxa’s android build 20221129 (https://github.com/radxa/manifests/releases/download/Rock-android12-20221201/Rock5B-Android12-rkr12-Tablet-20221129-gpt.zip)

Someone just messaged me about having fixed this but if anyone is interested this is MediaInfo from some files that work:


And these don’t work:


Any ideas about the cause?

2

can see that the file impacted were x265 encoded with main10 color profile. simple way to encode this file were by using handbrake, select “H.265 10bit (x265)” codec. main8 x265 encoded file are not impacted.

3

Aren’t all of these encoded with main10?

4

different color space possibly (rec2020/bt2020 for hdr?), while the default were using bt709/rec709

5

You’re on to something, maybe BT.2020 works and others have trouble. I’ll check on the firmware which has it fixed supposedly.

6

I tried encode non hdr content with bt2020 colorspance, green screen still persist.

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 5 s 280 ms
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 0)
Bit depth : 10 bits
Writing library : x265 3.5+1-f0c1022b6:[Windows][GCC 10.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=20 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=15 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=2 / selective-sao=4 / no-early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=14 / colormatrix=9 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : BT.2020 (10-bit)
Matrix coefficients : BT.2020 non-constant

1 Like
7

The same issue occurs on another board too, the Orange Pi 5.

I discovered that any and all 10 Bit X265 files will result in a green screen, except for those with HDR, which play perfectly.

1 Like
8

submitted issue on rockchip-linux github:

feel free to include application log if errors were noticed

1 Like
9

did you try the latest atv or gtv ?
it from rkr12 sdk and another mpp and vpu

av1 still doesnt wanna be friends but with rest no issues

and on android it involves more as mpp :wink:

10

didnt work :wink:
personally i didnt bother with av1, contents are pretty much limited

11

so if that didnt work

you can use the same mpp from the repo in linux it is the same so if it also there doent work it is mpp

but think it is more in 1 of the other libs like the osal codecs2 folder

and kodi is not suited to test video use the default rkmediaplayer

12

i think this is more into android mediacodec API specific, rockchip API seems to be fine (tested with mx-player HW(non-plus) decoder). but hey if they could get avc and vp9(for obvious reason,youtube) to work, hevc should be do-able too right :smiley:

anyway there is reason why i cant use rkmediaplayer, the function is too limited. might as well live with software decoding instead.