Slashdot Mirror
Flash Comes To the iPad Via RipCode
suraj.sun writes "Texas-based company RipCode has announced a new 'clientless Flash video codec' that will allow Flash content to be streamed on Apple's iPad. This would include sites like Hulu and YouTube, assuming the respective companies don't find a way to block it. According to RipCode's press release, the TransAct Transcoder V6 captures the iPad's request for Flash content and converts it into a special format that the device accepts and plays. This is all done without a local client or user intervention. 'RipCode's Transactional Transcoding platform enables an alternate and immediate solution to this issue, opening up video content to users without requiring the content hoster to move to HTML5 or pre-transcode entire video libraries from Flash to an iPad-accepted container format. By transcoding the content "in the cloud," it is essentially analogous to a network-based Flash to MP4 or MPEG-TS video adaption layer.'"
Killing flash.
Thus, I'll expect they'll patch in a way to detect and block this ASAP.
"Waste not one watt!" - CZ
This could actually hasten the demise of flash (assuming that's actually going to happen at all...), if the format it transcodes into is universally playable.
On the fly transcoding every time a piece of content is accessed seems is a fairly excessive load on the server, so presumably the videos are either pre-transcoded en masse or transcoded on demand and then cached for future access.
In either case, the content provider is left with a pile of flash videos and a separate pile of videos in this new format (site seems to be down, so I can't check what that actually is). If the mystery format is, in fact, playable on non-Apple devices there's no real reason for them to keep hold of the flash versions - why serve two copies if the iPad version does fine for PCs as well?
It does.
From what I understand, this reads flash videos without using flash code. There is a difference between flash code and flash codec. One is an insecure runtime that is a blatant hole inside a device's security and allows arbitrary code execution, the other is just a regular video codec that VLC can read.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
Apparently CPU power for transcoding Flash and bandwidth for streaming the result are both free, if the cloud is involved. What's in it for them?
I don't understand why people mix up Flash and Flash video all the time. The latter is a small subset of the former. Can you really not conceptually tell the difference between a video playing at youtube and the content at http://www.homestarrunner.com/ ?
Why? All it does is remove any incentive for ad agencies to switch to HTML 5. Again, you need to think bigger than flash video, for the most part digital ad agencies practically breathe flash and very often develop simultaneous desktop/web deployed applications with it (Zinc, AIR).
Given that most flash videos are actually mpeg 4 or h264, but wrapped up, it probably wouldn't put major load on a server to "transcode" on the fly –all they need to do is recontain the video.
Flash's demise will have nothing to do with something as inconsequential as RipCode. Let's be clear on what RipCode is: a Flash video replacement. What it isn't: Flash.
You know all those websites created in Flash, with Flash menus and Flash fonts, etc? You know, the ones with something called ActionScript going on deep down where you interact with the website... well, Ripcode doesn't even begin to replace them, it only replaces Flash video.
Now, RipCode may provide a stop-gap solution for displaying video until HTML5 fully arrives, but a Flash replacement it ain't. A strange (on-demand video re-encoding at the server??) temporary solution that will be obsolete in a year, it is.
For a substantial percentage of "flash videos" I would suspect that no real re-encoding is necessary. Ever since Flash 9.something, the Adobe flash player has been able to decode h.264. A fair few "flash based" streaming sites took them up on that pretty quickly. The .swf blob just provides some widgets for playback/volume/time slider, and pulls the video from some URL(usually found in the page source, sometimes obfuscated a bit). Even before 9.something, the prior .flv format, while not as standard s h.264, is publicly understood and playable(just as VLC). In all these cases, and they cover a large area, the only real challenge is working past the weak obfuscation, if any, to find the actual source URL for the video, which is already in a workable format, and just grabbing it. For individual video capturing use, "View source" and a couple minutes of thinking is usually sufficient, with Wireshark and a filter looking for HTTP GET requests waiting in the wings if that doesn't work. If you want to release a product, though, it has to work automatically, preferably without you dedicating employees to manually building per-site rulesets that the app has to pull down on a daily basis. That could be a bit tricky, so it would be interesting to see how they do it.
.swf and a .mp4 from any commodity webserver is way cheaper than using Adobe's "secure streaming solutions" and, if you are one of the hundreds of more-or-less-youtube-clones out there, expensive software is a greater threat to your solvency than a few people downloading and watching video offline.
.flv) as a container format, it
Adobe does offer some slightly more sophisticated and DRM-y streaming delivery methods, for those delivering their precious "premium content" via flash(and I have no idea what the RipCode guys are planning to do about that, since, even if solving that one is technologically trivial, it is almost certainly DMCA-violating). Most of the guys in the cheap seats don't bother, since just serving a
The case that would be technologically tricky(but which is becoming increasingly uncommon) is what people used to mean when they said "flash video", which was a script-driven vector-with-occasional-bitmap-bit-and-a-soundtrack flash object, rather than just lossy compressed video that happened to be played by flash. For the ones that are purely non-interactive, you could basically just do a screen capture, and compress the result into a standard video format; but you'd have to do some sort of fairly clever algorithmic parsing to deal with the ones that were mostly just animation; but had some limited interactivity(even if it was just a start/stop/mute button).
The second main question, aside from "how are they going to process the flash?" is "How is it 'clientless'?". Even when dealing with the most trivial case(.swf player object being used as an embedded player for an h.264 video whose URL is clearly evident in the page source), their software is going to have to get a word in, to rewrite the page, removing the EMBED and replacing it with an HTML5 VIDEO widget with the appropriate video URL. There is Absolutely No Way that Apple is going to approve some sort of plugin for mobile Safari. Is their plan to have people browse through a basic proxy page, controlled by them, that does the rewriting(and a little analytics and spying on the side, just to pay the bills?), or are they going to have an App that uses Safari for page rendering, with their own mogrification sauce for the flash bits?
Press release is slashdotted right now, so I can't get details; but I'm not terribly optimistic for this outfit(unless they have some brilliant insight into the problem that isn't evident from TFS). Pretty much all the sites where automated transformation of flash blobs to iPod-accepted video would be a simple problem will probably make the change themselves in the fairly near future. If you are already using h.264(or even
This one person doesn't speak for MacWorld. He is a contributor (right up there with blogger). If you actually read the piece, he obviously dislikes the small screen. He reiterates that point many times in many different ways, meaning he won't be satisfied with any small screen for regular day to day use. The article is more of a piece about the wasted time trying to do real 'work' on a small screen than a statement about the iPad itself.
As to the article summary, they should realize that YouTube already pushes H.264 to Apple mobile devices.
And fonts are so 1990. Most of us are so over being wowed by the fact that a site has 10 fonts that should have never been allowed to be on the same page.
About the only two things that most people see as useful flash is watch movies and, maybe, google finance and the like. For kids the flash games are important. Most users would be perfectly happy with the former in a non-flash wrapper, since the only reason it is to provide some primitive form of DRM.
But, really, without the movies flash could go away and many would never notice. Except, of course, for the ad agencies.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black