Re: [rtcweb] [payload] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution)
Harald Alvestrand <harald@alvestrand.no> Mon, 25 March 2013 19:12 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D921F8BA4 for <rtcweb@ietfa.amsl.com>; Mon, 25 Mar 2013 12:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.399
X-Spam-Level:
X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI+P0312u2ZG for <rtcweb@ietfa.amsl.com>; Mon, 25 Mar 2013 12:12:58 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1645721F8B45 for <rtcweb@ietf.org>; Mon, 25 Mar 2013 12:12:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3C0539E172 for <rtcweb@ietf.org>; Mon, 25 Mar 2013 20:12:48 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLQLYzY+ibQk for <rtcweb@ietf.org>; Mon, 25 Mar 2013 20:12:46 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:38db:202b:821e:982d] (unknown [IPv6:2001:470:de0a:27:38db:202b:821e:982d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EF0F539E13B for <rtcweb@ietf.org>; Mon, 25 Mar 2013 20:12:45 +0100 (CET)
Message-ID: <5150A1AC.6020602@alvestrand.no>
Date: Mon, 25 Mar 2013 20:12:44 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CBB1D76E.85DD1%stewe@stewe.org> <C5E08FE080ACFD4DAE31E4BDBF944EB1134339F8@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1134339F8@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] [payload] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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 Mar 2013 19:12:59 -0000
On 03/25/2013 03:53 PM, Cullen Jennings (fluffy) wrote: > I'd would find it very helpful to see the parameterization of Google hardware implementations. It been said that anyone can get the CHDL/Verilog for this but I can't get it. Looking at that would help understand what are limitations of at least one hardware implementation. I think that would shed a bunch of light on what might be needed. Cullen, I still haven't seen the note from you with a copy of the note from Aki that said what the issue is with you getting access to the hardware design stuff. The message you quote below is almost one year old, and we added two new parameters to the VP8 SDP declaration after that specifically to address Stefan's point, and included the following text: 6.2.2. Offer/Answer Considerations The VP8 codec offers a decode complexity that is roughly linear with the number of pixels encoded. In some practical applications, there will be a need for negotiating frame rate and resolution, provided by the OPTIONAL parameters "max-fs" and "max-fr", in addition to these parameters, many practical applications will need a mean to communicate the max bitrate. The SDP endpoints MAY negotiate a method to communicate the maximum media bitrate, such as TMMBR in [RFC5104], therefore VP8 does not add any new mechanisms for this negotiation. The parameter "max-fr" and "max-fs" are defined in Section 6.1, where the macroblock size is 16x16 pixels as defined in [RFC6386]. In many practical applications, the max frame size and max frame rate are known from other information; if they are not constrained by other means, the max-fs and max-fr parameters MUST be used to establish these limits. > > On Apr 16, 2012, at 14:40 , Stephan Wenger wrote: > >> Hi all, >> >> For context: Harald and myself have been at odds for a while now about the >> lack of support for a code point in the VP8 payload that can be used to >> negotiate a maximum decoder/bitstream complexity. Specifically, Harald >> (and other VP8 payload folks) suggested that generic mechanisms, such as >> the a=framerate attribute of RFC4566 in conjunction with the picture size >> aspect of the imageattr of RFC 6236 can be used, at least in the rtcweb >> context. However, as far as I understood our argument, these two >> mechanisms in combination are not meant as a limit for decoder complexity >> (in terms of samples/sec processing rate), but rather as an indication, >> from receiver to sender, of an upper bound of what is "useful to send". >> See the email below. To me, it's quite obvious that an indication of >> "useful to send" includes "my decoder can handle this"; however, it could >> be more restrictive in that factors other than decoder horsepower could >> also be at play, such as screen size, user interface settings, and so on. >> >> I believe that the combination of what can be signaled using the above >> mechanisms should be sufficient for rtcweb. However, I also believe that >> it is insufficient for general purpose use, mostly because it requires the >> support of RFC 6236, which is not exactly a widely deployed technology. >> Further, the a=framerate attribute is not a particularly useful attribute >> these days anymore, because variable frame rates, at least for software >> encoding/decoding, are the norm. >> >> In previous posts on the payload list (in response to the VP8 payload >> WGLC), I have commented on the practical shortcomings of the (lack of) >> complexity negotiation, and suggested that this needs to be fixed. >> >> Two options: >> >> 1) codify Harald's mechanism (based on a=framerate and imageattr in the >> VP8 payload draft, at MUST strength. "In a declarative context, a >> prospective media sender supporting this (VP8 payload) specification MUST >> support RFC 4566 a=framerate and RFC6236 imageattr, and MUST include code >> points according to both mechanisms to identify the properties of the >> media stream. In an offer-answer context, both offerer and answerer >> receiver supporting this VP8 payload specification MUST support >> a=framertate and imageattr, and MUST include both in their respective >> offer/answer messages, so to identify an operation point that will not >> overload the media decoder's capabilities. >> >> The issue with this approach, IMO, is that we are dealing here with three >> individual code points (framerate, horizontal and vertical picture size), >> where a single code point ought to be sufficient for determining whether a >> décor is capable of decoding a stream, at least from a complexity >> viewpoint). >> >> 2) include, in the V8 payload, a negotiable SDP code point indicating the >> complexity of a stream, in units of samples per second processing >> requirements or a derivative thereof (such as: levels as used in the MPEG >> world). For example, the VP8 payload could include a single, optional, >> negotiable parameter "SamplePerSecond". If SamplePerSecond were absent in >> the SDP, a value of xxxxx must be inferred. (a sensible value for xxxxx >> could be, for example 9216000, which is the number of samples per second >> for VGA resolution at 30 Hz). If SamplePerSecond is present in a >> declarative context, it indicates the minimum processing requirements a >> decoder must support in order to successfully decode the stream. In a >> symmetric offer-answer context, SamplePerSecond can be used to "dial down" >> the complexity of the stream to a value that both encoder and decoder can >> support. >> >> My preference is obviously the second proposal, but I'm willing to help >> fleshing out either or both of them, just not today :-) >> >> Regards, >> Stephan >> >> >> >> On 4.13.2012 00:45 , "Harald Alvestrand" <harald@alvestrand.no> wrote: >> >>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: >>>> On 4.12.2012 12:08 , "Harald Alvestrand"<harald@alvestrand.no> wrote: >>>> >>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>>>> Hi Harald, >>>>>> Thanks for this strawman. I believe it should work, but I fail to see >>>>>> how >>>>>> a two dimensional negotiation requirement (negotiating max values for >>>>>> framerate and image size--which, in turn, also has two-dimensional >>>>>> properties) leads to better interop than a one dimensional negotiation >>>>>> (pixels per second processing requirement). >>>>> Stephan, >>>>> >>>>> I do not see this (or the requirement from the use-cases document) >>>>> first >>>>> and foremost a decoder complexity negotiation; it is a negotiation of >>>>> how much data it is useful to send, given the recipient's intended use >>>>> of that data. >>>> Then such a negotiation should be executed in addition. Decoder cycle >>>> requirement do matter in practical implementations. >>> Feel free to propose language that captures this requirement. As noted, >>> my I-D fragment doesn't. >>> >>> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Resolution negotiation - a contribution Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Timothy B. Terriberry
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Marshall Eubanks
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- [rtcweb] VP8 payload, decoder processing capabili… Stephan Wenger
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Yuepeiyu (Roy)
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- [rtcweb] Alternative Proposal for Dynamic Codec P… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Timothy B. Terriberry
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Bernard Aboba
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Cullen Jennings (fluffy)
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Harald Alvestrand