Subject: [MMUSIC] Maximum non-scaled image size

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 19 Dec 2004 19:52:16 -0500

Do any video payload formats specify, as SDP format attributes or 
otherwise, the maximum image size supported natively (i.e., without 
downscaling)?

For a draft we're working on, I'd like to re-use any existing 
conventions. In general, it would seem useful to know this since there 
isn't much point in sending at a higher resolution than the screen 
resolution or the maximum size that an application can handle. This 
seems like a natural extension to a=framerate in SDP.

Henning

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 20 Dec 2004 09:32:21 +0200

Henning,
In the bis drafts for the H.263 and H.261 I added the support for
specifying the image size that the decoder can receive per frame rate.
For H.261 the support is for fixed resolutions for H.263 the support is
also for custom formats. See draft-ietf-avt-rfc2429-bis-03.txt and
draft-ietf-avt-rfc2032-bis-03.txt
In the H.264, see draft-ietf-avt-rtp-h264-11, the concept was that the
decoder, using the level parameter, specifies the number of macro blocks
per second it can process; The level as specified in H.264 gives a
maximum on the frame rate and resolution. The level parameters can be
overridden by the optional parameters specified in the draft.

The transformation from the decoder to the display is up to the
implementer.  

As can be seen in H.261 and H.263 the SDP from the receiver can specify
an exact picture size(resolution)it can receive, but still the encoder
can send any allowed picture size that is bellow the decoder capability.
For example in H.261 if the decoder specifies it can receive a CIF
picture at 30 fps, the encoder can send a QCIF picture at 15 fps. 
In H.264 there is no explicit resolution specified.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Monday, December 20, 2004 2:52 AM
To: [email-masked]; [email-masked]
Subject: [MMUSIC] Maximum non-scaled image size

Henning

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 20 Dec 2004 09:32:21 +0200

Henning,

Roni Even

-----Original Message-----

Henning

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 20 Dec 2004 09:32:21 +0200

Henning,

Roni Even

-----Original Message-----

Henning

---

From: "Gary Sullivan" <[email-masked]>
Date: Sun, 19 Dec 2004 17:32:01 -0800

There are ways to declare an image size as part of a decoder capability
or a decoder preference indication in both H.245 and SDP (and perhaps
other places too, most likely including H.241 and what H.320 uses) -- I
would suggest checking the design in regards to H.263 as that has
probably been the most commonly used video codec in two-way
communication scenarios.

When specified as part of a declaration of decoder capability, an image
size would ordinarily be interpreted as the maximum that the decoder
could decode, rather than as the maximum it can display.  But if
specified as a decoder preference, its interpretation would be more akin
to what you mention.  That would be a declaration of what image size the
decoder would most like to receive, although perhaps not necessarily an
indication of exactly why.  In some sense, that might be a better thing
to design than what you seek.  (Why pick only one specific reason for
the decoder to indicate its preference for something?)

A decoder might also, of course, use censorship of its decoder
capability declaration to simply not declare capabilities beyond its
native display resolutions.

>From draft-ietf-avt-rfc2429-bis-03.txt (September 2004, section 8.1),
there is a way in SDP for an H.263 decoder to indicate an ordered list
of preferences for picture resolution and frame rate.  (That stuff is
also probably in the original RFC 2429 as well -- I just happen to have
checked the "bis" draft).

Best Regards,

Gary Sullivan

+> -----Original Message-----
+> From: [email-masked] [mailto:[email-masked]] On 
+> Behalf Of Henning Schulzrinne
+> Sent: Sunday, December 19, 2004 4:52 PM
+> To: [email-masked]; [email-masked]
+> Subject: [AVT] Maximum non-scaled image size
+> 
+> Do any video payload formats specify, as SDP format attributes or 
+> otherwise, the maximum image size supported natively (i.e., without 
+> downscaling)?
+> 
+> For a draft we're working on, I'd like to re-use any existing 
+> conventions. In general, it would seem useful to know this 
+> since there 
+> isn't much point in sending at a higher resolution than the screen 
+> resolution or the maximum size that an application can handle. This 
+> seems like a natural extension to a=framerate in SDP.
+> 
+> Henning
+> 
+> 
+> _______________________________________________
+> Audio/Video Transport Working Group
+> [email-masked]
+> https://www1.ietf.org/mailman/listinfo/avt
+>

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 21 Dec 2004 16:00:21 +0200

Hi,
Just a small correction.
The frame rate is not a fixed parameter, for H.261 there are no profile and level. For H.263++ you can use profile and levels but the levels gives maximum on frame rate and on resolution. That is why we are adding in draft-ietf-avt-rfc2032-bis and draft-ietf-avt-rfc2429-bis the SDP parameters to specify the resolutions and the frame rates that can be used. The specific video codecs (H.261 and H.263) has a list of defined resolutions they support and not all the list specified. H.263 can support custom formats.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teodora Guenkova-Luy
Sent: Monday, December 20, 2004 8:51 PM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [MMUSIC] Maximum non-scaled image size

Dear Henning Schulzrinne,
For some codecs the framerate is also a fix parameter of the codec 
definition (e.g. the ITU-T H.26x codecs profiles and levels) and
for other codecs (e.g. MPEG-4) it is a generic parameter, which should 
be defined using descriptions of the media like in SDP.
The framerate is the parameter of biggest influence for the network 
traffic and IMHO that is why nobody has considered the framesize
and the colour quality as generic parameter in SDP up to now. But in 
order to specify performance for codecs with arbitrary definitions
of framesize and the colour quality, you need their media definition in 
SDP (or even better in XML format in SDPng) as well.

With respect to framesize, I would rather put the framesize information 
as one line and would rather specify the following for SDP:

framesize-type = "a=framesize:" sizetype SP width SP height
sizetype = ciftype | vesatype | "arbitrary"

Where the "ciftype" can be described considering the inputs of the 
following table:
CIF Format        Resolution in pixels (width x height)
SQCIF               128 × 96
QCIF                 176 × 144
CIF                    352 × 288
4CIF                  704 × 576
9CIF                  1056 × 864
16CIF                1408 × 1152
TV                     720 × 576
SIF                    352 × 240
SIF (NTSC)      360 × 240
SIF (PAL)         360 × 288

and "vesatype" (AR is Aspect Ratio):

VESA Format    width    height    AR-16:10    AR-16:9    AR-4:3    
non-square pixel
QUXGA-Wide    3820    2400    x           
WUXGA            1920    1200    x           
WSXGA+            1680    1050    x           
WXGA+
  
WXGA                1440    900    x           
                            1280    854    x                          
                              3:2
                            1280    800    x           
                            1280    768    x                           
                             5:3
1080i/1080p        1920    1080                        x       
720i/720p            1280    720                          x       
QUXGA              3200    2400                                        x   
QXGA                 2048    1536                                        
x   
UXGA                1600    1200                                         
x   
SXGA+              1400    1050                                         
x   
SXGA                1280    1024                                         
x                    5:4
XGA                   1024    768                                        
  x   
SVGA                 800    600                                        
    x   
VGA                   640    480                                        
    x   
QVGA                320    240                                        
    x   

If specifying a "ciftype" or "vesatype" the SDP "width" and "height" 
parameters could be optional, e.g.
a=framesize:4CIF

If specifying an "arbitrary" framesize then the  "width" and "height" 
parameters are mandatory and shall be expressed in pixel, e.g.
a=framesize:arbitrary 300 200

Hope this helps,
Teodora Guenkova-Luy

Henning Schulzrinne wrote:

> Thanks for all the explanation. It seems a bit asymmetric that 
> framerate is specified as a generic a= parameter in SDP, while 
> resolution is specified, if at all, on a per-codec basis. Would it 
> make sense to have an 'a=width' and 'a=height' parameter as well?
>
> Teodora Guenkova-Luy wrote:
>
>> Henning Schulzrinne wrote:
>> ------------------------------------------------------------------------- 
>>
>> Dear All,
>>
>> The ITU-T standards (e.g. H.261, H.263, H.264, etc.) explicitly 
>> specify image sizes for the codecs. H.261 and H.263 specify image 
>> sizes according to ITU CIF standard in form of (height x width) 
>> resolution. H.264 also specifies max image sizes per used profile 
>> level in form of max bits per image, but without specifying aspect 
>> ratios. From the MPEG standards only MPEG-1 specifies max image size 
>> of 352x240 height x width resolution. All the other Video MPEGs are 
>> with arbitrary image sizes.  Another possibility to specify image 
>> sizes are the VESA standards from www.vesa.org (e.g. VESA's VGA BIOS 
>> Extensions).  Note, that some standards for video specify frame-rate, 
>> frame-size and colour-quality dependencies. Hence, using some 
>> standard definitions might influence all of these 3 parameters, i.e. 
>> the colour-quality (number of colours per image) might also influence 
>> the amount of network data for the video streams.
>> Note, that frame-size can be specified in 3 different manners:
>> - (height x width) resolution in (pixel x pixel)
>> - standard - i.e. CIF or VESA
>> - max number of bits + aspect ratio - e.g. commonly used aspect 
>> ratios are height: width = 4:3, 5:4, 11:9, 16:9, 16:10. These aspect 
>> ratios stem also from CIF and VESA
>> For the complete and unique video performance specification with SDP 
>> in case of arbitrary video image specification one needs to have 
>> specifications for frame-rate, frame-size and colour-quality.
>> Best Regards,
>>    Teodora Guenkova-Luy
>>
>>
>>

-- 
-----------------------------------------
Teodora Guenkova-Luy

Dept. Distributed Systems, University of Ulm, 
Oberer Eselsberg, 89069 Ulm, Germany

Tel.: +49 (0731) 502-4148 
FAX: +49 (0731) 502-4142

e-Mail: [email-masked]

Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/ 

-----------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 23 Dec 2004 13:03:49 +0200

Hi,
Hi,
As Magnus points out the maximum frame size is limited by the available
frame buffer in the decoder but another parameter that is important is
the frame rate. A decoder may have a large frame buffer or high
resolution display, but due to processing power may be able to use the
full size only for low frame rate.

As for screen resolution I am wondering if the parameter that Magnus
describes address the screen resolution or the available decoder frame
buffer, are they the same.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Magnus Westerlund
Sent: Wednesday, December 22, 2004 10:20 PM
To: Teodora Guenkova-Luy
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [MMUSIC] Maximum non-scaled image size

Hi,

I would like to point out that 3GPP has defined in TS 26.234 a SDP 
attribute a=framesize. It has the following definition:

The following media level SDP field is defined for PSS:

- "a=framesize:<payload type number> <width>-<height>"

This gives the largest video frame size of H.263 streams.
The frame size field in SDP is needed by the client in order to properly

allocate frame buffer memory.  For MPEG-4 Visual streams, the frame size

shall be extracted from the "config" information in the SDP. For H.264 
(AVC) streams, the frame size shall be extracted from the 
sprop-parameters-sets information in the SDP. For H.263 streams, a PSS 
server shall include the "a=framesize" field at the media level for each

stream in SDP, and a PSS client should interpret this field, if present.

Clients should be ready to receive SDP descriptions without this
attribute.

If this attribute is present, the frame size parameters shall exactly 
match the largest frame size defined in the video stream. The width and 
height values shall be expressed in pixels.

However, to my understanding, this attribute is not what Henning is 
seeking. I only like to warn you at an early stage about the potential 
name conflict. I am sorry that I haven't had time yet to write the SDP 
registration draft for the PSS specification.

But on the point Henning is asking about, in the 3GPP Packet-based 
Streaming Service, the servers can use UAProf to determine the clients 
screen resolution.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]