Draft: draft-ietf-rtcweb-jsep

Commentary: Discusses multiple imageattr ; use of different codecs ; no aspect ratio handling ; preserve aspect ratio when scaling 
 LGTM 
 LGTM
Paragraph (version A):
This specification prescribes more specific behavior.  When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so.  Note that when
considering a MediaStreamTrack that is producing rotated video, the
unrotated resolution MUST be used.  This is required regardless of
whether the receiver supports performing receive-side rotation (e.g.,
through CVO), as it significantly simplifies the matching logic.
Paragraph (version A):
If the original resolution is too large for the attribute criteria,
the sender SHOULD apply downscaling to the output of the
MediaStreamTrack in order to satisfy the criteria.
Paragraph (version A):
If the receiver requires a minimum resolution which is greater than
the native resolution of the video, upscaling is needed, but this may
not be appropriate in all cases.  To address this concern, the
application can set an upscaling policy for each sent track.  For
this case, if upscaling is permitted by policy, the sender SHOULD
apply upscaling in order to provide the desired resolution.
Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD
NOT upscale in other cases, even if the policy permits it.
Paragraph (version A):
If there is no appropriate and permitted scaling mechanism that
allows the received criteria to be satisfied, the sender MUST NOT
transmit the track.
Paragraph (version B):
This specification prescribes more specific behavior.  When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST check
to see if the original resolution meets the size criteria specified
in the attribute, and adapt the resolution accordingly by scaling (if
appropriate).  Note that when considering a MediaStreamTrack that is
producing rotated video, the unrotated resolution MUST be used.  This
is required regardless of whether the receiver supports performing
receive-side rotation (e.g., through CVO), as it significantly
simplifies the matching logic.
Paragraph (version B):
For an "a=imageattr recv" attribute, only size limits are considered.
Any other values, e.g. aspect ratio, MUST be ignored.
Paragraph (version B):
When communicating with a non-JSEP endpoint, multiple relevant
"a=imageattr recv" attributes may be received.  If this occurs,
attributes other than the one with the highest "q=" value MUST be
ignored.
Paragraph (version B):
If an "a=imageattr recv" attribute references a different video codec
than what has been selected for the MediaStreamTrack, it MUST be
ignored.
Paragraph (version B):
If the original resolution matches the size limits in the attribute,
the track MUST be transmitted untouched.
Paragraph (version B):
If the original resolution exceeds the size limits in the attribute,
the sender SHOULD apply downscaling to the output of the
MediaStreamTrack in order to satisfy the limits.  Downscaling MUST
NOT change the track aspect ratio.
Paragraph (version B):
If the original resolution is less than the size limits in the
attribute, upscaling is needed, but this may not be appropriate in
all cases.  To address this concern, the application can set an
upscaling policy for each sent track.  For this case, if upscaling is
permitted by policy, the sender SHOULD apply upscaling in order to
provide the desired resolution.  Otherwise, the sender MUST NOT apply
upscaling.  The sender SHOULD NOT upscale in other cases, even if the
policy permits it.  Upscaling MUST NOT change the track aspect ratio.
Paragraph (version B):
If there is no appropriate and permitted scaling mechanism that
allows the received size limits to be satisfied, the sender MUST NOT
transmit the track.