5 ms·

So they don't have to deal with inconsistent behaviors on different platforms. You can pretty much mess up your os installation anyway you would like, but bundl

So they don't have to deal with inconsistent behaviors on different platforms. You can pretty much mess up your os installation anyway you would like, but bundling ffmpeg, libtheora or libvpx and you no longer need to worry about different platforms or configs

CountSessine 16y ago
That converts a trivially solved technical problem into an insoluble political problem.
wtallis 16y ago
Unless you want hardware acceleration...
- sid0 16y ago
  What precludes bundled libraries from having support for hardware acceleration? Firefox 4 accelerates full-screen WebM videos on Windows and Mac, for instance.
  - wtallis 16y ago
    You need platform-specific APIs to give you direct access to the relevant hardware, which you then need to be able to use efficiently. I'd rather see applications just feed the bytestream to the OS to decode using the best means available, even if it means support for new codecs is a bit slow. (Although an OS-level codec plugin architecture like QuickTime Components can get you software decoding for new or obscure codecs.) If my GPU has a high-quality, high-speed H.264 decoder, I shouldn't have to worry about which browsers will use it. They should all default to the OS-provided decoding and playback methods unless there are sound technical reasons not to. If I want to use a new codec that's not supported by the fixed-function decoder, I shouldn't have to worry about which web browsers have bothered to include the necessary OpenCL code to decode on my GPU. I should just be able to install one codec that hooks in to the OS's media framework, and all browsers should use that first.
    - sid0 16y ago
      You need platform-specific APIs to give you direct access to the relevant hardware, which you then need to be able to use efficiently. Yes, and Firefox already has platform-specific Direct3D and OpenGL backends. Remember that a browser today needs to be able to accelerate not just video but all content and compositing, so they already have to put in that investment. The investment in video is just an additional delta. I'd rather see applications just feed the bytestream to the OS to decode using the best means available, even if it means support for new codecs is a bit slow. (Although an OS-level codec plugin architecture like QuickTime Components can get you software decoding for new or obscure codecs.) Hm. "I'd rather see applications just feed the HTML to the OS to render using the best means available, even if it means support for new HTML features is a bit slow. (Although a engine-level plugin architecture like ActiveX or NPAPI can get you some sort of rendering for new or obscure features.)" How is your assertion materially different? If my GPU has a high-quality, high-speed H.264 decoder, I shouldn't have to worry about which browsers will use it. They should all default to the OS-provided decoding and playback methods unless there are sound technical reasons not to. If I want to use a new codec that's not supported by the fixed-function decoder, I shouldn't have to worry about which web browsers have bothered to include the necessary OpenCL code to decode on my GPU. I should just be able to install one codec that hooks in to the OS's media framework, and all browsers should use that first. - See http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html http://weblogs.mozillazine.org/roc/archives/2009/06/directsh... for some problems with using OS codecs, some of which apply to Quicktime too. - You're ignoring the fact that browser makers may think supporting H.264 is against the principles of the web and will damage it.
      - wtallis 16y ago
        HTML is a web technology, but video codecs are needed by a wider range of applications, including playing optical media, games, and presentation software. The non-political arguments the mozillazine article makes against using the OS's media frameworks can be solved by using ffmpeg/etc. as fallbacks, except for the one about having to support multiple rendering paths (and even that could be solved by just packaging ffmpeg in the OS-supported codec format). If a web browser maker wants to make it hard to use H.264 even when the user already has a fully-licensed decoder as part of their operating system, then they are putting their political goals above the users' needs. If I want my browser to supplant my operating system, I'll use ChromeOS. Otherwise, I want my browser to play nice and not bring along political baggage. I don't want my browser to include it's own unoptimized codecs, it's own half-assed OpenGL implementation, it's own font rendering code, it's own widget library, it's own PDF viewer, and it's own device drivers. I want my browser to include a kick-ass [X]HTML+CSS+JS engine, and delegate the rest to the operating system like any sane application.

CountSessine 16y ago

That converts a trivially solved technical problem into an insoluble political problem.

wtallis 16y ago

Unless you want hardware acceleration...

sid0 16y ago
What precludes bundled libraries from having support for hardware acceleration? Firefox 4 accelerates full-screen WebM videos on Windows and Mac, for instance.
- wtallis 16y ago
  You need platform-specific APIs to give you direct access to the relevant hardware, which you then need to be able to use efficiently. I'd rather see applications just feed the bytestream to the OS to decode using the best means available, even if it means support for new codecs is a bit slow. (Although an OS-level codec plugin architecture like QuickTime Components can get you software decoding for new or obscure codecs.) If my GPU has a high-quality, high-speed H.264 decoder, I shouldn't have to worry about which browsers will use it. They should all default to the OS-provided decoding and playback methods unless there are sound technical reasons not to. If I want to use a new codec that's not supported by the fixed-function decoder, I shouldn't have to worry about which web browsers have bothered to include the necessary OpenCL code to decode on my GPU. I should just be able to install one codec that hooks in to the OS's media framework, and all browsers should use that first.
  - sid0 16y ago
    You need platform-specific APIs to give you direct access to the relevant hardware, which you then need to be able to use efficiently. Yes, and Firefox already has platform-specific Direct3D and OpenGL backends. Remember that a browser today needs to be able to accelerate not just video but all content and compositing, so they already have to put in that investment. The investment in video is just an additional delta. I'd rather see applications just feed the bytestream to the OS to decode using the best means available, even if it means support for new codecs is a bit slow. (Although an OS-level codec plugin architecture like QuickTime Components can get you software decoding for new or obscure codecs.) Hm. "I'd rather see applications just feed the HTML to the OS to render using the best means available, even if it means support for new HTML features is a bit slow. (Although a engine-level plugin architecture like ActiveX or NPAPI can get you some sort of rendering for new or obscure features.)" How is your assertion materially different? If my GPU has a high-quality, high-speed H.264 decoder, I shouldn't have to worry about which browsers will use it. They should all default to the OS-provided decoding and playback methods unless there are sound technical reasons not to. If I want to use a new codec that's not supported by the fixed-function decoder, I shouldn't have to worry about which web browsers have bothered to include the necessary OpenCL code to decode on my GPU. I should just be able to install one codec that hooks in to the OS's media framework, and all browsers should use that first. - See http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html http://weblogs.mozillazine.org/roc/archives/2009/06/directsh... for some problems with using OS codecs, some of which apply to Quicktime too. - You're ignoring the fact that browser makers may think supporting H.264 is against the principles of the web and will damage it.
    - wtallis 16y ago
      HTML is a web technology, but video codecs are needed by a wider range of applications, including playing optical media, games, and presentation software. The non-political arguments the mozillazine article makes against using the OS's media frameworks can be solved by using ffmpeg/etc. as fallbacks, except for the one about having to support multiple rendering paths (and even that could be solved by just packaging ffmpeg in the OS-supported codec format). If a web browser maker wants to make it hard to use H.264 even when the user already has a fully-licensed decoder as part of their operating system, then they are putting their political goals above the users' needs. If I want my browser to supplant my operating system, I'll use ChromeOS. Otherwise, I want my browser to play nice and not bring along political baggage. I don't want my browser to include it's own unoptimized codecs, it's own half-assed OpenGL implementation, it's own font rendering code, it's own widget library, it's own PDF viewer, and it's own device drivers. I want my browser to include a kick-ass [X]HTML+CSS+JS engine, and delegate the rest to the operating system like any sane application.