It’s just an image, silly, don’t click here.
This is the second in a series of columns about interesting new technologies, in this case JavaScript video.
Three quarters of the bits being schlepped over the internet today are video bits, so video standards are more important than ever. To accommodate this huge load of video data we’ve developed compression technologies, special protocols like the Real Time Streaming Protocol (RTSP), we’ve pushed data to the edge of the network with Content Distribution Networks (originally Akamai but now many others). All these Internet video technologies are in transition, too, with H.264 and HTML5 video in the ascendence while stalwarts like RealVideo and even Flash Video appear to be in decline. The latter is most significant because Adobe’s Flash has been — thanks to YouTube — the most ubiquitous video standard. Flash video was everywhere. But with Flash apparently leaving the ever-growing mobile space, will we ever see another truly ubiquitous web video standard? We already have and it is called ClipStream G2 JavaScript video.
JavaScript is everywhere on the World Wide Web. If you have a browser you have JavaScript. Have an iPhone without Flash? You still have JavaScript. Have a smartphone without Java? You still have JavaScript. Even HTML5, the supposed future of Internet video, isn’t available yet on all platforms, but JavaScript is.
The Web couldn’t function without JavaScript. So if you really need to deploy something everywhere on the web, doing it in JavaScript is a great idea. But JavaScript video is difficult since the scripting language was never developed with video in mind. But as processors get faster and devices have more memory, the idea of doing video in JavaScript became more feasible even though it feels to me a bit like drawing the screen in crayon.
This new patented technology, only 17 years in the making, was just released in beta this morning. Here’s a sample video featuring someone you may know. It’s glitchy, but think of what an achievement this is. And think how much better it will play a month or a year from now.
ClipStream G2 comes from a Canadian company, Destiny Media Technologies, which has been around since 1991. They literally invented streaming audio, and launched internet radio before Windows Media, Quicktime or Real Networks even existed. They eventually moved into Internet video only to be killed when Flash came out for a lot less money and then YouTube for free. More recently they’ve built a business for professional musicians, securely delivering pre-release music for all the record companies to radio stations.
Now, with Flash abandoning mobile, Destiny sees an opportunity in video again.
“JavaScript powered video doesn’t sound like a big deal,” explained Destiny co-founder Steve Vestergaard, “except Javascript performs like a slug. We went from C and assembly in 1995 to Java in 1999 (maybe 100 times slower) to Javascript now (maybe another ten times slower). We have less horsepower in 2012 than we had in 1995, but we play everywhere. Some of the big guys, including chip manufacturers, see an opportunity to improve our performance and keep the cross platform aspect. Our seven patents are about how to do streaming video when there is no horsepower at all!”
Here’s what makes JavaScript video significant. It not only works on all recent browsers, it requires no streaming servers. Stick the Destiny folder on your web server, embed their code in your web page and that’s it.
Not only is there no special server, there’s also no player since the video is rendered by the browser. There is nothing to download or maintain.
There is no transcoding required and Content Distribution Networks like Akamai or LimeLight aren’t needed, either.
JavaScript video is also more bandwidth efficient since it looks like regular old web content and can be buffered for reuse in proxy servers. The company estimates that streams are reused at least 10 times saving 90 percent on bandwidth and infrastructure not to mention $4.3 billion in annual transcoding and CDN costs if widely deployed.
It’s not perfect, but then beta code never is. I think this is a major step, though, toward Internet simplification.
Sometimes you spend so much time and effort into optimizing in order to bypass a limitation that you miss the chance to leapfrog it entirely.
Great story.
Hey Bobo……..that sample video…..is it part of a program that I have not seen?
I try to watch everything you have done so I NEEDS TO KNOWS! 🙂
Surely it’s the never-released Super Genius All Merrikan Startup Roadshow Tour thing that Bob kept promising would be released.
Demo works well on my iPhone and on my Mac (Safari). Video quality is quite low.
On my recent vintage Mac, it used about 50% CPU. Very high compared to hardware h264 decoding. I can only presume how much puny iPhone CPU this will need and how quickly it will drain my battery. A deal-breaker for mobile.
On top of that, it doesn’t integrate as well with iOS as html5 does: No Airplay, can’t control playback from the headphones, or from the multitasking bar. I’m sure there will be analogous limitations on other platforms.
So, a great tech demo, but I wouldn’t build a company or expect to make much money around it. If someone is betting on letting CPU power and Javascript engines to catch up, I think they will be disappointed. It will happen. But by then HTML5 and h264 hardware decoding will be as widespread as Javascript, rendering this technology useless.
I think you’re ignoring the fact that this is clearly labeled “beta”. More a technology demo than a proposed product.
I don’t think you understand the technology
The issue is not that someone doesn’t understand the technology, it is that the technology is solving a non-problem.
Technologies that solve a (perceived) non-problem don’t gain traction no matter how great they are, JPEG 2000 is an example, as are Bob’s list of favorite techs that went no-where, from aluminum hard drive replacements to codecs that were somehow based on tracking eye movements.
The way this is going to play out is that at some point in the near future h.265 will be released. Apple will of course support it, and soon enough there’ll be HW for it everywhere. I expect at that point Google and Mozilla will also get on board, facing up to reality. No-one gives a damn about a codec written in a completely inappropriate language that can’t give the compression performance of h.265 and takes vastly more power (COU power and electrical power) to perform its task.
Better compression ratios at lower battery powers? = real problem.
How can I use a non-standard codec that just happens to be written in a totally inappropriate language? = problem no-one is asking you to solve.
Maynard Handley – I agree that it is not solving a current problem. But I am an innovator. Call me crazy. This technology opens a new door, and behind that door, is a place that very few talented people have ever looked. Once they catch a glimpse of what is there, their imaginations run wild, and mark my words, problem solving innovations will be conceived. Look at history.
Reminds me of the early days of Quicktime, the audio was delivered nicely but the video was choppy. Are they codec independent? How will H.265’s development affect them?
That is incredibly cool. :O
It doesn’t need CDN more than any other webpage, but lots of companies still use CDN’s for static content just to lessen the latency, right?
Nice tech demo, but you got carried away a little.
– “There’s nothing to download or maintain”
You still have to download the script that will render the video.
– “It requires no streaming servers”
It will, if you need adaptive bitrate or skipping into the video.
– “There’s no transcoding required”
I have all my videos in H.264 format, which browsers support. Do I need to transcode them to use that JS tool? I bet yes, or otherwise it’d print “H.264 support” in big letters everywhere.
– “Content Distribution Networks like Akamai or LimeLight aren’t needed”
Woah, wait a minute. CDN are about distirbuting bandwidth load, this has nothing to do with whether you use a binary codec, Flash, Java, a plug-in, an on-chip codec or… JS codec.
If you want to serve to a sizable audience, you need a CDN. If you don’t, well you don’t need a CDN for any codec.
– “JavaScript video is also more bandwidth efficient since it looks like regular old web content and can be buffered for reuse in proxy servers.”
That’s nonsense. Any static file can be cached by proxy servers, and I’m sure this JS codec need a much higher bitrate than H.264 for comparable quality.
Comparable quality being the key phrase (we already know crappier videos take less bandwidth, thankyouverymuch).
Yep, definitely got carried away with the proclamations at the end.
It makes it sound like using JavaScript, you don’t even need to download the bits for the video – they’re computed out of thin air on the client!
If the patent is for a technology that says (server side) “show ’em a video about cats!” and the client-side magically produces exactly the cat video you wanted without transferring any bits, then yep! Magic!
Otherwise, I don’t see how “streaming” and “CDNs” and so on can be avoided without a peering infrastructure getting the video bits closer to the client.
You’re technically right in many of your arguments but somehow miss the point.. repeatedly.
“You still have to download the script that will render the video”
– No YOU don’t… your browser does… but that’s painless which I think is the point.
“It will [require streaming servers] , if you need adaptive bitrate or skipping into the video.”
– I think you’re assuming a bit much. I bet they’ve thought about this a lot more in 17 years than you in 10 minutes. I can think of a way to allow skipping forward and still using a simple file server why can’t you?
“Do I need to transcode them to use that JS tool?”
oh boy.. are you ever missing the point…
Think more from the customer viewpoint…
From customer point of view, this this is a destroyed of mobile device batteries.
Every mobile device comes with a hardware accelerated H.264 decoder, on-chip.
I’m sorry but at this point it’s a solution in search of a problem.
I agree. This article is full of nonsense.
– Javascript can’t run anything, it is a language not a platform. This uses HTML5, just like the video-tag. It won’t run on older browsers.
– Java isn’t 100 times slower than C in most cases.
– Machine generated javascript can run quite fast nowadays, almost like C; look up the research on this. But not on video decoding, which should be done by the GPU.
– The HTML5 video-tag doesn’t need streaming servers as well for simple cases. And why not use a streaming server if you do need some power.
– The demo shows lots and lots and lots of http requests. Including all the fuss like cookies going back and forth. Like that is efficient! And sending jpg’s over the line isn’t going to be really efficient for video no matter what. Not for streaming and not for storing. Let’s use a photo codec instead of a video codec for video, yeah!
Again, this is using html/script for things it wasn’t designed for. Facebook just created a native iOS app to replace the HTML app. Everyone is happy.
It is not sending JPGs over the line. It is loading data urls. It looks like a remote request, but it isn’t.
Despite other’s reservations I think it’s great that someone is trying to reinvent a buckled and out-of-line wheel. About time too! The first “kick” I got out of the Internet – once I’d ooh’d and aah’d the pictures – was that rarity back then of video. Since then it’s all been warring codecs and their attendant apps; one or other claiming better quality to file-size ratio.
Anything that can simplfiy the game, make it more sensible and ubiquitous, has got to be a goer.
I’d be interested to learn what method is used to offer the stream if it is just Javascript. There must be something for Destiny Media Technologies to patent and make a living from.
And as PS – good to see Mr Cringley out in the fresh air for once! 🙂
HTML has audio API and a canvas (immediate mode graphics) API, which modern browsers support.
So it works literally like any codec: take content, decode it to a sound wave and pixels, and feed it into the APIs to show.
The JS API could “hijack” some of the browser’s decoding power by encoding inline JPEG delta and keyframes which it then mixes manually on the canvas.
Doing all this with JS is understandably slower, so don’t expect to watch high-def trailers any time soon. It’ll also take a lot more bandwidth for comparable quality movie compared to H.264.
Interesting… Thanks.
I wonder about bandwidth being higher though… Maybe routers offer in-line compression like my 56k modem used to do? With the “old” method a pre-compressed ZIP file or JPEG wouldn’t download quicker than a raw BMP or file because the modem struggled to compress a ZIP or JPEG further while an uncompressed format was shrunk considerably for transmission.
Mozilla showed software decoding of H264 in Javascript over a year ago: http://arstechnica.com/information-technology/2011/10/native-javascript-h264-decoder-offers-compelling-demo-of-js-performance/
and it’s Open Source.
Your Mozilla thing works great, at least as well as YouTube on Win7, IE8, 1.5 GHz Intel Atom. The clipstream thing doesn’t work at all right now. All I get is the “loading” animation symbol. Maybe it’s server overload since this is the first day for Bob’s current column.
I AM THE NINTH PERSON TO COMMENT ON THIS POST BOYYYYYSS WOOO!!!!
“HTML5, the supposed future of Internet video, isn’t available yet on all platforms, but JavaScript is.”
This video player uses the CANVAS element, which is a big part of what makes HTML5, “HTML5”. This won’t work on older browsers.
Video works well on iOS devices because of the dedicated H.264 playback chip. Android devices use hardware acceleration as well. You’re not going to get quality on mobile without it. You’re also going to drain the battery very quickly.
As far as I can see, the only upside to this technology is that it requires a single video file where you generally need two or three.
Too bad Google/Mozilla are being willfully obstructionist about native H.264 support. That’ll get solved eventually, but I don’t see JS playback of video taking off in the meantime.
Chrome and Firefox both support H.264. OpenChrome does too. The difference is that Firefox and OpenChrome are not distributed with built-in codecs, and don’t expect that to change anytime soon. However, they will both gladly use any codecs you have installed on your system already – whether Ogg/Theora, WebM, H.264, or anything else.
Apple should rather adopt a license free standard like webm or theora. H.264 is a great standard, but the web really needs an open and free standard. W3c needs to decide this, like, yesterday.
webm is far from being license free. It’s getting sued for patent infringement.
So what you’re saying is, there are very powerful entities out there who would like to ensure this is never widely adopted?
The demo worked perfectly on my system (chrome, windows7). Rather impressive but i am not totally sure it will be a prefect replacement for HTML5/H.264
I don’t think lower quality will win out. Sometimes it does, but this time it won’t. The reason is because mobile is essentially owned by Apple (H.264) and Google (VP8) now.
We have two intellectual silos defining what will happen on almost all mobile devices. That will hugely drive the future of all web video.
So while Bob’s article is a nice daydream about the triumph of a small company with a consistent vision, it is only a dream or perhaps an edge case for a tiny minority of users.
The overwhelming majority of sites will migrate to higher quality H.264 & VP8 that will play well on mobile devices.
“We have two intellectual silos defining what will happen on almost all mobile devices.”
This might be a business argument FOR a javascript video player’s success.
In my opinion, from an engineering viewpoint it would be terrible to decode video so inefficiently [with javascript] but then I feel that way about a lot of javascript applications ( including my own project)!
just gave this another try on my phone and it worked amazingly well. Better than things done in Flash (which imho is horrible on even the best phones).
If the cost savings are as big and stated then it would be interesting if someone like vimeo started using this.
It’s very impressive and yet with ubiquitous h264 hardware decoding I’m not sure I see the point. I assume they’re encoding the video as actual JavaScript commands (a neat trick a friend of mine used to write fast blitters back in the day).
Note that the implementation shown depends on the canvas element (HTML5), so the idea that this is a “pure JavaScript” technology and thus has broader support than HTML5 is currently, and foreseeably, incorrect.
That might explain why it doesn’t work for me…I have Javascript but not html5. But what I don’t understand is this statement from Bob’s article: “You still have JavaScript. Even HTML5, the supposed future of Internet video, isn’t available yet on all platforms, but JavaScript is.” I sure sounds like Bob expects it to work without html5.
Oh — I’m also not clear how Destiny Media can have invented internet radio before QuickTime existed when it was founded after QuickTime was released (and QuickTime had been in demoed at WWDC etc. for couple of years before the 1.0 release).
Watch out! The MPAA may issue a warrant against you! No centralized control required for finding out where the subpoenas to be issued to? Encryption on an individual transaction pair so no one (including the ISP and the NSA) can figure out the content? A Canadian company?
Mon Dieu!
I’ll join in with those that commented there have already been JS decoders written before; it’s not the worst idea and the new tech like HTML 4 Canvas and WebGL should help with that. Just for now, I’m not going to be holding my breath waiting for HD H.264 CABAC decoding done in JS…
I still have nightmares about ISO/IEC standards documents on MPEG 4 video (which includes H.264) – not so much about them being bad, but as to how much effort goes into making sure we can all play it back… the “Yet Another Proprietary Codec” game deserves to die.
The problem with internet video is not technology – it’s business.
This javascript video of yours was a great opportunity to confirm something that I knew … and a surprise.
Running Fedora 17 on my DFI LANParty UT nF3 250Gb AMD Socket 754 Motherboard w/2 GB …
Firefox 14.0.* stuttered and “buffered” something AWFUL (*as expected* because it is SUCH A DOG of a browser on x86 Fedora)
Chrome 21.0.* played it rather smoothly (as expected).
Well … cranked up the Windows 2000 Pro 750 MHz AMD Duron CPU-powered 500 MB ABit motherboard …
IE 6 SP1 had absolutely no idea whatsoever what the Clipstream video player page was trying to do. :^)
Firefox 3.6.10 could never get past the “buffering” symbol at the start of render though I waited 5 minutes…
Then I tried it with OPERA 10.51 and it played pretty well, a little choppy, but NOT BAD!
Bravo to Clipstream!
Is there any more tech info available? I mean it’s clear that they’re using canvas and javascript, but I was hoping to get a bit more info about what compression algorithm they use on the images, how the javascript works etc. (I had a look through the js on the page, but it’s kinda hard to grok)
The important script is at https://www.dsny.com/g2/arizona/first-min.js. It has been obfuscated, but there’s an app for (removing) that.
Only people who hate capitalism suck. Capitalism in a true form…..not a Dear Leader Obamao form……. is the most effective tool ever created.
[…] VANCOUVER, Aug. 23, 2012 /PRNewswire/ – Destiny Media Technologies (TSXV: DSY), (OTCQX: DSNY), the leading provider of secure distribution of pre-release music and playerless streaming video is pleased to announce that its new Clipstream® G2 technology was presented to the technology community through the blog site I Cringly: Cringely on Technology at http://cringely.com.  The feature is at https://www.cringely.com/2012/08/22/javascript-video-17-years-in-the-making/. […]
[…] javascript video – cringely […]
Nice video. I can’t wait to see more of it. (Hint, hint!)
The video ran quite well on a normal PC with a good connection to the Internet. For new Beta code it is an impressive accomplishment. It will be nice to see how it scales to handle higher resolution and faster frame rates.
I then ran the video on my puny Android phone, with no memory, a slow CPU, on a 3G data service. While it playback stopped a couple times to regroup, the delays were brief and it was able to play the whole clip. I have YouTube and Netflix apps on this phone. The often lockup and sometimes I have to reboot my phone.
So this is not bad.
“except Javascript performs like a slug. We went from C and assembly in 1995 to Java in 1999 (maybe 100 times slower) to Javascript now (maybe another ten times slower).”
This sort of quote is really depressing. Did they just defrost him?
V8 compiles the whole JS codebase prior to execution, then launches a profiling thread for hotspot optimisation. It’s not exactly hand crafted assembly, but it’s reasonable to say it’s running on the metal.
Benchmarks such as this are becoming common :
http://wingolog.org/archives/2011/06/10/v8-is-faster-than-gcc
There is extreme competition between the JS engine vendors, resulting in a performance war. Can we abandon the lazy anachronisms and assumptions now?
It didn’t ever play using Linux Mint and Chromium, but it did work using Linux Mint and Firefox.
Javascript and its use as an attack vector remain too great a risk for many people to treat it seriously.
And, to highlight the point…
http://krebsonsecurity.com/2012/08/attackers-pounce-on-zero-day-java-exploit/
Although javascript can be exploited, the java example doesn’t apply since they are completely different languages. Most people can get along without installing Java on their computer and never miss it. Javascript is used in most modern web pages and you will quickly notice if you turn it off. Javascript is built in to every modern browser but Java must be downloaded and installed as a separate program even though once installed it can be used by the browser as an “add-on”.
[…] VANCOUVER, Aug. 23, 2012 /PRNewswire/ – Destiny Media Technologies (TSXV: DSY), (OTCQX: DSNY), the leading provider of secure distribution of pre-release music and playerless streaming video is pleased to announce that its new Clipstream® G2 technology was presented to the technology community through the blog site I Cringly: Cringely on Technology at http://cringely.com. The feature is at https://www.cringely.com/2012/08/22/javascript-video-17-years-in-the-making/. […]
This worked amazingly well on my original iPad. There are some good potential uses for something like this. Maybe it won’t take the internet by storm but for certain areas I see adopting this for quick delivery of information.
Glad to see a part of the Startup Tour as well.
Thanks Bob!
i clicked it …
“This is the second in a series of columns about interesting new technologies”. Anyone know which column was the first?
Maybe the Metal Foil Drive article from 6 years ago?
https://www.pbs.org/cringely/pulpit/2006/pulpit_20061026_001143.html
I’m still waiting to buy one.
Now that’s exciting stuff bob. You’re right. The dude in the video does look familiar.
Its such as you learn my thoughts! You appear to know so much approximately this, such as you wrote the guide in it or something. I think that you simply can do with a few % to drive the message home a little bit, but instead of that, this is excellent blog. A fantastic read. I will certainly be back.
I liked as much as you’ll receive carried out proper here. The comic strip is attractive, your authored subject matter stylish. however, you command get bought an nervousness over that you want be turning in the following. ill definitely come more until now once more as exactly the same nearly a lot incessantly inside of case you shield this hike.
I’m struggling to see the difference between Clipstream and HTML5 Video Tagging. Anyone?
Is this why the only opposition to the theory of evolution comes from religious leaders and other people who make money from selling religion and spirituality to gullible people, because if gullible people weren’t gullible anymore, then these guys would have to contribute to society the way the rest of us do; with real jobs?
I have a android 2.3 tablet and i want to use it as a touch screen for my windows 7 PC.I also want that my windows believe that it is a pentouch input in it. With touch interference like up and down action,etc.
I am really inspired along with your writing talents as smartly as with the format for your blog. Is that this a paid subject matter or did you customize it your self? Anyway stay up the excellent quality writing, it is uncommon to see a nice blog like this one today..
All-in-one Pyjamas…
[…]JavaScript video technology only 17 years in the making[…]…
trend tracks…
[…]JavaScript video technology only 17 years in the making[…]…
general health, physical health , mehtal health…
[…]JavaScript video technology only 17 years in the making[…]…
Hi, i think that i noticed you visited my site thus i came to go back the desire?.I am trying to find issues to improve my web site!I guess its good enough to use a few of your ideas!!
Great submit, very informative. I’m wondering why the opposite experts of this sector do not understand this. You must proceed your writing. I’m confident, you have a huge readers’ base already!|What’s Happening i am new to this, I stumbled upon this I have discovered It absolutely helpful and it has helped me out loads. I am hoping to contribute & help other customers like its aided me. Good job.
Any more news on this JavaScript video. There really needs to be a universal format. All this transcoding is ridiculous. Did the Giantoogle crush this little company?