Re: [rtcweb] Finishing up the Video Codec document

Peter Saint-Andre - &yet <> Thu, 04 December 2014 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 04F6E1AD455 for <>; Thu, 4 Dec 2014 07:46:32 -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 C_fdjgVDeQ4y for <>; Thu, 4 Dec 2014 07:46:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD3031AD475 for <>; Thu, 4 Dec 2014 07:45:30 -0800 (PST)
Received: by with SMTP id rd18so15979614iec.29 for <>; Thu, 04 Dec 2014 07:45:30 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TjlgO5L2szIHEh9y+YikgEAddaYWROfJ1UBeMjcCvr4=; b=c90LpuR4lpHz0NHmU/Dlga0jV0u008G+sqW18hVmnwiMaopKFlRK0xaCwm6kIdWUI1 9clLJdFJhX3T7BUgOag6ny7p1s5uQGq4TXBsnDXP4EYxJ9GO9EZ27h0O1oylWHSSR5lb UckEcW2MvXAghdRU4bb5Vu75X7yncJAS9emDTj3CAInpg9OJiNXqdk5/f9BzhXmkQb7l IBW4FkXphXjYfQAyF7tDY6Z77ESgx5I+/xrEeyvUKZyRwBbp1t78DZm2T+YonAMTbyf2 /1jxs3+qi6BMOJpSdF8qJSiJY25myn84FNf5SkOu0fJiSo3CqTnY7u4pvcSJ4X6dHcsA CN1w==
X-Gm-Message-State: ALoCoQnNBE0XypJuidpmR9LdkKf4bL2qsijyUvWX0vWyKLJN68dyql3v+q4hMnhbKydmLiHTbK5U
X-Received: by with SMTP id e4mr54535099igo.26.1417707929900; Thu, 04 Dec 2014 07:45:29 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id n36sm2791643ioe.4.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:45:29 -0800 (PST)
Message-ID: <>
Date: Thu, 04 Dec 2014 08:45:28 -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: Ron <>,
References: <> <> <20141204150041.GI10449@hex.shelbyville.oz>
In-Reply-To: <20141204150041.GI10449@hex.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 15:46:32 -0000

On 12/4/14, 8:00 AM, Ron wrote:
> Hi Peter,
> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet wrote:
>> 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
>> possibility.
>> Furthermore, this text about WebRTC Browsers sends the wrong message, I
>> think:
>>        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.
> I'd definitely be interested in seeing proposals from you to improve
> upon these things.  It seemed premature to explore this until we had
> some sense of whether this kind of compromise could fly at all, but
> now that it seems it can, I think these are important details for us
> to clarify as best we can.

OK, I'll get to work. :-)


Peter Saint-Andre