Re: [rtcweb] Finishing up the Video Codec document

Iñaki Baz Castillo <ibc@aliax.net> Fri, 12 December 2014 18:23 UTC

Return-Path: <ibc@aliax.net>
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 D937B1A1EED for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 10:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 evwJR9y3_-1T for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 10:23:50 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7856E1A7D80 for <rtcweb@ietf.org>; Fri, 12 Dec 2014 10:23:50 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id v10so5478202qac.21 for <rtcweb@ietf.org>; Fri, 12 Dec 2014 10:23:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/lnL3OD5krGPaJXze+GnrGlPa0V+XhwLv0JCEx4Yg9M=; b=bRyIKPwc1ZWQqNUeo2popwHgWiyvTf+62QaCi34ql/a7IoYR2giaBGP30Ehlf98udw 538LAYY+7XBVBCsL6k17bswac/CULJG03on2qM6K0wtTIdCiJydooQyZyj+TkD1UlwoR 5LagVfmLD82fVoXpYYq5NQALLssy7W/6taJBYHpjTvLmOQRQF/EeTZQHsqVHVo3Ms6sn UsmAJR5pcUmU7Y1z9dwWxU3wDYwC14jtS8XgvBHmkHb4v/a0tdxomm18sfqRGR/zLI2X CvNvv/ajuOELr9uEF1RGPcZSrolkCBTj4Kdkdth5ecSc3GYeB2M2CfXBxqCTHRI9Y2zY e75A==
X-Gm-Message-State: ALoCoQm95xySeGdDclPHmpeSrg4vYjQAIziFrDLMq+IbZm5eRE6zPGFReYLj/Muem2LCY165gPi/
X-Received: by 10.224.38.71 with SMTP id a7mr33781088qae.24.1418408629785; Fri, 12 Dec 2014 10:23:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 10:23:29 -0800 (PST)
In-Reply-To: <5476092D.4010406@nostrum.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Fri, 12 Dec 2014 19:23:29 +0100
Message-ID: <CALiegf=gbRFh8Lkyabo3qxZSGVxGjzGhbkp4HrPp2kZZcYRP-g@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NNTArdWquaNzelNHVqZxSmaUziI
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Harald Alvestrand <hta@google.com>
Subject: Re: [rtcweb] Finishing up the Video Codec document
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: Fri, 12 Dec 2014 18:23:53 -0000

2014-11-26 18:09 GMT+01:00 Adam Roach <adam@nostrum.com>om>:
> On 11/26/14 03:15, Daniel-Constantin Mierla wrote:
>>
>> IMO, mandatory codec revisiting has to be done for all webrtc entities.
>> Why not doing it for web browsers when one codec is proved to be royalty
>> free?
>
>
> The rationale here is browser accommodation for very constrained "WebRTC
> compatible" devices, which will most typically be concerned with browser
> interoperation. The example that's been tossed around in this space is the
> "WebRTC doorbell" -- when someone rings the bell, you navigate to its
> interface using WebRTC, and stream an image from a small, embedded camera.
> In these kinds of very-low-cost devices, you're going to likely see hardware
> video encoding (e.g. do a web search for NVS2200), which will likely be one
> codec or another, but not both.
>
> The goal is continued browser support for such devices in perpetuity.


So potential new open source browser vendors will have to deal with
H264 license/patent issues even within the next 6 years just because
the "goal is continued browser support for [old video devices] in
perpetuity". And that goal seems to be more important than making a
W3C/IETF standard 100% free of royalties and patents stuff.

May I know where in the WG chapter is that goal defined please?

-- 
Iñaki Baz Castillo
<ibc@aliax.net>