Re: [rtcweb] On video codec for rtcweb

"Timothy B. Terriberry" <> Fri, 23 March 2012 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7AAD21F8514 for <>; Fri, 23 Mar 2012 04:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vORjUMacEYfv for <>; Fri, 23 Mar 2012 04:40:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 37E0421F850B for <>; Fri, 23 Mar 2012 04:40:41 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTP id C74614AEDA6; Fri, 23 Mar 2012 04:40:40 -0700 (PDT)
Message-ID: <>
Date: Fri, 23 Mar 2012 04:40:40 -0700
From: "Timothy B. Terriberry" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120305 SeaMonkey/2.7.1
MIME-Version: 1.0
To: Stefan Hakansson LK <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] On video codec for rtcweb
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Mar 2012 11:40:41 -0000

Stefan Hakansson LK wrote:
> So, I propose that h.264 should be mandatory to implement.

Mozilla strongly opposes such a proposal. Many will be familiar with our 
announcements regarding our use of platform codecs on B2G and possibly 
Android last week. The primary reasoning behind that decision, i.e. the 
one factor that was not in our power to change, was the availability of 
content on websites. This is not a problem for WebRTC, as browsers 
control both ends of the communication.

What _is_ a problem is licensing and distributing encoders in an 
open-source project. This is quite a bit different than using system 
decoders, as outside of mobile, encoders are usually not available, and 
even if they were, they might not have particularly good quality, nor 
the features to control latency, loss robustness, and other aspects 
necessary for real-time communication.

If you thought that a concession in one place would make Mozilla more 
likely to compromise in others, I assure you the opposite is true. 
Maintaining the use of RF codecs in WebRTC is now even more important 
than it was before. See the words directly from Mozilla's CTO: