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:
>> 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.
>
>I believe I agree (even though the formulation in the draft may say
>different). A reasonable assumption is that the codec specific
>parameters are the limiting factor.

Good.

>> Can we allow "*" for payload type, like a=rtcp-fb does?  This 
>> could be very handy to avoid an explosion of lines.
>
>Didn't think of it but I see no problem in that esp. with the assumtion
>above that the codec specific parameters are the limiting factor.

I think that works well, since often the imageattr will specify the
physical resolution or optimum display resolution, plus some preferred
scaled (or unscaled) sizes, and these often will be codec-invariant.

>> 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>
>
>Actually this is one of the parts in the draft that I don't like and I
>planned to ask the group for suggestions how to improve the assymetric
>setup. Your alternative suggestions look attractive.

Thanks.

>One reason to why I initially picked the two RTP session alternative as
>one may anyway want to run different codecs in the two directions but as
>you said it may cause a lot of trouble.

You certainly can run different codecs in each direction, or the same codec
initially but switch codecs (or switch resolutions) on the fly with no
renegotiation, assuming the offer and answer allow for it.  imageattr
shouldn't restrict these possibilities.

-- 
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