Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions

[Harald Alvestrand <[e-mail]>]

On 04/19/2012 10:18 AM, Roni Even wrote:
> Hi Harald,
> The reason for the language was that this is really what the receiver wished
> to receive.
The strength of his wish may be the issue here....
>   The issue is that at least for H.264 there is no mandatory
> requirement for the encoder to support all resolutions within the supported
> level. The receiver must be able to crop and scale.
I couldn't parse that.

Does the sender have to (MUST) send a resolution within the boundaries 
of the "recv" spec, or can he send something outside it? (ie if the 
receiver sends recv [x=320,y=200], can the sender send something with 
x=320,y=240, or is he completely constrained?)

What does the receiver have to be able to do?

                    Harald
>
> Roni Even
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Harald Alvestrand
>> Sent: Thursday, April 19, 2012 10:47 AM
>> To: [e-mail]
>> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory
>> resolutions
>>
>> When discussing the issue of resolution negotiation locally, we found a
>> quandary:
>>
>> We have two different negotiation needs:
>> - Maximum resolution that's possible to use in a given context
>> - The preferred resolution for a given context
>>
>> The current imageattr= spec (RFC 6236) doesn't specify clearly whether
>> the result of the negotiation is to be considered mandatory or advisory
>> (it uses the term "wishes" a lot), but the description reads most
>> consistently if one assumes that it is a "MUST" type request.
>>
>> One interpretation is that the highest functionality available in the
>> spec is the "limit", while the highest q value is the "preference",
>> thus:
>>
>> recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1]
>>
>> would indicate that the receiver is capable of 200x160 to 1024x768, but
>> wants 320x200.
>>
>> This maps reasonably to the capabilities spec's talk about "mandatory"
>> vs "optional" capabilities.
>>
>> Does this interpretation make sense?
>>
>>                         Harald
>>
>>
>> On 04/12/2012 10:46 AM, Harald Alvestrand wrote:
>>> Hello folks,
>>>
>>> after the IETF, I've attempted to gather together information about
>>> resolution negotiation and what we might need to do there.
>>>
>>> I pulled together the paragraphs below - this may want to be
>>> incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go
>>> somewhere else. Chairs' guidance is appreciated.
>>>
>>> At the moment, I have it in xml2rfc format, so it should be easy to
>> do
>>> cut-and-paste on it, but don't want to push it as a separate I-D
>>> unless that's what the chairs desire.
>>> Note - there are some QUERY sections in there - I'm unsure what those
>>> should be resolved to.
>>>
>>> Comments?
>>>
>>>                           Harald
>>>
>>> 2.  Requirements
>>>
>>>     The relevant requirement for video resolution negotiation from the
>>>     RTCWEB use cases document
>>>     [I-D.ietf-rtcweb-use-cases-and-requirements] is:
>>>
>>>     o  F25 The browser SHOULD use encoding of streams suitable for the
>>>        current rendering (e.g. video display size) and SHOULD change
>>>        parameters if the rendering changes during the session.
>>>
>>>     The resulting need is:
>>>
>>>     o  To negotiate a maximum spatial resolution for all videos at
>> call
>>>        setup time
>>>
>>>     o  To negotiate a maximum temporal resolution ("frame rate")
>> across
>>>        all videos at call setup time
>>>
>>>     o  To indicate the desire of the recipient for a particular
>> spatial
>>>        or temporal resolution on a particular video source
>>>
>>>     o  To indicate the intent of the sender to send a video source in
>> a
>>>        particular spatial or temporal resolution
>>>
>>>     This document does not mention other requirements.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>