From nobody Sun Mar 2 23:44:11 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054991A0976; Sun, 2 Mar 2014 23:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 p0XK8PI9iAl3; Sun, 2 Mar 2014 23:44:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6FA1A0349; Sun, 2 Mar 2014 23:44:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303074403.9677.59679.idtracker@ietfa.amsl.com> Date: Sun, 02 Mar 2014 23:44:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/WmS8NiInW_9dQW-SXJH3EH17jGI Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 07:44:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Bluetooth's SBC Audio Codec Authors : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-07.txt Pages : 23 Date : 2014-03-02 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-sbc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 2 23:55:56 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B269E1A042E for ; Sun, 2 Mar 2014 23:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 llb385ECB1yV for ; Sun, 2 Mar 2014 23:55:50 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 066661A078B for ; Sun, 2 Mar 2014 23:55:46 -0800 (PST) Received: from mail125-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 07:55:43 +0000 Received: from mail125-tx2 (localhost [127.0.0.1]) by mail125-tx2-R.bigfish.com (Postfix) with ESMTP id 898B0400093 for ; Mon, 3 Mar 2014 07:55:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.241.149; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -29 X-BigFish: VPS-29(zz15d6O9371I936eI542I9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2 (MessageSwitch) id 1393833342348275_10325; Mon, 3 Mar 2014 07:55:42 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.245]) by mail125-tx2.bigfish.com (Postfix) with ESMTP id 457734E0063 for ; Mon, 3 Mar 2014 07:55:42 +0000 (UTC) Received: from mail.philips.com (206.191.241.149) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 07:55:42 +0000 Received: from AM3PRD9003MB049.MGDPHG.emi.philips.com ([169.254.10.88]) by AM3PRD9003HT003.MGDPHG.emi.philips.com ([141.251.30.208]) with mapi id 14.16.0411.000; Mon, 3 Mar 2014 07:55:38 +0000 From: "Bont, Frans de" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-sbc-07.txt Thread-Index: AQHPNrRzLYW/tQ2Zw0mELyj8mIzQ0ZrO/ezQ Date: Mon, 3 Mar 2014 07:55:36 +0000 Message-ID: References: <20140303074403.9677.59679.idtracker@ietfa.amsl.com> In-Reply-To: <20140303074403.9677.59679.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/payload/d_n2QX8wrX94gPHdEGA5PDNyrwE Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 07:55:53 -0000 This version has been uploaded to keep the draft alive waiting for WGLC. Best regards, Frans -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Monday, March 03, 2014 8:44 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for Bluetooth's SBC Audio Code= c Authors : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-07.txt Pages : 23 Date : 2014-03-02 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-sbc-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Mon Mar 3 11:07:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56B1A0225 for ; Mon, 3 Mar 2014 11:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 a_lzmfzFr7pN for ; Mon, 3 Mar 2014 11:07:10 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 567581A01E7 for ; Mon, 3 Mar 2014 11:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393873627; x=1425409627; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H4LUq2XAFyda9BczHisS9e11Fk0mS2Y3IQyflXZIBho=; b=TN1EjrygKghpLLBWSFJX5Q8EAcUrUuP4eC2jPpZxN5fUai2ZjP4XdP83 d+yziKl4LtR7h8blYmx6+M9uTq3h3yP95xzrvPzZR6YqBGA2O2r/Zul90 X3COXwD8k/FbH4/rF8a5krdu3P1RMtPsjRHyjiV6SUdOypoJwVJgh/+tq M=; X-IronPort-AV: E=McAfee;i="5400,1158,7366"; a="108984180" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 03 Mar 2014 11:07:07 -0800 X-IronPort-AV: E=Sophos;i="4.97,579,1389772800"; d="scan'208";a="602829076" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Mar 2014 11:07:07 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0158.001; Mon, 3 Mar 2014 11:07:06 -0800 From: "Wang, Ye-Kui" To: Magnus Westerlund , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCA Date: Mon, 3 Mar 2014 19:07:06 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> In-Reply-To: <5310AF7F.9050508@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/OYAkehSIc7Wq3MjM-itxsqkT5dE Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:07:14 -0000 Comments 17-22 are on PACI, which is Stephan's baby, and I will thus let St= ephan to address them. My responses to comments 23 upwards are interleaved below (again, for conve= nience, I only included comments 23 upwards). BR, YK 23. Section 5: Otherwise (sprop- depack-buf-nalus is equal to 0 for an RTP stream), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order. This fails to describe how you determines the NAL unit decoding order. I as= sume in RTP sequence order and for each payload in the order the NALUs are = included? [YK]: No, the NAL unit decoding order is described by the de-packetization = process in Section 6, which applies in all cases, regardless of sprop-depac= k-buf-nalus being 0 or greater than 0. Yes, when sprop-depack-buf-nalus is = equal to 0, the order would be as you assumed above. I don't see anything w= rong or missing in this regard. However, if you think more clarification is= needed anywhere, please suggest and let us know where. 24. Section 6: When MST is in use, NAL units of all RTP streams are stored in the same de-packetization buffer. I think it needs to be clarified that this is all RTP streams from the same= encoder instance and media source. Not all RTP streams from multiple encod= er instances and media sources. [YK]: Yes. But on other hand, in my understanding, we always refer to the c= ontext of one "encoder instance and media source" in RTP payload format for= a particular codec, right? Is it OK that we just make this generic clarifi= cation? 25. Section 7.1: The receiver MUST ignore any unspecified parameter. First, I don't know if this is the right place to included this rule. Secondly, should it not be "unknown" parameters for the one processing the = media format parameters? [YK]: OK, I will change the wording to "unrecognized". However, to me this = is a good place to say this - we did it the same way and in the same place = in RFCs 6184/6190. However, if you know a better place, please let us know. 26. Section 7.1: profile-space, profile-id: Otherwise (the RTP stream is a dependent RTP stream), the following applies, with j being the value of the sub-layer- id parameter: o profile_space =3D sub_layer_profile_space[j] o profile_id =3D sub_layer_profile_idc[j] The following text raises some concerns. A) These are defined as being stream specific values. It is unclear how one= deals with these if one only want to configure the general capability with= in a RTP payload type. [YK]: Note that these are "elementary stream" specific values, not "RTP str= eam" specific values. For example, if there are 3 temporal sub-layers, with= TemporalId equal to 0, 1, and 2, respectively, and each is carried in one = RTP stream, then the values of the RTP stream corresponding to the temporal= sub-layers with TemporalId equal to 2 are the property of the bitstream or= elementary stream consisting of all the three temporal sub-layers. And sin= ce this RTP stream is not a dependent RTP stream (because no other RTP stre= am depends on it), the general capability is assigned. B) It is unclear if one may or are required to create different RTP payload= types for the different scalability layers. From my perspective it is cruc= ial that one can avoid a requirement to create layer specific payload types= as this can result in total consumption of the available payload type spac= e in an RTP session. Thus, I see a need to clarify if and when one uses the above assignment. And how the counter part in any signalling exchange is supposed to interpre= t these cases. [YK]: To me, when a spec does not disallow the use of different RTP payload= types, which is the case with the current spec, then the use is allowed. D= o you see any reason to impose an restriction on use of payload types for t= he different RTP streams in a multi-stream transmission? If not, I think we= can just add a note to say that there is no restriction imposed herein for= the use of payload types.=20 The same concerns relate to the tier-flag, level-id: Otherwise (the RTP stream is a dependent RTP stream), the following applies, with j being the value of the sub-layer- id parameter: o tier-flag =3D sub_layer_tier_flag[j] o level-id =3D sub_layer_level_idc[j] 27. Section 7.1: profile-compatibility-indicator: Isn't this a sprop parameter? [YK]: It is the same as profile, tier, and level. And you can see in later = text, it is part of the media format configuration. Also it is not clear what "j" is: If the RTP stream is not a dependent RTP stream, the following applies with j =3D 0..31: o The 32 flags =3D general_profile_compatibility_flag[j] Am I correct that j in this case are the integer identifying a particular H= EVC profile? [YK]: That is true. This is clear from the semantics of the flag as defined= in the HEVC spec. We can try to add a bit more clarification on this. 28. Section 7.1: profile-compatibility-indicator: It is not clear to me that this parameter has long term applicability. If one includes this, is that a promise until signaling changes to not prov= ide a stream that breaks the provided value? I wonder how one deals with th= e use cases like AD splicing. One stream may ensure this, is it the role of= the signalling to enforce that what one says applies, or will be renegotia= ted in signalling? [YK]: Again, the nature and the usage of this parameter is the same as prof= ile, tier, and level. So, yes, it would be a promise when provided, in eith= er SDP offer/answer or declarative usage. 29. sub-layer-id: This parameter MAY be used to indicate the highest allowed value of TID in the stream. When not present, the value of sub-layer-id is inferred to be equal to 6. This parameter is written in a generic form, however the O/A Section indica= tes this to declare a property of the stream to be sent. But not explicit d= iscussion of this parameter is provided. So what is the meaning of this par= ameter? A) I promise that the streams I send does not use more than X sub-layers B) I require the peer sending me a stream to not use more than X sub-layers= . [YK]: It is A. Would it be clear enough in your view if we add that this pa= rameter shall not be used for any other purpose than indicating a property = of the stream (which to me is sort of clear from its current semantics)? 30. Section 7.1: sprop-vps, sprop-sps and sprop-pps: I think one unclarity and one that existed in H.264 also, is the precedence= between out-of-band and in-band parameter sets. And when they start to app= ly. The later is especially important in cases when you actually transmit a= different set in a new signalling exchange then what has previously been u= sed. Can some clarification on this be included? [YK]: OK, we can add a clarification to state that, out-of-band parameter s= ets can be put at the beginning of the bitstream output to the decoder, whi= le in-band parameter sets can be sent to the decoder in the same way as the= receiver outputs other types of NAL units from the de-packetization proces= s. 31. Section 7.1: Many of the parameters. I notices that quite a lot of the parameters are= not explicitly defining the value range allowed for the parameters. This is especially true for integer style values. See the many max- paramet= ers. [YK]: Right. We have been doing this all the time, including RFCs 6184/6190= . Are you saying that from now that the value range of each parameter needs= to be clearly specified in RTP payload formats? 32. Section 7.1: max-dpb: Formation error [YK]: Sorry, I don't know what is error by comparing to the semantics to th= at of other parameters. Could you please clarify? 33. Section 7.1: cap-parameter =3D tier-flag / level-id / max-lsr / max-lps / max-br These ABNF elements are not defined. I think they need to be. [YK]: This came from you guys. Can you please provide the missing definitio= n? 34. Section 7.2.1: Source specific parameters: o The OPTIONAL parameters "sprop-vps", "sprop-sps", and "sprop- pps", when present, MUST be included in the "a=3Dfmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in section 6.3 of [RFC5576]. For a particular media format (i.e. RTP payload type), "sprop-vps" "sprop-sps", or "sprop-pps" MUST NOT be both included in the "a=3Dfmtp" line of SDP and conveyed using the "fmtp" source attribute. This text exemplifies that there are important differencies between RTP ses= sion level configuration and individual source level configuration. I think= some more general discussion of the potential constraints and implications= of the two methods needs to be considered. Especially when you are prevent= ed from signalling both session and stream level. Stream level requires on to know that this stream will be sent and its conf= iguration. And when you also can't provide a session level set that is defa= ult fall back if no stream specific is provided then you get to choose betw= een. These parameter constraints applies to all streams, or no pre-provided= parameters can be provided at all, and you need per stream signalling. [YK]: OK, we will try to add some usage description along the line mentione= d above, probably with some help from the original proponent of this source= -specific feature. 35. Section 7.2.2: Informative note: The above parameters apply for any stream sent by a declaring entity with the same configuration; i.e. they are dependent on their source. Rather than being bound to the payload type, the values may have to be applied to another payload type when being sent, as they apply for the configuration. I find this confusing. I don't know if it is a typo and should say "indepen= dent of their source", or if it is the definition of source here that is wr= ong. It might be that the paragraph before the above: o The parameters sprop-depack-buf-nalus and sprop-depack-buf-bytes describe the properties of the RTP stream that the offerer or the answerer is sending for the media format configuration. This differs from the normal usage of the Offer/Answer parameters: normally such parameters declare the properties of the stream that the offerer or the answerer is able to receive. When dealing with HEVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered. actually needs to separate between end point specific configurations that a= pply to the whole RTP session through the payload type or if is on specific= media encoding basis and thus needs to be connected to the SSRC(s) that carries the particular media encoding. [YK]: It seems to be a good catch. The same wording was inherited from RFC = 6184, and appeared in RFC 3984 as well, for which you were a co-author. Cou= ld you authors of RFC 3984 (e.g. Stephan, Miska, Magnus) try to help figure= out what was the actual intent when this wording was firstly introduced in= to RFC 3984? 36. Section 7.2.2: min_spatial_segmentation_idc equal to or larger than dec- parallel-cap.spatial-seg-idc of the capability point. A stream that is sent based on choosing a capability point with parallel tool type 't' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 0 and min_spatial_segmentation_idc equal to or larger than dec- parallel-cap.spatial-seg-idc of the capability point. It looks like someone managed to turn this text into straight left and righ= t columns, this is not allowed in IETF, we use ragged rights. [YK]: I guess you meant to align text only to the left margin, not to both = left and right margins? If that is the case, we actually did this in all th= e places in the Word based template for preparing of the draft. Do you see = any issues in other places as well? Can you please let us know some specifi= c line for which the style should be changed? 37. Section 7.2.2: o An offerer has to include the size of the de-packetization buffer, sprop-depack-buf-bytes, and sprop-depack-buf-nalus, in the offer for an interleaved HEVC stream or for the MST transmission mode. To enable the offerer and answerer to inform each other about their capabilities for de-packetization buffering in receiving streams, both parties are RECOMMENDED to include depack-buf-cap. For interleaved streams or in MST, it is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown. This paragraph contains two mentions of "interleaved", the only two in the = whole specification. I assume a copy and paste from RFC 6184 that wasn't co= nverted properly. [YK]: No they are intentionally left here, as interleaved packetization is = allowed. Maybe we can add one sentence or two to make this more explicit. 38. Section 7.2.2.: However, when out-of-band transport of parameter sets is used, parameter sets MAY still be additionally transported in-band unless explicitly disallowed by an application. To me it doesn't appear that this rule is O/A specific. It should apply als= o to declarative usage. I propose that this is moved to the parameter defin= ition itself. [YK]: OK. Section 7.2.4 (Parameter set considerations) should be a good pla= ce to hold this. 39. Section 7.2.2.: o In MST, the answerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps of all RTP streams that a particular RTP stream depends on, when present (either included in the "a=3Dfmtp" line of SDP or conveyed using the "fmtp" source attribute), for decoding the incoming NAL unit stream. I become uncertain how this really works. Especially in the context of recv= -sub-layer-id. So the offerer includes the parameter sets for all the layer= s it intended to send. Then the answerer sub-sets that selection using recv= -sub-layer-id. Is the intention to say that the answerer needs to try to ap= ply the parameter sets that matches the selected layers. [YK]: When MST is in use, parameter sets may be split and transmitted in di= fferent RTP streams. When a reciver chooses to receive a set of the RTP str= eams, the receiver must be prepared to use parameter sets carried in all RT= P streams of the set, not just parameter sets carried in the highest RTP st= ream. We can try to make this clearer. 40. Section 7.2.2: o If the level to use in the answerer-to-offerer direction is equal to the default level in the answer, the offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=3Dfmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming NAL unit stream. Otherwise, the offerer MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included in the "a=3Dfmtp" line of SDP or conveyed using the "fmtp" source attribute) and the answerer MUST transmit parameter sets in-band. Sorry, I missing something here. In the Answerer to Offerer direction, ther= e are no reason for the answerer to not provide parameter sets that matches= the offerer's declared receiving capability. Thus, why discuss the "defaul= t" level? [YK]: Good catch. The answerer should just provide parameter sets that matc= hes the offerer's declared receiving capability if out-of-band parameter se= ts transmission is used. Will change this in the next version. 41. Section 7.2.2: o In MST, the offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps of all RTP streams that a particular RTP stream depends on, when present (either included in the "a=3Dfmtp" line of SDP or conveyed using the "fmtp" source attribute), for decoding the incoming NAL unit stream. I am uncertain if this is intended to mean something else than, if provided= attempt to use them. [YK]: This is a repeat of comment #39. See my reply to comment #39 above. 42. Section 7.2.2: Parameter sets associated with one source MUST only be used to decode NAL units conveyed in RTP packets from the same source. The question is what is meant with "same source" in the above. Is it SSRC, = Media Source or Media Encoding, or even Endpoint. [YK]: I think this means the same media source or the same media encoding i= nstance. Will change in the next version. 43. Section 7.2.2: sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | profile-space C X C X P profile-id C X C X P tier-flag C X C X P level-id C X C X P C: configuration for sending and receiving streams I don't get this usage or definition of C for these parameters. So these parameters are receiver capabilities, and they needs to be symmetr= ically used in the signalling, however the actually used values in the tran= smission direction from an O/A agent only needs to be within the receivers = provided parameters. Thus, they are not a "configuration" for the sending direction. [YK]: These are configuration parameters, meaning indicating both what is t= o be sent and what is to be received for sendrecv and must be used symmetri= cally, and only the latter for recvonly.=20 Also I really don't get the X's in the answer: recvonly, recv-sub-layer-id,= and answer: sendrecv, recv-sub-layer-id. The answering agent is going to r= eceive stream in both these cases, thus it needs to declare the payload typ= e, and these parameters MUST be included (unless defaulted). So why is they= marked with X? [YK]: When recv-sub-layer-id is included in an SDP answer, it means that th= e answer chooses one of the multiple operation points corresponding to the = offered or declared sub-layers in the sprop-vps, and in this case there is = no need to repeat the information of profile, level etc. in the SDP, thus t= here are marked with X (MUST NOT be present). 44. Section 7.2.2: sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | interop-constraints C X C X P profile-compatibility-indicator C X C X P I don't understand how these parameters really are used for receiver capabi= lity declarations, so I don't understand why the Cs are C and not P. [YK]: As explained earlier, these are also parts of the media type configur= ation, same as profile, tier, and level, and their usage are the same as th= ose too. From nobody Mon Mar 3 14:10:42 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614FD1A0132; Mon, 3 Mar 2014 14:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 q8Uwm58SGTNA; Mon, 3 Mar 2014 14:10:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70661A00C9; Mon, 3 Mar 2014 14:10:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303221033.319.24403.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 14:10:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/-ohq3_QixCti6flrruwluj90iek Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-g7110-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 22:10:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for G.711.0 Authors : Michael A. Ramalho Paul E. Jones Noboru Harada Muthu Arul Mozhi Perumal Lei Miao Filename : draft-ietf-payload-g7110-02.txt Pages : 28 Date : 2014-03-03 Abstract: This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-g7110-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-g7110-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 14:11:43 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF611A01C4 for ; Mon, 3 Mar 2014 14:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 EJgSrol8NIR8 for ; Mon, 3 Mar 2014 14:11:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7891A01BA for ; Mon, 3 Mar 2014 14:11:26 -0800 (PST) Received: from localhost ([127.0.0.1]:53929 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WKb4l-0003go-Fe; Mon, 03 Mar 2014 23:11:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org, jonatan.samuelsson@ericsson.com X-Trac-Project: payload Date: Mon, 03 Mar 2014 22:11:07 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/10#comment:3 Message-ID: <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org, jonatan.samuelsson@ericsson.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Cf66mEgMEVJbuCImZz5PZqkG-Yo Cc: payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 22:11:39 -0000 #10: Marker bit in H.265/HEVC Comment (by jonatan.samuelsson@ericsson.com): Thanks Stefan for the comments and the example. It is exactly this kind of cases I'm concerned about but I wouldn't characterize them as exotic. For conversational applications it is natural to operate in *very* low delay mode (i.e. not buffering packets before forwarding them) and having post- picture SEI packetized in their own packets is the only option as soon as the VCL NAL units are fragmented since FUs cannot be aggregated. Having to introduce slices just to avoid FUs and thereby being able to aggregate SEI messages with VCL NAL units does not sound like a compelling alternative. The most reasonable solution for this case is probably to just not perform thinning by removing the SEI messages since they are typically not very large in the first place. However, as far as I understand, it is allowed for an encoder to create a bitstream with two temporal sub-layers (every second picture with TId 0 and every second picture with TId 1) but put post-picture SEI messages for all access units in temporal layer 1 (also for access units in which the picture has TId 0, as a hint of the relative importance of the NAL units). For that case I guess there will be one RTP stream (corresponding to TId 0) completely without any marker bit set, right? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Tue Mar 4 01:41:22 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AFD1A0457 for ; Tue, 4 Mar 2014 01:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 fhSgabXdyYk7 for ; Tue, 4 Mar 2014 01:41:17 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8DD1A0451 for ; Tue, 4 Mar 2014 01:41:16 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-92-53159fb959b4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 67.67.04853.9BF95135; Tue, 4 Mar 2014 10:41:13 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 10:41:12 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/FZ37D8KebEWrOTyjcR0I9prJKgwAgAAu2ACAB1WSwA== Date: Tue, 4 Mar 2014 09:41:12 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje7O+aLBBi82CVucOHKQ3eLSxbNM Fk/WHGN2YPaY8nsjq8eSJT+ZPBZNfcYYwBzFZZOSmpNZllqkb5fAlfFo6l/GgoX6FXentLM2 MF5T62Lk5JAQMJF4fO8jE4QtJnHh3nq2LkYuDiGBE4wSy9bdYwFJCAksZpRY9ZO/i5GDg03A SuL7iwiQsIjAPkaJiXssQWxhARuJt4+7WCHithKN8x8wQthOEnu6+5lBWlkEVCSO73UECfMK eEusufKMCWLVLEaJI4+PgK3iFAiWWLH7E5jNKCArcf87xAnMAuISt57Mh7pTQGLJnvPMELao xMvH/1ghbEWJnWfbmSHq9SRuTJ3CBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsopRsji1uDg33chALzc9t0QvtSgzubg4P0+vOHUTIzCCDm75bbSD8eQe+0OM0hwsSuK8 11lrgoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwOqkdVIj+yerNcWgR01kels9J6ZZb//sr brFRfHL/bKlERczuO2E++hr3b7FIrtCxrRTUKfRVlxNo3c5QOat4RUZX8cHphtPeu82597tA y6fNLEWMv/NjxfFdKddXJu34vk6J4QKLZ9u8pR1H//l/3LQ/WTfhQNVatf4ZDOcaTLa5uy6y niauxFKckWioxVxUnAgAWCPjRW4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/5F9H4vXk4Hje4wYYyoUim9Ju_9c Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:41:19 -0000 Thanks Ye-Kui for the suggested changes. I think they improve the situation= to a large extent, but there is one more thing that I would like change; r= eplacing the "MUST" with a "SHOULD" so that it becomes: "The encoder SHOULD use a picture rate equal to or less than this value. I= n 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." I think this change would be needed in order to not redefine the level defi= nitions of the HEVC specification. A sender that for some reason is not cap= able of producing lower picture rate (e.g. since the material is pre-encode= d) should be allowed to use a picture rate higher than the value of max-fps= , but it must then be aware that the receiver might not be capable of adequ= ately present all decoded pictures. Best Regards Jonatan=20 -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 27 februari 2014 19:20 To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter I am with Magnus here. If a decoder cannot DECODE a picture rate allowed by= a level, then the decoder is not even a confirming decoder. We usually don= 't standardize mechanisms for non-confirming decoders, unless there is a ve= ry strong reason.=20 I think making the following changes (4 places in the first paragraph of th= e semantics) would resolve the issue, with conceptually good semantics, but= the use of the parameter is still practically the same. -----------------Start of the semantics, with suggested changes------------= -------------- max-fps: The value of max-fps is an integer indicating the maximum picture rate in u= nits of hundreds of pictures per second that can be efficiently received (*= **CHANGE TO "effectively processed by the receiver"***). The max-fps param= eter MAY be used to signal that the receiver has a constraint in that it is= not capable of decoding (***CHANGE TO "processing"***) video efficiently = (***CHANGE TO "effectively"***) at the full picture rate that is implied b= y the highest level and, when present, one or more of the parameters max-ls= r, max-lps, and max-br. The value of max-fps is not necessarily the picture rate at which the maxim= um 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 c= ases where the max-fps parameter is absent the encoder is free to choose an= y picture rate according to the highest level and any signaled optional par= ameters. -----------------End of the semantics, with suggested changes--------------= ------------ Please express your opinion if this is not acceptable to you.=20 BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Thursday, February 27, 2014 7:32 AM To: Geir Sandbakken (geirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > #12: The max-fps parameter >=20 > Lessons learned from video conferencing using H.264 showed that a lot=20 > of equipment designed for 30 fps could not handle 60 fps even at=20 > sufficiently low resolution. We do anticipate similar problems when=20 > moving towards 120 fps in H.265. It might not be caused by=20 > limitations in the decoder itself, but that the surrounding media=20 > pipeline will not have been properly tested for 120 fps before being put = into the wild. > If we don't allow for a code point to be used by the "restricted" > equipment, it will be required by the "flexible/proper" to include one.=20 > This is what happened with max-fps in H.264 enabling higher frame=20 > rates compared to lowering them. >=20 I do have concerns with defining a parameter that allow dynamically sub-set= ting the profile and levels that has been defined for HEVC. This can also c= reate interoperability issues with any pre-encoded content to a particular = profile and level. The issues with the media pipeline has they been with the reception of the = high framerate of packets and forwarding them to the decoder or the playbac= k part, i.e. handling of the decoded picture? If it is predominately the later it appears very reasonable to have this as= an informative parameter. I will not make use of higher FPS than X, if you= send me higher than X I will need to reduce that to X or lower before disp= laying it. That way we are not re-defining the profiles, we are ensuring th= at we can handle content encoded within the profile and still by taking car= e of the this in the end of your decoder chain you can protect the rest of = the media framework from not yet supported frame-rates. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Tue Mar 4 01:47:44 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E991A043C for ; Tue, 4 Mar 2014 01:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vBMCNa6gmkim for ; Tue, 4 Mar 2014 01:47:38 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE81A0175 for ; Tue, 4 Mar 2014 01:47:37 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by SN2PR07MB016.namprd07.prod.outlook.com (10.255.174.38) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 4 Mar 2014 09:47:31 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.225]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.225]) with mapi id 15.00.0888.003; Tue, 4 Mar 2014 09:47:30 +0000 From: Stephan Wenger To: Jonatan Samuelsson , "Wang, Ye-Kui" , Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/JKcEkrnbCUK5i7+Hi76mZprJOs8AgAAu2QCAB0rPAIAAAb4A Date: Tue, 4 Mar 2014 09:47:30 +0000 Message-ID: References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.165.122] x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(13464003)(189002)(199002)(24454002)(377424004)(93516002)(77096001)(4396001)(80022001)(74876001)(92726001)(87266001)(92566001)(66066001)(74366001)(93136001)(59766001)(65816001)(81342001)(69226001)(83072002)(47976001)(50986001)(85306002)(74706001)(49866001)(47736001)(95666003)(47446002)(80976001)(63696002)(77982001)(94316002)(46102001)(81816001)(81686001)(87936001)(36756003)(31966008)(74502001)(54316002)(56776001)(85852003)(90146001)(74662001)(86362001)(53806001)(51856001)(79102001)(56816005)(76786001)(94946001)(19580405001)(76796001)(19580395003)(54356001)(95416001)(81542001)(83322001)(76482001)(2656002)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB016; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:31.133.165.122; FPR:EEEFFDCC.ACEA91C3.AAF1324B.4AEAC861.2061D; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1EEC612C5025FE45B965BCAC19362E3B@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/G5n7QBlwbIbwI0FV8I7LOclgC2c Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:47:42 -0000 Let me push back once more. Overwriting the limits of the level definition is common practice in the video conferencing industry, and has been done since staid industry changed to H.264 (which first introduced the level concepts in video compression standards widely deployed in video conferencing). That SHOULD will be ignored, or overwritten by system standards. Is there any technical reason for not allowing overwriting level limitations in scenarios where there is two way negotiation? (I would be fine with a SHOULD, or even the removal of max_fps entirely, in SDP declarative use scenarios. I only care about O/A scenarios.) Stephan On 4.3.14, 9:41, "Jonatan Samuelsson" wrote: >Thanks Ye-Kui for the suggested changes. I think they improve the >situation to a large extent, but there is one more thing that I would >like change; replacing the "MUST" with a "SHOULD" so that it becomes: > >"The encoder SHOULD 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." > >I think this change would be needed in order to not redefine the level >definitions of the HEVC specification. A sender that for some reason is >not capable of producing lower picture rate (e.g. since the material is >pre-encoded) should be allowed to use a picture rate higher than the >value of max-fps, but it must then be aware that the receiver might not >be capable of adequately present all decoded pictures. > >Best Regards Jonatan > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui >Sent: den 27 februari 2014 19:20 >To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >I am with Magnus here. If a decoder cannot DECODE a picture rate allowed >by a level, then the decoder is not even a confirming decoder. We usually >don't standardize mechanisms for non-confirming decoders, unless there is >a very strong reason. > >I think making the following changes (4 places in the first paragraph of >the semantics) would resolve the issue, with conceptually good semantics, >but the use of the parameter is still practically the same. > >-----------------Start of the semantics, with suggested >changes-------------------------- >max-fps: >The value of max-fps is an integer indicating the maximum picture rate in >units of hundreds of pictures per second that can be efficiently received >(***CHANGE TO "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 decoding (***CHANGE TO "processing"***) video >efficiently (***CHANGE TO "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. >-----------------End of the semantics, with suggested >changes-------------------------- > >Please express your opinion if this is not acceptable to you. > >BR, YK > > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus >Westerlund >Sent: Thursday, February 27, 2014 7:32 AM >To: Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: >> #12: The max-fps parameter >>=20 >> Lessons learned from video conferencing using H.264 showed that a lot >> of equipment designed for 30 fps could not handle 60 fps even at >> sufficiently low resolution. We do anticipate similar problems when >> moving towards 120 fps in H.265. It might not be caused by >> limitations in the decoder itself, but that the surrounding media >> pipeline will not have been properly tested for 120 fps before being >>put into the wild. >> If we don't allow for a code point to be used by the "restricted" >> equipment, it will be required by the "flexible/proper" to include one. >> This is what happened with max-fps in H.264 enabling higher frame >> rates compared to lowering them. >>=20 > >I do have concerns with defining a parameter that allow dynamically >sub-setting the profile and levels that has been defined for HEVC. This >can also create interoperability issues with any pre-encoded content to a >particular profile and level. > >The issues with the media pipeline has they been with the reception of >the high framerate of packets and forwarding them to the decoder or the >playback part, i.e. handling of the decoded picture? > >If it is predominately the later it appears very reasonable to have this >as an informative parameter. I will not make use of higher FPS than X, if >you send me higher than X I will need to reduce that to X or lower before >displaying it. That way we are not re-defining the profiles, we are >ensuring that we can handle content encoded within the profile and still >by taking care of the this in the end of your decoder chain you can >protect the rest of the media framework from not yet supported >frame-rates. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From nobody Tue Mar 4 02:42:47 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61141A06A9 for ; Tue, 4 Mar 2014 02:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 vzoYNuNQRLJS for ; Tue, 4 Mar 2014 02:42:42 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CDDA81A069C for ; Tue, 4 Mar 2014 02:42:41 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-7f-5315ae1d8cbc Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EA.7D.23809.D1EA5135; Tue, 4 Mar 2014 11:42:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 11:42:36 +0100 From: Jonatan Samuelsson To: Stephan Wenger , "Wang, Ye-Kui" , Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/FZ37D8KebEWrOTyjcR0I9prJKgwAgAAu2ACAB1WSwP//9wAAgAAcGYA= Date: Tue, 4 Mar 2014 10:42:35 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7cOtFggwPnWS1OHDnIbnHp4lkm i+uNm9gtnqw5xuzA4jHl90ZWjyVLfjJ5LJr6jNFj8fr3jAEsUVw2Kak5mWWpRfp2CVwZu7dn Fzy0rVi9ZjlzA+Ns4y5GDg4JAROJ7Qfiuxg5gUwxiQv31rN1MXJxCAkcYpR43TiNBcJZDOS8 2MMC0sAmYCXx/UUESFxE4BGjROetXcwg3cICNhJvH3exgtgiArYSjfMfMELYfhJtG/exg9gs AioSt859A7N5Bbwlnj+5ywRiCwn8Z5Q4M0kPxOYU0JW4cfoc2BxGAVmJ+9/vsYDYzALiEree zGeCuFRAYsme88wQtqjEy8f/WCFsRYmdZ9uZIer1JG5MncIGYWtLLFv4mhlir6DEyZlPWCYw is5CMnYWkpZZSFpmIWlZwMiyipE9NzEzJ73caBMjMGIObvmtuoPxzjmRQ4zSHCxK4rwf3joH CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBcqc2eY23Dml4Ywvp2w4zsmOTDx5KZg0u6fVWe H933R75+y/bbF3+u0nxrnK49W+cYb3bmjM5omzerv/j+t7+4tk7V/fSR8l/V7lpndA+1p2df Nd/Ir5q1veDYM2b5QCetJT8KhG8VVUpIH02yDvybNffc+mDG3bv+ZCxZN3XeL76DnTpbrhcp sRRnJBpqMRcVJwIAqNYg4mYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/NENV72fYK1ZEpiU2e1HkKDPmQTM Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:42:45 -0000 As far as I know, all other similar parameters in H.264 RTP PL and H.265 RT= P PL extends on the levels defined in the video specification in the sense = that you are capable of expressing for example "I can decode level 4.1 plus= resolutions up to 4K" which can never put a level 4.1 compliant encoder in= a difficult situation (i.e. everything in level 4.1 is still allowed).=20 If the motivation for max-fps is only for SDP O/A, why isn't the SDP attrib= ute a=3Dframerate sufficient? Best Regards Jonatan -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: den 4 mars 2014 10:48 To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (g= eirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter Let me push back once more. Overwriting the limits of the level definition= is common practice in the video conferencing industry, and has been done s= ince staid industry changed to H.264 (which first introduced the level conc= epts in video compression standards widely deployed in video conferencing).= That SHOULD will be ignored, or overwritten by system standards. Is there any technical reason for not allowing overwriting level limitation= s in scenarios where there is two way negotiation? (I would be fine with a SHOULD, or even the removal of max_fps entirely, in= SDP declarative use scenarios. I only care about O/A scenarios.) Stephan On 4.3.14, 9:41, "Jonatan Samuelsson" wrote: >Thanks Ye-Kui for the suggested changes. I think they improve the=20 >situation to a large extent, but there is one more thing that I would=20 >like change; replacing the "MUST" with a "SHOULD" so that it becomes: > >"The encoder SHOULD 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=20 >choose any picture rate according to the highest level and any signaled=20 >optional parameters." > >I think this change would be needed in order to not redefine the level=20 >definitions of the HEVC specification. A sender that for some reason is=20 >not capable of producing lower picture rate (e.g. since the material is >pre-encoded) should be allowed to use a picture rate higher than the=20 >value of max-fps, but it must then be aware that the receiver might not=20 >be capable of adequately present all decoded pictures. > >Best Regards Jonatan > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,=20 >Ye-Kui >Sent: den 27 februari 2014 19:20 >To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >I am with Magnus here. If a decoder cannot DECODE a picture rate=20 >allowed by a level, then the decoder is not even a confirming decoder.=20 >We usually don't standardize mechanisms for non-confirming decoders,=20 >unless there is a very strong reason. > >I think making the following changes (4 places in the first paragraph=20 >of the semantics) would resolve the issue, with conceptually good=20 >semantics, but the use of the parameter is still practically the same. > >-----------------Start of the semantics, with suggested >changes-------------------------- >max-fps: >The value of max-fps is an integer indicating the maximum picture rate=20 >in units of hundreds of pictures per second that can be efficiently=20 >received (***CHANGE TO "effectively processed by the receiver"***). =20 >The max-fps parameter MAY be used to signal that the receiver has a=20 >constraint in that it is not capable of decoding (***CHANGE TO =20 >"processing"***) video efficiently (***CHANGE TO "effectively"***) at=20 >the full picture rate that is implied by the highest level and, when=20 >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=20 >maximum picture size can be sent, it constitutes a constraint on=20 >maximum picture rate for all resolutions. > >Informative note: The max-fps parameter is semantically different from=20 >max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that=20 >max-fps is used to signal a constraint, lowering the maximum picture=20 >rate from what is implied by other parameters. > >The encoder MUST use a picture rate equal to or less than this value. =20 >In cases where the max-fps parameter is absent the encoder is free to=20 >choose any picture rate according to the highest level and any signaled=20 >optional parameters. >-----------------End of the semantics, with suggested >changes-------------------------- > >Please express your opinion if this is not acceptable to you. > >BR, YK > > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus=20 >Westerlund >Sent: Thursday, February 27, 2014 7:32 AM >To: Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: >> #12: The max-fps parameter >>=20 >> Lessons learned from video conferencing using H.264 showed that a lot =20 >>of equipment designed for 30 fps could not handle 60 fps even at =20 >>sufficiently low resolution. We do anticipate similar problems when =20 >>moving towards 120 fps in H.265. It might not be caused by =20 >>limitations in the decoder itself, but that the surrounding media =20 >>pipeline will not have been properly tested for 120 fps before being=20 >>put into the wild. >> If we don't allow for a code point to be used by the "restricted" >> equipment, it will be required by the "flexible/proper" to include one. >> This is what happened with max-fps in H.264 enabling higher frame =20 >>rates compared to lowering them. >>=20 > >I do have concerns with defining a parameter that allow dynamically=20 >sub-setting the profile and levels that has been defined for HEVC. This=20 >can also create interoperability issues with any pre-encoded content to=20 >a particular profile and level. > >The issues with the media pipeline has they been with the reception of=20 >the high framerate of packets and forwarding them to the decoder or the=20 >playback part, i.e. handling of the decoded picture? > >If it is predominately the later it appears very reasonable to have=20 >this as an informative parameter. I will not make use of higher FPS=20 >than X, if you send me higher than X I will need to reduce that to X or=20 >lower before displaying it. That way we are not re-defining the=20 >profiles, we are ensuring that we can handle content encoded within the=20 >profile and still by taking care of the this in the end of your decoder=20 >chain you can protect the rest of the media framework from not yet=20 >supported frame-rates. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From nobody Tue Mar 4 06:18:49 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D071A015D for ; Tue, 4 Mar 2014 06:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FRT_BELOW2=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 jxlzjRJ3h8fy for ; Tue, 4 Mar 2014 06:18:45 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 904121A0128 for ; Tue, 4 Mar 2014 06:18:44 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so5025731wgh.3 for ; Tue, 04 Mar 2014 06:18:41 -0800 (PST) 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=KWQjMXv6t5kQKIN9eWhtqRCLGK4Y2guA8wZgwRP6uU0=; b=jOzoYqGUVsj/eiTqRyEZpbH6B+rLRWYyl7wWs0OKJepqQkTX/Bjxl2LGMq2ggOP39Z 96MdJc/GufSeD2vuM3OUjE8hBjIz/RyOE0gjLrbiKY2074txci/JZX0NdKHhv4avQX21 MzabtpTIDA9UCBjaxz4xUq6PBoKdOHkWVEVxDE0ttI1MF+6vh2xMoRcfNl+qUJ+/6/mC WzIn6bHmkPphcpwCfsPU0k5JxsCsXYlEz1ls46u7sEpvkICX0w/07wqpjjLrcik7iUN9 k27kB1VImAE3Un3/Ct+sVWpNOAIHQymPL3Tyv6P76FJf/GAZ+kDefagU+IJhvsAMtBAB iFoQ== X-Received: by 10.194.87.195 with SMTP id ba3mr18284788wjb.53.1393942720878; Tue, 04 Mar 2014 06:18:40 -0800 (PST) Received: from RoniE ([2001:67c:370:160:50f8:ad6:f20a:2521]) by mx.google.com with ESMTPSA id ju6sm52657759wjc.1.2014.03.04.06.18.37 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Mar 2014 06:18:40 -0800 (PST) From: "Roni Even" To: "'IANA Media types'" Date: Tue, 4 Mar 2014 16:18:32 +0200 Message-ID: <030d01cf37b4$a33dc8d0$e9b95a70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030E_01CF37C5.66CF4B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac83tAwAj7yTRVxBQ9yQcl9tpkgGwg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/rge4DJA4huEgkYRb-1pP0PajlBs Cc: draft-ietf-payload-g7110@tools.ietf.org, payload@ietf.org Subject: [payload] registeration of G7110 media subtype for G.711.0 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:18:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030E_01CF37C5.66CF4B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, draft-ietf-payload-g7110-02 has passed Working Group Last Call in the Payload Working Group. The document registers media subtype G7110. The new registrations are in Section 5.1 of the document and is also given bellow. Comments on the registration are welcome. Thanks Roni Even Payload WG co-chair Media Type Registration Type name: audio Subtype name: G7110 Required parameters: rate: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate used with G.711 encoding is 8000, but other rates may be specified. The default rate is 8000. complaw: Indicates the companding law (A-law or mu-law) employed. The case-insensitive values are "al" or "mu" for A-law and mu-law, respectively. Optional parameters: channels: See RFC 4566 [RFC4566] for definition. Specifies how many audio streams are represented in the G.711.0 payload and MUST be present if the number of channels is greater than one. This parameter defaults to 1 if not present (as per RFC 4566) and is typically a non-zero small-valued positive integer. It is expected that implementations that specify multiple channels will also define a mechanism to map the channels appropriately within their system design, otherwise the channel order specified in RFC 3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right, center, ... ). maxptime: See RFC 4566 [RFC4566] for definition. ptime: See RFC 4566 [RFC4566] for definition. The inclusion of "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an application specific reason not to include it (e.g., an application that has a variable ptime on a packet-by-packet basis). For constant ptime applications, it is considered good form to include "ptime" in the SDP for session diagnostic purposes. For the constant ptime multiple channel case described in Section 4.2.2, the inclusion of "ptime" can provide a desirable payload check. Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 6838 [RFC6838]) compressed as per ITU-T Rec. G.711.0. Security considerations: See Section 10. Interoperability considerations: none Published specification: ITU-T Rec. G.711.0 and RFC XXXX. [ RFC Editor: please replace XXXXX with a reference to this RFC ] Applications that use this media type: Although initially conceived for VoIP, the use of G.711.0, like G.711 before it, may find use within audio and video streaming and /or conferencing applications for the audio portion of those applications. Additional information: The following applies to stored-file transfer methods: Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law encodings respectively, see Section 6). File Extensions: None Macintosh file type code: None Object identifier or OIL: None Person & email address to contact for further information: Michael A. Ramalho or Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. Author: Michael A. Ramalho Change controller: IETF Payload working group delegated from the IESG. ------=_NextPart_000_030E_01CF37C5.66CF4B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

draft-iet=
f-payload-g7110-02 has passed =
Working Group Last Call in the Payload Working Group. =

The =
document registers media subtype G7110.  =

 =

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

Comments on the registration are = welcome.

 

Thanks

Roni = Even

Payload WG = co-chair

 

 

 

 

Media Type = Registration

 

   Type name: = audio

 

   Subtype name: = G7110

 

   Required = parameters:

 

      rate: The RTP = timestamp clock rate, which is equal to the = sampling

      rate.  The = typical rate used with G.711 encoding is 8000, = but

      other rates may be = specified.  The default rate is 8000.

 

      complaw: Indicates = the companding law (A-law or mu-law) employed.

      The = case-insensitive values are "al" or "mu" for A-law = and mu-law,

      = respectively.

 

   Optional = parameters:

 

      channels: See RFC = 4566 [RFC4566] for definition.  Specifies = how

      many audio streams = are represented in the G.711.0 payload and MUST

      be present if the = number of channels is greater than one.  = This

      parameter defaults = to 1 if not present (as per RFC 4566) and is

      typically a = non-zero small-valued positive integer.  It = is

      expected that = implementations that specify multiple channels = will

      also define a = mechanism to map the channels appropriately = within

      their system = design, otherwise the channel order specified in = RFC

      3551 [RFC3551] = Section 4.1 will be assumed (e.g., left, right,

      center, ... = ).

 

      maxptime: See RFC = 4566 [RFC4566] for definition.

 

      ptime: See RFC 4566 = [RFC4566] for definition.  The inclusion of

      "ptime" = is RECOMMENDED and SHOULD be in the SDP unless there is = an

      application = specific reason not to include it (e.g., an

      application that = has a variable ptime on a packet-by-packet

      basis).  For = constant ptime applications, it is considered = good

      form to include = "ptime" in the SDP for session = diagnostic

      purposes.  For = the constant ptime multiple channel case = described

      in Section 4.2.2, = the inclusion of "ptime" can provide a = desirable

      payload = check.

 

   Encoding = considerations:

 

      This media type is = framed binary data (see Section 4.8 in RFC 6838

      [RFC6838]) = compressed as per ITU-T Rec. G.711.0.

 

   Security = considerations:

 

      See Section = 10.

 

   = Interoperability considerations: none

 

   Published = specification:

 

      ITU-T Rec. G.711.0 = and RFC XXXX.

 

      [ RFC Editor: = please replace XXXXX with a reference to this RFC = ]

 

   Applications = that use this media type:

 

      Although initially = conceived for VoIP, the use of G.711.0, like

      G.711 before it, = may find use within audio and video streaming = and

      /or conferencing = applications for the audio portion of those

      = applications.

 

   Additional = information:

 

   The following = applies to stored-file transfer methods:

 

         = Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or = MU-law

         = encodings respectively, see Section 6).

 

=         File Extensions: = None

 

         = Macintosh file type code: None

 

         = Object identifier or OIL: None

 

   Person & = email address to contact for further = information:

 

      Michael A. Ramalho = <mramalho@cisco.com> or = <mar42@cornell.edu>

 

   Intended = usage: COMMON

 

   Restrictions = on usage:

 

      This media type = depends on RTP framing, and hence is only = defined

      for transfer via = RTP [RFC3550].  Transport within other = framing

      protocols is not = defined at this time.

 

   Author: = Michael A. Ramalho

 

   Change = controller:

 

 

      IETF Payload = working group delegated from the IESG.

 

 

------=_NextPart_000_030E_01CF37C5.66CF4B60-- From nobody Tue Mar 4 09:16:40 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C7E1A025E for ; Tue, 4 Mar 2014 09:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 plbkkXKHCT9t for ; Tue, 4 Mar 2014 09:16:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id CAE641A0251 for ; Tue, 4 Mar 2014 09:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393953385; x=1425489385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7BxfwuRpf10QCDdTYsCDggYriz0EoNPL6SacusA1nrs=; b=LzYksPM3/+s3y9CaUV086ppr5hoZDVZDk3CXo8ayqbTuAUmfkDcSPtrC EhnjDRIgEcPvCN2VwMXYPUTJ1FeZf9YV3pXjJJm8e1t4T70bi1/2kebmF M5GhyYnPbRhS4qnBEkW4DIVkLD1oMGMk4KKfMLPBTgrO2JLjOFmw5V9FB U=; X-IronPort-AV: E=McAfee;i="5400,1158,7367"; a="18309046" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 04 Mar 2014 09:16:25 -0800 X-IronPort-AV: E=Sophos;i="4.97,585,1389772800"; d="scan'208";a="28011875" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 09:16:24 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 09:16:24 -0800 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , Stephan Wenger , Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/tQCfPN0v2EGxR7CgdZmQz5rJwOwA//+msXCAB9L2AIAAAcMAgAAPZID//+cXUA== Date: Tue, 4 Mar 2014 17:16:23 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D5BA4@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.56.80] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Kz4gBkBZL4bsjV8qKMd4rR7lKmg Cc: "Tom Kristensen \(tomkrist@cisco.com\)" Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:16:33 -0000 Let me pull Tom into the discussion :-) Personally I am OK with the SHOULD = language here too as I don't have a good counter argument against Jonatan's= comment.=20 Tom, would the SHOULD language be fine with you as well (as the proponent o= f this parameter)? Do you see any technical problem with this? BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 Sent: Tuesday, March 04, 2014 2:43 AM To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (geirs= and); payload@ietf.org Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter As far as I know, all other similar parameters in H.264 RTP PL and H.265 RT= P PL extends on the levels defined in the video specification in the sense = that you are capable of expressing for example "I can decode level 4.1 plus= resolutions up to 4K" which can never put a level 4.1 compliant encoder in= a difficult situation (i.e. everything in level 4.1 is still allowed).=20 If the motivation for max-fps is only for SDP O/A, why isn't the SDP attrib= ute a=3Dframerate sufficient? Best Regards Jonatan -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org] Sent: den 4 mars 2014 10:48 To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (g= eirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter Let me push back once more. Overwriting the limits of the level definition= is common practice in the video conferencing industry, and has been done s= ince staid industry changed to H.264 (which first introduced the level conc= epts in video compression standards widely deployed in video conferencing).= That SHOULD will be ignored, or overwritten by system standards. Is there any technical reason for not allowing overwriting level limitation= s in scenarios where there is two way negotiation? (I would be fine with a SHOULD, or even the removal of max_fps entirely, in= SDP declarative use scenarios. I only care about O/A scenarios.) Stephan On 4.3.14, 9:41, "Jonatan Samuelsson" wrote: >Thanks Ye-Kui for the suggested changes. I think they improve the=20 >situation to a large extent, but there is one more thing that I would=20 >like change; replacing the "MUST" with a "SHOULD" so that it becomes: > >"The encoder SHOULD 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=20 >choose any picture rate according to the highest level and any signaled=20 >optional parameters." > >I think this change would be needed in order to not redefine the level=20 >definitions of the HEVC specification. A sender that for some reason is=20 >not capable of producing lower picture rate (e.g. since the material is >pre-encoded) should be allowed to use a picture rate higher than the=20 >value of max-fps, but it must then be aware that the receiver might not=20 >be capable of adequately present all decoded pictures. > >Best Regards Jonatan > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,=20 >Ye-Kui >Sent: den 27 februari 2014 19:20 >To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >I am with Magnus here. If a decoder cannot DECODE a picture rate=20 >allowed by a level, then the decoder is not even a confirming decoder. >We usually don't standardize mechanisms for non-confirming decoders,=20 >unless there is a very strong reason. > >I think making the following changes (4 places in the first paragraph=20 >of the semantics) would resolve the issue, with conceptually good=20 >semantics, but the use of the parameter is still practically the same. > >-----------------Start of the semantics, with suggested >changes-------------------------- >max-fps: >The value of max-fps is an integer indicating the maximum picture rate=20 >in units of hundreds of pictures per second that can be efficiently=20 >received (***CHANGE TO "effectively processed by the receiver"***). >The max-fps parameter MAY be used to signal that the receiver has a=20 >constraint in that it is not capable of decoding (***CHANGE TO >"processing"***) video efficiently (***CHANGE TO "effectively"***) at=20 >the full picture rate that is implied by the highest level and, when=20 >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=20 >maximum picture size can be sent, it constitutes a constraint on=20 >maximum picture rate for all resolutions. > >Informative note: The max-fps parameter is semantically different from=20 >max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that=20 >max-fps is used to signal a constraint, lowering the maximum picture=20 >rate from what is implied by other parameters. > >The encoder MUST use a picture rate equal to or less than this value. =20 >In cases where the max-fps parameter is absent the encoder is free to=20 >choose any picture rate according to the highest level and any signaled=20 >optional parameters. >-----------------End of the semantics, with suggested >changes-------------------------- > >Please express your opinion if this is not acceptable to you. > >BR, YK > > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus=20 >Westerlund >Sent: Thursday, February 27, 2014 7:32 AM >To: Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: >> #12: The max-fps parameter >>=20 >> Lessons learned from video conferencing using H.264 showed that a lot=20 >>of equipment designed for 30 fps could not handle 60 fps even at=20 >>sufficiently low resolution. We do anticipate similar problems when=20 >>moving towards 120 fps in H.265. It might not be caused by=20 >>limitations in the decoder itself, but that the surrounding media=20 >>pipeline will not have been properly tested for 120 fps before being=20 >>put into the wild. >> If we don't allow for a code point to be used by the "restricted" >> equipment, it will be required by the "flexible/proper" to include one. >> This is what happened with max-fps in H.264 enabling higher frame=20 >>rates compared to lowering them. >>=20 > >I do have concerns with defining a parameter that allow dynamically=20 >sub-setting the profile and levels that has been defined for HEVC. This=20 >can also create interoperability issues with any pre-encoded content to=20 >a particular profile and level. > >The issues with the media pipeline has they been with the reception of=20 >the high framerate of packets and forwarding them to the decoder or the=20 >playback part, i.e. handling of the decoded picture? > >If it is predominately the later it appears very reasonable to have=20 >this as an informative parameter. I will not make use of higher FPS=20 >than X, if you send me higher than X I will need to reduce that to X or=20 >lower before displaying it. That way we are not re-defining the=20 >profiles, we are ensuring that we can handle content encoded within the=20 >profile and still by taking care of the this in the end of your decoder=20 >chain you can protect the rest of the media framework from not yet=20 >supported frame-rates. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From nobody Tue Mar 4 09:26:53 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44A1A022B for ; Tue, 4 Mar 2014 09:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 GAZ7zchzdhKW for ; Tue, 4 Mar 2014 09:26:49 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4821F1A0240 for ; Tue, 4 Mar 2014 09:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393954006; x=1425490006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eHhki3pGQE1x13Oo8/DvWd4gYDpanZOvmo/pySQ54NQ=; b=q7vj+SDd38m+lyu8KGuVrOgzdv4RnFTUCNNZndNvkdzUy2q5H75RcLUC 4Kyzuq1HEN3QNp3BnM2IfOmiBLEYblXNjJ6BIIQK5UNYtJUyVBa+U235G Kk6QukotT8K+ZMaq4smaxzqZkqjYQlsqv27qt/TWfktfOGY1GG9A6sJvO o=; X-IronPort-AV: E=McAfee;i="5400,1158,7367"; a="60174521" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 04 Mar 2014 09:26:46 -0800 X-IronPort-AV: E=Sophos;i="4.97,586,1389772800"; d="scan'208";a="28012789" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 09:26:45 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc15.na.qualcomm.com ([129.46.52.215]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 09:20:36 -0800 From: "Wang, Ye-Kui" To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" , "jonatan.samuelsson@ericsson.com" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1A Date: Tue, 4 Mar 2014 17:20:35 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> In-Reply-To: <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.56.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/QXoTxyDUNC6ATX0lWeex2Fo4hWw Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:26:52 -0000 SGkgSm9uYXRhbiwNCg0KSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIGV4 YW1wbGU6DQoNCiJIb3dldmVyLCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCBpdCBpcyBhbGxvd2Vk IGZvciBhbiBlbmNvZGVyIHRvIGNyZWF0ZSBhICBiaXRzdHJlYW0gd2l0aCB0d28gdGVtcG9yYWwg c3ViLWxheWVycyAoZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0aCBUSWQgMCAgYW5kIGV2ZXJ5IHNl Y29uZCBwaWN0dXJlIHdpdGggVElkIDEpIGJ1dCBwdXQgcG9zdC1waWN0dXJlIFNFSSBtZXNzYWdl cyBmb3IgIGFsbCBhY2Nlc3MgdW5pdHMgaW4gdGVtcG9yYWwgbGF5ZXIgMSAoYWxzbyBmb3IgYWNj ZXNzIHVuaXRzIGluIHdoaWNoIHRoZSAgcGljdHVyZSBoYXMgVElkIDAsIGFzIGEgaGludCBvZiB0 aGUgcmVsYXRpdmUgaW1wb3J0YW5jZSBvZiB0aGUgTkFMIHVuaXRzKS4gRm9yIHRoYXQgY2FzZSBJ IGd1ZXNzIHRoZXJlIHdpbGwgYmUgb25lIFJUUCBzdHJlYW0gKGNvcnJlc3BvbmRpbmcgdG8gVElk IDApIGNvbXBsZXRlbHkgd2l0aG91dCBhbnkgbWFya2VyIGJpdCBzZXQsIHJpZ2h0PyINCg0KQ291 bGQgeW91IHBsZWFzZSBjaGVjayB3aGV0aGVyIGl0IGNhbiBiZSBjbGFyaWZpZWQgYSBiaXQ/DQoN CkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF5bG9hZCBpc3N1 ZSB0cmFja2VyIFttYWlsdG86dHJhYytwYXlsb2FkQHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KU2Vu dDogTW9uZGF5LCBNYXJjaCAwMywgMjAxNCAyOjExIFBNDQpUbzogZHJhZnQtaWV0Zi1wYXlsb2Fk LXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnOyBXYW5nLCBZZS1LdWk7IHN0ZXdlQHN0ZXdlLm9yZzsg am9uYXRhbi5zYW11ZWxzc29uQGVyaWNzc29uLmNvbQ0KQ2M6IHBheWxvYWRAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcGF5bG9hZF0gIzEwIChydHAtaDI2NSk6IE1hcmtlciBiaXQgaW4gSC4yNjUv SEVWQw0KDQojMTA6IE1hcmtlciBiaXQgaW4gSC4yNjUvSEVWQw0KDQoNCkNvbW1lbnQgKGJ5IGpv bmF0YW4uc2FtdWVsc3NvbkBlcmljc3Nvbi5jb20pOg0KDQogVGhhbmtzIFN0ZWZhbiBmb3IgdGhl IGNvbW1lbnRzIGFuZCB0aGUgZXhhbXBsZS4gSXQgaXMgZXhhY3RseSB0aGlzIGtpbmQgb2YgIGNh c2VzIEknbSBjb25jZXJuZWQgYWJvdXQgYnV0IEkgd291bGRuJ3QgY2hhcmFjdGVyaXplIHRoZW0g YXMgZXhvdGljLiBGb3IgIGNvbnZlcnNhdGlvbmFsIGFwcGxpY2F0aW9ucyBpdCBpcyBuYXR1cmFs IHRvIG9wZXJhdGUgaW4gKnZlcnkqIGxvdyBkZWxheSAgbW9kZSAoaS5lLiBub3QgYnVmZmVyaW5n IHBhY2tldHMgYmVmb3JlIGZvcndhcmRpbmcgdGhlbSkgYW5kIGhhdmluZyBwb3N0LSAgcGljdHVy ZSBTRUkgcGFja2V0aXplZCBpbiB0aGVpciBvd24gcGFja2V0cyBpcyB0aGUgb25seSBvcHRpb24g YXMgc29vbiBhcyAgdGhlIFZDTCBOQUwgdW5pdHMgYXJlIGZyYWdtZW50ZWQgc2luY2UgRlVzIGNh bm5vdCBiZSBhZ2dyZWdhdGVkLiBIYXZpbmcgdG8gIGludHJvZHVjZSBzbGljZXMganVzdCB0byBh dm9pZCBGVXMgYW5kIHRoZXJlYnkgYmVpbmcgYWJsZSB0byBhZ2dyZWdhdGUgU0VJICBtZXNzYWdl cyB3aXRoIFZDTCBOQUwgdW5pdHMgZG9lcyBub3Qgc291bmQgbGlrZSBhIGNvbXBlbGxpbmcgYWx0 ZXJuYXRpdmUuDQoNCiBUaGUgbW9zdCByZWFzb25hYmxlIHNvbHV0aW9uIGZvciB0aGlzIGNhc2Ug aXMgcHJvYmFibHkgdG8ganVzdCBub3QgcGVyZm9ybSAgdGhpbm5pbmcgYnkgcmVtb3ZpbmcgdGhl IFNFSSBtZXNzYWdlcyBzaW5jZSB0aGV5IGFyZSB0eXBpY2FsbHkgbm90IHZlcnkgIGxhcmdlIGlu IHRoZSBmaXJzdCBwbGFjZS4NCg0KIEhvd2V2ZXIsIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIGl0 IGlzIGFsbG93ZWQgZm9yIGFuIGVuY29kZXIgdG8gY3JlYXRlIGEgIGJpdHN0cmVhbSB3aXRoIHR3 byB0ZW1wb3JhbCBzdWItbGF5ZXJzIChldmVyeSBzZWNvbmQgcGljdHVyZSB3aXRoIFRJZCAwICBh bmQgZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0aCBUSWQgMSkgYnV0IHB1dCBwb3N0LXBpY3R1cmUg U0VJIG1lc3NhZ2VzIGZvciAgYWxsIGFjY2VzcyB1bml0cyBpbiB0ZW1wb3JhbCBsYXllciAxIChh bHNvIGZvciBhY2Nlc3MgdW5pdHMgaW4gd2hpY2ggdGhlICBwaWN0dXJlIGhhcyBUSWQgMCwgYXMg YSBoaW50IG9mIHRoZSByZWxhdGl2ZSBpbXBvcnRhbmNlIG9mIHRoZSBOQUwgdW5pdHMpLg0KIEZv ciB0aGF0IGNhc2UgSSBndWVzcyB0aGVyZSB3aWxsIGJlIG9uZSBSVFAgc3RyZWFtIChjb3JyZXNw b25kaW5nIHRvIFRJZA0KIDApIGNvbXBsZXRlbHkgd2l0aG91dCBhbnkgbWFya2VyIGJpdCBzZXQs IHJpZ2h0Pw0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1wYXlsb2FkLQ0KICBqb25hdGFuLnNhbXVlbHNzb25A ZXJpY3Nzb24uY29tICAgIHwgIHJ0cC1oMjY1QHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBk ZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAg bWFqb3IgICAgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBydHAt aDI2NSAgICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjogIDIuMA0KIFNldmVyaXR5OiAgLSAg ICAgICAgICAgICAgICAgICAgICAgIHwgIFJlc29sdXRpb246DQogS2V5d29yZHM6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcGF5bG9hZC90cmFjL3RpY2tldC8xMCNjb21tZW50OjM+DQpwYXlsb2FkIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGF5bG9hZC8+DQoNCg== From nobody Tue Mar 4 13:28:26 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407A1A0316 for ; Tue, 4 Mar 2014 13:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 fVkMp2I0vp68 for ; Tue, 4 Mar 2014 13:28:22 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 952E51A0305 for ; Tue, 4 Mar 2014 13:28:21 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-6a-531645703e4e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 35.4B.04853.07546135; Tue, 4 Mar 2014 22:28:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 22:28:16 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPMkf2CFY3DR2ikEyoFpWG3Tj1ZprP5Z+AgAFBKICAAE+AEA== Date: Tue, 4 Mar 2014 21:28:16 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+JvjW6hq1iwQdsnNotTF/exWly6eJbJ 4nrjJnaLxpmmFk/WHGN2YPVYsuQnk8eiqc8YPRavf8/o8eXyZzaPn3s2swawRnHZpKTmZJal FunbJXBlrFq2mqngkn7F2gs9bA2MW/S6GDk5JARMJHZOWsMOYYtJXLi3nq2LkYtDSOAEo8TV NVuYIJzFjBIP3j8Gcjg42ASsJL6/iACJiwi8Y5RYdK6NFaSbWUBT4tDnx2wgtrCAvcS9+z8Y QWwRAQeJ01PXM0PYThLtO7+B1bMIqEic2LkcLM4r4C0x+dwOZohlZxglLvW8ZwFJcAoES/w/ 2QhmMwrIStz/fo8FYpm4xK0n85kgzhaQWLLnPDOELSrx8vE/VghbSaJxyRNWkKNBjlu/Sx+i VVFiSvdDdoi9ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2RxanFxbrqRgV5uem6JXmpR ZnJxcX6eXnHqJkZgBB7c8ttoB+PJPfaHGKU5WJTEea+z1gQJCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYJz+pz8lrGnx/EwlkccTf2rd6U/4KPbwgN8Upe4gA+vKnam1/HNXXV75Vkev8Y1o bdAaO1OBDU//8DAq2N63E7DurjKe82P6prCEWIG8nT0f/szYX+s48f/Gtb4fs19NTVczlr/k 3SzCaih1u/yGXt4E1QcRm/QXWN4reTFPW3TzH/0FVqpmv5RYijMSDbWYi4oTAeAVnJmOAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/tGR2fMaHG2jTgFWO4J2oCBRU7Uw Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:28:24 -0000 RGVhciBZZS1LdWksDQoNCkxldCBtZSB0cnkgdG8gbWFrZSB0aGUgZXhhbXBsZSBtb3JlIHNwZWNp ZmljIChhbmQgdGhlbiBhbHNvIHNlZSBpZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGUgbXVsdGktc3Ry ZWFtIHRyYW5zbWlzc2lvbiBjb25jZXB0IGNvcnJlY3RseSkuDQoNCkFzc3VtZSB0aGF0IHRoZSBz ZW5kZXIgcHV0cyBhbGwgTkFMIHVuaXRzIHdpdGggVElkIDAgaW4gb25lIFJUUCBzdHJlYW0gKHN0 cmVhbSBBKSBhbmQgYWxsIE5BTCB1bml0cyB3aXRoIFRJZCAxIGluIGFub3RoZXIgUlRQIHN0cmVh bSAoc3RyZWFtIEIpLiBOb3cgZm9yIHRoZSBmaXJzdCBlbmNvZGVkIHBpY3R1cmUgdGhlIFZDTCBO QUwgdW5pdHMgYXJlIGFzc2lnbmVkIFRJZCAwIGFuZCB0aGVuIGEgZGVjb2RlZCBwaWN0dXJlIGhh c2ggU0VJIG1lc3NhZ2UgaXMgY3JlYXRlZCBpbiB0aGUgc2FtZSBhY2Nlc3MgdW5pdCBidXQgaXMg Z2l2ZW4gVElkIDEuIFRoZW4gdGhlIG1hcmtlciBiaXQgd2lsbCBiZSBzZXQgb24gdGhlIHBhY2tl dCBjb250YWluaW5nIHRoZSBkZWNvZGVkIHBpY3R1cmUgaGFzaCBTRUkgbWVzc2FnZSB3aGljaCBp cyBwdXQgaW4gc3RyZWFtIEIuIElmIHRoaXMgc2NoZW1lIGlzIGFwcGxpZWQgZm9yIGFsbCBhY2Nl c3MgdW5pdHMsIHN0cmVhbSBBIHdpbGwgbm90IGNvbnRhaW4gYW55IHBhY2tldHMgd2l0aCB0aGUg bWFya2VyIGJpdCBzZXQgc2luY2UgdGhlc2UgYXJlIGFsbCBwdXQgaW4gc3RyZWFtIEIuIEEgTUFO RSB0aGF0IG9ubHkgd2FudHMgdG8gZm9yd2FyZCBzdHJlYW0gQSB0byBhIHJlY2VpdmVyIHdvdWxk IGJlIHJlcXVpcmVkIHRvIHBlcmZvcm0gYW5hbHlzaXMgKGFuZCBwcm9iYWJseSBpbnRyb2R1Y2Ug ZGVsYXkpIGluIG9yZGVyIHRvIGNvcnJlY3RseSBjaGFuZ2UgdGhlIG1hcmtlciBiaXQgb24gdGhl ICJuZXciIGxhc3QgcGFja2V0IG9mIHRoZSBhY2Nlc3MgdW5pdC4NCg0KSXMgdGhhdCBjb3JyZWN0 LCBvciBoYXZlIEkgbWlzaW50ZXJwcmV0ZWQgYW55dGhpbmc/DQoNCkJlc3QgUmVnYXJkcyBKb25h dGFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYW5nLCBZZS1LdWkgW21h aWx0bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbV0gDQpTZW50OiBkZW4gNCBtYXJzIDIwMTQgMTg6 MjENClRvOiBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2 NUB0b29scy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uub3JnOyBKb25hdGFuIFNhbXVlbHNzb24NCkNj OiBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3BheWxvYWRdICMxMCAocnRwLWgyNjUp OiBNYXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KSGkgSm9uYXRhbiwNCg0KSSBkbyBub3QgZnVs bHkgdW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIGV4YW1wbGU6DQoNCiJIb3dldmVyLCBhcyBmYXIg YXMgSSB1bmRlcnN0YW5kLCBpdCBpcyBhbGxvd2VkIGZvciBhbiBlbmNvZGVyIHRvIGNyZWF0ZSBh ICBiaXRzdHJlYW0gd2l0aCB0d28gdGVtcG9yYWwgc3ViLWxheWVycyAoZXZlcnkgc2Vjb25kIHBp Y3R1cmUgd2l0aCBUSWQgMCAgYW5kIGV2ZXJ5IHNlY29uZCBwaWN0dXJlIHdpdGggVElkIDEpIGJ1 dCBwdXQgcG9zdC1waWN0dXJlIFNFSSBtZXNzYWdlcyBmb3IgIGFsbCBhY2Nlc3MgdW5pdHMgaW4g dGVtcG9yYWwgbGF5ZXIgMSAoYWxzbyBmb3IgYWNjZXNzIHVuaXRzIGluIHdoaWNoIHRoZSAgcGlj dHVyZSBoYXMgVElkIDAsIGFzIGEgaGludCBvZiB0aGUgcmVsYXRpdmUgaW1wb3J0YW5jZSBvZiB0 aGUgTkFMIHVuaXRzKS4gRm9yIHRoYXQgY2FzZSBJIGd1ZXNzIHRoZXJlIHdpbGwgYmUgb25lIFJU UCBzdHJlYW0gKGNvcnJlc3BvbmRpbmcgdG8gVElkIDApIGNvbXBsZXRlbHkgd2l0aG91dCBhbnkg bWFya2VyIGJpdCBzZXQsIHJpZ2h0PyINCg0KQ291bGQgeW91IHBsZWFzZSBjaGVjayB3aGV0aGVy IGl0IGNhbiBiZSBjbGFyaWZpZWQgYSBiaXQ/DQoNCkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogcGF5bG9hZCBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytwYXls b2FkQHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBNYXJjaCAwMywgMjAxNCAy OjExIFBNDQpUbzogZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnOyBX YW5nLCBZZS1LdWk7IHN0ZXdlQHN0ZXdlLm9yZzsgam9uYXRhbi5zYW11ZWxzc29uQGVyaWNzc29u LmNvbQ0KQ2M6IHBheWxvYWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF5bG9hZF0gIzEwIChy dHAtaDI2NSk6IE1hcmtlciBiaXQgaW4gSC4yNjUvSEVWQw0KDQojMTA6IE1hcmtlciBiaXQgaW4g SC4yNjUvSEVWQw0KDQoNCkNvbW1lbnQgKGJ5IGpvbmF0YW4uc2FtdWVsc3NvbkBlcmljc3Nvbi5j b20pOg0KDQogVGhhbmtzIFN0ZWZhbiBmb3IgdGhlIGNvbW1lbnRzIGFuZCB0aGUgZXhhbXBsZS4g SXQgaXMgZXhhY3RseSB0aGlzIGtpbmQgb2YgIGNhc2VzIEknbSBjb25jZXJuZWQgYWJvdXQgYnV0 IEkgd291bGRuJ3QgY2hhcmFjdGVyaXplIHRoZW0gYXMgZXhvdGljLiBGb3IgIGNvbnZlcnNhdGlv bmFsIGFwcGxpY2F0aW9ucyBpdCBpcyBuYXR1cmFsIHRvIG9wZXJhdGUgaW4gKnZlcnkqIGxvdyBk ZWxheSAgbW9kZSAoaS5lLiBub3QgYnVmZmVyaW5nIHBhY2tldHMgYmVmb3JlIGZvcndhcmRpbmcg dGhlbSkgYW5kIGhhdmluZyBwb3N0LSAgcGljdHVyZSBTRUkgcGFja2V0aXplZCBpbiB0aGVpciBv d24gcGFja2V0cyBpcyB0aGUgb25seSBvcHRpb24gYXMgc29vbiBhcyAgdGhlIFZDTCBOQUwgdW5p dHMgYXJlIGZyYWdtZW50ZWQgc2luY2UgRlVzIGNhbm5vdCBiZSBhZ2dyZWdhdGVkLiBIYXZpbmcg dG8gIGludHJvZHVjZSBzbGljZXMganVzdCB0byBhdm9pZCBGVXMgYW5kIHRoZXJlYnkgYmVpbmcg YWJsZSB0byBhZ2dyZWdhdGUgU0VJICBtZXNzYWdlcyB3aXRoIFZDTCBOQUwgdW5pdHMgZG9lcyBu b3Qgc291bmQgbGlrZSBhIGNvbXBlbGxpbmcgYWx0ZXJuYXRpdmUuDQoNCiBUaGUgbW9zdCByZWFz b25hYmxlIHNvbHV0aW9uIGZvciB0aGlzIGNhc2UgaXMgcHJvYmFibHkgdG8ganVzdCBub3QgcGVy Zm9ybSAgdGhpbm5pbmcgYnkgcmVtb3ZpbmcgdGhlIFNFSSBtZXNzYWdlcyBzaW5jZSB0aGV5IGFy ZSB0eXBpY2FsbHkgbm90IHZlcnkgIGxhcmdlIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KIEhvd2V2 ZXIsIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIGl0IGlzIGFsbG93ZWQgZm9yIGFuIGVuY29kZXIg dG8gY3JlYXRlIGEgIGJpdHN0cmVhbSB3aXRoIHR3byB0ZW1wb3JhbCBzdWItbGF5ZXJzIChldmVy eSBzZWNvbmQgcGljdHVyZSB3aXRoIFRJZCAwICBhbmQgZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0 aCBUSWQgMSkgYnV0IHB1dCBwb3N0LXBpY3R1cmUgU0VJIG1lc3NhZ2VzIGZvciAgYWxsIGFjY2Vz cyB1bml0cyBpbiB0ZW1wb3JhbCBsYXllciAxIChhbHNvIGZvciBhY2Nlc3MgdW5pdHMgaW4gd2hp Y2ggdGhlICBwaWN0dXJlIGhhcyBUSWQgMCwgYXMgYSBoaW50IG9mIHRoZSByZWxhdGl2ZSBpbXBv cnRhbmNlIG9mIHRoZSBOQUwgdW5pdHMpLg0KIEZvciB0aGF0IGNhc2UgSSBndWVzcyB0aGVyZSB3 aWxsIGJlIG9uZSBSVFAgc3RyZWFtIChjb3JyZXNwb25kaW5nIHRvIFRJZA0KIDApIGNvbXBsZXRl bHkgd2l0aG91dCBhbnkgbWFya2VyIGJpdCBzZXQsIHJpZ2h0Pw0KDQotLSANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCiBSZXBvcnRl cjogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1w YXlsb2FkLQ0KICBqb25hdGFuLnNhbXVlbHNzb25AZXJpY3Nzb24uY29tICAgIHwgIHJ0cC1oMjY1 QHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAg ICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgIHwg ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBydHAtaDI2NSAgICAgICAgICAgICAgICAgfCAgICAg VmVyc2lvbjogIDIuMA0KIFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICAgICAgIHwgIFJl c29sdXRpb246DQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpU aWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcGF5bG9hZC90cmFjL3Rp Y2tldC8xMCNjb21tZW50OjM+DQpwYXlsb2FkIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGF5bG9h ZC8+DQoNCg== From nobody Tue Mar 4 16:20:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7701A0088 for ; Tue, 4 Mar 2014 16:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 Ly--mw3Js4Nn for ; Tue, 4 Mar 2014 16:20:38 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 311C61A0079 for ; Tue, 4 Mar 2014 16:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393978835; x=1425514835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VaUBT1GhsiSZRmn5/Zn1Cry8gGBgvjZQbpbyBDqiREU=; b=tQ1PffLIuhVhl0ymtsJ+r2NwvUCL9/ZzAnTEYi67PIrhKjRT0S91X5PA hbgFx22xBvy2bIYGmGT89U3FJyXjFr79hq7V3waGJbydNwgCqfbjI5Cm3 lKqAqM4VgWhp9sbCTA6n2nmtPC21jITz7f08o4y2+estwuw5XotjfhOr7 M=; X-IronPort-AV: E=McAfee;i="5400,1158,7367"; a="109374092" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 04 Mar 2014 16:20:34 -0800 X-IronPort-AV: E=Sophos;i="4.97,589,1389772800"; d="scan'208";a="640225293" Received: from nasanexhc02.na.qualcomm.com ([172.30.48.24]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 16:20:17 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC02.na.qualcomm.com (172.30.48.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 16:20:07 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 16:20:06 -0800 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , "payload issue tracker" , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0A== Date: Wed, 5 Mar 2014 00:20:06 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/MZJ9tQ5309UzzFQkgbsqAk4pbZ8 Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 00:20:43 -0000 SG1tLCBhIGRlY29kZWQgcGljdHVyZSBoYXNoIFNFSSBtZXNzYWdlIGFwcGxpZXMgdG8gKGFuZCBp cyBhc3NvY2lhdGVkIHdpdGgpIHRoZSBwcmVjZWRpbmcgZGVjb2RpbmcgcGljdHVyZSBpbiBkZWNv ZGluZyBvcmRlciBhbmQgdGh1cyB0aGUgVElkIG9mIHRoZSBjb250YWluaW5nIHN1ZmZpeCBTRUkg TkFMIHVuaXQgc2hvdWxkIGJlIHNldCBlcXVhbCB0byB0aGUgVElkIG9mIHRoZSBhc3NvY2lhdGVk IHBpY3R1cmUuIFRodXMgaW4gdGhlIGV4YW1wbGUsIGZvciB0aGUgc3VmZml4IFNFSSBOQUwgdW5p dCBjb250YWluaW5nIHRoZSBkZWNvZGVkIHBpY3R1cmUgaGFzaCBTRUkgbWVzc2FnZSBmb3IgdGhl IGZpcnN0IGVuY29kZWQgcGljdHVyZSBzaG91bGQgYmUgYXNzaWduZWQgVElkIGVxdWFsIHRvIDAu IA0KDQpBY2NvcmRpbmcgdG8gdGhlIEhFVkMgc3BlYywgY3VycmVudGx5IHRoZSBmb2xsb3dpbmcg U0VJIG1lc3NhZ2VzIGFyZSBvciBjYW4gYmUgc3VmZml4IFNFSSBtZXNzYWdlczogZmlsbGVyX3Bh eWxvYWQsIHVzZXJfZGF0YV9yZWdpc3RlcmVkX2l0dV90X3QzNSwgdXNlcl9kYXRhX3VucmVnaXN0 ZXJlZCwgcHJvZ3Jlc3NpdmVfcmVmaW5lbWVudF9zZWdtZW50X2VuZCwgcG9zdF9maWx0ZXJfaGlu dCwgYW5kIGRlY29kZWRfcGljdHVyZV9oYXNoLiBBbW9uZyB0aGVzZSwgSSB0aGluayBhbGwgb2Yg dGhlICJzcGVjaWZpZWQiIFNFSSBtZXNzYWdlcyAoaS5lLiB0aGUgYWJvdmUgbGlzdCBleGNsdWRp bmcgdXNlcl9kYXRhX3JlZ2lzdGVyZWRfaXR1X3RfdDM1LCB1c2VyX2RhdGFfdW5yZWdpc3RlcmVk KSBjb250YWluZWQgaW4gYSBzdWZmaXggU0VJIE5BTCB1bml0IHdvdWxkIGFwcGx5IHRvIHRoZSBw cmVjZWRpbmcgZGVjb2RlZCBwaWN0dXJlIGluIGRlY29kZXIgb3JkZXIgYW5kIHNob3VsZCBoYXZl IHRoZSBzYW1lIFRJZCBhcyB0aGUgYXNzb2NpYXRlZCBwaWN0dXJlLiBUaGUgb25seSBTRUkgbWVz c2FnZXMgdGhhdCBjYW4gaGF2ZSBhIGdyZWF0ZXIgVElkIHZhbHVlIHRoYW4gdGhlIGNvbnRhaW5p bmcgYWNjZXNzIHVuaXQgYXJlIHRoZSB0aHJlZSBTRUkgbWVzc2FnZSB0aGF0IGNhbiBjYXJyeSBI UkQgaW5mb3JtYXRpb24sIGkuZS4sIGJ1ZmZlcmluZ19wZXJpb2QsIHBpY190aW1pbmcsIGFuZCBk ZWNvZGluZ191bml0X2luZm8sIGJ1dCB0aGVzZSBjYW4gb25seSBiZSBwcmVmaXggU0VJIG1lc3Nh Z2VzLg0KDQpPZiBjb3Vyc2UsIGluIHRoZW9yeSwgZnV0dXJlIHZlcnNpb25zIG9mIEhFVkMgb3Ig c29tZSBleHRlbnNpb25zIChldmVuIGRlZmluZWQgYnkgYW4gYXBwbGljYXRpb24gc3BlYykgY291 bGQgZGVmaW5lIHN1ZmZpeCBTRUkgbWVzc2FnZXMgdGhhdCBjYW4gaGF2ZSBhIGdyZWF0ZXIgVElk IHZhbHVlIHRoYW4gdGhlIGNvbnRhaW5pbmcgYWNjZXNzIHVuaXQuIEluIHRoYXQgY2FzZSwgd2hh dCB5b3UgZGVzY3JpYmVkIGNvdWxkIGJlIG1lYW5pbmdmdWwsIGFuZCBpbmRlZWQgaWYgYSByZWNl aXZlciByZWNlaXZlcyB0aGUgImJhc2Ugc3ViLWxheWVyIiBzdHJlYW0sIHNvbWUgZW50aXR5IHdv dWxkIGhhdmUgdG8gc2V0IHRoZSBtYXJrZXIgYml0IG9mIHRob3NlIHBhY2tldHMgY29udGFpbmlu ZyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBhY2Nlc3MgdW5pdCBmb3IgdGhhdCBzdHJlYW0sIGFj Y29yZGluZyB0byB0aGUgY3VycmVudCBzZW1hbnRpY3MuDQoNCkhvd2V2ZXIsIGlmIHdlIGNoYW5n ZSB0aGUgd29yZGluZyB0byB0aGUgbGFzdCBWQ0wgTkFMIHVuaXQgYXMgeW91IHN1Z2dlc3RlZCwg YW5kIGluIGNhc2UgYSBzdWZmaXggU0VJIE5BTCB1bml0IG9mIHBpY3R1cmUgQSBpcyBub3QgY2Fy cmllZCB0aGUgcGFja2V0IGNvbnRhaW5pbmcgdGhlIGxhc3QgVkNMIE5BTCB1bml0IGlmIHRoZSBh Y2Nlc3MgdW5pdCwgd291bGQgdGhlIHVzYWdlIG9mIHRoZSBtYXJrZXIgYml0IGJlIGFmZmVjdGVk LCBlLmcuIGluIHBsYXlvdXQgYnVmZmVyIGhhbmRsaW5nPyBJZiB0aGUgYW5zd2VyIGlzIG5vLCB0 aGVuIHRoZXJlIHNob3VsZCBiZSBubyBwcm9ibGVtIHRvIGRvIHRoZSBjaGFuZ2UuDQoNCkJhc2lj YWxseSB0aGUgc2l0dWF0aW9uIGlzIGFzIGZvbGxvd3MuIFRoZXJlIGlzIG5vIGNvbmNyZXRlIHBy b2JsZW0gbm93LiBIb3dldmVyLCB0aGVyZSBjYW4gYmUgYSBwb3RlbnRpYWwgcHJvYmxlbSBpbiB0 aGUgZnV0dXJlIGlmIGEgc3VmZml4IFNFSSBtZXNzYWdlIGlzIGRlZmluZWQgYW5kIGNhbiBoYXZl IGEgZ3JlYXRlciBUSWQgdmFsdWUgdGhhbiB0aGUgY29udGFpbmluZyBhY2Nlc3MgdW5pdC4gSWYg dGhlIHN1Z2dlc3RlZCBjaGFuZ2UgZG9lcyBub3QgYWZmZWN0IHRoZSB1c2FnZSBvZiB0aGUgYml0 LCB3ZSBzaG91bGQgZG8gdGhlIGNoYW5nZSBub3cgdG8gbWFrZSB0aGUgZGVzaWduIGZ1dHVyZS1w cm9vZi4gU28gdGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBzdWdnZXN0IGNoYW5nZSB3 b3VsZCBhZmZlY3QgdGhlIHVzYWdlIG9mIHRoZSBiaXQuIA0KDQpEb2VzIGFueW9uZSBrbm93IGhv dyB0aGUgbWFya2VyIGJpdCBpcyB1c2VkIGluIHBsYXlvdXQgYnVmZmVyaW5nIGhhbmRsaW5nPyBB biBleHBsYW5hdGlvbiBvciBhIHBvaW50ZXIgd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC4N Cg0KQlIsIFlLDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb25hdGFuIFNh bXVlbHNzb24gW21haWx0bzpqb25hdGFuLnNhbXVlbHNzb25AZXJpY3Nzb24uY29tXSANClNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDA0LCAyMDE0IDE6MjggUE0NClRvOiBXYW5nLCBZZS1LdWk7IHBheWxv YWQgaXNzdWUgdHJhY2tlcjsgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYu b3JnOyBzdGV3ZUBzdGV3ZS5vcmcNCkNjOiBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3BheWxvYWRdICMxMCAocnRwLWgyNjUpOiBNYXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KRGVh ciBZZS1LdWksDQoNCkxldCBtZSB0cnkgdG8gbWFrZSB0aGUgZXhhbXBsZSBtb3JlIHNwZWNpZmlj IChhbmQgdGhlbiBhbHNvIHNlZSBpZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGUgbXVsdGktc3RyZWFt IHRyYW5zbWlzc2lvbiBjb25jZXB0IGNvcnJlY3RseSkuDQoNCkFzc3VtZSB0aGF0IHRoZSBzZW5k ZXIgcHV0cyBhbGwgTkFMIHVuaXRzIHdpdGggVElkIDAgaW4gb25lIFJUUCBzdHJlYW0gKHN0cmVh bSBBKSBhbmQgYWxsIE5BTCB1bml0cyB3aXRoIFRJZCAxIGluIGFub3RoZXIgUlRQIHN0cmVhbSAo c3RyZWFtIEIpLiBOb3cgZm9yIHRoZSBmaXJzdCBlbmNvZGVkIHBpY3R1cmUgdGhlIFZDTCBOQUwg dW5pdHMgYXJlIGFzc2lnbmVkIFRJZCAwIGFuZCB0aGVuIGEgZGVjb2RlZCBwaWN0dXJlIGhhc2gg U0VJIG1lc3NhZ2UgaXMgY3JlYXRlZCBpbiB0aGUgc2FtZSBhY2Nlc3MgdW5pdCBidXQgaXMgZ2l2 ZW4gVElkIDEuIFRoZW4gdGhlIG1hcmtlciBiaXQgd2lsbCBiZSBzZXQgb24gdGhlIHBhY2tldCBj b250YWluaW5nIHRoZSBkZWNvZGVkIHBpY3R1cmUgaGFzaCBTRUkgbWVzc2FnZSB3aGljaCBpcyBw dXQgaW4gc3RyZWFtIEIuIElmIHRoaXMgc2NoZW1lIGlzIGFwcGxpZWQgZm9yIGFsbCBhY2Nlc3Mg dW5pdHMsIHN0cmVhbSBBIHdpbGwgbm90IGNvbnRhaW4gYW55IHBhY2tldHMgd2l0aCB0aGUgbWFy a2VyIGJpdCBzZXQgc2luY2UgdGhlc2UgYXJlIGFsbCBwdXQgaW4gc3RyZWFtIEIuIEEgTUFORSB0 aGF0IG9ubHkgd2FudHMgdG8gZm9yd2FyZCBzdHJlYW0gQSB0byBhIHJlY2VpdmVyIHdvdWxkIGJl IHJlcXVpcmVkIHRvIHBlcmZvcm0gYW5hbHlzaXMgKGFuZCBwcm9iYWJseSBpbnRyb2R1Y2UgZGVs YXkpIGluIG9yZGVyIHRvIGNvcnJlY3RseSBjaGFuZ2UgdGhlIG1hcmtlciBiaXQgb24gdGhlICJu ZXciIGxhc3QgcGFja2V0IG9mIHRoZSBhY2Nlc3MgdW5pdC4NCg0KSXMgdGhhdCBjb3JyZWN0LCBv ciBoYXZlIEkgbWlzaW50ZXJwcmV0ZWQgYW55dGhpbmc/DQoNCkJlc3QgUmVnYXJkcyBKb25hdGFu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYW5nLCBZZS1LdWkgW21haWx0 bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbV0gDQpTZW50OiBkZW4gNCBtYXJzIDIwMTQgMTg6MjEN ClRvOiBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0 b29scy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uub3JnOyBKb25hdGFuIFNhbXVlbHNzb24NCkNjOiBw YXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3BheWxvYWRdICMxMCAocnRwLWgyNjUpOiBN YXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KSGkgSm9uYXRhbiwNCg0KSSBkbyBub3QgZnVsbHkg dW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIGV4YW1wbGU6DQoNCiJIb3dldmVyLCBhcyBmYXIgYXMg SSB1bmRlcnN0YW5kLCBpdCBpcyBhbGxvd2VkIGZvciBhbiBlbmNvZGVyIHRvIGNyZWF0ZSBhICBi aXRzdHJlYW0gd2l0aCB0d28gdGVtcG9yYWwgc3ViLWxheWVycyAoZXZlcnkgc2Vjb25kIHBpY3R1 cmUgd2l0aCBUSWQgMCAgYW5kIGV2ZXJ5IHNlY29uZCBwaWN0dXJlIHdpdGggVElkIDEpIGJ1dCBw dXQgcG9zdC1waWN0dXJlIFNFSSBtZXNzYWdlcyBmb3IgIGFsbCBhY2Nlc3MgdW5pdHMgaW4gdGVt cG9yYWwgbGF5ZXIgMSAoYWxzbyBmb3IgYWNjZXNzIHVuaXRzIGluIHdoaWNoIHRoZSAgcGljdHVy ZSBoYXMgVElkIDAsIGFzIGEgaGludCBvZiB0aGUgcmVsYXRpdmUgaW1wb3J0YW5jZSBvZiB0aGUg TkFMIHVuaXRzKS4gRm9yIHRoYXQgY2FzZSBJIGd1ZXNzIHRoZXJlIHdpbGwgYmUgb25lIFJUUCBz dHJlYW0gKGNvcnJlc3BvbmRpbmcgdG8gVElkIDApIGNvbXBsZXRlbHkgd2l0aG91dCBhbnkgbWFy a2VyIGJpdCBzZXQsIHJpZ2h0PyINCg0KQ291bGQgeW91IHBsZWFzZSBjaGVjayB3aGV0aGVyIGl0 IGNhbiBiZSBjbGFyaWZpZWQgYSBiaXQ/DQoNCkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogcGF5bG9hZCBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhYytwYXlsb2Fk QHRyYWMudG9vbHMuaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBNYXJjaCAwMywgMjAxNCAyOjEx IFBNDQpUbzogZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnOyBXYW5n LCBZZS1LdWk7IHN0ZXdlQHN0ZXdlLm9yZzsgam9uYXRhbi5zYW11ZWxzc29uQGVyaWNzc29uLmNv bQ0KQ2M6IHBheWxvYWRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF5bG9hZF0gIzEwIChydHAt aDI2NSk6IE1hcmtlciBiaXQgaW4gSC4yNjUvSEVWQw0KDQojMTA6IE1hcmtlciBiaXQgaW4gSC4y NjUvSEVWQw0KDQoNCkNvbW1lbnQgKGJ5IGpvbmF0YW4uc2FtdWVsc3NvbkBlcmljc3Nvbi5jb20p Og0KDQogVGhhbmtzIFN0ZWZhbiBmb3IgdGhlIGNvbW1lbnRzIGFuZCB0aGUgZXhhbXBsZS4gSXQg aXMgZXhhY3RseSB0aGlzIGtpbmQgb2YgIGNhc2VzIEknbSBjb25jZXJuZWQgYWJvdXQgYnV0IEkg d291bGRuJ3QgY2hhcmFjdGVyaXplIHRoZW0gYXMgZXhvdGljLiBGb3IgIGNvbnZlcnNhdGlvbmFs IGFwcGxpY2F0aW9ucyBpdCBpcyBuYXR1cmFsIHRvIG9wZXJhdGUgaW4gKnZlcnkqIGxvdyBkZWxh eSAgbW9kZSAoaS5lLiBub3QgYnVmZmVyaW5nIHBhY2tldHMgYmVmb3JlIGZvcndhcmRpbmcgdGhl bSkgYW5kIGhhdmluZyBwb3N0LSAgcGljdHVyZSBTRUkgcGFja2V0aXplZCBpbiB0aGVpciBvd24g cGFja2V0cyBpcyB0aGUgb25seSBvcHRpb24gYXMgc29vbiBhcyAgdGhlIFZDTCBOQUwgdW5pdHMg YXJlIGZyYWdtZW50ZWQgc2luY2UgRlVzIGNhbm5vdCBiZSBhZ2dyZWdhdGVkLiBIYXZpbmcgdG8g IGludHJvZHVjZSBzbGljZXMganVzdCB0byBhdm9pZCBGVXMgYW5kIHRoZXJlYnkgYmVpbmcgYWJs ZSB0byBhZ2dyZWdhdGUgU0VJICBtZXNzYWdlcyB3aXRoIFZDTCBOQUwgdW5pdHMgZG9lcyBub3Qg c291bmQgbGlrZSBhIGNvbXBlbGxpbmcgYWx0ZXJuYXRpdmUuDQoNCiBUaGUgbW9zdCByZWFzb25h YmxlIHNvbHV0aW9uIGZvciB0aGlzIGNhc2UgaXMgcHJvYmFibHkgdG8ganVzdCBub3QgcGVyZm9y bSAgdGhpbm5pbmcgYnkgcmVtb3ZpbmcgdGhlIFNFSSBtZXNzYWdlcyBzaW5jZSB0aGV5IGFyZSB0 eXBpY2FsbHkgbm90IHZlcnkgIGxhcmdlIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KIEhvd2V2ZXIs IGFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIGl0IGlzIGFsbG93ZWQgZm9yIGFuIGVuY29kZXIgdG8g Y3JlYXRlIGEgIGJpdHN0cmVhbSB3aXRoIHR3byB0ZW1wb3JhbCBzdWItbGF5ZXJzIChldmVyeSBz ZWNvbmQgcGljdHVyZSB3aXRoIFRJZCAwICBhbmQgZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0aCBU SWQgMSkgYnV0IHB1dCBwb3N0LXBpY3R1cmUgU0VJIG1lc3NhZ2VzIGZvciAgYWxsIGFjY2VzcyB1 bml0cyBpbiB0ZW1wb3JhbCBsYXllciAxIChhbHNvIGZvciBhY2Nlc3MgdW5pdHMgaW4gd2hpY2gg dGhlICBwaWN0dXJlIGhhcyBUSWQgMCwgYXMgYSBoaW50IG9mIHRoZSByZWxhdGl2ZSBpbXBvcnRh bmNlIG9mIHRoZSBOQUwgdW5pdHMpLg0KIEZvciB0aGF0IGNhc2UgSSBndWVzcyB0aGVyZSB3aWxs IGJlIG9uZSBSVFAgc3RyZWFtIChjb3JyZXNwb25kaW5nIHRvIFRJZA0KIDApIGNvbXBsZXRlbHkg d2l0aG91dCBhbnkgbWFya2VyIGJpdCBzZXQsIHJpZ2h0Pw0KDQotLSANCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCiBSZXBvcnRlcjog ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1wYXls b2FkLQ0KICBqb25hdGFuLnNhbXVlbHNzb25AZXJpY3Nzb24uY29tICAgIHwgIHJ0cC1oMjY1QHRv b2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAg IFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICAgICAgIHwgICBN aWxlc3RvbmU6DQpDb21wb25lbnQ6ICBydHAtaDI2NSAgICAgICAgICAgICAgICAgfCAgICAgVmVy c2lvbjogIDIuMA0KIFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICAgICAgIHwgIFJlc29s dXRpb246DQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNr ZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcGF5bG9hZC90cmFjL3RpY2tl dC8xMCNjb21tZW50OjM+DQpwYXlsb2FkIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGF5bG9hZC8+ DQoNCg== From nobody Wed Mar 5 01:06:56 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D091A01F5 for ; Wed, 5 Mar 2014 01:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MANGLED_TOOL=2.3, SPF_PASS=-0.001] 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 DVf2_8Nk-6Lf for ; Wed, 5 Mar 2014 01:06:53 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 010BB1A01C7 for ; Wed, 5 Mar 2014 01:06:51 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-5d-5316e9272aa1 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FB.F3.04853.729E6135; Wed, 5 Mar 2014 10:06:47 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 10:06:47 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPMkf2CFY3DR2ikEyoFpWG3Tj1ZprP5Z+AgAFBKICAAE+AEIAAJbcAgACZfjA= Date: Wed, 5 Mar 2014 09:06:46 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvja76S7Fgg+4j+hanLu5jtbh08SyT xfXGTewWjTNNLZ6sOcbswOqxZMlPJo9FU58xeixe/57R48vlz2weP/dsZg1gjeKySUnNySxL LdK3S+DK+LW5k6mgIbViW8sztgbGLUldjJwcEgImEu8/zWKFsMUkLtxbz9bFyMUhJHCCUeLy nLOMEM5iRokNZ9YwdTFycLAJWEl8fxEBEhcReMcosehcG1g3s4CmxKHPj9lAbGEBe4l7938w gtgiAg4Sp6euZ4aw/SRWL5jPCDKHRUBF4txlV5Awr4C3RPPV+1C7rjNJ9P5tAavnFAiW6Jl2 CMxmFJCVuP/9HgvELnGJW0/mM0FcLSCxZM95ZghbVOLl439Q3yhKfHy1D2wXyG3rd+lDtCpK TOl+yA6xV1Di5MwnLBMYxWYhmToLoWMWko5ZSDoWMLKsYpQsTi0uzk03MtDLTc8t0Ustykwu Ls7P0ytO3cQIjL+DW34b7WA8ucf+EKM0B4uSOO911pogIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYzLDUxK7Oyk2aPmbjj+7LdX1e860+r3183ntfO9kuJf7ijzfJf2xiKrvG2vPJty4mV7 rPXfbHuSHamzffaasKvpzgeLsqTWH42JVfH5w+WzJkZipfhh6Vv6D6epmXzeVWEq9Ch+8vaH 9x4Hvf3GoJx0/1VVrsHe15MVb3m3exa8u/4p7UBfmrcSS3FGoqEWc1FxIgBdJUxCjQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/pt-vVKbprDvhYKcBRna8zjxk-ik Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:06:55 -0000 VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIFllLUt1aSwNCg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFu ZCwgb3V0IG9mIHRoZSA2IFNFSSBtZXNzYWdlcyB0aGF0IGhhdmUgc28gZmFyIGJlZW4gZGVmaW5l ZCBpbiB0aGUgSEVWQyBzcGVjIGFzIHBvc3NpYmxlIHRvIHVzZSBhcyBzdWZmaXhlcyAoZmlsbGVy X3BheWxvYWQsIHVzZXJfZGF0YV9yZWdpc3RlcmVkX2l0dV90X3QzNSwgdXNlcl9kYXRhX3VucmVn aXN0ZXJlZCwgcHJvZ3Jlc3NpdmVfcmVmaW5lbWVudF9zZWdtZW50X2VuZCwgcG9zdF9maWx0ZXJf aGludCwgYW5kIGRlY29kZWRfcGljdHVyZV9oYXNoKSB0aGVyZSBhcmUgMyB0aGF0IGFyZSBub3Qg cmVxdWlyZWQgdG8gaGF2ZSB0aGUgc2FtZSBUSWQgYXMgdGhlIFZDTCBOQUwgdW5pdHMgb2YgdGhl IGFjY2VzcyB1bml0OiAgdXNlcl9kYXRhX3JlZ2lzdGVyZWRfaXR1X3RfdDM1LCB1c2VyX2RhdGFf dW5yZWdpc3RlcmVkIGFuZCBkZWNvZGVkX3BpY3R1cmVfaGFzaCBzaW5jZSB0aGVpciBwYXlsb2Fk VHlwZSBudW1iZXJzICg0LCA1IGFuZCAxMzIpIGFyZSBub3QgaW5jbHVkZWQgaW4gdGhlIGxpc3Q6 DQoNCiJXaGVuIGEgbm9uLW5lc3RlZCBTRUkgbWVzc2FnZSBoYXMgcGF5bG9hZFR5cGUgZXF1YWwg dG8gMiwgMywgNiwgOSwgMTUsIDE2LCAxNywgMTksIDIyLCAyMywgNDUsIDQ3LCAxMjgsIDEzMSwg b3IgMTM0IChpLmUuLCBvbmUgb2YgdGhlIFNFSSBtZXNzYWdlcyB0aGF0IGhhdmUgcGF5bG9hZFR5 cGUgbm90IGVxdWFsIHRvIDAsIDEsIG9yIDEzMCwgYW5kIHRoYXQgYXJlIGFsbG93ZWQgdG8gYmUg bmVzdGVkIFNFSSBtZXNzYWdlcyksIHRoZSBTRUkgTkFMIHVuaXQgY29udGFpbmluZyB0aGUgbm9u LW5lc3RlZCBTRUkgbWVzc2FnZSBzaGFsbCBoYXZlIFRlbXBvcmFsSWQgZXF1YWwgdG8gdGhlIFRl bXBvcmFsSWQgb2YgdGhlIGFjY2VzcyB1bml0IGNvbnRhaW5pbmcgdGhlIFNFSSBOQUwgdW5pdC4i DQoNCk1heWJlIGl0J3MgYSBtaXN0YWtlIGluIHRoZSBIRVZDIHNwZWMgdGhhdCAxMzIgaXMgbm90 IGluIHRoaXMgbGlzdCwgYnV0IEkgdGhpbmsgdGhlIHByb2JsZW0gd291bGQgZXhpc3QgZXZlbiBp ZiB3YXMuIEFuIGVuY29kZXIgdGhhdCAoZm9yIHdoYXRldmVyIHJlYXNvbikgcHV0cyBpbiB1c2Vy X2RhdGFfcmVnaXN0ZXJlZF9pdHVfdF90MzUgb3IgdXNlcl9kYXRhX3VucmVnaXN0ZXJlZCBzdWZm aXggU0VJIG1lc3NhZ2VzIHdpdGggaGlnaGVyIFRJZCB3b3VsZCBwdXQgYSBNQU5FIGluIGEgZGlm ZmljdWx0IHNpdHVhdGlvbi4gDQoNCkkgYWxzbyB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgZnV0 dXJlIGV4dGVuc2lvbnMgb2YgSEVWQyAoaS5lLiBTSFZDIGFuZCBNVi1IRVZDKSBpbiB3aGljaCBh biBhY2Nlc3MgdW5pdCBtYXkgY29udGFpbiBtYW55IHBpY3R1cmVzIHdpdGggZGlmZmVyZW50IHZh bHVlcyBvZiBudWhfbGF5ZXJfaWQuIElmIHRoZSBtYXJrZXIgYml0IGlzIHNldCBmb3IgdGhlIGxh c3QgcGFja2V0IG9mIGFuIGFjY2VzcyB1bml0LCB0aGVuIG9uY2UgYWdhaW4gYWxsIHRoZSBtYXJr ZXIgYml0cyB3aWxsIGVuZCB1cCBpbiB0aGUgaGlnaGVzdCBsYXllciAoc3RyZWFtKSBhbmQgYSBN QU5FIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHRoZSB2YWx1ZSBvZiBtYXJrZXIgYml0cyBhcyBzb29u IGFzIG5vdCBhbGwgbGF5ZXJzIChzdHJlYW1zKSBhcmUgZm9yd2FyZGVkLg0KDQpCZXN0IFJlZ2Fy ZHMgSm9uYXRhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2FuZywgWWUt S3VpIFttYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb21dIA0KU2VudDogZGVuIDUgbWFycyAy MDE0IDAxOjIwDQpUbzogSm9uYXRhbiBTYW11ZWxzc29uOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7 IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uu b3JnDQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0 cC1oMjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9IRVZDDQoNCkhtbSwgYSBkZWNvZGVkIHBpY3R1 cmUgaGFzaCBTRUkgbWVzc2FnZSBhcHBsaWVzIHRvIChhbmQgaXMgYXNzb2NpYXRlZCB3aXRoKSB0 aGUgcHJlY2VkaW5nIGRlY29kaW5nIHBpY3R1cmUgaW4gZGVjb2Rpbmcgb3JkZXIgYW5kIHRodXMg dGhlIFRJZCBvZiB0aGUgY29udGFpbmluZyBzdWZmaXggU0VJIE5BTCB1bml0IHNob3VsZCBiZSBz ZXQgZXF1YWwgdG8gdGhlIFRJZCBvZiB0aGUgYXNzb2NpYXRlZCBwaWN0dXJlLiBUaHVzIGluIHRo ZSBleGFtcGxlLCBmb3IgdGhlIHN1ZmZpeCBTRUkgTkFMIHVuaXQgY29udGFpbmluZyB0aGUgZGVj b2RlZCBwaWN0dXJlIGhhc2ggU0VJIG1lc3NhZ2UgZm9yIHRoZSBmaXJzdCBlbmNvZGVkIHBpY3R1 cmUgc2hvdWxkIGJlIGFzc2lnbmVkIFRJZCBlcXVhbCB0byAwLiANCg0KQWNjb3JkaW5nIHRvIHRo ZSBIRVZDIHNwZWMsIGN1cnJlbnRseSB0aGUgZm9sbG93aW5nIFNFSSBtZXNzYWdlcyBhcmUgb3Ig Y2FuIGJlIHN1ZmZpeCBTRUkgbWVzc2FnZXM6IGZpbGxlcl9wYXlsb2FkLCB1c2VyX2RhdGFfcmVn aXN0ZXJlZF9pdHVfdF90MzUsIHVzZXJfZGF0YV91bnJlZ2lzdGVyZWQsIHByb2dyZXNzaXZlX3Jl ZmluZW1lbnRfc2VnbWVudF9lbmQsIHBvc3RfZmlsdGVyX2hpbnQsIGFuZCBkZWNvZGVkX3BpY3R1 cmVfaGFzaC4gQW1vbmcgdGhlc2UsIEkgdGhpbmsgYWxsIG9mIHRoZSAic3BlY2lmaWVkIiBTRUkg bWVzc2FnZXMgKGkuZS4gdGhlIGFib3ZlIGxpc3QgZXhjbHVkaW5nIHVzZXJfZGF0YV9yZWdpc3Rl cmVkX2l0dV90X3QzNSwgdXNlcl9kYXRhX3VucmVnaXN0ZXJlZCkgY29udGFpbmVkIGluIGEgc3Vm Zml4IFNFSSBOQUwgdW5pdCB3b3VsZCBhcHBseSB0byB0aGUgcHJlY2VkaW5nIGRlY29kZWQgcGlj dHVyZSBpbiBkZWNvZGVyIG9yZGVyIGFuZCBzaG91bGQgaGF2ZSB0aGUgc2FtZSBUSWQgYXMgdGhl IGFzc29jaWF0ZWQgcGljdHVyZS4gVGhlIG9ubHkgU0VJIG1lc3NhZ2VzIHRoYXQgY2FuIGhhdmUg YSBncmVhdGVyIFRJZCB2YWx1ZSB0aGFuIHRoZSBjb250YWluaW5nIGFjY2VzcyB1bml0IGFyZSB0 aGUgdGhyZWUgU0VJIG1lc3NhZ2UgdGhhdCBjYW4gY2FycnkgSFJEIGluZm9ybWF0aW9uLCBpLmUu LCBidWZmZXJpbmdfcGVyaW9kLCBwaWNfdGltaW5nLCBhbmQgZGVjb2RpbmdfdW5pdF9pbmZvLCBi dXQgdGhlc2UgY2FuIG9ubHkgYmUgcHJlZml4IFNFSSBtZXNzYWdlcy4NCg0KT2YgY291cnNlLCBp biB0aGVvcnksIGZ1dHVyZSB2ZXJzaW9ucyBvZiBIRVZDIG9yIHNvbWUgZXh0ZW5zaW9ucyAoZXZl biBkZWZpbmVkIGJ5IGFuIGFwcGxpY2F0aW9uIHNwZWMpIGNvdWxkIGRlZmluZSBzdWZmaXggU0VJ IG1lc3NhZ2VzIHRoYXQgY2FuIGhhdmUgYSBncmVhdGVyIFRJZCB2YWx1ZSB0aGFuIHRoZSBjb250 YWluaW5nIGFjY2VzcyB1bml0LiBJbiB0aGF0IGNhc2UsIHdoYXQgeW91IGRlc2NyaWJlZCBjb3Vs ZCBiZSBtZWFuaW5nZnVsLCBhbmQgaW5kZWVkIGlmIGEgcmVjZWl2ZXIgcmVjZWl2ZXMgdGhlICJi YXNlIHN1Yi1sYXllciIgc3RyZWFtLCBzb21lIGVudGl0eSB3b3VsZCBoYXZlIHRvIHNldCB0aGUg bWFya2VyIGJpdCBvZiB0aG9zZSBwYWNrZXRzIGNvbnRhaW5pbmcgdGhlIGxhc3QgTkFMIHVuaXQg b2YgYW4gYWNjZXNzIHVuaXQgZm9yIHRoYXQgc3RyZWFtLCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgc2VtYW50aWNzLg0KDQpIb3dldmVyLCBpZiB3ZSBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gdGhl IGxhc3QgVkNMIE5BTCB1bml0IGFzIHlvdSBzdWdnZXN0ZWQsIGFuZCBpbiBjYXNlIGEgc3VmZml4 IFNFSSBOQUwgdW5pdCBvZiBwaWN0dXJlIEEgaXMgbm90IGNhcnJpZWQgdGhlIHBhY2tldCBjb250 YWluaW5nIHRoZSBsYXN0IFZDTCBOQUwgdW5pdCBpZiB0aGUgYWNjZXNzIHVuaXQsIHdvdWxkIHRo ZSB1c2FnZSBvZiB0aGUgbWFya2VyIGJpdCBiZSBhZmZlY3RlZCwgZS5nLiBpbiBwbGF5b3V0IGJ1 ZmZlciBoYW5kbGluZz8gSWYgdGhlIGFuc3dlciBpcyBubywgdGhlbiB0aGVyZSBzaG91bGQgYmUg bm8gcHJvYmxlbSB0byBkbyB0aGUgY2hhbmdlLg0KDQpCYXNpY2FsbHkgdGhlIHNpdHVhdGlvbiBp cyBhcyBmb2xsb3dzLiBUaGVyZSBpcyBubyBjb25jcmV0ZSBwcm9ibGVtIG5vdy4gSG93ZXZlciwg dGhlcmUgY2FuIGJlIGEgcG90ZW50aWFsIHByb2JsZW0gaW4gdGhlIGZ1dHVyZSBpZiBhIHN1ZmZp eCBTRUkgbWVzc2FnZSBpcyBkZWZpbmVkIGFuZCBjYW4gaGF2ZSBhIGdyZWF0ZXIgVElkIHZhbHVl IHRoYW4gdGhlIGNvbnRhaW5pbmcgYWNjZXNzIHVuaXQuIElmIHRoZSBzdWdnZXN0ZWQgY2hhbmdl IGRvZXMgbm90IGFmZmVjdCB0aGUgdXNhZ2Ugb2YgdGhlIGJpdCwgd2Ugc2hvdWxkIGRvIHRoZSBj aGFuZ2Ugbm93IHRvIG1ha2UgdGhlIGRlc2lnbiBmdXR1cmUtcHJvb2YuIFNvIHRoZSBrZXkgcXVl c3Rpb24gaXMgd2hldGhlciB0aGUgc3VnZ2VzdCBjaGFuZ2Ugd291bGQgYWZmZWN0IHRoZSB1c2Fn ZSBvZiB0aGUgYml0LiANCg0KRG9lcyBhbnlvbmUga25vdyBob3cgdGhlIG1hcmtlciBiaXQgaXMg dXNlZCBpbiBwbGF5b3V0IGJ1ZmZlcmluZyBoYW5kbGluZz8gQW4gZXhwbGFuYXRpb24gb3IgYSBw b2ludGVyIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNCkJSLCBZSw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9uYXRhbiBTYW11ZWxzc29uIFttYWlsdG86am9u YXRhbi5zYW11ZWxzc29uQGVyaWNzc29uLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwNCwg MjAxNCAxOjI4IFBNDQpUbzogV2FuZywgWWUtS3VpOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRy YWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uub3Jn DQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0cC1o MjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9IRVZDDQoNCkRlYXIgWWUtS3VpLA0KDQpMZXQgbWUg dHJ5IHRvIG1ha2UgdGhlIGV4YW1wbGUgbW9yZSBzcGVjaWZpYyAoYW5kIHRoZW4gYWxzbyBzZWUg aWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhlIG11bHRpLXN0cmVhbSB0cmFuc21pc3Npb24gY29uY2Vw dCBjb3JyZWN0bHkpLg0KDQpBc3N1bWUgdGhhdCB0aGUgc2VuZGVyIHB1dHMgYWxsIE5BTCB1bml0 cyB3aXRoIFRJZCAwIGluIG9uZSBSVFAgc3RyZWFtIChzdHJlYW0gQSkgYW5kIGFsbCBOQUwgdW5p dHMgd2l0aCBUSWQgMSBpbiBhbm90aGVyIFJUUCBzdHJlYW0gKHN0cmVhbSBCKS4gTm93IGZvciB0 aGUgZmlyc3QgZW5jb2RlZCBwaWN0dXJlIHRoZSBWQ0wgTkFMIHVuaXRzIGFyZSBhc3NpZ25lZCBU SWQgMCBhbmQgdGhlbiBhIGRlY29kZWQgcGljdHVyZSBoYXNoIFNFSSBtZXNzYWdlIGlzIGNyZWF0 ZWQgaW4gdGhlIHNhbWUgYWNjZXNzIHVuaXQgYnV0IGlzIGdpdmVuIFRJZCAxLiBUaGVuIHRoZSBt YXJrZXIgYml0IHdpbGwgYmUgc2V0IG9uIHRoZSBwYWNrZXQgY29udGFpbmluZyB0aGUgZGVjb2Rl ZCBwaWN0dXJlIGhhc2ggU0VJIG1lc3NhZ2Ugd2hpY2ggaXMgcHV0IGluIHN0cmVhbSBCLiBJZiB0 aGlzIHNjaGVtZSBpcyBhcHBsaWVkIGZvciBhbGwgYWNjZXNzIHVuaXRzLCBzdHJlYW0gQSB3aWxs IG5vdCBjb250YWluIGFueSBwYWNrZXRzIHdpdGggdGhlIG1hcmtlciBiaXQgc2V0IHNpbmNlIHRo ZXNlIGFyZSBhbGwgcHV0IGluIHN0cmVhbSBCLiBBIE1BTkUgdGhhdCBvbmx5IHdhbnRzIHRvIGZv cndhcmQgc3RyZWFtIEEgdG8gYSByZWNlaXZlciB3b3VsZCBiZSByZXF1aXJlZCB0byBwZXJmb3Jt IGFuYWx5c2lzIChhbmQgcHJvYmFibHkgaW50cm9kdWNlIGRlbGF5KSBpbiBvcmRlciB0byBjb3Jy ZWN0bHkgY2hhbmdlIHRoZSBtYXJrZXIgYml0IG9uIHRoZSAibmV3IiBsYXN0IHBhY2tldCBvZiB0 aGUgYWNjZXNzIHVuaXQuDQoNCklzIHRoYXQgY29ycmVjdCwgb3IgaGF2ZSBJIG1pc2ludGVycHJl dGVkIGFueXRoaW5nPw0KDQpCZXN0IFJlZ2FyZHMgSm9uYXRhbg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2FuZywgWWUtS3VpIFttYWlsdG86eWVrdWl3QHF0aS5xdWFsY29t bS5jb21dIA0KU2VudDogZGVuIDQgbWFycyAyMDE0IDE4OjIxDQpUbzogcGF5bG9hZCBpc3N1ZSB0 cmFja2VyOyBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAdG9vbHMuaWV0Zi5vcmc7IHN0ZXdl QHN0ZXdlLm9yZzsgSm9uYXRhbiBTYW11ZWxzc29uDQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0cC1oMjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9I RVZDDQoNCkhpIEpvbmF0YW4sDQoNCkkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGZvbGxv d2luZyBleGFtcGxlOg0KDQoiSG93ZXZlciwgYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgaXQgaXMg YWxsb3dlZCBmb3IgYW4gZW5jb2RlciB0byBjcmVhdGUgYSAgYml0c3RyZWFtIHdpdGggdHdvIHRl bXBvcmFsIHN1Yi1sYXllcnMgKGV2ZXJ5IHNlY29uZCBwaWN0dXJlIHdpdGggVElkIDAgIGFuZCBl dmVyeSBzZWNvbmQgcGljdHVyZSB3aXRoIFRJZCAxKSBidXQgcHV0IHBvc3QtcGljdHVyZSBTRUkg bWVzc2FnZXMgZm9yICBhbGwgYWNjZXNzIHVuaXRzIGluIHRlbXBvcmFsIGxheWVyIDEgKGFsc28g Zm9yIGFjY2VzcyB1bml0cyBpbiB3aGljaCB0aGUgIHBpY3R1cmUgaGFzIFRJZCAwLCBhcyBhIGhp bnQgb2YgdGhlIHJlbGF0aXZlIGltcG9ydGFuY2Ugb2YgdGhlIE5BTCB1bml0cykuIEZvciB0aGF0 IGNhc2UgSSBndWVzcyB0aGVyZSB3aWxsIGJlIG9uZSBSVFAgc3RyZWFtIChjb3JyZXNwb25kaW5n IHRvIFRJZCAwKSBjb21wbGV0ZWx5IHdpdGhvdXQgYW55IG1hcmtlciBiaXQgc2V0LCByaWdodD8i DQoNCkNvdWxkIHlvdSBwbGVhc2UgY2hlY2sgd2hldGhlciBpdCBjYW4gYmUgY2xhcmlmaWVkIGEg Yml0Pw0KDQpCUiwgWUsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBheWxv YWQgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrcGF5bG9hZEB0cmFjLnRvb2xzLmlldGYub3Jn XSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDMsIDIwMTQgMjoxMSBQTQ0KVG86IGRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzsgV2FuZywgWWUtS3VpOyBzdGV3ZUBzdGV3 ZS5vcmc7IGpvbmF0YW4uc2FtdWVsc3NvbkBlcmljc3Nvbi5jb20NCkNjOiBwYXlsb2FkQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3BheWxvYWRdICMxMCAocnRwLWgyNjUpOiBNYXJrZXIgYml0IGlu IEguMjY1L0hFVkMNCg0KIzEwOiBNYXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KDQpDb21tZW50 IChieSBqb25hdGFuLnNhbXVlbHNzb25AZXJpY3Nzb24uY29tKToNCg0KIFRoYW5rcyBTdGVmYW4g Zm9yIHRoZSBjb21tZW50cyBhbmQgdGhlIGV4YW1wbGUuIEl0IGlzIGV4YWN0bHkgdGhpcyBraW5k IG9mICBjYXNlcyBJJ20gY29uY2VybmVkIGFib3V0IGJ1dCBJIHdvdWxkbid0IGNoYXJhY3Rlcml6 ZSB0aGVtIGFzIGV4b3RpYy4gRm9yICBjb252ZXJzYXRpb25hbCBhcHBsaWNhdGlvbnMgaXQgaXMg bmF0dXJhbCB0byBvcGVyYXRlIGluICp2ZXJ5KiBsb3cgZGVsYXkgIG1vZGUgKGkuZS4gbm90IGJ1 ZmZlcmluZyBwYWNrZXRzIGJlZm9yZSBmb3J3YXJkaW5nIHRoZW0pIGFuZCBoYXZpbmcgcG9zdC0g IHBpY3R1cmUgU0VJIHBhY2tldGl6ZWQgaW4gdGhlaXIgb3duIHBhY2tldHMgaXMgdGhlIG9ubHkg b3B0aW9uIGFzIHNvb24gYXMgIHRoZSBWQ0wgTkFMIHVuaXRzIGFyZSBmcmFnbWVudGVkIHNpbmNl IEZVcyBjYW5ub3QgYmUgYWdncmVnYXRlZC4gSGF2aW5nIHRvICBpbnRyb2R1Y2Ugc2xpY2VzIGp1 c3QgdG8gYXZvaWQgRlVzIGFuZCB0aGVyZWJ5IGJlaW5nIGFibGUgdG8gYWdncmVnYXRlIFNFSSAg bWVzc2FnZXMgd2l0aCBWQ0wgTkFMIHVuaXRzIGRvZXMgbm90IHNvdW5kIGxpa2UgYSBjb21wZWxs aW5nIGFsdGVybmF0aXZlLg0KDQogVGhlIG1vc3QgcmVhc29uYWJsZSBzb2x1dGlvbiBmb3IgdGhp cyBjYXNlIGlzIHByb2JhYmx5IHRvIGp1c3Qgbm90IHBlcmZvcm0gIHRoaW5uaW5nIGJ5IHJlbW92 aW5nIHRoZSBTRUkgbWVzc2FnZXMgc2luY2UgdGhleSBhcmUgdHlwaWNhbGx5IG5vdCB2ZXJ5ICBs YXJnZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCiBIb3dldmVyLCBhcyBmYXIgYXMgSSB1bmRlcnN0 YW5kLCBpdCBpcyBhbGxvd2VkIGZvciBhbiBlbmNvZGVyIHRvIGNyZWF0ZSBhICBiaXRzdHJlYW0g d2l0aCB0d28gdGVtcG9yYWwgc3ViLWxheWVycyAoZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0aCBU SWQgMCAgYW5kIGV2ZXJ5IHNlY29uZCBwaWN0dXJlIHdpdGggVElkIDEpIGJ1dCBwdXQgcG9zdC1w aWN0dXJlIFNFSSBtZXNzYWdlcyBmb3IgIGFsbCBhY2Nlc3MgdW5pdHMgaW4gdGVtcG9yYWwgbGF5 ZXIgMSAoYWxzbyBmb3IgYWNjZXNzIHVuaXRzIGluIHdoaWNoIHRoZSAgcGljdHVyZSBoYXMgVElk IDAsIGFzIGEgaGludCBvZiB0aGUgcmVsYXRpdmUgaW1wb3J0YW5jZSBvZiB0aGUgTkFMIHVuaXRz KS4NCiBGb3IgdGhhdCBjYXNlIEkgZ3Vlc3MgdGhlcmUgd2lsbCBiZSBvbmUgUlRQIHN0cmVhbSAo Y29ycmVzcG9uZGluZyB0byBUSWQNCiAwKSBjb21wbGV0ZWx5IHdpdGhvdXQgYW55IG1hcmtlciBi aXQgc2V0LCByaWdodD8NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQogUmVwb3J0ZXI6ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICBPd25lcjogIGRyYWZ0LWlldGYtcGF5bG9hZC0NCiAgam9uYXRhbi5zYW11 ZWxzc29uQGVyaWNzc29uLmNvbSAgICB8ICBydHAtaDI2NUB0b29scy5pZXRmLm9yZw0KICAgICBU eXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlv cml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KQ29tcG9uZW50 OiAgcnRwLWgyNjUgICAgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246ICAyLjANCiBTZXZlcml0 eTogIC0gICAgICAgICAgICAgICAgICAgICAgICB8ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL3BheWxvYWQvdHJhYy90aWNrZXQvMTAjY29tbWVudDozPg0KcGF5 bG9hZCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3BheWxvYWQvPg0KDQo= From nobody Wed Mar 5 10:28:59 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613ED1A0418 for ; Wed, 5 Mar 2014 10:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 Y57kJCMokExt for ; Wed, 5 Mar 2014 10:28:54 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB61A045B for ; Wed, 5 Mar 2014 10:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394044130; x=1425580130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IZPn638qu6y9XMTolmlfjkMcqQj4UIPJ/PADGpD0waQ=; b=WvLVk73USy6HLY03VZ3xNdfenA6STz5RRkEfucVfqLY91OQrLWU3TbCi pvTU5GMFxAasTISfU/qJeKog00oxvIc8cSBDymi4g+DtQeAj/qnDyGQ88 1ponoLFdhUPlQnLh108SgR2+5elu7FpEbVbPbXef5rzhG8PinI3u48f78 o=; X-IronPort-AV: E=McAfee;i="5400,1158,7368"; a="18645328" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 05 Mar 2014 10:28:50 -0800 X-IronPort-AV: E=Sophos;i="4.97,593,1389772800"; d="scan'208";a="627898345" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2014 10:28:51 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 10:28:49 -0800 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , "payload issue tracker" , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHA= Date: Wed, 5 Mar 2014 18:28:48 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/gvZPOBjeRqp1e6DqOAz-5kbH0iw Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:28:57 -0000 U29tZXRoaW5nIHNob3VsZCBiZSBkb25lIHRvIHRoZSBIRVZDIHNwZWMgdG8gbWFrZSBpdCBjbGVh cmVyIGZvciB0aGUgZGVjb2RlZCBwaWN0dXJlIGhhc2ggU0VJIG1lc3NhZ2UsIGxpa2UgdGhhdCBp dCBzaGFsbCBub3QgYmUgbmVzdGVkIGFuZCB3aGF0IHRoZSB2YWx1ZXMgb2YgTGF5ZXJJZCBhbmQg TElkIHNob3VsZCBiZSwgb3IgYWxsb3cgYWRkIHRvIHRoZSBsaXN0IG9mIG5lc3RhYmxlIFNFSSBt ZXNzYWdlLiBJbiBhbnkgY2FzZSwgaXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBtZSB0byBwdXQg YSBncmVhdGVyIHZhbHVlIG9mIFRJZCB0aGFuIGl0cyBhc3NvY2lhdGVkIHBpY3R1cmUuIE9uIHVz ZXJfZGF0YV9yZWdpc3RlcmVkX2l0dV90X3QzNSBhbmQgdXNlcl9kYXRhX3VucmVnaXN0ZXJlZCBz dWZmaXggU0VJIG1lc3NhZ2VzLCBvbmx5IGlmIGl0IGlzIGRlZmluZWQgYnkgc29tZSBhcHBsaWNh dGlvbiB0aGVuIGl0IG1heSBtYWtlIHNlbnNlIHRvIHB1dCBhIGdyZWF0ZXIgdmFsdWUgb2YgVElk IHRoYW4gaXRzIGFzc29jaWF0ZWQgcGljdHVyZSAtIGN1cnJlbnRseSBJIGhhdmUgbm90IHNlZW4g YW55IHN1Y2ggdXNlIGJlaW5nIGRlZmluZWQgYW55d2hlcmUuDQoNCkFueXdheSwgSSBhZG1pdHRl ZCB0aGF0IHRoZSBjdXJyZW50IHNlbWFudGljcyBhcmUgbm90IGZ1bGx5IGZ1dHVyZS1wcm9vZiBy ZWdhcmRpbmcgc3VmZml4IFNFSSBtZXNzYWdlcy4gSW4gbG9va2luZyBpbnRvIGZ1dHVyZSBtdWx0 aS1sYXllciBleHRlbnNpb25zLCBpdCBhcHBlYXJzIHRoYXQgc2ltcGx5IGNoYW5naW5nIHRoZSB3 b3JkaW5nIGZyb20gImxhc3QgTkFMIHVuaXQiIHRvICJsYXN0IFZDTCBOQUwgdW5pdCIgaXMgbm90 IGdvb2QgZW5vdWdoLiBXZSBtaWdodCBuZWVkIHRvIHNwZWNpZnkgdGhlIHNlbWFudGljcyBvZiB0 aGUgbWFya2VyIGJpdCB0byBiZSBSVFAgc3RyZWFtIHNwZWNpZmljLiBUbyBtYWtlIHN1cmUgd2hl dGhlciBzdWNoIGEgY2hhbmdlIGlzIE9LLCB3ZSBhbHNvIG5lZWQgdG8gY2hlY2sgYWdhaW5zdCB0 aGUgdXNhZ2Ugb2YgdGhlIG1hcmtlciBiaXQuDQoNCkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSm9uYXRhbiBTYW11ZWxzc29uIFttYWlsdG86am9uYXRhbi5zYW11 ZWxzc29uQGVyaWNzc29uLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA1LCAyMDE0IDE6 MDcgQU0NClRvOiBXYW5nLCBZZS1LdWk7IHBheWxvYWQgaXNzdWUgdHJhY2tlcjsgZHJhZnQtaWV0 Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnOyBzdGV3ZUBzdGV3ZS5vcmcNCkNjOiBw YXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3BheWxvYWRdICMxMCAocnRwLWgyNjUpOiBN YXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlIFllLUt1 aSwNCg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgb3V0IG9mIHRoZSA2IFNFSSBtZXNzYWdlcyB0 aGF0IGhhdmUgc28gZmFyIGJlZW4gZGVmaW5lZCBpbiB0aGUgSEVWQyBzcGVjIGFzIHBvc3NpYmxl IHRvIHVzZSBhcyBzdWZmaXhlcyAoZmlsbGVyX3BheWxvYWQsIHVzZXJfZGF0YV9yZWdpc3RlcmVk X2l0dV90X3QzNSwgdXNlcl9kYXRhX3VucmVnaXN0ZXJlZCwgcHJvZ3Jlc3NpdmVfcmVmaW5lbWVu dF9zZWdtZW50X2VuZCwgcG9zdF9maWx0ZXJfaGludCwgYW5kIGRlY29kZWRfcGljdHVyZV9oYXNo KSB0aGVyZSBhcmUgMyB0aGF0IGFyZSBub3QgcmVxdWlyZWQgdG8gaGF2ZSB0aGUgc2FtZSBUSWQg YXMgdGhlIFZDTCBOQUwgdW5pdHMgb2YgdGhlIGFjY2VzcyB1bml0OiAgdXNlcl9kYXRhX3JlZ2lz dGVyZWRfaXR1X3RfdDM1LCB1c2VyX2RhdGFfdW5yZWdpc3RlcmVkIGFuZCBkZWNvZGVkX3BpY3R1 cmVfaGFzaCBzaW5jZSB0aGVpciBwYXlsb2FkVHlwZSBudW1iZXJzICg0LCA1IGFuZCAxMzIpIGFy ZSBub3QgaW5jbHVkZWQgaW4gdGhlIGxpc3Q6DQoNCiJXaGVuIGEgbm9uLW5lc3RlZCBTRUkgbWVz c2FnZSBoYXMgcGF5bG9hZFR5cGUgZXF1YWwgdG8gMiwgMywgNiwgOSwgMTUsIDE2LCAxNywgMTks IDIyLCAyMywgNDUsIDQ3LCAxMjgsIDEzMSwgb3IgMTM0IChpLmUuLCBvbmUgb2YgdGhlIFNFSSBt ZXNzYWdlcyB0aGF0IGhhdmUgcGF5bG9hZFR5cGUgbm90IGVxdWFsIHRvIDAsIDEsIG9yIDEzMCwg YW5kIHRoYXQgYXJlIGFsbG93ZWQgdG8gYmUgbmVzdGVkIFNFSSBtZXNzYWdlcyksIHRoZSBTRUkg TkFMIHVuaXQgY29udGFpbmluZyB0aGUgbm9uLW5lc3RlZCBTRUkgbWVzc2FnZSBzaGFsbCBoYXZl IFRlbXBvcmFsSWQgZXF1YWwgdG8gdGhlIFRlbXBvcmFsSWQgb2YgdGhlIGFjY2VzcyB1bml0IGNv bnRhaW5pbmcgdGhlIFNFSSBOQUwgdW5pdC4iDQoNCk1heWJlIGl0J3MgYSBtaXN0YWtlIGluIHRo ZSBIRVZDIHNwZWMgdGhhdCAxMzIgaXMgbm90IGluIHRoaXMgbGlzdCwgYnV0IEkgdGhpbmsgdGhl IHByb2JsZW0gd291bGQgZXhpc3QgZXZlbiBpZiB3YXMuIEFuIGVuY29kZXIgdGhhdCAoZm9yIHdo YXRldmVyIHJlYXNvbikgcHV0cyBpbiB1c2VyX2RhdGFfcmVnaXN0ZXJlZF9pdHVfdF90MzUgb3Ig dXNlcl9kYXRhX3VucmVnaXN0ZXJlZCBzdWZmaXggU0VJIG1lc3NhZ2VzIHdpdGggaGlnaGVyIFRJ ZCB3b3VsZCBwdXQgYSBNQU5FIGluIGEgZGlmZmljdWx0IHNpdHVhdGlvbi4gDQoNCkkgYWxzbyB0 aGluayB3ZSBzaG91bGQgY29uc2lkZXIgZnV0dXJlIGV4dGVuc2lvbnMgb2YgSEVWQyAoaS5lLiBT SFZDIGFuZCBNVi1IRVZDKSBpbiB3aGljaCBhbiBhY2Nlc3MgdW5pdCBtYXkgY29udGFpbiBtYW55 IHBpY3R1cmVzIHdpdGggZGlmZmVyZW50IHZhbHVlcyBvZiBudWhfbGF5ZXJfaWQuIElmIHRoZSBt YXJrZXIgYml0IGlzIHNldCBmb3IgdGhlIGxhc3QgcGFja2V0IG9mIGFuIGFjY2VzcyB1bml0LCB0 aGVuIG9uY2UgYWdhaW4gYWxsIHRoZSBtYXJrZXIgYml0cyB3aWxsIGVuZCB1cCBpbiB0aGUgaGln aGVzdCBsYXllciAoc3RyZWFtKSBhbmQgYSBNQU5FIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHRoZSB2 YWx1ZSBvZiBtYXJrZXIgYml0cyBhcyBzb29uIGFzIG5vdCBhbGwgbGF5ZXJzIChzdHJlYW1zKSBh cmUgZm9yd2FyZGVkLg0KDQpCZXN0IFJlZ2FyZHMgSm9uYXRhbg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2FuZywgWWUtS3VpIFttYWlsdG86eWVrdWl3QHF0aS5xdWFsY29t bS5jb21dIA0KU2VudDogZGVuIDUgbWFycyAyMDE0IDAxOjIwDQpUbzogSm9uYXRhbiBTYW11ZWxz c29uOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0 b29scy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uub3JnDQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3Vi amVjdDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0cC1oMjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9I RVZDDQoNCkhtbSwgYSBkZWNvZGVkIHBpY3R1cmUgaGFzaCBTRUkgbWVzc2FnZSBhcHBsaWVzIHRv IChhbmQgaXMgYXNzb2NpYXRlZCB3aXRoKSB0aGUgcHJlY2VkaW5nIGRlY29kaW5nIHBpY3R1cmUg aW4gZGVjb2Rpbmcgb3JkZXIgYW5kIHRodXMgdGhlIFRJZCBvZiB0aGUgY29udGFpbmluZyBzdWZm aXggU0VJIE5BTCB1bml0IHNob3VsZCBiZSBzZXQgZXF1YWwgdG8gdGhlIFRJZCBvZiB0aGUgYXNz b2NpYXRlZCBwaWN0dXJlLiBUaHVzIGluIHRoZSBleGFtcGxlLCBmb3IgdGhlIHN1ZmZpeCBTRUkg TkFMIHVuaXQgY29udGFpbmluZyB0aGUgZGVjb2RlZCBwaWN0dXJlIGhhc2ggU0VJIG1lc3NhZ2Ug Zm9yIHRoZSBmaXJzdCBlbmNvZGVkIHBpY3R1cmUgc2hvdWxkIGJlIGFzc2lnbmVkIFRJZCBlcXVh bCB0byAwLiANCg0KQWNjb3JkaW5nIHRvIHRoZSBIRVZDIHNwZWMsIGN1cnJlbnRseSB0aGUgZm9s bG93aW5nIFNFSSBtZXNzYWdlcyBhcmUgb3IgY2FuIGJlIHN1ZmZpeCBTRUkgbWVzc2FnZXM6IGZp bGxlcl9wYXlsb2FkLCB1c2VyX2RhdGFfcmVnaXN0ZXJlZF9pdHVfdF90MzUsIHVzZXJfZGF0YV91 bnJlZ2lzdGVyZWQsIHByb2dyZXNzaXZlX3JlZmluZW1lbnRfc2VnbWVudF9lbmQsIHBvc3RfZmls dGVyX2hpbnQsIGFuZCBkZWNvZGVkX3BpY3R1cmVfaGFzaC4gQW1vbmcgdGhlc2UsIEkgdGhpbmsg YWxsIG9mIHRoZSAic3BlY2lmaWVkIiBTRUkgbWVzc2FnZXMgKGkuZS4gdGhlIGFib3ZlIGxpc3Qg ZXhjbHVkaW5nIHVzZXJfZGF0YV9yZWdpc3RlcmVkX2l0dV90X3QzNSwgdXNlcl9kYXRhX3VucmVn aXN0ZXJlZCkgY29udGFpbmVkIGluIGEgc3VmZml4IFNFSSBOQUwgdW5pdCB3b3VsZCBhcHBseSB0 byB0aGUgcHJlY2VkaW5nIGRlY29kZWQgcGljdHVyZSBpbiBkZWNvZGVyIG9yZGVyIGFuZCBzaG91 bGQgaGF2ZSB0aGUgc2FtZSBUSWQgYXMgdGhlIGFzc29jaWF0ZWQgcGljdHVyZS4gVGhlIG9ubHkg U0VJIG1lc3NhZ2VzIHRoYXQgY2FuIGhhdmUgYSBncmVhdGVyIFRJZCB2YWx1ZSB0aGFuIHRoZSBj b250YWluaW5nIGFjY2VzcyB1bml0IGFyZSB0aGUgdGhyZWUgU0VJIG1lc3NhZ2UgdGhhdCBjYW4g Y2FycnkgSFJEIGluZm9ybWF0aW9uLCBpLmUuLCBidWZmZXJpbmdfcGVyaW9kLCBwaWNfdGltaW5n LCBhbmQgZGVjb2RpbmdfdW5pdF9pbmZvLCBidXQgdGhlc2UgY2FuIG9ubHkgYmUgcHJlZml4IFNF SSBtZXNzYWdlcy4NCg0KT2YgY291cnNlLCBpbiB0aGVvcnksIGZ1dHVyZSB2ZXJzaW9ucyBvZiBI RVZDIG9yIHNvbWUgZXh0ZW5zaW9ucyAoZXZlbiBkZWZpbmVkIGJ5IGFuIGFwcGxpY2F0aW9uIHNw ZWMpIGNvdWxkIGRlZmluZSBzdWZmaXggU0VJIG1lc3NhZ2VzIHRoYXQgY2FuIGhhdmUgYSBncmVh dGVyIFRJZCB2YWx1ZSB0aGFuIHRoZSBjb250YWluaW5nIGFjY2VzcyB1bml0LiBJbiB0aGF0IGNh c2UsIHdoYXQgeW91IGRlc2NyaWJlZCBjb3VsZCBiZSBtZWFuaW5nZnVsLCBhbmQgaW5kZWVkIGlm IGEgcmVjZWl2ZXIgcmVjZWl2ZXMgdGhlICJiYXNlIHN1Yi1sYXllciIgc3RyZWFtLCBzb21lIGVu dGl0eSB3b3VsZCBoYXZlIHRvIHNldCB0aGUgbWFya2VyIGJpdCBvZiB0aG9zZSBwYWNrZXRzIGNv bnRhaW5pbmcgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gYWNjZXNzIHVuaXQgZm9yIHRoYXQgc3Ry ZWFtLCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgc2VtYW50aWNzLg0KDQpIb3dldmVyLCBpZiB3 ZSBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gdGhlIGxhc3QgVkNMIE5BTCB1bml0IGFzIHlvdSBzdWdn ZXN0ZWQsIGFuZCBpbiBjYXNlIGEgc3VmZml4IFNFSSBOQUwgdW5pdCBvZiBwaWN0dXJlIEEgaXMg bm90IGNhcnJpZWQgdGhlIHBhY2tldCBjb250YWluaW5nIHRoZSBsYXN0IFZDTCBOQUwgdW5pdCBp ZiB0aGUgYWNjZXNzIHVuaXQsIHdvdWxkIHRoZSB1c2FnZSBvZiB0aGUgbWFya2VyIGJpdCBiZSBh ZmZlY3RlZCwgZS5nLiBpbiBwbGF5b3V0IGJ1ZmZlciBoYW5kbGluZz8gSWYgdGhlIGFuc3dlciBp cyBubywgdGhlbiB0aGVyZSBzaG91bGQgYmUgbm8gcHJvYmxlbSB0byBkbyB0aGUgY2hhbmdlLg0K DQpCYXNpY2FsbHkgdGhlIHNpdHVhdGlvbiBpcyBhcyBmb2xsb3dzLiBUaGVyZSBpcyBubyBjb25j cmV0ZSBwcm9ibGVtIG5vdy4gSG93ZXZlciwgdGhlcmUgY2FuIGJlIGEgcG90ZW50aWFsIHByb2Js ZW0gaW4gdGhlIGZ1dHVyZSBpZiBhIHN1ZmZpeCBTRUkgbWVzc2FnZSBpcyBkZWZpbmVkIGFuZCBj YW4gaGF2ZSBhIGdyZWF0ZXIgVElkIHZhbHVlIHRoYW4gdGhlIGNvbnRhaW5pbmcgYWNjZXNzIHVu aXQuIElmIHRoZSBzdWdnZXN0ZWQgY2hhbmdlIGRvZXMgbm90IGFmZmVjdCB0aGUgdXNhZ2Ugb2Yg dGhlIGJpdCwgd2Ugc2hvdWxkIGRvIHRoZSBjaGFuZ2Ugbm93IHRvIG1ha2UgdGhlIGRlc2lnbiBm dXR1cmUtcHJvb2YuIFNvIHRoZSBrZXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgc3VnZ2VzdCBj aGFuZ2Ugd291bGQgYWZmZWN0IHRoZSB1c2FnZSBvZiB0aGUgYml0LiANCg0KRG9lcyBhbnlvbmUg a25vdyBob3cgdGhlIG1hcmtlciBiaXQgaXMgdXNlZCBpbiBwbGF5b3V0IGJ1ZmZlcmluZyBoYW5k bGluZz8gQW4gZXhwbGFuYXRpb24gb3IgYSBwb2ludGVyIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVj aWF0ZWQuDQoNCkJSLCBZSw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9u YXRhbiBTYW11ZWxzc29uIFttYWlsdG86am9uYXRhbi5zYW11ZWxzc29uQGVyaWNzc29uLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwNCwgMjAxNCAxOjI4IFBNDQpUbzogV2FuZywgWWUtS3Vp OyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0b29s cy5pZXRmLm9yZzsgc3Rld2VAc3Rld2Uub3JnDQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0cC1oMjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9IRVZD DQoNCkRlYXIgWWUtS3VpLA0KDQpMZXQgbWUgdHJ5IHRvIG1ha2UgdGhlIGV4YW1wbGUgbW9yZSBz cGVjaWZpYyAoYW5kIHRoZW4gYWxzbyBzZWUgaWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhlIG11bHRp LXN0cmVhbSB0cmFuc21pc3Npb24gY29uY2VwdCBjb3JyZWN0bHkpLg0KDQpBc3N1bWUgdGhhdCB0 aGUgc2VuZGVyIHB1dHMgYWxsIE5BTCB1bml0cyB3aXRoIFRJZCAwIGluIG9uZSBSVFAgc3RyZWFt IChzdHJlYW0gQSkgYW5kIGFsbCBOQUwgdW5pdHMgd2l0aCBUSWQgMSBpbiBhbm90aGVyIFJUUCBz dHJlYW0gKHN0cmVhbSBCKS4gTm93IGZvciB0aGUgZmlyc3QgZW5jb2RlZCBwaWN0dXJlIHRoZSBW Q0wgTkFMIHVuaXRzIGFyZSBhc3NpZ25lZCBUSWQgMCBhbmQgdGhlbiBhIGRlY29kZWQgcGljdHVy ZSBoYXNoIFNFSSBtZXNzYWdlIGlzIGNyZWF0ZWQgaW4gdGhlIHNhbWUgYWNjZXNzIHVuaXQgYnV0 IGlzIGdpdmVuIFRJZCAxLiBUaGVuIHRoZSBtYXJrZXIgYml0IHdpbGwgYmUgc2V0IG9uIHRoZSBw YWNrZXQgY29udGFpbmluZyB0aGUgZGVjb2RlZCBwaWN0dXJlIGhhc2ggU0VJIG1lc3NhZ2Ugd2hp Y2ggaXMgcHV0IGluIHN0cmVhbSBCLiBJZiB0aGlzIHNjaGVtZSBpcyBhcHBsaWVkIGZvciBhbGwg YWNjZXNzIHVuaXRzLCBzdHJlYW0gQSB3aWxsIG5vdCBjb250YWluIGFueSBwYWNrZXRzIHdpdGgg dGhlIG1hcmtlciBiaXQgc2V0IHNpbmNlIHRoZXNlIGFyZSBhbGwgcHV0IGluIHN0cmVhbSBCLiBB IE1BTkUgdGhhdCBvbmx5IHdhbnRzIHRvIGZvcndhcmQgc3RyZWFtIEEgdG8gYSByZWNlaXZlciB3 b3VsZCBiZSByZXF1aXJlZCB0byBwZXJmb3JtIGFuYWx5c2lzIChhbmQgcHJvYmFibHkgaW50cm9k dWNlIGRlbGF5KSBpbiBvcmRlciB0byBjb3JyZWN0bHkgY2hhbmdlIHRoZSBtYXJrZXIgYml0IG9u IHRoZSAibmV3IiBsYXN0IHBhY2tldCBvZiB0aGUgYWNjZXNzIHVuaXQuDQoNCklzIHRoYXQgY29y cmVjdCwgb3IgaGF2ZSBJIG1pc2ludGVycHJldGVkIGFueXRoaW5nPw0KDQpCZXN0IFJlZ2FyZHMg Sm9uYXRhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2FuZywgWWUtS3Vp IFttYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb21dIA0KU2VudDogZGVuIDQgbWFycyAyMDE0 IDE4OjIxDQpUbzogcGF5bG9hZCBpc3N1ZSB0cmFja2VyOyBkcmFmdC1pZXRmLXBheWxvYWQtcnRw LWgyNjVAdG9vbHMuaWV0Zi5vcmc7IHN0ZXdlQHN0ZXdlLm9yZzsgSm9uYXRhbiBTYW11ZWxzc29u DQpDYzogcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtwYXlsb2FkXSAjMTAgKHJ0cC1o MjY1KTogTWFya2VyIGJpdCBpbiBILjI2NS9IRVZDDQoNCkhpIEpvbmF0YW4sDQoNCkkgZG8gbm90 IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KDQoiSG93ZXZlciwgYXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCwgaXQgaXMgYWxsb3dlZCBmb3IgYW4gZW5jb2RlciB0byBjcmVh dGUgYSAgYml0c3RyZWFtIHdpdGggdHdvIHRlbXBvcmFsIHN1Yi1sYXllcnMgKGV2ZXJ5IHNlY29u ZCBwaWN0dXJlIHdpdGggVElkIDAgIGFuZCBldmVyeSBzZWNvbmQgcGljdHVyZSB3aXRoIFRJZCAx KSBidXQgcHV0IHBvc3QtcGljdHVyZSBTRUkgbWVzc2FnZXMgZm9yICBhbGwgYWNjZXNzIHVuaXRz IGluIHRlbXBvcmFsIGxheWVyIDEgKGFsc28gZm9yIGFjY2VzcyB1bml0cyBpbiB3aGljaCB0aGUg IHBpY3R1cmUgaGFzIFRJZCAwLCBhcyBhIGhpbnQgb2YgdGhlIHJlbGF0aXZlIGltcG9ydGFuY2Ug b2YgdGhlIE5BTCB1bml0cykuIEZvciB0aGF0IGNhc2UgSSBndWVzcyB0aGVyZSB3aWxsIGJlIG9u ZSBSVFAgc3RyZWFtIChjb3JyZXNwb25kaW5nIHRvIFRJZCAwKSBjb21wbGV0ZWx5IHdpdGhvdXQg YW55IG1hcmtlciBiaXQgc2V0LCByaWdodD8iDQoNCkNvdWxkIHlvdSBwbGVhc2UgY2hlY2sgd2hl dGhlciBpdCBjYW4gYmUgY2xhcmlmaWVkIGEgYml0Pw0KDQpCUiwgWUsNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHBheWxvYWQgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMr cGF5bG9hZEB0cmFjLnRvb2xzLmlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDMsIDIw MTQgMjoxMSBQTQ0KVG86IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9y ZzsgV2FuZywgWWUtS3VpOyBzdGV3ZUBzdGV3ZS5vcmc7IGpvbmF0YW4uc2FtdWVsc3NvbkBlcmlj c3Nvbi5jb20NCkNjOiBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BheWxvYWRdICMx MCAocnRwLWgyNjUpOiBNYXJrZXIgYml0IGluIEguMjY1L0hFVkMNCg0KIzEwOiBNYXJrZXIgYml0 IGluIEguMjY1L0hFVkMNCg0KDQpDb21tZW50IChieSBqb25hdGFuLnNhbXVlbHNzb25AZXJpY3Nz b24uY29tKToNCg0KIFRoYW5rcyBTdGVmYW4gZm9yIHRoZSBjb21tZW50cyBhbmQgdGhlIGV4YW1w bGUuIEl0IGlzIGV4YWN0bHkgdGhpcyBraW5kIG9mICBjYXNlcyBJJ20gY29uY2VybmVkIGFib3V0 IGJ1dCBJIHdvdWxkbid0IGNoYXJhY3Rlcml6ZSB0aGVtIGFzIGV4b3RpYy4gRm9yICBjb252ZXJz YXRpb25hbCBhcHBsaWNhdGlvbnMgaXQgaXMgbmF0dXJhbCB0byBvcGVyYXRlIGluICp2ZXJ5KiBs b3cgZGVsYXkgIG1vZGUgKGkuZS4gbm90IGJ1ZmZlcmluZyBwYWNrZXRzIGJlZm9yZSBmb3J3YXJk aW5nIHRoZW0pIGFuZCBoYXZpbmcgcG9zdC0gIHBpY3R1cmUgU0VJIHBhY2tldGl6ZWQgaW4gdGhl aXIgb3duIHBhY2tldHMgaXMgdGhlIG9ubHkgb3B0aW9uIGFzIHNvb24gYXMgIHRoZSBWQ0wgTkFM IHVuaXRzIGFyZSBmcmFnbWVudGVkIHNpbmNlIEZVcyBjYW5ub3QgYmUgYWdncmVnYXRlZC4gSGF2 aW5nIHRvICBpbnRyb2R1Y2Ugc2xpY2VzIGp1c3QgdG8gYXZvaWQgRlVzIGFuZCB0aGVyZWJ5IGJl aW5nIGFibGUgdG8gYWdncmVnYXRlIFNFSSAgbWVzc2FnZXMgd2l0aCBWQ0wgTkFMIHVuaXRzIGRv ZXMgbm90IHNvdW5kIGxpa2UgYSBjb21wZWxsaW5nIGFsdGVybmF0aXZlLg0KDQogVGhlIG1vc3Qg cmVhc29uYWJsZSBzb2x1dGlvbiBmb3IgdGhpcyBjYXNlIGlzIHByb2JhYmx5IHRvIGp1c3Qgbm90 IHBlcmZvcm0gIHRoaW5uaW5nIGJ5IHJlbW92aW5nIHRoZSBTRUkgbWVzc2FnZXMgc2luY2UgdGhl eSBhcmUgdHlwaWNhbGx5IG5vdCB2ZXJ5ICBsYXJnZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCiBI b3dldmVyLCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCBpdCBpcyBhbGxvd2VkIGZvciBhbiBlbmNv ZGVyIHRvIGNyZWF0ZSBhICBiaXRzdHJlYW0gd2l0aCB0d28gdGVtcG9yYWwgc3ViLWxheWVycyAo ZXZlcnkgc2Vjb25kIHBpY3R1cmUgd2l0aCBUSWQgMCAgYW5kIGV2ZXJ5IHNlY29uZCBwaWN0dXJl IHdpdGggVElkIDEpIGJ1dCBwdXQgcG9zdC1waWN0dXJlIFNFSSBtZXNzYWdlcyBmb3IgIGFsbCBh Y2Nlc3MgdW5pdHMgaW4gdGVtcG9yYWwgbGF5ZXIgMSAoYWxzbyBmb3IgYWNjZXNzIHVuaXRzIGlu IHdoaWNoIHRoZSAgcGljdHVyZSBoYXMgVElkIDAsIGFzIGEgaGludCBvZiB0aGUgcmVsYXRpdmUg aW1wb3J0YW5jZSBvZiB0aGUgTkFMIHVuaXRzKS4NCiBGb3IgdGhhdCBjYXNlIEkgZ3Vlc3MgdGhl cmUgd2lsbCBiZSBvbmUgUlRQIHN0cmVhbSAoY29ycmVzcG9uZGluZyB0byBUSWQNCiAwKSBjb21w bGV0ZWx5IHdpdGhvdXQgYW55IG1hcmtlciBiaXQgc2V0LCByaWdodD8NCg0KLS0gDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQogUmVw b3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBPd25lcjogIGRyYWZ0LWll dGYtcGF5bG9hZC0NCiAgam9uYXRhbi5zYW11ZWxzc29uQGVyaWNzc29uLmNvbSAgICB8ICBydHAt aDI2NUB0b29scy5pZXRmLm9yZw0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAg IHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAg ICB8ICAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcnRwLWgyNjUgICAgICAgICAgICAgICAgIHwg ICAgIFZlcnNpb246ICAyLjANCiBTZXZlcml0eTogIC0gICAgICAgICAgICAgICAgICAgICAgICB8 ICBSZXNvbHV0aW9uOg0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0N Cg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3BheWxvYWQvdHJh Yy90aWNrZXQvMTAjY29tbWVudDozPg0KcGF5bG9hZCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3Bh eWxvYWQvPg0KDQo= From nobody Wed Mar 5 11:22:37 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22A1A0183 for ; Wed, 5 Mar 2014 11:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 CmExmyG4UAJC for ; Wed, 5 Mar 2014 11:22:28 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 541C31A011E for ; Wed, 5 Mar 2014 11:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394047346; x=1425583346; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T04FhSGGWQa5KYVX0mhlQy7IHOw3UDSs18BKxMfjMRs=; b=QJ1l13h75eWjWD03Wy1v7OKyQ7T2e8tEnMtYG68/Sfy8ilV3uutslxDz M9wWoEIQK6IH3uP0rPGKAU/ntbjm1pE5xsYR2SmJPToS28g3tJBKr+W07 R/sGo5yRIXKDBtOy1BeGYLRLMdB1oHFOWPy8yHYVOixm8PdYbOSN3cdQN k=; X-IronPort-AV: E=McAfee;i="5400,1158,7368"; a="60229791" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 05 Mar 2014 11:22:26 -0800 X-IronPort-AV: E=Sophos;i="4.97,593,1389772800"; d="scan'208";a="27739578" Received: from nasanexhc02.na.qualcomm.com ([172.30.48.24]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2014 11:22:24 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by NASANEXHC02.na.qualcomm.com ([172.30.48.24]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 11:20:50 -0800 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , "payload issue tracker" , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "stewe@stewe.org" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQA== Date: Wed, 5 Mar 2014 19:20:50 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/-TzO_pibW6Ogi18X7jlF9ntzLnM Cc: "payload@ietf.org" Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:22:30 -0000 I did a bit of search on the usage of the marker bit for video, and the mos= t relevant description I found was the following paragraph in Section 5 of = RFC 3551: Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed. So the key usage of the marker bit is that in some low-delay applications, = output/display of a picture can be done before receiving an RTP packet with= a different/greater timestamp. Since non-VCL NAL unit should have the same= timestamp as the associated picture, thus I think we should not use the wo= rding of "last VCL NAL unit" in determining the setting of the marker bit. To make the semantics extensible or future-proof for multi-layer extensions= , I think we should change it to be RTP stream (or equivalently packet stre= am) specific, and each receiver can just look at the marker bits of the pac= kets from the highest RTP stream for the usage. And this will also resolve = the issue of requiring some entities to change the marker bit in sub-layer = scalability usage as Jonaton raised.=20 In other words, the normative semantics are to be changed as follows: Marker bit (M): 1 bit Set for the last packet, carried in the current RTP stream, of an access un= it, in line with the normal use of the M bit in video formats, to allow an = efficient playout buffer handling. Please let me know if there is any concern with such a change (and note tha= t we would align the terminology of RTP stream with other drafts, e.g. the = Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing co= mments). BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Wednesday, March 05, 2014 10:29 AM To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; stewe@stewe.org Cc: payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Something should be done to the HEVC spec to make it clearer for the decode= d picture hash SEI message, like that it shall not be nested and what the v= alues of LayerId and LId should be, or allow add to the list of nestable SE= I message. In any case, it does not make sense to me to put a greater value= of TId than its associated picture. On user_data_registered_itu_t_t35 and = user_data_unregistered suffix SEI messages, only if it is defined by some a= pplication then it may make sense to put a greater value of TId than its as= sociated picture - currently I have not seen any such use being defined any= where. Anyway, I admitted that the current semantics are not fully future-proof re= garding suffix SEI messages. In looking into future multi-layer extensions,= it appears that simply changing the wording from "last NAL unit" to "last = VCL NAL unit" is not good enough. We might need to specify the semantics of= the marker bit to be RTP stream specific. To make sure whether such a chan= ge is OK, we also need to check against the usage of the marker bit. BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 Sent: Wednesday, March 05, 2014 1:07 AM To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tools.= ietf.org; stewe@stewe.org Cc: payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thanks for your response Ye-Kui, As far as I understand, out of the 6 SEI messages that have so far been def= ined in the HEVC spec as possible to use as suffixes (filler_payload, user_= data_registered_itu_t_t35, user_data_unregistered, progressive_refinement_s= egment_end, post_filter_hint, and decoded_picture_hash) there are 3 that ar= e not required to have the same TId as the VCL NAL units of the access unit= : user_data_registered_itu_t_t35, user_data_unregistered and decoded_pictu= re_hash since their payloadType numbers (4, 5 and 132) are not included in = the list: "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 16,= 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages th= at have payloadType not equal to 0, 1, or 130, and that are allowed to be n= ested SEI messages), the SEI NAL unit containing the non-nested SEI message= shall have TemporalId equal to the TemporalId of the access unit containin= g the SEI NAL unit." Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I t= hink the problem would exist even if was. An encoder that (for whatever rea= son) puts in user_data_registered_itu_t_t35 or user_data_unregistered suffi= x SEI messages with higher TId would put a MANE in a difficult situation.=20 I also think we should consider future extensions of HEVC (i.e. SHVC and MV= -HEVC) in which an access unit may contain many pictures with different val= ues of nuh_layer_id. If the marker bit is set for the last packet of an acc= ess unit, then once again all the marker bits will end up in the highest la= yer (stream) and a MANE would have to change the value of marker bits as so= on as not all layers (streams) are forwarded. Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 5 mars 2014 01:20 To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; stewe@stewe.org Cc: payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Hmm, a decoded picture hash SEI message applies to (and is associated with)= the preceding decoding picture in decoding order and thus the TId of the c= ontaining suffix SEI NAL unit should be set equal to the TId of the associa= ted picture. Thus in the example, for the suffix SEI NAL unit containing th= e decoded picture hash SEI message for the first encoded picture should be = assigned TId equal to 0.=20 According to the HEVC spec, currently the following SEI messages are or can= be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, us= er_data_unregistered, progressive_refinement_segment_end, post_filter_hint,= and decoded_picture_hash. Among these, I think all of the "specified" SEI = messages (i.e. the above list excluding user_data_registered_itu_t_t35, use= r_data_unregistered) contained in a suffix SEI NAL unit would apply to the = preceding decoded picture in decoder order and should have the same TId as = the associated picture. The only SEI messages that can have a greater TId v= alue than the containing access unit are the three SEI message that can car= ry HRD information, i.e., buffering_period, pic_timing, and decoding_unit_i= nfo, but these can only be prefix SEI messages. Of course, in theory, future versions of HEVC or some extensions (even defi= ned by an application spec) could define suffix SEI messages that can have = a greater TId value than the containing access unit. In that case, what you= described could be meaningful, and indeed if a receiver receives the "base= sub-layer" stream, some entity would have to set the marker bit of those p= ackets containing the last NAL unit of an access unit for that stream, acco= rding to the current semantics. However, if we change the wording to the last VCL NAL unit as you suggested= , and in case a suffix SEI NAL unit of picture A is not carried the packet = containing the last VCL NAL unit if the access unit, would the usage of the= marker bit be affected, e.g. in playout buffer handling? If the answer is = no, then there should be no problem to do the change. Basically the situation is as follows. There is no concrete problem now. Ho= wever, there can be a potential problem in the future if a suffix SEI messa= ge is defined and can have a greater TId value than the containing access u= nit. If the suggested change does not affect the usage of the bit, we shoul= d do the change now to make the design future-proof. So the key question is= whether the suggest change would affect the usage of the bit.=20 Does anyone know how the marker bit is used in playout buffering handling? = An explanation or a pointer would be greatly appreciated. BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 Sent: Tuesday, March 04, 2014 1:28 PM To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tools.= ietf.org; stewe@stewe.org Cc: payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Dear Ye-Kui, Let me try to make the example more specific (and then also see if I have u= nderstood the multi-stream transmission concept correctly). Assume that the sender puts all NAL units with TId 0 in one RTP stream (str= eam A) and all NAL units with TId 1 in another RTP stream (stream B). Now f= or the first encoded picture the VCL NAL units are assigned TId 0 and then = a decoded picture hash SEI message is created in the same access unit but i= s given TId 1. Then the marker bit will be set on the packet containing the= decoded picture hash SEI message which is put in stream B. If this scheme = is applied for all access units, stream A will not contain any packets with= the marker bit set since these are all put in stream B. A MANE that only w= ants to forward stream A to a receiver would be required to perform analysi= s (and probably introduce delay) in order to correctly change the marker bi= t on the "new" last packet of the access unit. Is that correct, or have I misinterpreted anything? Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 4 mars 2014 18:21 To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; stew= e@stewe.org; Jonatan Samuelsson Cc: payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Hi Jonatan, I do not fully understand the following example: "However, as far as I understand, it is allowed for an encoder to create a = bitstream with two temporal sub-layers (every second picture with TId 0 a= nd every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the p= icture has TId 0, as a hint of the relative importance of the NAL units). F= or that case I guess there will be one RTP stream (corresponding to TId 0) = completely without any marker bit set, right?" Could you please check whether it can be clarified a bit? BR, YK -----Original Message----- From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 Sent: Monday, March 03, 2014 2:11 PM To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe.o= rg; jonatan.samuelsson@ericsson.com Cc: payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC #10: Marker bit in H.265/HEVC Comment (by jonatan.samuelsson@ericsson.com): Thanks Stefan for the comments and the example. It is exactly this kind of= cases I'm concerned about but I wouldn't characterize them as exotic. For= conversational applications it is natural to operate in *very* low delay = mode (i.e. not buffering packets before forwarding them) and having post- = picture SEI packetized in their own packets is the only option as soon as = the VCL NAL units are fragmented since FUs cannot be aggregated. Having to= introduce slices just to avoid FUs and thereby being able to aggregate SE= I messages with VCL NAL units does not sound like a compelling alternative= . The most reasonable solution for this case is probably to just not perform= thinning by removing the SEI messages since they are typically not very = large in the first place. However, as far as I understand, it is allowed for an encoder to create a = bitstream with two temporal sub-layers (every second picture with TId 0 a= nd every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the p= icture has TId 0, as a hint of the relative importance of the NAL units). For that case I guess there will be one RTP stream (corresponding to TId 0) completely without any marker bit set, right? --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Mar 5 16:05:06 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0C1A0290 for ; Wed, 5 Mar 2014 16:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ie2Iu9jcJAWg for ; Wed, 5 Mar 2014 16:04:57 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4D11A0244 for ; Wed, 5 Mar 2014 16:04:57 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/5/2014 7:04:51 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-56/SG:2 3/5/2014 7:04:19 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.889635 p=-0.982187 Source White X-Signature-Violations: 0-0-0-31110-c X-Note-419: 46.8012 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 3/5/2014 7:04:52 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77726181; Wed, 05 Mar 2014 19:04:51 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 18:04:50 -0600 From: Jonathan Lennox To: "Wang, Ye-Kui" Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQIAAuiiA Date: Thu, 6 Mar 2014 00:04:50 +0000 Message-ID: <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.3.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02476E2D6020E5489F0AE7AA122DCE8A@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/_rOm_WCD7HayTHqHo-SQjmz2yoU Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:05:02 -0000 This seems correct to me. I would suggest, however, explicitly pointing ou= t that in MST mode, if an access unit appears in multiple packet streams, t= he marker bit is set on each packet stream=92s last packet of the access un= it. I think this definition works even when DONs are in use (when sprop-depack-= buf-nalus is > 0), since an AP can only contain packets from a single acces= s unit. If packets from different access units are interleaved (in RTP ord= er) using DON, the packet stream will look odd to a naive RTP analysis, but= I believe the marker bit will still be useful, allowing low-delay decoders= to flush complete access units out of the de-packetization buffer early. Ye-Kui, a question about your comment, though: are we sure that the final p= acket of the access unit will in fact always be the final packet of the hig= hest layer? In particular, in SHVC or MV-HEVC, presumably we=92ll be able = to split MST streams by nuh_layer_id. How will the nuh_layer_id be set for= trailing SEIs in such streams? If it=92s set to 0, then the final packet = of the access unit will in fact be sent in a lower layer. I don=92t think = this actually matters, especially since MST streams will use DON, but we sh= ould be careful about our logic. On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: > I did a bit of search on the usage of the marker bit for video, and the m= ost relevant description I found was the following paragraph in Section 5 o= f RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > So the key usage of the marker bit is that in some low-delay applications= , output/display of a picture can be done before receiving an RTP packet wi= th a different/greater timestamp. Since non-VCL NAL unit should have the sa= me timestamp as the associated picture, thus I think we should not use the = wording of "last VCL NAL unit" in determining the setting of the marker bit= . >=20 > To make the semantics extensible or future-proof for multi-layer extensio= ns, I think we should change it to be RTP stream (or equivalently packet st= ream) specific, and each receiver can just look at the marker bits of the p= ackets from the highest RTP stream for the usage. And this will also resolv= e the issue of requiring some entities to change the marker bit in sub-laye= r scalability usage as Jonaton raised.=20 >=20 > In other words, the normative semantics are to be changed as follows: >=20 > Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling. >=20 > Please let me know if there is any concern with such a change (and note t= hat we would align the terminology of RTP stream with other drafts, e.g. th= e Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing = comments). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui > Sent: Wednesday, March 05, 2014 10:29 AM > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Something should be done to the HEVC spec to make it clearer for the deco= ded picture hash SEI message, like that it shall not be nested and what the= values of LayerId and LId should be, or allow add to the list of nestable = SEI message. In any case, it does not make sense to me to put a greater val= ue of TId than its associated picture. On user_data_registered_itu_t_t35 an= d user_data_unregistered suffix SEI messages, only if it is defined by some= application then it may make sense to put a greater value of TId than its = associated picture - currently I have not seen any such use being defined a= nywhere. >=20 > Anyway, I admitted that the current semantics are not fully future-proof = regarding suffix SEI messages. In looking into future multi-layer extension= s, it appears that simply changing the wording from "last NAL unit" to "las= t VCL NAL unit" is not good enough. We might need to specify the semantics = of the marker bit to be RTP stream specific. To make sure whether such a ch= ange is OK, we also need to check against the usage of the marker bit. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, March 05, 2014 1:07 AM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks for your response Ye-Kui, >=20 > As far as I understand, out of the 6 SEI messages that have so far been d= efined in the HEVC spec as possible to use as suffixes (filler_payload, use= r_data_registered_itu_t_t35, user_data_unregistered, progressive_refinement= _segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that = are not required to have the same TId as the VCL NAL units of the access un= it: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pic= ture_hash since their payloadType numbers (4, 5 and 132) are not included i= n the list: >=20 > "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 1= 6, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages = that have payloadType not equal to 0, 1, or 130, and that are allowed to be= nested SEI messages), the SEI NAL unit containing the non-nested SEI messa= ge shall have TemporalId equal to the TemporalId of the access unit contain= ing the SEI NAL unit." >=20 > Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I= think the problem would exist even if was. An encoder that (for whatever r= eason) puts in user_data_registered_itu_t_t35 or user_data_unregistered suf= fix SEI messages with higher TId would put a MANE in a difficult situation.= =20 >=20 > I also think we should consider future extensions of HEVC (i.e. SHVC and = MV-HEVC) in which an access unit may contain many pictures with different v= alues of nuh_layer_id. If the marker bit is set for the last packet of an a= ccess unit, then once again all the marker bits will end up in the highest = layer (stream) and a MANE would have to change the value of marker bits as = soon as not all layers (streams) are forwarded. >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 5 mars 2014 01:20 > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hmm, a decoded picture hash SEI message applies to (and is associated wit= h) the preceding decoding picture in decoding order and thus the TId of the= containing suffix SEI NAL unit should be set equal to the TId of the assoc= iated picture. Thus in the example, for the suffix SEI NAL unit containing = the decoded picture hash SEI message for the first encoded picture should b= e assigned TId equal to 0.=20 >=20 > According to the HEVC spec, currently the following SEI messages are or c= an be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, = user_data_unregistered, progressive_refinement_segment_end, post_filter_hin= t, and decoded_picture_hash. Among these, I think all of the "specified" SE= I messages (i.e. the above list excluding user_data_registered_itu_t_t35, u= ser_data_unregistered) contained in a suffix SEI NAL unit would apply to th= e preceding decoded picture in decoder order and should have the same TId a= s the associated picture. The only SEI messages that can have a greater TId= value than the containing access unit are the three SEI message that can c= arry HRD information, i.e., buffering_period, pic_timing, and decoding_unit= _info, but these can only be prefix SEI messages. >=20 > Of course, in theory, future versions of HEVC or some extensions (even de= fined by an application spec) could define suffix SEI messages that can hav= e a greater TId value than the containing access unit. In that case, what y= ou described could be meaningful, and indeed if a receiver receives the "ba= se sub-layer" stream, some entity would have to set the marker bit of those= packets containing the last NAL unit of an access unit for that stream, ac= cording to the current semantics. >=20 > However, if we change the wording to the last VCL NAL unit as you suggest= ed, and in case a suffix SEI NAL unit of picture A is not carried the packe= t containing the last VCL NAL unit if the access unit, would the usage of t= he marker bit be affected, e.g. in playout buffer handling? If the answer i= s no, then there should be no problem to do the change. >=20 > Basically the situation is as follows. There is no concrete problem now. = However, there can be a potential problem in the future if a suffix SEI mes= sage is defined and can have a greater TId value than the containing access= unit. If the suggested change does not affect the usage of the bit, we sho= uld do the change now to make the design future-proof. So the key question = is whether the suggest change would affect the usage of the bit.=20 >=20 > Does anyone know how the marker bit is used in playout buffering handling= ? An explanation or a pointer would be greatly appreciated. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Tuesday, March 04, 2014 1:28 PM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Dear Ye-Kui, >=20 > Let me try to make the example more specific (and then also see if I have= understood the multi-stream transmission concept correctly). >=20 > Assume that the sender puts all NAL units with TId 0 in one RTP stream (s= tream A) and all NAL units with TId 1 in another RTP stream (stream B). Now= for the first encoded picture the VCL NAL units are assigned TId 0 and the= n a decoded picture hash SEI message is created in the same access unit but= is given TId 1. Then the marker bit will be set on the packet containing t= he decoded picture hash SEI message which is put in stream B. If this schem= e is applied for all access units, stream A will not contain any packets wi= th the marker bit set since these are all put in stream B. A MANE that only= wants to forward stream A to a receiver would be required to perform analy= sis (and probably introduce delay) in order to correctly change the marker = bit on the "new" last packet of the access unit. >=20 > Is that correct, or have I misinterpreted anything? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 4 mars 2014 18:21 > To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; st= ewe@stewe.org; Jonatan Samuelsson > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hi Jonatan, >=20 > I do not fully understand the following example: >=20 > "However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units).= For that case I guess there will be one RTP stream (corresponding to TId 0= ) completely without any marker bit set, right?" >=20 > Could you please check whether it can be clarified a bit? >=20 > BR, YK >=20 > -----Original Message----- > From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 > Sent: Monday, March 03, 2014 2:11 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe= .org; jonatan.samuelsson@ericsson.com > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > #10: Marker bit in H.265/HEVC >=20 >=20 > Comment (by jonatan.samuelsson@ericsson.com): >=20 > Thanks Stefan for the comments and the example. It is exactly this kind o= f cases I'm concerned about but I wouldn't characterize them as exotic. Fo= r conversational applications it is natural to operate in *very* low delay= mode (i.e. not buffering packets before forwarding them) and having post-= picture SEI packetized in their own packets is the only option as soon as= the VCL NAL units are fragmented since FUs cannot be aggregated. Having t= o introduce slices just to avoid FUs and thereby being able to aggregate S= EI messages with VCL NAL units does not sound like a compelling alternativ= e. >=20 > The most reasonable solution for this case is probably to just not perfor= m thinning by removing the SEI messages since they are typically not very = large in the first place. >=20 > However, as far as I understand, it is allowed for an encoder to create a= bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). > For that case I guess there will be one RTP stream (corresponding to TId > 0) completely without any marker bit set, right? >=20 > --=20 > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Wed Mar 5 16:18:16 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66D1A0011 for ; Wed, 5 Mar 2014 16:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 Ad8u_s7q_JJW for ; Wed, 5 Mar 2014 16:18:13 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00E1A0004 for ; Wed, 5 Mar 2014 16:18:13 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/5/2014 7:18:08 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-56/SG:2 3/5/2014 7:17:19 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.890093 p=-0.981912 Source White X-Signature-Violations: 0-0-0-3806-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/5/2014 7:17:53 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77728396; Wed, 05 Mar 2014 19:18:08 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 18:18:08 -0600 From: Jonathan Lennox To: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: A few questions about DON in the H.265 payload Thread-Index: AQHPONGMMPGmnatbJkuiS2/WscfY4Q== Date: Thu, 6 Mar 2014 00:18:07 +0000 Message-ID: <8A37BB2C-70A2-46FD-832D-EFA82F4A98A7@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.3.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/VCPlYg7xajFMFw5iPx6GUspT6d8 Subject: [payload] A few questions about DON in the H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:18:15 -0000 When reading over the H.265 payload spec to understand DON and marker bits,= I realized I had a few questions/comments about DON. 1. DON values are not required to be consecutive. How does this interact w= ith sprop-depack-buf-nalus? If, as a receiver, I=92m decoding a stream wit= h sprop-depack-buf-nalus =3D=3D 2, and I receive a packet with DON 1 and th= en one with DON 3, may I immediately release the packet with DON 1 to the d= ecoder? 2. The definition of sprop-depack-buf-nalus says "When the RTP stream depen= ds on one or more other RTP streams (in this case MST is in use), this para= meter MUST be present and the value MUST be greater than 0=94. I don=92t t= hink this is sufficient =97 I think the depended-on stream must have sprop-= depack-buf-nalus > 0 as well. Otherwise, you can=92t use the DON values to= determine the total decode order across all the MST streams. 3. If you=92re using MST but aren=92t interested in re-ordering packets at = all, how should sprop-depack-buf-nalus be set? Even 1 would seem to imply = that you're doing single-NALU reordering, forcing extra delay onto the deco= ding process. 4. I think labeling the DON fields =93(optional)=94 in the packet diagrams = is confusing, since depending on the value of sprop-depack-buf-nalus it=92s= either mandatory or forbidden. I think =93(conditional)=94 would be clear= er.= From nobody Wed Mar 5 16:23:44 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFFF1A0004 for ; Wed, 5 Mar 2014 16:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 m7424nv3WZKl for ; Wed, 5 Mar 2014 16:23:38 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id B7A771A0011 for ; Wed, 5 Mar 2014 16:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394065415; x=1425601415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YB8ENXuAv8Q9OtScRnx4JpSouKlEBBp0wFnISoXdFK4=; b=zS3YnOuvzOeonObH6WulZUgfNJWorYuB6N6ebPm+9okcpZ+NIWMi7LaK 9Ki5IUXIavfA0wwrucgw6V75cGK8+iGc8DdKzk5Ydvkt/fMmmYdDY27Rk xVLECUWts/hlNwNy5h2qoH99ek+TkG15mUu8RTEde4WrCTxNBVRvAuIuB s=; X-IronPort-AV: E=McAfee;i="5400,1158,7368"; a="109701095" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 05 Mar 2014 16:23:35 -0800 X-IronPort-AV: E=Sophos;i="4.97,596,1389772800"; d="scan'208";a="604268173" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2014 16:23:34 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 16:23:34 -0800 From: "Wang, Ye-Kui" To: Jonathan Lennox Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQIAAuiiA//+fAJA= Date: Thu, 6 Mar 2014 00:23:33 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> In-Reply-To: <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/7cMUye4RvSQvjzMbTVG3dRtuxFY Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:23:42 -0000 Agree to make the intention clearer, e.g. by adding a note. On your last question: I think you are right, a non-VCL suffix NAL unit, e.= g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_la= yer_id equal to 0, and thus in MST the last NAL unit of an access unit may = actually be carried in the last packet from the "base" RTP stream. And yes = this actually does not matter for using of the marker bit for the purpose d= escribed below.=20 BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Wednesday, March 05, 2014 4:05 PM To: Wang, Ye-Kui Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC This seems correct to me. I would suggest, however, explicitly pointing ou= t that in MST mode, if an access unit appears in multiple packet streams, t= he marker bit is set on each packet stream's last packet of the access unit= . I think this definition works even when DONs are in use (when sprop-depack-= buf-nalus is > 0), since an AP can only contain packets from a single acces= s unit. If packets from different access units are interleaved (in RTP ord= er) using DON, the packet stream will look odd to a naive RTP analysis, but= I believe the marker bit will still be useful, allowing low-delay decoders= to flush complete access units out of the de-packetization buffer early. Ye-Kui, a question about your comment, though: are we sure that the final p= acket of the access unit will in fact always be the final packet of the hig= hest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able to= split MST streams by nuh_layer_id. How will the nuh_layer_id be set for t= railing SEIs in such streams? If it's set to 0, then the final packet of t= he access unit will in fact be sent in a lower layer. I don't think this a= ctually matters, especially since MST streams will use DON, but we should b= e careful about our logic. On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: > I did a bit of search on the usage of the marker bit for video, and the m= ost relevant description I found was the following paragraph in Section 5 o= f RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > So the key usage of the marker bit is that in some low-delay applications= , output/display of a picture can be done before receiving an RTP packet wi= th a different/greater timestamp. Since non-VCL NAL unit should have the sa= me timestamp as the associated picture, thus I think we should not use the = wording of "last VCL NAL unit" in determining the setting of the marker bit= . >=20 > To make the semantics extensible or future-proof for multi-layer extensio= ns, I think we should change it to be RTP stream (or equivalently packet st= ream) specific, and each receiver can just look at the marker bits of the p= ackets from the highest RTP stream for the usage. And this will also resolv= e the issue of requiring some entities to change the marker bit in sub-laye= r scalability usage as Jonaton raised.=20 >=20 > In other words, the normative semantics are to be changed as follows: >=20 > Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling. >=20 > Please let me know if there is any concern with such a change (and note t= hat we would align the terminology of RTP stream with other drafts, e.g. th= e Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing = comments). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui > Sent: Wednesday, March 05, 2014 10:29 AM > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Something should be done to the HEVC spec to make it clearer for the deco= ded picture hash SEI message, like that it shall not be nested and what the= values of LayerId and LId should be, or allow add to the list of nestable = SEI message. In any case, it does not make sense to me to put a greater val= ue of TId than its associated picture. On user_data_registered_itu_t_t35 an= d user_data_unregistered suffix SEI messages, only if it is defined by some= application then it may make sense to put a greater value of TId than its = associated picture - currently I have not seen any such use being defined a= nywhere. >=20 > Anyway, I admitted that the current semantics are not fully future-proof = regarding suffix SEI messages. In looking into future multi-layer extension= s, it appears that simply changing the wording from "last NAL unit" to "las= t VCL NAL unit" is not good enough. We might need to specify the semantics = of the marker bit to be RTP stream specific. To make sure whether such a ch= ange is OK, we also need to check against the usage of the marker bit. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, March 05, 2014 1:07 AM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks for your response Ye-Kui, >=20 > As far as I understand, out of the 6 SEI messages that have so far been d= efined in the HEVC spec as possible to use as suffixes (filler_payload, use= r_data_registered_itu_t_t35, user_data_unregistered, progressive_refinement= _segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that = are not required to have the same TId as the VCL NAL units of the access un= it: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pic= ture_hash since their payloadType numbers (4, 5 and 132) are not included i= n the list: >=20 > "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 1= 6, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages = that have payloadType not equal to 0, 1, or 130, and that are allowed to be= nested SEI messages), the SEI NAL unit containing the non-nested SEI messa= ge shall have TemporalId equal to the TemporalId of the access unit contain= ing the SEI NAL unit." >=20 > Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I= think the problem would exist even if was. An encoder that (for whatever r= eason) puts in user_data_registered_itu_t_t35 or user_data_unregistered suf= fix SEI messages with higher TId would put a MANE in a difficult situation.= =20 >=20 > I also think we should consider future extensions of HEVC (i.e. SHVC and = MV-HEVC) in which an access unit may contain many pictures with different v= alues of nuh_layer_id. If the marker bit is set for the last packet of an a= ccess unit, then once again all the marker bits will end up in the highest = layer (stream) and a MANE would have to change the value of marker bits as = soon as not all layers (streams) are forwarded. >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 5 mars 2014 01:20 > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hmm, a decoded picture hash SEI message applies to (and is associated wit= h) the preceding decoding picture in decoding order and thus the TId of the= containing suffix SEI NAL unit should be set equal to the TId of the assoc= iated picture. Thus in the example, for the suffix SEI NAL unit containing = the decoded picture hash SEI message for the first encoded picture should b= e assigned TId equal to 0.=20 >=20 > According to the HEVC spec, currently the following SEI messages are or c= an be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, = user_data_unregistered, progressive_refinement_segment_end, post_filter_hin= t, and decoded_picture_hash. Among these, I think all of the "specified" SE= I messages (i.e. the above list excluding user_data_registered_itu_t_t35, u= ser_data_unregistered) contained in a suffix SEI NAL unit would apply to th= e preceding decoded picture in decoder order and should have the same TId a= s the associated picture. The only SEI messages that can have a greater TId= value than the containing access unit are the three SEI message that can c= arry HRD information, i.e., buffering_period, pic_timing, and decoding_unit= _info, but these can only be prefix SEI messages. >=20 > Of course, in theory, future versions of HEVC or some extensions (even de= fined by an application spec) could define suffix SEI messages that can hav= e a greater TId value than the containing access unit. In that case, what y= ou described could be meaningful, and indeed if a receiver receives the "ba= se sub-layer" stream, some entity would have to set the marker bit of those= packets containing the last NAL unit of an access unit for that stream, ac= cording to the current semantics. >=20 > However, if we change the wording to the last VCL NAL unit as you suggest= ed, and in case a suffix SEI NAL unit of picture A is not carried the packe= t containing the last VCL NAL unit if the access unit, would the usage of t= he marker bit be affected, e.g. in playout buffer handling? If the answer i= s no, then there should be no problem to do the change. >=20 > Basically the situation is as follows. There is no concrete problem now. = However, there can be a potential problem in the future if a suffix SEI mes= sage is defined and can have a greater TId value than the containing access= unit. If the suggested change does not affect the usage of the bit, we sho= uld do the change now to make the design future-proof. So the key question = is whether the suggest change would affect the usage of the bit.=20 >=20 > Does anyone know how the marker bit is used in playout buffering handling= ? An explanation or a pointer would be greatly appreciated. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Tuesday, March 04, 2014 1:28 PM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Dear Ye-Kui, >=20 > Let me try to make the example more specific (and then also see if I have= understood the multi-stream transmission concept correctly). >=20 > Assume that the sender puts all NAL units with TId 0 in one RTP stream (s= tream A) and all NAL units with TId 1 in another RTP stream (stream B). Now= for the first encoded picture the VCL NAL units are assigned TId 0 and the= n a decoded picture hash SEI message is created in the same access unit but= is given TId 1. Then the marker bit will be set on the packet containing t= he decoded picture hash SEI message which is put in stream B. If this schem= e is applied for all access units, stream A will not contain any packets wi= th the marker bit set since these are all put in stream B. A MANE that only= wants to forward stream A to a receiver would be required to perform analy= sis (and probably introduce delay) in order to correctly change the marker = bit on the "new" last packet of the access unit. >=20 > Is that correct, or have I misinterpreted anything? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 4 mars 2014 18:21 > To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; st= ewe@stewe.org; Jonatan Samuelsson > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hi Jonatan, >=20 > I do not fully understand the following example: >=20 > "However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units).= For that case I guess there will be one RTP stream (corresponding to TId 0= ) completely without any marker bit set, right?" >=20 > Could you please check whether it can be clarified a bit? >=20 > BR, YK >=20 > -----Original Message----- > From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 > Sent: Monday, March 03, 2014 2:11 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe= .org; jonatan.samuelsson@ericsson.com > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > #10: Marker bit in H.265/HEVC >=20 >=20 > Comment (by jonatan.samuelsson@ericsson.com): >=20 > Thanks Stefan for the comments and the example. It is exactly this kind o= f cases I'm concerned about but I wouldn't characterize them as exotic. Fo= r conversational applications it is natural to operate in *very* low delay= mode (i.e. not buffering packets before forwarding them) and having post-= picture SEI packetized in their own packets is the only option as soon as= the VCL NAL units are fragmented since FUs cannot be aggregated. Having t= o introduce slices just to avoid FUs and thereby being able to aggregate S= EI messages with VCL NAL units does not sound like a compelling alternativ= e. >=20 > The most reasonable solution for this case is probably to just not perfor= m thinning by removing the SEI messages since they are typically not very = large in the first place. >=20 > However, as far as I understand, it is allowed for an encoder to create a= bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). > For that case I guess there will be one RTP stream (corresponding to TId > 0) completely without any marker bit set, right? >=20 > --=20 > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Wed Mar 5 16:56:04 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694711A0033 for ; Wed, 5 Mar 2014 16:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 0BbUpq6Oaly9 for ; Wed, 5 Mar 2014 16:56:01 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id AD7A41A0010 for ; Wed, 5 Mar 2014 16:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394067358; x=1425603358; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3wX061/E/HxqI9v6fdrZ0n2k3axdW+NkR/pk8miDF1E=; b=DTV4PK4Np9AEA8xM2jgcMclBBtvfe2MXedOyoNP6z+o7H3ZjcHOKvOUx o8LYaljt+NBVWJM74QLfu+dqOEUd7yPRo0MF6xiQ+yA0i8xGroSZAgzjC 6eJBV5DjSvLOdOpAx6K1LbivwsdzdxZ2ONRd42JgumCi2KEs9KqR8HtU7 g=; X-IronPort-AV: E=McAfee;i="5400,1158,7368"; a="60146394" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 05 Mar 2014 16:55:57 -0800 X-IronPort-AV: E=Sophos;i="4.97,596,1389772800"; d="scan'208";a="628124218" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Mar 2014 16:55:57 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 16:55:57 -0800 From: "Wang, Ye-Kui" To: Jonathan Lennox , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: A few questions about DON in the H.265 payload Thread-Index: AQHPONGMMPGmnatbJkuiS2/WscfY4ZrTNdPw Date: Thu, 6 Mar 2014 00:55:56 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D8794@nasanexd02f.na.qualcomm.com> References: <8A37BB2C-70A2-46FD-832D-EFA82F4A98A7@vidyo.com> In-Reply-To: <8A37BB2C-70A2-46FD-832D-EFA82F4A98A7@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Biia-t8_2EFg_JbnPgKw25Y4iV4 Subject: Re: [payload] A few questions about DON in the H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:56:03 -0000 Thanks Jonathan for the comments. See my responses inline below. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonathan Lenno= x Sent: Wednesday, March 05, 2014 4:18 PM To: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: [payload] A few questions about DON in the H.265 payload When reading over the H.265 payload spec to understand DON and marker bits,= I realized I had a few questions/comments about DON. 1. DON values are not required to be consecutive. How does this interact w= ith sprop-depack-buf-nalus? If, as a receiver, I'm decoding a stream with s= prop-depack-buf-nalus =3D=3D 2, and I receive a packet with DON 1 and then = one with DON 3, may I immediately release the packet with DON 1 to the deco= der? [YK]: You just count the number of NAL units buffered to check against the = value of sprop-depack-buf-nalus, while the DON values are used to pick whic= h of the buffered NAL units to be first output. This is the answer to your = first question. And consequently, the answer is yes to your second question= .=20 2. The definition of sprop-depack-buf-nalus says "When the RTP stream depen= ds on one or more other RTP streams (in this case MST is in use), this para= meter MUST be present and the value MUST be greater than 0". I don't think= this is sufficient - I think the depended-on stream must have sprop-depack= -buf-nalus > 0 as well. Otherwise, you can't use the DON values to determi= ne the total decode order across all the MST streams. [YK]: Let us use an example. Assume we have two RTP streams carrying the bi= tstream, the base (i.e. the depended-on) stream s1 and the stream s2 that = depends on s1. The value of sprop-depack-buf-nalus signalled for the stream= s2 indicates the buffer size needed for de-packetizing both streams s1 and= s2, not just s2 - you don't de-packetize a stream itself that depends on a= nother stream. Furthermore, if the stream s1 is not interleaved (i.e. trans= mission order =3D decoding order), then the value of sprop-depack-buf-nalus= signalled for the stream s1 can be set to 0 as this parameter only specifi= es the buffer size needed for de-packetization only when the stream s1 is r= eceived. 3. If you're using MST but aren't interested in re-ordering packets at all,= how should sprop-depack-buf-nalus be set? Even 1 would seem to imply that= you're doing single-NALU reordering, forcing extra delay onto the decoding= process. [YK]: In MST, some reordering of NAL units across RTP streams is always nee= ded. For example, if there is no interleaving within each of the RTP stream= s, then the value of sprop-depack-buf-nalus needs to be set to be equal to = or greater than the minimum value that is sufficient for handling the inter= -stream jitter, which can be caused by e.g. the first packet of the highest= RTP stream actually comes before the first packet of a "lower" RTP stream.= Or are you saying that it should be assumed that the NAL units always flow= into the de-packetization buffer in the stream-dependency order (low to hi= gh)? 4. I think labeling the DON fields "(optional)" in the packet diagrams is c= onfusing, since depending on the value of sprop-depack-buf-nalus it's eithe= r mandatory or forbidden. I think "(conditional)" would be clearer. [YK]: Agreed. Magnus made the same comment earlier. From nobody Wed Mar 5 17:28:38 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A201A0011 for ; Wed, 5 Mar 2014 17:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 9lx_JsGkp4_a for ; Wed, 5 Mar 2014 17:28:32 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id 88BF71A0031 for ; Wed, 5 Mar 2014 17:28:32 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/5/2014 8:28:27 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-90/SG:2 3/5/2014 8:27:50 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.916287 p=-0.984596 Source White X-Signature-Violations: 0-0-0-11861-c X-Note-419: 15.6005 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 3/5/2014 8:28:19 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 103623935; Wed, 05 Mar 2014 20:28:27 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 19:28:26 -0600 From: Jonathan Lennox To: "Wang, Ye-Kui" Thread-Topic: A few questions about DON in the H.265 payload Thread-Index: AQHPONGMMPGmnatbJkuiS2/WscfY4ZrTNdPwgABz24A= Date: Thu, 6 Mar 2014 01:28:25 +0000 Message-ID: <182A527B-0EFF-4A5E-99BF-9CB47EB6CD03@vidyo.com> References: <8A37BB2C-70A2-46FD-832D-EFA82F4A98A7@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8794@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D8794@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.3.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7ECC95D943DB404BBE6AB3C8D9C0F188@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/4LbQ9qU-F86u8Q8ugDU-NqjVm3M Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] A few questions about DON in the H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:28:35 -0000 On Mar 6, 2014, at 12:55 AM, Wang, Ye-Kui wrote: > Thanks Jonathan for the comments. See my responses inline below. Mine are inline as well. >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonathan Len= nox > Sent: Wednesday, March 05, 2014 4:18 PM > To: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org > Subject: [payload] A few questions about DON in the H.265 payload >=20 > When reading over the H.265 payload spec to understand DON and marker bit= s, I realized I had a few questions/comments about DON. >=20 > 1. DON values are not required to be consecutive. How does this interact= with sprop-depack-buf-nalus? If, as a receiver, I'm decoding a stream with= sprop-depack-buf-nalus =3D=3D 2, and I receive a packet with DON 1 and the= n one with DON 3, may I immediately release the packet with DON 1 to the de= coder? >=20 > [YK]: You just count the number of NAL units buffered to check against th= e value of sprop-depack-buf-nalus, while the DON values are used to pick wh= ich of the buffered NAL units to be first output. This is the answer to you= r first question. And consequently, the answer is yes to your second questi= on.=20 This doesn=92t follow. In this example, there are 2 buffered NAL units, wh= ich is <=3D sprop-depack-buf-nalus=3D2. Or have I mis-read the algorithm? To make this more explicit (so we don=92t have to worry about < vs. <=3D ca= ses), let=92s say that my sprop-depack-buf-nalus=3D=3D10, and I receive two= packets: one with DON=3D1, and then one with DON=3D30. These are the only= two packets I have ever received. Can I decode the packet with DON=3D1? On the current language of the spec, the answer would be no =97 I have to w= ait for eight more NALUs to arrive. (Unless I=92ve mis-read the spec.) I argue that a different definition of sprop-depack-buf-nalus, such that I = could, would be more useful =97 that I can safely decode any packet whose D= ON value is <=3D (highest DON received) - (sprop-depack-buf-nalus). This s= afely handles scenarios of packet loss and non-consecutive DON values. Doe= s it break any uses of DON? > 2. The definition of sprop-depack-buf-nalus says "When the RTP stream dep= ends on one or more other RTP streams (in this case MST is in use), this pa= rameter MUST be present and the value MUST be greater than 0". I don't thi= nk this is sufficient - I think the depended-on stream must have sprop-depa= ck-buf-nalus > 0 as well. Otherwise, you can't use the DON values to deter= mine the total decode order across all the MST streams. >=20 > [YK]: Let us use an example. Assume we have two RTP streams carrying the = bitstream, the base (i.e. the depended-on) stream s1 and the stream s2 tha= t depends on s1. The value of sprop-depack-buf-nalus signalled for the stre= am s2 indicates the buffer size needed for de-packetizing both streams s1 a= nd s2, not just s2 - you don't de-packetize a stream itself that depends on= another stream. Furthermore, if the stream s1 is not interleaved (i.e. tra= nsmission order =3D decoding order), then the value of sprop-depack-buf-nal= us signalled for the stream s1 can be set to 0 as this parameter only speci= fies the buffer size needed for de-packetization only when the stream s1 is= received. But how do I determine the relative placement of the NALUs of the base and = dependent streams, without DON values in the base stream? Consider for ins= tance the example we had in our previous e-mail exchange, where an (SHVC) a= ccess unit consists of base VCL NAL units in stream 0, then enhancement VCL= NAL units in stream 1, and then a trailing SEI in stream 0. With DON it= =92s easy to communicate the total order of the NALUs, but if stream 0 does= n=92t have DON values I don=92t see how a receiver can reconstruct that. I think my point is that there may need to be some set of parameters that i= ndicates that a base packet stream carries DON values in its packets, even = though its sprop-depack-buf-nalus value is 0. Since this stream isn=92t in= terleaved, these DONs would only be used for MST reconstruction, and would = not be useful for the stream on its own. > 3. If you're using MST but aren't interested in re-ordering packets at al= l, how should sprop-depack-buf-nalus be set? Even 1 would seem to imply th= at you're doing single-NALU reordering, forcing extra delay onto the decodi= ng process. >=20 > [YK]: In MST, some reordering of NAL units across RTP streams is always n= eeded. For example, if there is no interleaving within each of the RTP stre= ams, then the value of sprop-depack-buf-nalus needs to be set to be equal t= o or greater than the minimum value that is sufficient for handling the int= er-stream jitter, which can be caused by e.g. the first packet of the highe= st RTP stream actually comes before the first packet of a "lower" RTP strea= m. Or are you saying that it should be assumed that the NAL units always fl= ow into the de-packetization buffer in the stream-dependency order (low to = high)? You can=92t assume that the sender knows how big the inter-stream jitter is= , or the relative path delay of the MST streams. These are network charact= eristics beyond its visibility, and need to be handled =93upstream=94 of th= e H.265 decoding process just like standard intra-stream jitter is. Thus, = I was assuming dejittering and alignment had already been handled by the ti= me packets were to be put into the de-packetization buffer. I suppose I was thinking about putting packets into the buffer in stream-de= pendency order, or something like it, though I hadn=92t thought through the= details very clearly. But I=92m certainly thinking of a model where there= =92s no interleaving *within* any given stream.= From nobody Thu Mar 6 02:59:01 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD21A01FC for ; Thu, 6 Mar 2014 02:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ZoSu_hNks41U for ; Thu, 6 Mar 2014 02:58:56 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB181A0274 for ; Thu, 6 Mar 2014 02:58:55 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-37-531854ebfa4f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 91.D1.23809.BE458135; Thu, 6 Mar 2014 11:58:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 11:58:50 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , Jonathan Lennox Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPMkf2CFY3DR2ikEyoFpWG3Tj1ZprP5Z+AgAFBKICAAE+AEIAAJbcAgACZfjCAAJawAIAADokAgABPWgCAAAU6gIAArnFg Date: Thu, 6 Mar 2014 10:58:49 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje7rEIlgg19LxC1OXdzHarF/8Xlm i0sXzzJZXG/cxG6xZPJNZosna44xO7B5vOjex+6xZMlPJo9FU58xeixe/57R48vlz2webc/u sAewRXHZpKTmZJalFunbJXBlXFq6g6lgVS9jxepLe5gbGC8UdjFycEgImEh8vVLZxcgJZIpJ XLi3nq2LkYtDSOAQo0TD/y2MEM5iRokdZ6eygDSwCVhJfH8RAdIgIhAi8f1eAwtIDbPAK0aJ Bau3sYEkhAXsJe7d/8EIUeQgcXrqemYIO0/i6adWdpA5LAIqEis7LUHCvALeEh1fN7FC7FrO KjH/yywmkASnQLBE5+4msF5GAVmJ+9/vsYDYzALiEreezGeCuFpAYsme88wQtqjEy8f/WCFs RYmr05czQdTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFSN7 bmJmTnq50SZGYNQd3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTI xMEp1cDYX8+hL2SxZQ/XYaMNJQ68PhFvROZ+XXrhcpmfpIrEV7PuDvXIh6r7Pfd+NYssmyrw bN7BrydnVokLVwfIXtD+PG9rRxV7WfHZgEr1VUq3WZ/n9m+aFndWdv3HqaeUVu5rDPmSo+C3 8frbB/rsvY63m197/S6dd01/o/XHed735q9YeOGbuL67EktxRqKhFnNRcSIA8gx7GYgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/XpYqtBzFotciZBK3CpEN1XYgYHE Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:58:59 -0000 Thanks Ye-Kui and Jonathan for your responses. Regarding Section 5 of RFC 3551: Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed. I don't think this text is really up to date with HEVC in the sense that th= e actual video frame (which in my opinion, for the HEVC case, is the VCL NA= L units of an access unit) can be completely received even though there are= more packet(s) that are following with the same time stamp. Since none of the suffix SEI messages has any normative effect on the outpu= t of the decoder, why should it be necessary to wait for example for a deco= ded_picture_hash SEI before detecting that a frame can be displayed? Ye-Kui, you earlier wrote: "Anyway, I admitted that the current semantics are not fully future-proof r= egarding suffix SEI messages. In looking into future multi-layer extensions= , it appears that simply changing the wording from "last NAL unit" to "last= VCL NAL unit" is not good enough." But if (as I initially suggested) the change is from "last NAL unit of an a= ccess unit" to "last VCL NAL unit of a picture" I guess it could work also = for future extensions in which there will be several pictures in the same a= ccess unit. Or do you see a problem here? Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 6 mars 2014 01:24 To: Jonathan Lennox Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Agree to make the intention clearer, e.g. by adding a note. On your last question: I think you are right, a non-VCL suffix NAL unit, e.= g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_la= yer_id equal to 0, and thus in MST the last NAL unit of an access unit may = actually be carried in the last packet from the "base" RTP stream. And yes = this actually does not matter for using of the marker bit for the purpose d= escribed below.=20 BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Wednesday, March 05, 2014 4:05 PM To: Wang, Ye-Kui Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC This seems correct to me. I would suggest, however, explicitly pointing ou= t that in MST mode, if an access unit appears in multiple packet streams, t= he marker bit is set on each packet stream's last packet of the access unit= . I think this definition works even when DONs are in use (when sprop-depack-= buf-nalus is > 0), since an AP can only contain packets from a single acces= s unit. If packets from different access units are interleaved (in RTP ord= er) using DON, the packet stream will look odd to a naive RTP analysis, but= I believe the marker bit will still be useful, allowing low-delay decoders= to flush complete access units out of the de-packetization buffer early. Ye-Kui, a question about your comment, though: are we sure that the final p= acket of the access unit will in fact always be the final packet of the hig= hest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able to= split MST streams by nuh_layer_id. How will the nuh_layer_id be set for t= railing SEIs in such streams? If it's set to 0, then the final packet of t= he access unit will in fact be sent in a lower layer. I don't think this a= ctually matters, especially since MST streams will use DON, but we should b= e careful about our logic. On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: > I did a bit of search on the usage of the marker bit for video, and the m= ost relevant description I found was the following paragraph in Section 5 o= f RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > So the key usage of the marker bit is that in some low-delay applications= , output/display of a picture can be done before receiving an RTP packet wi= th a different/greater timestamp. Since non-VCL NAL unit should have the sa= me timestamp as the associated picture, thus I think we should not use the = wording of "last VCL NAL unit" in determining the setting of the marker bit= . >=20 > To make the semantics extensible or future-proof for multi-layer extensio= ns, I think we should change it to be RTP stream (or equivalently packet st= ream) specific, and each receiver can just look at the marker bits of the p= ackets from the highest RTP stream for the usage. And this will also resolv= e the issue of requiring some entities to change the marker bit in sub-laye= r scalability usage as Jonaton raised.=20 >=20 > In other words, the normative semantics are to be changed as follows: >=20 > Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling. >=20 > Please let me know if there is any concern with such a change (and note t= hat we would align the terminology of RTP stream with other drafts, e.g. th= e Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing = comments). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui > Sent: Wednesday, March 05, 2014 10:29 AM > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Something should be done to the HEVC spec to make it clearer for the deco= ded picture hash SEI message, like that it shall not be nested and what the= values of LayerId and LId should be, or allow add to the list of nestable = SEI message. In any case, it does not make sense to me to put a greater val= ue of TId than its associated picture. On user_data_registered_itu_t_t35 an= d user_data_unregistered suffix SEI messages, only if it is defined by some= application then it may make sense to put a greater value of TId than its = associated picture - currently I have not seen any such use being defined a= nywhere. >=20 > Anyway, I admitted that the current semantics are not fully future-proof = regarding suffix SEI messages. In looking into future multi-layer extension= s, it appears that simply changing the wording from "last NAL unit" to "las= t VCL NAL unit" is not good enough. We might need to specify the semantics = of the marker bit to be RTP stream specific. To make sure whether such a ch= ange is OK, we also need to check against the usage of the marker bit. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, March 05, 2014 1:07 AM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks for your response Ye-Kui, >=20 > As far as I understand, out of the 6 SEI messages that have so far been d= efined in the HEVC spec as possible to use as suffixes (filler_payload, use= r_data_registered_itu_t_t35, user_data_unregistered, progressive_refinement= _segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that = are not required to have the same TId as the VCL NAL units of the access un= it: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pic= ture_hash since their payloadType numbers (4, 5 and 132) are not included i= n the list: >=20 > "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 1= 6, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages = that have payloadType not equal to 0, 1, or 130, and that are allowed to be= nested SEI messages), the SEI NAL unit containing the non-nested SEI messa= ge shall have TemporalId equal to the TemporalId of the access unit contain= ing the SEI NAL unit." >=20 > Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I= think the problem would exist even if was. An encoder that (for whatever r= eason) puts in user_data_registered_itu_t_t35 or user_data_unregistered suf= fix SEI messages with higher TId would put a MANE in a difficult situation.= =20 >=20 > I also think we should consider future extensions of HEVC (i.e. SHVC and = MV-HEVC) in which an access unit may contain many pictures with different v= alues of nuh_layer_id. If the marker bit is set for the last packet of an a= ccess unit, then once again all the marker bits will end up in the highest = layer (stream) and a MANE would have to change the value of marker bits as = soon as not all layers (streams) are forwarded. >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 5 mars 2014 01:20 > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hmm, a decoded picture hash SEI message applies to (and is associated wit= h) the preceding decoding picture in decoding order and thus the TId of the= containing suffix SEI NAL unit should be set equal to the TId of the assoc= iated picture. Thus in the example, for the suffix SEI NAL unit containing = the decoded picture hash SEI message for the first encoded picture should b= e assigned TId equal to 0.=20 >=20 > According to the HEVC spec, currently the following SEI messages are or c= an be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, = user_data_unregistered, progressive_refinement_segment_end, post_filter_hin= t, and decoded_picture_hash. Among these, I think all of the "specified" SE= I messages (i.e. the above list excluding user_data_registered_itu_t_t35, u= ser_data_unregistered) contained in a suffix SEI NAL unit would apply to th= e preceding decoded picture in decoder order and should have the same TId a= s the associated picture. The only SEI messages that can have a greater TId= value than the containing access unit are the three SEI message that can c= arry HRD information, i.e., buffering_period, pic_timing, and decoding_unit= _info, but these can only be prefix SEI messages. >=20 > Of course, in theory, future versions of HEVC or some extensions (even de= fined by an application spec) could define suffix SEI messages that can hav= e a greater TId value than the containing access unit. In that case, what y= ou described could be meaningful, and indeed if a receiver receives the "ba= se sub-layer" stream, some entity would have to set the marker bit of those= packets containing the last NAL unit of an access unit for that stream, ac= cording to the current semantics. >=20 > However, if we change the wording to the last VCL NAL unit as you suggest= ed, and in case a suffix SEI NAL unit of picture A is not carried the packe= t containing the last VCL NAL unit if the access unit, would the usage of t= he marker bit be affected, e.g. in playout buffer handling? If the answer i= s no, then there should be no problem to do the change. >=20 > Basically the situation is as follows. There is no concrete problem now. = However, there can be a potential problem in the future if a suffix SEI mes= sage is defined and can have a greater TId value than the containing access= unit. If the suggested change does not affect the usage of the bit, we sho= uld do the change now to make the design future-proof. So the key question = is whether the suggest change would affect the usage of the bit.=20 >=20 > Does anyone know how the marker bit is used in playout buffering handling= ? An explanation or a pointer would be greatly appreciated. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Tuesday, March 04, 2014 1:28 PM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Dear Ye-Kui, >=20 > Let me try to make the example more specific (and then also see if I have= understood the multi-stream transmission concept correctly). >=20 > Assume that the sender puts all NAL units with TId 0 in one RTP stream (s= tream A) and all NAL units with TId 1 in another RTP stream (stream B). Now= for the first encoded picture the VCL NAL units are assigned TId 0 and the= n a decoded picture hash SEI message is created in the same access unit but= is given TId 1. Then the marker bit will be set on the packet containing t= he decoded picture hash SEI message which is put in stream B. If this schem= e is applied for all access units, stream A will not contain any packets wi= th the marker bit set since these are all put in stream B. A MANE that only= wants to forward stream A to a receiver would be required to perform analy= sis (and probably introduce delay) in order to correctly change the marker = bit on the "new" last packet of the access unit. >=20 > Is that correct, or have I misinterpreted anything? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 4 mars 2014 18:21 > To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; st= ewe@stewe.org; Jonatan Samuelsson > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hi Jonatan, >=20 > I do not fully understand the following example: >=20 > "However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units).= For that case I guess there will be one RTP stream (corresponding to TId 0= ) completely without any marker bit set, right?" >=20 > Could you please check whether it can be clarified a bit? >=20 > BR, YK >=20 > -----Original Message----- > From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 > Sent: Monday, March 03, 2014 2:11 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe= .org; jonatan.samuelsson@ericsson.com > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > #10: Marker bit in H.265/HEVC >=20 >=20 > Comment (by jonatan.samuelsson@ericsson.com): >=20 > Thanks Stefan for the comments and the example. It is exactly this kind o= f cases I'm concerned about but I wouldn't characterize them as exotic. Fo= r conversational applications it is natural to operate in *very* low delay= mode (i.e. not buffering packets before forwarding them) and having post-= picture SEI packetized in their own packets is the only option as soon as= the VCL NAL units are fragmented since FUs cannot be aggregated. Having t= o introduce slices just to avoid FUs and thereby being able to aggregate S= EI messages with VCL NAL units does not sound like a compelling alternativ= e. >=20 > The most reasonable solution for this case is probably to just not perfor= m thinning by removing the SEI messages since they are typically not very = large in the first place. >=20 > However, as far as I understand, it is allowed for an encoder to create a= bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). > For that case I guess there will be one RTP stream (corresponding to TId > 0) completely without any marker bit set, right? >=20 > --=20 > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Thu Mar 6 13:40:41 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8FC1A00AF for ; Thu, 6 Mar 2014 13:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 CNh_Ep1uxYDM for ; Thu, 6 Mar 2014 13:40:38 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 50A391A0068 for ; Thu, 6 Mar 2014 13:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394142034; x=1425678034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+4dhAknJ9Fhw63vGculB8Uvs/PmGQBiMidhcCLLg7Zk=; b=XxYF1qRdPpIxwuJHqIsykp3wWlTunORjPKLCWBHCwM1NyTT4zCD1PKIb 1dXt88Rht/gIY1M/jPDl1btn/DMmxNluLJsKvIGNjJ6upw6ULurUdsFET 9UeW1r2GNFEASbqjNMsE++Bj1Vw2VnR7fmT93uHLc8vOBJ2qvTazJyNNd E=; X-IronPort-AV: E=McAfee;i="5400,1158,7369"; a="109991043" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 06 Mar 2014 13:40:34 -0800 X-IronPort-AV: E=Sophos;i="4.97,603,1389772800"; d="scan'208";a="628612337" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Mar 2014 13:40:17 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 13:39:04 -0800 From: "Wang, Ye-Kui" To: Jonathan Lennox Thread-Topic: A few questions about DON in the H.265 payload Thread-Index: AQHPONGMMPGmnatbJkuiS2/WscfY4ZrTNdPwgABz24CAAOeEEA== Date: Thu, 6 Mar 2014 21:39:03 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D9517@nasanexd02f.na.qualcomm.com> References: <8A37BB2C-70A2-46FD-832D-EFA82F4A98A7@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8794@nasanexd02f.na.qualcomm.com> <182A527B-0EFF-4A5E-99BF-9CB47EB6CD03@vidyo.com> In-Reply-To: <182A527B-0EFF-4A5E-99BF-9CB47EB6CD03@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/cygsPwGm9bHWlTPWlvasyAYMPTk Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] A few questions about DON in the H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:40:41 -0000 Further response inline below. I removed the overheads. > 1. DON values are not required to be consecutive. How does this interact= with sprop-depack-buf-nalus? If, as a receiver, I'm decoding a stream with= sprop-depack-buf-nalus =3D=3D 2, and I receive a packet with DON 1 and the= n one with DON 3, may I immediately release the packet with DON 1 to the de= coder? >=20 > [YK]: You just count the number of NAL units buffered to check against th= e value of sprop-depack-buf-nalus, while the DON values are used to pick wh= ich of the buffered NAL units to be first output. This is the answer to you= r first question. And consequently, the answer is yes to your second questi= on.=20 This doesn't follow. In this example, there are 2 buffered NAL units, whic= h is <=3D sprop-depack-buf-nalus=3D2. Or have I mis-read the algorithm? To make this more explicit (so we don't have to worry about < vs. <=3D case= s), let's say that my sprop-depack-buf-nalus=3D=3D10, and I receive two pac= kets: one with DON=3D1, and then one with DON=3D30. These are the only two= packets I have ever received. Can I decode the packet with DON=3D1? On the current language of the spec, the answer would be no - I have to wai= t for eight more NALUs to arrive. (Unless I've mis-read the spec.) [YK]: You have the same understanding as me. I argue that a different definition of sprop-depack-buf-nalus, such that I = could, would be more useful - that I can safely decode any packet whose DON= value is <=3D (highest DON received) - (sprop-depack-buf-nalus). This saf= ely handles scenarios of packet loss and non-consecutive DON values. Does = it break any uses of DON? [YK]: I see your point. If there is no gap in DON values, no sharing of DON= values (multiple NAL units having the same DON), and no packet loss, the = behavior is the same. I need to think a bit whether your suggestion (exactl= y as described above) work with cases when there are gaps in DON values or = when there are sharing of DON values. However, the general idea of improvin= g the algorithm to make it more friendly to packet losses is good. So let's= study this a bit more. > 2. The definition of sprop-depack-buf-nalus says "When the RTP stream dep= ends on one or more other RTP streams (in this case MST is in use), this pa= rameter MUST be present and the value MUST be greater than 0". I don't thi= nk this is sufficient - I think the depended-on stream must have sprop-depa= ck-buf-nalus > 0 as well. Otherwise, you can't use the DON values to deter= mine the total decode order across all the MST streams. >=20 > [YK]: Let us use an example. Assume we have two RTP streams carrying the = bitstream, the base (i.e. the depended-on) stream s1 and the stream s2 tha= t depends on s1. The value of sprop-depack-buf-nalus signalled for the stre= am s2 indicates the buffer size needed for de-packetizing both streams s1 a= nd s2, not just s2 - you don't de-packetize a stream itself that depends on= another stream. Furthermore, if the stream s1 is not interleaved (i.e. tra= nsmission order =3D decoding order), then the value of sprop-depack-buf-nal= us signalled for the stream s1 can be set to 0 as this parameter only speci= fies the buffer size needed for de-packetization only when the stream s1 is= received. But how do I determine the relative placement of the NALUs of the base and = dependent streams, without DON values in the base stream? Consider for ins= tance the example we had in our previous e-mail exchange, where an (SHVC) a= ccess unit consists of base VCL NAL units in stream 0, then enhancement VCL= NAL units in stream 1, and then a trailing SEI in stream 0. With DON it's= easy to communicate the total order of the NALUs, but if stream 0 doesn't = have DON values I don't see how a receiver can reconstruct that. I think my point is that there may need to be some set of parameters that i= ndicates that a base packet stream carries DON values in its packets, even = though its sprop-depack-buf-nalus value is 0. Since this stream isn't inte= rleaved, these DONs would only be used for MST reconstruction, and would no= t be useful for the stream on its own. [YK]: Good point - I got you. Originally we had a parameter tx-mode that is= used together with sprop-depack-buf-nalus > 0 to determine the existence o= f some DON related fields. During a discussion with Bernard on the usefulne= ss of tx-mode I incorrectly agreed that tx-mode was not useful. Actually tx= -mode would be useful to enable non-interleaved base stream with sprop-depa= ck-buf-nalus equal to 0. I'd suggest that we revoke that change for this is= sue, unless there is a better suggestion. > 3. If you're using MST but aren't interested in re-ordering packets at al= l, how should sprop-depack-buf-nalus be set? Even 1 would seem to imply th= at you're doing single-NALU reordering, forcing extra delay onto the decodi= ng process. >=20 > [YK]: In MST, some reordering of NAL units across RTP streams is always n= eeded. For example, if there is no interleaving within each of the RTP stre= ams, then the value of sprop-depack-buf-nalus needs to be set to be equal t= o or greater than the minimum value that is sufficient for handling the int= er-stream jitter, which can be caused by e.g. the first packet of the highe= st RTP stream actually comes before the first packet of a "lower" RTP strea= m. Or are you saying that it should be assumed that the NAL units always fl= ow into the de-packetization buffer in the stream-dependency order (low to = high)? You can't assume that the sender knows how big the inter-stream jitter is, = or the relative path delay of the MST streams. These are network character= istics beyond its visibility, and need to be handled "upstream" of the H.26= 5 decoding process just like standard intra-stream jitter is. Thus, I was = assuming dejittering and alignment had already been handled by the time pac= kets were to be put into the de-packetization buffer. I suppose I was thinking about putting packets into the buffer in stream-de= pendency order, or something like it, though I hadn't thought through the d= etails very clearly. But I'm certainly thinking of a model where there's n= o interleaving *within* any given stream. [YK]: You know currently intra-stream jitter was assumed to be handled sepa= rately, not part of the de-packetization process. I think you are right tha= t the handling of inter-stream jitter should also be handled similarly (sep= arately, not part of the de-packetization process). Therefore, we should ch= ange the process to enable sprop-depack-buf-nalus to be equal to 0 for any = stream as long as no interleaving is used within or across the stream and a= ll the streams it depends.=20 BR, YK From nobody Thu Mar 6 13:52:13 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE321A00BB for ; Thu, 6 Mar 2014 13:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 nxcKfSvaiWac for ; Thu, 6 Mar 2014 13:52:08 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 430091A00AF for ; Thu, 6 Mar 2014 13:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394142724; x=1425678724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LqTjrdRDP8SofRTUZ//EV7SN0C4GUboxWocAnnTeXj8=; b=icV+u1ayV9h1oWgQeR8/tzYR2BTWXYmd8/uFZct4DPFF622G8zo6cojS byx+UIp9jnCZ30KqqEWDgsJSlveMNDcaJMD63QVB3BUIlXuEo/vR5bLcU nCKKosRqkBduUyWaSxoel2dgG0VMG8RWVRj6KJx9ijVkIkApDaZ3U/P4F c=; X-IronPort-AV: E=McAfee;i="5400,1158,7369"; a="109993314" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 06 Mar 2014 13:52:04 -0800 X-IronPort-AV: E=Sophos;i="4.97,603,1389772800"; d="scan'208";a="628617261" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Mar 2014 13:52:04 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc15.na.qualcomm.com ([129.46.52.215]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 13:52:03 -0800 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , Jonathan Lennox Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQIAAuiiA//+fAJCAATlBgIAALTag Date: Thu, 6 Mar 2014 21:52:02 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/gnnW5pSM4P5zwvlKNmzN-0FGiuY Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 21:52:11 -0000 [Jonatan]: I don't think this text is really up to date with HEVC in the se= nse that the actual video frame (which in my opinion, for the HEVC case, is= the VCL NAL units of an access unit) can be completely received even thoug= h there are more packet(s) that are following with the same time stamp. I don't understand the above sentence. I think the receiver can only conclu= de that an access unit is completely received only when no more packets wit= h the same timestamp is coming soon. For other parts of your new message below: Any data, including non-VCL data= , associated with a picture in the bitstream is supposed to be used by the = decoder side (not just the decoder) to do something that can be helpful in = processing (decoding including error concealment and so on, display, etc.) = of the decoded picture, even not needed for NORMATIVE decoding of the pictu= re. Thus, only when the decoder side receives all data associated with a pi= cture, can it be sure that no more useful information may come before sent = the decoded picture to the display. Therefore, we should not change the wor= ding from "the last NAL unit" to "the last VCL NAL unit". Also, without mak= ing the setting to be stream specific, as I suggested and Jonathan agreed, = multi-layer extensions will be problematic. BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 Sent: Thursday, March 06, 2014 2:59 AM To: Wang, Ye-Kui; Jonathan Lennox Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; Step= han Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thanks Ye-Kui and Jonathan for your responses. Regarding Section 5 of RFC 3551: Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed. I don't think this text is really up to date with HEVC in the sense that th= e actual video frame (which in my opinion, for the HEVC case, is the VCL NA= L units of an access unit) can be completely received even though there are= more packet(s) that are following with the same time stamp. Since none of the suffix SEI messages has any normative effect on the outpu= t of the decoder, why should it be necessary to wait for example for a deco= ded_picture_hash SEI before detecting that a frame can be displayed? Ye-Kui, you earlier wrote: "Anyway, I admitted that the current semantics are not fully future-proof r= egarding suffix SEI messages. In looking into future multi-layer extensions= , it appears that simply changing the wording from "last NAL unit" to "last= VCL NAL unit" is not good enough." But if (as I initially suggested) the change is from "last NAL unit of an a= ccess unit" to "last VCL NAL unit of a picture" I guess it could work also = for future extensions in which there will be several pictures in the same a= ccess unit. Or do you see a problem here? Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 6 mars 2014 01:24 To: Jonathan Lennox Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Agree to make the intention clearer, e.g. by adding a note. On your last question: I think you are right, a non-VCL suffix NAL unit, e.= g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_la= yer_id equal to 0, and thus in MST the last NAL unit of an access unit may = actually be carried in the last packet from the "base" RTP stream. And yes = this actually does not matter for using of the marker bit for the purpose d= escribed below.=20 BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Wednesday, March 05, 2014 4:05 PM To: Wang, Ye-Kui Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC This seems correct to me. I would suggest, however, explicitly pointing ou= t that in MST mode, if an access unit appears in multiple packet streams, t= he marker bit is set on each packet stream's last packet of the access unit= . I think this definition works even when DONs are in use (when sprop-depack-= buf-nalus is > 0), since an AP can only contain packets from a single acces= s unit. If packets from different access units are interleaved (in RTP ord= er) using DON, the packet stream will look odd to a naive RTP analysis, but= I believe the marker bit will still be useful, allowing low-delay decoders= to flush complete access units out of the de-packetization buffer early. Ye-Kui, a question about your comment, though: are we sure that the final p= acket of the access unit will in fact always be the final packet of the hig= hest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able to= split MST streams by nuh_layer_id. How will the nuh_layer_id be set for t= railing SEIs in such streams? If it's set to 0, then the final packet of t= he access unit will in fact be sent in a lower layer. I don't think this a= ctually matters, especially since MST streams will use DON, but we should b= e careful about our logic. On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: > I did a bit of search on the usage of the marker bit for video, and the m= ost relevant description I found was the following paragraph in Section 5 o= f RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > So the key usage of the marker bit is that in some low-delay applications= , output/display of a picture can be done before receiving an RTP packet wi= th a different/greater timestamp. Since non-VCL NAL unit should have the sa= me timestamp as the associated picture, thus I think we should not use the = wording of "last VCL NAL unit" in determining the setting of the marker bit= . >=20 > To make the semantics extensible or future-proof for multi-layer extensio= ns, I think we should change it to be RTP stream (or equivalently packet st= ream) specific, and each receiver can just look at the marker bits of the p= ackets from the highest RTP stream for the usage. And this will also resolv= e the issue of requiring some entities to change the marker bit in sub-laye= r scalability usage as Jonaton raised.=20 >=20 > In other words, the normative semantics are to be changed as follows: >=20 > Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling. >=20 > Please let me know if there is any concern with such a change (and note t= hat we would align the terminology of RTP stream with other drafts, e.g. th= e Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing = comments). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui > Sent: Wednesday, March 05, 2014 10:29 AM > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Something should be done to the HEVC spec to make it clearer for the deco= ded picture hash SEI message, like that it shall not be nested and what the= values of LayerId and LId should be, or allow add to the list of nestable = SEI message. In any case, it does not make sense to me to put a greater val= ue of TId than its associated picture. On user_data_registered_itu_t_t35 an= d user_data_unregistered suffix SEI messages, only if it is defined by some= application then it may make sense to put a greater value of TId than its = associated picture - currently I have not seen any such use being defined a= nywhere. >=20 > Anyway, I admitted that the current semantics are not fully future-proof = regarding suffix SEI messages. In looking into future multi-layer extension= s, it appears that simply changing the wording from "last NAL unit" to "las= t VCL NAL unit" is not good enough. We might need to specify the semantics = of the marker bit to be RTP stream specific. To make sure whether such a ch= ange is OK, we also need to check against the usage of the marker bit. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, March 05, 2014 1:07 AM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks for your response Ye-Kui, >=20 > As far as I understand, out of the 6 SEI messages that have so far been d= efined in the HEVC spec as possible to use as suffixes (filler_payload, use= r_data_registered_itu_t_t35, user_data_unregistered, progressive_refinement= _segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that = are not required to have the same TId as the VCL NAL units of the access un= it: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pic= ture_hash since their payloadType numbers (4, 5 and 132) are not included i= n the list: >=20 > "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 1= 6, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages = that have payloadType not equal to 0, 1, or 130, and that are allowed to be= nested SEI messages), the SEI NAL unit containing the non-nested SEI messa= ge shall have TemporalId equal to the TemporalId of the access unit contain= ing the SEI NAL unit." >=20 > Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I= think the problem would exist even if was. An encoder that (for whatever r= eason) puts in user_data_registered_itu_t_t35 or user_data_unregistered suf= fix SEI messages with higher TId would put a MANE in a difficult situation.= =20 >=20 > I also think we should consider future extensions of HEVC (i.e. SHVC and = MV-HEVC) in which an access unit may contain many pictures with different v= alues of nuh_layer_id. If the marker bit is set for the last packet of an a= ccess unit, then once again all the marker bits will end up in the highest = layer (stream) and a MANE would have to change the value of marker bits as = soon as not all layers (streams) are forwarded. >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 5 mars 2014 01:20 > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hmm, a decoded picture hash SEI message applies to (and is associated wit= h) the preceding decoding picture in decoding order and thus the TId of the= containing suffix SEI NAL unit should be set equal to the TId of the assoc= iated picture. Thus in the example, for the suffix SEI NAL unit containing = the decoded picture hash SEI message for the first encoded picture should b= e assigned TId equal to 0.=20 >=20 > According to the HEVC spec, currently the following SEI messages are or c= an be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, = user_data_unregistered, progressive_refinement_segment_end, post_filter_hin= t, and decoded_picture_hash. Among these, I think all of the "specified" SE= I messages (i.e. the above list excluding user_data_registered_itu_t_t35, u= ser_data_unregistered) contained in a suffix SEI NAL unit would apply to th= e preceding decoded picture in decoder order and should have the same TId a= s the associated picture. The only SEI messages that can have a greater TId= value than the containing access unit are the three SEI message that can c= arry HRD information, i.e., buffering_period, pic_timing, and decoding_unit= _info, but these can only be prefix SEI messages. >=20 > Of course, in theory, future versions of HEVC or some extensions (even de= fined by an application spec) could define suffix SEI messages that can hav= e a greater TId value than the containing access unit. In that case, what y= ou described could be meaningful, and indeed if a receiver receives the "ba= se sub-layer" stream, some entity would have to set the marker bit of those= packets containing the last NAL unit of an access unit for that stream, ac= cording to the current semantics. >=20 > However, if we change the wording to the last VCL NAL unit as you suggest= ed, and in case a suffix SEI NAL unit of picture A is not carried the packe= t containing the last VCL NAL unit if the access unit, would the usage of t= he marker bit be affected, e.g. in playout buffer handling? If the answer i= s no, then there should be no problem to do the change. >=20 > Basically the situation is as follows. There is no concrete problem now. = However, there can be a potential problem in the future if a suffix SEI mes= sage is defined and can have a greater TId value than the containing access= unit. If the suggested change does not affect the usage of the bit, we sho= uld do the change now to make the design future-proof. So the key question = is whether the suggest change would affect the usage of the bit.=20 >=20 > Does anyone know how the marker bit is used in playout buffering handling= ? An explanation or a pointer would be greatly appreciated. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Tuesday, March 04, 2014 1:28 PM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Dear Ye-Kui, >=20 > Let me try to make the example more specific (and then also see if I have= understood the multi-stream transmission concept correctly). >=20 > Assume that the sender puts all NAL units with TId 0 in one RTP stream (s= tream A) and all NAL units with TId 1 in another RTP stream (stream B). Now= for the first encoded picture the VCL NAL units are assigned TId 0 and the= n a decoded picture hash SEI message is created in the same access unit but= is given TId 1. Then the marker bit will be set on the packet containing t= he decoded picture hash SEI message which is put in stream B. If this schem= e is applied for all access units, stream A will not contain any packets wi= th the marker bit set since these are all put in stream B. A MANE that only= wants to forward stream A to a receiver would be required to perform analy= sis (and probably introduce delay) in order to correctly change the marker = bit on the "new" last packet of the access unit. >=20 > Is that correct, or have I misinterpreted anything? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 4 mars 2014 18:21 > To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; st= ewe@stewe.org; Jonatan Samuelsson > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hi Jonatan, >=20 > I do not fully understand the following example: >=20 > "However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units).= For that case I guess there will be one RTP stream (corresponding to TId 0= ) completely without any marker bit set, right?" >=20 > Could you please check whether it can be clarified a bit? >=20 > BR, YK >=20 > -----Original Message----- > From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 > Sent: Monday, March 03, 2014 2:11 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe= .org; jonatan.samuelsson@ericsson.com > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > #10: Marker bit in H.265/HEVC >=20 >=20 > Comment (by jonatan.samuelsson@ericsson.com): >=20 > Thanks Stefan for the comments and the example. It is exactly this kind o= f cases I'm concerned about but I wouldn't characterize them as exotic. Fo= r conversational applications it is natural to operate in *very* low delay= mode (i.e. not buffering packets before forwarding them) and having post-= picture SEI packetized in their own packets is the only option as soon as= the VCL NAL units are fragmented since FUs cannot be aggregated. Having t= o introduce slices just to avoid FUs and thereby being able to aggregate S= EI messages with VCL NAL units does not sound like a compelling alternativ= e. >=20 > The most reasonable solution for this case is probably to just not perfor= m thinning by removing the SEI messages since they are typically not very = large in the first place. >=20 > However, as far as I understand, it is allowed for an encoder to create a= bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). > For that case I guess there will be one RTP stream (corresponding to TId > 0) completely without any marker bit set, right? >=20 > --=20 > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Thu Mar 6 16:40:00 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DEB1A017D for ; Thu, 6 Mar 2014 16:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 0pB1yJ7h5ozL for ; Thu, 6 Mar 2014 16:39:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 276E51A001D for ; Thu, 6 Mar 2014 16:39:55 -0800 (PST) Received: from localhost ([127.0.0.1]:39410 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLip8-0008PS-R7; Fri, 07 Mar 2014 01:39:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Fri, 07 Mar 2014 00:39:37 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/9#comment:2 Message-ID: <088.e5482ff1a3d22c96bf860aef2b094236@trac.tools.ietf.org> References: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/KC5WzwzucBPpUcDYBvElew-Gr5c Cc: payload@ietf.org Subject: Re: [payload] #9 (rtp-h265): Empty FUs X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:39:58 -0000 #9: Empty FUs Changes (by yekuiw@qti.qualcomm.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Thu Mar 6 16:41:17 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079E81A00CA for ; Thu, 6 Mar 2014 16:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 Y3LgF9WFoKYj for ; Thu, 6 Mar 2014 16:41:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 54B901A001D for ; Thu, 6 Mar 2014 16:41:13 -0800 (PST) Received: from localhost ([127.0.0.1]:39465 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLiqR-0006NE-Hu; Fri, 07 Mar 2014 01:41:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Fri, 07 Mar 2014 00:40:59 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/11#comment:2 Message-ID: <088.2d6dcf972f264084249461a7dba9fd08@trac.tools.ietf.org> References: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Rf5ffVxWHUyC3RnMRioio3t3uSc Cc: payload@ietf.org Subject: Re: [payload] #11 (rtp-h265): Slice based parallelism X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:41:15 -0000 #11: Slice based parallelism Changes (by yekuiw@qti.qualcomm.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Thu Mar 6 23:59:42 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0D1A024C for ; Thu, 6 Mar 2014 23:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] 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 7sFWa3afp0_s for ; Thu, 6 Mar 2014 23:59:35 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE81A0258 for ; Thu, 6 Mar 2014 23:59:34 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i8so4319852qcq.31 for ; Thu, 06 Mar 2014 23:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YOAIKpU9n8oD1NAeD48c7QfR+y4XMih5mATi2EJjUpY=; b=qDr7qF8TmXObivzvyJh/ygq98M9ynUpDHpCvgQh3d9f8srVYOkS/bcay3/FbnRdnah nn5p4FPCyBls6EbPT3/mPFINvb0XQndl064DbRtO988ILtv+qe0CEhBgUkNgk2Q0M3A+ 8FNK9KlZVe8XdUGoJtRr6D1x5WLUoaNmfRFvN7oqyzQ8UgpUEzXXPP4OLvadyRzN/MNF FQm36BhPmfR2+itDQweCNZTfzMPrLeuHm1Wgi5UDxN677F6DmkY32CpYenI6k/L7VKJs fXzOWl/mucDQy2JrB2+ooXOS1mkbdC4og3ElwCHg88GtEyjf19jPEAcrOWxohCHKGj4r A0hg== MIME-Version: 1.0 X-Received: by 10.229.125.193 with SMTP id z1mr13381339qcr.10.1394179170232; Thu, 06 Mar 2014 23:59:30 -0800 (PST) Received: by 10.229.2.69 with HTTP; Thu, 6 Mar 2014 23:59:30 -0800 (PST) In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D5BA4@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BA4@nasanexd02f.na.qualcomm.com> Date: Fri, 7 Mar 2014 08:59:30 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Wang, Ye-Kui" Content-Type: multipart/alternative; boundary=001a1132e66c31ed6204f3ffa2b6 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ecuFnKl49MDB5Kp_ofNt0oCRxVA Cc: "Tom Kristensen \(tomkrist@cisco.com\)" , "payload@ietf.org" Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:59:38 -0000 --001a1132e66c31ed6204f3ffa2b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I cannot see a reason for using SHOULD in offer/answer scenarios - as Stephan argued for earlier here. If there is a limit and a reason for signalling max-fps due, there is little use waiving the flag with a SHOULD (which is often ignored, as we know). I think we should rather remove max-fps for declarative usage (or relax the MUST to SHOULD there). -- Tom On 4 March 2014 18:16, Wang, Ye-Kui wrote: > Let me pull Tom into the discussion :-) Personally I am OK with the SHOUL= D > language here too as I don't have a good counter argument against Jonatan= 's > comment. > > Tom, would the SHOULD language be fine with you as well (as the proponent > of this parameter)? Do you see any technical problem with this? > > BR, YK > > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] > Sent: Tuesday, March 04, 2014 2:43 AM > To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken > (geirsand); payload@ietf.org > Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter > > As far as I know, all other similar parameters in H.264 RTP PL and H.265 > RTP PL extends on the levels defined in the video specification in the > sense that you are capable of expressing for example "I can decode level > 4.1 plus resolutions up to 4K" which can never put a level 4.1 compliant > encoder in a difficult situation (i.e. everything in level 4.1 is still > allowed). > > If the motivation for max-fps is only for SDP O/A, why isn't the SDP > attribute a=3Dframerate sufficient? > > Best Regards Jonatan > > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: den 4 mars 2014 10:48 > To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken > (geirsand); payload@ietf.org > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > Let me push back once more. Overwriting the limits of the level > definition is common practice in the video conferencing industry, and has > been done since staid industry changed to H.264 (which first introduced t= he > level concepts in video compression standards widely deployed in video > conferencing). That SHOULD will be ignored, or overwritten by system > standards. > Is there any technical reason for not allowing overwriting level > limitations in scenarios where there is two way negotiation? > (I would be fine with a SHOULD, or even the removal of max_fps entirely, > in SDP declarative use scenarios. I only care about O/A scenarios.) Step= han > > > On 4.3.14, 9:41, "Jonatan Samuelsson" > wrote: > > >Thanks Ye-Kui for the suggested changes. I think they improve the > >situation to a large extent, but there is one more thing that I would > >like change; replacing the "MUST" with a "SHOULD" so that it becomes: > > > >"The encoder SHOULD 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." > > > >I think this change would be needed in order to not redefine the level > >definitions of the HEVC specification. A sender that for some reason is > >not capable of producing lower picture rate (e.g. since the material is > >pre-encoded) should be allowed to use a picture rate higher than the > >value of max-fps, but it must then be aware that the receiver might not > >be capable of adequately present all decoded pictures. > > > >Best Regards Jonatan > > > >-----Original Message----- > >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, > >Ye-Kui > >Sent: den 27 februari 2014 19:20 > >To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org > >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > > >I am with Magnus here. If a decoder cannot DECODE a picture rate > >allowed by a level, then the decoder is not even a confirming decoder. > >We usually don't standardize mechanisms for non-confirming decoders, > >unless there is a very strong reason. > > > >I think making the following changes (4 places in the first paragraph > >of the semantics) would resolve the issue, with conceptually good > >semantics, but the use of the parameter is still practically the same. > > > >-----------------Start of the semantics, with suggested > >changes-------------------------- > >max-fps: > >The value of max-fps is an integer indicating the maximum picture rate > >in units of hundreds of pictures per second that can be efficiently > >received (***CHANGE TO "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 decoding (***CHANGE TO > >"processing"***) video efficiently (***CHANGE TO "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. > >-----------------End of the semantics, with suggested > >changes-------------------------- > > > >Please express your opinion if this is not acceptable to you. > > > >BR, YK > > > > > >-----Original Message----- > >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > >Westerlund > >Sent: Thursday, February 27, 2014 7:32 AM > >To: Geir Sandbakken (geirsand); payload@ietf.org > >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > > >On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > >> #12: The max-fps parameter > >> > >> Lessons learned from video conferencing using H.264 showed that a lot > >>of equipment designed for 30 fps could not handle 60 fps even at > >>sufficiently low resolution. We do anticipate similar problems when > >>moving towards 120 fps in H.265. It might not be caused by > >>limitations in the decoder itself, but that the surrounding media > >>pipeline will not have been properly tested for 120 fps before being > >>put into the wild. > >> If we don't allow for a code point to be used by the "restricted" > >> equipment, it will be required by the "flexible/proper" to include one= . > >> This is what happened with max-fps in H.264 enabling higher frame > >>rates compared to lowering them. > >> > > > >I do have concerns with defining a parameter that allow dynamically > >sub-setting the profile and levels that has been defined for HEVC. This > >can also create interoperability issues with any pre-encoded content to > >a particular profile and level. > > > >The issues with the media pipeline has they been with the reception of > >the high framerate of packets and forwarding them to the decoder or the > >playback part, i.e. handling of the decoded picture? > > > >If it is predominately the later it appears very reasonable to have > >this as an informative parameter. I will not make use of higher FPS > >than X, if you send me higher than X I will need to reduce that to X or > >lower before displaying it. That way we are not re-defining the > >profiles, we are ensuring that we can handle content encoded within the > >profile and still by taking care of the this in the end of your decoder > >chain you can protect the rest of the media framework from not yet > >supported frame-rates. > > > >Cheers > > > >Magnus Westerlund > > > >---------------------------------------------------------------------- > >Services, Media and Network features, Ericsson Research EAB/TXM > >---------------------------------------------------------------------- > >Ericsson AB | Phone +46 10 7148287 > >F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >---------------------------------------------------------------------- > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a1132e66c31ed6204f3ffa2b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well, I cannot see a reason for using SHOULD in offer/answ= er scenarios - as Stephan argued for earlier here. If there is a limit and = a reason for signalling max-fps due, there is little use waiving the flag w= ith a SHOULD (which is often ignored, as we know).

I think we should rather remove max-fps for declarative usag= e (or relax the MUST to SHOULD there).

-- Tom


On 4 March 2014 18:16, Wang, Ye-Kui <yekuiw@qti.qualcomm.com>= wrote:
Let me pull Tom into the discussion :-) Personally I am OK with the SHOULD = language here too as I don't have a good counter argument against Jonat= an's comment.

Tom, would the SHOULD language be fine with you as well (as the proponent o= f this parameter)? Do you see any technical problem with this?

BR, YK

-----Original Message-----
From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Tuesday, March 04, 2014 2:43 AM
To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (geirs= and); payload@ietf.org
Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter

As far as I know, all other similar parameters in H.264 RTP PL and H.265 RT= P PL extends on the levels defined in the video specification in the sense = that you are capable of expressing for example "I can decode level 4.1= plus resolutions up to 4K" which can never put a level 4.1 compliant = encoder in a difficult situation (i.e. everything in level 4.1 is still all= owed).

If the motivation for max-fps is only for SDP O/A, why isn't the SDP at= tribute a=3Dframerate sufficient?

Best Regards Jonatan

-----Original Message-----
From: Stephan Wenger [mailto:stewe@stewe= .org]
Sent: den 4 mars 2014 10:48
To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (g= eirsand); payload@ietf.org
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter

Let me push back once more. =A0Overwriting the limits of the level definiti= on is common practice in the video conferencing industry, and has been done= since staid industry changed to H.264 (which first introduced the level co= ncepts in video compression standards widely deployed in video conferencing= ). =A0That SHOULD will be ignored, or overwritten by system standards.
Is there any technical reason for not allowing overwriting level limitation= s in scenarios where there is two way negotiation?
(I would be fine with a SHOULD, or even the removal of max_fps entirely, in= SDP declarative use scenarios. =A0I only care about O/A scenarios.) Stepha= n


On 4.3.14, 9:41, "Jonatan Samuelsson" <jonatan.samuelsson@ericsson.com>
wrote:

>Thanks Ye-Kui for the suggested changes. I think they improve the
>situation to a large extent, but there is one more thing that I would >like change; replacing the "MUST" with a "SHOULD" s= o that it becomes:
>
>"The encoder SHOULD 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."
>
>I think this change would be needed in order to not redefine the level<= br> >definitions of the HEVC specification. A sender that for some reason is=
>not capable of producing lower picture rate (e.g. since the material is=
>pre-encoded) should be allowed to use a picture rate higher than the >value of max-fps, but it must then be aware that the receiver might not=
>be capable of adequately present all decoded pictures.
>
>Best Regards Jonatan
>
>-----Original Message-----
>From: payload [mailto:paylo= ad-bounces@ietf.org] On Behalf Of Wang,
>Ye-Kui
>Sent: den 27 februari 2014 19:20
>To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org
>Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
>
>I am with Magnus here. If a decoder cannot DECODE a picture rate
>allowed by a level, then the decoder is not even a confirming decoder.<= br> >We usually don't standardize mechanisms for non-confirming decoders= ,
>unless there is a very strong reason.
>
>I think making the following changes (4 places in the first paragraph >of the semantics) would resolve the issue, with conceptually good
>semantics, but the use of the parameter is still practically the same.<= br> >
>-----------------Start of the semantics, with suggested
>changes--------------------------
>max-fps:
>The value of max-fps is an integer indicating the maximum picture rate<= br> >in units of hundreds of pictures per second that can be efficiently
>received (***CHANGE TO "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 decoding (***CHANGE TO
>"processing"***) video efficiently (***CHANGE TO =A0"eff= ectively"***) 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<= br> >max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that<= br> >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.
>-----------------End of the semantics, with suggested
>changes--------------------------
>
>Please express your opinion if this is not acceptable to you.
>
>BR, YK
>
>
>-----Original Message-----
>From: payload [mailto:paylo= ad-bounces@ietf.org] On Behalf Of Magnus
>Westerlund
>Sent: Thursday, February 27, 2014 7:32 AM
>To: Geir Sandbakken (geirsand); pay= load@ietf.org
>Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
>
>On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote:
>> #12: The max-fps parameter
>>
>> Lessons learned from video conferencing using H.264 showed that a = lot
>>of equipment designed for 30 fps could not handle 60 fps even at >>sufficiently low resolution. We do anticipate similar problems when=
>>moving towards 120 fps in H.265. =A0It might not be caused by
>>limitations in the decoder itself, =A0but that the surrounding medi= a
>>pipeline will not have been properly tested for 120 fps before bein= g
>>put into the wild.
>> If we don't allow for a code point to be used by the "res= tricted"
>> equipment, it will be required by the "flexible/proper" = to include one.
>> This is what happened with max-fps in H.264 enabling higher frame<= br> >>rates compared to lowering them.
>>
>
>I do have concerns with defining a parameter that allow dynamically
>sub-setting the profile and levels that has been defined for HEVC. This=
>can also create interoperability issues with any pre-encoded content to=
>a particular profile and level.
>
>The issues with the media pipeline has they been with the reception of<= br> >the high framerate of packets and forwarding them to the decoder or the=
>playback part, i.e. handling of the decoded picture?
>
>If it is predominately the later it appears very reasonable to have
>this as an informative parameter. I will not make use of higher FPS
>than X, if you send me higher than X I will need to reduce that to X or=
>lower before displaying it. That way we are not re-defining the
>profiles, we are ensuring that we can handle content encoded within the=
>profile and still by taking care of the this in the end of your decoder=
>chain you can protect the rest of the media framework from not yet
>supported frame-rates.
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------<= br> >Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------<= br> >Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 7148287 >F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079=
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------<= br> >
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



--
= # Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/tel= epresence/
## tomkrist@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--001a1132e66c31ed6204f3ffa2b6-- From nobody Fri Mar 7 00:20:20 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5371A0113 for ; Fri, 7 Mar 2014 00:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] 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 gIy1-s43-CNi for ; Fri, 7 Mar 2014 00:20:10 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B30C31A0125 for ; Fri, 7 Mar 2014 00:20:09 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-7c-531981340acb Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A9.E8.04853.43189135; Fri, 7 Mar 2014 09:20:04 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 09:20:03 +0100 From: Jonatan Samuelsson To: Tom Kristensen <2mkristensen@gmail.com>, "Wang, Ye-Kui" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/FZ37D8KebEWrOTyjcR0I9prJKgwAgAAu2ACAB1WSwP//9wAAgAAcGYCAAGFSgIAEG2cAgAASVMA= Date: Fri, 7 Mar 2014 08:20:02 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C7BA8@ESESSMB109.ericsson.se> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BA4@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_634D3B5D82E3214DA9B6A36D5F50DB231C7BA8ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvja5Jo2SwweZudYstx9+xWJw4cpDd 4tLFs0wW1xs3sVtcOfKLzeLJmmPMDmweU35vZPXYOesuu8eSJT+ZPBZNfcbosXj9e8YA1igu m5TUnMyy1CJ9uwSujHX7zjAVvHnCWLHneR9bA2P3EcYuRk4OCQETiUktHawQtpjEhXvr2UBs IYETjBKzb1R0MXIB2YsZJV6t7GHvYuTgYBOwkvj+IgKkRkQgXOL47D8sIDazwBdGiTn7eEFs YQEbibePu1ghamwlGuc/YARpFRFIkli4igskzCKgIvF44UawE3gFvCXuHPjICrHqIrPE2cbj rCD1nAKBEhtWu4DUMArIStz/fg9qlbjErSfzmSBOFpBYsuc8M4QtKvHy8T+oVxQl2p82MELU 50u8m3SMBWKXoMTJmU9YJjCKzkIyahaSsllIyiDiehI3pk5hg7C1JZYtfM0MYetKzPh3iAVZ fAEj+ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMDoPbjlt9EOxpN77A8xSnOwKInz XmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWHU8qWTxjmeufNqeM05P3rym5HTN3DtT 3mSECnfcNGjpai91O6klo7tlcvCR8CZ7H64La4yYNplVrwv60lAx12OxsmRZR+/0iQfyGs8t 0/TOtlnz+Oz1l4tcnq5+Elm6OHHq/JC9/qUn/2T3rJZ3THdl8+UJ/8D4uW1PjqB2vulpnunL y45eVGIpzkg01GIuKk4EAG9Ar4isAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/IGqXewWycKsa_6Iudd02YN394Y8 Cc: "Tom Kristensen \(tomkrist@cisco.com\)" , "payload@ietf.org" Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 08:20:18 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB231C7BA8ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Tom for your feedback, For me to get a better understanding of if it is reasonable to make an exce= ption from the design principle of not re-defining level definitions from t= he video specification, it would be very valuable with answers to my earlie= r question: "If the motivation for max-fps is only for SDP O/A, why isn't the SDP attri= bute a=3Dframerate sufficient?" and to Magnus' earlier question: "The issues with the media pipeline has they been with the reception of the= high framerate of packets and forwarding them to the decoder or the playba= ck part, i.e. handling of the decoded picture?" Best Regards Jonatan From: Tom Kristensen [mailto:2mkristensen@gmail.com] Sent: den 7 mars 2014 09:00 To: Wang, Ye-Kui Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; Geir Sandbakken = (geirsand); payload@ietf.org; Tom Kristensen (tomkrist@cisco.com) Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter Well, I cannot see a reason for using SHOULD in offer/answer scenarios - as= Stephan argued for earlier here. If there is a limit and a reason for sign= alling max-fps due, there is little use waiving the flag with a SHOULD (whi= ch is often ignored, as we know). I think we should rather remove max-fps for declarative usage (or relax the= MUST to SHOULD there). -- Tom On 4 March 2014 18:16, Wang, Ye-Kui > wrote: Let me pull Tom into the discussion :-) Personally I am OK with the SHOULD = language here too as I don't have a good counter argument against Jonatan's= comment. Tom, would the SHOULD language be fine with you as well (as the proponent o= f this parameter)? Do you see any technical problem with this? BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Tuesday, March 04, 2014 2:43 AM To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (geirs= and); payload@ietf.org Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter As far as I know, all other similar parameters in H.264 RTP PL and H.265 RT= P PL extends on the levels defined in the video specification in the sense = that you are capable of expressing for example "I can decode level 4.1 plus= resolutions up to 4K" which can never put a level 4.1 compliant encoder in= a difficult situation (i.e. everything in level 4.1 is still allowed). If the motivation for max-fps is only for SDP O/A, why isn't the SDP attrib= ute a=3Dframerate sufficient? Best Regards Jonatan -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org] Sent: den 4 mars 2014 10:48 To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (g= eirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter Let me push back once more. Overwriting the limits of the level definition= is common practice in the video conferencing industry, and has been done s= ince staid industry changed to H.264 (which first introduced the level conc= epts in video compression standards widely deployed in video conferencing).= That SHOULD will be ignored, or overwritten by system standards. Is there any technical reason for not allowing overwriting level limitation= s in scenarios where there is two way negotiation? (I would be fine with a SHOULD, or even the removal of max_fps entirely, in= SDP declarative use scenarios. I only care about O/A scenarios.) Stephan On 4.3.14, 9:41, "Jonatan Samuelsson" > wrote: >Thanks Ye-Kui for the suggested changes. I think they improve the >situation to a large extent, but there is one more thing that I would >like change; replacing the "MUST" with a "SHOULD" so that it becomes: > >"The encoder SHOULD 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." > >I think this change would be needed in order to not redefine the level >definitions of the HEVC specification. A sender that for some reason is >not capable of producing lower picture rate (e.g. since the material is >pre-encoded) should be allowed to use a picture rate higher than the >value of max-fps, but it must then be aware that the receiver might not >be capable of adequately present all decoded pictures. > >Best Regards Jonatan > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, >Ye-Kui >Sent: den 27 februari 2014 19:20 >To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >I am with Magnus here. If a decoder cannot DECODE a picture rate >allowed by a level, then the decoder is not even a confirming decoder. >We usually don't standardize mechanisms for non-confirming decoders, >unless there is a very strong reason. > >I think making the following changes (4 places in the first paragraph >of the semantics) would resolve the issue, with conceptually good >semantics, but the use of the parameter is still practically the same. > >-----------------Start of the semantics, with suggested >changes-------------------------- >max-fps: >The value of max-fps is an integer indicating the maximum picture rate >in units of hundreds of pictures per second that can be efficiently >received (***CHANGE TO "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 decoding (***CHANGE TO >"processing"***) video efficiently (***CHANGE TO "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. >-----------------End of the semantics, with suggested >changes-------------------------- > >Please express your opinion if this is not acceptable to you. > >BR, YK > > >-----Original Message----- >From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus >Westerlund >Sent: Thursday, February 27, 2014 7:32 AM >To: Geir Sandbakken (geirsand); payload@ietf.org >Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > >On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: >> #12: The max-fps parameter >> >> Lessons learned from video conferencing using H.264 showed that a lot >>of equipment designed for 30 fps could not handle 60 fps even at >>sufficiently low resolution. We do anticipate similar problems when >>moving towards 120 fps in H.265. It might not be caused by >>limitations in the decoder itself, but that the surrounding media >>pipeline will not have been properly tested for 120 fps before being >>put into the wild. >> If we don't allow for a code point to be used by the "restricted" >> equipment, it will be required by the "flexible/proper" to include one. >> This is what happened with max-fps in H.264 enabling higher frame >>rates compared to lowering them. >> > >I do have concerns with defining a parameter that allow dynamically >sub-setting the profile and levels that has been defined for HEVC. This >can also create interoperability issues with any pre-encoded content to >a particular profile and level. > >The issues with the media pipeline has they been with the reception of >the high framerate of packets and forwarding them to the decoder or the >playback part, i.e. handling of the decoded picture? > >If it is predominately the later it appears very reasonable to have >this as an informative parameter. I will not make use of higher FPS >than X, if you send me higher than X I will need to reduce that to X or >lower before displaying it. That way we are not re-defining the >profiles, we are ensuring that we can handle content encoded within the >profile and still by taking care of the this in the end of your decoder >chain you can protect the rest of the media framework from not yet >supported frame-rates. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_634D3B5D82E3214DA9B6A36D5F50DB231C7BA8ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Tom for your feedb= ack,

 <= /p>

For me to get a better un= derstanding of if it is reasonable to make an exception from the design pri= nciple of not re-defining level definitions from the video specification, it would be very valuable with answers to my earlier questi= on:

 <= /p>

“If the moti= vation for max-fps is only for SDP O/A, why isn't the SDP attribute a=3Dfra= merate sufficient?”

 <= /p>

and to Magnus’ earl= ier question:

 <= /p>

“The issues = with the media pipeline has they been with the reception of the high framer= ate of packets and forwarding them to the decoder or the playback part, i.e. handling of the decoded picture?R= 21;

 <= /p>

Best Regards Jonatan=

 <= /p>

From: Tom Kris= tensen [mailto:2mkristensen@gmail.com]
Sent: den 7 mars 2014 09:00
To: Wang, Ye-Kui
Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; Geir Sand= bakken (geirsand); payload@ietf.org; Tom Kristensen (tomkrist@cisco.com) Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter

 

Well, I cannot see a reason for using SHOULD in offe= r/answer scenarios - as Stephan argued for earlier here. If there is a limi= t and a reason for signalling max-fps due, there is little use waiving the = flag with a SHOULD (which is often ignored, as we know).

 

I think we should rather remove max-fps for declarat= ive usage (or relax the MUST to SHOULD there).

 

-- Tom

 

On 4 March 2014 18:16, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:

Let me pull Tom into the discussion :-) Personally I= am OK with the SHOULD language here too as I don't have a good counter arg= ument against Jonatan's comment.

Tom, would the SHOULD language be fine with you as well (as the proponent o= f this parameter)? Do you see any technical problem with this?

BR, YK


-----Original Message-----
From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Tuesday, March 04, 2014 2:43 AM
To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (geirs= and); payload@ietf.org
Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter

As far as I know, all other similar parameters in H.264 RTP PL and H.265 RT= P PL extends on the levels defined in the video specification in the sense = that you are capable of expressing for example "I can decode level 4.1= plus resolutions up to 4K" which can never put a level 4.1 compliant encoder in a difficult situation (i.e. eve= rything in level 4.1 is still allowed).

If the motivation for max-fps is only for SDP O/A, why isn't the SDP attrib= ute a=3Dframerate sufficient?

Best Regards Jonatan

-----Original Message-----
From: Stephan Wenger [mailto:stewe@stewe= .org]
Sent: den 4 mars 2014 10:48
To: Jonatan Samuelsson; Wang, Ye-Kui; Magnus Westerlund; Geir Sandbakken (g= eirsand); payload@ietf.org
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter

Let me push back once more.  Overwriting the limits of the level defin= ition is common practice in the video conferencing industry, and has been d= one since staid industry changed to H.264 (which first introduced the level= concepts in video compression standards widely deployed in video conferencing).  That SHOULD will be ignored,= or overwritten by system standards.
Is there any technical reason for not allowing overwriting level limitation= s in scenarios where there is two way negotiation?
(I would be fine with a SHOULD, or even the removal of max_fps entirely, in= SDP declarative use scenarios.  I only care about O/A scenarios.) Ste= phan


On 4.3.14, 9:41, "Jonatan Samuelsson" <jonatan.samuelsson@ericsson.com>
wrote:

>Thanks Ye-Kui for the suggested changes. I think they improve the
>situation to a large extent, but there is one more thing that I would >like change; replacing the "MUST" with a "SHOULD" s= o that it becomes:
>
>"The encoder SHOULD 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."
>
>I think this change would be needed in order to not redefine the level<= br> >definitions of the HEVC specification. A sender that for some reason is=
>not capable of producing lower picture rate (e.g. since the material is=
>pre-encoded) should be allowed to use a picture rate higher than the >value of max-fps, but it must then be aware that the receiver might not=
>be capable of adequately present all decoded pictures.
>
>Best Regards Jonatan
>
>-----Original Message-----
>From: payload [mailto:paylo= ad-bounces@ietf.org] On Behalf Of Wang,
>Ye-Kui
>Sent: den 27 februari 2014 19:20
>To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org
>Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
>
>I am with Magnus here. If a decoder cannot DECODE a picture rate
>allowed by a level, then the decoder is not even a confirming decoder.<= br> >We usually don't standardize mechanisms for non-confirming decoders, >unless there is a very strong reason.
>
>I think making the following changes (4 places in the first paragraph >of the semantics) would resolve the issue, with conceptually good
>semantics, but the use of the parameter is still practically the same.<= br> >
>-----------------Start of the semantics, with suggested
>changes--------------------------
>max-fps:
>The value of max-fps is an integer indicating the maximum picture rate<= br> >in units of hundreds of pictures per second that can be efficiently
>received (***CHANGE TO "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 decoding (***CHANGE TO
>"processing"***) video efficiently (***CHANGE TO  "= 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<= br> >max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that<= br> >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.
>-----------------End of the semantics, with suggested
>changes--------------------------
>
>Please express your opinion if this is not acceptable to you.
>
>BR, YK
>
>
>-----Original Message-----
>From: payload [mailto:paylo= ad-bounces@ietf.org] On Behalf Of Magnus
>Westerlund
>Sent: Thursday, February 27, 2014 7:32 AM
>To: Geir Sandbakken (geirsand); pay= load@ietf.org
>Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
>
>On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote:
>> #12: The max-fps parameter
>>
>> Lessons learned from video conferencing using H.264 showed that a = lot
>>of equipment designed for 30 fps could not handle 60 fps even at >>sufficiently low resolution. We do anticipate similar problems when=
>>moving towards 120 fps in H.265.  It might not be caused by >>limitations in the decoder itself,  but that the surrounding m= edia
>>pipeline will not have been properly tested for 120 fps before bein= g
>>put into the wild.
>> If we don't allow for a code point to be used by the "restric= ted"
>> equipment, it will be required by the "flexible/proper" = to include one.
>> This is what happened with max-fps in H.264 enabling higher frame<= br> >>rates compared to lowering them.
>>
>
>I do have concerns with defining a parameter that allow dynamically
>sub-setting the profile and levels that has been defined for HEVC. This=
>can also create interoperability issues with any pre-encoded content to=
>a particular profile and level.
>
>The issues with the media pipeline has they been with the reception of<= br> >the high framerate of packets and forwarding them to the decoder or the=
>playback part, i.e. handling of the decoded picture?
>
>If it is predominately the later it appears very reasonable to have
>this as an informative parameter. I will not make use of higher FPS
>than X, if you send me higher than X I will need to reduce that to X or=
>lower before displaying it. That way we are not re-defining the
>profiles, we are ensuring that we can handle content encoded within the=
>profile and still by taking care of the this in the end of your decoder=
>chain you can protect the rest of the media framework from not yet
>supported frame-rates.
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------<= br> >Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------<= br> >Ericsson AB                 | P= hone  +46 10 7148287
>F=E4r=F6gatan 6                = | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------<= br> >
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/

--_000_634D3B5D82E3214DA9B6A36D5F50DB231C7BA8ESESSMB109ericsso_-- From nobody Sat Mar 8 07:28:51 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9681A028B for ; Sat, 8 Mar 2014 07:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 arHA_E23hRYS for ; Sat, 8 Mar 2014 07:28:47 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id E53331A0285 for ; Sat, 8 Mar 2014 07:28:46 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by BLUPR07MB001.namprd07.prod.outlook.com (10.255.209.35) with Microsoft SMTP Server (TLS) id 15.0.893.10; Sat, 8 Mar 2014 15:28:39 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.156]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.156]) with mapi id 15.00.0893.001; Sat, 8 Mar 2014 15:28:38 +0000 From: Stephan Wenger To: "payload@ietf.org" Thread-Topic: H.265 payload, tickets #2 through #8 Thread-Index: AQHPOuMTXN7R5stjjkatvsYCmZYh7A== Date: Sat, 8 Mar 2014 15:28:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.144.228.186] x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(53754006)(189002)(199002)(90146001)(4396001)(74706001)(74876001)(16236675002)(80976001)(83322001)(76176001)(69226001)(76796001)(56816005)(77096001)(81816001)(76786001)(47736001)(95666003)(65816001)(50986001)(47976001)(36756003)(87266001)(49866001)(81686001)(66066001)(80022001)(87936001)(76482001)(94316002)(86362001)(54356001)(59766001)(77982001)(53806001)(56776001)(74366001)(95416001)(85306002)(31966008)(94946001)(74662001)(2656002)(54316002)(74502001)(79102001)(83072002)(47446002)(93136001)(97186001)(81542001)(46102001)(63696002)(92726001)(92566001)(85852003)(97336001)(81342001)(93516002)(51856001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR07MB001; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:109.144.228.186; FPR:F957D49E.ACD18FEB.3D537F56.8EAAEF1.20135; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CF40E7A34379Estewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/qKAz9oXGQO7d10xf7eBrc4sxpZM Subject: [payload] H.265 payload, tickets #2 through #8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 15:28:49 -0000 --_000_CF40E7A34379Estewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As suggested in the payload session in London, I hereby ask if anyone objec= ts to the closing of tickets #2 through #9, all related to the H.265 payloa= d format, and all (I assert) either adequately addressed on the mailing lis= t months ago and in draft-ietf-payload-rtp-h265-02, found as not in scope, = or covered by other agreements reached on the mailing list or in London. I plan to close all such tickets with appropriate disposition around March = 15. If you want to keep a ticket open, please respond to the list. Thanks, Stephan --_000_CF40E7A34379Estewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <40940AE8DE26064A8AD47F5A75F669D6@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,
As suggested in the payload session in London, I hereby ask if anyone = objects to the closing of tickets #2 through #9, all related to the H.265 p= ayload format, and all (I assert) either adequately addressed on the mailin= g list months ago and in draft-ietf-payload-rtp-h265-02, found as not in scope, or covered by other agreements reached on the maili= ng list or in London.
I plan to close all such tickets with appropriate disposition around M= arch 15.  If you want to keep a ticket open, please respond to the lis= t.
Thanks,
Stephan
 
--_000_CF40E7A34379Estewesteweorg_-- From nobody Mon Mar 10 06:17:57 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40AA1A043E for ; Mon, 10 Mar 2014 06:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 FWtcZDjpM-Fl for ; Mon, 10 Mar 2014 06:17:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1E1A0447 for ; Mon, 10 Mar 2014 06:17:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-01-531dbb78524b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 89.D4.10875.87BBD135; Mon, 10 Mar 2014 14:17:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Mar 2014 14:17:43 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , Jonathan Lennox Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPMkf2CFY3DR2ikEyoFpWG3Tj1ZprP5Z+AgAFBKICAAE+AEIAAJbcAgACZfjCAAJawAIAADokAgABPWgCAAAU6gIAArnFggAC5jwCABbv2cA== Date: Mon, 10 Mar 2014 13:17:42 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C846A@ESESSMB109.ericsson.se> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7Fbtlgg5mrRS1OXdzHarF/8Xlm i0sXzzJZXG/cxG6xZPJNZosna44xO7B5vOjex+6xZMlPJo9FU58xeixe/57R48vlz2webc/u sAewRXHZpKTmZJalFunbJXBlNE9azVxwdiVjxbyFH9kbGFd3MHYxcnJICJhInLhxkR3CFpO4 cG89WxcjF4eQwCFGiVMbpjBCOEsYJU58mgBUxcHBJmAl8f1FBEiDiECIxPd7DSwgNcwCrxgl FqzexgaSEBawl7h3/wcjRJGDxOmp65kh7DqJ81MuM4PMYRFQlTi1pQYkzCvgLXH89G5WiF2b 2CRenTgF1sspECyxbvIssJmMArIS97/fYwGxmQXEJW49mc8EcbWAxJI955khbFGJl4//sULY ihIfX+1jhKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkb2 3MTMnPRyw02MwMg7uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFRJUDVUZM51ognaNOPn53XdVt4elfXmtnfLV7687Wa2U/Fin03ntmukls8M/7p9F/h amyzmqq2SX249+O01os/dYbn5Lax+ik1abxti7P/Yxj7aVOs/PTT16bnRcWliSxdmFt5WuiY vvnut02rZd911h1MYjSWU4raYK/2Lq6+4P/jTGUufxslluKMREMt5qLiRADqZQY1igIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Hi_kFnENtyzYCn4WL6kekaaKhNs Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:17:56 -0000 Thanks for your response Ye-Kui (sorry for my late reply), In my opinion it does make sense to distinguish between VCL data and non-VC= L data. Just because you have received all packets with the same timestamp = it is not necessarily the case that you can safely display the picture in t= hat access unit, e.g. if you in the next access unit receive a picture with= lower timestamp. Thus, in my opinion, the most useful information that you= can get from the marker bit is whether you have received all VCL NAL units= of a picture or not. Anyway, let me ask one question on the solution that you were suggesting.=20 " Marker bit (M): 1 bit Set for the last packet, carried in the current RTP stream, of an access un= it, in line with the normal use of the M bit in video formats, to allow an = efficient playout buffer handling." Would it be equivalent to: " Marker bit (M): 1 bit=20 Set when the next packet (if any), in the same RTP stream, has a different = timestamp than the current packet." Another question related to=20 Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed. It uses "SHOULD" from RFC 2119 but in the H.265 payload format "SHOULD" is = not used. Is the intended interpretation: " Marker bit (M): 1 bit SHOULD be set for the last packet..."? Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 6 mars 2014 22:52 To: Jonatan Samuelsson; Jonathan Lennox Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; Step= han Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC [Jonatan]: I don't think this text is really up to date with HEVC in the se= nse that the actual video frame (which in my opinion, for the HEVC case, is= the VCL NAL units of an access unit) can be completely received even thoug= h there are more packet(s) that are following with the same time stamp. I don't understand the above sentence. I think the receiver can only conclu= de that an access unit is completely received only when no more packets wit= h the same timestamp is coming soon. For other parts of your new message below: Any data, including non-VCL data= , associated with a picture in the bitstream is supposed to be used by the = decoder side (not just the decoder) to do something that can be helpful in = processing (decoding including error concealment and so on, display, etc.) = of the decoded picture, even not needed for NORMATIVE decoding of the pictu= re. Thus, only when the decoder side receives all data associated with a pi= cture, can it be sure that no more useful information may come before sent = the decoded picture to the display. Therefore, we should not change the wor= ding from "the last NAL unit" to "the last VCL NAL unit". Also, without mak= ing the setting to be stream specific, as I suggested and Jonathan agreed, = multi-layer extensions will be problematic. BR, YK -----Original Message----- From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 Sent: Thursday, March 06, 2014 2:59 AM To: Wang, Ye-Kui; Jonathan Lennox Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; Step= han Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thanks Ye-Kui and Jonathan for your responses. Regarding Section 5 of RFC 3551: Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed. I don't think this text is really up to date with HEVC in the sense that th= e actual video frame (which in my opinion, for the HEVC case, is the VCL NA= L units of an access unit) can be completely received even though there are= more packet(s) that are following with the same time stamp. Since none of the suffix SEI messages has any normative effect on the outpu= t of the decoder, why should it be necessary to wait for example for a deco= ded_picture_hash SEI before detecting that a frame can be displayed? Ye-Kui, you earlier wrote: "Anyway, I admitted that the current semantics are not fully future-proof r= egarding suffix SEI messages. In looking into future multi-layer extensions= , it appears that simply changing the wording from "last NAL unit" to "last= VCL NAL unit" is not good enough." But if (as I initially suggested) the change is from "last NAL unit of an a= ccess unit" to "last VCL NAL unit of a picture" I guess it could work also = for future extensions in which there will be several pictures in the same a= ccess unit. Or do you see a problem here? Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 6 mars 2014 01:24 To: Jonathan Lennox Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Agree to make the intention clearer, e.g. by adding a note. On your last question: I think you are right, a non-VCL suffix NAL unit, e.= g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_la= yer_id equal to 0, and thus in MST the last NAL unit of an access unit may = actually be carried in the last packet from the "base" RTP stream. And yes = this actually does not matter for using of the marker bit for the purpose d= escribed below.=20 BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Wednesday, March 05, 2014 4:05 PM To: Wang, Ye-Kui Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h265@= tools.ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC This seems correct to me. I would suggest, however, explicitly pointing ou= t that in MST mode, if an access unit appears in multiple packet streams, t= he marker bit is set on each packet stream's last packet of the access unit= . I think this definition works even when DONs are in use (when sprop-depack-= buf-nalus is > 0), since an AP can only contain packets from a single acces= s unit. If packets from different access units are interleaved (in RTP ord= er) using DON, the packet stream will look odd to a naive RTP analysis, but= I believe the marker bit will still be useful, allowing low-delay decoders= to flush complete access units out of the de-packetization buffer early. Ye-Kui, a question about your comment, though: are we sure that the final p= acket of the access unit will in fact always be the final packet of the hig= hest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able to= split MST streams by nuh_layer_id. How will the nuh_layer_id be set for t= railing SEIs in such streams? If it's set to 0, then the final packet of t= he access unit will in fact be sent in a lower layer. I don't think this a= ctually matters, especially since MST streams will use DON, but we should b= e careful about our logic. On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: > I did a bit of search on the usage of the marker bit for video, and the m= ost relevant description I found was the following paragraph in Section 5 o= f RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > So the key usage of the marker bit is that in some low-delay applications= , output/display of a picture can be done before receiving an RTP packet wi= th a different/greater timestamp. Since non-VCL NAL unit should have the sa= me timestamp as the associated picture, thus I think we should not use the = wording of "last VCL NAL unit" in determining the setting of the marker bit= . >=20 > To make the semantics extensible or future-proof for multi-layer extensio= ns, I think we should change it to be RTP stream (or equivalently packet st= ream) specific, and each receiver can just look at the marker bits of the p= ackets from the highest RTP stream for the usage. And this will also resolv= e the issue of requiring some entities to change the marker bit in sub-laye= r scalability usage as Jonaton raised.=20 >=20 > In other words, the normative semantics are to be changed as follows: >=20 > Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling. >=20 > Please let me know if there is any concern with such a change (and note t= hat we would align the terminology of RTP stream with other drafts, e.g. th= e Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing = comments). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui > Sent: Wednesday, March 05, 2014 10:29 AM > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Something should be done to the HEVC spec to make it clearer for the deco= ded picture hash SEI message, like that it shall not be nested and what the= values of LayerId and LId should be, or allow add to the list of nestable = SEI message. In any case, it does not make sense to me to put a greater val= ue of TId than its associated picture. On user_data_registered_itu_t_t35 an= d user_data_unregistered suffix SEI messages, only if it is defined by some= application then it may make sense to put a greater value of TId than its = associated picture - currently I have not seen any such use being defined a= nywhere. >=20 > Anyway, I admitted that the current semantics are not fully future-proof = regarding suffix SEI messages. In looking into future multi-layer extension= s, it appears that simply changing the wording from "last NAL unit" to "las= t VCL NAL unit" is not good enough. We might need to specify the semantics = of the marker bit to be RTP stream specific. To make sure whether such a ch= ange is OK, we also need to check against the usage of the marker bit. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, March 05, 2014 1:07 AM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks for your response Ye-Kui, >=20 > As far as I understand, out of the 6 SEI messages that have so far been d= efined in the HEVC spec as possible to use as suffixes (filler_payload, use= r_data_registered_itu_t_t35, user_data_unregistered, progressive_refinement= _segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that = are not required to have the same TId as the VCL NAL units of the access un= it: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pic= ture_hash since their payloadType numbers (4, 5 and 132) are not included i= n the list: >=20 > "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, 1= 6, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages = that have payloadType not equal to 0, 1, or 130, and that are allowed to be= nested SEI messages), the SEI NAL unit containing the non-nested SEI messa= ge shall have TemporalId equal to the TemporalId of the access unit contain= ing the SEI NAL unit." >=20 > Maybe it's a mistake in the HEVC spec that 132 is not in this list, but I= think the problem would exist even if was. An encoder that (for whatever r= eason) puts in user_data_registered_itu_t_t35 or user_data_unregistered suf= fix SEI messages with higher TId would put a MANE in a difficult situation.= =20 >=20 > I also think we should consider future extensions of HEVC (i.e. SHVC and = MV-HEVC) in which an access unit may contain many pictures with different v= alues of nuh_layer_id. If the marker bit is set for the last packet of an a= ccess unit, then once again all the marker bits will end up in the highest = layer (stream) and a MANE would have to change the value of marker bits as = soon as not all layers (streams) are forwarded. >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 5 mars 2014 01:20 > To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hmm, a decoded picture hash SEI message applies to (and is associated wit= h) the preceding decoding picture in decoding order and thus the TId of the= containing suffix SEI NAL unit should be set equal to the TId of the assoc= iated picture. Thus in the example, for the suffix SEI NAL unit containing = the decoded picture hash SEI message for the first encoded picture should b= e assigned TId equal to 0.=20 >=20 > According to the HEVC spec, currently the following SEI messages are or c= an be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35, = user_data_unregistered, progressive_refinement_segment_end, post_filter_hin= t, and decoded_picture_hash. Among these, I think all of the "specified" SE= I messages (i.e. the above list excluding user_data_registered_itu_t_t35, u= ser_data_unregistered) contained in a suffix SEI NAL unit would apply to th= e preceding decoded picture in decoder order and should have the same TId a= s the associated picture. The only SEI messages that can have a greater TId= value than the containing access unit are the three SEI message that can c= arry HRD information, i.e., buffering_period, pic_timing, and decoding_unit= _info, but these can only be prefix SEI messages. >=20 > Of course, in theory, future versions of HEVC or some extensions (even de= fined by an application spec) could define suffix SEI messages that can hav= e a greater TId value than the containing access unit. In that case, what y= ou described could be meaningful, and indeed if a receiver receives the "ba= se sub-layer" stream, some entity would have to set the marker bit of those= packets containing the last NAL unit of an access unit for that stream, ac= cording to the current semantics. >=20 > However, if we change the wording to the last VCL NAL unit as you suggest= ed, and in case a suffix SEI NAL unit of picture A is not carried the packe= t containing the last VCL NAL unit if the access unit, would the usage of t= he marker bit be affected, e.g. in playout buffer handling? If the answer i= s no, then there should be no problem to do the change. >=20 > Basically the situation is as follows. There is no concrete problem now. = However, there can be a potential problem in the future if a suffix SEI mes= sage is defined and can have a greater TId value than the containing access= unit. If the suggested change does not affect the usage of the bit, we sho= uld do the change now to make the design future-proof. So the key question = is whether the suggest change would affect the usage of the bit.=20 >=20 > Does anyone know how the marker bit is used in playout buffering handling= ? An explanation or a pointer would be greatly appreciated. >=20 > BR, YK >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Tuesday, March 04, 2014 1:28 PM > To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org; stewe@stewe.org > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Dear Ye-Kui, >=20 > Let me try to make the example more specific (and then also see if I have= understood the multi-stream transmission concept correctly). >=20 > Assume that the sender puts all NAL units with TId 0 in one RTP stream (s= tream A) and all NAL units with TId 1 in another RTP stream (stream B). Now= for the first encoded picture the VCL NAL units are assigned TId 0 and the= n a decoded picture hash SEI message is created in the same access unit but= is given TId 1. Then the marker bit will be set on the packet containing t= he decoded picture hash SEI message which is put in stream B. If this schem= e is applied for all access units, stream A will not contain any packets wi= th the marker bit set since these are all put in stream B. A MANE that only= wants to forward stream A to a receiver would be required to perform analy= sis (and probably introduce delay) in order to correctly change the marker = bit on the "new" last packet of the access unit. >=20 > Is that correct, or have I misinterpreted anything? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 4 mars 2014 18:21 > To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; st= ewe@stewe.org; Jonatan Samuelsson > Cc: payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Hi Jonatan, >=20 > I do not fully understand the following example: >=20 > "However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units).= For that case I guess there will be one RTP stream (corresponding to TId 0= ) completely without any marker bit set, right?" >=20 > Could you please check whether it can be clarified a bit? >=20 > BR, YK >=20 > -----Original Message----- > From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 > Sent: Monday, March 03, 2014 2:11 PM > To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stewe= .org; jonatan.samuelsson@ericsson.com > Cc: payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > #10: Marker bit in H.265/HEVC >=20 >=20 > Comment (by jonatan.samuelsson@ericsson.com): >=20 > Thanks Stefan for the comments and the example. It is exactly this kind o= f cases I'm concerned about but I wouldn't characterize them as exotic. Fo= r conversational applications it is natural to operate in *very* low delay= mode (i.e. not buffering packets before forwarding them) and having post-= picture SEI packetized in their own packets is the only option as soon as= the VCL NAL units are fragmented since FUs cannot be aggregated. Having t= o introduce slices just to avoid FUs and thereby being able to aggregate S= EI messages with VCL NAL units does not sound like a compelling alternativ= e. >=20 > The most reasonable solution for this case is probably to just not perfor= m thinning by removing the SEI messages since they are typically not very = large in the first place. >=20 > However, as far as I understand, it is allowed for an encoder to create a= bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for = all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). > For that case I guess there will be one RTP stream (corresponding to TId > 0) completely without any marker bit set, right? >=20 > --=20 > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Mon Mar 10 09:13:54 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CA71A052E for ; Mon, 10 Mar 2014 09:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.169 X-Spam-Level: * X-Spam-Status: No, score=1.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] 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 7Gluvnte8wMM for ; Mon, 10 Mar 2014 09:13:37 -0700 (PDT) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3A1A0527 for ; Mon, 10 Mar 2014 09:13:35 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/10/2014 12:13:27 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-84/SG:2 3/10/2014 12:12:37 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.851246 p=-0.979317 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/10/2014 12:13:14 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 104610648; Mon, 10 Mar 2014 12:13:27 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Mon, 10 Mar 2014 11:13:26 -0500 From: Jonathan Lennox To: Jonatan Samuelsson Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQIAAuiiA//+fAJCAARe6gIAAtoEAgAWo3ACAADEbgA== Date: Mon, 10 Mar 2014 16:13:25 +0000 Message-ID: <7975B7E5-D690-4F0A-8DDD-1AE5CA13FAB2@vidyo.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C846A@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB231C846A@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/gEIVELR3af8WG7c3GzYJzfgct2Y Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:13:43 -0000 On Mar 10, 2014, at 9:17 AM, Jonatan Samuelsson wrote: > Thanks for your response Ye-Kui (sorry for my late reply), >=20 > In my opinion it does make sense to distinguish between VCL data and non-= VCL data. Just because you have received all packets with the same timestam= p it is not necessarily the case that you can safely display the picture in= that access unit, e.g. if you in the next access unit receive a picture wi= th lower timestamp. Thus, in my opinion, the most useful information that y= ou can get from the marker bit is whether you have received all VCL NAL uni= ts of a picture or not. I disagree. I don=92t think VCL and non-VCL NAL units should be distinguis= hed for the marker bit. Presumably any encoder which is sending suffix NAL= units (and I would expect them to be rare) is doing so because it believes= they=92ll be useful for the decoders to fully decode the access unit. If a later packet contains an earlier timestamp, you=92re either doing fram= e reordering (in which case it *is* safe to decode the earlier frame in dec= ode order) or else using DON (in which case you need to track DON values ra= ther than sequence numbers). The marker bit =97 by definition =97 can=92t carry more than one bit of dat= a, so there=92s no way to tell just from that bit whether it=92s safe to de= code a frame given arbitrary earlier packet loss. Without packet loss, it = should always be possible to decode an access unit when the marker bit is r= eceived, if all earlier access units in decode order (since the last refres= h point) have already been decoded. > Anyway, let me ask one question on the solution that you were suggesting.= =20 >=20 > " Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling." >=20 > Would it be equivalent to: >=20 > " Marker bit (M): 1 bit=20 > Set when the next packet (if any), in the same RTP stream, has a differen= t timestamp than the current packet.=94 They are equivalent when not using DON (or more specifically when sprop-dep= ack-buf-nalus > 0). When you are using DON, they are different; and I thin= k the original definition is more useful. > Another question related to=20 >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > It uses "SHOULD" from RFC 2119 but in the H.265 payload format "SHOULD" i= s not used. Is the intended interpretation: >=20 > " Marker bit (M): 1 bit > SHOULD be set for the last packet=85"? Bare SHOULDs (i.e., a statement that says something SHOULD be done, without= explaining the circumstances in which an implementation would not do it) a= re generally considered undesirable in IETF standards these days. (This is= a stylistic change since RFC 3551 was written.) What do you consider the = circumstances in which it would be appropriate for an H.265 RTP implementat= ion not to set the marker bit? > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 6 mars 2014 22:52 > To: Jonatan Samuelsson; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; St= ephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > [Jonatan]: I don't think this text is really up to date with HEVC in the = sense that the actual video frame (which in my opinion, for the HEVC case, = is the VCL NAL units of an access unit) can be completely received even tho= ugh there are more packet(s) that are following with the same time stamp. >=20 > I don't understand the above sentence. I think the receiver can only conc= lude that an access unit is completely received only when no more packets w= ith the same timestamp is coming soon. >=20 > For other parts of your new message below: Any data, including non-VCL da= ta, associated with a picture in the bitstream is supposed to be used by th= e decoder side (not just the decoder) to do something that can be helpful i= n processing (decoding including error concealment and so on, display, etc.= ) of the decoded picture, even not needed for NORMATIVE decoding of the pic= ture. Thus, only when the decoder side receives all data associated with a = picture, can it be sure that no more useful information may come before sen= t the decoded picture to the display. Therefore, we should not change the w= ording from "the last NAL unit" to "the last VCL NAL unit". Also, without m= aking the setting to be stream specific, as I suggested and Jonathan agreed= , multi-layer extensions will be problematic. >=20 > BR, YK >=20 >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Thursday, March 06, 2014 2:59 AM > To: Wang, Ye-Kui; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; St= ephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks Ye-Kui and Jonathan for your responses. >=20 > Regarding Section 5 of RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > I don't think this text is really up to date with HEVC in the sense that = the actual video frame (which in my opinion, for the HEVC case, is the VCL = NAL units of an access unit) can be completely received even though there a= re more packet(s) that are following with the same time stamp. >=20 > Since none of the suffix SEI messages has any normative effect on the out= put of the decoder, why should it be necessary to wait for example for a de= coded_picture_hash SEI before detecting that a frame can be displayed? >=20 > Ye-Kui, you earlier wrote: > "Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough." >=20 > But if (as I initially suggested) the change is from "last NAL unit of an= access unit" to "last VCL NAL unit of a picture" I guess it could work als= o for future extensions in which there will be several pictures in the same= access unit. Or do you see a problem here? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 > Sent: den 6 mars 2014 01:24 > To: Jonathan Lennox > Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; Stephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Agree to make the intention clearer, e.g. by adding a note. >=20 > On your last question: I think you are right, a non-VCL suffix NAL unit, = e.g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_= layer_id equal to 0, and thus in MST the last NAL unit of an access unit ma= y actually be carried in the last packet from the "base" RTP stream. And ye= s this actually does not matter for using of the marker bit for the purpose= described below.=20 >=20 > BR, YK >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 > Sent: Wednesday, March 05, 2014 4:05 PM > To: Wang, Ye-Kui > Cc: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h26= 5@tools.ietf.org; Stephan Wenger; payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > This seems correct to me. I would suggest, however, explicitly pointing = out that in MST mode, if an access unit appears in multiple packet streams,= the marker bit is set on each packet stream's last packet of the access un= it. >=20 > I think this definition works even when DONs are in use (when sprop-depac= k-buf-nalus is > 0), since an AP can only contain packets from a single acc= ess unit. If packets from different access units are interleaved (in RTP o= rder) using DON, the packet stream will look odd to a naive RTP analysis, b= ut I believe the marker bit will still be useful, allowing low-delay decode= rs to flush complete access units out of the de-packetization buffer early. >=20 > Ye-Kui, a question about your comment, though: are we sure that the final= packet of the access unit will in fact always be the final packet of the h= ighest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able = to split MST streams by nuh_layer_id. How will the nuh_layer_id be set for= trailing SEIs in such streams? If it's set to 0, then the final packet of= the access unit will in fact be sent in a lower layer. I don't think this= actually matters, especially since MST streams will use DON, but we should= be careful about our logic. >=20 >=20 >=20 > On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: >=20 >> I did a bit of search on the usage of the marker bit for video, and the = most relevant description I found was the following paragraph in Section 5 = of RFC 3551: >>=20 >> Most of these video encodings also specify that the marker bit of the >> RTP header SHOULD be set to one in the last packet of a video frame >> and otherwise set to zero. Thus, it is not necessary to wait for a >> following packet with a different timestamp to detect that a new >> frame should be displayed. >>=20 >> So the key usage of the marker bit is that in some low-delay application= s, output/display of a picture can be done before receiving an RTP packet w= ith a different/greater timestamp. Since non-VCL NAL unit should have the s= ame timestamp as the associated picture, thus I think we should not use the= wording of "last VCL NAL unit" in determining the setting of the marker bi= t. >>=20 >> To make the semantics extensible or future-proof for multi-layer extensi= ons, I think we should change it to be RTP stream (or equivalently packet s= tream) specific, and each receiver can just look at the marker bits of the = packets from the highest RTP stream for the usage. And this will also resol= ve the issue of requiring some entities to change the marker bit in sub-lay= er scalability usage as Jonaton raised.=20 >>=20 >> In other words, the normative semantics are to be changed as follows: >>=20 >> Marker bit (M): 1 bit >> Set for the last packet, carried in the current RTP stream, of an access= unit, in line with the normal use of the M bit in video formats, to allow = an efficient playout buffer handling. >>=20 >> Please let me know if there is any concern with such a change (and note = that we would align the terminology of RTP stream with other drafts, e.g. t= he Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing= comments). >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Ku= i >> Sent: Wednesday, March 05, 2014 10:29 AM >> To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h2= 65@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Something should be done to the HEVC spec to make it clearer for the dec= oded picture hash SEI message, like that it shall not be nested and what th= e values of LayerId and LId should be, or allow add to the list of nestable= SEI message. In any case, it does not make sense to me to put a greater va= lue of TId than its associated picture. On user_data_registered_itu_t_t35 a= nd user_data_unregistered suffix SEI messages, only if it is defined by som= e application then it may make sense to put a greater value of TId than its= associated picture - currently I have not seen any such use being defined = anywhere. >>=20 >> Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough. We might need to specify the semantics= of the marker bit to be RTP stream specific. To make sure whether such a c= hange is OK, we also need to check against the usage of the marker bit. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 >> Sent: Wednesday, March 05, 2014 1:07 AM >> To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@too= ls.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Thanks for your response Ye-Kui, >>=20 >> As far as I understand, out of the 6 SEI messages that have so far been = defined in the HEVC spec as possible to use as suffixes (filler_payload, us= er_data_registered_itu_t_t35, user_data_unregistered, progressive_refinemen= t_segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that= are not required to have the same TId as the VCL NAL units of the access u= nit: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pi= cture_hash since their payloadType numbers (4, 5 and 132) are not included = in the list: >>=20 >> "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, = 16, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages= that have payloadType not equal to 0, 1, or 130, and that are allowed to b= e nested SEI messages), the SEI NAL unit containing the non-nested SEI mess= age shall have TemporalId equal to the TemporalId of the access unit contai= ning the SEI NAL unit." >>=20 >> Maybe it's a mistake in the HEVC spec that 132 is not in this list, but = I think the problem would exist even if was. An encoder that (for whatever = reason) puts in user_data_registered_itu_t_t35 or user_data_unregistered su= ffix SEI messages with higher TId would put a MANE in a difficult situation= .=20 >>=20 >> I also think we should consider future extensions of HEVC (i.e. SHVC and= MV-HEVC) in which an access unit may contain many pictures with different = values of nuh_layer_id. If the marker bit is set for the last packet of an = access unit, then once again all the marker bits will end up in the highest= layer (stream) and a MANE would have to change the value of marker bits as= soon as not all layers (streams) are forwarded. >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 >> Sent: den 5 mars 2014 01:20 >> To: Jonatan Samuelsson; payload issue tracker; draft-ietf-payload-rtp-h2= 65@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hmm, a decoded picture hash SEI message applies to (and is associated wi= th) the preceding decoding picture in decoding order and thus the TId of th= e containing suffix SEI NAL unit should be set equal to the TId of the asso= ciated picture. Thus in the example, for the suffix SEI NAL unit containing= the decoded picture hash SEI message for the first encoded picture should = be assigned TId equal to 0.=20 >>=20 >> According to the HEVC spec, currently the following SEI messages are or = can be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35,= user_data_unregistered, progressive_refinement_segment_end, post_filter_hi= nt, and decoded_picture_hash. Among these, I think all of the "specified" S= EI messages (i.e. the above list excluding user_data_registered_itu_t_t35, = user_data_unregistered) contained in a suffix SEI NAL unit would apply to t= he preceding decoded picture in decoder order and should have the same TId = as the associated picture. The only SEI messages that can have a greater TI= d value than the containing access unit are the three SEI message that can = carry HRD information, i.e., buffering_period, pic_timing, and decoding_uni= t_info, but these can only be prefix SEI messages. >>=20 >> Of course, in theory, future versions of HEVC or some extensions (even d= efined by an application spec) could define suffix SEI messages that can ha= ve a greater TId value than the containing access unit. In that case, what = you described could be meaningful, and indeed if a receiver receives the "b= ase sub-layer" stream, some entity would have to set the marker bit of thos= e packets containing the last NAL unit of an access unit for that stream, a= ccording to the current semantics. >>=20 >> However, if we change the wording to the last VCL NAL unit as you sugges= ted, and in case a suffix SEI NAL unit of picture A is not carried the pack= et containing the last VCL NAL unit if the access unit, would the usage of = the marker bit be affected, e.g. in playout buffer handling? If the answer = is no, then there should be no problem to do the change. >>=20 >> Basically the situation is as follows. There is no concrete problem now.= However, there can be a potential problem in the future if a suffix SEI me= ssage is defined and can have a greater TId value than the containing acces= s unit. If the suggested change does not affect the usage of the bit, we sh= ould do the change now to make the design future-proof. So the key question= is whether the suggest change would affect the usage of the bit.=20 >>=20 >> Does anyone know how the marker bit is used in playout buffering handlin= g? An explanation or a pointer would be greatly appreciated. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 >> Sent: Tuesday, March 04, 2014 1:28 PM >> To: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@too= ls.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Dear Ye-Kui, >>=20 >> Let me try to make the example more specific (and then also see if I hav= e understood the multi-stream transmission concept correctly). >>=20 >> Assume that the sender puts all NAL units with TId 0 in one RTP stream (= stream A) and all NAL units with TId 1 in another RTP stream (stream B). No= w for the first encoded picture the VCL NAL units are assigned TId 0 and th= en a decoded picture hash SEI message is created in the same access unit bu= t is given TId 1. Then the marker bit will be set on the packet containing = the decoded picture hash SEI message which is put in stream B. If this sche= me is applied for all access units, stream A will not contain any packets w= ith the marker bit set since these are all put in stream B. A MANE that onl= y wants to forward stream A to a receiver would be required to perform anal= ysis (and probably introduce delay) in order to correctly change the marker= bit on the "new" last packet of the access unit. >>=20 >> Is that correct, or have I misinterpreted anything? >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 >> Sent: den 4 mars 2014 18:21 >> To: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; s= tewe@stewe.org; Jonatan Samuelsson >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hi Jonatan, >>=20 >> I do not fully understand the following example: >>=20 >> "However, as far as I understand, it is allowed for an encoder to create= a bitstream with two temporal sub-layers (every second picture with TId 0= and every second picture with TId 1) but put post-picture SEI messages fo= r all access units in temporal layer 1 (also for access units in which the= picture has TId 0, as a hint of the relative importance of the NAL units)= . For that case I guess there will be one RTP stream (corresponding to TId = 0) completely without any marker bit set, right?" >>=20 >> Could you please check whether it can be clarified a bit? >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org]=20 >> Sent: Monday, March 03, 2014 2:11 PM >> To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui; stewe@stew= e.org; jonatan.samuelsson@ericsson.com >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> #10: Marker bit in H.265/HEVC >>=20 >>=20 >> Comment (by jonatan.samuelsson@ericsson.com): >>=20 >> Thanks Stefan for the comments and the example. It is exactly this kind = of cases I'm concerned about but I wouldn't characterize them as exotic. F= or conversational applications it is natural to operate in *very* low dela= y mode (i.e. not buffering packets before forwarding them) and having post= - picture SEI packetized in their own packets is the only option as soon a= s the VCL NAL units are fragmented since FUs cannot be aggregated. Having = to introduce slices just to avoid FUs and thereby being able to aggregate = SEI messages with VCL NAL units does not sound like a compelling alternati= ve. >>=20 >> The most reasonable solution for this case is probably to just not perfo= rm thinning by removing the SEI messages since they are typically not very= large in the first place. >>=20 >> However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). >> For that case I guess there will be one RTP stream (corresponding to TId >> 0) completely without any marker bit set, right? >>=20 >> --=20 >> -------------------------------------+---------------------------------- >> -------------------------------------+--- >> Reporter: | Owner: draft-ietf-payload- >> jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rtp-h265 | Version: 2.0 >> Severity: - | Resolution: >> Keywords: | >> -------------------------------------+---------------------------------- >> -------------------------------------+--- >>=20 >> Ticket URL: >> payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >=20 From nobody Mon Mar 10 09:29:52 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8F81A055D for ; Mon, 10 Mar 2014 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 2GYqyuDcvfS7 for ; Mon, 10 Mar 2014 09:29:40 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id C41901A052E for ; Mon, 10 Mar 2014 09:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394468975; x=1426004975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eHv1Hizsaw/m5UvJmwvR1dRZ4gyHOYjWgu+iUrwfMAs=; b=eltPq4V4RIBMbpKErjoWH5qNFU7INWDuOiRFWuqZs+MFXLfkCn0xOhcX LFb0aToW4y5GdYC0e7zEMo/zTf3pBSVVoOw1EbU2AoMte3TVC09wfpvxC L43FKtmFwtm2hrBBnOaS9EIIY2KML4wJBK/8OLNlkbo3UplfLTRFgzBGS E=; X-IronPort-AV: E=McAfee;i="5400,1158,7372"; a="60330920" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 10 Mar 2014 09:29:35 -0700 X-IronPort-AV: E=Sophos;i="4.97,624,1389772800"; d="scan'208";a="697079500" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Mar 2014 09:29:35 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Mon, 10 Mar 2014 09:29:34 -0700 From: "Wang, Ye-Kui" To: Jonathan Lennox , Jonatan Samuelsson Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPNy2E9/hww0j0CUugS6BNO6oybZrRLN1AgADMMwD//53j0IABJUUAgAASsHCAAAyLQIAAuiiA//+fAJCAATlBgIAALTaggAYyJwCAADEYgP//jXRw Date: Mon, 10 Mar 2014 16:29:33 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387DBF7C@nasanexd02f.na.qualcomm.com> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C846A@ESESSMB109.ericsson.se> <7975B7E5-D690-4F0A-8DDD-1AE5CA13FAB2@vidyo.com> In-Reply-To: <7975B7E5-D690-4F0A-8DDD-1AE5CA13FAB2@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/GeHZxQXbvVZiSCK8OqLlK2tTp_Q Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:29:45 -0000 I have basically the same opinion here as Jonathan. Just one aspect regarding Jonatan's following comment: > Just because you have received all packets with the same timestamp it is = not necessarily the case that you can safely display the picture in that ac= cess unit, e.g. if you in the next access unit receive a picture with lower= timestamp. Thus, in my opinion, the most useful information that you can g= et from the marker bit is whether you have received all VCL NAL units of a = picture or not. [YK] I think your first sentence is correct, but I don't see the logic that= this true statement can lead to the conclusion that "the most useful infor= mation that you can get from the marker bit is whether you have received al= l VCL NAL units of a picture or not". To me, if you have reordering in enco= ding, then you are not doing low-delay, and then the marker bit is less use= ful than in low-delay where there is no reordering in encoding. BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Monday, March 10, 2014 9:13 AM To: Jonatan Samuelsson Cc: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tools.= ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC On Mar 10, 2014, at 9:17 AM, Jonatan Samuelsson wrote: > Thanks for your response Ye-Kui (sorry for my late reply), >=20 > In my opinion it does make sense to distinguish between VCL data and non-= VCL data. Just because you have received all packets with the same timestam= p it is not necessarily the case that you can safely display the picture in= that access unit, e.g. if you in the next access unit receive a picture wi= th lower timestamp. Thus, in my opinion, the most useful information that y= ou can get from the marker bit is whether you have received all VCL NAL uni= ts of a picture or not. I disagree. I don't think VCL and non-VCL NAL units should be distinguishe= d for the marker bit. Presumably any encoder which is sending suffix NAL u= nits (and I would expect them to be rare) is doing so because it believes t= hey'll be useful for the decoders to fully decode the access unit. If a later packet contains an earlier timestamp, you're either doing frame = reordering (in which case it *is* safe to decode the earlier frame in decod= e order) or else using DON (in which case you need to track DON values rath= er than sequence numbers). The marker bit - by definition - can't carry more than one bit of data, so = there's no way to tell just from that bit whether it's safe to decode a fra= me given arbitrary earlier packet loss. Without packet loss, it should alw= ays be possible to decode an access unit when the marker bit is received, i= f all earlier access units in decode order (since the last refresh point) h= ave already been decoded. > Anyway, let me ask one question on the solution that you were suggesting.= =20 >=20 > " Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling." >=20 > Would it be equivalent to: >=20 > " Marker bit (M): 1 bit > Set when the next packet (if any), in the same RTP stream, has a differen= t timestamp than the current packet." They are equivalent when not using DON (or more specifically when sprop-dep= ack-buf-nalus > 0). When you are using DON, they are different; and I thin= k the original definition is more useful. > Another question related to >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > It uses "SHOULD" from RFC 2119 but in the H.265 payload format "SHOULD" i= s not used. Is the intended interpretation: >=20 > " Marker bit (M): 1 bit > SHOULD be set for the last packet..."? Bare SHOULDs (i.e., a statement that says something SHOULD be done, without= explaining the circumstances in which an implementation would not do it) a= re generally considered undesirable in IETF standards these days. (This is= a stylistic change since RFC 3551 was written.) What do you consider the = circumstances in which it would be appropriate for an H.265 RTP implementat= ion not to set the marker bit? > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > Sent: den 6 mars 2014 22:52 > To: Jonatan Samuelsson; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org;=20 > Stephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > [Jonatan]: I don't think this text is really up to date with HEVC in the = sense that the actual video frame (which in my opinion, for the HEVC case, = is the VCL NAL units of an access unit) can be completely received even tho= ugh there are more packet(s) that are following with the same time stamp. >=20 > I don't understand the above sentence. I think the receiver can only conc= lude that an access unit is completely received only when no more packets w= ith the same timestamp is coming soon. >=20 > For other parts of your new message below: Any data, including non-VCL da= ta, associated with a picture in the bitstream is supposed to be used by th= e decoder side (not just the decoder) to do something that can be helpful i= n processing (decoding including error concealment and so on, display, etc.= ) of the decoded picture, even not needed for NORMATIVE decoding of the pic= ture. Thus, only when the decoder side receives all data associated with a = picture, can it be sure that no more useful information may come before sen= t the decoded picture to the display. Therefore, we should not change the w= ording from "the last NAL unit" to "the last VCL NAL unit". Also, without m= aking the setting to be stream specific, as I suggested and Jonathan agreed= , multi-layer extensions will be problematic. >=20 > BR, YK >=20 >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] > Sent: Thursday, March 06, 2014 2:59 AM > To: Wang, Ye-Kui; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org;=20 > Stephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks Ye-Kui and Jonathan for your responses. >=20 > Regarding Section 5 of RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > I don't think this text is really up to date with HEVC in the sense that = the actual video frame (which in my opinion, for the HEVC case, is the VCL = NAL units of an access unit) can be completely received even though there a= re more packet(s) that are following with the same time stamp. >=20 > Since none of the suffix SEI messages has any normative effect on the out= put of the decoder, why should it be necessary to wait for example for a de= coded_picture_hash SEI before detecting that a frame can be displayed? >=20 > Ye-Kui, you earlier wrote: > "Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough." >=20 > But if (as I initially suggested) the change is from "last NAL unit of an= access unit" to "last VCL NAL unit of a picture" I guess it could work als= o for future extensions in which there will be several pictures in the same= access unit. Or do you see a problem here? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > Sent: den 6 mars 2014 01:24 > To: Jonathan Lennox > Cc: Jonatan Samuelsson; payload issue tracker;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org; Stephan Wenger;=20 > payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Agree to make the intention clearer, e.g. by adding a note. >=20 > On your last question: I think you are right, a non-VCL suffix NAL unit, = e.g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_= layer_id equal to 0, and thus in MST the last NAL unit of an access unit ma= y actually be carried in the last packet from the "base" RTP stream. And ye= s this actually does not matter for using of the marker bit for the purpose= described below.=20 >=20 > BR, YK >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Wednesday, March 05, 2014 4:05 PM > To: Wang, Ye-Kui > Cc: Jonatan Samuelsson; payload issue tracker;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org; Stephan Wenger;=20 > payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > This seems correct to me. I would suggest, however, explicitly pointing = out that in MST mode, if an access unit appears in multiple packet streams,= the marker bit is set on each packet stream's last packet of the access un= it. >=20 > I think this definition works even when DONs are in use (when sprop-depac= k-buf-nalus is > 0), since an AP can only contain packets from a single acc= ess unit. If packets from different access units are interleaved (in RTP o= rder) using DON, the packet stream will look odd to a naive RTP analysis, b= ut I believe the marker bit will still be useful, allowing low-delay decode= rs to flush complete access units out of the de-packetization buffer early. >=20 > Ye-Kui, a question about your comment, though: are we sure that the final= packet of the access unit will in fact always be the final packet of the h= ighest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able = to split MST streams by nuh_layer_id. How will the nuh_layer_id be set for= trailing SEIs in such streams? If it's set to 0, then the final packet of= the access unit will in fact be sent in a lower layer. I don't think this= actually matters, especially since MST streams will use DON, but we should= be careful about our logic. >=20 >=20 >=20 > On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: >=20 >> I did a bit of search on the usage of the marker bit for video, and the = most relevant description I found was the following paragraph in Section 5 = of RFC 3551: >>=20 >> Most of these video encodings also specify that the marker bit of=20 >> the RTP header SHOULD be set to one in the last packet of a video=20 >> frame and otherwise set to zero. Thus, it is not necessary to wait=20 >> for a following packet with a different timestamp to detect that a=20 >> new frame should be displayed. >>=20 >> So the key usage of the marker bit is that in some low-delay application= s, output/display of a picture can be done before receiving an RTP packet w= ith a different/greater timestamp. Since non-VCL NAL unit should have the s= ame timestamp as the associated picture, thus I think we should not use the= wording of "last VCL NAL unit" in determining the setting of the marker bi= t. >>=20 >> To make the semantics extensible or future-proof for multi-layer extensi= ons, I think we should change it to be RTP stream (or equivalently packet s= tream) specific, and each receiver can just look at the marker bits of the = packets from the highest RTP stream for the usage. And this will also resol= ve the issue of requiring some entities to change the marker bit in sub-lay= er scalability usage as Jonaton raised.=20 >>=20 >> In other words, the normative semantics are to be changed as follows: >>=20 >> Marker bit (M): 1 bit >> Set for the last packet, carried in the current RTP stream, of an access= unit, in line with the normal use of the M bit in video formats, to allow = an efficient playout buffer handling. >>=20 >> Please let me know if there is any concern with such a change (and note = that we would align the terminology of RTP stream with other drafts, e.g. t= he Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing= comments). >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,=20 >> Ye-Kui >> Sent: Wednesday, March 05, 2014 10:29 AM >> To: Jonatan Samuelsson; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Something should be done to the HEVC spec to make it clearer for the dec= oded picture hash SEI message, like that it shall not be nested and what th= e values of LayerId and LId should be, or allow add to the list of nestable= SEI message. In any case, it does not make sense to me to put a greater va= lue of TId than its associated picture. On user_data_registered_itu_t_t35 a= nd user_data_unregistered suffix SEI messages, only if it is defined by som= e application then it may make sense to put a greater value of TId than its= associated picture - currently I have not seen any such use being defined = anywhere. >>=20 >> Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough. We might need to specify the semantics= of the marker bit to be RTP stream specific. To make sure whether such a c= hange is OK, we also need to check against the usage of the marker bit. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] >> Sent: Wednesday, March 05, 2014 1:07 AM >> To: Wang, Ye-Kui; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Thanks for your response Ye-Kui, >>=20 >> As far as I understand, out of the 6 SEI messages that have so far been = defined in the HEVC spec as possible to use as suffixes (filler_payload, us= er_data_registered_itu_t_t35, user_data_unregistered, progressive_refinemen= t_segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that= are not required to have the same TId as the VCL NAL units of the access u= nit: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pi= cture_hash since their payloadType numbers (4, 5 and 132) are not included = in the list: >>=20 >> "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, = 16, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages= that have payloadType not equal to 0, 1, or 130, and that are allowed to b= e nested SEI messages), the SEI NAL unit containing the non-nested SEI mess= age shall have TemporalId equal to the TemporalId of the access unit contai= ning the SEI NAL unit." >>=20 >> Maybe it's a mistake in the HEVC spec that 132 is not in this list, but = I think the problem would exist even if was. An encoder that (for whatever = reason) puts in user_data_registered_itu_t_t35 or user_data_unregistered su= ffix SEI messages with higher TId would put a MANE in a difficult situation= .=20 >>=20 >> I also think we should consider future extensions of HEVC (i.e. SHVC and= MV-HEVC) in which an access unit may contain many pictures with different = values of nuh_layer_id. If the marker bit is set for the last packet of an = access unit, then once again all the marker bits will end up in the highest= layer (stream) and a MANE would have to change the value of marker bits as= soon as not all layers (streams) are forwarded. >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] >> Sent: den 5 mars 2014 01:20 >> To: Jonatan Samuelsson; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hmm, a decoded picture hash SEI message applies to (and is associated wi= th) the preceding decoding picture in decoding order and thus the TId of th= e containing suffix SEI NAL unit should be set equal to the TId of the asso= ciated picture. Thus in the example, for the suffix SEI NAL unit containing= the decoded picture hash SEI message for the first encoded picture should = be assigned TId equal to 0.=20 >>=20 >> According to the HEVC spec, currently the following SEI messages are or = can be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35,= user_data_unregistered, progressive_refinement_segment_end, post_filter_hi= nt, and decoded_picture_hash. Among these, I think all of the "specified" S= EI messages (i.e. the above list excluding user_data_registered_itu_t_t35, = user_data_unregistered) contained in a suffix SEI NAL unit would apply to t= he preceding decoded picture in decoder order and should have the same TId = as the associated picture. The only SEI messages that can have a greater TI= d value than the containing access unit are the three SEI message that can = carry HRD information, i.e., buffering_period, pic_timing, and decoding_uni= t_info, but these can only be prefix SEI messages. >>=20 >> Of course, in theory, future versions of HEVC or some extensions (even d= efined by an application spec) could define suffix SEI messages that can ha= ve a greater TId value than the containing access unit. In that case, what = you described could be meaningful, and indeed if a receiver receives the "b= ase sub-layer" stream, some entity would have to set the marker bit of thos= e packets containing the last NAL unit of an access unit for that stream, a= ccording to the current semantics. >>=20 >> However, if we change the wording to the last VCL NAL unit as you sugges= ted, and in case a suffix SEI NAL unit of picture A is not carried the pack= et containing the last VCL NAL unit if the access unit, would the usage of = the marker bit be affected, e.g. in playout buffer handling? If the answer = is no, then there should be no problem to do the change. >>=20 >> Basically the situation is as follows. There is no concrete problem now.= However, there can be a potential problem in the future if a suffix SEI me= ssage is defined and can have a greater TId value than the containing acces= s unit. If the suggested change does not affect the usage of the bit, we sh= ould do the change now to make the design future-proof. So the key question= is whether the suggest change would affect the usage of the bit.=20 >>=20 >> Does anyone know how the marker bit is used in playout buffering handlin= g? An explanation or a pointer would be greatly appreciated. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] >> Sent: Tuesday, March 04, 2014 1:28 PM >> To: Wang, Ye-Kui; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Dear Ye-Kui, >>=20 >> Let me try to make the example more specific (and then also see if I hav= e understood the multi-stream transmission concept correctly). >>=20 >> Assume that the sender puts all NAL units with TId 0 in one RTP stream (= stream A) and all NAL units with TId 1 in another RTP stream (stream B). No= w for the first encoded picture the VCL NAL units are assigned TId 0 and th= en a decoded picture hash SEI message is created in the same access unit bu= t is given TId 1. Then the marker bit will be set on the packet containing = the decoded picture hash SEI message which is put in stream B. If this sche= me is applied for all access units, stream A will not contain any packets w= ith the marker bit set since these are all put in stream B. A MANE that onl= y wants to forward stream A to a receiver would be required to perform anal= ysis (and probably introduce delay) in order to correctly change the marker= bit on the "new" last packet of the access unit. >>=20 >> Is that correct, or have I misinterpreted anything? >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] >> Sent: den 4 mars 2014 18:21 >> To: payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org; Jonatan=20 >> Samuelsson >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hi Jonatan, >>=20 >> I do not fully understand the following example: >>=20 >> "However, as far as I understand, it is allowed for an encoder to create= a bitstream with two temporal sub-layers (every second picture with TId 0= and every second picture with TId 1) but put post-picture SEI messages fo= r all access units in temporal layer 1 (also for access units in which the= picture has TId 0, as a hint of the relative importance of the NAL units)= . For that case I guess there will be one RTP stream (corresponding to TId = 0) completely without any marker bit set, right?" >>=20 >> Could you please check whether it can be clarified a bit? >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org] >> Sent: Monday, March 03, 2014 2:11 PM >> To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui;=20 >> stewe@stewe.org; jonatan.samuelsson@ericsson.com >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> #10: Marker bit in H.265/HEVC >>=20 >>=20 >> Comment (by jonatan.samuelsson@ericsson.com): >>=20 >> Thanks Stefan for the comments and the example. It is exactly this kind = of cases I'm concerned about but I wouldn't characterize them as exotic. F= or conversational applications it is natural to operate in *very* low dela= y mode (i.e. not buffering packets before forwarding them) and having post= - picture SEI packetized in their own packets is the only option as soon a= s the VCL NAL units are fragmented since FUs cannot be aggregated. Having = to introduce slices just to avoid FUs and thereby being able to aggregate = SEI messages with VCL NAL units does not sound like a compelling alternati= ve. >>=20 >> The most reasonable solution for this case is probably to just not perfo= rm thinning by removing the SEI messages since they are typically not very= large in the first place. >>=20 >> However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). >> For that case I guess there will be one RTP stream (corresponding to=20 >> TId >> 0) completely without any marker bit set, right? >>=20 >> -- >> -------------------------------------+------------------------------- >> -------------------------------------+--- >> -------------------------------------+--- >> Reporter: | Owner: draft-ietf-payload- >> jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rtp-h265 | Version: 2.0 >> Severity: - | Resolution: >> Keywords: | >> -------------------------------------+------------------------------- >> -------------------------------------+--- >> -------------------------------------+--- >>=20 >> Ticket URL:=20 >> >> payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >=20 From nobody Wed Mar 12 05:18:17 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6915D1A096C for ; Wed, 12 Mar 2014 05:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MANGLED_TOOL=2.3, SPF_PASS=-0.001] 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 wNL5PKOnlbzG for ; Wed, 12 Mar 2014 05:18:10 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id AA2331A0969 for ; Wed, 12 Mar 2014 05:18:09 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-28-5320507ac7be Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 12.9B.04853.A7050235; Wed, 12 Mar 2014 13:18:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Wed, 12 Mar 2014 13:18:02 +0100 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , Jonathan Lennox Thread-Topic: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC Thread-Index: AQHPMkf2CFY3DR2ikEyoFpWG3Tj1ZprP5Z+AgAFBKICAAE+AEIAAJbcAgACZfjCAAJawAIAADokAgABPWgCAAAU6gIAArnFggAC5jwCABbv2cIAALsGAgAAEgoCAAPgv0A== Date: Wed, 12 Mar 2014 12:18:01 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB231C8DC2@ESESSMB109.ericsson.se> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> <088.5cce7c7048eaf169f8424dbdd09a8722@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BD0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C6FAB@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D6229@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C74DC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D804D@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D8196@nasanexd02f.na.qualcomm.com> <02ACD790-4F42-4CB1-84CE-8F6490374477@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D86D4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7983@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D956D@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C846A@ESESSMB109.ericsson.se> <7975B7E5-D690-4F0A-8DDD-1AE5CA13FAB2@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83387DBF7C@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387DBF7C@nasanexd02f.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RrcqQCHY4N53A4tTF/exWuxffJ7Z 4tLFs0wW1xs3sVssmXyT2eLJmmPMDmweL7r3sXssWfKTyWPR1GeMHovXv2f0+HL5M5tH27M7 7AFsUVw2Kak5mWWpRfp2CVwZC7+cZSqYdpex4tS7vWwNjG2bGLsYOTkkBEwkfq6ZygRhi0lc uLeerYuRi0NI4ASjxLubixghnCWMEgs37wRyODjYBKwkvr+IAGkQEQiR+H6vgQWkhlngFaPE gtXb2EASwgL2Evfu/2CEKHKQOD11PTNIkYjAJEaJhl/bwRIsAqoS337dZgGxeQW8JTafnA+1 7QO7xMbZ68CKOAWCJd6u2AM2lVFAVuL+93tgDcwC4hK3nsyHultAYsme88wQtqjEy8f/WEEu lRBQlFjeLwdRriOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVFsFpKps5C0zELSMgtJywJGllWM ksWpxcW56UYGernpuSV6qUWZycXF+Xl6xambGIHxeXDLb6MdjCf32B9ilOZgURLnvc5aEyQk kJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBse6Fd9Snl7/Otvu+rjhZ9EygZeK1lNOPbp/0Kz21 48bJjKczM04lPYg//rBkub1G++dnCzW8rk3kOio+Of7hr5ZHV1badT96Vh4UfCpB68vTpLuP l36WL3C9d6vrvfmv2slpp9euC3PhO8QpesJ6W915psAbsfn7+Nc4Hk/8vUtj6qnghR837Hyg xFKckWioxVxUnAgA7b4HqJ0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/IpnxTLhV0vbjO-hnljROT4DS2dE Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , payload issue tracker Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 12:18:14 -0000 Hi,=20 Regarding Jonathan's question: "Bare SHOULDs (i.e., a statement that says something SHOULD be done, withou= t explaining the circumstances in which an implementation would not do it) = are generally considered undesirable in IETF standards these days. (This i= s a stylistic change since RFC 3551 was written.) What do you consider the= circumstances in which it would be appropriate for an H.265 RTP implementa= tion not to set the marker bit?" In fact I would prefer if it was explicitly stated that the marker bit MUST= be set on the last packet in an RTP stream of an access unit and that it M= UST NOT be set on a packet that is not the last packet of an RTP stream of = an access unit.=20 One concrete example of where a "lazy" MANE would be tempted not to set mar= ker bit correctly is when an RTP stream containing two temporal layers is s= plit up to two different RTP streams based on temporal_id. In order two ded= uce which packet to set the marker bit on in each stream the MANE would hav= e to buffer the entire access unit before being able to forward the last pa= cket of the stream corresponding to the higher temporal_id. Another example was the one I mentioned earlier. A "lazy" MANE that (for so= me reason) removes suffix SEI messages (perhaps it has somehow been informe= d that the receiver is not capable of making use of them) without buffering= preceding packets will not set the marker bit on the last packet if it has= already been forwarded.=20 A third example is for SHVC or MV-HEVC in which a MANE extracts a base laye= r from a single RTP stream containing multiple layers. If that stream is su= pposed to be correct according to the HEVC payload format the MANE will mos= t probably have to buffer and wait for all layers of that access unit befor= e deducing which packet was the last packet of the base layer. Anyway. I appreciate the constructive discussion on the topic (thanks) and = I think the suggestion on the table: =20 " Marker bit (M): 1 bit Set for the last packet, carried in the current RTP stream, of an access un= it, in line with the normal use of the M bit in video formats, to allow an = efficient playout buffer handling."=20 is ok and an improvement compared to the original text in the draft but I w= ould appreciate if it was made clear that this is to be interpreted as a MU= ST (not a SHOULD) and that some more text is added to, as Jonathan suggeste= d: "explicitly pointing out that in MST mode, if an access unit appears in mul= tiple packet streams, the marker bit is set on each packet stream's last pa= cket of the access unit." Best Regards Jonatan -----Original Message----- From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20 Sent: den 10 mars 2014 17:30 To: Jonathan Lennox; Jonatan Samuelsson Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org; Step= han Wenger; payload@ietf.org Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC I have basically the same opinion here as Jonathan. Just one aspect regarding Jonatan's following comment: > Just because you have received all packets with the same timestamp it is = not necessarily the case that you can safely display the picture in that ac= cess unit, e.g. if you in the next access unit receive a picture with lower= timestamp. Thus, in my opinion, the most useful information that you can g= et from the marker bit is whether you have received all VCL NAL units of a = picture or not. [YK] I think your first sentence is correct, but I don't see the logic that= this true statement can lead to the conclusion that "the most useful infor= mation that you can get from the marker bit is whether you have received al= l VCL NAL units of a picture or not". To me, if you have reordering in enco= ding, then you are not doing low-delay, and then the marker bit is less use= ful than in low-delay where there is no reordering in encoding. BR, YK -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Monday, March 10, 2014 9:13 AM To: Jonatan Samuelsson Cc: Wang, Ye-Kui; payload issue tracker; draft-ietf-payload-rtp-h265@tools.= ietf.org; Stephan Wenger; payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC On Mar 10, 2014, at 9:17 AM, Jonatan Samuelsson wrote: > Thanks for your response Ye-Kui (sorry for my late reply), >=20 > In my opinion it does make sense to distinguish between VCL data and non-= VCL data. Just because you have received all packets with the same timestam= p it is not necessarily the case that you can safely display the picture in= that access unit, e.g. if you in the next access unit receive a picture wi= th lower timestamp. Thus, in my opinion, the most useful information that y= ou can get from the marker bit is whether you have received all VCL NAL uni= ts of a picture or not. I disagree. I don't think VCL and non-VCL NAL units should be distinguishe= d for the marker bit. Presumably any encoder which is sending suffix NAL u= nits (and I would expect them to be rare) is doing so because it believes t= hey'll be useful for the decoders to fully decode the access unit. If a later packet contains an earlier timestamp, you're either doing frame = reordering (in which case it *is* safe to decode the earlier frame in decod= e order) or else using DON (in which case you need to track DON values rath= er than sequence numbers). The marker bit - by definition - can't carry more than one bit of data, so = there's no way to tell just from that bit whether it's safe to decode a fra= me given arbitrary earlier packet loss. Without packet loss, it should alw= ays be possible to decode an access unit when the marker bit is received, i= f all earlier access units in decode order (since the last refresh point) h= ave already been decoded. > Anyway, let me ask one question on the solution that you were suggesting.= =20 >=20 > " Marker bit (M): 1 bit > Set for the last packet, carried in the current RTP stream, of an access = unit, in line with the normal use of the M bit in video formats, to allow a= n efficient playout buffer handling." >=20 > Would it be equivalent to: >=20 > " Marker bit (M): 1 bit > Set when the next packet (if any), in the same RTP stream, has a differen= t timestamp than the current packet." They are equivalent when not using DON (or more specifically when sprop-dep= ack-buf-nalus > 0). When you are using DON, they are different; and I thin= k the original definition is more useful. > Another question related to >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > It uses "SHOULD" from RFC 2119 but in the H.265 payload format "SHOULD" i= s not used. Is the intended interpretation: >=20 > " Marker bit (M): 1 bit > SHOULD be set for the last packet..."? Bare SHOULDs (i.e., a statement that says something SHOULD be done, without= explaining the circumstances in which an implementation would not do it) a= re generally considered undesirable in IETF standards these days. (This is= a stylistic change since RFC 3551 was written.) What do you consider the = circumstances in which it would be appropriate for an H.265 RTP implementat= ion not to set the marker bit? > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > Sent: den 6 mars 2014 22:52 > To: Jonatan Samuelsson; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org;=20 > Stephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > [Jonatan]: I don't think this text is really up to date with HEVC in the = sense that the actual video frame (which in my opinion, for the HEVC case, = is the VCL NAL units of an access unit) can be completely received even tho= ugh there are more packet(s) that are following with the same time stamp. >=20 > I don't understand the above sentence. I think the receiver can only conc= lude that an access unit is completely received only when no more packets w= ith the same timestamp is coming soon. >=20 > For other parts of your new message below: Any data, including non-VCL da= ta, associated with a picture in the bitstream is supposed to be used by th= e decoder side (not just the decoder) to do something that can be helpful i= n processing (decoding including error concealment and so on, display, etc.= ) of the decoded picture, even not needed for NORMATIVE decoding of the pic= ture. Thus, only when the decoder side receives all data associated with a = picture, can it be sure that no more useful information may come before sen= t the decoded picture to the display. Therefore, we should not change the w= ording from "the last NAL unit" to "the last VCL NAL unit". Also, without m= aking the setting to be stream specific, as I suggested and Jonathan agreed= , multi-layer extensions will be problematic. >=20 > BR, YK >=20 >=20 > -----Original Message----- > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] > Sent: Thursday, March 06, 2014 2:59 AM > To: Wang, Ye-Kui; Jonathan Lennox > Cc: payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org;=20 > Stephan Wenger; payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Thanks Ye-Kui and Jonathan for your responses. >=20 > Regarding Section 5 of RFC 3551: >=20 > Most of these video encodings also specify that the marker bit of the > RTP header SHOULD be set to one in the last packet of a video frame > and otherwise set to zero. Thus, it is not necessary to wait for a > following packet with a different timestamp to detect that a new > frame should be displayed. >=20 > I don't think this text is really up to date with HEVC in the sense that = the actual video frame (which in my opinion, for the HEVC case, is the VCL = NAL units of an access unit) can be completely received even though there a= re more packet(s) that are following with the same time stamp. >=20 > Since none of the suffix SEI messages has any normative effect on the out= put of the decoder, why should it be necessary to wait for example for a de= coded_picture_hash SEI before detecting that a frame can be displayed? >=20 > Ye-Kui, you earlier wrote: > "Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough." >=20 > But if (as I initially suggested) the change is from "last NAL unit of an= access unit" to "last VCL NAL unit of a picture" I guess it could work als= o for future extensions in which there will be several pictures in the same= access unit. Or do you see a problem here? >=20 > Best Regards Jonatan >=20 > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > Sent: den 6 mars 2014 01:24 > To: Jonathan Lennox > Cc: Jonatan Samuelsson; payload issue tracker;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org; Stephan Wenger;=20 > payload@ietf.org > Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > Agree to make the intention clearer, e.g. by adding a note. >=20 > On your last question: I think you are right, a non-VCL suffix NAL unit, = e.g. an SEI, end of sequence, or end of bitstream NAL unit, could have nuh_= layer_id equal to 0, and thus in MST the last NAL unit of an access unit ma= y actually be carried in the last packet from the "base" RTP stream. And ye= s this actually does not matter for using of the marker bit for the purpose= described below.=20 >=20 > BR, YK >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Wednesday, March 05, 2014 4:05 PM > To: Wang, Ye-Kui > Cc: Jonatan Samuelsson; payload issue tracker;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org; Stephan Wenger;=20 > payload@ietf.org > Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >=20 > This seems correct to me. I would suggest, however, explicitly pointing = out that in MST mode, if an access unit appears in multiple packet streams,= the marker bit is set on each packet stream's last packet of the access un= it. >=20 > I think this definition works even when DONs are in use (when sprop-depac= k-buf-nalus is > 0), since an AP can only contain packets from a single acc= ess unit. If packets from different access units are interleaved (in RTP o= rder) using DON, the packet stream will look odd to a naive RTP analysis, b= ut I believe the marker bit will still be useful, allowing low-delay decode= rs to flush complete access units out of the de-packetization buffer early. >=20 > Ye-Kui, a question about your comment, though: are we sure that the final= packet of the access unit will in fact always be the final packet of the h= ighest layer? In particular, in SHVC or MV-HEVC, presumably we'll be able = to split MST streams by nuh_layer_id. How will the nuh_layer_id be set for= trailing SEIs in such streams? If it's set to 0, then the final packet of= the access unit will in fact be sent in a lower layer. I don't think this= actually matters, especially since MST streams will use DON, but we should= be careful about our logic. >=20 >=20 >=20 > On Mar 5, 2014, at 7:20 PM, Wang, Ye-Kui wrote: >=20 >> I did a bit of search on the usage of the marker bit for video, and the = most relevant description I found was the following paragraph in Section 5 = of RFC 3551: >>=20 >> Most of these video encodings also specify that the marker bit of=20 >> the RTP header SHOULD be set to one in the last packet of a video=20 >> frame and otherwise set to zero. Thus, it is not necessary to wait=20 >> for a following packet with a different timestamp to detect that a=20 >> new frame should be displayed. >>=20 >> So the key usage of the marker bit is that in some low-delay application= s, output/display of a picture can be done before receiving an RTP packet w= ith a different/greater timestamp. Since non-VCL NAL unit should have the s= ame timestamp as the associated picture, thus I think we should not use the= wording of "last VCL NAL unit" in determining the setting of the marker bi= t. >>=20 >> To make the semantics extensible or future-proof for multi-layer extensi= ons, I think we should change it to be RTP stream (or equivalently packet s= tream) specific, and each receiver can just look at the marker bits of the = packets from the highest RTP stream for the usage. And this will also resol= ve the issue of requiring some entities to change the marker bit in sub-lay= er scalability usage as Jonaton raised.=20 >>=20 >> In other words, the normative semantics are to be changed as follows: >>=20 >> Marker bit (M): 1 bit >> Set for the last packet, carried in the current RTP stream, of an access= unit, in line with the normal use of the M bit in video formats, to allow = an efficient playout buffer handling. >>=20 >> Please let me know if there is any concern with such a change (and note = that we would align the terminology of RTP stream with other drafts, e.g. t= he Grouping Taxonomy draft, as discussed in responding to Magnus' reviewing= comments). >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,=20 >> Ye-Kui >> Sent: Wednesday, March 05, 2014 10:29 AM >> To: Jonatan Samuelsson; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Something should be done to the HEVC spec to make it clearer for the dec= oded picture hash SEI message, like that it shall not be nested and what th= e values of LayerId and LId should be, or allow add to the list of nestable= SEI message. In any case, it does not make sense to me to put a greater va= lue of TId than its associated picture. On user_data_registered_itu_t_t35 a= nd user_data_unregistered suffix SEI messages, only if it is defined by som= e application then it may make sense to put a greater value of TId than its= associated picture - currently I have not seen any such use being defined = anywhere. >>=20 >> Anyway, I admitted that the current semantics are not fully future-proof= regarding suffix SEI messages. In looking into future multi-layer extensio= ns, it appears that simply changing the wording from "last NAL unit" to "la= st VCL NAL unit" is not good enough. We might need to specify the semantics= of the marker bit to be RTP stream specific. To make sure whether such a c= hange is OK, we also need to check against the usage of the marker bit. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] >> Sent: Wednesday, March 05, 2014 1:07 AM >> To: Wang, Ye-Kui; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Thanks for your response Ye-Kui, >>=20 >> As far as I understand, out of the 6 SEI messages that have so far been = defined in the HEVC spec as possible to use as suffixes (filler_payload, us= er_data_registered_itu_t_t35, user_data_unregistered, progressive_refinemen= t_segment_end, post_filter_hint, and decoded_picture_hash) there are 3 that= are not required to have the same TId as the VCL NAL units of the access u= nit: user_data_registered_itu_t_t35, user_data_unregistered and decoded_pi= cture_hash since their payloadType numbers (4, 5 and 132) are not included = in the list: >>=20 >> "When a non-nested SEI message has payloadType equal to 2, 3, 6, 9, 15, = 16, 17, 19, 22, 23, 45, 47, 128, 131, or 134 (i.e., one of the SEI messages= that have payloadType not equal to 0, 1, or 130, and that are allowed to b= e nested SEI messages), the SEI NAL unit containing the non-nested SEI mess= age shall have TemporalId equal to the TemporalId of the access unit contai= ning the SEI NAL unit." >>=20 >> Maybe it's a mistake in the HEVC spec that 132 is not in this list, but = I think the problem would exist even if was. An encoder that (for whatever = reason) puts in user_data_registered_itu_t_t35 or user_data_unregistered su= ffix SEI messages with higher TId would put a MANE in a difficult situation= .=20 >>=20 >> I also think we should consider future extensions of HEVC (i.e. SHVC and= MV-HEVC) in which an access unit may contain many pictures with different = values of nuh_layer_id. If the marker bit is set for the last packet of an = access unit, then once again all the marker bits will end up in the highest= layer (stream) and a MANE would have to change the value of marker bits as= soon as not all layers (streams) are forwarded. >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] >> Sent: den 5 mars 2014 01:20 >> To: Jonatan Samuelsson; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hmm, a decoded picture hash SEI message applies to (and is associated wi= th) the preceding decoding picture in decoding order and thus the TId of th= e containing suffix SEI NAL unit should be set equal to the TId of the asso= ciated picture. Thus in the example, for the suffix SEI NAL unit containing= the decoded picture hash SEI message for the first encoded picture should = be assigned TId equal to 0.=20 >>=20 >> According to the HEVC spec, currently the following SEI messages are or = can be suffix SEI messages: filler_payload, user_data_registered_itu_t_t35,= user_data_unregistered, progressive_refinement_segment_end, post_filter_hi= nt, and decoded_picture_hash. Among these, I think all of the "specified" S= EI messages (i.e. the above list excluding user_data_registered_itu_t_t35, = user_data_unregistered) contained in a suffix SEI NAL unit would apply to t= he preceding decoded picture in decoder order and should have the same TId = as the associated picture. The only SEI messages that can have a greater TI= d value than the containing access unit are the three SEI message that can = carry HRD information, i.e., buffering_period, pic_timing, and decoding_uni= t_info, but these can only be prefix SEI messages. >>=20 >> Of course, in theory, future versions of HEVC or some extensions (even d= efined by an application spec) could define suffix SEI messages that can ha= ve a greater TId value than the containing access unit. In that case, what = you described could be meaningful, and indeed if a receiver receives the "b= ase sub-layer" stream, some entity would have to set the marker bit of thos= e packets containing the last NAL unit of an access unit for that stream, a= ccording to the current semantics. >>=20 >> However, if we change the wording to the last VCL NAL unit as you sugges= ted, and in case a suffix SEI NAL unit of picture A is not carried the pack= et containing the last VCL NAL unit if the access unit, would the usage of = the marker bit be affected, e.g. in playout buffer handling? If the answer = is no, then there should be no problem to do the change. >>=20 >> Basically the situation is as follows. There is no concrete problem now.= However, there can be a potential problem in the future if a suffix SEI me= ssage is defined and can have a greater TId value than the containing acces= s unit. If the suggested change does not affect the usage of the bit, we sh= ould do the change now to make the design future-proof. So the key question= is whether the suggest change would affect the usage of the bit.=20 >>=20 >> Does anyone know how the marker bit is used in playout buffering handlin= g? An explanation or a pointer would be greatly appreciated. >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] >> Sent: Tuesday, March 04, 2014 1:28 PM >> To: Wang, Ye-Kui; payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Dear Ye-Kui, >>=20 >> Let me try to make the example more specific (and then also see if I hav= e understood the multi-stream transmission concept correctly). >>=20 >> Assume that the sender puts all NAL units with TId 0 in one RTP stream (= stream A) and all NAL units with TId 1 in another RTP stream (stream B). No= w for the first encoded picture the VCL NAL units are assigned TId 0 and th= en a decoded picture hash SEI message is created in the same access unit bu= t is given TId 1. Then the marker bit will be set on the packet containing = the decoded picture hash SEI message which is put in stream B. If this sche= me is applied for all access units, stream A will not contain any packets w= ith the marker bit set since these are all put in stream B. A MANE that onl= y wants to forward stream A to a receiver would be required to perform anal= ysis (and probably introduce delay) in order to correctly change the marker= bit on the "new" last packet of the access unit. >>=20 >> Is that correct, or have I misinterpreted anything? >>=20 >> Best Regards Jonatan >>=20 >> -----Original Message----- >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] >> Sent: den 4 mars 2014 18:21 >> To: payload issue tracker;=20 >> draft-ietf-payload-rtp-h265@tools.ietf.org; stewe@stewe.org; Jonatan=20 >> Samuelsson >> Cc: payload@ietf.org >> Subject: RE: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> Hi Jonatan, >>=20 >> I do not fully understand the following example: >>=20 >> "However, as far as I understand, it is allowed for an encoder to create= a bitstream with two temporal sub-layers (every second picture with TId 0= and every second picture with TId 1) but put post-picture SEI messages fo= r all access units in temporal layer 1 (also for access units in which the= picture has TId 0, as a hint of the relative importance of the NAL units)= . For that case I guess there will be one RTP stream (corresponding to TId = 0) completely without any marker bit set, right?" >>=20 >> Could you please check whether it can be clarified a bit? >>=20 >> BR, YK >>=20 >> -----Original Message----- >> From: payload issue tracker [mailto:trac+payload@trac.tools.ietf.org] >> Sent: Monday, March 03, 2014 2:11 PM >> To: draft-ietf-payload-rtp-h265@tools.ietf.org; Wang, Ye-Kui;=20 >> stewe@stewe.org; jonatan.samuelsson@ericsson.com >> Cc: payload@ietf.org >> Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC >>=20 >> #10: Marker bit in H.265/HEVC >>=20 >>=20 >> Comment (by jonatan.samuelsson@ericsson.com): >>=20 >> Thanks Stefan for the comments and the example. It is exactly this kind = of cases I'm concerned about but I wouldn't characterize them as exotic. F= or conversational applications it is natural to operate in *very* low dela= y mode (i.e. not buffering packets before forwarding them) and having post= - picture SEI packetized in their own packets is the only option as soon a= s the VCL NAL units are fragmented since FUs cannot be aggregated. Having = to introduce slices just to avoid FUs and thereby being able to aggregate = SEI messages with VCL NAL units does not sound like a compelling alternati= ve. >>=20 >> The most reasonable solution for this case is probably to just not perfo= rm thinning by removing the SEI messages since they are typically not very= large in the first place. >>=20 >> However, as far as I understand, it is allowed for an encoder to create = a bitstream with two temporal sub-layers (every second picture with TId 0 = and every second picture with TId 1) but put post-picture SEI messages for= all access units in temporal layer 1 (also for access units in which the = picture has TId 0, as a hint of the relative importance of the NAL units). >> For that case I guess there will be one RTP stream (corresponding to=20 >> TId >> 0) completely without any marker bit set, right? >>=20 >> -- >> -------------------------------------+------------------------------- >> -------------------------------------+--- >> -------------------------------------+--- >> Reporter: | Owner: draft-ietf-payload- >> jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rtp-h265 | Version: 2.0 >> Severity: - | Resolution: >> Keywords: | >> -------------------------------------+------------------------------- >> -------------------------------------+--- >> -------------------------------------+--- >>=20 >> Ticket URL:=20 >> >> payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >=20 From nobody Mon Mar 17 07:22:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D041A034B for ; Mon, 17 Mar 2014 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 JZrCU_kZ2Vat for ; Mon, 17 Mar 2014 07:22:42 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 90C241A0412 for ; Mon, 17 Mar 2014 07:22:41 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-49-532705289600 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id EF.2A.04853.82507235; Mon, 17 Mar 2014 15:22:32 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Mar 2014 15:22:31 +0100 Message-ID: <53270527.9010407@ericsson.com> Date: Mon, 17 Mar 2014 15:22:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D100D@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D100D@nasanexd02f.na.qualcomm.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvja4Gq3qwwbuDJhanLu5jtbh08SyT xZM1x5gdmD2WLPnJ5LFo6jNGjy+XP7MFMEdx2aSk5mSWpRbp2yVwZTT2/2AsWK9R8fnFeqYG xk6FLkZODgkBE4krfx4wQthiEhfurWcDsYUETjBK/Lws0sXIBWQvZ5R4t/skWBGvgLbEposr wWwWAVWJm6dvMYPYbAIWEjd/NII1iwoES+w88BuqXlDi5MwnLCCDRAQ2MUosXLwGrEhYwFFi Q2MrE8S2IonjXc3sIDYnUHPPgydAzRxAF4lL9DQGgYSZBfQkplxtYYSw5SWat85mhmjVlmho 6mCdwCg4C8m6WUhaZiFpWcDIvIpRsji1uDg33chALzc9t0QvtSgzubg4P0+vOHUTIzCUD275 bbSD8eQe+0OM0hwsSuK811lrgoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw8inP+vyO89e6 A7orf/2emnT2e+z7m+d9hLKuNZ7f8nb6o/bnDeyunmoNrTsvHSxPXpm98vzMxp091+buurup V/ycqlTouVVie/XU6+RZcqwzhF4vlO9cEiTJ7uTM3ZYz91cll2zXz+s3Pndcf1yzQ0SwomJ1 whGFi2VRIbtvO1Q2Kb+bGPProBJLcUaioRZzUXEiAIJ4uoczAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/mMa7YiZP-cQEHzs3-xhwklcNArQ Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:22:44 -0000 Hi, Removing the issues where I am happy with your response and have no further to add. On 2014-03-01 00:31, Wang, Ye-Kui wrote: > -----Original Message----- From: payload > [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Friday, February 28, 2014 7:47 AM To: payload@ietf.org; > draft-ietf-payload-rtp-h265@tools.ietf.org Subject: [payload] > Comments on draft-ietf-payload-rtp-h265-02 > > Hi, > > I have reviewed the H.265 RTP payload format and have a some > comments. > > 5. Section 1.2: o Transmission of HEVC NAL units of the same > bitstream within a single RTP stream (note that RTP stream is used > equivalently as RTP flow in this memo) or multiple RTP streams > > I would propose to make clear that "multiple RTP streams" is within > one or more RTP sessions. > > [YK]: The motivation is to allow for the multiple RTP streams to be > within either one or more RTP sessions. I hope changing "or multiple > RTP streams" to "or multiple RTP streams within one or more RTP > sessions" would be good to clarify this. > Yes, that would be a relevant clarification. > > 11. Section 4.1: Sequence number (SN): 16 bits > > Set and used in accordance with RFC 3550. > > To my understanding when using single stream transmission the > Decoding order is recovered soley from RTP sequence numbers and order > of the NALUs within each RTP payload. This usage should be mentioned > here as it affects the impact if anyone would inject other payloads > in the same RTP packet stream. > > [YK]: The current draft also supports interleaved transmission, > wherein decoding order can be different from RTP sequence number > order. Decoder order number (DON) values are used for > de-packetization. That is really not clear. My reading of the draft, really indicated that you removed all the interleaving support that was present in H.264's payload format and that DONs really was to support scalability. If it is intended to support Interleaving, then the draft needs to be explicit about this support and discuss the limitations on that mechanism, including how the use of the signalling attribute to negotiate buffer capability. > > 12. Section 4.1: I am missing the SSRC usage for this RTP payload. In > SST that is the classical identification of a particular encoding of > a media source. But for MST the SSRC usage is different as one needs > to know which SSRC in which RTP sessions that are associated. I think > this dependency needs to be noted. > > [YK]: OK. I'd appreciate if you could provide some concrete language > for this. Ok, a draft for you to word smith. synchronization source (SSRC): 32-bits Used to identify the source of the RTP packets. In SST mode a single SSRC will be used for all the parts of a single encoding. In MST mode, each SSRC is used for a packet stream containing a sub-set of encoding layers for a single encoding. Thus, a receive is required to correctly associate the set of SSRCs that included parts of the same encoding. See Section X.Y for further discussion of this association. What I considered but haven't included is if more about the dependency tree needs to be expressed here, or if that is sufficient to be covered elsewhere? > > 15. Section 4.7: If sprop-depack-buf-nalus is greater than 0, the > DOND field MUST be present in an aggregation unit that is not the > first aggregation unit in an AP, and the variable DON for the > aggregated NAL unit is derived as equal to the DON of the preceding > aggregated NAL unit in the same AP plus the value of the DOND field > plus 1 modulo 65536. > > I really wonder over the "+1" usage in the DOND field. That prevents > two NALUs in an AP to have same DON. Which at least Section 4.5 hints > to as being valid. If that is not valid, then Section 4.5 is in > error. Thus, this definition can cause issues and I don't see any > issues with defining the field without the plus. That limits the > difference to increment with a maximum of 255 instead of 256. > > [YK]: I don't see there is an error. Section 4.5 allows two NALUs in > an AP to have the same DON, but it does not require them to have > different DONs. To me, both options would work, and it is just a > matter of design taste. To my knowledge there are already some > implementations of the payload format, thus I'd prefer to keep the > "plus 1", though I don't have a strong opinion herein. I am fine with this, as long as people are okay with that they will not be able to assign the same DON value to two consecutive NALUs within a single packet. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 17 08:54:23 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877541A042D for ; Mon, 17 Mar 2014 08:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 HF87s-vT5azL for ; Mon, 17 Mar 2014 08:54:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5271A01BE for ; Mon, 17 Mar 2014 08:54:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-38-53271aa1e35e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3C.C5.10875.1AA17235; Mon, 17 Mar 2014 16:54:09 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Mon, 17 Mar 2014 16:54:05 +0100 Message-ID: <53271A9D.4020906@ericsson.com> Date: Mon, 17 Mar 2014 16:54:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RnehlHqwwYmjShanLu5jtbh08SyT xZM1x5gdmD2WLPnJ5LFo6jNGjy+XP7MFMEdx2aSk5mSWpRbp2yVwZZx8E14wZRZjxfSbq9gb GK9UdDFyckgImEhMmD6fCcIWk7hwbz0biC0kcIhRYuWpqC5GLiB7OaNEw4NlzCAJXgFtienL VwDZHBwsAqoSp/ZogYTZBCwkbv5oBOsVFQiW2HngNyNEuaDEyZlPWEDmiAhsYpRYuHgNWJGw gKPEhsZWJohlRRInDpxgBbE5gZq/bWllB5kvISAu0dMYBBJmFtCTmHK1hRHClpdo3jqbGaJV W6KhqYN1AqPgLCTrZiFpmYWkZQEj8ypG9tzEzJz0csNNjMAgPbjlt+4OxlPnRA4xSnOwKInz fnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsYJ1q3BFzv+/DPLF3cFSm5ZdXvLG+sIs neeLauNMZEtUNvjK9b76GVEhGnsjfgdj56s3OqvufgxouPdW8SOj6jvrpd+fcMy8mzh7Wq3g 71MH71geTz3xyuGo0uaZ/z5PfC0Te0jC6lPy6Q8eeppbn+5ZkvHVLCbpnqbpCoNzktliHyVv H7RcuVGJpTgj0VCLuag4EQARH0STIAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/nVVZh2bKf9iemoyZj19C_XkhVHc Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:54:22 -0000 Hi, Here are my response, I have removed all issues where I am happy with the response. On 2014-03-03 20:07, Wang, Ye-Kui wrote: > Comments 17-22 are on PACI, which is Stephan's baby, and I will thus > let Stephan to address them. > > My responses to comments 23 upwards are interleaved below (again, for > convenience, I only included comments 23 upwards). > > BR, YK > > 23. Section 5: Otherwise (sprop- depack-buf-nalus is equal to 0 > for an RTP stream), the transmission order of NAL units carried > in the RTP stream MUST be the same as the NAL unit decoding order. > > This fails to describe how you determines the NAL unit decoding > order. I assume in RTP sequence order and for each payload in the > order the NALUs are included? > > [YK]: No, the NAL unit decoding order is described by the > de-packetization process in Section 6, which applies in all cases, > regardless of sprop-depack-buf-nalus being 0 or greater than 0. Yes, > when sprop-depack-buf-nalus is equal to 0, the order would be as you > assumed above. I don't see anything wrong or missing in this regard. > However, if you think more clarification is needed anywhere, please > suggest and let us know where. What might not be clear in Section 5, is what is counted as transmission order within an aggregation packet. That is also not given for sprop-depack-buf-nalus=0 in Section 4.7. But, you might be correct that the actual text that I am missing is the one that belongs to Section 6, on how to derive decoding order from received packets when sprop-depack-buf-nalus=0. > > 24. Section 6: > > When MST is in use, NAL units of all RTP streams are stored in the > same de-packetization buffer. > > I think it needs to be clarified that this is all RTP streams from > the same encoder instance and media source. Not all RTP streams from > multiple encoder instances and media sources. > > [YK]: Yes. But on other hand, in my understanding, we always refer to > the context of one "encoder instance and media source" in RTP payload > format for a particular codec, right? Is it OK that we just make this > generic clarification? "for a particular codec" can be misinterpreted as meaning some other format, like H.264. Thus, I would prefer if you try to be more explicit so that it isn't misunderstood. Multi source and multi-stream (within a single media type) hasn't been that common. > 26. Section 7.1: > > profile-space, profile-id: Otherwise (the RTP stream is a dependent > RTP stream), the following applies, with j being the value of the > sub-layer- id parameter: > > o profile_space = sub_layer_profile_space[j] o profile_id = > sub_layer_profile_idc[j] > > The following text raises some concerns. A) These are defined as > being stream specific values. It is unclear how one deals with these > if one only want to configure the general capability within a RTP > payload type. > > [YK]: Note that these are "elementary stream" specific values, not > "RTP stream" specific values. For example, if there are 3 temporal > sub-layers, with TemporalId equal to 0, 1, and 2, respectively, and > each is carried in one RTP stream, then the values of the RTP stream > corresponding to the temporal sub-layers with TemporalId equal to 2 > are the property of the bitstream or elementary stream consisting of > all the three temporal sub-layers. And since this RTP stream is not a > dependent RTP stream (because no other RTP stream depends on it), the > general capability is assigned. Well, I think you need to be explicit about what "stream" you mean in the text throughout the whole payload format. > > B) It is unclear if one may or are required to create different RTP > payload types for the different scalability layers. From my > perspective it is crucial that one can avoid a requirement to create > layer specific payload types as this can result in total consumption > of the available payload type space in an RTP session. > > Thus, I see a need to clarify if and when one uses the above > assignment. And how the counter part in any signalling exchange is > supposed to interpret these cases. > > [YK]: To me, when a spec does not disallow the use of different RTP > payload types, which is the case with the current spec, then the use > is allowed. Do you see any reason to impose an restriction on use of > payload types for the different RTP streams in a multi-stream > transmission? If not, I think we can just add a note to say that > there is no restriction imposed herein for the use of payload types. No, I don't see a reason to impose a restriction. But, if something is intended to be possible it is better to be explicit so that the lazy implementor doesn't miss that it is required to be capable of handling such a configuration. > > 27. Section 7.1: profile-compatibility-indicator: > > Isn't this a sprop parameter? > > [YK]: It is the same as profile, tier, and level. And you can see in > later text, it is part of the media format configuration. > > Also it is not clear what "j" is: > > If the RTP stream is not a dependent RTP stream, the following > applies with j = 0..31: > > o The 32 flags = general_profile_compatibility_flag[j] > > Am I correct that j in this case are the integer identifying a > particular HEVC profile? > > [YK]: That is true. This is clear from the semantics of the flag as > defined in the HEVC spec. We can try to add a bit more clarification > on this. Thanks, a pointer is likely all that is necessary, but as someone who only read a few very specific parts of the HEVC spec, I don't know these are defined in the HEVC specification. > > 28. Section 7.1: profile-compatibility-indicator: > > It is not clear to me that this parameter has long term > applicability. If one includes this, is that a promise until > signaling changes to not provide a stream that breaks the provided > value? I wonder how one deals with the use cases like AD splicing. > One stream may ensure this, is it the role of the signalling to > enforce that what one says applies, or will be renegotiated in > signalling? > > [YK]: Again, the nature and the usage of this parameter is the same > as profile, tier, and level. So, yes, it would be a promise when > provided, in either SDP offer/answer or declarative usage. Good, can you make this clearer somehow? > > 29. > > sub-layer-id: > > This parameter MAY be used to indicate the highest allowed value of > TID in the stream. When not present, the value of sub-layer-id is > inferred to be equal to 6. > > This parameter is written in a generic form, however the O/A Section > indicates this to declare a property of the stream to be sent. But > not explicit discussion of this parameter is provided. So what is the > meaning of this parameter? > > A) I promise that the streams I send does not use more than X > sub-layers > > B) I require the peer sending me a stream to not use more than X > sub-layers. > > [YK]: It is A. Would it be clear enough in your view if we add that > this parameter shall not be used for any other purpose than > indicating a property of the stream (which to me is sort of clear > from its current semantics)? If it is only A, then I think it should have a sprop prefix. > > 30. Section 7.1: sprop-vps, sprop-sps and sprop-pps: > > I think one unclarity and one that existed in H.264 also, is the > precedence between out-of-band and in-band parameter sets. And when > they start to apply. The later is especially important in cases when > you actually transmit a different set in a new signalling exchange > then what has previously been used. > > Can some clarification on this be included? > > [YK]: OK, we can add a clarification to state that, out-of-band > parameter sets can be put at the beginning of the bitstream output to > the decoder, while in-band parameter sets can be sent to the decoder > in the same way as the receiver outputs other types of NAL units from > the de-packetization process. I am uncertain that what you try to say here. I interpret it as: As soon as you get the out-of-band parameters sets they can be added to the front of the queue of NALUS that are given to the decoder. Is that what you intended? > > 31. Section 7.1: Many of the parameters. I notices that quite a lot > of the parameters are not explicitly defining the value range allowed > for the parameters. This is especially true for integer style values. > See the many max- parameters. > > [YK]: Right. We have been doing this all the time, including RFCs > 6184/6190. Are you saying that from now that the value range of each > parameter needs to be clearly specified in RTP payload formats? >From my perspective, being explicit about what values you expect reduces the risk for error or becoming subject to an attack as you can parse according to the spec, and if the input is malformed or malicious you can give an error with a clear reason. If you are not explicit, you don't know what to expect here. Thus, I think explicit ranges or at least data types, i.e. what data and format to parse the value as. > > 32. Section 7.1: max-dpb: Formation error > > [YK]: Sorry, I don't know what is error by comparing to the semantics > to that of other parameters. Could you please clarify? Sorry, poorly worded. The lines on page 55 overflows the 72 column boundaries. > > 33. Section 7.1: > > cap-parameter = tier-flag / level-id / max-lsr / max-lps / max-br > > These ABNF elements are not defined. I think they need to be. > > [YK]: This came from you guys. Can you please provide the missing > definition? Yes, I know. Here is an proposal. 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 = "=" DIGIT = This is based on my understanding that tier-flag really only is a binary flag. level-id is an unsigned 8-bit value. max-lsr and max-br clearly has the potential for being larger than 32-bit integer, thus I used a 64-bit integer. I think 4G of pixel resolution is likely sufficient. Any errors in these assumptions? > > 35. Section 7.2.2: > > Informative note: The above parameters apply for any stream sent by > a declaring entity with the same configuration; i.e. they are > dependent on their source. Rather than being bound to the payload > type, the values may have to be applied to another payload type when > being sent, as they apply for the configuration. > > I find this confusing. I don't know if it is a typo and should say > "independent of their source", or if it is the definition of source > here that is wrong. > > It might be that the paragraph before the above: o The parameters > sprop-depack-buf-nalus and sprop-depack-buf-bytes describe the > properties of the RTP stream that the offerer or the answerer is > sending for the media format configuration. This differs from the > normal usage of the Offer/Answer parameters: normally such parameters > declare the properties of the stream that the offerer or the answerer > is able to receive. When dealing with HEVC, the offerer assumes that > the answerer will be able to receive media encoded using the > configuration being offered. > > actually needs to separate between end point specific configurations > that apply to the whole RTP session through the payload type or if is > on specific media encoding basis and thus needs to be connected to > the SSRC(s) that carries the particular media encoding. > > [YK]: It seems to be a good catch. The same wording was inherited > from RFC 6184, and appeared in RFC 3984 as well, for which you were a > co-author. Could you authors of RFC 3984 (e.g. Stephan, Miska, > Magnus) try to help figure out what was the actual intent when this > wording was firstly introduced into RFC 3984? What, you are holding me responsible for what I wrote 10 years ago? ;-) Considering this is SDP O/A, and looking at it again. I think it refer to that an SDP agent sending a Offer or Answer with sprop-depack-buf-nalus and sprop-depack-buf-bytes included, are responsible to ensure that any HEVC encoding and its RTP packetization conforms to the declared parameters. This applies to each encoding independently, even if multiple encodings are transmitted. Thus, I think this text would be clearer if one adds "endpoint" after source. > > 36. Section 7.2.2: > > min_spatial_segmentation_idc equal to or larger than dec- > parallel-cap.spatial-seg-idc of the capability point. A stream that > is sent based on choosing a capability point with parallel tool > type 't' from dec-parallel-cap MUST have > entropy_coding_sync_enabled_flag equal to 0 and > min_spatial_segmentation_idc equal to or larger than dec- > parallel-cap.spatial-seg-idc of the capability point. > > It looks like someone managed to turn this text into straight left > and right columns, this is not allowed in IETF, we use ragged > rights. > > [YK]: I guess you meant to align text only to the left margin, not to > both left and right margins? If that is the case, we actually did > this in all the places in the Word based template for preparing of > the draft. Do you see any issues in other places as well? Can you > please let us know some specific line for which the style should be > changed? Correct, I have seen this in some few places. Lines: 33 58, for three lines 262 285 299, for 3 lines 376 etc. 3275, for 5-lines Search for ". " and you will find a large number of these issues. > > 37. Section 7.2.2: > > o An offerer has to include the size of the de-packetization buffer, > sprop-depack-buf-bytes, and sprop-depack-buf-nalus, in the offer > for an interleaved HEVC stream or for the MST transmission > mode. To enable the offerer and answerer to inform each other > about their capabilities for de-packetization buffering in > receiving streams, both parties are RECOMMENDED to include > depack-buf-cap. For interleaved streams or in MST, it is also > RECOMMENDED to consider offering multiple payload types with > different buffering requirements when the capabilities of the > receiver are unknown. > > This paragraph contains two mentions of "interleaved", the only two > in the whole specification. I assume a copy and paste from RFC 6184 > that wasn't converted properly. > > [YK]: No they are intentionally left here, as interleaved > packetization is allowed. Maybe we can add one sentence or two to > make this more explicit. As said earlier, if this is a supported feature of the payload format, then you need to discuss it explicitly. > 43. Section 7.2.2: > > sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o > recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ > | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | > profile-space C X C X P profile-id > C X C X P tier-flag C X C X P > level-id C X C X P > > C: configuration for sending and receiving streams > > I don't get this usage or definition of C for these parameters. > > So these parameters are receiver capabilities, and they needs to be > symmetrically used in the signalling, however the actually used > values in the transmission direction from an O/A agent only needs to > be within the receivers provided parameters. Thus, they are not a > "configuration" for the sending direction. > > [YK]: These are configuration parameters, meaning indicating both > what is to be sent and what is to be received for sendrecv and must > be used symmetrically, and only the latter for recvonly. This is at a least wrong for the level-id which a peer agent in an O/A may downgrade. The rest I agree the payload format itself requires to be kept in answer, or the corresponding PT dropped. > > Also I really don't get the X's in the answer: recvonly, > recv-sub-layer-id, and answer: sendrecv, recv-sub-layer-id. The > answering agent is going to receive stream in both these cases, thus > it needs to declare the payload type, and these parameters MUST be > included (unless defaulted). So why is they marked with X? > > [YK]: When recv-sub-layer-id is included in an SDP answer, it means > that the answer chooses one of the multiple operation points > corresponding to the offered or declared sub-layers in the sprop-vps, > and in this case there is no need to repeat the information of > profile, level etc. in the SDP, thus there are marked with X (MUST > NOT be present). This appears very strange to me. The Offerer includes a VPS that contains options for what it can send. The answering party, i.e. which will receive this stream needs in accordance to SDP O/A rules declare which PTs it can receive. This PT must be corresponding to the one that the Offerer proposed to send and in which the VPS was included. For me this implies the following: 1. The parameters indicating the basic configuraiton of the payload type, i.e profile, level ,tier etc. MUST be present in the answer with the same values as in the offer it responds to. Otherwise the PT matching rule fails. 2. In addition the PT to receive on MUST be declared as existing to ensure that any middleboxes doesn't block it. Thus, explicit indication of what will go in it is really recommended, especially considering i all the other cases that information will be explicit here. Thus, I think the X's are plain wrong. Or I am still misunderstanding something here. > > 44. Section 7.2.2: > > sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o > recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ > | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | > interop-constraints C X C X P > profile-compatibility-indicator C X C X P > > I don't understand how these parameters really are used for receiver > capability declarations, so I don't understand why the Cs are C and > not P. > > [YK]: As explained earlier, these are also parts of the media type > configuration, same as profile, tier, and level, and their usage are > the same as those too. First of all these parameters are not included as the ones that have to be symmetrically provided. I also think they could be SDP agent specifically given. But, that can be discussed. But, according to the current text, I fail to see that these needs to be handled as the profile-id, level-id, etc. The only constraint I find for these two flags applies under multicast. Either they need text, or these C's need to be changed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------