Announcement

Collapse
No announcement yet.

Adobe Rants Over Linux Video Acceleration APIs

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

  • #76
    Originally posted by Wyatt View Post
    Call me crazy, but isn't this sort of thing why we have NPAPI? FFMPEG can already decode h264-- I wouldn't be terribly surprised to find that someone is already hacking up a fix to this "issue".
    Can NPAPI handle implementation of the necessary DOM methods? I was skimming some docs and it looks like it's possible for a plugin to extend <embed> with methods, but could the <video> API be provided in a sane way?

    Comment


    • #77
      HTML5 does not say anything about a codec for the video element. That means that a browser is not required to implement any specific codec at all. And this is why a plug-in makes sense. You people don't grasp what a plug-in actually is. Sure, they're used for embed stuff. But they can be used for whatever else you can think of.

      Also, don't forget that a plug-in might not even be needed. Firefox could just use the platform's video codec. Just like a media player who uses external codecs doesn't have to think about codec royalties, Mozilla wouldn't have to either.

      Furthermore, if Mozilla won't try to externally support H.264, then Google Chrome will win it all, since it's the one and only browser that supports both H.264 and Theora. All other browsers are Theora-only and H.264-only. And since, as I said above, the HTML5 spec does not dictate any codecs, websites are bound to use whatever codec they want and the only browser that will cope with both is Chrome.

      Comment


      • #78
        Furthermore, if Mozilla won't try to externally support H.264, then Google Chrome will win it all, since it's the one and only browser that supports both H.264 and Theora. All other browsers are Theora-only and H.264-only. And since, as I said above, the HTML5 spec does not dictate any codecs, websites are bound to use whatever codec they want and the only browser that will cope with both is Chrome.
        "External" support is no solution. Chrome does that with FFMPEG and guess what? Fedora users are locked out of youtube, because their distro doesn't build FFMPEG with H.264 support.

        Comment


        • #79
          Moreover, the original HTML5 spec did mandate Theora, something that was removed later on. Also guess who stands to make a lot of money out of H.264 (hint: it ends in "Microsoft").

          While we are at it, why don't we make Silverlight a web standard, too? If anything it's less patent encumbered than H.264, so why not?

          Comment


          • #80
            So what if it won't work everywhere? The standard doesn't mandate that Flash must work in all platforms either. The <video> tag isn't any different from <embed>. Just as it isn't important what types of objects work in an <embed>, what kind of video codec works in a <video> tag isn't important either.

            And who makes money out of H.264 isn't important in this discussion. You're now shifting your original claims about the reason Mozilla doesn't provide H.264 support into monetary politics. That makes you a hypocrite. You should have said what you really think from the beginning.

            Mozilla can provide H.264 on "supported platforms" (meaning platforms that either have an external H.264 codec that Gecko can use or provide one in the form of a brower-plugin) with no fear of royalties. I certainly don't see Mozilla disallowing Flash completely in their browser just because some platforms don't have an implementation of it. Yet you give the same argument about H.264. Who cares? If some platforms won't have H.264 so be it, just like with Java and Flash objects. There's absolutely no reason why the same can't be done with H.264 too.

            Comment


            • #81
              Originally posted by RealNC View Post
              So what if it won't work everywhere? The standard doesn't mandate that Flash must work in all platforms either. The <video> tag isn't any different from <embed>. Just as it isn't important what types of objects work in an <embed>, what kind of video codec works in a <video> tag isn't important either.
              I believe the main reason for the hullabaloo is more due to a desire of making it possible to have a least common denominator that doesn't need a plugin at all to play. In light of the fact that most of the h.264 videos on the 'net aren't encoded at really much of any higher quality than Vorbis, I would say that it's a somewhat reasonable desire to seek that sort of thing. Now, before you remark on "hardware supports h.264 and doesn't Vorbis", I would observe that for the hardware in question, save for some instances of video adapters where we don't have a lot of support on, that the "hardware" is mostly a DSP doing the work and can be reconfigured for the task of Vorbis support fairly easily. Moreover, it's largely doubtful that a silicon vendor, except for perhaps an ATSC or other HD television, would be producing a end-to-end h.264 decoder- they make pieces. Many of which recycle over (otherwise they wouldn't be able to do MPEG1, MPEG2, or MPEG4 in addition to AVC (h.264...).

              Whether it happens or not, is irrelevant- but it is a somewhat reasonable position to ask for and it's not impossible for the vendors, in the large, to support as a baseline.

              Comment


              • #82
                @RealNC: The only hypocrite here is you saying that Mozilla is somehow limiting your freedom by not supporting a patent-encumbered codec in a free implementation of an open standard. You seem to have some very skewed perspective of the world.

                Once more, if you want to use plugins for video you can do that already. It's called flash. You can also use Chrome or - if you can't live without Firefox - you can fork that too and provide your own video implementation.

                Comment


                • #83
                  Originally posted by Svartalf View Post
                  I believe the main reason for the hullabaloo is more due to a desire of making it possible to have a least common denominator that doesn't need a plugin at all to play.
                  Unfortunately, there is none. No, Theora (Vorbis is an audio codec) won't be implemented by Apple for Safari and probably Microsoft for Internet Explorer. They will implement H.264 instead. That's *at least* one half of the browser market. The other half, Firefox, Opera and Chromium (not Chrome) will only implement Theora. Chrome will implement both. There's no "least common denominator" here for a website to follow. It's either the one half, or the other half.

                  In light of the fact that most of the h.264 videos on the 'net aren't encoded at really much of any higher quality than Vorbis
                  I'm not sure I understand what you mean. Do you claim that for the same bitrate, Theors (and not Vorbis) would offer the same quality? I think it has been established by now that H.264 offers the smaller sizes for a given target quality.

                  I would say that it's a somewhat reasonable desire to seek that sort of thing. Now, before you remark on "hardware supports h.264 and doesn't Vorbis", I would observe that for the hardware in question, save for some instances of video adapters where we don't have a lot of support on, that the "hardware" is mostly a DSP doing the work and can be reconfigured for the task of Vorbis support fairly easily.
                  I didn't consider hardware players in any of my arguments. Since I don't really know anything about it, I'll stay of this. From "the outside" though, it seems H.264 has the upper hand here too because of Apple devices ("iRandomWord" stuff). And it seems Apple will not support Theora and Vorbis unless Hell freezes over.

                  Whether it happens or not, is irrelevant- but it is a somewhat reasonable position to ask for and it's not impossible for the vendors, in the large, to support as a baseline.
                  As stated above, there probably will not be a baseline. Anyone who offers web videos using HTML5 will have to decide which half of the market they want to support or recommend everyone to use Google Chrome.



                  Originally posted by BlackStar View Post
                  @RealNC: The only hypocrite here is you saying that Mozilla is somehow limiting your freedom by not supporting a patent-encumbered codec in a free implementation of an open standard. You seem to have some very skewed perspective of the world.

                  Once more, if you want to use plugins for video you can do that already. It's called flash. You can also use Chrome or - if you can't live without Firefox - you can fork that too and provide your own video implementation.
                  A totally irrelevant answer as it doesn't add anything new to what I've already answered. Just goes back and repeats the already dealt with issues.

                  Comment


                  • #84
                    Originally posted by RealNC View Post
                    The <video> tag isn't any different from <embed>.
                    Yes it is. As an element, <embed> doesn't directly imply anything about what kind of media is embedded, nor does it present a standardized API for streaming media. The API is part of the spec, and sites using <video> will likely break if that API is not present. You keep talking about this as though Mozilla has made some kind of arbitrary decision to not "allow" plugins for <video>, but you haven't addressed how they've gone about "disallowing" it. If they have to extend NPAPI to make it possible, that's not a task to be undertaken on a whim.

                    Originally posted by RealNC
                    There's no "least common denominator" here for a website to follow. It's either the one half, or the other half.
                    Sites can encode in both formats; they aren't required to choose just one. They can either supply multiple <source> elements (which seems to be the recommended method) or use JavaScript to generate the "src" attribute. Yes, this requires more storage, but I'd think that the main bottleneck for streaming video is bandwidth.

                    Comment


                    • #85
                      Originally posted by Ex-Cyber View Post
                      Yes it is. As an element, <embed> doesn't directly imply anything about what kind of media is embedded, nor does it present a standardized API for streaming media. The API is part of the spec, and sites using <video> will likely break if that API is not present.
                      It's similar to the given problem. I should rather say, "In this regard, the <video> tag isn't any different from <embed>." When Firefox sees an <embed> it tries to find a plugin that can deal with it. Similarly, when Firefox would find a <video> or <audio>, it could try to find a plugin that deals with the video's or audio's *codec*, not the <video>/<audio> itself.

                      In other words, the entity "codec of the <video> source" could be treated similarly to the entity "object of <embed> source". Yes, sure <video> always means video. But the codec isn't part of <video> and could be a plugin.

                      You keep talking about this as though Mozilla has made some kind of arbitrary decision to not "allow" plugins for <video>, but you haven't addressed how they've gone about "disallowing" it.
                      When did I say that they disallowed it? "No support" doesn't mean "disallow." Unless you mean the statement about Flash. That was the counter-argument to platform differences. I'll reword it then to make it clearer:

                      Argument: Mozilla can't support H.264 (externally or however) because not all platforms would support it.

                      Counter-argument: Mozilla supports Flash, which is an <embed> object, even though not all platforms can support it. They could do the same for <video> codecs. If they wanted to always support the same stuff on all platforms, they would have chosen only the subset of <embed> objects that are known to be supported on all platforms. That would really mean actively disallowing Flash. They aren't disallowing H.264. They just don't support a way for others to add support (trough a platform codec or plugin.)

                      If they have to extend NPAPI to make it possible, that's not a task to be undertaken on a whim.
                      But can be done.

                      Sites can encode in both formats; they aren't required to choose just one. They can either supply multiple <source> elements (which seems to be the recommended method) or use JavaScript to generate the "src" attribute. Yes, this requires more storage, but I'd think that the main bottleneck for streaming video is bandwidth.
                      They certainly can. And they might even do it. But they also might not.

                      Comment


                      • #86
                        Originally posted by RealNC View Post
                        So what if it won't work everywhere?
                        If you don't understand the need or importance of universally accessible information you have failed to grasp the most important tenant of the internet itself. This discussion is over.

                        To anyone else: keep in mind HTML 5 is still in flux and just because a codec hasn't been chosen yet doesn't mean one wont be in the future. Why do you think Google bought On2 directly after the first Theora / HTML 5 debate? Something interesting should be coming out from them soon.

                        Comment


                        • #87
                          Originally posted by Hoodlum View Post
                          If you don't understand the need or importance of universally accessible information you have failed to grasp the most important tenant of the internet itself. This discussion is over.
                          Goodbye and don't forget to send a postcard.

                          To anyone else: keep in mind HTML 5 is still in flux and just because a codec hasn't been chosen yet doesn't mean one wont be in the future.
                          Hoodlum failed to check facts before posting. (I'm using third person because he/she left the discussion.) A codec was chosen (Theora) and then, after they thought it through thoroughly (I always wanted to use those three words together :P) they removed it again.

                          Comment


                          • #88
                            Originally posted by RealNC View Post
                            Goodbye and don't forget to send a postcard.
                            I didn't leave the thread, I recognised there is no counter for what I have said (which was purely factual). You just confirmed this fact.

                            Hoodlum failed to check facts before posting.
                            Wrong again.

                            A codec was chosen (Theora) and then, after they thought it through thoroughly (I always wanted to use those three words together :P) they removed it again.
                            Yes and HTML 5 spec is still in flux, as I said. I suggest you educate yourself before you post in future.

                            Here I'll help you: http://en.wikipedia.org/wiki/HTML_5
                            "HTML5 is being developed as the next major revision of HTML (Hypertext Markup Language), the core markup language of the World Wide Web."

                            Being developed. It is in progess I cannot make this any more simple for you to understand.

                            Comment


                            • #89
                              I can't believe we're having this discussion, yet AGAIN.

                              RealNC, of course Mozilla could use the system codecs, but that doesn't mean they should.

                              They've said that they are attempting to steer the video tag away from the disaster that flash and the gif format was. If they went ahead and implemented using the system plugins, everyone would simply use h264 and it would be over. By forcing this situation while sites haven't yet moved over, they're hoping they can convince sites to provide theora in addition to h264 for apple. That, or it sounds like they are very hopeful that google might open up VP8 and move everything to that.

                              If it becomes apparent that Mozilla has lost the battle, and everyone is simply using h264 anyway, they've said they will go ahead and implement it, that's just something that would be stupid to do before they absolutely are forced into it.

                              And for everyone complaining about this, why aren't you complaining the same about Apple not including Theora support? Is it just because you recognize there's no way in hell that's ever going to happen? Why do they get held to a lesser standard than the open source Firefox, which anyone could go in and fork to their needs if necessary?

                              Comment


                              • #90
                                Yes, it's in progress. And? How do you know they'll bring back codecs into the spec? Are you psychic?

                                Comment

                                Working...
                                X