BoringName

I haven't got my head around what the differences are with -copy options. I'm able to use drm-copy but it produces a small stutter when watching 1080p hevc content whereas drm is very smooth. As previously mentioned, drm-copy does allow mpv to display videos with problematic file widths instead of just a black screen. I don't understand it all enough to know why that is.

I think building a new image is probably beyond me at the moment. I uninstalled the existing headers, rebooted and installed the updated headers and rebooted. The issue persists. I'm just going to give up on it. I don't really need to LCD display to work. I just wanted confirmation I wasn't missing something stupid. Thanks.

This repo is a bit behind what you are running. drm has been changed to v4l2request. I'm going to assume you have hwdec=v4l2request in your mpv.conf file.

Some other info that may be relevant. Pretty much the only thing I could find that seemed to indicate different versions. cat /proc/version Linux Version 6.12.11-edge-sunxi64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT Thu Jan 23 11:23:05 EST 2025 gcc --version gcc (Debian 12.2.0-14+deb12u1) 12.2.0

I currently have a TV box with @Nick A Armbian-unofficial_25.05.0-trunk_x98h_bookworm_edge_6.12.11_xfce_desktop.img. I have installed linux-headers-edge-sunxi64_25.05.0-trunk_arm64__6.12.11 from the same repository. I'm trying to build a custom module to get the LCD working but I keep coming up against a Exec Format Error which implies a mismatch between the build version and the installed version. But I can't find the cause. I have been following the build instructions for tm16xx-display which hasn't been a smooth process. I've had to remove some forward slashes in the Makefile so it would find the drivers/auxdisplay folder and the line-display.mod.c file it created had entries with multiple double quotes that caused errors. I had to change ""LINEDISP"" to "'LINEDISP'" before it would build. I should also mention I have previously tried OpenVFD and come up with the exact same issue so I don't think it's related to tm16xx. uname - r 6.12.11-edge-sunxi64 Vermagic of the module 6.12.11-edge-sunxi64 SMP preempt mod_unload aarch64 uname -a Linux x98h 6.12.11-edge-sunxi64 #1 SMP PREEMPT Thu Jan 23 11:23:05 EST 2025 aarch64 GNU/LINUX I have little experience with building things in Linux. Am I missing something simple? Is "PREEMPT" listed in all caps in uname -a an issue when the vermagic line is lower case? What about mod_unload? Any other ideas? I've been googling all day and got nowhere. Most results show different version between uname and vermagic which isn't the case here as far as I can tell. I guess I just need to know if it's possible to build custom modules with armbian images or if it's something that just doesn't work and I should forget about it. Thanks.

Just some more info I forgot to mention that might help others. I found other repositories for mpv for bookworm that were greater than the version in this repository (35.1) but none of them worked with drm. I believe it's because drm support gets skipped if mpv is built without libdrm being installed. Run mpv --hwdec=help If drm is not listed as one of the options it will not work. You need to find a build with drm support.

Sorry for filling this thread with my issues. I'm calling it quits on this one and I'll just put up with it. It seems the v4l2request/drmprime stuff is a slow moving beast with ffmpeg/mpv and I have no interest in dealing with the dependency rabbit hole building my own versions. I found some references on the mpv github mentioning possible frame size issues so that's probably what causing my problems. I don't expect it will be fixed until ffmpeg upstream is sorted out. Going by current progress rates that's probably 2 years away.... I did find using --hwdec=drm-copy will play the files without producing the driver error but the green issue is still there. Using drm-copy with 1080p videos would be a little choppy though. I did a grep search on the mpv and mesa driver source code and couldn't find any reference to the "rejecting image due to unsupported offset" error so that must be coming from an external library. I did have a small win as installing the backported Mesa driver did fix some slight screen tearing issues I was encountering on 1080p content.

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.

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.

With a lot of trial and error I figured out the issue but not the cause. This seems to only effect HEVC (x265) videos when drm is successfully enabled with MPV from this repository. If I try a different player, they play fine but no hardware acceleration. If I encode the videos to x264 they play but hardware acceleration fails with the following error [ffmpeg/video] h264: v4l2_request_probe_video_device: set controls failed. Invalid argument (22) The issue is the width of the video. Outside of certain ranges it will display a black video (audio works). It doesn't seem to matter what the height is set to. Eg) 704x480, 704x960 image is displayed. 706x480, 706x960 black screen The ranges go for 14 pixels and each range is separated by 50 pixels. eg) widths in the range of 690 to 704 display an image. Widths between 706 and 752 display a black screen. 754 to 768 display an image. It's a strange one.... Here is a list of ranges that work. Any widths outside of these ranges produces a black screen. It only goes up to 1984 but I'm sure the same rules would apply above this value.

I don't like my chances of any resolution to this problem but here goes. I'll start off by saying thanks for providing this repository, I recently went on holidays and was able to use my little magcubic box to watch content off my nas remotely. It was mostly great. One issue I have come across is most of my SD content (ripped from DVD) just displays a black screen. I encode it to 10 bit x265 the same as I do for blurays. Blurays at 1080p play fine, the DVD rips at 480p and 576p just display a black screen, audio works. When comparing them with MediaInfo the only real difference (aside from resolution) is the color primaries, transfer characteristics and matrix coefficient tags. Blurays are bt.709 and the DVD rips are bt.601. Also NTSC vs PAL for the blurays. I've also come across some files that I believe I downloaded at some point that are DVD resolutions, 10 bit x265 PAL that play ok. In MediaInfo these files are missing the all the tags mentioned above. I don't know how this is possible... To troubleshoot I've tried converting a non working file to 25 FPS (PAL) and setting the elements above to bt.709 but no dice. I've run mpv from the terminal in verbose mode and tried to compare a working file to non working file and nothing is really standing out. I think ffmpeg is just serving up black frames with v4l2 in certain circumstances, maybe when the color primaries are bt.601. I'm not overly confident the method I used above to set the bt.709 values would actually work. I installed mplayer and this plays the files ok but doesn't have hardware acceleration. This is why I think the issue is ffmpeg and v4l2. Probably not relevant but 2160p content plays (bt.2020). It really struggles with it but it displays an image. Any ideas would be great. At this stage I'm probably going to take a 10 second clip of a non working file and just run it through bunch of different encode settings until I get something that displays and work backwards from there.

I've been trying to get the LCD working on my box. I've used Nicks image - Armbian-unofficial_25.05.0-trunk_X98h_bookworm_edge_6.12.11_xfce_desktop I've followed instructions for OpenVFD and tm16xx on these forums but both result in an Exec Format Error when I try to install the compiled module. From what I have read this is a version mismatch between the kernal and what the module was built with but when I compare uname -r with the vermagic of the module they match. I initially installed the linux headers from Nick's Github: linux-headers-edge-sunxi64_25.05.0-trunk_arm64_6.12.11. After I got the format error I tried installing headers from Armbian-config but get the same result. Make wouldn't work at all initially until I did a symlink between the relevant folders in usr/src and lib/modules. Maybe that stuffed something up?

Bookworm. But my point was the version 35.1 is what got installed when I ran the scripts in the first post. If the script installed 37 for you because you're on Ubuntu then I probably am on the wrong track. Yes I believe it does this. I was just pointing out that drm_prime works for me but I guess that could just be due to different hardware on the device. I'm not using an Orange Pi.

I was surprised when mine played H265 10 bit. I thought I'd read somewhere v4l2 was limited to 8 bit. Obviously that was incorrect.

I'm very new to Armbian so I could be off track here but I noticed your running MPV version 37. When I ran the instructions for the first time I already had mpv installed (version 40 or something) so it didn't get updated. I ended up uninstalling MPV and running the instructions again. Now I have version 35.1 which fixed the drm_prime errors for me. The version difference could be because you are on 26.2 of Armbian and I'm on 25.05, I haven't got my head around all the different versions of things yet. Maybe try uninstalling MPV and trying the commands again and see what version it gives you.