Subject: [MMUSIC] draft-johansson-mmusic-image-attributes

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 26 Jun 2008 16:52:17 +0200

Hi

The image attribute draft has been updated to version -01 with some major changes.
+ Support for Sample Aspect Ratios (SAR)
+ Offer/answer for asymmetric display capabilities
+ Picture aspect Ratio range to limit the number of x and y resolution options

Comments are welcome
/Ingemar

======================================
Filename:	 draft-johansson-mmusic-image-attributes
Revision:	 01
Title:		 Negotiation of Generic Image Attributes in SDP
Creation_date:	 2008-06-26
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This draft proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size.
A possible use case is to make it possible for a e.g a low-end hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power.  The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted.                                
http://tools.ietf.org/id/draft-johansson-mmusic-image-attributes-01.txt

======================================
******************************************* 
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 
******************************************* 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Jun 2008 20:00:25 +0100

Hi,

The draft lists several issues in section 5. There are also possible  
feature interactions with the "a=framerate:", "a=quality:" and  
"a=orient:" attributes in RFC 4566. And, RFC 4175 also defines width  
and height parameters which may conflict. I doubt any of these are  
major issues, but the interactions need to be specified.

Cheers,
Colin

On 26 Jun 2008, at 15:52, Ingemar Johansson S wrote:
> This draft proposes a new generic session setup attribute to make  
> it possible to negotiate different image attributes such as image  
> size.
> A possible use case is to make it possible for a e.g a low-end  
> hand- held terminal to display video without the need to rescale  
> the image, something that may consume large amounts of memory and  
> processing power.  The draft also helps to maintain an optimal  
> bitrate for video as only the image size that is desired by the  
> receiver is transmitted.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 30 Jun 2008 09:44:51 +0300

Hi,
I think Colin makes good point and would like to add that bullet 1 in section 5 may cause a interoperability problem if the answerer supports only the sprop parameter. My suggestion is to specify that if image att is supported than the sprop parameter will be ignored.

I also want to add that image size are also specified in other payload formats and not only in H.264.

The justification for image size is for supporting screen size and low compute and that is why the image attribute by itself is not giving a full answer. Low compute can be achieved by specifying the relation between frame rate and size like in H.263 and H.261 payload specifications or by having a max macro blocks per second associated like in H.264 which applies that same limitation as the frame rate per resolution in H.263/H.261. 
By specifying the maximum image size and the maximum Macro Blocks per second you can allow slower frame rate at the maximum resolution and higher frame rate at lower resolution.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Colin Perkins
> Sent: Sunday, June 29, 2008 10:00 PM
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [MMUSIC] draft-johansson-mmusic-image-attributes
> 
> Hi,
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 30 Jun 2008 11:36:34 +0200

Hi

Thanks for the comments. I agree that the parameters mentioned below and how they interact with imageattr must be included in a later version of the draft. 
A short analysis:

RFC4566:
a=framerate: 
  According to RFC4566 this specifies the maximum framerate. a=imageattr supports to specify a framerate range for each set. Difference here (for normal sendrevc setup) is that framerate specifies what the offerer wish to receive while imageattr specifies what the offerer can support to send. 

a=quality: 
  Gives an opportunity to do a tradeoff between high framerate with poor image quality and low frame rate with high still image quality. Although the "fr=" parameter exist in imageattr I don't believe that the two aim at the same solution, still the two may conflict.

a=orient:
  Can be specified as portait, landscape and seascape. imageattr can support portrait or landscape by means of the x and y ranges + the par range. Here again the direction of the attributes is opposite. In order to support both landscape and portrait image attr must include both alternatives. seascape is not supported, what is the actual use case for this ?

RFC4175:
a=width and a=height:
  In this particular case I doubth that imageattr has anything to contribute with as the negotiation of desired image size is already in place.

Regards
Ingemar

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: den 29 juni 2008 21:00
> To: Ingemar Johansson S
> Cc: [email-masked]
> The draft lists several issues in section 5. There are also 
> possible feature interactions with the "a=framerate:", 
> "a=quality:" and "a=orient:" attributes in RFC 4566. And, RFC 
> 4175 also defines width and height parameters which may 
> conflict. I doubt any of these are major issues, but the 
> interactions need to be specified.
> 
> Cheers,
> Colin
> 
> 
> 
> > The image attribute draft has been updated to version -01 
> with some  
> > major changes.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 30 Jun 2008 14:01:55 +0200

Hi

Thanks for comments, answers inline below

/Ingemar 

> From: Even, Roni [mailto:[email-masked]] 
> Sent: den 30 juni 2008 08:45
> To: Colin Perkins; Ingemar Johansson S
> Cc: [email-masked]
> Subject: RE: [MMUSIC] draft-johansson-mmusic-image-attributes
> 
> Hi,
> I think Colin makes good point and would like to add that 
> bullet 1 in section 5 may cause a interoperability problem if 
> the answerer supports only the sprop parameter. My suggestion 
> is to specify that if imageattr is supported that the sprop 
> parameter will be ignored.
OK, will check this out
 
> I also want to add that image size are also specified in 
> other payload formats and not only in H.264.
I find it specified for H.263 (CUSTOM=x,y,MPI). One issue I see is that it, in normal cases, specifies what the offerer wants to receive. Suppose that an fmtp line is as follows.
   CUSTOM=360,240,2;CIF=4;QCIF=3;SQCIF=2
This line would indicate that the custom size (360x240) is the most preferred in order to avoid rescaling. If the answerer accepts this, then we are home free. However if it is not supported the next step is CIF (352x288), if we suppose that this is OK then the receiver of the media will need to do rescaling to fit the image within the desired 360x240 area as the implementor wants to fit other stuff such as menus, buttons and decorative frames etc on the display area aswell.
I would see the options listed on the fmtp line as restrictions related to decoder(+encoder) complexity while imageattr is a way to select desired imagesize on the screen. From that perspective it may well be that the "fr=" parameter should not be present for imageattr.
 
> The justification for image size is for supporting screen 
> size and low compute and that is why the image attribute by 
> itself is not giving a full answer. Low compute can be 
> achieved by specifying the relation between frame rate and 
> size like in H.263 and H.261 payload specifications or by 
> having a max macro blocks per second associated like in H.264 
> which applies that same limitation as the frame rate per 
> resolution in H.263/H.261. 
> By specifying the maximum image size and the maximum Macro 
> Blocks per second you can allow slower frame rate at the 
> maximum resolution and higher frame rate at lower resolution.
I believe I agree here. There is probably little reason for imageattr to interfere with this. I made the "fr=" parameter optional in the draft but it is possible that it should not even be allowed as it may cause too much ambiguities.

> possible 
> > > + Support for Sample Aspect Ratios (SAR) Offer/answer for 
> asymmetric 
> > > + display capabilities Picture aspect Ratio range to limit the 
> > > + number of x and y
> > > resolution options
> > >
> > >
> > > Comments are welcome
> > > /Ingemar
> > >
> > > This draft proposes a new generic session setup attribute 
> to make it 
> > > possible to negotiate different image attributes such as 
> image size.
> > > hand- held terminal to display video without the need to 
> rescale the 
> > > image, something that may consume large amounts of memory and