Re: [rtcweb] Asymmetric codecs

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Mon, 25 November 2013 14:09 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 CB30A1ADD02 for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 06:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 jGM4g7ndfXHF for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 06:09:16 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7731ADBFF for <rtcweb@ietf.org>; Mon, 25 Nov 2013 06:09:16 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ed-52935a0b70ee
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 08.75.23787.B0A53925; Mon, 25 Nov 2013 15:09:16 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 15:09:15 +0100
From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
Thread-Topic: [rtcweb] Asymmetric codecs
Thread-Index: AQHO6YOHQHY8Un59WEC1K24yFUskgQ==
Date: Mon, 25 Nov 2013 14:09:15 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3F5B06@ESESSMB209.ericsson.se>
References: <CEB676E0.1ED44%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrS5P1OQgg97LLBbXzvxjtHjxYA6T xc2Gx4wWa/+1szuweEz5vZHVY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DK2PttKUvBV7mK F/cfsTcwbpDsYuTkkBAwkVhyeD0LhC0mceHeejYQW0jgEKPEofkmXYxcQPZiRomv374zdzFy cLAJBEs0/XUDiYsI7GWU+D2tmRGkgVlAXeLO4nPsILYwkH19xUVmEFtEQENiWf8NNghbT+Jl 11ewGhYBVYl1s5aALeYV8JVY2dLNDrFYT2LC9IdMIDYj0EHfT61hgpgvLnHryXwmiEMFJJbs Oc8MYYtKvHz8jxXCVpS4On05VL2BxPtz85khbG2JZQtfM0PsEpQ4OfMJywRG0VlIxs5C0jIL ScssJC0LGFlWMbLnJmbmpJcbbmIERsrBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYzJWxUv2ZV07t+1c6bJv045W2Xb0B+5Hf07WJYVFBx96frwp1zw 0oI7PK2vLQtvnLj5xvbT8ayZRnLs4Z25lv57pgglzOZtsD0x83RN+p8LV3by8a/aMCV1walD Qi6fWxv3rreV1vmdFKkcduWU3Y81rRfbp+ttilT60/Q9oHGD/CUDsQDRdy5KLMUZiYZazEXF iQBQBnn2YgIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 14:09:19 -0000

On 2013-11-25 03:11, Mo Zanaty (mzanaty) wrote:
> 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:
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-offer-answer-examples-02.txt
>
> They were removed for fear of issues with shared ports:
> http://www.ietf.org/mail-archive/text/mmusic/2003-09.mail
>
> 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.)

I've in the past been arguing that the WebRTC API, which is geared 
towards sending tracks, fits best with separate m-lines per direction. 
So I'm all for this (naturally the browser must be able to understand a 
sendrecv m-line if some legacy equipment signals that).

I'm not sure what you mean by the dependency on bundle. Do you mean that 
if bundle is not used the result would be that twice the number of ports 
would be needed for a symmetrical session?

>
> 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 <christer.holmberg@ericsson.com>;
> 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) <pgiralt@cisco.com>; 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 <martin.thomson@gmail.com>; wrote:
> The bidirectional thing in O/A is the strange way to do things.  Two
> lines is pretty intuitive.
>