Re: [rtcweb] Codec extensibility (Re: Interoperability between browsers (MTI Video))

Leon Geyser <lgeyser@gmail.com> Sun, 17 March 2013 14:07 UTC

Return-Path: <lgeyser@gmail.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 DD57021F86EF for <rtcweb@ietfa.amsl.com>; Sun, 17 Mar 2013 07:07:32 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 xjH0jCrKHr+n for <rtcweb@ietfa.amsl.com>; Sun, 17 Mar 2013 07:07:32 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2C21F86C5 for <rtcweb@ietf.org>; Sun, 17 Mar 2013 07:07:31 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id fe20so5235407lab.1 for <rtcweb@ietf.org>; Sun, 17 Mar 2013 07:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V8EBklekigAvuiY5F4QKSI/9nWRz1rgEmm5vtU2sQDk=; b=bSrHyVwzo5HEm8mQzn2B49iN13BOpMbgoHYCZkSsNnteFOEqL9a3+Jukm9H5jet8Ep niNDn2FhYPtEVs1HjlMD6jVBa4C2LP9AZVW1EoZjc7NZI5qoLokF803X7AdKQEgCXB3T X/kVbEV/iqkjT52HgzalINcWWH7lJOjiyiiqEmp62mKOnVzbxzwq4/2Df1Y3/gnMPWNW o9yXH2Ugm4EhLi0cbZoI6qYZrI7p2h9INRVtnO0jqeLth+b2DuZKrxNrIl4hryStqRiA 94JfwfVTzJqe7zy3i1uWW18G320ZXLHyKlB5/WpLkc64LmIsGhk53rA2Rs8SngdmoEgT 52PA==
MIME-Version: 1.0
X-Received: by 10.152.113.164 with SMTP id iz4mr11515136lab.50.1363529250401; Sun, 17 Mar 2013 07:07:30 -0700 (PDT)
Received: by 10.114.2.76 with HTTP; Sun, 17 Mar 2013 07:07:30 -0700 (PDT)
In-Reply-To: <8723315D-E820-4BA1-9C51-CD581338722A@acmepacket.com>
References: <CAGgHUiQPNSOEtffncjXMozxPM70hL9N++sM=RkC6qVFGSFNREA@mail.gmail.com> <BLU402-EAS287A23CE95CE9F7C2F324193EE0@phx.gbl> <51456E0F.1050008@alvestrand.no> <8723315D-E820-4BA1-9C51-CD581338722A@acmepacket.com>
Date: Sun, 17 Mar 2013 16:07:30 +0200
Message-ID: <CAGgHUiTW+5pzqV9XBC_JmRi9Sx-=J26gAJaD-ButxVWCUmpTrg@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary="f46d0408930b9c741504d81f643b"
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Codec extensibility (Re: Interoperability between browsers (MTI Video))
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 Mar 2013 14:07:33 -0000

>
> Sure, or an extension that uses an API embedded in the local hardware -
> i.e., if you're on a vendor-X phone and vendor-X provides the extension to
> work in your browser(s).
> Or perhaps the patent holders of H.264 will convince the holdouts to
> accept an RF license for a browser extension, restricted to use only in
> browsers.
>

This might work if such an API is consisitently the same on all phones and
even accessible. What if the hardware does not have the API or no H.264
hardware capability? or vendor-X does not want to supply such an extension
for vendor-X phone?
No interop. Back to square one.

IMO for interop to work there needs to be a common video codec available on
all WebRTC implementations that isn't a codec extension. It must be stock
standard.

An API for access to raw incoming/outgoing data, and for registering a
> codec in the negotiation machinery, would need to be defined, but doesn't
> seem extremely complicated to do (although the details will take some
> care). But the license issue might mean that the first plug-in codecs
> developed would be the ASCII codec, the H.261 codec and VP8.
>

It isn't as easy as creating one plugin that would work on all browsers.
Browsers/CPU Architectures/Operating Systems are all different. Some
browsers might not even allow/have plug-in capabilities.
Also that would mean somebody would have to go and create one for that
browser and it might not be a user friendly experience (It might take an
advanced user to install the plug-in). If there isn't any developer willing
to create that plug-in then there won't be interop. Back to the square one.
Rather let the developers who create the browsers implement MTI codecs. It
would be nice to work out-of-the-box.

If VP8 can be MTI then there is no need for H.261. Let us see what will
happen in the next few weeks.

On 17 March 2013 14:46, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

>
> On Mar 17, 2013, at 3:17 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> > On 03/16/2013 10:17 PM, Bernard Aboba wrote:
> >>
> >> On Mar 16, 2013, at 15:18, "Leon Geyser" <lgeyser@gmail.com> wrote:
> >>
> >>> In my opinion there really is a need for a MTI video codec for
> interoperability between browsers.
> >>>
> >>> Here are some scenarios on MTI decisions:
> >>>
> >>> -- Decide on no MTI codec:
> >>> This would split the browers in two sides.
> >> [BA] No. It just removes the stick that each side can use to beat the
> other side.  The need for interoperability still remains, and most likely
> will either be addressed by the marketplace choosing one over the other
> decisively, or if deployment is split, by support for (limited) codec
> extensibility.
> > An interesting angle on codec extensibility is what license agreement
> one needs in order to deploy a codec extension; it would seem natural to
> assume that one would need an MPEG-LA license in order to deploy a H.264
> codec extension.
>
> Sure, or an extension that uses an API embedded in the local hardware -
> i.e., if you're on a vendor-X phone and vendor-X provides the extension to
> work in your browser(s).
> Or perhaps the patent holders of H.264 will convince the holdouts to
> accept an RF license for a browser extension, restricted to use only in
> browsers.
>
>
> > An API for access to raw incoming/outgoing data, and for registering a
> codec in the negotiation machinery, would need to be defined, but doesn't
> seem extremely complicated to do (although the details will take some
> care). But the license issue might mean that the first plug-in codecs
> developed would be the ASCII codec, the H.261 codec and VP8.
>
> But that's a good thing, no?  VP8 everywhere!
> Besides, it might even foster innovation in new codecs - like 3D video, or
> *color* ASCII/ANSI-code video. :)
>
> -hadriel
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>