Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 9 Sep 2008 08:15:49 +0200

Hi

Please see question below

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 08 Sep 2008 01:12:23 -0400
> From: Randell Jesup <[email-masked]>
> Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id
> To: <[email-masked]>
> Cc: [email-masked], [email-masked],
> 	[email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> 
> <[email-masked]> writes:
> >Just to point out that, in Dublin, the following changes in 
> >draft-wang-avt-rfc3984bis-01.txt and summarized in the 
> present slides 
> >were all agreed. That does not necessarily mean we cannot further 
> >change these, but it seems to me that the discussions in this thread 
> >are not based on the latest status.
> >
> >- Level downgrade: If a level is offered, any lower level of 
> the same 
> >profile is automatically offered, including level 1b.
> 
> Ok, that means that the "constraints" section can change (but 
> only in one very specific case).  No other constraint changes 
> are allowed.
> 
> >- Removed the restriction that sprop-parameter_sets in an SDP answer 
> >shall be equal or a superset of that in the offer.
> >-- It seems to be a clear mistake in RFC 3984, because the 
> restriction 
> >seriously limits separate encoding optimizations in the two 
> sides, and 
> >it basically disallows level downgrade
> 
> This is factually incorrect, though I agree with the 
> sentiment.  Just because the answer has to be a superset of 
> the offer doesn't in any way limit encoding optimizations.  
> The answer can add whatever parameter sets it wants (within 
> the profile-level-id constraints), then use those when 
> encoding.  Just because the answer has parameter sets copied 
> from the offer doesn't affect this.

Just a question with reference to the image attribute work in MMUSIC. If I understand the above correctly it should be possible for the offerer to specify a parameter set that says 352x288 resolution while the answerer can give a parameter set that says 400x300 as long as it is supported by the profile level id. Is this correct.

/Ingemar
******************************************* 
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
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 10:10:01 +0300

Ingemar,

>Just a question with reference to the image attribute work in 
>MMUSIC. If I understand the above correctly it should be 
>possible for the offerer to specify a parameter set that says 
>352x288 resolution while the answerer can give a parameter set 
>that says 400x300 as long as it is supported by the profile 
>level id. Is this correct.

This is correct in my understanding, after the removal of the sprop-spatial-resolution parameter, which was supposed to be used for negotiation of an image resolution, but left to be done by using your imageattr. In this case, if the offer/answer stops at here (i.e. no second offer/answer round), then the offerer will send a bitstream with a spatial resolution of 352x288, while the answerer will send a bitstream with a spatial resolution of 400x300. This is certainly not nice - that's why it would be nice to have something like imageattr and sprop-spatial-resolution. 

BR, YK 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Ingemar Johansson S
>Sent: 09 September, 2008 09:16
>To: [email-masked]
>Cc: [email-masked]
>Just a question with reference to the image attribute work in 
>MMUSIC. If I understand the above correctly it should be 
>possible for the offerer to specify a parameter set that says 
>352x288 resolution while the answerer can give a parameter set 
>that says 400x300 as long as it is supported by the profile 
>level id. Is this correct.
>
>/Ingemar

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 10:16:00 +0300

Another solution, with the absence of imageattr and sprop-spatial-resolution, is to partially restrict sprop-parameter-sets, by saying that the spatial resolution indicated by any sequence parameter set included in an answer MUST be identical to that indicated by any sequence parameter set included in the offer (which also means all sequence parameter sets included in an offer or an answer MUST indicate the same spatial resolution).

BR, YK

>From: Wang Ye-Kui (Nokia-NRC/Tampere) 
>Sent: 09 September, 2008 10:10
>To: 'ext Ingemar Johansson S'; [email-masked]
>Subject: RE: [AVT] SDP Negotiation based on Profile-Level-Id
>
>
>Ingemar,
>
>This is correct in my understanding, after the removal of the 
>sprop-spatial-resolution parameter, which was supposed to be 
>used for negotiation of an image resolution, but left to be 
>done by using your imageattr. In this case, if the 
>offer/answer stops at here (i.e. no second offer/answer 
>round), then the offerer will send a bitstream with a spatial 
>resolution of 352x288, while the answerer will send a 
>bitstream with a spatial resolution of 400x300. This is 
>certainly not nice - that's why it would be nice to have 
>something like imageattr and sprop-spatial-resolution. 
>
>BR, YK 
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Sep 2008 10:41:59 +0300

YK,

Just to be more precise, the offerer MAY send 352x288 but can send other
resolutions as long as it sends the parameters sets used (within the level
constrains) before sending the actual picture. This may be by a new
sprop-parameter-set or by sending them in-band.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, September 09, 2008 10:10 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [AVT] SDP Negotiation based on Profile-Level-Id

Ingemar,

This is correct in my understanding, after the removal of the
sprop-spatial-resolution parameter, which was supposed to be used for
negotiation of an image resolution, but left to be done by using your
imageattr. In this case, if the offer/answer stops at here (i.e. no second
offer/answer round), then the offerer will send a bitstream with a spatial
resolution of 352x288, while the answerer will send a bitstream with a
spatial resolution of 400x300. This is certainly not nice - that's why it
would be nice to have something like imageattr and sprop-spatial-resolution.

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Sep 2008 10:46:10 +0300

YK,
I am not sure that this will work in all tolpologies. If I understand your
suggestion it will mean that the parameter sets will have to have unique
numbers coming from different sources.
Roni

-----Original Message-----
Sent: Tuesday, September 09, 2008 10:16 AM

Another solution, with the absence of imageattr and
sprop-spatial-resolution, is to partially restrict sprop-parameter-sets, by
saying that the spatial resolution indicated by any sequence parameter set
included in an answer MUST be identical to that indicated by any sequence
parameter set included in the offer (which also means all sequence parameter
sets included in an offer or an answer MUST indicate the same spatial
resolution).

BR, YK

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 10:58:39 +0300

Roni,

As we know, out-of-band transmission has problem (or say does not work) for topologies like multipart conferencing with MCU switching video source during the session, unless unique parameter set IDs are allocated for each source (i.e. all the sources share the same value space of sequence or picture parameter set ID) or in-band transport of parameter sets are used. For other topologies like point-to-point, parameter sets from different sources can have different and indpendent value spaces of sequence or picture parameter set ID. If the restriction I suggested below is adopted, then the same spatial resolution shall be used for sending and receiving by both the offerer and the answerer, which is nice as I understand. If a UA is allowed to change spatial resolution during a session, it would be bad for a receiver for which the decoder is initialized according to the initial spatial resolution. 

BR, YK 

>From: ext Roni Even [mailto:[email-masked]] 
>Sent: 09 September, 2008 10:46
>To: Wang Ye-Kui (Nokia-NRC/Tampere); 
>[email-masked]; [email-masked]

---

From: Alex Eleftheriadis <[email-masked]>
Date: Tue, 9 Sep 2008 11:08:23 +0300

I have not followed this particular thread closely (yet), but I want  
to emphasize that it MUST be allowed for the sender and receiver to be  
sending video at different resolutions. In a DSL videoconferencing  
environment, HD downstream with a lower resolution upstream (qHD or  
lower, depending on available bit rate) is both typical and good.

Apologies if I misunderstood the setting of the argument.

--Alex

On Sep 9, 2008, at 10:58 AM, <[email-masked]> wrote:

>
> Roni,
>
> As we know, out-of-band transmission has problem (or say does not  
> work) for topologies like multipart conferencing with MCU switching  
> video source during the session, unless unique parameter set IDs are  
> allocated for each source (i.e. all the sources share the same value  
> space of sequence or picture parameter set ID) or in-band transport  
> of parameter sets are used. For other topologies like point-to- 
> point, parameter sets from different sources can have different and  
> indpendent value spaces of sequence or picture parameter set ID. If  
> the restriction I suggested below is adopted, then the same spatial  
> resolution shall be used for sending and receiving by both the  
> offerer and the answerer, which is nice as I understand. If a UA is  
> allowed to change spatial resolution during a session, it would be  
> bad for a receiver for which the decoder is initialized according to  
> the initial spatial resolution.
>
> BR, YK
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Sep 2008 11:12:46 +0300

YK,
I am not sure I understand, are you suggesting that if the stream starts as
CIF resolution by the offerer then the answerer must send CIF and it should
stay CIF all the time, never change? 
Spatial resolution is symmetric and fixed?

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2008 10:59 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [AVT] SDP Negotiation based on Profile-Level-Id

Roni,

As we know, out-of-band transmission has problem (or say does not work) for
topologies like multipart conferencing with MCU switching video source
during the session, unless unique parameter set IDs are allocated for each
source (i.e. all the sources share the same value space of sequence or
picture parameter set ID) or in-band transport of parameter sets are used.
For other topologies like point-to-point, parameter sets from different
sources can have different and indpendent value spaces of sequence or
picture parameter set ID. If the restriction I suggested below is adopted,
then the same spatial resolution shall be used for sending and receiving by
both the offerer and the answerer, which is nice as I understand. If a UA is
allowed to change spatial resolution during a session, it would be bad for a
receiver for which the decoder is initialized according to the initial
spatial resolution. 

BR, YK

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 11:26:08 +0300

Very good point, Alex. In that case, you may use separate SDP with sendonly and recvonly direction attributes - this also allows sending and receiving at different values of level. The question is then whether negotiation of such asymmetric configuration must also be enabled using sendrecv, which may complicate things or allow some unexpected behavior (e.g. changing of spatial resolution during a session). 

BR, YK 

>From: ext Alex Eleftheriadis [mailto:[email-masked]] 
>Sent: 09 September, 2008 11:08
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>Behalf Of

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 11:27:52 +0300

Roni,

As seen from another email replying Alex, my understanding is that spatial resolution should be fixed, but may be asymmetric for sending and receiving. What's your opinion?

BR, YK 

>Sent: 09 September, 2008 11:13

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Sep 2008 13:12:54 +0300

YK,
This is not what Alex describes or what I would like to see. The idea is
that each side may be able to request a specific resolution or send a
different resolution using the same payload type and change it in the middle
of the call without using two m-lines like your suggestion. Symmetry is not
a MUST maybe we can add a Symmetry parameter explaining the use case.

To add to Alex example: In multipoint when the MCU composes pictures it
would like to get a lower resolution from the senders and build a mixed
higher resolution picture to send to the receivers.
In a point to point a receiver with a non HD display and HD camera may
prefer to receive low resolution picture to reduce the need for decoding and
scaling while sending an HD picture to the other side that has an HD display
and is capable of decoding such image

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2008 11:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [AVT] SDP Negotiation based on Profile-Level-Id

Very good point, Alex. In that case, you may use separate SDP with sendonly
and recvonly direction attributes - this also allows sending and receiving
at different values of level. The question is then whether negotiation of
such asymmetric configuration must also be enabled using sendrecv, which may
complicate things or allow some unexpected behavior (e.g. changing of
spatial resolution during a session). 

BR, YK

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 13:27:59 +0300

Roni,

OK, so you want spatial resolution to be changeable during a session. One think I don't know is that, in the use case you mentioned, how does the MCU request a lower resolution from the receiver?

BR, YK 

>Sent: 09 September, 2008 13:13
>To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
>Cc: [email-masked]; [email-masked];

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Sep 2008 13:39:11 +0300

YK,
This is the new mode request in H.241 and I think that maybe Tom should look
at how to address it.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2008 1:28 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];

Roni,

OK, so you want spatial resolution to be changeable during a session. One
think I don't know is that, in the use case you mentioned, how does the MCU
request a lower resolution from the receiver?

BR, YK

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Sep 2008 11:35:58 -0400

>sprop-spatial-resolution.  

In fact it's not only nice to have asynchronous resolutions, it's really
useful in practice.  For example, endpoints calling into an MCU can send
QCIF or CIF, and the MCU can composite the different video sources and send
CIF or 4CIF or HD to the endpoints.  (All assuming that those are within
the agreed-to level.)  Much more efficient than identical resolutions.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"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)