It’s pretty fast, but I’m not sure it’s the fastest.

If you want throughput, hardware-based h.264 gonna be faster than JPEG while delivering better quality. It’s possible to configure the encoder so it only emits keyframes (I-frames), which makes the video stream a sequence of independent compressed frames. However don’t forget about parameter sets, i.e. SPS/PPS blobs – the decoder gonna need them for each frame.

If you want latency, consider BC1 https://docs.microsoft.com/en-us/windows/win32/direct3d10/d3... or BC7 https://docs.microsoft.com/en-us/windows/win32/direct3d11/bc... They are lossy codecs usually used for textures in 3D scenes, the decoders are implemented in hardware in all modern PC GPUs. The algorithms are way simpler than JPEG, also easily parallelizable. Compression ratio is much worse though, for RGB24 images it’s 33% for BC7 and 17% for BC1, JPEG compression is way more efficient.

You can get libx264 to encode 1080p in under 10ms if you spend enough time tuning it, altough I never compared the quality to JPEG.

The fact that it is multi-threaded (where .jpeg and .png are not) is also a huge deal.

Motion JPEG is widely used as a simple video streaming format.

Yes, but it stems from the fact that some phone manufacturers decided to reuse the hardware IP they already had in place for JPEG compression instead of paying for another chip that could do MPEG. It works, but it's not compression.

Then for some weird reason it gained traction as a "good quality video codec" (probably because there's no motion vectors, hence the associated artifacts simply can't happen with it).