I ordered a Jetson Orin Nano Super developer kit. At that price, it was hard to resist trying it. My more ambitious thought was an 8K stereo camera, although the missing hardware encoder was an obvious complication before the board even arrived.
The order is the concrete part of this story. The camera is a plan. I wanted to explore how far the board could go, and delivery was expected before the new year. There was no completed capture result hiding behind the enthusiasm.
NVIDIA's Super announcement emphasizes increased compute performance and memory bandwidth through a new power mode. Those are useful capabilities for vision work. They do not answer the separate question of how two high-resolution camera streams will reach storage in a usable format.
Follow the frames
A camera system is a chain. Sensors produce data, an interface brings it into memory, processing changes it, an encoder compresses it and storage accepts the result. Every stage has a throughput requirement. A large number beside "AI performance" does not tell you whether the whole chain can keep up.
For stereo, there are two images to preserve and a relationship between them. If the left image and right image describe different instants, a moving subject produces inconsistent depth cues. Matching their resolution is not enough. Timing, exposure behavior and dropped frames matter as well.
Encoding is particularly important on this board because the Orin Nano does not include NVENC. Software encoding uses resources that other parts of the system may also need. An uncompressed capture path avoids the codec's work but moves the cost into memory traffic and storage bandwidth.
As an illustration, two 3840 by 2160 images in 8-bit YUV 4:2:0 contain roughly 25 MB per stereo pair before container overhead. At 30 pairs per second, that is about 746 MB per second. This is arithmetic for a hypothetical format, not a measured result from the kit. It is enough to show why "just record both eyes" deserves a careful plan.
I would split the experiment into stages. First establish reliable capture and inspect timestamps. Then verify that both streams can be recorded for a sustained interval. Add processing and encoding only when the simpler path is understood. A short preview can hide buffering that a long recording eventually exposes.
The useful measurements would include missed frames, latency, CPU load and actual bytes written. Temperature and power mode also belong in the notes, because a result that lasts a few seconds may not survive a longer session.
The attraction of the Jetson is having a compact place to connect cameras, run vision code and experiment close to the input. Even if the original camera idea needs a different encoding path, the board can still be useful for learning where the limits are. For now, I have an order, a set of questions and a good reason to start with the frame pipeline rather than the headline specification.