Re: [rtcweb] Video codec selection - way forward
cowwoc <cowwoc@bbs.darktech.org> Mon, 18 November 2013 03:06 UTC
Return-Path: <cowwoc@bbs.darktech.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 B24FD11E80E2 for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 19:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level:
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 bBvyPGozDUA0 for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 19:06:49 -0800 (PST)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3C11E8122 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 19:06:45 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so1714160iec.13 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 19:06:45 -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=r+EFNfb+gfoKYWQvxmW8fosPdhpIFotILRDgJExlEoo=; b=QLZrKUfMZ6q+dye6m8XCkG7z+GZkI0SBfHgnC1nGDf6vE1Wueqwo/INlmZu48EngjV HeCevT9iByVOUWPVPM56dk+vnI2mpLZ6lF6xg1TVLwKIFquxkjoGwZB8sr5WrM4eC7GX m3DcqRyAKJeYvLc42lMxjIMDhbIsQbRLak2rc2Wy3SXK5osji05MsoIyLSdrXq+UBcKM z7YYqOIaH2/3c4PinDcszKl9vqaopz/XaTGTdDhwBqj7jBsrEmgRvp1xTPFo5OQIDs+1 eOuxVo3g37/0R+wfkzQ6pjioqEHBhwZPdnEYV6SwajJMUeXTq9OGrGz4AZqbqzK0aTOt uiYA==
X-Gm-Message-State: ALoCoQlAwTi2d8TdHAbuUQzo51dXQ3gOYiVbH+p1MLNX0Z+LC+aRxbQavoRzi3EhqcVjecnzJ50E
X-Received: by 10.50.129.39 with SMTP id nt7mr12178119igb.13.1384744004647; Sun, 17 Nov 2013 19:06:44 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm11461866igx.8.2013.11.17.19.06.43 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 19:06:43 -0800 (PST)
Message-ID: <5289842C.5030406@bbs.darktech.org>
Date: Sun, 17 Nov 2013 22:06:20 -0500
From: cowwoc <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>
In-Reply-To: <52891EDB.2050607@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.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: Mon, 18 Nov 2013 03:06:53 -0000
Maik, Interesting :) +1 for adding this as a new option. It gives the H.264 and VP8 crowds incentive to implement each other's codecs, or suffer with an older codec (H.261). It's a win-win either way. My only worry is that this option will lead to the neglect of H.261 support. So long as the working group commits to providing a "good enough" H.261 implementation (with a commercially-friendly license) as part of the reference WebRTC implementation I think we will be okay. Gili On 17/11/2013 2:54 PM, Maik Merten 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
- [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward cb.list6
- Re: [rtcweb] Video codec selection - way forward Robin Raymond
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Gustavo Garcia
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Jeremy Fuller
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bjoern Hoehrmann
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Harald Alvestrand
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Ross Finlayson
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- [rtcweb] H.263 licensing situation Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- [rtcweb] Reference implementation of software cod… cowwoc
- Re: [rtcweb] Reference implementation of software… cowwoc
- Re: [rtcweb] Reference implementation of software… Maik Merten
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Adam Roach
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Steve Kann
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Monty Montgomery
- Re: [rtcweb] Video codec selection - way forward Matt Fredrickson
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Enrico Marocco
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Matthew Kaufman
- [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 Matt Fredrickson
- Re: [rtcweb] cisco binary on ec2 Lorenzo Miniero
- Re: [rtcweb] Video codec selection - way forward cb.list6
- [rtcweb] H.264 CBP (was: Video codec selection - … cowwoc
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Eric Rescorla
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Stefan Slivinski
- Re: [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 cowwoc
- Re: [rtcweb] cisco binary on ec2 Roman Shpount