Re: [rtcweb] Video Codec - Possible to use.

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Fri, 19 October 2012 15:49 UTC

Return-Path: <andrew.hutton@siemens-enterprise.com>
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 D5D5621F874B for <rtcweb@ietfa.amsl.com>; Fri, 19 Oct 2012 08:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level:
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp7GaE+brUUB for <rtcweb@ietfa.amsl.com>; Fri, 19 Oct 2012 08:49:41 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2521921F8744 for <rtcweb@ietf.org>; Fri, 19 Oct 2012 08:49:41 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3312D23F04CC; Fri, 19 Oct 2012 17:49:40 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 17:49:39 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] Video Codec - Possible to use.
Thread-Index: Ac2uAdvfNfH0YMcdSYGJWOnt/4GLHP//7vMA///bPHCAAC18AP//28Ig
Date: Fri, 19 Oct 2012 15:49:39 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130ADDB@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> <CABcZeBNEDjQaKwwwNodsCjCh7G8bkAQSsNnPArbVoXkekZecmg@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF0130AC84@MCHP04MSX.global-ad.net> <CABcZeBME__geZgZQQz3chVezk6FWdox1y2JVY9jOii8ih90sgA@mail.gmail.com>
In-Reply-To: <CABcZeBME__geZgZQQz3chVezk6FWdox1y2JVY9jOii8ih90sgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Video Codec - Possible to use.
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: Fri, 19 Oct 2012 15:49:41 -0000

On 19 October 2012 16:29 Eric Rescorla wrote:
> To: Hutton, Andrew
> So, obviously it depends on *exactly* what one means by the codec being
> available on the underlying platform. There seem to be at least two
> cases:
> 
> 1. This is some feature provided by the OS or platform vendor. In this
> case presumably it comes with documentation and the browser implementor
> reads the documentation and the associated RFCS and generates the
> right SDP. In this case, the situation is not much different from that
> when
> the codec implementation is part of the browser. (Note that in many
> cases
> these codecs come from third party libraries in any case).
> 
> 2. The browser supports some kind of plugin scheme which allows
> people to download their own codecs and install them. This would
> require
> the browser vendor to implement some interface for each codec to
> get a crack at the SDP and is therefore a lot more work.
> 
> Which case are you concerned about?

Both and thanks your answer really helps my understanding and it seems it is really up to the browser vendors and nothing the IETF or W3C can do to influence this.

So would I be correct in thinking that at least for the immediate future webrtc applications will be limited to the codec(s) that the browsers natively support or do browser vendors intend to at least implement option 1 above for at least some commonly used video codec's?

Andy