From nobody Fri May 2 01:57: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 4437C1A08EA for ; Fri, 2 May 2014 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=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 SBOlX_sUqh6q for ; Fri, 2 May 2014 01:57:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50F1A0371 for ; Fri, 2 May 2014 01:57:39 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-ad-53635e017a9f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.60.04199.10E53635; Fri, 2 May 2014 10:57:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Fri, 2 May 2014 10:57:36 +0200 Message-ID: <53635E00.5050204@ericsson.com> Date: Fri, 2 May 2014 10:57:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> In-Reply-To: <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+JvjS5jXHKwwbSpIhanLu5jtbh08SyT xaTja9ksnqw5xuzA4jH91GJmjyVLfjJ5LJr6jNHjy+XPbAEsUVw2Kak5mWWpRfp2CVwZfxbf ZCyYo1yx+sFN5gbGGzJdjJwcEgImEh+7GlghbDGJC/fWs3UxcnEICRxllPjX1sQC4SxjlFg3 ez4jSBWvgLbEv55tbCA2i4CKxPbfs9hBbDYBC4mbPxrB4qICwRIbHv5lh6gXlDg58wkLiC0i YCixZPVjdpChzAKbGCUe/J4PViQs4CixobGVCWJbA4vE+/PvmEASnAKuEvvO3APq5gC6T1yi pzEIJMwsoCcx5WoLI4QtL9G8dTYziC0EdFxDUwfrBEahWUh2z0LSMgtJywJG5lWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgSF/cMtvgx2ML587HmIU4GBU4uEt/hIZLMSaWFZcmXuIUZqD RUmc99tZ92AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjIsW1JumSL3J3Rl6aIOwFltJedyU CWraZVmZurPm613eV+uW7CK+4bE3+3u+D54nTJ9cmGzbrqL/vCxOu+jH2+vTi54KhO01k/rY Z9bJYenAf/i8q4d6wMQdzOcrvG8sUd54ZMqx5Z6Nm3i+Fq++MbH23JbXrhnvV8bUHU5Z9G/5 hWN5pv53apVYijMSDbWYi4oTAfrl7FJaAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Pe2r1NJv6QyneHeF2rYfUqHjLMA Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Fri, 02 May 2014 08:57:42 -0000 On 2014-04-30 16:40, Yago Sanchez wrote: > Hi Magnus, > > I think there is a misunderstanding with the intention of using the > profile-compatibility-indicator. It is not about indicating support for > additional profiles. The profile-compatibility-indicator sets additional > constraints to the profile indicated in the profile-id. That is why > Ye-Kui was pointing that both the profile-id and the > profile-compatibility-indicator are used to express the same as the > profile_idc in RFC 6184. This means that if the offerer indicates > profile-id equal to A and includes profile B in the > profile-compatibility-indicator, the offerer would indicate capability > of encoding/decoding a stream that only contains the tools that are in > the intersection of both profiles. The offerer promise would not even be > that it is able to decode the full A profile, unless indicated in > another PT. No, I understand that this in HEVC spec indicates that although a particular coded video sequence where the parameters in included is compliant not only to the profile it is declared for in the profile indicator parameter, it is also compliant to these marked in the profile-compatibility-indicator. However, what applies to a specific encoder instances and more precisely a coded video sequence (CVS) has a different meaning if one applies these constraints to a RTP payload type. An RTP payload type has applicability across all RTP packet streams that claims to use this payload type. In addition in an SDP O/A context with the rules currently in the draft, i.e. they apply both to the offerer and the answerer if they maintain the payload type, that means that from a P2P session context, both endpoints if accepting the PT, must be able to encoded and output a CVS which fulfils the requirements of the profile-compatibility-indicator. Which means that you MUST have an encoder that both are aware of all the profiles indicated in the included instance of profile-compatibility-indicator, i.e. you can't ignore a new profile that you don't know anything about, if the offerer has marked this unknown profile as being in the compability set. You also as an answerer must be able to determine that you can constrain your encoder implementation to the same set of coding tools that the answerer implementation have. > > My understanding was that this would be useful for those cases where two > endpoints support different profiles but are aware of the intersection > with other profiles, as in the case expressed above. Thus, there could > express more PTs with the profile they fully support and with subsets of > it result of intersections with other profiles. I think you will have to be more explicit how this is being done within the rules of the RTP payload format for HEVC. I don't see how you an answerer within SDP O/A rules can accept a payload type that has a profile=X value where it doesn't support X, but do support Y that is marked within profile-compatibility-indicator. The reason is that if the answerer indicates support in a SendRecv m= section then it must be able to decode profile X, it also must be able to send a stream marked as being X, but fulfilling also Y. That is not the same as being able to send a stream according to profile Y. The issue I am trying to make you aware of is that the combination of sender and receiver constraints profile-compatibility-indicator introduces does not appear to provide any benefit, only limitations that makes things less compatible. > > Therefore, I still think that including profile-compatibility-indicator > may be useful. Would this be reasonable or is there anything I am > missing from the discussion below? I think you are missing something about what it implies to declare a PT in a sendrecv context with this parameter. It might be me missing something, but I would like you to try to explain in detail how what you think is possible above actually works. 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 Fri May 2 17:23:15 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 7B6751A6EF1; Fri, 2 May 2014 17:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 Ay_A1qkQWlCW; Fri, 2 May 2014 17:23:11 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4A1A6F63; Fri, 2 May 2014 17:23:10 -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=1399076589; x=1430612589; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ddWj0guMcAobIRW+tMWMy8HUEG2/46gDUp2/hwuANJI=; b=rv0PDiv7bt9BaUHxDPMGHk4ALwudriEwDWNTSpU5/OiIOJMit6S2AMKN c0I2LidV5kdW85aoL6xlkmr8vOmB3s1VGvuMeKhcIU1Y9snKtrRROhN0Q k85JK/MqhWWbLk76LqAfR+6fXa20LVshdKTX/CW6C1KbPhGpS9jDJoDuS I=; X-IronPort-AV: E=McAfee;i="5600,1067,7426"; a="62858178" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 02 May 2014 17:23:08 -0700 X-IronPort-AV: E=Sophos; i="4.97,975,1389772800"; d="scan'208,217"; a="29584736" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 May 2014 17:23:09 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Fri, 2 May 2014 17:23:10 -0700 From: "Wang, Ye-Kui" To: Alex Eleftheriadis , Bernard Aboba Thread-Topic: [avtext] Proposed RTP Taxonomy updates Thread-Index: Ac9eyJwZU1yGeu96Tu+aOoOxWGE6dgFI88oAAC4LHgAAAVzTQAANClEAAB+Z2AAAQdy2sA== Date: Sat, 3 May 2014 00:23:09 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8345249883@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A8345247374@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/yN51o3fsq3cSreIXYWbfprRG83A Cc: "avtext@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [avtext] Proposed RTP Taxonomy updates 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, 03 May 2014 00:23:14 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Posting it to payload reflector as well]. I am fine with Alex's suggestion on Single Stream Configuration (SSC) and M= ulti-Stream Configuration (MSC) to replace SST/MST in the HEVC payload form= at. Does anyone else has an opinion here? @Bernard: Note that changing of "S" the middle of "SST" and "MST" from "ses= sion" to "stream" in the HEVC payload draft was a result from one of your s= uggestions. @Bernard and Alex: It is just editorial, I don't understand why it is relev= ant to mention whether something has been implemented or not - you implemen= t techniques not editorial terms - unless you meant "implemented or deploye= d in specifications". Anyway, I hope you guys can converge on the terms soon. BR, YK From: Alex Eleftheriadis [mailto:alex@vidyo.com] Sent: Thursday, May 01, 2014 2:44 AM To: Bernard Aboba Cc: Wang, Ye-Kui; Bo Burman; avtext@ietf.org Subject: Re: [avtext] Proposed RTP Taxonomy updates I agree with Bernard. There is now both SST-MS and SST-SS widely deployed b= ut, more importantly, the concepts are truly distinct. So we should not "ov= erload" SST to always mean one or the other. W.r.t. the HEVC payload spec, I would argue that redefining it there to mea= n stream rather than session, as it does in the H.264 spec, should be serio= usly reconsidered. As someone who, for many years, has tried to explain these architectures to= several people, a lot of them technically very very knowledgeable, I have = found the lack of appropriate commonly accepted terminology a serious imped= iment. Now that these architectures are investigated very extensively, we = have a great opportunity to fix that and do it the right way. Redefining ac= ronyms, and particularly in the same series of specifications, is imho goin= g in the exactly opposite direction. Maybe we can use something like "configuration": Single Stream Configuratio= n (SSC) and Multi-Stream Configuration (MSC). They describe how the layers = are configured for transmission, not how they are transmitted. The transmis= sion part comes next, and uses the SST and MST acronyms. That would simpli= fy potential changes to all drafts, and avoid confusion. --Alex [with apologies for not always closely following the thread] On Apr 30, 2014, at 9:39 PM, Bernard Aboba > wrote: The problem is that the single/ multiple session and single/multiple stream= dimensions are somewhat independent, and affect SFU design as well as clie= nt behavior. In particular, SST-MS has now been widely implemented, so we = cannot pretend it doesn't exist. Changing the meaning of the SST/MST abbrev= iations could potentially increase the already considerable confusion. On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" > wrote: Regarding the term of "RTP packet stream", "packet stream", or "RTP stream"= , I prefer "RTP stream" too. On SST/MST, note that in the latest HEVC/H.265 payload draft, we are using = "Single-Stream Transmission" and "Multi-Stream Transmission". SST here is o= bviously within one RTP session, while MST herein can involve either a sing= le or multiple RTP sessions. What is the importance of adding the suffix "-= SS" or "-MS" herein in the term? Why it is not sufficient to just use SST/M= ST with the S in the middle mean "stream"? BR, YK From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: Wednesday, April 30, 2014 4:47 AM To: Bernard Aboba Cc: avtext@ietf.org Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to leaving current SST/MST definition alone, I agree, but I th= ink there was also agreement to describe them in Taxonomy terms, without re= -defining anything. In that, "MST" and "SST" without any distinction is unclear, but should acc= ording to IETF 89 discussions typically mean "MST-SS" and "SST-SS" , which = should be described (with or without explicitly referring to any -SS and -M= S distinctions). Bernard and Alex, do I understand you correctly that you prefer to keep the= -SS and -MS distinctions? I have no problem keeping it, and I am also open= to alternative terminology describing the same thing. Do you have any prop= osals? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 29 april 2014 15:49 To: Bo Burman Cc: avtext@ietf.org; Alex Eleftheriadis Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to SST/MST, as I recall, Alex's suggestion was to leave the RF= C 6190 definition alone, but also define terminology for the single/multi-s= tream distinction. For example, it is possible to have multiple streams wit= hin a single session (SST-MS). On Apr 29, 2014, at 6:27, "Bo Burman" > wrote: Hi all, Based on the AVTEXT session at IETF 88 & 89 and some mailing list discussio= ns, I propose to make the following updates to RTP Taxonomy: * In 3.2.1 clearly define what RFC 6190 terms "SST" and "MST" means= in Taxonomy terms and remove the current discussion on Single- and Multi-S= tream. * Mention in 2.2.1 under Alternate usages that an "End Point" in Ta= xonomy terms is typically a single "host" (although "host" has no unique de= finition). * Change the term "Packet Stream" throughout the document, since it= is arguably too generic: o "RTP Packet Stream" was suggested by Magnus W about a month ago and rec= eived some support. I think it is a bit long and unnecessarily redundant, s= ince RTP already implies that it is a packet o "RTP Stream" could possibly be a sufficiently precise term; what do ot= hers think? * Re-structure the document such that Alternate usages (describing = existing terms in Taxonomy wording) are separated out into their own sub-se= ctions, making it possible to find them through the table of contents o I believe this could take care of Roni Even's request at IETF 88 for an= overview table with existing terms, while avoiding the fact that the neede= d explanations will hardly fit in a table format. * Editorial: o Remove formal numberings of level 4 headings (change to body text or he= adings in body text format). Comments are welcome! Cheers, Bo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Posting it to payload re= flector as well].

 <= /p>

I am fine with Alex’= ;s suggestion on Single Stream Configuration (SSC) and Multi-Stream Configu= ration (MSC) to replace SST/MST in the HEVC payload format. Does anyone else has an opinion here?

 <= /p>

@Bernard: Note that chang= ing of “S” the middle of “SST” and “MST”= ; from “session” to “stream” in the HEVC payload dr= aft was a result from one of your suggestions.

 <= /p>

@Bernard and Alex: It is = just editorial, I don’t understand why it is relevant to mention whet= her something has been implemented or not – you implement techniques not editorial terms – unless you meant “implemented or deploye= d in specifications”.

 <= /p>

Anyway, I hope you guys c= an converge on the terms soon.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Alex Ele= ftheriadis [mailto:alex@vidyo.com]
Sent: Thursday, May 01, 2014 2:44 AM
To: Bernard Aboba
Cc: Wang, Ye-Kui; Bo Burman; avtext@ietf.org
Subject: Re: [avtext] Proposed RTP Taxonomy updates

 

I agree with Bernard. There is now both SST-MS and S= ST-SS widely deployed but, more importantly, the concepts are truly distinc= t. So we should not "overload" SST to always mean one or the othe= r. 

 

W.r.t. the HEVC payload spec, I would argue that red= efining it there to mean stream rather than session, as it does in the H.26= 4 spec, should be seriously reconsidered.   

 

As someone who, for many years, has tried to explain= these architectures to several people, a lot of them technically very very= knowledgeable, I have found the lack of appropriate commonly accepted term= inology a serious impediment. Now that these architectures are investigated very extensively,  we have = a great opportunity to fix that and do it the right way. Redefining acronym= s, and particularly in the same series of specifications, is imho going in = the exactly opposite direction. 

 

Maybe we can use something like "configuration&= quot;: Single Stream Configuration (SSC) and Multi-Stream Configuration (MS= C). They describe how the layers are configured for transmission, not how t= hey are transmitted. The transmission part comes next, and uses the SST and MST acronyms.  That would simplify potenti= al changes to all drafts, and avoid confusion. 

 

--Alex [with apologies for not always closely follow= ing the thread] 

 

On Apr 30, 2014, at 9:39 PM, Bernard Aboba <bernard_aboba@hotmail.com> w= rote:



The problem is that the single/ multiple = session and single/multiple stream dimensions are somewhat independent, and= affect SFU design as well as client behavior.  In particular, SST-MS has now been widely implemented, so we cannot pretend it doesn't ex= ist. Changing the meaning of the SST/MST abbreviations could potentially in= crease the already considerable confusion.


On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm= .com> wrote:

Regarding the term of = 220;RTP packet stream”, “packet stream”, or “RTP st= ream”,  I prefer “RTP stream” too.

 

On SST/MST, note that in = the latest HEVC/H.265 payload draft, we are using “Single-Stream Tran= smission” and “Multi-Stream Transmission”. SST here is ob= viously within one RTP session, while MST herein can involve either a single or mu= ltiple RTP sessions. What is the importance of adding the suffix “-SS= ” or “-MS” herein in the term? Why it is not sufficient t= o just use SST/MST with the S in the middle mean “stream”?

 

BR, YK

 

From: avtext [m= ailto:avtext-bounces@ietf.org] On Behalf Of = ;Bo Burman
Sent: Wednesday, A= pril 30, 2014 4:47 AM
To: Bernard Aboba<= br> Cc: avtext@ietf.org
Subject: Re: [avte= xt] Proposed RTP Taxonomy updates

 

With respect to leaving c= urrent SST/MST definition alone, I agree, but I think there was also agreem= ent to describe them in Taxonomy terms, without re-defining anything.

 

In that, “MST”= ; and “SST” without any distinction is unclear, but should acco= rding to IETF 89 discussions typically mean “MST-SS” and “= ;SST-SS” , which should be described (with or without explicitly referring to any –SS and &#= 8211;MS distinctions).

 

Bernard and Alex, do I un= derstand you correctly that you prefer to keep the –SS and –MS = distinctions? I have no problem keeping it, and I am also open to alternati= ve terminology describing the same thing. Do you have any proposals?

 

 

 

With respect to SST/MST, as I recall, A= lex's suggestion was to leave the RFC 6190 definition alone, but also defin= e terminology for the single/multi-stream distinction. For example, it is possible to have multiple streams within a single session (= SST-MS).

Hi all,

 

Based on the AVTEXT session at IETF 88 = & 89 and some mailing list discussions, I propose to make the following= updates to RTP Taxonomy:

·         In 3.2.1 clearly define what RFC 6190 terms “SST” and “MST&= #8221; means in Taxonomy terms and remove the current discussion on Single-= and Multi-Stream.

·         Mention in 2.2.1 under Alternate usages that an “End Point” in Taxonom= y terms is typically a single “host” (although “host̶= 1; has no unique definition).

·         Change the term “Packet Stream” throughout the document, since it is = arguably too generic:

o   <= /span>“RTP Packet Stream” was suggested by Magnus W about a month ago and recei= ved some support. I think it is a bit long and unnecessarily redundant, sin= ce RTP already implies that it is a packet

o   <= /span> “RTP Stream” could possibly be a sufficiently precise term; what do other= s think?

·         Re-structure the document such that Alternate usages (describing existing terms in Taxo= nomy wording) are separated out into their own sub-sections, making it poss= ible to find them through the table of contents

o   <= /span>I believe this could take care of Roni Even’s request at IETF 88 for a= n overview table with existing terms, while avoiding the fact that the need= ed explanations will hardly fit in a table format.

·         Editorial:

o   <= /span>Remove formal numberings of level 4 headings (change to body text or headings in = body text format).

 

Comments are welcome!=

 

Cheers,

Bo

 

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

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_-- From nobody Sun May 4 13:32: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 C8FCC1A012B for ; Sun, 4 May 2014 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 z-TcdGYSwqYM for ; Sun, 4 May 2014 13:32:18 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 172251A0096 for ; Sun, 4 May 2014 13:32:17 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Content-Type: multipart/alternative; boundary="Apple-Mail=_8A6E5528-E819-4A70-ABB0-864BA122053D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yago Sanchez In-Reply-To: <53635E00.5050204@ericsson.com> Date: Sun, 4 May 2014 22:32:31 +0200 Message-Id: References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20674.002 X-TM-AS-Result: No--20.462-11.0-31-10 X-imss-scan-details: No--20.462-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: IDdx3MBO6EDkrFr7PzPkpnlMlWV+Ir67qapJP7NkemEb+/bhg0acy1YW wxB9tw0TIfqPF9C+GOiabxa5lK3CzMK8bCqGv6ntneIQmu8UmaHPapfR5AcJqeqLmFCMpwfUlOs EqPv4OiuiXpzzvoCSmdoxOXWr3hRBULNUje/+PyDhPOvpPbk2RzhaxI2If9ReHF5gWd5iOUkmBE sMjlphlM3DBOwul+3L5T1jmXZ6BXy7JfBr9Xl5CqngbqTYC4GHmtxAUpcZfKCTMTaQzhvoehETu dPHaLpduEie4Mp9+IhaOXG2R10KZU9yJAiyTb0LuIwLnB3Aqp3WSrKtwxqWpZUQzHWBKOFAHGmA LPPxetdNW4Hf2ycWmQj/5rXY+RDhuafWgMhNYLk1yhbbA7We0ywJzaIVMjGtD/G4UdVtqR5LCMY t+C2yUiUC1M+YPEhu1SQkxzt2Vp97YC9GYAGdqylrosmS0SOAE3NxsGztrMuYfLu5qIysvvQHtV D6jkQ6leq4KPTW4v82KpIGw/EwWkJtAkWtyGcuwbRQ2BpmliqZEoWHC6Rh/R9Oluq8LbzVD5jTe +M5E7S36SL29gBZ5ihiPa95Af6oY+VfsshMgK0cFO8D2ue9rwhRCJFb9cusFLXUWU5hGiF8i2xl 1bo26PF3IVwTE9PO+UMupT43/kfUyLz2MoPS7I3NgkEqAN0RwW1rM+V9HtI7LF3pX3rdVLjxa5E VBV1q4vM1YF6AJbZO+3uGNcav93czv8nPF99xOwBXM346/+wTmxKXDlCiB4CAQVwW46qzell5jp 0bCEVQL1t+k81g/MNcrPkKMJhR X-IMSS-DKIM-White-List: No X-alterMIME: Yes Archived-At: http://mailarchive.ietf.org/arch/msg/payload/mbMxS86ieJ_z5YUiszegQVR5c7k Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Sun, 04 May 2014 20:32:23 -0000 --Apple-Mail=_8A6E5528-E819-4A70-ABB0-864BA122053D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Magnus, I still think that profile-compatibility-indicator may be useful. Let me = list the different options I see and come finally to a conclusion. All = options are related to offerer supporting profile A and answerer profile = B. 1) Offerer includes profile A and no profile-compatibility-indicator. = Answerer cannot accept profile A so they cannot achieve = interoperability. 2) Offerer includes profile A and sets the flag related to profile B in = the profile-compatibility-indicator (Offerer has to be aware of the = intersection of both profiles). Answerer ist not aware of profile A and = does not know which are the tools that lay in the intersection, so again = interoperability cannot be achieved, since the answerer cannot = constraint the sent stream so that the offerer can decode it. Still, the use of profile-compatibility-indicator does not harm session = negotiation. The reason for not achieving interoperability is another = one. 3) Offerer includes profile A and sets the flag related to profile B in = the profile-compatibility-indicator (Offerer has to be aware of the = intersection of both profiles). Answerer ist also aware of profile A and = the intersection with B and can accept the offer and answer with a = stream to the offerer that can be decoded. In this case profile-compatibility-indicator helps for achieving = interoperability. 4) The last option might be one that could show a case where = profile-compatibility-indicator could be harmful. Lets assume profile A = is a superset of profile B. The answerer could offer profile A and set = the flag corresponding to profile B in profile-compatibility-indicator = or even offer profile B and set the flag corresponding to profile A in = profile-compatibility-indicator (both cases express the same). The = answerer even though it could decode and encode such a stream would have = to reject the payload type if it is not aware of what means to have a = stream being compatible to profile A due to not knowing profile A. I = think this is what you are concern about right? In summary, I only see it could be harmful in case 4. And case 4 is only = the case where a full profile is supported (in the example profile B) = and all profiles that are supersets of it are marked in the = profile-compatibility-indicator. All other cases of profiles not being = supersets and being marked in profile-compatibility-indicator would be = either example 2 or 3. Therefore my suggestion would be to still keep = profile-compatibility-indicator, since it might achieve interoperability = as shown in example 3 and add some text that expresses that if a profile = is fully supported and profile-compatibility-indicator does not = constraint that profile further the profile-id should indicate such a = profile and profile-compatibility-indicator should not be included. = Obviously this only applies for O/A and not for declarative session = description.=20 Would this make sense for you Ye-Kui and Magnus? Best regards, Yago On 2 May 2014, at 10:57, Magnus Westerlund = wrote: > On 2014-04-30 16:40, Yago Sanchez wrote: >> Hi Magnus, >>=20 >> I think there is a misunderstanding with the intention of using the >> profile-compatibility-indicator. It is not about indicating support = for >> additional profiles. The profile-compatibility-indicator sets = additional >> constraints to the profile indicated in the profile-id. That is why >> Ye-Kui was pointing that both the profile-id and the >> profile-compatibility-indicator are used to express the same as the >> profile_idc in RFC 6184. This means that if the offerer indicates >> profile-id equal to A and includes profile B in the >> profile-compatibility-indicator, the offerer would indicate = capability >> of encoding/decoding a stream that only contains the tools that are = in >> the intersection of both profiles. The offerer promise would not even = be >> that it is able to decode the full A profile, unless indicated in >> another PT. >=20 > No, I understand that this in HEVC spec indicates that although a > particular coded video sequence where the parameters in included is > compliant not only to the profile it is declared for in the profile > indicator parameter, it is also compliant to these marked in the > profile-compatibility-indicator. >=20 > However, what applies to a specific encoder instances and more = precisely > a coded video sequence (CVS) has a different meaning if one applies > these constraints to a RTP payload type. An RTP payload type has > applicability across all RTP packet streams that claims to use this > payload type. >=20 > In addition in an SDP O/A context with the rules currently in the = draft, > i.e. they apply both to the offerer and the answerer if they maintain > the payload type, that means that from a P2P session context, both > endpoints if accepting the PT, must be able to encoded and output a = CVS > which fulfils the requirements of the profile-compatibility-indicator. > Which means that you MUST have an encoder that both are aware of all = the > profiles indicated in the included instance of > profile-compatibility-indicator, i.e. you can't ignore a new profile > that you don't know anything about, if the offerer has marked this > unknown profile as being in the compability set. You also as an = answerer > must be able to determine that you can constrain your encoder > implementation to the same set of coding tools that the answerer > implementation have. >=20 >>=20 >> My understanding was that this would be useful for those cases where = two >> endpoints support different profiles but are aware of the = intersection >> with other profiles, as in the case expressed above. Thus, there = could >> express more PTs with the profile they fully support and with subsets = of >> it result of intersections with other profiles. >=20 > I think you will have to be more explicit how this is being done = within > the rules of the RTP payload format for HEVC. I don't see how you an > answerer within SDP O/A rules can accept a payload type that has a > profile=3DX value where it doesn't support X, but do support Y that is > marked within profile-compatibility-indicator. The reason is that if = the > answerer indicates support in a SendRecv m=3D section then it must be = able > to decode profile X, it also must be able to send a stream marked as > being X, but fulfilling also Y. That is not the same as being able to > send a stream according to profile Y. >=20 > The issue I am trying to make you aware of is that the combination of > sender and receiver constraints profile-compatibility-indicator > introduces does not appear to provide any benefit, only limitations = that > makes things less compatible. >=20 >>=20 >> Therefore, I still think that including = profile-compatibility-indicator >> may be useful. Would this be reasonable or is there anything I am >> missing from the discussion below? >=20 > I think you are missing something about what it implies to declare a = PT > in a sendrecv context with this parameter. It might be me missing > something, but I would like you to try to explain in detail how what = you > think is possible above actually works. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- --Apple-Mail=_8A6E5528-E819-4A70-ABB0-864BA122053D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Magnus,

I still think that profile-compatibility-indicator = may be useful. Let me list the different options I see and come finally = to a conclusion. All options are related to offerer supporting profile A = and answerer profile B.

1) Offerer includes = profile A and no profile-compatibility-indicator. Answerer cannot accept = profile A so they cannot achieve = interoperability.

2) Offerer includes profile A = and sets the flag related to profile B in the = profile-compatibility-indicator (Offerer has to be aware of the = intersection of both profiles). Answerer ist not aware of profile A and = does not know which are the tools that lay in the intersection, so again = interoperability cannot be achieved, since the answerer cannot = constraint the sent stream so that the offerer can decode = it.
Still, the use of profile-compatibility-indicator does not = harm session negotiation. The reason for not achieving interoperability = is another one.

3) Offerer includes profile A = and sets the flag related to profile B in the = profile-compatibility-indicator (Offerer has to be aware of the = intersection of both profiles). Answerer ist also aware of profile A and = the intersection with B and can accept the offer and answer with a = stream to the offerer that can be decoded.
In this case = profile-compatibility-indicator helps for achieving = interoperability.

4) The last option might be = one that could show a case where profile-compatibility-indicator could = be harmful. Lets assume profile A is a superset of profile B. The = answerer could offer profile A and set the flag corresponding to profile = B in profile-compatibility-indicator or even offer profile B and set the = flag corresponding to profile A in profile-compatibility-indicator (both = cases express the same). The answerer even though it could decode and = encode such a stream would have to reject the payload type if it is not = aware of what means to have a stream being compatible to profile A due = to not knowing profile A. I think this is what you are concern about = right?

In summary, I only see it could be = harmful in case 4. And case 4 is only the case where a full profile is = supported (in the example profile B) and all profiles that are supersets = of it are marked in the profile-compatibility-indicator. All other cases = of profiles not being supersets and being marked in = profile-compatibility-indicator would be either example 2 or = 3.

Therefore my suggestion would be to still = keep profile-compatibility-indicator, since it might achieve = interoperability as shown in example 3 and add some text that expresses = that if a profile is fully supported and profile-compatibility-indicator = does not constraint that profile further the profile-id should indicate = such a profile and profile-compatibility-indicator should not be = included. Obviously this only applies for O/A and not for declarative = session description. 

Would this make = sense for you Ye-Kui and Magnus?

Best = regards,
Yago

On 2 May = 2014, at 10:57, Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:

On 2014-04-30 16:40, Yago Sanchez = wrote:
Hi Magnus,

I think there is a = misunderstanding with the intention of using = the
profile-compatibility-indicator. It is not about indicating = support for
additional profiles. The profile-compatibility-indicator = sets additional
constraints to the profile indicated in the = profile-id. That is why
Ye-Kui was pointing that both the profile-id = and the
profile-compatibility-indicator are used to express the same = as  the
profile_idc in RFC 6184. This means that if the offerer = indicates
profile-id equal to A and includes profile B in = the
profile-compatibility-indicator, the offerer would indicate = capability
of encoding/decoding a stream that only contains the tools = that are in
the intersection of both profiles. The offerer promise = would not even be
that it is able to decode the full A profile, = unless indicated in
another PT.

No, I understand = that this in HEVC spec indicates that although a
particular coded = video sequence where the parameters in included is
compliant not only = to the profile it is declared for in the profile
indicator parameter, = it is also compliant to these marked in = the
profile-compatibility-indicator.

However, what applies to = a specific encoder instances and more precisely
a coded video = sequence (CVS) has a different meaning if one applies
these = constraints to a RTP payload type. An RTP payload type = has
applicability across all RTP packet streams that claims to use = this
payload type.

In addition in an SDP O/A context with the = rules currently in the draft,
i.e. they apply both to the offerer and = the answerer if they maintain
the payload type, that means that from = a P2P session context, both
endpoints if accepting the PT, must be = able to encoded and output a CVS
which fulfils the requirements of = the profile-compatibility-indicator.
Which means that you MUST have = an encoder that both are aware of all the
profiles indicated in the = included instance of
profile-compatibility-indicator, i.e. you can't = ignore a new profile
that you don't know anything about, if the = offerer has marked this
unknown profile as being in the compability = set. You also as an answerer
must be able to determine that you can = constrain your encoder
implementation to the same set of coding tools = that the answerer
implementation have.


My understanding was that this would be useful for = those cases where two
endpoints support different profiles but are = aware of the intersection
with other profiles, as in the case = expressed above. Thus, there could
express more PTs with the profile = they fully support and with subsets of
it result of intersections = with other profiles.

I think you will have to be = more explicit how this is being done within
the rules of the RTP = payload format for HEVC. I don't see how you an
answerer within SDP = O/A rules can accept a payload type that has a
profile=3DX value = where it doesn't support X, but do support Y that is
marked within = profile-compatibility-indicator. The reason is that if the
answerer = indicates support in a SendRecv m=3D section then it must be able
to = decode profile X, it also must be able to send a stream marked = as
being X, but fulfilling also Y. That is not the same as being able = to
send a stream according to profile Y.

The issue I am trying = to make you aware of is that the combination of
sender and receiver = constraints profile-compatibility-indicator
introduces does not = appear to provide any benefit, only limitations that
makes things = less compatible.


Therefore, I still = think that including profile-compatibility-indicator
may be useful. = Would this be reasonable or is there anything I am
missing from the = discussion below?

I think you are missing something = about what it implies to declare a PT
in a sendrecv context with this = parameter. It might be me missing
something, but I would like you to = try to explain in detail how what you
think is possible above = actually works.

Cheers

Magnus = Westerlund

--------------------------------------------------------= --------------
Services, Media and Network features, Ericsson = Research = EAB/TXM
---------------------------------------------------------------= -------
Ericsson AB =             &n= bsp;   | Phone  +46 10 7148287
F=E4r=F6gatan 6 =             &n= bsp;   | Mobile +46 73 0949079
SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsson.= com
---------------------------------------------------------------= -------


=
= = --Apple-Mail=_8A6E5528-E819-4A70-ABB0-864BA122053D-- From nobody Mon May 5 01:05: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 AAAF81A027D for ; Mon, 5 May 2014 01:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=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 wn8vljP6Z_9H for ; Mon, 5 May 2014 01:05:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7641A0280 for ; Mon, 5 May 2014 01:05:03 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-19-5367462b8d1a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.23.05409.B2647635; Mon, 5 May 2014 10:04:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Mon, 5 May 2014 10:04:58 +0200 Message-ID: <5367462A.903@ericsson.com> Date: Mon, 5 May 2014 10:04:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvja62W3qwwaeL4hanLu5jtbh08SyT xaTja9ksnqw5xuzA4jH91GJmjyVLfjJ5LJr6jNHjy+XPbAEsUVw2Kak5mWWpRfp2CVwZW/b2 sBY8d6+Yee4oawPjA6suRk4OCQETiT+72lkhbDGJC/fWs3UxcnEICRxllNhxt5MFJCEksIxR 4uhdExCbV0Bd4vHcR2wgNouAisTGlc1gNWwCFhI3fzSCxUUFgiU2PPzLDlEvKHFy5hOwGhEB Q4klqx+zgyxgFtjEKPHg93ywImEBR4kNja1MEJtvskg82/CJGSTBKeAq8WLKVKAEB9B54hI9 jUEgYWYBPYkpV1sYIWx5ieats5khDtWWaGjqYJ3AKDQLye5ZSFpmIWlZwMi8ilG0OLU4KTfd yFgvtSgzubg4P08vL7VkEyMw4A9u+a26g/HyG8dDjAIcjEo8vMVfIoOFWBPLiitzDzFKc7Ao ifN+ueUTLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRJ9T8Eu9zmYlXtZNyf2jWfFqSYqkZ VOdj2qzk99iqNCPhvZyXvL/69IT55zbdex6quFlDLGPpm4vNFd0uth0z6m5dzzGI6X47c+Pq wwL2O+qNpfZfT81dLxr58VPJvoKWPRekFYostzekyMcF+B57IJXurnLpzvp97vpbWyI0/CoT Uo6sDldiKc5INNRiLipOBABjR3IRWQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/EYHrgd0M_7NoaxQS_omUaYNIHAQ Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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, 05 May 2014 08:05:07 -0000 Hi Yago, Please see inline for comments On 2014-05-04 22:32, Yago Sanchez wrote: > Hi Magnus, > > I still think that profile-compatibility-indicator may be useful. Let me > list the different options I see and come finally to a conclusion. All > options are related to offerer supporting profile A and answerer profile B. > > 1) Offerer includes profile A and no profile-compatibility-indicator. > Answerer cannot accept profile A so they cannot achieve interoperability. > > 2) Offerer includes profile A and sets the flag related to profile B in > the profile-compatibility-indicator (Offerer has to be aware of the > intersection of both profiles). Answerer ist not aware of profile A and > does not know which are the tools that lay in the intersection, so again > interoperability cannot be achieved, since the answerer cannot > constraint the sent stream so that the offerer can decode it. > Still, the use of profile-compatibility-indicator does not harm session > negotiation. The reason for not achieving interoperability is another one. > > 3) Offerer includes profile A and sets the flag related to profile B in > the profile-compatibility-indicator (Offerer has to be aware of the > intersection of both profiles). Answerer ist also aware of profile A and > the intersection with B and can accept the offer and answer with a > stream to the offerer that can be decoded. > In this case profile-compatibility-indicator helps for achieving > interoperability. Lets look at this depending on directional attribute. Offer: a=recvonly: In this case, there was no point of offering the profile-compatibility-indicator, as that would only unnecessary restrict the answerer in its sending of the stream. Offer: a=sendonly So in this case the offerer can include the profile-compatibility-indicator and the answerer will know that the offered stream is also compliant with the marked profiles. However, I seriously question if the answerer can accept this RTP payload type. Yes, it can receive this specific stream under these constraints. However, the receiver if it accepts the RTP payload type, it promises to accept any stream that matches the RTP payload type. Thus, if one sends an additional stream under this RTP payload type what are the promise. It can't receive any stream fulfilling the profile-id parameter, it MUST also follow the constraints of the profile-compatibility-indicator. So what happens if that second encoder does not know about this profile. Then you end up in a incompatibility. Sure, with tight enforcement of that any stream you are being sent must fulfil to have the same profile-compatibility-indicator as negotiated, it can work. Offer: a=sendrecv Answerer: a=recvonly Equal to above Offer: a=sendrecv Answerer: a=sendonly The answerer will not accept to receive the stream from Offerer, thus the answerer can accept the payload type, given that it can provided a stream matching the RTP payload type. However, as in this scenario the answerer don't support the offered profile-id, only a another supported profile. Thus, it doesn't fulfil the payload type and must reject it. Offer: a=sendrecv Answerer: a=sendrecv In this case the answerer must reject the RTP payload on the grounds that it can't send the offerer a stream matching the RTP payload type, see just above with answerer:sendonly. Thus, I would say that it provides some benefit in the cases the offerer will only send the stream to answerer, but in no other cases. Also, this might give the offerer the wrong impression, and if one tries to modify the session to bi-directional streams, then this fails per the other options. Lets instead look at the option to include one payload type per compatible profile that the encoder can send, i.e. each profile marked in profile-compatibility-indicator will get its own RTP payload type: Offer: a=recvonly: Given that the decoder has the capability for all profiles the encoder could produce, the compatibility would be maximized. However, this is mostly irrelvant in this comparision. Offer: a=sendonly If the offerer includes both the intended profile and one for the compatible, then the answer rejects the intended one and accepts the PT for the compatible one. Things work, given that the answerer accepts a bitstream with profile-Id = intended and profile-compatibility-indicator=compatible one. Offer: a=sendrecv Answerer: a=recvonly Equal to above with the additional benefit that the offerer knows which profile the answerer supports to receive and likely send. Offer: a=sendrecv Answerer: a=sendonly To be able to offer this, the offerer must also be able to receive the compatible profile(s). If it doesn't then it can't offer multiple profiles and then we anyway have compatibility rejection. Offer: a=sendrecv Answerer: a=sendrecv To be able to offer this, the offerer must also be able to receive the compatible profile(s). If not we have failure as there is no compatible profile both can produce. If it can we have interoperability, and answerer indicates that it can only produce the other profile. You might now better understand why I bring this up. It mostly fails or appear to have none intentional restrictions. So I will admit that profile-compatibility-indicator provides a benefit if, and only if one offers sendonly streams, or ends up in sendonly from the party offering the profile-compatibility-indicator. This appears to indicate that having this as a sender constraint only would reduce the cases where it restricts. However, in this case one do loose the possibility to negotiate for a central mixer case, that you must produce a stream that fulfils the subset of these profiles. I do note that it appear necessary to make it clear that one MUST accept a video bitstream as long as its profile-id or profile-compatibility-indicator indicates the profile one has negotiated for the payload type. Is that clear in the HEVC specification? Does it need to be repeated in the payload format to prevent packetizers and others to make this error if they look slightly into the bitstream? However, if we are getting into this detail of negotiation, then I would suggest that we create one profile-compatibility-indicator signalling attribute per send and receive direction. So that one can have senders constraints without the receive constraints. > > 4) The last option might be one that could show a case where > profile-compatibility-indicator could be harmful. Lets assume profile A > is a superset of profile B. The answerer could offer profile A and set > the flag corresponding to profile B in profile-compatibility-indicator > or even offer profile B and set the flag corresponding to profile A in > profile-compatibility-indicator (both cases express the same). The > answerer even though it could decode and encode such a stream would have > to reject the payload type if it is not aware of what means to have a > stream being compatible to profile A due to not knowing profile A. I > think this is what you are concern about right? It is one of my concerns, and depends on interpretation of the profile-compatibility-indicator. This is only relevant if one is forced to use the profile-compatibility-indicator as send direction constraint in an encoder. In a reception only case, one can look for just a profile one supports. Which further speaks for splitting the send and receiver constrints. > > In summary, I only see it could be harmful in case 4. And case 4 is only > the case where a full profile is supported (in the example profile B) > and all profiles that are supersets of it are marked in the > profile-compatibility-indicator. All other cases of profiles not being > supersets and being marked in profile-compatibility-indicator would be > either example 2 or 3. > > Therefore my suggestion would be to still keep > profile-compatibility-indicator, since it might achieve interoperability > as shown in example 3 and add some text that expresses that if a profile > is fully supported and profile-compatibility-indicator does not > constraint that profile further the profile-id should indicate such a > profile and profile-compatibility-indicator should not be included. > Obviously this only applies for O/A and not for declarative session > description. I hope my above extension of your cases allows you to better see my concerns with the current specification of the profile-compatibility-indicator. If one would divide them into sender and receive direction some of the issues goes away. 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 May 5 17:38: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 5A4C01A0479 for ; Mon, 5 May 2014 17:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 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_18=0.6, RP_MATCHES_RCVD=-0.651, 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 3XUYGuSxF7-q for ; Mon, 5 May 2014 17:38:35 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 544141A04A6 for ; Mon, 5 May 2014 17:38:35 -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=1399336713; x=1430872713; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BZIcpJQVEJEUFagm+yYfCnwk7BIl83C+Nx/Eracwtd8=; b=aYvqTCMacAy9S+i8J+6DBEFFd+Mb28FqVXw15brQFduEaWv1ML408BL1 lFtr+9sM/tDznQzt09Gqc6yOr2zplVGMow/u0i4p0rClRbSwF2uH5f00w EOdpai10bOFKS9G8nA9bLI4VvMx6DqKtc559X5WXxBS/w03QAh/SnRWm0 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7429"; a="63080261" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 05 May 2014 17:38:32 -0700 X-IronPort-AV: E=Sophos;i="4.97,992,1389772800"; d="scan'208";a="727270970" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 May 2014 17:38:31 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.03.0158.001; Mon, 5 May 2014 17:38:39 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplg Date: Tue, 6 May 2014 00:38:37 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> In-Reply-To: <5367462A.903@ericsson.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/4CGncjA4xvTFCN7IH4w53r7FHws Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 06 May 2014 00:38:40 -0000 Hi Magnus, Yago, Thanks for having the discussion ongoing. See my comments inline below.=20 For easy of discussion, I numbered the different cases. I am hoping that th= rough these discussions, we all would have a more comprehensive, and on-the= -same-page, understanding on this issue. Then it should be easy to conclude= how to proceed. BR, YK -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, May 05, 2014 1:05 AM To: Yago Sanchez Cc: Wang, Ye-Kui; payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.= org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi Yago, Please see inline for comments On 2014-05-04 22:32, Yago Sanchez wrote: > Hi Magnus, >=20 > I still think that profile-compatibility-indicator may be useful. Let=20 > me list the different options I see and come finally to a conclusion.=20 > All options are related to offerer supporting profile A and answerer prof= ile B. >=20 > 1) Offerer includes profile A and no profile-compatibility-indicator. > Answerer cannot accept profile A so they cannot achieve interoperability. >=20 > 2) Offerer includes profile A and sets the flag related to profile B=20 > in the profile-compatibility-indicator (Offerer has to be aware of the=20 > intersection of both profiles). Answerer ist not aware of profile A=20 > and does not know which are the tools that lay in the intersection, so=20 > again interoperability cannot be achieved, since the answerer cannot=20 > constraint the sent stream so that the offerer can decode it. > Still, the use of profile-compatibility-indicator does not harm=20 > session negotiation. The reason for not achieving interoperability is ano= ther one. >=20 > 3) Offerer includes profile A and sets the flag related to profile B=20 > in the profile-compatibility-indicator (Offerer has to be aware of the=20 > intersection of both profiles). Answerer ist also aware of profile A=20 > and the intersection with B and can accept the offer and answer with a=20 > stream to the offerer that can be decoded. > In this case profile-compatibility-indicator helps for achieving=20 > interoperability. Lets look at this depending on directional attribute. Case 1: Offer: a=3Drecvonly: In this case, there was no point of offering the profile-compatibility-indi= cator, as that would only unnecessary restrict the answerer in its sending = of the stream. [YK]: There can be still be a point to offer profile-compatibility-indicato= r in this case. For example, it is possible that the decoder of the offerer= only supports the common tools of profiles A and B, while it does not supp= ort either full profile A or full profile B. Think about similar situation = for the AVC Constrained Baseline profile, which contains the common tools o= f the Baseline profile and the Main profile, and was defined after the defi= nitions of the Baseline profile and the Main profile, and uses the same pro= file_idc as the Baseline profile. Similar situations could happen for HEVC.= Note that this can also happen when the direction attribute has other valu= es. Case 2: Offer: a=3Dsendonly So in this case the offerer can include the profile-compatibility-indicator= and the answerer will know that the offered stream is also compliant with = the marked profiles. However, I seriously question if the answerer can acce= pt this RTP payload type. Yes, it can receive this specific stream under these constraints. However, the receiver if it accepts the RTP payload type, it promises to ac= cept any stream that matches the RTP payload type. Thus, if one sends an ad= ditional stream under this RTP payload type what are the promise. It can't receive any stream fulfilling the profile-id parameter, it MUST al= so follow the constraints of the profile-compatibility-indicator. So what h= appens if that second encoder does not know about this profile. Then you end up in a incompatibility. Sure, with tight enforcement of that = any stream you are being sent must fulfil to have the same profile-compatib= ility-indicator as negotiated, it can work. [YK]: I see your point. In this case, if the offerer both profile A and pro= file B (by profile-id together with profile-compatibility-indicator), while= the answerer understands profile A but does not understand profile B, the = answerer can actually still accept the offer for the video communication fr= om the offerer-to-answerer direction. However, for the other direction (ans= werer-to-offerer direction), the answerer does not know which tools to disa= ble when encoding the video, there is no way to ensure interoperable video = media in this direction. So, this can only work for single-direction commun= ication, or declarative mode. Case 3: Offer: a=3Dsendrecv Answerer: a=3Drecvonly Equal to above [YK]: Agreed, and my above comments apply. Case 4: Offer: a=3Dsendrecv Answerer: a=3Dsendonly The answerer will not accept to receive the stream from Offerer, thus the a= nswerer can accept the payload type, given that it can provided a stream ma= tching the RTP payload type. However, as in this scenario the answerer don'= t support the offered profile-id, only a another supported profile. Thus, i= t doesn't fulfil the payload type and must reject it. [YK]: I don't understand the first part above (thus the answerer can accept= the payload type ...) - maybe there is a typo. But you second part seems t= o be aligned with my understanding, which is as follows (just to make the e= xample clearer such that we are talking about the same thing). In this case= , if the offerer indicates profile A and profile B (by profile-id together = with profile-compatibility-indicator), while the answerer understands profi= le A but does not understand profile B, since the answerer does not know wh= ich tools to disable when encoding the video, there is no way to ensure int= eroperable video media in this direction, thus it has to reject the payload= type. Case 5: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv In this case the answerer must reject the RTP payload on the grounds that i= t can't send the offerer a stream matching the RTP payload type, see just a= bove with answerer:sendonly. Thus, I would say that it provides some benefit in the cases the offerer wi= ll only send the stream to answerer, but in no other cases. Also, this migh= t give the offerer the wrong impression, and if one tries to modify the ses= sion to bi-directional streams, then this fails per the other options. [YK]: The conclusion here should be slightly changed per Case 1. One optimi= zation we can do here is to relax the constraint (that both profile_id and = profile-compatibility-indicator must remain unchanged in offer and answer) = a bit to enable Cases 2 and 3 (for single-direction from offerer to answere= r, or declarative usage). For other cases, the current constraint applies (= or as I said earlier, profile_id and profile-compatibility-indicator in bot= h offer and answer must indicate the same set of encoding tools supported). Lets instead look at the option to include one payload type per compatible = profile that the encoder can send, i.e. each profile marked in profile-comp= atibility-indicator will get its own RTP payload type: Case 6: Offer: a=3Drecvonly: Given that the decoder has the capability for all profiles the encoder coul= d produce, the compatibility would be maximized. However, this is mostly ir= relvant in this comparision. [YK]: See discussions above for Case 1. This case can actually be split int= o two cases. Case 6.1: if the decoder does fully support each of the multip= le profiles, then using one payload type for each of these profiles is OK. = Case 6.2: if the decoder only supports the common tools of a list of profil= es but not fully for each of the profiles, then using one payload type for = each of these profiles is NOT OK. Case 7: Offer: a=3Dsendonly If the offerer includes both the intended profile and one for the compatibl= e, then the answer rejects the intended one and accepts the PT for the comp= atible one. Things work, given that the answerer accepts a bitstream with p= rofile-Id =3D intended and profile-compatibility-indicator=3Dcompatible one= . [YK]: My above comments for Case 6 apply. Case 8: Offer: a=3Dsendrecv Answerer: a=3Drecvonly Equal to above with the additional benefit that the offerer knows which pro= file the answerer supports to receive and likely send. [YK]: My above comments for Case 6 apply. Case 9: Offer: a=3Dsendrecv Answerer: a=3Dsendonly To be able to offer this, the offerer must also be able to receive the comp= atible profile(s). If it doesn't then it can't offer multiple profiles and = then we anyway have compatibility rejection. [YK]: My above comments for Case 6 apply. Case 10: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv To be able to offer this, the offerer must also be able to receive the comp= atible profile(s). If not we have failure as there is no compatible profile= both can produce. If it can we have interoperability, and answerer indicat= es that it can only produce the other profile. [YK]: My above comments for Case 6 apply. You might now better understand why I bring this up. It mostly fails or app= ear to have none intentional restrictions. So I will admit that profile-compatibility-indicator provides a benefit if,= and only if one offers sendonly streams, or ends up in sendonly from the p= arty offering the profile-compatibility-indicator. This appears to indicate= that having this as a sender constraint only would reduce the cases where = it restricts. However, in this case one do loose the possibility to negotia= te for a central mixer case, that you must produce a stream that fulfils th= e subset of these profiles. I do note that it appear necessary to make it c= lear that one MUST accept a video bitstream as long as its profile-id or pr= ofile-compatibility-indicator indicates the profile one has negotiated for = the payload type. Is that clear in the HEVC specification? Does it need to = be repeated in the payload format to prevent packetizers and others to make= this error if they look slightly into the bitstream? However, if we are getting into this detail of negotiation, then I would su= ggest that we create one profile-compatibility-indicator signalling attribu= te per send and receive direction. So that one can have senders constraints= without the receive constraints. [YK]: I hope with my above comments, particularly those under Case 1, some = of the conclusions above would be adjusted. And also please check my sugges= tion in the comments under Case 5. >=20 > 4) The last option might be one that could show a case where=20 > profile-compatibility-indicator could be harmful. Lets assume profile=20 > A is a superset of profile B. The answerer could offer profile A and=20 > set the flag corresponding to profile B in=20 > profile-compatibility-indicator or even offer profile B and set the=20 > flag corresponding to profile A in profile-compatibility-indicator=20 > (both cases express the same). The answerer even though it could=20 > decode and encode such a stream would have to reject the payload type=20 > if it is not aware of what means to have a stream being compatible to=20 > profile A due to not knowing profile A. I think this is what you are conc= ern about right? It is one of my concerns, and depends on interpretation of the profile-comp= atibility-indicator. This is only relevant if one is forced to use the prof= ile-compatibility-indicator as send direction constraint in an encoder. In = a reception only case, one can look for just a profile one supports. Which = further speaks for splitting the send and receiver constrints. [YK]: This is the same as Cases 4 and 5 above. >=20 > In summary, I only see it could be harmful in case 4. And case 4 is=20 > only the case where a full profile is supported (in the example=20 > profile B) and all profiles that are supersets of it are marked in the=20 > profile-compatibility-indicator. All other cases of profiles not being=20 > supersets and being marked in profile-compatibility-indicator would be=20 > either example 2 or 3. >=20 > Therefore my suggestion would be to still keep=20 > profile-compatibility-indicator, since it might achieve=20 > interoperability as shown in example 3 and add some text that=20 > expresses that if a profile is fully supported and=20 > profile-compatibility-indicator does not constraint that profile=20 > further the profile-id should indicate such a profile and profile-compati= bility-indicator should not be included. > Obviously this only applies for O/A and not for declarative session=20 > description. I hope my above extension of your cases allows you to better see my concern= s with the current specification of the profile-compatibility-indicator. If= one would divide them into sender and receive direction some of the issues= goes away. [YK]: I think I now do see your points in Case 2 and 3, and as I said above= , we can do some optimization (see again my suggestion above under Case 2).= However, considering my above comments, particularly those under Case 1, I= hope we can have a more comprehensive, and on-the-same-page understanding = on this issue. From nobody Tue May 6 01:05:50 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 532271A0572 for ; Tue, 6 May 2014 01:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 21pELMg_k3Zx for ; Tue, 6 May 2014 01:05:47 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD61A0728 for ; Tue, 6 May 2014 01:05:46 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Received: from maclaptop002.ic.tu-berlin.de (maclaptop002.ic.tu-berlin.de [130.149.228.68]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id F1A9F186803D; Tue, 6 May 2014 10:05:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yago Sanchez In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> Date: Tue, 6 May 2014 10:05:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20676.006 X-TM-AS-Result: No--11.305-11.0-31-10 X-imss-scan-details: No--11.305-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: X4bcv0S75Kk/FLJq3yHG9ZciNJzaqUX1CQ3xS+zL6e3agsZM0qVv18ux W1Xm4BegBMhVYRT3oC+2dtYUSUBbTCZywmJvYiNpz5rIW0RbS5gLce5ZyDJAJhg+C+mOIAG21fc e4C9pfzJeTqY5d+9GYOU9Y5l2egV8y7OaxHPhxP+zI1v7J4hECsAzJgO8Cv2mNwCgQD6pGqYmfs 5a44EdZwswLGS5Or9kpsOhFeFsiM0oZZgCxeSxyEhEDfw/93Bu1KoSW5Ji1XswyfWtyopBqAeII WbJ+nYwhdVBhzYvcP408c4i3eLsKpldEUybktN8xFLSluI58puFXSyuOiq3HwlbhF7ZTanLtKRk nI5K5Gv/tpXs4dBHBikbtN4uf006TR46EMdjJlaeAiCmPx4NwMHGqwpJzOMi+gD2vYtOFhgqtq5 d3cxkNYzzTLFRnsvHHVN0WO3YnVl7Fb2+l2eyqmQaLB9R0smpBa8DjtnnYOA= X-IMSS-DKIM-White-List: No X-alterMIME: Yes Archived-At: http://mailarchive.ietf.org/arch/msg/payload/HT9jQiFFokzlPduj4jSafzvgV3s Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id 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, 06 May 2014 08:05:49 -0000 Hi Magnus,=20 Let me bring the discussion on recv-sub-layer-id back so that I = understand your point here. (removed the rest of the discussion for = clarity). Following the example Ye-Kui provided with two operation points = (sub-layers) 720p@30fps and 720p@15fps, lets assume the offerer includes = a payload type with profile-id and level-id for 720p@30 fps. What do you mean when you say =93the recv-sub-layer-id is fine as a = stream specific selection mechanism, but does not replace the capability = declaration the regular parameters perform=94? Does it mean that if the = answerer accepts the payload type with recv-sub-layer-id equal to 0 in = the answer (without level downgrade), it is selecting 720p@15fps but = actually is indicating to have capabilities that match the profile-id = and level-id of 720p@30 fps? Best regards, Yago On 25 Apr 2014, at 19:56, Wang, Ye-Kui wrote: >=20 >> [YK]: Let's use an example, which should help. Let's say the offer = SDP=20 >> includes a VPS that provides two operation points, 720p@15fps and=20 >> 720p@30fps, corresponding to recv-sub-layer-id 0 and 1, respectively. >> The profile, tier, level, and so on for each operation point are=20 >> signalled by the VPS. If recv-sub-layer-id=3D0 is included in an SDP=20= >> answer, then that means the answerer chooses to operate at = 720p@15fps.=20 >> In this case, the profile, tier, level, and so on for the chosen=20 >> operation point does not need to be explicitly sent again in the SDP,=20= >> as it is clear what they are (they are signalled in the VPS in the = SDP=20 >> offer). So there is no ambiguity here. Are you suggesting that in = some=20 >> use cases even there is no ambiguity the configuration information=20 >> must always be explicitly signalled (i.e. values that are derivable)?=20= >> If yes, could you please explain in what use cases and why. Note that=20= >> we had the same mechanism specified for SVC in RFC 6190. Also, on PT=20= >> use, we have allowed the use of a different PT value in an SDP answer=20= >> than the matching PT value in the offer since at least RFC 3984 as=20 >> long as the PT matching is clear. >=20 > Okay, I can now put the finger on what troubles me with this. I think = this is violation or at least an omission of the principle of SDP = Offer/Answer. The reason is that you substitute the answering explicitly = declaring its receiving capabilities with a reference to a particular = instantiation of a video sequence parameter set that falls within the = receiver's capabilities. Thus, the offerer does not know the receiver's = actually capabilities if it needs to reconfigure the encoder, or in case = the RTP payload type is going to be used by multiple media streams and = possibly different encoder instances. >=20 > In addition it creates an issue for any middlebox that is on the = signalling path that it keeps track and state for what was in the offer = to know what the answer means. >=20 > Thus, I think it is important that the answerer doesn't treat this = situation differently, and instead declare its capabilities as normally = in answer. The recv-sub-layer-id parameter is an optional parameter and = it is also stream specific, while the profile, level, etc are = generically applicable to the RTP payload type do applies on RTP session = level. >=20 > To conclude, the recv-sub-layer-id is fine as a stream specific = selection mechanism, but does not replace the capability declaration the = regular parameters perform. >=20 From nobody Tue May 6 02:28:34 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 1938D1A0775 for ; Tue, 6 May 2014 02:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SkGzF-7tfVFT for ; Tue, 6 May 2014 02:28:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5F1A029C for ; Tue, 6 May 2014 02:28:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-58-5368ab3a2bec Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.C8.04714.A3BA8635; Tue, 6 May 2014 11:28:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Tue, 6 May 2014 11:28:26 +0200 Message-ID: <5368AB3A.4050805@ericsson.com> Date: Tue, 6 May 2014 11:28:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvja716oxgg8vd3BanLu5jtbh08SyT xaTja9ksnqw5xuzA4jH91GJmjyVLfjJ5LJr6jNHjy+XPbAEsUVw2Kak5mWWpRfp2CVwZTSuv sBR84q1Y3/2QuYFxNXcXIweHhICJxLmfIV2MnECmmMSFe+vZuhi5OIQEjjJKHFx1hRnCWcYo 8f3dPhaQBl4BbYkTS0xAGlgEVCQu3Z/DBGKzCVhI3PzRyAZiiwoES2x4+JcdxOYVEJQ4OfMJ C4gtImAosWT1Y7A4s8AWRokrd5xBbGGBcIm1bQuhFv9kkvj07DczSIJTwFViWlMPC8Sh4hI9 jUEQvQYSRxbNYYWw5SWat84GKxcCOq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypG0eLU4uLcdCNj vdSizOTi4vw8vbzUkk2MwGA/uOW37g7G1a8dDzEKcDAq8fDuac0IFmJNLCuuzD3EKM3BoiTO 23bXO1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo8DMOwZ87TMzJeokdZMe2P6590B1T3Pn 8q+uQpEuhgY67P7rZp1paivlts3q6IifVCkzgedhwYmMkOfvCk0k7xqpXE978YLziKzL8RMb tNL/fvVNybnZO/X4r+UX/M7IssxPVAh4PP9deGYJA8cFjjrFG6qz+Wf/nZNU0bV7UUbgthw2 FzsrJZbijERDLeai4kQAMfnQNlcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Q32EIyEBWePF6u1SgKuq8NJwcGg Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id 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, 06 May 2014 09:28:33 -0000 On 2014-05-06 10:05, Yago Sanchez wrote: > Hi Magnus, > > Let me bring the discussion on recv-sub-layer-id back so that I > understand your point here. (removed the rest of the discussion for > clarity). Following the example Ye-Kui provided with two operation > points (sub-layers) 720p@30fps and 720p@15fps, lets assume the > offerer includes a payload type with profile-id and level-id for > 720p@30 fps. > > What do you mean when you say “the recv-sub-layer-id is fine as a > stream specific selection mechanism, but does not replace the > capability declaration the regular parameters perform”? Does it mean > that if the answerer accepts the payload type with recv-sub-layer-id > equal to 0 in the answer (without level downgrade), it is selecting > 720p@15fps but actually is indicating to have capabilities that match > the profile-id and level-id of 720p@30 fps? > Yes, that is the crux of the issue. The payload type states that you have the 720p@30fps capability, as you haven't changed your profile or level. While receive-sub-layer-id can point to that lower capability 720p@15fps. That is a contradiction. In addition using a pointer to value in the offer, results that the actual value is not directly available when parsing the answer. 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 Tue May 6 02:56: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 61F941A0659 for ; Tue, 6 May 2014 02:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=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 dkRp5I1bigPK for ; Tue, 6 May 2014 02:56:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id D2F621A029B for ; Tue, 6 May 2014 02:56:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-3c-5368b1bdb370 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.0D.05066.DB1B8635; Tue, 6 May 2014 11:56:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.174.1; Tue, 6 May 2014 11:56:12 +0200 Message-ID: <5368B1BC.5070104@ericsson.com> Date: Tue, 6 May 2014 11:56:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@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+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvje7ejRnBBvvuK1icuriP1eLSxbNM FpOOr2WzeLLmGLMDi8f0U4uZPZYs+cnksWjqM0aPL5c/swWwRHHZpKTmZJalFunbJXBlnJzc w1ZwoYWxYv55zgbGtdldjBwcEgImEvs/BnQxcgKZYhIX7q1n62Lk4hASOMoo8eNKCxNIQkhg GaPE1BfVIDavgLbEjZ3PGUFsFgEViaan/SwgNpuAhcTNH41sILaoQLDEhod/2SHqBSVOznzC ArJLRCBW4tUNQZD5zAIdjBLnt30DqxEWcJTY0NjKBLF4D6vEo6sQgziBBq040s0Mcai4RE9j EEiYWUBPYsrVFkYIW16ieetsZog7tSUamjpYJzAKzUKyehaSlllIWhYwMq9iFC1OLS7OTTcy 0kstykwuLs7P08tLLdnECAz2g1t+W+1gPPjc8RCjAAejEg/v7taMYCHWxLLiytxDjNIcLEri vJMWuQcLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAxf9iNmfvvDxdq/folXXG5tOja9qNVz nfVN8Q/ZATPbeBS/Xp18aPeSP13/D67eNFfy7dX9eQn/LGo1nltVMGyd+85JLbPq/htmtgpD 9R2HXp5vFjVYsnthdOgcp9iIvdFtMx9vaEi+78XqXX/l7tJzPt36J79NFCo3eVDwl7n0uKbV zrd5Gy4qsRRnJBpqMRcVJwIA+kYZ21cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/yfwvBixJbympcSzNefxaOQHyQuw Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 06 May 2014 09:56:21 -0000 On 2014-05-06 02:38, Wang, Ye-Kui wrote: > Hi Magnus, Yago, > > Thanks for having the discussion ongoing. See my comments inline > below. > > For easy of discussion, I numbered the different cases. I am hoping > that through these discussions, we all would have a more > comprehensive, and on-the-same-page, understanding on this issue. > Then it should be easy to conclude how to proceed. > > BR, YK > > -----Original Message----- From: Magnus Westerlund > [mailto:magnus.westerlund@ericsson.com] Sent: Monday, May 05, 2014 > 1:05 AM To: Yago Sanchez Cc: Wang, Ye-Kui; payload@ietf.org; > draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload] > Comments on draft-ietf-payload-rtp-h265-02 > > Hi Yago, > > Please see inline for comments > > On 2014-05-04 22:32, Yago Sanchez wrote: >> Hi Magnus, >> >> I still think that profile-compatibility-indicator may be useful. >> Let me list the different options I see and come finally to a >> conclusion. All options are related to offerer supporting profile A >> and answerer profile B. >> >> 1) Offerer includes profile A and no >> profile-compatibility-indicator. Answerer cannot accept profile A >> so they cannot achieve interoperability. >> >> 2) Offerer includes profile A and sets the flag related to profile >> B in the profile-compatibility-indicator (Offerer has to be aware >> of the intersection of both profiles). Answerer ist not aware of >> profile A and does not know which are the tools that lay in the >> intersection, so again interoperability cannot be achieved, since >> the answerer cannot constraint the sent stream so that the offerer >> can decode it. Still, the use of profile-compatibility-indicator >> does not harm session negotiation. The reason for not achieving >> interoperability is another one. >> >> 3) Offerer includes profile A and sets the flag related to profile >> B in the profile-compatibility-indicator (Offerer has to be aware >> of the intersection of both profiles). Answerer ist also aware of >> profile A and the intersection with B and can accept the offer and >> answer with a stream to the offerer that can be decoded. In this >> case profile-compatibility-indicator helps for achieving >> interoperability. > > Lets look at this depending on directional attribute. > > Case 1: Offer: a=recvonly: In this case, there was no point of > offering the profile-compatibility-indicator, as that would only > unnecessary restrict the answerer in its sending of the stream. > > [YK]: There can be still be a point to offer > profile-compatibility-indicator in this case. For example, it is > possible that the decoder of the offerer only supports the common > tools of profiles A and B, while it does not support either full > profile A or full profile B. Think about similar situation for the > AVC Constrained Baseline profile, which contains the common tools of > the Baseline profile and the Main profile, and was defined after the > definitions of the Baseline profile and the Main profile, and uses > the same profile_idc as the Baseline profile. Similar situations > could happen for HEVC. Note that this can also happen when the > direction attribute has other values. Then the decoder is not compliant with any profile of A and B, if it only supports the common subset. But, at least we share the interpretation of what the profile-compatibility-indicator means in this case. The answer's encoder MUST be capable of producing a bitstream that fulfils the resulting constraint of producing a bitstream that is decodable with a decoder compliant according to either profile A or B or both. >From my perspective and in the interest of efficient profile handling and interoperability, if we care about the intersection of profiles A and B, then define profile C that is that intersection. Don't play around with this mechanism to achieve this. Thus, I still think this is unnecessarily constraint on the answerer's encoder. > > Case 2: Offer: a=sendonly So in this case the offerer can include the > profile-compatibility-indicator and the answerer will know that the > offered stream is also compliant with the marked profiles. However, I > seriously question if the answerer can accept this RTP payload type. > Yes, it can receive this specific stream under these constraints. > However, the receiver if it accepts the RTP payload type, it promises > to accept any stream that matches the RTP payload type. Thus, if one > sends an additional stream under this RTP payload type what are the > promise. It can't receive any stream fulfilling the profile-id > parameter, it MUST also follow the constraints of the > profile-compatibility-indicator. So what happens if that second > encoder does not know about this profile. Then you end up in a > incompatibility. Sure, with tight enforcement of that any stream you > are being sent must fulfil to have the same > profile-compatibility-indicator as negotiated, it can work. > > [YK]: I see your point. In this case, if the offerer both profile A > and profile B (by profile-id together with > profile-compatibility-indicator), while the answerer understands > profile A but does not understand profile B, the answerer can > actually still accept the offer for the video communication from the > offerer-to-answerer direction. However, for the other direction > (answerer-to-offerer direction), the answerer does not know which > tools to disable when encoding the video, there is no way to ensure > interoperable video media in this direction. So, this can only work > for single-direction communication, or declarative mode. Correct! > > Case 3: Offer: a=sendrecv Answerer: a=recvonly > > Equal to above > > [YK]: Agreed, and my above comments apply. > > Case 4: Offer: a=sendrecv Answerer: a=sendonly The answerer will not > accept to receive the stream from Offerer, thus the answerer can > accept the payload type, given that it can provided a stream matching > the RTP payload type. However, as in this scenario the answerer don't > support the offered profile-id, only a another supported profile. > Thus, it doesn't fulfil the payload type and must reject it. > > [YK]: I don't understand the first part above (thus the answerer can > accept the payload type ...) - maybe there is a typo. But you second > part seems to be aligned with my understanding, which is as follows > (just to make the example clearer such that we are talking about the > same thing). In this case, if the offerer indicates profile A and > profile B (by profile-id together with > profile-compatibility-indicator), while the answerer understands > profile A but does not understand profile B, since the answerer does > not know which tools to disable when encoding the video, there is no > way to ensure interoperable video media in this direction, thus it > has to reject the payload type. Correct! > > Case 5: Offer: a=sendrecv Answerer: a=sendrecv > > In this case the answerer must reject the RTP payload on the grounds > that it can't send the offerer a stream matching the RTP payload > type, see just above with answerer:sendonly. > > Thus, I would say that it provides some benefit in the cases the > offerer will only send the stream to answerer, but in no other cases. > Also, this might give the offerer the wrong impression, and if one > tries to modify the session to bi-directional streams, then this > fails per the other options. > > [YK]: The conclusion here should be slightly changed per Case 1. One > optimization we can do here is to relax the constraint (that both > profile_id and profile-compatibility-indicator must remain unchanged > in offer and answer) a bit to enable Cases 2 and 3 (for > single-direction from offerer to answerer, or declarative usage). For > other cases, the current constraint applies (or as I said earlier, > profile_id and profile-compatibility-indicator in both offer and > answer must indicate the same set of encoding tools supported). Yes, I only looked at the implications of one direction as they was sufficient to reject the payload type. In the other direction it learns that it can receive it. But, they are still not compatible for bi-directional communication. Sorry, I don't understand your proposal for relaxing the constraints. > > > Lets instead look at the option to include one payload type per > compatible profile that the encoder can send, i.e. each profile > marked in profile-compatibility-indicator will get its own RTP > payload type: > > Case 6: Offer: a=recvonly: Given that the decoder has the capability > for all profiles the encoder could produce, the compatibility would > be maximized. However, this is mostly irrelvant in this comparision. > > [YK]: See discussions above for Case 1. This case can actually be > split into two cases. Case 6.1: if the decoder does fully support > each of the multiple profiles, then using one payload type for each > of these profiles is OK. Case 6.2: if the decoder only supports the > common tools of a list of profiles but not fully for each of the > profiles, then using one payload type for each of these profiles is > NOT OK. Yes, but that means going into sub-profiles, rather than assuming that the decoder is compliant with particular profiles. I don't think we should go into that discussion and the resulting issues. > > Case 7: Offer: a=sendonly If the offerer includes both the intended > profile and one for the compatible, then the answer rejects the > intended one and accepts the PT for the compatible one. Things work, > given that the answerer accepts a bitstream with profile-Id = > intended and profile-compatibility-indicator=compatible one. > > [YK]: My above comments for Case 6 apply. > > Case 8: Offer: a=sendrecv Answerer: a=recvonly Equal to above with > the additional benefit that the offerer knows which profile the > answerer supports to receive and likely send. > > [YK]: My above comments for Case 6 apply. > > Case 9: Offer: a=sendrecv Answerer: a=sendonly To be able to offer > this, the offerer must also be able to receive the compatible > profile(s). If it doesn't then it can't offer multiple profiles and > then we anyway have compatibility rejection. > > [YK]: My above comments for Case 6 apply. > > Case 10: Offer: a=sendrecv Answerer: a=sendrecv To be able to offer > this, the offerer must also be able to receive the compatible > profile(s). If not we have failure as there is no compatible profile > both can produce. If it can we have interoperability, and answerer > indicates that it can only produce the other profile. > > [YK]: My above comments for Case 6 apply. > > You might now better understand why I bring this up. It mostly fails > or appear to have none intentional restrictions. > > So I will admit that profile-compatibility-indicator provides a > benefit if, and only if one offers sendonly streams, or ends up in > sendonly from the party offering the profile-compatibility-indicator. > This appears to indicate that having this as a sender constraint only > would reduce the cases where it restricts. However, in this case one > do loose the possibility to negotiate for a central mixer case, that > you must produce a stream that fulfils the subset of these profiles. > I do note that it appear necessary to make it clear that one MUST > accept a video bitstream as long as its profile-id or > profile-compatibility-indicator indicates the profile one has > negotiated for the payload type. Is that clear in the HEVC > specification? Does it need to be repeated in the payload format to > prevent packetizers and others to make this error if they look > slightly into the bitstream? > > However, if we are getting into this detail of negotiation, then I > would suggest that we create one profile-compatibility-indicator > signalling attribute per send and receive direction. So that one can > have senders constraints without the receive constraints. > > [YK]: I hope with my above comments, particularly those under Case 1, > some of the conclusions above would be adjusted. And also please > check my suggestion in the comments under Case 5. To repeat, I don't think we shall support sub-profile support. Secondly, I don't understand what you meant in case 5. > >> >> 4) The last option might be one that could show a case where >> profile-compatibility-indicator could be harmful. Lets assume >> profile A is a superset of profile B. The answerer could offer >> profile A and set the flag corresponding to profile B in >> profile-compatibility-indicator or even offer profile B and set the >> flag corresponding to profile A in profile-compatibility-indicator >> (both cases express the same). The answerer even though it could >> decode and encode such a stream would have to reject the payload >> type if it is not aware of what means to have a stream being >> compatible to profile A due to not knowing profile A. I think this >> is what you are concern about right? > > It is one of my concerns, and depends on interpretation of the > profile-compatibility-indicator. This is only relevant if one is > forced to use the profile-compatibility-indicator as send direction > constraint in an encoder. In a reception only case, one can look for > just a profile one supports. Which further speaks for splitting the > send and receiver constrints. > > [YK]: This is the same as Cases 4 and 5 above. > >> >> In summary, I only see it could be harmful in case 4. And case 4 is >> only the case where a full profile is supported (in the example >> profile B) and all profiles that are supersets of it are marked in >> the profile-compatibility-indicator. All other cases of profiles >> not being supersets and being marked in >> profile-compatibility-indicator would be either example 2 or 3. >> >> Therefore my suggestion would be to still keep >> profile-compatibility-indicator, since it might achieve >> interoperability as shown in example 3 and add some text that >> expresses that if a profile is fully supported and >> profile-compatibility-indicator does not constraint that profile >> further the profile-id should indicate such a profile and >> profile-compatibility-indicator should not be included. Obviously >> this only applies for O/A and not for declarative session >> description. > > I hope my above extension of your cases allows you to better see my > concerns with the current specification of the > profile-compatibility-indicator. If one would divide them into sender > and receive direction some of the issues goes away. > > [YK]: I think I now do see your points in Case 2 and 3, and as I said > above, we can do some optimization (see again my suggestion above > under Case 2). However, considering my above comments, particularly > those under Case 1, I hope we can have a more comprehensive, and > on-the-same-page understanding on this issue. > Yes, I think we have a better understanding. Based on my understanding I want to further clarify what we should consider to do here. A) We should not go into the sub-profile discussion and dealing with the intersection of profiles as receiver capability. B) Unless we see a strong need to actually require encoders to produce bit-streams that are compliant with multiple profiles, we can actually remove the receiver direction interpretation of profile-compatibility-indicator. C) We define profile-compatibility-indicator as being purely a sender direction constraint. Assuming that we can mandate that a profile B decoder that accepts a RTP payload type that says profile-ID=A and profile-compatibility-indicator:B=Yes is capable of receiving that bitstream that enables at least the usage in unidirectional cases. This leaves us with a question if the answerer can send the offerer a bitstream that is Profile-ID=B and profile-compatibility-indicator:A=yes using this offered payload type? For that to work, we will need a general requirement that decoders can handle incoming bit-streams with any profile-id value as long as the profile-compatibility-indicator in the bistream is marked as compliant to one profile the decoder supports. That is not obvious for me. 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 Tue May 6 07:56: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 4136F1A035B for ; Tue, 6 May 2014 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 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_18=0.6, RP_MATCHES_RCVD=-0.651, 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 7lOAlIraT5Do for ; Tue, 6 May 2014 07:56:54 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id A1B0D1A008D for ; Tue, 6 May 2014 07:56:54 -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=1399388212; x=1430924212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TrJH1oj66xXaWNlKMk8qlZgiM0SLVLN0NOcZDvQ5TxA=; b=kWgEn9GuSJb7sQ5yu88SfTpHiXRFjRgToBr3v3MRYuQvYyfqpuzYIV4z 8f/R6Mv8Ipn1ACTUhevvapkHQXTs9wKsDsKBeBju+SIkWfoMgHDmpzy5O MUYb5D5/LnVRGoU173KeG5mg2TCRbLu3z9FkOmrRoWuYtRR7VF0VesjBh w=; X-IronPort-AV: E=McAfee;i="5600,1067,7429"; a="62997468" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 06 May 2014 07:56:51 -0700 X-IronPort-AV: E=Sophos;i="4.97,997,1389772800"; d="scan'208";a="660787260" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 May 2014 07:56:50 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by NASANEXHC03.na.qualcomm.com ([10.46.56.181]) with mapi id 14.03.0158.001; Tue, 6 May 2014 07:56:58 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplggAEi0AD//9aMYA== Date: Tue, 6 May 2014 14:56:58 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> In-Reply-To: <5368B1BC.5070104@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] 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/CfyRmp0tDw4e6wFrm7hwUA2y0fo Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 06 May 2014 14:56:58 -0000 Magnus, I think the only key different understanding between us now is the followin= g: Whether to assume that a decoder does not fully support any profile indi= cated by profile-id (what you called "sub-profile", e.g. only support the c= ommon tools of two or more profiles). Once we converge here, it should be easy to derive that text changes should= be made. Thus, let me focus on this in this email. Your opinion is obvious and strong - don't go into that direction. My opinion is strong too - we do need to go into that direction, because of= the following reasons: - The ITU-T/MPEG control how to use the bits of profile-id and profile-comp= atibility-indicator in the video coding specifications. It is simply possib= le that a new profile can be defined and indicated without using a new valu= e of profile-id, but indicated as conforming to two profiles. This happened= for AVC for the Constrained Baseline profile as I explained. Also, in the = recently finalized HEVC Range Extensions spec (see here: http://phenix.int-= evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q1005-v4.zip), 19= new profiles have been defined, indicated by only one value of profile-id = and some values of bits of the interop-constraints field (Note, not the pro= file-compatibility-indicator field). - Application standards organizations, e.g. 3GPP, may require "sub-profile"= capability for decoders. Again, AVC Constrained Baseline profile is an exa= mple - Magnus you should know this much better than many others. Thus, when defining the HEVC RTP payload here, I don't think we can ignore = the above. Rather, we must go into the direction of "sub-profile". BR, YK -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, May 06, 2014 2:56 AM To: Wang, Ye-Kui; Yago Sanchez Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 On 2014-05-06 02:38, Wang, Ye-Kui wrote: > Hi Magnus, Yago, >=20 > Thanks for having the discussion ongoing. See my comments inline=20 > below. >=20 > For easy of discussion, I numbered the different cases. I am hoping=20 > that through these discussions, we all would have a more=20 > comprehensive, and on-the-same-page, understanding on this issue. > Then it should be easy to conclude how to proceed. >=20 > BR, YK >=20 > -----Original Message----- From: Magnus Westerlund=20 > [mailto:magnus.westerlund@ericsson.com] Sent: Monday, May 05, 2014 > 1:05 AM To: Yago Sanchez Cc: Wang, Ye-Kui; payload@ietf.org;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload]=20 > Comments on draft-ietf-payload-rtp-h265-02 >=20 > Hi Yago, >=20 > Please see inline for comments >=20 > On 2014-05-04 22:32, Yago Sanchez wrote: >> Hi Magnus, >>=20 >> I still think that profile-compatibility-indicator may be useful. >> Let me list the different options I see and come finally to a=20 >> conclusion. All options are related to offerer supporting profile A=20 >> and answerer profile B. >>=20 >> 1) Offerer includes profile A and no >> profile-compatibility-indicator. Answerer cannot accept profile A so=20 >> they cannot achieve interoperability. >>=20 >> 2) Offerer includes profile A and sets the flag related to profile B=20 >> in the profile-compatibility-indicator (Offerer has to be aware of=20 >> the intersection of both profiles). Answerer ist not aware of profile=20 >> A and does not know which are the tools that lay in the intersection,=20 >> so again interoperability cannot be achieved, since the answerer=20 >> cannot constraint the sent stream so that the offerer can decode it.=20 >> Still, the use of profile-compatibility-indicator does not harm=20 >> session negotiation. The reason for not achieving interoperability is=20 >> another one. >>=20 >> 3) Offerer includes profile A and sets the flag related to profile B=20 >> in the profile-compatibility-indicator (Offerer has to be aware of=20 >> the intersection of both profiles). Answerer ist also aware of=20 >> profile A and the intersection with B and can accept the offer and=20 >> answer with a stream to the offerer that can be decoded. In this case=20 >> profile-compatibility-indicator helps for achieving interoperability. >=20 > Lets look at this depending on directional attribute. >=20 > Case 1: Offer: a=3Drecvonly: In this case, there was no point of=20 > offering the profile-compatibility-indicator, as that would only=20 > unnecessary restrict the answerer in its sending of the stream. >=20 > [YK]: There can be still be a point to offer=20 > profile-compatibility-indicator in this case. For example, it is=20 > possible that the decoder of the offerer only supports the common=20 > tools of profiles A and B, while it does not support either full=20 > profile A or full profile B. Think about similar situation for the AVC=20 > Constrained Baseline profile, which contains the common tools of the=20 > Baseline profile and the Main profile, and was defined after the=20 > definitions of the Baseline profile and the Main profile, and uses the=20 > same profile_idc as the Baseline profile. Similar situations could=20 > happen for HEVC. Note that this can also happen when the direction=20 > attribute has other values. Then the decoder is not compliant with any profile of A and B, if it only s= upports the common subset. But, at least we share the interpretation of wha= t the profile-compatibility-indicator means in this case. The answer's enco= der MUST be capable of producing a bitstream that fulfils the resulting con= straint of producing a bitstream that is decodable with a decoder compliant= according to either profile A or B or both. >From my perspective and in the interest of efficient profile handling and i= nteroperability, if we care about the intersection of profiles A and B, the= n define profile C that is that intersection. Don't play around with this m= echanism to achieve this. Thus, I still think this is unnecessarily constraint on the answerer's enco= der. >=20 > Case 2: Offer: a=3Dsendonly So in this case the offerer can include the=20 > profile-compatibility-indicator and the answerer will know that the=20 > offered stream is also compliant with the marked profiles. However, I=20 > seriously question if the answerer can accept this RTP payload type. > Yes, it can receive this specific stream under these constraints.=20 > However, the receiver if it accepts the RTP payload type, it promises=20 > to accept any stream that matches the RTP payload type. Thus, if one=20 > sends an additional stream under this RTP payload type what are the=20 > promise. It can't receive any stream fulfilling the profile-id=20 > parameter, it MUST also follow the constraints of the=20 > profile-compatibility-indicator. So what happens if that second=20 > encoder does not know about this profile. Then you end up in a=20 > incompatibility. Sure, with tight enforcement of that any stream you=20 > are being sent must fulfil to have the same=20 > profile-compatibility-indicator as negotiated, it can work. >=20 > [YK]: I see your point. In this case, if the offerer both profile A=20 > and profile B (by profile-id together with=20 > profile-compatibility-indicator), while the answerer understands=20 > profile A but does not understand profile B, the answerer can actually=20 > still accept the offer for the video communication from the=20 > offerer-to-answerer direction. However, for the other direction=20 > (answerer-to-offerer direction), the answerer does not know which=20 > tools to disable when encoding the video, there is no way to ensure=20 > interoperable video media in this direction. So, this can only work=20 > for single-direction communication, or declarative mode. Correct! >=20 > Case 3: Offer: a=3Dsendrecv Answerer: a=3Drecvonly >=20 > Equal to above >=20 > [YK]: Agreed, and my above comments apply. >=20 > Case 4: Offer: a=3Dsendrecv Answerer: a=3Dsendonly The answerer will not= =20 > accept to receive the stream from Offerer, thus the answerer can=20 > accept the payload type, given that it can provided a stream matching=20 > the RTP payload type. However, as in this scenario the answerer don't=20 > support the offered profile-id, only a another supported profile. > Thus, it doesn't fulfil the payload type and must reject it. >=20 > [YK]: I don't understand the first part above (thus the answerer can=20 > accept the payload type ...) - maybe there is a typo. But you second=20 > part seems to be aligned with my understanding, which is as follows=20 > (just to make the example clearer such that we are talking about the=20 > same thing). In this case, if the offerer indicates profile A and=20 > profile B (by profile-id together with=20 > profile-compatibility-indicator), while the answerer understands=20 > profile A but does not understand profile B, since the answerer does=20 > not know which tools to disable when encoding the video, there is no=20 > way to ensure interoperable video media in this direction, thus it has=20 > to reject the payload type. Correct! >=20 > Case 5: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv >=20 > In this case the answerer must reject the RTP payload on the grounds=20 > that it can't send the offerer a stream matching the RTP payload type,=20 > see just above with answerer:sendonly. >=20 > Thus, I would say that it provides some benefit in the cases the=20 > offerer will only send the stream to answerer, but in no other cases. > Also, this might give the offerer the wrong impression, and if one=20 > tries to modify the session to bi-directional streams, then this fails=20 > per the other options. >=20 > [YK]: The conclusion here should be slightly changed per Case 1. One=20 > optimization we can do here is to relax the constraint (that both=20 > profile_id and profile-compatibility-indicator must remain unchanged=20 > in offer and answer) a bit to enable Cases 2 and 3 (for=20 > single-direction from offerer to answerer, or declarative usage). For=20 > other cases, the current constraint applies (or as I said earlier,=20 > profile_id and profile-compatibility-indicator in both offer and=20 > answer must indicate the same set of encoding tools supported). Yes, I only looked at the implications of one direction as they was suffici= ent to reject the payload type. In the other direction it learns that it ca= n receive it. But, they are still not compatible for bi-directional communi= cation. Sorry, I don't understand your proposal for relaxing the constraints. >=20 >=20 > Lets instead look at the option to include one payload type per=20 > compatible profile that the encoder can send, i.e. each profile marked=20 > in profile-compatibility-indicator will get its own RTP payload type: >=20 > Case 6: Offer: a=3Drecvonly: Given that the decoder has the capability=20 > for all profiles the encoder could produce, the compatibility would be=20 > maximized. However, this is mostly irrelvant in this comparision. >=20 > [YK]: See discussions above for Case 1. This case can actually be=20 > split into two cases. Case 6.1: if the decoder does fully support each=20 > of the multiple profiles, then using one payload type for each of=20 > these profiles is OK. Case 6.2: if the decoder only supports the=20 > common tools of a list of profiles but not fully for each of the=20 > profiles, then using one payload type for each of these profiles is=20 > NOT OK. Yes, but that means going into sub-profiles, rather than assuming that the = decoder is compliant with particular profiles. I don't think we should go i= nto that discussion and the resulting issues. >=20 > Case 7: Offer: a=3Dsendonly If the offerer includes both the intended=20 > profile and one for the compatible, then the answer rejects the=20 > intended one and accepts the PT for the compatible one. Things work,=20 > given that the answerer accepts a bitstream with profile-Id =3D intended= =20 > and profile-compatibility-indicator=3Dcompatible one. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 8: Offer: a=3Dsendrecv Answerer: a=3Drecvonly Equal to above with th= e=20 > additional benefit that the offerer knows which profile the answerer=20 > supports to receive and likely send. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 9: Offer: a=3Dsendrecv Answerer: a=3Dsendonly To be able to offer=20 > this, the offerer must also be able to receive the compatible=20 > profile(s). If it doesn't then it can't offer multiple profiles and=20 > then we anyway have compatibility rejection. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 10: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv To be able to offer=20 > this, the offerer must also be able to receive the compatible=20 > profile(s). If not we have failure as there is no compatible profile=20 > both can produce. If it can we have interoperability, and answerer=20 > indicates that it can only produce the other profile. >=20 > [YK]: My above comments for Case 6 apply. >=20 > You might now better understand why I bring this up. It mostly fails=20 > or appear to have none intentional restrictions. >=20 > So I will admit that profile-compatibility-indicator provides a=20 > benefit if, and only if one offers sendonly streams, or ends up in=20 > sendonly from the party offering the profile-compatibility-indicator. > This appears to indicate that having this as a sender constraint only=20 > would reduce the cases where it restricts. However, in this case one=20 > do loose the possibility to negotiate for a central mixer case, that=20 > you must produce a stream that fulfils the subset of these profiles. > I do note that it appear necessary to make it clear that one MUST=20 > accept a video bitstream as long as its profile-id or=20 > profile-compatibility-indicator indicates the profile one has=20 > negotiated for the payload type. Is that clear in the HEVC=20 > specification? Does it need to be repeated in the payload format to=20 > prevent packetizers and others to make this error if they look=20 > slightly into the bitstream? >=20 > However, if we are getting into this detail of negotiation, then I=20 > would suggest that we create one profile-compatibility-indicator=20 > signalling attribute per send and receive direction. So that one can=20 > have senders constraints without the receive constraints. >=20 > [YK]: I hope with my above comments, particularly those under Case 1,=20 > some of the conclusions above would be adjusted. And also please check=20 > my suggestion in the comments under Case 5. To repeat, I don't think we shall support sub-profile support. Secondly, I = don't understand what you meant in case 5. >=20 >>=20 >> 4) The last option might be one that could show a case where=20 >> profile-compatibility-indicator could be harmful. Lets assume profile=20 >> A is a superset of profile B. The answerer could offer profile A and=20 >> set the flag corresponding to profile B in=20 >> profile-compatibility-indicator or even offer profile B and set the =20 >> flag corresponding to profile A in profile-compatibility-indicator =20 >> (both cases express the same). The answerer even though it could=20 >> decode and encode such a stream would have to reject the payload type=20 >> if it is not aware of what means to have a stream being compatible to=20 >> profile A due to not knowing profile A. I think this is what you are=20 >> concern about right? >=20 > It is one of my concerns, and depends on interpretation of the=20 > profile-compatibility-indicator. This is only relevant if one is=20 > forced to use the profile-compatibility-indicator as send direction=20 > constraint in an encoder. In a reception only case, one can look for=20 > just a profile one supports. Which further speaks for splitting the=20 > send and receiver constrints. >=20 > [YK]: This is the same as Cases 4 and 5 above. >=20 >>=20 >> In summary, I only see it could be harmful in case 4. And case 4 is =20 >> only the case where a full profile is supported (in the example=20 >> profile B) and all profiles that are supersets of it are marked in=20 >> the profile-compatibility-indicator. All other cases of profiles not=20 >> being supersets and being marked in profile-compatibility-indicator=20 >> would be either example 2 or 3. >>=20 >> Therefore my suggestion would be to still keep=20 >> profile-compatibility-indicator, since it might achieve=20 >> interoperability as shown in example 3 and add some text that=20 >> expresses that if a profile is fully supported and=20 >> profile-compatibility-indicator does not constraint that profile=20 >> further the profile-id should indicate such a profile and=20 >> profile-compatibility-indicator should not be included. Obviously=20 >> this only applies for O/A and not for declarative session=20 >> description. >=20 > I hope my above extension of your cases allows you to better see my=20 > concerns with the current specification of the=20 > profile-compatibility-indicator. If one would divide them into sender=20 > and receive direction some of the issues goes away. >=20 > [YK]: I think I now do see your points in Case 2 and 3, and as I said=20 > above, we can do some optimization (see again my suggestion above=20 > under Case 2). However, considering my above comments, particularly=20 > those under Case 1, I hope we can have a more comprehensive, and=20 > on-the-same-page understanding on this issue. >=20 Yes, I think we have a better understanding. Based on my understanding I wa= nt to further clarify what we should consider to do here. A) We should not go into the sub-profile discussion and dealing with the in= tersection of profiles as receiver capability. B) Unless we see a strong need to actually require encoders to produce bit-= streams that are compliant with multiple profiles, we can actually remove t= he receiver direction interpretation of profile-compatibility-indicator. C) We define profile-compatibility-indicator as being purely a sender direc= tion constraint. Assuming that we can mandate that a profile B decoder that= accepts a RTP payload type that says profile-ID=3DA and profile-compatibil= ity-indicator:B=3DYes is capable of receiving that bitstream that enables a= t least the usage in unidirectional cases. This leaves us with a question if the answerer can send the offerer a bitst= ream that is Profile-ID=3DB and profile-compatibility-indicator:A=3Dyes using this offered payload type? For that to work, we will need a general r= equirement that decoders can handle incoming bit-streams with any profile-i= d value as long as the profile-compatibility-indicator in the bistream is m= arked as compliant to one profile the decoder supports. That is not obvious for me. 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 ---------------------------------------------------------------------- From nobody Tue May 6 07:59:24 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 A82C31A035B for ; Tue, 6 May 2014 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 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_18=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 XwmaZVMv65oR for ; Tue, 6 May 2014 07:59:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D145E1A008D for ; Tue, 6 May 2014 07:59:19 -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=1399388356; x=1430924356; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=hfrUwHT9suSlwXO07sVMCie3vd3O+BYReGsCSw3hv/0=; b=mRkmkqPo54iTdhPNStjwg9RWrt2XoCacy7/Bgx48omC2cweR3pfz/cuk okns9fwtJChPN+5UiExlMMyHQYYM1hduEb90WGbW1bpAeVQx71ahB98nN wUPVN0g6WKKRvTL8hH17hjoXqRFeRyKgavJdtMoSAzLlCCqTz4Yvw3rKG A=; X-IronPort-AV: E=McAfee;i="5600,1067,7429"; a="33311292" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 06 May 2014 07:59:16 -0700 X-IronPort-AV: E=Sophos;i="4.97,997,1389772800"; d="scan'208";a="30206720" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 May 2014 07:59:15 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0158.001; Tue, 6 May 2014 07:59:23 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplggAEi0AD//9aMYIAACE7A Date: Tue, 6 May 2014 14:59:22 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834524B95A@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] 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/tCaCGtiYglEL2zZQ2Pq9AQvgS-0 Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 06 May 2014 14:59:22 -0000 Typo correction: " Whether to assume that a decoder does not fully support = ..." -> " Whether to assume ***it is possible*** that a decoder does not fu= lly support ..." BR, YK -----Original Message----- From: Wang, Ye-Kui=20 Sent: Tuesday, May 06, 2014 7:57 AM To: 'Magnus Westerlund'; Yago Sanchez Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 Magnus, I think the only key different understanding between us now is the followin= g: Whether to assume that a decoder does not fully support any profile indi= cated by profile-id (what you called "sub-profile", e.g. only support the c= ommon tools of two or more profiles). Once we converge here, it should be easy to derive that text changes should= be made. Thus, let me focus on this in this email. Your opinion is obvious and strong - don't go into that direction. My opinion is strong too - we do need to go into that direction, because of= the following reasons: - The ITU-T/MPEG control how to use the bits of profile-id and profile-comp= atibility-indicator in the video coding specifications. It is simply possib= le that a new profile can be defined and indicated without using a new valu= e of profile-id, but indicated as conforming to two profiles. This happened= for AVC for the Constrained Baseline profile as I explained. Also, in the = recently finalized HEVC Range Extensions spec (see here: http://phenix.int-= evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q1005-v4.zip), 19= new profiles have been defined, indicated by only one value of profile-id = and some values of bits of the interop-constraints field (Note, not the pro= file-compatibility-indicator field). - Application standards organizations, e.g. 3GPP, may require "sub-profile"= capability for decoders. Again, AVC Constrained Baseline profile is an exa= mple - Magnus you should know this much better than many others. Thus, when defining the HEVC RTP payload here, I don't think we can ignore = the above. Rather, we must go into the direction of "sub-profile". BR, YK -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, May 06, 2014 2:56 AM To: Wang, Ye-Kui; Yago Sanchez Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 On 2014-05-06 02:38, Wang, Ye-Kui wrote: > Hi Magnus, Yago, >=20 > Thanks for having the discussion ongoing. See my comments inline=20 > below. >=20 > For easy of discussion, I numbered the different cases. I am hoping=20 > that through these discussions, we all would have a more=20 > comprehensive, and on-the-same-page, understanding on this issue. > Then it should be easy to conclude how to proceed. >=20 > BR, YK >=20 > -----Original Message----- From: Magnus Westerlund=20 > [mailto:magnus.westerlund@ericsson.com] Sent: Monday, May 05, 2014 > 1:05 AM To: Yago Sanchez Cc: Wang, Ye-Kui; payload@ietf.org;=20 > draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload]=20 > Comments on draft-ietf-payload-rtp-h265-02 >=20 > Hi Yago, >=20 > Please see inline for comments >=20 > On 2014-05-04 22:32, Yago Sanchez wrote: >> Hi Magnus, >>=20 >> I still think that profile-compatibility-indicator may be useful. >> Let me list the different options I see and come finally to a=20 >> conclusion. All options are related to offerer supporting profile A=20 >> and answerer profile B. >>=20 >> 1) Offerer includes profile A and no >> profile-compatibility-indicator. Answerer cannot accept profile A so=20 >> they cannot achieve interoperability. >>=20 >> 2) Offerer includes profile A and sets the flag related to profile B=20 >> in the profile-compatibility-indicator (Offerer has to be aware of=20 >> the intersection of both profiles). Answerer ist not aware of profile=20 >> A and does not know which are the tools that lay in the intersection,=20 >> so again interoperability cannot be achieved, since the answerer=20 >> cannot constraint the sent stream so that the offerer can decode it. >> Still, the use of profile-compatibility-indicator does not harm=20 >> session negotiation. The reason for not achieving interoperability is=20 >> another one. >>=20 >> 3) Offerer includes profile A and sets the flag related to profile B=20 >> in the profile-compatibility-indicator (Offerer has to be aware of=20 >> the intersection of both profiles). Answerer ist also aware of=20 >> profile A and the intersection with B and can accept the offer and=20 >> answer with a stream to the offerer that can be decoded. In this case=20 >> profile-compatibility-indicator helps for achieving interoperability. >=20 > Lets look at this depending on directional attribute. >=20 > Case 1: Offer: a=3Drecvonly: In this case, there was no point of=20 > offering the profile-compatibility-indicator, as that would only=20 > unnecessary restrict the answerer in its sending of the stream. >=20 > [YK]: There can be still be a point to offer=20 > profile-compatibility-indicator in this case. For example, it is=20 > possible that the decoder of the offerer only supports the common=20 > tools of profiles A and B, while it does not support either full=20 > profile A or full profile B. Think about similar situation for the AVC=20 > Constrained Baseline profile, which contains the common tools of the=20 > Baseline profile and the Main profile, and was defined after the=20 > definitions of the Baseline profile and the Main profile, and uses the=20 > same profile_idc as the Baseline profile. Similar situations could=20 > happen for HEVC. Note that this can also happen when the direction=20 > attribute has other values. Then the decoder is not compliant with any profile of A and B, if it only s= upports the common subset. But, at least we share the interpretation of wha= t the profile-compatibility-indicator means in this case. The answer's enco= der MUST be capable of producing a bitstream that fulfils the resulting con= straint of producing a bitstream that is decodable with a decoder compliant= according to either profile A or B or both. >From my perspective and in the interest of efficient profile handling and i= nteroperability, if we care about the intersection of profiles A and B, the= n define profile C that is that intersection. Don't play around with this m= echanism to achieve this. Thus, I still think this is unnecessarily constraint on the answerer's enco= der. >=20 > Case 2: Offer: a=3Dsendonly So in this case the offerer can include the=20 > profile-compatibility-indicator and the answerer will know that the=20 > offered stream is also compliant with the marked profiles. However, I=20 > seriously question if the answerer can accept this RTP payload type. > Yes, it can receive this specific stream under these constraints.=20 > However, the receiver if it accepts the RTP payload type, it promises=20 > to accept any stream that matches the RTP payload type. Thus, if one=20 > sends an additional stream under this RTP payload type what are the=20 > promise. It can't receive any stream fulfilling the profile-id=20 > parameter, it MUST also follow the constraints of the=20 > profile-compatibility-indicator. So what happens if that second=20 > encoder does not know about this profile. Then you end up in a=20 > incompatibility. Sure, with tight enforcement of that any stream you=20 > are being sent must fulfil to have the same=20 > profile-compatibility-indicator as negotiated, it can work. >=20 > [YK]: I see your point. In this case, if the offerer both profile A=20 > and profile B (by profile-id together with=20 > profile-compatibility-indicator), while the answerer understands=20 > profile A but does not understand profile B, the answerer can actually=20 > still accept the offer for the video communication from the=20 > offerer-to-answerer direction. However, for the other direction=20 > (answerer-to-offerer direction), the answerer does not know which=20 > tools to disable when encoding the video, there is no way to ensure=20 > interoperable video media in this direction. So, this can only work=20 > for single-direction communication, or declarative mode. Correct! >=20 > Case 3: Offer: a=3Dsendrecv Answerer: a=3Drecvonly >=20 > Equal to above >=20 > [YK]: Agreed, and my above comments apply. >=20 > Case 4: Offer: a=3Dsendrecv Answerer: a=3Dsendonly The answerer will not= =20 > accept to receive the stream from Offerer, thus the answerer can=20 > accept the payload type, given that it can provided a stream matching=20 > the RTP payload type. However, as in this scenario the answerer don't=20 > support the offered profile-id, only a another supported profile. > Thus, it doesn't fulfil the payload type and must reject it. >=20 > [YK]: I don't understand the first part above (thus the answerer can=20 > accept the payload type ...) - maybe there is a typo. But you second=20 > part seems to be aligned with my understanding, which is as follows=20 > (just to make the example clearer such that we are talking about the=20 > same thing). In this case, if the offerer indicates profile A and=20 > profile B (by profile-id together with=20 > profile-compatibility-indicator), while the answerer understands=20 > profile A but does not understand profile B, since the answerer does=20 > not know which tools to disable when encoding the video, there is no=20 > way to ensure interoperable video media in this direction, thus it has=20 > to reject the payload type. Correct! >=20 > Case 5: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv >=20 > In this case the answerer must reject the RTP payload on the grounds=20 > that it can't send the offerer a stream matching the RTP payload type,=20 > see just above with answerer:sendonly. >=20 > Thus, I would say that it provides some benefit in the cases the=20 > offerer will only send the stream to answerer, but in no other cases. > Also, this might give the offerer the wrong impression, and if one=20 > tries to modify the session to bi-directional streams, then this fails=20 > per the other options. >=20 > [YK]: The conclusion here should be slightly changed per Case 1. One=20 > optimization we can do here is to relax the constraint (that both=20 > profile_id and profile-compatibility-indicator must remain unchanged=20 > in offer and answer) a bit to enable Cases 2 and 3 (for=20 > single-direction from offerer to answerer, or declarative usage). For=20 > other cases, the current constraint applies (or as I said earlier,=20 > profile_id and profile-compatibility-indicator in both offer and=20 > answer must indicate the same set of encoding tools supported). Yes, I only looked at the implications of one direction as they was suffici= ent to reject the payload type. In the other direction it learns that it ca= n receive it. But, they are still not compatible for bi-directional communi= cation. Sorry, I don't understand your proposal for relaxing the constraints. >=20 >=20 > Lets instead look at the option to include one payload type per=20 > compatible profile that the encoder can send, i.e. each profile marked=20 > in profile-compatibility-indicator will get its own RTP payload type: >=20 > Case 6: Offer: a=3Drecvonly: Given that the decoder has the capability=20 > for all profiles the encoder could produce, the compatibility would be=20 > maximized. However, this is mostly irrelvant in this comparision. >=20 > [YK]: See discussions above for Case 1. This case can actually be=20 > split into two cases. Case 6.1: if the decoder does fully support each=20 > of the multiple profiles, then using one payload type for each of=20 > these profiles is OK. Case 6.2: if the decoder only supports the=20 > common tools of a list of profiles but not fully for each of the=20 > profiles, then using one payload type for each of these profiles is=20 > NOT OK. Yes, but that means going into sub-profiles, rather than assuming that the = decoder is compliant with particular profiles. I don't think we should go i= nto that discussion and the resulting issues. >=20 > Case 7: Offer: a=3Dsendonly If the offerer includes both the intended=20 > profile and one for the compatible, then the answer rejects the=20 > intended one and accepts the PT for the compatible one. Things work,=20 > given that the answerer accepts a bitstream with profile-Id =3D intended= =20 > and profile-compatibility-indicator=3Dcompatible one. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 8: Offer: a=3Dsendrecv Answerer: a=3Drecvonly Equal to above with th= e=20 > additional benefit that the offerer knows which profile the answerer=20 > supports to receive and likely send. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 9: Offer: a=3Dsendrecv Answerer: a=3Dsendonly To be able to offer=20 > this, the offerer must also be able to receive the compatible=20 > profile(s). If it doesn't then it can't offer multiple profiles and=20 > then we anyway have compatibility rejection. >=20 > [YK]: My above comments for Case 6 apply. >=20 > Case 10: Offer: a=3Dsendrecv Answerer: a=3Dsendrecv To be able to offer=20 > this, the offerer must also be able to receive the compatible=20 > profile(s). If not we have failure as there is no compatible profile=20 > both can produce. If it can we have interoperability, and answerer=20 > indicates that it can only produce the other profile. >=20 > [YK]: My above comments for Case 6 apply. >=20 > You might now better understand why I bring this up. It mostly fails=20 > or appear to have none intentional restrictions. >=20 > So I will admit that profile-compatibility-indicator provides a=20 > benefit if, and only if one offers sendonly streams, or ends up in=20 > sendonly from the party offering the profile-compatibility-indicator. > This appears to indicate that having this as a sender constraint only=20 > would reduce the cases where it restricts. However, in this case one=20 > do loose the possibility to negotiate for a central mixer case, that=20 > you must produce a stream that fulfils the subset of these profiles. > I do note that it appear necessary to make it clear that one MUST=20 > accept a video bitstream as long as its profile-id or=20 > profile-compatibility-indicator indicates the profile one has=20 > negotiated for the payload type. Is that clear in the HEVC=20 > specification? Does it need to be repeated in the payload format to=20 > prevent packetizers and others to make this error if they look=20 > slightly into the bitstream? >=20 > However, if we are getting into this detail of negotiation, then I=20 > would suggest that we create one profile-compatibility-indicator=20 > signalling attribute per send and receive direction. So that one can=20 > have senders constraints without the receive constraints. >=20 > [YK]: I hope with my above comments, particularly those under Case 1,=20 > some of the conclusions above would be adjusted. And also please check=20 > my suggestion in the comments under Case 5. To repeat, I don't think we shall support sub-profile support. Secondly, I = don't understand what you meant in case 5. >=20 >>=20 >> 4) The last option might be one that could show a case where=20 >> profile-compatibility-indicator could be harmful. Lets assume profile=20 >> A is a superset of profile B. The answerer could offer profile A and=20 >> set the flag corresponding to profile B in=20 >> profile-compatibility-indicator or even offer profile B and set the=20 >> flag corresponding to profile A in profile-compatibility-indicator=20 >> (both cases express the same). The answerer even though it could=20 >> decode and encode such a stream would have to reject the payload type=20 >> if it is not aware of what means to have a stream being compatible to=20 >> profile A due to not knowing profile A. I think this is what you are=20 >> concern about right? >=20 > It is one of my concerns, and depends on interpretation of the=20 > profile-compatibility-indicator. This is only relevant if one is=20 > forced to use the profile-compatibility-indicator as send direction=20 > constraint in an encoder. In a reception only case, one can look for=20 > just a profile one supports. Which further speaks for splitting the=20 > send and receiver constrints. >=20 > [YK]: This is the same as Cases 4 and 5 above. >=20 >>=20 >> In summary, I only see it could be harmful in case 4. And case 4 is=20 >> only the case where a full profile is supported (in the example=20 >> profile B) and all profiles that are supersets of it are marked in=20 >> the profile-compatibility-indicator. All other cases of profiles not=20 >> being supersets and being marked in profile-compatibility-indicator=20 >> would be either example 2 or 3. >>=20 >> Therefore my suggestion would be to still keep=20 >> profile-compatibility-indicator, since it might achieve=20 >> interoperability as shown in example 3 and add some text that=20 >> expresses that if a profile is fully supported and=20 >> profile-compatibility-indicator does not constraint that profile=20 >> further the profile-id should indicate such a profile and=20 >> profile-compatibility-indicator should not be included. Obviously=20 >> this only applies for O/A and not for declarative session=20 >> description. >=20 > I hope my above extension of your cases allows you to better see my=20 > concerns with the current specification of the=20 > profile-compatibility-indicator. If one would divide them into sender=20 > and receive direction some of the issues goes away. >=20 > [YK]: I think I now do see your points in Case 2 and 3, and as I said=20 > above, we can do some optimization (see again my suggestion above=20 > under Case 2). However, considering my above comments, particularly=20 > those under Case 1, I hope we can have a more comprehensive, and=20 > on-the-same-page understanding on this issue. >=20 Yes, I think we have a better understanding. Based on my understanding I wa= nt to further clarify what we should consider to do here. A) We should not go into the sub-profile discussion and dealing with the in= tersection of profiles as receiver capability. B) Unless we see a strong need to actually require encoders to produce bit-= streams that are compliant with multiple profiles, we can actually remove t= he receiver direction interpretation of profile-compatibility-indicator. C) We define profile-compatibility-indicator as being purely a sender direc= tion constraint. Assuming that we can mandate that a profile B decoder that= accepts a RTP payload type that says profile-ID=3DA and profile-compatibil= ity-indicator:B=3DYes is capable of receiving that bitstream that enables a= t least the usage in unidirectional cases. This leaves us with a question if the answerer can send the offerer a bitst= ream that is Profile-ID=3DB and profile-compatibility-indicator:A=3Dyes using this offered payload type? For that to work, we will need a general r= equirement that decoders can handle incoming bit-streams with any profile-i= d value as long as the profile-compatibility-indicator in the bistream is m= arked as compliant to one profile the decoder supports. That is not obvious for me. 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 ---------------------------------------------------------------------- From nobody Tue May 6 11:43:39 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 2180C1A01C4 for ; Tue, 6 May 2014 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 0maDONjkdd2m for ; Tue, 6 May 2014 11:43:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4081A01BB for ; Tue, 6 May 2014 11:43:35 -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=1399401811; x=1430937811; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=18tut5EwQ4+LNjXN7FxXXOcqDwh8k00+Zkd4n6PHO3s=; b=izgEUy4nS+0Sj5PUpQT1T3N8HwY1tjCdDv8VfOV+hb6o8pk2p3HfoAhO NsIVaDrHJ+kJ72BdWkAZk/pyzxvJZooe6iTc7wHfoN/HY/WCOvv7cJJ0+ Rowkiwkl+nGV8WlxOZuTfM/tX8OQbPWJrFEpcwuD49kG0SETe7kVOy/eX w=; X-IronPort-AV: E=McAfee;i="5600,1067,7430"; a="124505797" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 06 May 2014 11:43:31 -0700 X-IronPort-AV: E=Sophos;i="4.97,998,1389772800"; d="scan'208";a="637564741" Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 May 2014 11:43:32 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0158.001; Tue, 6 May 2014 11:43:40 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: Open issue #4 // RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: Ac9pWOIaqUAT136kTi+fsTgglArXfA== Date: Tue, 6 May 2014 18:43:39 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834524BF20@nasanexd02f.na.qualcomm.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/m803Ujt51wOVJeEqm5WP0Umji4A Subject: [payload] Open issue #4 // RE: I-D Action: draft-ietf-payload-rtp-h265-03.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: Tue, 06 May 2014 18:43:37 -0000 Let's try to resolve one more open issue, the 4th, through this thread. The 4th open issue listed below is relatively minor, which is on using a di= fferent parameter category for level-id in Table 1 in Section 7.2.2. I have= some reservations to do that because of the following reasons: - Level down-grade has been mentioned already five times in this section, i= ncluding once right after the table. Thus, the intention is pretty clear al= ready. - Using a different category would increase the size of the table, which is= pretty big (more than one page) already. - As a result of the discussion on other threads on profile-id and profile-= compatibility-indicator, we are likely to allow to some extent asymmetric u= se of these two as well, e.g. depends on the direction attribute. A better = way to express this I think would still be use the 'C' category but clearly= spell out what is allowed. Magnus, with the above reasons in mind, please let me know you do still hav= e a strong opinion to use a different parameter category for level-id or yo= u can live with using the 'C' category. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Wednesday, April 30, 2014 11:29 AM To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed May 7 01:42: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 970E01A0377 for ; Wed, 7 May 2014 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 hne8gYe1DW9v for ; Wed, 7 May 2014 01:42:20 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 90F721A026F for ; Wed, 7 May 2014 01:42:19 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Received: from maclaptop002.ic.tu-berlin.de (maclaptop002.ic.tu-berlin.de [130.149.228.68]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id 45B521C9000C; Wed, 7 May 2014 10:42:13 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A9E12C7-C80B-4535-B4A6-F668FB0E9832" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yago Sanchez In-Reply-To: <5368AB3A.4050805@ericsson.com> Date: Wed, 7 May 2014 10:42:13 +0200 Message-Id: <8CE52840-765D-464D-AB09-9563CF7C2C67@hhi.fraunhofer.de> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <5368AB3A.4050805@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20678.006 X-TM-AS-Result: No--7.894-11.0-31-10 X-imss-scan-details: No--7.894-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: nI1cAR4k0HbOlvT/PJ/pVbMjW/sniEQKZTIutdVEQlU+gR+s21UkWFw3 j37kNg5GhAorr/1AbNl71Yis9UuwKMiKpygroIqgtLDu9qtqKeGqSTgi1qRkL914Aqe8EzF8kqO 2AbVSuPzHsoX+/PyGQ3y9ffIEknrpRft0j1zMO0yM29hkek7Xd7574JQAXc+h2An5g1C6+/Jau+ u2d9DSuOjsIkrzvj0/JbaRstWu5jLD11TnHAQ1PfHkpkyUphL9H181YDtIVaoji4BjRiqtPcJfR ix8rcI6FxNeB57tOTEbMASrqYe3nJNZ234i+Dn2ydRN/Yyg4pjAMyYDvAr9phSVYgoSgYGZIZjb V4eojrNApomIi7eNYkREQ58YRd3cYL5GMHK297SxT6X3XrQLUxiBRJlpoRsEB4sIhfTjqIFKslM 7VUaEwXb4Bm7FqQnL03BQIQx9Fl1CI2iUrGleqi+PrAd8gbHJnTcLR8+TzEqjC1E/zCEIrycKJ1 CtB5nF7fNKgmEEsE3c/PswyUm6tFATqJs9uVXRQ5lZokGzOaovcKmqjEcY3rNl/yOgFTFsYNYh5 x8mWMM2Scf7HImQ4/++gjOGfzBm5UcZtwNsCroURSScn+QSXsHGqwpJzOMi+gD2vYtOFhh5eoZ+ +n0Y7sQmnq708TADtL7rH+elRS780pm1WLBEu6f00vTgQnm6yQ0UjCmmIxdsf864ywuBN5b0eKT Fa5fBNnCqHY3aEqa2KL8toRHFvJRMZUCEHkRt X-IMSS-DKIM-White-List: No X-alterMIME: Yes Archived-At: http://mailarchive.ietf.org/arch/msg/payload/SG-tZU1FMKtjNQz0EAXDPRRdSBc Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id 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, 07 May 2014 08:42:22 -0000 --Apple-Mail=_2A9E12C7-C80B-4535-B4A6-F668FB0E9832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Magnus, If we go this way we would be removing the purpose of using the VPS for = session negotiation. Deprecating the use of recv-sub-layer-id to stream selection and not = using it for capability indication does not make much sense to me. Why = should an answerer choose a lower sub-layer if it is claiming that it = could get the highest one? There might be other reasons but the main one = I can think of is because it cannot receive the highest sub-layer due to = its capabilities. Thus, even though recv-sub-layer-id was used for = stream selection, the offerer could reconfigure the encoder leading to = the stream selection not being persistent, unless we stated somewhere = that this is not allowed. Note also that right now the draft says that when recv-sub-layer-id is = present the media configuration parameters MUST NOT be present, which = means we cannot use recv-sub-layer-id for selection and add the level-id = for level downgrade for capability indication. When an offerer gets the = recv-sub-layer-id it could easily understand the capabilities of the = answerer since it sent the sprop-vps but I see your concern for = middleboxes which have to keep track of what was sent by the offerer. I = did not see that as an issue but if you do, one potential way of solving = it is to remove the part that says that media configuration parameters = MUST NOT be present. Thus level downgrade could be accomplished while = here we need a MUST for the level-id being equal to the level indicated = in the VPS for the selected sub-layer. However, other parameters such as = profile-id could be potentially different for different sub-layers, = which means that the symmetry requirement of configuration parameters = should be relaxed conditioned on whether the recv-sub-layer-id is = present or not. Best regards, Yago On 6 May 2014, at 11:28, Magnus Westerlund = wrote: > On 2014-05-06 10:05, Yago Sanchez wrote: >> Hi Magnus, >>=20 >> Let me bring the discussion on recv-sub-layer-id back so that I >> understand your point here. (removed the rest of the discussion for >> clarity). Following the example Ye-Kui provided with two operation >> points (sub-layers) 720p@30fps and 720p@15fps, lets assume the >> offerer includes a payload type with profile-id and level-id for >> 720p@30 fps. >>=20 >> What do you mean when you say =93the recv-sub-layer-id is fine as a >> stream specific selection mechanism, but does not replace the >> capability declaration the regular parameters perform=94? Does it = mean >> that if the answerer accepts the payload type with recv-sub-layer-id >> equal to 0 in the answer (without level downgrade), it is selecting >> 720p@15fps but actually is indicating to have capabilities that match >> the profile-id and level-id of 720p@30 fps? >>=20 >=20 > Yes, that is the crux of the issue. The payload type states that you > have the 720p@30fps capability, as you haven't changed your profile or > level. While receive-sub-layer-id can point to that lower capability > 720p@15fps. That is a contradiction. >=20 > In addition using a pointer to value in the offer, results that the > actual value is not directly available when parsing the answer. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- --Apple-Mail=_2A9E12C7-C80B-4535-B4A6-F668FB0E9832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Magnus,

If we go this way we would be removing the = purpose of using the VPS for session = negotiation.

Deprecating the use of = recv-sub-layer-id to stream selection and not using it for capability = indication does not make much sense to me. Why should an answerer choose = a lower sub-layer if it is claiming that it could get the highest one? = There might be other reasons but the main one I can think of is because = it cannot receive the highest sub-layer due to its capabilities. Thus, = even though recv-sub-layer-id was used for stream selection, the offerer = could reconfigure the encoder leading to the stream selection not being = persistent, unless we stated somewhere that this is not = allowed.

Note also that right now the draft = says that when recv-sub-layer-id is present the media configuration = parameters MUST NOT be present, which means we cannot use = recv-sub-layer-id for selection and add the level-id for level downgrade = for capability indication. When an offerer gets the recv-sub-layer-id it = could easily understand the capabilities of the answerer since it sent = the sprop-vps but I see your concern for middleboxes which have to keep = track of what was sent by the offerer. I did not see that as an issue = but if you do, one potential way of solving it is to remove the part = that says that media configuration parameters MUST NOT be present. Thus = level downgrade could be accomplished while here we need a MUST for the = level-id being equal to the level indicated in the VPS for the selected = sub-layer. However, other parameters such as profile-id could be = potentially different for different sub-layers, which means that the = symmetry requirement of configuration parameters should be relaxed = conditioned on whether the recv-sub-layer-id is present or = not.

Best = regards,
Yago

On 6 May 2014, at 11:28, = Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:

On 2014-05-06 10:05, Yago Sanchez = wrote:
Hi Magnus,

Let me bring the = discussion on recv-sub-layer-id back so that I
understand your point = here. (removed the rest of the discussion for
clarity). Following the = example Ye-Kui provided with two operation
points (sub-layers) = 720p@30fps and 720p@15fps, lets assume the
offerer includes a payload = type with profile-id and level-id for
720p@30 fps.

What do you = mean when you say =93the recv-sub-layer-id is fine as a
stream = specific selection mechanism, but does not replace the
capability = declaration the regular parameters perform=94?  Does it = mean
that if the answerer accepts the payload type with = recv-sub-layer-id
equal to 0 in the answer (without level downgrade), = it is selecting
720p@15fps but actually is indicating to have = capabilities that match
the profile-id and level-id of 720p@30 = fps?


Yes, that is the crux of the issue. The = payload type states that you
have the 720p@30fps capability, as you = haven't changed your profile or
level. While receive-sub-layer-id can = point to that lower capability
720p@15fps. That is a = contradiction.

In addition using a pointer to value in the offer, = results that the
actual value is not directly available when parsing = the answer.


Cheers

Magnus = Westerlund

--------------------------------------------------------= --------------
Services, Media and Network features, Ericsson = Research = EAB/TXM
---------------------------------------------------------------= -------
Ericsson AB =             &n= bsp;   | Phone  +46 10 7148287
F=E4r=F6gatan 6 =             &n= bsp;   | Mobile +46 73 0949079
SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsson.= com
---------------------------------------------------------------= -------


=
= = --Apple-Mail=_2A9E12C7-C80B-4535-B4A6-F668FB0E9832-- From nobody Thu May 8 05:38: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 C13291A04B9 for ; Thu, 8 May 2014 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bPEJzqx2rEoc for ; Thu, 8 May 2014 05:38:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A04641A03DC for ; Thu, 8 May 2014 05:38:54 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-67-536b7ad9e2f0 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.B5.04714.9DA7B635; Thu, 8 May 2014 14:38:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.174.1; Thu, 8 May 2014 14:38:48 +0200 Message-ID: <536B7ACD.2010607@ericsson.com> Date: Thu, 8 May 2014 14:38:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <5368AB3A.4050805@ericsson.com> <8CE52840-765D-464D-AB09-9563CF7C2C67@hhi.fraunhofer.de> In-Reply-To: <8CE52840-765D-464D-AB09-9563CF7C2C67@hhi.fraunhofer.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvje7NquxggykvxC1OXdzHanHp4lkm i0nH17JZPFlzjNmBxWP6qcXMHkuW/GTyWDT1GaPHl8uf2QJYorhsUlJzMstSi/TtErgyOla0 MRV8k6rYs2Q/UwPjc9EuRk4OCQETidU7djFD2GISF+6tZ+ti5OIQEjjKKHHj71ZGCGcZo8T5 TfuBHA4OXgFtiWXtfCANLAIqEuumvWMFsdkELCRu/mhkA7FFBYIlNjz8yw5i8woISpyc+YQF xBYRMJRYsvoxWJxZYAujxJU7ziC2sEC4xNq2hWC9QgKXmCXendQEsTkFXCU27Z3MDLJWQkBc oqcxCKLVQOLIojmsELa8RPPW2cwQrdoSDU0drBMYhWYh2TwLScssJC0LGJlXMYoWpxYX56Yb GeulFmUmFxfn5+nlpZZsYgQG+8Etv3V3MK5+7XiIUYCDUYmHd0FJVrAQa2JZcWXuIUZpDhYl cd62u97BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhzK1IFzr9v+bD5hcYL9g/tnXOKMu9c q3QQF+LKDb75o+bqhDlzJryWnJOml1Sy/BfH2x6dDd58pjMym2ZvyJPYvXPR5pnbVQ6+Xrhe OlXxQEJMjLDN+aO1SXmF77Ir/xRsrg+V9PX6cGjSz17LHsX9drqPBXrtKqw6tvFb2ocfyX2/ iom345oSS3FGoqEWc1FxIgBeC6ZPVwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/B5wAqUrvncTqfbgoYon-JBFNF4c Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id 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, 08 May 2014 12:38:56 -0000 Hi, Please see inline. On 2014-05-07 10:42, Yago Sanchez wrote: > Hi Magnus, > > If we go this way we would be removing the purpose of using the VPS for > session negotiation. > > Deprecating the use of recv-sub-layer-id to stream selection and not > using it for capability indication does not make much sense to me. Why > should an answerer choose a lower sub-layer if it is claiming that it > could get the highest one? There might be other reasons but the main one > I can think of is because it cannot receive the highest sub-layer due to > its capabilities. Thus, even though recv-sub-layer-id was used for > stream selection, the offerer could reconfigure the encoder leading to > the stream selection not being persistent, unless we stated somewhere > that this is not allowed. I have to say that I am not a fan of performing selection and capability determination based on having to parse the VPS. The reason is that it makes the work of any intermediary including policy functions like these that exists in IMS more difficult to implement. Not only need to to understand the parameters in the SDP, they also need to include a HEVC VPS parser, and it needs to keep the offer VPS as state to determine what the answer means, as this is only a reference into that structure. > > Note also that right now the draft says that when recv-sub-layer-id is > present the media configuration parameters MUST NOT be present, which > means we cannot use recv-sub-layer-id for selection and add the level-id > for level downgrade for capability indication. When an offerer gets the > recv-sub-layer-id it could easily understand the capabilities of the > answerer since it sent the sprop-vps but I see your concern for > middleboxes which have to keep track of what was sent by the offerer. I > did not see that as an issue but if you do, one potential way of solving > it is to remove the part that says that media configuration parameters > MUST NOT be present. Thus level downgrade could be accomplished while > here we need a MUST for the level-id being equal to the level indicated > in the VPS for the selected sub-layer. However, other parameters such as > profile-id could be potentially different for different sub-layers, > which means that the symmetry requirement of configuration parameters > should be relaxed conditioned on whether the recv-sub-layer-id is > present or not. Yes, I think my concerns are lessen by including the answer parameters that matches what the recv-sub-layer-id layer requires. But, if that is done I still wonder what the advantage is of using the VPS for capability determination. Is it that the existing tools with profile and layers aren't fine grained enough. Or is it completely focused on the need to negotiate layer information. Something that will need a more complete (and likely complex) solution ones the scalable HEVC extensions are defined. 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 May 12 05:32:55 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 C700C1A068B; Mon, 12 May 2014 05:32:52 -0700 (PDT) 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 lc-opozQmP6X; Mon, 12 May 2014 05:32:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 839491A0697; Mon, 12 May 2014 05:32:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140512123248.2599.23648.idtracker@ietfa.amsl.com> Date: Mon, 12 May 2014 05:32:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/AwP4PMOQApBS8GiKmad0gngtWNM Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs' to Proposed Standard (draft-ietf-payload-rtp-aptx-05.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, 12 May 2014 12:32:52 -0000 The IESG has approved the following document: - 'RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs' (draft-ietf-payload-rtp-aptx-05.txt) as Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Richard Barnes and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ Technical Summary The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). Working Group Summary The WGLC was run once and it went rather smoothly. There were multiple reviews and they were addressed in the revisions after the WGLC. Document Quality There have been multiple vendors that sent an email to the mailing list saying that they strongly supported this draft and would deploy it as soon as the draft was completed. Media subtype registration was requested on Oct. 19th. Personnel Ali Begen is the document shepherd and Richard Barnes is the responsible AD. From nobody Mon May 12 13:01:30 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 EA7C01A0741 for ; Mon, 12 May 2014 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 1avyThhxijcG for ; Mon, 12 May 2014 13:01:25 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id E81391A0727 for ; Mon, 12 May 2014 13:01:24 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so8747279obc.6 for ; Mon, 12 May 2014 13:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=aOLp26x/WzlkZGZgDQZjoJoXqjVOUy35rwJdm8UdqCM=; b=nB7bqTkmFDJCSLMxf2fUIJ2WVKhY776CYCopTmkEZEJWYCa3YjKCl1myRyR9iLQWNS Alp4iCWFzXRqwiPkZMbfCTaaI9ed8kr0XBw9Kj6xp2AC5k5FPOTEetrc8hNb+Car9WlM SXCJ6pjxSAZQ8Nodagbis7UFGSIOwSt6N2bQKap2P5PVJ/NyBc5l8PaL/+YZZXAja4ZJ 0+qtBplAw/f84EFxxb0jhGKjyOrJZ31jNJA04u5AJKTLsSBQk+u5WYmakAt6Apb5y7iB dr3kTR0wSkA/XS0PT4AcDQZ18QS/lQNKF5LTgLscuwxBouSDbf0sVVipiedudU3Ekkdz D9Mg== X-Gm-Message-State: ALoCoQnKh6L3WdX88/7WKqti825PZwcmyR8cqweZqS/5SWng753TCn+iPxi8vfgNhPKiZu8D58mS MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr37381222obh.19.1399924878751; Mon, 12 May 2014 13:01:18 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Mon, 12 May 2014 13:01:18 -0700 (PDT) Date: Mon, 12 May 2014 22:01:18 +0200 Message-ID: From: Richard Barnes To: draft-ietf-payload-g7110@tools.ietf.org, "payload@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2cd181c4c2204f9396901 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Aa4coivqlp_N9oM5P9ADeZ1ADSo Subject: [payload] AD review of draft-ietf-payload-g7110-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, 12 May 2014 20:01:27 -0000 --001a11c2cd181c4c2204f9396901 Content-Type: text/plain; charset=UTF-8 I have reviewed this draft in preparation for IETF LC. I have some concerns below that I would like to see addressed before LC (MAJOR). Thanks, --Richard MAJOR: S4.2.3. H2 is a little unclear. Is the array indexing zero-based? If so, why are you skipping the first octet? If you mean it to be zero-based, and not to skip the first octet, set P=-1 in H1. S4.2.3. What happens in H5 if the G.711.0 decoder encounters an improperly formatted octet sequence? E.g., if the prefix code octet specifies that there are more samples than could be contained in the packet. I'm concerned that the process as-is could lead to reading past the end of the packet buffer. S4.2.4. What happens if the M is not a multiple of N? Does the receiver discard the packet? MINOR: S4.2.3. The "heuristic" seems more like an "algorithm". Or "process", as the section header says. S5.1. Is there any risk of G.7110 being defined, and needing a payload format that would collide with this identifier? S5.1. Can we specify that "channels" is an integer? S5.4.* Can someone verify that the spaces in the examples are valid? E.g., "complaw = al" and "ptime: 20". S6. It seems like the format described here can only hold single-channel, right? If so, this format seems fine, but you do need to clarify that it's single-channel only. If not, it seems like you need to (1) delimit packets, and (2) specify the number of channels at the start. EDITORIAL: S4.2.4. "the optional parameter is a MUST" -> "the optional 'channels' parameter is REQUIRED" S4.2.3. It seems like it would be simpler to state the decoding algorithm as while loop with an if statement, since it seems like that's how you would implement it in most normal programming languages. (See, e.g., the python snippet below). If you really want a state machine like representation, it would be nice to at least have a picture of it. +-----------+ | | V | H1 -> H2 -> H3 -> H4 -> STOP ^ | ^ | | | | +---> H5 ----+ | | | | +-----------+ def decode_g711_0_payload(payload): # H1 P = 0 N = len(payload) internal = [] output = [] while P < N: # H2 internal = packet[ P+1 : P+1+min(321,N-P) ] # H3 if internal[0] == '\x00': # H4 P += 1 else: # H5 (symbols, Q) = g711_0_decode(internal) output.extend(symbols) K += len(symbols) # == M P += Q return output --001a11c2cd181c4c2204f9396901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft in preparation for IETF LC. =C2= =A0I have some concerns below that I would like to see addressed before LC = (MAJOR).

Thanks,
--Richard


MAJOR:

S4.2.3.=C2=A0
H2 is a little unclear. =C2=A0Is the array indexing zero-based? =C2=A0If s= o, why are you skipping the first octet? =C2=A0If you mean it to be zero-ba= sed, and not to skip the first octet, set P=3D-1 in H1.

S4.2.3.
What happens in H5 if the = G.711.0 decoder encounters an improperly formatted octet sequence? =C2=A0E.= g., if the prefix code octet specifies that there are more samples than cou= ld be contained in the packet. =C2=A0I'm concerned that the process as-= is could lead to reading past the end of the packet buffer.

S4.2.4.
What happens if the M is not a = multiple of N? =C2=A0Does the receiver discard the packet?

MINOR:

S4.2.3.=C2=A0
The "heuristic" seems more like an "algorithm". =C2=A0O= r "process", as the section header says.

S5.1.=C2=A0
Is there any risk of G.7110 being defined, and needi= ng a payload format that would collide with this identifier?

S5.1.
Can we specify that "channels"= ; is an integer?

S5.4.*=C2=A0
Can someon= e verify that the spaces in the examples are valid? =C2=A0E.g., "complaw =3D al" and "ptime: 20".

<= span style=3D"color:rgb(0,0,0);font-size:1em">S6.
It seems like the format descri= bed here can only hold single-channel, right? =C2=A0If so, this format seem= s fine, but you do need to clarify that it's single-channel only. If no= t, it seems like you need to (1) delimit packets, and (2) specify the numbe= r of channels at the start.



EDITORIAL:

S4.2.4.
"the optional parameter= is a MUST" -> "the optional 'channels' parameter is R= EQUIRED"

S4.2.3.
It seems like it would be = simpler to state the decoding algorithm as while loop with an if statement,= since it seems like that's how you would implement it in most normal p= rogramming languages. =C2=A0(See, e.g., the python snippet below). =C2=A0If= you really want a state machine like representation, it would be nice to a= t least have a picture of it.

=C2=A0 =C2=A0 =C2=A0 +-----------+
=C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0 V =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
H1 -> H2 -> H= 3 -> H4 -> STOP
=C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +---> H5 ----+
=C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 +-----------+

def decode_g711_0_payload= (payload):
=C2=A0 # H1
=C2=A0 P =3D 0
=C2=A0 N =3D len(payload)
=C2=A0 internal =3D []
= =C2=A0 output =3D []
=C2=A0 while P < N:
=C2=A0 =C2= =A0 # H2
=C2=A0 =C2=A0 internal =3D packet[ P+1 : P+1+min(321,N-P= ) ]
=C2=A0 =C2=A0 # H3
=C2=A0 =C2=A0 if internal[0] =3D= =3D '\x00':
=C2=A0 =C2=A0 =C2=A0 # H4
=C2=A0 =C2=A0 =C2=A0 P +=3D 1
=C2=A0 =C2=A0 else:
=C2=A0 =C2=A0 =C2=A0 # H5
=C2= =A0 =C2=A0 =C2=A0 (symbols, Q) =3D g711_0_decode(internal)
=C2=A0= =C2=A0 =C2=A0 output.extend(symbols)
=C2=A0 =C2=A0 =C2=A0 K +=3D= len(symbols) # =3D=3D M
=C2=A0 =C2=A0 =C2=A0 P +=3D Q
=C2=A0 return output

--001a11c2cd181c4c2204f9396901-- From nobody Tue May 13 07:31:09 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 A58911A00CD for ; Tue, 13 May 2014 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BfVEV7UqN9vN for ; Tue, 13 May 2014 07:31:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 541911A00A8 for ; Tue, 13 May 2014 07:31:05 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-d2-53722ca13edb Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.3E.05409.1AC22735; Tue, 13 May 2014 16:30:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Tue, 13 May 2014 16:30:57 +0200 Message-ID: <53722C91.1000907@ericsson.com> Date: Tue, 13 May 2014 16:30:41 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , Yago Sanchez References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834524B931@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+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvje4inaJgg0tRFqcu7mO1uHTxLJPF pONr2SyerDnG7MDiMf3UYmaPJUt+MnksmvqM0ePL5c9sASxRXDYpqTmZZalF+nYJXBmLeruZ Cz7KVbxYXN3AOFmyi5GTQ0LARGLHnvfsELaYxIV769m6GLk4hASOMkpMmj6VFcJZzihx8N9p JpAqXgFtiaPX+xhBbBYBVYneLWtZQGw2AQuJmz8a2UBsUYFgiQ0P/7JD1AtKnJz5BKiGg0NE IFbi1Q1BkJnMAh2MEue3fQOrERZwlNjQ2MoEsWwxm8S1zmusIAlOoEGbPv0Ha5YQEJfoaQwC CTML6ElMudrCCGHLSzRvnc0MYgsB3dbQ1ME6gVFoFpLVs5C0zELSsoCReRWjaHFqcVJuupGx XmpRZnJxcX6eXl5qySZGYLAf3PJbdQfj5TeOhxgFOBiVeHgVeAqDhVgTy4orcw8xSnOwKInz frnlEywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsURyHvNm6/wnC44csFgu9+DOkqX7Lzmu fLw8ZInnmxWyl82ezVn4/nJXl5bxhoNZjTfUSvRnv0tMXlVW92zKfO7HWSG/cjg6/i4WLJVg iRJem7Iumd/xmrLA9ynJqaGrY0/nhN/kfH5b1jRLnTX99amg09m+THpeakGnljRcmRo0ybF6 RoJtrhJLcUaioRZzUXEiANtrQiVXAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/j9GKjx01vMEGh7i3JJNfx1QQ0sc Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 13 May 2014 14:31:07 -0000 Ye-Kui and WG, Please see inline. I think we need input from more people into this question to make progress. On 2014-05-06 16:56, Wang, Ye-Kui wrote: > Magnus, > > I think the only key different understanding between us now is the > following: Whether to assume that a decoder does not fully support > any profile indicated by profile-id (what you called "sub-profile", > e.g. only support the common tools of two or more profiles). > > Once we converge here, it should be easy to derive that text changes > should be made. Thus, let me focus on this in this email. > > Your opinion is obvious and strong - don't go into that direction. > > My opinion is strong too - we do need to go into that direction, > because of the following reasons: > > - The ITU-T/MPEG control how to use the bits of profile-id and > profile-compatibility-indicator in the video coding specifications. > It is simply possible that a new profile can be defined and indicated > without using a new value of profile-id, but indicated as conforming > to two profiles. This happened for AVC for the Constrained Baseline > profile as I explained. Also, in the recently finalized HEVC Range > Extensions spec (see here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q1005-v4.zip), > 19 new profiles have been defined, indicated by only one value of > profile-id and some values of bits of the interop-constraints field > (Note, not the profile-compatibility-indicator field). Yes this may happen, but jumping onto this now, do in fact create a tool where anyone can attempt to create new interoperability points by selecting an intersection between profiles. That doesn't benefit interoperability, it instead fractures the market and works against the purpose of the profiles in the first place. Secondly, in relation to H.264 constrained baseline, that was created using constraint bits, a concept that already is part of the specification, it might be defined as the intersection of two profiles, but the signalling is done according to one profile with a specific bit set. Just like the HEVC Range Extension profiles. However, to me it appears that when one selected the structure for HEVC Range Extensions one forgot about the profile-compatibility-indicator as it is not possible to signal compatibility across the main directions in the range extension profiles. The main directions are within themselves nicely onion shaped, but the compatibility between them does not appear to have been well considered. > > - Application standards organizations, e.g. 3GPP, may require > "sub-profile" capability for decoders. Again, AVC Constrained > Baseline profile is an example - Magnus you should know this much > better than many others. Yes, however I think it is usually bad for interoperability. And HEVC does not appear to be in the same position that H.264 was when it was just finished. Thus, I expect the issues are being different. > > Thus, when defining the HEVC RTP payload here, I don't think we can > ignore the above. Rather, we must go into the direction of > "sub-profile". I understand your arguments. What is required is highly dependent on what will be done with future profiling of HEVC. I see enabling the possibility to intersect any choice of profiles do create an potential for fracturing the market and reducing the interoperability of HEVC. 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 Tue May 13 07:36: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 4F05F1A00DB for ; Tue, 13 May 2014 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9V6TxEs7qgW1 for ; Tue, 13 May 2014 07:36:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 808601A00D7 for ; Tue, 13 May 2014 07:36:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-f1-53722df7a30b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.3F.04714.7FD22735; Tue, 13 May 2014 16:36:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Tue, 13 May 2014 16:36:39 +0200 Message-ID: <53722DE9.9020303@ericsson.com> Date: Tue, 13 May 2014 16:36:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , "payload@ietf.org" References: <8BA7D4CEACFFE04BA2D902BF11719A834524BF20@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834524BF20@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+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje533aJggxU39S0uXTzLZPFkzTFm ByaPJUt+MnksmvqMMYApissmJTUnsyy1SN8ugSvjwz25gn/8Fa+3HGdtYHzC08XIwSEhYCLx 8nthFyMnkCkmceHeerYuRi4OIYGjjBKLe9sZIZzljBLH7r5lBaniFdCWON/exgxiswioSiw4 tpURxGYTsJC4+aORDcQWFQiW2PDwLztEvaDEyZlPWEBsEYFQiS8fp7KDLBYWiJLo3h4DEhYS CJK4dmYfE4jNCdQ6b8VZFojbxCV6GoNAwswCehJTrrYwQtjyEs1bZzNDtGpLNDR1sE5gFJyF ZNksJC2zkLQsYGRexShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYqAe3/Nbdwbj6teMhRgEO RiUeXgWewmAh1sSy4srcQ4zSHCxK4rxtd72DhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCu 0zArYv2/wGF9nEzQW1GXjSu+Jrz2nv7u7JvfnCH/Io/P6diQ9Wr3MZeHa7o+/D1unxy0PP7g TWtWrtjXZkmvF7e3HHCIrgzqD2rP3XPjoP6c2SVLJjc9nMOv2Xjreaf7GiXGeTtZr24I9RXf Vxh5lvHsg4XyJ976T//tw6H2PfB4YtgC/+deSizFGYmGWsxFxYkAyEJeXzUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/wAHKOlW7V33ZeEmR0_S2WFfzhyM Subject: Re: [payload] Open issue #4 // RE: I-D Action: draft-ietf-payload-rtp-h265-03.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: Tue, 13 May 2014 14:36:48 -0000 On 2014-05-06 20:43, Wang, Ye-Kui wrote: > Let's try to resolve one more open issue, the 4th, through this > thread. > > The 4th open issue listed below is relatively minor, which is on > using a different parameter category for level-id in Table 1 in > Section 7.2.2. I have some reservations to do that because of the > following reasons: > - Level down-grade has been mentioned already five times in this > section, including once right after the table. Thus, the intention is > pretty clear already. > - Using a different category would increase the size of the table, > which is pretty big (more than one page) already. Sorry, I don't understand why changing C into D for the relevant places for the level-id would expand the table. D: Downgradable Configuration, as C except possible to answer also with a lesser value. > - As a result of the discussion on other threads on profile-id and > profile-compatibility-indicator, we are likely to allow to some > extent asymmetric use of these two as well, e.g. depends on the > direction attribute. A better way to express this I think would still > be use the 'C' category but clearly spell out what is allowed. > > Magnus, with the above reasons in mind, please let me know you do > still have a strong opinion to use a different parameter category for > level-id or you can live with using the 'C' category.> > BR, YK > I think you might have misunderstood the extent of my proposal to fix this, please see above to see if you think this is acceptable. 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 Tue May 13 09:37:10 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 2782D1A0115 for ; Tue, 13 May 2014 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 NF0r0gplLqYy for ; Tue, 13 May 2014 09:36:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFF71A013C for ; Tue, 13 May 2014 09:36:52 -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=1399999006; x=1431535006; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rOGTDfyOi13zyeJQ8jRyTi4ahK8t9pTxTxxpzGoLUHo=; b=UToviQZ19Ogwq/Dlnvv1xVqFfEUA63SUsl9LCNArgaNIdafwt9N6RKIJ puXpnwcSGJJdjjzH/33pYhWOABqg7zy65W8Ygg0ocsm2j5lYaA6hOlHNr mqBXYr+ynFkryZH4w5QcQuBcvX9G2r5gpjuKQyPsc/BsM0QWxko9qHmWj 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7436"; a="34764687" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 13 May 2014 09:36:45 -0700 X-IronPort-AV: E=Sophos;i="4.97,1044,1389772800"; d="scan'208";a="731791755" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 May 2014 09:36:45 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.220]) by NASANEXHC01.na.qualcomm.com ([10.46.57.53]) with mapi id 14.03.0181.006; Tue, 13 May 2014 09:37:06 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , "payload@ietf.org" Thread-Topic: Open issue #4 // RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: Ac9pWOIaqUAT136kTi+fsTgglArXfAFmoHaAAAqEBlA= Date: Tue, 13 May 2014 16:37:06 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834527BB48@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A834524BF20@nasanexd02f.na.qualcomm.com> <53722DE9.9020303@ericsson.com> In-Reply-To: <53722DE9.9020303@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/HUNUut-ZTM2C2jOGN8-whESE89Y Subject: Re: [payload] Open issue #4 // RE: I-D Action: draft-ietf-payload-rtp-h265-03.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: Tue, 13 May 2014 16:36:59 -0000 By expanding the table I meant exactly that one more notation of the new ca= tegory, e.g. the same as you did, would need to be added. However, if you do have a strong opinion here, then let's do what you sugge= sted. I do not have a strong opinion here. BR, YK -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, May 13, 2014 7:36 AM To: Wang, Ye-Kui; payload@ietf.org Subject: Re: Open issue #4 // RE: [payload] I-D Action: draft-ietf-payload-= rtp-h265-03.txt On 2014-05-06 20:43, Wang, Ye-Kui wrote: > Let's try to resolve one more open issue, the 4th, through this=20 > thread. >=20 > The 4th open issue listed below is relatively minor, which is on using=20 > a different parameter category for level-id in Table 1 in Section=20 > 7.2.2. I have some reservations to do that because of the following=20 > reasons: > - Level down-grade has been mentioned already five times in this=20 > section, including once right after the table. Thus, the intention is=20 > pretty clear already. > - Using a different category would increase the size of the table,=20 > which is pretty big (more than one page) already. Sorry, I don't understand why changing C into D for the relevant places for= the level-id would expand the table. D: Downgradable Configuration, as C except possible to answer also with a l= esser value. > - As a result of the discussion on other threads on profile-id and=20 > profile-compatibility-indicator, we are likely to allow to some extent=20 > asymmetric use of these two as well, e.g. depends on the direction=20 > attribute. A better way to express this I think would still be use the=20 > 'C' category but clearly spell out what is allowed. >=20 > Magnus, with the above reasons in mind, please let me know you do=20 > still have a strong opinion to use a different parameter category for=20 > level-id or you can live with using the 'C' category.> BR, YK >=20 I think you might have misunderstood the extent of my proposal to fix this,= please see above to see if you think this is acceptable. 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 ---------------------------------------------------------------------- From nobody Tue May 13 09:57:24 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 067151A0124 for ; Tue, 13 May 2014 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 xxxtaSI0ocfX for ; Tue, 13 May 2014 09:57:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 119761A0107 for ; Tue, 13 May 2014 09:57:20 -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=1400000234; x=1431536234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R43oTXMAbRMx85Xr6yLDevhbGIdrGjewcZ/4gcbstTc=; b=PjCCBNOi8DYj8SgF/CM9YkHnsv1pnGFCBAvKLHkseCQyIprc9oR1rDON 0pLNbaf2Dne8z+JRSkfm5h6hYE65mciUfz1rBnja0FUrFT+OSbKTNjvWq 7ZQJHPxfGkXdF7I6+lqi/v0dFRmg2rM2r6m1NokZpjeZPak9a/cVXwPq8 g=; X-IronPort-AV: E=McAfee;i="5600,1067,7436"; a="34768233" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 13 May 2014 09:57:13 -0700 X-IronPort-AV: E=Sophos;i="4.97,1044,1389772800"; d="scan'208";a="677648731" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 May 2014 09:57:13 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.220]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0181.006; Tue, 13 May 2014 09:57:34 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplggAEi0AD//9aMYIALdneA//+t/aA= Date: Tue, 13 May 2014 16:57:34 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> In-Reply-To: <53722C91.1000907@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/vj9Zyh64tWQIcjoGlEQPnMaQJVs Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 13 May 2014 16:57:23 -0000 Magnus, I understand your arguments too. Your main worry seems to be about the HEVC= profiling fracturing the market and reducing the interoperability of HEVC,= which I do share. However, the key point here is that, that is not up to u= s, it is controlled by other organizations. If we go ahead to disallow the = support of that in the HEVC payload format, that does not mean we would suc= cessfully prevent that from happening in MPEG/ITU-T and other application s= tandard organizations - and if that happens, then an extension to the paylo= ad format would need to be specified, which might introduce more IOP issues= even on the RTP encapsulation level for HEVC.=20 I fully agree that some more opinions from others would be very helpful. Please, whoever cares about this draft and cares about using HEVC with RTP,= say your opinion. We really need to have this document finalized soon for = HEVC deployment!!! See some other detailed replies inline below too. BR, YK -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, May 13, 2014 7:31 AM To: Wang, Ye-Kui; Yago Sanchez Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Ye-Kui and WG, Please see inline. I think we need input from more people into this questio= n to make progress. On 2014-05-06 16:56, Wang, Ye-Kui wrote: > Magnus, >=20 > I think the only key different understanding between us now is the > following: Whether to assume that a decoder does not fully support any=20 > profile indicated by profile-id (what you called "sub-profile", e.g.=20 > only support the common tools of two or more profiles). >=20 > Once we converge here, it should be easy to derive that text changes=20 > should be made. Thus, let me focus on this in this email. >=20 > Your opinion is obvious and strong - don't go into that direction. >=20 > My opinion is strong too - we do need to go into that direction,=20 > because of the following reasons: >=20 > - The ITU-T/MPEG control how to use the bits of profile-id and=20 > profile-compatibility-indicator in the video coding specifications. > It is simply possible that a new profile can be defined and indicated=20 > without using a new value of profile-id, but indicated as conforming=20 > to two profiles. This happened for AVC for the Constrained Baseline=20 > profile as I explained. Also, in the recently finalized HEVC Range=20 > Extensions spec (see here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/ > JCTVC-Q1005-v4.zip), > 19 new profiles have been defined, indicated by only one value of=20 > profile-id and some values of bits of the interop-constraints field=20 > (Note, not the profile-compatibility-indicator field). Yes this may happen, but jumping onto this now, do in fact create a tool wh= ere anyone can attempt to create new interoperability points by selecting a= n intersection between profiles. That doesn't benefit interoperability, it = instead fractures the market and works against the purpose of the profiles = in the first place. [YK]: Agreed - but again that is not up to us, it is controlled by other SD= Os (which are in turn driven by the markets). Secondly, in relation to H.264 constrained baseline, that was created using= constraint bits, a concept that already is part of the specification, it m= ight be defined as the intersection of two profiles, but the signalling is = done according to one profile with a specific bit set. Just like the HEVC R= ange Extension profiles. [YK]: Why the signalling is different? Herein you also use a profile-id val= ue with a specific bit set. However, to me it appears that when one selected the structure for HEVC Ran= ge Extensions one forgot about the profile-compatibility-indicator as it is= not possible to signal compatibility across the main directions in the ran= ge extension profiles. The main directions are within themselves nicely oni= on shaped, but the compatibility between them does not appear to have been = well considered. [YK]: I was not involved in the definition of the structure for HEVC Range = Extensions - so no comment here. >=20 > - Application standards organizations, e.g. 3GPP, may require=20 > "sub-profile" capability for decoders. Again, AVC Constrained Baseline=20 > profile is an example - Magnus you should know this much better than=20 > many others. Yes, however I think it is usually bad for interoperability. And HEVC does = not appear to be in the same position that H.264 was when it was just finis= hed. Thus, I expect the issues are being different. [YK]: True - but on the other hand, that was driven by the market too, and = they wanted that for interoperability for that particular capability. Here = the issue is not about what was defined already in HEVC, but what could be = done in the future. When RFC 3984 was finalized, the Constrained Baseline p= rofile was not available yet. So, right now, the situation is the same. Unl= ess we can surely know similar things won't happen, we should follow the ap= proach in RFC 3984, i.e. to allow for such intersection of two more profile= s. Nobody can be sure right now for what could happen in the future, at lea= st for this issue. >=20 > Thus, when defining the HEVC RTP payload here, I don't think we can=20 > ignore the above. Rather, we must go into the direction of=20 > "sub-profile". I understand your arguments. What is required is highly dependent on what w= ill be done with future profiling of HEVC. I see enabling the possibility t= o intersect any choice of profiles do create an potential for fracturing th= e market and reducing the interoperability of HEVC. [YK]: Again, agree in general, but again that is not controlled by us. 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 ---------------------------------------------------------------------- From nobody Tue May 13 10:11: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 D35E91A014C for ; Tue, 13 May 2014 10:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 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.651, 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 1u2iGYWsK7Jp for ; Tue, 13 May 2014 10:11:16 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA21A015B for ; Tue, 13 May 2014 10:11:16 -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=1400001070; x=1431537070; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JWVCbxPfry83kl/9U1Cu8fKn5pRZwmCIfa6Lx0PFkkA=; b=v5hmJgebJcsNP0K53ErI7KLMML+uE9czenO/W9ozASPLTG1z4n57RatN wJP8Y1iw3qKwKDJLGXgqyyE5xTOqLUk4FcBxVC8yq32ytLEfmHQou7eKr 0kG16K0w5MkDBm4qqHmBaPUkqoy6n2N6g/7F7jqQeC0R9w+vQmYApDxu/ o=; X-IronPort-AV: E=McAfee;i="5600,1067,7436"; a="63454351" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 13 May 2014 10:11:09 -0700 X-IronPort-AV: E=Sophos;i="4.97,1044,1389772800"; d="scan'208";a="29657493" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 May 2014 10:11:09 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.220]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.03.0181.006; Tue, 13 May 2014 10:11:30 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id Thread-Index: AQHPaQIBD8+QkJRP1U2VdRboUKljKpszvmUAgAGFa4CAAdRigIAHr2mQ Date: Tue, 13 May 2014 17:11:30 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834527BBC8@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <5368AB3A.4050805@ericsson.com> <8CE52840-765D-464D-AB09-9563CF7C2C67@hhi.fraunhofer.de> <536B7ACD.2010607@ericsson.com> In-Reply-To: <536B7ACD.2010607@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Ay2YHxJpqaEk7TED7D5BerGsvWU Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-sub-layer-id 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, 13 May 2014 17:11:19 -0000 So we have the following options: A: To keep what we have now. This way, the SDP answer message can be slim, = but it does require entities involved in O/A to parse some parts of the VPS= . B: To completely remove the use of VPS for session negotiation in O/A. This= way, the SDP answer message would be fatter compared to A, but it does req= uire entities involved in O/A to parse any parts of the VPS. C: In between A and B, by allowing for the use of the VPS for session negot= iation in O/A, but require the key parts like profile, level, and other Con= figuration parameters to be present in the answer SDP too. This way, the SD= P answer would probably be even a litter bit fatter than B, and it entities= involved in O/A may or may not parse the VPS. I personally prefer A, which is aligned with what we have in RFC 6190 (the = SVC payload format), and would be directly applicable for SHVC (the scalabl= e extension of HEVC) and MV-HEVC (the multiview extension of HEVC) as well. Again, I'd like to ask those who care about this draft and about deploying = HEVC over RTP to express their opinions, as really the market is deploying = HEVC already and we should try to get this document finalized as soon as po= ssible. Thanks!!! BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Thursday, May 08, 2014 5:39 AM To: Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02- on recv-= sub-layer-id Hi, Please see inline. On 2014-05-07 10:42, Yago Sanchez wrote: > Hi Magnus, >=20 > If we go this way we would be removing the purpose of using the VPS=20 > for session negotiation. >=20 > Deprecating the use of recv-sub-layer-id to stream selection and not=20 > using it for capability indication does not make much sense to me. Why=20 > should an answerer choose a lower sub-layer if it is claiming that it=20 > could get the highest one? There might be other reasons but the main=20 > one I can think of is because it cannot receive the highest sub-layer=20 > due to its capabilities. Thus, even though recv-sub-layer-id was used=20 > for stream selection, the offerer could reconfigure the encoder=20 > leading to the stream selection not being persistent, unless we stated=20 > somewhere that this is not allowed. I have to say that I am not a fan of performing selection and capability de= termination based on having to parse the VPS. The reason is that it makes t= he work of any intermediary including policy functions like these that exis= ts in IMS more difficult to implement. Not only need to to understand the p= arameters in the SDP, they also need to include a HEVC VPS parser, and it n= eeds to keep the offer VPS as state to determine what the answer means, as = this is only a reference into that structure. >=20 > Note also that right now the draft says that when recv-sub-layer-id is=20 > present the media configuration parameters MUST NOT be present, which=20 > means we cannot use recv-sub-layer-id for selection and add the=20 > level-id for level downgrade for capability indication. When an=20 > offerer gets the recv-sub-layer-id it could easily understand the=20 > capabilities of the answerer since it sent the sprop-vps but I see=20 > your concern for middleboxes which have to keep track of what was sent=20 > by the offerer. I did not see that as an issue but if you do, one=20 > potential way of solving it is to remove the part that says that media=20 > configuration parameters MUST NOT be present. Thus level downgrade=20 > could be accomplished while here we need a MUST for the level-id being=20 > equal to the level indicated in the VPS for the selected sub-layer.=20 > However, other parameters such as profile-id could be potentially=20 > different for different sub-layers, which means that the symmetry=20 > requirement of configuration parameters should be relaxed conditioned=20 > on whether the recv-sub-layer-id is present or not. Yes, I think my concerns are lessen by including the answer parameters that= matches what the recv-sub-layer-id layer requires. But, if that is done I = still wonder what the advantage is of using the VPS for capability determin= ation. Is it that the existing tools with profile and layers aren't fine gr= ained enough. Or is it completely focused on the need to negotiate layer in= formation. Something that will need a more complete (and likely complex) so= lution ones the scalable HEVC extensions are defined. 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 From nobody Tue May 13 10:38: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 7E9061A0141 for ; Tue, 13 May 2014 10:38:06 -0700 (PDT) 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 sAMWcLJNLMvq for ; Tue, 13 May 2014 10:37:57 -0700 (PDT) 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 DCBB31A018D for ; Tue, 13 May 2014 10:37:43 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.939.12; Tue, 13 May 2014 17:37:34 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.26]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.26]) with mapi id 15.00.0939.000; Tue, 13 May 2014 17:37:33 +0000 From: Stephan Wenger To: "Wang, Ye-Kui" , Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxmAvGxRz3pFU6I5jRks/D3MJrPvlAAgBXKtoCAJ2xrgIAVdNAAgACL4YCAA/zxAIAA/yUAgAKbJwCAAA2ygIACxNYAgAPm0oCAAMF4AIABFZ+AgACbyQCAAFQJAIAK+PqAgAApCgD//5XOgA== Date: Tue, 13 May 2014 17:37:32 +0000 Message-ID: References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(199002)(189002)(24454002)(13464003)(377424004)(76176999)(15202345003)(92726001)(80022001)(101416001)(36756003)(87936001)(85852003)(50986999)(2656002)(77982001)(66066001)(76482001)(99286001)(83322001)(15975445006)(8558605003)(19580395003)(19580405001)(81542001)(74502001)(99396002)(86362001)(4396001)(81342001)(83072002)(54356999)(74662001)(20776003)(21056001)(46102001)(79102001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/XHEFSHcXmIy4onBD_bVvoIH9Fg4 Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Tue, 13 May 2014 17:38:06 -0000 Hi, I=B9m one of the co-authors. To make one thing clear from the outset: I=B9m one who says that any and al= l options of a given payload necessarily need always to be supported by a RTP payload format. Sometimes, it=B9s IMO completely OK to forgo the support of an odd mechanism that=B9s not required or useful for the application =B3payload over the Internet using RTP=B2. That said, the case here is different. What we have here is a request (by Magnus) to narrow down the number of interoperability points negotiable using O/A negotiation, by intentionally disabling a mechanism that was expressly included for purposes just like this. There was considerable discussion in JCT-VC, MPEG, and VCEG about the subject. I would say it was one of the key drivers, but my view may be a bit one-sided. However, it was discussed more than once. The front lines were often between the hardware folks (who would like to have as few interop points as possible) and the software people (who would prefer to have a finer granularity, to better suit individual application needs). The resulting compromise necessarily made no one completely happy, but everyone could live with it. Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling architecture discussions/decisions. Thanks for your consideration, Stephan On 13.5.14, 9:57, "Wang, Ye-Kui" wrote: >Magnus, > >I understand your arguments too. Your main worry seems to be about the >HEVC profiling fracturing the market and reducing the interoperability of >HEVC, which I do share. However, the key point here is that, that is not >up to us, it is controlled by other organizations. If we go ahead to >disallow the support of that in the HEVC payload format, that does not >mean we would successfully prevent that from happening in MPEG/ITU-T and >other application standard organizations - and if that happens, then an >extension to the payload format would need to be specified, which might >introduce more IOP issues even on the RTP encapsulation level for HEVC. > >I fully agree that some more opinions from others would be very helpful. > >Please, whoever cares about this draft and cares about using HEVC with >RTP, say your opinion. We really need to have this document finalized >soon for HEVC deployment!!! > >See some other detailed replies inline below too. > >BR, YK > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, May 13, 2014 7:31 AM >To: Wang, Ye-Kui; Yago Sanchez >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >Ye-Kui and WG, > >Please see inline. I think we need input from more people into this >question to make progress. > > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: >> Magnus, >>=20 >> I think the only key different understanding between us now is the >> following: Whether to assume that a decoder does not fully support any >> profile indicated by profile-id (what you called "sub-profile", e.g. >> only support the common tools of two or more profiles). >>=20 >> Once we converge here, it should be easy to derive that text changes >> should be made. Thus, let me focus on this in this email. >>=20 >> Your opinion is obvious and strong - don't go into that direction. >>=20 >> My opinion is strong too - we do need to go into that direction, >> because of the following reasons: >>=20 >> - The ITU-T/MPEG control how to use the bits of profile-id and >> profile-compatibility-indicator in the video coding specifications. >> It is simply possible that a new profile can be defined and indicated >> without using a new value of profile-id, but indicated as conforming >> to two profiles. This happened for AVC for the Constrained Baseline >> profile as I explained. Also, in the recently finalized HEVC Range >> Extensions spec (see here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11/ >> JCTVC-Q1005-v4.zip), >> 19 new profiles have been defined, indicated by only one value of >> profile-id and some values of bits of the interop-constraints field >> (Note, not the profile-compatibility-indicator field). > >Yes this may happen, but jumping onto this now, do in fact create a tool >where anyone can attempt to create new interoperability points by >selecting an intersection between profiles. That doesn't benefit >interoperability, it instead fractures the market and works against the >purpose of the profiles in the first place. > >[YK]: Agreed - but again that is not up to us, it is controlled by other >SDOs (which are in turn driven by the markets). > >Secondly, in relation to H.264 constrained baseline, that was created >using constraint bits, a concept that already is part of the >specification, it might be defined as the intersection of two profiles, >but the signalling is done according to one profile with a specific bit >set. Just like the HEVC Range Extension profiles. > >[YK]: Why the signalling is different? Herein you also use a profile-id >value with a specific bit set. > >However, to me it appears that when one selected the structure for HEVC >Range Extensions one forgot about the profile-compatibility-indicator as >it is not possible to signal compatibility across the main directions in >the range extension profiles. The main directions are within themselves >nicely onion shaped, but the compatibility between them does not appear >to have been well considered. > >[YK]: I was not involved in the definition of the structure for HEVC >Range Extensions - so no comment here. > >>=20 >> - Application standards organizations, e.g. 3GPP, may require >> "sub-profile" capability for decoders. Again, AVC Constrained Baseline >> profile is an example - Magnus you should know this much better than >> many others. > >Yes, however I think it is usually bad for interoperability. And HEVC >does not appear to be in the same position that H.264 was when it was >just finished. Thus, I expect the issues are being different. > >[YK]: True - but on the other hand, that was driven by the market too, >and they wanted that for interoperability for that particular capability. >Here the issue is not about what was defined already in HEVC, but what >could be done in the future. When RFC 3984 was finalized, the Constrained >Baseline profile was not available yet. So, right now, the situation is >the same. Unless we can surely know similar things won't happen, we >should follow the approach in RFC 3984, i.e. to allow for such >intersection of two more profiles. Nobody can be sure right now for what >could happen in the future, at least for this issue. > >>=20 >> Thus, when defining the HEVC RTP payload here, I don't think we can >> ignore the above. Rather, we must go into the direction of >> "sub-profile". > >I understand your arguments. What is required is highly dependent on what >will be done with future profiling of HEVC. I see enabling the >possibility to intersect any choice of profiles do create an potential >for fracturing the market and reducing the interoperability of HEVC. > >[YK]: Again, agree in general, but again that is not controlled by us. > >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 From nobody Wed May 14 01:57:58 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 9AE1C1A0278 for ; Wed, 14 May 2014 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 f_thcG0tJg2R for ; Wed, 14 May 2014 01:57:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 853BC1A0273 for ; Wed, 14 May 2014 01:57:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-72-537330070f2f Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.98.04714.70033735; Wed, 14 May 2014 10:57:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 14 May 2014 10:57:43 +0200 From: Jonatan Samuelsson To: "Wang, Ye-Kui" , "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqvCW5lJ2j202VpYpONAh1lJsqWUMAgBWA2bA= Date: Wed, 14 May 2014 08:57:42 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@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: multipart/alternative; boundary="_000_634D3B5D82E3214DA9B6A36D5F50DB2321F92DESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+JvjS67QXGwwf1FlhaXLp5lsniy5hiz A5PHkiU/mTwWTX3GGMAUxWWTkpqTWZZapG+XwJVx/t0GxoIJxxgr5u74wtTAOH85YxcjJ4eE gInEsZenmCBsMYkL99azdTFycQgJHGWUmLh6JQuEs5hRYs2P+UAdHBxsAlYS319EgDSICIRK fPk4lR0kLCzgKnF6AjOIKSLgJnHliCJEhZXE+Zlv2EFsFgFViS2LprKA2LwC3hJt39cwQkzv YpTo3fUY7AZOgWCJA/M7WUFsRgFZifvf74E1MAuIS9x6Mh/qTgGJJXvOM0PYohIvH/9jhbAV Ja5OX84EUZ8vMWvfHUaIZYISJ2c+YZnAKDILyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x9 5sBjJmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI+vglt+6OxhXv3Y8xCjAwajE w7sgtihYiDWxrLgy9xCjNAeLkjhv213vYCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MCiuE PD+9Oxlxv1Qra0u0YdcVtSnusdfyJ7flLxXnOH45llVDVLggie1J2DIBXd0pTg+t1UJkvMRy Z/6e6vLvo5jt98NFjpP6+lRShRXXnEsuads1cQ2n+++Z9fKNJxyOmjM9s9s8XdnppMa/tklz mj47HpMqDnm4Yc5f06QZVdElv/ZKeQUpsRRnJBpqMRcVJwIAOZDwVo0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/q7i0UWhN1wsLmAEJ8nUOEAQqXLc Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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: Wed, 14 May 2014 08:57:56 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB2321F92DESESSMB109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsb consists of = fewer than 6 bits. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be corr= ect 2: The MD5 of the reference picture is incorrect (i.e. do = NOT use for reference) 3: The MD5 is included in the RPSI message (directly follo= wing the PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_634D3B5D82E3214DA9B6A36D5F50DB2321F92DESESSMB109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Ye-Kui, editors, all,
Thanks for improving the draft and makin= g the new version available. I read through the new section 8 in the latest= draft, in which more feedback features have been added (which I think is v= ery good). I have some minor comments and then some suggestions for improving the RPSI signalling. Compared to ea= rlier standards, HEVC contains a new very useful SEI message that can be us= ed to check integrity and correctness of decoded pictures and thereby detec= t errors that are not necessarily due to packet losses: Decoded  picture hash SEI (e.g. MD5 calculated o= ver a decoded picture) . I think it would be good to exploit that functiona= lity also in the RTP payload format for HEVC in order to make implementatio= ns even more robust.
First some minor comments:
In 8.1:
A. Remove one instance of 'the loss of' in the sentence: ' As specified in RFC 4585 section 6.3.1, the reception of a picture loss indication by a media sender= indicates the loss of "the loss of an undefined amount of coded video= data belonging to one or more pictures.".'
B. The 'BE' in 'SHOULD BE' should not be= using CAPITAL LETTERS.
In 8.2:
C. Regarding 'the loss of a number of Coded T= ree Blocks (CTBs) in CTB raster scan order of a picture.'. Wh= en tiles are used, the loss of a slice does typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for th= is case. Wouldn't it be better to use 'tile scan' in order to correctly identify what part of the picture was lost?
D. Regarding 'the subfield "First" = MUST be set to the CTB address of the first lost CTB'. Wouldn= 't it be better to require "First" to be set to a number that is lower than or equal to the CTB address of the= first lost CTB, since it might be difficult to deduce the exact CTB addres= s of the first lost CTB in the case of loss of  dependent slices and/o= r fragmentation units?
E. Regarding 'The subfield "PictureID&qu= ot; MUST  be  set  to  the  6  least signific= ant  bits  of  a  binary representation  of  = the  value  of slice_pic_order_cnt_lsb  of  the picture for which the lost CTBs are indicated.'.= Isn't it better to use the 6 least significant bits of PicOrderCntVal? Usi= ng the 6 least significant bits of  slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_ls= b consists of  fewer than 6 bits.
F. Regarding the sentence: 'In many cases, = error tracking is required to identify the corrupted region in the receiver= 's state (reference pictures) because of error import in uncorrupted regions of the picture through motion compensation, a= nd reference picture selection can also be used to "clean up" the= corrupted picture, which is usually more efficient and less likely to gene= rate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: 'In many cases= , error tracking is required to identify the corrupted region in the receiv= er's state (reference pictures) because of error import in uncorrupted regions of the picture through motion compen= sation. Reference picture selection can also be used to "clean up"= ; the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.'
Regarding RPSI (section 8.3) I would lik= e to propose the following changes:
G. Add the possibility to include more t= han one reference picture in the RPSI message so that the encoder can selec= t to use one or more of the pictures included in RPSI message. Using multip= le pictures for reference is a key feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection.
H. Using the 2 currently unused bits in = the '= Native RPSI bit string defined per codec' for adding the poss= ibility of including information regarding the MD5 in the RPSI message as follows:
0:   &n= bsp;        No information regarding the= MD5 available
1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)
The last option can be used when the enc= oder does not include MD5s in-band but wants to check the MD5 before using = a selected picture for reference. Typically this will be more bit-efficient= than including decoded picture hash SEI messages in-band.
In my opinion it would be very useful to= be able to include information regarding the correctness of the decoded pi= ctures, e.g. to detect incompatibility issues and bit errors. I will send a= suggestion for the text changes needed to enable this, hopefully later today.
Best Regards Jonatan
-----Original Message-----
From: payload [mailto:payload-b= ounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt
 
Dear All,
 
Compare to -02, we have addressed most of the numerous comments and ti= ckets, from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the followi= ng changes:
- Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the ref= lector, agreed by most of the authors, no objection from anyone.
- Addition of an informative, brief description of the display orienta= tion SEI message, which is among one of those new SEI messages that have so= me systems usage.
- Addition of a definition of NAL-unit-like structure. The term was us= ed but not defined earlier.
- Addition of descriptions for use of the PLI and SLI messages (specif= ied in RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in = addition to the RFC 4585 RPSI message for which the use description was alr= eady included, as agreed during the presentation at the previous IETF meeting
 
Remaining open issues:
- On profile-compatibility-indicator and interop-constraints (raised b= y Magnus, being discussed among Magnus, myself and Yago, no conclusion yet)=
- On recv-sub-layer-id and using of sprop-vps for session negotiation = (raised by Magnus, still being discussed among the authors and Magnus)
- On source-specific sprop parameter sets (raised by Magnus, still bei= ng discussed among the authors and Jonathan for exact text changes)
- On using a different parameter category for level-id (raised by Magn= us, discussed between Magnus and myself, no conclusion yet)
- I just noticed that the definition of "packet stream" itse= lf needs to be changed back to "RTP stream"
 
We will try to address the above open issues as soon as possible. At t= he same time, further review and comments are welcome.
 
BR, YK
 
-----Original Message-----
Sent: Wednesday, April 30, 2014 10:34 AM
Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Audio/Video Transport Payloads Worki= ng Group of the IETF.
 
        Title   &nbs= p;       : RTP Payload Format for High Effici= ency Video Coding
        Authors   &n= bsp;     : Ye-Kui Wang
           &nbs= p;            &= nbsp; Yago Sanchez
           &nbs= p;            &= nbsp; Thomas Schierl
           &nbs= p;            &= nbsp; Stephan Wenger
           &nbs= p;            &= nbsp; Miska M. Hannuksela
        Filename   &= nbsp;    : draft-ietf-payload-rtp-h265-03.txt
        Pages   &nbs= p;       : 92
        Date    = ;        : 2014-04-30
 
Abstract:
   This memo describes an RTP payload format for the video c= oding
   standard ITU-T Recommendation H.265 and ISO/IEC Internati= onal
   Standard 23008-2, both also known as High Efficiency Vide= o Coding
   (HEVC) [HEVC] and developed by the Joint Collaborative Te= am on Video
   Coding (JCT-VC).  The RTP payload format allows for = packetization of
   one or more Network Abstraction Layer (NAL) units in each= RTP packet
   payload, as well as fragmentation of a NAL unit into mult= iple RTP
   packets.  Furthermore, it supports transmission of a= n HEVC bitstream
   over a single as well as multiple RTP streams.  The = payload format
   has wide applicability in videoconferencing, Internet vid= eo
   streaming, and high bit-rate entertainment-quality video,= among
   others.
 
 
The IETF datatracker status page for this draft is:
 
There's also a htmlized version available at:
 
A diff from the previous version is available at:
 
 
Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.=
 
Internet-Drafts are also available by anonymous FTP at:
 
_______________________________________________
payload mailing list
 
_______________________________________________
payload mailing list
 
 --_000_634D3B5D82E3214DA9B6A36D5F50DB2321F92DESESSMB109ericsso_-- From nobody Thu May 15 13:25:39 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 A5F5E1A02F3 for ; Thu, 15 May 2014 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, 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 KGJK8zCSPVOw for ; Thu, 15 May 2014 13:25:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27B01A0191 for ; Thu, 15 May 2014 13:25:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-c5-537522af9f25 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.CF.04329.FA225735; Thu, 15 May 2014 22:25:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Thu, 15 May 2014 22:25:18 +0200 From: Jonatan Samuelsson To: Jonatan Samuelsson , "Wang, Ye-Kui" , "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqvCW5lJ2j202VpYpONAh1lJsqWUMAgBWA2bCAAePN8A== Date: Thu, 15 May 2014 20:25:18 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB2321FFB6@ESESSMB109.ericsson.se> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> 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: multipart/alternative; boundary="_000_634D3B5D82E3214DA9B6A36D5F50DB2321FFB6ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje56pdJgg9t3+C0uXTzLZPFkzTFm ByaPJUt+MnksmvqMMYApissmJTUnsyy1SN8ugSvjUFtWwc1m1orO1Y+ZGxh/bGbpYuTgkBAw kVh53bmLkRPIFJO4cG89WxcjF4eQwFFGiWv73jBDOIsZJSY3/mEFaWATsJL4/iICpEFEoJtR 4t9CWZCwsICrxOkJzCCmiICbxJUjihAVThLXz28Ba2QRUJWYfZwTxOQV8JaY9EgaYvYZRonX V+8xgpRzCvhITO5/xA5iMwrIStz/fo8FxGYWEJe49WQ+E8SVAhJL9pxnhrBFJV4+/scKYStJ NC55wgpRny/Rvm0TmM0rIChxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hn DjxmQhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwog5u+W21g/Hgc8dDjAIcjEo8 vArri4OFWBPLiitzDzFKc7AoifPeOFwSLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExUCji xJUT/l7Pnr2yED3/P5lNWe/Kmb7jj4pfXRW6pxeps0Got2S+Zd3EbZ+/3V5UnxYftKFzfbPv vXVH0itq5N1+6V/0KMtYu2/2q8x10XkOmvqmzEJX/2VOuikpq7DoqJbY3LSgwoufFmz1zjxS 0r3LOnb/bNlenQ0r7D1mFj8PcFUty8hUYinOSDTUYi4qTgQA13EnCIkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/TXKDCqXKY0unriJvaU9pPbDuUA0 Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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: Thu, 15 May 2014 20:25:37 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB2321FFB6ESESSMB109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Magnus and I have written text for enabling the use of decoded picture hash= (e.g. MD5) information in RPSI feedback messages. We have made sure that t= he syntax to a large extent is compatible with earlier versions of the draf= t in case anyone has started to implement HEVC RPSI already (since the MT v= alue equal to 0 corresponds to that no information regarding the decoded pi= cture hash is available in the RPSI message). The suggestion includes: - The possibility to include more than one reference picture in an= RPSI feedback message - The possibility to indicate information about decoded picture ha= sh (e.g. MD5) for each picture in an RPSI feedback message - A parameter, include-dph, for indicating/requesting that decoded= picture hash SEI will be sent with the video data - A parameter, rpsi-dph, for indicating/requesting that decoded pi= cture hash will be included in RPSI feedback messages Here is our suggested text: 8.3 Use of HEVC with the RPSI Feedback Message Feedback based reference picture selection has been shown as a powerful too= l to stop temporal error propagation for improved error resilience [Girod99= ][Wang05]. In one approach, the decoder side tracks errors in the decoded = pictures and informs to the encoder side that one or more particular pictur= es that has been decoded relatively earlier is correct and still present in= the decoded picture buffer and requests the encoder to use one or more of = those correct pictures for reference when encoding the next picture, so to = stop further temporal error propagation. For this approach, the decoder si= de should use the RPSI feedback message [RFC4585]. Encoders can encode some long-term reference pictures as specified in H.264= or HEVC for purposes described in the previous paragraph without the need = of a huge decoded picture buffer. As shown in [Wang05], with a flexible re= ference picture management scheme as in H.264 and HEVC, even a decoded pict= ure buffer size of two would work for the approach described in the previou= s paragraph. The hash values, as defined in section D.3.19 in [HEVC] can be= used to verify the correctness of decoded pictures. Informative note: The use of hash values calculated over the decoded sample= values enables detection of problems that are not necessarily due to packe= t losses. Examples of such errors are; bit-errors in the transport, memory = corruption in decoder or encoder and encoder-decoder incompatibility proble= ms (i.e. due to non-conforming encoder or decoder). For HEVC, the field "Native RPSI bit string defined per codec" in the RPSI = message consists of one or more entries that follows the format depicted in= Figure X: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT| RefLayer | RefPicId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RefPicId | | +-+-+-+-+-+-+-+-+ + | | + Decoded Picture Hash (conditional) + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure X: The HEVC "Native RPSI bit string defined per codec" The semantics of the fields are as follows: MT: 2 bits Indicates the hash information as follows: 0: No hash information regarding the correctness of the refere= nce picture is available. 1: The Decoded Picture Hash SEI has been used to verify the re= ference picture to be correct. 2: The Decoded Picture Hash SEI has been used to verify the re= ference picture to be incorrect. 3: The Decoded Picture Hash of the reference picture is includ= ed in the RPSI message. When MT equals 0, 1 or 3, the reference picture identified by the current e= ntry is requested to be used for reference when encoding the next picture. = For 3 with the exception, if the encoder finds the provided hash of the ref= erence picture to not match the encoder's hash value, in which case it MUST= NOT use the reference picture. Informative note: When an RPSI message contains more than one entry with MT= equal to 0, 1 or 3 the encoder may select one or more of the identified pi= ctures to be used for reference. The selection of which picture(s) to use f= or reference is out of scope of this specification but may for example be b= ased on maximizing compression efficiency. When MT equals 2 the reference picture identified by the current entry MUST= NOT be used for reference for the next picture or any picture that follows= the next picture. RefLayer: 6 bits Represents the 6 bits of nuh_layer_id of the reference picture, as defined = in [HEVC]. RefPicId: 32 bits Represents the value of the PicOrderCntVal (in network byte order) of the r= eference picture, as defined in [HEVC]. Decoded Picture Hash: Variable number of bytes Present only if MT equals 3. Represent the Decoded Picture Hash SEI payload= (in network byte order), see D.2.19 of [HEVC], of the decoded picture. The= Decoded Picture Hash payload starts with a one byte type field, which give= s the amount of hash data (2, 4 or 16 bytes for the defined hashes). The use of the RPSI feedback message as positive acknowledgement with HEVC = is deprecated. In other words, the RPSI feedback message MUST only be used= as a reference picture selection request, such that it can also be used in= multicast. Section 7.1 New parameters: include-dph: This parameter is used to indicate capability and preference to utilize or = include Decoded Picture Hash (DPH) SEI messages (See Section D.3.19 of [HEV= C]) in the encoded video sequence. The value is a comma separated list of h= ash types that is supported or requested to be used, each hash type provide= d as an unsigned integer value (0-255), with the hash types listed from mos= t preferred to the least preferred. Example: "include-dph=3D0,2", which ind= icates the capability for MD5 (most preferred) and Checksum (less preferred= ). If the parameter is not included or the value contains no hash types, th= en no capability to utilize DPH SEI messages is assumed. Note that DPH SEI = messages MAY still be included in the encoded video sequence even when ther= e is no declaration of capability to use them. rpsi-dph: This parameter is used to indicate capability and preference for which type= s of Decoded Picture Hash to include or use with the RTCP Reference Picture= Selection Indication (RPSI) message as defined in Section 8.3. The value i= s a comma separated list of hash types that is supported or requested to be= used, each hash type provided as an unsigned integer value (0-255), with t= he hash types listed from most preferred to the least preferred. If the par= ameter is not included or the value contains no hash types, then no capabil= ity to utilize DPH in RPSI is assumed. In this case, RTCP RPSI entries usin= g MT=3D3 SHALL NOT be sent, MT=3D0,1, and 2 MAY still be sent. This paramet= er has meaning only if support for RTCP RPSI messages for the HEVC RTP payl= oad type is indicated. Section 7.2.1: Add above parameters in list of Optional parameters Section 7.2.2: * The capability parameter include-dph MAY be used to declare the capabi= lity to utilize Decoded Picture Hash SEI messages and which types of hashes= in any RTP streams received by the offerer or answerer. The parameter MAY = be included in offerer or answerer's media descriptions that are a=3Dsendon= ly to indicate a capability to provide DPH SEIs. * The capability parameter rpsi-dph MAY be used to declare an offerer or= answerer's capability to receive RPSI messages which include Decoded Pictu= re Hash and which types of hashes. This parameter SHOULD only be provided w= hen RTCP RPSI is indicated. Note that this parameter is media sender proper= ty, not a receiver property. Thus, for media descriptions with sendonly or = sendrecv, the declaring entity (offerer or answerer) has the capability to = receive RPSI with the hashes. For a media description that is a=3Drecvonly = the inclusion of the parameter indicates the capability of media receiver t= o provide hashes in the RPSI it may send. Section 7.2.3: Add include-dph and rpsi-dph to the list "Declaring actual configuration or= bitstream properties:" Best Regards Jonatan and Magnus From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonatan Samuel= sson Sent: den 14 maj 2014 10:58 To: Wang, Ye-Kui; payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsb consists of = fewer than 6 bits. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be correct 2: The MD5 of the reference picture is incorrect (i.e. do NOT us= e for reference) 3: The MD5 is included in the RPSI message (directly following t= he PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 Gro= up of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_634D3B5D82E3214DA9B6A36D5F50DB2321FFB6ESESSMB109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,<= o:p>

 = ;

Magnus and= I have written text for enabling the use of decoded picture hash (e.g. MD5= ) information in RPSI feedback messages. We have made sure that the syntax to a large extent is compatible with earlier versions of t= he draft in case anyone has started to implement HEVC RPSI already (since t= he MT value equal to 0 corresponds to that no information regarding the dec= oded picture hash is available in the RPSI message).

 = ;

The sugges= tion includes:

-          Th= e possibility to include more than one reference picture in an RPSI feedbac= k message

-          Th= e possibility to indicate information about decoded picture hash (e.g. MD5)= for each picture in an RPSI feedback message

-          A = parameter, include-dph, for indicating/requesting that decoded picture hash SEI will be sent with the video data

-          A = parameter, rpsi-dph, = for indicating/requesting that decoded picture hash will be included in RPSI feedback messages

 = ;

Here is ou= r suggested text:

 = ;

8.3 Use of HEVC with the RPSI Feedback Mess= age

 

Feedback based reference picture selection = has been shown as a powerful tool to stop temporal error propagation for im= proved error resilience [Girod99][Wang05].  In one approach, the decoder side tracks errors in the decoded pictures and infor= ms to the encoder side that one or more particular pictures that has been d= ecoded relatively earlier is correct and still present in the decoded pictu= re buffer and requests the encoder to use one or more of those correct pictures for reference when encoding t= he next picture, so to stop further temporal error propagation.  For t= his approach, the decoder side should use the RPSI feedback message [RFC458= 5].

 

Encoders can encode some long-term referenc= e pictures as specified in H.264 or HEVC for purposes described in the prev= ious paragraph without the need of a huge decoded picture buffer.  As shown in [Wang05], with a flexible reference pict= ure management scheme as in H.264 and HEVC, even a decoded picture buffer s= ize of two would work for the approach described in the previous paragraph.= The hash values, as defined in section D.3.19 in [HEVC] can be used to verify the correctness of decoded pictures= .

 

Informative no= te: The use of hash values calculated over the decoded sample values enable= s detection of problems that are not necessarily due to packet losses. Examples of such errors are; bit-errors in the transport= , memory corruption in decoder or encoder and encoder-decoder incompatibili= ty problems (i.e. due to non-conforming encoder or decoder).

 

For HEVC, the field "Native RPSI bit s= tring defined per codec" in the RPSI message consists of one or more e= ntries that follows the format depicted in Figure X:

   0     = ;             &= nbsp;1           &nb= sp;       2     &nbs= p;             = 3

    0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

   | MT| RefLayer  | &n= bsp;            = ;   RefPicId         = ;             |=

   +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

   |    RefPicId&n= bsp;  |          &nb= sp;            =             &nb= sp;           |

   +-+-+-+-+-= +-+-+-+        &nbs= p;            &= nbsp;           &nbs= p;             = +

   |     = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;       |

   +    &= nbsp;        Decoded Picture Hash (condi= tional)           &n= bsp;    +

   |     = ;            &n= bsp;            = ;            &n= bsp;            = ;        |

   +    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        +

   |     = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;       |

   +    &= nbsp;            &nb= sp;            =  +-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

   |     = ;             &= nbsp;           &nbs= p;|

   +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+&nbs= p; 

Figure X: The HEVC "Native RPSI bit st= ring defined per codec"

 

The semantics of the fields are as follows:=

 

MT: 2 bits

     Indicates the hash= information as follows:

       &= nbsp;   0:   No hash information regarding the correctn= ess of the reference picture is available.

       &= nbsp;   1:   The Decoded Picture Hash SEI has been used= to verify the reference picture to be correct.

       &= nbsp;   2:   The Decoded Picture Hash SEI has been used= to verify the reference picture to be incorrect.

       &= nbsp;   3:   The Decoded Picture Hash of the reference = picture is included in the RPSI message.

When MT equals= 0, 1 or 3, the reference picture identified by the current entry is reques= ted to be used for reference when encoding the next picture. For 3 with the exception, if the encoder finds the provided hash = of the reference picture to not match the encoder’s hash value, in wh= ich case it MUST NOT use the reference picture.

 

Informative no= te: When an RPSI message contains more than one entry with MT equal to 0, 1= or 3 the encoder may select one or more of the identified pictures to be used for reference. The selection of which picture(s) to us= e for reference is out of scope of this specification but may for example b= e based on maximizing compression efficiency.

 

When MT equals= 2 the reference picture identified by the current entry MUST NOT be used f= or reference for the next picture or any picture that follows the next picture.

 

RefLayer: 6 bits

Represents the= 6 bits of nuh_layer_id of the reference picture, as defined in [HEVC].

 

RefPicId: 32 bits

Represents the= value of the PicOrderCntVal (in network byte order) of the reference pictu= re, as defined in [HEVC].

 

Decoded Picture Hash: Variable number of by= tes

Present only i= f MT equals 3. Represent the Decoded Picture Hash SEI payload (in network b= yte order), see D.2.19 of [HEVC], of the decoded picture. The Decoded Picture Hash payload starts with a one byte type field, which = gives the amount of hash data (2, 4 or 16 bytes for the defined hashes).

 

The use of the= RPSI feedback message as positive acknowledgement with HEVC is deprecated.=   In other words, the RPSI feedback message MUST only be used as a reference picture selection request, such that it can also be= used in multicast.

 = ;

Section 7.= 1

New parame= ters:

 

include-dph:

This parameter= is used to indicate capability and preference to utilize or include Decode= d Picture Hash (DPH) SEI messages (See Section D.3.19 of [HEVC]) in the encoded video sequence. The value is a comma separated l= ist of hash types that is supported or requested to be used, each hash type= provided as an unsigned integer value (0-255), with the hash types listed = from most preferred to the least preferred. Example: “include-dph=3D0,2”, which indicates the c= apability for MD5 (most preferred) and Checksum (less preferred). If the pa= rameter is not included or the value contains no hash types, then no capabi= lity to utilize DPH SEI messages is assumed. Note that DPH SEI messages MAY still be included in the encoded video sequence = even when there is no declaration of capability to use them.

 

rpsi-dph:

This parameter= is used to indicate capability and preference for which types of Decoded P= icture Hash to include or use with the RTCP Reference Picture Selection Indication (RPSI) message as defined in Section 8.3. The= value is a comma separated list of hash types that is supported or request= ed to be used, each hash type provided as an unsigned integer value (0-255)= , with the hash types listed from most preferred to the least preferred. If the parameter is not included or= the value contains no hash types, then no capability to utilize DPH in RPS= I is assumed. In this case, RTCP RPSI entries using MT=3D3 SHALL NOT be sen= t, MT=3D0,1, and 2 MAY still be sent. This parameter has meaning only if support for RTCP RPSI messages for the = HEVC RTP payload type is indicated.

 = ;

Section 7.= 2.1:

Add above = parameters in list of Optional parameters

 = ;

Section 7.= 2.2:

•    The capability pa= rameter include-dph MAY be used to declare the capability to utilize Decode= d Picture Hash SEI messages and which types of hashes in any RTP streams received by the offerer or answerer. The parameter MAY be included in offe= rer or answerer’s media descriptions that are a=3Dsendonly to indicat= e a capability to provide DPH SEIs.

•    The capability pa= rameter rpsi-dph MAY be used to declare an offerer or answerer’s capa= bility to receive RPSI messages which include Decoded Picture Hash and whic= h types of hashes. This parameter SHOULD only be provided when RTCP RPSI is = indicated. Note that this parameter is media sender property, not a receive= r property. Thus, for media descriptions with sendonly or sendrecv, the dec= laring entity (offerer or answerer) has the capability to receive RPSI with the hashes. For a media descriptio= n that is a=3Drecvonly the inclusion of the parameter indicates the capabil= ity of media receiver to provide hashes in the RPSI it may send.=

 

Section 7.= 2.3:

Add includ= e-dph and rpsi-dph to the list “Declaring actual configuration or bit= stream properties:”

 

Best Regards Jonatan and = Magnus

 = ;

 = ;

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Jonatan Samuelsson
Sent: den 14 maj 2014 10:58
To: Wang, Ye-Kui; payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Dear Ye-Kui, editors, all,

Thanks for improving the draft and maki= ng the new version available. I read through the new section 8 in the lates= t draft, in which more feedback features have been added (which I think is very good). I have some minor comments and then some sug= gestions for improving the RPSI signalling. Compared to earlier standards, = HEVC contains a new very useful SEI message that can be used to check integ= rity and correctness of decoded pictures and thereby detect errors that are not necessarily due to packet = losses: Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also in t= he RTP payload format for HEVC in order to make implementations even more robust.

First some minor comments:

In 8.1:

A. Remove one instance of 'the loss of' in the sentence: ' As specified in RFC 4585 section 6.3.1, the reception of a picture loss in= dication by a media sender indicates the loss of "the loss of an undef= ined amount of coded video data belonging to one or more pictures.".'

B. The 'BE' in 'SHOULD BE' should not b= e using CAPITAL LETTERS.

In 8.2:

C. Regarding 'the loss of a number of = Coded Tree Blocks (CTBs) in CTB raster scan order of a picture.'. When tiles are used, the loss of a slice does typically not result in lost= CTBs in raster scan order of the picture. The text does not describe how t= o calculate the "Number" field for this case. Wouldn't it be bett= er to use 'tile scan' in order to correctly identify what part of the = picture was lost?

D. Regarding 'the subfield "First= " MUST be set to the CTB address of the first lost CTB'. Wouldn't it be better to require "First" to= be set to a number that is lower than or equal to the CTB address of the f= irst lost CTB, since it might be difficult to deduce the exact CTB address of t= he first lost CTB in the case of loss of  dependent slices and/or frag= mentation units?

E. Regarding 'The subfield "Pictu= reID" MUST  be  set  to  the  6  least s= ignificant  bits  of  a  binary representation  of  the  value  of slice_pic_order_cnt_lsb  of  t= he picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of  slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_lsb consists of  fewer than 6= bits.

F. Regarding the sentence: 'In many ca= ses, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncor= rupted regions of the picture through motion compensation, and reference pi= cture selection can also be used to "clean up" the corrupted pict= ure, which is usually more efficient and less likely to generate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: = ''

Regarding RPSI (section 8.3) I would li= ke to propose the following changes:

G. Add the possibility to include more = than one reference picture in the RPSI message so that the encoder can sele= ct to use one or more of the pictures included in RPSI message. Using multiple pictures for reference is a key feature in HEVC which subst= antially improves coding efficiency. In the case where multiple earlier pic= tures are available for reference it is beneficial to let the encoder decid= e which one(s) to use for reference instead of relying on the decoder to make that selection.

H. Using the 2 currently unused bits in= the 'Native RPSI bit string defined per codec' for adding the possibility of including information regarding the MD5 in t= he RPSI message as follows:

0:      &= nbsp;     No information regarding the MD5 available 1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)

The last option can be used when the en= coder does not include MD5s in-band but wants to check the MD5 before using= a selected picture for reference. Typically this will be more bit-efficient than including decoded picture hash SEI messages in-ban= d.

In my opinion it would be very useful t= o be able to include information regarding the correctness of the decoded p= ictures, e.g. to detect incompatibility issues and bit errors. I will send a suggestion for the text changes needed to enable this, hopef= ully later today.

Best Regards Jonatan<= /p>

-----Original Message-----
From: payload [mailto:payload-b= ounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt<= /o:p>

 

Dear All,

 

Compare to -02, we have addressed most = of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Berna= rd, ..., as well as the following changes:

- Addition of sprop-sei, as suggested b= y Stephan on Apr. 23 to the reflector, agreed by most of the authors, no ob= jection from anyone.

- Addition of an informative, brief des= cription of the display orientation SEI message, which is among one of thos= e new SEI messages that have some systems usage.

- Addition of a definition of NAL-unit-= like structure. The term was used but not defined earlier.

- Addition of descriptions for use of t= he PLI and SLI messages (specified in RFC 4585) and the FIR message (specif= ied in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed= during the presentation at the previous IETF meeting

 

Remaining open issues:

- On profile-compatibility-indicator an= d interop-constraints (raised by Magnus, being discussed among Magnus, myse= lf and Yago, no conclusion yet)

- On recv-sub-layer-id and using of spr= op-vps for session negotiation (raised by Magnus, still being discussed amo= ng the authors and Magnus)

- On source-specific sprop parameter se= ts (raised by Magnus, still being discussed among the authors and Jonathan = for exact text changes)

- On using a different parameter catego= ry for level-id (raised by Magnus, discussed between Magnus and myself, no = conclusion yet)

- I just noticed that the definition of= "packet stream" itself needs to be changed back to "RTP str= eam"

 

We will try to address the above open i= ssues as soon as possible. At the same time, further review and comments ar= e welcome.

 

BR, YK

 

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

Sent: Wednesday, April 30, 2014 10:34 A= M

Cc: payload@ietf.org<= /p>

Subject: [payload] I-D Action: draft-ie= tf-payload-rtp-h265-03.txt

 

 

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.

 

      &nb= sp; Title           : RTP= Payload Format for High Efficiency Video Coding

      &nb= sp; Authors         : Ye-Kui Wang

      &nb= sp;            =        Yago Sanchez

      &nb= sp;            =        Thomas Schierl

      &nb= sp;            =        Stephan Wenger

      &nb= sp;            =        Miska M. Hannuksela<= /p>

      &nb= sp; Filename        : draft-ietf-payload= -rtp-h265-03.txt

      &nb= sp; Pages           : 92<= o:p>

      &nb= sp; Date            = : 2014-04-30

 

Abstract:

   This memo describes an RTP= payload format for the video coding

   standard ITU-T Recommendat= ion H.265 and ISO/IEC International

   Standard 23008-2, both als= o known as High Efficiency Video Coding

   (HEVC) [HEVC] and develope= d by the Joint Collaborative Team on Video

   Coding (JCT-VC).  The= RTP payload format allows for packetization of

   one or more Network Abstra= ction Layer (NAL) units in each RTP packet

   payload, as well as fragme= ntation of a NAL unit into multiple RTP

   packets.  Furthermore= , it supports transmission of an HEVC bitstream

   over a single as well as m= ultiple RTP streams.  The payload format

   has wide applicability in = videoconferencing, Internet video

   streaming, and high bit-ra= te entertainment-quality video, among

   others.<= /p>

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

payload mailing list<= /p>

 

_______________________________________= ________

payload mailing list<= /p>

 

--_000_634D3B5D82E3214DA9B6A36D5F50DB2321FFB6ESESSMB109ericsso_-- From nobody Fri May 16 02:30: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 1075F1A01DF for ; Fri, 16 May 2014 02:30:51 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 wnt2e0wNgh1P for ; Fri, 16 May 2014 02:30:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E171A01BA for ; Fri, 16 May 2014 02:30:42 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-4c-5375dab97fdc Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.71.04199.9BAD5735; Fri, 16 May 2014 11:30:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Fri, 16 May 2014 11:30:32 +0200 From: Jonatan Samuelsson To: Stephan Wenger , "Wang, Ye-Kui" , Magnus Westerlund , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAVZn0AgACL4YCAA/zxAIAA/yUAgAKbJwCAAA2ygIACxNYAgAPm0oCAAMF4AIABFZ+AgACbyQCAAFQJAIAK+PqAgAApCgCAAAsqAIAETxpg Date: Fri, 16 May 2014 09:30:33 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109.ericsson.se> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@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.17] Content-Type: multipart/alternative; boundary="_000_634D3B5D82E3214DA9B6A36D5F50DB23220112ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvje7OW6XBBienGVicuriP1eLSxbNM FtcbN7FbTDq+ls3iyZpjzA6sHtNPLWb2WLLkJ5PHoqnPGD0Wr3/P6PHl8me2ANYoLpuU1JzM stQifbsErox/O4UKvtxjqvjeOputgfHcWqYuRk4OCQETiWttz6FsMYkL99azdTFycQgJHGWU OL3wGSNIQkhgMaPEv5PGXYwcHGwCVhLfX0SA1IgIbGeU2LlwNTOIwyzQwSixdfJkFpAiYQFH iRcH1EBMEQEniZM7uSDqVzFKnLo1jw1kJouAqsS2rSvAynkFvCWu/S6B2HueXWLVvQdgB3EK 6ErMnfeJBcRmFJCVuP/9HpjNLCAucevJfKijBSSW7DnPDGGLSrx8/I8VZKaEgKLE8n45iPJ8 ibb2B2AlvAKCEidnPmGZwCg6C8mkWUjKZiEpg4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTx BYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECY/Xglt8GOxhfPnc8xCjAwajEw/vAojRY iDWxrLgy9xCjNAeLkjjv7V1AIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwL4u+65Cuffygv csNr1eadRx5PecV67qGOtbT+dOEilWWCEnrXNquYf9swMXtvcJp/UWwos4LLG+51l2UNWhXv Xgou37BN+Jfx/lLhj+xGZ56sb4pfsKV45o+kFG3maT6PXl5ni2y8WHfm4PGwrQE/z7VFba3l 55i/q5Zr9rWwKS/X7Jj8b0OPEktxRqKhFnNRcSIA3HbE57YCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/p2piFcxFTrOFzTHhb190TZCe1Og Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Fri, 16 May 2014 09:30:51 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB23220112ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ye-Kui, Stefan, all, Let me express my opinion on this topic (since you explicitly asked for mor= e opinions). I do represent the same company as Magnus, but (in contrast to= Magnus) I was also part of the discussions on how to define the profiles i= n HEVC version 1. I share Magnus' view that it would be very unfortunate if= the payload format allows for definitions of sub-profiles using profile-co= mpatibility-indicator. The purpose of the profile_compatibility_flags is ve= ry clear in the contribution that proposed them, JCTVC-I0499 (http://phenix= .it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761): "We need a labelling scheme that: a) allows the committee to introduce new profiles, and older systems b= e able to work out which bitstreams they can decode when those new profiles= are fully subsets of older existing profiles, even when they do not recogn= ize the new profile identifier; b) allows bitstreams which don't use all the features of any given pro= file, and are as a consequence compatible with more than one, to be labelle= d with so that it's possible to deduce all the profiles that the bitstream = is compatible with (the ones that don't automatically follow from the nesti= ng structure). " If there is an intersection between two profiles that does make sense and i= s useful to the industry it is reasonable to assume that ITU/ISO/IEC would = define a new profile corresponding to that intersection (just as was done w= ith Constrained Baseline Profile in h.264). And in HEVC, the profile_compat= ibility_flags provides a mechanism for introducing a new profile, with a ne= w profile_idc while still being able to indicate conformance to one or more= of the old profiles (a mechanism that did not exist in h.264). However, it is worth noting that the way the Range Extension profiles have = been defined in the second (soon to be released) version of HEVC, the funct= ionality of profile_compatibility_flag is already broken. There are 19 new = profiles in there but only one profile_idc is used to identify them. Thus i= t is not possible in the same bitstream to indicate that it conforms to two= different of these 19 profiles. Now to connect back to the example you mentioned, Ye-Kui, on May 5: "There = can be still be a point to offer profile-compatibility-indicator in this ca= se. For example, it is possible that the decoder of the offerer only suppor= ts the common tools of profiles A and B, while it does not support either f= ull profile A or full profile B. 1. I don't think this is desirable. 2. Within the profiles defined in "format range extension" (~90% of t= he profiles defined so far) this is not possible. 3. When I read the latest HEVC payload format draft, I don't find any= thing supporting that kind of usage of profile-compatibility-indicator. On = the contrary: A decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. The profile-compatibility-indicator provides exact information of the ability of a decoder conforming to a certain profile to decode bitstreams conforming to another profile. More concretely, if the profile compatibility flag corresponding to the profile a decoder conforms to is set, then the decoder is able to decode any bitstream with the flag set, irrespective of the profile the bitstream conforms to (provided that the decoder supports the highest level of the bitstream). I can see the benefit in using the interop-constraints to express constrain= ts that applies to well-defined profiles (both from a decoder and encoder p= oint of view). However, using profile-compatibility-indicator to let decode= rs create ad-hoc on the fly "sub-profiles" of an arbitrary number of define= d profiles serves IMO no purpose and is simply a misuse of the profile_comp= atibility_flags. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: den 13 maj 2014 19:38 To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, I=B9m one of the co-authors. To make one thing clear from the outset: I=B9m one who says that any and al= l options of a given payload necessarily need always to be supported by a R= TP payload format. Sometimes, it=B9s IMO completely OK to forgo the suppor= t of an odd mechanism that=B9s not required or useful for the application = =B3payload over the Internet using RTP=B2. That said, the case here is different. What we have here is a request (by Magnus) to narrow down the number of interoperability points negotiable usi= ng O/A negotiation, by intentionally disabling a mechanism that was express= ly included for purposes just like this. There was considerable discussion= in JCT-VC, MPEG, and VCEG about the subject. I would say it was one of th= e key drivers, but my view may be a bit one-sided. However, it was discuss= ed more than once. The front lines were often between the hardware folks (= who would like to have as few interop points as possible) and the software = people (who would prefer to have a finer granularity, to better suit indivi= dual application needs). The resulting compromise necessarily made no one = completely happy, but everyone could live with it. Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling arch= itecture discussions/decisions. Thanks for your consideration, Stephan On 13.5.14, 9:57, "Wang, Ye-Kui" > wrote: >Magnus, > >I understand your arguments too. Your main worry seems to be about the >HEVC profiling fracturing the market and reducing the interoperability >of HEVC, which I do share. However, the key point here is that, that is >not up to us, it is controlled by other organizations. If we go ahead >to disallow the support of that in the HEVC payload format, that does >not mean we would successfully prevent that from happening in >MPEG/ITU-T and other application standard organizations - and if that >happens, then an extension to the payload format would need to be >specified, which might introduce more IOP issues even on the RTP encapsula= tion level for HEVC. > >I fully agree that some more opinions from others would be very helpful. > >Please, whoever cares about this draft and cares about using HEVC with >RTP, say your opinion. We really need to have this document finalized >soon for HEVC deployment!!! > >See some other detailed replies inline below too. > >BR, YK > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, May 13, 2014 7:31 AM >To: Wang, Ye-Kui; Yago Sanchez >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265= @tools.ietf.org >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >Ye-Kui and WG, > >Please see inline. I think we need input from more people into this >question to make progress. > > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: >> Magnus, >> >> I think the only key different understanding between us now is the >> following: Whether to assume that a decoder does not fully support >> any profile indicated by profile-id (what you called "sub-profile", e.g. >> only support the common tools of two or more profiles). >> >> Once we converge here, it should be easy to derive that text changes >> should be made. Thus, let me focus on this in this email. >> >> Your opinion is obvious and strong - don't go into that direction. >> >> My opinion is strong too - we do need to go into that direction, >> because of the following reasons: >> >> - The ITU-T/MPEG control how to use the bits of profile-id and >> profile-compatibility-indicator in the video coding specifications. >> It is simply possible that a new profile can be defined and indicated >> without using a new value of profile-id, but indicated as conforming >> to two profiles. This happened for AVC for the Constrained Baseline >> profile as I explained. Also, in the recently finalized HEVC Range >> Extensions spec (see here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11 >> / >> JCTVC-Q1005-v4.zip), >> 19 new profiles have been defined, indicated by only one value of >> profile-id and some values of bits of the interop-constraints field >> (Note, not the profile-compatibility-indicator field). > >Yes this may happen, but jumping onto this now, do in fact create a >tool where anyone can attempt to create new interoperability points by >selecting an intersection between profiles. That doesn't benefit >interoperability, it instead fractures the market and works against the >purpose of the profiles in the first place. > >[YK]: Agreed - but again that is not up to us, it is controlled by >other SDOs (which are in turn driven by the markets). > >Secondly, in relation to H.264 constrained baseline, that was created >using constraint bits, a concept that already is part of the >specification, it might be defined as the intersection of two profiles, >but the signalling is done according to one profile with a specific bit >set. Just like the HEVC Range Extension profiles. > >[YK]: Why the signalling is different? Herein you also use a profile-id >value with a specific bit set. > >However, to me it appears that when one selected the structure for HEVC >Range Extensions one forgot about the profile-compatibility-indicator >as it is not possible to signal compatibility across the main >directions in the range extension profiles. The main directions are >within themselves nicely onion shaped, but the compatibility between >them does not appear to have been well considered. > >[YK]: I was not involved in the definition of the structure for HEVC >Range Extensions - so no comment here. > >> >> - Application standards organizations, e.g. 3GPP, may require >> "sub-profile" capability for decoders. Again, AVC Constrained >> Baseline profile is an example - Magnus you should know this much >> better than many others. > >Yes, however I think it is usually bad for interoperability. And HEVC >does not appear to be in the same position that H.264 was when it was >just finished. Thus, I expect the issues are being different. > >[YK]: True - but on the other hand, that was driven by the market too, >and they wanted that for interoperability for that particular capability. >Here the issue is not about what was defined already in HEVC, but what >could be done in the future. When RFC 3984 was finalized, the >Constrained Baseline profile was not available yet. So, right now, the >situation is the same. Unless we can surely know similar things won't >happen, we should follow the approach in RFC 3984, i.e. to allow for >such intersection of two more profiles. Nobody can be sure right now >for what could happen in the future, at least for this issue. > >> >> Thus, when defining the HEVC RTP payload here, I don't think we can >> ignore the above. Rather, we must go into the direction of >> "sub-profile". > >I understand your arguments. What is required is highly dependent on >what will be done with future profiling of HEVC. I see enabling the >possibility to intersect any choice of profiles do create an potential >for fracturing the market and reducing the interoperability of HEVC. > >[YK]: Again, agree in general, but again that is not controlled by us. > >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 --_000_634D3B5D82E3214DA9B6A36D5F50DB23220112ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Ye= -Kui, Stefan, all,

&n= bsp;

Let me = express my opinion on this topic (since you explicitly asked for more opini= ons). I do represent the same company as Magnus, but (in contrast to Magnus= ) I was also part of the discussions on how to define the profiles in HEVC version 1. I share Magnus' view that it= would be very unfortunate if the payload format allows for definitions of = sub-profiles using profile-compatibility-indicator. The purpose of the prof= ile_compatibility_flags is very clear in the contribution that proposed them, JCTVC-I0499 (<= span style=3D"color:#1F497D">http://phenix.it-sudparis.eu/jct/doc_end_user/= current_document.php?id=3D5761):

"<= /span>We need a labelling scheme that:

a)      allows the committee to introduce new profiles, and= older systems be able to work out which bitstreams they can decode when th= ose new profiles are fully subsets of older existing profiles, even when th= ey do not recognize the new profile identifier;

b)      allows bitstreams which don't use all the features = of any given profile, and are as a consequence compatible with more than on= e, to be labelled with so that it's possible to deduce all the profiles tha= t the bitstream is compatible with (the ones that don't automatically follow from the nesting structure).

"<= o:p>

If ther= e is an intersection between two profiles that does make sense and is usefu= l to the industry it is reasonable to assume that ITU/ISO/IEC would define = a new profile corresponding to that intersection (just as was done with Constrained Baseline Profile in h.264). And in HEVC= , the profile_compatibility_flags provides a mechanism for introducing a ne= w profile, with a new profile_idc while still being able to indicate confor= mance to one or more of the old profiles (a mechanism that did not exist in h.264).

&n= bsp;

However= , it is worth noting that the way the Range Extension profiles have been de= fined in the second (soon to be released) version of HEVC, the functionalit= y of profile_compatibility_flag is already broken. There are 19 new profiles in there but only one profile_idc is use= d to identify them. Thus it is not possible in the same bitstream to indica= te that it conforms to two different of these 19 profiles.

&n= bsp;

Now to = connect back to the example you mentioned, Ye-Kui, on May 5: “= There can be still be a point to offer profile-compatibility-indicator in t= his case. For example, it is possible that the decoder of the offerer only supports the common tools of profiles A and B,= while it does not support either full profile A or full profile B.

1.&= nbsp;      I don’t think this is desirable.

2.&= nbsp;      Within the pro= files defined in “format range extension” (~90% of the profiles= defined so far) this is not possible.

3.&= nbsp;      When I read th= e latest HEVC payload format draft, I don’t find anything supporting = that kind of usage of profile-compatibility-i= ndicator. On the contrary:<= /span>

 

         A decoder conforming =
to a certain profile may
         be able to decode bit=
streams conforming to other profiles.
         The profile-compatibi=
lity-indicator provides exact information
         of the ability of a d=
ecoder conforming to a certain profile to
         decode bitstreams con=
forming to another profile.  More
         concretely, if the pr=
ofile compatibility flag corresponding to
         the profile a decoder=
 conforms to is set, then the decoder is
         able to decode any bi=
tstream with the flag set, irrespective
         of the profile the bi=
tstream conforms to (provided that the
         decoder supports the =
highest level of the bitstream).

 

I can see the benefit = in using the interop-constraints to express constraints that applies to wel= l-defined profiles (both from a decoder and encoder point of view). However= , using profile-compatibility-indicator to let decoders create ad-hoc on the fly “sub-profiles” of an = arbitrary number of defined profiles serves IMO no purpose and is simply a = misuse of the profile_compatibility_f= lags.

 

Best Regards Jonata= n

 

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger=
Sent: den 13 maj 2014 19:38
To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi,

I=B9m one of the co-authors.

To make one thing clear from the outset: I=B9m on= e who says that any and all options of a given payload necessarily need alw= ays to be supported by a RTP payload format.  Sometimes, it=B9s IMO co= mpletely OK to forgo the support of an odd mechanism that=B9s not required or useful for the application =B3payload o= ver the Internet using RTP=B2.

That said, the case here is different.  What= we have here is a request (by

Magnus) to narrow down the number of interoperabi= lity points negotiable using O/A negotiation, by intentionally disabling a = mechanism that was expressly included for purposes just like this.  Th= ere was considerable discussion in JCT-VC, MPEG, and VCEG about the subject.  I would say it was one of the key = drivers, but my view may be a bit one-sided.  However, it was discusse= d more than once.  The front lines were often between the hardware fol= ks (who would like to have as few interop points as possible) and the software people (who would prefer to have a finer gra= nularity, to better suit individual application needs).  The resulting= compromise necessarily made no one completely happy, but everyone could li= ve with it.

Ye-Kui is right: it=B9s not the IETF=B9s job to r= ehash these profiling architecture discussions/decisions.

Thanks for your consideration,

Stephan

 

On 13.5.14, 9:57, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

 

>Magnus,

> 

>I understand your arguments too. Your main wo= rry seems to be about the

>HEVC profiling fracturing the market and redu= cing the interoperability

>of HEVC, which I do share. However, the key p= oint here is that, that is

>not up to us, it is controlled by other organ= izations. If we go ahead

>to disallow the support of that in the HEVC p= ayload format, that does

>not mean we would successfully prevent that f= rom happening in

>MPEG/ITU-T and other application standard org= anizations - and if that

>happens, then an extension to the payload for= mat would need to be

>specified, which might introduce more IOP iss= ues even on the RTP encapsulation level for HEVC.

> 

>I fully agree that some more opinions from ot= hers would be very helpful.

> 

>Please, whoever cares about this draft and ca= res about using HEVC with

>RTP, say your opinion. We really need to have= this document finalized

>soon for HEVC deployment!!!

> 

>See some other detailed replies inline below = too.

> 

>BR, YK

> 

>-----Original Message-----

>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]

>Sent: Tuesday, May 13, 2014 7:31 AM

>To: Wang, Ye-Kui; Yago Sanchez

>Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tool= s.ietf.org

>Subject: Re: [payload] Comments on draft-ietf= -payload-rtp-h265-02

> 

>Ye-Kui and WG,

> 

>Please see inline. I think we need input from= more people into this

>question to make progress.

> 

> 

>On 2014-05-06 16:56, Wang, Ye-Kui wrote:=

>> Magnus,

>>

>> I think the only key different understan= ding between us now is the

>> following: Whether to assume that a deco= der does not fully support

>> any profile indicated by profile-id (wha= t you called "sub-profile", e.g.

>> only support the common tools of two or = more profiles).

>>

>> Once we converge here, it should be easy= to derive that text changes

>> should be made. Thus, let me focus on th= is in this email.

>>

>> Your opinion is obvious and strong - don= 't go into that direction.

>>

>> My opinion is strong too - we do need to= go into that direction,

>> because of the following reasons:

>>

>> - The ITU-T/MPEG control how to use the = bits of profile-id and

>> profile-compatibility-indicator in the v= ideo coding specifications.

>> It is simply possible that a new profile= can be defined and indicated

>> without using a new value of profile-id,= but indicated as conforming

>> to two profiles. This happened for AVC f= or the Constrained Baseline

>> profile as I explained. Also, in the rec= ently finalized HEVC Range

>> Extensions spec (see here:

>> http://phenix.int-evr= y.fr/jct/doc_end_user/documents/17_Valencia/wg11

>> /

>> JCTVC-Q1005-v4.zip),

>> 19 new profiles have been defined, indic= ated by only one value of

>> profile-id and some values of bits of th= e interop-constraints field

>> (Note, not the profile-compatibility-ind= icator field).

> 

>Yes this may happen, but jumping onto this no= w, do in fact create a

>tool where anyone can attempt to create new i= nteroperability points by

>selecting an intersection between profiles. T= hat doesn't benefit

>interoperability, it instead fractures the ma= rket and works against the

>purpose of the profiles in the first place.

> 

>[YK]: Agreed - but again that is not up to us= , it is controlled by

>other SDOs (which are in turn driven by the m= arkets).

> 

>Secondly, in relation to H.264 constrained ba= seline, that was created

>using constraint bits, a concept that already= is part of the

>specification, it might be defined as the int= ersection of two profiles,

>but the signalling is done according to one p= rofile with a specific bit

>set. Just like the HEVC Range Extension profi= les.

> 

>[YK]: Why the signalling is different? Herein= you also use a profile-id

>value with a specific bit set.

> 

>However, to me it appears that when one selec= ted the structure for HEVC

>Range Extensions one forgot about the profile= -compatibility-indicator

>as it is not possible to signal compatibility= across the main

>directions in the range extension profiles. T= he main directions are

>within themselves nicely onion shaped, but th= e compatibility between

>them does not appear to have been well consid= ered.

> 

>[YK]: I was not involved in the definition of= the structure for HEVC

>Range Extensions - so no comment here.

> 

>>

>> - Application standards organizations, e= .g. 3GPP, may require

>> "sub-profile" capability for d= ecoders. Again, AVC Constrained

>> Baseline profile is an example - Magnus = you should know this much

>> better than many others.

> 

>Yes, however I think it is usually bad for in= teroperability. And HEVC

>does not appear to be in the same position th= at H.264 was when it was

>just finished. Thus, I expect the issues are = being different.

> 

>[YK]: True - but on the other hand, that was = driven by the market too,

>and they wanted that for interoperability for= that particular capability.

>Here the issue is not about what was defined = already in HEVC, but what

>could be done in the future. When RFC 3984 wa= s finalized, the

>Constrained Baseline profile was not availabl= e yet. So, right now, the

>situation is the same. Unless we can surely k= now similar things won't

>happen, we should follow the approach in RFC = 3984, i.e. to allow for

>such intersection of two more profiles. Nobod= y can be sure right now

>for what could happen in the future, at least= for this issue.

> 

>>

>> Thus, when defining the HEVC RTP payload= here, I don't think we can

>> ignore the above. Rather, we must go int= o the direction of

>> "sub-profile".

> 

>I understand your arguments. What is required= is highly dependent on

>what will be done with future profiling of HE= VC. I see enabling the

>possibility to intersect any choice of profil= es do create an potential

>for fracturing the market and reducing the in= teroperability of HEVC.

> 

>[YK]: Again, agree in general, but again that= is not controlled by us.

> 

>Cheers

> 

>Magnus Westerlund

> 

>---------------------------------------------= -------------------------

>Services, Media and Network features, Ericsso= n Research EAB/TXM

>---------------------------------------------= -------------------------

>Ericsson AB     &nbs= p;           | Phone = ; +46 10 7148287

>F=E4r=F6gatan 6     =             | Mobile= +46 73 0949079

>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@eri= csson.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

--_000_634D3B5D82E3214DA9B6A36D5F50DB23220112ESESSMB109ericsso_-- From nobody Fri May 16 11:28: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 363FB1A02EF for ; Fri, 16 May 2014 11:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 HZkJ3f7sSEav for ; Fri, 16 May 2014 11:19:44 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214901A031B for ; Fri, 16 May 2014 11:19:44 -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=1400264377; x=1431800377; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hbzNsKO/Zp5srg1xir571VKv3Hyi5CB8uG0GC7g1kR0=; b=go88ihLLS/BwS+TmrKX2/cuf+Ad2010bOk/QiTtSwG30RYMtFTMaopsh EYu8hRPPieODVmTuYJXqRoWzXmGRWCR5wdMMr95an9zzosk/GiJgKs3EE Pwn+/nxQ58TCvp5T7Nj6hH/9UTrXakd3kGbUr3dLTVLN1bXPJGgBO2SP2 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7440"; a="35518649" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 16 May 2014 11:19:36 -0700 X-IronPort-AV: E=Sophos;i="4.97,1068,1389772800"; d="scan'208,217";a="679580791" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 May 2014 11:19:36 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.220]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0181.006; Fri, 16 May 2014 11:20:01 -0700 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , Stephan Wenger , Magnus Westerlund , "Yago Sanchez" Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplggAEi0AD//9aMYIALdneA//+t/aCAAIY3AIAELu+AgAAG2/A= Date: Fri, 16 May 2014 18:20:01 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8345294AAE@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8345294AAEnasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Z0-GWewjdPldhliF3u0DjTIsxwc Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" 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: Fri, 16 May 2014 18:19:55 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8345294AAEnasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonatan, Thanks for responding to my request for comments - I really appreciate (eve= n though you are not supporting my opinion :)). Frankly, I think the observations you pointed out below do not support the = opinion you expressed (See more detailed replies inline below.). What are being discussed here, as Stephan accurately pointed out, is whethe= r to narrow down the number of interoperability points negotiable using O/A= negotiation, by intentionally disabling a mechanism that was expressly inc= luded for purposes that might happen and that have happened. To do (the na= rrowing down) or not to do, that is the question. And the key point to dert= ermine the answer to the question is whether THAT (the intersection way of = profiling) might happen. Unless it is fairly sure that THAT won't happen, w= e ought to provide the support of THAT in the payload format. The facts that THAT did happened for H.264 and that whether it would happen= is not controlled by IETF, but by other organizations, more than one of th= em, I'd say that we are far from being fairly sure that THAT won't happen. = Again, if the narrowing is done and if THAT occurs, then an extension to th= e payload format needs to be specified to add the support of this case and = the design would be the same as what we have now, except that it introduces= new IOP issue on the payload format level (due to two incompatible version= s of the payload format), and if the narrowing is not done and if THAT does= not occur, all the hypothetical issues won't happen anyway. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Friday, May 16, 2014 2:31 AM To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 Dear Ye-Kui, Stefan, all, Let me express my opinion on this topic (since you explicitly asked for mor= e opinions). I do represent the same company as Magnus, but (in contrast to= Magnus) I was also part of the discussions on how to define the profiles i= n HEVC version 1. I share Magnus' view that it would be very unfortunate if= the payload format allows for definitions of sub-profiles using profile-co= mpatibility-indicator. The purpose of the profile_compatibility_flags is ve= ry clear in the contribution that proposed them, JCTVC-I0499 (http://phenix= .it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761): "We need a labelling scheme that: a) allows the committee to introduce new profiles, and older systems b= e able to work out which bitstreams they can decode when those new profiles= are fully subsets of older existing profiles, even when they do not recogn= ize the new profile identifier; b) allows bitstreams which don't use all the features of any given pro= file, and are as a consequence compatible with more than one, to be labelle= d with so that it's possible to deduce all the profiles that the bitstream = is compatible with (the ones that don't automatically follow from the nesti= ng structure). " [YK]: Item b above talking about exactly encoding a bitstream using an inte= rsection of multiple profiles, which is exactly the point we are taking abo= ut. If there is an intersection between two profiles that does make sense and i= s useful to the industry it is reasonable to assume that ITU/ISO/IEC would = define a new profile corresponding to that intersection (just as was done w= ith Constrained Baseline Profile in h.264). [YK]: Defining a new profile does not necessarily means using of a new valu= e of the profile-id for indicating the new profile, just as was done with t= he Constrained Baseline profile of H.264. And in HEVC, the profile_compatibility_flags provides a mechanism for intro= ducing a new profile, with a new profile_idc while still being able to indi= cate conformance to one or more of the old profiles (a mechanism that did n= ot exist in h.264). [YK]: The mechanism of profile_compatibility_flags is very similar to what = H.264 has, with the only difference been that in HEVC there are 32 of these= flags and 5-bit of profile-id, while in H.264 there are less bits of these= flags and 8 bits of profile-id. However, it is worth noting that the way the Range Extension profiles have = been defined in the second (soon to be released) version of HEVC, the funct= ionality of profile_compatibility_flag is already broken. There are 19 new = profiles in there but only one profile_idc is used to identify them. Thus i= t is not possible in the same bitstream to indicate that it conforms to two= different of these 19 profiles. [YK]: Which functionality of profile_compatibility_flag as specified in th= e HEVC spec is broken? I guess it is just the functionality of profile_comp= atibility_flag in your understanding is broken :) We should not assume anyt= hing more than said in the spec. I don't see anything written in the spec i= s broken, even though it was a little surprise to me too when seeing the de= finition of the Range Extension profiles (as I did not expect to use the in= terop-constraints bits for profile definition either). The fact that the in= terop-constraints bits have been used in profile definition proves more tha= t the way of profile signalling is not controlled by us, and we should NOT = preclude the support of such profile signalling. Fortunately, the mechanism= we currently specify in the payload draft, where interop-constraints is on= e of the configuration parameters required for symmetric use in O/A, works = with this. Now to connect back to the example you mentioned, Ye-Kui, on May 5: "There = can be still be a point to offer profile-compatibility-indicator in this ca= se. For example, it is possible that the decoder of the offerer only suppor= ts the common tools of profiles A and B, while it does not support either f= ull profile A or full profile B. 1. I don't think this is desirable. [YK]: As I said earlier in replies to Magnus, I do share the concern either= , but this is not up to us - let me repeat again. 2. Within the profiles defined in "format range extension" (~90% of t= he profiles defined so far) this is not possible. [YK]: There is no such principle or functionality that the example must be = possible for all cases. As long as it is possible for any two of the 32 fla= gs, the payload format should provide support. Otherwise, as I said earlier= , we as the payload format designers are only introducing more IOP issues i= n the future once this is done (by other organizations). 3. When I read the latest HEVC payload format draft, I don't find any= thing supporting that kind of usage of profile-compatibility-indicator. On = the contrary: A decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. The profile-compatibility-indicator provides exact information of the ability of a decoder conforming to a certain profile to decode bitstreams conforming to another profile. More concretely, if the profile compatibility flag corresponding to the profile a decoder conforms to is set, then the decoder is able to decode any bitstream with the flag set, irrespective of the profile the bitstream conforms to (provided that the decoder supports the highest level of the bitstream). [YK] Due to the newly introduced signalling of Range Extensions profiles us= ing one profile-id value in combination with interop-constraints, the above= description of profile-compatibility-indicator needs to be updated. I had = planned to do this in the next version. But again, here we need to specify = the text to align with whatever is specified in the HEVC specification. I can see the benefit in using the interop-constraints to express constrain= ts that applies to well-defined profiles (both from a decoder and encoder p= oint of view). However, using profile-compatibility-indicator to let decode= rs create ad-hoc on the fly "sub-profiles" of an arbitrary number of define= d profiles serves IMO no purpose and is simply a misuse of the profile_comp= atibility_flags. [YK] See above. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: den 13 maj 2014 19:38 To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, I=B9m one of the co-authors. To make one thing clear from the outset: I=B9m one who says that any and al= l options of a given payload necessarily need always to be supported by a R= TP payload format. Sometimes, it=B9s IMO completely OK to forgo the suppor= t of an odd mechanism that=B9s not required or useful for the application = =B3payload over the Internet using RTP=B2. That said, the case here is different. What we have here is a request (by Magnus) to narrow down the number of interoperability points negotiable usi= ng O/A negotiation, by intentionally disabling a mechanism that was express= ly included for purposes just like this. There was considerable discussion= in JCT-VC, MPEG, and VCEG about the subject. I would say it was one of th= e key drivers, but my view may be a bit one-sided. However, it was discuss= ed more than once. The front lines were often between the hardware folks (= who would like to have as few interop points as possible) and the software = people (who would prefer to have a finer granularity, to better suit indivi= dual application needs). The resulting compromise necessarily made no one = completely happy, but everyone could live with it. Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling arch= itecture discussions/decisions. Thanks for your consideration, Stephan On 13.5.14, 9:57, "Wang, Ye-Kui" > wrote: >Magnus, > >I understand your arguments too. Your main worry seems to be about the >HEVC profiling fracturing the market and reducing the interoperability >of HEVC, which I do share. However, the key point here is that, that is >not up to us, it is controlled by other organizations. If we go ahead >to disallow the support of that in the HEVC payload format, that does >not mean we would successfully prevent that from happening in >MPEG/ITU-T and other application standard organizations - and if that >happens, then an extension to the payload format would need to be >specified, which might introduce more IOP issues even on the RTP encapsula= tion level for HEVC. > >I fully agree that some more opinions from others would be very helpful. > >Please, whoever cares about this draft and cares about using HEVC with >RTP, say your opinion. We really need to have this document finalized >soon for HEVC deployment!!! > >See some other detailed replies inline below too. > >BR, YK > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, May 13, 2014 7:31 AM >To: Wang, Ye-Kui; Yago Sanchez >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265= @tools.ietf.org >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >Ye-Kui and WG, > >Please see inline. I think we need input from more people into this >question to make progress. > > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: >> Magnus, >> >> I think the only key different understanding between us now is the >> following: Whether to assume that a decoder does not fully support >> any profile indicated by profile-id (what you called "sub-profile", e.g. >> only support the common tools of two or more profiles). >> >> Once we converge here, it should be easy to derive that text changes >> should be made. Thus, let me focus on this in this email. >> >> Your opinion is obvious and strong - don't go into that direction. >> >> My opinion is strong too - we do need to go into that direction, >> because of the following reasons: >> >> - The ITU-T/MPEG control how to use the bits of profile-id and >> profile-compatibility-indicator in the video coding specifications. >> It is simply possible that a new profile can be defined and indicated >> without using a new value of profile-id, but indicated as conforming >> to two profiles. This happened for AVC for the Constrained Baseline >> profile as I explained. Also, in the recently finalized HEVC Range >> Extensions spec (see here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11 >> / >> JCTVC-Q1005-v4.zip), >> 19 new profiles have been defined, indicated by only one value of >> profile-id and some values of bits of the interop-constraints field >> (Note, not the profile-compatibility-indicator field). > >Yes this may happen, but jumping onto this now, do in fact create a >tool where anyone can attempt to create new interoperability points by >selecting an intersection between profiles. That doesn't benefit >interoperability, it instead fractures the market and works against the >purpose of the profiles in the first place. > >[YK]: Agreed - but again that is not up to us, it is controlled by >other SDOs (which are in turn driven by the markets). > >Secondly, in relation to H.264 constrained baseline, that was created >using constraint bits, a concept that already is part of the >specification, it might be defined as the intersection of two profiles, >but the signalling is done according to one profile with a specific bit >set. Just like the HEVC Range Extension profiles. > >[YK]: Why the signalling is different? Herein you also use a profile-id >value with a specific bit set. > >However, to me it appears that when one selected the structure for HEVC >Range Extensions one forgot about the profile-compatibility-indicator >as it is not possible to signal compatibility across the main >directions in the range extension profiles. The main directions are >within themselves nicely onion shaped, but the compatibility between >them does not appear to have been well considered. > >[YK]: I was not involved in the definition of the structure for HEVC >Range Extensions - so no comment here. > >> >> - Application standards organizations, e.g. 3GPP, may require >> "sub-profile" capability for decoders. Again, AVC Constrained >> Baseline profile is an example - Magnus you should know this much >> better than many others. > >Yes, however I think it is usually bad for interoperability. And HEVC >does not appear to be in the same position that H.264 was when it was >just finished. Thus, I expect the issues are being different. > >[YK]: True - but on the other hand, that was driven by the market too, >and they wanted that for interoperability for that particular capability. >Here the issue is not about what was defined already in HEVC, but what >could be done in the future. When RFC 3984 was finalized, the >Constrained Baseline profile was not available yet. So, right now, the >situation is the same. Unless we can surely know similar things won't >happen, we should follow the approach in RFC 3984, i.e. to allow for >such intersection of two more profiles. Nobody can be sure right now >for what could happen in the future, at least for this issue. > >> >> Thus, when defining the HEVC RTP payload here, I don't think we can >> ignore the above. Rather, we must go into the direction of >> "sub-profile". > >I understand your arguments. What is required is highly dependent on >what will be done with future profiling of HEVC. I see enabling the >possibility to intersect any choice of profiles do create an potential >for fracturing the market and reducing the interoperability of HEVC. > >[YK]: Again, agree in general, but again that is not controlled by us. > >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 --_000_8BA7D4CEACFFE04BA2D902BF11719A8345294AAEnasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jonatan,=

 

Thanks for responding = to my request for comments – I really appreciate (even though you are= not supporting my opinion J).

 

Frankly, I think the o= bservations you pointed out below do not support the opinion you expressed = (See more detailed replies inline below.).

 

What are being discuss= ed here, as Stephan accurately pointed out, is whether to narrow down the n= umber of interoperability points negotiable using O/A negotiation, by inten= tionally disabling a mechanism that was expressly included for purposes that might happen and that have happen= ed.  To do (the narrowing down) or not to do, that is the question. An= d the key point to dertermine the answer to the question is whether THAT (t= he intersection way of profiling) might happen. Unless it is fairly sure that THAT won’t happen, we ought to= provide the support of THAT in the payload format.

 

The facts that THAT di= d happened for H.264 and that whether it would happen is not controlled by = IETF, but by other organizations, more than one of them, I’d say that= we are far from being fairly sure that THAT won’t happen. Again, if the narrowing is done and if THAT occurs, th= en an extension to the payload format needs to be specified to add the supp= ort of this case and the design would be the same as what we have now, exce= pt that it introduces new IOP issue on the payload format level (due to two incompatible versions of the payload = format), and if the narrowing is not done and if THAT does not occur, all t= he hypothetical issues won’t happen anyway.

 

 

BR, YK

 

From: Jonatan = Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Friday, May 16, 2014 2:31 AM
To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Dear Ye= -Kui, Stefan, all,

 <= /span>

Let me = express my opinion on this topic (since you explicitly asked for more opini= ons). I do represent the same company as Magnus, but (in contrast to Magnus= ) I was also part of the discussions on how to define the profiles in HEVC version 1. I share Magnus' view that it= would be very unfortunate if the payload format allows for definitions of = sub-profiles using profile-compatibility-indicator. The purpose of the prof= ile_compatibility_flags is very clear in the contribution that proposed them, JCTVC-I0499 (<= span style=3D"color:#1F497D">http://phenix.it-sudparis.eu/jct/doc_end_user/= current_document.php?id=3D5761):

"<= /span>We need a labelling scheme that:

a)      allows the committee to introduce new profiles, and= older systems be able to work out which bitstreams they can decode when th= ose new profiles are fully subsets of older existing profiles, even when th= ey do not recognize the new profile identifier;

b)      allows bitstreams which don't use all the features = of any given profile, and are as a consequence compatible with more than on= e, to be labelled with so that it's possible to deduce all the profiles tha= t the bitstream is compatible with (the ones that don't automatically follow from the nesting structure).

"<= /span>

&n= bsp;

[YK]: I= tem b above talking about exactly encoding a bitstream using an intersectio= n of multiple profiles, which is exactly the point we are taking about.

&n= bsp;

If ther= e is an intersection between two profiles that does make sense and is usefu= l to the industry it is reasonable to assume that ITU/ISO/IEC would define = a new profile corresponding to that intersection (just as was done with Constrained Baseline Profile in h.264).

&n= bsp;

[YK]: D= efining a new profile does not necessarily means using of a new value of th= e profile-id for indicating the new profile, just as was done with the Cons= trained Baseline profile of H.264.

&n= bsp;

And in = HEVC, the profile_compatibility_flags provides a mechanism for introducing = a new profile, with a new profile_idc while still being able to indicate co= nformance to one or more of the old profiles (a mechanism that did not exist in h.264).

 

[YK]: T= he mechanism of profile_compatibility_flags is very similar to what H.264 h= as, with the only difference been that in HEVC there are 32 of these flags = and 5-bit of profile-id, while in H.264 there are less bits of these flags and 8 bits of profile-id.

 <= /span>

However= , it is worth noting that the way the Range Extension profiles have been de= fined in the second (soon to be released) version of HEVC, the functionalit= y of profile_compatibility_flag is already broken. There are 19 new profiles in there but only one profile_idc is use= d to identify them. Thus it is not possible in the same bitstream to indica= te that it conforms to two different of these 19 profiles.

 

[YK]: Which functional= ity of  profile_compatibility_flag as specified in the HEVC spec is br= oken? I guess it is just the functionality of profile_compatibility_flag in= your understanding is broken J We should not assume anything more than said in the = spec. I don’t see anything written in the spec is broken, even though= it was a little surprise to me too when seeing the definition of the Range Extension profiles (as I did not expect to use= the interop-constraints bits for profile definition either). The fact that= the interop-constraints bits have been used in profile definition proves m= ore that the way of profile signalling is not controlled by us, and we should NOT preclude the support of such pr= ofile signalling. Fortunately, the mechanism we currently specify in the pa= yload draft, where interop-constraints is one of the configuration paramete= rs required for symmetric use in O/A, works with this.

 <= /span>

Now to = connect back to the example you mentioned, Ye-Kui, on May 5: “= There can be still be a point to offer profile-compatibility-indicator in t= his case. For example, it is possible that the decoder of the offerer only supports the common tools of profiles A and B,= while it does not support either full profile A or full profile B.

1.     &= nbsp; I don&= #8217;t think this is desirable.

[YK]: As I said earlie= r in replies to Magnus, I do share the concern either, but this is not up t= o us – let me repeat again.=

 

2.     &= nbsp; Within the profiles d= efined in “format range extension” (~90% of the profiles define= d so far) this is not possible.

[YK]: There is no such= principle or functionality that the example must be possible for all cases= . As long as it is possible for any two of the 32 flags, the payload format= should provide support. Otherwise, as I said earlier, we as the payload format designers are only introducing= more IOP issues in the future once this is done (by other organizations).<= o:p>

 

3.     &= nbsp; When I read the lates= t HEVC payload format draft, I don’t find anything supporting that ki= nd of usage of profile-compatibility-i= ndicator. On the contrary:=

 

         A decoder conforming =
to a certain profile may
         be able to decode bit=
streams conforming to other profiles.
         The profile-compatibi=
lity-indicator provides exact information
         of the ability of a d=
ecoder conforming to a certain profile to
         decode bitstreams con=
forming to another profile.  More
         concretely, if the pr=
ofile compatibility flag corresponding to
         the profile a decoder=
 conforms to is set, then the decoder is
         able to decode any bi=
tstream with the flag set, irrespective
         of the profile the bi=
tstream conforms to (provided that the
         decoder supports the =
highest level of the bitstream).

 

[YK] Due to the newly = introduced signalling of Range Extensions profiles using one profile-id val= ue in combination with interop-constraints, the above description of profil= e-compatibility-indicator needs to be updated. I had planned to do this in the next version. But again, here we = need to specify the text to align with whatever is specified in the HEVC sp= ecification.

 

I can see the benefit = in using the interop-constraints to express constraints that applies to wel= l-defined profiles (both from a decoder and encoder point of view). However= , using profile-compatibility-indicator to let decoders create ad-hoc on the fly “sub-profiles” of an = arbitrary number of defined profiles serves IMO no purpose and is simply a = misuse of the profile_compatibility_f= lags.

 

[YK] See above. <= /o:p>

 

Best Regards Jonata= n

 

-----Original Message-----
From: payload [mailto:payload-b= ounces@ietf.org] On Behalf Of Stephan Wenger
Sent: den 13 maj 2014 19:38
To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft-iet= f-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi,

I=B9m one of the co-authors.

To make one thing clear from the outset: I=B9m on= e who says that any and all options of a given payload necessarily need alw= ays to be supported by a RTP payload format.  Sometimes, it=B9s IMO co= mpletely OK to forgo the support of an odd mechanism that=B9s not required or useful for the application =B3payload o= ver the Internet using RTP=B2.

That said, the case here is different.  What= we have here is a request (by

Magnus) to narrow down the number of interoperabi= lity points negotiable using O/A negotiation, by intentionally disabling a = mechanism that was expressly included for purposes just like this.  Th= ere was considerable discussion in JCT-VC, MPEG, and VCEG about the subject.  I would say it was one of the key = drivers, but my view may be a bit one-sided.  However, it was discusse= d more than once.  The front lines were often between the hardware fol= ks (who would like to have as few interop points as possible) and the software people (who would prefer to have a finer gra= nularity, to better suit individual application needs).  The resulting= compromise necessarily made no one completely happy, but everyone could li= ve with it.

Ye-Kui is right: it=B9s not the IETF=B9s job to r= ehash these profiling architecture discussions/decisions.

Thanks for your consideration,

Stephan

 

On 13.5.14, 9:57, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

 

>Magnus,

> 

>I understand your arguments too. Your main wo= rry seems to be about the

>HEVC profiling fracturing the market and redu= cing the interoperability

>of HEVC, which I do share. However, the key p= oint here is that, that is

>not up to us, it is controlled by other organ= izations. If we go ahead

>to disallow the support of that in the HEVC p= ayload format, that does

>not mean we would successfully prevent that f= rom happening in

>MPEG/ITU-T and other application standard org= anizations - and if that

>happens, then an extension to the payload for= mat would need to be

>specified, which might introduce more IOP iss= ues even on the RTP encapsulation level for HEVC.

> 

>I fully agree that some more opinions from ot= hers would be very helpful.

> 

>Please, whoever cares about this draft and ca= res about using HEVC with

>RTP, say your opinion. We really need to have= this document finalized

>soon for HEVC deployment!!!

> 

>See some other detailed replies inline below = too.

> 

>BR, YK

> 

>-----Original Message-----

>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]

>Sent: Tuesday, May 13, 2014 7:31 AM

>To: Wang, Ye-Kui; Yago Sanchez

>Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tool= s.ietf.org

>Subject: Re: [payload] Comments on draft-ietf= -payload-rtp-h265-02

> 

>Ye-Kui and WG,

> 

>Please see inline. I think we need input from= more people into this

>question to make progress.

> 

> 

>On 2014-05-06 16:56, Wang, Ye-Kui wrote:=

>> Magnus,

>>

>> I think the only key different understan= ding between us now is the

>> following: Whether to assume that a deco= der does not fully support

>> any profile indicated by profile-id (wha= t you called "sub-profile", e.g.

>> only support the common tools of two or = more profiles).

>>

>> Once we converge here, it should be easy= to derive that text changes

>> should be made. Thus, let me focus on th= is in this email.

>>

>> Your opinion is obvious and strong - don= 't go into that direction.

>>

>> My opinion is strong too - we do need to= go into that direction,

>> because of the following reasons:

>>

>> - The ITU-T/MPEG control how to use the = bits of profile-id and

>> profile-compatibility-indicator in the v= ideo coding specifications.

>> It is simply possible that a new profile= can be defined and indicated

>> without using a new value of profile-id,= but indicated as conforming

>> to two profiles. This happened for AVC f= or the Constrained Baseline

>> profile as I explained. Also, in the rec= ently finalized HEVC Range

>> Extensions spec (see here:

>> http://phenix.int-evr= y.fr/jct/doc_end_user/documents/17_Valencia/wg11

>> /

>> JCTVC-Q1005-v4.zip),

>> 19 new profiles have been defined, indic= ated by only one value of

>> profile-id and some values of bits of th= e interop-constraints field

>> (Note, not the profile-compatibility-ind= icator field).

> 

>Yes this may happen, but jumping onto this no= w, do in fact create a

>tool where anyone can attempt to create new i= nteroperability points by

>selecting an intersection between profiles. T= hat doesn't benefit

>interoperability, it instead fractures the ma= rket and works against the

>purpose of the profiles in the first place.

> 

>[YK]: Agreed - but again that is not up to us= , it is controlled by

>other SDOs (which are in turn driven by the m= arkets).

> 

>Secondly, in relation to H.264 constrained ba= seline, that was created

>using constraint bits, a concept that already= is part of the

>specification, it might be defined as the int= ersection of two profiles,

>but the signalling is done according to one p= rofile with a specific bit

>set. Just like the HEVC Range Extension profi= les.

> 

>[YK]: Why the signalling is different? Herein= you also use a profile-id

>value with a specific bit set.

> 

>However, to me it appears that when one selec= ted the structure for HEVC

>Range Extensions one forgot about the profile= -compatibility-indicator

>as it is not possible to signal compatibility= across the main

>directions in the range extension profiles. T= he main directions are

>within themselves nicely onion shaped, but th= e compatibility between

>them does not appear to have been well consid= ered.

> 

>[YK]: I was not involved in the definition of= the structure for HEVC

>Range Extensions - so no comment here.

> 

>>

>> - Application standards organizations, e= .g. 3GPP, may require

>> "sub-profile" capability for d= ecoders. Again, AVC Constrained

>> Baseline profile is an example - Magnus = you should know this much

>> better than many others.

> 

>Yes, however I think it is usually bad for in= teroperability. And HEVC

>does not appear to be in the same position th= at H.264 was when it was

>just finished. Thus, I expect the issues are = being different.

> 

>[YK]: True - but on the other hand, that was = driven by the market too,

>and they wanted that for interoperability for= that particular capability.

>Here the issue is not about what was defined = already in HEVC, but what

>could be done in the future. When RFC 3984 wa= s finalized, the

>Constrained Baseline profile was not availabl= e yet. So, right now, the

>situation is the same. Unless we can surely k= now similar things won't

>happen, we should follow the approach in RFC = 3984, i.e. to allow for

>such intersection of two more profiles. Nobod= y can be sure right now

>for what could happen in the future, at least= for this issue.

> 

>>

>> Thus, when defining the HEVC RTP payload= here, I don't think we can

>> ignore the above. Rather, we must go int= o the direction of

>> "sub-profile".

> 

>I understand your arguments. What is required= is highly dependent on

>what will be done with future profiling of HE= VC. I see enabling the

>possibility to intersect any choice of profil= es do create an potential

>for fracturing the market and reducing the in= teroperability of HEVC.

> 

>[YK]: Again, agree in general, but again that= is not controlled by us.

> 

>Cheers

> 

>Magnus Westerlund

> 

>---------------------------------------------= -------------------------

>Services, Media and Network features, Ericsso= n Research EAB/TXM

>---------------------------------------------= -------------------------

>Ericsson AB     &nbs= p;           | Phone = ; +46 10 7148287

>F=E4r=F6gatan 6     =             | Mobile= +46 73 0949079

>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@eri= csson.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

--_000_8BA7D4CEACFFE04BA2D902BF11719A8345294AAEnasanexd02fnaqu_-- From nobody Fri May 16 16:09:30 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 490741A01A6 for ; Fri, 16 May 2014 16:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 cEY8GmYTjTqh for ; Fri, 16 May 2014 16:09:20 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71AA1A0126 for ; Fri, 16 May 2014 16:09:20 -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=1400281753; x=1431817753; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W/4XzLrRxDIZ0jurjCWZCJYhu5Qu5CXwzF+Dk0MuhNU=; b=PSuqdmcczgdozzPALY5IMyk8HDSjdcuoT5zrtbSH0uIAI4Am0A5PtUNx +Nb87t8LzfpK4cuxEGf9oN0Q3fUUsjJq4mUuhGXTO9SkUL37+1jpUhy3n 6dBJwRhs3/fgGfZbdC438h9nCFBKZifkSzLVDy8K6o901E1yKtTDUIW9L s=; X-IronPort-AV: E=McAfee;i="5600,1067,7440"; a="63524883" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 16 May 2014 16:09:12 -0700 X-IronPort-AV: E=Sophos;i="4.97,1070,1389772800"; d="scan'208,217";a="29689085" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 May 2014 16:09:12 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.220]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.03.0181.006; Fri, 16 May 2014 16:09:38 -0700 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqbLyXIk9FYUOA5cqUKWqAxJsqbPSAgBXkUACAA4F9oA== Date: Fri, 16 May 2014 23:09:37 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@nasanexd02f.na.qualcomm.com> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> 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: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A834529B2D3nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/JvERXSP7pgN3ZrMsa33zbMdV-l4 Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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: Fri, 16 May 2014 23:09:29 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A834529B2D3nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonatan, Thanks for reviewing the new version. Please see my replies inline below, i= ncluding some comments on the two newly proposed features related to RPSI. = For these two features, let's first discuss whether to have them in this pa= yload format document before going into the details in text proposed in ano= ther email. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Wednesday, May 14, 2014 1:58 AM To: Wang, Ye-Kui; payload@ietf.org Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' [YK]: Thanks! To be done in the next version. B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. [YK]: Thanks! To be done in the next version. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? [YK]: The intended use of the SLI message as specified is to indicate the l= oss of CTBs regardless of whether and how slices are in use and whether and= how tiles are in use. The semantics of the "Number" field is clear to me t= oo - why it is not clear? Note that the semantics of slice_segment_address = in the HEVC spec itself is also in CTB raster scan order, regardless of whe= ther and how tiles are in use. Personally I'd prefer to keep the semantics = of SLI to be generic, and also aligned with the semantics of slice_segment_= address in the HEVC spec. D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? [YK]: To me this change would make the semantics a lot less clear and the m= essage less useful. Also, each dependent slice segment has slice_segment_ad= dress signalled too, while FUs are supposed to be assembled before sending = to the decoder - thus from the decoder point of view FUs do not need to be = considered. E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsb consists of = fewer than 6 bits. [YK]: Good point. To be done in the next version unless the discussion lead= s into a different conclusion. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' [YK]: To be done in the next version. Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. [YK]: A few points to discuss. G.1: Is it backward compatible to RFC 4585 t= o use one RPSI message to convey more than one reference picture? Would it = be better to define a new message for this purpose if it is deemed useful? = G.2: The concept applies to any video codec that supports multiple referenc= e pictures, is not specific to HEVC, thus would it be better if this is dis= cussed as a generic mechanism, similarly as the SPLI message included in dr= aft-ietf-payload-rtp-h265-01 but dropped later for the very reason? G.3: On= the usefulness of this functionality seems to be unclear to me either. If = the last correct picture before an error occurs is known, it is also known = that the reference pictures of the last correct pictures are correct, thus = the encoder can anyway choose to use one or more of these pictures, when av= ailable, for encoding the next picture. Thus, it might be sufficient just t= o slightly change the semantics of the RPLI message, to say that the encode= r can choose to use one or more of the identified picture and its reference= pictures for encoding the next picture. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be correct 2: The MD5 of the reference picture is incorrect (i.e. do NOT us= e for reference) 3: The MD5 is included in the RPSI message (directly following t= he PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. [YK]: Firstly, in my understanding, the decoder picture hash SEI message is= very useful for debugging in development of encoder and decoder implementa= tions, as used by the JCT-VC for the development of the HEVC reference soft= ware, and it is intended for use with that purpose. Using of it for error r= esilience in communications is an overkill to me. For example, you would ne= ed 48 bytes to signal the MD5 hash for each picture. Secondly, it is archit= ecturally incorrect to couple this with the RPSI feedback message, as the p= icture identified is supposed to be correctly decoded by the decoder and th= e purpose of the message is to request the encoder to use that picture for = encoding of the next picture, thus why would you even indicate a picture th= at is incorrect using an RPSI feedback message? Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 Gro= up of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_8BA7D4CEACFFE04BA2D902BF11719A834529B2D3nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonatan,

 <= /p>

Thanks for reviewing the = new version. Please see my replies inline below, including some comments on= the two newly proposed features related to RPSI. For these two features, let’s first discuss whether to have them in this paylo= ad format document before going into the details in text proposed in anothe= r email.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan = Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Wednesday, May 14, 2014 1:58 AM
To: Wang, Ye-Kui; payload@ietf.org
Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Dear Ye-Kui, editors, all,

Thanks for improving the draft and maki= ng the new version available. I read through the new section 8 in the lates= t draft, in which more feedback features have been added (which I think is very good). I have some minor comments and then some sug= gestions for improving the RPSI signalling. Compared to earlier standards, = HEVC contains a new very useful SEI message that can be used to check integ= rity and correctness of decoded pictures and thereby detect errors that are not necessarily due to packet = losses: Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also in t= he RTP payload format for HEVC in order to make implementations even more robust.

First some minor comments:

In 8.1:

A. Remove one instance of 'the loss of' in the sentence: ' As specified in RFC 4585 section 6.3.1, the reception of a picture loss in= dication by a media sender indicates the loss of "the loss of an undef= ined amount of coded video data belonging to one or more pictures.".'

 <= /p>

[YK]: Thanks! To be done = in the next version.

B. The 'BE' in 'SHOULD BE' should not b= e using CAPITAL LETTERS.

[YK]: Thanks! To be done = in the next version.

 <= /p>

In 8.2:

C. Regarding 'the loss of a number of = Coded Tree Blocks (CTBs) in CTB raster scan order of a picture.'. When tiles are used, the loss of a slice does typically not result in lost= CTBs in raster scan order of the picture. The text does not describe how t= o calculate the "Number" field for this case. Wouldn't it be bett= er to use 'tile scan' in order to correctly identify what part of the = picture was lost?

 <= /p>

[YK]: The intended use of= the SLI message as specified is to indicate the loss of CTBs regardless of= whether and how slices are in use and whether and how tiles are in use. The semantics of the “Number” field is clear to me= too – why it is not clear? Note that the semantics of slice_segment_= address in the HEVC spec itself is also in CTB raster scan order, regardles= s of whether and how tiles are in use. Personally I’d prefer to keep the semantics of SLI to be generic, and also alig= ned with the semantics of slice_segment_address in the HEVC spec.

D. Regarding 'the subfield "First= " MUST be set to the CTB address of the first lost CTB'. Wouldn't it be better to require "First" to= be set to a number that is lower than or equal to the CTB address of the f= irst lost CTB, since it might be difficult to deduce the exact CTB address of t= he first lost CTB in the case of loss of  dependent slices and/or frag= mentation units?

 <= /p>

[YK]: To me this change w= ould make the semantics a lot less clear and the message less useful. Also,= each dependent slice segment has slice_segment_address signalled too, while FUs are supposed to be assembled before sending to th= e decoder – thus from the decoder point of view FUs do not need to be= considered.

E. Regarding 'The subfield "Pictu= reID" MUST  be  set  to  the  6  least s= ignificant  bits  of  a  binary representation  of  the  value  of slice_pic_order_cnt_lsb  of  t= he picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of  slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_lsb consists of  fewer than 6= bits.

[YK]: Good point. To be d= one in the next version unless the discussion leads into a different conclu= sion.

 <= /p>

F. Regarding the sentence: 'In many ca= ses, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncor= rupted regions of the picture through motion compensation, and reference pi= cture selection can also be used to "clean up" the corrupted pict= ure, which is usually more efficient and less likely to generate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: = ''

[YK]: To be done in the n= ext version.

 <= /p>

Regarding RPSI (section 8.3) I would li= ke to propose the following changes:

G. Add the possibility to include more = than one reference picture in the RPSI message so that the encoder can sele= ct to use one or more of the pictures included in RPSI message. Using multiple pictures for reference is a key feature in HEVC which subst= antially improves coding efficiency. In the case where multiple earlier pic= tures are available for reference it is beneficial to let the encoder decid= e which one(s) to use for reference instead of relying on the decoder to make that selection.

[YK]: A few points to dis= cuss. G.1: Is it backward compatible to RFC 4585 to use one RPSI message to= convey more than one reference picture? Would it be better to define a new message for this purpose if it is deemed useful? G.2: The = concept applies to any video codec that supports multiple reference picture= s, is not specific to HEVC, thus would it be better if this is discussed as= a generic mechanism, similarly as the SPLI message included in draft-ietf-payload-rtp-h265-01 but dropped= later for the very reason? G.3: On the usefulness of this functionality se= ems to be unclear to me either. If the last correct picture before an error= occurs is known, it is also known that the reference pictures of the last correct pictures are correct, thus= the encoder can anyway choose to use one or more of these pictures, when a= vailable, for encoding the next picture. Thus, it might be sufficient just = to slightly change the semantics of the RPLI message, to say that the encoder can choose to use one or more= of the identified picture and its reference pictures for encoding the next= picture.

 <= /p>

H. Using the 2 currently unused bits in= the 'Native RPSI bit string defined per codec' for adding the possibility of including information regarding the MD5 in t= he RPSI message as follows:

0:      &= nbsp;     No information regarding the MD5 available 1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)

The last option can be used when the en= coder does not include MD5s in-band but wants to check the MD5 before using= a selected picture for reference. Typically this will be more bit-efficient than including decoded picture hash SEI messages in-ban= d.

In my opinion it would be very useful t= o be able to include information regarding the correctness of the decoded p= ictures, e.g. to detect incompatibility issues and bit errors. I will send a suggestion for the text changes needed to enable this, hopef= ully later today.

 <= /p>

[YK]: Firstly, in my unde= rstanding, the decoder picture hash SEI message is very useful for debuggin= g in development of encoder and decoder implementations, as used by the JCT-VC for the development of the HEVC reference software, = and it is intended for use with that purpose. Using of it for error resilie= nce in communications is an overkill to me. For example, you would need 48 = bytes to signal the MD5 hash for each picture. Secondly, it is architecturally incorrect to couple this wit= h the RPSI feedback message, as the picture identified is supposed to be co= rrectly decoded by the decoder and the purpose of the message is to request= the encoder to use that picture for encoding of the next picture, thus why would you even indicate a pictu= re that is incorrect using an RPSI feedback message?

 <= /p>

Best Regards Jonatan<= /p>

-----Original Message-----
From: payload [mailto:payload-b= ounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt<= /o:p>

 

Dear All,

 

Compare to -02, we have addressed most = of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Berna= rd, ..., as well as the following changes:

- Addition of sprop-sei, as suggested b= y Stephan on Apr. 23 to the reflector, agreed by most of the authors, no ob= jection from anyone.

- Addition of an informative, brief des= cription of the display orientation SEI message, which is among one of thos= e new SEI messages that have some systems usage.

- Addition of a definition of NAL-unit-= like structure. The term was used but not defined earlier.

- Addition of descriptions for use of t= he PLI and SLI messages (specified in RFC 4585) and the FIR message (specif= ied in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed= during the presentation at the previous IETF meeting

 

Remaining open issues:

- On profile-compatibility-indicator an= d interop-constraints (raised by Magnus, being discussed among Magnus, myse= lf and Yago, no conclusion yet)

- On recv-sub-layer-id and using of spr= op-vps for session negotiation (raised by Magnus, still being discussed amo= ng the authors and Magnus)

- On source-specific sprop parameter se= ts (raised by Magnus, still being discussed among the authors and Jonathan = for exact text changes)

- On using a different parameter catego= ry for level-id (raised by Magnus, discussed between Magnus and myself, no = conclusion yet)

- I just noticed that the definition of= "packet stream" itself needs to be changed back to "RTP str= eam"

 

We will try to address the above open i= ssues as soon as possible. At the same time, further review and comments ar= e welcome.

 

BR, YK

 

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

Sent: Wednesday, April 30, 2014 10:34 A= M

Cc: payload@ietf.org<= /p>

Subject: [payload] I-D Action: draft-ie= tf-payload-rtp-h265-03.txt

 

 

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.

 

      &nb= sp; Title           : RTP= Payload Format for High Efficiency Video Coding

      &nb= sp; Authors         : Ye-Kui Wang

      &nb= sp;            =        Yago Sanchez

      &nb= sp;            =        Thomas Schierl

      &nb= sp;            =        Stephan Wenger

      &nb= sp;            =        Miska M. Hannuksela<= /p>

      &nb= sp; Filename        : draft-ietf-payload= -rtp-h265-03.txt

      &nb= sp; Pages           : 92<= o:p>

      &nb= sp; Date            = : 2014-04-30

 

Abstract:

   This memo describes an RTP= payload format for the video coding

   standard ITU-T Recommendat= ion H.265 and ISO/IEC International

   Standard 23008-2, both als= o known as High Efficiency Video Coding

   (HEVC) [HEVC] and develope= d by the Joint Collaborative Team on Video

   Coding (JCT-VC).  The= RTP payload format allows for packetization of

   one or more Network Abstra= ction Layer (NAL) units in each RTP packet

   payload, as well as fragme= ntation of a NAL unit into multiple RTP

   packets.  Furthermore= , it supports transmission of an HEVC bitstream

   over a single as well as m= ultiple RTP streams.  The payload format

   has wide applicability in = videoconferencing, Internet video

   streaming, and high bit-ra= te entertainment-quality video, among

   others.<= /p>

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

payload mailing list<= /p>

 

_______________________________________= ________

payload mailing list<= /p>

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A834529B2D3nasanexd02fnaqu_-- From nobody Sat May 17 03:06:50 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 DF84E1A000D for ; Sat, 17 May 2014 03:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 qN1vNaU93SG6 for ; Sat, 17 May 2014 03:06:43 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id D98F91A000B for ; Sat, 17 May 2014 03:06:40 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Content-Type: multipart/alternative; boundary="Apple-Mail=_022C07F0-29BA-41AD-85F7-A88CEA53F003" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yago Sanchez In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8345294AAE@nasanexd02f.na.qualcomm.com> Date: Sat, 17 May 2014 12:06:28 +0200 Message-Id: <6E8F970B-DBA2-4EA8-87FF-F96D9AC2E5C3@hhi.fraunhofer.de> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109 .ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A8345294AAE@nasanexd02f.na.qualcomm.com> To: "Wang, Ye-Kui" X-Mailer: Apple Mail (2.1874) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20698.006 X-TM-AS-Result: No--21.844-11.0-31-10 X-imss-scan-details: No--21.844-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: yebcs53SkkCs7uBvvd6AmeJ28KqpjndpmdndBk1gfyVXPwnnY5XL5CWd w9Myj4excsVNLqRTQ1qV1/iPj7Iy0waXArGVAk7mp9ciXoJ/pWsRlN4UFFawbmtEzrC9eANpbsd jo1iTezLUVzrVUIa+HaQtLOkc1NHajoR5DwlwBUfKl4yJoI+fG/Lk3+lOElCDzb25lDDElxeSYh PCEVba/AhziKiNgUAxrP8eSd+YY5DCk1vfIz8MDatWSWds/km2RvyVHewb0kIhvFjBsLEZNEdQi oyKKnefwuvyS4oaU7kQoXJc60V7Q9wrRLDk2cbiaUe/i9AephMxmbT6wQT2a23D6f6IpbLI48fE 6PIFskCriRYr2MPBlGsVIHEKo/MpFDf/GgM78iWsDodw9yUkxhGRqkLTNCogBoA1fKObuhMF3Vh 9D4v36fwgIEyaDr8N52qg0td9rOIVLX6oLGmWi6OuVibdZNTvAHN/Ezu9EnFH7rX2ckGqtcS4G+ 2ecnOxP68XQYAPciq1JbtVeGZHGHNLw2+e/n0l7TLIvnWov9EhauGyjTkf9VpbYq2f4jz+VZJS7 FUPq57YrzMcor2ex+ev2HnLAk3RE2ZRbV2rc3HDg+U1NSmcuc9NijU3CR/LWabPstVV86kL27i3 iyIp1z4qJoE02whudVYa3yVSesS7bbuKEQVOoQ/6H9abDIMR1KoSW5Ji1XvOxDyJFXIPjus2fXz lju20CpXs9czk3J5RiDm0M6cHX2WmmXDOLKejbQ9aoPSmWJFBrawMcuRDTiBs0OU9P6tbzKhI/P M+wq+EhIzACHRx/gN1IPR5ldye4T9E4o5DZ/6eAiCmPx4NwGmRqNBHmBveeVl+oyOKCVfUZxEAl FPo8xec2mundr02q9eNdf4oQWn7DLJ4UjWfKFEj2daFwhdAQrxo+/YbdbY= X-IMSS-DKIM-White-List: No X-alterMIME: Yes Archived-At: http://mailarchive.ietf.org/arch/msg/payload/XAx6Bm8T2A-I1VLQCvkuqtCJNUg Cc: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" 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: Sat, 17 May 2014 10:06:49 -0000 --Apple-Mail=_022C07F0-29BA-41AD-85F7-A88CEA53F003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Ye-Kui, Jonatan,all, Just to make clear my opinion on this topic, I am here with Ye-Kui and = Stephan as already expressed previously in this thread. Desirable or = not, profile_compatibility_indicator allows for indicating intersection = of profiles as expressed in the item b) in the contribution mentioned in = the email below. Whether the intersections will get a profile_idc or not = cannot be known beforehand and might not since we have = profile_compatibility_flag for that purpose. Said that still I think the = argument here is that if HEVC allows for it we should support it in the = payload format. Best regards, Yago On 16 May 2014, at 20:20, Wang, Ye-Kui wrote: > Hi Jonatan, > =20 > Thanks for responding to my request for comments =96 I really = appreciate (even though you are not supporting my opinion J). > =20 > Frankly, I think the observations you pointed out below do not support = the opinion you expressed (See more detailed replies inline below.). > =20 > What are being discussed here, as Stephan accurately pointed out, is = whether to narrow down the number of interoperability points negotiable = using O/A negotiation, by intentionally disabling a mechanism that was = expressly included for purposes that might happen and that have = happened. To do (the narrowing down) or not to do, that is the = question. And the key point to dertermine the answer to the question is = whether THAT (the intersection way of profiling) might happen. Unless it = is fairly sure that THAT won=92t happen, we ought to provide the support = of THAT in the payload format. > =20 > The facts that THAT did happened for H.264 and that whether it would = happen is not controlled by IETF, but by other organizations, more than = one of them, I=92d say that we are far from being fairly sure that THAT = won=92t happen. Again, if the narrowing is done and if THAT occurs, then = an extension to the payload format needs to be specified to add the = support of this case and the design would be the same as what we have = now, except that it introduces new IOP issue on the payload format level = (due to two incompatible versions of the payload format), and if the = narrowing is not done and if THAT does not occur, all the hypothetical = issues won=92t happen anyway. > =20 > =20 > BR, YK > =20 > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Friday, May 16, 2014 2:31 AM > To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez > Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org > Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 > =20 > Dear Ye-Kui, Stefan, all, > =20 > Let me express my opinion on this topic (since you explicitly asked = for more opinions). I do represent the same company as Magnus, but (in = contrast to Magnus) I was also part of the discussions on how to define = the profiles in HEVC version 1. I share Magnus' view that it would be = very unfortunate if the payload format allows for definitions of = sub-profiles using profile-compatibility-indicator. The purpose of the = profile_compatibility_flags is very clear in the contribution that = proposed them, JCTVC-I0499 = (http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5= 761): > "We need a labelling scheme that: > a) allows the committee to introduce new profiles, and older = systems be able to work out which bitstreams they can decode when those = new profiles are fully subsets of older existing profiles, even when = they do not recognize the new profile identifier; > b) allows bitstreams which don't use all the features of any = given profile, and are as a consequence compatible with more than one, = to be labelled with so that it's possible to deduce all the profiles = that the bitstream is compatible with (the ones that don't automatically = follow from the nesting structure). > " > =20 > [YK]: Item b above talking about exactly encoding a bitstream using an = intersection of multiple profiles, which is exactly the point we are = taking about. > =20 > If there is an intersection between two profiles that does make sense = and is useful to the industry it is reasonable to assume that = ITU/ISO/IEC would define a new profile corresponding to that = intersection (just as was done with Constrained Baseline Profile in = h.264). > =20 > [YK]: Defining a new profile does not necessarily means using of a new = value of the profile-id for indicating the new profile, just as was done = with the Constrained Baseline profile of H.264. > =20 > And in HEVC, the profile_compatibility_flags provides a mechanism for = introducing a new profile, with a new profile_idc while still being able = to indicate conformance to one or more of the old profiles (a mechanism = that did not exist in h.264). > =20 > [YK]: The mechanism of profile_compatibility_flags is very similar to = what H.264 has, with the only difference been that in HEVC there are 32 = of these flags and 5-bit of profile-id, while in H.264 there are less = bits of these flags and 8 bits of profile-id. > =20 > However, it is worth noting that the way the Range Extension profiles = have been defined in the second (soon to be released) version of HEVC, = the functionality of profile_compatibility_flag is already broken. There = are 19 new profiles in there but only one profile_idc is used to = identify them. Thus it is not possible in the same bitstream to indicate = that it conforms to two different of these 19 profiles. > =20 > [YK]: Which functionality of profile_compatibility_flag as specified = in the HEVC spec is broken? I guess it is just the functionality of = profile_compatibility_flag in your understanding is broken J We should = not assume anything more than said in the spec. I don=92t see anything = written in the spec is broken, even though it was a little surprise to = me too when seeing the definition of the Range Extension profiles (as I = did not expect to use the interop-constraints bits for profile = definition either). The fact that the interop-constraints bits have been = used in profile definition proves more that the way of profile = signalling is not controlled by us, and we should NOT preclude the = support of such profile signalling. Fortunately, the mechanism we = currently specify in the payload draft, where interop-constraints is one = of the configuration parameters required for symmetric use in O/A, works = with this. > =20 > Now to connect back to the example you mentioned, Ye-Kui, on May 5: = =93There can be still be a point to offer = profile-compatibility-indicator in this case. For example, it is = possible that the decoder of the offerer only supports the common tools = of profiles A and B, while it does not support either full profile A or = full profile B. > 1. I don=92t think this is desirable. > [YK]: As I said earlier in replies to Magnus, I do share the concern = either, but this is not up to us =96 let me repeat again. > =20 > 2. Within the profiles defined in =93format range extension=94 = (~90% of the profiles defined so far) this is not possible. > [YK]: There is no such principle or functionality that the example = must be possible for all cases. As long as it is possible for any two of = the 32 flags, the payload format should provide support. Otherwise, as I = said earlier, we as the payload format designers are only introducing = more IOP issues in the future once this is done (by other = organizations). > =20 > 3. When I read the latest HEVC payload format draft, I don=92t = find anything supporting that kind of usage of = profile-compatibility-indicator. On the contrary: > =20 > A decoder conforming to a certain profile may > be able to decode bitstreams conforming to other profiles. > The profile-compatibility-indicator provides exact = information > of the ability of a decoder conforming to a certain profile = to > decode bitstreams conforming to another profile. More > concretely, if the profile compatibility flag corresponding = to > the profile a decoder conforms to is set, then the decoder is > able to decode any bitstream with the flag set, irrespective > of the profile the bitstream conforms to (provided that the > decoder supports the highest level of the bitstream). > =20 > [YK] Due to the newly introduced signalling of Range Extensions = profiles using one profile-id value in combination with = interop-constraints, the above description of = profile-compatibility-indicator needs to be updated. I had planned to do = this in the next version. But again, here we need to specify the text to = align with whatever is specified in the HEVC specification. > =20 > I can see the benefit in using the interop-constraints to express = constraints that applies to well-defined profiles (both from a decoder = and encoder point of view). However, using = profile-compatibility-indicator to let decoders create ad-hoc on the fly = =93sub-profiles=94 of an arbitrary number of defined profiles serves IMO = no purpose and is simply a misuse of theprofile_compatibility_flags. > =20 > [YK] See above. > =20 > Best Regards Jonatan > =20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan = Wenger > Sent: den 13 maj 2014 19:38 > To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez > Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org > Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > =20 > Hi, > I=B9m one of the co-authors. > To make one thing clear from the outset: I=B9m one who says that any = and all options of a given payload necessarily need always to be = supported by a RTP payload format. Sometimes, it=B9s IMO completely OK = to forgo the support of an odd mechanism that=B9s not required or useful = for the application =B3payload over the Internet using RTP=B2. > That said, the case here is different. What we have here is a request = (by > Magnus) to narrow down the number of interoperability points = negotiable using O/A negotiation, by intentionally disabling a mechanism = that was expressly included for purposes just like this. There was = considerable discussion in JCT-VC, MPEG, and VCEG about the subject. I = would say it was one of the key drivers, but my view may be a bit = one-sided. However, it was discussed more than once. The front lines = were often between the hardware folks (who would like to have as few = interop points as possible) and the software people (who would prefer to = have a finer granularity, to better suit individual application needs). = The resulting compromise necessarily made no one completely happy, but = everyone could live with it. > Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling = architecture discussions/decisions. > Thanks for your consideration, > Stephan > =20 > On 13.5.14, 9:57, "Wang, Ye-Kui" wrote: > =20 > >Magnus, > >=20 > >I understand your arguments too. Your main worry seems to be about = the > >HEVC profiling fracturing the market and reducing the = interoperability > >of HEVC, which I do share. However, the key point here is that, that = is > >not up to us, it is controlled by other organizations. If we go ahead > >to disallow the support of that in the HEVC payload format, that does > >not mean we would successfully prevent that from happening in > >MPEG/ITU-T and other application standard organizations - and if that > >happens, then an extension to the payload format would need to be > >specified, which might introduce more IOP issues even on the RTP = encapsulation level for HEVC. > >=20 > >I fully agree that some more opinions from others would be very = helpful. > >=20 > >Please, whoever cares about this draft and cares about using HEVC = with > >RTP, say your opinion. We really need to have this document finalized > >soon for HEVC deployment!!! > >=20 > >See some other detailed replies inline below too. > >=20 > >BR, YK > >=20 > >-----Original Message----- > >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >Sent: Tuesday, May 13, 2014 7:31 AM > >To: Wang, Ye-Kui; Yago Sanchez > >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org > >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >=20 > >Ye-Kui and WG, > >=20 > >Please see inline. I think we need input from more people into this > >question to make progress. > >=20 > >=20 > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: > >> Magnus, > >> > >> I think the only key different understanding between us now is the > >> following: Whether to assume that a decoder does not fully support > >> any profile indicated by profile-id (what you called "sub-profile", = e.g. > >> only support the common tools of two or more profiles). > >> > >> Once we converge here, it should be easy to derive that text = changes > >> should be made. Thus, let me focus on this in this email. > >> > >> Your opinion is obvious and strong - don't go into that direction. > >> > >> My opinion is strong too - we do need to go into that direction, > >> because of the following reasons: > >> > >> - The ITU-T/MPEG control how to use the bits of profile-id and > >> profile-compatibility-indicator in the video coding specifications. > >> It is simply possible that a new profile can be defined and = indicated > >> without using a new value of profile-id, but indicated as = conforming > >> to two profiles. This happened for AVC for the Constrained Baseline > >> profile as I explained. Also, in the recently finalized HEVC Range > >> Extensions spec (see here: > >> = http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11 > >> / > >> JCTVC-Q1005-v4.zip), > >> 19 new profiles have been defined, indicated by only one value of > >> profile-id and some values of bits of the interop-constraints field > >> (Note, not the profile-compatibility-indicator field). > >=20 > >Yes this may happen, but jumping onto this now, do in fact create a > >tool where anyone can attempt to create new interoperability points = by > >selecting an intersection between profiles. That doesn't benefit > >interoperability, it instead fractures the market and works against = the > >purpose of the profiles in the first place. > >=20 > >[YK]: Agreed - but again that is not up to us, it is controlled by > >other SDOs (which are in turn driven by the markets). > >=20 > >Secondly, in relation to H.264 constrained baseline, that was created > >using constraint bits, a concept that already is part of the > >specification, it might be defined as the intersection of two = profiles, > >but the signalling is done according to one profile with a specific = bit > >set. Just like the HEVC Range Extension profiles. > >=20 > >[YK]: Why the signalling is different? Herein you also use a = profile-id > >value with a specific bit set. > >=20 > >However, to me it appears that when one selected the structure for = HEVC > >Range Extensions one forgot about the profile-compatibility-indicator > >as it is not possible to signal compatibility across the main > >directions in the range extension profiles. The main directions are > >within themselves nicely onion shaped, but the compatibility between > >them does not appear to have been well considered. > >=20 > >[YK]: I was not involved in the definition of the structure for HEVC > >Range Extensions - so no comment here. > >=20 > >> > >> - Application standards organizations, e.g. 3GPP, may require > >> "sub-profile" capability for decoders. Again, AVC Constrained > >> Baseline profile is an example - Magnus you should know this much > >> better than many others. > >=20 > >Yes, however I think it is usually bad for interoperability. And HEVC > >does not appear to be in the same position that H.264 was when it was > >just finished. Thus, I expect the issues are being different. > >=20 > >[YK]: True - but on the other hand, that was driven by the market = too, > >and they wanted that for interoperability for that particular = capability. > >Here the issue is not about what was defined already in HEVC, but = what > >could be done in the future. When RFC 3984 was finalized, the > >Constrained Baseline profile was not available yet. So, right now, = the > >situation is the same. Unless we can surely know similar things won't > >happen, we should follow the approach in RFC 3984, i.e. to allow for > >such intersection of two more profiles. Nobody can be sure right now > >for what could happen in the future, at least for this issue. > >=20 > >> > >> Thus, when defining the HEVC RTP payload here, I don't think we can > >> ignore the above. Rather, we must go into the direction of > >> "sub-profile". > >=20 > >I understand your arguments. What is required is highly dependent on > >what will be done with future profiling of HEVC. I see enabling the > >possibility to intersect any choice of profiles do create an = potential > >for fracturing the market and reducing the interoperability of HEVC. > >=20 > >[YK]: Again, agree in general, but again that is not controlled by = us. > >=20 > >Cheers > >=20 > >Magnus Westerlund > >=20 > = >---------------------------------------------------------------------- > >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 > = >---------------------------------------------------------------------- > >=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 --Apple-Mail=_022C07F0-29BA-41AD-85F7-A88CEA53F003 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Ye-Kui, Jonatan,all,

Just to make clear my opinion on = this topic, I am here with Ye-Kui and Stephan as already expressed = previously in this thread. Desirable or not, = profile_compatibility_indicator allows for indicating intersection of = profiles as expressed in the item b) in the contribution mentioned in = the email below. Whether the intersections will get a profile_idc or not = cannot be known beforehand and might not since we have = profile_compatibility_flag for that purpose. Said that still I think the = argument here is that if HEVC allows for it we should support it in the = payload format.

Best = regards,
Yago


On 16 May 2014, = at 20:20, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> = wrote:

Hi Jonatan,
 
Thanks for responding to my request for comments =96 = I really appreciate (even though you are not supporting my opinion J).
 
Frankly, I think the observations you pointed out = below do not support the opinion you expressed (See more detailed = replies inline below.).
 
What are = being discussed here, as Stephan accurately pointed out, is whether to = narrow down the number of interoperability points negotiable using O/A = negotiation, by intentionally disabling a mechanism that was expressly = included for purposes that might happen and that have happened.  To = do (the narrowing down) or not to do, that is the question. And the key = point to dertermine the answer to the question is whether THAT (the = intersection way of profiling) might happen. Unless it is fairly sure = that THAT won=92t happen, we ought to provide the support of THAT in the = payload format.
 
The facts = that THAT did happened for H.264 and that whether it would happen is not = controlled by IETF, but by other organizations, more than one of them, = I=92d say that we are far from being fairly sure that THAT won=92t = happen. Again, if the narrowing is done and if THAT occurs, then an = extension to the payload format needs to be specified to add the support = of this case and the design would be the same as what we have now, = except that it introduces new IOP issue on the payload format level (due = to two incompatible versions of the payload format), and if the = narrowing is not done and if THAT does not occur, all the hypothetical = issues won=92t happen anyway.
 
 
BR, YK
 
From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Friday, May 16, 2014 2:31 = AM
To: Stephan= Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago = Sanchez
Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: RE: [payload] Comments on = draft-ietf-payload-rtp-h265-02
 
Dear Ye-Kui, Stefan, = all,
 
Let me express my opinion on this topic (since you explicitly = asked for more opinions). I do represent the same company as Magnus, but = (in contrast to Magnus) I was also part of the discussions on how to = define the profiles in HEVC version 1. I share Magnus' view that it = would be very unfortunate if the payload format allows for definitions = of sub-profiles using profile-compatibility-indicator. The purpose of = the profile_compatibility_flags is very clear in the contribution that = proposed them, JCTVC-I0499 (http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?= id=3D5761):
"We need a = labelling scheme that:
a)      allows the = committee to introduce new profiles, and older systems be able to work = out which bitstreams they can decode when those new profiles are fully = subsets of older existing profiles, even when they do not recognize the = new profile identifier;
b)      allows = bitstreams which don't use all the features of any given profile, and = are as a consequence compatible with more than one, to be labelled with = so that it's possible to deduce all the profiles that the bitstream is = compatible with (the ones that don't automatically follow from the = nesting structure).
"
 
[YK]: Item b above talking about exactly encoding a bitstream = using an intersection of multiple profiles, which is exactly the point = we are taking about.
 
If there is an intersection between = two profiles that does make sense and is useful to the industry it is = reasonable to assume that ITU/ISO/IEC would define a new profile = corresponding to that intersection (just as was done with Constrained = Baseline Profile in h.264).
 
[YK]: Defining a new profile does not = necessarily means using of a new value of the profile-id for indicating = the new profile, just as was done with the Constrained Baseline profile = of H.264.
 
And in HEVC, the profile_compatibility_flags provides a mechanism = for introducing a new profile, with a new profile_idc while still being = able to indicate conformance to one or more of the old profiles (a = mechanism that did not exist in h.264).
 
[YK]: The mechanism of profile_compatibility_flags is very similar = to what H.264 has, with the only difference been that in HEVC there are = 32 of these flags and 5-bit of profile-id, while in H.264 there are less = bits of these flags and 8 bits of = profile-id.
 
However, it is worth = noting that the way the Range Extension profiles have been defined in = the second (soon to be released) version of HEVC, the functionality of = profile_compatibility_flag is already broken. There are 19 new profiles = in there but only one profile_idc is used to identify them. Thus it is = not possible in the same bitstream to indicate that it conforms to two = different of these 19 profiles.
 
[YK]: = Which functionality of  profile_compatibility_flag as specified in = the HEVC spec is broken? I guess it is just the functionality of = profile_compatibility_flag in your understanding is broken J We should not assume = anything more than said in the spec. I don=92t see anything written in = the spec is broken, even though it was a little surprise to me too when = seeing the definition of the Range Extension profiles (as I did not = expect to use the interop-constraints bits for profile definition = either). The fact that the interop-constraints bits have been used in = profile definition proves more that the way of profile signalling is not = controlled by us, and we should NOT preclude the support of such profile = signalling. Fortunately, the mechanism we currently specify in the = payload draft, where interop-constraints is one of the configuration = parameters required for symmetric use in O/A, works with = this.
 
Now to connect back to the example you mentioned, Ye-Kui, on May = 5: =93There can be still be a point to offer = profile-compatibility-indicator in this case. For example, it is = possible that the decoder of the offerer only supports the common tools = of profiles A and B, while it does not support either full profile A or = full profile B.
1.       I don=92t think this = is desirable.
[YK]: As I said earlier in replies to = Magnus, I do share the concern either, but this is not up to us =96 let = me repeat again.
 
2.       Within the profiles defined in = =93format range extension=94 (~90% of the profiles defined so far) this = is not possible.
[YK]: There is no such principle or = functionality that the example must be possible for all cases. As long = as it is possible for any two of the 32 flags, the payload format should = provide support. Otherwise, as I said earlier, we as the payload format = designers are only introducing more IOP issues in the future once this = is done (by other organizations).
 
3.       When I read the latest HEVC payload = format draft, I don=92t find anything supporting that kind of usage = of profile-compatibility-indicator. On the contrary:
 
         A decoder =
conforming to a certain profile may
         be able to =
decode bitstreams conforming to other profiles.
         The =
profile-compatibility-indicator provides exact =
information
         of the ability =
of a decoder conforming to a certain profile to
         decode =
bitstreams conforming to another profile.  =
More
         concretely, if =
the profile compatibility flag corresponding to
         the =
profile a decoder conforms to is set, then the decoder =
is
         able to decode =
any bitstream with the flag set, irrespective
         of the =
profile the bitstream conforms to (provided that =
the
         decoder supports =
the highest level of the bitstream).
 
[YK] Due to the newly introduced signalling of Range = Extensions profiles using one profile-id value in combination with = interop-constraints, the above description of = profile-compatibility-indicator needs to be updated. I had planned to do = this in the next version. But again, here we need to specify the text to = align with whatever is specified in the HEVC = specification.
 
I can see = the benefit in using the interop-constraints to express constraints that = applies to well-defined profiles (both from a decoder and encoder point = of view). However, using profile-compatibility-indicator to let decoders = create ad-hoc on the fly =93sub-profiles=94 of an arbitrary number of = defined profiles serves IMO no purpose and is simply a misuse of = theprofile_compatibility_flags.
 
[YK] See = above.
 
Best Regards = Jonatan
 
-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On = Behalf Of Stephan Wenger
Sent: den 13 maj 2014 19:38
To: Wang, = Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: = [payload] Comments on = draft-ietf-payload-rtp-h265-02
 
Hi,
I=B9m one of the = co-authors.
To make one thing = clear from the outset: I=B9m one who says that any and all options of a = given payload necessarily need always to be supported by a RTP payload = format.  Sometimes, it=B9s IMO completely OK to forgo the support = of an odd mechanism that=B9s not required or useful for the application = =B3payload over the Internet using RTP=B2.
That said, the case here is different.  What = we have here is a request (by
Magnus) to narrow down the number of interoperability = points negotiable using O/A negotiation, by intentionally disabling a = mechanism that was expressly included for purposes just like this.  = There was considerable discussion in JCT-VC, MPEG, and VCEG about the = subject.  I would say it was one of the key drivers, but my view = may be a bit one-sided.  However, it was discussed more than = once.  The front lines were often between the hardware folks (who = would like to have as few interop points as possible) and the software = people (who would prefer to have a finer granularity, to better suit = individual application needs).  The resulting compromise = necessarily made no one completely happy, but everyone could live with = it.
Ye-Kui is right: it=B9s not the = IETF=B9s job to rehash these profiling architecture = discussions/decisions.
Thanks for = your consideration,
Stephan
 
On = 13.5.14, 9:57, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> = wrote:
 
>Magnus,
> 
>I = understand your arguments too. Your main worry seems to be about = the
>HEVC profiling fracturing = the market and reducing the interoperability
>of HEVC, which I do share. However, the key = point here is that, that is
>not up to us, it is controlled by other organizations. = If we go ahead
>to disallow the = support of that in the HEVC payload format, that = does
>not mean we would = successfully prevent that from happening in
>MPEG/ITU-T and other application standard = organizations - and if that
>happens, then an extension to the payload format would = need to be
>specified, which = might introduce more IOP issues even on the RTP encapsulation level for = HEVC.
> 
>I fully agree that some more opinions from = others would be very helpful.
> 
>Please, whoever cares about this draft and cares about = using HEVC with
>RTP, say your = opinion. We really need to have this document = finalized
>soon for HEVC = deployment!!!
> 
>See = some other detailed replies inline below too.
> 
>BR, YK
> 
>-----Original Message-----
>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;">>Sent: Tuesday, May 13, 2014 7:31 = AM
>To: Wang, Ye-Kui; Yago = Sanchez
>Cc: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org
>Subject: Re: [payload] Comments on = draft-ietf-payload-rtp-h265-02
> 
>Ye-Kui = and WG,
> 
>Please = see inline. I think we need input from more people into = this
>question to make = progress.
> 
> 
>On = 2014-05-06 16:56, Wang, Ye-Kui wrote:
>> Magnus,
>>
>> I think the only key different understanding = between us now is the
>> = following: Whether to assume that a decoder does not fully = support
>> any profile = indicated by profile-id (what you called "sub-profile", = e.g.
>> only support the = common tools of two or more profiles).
>>
>> Once we converge here, it should be easy to derive = that text changes
>> = should be made. Thus, let me focus on this in this = email.
>>
>> = Your opinion is obvious and strong - don't go into that = direction.
>>
>> = My opinion is strong too - we do need to go into that = direction,
>> because of = the following reasons:
>>
>> - = The ITU-T/MPEG control how to use the bits of profile-id = and
>> = profile-compatibility-indicator in the video coding = specifications.
>> It is = simply possible that a new profile can be defined and = indicated
>> without = using a new value of profile-id, but indicated as = conforming
>> to two = profiles. This happened for AVC for the Constrained = Baseline
>> profile as = I explained. Also, in the recently finalized HEVC = Range
>> Extensions spec (see = here:
>> = /
>> = JCTVC-Q1005-v4.zip),
>> = 19 new profiles have been defined, indicated by only one value = of
>> profile-id and some = values of bits of the interop-constraints field
>> (Note, not the = profile-compatibility-indicator field).
> 
>Yes this may happen, but jumping onto this now, do in = fact create a
>tool where = anyone can attempt to create new interoperability points = by
>selecting an intersection = between profiles. That doesn't benefit
>interoperability, it instead fractures the = market and works against the
>purpose of the profiles in the first = place.
> 
>[YK]: = Agreed - but again that is not up to us, it is controlled = by
>other SDOs (which are in = turn driven by the markets).
> 
>Secondly, in relation to H.264 constrained baseline, = that was created
>using constraint = bits, a concept that already is part of the
>specification, it might be defined as the = intersection of two profiles,
>but the signalling is done according to one profile = with a specific bit
>set. = Just like the HEVC Range Extension profiles.
> 
>[YK]: Why the signalling is different? Herein you also = use a profile-id
>value with a = specific bit set.
> 
>However, to me it appears that when one selected the = structure for HEVC
>Range = Extensions one forgot about the = profile-compatibility-indicator
>as it is not possible to signal compatibility across = the main
>directions in = the range extension profiles. The main directions = are
>within themselves nicely = onion shaped, but the compatibility between
>them does not appear to have been well = considered.
> 
>[YK]: = I was not involved in the definition of the structure for = HEVC
>Range Extensions - so no = comment here.
> 
>>
>> - = Application standards organizations, e.g. 3GPP, may = require
>> = "sub-profile" capability for decoders. Again, AVC = Constrained
>> Baseline = profile is an example - Magnus you should know this = much
>> better than many = others.
> 
>Yes, = however I think it is usually bad for interoperability. And = HEVC
>does not appear to be in = the same position that H.264 was when it was
>just finished. Thus, I expect the issues are = being different.
> 
>[YK]: = True - but on the other hand, that was driven by the market = too,
>and they wanted that for = interoperability for that particular capability.
>Here the issue is not about what was defined = already in HEVC, but what
>could = be done in the future. When RFC 3984 was finalized, = the
>Constrained Baseline = profile was not available yet. So, right now, the
>situation is the same. Unless we can surely = know similar things won't
>happen, we should follow the approach in RFC 3984, i.e. = to allow for
>such = intersection of two more profiles. Nobody can be sure right = now
>for what could happen in = the future, at least for this issue.
> 
>>
>> = Thus, when defining the HEVC RTP payload here, I don't think we = can
>> ignore the above. = Rather, we must go into the direction of
>> "sub-profile".
> 
>I understand your arguments. What is required is highly = dependent on
>what will be = done with future profiling of HEVC. I see enabling = the
>possibility to intersect = any choice of profiles do create an potential
>for fracturing the market and reducing the = interoperability of HEVC.
> 
>[YK]: = Again, agree in general, but again that is not controlled by = us.
> 
>Cheers
> 
>Magnus = Westerlund
> 
>---------------------------------------------------------= -------------
>Services, Media = and Network features, Ericsson Research EAB/TXM
>---------------------------------------------------------= -------------
>Ericsson = AB            =      | Phone  +46 10 = 7148287
>F=E4r=F6gatan = 6            &= nbsp;    | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>---------------------------------------------------------= -------------
> 
>_______________________________________________
>payload mailing = list
 
_______________________________________________
payload mailing list


=
= = --Apple-Mail=_022C07F0-29BA-41AD-85F7-A88CEA53F003-- From nobody Sat May 17 03:47: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 C0D281A000D for ; Sat, 17 May 2014 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 6PnrobIvZf6P for ; Sat, 17 May 2014 03:46:57 -0700 (PDT) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 941F31A0023 for ; Sat, 17 May 2014 03:46:56 -0700 (PDT) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Content-Type: multipart/alternative; boundary="Apple-Mail=_D8CF618F-1725-4DC2-BAC7-2A0A74CB8F51" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yago Sanchez In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@nasanexd02f.na.qualcomm.com> Date: Sat, 17 May 2014 12:46:45 +0200 Message-Id: References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@nasanexd02f.na.qualcomm.com> To: Jonatan Samuelsson X-Mailer: Apple Mail (2.1874) X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20698.006 X-TM-AS-Result: No--27.634-11.0-31-10 X-imss-scan-details: No--27.634-11.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: mGV7xPP3pcU7iuZ/mdYYtlCedixYXzOrCV5GGxwE9VzvVWUsZ2Mpku8q uj4XkUhL8zWY0cbqPL4dxBAG5/hkWwXXmzqmsIi7NnTulc4DT5nORC5YSFfY+y/layKw2sQT5O0 gWNbQ5pdKqHz0bbqoCGzBijri5+RV+LidURF+DB0XdhT0BAdFzskUhKWc+gwPhRRldM2EkSI6ua uFPPtNZbgSigd+50baBFtTtfRjLMHomPrNi98UBESVpnjjB2vke/sij3WsF/Aia5lIlJqExT+MS BX7DG43bBfEWzUJPFesDodw9yUkxgO3/A5KGHP/H5kZy/EQbgR4NBlm/4a7fX+0Af6HPHTndFD0 10qWJucFdjShemonXrThj82FPFSCtDSfcMR+7ZMxRNW7reqp1DBXXb/qS263BZreHpNuL3JyrEh 88nqfobaOw3xqC4q84jRkIImnX0NQCOsAlaxN75j9R7obtcgy0rqU5YP+XxSGDhWUBvJBA8SW+6 5RkljTuyWSkmm9TH7AJnGRMfFxyZVl8bxyvq1eVL6geaPy6nOEY2+qvfbJSSeWRIt3Ntj4o9Quc KBCOaGbcr4ImzwgkxHRbGr1ECgHkT7cMJfe6JtjEYffELkJAMFhZqAymFDVUpOLo+5+pg22ulYb Kh5IXqkkQ1CnmCG/CLQsumV/5S/82p2ebJNgc1wpnAAvAwaz/Wj6/cXcCVl8+EOJxRoKCVIetti 0jAIrFrC7JkTvr3clcqT+ugT9ECR8aOC0Z4AoaxKBbTWINAt5V8mQm73t9JqxT9Jd2NYjMJTUBf mDlFuvGlLKy0RckqMVgdN9w+TC6lJjXPUiIdSbKItl61J/yZUdXE/WGn0FRI2bAzQeUMU6nvZ/6 W0BhzsAVzN+Ov/sO6E19sk5XBVtkcWT1Y/NALim6MZahMFvWlING3laKBEFopq/FMFzBw== X-IMSS-DKIM-White-List: No X-alterMIME: Yes Archived-At: http://mailarchive.ietf.org/arch/msg/payload/8tF5Pd9DcRZ7d1ijwo-pR4FXABw Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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: Sat, 17 May 2014 10:47:03 -0000 --Apple-Mail=_D8CF618F-1725-4DC2-BAC7-2A0A74CB8F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jonatan,=20 Similar to Ye-Kui=92s comments, on the inclusion of MD5 in the RPSI, it = is not clear to me why this could be useful. When talking about = =93incompatibility=94 about encoder and decoder this would mean that one = of them is not properly working, i.e. it does not fully conform to the = standard. In such a case I personally do not think that this is an issue = needed to be solved with the RPSI but at the development phase of the = encoder/decoder. I would assume here that both encoder and decoder are = conforming to the standard. For other cases, I cannot think of any case of a picture being = =93correctly=94 decoded, while being a mismatch between encoder and = decoder. Is there any case where this happens that I am missing? Best regards, Yago On 17 May 2014, at 01:09, Wang, Ye-Kui wrote: > Hi Jonatan, > =20 > Thanks for reviewing the new version. Please see my replies inline = below, including some comments on the two newly proposed features = related to RPSI. For these two features, let=92s first discuss whether = to have them in this payload format document before going into the = details in text proposed in another email. > =20 > BR, YK > =20 > From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com]=20 > Sent: Wednesday, May 14, 2014 1:58 AM > To: Wang, Ye-Kui; payload@ietf.org > Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt > =20 > Dear Ye-Kui, editors, all, > Thanks for improving the draft and making the new version available. I = read through the new section 8 in the latest draft, in which more = feedback features have been added (which I think is very good). I have = some minor comments and then some suggestions for improving the RPSI = signalling. Compared to earlier standards, HEVC contains a new very = useful SEI message that can be used to check integrity and correctness = of decoded pictures and thereby detect errors that are not necessarily = due to packet losses: Decoded picture hash SEI (e.g. MD5 calculated = over a decoded picture) . I think it would be good to exploit that = functionality also in the RTP payload format for HEVC in order to make = implementations even more robust. > First some minor comments: > In 8.1: > A. Remove one instance of 'the loss of' in the sentence: ' As = specified in RFC 4585 section 6.3.1, the reception of a picture loss = indication by a media sender indicates the loss of "the loss of an = undefined amount of coded video data belonging to one or more = pictures.".' > =20 > [YK]: Thanks! To be done in the next version. > B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. > [YK]: Thanks! To be done in the next version. > =20 > In 8.2: > C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB = raster scan order of a picture.'. When tiles are used, the loss of a = slice does typically not result in lost CTBs in raster scan order of the = picture. The text does not describe how to calculate the "Number" field = for this case. Wouldn't it be better to use 'tile scan' in order to = correctly identify what part of the picture was lost? > =20 > [YK]: The intended use of the SLI message as specified is to indicate = the loss of CTBs regardless of whether and how slices are in use and = whether and how tiles are in use. The semantics of the =93Number=94 = field is clear to me too =96 why it is not clear? Note that the = semantics of slice_segment_address in the HEVC spec itself is also in = CTB raster scan order, regardless of whether and how tiles are in use. = Personally I=92d prefer to keep the semantics of SLI to be generic, and = also aligned with the semantics of slice_segment_address in the HEVC = spec. > D. Regarding 'the subfield "First" MUST be set to the CTB address of = the first lost CTB'. Wouldn't it be better to require "First" to be set = to a number that is lower than or equal to the CTB address of the first = lost CTB, since it might be difficult to deduce the exact CTB address of = the first lost CTB in the case of loss of dependent slices and/or = fragmentation units? > =20 > [YK]: To me this change would make the semantics a lot less clear and = the message less useful. Also, each dependent slice segment has = slice_segment_address signalled too, while FUs are supposed to be = assembled before sending to the decoder =96 thus from the decoder point = of view FUs do not need to be considered. > E. Regarding 'The subfield "PictureID" MUST be set to the 6 = least significant bits of a binary representation of the value = of slice_pic_order_cnt_lsb of the picture for which the lost CTBs are = indicated.'. Isn't it better to use the 6 least significant bits of = PicOrderCntVal? Using the 6 least significant bits of = slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the = case when slice_pic_order_cnt_lsbconsists of fewer than 6 bits. > [YK]: Good point. To be done in the next version unless the discussion = leads into a different conclusion. > =20 > F. Regarding the sentence: 'In many cases, error tracking is required = to identify the corrupted region in the receiver's state (reference = pictures) because of error import in uncorrupted regions of the picture = through motion compensation, and reference picture selection can also be = used to "clean up" the corrupted picture, which is usually more = efficient and less likely to generate congestion than sending intra = information.' For improved readability I suggest splitting it in two = sentences: 'In many cases, error tracking is required to identify the = corrupted region in the receiver's state (reference pictures) because of = error import in uncorrupted regions of the picture through motion = compensation. Reference picture selection can also be used to "clean up" = the corrupted picture, which is usually more efficient and less likely = to generate congestion than sending intra information.' > [YK]: To be done in the next version. > =20 > Regarding RPSI (section 8.3) I would like to propose the following = changes: > G. Add the possibility to include more than one reference picture in = the RPSI message so that the encoder can select to use one or more of = the pictures included in RPSI message. Using multiple pictures for = reference is a key feature in HEVC which substantially improves coding = efficiency. In the case where multiple earlier pictures are available = for reference it is beneficial to let the encoder decide which one(s) to = use for reference instead of relying on the decoder to make that = selection. > [YK]: A few points to discuss. G.1: Is it backward compatible to RFC = 4585 to use one RPSI message to convey more than one reference picture? = Would it be better to define a new message for this purpose if it is = deemed useful? G.2: The concept applies to any video codec that supports = multiple reference pictures, is not specific to HEVC, thus would it be = better if this is discussed as a generic mechanism, similarly as the = SPLI message included in draft-ietf-payload-rtp-h265-01 but dropped = later for the very reason? G.3: On the usefulness of this functionality = seems to be unclear to me either. If the last correct picture before an = error occurs is known, it is also known that the reference pictures of = the last correct pictures are correct, thus the encoder can anyway = choose to use one or more of these pictures, when available, for = encoding the next picture. Thus, it might be sufficient just to slightly = change the semantics of the RPLI message, to say that the encoder can = choose to use one or more of the identified picture and its reference = pictures for encoding the next picture. > =20 > H. Using the 2 currently unused bits in the 'Native RPSI bit string = defined per codec' for adding the possibility of including information = regarding the MD5 in the RPSI message as follows: > 0: No information regarding the MD5 available > 1: The MD5 of the reference picture is verified to be = correct > 2: The MD5 of the reference picture is incorrect (i.e. do = NOT use for reference) > 3: The MD5 is included in the RPSI message (directly = following the PicOrderCntVal) > The last option can be used when the encoder does not include MD5s = in-band but wants to check the MD5 before using a selected picture for = reference. Typically this will be more bit-efficient than including = decoded picture hash SEI messages in-band. > In my opinion it would be very useful to be able to include = information regarding the correctness of the decoded pictures, e.g. to = detect incompatibility issues and bit errors. I will send a suggestion = for the text changes needed to enable this, hopefully later today. > =20 > [YK]: Firstly, in my understanding, the decoder picture hash SEI = message is very useful for debugging in development of encoder and = decoder implementations, as used by the JCT-VC for the development of = the HEVC reference software, and it is intended for use with that = purpose. Using of it for error resilience in communications is an = overkill to me. For example, you would need 48 bytes to signal the MD5 = hash for each picture. Secondly, it is architecturally incorrect to = couple this with the RPSI feedback message, as the picture identified is = supposed to be correctly decoded by the decoder and the purpose of the = message is to request the encoder to use that picture for encoding of = the next picture, thus why would you even indicate a picture that is = incorrect using an RPSI feedback message? > =20 > Best Regards Jonatan > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, = Ye-Kui > Sent: den 30 april 2014 20:29 > To: payload@ietf.org > Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt > =20 > Dear All, > =20 > Compare to -02, we have addressed most of the numerous comments and = tickets, from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the = following changes: > - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the = reflector, agreed by most of the authors, no objection from anyone. > - Addition of an informative, brief description of the display = orientation SEI message, which is among one of those new SEI messages = that have some systems usage. > - Addition of a definition of NAL-unit-like structure. The term was = used but not defined earlier. > - Addition of descriptions for use of the PLI and SLI messages = (specified in RFC 4585) and the FIR message (specified in RFC 5104) with = HEVC, in addition to the RFC 4585 RPSI message for which the use = description was already included, as agreed during the presentation at = the previous IETF meeting > =20 > Remaining open issues: > - On profile-compatibility-indicator and interop-constraints (raised = by Magnus, being discussed among Magnus, myself and Yago, no conclusion = yet) > - On recv-sub-layer-id and using of sprop-vps for session negotiation = (raised by Magnus, still being discussed among the authors and Magnus) > - On source-specific sprop parameter sets (raised by Magnus, still = being discussed among the authors and Jonathan for exact text changes) > - On using a different parameter category for level-id (raised by = Magnus, discussed between Magnus and myself, no conclusion yet) > - I just noticed that the definition of "packet stream" itself needs = to be changed back to "RTP stream" > =20 > We will try to address the above open issues as soon as possible. At = the same time, further review and comments are welcome. > =20 > BR, YK > =20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Wednesday, April 30, 2014 10:34 AM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt > =20 > =20 > 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. > =20 > Title : RTP Payload Format for High Efficiency Video = Coding > Authors : Ye-Kui Wang > Yago Sanchez > Thomas Schierl > Stephan Wenger > Miska M. Hannuksela > Filename : draft-ietf-payload-rtp-h265-03.txt > Pages : 92 > Date : 2014-04-30 > =20 > Abstract: > This memo describes an RTP payload format for the video coding > standard ITU-T Recommendation H.265 and ISO/IEC International > Standard 23008-2, both also known as High Efficiency Video Coding > (HEVC) [HEVC] and developed by the Joint Collaborative Team on = Video > Coding (JCT-VC). The RTP payload format allows for packetization = of > one or more Network Abstraction Layer (NAL) units in each RTP = packet > payload, as well as fragmentation of a NAL unit into multiple RTP > packets. Furthermore, it supports transmission of an HEVC = bitstream > over a single as well as multiple RTP streams. The payload format > has wide applicability in videoconferencing, Internet video > streaming, and high bit-rate entertainment-quality video, among > others. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 > =20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 > =20 > =20 > 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. > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =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 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --Apple-Mail=_D8CF618F-1725-4DC2-BAC7-2A0A74CB8F51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Jonatan, 

Similar to Ye-Kui=92s comments, on the = inclusion of MD5 in the RPSI, it is not clear to me why this could be = useful. When talking about =93incompatibility=94 about encoder and = decoder this would mean that one of them is not properly working, i.e. = it does not fully conform to the standard. In such a case I personally = do not think that this is an issue needed to be solved with the RPSI but = at the development phase of the encoder/decoder. I would assume here = that both encoder and decoder are conforming to the = standard.

For other cases, I cannot think of = any case of a picture being =93correctly=94 decoded, while being a = mismatch between encoder and decoder. Is there any case where this = happens that I am missing?

Best = regards,
Yago

On 17 May 2014, at = 01:09, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> = wrote:

Hi Jonatan,
 
Thanks for reviewing the = new version. Please see my replies inline below, including some comments = on the two newly proposed features related to RPSI. For these two = features, let=92s first discuss whether to have them in this payload = format document before going into the details in text proposed in = another email.
 
BR, YK
 
From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Wednesday, May 14, 2014 = 1:58 AM
To: Wang, Ye-Kui; payload@ietf.org
Subject: RE: [payload] I-D Action: = draft-ietf-payload-rtp-h265-03.txt
 
Dear Ye-Kui, editors, = all,
Thanks for improving the draft and = making the new version available. I read through the new section 8 in = the latest draft, in which more feedback features have been added (which = I think is very good). I have some minor comments and then some = suggestions for improving the RPSI signalling. Compared to earlier = standards, HEVC contains a new very useful SEI message that can be used = to check integrity and correctness of decoded pictures and thereby = detect errors that are not necessarily due to packet losses: = Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also = in the RTP payload format for HEVC in order to make implementations even = more robust.
First some minor = comments:
In = 8.1:
A. Remove one instance of 'the loss = of' in the = sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a = media sender indicates the loss of "the loss of an undefined amount of = coded video data belonging to one or more pictures.".'
 
[YK]: Thanks! To be done in the next = version.
B. The 'BE' in 'SHOULD BE' should not = be using CAPITAL LETTERS.
[YK]: Thanks! To be done in the next = version.
 
In = 8.2:
C. Regarding 'the loss of a = number of Coded Tree Blocks (CTBs) in CTB raster scan order of a = picture.'. When tiles are used, the loss of a slice does typically = not result in lost CTBs in raster scan order of the picture. The text = does not describe how to calculate the "Number" field for this case. = Wouldn't it be better to use 'tile scan' in order to correctly = identify what part of the picture was lost?
 
[YK]: The intended use of = the SLI message as specified is to indicate the loss of CTBs regardless = of whether and how slices are in use and whether and how tiles are in = use. The semantics of the =93Number=94 field is clear to me too =96 why = it is not clear? Note that the semantics of slice_segment_address in the = HEVC spec itself is also in CTB raster scan order, regardless of whether = and how tiles are in use. Personally I=92d prefer to keep the semantics = of SLI to be generic, and also aligned with the semantics of = slice_segment_address in the HEVC = spec.
D. Regarding 'the subfield = "First" MUST be set to the CTB address of the first lost CTB'. Wouldn't = it be better to require "First" to be set to a number that is lower = than or equal to the CTB address of the first lost CTB, since it might = be difficult to deduce the exact CTB address of the first lost CTB in = the case of loss of  dependent slices and/or fragmentation = units?
 
[YK]: To me this change would make the semantics a = lot less clear and the message less useful. Also, each dependent slice = segment has slice_segment_address signalled too, while FUs are supposed = to be assembled before sending to the decoder =96 thus from the decoder = point of view FUs do not need to be = considered.
E. Regarding 'The subfield = "PictureID" MUST  be  set  to  the  6  = least significant  bits  of  a  binary = representation  of  the  value  of = slice_pic_order_cnt_lsb  of  the picture for which the lost = CTBs are indicated.'. Isn't it better to use the 6 least significant = bits of PicOrderCntVal? Using the 6 least significant bits of  slice_pic_order_cnt_lsb seems a bit confusing (and = less robust) for the case when slice_pic_order_cnt_lsbconsists of  fewer than 6 = bits.
[YK]: Good = point. To be done in the next version unless the discussion leads into a = different conclusion.
 
F. Regarding the sentence: 'In many cases, = error tracking is required to identify the corrupted region in the = receiver's state (reference pictures) because of error import in = uncorrupted regions of the picture through motion compensation, and = reference picture selection can also be used to "clean up" the corrupted = picture, which is usually more efficient and less likely to generate = congestion than sending intra information.' For improved readability I = suggest splitting it in two sentences: 'In many cases, error tracking is = required to identify the corrupted region in the receiver's state = (reference pictures) because of error import in uncorrupted regions of = the picture through motion compensation. Reference picture selection can = also be used to "clean up" the corrupted picture, which is usually more = efficient and less likely to generate congestion than sending intra = information.'
[YK]: To be = done in the next version.
 
Regarding RPSI (section 8.3) I would like to = propose the following changes:
G. Add the = possibility to include more than one reference picture in the RPSI = message so that the encoder can select to use one or more of the = pictures included in RPSI message. Using multiple pictures for reference = is a key feature in HEVC which substantially improves coding efficiency. = In the case where multiple earlier pictures are available for reference = it is beneficial to let the encoder decide which one(s) to use for = reference instead of relying on the decoder to make that = selection.
[YK]: A few = points to discuss. G.1: Is it backward compatible to RFC 4585 to use one = RPSI message to convey more than one reference picture? Would it be = better to define a new message for this purpose if it is deemed useful? = G.2: The concept applies to any video codec that supports multiple = reference pictures, is not specific to HEVC, thus would it be better if = this is discussed as a generic mechanism, similarly as the SPLI message = included in draft-ietf-payload-rtp-h265-01 but dropped later for the = very reason? G.3: On the usefulness of this functionality seems to be = unclear to me either. If the last correct picture before an error occurs = is known, it is also known that the reference pictures of the last = correct pictures are correct, thus the encoder can anyway choose to use = one or more of these pictures, when available, for encoding the next = picture. Thus, it might be sufficient just to slightly change the = semantics of the RPLI message, to say that the encoder can choose to use = one or more of the identified picture and its reference pictures for = encoding the next picture.
 
H. Using the 2 currently unused bits in the = 'Native RPSI bit string defined per codec' for adding the possibility = of including information regarding the MD5 in the RPSI message as = follows:
0:          = ;  No information regarding the MD5 = available
1:          = ;  The MD5 of the reference picture is verified to be = correct
2:          &= nbsp; The MD5 of the reference picture is incorrect (i.e. do NOT use for = reference)
3:         &nbs= p;  The MD5 is included in the RPSI message (directly following the = PicOrderCntVal)
The last option can be used when the = encoder does not include MD5s in-band but wants to check the MD5 before = using a selected picture for reference. Typically this will be more = bit-efficient than including decoded picture hash SEI messages = in-band.
In my opinion it would be very useful = to be able to include information regarding the correctness of the = decoded pictures, e.g. to detect incompatibility issues and bit errors. = I will send a suggestion for the text changes needed to enable this, = hopefully later today.
 
[YK]: Firstly, in my = understanding, the decoder picture hash SEI message is very useful for = debugging in development of encoder and decoder implementations, as used = by the JCT-VC for the development of the HEVC reference software, and it = is intended for use with that purpose. Using of it for error resilience = in communications is an overkill to me. For example, you would need 48 = bytes to signal the MD5 hash for each picture. Secondly, it is = architecturally incorrect to couple this with the RPSI feedback message, = as the picture identified is supposed to be correctly decoded by the = decoder and the purpose of the message is to request the encoder to use = that picture for encoding of the next picture, thus why would you even = indicate a picture that is incorrect using an RPSI feedback = message?
 
Best Regards = Jonatan
-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On = Behalf Of Wang, Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: = [payload] I-D Action: = draft-ietf-payload-rtp-h265-03.txt
 
Dear All,
 
Compare to -02, we have addressed most of the = numerous comments and tickets, from Magnus, Jonathan, Jonatan, Bernard, = ..., as well as the following = changes:
- Addition = of sprop-sei, as suggested by Stephan on Apr. 23 to the reflector, = agreed by most of the authors, no objection from = anyone.
- Addition = of an informative, brief description of the display orientation SEI = message, which is among one of those new SEI messages that have some = systems usage.
- Addition of a definition of NAL-unit-like structure. The = term was used but not defined = earlier.
- Addition = of descriptions for use of the PLI and SLI messages (specified in RFC = 4585) and the FIR message (specified in RFC 5104) with HEVC, in addition = to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF = meeting
 
Remaining open = issues:
- On = profile-compatibility-indicator and interop-constraints (raised by = Magnus, being discussed among Magnus, myself and Yago, no conclusion = yet)
- On = recv-sub-layer-id and using of sprop-vps for session negotiation (raised = by Magnus, still being discussed among the authors and = Magnus)
- On = source-specific sprop parameter sets (raised by Magnus, still being = discussed among the authors and Jonathan for exact text = changes)
- On using = a different parameter category for level-id (raised by Magnus, discussed = between Magnus and myself, no conclusion = yet)
- I just = noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream"
 
We will try to address the above open issues as = soon as possible. At the same time, further review and comments are = welcome.
 
BR, YK
 
-----Original = Message-----
Sent: Wednesday, April 30, 2014 10:34 = AM
Subject: [payload] I-D Action: = draft-ietf-payload-rtp-h265-03.txt
 
 
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 High Efficiency Video = Coding
        = Authors         : Ye-Kui = Wang
          &= nbsp;           &nb= sp;   Yago Sanchez
          &= nbsp;           &nb= sp;   Thomas Schierl
          &= nbsp;           &nb= sp;   Stephan Wenger
          &= nbsp;           &nb= sp;   Miska M. = Hannuksela
        = Filename        : = draft-ietf-payload-rtp-h265-03.txt
        = Pages           : = 92
        = Date            : = 2014-04-30
 
Abstract:
   This memo describes an RTP payload = format for the video coding
   standard ITU-T Recommendation H.265 = and ISO/IEC International
   Standard 23008-2, both also known as = High Efficiency Video Coding
   (HEVC) [HEVC] and developed by the = Joint Collaborative Team on Video
   Coding (JCT-VC).  The RTP = payload format allows for packetization = of
   one or more Network Abstraction Layer (NAL) = units in each RTP packet
   payload, as well as fragmentation of = a NAL unit into multiple RTP
   packets.  Furthermore, it = supports transmission of an HEVC = bitstream
   over a single as well as multiple RTP = streams.  The payload format
   has wide applicability in = videoconferencing, Internet video
   streaming, and high bit-rate = entertainment-quality video, = among
   others.
 
 
The IETF datatracker status page for this draft = is:
 
A diff from the previous version is available = at:
 
 
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:
 
_______________________________________________
payload mailing = list
 
_______________________________________________
payload mailing = list
 
___________________= ____________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload


=
= = --Apple-Mail=_D8CF618F-1725-4DC2-BAC7-2A0A74CB8F51-- From nobody Mon May 19 02:23: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 398C21A032A for ; Mon, 19 May 2014 02:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 fnfaKfzpeVCQ for ; Mon, 19 May 2014 02:23:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0DC1A0253 for ; Mon, 19 May 2014 02:23:21 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-ec-5379cd885273 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.C2.05409.88DC9735; Mon, 19 May 2014 11:23:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.10]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Mon, 19 May 2014 11:23:19 +0200 From: Jonatan Samuelsson To: Yago Sanchez , "Wang, Ye-Kui" Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAVZn0AgACL4YCAA/zxAIAA/yUAgAKbJwCAAA2ygIACxNYAgAPm0oCAAMF4AIABFZ+AgACbyQCAAFQJAIAK+PqAgAApCgCAAAsqAIAETxpggABzw4CAAQhwAIAC/ESA Date: Mon, 19 May 2014 09:23:19 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB2322DC18@ESESSMB109.ericsson.se> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109 .ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A8345294AAE@nasanexd02f.na.qualcomm.com> <6E8F970B-DBA2-4EA8-87FF-F96D9AC2E5C3@hhi.fraunhofer.de> In-Reply-To: <6E8F970B-DBA2-4EA8-87FF-F96D9AC2E5C3@hhi.fraunhofer.de> 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_634D3B5D82E3214DA9B6A36D5F50DB2322DC18ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM+JvjW7H2cpgg4b1ihanLu5jtbh08SyT xfXGTewWk46vZbN4suYYswOrx/RTi5k9liz5yeSxaOozRo/F698zeny5/JktgDWKyyYlNSez LLVI3y6BK+Pp5Y0sBVfXsFV0HJvM3sD44RJrFyMnh4SAicTBiVPZIGwxiQv31gPZXBxCAkcZ JZYcfcEM4SxmlNj6eAt7FyMHB5uAlcT3FxEgpohArMSXz+4gJcwCjxgl/n5cwQgSFxZwlHhx QA2ixEni5E4ukBIRgX2MEhOWLAXbxSKgKjG/eR8LiM0r4C0x494pVohV0zgldp/rYAdJcAq4 Ssw6OxGsiFFAVuL+93tgNrOAuMStJ/OZII4WkFiy5zwzhC0q8fLxP6jHFCXanzYwQtTnS1zv nAO1TFDi5MwnLBMYRWchGTULSdksJGUQcT2JG1OnsEHY2hLLFr5mhrB1JWb8O8SCLL6AkX0V o2hxanFSbrqRsV5qUWZycXF+nl5easkmRmC8HtzyW3UH4+U3jocYBTgYlXh4F6RWBguxJpYV V+YeYpTmYFES5729qzRYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OVyrM3L5r9OueuZg82 W8ndJipgVrdQhle3S23ac+8rQSc9mCY8eL7008PbtdpqU/Zu3XQq6KBYzJH4kCauvOYwvVWN 52Rvd/yZUMj3U9yFM6DS9Otsr9kLKrqdk2Yu57+472A98+MPTQ+fNZzYvqFuo+zj/VUzu98/ DpjKsqy2tGuB/PG63U1KLMUZiYZazEXFiQBgYG+uuAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/payload/uuzRV0aAHmhKrTAZUz7j2gZ89QM Cc: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" 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, 19 May 2014 09:23:36 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB2322DC18ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ye-Kui, Yago, all, Just to make one thing clear; there is a HUGE difference between bitstreams= that conforms to multiple profiles (which is what "item b)" below is about= ) and decoders that only supports intersections of multiple profiles. From = an encoder implementers point of view it is a nightmare to handle all the d= ifferent intersections that can occur. As soon as a new profile is defined = in the HEVC specification an encoder implementer will not only have to add = support for that profile but also for all the intersections with old profil= es and all the intersections with the different intersections of old profil= es. A complete explosion of operating points resulting in increased cost an= d higher risk of bugs and misinterpretations causing interoperability probl= ems. I think profile-compatibility-indicator is very useful as a bitstream prope= rty (sprop parameter). By using that, the same payload type can be accepted= by answerer A (supporting profile pA) and answerer B (supporting profile p= B). Let me express the alternatives I see for profile-compatibility-indicator, = in my order of preference: 1. Making it a sprop parameter only (expressing a property of the bit= stream) 2. Making 2 parameters: one sprop parameter AND one receiver paramete= r that can be used to express that the decoder supports multiple (full) pro= files (similar to the cited text below from the latest draft of the payload= spec) 3. Making it a single parameter used both for expressing that a bitst= ream conforms to multiple profiles and that a decoder only supports the int= ersection of all the indicated profiles (this is what you are proposing, ri= ght?). I would strongly prefer if option 3 could be avoided for the above mentione= d reason. If not, I guess we just have to ensure that all SDOs that uses th= e HEVC payload spec does not use this mechanism :). See some further discus= sion inline below. Best Regards Jonatan From: Yago Sanchez [mailto:yago.sanchez@hhi.fraunhofer.de] Sent: den 17 maj 2014 12:06 To: Wang, Ye-Kui Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; draft-ietf-paylo= ad-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, Ye-Kui, Jonatan,all, Just to make clear my opinion on this topic, I am here with Ye-Kui and Step= han as already expressed previously in this thread. Desirable or not, profi= le_compatibility_indicator allows for indicating intersection of profiles a= s expressed in the item b) in the contribution mentioned in the email below= . Whether the intersections will get a profile_idc or not cannot be known b= eforehand and might not since we have profile_compatibility_flag for that p= urpose. Said that still I think the argument here is that if HEVC allows fo= r it we should support it in the payload format. [JS] As mentioned above; there is a HUGE difference between bitstreams that= conforms to multiple profiles and decoders that only supports intersection= s of multiple profiles. The HEVC spec does not allow the latter. If we intr= oduce the concept of decoders conforming to intersection of profiles in the= HEVC payload format that would be something which does not have any corres= pondence in the HEVC spec. Best regards, Yago On 16 May 2014, at 20:20, Wang, Ye-Kui > wrote: Hi Jonatan, Thanks for responding to my request for comments - I really appreciate (eve= n though you are not supporting my opinion :)). Frankly, I think the observations you pointed out below do not support the = opinion you expressed (See more detailed replies inline below.). What are being discussed here, as Stephan accurately pointed out, is whethe= r to narrow down the number of interoperability points negotiable using O/A= negotiation, by intentionally disabling a mechanism that was expressly inc= luded for purposes that might happen and that have happened. To do (the na= rrowing down) or not to do, that is the question. And the key point to dert= ermine the answer to the question is whether THAT (the intersection way of = profiling) might happen. Unless it is fairly sure that THAT won't happen, w= e ought to provide the support of THAT in the payload format. [JS] Given that the profiles in HEVC version 1 are nicely "onion shaped" (= which they were not in h.264) and given that there are 48 constraint flags = (compared to the 8 in h.264) I am personally fairly sure THAT won't happen,= but apparently you are not :). The facts that THAT did happened for H.264 and that whether it would happen= is not controlled by IETF, but by other organizations, more than one of th= em, I'd say that we are far from being fairly sure that THAT won't happen. = Again, if the narrowing is done and if THAT occurs, then an extension to th= e payload format needs to be specified to add the support of this case and = the design would be the same as what we have now, except that it introduces= new IOP issue on the payload format level (due to two incompatible version= s of the payload format), and if the narrowing is not done and if THAT does= not occur, all the hypothetical issues won't happen anyway. [JS] If THAT does occur sometime in the future, there are multiple options = for how it could be handled in the payload format (depending on how specifi= c the case for which it occurs is). I would much rather see some inconvenie= nce for that specific case then, compared to this burdensome mechanism. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Friday, May 16, 2014 2:31 AM To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 Dear Ye-Kui, Stefan, all, Let me express my opinion on this topic (since you explicitly asked for mor= e opinions). I do represent the same company as Magnus, but (in contrast to= Magnus) I was also part of the discussions on how to define the profiles i= n HEVC version 1. I share Magnus' view that it would be very unfortunate if= the payload format allows for definitions of sub-profiles using profile-co= mpatibility-indicator. The purpose of the profile_compatibility_flags is ve= ry clear in the contribution that proposed them, JCTVC-I0499 (http://phenix= .it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761): "We need a labelling scheme that: a) allows the committee to introduce new profiles, and older systems b= e able to work out which bitstreams they can decode when those new profiles= are fully subsets of older existing profiles, even when they do not recogn= ize the new profile identifier; b) allows bitstreams which don't use all the features of any given pro= file, and are as a consequence compatible with more than one, to be labelle= d with so that it's possible to deduce all the profiles that the bitstream = is compatible with (the ones that don't automatically follow from the nesti= ng structure). " [YK]: Item b above talking about exactly encoding a bitstream using an inte= rsection of multiple profiles, which is exactly the point we are taking abo= ut. If there is an intersection between two profiles that does make sense and i= s useful to the industry it is reasonable to assume that ITU/ISO/IEC would = define a new profile corresponding to that intersection (just as was done w= ith Constrained Baseline Profile in h.264). [YK]: Defining a new profile does not necessarily means using of a new valu= e of the profile-id for indicating the new profile, just as was done with t= he Constrained Baseline profile of H.264. And in HEVC, the profile_compatibility_flags provides a mechanism for intro= ducing a new profile, with a new profile_idc while still being able to indi= cate conformance to one or more of the old profiles (a mechanism that did n= ot exist in h.264). [YK]: The mechanism of profile_compatibility_flags is very similar to what = H.264 has, with the only difference been that in HEVC there are 32 of these= flags and 5-bit of profile-id, while in H.264 there are less bits of these= flags and 8 bits of profile-id. [JS] There is also the difference that the semantics of all the profile_com= patibility_flags in HEVC are defined already in version 1. In h.264 there w= ere only 3 bits defined in version 1 and the rest were reserved bits thus m= aking them more comparable to the flags called "interop-constraints" in the= HEVC payload draft. However, it is worth noting that the way the Range Extension profiles have = been defined in the second (soon to be released) version of HEVC, the funct= ionality of profile_compatibility_flag is already broken. There are 19 new = profiles in there but only one profile_idc is used to identify them. Thus i= t is not possible in the same bitstream to indicate that it conforms to two= different of these 19 profiles. [YK]: Which functionality of profile_compatibility_flag as specified in th= e HEVC spec is broken? I guess it is just the functionality of profile_comp= atibility_flag in your understanding is broken :) We should not assume anyt= hing more than said in the spec. I don't see anything written in the spec i= s broken, even though it was a little surprise to me too when seeing the de= finition of the Range Extension profiles (as I did not expect to use the in= terop-constraints bits for profile definition either). The fact that the in= terop-constraints bits have been used in profile definition proves more tha= t the way of profile signalling is not controlled by us, and we should NOT = preclude the support of such profile signalling. Fortunately, the mechanism= we currently specify in the payload draft, where interop-constraints is on= e of the configuration parameters required for symmetric use in O/A, works = with this. [JS] It appears broken to me: general_profile_compatibility_flag[ j ] equal to 1, when general_profile_sp= ace is equal to 0, indicates that the CVS conforms to the profile indicated= by general_profile_idc equal to i as specified in Annex A. How should you interpret "the CVS conforms to the profile indicated by gene= ral_profile_idc equal to i" when i equals 4? Which is "the profile" in this= case? Now to connect back to the example you mentioned, Ye-Kui, on May 5: "There = can be still be a point to offer profile-compatibility-indicator in this ca= se. For example, it is possible that the decoder of the offerer only suppor= ts the common tools of profiles A and B, while it does not support either f= ull profile A or full profile B. 1. I don't think this is desirable. [YK]: As I said earlier in replies to Magnus, I do share the concern either= , but this is not up to us - let me repeat again. 2. Within the profiles defined in "format range extension" (~90% of t= he profiles defined so far) this is not possible. [YK]: There is no such principle or functionality that the example must be = possible for all cases. As long as it is possible for any two of the 32 fla= gs, the payload format should provide support. Otherwise, as I said earlier= , we as the payload format designers are only introducing more IOP issues i= n the future once this is done (by other organizations). 3. When I read the latest HEVC payload format draft, I don't find any= thing supporting that kind of usage of profile-compatibility-indicator. On = the contrary: A decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. The profile-compatibility-indicator provides exact information of the ability of a decoder conforming to a certain profile to decode bitstreams conforming to another profile. More concretely, if the profile compatibility flag corresponding to the profile a decoder conforms to is set, then the decoder is able to decode any bitstream with the flag set, irrespective of the profile the bitstream conforms to (provided that the decoder supports the highest level of the bitstream). [YK] Due to the newly introduced signalling of Range Extensions profiles us= ing one profile-id value in combination with interop-constraints, the above= description of profile-compatibility-indicator needs to be updated. I had = planned to do this in the next version. But again, here we need to specify = the text to align with whatever is specified in the HEVC specification. I can see the benefit in using the interop-constraints to express constrain= ts that applies to well-defined profiles (both from a decoder and encoder p= oint of view). However, using profile-compatibility-indicator to let decode= rs create ad-hoc on the fly "sub-profiles" of an arbitrary number of define= d profiles serves IMO no purpose and is simply a misuse of theprofile_compa= tibility_flags. [YK] See above. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: den 13 maj 2014 19:38 To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, I=B9m one of the co-authors. To make one thing clear from the outset: I=B9m one who says that any and al= l options of a given payload necessarily need always to be supported by a R= TP payload format. Sometimes, it=B9s IMO completely OK to forgo the suppor= t of an odd mechanism that=B9s not required or useful for the application = =B3payload over the Internet using RTP=B2. That said, the case here is different. What we have here is a request (by Magnus) to narrow down the number of interoperability points negotiable usi= ng O/A negotiation, by intentionally disabling a mechanism that was express= ly included for purposes just like this. There was considerable discussion= in JCT-VC, MPEG, and VCEG about the subject. I would say it was one of th= e key drivers, but my view may be a bit one-sided. However, it was discuss= ed more than once. The front lines were often between the hardware folks (= who would like to have as few interop points as possible) and the software = people (who would prefer to have a finer granularity, to better suit indivi= dual application needs). The resulting compromise necessarily made no one = completely happy, but everyone could live with it. Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling arch= itecture discussions/decisions. Thanks for your consideration, Stephan On 13.5.14, 9:57, "Wang, Ye-Kui" > wrote: >Magnus, > >I understand your arguments too. Your main worry seems to be about the >HEVC profiling fracturing the market and reducing the interoperability >of HEVC, which I do share. However, the key point here is that, that is >not up to us, it is controlled by other organizations. If we go ahead >to disallow the support of that in the HEVC payload format, that does >not mean we would successfully prevent that from happening in >MPEG/ITU-T and other application standard organizations - and if that >happens, then an extension to the payload format would need to be >specified, which might introduce more IOP issues even on the RTP encapsula= tion level for HEVC. > >I fully agree that some more opinions from others would be very helpful. > >Please, whoever cares about this draft and cares about using HEVC with >RTP, say your opinion. We really need to have this document finalized >soon for HEVC deployment!!! > >See some other detailed replies inline below too. > >BR, YK > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, May 13, 2014 7:31 AM >To: Wang, Ye-Kui; Yago Sanchez >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265= @tools.ietf.org >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >Ye-Kui and WG, > >Please see inline. I think we need input from more people into this >question to make progress. > > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: >> Magnus, >> >> I think the only key different understanding between us now is the >> following: Whether to assume that a decoder does not fully support >> any profile indicated by profile-id (what you called "sub-profile", e.g. >> only support the common tools of two or more profiles). >> >> Once we converge here, it should be easy to derive that text changes >> should be made. Thus, let me focus on this in this email. >> >> Your opinion is obvious and strong - don't go into that direction. >> >> My opinion is strong too - we do need to go into that direction, >> because of the following reasons: >> >> - The ITU-T/MPEG control how to use the bits of profile-id and >> profile-compatibility-indicator in the video coding specifications. >> It is simply possible that a new profile can be defined and indicated >> without using a new value of profile-id, but indicated as conforming >> to two profiles. This happened for AVC for the Constrained Baseline >> profile as I explained. Also, in the recently finalized HEVC Range >> Extensions spec (see here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11 >> / >> JCTVC-Q1005-v4.zip), >> 19 new profiles have been defined, indicated by only one value of >> profile-id and some values of bits of the interop-constraints field >> (Note, not the profile-compatibility-indicator field). > >Yes this may happen, but jumping onto this now, do in fact create a >tool where anyone can attempt to create new interoperability points by >selecting an intersection between profiles. That doesn't benefit >interoperability, it instead fractures the market and works against the >purpose of the profiles in the first place. > >[YK]: Agreed - but again that is not up to us, it is controlled by >other SDOs (which are in turn driven by the markets). > >Secondly, in relation to H.264 constrained baseline, that was created >using constraint bits, a concept that already is part of the >specification, it might be defined as the intersection of two profiles, >but the signalling is done according to one profile with a specific bit >set. Just like the HEVC Range Extension profiles. > >[YK]: Why the signalling is different? Herein you also use a profile-id >value with a specific bit set. > >However, to me it appears that when one selected the structure for HEVC >Range Extensions one forgot about the profile-compatibility-indicator >as it is not possible to signal compatibility across the main >directions in the range extension profiles. The main directions are >within themselves nicely onion shaped, but the compatibility between >them does not appear to have been well considered. > >[YK]: I was not involved in the definition of the structure for HEVC >Range Extensions - so no comment here. > >> >> - Application standards organizations, e.g. 3GPP, may require >> "sub-profile" capability for decoders. Again, AVC Constrained >> Baseline profile is an example - Magnus you should know this much >> better than many others. > >Yes, however I think it is usually bad for interoperability. And HEVC >does not appear to be in the same position that H.264 was when it was >just finished. Thus, I expect the issues are being different. > >[YK]: True - but on the other hand, that was driven by the market too, >and they wanted that for interoperability for that particular capability. >Here the issue is not about what was defined already in HEVC, but what >could be done in the future. When RFC 3984 was finalized, the >Constrained Baseline profile was not available yet. So, right now, the >situation is the same. Unless we can surely know similar things won't >happen, we should follow the approach in RFC 3984, i.e. to allow for >such intersection of two more profiles. Nobody can be sure right now >for what could happen in the future, at least for this issue. > >> >> Thus, when defining the HEVC RTP payload here, I don't think we can >> ignore the above. Rather, we must go into the direction of >> "sub-profile". > >I understand your arguments. What is required is highly dependent on >what will be done with future profiling of HEVC. I see enabling the >possibility to intersect any choice of profiles do create an potential >for fracturing the market and reducing the interoperability of HEVC. > >[YK]: Again, agree in general, but again that is not controlled by us. > >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 --_000_634D3B5D82E3214DA9B6A36D5F50DB2322DC18ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ye-Kui, Yago, all,

 <= /p>

Just to make one thing cl= ear; there is a HUGE difference between bitstreams that conforms to multiple profiles (which is what “item b)” below i= s about) and decoders that only supports intersections of multiple profiles= . From an encoder implementers point of view it is a nightmare to handle al= l the different intersections that can occur. As soon as a new profile is defined in the HEVC specification an encoder i= mplementer will not only have to add support for that profile but also for = all the intersections with old profiles and all the intersections with the = different intersections of old profiles. A complete explosion of operating points resulting in increased cost and h= igher risk of bugs and misinterpretations causing interoperability problems= .

 <= /p>

I think profile-compatibility-indi= cator is very useful as a bitstream property (sprop parameter). By using that, the same payload type can be accepted by answerer A (suppor= ting profile pA) and answerer B (supporting profile pB).<= /p>

 = ;

Let me express the altern= atives I see for profile-compatibility-indi= cator, in my order of preference:

1.&nbs= p;      Making it a sprop= parameter only (expressing a property of the bitstream)<= /p>

2.&nbs= p;      Making 2 paramete= rs: one sprop parameter AND one receiver parameter that can be used to express that the decoder supports multiple (full) profiles = (similar to the cited text below from the latest draft of the payload spec)=

3.&nbs= p;      Making it a singl= e parameter used both for expressing that a bitstream conforms to multiple profiles and that a decoder only supports the interse= ction of all the indicated profiles (this is what you are proposing, right?= ).

 <= /p>

I would strongly prefer i= f option 3 could be avoided for the above mentioned reason. If not, I guess we just have to ensure that all SDOs that uses the HEVC pa= yload spec does not use this mechanism J. See some further discussion inline below.

 <= /p>

Best Regards Jonatan=

 <= /p>

 <= /p>

From: Yago San= chez [mailto:yago.sanchez@hhi.fraunhofer.de]
Sent: den 17 maj 2014 12:06
To: Wang, Ye-Kui
Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; draft-iet= f-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi, Ye-Kui, Jonatan,all,

 

Just to make clear my opinion on this topic, I am he= re with Ye-Kui and Stephan as already expressed previously in this thread. = Desirable or not, profile_compatibility_indicator allows for indicating int= ersection of profiles as expressed in the item b) in the contribution mentioned in the email below. Whether t= he intersections will get a profile_idc or not cannot be known beforehand a= nd might not since we have profile_compatibility_flag for that purpose. Sai= d that still I think the argument here is that if HEVC allows for it we should support it in the payload for= mat.

 <= /p>

[JS] As mentioned above; = there is a HUGE difference between bitstreams that conforms to multiple profiles and decoders that only supports intersections of mult= iple profiles. The HEVC spec does not allow the latter. If we introduce the= concept of decoders conforming to intersection of profiles in the HEVC pay= load format that would be something which does not have any correspondence in the HEVC spec.=

 

Best regards,

Yago

 

 

On 16 May 2014, at 20:20, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:<= o:p>



Hi Jonatan,

 

Thanks for responding to = my request for comments – I really appreciate (even though you are no= t supporting my opinion <= /span>= J).=

 

Frankly, I think the obse= rvations you pointed out below do not support the opinion you expressed (Se= e more detailed replies inline below.).

 

What are being discussed = here, as Stephan accurately pointed out, is whether to narrow down the numb= er of interoperability points negotiable using O/A negotiation, by intentionally disabling a mechanism that was expressly included for pur= poses that might happen and that have happened.  To do (the narrowing = down) or not to do, that is the question. And the key point to dertermine t= he answer to the question is whether THAT (the intersection way of profiling) might happen. Unless it is fairly= sure that THAT won’t happen, we ought to provide the support of THAT= in the payload format.

[JS] Given that the profi= les in  HEVC version 1 are nicely “onion shaped” (which they were not in h.264) and given that there are 48 constraint flags (comp= ared to the 8 in h.264) I am personally fairly sure THAT won’t happen= , but apparently you are not J.

 

The facts that THAT did h= appened for H.264 and that whether it would happen is not controlled by IET= F, but by other organizations, more than one of them, I’d say that we are far from being fairly sure that THAT won’t happen. A= gain, if the narrowing is done and if THAT occurs, then an extension to the= payload format needs to be specified to add the support of this case and t= he design would be the same as what we have now, except that it introduces new IOP issue on the payload format le= vel (due to two incompatible versions of the payload format), and if the na= rrowing is not done and if THAT does not occur, all the hypothetical issues= won’t happen anyway.

[JS] If THAT does occur s= ometime in the future, there are multiple options for how it could be handled in the payload format (depending on how specific the c= ase for which it occurs is). I would much rather see some inconvenience for= that specific case then, compared to this burdensome mechanism.

 <= /p>

BR, YK

 

From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Friday, May = 16, 2014 2:31 AM
To: Stephan Wenger= ; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: RE: [payl= oad] Comments on draft-ietf-payload-rtp-h265-02

 

Dear Ye-Ku= i, Stefan, all,

 

Let me exp= ress my opinion on this topic (since you explicitly asked for more opinions= ). I do represent the same company as Magnus, but (in contrast to Magnus) I was also part of the discussions on how to define the profile= s in HEVC version 1. I share Magnus' view that it would be very unfortunate= if the payload format allows for definitions of sub-profiles using profile= -compatibility-indicator. The purpose of the profile_compatibility_flags is very clear in the contribution that = proposed them, JCTVC-I0499 (htt= p://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761):

"We need a labelling scheme that:

a)=       allows the committee to introduce new profiles, and older systems be able to work= out which bitstreams they can decode when those new profiles are fully sub= sets of older existing profiles, even when they do not recognize the new pr= ofile identifier;

b)=       allows bitstreams which don't use all the features of any given profile, and are = as a consequence compatible with more than one, to be labelled with so that= it's possible to deduce all the profiles that the bitstream is compatible = with (the ones that don't automatically follow from the nesting structure).

"

 

[YK]: Item= b above talking about exactly encoding a bitstream using an intersection o= f multiple profiles, which is exactly the point we are taking about.

 

If there i= s an intersection between two profiles that does make sense and is useful t= o the industry it is reasonable to assume that ITU/ISO/IEC would define a new profile corresponding to that intersection (just as was= done with Constrained Baseline Profile in h.264).=

 

[YK]: Defi= ning a new profile does not necessarily means using of a new value of the p= rofile-id for indicating the new profile, just as was done with the Constrained Baseline profile of H.264.

 

And in HEV= C, the profile_compatibility_flags provides a mechanism for introducing a n= ew profile, with a new profile_idc while still being able to indicate conformance to one or more of the old profiles (a mechanism th= at did not exist in h.264).

 

[YK]: The = mechanism of profile_compatibility_flags is very similar to what H.264 has,= with the only difference been that in HEVC there are 32 of these flags and 5-bit of profile-id, while in H.264 there are less bits of= these flags and 8 bits of profile-id.

[JS] There is also the di= fference that the semantics of all the profile_compatibility_flags in HEVC are defined already in version 1. In h.264 there were only 3 bits = defined in version 1 and the rest were reserved bits thus making them more = comparable to the flags called “interop-constraints” in the HEV= C payload draft.

 

However, i= t is worth noting that the way the Range Extension profiles have been defin= ed in the second (soon to be released) version of HEVC, the functionality of profile_compatibility_flag is already broken. There are 1= 9 new profiles in there but only one profile_idc is used to identify them. = Thus it is not possible in the same bitstream to indicate that it conforms = to two different of these 19 profiles.

 

[YK]: Which functionality= of  profile_compatibility_flag as specified in the HEVC spec is broke= n? I guess it is just the functionality of profile_compatibility_flag in your understanding is broken = ;J We should not assume anything more than said in the spec. I don’t see a= nything written in the spec is broken, even though it was a little surprise= to me too when seeing the definition of the Range Extension profiles (as I= did not expect to use the interop-constraints bits for profile definition either). The fact that the interop-constraints= bits have been used in profile definition proves more that the way of prof= ile signalling is not controlled by us, and we should NOT preclude the supp= ort of such profile signalling. Fortunately, the mechanism we currently specify in the payload draft, wher= e interop-constraints is one of the configuration parameters required for s= ymmetric use in O/A, works with this.=

[JS] It appears broken to= me:

general_profile_compatibility_flag[ j&nb= sp;] equal to 1, when general_profile_space is equal to 0, indicates that t= he CVS conforms to the profile indicated by general_profile_idc equal to i = as specified in Annex A.

How should you interpret = “the CVS conforms to the profile indicated by general_profile_= idc equal to i” when i equals 4? Which is = 220;the profile” in this case?

 

Now to con= nect back to the example you mentioned, Ye-Kui, on May 5: “There can be still be a point to offer profile-compatibility-indicator in this c= ase. For example, it is possible that the decoder of the offerer only suppo= rts the common tools of profiles A and B, while it does not support either = full profile A or full profile B.

1.=        I don’t think this is desirable.=

[YK]: As I said earlier i= n replies to Magnus, I do share the concern either, but this is not up to u= s – let me repeat again.

 

2.=        Within the profiles defined in “format range extension” (~90% of the = profiles defined so far) this is not possible.

[YK]: There is no such pr= inciple or functionality that the example must be possible for all cases. A= s long as it is possible for any two of the 32 flags, the payload format should provide support. Otherwise, as I said earlier, we as= the payload format designers are only introducing more IOP issues in the f= uture once this is done (by other organizations).<= /o:p>

 

3.=        When I read the latest HEVC payload format draft, I don’t find anything s= upporting that kind of usage of = profile-compatibili= ty-indicator. On the contrary:

 

         A decoder conforming =
to a certain profile may
         be able to decode bit=
streams conforming to other profiles.
         The profile-compatibi=
lity-indicator provides exact information
         of the ability of a d=
ecoder conforming to a certain profile to
         decode bitstreams con=
forming to another profile.  More
         concretely, if the pr=
ofile compatibility flag corresponding to
         the profile a decoder=
 conforms to is set, then the decoder is
         able to decode any bi=
tstream with the flag set, irrespective
         of the profile the bi=
tstream conforms to (provided that the
         decoder supports the =
highest level of the bitstream).

 

[YK] Due to the newly int= roduced signalling of Range Extensions profiles using one profile-id value = in combination with interop-constraints, the above description of profile-compatibility-indicator needs to be updated. I had planned to d= o this in the next version. But again, here we need to specify the text to = align with whatever is specified in the HEVC specification.

 

I can see the benefit in = using the interop-constraints to express constraints that applies to well-d= efined profiles (both from a decoder and encoder point of view). However, using profile-compatibility-indicator to let decoders crea= te ad-hoc on the fly “sub-profiles” of an arbitrary number of d= efined profiles serves IMO no purpose and is simply a misuse of the<= span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">profile_compatibility_flags.

 

[YK] See above.

 

Best Regards Jonatan

 

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Steph= an Wenger
Sent: den 13 maj 2014 19:38
To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft= -ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi,

I=B9m one of the co-authors.=

To make one thing clear from the outset= : I=B9m one who says that any and all options of a given payload necessaril= y need always to be supported by a RTP payload format.  Sometimes, it=B9s IMO completely OK to forgo the support of an odd mechanism that=B9s= not required or useful for the application =B3payload over the Internet us= ing RTP=B2.

That said, the case here is different.&= nbsp; What we have here is a request (by

Magnus) to narrow down the number of in= teroperability points negotiable using O/A negotiation, by intentionally di= sabling a mechanism that was expressly included for purposes just like this.  There was considerable discussion in JCT-VC, MPEG, a= nd VCEG about the subject.  I would say it was one of the key drivers,= but my view may be a bit one-sided.  However, it was discussed more t= han once.  The front lines were often between the hardware folks (who would like to have as few interop points as possible) = and the software people (who would prefer to have a finer granularity, to b= etter suit individual application needs).  The resulting compromise ne= cessarily made no one completely happy, but everyone could live with it.

Ye-Kui is right: it=B9s not the IETF=B9= s job to rehash these profiling architecture discussions/decisions.

Thanks for your consideration,

Stephan

 

On 13.5.14, 9:57, "Wang, Ye-Kui&qu= ot; <yekuiw@qti.qualcomm.com> wrote:=

 

>Magnus,

> 

>I understand your arguments too. Yo= ur main worry seems to be about the

>HEVC profiling fracturing the marke= t and reducing the interoperability

>of HEVC, which I do share. However,= the key point here is that, that is

>not up to us, it is controlled by o= ther organizations. If we go ahead

>to disallow the support of that in = the HEVC payload format, that does

>not mean we would successfully prev= ent that from happening in

>MPEG/ITU-T and other application st= andard organizations - and if that

>happens, then an extension to the p= ayload format would need to be

>specified, which might introduce mo= re IOP issues even on the RTP encapsulation level for HEVC.

> 

>I fully agree that some more opinio= ns from others would be very helpful.

> 

>Please, whoever cares about this dr= aft and cares about using HEVC with

>RTP, say your opinion. We really ne= ed to have this document finalized

>soon for HEVC deployment!!!

> 

>See some other detailed replies inl= ine below too.

> 

>BR, YK

> 

>-----Original Message-----

>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]

>Sent: Tuesday, May 13, 2014 7:31 AM=

>To: Wang, Ye-Kui; Yago Sanchez=

>Subject: Re: [payload] Comments on = draft-ietf-payload-rtp-h265-02

> 

>Ye-Kui and WG,

> 

>Please see inline. I think we need = input from more people into this

>question to make progress.

> 

> 

>On 2014-05-06 16:56, Wang, Ye-Kui w= rote:

>> Magnus,

>> 

>> I think the only key different= understanding between us now is the

>> following: Whether to assume t= hat a decoder does not fully support

>> any profile indicated by profi= le-id (what you called "sub-profile", e.g.

>> only support the common tools = of two or more profiles).

>> 

>> Once we converge here, it shou= ld be easy to derive that text changes

>> should be made. Thus, let me f= ocus on this in this email.

>> 

>> Your opinion is obvious and st= rong - don't go into that direction.

>> 

>> My opinion is strong too - we = do need to go into that direction,

>> because of the following reaso= ns:

>> 

>> - The ITU-T/MPEG control how t= o use the bits of profile-id and

>> profile-compatibility-indicato= r in the video coding specifications.

>> It is simply possible that a n= ew profile can be defined and indicated

>> without using a new value of p= rofile-id, but indicated as conforming

>> to two profiles. This happened= for AVC for the Constrained Baseline

>> profile as I explained. Also, = in the recently finalized HEVC Range

>> Extensions spec (see here:

>> /

>> JCTVC-Q1005-v4.zip),

>> 19 new profiles have been defi= ned, indicated by only one value of

>> profile-id and some values of = bits of the interop-constraints field

>> (Note, not the profile-compati= bility-indicator field).

> 

>Yes this may happen, but jumping on= to this now, do in fact create a

>tool where anyone can attempt to cr= eate new interoperability points by

>selecting an intersection between p= rofiles. That doesn't benefit

>interoperability, it instead fractu= res the market and works against the

>purpose of the profiles in the firs= t place.

> 

>[YK]: Agreed - but again that is no= t up to us, it is controlled by

>other SDOs (which are in turn drive= n by the markets).

> 

>Secondly, in relation to H.264 cons= trained baseline, that was created

>using constraint bits, a concept th= at already is part of the

>specification, it might be defined = as the intersection of two profiles,

>but the signalling is done accordin= g to one profile with a specific bit

>set. Just like the HEVC Range Exten= sion profiles.

> 

>[YK]: Why the signalling is differe= nt? Herein you also use a profile-id

>value with a specific bit set.=

> 

>However, to me it appears that when= one selected the structure for HEVC

>Range Extensions one forgot about t= he profile-compatibility-indicator

>as it is not possible to signal com= patibility across the main

>directions in the range extension p= rofiles. The main directions are

>within themselves nicely onion shap= ed, but the compatibility between

>them does not appear to have been w= ell considered.

> 

>[YK]: I was not involved in the def= inition of the structure for HEVC

>Range Extensions - so no comment he= re.

> 

>> 

>> - Application standards organi= zations, e.g. 3GPP, may require

>> "sub-profile" capabi= lity for decoders. Again, AVC Constrained

>> Baseline profile is an example= - Magnus you should know this much

>> better than many others.<= /o:p>

> 

>Yes, however I think it is usually = bad for interoperability. And HEVC

>does not appear to be in the same p= osition that H.264 was when it was

>just finished. Thus, I expect the i= ssues are being different.

> 

>[YK]: True - but on the other hand,= that was driven by the market too,

>and they wanted that for interopera= bility for that particular capability.

>Here the issue is not about what wa= s defined already in HEVC, but what

>could be done in the future. When R= FC 3984 was finalized, the

>Constrained Baseline profile was no= t available yet. So, right now, the

>situation is the same. Unless we ca= n surely know similar things won't

>happen, we should follow the approa= ch in RFC 3984, i.e. to allow for

>such intersection of two more profi= les. Nobody can be sure right now

>for what could happen in the future= , at least for this issue.

> 

>> 

>> Thus, when defining the HEVC R= TP payload here, I don't think we can

>> ignore the above. Rather, we m= ust go into the direction of

>> "sub-profile".<= /o:p>

> 

>I understand your arguments. What i= s required is highly dependent on

>what will be done with future profi= ling of HEVC. I see enabling the

>possibility to intersect any choice= of profiles do create an potential

>for fracturing the market and reduc= ing the interoperability of HEVC.

> 

>[YK]: Again, agree in general, but = again that is not controlled by us.

> 

>Cheers

> 

>Magnus Westerlund=

> 

>-----------------------------------= -----------------------------------

>Services, Media and Network feature= s, Ericsson Research EAB/TXM

>-----------------------------------= -----------------------------------

>Ericsson AB    =              | = Phone  +46 10 7148287

>F=E4r=F6gatan 6   &n= bsp;            = ; | Mobile +46 73 0949079

>SE-164 80 Stockholm, Sweden | mailt= o: magnus.westerlund@ericsson.com

>-----------------------------------= -----------------------------------

> 

>___________________________________= ____________

>payload mailing list

 

_______________________________________= ________

payload mailing list<= /p>

 

 

--_000_634D3B5D82E3214DA9B6A36D5F50DB2322DC18ESESSMB109ericsso_-- From nobody Mon May 19 06:28:58 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 9CAD81A005C for ; Mon, 19 May 2014 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 5rtnW_4rgVYP for ; Mon, 19 May 2014 06:28:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FF01A005A for ; Mon, 19 May 2014 06:28:47 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-83-537a070d38c1 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.3A.04199.D070A735; Mon, 19 May 2014 15:28:46 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.10]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Mon, 19 May 2014 15:28:45 +0200 From: Jonatan Samuelsson To: Yago Sanchez Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqvCW5lJ2j202VpYpONAh1lJsqWUMAgBWA2bCAA/L4gIAAwseAgAMu8vA= Date: Mon, 19 May 2014 13:28:44 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB23231D6F@ESESSMB109.ericsson.se> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@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_634D3B5D82E3214DA9B6A36D5F50DB23231D6FESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RpePvSrYYGaZxaWLZ5ksJh1fy2bx ZM0xZgdmj+mnFjN7LFnyk8lj0dRnjAHMUVw2Kak5mWWpRfp2CVwZ69doFkzazVqxvHcRawPj sccsXYycHBICJhIvW6dA2WISF+6tZ+ti5OIQEjjKKLHv/l1mCGcxo8TU7YuBMhwcbAJWEt9f RIA0iAgYSixZ/ZgdxGYWCJV4tK6BFaREWMBV4vQEZhBTRMBN4soRRYhqP4m5R/8wg9gsAqoS N+9tYAOxeQW8JS7OusAIsekCk8S7Wc/ARnICjbm95CDYbYwCshL3v99jgVglLnHryXwmiJsF JJbsOc8MYYtKvHz8jxXCVpRof9rACFGfL3H77SNGiGWCEidnPmGZwCg6C8moWUjKZiEpg4jr SCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAiPw 4JbfBjsYXz53PMQowMGoxMO7ILUyWIg1say4MvcQozQHi5I47+1dpcFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGCdX8+tXLzY5wPiX+bHMxb0z3H7PW/Pe9cW/1G6DqnVyqxrzYg5fnXVL Va2E48ryjNsrOw83bwjd81KExUTCclar+NucblsHo57DUa5ffCzuSb1WlavfNCk5my/Kdf2V VueUiVaBzZdK/MLb3n7Ie5K1QkVkz5+uqf1xLK75n1+vmrrk6pn5vUosxRmJhlrMRcWJALed NCqhAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/payload/upPkLMcKnA4cQFIwfoj4ivo-JzU Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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, 19 May 2014 13:28:56 -0000 --_000_634D3B5D82E3214DA9B6A36D5F50DB23231D6FESESSMB109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ye-Kui, Yago, all, Let me start with some further motivation for why I think it would be usefu= l to include MD5 information in RPSI. I see two categories of "errors" that= can cause encoder and decoder MD5 mismatch: 1. External causes. It is possible that a bit-error in a bitstream is= not detected during decoding, causing a decoded picture to have different = values compared to the reconstructed picture at the encoder. It is also pos= sible that decoded pictures or reconstructed pictures are stored on a media= that is not 100% reliable (e.g. due to malfunctioning hardware). Having a = single value wrong in a reference picture can quite fast propagate to sever= e visual artifacts due to temporal prediction. 2. Implementation causes. Each HEVC encoder and decoder implementatio= n (both hardware and software) is an interpretation of the more than 300 pa= ges long HEVC specification and there is always the risk that there are som= e parts of the specification interpreted differently. The reference encoder= and decoder (HM) can perform guidance here but HM is far from "complete" i= n the sense that it can test all encoder (bitstream) features fully or corr= ectly report all illegal bitstreams to be non-conforming. There is also the= risk that an implementation contains bugs that appear only for very rare c= ases. Our motivation for including MD5 in RPSI is primarily based on the second c= ategory (although the first category should not be ignored). It is true tha= t you would ideally want all deployed encoders and decoders to be fully sta= ndards compliant with no exceptions. However, history has taught us that th= is is unfortunately not the case. For h.264, even in the reference software= JM, bugs have been found several years after h.264 was standardized (examp= le: https://ipbt.hhi.fraunhofer.de/mantis/view.php?id=3D193). And when x264= started using weighted prediction several decoders silently accepted those= bitstreams while displaying erroneous video (http://x264dev.multimedia.cx/= archives/212#more-212). I would not expect HEVC with all its different poss= ible combinations of block sizes and new coding tools to be easier to imple= ment correct compared to h.264. We believe it would be very useful to provide better tools for discovering = incompatibility issues and be able to automatically trigger events based on= the detection of MD5 mismatch. It could for example include: - Taking immediate action to solve the problem such as sending an = IDR picture - Change the configuration of a session with the hope of finding a= configuration which does not cause encoder-decoder problems (e.g. by using= a more basic set of tools or by switching profie/level) - Gather statistics for which clients does not work with which cli= ents and under which circumstances See further comments inline. Best Regards Jonatan From: Yago Sanchez [mailto:yago.sanchez@hhi.fraunhofer.de] Sent: den 17 maj 2014 12:47 To: Jonatan Samuelsson Cc: payload@ietf.org; Wang, Ye-Kui Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Hi Jonatan, Similar to Ye-Kui's comments, on the inclusion of MD5 in the RPSI, it is no= t clear to me why this could be useful. When talking about "incompatibility= " about encoder and decoder this would mean that one of them is not properl= y working, i.e. it does not fully conform to the standard. In such a case I= personally do not think that this is an issue needed to be solved with the= RPSI but at the development phase of the encoder/decoder. I would assume h= ere that both encoder and decoder are conforming to the standard. For other cases, I cannot think of any case of a picture being "correctly" = decoded, while being a mismatch between encoder and decoder. Is there any c= ase where this happens that I am missing? Best regards, Yago On 17 May 2014, at 01:09, Wang, Ye-Kui > wrote: Hi Jonatan, Thanks for reviewing the new version. Please see my replies inline below, i= ncluding some comments on the two newly proposed features related to RPSI. = For these two features, let's first discuss whether to have them in this pa= yload format document before going into the details in text proposed in ano= ther email. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Wednesday, May 14, 2014 1:58 AM To: Wang, Ye-Kui; payload@ietf.org Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' [YK]: Thanks! To be done in the next version. B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. [YK]: Thanks! To be done in the next version. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? [YK]: The intended use of the SLI message as specified is to indicate the l= oss of CTBs regardless of whether and how slices are in use and whether and= how tiles are in use. The semantics of the "Number" field is clear to me t= oo - why it is not clear? Note that the semantics of slice_segment_address = in the HEVC spec itself is also in CTB raster scan order, regardless of whe= ther and how tiles are in use. Personally I'd prefer to keep the semantics = of SLI to be generic, and also aligned with the semantics of slice_segment_= address in the HEVC spec. [JS] I guess I'm missing something here. Let's look at a very simple examp= le of a picture of 4x3 CTBs with two tiles, one to the right and one to the= left, each signaled in a separate slice. The CTB addresses in CTB raster scan order of the picture is: ------------- | 0| 1| 2| 3| | 4| 5| 6| 7| | 8| 9|10|11| ------------- With two tiles layed out as follows: ------------- | A| A| B| B| | A| A| B| B| | A| A| B| B| ------------- the CTB address in tile scan is: ------------- | 0| 1| 6| 7| | 2| 3| 8| 9| | 4| 5|10|11| ------------- Now, if the second tile (second slice) is lost. I should obviously set the = value of "First" to 2 (since that is the CTB address in CTB raster scan ord= er of the picture), but what value should I set for "Number"? I would like = to set it to 6 since that is the number of CTBs that are lost. But if I cou= nt in CTB raster scan order of the picture I get to 10 before I reach the l= ast CTB that was lost. This means some CTBs needs to be indicated as lost e= ven though they were not. Or do I misinterpret the following sentence: The subfield "Number" MUST be set to the number of consecutive lost CTBs, a= gain in CTB raster scan order of a picture. D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? [YK]: To me this change would make the semantics a lot less clear and the m= essage less useful. Also, each dependent slice segment has slice_segment_ad= dress signalled too, while FUs are supposed to be assembled before sending = to the decoder - thus from the decoder point of view FUs do not need to be = considered. [JS] Sending incomplete FUs to the decoder can significantly improve error = concealment algorithms. However, this is just a minor comment from my side.= It is anyway up to the receiver to decide how much data is reported to be = lost regardless of how much it actually received. E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsbconsists of = fewer than 6 bits. [YK]: Good point. To be done in the next version unless the discussion lead= s into a different conclusion. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' [YK]: To be done in the next version. Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. [YK]: A few points to discuss. G.1: Is it backward compatible to RFC 4585 t= o use one RPSI message to convey more than one reference picture? Would it = be better to define a new message for this purpose if it is deemed useful? [JS] I don't see anything in RFC 4585 that would prohibit including more th= an one reference picture in the "Native RPSI bit string defined per codec" = field. G.2: The concept applies to any video codec that supports multiple referenc= e pictures, is not specific to HEVC, thus would it be better if this is dis= cussed as a generic mechanism, similarly as the SPLI message included in dr= aft-ietf-payload-rtp-h265-01 but dropped later for the very reason? [JS] This would be an option but I don't think it's needed since RPSI in RF= C 4585 is already generic enough to govern this also for other codecs. G.3: On the usefulness of this functionality seems to be unclear to me eith= er. If the last correct picture before an error occurs is known, it is also= known that the reference pictures of the last correct pictures are correct= , thus the encoder can anyway choose to use one or more of these pictures, = when available, for encoding the next picture. Thus, it might be sufficient= just to slightly change the semantics of the RPLI message, to say that the= encoder can choose to use one or more of the identified picture and its re= ference pictures for encoding the next picture. [JS] The strength of RPSI in my opinion is that it can be used to recover f= rom errors that is not a simple loss-of-a-NAL-unit-error (for this case gen= eric NACK, SLI and PLI are probably better suited). An RPSI message can be= used to try to recover from any type of divergence between encoder and dec= oder without the need of a complete reset (i.e. through IDR picture). For s= uch scenarios it might be very difficult to identify exactly which referenc= e pictures are still available (and which of them are correct, as addressed= by suggestion H. below) and it would be dangerous to assume that all refer= ence pictures of one specific reference pictures will be available. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be correct 2: The MD5 of the reference picture is incorrect (i.e. do NOT us= e for reference) 3: The MD5 is included in the RPSI message (directly following t= he PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. [YK]: Firstly, in my understanding, the decoder picture hash SEI message is= very useful for debugging in development of encoder and decoder implementa= tions, as used by the JCT-VC for the development of the HEVC reference soft= ware, and it is intended for use with that purpose. Using of it for error r= esilience in communications is an overkill to me. For example, you would ne= ed 48 bytes to signal the MD5 hash for each picture. [JS] It would still be optional to include those 48 bytes of MD5 info, and = if they can be used to detect errors that would otherwise not be detected, = then 48 bytes per reference picture does not sound much compared to the typ= ical bitrates for video streams. Secondly, it is architecturally incorrect to couple this with the RPSI feed= back message, as the picture identified is supposed to be correctly decoded= by the decoder and the purpose of the message is to request the encoder to= use that picture for encoding of the next picture, [JS] You are right that the identified picture(s) is supposed to be correct= . The proposed usage of MD5 provides a mechanism for verifying that a pictu= re is actually correct. thus why would you even indicate a picture that is incorrect using an RPSI = feedback message? [JS] See further motivation at the top of this email. That information can = be used to identify incompatibility issues for immediate actions (change co= nfiguration) and long-term actions (identify non-conforming encoders/decode= rs). In scenarios where Full Intra reset is not feasible an encoder may use= this information to perform gradual decoder refresh until the encoder and = decoder have been verified to have identical reference pictures in their bu= ffers. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 Gro= up of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ 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 --_000_634D3B5D82E3214DA9B6A36D5F50DB23231D6FESESSMB109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Ye-Kui, Yago, all,

 <= /p>

Let me start with some fu= rther motivation for why I think it would be useful to include MD5 informat= ion in RPSI. I see two categories of “errors” that can cause encoder and decoder MD5 mismatch:

1.&nbs= p;      External causes. = It is possible that a bit-error in a bitstream is not detected during decod= ing, causing a decoded picture to have different values compared to the reconstructed picture at the encoder. It is also possible = that decoded pictures or reconstructed pictures are stored on a media that = is not 100% reliable (e.g. due to malfunctioning hardware). Having a single= value wrong in a reference picture can quite fast propagate to severe visual artifacts due to temporal predic= tion.

2.&nbs= p;      Implementation ca= uses. Each HEVC encoder and decoder implementation (both hardware and softw= are) is an interpretation of the more than 300 pages long HEVC specification and there is always the risk that there are some parts = of the specification interpreted differently. The reference encoder and dec= oder (HM) can perform guidance here but HM is far from “complete̶= 1; in the sense that it can test all encoder (bitstream) features fully or correctly report all illegal bitstreams to b= e non-conforming. There is also the risk that an implementation contains bu= gs that appear only for very rare cases.

 <= /p>

Our motivation for includ= ing MD5 in RPSI is primarily based on the second category (although the fir= st category should not be ignored). It is true that you would ideally want all deployed encoders and decoders to be fully standard= s compliant with no exceptions. However, history has taught us that this is= unfortunately not the case. For h.264, even in the reference software JM, = bugs have been found several years after h.264 was standardized (example: https://ipbt.hhi.fraunhofer.de/mantis/view.ph= p?id=3D193). And when x264 started using weighted prediction sev= eral decoders silently accepted those bitstreams while displaying erroneous= video (http://x264dev.multimedia.cx/archives/212#more-21= 2). I would not expect HEVC with all its different possible combinations of bl= ock sizes and new coding tools to be easier to implement correct compared t= o h.264.

 <= /p>

We believe it would be ve= ry useful to provide better tools for discovering incompatibility issues an= d be able to automatically trigger events based on the detection of MD5 mismatch. It could for example include:

- = ;         Taking immediate = action to solve the problem such as sending an IDR picture

- = ;         Change the config= uration of a session with the hope of finding a configuration which does no= t cause encoder-decoder problems (e.g. by using a more basic set of tools or by switching profie/level)

- = ;         Gather statistics= for which clients does not work with which clients and under which circums= tances

 <= /p>

See further comments inli= ne.

 <= /p>

Best Regards Jonatan=

 <= /p>

From: Yago San= chez [mailto:yago.sanchez@hhi.fraunhofer.de]
Sent: den 17 maj 2014 12:47
To: Jonatan Samuelsson
Cc: payload@ietf.org; Wang, Ye-Kui
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Hi Jonatan, 

 

Similar to Ye-Kui’s comments, on the inclusion= of MD5 in the RPSI, it is not clear to me why this could be useful. When t= alking about “incompatibility” about encoder and decoder this w= ould mean that one of them is not properly working, i.e. it does not fully conform to the standard. In such a case I personall= y do not think that this is an issue needed to be solved with the RPSI but = at the development phase of the encoder/decoder. I would assume here that b= oth encoder and decoder are conforming to the standard.

 

For other cases, I cannot think of any case of a pic= ture being “correctly” decoded, while being a mismatch between = encoder and decoder. Is there any case where this happens that I am missing= ?

 

Best regards,

Yago

 

On 17 May 2014, at 01:09, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:<= o:p>



Hi Jonatan,

 <= /p>

Thanks for reviewing the = new version. Please see my replies inline below, including some comments on= the two newly proposed features related to RPSI. For these two features, let’s first discuss whether to have them in this paylo= ad format document before going into the details in text proposed in anothe= r email.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Wednesday, M= ay 14, 2014 1:58 AM
To: Wang, Ye-Kui;<= span class=3D"apple-converted-space"> payload@ietf.org
Subject: RE: [payl= oad] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear Ye-Kui, editors, all,<= /o:p>

Thanks for improving the draft and maki= ng the new version available. I read through the new section 8 in the lates= t draft, in which more feedback features have been added (which I think is very good). I have some minor comments and then some sug= gestions for improving the RPSI signalling. Compared to earlier standards, = HEVC contains a new very useful SEI message that can be used to check integ= rity and correctness of decoded pictures and thereby detect errors that are not necessarily due to packet = losses: Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also in t= he RTP payload format for HEVC in order to make implementations even more robust.

First some minor comments:<= /o:p>

In 8.1:

A. Remove one instance of 'the loss of' in the sentence: ' <= span style=3D"font-size:10.0pt;font-family:"Courier New"">As spec= ified in RFC 4585 section 6.3.1, the reception of a picture loss indication= by a media sender indicates the loss of "the loss of an undefined amount of coded video data belonging to one or more pictur= es.".'

 <= /p>

[YK]: Thanks! To be done = in the next version.

B. The 'BE' in 'SHOULD BE' should not b= e using CAPITAL LETTERS.

[YK]: Thanks! To be done = in the next version.

 <= /p>

In 8.2:

C. Regarding 'the loss of a number of = Coded Tree Blocks (CTBs) in CTB raster scan order of a picture.'. When tiles are used, the loss of a slice does typically not result in lost= CTBs in raster scan order of the picture. The text does not describe how t= o calculate the "Number" field for this case. Wouldn't it be bett= er to use 'tile scan' in order to correctly identify what part of the = picture was lost?

 <= /p>

[YK]: The intended use of= the SLI message as specified is to indicate the loss of CTBs regardless of= whether and how slices are in use and whether and how tiles are in use. The semantics of the “Number” field is clear to me= too – why it is not clear? Note that the semantics of slice_segment_= address in the HEVC spec itself is also in CTB raster scan order, regardles= s of whether and how tiles are in use. Personally I’d prefer to keep the semantics of SLI to be generic, and also alig= ned with the semantics of slice_segment_address in the HEVC spec.

[JS] I guess I’m&nb= sp; missing something here. Let’s look at a very simple example of a = picture of 4x3 CTBs with two tiles, one to the right and one to the left, each signaled in a separate slice.

The CTB addresses in CTB = raster scan order of the picture is:

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

| 0| 1| 2| 3|

| 4| 5| 6| 7|

| 8| 9|10|11|

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

With two tiles layed out = as follows:

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

| A| A| B| B|

| A| A| B| B|

| A| A| B| B|

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

the CTB address in tile s= can is:

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

| 0| 1| 6| 7|

| 2| 3| 8| 9|

| 4| 5|10|11|

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

Now, if the second tile (= second slice) is lost. I should obviously set the value of “FirstR= 21; to 2 (since that is the CTB address in CTB raster scan order of the picture),= but what value should I set for “Number”? I would like to set = it to 6 since that is the number of CTBs that are lost. But if I count in CTB raster scan order of the picture I get to 10 before I reach the las= t CTB that was lost. This means some CTBs needs to be indicated as lost eve= n though they were not. Or do I misinterpret the following sentence:=

The subfield "Number&= quot; MUST be set to the number of consecutive lost CTBs, again in CTB rast= er scan order of a picture.

D. Regarding 'the subfield "First= " MUST be set to the CTB address of the first lost CTB'. Wouldn't it be better to require "First" to= be set to a number that is lower than or equal to the CTB address of the f= irst lost CTB, since it might be difficult to deduce the exact CTB address of t= he first lost CTB in the case of loss of  dependent slices and/or frag= mentation units?

 <= /p>

[YK]: To me this change w= ould make the semantics a lot less clear and the message less useful. Also,= each dependent slice segment has slice_segment_address signalled too, while FUs are supposed to be assembled before sending to th= e decoder – thus from the decoder point of view FUs do not need to be= considered.

[JS] Sending incomplete F= Us to the decoder can significantly improve error concealment algorithms. H= owever, this is just a minor comment from my side. It is anyway up to the receiver to decide how much data is reported to be lost r= egardless of how much it actually received.

E. Regarding 'The subfield "Pictu= reID" MUST  be  set  to  the  6  least s= ignificant  bits  of  a  binary representation  of  the  value  of slice_pic_order_cnt_lsb  of  t= he picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of  = ;slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_lsbcon= sists of  fewer than 6 bits.

[YK]: Good point. To be d= one in the next version unless the discussion leads into a different conclu= sion.

 <= /p>

F. Regarding the sentence: 'In many ca= ses, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncor= rupted regions of the picture through motion compensation, and reference pi= cture selection can also be used to "clean up" the corrupted pict= ure, which is usually more efficient and less likely to generate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: = ''

[YK]: To be done in the n= ext version.

 <= /p>

Regarding RPSI (section 8.3) I would li= ke to propose the following changes:

G. Add the possibility to include more = than one reference picture in the RPSI message so that the encoder can sele= ct to use one or more of the pictures included in RPSI message. Using multiple pictures for reference is a key feature in HEVC which subst= antially improves coding efficiency. In the case where multiple earlier pic= tures are available for reference it is beneficial to let the encoder decid= e which one(s) to use for reference instead of relying on the decoder to make that selection.

[YK]: A few points to dis= cuss. G.1: Is it backward compatible to RFC 4585 to use one RPSI message to= convey more than one reference picture? Would it be better to define a new message for this purpose if it is deemed useful?

[JS] I don’t see an= ything in RFC 4585 that would prohibit including more than one reference pi= cture in the "Native RPSI bit string defined per codec" field.

G.2: The concept applies = to any video codec that supports multiple reference pictures, is not specif= ic to HEVC, thus would it be better if this is discussed as a generic mechanism, similarly as the SPLI message included in draft-ie= tf-payload-rtp-h265-01 but dropped later for the very reason?

[JS] This would be an opt= ion but I don’t think it’s needed since RPSI in RFC 4585 is alr= eady generic enough to govern this also for other codecs.

G.3: On the usefulness of= this functionality seems to be unclear to me either. If the last correct p= icture before an error occurs is known, it is also known that the reference pictures of the last correct pictures are correct, thus= the encoder can anyway choose to use one or more of these pictures, when a= vailable, for encoding the next picture. Thus, it might be sufficient just = to slightly change the semantics of the RPLI message, to say that the encoder can choose to use one or more= of the identified picture and its reference pictures for encoding the next= picture.

[JS] The strength of RPSI= in my opinion is that it can be used to recover from errors that is not a = simple loss-of-a-NAL-unit-error (for this case generic NACK,  SLI and PLI are probably better suited). An RPSI message can be used= to try to recover from any type of divergence between encoder and decoder = without the need of a complete reset (i.e. through IDR picture). For such s= cenarios it might be very difficult to identify exactly which reference pictures are still available (and which o= f them are correct, as addressed by suggestion H. below) and it would be da= ngerous to assume that all reference pictures of one specific reference pic= tures will be available.

 <= /p>

H. Using the 2 currently unused bits in= the 'Native RPSI bit string defined per codec' for adding the possibility of including information regarding the MD5 in the R= PSI message as follows:

0:      &= nbsp;     No information regarding the MD5 available 1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)

The last option can be used when the en= coder does not include MD5s in-band but wants to check the MD5 before using= a selected picture for reference. Typically this will be more bit-efficient than including decoded picture hash SEI messages in-ban= d.

In my opinion it would be very useful t= o be able to include information regarding the correctness of the decoded p= ictures, e.g. to detect incompatibility issues and bit errors. I will send a suggestion for the text changes needed to enable this, hopef= ully later today.

 <= /p>

[YK]: Firstly, in my unde= rstanding, the decoder picture hash SEI message is very useful for debuggin= g in development of encoder and decoder implementations, as used by the JCT-VC for the development of the HEVC reference software, = and it is intended for use with that purpose. Using of it for error resilie= nce in communications is an overkill to me. For example, you would need 48 = bytes to signal the MD5 hash for each picture.

[JS] It would still be op= tional to include those 48 bytes of MD5 info, and if they can be used to de= tect errors that would otherwise not be detected, then 48 bytes per reference picture does not sound much compared to the typical bi= trates for video streams.   &nb= sp;

Secondly, it is architect= urally incorrect to couple this with the RPSI feedback message, as the pict= ure identified is supposed to be correctly decoded by the decoder and the purpose of the message is to request the encoder to use th= at picture for encoding of the next picture,

[JS] You are right that t= he identified picture(s) is supposed to be correct. The proposed usage of M= D5 provides a mechanism for verifying that a picture is actually correct.

thus why would you even i= ndicate a picture that is incorrect using an RPSI feedback message?<= o:p>

[JS] See further motivati= on at the top of this email. That information can be used to identify incom= patibility issues for immediate actions (change configuration) and long-term actions (identify non-conforming encoders/decoders). In scen= arios where Full Intra reset is not feasible an encoder may use this inform= ation to perform gradual decoder refresh until the encoder and decoder have= been verified to have identical reference pictures in their buffers.

Best Regards Jonatan<= /p>

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear All,

 

Compare to -02, we have addressed most = of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Berna= rd, ..., as well as the following changes:

- Addition of sprop-sei, as suggested b= y Stephan on Apr. 23 to the reflector, agreed by most of the authors, no ob= jection from anyone.

- Addition of an informative, brief des= cription of the display orientation SEI message, which is among one of thos= e new SEI messages that have some systems usage.

- Addition of a definition of NAL-unit-= like structure. The term was used but not defined earlier.

- Addition of descriptions for use of t= he PLI and SLI messages (specified in RFC 4585) and the FIR message (specif= ied in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed= during the presentation at the previous IETF meeting

 

Remaining open issues:

- On profile-compatibility-indicator an= d interop-constraints (raised by Magnus, being discussed among Magnus, myse= lf and Yago, no conclusion yet)

- On recv-sub-layer-id and using of spr= op-vps for session negotiation (raised by Magnus, still being discussed amo= ng the authors and Magnus)

- On source-specific sprop parameter se= ts (raised by Magnus, still being discussed among the authors and Jonathan = for exact text changes)

- On using a different parameter catego= ry for level-id (raised by Magnus, discussed between Magnus and myself, no = conclusion yet)

- I just noticed that the definition of= "packet stream" itself needs to be changed back to "RTP str= eam"

 

We will try to address the above open i= ssues as soon as possible. At the same time, further review and comments ar= e welcome.

 

BR, YK

 

-----Original Message-----<= /o:p>

From: payload [mailto:payload-bounces@iet= f.org] On Behalf Of <= /span>internet-drafts@ietf.org

Sent: Wednesday, April 30, 2014 10:34 A= M

Subject: [payload] I-D Action: draft-ie= tf-payload-rtp-h265-03.txt

 

 

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.

 

      &nb= sp; Title           : RTP= Payload Format for High Efficiency Video Coding

      &nb= sp; Authors         : Ye-Kui Wang

      &nb= sp;            =        Yago Sanchez

      &nb= sp;            =        Thomas Schierl

      &nb= sp;            =        Stephan Wenger

      &nb= sp;            =        Miska M. Hannuksela<= /p>

      &nb= sp; Filename        : draft-ietf-payload= -rtp-h265-03.txt

      &nb= sp; Pages           : 92<= /span>

      &nb= sp; Date            = : 2014-04-30

 

Abstract:

   This memo describes an RTP= payload format for the video coding

   standard ITU-T Recommendat= ion H.265 and ISO/IEC International

   Standard 23008-2, both als= o known as High Efficiency Video Coding

   (HEVC) [HEVC] and develope= d by the Joint Collaborative Team on Video

   Coding (JCT-VC).  The= RTP payload format allows for packetization of

   one or more Network Abstra= ction Layer (NAL) units in each RTP packet

   payload, as well as fragme= ntation of a NAL unit into multiple RTP

   packets.  Furthermore= , it supports transmission of an HEVC bitstream

   over a single as well as m= ultiple RTP streams.  The payload format

   has wide applicability in = videoconferencing, Internet video

   streaming, and high bit-ra= te entertainment-quality video, among

   others.<= /p>

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

payload mailing list<= /p>

 

_______________________________________= ________

payload mailing list<= /p>

 

______________________________________= _________
payload mailing list
payload@ie= tf.org
https://www.ietf.org/mailman/listinfo/payload

 

 

--_000_634D3B5D82E3214DA9B6A36D5F50DB23231D6FESESSMB109ericsso_-- From nobody Mon May 19 09:25: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 928561A0393 for ; Mon, 19 May 2014 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ETbUnu2vAM5W for ; Mon, 19 May 2014 09:25:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC50B1A0390 for ; Mon, 19 May 2014 09:25:04 -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=1400516705; x=1432052705; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fGx5R0kMERVclPA9AfTsQRhTt2qLqLGB0B4OgBQUqYw=; b=MA+cWl1V0/a/iiWvGlOn+bbTu4cE86gGvU1lk0I/q8ZJf2DKnX70xtDC MmoUgOscfdrfXzFq3RzN+WbCBujp3QBF3lGUcIi7gZO3UgyyupHexpE6n xslxy5asS0h6oTzgsea6nYSnyXQ3b3MgeHwxjEOckkWPMdVJ5t9aQ3OYN 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7442"; a="35938120" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 19 May 2014 09:25:04 -0700 X-IronPort-AV: E=Sophos;i="4.98,868,1392192000"; d="scan'208,217";a="735179583" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 May 2014 09:25:04 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.156]) by nasanexhc15.na.qualcomm.com ([129.46.52.215]) with mapi id 14.03.0181.006; Mon, 19 May 2014 09:25:35 -0700 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , Yago Sanchez Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrPnXCAgBZg74CAJuPegIAV/V0AgAATNgCABHWcAIAAffAAgAMcXACAAA2ygIACxNUAgAPm0oCAAMF4AIAAjplggAEi0AD//9aMYIALdneA//+t/aCAAIY3AIAELu+AgAAG2/CAAZWDAIADGJuA////aLA= Date: Mon, 19 May 2014 16:25:35 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83452BD691@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387D4E31@nasanexd02f.na.qualcomm.com> <53271A9D.4020906@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345200F61@nasanexd02f.na.qualcomm.com> <535A2C74.7020306@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834523F1EC@nasanexd02f.na.qualcomm.com> <535DFA38.5090901@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A8345242101@nasanexd02f.na.qualcomm.com> <5360FFE6.3070206@ericsson.com> <8C8C86DF-6425-4D5B-8142-408146A154F0@hhi.fraunhofer.de> <53635E00.5050204@ericsson.com> <5367462A.903@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B1FF@nasanexd02f.na.qualcomm.com> <5368B1BC.5070104@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834524B931@nasanexd02f.na.qualcomm.com> <53722C91.1000907@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A834527BBA0@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23220112@ESESSMB109 .ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A8345294AAE@nasanexd02f.na.qualcomm.com> <6E8F970B-DBA2-4EA8-87FF-F96D9AC2E5C3@hhi.fraunhofer.de> <634D3B5D82E3214DA9B6A36D5F50DB2322DC18@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB2322DC18@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.89] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD691nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/FiTjd7Wm74OKFR6d3ux04LpY-10 Cc: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" 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, 19 May 2014 16:25:13 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD691nasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonatan, I think there is a big misunderstanding here. Just because the payload form= at supports the mechanism of a configuration of an intersection of more tha= n one profile does not mean that encoders must be able to support all possi= ble intersections. If you think so, please point out where is this implied. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Monday, May 19, 2014 2:23 AM To: Yago Sanchez; Wang, Ye-Kui Cc: Stephan Wenger; Magnus Westerlund; draft-ietf-payload-rtp-h265@tools.ie= tf.org; payload@ietf.org Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi Ye-Kui, Yago, all, Just to make one thing clear; there is a HUGE difference between bitstreams= that conforms to multiple profiles (which is what "item b)" below is about= ) and decoders that only supports intersections of multiple profiles. From = an encoder implementers point of view it is a nightmare to handle all the d= ifferent intersections that can occur. As soon as a new profile is defined = in the HEVC specification an encoder implementer will not only have to add = support for that profile but also for all the intersections with old profil= es and all the intersections with the different intersections of old profil= es. A complete explosion of operating points resulting in increased cost an= d higher risk of bugs and misinterpretations causing interoperability probl= ems. I think profile-compatibility-indicator is very useful as a bitstream prope= rty (sprop parameter). By using that, the same payload type can be accepted= by answerer A (supporting profile pA) and answerer B (supporting profile p= B). Let me express the alternatives I see for profile-compatibility-indicator, = in my order of preference: 1. Making it a sprop parameter only (expressing a property of the bit= stream) 2. Making 2 parameters: one sprop parameter AND one receiver paramete= r that can be used to express that the decoder supports multiple (full) pro= files (similar to the cited text below from the latest draft of the payload= spec) 3. Making it a single parameter used both for expressing that a bitst= ream conforms to multiple profiles and that a decoder only supports the int= ersection of all the indicated profiles (this is what you are proposing, ri= ght?). I would strongly prefer if option 3 could be avoided for the above mentione= d reason. If not, I guess we just have to ensure that all SDOs that uses th= e HEVC payload spec does not use this mechanism :). See some further discus= sion inline below. Best Regards Jonatan From: Yago Sanchez [mailto:yago.sanchez@hhi.fraunhofer.de] Sent: den 17 maj 2014 12:06 To: Wang, Ye-Kui Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; draft-ietf-paylo= ad-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, Ye-Kui, Jonatan,all, Just to make clear my opinion on this topic, I am here with Ye-Kui and Step= han as already expressed previously in this thread. Desirable or not, profi= le_compatibility_indicator allows for indicating intersection of profiles a= s expressed in the item b) in the contribution mentioned in the email below= . Whether the intersections will get a profile_idc or not cannot be known b= eforehand and might not since we have profile_compatibility_flag for that p= urpose. Said that still I think the argument here is that if HEVC allows fo= r it we should support it in the payload format. [JS] As mentioned above; there is a HUGE difference between bitstreams that= conforms to multiple profiles and decoders that only supports intersection= s of multiple profiles. The HEVC spec does not allow the latter. If we intr= oduce the concept of decoders conforming to intersection of profiles in the= HEVC payload format that would be something which does not have any corres= pondence in the HEVC spec. Best regards, Yago On 16 May 2014, at 20:20, Wang, Ye-Kui > wrote: Hi Jonatan, Thanks for responding to my request for comments - I really appreciate (eve= n though you are not supporting my opinion :)). Frankly, I think the observations you pointed out below do not support the = opinion you expressed (See more detailed replies inline below.). What are being discussed here, as Stephan accurately pointed out, is whethe= r to narrow down the number of interoperability points negotiable using O/A= negotiation, by intentionally disabling a mechanism that was expressly inc= luded for purposes that might happen and that have happened. To do (the na= rrowing down) or not to do, that is the question. And the key point to dert= ermine the answer to the question is whether THAT (the intersection way of = profiling) might happen. Unless it is fairly sure that THAT won't happen, w= e ought to provide the support of THAT in the payload format. [JS] Given that the profiles in HEVC version 1 are nicely "onion shaped" (= which they were not in h.264) and given that there are 48 constraint flags = (compared to the 8 in h.264) I am personally fairly sure THAT won't happen,= but apparently you are not :). The facts that THAT did happened for H.264 and that whether it would happen= is not controlled by IETF, but by other organizations, more than one of th= em, I'd say that we are far from being fairly sure that THAT won't happen. = Again, if the narrowing is done and if THAT occurs, then an extension to th= e payload format needs to be specified to add the support of this case and = the design would be the same as what we have now, except that it introduces= new IOP issue on the payload format level (due to two incompatible version= s of the payload format), and if the narrowing is not done and if THAT does= not occur, all the hypothetical issues won't happen anyway. [JS] If THAT does occur sometime in the future, there are multiple options = for how it could be handled in the payload format (depending on how specifi= c the case for which it occurs is). I would much rather see some inconvenie= nce for that specific case then, compared to this burdensome mechanism. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Friday, May 16, 2014 2:31 AM To: Stephan Wenger; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02 Dear Ye-Kui, Stefan, all, Let me express my opinion on this topic (since you explicitly asked for mor= e opinions). I do represent the same company as Magnus, but (in contrast to= Magnus) I was also part of the discussions on how to define the profiles i= n HEVC version 1. I share Magnus' view that it would be very unfortunate if= the payload format allows for definitions of sub-profiles using profile-co= mpatibility-indicator. The purpose of the profile_compatibility_flags is ve= ry clear in the contribution that proposed them, JCTVC-I0499 (http://phenix= .it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761): "We need a labelling scheme that: a) allows the committee to introduce new profiles, and older systems b= e able to work out which bitstreams they can decode when those new profiles= are fully subsets of older existing profiles, even when they do not recogn= ize the new profile identifier; b) allows bitstreams which don't use all the features of any given pro= file, and are as a consequence compatible with more than one, to be labelle= d with so that it's possible to deduce all the profiles that the bitstream = is compatible with (the ones that don't automatically follow from the nesti= ng structure). " [YK]: Item b above talking about exactly encoding a bitstream using an inte= rsection of multiple profiles, which is exactly the point we are taking abo= ut. If there is an intersection between two profiles that does make sense and i= s useful to the industry it is reasonable to assume that ITU/ISO/IEC would = define a new profile corresponding to that intersection (just as was done w= ith Constrained Baseline Profile in h.264). [YK]: Defining a new profile does not necessarily means using of a new valu= e of the profile-id for indicating the new profile, just as was done with t= he Constrained Baseline profile of H.264. And in HEVC, the profile_compatibility_flags provides a mechanism for intro= ducing a new profile, with a new profile_idc while still being able to indi= cate conformance to one or more of the old profiles (a mechanism that did n= ot exist in h.264). [YK]: The mechanism of profile_compatibility_flags is very similar to what = H.264 has, with the only difference been that in HEVC there are 32 of these= flags and 5-bit of profile-id, while in H.264 there are less bits of these= flags and 8 bits of profile-id. [JS] There is also the difference that the semantics of all the profile_com= patibility_flags in HEVC are defined already in version 1. In h.264 there w= ere only 3 bits defined in version 1 and the rest were reserved bits thus m= aking them more comparable to the flags called "interop-constraints" in the= HEVC payload draft. However, it is worth noting that the way the Range Extension profiles have = been defined in the second (soon to be released) version of HEVC, the funct= ionality of profile_compatibility_flag is already broken. There are 19 new = profiles in there but only one profile_idc is used to identify them. Thus i= t is not possible in the same bitstream to indicate that it conforms to two= different of these 19 profiles. [YK]: Which functionality of profile_compatibility_flag as specified in th= e HEVC spec is broken? I guess it is just the functionality of profile_comp= atibility_flag in your understanding is broken :) We should not assume anyt= hing more than said in the spec. I don't see anything written in the spec i= s broken, even though it was a little surprise to me too when seeing the de= finition of the Range Extension profiles (as I did not expect to use the in= terop-constraints bits for profile definition either). The fact that the in= terop-constraints bits have been used in profile definition proves more tha= t the way of profile signalling is not controlled by us, and we should NOT = preclude the support of such profile signalling. Fortunately, the mechanism= we currently specify in the payload draft, where interop-constraints is on= e of the configuration parameters required for symmetric use in O/A, works = with this. [JS] It appears broken to me: general_profile_compatibility_flag[ j ] equal to 1, when general_profile_sp= ace is equal to 0, indicates that the CVS conforms to the profile indicated= by general_profile_idc equal to i as specified in Annex A. How should you interpret "the CVS conforms to the profile indicated by gene= ral_profile_idc equal to i" when i equals 4? Which is "the profile" in this= case? Now to connect back to the example you mentioned, Ye-Kui, on May 5: "There = can be still be a point to offer profile-compatibility-indicator in this ca= se. For example, it is possible that the decoder of the offerer only suppor= ts the common tools of profiles A and B, while it does not support either f= ull profile A or full profile B. 1. I don't think this is desirable. [YK]: As I said earlier in replies to Magnus, I do share the concern either= , but this is not up to us - let me repeat again. 2. Within the profiles defined in "format range extension" (~90% of t= he profiles defined so far) this is not possible. [YK]: There is no such principle or functionality that the example must be = possible for all cases. As long as it is possible for any two of the 32 fla= gs, the payload format should provide support. Otherwise, as I said earlier= , we as the payload format designers are only introducing more IOP issues i= n the future once this is done (by other organizations). 3. When I read the latest HEVC payload format draft, I don't find any= thing supporting that kind of usage of profile-compatibility-indicator. On = the contrary: A decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. The profile-compatibility-indicator provides exact information of the ability of a decoder conforming to a certain profile to decode bitstreams conforming to another profile. More concretely, if the profile compatibility flag corresponding to the profile a decoder conforms to is set, then the decoder is able to decode any bitstream with the flag set, irrespective of the profile the bitstream conforms to (provided that the decoder supports the highest level of the bitstream). [YK] Due to the newly introduced signalling of Range Extensions profiles us= ing one profile-id value in combination with interop-constraints, the above= description of profile-compatibility-indicator needs to be updated. I had = planned to do this in the next version. But again, here we need to specify = the text to align with whatever is specified in the HEVC specification. I can see the benefit in using the interop-constraints to express constrain= ts that applies to well-defined profiles (both from a decoder and encoder p= oint of view). However, using profile-compatibility-indicator to let decode= rs create ad-hoc on the fly "sub-profiles" of an arbitrary number of define= d profiles serves IMO no purpose and is simply a misuse of theprofile_compa= tibility_flags. [YK] See above. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: den 13 maj 2014 19:38 To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, I=B9m one of the co-authors. To make one thing clear from the outset: I=B9m one who says that any and al= l options of a given payload necessarily need always to be supported by a R= TP payload format. Sometimes, it=B9s IMO completely OK to forgo the suppor= t of an odd mechanism that=B9s not required or useful for the application = =B3payload over the Internet using RTP=B2. That said, the case here is different. What we have here is a request (by Magnus) to narrow down the number of interoperability points negotiable usi= ng O/A negotiation, by intentionally disabling a mechanism that was express= ly included for purposes just like this. There was considerable discussion= in JCT-VC, MPEG, and VCEG about the subject. I would say it was one of th= e key drivers, but my view may be a bit one-sided. However, it was discuss= ed more than once. The front lines were often between the hardware folks (= who would like to have as few interop points as possible) and the software = people (who would prefer to have a finer granularity, to better suit indivi= dual application needs). The resulting compromise necessarily made no one = completely happy, but everyone could live with it. Ye-Kui is right: it=B9s not the IETF=B9s job to rehash these profiling arch= itecture discussions/decisions. Thanks for your consideration, Stephan On 13.5.14, 9:57, "Wang, Ye-Kui" > wrote: >Magnus, > >I understand your arguments too. Your main worry seems to be about the >HEVC profiling fracturing the market and reducing the interoperability >of HEVC, which I do share. However, the key point here is that, that is >not up to us, it is controlled by other organizations. If we go ahead >to disallow the support of that in the HEVC payload format, that does >not mean we would successfully prevent that from happening in >MPEG/ITU-T and other application standard organizations - and if that >happens, then an extension to the payload format would need to be >specified, which might introduce more IOP issues even on the RTP encapsula= tion level for HEVC. > >I fully agree that some more opinions from others would be very helpful. > >Please, whoever cares about this draft and cares about using HEVC with >RTP, say your opinion. We really need to have this document finalized >soon for HEVC deployment!!! > >See some other detailed replies inline below too. > >BR, YK > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, May 13, 2014 7:31 AM >To: Wang, Ye-Kui; Yago Sanchez >Cc: payload@ietf.org; draft-ietf-payload-rtp-h265= @tools.ietf.org >Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 > >Ye-Kui and WG, > >Please see inline. I think we need input from more people into this >question to make progress. > > >On 2014-05-06 16:56, Wang, Ye-Kui wrote: >> Magnus, >> >> I think the only key different understanding between us now is the >> following: Whether to assume that a decoder does not fully support >> any profile indicated by profile-id (what you called "sub-profile", e.g. >> only support the common tools of two or more profiles). >> >> Once we converge here, it should be easy to derive that text changes >> should be made. Thus, let me focus on this in this email. >> >> Your opinion is obvious and strong - don't go into that direction. >> >> My opinion is strong too - we do need to go into that direction, >> because of the following reasons: >> >> - The ITU-T/MPEG control how to use the bits of profile-id and >> profile-compatibility-indicator in the video coding specifications. >> It is simply possible that a new profile can be defined and indicated >> without using a new value of profile-id, but indicated as conforming >> to two profiles. This happened for AVC for the Constrained Baseline >> profile as I explained. Also, in the recently finalized HEVC Range >> Extensions spec (see here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/17_Valencia/wg11 >> / >> JCTVC-Q1005-v4.zip), >> 19 new profiles have been defined, indicated by only one value of >> profile-id and some values of bits of the interop-constraints field >> (Note, not the profile-compatibility-indicator field). > >Yes this may happen, but jumping onto this now, do in fact create a >tool where anyone can attempt to create new interoperability points by >selecting an intersection between profiles. That doesn't benefit >interoperability, it instead fractures the market and works against the >purpose of the profiles in the first place. > >[YK]: Agreed - but again that is not up to us, it is controlled by >other SDOs (which are in turn driven by the markets). > >Secondly, in relation to H.264 constrained baseline, that was created >using constraint bits, a concept that already is part of the >specification, it might be defined as the intersection of two profiles, >but the signalling is done according to one profile with a specific bit >set. Just like the HEVC Range Extension profiles. > >[YK]: Why the signalling is different? Herein you also use a profile-id >value with a specific bit set. > >However, to me it appears that when one selected the structure for HEVC >Range Extensions one forgot about the profile-compatibility-indicator >as it is not possible to signal compatibility across the main >directions in the range extension profiles. The main directions are >within themselves nicely onion shaped, but the compatibility between >them does not appear to have been well considered. > >[YK]: I was not involved in the definition of the structure for HEVC >Range Extensions - so no comment here. > >> >> - Application standards organizations, e.g. 3GPP, may require >> "sub-profile" capability for decoders. Again, AVC Constrained >> Baseline profile is an example - Magnus you should know this much >> better than many others. > >Yes, however I think it is usually bad for interoperability. And HEVC >does not appear to be in the same position that H.264 was when it was >just finished. Thus, I expect the issues are being different. > >[YK]: True - but on the other hand, that was driven by the market too, >and they wanted that for interoperability for that particular capability. >Here the issue is not about what was defined already in HEVC, but what >could be done in the future. When RFC 3984 was finalized, the >Constrained Baseline profile was not available yet. So, right now, the >situation is the same. Unless we can surely know similar things won't >happen, we should follow the approach in RFC 3984, i.e. to allow for >such intersection of two more profiles. Nobody can be sure right now >for what could happen in the future, at least for this issue. > >> >> Thus, when defining the HEVC RTP payload here, I don't think we can >> ignore the above. Rather, we must go into the direction of >> "sub-profile". > >I understand your arguments. What is required is highly dependent on >what will be done with future profiling of HEVC. I see enabling the >possibility to intersect any choice of profiles do create an potential >for fracturing the market and reducing the interoperability of HEVC. > >[YK]: Again, agree in general, but again that is not controlled by us. > >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 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD691nasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jonatan,

 <= /p>

I think there is a big mi= sunderstanding here. Just because the payload format supports the mechanism= of a configuration of an intersection of more than one profile does not mean that encoders must be able to support all possible i= ntersections. If you think so, please point out where is this implied.=

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan = Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Monday, May 19, 2014 2:23 AM
To: Yago Sanchez; Wang, Ye-Kui
Cc: Stephan Wenger; Magnus Westerlund; draft-ietf-payload-rtp-h265@t= ools.ietf.org; payload@ietf.org
Subject: RE: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi Ye-Kui, Yago, all,

 <= /p>

Just to make one thing cl= ear; there is a HUGE difference between bitstreams that conforms to multipl= e profiles (which is what “item b)” below is about) and decoders that only supports intersections of multiple profiles. From an en= coder implementers point of view it is a nightmare to handle all the differ= ent intersections that can occur. As soon as a new profile is defined in th= e HEVC specification an encoder implementer will not only have to add support for that profile but also fo= r all the intersections with old profiles and all the intersections with th= e different intersections of old profiles. A complete explosion of operatin= g points resulting in increased cost and higher risk of bugs and misinterpretations causing interoperabili= ty problems.

 <= /p>

I think profile-compatibility-indi= cator is very useful as a bitstream property (sprop parameter). By using th= at, the same payload type can be accepted by answerer A (supporting profile pA) and answerer B (supporting profile pB).=

 = ;

Let me express the altern= atives I see for profile-compatibility-indi= cator, in my order of preference:

1. = ;      Making it a sprop= parameter only (expressing a property of the bitstream)<= /p>

2. = ;      Making 2 paramete= rs: one sprop parameter AND one receiver parameter that can be used to expr= ess that the decoder supports multiple (full) profiles (similar to the cited text below from the latest draft of the payload spec= )

3. = ;      Making it a singl= e parameter used both for expressing that a bitstream conforms to multiple = profiles and that a decoder only supports the intersection of all the indicated profiles (this is what you are proposing, right?).

 <= /p>

I would strongly prefer i= f option 3 could be avoided for the above mentioned reason. If not, I guess= we just have to ensure that all SDOs that uses the HEVC payload spec does not use this mechanism J. See some further discussion inline below.

 <= /p>

Best Regards Jonatan=

 <= /p>

 <= /p>

From: Yago San= chez [mailto:yago.sanchez= @hhi.fraunhofer.de]
Sent: den 17 maj 2014 12:06
To: Wang, Ye-Kui
Cc: Jonatan Samuelsson; Stephan Wenger; Magnus Westerlund; draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi, Ye-Kui, Jonatan,all,

 

Just to make clear my opinion on this topic, I am he= re with Ye-Kui and Stephan as already expressed previously in this thread. = Desirable or not, profile_compatibility_indicator allows for indicating int= ersection of profiles as expressed in the item b) in the contribution mentioned in the email below. Whether t= he intersections will get a profile_idc or not cannot be known beforehand a= nd might not since we have profile_compatibility_flag for that purpose. Sai= d that still I think the argument here is that if HEVC allows for it we should support it in the payload for= mat.

 <= /p>

[JS] As mentioned above; = there is a HUGE difference between bitstreams that conforms to multiple pro= files and decoders that only supports intersections of multiple profiles. The HEVC spec does not allow the latter. If we introduce the con= cept of decoders conforming to intersection of profiles in the HEVC payload= format that would be something which does not have any correspondence in t= he HEVC spec.

 

Best regards,

Yago

 

 

On 16 May 2014, at 20:20, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:<= o:p>

 

Hi Jonatan,

 

Thanks for responding to = my request for comments – I really appreciate (even though you are no= t supporting my opinion <= /span>= J).=

 

Frankly, I think the obse= rvations you pointed out below do not support the opinion you expressed (Se= e more detailed replies inline below.).

 

What are being discussed = here, as Stephan accurately pointed out, is whether to narrow down the numb= er of interoperability points negotiable using O/A negotiation, by intentionally disabling a mechanism that was expressly included for pur= poses that might happen and that have happened.  To do (the narrowing = down) or not to do, that is the question. And the key point to dertermine t= he answer to the question is whether THAT (the intersection way of profiling) might happen. Unless it is fairly= sure that THAT won’t happen, we ought to provide the support of THAT= in the payload format.

[JS] Given that the profi= les in  HEVC version 1 are nicely “onion shaped” (which th= ey were not in h.264) and given that there are 48 constraint flags (compare= d to the 8 in h.264) I am personally fairly sure THAT won’t happen, bu= t apparently you are not J.

 

The facts that THAT did h= appened for H.264 and that whether it would happen is not controlled by IET= F, but by other organizations, more than one of them, I’d say that we are far from being fairly sure that THAT won’t happen. A= gain, if the narrowing is done and if THAT occurs, then an extension to the= payload format needs to be specified to add the support of this case and t= he design would be the same as what we have now, except that it introduces new IOP issue on the payload format le= vel (due to two incompatible versions of the payload format), and if the na= rrowing is not done and if THAT does not occur, all the hypothetical issues= won’t happen anyway.

[JS] If THAT does occur s= ometime in the future, there are multiple options for how it could be handl= ed in the payload format (depending on how specific the case for which it occurs is). I would much rather see some inconvenience f= or that specific case then, compared to this burdensome mechanism.

 <= /p>

BR, YK

 

From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Friday, May = 16, 2014 2:31 AM
To: Stephan Wenger= ; Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft-ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: RE: [payl= oad] Comments on draft-ietf-payload-rtp-h265-02

 

Dear Ye-Ku= i, Stefan, all,

 

Let me exp= ress my opinion on this topic (since you explicitly asked for more opinions= ). I do represent the same company as Magnus, but (in contrast to Magnus) I was also part of the discussions on how to define the profile= s in HEVC version 1. I share Magnus' view that it would be very unfortunate= if the payload format allows for definitions of sub-profiles using profile= -compatibility-indicator. The purpose of the profile_compatibility_flags is very clear in the contribution that = proposed them, JCTVC-I0499 (htt= p://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=3D5761):

"We need a labelling scheme that:

a)<= span style=3D"font-size:7.0pt">      allows the committee to introduce new profiles, and older systems be able to work= out which bitstreams they can decode when those new profiles are fully sub= sets of older existing profiles, even when they do not recognize the new pr= ofile identifier;

b)<= span style=3D"font-size:7.0pt">      allows bitstreams which don't use all the features of any given profile, and are = as a consequence compatible with more than one, to be labelled with so that= it's possible to deduce all the profiles that the bitstream is compatible = with (the ones that don't automatically follow from the nesting structure).

"

 

[YK]: Item= b above talking about exactly encoding a bitstream using an intersection o= f multiple profiles, which is exactly the point we are taking about.

 

If there i= s an intersection between two profiles that does make sense and is useful t= o the industry it is reasonable to assume that ITU/ISO/IEC would define a new profile corresponding to that intersection (just as was= done with Constrained Baseline Profile in h.264).=

 

[YK]: Defi= ning a new profile does not necessarily means using of a new value of the p= rofile-id for indicating the new profile, just as was done with the Constrained Baseline profile of H.264.

 

And in HEV= C, the profile_compatibility_flags provides a mechanism for introducing a n= ew profile, with a new profile_idc while still being able to indicate conformance to one or more of the old profiles (a mechanism th= at did not exist in h.264).

 

[YK]: The = mechanism of profile_compatibility_flags is very similar to what H.264 has,= with the only difference been that in HEVC there are 32 of these flags and 5-bit of profile-id, while in H.264 there are less bits of= these flags and 8 bits of profile-id.

[JS] There is also the di= fference that the semantics of all the profile_compatibility_flags in HEVC = are defined already in version 1. In h.264 there were only 3 bits defined in version 1 and the rest were reserved bits thus making th= em more comparable to the flags called “interop-constraints” in= the HEVC payload draft.

 

However, i= t is worth noting that the way the Range Extension profiles have been defin= ed in the second (soon to be released) version of HEVC, the functionality of profile_compatibility_flag is already broken. There are 1= 9 new profiles in there but only one profile_idc is used to identify them. = Thus it is not possible in the same bitstream to indicate that it conforms = to two different of these 19 profiles.

 

[YK]: Which functionality= of  profile_compatibility_flag as specified in the HEVC spec is broke= n? I guess it is just the functionality of profile_compatibility_flag in your understanding is broken = ;J We should not assume anything more than said in the spec. I don’t see a= nything written in the spec is broken, even though it was a little surprise= to me too when seeing the definition of the Range Extension profiles (as I= did not expect to use the interop-constraints bits for profile definition either). The fact that the interop-constraints= bits have been used in profile definition proves more that the way of prof= ile signalling is not controlled by us, and we should NOT preclude the supp= ort of such profile signalling. Fortunately, the mechanism we currently specify in the payload draft, wher= e interop-constraints is one of the configuration parameters required for s= ymmetric use in O/A, works with this.=

[JS] It appears broken to= me:

general_profile_compatibility_flag[ j&nb= sp;] equal to 1, when general_profile_space is equal to 0, indicates that t= he CVS conforms to the profile indicated by general_profile_idc equal to i = as specified in Annex A.

How should you interpret = “the CVS conforms to the profile indicated by general_profile_= idc equal to i” when i equals 4? Which is “the profile” in this case?

 

Now to con= nect back to the example you mentioned, Ye-Kui, on May 5: “There can be still be a point to offer profile-compatibility-indicator in this c= ase. For example, it is possible that the decoder of the offerer only suppo= rts the common tools of profiles A and B, while it does not support either = full profile A or full profile B.

1.<= span style=3D"font-size:7.0pt">       I don’t think this is desirable.=

[YK]: As I said earlier i= n replies to Magnus, I do share the concern either, but this is not up to u= s – let me repeat again.

 

2.<= span style=3D"font-size:7.0pt">       

[YK]: There is no such pr= inciple or functionality that the example must be possible for all cases. A= s long as it is possible for any two of the 32 flags, the payload format should provide support. Otherwise, as I said earlier, we as= the payload format designers are only introducing more IOP issues in the f= uture once this is done (by other organizations).<= /o:p>

 

3.<= span style=3D"font-size:7.0pt">        = profile-compatibili= ty-indicator. On the contrary:

 

         A decoder conforming =
to a certain profile may
         be able to decode bit=
streams conforming to other profiles.
         The profile-compatibi=
lity-indicator provides exact information
         of the ability of a d=
ecoder conforming to a certain profile to
         decode bitstreams con=
forming to another profile.  More
         concretely, if the pr=
ofile compatibility flag corresponding to
         the profile a decoder=
 conforms to is set, then the decoder is
         able to decode any bi=
tstream with the flag set, irrespective
         of the profile the bi=
tstream conforms to (provided that the
         decoder supports the =
highest level of the bitstream).

 

[YK] Due to the newly int= roduced signalling of Range Extensions profiles using one profile-id value = in combination with interop-constraints, the above description of profile-compatibility-indicator needs to be updated. I had planned to d= o this in the next version. But again, here we need to specify the text to = align with whatever is specified in the HEVC specification.

 

I can see the benefit in = using the interop-constraints to express constraints that applies to well-d= efined profiles (both from a decoder and encoder point of view). However, using profile-compatibility-indicator to let decoders crea= te ad-hoc on the fly “sub-profiles” of an arbitrary number of d= efined profiles serves IMO no purpose and is simply a misuse of the<= span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">profile_compatibility_flags.

 

[YK] See above.

 

Best Regards Jonatan

 

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Steph= an Wenger
Sent: den 13 maj 2014 19:38
To: Wang, Ye-Kui; Magnus Westerlund; Yago Sanchez
Cc: draft= -ietf-payload-rtp-h265@tools.ietf.org; payload@ietf.org
Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02

 

Hi,

I=B9m one of the co-authors.=

To make one thing clear from the outset= : I=B9m one who says that any and all options of a given payload necessaril= y need always to be supported by a RTP payload format.  Sometimes, it=B9s IMO completely OK to forgo the support of an odd mechanism that=B9s= not required or useful for the application =B3payload over the Internet us= ing RTP=B2.

That said, the case here is different.&= nbsp; What we have here is a request (by

Magnus) to narrow down the number of in= teroperability points negotiable using O/A negotiation, by intentionally di= sabling a mechanism that was expressly included for purposes just like this.  There was considerable discussion in JCT-VC, MPEG, a= nd VCEG about the subject.  I would say it was one of the key drivers,= but my view may be a bit one-sided.  However, it was discussed more t= han once.  The front lines were often between the hardware folks (who would like to have as few interop points as possible) = and the software people (who would prefer to have a finer granularity, to b= etter suit individual application needs).  The resulting compromise ne= cessarily made no one completely happy, but everyone could live with it.

Ye-Kui is right: it=B9s not the IETF=B9= s job to rehash these profiling architecture discussions/decisions.

Thanks for your consideration,

Stephan

 

On 13.5.14, 9:57, "Wang, Ye-Kui&qu= ot; <yekuiw@qti.qualcomm.com> wrote:=

 

>Magnus,

> 

>I understand your arguments too. Yo= ur main worry seems to be about the

>HEVC profiling fracturing the marke= t and reducing the interoperability

>of HEVC, which I do share. However,= the key point here is that, that is

>not up to us, it is controlled by o= ther organizations. If we go ahead

>to disallow the support of that in = the HEVC payload format, that does

>not mean we would successfully prev= ent that from happening in

>MPEG/ITU-T and other application st= andard organizations - and if that

>happens, then an extension to the p= ayload format would need to be

>specified, which might introduce mo= re IOP issues even on the RTP encapsulation level for HEVC.

> 

>I fully agree that some more opinio= ns from others would be very helpful.

> 

>Please, whoever cares about this dr= aft and cares about using HEVC with

>RTP, say your opinion. We really ne= ed to have this document finalized

>soon for HEVC deployment!!!

> 

>See some other detailed replies inl= ine below too.

> 

>BR, YK

> 

>-----Original Message-----

>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]

>Sent: Tuesday, May 13, 2014 7:31 AM=

>To: Wang, Ye-Kui; Yago Sanchez=

>Subject: Re: [payload] Comments on = draft-ietf-payload-rtp-h265-02

> 

>Ye-Kui and WG,

> 

>Please see inline. I think we need = input from more people into this

>question to make progress.

> 

> 

>On 2014-05-06 16:56, Wang, Ye-Kui w= rote:

>> Magnus,

>> 

>> I think the only key different= understanding between us now is the

>> following: Whether to assume t= hat a decoder does not fully support

>> any profile indicated by profi= le-id (what you called "sub-profile", e.g.

>> only support the common tools = of two or more profiles).

>> 

>> Once we converge here, it shou= ld be easy to derive that text changes

>> should be made. Thus, let me f= ocus on this in this email.

>> 

>> Your opinion is obvious and st= rong - don't go into that direction.

>> 

>> My opinion is strong too - we = do need to go into that direction,

>> because of the following reaso= ns:

>> 

>> - The ITU-T/MPEG control how t= o use the bits of profile-id and

>> profile-compatibility-indicato= r in the video coding specifications.

>> It is simply possible that a n= ew profile can be defined and indicated

>> without using a new value of p= rofile-id, but indicated as conforming

>> to two profiles. This happened= for AVC for the Constrained Baseline

>> profile as I explained. Also, = in the recently finalized HEVC Range

>> Extensions spec (see here:

>> /

>> JCTVC-Q1005-v4.zip),

>> 19 new profiles have been defi= ned, indicated by only one value of

>> profile-id and some values of = bits of the interop-constraints field

>> (Note, not the profile-compati= bility-indicator field).

> 

>Yes this may happen, but jumping on= to this now, do in fact create a

>tool where anyone can attempt to cr= eate new interoperability points by

>selecting an intersection between p= rofiles. That doesn't benefit

>interoperability, it instead fractu= res the market and works against the

>purpose of the profiles in the firs= t place.

> 

>[YK]: Agreed - but again that is no= t up to us, it is controlled by

>other SDOs (which are in turn drive= n by the markets).

> 

>Secondly, in relation to H.264 cons= trained baseline, that was created

>using constraint bits, a concept th= at already is part of the

>specification, it might be defined = as the intersection of two profiles,

>but the signalling is done accordin= g to one profile with a specific bit

>set. Just like the HEVC Range Exten= sion profiles.

> 

>[YK]: Why the signalling is differe= nt? Herein you also use a profile-id

>value with a specific bit set.=

> 

>However, to me it appears that when= one selected the structure for HEVC

>Range Extensions one forgot about t= he profile-compatibility-indicator

>as it is not possible to signal com= patibility across the main

>directions in the range extension p= rofiles. The main directions are

>within themselves nicely onion shap= ed, but the compatibility between

>them does not appear to have been w= ell considered.

> 

>[YK]: I was not involved in the def= inition of the structure for HEVC

>Range Extensions - so no comment he= re.

> 

>> 

>> - Application standards organi= zations, e.g. 3GPP, may require

>> "sub-profile" capabi= lity for decoders. Again, AVC Constrained

>> Baseline profile is an example= - Magnus you should know this much

>> better than many others.<= /o:p>

> 

>Yes, however I think it is usually = bad for interoperability. And HEVC

>does not appear to be in the same p= osition that H.264 was when it was

>just finished. Thus, I expect the i= ssues are being different.

> 

>[YK]: True - but on the other hand,= that was driven by the market too,

>and they wanted that for interopera= bility for that particular capability.

>Here the issue is not about what wa= s defined already in HEVC, but what

>could be done in the future. When R= FC 3984 was finalized, the

>Constrained Baseline profile was no= t available yet. So, right now, the

>situation is the same. Unless we ca= n surely know similar things won't

>happen, we should follow the approa= ch in RFC 3984, i.e. to allow for

>such intersection of two more profi= les. Nobody can be sure right now

>for what could happen in the future= , at least for this issue.

> 

>> 

>> Thus, when defining the HEVC R= TP payload here, I don't think we can

>> ignore the above. Rather, we m= ust go into the direction of

>> "sub-profile".<= /o:p>

> 

>I understand your arguments. What i= s required is highly dependent on

>what will be done with future profi= ling of HEVC. I see enabling the

>possibility to intersect any choice= of profiles do create an potential

>for fracturing the market and reduc= ing the interoperability of HEVC.

> 

>[YK]: Again, agree in general, but = again that is not controlled by us.

> 

>Cheers

> 

>Magnus Westerlund=

> 

>-----------------------------------= -----------------------------------

>Services, Media and Network feature= s, Ericsson Research EAB/TXM

>-----------------------------------= -----------------------------------

>Ericsson AB    =              | = Phone  +46 10 7148287

>F=E4r=F6gatan 6   &n= bsp;            = ; | Mobile +46 73 0949079

>SE-164 80 Stockholm, Sweden | mailt= o: magnus.westerlund@ericsson.com

>-----------------------------------= -----------------------------------

> 

>___________________________________= ____________

>payload mailing list

 

_______________________________________= ________

payload mailing list<= /p>

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD691nasanexd02fnaqu_-- From nobody Mon May 19 09:48: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 D11221A0102 for ; Mon, 19 May 2014 09:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 6jZOopGcnu41 for ; Mon, 19 May 2014 09:48:24 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15711A02D6 for ; Mon, 19 May 2014 09:48:03 -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=1400518084; x=1432054084; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FWK9g/7Dw5+3TyxECHOHMayJOEWTxiUdnI6Z43ibrdY=; b=kOO/TqciKXQ+g1K6BlpFr2VUValxOCmOzThD6feN5aa5vXoIoocZQFDv boBot7aEA88xZbRk+9cXI9d+aRBBkhK+B2VsfOkVOBHc48fpzjDZNpdwS UMeGVbkLoDDHX6GSSeJjj4zeiz/bRa8htmnH8VLSX/rIRNUWnkrtNssay 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7442"; a="63735017" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 19 May 2014 09:48:03 -0700 X-IronPort-AV: E=Sophos;i="4.98,868,1392192000"; d="scan'208,217";a="735188778" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 May 2014 09:48:03 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.156]) by NASANEXHC01.na.qualcomm.com ([10.46.57.53]) with mapi id 14.03.0181.006; Mon, 19 May 2014 09:48:34 -0700 From: "Wang, Ye-Kui" To: Jonatan Samuelsson , Yago Sanchez Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqbLyXIk9FYUOA5cqUKWqAxJsqbPSAgBXkUACAA4F9oIABU/qAgANR6wD//7w8wA== Date: Mon, 19 May 2014 16:48:34 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83452BD6EF@nasanexd02f.na.qualcomm.com> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23231D6F@ESESSMB109.ericsson.se> In-Reply-To: <634D3B5D82E3214DA9B6A36D5F50DB23231D6F@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.89] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD6EFnasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/dO8g74o1lsbJJJU4LS5NA0M1FD8 Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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, 19 May 2014 16:48:36 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD6EFnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonatan, All, On item C: In that example, you report three set of consecutive CTB losses,= (2,2), (6, 2), and (10, 2). The semantics can only be interpreted this way= , no? On item D: It is up to the receiver to decide how much data is reported to = be lost regardless of how much it actually received, but whatever it report= s, it should report something that is accurate enough for the sender side t= o make meaningful reaction. On item G: I'd like to see some opinions from others, particularly those wh= o have been deeply involved in RFC 4585 to comment on the G.1 and G.2. On G= .3, the wording "the encoder can choose to use one or more of the identifie= d picture and its reference pictures for encoding the next picture" does no= t at all assume that all reference pictures of one specific reference pictu= res will be available, it just means that use whichever from that set when = available. On item H: Assume that the MD5 support as part of RPSI is specified, once a= mismatch due to non-conformation encoder/decoder implementations is known,= you still need people to get involved to debug and to see what is the reas= on of the mismatch, and you cannot assume the buggy implementations to be s= o powerful to super-intelligently figure out what is wrong with the impleme= ntation itself and then do a proper action to continue the session. Rather,= in practice, I would think the signalling does not change anything to the = session itself. For the codec implementation debugging purpose itself, enco= ders are always free to send the MD5 hash in the decoded picture hash SEI m= essages and decoders are free to parse and compare it, I don't see a need f= or yet another standardize effort for that. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Monday, May 19, 2014 6:29 AM To: Yago Sanchez Cc: payload@ietf.org; Wang, Ye-Kui Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, Yago, all, Let me start with some further motivation for why I think it would be usefu= l to include MD5 information in RPSI. I see two categories of "errors" that= can cause encoder and decoder MD5 mismatch: 1. External causes. It is possible that a bit-error in a bitstream is= not detected during decoding, causing a decoded picture to have different = values compared to the reconstructed picture at the encoder. It is also pos= sible that decoded pictures or reconstructed pictures are stored on a media= that is not 100% reliable (e.g. due to malfunctioning hardware). Having a = single value wrong in a reference picture can quite fast propagate to sever= e visual artifacts due to temporal prediction. 2. Implementation causes. Each HEVC encoder and decoder implementatio= n (both hardware and software) is an interpretation of the more than 300 pa= ges long HEVC specification and there is always the risk that there are som= e parts of the specification interpreted differently. The reference encoder= and decoder (HM) can perform guidance here but HM is far from "complete" i= n the sense that it can test all encoder (bitstream) features fully or corr= ectly report all illegal bitstreams to be non-conforming. There is also the= risk that an implementation contains bugs that appear only for very rare c= ases. Our motivation for including MD5 in RPSI is primarily based on the second c= ategory (although the first category should not be ignored). It is true tha= t you would ideally want all deployed encoders and decoders to be fully sta= ndards compliant with no exceptions. However, history has taught us that th= is is unfortunately not the case. For h.264, even in the reference software= JM, bugs have been found several years after h.264 was standardized (examp= le: https://ipbt.hhi.fraunhofer.de/mantis/view.php?id=3D193). And when x264= started using weighted prediction several decoders silently accepted those= bitstreams while displaying erroneous video (http://x264dev.multimedia.cx/= archives/212#more-212). I would not expect HEVC with all its different poss= ible combinations of block sizes and new coding tools to be easier to imple= ment correct compared to h.264. We believe it would be very useful to provide better tools for discovering = incompatibility issues and be able to automatically trigger events based on= the detection of MD5 mismatch. It could for example include: - Taking immediate action to solve the problem such as sending an = IDR picture - Change the configuration of a session with the hope of finding a= configuration which does not cause encoder-decoder problems (e.g. by using= a more basic set of tools or by switching profie/level) - Gather statistics for which clients does not work with which cli= ents and under which circumstances See further comments inline. Best Regards Jonatan From: Yago Sanchez [mailto:yago.sanchez@hhi.fraunhofer.de] Sent: den 17 maj 2014 12:47 To: Jonatan Samuelsson Cc: payload@ietf.org; Wang, Ye-Kui Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Hi Jonatan, Similar to Ye-Kui's comments, on the inclusion of MD5 in the RPSI, it is no= t clear to me why this could be useful. When talking about "incompatibility= " about encoder and decoder this would mean that one of them is not properl= y working, i.e. it does not fully conform to the standard. In such a case I= personally do not think that this is an issue needed to be solved with the= RPSI but at the development phase of the encoder/decoder. I would assume h= ere that both encoder and decoder are conforming to the standard. For other cases, I cannot think of any case of a picture being "correctly" = decoded, while being a mismatch between encoder and decoder. Is there any c= ase where this happens that I am missing? Best regards, Yago On 17 May 2014, at 01:09, Wang, Ye-Kui > wrote: Hi Jonatan, Thanks for reviewing the new version. Please see my replies inline below, i= ncluding some comments on the two newly proposed features related to RPSI. = For these two features, let's first discuss whether to have them in this pa= yload format document before going into the details in text proposed in ano= ther email. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Wednesday, May 14, 2014 1:58 AM To: Wang, Ye-Kui; payload@ietf.org Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' [YK]: Thanks! To be done in the next version. B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. [YK]: Thanks! To be done in the next version. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? [YK]: The intended use of the SLI message as specified is to indicate the l= oss of CTBs regardless of whether and how slices are in use and whether and= how tiles are in use. The semantics of the "Number" field is clear to me t= oo - why it is not clear? Note that the semantics of slice_segment_address = in the HEVC spec itself is also in CTB raster scan order, regardless of whe= ther and how tiles are in use. Personally I'd prefer to keep the semantics = of SLI to be generic, and also aligned with the semantics of slice_segment_= address in the HEVC spec. [JS] I guess I'm missing something here. Let's look at a very simple examp= le of a picture of 4x3 CTBs with two tiles, one to the right and one to the= left, each signaled in a separate slice. The CTB addresses in CTB raster scan order of the picture is: ------------- | 0| 1| 2| 3| | 4| 5| 6| 7| | 8| 9|10|11| ------------- With two tiles layed out as follows: ------------- | A| A| B| B| | A| A| B| B| | A| A| B| B| ------------- the CTB address in tile scan is: ------------- | 0| 1| 6| 7| | 2| 3| 8| 9| | 4| 5|10|11| ------------- Now, if the second tile (second slice) is lost. I should obviously set the = value of "First" to 2 (since that is the CTB address in CTB raster scan ord= er of the picture), but what value should I set for "Number"? I would like = to set it to 6 since that is the number of CTBs that are lost. But if I cou= nt in CTB raster scan order of the picture I get to 10 before I reach the l= ast CTB that was lost. This means some CTBs needs to be indicated as lost e= ven though they were not. Or do I misinterpret the following sentence: The subfield "Number" MUST be set to the number of consecutive lost CTBs, a= gain in CTB raster scan order of a picture. D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? [YK]: To me this change would make the semantics a lot less clear and the m= essage less useful. Also, each dependent slice segment has slice_segment_ad= dress signalled too, while FUs are supposed to be assembled before sending = to the decoder - thus from the decoder point of view FUs do not need to be = considered. [JS] Sending incomplete FUs to the decoder can significantly improve error = concealment algorithms. However, this is just a minor comment from my side.= It is anyway up to the receiver to decide how much data is reported to be = lost regardless of how much it actually received. E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsbconsists of = fewer than 6 bits. [YK]: Good point. To be done in the next version unless the discussion lead= s into a different conclusion. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' [YK]: To be done in the next version. Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. [YK]: A few points to discuss. G.1: Is it backward compatible to RFC 4585 t= o use one RPSI message to convey more than one reference picture? Would it = be better to define a new message for this purpose if it is deemed useful? [JS] I don't see anything in RFC 4585 that would prohibit including more th= an one reference picture in the "Native RPSI bit string defined per codec" = field. G.2: The concept applies to any video codec that supports multiple referenc= e pictures, is not specific to HEVC, thus would it be better if this is dis= cussed as a generic mechanism, similarly as the SPLI message included in dr= aft-ietf-payload-rtp-h265-01 but dropped later for the very reason? [JS] This would be an option but I don't think it's needed since RPSI in RF= C 4585 is already generic enough to govern this also for other codecs. G.3: On the usefulness of this functionality seems to be unclear to me eith= er. If the last correct picture before an error occurs is known, it is also= known that the reference pictures of the last correct pictures are correct= , thus the encoder can anyway choose to use one or more of these pictures, = when available, for encoding the next picture. Thus, it might be sufficient= just to slightly change the semantics of the RPLI message, to say that the= encoder can choose to use one or more of the identified picture and its re= ference pictures for encoding the next picture. [JS] The strength of RPSI in my opinion is that it can be used to recover f= rom errors that is not a simple loss-of-a-NAL-unit-error (for this case gen= eric NACK, SLI and PLI are probably better suited). An RPSI message can be= used to try to recover from any type of divergence between encoder and dec= oder without the need of a complete reset (i.e. through IDR picture). For s= uch scenarios it might be very difficult to identify exactly which referenc= e pictures are still available (and which of them are correct, as addressed= by suggestion H. below) and it would be dangerous to assume that all refer= ence pictures of one specific reference pictures will be available. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be correct 2: The MD5 of the reference picture is incorrect (i.e. do NOT us= e for reference) 3: The MD5 is included in the RPSI message (directly following t= he PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. [YK]: Firstly, in my understanding, the decoder picture hash SEI message is= very useful for debugging in development of encoder and decoder implementa= tions, as used by the JCT-VC for the development of the HEVC reference soft= ware, and it is intended for use with that purpose. Using of it for error r= esilience in communications is an overkill to me. For example, you would ne= ed 48 bytes to signal the MD5 hash for each picture. [JS] It would still be optional to include those 48 bytes of MD5 info, and = if they can be used to detect errors that would otherwise not be detected, = then 48 bytes per reference picture does not sound much compared to the typ= ical bitrates for video streams. Secondly, it is architecturally incorrect to couple this with the RPSI feed= back message, as the picture identified is supposed to be correctly decoded= by the decoder and the purpose of the message is to request the encoder to= use that picture for encoding of the next picture, [JS] You are right that the identified picture(s) is supposed to be correct= . The proposed usage of MD5 provides a mechanism for verifying that a pictu= re is actually correct. thus why would you even indicate a picture that is incorrect using an RPSI = feedback message? [JS] See further motivation at the top of this email. That information can = be used to identify incompatibility issues for immediate actions (change co= nfiguration) and long-term actions (identify non-conforming encoders/decode= rs). In scenarios where Full Intra reset is not feasible an encoder may use= this information to perform gradual decoder refresh until the encoder and = decoder have been verified to have identical reference pictures in their bu= ffers. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 Gro= up of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ 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 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD6EFnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonatan, All,

 <= /p>

On item C: In that exampl= e, you report three set of consecutive CTB losses, (2,2), (6, 2), and (10, = 2). The semantics can only be interpreted this way, no?

 <= /p>

On item D: It is up to th= e receiver to decide how much data is reported to be lost regardless of how= much it actually received, but whatever it reports, it should report something that is accurate enough for the sender side to mak= e meaningful reaction.

 <= /p>

On item G: I’d like= to see some opinions from others, particularly those who have been deeply = involved in RFC 4585 to comment on the G.1 and G.2. On G.3, the wording “the encoder can choose to= use one or more of the identified picture and its reference pictures for e= ncoding the next picture” does not at all assume that all reference pictures of one specific referen= ce pictures will be available, it just means that use whichever from that s= et when available.

 <= /p>

On item H: Assume that th= e MD5 support as part of RPSI is specified, once a mismatch due to non-conf= ormation encoder/decoder implementations is known, you still need people to get involved to debug and to see what is the reason of the = mismatch, and you cannot assume the buggy implementations to be so powerful= to super-intelligently figure out what is wrong with the implementation it= self and then do a proper action to continue the session. Rather, in practice, I would think the signalling= does not change anything to the session itself. For the codec implementati= on debugging purpose itself, encoders are always free to send the MD5 hash = in the decoded picture hash SEI messages and decoders are free to parse and compare it, I don’t see = a need for yet another standardize effort for that.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan = Samuelsson [mailto:jonatan.samuelsson@ericsson.com]
Sent: Monday, May 19, 2014 6:29 AM
To: Yago Sanchez
Cc: payload@ietf.org; Wang, Ye-Kui
Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Dear Ye-Kui, Yago, all,

 <= /p>

Let me start with some fu= rther motivation for why I think it would be useful to include MD5 informat= ion in RPSI. I see two categories of “errors” that can cause encoder and decoder MD5 mismatch:

1. = ;      External causes. = It is possible that a bit-error in a bitstream is not detected during decod= ing, causing a decoded picture to have different values compared to the reconstructed picture at the encoder. It is also possible = that decoded pictures or reconstructed pictures are stored on a media that = is not 100% reliable (e.g. due to malfunctioning hardware). Having a single= value wrong in a reference picture can quite fast propagate to severe visual artifacts due to temporal predic= tion.

2. = ;      Implementation ca= uses. Each HEVC encoder and decoder implementation (both hardware and softw= are) is an interpretation of the more than 300 pages long HEVC specification and there is always the risk that there are some parts = of the specification interpreted differently. The reference encoder and dec= oder (HM) can perform guidance here but HM is far from “complete̶= 1; in the sense that it can test all encoder (bitstream) features fully or correctly report all illegal bitstreams to b= e non-conforming. There is also the risk that an implementation contains bu= gs that appear only for very rare cases.

 <= /p>

Our motivation for includ= ing MD5 in RPSI is primarily based on the second category (although the fir= st category should not be ignored). It is true that you would ideally want all deployed encoders and decoders to be fully standard= s compliant with no exceptions. However, history has taught us that this is= unfortunately not the case. For h.264, even in the reference software JM, = bugs have been found several years after h.264 was standardized (example: https://ipbt.hhi.fraunhofer.de/mantis/view.ph= p?id=3D193). And when x264 started using weighted prediction sev= eral decoders silently accepted those bitstreams while displaying erroneous= video (http://x264dev.multimedia.cx/archives/212#more-21= 2). I would not expect HEVC with all its different possible combinations of bl= ock sizes and new coding tools to be easier to implement correct compared t= o h.264.

 <= /p>

We believe it would be ve= ry useful to provide better tools for discovering incompatibility issues an= d be able to automatically trigger events based on the detection of MD5 mismatch. It could for example include:

- =          Taking immediate = action to solve the problem such as sending an IDR picture

- =          Change the config= uration of a session with the hope of finding a configuration which does no= t cause encoder-decoder problems (e.g. by using a more basic set of tools or by switching profie/level)

- =          Gather statistics= for which clients does not work with which clients and under which circums= tances

 <= /p>

See further comments inli= ne.

 <= /p>

Best Regards Jonatan=

 <= /p>

From: Yago San= chez [mailto:yago.sanchez= @hhi.fraunhofer.de]
Sent: den 17 maj 2014 12:47
To: Jonatan Samuelsson
Cc: payload@ietf.org; Wang, = Ye-Kui
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Hi Jonatan, 

 

Similar to Ye-Kui’s comments, on the inclusion= of MD5 in the RPSI, it is not clear to me why this could be useful. When t= alking about “incompatibility” about encoder and decoder this w= ould mean that one of them is not properly working, i.e. it does not fully conform to the standard. In such a case I personall= y do not think that this is an issue needed to be solved with the RPSI but = at the development phase of the encoder/decoder. I would assume here that b= oth encoder and decoder are conforming to the standard.

 

For other cases, I cannot think of any case of a pic= ture being “correctly” decoded, while being a mismatch between = encoder and decoder. Is there any case where this happens that I am missing= ?

 

Best regards,

Yago

 

On 17 May 2014, at 01:09, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:<= o:p>

 

Hi Jonatan,

 <= /p>

Thanks for reviewing the = new version. Please see my replies inline below, including some comments on= the two newly proposed features related to RPSI. For these two features, let’s first discuss whether to have them in this paylo= ad format document before going into the details in text proposed in anothe= r email.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Wednesday, M= ay 14, 2014 1:58 AM
To: Wang, Ye-Kui;<= span class=3D"apple-converted-space"> payload@ietf.org
Subject: RE: [payl= oad] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear Ye-Kui, editors, all,<= /o:p>

Thanks for improving the draft and maki= ng the new version available. I read through the new section 8 in the lates= t draft, in which more feedback features have been added (which I think is very good). I have some minor comments and then some sug= gestions for improving the RPSI signalling. Compared to earlier standards, = HEVC contains a new very useful SEI message that can be used to check integ= rity and correctness of decoded pictures and thereby detect errors that are not necessarily due to packet = losses: Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also in t= he RTP payload format for HEVC in order to make implementations even more robust.

First some minor comments:<= /o:p>

In 8.1:

A. Remove one instance of 'the loss of' in the sentence: ' <= span style=3D"font-size:10.0pt;font-family:"Courier New"">As spec= ified in RFC 4585 section 6.3.1, the reception of a picture loss indication= by a media sender indicates the loss of "the loss of an undefined amount of coded video data belonging to one or more pictur= es.".'

 <= /p>

[YK]: Thanks! To be done = in the next version.

B. The 'BE' in 'SHOULD BE' should not b= e using CAPITAL LETTERS.

[YK]: Thanks! To be done = in the next version.

 <= /p>

In 8.2:

C. Regarding 'the loss of a number of = Coded Tree Blocks (CTBs) in CTB raster scan order of a picture.'. When tiles are used, the loss of a slice does typically not result in lost= CTBs in raster scan order of the picture. The text does not describe how t= o calculate the "Number" field for this case. Wouldn't it be bett= er to use 'tile scan' in order to correctly identify what part of the = picture was lost?

 <= /p>

[YK]: The intended use of= the SLI message as specified is to indicate the loss of CTBs regardless of= whether and how slices are in use and whether and how tiles are in use. The semantics of the “Number” field is clear to me= too – why it is not clear? Note that the semantics of slice_segment_= address in the HEVC spec itself is also in CTB raster scan order, regardles= s of whether and how tiles are in use. Personally I’d prefer to keep the semantics of SLI to be generic, and also alig= ned with the semantics of slice_segment_address in the HEVC spec.

[JS] I guess I’m&nb= sp; missing something here. Let’s look at a very simple example of a = picture of 4x3 CTBs with two tiles, one to the right and one to the left, each signaled in a separate slice.

The CTB addresses in CTB = raster scan order of the picture is:

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

| 0| 1| 2| 3|

| 4| 5| 6| 7|

| 8| 9|10|11|

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

With two tiles layed out = as follows:

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

| A| A| B| B|

| A| A| B| B|

| A| A| B| B|

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

the CTB address in tile s= can is:

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

| 0| 1| 6| 7|

| 2| 3| 8| 9|

| 4| 5|10|11|

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

Now, if the second tile (= second slice) is lost. I should obviously set the value of “FirstR= 21; to 2 (since that is the CTB address in CTB raster scan order of the picture), but what value should I set for “Number”? I woul= d like to set it to 6 since that is the number of CTBs that are lost. But i= f I count in CTB raster scan order of the picture I get to 10 before I reac= h the last CTB that was lost. This means some CTBs needs to be indicated as lost even though they were not. Or do I misi= nterpret the following sentence:

The subfield "Number&= quot; MUST be set to the number of consecutive lost CTBs, again in CTB rast= er scan order of a picture.

D. Regarding 'the subfield "First= " MUST be set to the CTB address of the first lost CTB'. Wouldn't it be better to require "First" to= be set to a number that is lower than or equal to the CTB address of the f= irst lost CTB, since it might be difficult to deduce the exact CTB address of t= he first lost CTB in the case of loss of  dependent slices and/or frag= mentation units?

 <= /p>

[YK]: To me this change w= ould make the semantics a lot less clear and the message less useful. Also,= each dependent slice segment has slice_segment_address signalled too, while FUs are supposed to be assembled before sending to th= e decoder – thus from the decoder point of view FUs do not need to be= considered.

[JS] Sending incomplete F= Us to the decoder can significantly improve error concealment algorithms. H= owever, this is just a minor comment from my side. It is anyway up to the receiver to decide how much data is reported to be lost r= egardless of how much it actually received.

E. Regarding 'The subfield "Pictu= reID" MUST  be  set  to  the  6  least s= ignificant  bits  of  a  binary representation  of  the  value  of slice_pic_order_cnt_lsb  of  t= he picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of  = ;slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_lsbcon= sists of  fewer than 6 bits.

[YK]: Good point. To be d= one in the next version unless the discussion leads into a different conclu= sion.

 <= /p>

F. Regarding the sentence: 'In many ca= ses, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncor= rupted regions of the picture through motion compensation, and reference pi= cture selection can also be used to "clean up" the corrupted pict= ure, which is usually more efficient and less likely to generate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: = ''

[YK]: To be done in the n= ext version.

 <= /p>

Regarding RPSI (section 8.3) I would li= ke to propose the following changes:

G. Add the possibility to include more = than one reference picture in the RPSI message so that the encoder can sele= ct to use one or more of the pictures included in RPSI message. Using multiple pictures for reference is a key feature in HEVC which subst= antially improves coding efficiency. In the case where multiple earlier pic= tures are available for reference it is beneficial to let the encoder decid= e which one(s) to use for reference instead of relying on the decoder to make that selection.

[YK]: A few points to dis= cuss. G.1: Is it backward compatible to RFC 4585 to use one RPSI message to= convey more than one reference picture? Would it be better to define a new message for this purpose if it is deemed useful?

[JS] I don’t see an= ything in RFC 4585 that would prohibit including more than one reference pi= cture in the "Native RPSI bit string defined per codec" field.

G.2: The concept applies = to any video codec that supports multiple reference pictures, is not specif= ic to HEVC, thus would it be better if this is discussed as a generic mechanism, similarly as the SPLI message included in draft-ie= tf-payload-rtp-h265-01 but dropped later for the very reason?

[JS] This would be an opt= ion but I don’t think it’s needed since RPSI in RFC 4585 is alr= eady generic enough to govern this also for other codecs.

G.3: On the usefulness of= this functionality seems to be unclear to me either. If the last correct p= icture before an error occurs is known, it is also known that the reference pictures of the last correct pictures are correct, thus= the encoder can anyway choose to use one or more of these pictures, when a= vailable, for encoding the next picture. Thus, it might be sufficient just = to slightly change the semantics of the RPLI message, to say that the encoder can choose to use one or more= of the identified picture and its reference pictures for encoding the next= picture.

[JS] The strength of RPSI= in my opinion is that it can be used to recover from errors that is not a = simple loss-of-a-NAL-unit-error (for this case generic NACK,  SLI and PLI are probably better suited). An RPSI message can be used= to try to recover from any type of divergence between encoder and decoder = without the need of a complete reset (i.e. through IDR picture). For such s= cenarios it might be very difficult to identify exactly which reference pictures are still available (and which o= f them are correct, as addressed by suggestion H. below) and it would be da= ngerous to assume that all reference pictures of one specific reference pic= tures will be available.

 <= /p>

H. Using the 2 currently unused bits in= the 'Native RPSI bit string defined per codec' for adding the possibility of including information regarding the MD5 in the R= PSI message as follows:

0:      &= nbsp;     No information regarding the MD5 available 1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)

The last option can be used when the en= coder does not include MD5s in-band but wants to check the MD5 before using= a selected picture for reference. Typically this will be more bit-efficient than including decoded picture hash SEI messages in-ban= d.

In my opinion it would be very useful t= o be able to include information regarding the correctness of the decoded p= ictures, e.g. to detect incompatibility issues and bit errors. I will send a suggestion for the text changes needed to enable this, hopef= ully later today.

 <= /p>

[YK]: Firstly, in my unde= rstanding, the decoder picture hash SEI message is very useful for debuggin= g in development of encoder and decoder implementations, as used by the JCT-VC for the development of the HEVC reference software, = and it is intended for use with that purpose. Using of it for error resilie= nce in communications is an overkill to me. For example, you would need 48 = bytes to signal the MD5 hash for each picture.

[JS] It would still be op= tional to include those 48 bytes of MD5 info, and if they can be used to de= tect errors that would otherwise not be detected, then 48 bytes per reference picture does not sound much compared to the typical bi= trates for video streams.   &nb= sp;

Secondly, it is architect= urally incorrect to couple this with the RPSI feedback message, as the pict= ure identified is supposed to be correctly decoded by the decoder and the purpose of the message is to request the encoder to use th= at picture for encoding of the next picture,

[JS] You are right that t= he identified picture(s) is supposed to be correct. The proposed usage of M= D5 provides a mechanism for verifying that a picture is actually correct.

thus why would you even i= ndicate a picture that is incorrect using an RPSI feedback message?<= o:p>

[JS] See further motivati= on at the top of this email. That information can be used to identify incom= patibility issues for immediate actions (change configuration) and long-term actions (identify non-conforming encoders/decoders). In scen= arios where Full Intra reset is not feasible an encoder may use this inform= ation to perform gradual decoder refresh until the encoder and decoder have= been verified to have identical reference pictures in their buffers.

Best Regards Jonatan<= /p>

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear All,

 

Compare to -02, we have addressed most = of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Berna= rd, ..., as well as the following changes:

- Addition of sprop-sei, as suggested b= y Stephan on Apr. 23 to the reflector, agreed by most of the authors, no ob= jection from anyone.

- Addition of an informative, brief des= cription of the display orientation SEI message, which is among one of thos= e new SEI messages that have some systems usage.

- Addition of a definition of NAL-unit-= like structure. The term was used but not defined earlier.

- Addition of descriptions for use of t= he PLI and SLI messages (specified in RFC 4585) and the FIR message (specif= ied in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed= during the presentation at the previous IETF meeting

 

Remaining open issues:

- On profile-compatibility-indicator an= d interop-constraints (raised by Magnus, being discussed among Magnus, myse= lf and Yago, no conclusion yet)

- On recv-sub-layer-id and using of spr= op-vps for session negotiation (raised by Magnus, still being discussed amo= ng the authors and Magnus)

- On source-specific sprop parameter se= ts (raised by Magnus, still being discussed among the authors and Jonathan = for exact text changes)

- On using a different parameter catego= ry for level-id (raised by Magnus, discussed between Magnus and myself, no = conclusion yet)

- I just noticed that the definition of= "packet stream" itself needs to be changed back to "RTP str= eam"

 

We will try to address the above open i= ssues as soon as possible. At the same time, further review and comments ar= e welcome.

 

BR, YK

 

-----Original Message-----<= /o:p>

From: payload [mailto:payload-bounces@iet= f.org] On Behalf Of <= /span>internet-drafts@ietf.org

Sent: Wednesday, April 30, 2014 10:34 A= M

Subject: [payload] I-D Action: draft-ie= tf-payload-rtp-h265-03.txt

 

 

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.

 

      &nb= sp; Title           : RTP= Payload Format for High Efficiency Video Coding

      &nb= sp; Authors         : Ye-Kui Wang

      &nb= sp;            =        Yago Sanchez

      &nb= sp;            =        Thomas Schierl

      &nb= sp;            =        Stephan Wenger

      &nb= sp;            =        Miska M. Hannuksela<= /p>

      &nb= sp; Filename        : draft-ietf-payload= -rtp-h265-03.txt

      &nb= sp; Pages           : 92<= /span>

      &nb= sp; Date            = : 2014-04-30

 

Abstract:

   This memo describes an RTP= payload format for the video coding

   standard ITU-T Recommendat= ion H.265 and ISO/IEC International

   Standard 23008-2, both als= o known as High Efficiency Video Coding

   (HEVC) [HEVC] and develope= d by the Joint Collaborative Team on Video

   Coding (JCT-VC).  The= RTP payload format allows for packetization of

   one or more Network Abstra= ction Layer (NAL) units in each RTP packet

   payload, as well as fragme= ntation of a NAL unit into multiple RTP

   packets.  Furthermore= , it supports transmission of an HEVC bitstream

   over a single as well as m= ultiple RTP streams.  The payload format

   has wide applicability in = videoconferencing, Internet video

   streaming, and high bit-ra= te entertainment-quality video, among

   others.<= /p>

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

payload mailing list<= /p>

 

_______________________________________= ________

payload mailing list<= /p>

 

______________________________________= _________
payload mailing list
payload@ie= tf.org
https://www.ietf.org/mailman/listinfo/payload

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83452BD6EFnasanexd02fnaqu_-- From nobody Tue May 20 03:13:07 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 574FF1A0679 for ; Tue, 20 May 2014 03:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 XUoDQQpFSI96 for ; Tue, 20 May 2014 03:12:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6604E1A04B6 for ; Tue, 20 May 2014 03:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44556; q=dns/txt; s=iport; t=1400580779; x=1401790379; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4kVShYy0lP9vUx2vJIDAIcvgD4ojpiJvPiIN0Cb9uP4=; b=EskSO1lWCZhzoyEDTwEn/Mz8Ou8qt8XNoAIO8k4ffewTYfQ8544AnXOA uyGeiM1k9/nG50aMTRS7Tq/7la3ScgshL0TkG1gYnwBdYzZ5SgUJOa78s ixDsNclrlIkWYA/TXeWYKdm3SzpIrmrZvvWwsliXaQptCgE+7XRJotMqZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAEgqe1OtJV2U/2dsb2JhbABZgkJEUVi7EoFCAYZpUQGBGRZ0giUBAQEEAQEBCQ4TKBkLDAICAgEIEQMBAQEBIAEGBxsGBgsUCQgCBAENBRuIEgMRDcwLDYYvFwSJLIMJgT4sBxMNBAYBBgOENwSVZIIIgXSBPYtyA4VrgziBb0E X-IronPort-AV: E=Sophos;i="4.98,873,1392163200"; d="scan'208,217";a="326284309" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 20 May 2014 10:12:57 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4KACvme011072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 10:12:57 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.4]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 20 May 2014 05:12:55 -0500 From: "Geir Sandbakken (geirsand)" To: "Wang, Ye-Kui" , Jonatan Samuelsson Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/7flCDn/vQEuMFGb3bWwIkprJn2UAgAAu2ACAB0rPAIAAAcMAgAAPY4CAAG4HgIAEG2cAgAAFvQCAN7lGAIAS6BAAgCnbcYA= Date: Tue, 20 May 2014 10:12:55 +0000 Message-ID: References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C5C94@ESESSMB109.ericsson.se> <634D3B5D82E3214DA9B6A36D5F50DB231C5CEC@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83387D5BA4@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB231C7BA8@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83452011C7@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A834523BADE@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A834523BADE@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.61.110.48] Content-Type: multipart/alternative; boundary="_000_CFA0EA6A99F6Egeirsandciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/TwddwRPT9eM9NJcrDM6mTr9ODns Cc: "David Benham \(dbenham\)" , "payload@ietf.org" , "Tom Kristensen \(tomkrist\)" 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, 20 May 2014 10:13:03 -0000 --_000_CFA0EA6A99F6Egeirsandciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jonathan, Ye-Kui, If this feedback is too late, please ignore. The language improvements be= low are very nice, but the move from MUST to SHOULD has some implications.= The reason we promoted the use of MUST is that max-fps represents a restr= iction =96 not an indication. It=92s a restriction that include the surro= unding media pipeline together with the actual decoder instance. As it has= wider scope than the decoder itself, it can not be part of the restriction= s set up by the levels. Violating the max-fps usually moves you into unch= arted waters similar to violating any other restriction. Consequently if w= e are to have an exception for pre-encoded streams for the max-fps restrict= ion, similar exceptions should be made for any of them. Previously in this thread the a=3Dframerate attribute was suggested as a po= tential solution. IMHO there are two caveats. Firstly it is only an indic= ation, and secondly that it cover all media codecs for a single media line= . This creates the limitation of having the same media pipeline for all co= dec types, and such architectural limitations are best avoided. The latte= r caveat can be remedied by splitting codecs over multiple media lines, bu= t we don=92t want the nice participants of SipIt to shed more tears than st= rictly required. Thanks, Geir A From: , Ye-Kui > Date: Wednesday 23 April 2014 23:00 To: Jonatan Samuelsson >, Tom Kristensen <2mkristensen@gmail.com> Cc: "payload@ietf.org" >, "Tom Kristensen (tomkrist)" > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter We need to proceed. In case there is no more input, I suggest that we go ah= ead to change the semantics as follows: 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 receivedeff= ectively processed by the receiver. The max-fps parameter MAY be used to s= ignal that the receiver has a constraint in that it is not capable of decod= ing video efficiently processing video effectively at the full picture rate= that is implied by the highest level and, when present, one or more of the= parameters max-lsr, max-lps, and max-br. The value of max-fps is not necessarily the picture rate at which the 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 SHOULD use a picture rate equal to or less than this value= . An exception is when sending a pre-encoded bitstream the picture rate ma= y be greater than the value of max-fps. In cases where the max-fps paramet= er is absent the encoder is free to choose any picture rate according to th= e highest level and any signaled optional parameters. The value of max-fps MUST be smaller than or equal to the full picture rate= that is implied by the highest level and, when present, one or more of the= parameters max-lsr, max-lps, and max-br. [Note that addition of this sente= nce is to address the Magnus=92 comment on a value range for each parameter= .] Jonatan, please suggest if you have a better exception case in mind (note t= hat nowadays generally an exception case needs to be clarified for each SHO= ULD wording). BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Friday, April 11, 2014 1:17 PM To: Jonatan Samuelsson; Tom Kristensen Cc: payload@ietf.org; Tom Kristensen (tomkrist@cis= co.com) Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter We should also try to conclude herein. Tom, do you have any response to Jonatan=92s comment below? BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonatan Samuel= sson Sent: Friday, March 07, 2014 12:20 AM To: Tom Kristensen; Wang, Ye-Kui Cc: Tom Kristensen (tomkrist@cisco.com); payload= @ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter 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: =93If the motivation for max-fps is only for SDP O/A, why isn't the SDP att= ribute a=3Dframerate sufficient?=94 and to Magnus=92 earlier question: =93The issues with the media pipeline has they been with the reception of t= he high framerate of packets and forwarding them to the decoder or the play= back part, i.e. handling of the decoded picture?=94 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 (tomk= rist@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_CFA0EA6A99F6Egeirsandciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <18AA91ACD241E04F99983CC8907615FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Jonathan, Ye-Kui, 

If this feedback is too late,  please ignore.  The language = improvements below are very nice,  but the move from MUST to SHOULD ha= s some implications.  The reason we promoted the use of MUST is that m= ax-fps represents a restriction =96 not an indication.   It=92s a restriction that include the surrounding media pipeline to= gether with the actual decoder instance.  As it has wider scope than t= he decoder itself, it can not be part of the restrictions set up by the lev= els.   Violating the max-fps usually moves you into uncharted waters similar to violating any other restriction.  Co= nsequently if we are to have an exception for pre-encoded streams for the m= ax-fps restriction,  similar exceptions should be made for any of them= .

Previously in this thread the a=3Dframerate attribute was suggested as= a potential solution.  IMHO there are two caveats.  Firstly it i= s only an indication,  and secondly that it cover all media codecs for= a single media line.  This creates the limitation of having the same media pipeline for all codec types,  and such arch= itectural limitations are best avoided.  The latter caveat can be reme= died by splitting codecs over multiple media lines,  but we don=92t wa= nt the nice participants of SipIt to shed more tears than strictly required. 

Thanks,
Geir A

From: <Wang>, Ye-Kui <yekuiw@qti.qualcomm.com>
Date: Wednesday 23 April 2014 23:00=
To: Jonatan Samuelsson <jonatan.samuelsson@ericsson.com= >, Tom Kristensen <2mkr= istensen@gmail.com>
Cc: "payload@ietf.org" <payload@ietf.org>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Subject: Re: [payload] #12 (rtp-h26= 5): The max-fps parameter

We need to proceed. In case there i= s no more input, I suggest that we go ahead to change the semantics as foll= ows:

 

max= -fps:

The v= alue of max-fps is an integer indicating the maximum picture rate in units = of hundreds of pictures per second that can be efficiently receivedef= fectively 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 decod= ing video efficiently processing video eff= ectively at the full picture rate that is implied by the highest lev= el and, when present, one or more of the parameters max-lsr, max-lps, and m= ax-br.

=  

The v= alue of max-fps is not necessarily the picture rate at which the maximum pi= cture size can be sent, it constitutes a constraint on maximum picture rate= for all resolutions.

=  

Infor= mative 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 us= ed to signal a constraint, lowering the maximum picture rate from what is implied by other parameters.

=  

The e= ncoder MUST SHOULD use a picture rate equal to or less than this value.  An exception is when sending a pre-encoded bitstream the picture rate may b= e greater than the value of max-fps.  In cases where the max-fp= s parameter is absent the encoder is free to choose any picture rate accord= ing to the highest level and any signaled optional parameters.

=  

The value of max-fps MUST= be smaller than or equal to the full picture rate that is implied by the h= ighest level and, when present, one or more of the parameters max-lsr, max-lps, and max-br. [Note that addition of this sentence is to address the Magnus=92 comment on= a value range for each parameter.]

 

Jonatan, please suggest if you have= a better exception case in mind (note that nowadays generally an exception= case needs to be clarified for each SHOULD wording).

 

BR, YK

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Friday, April 11, 2014 1:17 PM
To: Jonatan Samuelsson; Tom Kristensen
Cc: payload@ietf.org; Tom Kr= istensen (tomkrist@cisco.com)
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter

 

We should also try to conclude here= in.

 

Tom, do you have any response to Jo= natan=92s comment below?

 

BR, YK

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Jonatan Samuelsson
Sent: Friday, March 07, 2014 12:20 AM
To: Tom Kristensen; Wang, Ye-Kui
Cc: Tom Kristensen (tomkrist@c= isco.com); payload@ietf.org
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter<= o:p>

 

Thanks Tom for your feedback,

 

For me to get a better understandin= g of if it is reasonable to make an exception from the design principle of = not re-defining level definitions from the video specification, it would be very valuable with answers to my earl= ier question:

 

=93If the motivation for max= -fps is only for SDP O/A, why isn't the SDP attribute a=3Dframerate suffici= ent?=94

 

and to Magnus=92 earlier question:<= /span>

 

=93The 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?= =94

 

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 Sand= bakken (geirsand); payload@ietf.org; Tom Kristensen (<= a href=3D"mailto:tomkrist@cisco.com">tomkrist@cisco.com)
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter<= o:p>

 

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_CFA0EA6A99F6Egeirsandciscocom_-- From nobody Tue May 20 08:21: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 B4F8C1A074A for ; Tue, 20 May 2014 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651] 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 OIjGkHAmyBp9 for ; Tue, 20 May 2014 08:21:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAD41A073C for ; Tue, 20 May 2014 08:21:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 30C907C0375 for ; Tue, 20 May 2014 17:21:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsorbzX67-1j for ; Tue, 20 May 2014 17:21:17 +0200 (CEST) Received: from [172.31.57.6] (unknown [72.14.227.113]) by mork.alvestrand.no (Postfix) with ESMTPSA id 54BD57C0218 for ; Tue, 20 May 2014 17:21:16 +0200 (CEST) Message-ID: <537B72EB.3080509@alvestrand.no> Date: Tue, 20 May 2014 11:21:15 -0400 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: payload@ietf.org References: <52F42707.10606@alvestrand.no> In-Reply-To: <52F42707.10606@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070607060507070704010801" Archived-At: http://mailarchive.ietf.org/arch/msg/payload/0gz7H3yqLp5SVNrcVKvsz8fhXFs Subject: Re: [payload] New Version Notification for draft-nandakumar-payload-sdp-max-video-resolution-00.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: Tue, 20 May 2014 15:21:22 -0000 This is a multi-part message in MIME format. --------------070607060507070704010801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a reminder, since Cullen reminded me that this issue has languished: I have seen no response to my February 6 message raising specific issues about max-video-resolution (reproduced below). I have seen no update to max-video-resolution based on the discussion in London. I have seen no action from the chairs to either adopt or reject this work item. As far as I can tell, nothing is happening. If there is no interest in pursuing this work, can we declare that it is not an IETF work item and stop blocking other things on it? Harald On 02/06/2014 07:21 PM, Harald Alvestrand wrote: > On 02/01/2014 02:51 AM, Suhas Nandakumar wrote: >> Hello All >> >> Following draft has been submitted to specify payload format >> parameters indicating an end-point's maximum image resolution receive >> capability in SDP. This draft aims at solving the issue with >> specifying such functionality for VP8 and is also applicable to other >> codecs in general. > > Thank you for finally posting this to the payload list! (The date of > the draft is Dec 7 - I've been waiting for the proponents to make a > public statement about it). > > My biggest worry with this particular proposal is that it modifies the > way a=fmtp is specified. > > As far as I understand, the syntax of a=fmtp has previously been > assumed to be specified completely by the payload specification (viz > the rather non-orthogonal stuff that is in the DTMF payload). > > This specification proposes to add new parameters into a=fmtp that are > applicable to any payload. This seems like a doubtful architectural > decision. > I think it would be cleaner to add a new a= attribute that is > independent of codec (but linked to payload type) containing the > information. > > I also have a nit with the way offer/answer is specified: > > ..... When the direction is > sendonly, these attributes have no interpretation and MUST be ignored > by the receiving Endpoint, if present. > > ...... > > An SDP Answerer MUST NOT include these parameters in the SDP Answer > unless they are specified in the associated SDP Offer. > > > If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless. > > My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply. > > Note: I see absolutely no reason to link this functionality, if > desirable, to the RTP format for VP8. If it needs mandating, it should > be mandated for all video types going forward, including H.265, and > strongly recommended for all video types that have been standardized > in the past. > > If it doesn't need mandating, it doesn't need mandating for anyone. > > > > > >> >> >> URL: >> http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt >> Htmlized: >> http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00 >> >> >> Looking forward for the inputs on how do we take his work ahead. >> >> >> Thanks >> Suhas Nandakumar >> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. --------------070607060507070704010801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Just a reminder, since Cullen reminded me that this issue has languished:

I have seen no response to my February 6 message raising specific issues about max-video-resolution (reproduced below).
I have seen no update to max-video-resolution based on the discussion in London.
I have seen no action from the chairs to either adopt or reject this work item.

As far as I can tell, nothing is happening.

If there is no interest in pursuing this work, can we declare that it is not an IETF work item and stop blocking other things on it?

                   Harald


On 02/06/2014 07:21 PM, Harald Alvestrand wrote:
On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:
Hello All

  Following draft has been submitted to specify payload format parameters indicating an end-point's maximum image resolution receive capability in SDP. This draft aims at solving the issue with specifying such functionality for VP8 and is also applicable to other codecs in general.

Thank  you for finally posting this to the payload list! (The date of the draft is Dec 7 - I've been waiting for the proponents to make a public statement about it).

My biggest worry with this particular proposal is that it modifies the way a=fmtp is specified.

As far as I understand, the syntax of a=fmtp has previously been assumed to be specified completely by the payload specification (viz the rather non-orthogonal stuff that is in the DTMF payload).

This specification proposes to add new parameters into a=fmtp that are applicable to any payload. This seems like a doubtful architectural decision.
I think it would be cleaner to add a new a= attribute that is independent of codec (but linked to payload type) containing the information.

I also have a nit with the way offer/answer is specified:

                          ..... When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.

   ......

   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.


If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless.

My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply.
Note: I see absolutely no reason to link this functionality, if desirable, to the RTP format for VP8. If it needs mandating, it should be mandated for all video types going forward, including H.265, and strongly recommended for all video types that have been standardized in the past.

If it doesn't need mandating, it doesn't need mandating for anyone.







URL:             http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt
Htmlized:        http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00


Looking forward for the inputs on how do we take his work ahead.


Thanks
Suhas Nandakumar


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



-- 
Surveillance is pervasive. Go Dark.



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



-- 
Surveillance is pervasive. Go Dark.
--------------070607060507070704010801-- From nobody Tue May 20 18:38:10 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 D0EAD1A03FB for ; Tue, 20 May 2014 18:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.951 X-Spam-Level: X-Spam-Status: No, score=-6.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 vEH4zMLAdU5s for ; Tue, 20 May 2014 18:37:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AAD1A03F6 for ; Tue, 20 May 2014 18:37:54 -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=1400636274; x=1432172274; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=D9fmD4+0fulGIr4E6j81d12lDiy22yaliiWSRhqWpUk=; b=um5V5EA8WAwps5yieIztEwajMWgXES5mSOPnx244Fc8Zmg0Iq179ot75 B0lNWt8MXBzPjCordLhiZvowJ4bIo5oDYpwpY9n9ydwkeMgpye8RROJb7 5YMq/Q/Qop7S5q5dbRRudD2fuLkVxre2rXTBh213JIasG4SzOVUDcERRB I=; X-IronPort-AV: E=McAfee;i="5600,1067,7444"; a="36284848" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 20 May 2014 18:37:53 -0700 X-IronPort-AV: E=Sophos;i="4.98,877,1392192000"; d="scan'208,217";a="736068715" Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 May 2014 18:37:53 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.156]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0181.006; Tue, 20 May 2014 18:38:27 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Thread-Index: AQHPZJpqbLyXIk9FYUOA5cqUKWqAxJsqbPSAgBXkUACAA4F9oIABU/qAgANR6wD//7w8wIACJhjQ Date: Wed, 21 May 2014 01:38:25 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83452CDDE4@nasanexd02f.na.qualcomm.com> References: <20140430173354.18935.27971.idtracker@ietfa.amsl.com> <8BA7D4CEACFFE04BA2D902BF11719A83452473D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB2321F92D@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A834529B2D3@nasanexd02f.na.qualcomm.com> <634D3B5D82E3214DA9B6A36D5F50DB23231D6F@ESESSMB109.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A83452BD6EF@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83452BD6EF@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83452CDDE4nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/NeZBN6_YDyzW3TKTTUoWTSZlEuE Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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: Wed, 21 May 2014 01:38:05 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452CDDE4nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, The following group of persons had a conference call today (May 20, 2014, 1= 1:00am-12:30pm PDT), with the goal to resolve the remaining open issues for= this payload format, such that it can be finalized as soon as possible due= to the urgent need of the HEVC payload format for the deployment of HEVC: - Magnus Westerlund - Stephan Wenger - Jonatan Samuelsson - Yago Sanchez - Ye-Kui Wang The discussed list of open issues are: 1) Ticket#12 (rtp-h265): The max-fps parameter 2) On source-specific sprop parameter sets 3) On support of a future profile defined as the intersection of more = than one profile 4) On recv-sub-layer-id and using of sprop-vps for session negotiation 5) On the SLI feedback message: in CTB raster scan order or in tile sc= an order, for both FIRST and NUMBER 6) On the RPSI feedback message a. Signalling of more than one reference picture to be used for encod= ing the next picture b. Support of integrity check What we agreed among the participants on the above issues are as follows: 1) Ticket#12 (rtp-h265): The max-fps parameter With the clarifications in the latest email from Geir Sandbakken, we agreed= that it would be OK with the use of the MUST language as Geir suggested. 2) On source-specific sprop parameter sets We agreed to add a clarification sentence like: When conveyed in the "a=3Df= mtp" line of SDP for a particular payload type, the parameters "sprop-vps",= "sprop-sps", and "sprop-pps" MUST be applied to each SSRC with the payload= type. 3) On support of a future profile defined as the intersection of more = than one profile We agreed to have the support, but clearly document the intention of such s= upport, to avoid possible confusions, such as requiring encoders to support= all possible intersections as discussed between Jonatan and myself. Also t= ry to clarify the implications of when the profile related parameters are u= sed with different direction attributes. Magnus kindly agreed to draft some= text. 4) On recv-sub-layer-id and using of sprop-vps for session negotiation We agreed to allow the use of sprop-vps for session negotiation, but requir= e profile, tier, level info to be present in the SDP answer. Compared to co= mpletely removing this mechanism, this approach supports selection of one o= f the multiple operation points, particular when more than one of the opera= tion points comply with the some profile, tier, and level. 5) On the SLI feedback message: in CTB raster scan order or in tile sc= an order, for both FIRST and NUMBER We agreed to keep the current method (i.e. in CTB raster scan order), but c= larify a bit to make it clearer, e.g. including mentioning in some cases wi= th tiles multiple messages might be needed for reporting the loss of one sl= ice. 6) On the RPSI feedback message a. Signalling of more than one reference picture to be used for encod= ing the next picture b. Support of integrity check We agreed to investigate both a and b above in a separate document in a gen= eric way in the context of avtext. Jonatan to initiate the document. For th= is payload format document, we agreed to add the parameter "include-dph", a= s Jonatan suggested to the mailing list. For convenience, the semantics of = this parameter is provided is as follows: include-dph: This parameter is used to indicate capability and preference to utilize or = include Decoded Picture Hash (DPH) SEI messages (See Section D.3.19 of [HEV= C]) in the encoded video sequence. The value is a comma separated list of h= ash types that is supported or requested to be used, each hash type provide= d as an unsigned integer value (0-255), with the hash types listed from mos= t preferred to the least preferred. Example: "include-dph=3D0,2", which ind= icates the capability for MD5 (most preferred) and Checksum (less preferred= ). If the parameter is not included or the value contains no hash types, th= en no capability to utilize DPH SEI messages is assumed. Note that DPH SEI = messages MAY still be included in the encoded video sequence even when ther= e is no declaration of capability to use them. Comments and suggestions are welcome! Unless otherwise concluded, we would = implement text changes for the above issues to the document. Thanks! BR, YK (representing the above list of participants to the call) From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Monday, May 19, 2014 9:49 AM To: Jonatan Samuelsson; Yago Sanchez Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Hi Jonatan, All, On item C: In that example, you report three set of consecutive CTB losses,= (2,2), (6, 2), and (10, 2). The semantics can only be interpreted this way= , no? On item D: It is up to the receiver to decide how much data is reported to = be lost regardless of how much it actually received, but whatever it report= s, it should report something that is accurate enough for the sender side t= o make meaningful reaction. On item G: I'd like to see some opinions from others, particularly those wh= o have been deeply involved in RFC 4585 to comment on the G.1 and G.2. On G= .3, the wording "the encoder can choose to use one or more of the identifie= d picture and its reference pictures for encoding the next picture" does no= t at all assume that all reference pictures of one specific reference pictu= res will be available, it just means that use whichever from that set when = available. On item H: Assume that the MD5 support as part of RPSI is specified, once a= mismatch due to non-conformation encoder/decoder implementations is known,= you still need people to get involved to debug and to see what is the reas= on of the mismatch, and you cannot assume the buggy implementations to be s= o powerful to super-intelligently figure out what is wrong with the impleme= ntation itself and then do a proper action to continue the session. Rather,= in practice, I would think the signalling does not change anything to the = session itself. For the codec implementation debugging purpose itself, enco= ders are always free to send the MD5 hash in the decoded picture hash SEI m= essages and decoders are free to parse and compare it, I don't see a need f= or yet another standardize effort for that. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Monday, May 19, 2014 6:29 AM To: Yago Sanchez Cc: payload@ietf.org; Wang, Ye-Kui Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, Yago, all, Let me start with some further motivation for why I think it would be usefu= l to include MD5 information in RPSI. I see two categories of "errors" that= can cause encoder and decoder MD5 mismatch: 1. External causes. It is possible that a bit-error in a bitstream is= not detected during decoding, causing a decoded picture to have different = values compared to the reconstructed picture at the encoder. It is also pos= sible that decoded pictures or reconstructed pictures are stored on a media= that is not 100% reliable (e.g. due to malfunctioning hardware). Having a = single value wrong in a reference picture can quite fast propagate to sever= e visual artifacts due to temporal prediction. 2. Implementation causes. Each HEVC encoder and decoder implementatio= n (both hardware and software) is an interpretation of the more than 300 pa= ges long HEVC specification and there is always the risk that there are som= e parts of the specification interpreted differently. The reference encoder= and decoder (HM) can perform guidance here but HM is far from "complete" i= n the sense that it can test all encoder (bitstream) features fully or corr= ectly report all illegal bitstreams to be non-conforming. There is also the= risk that an implementation contains bugs that appear only for very rare c= ases. Our motivation for including MD5 in RPSI is primarily based on the second c= ategory (although the first category should not be ignored). It is true tha= t you would ideally want all deployed encoders and decoders to be fully sta= ndards compliant with no exceptions. However, history has taught us that th= is is unfortunately not the case. For h.264, even in the reference software= JM, bugs have been found several years after h.264 was standardized (examp= le: https://ipbt.hhi.fraunhofer.de/mantis/view.php?id=3D193). And when x264= started using weighted prediction several decoders silently accepted those= bitstreams while displaying erroneous video (http://x264dev.multimedia.cx/= archives/212#more-212). I would not expect HEVC with all its different poss= ible combinations of block sizes and new coding tools to be easier to imple= ment correct compared to h.264. We believe it would be very useful to provide better tools for discovering = incompatibility issues and be able to automatically trigger events based on= the detection of MD5 mismatch. It could for example include: - Taking immediate action to solve the problem such as sending an = IDR picture - Change the configuration of a session with the hope of finding a= configuration which does not cause encoder-decoder problems (e.g. by using= a more basic set of tools or by switching profie/level) - Gather statistics for which clients does not work with which cli= ents and under which circumstances See further comments inline. Best Regards Jonatan From: Yago Sanchez [mailto:yago.sanchez@hhi.fraunhofer.de] Sent: den 17 maj 2014 12:47 To: Jonatan Samuelsson Cc: payload@ietf.org; Wang, Ye-Kui Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Hi Jonatan, Similar to Ye-Kui's comments, on the inclusion of MD5 in the RPSI, it is no= t clear to me why this could be useful. When talking about "incompatibility= " about encoder and decoder this would mean that one of them is not properl= y working, i.e. it does not fully conform to the standard. In such a case I= personally do not think that this is an issue needed to be solved with the= RPSI but at the development phase of the encoder/decoder. I would assume h= ere that both encoder and decoder are conforming to the standard. For other cases, I cannot think of any case of a picture being "correctly" = decoded, while being a mismatch between encoder and decoder. Is there any c= ase where this happens that I am missing? Best regards, Yago On 17 May 2014, at 01:09, Wang, Ye-Kui > wrote: Hi Jonatan, Thanks for reviewing the new version. Please see my replies inline below, i= ncluding some comments on the two newly proposed features related to RPSI. = For these two features, let's first discuss whether to have them in this pa= yload format document before going into the details in text proposed in ano= ther email. BR, YK From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] Sent: Wednesday, May 14, 2014 1:58 AM To: Wang, Ye-Kui; payload@ietf.org Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear Ye-Kui, editors, all, Thanks for improving the draft and making the new version available. I read= through the new section 8 in the latest draft, in which more feedback feat= ures have been added (which I think is very good). I have some minor commen= ts and then some suggestions for improving the RPSI signalling. Compared to= earlier standards, HEVC contains a new very useful SEI message that can be= used to check integrity and correctness of decoded pictures and thereby de= tect errors that are not necessarily due to packet losses: Decoded picture= hash SEI (e.g. MD5 calculated over a decoded picture) . I think it would b= e good to exploit that functionality also in the RTP payload format for HEV= C in order to make implementations even more robust. First some minor comments: In 8.1: A. Remove one instance of 'the loss of' in the sentence: ' As specified in = RFC 4585 section 6.3.1, the reception of a picture loss indication by a med= ia sender indicates the loss of "the loss of an undefined amount of coded v= ideo data belonging to one or more pictures.".' [YK]: Thanks! To be done in the next version. B. The 'BE' in 'SHOULD BE' should not be using CAPITAL LETTERS. [YK]: Thanks! To be done in the next version. In 8.2: C. Regarding 'the loss of a number of Coded Tree Blocks (CTBs) in CTB raste= r scan order of a picture.'. When tiles are used, the loss of a slice does = typically not result in lost CTBs in raster scan order of the picture. The = text does not describe how to calculate the "Number" field for this case. W= ouldn't it be better to use 'tile scan' in order to correctly identify what= part of the picture was lost? [YK]: The intended use of the SLI message as specified is to indicate the l= oss of CTBs regardless of whether and how slices are in use and whether and= how tiles are in use. The semantics of the "Number" field is clear to me t= oo - why it is not clear? Note that the semantics of slice_segment_address = in the HEVC spec itself is also in CTB raster scan order, regardless of whe= ther and how tiles are in use. Personally I'd prefer to keep the semantics = of SLI to be generic, and also aligned with the semantics of slice_segment_= address in the HEVC spec. [JS] I guess I'm missing something here. Let's look at a very simple examp= le of a picture of 4x3 CTBs with two tiles, one to the right and one to the= left, each signaled in a separate slice. The CTB addresses in CTB raster scan order of the picture is: ------------- | 0| 1| 2| 3| | 4| 5| 6| 7| | 8| 9|10|11| ------------- With two tiles layed out as follows: ------------- | A| A| B| B| | A| A| B| B| | A| A| B| B| ------------- the CTB address in tile scan is: ------------- | 0| 1| 6| 7| | 2| 3| 8| 9| | 4| 5|10|11| ------------- Now, if the second tile (second slice) is lost. I should obviously set the = value of "First" to 2 (since that is the CTB address in CTB raster scan ord= er of the picture), but what value should I set for "Number"? I would like = to set it to 6 since that is the number of CTBs that are lost. But if I cou= nt in CTB raster scan order of the picture I get to 10 before I reach the l= ast CTB that was lost. This means some CTBs needs to be indicated as lost e= ven though they were not. Or do I misinterpret the following sentence: The subfield "Number" MUST be set to the number of consecutive lost CTBs, a= gain in CTB raster scan order of a picture. D. Regarding 'the subfield "First" MUST be set to the CTB address of the fi= rst lost CTB'. Wouldn't it be better to require "First" to be set to a numb= er that is lower than or equal to the CTB address of the first lost CTB, si= nce it might be difficult to deduce the exact CTB address of the first lost= CTB in the case of loss of dependent slices and/or fragmentation units? [YK]: To me this change would make the semantics a lot less clear and the m= essage less useful. Also, each dependent slice segment has slice_segment_ad= dress signalled too, while FUs are supposed to be assembled before sending = to the decoder - thus from the decoder point of view FUs do not need to be = considered. [JS] Sending incomplete FUs to the decoder can significantly improve error = concealment algorithms. However, this is just a minor comment from my side.= It is anyway up to the receiver to decide how much data is reported to be = lost regardless of how much it actually received. E. Regarding 'The subfield "PictureID" MUST be set to the 6 least sig= nificant bits of a binary representation of the value of slice_pic_= order_cnt_lsb of the picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of slice_pic_order_cnt_lsb seems a bit confusi= ng (and less robust) for the case when slice_pic_order_cnt_lsbconsists of = fewer than 6 bits. [YK]: Good point. To be done in the next version unless the discussion lead= s into a different conclusion. F. Regarding the sentence: 'In many cases, error tracking is required to id= entify the corrupted region in the receiver's state (reference pictures) be= cause of error import in uncorrupted regions of the picture through motion = compensation, and reference picture selection can also be used to "clean up= " the corrupted picture, which is usually more efficient and less likely to= generate congestion than sending intra information.' For improved readabil= ity I suggest splitting it in two sentences: 'In many cases, error tracking= is required to identify the corrupted region in the receiver's state (refe= rence pictures) because of error import in uncorrupted regions of the pictu= re through motion compensation. Reference picture selection can also be use= d to "clean up" the corrupted picture, which is usually more efficient and = less likely to generate congestion than sending intra information.' [YK]: To be done in the next version. Regarding RPSI (section 8.3) I would like to propose the following changes: G. Add the possibility to include more than one reference picture in the RP= SI message so that the encoder can select to use one or more of the picture= s included in RPSI message. Using multiple pictures for reference is a key = feature in HEVC which substantially improves coding efficiency. In the case= where multiple earlier pictures are available for reference it is benefici= al to let the encoder decide which one(s) to use for reference instead of r= elying on the decoder to make that selection. [YK]: A few points to discuss. G.1: Is it backward compatible to RFC 4585 t= o use one RPSI message to convey more than one reference picture? Would it = be better to define a new message for this purpose if it is deemed useful? [JS] I don't see anything in RFC 4585 that would prohibit including more th= an one reference picture in the "Native RPSI bit string defined per codec" = field. G.2: The concept applies to any video codec that supports multiple referenc= e pictures, is not specific to HEVC, thus would it be better if this is dis= cussed as a generic mechanism, similarly as the SPLI message included in dr= aft-ietf-payload-rtp-h265-01 but dropped later for the very reason? [JS] This would be an option but I don't think it's needed since RPSI in RF= C 4585 is already generic enough to govern this also for other codecs. G.3: On the usefulness of this functionality seems to be unclear to me eith= er. If the last correct picture before an error occurs is known, it is also= known that the reference pictures of the last correct pictures are correct= , thus the encoder can anyway choose to use one or more of these pictures, = when available, for encoding the next picture. Thus, it might be sufficient= just to slightly change the semantics of the RPLI message, to say that the= encoder can choose to use one or more of the identified picture and its re= ference pictures for encoding the next picture. [JS] The strength of RPSI in my opinion is that it can be used to recover f= rom errors that is not a simple loss-of-a-NAL-unit-error (for this case gen= eric NACK, SLI and PLI are probably better suited). An RPSI message can be= used to try to recover from any type of divergence between encoder and dec= oder without the need of a complete reset (i.e. through IDR picture). For s= uch scenarios it might be very difficult to identify exactly which referenc= e pictures are still available (and which of them are correct, as addressed= by suggestion H. below) and it would be dangerous to assume that all refer= ence pictures of one specific reference pictures will be available. H. Using the 2 currently unused bits in the 'Native RPSI bit string defined= per codec' for adding the possibility of including information regarding t= he MD5 in the RPSI message as follows: 0: No information regarding the MD5 available 1: The MD5 of the reference picture is verified to be correct 2: The MD5 of the reference picture is incorrect (i.e. do NOT us= e for reference) 3: The MD5 is included in the RPSI message (directly following t= he PicOrderCntVal) The last option can be used when the encoder does not include MD5s in-band = but wants to check the MD5 before using a selected picture for reference. T= ypically this will be more bit-efficient than including decoded picture has= h SEI messages in-band. In my opinion it would be very useful to be able to include information reg= arding the correctness of the decoded pictures, e.g. to detect incompatibil= ity issues and bit errors. I will send a suggestion for the text changes ne= eded to enable this, hopefully later today. [YK]: Firstly, in my understanding, the decoder picture hash SEI message is= very useful for debugging in development of encoder and decoder implementa= tions, as used by the JCT-VC for the development of the HEVC reference soft= ware, and it is intended for use with that purpose. Using of it for error r= esilience in communications is an overkill to me. For example, you would ne= ed 48 bytes to signal the MD5 hash for each picture. [JS] It would still be optional to include those 48 bytes of MD5 info, and = if they can be used to detect errors that would otherwise not be detected, = then 48 bytes per reference picture does not sound much compared to the typ= ical bitrates for video streams. Secondly, it is architecturally incorrect to couple this with the RPSI feed= back message, as the picture identified is supposed to be correctly decoded= by the decoder and the purpose of the message is to request the encoder to= use that picture for encoding of the next picture, [JS] You are right that the identified picture(s) is supposed to be correct= . The proposed usage of MD5 provides a mechanism for verifying that a pictu= re is actually correct. thus why would you even indicate a picture that is incorrect using an RPSI = feedback message? [JS] See further motivation at the top of this email. That information can = be used to identify incompatibility issues for immediate actions (change co= nfiguration) and long-term actions (identify non-conforming encoders/decode= rs). In scenarios where Full Intra reset is not feasible an encoder may use= this information to perform gradual decoder refresh until the encoder and = decoder have been verified to have identical reference pictures in their bu= ffers. Best Regards Jonatan -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: den 30 april 2014 20:29 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt Dear All, Compare to -02, we have addressed most of the numerous comments and tickets= , from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following ch= anges: - Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflecto= r, agreed by most of the authors, no objection from anyone. - Addition of an informative, brief description of the display orientation = SEI message, which is among one of those new SEI messages that have some sy= stems usage. - Addition of a definition of NAL-unit-like structure. The term was used bu= t not defined earlier. - Addition of descriptions for use of the PLI and SLI messages (specified i= n RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addit= ion to the RFC 4585 RPSI message for which the use description was already = included, as agreed during the presentation at the previous IETF meeting Remaining open issues: - On profile-compatibility-indicator and interop-constraints (raised by Mag= nus, being discussed among Magnus, myself and Yago, no conclusion yet) - On recv-sub-layer-id and using of sprop-vps for session negotiation (rais= ed by Magnus, still being discussed among the authors and Magnus) - On source-specific sprop parameter sets (raised by Magnus, still being di= scussed among the authors and Jonathan for exact text changes) - On using a different parameter category for level-id (raised by Magnus, d= iscussed between Magnus and myself, no conclusion yet) - I just noticed that the definition of "packet stream" itself needs to be = changed back to "RTP stream" We will try to address the above open issues as soon as possible. At the sa= me time, further review and comments are welcome. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, April 30, 2014 10:34 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.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 Gro= up of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-03.txt Pages : 92 Date : 2014-04-30 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-03 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 _______________________________________________ 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 --_000_8BA7D4CEACFFE04BA2D902BF11719A83452CDDE4nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

The following group of= persons had a conference call today (May 20, 2014, 11:00am-12:30pm PDT), w= ith the goal to resolve the remaining open issues for this payload format, = such that it can be finalized as soon as possible due to the urgent need of the HEVC payload format for the depl= oyment of HEVC:

-&nb= sp;         Magnus Westerl= und

-&nb= sp;         Stephan Wenger=

-&nb= sp;         Jonatan Samuel= sson

-&nb= sp;         Yago Sanchez

-&nb= sp;         Ye-Kui Wang

 

The discussed list of = open issues are:

1)&n= bsp;     Ticket#12 (rtp= -h265): The max-fps parameter

2)&n= bsp;     On source-spec= ific sprop parameter sets

3)&n= bsp;     On support of = a future profile defined as the intersection of more than one profile<= /o:p>

4)&n= bsp;     On recv-sub-la= yer-id and using of sprop-vps for session negotiation

5)&n= bsp;     On the SLI fee= dback message: in CTB raster scan order or in tile scan order, for both FIR= ST and NUMBER

6)&n= bsp;     On the RPSI fe= edback message

a. &nbs= p;     Signalling of = more than one reference picture to be used for encoding the next picture

b. &nbs= p;    Support of int= egrity check

 

What we agreed among t= he participants on the above issues are as follows:

 

1)&n= bsp;     Ticket#12 (rtp= -h265): The max-fps parameter

 

With the clarification= s in the latest email from Geir Sandbakken, we agreed that it would be OK w= ith the use of the MUST language as Geir suggested.

 

2)&n= bsp;     On source-spec= ific sprop parameter sets

 

We agreed to add a cla= rification sentence like: When conveyed in the "a=3Dfmtp" line of= SDP for a particular payload type, the parameters "sprop-vps", &= quot;sprop-sps", and "sprop-pps" MUST be applied to each SSR= C with the payload type.

 

3)&n= bsp;     On support of = a future profile defined as the intersection of more than one profile<= /o:p>

 

We agreed to have the = support, but clearly document the intention of such support, to avoid possi= ble confusions, such as requiring encoders to support all possible intersec= tions as discussed between Jonatan and myself. Also try to clarify the implications of when the profile related p= arameters are used with different direction attributes. Magnus kindly agree= d to draft some text.

 

4)&n= bsp;     On recv-sub-la= yer-id and using of sprop-vps for session negotiation

 

We agreed to allow the= use of sprop-vps for session negotiation, but require profile, tier, level= info to be present in the SDP answer. Compared to completely removing this= mechanism, this approach supports selection of one of the multiple operation points, particular when more than one of = the operation points comply with the some profile, tier, and level.

 

5)&n= bsp;     On the SLI fee= dback message: in CTB raster scan order or in tile scan order, for both FIR= ST and NUMBER

 

We agreed to keep the = current method (i.e. in CTB raster scan order), but clarify a bit to make i= t clearer, e.g. including mentioning in some cases with tiles multiple mess= ages might be needed for reporting the loss of one slice.

 

6)&n= bsp;     On the RPSI fe= edback message

a. &nbs= p;     Signalling of = more than one reference picture to be used for encoding the next picture

b. &nbs= p;    Support of int= egrity check

 

We agreed to investiga= te both a and b above in a separate document in a generic way in the contex= t of avtext. Jonatan to initiate the document. For this payload format docu= ment, we agreed to add the parameter “include-dph”, as Jonatan suggested to the mailing list. For c= onvenience, the semantics of this parameter is provided is as follows:=

include-dph:

This parameter is used to indicate capability a= nd preference to utilize or include Decoded Picture Hash (DPH) SEI messages= (See Section D.3.19 of [HEVC]) in the encoded video sequence. The value is a comma separated list of hash types that is suppor= ted or requested to be used, each hash type provided as an unsigned integer= value (0-255), with the hash types listed from most preferred to the least= preferred. Example: “include-dph=3D0,2”, which indicates the capability for MD5 (most preferred) and Checksum (less= preferred). If the parameter is not included or the value contains no hash= types, then no capability to utilize DPH SEI messages is assumed. Note tha= t DPH SEI messages MAY still be included in the encoded video sequence even when there is no declaration o= f capability to use them.

 

Comments and suggestio= ns are welcome! Unless otherwise concluded, we would implement text changes= for the above issues to the document. Thanks!

 

BR, YK (representing t= he above list of participants to the call)

 

 <= /p>

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Monday, May 19, 2014 9:49 AM
To: Jonatan Samuelsson; Yago Sanchez
Cc: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Hi Jonatan, All,

 <= /p>

On item C: In that exampl= e, you report three set of consecutive CTB losses, (2,2), (6, 2), and (10, = 2). The semantics can only be interpreted this way, no?

 <= /p>

On item D: It is up to th= e receiver to decide how much data is reported to be lost regardless of how= much it actually received, but whatever it reports, it should report something that is accurate enough for the sender side to mak= e meaningful reaction.

 <= /p>

On item G: I’d like= to see some opinions from others, particularly those who have been deeply = involved in RFC 4585 to comment on the G.1 and G.2. On G.3, the wording “the encoder can choose to use one or more of the identified= picture and its reference pictures for encoding the next picture” do= es not at all assume that all reference pictures of one specific reference = pictures will be available, it just means that use whichever from that set when available.

 <= /p>

On item H: Assume that th= e MD5 support as part of RPSI is specified, once a mismatch due to non-conf= ormation encoder/decoder implementations is known, you still need people to get involved to debug and to see what is the reason of the = mismatch, and you cannot assume the buggy implementations to be so powerful= to super-intelligently figure out what is wrong with the implementation it= self and then do a proper action to continue the session. Rather, in practice, I would think the signalling= does not change anything to the session itself. For the codec implementati= on debugging purpose itself, encoders are always free to send the MD5 hash = in the decoded picture hash SEI messages and decoders are free to parse and compare it, I don’t see = a need for yet another standardize effort for that.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan = Samuelsson [mailto:jonat= an.samuelsson@ericsson.com]
Sent: Monday, May 19, 2014 6:29 AM
To: Yago Sanchez
Cc: payload@ietf.org; Wang, = Ye-Kui
Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Dear Ye-Kui, Yago, all,

 <= /p>

Let me start with some fu= rther motivation for why I think it would be useful to include MD5 informat= ion in RPSI. I see two categories of “errors” that can cause encoder and decoder MD5 mismatch:

1. = ;      External causes. = It is possible that a bit-error in a bitstream is not detected during decod= ing, causing a decoded picture to have different values compared to the reconstructed picture at the encoder. It is also possible = that decoded pictures or reconstructed pictures are stored on a media that = is not 100% reliable (e.g. due to malfunctioning hardware). Having a single= value wrong in a reference picture can quite fast propagate to severe visual artifacts due to temporal predic= tion.

2. = ;      Implementation ca= uses. Each HEVC encoder and decoder implementation (both hardware and softw= are) is an interpretation of the more than 300 pages long HEVC specification and there is always the risk that there are some parts = of the specification interpreted differently. The reference encoder and dec= oder (HM) can perform guidance here but HM is far from “complete̶= 1; in the sense that it can test all encoder (bitstream) features fully or correctly report all illegal bitstreams to b= e non-conforming. There is also the risk that an implementation contains bu= gs that appear only for very rare cases.

 <= /p>

Our motivation for includ= ing MD5 in RPSI is primarily based on the second category (although the fir= st category should not be ignored). It is true that you would ideally want all deployed encoders and decoders to be fully standard= s compliant with no exceptions. However, history has taught us that this is= unfortunately not the case. For h.264, even in the reference software JM, = bugs have been found several years after h.264 was standardized (example: https://ipbt.hhi.fraunhofer.de/mantis/view.ph= p?id=3D193). And when x264 started using weighted prediction sev= eral decoders silently accepted those bitstreams while displaying erroneous= video (http://x264dev.multimedia.cx/archives/212#more-21= 2). I would not expect HEVC with all its different possible combinations of bl= ock sizes and new coding tools to be easier to implement correct compared t= o h.264.

 <= /p>

We believe it would be ve= ry useful to provide better tools for discovering incompatibility issues an= d be able to automatically trigger events based on the detection of MD5 mismatch. It could for example include:

- =          Taking immediate = action to solve the problem such as sending an IDR picture

- =          Change the config= uration of a session with the hope of finding a configuration which does no= t cause encoder-decoder problems (e.g. by using a more basic set of tools or by switching profie/level)

- =          Gather statistics= for which clients does not work with which clients and under which circums= tances

 <= /p>

See further comments inli= ne.

 <= /p>

Best Regards Jonatan=

 <= /p>

From: Yago San= chez [mailto:yago.sanchez= @hhi.fraunhofer.de]
Sent: den 17 maj 2014 12:47
To: Jonatan Samuelsson
Cc: payload@ietf.org; Wang, = Ye-Kui
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.tx= t

 

Hi Jonatan, 

 

Similar to Ye-Kui’s comments, on the inclusion= of MD5 in the RPSI, it is not clear to me why this could be useful. When t= alking about “incompatibility” about encoder and decoder this w= ould mean that one of them is not properly working, i.e. it does not fully conform to the standard. In such a case I personall= y do not think that this is an issue needed to be solved with the RPSI but = at the development phase of the encoder/decoder. I would assume here that b= oth encoder and decoder are conforming to the standard.

 

For other cases, I cannot think of any case of a pic= ture being “correctly” decoded, while being a mismatch between = encoder and decoder. Is there any case where this happens that I am missing= ?

 

Best regards,

Yago

 

On 17 May 2014, at 01:09, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:<= o:p>

 

Hi Jonatan,

 <= /p>

Thanks for reviewing the = new version. Please see my replies inline below, including some comments on= the two newly proposed features related to RPSI. For these two features, let’s first discuss whether to have them in this paylo= ad format document before going into the details in text proposed in anothe= r email.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonatan Samuelsson [mailto:jonatan.samuelsson@ericsson.com] 
Sent: Wednesday, M= ay 14, 2014 1:58 AM
To: Wang, Ye-Kui;<= span class=3D"apple-converted-space"> payload@ietf.org
Subject: RE: [payl= oad] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear Ye-Kui, editors, all,<= /o:p>

Thanks for improving the draft and maki= ng the new version available. I read through the new section 8 in the lates= t draft, in which more feedback features have been added (which I think is very good). I have some minor comments and then some sug= gestions for improving the RPSI signalling. Compared to earlier standards, = HEVC contains a new very useful SEI message that can be used to check integ= rity and correctness of decoded pictures and thereby detect errors that are not necessarily due to packet = losses: Decoded  picture hash SEI (e.g. MD5 calculated over a decoded = picture) . I think it would be good to exploit that functionality also in t= he RTP payload format for HEVC in order to make implementations even more robust.

First some minor comments:<= /o:p>

In 8.1:

A. Remove one instance of 'the loss of' in the sentence: ' <= span style=3D"font-size:10.0pt;font-family:"Courier New"">As spec= ified in RFC 4585 section 6.3.1, the reception of a picture loss indication= by a media sender indicates the loss of "the loss of an undefined amount of coded video data belonging to one or more pictur= es.".'

 <= /p>

[YK]: Thanks! To be done = in the next version.

B. The 'BE' in 'SHOULD BE' should not b= e using CAPITAL LETTERS.

[YK]: Thanks! To be done = in the next version.

 <= /p>

In 8.2:

C. Regarding 'the loss of a number of = Coded Tree Blocks (CTBs) in CTB raster scan order of a picture.'. When tiles are used, the loss of a slice does typically not result in lost= CTBs in raster scan order of the picture. The text does not describe how t= o calculate the "Number" field for this case. Wouldn't it be bett= er to use 'tile scan' in order to correctly identify what part of the = picture was lost?

 <= /p>

[YK]: The intended use of= the SLI message as specified is to indicate the loss of CTBs regardless of= whether and how slices are in use and whether and how tiles are in use. The semantics of the “Number” field is clear to me= too – why it is not clear? Note that the semantics of slice_segment_= address in the HEVC spec itself is also in CTB raster scan order, regardles= s of whether and how tiles are in use. Personally I’d prefer to keep the semantics of SLI to be generic, and also alig= ned with the semantics of slice_segment_address in the HEVC spec.

[JS] I guess I’m&nb= sp; missing something here. Let’s look at a very simple example of a = picture of 4x3 CTBs with two tiles, one to the right and one to the left, each signaled in a separate slice.

The CTB addresses in CTB = raster scan order of the picture is:

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

| 0| 1| 2| 3|

| 4| 5| 6| 7|

| 8| 9|10|11|

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

With two tiles layed out = as follows:

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

| A| A| B| B|

| A| A| B| B|

| A| A| B| B|

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

the CTB address in tile s= can is:

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

| 0| 1| 6| 7|

| 2| 3| 8| 9|

| 4| 5|10|11|

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

Now, if the second tile (= second slice) is lost. I should obviously set the value of “FirstR= 21; to 2 (since that is the CTB address in CTB raster scan order of the picture), but what value should I set for “Number”? I woul= d like to set it to 6 since that is the number of CTBs that are lost. But i= f I count in CTB raster scan order of the picture I get to 10 before I reac= h the last CTB that was lost. This means some CTBs needs to be indicated as lost even though they were not. Or do I misi= nterpret the following sentence:

The subfield "Number&= quot; MUST be set to the number of consecutive lost CTBs, again in CTB rast= er scan order of a picture.

D. Regarding 'the subfield "First= " MUST be set to the CTB address of the first lost CTB'. Wouldn't it be better to require "First" to= be set to a number that is lower than or equal to the CTB address of the f= irst lost CTB, since it might be difficult to deduce the exact CTB address of t= he first lost CTB in the case of loss of  dependent slices and/or frag= mentation units?

 <= /p>

[YK]: To me this change w= ould make the semantics a lot less clear and the message less useful. Also,= each dependent slice segment has slice_segment_address signalled too, while FUs are supposed to be assembled before sending to th= e decoder – thus from the decoder point of view FUs do not need to be= considered.

[JS] Sending incomplete F= Us to the decoder can significantly improve error concealment algorithms. H= owever, this is just a minor comment from my side. It is anyway up to the receiver to decide how much data is reported to be lost r= egardless of how much it actually received.

E. Regarding 'The subfield "Pictu= reID" MUST  be  set  to  the  6  least s= ignificant  bits  of  a  binary representation  of  the  value  of slice_pic_order_cnt_lsb  of  t= he picture for which the lost CTBs are indicated.'. Isn= 't it better to use the 6 least significant bits of PicOrderCntVal? Using t= he 6 least significant bits of  = ;slice_pic_order_cnt_lsb seems a bit confusing (and less robust) for the case when slice_pic_order_cnt_lsbcon= sists of  fewer than 6 bits.

[YK]: Good point. To be d= one in the next version unless the discussion leads into a different conclu= sion.

 <= /p>

F. Regarding the sentence: 'In many ca= ses, error tracking is required to identify the corrupted region in the receiver's state (reference pictures) because of error import in uncor= rupted regions of the picture through motion compensation, and reference pi= cture selection can also be used to "clean up" the corrupted pict= ure, which is usually more efficient and less likely to generate congestion than sending intra information.' For improved readability I suggest splitting it in two sentences: = ''

[YK]: To be done in the n= ext version.

 <= /p>

Regarding RPSI (section 8.3) I would li= ke to propose the following changes:

G. Add the possibility to include more = than one reference picture in the RPSI message so that the encoder can sele= ct to use one or more of the pictures included in RPSI message. Using multiple pictures for reference is a key feature in HEVC which subst= antially improves coding efficiency. In the case where multiple earlier pic= tures are available for reference it is beneficial to let the encoder decid= e which one(s) to use for reference instead of relying on the decoder to make that selection.

[YK]: A few points to dis= cuss. G.1: Is it backward compatible to RFC 4585 to use one RPSI message to= convey more than one reference picture? Would it be better to define a new message for this purpose if it is deemed useful?

[JS] I don’t see an= ything in RFC 4585 that would prohibit including more than one reference pi= cture in the "Native RPSI bit string defined per codec" field.

G.2: The concept applies = to any video codec that supports multiple reference pictures, is not specif= ic to HEVC, thus would it be better if this is discussed as a generic mechanism, similarly as the SPLI message included in draft-ie= tf-payload-rtp-h265-01 but dropped later for the very reason?

[JS] This would be an opt= ion but I don’t think it’s needed since RPSI in RFC 4585 is alr= eady generic enough to govern this also for other codecs.

G.3: On the usefulness of= this functionality seems to be unclear to me either. If the last correct p= icture before an error occurs is known, it is also known that the reference pictures of the last correct pictures are correct, thus= the encoder can anyway choose to use one or more of these pictures, when a= vailable, for encoding the next picture. Thus, it might be sufficient just = to slightly change the semantics of the RPLI message, to say that the encoder can choose to use one or more= of the identified picture and its reference pictures for encoding the next= picture.

[JS] The strength of RPSI= in my opinion is that it can be used to recover from errors that is not a = simple loss-of-a-NAL-unit-error (for this case generic NACK,  SLI and PLI are probably better suited). An RPSI message can be used= to try to recover from any type of divergence between encoder and decoder = without the need of a complete reset (i.e. through IDR picture). For such s= cenarios it might be very difficult to identify exactly which reference pictures are still available (and which o= f them are correct, as addressed by suggestion H. below) and it would be da= ngerous to assume that all reference pictures of one specific reference pic= tures will be available.

 <= /p>

H. Using the 2 currently unused bits in= the 'Native RPSI bit string defined per codec' for adding the possibility of including information regarding the MD5 in the R= PSI message as follows:

0:      &= nbsp;     No information regarding the MD5 available 1:            The MD= 5 of the reference picture is verified to be correct
2:            The MD= 5 of the reference picture is incorrect (i.e. do NOT use for reference)
3:            The MD= 5 is included in the RPSI message (directly following the PicOrderCntVal)

The last option can be used when the en= coder does not include MD5s in-band but wants to check the MD5 before using= a selected picture for reference. Typically this will be more bit-efficient than including decoded picture hash SEI messages in-ban= d.

In my opinion it would be very useful t= o be able to include information regarding the correctness of the decoded p= ictures, e.g. to detect incompatibility issues and bit errors. I will send a suggestion for the text changes needed to enable this, hopef= ully later today.

 <= /p>

[YK]: Firstly, in my unde= rstanding, the decoder picture hash SEI message is very useful for debuggin= g in development of encoder and decoder implementations, as used by the JCT-VC for the development of the HEVC reference software, = and it is intended for use with that purpose. Using of it for error resilie= nce in communications is an overkill to me. For example, you would need 48 = bytes to signal the MD5 hash for each picture.

[JS] It would still be op= tional to include those 48 bytes of MD5 info, and if they can be used to de= tect errors that would otherwise not be detected, then 48 bytes per reference picture does not sound much compared to the typical bi= trates for video streams.   &nb= sp;

Secondly, it is architect= urally incorrect to couple this with the RPSI feedback message, as the pict= ure identified is supposed to be correctly decoded by the decoder and the purpose of the message is to request the encoder to use th= at picture for encoding of the next picture,

[JS] You are right that t= he identified picture(s) is supposed to be correct. The proposed usage of M= D5 provides a mechanism for verifying that a picture is actually correct.

thus why would you even i= ndicate a picture that is incorrect using an RPSI feedback message?<= o:p>

[JS] See further motivati= on at the top of this email. That information can be used to identify incom= patibility issues for immediate actions (change configuration) and long-term actions (identify non-conforming encoders/decoders). In scen= arios where Full Intra reset is not feasible an encoder may use this inform= ation to perform gradual decoder refresh until the encoder and decoder have= been verified to have identical reference pictures in their buffers.

Best Regards Jonatan<= /p>

-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui
Sent: den 30 april 2014 20:29
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

 

Dear All,

 

Compare to -02, we have addressed most = of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Berna= rd, ..., as well as the following changes:

- Addition of sprop-sei, as suggested b= y Stephan on Apr. 23 to the reflector, agreed by most of the authors, no ob= jection from anyone.

- Addition of an informative, brief des= cription of the display orientation SEI message, which is among one of thos= e new SEI messages that have some systems usage.

- Addition of a definition of NAL-unit-= like structure. The term was used but not defined earlier.

- Addition of descriptions for use of t= he PLI and SLI messages (specified in RFC 4585) and the FIR message (specif= ied in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed= during the presentation at the previous IETF meeting

 

Remaining open issues:

- On profile-compatibility-indicator an= d interop-constraints (raised by Magnus, being discussed among Magnus, myse= lf and Yago, no conclusion yet)

- On recv-sub-layer-id and using of spr= op-vps for session negotiation (raised by Magnus, still being discussed amo= ng the authors and Magnus)

- On source-specific sprop parameter se= ts (raised by Magnus, still being discussed among the authors and Jonathan = for exact text changes)

- On using a different parameter catego= ry for level-id (raised by Magnus, discussed between Magnus and myself, no = conclusion yet)

- I just noticed that the definition of= "packet stream" itself needs to be changed back to "RTP str= eam"

 

We will try to address the above open i= ssues as soon as possible. At the same time, further review and comments ar= e welcome.

 

BR, YK

 

-----Original Message-----<= /o:p>

From: payload [mailto:payload-bounces@iet= f.org] On Behalf Of <= /span>internet-drafts@ietf.org

Sent: Wednesday, April 30, 2014 10:34 A= M

Subject: [payload] I-D Action: draft-ie= tf-payload-rtp-h265-03.txt

 

 

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.

 

      &nb= sp; Title           : RTP= Payload Format for High Efficiency Video Coding

      &nb= sp; Authors         : Ye-Kui Wang

      &nb= sp;            =        Yago Sanchez

      &nb= sp;            =        Thomas Schierl

      &nb= sp;            =        Stephan Wenger

      &nb= sp;            =        Miska M. Hannuksela<= /p>

      &nb= sp; Filename        : draft-ietf-payload= -rtp-h265-03.txt

      &nb= sp; Pages           : 92<= /span>

      &nb= sp; Date            = : 2014-04-30

 

Abstract:

   This memo describes an RTP= payload format for the video coding

   standard ITU-T Recommendat= ion H.265 and ISO/IEC International

   Standard 23008-2, both als= o known as High Efficiency Video Coding

   (HEVC) [HEVC] and develope= d by the Joint Collaborative Team on Video

   Coding (JCT-VC).  The= RTP payload format allows for packetization of

   one or more Network Abstra= ction Layer (NAL) units in each RTP packet

   payload, as well as fragme= ntation of a NAL unit into multiple RTP

   packets.  Furthermore= , it supports transmission of an HEVC bitstream

   over a single as well as m= ultiple RTP streams.  The payload format

   has wide applicability in = videoconferencing, Internet video

   streaming, and high bit-ra= te entertainment-quality video, among

   others.<= /p>

 

 

The IETF datatracker status page for th= is draft is:

 

There's also a htmlized version availab= le at:

 

A diff from the previous version is ava= ilable at:

 

 

Please note that it may take a couple o= f minutes from the time of submission until the htmlized version and diff a= re available at tools.ietf.org.

 

Internet-Drafts are also available by a= nonymous FTP at:

 

_______________________________________= ________

payload mailing list<= /p>

 

_______________________________________= ________

payload mailing list<= /p>

 

______________________________________= _________
payload mailing list
payload@ie= tf.org
https://www.ietf.org/mailman/listinfo/payload

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83452CDDE4nasanexd02fnaqu_-- From nobody Tue May 27 00:07: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 3BBC11A01F2 for ; Tue, 27 May 2014 00:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651] 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 XlNyj2LYp409 for ; Tue, 27 May 2014 00:07:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id EFFDC1A0163 for ; Tue, 27 May 2014 00:07:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 62D267C0CC1 for ; Tue, 27 May 2014 09:06:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPGVgRRvzGBG for ; Tue, 27 May 2014 09:06:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:9150:eadf:1a2d:a453] (unknown [IPv6:2001:470:de0a:27:9150:eadf:1a2d:a453]) by mork.alvestrand.no (Postfix) with ESMTPSA id D3F437C0B58 for ; Tue, 27 May 2014 09:06:56 +0200 (CEST) Message-ID: <53843990.2090400@alvestrand.no> Date: Tue, 27 May 2014 09:06:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: payload@ietf.org References: <52F42707.10606@alvestrand.no> <537B72EB.3080509@alvestrand.no> In-Reply-To: <537B72EB.3080509@alvestrand.no> Content-Type: multipart/alternative; boundary="------------070600040707000401090104" Archived-At: http://mailarchive.ietf.org/arch/msg/payload/HXhqEbLl5mmGvQmyzRyz92V4fmg Subject: [payload] Request to Last Call draft-ietf-vp8-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, 27 May 2014 07:07:05 -0000 This is a multi-part message in MIME format. --------------070600040707000401090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Given that another week has gone by with zero feedback on draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby ask the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 without any link to this draft. The interest shown by the community in pursuing such a linkage is not indicative of an IETF consensus for a linkage. Harald On 05/20/2014 05:21 PM, Harald Alvestrand wrote: > Just a reminder, since Cullen reminded me that this issue has languished: > > I have seen no response to my February 6 message raising specific > issues about max-video-resolution (reproduced below). > I have seen no update to max-video-resolution based on the discussion > in London. > I have seen no action from the chairs to either adopt or reject this > work item. > > As far as I can tell, nothing is happening. > > If there is no interest in pursuing this work, can we declare that it > is not an IETF work item and stop blocking other things on it? > > Harald > > > On 02/06/2014 07:21 PM, Harald Alvestrand wrote: >> On 02/01/2014 02:51 AM, Suhas Nandakumar wrote: >>> Hello All >>> >>> Following draft has been submitted to specify payload format >>> parameters indicating an end-point's maximum image resolution >>> receive capability in SDP. This draft aims at solving the issue with >>> specifying such functionality for VP8 and is also applicable to >>> other codecs in general. >> >> Thank you for finally posting this to the payload list! (The date of >> the draft is Dec 7 - I've been waiting for the proponents to make a >> public statement about it). >> >> My biggest worry with this particular proposal is that it modifies >> the way a=fmtp is specified. >> >> As far as I understand, the syntax of a=fmtp has previously been >> assumed to be specified completely by the payload specification (viz >> the rather non-orthogonal stuff that is in the DTMF payload). >> >> This specification proposes to add new parameters into a=fmtp that >> are applicable to any payload. This seems like a doubtful >> architectural decision. >> I think it would be cleaner to add a new a= attribute that is >> independent of codec (but linked to payload type) containing the >> information. >> >> I also have a nit with the way offer/answer is specified: >> >> ..... When the direction is >> sendonly, these attributes have no interpretation and MUST be ignored >> by the receiving Endpoint, if present. >> >> ...... >> >> An SDP Answerer MUST NOT include these parameters in the SDP Answer >> unless they are specified in the associated SDP Offer. >> >> >> If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless. >> >> My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply. >> >> Note: I see absolutely no reason to link this functionality, if >> desirable, to the RTP format for VP8. If it needs mandating, it >> should be mandated for all video types going forward, including >> H.265, and strongly recommended for all video types that have been >> standardized in the past. >> >> If it doesn't need mandating, it doesn't need mandating for anyone. >> >> >> >> >> >>> >>> >>> URL: >>> http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt >>> Htmlized: >>> http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00 >>> >>> >>> Looking forward for the inputs on how do we take his work ahead. >>> >>> >>> Thanks >>> Suhas Nandakumar >>> >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --------------070600040707000401090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Given that another week has gone by with zero feedback on draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby ask the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 without any link to this draft.

The interest shown by the community in pursuing such a linkage is not indicative of an IETF consensus for a linkage.

             Harald


On 05/20/2014 05:21 PM, Harald Alvestrand wrote:
Just a reminder, since Cullen reminded me that this issue has languished:

I have seen no response to my February 6 message raising specific issues about max-video-resolution (reproduced below).
I have seen no update to max-video-resolution based on the discussion in London.
I have seen no action from the chairs to either adopt or reject this work item.

As far as I can tell, nothing is happening.

If there is no interest in pursuing this work, can we declare that it is not an IETF work item and stop blocking other things on it?

                   Harald


On 02/06/2014 07:21 PM, Harald Alvestrand wrote:
On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:
Hello All

  Following draft has been submitted to specify payload format parameters indicating an end-point's maximum image resolution receive capability in SDP. This draft aims at solving the issue with specifying such functionality for VP8 and is also applicable to other codecs in general.

Thank  you for finally posting this to the payload list! (The date of the draft is Dec 7 - I've been waiting for the proponents to make a public statement about it).

My biggest worry with this particular proposal is that it modifies the way a=fmtp is specified.

As far as I understand, the syntax of a=fmtp has previously been assumed to be specified completely by the payload specification (viz the rather non-orthogonal stuff that is in the DTMF payload).

This specification proposes to add new parameters into a=fmtp that are applicable to any payload. This seems like a doubtful architectural decision.
I think it would be cleaner to add a new a= attribute that is independent of codec (but linked to payload type) containing the information.

I also have a nit with the way offer/answer is specified:

                          ..... When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.

   ......

   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.


If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless.

My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply.
Note: I see absolutely no reason to link this functionality, if desirable, to the RTP format for VP8. If it needs mandating, it should be mandated for all video types going forward, including H.265, and strongly recommended for all video types that have been standardized in the past.

If it doesn't need mandating, it doesn't need mandating for anyone.







URL:             http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt
Htmlized:        http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00


Looking forward for the inputs on how do we take his work ahead.


Thanks
Suhas Nandakumar


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



-- 
Surveillance is pervasive. Go Dark.



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



-- 
Surveillance is pervasive. Go Dark.



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

--------------070600040707000401090104-- From nobody Tue May 27 01:13: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 E7A151A03E3; Tue, 27 May 2014 01:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 ud1k4hU1Y4Sf; Tue, 27 May 2014 01:13:09 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85CF1A03DE; Tue, 27 May 2014 01:13:07 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so8998745wes.37 for ; Tue, 27 May 2014 01:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=1/3AyyPcL3RXRiF3K0lM9oLSN/7vfhmhFL8i3CjlHsc=; b=BOiuZAs9QwKHUBfplv4gAGiBeDF8HBtYkCAIAN9ZXKHs9xYMtuNiDnsP6kuj9DLGsv MF40bhsr2OkOmrlixZQBn+Xaz4Bl6DzWGf+1lbwaGGH2ElOS2/tsBAz+sgVKIa+v/Fcq hnzOLgpLSXbPAStk9YjGOuUn2jdtGZldx6CTzQ+9OmHpHEPbFGyPNV7EBAlalZF2zHN7 HP3QnH6f9+gp0tI3QctHPCpcPJ56D6jnu9RBTPayp3U2V1aUXAcqQM+PTlQpqqLPK4pm 04R6l/lXacBxale6E53CRBpPHNEA0PfJrQHAPvEWo+q90IG3mw8W2gBfxU3TiustrnbA Wfzg== X-Received: by 10.180.72.136 with SMTP id d8mr34813539wiv.36.1401178383336; Tue, 27 May 2014 01:13:03 -0700 (PDT) Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id f6sm6307365wiy.19.2014.05.27.01.13.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 May 2014 01:13:02 -0700 (PDT) From: "Roni Even" To: Date: Tue, 27 May 2014 11:12:56 +0300 Message-ID: <033b01cf7983$78f591f0$6ae0b5d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033C_01CF799C.9E436630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac95g3Q7dDyBSvZrRoWjbmxkG++FEQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/WqvD4RAqv-0NgoLwFxUEVOlfRrg Cc: avt@ietf.org Subject: [payload] maximum receive video resolution -open issue 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, 27 May 2014 08:13:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033C_01CF799C.9E436630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We need to get feedback on this topic ( posting also to AVTcore to get larger exposure) At the IETF 89 meeting the chairs summarized the topic as follows: Payload specific parameters for specifying video resolution in SDP in http://tools.ietf.org/id/draft-nandakumar-payload-sdp-max-video-resolution-0 0.txt was presented by Suhas Nandakumar. The slides are is https://tools.ietf.org/agenda/89/slides/slides-89-payload-5.pdf . The proposal is to provide a codec agnostic way for a receiver to signal maximum receive video resolution. The feeling is that there is a need for this but need use cases. There was disagreement whether to use codec agnostics or codec specifics. Action: There is a need for a document that will specify the need to signal maximum receive video resolution. (Can be in RTP how to or a separate document). Need to discuss on the list if the solution should be codec specific or not. Since there were no comments to far and we want to progress the VP8 RTP payload specification we may start a WGLC on the VP8 RTP payload and have this topic as one of the issues to conclude. Roni Even Payload co-chair ------=_NextPart_000_033C_01CF799C.9E436630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We need to get = feedback on this topic ( posting also to AVTcore to get larger = exposure)

At the IETF 89 meeting the = chairs summarized the topic as follows:

 

Payload = specific parameters for specifying video resolution in SDP in = http://tools.ietf.org/id/draft-nandakumar-payload-sdp-max-video-resolutio= n-00.txt was presented by Suhas Nandakumar.

 

The slides = are is https://tools.ietf.org/agenda/89/slides/slides-89-payload-5.pdf . =

 

The proposal is to provide a codec agnostic way for a = receiver to signal maximum receive video resolution.

 

The feeling = is that there is a need for this but need use cases. There was = disagreement whether to use codec agnostics or codec specifics. =

 

Action: There is a need for a document that = will specify the need to signal maximum receive video resolution. (Can = be in RTP how to or a separate document).

 

 

Need to = discuss on the list if the solution should be codec specific or not. =

 

 

Since there = were no comments to far and we want to progress the VP8 RTP payload = specification  we may start a WGLC on the VP8 RTP payload and have = this topic as one of the issues to conclude.

 

Roni = Even

Payload = co-chair

------=_NextPart_000_033C_01CF799C.9E436630-- From nobody Tue May 27 01:15:05 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 5A0A41A0407 for ; Tue, 27 May 2014 01:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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_14=0.6, J_CHICKENPOX_18=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 cWacAJz0t-FD for ; Tue, 27 May 2014 01:14:46 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA351A03E8 for ; Tue, 27 May 2014 01:14:46 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so9091638wgh.5 for ; Tue, 27 May 2014 01:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=5CjRUMhd6YpJYCx+UYairqp9z6emxCwupXCi8PNMyNs=; b=EY7bBA2dsm+q0d+BtLRcYM2SNO1W65fBSuS5NjOduokg5uO/486hfXSdSKixF1xyJ3 R6tdqdzOOOyHGkK2990u4Uhu5yTewXrFxFQnNJnBg8CGjlwpFVSSRuKf9twzPNMNlwad vehysq2ZNoy46STNAhsSbmNJR1xYTDN33xsE22cXeHsont5uaJ7csIJXIvMh5e23PYRF SgFy6vtiuZtHaHITXz48G8udQJJRwSoiieAr0rcQLbpxiJQNKlCqsYmVFi4snZNPC/v6 ih+UT0IrSrM5z8m1vnZqlj6+y8XpIlhrBkx233l0pT7RlIQoGlQYHsdTT7SY5WJQvqPu 0byg== X-Received: by 10.180.93.101 with SMTP id ct5mr35539272wib.23.1401178481910; Tue, 27 May 2014 01:14:41 -0700 (PDT) Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id l5sm33154659wja.12.2014.05.27.01.14.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 May 2014 01:14:41 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" , References: <52F42707.10606@alvestrand.no> <537B72EB.3080509@alvestrand.no> <53843990.2090400@alvestrand.no> In-Reply-To: <53843990.2090400@alvestrand.no> Date: Tue, 27 May 2014 11:14:33 +0300 Message-ID: <034001cf7983$b34e8d20$19eba760$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0341_01CF799C.D89D4BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQErixLqQ7IjzAXgvCM0/wEbCuqzEAETZ3QgAqrleawCSa3AH5xrsP8w Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ibPwirRNb86j2DTKCuwvBrVEwOk Subject: Re: [payload] Request to Last Call draft-ietf-vp8-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, 27 May 2014 08:14:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0341_01CF799C.D89D4BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I sent an email to the list asking for feedback on the maximum receive resolution. Regardless I will start a WGLC next week and have this issue as one that need to be concluded ASAP Roni Even Payload co-chair From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 27 May, 2014 10:07 AM To: payload@ietf.org Subject: [payload] Request to Last Call draft-ietf-vp8-payload Given that another week has gone by with zero feedback on draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby ask the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 without any link to this draft. The interest shown by the community in pursuing such a linkage is not indicative of an IETF consensus for a linkage. Harald On 05/20/2014 05:21 PM, Harald Alvestrand wrote: Just a reminder, since Cullen reminded me that this issue has languished: I have seen no response to my February 6 message raising specific issues about max-video-resolution (reproduced below). I have seen no update to max-video-resolution based on the discussion in London. I have seen no action from the chairs to either adopt or reject this work item. As far as I can tell, nothing is happening. If there is no interest in pursuing this work, can we declare that it is not an IETF work item and stop blocking other things on it? Harald On 02/06/2014 07:21 PM, Harald Alvestrand wrote: On 02/01/2014 02:51 AM, Suhas Nandakumar wrote: Hello All Following draft has been submitted to specify payload format parameters indicating an end-point's maximum image resolution receive capability in SDP. This draft aims at solving the issue with specifying such functionality for VP8 and is also applicable to other codecs in general. Thank you for finally posting this to the payload list! (The date of the draft is Dec 7 - I've been waiting for the proponents to make a public statement about it). My biggest worry with this particular proposal is that it modifies the way a=fmtp is specified. As far as I understand, the syntax of a=fmtp has previously been assumed to be specified completely by the payload specification (viz the rather non-orthogonal stuff that is in the DTMF payload). This specification proposes to add new parameters into a=fmtp that are applicable to any payload. This seems like a doubtful architectural decision. I think it would be cleaner to add a new a= attribute that is independent of codec (but linked to payload type) containing the information. I also have a nit with the way offer/answer is specified: ..... When the direction is sendonly, these attributes have no interpretation and MUST be ignored by the receiving Endpoint, if present. ...... An SDP Answerer MUST NOT include these parameters in the SDP Answer unless they are specified in the associated SDP Offer. If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless. My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply. Note: I see absolutely no reason to link this functionality, if desirable, to the RTP format for VP8. If it needs mandating, it should be mandated for all video types going forward, including H.265, and strongly recommended for all video types that have been standardized in the past. If it doesn't need mandating, it doesn't need mandating for anyone. URL: http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-r esolution-00.txt Htmlized: http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution -00 Looking forward for the inputs on how do we take his work ahead. Thanks Suhas Nandakumar _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_NextPart_000_0341_01CF799C.D89D4BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I sent an email to the list asking for feedback on the maximum = receive resolution.

Regardless I will start a WGLC next week and have this issue as one = that need to be concluded ASAP

Roni Even

Payload co-chair

 

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of = Harald Alvestrand
Sent: 27 May, 2014 10:07 = AM
To: payload@ietf.org
Subject: [payload] Request = to Last Call draft-ietf-vp8-payload

 

Given = that another week has gone by with zero feedback on = draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby = ask the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 = without any link to this draft.

The interest shown by the = community in pursuing such a linkage is not indicative of an IETF = consensus for a = linkage.

         &nb= sp;   Harald


On 05/20/2014 05:21 PM, Harald = Alvestrand wrote:

Just a reminder, since Cullen reminded me that this = issue has languished:

I have seen no response to my February 6 = message raising specific issues about max-video-resolution (reproduced = below).
I have seen no update to max-video-resolution based on the = discussion in London.
I have seen no action from the chairs to either = adopt or reject this work item.

As far as I can tell, nothing is = happening.

If there is no interest in pursuing this work, can we = declare that it is not an IETF work item and stop blocking other things = on = it?

          &n= bsp;        Harald


On = 02/06/2014 07:21 PM, Harald Alvestrand = wrote:

On 02/01/2014 02:51 AM, Suhas Nandakumar = wrote:

Hello All

 

  Following draft has been submitted to specify = payload format parameters indicating an end-point's maximum image = resolution receive capability in SDP. This draft aims at solving the = issue with specifying such functionality for VP8 and is also applicable = to other codecs in general.


Thank  you for finally posting this to the = payload list! (The date of the draft is Dec 7 - I've been waiting for = the proponents to make a public statement about it).

My biggest = worry with this particular proposal is that it modifies the way a=3Dfmtp = is specified.

As far as I understand, the syntax of a=3Dfmtp has = previously been assumed to be specified completely by the payload = specification (viz the rather non-orthogonal stuff that is in the DTMF = payload).

This specification proposes to add new parameters into = a=3Dfmtp that are applicable to any payload. This seems like a doubtful = architectural decision.
I think it would be cleaner to add a new a=3D = attribute that is independent of codec (but linked to payload type) = containing the information.

I also have a nit with the way = offer/answer is = specified:


     &=
nbsp;           &n=
bsp;        ..... When the direction =
is
   sendonly, these attributes have no =
interpretation and MUST be ignored
   by =
the receiving Endpoint, if =
present.
 
   =
......
 
   An =
SDP Answerer MUST NOT include these parameters in the SDP =
Answer
   unless they are specified in =
the associated SDP =
Offer.
 
 =

If taken literally, an SDP answerer wishing to state its =
limitations on an a=3Dsendonly M-line would not have the option to do =
so. Also, it's not clear what values would be appropriate if the values =
were meaningless.
 
My =
suggestion would be to say that the SDP Offerer should include =
max-recv-widht=3D? and max-recv-height=3D? in the SDP, to indicate that =
it understands the parameters, but has no meaningful values to =
supply.
 

Note: I see absolutely no reason to link this = functionality, if desirable, to the RTP format for VP8. If it needs = mandating, it should be mandated for all video types going forward, = including H.265, and strongly recommended for all video types that have = been standardized in the past.

If it doesn't need mandating, it = doesn't need mandating for = anyone.






 

 

Looking forward for the inputs on how do we take his = work ahead.

 

 

Thanks

Suhas Nandakumar




_______________________=
________________________
payload mailing =
list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload




-- =

Surveillance is pervasive. Go =
Dark.




_______________________=
________________________
payload mailing =
list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload




-- =

Surveillance is pervasive. Go =
Dark.




_______________________=
________________________
payload mailing =
list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload

 

------=_NextPart_000_0341_01CF799C.D89D4BC0-- From nobody Tue May 27 14:02: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 2A6031A02F4 for ; Mon, 26 May 2014 19:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 vjm6OQoF0ozL for ; Mon, 26 May 2014 19:23:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED781A02EC for ; Mon, 26 May 2014 19:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39904; q=dns/txt; s=iport; t=1401157423; x=1402367023; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BoImkLUTvMMDiC063A2rZFkX+wgxWBfjuCkC1UTa+EQ=; b=eZAuosVYtu3quiBegNBxvNqgA8hLpmqt9mDUw6/bDtt0eScgNa5r/DoN g/7FoRnXG2hveppik60T0MSq/Wm3pT+nBbAU6/K00lTqjxd5APDG3F1n1 6mGSI0zghp15OjuA5nJfKeoDZP+ojnurEDb7ox8ihwaQtq79gpj8hf4gg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOb1g1OtJA2I/2dsb2JhbABZgkJFUliCar8rARl0FnSCJQEBAQQjBAZGBhACAQgOAwQBAQsWAQYDAgICMBQJCAIEAQ0FCIg6rzmkbheNcAoHAQcYMQYBgnU2gRUErRqDOIFtAQgXIg X-IronPort-AV: E=Sophos; i="4.98,916,1392163200"; d="scan'208,217"; a="47444492" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 27 May 2014 02:23:42 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4R2NgbR011290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 02:23:42 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.180]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 26 May 2014 21:23:42 -0500 From: "Michael Ramalho (mramalho)" To: Richard Barnes , "draft-ietf-payload-g7110@tools.ietf.org" , "payload@ietf.org" Thread-Topic: [payload] AD review of draft-ietf-payload-g7110-02 Thread-Index: AQHPbhz1qBSDf1BA/UWiAAF24aHAWptTrvlg Date: Tue, 27 May 2014 02:23:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.228.240] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B9103230D6353xmbrcdx12ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/kWrNM7ZBMAtqanh9Jn8nuK8XMx4 X-Mailman-Approved-At: Tue, 27 May 2014 14:02:48 -0700 Cc: "Paul Jones \(paulej\)" Subject: Re: [payload] AD review of draft-ietf-payload-g7110-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: Tue, 27 May 2014 02:23:49 -0000 --_000_D21571530BF9644D9A443D6BD95B9103230D6353xmbrcdx12ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KTXkgYXBvbG9naWVzLCBJIGRpZG7igJl0IHNlZSB5b3VyIGVtYWlsLg0KDQpJ IGhhZCBhIGRlYXRoIGluIHRoZSBmYW1pbHkgb24gTWF5IDEwIChTYXR1cmRheSkgYW5kIEkgd2Fz buKAmXQgbWFkZSBhd2FyZSBvZiB5b3VyIGVtYWlsICh3aGljaCB5b3Ugc2VudCB0aGUgTW9uZGF5 IGFmdGVyd2FyZHMpIHVudGlsIHJlY2VudGx5Lg0KDQpNeSBjb21tZW50cyBhcmUgYmVsb3cgKHBy ZWZhY2VkIHdpdGgg4oCcTUFSOuKAnSkuIEkgaGF2ZSBjb3BpZWQgdGhlIGNvLWF1dGhvcnMgb24g dGhlIGRyYWZ0IGZvciB0aGVpciBjb21tZW50YXJ5ICh0aGV5IGNhbiBjb21tZW50IHZpYSBlbWFp bCBzZXBhcmF0ZWx5KS4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciB2ZXJ5IHRob3Jv dWdoIHJldmlldy4gSXQgd2FzIG15IGJlbGllZiB0aGF0IHRoZSBMQyBlbmRlZCwgYnV0IEkgY2Fu IHNlZSB2YWx1ZSBpbiBpbmNvcnBvcmF0aW5nIHNvbWUgb2YgeW91ciBjb21tZW50cy4NCg0KUmVn YXJkcywNCg0KTWljaGFlbCBSYW1hbGhvDQoNCkZyb206IHBheWxvYWQgW21haWx0bzpwYXlsb2Fk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhcm5lcw0KU2VudDogTW9u ZGF5LCBNYXkgMTIsIDIwMTQgNDowMSBQTQ0KVG86IGRyYWZ0LWlldGYtcGF5bG9hZC1nNzExMEB0 b29scy5pZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVjdDogW3BheWxvYWRdIEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLXBheWxvYWQtZzcxMTAtMDINCg0KSSBoYXZlIHJldmlld2VkIHRo aXMgZHJhZnQgaW4gcHJlcGFyYXRpb24gZm9yIElFVEYgTEMuICBJIGhhdmUgc29tZSBjb25jZXJu cyBiZWxvdyB0aGF0IEkgd291bGQgbGlrZSB0byBzZWUgYWRkcmVzc2VkIGJlZm9yZSBMQyAoTUFK T1IpLg0KDQpUaGFua3MsDQotLVJpY2hhcmQNCg0KDQpNQUpPUjoNCg0KUzQuMi4zLg0KSDIgaXMg YSBsaXR0bGUgdW5jbGVhci4gIElzIHRoZSBhcnJheSBpbmRleGluZyB6ZXJvLWJhc2VkPyAgSWYg c28sIHdoeSBhcmUgeW91IHNraXBwaW5nIHRoZSBmaXJzdCBvY3RldD8gIElmIHlvdSBtZWFuIGl0 IHRvIGJlIHplcm8tYmFzZWQsIGFuZCBub3QgdG8gc2tpcCB0aGUgZmlyc3Qgb2N0ZXQsIHNldCBQ PS0xIGluIEgxLg0KDQpNQVI6IE5vYm9ydSBtYXkgaGF2ZSBhbm90aGVyIHdheSB0byBhZGRyZXNz IHlvdXIgcG9pbnQgKGFuZCBjYW4gY29tbWVudCBpbiBhbm90aGVyIGVtYWlsKSwgYnV0IFAsIEsg YW5kIE4gYXJlIGNvdW50ZXJzIGFzIGRlZmluZWQgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaHMg 4oCTIG5vdCBhcnJheSBpbmRleGVzLg0KDQpNQVI6IEgyIHNheXMgdG8gcmVhZCB0aGUgbWluaW11 bSBvZiAzMjEgb3IgKE4tUCkgb2N0ZXRzIGludG8gYW4gaW50ZXJuYWwgYnVmZmVyIGZyb20gdGhl IChQKzEpc3Qgb2N0ZXQuIFNpbmNlIFAgc3RhcnRzIGF0IHplcm8gaW4gSDEsIHdlIG5ldmVyIHNr aXAgdGhlIGZpcnN0IG9jdGV0OyBvbiB0aGUgZmlyc3QgcGFzcyB0aGUgZmlyc3Qgb2N0ZXQgaXMg cGxhY2VkIGluIHRoZSBpbnRlcm5hbCBidWZmZXIuDQoNClM0LjIuMy4NCldoYXQgaGFwcGVucyBp biBINSBpZiB0aGUgRy43MTEuMCBkZWNvZGVyIGVuY291bnRlcnMgYW4gaW1wcm9wZXJseSBmb3Jt YXR0ZWQgb2N0ZXQgc2VxdWVuY2U/ICBFLmcuLCBpZiB0aGUgcHJlZml4IGNvZGUgb2N0ZXQgc3Bl Y2lmaWVzIHRoYXQgdGhlcmUgYXJlIG1vcmUgc2FtcGxlcyB0aGFuIGNvdWxkIGJlIGNvbnRhaW5l ZCBpbiB0aGUgcGFja2V0LiAgSSdtIGNvbmNlcm5lZCB0aGF0IHRoZSBwcm9jZXNzIGFzLWlzIGNv dWxkIGxlYWQgdG8gcmVhZGluZyBwYXN0IHRoZSBlbmQgb2YgdGhlIHBhY2tldCBidWZmZXIuDQoN Ck1BUjogRm9yIGEgZ2l2ZW4gcGFzcyB0aHJvdWdoIEg1LCB0aGUgaW50ZXJuYWwgYnVmZmVyIHdp bGwgYXQgbW9zdCBoYXZlIGFsbCB0aGUgcmVtYWluaW5nIG9jdGV0cyBpbiB0aGUgUlRQIHBheWxv YWQgYnkgdmlydHVlIG9mIHRoZSDigJxSZWFkIG1pbiB7MzIxLChOLVApfSBvY3RldHPigJ0gaW4g SDIuIFN0YXRlZCBhbm90aGVyIHdheSwgdGhlcmUgaXMgbm8gd2F5IHRoZSBpbnRlcm5hbCBidWZm ZXIgY2FuIGhhdmUgbW9yZSBvY3RldHMgdGhhbiB3YXMgb3JpZ2luYWxseSBpbiB0aGUgUlRQIHBh eWxvYWQuDQoNCk1BUjogSWYgdGhlIElUVS1UIHNwZWNpZmllZCBkZWNvZGVyIGNvdWxkIChkdWUg dG8gYml0IGVycm9yKSByZWFkIHBhc3QgdGhlIGVuZCBvZiB0aGUgZGF0YSBpbnRlbmRlZCBpbiB0 aGUgaW50ZXJuYWwgYnVmZmVyLCBpdCB3b3VsZCBkZWNvZGUgdGhlIChhcHBhcmVudGx5KSByYW5k b20gZGF0YSBhZnRlciB0aGF0IHRvIHRoZSBlbmQgb2YgdGhlIGludGVybmFsIGJ1ZmZlciBpbnRv IHNvbWV0aGluZyDigJMgYnV0IHRoYXQgc29tZXRoaW5nIHdvdWxkIGJlIG9mIGxpbWl0ZWQgbGVu Z3RoIGJ5IHZpcnR1ZSBvZiB0aGUgZGVjb2RpbmcgcHJvY2Vzcy4gVGhpcyBwb2ludCBpcyBhbHNv IG1hZGUgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g4oCTIHRoYXQgZGF0 YSBwb3NpbmcgYXMgYSBkZXNpcmVkIEcuNzExLjAgcGF5bG9hZCBjb3VsZCBub3QgYmUgdHVybmVk IGludG8gYSBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2sgKGFzIHRoZSBHLjcxMS4wIHByb2Nlc3Np bmcgaGFzIGEgd29yc3QgY2FzZSBwcm9jZXNzaW5nIHBhdGggYW5kIGNvbXBsZXRlcyBpbiBhIGZp bml0ZSBhbW91bnQgb2YgcHJvY2Vzc2luZywgbm8gbG9vcHMsIGV0Yy4pLg0KDQpNQVI6IElmIHdl IHJlYWxseSwgcmVhbGx5LCByZWFsbHkgd2FudCB0byBlbnN1cmUgdGhhdCB0aGUgRy43MTEuMCBk ZWNvZGVyIGRpZG7igJl0IGV2ZW4gcmVhZCBqdW5rIGluIHRoZSBpbnRlcm5hbCBidWZmZXIgcGFz dCB0aGUgaW50ZW5kZWQgRy43MTEuMCBkYXRhIOKAkyB3ZSBjb3VsZCBtb2RpZnkgdGhlIOKAnFJl YWQgbWluIHszMjEsKE4tUCl9IG9jdGV4dHPigJ0gaW4gSDIgdG8gZXhwbGljaXRseSBzdGF0ZSB0 aGF0IGFueSB1bnVzZWQgb2N0ZXRzIGluIHRoZSAzMjEgYnl0ZSBpbnRlcm5hbCBidWZmZXIgYWZ0 ZXIgdGhlIHJlYWQgbXVzdCBiZSBzZXQgdG8gMHgwMCAod2hpY2ggd291bGQgYmUgZ3VhcmFudGVl ZCBub3QgdG8gcHJvZHVjZSBhbnkgdW5pbnRlbmRlZCBHLjcxMSBzb3VyY2Ugc3ltYm9scykuIFdl IGNvdWxkIGVhc2lseSBkbyB0aGlzIGJ5IG1vZGlmeWluZyBIMiB0byByZWFkOg0KDQpSZWFkIGlu dGVybmFsIGJ1ZmZlcjog4oCcU2V0IGFsbCBvY3RldHMgaW4gdGhlIGludGVybmFsIGJ1ZmZlciB0 byB6ZXJvICgweDAwKSwgdGhlbiByZWFkIG1pbigzMjEsKE4tUCl9IG9jdGV4dHMgIGludG8gdGhl IGludGVybmFsIGJ1ZmZlciBmcm9tIHRoZSAoUCsxKSBvY3RldCBpbiB0aGUgUlRQIFBheWxvYWTi gJ0uDQoNCk1BUjogSSB3b3VsZCBkZWZlciB0byBOb2JvcnUgaGVyZS4NCg0KUzQuMi40Lg0KV2hh dCBoYXBwZW5zIGlmIHRoZSBNIGlzIG5vdCBhIG11bHRpcGxlIG9mIE4/ICBEb2VzIHRoZSByZWNl aXZlciBkaXNjYXJkIHRoZSBwYWNrZXQ/DQoNCk1BUjogR29vZCBwb2ludC4gT2YgY291cnNlIHRo aXMgc2hvdWxkIG5ldmVyIGhhcHBlbiB3aXRoIGEgY29ycmVjdGx5IGZvcm1hdHRlZCBwYXlsb2Fk LCBidXQgaXQgd291bGRu4oCZdCBodXJ0IHRvIGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0IGl0IGlz IHByb2JhYmx5IHdpc2UgdG8gZGlzY2FyZCB0aGUgcGFja2V0Lg0KDQpNQVI6IEFzIGFuIGFzaWRl LCB5b3Ugc2hvdWxkIGhhdmUgcmV2aWV3ZWQgUkZDIDM1NTEg4oCTIGFzIGl0IGlzIHNpbGVudCBv biB0aGUgcG9pbnQgb2Ygd2hhdCBoYXBwZW5zIGlmIHRoZXJlIGFyZW7igJl0IGVub3VnaCBzYW1w bGVzIHRvIGNvbXBsZXRlIGEgc2FtcGxlLWJhc2VkIGVuY29kaW5nIChTZWN0aW9uIDQuMykuDQoN Ck1BUjogQXNzdW1pbmcgbXkgY28tYXV0aG9ycyBhbmQgV0cgY2hhaXJzIGFncmVlLCB3ZSBjYW4g ZHJhZnQgc3VjaCBhIHN0YXRlbWVudC4NCg0KTUlOT1I6DQoNClM0LjIuMy4NClRoZSAiaGV1cmlz dGljIiBzZWVtcyBtb3JlIGxpa2UgYW4gImFsZ29yaXRobSIuICBPciAicHJvY2VzcyIsIGFzIHRo ZSBzZWN0aW9uIGhlYWRlciBzYXlzLg0KDQpNQVI6IElmIG15IGNvLWF1dGhvcnMgYW5kIFdHIGNo YWlycyBhZ3JlZSwgSSB3b3VsZCBiZSBoYXBweSB0byBjaGFuZ2UgaGV1cmlzdGljIHRvIHByb2Nl c3MgYXQgYWxsIHJlbGV2YW50IG9jY3VycmVuY2VzLg0KDQpTNS4xLg0KSXMgdGhlcmUgYW55IHJp c2sgb2YgRy43MTEwIGJlaW5nIGRlZmluZWQsIGFuZCBuZWVkaW5nIGEgcGF5bG9hZCBmb3JtYXQg dGhhdCB3b3VsZCBjb2xsaWRlIHdpdGggdGhpcyBpZGVudGlmaWVyPw0KDQpNQVI6IFBhdWwgSm9u ZXMgKElUVS1UIFNHMTYgUmFwcG9ydGV1ciBhbmQgY28tYXV0aG9yIGhlcmUpIGNhbiBjb21tZW50 IOKApiBidXQgdGhlIEctc2VyaWVzIG51bWJlcmluZyByYW4gb3V0IGEgd2hpbGUgYWdvIGFuZCB0 aGV5IGJlZ2FuIHRvIGxhYmVsIHRoaW5ncyB3aXRoIGEg4oCcZG904oCdIG5vbWVuY2xhdHVyZSAo ZS5nLiwgRy43MjIuMSkuIFRodXMgSSBkb3VidCB0aGF0IHRoZXJlIHdpbGwgYmUgYSBHLjcxMTAg c3RhbmRhcmQgaW4gdGhlIEcgc2VyaWVzIGZvciBtZWRpYSBjb2RlY3MuDQoNClM1LjEuDQpDYW4g d2Ugc3BlY2lmeSB0aGF0ICJjaGFubmVscyIgaXMgYW4gaW50ZWdlcj8NCg0KTUFSOiBJIGhhdmUg bm8gaXNzdWUsIGJ1dCBJIGNhbuKAmXQgZmluZCBhbnkgbWVudGlvbiBpbiBSRkM0NTY2IG9yIGFu eSBvdGhlciBSVFAgZm9ybWF0IGRlZmluaXRpb24gdGhhdCBleHBsaWNpdGx5IG1lbnRpb25zIG5v bi1pbnRlZ2VyIGNoYW5uZWxzLg0KDQpNQVI6IOKAnDUuMSBzdXJyb3VuZOKAnSBpc27igJl0IHJl YWxseSA1LjEgY2hhbm5lbHMgOy0pICkuDQoNClM1LjQuKg0KQ2FuIHNvbWVvbmUgdmVyaWZ5IHRo YXQgdGhlIHNwYWNlcyBpbiB0aGUgZXhhbXBsZXMgYXJlIHZhbGlkPyAgRS5nLiwgImNvbXBsYXcg PSBhbCIgYW5kICJwdGltZTogMjAiLg0KDQpTNi4NCkl0IHNlZW1zIGxpa2UgdGhlIGZvcm1hdCBk ZXNjcmliZWQgaGVyZSBjYW4gb25seSBob2xkIHNpbmdsZS1jaGFubmVsLCByaWdodD8gIElmIHNv LCB0aGlzIGZvcm1hdCBzZWVtcyBmaW5lLCBidXQgeW91IGRvIG5lZWQgdG8gY2xhcmlmeSB0aGF0 IGl0J3Mgc2luZ2xlLWNoYW5uZWwgb25seS4gSWYgbm90LCBpdCBzZWVtcyBsaWtlIHlvdSBuZWVk IHRvICgxKSBkZWxpbWl0IHBhY2tldHMsIGFuZCAoMikgc3BlY2lmeSB0aGUgbnVtYmVyIG9mIGNo YW5uZWxzIGF0IHRoZSBzdGFydC4NCg0KTUFSOiBZZXMsIHRoZSBzdG9yYWdlIG1vZGUgZGVmaW5l ZCBpbiBTZWN0aW9uIDYuMyB3aXRoIHZlcnNpb24gb2N0ZXQg4oCcMHgwMOKAnSBvbmx5IHN1cHBv cnRzIGEgc2luZ2xlIGNoYW5uZWwuDQoNCk1BUjogQXMgdGhlIHRleHQgZGVzY3JpYmVzLCBpZiB0 aGVyZSBpcyBhIGZ1dHVyZSBuZWVkIGZvciBvdGhlciBmb3JtYXRzIHRvIHN1cHBvcnQgdGhpbmdz IGxpa2UgbXVsdGlwbGUgY2hhbm5lbHMgb3IgbWV0YWRhdGEg4oCmIHRoZXkgY2FuIGJlIGRlZmlu ZWQgZWxzZXdoZXJlIChpbiBhbm90aGVyIElFVEYgZG9jdW1lbnQgb3IgaW4gYW5vdGhlciBTRE8p IHdpdGggYSB2ZXJzaW9uIG51bWJlciBvdGhlciB0aGFuIOKAnDB4MDDigJ0uDQoNCg0KRURJVE9S SUFMOg0KDQpTNC4yLjQuDQoidGhlIG9wdGlvbmFsIHBhcmFtZXRlciBpcyBhIE1VU1QiIC0+ICJ0 aGUgb3B0aW9uYWwgJ2NoYW5uZWxzJyBwYXJhbWV0ZXIgaXMgUkVRVUlSRUQiDQoNCk1BUjogR29v ZCBjYXRjaC4NCg0KUzQuMi4zLg0KSXQgc2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBzaW1wbGVyIHRv IHN0YXRlIHRoZSBkZWNvZGluZyBhbGdvcml0aG0gYXMgd2hpbGUgbG9vcCB3aXRoIGFuIGlmIHN0 YXRlbWVudCwgc2luY2UgaXQgc2VlbXMgbGlrZSB0aGF0J3MgaG93IHlvdSB3b3VsZCBpbXBsZW1l bnQgaXQgaW4gbW9zdCBub3JtYWwgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLiAgKFNlZSwgZS5nLiwg dGhlIHB5dGhvbiBzbmlwcGV0IGJlbG93KS4gIElmIHlvdSByZWFsbHkgd2FudCBhIHN0YXRlIG1h Y2hpbmUgbGlrZSByZXByZXNlbnRhdGlvbiwgaXQgd291bGQgYmUgbmljZSB0byBhdCBsZWFzdCBo YXZlIGEgcGljdHVyZSBvZiBpdC4NCg0KICAgICAgKy0tLS0tLS0tLS0tKw0KICAgICAgfCAgICAg ICAgICAgfA0KICAgICAgViAgICAgICAgICAgfA0KSDEgLT4gSDIgLT4gSDMgLT4gSDQgLT4gU1RP UA0KICAgICAgXiAgICAgfCAgICAgICAgICAgIF4NCiAgICAgIHwgICAgIHwgICAgICAgICAgICB8 DQogICAgICB8ICAgICArLS0tPiBINSAtLS0tKw0KICAgICAgfCAgICAgICAgICAgfA0KICAgICAg fCAgICAgICAgICAgfA0KICAgICAgKy0tLS0tLS0tLS0tKw0KDQpkZWYgZGVjb2RlX2c3MTFfMF9w YXlsb2FkKHBheWxvYWQpOg0KICAjIEgxDQogIFAgPSAwDQogIE4gPSBsZW4ocGF5bG9hZCkNCiAg aW50ZXJuYWwgPSBbXQ0KICBvdXRwdXQgPSBbXQ0KICB3aGlsZSBQIDwgTjoNCiAgICAjIEgyDQog ICAgaW50ZXJuYWwgPSBwYWNrZXRbIFArMSA6IFArMSttaW4oMzIxLE4tUCkgXQ0KICAgICMgSDMN CiAgICBpZiBpbnRlcm5hbFswXSA9PSAnXHgwMCc6DQogICAgICAjIEg0DQogICAgICBQICs9IDEN CiAgICBlbHNlOg0KICAgICAgIyBINQ0KICAgICAgKHN5bWJvbHMsIFEpID0gZzcxMV8wX2RlY29k ZShpbnRlcm5hbCkNCiAgICAgIG91dHB1dC5leHRlbmQoc3ltYm9scykNCiAgICAgIEsgKz0gbGVu KHN5bWJvbHMpICMgPT0gTQ0KICAgICAgUCArPSBRDQogIHJldHVybiBvdXRwdXQNCg0KTUFSOiBJ IHdyb3RlIHRoZSBwcm9zZSBtb3JlIG9yIGxlc3MgdG8gbWltaWMgdGhlIHdvcmRzIGluIHRoZSBJ VFUtVCBHLjcxMS4wIHNwZWNpZmljYXRpb24uDQoNCk1BUjogSG93ZXZlciwgSSB3b3VsZCBoYXZl IG5vIGlzc3VlIHdpdGggYSBwaWN0dXJlIG9yIHBzZXVkbyBjb2RlLiBJIGNvbXBsZXRlbHkgZGVm ZXIgdG8gUGF1bCBKb25lcyBvciBOb2JvcnUgSGFyYWRhIGhlcmUuDQoNCk1BUjogTXkgbW9zdCBz aW5jZXJlIHRoYW5rcyBmb3IgeW91ciB0aHJvdWdoIHJldmlldy4NCg0K --_000_D21571530BF9644D9A443D6BD95B9103230D6353xmbrcdx12ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmljaGFyZCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk15IGFwb2xvZ2llcywgSSBkaWRu4oCZdCBzZWUgeW91ciBlbWFpbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg aGFkIGEgZGVhdGggaW4gdGhlIGZhbWlseSBvbiBNYXkgMTAgKFNhdHVyZGF5KSBhbmQgSSB3YXNu 4oCZdCBtYWRlIGF3YXJlIG9mIHlvdXIgZW1haWwgKHdoaWNoIHlvdSBzZW50IHRoZSBNb25kYXkg YWZ0ZXJ3YXJkcykgdW50aWwgcmVjZW50bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBjb21tZW50cyBhcmUgYmVs b3cgKHByZWZhY2VkIHdpdGgg4oCcTUFSOuKAnSkuIEkgaGF2ZSBjb3BpZWQgdGhlIGNvLWF1dGhv cnMgb24gdGhlIGRyYWZ0IGZvciB0aGVpciBjb21tZW50YXJ5ICh0aGV5IGNhbiBjb21tZW50IHZp YSBlbWFpbCBzZXBhcmF0ZWx5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlv dXIgdmVyeSB0aG9yb3VnaCByZXZpZXcuIEl0IHdhcyBteSBiZWxpZWYgdGhhdCB0aGUgTEMgZW5k ZWQsIGJ1dCBJIGNhbiBzZWUgdmFsdWUgaW4gaW5jb3Jwb3JhdGluZyBzb21lIG9mIHlvdXIgY29t bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbCBSYW1hbGhvPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBwYXlsb2FkIFttYWlsdG86cGF5 bG9hZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWNoYXJkIEJhcm5l czxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAxMiwgMjAxNCA0OjAxIFBNPGJyPg0KPGI+ VG86PC9iPiBkcmFmdC1pZXRmLXBheWxvYWQtZzcxMTBAdG9vbHMuaWV0Zi5vcmc7IHBheWxvYWRA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3BheWxvYWRdIEFEIHJldmlldyBvZiBkcmFm dC1pZXRmLXBheWxvYWQtZzcxMTAtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBmb3IgSUVURiBM Qy4gJm5ic3A7SSBoYXZlIHNvbWUgY29uY2VybnMgYmVsb3cgdGhhdCBJIHdvdWxkIGxpa2UgdG8g c2VlIGFkZHJlc3NlZCBiZWZvcmUgTEMgKE1BSk9SKS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1BSk9SOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TNC4yLjMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SDIg aXMgYSBsaXR0bGUgdW5jbGVhci4gJm5ic3A7SXMgdGhlIGFycmF5IGluZGV4aW5nIHplcm8tYmFz ZWQ/ICZuYnNwO0lmIHNvLCB3aHkgYXJlIHlvdSBza2lwcGluZyB0aGUgZmlyc3Qgb2N0ZXQ/ICZu YnNwO0lmIHlvdSBtZWFuIGl0IHRvIGJlIHplcm8tYmFzZWQsIGFuZCBub3QgdG8gc2tpcCB0aGUg Zmlyc3Qgb2N0ZXQsIHNldCBQPS0xIGluIEgxLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6IE5vYm9ydSBtYXkgaGF2ZSBhbm90 aGVyIHdheSB0byBhZGRyZXNzIHlvdXIgcG9pbnQgKGFuZCBjYW4gY29tbWVudCBpbiBhbm90aGVy IGVtYWlsKSwgYnV0IFAsIEsgYW5kIE4gYXJlIGNvdW50ZXJzIGFzIGRlZmluZWQgaW4gdGhlIHBy ZXZpb3VzIHBhcmFncmFwaHMNCiDigJMgbm90IGFycmF5IGluZGV4ZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6 IEgyIHNheXMgdG8gcmVhZCB0aGUgbWluaW11bSBvZiAzMjEgb3IgKE4tUCkgb2N0ZXRzIGludG8g YW4gaW50ZXJuYWwgYnVmZmVyIGZyb20gdGhlIChQJiM0MzsxKXN0IG9jdGV0LiBTaW5jZSBQIHN0 YXJ0cyBhdCB6ZXJvIGluIEgxLCB3ZSBuZXZlciBza2lwIHRoZSBmaXJzdA0KIG9jdGV0OyBvbiB0 aGUgZmlyc3QgcGFzcyB0aGUgZmlyc3Qgb2N0ZXQgaXMgcGxhY2VkIGluIHRoZSBpbnRlcm5hbCBi dWZmZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlM0LjIuMy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGhhcHBlbnMgaW4gSDUgaWYgdGhlIEcu NzExLjAgZGVjb2RlciBlbmNvdW50ZXJzIGFuIGltcHJvcGVybHkgZm9ybWF0dGVkIG9jdGV0IHNl cXVlbmNlPyAmbmJzcDtFLmcuLCBpZiB0aGUgcHJlZml4IGNvZGUgb2N0ZXQgc3BlY2lmaWVzIHRo YXQgdGhlcmUgYXJlIG1vcmUgc2FtcGxlcyB0aGFuIGNvdWxkIGJlIGNvbnRhaW5lZCBpbiB0aGUg cGFja2V0LiAmbmJzcDtJJ20gY29uY2VybmVkIHRoYXQgdGhlIHByb2Nlc3MgYXMtaXMNCiBjb3Vs ZCBsZWFkIHRvIHJlYWRpbmcgcGFzdCB0aGUgZW5kIG9mIHRoZSBwYWNrZXQgYnVmZmVyLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N QVI6IEZvciBhIGdpdmVuIHBhc3MgdGhyb3VnaCBINSwgdGhlIGludGVybmFsIGJ1ZmZlciB3aWxs IGF0IG1vc3QgaGF2ZSBhbGwgdGhlIHJlbWFpbmluZyBvY3RldHMgaW4gdGhlIFJUUCBwYXlsb2Fk IGJ5IHZpcnR1ZSBvZiB0aGUg4oCcUmVhZCBtaW4gezMyMSwoTi1QKX0gb2N0ZXRz4oCdDQogaW4g SDIuIFN0YXRlZCBhbm90aGVyIHdheSwgdGhlcmUgaXMgbm8gd2F5IHRoZSBpbnRlcm5hbCBidWZm ZXIgY2FuIGhhdmUgbW9yZSBvY3RldHMgdGhhbiB3YXMgb3JpZ2luYWxseSBpbiB0aGUgUlRQIHBh eWxvYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NQVI6IElmIHRoZSBJVFUtVCBzcGVjaWZpZWQgZGVjb2RlciBjb3Vs ZCAoZHVlIHRvIGJpdCBlcnJvcikgcmVhZCBwYXN0IHRoZSBlbmQgb2YgdGhlIGRhdGEgaW50ZW5k ZWQgaW4gdGhlIGludGVybmFsIGJ1ZmZlciwgaXQgd291bGQgZGVjb2RlIHRoZSAoYXBwYXJlbnRs eSkNCiByYW5kb20gZGF0YSBhZnRlciB0aGF0IHRvIHRoZSBlbmQgb2YgdGhlIGludGVybmFsIGJ1 ZmZlciBpbnRvIHNvbWV0aGluZyDigJMgYnV0IHRoYXQgc29tZXRoaW5nIHdvdWxkIGJlIG9mIGxp bWl0ZWQgbGVuZ3RoIGJ5IHZpcnR1ZSBvZiB0aGUgZGVjb2RpbmcgcHJvY2Vzcy4gVGhpcyBwb2lu dCBpcyBhbHNvIG1hZGUgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g4oCT IHRoYXQgZGF0YSBwb3NpbmcgYXMgYSBkZXNpcmVkIEcuNzExLjANCiBwYXlsb2FkIGNvdWxkIG5v dCBiZSB0dXJuZWQgaW50byBhIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFjayAoYXMgdGhlIEcuNzEx LjAgcHJvY2Vzc2luZyBoYXMgYSB3b3JzdCBjYXNlIHByb2Nlc3NpbmcgcGF0aCBhbmQgY29tcGxl dGVzIGluIGEgZmluaXRlIGFtb3VudCBvZiBwcm9jZXNzaW5nLCBubyBsb29wcywgZXRjLikuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5NQVI6IElmIHdlIHJlYWxseSwgcmVhbGx5LCByZWFsbHkgd2FudCB0byBlbnN1cmUg dGhhdCB0aGUgRy43MTEuMCBkZWNvZGVyIGRpZG7igJl0IGV2ZW4gcmVhZCBqdW5rIGluIHRoZSBp bnRlcm5hbCBidWZmZXIgcGFzdCB0aGUgaW50ZW5kZWQgRy43MTEuMCBkYXRhIOKAkyB3ZSBjb3Vs ZA0KIG1vZGlmeSB0aGUg4oCcUmVhZCBtaW4gezMyMSwoTi1QKX0gb2N0ZXh0c+KAnSBpbiBIMiB0 byBleHBsaWNpdGx5IHN0YXRlIHRoYXQgYW55IHVudXNlZCBvY3RldHMgaW4gdGhlIDMyMSBieXRl IGludGVybmFsIGJ1ZmZlciBhZnRlciB0aGUgcmVhZCBtdXN0IGJlIHNldCB0byAweDAwICh3aGlj aCB3b3VsZCBiZSBndWFyYW50ZWVkIG5vdCB0byBwcm9kdWNlIGFueSB1bmludGVuZGVkIEcuNzEx IHNvdXJjZSBzeW1ib2xzKS4gV2UgY291bGQgZWFzaWx5IGRvDQogdGhpcyBieSBtb2RpZnlpbmcg SDIgdG8gcmVhZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlYWQgaW50ZXJuYWwgYnVmZmVyOiDigJxTZXQgYWxsIG9j dGV0cyBpbiB0aGUgaW50ZXJuYWwgYnVmZmVyIHRvIHplcm8gKDB4MDApLCB0aGVuIHJlYWQgbWlu KDMyMSwoTi1QKX0gb2N0ZXh0cyAmbmJzcDtpbnRvIHRoZSBpbnRlcm5hbCBidWZmZXIgZnJvbSB0 aGUgKFAmIzQzOzEpIG9jdGV0DQogaW4gdGhlIFJUUCBQYXlsb2Fk4oCdLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFS OiBJIHdvdWxkIGRlZmVyIHRvIE5vYm9ydSBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TNC4yLjQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGhhcHBl bnMgaWYgdGhlIE0gaXMgbm90IGEgbXVsdGlwbGUgb2YgTj8gJm5ic3A7RG9lcyB0aGUgcmVjZWl2 ZXIgZGlzY2FyZCB0aGUgcGFja2V0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6IEdvb2QgcG9pbnQuIE9mIGNvdXJzZSB0aGlz IHNob3VsZCBuZXZlciBoYXBwZW4gd2l0aCBhIGNvcnJlY3RseSBmb3JtYXR0ZWQgcGF5bG9hZCwg YnV0IGl0IHdvdWxkbuKAmXQgaHVydCB0byBleHBsaWNpdGx5IG1lbnRpb24gdGhhdCBpdCBpcyBw cm9iYWJseSB3aXNlDQogdG8gZGlzY2FyZCB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFSOiBBcyBh biBhc2lkZSwgeW91IHNob3VsZCBoYXZlIHJldmlld2VkIFJGQyAzNTUxIOKAkyBhcyBpdCBpcyBz aWxlbnQgb24gdGhlIHBvaW50IG9mIHdoYXQgaGFwcGVucyBpZiB0aGVyZSBhcmVu4oCZdCBlbm91 Z2ggc2FtcGxlcyB0byBjb21wbGV0ZSBhIHNhbXBsZS1iYXNlZA0KIGVuY29kaW5nIChTZWN0aW9u IDQuMykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NQVI6IEFzc3VtaW5nIG15IGNvLWF1dGhvcnMgYW5kIFdHIGNoYWly cyBhZ3JlZSwgd2UgY2FuIGRyYWZ0IHN1Y2ggYSBzdGF0ZW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NSU5PUjo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UzQuMi4zLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlICZxdW90O2hldXJpc3RpYyZxdW90OyBzZWVtcyBtb3JlIGxpa2UgYW4gJnF1b3Q7YWxnb3Jp dGhtJnF1b3Q7LiAmbmJzcDtPciAmcXVvdDtwcm9jZXNzJnF1b3Q7LCBhcyB0aGUgc2VjdGlvbiBo ZWFkZXIgc2F5cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TUFSOiBJZiBteSBjby1hdXRob3JzIGFuZCBXRyBjaGFpcnMgYWdyZWUs IEkgd291bGQgYmUgaGFwcHkgdG8gY2hhbmdlIGhldXJpc3RpYyB0byBwcm9jZXNzIGF0IGFsbCBy ZWxldmFudCBvY2N1cnJlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlM1LjEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBhbnkgcmlzayBvZiBHLjcx MTAgYmVpbmcgZGVmaW5lZCwgYW5kIG5lZWRpbmcgYSBwYXlsb2FkIGZvcm1hdCB0aGF0IHdvdWxk IGNvbGxpZGUgd2l0aCB0aGlzIGlkZW50aWZpZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUjogUGF1bCBKb25lcyAoSVRVLVQg U0cxNiBSYXBwb3J0ZXVyIGFuZCBjby1hdXRob3IgaGVyZSkgY2FuIGNvbW1lbnQg4oCmIGJ1dCB0 aGUgRy1zZXJpZXMgbnVtYmVyaW5nIHJhbiBvdXQgYSB3aGlsZSBhZ28gYW5kIHRoZXkgYmVnYW4g dG8gbGFiZWwgdGhpbmdzIHdpdGgNCiBhIOKAnGRvdOKAnSBub21lbmNsYXR1cmUgKGUuZy4sIEcu NzIyLjEpLiBUaHVzIEkgZG91YnQgdGhhdCB0aGVyZSB3aWxsIGJlIGEgRy43MTEwIHN0YW5kYXJk IGluIHRoZSBHIHNlcmllcyBmb3IgbWVkaWEgY29kZWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UzUuMS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB3ZSBzcGVjaWZ5IHRo YXQgJnF1b3Q7Y2hhbm5lbHMmcXVvdDsgaXMgYW4gaW50ZWdlcj88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFSOiBJIGhhdmUgbm8g aXNzdWUsIGJ1dCBJIGNhbuKAmXQgZmluZCBhbnkgbWVudGlvbiBpbiBSRkM0NTY2IG9yIGFueSBv dGhlciBSVFAgZm9ybWF0IGRlZmluaXRpb24gdGhhdCBleHBsaWNpdGx5IG1lbnRpb25zIG5vbi1p bnRlZ2VyIGNoYW5uZWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFSOiDigJw1LjEgc3Vycm91bmTigJ0gaXNu4oCZ dCByZWFsbHkgNS4xIGNoYW5uZWxzIDstKSApLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UzUuNC4qJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4gc29tZW9uZSB2ZXJp ZnkgdGhhdCB0aGUgc3BhY2VzIGluIHRoZSBleGFtcGxlcyBhcmUgdmFsaWQ/ICZuYnNwO0UuZy4s ICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Y29tcGxhdyA9IGFsJnF1b3Q7IGFuZCAm cXVvdDtwdGltZTogMjAmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlM2Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkl0IHNlZW1zIGxpa2UgdGhlIGZvcm1h dCBkZXNjcmliZWQgaGVyZSBjYW4gb25seSBob2xkIHNpbmdsZS1jaGFubmVsLCByaWdodD8gJm5i c3A7SWYgc28sIHRoaXMgZm9ybWF0IHNlZW1zIGZpbmUsIGJ1dCB5b3UgZG8gbmVlZCB0byBjbGFy aWZ5IHRoYXQgaXQncyBzaW5nbGUtY2hhbm5lbCBvbmx5LiBJZiBub3QsIGl0IHNlZW1zIGxpa2Ug eW91IG5lZWQgdG8gKDEpIGRlbGltaXQNCiBwYWNrZXRzLCBhbmQgKDIpIHNwZWNpZnkgdGhlIG51 bWJlciBvZiBjaGFubmVscyBhdCB0aGUgc3RhcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6IFllcywgdGhlIHN0 b3JhZ2UgbW9kZSBkZWZpbmVkIGluIFNlY3Rpb24gNi4zIHdpdGggdmVyc2lvbiBvY3RldCDigJww eDAw4oCdIG9ubHkgc3VwcG9ydHMgYSBzaW5nbGUgY2hhbm5lbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUjogQXMg dGhlIHRleHQgZGVzY3JpYmVzLCBpZiB0aGVyZSBpcyBhIGZ1dHVyZSBuZWVkIGZvciBvdGhlciBm b3JtYXRzIHRvIHN1cHBvcnQgdGhpbmdzIGxpa2UgbXVsdGlwbGUgY2hhbm5lbHMgb3IgbWV0YWRh dGEg4oCmIHRoZXkgY2FuIGJlIGRlZmluZWQgZWxzZXdoZXJlDQogKGluIGFub3RoZXIgSUVURiBk b2N1bWVudCBvciBpbiBhbm90aGVyIFNETykgd2l0aCBhIHZlcnNpb24gbnVtYmVyIG90aGVyIHRo YW4g4oCcMHgwMOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5FRElUT1JJQUw6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlM0LjIuNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDt0aGUgb3B0aW9uYWwgcGFyYW1ldGVyIGlzIGEg TVVTVCZxdW90OyAtJmd0OyAmcXVvdDt0aGUgb3B0aW9uYWwgJ2NoYW5uZWxzJyBwYXJhbWV0ZXIg aXMgUkVRVUlSRUQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFSOiBHb29kIGNhdGNoLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TNC4yLjMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgc2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBzaW1wbGVyIHRvIHN0YXRlIHRoZSBkZWNvZGlu ZyBhbGdvcml0aG0gYXMgd2hpbGUgbG9vcCB3aXRoIGFuIGlmIHN0YXRlbWVudCwgc2luY2UgaXQg c2VlbXMgbGlrZSB0aGF0J3MgaG93IHlvdSB3b3VsZCBpbXBsZW1lbnQgaXQgaW4gbW9zdCBub3Jt YWwgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLiAmbmJzcDsoU2VlLCBlLmcuLCB0aGUgcHl0aG9uIHNu aXBwZXQgYmVsb3cpLiAmbmJzcDtJZg0KIHlvdSByZWFsbHkgd2FudCBhIHN0YXRlIG1hY2hpbmUg bGlrZSByZXByZXNlbnRhdGlvbiwgaXQgd291bGQgYmUgbmljZSB0byBhdCBsZWFzdCBoYXZlIGEg cGljdHVyZSBvZiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgViAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkgxIC0mZ3Q7IEgy IC0mZ3Q7IEgzIC0mZ3Q7IEg0IC0mZ3Q7IFNUT1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IF4gJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0mZ3Q7 IEg1IC0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVmIGRlY29kZV9n NzExXzBfcGF5bG9hZChwYXlsb2FkKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAjIEgxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgUCA9IDA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBOID0gbGVuKHBheWxvYWQp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgaW50ZXJuYWwgPSBbXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IG91dHB1dCA9IFtdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgd2hpbGUgUCAmbHQ7IE46PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICMgSDI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgaW50ZXJuYWwgPSBwYWNrZXRbIFAmIzQzOzEgOiBQJiM0MzsxJiM0Mztt aW4oMzIxLE4tUCkgXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAjIEgzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGlmIGludGVybmFsWzBdID09ICdc eDAwJzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICMgSDQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFAgJiM0Mzs9IDE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgZWxzZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICMgSDU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IChzeW1ib2xz LCBRKSA9IGc3MTFfMF9kZWNvZGUoaW50ZXJuYWwpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBvdXRwdXQuZXh0 ZW5kKHN5bWJvbHMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBLICYjNDM7PSBsZW4oc3ltYm9scykgIyA9PSBN PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyBQICYjNDM7PSBRPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgcmV0dXJuIG91dHB1dDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6IEkgd3Jv dGUgdGhlIHByb3NlIG1vcmUgb3IgbGVzcyB0byBtaW1pYyB0aGUgd29yZHMgaW4gdGhlIElUVS1U IEcuNzExLjAgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUjogSG93ZXZlciwgSSB3b3VsZCBo YXZlIG5vIGlzc3VlIHdpdGggYSBwaWN0dXJlIG9yIHBzZXVkbyBjb2RlLiBJIGNvbXBsZXRlbHkg ZGVmZXIgdG8gUGF1bCBKb25lcyBvciBOb2JvcnUgSGFyYWRhIGhlcmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NQVI6 IE15IG1vc3Qgc2luY2VyZSB0aGFua3MgZm9yIHlvdXIgdGhyb3VnaCByZXZpZXcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D21571530BF9644D9A443D6BD95B9103230D6353xmbrcdx12ciscoc_-- From nobody Wed May 28 05:29:02 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 C0FA11A095E for ; Wed, 28 May 2014 05:29:00 -0700 (PDT) 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 O9xjQPHDhA2C for ; Wed, 28 May 2014 05:28:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1531A095D for ; Wed, 28 May 2014 05:28:58 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-4f-5385d685557b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.6C.28642.586D5835; Wed, 28 May 2014 14:28:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Wed, 28 May 2014 14:28:52 +0200 Message-ID: <5385D684.3030709@ericsson.com> Date: Wed, 28 May 2014 14:28:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: References: <5310AF7F.9050508@ericsson.com> In-Reply-To: <5310AF7F.9050508@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW7rtdZgg85+cYtLF88yOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/PT68wF91kr+r5cZG9gvM7SxcjBISFgIrFxkUYXIyeQKSZx 4d56ti5GLg4hgaOMEo9v32OEcJYzSpz8uYkNpIpXQFti+avPzCA2i4CqxP5HZ8HibAIWEjd/ NILZogLBEhse/mWHqBeUODnzCQuILQK04eH7s2C9wgKOEhsaW5lAbCGgme8OTgWr4RTQkTh+ toUZ4jhxiZ7GIJAws4CexJSrLYwQtrxE89bZzDCtDU0drBMYBWch2TYLScssJC0LGJlXMYoW pxYX56YbGemlFmUmFxfn5+nlpZZsYgQG5sEtv612MB587niIUYCDUYmHd8GllmAh1sSy4src Q4zSHCxK4rwXNaqDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAWhrXeOr7a7yU/1zZZQRkj 28fR/aY//7xZG/N40VPVvdJH5snEmqUF+qq6CZ7NPsD8U3n+uyk+hzdpLD8kp33yxEf5/SE3 D+qtde27z5S69KSBVF3sNZu0jc0br/OzXgoP7ftXOM3PZ5m0uZnuuV0y1R8fdqxhm209Sdt8 YYnt3NYJyT9Dtu5RYinOSDTUYi4qTgQA8pNXeC0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/OapRMyXmDi-GYT94J097l7E3yE0 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: Wed, 28 May 2014 12:29:00 -0000 WG, You can consider these issues closed from my side. I have been working with the authors on the forthcoming -04. And all my major issues appear resolved in that version. So there is no reason to not progress the draft on my account. 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 Victor.Demjanenko@vocal.com Wed May 28 07:59: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 79F531A042B for ; Wed, 28 May 2014 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 52Wp2u3d4npS for ; Wed, 28 May 2014 07:59:43 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id 93D281A09AC for ; Wed, 28 May 2014 07:59:31 -0700 (PDT) X-ASG-Debug-ID: 1401289167-03d25078ae443c10001-U2jSCT Received: from host101.olm1.com (host101.olm1.com [72.236.255.11]) by cuda.olm1.com with ESMTP id hWccAl77UwNxec22 for ; Wed, 28 May 2014 10:59:27 -0400 (EDT) X-Barracuda-Envelope-From: Victor.Demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.11 Received: from av-engine.localhost (host101.olm1.com [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 6ACBD6970585; Wed, 28 May 2014 10:59:28 -0400 (EDT) Received: 5385f9d063c59863497eda512b73d2 Received: from host101.olm1.com (unknown [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 24CDD6970576; Wed, 28 May 2014 10:59:28 -0400 (EDT) Received: from dev1PC (unknown [72.43.202.98]) by host101.olm1.com (Postfix) with ESMTP; Wed, 28 May 2014 10:59:28 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: Date: Wed, 28 May 2014 10:58:57 -0400 X-ASG-Orig-Subj: draft-demjanenko-payload-melpe-00.txt Message-ID: <117301cf7a85$5a2e5a60$0e8b0f20$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1174_01CF7A63.D31CBA60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac96hVnUe9tGjKyhSxW7dKwOZZ5hrw== Content-Language: en-us X-Barracuda-Connect: host101.olm1.com[72.236.255.11] X-Barracuda-Start-Time: 1401289167 X-Barracuda-URL: http://72.236.255.32:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6182 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/payload/xBOj_gG1EgXEmVsF_XxUVmRHjMs Subject: [payload] draft-demjanenko-payload-melpe-00.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: Wed, 28 May 2014 15:18:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1174_01CF7A63.D31CBA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello everyone. I'd like to introduce myself and make you aware of our recent draft of a payload specification. My company, VOCAL Technologies, has been in the business of licensing software and algorithms for communications system for the past 25 years. We have implemented all sorts of telephone line standards (including data, fax and voice) and now all sorts of VoIP protocols (including various common protocols and speech coders). One speech coder that we have used quite extensively over the past 10 years is MELP/MELPe. These were initially developed by DOD/NSA and later issued as a world-wide standard by NATO as STANAG 4591. This speech coder operates at three different rates, 2400, 1200 and 600bps. The primary use was for encrypted radio channels. We have had customers use MELP/MELPe for all sorts of applications and we have bridged traditional VOIP with MELP. After packaging MELP in RTP for several customers, we have realized that we need to promote a standardized RTP payload for this speech coder. This draft is an effort that we believe should result in an RFC to specify the RTP payload format and SDP parameters for the MELPe speech coder. Thank you for your time and comments. (BTW, we have audio examples of MELP encoded speech at http://www.vocal.com/audio-examples/other-speech-coder-audio-examples/. I hope to not be seen as self promoting but rather enlightening. Since many people may not be aware of MELP, I wanted to briefly convey the context and potential applications.) Victor Demjanenko, Ph.D. Associate VOCAL Technologies, Ltd. 520 Lee Entrance Amherst, NY 14228 Victor.Demjanenko@vocal.com http://www.vocal.com Tel: +1-716-688-4675 Fax: +1-716-639-0713 Confidential Information The information contained in this electronic mail transmission is confidential and intended to be sent only to the stated recipient of the transmission. It may therefore be protected from unauthorized use or dissemination. If you are not the intended recipient or the intended recipient's agent, you are hereby notified that any review, use, dissemination, distribution or copying of this communication is strictly prohibited. You are also asked to notify us immediately by telephone and to delete this transmission with any attachments and destroy all copies in any form. Thank you in advance for your cooperation. ------=_NextPart_000_1174_01CF7A63.D31CBA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = everyone.

 

I’d like to introduce myself and make you aware = of our recent draft of a payload specification.

 

My company, = VOCAL Technologies, has been in the business of licensing software and = algorithms for communications system for the past 25 years.  We = have implemented all sorts of telephone line standards (including data, = fax and voice) and now all sorts of VoIP protocols (including various = common protocols and speech coders).

 

One speech = coder that we have used quite extensively over the past 10 years is = MELP/MELPe.  These were initially developed by DOD/NSA and later = issued as a world-wide standard by NATO as STANAG 4591.  This = speech coder operates at three different rates, 2400, 1200 and = 600bps.  The primary use was for encrypted radio channels.  We = have had customers use MELP/MELPe for all sorts of applications and we = have bridged traditional VOIP with MELP.

 

After = packaging MELP in RTP for several customers, we have realized that we = need to promote a standardized RTP payload for this speech coder.  = This draft is an effort that we believe should result in an RFC to = specify the RTP payload format and SDP parameters for the MELPe speech = coder.

 

Thank you for your time and comments.

 

(BTW, we = have audio examples of MELP encoded speech at http://www.vocal.com/audio-examples/other-speech-coder-audio-examp= les/.  I hope to not be seen as self promoting but rather = enlightening.  Since many people may not be aware of MELP, I wanted = to briefly convey the context and potential = applications.)

 

 

Victor = Demjanenko, Ph.D.
Associate
VOCAL Technologies, Ltd.
520 Lee = Entrance
Amherst, NY  14228
Victor.Demjanenko@vocal.com
http://www.vocal.com
Tel: = +1-716-688-4675
Fax: +1-716-639-0713

 

Confidential = Information
The information contained in this electronic mail = transmission is confidential and intended to be sent only to the stated = recipient of the transmission.  It may therefore be protected from = unauthorized use or dissemination.  If you are not the intended = recipient or the intended recipient's agent, you are hereby notified = that any review, use, dissemination, distribution or copying of this = communication is strictly prohibited.  You are also asked to notify = us immediately by telephone and to delete this transmission with any = attachments and destroy all copies in any form.  Thank you in = advance for your cooperation.

 

------=_NextPart_000_1174_01CF7A63.D31CBA60-- From nobody Wed May 28 08:19:12 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 E9E391A032F for ; Tue, 27 May 2014 22:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbpdFirbXiig for ; Tue, 27 May 2014 22:09:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6681A0325 for ; Tue, 27 May 2014 22:09:47 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s4S59LYT027939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 01:09:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1401253767; bh=KNkViU59DHJ1Ld1gALOiEz+ugPQzUDMSTSRXcUFZSkc=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=eBABuUTUyubJFikjnKSnXI4amkX0eDMP0vgV6LOokpR02leheZE13oR3jVG3nJZLL Ivm0U/GMKaAE/JuKv7hKi7jqH3tkT6LYJExbXre+yDmKq6F7CZx1m3p51OeP0tyJ2B z77eobBUApuhe7v+WpJUmHEOoYrAkSZkAvSAxge0= From: "Paul E. Jones" To: "Michael Ramalho (mramalho)" , "Richard Barnes" , "draft-ietf-payload-g7110@tools.ietf.org" , "payload@ietf.org" Date: Wed, 28 May 2014 05:09:30 +0000 Content-Type: multipart/alternative; boundary="------=_MB13B37B4C-1809-4AE8-A36B-7138D8AF1B42" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/x8sWMu6A7SRaTw8Ej9TwA97kXDg X-Mailman-Approved-At: Wed, 28 May 2014 08:19:11 -0700 Cc: "Paul Jones \(paulej\)" Subject: Re: [payload] AD review of draft-ietf-payload-g7110-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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, 28 May 2014 05:09:49 -0000 --------=_MB13B37B4C-1809-4AE8-A36B-7138D8AF1B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Guys, Comments to items left for me: >S5.1. > >Is there any risk of G.7110 being defined, and needing a payload format= =20 >that would collide with this identifier? > > > >MAR: Paul Jones (ITU-T SG16 Rapporteur and co-author here) can comment=20 >=E2=80=A6 but the G-series numbering ran out a while ago and they began= to=20 >label things with a =E2=80=9Cdot=E2=80=9D nomenclature (e.g., G.722.1).= Thus I doubt=20 >that there will be a G.7110 standard in the G series for media codecs. > I would not say the number space ran out, as the ITU can (and does)=20 number documents using more than 3 digits. There are documents like=20 G.7713.1, for example. Would there ever be a G.7110? I cannot dismiss=20 that as a possibility, but it's highly unlikely the ITU would elect to=20 use that number to refer to a voice codec, as it would make it difficult= =20 to speak about that codec without confusing some people with G.711.0. =20 So not only would it be an issue for the IANA registration, but for=20 basic human conversation. But even if the number was re-used for a voice codec, this is an IANA=20 registration and the IETF/IANA control the conflict management. I doubt= =20 this will ever be an issue, but if it is one day far into the future,=20 the conflict will be addressed in the IETF and, therefore, not an issue=20 that cannot be easily resolved. >S4.2.3. > >It seems like it would be simpler to state the decoding algorithm as=20 >while loop with an if statement, since it seems like that's how you=20 >would implement it in most normal programming languages. (See, e.g.,=20 >the python snippet below). If you really want a state machine like=20 >representation, it would be nice to at least have a picture of it. > > > > +-----------+ > > | | > > V | > >H1 -> H2 -> H3 -> H4 -> STOP > > ^ | ^ > > | | | > > | +---> H5 ----+ > > | | > > | | > > +-----------+ > > > >def decode_g711_0_payload(payload): > > # H1 > > P =3D 0 > > N =3D len(payload) > > internal =3D [] > > output =3D [] > > while P < N: > > # H2 > > internal =3D packet[ P+1 : P+1+min(321,N-P) ] > > # H3 > > if internal[0] =3D=3D '\x00': > > # H4 > > P +=3D 1 > > else: > > # H5 > > (symbols, Q) =3D g711_0_decode(internal) > > output.extend(symbols) > > K +=3D len(symbols) # =3D=3D M > > P +=3D Q > > return output > > > >MAR: I wrote the prose more or less to mimic the words in the ITU-T=20 >G.711.0 specification. > > > >MAR: However, I would have no issue with a picture or pseudo code. I=20 >completely defer to Paul Jones or Noboru Harada here. > > > Having some form of pseudo code is nice, but I'm not expert in Python,=20 so I had to work about as hard to digest this a I did the prose. I have= =20 no objection to inserting python code, but we should have a python=20 person double-check it. I do have some concern (noted below) with the=20 code clearly aligning with the steps. Python allows for nice=20 "shortcuts" not possible in C, for example. I noted that in the python code that "K" was not defined. I think that=20 should be set to 0 to avoid an error. That said, I don't think K is even= =20 needed in Python, the output string is just concatenated with whatever=20 symbols that are returned (i.e., output.extend(symbols)). Taking this=20 short cut, though, makes it even more challenging to align the logic=20 with the description. Again, not being a python expert, I have to question this line: internal =3D packet[ P+1 : P+1+min(321,N-P) ] First, shouldn't this be "payload", rather than "packet"? The spec says to "read min{320+1, (N-P)} octets into the internal buffer= =20 from the (P+1) octet of the RTP payload". However, I believe that python indexes strings in such a way that, if I=20 have the string hello=3D"Hello" and I want the first two octets, I have = to=20 use the hello[0:2]. That suggests that the array indices to read the=20 data from the payload would need to be [ P : P+min(321,N-P) ]. I think.= =20 Initially, P is zero and the initial read needs to read the first byte,= =20 so I think the first index would be just "P". The second index would be= =20 P + ever how many octets we will read this time. I think. Please=20 correct me if I'm wrong. Michael, I noted that Q is defined as "the number of octets contained in= =20 the G.711.0 frame being processed", but then H5 says this: "The G.711.0 decoder will have consumed some number of packets, Q, in=20 the internal buffer to produce the M G.711 symbols." I think "packets" there should be octets. Paul --------=_MB13B37B4C-1809-4AE8-A36B-7138D8AF1B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Guys,
 
Comments to items left for me:
 

S5.1. 

Is there any risk of G.7110 being defined, and needing= a payload format that would collide with this identifier?

 

MAR: Paul Jones (ITU-T SG16 Rapporteur and= co-author here) can comment =E2=80=A6 but the G-series numbering ran out= a while ago and they began to label things with a =E2=80=9Cdot=E2=80=9D= nomenclature (e.g., G.722.1). Thus I doubt that there will be a G.7110 = standard in the G series for media codecs.

 
I would not say the number space ran out, as the ITU can (and does)= number documents using more than 3 digits.  There are documents like= G.7713.1, for example.  Would there ever be a G.7110?  I cannot= dismiss that as a possibility, but it's highly unlikely the ITU would elec= t to use that number to refer to a voice codec, as it would make it difficu= lt to speak about that codec without confusing some people with G.711.0.&nb= sp; So not only would it be an issue for the IANA registration, but for = basic human conversation.
 
But even if the number was re-used for a voice codec, this is an IANA= registration and the IETF/IANA control the conflict management.  I= doubt this will ever be an issue, but if it is one day far into the future= , the conflict will be addressed in the IETF and, therefore, not an= issue that cannot be easily resolved.
 
 

S4.2.3.

It seems like it would be simpler to state the decodin= g algorithm as while loop with an if statement, since it seems like that's= how you would implement it in most normal programming languages.  (Se= e, e.g., the python snippet below).  If you really want a state machin= e like representation, it would be nice to at least have a picture of it.

 

      +-----------+

      |         =   |

      V         =   |

H1 -> H2 -> H3 -> H4 -> STOP

      ^     |    =        ^

      |     |    =        |

      |     +---> H5 ----+=

      |         =   |

      |         =   |

      +-----------+

 

def decode_g711_0_payload(payload):

  # H1

  P =3D 0

  N =3D len(payload)

  internal =3D []

  output =3D []

  while P < N:

    # H2

    internal =3D packet[ P+1 : P+1+min(321,N= -P) ]

    # H3

    if internal[0] =3D=3D '\x00':=

      # H4

      P +=3D 1

    else:

      # H5

      (symbols, Q) =3D g711_0_decode(in= ternal)

      output.extend(symbols)=

      K +=3D len(symbols) # =3D=3D M

      P +=3D Q

  return output

 

MAR: I wrote the prose more or less to mimic= the words in the ITU-T G.711.0 specification.

 

MAR: However, I would have no issue with = a picture or pseudo code. I completely defer to Paul Jones or Noboru Harada= here.

 

 
Having some form of pseudo code is nice, but I'm not&= nbsp;expert in Python, so I had to work about as hard to digest this= a I did the prose.  I have no objection to inserting python code, = but we should have a python person double-check it.  I do have some= concern (noted below) with the code clearly aligning with the steps. = Python allows for nice "shortcuts" not possible in C, for example.
 
I noted that in the python code that "K" was not defi= ned.  I think that should be set to 0 to avoid an error. That said,= I don't think K is even needed in Python, the output string is just concat= enated with whatever symbols that are returned (i.e., output.extend(sy= mbols)).  Taking this short cut, though, makes it even more challengin= g to align the logic with the description.
 
Again, not being a python expert, I have to question= this line:
 
    internal =3D packet[ P+1 : P+1+min= (321,N-P) ]
 
First, shouldn't this be "payload", rather than "pack= et"?
 
The spec says to "read min{320+1, (N-P)} octets into= the internal buffer from the (P+1) octet of the RTP payload".=
 
However, I believe that python indexes strings in = such a way that, if I have the string hello=3D"Hello" and I want the first= two octets, I have to use the hello[0:2].  That suggests that the = array indices to read the data from the payload would need to be [ P : P+mi= n(321,N-P) ].  I think.  Initially, P is zero and the initial = read needs to read the first byte, so I think the first index would be just= "P".  The second index would be P + ever how many octets we will read= this time.  I think.  Please correct me if I'm wrong.
 
Michael, I noted that Q is defined as "the number = of octets contained in the G.711.0 frame being processed", but then H5 says= this:
 
"The G.711.0 decoder will have consumed some number= of packets, Q, in the internal buffer to produce the M G.711 symbols."
 
I think "packets" there should be octets.
 
Paul
 
--------=_MB13B37B4C-1809-4AE8-A36B-7138D8AF1B42-- From nobody Wed May 28 08:19: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 4DD0B1A00C5 for ; Wed, 28 May 2014 05:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 AzvPvyT3zk4X for ; Wed, 28 May 2014 05:17:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DF11A00A6 for ; Wed, 28 May 2014 05:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35692; q=dns/txt; s=iport; t=1401279442; x=1402489042; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XSxD7zKfSptjsPxVik0kbx5yO3AYZuqt6kqS+lWbuw0=; b=QDIUX+8qaxOySO5Jf4mmSVD1vk3vvmKmdchBpYDmxgR7H3ONGgzrxgUf e4DlnIxHOPlWXCyGcd4DffWziQ4g00WtDv5Ek4thAZB/GDMOvrIrAQ9l1 rJAFLHZIgnx3hYmJWHSjfF4SX10hGOMAjKHzYzoKIGdHj0XtBepKWQAd2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAIrThVOtJV2d/2dsb2JhbABZgkJFUliCa783ARlwFnSCJQEBAQQjBAY+DhACAQgRBAEBCxYHAwICAjAUCQgCBAENBQiIOrFypE0XjiExBgGCdTaBFQStHIM4bIFD X-IronPort-AV: E=Sophos; i="4.98,928,1392163200"; d="scan'208,217"; a="47897557" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 28 May 2014 12:16:59 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4SCGxWN017109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 12:16:59 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.180]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 28 May 2014 07:16:59 -0500 From: "Michael Ramalho (mramalho)" To: "Paul E. Jones" , Richard Barnes , "draft-ietf-payload-g7110@tools.ietf.org" , "payload@ietf.org" Thread-Topic: [payload] AD review of draft-ietf-payload-g7110-02 Thread-Index: AQHPbhz1qBSDf1BA/UWiAAF24aHAWptTrvlggAIuoQCAACFvgA== Date: Wed, 28 May 2014 12:16:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.25] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B9103230DB15Cxmbrcdx12ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/H08jMvMsj_g9yDtdb4rfF-m9x4c X-Mailman-Approved-At: Wed, 28 May 2014 08:19:11 -0700 Cc: "Paul Jones \(paulej\)" Subject: Re: [payload] AD review of draft-ietf-payload-g7110-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: Wed, 28 May 2014 12:17:28 -0000 --_000_D21571530BF9644D9A443D6BD95B9103230DB15Cxmbrcdx12ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmU6ICJUaGUgRy43MTEuMCBkZWNvZGVyIHdpbGwgaGF2ZSBjb25zdW1lZCBzb21lIG51bWJlciBv ZiBwYWNrZXRzLCBRLCBpbiB0aGUgaW50ZXJuYWwgYnVmZmVyIHRvIHByb2R1Y2UgdGhlIE0gRy43 MTEgc3ltYm9scy4g4oCmSSB0aGluayAicGFja2V0cyIgdGhlcmUgc2hvdWxkIGJlIG9jdGV0cy7i gJ0NCg0KWWVzLCB5b3UgYXJlIGNvcnJlY3QgUGF1bC4gR29vZCBjYXRjaCAoSeKAmWQgcmVhZCB0 aGF0IGEgdGhvdXNhbmQgdGltZXMgd2l0aG91dCBub3RpY2luZyBpdCkuDQoNCkFsaS9Sb25pOiBT aG91bGQgSSBtYWtlIGFub3RoZXIgcGFzcyB0aHJvdWdoIHRoZSBkb2N1bWVudCwgb3Igd2FpdCB1 bnRpbCB0aGUgcG9zdC1MQyBlZGl0aW5nIHByb2Nlc3MgdG8gaW5jb3Jwb3JhdGUgdGhlc2UgcmVs YXRpdmVseSBlYXN5IGVkaXRzIChhbGwgYnV0IHRoZSBwb3NzaWJsZSBpbmNsdXNpb24gb2YgdGhl IFB5dGhvbiBjb2RlIGFyZSBlYXN5L3RyaXZpYWwpPw0KDQpJIHBlcnNvbmFsbHkgZG9u4oCZdCB0 aGluayB0aGUgUHl0aG9uIGNvZGUgaXMgZXNzZW50aWFsLCBiZWNhdXNlIHRoZSBwcm9zZSBpbiB0 aGUgZHJhZnQgbWltaWNzIGV4aXN0aW5nIHJlZmVyZW5jZSBjb2RlIGluIHRoZSBJVFUtVCBzdGFu ZGFyZCAoaWYgc29tZW9uZSB3YW50ZWQgdG8gbG9vayBhdCBjb2RlIHRoZXkgY291bGQgbG9vayBh dCByZWFsIG9wZXJhdGlvbmFsIGNvZGUgdGhlcmUpLiBCdXQgSSB3b3VsZG7igJl0IG9iamVjdCB0 byBpdCBiZWluZyBpbmNsdWRlZCBpbiBhbiBBcHBlbmRpeCBvZiB0aGUgcGF5bG9hZCBmb3JtYXQg ZHJhZnQgZWl0aGVyICh3aGljaCBpcyB3aGVyZSBJIHRoaW5rIGl0IHdvdWxkIG1vc3QgbG9naWNh bGx5IGJlbG9uZyBpZiB3ZSBkZXNpcmUgdG8gaW5jbHVkZSBpdCkuDQoNCk1pY2hhZWwgUmFtYWxo bw0KDQpGcm9tOiBQYXVsIEUuIEpvbmVzIFttYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0K U2VudDogV2VkbmVzZGF5LCBNYXkgMjgsIDIwMTQgMTowOSBBTQ0KVG86IE1pY2hhZWwgUmFtYWxo byAobXJhbWFsaG8pOyBSaWNoYXJkIEJhcm5lczsgZHJhZnQtaWV0Zi1wYXlsb2FkLWc3MTEwQHRv b2xzLmlldGYub3JnOyBwYXlsb2FkQGlldGYub3JnDQpDYzogUGF1bCBKb25lcyAocGF1bGVqKTsg aGFyYWRhLm5vYm9ydUBsYWIubnR0LmNvLmpwOyBNaWFvbGVpIChsZWkubWlhb0BodWF3ZWkuY29t KTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IEFsaSBDLiBCZWdlbiAoYWJl Z2VuKTsgcm9uaS5ldmVuQG1haWwwMS5odWF3ZWkuY29tOyBSb25pIEV2ZW4NClN1YmplY3Q6IFJl OiBbcGF5bG9hZF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1nNzExMC0wMg0KDQpH dXlzLA0KDQpDb21tZW50cyB0byBpdGVtcyBsZWZ0IGZvciBtZToNCg0KUzUuMS4NCklzIHRoZXJl IGFueSByaXNrIG9mIEcuNzExMCBiZWluZyBkZWZpbmVkLCBhbmQgbmVlZGluZyBhIHBheWxvYWQg Zm9ybWF0IHRoYXQgd291bGQgY29sbGlkZSB3aXRoIHRoaXMgaWRlbnRpZmllcj8NCg0KTUFSOiBQ YXVsIEpvbmVzIChJVFUtVCBTRzE2IFJhcHBvcnRldXIgYW5kIGNvLWF1dGhvciBoZXJlKSBjYW4g Y29tbWVudCDigKYgYnV0IHRoZSBHLXNlcmllcyBudW1iZXJpbmcgcmFuIG91dCBhIHdoaWxlIGFn byBhbmQgdGhleSBiZWdhbiB0byBsYWJlbCB0aGluZ3Mgd2l0aCBhIOKAnGRvdOKAnSBub21lbmNs YXR1cmUgKGUuZy4sIEcuNzIyLjEpLiBUaHVzIEkgZG91YnQgdGhhdCB0aGVyZSB3aWxsIGJlIGEg Ry43MTEwIHN0YW5kYXJkIGluIHRoZSBHIHNlcmllcyBmb3IgbWVkaWEgY29kZWNzLg0KDQpJIHdv dWxkIG5vdCBzYXkgdGhlIG51bWJlciBzcGFjZSByYW4gb3V0LCBhcyB0aGUgSVRVIGNhbiAoYW5k IGRvZXMpIG51bWJlciBkb2N1bWVudHMgdXNpbmcgbW9yZSB0aGFuIDMgZGlnaXRzLiAgVGhlcmUg YXJlIGRvY3VtZW50cyBsaWtlIEcuNzcxMy4xLCBmb3IgZXhhbXBsZS4gIFdvdWxkIHRoZXJlIGV2 ZXIgYmUgYSBHLjcxMTA/ICBJIGNhbm5vdCBkaXNtaXNzIHRoYXQgYXMgYSBwb3NzaWJpbGl0eSwg YnV0IGl0J3MgaGlnaGx5IHVubGlrZWx5IHRoZSBJVFUgd291bGQgZWxlY3QgdG8gdXNlIHRoYXQg bnVtYmVyIHRvIHJlZmVyIHRvIGEgdm9pY2UgY29kZWMsIGFzIGl0IHdvdWxkIG1ha2UgaXQgZGlm ZmljdWx0IHRvIHNwZWFrIGFib3V0IHRoYXQgY29kZWMgd2l0aG91dCBjb25mdXNpbmcgc29tZSBw ZW9wbGUgd2l0aCBHLjcxMS4wLiAgU28gbm90IG9ubHkgd291bGQgaXQgYmUgYW4gaXNzdWUgZm9y IHRoZSBJQU5BIHJlZ2lzdHJhdGlvbiwgYnV0IGZvciBiYXNpYyBodW1hbiBjb252ZXJzYXRpb24u DQoNCkJ1dCBldmVuIGlmIHRoZSBudW1iZXIgd2FzIHJlLXVzZWQgZm9yIGEgdm9pY2UgY29kZWMs IHRoaXMgaXMgYW4gSUFOQSByZWdpc3RyYXRpb24gYW5kIHRoZSBJRVRGL0lBTkEgY29udHJvbCB0 aGUgY29uZmxpY3QgbWFuYWdlbWVudC4gIEkgZG91YnQgdGhpcyB3aWxsIGV2ZXIgYmUgYW4gaXNz dWUsIGJ1dCBpZiBpdCBpcyBvbmUgZGF5IGZhciBpbnRvIHRoZSBmdXR1cmUsIHRoZSBjb25mbGlj dCB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgSUVURiBhbmQsIHRoZXJlZm9yZSwgbm90IGFuIGlz c3VlIHRoYXQgY2Fubm90IGJlIGVhc2lseSByZXNvbHZlZC4NCg0KDQpTNC4yLjMuDQpJdCBzZWVt cyBsaWtlIGl0IHdvdWxkIGJlIHNpbXBsZXIgdG8gc3RhdGUgdGhlIGRlY29kaW5nIGFsZ29yaXRo bSBhcyB3aGlsZSBsb29wIHdpdGggYW4gaWYgc3RhdGVtZW50LCBzaW5jZSBpdCBzZWVtcyBsaWtl IHRoYXQncyBob3cgeW91IHdvdWxkIGltcGxlbWVudCBpdCBpbiBtb3N0IG5vcm1hbCBwcm9ncmFt bWluZyBsYW5ndWFnZXMuICAoU2VlLCBlLmcuLCB0aGUgcHl0aG9uIHNuaXBwZXQgYmVsb3cpLiAg SWYgeW91IHJlYWxseSB3YW50IGEgc3RhdGUgbWFjaGluZSBsaWtlIHJlcHJlc2VudGF0aW9uLCBp dCB3b3VsZCBiZSBuaWNlIHRvIGF0IGxlYXN0IGhhdmUgYSBwaWN0dXJlIG9mIGl0Lg0KDQogICAg ICArLS0tLS0tLS0tLS0rDQogICAgICB8ICAgICAgICAgICB8DQogICAgICBWICAgICAgICAgICB8 DQpIMSAtPiBIMiAtPiBIMyAtPiBINCAtPiBTVE9QDQogICAgICBeICAgICB8ICAgICAgICAgICAg Xg0KICAgICAgfCAgICAgfCAgICAgICAgICAgIHwNCiAgICAgIHwgICAgICstLS0+IEg1IC0tLS0r DQogICAgICB8ICAgICAgICAgICB8DQogICAgICB8ICAgICAgICAgICB8DQogICAgICArLS0tLS0t LS0tLS0rDQoNCmRlZiBkZWNvZGVfZzcxMV8wX3BheWxvYWQocGF5bG9hZCk6DQogICMgSDENCiAg UCA9IDANCiAgTiA9IGxlbihwYXlsb2FkKQ0KICBpbnRlcm5hbCA9IFtdDQogIG91dHB1dCA9IFtd DQogIHdoaWxlIFAgPCBOOg0KICAgICMgSDINCiAgICBpbnRlcm5hbCA9IHBhY2tldFsgUCsxIDog UCsxK21pbigzMjEsTi1QKSBdDQogICAgIyBIMw0KICAgIGlmIGludGVybmFsWzBdID09ICdceDAw JzoNCiAgICAgICMgSDQNCiAgICAgIFAgKz0gMQ0KICAgIGVsc2U6DQogICAgICAjIEg1DQogICAg ICAoc3ltYm9scywgUSkgPSBnNzExXzBfZGVjb2RlKGludGVybmFsKQ0KICAgICAgb3V0cHV0LmV4 dGVuZChzeW1ib2xzKQ0KICAgICAgSyArPSBsZW4oc3ltYm9scykgIyA9PSBNDQogICAgICBQICs9 IFENCiAgcmV0dXJuIG91dHB1dA0KDQpNQVI6IEkgd3JvdGUgdGhlIHByb3NlIG1vcmUgb3IgbGVz cyB0byBtaW1pYyB0aGUgd29yZHMgaW4gdGhlIElUVS1UIEcuNzExLjAgc3BlY2lmaWNhdGlvbi4N Cg0KTUFSOiBIb3dldmVyLCBJIHdvdWxkIGhhdmUgbm8gaXNzdWUgd2l0aCBhIHBpY3R1cmUgb3Ig cHNldWRvIGNvZGUuIEkgY29tcGxldGVseSBkZWZlciB0byBQYXVsIEpvbmVzIG9yIE5vYm9ydSBI YXJhZGEgaGVyZS4NCg0KDQpIYXZpbmcgc29tZSBmb3JtIG9mIHBzZXVkbyBjb2RlIGlzIG5pY2Us IGJ1dCBJJ20gbm90ZXhwZXJ0IGluIFB5dGhvbiwgc28gSSBoYWQgdG8gd29yayBhYm91dCBhcyBo YXJkIHRvIGRpZ2VzdCB0aGlzIGEgSSBkaWQgdGhlIHByb3NlLiAgSSBoYXZlIG5vIG9iamVjdGlv biB0byBpbnNlcnRpbmcgcHl0aG9uIGNvZGUsIGJ1dCB3ZSBzaG91bGQgaGF2ZSBhIHB5dGhvbiBw ZXJzb24gZG91YmxlLWNoZWNrIGl0LiAgSSBkbyBoYXZlIHNvbWUgY29uY2VybiAobm90ZWQgYmVs b3cpIHdpdGggdGhlIGNvZGUgY2xlYXJseSBhbGlnbmluZyB3aXRoIHRoZSBzdGVwcy4gIFB5dGhv biBhbGxvd3MgZm9yIG5pY2UgInNob3J0Y3V0cyIgbm90IHBvc3NpYmxlIGluIEMsIGZvciBleGFt cGxlLg0KDQpJIG5vdGVkIHRoYXQgaW4gdGhlIHB5dGhvbiBjb2RlIHRoYXQgIksiIHdhcyBub3Qg ZGVmaW5lZC4gSSB0aGluayB0aGF0IHNob3VsZCBiZSBzZXQgdG8gMCB0byBhdm9pZCBhbiBlcnJv ci4gVGhhdCBzYWlkLCBJIGRvbid0IHRoaW5rIEsgaXMgZXZlbiBuZWVkZWQgaW4gUHl0aG9uLCB0 aGUgb3V0cHV0IHN0cmluZyBpcyBqdXN0IGNvbmNhdGVuYXRlZCB3aXRoIHdoYXRldmVyIHN5bWJv bHMgdGhhdCBhcmUgcmV0dXJuZWQgKGkuZS4sIG91dHB1dC5leHRlbmQoc3ltYm9scykpLiAgVGFr aW5nIHRoaXMgc2hvcnQgY3V0LCB0aG91Z2gsIG1ha2VzIGl0IGV2ZW4gbW9yZSBjaGFsbGVuZ2lu ZyB0byBhbGlnbiB0aGUgbG9naWMgd2l0aCB0aGUgZGVzY3JpcHRpb24uDQoNCkFnYWluLCBub3Qg YmVpbmcgYSBweXRob24gZXhwZXJ0LCBJIGhhdmUgdG8gcXVlc3Rpb24gdGhpcyBsaW5lOg0KDQog ICBpbnRlcm5hbCA9IHBhY2tldFsgUCsxIDogUCsxK21pbigzMjEsTi1QKSBdDQoNCg0KRmlyc3Qs IHNob3VsZG4ndCB0aGlzIGJlICJwYXlsb2FkIiwgcmF0aGVyIHRoYW4gInBhY2tldCI/DQoNClRo ZSBzcGVjIHNheXMgdG8gInJlYWQgbWluezMyMCsxLCAoTi1QKX0gb2N0ZXRzIGludG8gdGhlIGlu dGVybmFsIGJ1ZmZlciBmcm9tIHRoZSAoUCsxKSBvY3RldCBvZiB0aGUgUlRQIHBheWxvYWQiLg0K DQpIb3dldmVyLCBJIGJlbGlldmUgdGhhdCBweXRob24gaW5kZXhlcyBzdHJpbmdzIGluIHN1Y2gg YSB3YXkgdGhhdCwgaWYgSSBoYXZlIHRoZSBzdHJpbmcgaGVsbG89IkhlbGxvIiBhbmQgSSB3YW50 IHRoZSBmaXJzdCB0d28gb2N0ZXRzLCBJIGhhdmUgdG8gdXNlIHRoZSBoZWxsb1swOjJdLiBUaGF0 IHN1Z2dlc3RzIHRoYXQgdGhlIGFycmF5IGluZGljZXMgdG8gcmVhZCB0aGUgZGF0YSBmcm9tIHRo ZSBwYXlsb2FkIHdvdWxkIG5lZWQgdG8gYmUgWyBQIDogUCttaW4oMzIxLE4tUCkgXS4gIEkgdGhp bmsuICBJbml0aWFsbHksIFAgaXMgemVybyBhbmQgdGhlIGluaXRpYWwgcmVhZCBuZWVkcyB0byBy ZWFkIHRoZSBmaXJzdCBieXRlLCBzbyBJIHRoaW5rIHRoZSBmaXJzdCBpbmRleCB3b3VsZCBiZSBq dXN0ICJQIi4gIFRoZSBzZWNvbmQgaW5kZXggd291bGQgYmUgUCArIGV2ZXIgaG93IG1hbnkgb2N0 ZXRzIHdlIHdpbGwgcmVhZCB0aGlzIHRpbWUuICBJIHRoaW5rLiAgUGxlYXNlIGNvcnJlY3QgbWUg aWYgSSdtIHdyb25nLg0KDQpNaWNoYWVsLCBJIG5vdGVkIHRoYXQgUSBpcyBkZWZpbmVkIGFzICJ0 aGUgbnVtYmVyIG9mIG9jdGV0cyBjb250YWluZWQgaW4gdGhlIEcuNzExLjAgZnJhbWUgYmVpbmcg cHJvY2Vzc2VkIiwgYnV0IHRoZW4gSDUgc2F5cyB0aGlzOg0KDQoiVGhlIEcuNzExLjAgZGVjb2Rl ciB3aWxsIGhhdmUgY29uc3VtZWQgc29tZSBudW1iZXIgb2YgcGFja2V0cywgUSwgaW4gdGhlIGlu dGVybmFsIGJ1ZmZlciB0byBwcm9kdWNlIHRoZSBNIEcuNzExIHN5bWJvbHMuIg0KDQpJIHRoaW5r ICJwYWNrZXRzIiB0aGVyZSBzaG91bGQgYmUgb2N0ZXRzLg0KDQpQYXVsDQoNCg== --_000_D21571530BF9644D9A443D6BD95B9103230DB15Cxmbrcdx12ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5tc29j aHBkZWZhdWx0LCBsaS5tc29jaHBkZWZhdWx0LCBkaXYubXNvY2hwZGVmYXVsdA0KCXttc28tc3R5 bGUtbmFtZTptc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLmVtYWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxl MTc7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzAwMDAwMCIgdmxpbms9 IiMwMDAwMDAiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZToNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7VGhlIEcu NzExLjAgZGVjb2RlciB3aWxsIGhhdmUgY29uc3VtZWQgc29tZSBudW1iZXIgb2YgcGFja2V0cywg USwgaW4gdGhlIGludGVybmFsIGJ1ZmZlciB0byBwcm9kdWNlIHRoZSBNIEcuNzExIHN5bWJvbHMu IOKApkkgdGhpbmsgJnF1b3Q7cGFja2V0cyZxdW90OyB0aGVyZSBzaG91bGQgYmUgb2N0ZXRzLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5ZZXMsIHlvdSBhcmUgY29ycmVjdCBQYXVsLiBHb29kIGNhdGNoIChJ4oCZZCByZWFkIHRo YXQgYSB0aG91c2FuZCB0aW1lcyB3aXRob3V0IG5vdGljaW5nIGl0KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsaS9S b25pOiBTaG91bGQgSSBtYWtlIGFub3RoZXIgcGFzcyB0aHJvdWdoIHRoZSBkb2N1bWVudCwgb3Ig d2FpdCB1bnRpbCB0aGUgcG9zdC1MQyBlZGl0aW5nIHByb2Nlc3MgdG8gaW5jb3Jwb3JhdGUgdGhl c2UgcmVsYXRpdmVseSBlYXN5IGVkaXRzIChhbGwgYnV0IHRoZQ0KIHBvc3NpYmxlIGluY2x1c2lv biBvZiB0aGUgUHl0aG9uIGNvZGUgYXJlIGVhc3kvdHJpdmlhbCk/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHBlcnNv bmFsbHkgZG9u4oCZdCB0aGluayB0aGUgUHl0aG9uIGNvZGUgaXMgZXNzZW50aWFsLCBiZWNhdXNl IHRoZSBwcm9zZSBpbiB0aGUgZHJhZnQgbWltaWNzIGV4aXN0aW5nIHJlZmVyZW5jZSBjb2RlIGlu IHRoZSBJVFUtVCBzdGFuZGFyZCAoaWYgc29tZW9uZSB3YW50ZWQNCiB0byBsb29rIGF0IGNvZGUg dGhleSBjb3VsZCBsb29rIGF0IHJlYWwgb3BlcmF0aW9uYWwgY29kZSB0aGVyZSkuIEJ1dCBJIHdv dWxkbuKAmXQgb2JqZWN0IHRvIGl0IGJlaW5nIGluY2x1ZGVkIGluIGFuIEFwcGVuZGl4IG9mIHRo ZSBwYXlsb2FkIGZvcm1hdCBkcmFmdCBlaXRoZXIgKHdoaWNoIGlzIHdoZXJlIEkgdGhpbmsgaXQg d291bGQgbW9zdCBsb2dpY2FsbHkgYmVsb25nIGlmIHdlIGRlc2lyZSB0byBpbmNsdWRlIGl0KS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk1pY2hhZWwgUmFtYWxobzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGF1bCBFLiBKb25lcyBbbWFp bHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IE1heSAyOCwgMjAxNCAxOjA5IEFNPGJyPg0KPGI+VG86PC9iPiBNaWNoYWVsIFJhbWFsaG8gKG1y YW1hbGhvKTsgUmljaGFyZCBCYXJuZXM7IGRyYWZ0LWlldGYtcGF5bG9hZC1nNzExMEB0b29scy5p ZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gUGF1bCBKb25lcyAocGF1 bGVqKTsgaGFyYWRhLm5vYm9ydUBsYWIubnR0LmNvLmpwOyBNaWFvbGVpIChsZWkubWlhb0BodWF3 ZWkuY29tKTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IEFsaSBDLiBCZWdl biAoYWJlZ2VuKTsgcm9uaS5ldmVuQG1haWwwMS5odWF3ZWkuY29tOyBSb25pIEV2ZW48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXlsb2FkXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYXls b2FkLWc3MTEwLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R3V5cyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Q29tbWVudHMgdG8gaXRlbXMgbGVmdCBmb3IgbWU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IjNhOTQx YWU3NzczNDQ2NzVhNWRmZDViOTMzNjdhNDNiIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g OC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlM1LjEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyB0aGVyZSBhbnkgcmlzayBvZiBHLjcxMTAgYmVpbmcgZGVmaW5lZCwgYW5k IG5lZWRpbmcgYSBwYXlsb2FkIGZvcm1hdCB0aGF0IHdvdWxkIGNvbGxpZGUgd2l0aCB0aGlzIGlk ZW50aWZpZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1BUjogUGF1bCBKb25lcyAoSVRVLVQgU0cxNiBSYXBwb3J0ZXVyIGFuZCBj by1hdXRob3IgaGVyZSkgY2FuIGNvbW1lbnQg4oCmIGJ1dCB0aGUgRy1zZXJpZXMgbnVtYmVyaW5n IHJhbiBvdXQgYSB3aGlsZSBhZ28gYW5kIHRoZXkgYmVnYW4gdG8gbGFiZWwgdGhpbmdzIHdpdGgN CiBhIOKAnGRvdOKAnSBub21lbmNsYXR1cmUgKGUuZy4sIEcuNzIyLjEpLiBUaHVzIEkgZG91YnQg dGhhdCB0aGVyZSB3aWxsIGJlIGEgRy43MTEwIHN0YW5kYXJkIGluIHRoZSBHIHNlcmllcyBmb3Ig bWVkaWEgY29kZWNzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgd291bGQg bm90IHNheSB0aGUgbnVtYmVyIHNwYWNlIHJhbiBvdXQsIGFzIHRoZSBJVFUgY2FuIChhbmQgZG9l cykgbnVtYmVyIGRvY3VtZW50cyB1c2luZyBtb3JlIHRoYW4gMyBkaWdpdHMuJm5ic3A7IFRoZXJl IGFyZSBkb2N1bWVudHMgbGlrZSBHLjc3MTMuMSwgZm9yIGV4YW1wbGUuJm5ic3A7IFdvdWxkIHRo ZXJlDQogZXZlciBiZSBhIEcuNzExMD8mbmJzcDsgSSBjYW5ub3QgZGlzbWlzcyB0aGF0IGFzIGEg cG9zc2liaWxpdHksIGJ1dCBpdCdzIGhpZ2hseSB1bmxpa2VseSB0aGUgSVRVIHdvdWxkIGVsZWN0 IHRvIHVzZSB0aGF0IG51bWJlciB0byByZWZlciB0byBhIHZvaWNlIGNvZGVjLCBhcyBpdCB3b3Vs ZCBtYWtlIGl0IGRpZmZpY3VsdCB0byBzcGVhayBhYm91dCB0aGF0IGNvZGVjIHdpdGhvdXQgY29u ZnVzaW5nIHNvbWUgcGVvcGxlIHdpdGggRy43MTEuMC4mbmJzcDsgU28gbm90DQogb25seSB3b3Vs ZCBpdCBiZSBhbiBpc3N1ZSBmb3IgdGhlIElBTkEgcmVnaXN0cmF0aW9uLCBidXQgZm9yIGJhc2lj IGh1bWFuIGNvbnZlcnNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnV0IGV2ZW4gaWYgdGhlIG51bWJlciB3 YXMgcmUtdXNlZCBmb3IgYSB2b2ljZSBjb2RlYywgdGhpcyBpcyBhbiBJQU5BIHJlZ2lzdHJhdGlv biBhbmQgdGhlIElFVEYvSUFOQSBjb250cm9sIHRoZSBjb25mbGljdCBtYW5hZ2VtZW50LiZuYnNw OyBJIGRvdWJ0IHRoaXMgd2lsbCBldmVyIGJlIGFuIGlzc3VlLA0KIGJ1dCBpZiBpdCBpcyBvbmUg ZGF5IGZhciBpbnRvIHRoZSBmdXR1cmUsJm5ic3A7dGhlIGNvbmZsaWN0IHdpbGwgYmUgYWRkcmVz c2VkIGluIHRoZSBJRVRGIGFuZCwgdGhlcmVmb3JlLCBub3QgYW4gaXNzdWUgdGhhdCBjYW5ub3Qg YmUgZWFzaWx5IHJlc29sdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxlZnQ6 My43NXB0O21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlM0LjIuMy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBz ZWVtcyBsaWtlIGl0IHdvdWxkIGJlIHNpbXBsZXIgdG8gc3RhdGUgdGhlIGRlY29kaW5nIGFsZ29y aXRobSBhcyB3aGlsZSBsb29wIHdpdGggYW4gaWYgc3RhdGVtZW50LCBzaW5jZSBpdCBzZWVtcyBs aWtlIHRoYXQncyBob3cgeW91IHdvdWxkIGltcGxlbWVudCBpdCBpbiBtb3N0IG5vcm1hbCBwcm9n cmFtbWluZyBsYW5ndWFnZXMuICZuYnNwOyhTZWUsIGUuZy4sIHRoZSBweXRob24gc25pcHBldCBi ZWxvdykuICZuYnNwO0lmDQogeW91IHJlYWxseSB3YW50IGEgc3RhdGUgbWFjaGluZSBsaWtlIHJl cHJlc2VudGF0aW9uLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGF0IGxlYXN0IGhhdmUgYSBwaWN0dXJl IG9mIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBWICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SDEgLSZndDsgSDIgLSZndDsg SDMgLSZndDsgSDQgLSZndDsgU1RPUDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgXiAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtePG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLSZndDsgSDUgLS0t LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZWYgZGVjb2RlX2c3MTFfMF9w YXlsb2FkKHBheWxvYWQpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICMgSDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBQID0gMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IE4gPSBsZW4ocGF5bG9hZCk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbnRl cm5hbCA9IFtdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgb3V0cHV0ID0gW108bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB3aGlsZSBQICZsdDsgTjo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgIyBIMjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBpbnRlcm5hbCA9IHBhY2tldFsgUCYjNDM7MSA6IFAmIzQzOzEmIzQzO21pbigzMjEs Ti1QKSBdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICMgSDM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgaWYgaW50ZXJuYWxbMF0gPT0gJ1x4MDAnOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgIyBINDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUCAmIzQzOz0gMTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBl bHNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgIyBINTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgKHN5bWJvbHMsIFEpID0g ZzcxMV8wX2RlY29kZShpbnRlcm5hbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG91dHB1dC5leHRlbmQoc3lt Ym9scyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IEsgJiM0Mzs9IGxlbihzeW1ib2xzKSAjID09IE08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7IFAgJiM0Mzs9IFE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyByZXR1cm4gb3V0cHV0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1BUjogSSB3cm90ZSB0aGUg cHJvc2UgbW9yZSBvciBsZXNzIHRvIG1pbWljIHRoZSB3b3JkcyBpbiB0aGUgSVRVLVQgRy43MTEu MCBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUFSOiBIb3dldmVyLCBJIHdvdWxkIGhhdmUgbm8g aXNzdWUgd2l0aCBhIHBpY3R1cmUgb3IgcHNldWRvIGNvZGUuIEkgY29tcGxldGVseSBkZWZlciB0 byBQYXVsIEpvbmVzIG9yIE5vYm9ydSBIYXJhZGEgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGF2aW5n IHNvbWUgZm9ybSBvZiBwc2V1ZG8gY29kZSBpcyBuaWNlLCBidXQgSSdtIG5vdGV4cGVydCBpbiZu YnNwO1B5dGhvbiwgc28gSSBoYWQgdG8gd29yayBhYm91dCBhcyBoYXJkIHRvIGRpZ2VzdCB0aGlz IGEgSSBkaWQgdGhlIHByb3NlLiZuYnNwOyBJIGhhdmUgbm8gb2JqZWN0aW9uDQogdG8gaW5zZXJ0 aW5nIHB5dGhvbiBjb2RlLCBidXQgd2Ugc2hvdWxkIGhhdmUgYSBweXRob24gcGVyc29uIGRvdWJs ZS1jaGVjayBpdC4mbmJzcDsgSSBkbyBoYXZlIHNvbWUgY29uY2VybiAobm90ZWQgYmVsb3cpIHdp dGggdGhlIGNvZGUgY2xlYXJseSBhbGlnbmluZyB3aXRoIHRoZSBzdGVwcy4mbmJzcDsgUHl0aG9u IGFsbG93cyBmb3IgbmljZSAmcXVvdDtzaG9ydGN1dHMmcXVvdDsgbm90IHBvc3NpYmxlIGluIEMs IGZvciBleGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBub3RlZCB0aGF0IGluIHRoZSBweXRob24gY29kZSB0aGF0ICZx dW90O0smcXVvdDsgd2FzIG5vdCBkZWZpbmVkLiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIHNldCB0 byAwIHRvIGF2b2lkIGFuIGVycm9yLiBUaGF0IHNhaWQsIEkgZG9uJ3QgdGhpbmsgSyBpcyBldmVu IG5lZWRlZCBpbiBQeXRob24sDQogdGhlIG91dHB1dCBzdHJpbmcgaXMganVzdCBjb25jYXRlbmF0 ZWQgd2l0aCB3aGF0ZXZlciBzeW1ib2xzJm5ic3A7dGhhdCBhcmUgcmV0dXJuZWQgKGkuZS4sIG91 dHB1dC5leHRlbmQoc3ltYm9scykpLiZuYnNwOyBUYWtpbmcgdGhpcyBzaG9ydCBjdXQsIHRob3Vn aCwgbWFrZXMgaXQgZXZlbiBtb3JlIGNoYWxsZW5naW5nIHRvIGFsaWduIHRoZSBsb2dpYyB3aXRo IHRoZSBkZXNjcmlwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFnYWluLCBub3QgYmVpbmcgYSBweXRob24gZXhwZXJ0LCBJ IGhhdmUgdG8gcXVlc3Rpb24gdGhpcyBsaW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGludGVybmFsID0g cGFja2V0WyBQJiM0MzsxIDogUCYjNDM7MSYjNDM7bWluKDMyMSxOLVApIF08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0LCBzaG91bGRuJ3QgdGhp cyBiZSAmcXVvdDtwYXlsb2FkJnF1b3Q7LCByYXRoZXIgdGhhbiAmcXVvdDtwYWNrZXQmcXVvdDs/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgc3BlYyBzYXlzIHRvICZxdW90O3JlYWQgbWluezMyMCYjNDM7MSwgKE4tUCl9IG9j dGV0cyBpbnRvIHRoZSBpbnRlcm5hbCBidWZmZXIgZnJvbSB0aGUgKFAmIzQzOzEpIG9jdGV0IG9m IHRoZSBSVFAgcGF5bG9hZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0IHB5dGhv biBpbmRleGVzIHN0cmluZ3MgaW4gc3VjaCBhIHdheSB0aGF0LCBpZiBJIGhhdmUgdGhlIHN0cmlu ZyBoZWxsbz0mcXVvdDtIZWxsbyZxdW90OyBhbmQgSSB3YW50IHRoZSBmaXJzdCB0d28gb2N0ZXRz LCBJIGhhdmUgdG8gdXNlIHRoZSBoZWxsb1swOjJdLg0KIFRoYXQgc3VnZ2VzdHMgdGhhdCB0aGUg YXJyYXkgaW5kaWNlcyB0byByZWFkIHRoZSBkYXRhIGZyb20gdGhlIHBheWxvYWQgd291bGQgbmVl ZCB0byBiZSBbIFAgOiBQJiM0MzttaW4oMzIxLE4tUCkgXS4mbmJzcDsgSSB0aGluay4mbmJzcDsg SW5pdGlhbGx5LCBQIGlzIHplcm8gYW5kIHRoZSBpbml0aWFsIHJlYWQgbmVlZHMgdG8gcmVhZCB0 aGUgZmlyc3QgYnl0ZSwgc28gSSB0aGluayB0aGUgZmlyc3QgaW5kZXggd291bGQgYmUganVzdCAm cXVvdDtQJnF1b3Q7LiZuYnNwOyBUaGUgc2Vjb25kIGluZGV4DQogd291bGQgYmUgUCAmIzQzOyBl dmVyIGhvdyBtYW55IG9jdGV0cyB3ZSB3aWxsIHJlYWQgdGhpcyB0aW1lLiZuYnNwOyBJIHRoaW5r LiZuYnNwOyBQbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsLCBJIG5v dGVkIHRoYXQgUSBpcyBkZWZpbmVkIGFzICZxdW90O3RoZSBudW1iZXIgb2Ygb2N0ZXRzIGNvbnRh aW5lZCBpbiB0aGUgRy43MTEuMCBmcmFtZSBiZWluZyBwcm9jZXNzZWQmcXVvdDssIGJ1dCB0aGVu IEg1IHNheXMgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZxdW90O1RoZSBHLjcxMS4wIGRlY29kZXIgd2lsbCBoYXZlIGNv bnN1bWVkIHNvbWUgbnVtYmVyIG9mIHBhY2tldHMsIFEsIGluIHRoZSBpbnRlcm5hbCBidWZmZXIg dG8gcHJvZHVjZSB0aGUgTSBHLjcxMSBzeW1ib2xzLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayAmcXVvdDtw YWNrZXRzJnF1b3Q7IHRoZXJlIHNob3VsZCBiZSBvY3RldHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D21571530BF9644D9A443D6BD95B9103230DB15Cxmbrcdx12ciscoc_-- From nobody Wed May 28 10:08: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 12D7F1A045D for ; Wed, 28 May 2014 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 ioDSP49ZIg4t for ; Wed, 28 May 2014 10:08:47 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id B2E7B1A0A08 for ; Wed, 28 May 2014 10:08:47 -0700 (PDT) X-ASG-Debug-ID: 1401296923-03d25078ae468110001-U2jSCT Received: from host101.olm1.com (host101.olm1.com [72.236.255.11]) by cuda.olm1.com with ESMTP id zJpfQuPcBk7ZLkB0 for ; Wed, 28 May 2014 13:08:43 -0400 (EDT) X-Barracuda-Envelope-From: Victor.Demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.11 Received: from av-engine.localhost (host101.olm1.com [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 69DF66970585; Wed, 28 May 2014 13:08:44 -0400 (EDT) Received: 5386181c77dcb92887c6d3d92b729a Received: from host101.olm1.com (unknown [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 2392A6970576; Wed, 28 May 2014 13:08:44 -0400 (EDT) Received: from dev1PC (unknown [72.43.202.98]) by host101.olm1.com (Postfix) with ESMTP; Wed, 28 May 2014 13:08:44 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: References: <117301cf7a85$5a2e5a60$0e8b0f20$@Demjanenko@vocal.com> In-Reply-To: <117301cf7a85$5a2e5a60$0e8b0f20$@Demjanenko@vocal.com> Date: Wed, 28 May 2014 13:08:13 -0400 X-ASG-Orig-Subj: draft-demjanenko-payload-melpe-00.txt Message-ID: <119f01cf7a97$6915f210$3b41d630$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11A0_01CF7A75.E2045210" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac96hVnUe9tGjKyhSxW7dKwOZZ5hrwAEfnSg Content-Language: en-us X-Barracuda-Connect: host101.olm1.com[72.236.255.11] X-Barracuda-Start-Time: 1401296923 X-Barracuda-URL: http://72.236.255.32:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6186 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/payload/kXdblIHJMARit5tmY_BLmbBWzzY Subject: [payload] draft-demjanenko-payload-melpe-00.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: Wed, 28 May 2014 17:08:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_11A0_01CF7A75.E2045210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello everyone. I'd like to introduce myself and make you aware of our recent draft of a payload specification. My company, VOCAL Technologies, has been in the business of licensing software and algorithms for communications system for the past 25 years. We have implemented all sorts of telephone line standards (including data, fax and voice) and now all sorts of VoIP protocols (including various common protocols and speech coders). One speech coder that we have used quite extensively over the past 10 years is MELP/MELPe. These were initially developed by DOD/NSA and later issued as a world-wide standard by NATO as STANAG 4591. This speech coder operates at three different rates, 2400, 1200 and 600bps. The primary use was for encrypted radio channels. We have had customers use MELP/MELPe for all sorts of applications and we have bridged traditional VOIP with MELP. After packaging MELP in RTP for several customers, we have realized that we need to promote a standardized RTP payload for this speech coder. This draft is an effort that we believe should result in an RFC to specify the RTP payload format and SDP parameters for the MELPe speech coder. Thank you for your time and comments. (BTW, we have audio examples of MELP encoded speech at http://www.vocal.com/audio-examples/other-speech-coder-audio-examples/. I hope to not be seen as self promoting but rather enlightening. Since many people may not be aware of MELP, I wanted to briefly convey the context and potential applications.) Victor Demjanenko, Ph.D. Associate VOCAL Technologies, Ltd. 520 Lee Entrance Amherst, NY 14228 Victor.Demjanenko@vocal.com http://www.vocal.com Tel: +1-716-688-4675 Fax: +1-716-639-0713 Confidential Information The information contained in this electronic mail transmission is confidential and intended to be sent only to the stated recipient of the transmission. It may therefore be protected from unauthorized use or dissemination. If you are not the intended recipient or the intended recipient's agent, you are hereby notified that any review, use, dissemination, distribution or copying of this communication is strictly prohibited. You are also asked to notify us immediately by telephone and to delete this transmission with any attachments and destroy all copies in any form. Thank you in advance for your cooperation. ------=_NextPart_000_11A0_01CF7A75.E2045210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = everyone.

 

I’d like to introduce myself and make you aware = of our recent draft of a payload specification.

 

My company, = VOCAL Technologies, has been in the business of licensing software and = algorithms for communications system for the past 25 years.  We = have implemented all sorts of telephone line standards (including data, = fax and voice) and now all sorts of VoIP protocols (including various = common protocols and speech coders).

 

One speech = coder that we have used quite extensively over the past 10 years is = MELP/MELPe.  These were initially developed by DOD/NSA and later = issued as a world-wide standard by NATO as STANAG 4591.  This = speech coder operates at three different rates, 2400, 1200 and = 600bps.  The primary use was for encrypted radio channels.  We = have had customers use MELP/MELPe for all sorts of applications and we = have bridged traditional VOIP with MELP.

 

After = packaging MELP in RTP for several customers, we have realized that we = need to promote a standardized RTP payload for this speech coder.  = This draft is an effort that we believe should result in an RFC to = specify the RTP payload format and SDP parameters for the MELPe speech = coder.

 

Thank you for your time and comments.

 

(BTW, we = have audio examples of MELP encoded speech at http://www.vocal.com/audio-examples/other-speech-coder-audio-examp= les/.  I hope to not be seen as self promoting but rather = enlightening.  Since many people may not be aware of MELP, I wanted = to briefly convey the context and potential = applications.)

 

 

Victor = Demjanenko, Ph.D.
Associate
VOCAL Technologies, Ltd.
520 Lee = Entrance
Amherst, NY  14228
Victor.Demjanenko@vocal.com
http://www.vocal.com
Tel: = +1-716-688-4675
Fax: +1-716-639-0713

 

Confidential = Information
The information contained in this electronic mail = transmission is confidential and intended to be sent only to the stated = recipient of the transmission.  It may therefore be protected from = unauthorized use or dissemination.  If you are not the intended = recipient or the intended recipient's agent, you are hereby notified = that any review, use, dissemination, distribution or copying of this = communication is strictly prohibited.  You are also asked to notify = us immediately by telephone and to delete this transmission with any = attachments and destroy all copies in any form.  Thank you in = advance for your cooperation.

 

------=_NextPart_000_11A0_01CF7A75.E2045210-- From nobody Wed May 28 17:58: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 53F971A07D0; Wed, 28 May 2014 17:58:39 -0700 (PDT) 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 pZh8BU8FXk0P; Wed, 28 May 2014 17:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E111A0310; Wed, 28 May 2014 17:58:37 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529005837.21190.39014.idtracker@ietfa.amsl.com> Date: Wed, 28 May 2014 17:58:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Fo-IFOTyphhcXcUYSguYBr4AzWc Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-04.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: Thu, 29 May 2014 00:58:39 -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 High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-04.txt Pages : 96 Date : 2014-05-28 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-04 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 Wed May 28 18:06:24 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 C1BCE1A6F1F for ; Wed, 28 May 2014 18:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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.651, 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 sUrEhuHtjDHp for ; Wed, 28 May 2014 18:06:11 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4991A6F20 for ; Wed, 28 May 2014 18:06:11 -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=1401325567; x=1432861567; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p36+1SQ3Vn3yF50SHoU2+V5TG54KvckaOa9FY8GOC/U=; b=hBXOshnffLnECbyc0VFkdPqfWvsZiJKT0dpB2z7xOb7HCo/M17mDXlaQ d73mmRhQRj0MNeaTc4tTWhXCzECr1oAIFsy54kFb+/fjsqna4JNLLp35E zup8Y65btKna0qJbvjOII4Ysxtl7Lx2wlLV1TX4Pw7uw36XKL9F+wjPTQ g=; X-IronPort-AV: E=McAfee;i="5600,1067,7452"; a="37870533" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 28 May 2014 18:06:07 -0700 X-IronPort-AV: E=Sophos;i="4.98,931,1392192000"; d="scan'208";a="740111377" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 May 2014 18:06:08 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.156]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0181.006; Wed, 28 May 2014 18:06:07 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-04.txt Thread-Index: AQHPetkhzU0sgg7nwU+NffcuIOHWvptWvYxQ Date: Thu, 29 May 2014 01:06:06 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83452E0536@nasanexd02f.na.qualcomm.com> References: <20140529005837.21190.39014.idtracker@ietfa.amsl.com> In-Reply-To: <20140529005837.21190.39014.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] 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/x1-BFKStV6iyq6CWIuqwKhoTRMA Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-04.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: Thu, 29 May 2014 01:06:18 -0000 Compared to -03, we have addressed all open issues that we are aware of, in= cluding those mentioned in my previous email mentioning a conference call a= mong some of us.=20 I'd like to request the WG chairs to issue the WGLC for this draft, based o= n that we have addressed all open issues and that the RFC is urgently neede= d by the industry for HEVC deployment. Many thanks! BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, May 28, 2014 5:59 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-04.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 High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-04.txt Pages : 96 Date : 2014-05-28 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-04 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