Re: [payload] VP8 payload, decoder processing capabilities

"Sandy (Alexander) MacInnis" <macinnis@broadcom.com> Wed, 25 April 2012 16:26 UTC

Return-Path: <macinnis@broadcom.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6547021F866D for <payload@ietfa.amsl.com>; Wed, 25 Apr 2012 09:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 8mFUWurDB++i for <payload@ietfa.amsl.com>; Wed, 25 Apr 2012 09:26:14 -0700 (PDT)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E621F8668 for <payload@ietf.org>; Wed, 25 Apr 2012 09:26:13 -0700 (PDT)
Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 25 Apr 2012 09:26:06 -0700
X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD
Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 25 Apr 2012 09:26:04 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 09:26:03 -0700
From: "Sandy (Alexander) MacInnis" <macinnis@broadcom.com>
To: "payload@ietf.org" <payload@ietf.org>, Olivier Crête <olivier.crete@collabora.com>
Thread-Topic: [payload] VP8 payload, decoder processing capabilities
Thread-Index: AQHNImGsXgcarpaDUUCO3CZpwEnVYZaq9nMAgADA/nA=
Date: Wed, 25 Apr 2012 16:26:02 +0000
Message-ID: <5B1A263B43E389479AB3DAC1EAF0C8F5025DC5@SJEXCHMB12.corp.ad.broadcom.com>
References: <4F87D9B1.4000206@alvestrand.no> <CBB1D76E.85DD1%stewe@stewe.org><4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C06D5FEF9@xmb-sjc-234.amer.cisco.com> <4F969A29.3040908@logitech.com> <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> <5B1A263B43E389479AB3DAC1EAF0C8F5024458@SJEXCHMB12.corp.ad.broadcom.com> <1335303658.1928.3.camel@TesterTop4>
In-Reply-To: <1335303658.1928.3.camel@TesterTop4>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.240.253.102]
MIME-Version: 1.0
X-WSS-ID: 6386FA143E023004907-01-01
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Subject: Re: [payload] VP8 payload, decoder processing capabilities
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 16:26:15 -0000

Thanks Olivier.

I was hoping to hear from someone at Google about this.

BTW, there might be a misunderstanding here. What I have in mind is that a sender would offer a stream indicating how many coefficient partitions that stream uses, along with the frame size and rate (or whatever alternative such as pixel rate or macroblock rate the group decides on). A receiver would be able to decide based on this information whether or not it can decode the stream. The receiver might need at least a certain number of coefficient partitions to be able to decode a stream with a certain frame size & rate. 

Note 1: This does not apply to all receivers, but it might apply to some. 

Note 2: If the stream has more coefficient partitions than the receiver needs, that's not a problem, but if it has too few, that could potentially be a problem. 

In this scenario it doesn't matter whether the receiver's capability are static or dynamic; all that matters is that the receiver knows what its capabilities are at the time it decides whether or not it can decode the stream. 

If the concern is that the receiver's capability might be reduced after it starts to decode the stream, that opens a bigger issue that I was not trying to address. However, I don't think that concern applies to the specific question of how many coefficient partitions the stream has. If the receiver either requires a certain number of coefficient partitions initially, or anticipates that due to dynamic behavior it might require them in the future, it can use that information to decide whether or not to accept the stream. On the other hand, if the receiver might in the future require a smaller frame size & rate stream after the stream has started, that's another matter altogether.

--Sandy (Alexander) MacInnis
Broadcom


-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Olivier Crête
Sent: Tuesday, April 24, 2012 2:41 PM
To: payload@ietf.org
Subject: Re: [payload] VP8 payload, decoder processing capabilities

On Tue, 2012-04-24 at 21:31 +0000, Sandy (Alexander) MacInnis wrote:
> I have another question about this.
> 
> Background:
> In the VP8 bitstream spec, and in the payload draft, the use of multiple coefficient partitions is optional and not required. 
> 
> A VP8 decoder might use multi-threaded processing, such that it can achieve significantly greater throughput by decoding multiple coefficient partitions in parallel. Such a decoder might rely on the presence of a certain number of coefficient partitions in order to achieve a certain level of throughput.
> 
> For example, some receiver might comprise a multi-threaded decoder that can decode 1920x1080p60 if the stream has at least four coefficient partitions, but if the stream has only one coefficient partition it might be limited to a significantly smaller product of frame size and frame rate.
> 
> Question: With the current draft, how does a multi-threaded decoder know in advance how many coefficient partitions the stream uses, so it can decide whether it can decode a stream of a given frame size and frame rate? Or does this aspect not matter?

I think the receiver should include all of that in its SDP, maybe
something like: SamplesPerCoefficientPartition=X
MaxParallelCoeffficientPartitions=Y

That said, I'm concerned that all of this is a really static view of
things, which is useful on a fixed device. But is completely pointless
when writing software that runs on a general purpose computer (such as a
desktop or a smartphone), in which case we want something more dynamic.
So maybe all of this discussion is mostly pointless and we should push
for a more dynamic solution (maybe some kind of RTCP feedback?)

-- 
Olivier Crête
olivier.crete@collabora.com