Re: [rtcweb] Video codec selection - way forward

Maik Merten <maikmerten@googlemail.com> Wed, 20 November 2013 18:45 UTC

Return-Path: <maikmerten@googlemail.com>
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 3E2BA1AE063 for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 10:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 F3lFcK4MR46F for <rtcweb@ietfa.amsl.com>; Wed, 20 Nov 2013 10:45:51 -0800 (PST)
Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD751AE04D for <rtcweb@ietf.org>; Wed, 20 Nov 2013 10:45:51 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id e49so4203873eek.21 for <rtcweb@ietf.org>; Wed, 20 Nov 2013 10:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JMdUY4btTHDguqC/spuK6V6Y7oEelV/1H4HDNggyqpQ=; b=MIjF2QEBtpsL9NPsXmmdyqc/gxBc7OB3e/WfTGIVNEQIzuTMz55QLqKlgQ1tByrJka z5gyZXy7q4+8fjtu4yUHZnPg01deZ1x0Z3vaGNXMqoS5aG3IZrEK7D2ROp0Qr1Pha3Sg yg4U5wNN4uNMN7hR8x/PZuZOcO5z4lNcvX78E6RqMykBfQ1mYgLFqkZRsgnS69f6L2Gr e7Oju7tN8FuJDiWHg6dwsZhW982RFl1W+GH57KOhmX3aVfuD4yiG/8ThAMPTpSTPsIHv lpmbJF/a06tk1+5ZjOQcjlTog1GRnTYrnd4GTW2AJplkjRQmhreuVkNLtOzo4UR8e4G/ btUw==
X-Received: by 10.14.205.8 with SMTP id i8mr2764024eeo.19.1384973144401; Wed, 20 Nov 2013 10:45:44 -0800 (PST)
Received: from [192.168.2.101] (dslb-188-101-189-061.pools.arcor-ip.net. [188.101.189.61]) by mx.google.com with ESMTPSA id h48sm6530538eev.3.2013.11.20.10.45.42 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 10:45:43 -0800 (PST)
Message-ID: <528D0355.3090603@googlemail.com>
Date: Wed, 20 Nov 2013 19:45:41 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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>, , <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com>, , <528B2ABE.4040701@googlemail.com>, <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl>, <528C79AD.10608@googlemail.com> <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl>
In-Reply-To: <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl>
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.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: Wed, 20 Nov 2013 18:45:53 -0000

Dear Bernhard,

I'm completely with you regarding that a reliable mechanism for 
multi-codec handling is needed, no matter the outcome of the codec 
discussion. After all, everybody will want to deploy new codec 
technology in the future.

I also think that pressure from customers will eventually lead to 
transcoding services being offered to serve as a bandaid in case no 
consensus can be achieved. I'm saying "bandaid" here, because I suspect 
that in practice such transcoding services will introduce costs (which 
may not be acceptable to new players), increase latency (always not so 
nice), and possibly introduce single points of failure (nasty for 
everyone). Reliance on such services would be a admittance of failure 
regarding P2P interoperability.

(Personally, I would consider it a grave specification bug if users 
cannot reliably establish even a basic, direct video call, with every 
involved entity adhering to the spec and network conditions permitting.)

You're of course right that mandating something without consensus cannot 
possibly be solution. I'm just hoping there's consensus that P2P 
interoperability does matter. From my point of view H.261 is an option 
that can enable (very) basic video interoperability (engineering 
perspective) and also is trouble-free regarding IPR (legal perspective, 
which appears to be what's making consensus on codecs difficult). Having 
a solution that engineers can implement and lawyers can agree to seems 
to be a rare constellation. It's up to implementers to decide if they 
are willing to make use of it to achieve basic interoperability.


Best regards,

Maik



Am 20.11.2013 18:44, schrieb Bernard Aboba:
> Maik said:
>
>  > Cisco's offer, while certainly useful in some (or even many) application
>  > contexts, cannot cover all relevant deployment scenarios.
>
> [BA] I'd note that the current IETF discussion of MTI video codecs is
> somewhat similar to a previous discussion in W3C relating to the MTI
> codec for streaming video.   In that previous discussion, advocates of
> the potential MTI codecs offered to implement their preferred codec for
> other browsers.  So if past is prologue, other offers may emerge over time.
>
>  > Without a fallback codec there will be negotiation failure in ways
> that are out of control of the affected users.
>
> [BA] In practice, negotiation failure is annoying enough that customers
> and users are going to demand that it be addressed in some fashion.
>   This could be via native implementation of multiple codecs, via codec
> plugins as Cisco has proposed, or via on-premise or cloud-based
> transcoding solutions as Justin has described.   Given the penalties
> that the marketplace will impose on services that don't address
> interoperability in some fashion, it seems to me that the issue is very
> likely to be addressed in practice, at least for commercial services.
>
> On the other hand,  attempting to impose a solution that has no real
> consensus could do real damage, by diverting resources away from
> implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the
> WebRTC protocol specifications so as to fully enable multi-codec
> support, which is going to necessary whichever camp you're in.