Isn't it interesting how, caused by our inability to directly embed video onto websites, we are basically forced to reinvent video codecs in Javascript?
This basically means that on most mobile devices, instead of a hardware-accelerated decompressor, a slower, more CPU-consuming Javascript VM is in charge of video.
While technically impressive, I would much prefer the possibility of directly embedding (and controlling) real video.
- deciding not to support WebM, so Firefox users can't see their videos.
And now others are following them by helping to dig deeper in a vastly inefficient way of displaying moving images ?
What could previously be offloaded to dedicated engines is now going to burn the CPU via JS. Hum, now that's gonna work…
> a vastly inefficient way of displaying moving images ?
I don't see this as a MP4/WebM replacement (compared to which it is effectively inefficient) but a GIF replacement (plus it's scriptable and hackable in a number of interesting ways). I wish it were a real, self-contained file format, but APNG completely failed to displace GIF.
It's a hack, but it solves a real problem and it opens a venue for something less hackish.
Also, it's simple enough any developer can understand the algorithm, there's no patent looming over, no complex codec infrastructure (however layered away), and it's using only HTML/CSS/JS.
I viewed three examples simultaneously from the Phosphor gallery at http://www.divergentmedia.com/phosphor/gallery and each one only used about 5% CPU, for 15% total. I closed them and viewed a YouTube HTML5 video (no Flash on this machine) and it consistently used 70% CPU. It seems the Phosphor approach is more lightweight than video and it was entirely smooth (on a 2007 dual core MacBook Pro running a 64-bit Linux). If you don't need audio and want to include a video or presentation in your page that doesn't require a plugin and looks to be supported on a wide range of browsers and platforms, this looks like a compelling option.
The image frames in those examples are 250 x 250. There's no sound. It's video deconstructed into frames then those frames animated to re-form a second-rate appearance of the original video.
I can't believe it's not butter!
Funnily enough it's Flash which is the best performer out of those he lists. Attempting to mask and layer video in HTML5 is a painful scrapheap of half-baked canvas hacking and browser compatibility woes. And then it doesn't work very well anyway even when you finally get the canvas to kick in. Flash eats that kind of thing for breakfast, with easy alpha channels on video layers and so on.
I wish Flash would just make a comeback, improve itself as a mobile plugin for browsers, and we can all enjoy rights-restricted video playback in the browser (at least), and clever next gen web games without paying Apple 30%.
Jon Skinner implemented a similar technique to create and display screencast animations on the Sublime Text homepage. I was just reading his article[1] last night in which he discussed his technique.
It's similar to this implementation, and his source is available on Github[2] (written in Python).
Maybe this is a dumb question, but I'm probably not the only one wondering that: how do you capture the video from the iPhone screen in the first place? [Edit: oh, just realized you're probably just using the simulator?]
Otherwise, awesome app. I can definitely see myself using this to add short videos to my designs.
Check out http://www.airsquirrels.com/ they have an app that let's you mirror your iPhone to your desktop. It's very smooth. I use that, and then use a standard screen cap tool to capture the screen on OSX. Result is the ability to do full app demo on your iPhone and have everything mirrored to your screen. Also handy for sharing via a projector... Since it all goes over AirPlay you can demo without needing a cable/dongle off the iPhone.
For that demo, we used the iOS simulator app that's part of Xcode, along with normal screencapture tools (Screenflow in this case). I think that's the way most iOS devs do screencast content, though jailbroken devices can also do native screencapture.
The video was so smooth I didn't realise what the example was. I actually watched the example video through several times thinking "what? there's no video on that page!" before realising that the thing I was watching was the video.
HTML 5 video: iOS devices won't play video tags in the
DOM, they instead open in a standardized player. Apple
also stops them from auto-playing on iPhone.
This is what makes Vine so useless on iOS outside of the native app. It makes it preferable to use GIF sans audio generally, whenever it's an option.
I get where Apple is coming from, but this is definitely sorely needed for some use cases.
It's not "iOS devices". It's the default browser, Safari.
If you use, say, iCab, HTML5 video stays embedded in the page -- to a fault. Often you won't be able to full screen the video, you end up having to zoom the page.
Thanks! I've been debating doing something like this on one of my app pages. So I've gone and done it now: http://awesomeputioapp.com
Feedback: I didn't like that there isn't a nice way to put all of the Phosphorous code in a subfolder (warning my HTML isn't amazing, I do iOS.) without a find & replace and hunting for the things to change. Overall I'm a happy customer though! Good work guys.
I just took a look at the site, glad it's working for you! As for the moving, perhaps we should emit sample code with a location string you can fill with your path prefix? Sounds good to me.
As for your composition, I took a look and the atlas images seem large compared to what we tend to see. Perhaps try turning down the quality slider in the main page - all that affects is the post encoding jpg compression. 60-80% tends to look good.
But often you can't upload videos or javascript, but only a GIF, like on a github.com's README file.
For that scenario, I recently wrote up a quick tutorial on how to use Quicktime + FFmpeg + gifsice to easily create a short screencast and convert it into a GIF.
Looks fantastic, might try and think of a use for it at work and give it a whirl. I remember being very impressed when reading the 'teardown' articles about how Apple had achieved it, the gap between a GIF and a <video> tag has always had potential, imho...
You can email us at support@divergentmedia.com. We've found one crash and are prepping a fix to submit to the MAS, but we can email you a new build if you get in touch.
html5 video and a good codec are a way better use of bandwidth.
This technique is good for animations with few moving parts. For example the Alfa animation http://www.divergentmedia.com/phosphor/gallery#alfa needs to download 14 additional images for a total of 3.5 megabytes for a few seconds' worth of animation.
if you are animating the movie, just export from your app as prores. that's how some of our gallery clips are done (the logo spin for instance in blender 3d model rendered straight to quicktime)
In our tests, it depends a lot on the type of content. "line art" compresses much better than video. We left a lot of room in the format to make the encoder side smarter with time which will increase compression performance.
The general rule of thumb for file size is h264 is smaller than phosphor is smaller than gif.
The blog post acknowledges that the inspiration for the app was the Apple site (and a post on HN). None of the code is shared with their implementation (and all Phosphor's javascript is under MIT license, https://github.com/mikewoodworth/phosphorframework), and the Phosphor encoder itself is far more space-efficient than whatever toolset Apple is using internally.
I'm not sure what you're trying to say ... Are you upset by the capitalism or what, exactly? Need + ProuctThatSolvesNeed => Profit seems like a good plan to me. If you think it is just plagiarism ... that's a big accusation/assumption.
This basically means that on most mobile devices, instead of a hardware-accelerated decompressor, a slower, more CPU-consuming Javascript VM is in charge of video.
While technically impressive, I would much prefer the possibility of directly embedding (and controlling) real video.