From nobody Fri Aug 8 07:44:08 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E414F1B2B1E for ; Fri, 8 Aug 2014 07:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_42=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_IKeh1aNa_D for ; Fri, 8 Aug 2014 07:44:02 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1571B2A75 for ; Fri, 8 Aug 2014 07:43:57 -0700 (PDT) Received: from cn03.changenet.sk (cn03.changenet.sk [86.110.225.135]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id s78Eha2Y023066 for ; Fri, 8 Aug 2014 14:43:57 GMT Received: from localhost (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: szilva) by cn03.changenet.sk (Postfix) with ESMTPSA id 58B82A21D8; Fri, 8 Aug 2014 16:27:33 +0200 (CEST) Received: from 188-167-156-191.dynamic.chello.sk (188-167-156-191.dynamic.chello.sk [188.167.156.191]) by mail.changenet.sk (Horde Framework) with HTTP; Fri, 08 Aug 2014 16:27:33 +0200 Message-ID: <20140808162733.11461mttmgyy1ikg@mail.changenet.sk> Date: Fri, 08 Aug 2014 16:27:33 +0200 From: szilva@changenet.sk To: S Moonesamy References: <20140308160850.57913ia6w1v9df0g@mail.changenet.sk> <5322BCCD.8080000@it.aoyama.ac.jp> <20140317110118.10645ltjtjjp6c0s@mail.changenet.sk> <6.2.5.6.2.20140321141522.0d3b6180@resistor.net> In-Reply-To: <6.2.5.6.2.20140321141522.0d3b6180@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Virus-Scanned: clamav-milter 0.98.1 at cn03 X-Virus-Status: Clean X-Greylist: Delayed for 00:16:02 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 08 Aug 2014 14:43:57 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/G3gGB7KuQvxUWzqGAnN_3mCGtzE Cc: "Martin J. =?utf-8?b?RMO8cnN0?=" , media-types@iana.org Subject: Re: [media-types] media type registration of the Slovak national standard for e-forms container e-form+xml, e-form+zip X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:44:04 -0000 Citát S Moonesamy : > Hi Stefan, > At 03:01 17-03-2014, szilva@changenet.sk wrote: >> Do you think IESG can accept the Ministry of finance of the Slovak >> republic as a recognized standards-related organization? If you think >> so, how long can such a decision take and what is needed for such an >> approval? > > Would it be possible to do it through SÚTN? > Thank you for your answer. I am sorry for my late response. After a lot of work the Slovak national e-forms specification is now in one of the final legislative phases. In March 2014, I wrote to SÚTN (Slovak Standards Institute) and they informed me: - They do not have any practice with IANA registrations. They are not IANA members and they never consulted with IANA. - They suggested us to communicate directly with IANA and try to agree on next steps. - Since January 1, 2014 they are merged with Slovak Office of Standards, Metrology and Testing (UNMS). SUTN is now only one of UNMS internal sections. They had too much work with the merging process. >> Or you think we should submit our specification to the IESG >> standardization process - i.e. for publication as an RFC? >> >> We do not have any experience with the IETF/IESG standardization >> process and I have doubt if it is realistic to try to register our >> national standard in the Standards Tree. Our specifications are >> currently only in the Slovak language and I don't know if or when we >> will create an adequate English version. Our working groups do not >> have enough time and human resources (most of the work is done >> voluntarily). I'm afraid our standardization effort in the Standards >> Tree can get stuck because of these reasons. We need the media type >> registration in a short time. > > It would help to have a stable specification. It does not have to be a RFC. > > It is better to do what is easier for you especially if there isn't > enough human resources. Please ask questions if you have any doubt > about how the standardization process works. > OK. Do you agree with Martin J. Dürst that the following media type designation may be acceptable for IANA? : "e-form+xml" - application/vnd.gov.sk.e-form+xml "e-form+zip" - application/vnd.gov.sk.e-form+zip "gov.sk" is the second-level domain name used by the Slovak government organizations, such as www.government.gov.sk, www.finance.gov.sk, www.nases.gov.sk, etc. The contact person for the standard will be Mr. Peter Biro, Ministry of finance of the Slovak republic - standard ( at ) mfsr.sk Thank you for your help. Stefan Szilva > Regards, > S. Moonesamy From fvitaliprivate@gmail.com Sat Aug 16 09:55:51 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE01E1A0768 for ; Sat, 16 Aug 2014 09:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.466 X-Spam-Level: * X-Spam-Status: No, score=1.466 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec9gEtGiw8wP for ; Sat, 16 Aug 2014 09:55:50 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21D11A04E7 for ; Sat, 16 Aug 2014 09:55:48 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id s7GGtRGZ031760 for ; Sat, 16 Aug 2014 16:55:48 GMT Received: by mail-wg0-f45.google.com with SMTP id x12so3341695wgg.28 for ; Sat, 16 Aug 2014 09:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=JUYbK3y0j7pWijMa6HvePt40GpGVnc37aRuUIjA6x0g=; b=ndJhz8wq3UQ5UjFu64Bq0wK6n7PLjmXUpIZhorpcRuPxOJMRC58PUAJGWP0zjxISvg l35MaXSu+5pyfC2B8jtetLz9oFmA0NmnOi4RQEJmij93gW7G/HOPc5mbXGwAv+1SbbUV jAscSdGfxsashepsXNSkX5QsKrTZJ6dgVd6ncxYUDiTIDsfzGDPJGft9S3bk8271aoUl anTKwqoe07um5zirtt+BNWeD2YoRBWTnMPQwg9rJO4ub4LhjhlEndIa/WqrEHwNE+zTK SpfTwzdSnUzvQH2n5GVYtvwf2Qz0faW5AaWIf/T+g2ba4h3DOf58O8pj8yr+TS40dtI5 vLew== X-Received: by 10.180.19.97 with SMTP id d1mr29307542wie.19.1408208127148; Sat, 16 Aug 2014 09:55:27 -0700 (PDT) Received: from [10.0.1.13] (host241-50-dynamic.47-79-r.retail.telecomitalia.it. [79.47.50.241]) by mx.google.com with ESMTPSA id 10sm27707788wjr.22.2014.08.16.09.55.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 09:55:26 -0700 (PDT) Sender: Fabio Vitali From: Fabio Vitali Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Aug 2014 18:55:32 +0200 Message-Id: <484B3BE9-8FF5-4BA2-BB24-75DAE19BDC7A@cs.unibo.it> To: media-types@iana.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Sat, 16 Aug 2014 16:55:48 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/CGVfyVn1oa93bNQz6Db4CQvWRV8 X-Mailman-Approved-At: Sat, 16 Aug 2014 11:24:17 -0700 Cc: Monica Palmirani , Robin Cover Subject: [media-types] Proposed media type registration for OASIS LegalDocML - Akoma Ntoso XML (resending) X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 17:16:08 -0000 Hello.=20 I have been tasked by the OASIS LegalDocML Technical Committee to start = the procedures to register a new media type under the 'application' = tree, as specified in the following. As an explanation, Akoma Ntoso is the main expected output of the = activities of the OASIS LegalDocML Technical Committee, aimed at = providing an XML vocabulary for legal and legislative documents in = national parliaments, courts and other legal institutions. Several = Parliaments and legislative bodies in the world have already decided = adoption or expressed interest and support for the data format.=20 Thank you. Fabio Vitali=20 (OASIS LegalDocML co-chair) ---------------------------------------------------- MIME media type name: --------------------- application MIME subtype name: ------------------ akn+xml Required parameters: -------------------- None Optional parameters: -------------------- charset with identical semantics to the charset parameter of the application/xml media type as specified in [RFC 3023] and=20 successors. Encoding considerations: ------------------------ Akoma Ntoso documents are XML, and therefore have the same considerations when sent as "application/akn+xml" as XML. See [RFC 3023] (or its successors), section 3.2. Security considerations: ------------------------ Since this media type uses the "+xml" convention, it shares the security considerations described in Section 10 of RFC 3023=20 [RFC3023], Akoma Ntoso documents may contain arbitrary URIs.=20 Hence the security issues of [RFC3986], Section 7, apply. Interoperability considerations: -------------------------------- This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements. Since Akoma Ntoso is designed to=20 be extensible in specific elements, "application/akn+xml" processors=20= MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid Akoma Ntoso or expect to recognize = all of the elements and attributes in the document. Published specification: ------------------------ The Akoma Ntoso specifications are an upcoming output of the = LegalDocML=20 Technical Committee of OASIS. Specification of the Akoma Ntoso schema = is available in draft form at http://www.akomantoso.org, and will be = made available on the OASIS web site during the normal approval process.=20= Applications which use this media type=20 -------------------------------------- Akoma Ntoso documents are created, accepted and managed by a number = of=20 tools in use by parliaments that are active in the legal XML domain.=20= These include document management systems, legal drafting tools, URI=20= resolvers and format converters.=20 The necessity of this media types arises with those institutions that have another XML data format for their legal documents, and that want=20= to add support for Akoma Ntoso, since by examining the request they need to be able to determine the XML vocabulary to use for the = response.=20 Fragment identifiers -------------------- Documents having the media type 'application/akn+xml' use a fragment=20= identifier notation totally consistent with what is specified in = [RFC3023]=20 for the media type 'application/xml'. Restrictions on usage=20 --------------------- None.=20 Provisional registration?=20 ------------------------- We kindly request provisional registration for application/akn+xml Additional information: ----------------------- Magic number(s): There is no single initial octet sequence that is always present in Akoma Ntoso documents. File extension(s): Akoma Ntoso documents are most often identified with the = extensions ".akn". Macintosh File Type Code(s): TEXT Person and email address to contact for further information: ------------------------------------------------------------ Fabio Vitali Monica Palmirani Intended usage: --------------- COMMON Author: ------- The Akoma Ntoso specification is an output of the LegalDocML=20 Technical Committee of the Legal XML Member Section of OASIS. Change controller: ------------------ The OASIS Legal XML Member Section has change control over these = specifications. ------------------------------------------------------------------ -- Fabio Vitali Tiger got to hunt, bird got to = fly, Dept. of Computer Science Man got to sit and wonder "Why, why, = why?' Univ. of Bologna ITALY Tiger got to sleep, bird got to = land, phone: +39 051 2094872 Man got to tell himself he = understand. e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's = cradle" http://vitali.web.cs.unibo.it/ From nobody Fri Aug 29 02:53:30 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E142E1A001C for ; Fri, 29 Aug 2014 02:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.888 X-Spam-Level: **** X-Spam-Status: No, score=4.888 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXXjiYJfe0AW for ; Fri, 29 Aug 2014 02:53:19 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D9E1A0007 for ; Fri, 29 Aug 2014 02:53:19 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id s7T9qvVC019140 for ; Fri, 29 Aug 2014 09:53:17 GMT Received: by mail-wg0-f46.google.com with SMTP id x13so1877089wgg.29 for ; Fri, 29 Aug 2014 02:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=1dbGLC0BNyEBKxY9Yx2xbJGLlwNeABo8VEi8WTSDfvs=; b=HeJaqonKo4sUaaYJDPfvtBuQVA8dw8HEkQmHC9/gnp7fv/25mzT8nX43IP5OQVHsWU 7B+sCQ0a8OnMK0jVWDqj7W1JzTfLukbezqa/oEi9iM/gZUwu6jNRTQ4UCzUFAfqMkmI4 dm1mGWSplrg2QH+DDmRDvtGpSljlm4zKIymqh7rnvJs+V4JmKSpw1m43BAzrJm9b2aHY OLjP0sxvJtZKgFvBOgaLOhkzROOFEorhH9KEVdtnZUwYn3wHwlrqWOAwzZMwgbmbev2X sojZGZdh0FowXLmOs865HQA3VEZH+TGstmEia5MBspelI2l37fE75IxzHwuyAS4cYy9/ BD6A== X-Received: by 10.180.93.5 with SMTP id cq5mr2850025wib.16.1409305976660; Fri, 29 Aug 2014 02:52:56 -0700 (PDT) Received: from RoniE (bzq-79-180-161-139.red.bezeqint.net. [79.180.161.139]) by mx.google.com with ESMTPSA id lv7sm24546081wic.16.2014.08.29.02.52.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Aug 2014 02:52:55 -0700 (PDT) From: "Roni Even" To: Date: Fri, 29 Aug 2014 12:52:36 +0300 Message-ID: <001801cfc36e$f7b61d40$e72257c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CFC388.1D199C60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+Pc0bGW1wUhWZUT362e/jTreaTVQ== Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Fri, 29 Aug 2014 09:53:19 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/tt5fcQLn1CNZn1hlZxqrfq8BdZc Cc: draft-ietf-payload-rtp-h265@tools.ietf.org, "'Ali C. Begen \(abegen\)'" Subject: [media-types] registeration of H265 media subtype for High Efficiency Video Coding (H.265) payload format X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 09:53:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CFC388.1D199C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, draft-ietf-payload-rtp-h265-04 is in Working Group Last Call in the Payload Working Group. The document registers media subtype H265. The new registrations are in Section 7.1 of the document and is also given bellow. Comments on the registration are welcome. Thanks Roni Even Payload WG co-chair Media Type name: video Media subtype name: H265 Required parameters: none OPTIONAL parameters: profile-space, tier-flag, profile-id, profile-compatibility- indicator, interop-constraints, and level-id: These parameters indicate the profile, tier, default level, and some constraints of the bitstream carried by the RTP stream and all RTP streams the RTP stream depends on, or a specific set of the profile, tier, default level, and some constraints the receiver supports. The profile and some constraints are indicated collectively by profile-space, profile-id, profile-compatibility-indicator, and interop-constraints. The profile specifies the subset of coding tools that may have been used to generate the bitstream or that the receiver supports. Informative note: There are 32 values of profile-id, and there are 32 flags in profile-compatibility-indicator, each flag corresponding to one value of profile-id. According to HEVC version 1 in [HEVC], when more than one of the 32 flags is set for a bitstream, the bitstream would comply with all the profiles corresponding to the set flags. However, in a draft of HEVC version 2 in [HEVC draft v2], subclause A.3.5, 19 Format Range Extensions profiles have been specified, all using the same value of profile-id (4), differentiated by some of the 48 bits in interop- constraints - this (rather unexpected way of profile signalling) means that one of the 32 flags may correspond to multiple profiles. To be able to support whatever HEVC extension profile that might be specified and indicated using profile-space, profile-id, profile-compatibility- indicator, and interop-constraints in the future, it would be safe to require symmetric use of these parameters in SDP offer/answer unless recv-sub-layer-id is included in the SDP answer for choosing one of the sub-layers offered. The tier is indicated by tier-flag. The default level is indicated by level-id. The tier and the default level specify the limits on values of syntax elements or arithmetic combinations of values of syntax elements that are followed when generating the bitstream or that the receiver supports. A set of profile-space, tier-flag, profile-id, profile- compatibility-indicator, interop-constraints, and level-id parameters ptlA is said to be consistent with another set of these parameters ptlB if any decoder that conforms to the profile, tier, level, and constraints indicated by ptlB can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by ptlA. In SDP offer/answer, when the SDP answer does not include the recv-sub-layer-id parameter that is less than the sprop-sub- layer-id parameter in the SDP offer, the following applies: o The profile-space, tier-flag, profile-id, profile- compatibility-indicator, and interop-constraints parameters MUST be used symmetrically, i.e. the value of each of these parameters in the offer MUST be the same as that in the answer, either explicitly signalled or implicitly inferred. o The level-id parameter is changeable as long as the highest level indicated by the answer is either equal to or lower than that in the offer. Note that the highest level is indicated by level-id and max-recv-level-id together. In SDP offer/answer, when the SDP answer does include the recv-sub-layer-id parameter that is less than the sprop-sub- layer-id parameter in the SDP offer, the set of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop-constraints, and level-id parameters included in the answer MUST be consistent with that for the chosen sub-layer representation as indicated in the SDP offer, with the exception that the level-id parameter in the SDP answer is changable as long as the highest level indicated by the answer is either lower than or equal to that in the offer. More specifications of these parameters, including how they relate to the values of the profile, tier, and level syntax elements specified in [HEVC] are provided below. profile-space, profile-id: The value of profile-space MUST be in the range of 0 to 3, inclusive. The value of profile-id MUST be in the range of 0 to 31, inclusive. When profile-space is not present, a value of 0 MUST be inferred. When profile-id is not present, a value of 1 (i.e. the Main profile) MUST be inferred. When used to indicate properties of a bitstream, profile-space and profile-id are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_profile_space, general_profile_idc, sub_layer_profile_space[j], and sub_layer_profile_idc[j] are specified in [HEVC]: If the RTP stream is the highest RTP stream, the following applies: o profile_space = general_profile_space o profile_id = general_profile_idc Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub- layer-id parameter: o profile_space = sub_layer_profile_space[j] o profile_id = sub_layer_profile_idc[j] tier-flag, level-id: The value of tier-flag MUST be in the range of 0 to 1, inclusive. The value of level-id MUST be in the range of 0 to 255, inclusive. If the tier-flag and level-id parameters are used to indicate properties of a bitstream, they indicate the tier and the highest level the bitstream complies with. If the tier-flag and level-id parameters are used for capability exchange, the following applies. If max-recv- level-id is not present, the default level defined by level-id indicates the highest level the codec wishes to support. Otherwise, max-recv-level-id indicates the highest level the codec supports for receiving. For either receiving or sending, all levels that are lower than the highest level supported MUST also be supported. If no tier-flag is present, a value of 0 MUST be inferred and if no level-id is present, a value of 93 (i.e. level 3.1) MUST be inferred. When used to indicate properties of a bitstream, the tier-flag and level-id parameters are derived from the profile, tier, and level syntax elements in SPS or VPS NAL units as follows, where general_tier_flag, general_level_idc, sub_layer_tier_flag[j], and sub_layer_level_idc[j] are specified in [HEVC]: If the RTP stream is the highest RTP stream, the following applies: o tier-flag = general_tier_flag o level-id = general_level_idc Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub- layer-id parameter: o tier-flag = sub_layer_tier_flag[j] o level-id = sub_layer_level_idc[j] interop-constraints: A base16 [RFC4648] (hexadecimal) representation of six bytes of data, consisting of progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, and reserved_zero_44bits. If the interop-constraints parameter is not present, the following MUST be inferred: o progressive_source_flag = 1 o interlaced_source_flag = 0 o non_packed_constraint_flag = 1 o frame_only_constraint_flag = 1 o reserved_zero_44bits = 0 When the interop-constraints parameter is used to indicate properties of a bitstream, the following applies, where general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, sub_layer_progressive_source_flag[j], sub_layer_interlaced_source_flag[j], sub_layer_non_packed_constraint_flag[j], sub_layer_frame_only_constraint_flag[j], and sub_layer_reserved_zero_44bits[j] are specified in [HEVC]: If the RTP stream is the highest RTP stream, the following applies: o progressive_source_flag = general_progressive_source_flag o interlaced_source_flag = general_interlaced_source_flag o non_packed_constraint_flag = general_non_packed_constraint_flag o frame_only_constraint_flag = general_frame_only_constraint_flag o reserved_zero_44bits = general_reserved_zero_44bits Otherwise (the RTP stream is a dependee RTP stream), the following applies, with j being the value of the sprop-sub- layer-id parameter: o progressive_source_flag = sub_layer_progressive_source_flag[j] o interlaced_source_flag = sub_layer_interlaced_source_flag[j] o non_packed_constraint_flag = sub_layer_non_packed_constraint_flag[j] o frame_only_constraint_flag = sub_layer_frame_only_constraint_flag[j] o reserved_zero_44bits = sub_layer_reserved_zero_44bits[j] Using interop-constraints for capability exchange results in a requirement on any bitstream to be compliant with the interop- constraints. profile-compatibility-indicator: A base16 [RFC4648] representation of four bytes of data. When profile-compatibility-indicator is used to indicate properties of a bitstream, the following applies, where general_profile_compatibility_flag[j] and sub_layer_profile_compatibility_flag[i][j] are specified in [HEVC]: The profile-compatibility-indicator in this case indicates additional profiles to the profile defined by profile_space, profile_id, and interop-constraints the bitstream conforms to. A decoder that conforms to any of all the profiles the bitstream conforms to would be capable of decoding the bitstream. These additional profiles are defined by profile-space, each set bit of profile- compatibility-indicator, and interop-constraints. If the RTP stream is the highest RTP stream, the following applies for each value of j in the range of 0 to 31, inclusive: o bit j of profile-compatibility-indicator = general_profile_compatibility_flag[j] Otherwise (the RTP stream is a dependee RTP stream), the following applies for i equal to sprop-sub-layer-id and for each value of j in the range of 0 to 31, inclusive: o bit j of profile-compatibility-indicator = sub_layer_profile_compatibility_flag[i][j] Using profile-compatibility-indicator for capability exchange results in a requirement on any bitstream to be compliant with the profile-compatibility-indicator. This is intended to handle cases where any future HEVC profile is defined as an intersection of two or more profiles. If this parameter is not present, this parameter defaults to the following: bit j, with j equal to profile-id, of profile- compatibility-indicator is inferred to be equal to 1, and all other bits are inferred to be equal to 0. sprop-sub-layer-id: This parameter MAY be used to indicate the highest allowed value of TID in the bitstream. When not present, the value of sprop-sub-layer-id is inferred to be equal to 6. The value of sprop-sub-layer-id MUST be in the range of 0 to 6, inclusive. recv-sub-layer-id: This parameter MAY be used to signal a receiver's choice of the offered or declared sub-layer representations in the sprop-vps. The value of recv-sub-layer-id indicates the TID of the highest sub-layer of the bitstream that a receiver supports. When not present, the value of recv-sub-layer-id is inferred to be equal to the value of the sprop-sub-layer-id parameter in the SDP offer. The value of recv-sub-layer-id MUST be in the range of 0 to 6, inclusive. max-recv-level-id: This parameter MAY be used to indicate the highest level a receiver supports. The highest level the receiver supports is equal to the value of max-recv-level-id divided by 30. The value of max-recv-level-id MUST be in the range of 0 to 255, inclusive. When max-recv-level-id is not present, the value is inferred to be equal to level-id. max-recv-level-id MUST NOT be present when the highest level the receiver supports is not higher than the default level. tx-mode: This parameter indicates whether the transmission mode is SSM or MSM. The value of tx-mode MUST be equal to either "MSM" or "SSM". When not present, the value of tx-mode is inferred to be equal to "SSM". If the value is equal to "MSM", MSM MUST be in use. Otherwise (the value is equal to "SSM"), SSM MUST be in use. The value of tx-mode MUST be equal to "MSM" for all RTP sessions in an MSM. sprop-vps: This parameter MAY be used to convey any video parameter set NAL unit of the bitstream for out-of-band transmission of video parameter sets. The parameter MAY also be used for capability exchange and to indicate sub-stream characteristics (i.e. properties of sub-layer representations as defined in [HEVC]). The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the video parameter set NAL units as specified in Section 7.3.2.1 of [HEVC]. The sprop-vps parameter MAY contain one or more than one video parameter set NAL unit. However, all other video parameter sets contained in the sprop-vps parameter MUST be consistent with the first video parameter set in the sprop-vps parameter. A video parameter set vpsB is said to be consistent with another video parameter set vpsA if any decoder that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_id, inclusive, in the first profile_tier_level( ) syntax structure in vpsA can decode any bitstream that conforms to the profile, tier, level, and constraints indicated by the 12 bytes of data starting from the syntax element general_profile_space to the syntax element general_level_id, inclusive, in the first profile_tier_level( ) syntax structure in vpsB. sprop-sps: This parameter MAY be used to convey sequence parameter set NAL units of the bitstream for out-of-band transmission of sequence parameter sets. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of the sequence parameter set NAL units as specified in Section 7.3.2.2 of [HEVC]. sprop-pps: This parameter MAY be used to convey picture parameter set NAL units of the bitstream for out-of-band transmission of picture parameter sets. The value of the parameter is a comma- separated (',') list of base64 [RFC4648] representations of the picture parameter set NAL units as specified in Section 7.3.2.3 of [HEVC]. sprop-sei: This parameter MAY be used to convey one or more SEI messages that describe bitstream characteristics. When present, a decoder can rely on the bitstream characteristics that are described in the SEI messages for the entire duration of the session, independently from the persistence scopes of the SEI messages as specified in [HEVC]. The value of the parameter is a comma-separated (',') list of base64 [RFC4648] representations of SEI NAL units as specified in Section 7.3.2.4 of [HEVC]. Informative note: Intentionally, no list of applicable or inapplicable SEI messages is specified here. Conveying certain SEI messages in sprop-sei may be sensible in some application scenarios and meaningless in others. However, a few examples are described below: 1) In an environment where the bitstream was created from film-based source material, and no splicing is going to occur during the lifetime of the session, the film grain characteristics SEI message or the tone mapping information SEI message are likely meaningful, and sending them in sprop-sei rather than in the bitstream at each entry point may help saving bits and allows to configure the renderer only once, avoiding unwanted artifacts. 2) The structure of pictures information SEI message in sprop-sei can be used to inform a decoder of information on the NAL unit types, picture order count values, and prediction dependencies of a sequence of pictures. Having such knowledge can be helpful for error recovery. 3) Examples for SEI messages that would be meaningless to be conveyed in sprop-sei include the decoded picture hash SEI message (it is close to impossible that all decoded pictures have the same hash-tag), the display orientation SEI message when the device is a handheld device (as the display orientation may change when the handheld device is turned around), or the filler payload SEI message (as there is no point in just having more bits in SDP). max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc: These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. The highest level (specified by max- recv-level-id) MUST be such that the receiver is fully capable of supporting. max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc MAY be used to indicate capabilities of the receiver that extend the required capabilities of the highest level, as specified below. When more than one parameter from the set (max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc) is present, the receiver MUST support all signaled capabilities simultaneously. For example, if both max-lsr and max-br are present, the highest level with the extension of both the picture rate and bitrate is supported. That is, the receiver is able to decode bitstreams in which the luma sample rate is up to max-lsr (inclusive), the bitrate is up to max-br (inclusive), the coded picture buffer size is derived as specified in the semantics of the max-br parameter below, and the other properties comply with the highest level specified by max-recv-level-id. Informative note: When the OPTIONAL media type parameters are used to signal the properties of a bitstream, and max- lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc are not present, the values of profile-space, tier-flag, profile-id, profile-compatibility-indicator, interop- constraints, and level-id must always be such that the bitstream complies fully with the specified profile, tier, and level. max-lsr: The value of max-lsr is an integer indicating the maximum processing rate in units of luma samples per second. The max- lsr parameter signals that the receiver is capable of decoding video at a higher rate than is required by the highest level. When max-lsr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxLumaSR value in Table A-2 of [HEVC] for the highest level is replaced with the value of max-lsr. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the highest level. When not present, the value of max-lsr is inferred to be equal to the value of MaxLumaSR given in Table A-2 of [HEVC] for the highest level. The value of max-lsr MUST be in the range of MaxLumaSR to 16 * MaxLumaSR, inclusive, where MaxLumaSR is given in Table A-2 of [HEVC] for the highest level. max-lps: The value of max-lps is an integer indicating the maximum picture size in units of luma samples. The max-lps parameter signals that the receiver is capable of decoding larger picture sizes than are required by the highest level. When max-lps is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxLumaPS value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-lps. Senders MAY use this knowledge to send larger pictures at a proportionally lower picture rate than is indicated in the highest level. When not present, the value of max-lps is inferred to be equal to the value of MaxLumaPS given in Table A-1 of [HEVC] for the highest level. The value of max-lps MUST be in the range of MaxLumaPS to 16 * MaxLumaPS, inclusive, where MaxLumaPS is given in Table A-1 of [HEVC] for the highest level. max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of CpbBrVclFactor bits for the VCL HRD parameters and in units of CpbBrNalFactor bits for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]. The max- cpb parameter signals that the receiver has more memory than the minimum amount of coded picture buffer memory required by the highest level. When max-cpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxCPB value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-cpb. Senders MAY use this knowledge to construct coded bitstreams with greater variation of bitrate than can be achieved with the MaxCPB value in Table A-1 of [HEVC]. When not present, the value of max-cpb is inferred to be equal to the value of MaxCPB given in Table A-1 of [HEVC] for the highest level. The value of max-cpb MUST be in the range of MaxCPB to 16 * MaxCPB, inclusive, where MaxLumaCPB is given in Table A-1 of [HEVC] for the highest level. Informative note: The coded picture buffer is used in the hypothetical reference decoder (Annex C of HEVC). The use of the hypothetical reference decoder is recommended in HEVC encoders to verify that the produced bitstream conforms to the standard and to control the output bitrate. Thus, the coded picture buffer is conceptually independent of any other potential buffers in the receiver, including de-packetization and de-jitter buffers. The coded picture buffer need not be implemented in decoders as specified in Annex C of HEVC, but rather standard-compliant decoders can have any buffering arrangements provided that they can decode standard-compliant bitstreams. Thus, in practice, the input buffer for a video decoder can be integrated with de-packetization and de-jitter buffers of the receiver. max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units decoded pictures at the MaxLumaPS for the highest level, i.e. the number of decoded pictures at the maximum picture size defined by the highest level. The value of max-dpb MUST be in the range of 1 to 16, respectively. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by default, which is MaxDpbPicBuf as defined in [HEVC] (equal to 6). When max-dpb is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxDpbPicBuff value defined in [HEVC] as 6 is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded pictures (MaxDpbSize) in its decoded picture buffer: if( PicSizeInSamplesY <= ( MaxLumaPS >> 2 ) ) MaxDpbSize = Min( 4 * max-dpb, 16 ) else if ( PicSizeInSamplesY <= ( MaxLumaPS >> 1 ) ) MaxDpbSize = Min( 2 * max-dpb, 16 ) else if ( PicSizeInSamplesY <= ( ( 3 * MaxLumaPS ) >> 2 ) ) MaxDpbSize = Min( (4 * max-dpb) / 3, 16 ) else MaxDpbSize = max-dpb Wherein MaxLumaPS given in Table A-1 of [HEVC] for the highest level and PicSizeInSamplesY is the current size of each decoded picture in units of luma samples as defined in [HEVC]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbPicBuf (i.e. 6) as defined in [HEVC]. Senders MAY use this knowledge to construct coded bitstreams with improved compression. When not present, the value of max-dpb is inferred to be equal to the value of MaxDpbPicBuf (i.e. 6) as defined in [HEVC]. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de- packetization and de-jitter buffers. max-br: The value of max-br is an integer indicating the maximum video bitrate in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters, where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]. The max-br parameter signals that the video decoder of the receiver is capable of decoding video at a higher bitrate than is required by the highest level. When max-br is signaled, the video codec of the receiver MUST be able to decode bitstreams that conform to the highest level, with the following exceptions in the limits specified by the highest level: o The value of max-br replaces the MaxBR value in Table A-2 of [HEVC] for the highest level. o When the max-cpb parameter is not present, the result of the following formula replaces the value of MaxCPB in Table A-1 of [HEVC]: (MaxCPB of the highest level) * max-br / (MaxBR of the highest level) For example, if a receiver signals capability for Main profile Level 2 with max-br equal to 2000, this indicates a maximum video bitrate of 2000 kbits/sec for VCL HRD parameters, a maximum video bitrate of 2200 kbits/sec for NAL HRD parameters, and a CPB size of 2000000 bits (2000000 / 1500000 * 1500000). Senders MAY use this knowledge to send higher bitrate video as allowed in the level definition of Annex A of HEVC to achieve improved video quality. When not present, the value of max-br is inferred to be equal to the value of MaxBR given in Table A-2 of [HEVC] for the highest level. The value of max-br MUST be in the range of MaxBR to 16 * MaxBR, inclusive, where MaxBR is given in Table A-2 of [HEVC] for the highest level. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The assumption that the network is capable of handling such bitrates at any given time cannot be made from the value of this parameter. In particular, no conclusion can be drawn that the signaled bitrate is possible under congestion control constraints. max-tr: The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than the value allowed by the highest level. When max-tr is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tr. Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than the value allowed by the highest level. When not present, the value of max-tr is inferred to be equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level. The value of max-tr MUST be in the range of MaxTileRows to 16 * MaxTileRows, inclusive, where MaxTileRows is given in Table A-1 of [HEVC] for the highest level. max-tc: The value of max-tc is an integer indication the maximum number of tile columns. The max-tc parameter signals that the receiver is capable of decoding video with a larger number of tile columns than the value allowed by the highest level. When max-tc is signaled, the receiver MUST be able to decode bitstreams that conform to the highest level, with the exception that the MaxTileCols value in Table A-1 of [HEVC] for the highest level is replaced with the value of max-tc. Senders MAY use this knowledge to send pictures utilizing a larger number of tile columns than the value allowed by the highest level. When not present, the value of max-tc is inferred to be equal to the value of MaxTileCols given in Table A-1 of [HEVC] for the highest level. The value of max-tc MUST be in the range of MaxTileCols to 16 * MaxTileCols, inclusive, where MaxTileCols is given in Table A-1 of [HEVC] for the highest level. max-fps: The value of max-fps is an integer indicating the maximum picture rate in units of pictures per 100 seconds that can be effectively processed by the receiver. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of processing video effectively at the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br. The value of max-fps is not necessarily the picture rate at which the maximum picture size can be sent, it constitutes a constraint on maximum picture rate for all resolutions. Informative note: The max-fps parameter is semantically different from max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps is used to signal a constraint, lowering the maximum picture rate from what is implied by other parameters. The encoder MUST use a picture rate equal to or less than this value. In cases where the max-fps parameter is absent the encoder is free to choose any picture rate according to the highest level and any signaled optional parameters. The value of max-fps MUST be smaller than or equal to the full picture rate that is implied by the highest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br. sprop-max-don-diff: The value of this parameter MUST be equal to 0, if the RTP stream does not depend on other RTP streams and there is no NAL unit naluA that is followed in transmission order by any NAL unit preceding naluA in decoding order. Otherwise, this parameter specifies the maximum absolute difference between the decoding order number (i.e., AbsDon) values of any two NAL units naluA and naluB, where naluA follows naluB in decoding order and precedes naluB in transmission order. The value of sprop-max-don-diff MUST be an integer in the range of 0 to 32767, inclusive. When not present, the value of sprop-max-don-diff is inferred to be equal to 0. When the RTP stream depends on one or more other RTP streams (in this case tx-mode MUST be equal to "MSM" and MSM is in use), this parameter MUST be present and the value MUST be greater than 0. Informative note: When the RTP stream does not depend on other RTP streams, either MSM or SSM may be in use. sprop-depack-buf-nalus: This parameter specifies the maximum number of NAL units that precede a NAL unit in transmission order and follow the NAL unit in decoding order. The value of sprop-depack-buf-nalus MUST be an integer in the range of 0 to 32767, inclusive. When not present, the value of sprop-depack-buf-nalus is inferred to be equal to 0. When the RTP stream depends on one or more other RTP streams (in this case tx-mode MUST be equal to "MSM" and MSM is in use), this parameter MUST be present and the value MUST be greater than 0. sprop-depack-buf-bytes: This parameter signals the required size of the de- packetization buffer in units of bytes. The value of the parameter MUST be greater than or equal to the maximum buffer occupancy (in units of bytes) of the de-packetization buffer as specified in section 6. The value of sprop-depack-buf-bytes MUST be an integer in the range of 0 to 4294967295, inclusive. When the RTP stream depends on one or more other RTP streams (in this case tx-mode MUST be equal to "MSM" and MSM is in use) or sprop-max-don-diff is present and greater than 0, this parameter MUST be present and the value MUST be greater than 0. Informative note: The value of sprop-depack-buf-bytes indicates the required size of the de-packetization buffer only. When network jitter can occur, an appropriately sized jitter buffer has to be available as well. depack-buf-cap: This parameter signals the capabilities of a receiver implementation and indicates the amount of de-packetization buffer space in units of bytes that the receiver has available for reconstructing the NAL unit decoding order from NAL units carried in one or more RTP streams. A receiver is able to handle any RTP stream, and all RTP streams the RTP stream depends on, when present, for which the value of the sprop- depack-buf-bytes parameter is smaller than or equal to this parameter. When not present, the value of depack-buf-cap is inferred to be equal to 4294967295. The value of depack-buf-cap MUST be an integer in the range of 1 to 4294967295, inclusive. Informative note: depack-buf-cap indicates the maximum possible size of the de-packetization buffer of the receiver only. When network jitter can occur, an appropriately sized jitter buffer has to be available as well. sprop-segmentation-id: This parameter MAY be used to signal the segmentation tools present in the bitstream and that can be used for parallelization. The value of sprop-segmentation-id MUST be an integer in the range of 0 to 3, inclusive. When not present, the value of sprop-segmentation-id is inferred to be equal to 0. When sprop-segmentation-id is equal to 0, no information about the segmentation tools is provided. When sprop-segmentation- id is equal to 1, it indicates that slices are present in the bitstream. When sprop-segmentation-id is equal to 2, it indicates that tiles are present in the bitstream. When sprop-segmentation-id is equal to 3, it indicates that WPP is used in the bitstream. sprop-spatial-segmentation-idc: A base16 [RFC4648] representation of the syntax element min_spatial_segmentation_idc as specified in [HEVC]. This parameter MAY be used to describe parallelization capabilities of the bitstream. dec-parallel-cap: This parameter MAY be used to indicate the decoder's additional decoding capabilities given the presence of tools enabling parallel decoding, such as slices, tiles, and WPP, in the bitstream. The decoding capability of the decoder may vary with the setting of the parallel decoding tools present in the bitstream, e.g. the size of the tiles that are present in a bitstream. Therefore, multiple capability points may be provided, each indicating the minimum required decoding capability that is associated with a parallelism requirement, which is a requirement on the bitstream that enables parallel decoding. Each capability point is defined as a combination of 1) a parallelism requirement, 2) a profile (determined by profile- space and profile-id), 3) a highest level, and 4) a maximum processing rate, a maximum picture size, and a maximum video bitrate that may be equal to or greater than that determined by the highest level. The parameter's syntax in ABNF [RFC5234] is as follows: dec-parallel-cap = "dec-parallel-cap={" cap-point *("," cap-point) "}" cap-point = ("w" / "t") ":" spatial-seg-idc 1*(";" cap-parameter) spatial-seg-idc = 1*4DIGIT ; (1-4095) cap-parameter = tier-flag / level-id / max-lsr / max-lps / max-br tier-flag = "tier-flag" EQ ("0" / "1") level-id = "level-id" EQ 1*3DIGIT ; (0-255) max-lsr = "max-lsr" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615) max-lps = "max-lps" EQ 1*10DIGIT ; (0-4,294,967,295) max-br = "max-br" EQ 1*20DIGIT ; (0- 18,446,744,073,709,551,615) EQ = "=" The set of capability points expressed by the dec-parallel-cap parameter is enclosed in a pair of curly braces ("{}"). Each set of two consecutive capability points is separated by a comma (','). Within each capability point, each set of two consecutive parameters, and when present, their values, is separated by a semicolon (';'). The profile of all capability points is determined by profile- space and profile-id that are outside the dec-parallel-cap parameter. Each capability point starts with an indication of the parallelism requirement, which consists of a parallel tool type, which may be equal to 'w' or 't', and a decimal value of the spatial-seg-idc parameter. When the type is 'w', the capability point is valid only for H.265 bitstreams with WPP in use, i.e. entropy_coding_sync_enabled_flag equal to 1. When the type is 't', the capability point is valid only for H.265 bitstreams with WPP not in use (i.e. entropy_coding_sync_enabled_flag equal to 0). The capability- point is valid only for H.265 bitstreams with min_spatial_segmentation_idc equal to or greater than spatial- seg-idc. After the parallelism requirement indication, each capability point continues with one or more pairs of parameter and value in any order for any of the following parameters: o tier-flag o level-id o max-lsr o max-lps o max-br At most one occurrence of each of the above five parameters is allowed within each capability point. The values of dec-parallel-cap.tier-flag and dec-parallel- cap.level-id for a capability point indicate the highest level of the capability point. The values of dec-parallel-cap.max- lsr, dec-parallel-cap.max-lps, and dec-parallel-cap.max-br for a capability point indicate the maximum processing rate in units of luma samples per second, the maximum picture size in units of luma samples, and the maximum video bitrate (in units of CpbBrVclFactor bits per second for the VCL HRD parameters and in units of CpbBrNalFactor bits per second for the NAL HRD parameters where CpbBrVclFactor and CpbBrNalFactor are defined in Section A.4 of [HEVC]). When not present, the value of dec-parallel-cap.tier-flag is inferred to be equal to the value of tier-flag outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.level-id is inferred to be equal to the value of max-recv-level-id outside the dec-parallel-cap parameter. When not present, the value of dec-parallel-cap.max-lsr, dec- parallel-cap.max-lps, or dec-parallel-cap.max-br is inferred to be equal to the value of max-lsr, max-lps, or max-br, respectively, outside the dec-parallel-cap parameter. The general decoding capability, expressed by the set of parameters outside of dec-parallel-cap, is defined as the capability point that is determined by the following combination of parameters: 1) the parallelism requirement corresponding to the value of sprop-segmentation-id equal to 0 for a bitstream, 2) the profile determined by profile-space, profile-id, profile-compatibility-indicator, and interop- constraints, 3) the tier and the highest level determined by tier-flag and max-recv-level-id, and 4) the maximum processing rate, the maximum picture size, and the maximum video bitrate determined by the highest level. The general decoding capability MUST NOT be included as one of the set of capability points in the dec-parallel-cap parameter. For example, the following parameters express the general decoding capability of 720p30 (Level 3.1) plus an additional decoding capability of 1080p30 (Level 4) given that the spatially largest tile or slice used in the bitstream is equal to or less than 1/3 of the picture size: a=fmtp:98 level-id=93;dec-parallel-cap={t:8;level-id=120} For another example, the following parameters express an additional decoding capability of 1080p30, using dec-parallel- cap.max-lsr and dec-parallel-cap.max-lps, given that WPP is used in the bitstream: a=fmtp:98 level-id=93;dec-parallel-cap={w:8; max-lsr=62668800;max-lps=2088960} Informative note: When min_spatial_segmentation_idc is present in a bitstream and WPP is not used, [HEVC] specifies that there is no slice or no tile in the bitstream containing more than 4 * PicSizeInSamplesY / ( min_spatial_segmentation_idc + 4 ) luma samples. include-dph: This parameter is used to indicate the capability and preference to utilize or include decoded picture hash (DPH) SEI messages (See Section D.3.19 of [HEVC]) in the bitstream. DPH SEI messages can be used to detect picture corruption so the receiver can request picture repair, see Section 8. The value is a comma separated list of hash types that is supported or requested to be used, each hash type provided as an unsigned integer value (0-255), with the hash types listed from most preferred to the least preferred. Example: "include-dph=0,2", which indicates the capability for MD5 (most preferred) and Checksum (less preferred). If the parameter is not included or the value contains no hash types, then no capability to utilize DPH SEI messages is assumed. Note that DPH SEI messages MAY still be included in the bitstream even when there is no declaration of capability to use them, as in general SEI messages do not affect the normative decoding process and decoders are allowed to ignore SEI messages. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See Section 9 of RFC XXXX. Public specification: Please refer to Section 13 of RFC XXXX. Additional information: None File extensions: none Macintosh file type code: none Object identifier or OID: none Person & email address to contact for further information: Intended usage: COMMON Author: See Section 14 of RFC XXXX. Change controller: IETF Audio/Video Transport Payloads working group delegated from the IESG. ------=_NextPart_000_0019_01CFC388.1D199C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

draft-=
ietf-payload-rtp-h265-04  is =
in Working Group Last Call in the Payload Working Group. =

The =
document registers media subtype H265.  =

 =

The new =
registrations are in Section 7.1 of the document and is also given =
bellow.
 

Comments on the registration are = welcome.

 

Thanks

Roni = Even

Payload WG = co-chair

 

Media = Type name:     video

 

   Media subtype name:  = H265

 

   Required parameters: = none

 

   OPTIONAL = parameters:

 

      profile-space, = tier-flag, profile-id, profile-compatibility-

      indicator, = interop-constraints, and level-id:

 

         These = parameters indicate the profile, tier, default = level,

         and = some constraints of the bitstream carried by the = RTP

         = stream and all RTP streams the RTP stream depends on, or = a

         = specific set of the profile, tier, default level, and = some

         = constraints the receiver supports.

 

         The = profile and some constraints are indicated collectively = by

         = profile-space, profile-id, = profile-compatibility-indicator,

         and = interop-constraints.  The profile specifies the subset = of

         = coding tools that may have been used to generate the = bitstream

         or = that the receiver supports.

 

         &= nbsp;  Informative note: There are 32 values of profile-id, = and

         &= nbsp;  there are 32 flags in profile-compatibility-indicator, = each

         &= nbsp;  flag corresponding to one value of profile-id.  = According

         &= nbsp;  to HEVC version 1 in [HEVC], when more than one of the = 32

         &= nbsp;  flags is set for a bitstream, the bitstream would = comply

         &= nbsp;  with all the profiles corresponding to the set = flags.

         &= nbsp;  However, in a draft of HEVC version 2 in [HEVC draft = v2],

         &= nbsp;  subclause A.3.5, 19 Format Range Extensions profiles = have

         &= nbsp;  been specified, all using the same value of profile-id = (4),

         &= nbsp;  differentiated by some of the 48 bits in = interop-

         &= nbsp;  constraints - this (rather unexpected way of = profile

         &= nbsp;  signalling) means that one of the 32 flags may = correspond

         &= nbsp;  to multiple profiles.  To be able to support whatever = HEVC

         &= nbsp;  extension profile that might be specified and = indicated

         &= nbsp;  using profile-space, profile-id, = profile-compatibility-

         &= nbsp;  indicator, and interop-constraints in the future, it = would

         &= nbsp;  be safe to require symmetric use of these parameters in = SDP

         &= nbsp;  offer/answer unless recv-sub-layer-id is included in = the

         &= nbsp;  SDP answer for choosing one of the sub-layers = offered.

 

         The = tier is indicated by tier-flag.  The default level = is

         = indicated by level-id.  The tier and the default level = specify

         the = limits on values of syntax elements or = arithmetic

         = combinations of values of syntax elements that are = followed

         when = generating the bitstream or that the receiver = supports.

 

         A set = of profile-space, tier-flag, profile-id, = profile-

         = compatibility-indicator, interop-constraints, and = level-id

         = parameters ptlA is said to be consistent with another set = of

         these = parameters ptlB if any decoder that conforms to = the

         = profile, tier, level, and constraints indicated by ptlB = can

         = decode any bitstream that conforms to the profile, = tier,

         = level, and constraints indicated by ptlA.

 

         In = SDP offer/answer, when the SDP answer does not include = the

         = recv-sub-layer-id parameter that is less than the = sprop-sub-

         = layer-id parameter in the SDP offer, the following = applies:

 

     =        o The profile-space, = tier-flag, profile-id, profile-

         &= nbsp;    compatibility-indicator, and = interop-constraints

         &= nbsp;    parameters MUST be used symmetrically, i.e. the = value of

         &= nbsp;    each of these parameters in the offer MUST be = the same as

         &= nbsp;    that in the answer, either explicitly signalled = or

         &= nbsp;    implicitly inferred.

         &= nbsp;  o The level-id parameter is changeable as long as = the

         &= nbsp;    highest level indicated by the answer is either = equal to

         =      or lower than that in the offer.  = Note that the highest

         &= nbsp;    level is indicated by level-id and = max-recv-level-id

         &= nbsp;    together.

 

         In = SDP offer/answer, when the SDP answer does include = the

         = recv-sub-layer-id parameter that is less than the = sprop-sub-

         = layer-id parameter in the SDP offer, the set of = profile-space,

         = tier-flag, profile-id, = profile-compatibility-indicator,

         = interop-constraints, and level-id parameters included in = the

         = answer MUST be consistent with that for the chosen = sub-layer

         = representation as indicated in the SDP offer, with = the

         = exception that the level-id parameter in the SDP answer = is

         = changable as long as the highest level indicated by the = answer

         is = either lower than or equal to that in the offer.

 

         More = specifications of these parameters, including how = they

         = relate to the values of the profile, tier, and level = syntax

         = elements specified in [HEVC] are provided below.

 

      profile-space, = profile-id:

 

         The = value of profile-space MUST be in the range of 0 to = 3,

         = inclusive.  The value of profile-id MUST be in the range of = 0

         to = 31, inclusive.

 

         When = profile-space is not present, a value of 0 MUST = be

         = inferred.  When profile-id is not present, a value of 1 = (i.e.

         the = Main profile) MUST be inferred.

 

         When = used to indicate properties of a bitstream, = profile-space

         and = profile-id are derived from the profile, tier, and = level

         = syntax elements in SPS or VPS NAL units as follows, = where

         = general_profile_space, general_profile_idc,

         = sub_layer_profile_space[j], and sub_layer_profile_idc[j] = are

         = specified in [HEVC]:

 

          =   If the RTP stream is the highest RTP stream, the = following

         &= nbsp;  applies:

 

         &= nbsp;  o profile_space =3D = general_profile_space

         &= nbsp;  o profile_id =3D general_profile_idc

 

         &= nbsp;  Otherwise (the RTP stream is a dependee RTP stream), = the

    =         following applies, with = j being the value of the sprop-sub-

         &= nbsp;  layer-id parameter:

 

         &= nbsp;  o profile_space =3D = sub_layer_profile_space[j]

         &= nbsp;  o profile_id =3D = sub_layer_profile_idc[j]

 

      tier-flag, = level-id:

 

         The = value of tier-flag MUST be in the range of 0 to = 1,

         = inclusive.  The value of level-id MUST be in the range of = 0

         to = 255, inclusive.

 

         If = the tier-flag and level-id parameters are used to = indicate

         = properties of a bitstream, they indicate the tier and = the

         = highest level the bitstream complies with.

 

         If = the tier-flag and level-id parameters are used = for

         = capability exchange, the following applies.  If = max-recv-

         = level-id is not present, the default level defined by = level-id

         = indicates the highest level the codec wishes to = support.

         = Otherwise, max-recv-level-id indicates the highest level = the

         codec = supports for receiving.  For either receiving = or

         = sending, all levels that are lower than the highest = level

         = supported MUST also be supported.

 

         If no = tier-flag is present, a value of 0 MUST be inferred = and

         if no = level-id is present, a value of 93 (i.e. level 3.1) = MUST

         be = inferred.

 

         When = used to indicate properties of a bitstream, the = tier-flag

         and = level-id parameters are derived from the profile, = tier,

         and = level syntax elements in SPS or VPS NAL units as = follows,

         where = general_tier_flag, general_level_idc,

         = sub_layer_tier_flag[j], and sub_layer_level_idc[j] = are

         = specified in [HEVC]:

 

         &= nbsp;  If the RTP stream is the highest RTP stream, the = following

         &= nbsp;  applies:

 

         &= nbsp;  o tier-flag =3D general_tier_flag

         =    o level-id =3D = general_level_idc

 

         &= nbsp;  Otherwise (the RTP stream is a dependee RTP stream), = the

         &= nbsp;  following applies, with j being the value of the = sprop-sub-

         &= nbsp;  layer-id parameter:

 

         &= nbsp;  o tier-flag =3D = sub_layer_tier_flag[j]

         &= nbsp;  o level-id =3D = sub_layer_level_idc[j]

 

      = interop-constraints:

 

         A = base16 [RFC4648] (hexadecimal) representation of six = bytes

         of = data, consisting of progressive_source_flag,

         = interlaced_source_flag, = non_packed_constraint_flag,

         = frame_only_constraint_flag, and = reserved_zero_44bits.

 

         If = the interop-constraints parameter is not present, = the

         = following MUST be inferred:

 

         &= nbsp;  o progressive_source_flag =3D 1

         &= nbsp;  o interlaced_source_flag =3D 0

         &= nbsp;  o non_packed_constraint_flag =3D 1

         &= nbsp;  o frame_only_constraint_flag =3D 1

         &= nbsp;  o reserved_zero_44bits =3D 0

 

         When = the interop-constraints parameter is used to = indicate

         = properties of a bitstream, the following applies, = where

         = general_progressive_source_flag,

         = general_interlaced_source_flag,

         = general_non_packed_constraint_flag,

         = general_non_packed_constraint_flag,

         = general_frame_only_constraint_flag,

         = general_reserved_zero_44bits,

         = sub_layer_progressive_source_flag[j],

         = sub_layer_interlaced_source_flag[j],

         = sub_layer_non_packed_constraint_flag[j],

         = sub_layer_frame_only_constraint_flag[j], and

         = sub_layer_reserved_zero_44bits[j] are specified in = [HEVC]:

 

         &= nbsp;  If the RTP stream is the highest RTP stream, the = following

         &= nbsp;  applies:

 

         &= nbsp;  o progressive_source_flag =3D = general_progressive_source_flag

         &= nbsp;  o interlaced_source_flag =3D = general_interlaced_source_flag

         &= nbsp;  o non_packed_constraint_flag =3D

         &= nbsp;           &n= bsp;        = general_non_packed_constraint_flag

         &= nbsp;  o frame_only_constraint_flag =3D

         &= nbsp;           &n= bsp;        = general_frame_only_constraint_flag

          =   o reserved_zero_44bits =3D = general_reserved_zero_44bits

 

         &= nbsp;  Otherwise (the RTP stream is a dependee RTP stream), = the

         &= nbsp;  following applies, with j being the value of the = sprop-sub-

         &= nbsp;  layer-id parameter:

 

         &= nbsp;  o progressive_source_flag =3D

         &= nbsp;           &n= bsp;        = sub_layer_progressive_source_flag[j]

         &= nbsp;  o interlaced_source_flag =3D

         &= nbsp;           &n= bsp;        = sub_layer_interlaced_source_flag[j]

         &= nbsp;  o non_packed_constraint_flag =3D

         &= nbsp;           &n= bsp;    =     sub_layer_non_packed_constraint_flag[j]

         &= nbsp;  o frame_only_constraint_flag =3D

         &= nbsp;           &n= bsp;        = sub_layer_frame_only_constraint_flag[j]

         &= nbsp;  o reserved_zero_44bits =3D = sub_layer_reserved_zero_44bits[j]

 

         Using = interop-constraints for capability exchange results in = a

         = requirement on any bitstream to be compliant with the = interop-

         = constraints.

 

      = profile-compatibility-indicator:

 

         A = base16 [RFC4648] representation of four bytes of = data.

 

         When = profile-compatibility-indicator is used to = indicate

         = properties of a bitstream, the following applies, = where

         = general_profile_compatibility_flag[j] and

         = sub_layer_profile_compatibility_flag[i][j] are specified = in

         = [HEVC]:

 

         &= nbsp;  The profile-compatibility-indicator in this case = indicates

         &= nbsp;  additional profiles to the profile defined = by

         &= nbsp;  profile_space, profile_id, and interop-constraints = the

         &= nbsp;  bitstream conforms to.  A decoder that conforms to any = of

         &= nbsp;  all the profiles the bitstream conforms to would be = capable

         &= nbsp;  of decoding the bitstream.  These additional profiles = are

         &= nbsp;  defined by profile-space, each set bit of = profile-

         &= nbsp;  compatibility-indicator, and = interop-constraints.

 

         &= nbsp;  If the RTP stream is the highest RTP stream, the = following

         &= nbsp;  applies for each value of j in the range of 0 to = 31,

         &= nbsp;  inclusive:

 

         &= nbsp;  o bit j of profile-compatibility-indicator = =3D

        =           general_profi= le_compatibility_flag[j]

 

         &= nbsp;  Otherwise (the RTP stream is a dependee RTP stream), = the

         &= nbsp;  following applies for i equal to sprop-sub-layer-id and = for

         &= nbsp;  each value of j in the range of 0 to 31, = inclusive:

 

         &= nbsp; o bit j of profile-compatibility-indicator = =3D

         &= nbsp;        = sub_layer_profile_compatibility_flag[i][j]

 

         Using = profile-compatibility-indicator for capability = exchange

         = results in a requirement on any bitstream to be compliant = with

         the = profile-compatibility-indicator.  This is intended = to

         = handle cases where any future HEVC profile is defined as = an

         = intersection of two or more profiles.

 

         If = this parameter is not present, this parameter defaults = to

         the = following: bit j, with j equal to profile-id, of = profile-

         = compatibility-indicator is inferred to be equal to 1, and = all

         other = bits are inferred to be equal to 0.

 

      = sprop-sub-layer-id:

 

         This = parameter MAY be used to indicate the highest = allowed

         value = of TID in the bitstream.  When not present, the value = of

         = sprop-sub-layer-id is inferred to be equal to 6.

 

         The = value of sprop-sub-layer-id MUST be in the range of = 0

         to 6, = inclusive.

 

      = recv-sub-layer-id:

 

         This = parameter MAY be used to signal a receiver's choice = of

         the = offered or declared sub-layer representations in = the

         = sprop-vps.  The value of recv-sub-layer-id indicates the = TID

         of = the highest sub-layer of the bitstream that a = receiver

         = supports.  When not present, the value of recv-sub-layer-id = is

         = inferred to be equal to the value of the = sprop-sub-layer-id

         = parameter in the SDP offer.

 

         The = value of recv-sub-layer-id MUST be in the range of 0 to = 6,

         = inclusive.

 

      = max-recv-level-id:

 

         This = parameter MAY be used to indicate the highest level = a

         = receiver supports.  The highest level the receiver supports = is

         equal = to the value of max-recv-level-id divided by 30.

 

         The = value of max-recv-level-id MUST be in the range of = 0

         to = 255, inclusive.

 

         When = max-recv-level-id is not present, the value is = inferred

         to be = equal to level-id.

 

       =   max-recv-level-id MUST NOT be present when the highest = level

         the = receiver supports is not higher than the default = level.

 

      = tx-mode:

 

         This = parameter indicates whether the transmission mode is = SSM

         or = MSM.

         The = value of tx-mode MUST be equal to either "MSM" or = "SSM".

         When = not present, the value of tx-mode is inferred to be = equal

         to = "SSM".

 

         If = the value is equal to "MSM", MSM MUST be in use.  = Otherwise

         (the = value is equal to "SSM"), SSM MUST be in = use.

 

         The = value of tx-mode MUST be equal to "MSM" for all = RTP

         = sessions in an MSM.

 

      = sprop-vps:

 

         This = parameter MAY be used to convey any video parameter = set

         NAL = unit of the bitstream for out-of-band transmission = of

         video = parameter sets.  The parameter MAY also be used = for

         = capability exchange and to indicate sub-stream = characteristics

         (i.e. = properties of sub-layer representations as defined = in

         = [HEVC]).  The value of the parameter is a = comma-separated

         (',') = list of base64 [RFC4648] representations of the = video

         = parameter set NAL units as specified in Section 7.3.2.1 = of

         = [HEVC].

 

         The = sprop-vps parameter MAY contain one or more than one = video

         = parameter set NAL unit. However, all other video = parameter

         sets = contained in the sprop-vps parameter MUST be = consistent

         with = the first video parameter set in the sprop-vps = parameter.

         A = video parameter set vpsB is said to be consistent = with

         = another video parameter set vpsA if any decoder that = conforms

         to = the profile, tier, level, and constraints indicated by = the

         12 = bytes of data starting from the syntax element

         = general_profile_space to the syntax element = general_level_id,

         = inclusive, in the first profile_tier_level( ) syntax = structure

         in = vpsA can decode any bitstream that conforms to the = profile,

         tier, = level, and constraints indicated by the 12 bytes of = data

         = starting from the syntax element general_profile_space to = the

         = syntax element general_level_id, inclusive, in the = first

         = profile_tier_level( ) syntax structure in vpsB.

      = sprop-sps:

 

         This = parameter MAY be used to convey sequence parameter = set

         NAL = units of the bitstream for out-of-band transmission = of

         = sequence parameter sets.  The value of the parameter is = a

         = comma-separated (',') list of base64 [RFC4648] = representations

         of = the sequence parameter set NAL units as specified = in

         = Section 7.3.2.2 of [HEVC].

 

      = sprop-pps:

 

         This = parameter MAY be used to convey picture parameter set = NAL

         units = of the bitstream for out-of-band transmission of = picture

         = parameter sets.  The value of the parameter is a = comma-

         = separated (',') list of base64 [RFC4648] representations = of

         the = picture parameter set NAL units as specified in = Section

   =       7.3.2.3 of = [HEVC].

 

      = sprop-sei:

 

         This = parameter MAY be used to convey one or more SEI = messages

         that = describe bitstream characteristics.  When present, = a

         = decoder can rely on the bitstream characteristics that = are

      =    described in the SEI messages for the entire duration = of the

         = session, independently from the persistence scopes of the = SEI

         = messages as specified in [HEVC].

 

         The = value of the parameter is a comma-separated (',') list = of

       =   base64 [RFC4648] representations of SEI NAL units as = specified

         in = Section 7.3.2.4 of [HEVC].

 

         &= nbsp;  Informative note: Intentionally, no list of applicable = or

         &= nbsp;  inapplicable SEI messages is specified here.  = Conveying

         &= nbsp;  certain SEI messages in sprop-sei may be sensible in = some

         &= nbsp;  application scenarios and meaningless in others.  = However,

         &= nbsp;  a few examples are described below:

 

         &= nbsp; 1) In an environment where the bitstream was created = from

         =       film-based source material, and no = splicing is going to

         &= nbsp;     occur during the lifetime of the session, = the film grain

         &= nbsp;     characteristics SEI message or the tone = mapping

         &= nbsp;     information SEI message are likely = meaningful, and

         &= nbsp;     sending them in sprop-sei rather than in = the bitstream

         &= nbsp;     at each entry point may help saving bits = and allows to

         &= nbsp;     configure the renderer only once, avoiding = unwanted

         &= nbsp;     artifacts.

         &= nbsp; 2) The structure of pictures information SEI message = in

         &= nbsp;     sprop-sei can be used to inform a decoder = of information

         &= nbsp;     on the NAL unit types, picture order count = values, and

         &= nbsp;     prediction dependencies of a sequence of = pictures.

         &= nbsp;     Having such knowledge can be helpful for = error recovery.

         &= nbsp; 3) Examples for SEI messages that would be meaningless = to

         &= nbsp;     be conveyed in sprop-sei include the = decoded picture

         &= nbsp;     hash SEI message (it is close to = impossible that all

         &= nbsp;     decoded pictures have the same hash-tag), = the display

         &= nbsp;     orientation SEI message when the device is = a handheld

         &= nbsp;     device (as the display orientation may = change when the

         &= nbsp;     handheld device is turned around), or the = filler payload

         &= nbsp;     SEI message (as there is no point in just = having more

         &= nbsp;     bits in SDP).

 

      max-lsr, max-lps, = max-cpb, max-dpb, max-br, max-tr, max-tc:

 

         These = parameters MAY be used to signal the capabilities of = a

         = receiver implementation.  These parameters MUST NOT be = used

         for = any other purpose.  The highest level (specified by = max-

         = recv-level-id) MUST be such that the receiver is fully = capable

        of = supporting.  max-lsr, max-lps, max-cpb, max-dpb, = max-br,

         = max-tr, and max-tc MAY be used to indicate capabilities of = the

         = receiver that extend the required capabilities of the = highest

         = level, as specified below.

 

         When = more than one parameter from the set (max-lsr, = max-lps,

         = max-cpb, max-dpb, max-br, max-tr, max-tc) is present, = the

         = receiver MUST support all signaled capabilities

         = simultaneously.  For example, if both max-lsr and max-br = are

         = present, the highest level with the extension of both = the

         = picture rate and bitrate is supported.  That is, the = receiver

         is = able to decode bitstreams in which the luma sample rate = is

         up to = max-lsr (inclusive), the bitrate is up to max-br

         = (inclusive), the coded picture buffer size is derived = as

         = specified in the semantics of the max-br parameter below, = and

         the = other properties comply with the highest level = specified

         by = max-recv-level-id.

 

         &= nbsp;  Informative note: When the OPTIONAL media type = parameters

         &= nbsp;  are used to signal the properties of a bitstream, and = max-

         &= nbsp;  lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and = max-tc

         &= nbsp;  are not present, the values of profile-space, = tier-flag,

         &= nbsp;  profile-id, profile-compatibility-indicator, = interop-

         &= nbsp;  constraints, and level-id must always be such that = the

         &= nbsp;  bitstream complies fully with the specified profile, = tier,

         &= nbsp;  and level.

 

   =    max-lsr:

         The = value of max-lsr is an integer indicating the = maximum

         = processing rate in units of luma samples per second.  The = max-

         lsr = parameter signals that the receiver is capable of = decoding

         video = at a higher rate than is required by the highest = level.

 

         When = max-lsr is signaled, the receiver MUST be able to = decode

         = bitstreams that conform to the highest level, with = the

         = exception that the MaxLumaSR value in Table A-2 of [HEVC] = for

         the = highest level is replaced with the value of = max-lsr.

         = Senders MAY use this knowledge to send pictures of a = given

         size = at a higher picture rate than is indicated in the = highest

         = level.

 

         When = not present, the value of max-lsr is inferred to be = equal

         to = the value of MaxLumaSR given in Table A-2 of [HEVC] for = the

         = highest level.

 

         The = value of max-lsr MUST be in the range of MaxLumaSR = to

         16 * = MaxLumaSR, inclusive, where MaxLumaSR is given in = Table

         A-2 = of [HEVC] for the highest level.

 

      = max-lps:

         The = value of max-lps is an integer indicating the = maximum

         = picture size in units of luma samples.  The max-lps = parameter

         = signals that the receiver is capable of decoding = larger

         = picture sizes than are required by the highest level.  = When

         = max-lps is signaled, the receiver MUST be able to = decode

         = bitstreams that conform to the highest level, with = the

         = exception that the MaxLumaPS value in Table A-1 of [HEVC] = for

         the = highest level is replaced with the value of = max-lps.

         = Senders MAY use this knowledge to send larger pictures at = a

         = proportionally lower picture rate than is indicated in = the

       =   highest level.

 

         When = not present, the value of max-lps is inferred to be = equal

         to = the value of MaxLumaPS given in Table A-1 of [HEVC] for = the

         = highest level.

 

         The = value of max-lps MUST be in the range of MaxLumaPS = to

  =        16 * MaxLumaPS, inclusive, = where MaxLumaPS is given in Table

         A-1 = of [HEVC] for the highest level.

 

      = max-cpb:

         The = value of max-cpb is an integer indicating the = maximum

         coded = picture buffer size in units of CpbBrVclFactor bits = for

         the = VCL HRD parameters and in units of CpbBrNalFactor bits = for

         the = NAL HRD parameters, where CpbBrVclFactor and

         = CpbBrNalFactor are defined in Section A.4 of [HEVC].  The = max-

         cpb = parameter signals that the receiver has more memory = than

         the = minimum amount of coded picture buffer memory required = by

         the = highest level.  When max-cpb is signaled, the = receiver

         MUST = be able to decode bitstreams that conform to the = highest

         = level, with the exception that the MaxCPB value in Table = A-1

         of = [HEVC] for the highest level is replaced with the value = of

         = max-cpb.  Senders MAY use this knowledge to construct = coded

         = bitstreams with greater variation of bitrate than can = be

         = achieved with the MaxCPB value in Table A-1 of = [HEVC].

 

         When = not present, the value of max-cpb is inferred to be = equal

         to = the value of MaxCPB given in Table A-1 of [HEVC] for = the

         = highest level.

 

         The = value of max-cpb MUST be in the range of MaxCPB = to

         16 * = MaxCPB, inclusive, where MaxLumaCPB is given in Table = A-1

         of = [HEVC] for the highest level.

 

         &= nbsp;  Informative note: The coded picture buffer is used in = the

         &= nbsp;  hypothetical reference decoder (Annex C of HEVC).  The = use

         &= nbsp;  of the hypothetical reference decoder is recommended = in

         &= nbsp;  HEVC encoders to verify that the produced = bitstream

         &= nbsp;  conforms to the standard and to control the output = bitrate.

      =       Thus, the coded picture buffer is = conceptually independent

         &= nbsp;  of any other potential buffers in the receiver, = including

         &= nbsp;  de-packetization and de-jitter buffers.  The coded = picture

         &= nbsp;  buffer need not be implemented in decoders as specified = in

         &= nbsp;  Annex C of HEVC, but rather standard-compliant decoders = can

         &= nbsp;  have any buffering arrangements provided that they = can

         &= nbsp;  decode standard-compliant bitstreams.  Thus, in = practice,

         &= nbsp;  the input buffer for a video decoder can be integrated = with

         &= nbsp;  de-packetization and de-jitter buffers of the = receiver.

 

      = max-dpb:

         The = value of max-dpb is an integer indicating the = maximum

         = decoded picture buffer size in units decoded pictures at = the

         = MaxLumaPS for the highest level, i.e. the number of = decoded

         = pictures at the maximum picture size defined by the = highest

         = level.  The value of max-dpb MUST be in the range of 1 to = 16,

         = respectively.  The max-dpb parameter signals that the = receiver

         has = more memory than the minimum amount of decoded = picture

         = buffer memory required by default, which is MaxDpbPicBuf = as

         = defined in [HEVC] (equal to 6).  When max-dpb is signaled, = the

         = receiver MUST be able to decode bitstreams that conform to = the

         = highest level, with the exception that the MaxDpbPicBuff = value

         = defined in [HEVC] as 6 is replaced with the value of = max-dpb.

         = Consequently, a receiver that signals max-dpb MUST be = capable

         of = storing the following number of decoded pictures

         = (MaxDpbSize) in its decoded picture buffer:

 

         &= nbsp;           &n= bsp;    if( PicSizeInSamplesY <=3D ( MaxLumaPS = >> 2 ) )

         &= nbsp;    MaxDpbSize =3D Min( 4 * max-dpb, 16 = )

         &= nbsp; else if ( PicSizeInSamplesY <=3D ( MaxLumaPS >> 1 ) = )

         &= nbsp;    MaxDpbSize =3D Min( 2 * max-dpb, 16 = )

         &= nbsp; else if ( PicSizeInSamplesY <=3D ( ( 3 * MaxLumaPS ) >> 2 = ) )

         &= nbsp;    MaxDpbSize =3D Min( (4 * max-dpb) / 3, 16 = )

         &= nbsp; else

         &= nbsp;    MaxDpbSize =3D max-dpb

 

         &= nbsp;           &n= bsp;  Wherein MaxLumaPS given in Table A-1 of [HEVC] for the = highest

         level = and PicSizeInSamplesY is the current size of = each

         = decoded picture in units of luma samples as defined in = [HEVC].

         &= nbsp;           &n= bsp;  The value of max-dpb MUST be greater than or equal to = the

         value = of MaxDpbPicBuf (i.e. 6) as defined in [HEVC].  = Senders

         MAY = use this knowledge to construct coded bitstreams = with

         = improved compression.

 

         &= nbsp;           &n= bsp;  When not present, the value of max-dpb is inferred to be = equal

         to = the value of MaxDpbPicBuf (i.e. 6) as defined in = [HEVC].

 

         &= nbsp;  Informative note: This parameter was added primarily = to

         &= nbsp;  complement a similar codepoint in the ITU-T = Recommendation

         &= nbsp;  H.245, so as to facilitate signaling gateway designs.  = The

         &= nbsp;  decoded picture buffer stores reconstructed samples.  = There

         &= nbsp;  is no relationship between the size of the decoded = picture

         &= nbsp;  buffer and the buffers used in RTP, especially = de-

         &= nbsp;  packetization and de-jitter buffers.

 

      = max-br:

         The = value of max-br is an integer indicating the maximum = video

         = bitrate in units of CpbBrVclFactor bits per second for the = VCL

         HRD = parameters and in units of CpbBrNalFactor bits per = second

         for = the NAL HRD parameters, where CpbBrVclFactor and

         = CpbBrNalFactor are defined in Section A.4 of = [HEVC].

 

         The = max-br parameter signals that the video decoder of = the

         = receiver is capable of decoding video at a higher bitrate = than

         is = required by the highest level.

 

         When = max-br is signaled, the video codec of the receiver = MUST

         be = able to decode bitstreams that conform to the = highest

         = level, with the following exceptions in the limits = specified

         by = the highest level:

 

          = o The value of max-br replaces the MaxBR value in Table = A-2

         &= nbsp;  of [HEVC] for the highest level.

          = o When the max-cpb parameter is not present, the result = of

         &= nbsp;  the following formula replaces the value of MaxCPB in = Table

         &= nbsp;  A-1 of [HEVC]:

 

         &= nbsp;     (MaxCPB of the highest level) * max-br / = (MaxBR of the

         &= nbsp;     highest level)

 

         For = example, if a receiver signals capability for Main = profile

         Level = 2 with max-br equal to 2000, this indicates a = maximum

         video = bitrate of 2000 kbits/sec for VCL HRD parameters, = a

         = maximum video bitrate of 2200 kbits/sec for NAL = HRD

         = parameters, and a CPB size of 2000000 bits (2000000 / = 1500000

         * = 1500000).

 

         = Senders MAY use this knowledge to send higher bitrate video = as

         = allowed in the level definition of Annex A of HEVC to = achieve

         = improved video quality.

 

         When = not present, the value of max-br is inferred to be = equal

         to = the value of MaxBR given in Table A-2 of [HEVC] for = the

         = highest level.

 

         The = value of max-br MUST be in the range of MaxBR to

         16 * = MaxBR, inclusive, where MaxBR is given in Table A-2 = of

         = [HEVC] for the highest level.

 

         &= nbsp;  Informative note: This parameter was added primarily = to

         &= nbsp;  complement a similar codepoint in the ITU-T = Recommendation

         &= nbsp;  H.245, so as to facilitate signaling gateway designs.  = The

         &= nbsp;  assumption that the network is capable of handling = such

         &= nbsp;  bitrates at any given time cannot be made from the value = of

         &= nbsp;  this parameter.  In particular, no conclusion can be = drawn

         &= nbsp;  that the signaled bitrate is possible under = congestion

         &= nbsp;  control constraints.

 

      = max-tr:

         The = value of max-tr is an integer indication the = maximum

         = number of tile rows.  The max-tr parameter signals that = the

         = receiver is capable of decoding video with a larger number = of

         tile = rows than the value allowed by the highest = level.

 

         When = max-tr is signaled, the receiver MUST be able to = decode

     =     bitstreams that conform to the highest level, = with the

         = exception that the MaxTileRows value in Table A-1 of = [HEVC]

         for = the highest level is replaced with the value of = max-tr.

         = Senders MAY use this knowledge to send pictures utilizing = a

         = larger number of tile rows than the value allowed by = the

         = highest level.

 

         When = not present, the value of max-tr is inferred to be = equal

         to = the value of MaxTileRows given in Table A-1 of [HEVC] = for

         the = highest level.

 

         The = value of max-tr MUST be in the range of MaxTileRows = to

         16 * = MaxTileRows, inclusive, where MaxTileRows is given = in

         Table = A-1 of [HEVC] for the highest level.

 

      = max-tc:

         The = value of max-tc is an integer indication the = maximum

         = number of tile columns.  The max-tc parameter signals that = the

         = receiver is capable of decoding video with a larger number = of

         tile = columns than the value allowed by the highest = level.

 

         When = max-tc is signaled, the receiver MUST be able to = decode

         = bitstreams that conform to the highest level, with = the

         = exception that the MaxTileCols value in Table A-1 of = [HEVC]

         for = the highest level is replaced with the value of = max-tc.

 

         = Senders MAY use this knowledge to send pictures utilizing = a

         = larger number of tile columns than the value allowed by = the

         = highest level.

 

         When = not present, the value of max-tc is inferred to be = equal

         to = the value of MaxTileCols given in Table A-1 of [HEVC] = for

         the = highest level.

 

         The = value of max-tc MUST be in the range of MaxTileCols = to

         16 * = MaxTileCols, inclusive, where MaxTileCols is given = in

         Table = A-1 of [HEVC] for the highest level.

 

      = max-fps:

 

         The = value of max-fps is an integer indicating the = maximum

         = picture rate in units of pictures per 100 seconds that can = be

         = effectively processed by the receiver.  The max-fps = parameter

         MAY = be used to signal that the receiver has a constraint = in

         that = it is not capable of processing video effectively at = the

         full = picture rate that is implied by the highest level = and,

  =        when present, one or more of = the parameters max-lsr, max-lps,

         and = max-br.

 

         The = value of max-fps is not necessarily the picture rate = at

         which = the maximum picture size can be sent, it constitutes = a

         = constraint on maximum picture rate for all = resolutions.

 

         &= nbsp;  Informative note: The max-fps parameter is = semantically

         &= nbsp;  different from max-lsr, max-lps, max-cpb, max-dpb, = max-br,

         &= nbsp;  max-tr, and max-tc in that max-fps is used to signal = a

          =   constraint, lowering the maximum picture rate from what = is

         &= nbsp;  implied by other parameters.

 

         The = encoder MUST use a picture rate equal to or less than = this

         = value.  In cases where the max-fps parameter is absent = the

         = encoder is free to choose any picture rate according to = the

         = highest level and any signaled optional = parameters.

 

         The = value of max-fps MUST be smaller than or equal to the = full

         = picture rate that is implied by the highest level and, = when

         = present, one or more of the parameters max-lsr, max-lps, = and

         = max-br.

 

      = sprop-max-don-diff:

 

         The = value of this parameter MUST be equal to 0, if the = RTP

         = stream does not depend on other RTP streams and there is = no

        NAL = unit naluA that is followed in transmission order by = any

         NAL = unit preceding naluA in decoding order.  Otherwise, = this

         = parameter specifies the maximum absolute difference = between

         the = decoding order number (i.e., AbsDon) values of any two = NAL

         units = naluA and naluB, where naluA follows naluB in = decoding

         order = and precedes naluB in transmission order.

 

         The = value of sprop-max-don-diff MUST be an integer in = the

         range = of 0 to 32767, inclusive.

 

         When = not present, the value of sprop-max-don-diff is = inferred

         to be = equal to 0.

         When = the RTP stream depends on one or more other RTP = streams

         (in = this case tx-mode MUST be equal to "MSM" and MSM is = in

        use), = this parameter MUST be present and the value MUST = be

         = greater than 0.

 

         &= nbsp;  Informative note: When the RTP stream does not depend = on

         &= nbsp;  other RTP streams, either MSM or SSM may be in = use.

 

      = sprop-depack-buf-nalus:

 

         This = parameter specifies the maximum number of NAL units = that

         = precede a NAL unit in transmission order and follow the = NAL

         unit = in decoding order.

 

         The = value of sprop-depack-buf-nalus MUST be an integer in = the

         range = of 0 to 32767, inclusive.

 

         When = not present, the value of sprop-depack-buf-nalus = is

         = inferred to be equal to 0.

 

         When = the RTP stream depends on one or more other RTP = streams

         (in = this case tx-mode MUST be equal to "MSM" and MSM is = in

         use), = this parameter MUST be present and the value MUST = be

         = greater than 0.

 

      = sprop-depack-buf-bytes:

 

         This = parameter signals the required size of the de-

         = packetization buffer in units of bytes.  The value of = the

         = parameter MUST be greater than or equal to the maximum = buffer

         = occupancy (in units of bytes) of the de-packetization = buffer

         as = specified in section 6.

 

         The = value of sprop-depack-buf-bytes MUST be an integer in = the

         range = of 0 to 4294967295, inclusive.

 

         When = the RTP stream depends on one or more other RTP = streams

         (in = this case tx-mode MUST be equal to "MSM" and MSM is = in

         use) = or sprop-max-don-diff is present and greater than 0, = this

         = parameter MUST be present and the value MUST be greater = than

         = 0.

         &= nbsp;  Informative note: The value of = sprop-depack-buf-bytes

         &= nbsp;  indicates the required size of the de-packetization = buffer

         &= nbsp;  only.  When network jitter can occur, an = appropriately

         &= nbsp;  sized jitter buffer has to be available as = well.

 

      = depack-buf-cap:

 

         This = parameter signals the capabilities of a receiver

         = implementation and indicates the amount of = de-packetization

         = buffer space in units of bytes that the receiver has = available

         for = reconstructing the NAL unit decoding order from NAL = units

         = carried in one or more RTP streams.  A receiver is able = to

         = handle any RTP stream, and all RTP streams the RTP = stream

         = depends on, when present, for which the value of the = sprop-

         = depack-buf-bytes parameter is smaller than or equal to = this

         = parameter.

 

         When = not present, the value of depack-buf-cap is inferred = to

         be = equal to 4294967295.  The value of depack-buf-cap MUST = be

         an = integer in the range of 1 to 4294967295, = inclusive.

 

         &= nbsp;  Informative note: depack-buf-cap indicates the = maximum

         &= nbsp;  possible size of the de-packetization buffer of = the

         &= nbsp;  receiver only.  When network jitter can occur, = an

         &= nbsp;  appropriately sized jitter buffer has to be available = as

         &= nbsp;  well.

 

      = sprop-segmentation-id:

 

         This = parameter MAY be used to signal the segmentation = tools

         = present in the bitstream and that can be used = for

         = parallelization.  The value of sprop-segmentation-id MUST = be

         an = integer in the range of 0 to 3, inclusive.  When = not

         = present, the value of sprop-segmentation-id is inferred to = be

         equal = to 0.

 

         When = sprop-segmentation-id is equal to 0, no information = about

         the = segmentation tools is provided.  When = sprop-segmentation-

         id is = equal to 1, it indicates that slices are present in = the

         = bitstream.  When sprop-segmentation-id is equal to 2, = it

         = indicates that tiles are present in the bitstream.  = When

        = sprop-segmentation-id is equal to 3, it indicates that WPP = is

         used = in the bitstream.

 

      = sprop-spatial-segmentation-idc:

 

         A = base16 [RFC4648] representation of the syntax = element

         = min_spatial_segmentation_idc as specified in [HEVC].  = This

         = parameter MAY be used to describe parallelization = capabilities

         of = the bitstream.

 

      = dec-parallel-cap:

 

         This = parameter MAY be used to indicate the decoder's

         = additional decoding capabilities given the presence of = tools

         = enabling parallel decoding, such as slices, tiles, and WPP, = in

  =        the bitstream.  The = decoding capability of the decoder may

         vary = with the setting of the parallel decoding tools = present

         in = the bitstream, e.g. the size of the tiles that are = present

         in a = bitstream.  Therefore, multiple capability points may = be

         = provided, each indicating the minimum required = decoding

         = capability that is associated with a parallelism = requirement,

         which = is a requirement on the bitstream that enables = parallel

         = decoding.

 

         Each = capability point is defined as a combination of 1) = a

         = parallelism requirement, 2) a profile (determined by = profile-

         space = and profile-id), 3) a highest level, and 4) a = maximum

         = processing rate, a maximum picture size, and a maximum = video

         = bitrate that may be equal to or greater than that = determined

         by = the highest level.  The parameter's syntax in = ABNF

         = [RFC5234] is as follows:

 

         &= nbsp;  dec-parallel-cap =3D "dec-parallel-cap=3D{" = cap-point *(","

      =             &= nbsp;           &n= bsp;cap-point) "}"

 

         &= nbsp;  cap-point =3D ("w" / "t") ":" = spatial-seg-idc 1*(";"

         &= nbsp;           &n= bsp;   cap-parameter)

 

         &= nbsp;  spatial-seg-idc =3D 1*4DIGIT ; = (1-4095)

 

         &= nbsp;  cap-parameter =3D tier-flag / level-id / = max-lsr

         &= nbsp;           &n= bsp;     / max-lps / = max-br

 

         &= nbsp;  tier-flag =3D "tier-flag" EQ ("0" / = "1")

 

         &= nbsp;  level-id  =3D "level-id" EQ 1*3DIGIT ; = (0-255)

 

         &= nbsp;  max-lsr   =3D "max-lsr" EQ  = 1*20DIGIT ; (0-

         &= nbsp;  18,446,744,073,709,551,615)

 

    =         max-lps   =3D = "max-lps" EQ 1*10DIGIT ; = (0-4,294,967,295)

 

         &= nbsp;  max-br    =3D "max-br"  EQ = 1*20DIGIT ; (0-

         &= nbsp;  18,446,744,073,709,551,615)

 

         &= nbsp;  EQ =3D "=3D"

 

         The = set of capability points expressed by the = dec-parallel-cap

    =      parameter is enclosed in a pair of curly = braces ("{}").  Each

         set = of two consecutive capability points is separated by = a

         comma = (',').  Within each capability point, each set of = two

         = consecutive parameters, and when present, their values, = is

         = separated by a semicolon (';').

 

         The = profile of all capability points is determined by = profile-

         space = and profile-id that are outside the = dec-parallel-cap

         = parameter.

 

         Each = capability point starts with an indication of = the

         = parallelism requirement, which consists of a parallel = tool

         type, = which may be equal to 'w' or 't', and a decimal value = of

         the = spatial-seg-idc parameter.  When the type is 'w', = the

         = capability point is valid only for H.265 bitstreams with = WPP

         in = use, i.e. entropy_coding_sync_enabled_flag equal to = 1.

         When = the type is 't', the capability point is valid only = for

         H.265 = bitstreams with WPP not in use (i.e.

         = entropy_coding_sync_enabled_flag equal to 0).  The = capability-

         point = is valid only for H.265 bitstreams with

         = min_spatial_segmentation_idc equal to or greater than = spatial-

         = seg-idc.

 

         After = the parallelism requirement indication, each = capability

         point = continues with one or more pairs of parameter and = value

         in = any order for any of the following parameters:

 

         &= nbsp;  o tier-flag

         &= nbsp;  o level-id

         &= nbsp;  o max-lsr

         &= nbsp;  o max-lps

         &= nbsp;  o max-br

 

         At = most one occurrence of each of the above five parameters = is

         = allowed within each capability point.

 

         The = values of dec-parallel-cap.tier-flag and = dec-parallel-

         = cap.level-id for a capability point indicate the highest = level

         of = the capability point.  The values of = dec-parallel-cap.max-

         lsr, = dec-parallel-cap.max-lps, and dec-parallel-cap.max-br = for

         a = capability point indicate the maximum processing rate = in

         units = of luma samples per second, the maximum picture size = in

         units = of luma samples, and the maximum video bitrate (in = units

         of = CpbBrVclFactor bits per second for the VCL HRD = parameters

         and = in units of CpbBrNalFactor bits per second for the NAL = HRD

         = parameters where CpbBrVclFactor and CpbBrNalFactor are = defined

         in = Section A.4 of [HEVC]).

 

         When = not present, the value of dec-parallel-cap.tier-flag = is

         = inferred to be equal to the value of tier-flag outside = the

         = dec-parallel-cap parameter.  When not present, the value = of

         = dec-parallel-cap.level-id is inferred to be equal to the = value

         of = max-recv-level-id outside the dec-parallel-cap = parameter.

         When = not present, the value of dec-parallel-cap.max-lsr, = dec-

         = parallel-cap.max-lps, or dec-parallel-cap.max-br is = inferred

         to be = equal to the value of max-lsr, max-lps, or = max-br,

         = respectively, outside the dec-parallel-cap = parameter.

 

         The = general decoding capability, expressed by the set = of

         = parameters outside of dec-parallel-cap, is defined as = the

         = capability point that is determined by the = following

         = combination of parameters: 1) the parallelism = requirement

      =    corresponding to the value of sprop-segmentation-id = equal to 0

         for a = bitstream, 2) the profile determined by = profile-space,

         = profile-id, profile-compatibility-indicator, and = interop-

         = constraints, 3) the tier and the highest level determined = by

         = tier-flag and max-recv-level-id, and 4) the maximum = processing

         rate, = the maximum picture size, and the maximum video = bitrate

         = determined by the highest level.  The general = decoding

         = capability MUST NOT be included as one of the set = of

         = capability points in the dec-parallel-cap = parameter.

 

         For = example, the following parameters express the = general

         = decoding capability of 720p30 (Level 3.1) plus an = additional

         = decoding capability of 1080p30 (Level 4) given that = the

         = spatially largest tile or slice used in the bitstream is = equal

         to or = less than 1/3 of the picture size:

 

         &= nbsp;  a=3Dfmtp:98 = level-id=3D93;dec-parallel-cap=3D{t:8;level-id=3D120}

 

         For = another example, the following parameters express = an

         = additional decoding capability of 1080p30, using = dec-parallel-

         = cap.max-lsr and dec-parallel-cap.max-lps, given that WPP = is

         used = in the bitstream:

 

         &= nbsp;  a=3Dfmtp:98 = level-id=3D93;dec-parallel-cap=3D{w:8;

         &= nbsp;           &n= bsp;  max-lsr=3D62668800;max-lps=3D2088960}

 

         &= nbsp;  Informative note: When min_spatial_segmentation_idc = is

         &= nbsp;  present in a bitstream and WPP is not used, = [HEVC]

         &= nbsp;  specifies that there is no slice or no tile in = the

         &= nbsp;  bitstream containing more than 4 * PicSizeInSamplesY = /

         &= nbsp;  ( min_spatial_segmentation_idc + 4 ) luma = samples.

 

      = include-dph:

 

         This = parameter is used to indicate the capability and

         = preference to utilize or include decoded picture hash = (DPH)

         SEI = messages (See Section D.3.19 of [HEVC]) in the = bitstream.

         DPH = SEI messages can be used to detect picture corruption = so

         the = receiver can request picture repair, see Section 8.  = The

  =        value is a comma separated = list of hash types that is

         = supported or requested to be used, each hash type provided = as

         an = unsigned integer value (0-255), with the hash types = listed

         from = most preferred to the least preferred. =  Example:

        = "include-dph=3D0,2", which indicates the capability for = MD5

         (most = preferred) and Checksum (less preferred).  If = the

         = parameter is not included or the value contains no hash = types,

         then = no capability to utilize DPH SEI messages is = assumed.

         Note = that DPH SEI messages MAY still be included in = the

         = bitstream even when there is no declaration of capability = to

         use = them, as in general SEI messages do not affect = the

         = normative decoding process and decoders are allowed to = ignore

         SEI = messages.

 

      Encoding = considerations:

 

         This = type is only defined for transfer via RTP (RFC = 3550).

 

      Security = considerations:

 

         See = Section 9 of RFC XXXX.

 

      Public = specification:

 

         = Please refer to Section 13 of RFC XXXX.

 

      Additional information: = None

 

      File extensions: = none

 

      Macintosh file type = code: none

 

      Object identifier or = OID: none

 

      Person & email = address to contact for further information:

 

      Intended usage: = COMMON

 

      Author: See Section 14 = of RFC XXXX.

 

      Change = controller:

 

         IETF = Audio/Video Transport Payloads working group = delegated

         from = the IESG.

 

 

------=_NextPart_000_0019_01CFC388.1D199C60--