VP8 vs. h.264

[RealNC]

That's because you fail to see the point of HTML5 video. The codecs are a non-issue.

I want to bring online video content to users. If I choose H.264 and Flash, I know for sure that the majority of my users can watch it because I can use the raw H.264 on mobiles (iPhone etc) and Flash on computers. If I choose HTML5, I can't be sure.

So how is this not an issue?

[RobbieAB]

It seems that the writing is on the wall for flash. It may take many years, but ultimately it seems to be slowly bleeding while html5 is strengthening. One thing that isn't so clear is whether or not open source video/audio will be the winner. Most html5 news I've read seems to indicate that h264 is winning the codec war. Is there much hope for VP8? Also, I've been wanting to find a good, easy to understand quality and performance comparison between the latest h264 and VP8 encoder/decoders. Does anyone have any information on that?

Interesting argument. How does HTML5 do a push based socket in the browser?

Flash does this out the box, almost all the alternatives I have seen either require server side support or use a flash socket.

That said, I may have missed something, in which case I would be delighted if you could enlighten me.

[Arceliar]

Interesting argument. How does HTML5 do a push based socket in the browser?

Flash does this out the box, almost all the alternatives I have seen either require server side support or use a flash socket.

That said, I may have missed something, in which case I would be delighted if you could enlighten me.

Forgive me if I'm misunderstanding the issue, as network protocols aren't an area I know much about, but doesn't flash have to initiate a connection from the client side anyway and leave it open for the server to push?

Because, if so, then I fail to see how something like this isn't equivalent.

[elanthis]

Interesting argument. How does HTML5 do a push based socket in the browser?

... the same way any other application opens a "push" socket (which isn't a real thing).

In terms of streaming videos, it does it the same way any other video streaming app does it. HTML5 video doesn't use regular AJAX requests or anything for video, it mandates that the browser supports built-in native video streaming just like Flash or whatnot does.

If you're asking how general Web apps do push updates, there's a few different ways. The only cross-browser method is to poll the server for updates, or to use "never-ending" HTTP responses (which are problematic on several levels). There's also some new HTML5 features like server-sent DOM events and WebSockets, but those are not universally supported and are still very very rarely used by real applications.

[BlackStar]

I want to bring online video content to users. If I choose H.264 and Flash, I know for sure that the majority of my users can watch it because I can use the raw H.264 on mobiles (iPhone etc) and Flash on computers. If I choose HTML5, I can't be sure.

So how is this not an issue?

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.

[RobbieAB]

... the same way any other application opens a "push" socket (which isn't a real thing).

In terms of streaming videos, it does it the same way any other video streaming app does it. HTML5 video doesn't use regular AJAX requests or anything for video, it mandates that the browser supports built-in native video streaming just like Flash or whatnot does.

If you're asking how general Web apps do push updates, there's a few different ways. The only cross-browser method is to poll the server for updates, or to use "never-ending" HTTP responses (which are problematic on several levels). There's also some new HTML5 features like server-sent DOM events and WebSockets, but those are not universally supported and are still very very rarely used by real applications.

So basically, if I want to open a socket and listen for an event from the server, I am back to flash?

Which pretty much kills the case that everything Flash can do, HTML5 can do better.

Orbited essentially requires server side support, which carries larger infrastructure costs.

Note: This is not a comment on HTML5 for video streaming, just one specific PR line.

[elanthis]

So basically, if I want to open a socket and listen for an event from the server, I am back to flash?

Which pretty much kills the case that everything Flash can do, HTML5 can do better.

No, HTML5 has two ways of doing this.

Nobody uses them because HTML5 is not universally deployed or supported. No browser actually implements all of the _draft_ HTML5 features yet, not even WebKit-based browsers or Firefox 4 beta.

The server-side DOM events and WebSockets are not yet supported in any stable released version of Firefox, and I'm unsure what the status is in WebKit (though I believe both are supported). Given that WebSockets has changed several times in the last couple years, relying on it is a bad idea right now.

So yeah, when HTML5 is an actual thing and not just a collection of incomplete draft proposals, it could replace Flash. Until then, either use the workarounds that people have used for years (polling or streaming/never-ending requests) or use Flash.

Orbited essentially requires server side support, which carries larger infrastructure costs.

Exactly how the heck do you think any streaming/push protocol is going to work without server-side support?

Do you think Flash is magically getting streaming data from a server without you deploying a server capable of efficiently handling the streaming data? Do you think there's some magical way of making a pre-fork server like most Apache deployments actually able to efficiently handle thousands of clients waiting for push notifications and streaming data updates that requires nothing more than a tweak to the HTML spec to achieve?

If you want streaming or push notifications of any kind, with any protocol, you're going to have to roll out a hefty server infrastructure in addition to your stock request-response HTTP server infrastructure.

[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

[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]

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.