From magnus.westerlund@ericsson.com Tue Oct 1 07:49:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FA11E81AC for ; Tue, 1 Oct 2013 07:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.618 X-Spam-Level: X-Spam-Status: No, score=-105.618 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+3GeM2VSwfz for ; Tue, 1 Oct 2013 07:49:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8711E819F for ; Tue, 1 Oct 2013 07:49:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-a2-524ae0fd4a8f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.D0.16099.DF0EA425; Tue, 1 Oct 2013 16:49:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Tue, 1 Oct 2013 16:49:33 +0200 Message-ID: <524AE118.3050306@ericsson.com> Date: Tue, 1 Oct 2013 16:50:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre7fB15BBn/vmFhcuniWyeJ64yZ2 ByaPJUt+MnksXv+eMYApissmJTUnsyy1SN8ugStjzf1H7AVHayqW9jcxNTBOT+pi5OCQEDCR OPclvIuRE8gUk7hwbz1bFyMXh5DAYUaJN5sXM0I4yxglNlxZzgpSxSugLfFySjsTiM0ioCKx 5VA/M4jNJmAhcfNHIxuILSoQLNG+/SsbRL2gxMmZT1hAbBGg+kM3f4DZzAKaEoc+PwarERaw l1gw6wjYfCEBHYlDj5vB4pwCuhIz3uxng7hOUmLbomPsEL16ElOutjBC2PISzVtnM0P0aks0 NHWwTmAUmoVk9SwkLbOQtCxgZF7FyJ6bmJmTXm64iREYqge3/NbdwXjqnMghRmkOFiVx3g9v nYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJo+XfErwGYLCy/Dswd336ufyvpZOntulNTR pd3vTMIcHp9VX/7p67EqlY6V/sd6Hv215jAMK7a4tu99b97Gj29XXZWsWBJZemLVu6z7SmkB tf9yimtdLoVGm55zNdj0ZMtEzaP7U9sTvP5rt+wO3Xviu/ScK1dyDhgnPdzdViwyraC4a73D 9ztKLMUZiYZazEXFiQAH7V0VIwIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 14:49:49 -0000 Hi Stephan, Thanks for the comments. See inline for comments how I see these are addressed. WG participants, please review! On 2013-09-26 20:07, Stephan Wenger wrote: > Hi Magnus, group, > > A few random comments. None of them are showstoppers. Yes, I should have > contributed those earlier. Sorry. > > Perhaps add a section about "writing style". Aspects here: > (1) contrary to most other SDOs, the IETF has a history of spelling out > not only WHAT an implementation is to do, but also WHY. As a lot of RTP > payload formats are written by media guys (who's home SDO is not > necessarily the IETF), mentioning this could help overcoming a culture > shock. Agreed, I will include this. > (2) OTOH, many/most implementers of RTP payload specs are the same people > that also implement the network centric parts of the media codec--at least > for well designed media codecs, systems, and payload formats. Therefore, > it is also good to reflect the style and terminology of the media codings > pec in the payload format--even if that makes the payload spec a little > bit less accessible for folks working only in the IETF. This is one > reason why I don't feel bad about the often lamented "density" of the > H.264 payload specs. No compromises should be made on core IETF habits > like the use of 2119 keywords, though. I don't see this necessarily as being contrary to 1). I think we should recommend using the terminology of the codec to be precise and clear. The payload formats goal is to make clear the mapping between the two worlds, thus the whole purpose is to bind these worlds together. > (3) It's also worth spelling out that the IETF has a historic (albeit > arguably not current) preference for lean and mean specs, even at the cost > of some functionality. Most media codec SDOs operate under an assumption > that if there were a use-case/requirement (however exotic/weak it may be, > and I note that use/case and requirements discussions have quite often > nothing to do with the real world) and no competing tool, a proposal goes > in, pleasing certain IPR departments and leading to patent bonuses and > career advancements, at the cost of a bloated document. Some RTP payload > formats written predominantly by media codec people arguably are bloated > as well for the same reason. (And yes, I take personal blame for some of > this.) While I do not see that we can change the situation (you want to > have the media competence of the media coding people), I think we can at > least point it out--hopefully in somewhat more diplomatic language--so to > explain a very common culture clash between IETF regulars and payload > format writers. The RTP Payload formats may not be lean any more, but I think that is due to the increased complexity in the codecs and the need for being clear and explicit. I propose that we add a section between 4.1.3 and 4.1.4 on Writing Style My attempt for this section is the following: 4.1.4. Writing Style When writing an IETF draft for an RTP payload format some few consideration on how to write in the IETF: Include Motivations: It is common to include the motivation for why a particular design or technical choice was chosen. These are not long statements, a sentence here and there explaining why. Use the Defined Terminology: There exist defined terminology both in RTP and in the various media codecs. A payload format specification do needs to use both to make clear the relation of features and their functions. Keeping It Simple: IETF has a history of specifications that are focused on their main usage. When it comes to RTP Payload formats that has a lot of modes and features the actually deployments has in most cases only include the most basic features that had very clear requirements. Time and effort can be saved by only focusing on the most important use cases and keep the solution simple. > > In 3.1.1 I would mention prominently the early and personal IPR disclosure > obligations in the IETF, as these differ from other SDOs which specify > media codecs. Simply pointing to the policy docs may be not enough. I agree, this should have been more clearly stated. Here are my proposal for text around this. It is very important to note and understand the IETF Intellectual Property Rights (IPR) policy that requires early disclosures and disclosures based on personal knowledge from the person contributing in IETF. These rules are significantly different from many other standardization organizations. The IETF rules and rights associated with copyright and IPR are documented in BCP 78 [RFC5378] and BCP 79 [RFC3979]. For example a person that has a patent or a patent application that is believed to cover a mechanism that gets added to the Internet draft they are contributing to (e.g. posting comments or suggestions on the mailing list or speaking at a meeting) they will need to make a timely (weeks, not months) IPR disclosure. Read the above documents for the authoritative rules. Failure to follow the IPR rules can have dire implications for the specification and the author as discussed in [RFC6701]. The main part of the IETF process is formally defined in RFC 2026 [RFC2026]. RFC 2418 [RFC2418] describes the WG process, the relation between the IESG and the WG, and the responsibilities of WG chairs and participants. > > Section 3 (and section 1). I think a lot of this description is written > for someone who wants to write an RTP payload format for an existing media > codec (with a stable and essentially unchangeable spec). While this is > probably still the most common scenario, there are a number of cases where > the transport aspects of the media coder and the media aspects of the > transport (RTP payload format) have been developed concurrently, generally > with very pleasing results for both specs. H.264 is one prominent > example, but there are others. Arguably, joint development of codec and > RTP payload format is becoming a trend. I think that a 2013 generation > RTP payload how-to should acknowledge this situation. One way to do that > would be to include, in section 3, subsections "read and understand the > media coding spec", and "influence the media coding spec". If people > think this is a good idea, I'm willing to draft a few paragraphs. Yes, I think this is relevant to be explicit. If you can write up some text I would be thankful, but please do so within one or maximum two weeks. > > I think the 9000 byte path MTU is generally not available in home > environments. Instead, MTU sizes larger than the 1500 bytes (from > Ethernet) are AFAICT, available only in a few selected (large/medium) > enterprises and in the academic world. If that's true, it should be > stated. And, in home environments, the limiting factor is often not even > the ISP, but those old $50 router boxes (and their NAT implementations) > that infest the world. Mentioning this, perhaps with an informative > reference to a recent study, would send a message: if your codec will be > used a lot in home environments, don't go above 1500 bytes. Not this > year, and not next. The message I really like to state is don't assume that 1500 bytes is your MTU. It might be lower, and it might be higher. Design the payload format to be flexible to allow usage in either environments. Then there is a usage configuration that in most environment you you need to be conservative, or maybe you should actually implement path MTU discovery ;-). Updated text proposal. At the time of writing this document the most common IP Maximum Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet data payload). However there exist both links with smaller MTUs and links with much larger MTUs. Certain parts of the Internet already today support an IP MTU of 8000 bytes or more, but these are limited islands. The most likely places to find larger MTUs than 1500 bytes are within enterprise networks, university networks, data centers, storage networks as well as over high capacity (10 Gbps or more) links. There is a slow ongoing evolution towards larger MTU sizes. However, at the same time it has become common to use tunneling protocols, often multiple ones who's overhead when added together can shrink the MTU significant. Thus, there exist a need to consider both limited MTUs as well as enable support of larger MTUs. This should be considered in the design, especially in regards to features such as aggregation of independently decodable data units. Note, I don't have an good reference to point at where these MTU networks exist. This is really a speculation based on what source of capability that exist for larger MTUs. > > Sections 5.1.1 and 5.1.2: one key use case of both aggregation and > fragmentation is the effective packetization of pre-recorded content, > where one cannot change the size of ADUs without transcoding. The key > use case of aggregation is the packetization overhead for small ADUs such > as parameter sets or SEI messages in H.264. Yes, I have tried to make these clearer in the below text. 5.1.1. Aggregation Aggregation allows for the inclusion of multiple application data units (ADUs) within the same RTP payload. This is commonly supported for codecs that produce ADUs of sizes smaller than the IP MTU. Do remember that the MTU may be significantly larger than 1500 bytes. An MTU of 9000 bytes is available today and an MTU of 64k may be available in the future. Many speech codecs have the property of ADUs of a few fixed sizes. Video encoders may generally produce ADUs of quite flexible sizes. Thus the need for aggregation may be less. But some codecs produces small ADUs mixed with large, for example H.264 SEI messages. Sending individual SEI message in separate packets are not efficient compared to combing the with other ADUs. There also exist cases when the ADUs are pre-produced and can't be adopted to a specific networks MTU. Instead their packetization needs to be adopted to the network. Thus there exist some different use cases with the possibility to aggregate multiple ADUs, including for different playback times, is useful. The main disadvantage of aggregation is the extra delay introduced (due to buffering until a sufficient number of ADUs have been collected at the sender) and reduced robustness against packet loss. Aggregation also introduces buffering requirements at the receiver. 5.1.2. Fragmentation If the real-time media format has the property that it may produce ADUs that are larger than common MTU sizes then fragmentation support should be considered. An RTP Payload format may always fall back on IP fragmentation, however as discussed in RFC 2736 this has some drawbacks. Mainly that IP fragmented packets commonly are discarded in the network, especially by Network Address Translators or Firewalls. The usage of RTP payload format-level fragmentation allows for more efficient usage of RTP packet loss recovery mechanisms. It may also in some cases also allow better usage of partial ADUs by doing media specific fragmentation at media specific boundaries. In use cases where the ADUs are pre-produced and can't be adopted to the network support for fragmentation can be crucial. > > In a different email, you asked for review of 5.1.5. There are more > qualified people on this list to comment, but here are a few points. > (1) citing H.264 RFC 6184 for temporal scalability is a bit questionable, > as 6184 doe snot include a single mechanism to support temporal > scalability (although H.264 does). So if people would go to 6184 as the > payload format for base H.264 and read it, expecting ideas on how to deal > with temporal scalability, they would come up blank after digging through > 101 pages of not exactly easy to read spec language. I fear that it would > be best to point to SVC and 6190 for temporal scalability, just as it is > done for spatial and SNR. I think there is a point that tempoeral scalability can simply be done, without explicit definition. But it should be clear that this is may also be more explictly defined as in SVC. > (2) with respect to MST: the doc could be read that re-alignment for > H.264-SVC could be implemented through 6051. This is not the case, as > decoding time and NAL unit order are mostly decoupled (not only in SVC, > but in all modern video codecs). Agreed, this is poorly formulated. I will try to make it clear that for certain features an payload format design could rely on these tools to be part of solution. The changed wording is: ... In order to allow correct data provision to a decoder after reception from different sessions, data re-alignment mechanisms are described for Scalable Video Coding [RFC6190]. There exist some generic tools that may be of use for a payload format design for a scalable codec. These include the Rapid Sync for RTP flows [RFC6051], which is using existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely inter-session synchronization. Another is the signaling feature for indicating dependencies of RTP sessions in SDP, as defined in the Media Decoding Dependency Grouping in SDP [RFC5583]. > (3) Perhaps write something to the extent that MST was unpopular because > of the impracticality of multiple transport addresses, and that this > reason is slowly going away through IETF-acceptance of RTP mux techniques. I think we need to be clear here. SVC MST mode appears to have gotten significant use as multiple packet streams (SSRCs) within a single RTP session. The original envision of the MST mode was for multicast or other receiver controlled steering of what flows was received. From my perspective any future scalable codec should consider having both a single stream and a multi stream mode. However, the mapping of the RTP packet streams needs to be flexible to cater both for multiple RTP sessions and then commonly multicast groups as well as within a single RTP session. > > Section 6.2, "recent" VC-1. You probably wanted to cite VP8? Calling > VC-1 and its payload spec "recent" is a bit of a stretch. Failure to keep the text current. This text was first included back in 2008. Haven't been in a hurry to finish this document. But now it is time. I updated this text to say: The definition of RTP payload formats for video has seen an evolution from the early ones such as H.261 towards the latest for VP-8 and H.265/HEVC. > > Perhaps add a "Do and don't" sections listing key mistakes. In the don't > section, list the handling of the timestamp in RFCs 2038 and 2250. This is WG last call, of a document that has been a WG document since 2006 (then in AVT). This proposal although a good idea, is a little bit late to introduce. Primarily as I think such a section would require a couple of rounds of revision before getting right. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Tue Oct 1 08:10:53 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9511E8125 for ; Tue, 1 Oct 2013 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.811 X-Spam-Level: X-Spam-Status: No, score=-103.811 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCIeyKXMCUVo for ; Tue, 1 Oct 2013 08:10:46 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B457621E81BA for ; Tue, 1 Oct 2013 08:10:29 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-b2-524ae5e49461 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9C.67.25272.4E5EA425; Tue, 1 Oct 2013 17:10:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.328.9; Tue, 1 Oct 2013 17:10:27 +0200 Message-ID: <524AE5FF.5090904@ericsson.com> Date: Tue, 1 Oct 2013 17:10:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <524422EA.7090408@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre6Tp15BBqdP6lo82D6X0eLSxbNM DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGwqk3mQvWSld0XfjG0sC4QLSLkYNDQsBE 4sc/ry5GTiBTTOLCvfVsXYxcHEICRxklZrZfg3KWMkrMaD/NDFLFK6AtseD+bSYQm0VARaKp 8zSYzSZgIXHzRyMbiC0qECzRvv0rG0S9oMTJmU9YQGwRAT2J/R3TGEFsZgFNiUOfH4PVCAvY SyyYdYQVYtlaRolZeyeBNXAK+Erca+lggzhPUmLbomPsEM16ElOutkANkpdo3job7DghoOMa mjpYJzAKzUKyexaSlllIWhYwMq9i5ChOLU7KTTcy2MQIDNeDW35b7GC8/NfmEKM0B4uSOO/H t85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhXGLFtL3w2zUdhas2inYbGidwue35FOsyv 8SsU+GtxZbdzOucbjtAdv9hMf3dZxzzPqpr+3qu07XdfnJomK9evD3nLahJWv/Bxf/b+8ff6 016i55kmHfGOK7gbeUld1jCwoM7+jOwa5csfdrruadzjdnJeS/axIzEmVnECS657eFz/X1ey Vk2JpTgj0VCLuag4EQAFt1y9JQIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 15:10:53 -0000 On 2013-09-26 14:59, Ali C. Begen (abegen) wrote: > > On Sep 26, 2013, at 3:04 PM, Magnus Westerlund wrote: > >> On 2013-09-26 11:46, Ali C. Begen (abegen) wrote: >>> Looks good to me except that there are bunch of lower-case 2119 keywords. >>> Any possibility to avoid them or is it better to make them upper case? >> >> No, they should not be interpreted in the RFC 2119 upper case meaning. >> This is an informative document and regular English interpretation are >> fine. > > yes, it is information and I keep forgetting that. > >> I find it difficult to write without using may, should, recommend >> and to some degree must. And removing these out of the document would be >> a massive undertaking which I fail to see the benefit with. >> > I think putting a note somewhere around the intro part about the use of these keywords in lower case would be beneficial. I think we actually have bigger issue regarding RFC 2119 language. The fact that we haven't discussed the usage of RFC 2119 language when writing RTP payload formats. Thus I propose the following section edits: New section: 2.3. Use of Normative Requirements Language As this document is an both of the informational category and being an instruction rather than a specification for something this document does not use any RFC 2119 language and the interpretation of may, should, recommended and must are the ones of the English language. New last bullet: 4.1.4. Writing Style When writing an IETF draft for an RTP payload format some few consideration on how to write in the IETF: Include Motivations: It is common to include the motivation for why a particular design or technical choice was chosen. These are not long statements, a sentence here and there explaining why. Use the Defined Terminology: There exist defined terminology both in RTP and in the various media codecs. A payload format specification do needs to use both to make clear the relation of features and their functions. Keeping It Simple: IETF has a history of specifications that are focused on their main usage. When it comes to RTP Payload formats that has a lot of modes and features the actually deployments has in most cases only include the most basic features that had very clear requirements. Time and effort can be saved by only focusing on the most important use cases and keep the solution simple. Normative Requirements: When writing specifications there are commonly need to make it clear when something is normative and at what level. In IETF the most common method is to use "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] that defines the meaning of "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 stewe@stewe.org Tue Oct 1 10:17:20 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31D811E81B4 for ; Tue, 1 Oct 2013 10:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N4qySpMl5e7 for ; Tue, 1 Oct 2013 10:17:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 579CA11E8153 for ; Tue, 1 Oct 2013 10:17:12 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 1 Oct 2013 17:17:02 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.67]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.67]) with mapi id 15.00.0775.005; Tue, 1 Oct 2013 17:17:02 +0000 From: Stephan Wenger To: Magnus Westerlund Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkpm9jcQAgBqFRACACBnOAP//s7AA Date: Tue, 1 Oct 2013 17:17:01 +0000 Message-ID: In-Reply-To: <524AE118.3050306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(52604005)(199002)(189002)(51444003)(51704005)(377424004)(24454002)(51914003)(81816001)(56816003)(77096001)(83072001)(561944002)(74366001)(76176001)(76786001)(76796001)(4396001)(36756003)(81686001)(46102001)(80976001)(74502001)(79102001)(53806001)(54316002)(56776001)(47446002)(74662001)(76482001)(31966008)(74876001)(54356001)(47736001)(69226001)(80022001)(66066001)(74706001)(19580395003)(65816001)(83322001)(19580405001)(81342001)(63696002)(51856001)(81542001)(49866001)(50986001)(47976001)(77982001)(59766001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB363; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:71.202.147.60; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <42569C635B6B864383B74C1733A1C8F4@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 17:17:20 -0000 Hi Magnus, all, Thanks for taking my suggestions into account. Your updates are fine, plus/minus massaging the language a bit (Magnus, I'll send you suggestions in private). As for this: >> >>Section 3 (and section 1). I think a lot of this description is written >>for someone who wants to write an RTP payload format for an existing >>media >>codec (with a stable and essentially unchangeable spec). While this is >>probably still the most common scenario, there are a number of cases >>where >>the transport aspects of the media coder and the media aspects of the >>transport (RTP payload format) have been developed concurrently, >>generally >>with very pleasing results for both specs. H.264 is one prominent >>example, but there are others. Arguably, joint development of codec and >>RTP payload format is becoming a trend. I think that a 2013 generation >>RTP payload how-to should acknowledge this situation. One way to do that >>would be to include, in section 3, subsections "read and understand the >>media coding spec", and "influence the media coding spec". If people >>think this is a good idea, I'm willing to draft a few paragraphs. > >Yes, I think this is relevant to be explicit. If you can write up some >text I would be thankful, but please do so within one or maximum two >weeks. How about two hours later :-) 3.x Read and understand the media coding spec It may be obvious, but it is necessary for an author of an RTP payload specification=20 to have a solid understanding of the media to be transported. Important are not only=20 the specifically spelled out transport aspects (if any) in the media coding spec, but also core concepts of the underlying technology. For example, an RTP payload format for=20 video coded with inter picture prediction will perform poorly if the payload designer does not take the use of inter picture prediction into account. OTOH, some (mostly older) media codecs offer "error resilience" tools against bit errors, which, when misemployed over RTP, in almost all cases would only introduce overhead with no=20 measurable return. 3.x Joint development of media coding spec and RTP payload format In the last decade there have been a few cases where the media codec and the associated=20 RTP payload format have been developed concurrently and jointly. Developing the two specs not only concurrently but also jointly, in close cooperation with the group developing The media codec, allows to leverage the benefits joint source/channel coding can provide. Doing so has historically resulted in well performing payload formats and in success of both media coding spec and associated RTP payload format. Insofar, whenever the opportunity presents it, it may be useful to closely keep the media coding group in the loop (through appropriate liaison means whatever those may be) and influence the media coding spec to=20 be RTP friendly. One example for such a media coding spec is H.264, where the RTP payload header co-serves as the H.264 NAL unit header and vice versa, and is documented in both specs. Stephan On 10.1.2013 07:50 , "Magnus Westerlund" wrote: >Hi Stephan, > >Thanks for the comments. See inline for comments how I see these are >addressed. > >WG participants, please review! > >On 2013-09-26 20:07, Stephan Wenger wrote: >> Hi Magnus, group, >>=20 >> A few random comments. None of them are showstoppers. Yes, I should >>have >> contributed those earlier. Sorry. >>=20 >> Perhaps add a section about "writing style". Aspects here: >> (1) contrary to most other SDOs, the IETF has a history of spelling out >> not only WHAT an implementation is to do, but also WHY. As a lot of RTP >> payload formats are written by media guys (who's home SDO is not >> necessarily the IETF), mentioning this could help overcoming a culture >> shock. > >Agreed, I will include this. > > >> (2) OTOH, many/most implementers of RTP payload specs are the same >>people >> that also implement the network centric parts of the media codec--at >>least >> for well designed media codecs, systems, and payload formats. >>Therefore, >> it is also good to reflect the style and terminology of the media >>codings >> pec in the payload format--even if that makes the payload spec a little >> bit less accessible for folks working only in the IETF. This is one >> reason why I don't feel bad about the often lamented "density" of the >> H.264 payload specs. No compromises should be made on core IETF habits >> like the use of 2119 keywords, though. > >I don't see this necessarily as being contrary to 1). I think we should >recommend using the terminology of the codec to be precise and clear. >The payload formats goal is to make clear the mapping between the two >worlds, thus the whole purpose is to bind these worlds together. > > >> (3) It's also worth spelling out that the IETF has a historic (albeit >> arguably not current) preference for lean and mean specs, even at the >>cost >> of some functionality. Most media codec SDOs operate under an >>assumption >> that if there were a use-case/requirement (however exotic/weak it may >>be, >> and I note that use/case and requirements discussions have quite often >> nothing to do with the real world) and no competing tool, a proposal >>goes >> in, pleasing certain IPR departments and leading to patent bonuses and >> career advancements, at the cost of a bloated document. Some RTP >>payload >> formats written predominantly by media codec people arguably are bloated >> as well for the same reason. (And yes, I take personal blame for some >>of >> this.) While I do not see that we can change the situation (you want to >> have the media competence of the media coding people), I think we can at >> least point it out--hopefully in somewhat more diplomatic language--so >>to >> explain a very common culture clash between IETF regulars and payload >> format writers. > >The RTP Payload formats may not be lean any more, but I think that is >due to the increased complexity in the codecs and the need for being >clear and explicit. > > >I propose that we add a section between 4.1.3 and 4.1.4 on Writing Style > >My attempt for this section is the following: > >4.1.4. Writing Style > > When writing an IETF draft for an RTP payload format some few > consideration on how to write in the IETF: > > Include Motivations: It is common to include the motivation for why > a particular design or technical choice was chosen. These are > not long statements, a sentence here and there explaining why. > > Use the Defined Terminology: There exist defined terminology both in > RTP and in the various media codecs. A payload format > specification do needs to use both to make clear the relation of > features and their functions. > > Keeping It Simple: IETF has a history of specifications that are > focused on their main usage. When it comes to RTP Payload formats > that has a lot of modes and features the actually deployments has > in most cases only include the most basic features that had very > clear requirements. Time and effort can be saved by only focusing > on the most important use cases and keep the solution simple. > > >>=20 >> In 3.1.1 I would mention prominently the early and personal IPR >>disclosure >> obligations in the IETF, as these differ from other SDOs which specify >> media codecs. Simply pointing to the policy docs may be not enough. > >I agree, this should have been more clearly stated. Here are my proposal >for text around this. > > It is very important to note and understand the IETF Intellectual > Property Rights (IPR) policy that requires early disclosures and > disclosures based on personal knowledge from the person contributing > in IETF. These rules are significantly different from many other > standardization organizations. The IETF rules and rights associated > with copyright and IPR are documented in BCP 78 [RFC5378] and BCP 79 > [RFC3979]. For example a person that has a patent or a patent > application that is believed to cover a mechanism that gets added to > the Internet draft they are contributing to (e.g. posting comments or > suggestions on the mailing list or speaking at a meeting) they will > need to make a timely (weeks, not months) IPR disclosure. Read the > above documents for the authoritative rules. Failure to follow the > IPR rules can have dire implications for the specification and the > author as discussed in [RFC6701]. > > The main part of the IETF process is formally defined in RFC 2026 > [RFC2026]. RFC 2418 [RFC2418] describes the WG process, the relation > between the IESG and the WG, and the responsibilities of WG chairs > and participants. > >>=20 >> Section 3 (and section 1). I think a lot of this description is written >> for someone who wants to write an RTP payload format for an existing >>media >> codec (with a stable and essentially unchangeable spec). While this is >> probably still the most common scenario, there are a number of cases >>where >> the transport aspects of the media coder and the media aspects of the >> transport (RTP payload format) have been developed concurrently, >>generally >> with very pleasing results for both specs. H.264 is one prominent >> example, but there are others. Arguably, joint development of codec and >> RTP payload format is becoming a trend. I think that a 2013 generation >> RTP payload how-to should acknowledge this situation. One way to do >>that >> would be to include, in section 3, subsections "read and understand the >> media coding spec", and "influence the media coding spec". If people >> think this is a good idea, I'm willing to draft a few paragraphs. > >Yes, I think this is relevant to be explicit. If you can write up some >text I would be thankful, but please do so within one or maximum two >weeks. > >>=20 >> I think the 9000 byte path MTU is generally not available in home >> environments. Instead, MTU sizes larger than the 1500 bytes (from >> Ethernet) are AFAICT, available only in a few selected (large/medium) >> enterprises and in the academic world. If that's true, it should be >> stated. And, in home environments, the limiting factor is often not >>even >> the ISP, but those old $50 router boxes (and their NAT implementations) >> that infest the world. Mentioning this, perhaps with an informative >> reference to a recent study, would send a message: if your codec will be >> used a lot in home environments, don't go above 1500 bytes. Not this >> year, and not next. > >The message I really like to state is don't assume that 1500 bytes is >your MTU. It might be lower, and it might be higher. Design the payload >format to be flexible to allow usage in either environments. > >Then there is a usage configuration that in most environment you you >need to be conservative, or maybe you should actually implement path MTU >discovery ;-). > >Updated text proposal. > >At the time of writing this document the most common IP Maximum >Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet data >payload). However there exist both links with smaller MTUs and links >with much larger MTUs. Certain parts of the Internet already today >support an IP MTU of 8000 bytes or more, but these are limited islands. >The most likely places to find larger MTUs than 1500 bytes are within >enterprise networks, university networks, data centers, storage networks >as well as over high capacity (10 Gbps or more) links. There is a slow >ongoing evolution towards larger MTU sizes. However, at the same time it >has become common to use tunneling protocols, often multiple ones who's >overhead when added together can shrink the MTU significant. Thus, there >exist a need to consider both limited MTUs as well as enable support of >larger MTUs. This should be considered in the design, especially in >regards to features such as aggregation of independently decodable data >units. > >Note, I don't have an good reference to point at where these MTU >networks exist. This is really a speculation based on what source of >capability that exist for larger MTUs. > >>=20 >> Sections 5.1.1 and 5.1.2: one key use case of both aggregation and >> fragmentation is the effective packetization of pre-recorded content, >> where one cannot change the size of ADUs without transcoding. The key >> use case of aggregation is the packetization overhead for small ADUs >>such >> as parameter sets or SEI messages in H.264. > >Yes, I have tried to make these clearer in the below text. > >5.1.1. Aggregation > > Aggregation allows for the inclusion of multiple application data > units (ADUs) within the same RTP payload. This is commonly supported > for codecs that produce ADUs of sizes smaller than the IP MTU. Do > remember that the MTU may be significantly larger than 1500 bytes. > An MTU of 9000 bytes is available today and an MTU of 64k may be > available in the future. Many speech codecs have the property of > ADUs of a few fixed sizes. Video encoders may generally produce ADUs > of quite flexible sizes. Thus the need for aggregation may be less. > But some codecs produces small ADUs mixed with large, for example > H.264 SEI messages. Sending individual SEI message in separate > packets are not efficient compared to combing the with other ADUs. > There also exist cases when the ADUs are pre-produced and can't be > adopted to a specific networks MTU. Instead their packetization > needs to be adopted to the network. Thus there exist some different > use cases with the possibility to aggregate multiple ADUs, including > for different playback times, is useful. > > The main disadvantage of aggregation is the extra delay introduced > (due to buffering until a sufficient number of ADUs have been > collected at the sender) and reduced robustness against packet loss. > Aggregation also introduces buffering requirements at the receiver. > >5.1.2. Fragmentation > > If the real-time media format has the property that it may produce > ADUs that are larger than common MTU sizes then fragmentation support > should be considered. An RTP Payload format may always fall back on > IP fragmentation, however as discussed in RFC 2736 this has some > drawbacks. Mainly that IP fragmented packets commonly are discarded > in the network, especially by Network Address Translators or > Firewalls. The usage of RTP payload format-level fragmentation > allows for more efficient usage of RTP packet loss recovery > mechanisms. It may also in some cases also allow better usage of > partial ADUs by doing media specific fragmentation at media specific > boundaries. In use cases where the ADUs are pre-produced and can't > be adopted to the network support for fragmentation can be crucial. > > >>=20 >> In a different email, you asked for review of 5.1.5. There are more >> qualified people on this list to comment, but here are a few points. >> (1) citing H.264 RFC 6184 for temporal scalability is a bit >>questionable, >> as 6184 doe snot include a single mechanism to support temporal >> scalability (although H.264 does). So if people would go to 6184 as the >> payload format for base H.264 and read it, expecting ideas on how to >>deal >> with temporal scalability, they would come up blank after digging >>through >> 101 pages of not exactly easy to read spec language. I fear that it >>would >> be best to point to SVC and 6190 for temporal scalability, just as it is >> done for spatial and SNR. > >I think there is a point that tempoeral scalability can simply be done, >without explicit definition. But it should be clear that this is may >also be more explictly defined as in SVC. > > >> (2) with respect to MST: the doc could be read that re-alignment for >> H.264-SVC could be implemented through 6051. This is not the case, as >> decoding time and NAL unit order are mostly decoupled (not only in SVC, >> but in all modern video codecs). > >Agreed, this is poorly formulated. I will try to make it clear that for >certain features an payload format design could rely on these tools to >be part of solution. The changed wording is: > > ... In order to allow > correct data provision to a decoder after reception from different > sessions, data re-alignment mechanisms are described for Scalable > Video Coding [RFC6190]. There exist some generic tools that may be > of use for a payload format design for a scalable codec. These > include the Rapid Sync for RTP flows [RFC6051], which is using > existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely > inter-session synchronization. Another is the signaling feature for > indicating dependencies of RTP sessions in SDP, as defined in the > Media Decoding Dependency Grouping in SDP [RFC5583]. > > >> (3) Perhaps write something to the extent that MST was unpopular because >> of the impracticality of multiple transport addresses, and that this >> reason is slowly going away through IETF-acceptance of RTP mux >>techniques. > >I think we need to be clear here. SVC MST mode appears to have gotten >significant use as multiple packet streams (SSRCs) within a single RTP >session. The original envision of the MST mode was for multicast or >other receiver controlled steering of what flows was received. From my >perspective any future scalable codec should consider having both a >single stream and a multi stream mode. However, the mapping of the RTP >packet streams needs to be flexible to cater both for multiple RTP >sessions and then commonly multicast groups as well as within a single >RTP session. > > >>=20 >> Section 6.2, "recent" VC-1. You probably wanted to cite VP8? Calling >> VC-1 and its payload spec "recent" is a bit of a stretch. > >Failure to keep the text current. This text was first included back in >2008. Haven't been in a hurry to finish this document. But now it is time. > >I updated this text to say: >The definition of RTP payload formats for video has seen an evolution >from the early ones such as H.261 towards the latest for VP-8 and >H.265/HEVC. > > >>=20 >> Perhaps add a "Do and don't" sections listing key mistakes. In the >>don't >> section, list the handling of the timestamp in RFCs 2038 and 2250. > >This is WG last call, of a document that has been a WG document since >2006 (then in AVT). This proposal although a good idea, is a little bit >late to introduce. Primarily as I think such a section would require a >couple of rounds of revision before getting right. > >Cheers > > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >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 internet-drafts@ietf.org Wed Oct 2 00:50:19 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF921F9E99; Wed, 2 Oct 2013 00:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIXPfnmMno7n; Wed, 2 Oct 2013 00:50:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A38E21F9FB6; Wed, 2 Oct 2013 00:49:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002074937.20697.87901.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 00:49:37 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 07:50:19 -0000 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 : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-07.txt Pages : 59 Date : 2013-10-02 Abstract: This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Wed Oct 2 00:50:58 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368A921F9929 for ; Wed, 2 Oct 2013 00:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9R+JYle5cZo for ; Wed, 2 Oct 2013 00:50:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 908B721E80F1 for ; Wed, 2 Oct 2013 00:49:45 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a7-524bd018ddb4 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.EF.03802.810DB425; Wed, 2 Oct 2013 09:49:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Wed, 2 Oct 2013 09:49:44 +0200 Message-ID: <524BD037.10209@ericsson.com> Date: Wed, 2 Oct 2013 09:50:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvra7EBe8gg6cHtSwuXTzLZHG9cRO7 A5PHkiU/mTwWr3/PGMAUxWWTkpqTWZZapG+XwJWx/s5B5oJ9ChX7Fv1lb2D8KdnFyMkhIWAi sfTAJFYIW0ziwr31bF2MXBxCAocZJdq+zYZyljFKbDw9gxmkildAU2LhpV+MIDaLgIrEycad LCA2m4CFxM0fjWwgtqhAsET79q9sEPWCEidnPgGrEQGqP3TzB5jNDDTn0OfHYDXCAvYSC2Yd AbtCSEBHYkVfH9h8TgFdidXzbrNAXCcpsW3RMXaIXj2JKVdbGCFseYnmrbOZIXq1JRqaOlgn MArNQrJ6FpKWWUhaFjAyr2Jkz03MzEkvN9rECAzWg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY9zI4tPJq2tQ/nmIxPTLtZe9PAY3Xlzr/s3Qsc3vK 791yr8XnSfn5rzPk9ILfhH7d++HTIZWPAQaOBz9n2Wn9O1/3xUb+8xrBx0fa2bRLUp0jdWZy +W7ODbm+99Q61U+zLDkPPj+6dGWS9KfJ8osTkhedVqzu/hT39chyNsaU7U5yVVVrPH/mKLEU ZyQaajEXFScCAJNP6qAkAgAA Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 07:50:58 -0000 Thanks for the text proposal Also thank for the text edits provided privately. To allow anyone in the WG to review these I have submitted and updated draft version. Please comment within a week if you think these edits are acceptable. If not, explicit changes are preferred. On 2013-10-01 19:17, Stephan Wenger wrote: > Hi Magnus, all, > Thanks for taking my suggestions into account. Your updates are fine, > plus/minus massaging the language a bit (Magnus, I'll send you suggestions > in private). > > As for this: >>> >>> Section 3 (and section 1). I think a lot of this description is written >>> for someone who wants to write an RTP payload format for an existing >>> media >>> codec (with a stable and essentially unchangeable spec). While this is >>> probably still the most common scenario, there are a number of cases >>> where >>> the transport aspects of the media coder and the media aspects of the >>> transport (RTP payload format) have been developed concurrently, >>> generally >>> with very pleasing results for both specs. H.264 is one prominent >>> example, but there are others. Arguably, joint development of codec and >>> RTP payload format is becoming a trend. I think that a 2013 generation >>> RTP payload how-to should acknowledge this situation. One way to do that >>> would be to include, in section 3, subsections "read and understand the >>> media coding spec", and "influence the media coding spec". If people >>> think this is a good idea, I'm willing to draft a few paragraphs. >> >> Yes, I think this is relevant to be explicit. If you can write up some >> text I would be thankful, but please do so within one or maximum two >> weeks. > > > How about two hours later :-) > > 3.x Read and understand the media coding spec > It may be obvious, but it is necessary for an author of an RTP payload > specification > to have a solid understanding of the media to be transported. Important > are not only > the specifically spelled out transport aspects (if any) in the media > coding spec, but also > core concepts of the underlying technology. For example, an RTP payload > format for > video coded with inter picture prediction will perform poorly if the > payload > designer does not take the use of inter picture prediction into account. > OTOH, some > (mostly older) media codecs offer "error resilience" tools against bit > errors, which, > when misemployed over RTP, in almost all cases would only introduce > overhead with no > measurable return. I put this as the new 3.1. > > 3.x Joint development of media coding spec and RTP payload format > In the last decade there have been a few cases where the media codec and > the associated > RTP payload format have been developed concurrently and jointly. > Developing the two specs > not only concurrently but also jointly, in close cooperation with the > group developing > The media codec, allows to leverage the benefits joint source/channel > coding can provide. > Doing so has historically resulted in well performing payload formats and > in success of > both media coding spec and associated RTP payload format. Insofar, > whenever the opportunity > presents it, it may be useful to closely keep the media coding group in > the loop (through > appropriate liaison means whatever those may be) and influence the media > coding spec to > be RTP friendly. One example for such a media coding spec is H.264, where > the RTP payload > header co-serves as the H.264 NAL unit header and vice versa, and is > documented in both > specs. I put this last in section 4, as Section 4.4. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Wed Oct 2 00:54:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666411E80FC for ; Wed, 2 Oct 2013 00:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.424 X-Spam-Level: X-Spam-Status: No, score=-104.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p53uxjl8W8np for ; Wed, 2 Oct 2013 00:54:17 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E64C711E814D for ; Wed, 2 Oct 2013 00:54:09 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-c5-524bd1207660 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 82.70.25272.021DB425; Wed, 2 Oct 2013 09:54:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Wed, 2 Oct 2013 09:53:38 +0200 Message-ID: <524BD122.4010106@ericsson.com> Date: Wed, 2 Oct 2013 09:54:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20131002074937.20697.87901.idtracker@ietfa.amsl.com> In-Reply-To: <20131002074937.20697.87901.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvra7CRe8gg85vFhaXLp5lcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvf9u9kKjgtXLD+xiKmB8Tp/FyMHh4SAicSMK8ZdjJxAppjE hXvr2boYuTiEBI4ySuyZuYAVwlnGKLFl1nVGkCpeAW2JKa1zmEBsFgEViad9Z1lBbDYBC4mb PxrZQGxRgWCJ9u1f2SDqBSVOznzCAmKLAG14+P4sM4gtLOAmsbthFtgcIQFHiWOdk1hADuIU cJJ4OyUT4iBJiW2LjrGD2MwCehJTrrYwQtjyEs1bZzNDtGpLNDR1sE5gFJyFZNssJC2zkLQs YGRexchRnFqclJtuZLCJERh+B7f8ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwdtc/mxGd5ctmdD1ecFNM36Gi1ZwyjV8Uc91Lp35l6nj29WGnxAR7D538 7z+7jod8UDf4svBr1d5PwnVMLuobfzJHv2UXm8h+qCV79XQLc80Itqh/tQaqE7emC824MXd7 nuHhM31OYtZ1ou4XPbWLNms/0ttfnqv4+dGGYIuVj0sXOPhwNNYosRRnJBpqMRcVJwIA8btU Mw0CAAA= Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 07:54:28 -0000 WG, This version contains the changes resulting of Stephan Wenger's and Ali's comments. Please review them, I will request from the WG chairs in one weeks time to request publication if no comments requiring changes has been forthcoming. The Diff makes it easy to review the last round of additions and changes. http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-07 Cheers Magnus On 2013-10-02 09:49, internet-drafts@ietf.org wrote: > > 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 : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-07.txt > Pages : 59 > Date : 2013-10-02 > > Abstract: > This document contains information on how to best write an RTP > payload format. It provides reading tips, design practices, and > practical tips on how to produce an RTP payload format specification > quickly and with good results. A template is also included with > instructions that can be used when writing an RTP payload format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 internet-drafts@ietf.org Thu Oct 3 16:11:58 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173421E80A6; Thu, 3 Oct 2013 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBXKxzL3zlT7; Thu, 3 Oct 2013 16:11:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0AE11E80DC; Thu, 3 Oct 2013 16:11:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131003231107.30291.84061.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 16:11:07 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-10.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 23:11:59 -0000 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 VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-10.txt Pages : 30 Date : 2013-10-03 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-10 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 yekuiw@qti.qualcomm.com Fri Oct 4 10:04:06 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417ED21F9D2A for ; Fri, 4 Oct 2013 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkCDJsty-Dro for ; Fri, 4 Oct 2013 10:04:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5708C21F9D1B for ; Fri, 4 Oct 2013 10:03:58 -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=1380906241; x=1412442241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JCEG9wAmUdAI8gUoYTFInlV+qFSeU1saFoh0Uq8MNNU=; b=ds0zGvUcGjv1uWFV34QEBdaglEDwUTFoxS+/ATmaCMxfYexw2BTYNGWf 2Itogu5QqAOkOR1qRbMUItwPXX5kON4f+AB7/Y+UeExABvti8ZyzSO3O+ UDbg7ni7HwS7nAAol+a+rhbpXie+oH/ZbGkjNPwcIuYJtYZZ8FhtG+hN1 8=; X-IronPort-AV: E=McAfee;i="5400,1158,7217"; a="78473428" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 04 Oct 2013 10:03:56 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7217"; a="549264944" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Oct 2013 10:03:56 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.158]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 10:03:48 -0700 From: "Wang, Ye-Kui" To: Stephan Wenger , "payload@ietf.org" Thread-Topic: [payload] FW: New Version Notification for draft-wenger-payload-h265-payload-header-extension-00.txt Thread-Index: AQHOuvWTBG5KaPm+6ESXmTTaE/l+pJnkxKmg Date: Fri, 4 Oct 2013 17:03:48 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83385AB1D3@nasanexd02f.na.qualcomm.com> References: <20130926200808.29653.4083.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , Jill Boyce Subject: Re: [payload] FW: New Version Notification for draft-wenger-payload-h265-payload-header-extension-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2013 17:04:06 -0000 Hi Stephan, All, We had a plan to introduce the signalling of the index of pictures with Tem= poralId equal to 0. Thus thanks for the draft targeting for fulfilling that= plan. I think we should agree on one approach for this, and include the ag= reed approach into draft-ietf-payload-rtp-h265-01. Preferably, to meet the = milestone of draft-ietf-payload-rtp-h265, we should have draft-ietf-payload= -rtp-h265-02 (with the agreed approach included) submitted before the next = IETF meeting. Among the two approaches included, I prefer option 2 (the one that can save= two bytes for each PACI packet), but with a slight change of the order of = the bits to largely reduce the irregularity - as the main drawback of the c= urrent option 2 is that there is no real PayloadHdr field immediately follo= wing the RTP header. This change would be:=20 - Move PayloadHdr of the contained NAL unit immediately after the RTP head= er, set the Type field to the PACI type value. - After PayloadHdr, put the original Type of contained NAL unit, then PHSs= ize etc. as in the draft. Some less important comments and nits: - It seems that PHSsize does not count the bytes of the flags between PHSsi= ze and PHS. It should be slightly better to let it cover the bytes of the f= lags too, such that parsing of the flags and PHS can be skipped if desirabl= e, e.g. in handling of a recorded RTP stream.=20 - In the figure for option 2, the three flags F[0..2] occupy 4 bit position= s in the figure. - The style of the first two figures (depicting options 1 and 2) are not al= igned with the payload structure figures in into draft-ietf-payload-rtp-h26= 5-01. The style of last figure (depicting the PHS structure) is aligned. Fo= r example, in the first figure, it seems that both PHS and the contained NA= L unit contain integer number of 32 bits. - It is specified that a PACI payload can be a FU or an AP (the wording of = "fragment" and "aggregation NAL unit" in sections 6.3 and 6.4 in the draft = make these aspects not really clear, but I guess the intent was to mean FU = and AP, respectively), but it is not specified whether a PACI payload can b= e a single NAL unit packet. I think it would be nice to allow a single NAL = unit packet to be a PACI payload too. - Re the following note: Why a larger field is desirable? Note: one of the authors' implementation experience suggests that a=20 larger field for TL0PICIDX may be desirable. The 8 bit field=20 proposed above is aligned with H.265's SEI message. =20 - The term "layer representation" used in the draft is not defined in HEVC = or draft-ietf-payload-rtp-h265-01. It should be replaced with "picture". - "Nal unit" in the semantics of the E bit should be changed to "NAL unit". BR, YK > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Stephan Wenger > Sent: Thursday, September 26, 2013 1:19 PM > To: payload@ietf.org > Cc: Jonathan Lennox; Jill Boyce > Subject: [payload] FW: New Version Notification for draft-wenger-payload- > h265-payload-header-extension-00.txt >=20 > Hi all, >=20 > In Berlin's payload session presentation of the H.265 payload format > (graciously hosted by AVTcore), I mentioned that we want to include suppo= rt > for temporal scalability in the draft H.265 payload format. > Attached a quick draft showing how this could be done--basically a (we > believe) improved variant of the PACSI NAL unit of RFC 6190. There are t= wo > alternative proposals in the draft, trading off alignment with design pri= nciples > of H.265 one one side and efficiency on the other. >=20 > Vidyo has IPR on this draft, which we will make available under terms lik= e > this: https://datatracker.ietf.org/ipr/1622/. I believe that the concept= s of this > draft should be included in the H.265 payload format itself, rather than = being > stand-alone. Once that happens, or if the group decides the draft to sta= y > stand-alone, we will file the official IPR disclosure against the then-cu= rrent > and appropriate document, so not to clutter the database. >=20 > Comments welcome. >=20 > Thanks, > Stephan >=20 >=20 >=20 > On 9.26.2013 13:08 , "internet-drafts@ietf.org" > wrote: >=20 > > > >A new version of I-D, > >draft-wenger-payload-h265-payload-header-extension-00.txt > >has been successfully submitted by Stephan Wenger and posted to the > >IETF repository. > > > >Filename: draft-wenger-payload-h265-payload-header-extension > >Revision: 00 > >Title: H.265 Payload Header Extension and Temporal Scalability > Support > >Creation date: 2013-09-26 > >Group: Individual Submission > >Number of pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-wenger-payload-h265-payload-h > >ead > >er-extension-00.txt > >Status: > >http://datatracker.ietf.org/doc/draft-wenger-payload-h265-payload-heade > >r-e > >xtension > >Htmlized: > >http://tools.ietf.org/html/draft-wenger-payload-h265-payload-header-ext > >ens > >ion-00 > > > > > >Abstract: > > Proposed are the allocation of a NAL unit type from the > > "unspecified" set of NAL units of H.265 [HEVC] for the purpose of > > payload header extensions, a generic syntax for the use of that > > pseudo NAL unit, and one application for it: the signaling of > > temporal scalability support information. Two alternative designs > > are included. The content of this draft is intended for > > incorporation into the H.265 RTP payload [h265-payload]. > > > > > > > > > > > > > > > >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. > > > >The IETF Secretariat > > >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Wed Oct 9 09:08:53 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89D21F9EAE; Wed, 9 Oct 2013 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uP+aaXrj054; Wed, 9 Oct 2013 09:08:42 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 12E7521F9B9F; Wed, 9 Oct 2013 09:07:19 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1273361pab.27 for ; Wed, 09 Oct 2013 09:07:18 -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=f7B2TOUpkGL8TTxJ9tvv0uTa64DB9G/QfBzCu49XyHg=; b=PfFXkdWJkxgiGWoYE+sQZnuu29XtpmPH6rfnxdhaB1UmNxl+tRPtlZa+40cYBJJTwW uOYcvRmd/D0vTVS32hNRb/6DOEQPtEiO7s3CUGOl+OiNBHvNHikmASByj8xpJs48aM4c RZeUQP7HRgyWCWS8SBt4Uc/b36OSqUbn1ei6Ck2tVuvoH75P9NZN5nl3LvZin7/SRVhS fexqi9w6GhyP9ApPaUpaUmtbL9Alu4m4AzT/5o9tjQKjf8Sbw7PIT1S4Cpc2aZ2gFPe5 Ozkv5HAxInbT7YApOyaXf18MfLAtFkp6FyVoUNFkNsbpU+c5pNPaQQLvqth1SEOwipAP lsQA== X-Received: by 10.68.28.36 with SMTP id y4mr2498131pbg.201.1381334838684; Wed, 09 Oct 2013 09:07:18 -0700 (PDT) Received: from RoniE ([59.37.12.1]) by mx.google.com with ESMTPSA id ye1sm55861864pab.19.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 09:07:17 -0700 (PDT) From: "Roni Even" To: Date: Wed, 9 Oct 2013 19:04:04 +0300 Message-ID: <007e01cec509$32acb540$98061fc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01CEC522.57FAB090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7FBop7wk2pTVLoSW2aKCqf/0iaxw== Content-Language: en-us Cc: payload@ietf.org Subject: [payload] AVTcore at IETF88 - agenda time requests X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2013 16:08:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01CEC522.57FAB090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. We may allocate some agenda time to payload based on available time avtcore Session Thursday , afternoon session II 15:20 - 17:20 Room Name: Regency C Some important dates: * 2013-10-11 (Friday): Final agenda to be published. * 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool . * 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . * 2013-10-25 (Friday): Early Bird registration and payment cut-off at UTC 24:00. * 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_007F_01CEC522.57FAB090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time. We may allocate some agenda time = to payload based on available time

 

    avtcore Session =

Thursday  , afternoon = session II 15:20 – 17:20

    Room Name: Regency = C

 

       =

Some important = dates:

 

  • 2013-10-11 = (Friday): Final = agenda to be published.
  • 2013-10-21 = (Monday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 24:00, = upload using IETF ID Submission = Tool.
  • 2013-10-23 = (Wednesday): Draft = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.
  • 2013-10-25 = (Friday): Early Bird = registration and payment cut-off at UTC 24:00.
  • 2013-10-28 = (Monday): Revised = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore = chair

------=_NextPart_000_007F_01CEC522.57FAB090-- From harald@alvestrand.no Thu Oct 10 04:29:07 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6521E8107 for ; Thu, 10 Oct 2013 04:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv5oFFyC4oq6 for ; Thu, 10 Oct 2013 04:29:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E421E80F1 for ; Thu, 10 Oct 2013 04:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D242C39EA19; Thu, 10 Oct 2013 13:29:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr82LwQcLM3J; Thu, 10 Oct 2013 13:29:00 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1A0C739E9DE; Thu, 10 Oct 2013 13:29:00 +0200 (CEST) Message-ID: <52568F7A.9070108@alvestrand.no> Date: Thu, 10 Oct 2013 13:28:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Roni Even , payload@ietf.org References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <520B7AEB.9080100@xiph.org> <520CE3D2.1070306@alvestrand.no> <04d801cea4a2$77652e60$662f8b20$@gmail.com> In-Reply-To: <04d801cea4a2$77652e60$662f8b20$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 11:29:07 -0000 Version -10 is now submitted. After discussing for a while internally what the default value should be, we reached the opposite conclusion of our first one: It is easier to accomodate future change if we make these parameters mandatory. So -10 has them as mandatory. Please review and comment if the language is adequate! Harald From rlb@ipv.sx Thu Oct 10 12:48:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3B21F9A3D for ; Thu, 10 Oct 2013 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn3r1MButxjX for ; Thu, 10 Oct 2013 12:48:09 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id AA58A11E81C1 for ; Thu, 10 Oct 2013 12:45:13 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so2085442obc.12 for ; Thu, 10 Oct 2013 12:45:09 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HN1dEC/NMK7mKe4C5b8D6mO5Rp5wVxv++7IYIHZsMB8=; b=F6UPReCKjSfhJg5CO1yaO14KpMkFQcf0hHSy0OlpZ6v4CO5fHwDQPRa1bUTKYM64dE oYTqRTmQztlbS8UtR0MIy7RhyYEPMnnjkQAD6WaGpVAt1jGy9kQBgq2jBco9aKI3Qn6O vk0a6zK8XcD12ODJfQrc+Xqu5XOWK07M7NItC1sbUfYd0f4ppq8vSQRwn/7+fiGk84wl zaBK7LpAay+2MFK3frf6vuUOz+tX7Hd9WiPQGVCvlSsvw09DyXbLxLUkScMy40YOH1yn HNbOuoR4J7hmxsEsFEQ36ZLmuxuI5cGDfkDw7iPVbhEXykWT18gddCjLvd2N2a11vcGp NwMA== X-Gm-Message-State: ALoCoQldQDodMiXO8PpJo/xf23DEzLdyCGKf9dZm2SwIAl32sjROdGu/XbpnKvvobjXK+Sn/XosL MIME-Version: 1.0 X-Received: by 10.60.76.72 with SMTP id i8mr11207623oew.11.1381434309360; Thu, 10 Oct 2013 12:45:09 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Thu, 10 Oct 2013 12:45:09 -0700 (PDT) In-Reply-To: <20130826162642.54E0B8E018@rfc-editor.org> References: <20130826162642.54E0B8E018@rfc-editor.org> Date: Thu, 10 Oct 2013 15:45:09 -0400 Message-ID: From: Richard Barnes To: RFC Errata System Content-Type: multipart/alternative; boundary=047d7b33d5484a58cb04e8683da1 X-Mailman-Approved-At: Thu, 10 Oct 2013 13:13:42 -0700 Cc: yekui.wang@huawei.com, "payload@ietf.org" , ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 19:48:29 -0000 --047d7b33d5484a58cb04e8683da1 Content-Type: text/plain; charset=ISO-8859-1 Do any PAYLOAD folks have a comment on this? This seems like a pretty major erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC6190, > "RTP Payload Format for Scalable Video Coding". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711 > > -------------------------------------- > Type: Technical > Reported by: Xiaohui Wei (Joanne) > > Section: 1.1.3 > > Original Text > ------------- > N: 1 bit > no_inter_layer_pred_flag. This flag specifies, when present in > a coded slice NAL unit, whether inter-layer prediction may be > used for decoding the coded slice (when equal to 1) or not > (when equal to 0). > > Corrected Text > -------------- > N: 1 bit > no_inter_layer_pred_flag. This flag specifies, when present in > a coded slice NAL unit, whether inter-layer prediction may be > used for decoding the coded slice (when equal to 0) or not > ^ > (when equal to 1). > ^ > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6190 (draft-ietf-avt-rtp-svc-27) > -------------------------------------- > Title : RTP Payload Format for Scalable Video Coding > Publication Date : May 2011 > Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis > Category : PROPOSED STANDARD > Source : Audio/Video Transport Payloads > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > --047d7b33d5484a58cb04e8683da1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do any PAYLOAD folks have a comment on this? =A0This seems= like a pretty major erratum, if correct.

Thanks,
<= div>--Richard


On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System <<= a href=3D"mailto:rfc-editor@rfc-editor.org" target=3D"_blank">rfc-editor@rf= c-editor.org> wrote:
The following errata report has been submitted for RFC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6190&eid=3D3711

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <wei= x@avaya.com>

Section: 1.1.3

Original Text
-------------
=A0 =A0N: =A0 =A01 bit
=A0 =A0 =A0 =A0 =A0no_inter_layer_pred_flag. =A0This flag specifies, when p= resent in
=A0 =A0 =A0 =A0 =A0a coded slice NAL unit, whether inter-layer prediction m= ay be
=A0 =A0 =A0 =A0 =A0used for decoding the coded slice (when equal to 1) or n= ot
=A0 =A0 =A0 =A0 =A0(when equal to 0).

Corrected Text
--------------
=A0 =A0N: =A0 =A01 bit
=A0 =A0 =A0 =A0 =A0no_inter_layer_pred_flag. =A0This flag specifies, when p= resent in
=A0 =A0 =A0 =A0 =A0a coded slice NAL unit, whether inter-layer prediction m= ay be
=A0 =A0 =A0 =A0 =A0used for decoding the coded slice (when equal to 0) or n= ot
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0(when equal to 1).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : RTP Payload Format for Scalable Video C= oding
Publication Date =A0 =A0: May 2011
Author(s) =A0 =A0 =A0 =A0 =A0 : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleft= heriadis
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Audio/Video Transport Payloads
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Real-time Applications and Infrastruc= ture
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG

--047d7b33d5484a58cb04e8683da1-- From yekuiw@qti.qualcomm.com Thu Oct 10 20:45:31 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8821E819F for ; Thu, 10 Oct 2013 20:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.148 X-Spam-Level: X-Spam-Status: No, score=-105.148 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEIQWiq6q5oV for ; Thu, 10 Oct 2013 20:45:15 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0611E8115 for ; Thu, 10 Oct 2013 20:45:06 -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=1381463106; x=1412999106; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v4uDqea+CO+CB5Wy6Ojrw4lKc5c0zXkxj0qbt2qtAgA=; b=MhjC8OpSaCebjhEmUxDoRH32aflN1Z9pjipSVYtTTazCTmEVt123wQJQ IcRLFOdO8D912xz3rNb6Xq6Or0CEsXEudbIXdNgFMNC/5XY7lT9fpgsK/ ecuiB+TIlGUWe92SyW6hzWAa7pvDbH+L1Vn6zK+00R1EELoZ/lfAwDcFD E=; X-IronPort-AV: E=McAfee;i="5400,1158,7224"; a="80243712" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 10 Oct 2013 20:45:06 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7224"; a="531665633" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Oct 2013 20:45:04 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.158]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.03.0158.001; Thu, 10 Oct 2013 20:45:03 -0700 From: "Wang, Ye-Kui" To: Richard Barnes , RFC Errata System Thread-Topic: [payload] [Technical Errata Reported] RFC6190 (3711) Thread-Index: AQHOonnvCEDPrF6dvUOMNHeKrvvlvpnvEtiAgAAPoIA= Date: Fri, 11 Oct 2013 03:45:03 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> References: <20130826162642.54E0B8E018@rfc-editor.org> In-Reply-To: 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: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83385B3410nasanexd02fnaqu_" MIME-Version: 1.0 Cc: "ts@thomas-schierl.de" , "payload@ietf.org" Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 03:45:31 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83385B3410nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The erratum is correct, though to me it is obviously a (relatively minor) t= ypo. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty majo= r erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System > wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) > Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG --_000_8BA7D4CEACFFE04BA2D902BF11719A83385B3410nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The erratum is correct, t= hough to me it is obviously a (relatively minor) typo.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

 

Do any PAYLOAD folks have a comment on this?  T= his seems like a pretty major erratum, if correct.

 

Thanks,

--Richard

 

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System = <rfc-edit= or@rfc-editor.org> wrote:

The following errata report has been submitted for R= FC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6190&eid=3D3711

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <wei= x@avaya.com>

Section: 1.1.3

Original Text
-------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 1) or not
         (when equal to 0).

Corrected Text
--------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 0) or not
                     = ;                     &nb= sp;               ^
         (when equal to 1).
                     = ;   ^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27)
--------------------------------------
Title               : RTP Payload Format= for Scalable Video Coding
Publication Date    : May 2011
Author(s)           : S. Wenger, Y.-K. Wang, T. Sc= hierl, A. Eleftheriadis
Category            : PROPOSED STANDARD
Source              : Audio/Video Transp= ort Payloads
Area                : Real-time App= lications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83385B3410nasanexd02fnaqu_-- From alex@vidyo.com Thu Oct 10 22:58:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E882F21F96EF for ; Thu, 10 Oct 2013 22:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9P8v7AQDnQm for ; Thu, 10 Oct 2013 22:57:59 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED6921E80B1 for ; Thu, 10 Oct 2013 22:57:55 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/11/2013 1:57:53 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: alex@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-55/SG:5 10/11/2013 1:57:22 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=1 p=-0.976129 Source White X-Signature-Violations: 0-0-0-17489-c X-Note-419: 15.6004 ms. Fail:1 Chk:1347 of 1347 total X-Note: SCH-CT/SI:1-1347/SG:1 10/11/2013 1:57:41 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: X-Note-Return-Path: alex@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 64141662; Fri, 11 Oct 2013 01:57:53 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 00:57:52 -0500 From: Alex Eleftheriadis To: "Wang, Ye-Kui" Thread-Topic: [payload] [Technical Errata Reported] RFC6190 (3711) Thread-Index: AQHOxfFDdcZCLstASUCW/FLiS46dPZnvMHiA///RSfM= Date: Fri, 11 Oct 2013 05:57:51 +0000 Message-ID: <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> References: <20130826162642.54E0B8E018@rfc-editor.org> , <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_70DC7CFEF7CE4FD6BD623911BDE33959vidyocom_" MIME-Version: 1.0 Cc: "ts@thomas-schierl.de" , "payload@ietf.org" , RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 05:58:04 -0000 --_000_70DC7CFEF7CE4FD6BD623911BDE33959vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree; the intended interpretation of the flag is evident by its name. It= should, however, be marked as an error. --AE On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" > wrote: The erratum is correct, though to me it is obviously a (relatively minor) t= ypo. BR, YK From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty majo= r erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System > wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) > Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_70DC7CFEF7CE4FD6BD623911BDE33959vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree; the intended interpretation of the flag is evident by its nam= e. It should, however, be marked as an error. 

--AE

On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

The erratum is correct, t= hough to me it is obviously a (relatively minor) typo.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [<= a href=3D"mailto:payload-bounces@ietf.org">mailto:payload-bounces@ietf.org<= /a>] On Behalf Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-sch= ierl.de
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

 

Do any PAYLOAD folks have a comment on this?  T= his seems like a pretty major erratum, if correct.

 

Thanks,

--Richard

 

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System = <rfc-edit= or@rfc-editor.org> wrote:

The following errata report has been submitted for R= FC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6190&eid=3D3711

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <wei= x@avaya.com>

Section: 1.1.3

Original Text
-------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 1) or not
         (when equal to 0).

Corrected Text
--------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 0) or not
                     = ;                     &nb= sp;               ^
         (when equal to 1).
                     = ;   ^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27)
--------------------------------------
Title               : RTP Payload Format= for Scalable Video Coding
Publication Date    : May 2011
Author(s)           : S. Wenger, Y.-K. Wang, T. Sc= hierl, A. Eleftheriadis
Category            : PROPOSED STANDARD
Source              : Audio/Video Transp= ort Payloads
Area                : Real-time App= lications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

 

_______________________________________________
payload mailing list
payload@ietf.org
https://www= .ietf.org/mailman/listinfo/payload
--_000_70DC7CFEF7CE4FD6BD623911BDE33959vidyocom_-- From ron.even.tlv@gmail.com Thu Oct 10 23:53:09 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28311E80E4 for ; Thu, 10 Oct 2013 23:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOWKVH69RWJm for ; Thu, 10 Oct 2013 23:53:08 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 78EAA21F9CA0 for ; Thu, 10 Oct 2013 23:53:07 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so3775918pbb.10 for ; Thu, 10 Oct 2013 23:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=tQHrFR38Joo5em3onzEfmUbxeu2qv4NlwOh7G1RnkJw=; b=FUv8dwHjR3XhwCO901o4t6czdzN0ndgij0W8gQhhFVx17M3krCD4ZQdOiPrJaGAqc2 NGvGNDLMUnGKLqbWZFJKj4xi7OgAFjiKl7Byv6C/DrF06C+VpQRKckQCafH5oKb5FuIs wwVDVlkxhDkgH5NfObYGtX+DXJCf9wDHRMUugXa3yyVoAwRlcSm1hbYNAknIwtWjsYQs ansSIdr6EfCS/yUAyqIyukOBPbgo76l3MKqsPkMquLe5BPGNdWEXyM0LMvoDEJ0Oqu4O ubXZyGJF12P7CozIraNDk6BB0wzeYe1OPIhiNGkyXHSkOCoiDd+irDgEtjPndB9I0+H+ Ssxg== X-Received: by 10.68.162.5 with SMTP id xw5mr18334850pbb.71.1381474387088; Thu, 10 Oct 2013 23:53:07 -0700 (PDT) Received: from RoniE ([60.247.108.2]) by mx.google.com with ESMTPSA id tx5sm57667406pbc.29.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Oct 2013 23:53:06 -0700 (PDT) From: "Roni Even" To: "'Alex Eleftheriadis'" , "'Wang, Ye-Kui'" References: <20130826162642.54E0B8E018@rfc-editor.org> , <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> In-Reply-To: <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> Date: Fri, 11 Oct 2013 09:49:56 +0300 Message-ID: <008901cec64e$1c865f00$55931d00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01CEC667.41D96360" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdSdvxMif5AQ4btCbVHo1UALZuogLg7UtLAfkiqTEB9nFqWpmbg3pA Content-Language: en-us Cc: ts@thomas-schierl.de, payload@ietf.org, 'RFC Errata System' Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 06:53:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01CEC667.41D96360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since I saw feedback from Alex and Ye-Kui, I am wondering what the implementation are currently doing. Even though it make sense to change the current meaning I do not think it is wrong to keep the current values if was implemented this way. Thanks Roni Even Payload WG co-chair From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Alex Eleftheriadis Sent: 11 October, 2013 8:58 AM To: Wang, Ye-Kui Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) I agree; the intended interpretation of the flag is evident by its name. It should, however, be marked as an error. --AE On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" wrote: The erratum is correct, though to me it is obviously a (relatively minor) typo. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty major erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6190 &eid=3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_NextPart_000_008A_01CEC667.41D96360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since I saw feedback from Alex and Ye-Kui,  I am wondering what = the  implementation are currently doing.

Even though it make sense to change the current meaning I do not = think it is wrong to keep the current values if was implemented this = way.

Thanks

Roni Even

Payload WG co-chair

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Alex Eleftheriadis
Sent: 11 October, 2013 8:58 = AM
To: Wang, Ye-Kui
Cc: ts@thomas-schierl.de; = payload@ietf.org; RFC Errata System
Subject: Re: [payload] = [Technical Errata Reported] RFC6190 = (3711)

 

I = agree; the intended interpretation of the flag is evident by its name. = It should, however, be marked as an = error. 

--AE


On Oct 11, 2013, at 4:45 AM, = "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> = wrote:

The erratum is correct, though to me it is obviously a (relatively = minor) typo.

 

BR, YK

 

 

Do any = PAYLOAD folks have a comment on this?  This seems like a pretty = major erratum, if correct.

 

Thanks,

--Richard

 

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System = <rfc-editor@rfc-editor.org> = wrote:

The following errata report = has been submitted for RFC6190,
"RTP Payload Format for Scalable = Video Coding".

--------------------------------------
You = may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6190&= amp;eid=3D3711

--------------------------------------
Type:= Technical
Reported by: Xiaohui Wei (Joanne) <weix@avaya.com>

Section: = 1.1.3

Original Text
-------------
   N:   =  1 bit
        =  no_inter_layer_pred_flag.  This flag specifies, when present = in
         a coded slice NAL unit, whether = inter-layer prediction may be
         used = for decoding the coded slice (when equal to 1) or not
    =      (when equal to 0).

Corrected = Text
--------------
   N:    1 bit
  =        no_inter_layer_pred_flag.  This flag = specifies, when present in
         a coded = slice NAL unit, whether inter-layer prediction may be
    =      used for decoding the coded slice (when equal to 0) = or not
                  =                     =                     = ^
         (when equal to 1).
  =                     =   = ^

Notes
-----


Instructions:
-------------
This= errata is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the verifying party = (IESG)
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC6190 = (draft-ietf-avt-rtp-svc-27)
--------------------------------------
= Title               : RTP Payload = Format for Scalable Video Coding
Publication Date    : May = 2011
Author(s)           : S. Wenger, Y.-K. = Wang, T. Schierl, A. Eleftheriadis
Category       =      : PROPOSED STANDARD
Source       =        : Audio/Video Transport Payloads
Area =                : Real-time = Applications and Infrastructure
Stream         =      : IETF
Verifying Party     : = IESG

 

_______________________________________________
payl= oad mailing list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload

------=_NextPart_000_008A_01CEC667.41D96360-- From internet-drafts@ietf.org Fri Oct 11 02:28:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8CC21E8143; Fri, 11 Oct 2013 02:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HQDAcl5fnea; Fri, 11 Oct 2013 02:28:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A511E8142; Fri, 11 Oct 2013 02:28:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011092811.4914.9082.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 02:28:11 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-08.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 09:28:12 -0000 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 : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-08.txt Pages : 58 Date : 2013-10-11 Abstract: This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-08 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 magnus.westerlund@ericsson.com Fri Oct 11 02:39:36 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5021F9FB1 for ; Fri, 11 Oct 2013 02:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGo+9+vM0TUw for ; Fri, 11 Oct 2013 02:39:32 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4EE21E80C1 for ; Fri, 11 Oct 2013 02:39:31 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-84-5257c746fe22 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 81.35.25272.647C7525; Fri, 11 Oct 2013 11:39:18 +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.2.328.9; Fri, 11 Oct 2013 11:39:18 +0200 Message-ID: <5257C78B.8070303@ericsson.com> Date: Fri, 11 Oct 2013 11:40:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "payload@ietf.org" References: <20131011092811.4914.9082.idtracker@ietfa.amsl.com> In-Reply-To: <20131011092811.4914.9082.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvra7b8fAgg52/rSwuXTzL5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPW/b7EWTFKu+PH1JFMD4wnpLkZODgkBE4nmLX2MELaYxIV7 69m6GLk4hASOMkpMm3KKBcJZzigxfclDsCpeAW2J/Yc+gNksAqoS0zd+Ygex2QQsJG7+aGQD sUUFgiXat39lg6gXlDg58wnQIA4OEQFNiUffhUDCwgI2EvenQZQICdhLnJ38mhnE5hRwkNiy 9DErxEGSEtsWHQMbzyygJzHlagsjhC0v0bx1NjNEr7ZEQ1MH6wRGwVlIts1C0jILScsCRuZV jBzFqcVJuelGBpsYgQF4cMtvix2Ml//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAPjfZ2KK/3h+g/K7qrqbJz0ffn+Xo/7RyZPcG30kv+tnlv412YzV5FjyomuMN6g HZ2Xnuiff8IcI1g2r0Blyxz51KtsUy6I7bLeWGB4qYGd9//hNHXLzBXznG2uflS/77lIwbXK +dD3/fkVx5e583u0PjP1ySr/tOLZ1FwT04innmYx6t9fNn1SYinOSDTUYi4qTgQAaiE95w4C AAA= Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-08.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 09:39:36 -0000 WG, This update is triggered by comments I received from the shepherd (Ali) as result of my request for publication. It is mostly editorials. I want to point out the few parts where the meaning of the text has been changed: Section 3.2.2 FEC Framework: The Forward Error Correction (FEC) Framework [RFC6363] defines how to use FEC protection for arbitrary packet flows. This framework can be applied for RTP/RTCP packet flows, including using RTP for transmission of repair symbols, an example is the RTP Payload for Raptor FEC [RFC6682]. RTP Retransmission: The RTP retransmission scheme [RFC4588] is used for semi-reliability of the most important RTP packets in a media stream. The level of reliability between semi and in practice full reliability depends on the targeted properties and situation where paramters such as round-trip time (RTT) allowed additional overhead, and allowable delay. It often requires the application to be quite delay tolerant as a minimum of one round-trip time plus processing delay is required to perform a retransmission. Thus it is mostly suitable for streaming applications but may also be usable in certain other cases when operating in networks with short round-trip times. RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of a framework for reports sent within RTCP. It can easily be extended by defining new report formats, which has and is occuring. The XRBLOCK WG in IETF is chartered (at the time of writing) with defining new report formats. The list of specified formats are available in IANA's RTCP XR Block Type registry (http: //www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block- types.xhtml). The report formats that are defined in RFC3611 provide report information on packet loss, packet duplication, packet reception times, RTCP statistics summary and VoIP Quality. [RFC3611] also defines a mechanism that allows receivers to calculate the RTT to other session participants when used. The spelling errors (paramters, and occuring) has been fixed in my source and will be fixed in the next submission. Cheers Magnus On 2013-10-11 11:28, internet-drafts@ietf.org wrote: > > 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 : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-08.txt > Pages : 58 > Date : 2013-10-11 > > Abstract: > This document contains information on how to best write an RTP > payload format specification. It provides reading tips, design > practices, and practical tips on how to produce an RTP payload format > specification quickly and with good results. A template is also > included with instructions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-08 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 abegen@cisco.com Fri Oct 11 06:59:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C5711E81B3 for ; Fri, 11 Oct 2013 06:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKsDFCydogoQ for ; Fri, 11 Oct 2013 06:59:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E400921F9C72 for ; Fri, 11 Oct 2013 06:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=819; q=dns/txt; s=iport; t=1381499952; x=1382709552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=I0VNc7G1NdxgXyiPMBBH37dMKxW6g/a4Xzcw7lltXuQ=; b=dCg19o1gnw6iWmYK+h0SrLqIrkRAvFBbZ6WNqBYvMrS3gZHojp3NNipv UC6hxXmQR1gPdMF4cnaEhkMYSTEYKk5mP1TaD8JSMZwX0xFqCUUc4Z9oo dYaGzoU40WRMNSh2Ky9t1+/gA1bJZnWjPYlEQmeUsCkGpv/CW9sAihyuZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFALwDWFKtJV2Z/2dsb2JhbABZgmYhOFLBBUuBIxZtB4ImAQEEAQEBNzQLEAIBCCIUECcLJQIEDgUIh34BC7sOBI8UAjEHgx+BBAOqB4Mkgio X-IronPort-AV: E=Sophos;i="4.90,1081,1371081600"; d="scan'208";a="271061757" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2013 13:59:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9BDxC6K016441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 13:59:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 08:59:11 -0500 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: AQHOst3GQJ5PwGEhn0qLtw2WH9fA5ZnwAjgA Date: Fri, 11 Oct 2013 13:59:11 +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.154.36.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-payload-rtp-aptx@tools.ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 13:59:28 -0000 There have been some comments in the list and authors seem to have adequate= ly addressed these in the list. Authors, please submit a revision (the cutoff is in a few days) so that we = can move on. -acbegen (as WG co-chair) On Sep 16, 2013, at 6:08 AM, Ali C. Begen (abegen) wrote= : > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 01).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >=20 > It is a short document. If you have comments, agreements or disagreements= , please let the list know in either case. >=20 > The deadline for the WGLC is September 30th. >=20 > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Fri Oct 11 08:12:00 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D721E8082 for ; Fri, 11 Oct 2013 08:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9rpf9WNzxqN for ; Fri, 11 Oct 2013 08:11:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3911E817A for ; Fri, 11 Oct 2013 08:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6214; q=dns/txt; s=iport; t=1381504315; x=1382713915; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=meMEKxcCPd0J31w/8oi6VPhhEx/OSC4wwg4GLS8kSt4=; b=HcthE7AgE5xy/NwXp2bUZ2Eb+tI1950gGpX7I5sSjHZjJgPvgbwegUop phPCGJwxDMZmRDBed4uLrHExrNsutcmlYHdWW5ceAiI9JZpz7z2E6iWd2 GFtYNNWF0JLat1gzfaK0ckf73el7LMiXE2qYdsejqImem59d15yQcCqlw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACQUWFKtJXHA/2dsb2JhbABPCoJmIThSwVCBIxZ0gicBBDoxBwIFEgEWFBRCJwQODQGHfQELuwiNfgaBEjGDJoEEA6oHgySBagcXBhw X-IronPort-AV: E=Sophos;i="4.90,1081,1371081600"; d="scan'208";a="271091462" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2013 15:11:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9BFBsvk029271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 15:11:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 10:11:54 -0500 From: "Ali C. Begen (abegen)" To: Richard Barnes Thread-Topic: Publication request for draft-ietf-payload-rtp-howto-08 Thread-Index: AQHOxpQ43uynBI2qz02tZTUjih+xdw== Date: Fri, 11 Oct 2013 15:11:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.36.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: [payload] Publication request for draft-ietf-payload-rtp-howto-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 15:12:00 -0000 Hi Richard, I am requesting the publication of the draft above. Here is the write-up. Thanks, -acbegen (WG co-chair) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational as indicated in the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes guidelines for people who would like to write an RT= P payload format specification. There have been changes in this process and= this document describes the latest. A document template is also provided. Working Group Summary The document received several reviews on various parts and as a whole. Ther= e have been quite a big number of improvements over time, both editorially = and technically. Document Quality This document is informational, so does not require an implementation. Seve= ral people who have written payload format specs before reviewed the materi= al carefully. Personnel Ali Begen is the document shepherd and Richard Barnes is the responsible AD= . (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There were a number of review stages. The document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? =20 No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. No IPR disclosures are needed and none were submitted. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20 Full WG support. (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits tool lists a few things. There is no 2119 keyword usage in this doc= ument as explained in the header. The=20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no such reviews needed. (13) Have all references within this document been identified as either normative or informative? They are all informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No normative reference exists. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in=20 the Last Call procedure.=20 N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No replacement of an existing document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA considerations here. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None was performed as it was not needed.= From jonathan@vidyo.com Fri Oct 11 08:40:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CB321E8189 for ; Fri, 11 Oct 2013 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSVpIQOz30tZ for ; Fri, 11 Oct 2013 08:40:45 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id D4B3221F9C40 for ; Fri, 11 Oct 2013 08:40:44 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/11/2013 11:40:43 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-45/SG:5 10/11/2013 11:40:41 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.959818 p=-0.964122 Source White X-Signature-Violations: 0-0-0-26771-c X-Note-419: 15.6003 ms. Fail:1 Chk:1347 of 1347 total X-Note: SCH-CT/SI:1-1347/SG:1 10/11/2013 11:40:41 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 39593106; Fri, 11 Oct 2013 11:40:43 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 10:40:42 -0500 From: Jonathan Lennox To: Roni Even Thread-Topic: [payload] [Technical Errata Reported] RFC6190 (3711) Thread-Index: AQHdSdvxMif5AQ4btCbVHo1UALZuogLg7UtLAfkiqTEB9nFqWpmbg3pAgADpEoA= Date: Fri, 11 Oct 2013 15:40:41 +0000 Message-ID: <31B495FC-06CA-43C3-AF15-5530D3D3E463@vidyo.com> References: <20130826162642.54E0B8E018@rfc-editor.org> , <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> <008901cec64e$1c865f00$55931d00$@gmail.com> In-Reply-To: <008901cec64e$1c865f00$55931d00$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_31B495FC06CA43C3AF155530D3D3E463vidyocom_" MIME-Version: 1.0 Cc: "" , "" , RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 15:40:49 -0000 --_000_31B495FC06CA43C3AF155530D3D3E463vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This error is in section 1.1.3 of RFC 6190, which explicitly states that it= is an summary of field definitions specified by the H.264 spec. Thus, I would hope (and expect) that most implementations are following the= H.264 definition of this bit, not the RFC 6190 definition. On Oct 11, 2013, at 2:49 AM, Roni Even > wrote: Since I saw feedback from Alex and Ye-Kui, I am wondering what the implem= entation are currently doing. Even though it make sense to change the current meaning I do not think it i= s wrong to keep the current values if was implemented this way. Thanks Roni Even Payload WG co-chair From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Alex Eleftheri= adis Sent: 11 October, 2013 8:58 AM To: Wang, Ye-Kui Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) I agree; the intended interpretation of the flag is evident by its name. It= should, however, be marked as an error. --AE On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" > wrote: The erratum is correct, though to me it is obviously a (relatively minor) t= ypo. BR, YK From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty majo= r erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System > wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) > Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ 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_31B495FC06CA43C3AF155530D3D3E463vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <87442E843D9B084F9E749F28D063140E@vidyo.com> Content-Transfer-Encoding: quoted-printable
This error is in section 1.1.3 of RFC 6190, which explicitly states th= at it is an summary of field definitions specified by the H.264 spec.

Thus, I would hope (and expect) that most implementations are followin= g the H.264 definition of this bit, not the RFC 6190 definition.

On Oct 11, 2013, at 2:49 AM, Roni Even <ron.even.tlv@gmail.com>
 wrote:

Since I saw feedback from Alex and Ye-Kui,  I am won= dering what the  implementation are currently doing.=
Even though it make sense to change the current meaning I= do not think it is wrong to keep the current values if was implemented thi= s way.
Thanks
Roni Even
Payload WG co-chair
 
From:=   <= /span>[mailto:payload-bounces@ietf.org] On Behalf Of Alex Eleft= heriadis
Sent: 11 October, = 2013 8:58 AM
To: Wang, Ye-Kui Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata System=
Subject: Re: [payl= oad] [Technical Errata Reported] RFC6190 (3711)
 
I agree; the intended interpretation of the flag is evident by its name. It= should, however, be marked as an error. 

--AE


On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

The erratum is correct, though to me it is obviously a (r= elatively minor) typo.
 
BR, YK
 
From:=   <= /span>[mailto:payload-bounces@ietf.org] On Behalf Of Richard Ba= rnes
Sent: Thursday, Oc= tober 10, 2013 12:45 PM
To: RFC Errata Sys= tem
Cc: yekui.wang@huawei.com; = ;payload@ietf.org; ts@thomas-schierl.de
Subject: Re: [payl= oad] [Technical Errata Reported] RFC6190 (3711)
 
Do any PAYLOAD folks have a comment on this?  This seems like a pretty= major erratum, if correct.
 
Thanks,
--Richard

 

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:<= /div>
The following errata report has been submitted for RFC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711=

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <weix@avaya.com>
Section: 1.1.3

Original Text
-------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 1) or not
         (when equal to 0).

Corrected Text
--------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 0) or not
                     = ;                     &nb= sp;               ^
         (when equal to 1).
                     = ;   ^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27)
--------------------------------------
Title               : RTP Payload Format= for Scalable Video Coding
Publication Date    : May 2011
Author(s)           : S. Wenger, Y.-K. Wang, T. Sc= hierl, A. Eleftheriadis
Category            : PROPOSED STANDARD
Source              : Audio/Video Transp= ort Payloads
Area                : Real-time App= lications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
 
_______________________________________________
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_31B495FC06CA43C3AF155530D3D3E463vidyocom_-- From yekuiw@qti.qualcomm.com Fri Oct 11 08:47:31 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659C221E8135 for ; Fri, 11 Oct 2013 08:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRpMCllbl0ll for ; Fri, 11 Oct 2013 08:47:27 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2721E81C3 for ; Fri, 11 Oct 2013 08:47:22 -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=1381506442; x=1413042442; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DGVawp7CdDfizBzm2y7wsqMJa6cpfL/At67xNPjhaao=; b=bJsqkEy2FsmzjuGWB/g8E34c19eiOll8WmN/eMKBK1fygMxEyh+utcQm 6yYz7l3BTSA99W1kG3rF6IdFxlMGzu9TIJcJATufncD5HGr1yrA5ntBev pYxEKt0yMQYGaRIb1ykOMp2qBeY9Yv9jVmiPnssCNXWJQKrkQPbRgb6TY o=; X-IronPort-AV: E=McAfee;i="5400,1158,7224"; a="54047156" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 11 Oct 2013 08:47:16 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7224"; a="21159109" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Oct 2013 08:47:16 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.158]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.03.0158.001; Fri, 11 Oct 2013 08:47:15 -0700 From: "Wang, Ye-Kui" To: Jonathan Lennox , Roni Even Thread-Topic: [payload] [Technical Errata Reported] RFC6190 (3711) Thread-Index: AQHOonnvCEDPrF6dvUOMNHeKrvvlvpnvEtiAgAAPoICAAJuQgIAADo0AgACUSoD//4tTYA== Date: Fri, 11 Oct 2013 15:47:15 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83385B4C3F@nasanexd02f.na.qualcomm.com> References: <20130826162642.54E0B8E018@rfc-editor.org> , <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> <008901cec64e$1c865f00$55931d00$@gmail.com> <31B495FC-06CA-43C3-AF15-5530D3D3E463@vidyo.com> In-Reply-To: <31B495FC-06CA-43C3-AF15-5530D3D3E463@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83385B4C3Fnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "" , "" , RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 15:47:31 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83385B4C3Fnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly - as it is just a summary of the field specified in the SVC spec, i= t is basically non-normative. Also, the fields in the 4-byte NAL unit header has been carefully designed = at JVT when SVC was developed, to avoid the possibility of certain bit patt= erns that are used as start codes in some systems. Considering all these factors, the errata should be approved (or whatever t= he right process is). BR, YK From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Friday, October 11, 2013 8:41 AM To: Roni Even Cc: Alex Eleftheriadis; Wang, Ye-Kui; ; ; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) This error is in section 1.1.3 of RFC 6190, which explicitly states that it= is an summary of field definitions specified by the H.264 spec. Thus, I would hope (and expect) that most implementations are following the= H.264 definition of this bit, not the RFC 6190 definition. On Oct 11, 2013, at 2:49 AM, Roni Even > wrote: Since I saw feedback from Alex and Ye-Kui, I am wondering what the implem= entation are currently doing. Even though it make sense to change the current meaning I do not think it i= s wrong to keep the current values if was implemented this way. Thanks Roni Even Payload WG co-chair From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Alex Eleftheri= adis Sent: 11 October, 2013 8:58 AM To: Wang, Ye-Kui Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) I agree; the intended interpretation of the flag is evident by its name. It= should, however, be marked as an error. --AE On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" > wrote: The erratum is correct, though to me it is obviously a (relatively minor) t= ypo. BR, YK From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty majo= r erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System > wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) > Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ 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_8BA7D4CEACFFE04BA2D902BF11719A83385B4C3Fnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Exactly – as it is = just a summary of the field specified in the SVC spec, it is basically non-= normative.

 <= /p>

Also, the fields in the 4= -byte NAL unit header has been carefully designed at JVT when SVC was devel= oped, to avoid the possibility of certain bit patterns that are used as start codes in some systems.

 <= /p>

Considering all these fac= tors, the errata should be approved (or whatever the right process is).

 <= /p>

BR, YK<= /p>

 <= /p>

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Friday, October 11, 2013 8:41 AM
To: Roni Even
Cc: Alex Eleftheriadis; Wang, Ye-Kui; <ts@thomas-schierl.de>; = <payload@ietf.org>; RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

 

This error is in section 1.1.3 of RFC 6190, which ex= plicitly states that it is an summary of field definitions specified by the= H.264 spec.

 

Thus, I would hope (and expect) that most implementa= tions are following the H.264 definition of this bit, not the RFC 6190 defi= nition.

 

On Oct 11, 2013, at 2:49 AM, Roni Even <ron.even.tlv@gmail.com>

 wrote:



Since I sa= w feedback from Alex and Ye-Kui,  I am wondering what the  implem= entation are currently doing.=

Even thoug= h it make sense to change the current meaning I do not think it is wrong to= keep the current values if was implemented this way.

Thanks

Roni Even<= /span>

Payload WG= co-chair

 

From: = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Alex Eleft= heriadis
Sent: 11 October, = 2013 8:58 AM
To: Wang, Ye-Kui Cc: ts@thomas-schierl.de= ; payload@ietf.org; RFC Errata System=
Subject: Re: [payl= oad] [Technical Errata Reported] RFC6190 (3711)=

 

I agree; the intended interpret= ation of the flag is evident by its name. It should, however, be marked as = an error. 

--AE

=
On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.= com> wrote:

The erratu= m is correct, though to me it is obviously a (relatively minor) typo.

 

BR, YK

 

From: = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Ba= rnes
Sent: Thursday, Oc= tober 10, 2013 12:45 PM
To: RFC Errata Sys= tem
Cc: yekui.wang@huawei.c= om; payload@ietf.org; ts@thomas-schierl.de
Subject: Re: [payl= oad] [Technical Errata Reported] RFC6190 (3711)=

 

Do any PAYLOAD folks have a com= ment on this?  This seems like a pretty major erratum, if correct.

 

Thanks,

--Richard

=  

On Mon, Aug 26, 2013 at 12:26 P= M, RFC Errata System <rfc-editor@rfc-editor.org<= /a>> wrote:

The following errata report has= been submitted for RFC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
You may review the report below and at:
http://www.rfc-edit= or.org/errata_search.php?rfc=3D6190&eid=3D3711

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <weix@avaya.com>

Section: 1.1.3

Original Text
-------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 1) or not
         (when equal to 0).

Corrected Text
--------------
   N:    1 bit
         no_inter_layer_pred_flag.  This flag= specifies, when present in
         a coded slice NAL unit, whether inter-lay= er prediction may be
         used for decoding the coded slice (when e= qual to 0) or not
                     = ;                     &nb= sp;               ^
         (when equal to 1).
                     = ;   ^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27)
--------------------------------------
Title               : RTP Payload Format= for Scalable Video Coding
Publication Date    : May 2011
Author(s)           : S. Wenger, Y.-K. Wang, T. Sc= hierl, A. Eleftheriadis
Category            : PROPOSED STANDARD
Source              : Audio/Video Transp= ort Payloads
Area                : Real-time App= lications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

 

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

______________________= _________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83385B4C3Fnasanexd02fnaqu_-- From fluffy@iii.ca Fri Oct 11 15:32:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060A21E809D; Fri, 11 Oct 2013 15:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY7SYGbTtsfm; Fri, 11 Oct 2013 15:32:10 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18521E8087; Fri, 11 Oct 2013 15:32:10 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AEFB922E1F3; Fri, 11 Oct 2013 18:32:02 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <520B77F5.4000800@alvestrand.no> Date: Fri, 11 Oct 2013 16:32:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2013 22:32:15 -0000 How do I signal that the max frame size I can receive is 640 x 480.=20 My preference as the answer to this question is to say that for VP8 (not = other codecs) you need to support a=3Dimageattr=20 On Aug 14, 2013, at 6:28 AM, Harald Alvestrand = wrote: > On 07/19/2013 10:17 PM, Cullen Jennings wrote: >> These can't be optional otherwise a device that is hardware limited = can't know that the other side will use them. Thus there is no way to = build solutions that interoperate by design instead of luck. >=20 >=20 > A device that has announced a=3Dimageattr:97 recv [x:640,y:480] and = a=3Dframerate:60 has stated that max-fr is >=3D 60 and that max-fs is >=3D= 1200. >=20 > These parameters were added because people on this list asked for = them. > So far, I do not think they have been added to any existing = implementation, and we don't seem to be seeing many interoperability = problems because of that. >=20 > I don't think this is because of "luck". I think it's because these = are not the constraints that are the most constraining in most practical = situations - other constraints make sure we never reach the limits that = might have been encoded using max-fr and max-fs. >=20 >=20 >> =20 >>=20 >> On Jul 17, 2013, at 7:06 AM, Harald Alvestrand = wrote: >>=20 >>> On 07/10/2013 10:28 PM, Stephan Wenger wrote: >>>> Hi, >>>> I read through the diff file. The main change seems to be to = reduce the >>>> PartitionID field by one bit, which is now reserved. This is fine. >>>> While reading through the diff file (without checking against the = main >>>> text--too lazy or too busy, take your choice :-), I noticed that = max_fr >>>> and max_fs are optional, and could not see a default being defined. >>> The theory is that there would be external constraints (such as an = application-wide configuration, or an out-of-SDP signalling mechanism) = that gave the constraints in question. >>>=20 >>> Quote from 6.2.2: >>>=20 >>> In many practical applications, the max frame size and >>> max frame rate are known from other information; if they are not >>> constrained by other means, the max-fs and max-fr parameters MUST = be >>> used to establish these limits. >>>=20 >>> We did not see a compelling reason to make non-compliant the present = applications that do not use these parameters. >>>=20 >>>=20 >>>=20 >>>> Is >>>> this prudent? How does a decoding system decide whether it is able = to >>>> decode a stream without any indication of the complexity of the = stream? >>>> Start decoding and reject once the header tells you that this = stream is >>>> beyond your capacity? >>>> Stephan >>>>=20 >>>> On 7.10.2013 08:50 , "internet-drafts@ietf.org" = >>>> wrote: >>>>=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 VP8 Video >>>>> Author(s) : Patrik Westin >>>>> Henrik F Lundin >>>>> Michael Glover >>>>> Justin Uberti >>>>> Frank Galligan >>>>> Filename : draft-ietf-payload-vp8-09.txt >>>>> Pages : 30 >>>>> Date : 2013-07-10 >>>>>=20 >>>>> Abstract: >>>>> This memo describes an RTP payload format for the VP8 video = codec. >>>>> The payload format has wide applicability, as it supports >>>>> applications from low bit-rate peer-to-peer usage, to high = bit-rate >>>>> video conferences. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-09 >>>>>=20 >>>>>=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 >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >=20 From harald@alvestrand.no Fri Oct 11 23:15:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9B21E80C2; Fri, 11 Oct 2013 23:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryf36uKCxYs5; Fri, 11 Oct 2013 23:14:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 052EB21E8096; Fri, 11 Oct 2013 23:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E1D039E175; Sat, 12 Oct 2013 08:14:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftIjlquzbuqT; Sat, 12 Oct 2013 08:14:55 +0200 (CEST) Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 058A439E125; Sat, 12 Oct 2013 08:14:55 +0200 (CEST) Message-ID: <5258E8DE.80304@alvestrand.no> Date: Sat, 12 Oct 2013 08:14:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Cullen Jennings References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 06:15:03 -0000 On 10/12/2013 12:32 AM, Cullen Jennings wrote: > How do I signal that the max frame size I can receive is 640 x 480. > > My preference as the answer to this question is to say that for VP8 (not other codecs) you need to support a=imageattr My preference is not to do this, and leave it as is. We suggested a solution based on an optional imageattr at first (-08 timeframe), but the comments by Stefan Wenger and Tim Terriberry led us to propose this solution instead - the comments we received were of type "either this solution or that solution", never "both solutions". The codec parameters are intended to guard against streams of too high complexity, because too complex streams might overload the decoder. We have not seen any indication up to now that there exist devices for which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not. There are many reasons to negotiate picture sizes, and the imageattr mechanism is available for doing so. But once max-fs is present and mandatory, I think it's not reasonable to require more mandatory parameters in order to avoid codec overruns. Can you live with the current version? Harald > > > > > On Aug 14, 2013, at 6:28 AM, Harald Alvestrand wrote: > >> On 07/19/2013 10:17 PM, Cullen Jennings wrote: >>> These can't be optional otherwise a device that is hardware limited can't know that the other side will use them. Thus there is no way to build solutions that interoperate by design instead of luck. >> >> A device that has announced a=imageattr:97 recv [x:640,y:480] and a=framerate:60 has stated that max-fr is >= 60 and that max-fs is >= 1200. >> >> These parameters were added because people on this list asked for them. >> So far, I do not think they have been added to any existing implementation, and we don't seem to be seeing many interoperability problems because of that. >> >> I don't think this is because of "luck". I think it's because these are not the constraints that are the most constraining in most practical situations - other constraints make sure we never reach the limits that might have been encoded using max-fr and max-fs. >> >> >>> >>> >>> On Jul 17, 2013, at 7:06 AM, Harald Alvestrand wrote: >>> >>>> On 07/10/2013 10:28 PM, Stephan Wenger wrote: >>>>> Hi, >>>>> I read through the diff file. The main change seems to be to reduce the >>>>> PartitionID field by one bit, which is now reserved. This is fine. >>>>> While reading through the diff file (without checking against the main >>>>> text--too lazy or too busy, take your choice :-), I noticed that max_fr >>>>> and max_fs are optional, and could not see a default being defined. >>>> The theory is that there would be external constraints (such as an application-wide configuration, or an out-of-SDP signalling mechanism) that gave the constraints in question. >>>> >>>> Quote from 6.2.2: >>>> >>>> In many practical applications, the max frame size and >>>> max frame rate are known from other information; if they are not >>>> constrained by other means, the max-fs and max-fr parameters MUST be >>>> used to establish these limits. >>>> >>>> We did not see a compelling reason to make non-compliant the present applications that do not use these parameters. >>>> >>>> >>>> >>>>> Is >>>>> this prudent? How does a decoding system decide whether it is able to >>>>> decode a stream without any indication of the complexity of the stream? >>>>> Start decoding and reject once the header tells you that this stream is >>>>> beyond your capacity? >>>>> Stephan >>>>> >>>>> On 7.10.2013 08:50 , "internet-drafts@ietf.org" >>>>> wrote: >>>>> >>>>>> 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 VP8 Video >>>>>> Author(s) : Patrik Westin >>>>>> Henrik F Lundin >>>>>> Michael Glover >>>>>> Justin Uberti >>>>>> Frank Galligan >>>>>> Filename : draft-ietf-payload-vp8-09.txt >>>>>> Pages : 30 >>>>>> Date : 2013-07-10 >>>>>> >>>>>> Abstract: >>>>>> This memo describes an RTP payload format for the VP8 video codec. >>>>>> The payload format has wide applicability, as it supports >>>>>> applications from low bit-rate peer-to-peer usage, to high bit-rate >>>>>> video conferences. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-09 >>>>>> >>>>>> >>>>>> 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 -- Surveillance is pervasive. Go Dark. From ron.even.tlv@gmail.com Sat Oct 12 08:52:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4599621E818C for ; Sat, 12 Oct 2013 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohvxV9UtMMGb for ; Sat, 12 Oct 2013 08:52:12 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFA421E8188 for ; Sat, 12 Oct 2013 08:52:12 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so5537623pdj.25 for ; Sat, 12 Oct 2013 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=ucpvjEQZINn3t74wnL3uUJD6TBFqd79HLBwV1TIHx9U=; b=n+xpawlk1/3kjZL4rRRa94MVaZEaUWNc+A/c21GpyI3bd+HedC2i+8+nbU7eP0h9VS DecEsdVeblCJhSxA9922NFbdZRkfHSngl/uHJOvH0M8a+pPbbusx4YcFX6ImtMQ+WEcF QqZKc0XU4TycK5gIOyFdvFGglBg1PGOK20hMDV04XAXHhGPHRGVlbT+g5JvB14UpSL50 WpMMZa7oNTCVsLIfIDjuFfGIqMZpq93kk0w1v5k/KXWNY+w6YV/b+npHVerruWARlbDU tRm6Klco12kJyyF5m3KIzgJk8c2EVWnxf0wC1WFiwZfjy8KCJa8P3OUM26tTV0+MooJx 0RuQ== X-Received: by 10.66.227.2 with SMTP id rw2mr27950627pac.131.1381593131876; Sat, 12 Oct 2013 08:52:11 -0700 (PDT) Received: from RoniE ([60.247.108.2]) by mx.google.com with ESMTPSA id q4sm67015230pba.12.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 12 Oct 2013 08:52:10 -0700 (PDT) From: "Roni Even" To: "'Wang, Ye-Kui'" , "'Jonathan Lennox'" References: <20130826162642.54E0B8E018@rfc-editor.org> , <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> <008901cec64e$1c865f00$55931d00$@gmail.com> <31B495FC-06CA-43C3-AF15-5530D3D3E463@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83385B4C3F@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83385B4C3F@nasanexd02f.na.qualcomm.com> Date: Sat, 12 Oct 2013 18:49:02 +0300 Message-ID: <000601cec762$95bd0bc0$c1372340$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CEC77B.BB0C8DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdSdvxMif5AQ4btCbVHo1UALZuogLg7UtLAfkiqTEB9nFqWgGCqU3tAtUEbqIB1sa9wZlsObEw Content-Language: en-us Cc: ts@thomas-schierl.de, payload@ietf.org, 'RFC Errata System' Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2013 15:52:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CEC77B.BB0C8DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK with me Roni Even From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] Sent: 11 October, 2013 6:47 PM To: Jonathan Lennox; Roni Even Cc: Alex Eleftheriadis; ; ; RFC Errata System Subject: RE: [payload] [Technical Errata Reported] RFC6190 (3711) Exactly - as it is just a summary of the field specified in the SVC spec, it is basically non-normative. Also, the fields in the 4-byte NAL unit header has been carefully designed at JVT when SVC was developed, to avoid the possibility of certain bit patterns that are used as start codes in some systems. Considering all these factors, the errata should be approved (or whatever the right process is). BR, YK From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Friday, October 11, 2013 8:41 AM To: Roni Even Cc: Alex Eleftheriadis; Wang, Ye-Kui; ; ; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) This error is in section 1.1.3 of RFC 6190, which explicitly states that it is an summary of field definitions specified by the H.264 spec. Thus, I would hope (and expect) that most implementations are following the H.264 definition of this bit, not the RFC 6190 definition. On Oct 11, 2013, at 2:49 AM, Roni Even wrote: Since I saw feedback from Alex and Ye-Kui, I am wondering what the implementation are currently doing. Even though it make sense to change the current meaning I do not think it is wrong to keep the current values if was implemented this way. Thanks Roni Even Payload WG co-chair From: payload-bounces@ietf.org [mailto:payload- bounces@ietf.org] On Behalf Of Alex Eleftheriadis Sent: 11 October, 2013 8:58 AM To: Wang, Ye-Kui Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) I agree; the intended interpretation of the flag is evident by its name. It should, however, be marked as an error. --AE On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" < yekuiw@qti.qualcomm.com> wrote: The erratum is correct, though to me it is obviously a (relatively minor) typo. BR, YK From: payload-bounces@ietf.org [ mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, October 10, 2013 12:45 PM To: RFC Errata System Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) Do any PAYLOAD folks have a comment on this? This seems like a pretty major erratum, if correct. Thanks, --Richard On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) < weix@avaya.com> Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ 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 ------=_NextPart_000_0007_01CEC77B.BB0C8DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK with me

Roni Even

 

From:= = Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
Sent: 11 = October, 2013 6:47 PM
To: Jonathan Lennox; Roni = Even
Cc: Alex Eleftheriadis; <ts@thomas-schierl.de>; = <payload@ietf.org>; RFC Errata System
Subject: RE: = [payload] [Technical Errata Reported] RFC6190 = (3711)

 

Exactly – as it is just a summary of the field specified in the = SVC spec, it is basically non-normative.

 

Also, the fields in the 4-byte NAL unit header has been carefully = designed at JVT when SVC was developed, to avoid the possibility of = certain bit patterns that are used as start codes in some = systems.

 

Considering all these factors, the errata should be approved (or = whatever the right process is).

 

BR, YK

 

From:= = Jonathan Lennox [mailto:jonathan@vidyo.com] =
Sent: Friday, October 11, 2013 8:41 AM
To: Roni = Even
Cc: Alex Eleftheriadis; Wang, Ye-Kui; <ts@thomas-schierl.de>; = <payload@ietf.org>; RFC = Errata System
Subject: Re: [payload] [Technical Errata = Reported] RFC6190 (3711)

 

This error is in section 1.1.3 of = RFC 6190, which explicitly states that it is an summary of field = definitions specified by the H.264 = spec.

 

Thus, I would hope (and expect) = that most implementations are following the H.264 definition of this = bit, not the RFC 6190 definition.

 

On Oct 11, 2013, at 2:49 AM, Roni = Even <ron.even.tlv@gmail.com>

 wrote:

 

Since I saw feedback from Alex and Ye-Kui,  I am wondering what = the  implementation are currently = doing.

Even though it make sense to change the current meaning I do not = think it is wrong to keep the current values if was implemented this = way.

Thanks

Roni Even

Payload WG co-chair

 

From:=  payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Alex = Eleftheriadis
Sent: 11 October, 2013 8:58 = AM
To: Wang, = Ye-Kui
Cc: ts@thomas-schierl.de; payload@ietf.org; RFC Errata = System
Subject: Re: [payload] [Technical = Errata Reported] RFC6190 = (3711)

 

I agree; the intended interpretation of the flag is = evident by its name. It should, however, be marked as an = error. 

--AE


On Oct 11, 2013, at = 4:45 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> = wrote:

The erratum is correct, though to me it is obviously a (relatively = minor) typo.

 

BR, YK

 

From:=  payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Thursday, October 10, 2013 = 12:45 PM
To: RFC Errata = System
Cc: yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de
Subject:=  Re: [payload] = [Technical Errata Reported] RFC6190 = (3711)

 

Do any PAYLOAD folks have a comment on this? =  This seems like a pretty major erratum, if = correct.

 

Thanks,

--Richard

 

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System = <rfc-editor@rfc-editor.org> = wrote:

The following = errata report has been submitted for RFC6190,
"RTP Payload = Format for Scalable Video = Coding".

--------------------------------------
You may = review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D= 6190&eid=3D3711

-----------------------------------= ---
Type: Technical
Reported by: Xiaohui Wei (Joanne) <weix@avaya.com>

Section: = 1.1.3

Original Text
-------------
   N:   =  1 bit
        =  no_inter_layer_pred_flag.  This flag specifies, when present = in
         a coded slice NAL unit, whether = inter-layer prediction may be
         used = for decoding the coded slice (when equal to 1) or not
    =      (when equal to 0).

Corrected = Text
--------------
   N:    1 bit
  =        no_inter_layer_pred_flag.  This flag = specifies, when present in
         a coded = slice NAL unit, whether inter-layer prediction may be
    =      used for decoding the coded slice (when equal to 0) = or not
                  =                     =                     = ^
         (when equal to 1).
  =                     =   = ^

Notes
-----


Instructions:
-------------
This= errata is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the verifying party = (IESG)
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC6190 = (draft-ietf-avt-rtp-svc-27)
--------------------------------------
= Title               : RTP Payload = Format for Scalable Video Coding
Publication Date    : May = 2011
Author(s)           : S. Wenger, Y.-K. = Wang, T. Schierl, A. Eleftheriadis
Category       =      : PROPOSED STANDARD
Source       =        : Audio/Video Transport Payloads
Area =                : Real-time = Applications and Infrastructure
Stream         =      : IETF
Verifying Party     : = IESG

 

_______________________________________________
payl= oad 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

 

------=_NextPart_000_0007_01CEC77B.BB0C8DB0-- From keith.drage@alcatel-lucent.com Tue Oct 15 08:14:54 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A029821F9C7D for ; Tue, 15 Oct 2013 08:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnhwvje5Z++d for ; Tue, 15 Oct 2013 08:14:49 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 738A521F84F8 for ; Tue, 15 Oct 2013 08:14:46 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9FFDS8H017110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Oct 2013 10:14:37 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9FEFauY023123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 16:15:37 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 15 Oct 2013 16:15:36 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Stephan Wenger Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOvrWJGJSNFO5TKE61CpVnAq+6GJn1qRkw Date: Tue, 15 Oct 2013 14:15:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524AE118.3050306@ericsson.com> In-Reply-To: <524AE118.3050306@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 15:14:54 -0000 Just got round to looking at this. I regard to the IPR considerations, I think some distinction should be made= between IPR that is essential to implement the codec, and that which is es= sential to implement the payload format. Clearly the latter should be declared. I believe in the past we have had also declarations which appear to relate = to the former, which while not wrong, I think just add to the confusion. Su= ch declarations should belong to the SDO specifying the codec. Regards Keith=20 > -----Original Message----- > From: payload-bounces@ietf.org=20 > [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: 01 October 2013 15:50 > To: Stephan Wenger > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 >=20 > Hi Stephan, >=20 > Thanks for the comments. See inline for comments how I see=20 > these are addressed. >=20 > WG participants, please review! >=20 > On 2013-09-26 20:07, Stephan Wenger wrote: > > Hi Magnus, group, > >=20 > > A few random comments. None of them are showstoppers. =20 > Yes, I should=20 > > have contributed those earlier. Sorry. > >=20 > > Perhaps add a section about "writing style". Aspects here: > > (1) contrary to most other SDOs, the IETF has a history of spelling=20 > > out not only WHAT an implementation is to do, but also WHY.=20 > As a lot=20 > > of RTP payload formats are written by media guys (who's home SDO is=20 > > not necessarily the IETF), mentioning this could help overcoming a=20 > > culture shock. >=20 > Agreed, I will include this. >=20 >=20 > > (2) OTOH, many/most implementers of RTP payload specs are the same=20 > > people that also implement the network centric parts of the media=20 > > codec--at least for well designed media codecs, systems,=20 > and payload=20 > > formats. Therefore, it is also good to reflect the style and=20 > > terminology of the media codings pec in the payload format--even if=20 > > that makes the payload spec a little bit less accessible for folks=20 > > working only in the IETF. This is one reason why I don't feel bad=20 > > about the often lamented "density" of the > > H.264 payload specs. No compromises should be made on core IETF=20 > > habits like the use of 2119 keywords, though. >=20 > I don't see this necessarily as being contrary to 1). I think=20 > we should recommend using the terminology of the codec to be=20 > precise and clear. > The payload formats goal is to make clear the mapping between=20 > the two worlds, thus the whole purpose is to bind these=20 > worlds together. >=20 >=20 > > (3) It's also worth spelling out that the IETF has a=20 > historic (albeit=20 > > arguably not current) preference for lean and mean specs,=20 > even at the=20 > > cost of some functionality. Most media codec SDOs operate under an=20 > > assumption that if there were a use-case/requirement (however=20 > > exotic/weak it may be, and I note that use/case and requirements=20 > > discussions have quite often nothing to do with the real=20 > world) and no=20 > > competing tool, a proposal goes in, pleasing certain IPR=20 > departments=20 > > and leading to patent bonuses and career advancements, at=20 > the cost of=20 > > a bloated document. Some RTP payload formats written=20 > predominantly by=20 > > media codec people arguably are bloated as well for the=20 > same reason. =20 > > (And yes, I take personal blame for some of > > this.) While I do not see that we can change the situation=20 > (you want=20 > > to have the media competence of the media coding people), I=20 > think we=20 > > can at least point it out--hopefully in somewhat more diplomatic=20 > > language--so to explain a very common culture clash between IETF=20 > > regulars and payload format writers. >=20 > The RTP Payload formats may not be lean any more, but I think=20 > that is due to the increased complexity in the codecs and the=20 > need for being clear and explicit. >=20 >=20 > I propose that we add a section between 4.1.3 and 4.1.4 on=20 > Writing Style >=20 > My attempt for this section is the following: >=20 > 4.1.4. Writing Style >=20 > When writing an IETF draft for an RTP payload format some few > consideration on how to write in the IETF: >=20 > Include Motivations: It is common to include the=20 > motivation for why > a particular design or technical choice was chosen. These are > not long statements, a sentence here and there explaining why. >=20 > Use the Defined Terminology: There exist defined=20 > terminology both in > RTP and in the various media codecs. A payload format > specification do needs to use both to make clear the relation of > features and their functions. >=20 > Keeping It Simple: IETF has a history of specifications that are > focused on their main usage. When it comes to RTP=20 > Payload formats > that has a lot of modes and features the actually=20 > deployments has > in most cases only include the most basic features that had very > clear requirements. Time and effort can be saved by=20 > only focusing > on the most important use cases and keep the solution simple. >=20 >=20 > >=20 > > In 3.1.1 I would mention prominently the early and personal IPR=20 > > disclosure obligations in the IETF, as these differ from other SDOs=20 > > which specify media codecs. Simply pointing to the policy=20 > docs may be not enough. >=20 > I agree, this should have been more clearly stated. Here are=20 > my proposal for text around this. >=20 > It is very important to note and understand the IETF Intellectual > Property Rights (IPR) policy that requires early disclosures and > disclosures based on personal knowledge from the person=20 > contributing > in IETF. These rules are significantly different from many other > standardization organizations. The IETF rules and rights=20 > associated > with copyright and IPR are documented in BCP 78 [RFC5378]=20 > and BCP 79 > [RFC3979]. For example a person that has a patent or a patent > application that is believed to cover a mechanism that=20 > gets added to > the Internet draft they are contributing to (e.g. posting=20 > comments or > suggestions on the mailing list or speaking at a meeting) they will > need to make a timely (weeks, not months) IPR disclosure. Read the > above documents for the authoritative rules. Failure to follow the > IPR rules can have dire implications for the specification and the > author as discussed in [RFC6701]. >=20 > The main part of the IETF process is formally defined in RFC 2026 > [RFC2026]. RFC 2418 [RFC2418] describes the WG process,=20 > the relation > between the IESG and the WG, and the responsibilities of WG chairs > and participants. >=20 > >=20 > > Section 3 (and section 1). I think a lot of this description is=20 > > written for someone who wants to write an RTP payload format for an=20 > > existing media codec (with a stable and essentially unchangeable=20 > > spec). While this is probably still the most common=20 > scenario, there=20 > > are a number of cases where the transport aspects of the=20 > media coder=20 > > and the media aspects of the transport (RTP payload format)=20 > have been=20 > > developed concurrently, generally with very pleasing=20 > results for both=20 > > specs. H.264 is one prominent example, but there are others. =20 > > Arguably, joint development of codec and RTP payload format is=20 > > becoming a trend. I think that a 2013 generation RTP=20 > payload how-to=20 > > should acknowledge this situation. One way to do that would be to=20 > > include, in section 3, subsections "read and understand the media=20 > > coding spec", and "influence the media coding spec". If=20 > people think this is a good idea, I'm willing to draft a few=20 > paragraphs. >=20 > Yes, I think this is relevant to be explicit. If you can=20 > write up some text I would be thankful, but please do so=20 > within one or maximum two weeks. >=20 > >=20 > > I think the 9000 byte path MTU is generally not available in home=20 > > environments. Instead, MTU sizes larger than the 1500 bytes (from > > Ethernet) are AFAICT, available only in a few selected=20 > (large/medium)=20 > > enterprises and in the academic world. If that's true, it=20 > should be=20 > > stated. And, in home environments, the limiting factor is=20 > often not=20 > > even the ISP, but those old $50 router boxes (and their NAT=20 > > implementations) that infest the world. Mentioning this,=20 > perhaps with=20 > > an informative reference to a recent study, would send a=20 > message: if=20 > > your codec will be used a lot in home environments, don't go above=20 > > 1500 bytes. Not this year, and not next. >=20 > The message I really like to state is don't assume that 1500=20 > bytes is your MTU. It might be lower, and it might be higher.=20 > Design the payload format to be flexible to allow usage in=20 > either environments. >=20 > Then there is a usage configuration that in most environment=20 > you you need to be conservative, or maybe you should actually=20 > implement path MTU discovery ;-). >=20 > Updated text proposal. >=20 > At the time of writing this document the most common IP=20 > Maximum Transmission Unit (MTU) in used link layers is 1500=20 > bytes (Ethernet data payload). However there exist both links=20 > with smaller MTUs and links with much larger MTUs. Certain=20 > parts of the Internet already today support an IP MTU of 8000=20 > bytes or more, but these are limited islands. > The most likely places to find larger MTUs than 1500 bytes=20 > are within enterprise networks, university networks, data=20 > centers, storage networks as well as over high capacity (10=20 > Gbps or more) links. There is a slow ongoing evolution=20 > towards larger MTU sizes. However, at the same time it has=20 > become common to use tunneling protocols, often multiple ones=20 > who's overhead when added together can shrink the MTU=20 > significant. Thus, there exist a need to consider both=20 > limited MTUs as well as enable support of larger MTUs. This=20 > should be considered in the design, especially in regards to=20 > features such as aggregation of independently decodable data units. >=20 > Note, I don't have an good reference to point at where these=20 > MTU networks exist. This is really a speculation based on=20 > what source of capability that exist for larger MTUs. >=20 > >=20 > > Sections 5.1.1 and 5.1.2: one key use case of both aggregation and=20 > > fragmentation is the effective packetization of=20 > pre-recorded content, > > where one cannot change the size of ADUs without=20 > transcoding. The key > > use case of aggregation is the packetization overhead for=20 > small ADUs=20 > > such as parameter sets or SEI messages in H.264. >=20 > Yes, I have tried to make these clearer in the below text. >=20 > 5.1.1. Aggregation >=20 > Aggregation allows for the inclusion of multiple application data > units (ADUs) within the same RTP payload. This is=20 > commonly supported > for codecs that produce ADUs of sizes smaller than the IP MTU. Do > remember that the MTU may be significantly larger than 1500 bytes. > An MTU of 9000 bytes is available today and an MTU of 64k may be > available in the future. Many speech codecs have the property of > ADUs of a few fixed sizes. Video encoders may generally=20 > produce ADUs > of quite flexible sizes. Thus the need for aggregation=20 > may be less. > But some codecs produces small ADUs mixed with large, for example > H.264 SEI messages. Sending individual SEI message in separate > packets are not efficient compared to combing the with other ADUs. > There also exist cases when the ADUs are pre-produced and can't be > adopted to a specific networks MTU. Instead their packetization > needs to be adopted to the network. Thus there exist some=20 > different > use cases with the possibility to aggregate multiple ADUs,=20 > including > for different playback times, is useful. >=20 > The main disadvantage of aggregation is the extra delay introduced > (due to buffering until a sufficient number of ADUs have been > collected at the sender) and reduced robustness against=20 > packet loss. > Aggregation also introduces buffering requirements at the receiver. >=20 > 5.1.2. Fragmentation >=20 > If the real-time media format has the property that it may produce > ADUs that are larger than common MTU sizes then=20 > fragmentation support > should be considered. An RTP Payload format may always=20 > fall back on > IP fragmentation, however as discussed in RFC 2736 this has some > drawbacks. Mainly that IP fragmented packets commonly are=20 > discarded > in the network, especially by Network Address Translators or > Firewalls. The usage of RTP payload format-level fragmentation > allows for more efficient usage of RTP packet loss recovery > mechanisms. It may also in some cases also allow better usage of > partial ADUs by doing media specific fragmentation at=20 > media specific > boundaries. In use cases where the ADUs are pre-produced and can't > be adopted to the network support for fragmentation can be crucial. >=20 >=20 > >=20 > > In a different email, you asked for review of 5.1.5. There=20 > are more=20 > > qualified people on this list to comment, but here are a few points. > > (1) citing H.264 RFC 6184 for temporal scalability is a bit=20 > > questionable, as 6184 doe snot include a single mechanism=20 > to support=20 > > temporal scalability (although H.264 does). So if people=20 > would go to=20 > > 6184 as the payload format for base H.264 and read it,=20 > expecting ideas=20 > > on how to deal with temporal scalability, they would come up blank=20 > > after digging through > > 101 pages of not exactly easy to read spec language. I=20 > fear that it=20 > > would be best to point to SVC and 6190 for temporal=20 > scalability, just=20 > > as it is done for spatial and SNR. >=20 > I think there is a point that tempoeral scalability can=20 > simply be done, without explicit definition. But it should be=20 > clear that this is may also be more explictly defined as in SVC. >=20 >=20 > > (2) with respect to MST: the doc could be read that=20 > re-alignment for=20 > > H.264-SVC could be implemented through 6051. This is not=20 > the case, as=20 > > decoding time and NAL unit order are mostly decoupled (not only in=20 > > SVC, but in all modern video codecs). >=20 > Agreed, this is poorly formulated. I will try to make it=20 > clear that for certain features an payload format design=20 > could rely on these tools to be part of solution. The changed=20 > wording is: >=20 > ... In order to allow > correct data provision to a decoder after reception from different > sessions, data re-alignment mechanisms are described for Scalable > Video Coding [RFC6190]. There exist some generic tools that may be > of use for a payload format design for a scalable codec. These > include the Rapid Sync for RTP flows [RFC6051], which is using > existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely > inter-session synchronization. Another is the signaling=20 > feature for > indicating dependencies of RTP sessions in SDP, as defined in the > Media Decoding Dependency Grouping in SDP [RFC5583]. >=20 >=20 > > (3) Perhaps write something to the extent that MST was unpopular=20 > > because of the impracticality of multiple transport addresses, and=20 > > that this reason is slowly going away through=20 > IETF-acceptance of RTP mux techniques. >=20 > I think we need to be clear here. SVC MST mode appears to=20 > have gotten significant use as multiple packet streams=20 > (SSRCs) within a single RTP session. The original envision of=20 > the MST mode was for multicast or other receiver controlled=20 > steering of what flows was received. From my perspective any=20 > future scalable codec should consider having both a single=20 > stream and a multi stream mode. However, the mapping of the=20 > RTP packet streams needs to be flexible to cater both for=20 > multiple RTP sessions and then commonly multicast groups as=20 > well as within a single RTP session. >=20 >=20 > >=20 > > Section 6.2, "recent" VC-1. You probably wanted to cite=20 > VP8? Calling > > VC-1 and its payload spec "recent" is a bit of a stretch. >=20 > Failure to keep the text current. This text was first=20 > included back in 2008. Haven't been in a hurry to finish this=20 > document. But now it is time. >=20 > I updated this text to say: > The definition of RTP payload formats for video has seen an=20 > evolution from the early ones such as H.261 towards the=20 > latest for VP-8 and H.265/HEVC. >=20 >=20 > >=20 > > Perhaps add a "Do and don't" sections listing key mistakes. In the=20 > > don't section, list the handling of the timestamp in RFCs=20 > 2038 and 2250. >=20 > This is WG last call, of a document that has been a WG document since > 2006 (then in AVT). This proposal although a good idea, is a=20 > little bit late to introduce. Primarily as I think such a=20 > section would require a couple of rounds of revision before=20 > getting right. >=20 > Cheers >=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > = From internet-drafts@ietf.org Tue Oct 15 09:24:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEABA21F9CCC; Tue, 15 Oct 2013 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES03FDq-Tgrv; Tue, 15 Oct 2013 09:24:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1170521F9D94; Tue, 15 Oct 2013 09:24:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015162444.2118.21923.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 09:24:44 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 16:24:59 -0000 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 Standard apt-X and Enhanced apt-X= Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-02.txt Pages : 22 Date : 2013-10-15 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Lindsay@worldcastsystems.com Tue Oct 15 09:38:42 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8245911E8188 for ; Tue, 15 Oct 2013 09:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOnXAc9CVa+E for ; Tue, 15 Oct 2013 09:38:38 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD6311E8181 for ; Tue, 15 Oct 2013 09:38:37 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 15 Oct 2013 17:38:36 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02FDE8F5@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-02 Thread-Index: Ac7JxPgTMA2Iw7QWQieUJza05ZtQEw== From: "John Lindsay" To: "Ali C. Begen (abegen)" , Cc: Foerster@worldcastsystems.com Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 16:38:42 -0000 Hi A new draft has been submitted "draft-ietf-payload-rtp-aptx-02" in response to the comments posted over the last few weeks. The changes are:- Section 3=20 Note of licensing the algorithm has been changed for better readability and contact details for CSR (who currently own the rights to the algorithms) have been added. Section 5.1 Changes to Marker bit to reference RFC3551. Changes to dynamic payload type to remove the range [96..127] as per the discussion in the avtcore list. Section 6.2 maxptime moved to its own SDP a attribute. Removed the notes to "delivery method" to improve readability. Thanks again to all who have taken the time to read the draft. Regards John -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: 11 October 2013 14:59 To: payload@ietf.org Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 There have been some comments in the list and authors seem to have adequately addressed these in the list. Authors, please submit a revision (the cutoff is in a few days) so that we can move on. -acbegen (as WG co-chair) On Sep 16, 2013, at 6:08 AM, Ali C. Begen (abegen) wrote: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 01).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >=20 > It is a short document. If you have comments, agreements or disagreements, please let the list know in either case. >=20 > The deadline for the WGLC is September 30th. >=20 > -acbegen > _______________________________________________ > 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 abegen@cisco.com Tue Oct 15 10:18:18 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EE11E81D5 for ; Tue, 15 Oct 2013 10:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWQ6A5Jgr6-b for ; Tue, 15 Oct 2013 10:18:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB311E8121 for ; Tue, 15 Oct 2013 10:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2389; q=dns/txt; s=iport; t=1381857493; x=1383067093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b2k8d3hzQaFvGh2ycwONHeVSVmJ2V2JB/5FLwdXy0O8=; b=f/Sg/ho81lxrpwJXXQpiGmj3bU5ySTSfsLHDDAyRlDSCHtmGHxXprtZz I5YzQTLSDssjihZnqNJ+gVHdwAnapzgKkylgP4g2M8F4LeqEi8/QsvoQK dyjV3LWcdLhljKDDKwsdOZvRjykdIzRAOk0ci7awqR6t6Sf8iqABWLXao I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAGB4XVKtJXG9/2dsb2JhbABagmYhOMIwS4EjFnSCJQEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQcnCxQJCAEBBA4FiAAGAQu9VwSPFwgrBwaDGYEGA5gEkgKDJA X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="272395441" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 15 Oct 2013 17:18:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FHIAn6008409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 17:18:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 12:18:10 -0500 From: "Ali C. Begen (abegen)" To: John Lindsay Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-02 Thread-Index: Ac7JxPgTMA2Iw7QWQieUJza05ZtQEwABY0Yy Date: Tue, 15 Oct 2013 17:18:09 +0000 Message-ID: References: <8C4E0C2409735E4FBC22D754A238F94D02FDE8F5@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02FDE8F5@APTSBS.apt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Foerster@worldcastsystems.com" , "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 15 Oct 2013 17:18:18 -0000 I will prepare the write up in a few days. If there are still outstanding c= omments, please raise them now.=20 -acbegen=20 Sent using iThumbs - DYAC > On Oct 15, 2013, at 7:38 PM, "John Lindsay" wrote: >=20 > Hi >=20 > A new draft has been submitted "draft-ietf-payload-rtp-aptx-02" in > response to the comments posted over the last few weeks. >=20 > The changes are:- >=20 > Section 3=20 >=20 > Note of licensing the algorithm has been changed for better readability > and contact details for CSR (who currently own the rights to the > algorithms) have been added. >=20 > Section 5.1 >=20 > Changes to Marker bit to reference RFC3551. > Changes to dynamic payload type to remove the range [96..127] as per the > discussion in the avtcore list. >=20 > Section 6.2 >=20 > maxptime moved to its own SDP a attribute. > Removed the notes to "delivery method" to improve readability. >=20 > Thanks again to all who have taken the time to read the draft. >=20 > Regards >=20 > John >=20 >=20 >=20 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Ali C. Begen (abegen) > Sent: 11 October 2013 14:59 > To: payload@ietf.org > Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 >=20 > There have been some comments in the list and authors seem to have > adequately addressed these in the list. >=20 > Authors, please submit a revision (the cutoff is in a few days) so that > we can move on. >=20 > -acbegen (as WG co-chair) >=20 > On Sep 16, 2013, at 6:08 AM, Ali C. Begen (abegen) > wrote: >=20 >> (As a WG co-chair) >>=20 >> I am starting WGLC for the following draft (version 01).=20 >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >>=20 >> It is a short document. If you have comments, agreements or > disagreements, please let the list know in either case. >>=20 >> The deadline for the WGLC is September 30th. >>=20 >> -acbegen >> _______________________________________________ >> 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 From magnus.westerlund@ericsson.com Tue Oct 15 23:38:19 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFE611E8108 for ; Tue, 15 Oct 2013 23:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.261 X-Spam-Level: X-Spam-Status: No, score=-105.261 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1tB7joSMhKh for ; Tue, 15 Oct 2013 23:38:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6157C11E826D for ; Tue, 15 Oct 2013 23:38:11 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-bb-525e3451c2b0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.A4.03802.1543E525; Wed, 16 Oct 2013 08:38:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Wed, 16 Oct 2013 08:38:09 +0200 Message-ID: <525E3488.2080303@ericsson.com> Date: Wed, 16 Oct 2013 08:39:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Stephan Wenger References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW6QSVyQwctXfBZPG88yWly6eJbJ 4nrjJnYHZo/WZ3tZPZYs+cnksXj9e8YA5igum5TUnMyy1CJ9uwSujN8PhAs+c1YcOdnI2MD4 m72LkZNDQsBEYuejJihbTOLCvfVsXYxcHEIChxkldjw/BuUsZ5SYev0cI0gVr4C2RPfTjawg NouAqsSXWbtYQGw2AQuJmz8a2UBsUYFgiRvLDrFB1AtKnJz5BKxGRCBe4v/mOWDbmAU0JQ59 fgxWIyxgL7Fg1hFWiGWzGSUenH0CluAUiJb4efcOG8R5khLbFh2DataTmHK1hRHClpdo3jqb GcQWAjquoamDdQKj0Cwku2chaZmFpGUBI/MqRvbcxMyc9HKjTYzAAD645bfqDsY750QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbE7wm1akHuLRdDa/yu03FTWzfth HZkZOHPL7uvbYhx6Iv7tsZf29fi/IV7v+iMmvd9xDhM6btpYn7A6YfV/1703mZpyBx7OSvkx pWe/cvojZp4Q7U8yUswegheNlRh+HS+ZVuo15zjjI4HEJN/GhPxnjs+vz5qu8YLR6swfn/Z1 ydc9boYrCCqxFGckGmoxFxUnAgCeBPitLgIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 06:38:19 -0000 On 2013-10-15 16:15, DRAGE, Keith (Keith) wrote: > Just got round to looking at this. > > I regard to the IPR considerations, I think some distinction should > be made between IPR that is essential to implement the codec, and > that which is essential to implement the payload format. > > Clearly the latter should be declared. > > I believe in the past we have had also declarations which appear to > relate to the former, which while not wrong, I think just add to the > confusion. Such declarations should belong to the SDO specifying the > codec. Yes, I agree with you. This should be clarified. Do you have a some text proposal? Consider where we are in the process I think it is good if we agree on some formulation here on the list, then I can incorporate it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Wed Oct 16 23:20:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15021F9F99 for ; Wed, 16 Oct 2013 23:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwjfPg8gv2Kz for ; Wed, 16 Oct 2013 23:20:50 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DE83411E81A1 for ; Wed, 16 Oct 2013 23:20:46 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-02-525f81bdfb8d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CA.CD.25272.DB18F525; Thu, 17 Oct 2013 08:20:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Thu, 17 Oct 2013 08:20:45 +0200 Message-ID: <525F81F9.2000107@ericsson.com> Date: Thu, 17 Oct 2013 08:21:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Stephan Wenger References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> In-Reply-To: <525E3488.2080303@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvje7exvggg7WLrCyeNp5ltLh08SyT xfXGTewOzB6tz/ayeixZ8pPJY/H694wBzFFcNimpOZllqUX6dglcGQcmnGYpWMFT8f/CN7YG xu+cXYwcHBICJhKti4BMTiBTTOLCvfVsXYxcHEICRxklNj48xwrhLGeUOHa3kxWkildAW+Lo v6VgNouAqsS+jhMsIDabgIXEzR+NbCC2qECwxI1lh9gg6gUlTs58AlYjIhAv8X/zHHYQm1lA U+LQ58dgNcIC9hILZh2BWrabUeJC002wBZwCOhLL7t1ihDhPUmLbomNQzXoSU662MELY8hLN W2czg9hCQMc1NHWwTmAUmoVk9ywkLbOQtCxgZF7FyFGcWpyUm25ksIkRGMIHt/y22MF4+a/N IUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCefbJ+oWajXd+7zpzMzW91 yp7nNkfcSvP0t72lde7Xr5AWm2BNuQv7pWUX7VFfrt347Xxdy+Qc6eqTt35PnJ30xjLt6703 3u0hpn3ujZNPPmJuac8U+Zeo3cW1a6J+C9u6o3vcL6v5drR9tj9evu0pR72/VNft4OpT26dz XlGrepPz63hr6i8lluKMREMt5qLiRABN+ubDLwIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 06:20:56 -0000 On 2013-10-16 08:39, Magnus Westerlund wrote: > On 2013-10-15 16:15, DRAGE, Keith (Keith) wrote: >> Just got round to looking at this. >> >> I regard to the IPR considerations, I think some distinction should >> be made between IPR that is essential to implement the codec, and >> that which is essential to implement the payload format. >> >> Clearly the latter should be declared. >> >> I believe in the past we have had also declarations which appear to >> relate to the former, which while not wrong, I think just add to the >> confusion. Such declarations should belong to the SDO specifying the >> codec. > > Yes, I agree with you. This should be clarified. Do you have a some text > proposal? WG, I propose that we add this text as a indented note after the second paragraph of Section 3.2.1: Note: These IPR rules applies on what is written in the RTP Payload format Internet Draft (and later RFC), IPRs that relates to a codec specification from an external body does not require IETF IPR disclosure. Is this okay, and appropriate to deal with this comment? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 keith.drage@alcatel-lucent.com Thu Oct 17 03:47:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF09711E8177 for ; Thu, 17 Oct 2013 03:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RVX89h8i9-n for ; Thu, 17 Oct 2013 03:47:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 68D8711E8103 for ; Thu, 17 Oct 2013 03:47:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9HAlY6k020741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2013 05:47:36 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9HAlXuZ007835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 12:47:33 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 17 Oct 2013 12:47:33 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Stephan Wenger Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOyjpnGJSNFO5TKE61CpVnAq+6GJn4TFKAgABqgKA= Date: Thu, 17 Oct 2013 10:47:33 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> In-Reply-To: <525F81F9.2000107@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 10:47:56 -0000 The proposal is, in principal, fine. Perhaps "on what is written" could be = a bit more specific to be "on the requirements". Informative text explainin= g the nature of the codec would not normally require an IETF IPR declaratio= n. I would also add a sentence something like: "Appropriate IPR declarations for the codec itself would normally be found = in files of the external body defining the codec, in accordance with that e= xternal bodies own IPR rules." Regards Keith > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 17 October 2013 07:22 > To: DRAGE, Keith (Keith); Stephan Wenger > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 >=20 > On 2013-10-16 08:39, Magnus Westerlund wrote: > > On 2013-10-15 16:15, DRAGE, Keith (Keith) wrote: > >> Just got round to looking at this. > >> > >> I regard to the IPR considerations, I think some=20 > distinction should=20 > >> be made between IPR that is essential to implement the codec, and=20 > >> that which is essential to implement the payload format. > >> > >> Clearly the latter should be declared. > >> > >> I believe in the past we have had also declarations which=20 > appear to=20 > >> relate to the former, which while not wrong, I think just=20 > add to the=20 > >> confusion. Such declarations should belong to the SDO=20 > specifying the=20 > >> codec. > >=20 > > Yes, I agree with you. This should be clarified. Do you have a some=20 > > text proposal? >=20 > WG, >=20 > I propose that we add this text as a indented note after the=20 > second paragraph of Section 3.2.1: >=20 > Note: These IPR rules applies on what is written in the RTP=20 > Payload format Internet Draft (and later RFC), IPRs that=20 > relates to a codec specification from an external body does=20 > not require IETF IPR disclosure. >=20 > Is this okay, and appropriate to deal with this comment? >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > = From magnus.westerlund@ericsson.com Thu Oct 17 04:04:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7E11E8115 for ; Thu, 17 Oct 2013 04:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.268 X-Spam-Level: X-Spam-Status: No, score=-105.268 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV-gws3PxIPz for ; Thu, 17 Oct 2013 04:04:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37C21F9DF3 for ; Thu, 17 Oct 2013 04:04:19 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-e3-525fc4313f99 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3A.B4.03802.134CF525; Thu, 17 Oct 2013 13:04:18 +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.2.328.9; Thu, 17 Oct 2013 13:04:17 +0200 Message-ID: <525FC46F.6080508@ericsson.com> Date: Thu, 17 Oct 2013 13:05:19 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Stephan Wenger References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvja7Rkfggg9f/RCyeNp5ltLh08SyT xfXGTewOzB6tz/ayeixZ8pPJY/H694wBzFFcNimpOZllqUX6dglcGXMPsBTc4Kl4fVOigXED VxcjJ4eEgInErkVvWSBsMYkL99azdTFycQgJHGaU+Dh1FiOEs5xRouPtYrAqXgFtib+TD7KB 2CwCqhIPfi1lArHZBCwkbv5oBIuLCgRL3Fh2iA2iXlDi5MwnYL0iAvES/zfPYQexmQU0JQ59 fgxWIyxgL7Fg1hFWEFtIYBWTxO/TpiA2p0C0xJtV/9ggrpOU2LboGFSvnsSUqy2MELa8RPPW 2cwQvdoSDU0drBMYhWYhWT0LScssJC0LGJlXMbLnJmbmpJcbbWIEBu/BLb9VdzDeOSdyiFGa g0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwuZ3k3T2rxNRHUNeDSkNp30dnf UvmirTJXbkCSpNcDS9ELh7zEIk7qX3QKf1a2+PK69Iv7TbMNp0d07+R6evVW2l+DjrsGWof8 7rZuObSaSf3dtkAX2+XVSxdtLp5peknLk8n65nODRWxztxWw/p63ccGmC1tZOn9/La8RL0pm b19dkpUzO0qJpTgj0VCLuag4EQC0lGe+LAIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 11:04:33 -0000 On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote: > The proposal is, in principal, fine. Perhaps "on what is written" > could be a bit more specific to be "on the requirements". Informative > text explaining the nature of the codec would not normally require an > IETF IPR declaration. > > I would also add a sentence something like: > > "Appropriate IPR declarations for the codec itself would normally be > found in files of the external body defining the codec, in accordance > with that external bodies own IPR rules." > Maybe using "specified" is better than what payload format requires? Anyway, updated text proposal: Note: These IPR rules applies on what is specified in the RTP Payload format Internet Draft (and later RFC), IPRs that relates to a codec specification from an external body does not require IETF IPR disclosure. Informative text explaining the nature of the codec would not normally require an IETF IPR declaration. Appropriate IPR declarations for the codec itself would normally be found in files of the external body defining the codec, in accordance with that external bodies own IPR rules. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 keith.drage@alcatel-lucent.com Thu Oct 17 04:06:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0711E8167 for ; Thu, 17 Oct 2013 04:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5bvlgk6iBOo for ; Thu, 17 Oct 2013 04:05:56 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C134211E8102 for ; Thu, 17 Oct 2013 04:05:56 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9HB5o5W013819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2013 06:05:51 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9HB5nZK031191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 13:05:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 17 Oct 2013 13:05:49 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Stephan Wenger Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOyjpnGJSNFO5TKE61CpVnAq+6GJn4TFKAgABqgKD//+S6gIAAIaEA Date: Thu, 17 Oct 2013 11:05:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BA51E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525FC46F.6080508@ericsson.com> In-Reply-To: <525FC46F.6080508@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 11:06:03 -0000 Fine. Keith=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 17 October 2013 12:05 > To: DRAGE, Keith (Keith); Stephan Wenger > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 >=20 > On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote: > > The proposal is, in principal, fine. Perhaps "on what is written" > > could be a bit more specific to be "on the requirements".=20 > Informative=20 > > text explaining the nature of the codec would not normally=20 > require an=20 > > IETF IPR declaration. > >=20 > > I would also add a sentence something like: > >=20 > > "Appropriate IPR declarations for the codec itself would=20 > normally be=20 > > found in files of the external body defining the codec, in=20 > accordance=20 > > with that external bodies own IPR rules." > >=20 >=20 > Maybe using "specified" is better than what payload format requires? > Anyway, updated text proposal: >=20 > Note: These IPR rules applies on what is specified in the RTP=20 > Payload format Internet Draft (and later RFC), IPRs that=20 > relates to a codec specification from an external body does=20 > not require IETF IPR disclosure. Informative text explaining=20 > the nature of the codec would not normally require an IETF=20 > IPR declaration. Appropriate IPR declarations for the codec=20 > itself would normally be found in files of the external body=20 > defining the codec, in accordance with that external bodies=20 > own IPR rules. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > = From hhhansen@MAYAH.com Thu Oct 17 14:31:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4111E81FD; Thu, 17 Oct 2013 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4M2Udb1hKPq; Thu, 17 Oct 2013 14:31:51 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7A46311E81DE; Thu, 17 Oct 2013 14:31:50 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VWvAa-0006kx-AH; Thu, 17 Oct 2013 23:31:48 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 17 Oct 2013 23:31:46 +0200 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C38F542@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-02.txt Thread-Index: Ac7Jw9dpZHopX09YTOeNZQXCJIaDLQBu5z8Q From: "Hans-Heinrich Hansen" To: , X-Df-Sender: MzI2MjQx Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 21:31:56 -0000 We support this draft in our MAYAH devices and hope that this draft will = be released asap! Best regards, Hans-Heinrich Hansen MAYAH Communications GmbH -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]On Behalf Of internet-drafts@ietf.org Sent: Tuesday, October 15, 2013 6:25 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-02.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 Standard apt-X and Enhanced = apt-X Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-02.txt Pages : 22 Date : 2013-10-15 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-02 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Fri Oct 18 08:34:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B591F0CE4 for ; Fri, 18 Oct 2013 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCzuRzWYP1Aq for ; Fri, 18 Oct 2013 08:33:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D0FEA1F0ED5 for ; Fri, 18 Oct 2013 08:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2030; q=dns/txt; s=iport; t=1382110435; x=1383320035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WFB2o7OwRII56MPhgf/ukR6TA/3aEGVt0xG9HLbmyXM=; b=ZCK125zZDzrX5QMNbcbWMQEu5UvkaydAYmUeJ4pa9eHPS3T+hjMBBz+8 JAkfBZO5CUpoKDe1Gxk2WVrjDHfnTRu088b3ukM561aSpHx/WjbOZjszE E27gIPy4fJn5oaLesQouOmdypVbHH0LUK/1SZQ20uSVpWRnDAhMF9eKlB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAJFTYVKtJXG//2dsb2JhbABagmYhOFK9VUuBIBZ0giUBAQEDAQEBAQliCwUJAgIBCBgKHQcbDAsUEQIEDgUIh3gGAQvAeQQEjx8CMQeDH4EKA4kHoQmDJIIp X-IronPort-AV: E=Sophos;i="4.93,523,1378857600"; d="scan'208";a="273886090" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 18 Oct 2013 15:33:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IFXsZw029870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 15:33:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 10:33:54 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkpm94ZUAgBr6o4CAB6RvAIAV9wgAgAESxwCAAY1+gIAASkOAgAAE94CAAd1lgA== Date: Fri, 18 Oct 2013 15:33:53 +0000 Message-ID: References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525FC46F.6080508@ericsson.com> In-Reply-To: <525FC46F.6080508@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F2317AB0D2B234CB1F3D290ABEB9372@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2013 15:34:03 -0000 On Oct 17, 2013, at 2:05 PM, Magnus Westerlund wrote: > On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote: >> The proposal is, in principal, fine. Perhaps "on what is written" >> could be a bit more specific to be "on the requirements". Informative >> text explaining the nature of the codec would not normally require an >> IETF IPR declaration. >>=20 >> I would also add a sentence something like: >>=20 >> "Appropriate IPR declarations for the codec itself would normally be >> found in files of the external body defining the codec, in accordance >> with that external bodies own IPR rules." >>=20 >=20 > Maybe using "specified" is better than what payload format requires? > Anyway, updated text proposal: >=20 > Note: These IPR rules applies on what is specified in the RTP Payload s/ applies/apply > format Internet Draft (and later RFC), IPRs that relates to a codec s/ relates/relate > specification from an external body does not require IETF IPR s/ does/do > disclosure. Informative text explaining the nature of the codec would > not normally require an IETF IPR declaration. Appropriate IPR > declarations for the codec itself would normally be found in files of > the external body defining the codec, in accordance with that external > bodies own IPR rules. s/bodies/body's >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 From abegen@cisco.com Sun Oct 20 13:57:18 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BD111E8447 for ; Sun, 20 Oct 2013 13:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csy+3apPMgkD for ; Sun, 20 Oct 2013 13:57:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3633311E8444 for ; Sun, 20 Oct 2013 13:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1815; q=dns/txt; s=iport; t=1382302629; x=1383512229; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=OQSukhimunEX0rsq6xs13HoNZZ7MhMuNvYJneWYiNxA=; b=aol57W54BEwLGw5SpAfx5tJz2nAzDpCd0QdX2aPCRNScjjkXBl5cOils s/ndnknDpZpFRcEYEXUOyyx7Omh5X+plwYM+233n2dqqTn3LYcz95qGc4 E9XEZKe7XG5RmS963IZkquPqB5WovXK/OFssDoHkw7t8GuPXu/sFdz1KG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAC1DZFKtJXHB/2dsb2JhbABagmYhOFS+MoEkFm0HgicBBDo/EgEqFEInBA4FCId+AQy9QY4TgRgxgyaBCgOZOJBYgySBcTk X-IronPort-AV: E=Sophos;i="4.93,534,1378857600"; d="scan'208";a="274365386" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 20 Oct 2013 20:57:09 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9KKv8i2019111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 20:57:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Sun, 20 Oct 2013 15:57:08 -0500 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: Review of draft-ietf-payload-rtp-aptx-02 Thread-Index: AQHOzdbw2vjQftbAz0q6DC+dHfSdjw== Date: Sun, 20 Oct 2013 20:57:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.190] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-payload-rtp-aptx@tools.ietf.org" Subject: [payload] Review of draft-ietf-payload-rtp-aptx-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 20 Oct 2013 20:57:18 -0000 The WGLC has ended a few weeks ago and I just completed my review. Everythi= ng looks good except a few typos. In general, I would avoid using "ms" unti= l it is defined "milliseconds (ms)". Authors, if you can submit a revision by tomorrow (21st of Oct.), we can sh= ip this right away. Thanks, -acbegen Other comments regarding media subtype registration (Thanks to Bjoern Hoehr= mann): 1) The registration in Section 6.1 uses the old template.=20 The current template is here: http://tools.ietf.org/html/rfc6838#section-5.= 6 2) Regarding ptime: It might be better to say "Defaults to 4 (milliseconds)= ", otherwise some might be confused whether the `ms` is part of the value. 3) Regarding stereo channels: If the value includes characters like `{` the= n in protocols like HTTP the value would have to be enclosed in double quot= es since `{` is not allowed as a bare token in that protocol. The situation= may be similar in RTP, and if so, that's not sufficiently clear from the t= ext above. The same goes for some other parameters and other characters lik= e `,`. Is there some other way that we can use to avoid this potential problem? 4) Regarding embedded-autosync-channels: This should be rephrased to avoid = combining "MUST" and "only"; it is not clear whether specifying more than t= he first channel is optional or forbidden. Same for the `embedded-aux-chann= els` parameter. 5) Regarding the encoding considerations: This should say "framed".=20 6) "Restrictions on usage" field can say "RTP applications only". 7) Person & email address to contact for further information: This should b= e "John Lindsay email:lindsay@worldcastsystems.com" 8) Author/Change controller: This should say "IETF Payload Working Group de= legated from the IESG"= From magnus.westerlund@ericsson.com Sun Oct 20 22:44:20 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06D511E84AD for ; Sun, 20 Oct 2013 22:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.488 X-Spam-Level: X-Spam-Status: No, score=-103.488 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsbF2tjGuoha for ; Sun, 20 Oct 2013 22:44:12 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0A11E8348 for ; Sun, 20 Oct 2013 22:44:05 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-9c-5264bf1cce05 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.0D.25272.C1FB4625; Mon, 21 Oct 2013 07:43:56 +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.2.328.9; Mon, 21 Oct 2013 07:43:56 +0200 Message-ID: <5264BF6E.7070800@ericsson.com> Date: Mon, 21 Oct 2013 07:45:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Magnus Westerlund , "DRAGE, Keith (Keith)" , Stephan Wenger References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525FC46F.6080508@ericsson.com> In-Reply-To: <525FC46F.6080508@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvja7M/pQgg1VzzCyeNp5ltLh08SyT xfXGTewOzB6tz/ayeixZ8pPJY/H694wBzFFcNimpOZllqUX6dglcGTs+/mYsmC1WsW7Fd9YG xg6hLkYODgkBE4nF5/S7GDmBTDGJC/fWs3UxcnEICRxllLj14gszhLOcUeLE1YcsIA28AtoS b7/7gDSwCKhKbH54iRnEZhOwkLj5o5ENxBYVCJa4sewQmM0rIChxcuYTFhBbRGAyo8SlvdUg NrOApsShz4/BaoQF7CUWzDrCCrHrFJPEpue3wBo4BXQk2td9ZYK4TlJi26Jj7BDNehJTrrYw QtjyEs1bZ4MdIQR0W0NTB+sERqFZSHbPQtIyC0nLAkbmVYwcxanFSbnpRgabGIEBfHDLb4sd jJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo5jO7O9KLqwxIpP+ ZjxaVhUu4yPtyVU3IdTyPEfq78dWqaorWwT1J9xnrJAyPv/lwt2E1glbeHl6uLhvXb7aulru s/upDHPXjpVSxSkWuoHVAorcO6u/27pmhF1JsrCP53nbF8LmWOnGI2XDm/jF/+DssKd/3O+F LUyUX3X3qf3l1uVSM58qsRRnJBpqMRcVJwIAMWL4Wi4CAAA= Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 05:44:20 -0000 Hi, I will not submit this proposal included in a version before the dead-line. The reason is that I want to discuss this with my legal department. Secondly, I think the WG should consider the implication of even this informative words about how it has been usually done. This group is not changing the IETF process in regards to the IPR. So are we really certain that we are not misrepresenting a reasonable interpretation of the IPR rules of IETF? cheers Magnus On 2013-10-17 13:05, Magnus Westerlund wrote: > On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote: >> The proposal is, in principal, fine. Perhaps "on what is written" >> could be a bit more specific to be "on the requirements". Informative >> text explaining the nature of the codec would not normally require an >> IETF IPR declaration. >> >> I would also add a sentence something like: >> >> "Appropriate IPR declarations for the codec itself would normally be >> found in files of the external body defining the codec, in accordance >> with that external bodies own IPR rules." >> > > Maybe using "specified" is better than what payload format requires? > Anyway, updated text proposal: > > Note: These IPR rules applies on what is specified in the RTP Payload > format Internet Draft (and later RFC), IPRs that relates to a codec > specification from an external body does not require IETF IPR > disclosure. Informative text explaining the nature of the codec would > not normally require an IETF IPR declaration. Appropriate IPR > declarations for the codec itself would normally be found in files of > the external body defining the codec, in accordance with that external > bodies own IPR rules. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 keith.drage@alcatel-lucent.com Mon Oct 21 05:53:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2824811E81C0 for ; Mon, 21 Oct 2013 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.289 X-Spam-Level: X-Spam-Status: No, score=-110.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9+4lFbHkOqm for ; Mon, 21 Oct 2013 05:53:51 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A821F9339 for ; Mon, 21 Oct 2013 05:53:46 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9LCrfbB028997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2013 07:53:43 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9LCreHg019653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 14:53:40 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 14:53:40 +0200 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , Stephan Wenger Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOziCwbgCQC0d1oU6GtZwB8fICl5n/Gl3g Date: Mon, 21 Oct 2013 12:53:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BC08E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525FC46F.6080508@ericsson.com> <5264BF6E.7070800@ericsson.com> In-Reply-To: <5264BF6E.7070800@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 12:53:59 -0000 Not sure which words you are having problems with. A reasonable interpretation of the IETF rules is that anyone can declare an= ything against any internet-draft / RFC. What we are concentrating on here is relevance, i.e. people can only be req= uired to declare essential IPR against what is covered by the document,a nd= that you cannot be expected to find all the codec IPR declarations being m= ade against the payload type definition. Keith=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 21 October 2013 06:45 > To: Magnus Westerlund; DRAGE, Keith (Keith); Stephan Wenger > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 >=20 > Hi, >=20 > I will not submit this proposal included in a version before=20 > the dead-line. The reason is that I want to discuss this with=20 > my legal department. >=20 > Secondly, I think the WG should consider the implication of=20 > even this informative words about how it has been usually=20 > done. This group is not changing the IETF process in regards=20 > to the IPR. So are we really certain that we are not=20 > misrepresenting a reasonable interpretation of the IPR rules of IETF? >=20 > cheers >=20 > Magnus >=20 > On 2013-10-17 13:05, Magnus Westerlund wrote: > > On 2013-10-17 12:47, DRAGE, Keith (Keith) wrote: > >> The proposal is, in principal, fine. Perhaps "on what is written" > >> could be a bit more specific to be "on the requirements".=20 > Informative=20 > >> text explaining the nature of the codec would not normally=20 > require an=20 > >> IETF IPR declaration. > >> > >> I would also add a sentence something like: > >> > >> "Appropriate IPR declarations for the codec itself would=20 > normally be=20 > >> found in files of the external body defining the codec, in=20 > accordance=20 > >> with that external bodies own IPR rules." > >> > >=20 > > Maybe using "specified" is better than what payload format requires? > > Anyway, updated text proposal: > >=20 > > Note: These IPR rules applies on what is specified in the=20 > RTP Payload=20 > > format Internet Draft (and later RFC), IPRs that relates to a codec=20 > > specification from an external body does not require IETF IPR=20 > > disclosure. Informative text explaining the nature of the=20 > codec would=20 > > not normally require an IETF IPR declaration. Appropriate IPR=20 > > declarations for the codec itself would normally be found=20 > in files of=20 > > the external body defining the codec, in accordance with=20 > that external=20 > > bodies own IPR rules. > >=20 > > Cheers > >=20 > > Magnus Westerlund > >=20 > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > >=20 > ---------------------------------------------------------------------- > > 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 > ---------------------------------------------------------------------- > >=20 > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > >=20 > >=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > = From internet-drafts@ietf.org Mon Oct 21 07:27:33 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6F11E81AF; Mon, 21 Oct 2013 07:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de4+MvFyQ-FP; Mon, 21 Oct 2013 07:27:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2611E85BF; Mon, 21 Oct 2013 07:26:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021142636.29456.86810.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 07:26:36 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 14:27:33 -0000 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 : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-09.txt Pages : 58 Date : 2013-10-21 Abstract: This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-09 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 magnus.westerlund@ericsson.com Mon Oct 21 07:33:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587D11E81AF for ; Mon, 21 Oct 2013 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.974 X-Spam-Level: X-Spam-Status: No, score=-104.974 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5q2eGnAfhlF for ; Mon, 21 Oct 2013 07:33:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E99511E85BC for ; Mon, 21 Oct 2013 07:32:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-dc-52653b12741a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AD.E9.16099.21B35625; Mon, 21 Oct 2013 16:32:51 +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.2.328.9; Mon, 21 Oct 2013 16:32:50 +0200 Message-ID: <52653B67.5010303@ericsson.com> Date: Mon, 21 Oct 2013 16:34:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Stephan Wenger References: <524AE118.3050306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0B92C9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525E3488.2080303@ericsson.com> <525F81F9.2000107@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BA4D2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <525FC46F.6080508@ericsson.com> <5264BF6E.7070800@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0BC08E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BC08E@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvja6wdWqQwbw2founjWcZLS5dPMtk cb1xE7sDs0frs72sHkuW/GTyWLz+PWMAcxSXTUpqTmZZapG+XQJXxsG9l5kLpnBXfHxxlL2B sZ2zi5GTQ0LARGLd7PVsELaYxIV7IDYXh5DAYUaJo69fM0M4yxkldn4/wghSxSugLXFnwxZm EJtFQFXi5sEOMJtNwELi5o9GsEmiAsESN5YdYoOoF5Q4OfMJC4gtIhAv8X/zHHYQm1lAU+LQ 58dgNcIC9hILZh1hhVi2k1li1oFzYEWcAtESy3unsECcJymxbdExqGY9iSlXWxghbHmJ5q2z wY4QAjquoamDdQKj0Cwku2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAED645bfuDsZT50QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdEoXJNr32K+pQvvdv2avbDC/MfJ J/pnr545ubDjt0/swsDilvBn7JfdTDPeZKktv27fdMm5bjqjsnOw5+8DE9ea1D3au3l917cr WQd2hj1+wuy70MPkz6wnYfHLrvvzLFOpnhb/t+FR7IH2O8c/O8ROOl15csUx0+exfT32TZ/N eDfc+SoREiGixFKckWioxVxUnAgAiao3Ei8CAAA= Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 14:33:40 -0000 On 2013-10-21 14:53, DRAGE, Keith (Keith) wrote: > Not sure which words you are having problems with. > > A reasonable interpretation of the IETF rules is that anyone can > declare anything against any internet-draft / RFC. > > What we are concentrating on here is relevance, i.e. people can only > be required to declare essential IPR against what is covered by the > document,a nd that you cannot be expected to find all the codec IPR > declarations being made against the payload type definition. I was worried about making a interpretation beyond the existing rules, and thus warping the rules. I have now submitted a new version with the note. I have done two other changes in the same section. First a rewording that makes it clear that IETF rules may be different compared to what you are used to. I also removed the time expression in regards to timely disclosure, as the rules are not providing any exact time frames. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 internet-drafts@ietf.org Mon Oct 21 10:20:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652F111E86AB; Mon, 21 Oct 2013 10:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhXuA9YUxynD; Mon, 21 Oct 2013 10:20:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1911E85D7; Mon, 21 Oct 2013 10:20:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021172011.32469.95579.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 10:20:11 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 17:20:12 -0000 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 Standard apt-X and Enhanced apt-X= Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-03.txt Pages : 22 Date : 2013-10-21 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-03 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 Lindsay@worldcastsystems.com Mon Oct 21 10:25:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D538A11E86AE for ; Mon, 21 Oct 2013 10:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ5CEXaGk4kV for ; Mon, 21 Oct 2013 10:25:34 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4461311E81ED for ; Mon, 21 Oct 2013 10:25:33 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Oct 2013 18:25:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02FDEAA9@APTSBS.apt.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-payload-rtp-aptx-02 Thread-Index: AQHOzdbw2vjQftbAz0q6DC+dHfSdj5n/aArg References: From: "John Lindsay" To: "Ali C. Begen (abegen)" , Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org Subject: Re: [payload] Review of draft-ietf-payload-rtp-aptx-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 17:25:39 -0000 Hi A new doc has been submitted in response to comments. See notes below. John -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: 20 October 2013 21:57 To: payload@ietf.org Cc: draft-ietf-payload-rtp-aptx@tools.ietf.org Subject: Review of draft-ietf-payload-rtp-aptx-02 The WGLC has ended a few weeks ago and I just completed my review. Everything looks good except a few typos. In general, I would avoid using "ms" until it is defined "milliseconds (ms)". > Changed ms to milliseconds throughout the doc. > Ran doc through spell checker but didn't change very much if you have > specifics let me know Authors, if you can submit a revision by tomorrow (21st of Oct.), we can ship this right away. Thanks, -acbegen Other comments regarding media subtype registration (Thanks to Bjoern Hoehrmann): 1) The registration in Section 6.1 uses the old template.=20 The current template is here: http://tools.ietf.org/html/rfc6838#section-5.6 > Updated please ensure you agree 2) Regarding ptime: It might be better to say "Defaults to 4 (milliseconds)", otherwise some might be confused whether the `ms` is part of the value. > Done 3) Regarding stereo channels: If the value includes characters like `{` then in protocols like HTTP the value would have to be enclosed in double quotes since `{` is not allowed as a bare token in that protocol. The situation may be similar in RTP, and if so, that's not sufficiently clear from the text above. The same goes for some other parameters and other characters like `,`. > I did not change this as these parameters are passed by SDP and are allowed. In addition they are used by everyone who has implemented so far without issue?? Is there some other way that we can use to avoid this potential problem? 4) Regarding embedded-autosync-channels: This should be rephrased to avoid combining "MUST" and "only"; it is not clear whether specifying more than the first channel is optional or forbidden. Same for the `embedded-aux-channels` parameter. >>> Removed the "only" as it still has the same meaning as they are pairs hence it can only refer to Channel 1 or 2 5) Regarding the encoding considerations: This should say "framed".=20 >>> Don't understand issue? Can you give further explanation? 6) "Restrictions on usage" field can say "RTP applications only". > Not sure what is meant by this? >Changed Intended usage: RTP applications only at the bottom of page 14? Can you ensure you agree? 7) Person & email address to contact for further information: This should be "John Lindsay email:lindsay@worldcastsystems.com" > Again cannot see the issue? Is this supposed to be in quotes? > Changed to quotes but not 100% sure this was the issue? > Person & email address to contact for further information: "John =20 > Lindsay email:lindsay@worldcastsystems.com" 8) Author/Change controller: This should say "IETF Payload Working Group delegated from the IESG" > Done From hhhansen@MAYAH.com Mon Oct 21 14:59:25 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648DE11E8732; Mon, 21 Oct 2013 14:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE5lklNFDoCL; Mon, 21 Oct 2013 14:59:20 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9D19011E873F; Mon, 21 Oct 2013 14:59:16 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VYNVK-0004XH-DL; Mon, 21 Oct 2013 23:59:14 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 21 Oct 2013 23:59:12 +0200 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C404B2A@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-03.txt Thread-Index: Ac7Og0Ji/mBrT2/yTwGTLBMr+nqgIwAJSdEA From: "Hans-Heinrich Hansen" To: , X-Df-Sender: MzI2MjQx Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 21:59:25 -0000 We've read this draft! This draft is already implemented in our hardware = codec devices. We hope that this draft will be released soon! Best regards, Hans-Heinrich Hansen Dipl.-Ing., Senior Development Engineer MAYAH Communications GmbH -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]On Behalf Of internet-drafts@ietf.org Sent: Monday, October 21, 2013 7:20 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-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 Standard apt-X and Enhanced = apt-X Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-03.txt Pages : 22 Date : 2013-10-21 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-03 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/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From fluffy@iii.ca Tue Oct 22 04:31:10 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8511E835D; Tue, 22 Oct 2013 04:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmm5hEqNJOgT; Tue, 22 Oct 2013 04:31:04 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02F11E8354; Tue, 22 Oct 2013 04:30:55 -0700 (PDT) Received: from [10.21.74.92] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB94422E200; Tue, 22 Oct 2013 07:30:47 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <5258E8DE.80304@alvestrand.no> Date: Tue, 22 Oct 2013 07:32:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca> References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 11:31:10 -0000 On Oct 12, 2013, at 2:14 AM, Harald Alvestrand = wrote: > On 10/12/2013 12:32 AM, Cullen Jennings wrote: >> How do I signal that the max frame size I can receive is 640 x 480.=20= >>=20 >> My preference as the answer to this question is to say that for VP8 = (not other codecs) you need to support a=3Dimageattr=20 >=20 > My preference is not to do this, and leave it as is. But leaving it as is does not work and it's causing interoperability = problems in the real world.=20 >=20 > We suggested a solution based on an optional imageattr at first (-08 > timeframe), but the comments by Stefan Wenger and Tim Terriberry led = us > to propose this solution instead - the comments we received were of = type > "either this solution or that solution", never "both solutions". >=20 > The codec parameters are intended to guard against streams of too high > complexity, because too complex streams might overload the decoder. >=20 > We have not seen any indication up to now that there exist devices for > which decoding 640x480@30 is reasonable, but decoding 480x640@30 is = not. I have.=20 And lets dig into that a bit deeper - you claim your hardware = implementation is freely available. Show me how in the google hardware = implementation you manage the allocation of the images buffers needed in = a way where there are no limits on the aspect ratio. I'm very serious = here, google keeps saying that the hardware implementation is available. = Show it to me, or at least this part of it.=20 >=20 > There are many reasons to negotiate picture sizes, and the imageattr > mechanism is available for doing so. But once max-fs is present and > mandatory, I think it's not reasonable to require more mandatory > parameters in order to avoid codec overruns. I'm not arguing agains max-fs, I'm saying it is not enough.=20 >=20 > Can you live with the current version? no - it won't work in environments where we need to be able to control = transcoding to existing codecs.=20 >=20 > Harald >=20 >=20 From harald@alvestrand.no Tue Oct 22 04:44:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DF811E81A5; Tue, 22 Oct 2013 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3rA9MVElSK7; Tue, 22 Oct 2013 04:43:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6332511E8354; Tue, 22 Oct 2013 04:43:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A77AA39E12D; Tue, 22 Oct 2013 13:43:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 452STx-NaVc4; Tue, 22 Oct 2013 13:43:51 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8C22539E062; Tue, 22 Oct 2013 13:43:51 +0200 (CEST) Message-ID: <526664FC.7030505@alvestrand.no> Date: Tue, 22 Oct 2013 13:43:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Cullen Jennings References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca> In-Reply-To: <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 11:44:05 -0000 On 10/22/2013 01:32 PM, Cullen Jennings wrote: > On Oct 12, 2013, at 2:14 AM, Harald Alvestrand wrote: > >> On 10/12/2013 12:32 AM, Cullen Jennings wrote: >>> How do I signal that the max frame size I can receive is 640 x 480. >>> >>> My preference as the answer to this question is to say that for VP8 (not other codecs) you need to support a=imageattr >> My preference is not to do this, and leave it as is. > But leaving it as is does not work and it's causing interoperability problems in the real world. Where? > >> We suggested a solution based on an optional imageattr at first (-08 >> timeframe), but the comments by Stefan Wenger and Tim Terriberry led us >> to propose this solution instead - the comments we received were of type >> "either this solution or that solution", never "both solutions". >> >> The codec parameters are intended to guard against streams of too high >> complexity, because too complex streams might overload the decoder. >> >> We have not seen any indication up to now that there exist devices for >> which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not. > I have. > > And lets dig into that a bit deeper - you claim your hardware implementation is freely available. Show me how in the google hardware implementation you manage the allocation of the images buffers needed in a way where there are no limits on the aspect ratio. I'm very serious here, google keeps saying that the hardware implementation is available. Show it to me, or at least this part of it. Cullen, you know that Cisco refused to sign the agreement that Google required in order to get to see the hardware implementation. This hardware design is made available free of charge, not without conditions. > > >> There are many reasons to negotiate picture sizes, and the imageattr >> mechanism is available for doing so. But once max-fs is present and >> mandatory, I think it's not reasonable to require more mandatory >> parameters in order to avoid codec overruns. > I'm not arguing agains max-fs, I'm saying it is not enough. > >> Can you live with the current version? > no - it won't work in environments where we need to be able to control transcoding to existing codecs. This is a new requirement (transcoding to existing codecs). I would like the chairs to state an opinion on whether that's a reasonable requirement. From abegen@cisco.com Tue Oct 22 05:49:21 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF79F11E8375; Tue, 22 Oct 2013 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqx+r2I7kHUm; Tue, 22 Oct 2013 05:49:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30311E839C; Tue, 22 Oct 2013 05:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2924; q=dns/txt; s=iport; t=1382446148; x=1383655748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=whM/WU2HEMOP3DcOd8JWp4FdZVcjZSqul/gAj1POl9A=; b=eXhK3qVTfXCJrFpmH+tQNLqRH2b43th3ywpCTKINq5aMWImeiY4S4/a7 IdzjndnoS4oRnqPhxk9FlJ0/mI88AIfL+Icl1kb78kh3S9Bf+QvYDdpQQ TlARWDEuZwkQuAFe+e2zAEof8lTdqqEIDgE/dNqJe687Wml5WeI6Dc3mn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFANVzZlKtJV2c/2dsb2JhbABZgmYhOL5PS4EnFnSCJQEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FG4dlBgEMuwQEjxMzB4MfgQoDlCqDX5IHgyQ X-IronPort-AV: E=Sophos;i="4.93,548,1378857600"; d="scan'208";a="275087155" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2013 12:49:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9MCn7Ks011096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 12:49:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 07:49:07 -0500 From: "Ali C. Begen (abegen)" To: Harald Alvestrand Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp8-09.txt Thread-Index: AQHOfYU88WV3R6ybhUOqTqfUvw8HJ5lesLoAgAqVqYCAA4x3gIAoWYaAgFvPzQCAAIFWAIAQEBYAgAADKAD//75kjQ== Date: Tue, 22 Oct 2013 12:49:06 +0000 Message-ID: <71F9EBE0-39E7-4766-A840-218D02647A88@cisco.com> References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca>, <526664FC.7030505@alvestrand.no> In-Reply-To: <526664FC.7030505@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" , The IESG Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 12:49:21 -0000 I am guessing below by transcoding you mean changing the resolution not nec= essarily the codec itself. Is that so? > On Oct 22, 2013, at 2:44 PM, "Harald Alvestrand" w= rote: >=20 >> On 10/22/2013 01:32 PM, Cullen Jennings wrote: >>> On Oct 12, 2013, at 2:14 AM, Harald Alvestrand w= rote: >>>=20 >>>> On 10/12/2013 12:32 AM, Cullen Jennings wrote: >>>> How do I signal that the max frame size I can receive is 640 x 480. >>>>=20 >>>> My preference as the answer to this question is to say that for VP8 (n= ot other codecs) you need to support a=3Dimageattr >>> My preference is not to do this, and leave it as is. >> But leaving it as is does not work and it's causing interoperability pro= blems in the real world. >=20 > Where? >=20 >>=20 >>> We suggested a solution based on an optional imageattr at first (-08 >>> timeframe), but the comments by Stefan Wenger and Tim Terriberry led us >>> to propose this solution instead - the comments we received were of typ= e >>> "either this solution or that solution", never "both solutions". >>>=20 >>> The codec parameters are intended to guard against streams of too high >>> complexity, because too complex streams might overload the decoder. >>>=20 >>> We have not seen any indication up to now that there exist devices for >>> which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not= . >> I have. >>=20 >> And lets dig into that a bit deeper - you claim your hardware implementa= tion is freely available. Show me how in the google hardware implementation= you manage the allocation of the images buffers needed in a way where ther= e are no limits on the aspect ratio. I'm very serious here, google keeps sa= ying that the hardware implementation is available. Show it to me, or at le= ast this part of it. >=20 > Cullen, you know that Cisco refused to sign the agreement that Google req= uired in order to get to see the hardware implementation. This hardware des= ign is made available free of charge, not without conditions. >=20 >>=20 >>=20 >>> There are many reasons to negotiate picture sizes, and the imageattr >>> mechanism is available for doing so. But once max-fs is present and >>> mandatory, I think it's not reasonable to require more mandatory >>> parameters in order to avoid codec overruns. >> I'm not arguing agains max-fs, I'm saying it is not enough. >>=20 >>> Can you live with the current version? >> no - it won't work in environments where we need to be able to control t= ranscoding to existing codecs. >=20 > This is a new requirement (transcoding to existing codecs). >=20 > I would like the chairs to state an opinion on whether that's a reasonabl= e requirement. >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From harald@alvestrand.no Tue Oct 22 05:53:45 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F63411E834D; Tue, 22 Oct 2013 05:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.261 X-Spam-Level: X-Spam-Status: No, score=-110.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CCOgdbOCJkM; Tue, 22 Oct 2013 05:53:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DE03211E839A; Tue, 22 Oct 2013 05:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F54739E12D; Tue, 22 Oct 2013 14:53:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkmdHFlRwnOp; Tue, 22 Oct 2013 14:53:34 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2A78239E062; Tue, 22 Oct 2013 14:53:34 +0200 (CEST) Message-ID: <5266754D.1060507@alvestrand.no> Date: Tue, 22 Oct 2013 14:53:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca>, <526664FC.7030505@alvestrand.no> <71F9EBE0-39E7-4766-A840-218D02647A88@cisco.com> In-Reply-To: <71F9EBE0-39E7-4766-A840-218D02647A88@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "payload@ietf.org" , The IESG Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 12:53:45 -0000 On 10/22/2013 02:49 PM, Ali C. Begen (abegen) wrote: > I am guessing below by transcoding you mean changing the resolution not necessarily the codec itself. Is that so? I read it as transcoding to H.264 (or other codecs). If it is a requirement that one always be able to limit the VP8 sender's stream to conform to any restriction that can be expressed in H.264 terms, I think that's a new requirement (and an onerous one). If the transcoder's willing to use cropping or rescaling to achieve the transcode, I don't think there will be an issue. > >> On Oct 22, 2013, at 2:44 PM, "Harald Alvestrand" wrote: >> >>> On 10/22/2013 01:32 PM, Cullen Jennings wrote: >>>> On Oct 12, 2013, at 2:14 AM, Harald Alvestrand wrote: >>>> >>>>> On 10/12/2013 12:32 AM, Cullen Jennings wrote: >>>>> How do I signal that the max frame size I can receive is 640 x 480. >>>>> >>>>> My preference as the answer to this question is to say that for VP8 (not other codecs) you need to support a=imageattr >>>> My preference is not to do this, and leave it as is. >>> But leaving it as is does not work and it's causing interoperability problems in the real world. >> Where? >> >>>> We suggested a solution based on an optional imageattr at first (-08 >>>> timeframe), but the comments by Stefan Wenger and Tim Terriberry led us >>>> to propose this solution instead - the comments we received were of type >>>> "either this solution or that solution", never "both solutions". >>>> >>>> The codec parameters are intended to guard against streams of too high >>>> complexity, because too complex streams might overload the decoder. >>>> >>>> We have not seen any indication up to now that there exist devices for >>>> which decoding 640x480@30 is reasonable, but decoding 480x640@30 is not. >>> I have. >>> >>> And lets dig into that a bit deeper - you claim your hardware implementation is freely available. Show me how in the google hardware implementation you manage the allocation of the images buffers needed in a way where there are no limits on the aspect ratio. I'm very serious here, google keeps saying that the hardware implementation is available. Show it to me, or at least this part of it. >> Cullen, you know that Cisco refused to sign the agreement that Google required in order to get to see the hardware implementation. This hardware design is made available free of charge, not without conditions. >> >>> >>>> There are many reasons to negotiate picture sizes, and the imageattr >>>> mechanism is available for doing so. But once max-fs is present and >>>> mandatory, I think it's not reasonable to require more mandatory >>>> parameters in order to avoid codec overruns. >>> I'm not arguing agains max-fs, I'm saying it is not enough. >>> >>>> Can you live with the current version? >>> no - it won't work in environments where we need to be able to control transcoding to existing codecs. >> This is a new requirement (transcoding to existing codecs). >> >> I would like the chairs to state an opinion on whether that's a reasonable requirement. >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. From abegen@cisco.com Tue Oct 22 10:31:04 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C947211E82A9 for ; Tue, 22 Oct 2013 10:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuHdiNhEmHmU for ; Tue, 22 Oct 2013 10:30:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27011E81FB for ; Tue, 22 Oct 2013 10:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1663; q=dns/txt; s=iport; t=1382463058; x=1383672658; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ifklvzj1sIQho5eFPEMbJq1hrHWEzl9KSX3Lx3Kppa0=; b=ilIEWgmwUKIuCyhSO8lp83OYNOgm//EM7+xd9cUKx7deb69RpoMT2kYT h7b8HXsh+jNZypnty1Yjiw3NnV+pAxf7a4FjqsMYJTNyZ2B+OCjFLmhab 02QQTNB/KabGCUGqTfGJG8mOCO+4Au2vPB99S9gPsX3s/wfM+P910CX6T 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAKq1ZlKtJV2Y/2dsb2JhbABZgmYhOFS+SoEnFnSCJQEBAQMBOj8FCwIBCCIUEDIlAgQKBAUIh3gGAQy6UI4FgRYCMQeDH4EKA5k4kFiDJIFxOQ X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208";a="275025735" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 22 Oct 2013 17:30:57 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MHUvLC017843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 17:30:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 12:30:57 -0500 From: "Ali C. Begen (abegen)" To: John Lindsay Thread-Topic: Review of draft-ietf-payload-rtp-aptx-02 Thread-Index: AQHOzdbw2vjQftbAz0q6DC+dHfSdj5n/aArggAHpBwA= Date: Tue, 22 Oct 2013 17:30:57 +0000 Message-ID: References: <8C4E0C2409735E4FBC22D754A238F94D02FDEAA9@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02FDEAA9@APTSBS.apt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <80CD5B563845FA42A4BB4EE06575AD1F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [payload] Review of draft-ietf-payload-rtp-aptx-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 17:31:05 -0000 John, A few errors still exist (I dont think these are showstoppers but IESG tend= s to be picky about these when the document is shipped w/o fixing them). > 1) The registration in Section 6.1 uses the old template.=20 > The current template is here: > http://tools.ietf.org/html/rfc6838#section-5.6 >> Updated please ensure you agree You forgot the following item (insert it based on the template): Fragment identifier considerations: None > 5) Regarding the encoding considerations: This should say "framed".=20 >>>> Don't understand issue? Can you give further explanation? Encoding considerations: This media type is framed in RTP and contains bina= ry data; see Section 4.8 of [RFC6838]. > 6) "Restrictions on usage" field can say "RTP applications only". >> Not sure what is meant by this? >> Changed Intended usage: RTP applications only at the bottom of page 14? > Can you ensure you agree? Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is= only defined for transfer via RTP [RFC3550]. >=20 > 7) Person & email address to contact for further information: This > should be "John Lindsay email:lindsay@worldcastsystems.com" >> Again cannot see the issue? Is this supposed to be in quotes? >> Changed to quotes but not 100% sure this was the issue? >> Person & email address to contact for further information: "John =20 >> Lindsay email:lindsay@worldcastsystems.com" I am sorry. Please remove the quotes. I thought the email was missing. The submission is now closed but will open in two weeks. Please update the = draft at that time. Thanks, -acbegen From fluffy@iii.ca Tue Oct 22 11:30:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91BF11E8211; Tue, 22 Oct 2013 11:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2x5gerC3E1W; Tue, 22 Oct 2013 11:29:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 52F3911E81F9; Tue, 22 Oct 2013 11:29:56 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E5C722E256; Tue, 22 Oct 2013 14:29:46 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <526664FC.7030505@alvestrand.no> Date: Tue, 22 Oct 2013 12:29:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <32EE1C2A-EFC9-49F9-9FF3-7B8B32C5BF54@iii.ca> References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca> <526664FC.7030505@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 18:30:06 -0000 On Oct 22, 2013, at 5:43 AM, Harald Alvestrand = wrote: >>> Can you live with the current version? >> no - it won't work in environments where we need to be able to = control transcoding to existing codecs. >=20 > This is a new requirement (transcoding to existing codecs). >=20 > I would like the chairs to state an opinion on whether that's a = reasonable requirement. So let me get this right, google is blocking adding the imageattr = because they don't want it to be possible to make a system with an RTP = transcoder from H.264 to VP8. This just gets better and better From harald@alvestrand.no Tue Oct 22 12:37:00 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3D21E8083; Tue, 22 Oct 2013 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HbMMTQqX9TW; Tue, 22 Oct 2013 12:36:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 956A221E8056; Tue, 22 Oct 2013 12:36:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A05B39E149; Tue, 22 Oct 2013 21:36:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goV3q7ib5eGA; Tue, 22 Oct 2013 21:36:45 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 77E1539E062; Tue, 22 Oct 2013 21:36:45 +0200 (CEST) Message-ID: <5266D3CD.5060608@alvestrand.no> Date: Tue, 22 Oct 2013 21:36:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Cullen Jennings References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <5258E8DE.80304@alvestrand.no> <66C4765E-2FA0-49B9-B796-A710868A0FEC@iii.ca> <526664FC.7030505@alvestrand.no> <32EE1C2A-EFC9-49F9-9FF3-7B8B32C5BF54@iii.ca> In-Reply-To: <32EE1C2A-EFC9-49F9-9FF3-7B8B32C5BF54@iii.ca> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 19:37:00 -0000 On 10/22/2013 08:29 PM, Cullen Jennings wrote: > On Oct 22, 2013, at 5:43 AM, Harald Alvestrand wrote: > >>>> Can you live with the current version? >>> no - it won't work in environments where we need to be able to control transcoding to existing codecs. >> This is a new requirement (transcoding to existing codecs). >> >> I would like the chairs to state an opinion on whether that's a reasonable requirement. > So let me get this right, google is blocking adding the imageattr because they don't want it to be possible to make a system with an RTP transcoder from H.264 to VP8. This just gets better and better > That's an interesting interpretation! Cullen, I think we need to chat about this directly. -- Surveillance is pervasive. Go Dark. From ron.even.tlv@gmail.com Tue Oct 22 14:58:42 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385611E8244; Tue, 22 Oct 2013 14:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB4CvLxQZC9D; Tue, 22 Oct 2013 14:58:41 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9111E822C; Tue, 22 Oct 2013 14:58:40 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so4608357ead.31 for ; Tue, 22 Oct 2013 14:58:38 -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=GNpBhlAb8EaKgrbb7TxEENV2Vgzdropj5w8sNLtvhl0=; b=EMvwT+b8mmqlfZkznvcYTwHkqLMc0rteUSeJVMSA16BtJv6y2W18+6MyWQCOKgp974 x1umo6DEr6WaI5H/VkPbrT3EwA3DBRzQ/3byNlXEH5EIPlqyWxyvpqmZf+Wu4u62jGy/ WXOpmLDyeITPSBjVNThoYBxyQ91UkLvIrDzV/Kj/WrVcM1UlQz1QVqvO1dGRqHaJXEDw spGb3k32SBwpTDm+Y7ZeuaEw9zYyPfbtpgfN9fPw7ULsmMWzgIAt2WRm4J12zrL71a1P uXMa1/CY9Mr9/cKqfSL37d+N04oiyyM8vAQud1Mi1xGTtL46bJuX9LYLd7Jh86wNwv8b K9mw== X-Received: by 10.15.77.132 with SMTP id p4mr1484149eey.95.1382479118254; Tue, 22 Oct 2013 14:58:38 -0700 (PDT) Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id b42sm61756477eem.9.2013.10.22.14.58.35 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Oct 2013 14:58:37 -0700 (PDT) From: "Roni Even" To: Date: Wed, 23 Oct 2013 00:55:26 +0300 Message-ID: <090501cecf71$6d634740$4829d5c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0906_01CECF8A.92B0F470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7PcRoF2W2BSJUEQ0itKDuVz8sR2w== Content-Language: en-us Cc: payload@ietf.org Subject: [payload] AVTcore agenda for IETF88 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 21:58:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0907_01CECF8A.92B0F470" ------=_NextPart_001_0907_01CECF8A.92B0F470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The proposed agenda for the AVTcore session in Vancouver is uploaded. We allocated some time for Payload WG. Please send any comments to the chairs Roni Even AVTcore co-chair ------=_NextPart_001_0907_01CECF8A.92B0F470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The proposed = agenda for the AVTcore session in Vancouver is uploaded. We allocated = some time for Payload WG.

Please send = any comments to the chairs

Roni = Even

AVTcore = co-chair

------=_NextPart_001_0907_01CECF8A.92B0F470-- ------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: text/html; name="agenda.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="agenda.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Thursday, 7 November 2013 at 15:20-17:20 (Regency C)

15:20 AVTCore Status UpdateChairs
15:35 Sending Multiple Media Streams in a Single RTP = SessionMagnus
= draft-ietf-avtcore-rtp-multi-stream-01
15:45 Grouping RTCP Reception Statistics and Other = FeedbackMagnus=20
draft-ietf-avtcore-rtp-multi-stream-optimisation-00
15:55 Circuit Breakers for Unicast SessionsZaheduzzaman Sarker=20
draft-ietf-avtcore-rtp-circuit-breakers-03
16:25 Payload Status UpdateChairs
16:35 RTP Payload Format for Opus Speech and Audio CodecJM Valin
draft-ie= tf-payload-rtp-opus-01
16:50 End
------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: text/plain; name="a1311.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a1311.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Thursday, 7 November 2013 at 15:20-17:20 (Regency C) ---------------------------------------------------- 15:20 AVTCore Status Update (Chairs, 15) 15:35 Sending Multiple Media Streams in a Single RTP Session(Magnus, 10) draft-ietf-avtcore-rtp-multi-stream-01 15:45 Grouping RTCP Reception Statistics and Other Feedback(Magnus , 10) draft-ietf-avtcore-rtp-multi-stream-optimisation-00 15:55 Circuit Breakers for Unicast Sessions (Zaheduzzaman Sarker , 30) draft-ietf-avtcore-rtp-circuit-breakers-03 16:25 Payload Status Update (Chairs, 10) 16:35 RTP Payload Format for Opus Speech and Audio Codec(JM Valin, 15) draft-ietf-payload-rtp-opus-01 16:50 End ------=_NextPart_000_0906_01CECF8A.92B0F470-- From wwwrun@rfc-editor.org Mon Oct 28 15:04:34 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB111E80E7; Mon, 28 Oct 2013 15:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luW7bPzSU9Qh; Mon, 28 Oct 2013 15:04:33 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 052E621F9E26; Mon, 28 Oct 2013 15:04:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 10003726004; Mon, 28 Oct 2013 14:55:36 -0700 (PDT) To: weix@avaya.com, stewe@stewe.org, yekui.wang@huawei.com, ts@thomas-schierl.de, alex@vidyo.com From: RFC Errata System Message-Id: <20131028215536.10003726004@rfc-editor.org> Date: Mon, 28 Oct 2013 14:55:36 -0700 (PDT) Cc: iesg@ietf.org, payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] [Errata Verified] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 22:04:34 -0000 The following errata report has been verified for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711 -------------------------------------- Status: Verified Type: Technical Reported by: Xiaohui Wei (Joanne) Date Reported: 2013-08-26 Verified by: Richard Barnes (IESG) Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From rlb@ipv.sx Mon Oct 28 15:04:46 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C187221F9E37 for ; Mon, 28 Oct 2013 15:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6onn8JnVe25m for ; Mon, 28 Oct 2013 15:04:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F211E80E7 for ; Mon, 28 Oct 2013 15:04:42 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id gq1so4385352obb.31 for ; Mon, 28 Oct 2013 15:04:41 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yrcXeIMYF00iPwJXdknBs2v8sshu7t6emTru0h60H1U=; b=Nu01iO++6VxA8CFmvbMK51VlPpeCq9y4tHqRyTSgyu1vTxA5BLshBwLFobiF17yAWT oNEYFpxpVI6xp1ixCS6RpgmAByywK8O6/yB/01uxT/fh/L4Ro2wdOy6LUnUQ9+EOk32i rPiMt5ZkHA0j0dD6D+5b6HWqxQ8eABQt6FlGubR93BkJOw9+iJKAhp8ARNGOIsDyfNZc Qhk7IY3DfR7r0mQJsr6nsi7+6klESKsB4oGqELrt5jCl4KJy0GW6K0GJ8n/GuHL6msX0 YCHqA/1jxLJQrdclbbypYY7r1v1cAY3uPOaIIqbHwovAZo5oVqNH4PM1wCDtveQzyXsE cLSw== X-Gm-Message-State: ALoCoQkkJw5FqCZBTt6D4fgFV2aaXkwOY/i9ijBSkpja6w+gUdGmhmHA6Tfp7JYNzfwZombpAWH7 MIME-Version: 1.0 X-Received: by 10.60.45.227 with SMTP id q3mr11413285oem.10.1382997881383; Mon, 28 Oct 2013 15:04:41 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Mon, 28 Oct 2013 15:04:41 -0700 (PDT) In-Reply-To: <000601cec762$95bd0bc0$c1372340$@gmail.com> References: <20130826162642.54E0B8E018@rfc-editor.org> <8BA7D4CEACFFE04BA2D902BF11719A83385B3410@nasanexd02f.na.qualcomm.com> <70DC7CFE-F7CE-4FD6-BD62-3911BDE33959@vidyo.com> <008901cec64e$1c865f00$55931d00$@gmail.com> <31B495FC-06CA-43C3-AF15-5530D3D3E463@vidyo.com> <8BA7D4CEACFFE04BA2D902BF11719A83385B4C3F@nasanexd02f.na.qualcomm.com> <000601cec762$95bd0bc0$c1372340$@gmail.com> Date: Mon, 28 Oct 2013 18:04:41 -0400 Message-ID: From: Richard Barnes To: Roni Even Content-Type: multipart/alternative; boundary=001a11c245f671fddc04e9d449aa Cc: Jonathan Lennox , ts@thomas-schierl.de, "payload@ietf.org" , RFC Errata System Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 22:04:46 -0000 --001a11c245f671fddc04e9d449aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, all. I have marked this as "Verified". On Sat, Oct 12, 2013 at 11:49 AM, Roni Even wrote: > OK with me**** > > Roni Even**** > > ** ** > > *From:* Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > *Sent:* 11 October, 2013 6:47 PM > *To:* Jonathan Lennox; Roni Even > *Cc:* Alex Eleftheriadis; ; ; RFC > Errata System > *Subject:* RE: [payload] [Technical Errata Reported] RFC6190 (3711)**** > > ** ** > > Exactly =96 as it is just a summary of the field specified in the SVC spe= c, > it is basically non-normative.**** > > ** ** > > Also, the fields in the 4-byte NAL unit header has been carefully designe= d > at JVT when SVC was developed, to avoid the possibility of certain bit > patterns that are used as start codes in some systems.**** > > ** ** > > Considering all these factors, the errata should be approved (or whatever > the right process is).**** > > ** ** > > BR, YK**** > > ** ** > > *From:* Jonathan Lennox [mailto:jonathan@vidyo.com ] > *Sent:* Friday, October 11, 2013 8:41 AM > *To:* Roni Even > *Cc:* Alex Eleftheriadis; Wang, Ye-Kui; ; < > payload@ietf.org>; RFC Errata System > *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)**** > > ** ** > > This error is in section 1.1.3 of RFC 6190, which explicitly states that > it is an summary of field definitions specified by the H.264 spec.**** > > ** ** > > Thus, I would hope (and expect) that most implementations are following > the H.264 definition of this bit, not the RFC 6190 definition.**** > > ** ** > > On Oct 11, 2013, at 2:49 AM, Roni Even **** > > wrote:**** > > ** ** > > Since I saw feedback from Alex and Ye-Kui, I am wondering what the > implementation are currently doing.**** > > Even though it make sense to change the current meaning I do not think it > is wrong to keep the current values if was implemented this way.**** > > Thanks**** > > Roni Even**** > > Payload WG co-chair**** > > **** > > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Alex Eleftheriadis > *Sent:* 11 October, 2013 8:58 AM > *To:* Wang, Ye-Kui > *Cc:* ts@thomas-schierl.de; payload@ietf.org; RFC Errata System > *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)**** > > **** > > I agree; the intended interpretation of the flag is evident by its name. > It should, however, be marked as an error. > > --AE**** > > > On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" > wrote:**** > > The erratum is correct, though to me it is obviously a (relatively minor) > typo.**** > > **** > > BR, YK**** > > **** > > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org > ] *On Behalf Of *Richard Barnes > *Sent:* Thursday, October 10, 2013 12:45 PM > *To:* RFC Errata System > *Cc:* yekui.wang@huawei.com; payload@ietf.org; ts@thomas-schierl.de > *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)**** > > **** > > Do any PAYLOAD folks have a comment on this? This seems like a pretty > major erratum, if correct.**** > > **** > > Thanks,**** > > --Richard**** > > **** > > On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote:**** > > The following errata report has been submitted for RFC6190, > "RTP Payload Format for Scalable Video Coding". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6190&eid=3D3711 > > -------------------------------------- > Type: Technical > Reported by: Xiaohui Wei (Joanne) > > Section: 1.1.3 > > Original Text > ------------- > N: 1 bit > no_inter_layer_pred_flag. This flag specifies, when present in > a coded slice NAL unit, whether inter-layer prediction may be > used for decoding the coded slice (when equal to 1) or not > (when equal to 0). > > Corrected Text > -------------- > N: 1 bit > no_inter_layer_pred_flag. This flag specifies, when present in > a coded slice NAL unit, whether inter-layer prediction may be > used for decoding the coded slice (when equal to 0) or not > ^ > (when equal to 1). > ^ > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6190 (draft-ietf-avt-rtp-svc-27) > -------------------------------------- > Title : RTP Payload Format for Scalable Video Coding > Publication Date : May 2011 > Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis > Category : PROPOSED STANDARD > Source : Audio/Video Transport Payloads > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG**** > > **** > > _______________________________________________ > 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 > > --001a11c245f671fddc04e9d449aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks, all.=A0 I have marked this as "Verified"= .


On= Sat, Oct 12, 2013 at 11:49 AM, Roni Even <ron.even.tlv@gmail.com= > wrote:

OK with me=

Roni Even

=A0

From:= Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
Sent: 11 October, 2013 6:47 PM
To: Jonathan Lennox; Roni E= ven
Cc: Alex Eleftheriadis; <ts@thomas-schierl.de>; <payload@ietf.org>; RFC Errata = System
Subject: RE: [payload] [Technical Errata Reported] RFC6190 (3711)=

=A0

Exactly =96 as it is just a summary of the field specified = in the SVC spec, it is basically non-normative.

=A0=

Also, the fields in the 4-byte NAL unit header has been carefully d= esigned at JVT when SVC was developed, to avoid the possibility of certain = bit patterns that are used as start codes in some systems.

=A0=

Considering all these factors, the errata should be approved (or wh= atever the right process is).

=A0=

BR, YK

=A0=

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Friday, October 11, 2013 8:41 AM
To: Roni Even
Cc: Alex Eleftheriadis; Wang, Ye-Kui; <ts@thomas-schierl.de>; <payload@ietf.org>; RFC Er= rata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)=

=A0

This error is in section 1.1.3 of RFC 6190, which explicitly states th= at it is an summary of field definitions specified by the H.264 spec.

=A0

Thus, I woul= d hope (and expect) that most implementations are following the H.264 defin= ition of this bit, not the RFC 6190 definition.

=A0<= /p>

On Oct 11, 2013, a= t 2:49 AM, Roni Even <ron.even.tlv@gmail.com>

=A0wrote:<= /u>

<= span lang=3D"EN-CA">=A0

Since I saw feedback from Alex and Ye-Kui,= =A0I am wondering what the =A0implementation are currently doing.

Even though it= make sense to change the current meaning I do not think it is wrong to kee= p the current values if was implemented this way.

Thanks<= u>

Roni Even

Payload WG co-= chair

=A0

=A0

I agree= ; the intended interpretation of the flag is evident by its name. It should= , however, be marked as an error.=A0

--AE


On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui&q= uot; <yekuiw@qti.qualcomm.com> wrote:

The erratum is correct, though= to me it is obviously a (relatively minor) typo.

=A0<= /u>

= BR, YK

=A0<= /u>

From:=A0payload-bounce= s@ietf.org=A0[mailto:payload-bounce= s@ietf.org]=A0On Behalf Of=A0Ri= chard Barnes
Sent:=A0Thursday, October 10, 2013 12:45 PM
To:=A0RFC Errata System
Cc:=A0yekui.wang@huawei.com;=A0payload@ietf.or= g;=A0ts@thomas-schierl.de Subject:=A0Re: [payload] [Technical Errata Reported] RF= C6190 (3711)

=A0

Do any = PAYLOAD folks have a comment on this? =A0This seems like a pretty major err= atum, if correct.

=A0

Thanks,

--Richard

=

=A0

On Mon, Aug 26, 2013 = at 12:26 PM, RFC Errata System <rfc-editor@rfc-editor.o= rg> wrote:

The following errata report has been subm= itted for RFC6190,
"RTP Payload Format for Scalable Video Coding&qu= ot;.

--------------------------------------
You may review the re= port below and at:
http://www.rfc-edit= or.org/errata_search.php?rfc=3D6190&eid=3D3711

------= --------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <weix@avaya.c= om>

Section: 1.1.3

Original Text
-----------= --
=A0 =A0N: =A0 =A01 bit
=A0 =A0 =A0 =A0 =A0no_inter_layer_pred_flag. =A0T= his flag specifies, when present in
=A0 =A0 =A0 =A0 =A0a coded slice NAL= unit, whether inter-layer prediction may be
=A0 =A0 =A0 =A0 =A0used for= decoding the coded slice (when equal to 1) or not
=A0 =A0 =A0 =A0 =A0(when equal to 0).

Corrected Text
------------= --
=A0 =A0N: =A0 =A01 bit
=A0 =A0 =A0 =A0 =A0no_inter_layer_pred_flag= . =A0This flag specifies, when present in
=A0 =A0 =A0 =A0 =A0a coded sli= ce NAL unit, whether inter-layer prediction may be
=A0 =A0 =A0 =A0 =A0used for decoding the coded slice (when equal to 0) or n= ot
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0(wh= en equal to 1).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
Notes
-----


Instructions:
-------------
This errata is currently posted as "= Reported". If necessary, please
use "Reply All" to discus= s whether it should be verified or
rejected. When a decision is reached,= the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

-= -------------------------------------
RFC6190 (draft-ietf-avt-rtp-svc-27= )
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 = =A0 =A0 : RTP Payload Format for Scalable Video Coding
Publication Date =A0 =A0: May 2011
Author(s) =A0 =A0 =A0 =A0 =A0 : S. We= nger, Y.-K. Wang, T. Schierl, A. Eleftheriadis
Category =A0 =A0 =A0 =A0 = =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Audio/Vid= eo Transport Payloads
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Real-time Ap= plications and Infrastructure
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG<= u>

=A0<= /p>

_______________________________________________
p= ayload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= u>

____________= ___________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload=

=A0


___________________________________= ____________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload


--001a11c245f671fddc04e9d449aa--