Wow, I totally forgot what it stood for - thanks for reminding me! I was just digging up the old snapshots of the site on archive.org . Were you involved in the project at all? I wonder if I still have any builds/files on any of my old MO disk backups from those days..!
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.
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.
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.
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.
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.
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
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.
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.
> 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.
Telegram would definitely be an option, it's just that neither I nor my family + friends are really on Telegram. I've spent years slowly convincing folks that Signal is The Way™, but unfortunately Signal isn't as amenable to API usage.
