Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?

"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Tue, 26 November 2013 02:16 UTC

Return-Path: <hangzhou.chenxin@huawei.com>
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 36DA01AE122 for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 18:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 AF0OB3jZVw3R for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 18:16:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A31351AE123 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 18:16:39 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR94270; Tue, 26 Nov 2013 02:16:37 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 02:16:04 +0000
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 02:16:31 +0000
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 10:16:27 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>, "lgeyser@gmail.com" <lgeyser@gmail.com>
Thread-Topic: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?
Thread-Index: AQHO6emAL0HmNLHA8EW7Ei95u3URtJo1e8EAgAADrICAAFYogIAA7Lig
Date: Tue, 26 Nov 2013 02:16:27 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE0397680A16A5@SZXEMA504-MBX.china.huawei.com>
References: <52935C89.5040408@ericsson.com> <CAGgHUiQnkQKkc-ptMu6DtfUYJY6N9i7PUaeAqKxp96nB2MQBGA@mail.gmail.com> <52936207.5040704@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620A13302B@008-AM1MPN1-041.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A13302B@008-AM1MPN1-041.mgdnok.nokia.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.166.41.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?
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: Tue, 26 Nov 2013 02:16:44 -0000

Hi

>-----Original Message-----
>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of
>Markus.Isomaki@nokia.com
>Sent: Tuesday, November 26, 2013 3:52 AM
>To: magnus.westerlund@ericsson.com; lgeyser@gmail.com
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?
>
>Hi,
>
>magnus.westerlund@ericsson.com wrote:
>>
>> On 2013-11-25 15:30, Leon Geyser wrote:
>> > Hi Magnus,
>> >
>> > Was H.263 a typo?
>> > I agree that 10 can be changed to:
>> > 10. MUST implement at least two of {VP8, H.264 CBP, H.261}
>>
>> Sorry,
>>
>> I did a mistake in this call. I missed that 10 and 11 talked about H.261 and
>> H.263 respectively.
>>
>> I think the above question of writing 10 in the above proposed format is then
>> the relevant question to the WG.
>>
>
>I agree that alternatives 10. and 11. are better to be written in the same
>format:
>
>10. MUST implement at least two of {VP8, H.264 CBP, H.261}
>11. MUST implement at least two of {VP8, H.264, H.263}
>

[Xin]I forget who proposed 10 first, but there are differences between new 10 and origin 10. 
In origin 10, H.261 has little chance be implemented. I don't think it is possible that one browser do not implement both H.264 and vp8, but implement H.261. even it is possible, only implement H.261 will not be helpful for interoperation. 
In alternatives 10, H.261 has much more possible be used, which is designed for interoperation purpose. 

So I agree to change alternatives 10. to

 10. MUST implement at least two of {VP8, H.264 CBP, H.261}

>I assume H.264 CBP = Constrained Baseline Profile as proposed in
>draft-burman-rtcweb-h264-proposal.
>
>For H.263 we would need to define if it means H.263 Baseline or something
>beyond that. I have seen at least Stephan Wenger arguing that H.263 Baseline is
>not suitable for WebRTC.

[xin]It is good we could get consensus on H.263 profile before the voting, which will be a argument if we miss it now.

>
>Markus
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb