111–120 of 121 posts
Earlier quoted context omitted.
They went through this rigamarole because it's an animation and animated gifs aren't great.
... And they made it an animation because of the limitations they built into iOS.
Say, something with more than a few dozen frames?
Earlier quoted context omitted.
... And they made it an animation because of the limitations they built into iOS.
Would anyone deliver an actual video this way? Say, something with more than a few dozen frames?
To make this anywhere near possible on a large scale would be feasible though. The easiest way would to be create the manifest while encoding the video. Take the same compression scheme but save the encoding diffs for every frame.
Seems like a terrible use of time.
Man, I wish there was a library to help us normal folk do similar things. The ability to do small video on mobile would rock.
You know, that this isn't exactly a video... If you really need to play a small video like that... try using gifs. It's easier, and there is only two drawbacks : 1- The stumbling loading of frames. 2- You can't do the thing they do with the earphones, going back and forth in the "video". If you're fine with these two drawbacks... You probably don't need all that over-engineering.
Earlier quoted context omitted.
Would anyone deliver an actual video this way? Say, something with more than a few dozen frames?
It would be unfeasible to do so. Assuming the displayed image is a reasonable size, say a dimension of 320x240, you would run out of pixel space in a jpeg due to dimension limitations after about 38 minutes @ 24fps. Granted, that's not using the manifest, just straight skipping around in the sprite. To make this anywhere near possible on a large scale would be feasible though. The easiest way would to be create the m…
Real-world video (filmed with a camcorder, not just a screencast) of any length probably wouldn't work well at all with this compression scheme, though. Apple's JS video compression basically only optimizes out parts of the image that don't change at all. If you're filming the "real world", pretty much every 8x8 block in each frame is going to have changes (it's basically guaranteed due to sensor noise, lightbulbs flickering, etc).
Earlier quoted context omitted.
Right. Now center it vertically. Also don't make any assumptions (like fixed height, or display: block) about container and the box to be centered.
http://cssdeck.com/labs/aqdw0l21/0 Container has fixed dimensions in my example, but it does not matter in this case.
Btw. your approach is exactly same that we had 10 years ago but with CSS table behavior faking rather than table tag.
Yay. Progress.
Earlier quoted context omitted.
How do you know they feel they're getting 'bit'? Maybe they think this is the optimal solution for what they are trying to accomplish? Maybe they have an internal tool for generating the images they need to accomplish these things? Maybe it's "smooth as butter", as they would say, on their side?
There's a reason that we have video codecs like mpeg and h264 instead of using mjpeg for everything; the compression is much better. In that sense, a stream of jpegs is far from optimal, even if it's smooth as butter on a fast connection.
About the last paragraph, we (Adinpsz) tried the PNG compression technique for JS demomaking (actually it's even a self-loading PNG-HTML ;)). You can learn more here with the JsExe tool: http://creativejs.com/2012/06/jsexe-javascript-compressor/ And see it in action here: http://pouet.net/prod.php?which=59071 (http://adinpsz.org/online/fabrik/)
But HTTP compression should be better anyway for "real world" usecases?
Maybe they should have used flash instead. That would have given them a higher percentage of successful deliveries than this solution.