Re: [rtcweb] Proposal for H.263 baseline codec

Basil Mohamed Gohar <> Thu, 29 March 2012 13:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ABAA21F8B5A for <>; Thu, 29 Mar 2012 06:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZMLzIbPhBhTL for <>; Thu, 29 Mar 2012 06:19:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 574BE21F8B59 for <>; Thu, 29 Mar 2012 06:19:40 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 1E07865265C for <>; Thu, 29 Mar 2012 09:19:39 -0400 (EDT)
Message-ID: <>
Date: Thu, 29 Mar 2012 09:19:31 -0400
From: Basil Mohamed Gohar <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=5AF4B362
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposal for H.263 baseline codec
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: Thu, 29 Mar 2012 13:19:41 -0000

On 03/29/2012 08:15 AM, Dean Willis wrote:
> In today's meeting I made a plea for a mandatory baseline codec that
> is approachable to the small developer without the cost and IPR risks
> of either H.264 or VP8.
> I believe that some sort of baseline codec is required to jump start
> the protocol. It's OK if this isn't the best possible codec. Market
> forces will assure that commercial implementations converge on a
> higher quality when the market requires it.
> While I proposed today that H.261 could serve as a baseline, we know
> this would be "extremely basic". In other words, it might not pass the
> "good enough to use" test required for a successful launch.
> Stephane and several others suggested H.263 as an alternative during
> the after-meeting chat. While it is not as IPR-safe a choice as H.261,
> it is relatively mature and the known challenges have generally
> failed. Implementations are reasonably available and should make it
> possible for smaller implementers, students, and hobbyists to play
> ball. It's not all that network efficient and is outright piggy at
> higher resolutions, but it probably works "well enough to use."
> So I propose we set H.263 as the baseline ( I expect a bit of
> profiling may be necessary to further qualify the baseline) and run
> with that for now. If the situation changes, we can always replace it
> before final publication.
> --
> Dean
Claiming that VP8 is riskier than a known IPR-enforced format is a
specious claim considering its already widely implemented usage across
the web on numerous sites and in hardware.  Additionally, a patent pool
was called for over a year ago, and nothing has been made public about this.

No technology can be completely free from the specter of patent trolls
and spurious software patents, so these arguments that VP8 is not
suitable based on this could be applied to anyone.  The fact of the
matter is that the only known patents on VP8 are owned now by Google and
they have been licensed in a way compatible with all appropriate uses of
the technology, including WebRTC.

While I appreciate the sentiment of this suggestion, I am of the opinion
that choosing a known-restricted format over VP8 will be
counter-productive to the adoption of the WebRTC standard and will, in
fact, restrict possible implementations.