I really wish they would stop making newer, faster, more expensive Pi's and just focus on making the existing Pi's cheaper and more available. Out of the dozen or so RPi's I have, not a single one is even connected to a monitor. I don't need dual 4k HDMI ports. I'd love a widely available and in-stock $20 Pi. It's like they've forgotten what the RPi is all about.
Their mass production of the Pi keyboard should clue you into at least one direction that they believe "the Pi is all about"; education, and increasing access to modern computing hardware. Enhancing the performance envelope and connecting to a monitor do, to me, seem like worthy steps toward that end.
Everyone uses general purpose computers differently. I feel your statement "they've forgotten what the RPi is all about" isn't just ignorant; its hurtful. Maybe their direction isn't parallel with what you want out of the products they make, but you should at least have the empathy to recognize that you aren't the main character in this play.
Yes, for context the Pi 1-4 all had H264 hardware encoder/decoder support, which could comfortable encode at least 720p @ 30Hz in realtime. The die space argument makes sense for why they don't have AV1/HEVC encoding, but it does not explain why H264 was dropped. The fact that the CPU is now powerful enough to encode H264 at better quality and frame rates than the old hardware encoder is a better argument, but still a step backwards for folks who need lower power consumption or need the CPU for other things, and doesn't explain why the hardware support needed to be dropped. It really does sound like something else (like licensing) drove the decision, and this is a post-facto attempt to sell/justify that decision.
It is a bit frustrating how married the Raspberry Pi foundation is to a company that couldn't care less if they live or die. Broadcom has always been at best indifferent and at worst hostile to the open source community.
Are you saying the hardware actually has encode on die but was "fused" off?
If so, Raspberry Pi has an organizational culture of outright lying, as opposed to simply speaking plainly. I know this is not Eben Upton speaking, but I've found him many times in the past being either evasive with the truth, or simply lying. It's one thing to not step of the toes of partners, or to not Osborne a product by suggesting a successor is nearing, but to be outright dishonest. Yuck.
"In future we’ll have to do something, but for Pi 5 we feel the hardware encode is a mm^2 too far."
Sounds reasonable, given a fast cpu & less-than optimal hw-accelerated encoding options. As for that "something", maybe:
1) Drop hw-accelerated encoding and decoding entirely, and use the freed up silicon for much beefier cpus (like ones including -bigger- vector units, more cores etc. Cortex X?). That would be useful for any cpu heavy applications.
2) Include hw encoder for a common (1), relatively 'heavy' codec. And hw decoder for same + maybe others.
3) Only include decoder(s?), like they seem to have done for RPi5.
4) Include some kind of flexible compute fabric that can be configured to do the heavy lifting for popular video codecs.
Combined with:
5) Move to newer silicon node to obtain higher efficiency or transistor budget.
Whatever route a future RPi would go, imho hw-accelerated decoding is much more useful than encoding.
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.
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.
There are a ton of pi derivatives that offer a pretty broad range of configurations. I always think of the Pi as the general consumer flagship. I was still pretty impressed with the Pi 4B... I just wish it had broader availability.
Yeah, there's a huge variety of SBCs that exist, most of which have a better specs/price ratio than RPi. If you buy a RPi, you're spending money on the hardware, you're spending it on the mountains of support/tutorials/standardization. I suspect that most people on HN can handle the reduced knowledge base that exists for BPi, OPi, ROCK, etc.
Jetson Orin Nano, the new devkit from Nvidia, surprisingly does not have a hardware video encoder either, you'll need use CPU to encode video instead, which is extremely odd considering video-encoding is a common use case on lots of video applications.
Wow, I was shocked to see that. They don't even bother using CUDA cores to encode (less of an issue if you have unified memory like in Jetsons). Anyway it seems you can get four 1080p streams at 30fps encoded to h264 in CPU if you set it up right: https://www.ridgerun.com/post/jetson-orin-nano-how-to-achiev...
h264 is the most available but probably not the most used. Every streaming service today either seeds AV1, VP9, or HEVC content first since it saves bandwidth[0] and every client from the past 5 years supports one of these newer formats (phones, GPUs, smart TVs, streaming boxes, etc).
Remember you can get an HP Prodesk G3 400 or some such for $60 refurbed with far more hardware capabilities if you don't need the portable form factor, gpio, or power consumption.
Maybe my expectations for RPi 5 are too high, but it’s hard to imagine that an SBC manufacturer known as the industry standard removed the H.264 decoder & encoder from their latest product instead of adding VP9 and AV1, causing users to go crazy when YouTube playback dropped frames. Not to mention serving up transcoded content as a media server.
Good news is that I've been playing around with its competing products. For those users who want a normal media server experience in 2023, Jellyfin will support RK3588 full hardware accelerated transcoding, includes AV1 decode, subtitle burn-in and HDR tone-mapping. (WIP https://github.com/jellyfin/jellyfin-ffmpeg/issues/34#issuec...)
The quite popular Logitech C920 webcam used to natively support H.264, but they dropped it in a model revision a while ago, because "nearly every computer offered in the market features a chipset that can efficiently encode high definition video at 1080p" [1].
I've used that very camera (without the accelerator) on an RPi 4 myself, and the only way to get acceptable quality was by using the Pi's H.264 hardware encoder.
I got a metal box with HDMI and an ethernet ports which encodes the HDMI video + audio and serves/publishes H.264 RTMP/TS segments. My intended use case was actually working with Pi's on live streams, installing fresh systems and the like where encoding might not be available anyway.
I couldn't find the one online but it looks like there are a few out there. Side note/tangent, the Pi3 was powerful enough to transcode 720p down to lower resolutions in real time.
For $85, the Orange Pi 5 supports 8K hardware video encoding (H265/H264) via gstreamer, and that's just what I'm aware of. I'm sure there are other single-board computers with similar (or better) features.
Unless you're dependent on the Raspberry Pi HAT ecosystem or you're not particularly technical, it's worth considering the alternatives.
The title doesn't seem to match the content. The comments are talking about hardware accelerated encode but I didn't see anything about accelerated decode being dropped.
The information is spread over multiple comments, I could only link to one comment and thought just linking to the main article would be confusing as the article itself doesn't mention it.
I think it's a really weak excuse of Gordon Hollingworth "On the processor you have more control over the output". The one on the pi 1-4 worked totally fine and nobody complained about its quality.
Don't forget you can always do software if you want to, it was just really great to have the hardware option.
[+] [-] firebat45|2 years ago|reply
[+] [-] 015a|2 years ago|reply
Everyone uses general purpose computers differently. I feel your statement "they've forgotten what the RPi is all about" isn't just ignorant; its hurtful. Maybe their direction isn't parallel with what you want out of the products they make, but you should at least have the empathy to recognize that you aren't the main character in this play.
[+] [-] aag01|2 years ago|reply
is corporate speech for "broadcom decided not to let us use their video IP cores for low cost/no cost any longer"
[+] [-] pavon|2 years ago|reply
[+] [-] jandrese|2 years ago|reply
[+] [-] deltasepsilon|2 years ago|reply
If so, Raspberry Pi has an organizational culture of outright lying, as opposed to simply speaking plainly. I know this is not Eben Upton speaking, but I've found him many times in the past being either evasive with the truth, or simply lying. It's one thing to not step of the toes of partners, or to not Osborne a product by suggesting a successor is nearing, but to be outright dishonest. Yuck.
This is very, very disappointing.
[+] [-] RetroTechie|2 years ago|reply
"In future we’ll have to do something, but for Pi 5 we feel the hardware encode is a mm^2 too far."
Sounds reasonable, given a fast cpu & less-than optimal hw-accelerated encoding options. As for that "something", maybe:
1) Drop hw-accelerated encoding and decoding entirely, and use the freed up silicon for much beefier cpus (like ones including -bigger- vector units, more cores etc. Cortex X?). That would be useful for any cpu heavy applications.
2) Include hw encoder for a common (1), relatively 'heavy' codec. And hw decoder for same + maybe others.
3) Only include decoder(s?), like they seem to have done for RPi5.
4) Include some kind of flexible compute fabric that can be configured to do the heavy lifting for popular video codecs.
Combined with:
5) Move to newer silicon node to obtain higher efficiency or transistor budget.
Whatever route a future RPi would go, imho hw-accelerated decoding is much more useful than encoding.
[+] [-] lxgr|2 years ago|reply
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.
[+] [-] danogentili|2 years ago|reply
[+] [-] cogman10|2 years ago|reply
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.
[+] [-] gjsman-1000|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] rightisleft|2 years ago|reply
Just a handful of examples:
Banana PI M5: https://www.banana-pi.org/
Odroid C4: https://wiki.odroid.com/start
Odroid N2+: Odroid C4: https://wiki.odroid.com/start
Libre "Le Potato": https://libre.computer/
Libre "Renegade": https://libre.computer/
Orange Pi 3 LTS: http://www.orangepi.org/
Orange Pi 5: http://www.orangepi.org/
Rock Pi 4C+: https://rockpi.org/
Nano Pi M4B: http://nanopi.io/
[+] [-] hatthew|2 years ago|reply
[+] [-] synergy20|2 years ago|reply
[+] [-] Y_Y|2 years ago|reply
[+] [-] Shorel|2 years ago|reply
What will OBS do then?
https://www.nvidia.com/en-us/geforce/guides/broadcasting-gui...
[+] [-] andrewstuart|2 years ago|reply
[+] [-] Thaxll|2 years ago|reply
[+] [-] judge2020|2 years ago|reply
0: https://www.etcentric.org/netflix-switching-from-vp9-codec-t...
[+] [-] supertrope|2 years ago|reply
[+] [-] lannisterstark|2 years ago|reply
It's actually a better deal for home servers.
[+] [-] fswd|2 years ago|reply
[+] [-] jrockway|2 years ago|reply
Prodesk G3: 24 hours * 365 days * 35W * 1000W/kW * $0.30/kWh = $91
Raspberry Pi 5: 24 hours * 365 days * 12W * 1000W/kW * $0.30/kWh = $31
It's likely that 12W over-counts for the Raspberry Pi 5 and 35W under-counts for the Intel chip, so it might be even worse than this.
[+] [-] KaiserPro|2 years ago|reply
yes its double the price, but in terms of power usage its ~4 watts at the plug at 50% load, (vs 30) and more over a million times faster.
[+] [-] bhouston|2 years ago|reply
I think that lack of choice in HW accelerated video encoding/decoding may just be standard on low-end devices in part to reduce costs.
[+] [-] andrewstuart|2 years ago|reply
https://youtu.be/WCRK-Uwb0EA?si=BlxaYkg7Ecq2rALJ
[+] [-] nyanmisaka|2 years ago|reply
Good news is that I've been playing around with its competing products. For those users who want a normal media server experience in 2023, Jellyfin will support RK3588 full hardware accelerated transcoding, includes AV1 decode, subtitle burn-in and HDR tone-mapping. (WIP https://github.com/jellyfin/jellyfin-ffmpeg/issues/34#issuec...)
[+] [-] gjsman-1000|2 years ago|reply
https://www.raspberrypi.com/news/introducing-raspberry-pi-5/...
[+] [-] eurekin|2 years ago|reply
[+] [-] lxgr|2 years ago|reply
I've used that very camera (without the accelerator) on an RPi 4 myself, and the only way to get acceptable quality was by using the Pi's H.264 hardware encoder.
[1] https://www.logitech.com/en-us/video-collaboration/resources...
[+] [-] harlanji|2 years ago|reply
I couldn't find the one online but it looks like there are a few out there. Side note/tangent, the Pi3 was powerful enough to transcode 720p down to lower resolutions in real time.
[+] [-] ehutch79|2 years ago|reply
There used to be an elgator capture card with some encoding, i _think_/
[+] [-] ohthatsnotright|2 years ago|reply
[+] [-] cosmojg|2 years ago|reply
Unless you're dependent on the Raspberry Pi HAT ecosystem or you're not particularly technical, it's worth considering the alternatives.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] giantrobot|2 years ago|reply
[+] [-] MikusR|2 years ago|reply
"JPEG and H264 encode and decode is now in software"
[+] [-] InsomniacL|2 years ago|reply
[+] [-] michaelt|2 years ago|reply
> But it only uses 50% of the processors to do 1080p60 on YouTube"
https://www.raspberrypi.com/news/introducing-raspberry-pi-5/...
[+] [-] devl547|2 years ago|reply
So no encoders and no h.264 decoder.
[+] [-] mastax|2 years ago|reply
https://www.raspberrypi.com/documentation/computers/processo...
- 4Kp60 HEVC hardware decode
- Other CODECs run in software
- H264 1080p24 decode ~10–20% of CPU
- H264 1080p60 decode ~50–60% of CPU
- H264 1080p30 encode (from ISP) ~30–40% CPU
Doesn't seem like the end of the world to me but I'm not trying to use the thing as a media server.
[+] [-] CodeWriter23|2 years ago|reply
[+] [-] InsomniacL|2 years ago|reply
[+] [-] wkat4242|2 years ago|reply
Don't forget you can always do software if you want to, it was just really great to have the hardware option.
[+] [-] t0bia_s|2 years ago|reply