Here at CrowdEmotion one important tech topic is capturing video in the most efficient way: we must be very careful about the quality of capture process, as on it depends part of the accuracy of our analysis processes.
On desktop web platforms the obvious choice is between Adobe Flash and, quite recently, HTML5.
Why bother to find something different from Flash? I’ll not add anything to what someone way more authoritative than me wrote on this topic; the conclusion is simply that HTML5 is the way to go for a number of very good reasons.
Currently, we use a 3rd-party Flash-based solution and we are fairly satisfied with it, but we need to do more, be more flexible. We already started experimenting with Flash development (with Haxe to try to work with open tools) and open source RTMP video servers (Wowza, Red5), but in any case you’re limited by the closed Flash platform.
One simple question first before going on more on HTML5 capture: why Google Hangouts does not yet run on HTML5 and relies instead on a native plugin?
Quick answer: because HTML5 real-time communication stack, called WebRTC, even if feature-complete, seems definitely too young to be adopted for a mainstream & strategic product like Hangouts.
The “URL shortener” concept is very simple: take an URL and transform it into another (shorter) URL, then use redirection to go back to the first URL. So what’s the deal? Continue reading URL Shortening
I’m trying to host my handful of web sites on Amazon, but in EC2 machines there’s support for only one IP (private and public) and, as you know, SSL/TLS encryption let you have only one domain name per IP address: this is a heavy limit (with a reason), but it’s unacceptable for some reasons (public IP addresses scarcity, cost and management overhead).
Besides other solutions (multi-domain certs for example), I would like to go for the most reasonable way: virtual hosted SSL/TLS web sites, exactly the same way we all use today for non-encrypted web sites. I use Apache and for it there are a couple of solutions in the works that implement SNI or Server Name Indication: an extension to TLS protocol that “… permits the client to request the domain name, before the certificate is committed to by the server“. The support in browsers can be also a problem, but every recent browser supports it (with the exception of IE 6 and 7, apart from Vista); try your browser here. Continue reading Apache, SSL/TSL and SNI status