idnits 2.17.1 draft-koskelainen-sdp263-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 530 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 27 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 416: '...Intra requests MUST NOT be used with S...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 95 has weird spacing: '...term may be p...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 476 looks like a reference -- Missing reference section? '4' on line 479 looks like a reference -- Missing reference section? '1' on line 469 looks like a reference -- Missing reference section? '2' on line 473 looks like a reference -- Missing reference section? '5' on line 482 looks like a reference -- Missing reference section? '6' on line 485 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Harri Honko 3 INTERNET-DRAFT Petri Koskelainen 4 Jouni Salonen 5 Expires: Dec 29, 1998 Nokia 6 June 29,1998 8 SDP syntax for H.263 options 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 ABSTRACT 31 This document defines the SDP syntax for 1998 version of H.263 codec 32 options and parameters for IETF multimedia conferencing architecture. 33 It is often useful to know beforehand (in call setup phase) what 34 features of H.263 the other end supports. This document specifies 35 the format spefic parameters for H.263, which exists in 36 a=fmtp: as defined in the SDP document. 37 Moreover, the usage of this feature with SIP and SAP is specified. 39 1. INTRODUCTION 41 Internet multimedia conferencing is becaming a reality and new protocols 42 have been defined to provide co-operation between different applications. 43 Current IETF protocols SIP [3] and SAP [4] are quite widely used to 44 simple MBone conferencing and Internet unicast conferencing is also 45 taking its first steps. Today, the most widely used video codec in this 46 environment is the ITU-T H.261 video standard, but a better and more 47 efficient low-bit rate video standard, ITU-T H.263 [1] (aka H.263+ and 48 H.263v2) is becoming more and more popular. 50 However, the usage of H.263 with current IETF multimedia conferencing 51 architecture is difficult, since improved efficiency of H.263 depends on 52 use of coding options and parameters which must be told somehow to the 53 other end. SIP and SAP protocols can deliver this information, but 54 current SDP [2] format does not specify standardised way of representing 55 these options and parameters. 57 This document specifies the SDP syntax which describes H.263 options and 58 parameters to be delivered by some signaling protocol (e.g. SIP or SAP). 59 The syntax presented in this document uses SDP "a=fmtp" attribute which 60 is meant for carrying codec specific parameters. 62 These options are especially useful in SIP. In SAP it is not clear whether 63 they have any use. In SIP, these format specific parameters are decoder 64 properties or wishes, and in SAP they informative announcement about 65 forthcoming video options and parameters. 66 The SAP rules are applied also if a multicast session is advertised in a 67 web page in SDP format. 69 The syntax in this document is text-based and uses the ISO 10646 character 70 set in UTF-8 encoding (RFC 2279 [5]). This syntax includes one line and it 71 is terminated by CRLF. 73 Syntax is described in an augmented Backus-Naur form (BNF) 74 described in detail in RFC 2234 [6]. 76 2. H.263 CODEC PARAMETERS 78 For further description about these H.263 parameters, please refer to 79 ITU documents [1]. 81 The context in which SDP syntax for H.263 is represented is SDP 82 "a" attribute: 84 a=fmtp 34 SDP_263_syntax 86 "34" is RTP payload number for H.263. 88 The syntax itself is defined as follows: 90 SDP_263_syntax = *capability CRLF | request CRLF | CRLF 92 capability = 1*Size SP | 1*Params SP | 1*Options SP 94 Here as usual, SP means space and *term means that zero or more instances of 95 term may be present. 1*term means that one or more instances of term may 96 appear. 97 SDP_263_syntax may be either capability announcement, intra request 98 during video session or empty line when having only CRLF (end of line). 99 Request is explained in chapter 4. 101 2.1 Picture information and MPI 103 H.263 bitstream supports many picture sizes and different frame rates. 104 Supported picture sizes and their corresponding minimum picture interval 105 (MPI) values are combined with "=" symbol. 106 MPI is an integer value (1..32) and it means that maximum picture (frame) 107 rate is (29.97/MPI) frames/sec. Bigger MPI value means slower picture rate. 109 Augmented BNF syntax for size related H.263 parameters is given below. 111 Size= "SQCIF" "=" mpi | "QCIF" "=" mpi | "CIF" "=" mpi | 112 "CIF4" "=" mpi | "CIF16" "=" mpi | 113 "XMAX" "=" xmax SP "YMAX" "=" ymax SP "MPI" "=" mpi 115 mpi=1*2DIGIT 116 xmax=1*3DIGIT 117 ymax=1*3DIGIT 119 Explanations: 121 SQCIF: 122 Sub-QCIF picture size and its MPI value. 123 MPI is integer value between 1 and 32. 125 QCIF: 126 QCIF picture size and its MPI value (1..32). 128 CIF: 129 CIF picture size and its MPI value (1..32). 131 CIF4: 132 CIF4 picture size and its MPI value (1..32). 134 CIF16: 135 CIF16 picture size and its MPI value (1..32). 137 Arbitrary picture sizes (XMAX,YMAX,MPI): 138 These parameters mean that terminal is capable and/or willing 139 to support arbitrary picture sizes. Both picture sizes must be divisible 140 by 4. These X and Y values are the maximum of allowed picture sizes with 141 corresponding MPI value. All three words must exist together in this 142 order, or none is allowed to exist. 144 More than one mode can exist in the same line (see example later). 145 At least one picture mode should be present. 147 2.2 Other parameters 149 Params= "PAR" "=" par_a ":" par_b | "CPCF" "=" cpcf | "MaxBR" "=" maxbr | 150 "BPP" "=" bpp | "HRD" "=" hrd 152 par_a=1*DIGIT 153 par_b=1*DIGIT 154 cpcf=1*DIGIT "." 1*DIGIT 155 maxbr=1*DIGIT 156 bpp=1*DIGIT 158 Explanations: 160 Arbitrary Pixel Aspect Ratio (PAR): 161 Par_a and par_b are integers between 0 and 255. 162 Default ratio is 12:11 if not otherwise specified. 164 Arbitrary (Custom) Picture Clock Frequency (CPCF): 165 Cpcf is floating point value. Defaut value is 29.97. 167 MaxBitRate (MaxBR): 168 Maximum video stream bitrate, presented with units of 169 100 bits/s. MaxBR value is an integer between 1..19200. 171 BitsPerPictureMaxKb (BPP): 172 Maximum amount of kilobits allowed to represent a single picture frame, 173 value is specified by largest supported picture resolution, see [1]. 174 If this parameter is not present, then default value, that is based 175 on the maximum supported resolution, is used. BPP is integer value 176 between 0 and 65536. 178 Hypothetical Reference Decoder (HRD): 179 See annex B of H.263 specification. 181 These parameters are separated by space. 183 3. H.263 CODEC OPTIONS 185 These options are presented by the character of the annex which 186 describes the corresponding feature. 188 Syntax for options is given below: 190 Options = "D" "=" #annex_d | "E" | "F" | "G" | "I" | "J" | 191 "K" "=" #annex_k | "L" "=" #annex_l | "M" | "N" "=" annex_n | 192 "O" "=" #annex_o | "P" | "Q" | "R" | "S" | "T" 194 annex_d= "1" | "2" 195 annex_k= "1" | "2" | "3" | "4" 196 annex_l= "1" | "2" | "3" | "4" | "5" | "6" | "7" 197 annex_n= "1" | "2" | "3" | "4" 198 annex_o= "1" | "2" | "3" 200 Here #term means comma separated list of term. 202 3.1 H.263v1 Options 204 Annex D: UnRestricted motion Vector option. 205 D is 1 and/or 2 see later in chapter 3.2. 207 Annex E: Syntax based Arithmetic Coding. 208 It is expected that this annex is not widely used because of the 209 complexity and IPR-issues. 211 Annex F: Advanced Prediction. 213 Annex G: PB Frames. 215 3.2 H.263v2 Options 217 Below are the new codec options which are defined in 1998 version of 218 H.263. 220 Annex D: UnRestricted motion Vector. 221 This mode is applied differently depending whether H.263v1 or 222 H.263v2 is used. 1 means that H.263v1 is used and annex D is applied 223 correspondingly. 2 means that H.263v2 is used. Terminal can support both 224 modes. 225 Example: D=1,2 227 Annex I: Advanced Intra Coding mode. 229 Annex J: Deblocking Filter mode 231 Annex K: Slice Structured mode 232 This mode can have up to four possible modes. It can support none, some or 233 all of these modes. The modes are as follows: 234 1: slicesInOrder-NonRect 235 2: slicesInOrder-Rect 236 3: slicesNoOrder-NonRect 237 4: slicesNoOrder-Rect 238 Example: K=1,2,4 240 Annex L: Supplementary Enhancement Information Specification 241 This mode has several features. 242 The possibly supported features are: 243 1: full picture freeze 244 2: partial picture freeze and release 245 3: resizing partial picture freeze 246 4: full picture snapshot 247 5: partial picture snapshot 248 6: video segment tagging 249 7: progressive refinement 250 Example: L=1,6 252 Annex M: Improved PB-frames mode 254 Annex N: Reference Picture Selection mode 255 Four choices (modes) is available: 256 1: NEITHER: In which no back-channel data is returned from the 257 decoder to the encoder, 258 2: ACK: In which the decoder returns only acknowledgment messages, 259 3: NACK: In which the decoder returns only non-acknowledgment messages, and 260 4: ACK+NACK: In which the decoder returns both acknowledgment and 261 non-acknowledgment messages. 262 Example: N=2 263 For further details, see [1]. 265 Annex O: Temporal, SNR, and Spatial Scalability mode 266 This annex has three possible choices (temporal, SNR, spatial). 267 The mode is represented by integer number which refers to temporal, 268 SNR or spatial scalability, respectively. These three 269 submodes can be available at the same time. 270 Example: O=2,3 272 Annex P: Reference Picture Resampling 273 Explanation: Following submodes are available: 274 1: dynamicPictureResizingByFour 275 2: dynamicPictureResizingBySixteenthPel 276 3: dynamicWarpingHalfPel 277 4: dynamicWarpingSixteenthPel 278 Example: P=1,3 279 See [1] for further details. 281 Annex Q: Reduced-Resolution Update mode 283 Annex R: Independent Segment Decoding mode 285 Annex S: Alternative INTER VLC mode 287 Annex T: Modified Quantization mode 289 The presence of annex character indicates the availability of that 290 feature. 292 The actual interpretation of these words is defined differently for 293 one-way and two-way negotiations (see chapters 5 and 6). 295 Note that some annexes can not be used together. H.263 specification 296 gives detailed rules for this issues and it should be followed. 298 4. H.263 REQUEST FEATURES IN SDP 300 It is sometimes useful to request intra update from other end 301 during video session. This update might be intra picture update 302 or GOP (Group of Blocks) update. 304 request= intra | gob 306 intra= "I-UPDATE" 307 Explanation: Intra picture should be sent as soon as possible. 308 This must NOT be present in the capability exchange phase. 309 It must be alone in the a=fmtp line when it is used (during video session). 311 gob= "GOB-UPDATE" "=" First "," Amount 312 First=1*DIGIT 313 Amount=1*DIGIT 315 Explanation: Group of Blocks are requested and they should be sent as soon 316 as possible. "First" is the first GOB to be requested and "Amount" is the 317 number of requested GOBs. This must NOT be present in the capability 318 exchange phase. 319 It must be alone in the a=fmtp line when it is used (during video session). 321 Example: 323 a=fmtp 34 GOP-UPDATE=1,3 324 Here first 3 GOPs are updated. 326 When receiving this, video encoder should send intra picture update 327 as soon as possible. This feature is signaled only during video session, 328 not before it. 330 5. USAGE OF SDP H.263 OPTIONS AND PARAMETERS WITH SIP 332 This document does not specify actual SIP signaling. There is no 333 need to negotiation because it is quite needless since it is enough 334 to tell the preferred decoder options and parameters and let the other 335 end to decide actual options and parameters as long as the other party 336 sends only such options and parameters which are advertized. 337 This scheme keeps the IETF multimedia terminal simple. 338 This syntax should be sent with SIP INVITE and corresponding 339 status response (200 ok). 341 Codec options: (D,E,F,G,I,J,K,L,M,N,O,P,Q,R,S,T) 342 These characters exist only if the sender of this SDP message is able or 343 willing to decode those. E.g. If a terminal is capable of decoding 344 SAC and AP options, it can put E F in the end of . Then the other party knows it, and can use those options 346 in its encoder. 348 Picture sizes and MPI: 349 Supported picture sizes and their corresponding minimum picture interval 350 (MPI) information can be combined. All picture sizes can be advertised to 351 other party, or only some subset of it. Terminal announces only those 352 picture sizes (with their MPIs) which it is willing to receive. 353 For example, MPI=2 means that maximum (decodeable) picture rate per sec 354 is about 15. 356 Parameter occurring first is the most preferred picture mode to be 357 received, and last is the least preferred (but still supported) one. 359 These words are present in SDP line only if terminal is willing to 360 decode the picture size with corresponding MPI. If terminal is not 361 willing to receive some mode, it is not present in the list. 363 Example of the usage of these words: 365 CIF=4 QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2 367 This means that sender hopes to receive CIF picture size, which it can 368 decode at MPI=4. If that is not possible, then QCIF with MPI value 3, 369 if that is neither possible, then SQCIF with MPI value =2. It is also 370 allowed (but least preferred) to send arbitrary picture sizes 371 (max 360x240) with MPI=2. 372 Note that most encoders support at least QCIF and CIF fixed resolutions 373 and they are expected to be available almost in every H.263-based video 374 application. 376 MaxBR and BPP parameters: 377 Both these parameters are useful in SIP. MaxBitRate is video decoder 378 property, hence it differs from SDP b: 379 attribute which refers more to application's total bandwidth (an 380 application consists often of both audio and video). 382 BitsPerPictureMaxKb is needed especially for decoder buffer size 383 estimation to reduce the propability of video buffer overflow. 385 Also PAR, CPCF and HRD parameters can be applied in SIP. 387 Below is an example of H.263 SDP syntax in SIP message. 389 a=fmtp 34 CIF=4 QCIF=2/MaxBR=1000/E F 391 This means that the sender of this message can decode H.263 (RTP 392 payload type 34) bitstream with following options and parameters: 393 Preferred resolution is CIF (its MPI is 4), but if that is not 394 possible then QCIF size is ok. Maximum receivable bitrate is 395 100 kbit/s (1000*100 bit/s) and SAC and AP options can be used. 397 Intra picture update can be provided during session with new SIP INVITE 398 message with same Call-id like this: 399 ... 400 m=video 9999 RTP/AVP 34 401 a=fmtp 34 I-UPDATE 402 .... 404 6. USE OF SDP H.263 SYNTAX AND OPTIONS WITH SAP 406 SAP announcements are one-way only. All H.263 options can be used to 407 mean that sending terminal is going to use these options in its 408 transmitted H.263 stream. It is just an informal message. 410 Usually only one picture size (with its MPI) exists. However, since it 411 is possible for a video source (terminal) to change its picture size 412 during session, several picture sizes can exist in the parameter list. 413 First one is the original picture size to be used in the beginning of 414 the session. 416 Intra requests MUST NOT be used with SAP. 418 Example with SAP: 419 a=fmtp 34 CIF=2/D=1 F 421 The video source is sending an H.263 bitstream and picture size is CIF, 422 MPI=2 and URV and SAC options are used. This kind of announcement can be 423 used e.g. in the MBone. 425 7. SECURITY CONSIDERATIONS 427 Security is truly believed to be irrelevant to this document. 429 8. CHANGES FROM DRAFT-01: 431 - Syntax is represented with augmented BNF 433 - H.263 option acronyms are changed to annex characters (e.g. "SAC"->"E") 435 - some parameter names are now shorter (e.g. BitsPerPictureMaxKb -> BPP) 436 in order to shorten SDP description and to simplify it 438 - new parameters as suggested by Gary Sullivan: HRD, PAR, CPCF 440 - intra updates are now possible during video session 441 (with new SIP INVITE-message) 443 - MaxBR is no longer mandatory plus many similar minor changes 445 - H.263v2 options are added. Some of these have parameters (e.g. annex O 446 has three possible values (temporal/SNR/spatial scalability) so the 447 syntax is e.g: O=2,3 449 9. OPEN QUESTIONS 451 The use of profiles (like in MPEG2 etc) to simplify the most common 452 group of options. 453 - this seems unnecessary.. 455 AUTHORS' ADDRESSES 457 Harri Honko, Petri Koskelainen 458 Nokia Research Center 459 P.O.Box 100 460 FIN-33721 Tampere 461 Finland 462 e-mail: 463 harri.honko@research.nokia.com, 464 petri.koskelainen@research.nokia.com, 465 jouni.salonen@ntc.nokia.com 467 References: 469 [1] International Telecommunication Union. 470 Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 471 ITU 1998 473 [2] Handley et al, ``SDP - Session Description Protocol'', 474 RFC2327, Internet Engineering Task Force, 1998. 476 [3] Handley et al, ``SIP - Session Initiation Protocol'', 477 INTERNET-DRAFT, Internet Engineering Task Force, 1998. 479 [4] ``SAP - Session Announcement Protocol'', 480 INTERNET-DRAFT, Internet Engineering Task Force, 1997. 482 [5] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 483 2279, Internet Engineering Task Force, Jan. 1998. 485 [6] D. Crocker and P. Overell, "Augmented BNF for syntax 486 specifications: ABNF," RFC 2234, Internet Engineering Task Force, 487 Nov. 1997.