[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] [MMUSIC] 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
> >regardlessFrom avt-bounces at ietf.org Thu Jul 31 01:51:04 2008
Return-Path: <avt-bounces at ietf.org>
X-Original-To: avt-archive at optimus.ietf.org
Delivered-To: ietfarch-avt-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id ACF0E3A6A2B;
Thu, 31 Jul 2008 01:51:03 -0700 (PDT)
X-Original-To: avt at core3.amsl.com
Delivered-To: avt at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 3BF1B3A68AE;
Thu, 31 Jul 2008 01:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.064
X-Spam-Level:
X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.185,
BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fqZZL2zopuYR; Thu, 31 Jul 2008 01:50:51 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id DA3563A68E0;
Thu, 31 Jul 2008 01:50:50 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
5E72B2156F; Thu, 31 Jul 2008 10:50:18 +0200 (CEST)
X-AuditID: c1b4fb3e-ae198bb000004ec0-e8-48917ccaec2d
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
336DE216D1; Thu, 31 Jul 2008 10:50:18 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 31 Jul 2008 10:50:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 10:50:16 +0200
Message-ID: <026F8EEDAD2C4342A993203088C1FC0507FB8057 at esealmw109.eemea.ericsson.se>
In-Reply-To: <ybuod4fp5vr.fsf at jesup.eng.wgate.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] [AVT] spatial-resolution parameter for RFC 3984bis
thread-index: AcjydFKMvdkGtCoZTR+Hp6I0fMe5IQAcMSog
References: <0K4S00DD1L1O0B at ms7.samsung.com><026F8EEDAD2C4342A993203088C1FC0507FB7C46 at esealmw109.eemea.ericsson.se><144ED8561CE90C41A3E5908EDECE315C05D2B6EB at IsrExch01.israel.polycom.com><026F8EEDAD2C4342A993203088C1FC0507FB7E96 at esealmw109.eemea.ericsson.se>
<ybuod4fp5vr.fsf at jesup.eng.wgate.com>
From: "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>
To: "Randell Jesup" <rjesup at wgate.com>
X-OriginalArrivalTime: 31 Jul 2008 08:50:17.0873 (UTC)
FILETIME=[74F7E010:01C8F2EA]
X-Brightmail-Tracker: AAAAAA==
Cc: Ye-Kui.Wang at nokia.com, "Even, Roni" <roni.even at polycom.co.il>,
kyunghun.jung at samsung.com, avt at ietf.org, mmusic at ietf.org
Subject: Re: [AVT] [MMUSIC] spatial-resolution parameter for RFC 3984bis
X-BeenThere: avt at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/avt>
List-Post: <mailto:avt at ietf.org>
List-Help: <mailto:avt-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces at ietf.org
Errors-To: avt-bounces at ietf.org
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 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 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)
> 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)
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt
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)
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt