I think I got chromium-mpp v129 working?

[kwankiu]

I have rewritten chromium-mpp based on alarm's latest v129, with some patches including chromium mpp patches released 1 day ago, @7Ji's lib path patch, as well as a fix for a patch failure.

The PKGBUILD is located at: https://github.com/1usOS/PKGBUILDs/tree/rockchip/chromium-mpp

Changes made on top of alarm's latest v129 chromium : https://github.com/1usOS/PKGBUILDs/compare/48a7476..da1eb48

Here is the compiled package to test: https://github.com/kwankiu/archlinux-installer/releases/download/kernel/chromium-mpp-129.0.6668.100-1-aarch64.pkg.tar.xz

I have installed it on my side, with joshua 6.1 on khadas edge 2 (hyprland), from what I can tell, it behaves like our previously working chromium-mpp v114, unlike your current v126 that struggles to get it working. In chrome://gpu , the video capabilities are showing properly,

and with YouTube, VP9 4K 60fps has around 60-70% CPU Usage, while AV1 4K 60fps has around 30-40% CPU Usage which seems like using HW decoding?

For GL, I couldn't test it as i am using PanVK (which isn't using the blob?) for graphics and there seems to be egl issues with Mesa 24.3 (there were issues with hyprland and some other software).

@JFLim1, FYI

[JFLim1]

@kwankiu Thanks. Will download and give it a go. Does the new chromium-mpp_v129 works with Wayland? Is there a requirement to use the mali blob? Hope it doesn't require mali blob, as never seems to have any luck with mali blob before on my Opi5-Plus.

Any particular chromium flags settings to enable vpu hw acceleration?

[kwankiu]

@kwankiu Thanks. Will download and give it a go. Does the new chromium-mpp_v129 works with Wayland? Is there a requirement to use the mali blob? Hope it doesn't require mali blob, as never seems to have any luck with mali blob before on my Opi5-Plus.

Any particular chromium flags settings to enable vpu hw acceleration?

my guess is you don't need any additional flags

for video acceleration, it just works by launching chromium for WebGL with panthor, you just need to set ozone platform to wayland

in my case with panthor/panvk, flags like --use-gl=angle / --use-gl=egl / --use-angle=gles-egl doesn't help, forcing egl would even results in error and it will disable all hw acceler feature.

[JFLim1]

or video acceleration, it just works by launching chromium for WebGL with panthor, you just need to set ozone platform to wayland

Thanks. This is great basically similar to amazingfate's chromium-mpp_v126 for Ubuntu Jammy/Noble.

Ok. Downloaded.

[kwankiu]

or video acceleration, it just works by launching chromium for WebGL with panthor, you just need to set ozone platform to wayland

Thanks. This is great basically similar to amazingfate's chromium-mpp_v126 for Ubuntu Jammy/Noble.

Ok. Downloaded.

just now, playing YouTube AV1 at 4K 60, it is very smooth, very minimal frame drops

[JFLim1]

just now, playing YouTube AV1 at 4K 60, it is very smooth, very minimal frame drops

Yeah, running your chromium-mpp_v129 on BredOS-Cinnamon-5.10.160-rockchip (kernel from BredOS repo) on Wayland session on mesa-panfork-git.

vpu hardware acceleration available on vp09 videos provided "--ozone-platform=wayland" is enabled but NOT on av1 video -- this is on mesa-panfork-git. Will test it on Panthor later to see whether av01 video have vpu hw acceleration like what you achieved on your device.

[kwankiu]

vpu hardware acceleration available on vp09 videos provided "--ozone-platform=wayland" is enabled but NOT on av1 video -- this is on mesa-panfork-git.

Do chrome://gpu shows video decode capabilities correctly on your side? How do you test VP9? From what I have heard of, youtube vp9 uses software decoding, for av1, if the youtube video source supports AV1, and chrome://gpu shows hardware AV1 decode capabilities, it will play in AV1, but not all video source supports AV1,

Here is one example of YouTube AV1 4K 60fps source : https://www.youtube.com/watch?v=gNtJ4HdMavo

[JFLim1]

Do chrome://gpu shows video decode capabilities correctly on your side?

Yes.

Video Acceleration Information
==============================
Decoding               : 
Decode av1 profile main: 48x48 to 7680x4320 pixels
Decode hevc main       : 48x48 to 7680x4320 pixels
Decode hevc main 10    : 48x48 to 7680x4320 pixels
Decode h264 baseline   : 48x48 to 7680x4320 pixels
Decode h264 main       : 48x48 to 7680x4320 pixels
Decode h264 high       : 48x48 to 7680x4320 pixels
Decode vp8             : 48x48 to 7680x4320 pixels
Decode vp9 profile0    : 48x48 to 7680x4320 pixels
Decode vp9 profile2    : 48x48 to 7680x4320 pixels
Encoding               : 
Encode h264 baseline   : 0x0 to 1920x1080 pixels, and/or 30.000 fps.
Encode h264 main       : 0x0 to 1920x1080 pixels, and/or 30.000 fps.
Encode h264 high       : 0x0 to 1920x1080 pixels, and/or 30.000 fps.
Encode vp8             : 0x0 to 1920x1080 pixels, and/or 30.000 fps.

How do you test VP9? From what I have heard of, youtube vp9 uses software decoding,

Using Youtube https://www.youtube.com/watch?v=k7dy1B6bOeM and vpu hw acceleration available.

for av1, if the youtube video source supports AV1, and chrome://gpu shows hardware AV1 decode capabilities, it will play in AV1, but not all video source supports AV1,

As per above Chrome://gpu does show AV01 with hw acceleration but when I play the Top Gun video from your link or any of the Youtube av01 videos NO vpu hw acceleration on BredOS-Cinnamon-5.10.160-rockchip with mesa-panfork-git. Check using "chrome://media-internals".

This might be unique to mesa-panfork-git. Will test on Panthor.

[JFLim1]

Here is one example of YouTube AV1 4K 60fps source : https://www.youtube.com/watch?v=gNtJ4HdMavo

Chromium-mpp_v129 on Panthor still NO vpu hw acceleration on AV01 videos on Gnome-6.1.75-joshua-git with mesa-24.2.4-1 (Panthor). Very high CPU usage with AV01 4K/60 with some dropped frames (around 3%) but is still smooth enough. "chrome://media-internals" indicates no vpu hw acceleration:

kVideoDecoderName "Dav1dVideoDecoder" instead of "kVideoDecoderName "V4L2VideoDecoder"

On VP09, H264 videos vpu hw acceleration is available. No idea why only av01 videos no vpu hw acceleration.

pacman -Qs mpp
local/chromium-mpp 129.0.6668.100-1
    A web browser built for speed, simplicity, and security
local/ffmpeg-mpp-git 7.0.2.r114870.6a166dcef1-1
    Complete solution to record, convert and stream audio and video supporting
    rockchip MPP hardware decoder
local/gst-rkmpp-bin 2-1
    Gstreamer plugin for Rockchip hardware video decoder/encoder
local/libv4l-rkmpp-git 1.7.1-1
    A rockchip-mpp V4L2 wrapper plugin for chromium V4L2 VDA/VEA, latest from
    git
local/mpp-git 1.0.7.r3711.690b262a-1
    Rockchip VPU Media Process Platform (MPP) for hardware video decode latest
    revision from git
local/v4l-utils-mpp 1.26.1-1
    Userspace tools and conversion library for Video 4 Linux, with Rockchip MPP
    support

[kwankiu]

kVideoDecoderName "Dav1dVideoDecoder" instead of "kVideoDecoderName "V4L2VideoDecoder"

On VP09, H264 videos vpu hw acceleration is available. No idea why only av01 videos no vpu hw acceleration.

Hmm,

  #[dav1d]=dav1d

dav1d is commented on my build where this is uncommented on 7Ji's build, I will see

[JFLim1]

Hi @kwankiu,

Had 2 random chromium-mpp_v129 crash. Just wonder whether you had the same experience with random chromium-mpp_v129 crash?

Yesterday after 3 hours of chromium-mpp_v129 up-time and this morning less than 5 minutes chromium up-time.

Edit: 2 more crashes this morning

[jfl@opi5plus ~]$ chromium

(chromium:2243): dconf-WARNING **: 10:23:40.275: unable to open file '/etc/dconf/db/local': Failed to open file “/etc/dconf/db/local”: open() failed: No such file or directory; expect degraded performance
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Failed to query video capabilities: Inappropriate ioctl for device
[1013/102413.286333:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.291222:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.291880:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.292112:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.293414:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Trace/breakpoint trap (core dumped)

[kwankiu]

Hi @kwankiu,

Had 2 random chromium-mpp_v129 crash. Just wonder whether you had the same experience with random chromium-mpp_v129 crash?

Yesterday after 3 hours of chromium-mpp_v129 up-time and this morning less than 5 minutes chromium up-time.

Edit: 2 more crashes this morning

[jfl@opi5plus ~]$ chromium

(chromium:2243): dconf-WARNING **: 10:23:40.275: unable to open file '/etc/dconf/db/local': Failed to open file “/etc/dconf/db/local”: open() failed: No such file or directory; expect degraded performance
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Failed to query video capabilities: Inappropriate ioctl for device
[1013/102413.286333:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.291222:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.291880:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.292112:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1013/102413.293414:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Trace/breakpoint trap (core dumped)

yeah, is that the same behaviour that happened before with v126 with amazingfate before he found the patch? If yes, can you point me to that patch?

[kwankiu]

@JFLim1 and for AV1

Can you test this package? https://github.com/kwankiu/archlinux-installer/releases/download/kernel/chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz

[kwankiu]

@JFLim1 and for AV1

Can you test this package? https://github.com/kwankiu/archlinux-installer/releases/download/kernel/chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz

Ok, i can see there are random crash issue with chromium, my guess is that it’s a wayland issue

With AV1 youtube 4K 60fps, i can not tell as there’s not really a significant difference, but well, yesterday it was smooth but still got some frame drops, this time i almost dont really see frame drops, initially the cpu usage is below 30%, lower than the 30-40% I mentioned yesterday.

[JFLim1]

yeah, is that the same behaviour that happened before with v126 with amazingfate before he found the patch? If yes, can you point me to that patch?

@kwankiu Not sure is the same but could be similar. amazinfate reverted this patch if not mistaken: https://github.com/chromium/chromium/commit/67d69c1b628b54c1442d8e494852d6403a21446a

According to him after reverting the patch, chromium-mpp was stable with Wayland.

Can you test this package? https://github.com/kwankiu/archlinux-installer/releases/download/kernel/chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz

Sure will check it shortly.

Edit: The new chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz still NO vpu hw acceleration with av01 video on my device. vpu hw acceleration only with VP09 and H264. Did not test other video types.

[kwankiu]

yeah, is that the same behaviour that happened before with v126 with amazingfate before he found the patch? If yes, can you point me to that patch?

@kwankiu Not sure is the same but could be similar. amazinfate reverted this patch if not mistaken: chromium/chromium@67d69c1

According to him after reverting the patch, chromium-mpp was stable with Wayland.

Can you test this package? https://github.com/kwankiu/archlinux-installer/releases/download/kernel/chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz

Sure will check it shortly.

Edit: The new chromium-mpp-129.0.6668.100-with-dav1d-aarch64.pkg.tar.xz still NO vpu hw acceleration with av01 video on my device. vpu hw acceleration only with VP09 and H264. Did not test other video types.

Are you sure that this is behaving differently compared to amazingfate's chromium on debian/ubuntu? I think there's some sort of AV1 HW acceler support on upstream chromium, not sure if it is merged, if it does then it wouldn't be using v4l2-mpp's decoder

on my side, i think uncommenting dav1d seems to have some improvements to youtube av1 playback @ 4k 60fps

[JFLim1]

Are you sure that this is behaving differently compared to amazingfate's chromium on debian/ubuntu? I think there's some sort of AV1 HW acceler support on upstream chromium, not sure if it is merged, if it does then it wouldn't be using v4l2-mpp's decoder

You are correct. There is av01 vpu hw acceleration on amazing fate chromium-mpp_v126 on Ubuntu (just that on av01 video cannot launch at 4K video firtst. start with lower resoluiton like 720p/1080p vpu hw acceleration will be available then select 4K resolution vpu hw acceleration will also work). According to him reverting the patch resolved the chromium-mpp Wayland stability issue. Without "--ozone-platform=wayland" chromium-mpp_v126 vpu hw acceleration does not work on any video and is the same as far as I can tell for your chromium-mpp_v129.

On my device av01 NO vpu hw acceleratio on chromium-mpp_v126 with Panfork or Panthor. For the time being I use "enhanced-h264ify" to block "av01" so that can have vpu hw acceleration streaming Youtube videos.

[kwankiu]

Are you sure that this is behaving differently compared to amazingfate's chromium on debian/ubuntu? I think there's some sort of AV1 HW acceler support on upstream chromium, not sure if it is merged, if it does then it wouldn't be using v4l2-mpp's decoder

You are correct. There is av01 vpu hw acceleration on amazing fate chromium-mpp_v126 on Ubuntu (just that on av01 video cannot launch at 4K video firtst. start with lower resoluiton like 720p/1080p vpu hw acceleration will be available then select 4K resolution vpu hw acceleration will also work). According to him reverting the patch resolved the chromium-mpp Wayland stability issue. Without "--ozone-platform=wayland" chromium-mpp_v126 vpu hw acceleration does not work on any video and is the same as far as I can tell for your chromium-mpp_v129.

On my device av01 NO vpu hw acceleratio on chromium-mpp_v126 with Panfork or Panthor. For the time being I use "enhanced-h264ify" to block "av01" so that can have vpu hw acceleration streaming Youtube videos.

Ok, so it looks like uncommenting dav1d doesnt do anything with chromium mpp v129, on my side, i can tell that both of my package behaves the same, on the first ~10 seconds, i have seen cpu usage less than 10%, which is clearly hw decoding, but then it would crash (freeze for a second) and fall back to software decoding. This only happens on AV1, no issue with VP9

[JFLim1]

Sorry errata: On my device av01 NO vpu hw acceleratio on your chromium-mpp_v129 with Panfork or Panthor.

, i can tell that both of my package behaves the same, on the first ~10 seconds, i have seen cpu usage less than 10%, which is clearly hw decoding, but then it would crash (freeze for a second) and fall back to software decoding

Same experience but only on first try I think but difficult to repeat -- when try to repeat there is no vpu hw acceleration just software decoding.

Do you experience any random crashes on Panthor? In actual fact, I can sort of trigger the crash on Panthor.

Just checking whether you will be releasing/building chromium-mpp_v129 with reverting the patch as suggested by amazingfate?

[kwankiu]

Same experience but only on first try I think but difficult to repeat -- when try to repeat there is no vpu hw acceleration just software decoding.

It seems happening to me on every time I launch chromium, since it fallback to software after a "crash" with the "av1 hw accel", it wont use hw decode until you restart chromium.

Do you experience any random crashes on Panthor? In actual fact, I can sort of trigger the crash on Panthor.

I am currently using panthor, yes, it does crash.

Just checking whether you will be releasing/building chromium-mpp_v129 with reverting the patch as suggested by amazingfate?

I will look into it soon, compiling chromium with local hardware is a very painful experience, it requires plenty of CPU power, memory, storage, and time.

[kwankiu]

@7Ji ,

Just tested your chromium-mpp after bumping to v129, and it results the same as v126 that there is no video acceleration, video capabilities in chrome://gpu is blank, meaning that the browser would assumes there is no hardware video decode available for 1080P or above.

Then I tried to replace chromium-mpp with my build and it results in a 0.06MB upgrade installed size (as reported by pacman), which means there's possibly something missing in your build resulting in this.

You might want to take a look at my PKGBUILD (which started clean from alarm and added the necessary changes based on your chromium-mpp),

https://github.com/1usOS/PKGBUILDs/tree/rockchip/chromium-mpp

Additionally, since I have experience with building linux-asahi kernel package with arb which resulted in a bootable kernel but without GPU acceleration working (becomes software rendered), and building the exact same pkgbuild with makepkg in host instead of via arb / inside a chroot solved the issue. I would suggest to give a try building the package without using arb to see if it makes a difference.

[7Ji]

which started clean from alarm and added the necessary changes based on your chromium-mpp

Every time chromium-mpp is bumped it is started from clean: resetting to alarm tree then re-adding back all changes, as it's not possible to do a merge-update anyway, and builds both before and after the change would be tested. I don't see logical difference you did differently in your PKGBUILD and I don't think the PKGBUILD is the issue.

and building the exact same pkgbuild with makepkg in host instead of via arb / inside a chroot solved the issue.

If building a PKGBUILD in clean chroot results in broken package and on host does not, then the PKGBUILD is broken and needs to be fixed.

I would suggest to give a try building the package without using arb to see if it makes a difference.

There is though, packages built without arb, built when I test PKGBUILD bumps, but I don't see any difference, maybe again this is caused by ccache, I'll disable that for the whole build server and try again.

And, as seen in https://github.com/1usOS/PKGBUILDs/releases/tag/aarch64 , is there a hard limit from Github that a release can have at most 500 assets? I never wrote arb to be a distro repo builder in any means because in its current form it sucks at splitting the build jobs (non in rewrite branch but I never had time to finish it) and is too pedantic on dependency changes.

[kwankiu]

is there a hard limit from Github that a release can have at most 500 assets?

I think it is just because I have exactly 500 (498+source) assets currently, armbian has releases with 1000+ assets: https://github.com/armbian/community/releases/tag/24.11.0-trunk.273

But releasing that much assets at once with a workflow automatically could be a problem, I am using ncipollo/release-action@v1 and I have seen workflow failed (only half of the assets uploaded) because of github server errors, but that's last month, I have not seen any issues this month.

[7Ji]

But releasing that much assets at once with a workflow automatically could be a problem, I am using ncipollo/release-action@v1 and I have seen workflow failed (only half of the assets uploaded) because of github server errors, but that's last month, I have not seen any issues this month.

https://github.com/1usOS/PKGBUILDs/blob/main/.github/workflows/upload_to_release_aarch64.yaml https://github.com/1usOS/PKGBUILDs/releases/tag/archive

If I understand correctly, you run a job everyday to re-upload everything from your previously uploaded archives, which itself is not updated everyday. That wastes a lot of bandwidth: your archive uploading is a full update and every day's upload from archive is another full update. That just wastes too much time when you have more and more packages. Why not upload assets on-demand and cache the checksums to skip assets that do not need to be re-uploaded? Like in https://github.com/7Ji/archrepo/blob/master/scripts/gh_sync.py ?

[7Ji]

@kwankiu I wonder how you even reached the state that "it behaves like our previously working chromium-mpp v114" with "@7Ji's lib path patch"? That took me off guard as I thought I don't need to bump that patch this time, considering your report. But it still needs to be adapted because chromium added yet more codes to hard code the lib lookup paths.

[4588:4703:1023/095043.482528:VERBOSE1:v4l2_stubs.cc(162)] : dlopen(/usr/lib64/libv4l2.so) failed.
[4588:4703:1023/095043.482733:VERBOSE1:v4l2_stubs.cc(164)] : dlerror() says:
/usr/lib64/libv4l2.so: 无法打开共享目标文件: 没有那个文件或目录
[4588:4703:1023/095043.482808:VERBOSE1:v4l2_utils.cc(607)] : GetSupportedV4L2DecoderConfigs(): Failed to initialize LIBV4L2 libs
[4588:4734:1023/095048.044274:VERBOSE1:v4l2_stubs.cc(162)] : dlopen(/usr/lib64/libv4l2.so) failed.
[4588:4734:1023/095048.044637:VERBOSE1:v4l2_stubs.cc(164)] : dlerror() says:
/usr/lib64/libv4l2.so: 无法打开共享目标文件: 没有那个文件或目录
[4588:4734:1023/095048.044781:VERBOSE1:v4l2_device.cc(886)] : OpenDevicePath(): Failed to initialize LIBV4L2 libs

Oops I made a mistake, my arch-local patches were not applied. Sorrry for the misinformation.

[7Ji]

I found it, I dropped my logic to apply my local patch when bumping to 122 by mistake:

https://github.com/7Ji-PKGBUILDs/chromium-mpp/commit/35302ecd541a915b8917a8225bb2aee0059122f1#diff-c13dbcca92f9ff12cd26ecce958be3f9ee8563baace04f7a463a6d2dd4252e0bL241

After that the patch always exist in tree but was never applied.

[7Ji]

4K HEVC verified to actually work on a 4K monitor on Joshua bsp6.1 kernel with panthor.

Test "8K" video larger than 7680x4320 does not work and that's a known issue.

AV1 does not work but that's another issue to dig and this issue is already too long. I'll just use HEVC and call it a day. Anybody with their free time could dig into the AV1 issue.

Closing by https://github.com/7Ji-PKGBUILDs/chromium-mpp/commit/9d3afd6141bc881969bd265f5891d755f8f0a4e3 .

[JFLim1]

Hi @7Ji,

With the new chromium-mpp-129.0.6668.100-2, can confirm have vpu hw acceleration except for av01 videos on kernel-6.1.75-joshua-git Panthor.

Thank you.