Re: [rtcweb] Asymmetric codecs

cowwoc <> Mon, 25 November 2013 07:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B6AA1AC7F2 for <>; Sun, 24 Nov 2013 23:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tfu95vqerz8J for <>; Sun, 24 Nov 2013 23:35:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 207B41AC43E for <>; Sun, 24 Nov 2013 23:35:27 -0800 (PST)
Received: by with SMTP id to1so6112734ieb.4 for <>; Sun, 24 Nov 2013 23:35:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=aNTo9sdOBbBlx6f+i3e8wfTrtsi2g11tX9fyTR0GR8I=; b=lS6KWY+4ycBoU4wFm0PHCPQEWtskOa9huvE/uouSigJTv5XbugQmzmhN5ToEkqOY3s 5tI73OtHi+5IGCydFrY/hO8dt3cGSbQjUagn/HN6Dd5gIkuQd3lC52TymEfbr/s+ohZi tJ8zvt4uLYZ6TPOc26zc6DnRqsD4BKnZjb7LZdGCJB7dUBSj16Qdcrm2e/0b30Ge0FNR b0monC9uliqI5DIi2k7qGAQ/BEqmJZ5T1Aq3bH18/ejnoK8JL0NBm+ZJjUq9LHrL6cb+ Bi9OTMn9jpXqh0CKySA+pV3ahMaBTpmK8v0eyh5BblkrvtswXPXzz3PkZol5WKYrEt+a loBA==
X-Gm-Message-State: ALoCoQmSCYDw4sMeyAg/bvpQMWfI4U70857IIFhM6mo109JXRUjcm/v7FGcuDakI6sycU3WFOqJE
X-Received: by with SMTP id g19mr11891100igz.1.1385364927255; Sun, 24 Nov 2013 23:35:27 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ft2sm25081579igb.5.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 23:35:26 -0800 (PST)
Message-ID: <>
Date: Mon, 25 Nov 2013 02:34:53 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060208090805040304010607"
Subject: Re: [rtcweb] Asymmetric codecs
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Nov 2013 07:35:30 -0000

SDP is supposed to be an implementation detail. Let's figure out whether 
asymmetric codecs solve our problems and wedge it into SDP later.

I suspect that this approach reduces the IPR risk, but H.264 royalties 
still apply, do they not?

Sadly this means we're stuck with: "MUST decode at least two of [VP8, 
H.264, H.261] and MUST encode at least one of them".


On 25/11/2013 2:24 AM, Christer Holmberg wrote:
> Hi,
> First, from a pure MTI codec perspective, the question is whether 
> usage of asymmetric codecs would solve the issues that people have.
> Second, from an SDP OA/BUNDLE perspective, I don't think we can 
> mandate *usage* of BUNDLE. And, even if we did, in the initial Offer 
> you still need to assign unique port values for each m- line (as 
> agreed in Vancouver).
> ...unless, of course, you assign an SDP 'bundle-only' attribute to all 
> m- lines with asymmetric codecs.
> Regards,
> Christer
> *From:*Mo Zanaty (mzanaty) []
> *Sent:* 25. marraskuuta 2013 4:11
> *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
> *Cc:*
> *Subject:* Asymmetric codecs
> I started a draft on how to standardize support for asymmetric codecs 
> back in September. The primary motivation was decoding H.264 and H.265 
> while only encoding H.264. A secondary motivation, for rtcweb, was 
> decoding H.264 and VP8 while only encoding one of them, as Stefan 
> mentioned. I thought it would be a trivial thing to write up by the 
> Oct. 6 deadline for MTI proposals. The draft is still incomplete and 
> unpublished because all solutions are ugly and overly complex for 
> something so seemingly trivial, just like bundle and unified plan. I 
> now sympathize with Christer and Adam for how they arrived at those 
> (not exactly elegant) solutions, and agree with Martin that a pair of 
> (bundled) m-lines is the most viable (although not exactly elegant) 
> solution for asymmetric codecs.
> RFC 4317 drafts originally included asymmetric codecs until they were 
> removed in draft 02:
> They were removed for fear of issues with shared ports:
> Now that we (almost) have bundle, can we resurrect asymmetric codecs 
> with separate sendonly and recvonly m-lines? Are folks ok with a 
> dependency on bundle? I would be happy to complete a draft in that 
> direction. (That is, a general mmusic draft on asymmetric codecs, not 
> a rtcweb draft on MTI asymmetric codecs. I will move the discussion to 
> mmusic after getting rtcweb opinions first.)
> Some may consider this a bizarre corner case. However, for hardware 
> codecs, it is the norm not the exception to have asymmetric encoder 
> and decoder formats. Especially for new formats, which usually appear 
> in hardware decoders well before hardware encoders are available. This 
> happened for H.264, H.265, VP8, and virtually every popular codec 
> format in virtually every popular chipset.
> Mo
> On 11/23/13, 9:09 AM, Christer Holmberg 
> < 
> <>> wrote:
> Like some others, I think the must-decode-both-must-endcode-one 
> alternative as such sounds interesting (whether it has any impact on 
> the licence/IPR issues I'll leave to others to speak for). However, I 
> have big concerns over the proposal to indicate sendrecv for a codec 
> even if an entity is only able to receive/decode it. ... Usage of 
> unidirectional, sendonly/recvonly, m- line would of course solve this, 
> and you might know that it is one option we are discussing in CLUE 
> (for other reasons than MTI codec, though).
> On 22 November 2013 16:20, Paul Giralt (pgiralt) < 
> <>> wrote:
> I gave this as an example of a possible way to do it, but that means 
> you need two separate m= lines - one for send and one for receive. 
> Seems strange to do this for something that you really want to be a 
> single bi-directional stream.
> On 11/22/13, 8:03 PM, Martin Thomson < 
> <>> wrote:
> The bidirectional thing in O/A is the strange way to do things.  Two 
> lines is pretty intuitive.
> _______________________________________________
> rtcweb mailing list