Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"In future we’ll have to do something, but for Pi 5 we feel the hardware encode is a mm^2 too far."

is corporate speech for "broadcom decided not to let us use their video IP cores for low cost/no cost any longer"



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.


Encode is always a bit messier; perhaps you need a tool which is not GPU aware, maybe your needs go beyond what the encoder can do.

But dropping the hardware h.264 decoder is a horrible thing to do. H.264 might as well be the lingua franca of online videos. Think of all the kids in classrooms loading videos on Youtube now constantly hammering the CPU for decode. It's such a weird decision that it can only be caused by business issues.


Youtube today is mostly vp9 anyway, if you don't use the h246ify extension which limits you on resolution/framerate anyway on many videos


Even on mobile? I sincerely hope when I play a YouTube video on my iPhone it's using the built-in decoder hardware rather than churning through what may as well be Google's proprietary codec on the CPU but I guess I have no way of knowing.


Apple has had VP9 hardware decode support for a while.


Well presumably h264/AVC is still there? The lack of HEVC just means it doesn't have an h265 encoder.


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.


There's not really an alternative.

Broadcom is one of the few options out there for ARM SoC. Rpi could dump a bunch of money into making their own SoC, but that would really ballon the costs.


They couldn't use Rockchip or Allwinner or Texas Instruments chips? Sure there is some work they would have to do all over again getting the drivers working and reliable, but in the long run the partnership could be far better for the company.


They should partner with qualcomm, not broadcom.

Too bad it's because of the former broadcom employees within the foundation.


Qualcomm is the single worst company to work with. They try to negotiate % of revenue deals instead of cost-per-unit deals and they make Broadcom look like Stallman-level open source fanatics.


> They should partner with qualcomm, not broadcom.

lol, are you unaware of how qualcomm treats all of it's customers, including megacorps?


I'm guessing you're not a fan of Google Wear watches or Microsoft Surface ARM at all or you'd be more aware of how Qualcomm treats their gift horses worse than I've seen any company. We are talking 10 year old mediocre designs being shown off as their flagship parts in some cases here and I'd expect if they did turn over the Pi to Qualcomm you'd get the best 2015 $100 phones had to offer as the SoC


They should produce boards from multiple vendors' SoCs.


This doesn’t work in practice since your costs scale with vendor count and theirs don’t.

In reality being a single big customer for one vendor is far more influential than being a small one with other options.


In reality being a single big customer for one vendor is far more influential than being a small one with other options.

In what world? the one where firms don't compete?

If other firms are explicitly on the table for the currently negotiated and next generation RPi, Broadcom will have more incentive to meet the RPi Foundation's specific needs. If Broadcom knows that RPi is not talking to other vendors, then their negotiating position is stronger.


In the real world. I’ve been working for large vendors for literal decades and I can tell you outright that you own us if you’re a big customer, even if we are the only vendor in sight, and no one gives a shit if you’re spreading out your business.

This is 100% a natural consequence of the need to make your quarter. A bigger deal is much more influential than a small one, consistently. Sales incentives also do this.

People who have not actually worked in the industry with a solid eye for how this works often think that having multiple vendors is a good answer, but it’s not. Having optionality helps, but in the end it’s all about deal size.


You generally get bulk discounts. The more vendors you have, the more expensive each is.


Also think of the added development expenses, which might even overshadow forgone bulk discounts


For different SoCs? You would just choose one vendor per device generation (but always evaluating multiple). It is a new order anyways.


It's highly likely they have a sweetheart deal with Broadcom in exchange for loyalty.


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.

This is very, very disappointing.


> Are you saying the hardware actually has encode on die but was "fused" off?

I don't think that is what they are saying, and I haven't seen any evidence of that. It makes the most sense to me that either (as GP said) they got rid of the H264 hardware to save on paying Broadcom for the rights to include that hardware block in the chip, or to save on the die area they take up (as RPi said), or both.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: