Re: [rtcweb] Asymmetric codecs

Justin Uberti <juberti@google.com> Mon, 25 November 2013 20:21 UTC

Return-Path: <juberti@google.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 D46511ADFCF for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 15iP4m3Auqhs for <rtcweb@ietfa.amsl.com>; Mon, 25 Nov 2013 12:21:35 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A377D1ADFC8 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:21:35 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jw12so3389730veb.31 for <rtcweb@ietf.org>; Mon, 25 Nov 2013 12:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KQHPNvej4QzclJ84FUWlUpkhAjYCexDIJWBTCsDzFBI=; b=my4SD7xi3W3+wVTtSUAUA9rSPCvEIjrIy+vGCh3gmUzAOfE8LqftNqpGHxP4p4dvJd jttZ3NLlubdBznmaDV+qdDyzVmUg8PUXdvobTP3UNlF2lAg1NnVP9G6BIERNm1FQnN7M qzD+crPjZj7eBohCCZHfmv2WtjN1hf9YlFMDj6AdNzTz68u5BziMehABwM/f2t9fgf6a 2cyzTdzjJLyrNdKKlCWITsaD++Q9dM7rP7c3TUH+RkRs3UqmJQc2/unkKOUw+nUQ88EY 5MrC7SdNVy/jN2UbYK13+5JXI8LwwvcqjONam5MftZjkwUj/awU7DKYAlqXjD3c8n+Ro uzTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KQHPNvej4QzclJ84FUWlUpkhAjYCexDIJWBTCsDzFBI=; b=Vquap2/RlZ8uAdLNCqJ+zF7mK6mWp3pEde2Oml1FIXmhQ6iyvwhxhOf/Nr3zj4Peaq pA99I7cbwuvXL5JBarTyp4kYUi6455znHzOFuoKSeeChVq1Jgj583GMGmo8A/5Qt7xFa EgIhUxRPeHbLq3/E4RrlBXiPBJXNHHoI2ey/pADkk/Tp7df2rXCqHb9wcSogUJHcKGdg e6V2H71Q8FI/0pNcbOn9GzpYdCJNbIN5IaZ+R/NyXr2YQ7MbbtX6rigP0M1XZj1JcUUU IusMN+3UQwOdkWZ83C4e0p6jJ/J3pi0Crt4ZpqloxUY0I397Our/2HcCghpEjhOwj1E2 WE3Q==
X-Gm-Message-State: ALoCoQmF29V+16Bu3QRvym5uTO+7voLpT25e97tmNkKSPvgUfz/N/3pYTiFIeXGyJKN6bpUxQsa8iOxNks+YrPlnrRmQjL9i6TmuEzRYttOp+GAIQEApjvYuGmPOiwizBo7JItbXYABV838MFT7khDtkXRhutFhjWeCWrSJ3KQDh1baM4+3E7TR6ySoT9ic0kzARviY+XTCi
X-Received: by 10.220.123.6 with SMTP id n6mr1820933vcr.28.1385410895398; Mon, 25 Nov 2013 12:21:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Mon, 25 Nov 2013 12:21:15 -0800 (PST)
In-Reply-To: <52938846.3040803@bbs.darktech.org>
References: <CEB676E0.1ED44%mzanaty@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55441B@ESESSMB209.ericsson.se> <5292FD9D.3020207@bbs.darktech.org> <7594FB04B1934943A5C02806D1A2204B1C554536@ESESSMB209.ericsson.se> <52938846.3040803@bbs.darktech.org>
From: Justin Uberti <juberti@google.com>
Date: Mon, 25 Nov 2013 12:21:15 -0800
Message-ID: <CAOJ7v-25fHv7U51yj5cLB7yPpiGmB7=YLXHEoQquqYQ=hyfSEg@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=089e011770f149e2c704ec061c36
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 20:21:39 -0000

SDP is just a serialization format, a clumsy yet somehow popular one.

Nothing we decide here on codecs will impose any mandate on what
serialization format is used in WebRTC 2.0.


On Mon, Nov 25, 2013 at 9:26 AM, cowwoc <cowwoc@bbs.darktech.org>; wrote:

>
> <cough> told you so <cough> :)
>
> So folks, what happens when we try removing any mention of SDP from the
> 2.0 spec? :) Are you saying this is no longer possible?
>
> Gili
>
>
> On 25/11/2013 2:43 AM, Christer Holmberg wrote:
>
>  Hi,
>
>
>
> I’m afraid that SDP has become is a little more than an implementation
> detail :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org <rtcweb-bounces@ietf.org>] *On
> Behalf Of *cowwoc
> *Sent:* 25. marraskuuta 2013 9:35
> *To:* rtcweb@ietf.org
> *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".
>
> Gili
>
> 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) [mailto:mzanaty@cisco.com <mzanaty@cisco.com>]
>
> *Sent:* 25. marraskuuta 2013 4:11
> *To:* Christer Holmberg; Martin Thomson; Paul Giralt (pgiralt)
> *Cc:* rtcweb@ietf.org
> *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:
>
>
> 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.)
>
>
>
> 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.
>
>
>
>
>
>
>  _______________________________________________
>
> rtcweb mailing list
>
> rtcweb@ietf.org
>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>