Posts by Chewi

Probably not related, sorry. I also only have a Pi 3b and 4b to test with.

Figured it out. It wasn't an entirely fair comparison. mpv has two DRM PRIME modes, one where it renders via EGL/VAAPI/Wayland, and one where it renders directly to an overlay plane. It tries the first before the second, but there isn't a way to explicitly select one of them at runtime. mpv tries to use desktop GL by default. This was failing under the Pi 3, so it fell back to the second mode. Desktop GL did work under the Pi 4, so it used the first mode. Telling it to use GLES instead made it slightly faster but not much. Eventually, I forced it to used the second mode by requesting GLES and setting MESA_GLES_VERSION_OVERRIDE=2.0. Now it works fine. I'll contact the mpv developers about this.

I tried HEVC on my Pi 3 and it did struggle a bit. I'm not sure whether that's expected to work or not. I gather it doesn't have the hardware. JC did work on a special decoder, but it doesn't seem to be in this patchset.

I then tried my Pi 4 for the first time. Kodi works fine, but mpv is slower than ever, which is really strange. It says it's using hardware decoding, but I think it's the display part that's slow.

Quote from chewitt

NB: Be aware that Pi support for RPi 0/1/2/3/4 is stateful (so nothing to do with v4l2_request) for H264 and stateless (using v4l2_request) for HEVC on RPi 4/5 hardware. Stateful things in the upstream kernel are not as mature/robust as stateless.

Damn, that was quite a big thing for me to miss! I have plenty of H.265 videos here, but I hadn't tried one yet. There is evidently more than just v4l2-request stuff going on in these patches though, as they definitely made a difference. lrusak's v4l2-drmprime patchset alone didn't help.

Quote from chewitt

I'd suggest you reach out to JC and let him know that you're packaging for Gentoo. Although his primary focus is the Raspberry Pi OS, the secondary mission is ensuring Pi hardware works great under any distro, so it's good for him to know how and where his patchsets are being used.

Will do, thanks.

Thanks, chewitt, that helps a lot. At this point, I think we'd be happy with just "good", as opposed to "great", if it means we only have to patch ffmpeg.

Perhaps I'm looking in the wrong place, but I couldn't find any relevant kernel patches. We do provide the RPi kernel, as well as the mainline kernel, same as you. I suspect HDR might still require kernel patches, but that would just be icing on the cake at this point. I've been following this from a gaming perspective, and it seems to be coming together at a decent pace now. I imagine such kernel patches won't be needed for long.

I did see the Kodi patches, but they didn't look essential, and indeed, my H.264 test videos performed much better even with vanilla master. I'll be helping to maintain ffmpeg in Gentoo, but that won't extend to Kodi as I don't have a personal interest in it right now, so that would be up to a different maintainer. We do at least provide "live" packages for users who want them, so any changes that do get merged will be immediately available to them.

I'll therefore provide JC's ffmpeg patchset to all ARM and RISC-V users by default. Perhaps it won't be a perfect fit in every case, but it shouldn't make things any worse.

Hello! I'm here as a Gentoo Linux developer. We support a very broad range of hardware, but our RPi support has been a bit lacking in recent years, with old versions of the legacy stack still present in our package repository. I get the impression that not many people use video on RPi under Gentoo, but I'd like to change that.

I've started putting the changes together to throw out the legacy stack, and I've been testing the video performance against mpv and Kodi. I quickly became aware that vanilla ffmpeg was not going to cut it, even for some 1080p videos on a Pi 3b. I tried various branches from various forks against 6.0 and 6.1, and while these generally worked for mpv, only jc-kynesim's test/6.0.1/main branch worked for Kodi.

I have seen that you only apply this patchset specifically for your RPi build, while you apply Kwiboo's v4l2-request and lrusak's v4l2-drmprime patchsets on most other devices. I know that these patchsets cannot be combined, and I can see that while there are some similarities, the RPi set is not a superset. Does this mean the RPi patchset is useless on other devices? Or perhaps you're trying not to deviate from upstream more than you need to on those devices? Being a source-based distro, Gentoo does not need to force the same patches on everyone, but I'd rather only have one set to deal with here, if possible.

Carrying these patches has the potential to make life difficult for Gentoo maintainers, as we may want to move on from older ffmpeg versions before these patchsets are available for newer versions. I did start rebasing jc-kynesim's branch against 6.1, and while I didn't get stuck, it looked like it was going to take a while, and I didn't want to continue without knowing whether I would succeed unless I really had to. 6.0 is still quite recent though, so I'm not too worried.

I hope and believe that you are still interested in getting these efforts upstreamed. I appreciate this has been a long road, and there may still be some distance to go yet. I don't know whether I can help in this regard, but perhaps another distro adopting this puts some weight behind it. What is the strategy when we have seemingly competing patchsets though?