[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] spatial-resolution parameter for RFC 3984bis
Hi
Given the discussion below I really wonder if it is not a better alternative to specifiy preferred image sizes using a dedicated (generic) SDP attribute.
Even though this is solved in some way in 3984bis we still have to provide with a solution for MPEG-4 or H.263 later on.
I drafted a proposed solution for an "a=imageattr" attribute some time ago that may be useful
http://tools.ietf.org/id/draft-johansson-mmusic-image-attributes-01.txt
The draft provides with a solution that may work but lacks a requirement spec to outline exactly what the attribute aims for. Also extra work is needed to avoid conflicts with related payload format parameters.
Regards
Ingemar
=============================
To: <Ye-Kui.Wang at nokia.com>
Subject: Re: [AVT] spatial-resolution parameter for RFC 3984bis
From: Randell Jesup <rjesup at wgate.com>
Date: Mon, 14 Jul 2008 09:35:18 -0400
Cc: roni.even at polycom.co.il, avt at ietf.org
<Ye-Kui.Wang at nokia.com> writes:
>The resolution must be restricted by the level part of profile-level-id
>and max-fs. Therefore, if a configuration is agreed (or agreeable), then
>the answerer must request a resolution under the constraint, and the
>offerer must accept the request as long as it meets the restriction.
>This is similar as sprop-parameter-sets, as long as it is complaint with
>the agreed (or agreeable) configuration, the other side must accept it.
I would suggest instead (and did in the thread back in March): that as a
receiver property, it is the *preferred* maximum frame size. The receiver
is required to decode and handle any size up to the size implied by the
level (and max-fs if given), but the receiver prefers this size (for
example, it may support 1920x1080, but only have an LCD display that can
display 1200x720, so there's no *need* to send it anything higher (and the
encoder may prefer to avoid encoding more macroblocks, especially in an MCU
that shares resources)). In other cases, the sender may have the stream
already encoded in different resolutions, and this can help select the best
one to send to save encoding (and bandwidth) resources.
There is no requirement that the encoder scale, but if it wants to it
can.
It also (if I remember) provides aspect-ratio information.
>Would it work this way?
>
>BR, YK
>
>>-----Original Message-----
>>From: ext Even, Roni [mailto:roni.even at polycom.co.il]
>>Sent: 14 July, 2008 10:38
>>To: Wang Ye-Kui (Nokia-NRC/Tampere); avt at ietf.org
>>Subject: RE: [AVT] spatial-resolution parameter for RFC 3984bis
>>
>>YK,
>>Just to clarify,
>>The text on the receiver side says that this is the requested
>>resolution, it does not address issue of negotiation, what will the
>>sender do if it cannot send this resolution, should it reject the
>>stream?.
>>If this is for negotiation do you except to do a new offer
>>answer if the
>>receiver wants a new resolution?
>>
>>Roni
>>
>>> -----Original Message-----
>>> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
>>> Ye-Kui.Wang at nokia.com
>>> Sent: Sunday, July 13, 2008 7:57 PM
>>> To: avt at ietf.org
>>> Subject: [AVT] spatial-resolution parameter for RFC 3984bis
>>>
>>>
>>> Concluded from the discussions in the email threads listed below, I
>>> added a new parameter, spatial-resolution, to the RFC 3984bis draft
>>> (which will be submitted by tomorrow):
>>>
>>> http://www.ietf.org/mail-archive/web/avt/current/msg09425.html
>>> http://www.ietf.org/mail-archive/web/avt/current/msg09650.html
>>>
>>> The parameter is specified as follows (basically as Randell suggested
>>> in
>>> http://www.ietf.org/mail-archive/web/avt/current/msg09429.html).
>>>
>>> spatial-resolution:
>>> This parameter MAY be used to indicate the maximum spatial resolution
>>> of
>>> a NAL unit stream or the preferred spatial resolution of a receiver.
>>> The value is a base16 [6] (hexadecimal) representation of the width
>>and
>>> height of the spatial resolution, in pixels, separated by a comma.
>>>
>>> Usage in SDP offer/answer:
>>> - When "a=sendrecv" or no direction attribute is used,
>>> "spatial-resolution" indicates both the maximum spatial resolution of
>>> the stream sent by the declaring entity and the preferred spatial
>>> resolution for receiving a stream.
>>> - When "a=sendonly", "spatial-resolution" indicates the maximum
>>spatial
>>> resolution of the outgoing stream.
>>> - When "a=recvonly", "spatial-resolution" indicates the preferred
>>> spatial resolution for receiving a stream.
>>>
>>> Comments are welcome.
>>>
>>> BR, YK
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> avt at ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>
>_______________________________________________
>Audio/Video Transport Working Group
>avt at ietf.org
>https://www.ietf.org/mailman/listinfo/avt
--
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)
*******************************************
Ingemar Johansson
Senior Research Engineer, IETF "nethead"
EAB/TVP - Multimedia Technologies
Ericsson Research Ericsson AB
Box 920 S-971 28 Luleå, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
ECC: 850-43074
Mobile: +46 (0)730 783289
*******************************************
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt