Re: [rtcweb] Finishing up the Video Codec document

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 04 December 2014 15:46 UTC

Return-Path: <peter@andyet.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F6E1AD455 for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 07:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_fdjgVDeQ4y for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 07:46:29 -0800 (PST)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3031AD475 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 07:45:30 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id rd18so15979614iec.29 for <rtcweb@ietf.org>; Thu, 04 Dec 2014 07:45:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.50.50.196 with SMTP id e4mr54535099igo.26.1417707929900; Thu, 04 Dec 2014 07:45:29 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n36sm2791643ioe.4.2014.12.04.07.45.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:45:29 -0800 (PST)
Message-ID: <54808198.7030207@andyet.net>
Date: Thu, 04 Dec 2014 08:45:28 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
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 <ron@debian.org>, rtcweb@ietf.org
References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <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
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_nS2uLiPnur6u7JvRY1c0xsIKz0
Subject: Re: [rtcweb] Finishing up the Video Codec document
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
>>> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt
>>
>> 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

-- 
Peter Saint-Andre
https://andyet.com/