Re: [rtcweb] Video codec selection - way forward

Basil Mohamed Gohar <basilgohar@librevideo.org> Sun, 17 November 2013 20:58 UTC

Return-Path: <basilgohar@librevideo.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07C11E81A3 for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 12:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-y4A3dQWc1k for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 12:58:23 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1011E8DE9 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 12:58:22 -0800 (PST)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 644FF65A543 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 15:58:21 -0500 (EST)
Message-ID: <52892DD8.9050105@librevideo.org>
Date: Sun, 17 Nov 2013 15:58:00 -0500
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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> <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>
In-Reply-To: <6A06EACB-69E2-4CE0-BDF2-1FDFD71159D3@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 17 Nov 2013 20:58:27 -0000

Thomas,

The reason H.261 is even being considered is because it is an old-enough
specification that any patents on it should have now expired.  Patents,
and their liability on existing video formats, are amongst the biggest
factors affecting which formats can be adopted into the rtcweb standard.

H.263 most likely (I haven't checked) still has patents associated with
it that are active and, therefore, present an issue unless the
respective owners of said patents have publicly declared them royalty-free.

On 11/17/2013 03:13 PM, Thomas Reisinger wrote:
> Hi,
> 
> Instead of h.261, I would recommend h.263 as a common base.
> 
> Cheers,
> 
> Thomas 
> Sent from mobile device
> 
>> On 17 Nov 2013, at 20: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
> 


-- 
Libre Video
http://librevideo.org