Re: [rtcweb] Asymmetric codecs

Christer Holmberg <> Mon, 25 November 2013 07:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 82FA21AC82A for <>; Sun, 24 Nov 2013 23:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B5ZOq11pGn-U for <>; Sun, 24 Nov 2013 23:45:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7BF551AC828 for <>; Sun, 24 Nov 2013 23:45:33 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-9c-5292ffe8102b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 95.ED.15980.9EFF2925; Mon, 25 Nov 2013 08:44:48 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 08:43:51 +0100
From: Christer Holmberg <>
To: cowwoc <>, "" <>
Thread-Topic: [rtcweb] Asymmetric codecs
Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgZo1iRZw///0yICAABJm0A==
Date: Mon, 25 Nov 2013 07:43:51 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C554536ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre7H/5OCDL79Zbc4c/M/u8Xaf+3s DkweTyZMZ/dYsuQnUwBTFJdNSmpOZllqkb5dAlfGg2X32Qr2Lmas+LIpuIHxSD9jFyMnh4SA icSb/p0sELaYxIV769m6GLk4hAQOMUo8ad3IBOEsZpSYe/05cxcjBwebgIVE9z9tkAYRAU+J v9Pfs4HYwgLqEu8f3WOFiGtILOu/wQZSLiLgJHFkXzSIySKgKvHxqwhIBa+Ar8T2+ZuZIabP YJT4sXcHWCungIFE7/33YLcxAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgfK4St KPHx1T5GiPp8oF2zmCCWCUqcnPmEZQKjyCwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZ A4+ZkMUXMLKvYmTPTczMSS8338QIjJ2DW34b7GDcdF/sEKM0B4uSOO+Ht85BQgLpiSWp2amp BalF8UWlOanFhxiZODilGhh3Tz5/okd2yQS1b69ulxxR3hRrtjj83PXo3/6Xrm+xawuPTD43 3T0utbz0mnvqm62Tty7pdcp2KE0wLIueUyp+/6y27fqijQEd3pPc3tsUHrszie2NS3Lkyjfn fsyv0+nt2bB/bsb3CVM/mO3jefF1o/zf5xsPHQxRPv5VfjNr773mn6+idvL/V2Ipzkg01GIu Kk4EADrcORdrAgAA
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:45:38 -0000


I'm afraid that SDP has become is a little more than an implementation detail :)



From: rtcweb [] On Behalf Of cowwoc
Sent: 25. marraskuuta 2013 9:35
Subject: Re: [rtcweb] Asymmetric codecs

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:

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.



From: Mo Zanaty (mzanaty) []
Sent: 25. marraskuuta 2013 4:11
To: Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
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.


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<>