
Mozilla will add H.264 to Firefox as Cisco makes push for WebRTC’s future - gz5
http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/
======
bbx
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.

~~~
wyck
This has nothing to do with the codec, the quality issues are bandwidth
related, most providers no not want to fork out cash to buffer your video's
anymore.

~~~
GhotiFish
they most certainly are player related. I can easily avoid every problem the
parent has described on a low quality DSL connection by downloading the video
directly and watching the partial download in a native video player.

The state of video players on the internet is just flat out terrible. Given
how restrictive the policies and philosophies are around downloading the
videos and watching them directly, browser players arn't actually competing
with native players. I don't think normal people realize just how terrible
they are. I can't imagine this situation ever getting better.

~~~
michaelmior
Not that I disagree, but the argument that it's not bandwidth-related isn't
refuted by saying you don't have issues by downloading the video and then
playing it with another player.

~~~
GhotiFish
I said I don't have issues downloading video and playing with another player
in low bandwith scenarios.

~~~
michaelmior
But you said you partially downloaded the video, and then played it? Perhaps
I'm missing something, but it sounds like the equivalent of pausing the Flash
player and waiting for it to buffer.

~~~
GhotiFish
Something's gone wrong with communication here:

It is the exact equivalent.

Except it never discards the buffer (they do this all the time), I can seek
with impunity (I do this all the time), it doesn't consume huge amounts of CPU
(they do this all the time), it goes full screen reliably and quickly (on
linux they fail frequently), If there are problems with the connection then I
won't lose everything I've downloaded (online video players are so terrible
about this), I can run it at any speed I want (I do this all the time), I can
supplement it with third party subtitles (I do this all the time) ect. ect.
ect.

further, no bizarre bandwidth saving gets involved. If the connection is very
bad, I can just let it download. It won't stop after 10 seconds and wait for
me to play, and I get to decide when it starts playing. I can resume failed
downloads, I can respond to bad connections, I can use web technologies that
have existed for decades that are specifically there to deal with bad
connections to route around poor network conditions.

Video players on the web are just death by a thousand cuts. They're all
different unique little snowflakes, and all worse then windows media player
from 2001. We are literally swimming in methodologies to deal with poor
network connections, and the inter

but other than that they are equivalent.

------
gz5
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.”

~~~
rubiquity
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
Not only has Moz not stopped looking for something better, they continue to
actively develop something better (i.e. Daala)

------
recuter
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
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.

------
devx
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.

~~~
mpyne
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.

~~~
cromwellian
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
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...](http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf)

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.

~~~
cromwellian
Well, the fact that Skype and Cisco were already onboard and using it helped a
bit and that audio codecs don't have the kind of deployment challenge that
displacing H264 does.

Surely, the argument is going to come around in 2015 or whenever Daala ships
that H264/H265 hardware is too widely deployed on billions of mobile devices
to justify a new codec.

Does Cisco really want to WebRTC to succeed when it clearly commodifies their
WebEx offering? The question is, what are they getting by ensuring H264 is
MTI?

What Mozilla and Google were going to get out of VP8 winning was pretty clear.
So one has to ask what their motivation is for spending so much money to keep
H264 as MTI.

------
hristov
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
We also have vp9 out in the wild and Dalaa sometime in Q1 of next year, we
hope.

------
wyager
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
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
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
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.

------
bstar77
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?

~~~
gcp
>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
It will work since it falls back on flash, but that's obviously not ideal.

------
RRRA
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...

~~~
pdpi
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).

------
shmerl
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-remov...](http://blogs.cisco.com/collaboration/open-
source-h-264-removes-barriers-webrtc/#comment-966293)

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

Thanks Mozilla!

~~~
gcp
Only baseline profile is supported. Don't expect most videos to work.

------
jeena
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
Well, anybody can build from source and compare to the Cisco-distributed
binary, no?

~~~
jeena
This is more complicated then you'd think
[https://madiba.encs.concordia.ca/~x_decarn/truecrypt-
binarie...](https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-
analysis/)

------
AsymetricCom
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?

~~~
pigubrco
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/)

