Double checked with fresh image Armbian imager -> Odroid -> XU4 -> Armbian Trixie minimal. Works as expected.

A bit more info. I updated the mesa drivers with backport drivers to 25.0.7. Now videos outside of the ranges I listed earlier produce an error when trying to play with mpv. Mesa: error: panfrost: rejecting image due to unsupported offset or stride alignment Of course googling that error comes up with nada. All videos inside the ranges continue to play fine. If I scale the video down (from 706x480 to 704x480) when encoding to bring it within the working ranges. ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -i "input.mkv" -pix_fmt yuv420p -vf scale=704x480 "output.mkv" The video will play in mpv but still has the green/purple issue. This command produces a playable video with no green/purple issue ffmpeg -i "input.mkv" -vf scale=704x480 "output.mkv" Whatever the issue seems to be effecting both ffmpeg and mpv with certain video widths. Fmmpeg is outputting video with screwed up colours and mpv causes a driver error. mpv uses ffmpeg under the hood so it makes sense it's effecting both of them. I don't suppose anyone using this repository with a mali-g31 gpu could try and play a 706x480 file to see if it works ok and confirm I'm not crazy? You need to make sure it says "Using hardware decoding (drm)" in the terminal when mpv is launched. I guess there is a chance it's just a driver issue and not related to this repository at all.

One option is to start a crowdfunding campaign. You can review how previous campaigns were structured here: https://forum.armbian.com/crowdfunding/ As a rough estimate, bringing a new board or image to a sustainable level typically requires around $5,000 just to cover the initial development effort - when dealing with something simple. Running a campaign also gives a clear picture of how challenging it is to secure funding for this type of work. However, initial development is only part of the cost. To avoid creating another long-term maintenance burden (a “support black hole”), an additional $5,000–$10,000 is usually needed to cover ongoing maintenance, updates, CI resources, testing, and long-term support. It’s also important to emphasize a general principle: you should ideally choose hardware that is already officially supported, rather than expecting support to be built around hardware after purchase. Supporting embedded devices sustainably requires planning, funding, and long-term commitment — it doesn’t happen automatically. In short - it’s possible, but it requires realistic budgeting and shared responsibility.

Feel free to reach out and become a partner: https://www.armbian.com/partners/ @Bruno Santos

Thanks but they didn't make any difference. I have confirmed it's an issue with the ffmpeg output when drm is enabled. I used the following to extract a single frame from a video using drm. ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -ss 00:00:10 -i "input.mkv" -frames:v 1 -q:v 2 "output%03d.jpg" It produces an image but it's nearly all green. If I remove the -hwaccel drm option the image produced is correct. I tried PNG format as well to rule out a format issue and got the same result. After the above result I tried ffmpeg -hwaccel drm -hwaccel_device /dev/dri/renderD128 -i "input.mkv" "output.mkv" As it's using default settings this converts the video to x264 output.mkv still plays as a black screen in mpv but when I play it with ffplay I get a video covered in green with splashes of purple here and there. Edit: I should clarify you can still make out the video contents, it's just the colours are messed up. It's mainly all green with purple flickers occasionally. So I guess I need to play around with ffmpeg.... the last time I tried to build my own it wasn't a fun time. Also unrelated to this issue but I found the cause of the invalid argument 22 error I mentioned earlier when playing x264 videos. 10 bit x264 videos are unsupported. Using -pix_fmt yuv420p when encoding changes it to an 8bit video which plays successfully in mpv with drm. I don't normally have 10bit x264 but when I was testing I converted a x265 to x264 and it must have maintained the pixel format. Edit: By adding the --vf=format=rgba to the mpv command line I can get mpv to play the file like ffplay does. Lots of green and purple but at least it displays an image instead of a black screen. I tried a bunch of different formats but they all come out exactly the same, except for --vf=format=gray. This plays a perfect black and white version of the video. For some frames the colours are correct in places but there is a lot of green blocky squares everywhere. So I don't think it's a format issue, I think ffmpeg is just screwing up the colour space for parts of the frame for certain width videos when drm is used.