Veering a bit off topic here, but I somewhat recently used MJPEG for a "live preview" type of application and found support on the browser side to cause no end of frustration. Details escape me now, but some browsers could never be made to stop streaming without closing the tab, certain versions of Chrome didn't work at all.
It felt great to finally figure out the correct HTTP header incantations to get a working-ish solution with MJPEG... but if I had time to revisit it I would have tried instead encapsulating JPEG frames in WebSocket messages and blitting them to a canvas with JS.
MJPEG seems to be firmly in legacy territory and while browser vendors have to keep supporting it for IP cams, it's probably going to keep getting hit with the regression stick. Meanwhile WebRTC is notionally the correct replacement technology but the complexity is high and support is still hit or miss.
It felt great to finally figure out the correct HTTP header incantations to get a working-ish solution with MJPEG... but if I had time to revisit it I would have tried instead encapsulating JPEG frames in WebSocket messages and blitting them to a canvas with JS.
MJPEG seems to be firmly in legacy territory and while browser vendors have to keep supporting it for IP cams, it's probably going to keep getting hit with the regression stick. Meanwhile WebRTC is notionally the correct replacement technology but the complexity is high and support is still hit or miss.