Ericsson launched a new mobile browser with WebRTC support. Its main purpose is to push Google in their open codec wars.
Ericsson Labs has just released a new mobile web browser called “Bowser”. They removed the R from the name but added WebRTC into it. Knowing marketing speak when I see it, they refer to it as “The World’s First WebRTC-Enabled Mobile Browser”.
What is in there?
- Support for iOS and Android
- On the audio front, G.711. Or as they write it: “The audio codec currently used in Bowser is the G.711 codec.” – I wonder if the next one supported will be Opus or AMR-WB…
- On the video front, H.264. In their words: “H.264 is a well-known codec with proven performance and quality”
I’ve presented the issue of codecs in WebRTC during the WebRTC Conference in Paris earlier this month. In it, I tried touching on the various standpoints each company had regarding the codec selection and where they came from with it. Ericsson is there as well.
[slideshare id=14701698&doc=20121012-webrtc-codecs-121012094007-phpapp02]
As I stated during my talk, codec selection for WebRTC has nothing to do with technology and everything to do with business decisions – usually political ones.
So why did Ericsson release a mobile browser?
Because they needed to assert their position as to the right codecs for WebRTC, and what better way is for doing that than come with a ready implementation?
On the desktop, we already have browsers that support WebRTC (Chrome and Firefox to some extent). They all come with Opus and VP8 in them; and while Opus has been selected as a mandatory codec, VP8 was not – the video codec selection is an open issue. Coming to the browser fight on desktop with an H.264 codec is something you might expect from Microsoft or Apple (Apple recently indicated they actually want H.264 as the mandatory codec – their first public opinion regarding WebRTC).
Mobile was left wide-open. Google left it for later, wanting to focus on getting WebRTC out the door on desktop, and Ericsson found a gap to close – one that will also allow them to put up a video codec fight.
Ericsson needs H.264:
- They are a part of MPEG-LA, owning patents in H.264. Whoever ends up using H.264 ends up paying to Ericsson. I don’t think they pay for its use, though I am not sure about it
- They have worked with H.264 for years. Shifting now to another codec means a world of pain – relearn, development, changing roadmaps – no fun
Now that we have WebRTC on a mobile browser, how do we make that video call with the desktop? One has VP8 and the other has H.264.
Which one will developers be using the do their initial alpha versions of their products? The mobile one or the desktop one – both won’t work with one another…
This move will put pressure on Google and probably on Mozilla to introduce their own WebRTC-enabled mobile browsers. Not the first to market, but ones that support VP8 as well.
Let the codec wars continue 🙂
Hopefully the next version will support Opus at Mono, 64Kbps(or lower) Wideband. 64Kbps Narrowband seems like a waste.
Leon,
The unknown here is video – will they be adding VP8 or skipping it to make a point and trying to make H.264 the de facto codec for WebRTC (similar to how Google is operating with VP8).
Counterpath’s mobile clients are said to support SILK in recent releases. Given this it’s not unreasonable to expect that they may move support Opus, especially since the RFC has been confirmed.
Counterpath’s mobile clients are said to support SILK in recent releases. Given this it’s not unreasonable to expect that they may move support Opus, especially since the RFC has been confirmed.
Seems like posturing to me. They launched their modified-WebKit based desktop browser a while back, and have not really advanced it (still running ROAP, no SRTP)…it appears Bowser is no further along in this regard. I guess I assumed they did it for for the publicity, with no real intention to advance browser technology…but your points on codecs seem to make sense.
Seems like posturing to me. They launched their modified-WebKit based desktop browser a while back, and have not really advanced it (still running ROAP, no SRTP)…it appears Bowser is no further along in this regard. I guess I assumed they did it for for the publicity, with no real intention to advance browser technology…but your points on codecs seem to make sense.
In the WebRTC video codec world we seem to have two clear camps.
VP8 – Google, Mozilla, Opera
H.264 – Apple, Cisco, Ericsson, Microsoft
Yesterday Mozilla CTO, Brendan Eich, reiterated his vow to “take the fight of unencumbered codecs to WebRTC”.
Lets hope they can come to an agreement that allows developers to not have to transcode server side. This is a very high price to pay for non-agreement.
We’ll probably end up installing 2 browser apps on our mobile devices, and then the WebRTC script will launch one or the other depending on which browser the party to be video-called has open ( e.g. in iOS: http://stackoverflow.com/questions/7658685/how-to-open-native-ios-app-calendar-notes-from-a-link-on-website )
In the WebRTC video codec world we seem to have two clear camps.
VP8 – Google, Mozilla, Opera
H.264 – Apple, Cisco, Ericsson, Microsoft
Yesterday Mozilla CTO, Brendan Eich, reiterated his vow to “take the fight of unencumbered codecs to WebRTC”.
Lets hope they can come to an agreement that allows developers to not have to transcode server side. This is a very high price to pay for non-agreement.