Re: [rtcweb] Video codec selection - way forward

Gili <cowwoc@bbs.darktech.org> Tue, 19 November 2013 20:25 UTC

Return-Path: <cowwoc@bbs.darktech.org>
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 A528E1AE1A3 for <rtcweb@ietfa.amsl.com>; Tue, 19 Nov 2013 12:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jnyceoCi9vXN for <rtcweb@ietfa.amsl.com>; Tue, 19 Nov 2013 12:24:58 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8885D1AE194 for <rtcweb@ietf.org>; Tue, 19 Nov 2013 12:24:58 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id wn1so2869352obc.33 for <rtcweb@ietf.org>; Tue, 19 Nov 2013 12:24:52 -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=wYBQUgDB7pjWo+PE5IqI+TE5I7wH5ZvUZTos7U6WfS0=; b=ADPt8KNS6wrKG56lxXN2xIudbqu4lkyYKAftoSRabccA+Jsr60e/y9rQfFptZxuguy vE6VYIZsopLzDq/XhR/lnJU5szF7puTBqZFWbRhmnOzZIDlixEtM2EOBPaI4DEZmpVcZ cRIKAiAy3QG3FiCdRtamveZKV/moHkWVKr91I/Yg+sBTVhsiWUqeDwAUWY128RSJ85hE qah6Vn92ozqphq5UvUJlZKh5J77wWYu2b9a3C58xAWn0lGyYXhjzjnXC8pD7OnheMO7S 4er0CCCBfVT+mFWwu+Ad1PSA7n9EvVRhwQxAWeLTz2Zq7bIcs/a+BtpBSMzULaRTOp7+ A2gw==
X-Gm-Message-State: ALoCoQlHvWfdTwEJXNjoukTpF1/Nplpsm3jW2rS6akGqjgVc8UYRPZqmV5W6JQxHbSzM7zLJEIQe
X-Received: by 10.182.28.35 with SMTP id y3mr2854739obg.55.1384892692071; Tue, 19 Nov 2013 12:24:52 -0800 (PST)
Received: from [10.35.1.167] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by mx.google.com with ESMTPSA id ii8sm31613553obb.11.2013.11.19.12.24.50 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 12:24:51 -0800 (PST)
Message-ID: <528BC901.3090206@bbs.darktech.org>
Date: Tue, 19 Nov 2013 12:24:33 -0800
From: Gili <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com> <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com> <528B2ABE.4040701@googlemail.com>
In-Reply-To: <528B2ABE.4040701@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
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, 19 Nov 2013 20:25:00 -0000

+1

On 19/11/2013 1:09 AM, Maik Merten wrote:
> I'm sure the prospect of implementing H.261 is not a desirable one but 
> I wonder if
>
>  - implementing the codec of "the other codec camp" is more desirable
>  - the end-users will appreciate spuriously failing video calls
>
>
> Basically this boils down on what the question is. "Who enjoys 
> implementing H.261?" clearly will be answered as "nobody". However, 
> "who can live with the inconvenience of implementing H.261 for the 
> sake of interoperability and accessibility" may be answered differently.
>
> It would, of course, be preferable if H.261 can be substituted with a 
> higher performing alternative, although I guess the set of codecs with 
> a universally accepted status as "no worries regarding IPR or 
> licensing" is limited.
>
>
> Maik
>
>
> Am 19.11.2013 01:07, schrieb David Singer:
>> It's an interesting idea, but the quality of H.261, the availability 
>> of decent implementations, and its (functional) restrictions may mean 
>> that people are very loath to spend (waste) engineering time on it.  
>> Is this a MUST that would, in fact, get respected?
>>
>>
>> On Nov 17, 2013, at 11:54 , Maik Merten <maikmerten@googlemail.com>; 
>> wrote:
>>
>>> Hello,
>>>
>>> just wondering if something like
>>>
>>> "9. All entities SHOULD support both H.264 and VP8. All entities 
>>> MUST at least implement one of those. Entities that do not support 
>>> both H.264 and VP8 MUST implement H.261."
>>>
>>> has already popped up. My reasoning is that implementations 
>>> supporting both high performance codecs will always negotiate to use 
>>> on of those - H.261 should never be relevant there.
>>>
>>> It appears that all implementors are willing to implement either 
>>> H.264 or VP8 (but not necessarily both). This obviously means that 
>>> negotiation failure regarding a high-performance codec is a 
>>> possiblity. In this case H.261 is actually useful so that basic 
>>> video calls can still be established (for instance, I guess deaf 
>>> people may always appreciate a video connection, as long as sign 
>>> language can be transmitted).
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>>> Hi,
>>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>>> only VP8 has clearly failed. I would welcome anyone to share their
>>>> thoughts on why they believe this situation will change anytime in the
>>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>>> from the list. Hopefully this will speed up the process by focusing
>>>> efforts towards gaining agreement on one of the remaining options.
>>>> The following alternatives has been proposed:
>>>>
>>>> 1. All entities MUST support H.264
>>>> 2. All entities MUST support VP8
>>>> 3. All entities MUST support both H.264 and VP8
>>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>     support at least one of H.264 and VP8
>>>> 5. All entities MUST support at least one of H.264 and VP8
>>>> 6. All entities MUST support H.261
>>>> 7. There is no MTI video codec
>>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>>     least one of H.264 and VP8
>>>>
>>>> Regards,
>>>> Jeremy Fuller
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb