ag123 Posted July 4 Author Posted July 4 this is somewhat 'off-topic' but still relevant to 'orange pi zero 3' If Orange Pi Zero 3 is operated in warm climates (e.g. room temperature 30 deg C etc) , it can at times run up to like 60 deg C. this is in open still air adding a fan blowing at it reduce that by some 20 deg C to 40 deg C ! And this is my ghetto fan setup, no fancy case, no heatsink nothing, just a single long machine screw that lifts it up checking temperatures is easy > armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:03:39 480 MHz 0.00 0% 0% 0% 0% 0% 0% 40.8 °C 0/7^C strictly speaking, 60 deg C is 'nothing to scream about' , I've a Rpi 4 hitting up 80 deg C and it throttles. similarly use a fan blowing at it + a heat sink over the cpu, drastically reduce running temperatures. for 'occasional' use, I don't think it is necessary to have a fan blowing at the Orange Pi Zero 3. I think it is feasible to run at lower temperatures if I disable and unclock the GPU and HDMI, but for now I'm not sure how to go about doing that. Initially, I'm thinking maybe the wifi is causing it, but now I don't think so, it is moderately likely the gpu is heating it up a bit. And still air don't seem to dissipate heat very well. 0 Quote
ag123 Posted July 7 Author Posted July 7 just like to say that the recent images works just well _ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (bookworm) Support: for advanced users (rolling release) IPv4: (LAN) xxx.xxx.xxx.xxx (WAN) yyy.yyy.yyy.yyy IPv6: fd00:xxxx:xxxx::xxxx:xxxx (WAN) xxxx:xxxx::yyyy:yyyy WiFi AP: SSID: (ssid), Performance: Load: 2% Uptime: 3:50 Memory usage: 4% of 3.83G CPU temp: 41°C Usage of /: 3% of 58G RX today: 7 MiB Commands: Configuration : armbian-config Monitoring : htop 0 Quote
ag123 Posted July 12 Author Posted July 12 thread about video in case anyone is looking for it and a recent 'success story' 0 Quote
TRay Posted July 12 Posted July 12 On 6/29/2025 at 7:59 AM, TRay said: Will armbian-config be fixed for OZPI v3 etc. problem using overlay-prefix in device tree? https://github.com/armbian/configng/issues/592 @Igor thank you for fixing overlay-prefix problem in current armbin-config now on OZPI V1 and V3 overlays in armbianEnv.txt are without prefix 0 Quote
robertoj Posted July 14 Posted July 14 On 7/12/2025 at 3:27 AM, ag123 said: and a recent 'success story' My story is definitely NOT a success story I see the media.patches in the cache folder, I compile armbian edge, but the image didn't contain the cedrus+v4l2 kernel modules I need for decoding acceleration 0 Quote
ag123 Posted July 15 Author Posted July 15 Quote * mpv plays most mp4s VERY SMOOTHLY BUT WITH 100% CPU oops, I missed reading that 100% cpu, but it is ok it is a a53 after all 😅 videos I'd guess is still 'difficult' on z3, accordingly there is some support for gpu vector graphics but I'd guess mostly just triangles. video decoding can be done with just neon (vector computation) , but i'd guess there is still limited access to video decoding hardware. using neon is likely to give that 100% cpu reading as the cpu is busy literally, using real video hardware would be 'invisible' in a sense, the cpu usage may look low but that one won't see that the video hardware itself may after all be reading 100%. 0 Quote
robertoj Posted July 15 Posted July 15 (edited) 12 hours ago, ag123 said: oops, I missed reading that 100% cpu, but it is ok it is a a53 after all 😅 videos I'd guess is still 'difficult' on z3, accordingly there is some support for gpu vector graphics but I'd guess mostly just triangles. video decoding can be done with just neon (vector computation) , but i'd guess there is still limited access to video decoding hardware. using neon is likely to give that 100% cpu reading as the cpu is busy literally, using real video hardware would be 'invisible' in a sense, the cpu usage may look low but that one won't see that the video hardware itself may after all be reading 100%. Thank you for replying. I run xscreensavers-gl in a window and it always gets 30FPS with <10% CPU in my opiz3, I even show 3D models in F3D... so I am getting 3D MESA acceleration in HDMI and SPI-LCD displays. If the video decoding in my opiz3 is using ARM NEON instructions, then I am fortunate I have that, at least (note: this is possible without needing ffmpeg-v4l2request) I will have to re-check how I was successful with 1080P H264 acceleration last year (I was even getting temporary glitches and pink hues sometimes). Edited July 15 by robertoj 0 Quote
ag123 Posted July 15 Author Posted July 15 Arm Neon is quite a thing, SIMD https://developer.arm.com/documentation/102159/latest/ https://github.com/thenifty/neon-guide and accordingly aarch64 (e.g. Cortex A53, A55, A72, A75, A76 etc etc i.e. arm V8a onwards have them) https://developer.arm.com/documentation/102474/0100/Fundamentals-of-Armv8-Neon-technology the H618 is an A53 and hence should have it. it is a good 'replacement' for proprietary hardware etc as this like Intel's sse, avx , simd are defiined and standardized by Arm. Hence, they'd work if programs are coded and compiled to use them. Accordiingly, the pripietary video hardware is still undocumented (at least not publicly accessible), and most of that works are reverse engineered and incomplete. apps written to use Neon SIMD would however 'just works' and accelerated by virtue that it is SIMD. 0 Quote
ag123 Posted July 16 Author Posted July 16 ok we have a cheap SBC Z3 H618, but we'd still want to run it as like a supercomputer https://linux-sunxi.org/Benchmarks#Linpack download https://www.netlib.org/benchmark/linpackc.new save as linpack.c makefiile all: linpack-noopt linpack-o3 linpack-noopt: linpack.c gcc -o $@ $^ linpack-o3: linpack.c gcc -O3 -o $@ $^ -lm -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations clean: linpack-noopt linpack-o3 rm $^ .PHONY: all clean ok, for your convenience it is in the attached zip file. to unzip you may need (as sudo): apt install zip unzip for the compilers you may need apt install build-essential $ make gcc -o linpack-noopt linpack.c gcc -O3 -o linpack-o3 linpack.c -lm -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations $ ./linpack-noopt Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 32 0.68 88.14% 2.66% 9.20% 71117.671 64 1.36 88.13% 2.66% 9.21% 71103.230 128 2.72 88.14% 2.66% 9.20% 71118.447 256 5.44 88.14% 2.66% 9.20% 71117.368 512 10.89 88.14% 2.66% 9.20% 71118.505 Enter array size (q to quit) [200]: q $ ./linpack-o3 Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 128 0.53 86.33% 2.89% 10.78% 374433.231 256 1.05 86.33% 2.88% 10.79% 374573.654 512 2.10 86.34% 2.88% 10.79% 374443.201 1024 4.21 86.32% 2.88% 10.80% 374574.751 2048 8.42 86.32% 2.88% 10.80% 374612.768 4096 16.83 86.33% 2.88% 10.79% 374574.926 Enter array size (q to quit) [200]: q This is single core benchmark, apparently gcc -o3 does Neon SIMD linpack.zip 0 Quote
robertoj Posted July 16 Posted July 16 (edited) I don't even have a reference viewpoint what should I start comparing? I read claims that Python3-numpy, python3-opencv are highly optimized, but I never researched HOW OPTIMIZED I have also heard that DRM can help accelerate machine learning https://www.youtube.com/watch?v=NQz6VqvtehI&t=5m7s Edited July 17 by robertoj 0 Quote
Gabriel Negrisiolo Righi Posted July 17 Posted July 17 (edited) For those who are seeking to enable video decode i've been able to get it working with those libs https://www.elektroda.pl/rtvforum/topic4018092.html#20840047 download h618_hwdec.tar.gz and replace the libs and add "extraargs=cma=256M" to your /boot/armbianEnv.txt , mpv works flawlessly with --hwdec=drm --profile=fast, scrcpy is also fast and with minimal cpu usage... i'm also using rolling edge kernel, and latest 25.2 mesa from source libva-v4l2-request-HACK_HEVC.zip Edited July 17 by Gabriel Negrisiolo Righi include info 1 Quote
ag123 Posted July 17 Author Posted July 17 @robertoj Quote I don't even have a reference viewpoint what should I start comparing? I read claims that Python3-numpy, python3-opencv are highly optimized, but I never researched HOW OPTIMIZED I have also heard that DRM can help accelerate machine learning https://www.youtube.com/watch?v=NQz6VqvtehI&t=5m7s well, Neon SIMD isn't just useful for that matrix math, it is useful e.g. as a video decoder/encoder in place of specialized on chip video hardware. it could partially explain the 'better performance' of mpv (https://mpv.io/) e.g. if mpv is after all built with -o3 or that mpv uses a library that is optimised iwth Neon SIMD, it could likely practically see a performance as the on-chip proprietary video hardware which is not publicly documented. with an apparent 100% cpu usage if all 4 cpu cores are used with Neon SIMD. I think I once chanced upon an Rpi forum comment about shifting the codes to Neon SIMD instead instead of using propietary video hardware, partly as these 'small' chips has 'limited' capabilities for on chip video processing etc. it isn;'t really a bad thing if after all we'd use say an Opi Z3 as a 'dedicated' video streamer. A thing is at 100% cpu, non compute threads may struggle to get a slot to run at times, it may take setting 'nice' levels so that some threads get a higher priority. I've been thinking about running a (crypto coin) miner on it, probably would do that some time. They certainly don't get close to say even a Haswell, or Ryzen or even a 'low end gpu' but that they are faster than the 'older' 'smaller' chips for a comparison, the quoted 'old' figures https://linux-sunxi.org/Benchmarks#Linpack -mcpu=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=hard -funsafe-math-optimizations -fno-fast-math Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 16 0.61 88.52% 6.56% 4.92% 37885.057 32 1.21 85.12% 2.48% 12.40% 41459.119 64 2.43 93.83% 2.47% 3.70% 37561.254 128 4.86 91.77% 2.47% 5.76% 38381.368 256 9.70 92.06% 2.89% 5.05% 38173.000 512 19.41 91.29% 2.47% 6.23% 38634.432 mcpu=cortex-a8 -mtune=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=hard -funsafe-math-optimizations -fomit-frame-pointer -ffast-math -funroll-loops -funsafe-loop-optimizations Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 16 0.53 90.57% 1.89% 7.55% 44843.537 32 1.05 90.48% 3.81% 5.71% 44390.572 64 2.13 90.14% 2.35% 7.51% 44615.905 128 4.23 90.54% 3.07% 6.38% 44390.572 256 8.46 90.19% 2.84% 6.97% 44672.596 512 17.03 90.55% 2.76% 6.69% 44250.892 vs that above is like 8x - 10x improvements on a single core 0 Quote
ag123 Posted July 17 Author Posted July 17 tried mining feathercoin, git clone https://github.com/ghostlander/cpuminer-neoscrypt lots of missing dependencies to build that apt install automake autoconf-archive pkg-config libtool libcurl4-openssl-dev but once done it is autogen.sh, configure, make next register on https://www.mining-dutch.nl/ then run ./minerd -D --algo=neoscrypt --url=stratum+tcp://mining-dutch.nl:9993 -u username.worker1 -p d=10 Spoiler Hash: 020E9F4B68201E05469CC87039286A9EEFAFB6525E9CDDAD40E4DCFC6D950000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:06] thread 2: 537 hashes, 1.097 KH/s [2025-07-17 20:07:06] accepted: 14/14 (100.000%), 4.398 KH/s (yay!!!) [2025-07-17 20:07:14] DEBUG (little endian): hash <= target Hash: FD8193D5659404573894CC22F8A37859A2347842E382CCF151747A0E34220100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:14] thread 1: 9481 hashes, 1.100 KH/s [2025-07-17 20:07:14] accepted: 15/15 (100.000%), 4.397 KH/s (yay!!!) [2025-07-17 20:07:18] DEBUG (little endian): hash <= target Hash: 9B92D3883EA6CE4BC66BE97CF9CDC6E8C51B0D28B8C3D7F2BA28B8C58D310100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:18] thread 2: 13983 hashes, 1.100 KH/s [2025-07-17 20:07:18] accepted: 16/16 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:07:32] DEBUG (little endian): hash <= target Hash: 3FC00FD320605941571915FC723A4CBB2C9E798552E309C980F333CA76B40000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:32] thread 1: 20346 hashes, 1.101 KH/s [2025-07-17 20:07:32] accepted: 17/17 (100.000%), 4.401 KH/s (yay!!!) [2025-07-17 20:07:34] thread 3: 66030 hashes, 1.100 KH/s [2025-07-17 20:07:36] DEBUG (little endian): hash <= target Hash: 787E9A8E6CF0D6293659419BA9963ED809F7D606A2AD8E879968A5B075620000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:36] thread 1: 4421 hashes, 1.100 KH/s [2025-07-17 20:07:36] accepted: 18/18 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:07:42] DEBUG (little endian): hash <= target Hash: 27163C9021EAE5D4D5D458F384751990AE336F19BD3AC8D980AA97C55A940000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:42] thread 3: 8654 hashes, 1.101 KH/s [2025-07-17 20:07:42] accepted: 19/19 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:08:00] thread 0: 65995 hashes, 1.100 KH/s [2025-07-17 20:08:18] thread 2: 65977 hashes, 1.100 KH/s [2025-07-17 20:08:36] thread 1: 65992 hashes, 1.100 KH/s [2025-07-17 20:08:37] DEBUG (little endian): hash <= target Hash: 037AD1DB8D7C7FAB0E022F8541BA34D67A7E9B3695B396FAF84C6D47AD950000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:08:37] thread 0: 40427 hashes, 1.100 KH/s [2025-07-17 20:08:37] accepted: 20/20 (100.000%), 4.401 KH/s (yay!!!) [2025-07-17 20:08:39] DEBUG (little endian): hash <= target Hash: 5FBB0159477A05E1324B6A3D240B89DAEDF34A83A8AA78FE155FA86DE3140100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:08:39] thread 3: 62568 hashes, 1.101 KH/s [2025-07-17 20:08:39] accepted: 21/21 (100.000%), 4.401 KH/s (yay!!!) a whopping 1.1 k hash/s on each core, well not very impressivve, but it mines i think this is no Neon SIMD Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 20:22:02 1416 MHz 3.90 100% 0% 0% 99% 0% 0% 53.2 °C 0/7 20:22:07 1416 MHz 3.91 100% 0% 0% 99% 0% 0% 53.2 °C 0/7 20:22:12 1416 MHz 3.92 100% 0% 0% 99% 0% 0% 53.4 °C 0/7 ^ this is with the fan on optimise it a little in makefile #CFLAGS = -g -O2 CFLAGS = minerd_CPPFLAGS = -O3 -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations Spoiler [2025-07-17 20:41:42] DEBUG (little endian): hash <= target Hash: 02D285CA9C499E30195BD3EC4F4DF544D03EDDC7A00DFC0D255EB1E7BA160000x0 Target: 0000000000000000000000000000000000000000000000000000008099190000x0 [2025-07-17 20:41:42] thread 1: 19364 hashes, 1.127 KH/s [2025-07-17 20:41:42] accepted: 1/1 (100.000%), 1.127 KH/s (yay!!!) [2025-07-17 20:41:54] thread 3: 32766 hashes, 1.128 KH/s [2025-07-17 20:41:54] thread 0: 32766 hashes, 1.127 KH/s [2025-07-17 20:41:54] thread 2: 32766 hashes, 1.124 KH/s [2025-07-17 20:42:42] thread 1: 67603 hashes, 1.127 KH/s [2025-07-17 20:42:53] thread 3: 67650 hashes, 1.128 KH/s [2025-07-17 20:42:54] thread 0: 67639 hashes, 1.127 KH/s [2025-07-17 20:42:54] thread 2: 67439 hashes, 1.124 KH/s [2025-07-17 20:43:42] thread 1: 67627 hashes, 1.128 KH/s well, just a very minor 0.025 k hash/s improvement per core. perhaps it already has Neon SIMD or that it needs 'hand optimization', that is hard. 0 Quote
Nick A Posted July 17 Posted July 17 (edited) If you are having trouble with hardware decoding. You need to disable the compositor. Follow jock’s setup instructions in the link below. Use this command to restart xfwm4 with compositor disabled. killall xfwm4 && xfwm4 --compositor=off & Edited July 18 by Nick A 0 Quote
robertoj Posted July 18 Posted July 18 Thank you Nick I tried again with compositor off I still get: [vd] Unsupported hwdec: drm [vd] Using software decoding. https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/page/4/ 0 Quote
Gabriel Negrisiolo Righi Posted July 19 Posted July 19 i've got working with compositor turned on 0 Quote
robertoj Posted July 19 Posted July 19 (edited) It turns out I was closer than I thought... thank you! Edited July 20 by robertoj 0 Quote
robertoj Posted July 19 Posted July 19 9 hours ago, Gabriel Negrisiolo Righi said: i've got working with compositor turned on I started building mesa 25.2 according to https://docs.mesa3d.org/install.html When I started meson, it complained about meson-1.0.1 is too old (Bookworm)... needs 1.4.0 Trixie will provide meson 1.7... is this what you did? Start with a self built Armbian-Trixie? When you type "replace the libs", do you mean to uninstall debian package, and install the just compiled source? libva2 - Video Acceleration (VA) API for Linux -- runtime Is this independent from ffmpeg (I only see libav in ffmpeg, not libva) Does mpv need any special configuration? 0 Quote
Gabriel Negrisiolo Righi Posted July 19 Posted July 19 (edited) Quote I actually dont remember the exact order of install, but from what i can recall first i compiled and installed libva-v4l2-request-HACK_HEVC.zip and followed that tutorial then i downloaded h618_hwdec.tar.gz from https://www.elektroda.pl/rtvforum/topic4018092.html#20840047, those are the libs i replaced in /lib/aarch64-linux-gnu/ install latest edge kernel from armbian-config (or enable rolling updates), download kernel hearders and enable gpu in device tree overlays to compile mesa first install deps than creat a python venv in mesa src directory to download latest meson in it sudo apt-get install bison build-essential ccache clang cmake flex git glslang-tools libclang-dev libdrm-dev libelf-dev libexpat1-dev libgl1-mesa-dev libgles2-mesa-dev libgoogle-perftools-dev libgtk-3-dev libllvm-18-dev libomxil-bellagio-dev libpciaccess-dev libsensors-dev libspirv-tools-dev libunwind-dev libva-dev libvdpau-dev libvulkan-dev libwayland-dev libx11-dev libx11-xcb-dev libxatracker-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0-dev libxcb-shm0-dev libxcb-sync-dev libxcb-xfixes0-dev libxdamage-dev libxext-dev libxfixes-dev libxrandr-dev libxshmfence-dev libxxf86vm-dev libzstd-dev llvm-18-dev meson ninja-build pkg-config python3-mako python3-pil wayland-protocols python3-venv python3 -m venv mesa_venv source mesa_venv/bin/activate pip3 install meson but if i tried to compile from inside the venv i was gettin a mako version error so i exited the venv (just open another terminal window) used this exact command to be able to build from outside the python3 venv PYTHON=~/src/mesa/mesa_venv/bin/python3 ~/src/mesa/mesa_venv/bin/meson setup build -Dbuildtype=release -Dprefix=/usr -Dgallium-drivers=panfrost -Dvulkan-drivers=panfrost -Dplatforms=x11 -Dvideo-codecs=all you need to add wayland to platforms if you're using it, i'm not (replace '~/src/mesa/mesa_venv/bin/python3' and '~/src/mesa/mesa_venv/bin/meson' with the path where you cloned the source...) install any other dependencies it complains about then install with sudo ninja -C build install you can confirm with glxinfo -B gabriel@orangepizero3:~/$ glxinfo -B name of display: :0.0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: Mali-G31 (Panfrost) (0xffffffff) Version: 25.2.0 Accelerated: yes Video memory: 3922MB ... i don't know if that libva hack is working but vainfo recognize gabriel@orangepizero3:~$ LIBVA_DRIVER_NAME=v4l2_request vainfo libva info: VA-API version 1.20.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.20 (libva 2.12.0) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD and finally mpv (with yt-dlp installed) gabriel@orangepizero3:~/$ mpv --hwdec=drm --profile=fast https://www.youtube.com/watch?v=Dyzf2evNjwc (+) Video --vid=1 (*) (h264 1920x1080 29.970fps) (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) File tags: Uploader: Zen Mechanics Channel_URL: https://www.youtube.com/channel/UCC8n8afKsdaYuI7Pr0J4pgA Using hardware decoding (drm). AO: [pulse] 48000Hz stereo 2ch float VO: [gpu] 1920x1080 drm_prime[nv12] it is a bit confusing but i hope it helps... i also recommend this moded mpv handler with youtube playlist and mpv prefetch queueing support: https://github.com/gabreek/mpv-handler-queue Edited July 19 by Gabriel Negrisiolo Righi 0 Quote
robertoj Posted July 20 Posted July 20 Successful playing of H264 1080p mp4 Orange pi zero 3, 1GB Self-built Bookworm, with XFCE desktop Linux edge 6.15.4 No changed linux configurations Using ffmpeg+libraries provided in the first post of https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ (you can even install all the bookworm ffmpeg, mpv, then when you add the new repository, update and upgrade, apt will replace the packages with their ffmpeg-v4l2request equivalents) Testing 1080P H264 (warning, some mp4's will actually be AV1 codec), checked with VLC Compositor on or off, doesn't make a difference. Video plays at full 30 fps To avoid video glitches during window resizing: add "extraargs=cma=256M" in /boot/armbianEnv.txt With hwdec=drm-prime, CPU is 50% in all 4 cores With hwdec=drm, CPU is 10% or less in all 4 cores Without HW acceleration, CPU is 100% in all 4 cores with many skipped frames mpv.conf and mpv log: Reveal hidden contents Spoiler roberto@orangepizero3:~$ cat /etc/mpv/mpv.conf hwdec=drm drm-drmprime-video-plane=primary drm-draw-plane=overlay roberto@orangepizero3:~$ roberto@orangepizero3:~$ roberto@orangepizero3:~$ DISPLAY=:0.0 mpv -v windwaker1080p.mp4 [cplayer] Command line options: '-v' 'windwaker1080p.mp4' [cplayer] mpv 0.35.1 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects [cplayer] built on UNKNOWN [cplayer] FFmpeg library versions: [cplayer] libavutil 57.28.100 [cplayer] libavcodec 59.37.100 [cplayer] libavformat 59.27.100 [cplayer] libswscale 6.7.100 [cplayer] libavfilter 8.44.100 [cplayer] libswresample 4.7.100 [cplayer] FFmpeg version: 5.1.6-0+deb12u1 [cplayer] [cplayer] Configuration: meson configure build -Dprefix=/usr -Dbuildtype=plain -Doptimization=plain [cplayer] List of enabled features: alsa av-channel-layout caca cdda cplayer cplugins cuda-hwaccel cuda-interop dmabuf-interop-gl dmabuf-interop-pl dmabuf-wayland drm drm-is-kms dvbin dvdnav egl egl-drm egl-helpers egl-x11 ffmpeg ffnvcodec gbm gl gl-wayland glibc-thread-name glob glob-posix gpl iconv jack javascript jpeg jpegxl lcms2 libarchive libass libavdevice libbluray libdl libm libmpv-shared libplacebo libplacebo-next librt linux-fstatfs lua52 manpage-build memfd_create noexecstack pipewire plain-gl posix pulse rubberband rubberband-3 sdl2 sdl2-audio sdl2-gamepad sdl2-video sixel spirv-cross stdatomic threads uchardet vaapi vaapi-drm vaapi-egl vaapi-libplacebo vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vector vt.h vulkan wayland wayland_protocols_1_24 x11 xv zimg zlib [cplayer] Reading config file /etc/mpv/encoding-profiles.conf [cplayer] Applying profile 'default'... [cplayer] Reading config file /etc/mpv/mpv.conf [cplayer] Applying profile 'default'... [cplayer] Setting option 'hwdec' = 'drm' (flags = 4) [cplayer] Setting option 'drm-drmprime-video-plane' = 'primary' (flags = 4) [cplayer] Setting option 'drm-draw-plane' = 'overlay' (flags = 4) [cplayer] Setting option 'v' = '' (flags = 😎 [cplayer] Waiting for scripts... [osd/libass] libass API version: 0x1701000 [osd/libass] libass source: tarball: 0.17.1 [osd/libass] Shaper: FriBidi 1.0.8 (SIMPLE) HarfBuzz-ng 6.0.0 (COMPLEX) [osd/libass] Setting up fonts... [osd/libass] Using font provider fontconfig [osd/libass] Done. [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Done loading scripts. [cplayer] Running hook: ytdl_hook/on_load [ytdl_hook] ytdl:// hook [ytdl_hook] not a ytdl:// url [ifo_dvdnav] Opening windwaker1080p.mp4 [bdmv/bluray] Opening windwaker1080p.mp4 [file] Opening windwaker1080p.mp4 [demux] Trying demuxers for level=normal. [cplayer] Set property: shared-script-properties -> 1 [osd/libass] libass API version: 0x1701000 [osd/libass] libass source: tarball: 0.17.1 [osd/libass] Shaper: FriBidi 1.0.8 (SIMPLE) HarfBuzz-ng 6.0.0 (COMPLEX) [osd/libass] Setting up fonts... [lavf] Found 'mov,mp4,m4a,3gp,3g2,mj2' at score=100 size=2048. [demux] Detected file format: mov,mp4,m4a,3gp,3g2,mj2 (libavformat) [cplayer] Opening done: windwaker1080p.mp4 [osd/libass] Using font provider fontconfig [osd/libass] Done. [find_files] Loading external files in . [cplayer] Running hook: ytdl_hook/on_preloaded [lavf] select track 0 [cplayer] (+) Video --vid=1 (*) (h264 1920x1080 29.970fps) [vo/gpu] Probing for best GPU context. [vo/gpu/opengl] Initializing GPU context 'wayland' [vo/gpu/opengl] Initializing GPU context 'x11egl' [vo/gpu/x11] X11 opening display: :0.0 [vo/gpu/x11] Display 0 (HDMI-1): [0, 0, 1920, 1080] @ 60.000000 FPS [vo/gpu/x11] Current display FPS: 60.000000 [vo/gpu/opengl] EGL_VERSION=1.4 [vo/gpu/opengl] EGL_VENDOR=Mesa Project [vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL OpenGL_ES [vo/gpu/opengl] Trying to create Desktop OpenGL context. [vo/gpu/opengl] Choosing visual EGL config 0x9, visual ID 0x21 [vo/gpu/x11] The XPresent extension was found. [vo/gpu/x11] XPresent disabled. [vo/gpu/opengl] GL_VERSION='3.1 Mesa 22.3.6' [vo/gpu/opengl] Detected desktop OpenGL 3.1. [vo/gpu/opengl] GL_VENDOR='Panfrost' [vo/gpu/opengl] GL_RENDERER='Mali-G31 (Panfrost)' [vo/gpu/opengl] GL_SHADING_LANGUAGE_VERSION='1.40' [vo/gpu/opengl] Loaded extension GL_ARB_sync. [vo/gpu/opengl] Loaded extension GL_ARB_invalidate_subdata. [vo/gpu/opengl] Loaded extension GL_ARB_get_program_binary. [vo/gpu/opengl] Loaded extension GL_ARB_buffer_storage. [vo/gpu/opengl] Loaded extension GL_ARB_shader_image_load_store. [vo/gpu/opengl] Loaded extension GL_ARB_shader_storage_buffer_object. [vo/gpu/opengl] Loaded extension GL_ARB_arrays_of_arrays. [vo/gpu/opengl] Loaded extension GL_ARB_debug_output. [vo/gpu/opengl] Loaded extension GL_KHR_debug. [vo/gpu] Testing FBO format rgba16f [vo/gpu] Using FBO format rgba16f. [vo/gpu] Disabling HDR peak computation (one or more of the following is not supported: compute shaders=0, SSBO=1). [vo/gpu] No advanced processing required. Enabling dumb mode. [vo/gpu] Assuming 60.000000 FPS for display sync. [vd] Container reported FPS: 29.970030 [vd] Codec list: [vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper [vd] h264_cuvid (h264) - Nvidia CUVID H264 decoder [vd] Opening decoder h264 [vd] Looking at hwdec h264-drm... [vo/gpu] Loading hwdec drivers for format: 'drm_prime' [vo/gpu] Loading hwdec driver 'drmprime-overlay' [vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display. [vo/gpu] Loading failed. [vo/gpu] Loading hwdec driver 'drmprime' [vo/gpu/drmprime] using EGL dmabuf interop [vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128 [vd] Trying hardware decoding via h264-drm. [vd] Selected codec: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10) [vf] User filter list: [vf] (empty) [cplayer] Starting playback... [cplayer] Set property: shared-script-properties -> 1 [vd] Pixel formats supported by decoder: vdpau cuda vaapi drm_prime yuv420p [vd] Codec profile: High (0x64) [vd] Requesting pixfmt 'drm_prime' from decoder. [vd] Using hardware decoding (drm). [vd] Decoder format: 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 [vf] [in] 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [vf] [userdeint] 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [vf] [userdeint] (disabled) [vf] [autorotate] 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [vf] [autorotate] (disabled) [vf] [convert] 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [vf] [convert] (disabled) [vf] [out] 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [cplayer] VO: [gpu] 1920x1080 drm_prime[nv12] [cplayer] VO: Description: Shader-based GPU Renderer [vo/gpu] reconfig to 1920x1080 drm_prime[nv12] bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [vo/gpu] Resize: 1920x1025 [vo/gpu] Window size: 1920x1025 (Borders: l=0 t=0 r=0 b=0) [vo/gpu] Video source: 1920x1080 (1:1) [vo/gpu] Video display: (0, 0) 1920x1080 -> (49, 0) 1822x1025 [vo/gpu] Video scale: 0.948958/0.949074 [vo/gpu] OSD borders: l=49 t=0 r=49 b=0 [vo/gpu] Video borders: l=49 t=0 r=49 b=0 [vo/gpu] Reported display depth: 8 [vo/gpu] Testing FBO format rgba16f [vo/gpu] Using FBO format rgba16f. [vo/gpu] No advanced processing required. Enabling dumb mode. [vo/gpu] Resize: 1920x1025 [vo/gpu] Window size: 1920x1025 (Borders: l=0 t=0 r=0 b=0) [vo/gpu] Video source: 1920x1080 (1:1) [vo/gpu] Video display: (0, 0) 1920x1080 -> (49, 0) 1822x1025 [vo/gpu] Video scale: 0.948958/0.949074 [vo/gpu] OSD borders: l=49 t=0 r=49 b=0 [vo/gpu] Video borders: l=49 t=0 r=49 b=0 [vo/gpu] Reported display depth: 8 [cplayer] first video frame after restart shown [cplayer] playback restart complete @ 0.000000, audio=eof, video=playing [statusline] V: 00:00:00 / 00:04:31 (0%) [vo/gpu/x11] Disabling screensaver. [statusline] V: 00:00:00 / 00:04:31 (0%) [cplayer] Set property: shared-script-properties -> 1 [statusline] V: 00:00:00 / 00:04:31 (0%) [cplayer] Set property: shared-script-properties -> 1 [statusline] V: 00:00:06 / 00:04:31 (2%) [cplayer] EOF code: 5 [cplayer] finished playback, success (reason 3) [cplayer] [cplayer] Exiting... (Quit) [cplayer] Set property: shared-script-properties -> 1 [vo/gpu/x11] Enabling screensaver. THANK YOU to all who gave me updated information! Edited just now by robertoj 0 Quote
ag123 Posted July 20 Author Posted July 20 all those things are wow give kodi a try? https://kodi.tv/ 0 Quote
ABhomeuser Posted Wednesday at 01:36 AM Posted Wednesday at 01:36 AM Hello there! I was looking at the new images from May 28th and noticed that for the minimal/IOT section there was two Debian Bookworm images with the exact same name. They appear to have a different sizes (230 and 241 mb) but no explanation is given for what exactly is different between the two. Does anyone here know what the difference between these two images are? 0 Quote
ag123 Posted Wednesday at 03:08 PM Author Posted Wednesday at 03:08 PM @ABhomeuser the board page is a bit out of date https://www.armbian.com/orange-pi-zero-3/ Debian 12 (Bookworm) Minimal / IOT SHA ASC 241.1 MB Debian 12 (Bookworm) Minimal / IOT SHA ASC 230.3 MB @Igor ^ how do we update that on the boards page? are actually the same file. proof: download the sha file for each of them and look at the content, you can see that both the filename and hash is identical in both sha texts. this means that both files are in fact identical and actually the same size, despite the incorrect file size indication on the front page. in fact that is currently linked to this release on github https://github.com/armbian/community/releases/tag/25.8.0-trunk.375 ^ this is released last week there are in fact 'earlier' releases, I'm running an image from this release https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 I'd suggest going with the 'latest and greatest' (trunk 375) (which is that on the boards page currently) and if there are issues, then try that a little earlier e.g. in the latter link (trunk 309). armbian community images are rolling releases, they are 'fast moving' and perhaps come back in a few weeks, and it could be another trunk release number. but simply take an image 'as of now' and normally it 'just works' e.g. from the boards page. 0 Quote
ag123 Posted Thursday at 12:42 PM Author Posted Thursday at 12:42 PM Installing rpi-monitor in Armbian for Orange Pi Zero 3 https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5 0 Quote
Igor Posted Thursday at 01:43 PM Posted Thursday at 01:43 PM 22 hours ago, ag123 said: how do we update that on the boards page? https://docs.armbian.com/Process_CI/ 0 Quote
robertoj Posted Friday at 04:23 PM Posted Friday at 04:23 PM (edited) On 7/19/2025 at 3:34 PM, Gabriel Negrisiolo Righi said: it is a bit confusing but i hope it helps... Thank you for your suggestions. I am trying to build Mesa in my Orange Pi Zero 3. When I tried installing the build dependencies, apt could not find libxatracker-dev, libllvm-18-dev, libspirv-tools-dev i added changed "deb-src" in the /etc/apt/debian.list, so I could download *-dev packages. How did you install all the dependencies? Are you in Bookworm, or Trixie? Actually I am looking for a double benefit with a new Mesa (bookworm provides mesa 22.3.6, trixie provides 25.0.7): *H264 hardware acceleration *I know that Raspberry has a newer Mesa (don't have it at hand), and X11 can handle the same LCD, with the same kernel module panel-mipi-dbi.ko Edited Friday at 08:34 PM by robertoj 1 Quote
TRay Posted 23 hours ago Posted 23 hours ago Hi I have use v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.35-current-sunxi64 and after run command dmesg I see information on screen So what can I do about it? 0 Quote
Werner Posted 23 hours ago Posted 23 hours ago 4 minutes ago, TRay said: So what can I do about it? I assume it is some debugging left-over. Dealing with sbc families and sunxi in particular it is a ongoing fight against regressions and having a debug kernel can help to identify such. It is not ideal having this on end-user sbcs enabled but to limit resources we cannot afford having two current branches with and without debugging. If this is an issue for you, you can always use the build framework to build your own kernel package with adjusted kernel config disabling traces. 0 Quote
Gabriel Negrisiolo Righi Posted 23 hours ago Posted 23 hours ago (edited) 14 hours ago, robertoj said: Thank you for your suggestions. I am trying to build Mesa in my Orange Pi Zero 3. I've run into similar problems and checking the bash history, what i used was sudo apt-get install build-essential meson ninja-build pkg-config git cmake gettext python3-mako python3-pip bison flex zlib1g-dev libelf-dev libunwind-dev libglvnd-dev llvm-18-dev libclang-18-dev libllvmspirvlib-18-dev libdrm-dev libva-dev libvdpau-dev libvulkan-dev vulkan-tools vulkan-validationlayers-dev spirv-tools libx11-dev libxext-dev libxdamage-dev libxfixes-dev libxrandr-dev libxshmfence-dev libxxf86vm-dev libxkbcommon-dev for what i've saw it seems axtracker is only needed with -Dgallium-xvmc=enabled so try to explicitly disable this if youre not declaring.. and try to keep the build options simple as in On 7/19/2025 at 7:34 PM, Gabriel Negrisiolo Righi said: PYTHON=~/src/mesa/mesa_venv/bin/python3 ~/src/mesa/mesa_venv/bin/meson setup build -Dbuildtype=release -Dprefix=/usr -Dgallium-drivers=panfrost -Dvulkan-drivers=panfrost -Dplatforms=x11 -Dvideo-codecs=all it is worth the hassle, performance increase within latest mesa releases is noticeable another tip is to create a alias to mpv in basrc (and launch gl applications with the same envs) alias mpv='vblank_mode=3 MESA_GLTHREAD=1 PAN_MESA_DEBUG=gofaster nice -n -20 mpv' it is actually faster, but don't set those mesa variables globally as it crashes xfce a lot Edited 22 hours ago by Gabriel Negrisiolo Righi 0 Quote
Gabriel Negrisiolo Righi Posted 23 hours ago Posted 23 hours ago (edited) On 7/20/2025 at 5:01 AM, ag123 said: give kodi a try? couldnt get it working with platform x11 and forcing it to build without internal ffmpeg stills defaults do software rendering with internal player, you can use mpv as external player it works but ina lot of cases you get a blue screen or a video filled with artifacts then it crashes... i'm compiling it with only gbm and forced external ffmpeg to test to use kodi with mpv create a file ~/.kodi/userdata/playercorefactory.xml Quote <playercorefactory> <players> <player name="MPV" type="ExternalPlayer" audio="false" video="true"> <filename>/usr/bin/mpv</filename> <args>PAN_MESA_DEBUG=gofaster --hwdec=drm --profile=fast --fs "{1}"</args> <hidexbmc>true</hidexbmc> <hideconsole>true</hideconsole> </player> </players> <rules action="prepend"> <rule video="true" player="MPV"/> </rules> </playercorefactory> then make it immutable because kodi for some reason keeps deleting it "sudo chattr +i ~/.kodi/userdata/playercorefactory.xml" to edit or delete run the same command with -i Edited 22 hours ago by Gabriel Negrisiolo Righi 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.