Re: [rtcweb] Video codec selection - way forward

Jonathan Rosenberg <jdrosen@jdrosen.net> Thu, 14 November 2013 15:57 UTC

Return-Path: <jdrosen@jdrosen.net>
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 5515811E80F2 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 07:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.916
X-Spam-Level:
X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 gyFSLofX5R4X for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 07:57:28 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4411E80E0 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 07:57:27 -0800 (PST)
Received: from mail-pb0-f45.google.com ([209.85.160.45]:55856) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <jdrosen@jdrosen.net>) id 1VgzIG-0005TF-T9 for rtcweb@ietf.org; Thu, 14 Nov 2013 10:57:25 -0500
Received: by mail-pb0-f45.google.com with SMTP id mc8so2213626pbc.32 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/rJvvWNGHKga/Av6yclJcPa7V9YmMZBYM+SNmn+1jF8=; b=hr1tdSpvAAJ8pYCLSQUVZpe7oB9v6splJbqOB8I/TY8YkQxRNXtrnBwe6N6CULN9zu apAmRty7g9wLEMDZvDWdmst8GhFUo43VTwTjUBqn2E77TzvGokIgxqngTrUiPios5JPz Vq7B1wDFPKYMOgCtqU8iMgjoUkph4Y/nG4/38MDMiBTn1vDVTElSmH7PhsPDIQFAWS1p Sl7vJt6qfyQV1mp3VfjSDlv5+w11x2fOSbhMKR2BvkwMm0D8Ns3SH1myOhuCHVOqoPos 6gZFoGbmEwN1OkFKIhs+98Dhwr1qAGvvSHpM1gGKjQQzcwnt/3wsqbKzGkvJz8trOnZj f8qw==
MIME-Version: 1.0
X-Received: by 10.68.40.169 with SMTP id y9mr1962750pbk.193.1384444640433; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
Received: by 10.70.49.48 with HTTP; Thu, 14 Nov 2013 07:57:20 -0800 (PST)
In-Reply-To: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com>
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com>
Date: Thu, 14 Nov 2013 10:57:20 -0500
Message-ID: <CA+23+fFyNzK_tZVAv3qn00uVvBWjU6Rh3CDsPKyJUSYgerwjjQ@mail.gmail.com>
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
To: Jeremy Fuller <jeremy.fuller@genband.com>
Content-Type: multipart/alternative; boundary=bcaec51a754601287d04eb252319
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Thu, 14 Nov 2013 15:57:32 -0000

I agree with others that SHOULD implement both, or other variations on
SHOULD, are not helpful. They will anyway be ignored and amount to more or
less the no-interop situation we're in if we continue on the current path
and have no consensus.  No consensus means the various players doing as
they prefer, which is what they'd do if there is a SHOULD.


On Thu, Nov 14, 2013 at 6:37 AM, Jeremy Fuller <jeremy.fuller@genband.com>wrote:

>  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
>
>


-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net