8 ms·

Mozilla will add H.264 to Firefox as Cisco makes push for WebRTC’s future

218 points by gz5 13y ago

gz5 13y ago
Good move by Cisco. Mozilla response seems lukewarm though? Mozilla CTO Brendan Eich: “Although H.264 will become available to Firefox users thanks to Cisco’s move, the codec still comes with restrictive licensing that we believe is not in the long-term best interests of users and the Web, compared to the situation with a truly free and unrestricted codec.”
- hyperpape 13y ago
  That makes sense to me. This is a reasonable compromise for Mozilla, but it's still a compromise. What they want is a free (as in FOSS) codec. What they got is a single free of charge implementation of a patent encumbered codec.
- kibwen 13y ago
  Here's the announcement from Eich himself: https://brendaneich.com/2013/10/ciscos-h-264-good-news/ https://brendaneich.com/2013/10/ciscos-h-264-good-news/ I wouldn't say that the reaction is lukewarm, but rather reserved. Mozilla's never been a fan of H.264, but supporting it has long since transformed from a philosophical choice to a political necessity. This move helps Mozilla, no question, but it doesn't advance their agenda of patent-unencumbered web standards. Let's hope that VP9 and Daala can do better on this front in the coming years.
- nly 13y ago
  Personally I'm overjoyed by that lukewarm response.
- rubiquity 13y ago
  It seems that Mozilla is in a position of doing what is right for pushing the Web forward for end users and doing what is right for the open Web. It's nice to see them choose on the side of end users but I doubt Mozilla will stop looking for a more open alternative.
  - mpyne 13y ago
    Not only has Moz not stopped looking for something better, they continue to actively develop something better (i.e. Daala)
- mpyne 13y ago
  Of course the response is lukewarm, this still represents a failure of open web usage. As a practical measure this is a good move, but that doesn't make this a principled measure.
- shmerl 13y ago
  It's a "move" but not a solution. Just a temporary workaround. The solution is work on Daala. See http://xiphmont.livejournal.com/61927.html http://xiphmont.livejournal.com/61927.html
bbx 13y ago
No matter what codec will eventually be widely adopted, I hope native video support for browsers will lead to better video players. Right now, I have issues with YouTube (loading speed, quality switching back and forth between 480p, 720p and 240p), Vimeo (still can't jump to a desired position, loads incredibly slowly), various Flash embedded players (won't load, or will reset to 0:00 when trying to change the current position), auto-playing videos, lack of controls, usability issues... I usually end up downloading the video with a Firefox add-on to watch it later. Or just stop bothering and close the tab.
- cbhl 13y ago
  I've never seen any of those issues -- are you sure your Internet provider isn't throttling video packets with DPI or something?
  - redthrowaway 13y ago
    I get the same, and it's not dependent on ISP. Many (most?) flash players are buggy resource hogs, and the html5 implementations I've seen don't feel ready for primetime yet.
    - actionscripted 13y ago
      (Former) Flash nerd here. The problems with plackback and scrubbing are absolutely the fault of the Flash player and there's really nothing you can do about it short of hacking your own video handling into the SWF format. There are a lot of low-level network-related problems in Flash. I have zero real proof, but I know for a long time Adobe (Macromedia) was pushing their streaming server and didn't really put a lot of effort into handling streaming/buffering without it and I suspect this just never got fixed as things were "good enough".
      - krilnon 13y ago
        To be fair, there weren't many (any?) standardized alternatives back then. There was no particular incentive for Adobe to support, say, Red5 when there was no standard to gather around. Apple's HLS is a pretty recent attempt at moving toward a documented standard. If you're talking about streaming .flvs off of a regular Apache setup, then it shouldn't be surprising that scrubbing and seeking are troublesome: static file servers weren't build for that use case. What would you have preferred Adobe to have done?
ck2 13y ago
Yes! Windows XP will get native video playback after all (doesn't support the current microsoft framework workaround). Thanks Mozilla!
- gcp 13y ago
  Only baseline profile is supported. Don't expect most videos to work.
- pix64 13y ago
  April 8, 2014 is approaching rather fast...
recuter 13y ago
I find myself increasingly frequently using 'youtube-dl' to grab clips, advantages being that youtube sometimes only buffers a little bit before stopping and this way I don't need to care about keeping tabs open or codecs. Everything always plays fine with VLC and I can mess with the playback speed by simply pressing '[]'. Should probably automate this. Maybe independently of browsers, just sniff my own traffic and MITM myself (request goes to youtube-dl, browser gets a page that closes itself immediately).
- GhotiFish 13y ago
  I would be interested in developments regarding this. I was thinking perhaps some extension to firefox to trigger youtube-dl. I don't think firefox would provide that kind of system level access to plugins, however.
RRRA 13y ago
So they will pay what? When? with what guarantee? What about production cost of videos? Do we need a license? That doesn't smell very good...
- pritambaral 13y ago
  The Cisco binary should include encoding as well as decoding for it to be usable in WebRTC. Production systems could download Cisco's binary and use it.
- pdpi 13y ago
  It's a brilliant hack, they pay exactly zero for this. You get a licence from Cisco, and they pay royalties to the MPEG LA for that licence. Now, the H.264 licence fees are per copy distributed, but there's a cap on the fees, and Cisco's own usage puts them _way_ over the cap anyhow, so distributing this thing freely for Mozilla to use costs them literally nothing at all. Plus, they're apparently really distributing binaries for any and all platforms you can think of (someone mentioned S/360).
wyager 13y ago
So according to this thread: https://news.ycombinator.com/item?id=6640324 https://news.ycombinator.com/item?id=6640324 Mozilla is going to add a Cisco blob to their distributed browser, and not the actual compiled source. Any clarification on that?
- mpyne 13y ago
  Cisco will release the source code, but according to the H264 licensing terms Cisco has to be the one to distribute the resultant binary if Cisco is to pay for the license. It would be good for others to independently verify that Cisco's source compiles to Cisco's binary, but that still wouldn't give legal permission for those others to distribute the binary -- only Cisco can do that.
  - e12e 13y ago
    What's more interesting is if this will allow end-user to compile a binary for personal use. If the build scripts works as well as eg: most c-extentions for python (so you can do like the equivalent on debian for mercurial: apt-get build-dep mercurial; virtualenv --no-site-packages test;cd test;./bin/pip install mercurial -- and have it just work) -- a real "loophole" might actually present itself in the licensing. It still wouldn't be quite as easy on Windows (even if it builds with a free and/or gratis compiler there) -- but on all platforms building a plugin (automagically) should be much more feasible than for "everyone" to build Firefox (that thing is a monster).
    - mpyne 13y ago
      Unfortunately as far as I understand it you're only "licensed" to use the codec if you receive the binary directly from Cisco... even if you manage to compile a bit-for-bit identical equivalent. You'd surely get away with it as a personal-use thing but I doubt distros would automate it for you.
devx 13y ago
Wow, this seems like a very backwards move. Just when the truly open source VP8 was set to go in WebRTC, we're opening the discussion about putting h.264 in there again? Why?! This seems like a very short sighted move.
- mayhew 13y ago
  Yeah, I don't think they had to compromise this much. Using the H.264 decoder on the host OS was good enough.
- mpyne 13y ago
  That's just it, it's not apparent that IETF will mandate VP8 in WebRTC even without Cisco's offer here. Nor can Mozilla go it alone, Chrome has already announced they will also support H264. As Monty himself put it on his personal blog, in the matter of VP8 vs. H264, VP8 lost. This is an appreciated measure by Cisco to mitigate the damage until Daala can be fielded to proactive displace whatever MPEG LA tries to push after H264.
  - pthatcherg 13y ago
    Chrome has not said it will support H264 in WebRTC.
  - cromwellian 13y ago
    What guarantee is there that a codec which doesn't even exist yet won't lose to Microsoft/Cisco/Nokia/et al the next time we need to standardize a MTI codec in some spec? This seems wishful thinking.
    - graue 13y ago
      No guarantee, but the same team was successful at getting Opus (audio codec) adopted as MTI for WebRTC. http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6... On a purely technical level, Opus' performance blew the pants off the other options, which surely helped. If Daala can repeat that performance I think they have a good chance.
hristov 13y ago
This still does not make it better than VP8. Yes CISCO will release a binary for most platforms but not all. They can snub platforms because of lack of resources or for strategic reasons. Furthermore, CISCO has not committed to keep paying the royalties until all patents expire. I suppose it is an ok move by CISCO, but still does not make H.264 acceptable when we have a completely free open source alternative.
- zanny 13y ago
  We also have vp9 out in the wild and Dalaa sometime in Q1 of next year, we hope.
bstar77 13y ago
I'm thoroughly confused by this press release. I have an app that needs cross browser video support and I was required to use either flash/webm/vorbis to get my videos working in FF. As of a few weeks ago, h264 videos started working in the latest version of FF. Once I discovered that I ditched webm and vorbis and now have it default to mp4. Then I see this press release... Does FF officially support h264 right now? I'm using FF v24 and it seems to already support h264. Is that because I'm using a mac and it falls back on a system codec?
- wmf 13y ago
  Right now Firefox uses system codecs where available. In the future it will also have the Cisco codec as an option.
- gcp 13y ago
  >Does FF officially support h264 right now? I'm using FF v24 and it seems to already support h264. Is that because I'm using a mac and it falls back on a system codec? It's using system codecs. Your stuff won't work on Windows XP, which is still a significant percentage of users.
  - bstar77 13y ago
    It will work since it falls back on flash, but that's obviously not ideal.
AsymetricCom 13y ago
Can someone explain to me what the purpose of WebRTC is? Why does the browser need some kind of new protocol in a browser to do "real time communication?" I mean, don't we already have TCP/IP?
- computerbob 13y ago
  As far as I understand it is a way for a 1-1 communication between browsers. No middleman. So when I talk to another browser it is (browser<->browser2) NOT (browser<->Google<->browser2)
- randyrand 13y ago
  Browsers currently can't do any "hosting" so there is no way to directly connect to another browser. WebRTC solves this problem.
- pigubrco 13y ago
  WebRTC allows developers to potentially write the next Skype-type application without having to worry about the underlying voice and video codecs, signal processing components like acoustic echo cancellation, bandwidth estimation and other complex components using high level javascript APIs because these components are now baked into the browser. There is also a data channels API that allows for peer to peer data transfer. http://www.html5rocks.com/en/tutorials/webrtc/basics/ http://www.html5rocks.com/en/tutorials/webrtc/basics/
- wmf 13y ago
  In addition to what pigubrco said, browser developers consider it dangerous to give Web pages direct access to TCP/IP because that would make it very easy to create botnets. Instead, browsers expose high-level APIs like XHR, WebSocket, and WebRTC and the implementations take care to not be vectors for new attacks.
shmerl 13y ago
For the reference: http://xiphmont.livejournal.com/61927.html http://xiphmont.livejournal.com/61927.html And an interesting part: http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc/#comment-966293 http://blogs.cisco.com/collaboration/open-source-h-264-remov...
jeena 13y ago
So how will I know that the binaries my Firefox downloads from Cisco don't include backdoors which aren't to find in the sourcecode which they provide too?
- jMyles 13y ago
  Well, anybody can build from source and compare to the Cisco-distributed binary, no?
  - u12481632 13y ago
    IMHO Mozilla should build it from source and give it to Cisco for distribution.
  - jeena 13y ago
    This is more complicated then you'd think https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/ https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...

218 points by gz5 13y ago

gz5 13y ago

Good move by Cisco. Mozilla response seems lukewarm though? Mozilla CTO Brendan Eich: “Although H.264 will become available to Firefox users thanks to Cisco’s move, the codec still comes with restrictive licensing that we believe is not in the long-term best interests of users and the Web, compared to the situation with a truly free and unrestricted codec.”

hyperpape 13y ago
That makes sense to me. This is a reasonable compromise for Mozilla, but it's still a compromise. What they want is a free (as in FOSS) codec. What they got is a single free of charge implementation of a patent encumbered codec.
kibwen 13y ago
Here's the announcement from Eich himself: https://brendaneich.com/2013/10/ciscos-h-264-good-news/ https://brendaneich.com/2013/10/ciscos-h-264-good-news/ I wouldn't say that the reaction is lukewarm, but rather reserved. Mozilla's never been a fan of H.264, but supporting it has long since transformed from a philosophical choice to a political necessity. This move helps Mozilla, no question, but it doesn't advance their agenda of patent-unencumbered web standards. Let's hope that VP9 and Daala can do better on this front in the coming years.
nly 13y ago
Personally I'm overjoyed by that lukewarm response.
rubiquity 13y ago
It seems that Mozilla is in a position of doing what is right for pushing the Web forward for end users and doing what is right for the open Web. It's nice to see them choose on the side of end users but I doubt Mozilla will stop looking for a more open alternative.
- mpyne 13y ago
  Not only has Moz not stopped looking for something better, they continue to actively develop something better (i.e. Daala)
mpyne 13y ago
Of course the response is lukewarm, this still represents a failure of open web usage. As a practical measure this is a good move, but that doesn't make this a principled measure.
shmerl 13y ago
It's a "move" but not a solution. Just a temporary workaround. The solution is work on Daala. See http://xiphmont.livejournal.com/61927.html http://xiphmont.livejournal.com/61927.html

bbx 13y ago

No matter what codec will eventually be widely adopted, I hope native video support for browsers will lead to better video players. Right now, I have issues with YouTube (loading speed, quality switching back and forth between 480p, 720p and 240p), Vimeo (still can't jump to a desired position, loads incredibly slowly), various Flash embedded players (won't load, or will reset to 0:00 when trying to change the current position), auto-playing videos, lack of controls, usability issues... I usually end up downloading the video with a Firefox add-on to watch it later. Or just stop bothering and close the tab.

cbhl 13y ago
I've never seen any of those issues -- are you sure your Internet provider isn't throttling video packets with DPI or something?
- redthrowaway 13y ago
  I get the same, and it's not dependent on ISP. Many (most?) flash players are buggy resource hogs, and the html5 implementations I've seen don't feel ready for primetime yet.
  - actionscripted 13y ago
    (Former) Flash nerd here. The problems with plackback and scrubbing are absolutely the fault of the Flash player and there's really nothing you can do about it short of hacking your own video handling into the SWF format. There are a lot of low-level network-related problems in Flash. I have zero real proof, but I know for a long time Adobe (Macromedia) was pushing their streaming server and didn't really put a lot of effort into handling streaming/buffering without it and I suspect this just never got fixed as things were "good enough".
    - krilnon 13y ago
      To be fair, there weren't many (any?) standardized alternatives back then. There was no particular incentive for Adobe to support, say, Red5 when there was no standard to gather around. Apple's HLS is a pretty recent attempt at moving toward a documented standard. If you're talking about streaming .flvs off of a regular Apache setup, then it shouldn't be surprising that scrubbing and seeking are troublesome: static file servers weren't build for that use case. What would you have preferred Adobe to have done?

ck2 13y ago

Yes! Windows XP will get native video playback after all (doesn't support the current microsoft framework workaround). Thanks Mozilla!

gcp 13y ago
Only baseline profile is supported. Don't expect most videos to work.
pix64 13y ago
April 8, 2014 is approaching rather fast...

recuter 13y ago

I find myself increasingly frequently using 'youtube-dl' to grab clips, advantages being that youtube sometimes only buffers a little bit before stopping and this way I don't need to care about keeping tabs open or codecs. Everything always plays fine with VLC and I can mess with the playback speed by simply pressing '[]'. Should probably automate this. Maybe independently of browsers, just sniff my own traffic and MITM myself (request goes to youtube-dl, browser gets a page that closes itself immediately).

GhotiFish 13y ago
I would be interested in developments regarding this. I was thinking perhaps some extension to firefox to trigger youtube-dl. I don't think firefox would provide that kind of system level access to plugins, however.

RRRA 13y ago

So they will pay what? When? with what guarantee? What about production cost of videos? Do we need a license? That doesn't smell very good...

pritambaral 13y ago
The Cisco binary should include encoding as well as decoding for it to be usable in WebRTC. Production systems could download Cisco's binary and use it.
pdpi 13y ago
It's a brilliant hack, they pay exactly zero for this. You get a licence from Cisco, and they pay royalties to the MPEG LA for that licence. Now, the H.264 licence fees are per copy distributed, but there's a cap on the fees, and Cisco's own usage puts them _way_ over the cap anyhow, so distributing this thing freely for Mozilla to use costs them literally nothing at all. Plus, they're apparently really distributing binaries for any and all platforms you can think of (someone mentioned S/360).

wyager 13y ago

So according to this thread: https://news.ycombinator.com/item?id=6640324 https://news.ycombinator.com/item?id=6640324 Mozilla is going to add a Cisco blob to their distributed browser, and not the actual compiled source. Any clarification on that?

mpyne 13y ago
Cisco will release the source code, but according to the H264 licensing terms Cisco has to be the one to distribute the resultant binary if Cisco is to pay for the license. It would be good for others to independently verify that Cisco's source compiles to Cisco's binary, but that still wouldn't give legal permission for those others to distribute the binary -- only Cisco can do that.
- e12e 13y ago
  What's more interesting is if this will allow end-user to compile a binary for personal use. If the build scripts works as well as eg: most c-extentions for python (so you can do like the equivalent on debian for mercurial: apt-get build-dep mercurial; virtualenv --no-site-packages test;cd test;./bin/pip install mercurial -- and have it just work) -- a real "loophole" might actually present itself in the licensing. It still wouldn't be quite as easy on Windows (even if it builds with a free and/or gratis compiler there) -- but on all platforms building a plugin (automagically) should be much more feasible than for "everyone" to build Firefox (that thing is a monster).
  - mpyne 13y ago
    Unfortunately as far as I understand it you're only "licensed" to use the codec if you receive the binary directly from Cisco... even if you manage to compile a bit-for-bit identical equivalent. You'd surely get away with it as a personal-use thing but I doubt distros would automate it for you.

devx 13y ago

Wow, this seems like a very backwards move. Just when the truly open source VP8 was set to go in WebRTC, we're opening the discussion about putting h.264 in there again? Why?! This seems like a very short sighted move.

mayhew 13y ago
Yeah, I don't think they had to compromise this much. Using the H.264 decoder on the host OS was good enough.
mpyne 13y ago
That's just it, it's not apparent that IETF will mandate VP8 in WebRTC even without Cisco's offer here. Nor can Mozilla go it alone, Chrome has already announced they will also support H264. As Monty himself put it on his personal blog, in the matter of VP8 vs. H264, VP8 lost. This is an appreciated measure by Cisco to mitigate the damage until Daala can be fielded to proactive displace whatever MPEG LA tries to push after H264.
- pthatcherg 13y ago
  Chrome has not said it will support H264 in WebRTC.
- cromwellian 13y ago
  What guarantee is there that a codec which doesn't even exist yet won't lose to Microsoft/Cisco/Nokia/et al the next time we need to standardize a MTI codec in some spec? This seems wishful thinking.
  - graue 13y ago
    No guarantee, but the same team was successful at getting Opus (audio codec) adopted as MTI for WebRTC. http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6... On a purely technical level, Opus' performance blew the pants off the other options, which surely helped. If Daala can repeat that performance I think they have a good chance.

hristov 13y ago

This still does not make it better than VP8. Yes CISCO will release a binary for most platforms but not all. They can snub platforms because of lack of resources or for strategic reasons. Furthermore, CISCO has not committed to keep paying the royalties until all patents expire. I suppose it is an ok move by CISCO, but still does not make H.264 acceptable when we have a completely free open source alternative.

zanny 13y ago
We also have vp9 out in the wild and Dalaa sometime in Q1 of next year, we hope.

bstar77 13y ago

I'm thoroughly confused by this press release. I have an app that needs cross browser video support and I was required to use either flash/webm/vorbis to get my videos working in FF. As of a few weeks ago, h264 videos started working in the latest version of FF. Once I discovered that I ditched webm and vorbis and now have it default to mp4. Then I see this press release... Does FF officially support h264 right now? I'm using FF v24 and it seems to already support h264. Is that because I'm using a mac and it falls back on a system codec?

wmf 13y ago
Right now Firefox uses system codecs where available. In the future it will also have the Cisco codec as an option.
gcp 13y ago
>Does FF officially support h264 right now? I'm using FF v24 and it seems to already support h264. Is that because I'm using a mac and it falls back on a system codec? It's using system codecs. Your stuff won't work on Windows XP, which is still a significant percentage of users.
- bstar77 13y ago
  It will work since it falls back on flash, but that's obviously not ideal.

AsymetricCom 13y ago

Can someone explain to me what the purpose of WebRTC is? Why does the browser need some kind of new protocol in a browser to do "real time communication?" I mean, don't we already have TCP/IP?

computerbob 13y ago
As far as I understand it is a way for a 1-1 communication between browsers. No middleman. So when I talk to another browser it is (browser<->browser2) NOT (browser<->Google<->browser2)
randyrand 13y ago
Browsers currently can't do any "hosting" so there is no way to directly connect to another browser. WebRTC solves this problem.
pigubrco 13y ago
WebRTC allows developers to potentially write the next Skype-type application without having to worry about the underlying voice and video codecs, signal processing components like acoustic echo cancellation, bandwidth estimation and other complex components using high level javascript APIs because these components are now baked into the browser. There is also a data channels API that allows for peer to peer data transfer. http://www.html5rocks.com/en/tutorials/webrtc/basics/ http://www.html5rocks.com/en/tutorials/webrtc/basics/
wmf 13y ago
In addition to what pigubrco said, browser developers consider it dangerous to give Web pages direct access to TCP/IP because that would make it very easy to create botnets. Instead, browsers expose high-level APIs like XHR, WebSocket, and WebRTC and the implementations take care to not be vectors for new attacks.

shmerl 13y ago

For the reference: http://xiphmont.livejournal.com/61927.html http://xiphmont.livejournal.com/61927.html And an interesting part: http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc/#comment-966293 http://blogs.cisco.com/collaboration/open-source-h-264-remov...

jeena 13y ago

So how will I know that the binaries my Firefox downloads from Cisco don't include backdoors which aren't to find in the sourcecode which they provide too?

jMyles 13y ago
Well, anybody can build from source and compare to the Cisco-distributed binary, no?
- u12481632 13y ago
  IMHO Mozilla should build it from source and give it to Cisco for distribution.
- jeena 13y ago
  This is more complicated then you'd think https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/ https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...