The old (by now) CMOSIS CMV12000 does 4000x3000 pixels at 10bit per pixel and 300 Hz. It reads the 4000 pixel rows in parallel, from the bottom and the top. Th

The old (by now) CMOSIS CMV12000 does 4000x3000 pixels at 10bit per pixel and 300 Hz. It reads the 4000 pixel rows in parallel, from the bottom and the top. There's no hard reason why this couldn't be extended to a larger sensor, with the per-row time at-worst linearly increasing with the row count (due to capacitance on the column-lines). But even then, the row count would only have quadratic influence on the readout time, and the column count not at all. Combines to, for fixed aspect ratio, a constant number of pixels-per-second. So going to the 8k equivalent of 8000x6000 pixels (48MP), you'd quarter those 300fps and still have 75fps left. Assuming you take wide-screen video of 8000x4320 (some sacrificial columns that don't matter for speed and double the rows of "4K" (2160p)), the reduced row count would take that up to ~104fps. Oh, that chip also has a pipelined electronic global shutter, so you can take the long exposure of a HDR stack while the short exposure is being read out. Also no jello and shutter down to 1/50000. How big of a sensor were you thinking, that RAW video recording would be inconceivable for the big sensor? And yeah, sure, you'll have to do something with those many gigabits. It's about 36 Gbit/s for the above example. A PCIe4x4 connection would do, but you'd need about 2-and-a-half PCIe4 M.2 SSD's worth of sustained sequential write to handle uncompressed RAW.