That's the problem right there: the Linux kernel situtation. As OP noted they just use the vendor's (long outdated) Linux kernel, with the vendor's (typically crap) kernel drivers. They just don't clean up that situation in that project, let alone try to mainline the drivers. It's where I thought I could help, but... see my other post on why that didn't work out.
With mainline-supported cameras using a standard API, a userland application that does streaming and all kinds of neat stuff is just much more doable IMHO.
They're not the only project that builds a ton of userland stuff on top of a rotten kernel foundation: oe-alliance has nine distros downstream from it, and hundreds of supported hardware platforms. As far as I can tell it's all ancient vendor kernels with un-upstreamable drivers.
That's the rotten situation with embedded Linux. Nearly all silicon vendors ship a highly modified kernel with proprietary drivers and firmware. Nothing gets upstreamed. The code quality is low and the changes are not architecturally sound, so patches wouldn't get accepted by OSS maintainers in their current state. Vendors end up with countless forks of the kernel, system libraries and system services (at least one for each SoC), which they don't maintain because it's too much work (of course).
This is such a weird market. Most embedded devices are purchased by randos who don't know what they're getting themselves into.
By contrast, security cameras are disproportionately purchased by, I'm guessing, security professionals. Often the security staff at large corporations that are buying cameras in volume. If there was any camera that was otherwise competitive and had mainline kernel drivers and open source firmware, would anybody even buy anything else?
The camera manufacturers don't make the silicon and the silicon makers don't care about any specific camera manufacturer.
Not even Google can get Qualcomm to upstream their drivers. Let that sink in. And it's not because of confidential IP, because many of the drivers are already open source.
Silicon vendors could save a lot of time by mainlining their code rather than having hundreds of forks of every library. Security would dramatically improve. OEMs could update their products.
Maybe it will take legislation or a special interpretation of the 2021 executive order on cyber security [1] to force silicon vendors to take this seriously.
And this is one of the big reasons that Raspberry Pis are so popular despite an endless supply of alternatives - it's basically the only well-documented and supported embedded linux. Almost every other dev board that competes with them has limited support and outdated kernels and countless other issues.
With mainline-supported cameras using a standard API, a userland application that does streaming and all kinds of neat stuff is just much more doable IMHO.
They're not the only project that builds a ton of userland stuff on top of a rotten kernel foundation: oe-alliance has nine distros downstream from it, and hundreds of supported hardware platforms. As far as I can tell it's all ancient vendor kernels with un-upstreamable drivers.