ffmpeg-rockchip-git: package renamed from ffmpeg-rockchip

[7Ji]

The PKGBUILD has declared a name with -git but the git repo was named without. Corrected the repo name to follow PKGBUILD and the actual packaging style.

@hbiyik You would probably need to update your git remote url.
@wyf9661 FYI

[kyak]

@7Ji what is the difference between ffmpeg-rockchip-git and ffmpeg-mpp packages?

[7Ji]

@7Ji what is the difference between ffmpeg-rockchip-git and ffmpeg-mpp packages?

#15 (comment)

Basically -mpp is the older, more mature and ready-to-use implementation, that's mainly maintained by hbiyik, it is very stable as you can see it's not released as a VCS package; -rockchip is the newer, not mature yet and in-devlopment implementation, that's mainly maintained by nyanmisaka, and hbiyik is also contributing to it.

If you're using 5.10 vendor, then use -mpp; 6.1 vendor, then use -rockchip.

[hbiyik]

lets discuss the upcoming big update of ffmpeg and kodi packages here, i will update again after i am done working with it.

[hbiyik]

So finally finished. Ugh, a lot has been done.

1. ffmpeg-mpp package will be replaced with ffmpeg-rockchip. It also replaces ffmpeg-mpp
2. ffmpeg4.4-mpp will be removed. It is based on ffmpeg 4.x i do not want to support it with very few. it was only used for vlc. Interested ones can use the vlc-git from our which supports system-ffmpeg. However i have not yet fiddled with vlc to support ffmpeg-rockchip at all, current solution is use mpv.
3. https://github.com/7Ji-PKGBUILDs/linux-radxa-rkbsp5-git/blob/master/0025-vop2_rgba2101010_capability_fix.patch is necessary for the kodi to work properly in GBM mode, i have patched radxa-rkbsp kernels, if you want to play kodi nicely, other kernels should also implement this. There is also below patch, but i think joshua should have already patched it in his own kernel. I do not know the situation in other kernels
   https://github.com/7Ji-PKGBUILDs/linux-radxa-rkbsp5-git/blob/master/0024-rga3_uncompact_fix.patch
4. Kodi is updated massively.

• Now GBM direct to plane and AFBC modes works flawlessly, you can get 8k@60 for hevc and h264.
• Now also binary addons also compiled with the package. Which means, all PVRs, inputstream addons and libretro compatability (retro emulators etc) can work inside Kodi. To get extra emulators you have to install extra repo: https://github.com/zach-morris/kodi_libretro_buildbot_game_addons

@7Ji but now building kodi takes hours,however i have made a trick to build incrementally. If you do not clean build, the next build will take minutes and only build the new stuff. So only first build will take some time. I am not sure how the build system works, but i definitely suggest to activate something like incremental builds.

As mentoined please refer to https://github.com/hbiyik/ffmpeg-rockchip/wiki/Rendering wiki for details on details.

For mpv use mpv-git package from AUR to get true 10bit support. My PRs just merged to mainline mpv mpv-player/mpv#13371

New Packages:
ffmpeg-rockchip-git (ready to be build)
kodi-nexus-mpp-git (i have done a very first build it seems to work but i appreciate another look @7Ji ). The stuff is at new branch https://github.com/7Ji-PKGBUILDs/kodi-nexus-mpp-git/tree/next

Packages to delete:
ffmpeg-mpp-git
ffmpeg4.4-mpp-git
kodi-matrix-mpp-git (based on ffmpeg4.4, just use nexus)

@kyak appreciate some tests as well :)

[7Ji]

if you want to play kodi nicely, other kernels should also implement this

I would most likely not apply that patch to my -7ji kernel as it sticks strictly to mainline. Most other bsp kernels could use these, though, @wyf9661 , what's your idea on this for the bsp kernels you maintain?

If you do not clean build, the next build will take minutes and only build the new stuff. So only first build will take some time. I am not sure how the build system works, but i definitely suggest to activate something like incremental builds.

That would be useful for users, but my builder would only do clean builds (current implementation). I'm rewriting the builder to implement a lot of things I missed and light-weight rebuild would be one of them. But for now, packages are always clean built, and I'll bite the bullet of that extra build time.

The stuff is at new branch https://github.com/7Ji-PKGBUILDs/kodi-nexus-mpp-git/tree/next

If you see fit you could just merge things to master branch.

Also for Kodi, I've disabled them both from the repo builder due to the funky network requirement, as said earlier it would always be cleanly built by the current builder, yet the Kodi build steps don't value locality so much, almost all deps would need to be fetched from network, and some of the servers ban my CN, RU and US IPs (the one hosting xz-utils, to be precise). Using global proxy from other countries would be of little use for now, as for whatever reason any access to Internet outside China would choke, lag, and break constantly...

Packages to delete

It would be reasonable to delete them from the repo build list, I'll do it. But I'd rather we archive unneeded PKGBUILDs than deleting them from 7Ji-PKGBUILDs, they would be of good reference for us and others when writing other packages in the future, and people who want those packages could build them by themselves. As always, 7Ji/archrepo and 7Ji-PKGBUILDs are two independent entities.

ffmpeg-mpp-git
ffmpeg4.4-mpp-git

We never hosted ffmpeg{,4.4}-mpp-git here did we? Those should beffmpeg-mpp and ffmpeg4.4-mpp right?

[wyf9661]

I plan to add this patch to custom dir of those kernel repo, but will not patch it in PKGBUILD as defult.

[hbiyik]

Kernel Patches

nyanmisaka/ffmpeg-rockchip#4 (comment)
What this patch does is disabling X/ARGB2101010 drm plane formats because andyshark from rockchip confirmed that ARGB is not even supported by rk3588 hardware. and AXRB2101010 is only supported when the buffer is AFBC compressed, but VOP2 driver has no such distinction, and always show it as available. When such planes are used you either get a black sreen or broken image.

This seems to be also a problem for mainline as well.
https://github.com/torvalds/linux/blob/41bccc98fb7931d63d03f326a746ac4d429c1dd3/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c#L18C44-L22C25

The RGA3 patch is not a mainline topic, since mainline does not even have rga3 support and joshua's bsp kernels has already merged that fix.

May be a better way to PR the ARGB fix to joshua kernel @wyf9661 which bsp kernel version do you use? I saw a lot of joshua kernels but could not tell which on is which, my concern is to prevent Opi5 users complain that their kodi does not work.

See armbian people discussion half of the same problem below, they found a partial workaround with manipulating the DTS but thats not the actual solution, it is like cutting your arm just because your finger is bleeding. And when they move to Kodi Omega, i think they will face with the rest of the problem. Currently most of them are using Nexus where 10bit rendering and X/ARGB2101010 are not used.
https://forum.armbian.com/topic/25957-guide-kodi-on-orange-pi-5-with-gpu-hardware-acceleration-and-hdmi-audio/page/7/

one last remark @wyf9661 if you put the patches under custom folder they will be patched automatically, at least this was how i wrote it in past if someone has not modified it. Also according to archlinux guidelines, there should not be a subfolder in the root folder, so this custom folder thing was only meant for local builds.

KODI mirror stuff

The mirrors mainly use github and sourceforge, github archives should not have any problem with blocking or rate limiting at all. But sourceforge really rate limtis if you keep downloading bunch of stuff from their server. This happens to me as well, if i clean build several times, it downloads the packages several times, and sourceforge starts to rate limit. This is also another good reason to go incremental builds, because kodi really has tons of dependencies.

But if the package is comletely blocked to your region i think we should PR this to XBMC team. this is really not nice and i think they might not be aware of this. Is it possible that you give a list of potential servers that are blocked to your region so that i can PR xbmc team to change them to something like github?

PS: yes ffmpeg-mpp and ffmpeg4.4-mpp, not -git variants, we do not have such things, my brain had just melted.

[7Ji]

I saw a lot of joshua kernels but could not tell which on is which

Basically:

• https://github.com/7Ji-PKGBUILDs/linux-rockchip-joshua : Joshua's linux-rockchip (bsp 5.10) repo as upstream, using his tagged releases, this proves to be useful enough, proven by his ubuntu-rockchip project.
• https://github.com/7Ji-PKGBUILDs/linux-rockchip-joshua-git : Joshua's linux-rockhip (bsp 5.10) repo as upstream, using HEAD, I would probably archive this as his main branch receives frequent force pushes.
• https://github.com/7Ji-PKGBUILDs/linux-joshua-git : Joshua's linux (mainline 6.7/8) as upstream, using HEAD, I would probably archive this as the repo is also receiving frequent force pushes, and it performs not as good as expected (worse than next-to-zero-patch -7ji) so not much useful.
• https://github.com/7Ji-PKGBUILDs/linux-rkbsp-joshua-git : Joshua's rockchip-kernel (bsp 6.1) repo as upstream, using HEAD. I think this might need to be renamed to like linux-rkbsp6.1-joshua-git? According to @wyf9661 this proves to be a sweet spot of newer kernel features and good enough hardware support.

my concern is to prevent Opi5 users complain that their kodi does not work

Thank you, but you don't need to worry about my other projects. I would handle them by myself. My preference would be to PR the patch to orangepi, as my opi kernel is basically upstream unchanged, and I don't want to carry a lot of patches around.

PR this to XBMC team

Thank you but not for now. The remote servers blocking my IP is one thing, and it's only the case for xz-utils, also not GH/GL/SF. The worst thing is that my connection to global Internet as a whole is breaking: I have several servers around the world hosting "website"s on which I also host proxys, yet I couldn't even SSH to them since a few days ago. In the past I could just proxy my traffic through one of them even when others are down, but now there could be a time when all of them are out of reach.

[wyf9661]

one last remark @wyf9661 if you put the patches under custom folder they will be patched automatically, at least this was how i wrote it in past if someone has not modified it.

Thanks for your kindly reminder, I was going to comment out the following scripts in my PKGBUILD

  # this is only for local builds so there is no need to integrity check. (if needed)
  for p in ../../custom/*.patch; do
    echo "Custom Patching with ${p}"
    patch -p1 -N -i $p || true
  done

and list a tip to explain the existence about this patch, as I think the kernel patch should be as less as possible.
If users need kodi, they can build it themselves and for one who does not care this, maybe the current is enough. The joshua' s kernel is just an alternative choice, users can select one he like and be interested in. If upstream(orangepi or rk) accept the pr, then we will not need to patch this as well.

[wyf9661]

I think this might need to be renamed to like linux-rkbsp6.1-joshua-git?

thanks for your advice, I will update the repo name.

[hbiyik]

but you don't need to worry about my other projects

Thats really not my intention, sorry if it was interpreted this way.

Without kodi, rest of that packages has no benefit for me, therefore i would just go another solution to publish packages with a new tool based on git repos and i would rather not maintain to different packages, would you take care of the existing packages here?

If you want you can delete or archive them as well. I just need to setup something like AUR but based on github, this way nobody would need to build package for anyone and i can be versatile to focus more on the development rather than package maintenance.

[7Ji]

Without kodi, rest of that packages has no benefit for me, therefore i would just go another solution to publish packages with a new tool based on git repos and i would rather not maintain to different packages, would you take care of the existing packages here?

I'd say we go full in with your tech direction and adapt/archive packages to follow your and nyanmisaka's effort, as you're the expert.

I'm also tired of maintaining too many packages I don't personally use and constantly fixing repo issues.

I don't have any rules here really, and I don't want any one involved here to consider some packages their duty to support endlessly, we see fit and we share PKGBUILDs, just like on AUR.

So if some packages don't fit any more, they can be archived / deleted. I prefer them being archived as I don't like history being completely erasedm.

I just need to setup something like AUR but based on github, this way nobody would need to build package for anyone and i can be versatile to focus more on the development rather than package maintenance.

This is always how this org works, isn't it? As always 7Ji/repo and 7Ji-PKGBUILDs are two distinct entities. People would open issues on inappropriate places but that shouldn't be your duty to fix broken things introduced by repo binary packages. Maybe we could rename this org to make things more clear?

[hbiyik]

i agree, and seriously i agree, such a model in my head is really necessary,

because our packages do not fit to AUR, and maintaining a repo, especially a binary repo is a big pain, especially when it is not native compiled you need infrastructure.

Even when building kodi myself today, i spent at least 6 hours to clean build, re build, disable lto and so on, and having this done constantly on a period of time is a problem for a signle entity, therefore i think it is users burden to carry those.

So my idea is to introduce a tool called AGR, "Archlinux Git Repositories" people can configure the packages from git, this tool will build it on the host. It would fit for niche applications like we do, and everyone has different objectives. Mine is kodi, some else is Firefox/Chromium, other guy is obsessed with gaming. So one little sbc running is some part of the world can not handle all of those.

From my POV i think only 1 git repo for my packages is enough i dont think i need a seperate repo for each also, it is easier to maintain for me as well. So yeah, lets burn this repo and let the users cook their own food.

[wyf9661]

@7Ji @hbiyik @kyak
Merged into joshua's branch:)
Joshua-Riek/linux-rockchip@ba7faab