[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] [AVT] spatial-resolution parameter for RFC 3984bis
Hi
Thanks for the comments, my cmments inline below.
/Ingemar
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: den 30 juli 2008 19:46
> To: Ingemar Johansson S
> Cc: Even, Roni; kyunghun.jung at samsung.com; mmusic at ietf.org;
> Ye-Kui.Wang at nokia.com; avt at ietf.org
> Subject: Re: [MMUSIC] [AVT] spatial-resolution parameter for
> RFC 3984bis
>
> "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.
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.
>
> 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.
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.
>
> 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>
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.
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.
>
> --
> 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)
>
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic