> so playback is entirely dependent on network delay
Ultimately true, but I set up my server to send each "frame" separately, with a fixed delay between each. Each frame is small so unless your network is unusually slow, the timing is set by my server.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
[2] https://www.ioccc.org/2013/mills/index.html
The "Refresh" header is encoded backwards on this line:
https://github.com/ioccc-src/winner/blob/619f554bbdb19e5003a...
https://en.wikipedia.org/wiki/Motion_JPEG
I've been here screaming "Motion JPEG EXISTS and is well supported in browsers" the entire time those gif hacks were popular. I've built a bunch of cool stuff with it.
https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php
https://github.com/donatj/imgboard/blob/master/main.go
The PHP example here is an illustration of how easy it is to pull off, and the Go example is part of a JavaScript-free multiuser drawing board.
"Hmm how can we use this for fingerprinting"
During the week, well, it would be unfair to call it LinkedInified, but it can often feel like a somewhat higher tier of that sort of strata. Plenty of good stuff in there still, but much more “serious business”.
This is how we defeat skynet: by sending each other pictures of cats.
A progress bar for something that’s loading in parallel over the same network, to give the user an idea of how much the delay is?
I mean that the "remove a word" 'symbol' is a 'word' that represents the verb he was trying to invoke, by sounding like it.
Birds chirp, bees buzz, moderators, toilets flush.
That's basically the server telling the client 'That data I just sent you, well now replace it with this new thing'.
No JavaScript needed, and can work with plain http and jpeg
You can use Service Worker to emulate a slow connection :)
Works fine for me in desktop Firefox. But on mobile iOS the “whole video within a jpeg” is 3 frames, all of which are nearly entirely solid color brown->orange->red with a vague cat silhouette. The color changes each frame, so you can tell it’s “working” but it’s certainly not what I’d call a video.
I was surprised when I pulled it up on my desktop and it did actually play like a video. Wonder if it’s causing some weird iOS image decoding glitch/edge case.
Maybe you just don't notice? It can be pretty invisible sometimes. I sometimes notice that image soon after page load an image is slightly blurry, and then another pass "sharpens" it. Yeah it's not like in the "old times" when the first progressive level was almost unreadable, but there's still value in sending a lower resolution version of image in 30% of the total file-size, basically for free
The observations you are reporting are from images you created yourself and you know are in fact progressive jpegs? (not "regressive", although that's funny). There are of course other techniques to start with a lower resolution image that do "work" (in the sense of actually displaying a lower resolution image first at least).
But if better compression for storage or you can verify progressive serves faster then it is of course a benefit.
I guess the point I am making is that most people think: I heard it's somehow better so lets use it.
But a lot of people do have slow connections sometimes.
And it is possible to losslessly transcode JPEG to progressive.
Lossless transcoding to JPEG XL gives even more space savings though.
Still the question is, does it help? Trying to access an average web app will probably take minutes before the browser may even see an image. If you do everything possible to render reasonably fast on very slow speeds, then progressive is nice. On a fast connection I don't think the average user will notice the difference.
But this is clever - just smash them together. Low frequency of one image concatenated with high frequency from another. This works surprisingly well!
This also reminded me of MRI where low frequency is acquired first in a space called k-space
