Bravo. I love JPEG. Amazing that it's been 23 years since its release and it remains as useful as ever.
I remember what it was like to watch a 320*200 JPEG image slowly build up on a 386SX PC with a VGA card. Today, a HD frame compressed with JPEG can be decoded in milliseconds. This highlights the secret to JPEG's success: it was designed with enough foresight and a sufficiently well-bounded scope that it keeps hitting a sweet spot between computing power and bandwidth.
Did you know that most browsers support JPEG video streaming using a plain old <img> tag? It works also on iOS and Android, but not IE unfortunately.
It's triggered by the "multipart/x-mixed-replace" content type header [0]. The HTTP server leaves the connection open after sending the first image, and then simply writes new images as they come in like it were a multipart file download. A compliant browser will update the image element's contents in place.
According to those links, they still support it for images, but removed support for other types of resources.
It's too bad IE never supported multipart/x-mixed-replace or we might have seen more live updating websites earlier. Now that we have WebSockets and well understood long polling approaches it doesn't matter any more, since x-mixed-replace would keep the download spinner spinning forever and the newer approaches don't have that problem.
I used multipart replace in firefox for streaming data for years with no download spinner. I couldn't use it in chrome because chrome always seemed to have some weird bug where 'frames' (of data in my case) were delayed.
I was disappointed when they were unceremoniously ripped out, but yes, websockets are better.
Ok, I believe you, it's been over 10 years since I tried it :-) Maybe I was thinking of the forever iframe, where a regular application/javascript document had content added to it incrementally over time.
It is actually pretty bizarre. If you point Chrome at a .jpeg that does multipart/replace it will stall, giving you roughly 0.2 fps. Point it at a. .html that contains an <img> tag and it works fine. Found this out while hacking on Hawkeye: https://igorpartola.com/projects/hawkeye/
It is interesting that you take up JPEG video streaming with the <img> tag in the context of a mozilla project. It works great in Chrome and Safari but in Firefox mjpeg streams only show the first frame. Here is the bug for it https://bugzilla.mozilla.org/show_bug.cgi?id=479015 which is unconfirmed since 2009, so clearly there is nobody over there who cares about this functionality.
I used a picture viewer named LXPIC in DOS on a 486 to look at JPEGs - and it was incredibly fast and small. Apparently it works even on the original IBM PC with an 8088, but I've never tried that.
There's no fundamental difference between MJPEG and streaming a sequence of independent JPEG files over HTTP.
The MJPEG format doesn't really exist anymore: it was designed in the '90s to account for interlaced video content, but that's a rare breed nowadays. For progressive video, Photo-JPEG is equivalent.
Many popular intraframe video codecs are basically the JPEG algorithm with some modifications for specific pixel formats and some custom metadata. These include Apple ProRes, Avid DNxHD and the stalwart DV format (as in MiniDV tapes).
I remember what it was like to watch a 320*200 JPEG image slowly build up on a 386SX PC with a VGA card. Today, a HD frame compressed with JPEG can be decoded in milliseconds. This highlights the secret to JPEG's success: it was designed with enough foresight and a sufficiently well-bounded scope that it keeps hitting a sweet spot between computing power and bandwidth.
Did you know that most browsers support JPEG video streaming using a plain old <img> tag? It works also on iOS and Android, but not IE unfortunately.
It's triggered by the "multipart/x-mixed-replace" content type header [0]. The HTTP server leaves the connection open after sending the first image, and then simply writes new images as they come in like it were a multipart file download. A compliant browser will update the image element's contents in place.
[0] http://en.wikipedia.org/wiki/MIME#Mixed-Replace