Re: [payload] VP8 payload, decoder processing capabilities

[Harald Alvestrand <[e-mail]>]

On 05/03/2012 07:14 AM, tom harper wrote:
> Has there been any follow up on this subject?  I have seen a great 
> deal of tangential discussion on the rtcweb list, but I am wondering 
> if that discussion changes what is done here?
>
> It seemed like there was some consensus on this list about including 
> max-mbps, max-fs, and max-fr type equivalents.  And possibly the 
> number of partitions used or equivalent?
>
> Regarding RFC 6236, it seems like so much of it is optional that it 
> could just cause more interoperability problems than it could solve- 
> but maybe I misinterpret the intent?  The syntax itself seems 
> promising as an alternative- was any final decision made about whether 
> it would work in this particular case?

The authors are working on an updated draft proposal. Real Soon Now!

>
> Thanks!
>
> Tom
>
>
>
> On 4/25/2012 9:26 AM, Sandy (Alexander) MacInnis wrote:
>> 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: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Olivier Crête
>> Sent: Tuesday, April 24, 2012 2:41 PM
>> To: [e-mail]
>> 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?)
>>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload