Re: [rtcweb] Resolution negotiation - a contribution

[Stephan Wenger <[e-mail]>]

Hi Harald,
Thanks for this strawman.  I believe it should work, but I fail to see how
a two dimensional negotiation requirement (negotiating max values for
framerate and image size--which, in turn, also has two-dimensional
properties) leads to better interop than a one dimensional negotiation
(pixels per second processing requirement).  Let alone a one dimensional
negotiation with a fragmented value space and constraints imposed an
maxima and minima for both resolution and frame rates to values that
represent common operation points (such as MPEG-style levels).  Actually,
I fail to see ANY positive aspect, except perhaps that dimension/framerate
may be a bit more intuitive than processing power demands.  This goes for
both the API and the protocol.
One can argue a lot about the value of MPEG's profiles in today's software
implementation world (and people do, myself included).  But the level
concept appears to make sense to me.
As a side note, something along the lines of CLUE's simultaneous
transmission sets concept (or however that thing is currently called; I
lost track) would also be beneficial for a system that is inherently
capable of displaying multiple video signals, such as  a web browser.
Regards,
Stephan


On 4.12.2012 01:46 , "Harald Alvestrand" <[e-mail]> 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.
>
>
>3.  SDP negotiation of video resolution
>
>    An RTCWEB client MUST support negotiation of resolution using the
>    "imageattr" attribute, as documented in [RFC6236].
>
>    An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and
>    MAY choose to support only the 1.0 value of the "sar" attribute.
>
>    The interpretation of the negotiation is that any video stream in the
>    m= line containing the a=imageattr attribute will have a resolution
>    within the bounds established by the negotiation.
>
>    An RTCWEB client MUST support negotiation of the "a=framerate"
>    attribute, as specified in [RFC4566] section 6.  Note that this is an
>    upper bound on framerate; there is no lower bound negotiated.
>
>    These requirements are necessary and sufficient for establishing the
>    maximum spatial and temporal resolution for all videos at call setup
>    time.  These bounds MAY be renegotiated over the course of the call,
>    but MUST NOT be renegotiated to render any currently transmitted
>    video stream out of bounds; the sending video stream MUST first be
>    changed to be of a resolution that fits within both the old and the
>    new bounds, or halted. <<QUERY: Is this necessary or sufficient
>    restriction???>>
>
>    An RTCWEB client MUST support per-SSRC requests for video
>    resolutions, as described in
>    [I-D.lennox-mmusic-sdp-source-selection].  This satisfies the
>    requirement to indicate the desire of the recipient for a particular
>    spatial or temporal resolution.
>
>    We assume that the media sent from a sender to a receiver contains
>    enough information inside the media format to tell what the
>    resolution and framerate is. <<QUERY: Do we need to extend RFC 5576
>    with an "imageattr" or "framerate" attribute in the forward direction
>    instead?>>
>
>
>4.  Non-SDP negotiation of video resolution
>
>    An RTCWEB client MAY support the COP mechanism
>    [I-D.westerlund-avtext-codec-operation-point] to negotiate the
>    resolution of video within the limits established by the SDP
>    negotiation without the need for additional SDP exchanges.
>
>
>5.  Relation to WebRTC API constraint
>
>    It is intended that the resolution negotiation be influenced by the
>    constraints set by the application of either mandatory or optional
>    constraints at the WebRTC API, as registered in the registry
>    established by [I-D.burnett-rtcweb-constraints-registry].
>
>    The following relationships hold for all attributes that the
>    implementation intends to satisfy (note that the constraints listed
>    here have NOT been registered yet):
>
>    video-min-height >= value of imageattr y= xyrange lower bound
>
>    video-max-height <= value of imageattr y= xyrange upper bound
>
>    video-min-framerate is not represented in SDP
>
>    video-max-framerate <= value of a=framerate attribute
>
>    video-min-aspect-ratio <= value of imageattr "par=" prange lower
>    bound
>
>    video-max-aspect-ratio >= value of imageattr "par=" prange upper
>    bound
>
>    The implementation is free to increase "min" values or decrease "max"
>    values (make requirements more restrictive) and add "step" in order
>    to fit with its implementation restrictions. <<NOTE - check the value
>    of the direction of those assumptions>>.
>
>    Constraints specified at PeerConnection creation time are reflected
>    as SDP-wide values.  Constraints specified when creating a
>    MediaStream or attaching a MediaStream to a PeerConnection are
>    reflected as ssrc-specific values.
>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>