Show HN: Forget Flash, Skip GIF, Control iOS(divergentmedia.com)
divergentmedia.com
Show HN: Forget Flash, Skip GIF, Control iOS
http://www.divergentmedia.com/blog/fullpost/phosphor_introduction
36 comments
So Apple dug a hole by:
- not allowing iOS to play videos in-DOM.
- 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…
- not allowing iOS to play videos in-DOM.
- 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 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%.
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).
[1] http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...
[2] http://github.com/sublimehq/anim_encoder
It's similar to this implementation, and his source is available on Github[2] (written in Python).
[1] http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...
[2] http://github.com/sublimehq/anim_encoder
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.
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.
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.
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.
True. I use Opera on desktop, so I should know to use the distinction. I just hate the browser alternatives on iOS so much I repressed them. :)
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.
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.
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.
I'll give it a re-run in the morning, sounds like a good idea. As does the path prefix :)
This is really cool!
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.
https://gist.github.com/4627207
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.
https://gist.github.com/4627207
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...
This looks great - And fits perfectly into a need I had at the moment for sharing smaller screencasts.
I had a few crashes with it this morning on a rMBP, what's the best route for support ? (your forums do not seem updated yet for phosphor)
I had a few crashes with it this morning on a rMBP, what's the best route for support ? (your forums do not seem updated yet for phosphor)
You can email us at [email protected]. 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.
So I can animate a movie/short film, take a screencast of it, and use Phosphor to render the movie on the client side?
That plus html5 audio could be a new low bandwidth way to stream movies in the future
That plus html5 audio could be a new low bandwidth way to stream movies in the future
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)
On iPad 1 all samples from the Gallery run at, what feels like, 1-2 fps. The screeencast in the blog though is very smooth. Why's the difference?
Same on the iPhone 4S. I have a feeling it's because they're all running at once.
Any research into how the download size compares to a similar video asset?
Do you have plans for native ios and android views?
Do you have plans for native ios and android views?
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.
-mike
The general rule of thumb for file size is h264 is smaller than phosphor is smaller than gif.
-mike
[deleted]
Does it have an overlaid div fallback option?
Currently no... it's on our list to do, but feel free to fork the player in github if you need it ASAP.
-mike
-mike
Wasn't this first seen on Apple's website for the iPhone 5 animations? Now this company is selling software to reproduce this effect for $9.99?
I haven't checked yet, but I wonder how much of the JavaScript output by this app is identical to what Apple wrote.
I haven't checked yet, but I wonder how much of the JavaScript output by this app is identical to what Apple wrote.
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.
$9.99 for an encoder that let's me autoplay animations cross browser and on mobile? Sold!
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.