Announcement

Collapse
No announcement yet.

VP8 vs. h.264

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Remco View Post
    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?

    Comment


    • #32
      Originally posted by Prescience500 View Post
      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.

      Comment


      • #33
        Originally posted by RobbieAB View Post
        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.

        Comment


        • #34
          Originally posted by RobbieAB View Post
          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.

          Comment


          • #35
            Originally posted by RealNC View Post
            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.

            Comment


            • #36
              Originally posted by elanthis View Post
              ... 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.

              Comment


              • #37
                Originally posted by RobbieAB View Post
                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.

                Comment


                • #38
                  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

                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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.

                      Comment


                      • #41
                        Originally posted by RobbieAB View Post
                        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.

                        Comment


                        • #42
                          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.

                          Comment


                          • #43
                            Originally posted by BlackStar View Post
                            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

                            Comment


                            • #44
                              Originally posted by RealNC View Post
                              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.

                              Comment


                              • #45
                                Originally posted by RealNC View Post
                                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.

                                Comment

                                Working...
                                X