Re: [AVT] imageattr and codec parameter sets (with embedded image size info)

[Randell Jesup <rjesup at wgate.com>]

Kyunghun Jung <kyunghun.jung at samsung.com> writes:
>The draft of imageattr currently does not introduce the codec parameter
>set issues, which also have image size information.
>
>For example, sprop-parameter-sets contains pic_width_in_mbs_minus1 and
>pic_height_in_map_units_minus_1.
>
>Let me summarize.
>
> - profile and level specify the maximum image size
>
> - imageattr specify the image sizes available from sender
>
> - config/sprop-parameters-sets specify the image size to be encoded
>(but not considered in session setup)

Note: if it's a specific, small list of resolutions, the imageattr values
an offerer is willing to send can all be included in the list of parameter
sets in the fmtp.

If the range of selected sizes is large or unspecified ("*") in the offer,
either a second offer/answer will be required, or in-band parameter set
transmission, or both.  See discussions of RFC 3984bis on this list
recently.

>Therefore I asked your opinions on the forming of SDP offer and suggested
>three (crudely drafted) examples of
>
>imageattr coupled with config/sprop-parameter-sets. In fact, one form
>showed a possibility that covers multiple levels.
>
>If imageattr is limited to a level, then the following form might be
>necessary to match the sizes in imageattr with three
>
>sets of config with different image size. My question was whether this
>form could be acceptable?
>
>
>
>  a=imageattr:99 [x=x1,y=y1] [x=x2,y=y2] [x=x3,y=y3]
>
>  a=fmtp:99 profile-level-id=8
>
>  a=fmtp:99  config=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_1
>
>  a=fmtp:99  config=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_2
>
>  a=fmtp:99  config=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_3

If payload 99 is H264, then this is invalid - only a single fmtp line
is allowed, and all the parameter sets are specified as a single
sprop-parameter-sets entry in the fmtp line.

>Or do we need to send config after the image size is decided? This will
>increase the session setup delay.

If the list of resolutions is large, then a second offer/answer or in-band
transmission (which is subject to loss) will be needed.  One option is to
start with in-band transmission (with some duplicates, since parameter sets
are normally short and can be merged with other NALs using STAP packets),
while at the same time starting a second offer/answer to provide guaranteed
reception.  There is no "I need the parameter set" codec-control message in
rtcp-fb, just FIR (requesting IDR, and commonly used to recover from packet
loss) and NACK, etc, so there's no easy way for the receiver to ask for the
parameter sets to be resent if they're lost.

>Let me answer a question from Mr. Randell Jesup.
>
>>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.
>
>-> q value, as in Example 3 of the draft, will offer the priority among
>offered sizes.

You didn't understand my comment.  My issue is with the requirement in the
current draft to use the same resolution in both directions for a given m=
line (RTP session).

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