Re: [AVT] [MMUSIC] spatial-resolution parameter for RFC 3984bis

[Randell Jesup <rjesup at wgate.com>]

"Ingemar Johansson S" <ingemar.s.johansson at ericsson.com> writes:
>So if I understand the H.264 part correctly the H.264 level-id parameter
>will provide with a upper limit to the maximum image size regardless of
>what is specified by imageattr, maxFS does infact specify something that
>relates to imageattr so here there may be a conflict.
>
>I believe that it makes sense to let "level-id in H.264" and "H.263 max
>resolution" be the limiting factor for imageattr as it will otherwise be
>too complex to incorporate hardware awareness into the attribute. 
>Under normal circumstances the offer will not specify an imageattr that
>goes beyond e.g the level-id but such cases may occur if one for
>instance specify the attribute in the SDPMedCapNeg framework.

My suggestion (again) is that codec-specific parameters limiting frame size
and frame rate are never overridden by imageattr.  So H.264 level (and
max-fs/max-mbps) specify the maximums allowed, and H.263 fmtp lines with
resolutions and MPIs specify which resolutions are allowed (perhaps
including CUSTOM).  The imageattr attribute is used to decide, within those
limits, what to *actually* send by exposing details of the receiver's
capabilities and preferences.  It extends and/or replaces the rough
preferences provided by the H.263 RFCs where order of declaration gave a
preference, for example.

Other issues:
>From the spec:
       a=imageattr:<PT> 1*WSP <sar=range 1*WSP> <list>
       list = set *(1*WSP set) ; defined in RFC 4566

       <PT> is the payload type number
       sar is the a set of supported sample aspect ratios (optional)

Can we allow "*" for payload type, like a=rtcp-fb does?  This could
be very handy to avoid an explosion of lines.

   A new "imageattr" attribute is defined.  The imageattr attribute
   contains a set of different image-resolution options that the offerer
   can provide.  The receiver can then select the desired image
   attribute (e.g image size) and has then the ability to avoid costly
   transformations (e.g rescaling) of the images.  In this approach only
   the image resolution and optionally the framerate, sample aspect
   ratio and preference is covered but the framework makes it possible
   to extend with other image related attributes that makes sense.

Um, a significant problem here.  There seems to be a requirement
that the negotiation is one-directional.  In this case, the offerer
provides NO indication about what he prefers to receive, just what he *can*
send.  When the answerer responds "picking" a resolution, what does the
answerer send?  The implication is that it's the same as what they picked
to receive, which may be seriously sub-optimal.

This appears to be handled by giving the "incomplete" offer of
a=imageattr:97 *
and having the answerer fill in the imageattr in the response.  This still
requires a symmetric session (identical resolutions, frame rates, etc).

The imageattr spec "solves" this by requiring use of two RTP sessions; one
in each direction.  In theory this works, but it's a painful way to solve
the problem, and many devices will not handle this formulation.  It's also
odd to force this, since you're not even required to use the same codecs in
the two directions, but here we're forcing two sessions just to support
different resolutions or framerates.

Even worse, the offerer has to "guess" if the negotiation will end up
asymmetric, and offer two sessions from the start.  The answerer can't
add sessions, let alone split them.  Plus this is relying on implicit
grouping; there's nothing specifying that both sessions are expected to
be active together - many will accept one and reject the other.

If you need separate "send" and "receive" formulations, then provide
them in one session.  Either:

a=imageattr-send:97 * (or list)
a=imageattr-receive:97 <list>

Or work send and receive into the syntax of imageattr directly (probably 
preferable).

a=imageattr:97 send * receive <list>
or
a=imageattr:97 send <list> receive <list>

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt