5 ms·

The wierd thing is that this has been supported for years. Firefox has a compile-time flag that allows it to use operating system codecs, it is just not activat

The wierd thing is that this has been supported for years. Firefox has a compile-time flag that allows it to use operating system codecs, it is just not activated in the official binaries. (I think it also uses a codec whitelist on some OSes, and you have to comment out a line.) On Windows, it used DirectShow codecs, on Linux GStreamer, and on OS X probably quicktime. It's great to be able to just point the browser to a file on the local net and be able to play everything the system can play (and even if it couldn't load the system codec, it could load a MPlayer plugin). I used this for a while on Linux when there was a codec war between Firefox and Chrome (forgot the details), but I could play videos that normally only played in Chrome without problems. Browser vendors cite usability problems (if one person's browser supports more codecs than the default, then it is confusing for other people with the default browser... and the person with more codecs might create websites that depend on this), and stability problems (plugins in any form have a bad reputation, but actually the default OS media player codecs are of pretty good quality as they are excercised thoroughly). But honestly, I think it is mostly politics that this is not enabled.

acdha 10y ago
One big concern is security: code like this is notoriously prone to exploits and once shipped everyone is exposed whether or not they use it. That doesn't mean new formats can't happen but it should encourage some careful assessment of the benefits relative to the need to support it for years. (This is one of the stated reasons why Firefox never shipped JPEG 2000 support despite some demand)
- nwah1 10y ago
  Good point. Decoders for various formats are being reimplemented in Rust, which may make Mozilla less hesitant. There's still no guarantees, but it seems much less dangerous.
  - acdha 10y ago
    It will definitely help but it also increases the cost of adding support if that means porting an existing code base and having to maintain it. It'll be interesting to see whether projects start migrating wholesale so that's not just a Mozilla effort.
- captainmuon 10y ago
  True, but there is no intrinsic reason why code from one vendor (Mozilla, Chrome group at Google) should be more or less secure that from the OS developer (e.g. MS, Apple). In fact, for probably everybody except large browser vendors, you should never roll your own codecs (security, networking libs...) if it is not absolutely necessary.
  - nitrogen 10y ago
    Much codec code was written years/decades ago with zero concern for security, so browsers have to have whitelists and private implementations.
  - zeta0134 10y ago
    I disagree with this idea in the specific domain of Web Browsers. If a vulnerability is discovered in a codec that ships with Firefox, Mozilla can have a patch out within 24 hours. They only have to test that codec against their own browser software. Microsoft and Apple can technically roll out a similar patch within 24 hours, but will rarely do so except for major bugs, which have significant baby-punching abilities, as they have to test all of the rest of the operating system software against changes to system libraries. (Linux users get to update their libraries independently, so my argument doesn't really hold water there.) Since my web browser is one of those bits of software that I regularly expect to load code that I will not vet, from developers whom I don't necessarily trust, I feel like I'd rather have it loading codecs that were designed with the web in mind. I don't think I trust it running my OS codecs, especially for more complicated formats. This still doesn't mean I'd expect Mozilla to write their own codecs from scratch; certainly they should pull that codec in from an open source, well written and well supported library. But I think they're in a better position to respond to threats and patch domain-specific issues out of that library than my OS vendor is.
  - Klinky 10y ago
    Codecs often aren't written by the OS vendor. Throughout the 2000s a lot of Windows users got their codecs via less than reputable codec multipacks from sites that may or may not be reputable. The VLC/MPC-HC/Web "just works out of the box" method is more user friendly and secure than a bunch of independent binaries, written by various people, which may end up conflicting with each other.
rasz_pl 10y ago
of course its politics. Google ships chrome with unoptimized h.264 software decoder causing 1080p60 h.264 YT clips to stutter on 4GHz intel while more cpu intensive vp9 is butter smooth, and same 1080p60 h.264 clips downloaded to disk play at 30% cpu in mplayer.
- emn13 10y ago
  That's not just politics, it's also patents.
  - rasz_pl 10y ago
    patents dont make people ship software compiled without optimization. Intel did same thing with its compiler to push cpus, Nvidia with physx compiled to use FPU instead of SSE/AVX and so on, its all politics.

acdha 10y ago

One big concern is security: code like this is notoriously prone to exploits and once shipped everyone is exposed whether or not they use it. That doesn't mean new formats can't happen but it should encourage some careful assessment of the benefits relative to the need to support it for years. (This is one of the stated reasons why Firefox never shipped JPEG 2000 support despite some demand)

nwah1 10y ago
Good point. Decoders for various formats are being reimplemented in Rust, which may make Mozilla less hesitant. There's still no guarantees, but it seems much less dangerous.
- acdha 10y ago
  It will definitely help but it also increases the cost of adding support if that means porting an existing code base and having to maintain it. It'll be interesting to see whether projects start migrating wholesale so that's not just a Mozilla effort.
captainmuon 10y ago
True, but there is no intrinsic reason why code from one vendor (Mozilla, Chrome group at Google) should be more or less secure that from the OS developer (e.g. MS, Apple). In fact, for probably everybody except large browser vendors, you should never roll your own codecs (security, networking libs...) if it is not absolutely necessary.
- nitrogen 10y ago
  Much codec code was written years/decades ago with zero concern for security, so browsers have to have whitelists and private implementations.
- zeta0134 10y ago
  I disagree with this idea in the specific domain of Web Browsers. If a vulnerability is discovered in a codec that ships with Firefox, Mozilla can have a patch out within 24 hours. They only have to test that codec against their own browser software. Microsoft and Apple can technically roll out a similar patch within 24 hours, but will rarely do so except for major bugs, which have significant baby-punching abilities, as they have to test all of the rest of the operating system software against changes to system libraries. (Linux users get to update their libraries independently, so my argument doesn't really hold water there.) Since my web browser is one of those bits of software that I regularly expect to load code that I will not vet, from developers whom I don't necessarily trust, I feel like I'd rather have it loading codecs that were designed with the web in mind. I don't think I trust it running my OS codecs, especially for more complicated formats. This still doesn't mean I'd expect Mozilla to write their own codecs from scratch; certainly they should pull that codec in from an open source, well written and well supported library. But I think they're in a better position to respond to threats and patch domain-specific issues out of that library than my OS vendor is.
- Klinky 10y ago
  Codecs often aren't written by the OS vendor. Throughout the 2000s a lot of Windows users got their codecs via less than reputable codec multipacks from sites that may or may not be reputable. The VLC/MPC-HC/Web "just works out of the box" method is more user friendly and secure than a bunch of independent binaries, written by various people, which may end up conflicting with each other.

rasz_pl 10y ago

of course its politics. Google ships chrome with unoptimized h.264 software decoder causing 1080p60 h.264 YT clips to stutter on 4GHz intel while more cpu intensive vp9 is butter smooth, and same 1080p60 h.264 clips downloaded to disk play at 30% cpu in mplayer.

emn13 10y ago
That's not just politics, it's also patents.
- rasz_pl 10y ago
  patents dont make people ship software compiled without optimization. Intel did same thing with its compiler to push cpus, Nvidia with physx compiled to use FPU instead of SSE/AVX and so on, its all politics.