From nobody Mon Jun 1 02:45:31 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD81A9127; Mon, 1 Jun 2015 02:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_jgpBgwZWam; Mon, 1 Jun 2015 02:45:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8761B1A911E; Mon, 1 Jun 2015 02:45:27 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-20-556c29b51ba4 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.19.17665.5B92C655; Mon, 1 Jun 2015 11:45:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.210.2; Mon, 1 Jun 2015 11:45:13 +0200 Message-ID: <556C29A9.5070409@ericsson.com> Date: Mon, 1 Jun 2015 11:45:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , Ben Campbell , Stephan Wenger References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> In-Reply-To: <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2J7oO5WzZxQg3kflC3md55mt3h8aimb xaWLZ5ksrjduYrd4suYYswOrx5IlP5k8Zu18wuKxaOozRo/F698zBrBEcdmkpOZklqUW6dsl cGWcnvKRuWCHZEXT8soGxg0iXYycHBICJhLdzx8zQthiEhfurWfrYuTiEBI4wijxfNJ1Fghn GaNE37onQBkODl4BbYmFPVkgDSwCKhJ/j95lArHZBCwkbv5oZAOxRQWiJKY+XscCYvMKCEqc nPkEzBYRKJB4tncfWD2zQJXEu5W/wGxhAXeJCX2voXZdZJQ4Ofk92CBOAW+JZe8/skM0WEjM nH+eEcKWl2jeOpsZxBYCuqehqYN1AqPgLCT7ZiFpmYWkZQEj8ypG0eLU4uLcdCNjvdSizOTi 4vw8vbzUkk2MwAA/uOW37g7G1a8dDzEKcDAq8fAu3JMdKsSaWFZcmXuIUZqDRUmc16srJFRI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY8GsnOumJo5zzKwbVFSNrCO6muea255niAv02MV1 ZJujL6eHYEbVc4YJgv1WwdO+mBeGat5N+bs5vvBEgd3mkC5rn2t3n6yqDdNstX6SGf/Had+B dWacHiePH5hbb3rDueVBiOBVr3cBd/SFM6U3psydfHQx6ymrisBtSqnLJNJPNnG+VmdXYinO SDTUYi4qTgQATFxO/lECAAA= Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 09:45:30 -0000 Hi, I looked at the changes and one thing made me react. Wang, Ye-Kui skrev den 2015-05-30 00:24: > Hi Ben, > > Thanks for your careful review and the detailed comments. Our answers > to your other questions are in below, each starting with "[YK]". We > will submit the new version containing these changes soon. > > *** Substantive *** > > -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax > violation." > > Does that mean that setting the bit is a syntax violation in itself, > or that it _indicates_ a syntax violation? As worded, it sound like > the former, but later examples seem to suggest the latter. (e.g. last > sentence of 4.4.3) > > [YK]: It is the former from the HEVC spec point of view. The HEVC > spec just says that the value of the bit shall be equal to 0. A MANE > (in the context of this memo) can use the bit to indicate a syntax > violation, as you noticed in the last sentence of 4.4.3. We will > change the wording as follows (plus the addition of RFC 3828 as an > informative reference) unless there is objection: > > [Current wording] forbidden_zero_bit. Required to be zero in [HEVC]. > HEVC declares a value of 1 as a syntax violation. Note that the > inclusion of this bit in the NAL unit header is to enable transport > of HEVC video over MPEG-2 transport systems (avoidance of start code > emulations) [MPEG2S]. > > [Changed wording] forbidden_zero_bit. Required to be zero in [HEVC]. > Note that the inclusion of this bit in the NAL unit header was to > enable transport of HEVC video over MPEG-2 transport systems > (avoidance of start code emulations) [MPEG2S]. In the context of > this memo, the value 1 MAY be used to indicate a syntax violation. > For example, when RTP is transported over UDP-lite [RFC3828] and the > receiver decides to feed the video decoder NAL unit(s) where the > corresponding UDP-lite packet failed a checksum test, then this bit > can be set to alarm the decoder of possible bit errors. The example in the new wording is not practically possible. The point of UDP-Lite is that you calculate the checksum only over a selected initial part of the IP/UDP packet. Any checksum violations will commonly result in that the whole packet is discarded. What UDP-Lite is offering is that any error in the unprotected part will not result in the packet being discarded. However, the receiver has no knowledge if the unprotected part of the UDP payload was damaged or not. Thus, no information is available to set the syntax violation bit. Thus, the example should be removed. No practical example came to mind, except maybe for a RTP middlebox forwarding a known uncomplete fragmented NALU where the end is missing. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 1 07:00:43 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EE01ACDFA; Mon, 1 Jun 2015 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMQH1HoygZ60; Mon, 1 Jun 2015 07:00:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE421A0358; Mon, 1 Jun 2015 07:00:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t51E0POt012587 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Jun 2015 09:00:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 01 Jun 2015 09:00:24 -0500 Message-ID: In-Reply-To: <556C29A9.5070409@ericsson.com> References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 14:00:42 -0000 On 1 Jun 2015, at 4:45, Magnus Westerlund wrote: > Hi, > > I looked at the changes and one thing made me react. > > > Wang, Ye-Kui skrev den 2015-05-30 00:24: >> Hi Ben, >> >> Thanks for your careful review and the detailed comments. Our answers >> to your other questions are in below, each starting with "[YK]". We >> will submit the new version containing these changes soon. >> >> *** Substantive *** >> >> -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax >> violation." >> >> Does that mean that setting the bit is a syntax violation in itself, >> or that it _indicates_ a syntax violation? As worded, it sound like >> the former, but later examples seem to suggest the latter. (e.g. last >> sentence of 4.4.3) >> >> [YK]: It is the former from the HEVC spec point of view. The HEVC >> spec just says that the value of the bit shall be equal to 0. A MANE >> (in the context of this memo) can use the bit to indicate a syntax >> violation, as you noticed in the last sentence of 4.4.3. We will >> change the wording as follows (plus the addition of RFC 3828 as an >> informative reference) unless there is objection: >> >> [Current wording] forbidden_zero_bit. Required to be zero in [HEVC]. >> HEVC declares a value of 1 as a syntax violation. Note that the >> inclusion of this bit in the NAL unit header is to enable transport >> of HEVC video over MPEG-2 transport systems (avoidance of start code >> emulations) [MPEG2S]. >> >> [Changed wording] forbidden_zero_bit. Required to be zero in [HEVC]. >> Note that the inclusion of this bit in the NAL unit header was to >> enable transport of HEVC video over MPEG-2 transport systems >> (avoidance of start code emulations) [MPEG2S]. In the context of >> this memo, the value 1 MAY be used to indicate a syntax violation. >> For example, when RTP is transported over UDP-lite [RFC3828] and the >> receiver decides to feed the video decoder NAL unit(s) where the >> corresponding UDP-lite packet failed a checksum test, then this bit >> can be set to alarm the decoder of possible bit errors. > > The example in the new wording is not practically possible. The point > of UDP-Lite is that you calculate the checksum only over a selected > initial part of the IP/UDP packet. Any checksum violations will > commonly result in that the whole packet is discarded. What UDP-Lite > is offering is that any error in the unprotected part will not result > in the packet being discarded. However, the receiver has no knowledge > if the unprotected part of the UDP payload was damaged or not. Thus, > no information is available to set the syntax violation bit. > > Thus, the example should be removed. No practical example came to > mind, except maybe for a RTP middlebox forwarding a known uncomplete > fragmented NALU where the end is missing. So is there ever value in setting the "forbidden_zero_bit"? Ben. From nobody Mon Jun 1 10:18:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670D51ACEED; Mon, 1 Jun 2015 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz22MkMIfEW1; Mon, 1 Jun 2015 10:18:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF9B1B2D05; Mon, 1 Jun 2015 10:18:32 -0700 (PDT) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 17:18:29 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 17:18:29 +0000 From: Stephan Wenger To: Ben Campbell , Magnus Westerlund Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Thread-Index: AQHQlzleVQ2EUNilNkOMutwxhnHkBp2ORqcAgAB/qACABMeqAIAD4uSAgABHTAD//8HwAA== Date: Mon, 1 Jun 2015 17:18:28 +0000 Message-ID: References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.5.177.48] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0701MB1275; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1275; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377424004)(199003)(51704005)(479174004)(40100003)(77156002)(2656002)(50986999)(5001860100001)(62966003)(76176999)(54356999)(87936001)(2900100001)(105586002)(68736005)(102836002)(2950100001)(99286002)(92566002)(86362001)(19580395003)(19580405001)(230783001)(5001830100001)(189998001)(106116001)(46102003)(5002640100001)(64706001)(93886004)(5001960100002)(122556002)(101416001)(97736004)(4001540100001)(66066001)(5001770100001)(106356001)(36756003)(81156007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 17:18:28.3917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1275 Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:18:35 -0000 Hi, The UDP-lite text was from me. After re-reading it, I agree with Magnus that it is incorrect as written. However: One can use (and some folks have used) the forbidden zero bit to advise the decoder that there *may* be bit errors in the payload. Similar markers have been used in H.324/M carrying H.263 for ages, and it was always a mess that there was no way in the bitstream to tell a (chip-based) decoder to be ready for the worst... In at least one implementation I am aware of, H.264=B9s forbidden zero bit has been used for precisely this purpose. In that case, the UDP-lite checksum covered only the UDP and RTP headers, and left the H.264 payload unprotected. The receiver was made aware that there may be something fishy in the H.264 NAL unit by the forbidden zero bit set in all such NAL units. Due to the failure of UDP-lite in general, this product never made any significant market impact, but it is my understanding that the vendors at that time had kind-of agreed (in IMTC?) that this would be the right thing to do. There were also ideas to set the forbidden zero bit in gateways, just as Magnus described. As a resolution, I can think of two ways forward, and I don=B9t really have a preference: 1. Remove the note. Has the advantage of being correct, but may lead people on the wrong path, just as perhaps Ben may be right now) 2. Change the note: OLD: For example, when RTP is transported over UDP-lite [RFC3828] and the receiver decides to feed the video decoder NAL unit(s) where the corresponding UDP-lite packet failed a checksum test, then this bit can be set to alarm the decoder of possible bit errors. NEW: For example, when RTP is transported over UDP-lite [RFC3828] and the receiver decides to feed the video decoder NAL unit(s) where the corresponding UDP-lite packet checksum-protected only parts of the packet (and therefore the the remainder of the packet can include bit errors with a likelyhood Several orders of magnitude higher than a UDP packet would have) then this bit can be set to alarm the decoder of possible bit errors. Stephan On 6/1/15, 07:00, "Ben Campbell" wrote: >On 1 Jun 2015, at 4:45, Magnus Westerlund wrote: > >> Hi, >> >> I looked at the changes and one thing made me react. >> >> >> Wang, Ye-Kui skrev den 2015-05-30 00:24: >>> Hi Ben, >>> >>> Thanks for your careful review and the detailed comments. Our answers >>> to your other questions are in below, each starting with "[YK]". We >>> will submit the new version containing these changes soon. >>> >>> *** Substantive *** >>> >>> -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a syntax >>> violation." >>> >>> Does that mean that setting the bit is a syntax violation in itself, >>> or that it _indicates_ a syntax violation? As worded, it sound like >>> the former, but later examples seem to suggest the latter. (e.g. last >>> sentence of 4.4.3) >>> >>> [YK]: It is the former from the HEVC spec point of view. The HEVC >>> spec just says that the value of the bit shall be equal to 0. A MANE >>> (in the context of this memo) can use the bit to indicate a syntax >>> violation, as you noticed in the last sentence of 4.4.3. We will >>> change the wording as follows (plus the addition of RFC 3828 as an >>> informative reference) unless there is objection: >>> >>> [Current wording] forbidden_zero_bit. Required to be zero in [HEVC]. >>> HEVC declares a value of 1 as a syntax violation. Note that the >>> inclusion of this bit in the NAL unit header is to enable transport >>> of HEVC video over MPEG-2 transport systems (avoidance of start code >>> emulations) [MPEG2S]. >>> >>> [Changed wording] forbidden_zero_bit. Required to be zero in [HEVC]. >>> Note that the inclusion of this bit in the NAL unit header was to >>> enable transport of HEVC video over MPEG-2 transport systems >>> (avoidance of start code emulations) [MPEG2S]. In the context of >>> this memo, the value 1 MAY be used to indicate a syntax violation. >>> For example, when RTP is transported over UDP-lite [RFC3828] and the >>> receiver decides to feed the video decoder NAL unit(s) where the >>> corresponding UDP-lite packet failed a checksum test, then this bit >>> can be set to alarm the decoder of possible bit errors. >> >> The example in the new wording is not practically possible. The point >> of UDP-Lite is that you calculate the checksum only over a selected >> initial part of the IP/UDP packet. Any checksum violations will >> commonly result in that the whole packet is discarded. What UDP-Lite >> is offering is that any error in the unprotected part will not result >> in the packet being discarded. However, the receiver has no knowledge >> if the unprotected part of the UDP payload was damaged or not. Thus, >> no information is available to set the syntax violation bit. >> >> Thus, the example should be removed. No practical example came to >> mind, except maybe for a RTP middlebox forwarding a known uncomplete >> fragmented NALU where the end is missing. > >So is there ever value in setting the "forbidden_zero_bit"? > > >Ben. From nobody Mon Jun 1 11:02:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE501B303A; Mon, 1 Jun 2015 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSEegIEngNig; Mon, 1 Jun 2015 11:02:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CD11B3037; Mon, 1 Jun 2015 11:02:31 -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=1433181751; x=1464717751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RezkKyvI6nUXH/Oa9aH+qbtMAjs5dS3WR+QKDNzR6YU=; b=BLg4YUIwWDE5TSwU6Iu4NU+ynOaosb0LYnc4p0/Cl0fYW1chFO25oAk8 3yoEtnQ5l8HMO85FpUpyLOnnSfS8FNE3mZlfB0x4AKFILEOtPgp3nHn4U YNXclQcxgSMxn4dtYS7DiRIr0RECuGqIUugc1oKuayRQK4s9GmywofNbX 4=; X-IronPort-AV: E=McAfee;i="5700,7163,7819"; a="213600230" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2015 11:02:30 -0700 X-IronPort-AV: E=Sophos;i="5.13,534,1427785200"; d="scan'208";a="899188888" Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Jun 2015 11:02:02 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 1 Jun 2015 11:02:01 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Mon, 1 Jun 2015 11:02:02 -0700 From: "Wang, Ye-Kui" To: Stephan Wenger , Ben Campbell , "Magnus Westerlund" Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Thread-Index: AQHQlzlcVEvfCj5WRk+v2nDAi0LC1J2PMW4AgAAKOgCAAmWFMIAGRQmAgABHTACAADdXAP//lApQ Date: Mon, 1 Jun 2015 18:02:01 +0000 Message-ID: References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:02:34 -0000 Ben noted earlier (in his initial reviewing comments) that we have the foll= owing use of this bit specified at the end of 4.4.3: "A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragmen= ts of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NA= L unit is not received. In this case, the forbidden_zero_bit of the NAL un= it MUST be set to one to indicate a syntax violation." This is also more-or-less aligned with what Magnus mentioned below. Thus, maybe it is better to remove the UDP-Lite example, and mention its ac= tual use in this document, as follows:. "forbidden_zero_bit. Required to be zero in [HEVC]. Note that the inclusi= on of this bit in the NAL unit header was to enable transport of HEVC video= over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S= ]. In the context of this memo, the value 1 may be used to indicate a synt= ax violation, e.g. for a NAL unit resulted from aggregating a number of fra= gmented units of a NAL unit but missing the last fragment, as described in = Section 4.4.3." If agreeable, I can quickly update the document and submit -v11.=20 BR, YK -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Monday, June 01, 2015 10:18 AM To: Ben Campbell; Magnus Westerlund Cc: Wang, Ye-Kui; payload@ietf.org; draft-ietf-payload-rtp-h265@ietf.org Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Hi, The UDP-lite text was from me. After re-reading it, I agree with Magnus th= at it is incorrect as written. However: One can use (and some folks have used) the forbidden zero bit to advise the= decoder that there *may* be bit errors in the payload. Similar markers ha= ve been used in H.324/M carrying H.263 for ages, and it was always a mess t= hat there was no way in the bitstream to tell a (chip-based) decoder to be ready for the worst... In at least one implementation I am aware of, H.264=B9s forbidden zero bit = has been used for precisely this purpose. In that case, the UDP-lite check= sum covered only the UDP and RTP headers, and left the H.264 payload unprot= ected. The receiver was made aware that there may be something fishy in th= e H.264 NAL unit by the forbidden zero bit set in all such NAL units. Due = to the failure of UDP-lite in general, this product never made any signific= ant market impact, but it is my understanding that the vendors at that time= had kind-of agreed (in IMTC?) that this would be the right thing to do. There were also ideas to set the forbidden zero bit in gateways, just as Ma= gnus described. As a resolution, I can think of two ways forward, and I don=B9t really have= a preference: 1. Remove the note. Has the advantage of being correct, but may lead peopl= e on the wrong path, just as perhaps Ben may be right now) 2. Change the no= te: OLD: For example, when RTP is transported over UDP-lite [RFC3828] and the r= eceiver decides to feed the video decoder NAL unit(s) where the correspondi= ng UDP-lite packet failed a checksum test, then this bit can be set to alar= m the decoder of possible bit errors. NEW: For example, when RTP is transported over UDP-lite [RFC3828] and the r= eceiver decides to feed the video decoder NAL unit(s) where the correspondi= ng UDP-lite packet checksum-protected only parts of the packet (and therefo= re the the remainder of the packet can include bit errors with a likelyhood= Several orders of magnitude higher than a UDP packet would have) then this= bit can be set to alarm the decoder of possible bit errors. Stephan On 6/1/15, 07:00, "Ben Campbell" wrote: >On 1 Jun 2015, at 4:45, Magnus Westerlund wrote: > >> Hi, >> >> I looked at the changes and one thing made me react. >> >> >> Wang, Ye-Kui skrev den 2015-05-30 00:24: >>> Hi Ben, >>> >>> Thanks for your careful review and the detailed comments. Our=20 >>> answers to your other questions are in below, each starting with=20 >>> "[YK]". We will submit the new version containing these changes soon. >>> >>> *** Substantive *** >>> >>> -- 1.1.4, forbidden_zero_bit, "HEVC declares a value of 1 as a=20 >>> syntax violation." >>> >>> Does that mean that setting the bit is a syntax violation in itself,=20 >>> or that it _indicates_ a syntax violation? As worded, it sound like=20 >>> the former, but later examples seem to suggest the latter. (e.g.=20 >>> last sentence of 4.4.3) >>> >>> [YK]: It is the former from the HEVC spec point of view. The HEVC=20 >>> spec just says that the value of the bit shall be equal to 0. A MANE=20 >>> (in the context of this memo) can use the bit to indicate a syntax=20 >>> violation, as you noticed in the last sentence of 4.4.3. We will=20 >>> change the wording as follows (plus the addition of RFC 3828 as an=20 >>> informative reference) unless there is objection: >>> >>> [Current wording] forbidden_zero_bit. Required to be zero in [HEVC]. >>> HEVC declares a value of 1 as a syntax violation. Note that the=20 >>> inclusion of this bit in the NAL unit header is to enable transport=20 >>> of HEVC video over MPEG-2 transport systems (avoidance of start code >>> emulations) [MPEG2S]. >>> >>> [Changed wording] forbidden_zero_bit. Required to be zero in [HEVC]. >>> Note that the inclusion of this bit in the NAL unit header was to=20 >>> enable transport of HEVC video over MPEG-2 transport systems=20 >>> (avoidance of start code emulations) [MPEG2S]. In the context of=20 >>> this memo, the value 1 MAY be used to indicate a syntax violation. >>> For example, when RTP is transported over UDP-lite [RFC3828] and the=20 >>> receiver decides to feed the video decoder NAL unit(s) where the=20 >>> corresponding UDP-lite packet failed a checksum test, then this bit=20 >>> can be set to alarm the decoder of possible bit errors. >> >> The example in the new wording is not practically possible. The point=20 >> of UDP-Lite is that you calculate the checksum only over a selected=20 >> initial part of the IP/UDP packet. Any checksum violations will=20 >> commonly result in that the whole packet is discarded. What UDP-Lite=20 >> is offering is that any error in the unprotected part will not result=20 >> in the packet being discarded. However, the receiver has no knowledge=20 >> if the unprotected part of the UDP payload was damaged or not. Thus,=20 >> no information is available to set the syntax violation bit. >> >> Thus, the example should be removed. No practical example came to=20 >> mind, except maybe for a RTP middlebox forwarding a known uncomplete=20 >> fragmented NALU where the end is missing. > >So is there ever value in setting the "forbidden_zero_bit"? > > >Ben. From nobody Mon Jun 1 11:28:13 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5941B30C1; Mon, 1 Jun 2015 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIJzKy1ZnWa4; Mon, 1 Jun 2015 11:28:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3C01B30AB; Mon, 1 Jun 2015 11:28:09 -0700 (PDT) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1899.namprd07.prod.outlook.com (25.163.42.29) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 18:28:06 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 18:28:04 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 18:28:04 +0000 From: Stephan Wenger To: "Wang, Ye-Kui" , Ben Campbell , Magnus Westerlund Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Thread-Index: AQHQlzleVQ2EUNilNkOMutwxhnHkBp2ORqcAgAB/qACABMeqAIAD4uSAgABHTAD//8HwAIAAgZKA//+R2oA= Date: Mon, 1 Jun 2015 18:28:03 +0000 Message-ID: References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.5.177.48] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1276; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1899; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0701MB1276; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1276; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377424004)(479174004)(24454002)(51704005)(199003)(377454003)(13464003)(68736005)(19580405001)(105586002)(19580395003)(102836002)(101416001)(66066001)(54356999)(76176999)(50986999)(40100003)(64706001)(46102003)(106116001)(106356001)(230783001)(122556002)(81156007)(4001540100001)(5002640100001)(97736004)(99286002)(87936001)(5001770100001)(5001920100001)(62966003)(2900100001)(2950100001)(77156002)(2656002)(36756003)(5001860100001)(93886004)(5001830100001)(5001960100002)(92566002)(86362001)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1276; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="euc-kr" Content-ID: <25664B9624BA684ABF3A71324713EC8B@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 18:28:03.9542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1276 X-OriginatorOrg: stewe.org Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:28:12 -0000 T0sgd2l0aCBtZS4NClMuDQoNCg0KT24gNi8xLzE1LCAxMTowMiwgIldhbmcsIFllLUt1aSIgPHll a3Vpd0BxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCg0KPkJlbiBub3RlZCBlYXJsaWVyIChpbiBo aXMgaW5pdGlhbCByZXZpZXdpbmcgY29tbWVudHMpIHRoYXQgd2UgaGF2ZSB0aGUNCj5mb2xsb3dp bmcgdXNlIG9mIHRoaXMgYml0IHNwZWNpZmllZCBhdCB0aGUgZW5kIG9mIDQuNC4zOg0KPg0KPiJB IHJlY2VpdmVyIGluIGFuIGVuZHBvaW50IG9yIGluIGEgTUFORSBNQVkgYWdncmVnYXRlIHRoZSBm aXJzdCBuLTENCj5mcmFnbWVudHMgb2YgYSBOQUwgdW5pdCB0byBhbiAoaW5jb21wbGV0ZSkgTkFM IHVuaXQsIGV2ZW4gaWYgZnJhZ21lbnQgbg0KPm9mIHRoYXQgTkFMIHVuaXQgaXMgbm90IHJlY2Vp dmVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgZm9yYmlkZGVuX3plcm9fYml0DQo+b2YgdGhlIE5BTCB1 bml0IE1VU1QgYmUgc2V0IHRvIG9uZSB0byBpbmRpY2F0ZSBhIHN5bnRheCB2aW9sYXRpb24uIg0K Pg0KPlRoaXMgaXMgYWxzbyBtb3JlLW9yLWxlc3MgYWxpZ25lZCB3aXRoIHdoYXQgTWFnbnVzIG1l bnRpb25lZCBiZWxvdy4NCj4NCj5UaHVzLCBtYXliZSBpdCBpcyBiZXR0ZXIgdG8gcmVtb3ZlIHRo ZSBVRFAtTGl0ZSBleGFtcGxlLCBhbmQgbWVudGlvbiBpdHMNCj5hY3R1YWwgdXNlIGluIHRoaXMg ZG9jdW1lbnQsIGFzIGZvbGxvd3M6Lg0KPg0KPiJmb3JiaWRkZW5femVyb19iaXQuICBSZXF1aXJl ZCB0byBiZSB6ZXJvIGluIFtIRVZDXS4gIE5vdGUgdGhhdCB0aGUNCj5pbmNsdXNpb24gb2YgdGhp cyBiaXQgaW4gdGhlIE5BTCB1bml0IGhlYWRlciB3YXMgdG8gZW5hYmxlIHRyYW5zcG9ydCBvZg0K PkhFVkMgdmlkZW8gb3ZlciBNUEVHLTIgdHJhbnNwb3J0IHN5c3RlbXMgKGF2b2lkYW5jZSBvZiBz dGFydCBjb2RlDQo+ZW11bGF0aW9ucykgW01QRUcyU10uICBJbiB0aGUgY29udGV4dCBvZiB0aGlz IG1lbW8sIHRoZSB2YWx1ZSAxIG1heSBiZQ0KPnVzZWQgdG8gaW5kaWNhdGUgYSBzeW50YXggdmlv bGF0aW9uLCBlLmcuIGZvciBhIE5BTCB1bml0IHJlc3VsdGVkIGZyb20NCj5hZ2dyZWdhdGluZyBh IG51bWJlciBvZiBmcmFnbWVudGVkIHVuaXRzIG9mIGEgTkFMIHVuaXQgYnV0IG1pc3NpbmcgdGhl DQo+bGFzdCBmcmFnbWVudCwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC40LjMuIg0KPg0KPklm IGFncmVlYWJsZSwgSSBjYW4gcXVpY2tseSB1cGRhdGUgdGhlIGRvY3VtZW50IGFuZCBzdWJtaXQg LXYxMS4NCj4NCj5CUiwgWUsNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IFN0ZXBoYW4gV2VuZ2VyIFttYWlsdG86c3Rld2VAc3Rld2Uub3JnXQ0KPlNlbnQ6IE1vbmRheSwg SnVuZSAwMSwgMjAxNSAxMDoxOCBBTQ0KPlRvOiBCZW4gQ2FtcGJlbGw7IE1hZ251cyBXZXN0ZXJs dW5kDQo+Q2M6IFdhbmcsIFllLUt1aTsgcGF5bG9hZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYXls b2FkLXJ0cC1oMjY1QGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtwYXlsb2FkXSBXR0xDIEZlZWRi YWNrIGZvciBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjUtMDkNCj4NCj5IaSwNCj5UaGUgVURQ LWxpdGUgdGV4dCB3YXMgZnJvbSBtZS4gIEFmdGVyIHJlLXJlYWRpbmcgaXQsIEkgYWdyZWUgd2l0 aCBNYWdudXMNCj50aGF0IGl0IGlzIGluY29ycmVjdCBhcyB3cml0dGVuLiAgSG93ZXZlcjoNCj5P bmUgY2FuIHVzZSAoYW5kIHNvbWUgZm9sa3MgaGF2ZSB1c2VkKSB0aGUgZm9yYmlkZGVuIHplcm8g Yml0IHRvIGFkdmlzZQ0KPnRoZSBkZWNvZGVyIHRoYXQgdGhlcmUgKm1heSogYmUgYml0IGVycm9y cyBpbiB0aGUgcGF5bG9hZC4gIFNpbWlsYXINCj5tYXJrZXJzIGhhdmUgYmVlbiB1c2VkIGluIEgu MzI0L00gY2FycnlpbmcgSC4yNjMgZm9yIGFnZXMsIGFuZCBpdCB3YXMNCj5hbHdheXMgYSBtZXNz IHRoYXQgdGhlcmUgd2FzIG5vIHdheSBpbiB0aGUgYml0c3RyZWFtIHRvIHRlbGwgYQ0KPihjaGlw LWJhc2VkKSBkZWNvZGVyIHRvIGJlIHJlYWR5IGZvciB0aGUgd29yc3QuLi4NCj5JbiBhdCBsZWFz dCBvbmUgaW1wbGVtZW50YXRpb24gSSBhbSBhd2FyZSBvZiwgSC4yNjSp9nMgZm9yYmlkZGVuIHpl cm8gYml0DQo+aGFzIGJlZW4gdXNlZCBmb3IgcHJlY2lzZWx5IHRoaXMgcHVycG9zZS4gIEluIHRo YXQgY2FzZSwgdGhlIFVEUC1saXRlDQo+Y2hlY2tzdW0gY292ZXJlZCBvbmx5IHRoZSBVRFAgYW5k IFJUUCBoZWFkZXJzLCBhbmQgbGVmdCB0aGUgSC4yNjQgcGF5bG9hZA0KPnVucHJvdGVjdGVkLiAg VGhlIHJlY2VpdmVyIHdhcyBtYWRlIGF3YXJlIHRoYXQgdGhlcmUgbWF5IGJlIHNvbWV0aGluZw0K PmZpc2h5IGluIHRoZSBILjI2NCBOQUwgdW5pdCBieSB0aGUgZm9yYmlkZGVuIHplcm8gYml0IHNl dCBpbiBhbGwgc3VjaCBOQUwNCj51bml0cy4gIER1ZSB0byB0aGUgZmFpbHVyZSBvZiBVRFAtbGl0 ZSBpbiBnZW5lcmFsLCB0aGlzIHByb2R1Y3QgbmV2ZXINCj5tYWRlIGFueSBzaWduaWZpY2FudCBt YXJrZXQgaW1wYWN0LCBidXQgaXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZQ0KPnZlbmRv cnMgYXQgdGhhdCB0aW1lIGhhZCBraW5kLW9mIGFncmVlZCAoaW4gSU1UQz8pIHRoYXQgdGhpcyB3 b3VsZCBiZSB0aGUNCj5yaWdodCB0aGluZyB0byBkby4NCj5UaGVyZSB3ZXJlIGFsc28gaWRlYXMg dG8gc2V0IHRoZSBmb3JiaWRkZW4gemVybyBiaXQgaW4gZ2F0ZXdheXMsIGp1c3QgYXMNCj5NYWdu dXMgZGVzY3JpYmVkLg0KPkFzIGEgcmVzb2x1dGlvbiwgSSBjYW4gdGhpbmsgb2YgdHdvIHdheXMg Zm9yd2FyZCwgYW5kIEkgZG9uqfZ0IHJlYWxseSBoYXZlDQo+YSBwcmVmZXJlbmNlOg0KPjEuIFJl bW92ZSB0aGUgbm90ZS4gIEhhcyB0aGUgYWR2YW50YWdlIG9mIGJlaW5nIGNvcnJlY3QsIGJ1dCBt YXkgbGVhZA0KPnBlb3BsZSBvbiB0aGUgd3JvbmcgcGF0aCwganVzdCBhcyBwZXJoYXBzIEJlbiBt YXkgYmUgcmlnaHQgbm93KSAyLiBDaGFuZ2UNCj50aGUgbm90ZToNCj5PTEQ6IEZvciBleGFtcGxl LCB3aGVuIFJUUCBpcyB0cmFuc3BvcnRlZCBvdmVyIFVEUC1saXRlIFtSRkMzODI4XSBhbmQgdGhl DQo+cmVjZWl2ZXIgZGVjaWRlcyB0byBmZWVkIHRoZSB2aWRlbyBkZWNvZGVyIE5BTCB1bml0KHMp IHdoZXJlIHRoZQ0KPmNvcnJlc3BvbmRpbmcgVURQLWxpdGUgcGFja2V0IGZhaWxlZCBhIGNoZWNr c3VtIHRlc3QsIHRoZW4gdGhpcyBiaXQgY2FuDQo+YmUgc2V0IHRvIGFsYXJtIHRoZSBkZWNvZGVy IG9mIHBvc3NpYmxlIGJpdCBlcnJvcnMuDQo+TkVXOiBGb3IgZXhhbXBsZSwgd2hlbiBSVFAgaXMg dHJhbnNwb3J0ZWQgb3ZlciBVRFAtbGl0ZSBbUkZDMzgyOF0gYW5kIHRoZQ0KPnJlY2VpdmVyIGRl Y2lkZXMgdG8gZmVlZCB0aGUgdmlkZW8gZGVjb2RlciBOQUwgdW5pdChzKSB3aGVyZSB0aGUNCj5j b3JyZXNwb25kaW5nIFVEUC1saXRlIHBhY2tldCBjaGVja3N1bS1wcm90ZWN0ZWQgb25seSBwYXJ0 cyBvZiB0aGUgcGFja2V0DQo+KGFuZCB0aGVyZWZvcmUgdGhlIHRoZSByZW1haW5kZXIgb2YgdGhl IHBhY2tldCBjYW4gaW5jbHVkZSBiaXQgZXJyb3JzDQo+d2l0aCBhIGxpa2VseWhvb2QgU2V2ZXJh bCBvcmRlcnMgb2YgbWFnbml0dWRlIGhpZ2hlciB0aGFuIGEgVURQIHBhY2tldA0KPndvdWxkIGhh dmUpIHRoZW4gdGhpcyBiaXQgY2FuIGJlIHNldCB0byBhbGFybSB0aGUgZGVjb2RlciBvZiBwb3Nz aWJsZSBiaXQNCj5lcnJvcnMuDQo+U3RlcGhhbg0KPg0KPg0KPk9uIDYvMS8xNSwgMDc6MDAsICJC ZW4gQ2FtcGJlbGwiIDxiZW5Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPg0KPj5PbiAxIEp1biAyMDE1 LCBhdCA0OjQ1LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4+DQo+Pj4gSGksDQo+Pj4NCj4+ PiBJIGxvb2tlZCBhdCB0aGUgY2hhbmdlcyBhbmQgb25lIHRoaW5nIG1hZGUgbWUgcmVhY3QuDQo+ Pj4NCj4+Pg0KPj4+IFdhbmcsIFllLUt1aSBza3JldiBkZW4gMjAxNS0wNS0zMCAwMDoyNDoNCj4+ Pj4gSGkgQmVuLA0KPj4+Pg0KPj4+PiBUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcgYW5k IHRoZSBkZXRhaWxlZCBjb21tZW50cy4gT3VyDQo+Pj4+IGFuc3dlcnMgdG8geW91ciBvdGhlciBx dWVzdGlvbnMgYXJlIGluIGJlbG93LCBlYWNoIHN0YXJ0aW5nIHdpdGgNCj4+Pj4gIltZS10iLiBX ZSB3aWxsIHN1Ym1pdCB0aGUgbmV3IHZlcnNpb24gY29udGFpbmluZyB0aGVzZSBjaGFuZ2VzIHNv b24uDQo+Pj4+DQo+Pj4+ICoqKiBTdWJzdGFudGl2ZSAqKioNCj4+Pj4NCj4+Pj4gLS0gMS4xLjQs IGZvcmJpZGRlbl96ZXJvX2JpdCwgIkhFVkMgZGVjbGFyZXMgYSB2YWx1ZSBvZiAxIGFzIGENCj4+ Pj4gc3ludGF4IHZpb2xhdGlvbi4iDQo+Pj4+DQo+Pj4+IERvZXMgdGhhdCBtZWFuIHRoYXQgc2V0 dGluZyB0aGUgYml0IGlzIGEgc3ludGF4IHZpb2xhdGlvbiBpbiBpdHNlbGYsDQo+Pj4+IG9yIHRo YXQgaXQgX2luZGljYXRlc18gYSBzeW50YXggdmlvbGF0aW9uPyBBcyB3b3JkZWQsIGl0IHNvdW5k IGxpa2UNCj4+Pj4gdGhlIGZvcm1lciwgYnV0IGxhdGVyIGV4YW1wbGVzIHNlZW0gdG8gc3VnZ2Vz dCB0aGUgbGF0dGVyLiAoZS5nLg0KPj4+PiBsYXN0IHNlbnRlbmNlIG9mIDQuNC4zKQ0KPj4+Pg0K Pj4+PiBbWUtdOiBJdCBpcyB0aGUgZm9ybWVyIGZyb20gdGhlIEhFVkMgc3BlYyBwb2ludCBvZiB2 aWV3LiBUaGUgSEVWQw0KPj4+PiBzcGVjIGp1c3Qgc2F5cyB0aGF0IHRoZSB2YWx1ZSBvZiB0aGUg Yml0IHNoYWxsIGJlIGVxdWFsIHRvIDAuIEEgTUFORQ0KPj4+PiAoaW4gdGhlIGNvbnRleHQgb2Yg dGhpcyBtZW1vKSBjYW4gdXNlIHRoZSBiaXQgdG8gaW5kaWNhdGUgYSBzeW50YXgNCj4+Pj4gdmlv bGF0aW9uLCBhcyB5b3Ugbm90aWNlZCBpbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiA0LjQuMy4gV2Ug d2lsbA0KPj4+PiBjaGFuZ2UgdGhlIHdvcmRpbmcgYXMgZm9sbG93cyAocGx1cyB0aGUgYWRkaXRp b24gb2YgUkZDIDM4MjggYXMgYW4NCj4+Pj4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlKSB1bmxlc3Mg dGhlcmUgaXMgb2JqZWN0aW9uOg0KPj4+Pg0KPj4+PiBbQ3VycmVudCB3b3JkaW5nXSBmb3JiaWRk ZW5femVyb19iaXQuICBSZXF1aXJlZCB0byBiZSB6ZXJvIGluIFtIRVZDXS4NCj4+Pj4gSEVWQyBk ZWNsYXJlcyBhIHZhbHVlIG9mIDEgYXMgYSBzeW50YXggdmlvbGF0aW9uLiAgTm90ZSB0aGF0IHRo ZQ0KPj4+PiBpbmNsdXNpb24gb2YgdGhpcyBiaXQgaW4gdGhlIE5BTCB1bml0IGhlYWRlciBpcyB0 byBlbmFibGUgdHJhbnNwb3J0DQo+Pj4+IG9mIEhFVkMgdmlkZW8gb3ZlciBNUEVHLTIgdHJhbnNw b3J0IHN5c3RlbXMgKGF2b2lkYW5jZSBvZiBzdGFydCBjb2RlDQo+Pj4+IGVtdWxhdGlvbnMpIFtN UEVHMlNdLg0KPj4+Pg0KPj4+PiBbQ2hhbmdlZCB3b3JkaW5nXSBmb3JiaWRkZW5femVyb19iaXQu ICBSZXF1aXJlZCB0byBiZSB6ZXJvIGluIFtIRVZDXS4NCj4+Pj4gTm90ZSB0aGF0IHRoZSBpbmNs dXNpb24gb2YgdGhpcyBiaXQgaW4gdGhlIE5BTCB1bml0IGhlYWRlciB3YXMgdG8NCj4+Pj4gZW5h YmxlIHRyYW5zcG9ydCBvZiBIRVZDIHZpZGVvIG92ZXIgTVBFRy0yIHRyYW5zcG9ydCBzeXN0ZW1z DQo+Pj4+IChhdm9pZGFuY2Ugb2Ygc3RhcnQgY29kZSBlbXVsYXRpb25zKSBbTVBFRzJTXS4gIElu IHRoZSBjb250ZXh0IG9mDQo+Pj4+IHRoaXMgbWVtbywgdGhlIHZhbHVlIDEgTUFZIGJlIHVzZWQg dG8gaW5kaWNhdGUgYSBzeW50YXggdmlvbGF0aW9uLg0KPj4+PiBGb3IgZXhhbXBsZSwgd2hlbiBS VFAgaXMgdHJhbnNwb3J0ZWQgb3ZlciBVRFAtbGl0ZSBbUkZDMzgyOF0gYW5kIHRoZQ0KPj4+PiBy ZWNlaXZlciBkZWNpZGVzIHRvIGZlZWQgdGhlIHZpZGVvIGRlY29kZXIgTkFMIHVuaXQocykgd2hl cmUgdGhlDQo+Pj4+IGNvcnJlc3BvbmRpbmcgVURQLWxpdGUgcGFja2V0IGZhaWxlZCBhIGNoZWNr c3VtIHRlc3QsIHRoZW4gdGhpcyBiaXQNCj4+Pj4gY2FuIGJlIHNldCB0byBhbGFybSB0aGUgZGVj b2RlciBvZiBwb3NzaWJsZSBiaXQgZXJyb3JzLg0KPj4+DQo+Pj4gVGhlIGV4YW1wbGUgaW4gdGhl IG5ldyB3b3JkaW5nIGlzIG5vdCBwcmFjdGljYWxseSBwb3NzaWJsZS4gVGhlIHBvaW50DQo+Pj4g b2YgVURQLUxpdGUgaXMgdGhhdCB5b3UgY2FsY3VsYXRlIHRoZSBjaGVja3N1bSBvbmx5IG92ZXIg YSBzZWxlY3RlZA0KPj4+IGluaXRpYWwgcGFydCBvZiB0aGUgSVAvVURQIHBhY2tldC4gQW55IGNo ZWNrc3VtIHZpb2xhdGlvbnMgd2lsbA0KPj4+IGNvbW1vbmx5IHJlc3VsdCBpbiB0aGF0IHRoZSB3 aG9sZSBwYWNrZXQgaXMgZGlzY2FyZGVkLiBXaGF0IFVEUC1MaXRlDQo+Pj4gaXMgb2ZmZXJpbmcg aXMgdGhhdCBhbnkgZXJyb3IgaW4gdGhlIHVucHJvdGVjdGVkIHBhcnQgd2lsbCBub3QgcmVzdWx0 DQo+Pj4gaW4gdGhlIHBhY2tldCBiZWluZyBkaXNjYXJkZWQuIEhvd2V2ZXIsIHRoZSByZWNlaXZl ciBoYXMgbm8ga25vd2xlZGdlDQo+Pj4gaWYgdGhlIHVucHJvdGVjdGVkIHBhcnQgb2YgdGhlIFVE UCBwYXlsb2FkIHdhcyBkYW1hZ2VkIG9yIG5vdC4gVGh1cywNCj4+PiBubyBpbmZvcm1hdGlvbiBp cyBhdmFpbGFibGUgdG8gc2V0IHRoZSBzeW50YXggdmlvbGF0aW9uIGJpdC4NCj4+Pg0KPj4+IFRo dXMsIHRoZSBleGFtcGxlIHNob3VsZCBiZSByZW1vdmVkLiBObyBwcmFjdGljYWwgZXhhbXBsZSBj YW1lIHRvDQo+Pj4gbWluZCwgZXhjZXB0IG1heWJlIGZvciBhIFJUUCBtaWRkbGVib3ggZm9yd2Fy ZGluZyBhIGtub3duIHVuY29tcGxldGUNCj4+PiBmcmFnbWVudGVkIE5BTFUgd2hlcmUgdGhlIGVu ZCBpcyBtaXNzaW5nLg0KPj4NCj4+U28gaXMgdGhlcmUgZXZlciB2YWx1ZSBpbiBzZXR0aW5nIHRo ZSAiZm9yYmlkZGVuX3plcm9fYml0Ij8NCj4+DQo+Pg0KPj5CZW4uDQo+DQoNCg== From nobody Tue Jun 2 01:07:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0381A8743; Tue, 2 Jun 2015 01:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKBgpyXdiliZ; Tue, 2 Jun 2015 01:07:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DC31A874D; Tue, 2 Jun 2015 01:07:31 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-95-556d6441f92f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.DB.04401.1446D655; Tue, 2 Jun 2015 10:07:29 +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.3.210.2; Tue, 2 Jun 2015 10:07:29 +0200 Message-ID: <556D6440.2020309@ericsson.com> Date: Tue, 2 Jun 2015 10:07:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , Stephan Wenger , Ben Campbell References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvra5jSm6owZ93RhbzO0+zWzw+tZTN 4tLFs0wW1xs3sVs8WXOM2YHVY8mSn0wes3Y+YfFYNPUZo8fi9e8ZA1iiuGxSUnMyy1KL9O0S uDJ+dy1iLtjPW/GkpZOxgfEXVxcjJ4eEgInEl5bn7BC2mMSFe+vZuhi5OIQEjjJKHF1zix3C WcYo8fH1UuYuRg4OXgFtiTUX9UEaWARUJDb/ewLWzCZgIXHzRyMbiC0qECUx9fE6FhCbV0BQ 4uTMJ2C2iECBxIoNk8DqmQWqJN6t/MUEYgsLuEtM6HvNArGrhVnidMd2VpBdnALeEjNXxoKY zAL2Eg+2lkG0yks0b53NDGILAV3T0NTBOoFRcBaSbbMQOmYh6VjAyLyKUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzC4D275rbqD8fIbx0OMAhyMSjy8Cny5oUKsiWXFlbmHGKU5WJTEeT27 QkKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEp6XJlR+/mTtEj0w5obocd+lbYwcHzq3sYY MU9gYfPlC7YPWDeFWTxboOkXWbbnN8t8Xw3GjwsCv/X5MIlsOR7nseDnoZdJd/ennGxg46q9 x/03PPHYvi0Ttf//16zv5irtZFj4uSS4xlL+vrn1wY2TIjSOpr3/wFt6wmvhtelSe7i5j/az JCmxFGckGmoxFxUnAgCC/jM9TwIAAA== Archived-At: Cc: "draft-ietf-payload-rtp-h265@ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 08:07:33 -0000 Wang, Ye-Kui skrev den 2015-06-01 20:02: > Ben noted earlier (in his initial reviewing comments) that we have the following use of this bit specified at the end of 4.4.3: > > "A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is not received. In this case, the forbidden_zero_bit of the NAL unit MUST be set to one to indicate a syntax violation." > > This is also more-or-less aligned with what Magnus mentioned below. > > Thus, maybe it is better to remove the UDP-Lite example, and mention its actual use in this document, as follows:. > > "forbidden_zero_bit. Required to be zero in [HEVC]. Note that the inclusion of this bit in the NAL unit header was to enable transport of HEVC video over MPEG-2 transport systems (avoidance of start code emulations) [MPEG2S]. In the context of this memo, the value 1 may be used to indicate a syntax violation, e.g. for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3." > > If agreeable, I can quickly update the document and submit -v11. Yes, that appears a good solution. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 2 05:11:51 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5226D1B2D7B; Tue, 2 Jun 2015 05:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJHmW59Gepqp; Tue, 2 Jun 2015 05:11:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186531A0231; Tue, 2 Jun 2015 05:11:47 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-19-556d9d82d48d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.2C.17665.28D9D655; Tue, 2 Jun 2015 14:11:46 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.30]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Tue, 2 Jun 2015 14:11:45 +0200 From: Bo Burman To: Magnus Westerlund , "Wang, Ye-Kui" , Stephan Wenger , Ben Campbell Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Thread-Index: AQHQlzleO2h3/+ZGtk24PkyiJUB8Wp2Omo4AgAAKOgCABMeqAIAD4uSAgABHTACAADdXAIAADCuAgADsNwCAAFEnMA== Date: Tue, 2 Jun 2015 12:11:45 +0000 Message-ID: References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> <556D6440.2020309@ericsson.com> In-Reply-To: <556D6440.2020309@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Vrdpbm6owZmr0hbzO0+zWzw+tZTN 4tLFs0wW1xs3sVs8WXOM2YHVY8mSn0wes3Y+YfFYNPUZo8fi9e8ZA1iiuGxSUnMyy1KL9O0S uDI2nPjCVLBZrOLVlJXMDYzPBLsYOTkkBEwkfvc0MUPYYhIX7q1n62Lk4hASOMoosaHpDwuE s4hRYs77bjaQKjYBDYn5O+4ygtgiAssYJZ53qnYxcnAwC1RJ/NymAGIKC7hLvFzuCWKKCHhI HOnQgCjOktj3fDpYI4uAisSi5WeYQGxeAV+JxW+mMUNs2sIssen1TrB7OAV0JK70nmEBsRkF ZCXuf78HZjMLiEvcejKfCeJmAYkle85D3S8q8fLxP1YIW1Fi59l2Zoh6PYkbU6ewQdjaEssW vmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st 2cQIjLeDW37r7mBc/drxEKMAB6MSD68CX26oEGtiWXFl7iFGaQ4WJXFer66QUCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M1mxHTSern+SqWfcmLmTejq7MPfq2trom3W8WnWG50xijqmvL q+l28cLPCY1ndJNc8zc8nrw132L23TNPH7e/SuoJWPgtLz2mSeiA+A055poKNgU5ttMT709Q 9Cs/e3IG81QTkQCHmEC3uR+W1aTrf5wgov7xe0NlbrFDfyDH4+2df4KfHfVQYinOSDTUYi4q TgQAitM0m5gCAAA= Archived-At: Cc: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 12:11:50 -0000 I checked -09 and -10 versions. Besides the comment made by Magnus and the = solution suggested below, which I agree to, I found only the following nit= : Section 4.1, below Figure 2: OLD: Marker bit (M): 1 bit Set for the last packet carried in the current RTP stream of the access unit. This is in line with the normal use of the M NEW: Marker bit (M): 1 bit Set for the last packet of the access unit, carried in the current RTP stream. This is in line with the normal use of the M Cheers, Bo > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Weste= rlund > Sent: den 2 juni 2015 10:07 > To: Wang, Ye-Kui; Stephan Wenger; Ben Campbell > Cc: draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org > Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 >=20 > Wang, Ye-Kui skrev den 2015-06-01 20:02: > > Ben noted earlier (in his initial reviewing comments) that we have the = following use of this bit specified at the end of > 4.4.3: > > > > "A receiver in an endpoint or in a MANE MAY aggregate the first n-1 fra= gments of a NAL unit to an (incomplete) NAL > unit, even if fragment n of that NAL unit is not received. In this case,= the forbidden_zero_bit of the NAL unit MUST be > set to one to indicate a syntax violation." > > > > This is also more-or-less aligned with what Magnus mentioned below. > > > > Thus, maybe it is better to remove the UDP-Lite example, and mention it= s actual use in this document, as follows:. > > > > "forbidden_zero_bit. Required to be zero in [HEVC]. Note that the inc= lusion of this bit in the NAL unit header was to > enable transport of HEVC video over MPEG-2 transport systems (avoidance o= f start code emulations) [MPEG2S]. In the > context of this memo, the value 1 may be used to indicate a syntax violat= ion, e.g. for a NAL unit resulted from > aggregating a number of fragmented units of a NAL unit but missing the la= st fragment, as described in Section 4.4.3." > > > > If agreeable, I can quickly update the document and submit -v11. >=20 > Yes, that appears a good solution. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Jun 2 09:26:49 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B241B2AB3; Tue, 2 Jun 2015 09:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj4KrZExQwL2; Tue, 2 Jun 2015 09:26:45 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0322D1B2ACE; Tue, 2 Jun 2015 09:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433262405; x=1464798405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jQpM89HlSYHuA3CoMOrig9Na17DpCldRxGphfZ2arHA=; b=ziLYmSRFi/w+wfe87gpki69zIzxv+0ISqp2ak3KrKWMfUwz1zcNgQG+u luF4w/zyrhHQjTiUXNOdOU7FwSkr446yymA3JL3+fKS1f66qtHpGiR4Rr k0agu0sLfpNMMvRS+5PbTbZNm+F+Zecs29fZ4wku8YRnfyiPA2Xgxlke3 8=; X-IronPort-AV: E=McAfee;i="5700,7163,7820"; a="91195539" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 02 Jun 2015 09:26:45 -0700 X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="33240221" Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jun 2015 09:26:43 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 2 Jun 2015 09:26:43 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Tue, 2 Jun 2015 09:26:43 -0700 From: "Wang, Ye-Kui" To: Bo Burman , Magnus Westerlund , Stephan Wenger , "Ben Campbell" Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 Thread-Index: AQHQlzlcVEvfCj5WRk+v2nDAi0LC1J2PMW4AgAAKOgCAAmWFMIAGRQmAgABHTACAADdXAP//lApQgAFkWACAAERAgP//0V/Q Date: Tue, 2 Jun 2015 16:26:42 +0000 Message-ID: <04f8a83883304f3cbaef861e9067e6ff@NASANEXM01H.na.qualcomm.com> References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> <556D6440.2020309@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@ietf.org" Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:26:48 -0000 Thanks Bo - the suggested change is indeed an improvement! Thanks Magnus as= well for confirming the other change.=20 I will now go ahead to make these two changes and submit -11.=20 BR, YK -----Original Message----- From: Bo Burman [mailto:bo.burman@ericsson.com]=20 Sent: Tuesday, June 02, 2015 5:12 AM To: Magnus Westerlund; Wang, Ye-Kui; Stephan Wenger; Ben Campbell Cc: draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org Subject: RE: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09 I checked -09 and -10 versions. Besides the comment made by Magnus and the = solution suggested below, which I agree to, I found only the following nit= : Section 4.1, below Figure 2: OLD: Marker bit (M): 1 bit Set for the last packet carried in the current RTP stream of the access unit. This is in line with the normal use of the M NEW: Marker bit (M): 1 bit Set for the last packet of the access unit, carried in the current RTP stream. This is in line with the normal use of the M Cheers, Bo > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus=20 > Westerlund > Sent: den 2 juni 2015 10:07 > To: Wang, Ye-Kui; Stephan Wenger; Ben Campbell > Cc: draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org > Subject: Re: [payload] WGLC Feedback for=20 > draft-ietf-payload-rtp-h265-09 >=20 > Wang, Ye-Kui skrev den 2015-06-01 20:02: > > Ben noted earlier (in his initial reviewing comments) that we have=20 > > the following use of this bit specified at the end of > 4.4.3: > > > > "A receiver in an endpoint or in a MANE MAY aggregate the first n-1=20 > > fragments of a NAL unit to an (incomplete) NAL > unit, even if fragment n of that NAL unit is not received. In this=20 > case, the forbidden_zero_bit of the NAL unit MUST be set to one to indica= te a syntax violation." > > > > This is also more-or-less aligned with what Magnus mentioned below. > > > > Thus, maybe it is better to remove the UDP-Lite example, and mention it= s actual use in this document, as follows:. > > > > "forbidden_zero_bit. Required to be zero in [HEVC]. Note that the=20 > > inclusion of this bit in the NAL unit header was to > enable transport of HEVC video over MPEG-2 transport systems=20 > (avoidance of start code emulations) [MPEG2S]. In the context of this=20 > memo, the value 1 may be used to indicate a syntax violation, e.g. for a = NAL unit resulted from aggregating a number of fragmented units of a NAL un= it but missing the last fragment, as described in Section 4.4.3." > > > > If agreeable, I can quickly update the document and submit -v11. >=20 > Yes, that appears a good solution. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Jun 2 09:45:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E621B31D4; Tue, 2 Jun 2015 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzcSEV4O3nz8; Tue, 2 Jun 2015 09:45:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A7E1B3157; Tue, 2 Jun 2015 09:45:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> Date: Tue, 02 Jun 2015 09:45:27 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:45:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-11.txt Pages : 100 Date : 2015-06-02 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 2 09:52:52 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E351B33F8 for ; Tue, 2 Jun 2015 09:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvH18IjJIihd for ; Tue, 2 Jun 2015 09:52:49 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DC41B33B5 for ; Tue, 2 Jun 2015 09:52:49 -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=1433263969; x=1464799969; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H7ThUpww7om0wySFb8YC5rdNp+vQCoW/8Xf16atNw+Q=; b=LzWZIB6GTiERH3G2VpC65uqNwQdwkCMbU6HyMf9wmJt53/MSpwBNQmV/ h5M4WnneUxjyurxBv7LseoDp5Wuz7B8C2TK9HNnRI8T6hGjX2vaZFFiik LQv3j3zbdgcCXN6pc/z7vwnmiEi0LWwcvahViboxaeF2nA+WNxHAX1Yea c=; X-IronPort-AV: E=McAfee;i="5700,7163,7820"; a="213786153" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2015 09:52:49 -0700 X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="984778356" Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jun 2015 09:52:49 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 2 Jun 2015 09:52:48 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Tue, 2 Jun 2015 09:52:48 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt Thread-Index: AQHQnVOMiH1NWr7R/0C2HiQDyhBXB52ZbRYw Date: Tue, 2 Jun 2015 16:52:47 +0000 Message-ID: <1bf93a50375543d987c14fc3f2f7b9a9@NASANEXM01H.na.qualcomm.com> References: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> In-Reply-To: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:52:51 -0000 Compared to -10, the changes are: - On the semantics of the F bit (forbidden_zero_bit) as discussed with Magn= us, Stephan, and Bo, and removed the informative reference to the UDP-Lite = RFC. - On the semantics of Marker bit (M) as suggested by Bo. - Added Ben and Bo to the list of reviewers in the acknowledgements (Magnus= was there already).=20 BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, June 02, 2015 9:45 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-11.txt Pages : 100 Date : 2015-06-02 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jun 3 06:12:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31A01A87ED for ; Wed, 3 Jun 2015 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtla6RVdin-W for ; Wed, 3 Jun 2015 06:12:01 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE981A038B for ; Wed, 3 Jun 2015 06:12:00 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-51-556efd1e8027 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.76.17665.E1DFE655; Wed, 3 Jun 2015 15:11:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Wed, 3 Jun 2015 15:11:58 +0200 Message-ID: <556EFD1D.4010904@ericsson.com> Date: Wed, 3 Jun 2015 15:11:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , "payload@ietf.org" References: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> <1bf93a50375543d987c14fc3f2f7b9a9@NASANEXM01H.na.qualcomm.com> In-Reply-To: <1bf93a50375543d987c14fc3f2f7b9a9@NASANEXM01H.na.qualcomm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvra7837xQgzdtTBaXLp5lsniy5hiz A5PHkiU/mTwWTX3GGMAUxWWTkpqTWZZapG+XwJUx4dZ7loIHchVTN+9hb2B8L97FyMEhIWAi sWhjSBcjJ5ApJnHh3nq2LkYuDiGBo4wSfYfeQjnLGCW65l5mAmngFdCW2NNUCtLAIqAi0bT8 LBuIzSZgIXHzRyOYLSoQJTH18ToWEJtXQFDi5MwnYLaIQKjEl49T2UFsYQFXiZ4V75lBbCGB eomjTbfBbE4Bb4nHr1eygqxiFrCXeLC1DCTMLCAv0bx1NlS5tkRDUwfrBEaBWUg2zELomIWk YwEj8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwIA8uOW37g7G1a8dDzEKcDAq8fAuiM8L FWJNLCuuzD3EKM3BoiTOO2MzUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjjkzmx10b+Do8 z5VPNz3kd/1vVfKSFJsL/rlr8pRdArz5vx9IWbO/aJbl5K6NF2vk2c8nL5nH9/1yQPDvpTbO HR8KdDiumt7lPxHQ2nh7dq7Y3eUhrUEzvnM8rbhmwmz+nuNWnGyUfbiKt8OHT+7HY5Rn1DPl C9375/Lms36PTdjlp++rs7KVWIozEg21mIuKEwGhQd7SKQIAAA== Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 13:12:03 -0000 Hi, No issues with the intentional changes, but something went wrong in the editing as start of Section 4.2 ended up in the wrong place. I will note that it is a good idea of generating a diff prior to submission with the previous version to detect these type of issues. Cheers Magnus Wang, Ye-Kui skrev den 2015-06-02 18:52: > Compared to -10, the changes are: > - On the semantics of the F bit (forbidden_zero_bit) as discussed with Magnus, Stephan, and Bo, and removed the informative reference to the UDP-Lite RFC. > - On the semantics of Marker bit (M) as suggested by Bo. > - Added Ben and Bo to the list of reviewers in the acknowledgements (Magnus was there already). > > BR, YK > > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, June 02, 2015 9:45 AM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > Title : RTP Payload Format for High Efficiency Video Coding > Authors : Ye-Kui Wang > Yago Sanchez > Thomas Schierl > Stephan Wenger > Miska M. Hannuksela > Filename : draft-ietf-payload-rtp-h265-11.txt > Pages : 100 > Date : 2015-06-02 > > Abstract: > This memo describes an RTP payload format for the video coding > standard ITU-T Recommendation H.265 and ISO/IEC International > Standard 23008-2, both also known as High Efficiency Video Coding > (HEVC) and developed by the Joint Collaborative Team on Video > Coding (JCT-VC). The RTP payload format allows for packetization > of one or more Network Abstraction Layer (NAL) units in each RTP > packet payload, as well as fragmentation of a NAL unit into > multiple RTP packets. Furthermore, it supports transmission of > an HEVC bitstream over a single as well as multiple RTP streams. > When multiple RTP streams are used, a single or multiple > transports may be utilized. The payload format has wide > applicability in videoconferencing, Internet video streaming, and > high bit-rate entertainment-quality video, among others. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-11 > > > 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 > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 3 11:58:31 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493081B29AB; Wed, 3 Jun 2015 11:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sQ9SQmS3oN1; Wed, 3 Jun 2015 11:58:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36E1B2850; Wed, 3 Jun 2015 11:58:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603185828.20140.22933.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 11:58:28 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:58:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload for SMPTE ST 291 Ancillary Data Author : Thomas G. Edwards Filename : draft-ietf-payload-rtp-ancillary-01.txt Pages : 12 Date : 2015-06-03 Abstract: This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, KLV metadata, Closed Captioning, and the Active Format Description (AFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 15:31:03 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564E1B2FF8; Wed, 3 Jun 2015 15:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcukTafW35_T; Wed, 3 Jun 2015 15:30:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BD81A8F37; Wed, 3 Jun 2015 15:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603223058.9895.59106.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 15:30:58 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-12.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:31:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-12.txt Pages : 100 Date : 2015-06-03 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 15:42:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7099D1B2F20; Wed, 3 Jun 2015 15:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgElbTezfq_Q; Wed, 3 Jun 2015 15:42:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E01A92EA; Wed, 3 Jun 2015 15:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603224230.15650.44496.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 15:42:30 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-13.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:42:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-13.txt Pages : 100 Date : 2015-06-03 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 15:49:56 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602711B3011 for ; Wed, 3 Jun 2015 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO337W1LWYtN for ; Wed, 3 Jun 2015 15:49:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E391B303A for ; Wed, 3 Jun 2015 15:49:48 -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=1433371789; x=1464907789; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=95Q3wMydoBoZlqxIKbbl5C0tWUe8sPASK3mAqKc70yY=; b=SvrU9/g3hfCcISvatm79jhEXITEFZPWCFW8WBSoitvnd5PTcewgVjacC QUin21Nu1l2QzVszgNtxRxStqx3caRCpkrCWVFh3Km6DQ4s2Azw0P48vQ PGfBPFFQ5gmZoIWcNn+9su1nptG7gYf+cb7MsClvNoEWSUrx9HEMZIREA g=; X-IronPort-AV: E=McAfee;i="5700,7163,7821"; a="214041451" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jun 2015 15:49:48 -0700 X-IronPort-AV: E=Sophos;i="5.13,549,1427785200"; d="scan'208";a="932239750" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jun 2015 15:49:47 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 3 Jun 2015 15:49:47 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Wed, 3 Jun 2015 15:49:47 -0700 From: "Wang, Ye-Kui" To: Magnus Westerlund , "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt Thread-Index: AQHQnVOMiH1NWr7R/0C2HiQDyhBXB52ZbRYwgAHLWICAACr0IA== Date: Wed, 3 Jun 2015 22:49:46 +0000 Message-ID: <36642853aa344677b1e2a1096a811a3a@NASANEXM01H.na.qualcomm.com> References: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> <1bf93a50375543d987c14fc3f2f7b9a9@NASANEXM01H.na.qualcomm.com> <556EFD1D.4010904@ericsson.com> In-Reply-To: <556EFD1D.4010904@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:49:54 -0000 Thanks Magnus again! That error was from accepting the change of moving a p= aragraph in the Word document. It's indeed a good idea to generate of diff prior to submission. Is there a= tool to do that before submission? BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Wednesday, June 03, 2015 6:12 AM To: Wang, Ye-Kui; payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt Hi, No issues with the intentional changes, but something went wrong in the edi= ting as start of Section 4.2 ended up in the wrong place. I will note that it is a good idea of generating a diff prior to submission= with the previous version to detect these type of issues. Cheers Magnus Wang, Ye-Kui skrev den 2015-06-02 18:52: > Compared to -10, the changes are: > - On the semantics of the F bit (forbidden_zero_bit) as discussed with Ma= gnus, Stephan, and Bo, and removed the informative reference to the UDP-Lit= e RFC. > - On the semantics of Marker bit (M) as suggested by Bo. > - Added Ben and Bo to the list of reviewers in the acknowledgements (Magn= us was there already). > > BR, YK > > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, June 02, 2015 9:45 AM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Payloads Working= Group of the IETF. > > Title : RTP Payload Format for High Efficiency Video C= oding > Authors : Ye-Kui Wang > Yago Sanchez > Thomas Schierl > Stephan Wenger > Miska M. Hannuksela > Filename : draft-ietf-payload-rtp-h265-11.txt > Pages : 100 > Date : 2015-06-02 > > Abstract: > This memo describes an RTP payload format for the video coding > standard ITU-T Recommendation H.265 and ISO/IEC International > Standard 23008-2, both also known as High Efficiency Video Coding > (HEVC) and developed by the Joint Collaborative Team on Video > Coding (JCT-VC). The RTP payload format allows for packetization > of one or more Network Abstraction Layer (NAL) units in each RTP > packet payload, as well as fragmentation of a NAL unit into > multiple RTP packets. Furthermore, it supports transmission of > an HEVC bitstream over a single as well as multiple RTP streams. > When multiple RTP streams are used, a single or multiple > transports may be utilized. The payload format has wide > applicability in videoconferencing, Internet video streaming, and > high bit-rate entertainment-quality video, among others. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-11 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > --=20 Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jun 3 15:52:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B221B3016 for ; Wed, 3 Jun 2015 15:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YBjzadjLpCx for ; Wed, 3 Jun 2015 15:52:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693951B3011 for ; Wed, 3 Jun 2015 15:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433371937; x=1464907937; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KazcUkfugh915IUEND9JrGqNDCoT4ek4qPiFL6HKf7c=; b=c39VSlvKF+U+fX3p/9pwd3GhCPlq4ZdK0PoJES4+nFdQwJFef07Um7eh 6/QIfKGlI95SeWPyuXi/fYva/tUvCypErwhfB+dTbSt2riXyeKuHjS35Y EyFkTB1bAVuK+FX3vEhDQ+z1HfRRKeLIitrOVaV3IMmFJD3aCFINd+GwW 4=; X-IronPort-AV: E=McAfee;i="5700,7163,7821"; a="121557021" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jun 2015 15:52:16 -0700 X-IronPort-AV: E=Sophos;i="5.13,549,1427785200"; d="scan'208";a="901218652" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jun 2015 15:52:16 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 3 Jun 2015 15:52:15 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Wed, 3 Jun 2015 15:52:15 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-13.txt Thread-Index: AQHQnk6lYibB1934S0OQ3YYzLbSPNJ2bYpSg Date: Wed, 3 Jun 2015 22:52:15 +0000 Message-ID: <94665cfd23404c03b7fdb76121f05b6b@NASANEXM01H.na.qualcomm.com> References: <20150603224230.15650.44496.idtracker@ietfa.amsl.com> In-Reply-To: <20150603224230.15650.44496.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-13.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:52:25 -0000 -12 fixes the wrong starting position of section 4.2, and -13 fixes an inco= rrect reference to section 4.2 that was introduced in -12.=20 BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, June 03, 2015 3:43 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-13.txt Pages : 100 Date : 2015-06-03 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-13 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Jun 3 17:50:45 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CBA1B30ED for ; Wed, 3 Jun 2015 17:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJubIE0OtJpE for ; Wed, 3 Jun 2015 17:50:42 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1061B30F5 for ; Wed, 3 Jun 2015 17:50:11 -0700 (PDT) Received: from pps.filterd (m0072270.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.14.7/8.14.7) with SMTP id t540kEej008666 for ; Wed, 3 Jun 2015 17:50:11 -0700 Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by mx0a-00195501.pphosted.com with ESMTP id 1ut8bbh506-1 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 03 Jun 2015 17:50:11 -0700 Received: from BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) by BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 4 Jun 2015 00:50:10 +0000 Received: from BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) by BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) with mapi id 15.01.0172.012; Thu, 4 Jun 2015 00:50:09 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: I-D Action: draft-ietf-payload-rtp-ancillary-01.txt Thread-Index: AQHQnmBo2igjoW8PJEmqD+1jgv1L1g== Date: Thu, 4 Jun 2015 00:50:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Edwards@fox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.205.246.229] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BLUPR05MB659; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB659; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(64706001)(62966003)(110136002)(450100001)(40100003)(5001860100001)(2501003)(2900100001)(189998001)(77156002)(5001830100001)(66066001)(81156007)(97736004)(122556002)(5002640100001)(4001540100001)(4001350100001)(2656002)(107886002)(46102003)(86362001)(92566002)(5001960100002)(105586002)(36756003)(87936001)(83506001)(19580395003)(19580405001)(77096005)(68736005)(102836002)(99286002)(106356001)(230783001)(54356999)(50986999)(229853001)(101416001)(106116001)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB659; H:BLUPR05MB659.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <8B75BB54AAE3CC49AC8546A0692F8ACE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2015 00:50:09.4463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB659 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-03_11:2015-06-03,2015-06-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506040010 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 00:50:44 -0000 Based on input from SMPTE members, the following changes were made in the new draft-ietf-payload-rtp-ancillary: 1) Made this explicitly clear: "If more than 255 ANC data packets need to be carried in a field or frame, additional RTP packets carrying ANC data may be sent with the same RTP timestamp but with different sequence numbers." 2) Added a "don't care" value of 0xFFF to Horizontal_Offset to indicate if the ANC data is carried without any specific location within the line. 3) Made this explicitly clear: "An ANC packet with the header fields Line_Number of 0x7FF and Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame." 4) Made this explicitly clear: "When reconstructing an SDI signal based on this payload, it is important to place ANC packets into the locations indicated by the ANC payload header fields Line_Number and Horizontal_Offset, and also to follow the requirements of SMPTE ST 291-1 [ST291] Section 7 "Ancillary Data Space Formatting (Component or Composite Interface)", which include rules on the placement of initial ANC data into allowed spaces as well as the contiguity of ANC data packet sequences within those spaces in order to assure that the resulting ANC packets in the SDI signal are valid." 5) A more clear example of multiple DID_SDID parameters in SDP. 6) Minor editorial nits. If there is any concern with these changes, please let me know! -Thomas --=20 Thomas Edwards=09 VP Engineering & Development FOX Networks Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 From nobody Thu Jun 4 15:15:20 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11E61AC3B1 for ; Thu, 4 Jun 2015 15:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1BSsoznwH2k for ; Thu, 4 Jun 2015 15:15:15 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7B31A88C5 for ; Thu, 4 Jun 2015 15:15:15 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-09v.sys.comcast.net with comcast id cNEy1q0055FMDhs01NFFGy; Thu, 04 Jun 2015 22:15:15 +0000 Received: from mail-vn0-f41.google.com ([209.85.216.41]) by resomta-po-19v.sys.comcast.net with comcast id cNDE1q00C0uAC6h01NDE3p; Thu, 04 Jun 2015 22:13:15 +0000 Received: by vnbg7 with SMTP id g7so862034vnb.10 for ; Thu, 04 Jun 2015 15:13:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.228.42 with SMTP id sf10mr534897vdc.12.1433455994164; Thu, 04 Jun 2015 15:13:14 -0700 (PDT) Received: by 10.52.190.230 with HTTP; Thu, 4 Jun 2015 15:13:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jun 2015 16:13:14 -0600 Message-ID: From: Kevin Gross To: Thomas Edwards Content-Type: multipart/alternative; boundary=089e01184d7a5562250517b87bb1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433456115; bh=C9ze8qHvecnVqeVMlh4gWn7vs8plYRa8Bgmr0k2/Mww=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=CyOYNjz5RxoRfSn+j9vqKuakg43LtB6IxEcWDDi/hxYlBUDw0t5iSDPmkC9N3ynsH EdUKRqvvJGEgE+ZRjfLGDSKsvtwzG/1hgO6q5eW24Erz3NKq8q+ri5B/oV2PjQeHzi ZtNmZC+SRMUboV2dOlQvG3qpUHn5MzIN+rwpWy9awCpBTiHZVg02LZzlHkQnLMuj// XNqaiswyEuWblonyvteYeAJhVnFnh6xbLtgbOq3hbne/A0Xrn1O6LuLfM6awTcVlbJ lNWgCIMkD/L9IVlmzCveiu3q10zb0GN46QBxrTZzaZcsMr47kdL17hoLt059unmXI5 MkTHHqPkM3PsA== Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 22:15:18 -0000 --089e01184d7a5562250517b87bb1 Content-Type: text/plain; charset=UTF-8 Thomas, I have some additional comments on your draft: Abstract: Consider providing a definition for "KLV" early on 1 Introduction: Jargon attenuation s/carriage of metadata within the bit stream multiplex of a Serial Digital Interface/carriage of metadata within the bit stream of a Serial Digital Interface Payload does not describe s/This RTP payload supports ANC data packets/This memo describes an RTP payload which supports ANC data packets Quotes unnecessary s/restored to their "original" locations/restored to their original locations Other wording improvements s/This payload could be used by itself, or used along with a range of RTP video formats. In particular, it has been specifically designed so that it could be used/This ANC payload can be used by itself, or used along with a range of RTP video formats. In particular, it has been designed so that it could be used 2.1 Payload Header Definitions Is there a justification you can provide for including Extended Header Sequence Number. Video payload protocols potentially require this because there may be many packets per video frame. I don't think that's the case for ANC. What is the maximum realistic rate for ANC data? We need some additional information about the ANC format to complete this draft. How do we find the beginning of each ANC packet in the payload? Where in an ANC packet is the Ancillary Data Flag (ADF)? Where do DID values come from? Based on what I've cleaned from the draft, it seems that we don't need both Length and ANC_Count. It seems like either would be sufficient to determine where payload data stops. You could possibly do without either and use the Length field in the UDP header to know when data ends. It is not clear to me what happens at (next ANC data packet). Is there another DID here or do we get a new Line_Number or something else? We need a better description of what an ANC data packet is. There's something off in Checksum_Word description, "The lower 8 bits of Checksum_Word, corresponding to bits b8 (MSB) through b0 (LSB) of the 10-bit data count word". b8 through b0 is 9 bits. Kevin Gross - AVA Networks On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards wrote: > Based on input from SMPTE members, the following changes were made in the > new draft-ietf-payload-rtp-ancillary: > > 1) Made this explicitly clear: > > "If more than 255 ANC data packets need to be carried in a field or frame, > additional RTP packets carrying ANC data may be sent with the same RTP > timestamp but with different sequence numbers." > > 2) Added a "don't care" value of 0xFFF to Horizontal_Offset to indicate if > the ANC data is carried without any specific location within the line. > > 3) Made this explicitly clear: > > "An ANC packet with the header fields Line_Number of 0x7FF and > Horizontal_Offset of 0xFFF SHALL be considered to be carried without any > specific location within the field or frame." > > 4) Made this explicitly clear: > > "When reconstructing an SDI signal based on this payload, it is > important to place ANC packets into the locations indicated by the ANC > payload header fields Line_Number and Horizontal_Offset, and also to > follow the requirements of SMPTE ST 291-1 [ST291] Section 7 "Ancillary > Data Space Formatting (Component or Composite Interface)", which > include rules on the placement of initial ANC data into allowed spaces > as well as the contiguity of ANC data packet sequences within those > spaces in order to assure that the resulting ANC packets in the SDI > signal are valid." > > 5) A more clear example of multiple DID_SDID parameters in SDP. > > 6) Minor editorial nits. > > If there is any concern with these changes, please let me know! > > -Thomas > > -- > Thomas Edwards > VP Engineering & Development > FOX Networks Engineering and Operations > thomas.edwards@fox.com > Phone: +1.310.369.6696 > 10201 West Pico Blvd. > Los Angeles, CA 90035 > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --089e01184d7a5562250517b87bb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas,

I have some additional comments= on your draft:


Abstract:

Consider providing a definition for "KLV" early o= n


1 Introduction:

Jargon attenuation
s/carriage of metadata within the bit stream=C2=A0multiplex=C2=A0<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">of a Serial Digital In= terface/carria= ge of metadata within the bit stream of a Serial Digital Interface

Payload does not describe=
s/<= /span>This RTP payloa= d supports ANC data packets/This=C2=A0memo describes an RTP payload which supports ANC data packets
=
Quotes unnecessary
s/restored to their "origina= l" locations/restored to their original locations

Other wording improvements
s/This payload could be used by itself, or= used along wi= th a range of RTP video formats. In particular, it has been specifically designed so tha= t it could be used/This ANC payload can be used by itself, or used along with a range of RTP video form= ats. In particular, it has been designed so that it could be used


2.1 Payload Header Defin= itions

Is there a justification you can provide for including Extended Header = Sequence Number. Video payload protocols potentially require this because t= here may be many packets per video frame. I don't think that's the = case for ANC. What is the maximum realistic rate for ANC data?
=

We need = some additional information about the ANC format to complete this draft. Ho= w do we find the beginning of each ANC packet in the payload? Where in an A= NC packet is the Ancillary Data Flag (ADF)? Where do DID values come from?<= /span>

Based on what I've cleaned from the draft, it seems that we don= 't need both Length and ANC_Count. It seems like either would be suffic= ient to determine where payload data stops. You could possibly do without e= ither and use the Length field in the UDP header to know when data ends.

It is not clear to me what happens at (next ANC data packet). Is there an= other DID here or do we get a new Line_Number or something else? We need a = better description of what an ANC data packet is.
<= font color=3D"#000000">
= There's something off in Checksum_Word description, "The lower 8 bits of Checksum_Word,= corresponding to bits b8 (MSB) through b0 (LSB) of the 10-bit data count word&qu= ot;. b8 through b0 is 9 bits.


Kevin Gross - AVA Networks

On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwar= ds <Thomas.Edwards@fox.com> wrote:
Based on input from SMPTE members, the following changes we= re made in the
new draft-ietf-payload-rtp-ancillary:

1) Made this explicitly clear:

"If more than 255 ANC data packets need to be carried in a field or fr= ame,
additional RTP packets carrying ANC data may be sent with the same RTP
timestamp but with different sequence numbers."

2) Added a "don't care" value of 0xFFF to Horizontal_Offset t= o indicate if
the ANC data is carried without any specific location within the line.

3) Made this explicitly clear:

"An ANC packet with the header fields Line_Number of 0x7FF and
Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame."

4) Made this explicitly clear:

"When reconstructing an SDI signal based on this payload, it is
important to place ANC packets into the locations indicated by the=C2=A0 = =C2=A0 ANC
payload header fields Line_Number and Horizontal_Offset, and also=C2=A0 =C2= =A0 to
follow the requirements of SMPTE ST 291-1 [ST291] Section 7=C2=A0 =C2=A0 &q= uot;Ancillary
Data Space Formatting (Component or Composite Interface)",=C2=A0 =C2= =A0 which
include rules on the placement of initial ANC data into allowed=C2=A0 =C2= =A0 spaces
as well as the contiguity of ANC data packet sequences within=C2=A0 =C2=A0 = those
spaces in order to assure that the resulting ANC packets in the=C2=A0 =C2= =A0 SDI
signal are valid."

5) A more clear example of multiple DID_SDID parameters in SDP.

6) Minor editorial nits.

If there is any concern with these changes, please let me know!

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.= 6696
10201 West Pico Blvd.
Los Angeles, CA 90035

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

--089e01184d7a5562250517b87bb1-- From nobody Fri Jun 5 00:19:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFDD1B2CCC; Fri, 5 Jun 2015 00:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn6dqTgq6evC; Fri, 5 Jun 2015 00:19:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F261B2CC3; Fri, 5 Jun 2015 00:19:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605071908.3374.41554.idtracker@ietfa.amsl.com> Date: Fri, 05 Jun 2015 00:19:08 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-16.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 07:19:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-16.txt Pages : 25 Date : 2015-06-05 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: https://tools.ietf.org/html/draft-ietf-payload-vp8-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 8 02:39:32 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7441B2DF0 for ; Mon, 8 Jun 2015 02:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pSuR0o80A8L for ; Mon, 8 Jun 2015 02:39:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831911B2DEF for ; Mon, 8 Jun 2015 02:39:28 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-1d-557562ce1ad4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.98.04401.EC265755; Mon, 8 Jun 2015 11:39:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 11:39:26 +0200 Message-ID: <557562CD.8050600@ericsson.com> Date: Mon, 8 Jun 2015 11:39:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Wang, Ye-Kui" , "payload@ietf.org" References: <20150602164527.7013.16695.idtracker@ietfa.amsl.com> <1bf93a50375543d987c14fc3f2f7b9a9@NASANEXM01H.na.qualcomm.com> <556EFD1D.4010904@ericsson.com> <36642853aa344677b1e2a1096a811a3a@NASANEXM01H.na.qualcomm.com> In-Reply-To: <36642853aa344677b1e2a1096a811a3a@NASANEXM01H.na.qualcomm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre65pNJQg/vT9CwuXTzLZPFkzTFm ByaPJUt+MnksmvqMMYApissmJTUnsyy1SN8ugSvjy/23rAXH2Ssu75zL1sA4ka2LkZNDQsBE YsGVyVC2mMSFe+uBbC4OIYGjjBKdj5qhnGWMEgtbpoFV8QpoS2ztvsoCYrMIqEgsm76dGcRm E7CQuPmjEaxGVCBKYurjdSwQ9YISJ2c+AbNFBEIlvnycyg5iCwu4SvSseM8MseAeo8S0FfvA BnEKeEssanvH2MXIwcEsYC/xYGsZSJhZQF6ieetssBIhoBsamjpYJzAKzEKyYhZCxywkHQsY mVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBIblwS2/VXcwXn7jeIhRgINRiYf3wb6SUCHW xLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYIz3z538d1qt3pOf BjPufFl7q3PFXUadLFEXmRe8Jzt+z2M4999N4LZO141/TCyOhauVBDJMHgpyHvlmcPbgru9V q9enzdmpqPD4XP4p43et2WHKq+1j1VoW/WYS/l7frm9jvtFlKkty3TmlKbxqF+d9WlHjZxil deHJDTnr441PF3RuVS8wmqPEUpyRaKjFXFScCAAhWDNlLAIAAA== Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:39:30 -0000 Wang, Ye-Kui skrev den 2015-06-04 00:49: > Thanks Magnus again! That error was from accepting the change of moving a paragraph in the Word document. > > It's indeed a good idea to generate of diff prior to submission. Is there a tool to do that before submission? > Use the web rfcdiff service: http://tools.ietf.org/rfcdiff That way you can even use a URL for the text version of the previous version or upload it yourself when comparing to the new version. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 18 17:45:28 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D851B2E24; Thu, 18 Jun 2015 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWz3yK_69Rqd; Thu, 18 Jun 2015 17:45:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC21B2BFF; Thu, 18 Jun 2015 17:45:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150619004525.28050.52388.idtracker@ietfa.amsl.com> Date: Thu, 18 Jun 2015 17:45:25 -0700 Archived-At: Cc: payload-chairs@ietf.org, draft-ietf-payload-vp8@ietf.org, payload@ietf.org Subject: [payload] Barry Leiba's No Objection on draft-ietf-payload-vp8-16: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 00:45:27 -0000 Barry Leiba has entered the following ballot position for draft-ietf-payload-vp8-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks very much for addressing all my comments. The downref to RFC 6386 was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't). That means we'd need to re-run a two-week last call for that. I'll leave it to the responsible AD to decide whether to do that or not. No further blocking from me on the point. From nobody Sat Jun 20 00:34:17 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6F1B2D87 for ; Sat, 20 Jun 2015 00:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JGbDNWZnyvn for ; Sat, 20 Jun 2015 00:34:15 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EAC1B2D7E for ; Sat, 20 Jun 2015 00:34:14 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so36211699wic.1 for ; Sat, 20 Jun 2015 00:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=pLucZyeJm0FXbvybK+1YgKPHpFo+oUsYsEqmNVUAvGc=; b=u4B8+9QJLJ4ChfU17QSRgRqScqjezzcYtmb8T3Lgl21VULmRHLCL8SD7kqID94oZJF 7qV4QEefBbXu6aR3nzwCoLBeanE8AUzdxJu3mtAQfQbUYTJyw0hBGluf6/d0vCLugJoB 1rJDVXOSgLF2k7eVYlIkC67xn2xD8cNfoZ6P6iNvWLj7t7UZwIEvSQN0h88dqOjIB1Ei TQGLNUcms5IAycruolIjnlf7vba0f1LLSDh+CKO+7Iq5m6Zt2A7q/t9waXkzdTypbn3T LDhlMGpKkpo1fiK5JjzGeGZiSt4fJ3/lryM37SUKtC0/Hl2TfOHROSxH3X/4p+xst/8D L7/g== X-Received: by 10.194.176.68 with SMTP id cg4mr32674213wjc.106.1434785653491; Sat, 20 Jun 2015 00:34:13 -0700 (PDT) Received: from RoniE ([109.66.172.245]) by mx.google.com with ESMTPSA id a9sm7005294wiv.13.2015.06.20.00.34.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 20 Jun 2015 00:34:12 -0700 (PDT) From: "Roni Even" To: Date: Sat, 20 Jun 2015 10:34:07 +0300 Message-ID: <057901d0ab2b$7f9f63c0$7ede2b40$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057A_01D0AB44.A4ED3800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCrKy4DIaJvxtoPSgKZLll1CfD0WA== Content-Language: en-us Archived-At: Subject: [payload] Agenda requests for PAYLOAD WG session IETF93 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 07:34:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057A_01D0AB44.A4ED3800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The preliminary agenda of IETF-92 was published. The Payload WG meeting is scheduled as follows: Monday, July 20, 2015 17:40 - 18:40 Afternoon Session III Berlin/Brussels ART Payload Audio/Video Transport Payloads WG Note that this scheduling is subject to change. Please send the chairs your requests for agenda items. Thanks and Regards, Roni Even Payload co-chair ------=_NextPart_000_057A_01D0AB44.A4ED3800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The = preliminary agenda of IETF-92 was published. The Payload WG meeting is = scheduled as follows:

 

 

Monday, July = 20, 2015

 

17:40 – 18:40  Afternoon Session = III

 

Berlin/Brussels  =           = ART            = Payload =             &= nbsp;       Audio/Video Transport Payloads = WG

 

Note that this scheduling is subject to change. =

 

Please send the chairs your requests for agenda items. =

 

Thanks and Regards,

 

Roni = Even

Payload = co-chair

 

------=_NextPart_000_057A_01D0AB44.A4ED3800-- From nobody Sat Jun 20 00:38:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674CB1A6F03 for ; Sat, 20 Jun 2015 00:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVNPiisvtOd1 for ; Sat, 20 Jun 2015 00:38:30 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049141ACE46 for ; Sat, 20 Jun 2015 00:38:30 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so104834355wgb.2 for ; Sat, 20 Jun 2015 00:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=fkI4U4ZrOcwd9KFuk4vkoBpE77IHBXlwnaNoiKorDag=; b=ZPeo/HvCb7reKNYfotMmLqJJV/AEycILqDnGzpaMWfmTKGRfQtqKNwYBoVl9W2LPWH UHnE9qIg9sJqwQluUuDj7Znywr+qtPv0eTE2ReuNpw3dC5WKXRLgwDCSyK8on9XPzA3x V9FL8cm2ZzmwDTZZIoPjEWt4b0oZb9i5Mtsaqn7tHrMTystdrA/MSUlF8a9VS41jX+rT oNuplF4sItXMBrfzOZ2gu6GoQDzUxE1P9jaqq4egABzho5bs89YoE7gVl4GfSIzo66gx YeLHh+dAf23vBOBqynytWvRoHAlDw9t9WRsXauN5ctvBeszqmMMHXeiHpLL7cVHQb6HC 3vMA== X-Received: by 10.194.97.196 with SMTP id ec4mr32953625wjb.3.1434785908783; Sat, 20 Jun 2015 00:38:28 -0700 (PDT) Received: from RoniE ([109.66.172.245]) by mx.google.com with ESMTPSA id di9sm7023999wib.16.2015.06.20.00.38.27 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 20 Jun 2015 00:38:28 -0700 (PDT) From: "Roni Even" To: Date: Sat, 20 Jun 2015 10:38:02 +0300 Message-ID: <057e01d0ab2c$17da5640$478f02c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057F_01D0AB45.3D282A80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCrKy4DIaJvxtoPSgKZLll1CfD0WA== Content-Language: en-us Archived-At: Subject: [payload] Agenda requests for PAYLOAD WG session IETF93 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 07:38:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057F_01D0AB45.3D282A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The preliminary agenda of IETF-93 was published. The Payload WG meeting is scheduled as follows: Monday, July 20, 2015 17:40 - 18:40 Afternoon Session III Berlin/Brussels ART Payload Audio/Video Transport Payloads WG Note that this scheduling is subject to change. Please send the chairs your requests for agenda items. Thanks and Regards, Roni Even Payload co-chair ------=_NextPart_000_057F_01D0AB45.3D282A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The = preliminary agenda of IETF-93 was published. The Payload WG meeting is = scheduled as follows:

 

 

Monday, July = 20, 2015

 

17:40 – 18:40  Afternoon Session = III

 

Berlin/Brussels  =           = ART            = Payload =             &= nbsp;       Audio/Video Transport Payloads = WG

 

Note that this scheduling is subject to change. =

 

Please send the chairs your requests for agenda items. =

 

Thanks and Regards,

 

Roni = Even

Payload = co-chair

 

------=_NextPart_000_057F_01D0AB45.3D282A80-- From nobody Mon Jun 22 05:40:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB831A1B8D for ; Mon, 22 Jun 2015 05:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C3Fzr2GVP0c for ; Mon, 22 Jun 2015 05:40:20 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06C1A1A6E for ; Mon, 22 Jun 2015 05:40:19 -0700 (PDT) X-ASG-Debug-ID: 1434976816-092fd314223f6c80001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id 1d7kFBIAUROAI1IL; Mon, 22 Jun 2015 08:40:16 -0400 (EDT) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 05480B41579; Mon, 22 Jun 2015 08:40:33 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" , , "'Ali C. Begen \(abegen\)'" References: <00d901d066b3$859e0810$90da1830$@gmail.com> In-Reply-To: <00d901d066b3$859e0810$90da1830$@gmail.com> Date: Mon, 22 Jun 2015 08:40:14 -0400 X-ASG-Orig-Subj: RE: [payload] comments on draft-demjanenko-payload-melpe-02 Message-ID: <033e01d0ace8$9711a310$c534e930$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033F_01D0ACC7.10000310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBmsWgRKdSfQ2i5QzWwMyEYVVAcvRGMjNQA Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1434976816 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.20072 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: dave.satterlee@vocal.com Subject: Re: [payload] comments on draft-demjanenko-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 12:40:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_033F_01D0ACC7.10000310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Roni, Ali, I would like to have our MELP RTP payload discussed and advanced toward an RFC at IETF-93 in July. We have updated our draft as per appendix of https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13. I believe I might not have addressed all of the below comments before so I will now. I appreciate all the help and suggestions offered. Please let me know what else needs to be addressed. Thanks. Victor From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, March 25, 2015 12:24 AM To: payload@ietf.org Subject: [payload] comments on draft-demjanenko-payload-melpe-02 Hi, I looked at the document and have some comments 1. The term MIME type is not used for RTP payload but we call it media subtype name , the media type is audio in your case v-> Looking at the 03 draft, I can find one place, near the end of section 4.2. Are you suggesting this should be "media subtype name" instead? Are there other places where this needs to be changed? 2. The term rate should probably be used for the clock rate and for what you call "rate" maybe use "bitrate" v-> Changed in the upcoming 04 draft to use "bitrate" 3. I am not sure what is the meaning of rate=600,1200,2400 in the offer, is that the sender capability to switch dynamically between these three rates? v-> Yes the sender may switch dynamically. This is referred to as dynamic rate switching. Do you think I need to explain this more? Where? 4. Are both sides need to use the same rate option (symmetric)? v-> No the section on SDP explains the negotiation and priority given to the answerer's preferred bit rate. 5. What is the meaning of an answer rate=600,1200 to the above offer? Does it mean that both sides can switch only between 600 and 1200. v-> Yes exactly. 6. We prefer not to have the rate in the media subtype name so use only MELP and MELPE and for fixed rate use the rate parameter. v-> Unfortunately there are legacy deployed systems that use the MELP2400, MELP1200 and MELP600 names. Otherwise I would be in complete agreement on your preference. 7. An RTP payload document must also have a congestion control section. You can look at https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to write an RTP payload specification and also look at one of the latest RTP audio payloads like opus (https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an example about the structure of an audio RTP payload and how to have the congestion control, security, IANA and SDP consideration sections v-> This was done in the preparation of the 03 draft. Hopefully I did not miss anything important. I know I did not split the suggested Background section contents from the Payload Format section. By this I mean I kept the original identification of the MELP parameters immediately ahead of each bit-rate payload format. This seemed to be a more natural organization of the material with less jumping between sections. Thanks Roni Even as individual ------=_NextPart_000_033F_01D0ACC7.10000310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni, Ali,

 

I would like to have our = MELP RTP payload discussed and advanced toward an RFC at IETF-93 in = July.  We have updated our draft as per appendix of http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13.  I = believe I might not have addressed all of the below comments before so I = will now.

 

I appreciate all the help and suggestions = offered.  Please let me know what else needs to be addressed.  = Thanks.

 

Victor

 

From:= = payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni = Even
Sent: Wednesday, March 25, 2015 12:24 AM
To: = payload@ietf.org
Subject: [payload] comments on = draft-demjanenko-payload-melpe-02

 

Hi,

I looked at the = document and have some comments

1.      = The term MIME type is not used for RTP payload = but we call it media subtype name , the media type is audio in your = case

v-> Looking at the 03 draft, I can find one = place, near the end of section 4.2.  Are you suggesting this should = be “media subtype name” instead?  Are there other = places where this needs to be changed?

2.      = The term rate should probably be used for the = clock rate and for what you call “rate” maybe use = “bitrate”

v-> Changed in the upcoming 04 draft to use = “bitrate”

3.      = I am not sure what is the meaning of = rate=3D600,1200,2400 in the offer, is that the sender capability to = switch dynamically between these three rates?

v-> Yes the sender = may switch dynamically.  This is referred to as dynamic rate = switching.  Do you think I need to explain this more?  = Where?

4.      = Are both sides need to use the same rate option = (symmetric)?

v-> No the section on SDP explains the = negotiation and priority given to the answerer’s preferred bit = rate.

5.      = What is the meaning of an answer rate=3D600,1200 = to the above offer? Does it mean that both sides can switch only between = 600 and 1200.

v-> Yes exactly.

6.      = We prefer not to have the rate in the media = subtype name so use only MELP and MELPE and for fixed rate use the rate = parameter.

v-> Unfortunately there are legacy deployed = systems that use the MELP2400, MELP1200 and MELP600 names.  = Otherwise I would be in complete agreement on your = preference.

7.      = An RTP payload document must also have a = congestion control section. You can look at http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to = write an RTP payload specification and also look at one of the latest = RTP audio payloads like opus (https= ://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an = example about the structure of an audio RTP payload and how to have the = congestion control, security, IANA and SDP consideration = sections

v-> This was done in the preparation of the = 03 draft.  Hopefully I did not miss anything important.  I = know I did not split the suggested Background section contents from the = Payload Format section.  By this I mean I kept the original = identification of the MELP parameters immediately ahead of each bit-rate = payload format.  This seemed to be a more natural organization of = the material with less jumping between sections.

 

Thanks

Roni Even as = individual

------=_NextPart_000_033F_01D0ACC7.10000310-- From nobody Mon Jun 22 09:52:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDDD1AD2D9 for ; Mon, 22 Jun 2015 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnopgo7vxNDG for ; Mon, 22 Jun 2015 09:52:53 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5696E1B3056 for ; Mon, 22 Jun 2015 09:52:50 -0700 (PDT) Received: by wguu7 with SMTP id u7so74576816wgu.3 for ; Mon, 22 Jun 2015 09:52:49 -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=2aw/uH6pvC/Yo1gHS0M6gQvbRE8+IoXhC9wrJ0UFaUA=; b=L2uqEfCN5PzZfuSDJpkergBAk8sUWKyMO39xvq8AXFAm1XeQL6WACIFvc/eqMX/2jd Mo3X18ouhbOkREmdjCcOjcIJhgmw/ImoPrmb3XLATCbQeUThUc85EXX+lsFEXa1gA2A1 bxOIRHV1NFgBgsaLudNEUIm468f6Gg3NXtIYUZWT8hWt3VL9ADB9VM7aHfvGlTtvY7Gi BjbZd6UYFJoPapX/osBGnOjr2c+gJ7sTnNi4Z1HMIFgbgj+OP6pu5H7S2uqUABJ1S/2t MvrBoD9OJOp/DXRR/0LESLHGCwsMJpWzP2ttiC+tqBUei73VfT7qFe78HZEF7w/MZtwY zEfQ== X-Received: by 10.180.73.244 with SMTP id o20mr33610276wiv.31.1434991968965; Mon, 22 Jun 2015 09:52:48 -0700 (PDT) Received: from RoniE (bzq-109-66-120-215.red.bezeqint.net. [109.66.120.215]) by mx.google.com with ESMTPSA id bz2sm15006196wjc.25.2015.06.22.09.52.45 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Jun 2015 09:52:47 -0700 (PDT) From: "Roni Even" To: "'Victor Demjanenko, Ph.D.'" , , "'Ali C. Begen \(abegen\)'" References: <00d901d066b3$859e0810$90da1830$@gmail.com> <55880233.d4968c0a.5abe.ffffe11eSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <55880233.d4968c0a.5abe.ffffe11eSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 22 Jun 2015 19:52:41 +0300 Message-ID: <067501d0ad0b$dd1857f0$974907d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0676_01D0AD25.02671690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvs0L9/fNoRQh9TV3NJhlVbqtJTwMWlXXXnWH4zBA= Content-Language: en-us Archived-At: Cc: dave.satterlee@vocal.com Subject: Re: [payload] comments on draft-demjanenko-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 16:52:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0676_01D0AD25.02671690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Victor, We can discuss the MELP at the Payload session in Prague, will you be there? As for the comments see inline ( the response on the comments are as an individual and not as the WG chair) Roni From: Victor Demjanenko, Ph.D. [mailto:victor.demjanenko@vocal.com] Sent: 22 June, 2015 3:40 PM To: 'Roni Even'; payload@ietf.org; 'Ali C. Begen (abegen)' Cc: 'Victor Demjanenko, Ph.D.'; dave.satterlee@vocal.com Subject: RE: [payload] comments on draft-demjanenko-payload-melpe-02 Roni, Ali, I would like to have our MELP RTP payload discussed and advanced toward an RFC at IETF-93 in July. We have updated our draft as per appendix of https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13. I believe I might not have addressed all of the below comments before so I will now. I appreciate all the help and suggestions offered. Please let me know what else needs to be addressed. Thanks. Victor From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, March 25, 2015 12:24 AM To: payload@ietf.org Subject: [payload] comments on draft-demjanenko-payload-melpe-02 Hi, I looked at the document and have some comments 1. The term MIME type is not used for RTP payload but we call it media subtype name , the media type is audio in your case v-> Looking at the 03 draft, I can find one place, near the end of section 4.2. Are you suggesting this should be "media subtype name" instead? Are there other places where this needs to be changed? [Roni Even] Yes 2. The term rate should probably be used for the clock rate and for what you call "rate" maybe use "bitrate" v-> Changed in the upcoming 04 draft to use "bitrate" 3. I am not sure what is the meaning of rate=600,1200,2400 in the offer, is that the sender capability to switch dynamically between these three rates? v-> Yes the sender may switch dynamically. This is referred to as dynamic rate switching. Do you think I need to explain this more? Where? [Roni Even] Please explain where you define the rate parameter 4. Are both sides need to use the same rate option (symmetric)? v-> No the section on SDP explains the negotiation and priority given to the answerer's preferred bit rate. [Roni Even] My reading is that the offer includes the send capabilities while the answer is the receive capabilities. So it means that the result MUST be symmetrical, you can provide better options if you use the send and recv attributes. 5. What is the meaning of an answer rate=600,1200 to the above offer? Does it mean that both sides can switch only between 600 and 1200. v-> Yes exactly. 6. We prefer not to have the rate in the media subtype name so use only MELP and MELPE and for fixed rate use the rate parameter. v-> Unfortunately there are legacy deployed systems that use the MELP2400, MELP1200 and MELP600 names. Otherwise I would be in complete agreement on your preference. [Roni Even] If an offer is with MELP1200 can the answer use MELP rate =1200 or is it mandatory to use the same subtype name? 7. An RTP payload document must also have a congestion control section. You can look at https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to write an RTP payload specification and also look at one of the latest RTP audio payloads like opus (https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an example about the structure of an audio RTP payload and how to have the congestion control, security, IANA and SDP consideration sections v-> This was done in the preparation of the 03 draft. Hopefully I did not miss anything important. I know I did not split the suggested Background section contents from the Payload Format section. By this I mean I kept the original identification of the MELP parameters immediately ahead of each bit-rate payload format. This seemed to be a more natural organization of the material with less jumping between sections. Thanks Roni Even as individual ------=_NextPart_000_0676_01D0AD25.02671690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Victor,

 

We can discuss the MELP = at the Payload session in Prague, will you be = there?

As for the comments see inline ( the response on = the comments are as an individual and not as the WG = chair)

Roni

 

From:= = Victor Demjanenko, Ph.D. [mailto:victor.demjanenko@vocal.com] =
Sent: 22 June, 2015 3:40 PM
To: 'Roni Even'; = payload@ietf.org; 'Ali C. Begen (abegen)'
Cc: 'Victor = Demjanenko, Ph.D.'; dave.satterlee@vocal.com
Subject: RE: = [payload] comments on = draft-demjanenko-payload-melpe-02

 

Roni, Ali,

 

I would like to have our = MELP RTP payload discussed and advanced toward an RFC at IETF-93 in = July.  We have updated our draft as per appendix of http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13.  I = believe I might not have addressed all of the below comments before so I = will now.

 

I appreciate all the help and suggestions = offered.  Please let me know what else needs to be addressed.  = Thanks.

 

Victor

 

From:= = payload [mailto:payload-bounces@ietf.org<= /a>] On Behalf Of Roni Even
Sent: Wednesday, March 25, = 2015 12:24 AM
To: payload@ietf.org
Subject: = [payload] comments on = draft-demjanenko-payload-melpe-02

 

Hi,

I looked at the = document and have some comments

1.       = The term MIME type is not = used for RTP payload but we call it media subtype name , the media type = is audio in your case

v-> Looking at the 03 draft, I can find one = place, near the end of section 4.2.  Are you suggesting this should = be “media subtype name” instead?  Are there other = places where this needs to be changed?

[Roni Even] = Yes

2.       = The term rate should = probably be used for the clock rate and for what you call = “rate” maybe use “bitrate”

v-> Changed in the = upcoming 04 draft to use “bitrate”

3.       = I am not sure what is the = meaning of rate=3D600,1200,2400 in the offer, is that the sender = capability to switch dynamically between these three = rates?

v-> Yes the sender may switch = dynamically.  This is referred to as dynamic rate switching.  = Do you think I need to explain this more?  = Where?

[Roni Even] Please explain where you define the = rate parameter

4.       = Are both sides need to = use the same rate option (symmetric)?

v-> No the section on = SDP explains the negotiation and priority given to the answerer’s = preferred bit rate.

 

[Roni Even] My = reading is that the offer includes the send capabilities while the = answer is the receive capabilities. So it means that the result MUST be = symmetrical, you can provide better options if you use the send and recv = attributes.

5.       = What is the meaning of an = answer rate=3D600,1200 to the above offer? Does it mean that both sides = can switch only between 600 and 1200.

v-> Yes = exactly.

6.       = We prefer not to have the = rate in the media subtype name so use only MELP and MELPE and for fixed = rate use the rate parameter.

v-> Unfortunately there are legacy deployed = systems that use the MELP2400, MELP1200 and MELP600 names.  = Otherwise I would be in complete agreement on your = preference.

[Roni Even] If an offer is with MELP1200 can the = answer use MELP rate =3D1200 or is it mandatory to use the same subtype = name?

7.       = An RTP payload document = must also have a congestion control section. You can look at http= s://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13 about how to = write an RTP payload specification and also look at one of the latest = RTP audio payloads like opus (https= ://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an = example about the structure of an audio RTP payload and how to have the = congestion control, security, IANA and SDP consideration = sections

v-> This was done in the preparation of the = 03 draft.  Hopefully I did not miss anything important.  I = know I did not split the suggested Background section contents from the = Payload Format section.  By this I mean I kept the original = identification of the MELP parameters immediately ahead of each bit-rate = payload format.  This seemed to be a more natural organization of = the material with less jumping between sections.

 

Thanks

Roni Even as = individual

------=_NextPart_000_0676_01D0AD25.02671690-- From nobody Wed Jun 24 01:07:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39BF1B31CA for ; Wed, 24 Jun 2015 01:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t98JXw1hOFlJ for ; Wed, 24 Jun 2015 01:07:56 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C2F1B31BF for ; Wed, 24 Jun 2015 01:07:56 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so28250339ieb.2 for ; Wed, 24 Jun 2015 01:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ecRV7Wz1drIlh5b5yfxwpkEV5i584/j+nsaZfSA0e3E=; b=abvmhWC19DcVdzcVS8GhWZC/6S9vtvbhZSItpAD3Uf2NDii5amQwTBzjLprcRR1P9f IY99m/rFiOO27pXSY+zyoME3DpvHGvVOFZICAF7+KoEf+4v9hCQVqVAX40b4oGlV0hGd G1ZQBapW81K7DYnP4A43zrOugVQvWhbID4EhHnxYG1hSmAPF9IqNG5kzeghwi7OHhFKk SxXf7LCovHrjr4lof0TScFjRNuAxWgqU0yJrRYlIh81TuzBMV09wayksnPVg00cDTyby vrjc+BzjS7jicJKTLLS8g2Sk65/TMzD/UcbLFZMTULedYjtq+T6lvgOfcBT9Ey5jl8mn lbEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ecRV7Wz1drIlh5b5yfxwpkEV5i584/j+nsaZfSA0e3E=; b=GpK+IPcSoEYdppiZ3ZWRVcv66sBwbKORgiSL4pA4YVZOS42bHXw97VWyRmbCGvKklV cSv8LRS6YRyLAWFWGZaMTlp7eN16FAro8GPf+7yUAIJAdmmZGSwDFd3AJxKfYF1RvzqD KLXir++aZyELt1Z4U91rY/Ty6cX7Ko/aVQ5tU2LRnq56dOcGh+lF99gtPCy1LzteYIl+ PdZZn++4c9L+AznRevD6LamcFvgyJHOjU2+KMIAwwyQ+9vVu8iXKtpY3HBtXktF2dHo/ TSUscMLuzaxSZRZo1YAphN9w7+Gapg2eExvUMMj/yG/AhQAS2d02mZh24+aTnRda1gIe MBmg== X-Gm-Message-State: ALoCoQnxv73JIvI++tT6aYnO+JgXrCXDZoyE6Ibh/qMu42E9F6b1Oog5yRm/wqiy58yiKT4WCJYW MIME-Version: 1.0 X-Received: by 10.107.10.151 with SMTP id 23mr49466657iok.89.1435133276014; Wed, 24 Jun 2015 01:07:56 -0700 (PDT) Received: by 10.64.228.241 with HTTP; Wed, 24 Jun 2015 01:07:55 -0700 (PDT) Date: Wed, 24 Jun 2015 10:07:55 +0200 Message-ID: From: Henrik Lundin To: "payload@ietf.org" Content-Type: multipart/alternative; boundary=001a113ee4761f897b05193f01f4 Archived-At: Subject: [payload] Summary of recent updates to draft-ietf-payload-vp8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 08:07:57 -0000 --001a113ee4761f897b05193f01f4 Content-Type: text/plain; charset=UTF-8 Dear all, Ben Campbell kindly pointed out that we have submitted two new revisions of draft-ietf-payload-vp8 without posting a summary to the list. This is what has changed in revisions 15 and 16: - Slightly changed wording in Section 4.2 Payload Descriptor. Improving the description of the extension bits and fields. [rev 16] - Moved the max-fr and max-fs parameters from "Required parameters" to "Optional parameters". The rationale for moving is to make it clear that they can be omitted in a send-only situation. Added a sentence that the parameters must be provided by an implementation willing to receive media. [rev 16] - Added "Fragment identifier considerations: N/A." [rev 16] - Dividing references into normative and informative. [rev 15] The authors have asked the AD to consider what the IESG should do next with the document. Thanks! /Henrik -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --001a113ee4761f897b05193f01f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Ben Campbell ki= ndly pointed out that we have submitted two new revisions of draft-ietf-pay= load-vp8 without posting a summary to the list. This is what has changed in= revisions 15 and 16:=C2=A0

- Slightly change= d wording in Section 4.2 Payload Descriptor. Improving the description of t= he extension bits and fields.=C2=A0= [rev 16]=C2=A0

- Moved the max-fr and max-fs parameters from "Required para= meters" to "Optional parameters". The rationale for moving i= s to make it clear that they can be omitted in a send-only situation. Added= a sentence that the parameters must be provided by an implementation willi= ng to receive media.=C2=A0[rev 16]<= /span>=C2=A0

- Added "Fragment identifier considerations: =C2=A0N/A."=C2=A0<= /span>[rev 16]=C2=A0

- Dividing references into= normative and informative.=C2=A0[r= ev 15]=C2=A0

The authors have asked the AD to consider what the IESG should do next wi= th the document.

Thanks!
/Henrik


--
Henrik Lundin=C2=A0|=C2=A0WebRTC Software Eng=C2=A0|=C2=A0hlundin@google.com=C2=A0|=C2=A0+46 70 646 13 41
<= font face=3D"'Times New Roman'" size=3D"3">
--001a113ee4761f897b05193f01f4-- From nobody Mon Jun 29 14:51:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FEF1B355B; Mon, 29 Jun 2015 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpNsv0vAF_4B; Mon, 29 Jun 2015 14:51:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C341A905C; Mon, 29 Jun 2015 14:51:00 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5TLojQo092202 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2015 16:50:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-payload-vp8.all@ietf.org, payload-chairs@ietf.org, payload@ietf.org Date: Mon, 29 Jun 2015 16:50:45 -0500 Message-ID: <8163A1DE-531A-4CDA-AA6F-61ADCDAE784B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [payload] Questions on draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:51:05 -0000 Hi, I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a repeat IETF Last Call. I have a few comments. I don't think any of these need delay the last call, so please address them along with any last call comments. Please bear in mind that I am reconstructing a lot of history here, so I apologize in advance if I bring up things that have already been discussed. Thanks! Ben. ------------ General: Ted Lemon and Pete Resnick made some AD comments when they were still ADs. Even though they are no longer on the IESG, their comments look reasonable. I don't see evidence that they have been addressed--please consider addressing them. It looks like you have addressed some, but not all, of Stephen Farrell's comments. Has there been discussion on why the ones not addressed were not addressed? (Note that in both of the paragraphs above, I don't mean by "addressed" that the draft necessarily needs to change--just that the authors respond to the input--even if only to say why they don't agree with a comment.) -- 4.5 and 4.5.1: It would be helpful to explain why these are listed as examples. I assume it's one of those cases where this algorithm gives the right results, but others could also do so. If so, some words to that effect would be helpful. It might also be helpful to include a few words indicating why 4.5.1 is a child of 4.5 rather than a peer. (I assume because partition reconstruction is a subset of frame reconstruction?) -- 7: I don't see a response to the secdir review ( Secdir review of draft-ietf-payload-vp8-08 ). For the SRTP question, please consider using the boilerplate in the appendix of draft-ietf-payload-rtp-howto-14 (section A.13). From nobody Mon Jun 29 16:20:49 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0771B2EF0; Mon, 29 Jun 2015 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFxWlYEajwzl; Mon, 29 Jun 2015 16:20:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13A1B3024; Mon, 29 Jun 2015 16:20:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150629232045.6629.59809.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 16:20:45 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for VP8 Video) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 29 Jun 2015 23:20:46 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for VP8 Video' as Proposed Standard This draft contains normative reference to an Informational RFC: RFC 6386 This is a repeated last call. The draft was previously last called and underwent IESG evaluation in 2013. The last call is being repeated due to the normative downward reference, and due to the fairly significant changes since that evaluation. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1622/ From nobody Tue Jun 30 16:36:32 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47131B2A68; Tue, 30 Jun 2015 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_XsEBv44GHs; Tue, 30 Jun 2015 16:36:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4281B2A60; Tue, 30 Jun 2015 16:36:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A955D18046B; Tue, 30 Jun 2015 16:33:17 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150630233317.A955D18046B@rfc-editor.org> Date: Tue, 30 Jun 2015 16:33:17 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 7587 on RTP Payload Format for the Opus Speech and Audio Codec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 23:36:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7587 Title: RTP Payload Format for the Opus Speech and Audio Codec Author: J. Spittka, K. Vos, JM. Valin Status: Standards Track Stream: IETF Date: June 2015 Mailbox: jspittka@gmail.com, koenvos74@gmail.com, jmvalin@jmvalin.ca Pages: 18 Characters: 41770 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-payload-rtp-opus-11.txt URL: https://www.rfc-editor.org/info/rfc7587 DOI: http://dx.doi.org/10.17487/RFC7587 This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC