I've got implementations on top of libjpegturbo that can encode with latency low enough to support interactive frame rates at modern resolutions. We are talking 1920x1080@4:4:4 in under 10 milliseconds.
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.
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).