Re: [rtcweb] Asymmetric codecs

Basil Mohamed Gohar <basilgohar@librevideo.org> Mon, 25 November 2013 17:54 UTC

Return-Path: <basilgohar@librevideo.org>
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 393881ADFCB for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 09:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uDPptTZzfJ_l for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 09:53:59 -0800 (PST)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id B9A771ACB4E for <rtcweb@ietf.org>; Mon, 25 Nov 2013 09:53:59 -0800 (PST)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BB3A665A988 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:53:59 -0500 (EST)
Message-ID: <52938EB4.8010004@librevideo.org>
Date: Mon, 25 Nov 2013 12:53:56 -0500
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CEB676E0.1ED44%mzanaty@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <CEB8D9AC.1F15E%mzanaty@cisco.com>
In-Reply-To: <CEB8D9AC.1F15E%mzanaty@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Asymmetric codecs
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: Mon, 25 Nov 2013 17:54:02 -0000

On 11/25/2013 11:13 AM, Mo Zanaty (mzanaty) wrote:
> Re: MTI, I don’t think asymmetric codecs will solve all the MTI issues.
> However, it may solve some practical deployment issues regardless of MTI
> decisions. If products have a decoder but no encoder, it may help to
> express that. For example, Chrome can expose its H.264 decoder for
> webrtc despite no encoder. Hardware products can expose their VP8
> decoder for webrtc despite no encoder.
> 
> Re: SDP, if you want asymmetric codecs over the same port, is it ok to
> mandate bundle to achieve this? I started with a single sendrecv m-line
> with all payload types that can be decoded but not necessarily encoded,
> as Justin suggested. That would not require bundle. However, it gets
> ugly when adding extra signaling for which payload types can’t be
> encoded and multiple O/A rounds for interop with arbitrary peers. The
> complexity approached bundle, so I ended up with separate
> sendonly/recvonly m-lines, as Martin suggested.

For what it's worth, if it doesn't muddy things up, having *support* for
a different codec being sent from both sides, doesn't sound like a
terribly bad idea.  Maybe a lower-end device, say, a watch or something,
can encode to a simpler codec but decode a more advanced one.  However,
this should be weighed on its own merits, and really shouldn't factor in
at all to the MTI discussion in my opinion.
-- 
Libre Video
http://librevideo.org