That’s somewhat understandable, but still a bit disappointing. Not all playback devices support HEVC, and additionally HEVC will likely remain patent-encumbered much longer than e.g. H.264.
I really wish there was at least one other and open hardware-accelerated format. It’s probably a bit too early for AV1, but VP9 would work with modern iOS and Android devices, for example.
I also wonder how much licensing costs were a concern here, although past RPis had software-unlockable codecs for that exact reason.
The rk3588 and rk3588s (i.e. orange pi 5) both support hardware H264/HEVC encoding @ 8k30fps, as well as hardware HEVC/VP9 decoding @ 8k60fps, H264 decoding @ 8k30fps, AV1 decoding @ 4k60fps.
Yes, and there are more advantages to the Orange Pi 5 SBCs:
- They have full size HDMI
- They have an m.2 connector
- They still have an audio jack
- They have more powerful performance cores
- They have low performance cores
- They have a 6 TOPS NPU
On the other hand, that cheap base model has no built-in wifi, but so you can add it in the m.2 slot.
For me, the Raspberry Pi 5 is quite disappointing.
But hey, the good thing is that maybe this will push more of the community to the RK3588(S) based boards.
Nobody needs that GPU. Alyssa Rosenzweig stopped working on the driver and got poached by Valve.
Also, real time encoding with VP8 (yes, that is the standard for WebRTC) barely works. It has barely enough CPU power to produce a working demo, but too little to actually do anything with it.
Can you expand on this? Is the hardware too slow, too power hungry, or just badly supported? At least coming from ARM there must be some hardware documentation on how they work. I mean, it can't be worse than Broadcom's all-proprietary GPUs.
In fact, she just no longer leads panfrost, but still reviews panfrost-related merge requests from time to time. Boris took over her place, and even panvk2 is on its way. https://gitlab.freedesktop.org/bbrezillon
Mali-G610MP4 is known to handle Genshin impact easily. (https://youtu.be/sA55S2Z7gLo?t=56) I doubt VideoCore VII can do that. As of today, there is still no detailed spec sheet for this GPU.
opi5 16gb is about 130 usd, rpi5 is about 80 usd I think? You get twice the cores and RAM so I think they're comparable value. But it's sort of academic for me because rpi5 8GB is not in stock in Australia.
Surprisingly, AV1 is easier to implement a decoder for than VP9 (by design). Some of the VP9 transforms were axed with AV1 purely to make the stream easier to decode.
Why AV1 hardware decoding has taken so long seems to be an issue with hardware manufactures not wanting to support it. HEVC and VVC seem to have more hardware support.
HEVC was built from the ground up to be implemented in hardware to stem the tide of the open-source codecs and thus keep the license money train running.
Ah, yes, I do agree on the quality – it certainly can't compete in any way with high-quality software or dedicated encoders.
But arguably it doesn't have to; many real-time applications (e.g. surveillance cameras) have local bandwidth to spare and/or don't care too highly about quality, and compatibility with older viewing devices without re-encoding is a priority.
If compatibility is a priority and bandwidth isn't an issue, MJPEG is still the way to go and is by far the most common encoding I see in security cameras.
On the other hand you could get cool stuff from the video encoding hardware, such as access to motion vectors on the cheap: https://github.com/osmaa/pinymotion
I wonder though if the OpenGL ES3.1 compute could be used for this purpose on it.
If bandwidth ain't much of an issue, can just dump frames to a separate device for encoding, aside, Can't imagine someone using a pi 5 just for camera usage (aside from projects needing cameras)
Maybe not only for cameras, but also for cameras. And when doing other things simultaneously, a video encoder not hogging all processing power becomes even more important.
Last time I tried to encode a video from H.264 to HEVC (hw-accelerated) on Linux it was such a pain to get to work that I eventually gave up and simply accepted the performance hit. I'm sorry, but I'm not gonna recompile ffmpeg so that it works on my machine. Considering that most RPi-users probably use a Linux-based OS this is IMHO a sensible decision.
Well it's not that uncommon to use a version of ffmpeg with more features enabled for a specific purpose. For instance my jellyfin server uses jellyfin-ffmpeg[0] to do hardware acceleration, even on my Pi.
For hardware acceleration it's probably easier to use gstreamer, depending on what device you are using to decode. But then you have a whole new problem.
Well, to quote Gordon Hollingworth on the original post:
"In future we’ll have to do something, but for Pi 5 we feel the hardware encode is a mm^2 too far."
Also, Raspberry Pi Foundation and Broadcom have been really working together on successors since the... BCM2787 in the Raspberry Pi 3, if I remember correctly? Broadcom still reserves the right to sell to anyone, but the Pi is still the primary customer for those specific chips now.
I really wish there was at least one other and open hardware-accelerated format. It’s probably a bit too early for AV1, but VP9 would work with modern iOS and Android devices, for example.
I also wonder how much licensing costs were a concern here, although past RPis had software-unlockable codecs for that exact reason.