Using multiple CPUs for encoding goes way back. The early (1994) C-Cube MPEG-1 and MPEG-2 real-time encoders for DirecTV were built with 8 chips running in parallel (out of necessity since they were only 60 MHz processors) to encode 704x480. Each chip encoded a slice of the image and an auxiliary bus was used to send reconstruction video between chips so that motion vectors could cross chip image boundaries.
Here's a picture of the VME bus development board. It was a two board sandwich to support 10 chips in parallel (only one board pictured).
The first real-time HDTV encoders for terrestrial digital television (ATSC) were built by Harris using an IBM encoder chip. It took 6 chips to encode 1920x1080. The IBM chips didn't have an auxiliary bus, so you could see motion vectors limited to chip image boundaries (in this case, 6 tiles arranged like so).
Yeah at this time intel was just releasing their quick sync tech and a few vendors were putting 4 intel cpus on a pcie board and using it for video encoding! Matrox also had a considerable piece of this business doing video compression and editing/compositing using bespoke processors and boards.
Despite being more "power efficient" - both nvidia and intel's hardware solutions left a lot to be desired in terms of final quality for the same bitrate, compared to x264 that seemed to just put out substantially better quality video for the same bitrate even at the same h264 profile levels. There are still lots of x264 design elements, some even verbatim ported, into modern av1 and hevc encoders.
As someone doing a lot of DVD transcoding at the time, I remember being excited for Quick Sync on my new Sandy Bridge build - only to find that, while fast, it had absolutely _horrendous_ quality. I revisited it on my previous main Plex server build, which I think was a Haswell, and it was still unusable for transcoding compared to x264.
It took Nvidia until the encoder they bundled into 20xx series cards and Intel until the 6th or 7th generation of Quick Sync, but their hardware encoders are _finally_ at a point you can get decent quality at reasonable bitrates. Even so, x264 (and x265!) beat the pants off of them if one can spare the time and electricity; they're still that far ahead.
There's never been a recorded S5 solar radiation storm. The highest level recorded was 43000 or S4 back in 1991. Another S4 storm occurred recently back in January 19, 2026 with a recorded flux of 36976.133.
Some of the accounts linked with those events are almost of biblical proportions. Red crucifixes on the sunset (associated with the 774–775 carbon-14 spike), sky serpents and so on.
The unpredictability of those events is a major point of anxiety by the way. We don't know enough to predict when the next big one will hit, and modern society has never seen one (the Carrington Event being the closest match, but still timid compared to the proxy evidence we have for what a strong solar event could be).
Your comment sounds dismissive. Did you intend it that way?
The table you cite goes back to the 1960s. The weather in the article occurs about 100 years before that. Not recording an S5 event doesn’t mean humanity has not experienced one.
Whether it’s worth preparing for is another issue entirely.
In 1981, my first job in Silicon Valley was obtained by answering a blind (no company name) ad in the Mercury News. It was a kooky company that built burn-in ovens for semiconductors (mostly 2164 memory chips back then).
I had a lot of fun there. The purchasing manager was a Scottish guy and he had an after hours drinking club in a small conference room with a wet bar. I was only 24 years old and working crazy hours. I'd get a few beers around 7 pm and then go back to work writing 8080 assembly language code for a few more hours.
I also ended up smoking weed with the CEO and CFO a couple of times. The CFO was not a young guy. I'm not sure how old he was, but he had all white hair. The CEO gave me a mason jar full of his homegrown weed as a gift when I finished the project.
That company and even the building is long gone. It's now a Google parking garage.
MPEG-2 video is still very much alive. In the US, almost all terrestrial OTA broadcast (ATSC 1.0) and all SD channels on cable systems. Even Comcast VOD was all MPEG-2 (including HD) until they shut down the QAM version in 2023.
The way I see it, if you were to draw two graph lines showing the prevalence of H.262 and H.264 over time, it would show of course that H.262 has lasted much longer so far just by virtue of it being older yet still in active use, but the area under the H.264 line is probably already or tracking on being much larger, depending on many factors, such as how you quantify "prevalence".
I don't see H.262 as becoming completely irrelevant any time soon, so it's clearly had a hell of a run, but I expect H.264 to wind up having a similarly long tail. I am not sure I'd bet on it being longer, but I wouldn't bet against it either. I'm only of the opinion that H.264 will have one of the longest of any video codec, but perhaps not the longest.
I was the project engineer for the Air Force Space Command / NORAD DSP satellite ground network back in the 80's. The system used the 10MB 8" Bernoulli drive and cartridges to store the early warning message traffic. The system was installed in 1988 and was decommissioned around 2005.
I'm not sure if they used the 8" cartridges all the way to 2005, but I can find out. I'm still friends with the original system maintainer. I pivoted to video compression in 1993 and lost track of the program, but we found each other on Facebook in 2010.
Rather than potentially 1000 HN readers each spending 15 minutes on Google trying to work out what you are talking about, may I suggest that you expand that with a few plain English sentences that tell us what that means?
I have no idea what "ATSC" means, and I've been in tech for nearly 40 years now so I have a fairly good handle on this stuff.
Advanced Television Systems Committee. It's the US standards organization for terrestrial digital television. ATSC 3.0 is a new standard that's very similar to DVB-T2 (used in the UK for HDTV) at the PHY layer.
The article kind of disses the Intel 8085. For those of us with 8080 code bases that were never going to be rewritten for the Z80, it was a welcome upgrade. On the paper dryer process control systems I was working on in 1979, the 8085 based Intel 80/30 Multibus SBC could be dropped in for the older 8080 based 80/20 SBC with no changes and provide a significant 2.5X performance upgrade.
I don't have enough hubris to assume I know things the people on LKML (or actually netdev in this case) don't. If anything, I might unicast a mail to Steffen.
Here's a picture of the VME bus development board. It was a two board sandwich to support 10 chips in parallel (only one board pictured).
https://www.w6rz.net/scorpio.jpg
The first real-time HDTV encoders for terrestrial digital television (ATSC) were built by Harris using an IBM encoder chip. It took 6 chips to encode 1920x1080. The IBM chips didn't have an auxiliary bus, so you could see motion vectors limited to chip image boundaries (in this case, 6 tiles arranged like so).
reply