[rtcweb] VP8 and parameters (Re: Signalling, SDP, and the way we think about interconnecting RTCWEB applications)

[Harald Alvestrand <[e-mail]>]

On 10/15/2011 05:42 PM, Stephan Wenger wrote:
> Hi Harald,
>
> On 10.15.2011 07:29 , "Harald Alvestrand"<[e-mail]>  wrote:
>
>> Given the last point - the app *cannot* "implicitly" what codec will be
>> used. And given that it doesn't know the codec, it can't know the
>> parameters either.
>>
>> (that said... I'm all in favour of fewer parameters. The RTP format for
>> VP8 that we're in the process of finishing has zero parameters. I hope
>> it will remain that way.)
> I would be surprised if that were the case.  As the very minimum, I would
> suspect that you need some form of upper bound for computational decoder
> complexity (measured in pixel numbers per second, framerate/picture size
> combination, or whatever).  It doest make sense that two systems agree on
> VP8, and the receiver cannot rdecode the sender's bitstream because the
> receiver is a cheap cellphone and the sender is a desktop PC which likes
> to send 1080p.  Let me also note that the VP8 payload spec (at least the
> current public version) has a number of "optional" mechanisms, which you
> would want to negotiate, no?
(changing the subject again)
This is a discussion more relevant for the payload wg....

As far as I understand the current spec, the features are optional in 
the sense that the sender can choose to use them or not; the recipient 
has to be able to decode the stream, no matter what features are used.

We've got generic features in SDP to negotiate bitrate, resolution and 
some other parameters in a codec-independent fashion, and the RTP/AVPF 
profile has things like TMMBR to tamp down the sending rate even more; 
we'll see if those prove adequate to protect low-powered recipients from 
high-powered senders.

If not, I guess the specs will have to grow.