[Android] non-power of 2 video resolution causing blocky, aliasing like artifacts.

[kajscopic]

Unity version

6000.0.39f1

Unity editor platform

Windows

AVPro Video edition

Ultra

AVPro Video version

3.2.5

Device hardware

Quest 3

Which Android OS version are you using?

15

Unity Graphics API

Vulkan

Video API

media3/ExoPlayer

Texture format

BGRA

Audio output

Facebook Audio 360

Any other Media Player component configuration required to reproduce the issue.

Not really.

Which output component(s) are you using?

Apply to Mesh

Any other component configuration required to reproduce the issue.

Not that i know of.

The issue

We're running 5120x2560 resolution videos on the quest 3 which before didn't give us any issues, upon migrating to unity 6.0 with avpro 3.2.5 we ended up getting strange aliasing issues. we tried checking all the 'obvious' settings, quality settings, URP, filtering (point, bilinear, trilinear) anisotropic filtering, materials in use. nothing seemed to help. but when we rconvert the video to 4096x2048 or to 8192x4096 (with ffmpeg) the problem dissapears, when we convert the video to something arbitrary (also with ffmpeg) to like 5.7k, the problem stays, we did this to exclude the conversion from fixing the problem. it seems that the change from gles3 to vulkan might not like the non power of 2 video textures, or maybe it's another system that doesn't like the non power of 2 video files.

Media information

logcat.log

General
Format : Matroska
Format version : Version 4
File size : 39.7 MiB
Duration : 37 s 211 ms
Overall bit rate : 8 953 kb/s
Writing application : Lavf58.20.100
Writing library : Lavf58.20.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L6
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 36 s 209 ms
Width : 5 120 pixels
Height : 2 560 pixels
Display aspect ratio : 2.000
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 155 r2917 0a84d98
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Audio
ID : 2
Format : Opus
Codec ID : A_OPUS
Duration : 37 s 211 ms
Channel(s) : 9 channels
Sampling rate : 48.0 kHz
Bit depth : 32 bits
Compression mode : Lossy
Writing library : REAPER
Default : No
Forced : No

Logcat output

it's in the media info, too many characters, but here are some things chatgpt picked out.

🔶 1. unknown/unsupported param ... warnings
Examples:
unknown/unsupported param input.buffers.max-size index = 0xC200081E

unknown/unsupported param raw.max-size index = 0x52002003

🔍 What it means:
The decoder (likely a Qualcomm V4L2-based codec) received parameters it doesn't recognize or support.

🎥 Possible impact:
Fallback to default buffer sizes (e.g. slightly less efficient memory allocation).

No visible artifacts, but may increase memory usage or reduce decoding performance in edge cases (e.g. high bitrate or low-end hardware).

🔶 2. failed to read private_transcode_metadata_stat
🔍 What it means:
An attempt to read a private metadata field failed — usually related to internal statistics used for debugging, transcoding, or hardware optimization.

🎥 Possible impact:
No impact on playback quality.

Might disable some performance tuning or hardware telemetry (e.g. for adaptive quality).

🔶 3. ? is not a supported pixel format!
🔍 What it means:
The decoder received a request for a pixel format that it couldn't identify or handle.

🎥 Possible impact:
Could fallback to a different format (e.g. NV12 instead of YUV420).

If there's a mismatch between decode output and surface input format, you might see color distortion or a black screen if the renderer can’t interpret the data.

In your case, the log later shows it settles on VENUS_NV12_UBWC, so the fallback was successful.

🔶 4. setOutputSurface -- failed to set consumer usage (6/BAD_INDEX)
🔍 What it means:
The output surface tried to set a specific buffer usage mode (e.g. for hardware acceleration), but the consumer (your rendering surface or texture) didn’t support it.

🎥 Possible impact:
Playback will still work, but without certain optimizations like zero-copy decoding or HDR support.

This may cause slightly higher CPU/GPU usage, or drop frames under stress.

🔶 5. Unknown AVC level: 60
🔍 What it means:
Your video stream uses an AVC/H.264 profile level that the decoder doesn’t officially recognize (level 6.0 is beyond typical limits like 5.2).

🎥 Possible impact:
Might ignore some constraints like bitrate or resolution limits.

If decoder isn’t fully compatible, you might see:

Jerky playback

Decoding errors under load

Black frames if frame size exceeds hardware limits

You got lucky: your hardware accepted the resolution despite this level mismatch.

✅ Overall Summary
Issue	Likely Cause	Possible Visible Effects
unsupported param	Codec ignoring unknown config	None or minor inefficiencies
pixel format not supported	Fallback to default format	Color shift, black screen (not in your case)
setOutputSurface failed	Surface/decoder mismatch	Higher GPU/CPU usage
AVC level: 60 unknown	High profile H.264 level	Risk of decoding limits hit
transcode_metadata_stat error	Missing optional info	No real impact
🛠️ What you could do (if you want to optimize):
Downscale slightly (e.g. 4096x2048) if high-res is not essential.

Re-encode using H.264 level 5.2 or below.

Ensure your decoder (especially on Android/Meta) officially supports 5K+ resolutions.

But honestly? If it's working and stable, you're in the clear. Let me know if you're seeing playback issues like stutters, black frames, or corruption — then we’d dive deeper.

Want me to help validate the optimal settings for encoding this kind of 5K footage?

[Chris-RH]

Out of interest, which versions of unity and AVPro video were you using previously?
It does seem to be a vulkan thing, so I would advise sticking with openGLES if that works for you.

[raymondscopiclabs]

Out of interest, which versions of unity and AVPro video were you using previously? It does seem to be a vulkan thing, so I would advise sticking with openGLES if that works for you.

Hi Chris, I also worked on this project, we tested this in Unity 2022.3.20f1 using the AVProVideo v3.2.1 Trial package with vulkan. In this version our 5.1k videos worked as expected. We switched to vulkan because we wanted to use the Meta passthrough feature for our project.

[Chris-RH]

If both had been using Vulkan, it would be interesting to know if it was the change to Unity 6 or the upgrade from AVPro Video 3.2.1 to 3.2.5 that caused this. I know we have added some improvements in Vulkan support in the most recent updates.

[raymondscopiclabs]

I luckily still had the older branch with this version of the app. I upgraded the AVPro 3.2.1 trial version to AVPro 3.2.5 Ultra, after upgrading the same issue has appeared in Unity 2022.3.20f1. It seems likely that the issue was caused by a newer version of AVPro.

If you want i can also provide videos of the 2 versions for comparison.

[Chris-RH]

It would be helpful if you could share the video file that you are testing with, as we don't have any np2 videos here to test with. Please email unitysupport@renderheads.com :)

[Chris-RH]

email received, thank you