VP8 vs. h.264

[XorEaxEax]

I think you meant HTML5 will support VP8?


Actually, what people watch is 720p when it's available.

It doesn't matter if they watch it in 720p, 480p, 720p etc is about resolution, not about quality. And looking at the quality the vast majority of Youtube videos have there's really no problem for VP8 to replace h264 in that regard. Also the quality of VP8 is improving with each release, it's an ongoing process.

I doubt VP8 will ever reach the quality of high end h264 encodes mainly due to patented technologies, but VP8/Webm isn't really there to replace h264 in Bluray's and likely not high quality on-demand video streaming either. I'd say it's mainly for sites like Youtube, Dailymotion, Veoh, Vimeo etc. Either way it must be a wet dream come true for those who wants to start their own video sites as it seriously lowers the bar of entry due to them not having to pay MPEGLA licence fees for serving videos.

[BlackStar]

And what about mobiles? Those need H.264 and even have acceleration support for it (meaning longer battery life.) That means no VP8. And that means Flash + H.264 and raw H.264 is still the best answer.

Yes, you might not like it. But it's just the way it is

Google Android is the fastest selling mobile platform and manufacturers have already pledged to support VP8.

1 + 1 = ?

[smitty3268]

And what about mobiles? Those need H.264 and even have acceleration support for it (meaning longer battery life.) That means no VP8. And that means Flash + H.264 and raw H.264 is still the best answer.

Yes, you might not like it. But it's just the way it is

Mobile hardware manufacturers have already pledged support for hardware decoding VP8. It does seem likely that Apple will intentionally sabotage that ability on the iPhone/iPad, though, so it may be a valid concern. We'll have to wait and see.

[elanthis]

And what about mobiles? Those need H.264 and even have acceleration support for it (meaning longer battery life.) That means no VP8. And that means Flash + H.264 and raw H.264 is still the best answer.

Yes, you might not like it. But it's just the way it is

To be fair, _current_ mobiles have that limitation. With Google behind Android now VP8, we may see a push for VP8 in hardware on more mobile chips going forward.

After all, it wasn't too long ago that mobiles didn't have .h264 hardware decoding, either.

Some day .h264 is going to be phased out even by the MPEG-LA. They do work on new codecs and improvements, you know. .h263 is actually still in frequent use, but is being successfully phased out for .h264.

[RealNC]

Use VP8 and play with HTML5/VP8 (if supported) or Flash/VP8 (if not). It's VP8 in both cases.

This is the third time someone is trying to tell you that Flash will support VP8 out of the box.

And what about mobiles? Those need H.264 and even have acceleration support for it (meaning longer battery life.) That means no VP8. And that means Flash + H.264 and raw H.264 is still the best answer.

Yes, you might not like it. But it's just the way it is

[smitty3268]

WebSockets API was actually deployed in several versions of Chrome. I think Opera might have it as well. It's been an issue because they've changed the protocol making the older browser versions incompatible.

The current version was supposed to go into Firefox 4, but got disabled after someone discovered a security flaw in the current protocol. Expect it to be enabled again and working when 4.5 comes out, hopefully by then they'll have worked through the remaining issues and it will be fairly safe to use without having to worry about them changing the format again.

[elanthis]

If you impose the same limitation on a JS socket that is imposed on a Java Applet socket (as I understand it) and forbid connecting to any server other than the originating server, the security impact shouldn't be any greater than allowing access to that server in the first place.

Unfortunately, that limits things greatly, especially in the example of an IRC server. You very rarely have an IRC server and Web server running on the same host. In many cases, they aren't even on the same domain. The same goes for game servers, database servers, and any other server setup in any reasonably and competently managed server infrastructure for real-world Web applications with a sizable user base.

There are other ways to accomplish the security, such as how Flash does it. This is similar to what the cross-domain AJAX feature added in the newer browsers does. I believe WebSockets do this, in fact, as does the new cross-domain AJAX support.

Still, the experts have decided that the best approach is to just deny use of plain TCP sockets and require a specialized protocol.

Maybe in the future there will be plain TCP socket support, but I wouldn't wait. It's really not as important as you might think. Even Flash applets still usually use the "proprietary" protocol via XMLSocket rather than the plain TCP socket feature. XMLSocket is pretty similar to WebSockets in terms of socket, albeit different in protocol.

[RobbieAB]

If you impose the same limitation on a JS socket that is imposed on a Java Applet socket (as I understand it) and forbid connecting to any server other than the originating server, the security impact shouldn't be any greater than allowing access to that server in the first place.

[elanthis]

Fairly straight forward in Flash (open a socket to the IRC server, and go) or a Java Applet. Using Orbited it requires additional server side infrastructure to do something that (I personally believe) any network programming language should be able to do out of the box.

Aaaah, I misunderstood what you were asking about. Sorry.

Yeah, older versions of Flash also had this limitation, until 10.0 I believe. It's a safety/security thing. You don't want your browser to be able to open any connection to any port with any protocol. The capability for abuse is very, very great. It could, for instance, be used as an attack on your Intranet to allow a malicious party to use your browser as a proxy to get past firewall restrictions, allowing them to subvert internal servers' security. There are potential ways to reduce this risk, but in general it's considered way safer to just not make it possible.

WebSockets and the like have been blocked for so long because of their security concerns, despite the fact that they're a specialized protocol that cannot connect to arbitrary servers.

So yeah, if you want to do an IRC client, you will need a server-side proxy to translate the WebSocket (or AJAX or whatever) connections into IRC connections. Even better, though, your IRC server could just contain WebSocket support. Back in the day I built MUD servers that had built-in support for multiple protocols, and had initial support for the old Flash network protocol before Flash could do plain TCP sockets.

This is considered a feature, not a bug. Obviously, some people may disagree.

[RobbieAB]

Consider a browser based IRC client...

Fairly straight forward in Flash (open a socket to the IRC server, and go) or a Java Applet. Using Orbited it requires additional server side infrastructure to do something that (I personally believe) any network programming language should be able to do out of the box.

YMMV