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.'"

Ignores the real use of flash

[Anonymous Coward]

Video games, whores, web conferencing, etc.

Re:This meets all of Apple's requirements except o

[fuzzyfuzzyfungus]

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.

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 .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.

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 .flv) as a container format, it

Re:This meets all of Apple's requirements except o

[node 3]

(Not that I think RipCode is particularly relevant. If it's not installed out of the box, people are going to year that "YouTube doesn't work on the iPad", and either they'll care about that or they won't. If YouTube is a big deal to them, they won't buy the device, and if it's not, then they won't need RipCode.)

Except YouTube does work on the iPad (and iPhone).