Re: [rtcweb] Finishing up the Video Codec document

Peter Saint-Andre - &yet <> Thu, 04 December 2014 02:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB6DB1A7032 for <>; Wed, 3 Dec 2014 18:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VHKHj8gZBlrH for <>; Wed, 3 Dec 2014 18:20:48 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93B631A1AEB for <>; Wed, 3 Dec 2014 18:20:48 -0800 (PST)
Received: by with SMTP id rl12so15041050iec.19 for <>; Wed, 03 Dec 2014 18:20:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jj7cofB4Ml4DmkUfoCMMLtNP4tJUBGugfnfruFseDzQ=; b=N71CfYqPImeDz7ltn3SENwSJOQyLyyiFGVj4gQXFkciCoQYjUS0KWg2QS1PhbMlQbZ kGf+TzVkUJvBrLYmxcjOQWlO693cj5tHLaFZDiAyKwsvAGnzozRslk/TlA7xT+nG2Otg Okd3AjYIkJkWS1Rv7DVn62vf+E3pkWHhKGgrZq1UA+ppEhPSKPTCcAfeqxy5dds2Qpes zUugykR8CBmaFG0zKCyHf6zgbOqWZ92AuO0qPpriMZPBM/aLJkHEck5HHebUaIGGYLxh 10IgpoxGSKDHIxnxCdXs0C7lGxXflBIQVDWruwlr1mGTpbICshRkA8PKIcwKfDYy/aN/ qYxw==
X-Gm-Message-State: ALoCoQklvfawMpo/sJ8wIlVFqnUYx0qdNWiM2B/+04rwMQa0h/OKify1owOV9tjf5quiUjaOQ8ln
X-Received: by with SMTP id eh5mr60846082igb.31.1417659647878; Wed, 03 Dec 2014 18:20:47 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id l14sm13695331ioi.31.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 18:20:47 -0800 (PST)
Message-ID: <>
Date: Wed, 03 Dec 2014 19:20:45 -0700
From: Peter Saint-Andre - &yet <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Adam Roach <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Harald Alvestrand <>
Subject: Re: [rtcweb] Finishing up the Video Codec document
X-Mailman-Version: 2.1.15
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, 04 Dec 2014 02:20:52 -0000

On 11/25/14, 4:33 PM, Adam Roach wrote:
> I've updated the draft-ietf-rtcweb-video based on the minutes from
> Hawaii. Now that we have a clear path to success, I'd like to get the
> document finalized and published as quickly as possible. This means I
> need your feedback on the remaining open issues (1, 4, and 5, below). If
> you are CCed on this mail, it's because you took an action item in
> Hawaii, and I'm waiting to hear back from you.
> New version:
> Diff:

I have concerns about the future-oriented text:

       To promote the use of non-royalty bearing video codecs,
       participants in the RTCWEB working group, and any successor
       working groups in the IETF, intend to monitor the evolving
       licensing landscape as it pertains to the two mandatory-to-
       implement codecs.  If compelling evidence arises that one of the
       codecs is available for use on a royalty-free basis, the working
       group plans to revisit the question of which codecs are required
       for Non-Browsers, with the intention being that the royalty-free
       codec will remain mandatory to implement, and the other will
       become optional.

The if-clause in the last sentence establishes a trigger for revisiting 
the combination of VP8 and H.264 as MTI video codecs. But is that the 
only possible trigger? If so, I think the document is misguided.

The ideal solution to the video codec problem would be for the IETF 
community to create a truly unencumbered video codec, as it has already 
done for audio with the Opus codec. If the IETF (or some other standards 
development organization) were to develop such a codec, then I think 
that would be a sufficient trigger for revisiting the recommendations in 
this document, no matter what happens with the royalty-free status of 
VP8 and H.264.

I would strongly prefer that the document contain text recognizing that 

Furthermore, this text about WebRTC Browsers sends the wrong message, I 

       These provisions apply to WebRTC Non-Browsers only.  There is no
       plan to revisit the codecs required for WebRTC Browsers.

Certainly there is no active plan at this time to revisit the MTI codec 
issue (after all, we're still *visiting* the issue for the first time), 
but that's immaterial to the question of when it might be appropriate to 
do so. The current text reads as if there are no conditions under which 
the MTI codec issue would ever be revisited, and that's just wrong.

(A smaller but not insignificant issue is that the document talks about 
"the RTCWEB working group", "any successor working groups in the IETF", 
and "the working group" interchangeably. Yet can this document establish 
plans for successor working groups, or even future incarnations of the 
RTCWEB working group? Any plans related to future efforts will be set by 
WG consensus or IETF consensus, not for all time by this document.)

IMHO we need to either pull out the future-oriented text entirely (which 
has its own problems) or significantly improve it. I would be happy to 
propose text for the latter.


Peter Saint-Andre