jock

mpv official github repo. v4l2request commits are in a pull request.

I compiled mpv 0.40.0 on Debian Trixie with the patches for v4l2request, but the outcome is messy at best. There is a new hwdec v4l2request, but also two new gpu-hwdec-interop v4l2request and v4l2request-overlay. It works with acceleration when launched from a terminal, but in wayland/weston v4l2request refuses to work. I don't know what happened, but it looks like a big regression from 0.39. Better use the old mpv version IMHO.

You're welcome @Hqnicolas 👍

sorry, no idea 🤷‍♂️

@samircobra Did you try multitool? You can find it in the first post; also read carefully the first post, it contains very useful informations, for example the hint about the failing eMMC on these rk3318 boards. Probably your box has a failing eMMC. Also another important thing: we don't talk about "firmwares" here, we talk about Armbian, so if you have questions not related to Armbian, this is the wrong place.

Don't know what to tell you, it is running fine on my boxes and dmesg is clean. Also I cannot see what is your build version since the screenshot is missing the top line of the screen. 🤷‍♂️

@JaydenWithaWhy I rebuilt and uploaded again a new copy of the multittol. Please download and try again, I tested successfully on a tvbox of mine and worked fine.

"Regular" mpv coming in Debian Bookworm works perfectly fine, as Bullseye did also. There should be no need for custom mpv builds, unless some features have been removed.

@JaydenWithaWhy ok ,the source is right. The multitool should leave a dmesg log in the MULTITOOL partition of the sdcard; that log could be handy to understand what's wrong. Also you can access via SSH and run the multitool from there, so you may get some clearer output and some more details about the error. A last note, I never tested it with a 128gb sdcard; it should work but bugs are around the corner...

From my tests, ffmpeg works fine with hardware acceleration under Debian Trixie, but packaged mpv (AFAIR it is v0.4.0) does always fails hardware decoding.

@JaydenWithaWhy Multitool is supposed to resize the partition to the whole size of the media as soon as you run it for the first time on the box. About the "command not found" and black box issues, I'm not aware about. When you see the Terms, you can scroll up and down and Enter key will just proceed to the main menu. Where did you download the software?

login via ssh

Open the box, read the silkscreen on the board, run rk322x-config and configure according to silkscreen name. Probably you have a r29/h20 board

Hello! You should really look to the board name in rk3318-config rather than relying to led-conf numbering; also your dmesg is showing a very bad error which is probably due to an unstable system rather than a bug

rk322x armbian images never used the offset of 8192 sectors, only the multitool has such offset to increase compatibility with stock images

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality. The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271 Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

@MattWestB According to /boot, your box should boot 6.16. I don't know though if you have other eMMC/sd/USB devices which may interfere

Normally not if you have a recent distribution. Beware not to test that kernel in a box that does something useful though!

@MattWestB@Thiên Thư Lục In this directory I have put an experimental kernel with a kernel patch that should fix some USB3 issues. If may want to try and experiment if it works for you. It is based upon kernel 6.16. You only need to install the image and dtb packages, headers are only if you need to compile some thirdy party drivers.

@robertoj --hwdec=v4l2request seems present on mpv v0.40, which is the one in trixie. Older mpv versions have --hwdec=drm; I don't know the differences, but I guess drm become v4l2request at some point. --gpu-hwdec-interop=drmprime-overlay directly presents the frames using an hardware overlay. It is very useful if you want to go fullscreen (like on a virtual terminal), but if you are running a desktop environment, everything behind the video overlay will be hidden. --gpu-hwdec-interop=drmprime instead uses the linux facilities (dmabuf) to transfer the decoded frames from the hardware decoder buffer to the EGL/OpenGL (or whatever) presentation layer without actually copying the buffer data, but just passing a file handler. It is more complex and has more overhead, but it is suitable to be used within a desktop environment because the frames are drawn in regular windows. --gpu-hwdec-interop=auto don't know, I guess mpv does some guessing to decide which one is the best.

It looks like mpv does not work anymore with v4l2request on trixie. Benchmarking with ffmpeg reports very high framerate on a 1080p h.265 video, but mpv refuses to work when --hwdec=v4l2request is chosen. It says a generic [vd] Could not create device. message in the log and switches to software rendering. Parameter --hwdec=v4l2request-copy works though, despite being slow because it involves framebuffer copy.

Hello Then you're doing it wrong. Bypassing the eMMC shorting the CLK pin to ground will definitely force the boot from sdcard, or fall into maskrom mode if no sdcard is in the slot. I wonder what debug info is prompted on the serial port (if any) and if the device is recognize if you connect the OTG USB port to a PC with a male-to-male cable

Then Trixie arm64 is already supported BTW: just managed to use a trixie armhf armbian rootfs as a rootfs container for lxc... it just works, so packages are coming for trixie armhf too 😁 edit: trixie armhf packages added!

Unfortunately, lxc containers are not supplied anymore for armhf targets (see https://github.com/lxc/lxc-ci/commit/8d7326930f824a0aeedb6be3598c64e9e9a6ce36, I read somewhere the build machine has no 32bit compatibility anymore), hence building ffmpeg on Debian Trixie for armhf (32 bits) requires some more trickery.