Ingemar, ForH.264 the level parameter defines the maximum FS (frame size) in macro blocks. The image can not be bigger than that since it specify the maximum display buffer on the receiver. There is a parameter that overrides it maxFS that allows the receiver to say that he can support larger picture but then the level parameter maxmbps (max macro blocks per second) will limit the frame rate. So For h.264 you cannot give picture size bigger then level or maxFS For H.263 you either specify maximum resolution using the parameters in RFC 4629 or the level in table X.2 in H.263. Text from H.263 Custom picture formats can have a custom pixel aspect ratio as described in Table 3, if the custom pixel aspect ratio use is first negotiated by external means. Custom picture formats can have any number of lines and any number of pixels per line, provided that the number of lines is divisible by four and is in the range [4, ... , 1152], and provided that the number of pixels per line is also divisible by foFrom avt-bounces at ietf.org Wed Jul 30 09:43:28 2008 Return-Path: <avt-bounces at ietf.org> X-Original-To: avt-archive at optimus.ietf.org Delivered-To: ietfarch-avt-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0DB3A6B48; Wed, 30 Jul 2008 09:43:28 -0700 (PDT) X-Original-To: avt at core3.amsl.com Delivered-To: avt at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187663A6BFD; Wed, 30 Jul 2008 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtCveJQG5q9I; Wed, 30 Jul 2008 09:43:20 -0700 (PDT) Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id F17EB3A6BE4; Wed, 30 Jul 2008 09:43:18 -0700 (PDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 19:44:37 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C05D2B6EC at IsrExch01.israel.polycom.com> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507FB7C46 at esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: RE: [MMUSIC] [AVT] spatial-resolution parameter for RFC 3984bis Thread-index: Acjx1mAy9rWwYJ8CRPmwN3dTSs9BPQATYOxwAA9TKCAReferences: <0K4S00DD1L1O0B at ms7.samsung.com> <026F8EEDAD2C4342A993203088C1FC0507FB7C46 at esealmw109.eemea.ericsson.se> From: "Even, Roni" <roni.even at polycom.co.il> To: "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>, <kyunghun.jung at samsung.com> Cc: Randell Jesup <rjesup at wgate.com>, mmusic at ietf.org, avt at ietf.org, Ye-Kui.Wang at nokia.com Subject: Re: [AVT] [MMUSIC] spatial-resolution parameter for RFC 3984bis X-BeenThere: avt at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/avt> List-Post: <mailto:avt at ietf.org> List-Help: <mailto:avt-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="==============27799125==" Sender: avt-bounces at ietf.org Errors-To: avt-bounces at ietf.org This is a multi-part message in MIME format.Title: Samsung Enterprise Portal mySingle
|
Ingemar, ForH.264 the level parameter
defines the maximum FS (frame size) in macro blocks. The image can not be
bigger than that since it specify the maximum display buffer on the receiver.
There is a parameter that overrides it maxFS that allows the receiver to say
that he can support larger picture but then the level parameter maxmbps (max
macro blocks per second) will limit the frame rate. So For h.264 you cannot
give picture size bigger then level or maxFS For H.263 you either specify
maximum resolution using the parameters in RFC 4629 or the level in table X.2
in H.263. Text from H.263 Custom picture formats can have a
custom pixel aspect ratio as described in Table 3, if the custom pixel aspect
ratio use is first negotiated by external means. Custom picture formats can
have any number of lines and any number of pixels per line, provided that the
number of lines is divisible by four and is in the range [4, ... ,
1152], and provided that the number of pixels per line is also divisible by
four and is in the range [4, ... , 2048]. For picture formats having
a width or height that is not divisible by 16, the picture is decoded in the
same manner as if the width or height had the next larger size that would be
divisible by 16 and then the picture is cropped at the right and the bottom to
the proper width and height for display purposes only. Table 3/H.263 – Custom pixel aspect ratios
All decoders and encoders shall be able to operate using the
CIF picture clock frequency. Some decoders and encoders may also support custom
picture clock frequencies. All decoders shall be able to operate using the
sub-QCIF picture format. All decoders shall also be able to operate using the
QCIF picture format. Some decoders may also operate with CIF, 4CIF or 16CIF, or
custom picture formats. Encoders shall be able to operate with one of the
picture formats sub-QCIF and QCIF. The encoders determine which of these two
formats are used, and are not obliged to be able to operate with both. Some
encoders can also operate with CIF, 4CIF, 16CIF, or custom picture formats. For H.261 there is no
support for arbitrary picture size (CIF is the largest) see RFC 4587 So in the general case there
should be a way to reject the request and maybe give the supported resolution,
still it will be wrong to use this attribute for H.261 Roni From: Ingemar Johansson S
[mailto:ingemar.s.johansson at ericsson.com] Hi If I understand your email correctly we will, with the
constructed SDP's below, have the potential issue that imageattr may offer
combinations (x and y resoluions) that are not allowed for a given profile
level ID. The solution I see is that the profile levels provides with an upper
(maybe also a lower?) limit. For instance if we have some (really wierd) imageattr like a=imageattr:97 [x=[128:16:1920],
y=[96:16:1280],par=[1.1 1.3]] and the profile levels only supports a resolution up to
352x288 , the latter limitation will apply which means that the imageattr
should infact be interpreted as a=imageattr:97 [x=[128:16:352],
y=[96:16:288],par=[1.1 1.3]] This is not written anywhere in the draft and I don't
right now know if this will hold in the general case, please comment. /Ingemar
Extended PAR |
m:n, m and n are relatively prime |
All decoders and encoders shall be able to operate using the
CIF picture clock frequency. Some decoders and encoders may also support custom
picture clock frequencies. All decoders shall be able to operate using the
sub-QCIF picture format. All decoders shall also be able to operate using the
QCIF picture format. Some decoders may also operate with CIF, 4CIF or 16CIF, or
custom picture formats. Encoders shall be able to operate with one of the
picture formats sub-QCIF and QCIF. The encoders determine which of these two
formats are used, and are not obliged to be able to operate with both. Some
encoders can also operate with CIF, 4CIF, 16CIF, or custom picture formats.
For H.261 there is no
support for arbitrary picture size (CIF is the largest) see RFC 4587
So in the general case there
should be a way to reject the request and maybe give the supported resolution,
still it will be wrong to use this attribute for H.261
Roni
From: Ingemar Johansson S
[mailto:ingemar.s.johansson at ericsson.com]
Sent: Wednesday, July 30, 2008 12:23 PM
To: kyunghun.jung at samsung.com; Even, Roni
Cc: Randell Jesup; mmusic at ietf.org; Ye-Kui.Wang at nokia.com; avt at ietf.org
Subject: RE: RE: [MMUSIC] [AVT] spatial-resolution parameter for RFC
3984bis
Hi
If I understand your email correctly we will, with the
constructed SDP's below, have the potential issue that imageattr may offer
combinations (x and y resoluions) that are not allowed for a given profile
level ID. The solution I see is that the profile levels provides with an upper
(maybe also a lower?) limit.
For instance if we have some (really wierd) imageattr like
a=imageattr:97 [x=[128:16:1920],
y=[96:16:1280],par=[1.1 1.3]]
and the profile levels only supports a resolution up to
352x288 , the latter limitation will apply which means that the imageattr
should infact be interpreted as
a=imageattr:97 [x=[128:16:352],
y=[96:16:288],par=[1.1 1.3]]
This is not written anywhere in the draft and I don't
right now know if this will hold in the general case, please comment.
/Ingemar
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www.ietf.org/mailman/listinfo/avt