From internet-drafts@ietf.org Mon Jun 3 04:34:44 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991CA21F9622; Mon, 3 Jun 2013 04:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b97GOGD+USG; Mon, 3 Jun 2013 04:34:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 387CF21F8DBC; Mon, 3 Jun 2013 04:34:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603113444.24974.7328.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 04:34:44 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:34:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-04.txt Pages : 51 Date : 2013-06-03 Abstract: This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Jun 3 04:42:50 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D542A21F94E1 for ; Mon, 3 Jun 2013 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7eRoFDEhASr for ; Mon, 3 Jun 2013 04:42:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8521F9635 for ; Mon, 3 Jun 2013 04:42:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-b5-51ac812f2367 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A4.36.09795.F218CA15; Mon, 3 Jun 2013 13:42:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 3 Jun 2013 13:42:38 +0200 Message-ID: <51AC8159.2020907@ericsson.com> Date: Mon, 3 Jun 2013 13:43:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "payload@ietf.org" References: <20130603113444.24974.7328.idtracker@ietfa.amsl.com> In-Reply-To: <20130603113444.24974.7328.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvra5+45pAg907LSwuXTzL5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ7Tr1gKpohUTD/5l6WBcbFAFyMHh4SAiUTT0pwuRk4gU0zi wr31bF2MXBxCAqcYJZ6/2c0IkhASWMYoMXNWMkg9r4C2xOt9oSAmi4CKxKzNBSAVbAIWEjd/ NLKB2KICwRJHtm9mAbF5BQQlTs58wgJSLiKgKfHouxBIWFjARmL32Q2sEMMdJDad6GAGKeEU cJQ4/CYD4hhJiS0v2tlBbGYBPYkpV1sYIWx5ieats5khWrUlGpo6WCcwCs5CsmwWkpZZSFoW MDKvYmTPTczMSS8338QIDLqDW34b7GDcdF/sEKM0B4uSOK8+7+JAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYw5N3/vzgg6ciW1tONVp25aNLfqz6NJNh3x8332ypjfFPg3Tck7YzX3CgnB nFlXP5/OF/x9J0iE9eelmo5fNkKvdNy73jk3nmk5fy8uOjjxoNba/uWmS6XEGY7ccT2mYC3h 1lwld8BcOr76RcE3d6OFK0u3N96L+8Pw/VdAfuGv5lzFlSfXGCixFGckGmoxFxUnAgBL3A5g CAIAAA== Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:42:50 -0000 WG, This update is to address some comments Colin Perkins sent to me. The result is that the security overview in this document has been shorten and more emphasis on the RTP Security Options placed. It also has some more ALF discussion in the context of Video. More discussion of the Top media type Application, including reference to ongoing congestion control work with circuit breaker and RMCAT WG. Finally some more discussion of Media Type Parameters in the context of IANA sections. Cheers Magnus On 2013-06-03 13:34, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > Title : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-04.txt > Pages : 51 > Date : 2013-06-03 > > Abstract: > This document contains information on how to best write an RTP > payload format. It provides reading tips, design practices, and > practical tips on how to produce an RTP payload format specification > quickly and with good results. A template is also included with > instructions that can be used when writing an RTP payload format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rlb@ipv.sx Tue Jun 4 13:11:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE921F918F for ; Tue, 4 Jun 2013 13:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsgGpDhjwv2P for ; Tue, 4 Jun 2013 13:11:06 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 24E0921F9B31 for ; Tue, 4 Jun 2013 12:14:51 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so1096557obc.13 for ; Tue, 04 Jun 2013 12:14:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FZfxxQwzfqxuCG4+7AYlOnIrhVbj0b3t5qWLGYCVN3s=; b=WB2DNzi+1w7+kOeD43tunzjfrJmkYN2GrfVpGXRmx7gVTFcbM9lslR2IZ2RP2X4tn+ kr0P1aNVcSJRP/v2cdFcyx1+h7T291Dl9hqmqVvtVJMK1y2Guq2TSLiemf6UdTM+TQDY YJQFtP434RR2Oa7GOE6T6AzBv2/KaaaNxuS1G5+tReX3HlS4ML6Pq8ViOvgmhx6cQskH kGi1G+wIfvifzPEZbf0MK1mkVhSMzgVWt/JA4ldCzAnNg56ksZDeHEmvVuyQYzqL20dI 2Q3b3p0Nps9amo55zWOZqCsVg5c6xtgvUpy086KQEwKsbjsTMYFPB78iuTWCoEh1+o8C ygiA== MIME-Version: 1.0 X-Received: by 10.182.74.131 with SMTP id t3mr12795394obv.87.1370373290632; Tue, 04 Jun 2013 12:14:50 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Tue, 4 Jun 2013 12:14:50 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: Date: Tue, 4 Jun 2013 15:14:50 -0400 Message-ID: From: Richard Barnes To: Patrik Westin Content-Type: multipart/alternative; boundary=001a11c1be0632dadf04de58e592 X-Gm-Message-State: ALoCoQkiBedjWVQj4lZ6OUFUEMlF0EmcFD+usorYtaCPfrZiUUnf5Xj9OCtvmhFPyRhchwZj3aFy Cc: "payload@ietf.org" Subject: Re: [payload] AD review of draft-ietf-payload-vp8-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 20:11:15 -0000 --001a11c1be0632dadf04de58e592 Content-Type: text/plain; charset=ISO-8859-1 Hi Patrik, Thanks for following up on this. Your explanation is much clearer (in particular, it clarifies that the PictureID is for feedback only). I've included one more revision below which I think clarifies a little further. Could you please add something like this to Section 4.4? In the meantime, I'll go ahead and send this out for IETF LC. Thanks, --Richard 1. Collect all packets with a given RTP timestamp 2. Order the packets by sequence number. If packets are missing, send NACK or decode with missing partitions, see 4.x below. 3. Find the first packet with S=1 and partId=0. This indicates the beginning of a frame. 4. While there is more data in the stream, attempt to read a new frame: 4.1. Until reaching the end of the frame (a packet with the marker bit set), reconstruct partitions: 4.1.1. Scan for the start of the next partition (S=1) 4.1.2. If loss is detected in the partition, discard all packets in this partition 4.1.3. Otherwise, store the packets for this partition 4.2. Send all complete partitions to the decode. If no complete partition is found, discard the whole frame. On Tue, May 21, 2013 at 11:22 AM, Patrik Westin wrote: > This is how I think about it > > 1. Collect all packets with a given RTP timestamp > 2. Go through packets in order, sorted by sequence numbers, if packets are > missing, send NACK or decode with missing partitions, see 4.x below. > 3. Complete frame is detected by no missing sequence numbers and first > packet in the frame containing S=1 with partId=0 and the last packet in the > frame having the marker bit set. > 4.1 scan for the start of a new partition; S=1 > 4.2 continue scan to detect end of partition; hence a new S=1 (previous > packet was the end of the partition) is found or the marker bit is set, if > a loss it detected before the end of the partition abandon all packets in > this partition and continue the scan repeating 4.1 > 4.3 store the packets in the complete partition continue the scan > repeating 4.1 until end of frame is reached. > 4.4 send all complete partitions to the decoder, if no complete partition > is found discard the whole frame. > > > Regarding the minor issues: > VP8 only support 8 partitions hence 3-bits in the PartID field should > therefor be enough. > > We have nothing that force the PictureID length to be fixed size during > the session, the receiver must handle both cases so in practice it make no > difference to the receiver. If the sender out of convenience want to keep > the same length it's free to do so. > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > --001a11c1be0632dadf04de58e592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Patrik,

Thanks for following up on t= his. =A0Your explanation is much clearer (in particular, it clarifies that = the PictureID is for feedback only). I've included one more revision be= low which I think clarifies a little further. =A0Could you please add somet= hing like this to Section 4.4?

In the meantime, I'll go ahead and send this out fo= r IETF LC.

Thanks,
--Richard
<= br>

1. Collect all packets with a given RTP t= imestamp

2. Order the packets by sequence number. =A0If packets = are missing, send NACK or decode with missing partitions, see 4.x below.

3. Find the first packet with S=3D1 and partId=3D0. = =A0This indicates the beginning of a frame.

4. While there is more data in the stream, attempt to r= ead a new frame:

4.1. Until reaching the end of th= e frame (a packet with the marker bit set), reconstruct partitions:

4.1.1. Scan for the start of the next partition (S=3D1)=

4.1.2. If loss is detected in the partition, disc= ard all packets in this partition=A0

4.1.3. Otherw= ise, store the packets for this partition

4.2. Send all complete partitions to the decode. =A0If = no complete partition is found, discard the whole frame.





On Tue, May 21, 2013 at 11:22 AM, Patrik= Westin <patrik.westin@gmail.com> wrote:
This is how I think about it

1. C= ollect all packets with a given RTP timestamp
2. Go through packets in o= rder, sorted by sequence numbers, if packets are missing, send NACK or deco= de with missing partitions, see 4.x below.
3. Complete frame is detected by no missing sequence numbers and first pack= et in the frame containing S=3D1 with partId=3D0 and the last packet in the= frame having the marker bit set. =A0
4.1 scan for the start of a new pa= rtition; S=3D1
4.2 continue scan to detect end of partition; hence a new S=3D1 (previous p= acket was the end of the partition) is found or the marker bit is set, if a= loss it detected before the end of the partition abandon all packets in th= is partition and continue the scan repeating 4.1
4.3 store the packets in the complete partition continue the scan repeating= 4.1 until end of frame is reached.=A0
4.4 send all complete partitions = =A0to the decoder, if no complete partition is found discard the whole fram= e.


Regarding the minor issues:
VP8 only support 8 par= titions =A0hence 3-bits in the PartID field should therefor be enough.

We = have nothing that force the PictureID length to be fixed size during the session, t= he receiver must handle both cases so in practice it make no difference to = the receiver. If the sender out of convenience want to keep the same length= it's free to do so.

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


--001a11c1be0632dadf04de58e592-- From iesg-secretary@ietf.org Tue Jun 4 15:25:57 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9069A21F999A; Tue, 4 Jun 2013 15:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-Pe+nVD3MkY; Tue, 4 Jun 2013 15:25:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6C21F9992; Tue, 4 Jun 2013 15:25:55 -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: 4.50 Sender: Message-ID: <20130604222555.32402.16024.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 15:25:55 -0700 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.12 Precedence: list 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: Tue, 04 Jun 2013 22:25:57 -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 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 2013-06-18. 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 http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1622/ From yekuiw@qti.qualcomm.com Tue Jun 11 10:00:37 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A82E21F9016 for ; Tue, 11 Jun 2013 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovaPQKU6PSXC for ; Tue, 11 Jun 2013 10:00:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 154F621F8FEC for ; Tue, 11 Jun 2013 10:00:33 -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=1370970033; x=1402506033; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AKhyxNgx8KL7gp/8BSfJwZK2rqId0Z3IIh+S9DRGA58=; b=ZG7nFeDRlWS6jo7RvPhbBjiJxjHuI8U5+xY0UQ9DgZpiBKA8Jb+8FlUa yVzEJYY5hx0g3UCfcfOB7P6z6nsoZpR9NiHYaMcgYyF1OvU+2J3qTxNsC 0wDqwOI+p6qmaHxvhB1eSO5fnOKH5xXg/OulXFBgKCY2inQTSDlc3NXXf k=; X-IronPort-AV: E=Sophos;i="4.87,846,1363158000"; d="scan'208";a="55633442" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 11 Jun 2013 10:00:32 -0700 X-IronPort-AV: E=Sophos;i="4.87,846,1363158000"; d="scan'208";a="551894184" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Jun 2013 10:00:19 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.230]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 10:00:19 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: Submission of new versions of H.265/HEVC payload format Thread-Index: Ac5mxRy1XpIRDmQdTgeDR7RG12PPdA== Date: Tue, 11 Jun 2013 17:00:19 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:00:37 -0000 Dear All, We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows: Version 02: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-02.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-02 Version 03: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-03.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-03 Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author. Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft.=20 BR, YK (on behalf of the authors) From ron.even.tlv@gmail.com Wed Jun 12 08:41:31 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2168D21F99C9 for ; Wed, 12 Jun 2013 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po8Ilkl50OM9 for ; Wed, 12 Jun 2013 08:41:30 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB221F99BB for ; Wed, 12 Jun 2013 08:41:29 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so6940672eak.18 for ; Wed, 12 Jun 2013 08:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=DmfHCndm1REMIUaIj2F79CpwLV4oNAGPkvDdrMZKhaI=; b=fiKlAqIsyBVZK+SUcLM5Yp+YJOdi4f0w28m0UZQaUV/MI+qmyN5MmCcbdtvaTa+ADo ovHsXqGfwbBsNQWWoActUHJBw0meKH1BbZ1eFm1G2tPOp7xybC6lwWc6jYLVJZyJcEKO l3YNSnEPJJ/fQzxJ37bHbb8Ln6ghai9XPW3moLNnZ16cYuCNzFK/6R52c8VNVpBKjG32 ZWd4kDRvsihA1rMsI/r208zDBlSePVK4owLpq904YPA9/Qea7KiYOuZBk74jt9vg25eQ mcCc/BCyW6y+ohxVVSWqD9Z1ksjiMXDi5ef6AIbum15+NydY/Q3J2t5pAtVmaEVjyajw +eCQ== X-Received: by 10.14.47.73 with SMTP id s49mr14092055eeb.71.1371051689191; Wed, 12 Jun 2013 08:41:29 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id a4sm4050738eez.0.2013.06.12.08.41.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 12 Jun 2013 08:41:28 -0700 (PDT) From: "Roni Even" To: Date: Wed, 12 Jun 2013 18:40:06 +0300 Message-ID: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D8_01CE679C.442CD130" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5ngwrun8+6pBZ+RHS6vfa9Cec8SQ== Content-Language: en-us Subject: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:41:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D8_01CE679C.442CD130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The ITU-T approved a new video codec High Efficiency Video Coding also known as H.265. There is an individual draft titled RTP Payload Format for High Efficiency Video Coding draft-schierl-payload-rtp-h265-03 The WG chairs would like to ask for a new milestone for December 2013 RTP Payload Format for High Efficiency Video Coding and accept this document as the initial document to address the milestone. The WG chairs are looking for WG feedback Please respond by Monday July 1st 2013 with your positions. Roni Even PAYLOAD WG co-chair ------=_NextPart_000_06D8_01CE679C.442CD130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

The ITU-T = approved a new video codec High = Efficiency Video Coding also known as  H.265= .

 =

There is = an individual draft  titled RTP Payload Format for High = Efficiency Video Coding dra= ft-schierl-payload-rtp-h265-03 =

 =

The WG = chairs would like to ask for a new milestone for December 2013 RTP = Payload Format for High = Efficiency Video Coding and = accept this document as the initial document to address the = milestone.

The WG = chairs are looking for WG feedback

 =

Please = respond by Monday July 1st  2013 with your positions. =

 

Roni Even

PAYLOAD WG = co-chair

 

 

------=_NextPart_000_06D8_01CE679C.442CD130-- From ron.even.tlv@gmail.com Thu Jun 13 04:29:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34521F9133 for ; Thu, 13 Jun 2013 04:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDbZPggtd5fS for ; Thu, 13 Jun 2013 04:29:26 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 06BDC21F99F7 for ; Thu, 13 Jun 2013 04:29:24 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d49so5080403eek.9 for ; Thu, 13 Jun 2013 04:29:15 -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:x-mailer :thread-index:content-language; bh=7TWTWBr8Kg7BNeE6jdQQgsPDUC21sqsHjngMePf+CS8=; b=LFNW2VuigmoQiv2An6u4zsOKruRoEQnmki4z+sfzRiyTJqFeK/TxA4AIQHlqKODV+i LpOUT5VFMVFiXO0MZoGPjL+fg0oQF9U3MrqFY3kghBYlI41/1676PSVdp1yB1Jxa6sTV gmCBVW4K/6H3E7xqQgqH3XI3lbI2tjF9p0GJLVo3XtLE1NjjcP6cxT9Kx5ymXwV75KVK aWlQpy6Be4dSny28o/Xm8G2E4IjDOHKAyIAo6YXyMwu/qI7qdTTBCeO8jtR/jp/fpjzb ZvOvMuqWQwvsxDBgLrcfSZTfD4yohKAmxNXUwZuunRR6+IAf5JynMaUe1vuVd4B0dQeC vTKg== X-Received: by 10.14.47.73 with SMTP id s49mr593355eeb.71.1371122955498; Thu, 13 Jun 2013 04:29:15 -0700 (PDT) Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id bk1sm43177654eeb.5.2013.06.13.04.29.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Jun 2013 04:29:14 -0700 (PDT) From: "Roni Even" To: Date: Thu, 13 Jun 2013 14:27:52 +0300 Message-ID: <008101ce6829$0c9719a0$25c54ce0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CE6842.31E4C6D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5oKKMdR9KjjCgURBGQPYo84ulKvA== Content-Language: en-us Subject: [payload] RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:29:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01CE6842.31E4C6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I skimmed through the document and one question I have is about the optional SDP parameters. Since all parameters are optional what is the meaning of (profile? Level?) m=video 49170 RTP/AVP 98 a=rtpmap:98 H265/90000 Roni Even ------=_NextPart_000_0082_01CE6842.31E4C6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I skimmed = through the document and one question I have is about the optional SDP = parameters.

Since all parameters are = optional what is the meaning of (profile? Level?)

 

        m=3Dvideo 49170 RTP/AVP = 98

         a=3Drtpmap:98 = H265/90000

 

Roni = Even

------=_NextPart_000_0082_01CE6842.31E4C6D0-- From harald@alvestrand.no Thu Jun 13 05:46:35 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8421F9A7C for ; Thu, 13 Jun 2013 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1Q4v16Owp9F for ; Thu, 13 Jun 2013 05:46:30 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6321F9A6A for ; Thu, 13 Jun 2013 05:46:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C723D39E172; Thu, 13 Jun 2013 14:46:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCR8Vr2ADzbn; Thu, 13 Jun 2013 14:45:59 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B309639E058; Thu, 13 Jun 2013 14:45:58 +0200 (CEST) Message-ID: <51B9BF06.80609@alvestrand.no> Date: Thu, 13 Jun 2013 14:45:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Barnes References: <062e01ce2f03$33956840$9ac038c0$@gmail.com> <065f01ce2f22$26c76b80$74564280$@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080508010602080103020704" Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, payload@ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:46:35 -0000 This is a multi-part message in MIME format. --------------080508010602080103020704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/28/2013 08:34 PM, Richard Barnes wrote: > Dear Authors, > > Any update on these issues? Working on it, but as you know from other discussions, there isn't exactly a lack of things to work on at the moment - it dropped off my queue, and I'm picking it up again now. We'll get back to you Real Soon Now. > > Thanks, > --Richard > > > On Mon, Apr 1, 2013 at 5:44 PM, Roni Even > wrote: > > Hi Richard, > > These fields are not part of the RTP header but part of the iSAC > payload header and I agree that it will be better to clarify them. > > Roni > > *From:*Richard Barnes [mailto:rlb@ipv.sx ] > *Sent:* 01 April, 2013 9:47 PM > *To:* Roni Even > *Cc:* payload@ietf.org ; > draft-ietf-avt-rtp-isac@tools.ietf.org > > *Subject:* Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 > > Sure. I didn't mean to imply that we need a reference to the > codec, in fact the opposite. I was looking for this document to > tell me how to parse out the fields I would feed into the black > box of the codec. They describe the fields, but it seems to me > that they need more detail in order for people to know how to > parse them out of the payload. > > --Richard > > On Mon, Apr 1, 2013 at 2:03 PM, Roni Even > wrote: > > Hi Richard, > > As a general comment, for RTP payload specifications we do not > require a normative reference to the codec. We only require enough > information that will allow an RTP receiver to parse the > information and move it to the decoder that can be a black box. > This allows us to publish RTP payload specification also for > codecs whose specifications are not publically available. > > Still in this case more information can be supplied. > > As for the comments the authors should address them > > Roni Even > > *From:*payload-bounces@ietf.org > [mailto:payload-bounces@ietf.org > ] *On Behalf Of *Richard Barnes > *Sent:* 01 April, 2013 8:06 PM > *To:* payload@ietf.org > *Cc:* draft-ietf-avt-rtp-isac@tools.ietf.org > > *Subject:* [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 > > Overall, this document looks in pretty good shape. A couple of > comments I would like to get resolved before IETF LC: > > Section 3.1., "Consult source code for details" > > If the details are only specified in the source code, then the > source needs to be a normative reference. And I would prefer to > avoid that :) Better to specify here how the BEI and FL fields > are encoded. Alternatively, if the codec really does expect a > combined BEI/FL field, you could specify such a field here, opaque > to the RTP layer. However, you would at least need to say how the > recipient knows where this field starts and stops. > > Section 3.2., "The length of the encoded data is variable and > depends on the signal characteristics and the target bit rate." > > However, there's nothing in this section that tells a recipient > how to determine what this length is. > > Section 3.3., "... verifying the CRC checksum ..." > > Please specify which CRC function is to be applied, and how the > CRC value field is formatted. > > Section 3.3., "If this value would exceed 255 at encoding..." > > It sounds like the LEN field is a single octet unsigned integer. > Please state that explicitly. > > Section 9.2. Informative References. > > Better path to source code would be > "webrtc/modules/audio_coding/codecs/isac" > > Thanks, > > --Richard > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --------------080508010602080103020704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/28/2013 08:34 PM, Richard Barnes wrote:
Dear Authors,

Any update on these issues?

Working on it, but as you know from other discussions, there isn't exactly a lack of things to work on at the moment - it dropped off my queue, and I'm picking it up again now.

We'll get back to you Real Soon Now.


Thanks,
--Richard


On Mon, Apr 1, 2013 at 5:44 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Richard,

These fields are not part of the RTP header but part of the iSAC payload header and I agree that it will be better to clarify them.

Roni

 

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: 01 April, 2013 9:47 PM
To: Roni Even
Cc: payload@ietf.org; draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

 

Sure. I didn't mean to imply that we need a reference to the codec, in fact the opposite.  I was looking for this document to tell me how to parse out the fields I would feed into the black box of the codec.  They describe the fields, but it seems to me that they need more detail in order for people to know how to parse them out of the payload.

 

--Richard

 

On Mon, Apr 1, 2013 at 2:03 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Richard,

As a general comment, for RTP payload specifications we do not require a normative reference to the codec. We only require enough information that will allow an RTP receiver to parse the information and move it to the decoder that can be a black box. This allows us to publish RTP payload specification also for codecs whose specifications are not publically available.

Still in this case more information can be supplied.

 

As for the comments the authors should address them

 

Roni Even

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: payload@ietf.org
Cc: draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

 

Overall, this document looks in pretty good shape.  A couple of comments I would like to get resolved before IETF LC:

 

Section 3.1., "Consult source code for details"

If the details are only specified in the source code, then the source needs to be a normative reference.  And I would prefer to avoid that  :)  Better to specify here how the BEI and FL fields are encoded.   Alternatively, if the codec really does expect a combined BEI/FL field, you could specify such a field here, opaque to the RTP layer.  However, you would at least need to say how the recipient knows where this field starts and stops.

 

Section 3.2., "The length of the encoded data is variable and depends on the signal characteristics and the target bit rate."

However, there's nothing in this section that tells a recipient how to determine what this length is.  

 

Section 3.3., "... verifying the CRC checksum ..."

Please specify which CRC function is to be applied, and how the CRC value field is formatted.

 

Section 3.3., "If this value would exceed 255 at encoding..."

It sounds like the LEN field is a single octet unsigned integer.  Please state that explicitly. 

 

Section 9.2. Informative References.

Better path to source code would be "webrtc/modules/audio_coding/codecs/isac"

 

Thanks,

--Richard

 




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

--------------080508010602080103020704-- From yekuiw@qti.qualcomm.com Thu Jun 13 09:10:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2521F9A10 for ; Thu, 13 Jun 2013 09:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uwIg3TDPS+1 for ; Thu, 13 Jun 2013 09:10:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id F246221F874E for ; Thu, 13 Jun 2013 09:10:00 -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=1371139800; x=1402675800; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=c6a7ChJJS3BMsoktYf+osU/zmd6/R93fuFO4cw7bPIk=; b=p78vBsZi1epzn/ERDDhxT2AkERyOOmdowHQZ3oZyPBZQzO1WwiYLxDQr Pc7VqWmUMWJ2VbBHNN+xYW8a4RLKpQLEJbyHXHQ/ApCj2a5RstpgggC44 g+Jr53VgYtKpF/5owtgM0PGUMUs/Xr05tOc3dGwsjV+U7LUa7g443Y96Y A=; X-IronPort-AV: E=Sophos;i="4.87,859,1363158000"; d="scan'208,217";a="56243684" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 13 Jun 2013 09:10:00 -0700 X-IronPort-AV: E=Sophos;i="4.87,859,1363158000"; d="scan'208,217";a="499524123" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Jun 2013 09:10:00 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.230]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 09:09:59 -0700 From: "Wang, Ye-Kui" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] RTP Payload Format for High Efficiency Video Coding (H.265) Thread-Index: Ac5oKKMdR9KjjCgURBGQPYo84ulKvAAJwyKw Date: Thu, 13 Jun 2013 16:09:59 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83383FABD1@nasanexd02f.na.qualcomm.com> References: <008101ce6829$0c9719a0$25c54ce0$@gmail.com> In-Reply-To: <008101ce6829$0c9719a0$25c54ce0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83383FABD1nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:10:12 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83383FABD1nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for calling for WG adoption and reviewing of the draft. Some of the = media type parameters, including profile and level, have default values spe= cified if the parameters are not present. The default profile is the Main p= rofile, and the default level is level 1 (ah, thus the default value of the= level-id should be 30 not 1 - this should be corrected in the draft - I wi= ll correct this in the next version). BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even Sent: Thursday, June 13, 2013 4:28 AM To: payload@ietf.org Subject: [payload] RTP Payload Format for High Efficiency Video Coding (H.2= 65) Hi, I skimmed through the document and one question I have is about the optiona= l SDP parameters. Since all parameters are optional what is the meaning of (profile? Level?) m=3Dvideo 49170 RTP/AVP 98 a=3Drtpmap:98 H265/90000 Roni Even --_000_8BA7D4CEACFFE04BA2D902BF11719A83383FABD1nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thanks for calling for= WG adoption and reviewing of the draft. Some of the media type parameters,= including profile and level, have default values specified if the paramete= rs are not present. The default profile is the Main profile, and the default level is level 1 (ah, thus the defaul= t value of the level-id should be 30 not 1 – this should be corrected= in the draft – I will correct this in the next version).<= /span>

 

BR, YK

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Roni Even
Sent: Thursday, June 13, 2013 4:28 AM
To: payload@ietf.org
Subject: [payload] RTP Payload Format for High Efficiency Video Codi= ng (H.265)

 

Hi,

I skimmed through the document = and one question I have is about the optional SDP parameters.

Since all parameters are option= al what is the meaning of (profile? Level?)

 

        = m=3Dvideo 49170 RTP/AVP 98

       &= nbsp; a=3Drtpmap:98 H265/90000

 

Roni Even

--_000_8BA7D4CEACFFE04BA2D902BF11719A83383FABD1nasanexd02fnaqu_-- From aeh@db.org Sat Jun 15 01:06:00 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B521F9AFE for ; Sat, 15 Jun 2013 01:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW1fXSKwzecl for ; Sat, 15 Jun 2013 01:05:56 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1330021F9B08 for ; Sat, 15 Jun 2013 01:05:55 -0700 (PDT) Received: from [46.15.129.207] (helo=alfred-heggestads-macbook-pro.local) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1UnlUe-0005yc-37; Sat, 15 Jun 2013 10:05:52 +0200 Message-ID: <51BC205F.8010900@db.org> Date: Sat, 15 Jun 2013 10:05:51 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> In-Reply-To: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 08:06:01 -0000 On 6/12/13 5:40 PM, Roni Even wrote: > Hi, > > The ITU-T approved a new video codec High Efficiency Video Coding also known as H.265. > > There is an individual draft titled RTP Payload Format for High Efficiency Video Coding draft-schierl-payload-rtp-h265-03 > > The WG chairs would like to ask for a new milestone for December 2013 RTP Payload Format for High Efficiency Video Codingand accept this document as the initial document to address the milestone. > > The WG chairs are looking for WG feedback > > Please respond by Monday July 1^st 2013 with your positions. > I support adopting this draft. /alfred From fluffy@cisco.com Tue Jun 18 13:56:06 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DED321F91BF for ; Tue, 18 Jun 2013 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.079 X-Spam-Level: X-Spam-Status: No, score=-110.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmhYxnDU6JpQ for ; Tue, 18 Jun 2013 13:56:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9421F942D for ; Tue, 18 Jun 2013 13:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=210; q=dns/txt; s=iport; t=1371588955; x=1372798555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IWnWXrHwQFR7errkg+rrd/aWhpruWVn8FjJ5ki2gOZE=; b=BbJZLBGbller9PdJqyloy1fk068fo/7GEuBSU3oo0r53WXDj8+Mhs7C0 exj81dcZCQjs7LiYc3GUBI7tQ1K5gtzPMnJ9Jf/aX2pWZYZO+iHPGT5n5 ONv4IxtxmWbN/mm/Snc08cdjk0qSludJVsd7hGODWT9bKGHXrIP1lJvtv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAMPIwFGtJXHA/2dsb2JhbABagwl6gjq8VoEEFnSCJAEBBB0dPxACAQgiFBAyJQIEDgUIiAa7B48KMQeDAGEDqQSBWIE3gig X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224532728" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2013 20:55:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IKttoF018518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 20:55:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.215]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:55:54 -0500 From: "Cullen Jennings (fluffy)" To: "Alfred E. Heggestad" Thread-Topic: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) Thread-Index: AQHObGY5IojO8VL2v0ac0QQxWKZACQ== Date: Tue, 18 Jun 2013 20:55:55 +0000 Message-ID: References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> <51BC205F.8010900@db.org> In-Reply-To: <51BC205F.8010900@db.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AA8ACC482CAD14DB4C99637D86BDB5C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:56:06 -0000 On Jun 15, 2013, at 2:05 AM, Alfred E. Heggestad wrote: >>=20 >> Please respond by Monday July 1^st 2013 with your positions. >>=20 >=20 > I support adopting this draft. >=20 +1=20 From prvs=4882b5f673=magnus.westerlund@ericsson.com Wed Jun 19 05:35:43 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4721F9C24 for ; Wed, 19 Jun 2013 05:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.097 X-Spam-Level: X-Spam-Status: No, score=-106.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJTrAxPAV5FF for ; Wed, 19 Jun 2013 05:35:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C355221F9C25 for ; Wed, 19 Jun 2013 05:35:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-66-51c1a595f84a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 79.8C.15700.595A1C15; Wed, 19 Jun 2013 14:35:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 19 Jun 2013 14:35:33 +0200 Message-ID: <51C1A59F.7000407@ericsson.com> Date: Wed, 19 Jun 2013 14:35:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> In-Reply-To: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvre7UpQcDDfb+l7G4dPEsk8XfdmYH Jo+ds+6yeyxZ8pMpgCmK2yYpsaQsODM9T98ugTvj0vQpjAVneSpaN0k3MH7k7GLk5JAQMJG4 83c3M4QtJnHh3nq2LkYuDiGBU4wS3+7NZYVwljNKTDixBqiKg4NXQFvi4j02EJNFQFVi12IR kF42AQuJmz8a2UBsUYFgiSPbN7OA2LwCghInZz4Bs0UE1CRer/0MVsMsICLROWk+O4gtLJAp ceHRClYQW0jAXGLu5wNg9ZxAMxf83scEcZukxJYX7ewQvXoSU662MELY8hLNW2czQ/RqSzQ0 dbBOYBSahWT1LCQts5C0LGBkXsXInpuYmZNebriJERimB7f81t3BeOqcyCFGaQ4WJXHeD6d2 BQoJpCeWpGanphakFsUXleakFh9iZOLgBBFcUg2MTo3BTF96WORPB4q+DF6iF7FD71218Lrk v5ujfldrzLWJbjK/kcS/K9d45q0dKW/+6ti6RkXLvA9qmFR21H3CkhjL8Pg0P1+J7buSF3Nk mJ+uyJea1RuifLR10RkWnRdntz1+sDnV8vo13qlOCpVz1C8GmW1+eSd+q8PrO8ttrW1Kv+fd c1ZWYinOSDTUYi4qTgQAizN9BiYCAAA= Cc: payload@ietf.org Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:35:43 -0000 Hi, I support taking this draft as a starting point for the WG specification. I intended to be active in the development work and provide proposals and reviews. Cheers Magnus Westerlund On 2013-06-12 17:40, Roni Even wrote: > Hi, > > > > The ITU-T approved a new video codec High Efficiency Video Coding also > known as H.265. > > > > There is an individual draft titled RTP Payload Format for High > Efficiency Video Coding draft-schierl-payload-rtp-h265-03 > > > > > The WG chairs would like to ask for a new milestone for December 2013 > RTP Payload Format for High Efficiency Video Codingand accept this > document as the initial document to address the milestone. > > The WG chairs are looking for WG feedback > > > > Please respond by Monday July 1^st 2013 with your positions. > > > > Roni Even > > PAYLOAD WG co-chair > > > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kevin.gross@avanw.com Wed Jun 19 17:09:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F036F21F9EF3 for ; Wed, 19 Jun 2013 17:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqTpxYAVxSRs for ; Wed, 19 Jun 2013 17:09:44 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 1149721F9EEA for ; Wed, 19 Jun 2013 17:09:43 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta10.emeryville.ca.mail.comcast.net with comcast id qQ001l0011GXsucAAQ9jcX; Thu, 20 Jun 2013 00:09:43 +0000 Received: from mail-ob0-x22a.google.com ([IPv6:2607:f8b0:4003:c01::22a]) by omta07.emeryville.ca.mail.comcast.net with comcast id qQ9i1l00V10tQmD8UQ9ipB; Thu, 20 Jun 2013 00:09:43 +0000 Received: by mail-ob0-f170.google.com with SMTP id ef5so6654946obb.15 for ; Wed, 19 Jun 2013 17:09:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iu7BeyQsQZcGAmN/TvBxh9lSK2ydat8iL4vd0dAYZfg=; b=FdIQ26nqsSCmD7HQW5rJ5RFZDmaoSlCzfmYiEP2NFDEPzoo+BOafWRsfgJGtN06waK vYAGQe2eBdWi89LZPdmEIggAGk6lqCfospVLUf8dPZUzTk0x41/teqm8YJBgRoOUA/hi PMtpSBkVTQJp9ay2Y7AfbsNQKGoWWSV4JWO6toGSnUyYg3ePBn4vIP8weoOKEZLcS8Te LuermDSC9Z35B+RJT5XI9M67i0bItelUAvpYrOBbD8R27228S8wSbRpg+h7VJHme0uu1 SSQYyzPVgmk1B0Ul2YskCaMZbYcT854PYJ7s5VxpmudbHCTEZ0xVf47MKJ85fMLj3uDE ncig== MIME-Version: 1.0 X-Received: by 10.60.142.7 with SMTP id rs7mr3391742oeb.106.1371686982330; Wed, 19 Jun 2013 17:09:42 -0700 (PDT) Received: by 10.182.34.202 with HTTP; Wed, 19 Jun 2013 17:09:42 -0700 (PDT) In-Reply-To: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> Date: Wed, 19 Jun 2013 18:09:42 -0600 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=047d7b3a9832533d5e04df8ac3b1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371686983; bh=iu7BeyQsQZcGAmN/TvBxh9lSK2ydat8iL4vd0dAYZfg=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=COLO7t4jhLjGHjWQPVdlbxqg8oxejzAWtWQ9Dm9UkQIBNGDrtGO8qjBHVCcaoCVxw yp8tWhWchiap+jXSL+gvstijM0R2rLUaBQrEFutLp0QCQjwTKMXlxiR7hFMT5h+agP mpU4pJtV47ZRnqo0Rwkd0E+Yap5B/b7QXdQvEur6PJ7bBD7YaIBWeHR/YUCtB8hjuZ ZuTaRCDQvPo6pxgoJNpo0ga8+472r4R0vzXYNLgMibUMwdTZZ15Uj9jCbaWv043y9W I4RtZUhn8/mkLMDo2tl04E3uxV342bU4j/NUWrz2LCkTKMDgj9z17JyRlfFXmaRMRW p81S+kw7hPPkQ== Cc: payload@ietf.org Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:09:49 -0000 --047d7b3a9832533d5e04df8ac3b1 Content-Type: text/plain; charset=ISO-8859-1 I support adopting this draft Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Jun 12, 2013 at 9:40 AM, Roni Even wrote: > Hi,**** > > ** ** > > The ITU-T approved a new video codec High Efficiency Video Coding also > known as H.265.**** > > ** ** > > There is an individual draft titled RTP Payload Format for High > Efficiency Video Coding draft-schierl-payload-rtp-h265-03 > **** > > ** ** > > The WG chairs would like to ask for a new milestone for December 2013 RTP > Payload Format for High Efficiency Video Coding and accept this document > as the initial document to address the milestone.**** > > The WG chairs are looking for WG feedback**** > > ** ** > > Please respond by Monday July 1st 2013 with your positions. **** > > ** ** > > Roni Even**** > > PAYLOAD WG co-chair**** > > ** ** > > ** ** > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > --047d7b3a9832533d5e04df8ac3b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support adopting this draft

Kevin Gross
+1-303-447-0517
Me= dia Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Wed, Jun 12, 2013 at 9:40 AM, Roni Ev= en <ron.even.tlv@gmail.com> wrote:

Hi,=

=A0

The ITU-T approved a new video codec High Efficiency Video Coding also known as = =A0H.265.

=A0

There is an ind= ividual draft =A0titled RTP Payload Format for High Efficiency Video Coding draft-schierl-payload-rtp-= h265-03

=A0

The WG chairs w= ould like to ask for a new milestone for December 2013 RTP Payload Format f= or High Efficiency Video Coding and accept this document as the initial document to address the mi= lestone.

The WG chairs are looking for WG feedback

=A0

Please respond by Monday July 1st=A0 2013 with y= our positions.

=A0

Roni Even

PAYLOAD W= G co-chair

=A0=

=A0


_______________= ________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload


--047d7b3a9832533d5e04df8ac3b1-- From rickard.sjoberg@ericsson.com Thu Jun 20 09:16:53 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF621F9702 for ; Thu, 20 Jun 2013 09:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpWFMBVxRzTQ for ; Thu, 20 Jun 2013 09:16:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89721F9798 for ; Thu, 20 Jun 2013 09:16:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-da-51c32aee4891 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 79.29.09795.EEA23C15; Thu, 20 Jun 2013 18:16:47 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 18:16:46 +0200 From: =?iso-8859-1?Q?Rickard_Sj=F6berg?= To: "Wang, Ye-Kui" , "payload@ietf.org" Thread-Topic: Submission of new versions of H.265/HEVC payload format Thread-Index: Ac5mxRy1XpIRDmQdTgeDR7RG12PPdAG+YyWAAARO1CA= Date: Thu, 20 Jun 2013 16:16:46 +0000 Message-ID: <4BC545FCE47FC14EAABD27484D62A9D01C1B65B3@ESESSMB103.ericsson.se> References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvre57rcOBBk0XuC0uXTzLZPFkzTFm ByaPJUt+MnksmvqMMYApissmJTUnsyy1SN8ugStj5pH3zAVnlCvunF7P3MD4WaaLkZNDQsBE 4tHVU2wQtpjEhXvrwWwhgcOMEiu/6XUxcgHZSxglzp14xA6SYBNwlzj5poMJxBYRCJX48nEq WFxYwEXix+7trBBxV4mzk99C1VhJHF+zE8xmEVCVWDOjmwXE5hXwlVjUfRqongNoQbDEj4+x IGFGAVmJL42rmUFsZgFxiVtP5jNB3CYgsWTPeWYIW1Ti5eN/rBC2okT70wZGiHo9iRtTp7BB 2NoSyxa+ZoZYJShxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS8338QIDPiDW34b 7GDcdF/sEKM0B4uSOO+nU7sChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAysu9qPZXjkLVh 4x32E/K204QijD+pbp517Cfj4wiz1h8/vao/aohf0OmUE9b12Kp5zIFn1+tJtVa3/+T8f3C4 OX+jwPFT61Ml5VrjCne3FraWzJ934MaqR1OefzBb/pppZdLcv+orl7pl3LmuFSU66di3X01O M8Pbw76rf2D13+voWeaqGCquxFKckWioxVxUnAgAn/j4jkYCAAA= Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:16:54 -0000 Dear all, I have taken a first look at draft-schierl-payload-rtp-h265-03 and have som= e questions/comments. My first question is what extensions of HEVC that draft-schierl-payload-rtp= -h265 is intended to cover? The draft mentions "future scalable or 3D v= ideo coding extensions of this specification", what extensions do you = refer to? Is the intent to cover the all HEVC extensions in a single payloa= d specification? Another question for my understanding is why "Receivers MUST pass picture t= iming SEI messages and decoding unit information SEI messages to the decode= r"? In "5. Packetization Rules" in Section 4.7, there are 5 rules. The fourth o= ne does not seem to be a rule since there is no "MUST" or "SHOULD" in the c= orresponding text. Further, the fifth one discourages using FUs, what are t= he reasons behind that?=20 In 8.2 and 8.3, the feedback messages are using PicOrderCntVal. Isn't there= a possiblity that the MSB of PicOrderCntVal may differ between the encoder= and decoder? The use of spatial-segmentation-idc may need some updates to be useful, let= me come back to that later on. I have also a number of spelling suggestions for your considerations: Section 1.1: Replace "community" by "communities" Section 1.1.1: Replace "In addition, interpolation filter" by "In addition, the interpolat= ion filter" Replace "skipping the transform coding" by "skipping the transform" (transf= orm_skip_flag of HEVC skips the transform, not the coding) Section 1.1.2: Replace: "2) An indication of whether there is any parameter set within the current = coded video sequence that updates another parameter set of the same type pr= eceding in decoding order." by: "2) An indication of whether there is no parameter set update in the coded = video sequence." since that is what no_parameter_set_update_flag in HEVC indicates. Section 4.7: Replace "Type" in Figure 10, and "Type: 6 bits" by "FU Type" and "FU Type:= 6 bits" to avoid confusion with the Type in the payload header. Section 6: Replace "recovery" by "recover" Section 7.1: Replace "level-id" by "level-idc" Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]" Section 8: Replace "two payload-specific feedback messages" by "a payload-specific= feedback message", since only SPLI is "Assigned in this memo". Also, consider removing references to H.264 in the last paragraph of Sectio= n 8 since the memo is about HEVC. Section 8.1: Seems to me that "There MUST be exactly one RPSI contained in the FCI field= " should be "There MUST be exactly one SPLI contained in the FCI field" Best Regards, Rickard Sj=F6berg -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Wang, Ye-Kui Sent: den 11 juni 2013 19:00 To: payload@ietf.org Subject: [payload] Submission of new versions of H.265/HEVC payload format Dear All, We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows: Version 02: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-02.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-02 Version 03: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-03.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-03 Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author. Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft.=20 BR, YK (on behalf of the authors) _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From internet-drafts@ietf.org Fri Jun 21 01:30:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD55D11E816B; Fri, 21 Jun 2013 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nStN6EzJ28cL; Fri, 21 Jun 2013 01:30:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6671211E816F; Fri, 21 Jun 2013 01:30:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130621083009.11760.71651.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 01:30:09 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-g7110-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:30:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for G.711.0 Author(s) : Michael A. Ramalho Paul E. Jones Noboru Harada Muthu Arul Mozhi Perumal Lei Miao Filename : draft-ietf-payload-g7110-00.txt Pages : 27 Date : 2013-06-20 Abstract: This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-g7110 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-g7110-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mans.nilsson@sverigesradio.se Wed Jun 19 23:07:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D415D11E8100 for ; Wed, 19 Jun 2013 23:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN7AXS6FHH+J for ; Wed, 19 Jun 2013 23:07:55 -0700 (PDT) Received: from mail-3.sr.se (mail-3.sr.se [192.165.8.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63CAF21F9C4D for ; Wed, 19 Jun 2013 23:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:from:to:cc:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:content-id: content-transfer-encoding:mime-version; bh=bWk3LfvC1XG/bzBdousn9p75J2P0Dq2gNKSvnC7XM5c=; b=hMXVyI2/qojfUcg4W+RRNF3qeLaDalQfw6r+AXSYLUuCsvXXC4esquMcH5HY+SEHiP0JnmRDOv3TQ CdGD7xn236HA/l2fvtEY15Mdj6vY4d7cGLBjbhFiJUEdEZ7o9nvG5kFZRD68Ldp9q/viNOVS91kZq8 MJafvtBnnsrEb9TU= X-Halon-ID: a8e38dbb-d96f-11e2-a4c0-000c2976599e Received: from STOEXCASHT02.sr.se (unknown [134.25.11.15]) by mail-3.sr.se (Halon Mail Gateway) with ESMTPS; Thu, 20 Jun 2013 08:07:17 +0200 (CEST) Received: from STOEXMBX02.sr.se ([fe80::c92a:3554:4d98:d95f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.03.0123.003; Thu, 20 Jun 2013 08:07:34 +0200 From: =?iso-8859-1?Q?M=E5ns_Nilsson?= To: Roni Even Thread-Topic: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) Thread-Index: Ac5ngwrun8+6pBZ+RHS6vfa9Cec8SQF6KTwA Date: Thu, 20 Jun 2013 06:07:34 +0000 Message-ID: <70389E19-F536-4646-8530-1EED5304C553@sr.se> References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> In-Reply-To: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <47F83504602654408F30FC080D34F023@sverigesradio.se> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 21 Jun 2013 08:12:59 -0700 Cc: "" Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 06:07:59 -0000 12 jun 2013 kl. 17:40 skrev Roni Even : > Hi, > =20 > The ITU-T approved a new video codec High Efficiency Video Coding also kn= own as H.265. > =20 > There is an individual draft titled RTP Payload Format for High Efficien= cy Video Coding draft-schierl-payload-rtp-h265-03 > =20 > The WG chairs would like to ask for a new milestone for December 2013 RTP= Payload Format for High Efficiency Video Coding and accept this document a= s the initial document to address the milestone. > The WG chairs are looking for WG feedback I have skimmed the draft and being mostly interested in audio coding also r= ead up on H.265. Having a RTP profile for H.265 is crucial and I support th= e draft being adopted.=20 Glad midsommar! (Happy midsummers eve!)=20 --=20 M=E5ns Nilsson Sveriges Radio +46 8 784 2326 +46 705989668 Tv=E5 saker verkar vara oundvikliga i milj=F6er med d=E5ligt chefsskap:=20 Det f=F6rsta =E4r horribla beslut, det andra att det inte g=E5r att f=F6ra en diskussion om f=F6rh=E5llandena. Mats Svegfors 2010 From yekuiw@qti.qualcomm.com Sun Jun 23 16:00:22 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B8E21F9D49 for ; Sun, 23 Jun 2013 16:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3m6SW5wM6-h for ; Sun, 23 Jun 2013 16:00:18 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7985521F9E39 for ; Sun, 23 Jun 2013 16:00:18 -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=1372028418; x=1403564418; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VyVsOve9rliXtdgb9u77orYse2124C+omK1MtuTlIUE=; b=nrzPdnhvcYcYq2OZBBr5HGdaNOodO1p4JWZiPPHwlQCk3J5gWjLOWI8S bzzoBWZ2eKPcw82DhREgeHvUtKHqHrWpNFOQvy43ezO1ywW1Gj2xq8M1W PEjrnu4/dwKxnM2Elm442Rg2ebiARUqA275s4qkGXsM8TjysyCBKe9zbp Y=; X-IronPort-AV: E=Sophos;i="4.87,924,1363158000"; d="scan'208";a="45918870" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 23 Jun 2013 16:00:18 -0700 Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jun 2013 16:00:17 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.02.0318.004; Sun, 23 Jun 2013 16:00:17 -0700 From: "Wang, Ye-Kui" To: =?iso-8859-1?Q?Rickard_Sj=F6berg?= , "payload@ietf.org" Thread-Topic: Submission of new versions of H.265/HEVC payload format Thread-Index: Ac5mxRy1XpIRDmQdTgeDR7RG12PPdAG+YyWAAARO1CAAmc/S0A== Date: Sun, 23 Jun 2013 23:00:16 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338431C78@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1B65B3@ESESSMB103.ericsson.se> In-Reply-To: <4BC545FCE47FC14EAABD27484D62A9D01C1B65B3@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 23:00:22 -0000 Hi Rickard, Thanks for the careful review and the comments. Please see inline below. BR, YK > -----Original Message----- > From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com] > Sent: Thursday, June 20, 2013 9:17 AM > To: Wang, Ye-Kui; payload@ietf.org > Subject: RE: Submission of new versions of H.265/HEVC payload format >=20 > Dear all, >=20 > I have taken a first look at draft-schierl-payload-rtp-h265-03 and have s= ome > questions/comments. >=20 > My first question is what extensions of HEVC that draft-schierl-payload-r= tp- > h265 is intended to cover? The draft mentions "future scalable or 3D = video > coding extensions of this specification", what extensions do you refe= r to? > Is the intent to cover the all HEVC extensions in a single payload specif= ication? >=20 [YK] That is in the semantics of LayerId (nuh_layer_id), where "this specif= ication" should be replaced with "[HEVC]". It is sort of copy-and-paste err= or. Thanks for the good catching. No, there is no intention to cover HEVC e= xtensions in this payload specification, though we intentionally to have th= e depacketization process and the use with feedback messages to work for HE= VC scalability and 3DV extensions. > Another question for my understanding is why "Receivers MUST pass picture > timing SEI messages and decoding unit information SEI messages to the > decoder"? [YK] Generally, RTP receivers should/must pass all NAL units specified by t= he video coding spec to the video decoders. This is emphasized here for the= two timing related SEI messages after it is said that picture output timin= g in RTP timestamps should be used instead (to avoid giving a wrong impress= ion to readers that the SEI messages should be ignored). If an RTP receiver= discards the SEI messages, then HRD conformance checking for the bitstream= that was possible would be disabled, and also the information related to f= rame doubling or tripping would be lost. >=20 > In "5. Packetization Rules" in Section 4.7, there are 5 rules. The fourth= one > does not seem to be a rule since there is no "MUST" or "SHOULD" in the > corresponding text. [YK] I see your point, it is only a "MAY" rule. An alternative to put this = as a packetization rule is to put it as part of the semantics of NAL unit h= eader (1.1.4), but that sub-section belongs to an overview wherein normativ= e language (even "MAY") should not appear. One solution to this is to inser= t "Payload Header Usage" after 4.1 "RTP Header Usage" and include at least = this item there. I will do this in the next version unless there is a bette= r suggestion. > Further, the fifth one discourages using FUs, what are > the reasons behind that? [YK] The bullet item only discourages using FUs for live-encoding scenarios= , wherein dependent slice segments should be used instead. This was added a= fter a discussion (among the authors) on the need of whether to specify a p= ayload structure for mixed FU and aggregation packets and from that discuss= ion we concluded that encoding dependent slice segments at source coding le= vel already allows for the use cases and using of FUs for live-encoding doe= s not make sense. Please let us know if you think differently. > In 8.2 and 8.3, the feedback messages are using PicOrderCntVal. Isn't the= re a > possiblity that the MSB of PicOrderCntVal may differ between the encoder > and decoder? [YK] Good question. In theory this is indeed possible when random accessing= to a bitstream is performed. However, it would not happen in conversationa= l applications where the feedback messages may be used. Therefore, to me th= is would just work just fine. But please feel free to make other suggestion= s. >=20 > The use of spatial-segmentation-idc may need some updates to be useful, l= et > me come back to that later on. >=20 [YK] OK. Look forward to seeing your input herein. >=20 > I have also a number of spelling suggestions for your considerations: >=20 > Section 1.1: > Replace "community" by "communities" [YK] I guess both are OK. But anyway I just changed it per your suggestion = (for the next version). >=20 > Section 1.1.1: > Replace "In addition, interpolation filter" by "In addition, the interpol= ation > filter" [YK] Thanks - done. > Replace "skipping the transform coding" by "skipping the transform" > (transform_skip_flag of HEVC skips the transform, not the coding) >=20 [YK] Done. > Section 1.1.2: > Replace: > "2) An indication of whether there is any parameter set within the curren= t > coded video sequence that updates another parameter set of the same type > preceding in decoding order." > by: > "2) An indication of whether there is no parameter set update in the code= d > video sequence." > since that is what no_parameter_set_update_flag in HEVC indicates. >=20 [YK] Changed the wording to "An indication of whether there is no parameter= set within the current coded video sequence that updates another parameter= set of the same type preceding in decoding order." > Section 4.7: > Replace "Type" in Figure 10, and "Type: 6 bits" by "FU Type" and "FU Typ= e: 6 > bits" to avoid confusion with the Type in the payload header. >=20 [YK] Good point again. I will change the field name to be "FuType". > Section 6: > Replace "recovery" by "recover" [YK] Done. >=20 > Section 7.1: > Replace "level-id" by "level-idc" [YK] We are consistently using "id" for profile-id, level-id, max-recv-leve= l-id etc, similarly as in RFC 6184, instead of "idc". > Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]" [YK] Done. >=20 > Section 8: > Replace "two payload-specific feedback messages" by "a payload-specif= ic > feedback message", since only SPLI is "Assigned in this memo". > Also, consider removing references to H.264 in the last paragraph of Sect= ion > 8 since the memo is about HEVC. [YK] Good catch again. Changed. >=20 > Section 8.1: > Seems to me that "There MUST be exactly one RPSI contained in the FCI > field" should be "There MUST be exactly one SPLI contained in the FCI fie= ld" [YK] Another good catch. Changed. >=20 >=20 > Best Regards, > Rickard Sj=F6berg >=20 >=20 >=20 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Wang, Ye-Kui > Sent: den 11 juni 2013 19:00 > To: payload@ietf.org > Subject: [payload] Submission of new versions of H.265/HEVC payload > format >=20 > Dear All, >=20 > We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h2= 65, > for which the links are as follows: >=20 > Version 02: > URL: http://www.ietf.org/internet-drafts/draft-schierl-payloa= d-rtp- > h265-02.txt > Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h26= 5-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload= -rtp-h265- > 02 >=20 > Version 03: > URL: http://www.ietf.org/internet-drafts/draft-schierl-payloa= d-rtp- > h265-03.txt > Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h26= 5-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload= -rtp-h265- > 03 >=20 > Version 02 includes huge changes compared to the earlier submitted versio= n > 01. In a short summary, the authors have worked hard to try to make the > design complete, from both the payload structure and the signaling points= of > view. Compared to version 02, version 03 only contains a correction of th= e > email address of an author. >=20 > Due to that the industry is eager to deploy H.265/HEVC and other standard= s > bodies such as 3GPP rely on the payload format for support of H.265/HEVC = in > RTP based video services, we need to progress this draft relatively quick= ly. > Therefore, we would like to request quick reviews from interested parties > and also request for the WG status of this draft. >=20 > BR, YK (on behalf of the authors) > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From wuym2000cn@gmail.com Tue Jun 25 00:57:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E4F21F8CDD for ; Tue, 25 Jun 2013 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_71=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZbeKZ68UAMq for ; Tue, 25 Jun 2013 00:57:04 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3F21F8842 for ; Tue, 25 Jun 2013 00:57:04 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so26959339iec.22 for ; Tue, 25 Jun 2013 00:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j39bf101mk2lSNi7JQ3KPANzbD8jQRa8h2S5uUIE+QM=; b=q4hz+J5DtoaH2OAlRZ2WUDzS90bEu4cQPCxyiWPGCUOhzpMr5E9voZxp/WUz9Gqt1c Pz/w5pdXp7+zKk3dpp5DhKJjd9ZBHwWC5UUHj2mjvqRxaT63R+5HMNfSzLW1IlFIHjHS Cq1bLiuE9LbsNC7LUdZdRrzjGXxn/EkB70bCxzkFTgCtS5+T0HSPu7tdB+ETUw4AyNAR joZ2QtyR9RZAXYxVwBRf9YSqVLv0Q0to75Kmy3Y5BMM0vKT3JE4FBLRd8SAvqcmFBOo4 cdBpv1SjkAX1ubBqAXF0Qmh8AFdZzEGsid4725VQeYrOdcFMJhnBKWMcvPBEt9bggZiF Lx/Q== MIME-Version: 1.0 X-Received: by 10.42.49.15 with SMTP id u15mr5348210icf.30.1372147023404; Tue, 25 Jun 2013 00:57:03 -0700 (PDT) Received: by 10.42.68.143 with HTTP; Tue, 25 Jun 2013 00:57:03 -0700 (PDT) Received: by 10.42.68.143 with HTTP; Tue, 25 Jun 2013 00:57:03 -0700 (PDT) Date: Tue, 25 Jun 2013 15:57:03 +0800 Message-ID: From: Woo Johnman To: payload@ietf.org Content-Type: multipart/alternative; boundary=90e6ba1efcb2e8eeba04dff5df07 Subject: [payload] H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:57:05 -0000 --90e6ba1efcb2e8eeba04dff5df07 Content-Type: text/plain; charset=ISO-8859-1 Hi, At paragraph 2 of page 40,it says"if no level-id is present,a value of 1 must be inferred." I think the value should be 30 since a factor 30 is applied to the real level. Regards, Woo --90e6ba1efcb2e8eeba04dff5df07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,
At paragraph 2 of page 40,it says"if no level-id is present,a value of= 1 must be inferred." I think the value=A0 should be 30 since a factor= 30 is applied to the real level.

Regards,
Woo

--90e6ba1efcb2e8eeba04dff5df07-- From yekuiw@qti.qualcomm.com Tue Jun 25 08:36:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55F11E80FB for ; Tue, 25 Jun 2013 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhe7xqThZBxs for ; Tue, 25 Jun 2013 08:36:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC8411E80EE for ; Tue, 25 Jun 2013 08:36:27 -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=1372174587; x=1403710587; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gcNKsQw5tOIXGu4ijhJ6OmVbjKw+5po7avHU6skdBbk=; b=h6kULR+Gwp+mOuhg32V1nGplvbnPt8XR/rZL1be7M+XX2qMv+7BaLUkN e9LMHXu+Jw1+2+AXHUavOEcPCv5aIGQxo62Wntcx5tNJqJ0v1fPQabyNQ swIB9Yd3ZCUxAi2n07a/WPtBe3gOIJPBr1Vpn9AS81EVE5087eljFhV9b I=; X-IronPort-AV: E=Sophos;i="4.87,938,1363158000"; d="scan'208,217";a="58886234" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 25 Jun 2013 08:36:26 -0700 X-IronPort-AV: E=Sophos;i="4.87,937,1363158000"; d="scan'208,217";a="558821446" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Jun 2013 08:36:26 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc15.na.qualcomm.com ([129.46.52.215]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 08:36:26 -0700 From: "Wang, Ye-Kui" To: Woo Johnman , "payload@ietf.org" Thread-Topic: [payload] H.265 payload Thread-Index: AQHOcXmcexfRY33NskyHANMSZCrebplGkFLA Date: Tue, 25 Jun 2013 15:36:25 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338449A00@nasanexd02f.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8338449A00nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] H.265 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:36:32 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8338449A00nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woo, You are right. This will be changed in the next version. See also my reply = to Roni on June 13. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Woo Johnman Sent: Tuesday, June 25, 2013 12:57 AM To: payload@ietf.org Subject: [payload] H.265 payload Hi, At paragraph 2 of page 40,it says"if no level-id is present,a value of 1 mu= st be inferred." I think the value should be 30 since a factor 30 is appli= ed to the real level. Regards, Woo --_000_8BA7D4CEACFFE04BA2D902BF11719A8338449A00nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Woo,=

 <= /p>

You are right. This will = be changed in the next version. See also my reply to Roni on June 13.<= /o:p>

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Woo Johnman
Sent: Tuesday, June 25, 2013 12:57 AM
To: payload@ietf.org
Subject: [payload] H.265 payload

 

Hi,
At paragraph 2 of page 40,it says"if no level-id is present,a value of= 1 must be inferred." I think the value  should be 30 since a fac= tor 30 is applied to the real level.

Regards,
Woo

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338449A00nasanexd02fnaqu_-- From sdeshpande@sharplabs.com Wed Jun 26 18:03:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794911E8184 for ; Wed, 26 Jun 2013 18:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41yECsupNOdJ for ; Wed, 26 Jun 2013 18:03:11 -0700 (PDT) Received: from mail4.sharplabs.com (mail4.sharplabs.com [216.65.151.214]) by ietfa.amsl.com (Postfix) with ESMTP id 912BF11E8164 for ; Wed, 26 Jun 2013 18:03:11 -0700 (PDT) X-ASG-Debug-ID: 1372294976-0208083a2424ec0001-U2jSCT Received: from WABCASP1.sharpamericas.com ([172.29.224.253]) by mail4.sharplabs.com with ESMTP id 2sfo7nOhGpBj5E1L; Wed, 26 Jun 2013 18:03:00 -0700 (PDT) X-Barracuda-Envelope-From: sdeshpande@sharplabs.com Received: from WABEXCHP1.sharpamericas.com ([fe80::f930:84ca:49e6:2cbd]) by Wabcasp1 ([172.29.224.2]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 18:02:57 -0700 From: "Deshpande, Sachin" To: "Wang, Ye-Kui" , "payload@ietf.org" Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format X-ASG-Orig-Subj: RE: [payload] Submission of new versions of H.265/HEVC payload format Thread-Index: AQHOcpSa4uQ5OSm2Uk+rJOohvFZKlg== Date: Thu, 27 Jun 2013 01:02:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.228.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.29.224.253] X-Barracuda-Start-Time: 1372294980 X-Barracuda-URL: http://mail4.enet.sharplabs.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sharplabs.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.14 X-Barracuda-Spam-Status: No, SCORE=0.14 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, CN_BODY_332, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.135069 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.12 CN_BODY_332 BODY: CN_BODY_332 Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 01:03:16 -0000 =0A= Dear All,=0A= I have done a first review of the draft-schierl-payload-rtp-h265-03.txt and= =0A= I support the draft to be adopted as the starting point of the WG item. =0A= Please find below my comments on the draft. =0A= Best regards,=0A= Sachin Deshpande=0A= =0A= -----=0A= =0A= Comments on RTP Payload Format for HEVC=0A= draft-schierl-payload-rtp-h265-03.txt=0A= =0A= Typos:=0A= T.1) Missing "as" in the following line on Pg. 14-15:=0A= Parallel processing is possible through parallel decoding of CTU rows, wher= e the start of=0A= the decoding of a row is delayed by two CTUs, so "as" to ensure that data= =0A= related to a CTU above and to the right of the subject CTU is =0A= available before the subject CTU is being decoded.=0A= =0A= T.2) Title for Figure 3:=0A= Current title: "The structure of the first aggregation unit in an AP"=0A= I believe it should be something like:=0A= "The structure of a single NAL unit packet"=0A= =0A= T.3) Text in Figure 8:=0A= "NALU 2 HRD" should be "NALU 2 HDR"=0A= =0A= T.4) Text in last paragraph in section 6:=0A= "remained" -> "remaining"=0A= =0A= =0A= Discussions:=0A= D.1) In section 4.5 Single NAL Unit Packets-=0A= "The payload header MUST be an exact copy of the NAL unit header of the con= tained NAL unit." =0A= My understanding is that The NAL Unit payload data that is shown in Fig. 3 = - contained in the single NAL unit packets=0A= does not include the NAL unit header.=0A= So a couple of clarification questions regarding this "MUST" requirement.= =0A= =0A= a. Does this mean that an entity can not change the payload header of a sin= gle NAL unit type compared to the original NAL unit header in the NAL unit?= =0A= e.g. to change the NAL unit type from say BLA_W_LP to BLA_N_LP if it decide= s to drop LPs? Other similar NAL unit type change examples are possible.=0A= I imagine supporting ability to allow a NAL unit type change such as above = may be desirable. =0A= Thus possibly changing the "MUST" requirement to "SHOULD" may make sense?= =0A= =0A= b. What is the way to check that the NAL unit header rule above is enforced= when an entity receives a single NAL unit packet.=0A= i.e. is there a conformance checking mechanism defined.=0A= =0A= D.2) My understanding is that a single NAL unit can be sent either inside a= single NAL unit packet=0A= or inside an aggregation packet (containing only one NAL unit). And that th= e bytes on the wire for these two cases will be different.=0A= Is there a use case envisioned that would benefit by allowing sending one N= AL unit (only) in these two different ways?=0A= If there is not then do we want to disallow single NAL unit (only) scenario= in an AP?=0A= =0A= Editorial Suggestions:=0A= E.1) At a number of places in text and figures (e.g. Fig. 3, 5, 6) DONL and= DOND fields are mentioned as "optional".=0A= e.g. section 4.5: "...an optional 16-bit DONL field (in network byte order)= ,...",=0A= section 4.6 "...consists of an optional 8-bit DOND field followed by..."=0A= I have a couple of questions and possible suggestions:=0A= -Is this use of the term "optional" with regards to DONL and DOND in draft-= schierl-payload-rtp-h265-03 to be interpreted as described in RFC 2119 ? = =0A= (I believe it should be interpreted that way based on the "2. Conventions" = section in draft-schierl-payload-rtp-h265-03)=0A= If so then RFC 2119 says on pg. 2:=0A= "... 5. MAY This word, or the adjective "OPTIONAL", mean that an item is = truly optional..."=0A= -Are the DOND and DONL "optional" as per RFC 2119 definition?=0A= I believe there are conditions where DONL and DOND MUST be present.=0A= e.g. section 4.5: "...If tx-mode is equal to "MST" or sprop-depack-buf-nalu= s is greater than 0, the DONL field MUST be present...",=0A= section 4.6: "...If tx-mode is equal to "MST" or sprop-depack-buf-nalus is = greater than 0, the DONL field MUST be present..."=0A= In this case is it correct to refer to DONL and DOND fields as "optional"?= =0A= -In case it is correct to refer to DONL and DOND fields as "optional" shoul= d the use of the word in text and Fig. 3, 5, 6 be using upper case "OPTIONA= L"?=0A= =0A= E.2) The term "header" is referred with different notations (e.g. XHdr, HDR= , Header) when referring to different header fields in figures and text e.g= .:=0A= Payload header is referred as: "PayloadHdr" (many Figures, text), =0A= NAL Unit header is referred as: "NALU X HDR" (Fig. 8 and text), =0A= Fragmentation Unit header is referred as: "FU Header" (figure 9 and text).= =0A= A consistent notation for referring to "header" fields may avoid confusion.= =0A= As currently it may appear to a casual reader that there is some reason to = use different labeling for these different header fields.=0A= =0A= E.3) It is mentioned:=0A= "Aggregation Packet (AP) : Contains one or more NAL units within one access= unit." (section 4.2)=0A= "An AP aggregates NAL units within one access unit." (section 4.6)=0A= But it seems there is no statement saying a "MUST" requirement on APs regar= ding all NAL units in it MUST belong to same access units.=0A= e.g. something like:=0A= An AP MUST contain NAL units which belong to the same access unit.=0A= =0A= E.4) Perhaps the current "Fragmentation Units" (section 4.7) could be terme= d "Fragmentation Unit Packets" or "Fragmentation Packets".=0A= This will then be similar to how aggregation "packets" consist of aggregati= on "units".=0A= =0A= -----=0A= =0A= =0A= =0A= =0A= =0A= -----Original Message-----=0A= From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Wang, Ye-Kui=0A= Sent: den 11 juni 2013 19:00=0A= To: payload@ietf.org=0A= Subject: [payload] Submission of new versions of H.265/HEVC payload format= =0A= =0A= Dear All,=0A= =0A= We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows:=0A= =0A= Version 02:=0A= URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-02.txt=0A= Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 02=0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-02=0A= =0A= Version 03:=0A= URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-03.txt=0A= Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 03=0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-03=0A= =0A= Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author.=0A= =0A= Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft.=0A= =0A= BR, YK (on behalf of the authors)=0A= _______________________________________________=0A= payload mailing list=0A= payload@ietf.org=0A= https://www.ietf.org/mailman/listinfo/payload=0A= =0A= =0A= _______________________________________________=0A= payload mailing list=0A= payload@ietf.org=0A= https://www.ietf.org/mailman/listinfo/payload=0A= From yekuiw@qti.qualcomm.com Wed Jun 26 22:33:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD04421F9B44 for ; Wed, 26 Jun 2013 22:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsYiYEmwIHMq for ; Wed, 26 Jun 2013 22:33:35 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55821F9B26 for ; Wed, 26 Jun 2013 22:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372311215; x=1403847215; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LnCLb2BQxMTh+LMpZZPS11AKySwpf4zviLSQlglc6Qs=; b=pRJQLG+A8AUgAnY7fVLpkGgmC5ynN5YOlzifmg2m1iGoqzjMHlJsz0R3 SKzeZvQ5+ovoTQ1wuUQgy5ZHu7Dz/1Za/LUW3LiHUiKbF4XA+iSCpxrQa btUWBUZ2ZQ5HoceOUB762NLBiHtLqUty6cTfzjqc08By12pG9Fh3nrzap Q=; X-IronPort-AV: E=Sophos;i="4.87,949,1363158000"; d="scan'208";a="46323049" Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 26 Jun 2013 22:33:35 -0700 X-IronPort-AV: E=Sophos;i="4.87,949,1363158000"; d="scan'208";a="559739134" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Jun 2013 22:33:35 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 22:33:34 -0700 From: "Wang, Ye-Kui" To: "Deshpande, Sachin" , "payload@ietf.org" Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format Thread-Index: AQHOcpSa4uQ5OSm2Uk+rJOohvFZKlplI79zA Date: Thu, 27 Jun 2013 05:33:33 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833844E2FE@nasanexd02f.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:33:39 -0000 Hi Sachin, Many thanks for your careful review and valuable comments! Please see below= , where I have removed those texts that are not needed any more. > I have done a first review of the draft-schierl-payload-rtp-h265-03.txt a= nd I > support the draft to be adopted as the starting point of the WG item. [YK] Thanks! > Typos: > T.1) Missing "as" in the following line on Pg. 14-15: > Parallel processing is possible through parallel decoding of CTU rows, wh= ere > the start of the decoding of a row is delayed by two CTUs, so "as" to ens= ure > that data related to a CTU above and to the right of the subject CTU is > available before the subject CTU is being decoded. >=20 [YK] Both "so to" and "so as to" seem to be OK. If you make a Googlefight (= http://www.googlefight.com/index.php?lang=3Den_GB&word1=3Dso+to&word2=3Dso+= as+to) actually the former wins slightly :-) > T.2) Title for Figure 3: > Current title: "The structure of the first aggregation unit in an AP" > I believe it should be something like: > "The structure of a single NAL unit packet" >=20 [YK] Absolutely! Good catch. Corrected (in what I preparing for the next v= ersion). > T.3) Text in Figure 8: > "NALU 2 HRD" should be "NALU 2 HDR" [YK] Corrected. >=20 > T.4) Text in last paragraph in section 6: > "remained" -> "remaining" >=20 [YK] Changed. >=20 > Discussions: > D.1) In section 4.5 Single NAL Unit Packets- "The payload header MUST be = an > exact copy of the NAL unit header of the contained NAL unit." > My understanding is that The NAL Unit payload data that is shown in Fig. = 3 - > contained in the single NAL unit packets does not include the NAL unit he= ader. > So a couple of clarification questions regarding this "MUST" requirement. >=20 > a. Does this mean that an entity can not change the payload header of a > single NAL unit type compared to the original NAL unit header in the NAL = unit? > e.g. to change the NAL unit type from say BLA_W_LP to BLA_N_LP if it deci= des > to drop LPs? Other similar NAL unit type change examples are possible. > I imagine supporting ability to allow a NAL unit type change such as abov= e > may be desirable. > Thus possibly changing the "MUST" requirement to "SHOULD" may make > sense? >=20 [YK] Very good point. Indeed, the language should not prohibit entities fro= m changing the NAL unit type value if it is desirable to change for example= a CRA picture to be a BLA picture in bitstream switching, splicing or rand= om accessing. I changed the language to be:=20 The payload header SHOULD be an exact copy of the NAL unit header of the co= ntained NAL unit. However, the Type (i.e. nal_unit_type) field MAY be chan= ged, e.g. when it is desirable to handle a CRA picture to be a BLA picture = [JCTVC-J0107]. > b. What is the way to check that the NAL unit header rule above is enforc= ed > when an entity receives a single NAL unit packet. > i.e. is there a conformance checking mechanism defined. >=20 [YK] No, there is no such conformance checking mechanism defined. Different= from those "shall" requirements in the video coding spec that must be veri= fiable by checking the bitstream (and possibly some external-means-provisio= ned information), herein the requirement can be simply imposed on the packe= tizer. > D.2) My understanding is that a single NAL unit can be sent either inside= a > single NAL unit packet or inside an aggregation packet (containing only o= ne > NAL unit). And that the bytes on the wire for these two cases will be dif= ferent. > Is there a use case envisioned that would benefit by allowing sending one > NAL unit (only) in these two different ways? > If there is not then do we want to disallow single NAL unit (only) scenar= io in > an AP? >=20 [YK] Good point again. After a bit thinking, I could not find a use case th= at needs an AP containing only one NAL unit. Unless such a use case is foun= d, I will go ahead to specify requiring the use of single NAL unit packet f= or carrying exactly one NAL unit in an RTP packet. > Editorial Suggestions: > E.1) At a number of places in text and figures (e.g. Fig. 3, 5, 6) DONL a= nd > DOND fields are mentioned as "optional". > e.g. section 4.5: "...an optional 16-bit DONL field (in network byte orde= r),...", > section 4.6 "...consists of an optional 8-bit DOND field followed by..." > I have a couple of questions and possible suggestions: > -Is this use of the term "optional" with regards to DONL and DOND in draf= t- > schierl-payload-rtp-h265-03 to be interpreted as described in RFC 2119 ? > (I believe it should be interpreted that way based on the "2. Conventions= " > section in draft-schierl-payload-rtp-h265-03) > If so then RFC 2119 says on pg. 2: > "... 5. MAY This word, or the adjective "OPTIONAL", mean that an item i= s > truly optional..." > -Are the DOND and DONL "optional" as per RFC 2119 definition? > I believe there are conditions where DONL and DOND MUST be present. > e.g. section 4.5: "...If tx-mode is equal to "MST" or sprop-depack-buf-na= lus is > greater than 0, the DONL field MUST be present...", section 4.6: "...If t= x-mode > is equal to "MST" or sprop-depack-buf-nalus is greater than 0, the DONL f= ield > MUST be present..." > In this case is it correct to refer to DONL and DOND fields as "optional"= ? > -In case it is correct to refer to DONL and DOND fields as "optional" sho= uld > the use of the word in text and Fig. 3, 5, 6 be using upper case "OPTIONA= L"? >=20 [YK] Hmm. I think this is again a good point. However, I am not sure what e= xactly the best way is. Checking RFC 6184 and RFC 6190, there are also such= optional fields, and both "OPTIONAL" and "optional" are used. Insights fro= m those who are more experienced on this would be appreciated! > E.2) The term "header" is referred with different notations (e.g. XHdr, H= DR, > Header) when referring to different header fields in figures and text e.g= .: > Payload header is referred as: "PayloadHdr" (many Figures, text), NAL Uni= t > header is referred as: "NALU X HDR" (Fig. 8 and text), Fragmentation Unit > header is referred as: "FU Header" (figure 9 and text). > A consistent notation for referring to "header" fields may avoid confusio= n. > As currently it may appear to a casual reader that there is some reason t= o > use different labeling for these different header fields. >=20 [YK] Another good point. However, I tried to unify but found that we'd bett= er keep them as they are. For example, "HDR" is only used inside Figures, c= hanging of some occurrences would destroy figures, which have to be drawn u= sing ASCII symbols. > E.3) It is mentioned: > "Aggregation Packet (AP) : Contains one or more NAL units within one acce= ss > unit." (section 4.2) "An AP aggregates NAL units within one access unit." > (section 4.6) But it seems there is no statement saying a "MUST" requirem= ent > on APs regarding all NAL units in it MUST belong to same access units. > e.g. something like: > An AP MUST contain NAL units which belong to the same access unit. >=20 [YK] This requirement to me is obvious. For example, if we should add such = a MUST requirement, should we also add a MUST requirement to say that a sin= gle NAL unit packet MUST contain exactly one NAL unit? And I believe there = are many more such cases. > E.4) Perhaps the current "Fragmentation Units" (section 4.7) could be ter= med > "Fragmentation Unit Packets" or "Fragmentation Packets". > This will then be similar to how aggregation "packets" consist of aggrega= tion > "units". [YK] We could do this. However, I guess keeping the term here to be consist= ent with RFC 6184 and RFC 6190 is probably more preferable. BR, YK From 2mkristensen@gmail.com Thu Jun 27 06:28:42 2013 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700B21F9DDD for ; Thu, 27 Jun 2013 06:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrCJyfGcoHDB for ; Thu, 27 Jun 2013 06:28:40 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3A6F21F9DD7 for ; Thu, 27 Jun 2013 06:28:32 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so414811lbc.3 for ; Thu, 27 Jun 2013 06:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CiwvYX7U1TwDD1EfofYa3V74B3ckTcUCcQzVthyX2Js=; b=qYSZo59vAMeByi2PYS+xB4hRtb43AIMCDs8991by3FfdGgat+VX7xw1CYUGnSIlQ77 73YTXvNhjPJFbvy8bVIqnblExj409w19nImvzZQND1YTFJ1U9jR354dh00shC8KKUrRD DhdjoBSCQ/XuT4wg7r2pDCeit2O5tg52q7ltS4wlRqbVnMxo1CUsN089oxHn8eERGry6 +gc5bgEqCYdxhA0kQb1jOZt5Q5DoutoyZqUTYavn1UZlvKt44xyYCMmkLtisah84uJEa nVOIEnzAeaWzpGf92SnXhg3892lIrNBV9uw/fNev58fmoNEGZOg6AxtEbuiQ1m24KHhD Xc0Q== MIME-Version: 1.0 X-Received: by 10.112.219.133 with SMTP id po5mr4219781lbc.80.1372339711778; Thu, 27 Jun 2013 06:28:31 -0700 (PDT) Received: by 10.114.13.131 with HTTP; Thu, 27 Jun 2013 06:28:31 -0700 (PDT) In-Reply-To: <51BC205F.8010900@db.org> References: <06d701ce6783$1edefcf0$5c9cf6d0$@gmail.com> <51BC205F.8010900@db.org> Date: Thu, 27 Jun 2013 15:28:31 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Alfred E. Heggestad" Content-Type: multipart/alternative; boundary=001a11c32ed808275a04e022bd12 Cc: IETF Payload WG Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:28:42 -0000 --001a11c32ed808275a04e022bd12 Content-Type: text/plain; charset=ISO-8859-1 +1 for this draft as basis. Will provide feedback and proposals, the first ones in a few seconds. -- Tom On 15 June 2013 10:05, Alfred E. Heggestad wrote: > On 6/12/13 5:40 PM, Roni Even wrote: > >> Hi, >> >> The ITU-T approved a new video codec High Efficiency Video Coding also >> known as H.265. >> >> There is an individual draft titled RTP Payload Format for High >> Efficiency Video Coding draft-schierl-payload-rtp-**h265-03 < >> http://tools.ietf.org/html/**draft-schierl-payload-rtp-**h265-03 >> > >> >> The WG chairs would like to ask for a new milestone for December 2013 RTP >> Payload Format for High Efficiency Video Codingand accept this document as >> the initial document to address the milestone. >> >> >> The WG chairs are looking for WG feedback >> >> Please respond by Monday July 1^st 2013 with your positions. >> >> > I support adopting this draft. > > > > > > /alfred > ______________________________**_________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/**listinfo/payload > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c32ed808275a04e022bd12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 for this draft as basis.

Will = provide feedback and proposals, the first ones in a few seconds.

-- Tom

On 15 June 2013 10:05, Alfred E. Heggestad <= span dir=3D"ltr"><aeh@db= .org> wrote:
On 6/12/13 5:40 PM, Roni Even wrote:
Hi,

The ITU-T approved a new video codec High Efficiency Video Coding also know= n as =A0H.265.

There is an individual draft =A0titled RTP Payload Format for High Efficien= cy Video Coding draft-schierl-payload-rtp-h265-03 <http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-0= 3>

The WG chairs would like to ask for a new milestone for December 2013 RTP P= ayload Format for High Efficiency Video Codingand accept this document as t= he initial document to address the milestone.


The WG chairs are looking for WG feedback

Please respond by Monday July 1^st =A0 2013 with your positions.


I support adopting this draft.





/alfred
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload



--
# Cisco =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/telepresence/
## tomkrist@c= isco.com =A0| =A0= http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--001a11c32ed808275a04e022bd12-- From 2mkristensen@gmail.com Thu Jun 27 06:33:41 2013 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAECF21F9E0B for ; Thu, 27 Jun 2013 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBwUSoqRCdcF for ; Thu, 27 Jun 2013 06:33:40 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0D21F9E0C for ; Thu, 27 Jun 2013 06:33:39 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so826023lab.32 for ; Thu, 27 Jun 2013 06:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WC2Y7FrvyR1x5bg363vjZT7U+9GHr8D9WTJdfzoNKUs=; b=BHYOI7PrTvhVFgJPXztLgo75f/zb1Y1BKL3mEjm/SR5ECX+3PpsuWr56uyCqvcPYeD yIXLk9SVS7HsuGmH0K2hwG8STv5qa2vRpXo0hmyLF+3oRQmY6i6CzJQ0d6s7q+3Lt8M6 blscZ7yIHYFM1LflnM2gfUfAZArK9jndaTdqa2bGomi2lXSAsBPwx4m8PkQWgzvkQ3sB S6DLmWd7g2X22JREy4LJUiAhE3QZWKc3oWQfi9RHK9dj+00BeD2HMDsGZV5F4bUMLuKu pr96MsZ1/dZ30vKiFsvZR33eLWQILKZDH3CJF3gSwufXJF2ma8hG0KiicFU1lHFCkxA/ ReGw== MIME-Version: 1.0 X-Received: by 10.152.115.242 with SMTP id jr18mr4202889lab.7.1372340017453; Thu, 27 Jun 2013 06:33:37 -0700 (PDT) Received: by 10.114.13.131 with HTTP; Thu, 27 Jun 2013 06:33:37 -0700 (PDT) In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> Date: Thu, 27 Jun 2013 15:33:37 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Wang, Ye-Kui" Content-Type: multipart/alternative; boundary=001a11c3327a40637b04e022cf5b Cc: Geir Arne Sandbakken , "payload@ietf.org" , Tom Kristensen Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:33:42 -0000 --001a11c3327a40637b04e022cf5b Content-Type: text/plain; charset=ISO-8859-1 We have done a first review of the new version of this draft. Seems promising. However, we are missing a couple of things. First, we would like to include a max-fps parameter in line with the proposed draft draft-kristensen-payload-rtp-h241param-00. A similar parameter has been part of H.241 for while and will eventually be valid for H.265 in H.323 land too. Note that this is a limiting parameter, different from the other max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br). We propose max-fps as something along the lines of: ------ max-fps: The value of max-fps is an integer indicating the maximum frame rate in units of hundredths of frames per second that can be efficiently received. The signaled highest level is conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of decoding video efficiently at the full frame rate that is implied by the signaled highest level and, if present, one or more of the parameters max-ls, max-lps or max-br. Notice that the value of max-fps is not necessarily the frame rate at which the maximum frame size can be sent, it constitutes a constraint on maximum frame rate for all resolutions. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-fps is used to signal a constraint, lowering the maximum frame rate from what is implied by the signaled MaxLumaSR and MaxLumaPS. The encoder MUST use a frame rate equal to or less than this value. In cases where the max-fps parameter is absent the encoder is free to choose any frame rate according to the highest signaled level and any signaled optional parameters. ------ Second, we are missing an ability to signal support for tiles (number of tiles used/to expect) and maximum tile size. The ability to signal support for a number of tiles higher than what is implied for the signalled level (as listed in Table A-1 in the HEVC specification. These two parameters have the same semantics as the existing max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br). We propose max-tr (or max-tile-rows) and the equivalent description for max-tc (or max-tile-cols) along the lines of: ------ (Will be introduced toghether with max-ls, max-lps, max-cpb, max-dpb, max-br, as parameters that "MAY be used to signal the capabilities of a receiver implementation.") capabilities...: max-tr: The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than is required by the signaled highest level. When max-tr is signaled, the receiver must be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the signaled highest level is replaced with the value of max-tr. The value of max-tr MUST be greater than or equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level. Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than is indicated in the signaled highest level. max-tc: (As for max-tr with s/max-tr/max-tc/ s/MaxTileRows/MaxTileCols/ s/rows/colums) ------ The last tile related parameter is a new parameter named max-lts to specify maximum luma tile size to make sure the decoder doesn't receive a stream with too large resolution and/or bitrate in one single tile. The max-lts parameter is a limiting parameter - as described for max-fps above. We propose max-lts to signal the maximum size allowed in one tile along the lines of: ------ max-lts: The value of max-lts, Maximum Luma Tile Size, is an integer indicating the maximum tile size in units of luma samples. The max-lts parameter signals the maximum size of one tile that the decoder is able to decode. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-lts is used to signal a constraint on the maximum tile size. The encoder MUST use a tile size equal to or less than this value. In cases where the max-lts parameter is absent the encoder is free to choose any tile size according to the highest signaled level and any signaled optional parameters. ------ Please consider these additions. More text needed to merge the new parameters into the media subtype specification, offer/answer rules and so on - of course. To be dealt with later. -- Tom On 11 June 2013 19:00, Wang, Ye-Kui wrote: > Dear All, > > We have just submitted versions 02 and 03 of > draft-schierl-payload-rtp-h265, for which the links are as follows: > > Version 02: > URL: > http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt > Htmlized: > http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-02 > > Version 03: > URL: > http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt > Htmlized: > http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-03 > > Version 02 includes huge changes compared to the earlier submitted version > 01. In a short summary, the authors have worked hard to try to make the > design complete, from both the payload structure and the signaling points > of view. Compared to version 02, version 03 only contains a correction of > the email address of an author. > > Due to that the industry is eager to deploy H.265/HEVC and other standards > bodies such as 3GPP rely on the payload format for support of H.265/HEVC in > RTP based video services, we need to progress this draft relatively > quickly. Therefore, we would like to request quick reviews from interested > parties and also request for the WG status of this draft. > > BR, YK (on behalf of the authors) > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c3327a40637b04e022cf5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have done a first review of the new version of this dra= ft. Seems promising. However, we are missing a couple of things.
<= br>
First, we would like to include a max-fps parameter in line w= ith the proposed draft draft-kristensen-payload-rtp-h241param-00. A similar= parameter has been part of H.241 for while and will eventually be valid fo= r H.265 in H.323 land too. Note that this is a limiting parameter, differen= t from the other max-* parameters (max-ls, max-lps, max-cpb, max-dpb and ma= x-br).

We propose max-fps as something along the lines of:
=A0 =A0------
=A0 =A0max-fps: =A0The value of max-fps is a= n integer indicating the maximum
=A0 =A0 =A0 frame rate in units = of hundredths of frames per second that can be
=A0 =A0 =A0 efficiently received. =A0The signaled highest level is con= veyed in
=A0 =A0 =A0 the value of the profile-level-id parameter = or the max-recv-level
=A0 =A0 =A0 parameter. =A0The max-fps param= eter MAY be used to signal that the
=A0 =A0 =A0 receiver has a constraint in that it is not capable of dec= oding
=A0 =A0 =A0 video efficiently at the full frame rate that i= s implied by the
=A0 =A0 =A0 signaled highest level and, if prese= nt, one or more of the
=A0 =A0 =A0 parameters max-ls, max-lps or max-br.

=
=A0 =A0 =A0 Notice that the value of max-fps is not necessarily the fr= ame rate
=A0 =A0 =A0 at which the maximum frame size can be sent,= it constitutes a
=A0 =A0 =A0 constraint on maximum frame rate for all resolutions.

=A0 =A0 =A0 =A0 =A0Informational note: The max-fps par= ameter is semantically
=A0 =A0 =A0 =A0 =A0different from max-ls, = max-lps, max-cpb, max-dpb,
=A0 =A0 =A0 =A0 =A0and max-br in that max-fps is used to signal a cons= traint,
=A0 =A0 =A0 =A0 =A0lowering the maximum frame rate from w= hat is implied by the
=A0 =A0 =A0 =A0 =A0signaled MaxLumaSR and M= axLumaPS.

=A0 =A0 =A0 The encoder MUST use a frame rate equal to or less than th= is
=A0 =A0 =A0 value. =A0In cases where the max-fps parameter is = absent the
=A0 =A0 =A0 encoder is free to choose any frame rate a= ccording
=A0 =A0 =A0 to the highest signaled level and any signaled optional
=A0 =A0 =A0 parameters.
=A0 =A0------

Second, we are missing an ability to signal support for tiles (number of t= iles used/to expect) and maximum tile size. The ability to signal support f= or a number of tiles higher than what is implied for the signalled level (a= s listed in Table A-1 in the HEVC specification. These two parameters have = the same semantics as the existing max-* parameters (max-ls, max-lps, max-c= pb, max-dpb and max-br).

We propose max-tr (or max-tile-rows) and the equivalent= description for max-tc (or max-tile-cols) along the lines of:
= =A0 =A0------
=A0 =A0(Will be introduced toghether with max-ls, m= ax-lps, max-cpb, max-dpb, max-br, as parameters that "MAY be used to s= ignal the capabilities of a receiver implementation.")
capabilities...:

=A0 =A0max-tr:=A0
= =A0 =A0 =A0 The value of max-tr is an integer indication the maximum number=
=A0 =A0 =A0 of tile rows. The max-tr parameter signals that the = receiver is
=A0 =A0 =A0 capable of decoding video with a larger number of tile row= s than
=A0 =A0 =A0 is required by the signaled highest level.

=A0 =A0 =A0 When max-tr is signaled, the receiver mus= t be able to decode NAL
=A0 =A0 =A0 unit streams that conform to the signaled highest level, w= ith the
=A0 =A0 =A0 exception that the MaxTileRows value in Table= A-1 of [HEVC] for
=A0 =A0 =A0 the signaled highest level is repl= aced with the value of max-tr.
=A0 =A0 =A0 The value of max-tr MUST be greater than or equal to the v= alue of
=A0 =A0 =A0 MaxTileRows given in Table A-1 of [HEVC] for = the highest
=A0 =A0 =A0 level. Senders MAY use this knowledge to = send pictures utilizing
=A0 =A0 =A0 a larger number of tile rows than is indicated in the sign= aled
=A0 =A0 =A0 highest level.

=A0 =A0m= ax-tc:
=A0 =A0 =A0 (As for max-tr with s/max-tr/max-tc/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s/MaxTileRows/MaxTileC= ols/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s/rows/colums)
=A0 =A0------

The last tile related paramet= er is a new parameter named max-lts to specify maximum luma tile size to ma= ke sure the decoder doesn't receive a stream with too large resolution = and/or bitrate in one single tile. The max-lts parameter is a limiting para= meter - as described for max-fps above.=A0

We propose max-lts to signal the maximum size allowed i= n one tile along the lines of:
=A0 =A0------
=A0 =A0max= -lts:
=A0 =A0 =A0 The value of max-lts, Maximum Luma Tile Size, i= s an integer
=A0 =A0 =A0 indicating the maximum tile size in units of luma samples.= The
=A0 =A0 =A0 max-lts parameter signals the maximum size of on= e tile that the
=A0 =A0 =A0 decoder is able to decode.
=
=A0 =A0 =A0 =A0 =A0Informational note: The max-fps parameter is semanticall= y
=A0 =A0 =A0 =A0 =A0different from max-ls, max-lps, max-cpb, max= -dpb,
=A0 =A0 =A0 =A0 =A0and max-br in that max-lts is used to si= gnal a constraint
=A0 =A0 =A0 =A0 =A0on the maximum tile size.

=A0 = =A0 =A0 The encoder MUST use a tile size equal to or less than this
=A0 =A0 =A0 value. =A0In cases where the max-lts parameter is absent the=
=A0 =A0 =A0 encoder is free to choose any tile size according
=A0 =A0 =A0 to the highest signaled level and any signaled optional
=A0 =A0 =A0 parameters.
=A0 =A0------

Please consider these additions. More text needed to merg= e the new parameters into the media subtype specification, offer/answer rul= es and so on - of course. To be dealt with later.

-- Tom


On 11 June 2013 19:00, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:
Dear All,

We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows:

Version 02:
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-schierl-payload-rtp-h265-02.txt
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-s= chierl-payload-rtp-h265-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-schierl-payload-rtp-h265-02

Version 03:
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-schierl-payload-rtp-h265-03.txt
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-s= chierl-payload-rtp-h265-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-schierl-payload-rtp-h265-03

Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author.

Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft.

BR, YK (on behalf of the authors)
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



--
# Cisco =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/telepresence/
## tomkrist@c= isco.com =A0| =A0= http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--001a11c3327a40637b04e022cf5b-- From yekuiw@qti.qualcomm.com Thu Jun 27 10:28:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEF121F9C52 for ; Thu, 27 Jun 2013 10:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQQdTE0lDWdp for ; Thu, 27 Jun 2013 10:28:25 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 72B5721F9A00 for ; Thu, 27 Jun 2013 10:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372354104; x=1403890104; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bs9HEuUadlp4eoBIxYWTK+pP2UXOhZhwJ9nQCQSfv4o=; b=mTtpLgKFDqofD0eQf6ftjjxbTy6cRs9aAllnFp2DekhG1VEi3pe6h0de 2cdpuwhqPeV51lN36iqCSFbGj65OQKtDYUa1Z/DqjaVNL1EXuuNqGiI4u zj7bFwn0+dww9DH+wmoRWTkZW4hOh3hq/gfdWGtb055fSW8CTb6c4BarN 8=; X-IronPort-AV: E=Sophos;i="4.87,953,1363158000"; d="scan'208,217";a="46355217" Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 27 Jun 2013 10:28:20 -0700 X-IronPort-AV: E=Sophos;i="4.87,953,1363158000"; d="scan'208,217";a="471326490" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Jun 2013 10:28:19 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 10:28:19 -0700 From: "Wang, Ye-Kui" To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format Thread-Index: AQHOczrzTxJvXBhLWkGnuMyZJW3g0ZlJxGPg Date: Thu, 27 Jun 2013 17:28:18 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833844E9AB@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A833844E9ABnasanexd02fnaqu_" MIME-Version: 1.0 Cc: Geir Arne Sandbakken , "payload@ietf.org" , Tom Kristensen Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:28:49 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A833844E9ABnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the review and the suggestions. I have some comments on the sugg= estions. On max-fps: The following paragraph in draft-kristensen-payload-rtp-h241par= am-00 seems to be the main reason for the introduction of max-fps. Just for= a better understanding, could you please clarify why the receiver side wou= ld have a preferred frame rate? Does that relate to rendering/display capab= ility? If that is the case, then discarding of the additional frames should= be done by the rendering module instead of the decoder, as conforming deco= ders should just output frames that are indicated, by the bitstream, to be = output. If the encoder chooses to send at a higher frame rate than preferred by the receiver side, the decoder will normally discard the additional frames after decoding them. The transmission of the extra frames and the processing of frames to just discard them are wasteful and the bandwidth and processing could be used more effectively. Not relevant for H.265/HEVC payload, but for H.264/AVC payload in RFC 6184,= would introduction of such a parameter cause any IOP issue between a legac= y sender and a new receiver? I think that should be analyzed in draft-krist= ensen-payload-rtp-h241param-00. Certainly, it would also be good to clarify= the above question related to rendering/display capability in draft-kriste= nsen-payload-rtp-h241param-00 too. On max-lts: It makes sense to me, but we would need to specify a lower boun= d of the value, such that it would at least not contradict with the min til= e size implied by other parameters. On max-tr and max-tc: It seems that they are saying that there are scenario= s where you would need more tiles than allowed by the indicated level. Coul= d you please give an (practical) example that this is needed? I am asking t= his because in JCT-VC there had been a lot of discussions after which the l= evel limits of MaxTileRows and MaxTileCols were concluded. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Tom Kristensen Sent: Thursday, June 27, 2013 6:34 AM To: Wang, Ye-Kui Cc: Geir Arne Sandbakken; payload@ietf.org; Tom Kristensen Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for= mat We have done a first review of the new version of this draft. Seems promisi= ng. However, we are missing a couple of things. First, we would like to include a max-fps parameter in line with the propos= ed draft draft-kristensen-payload-rtp-h241param-00. A similar parameter has= been part of H.241 for while and will eventually be valid for H.265 in H.3= 23 land too. Note that this is a limiting parameter, different from the oth= er max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br). We propose max-fps as something along the lines of: ------ max-fps: The value of max-fps is an integer indicating the maximum frame rate in units of hundredths of frames per second that can be efficiently received. The signaled highest level is conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of decoding video efficiently at the full frame rate that is implied by the signaled highest level and, if present, one or more of the parameters max-ls, max-lps or max-br. Notice that the value of max-fps is not necessarily the frame rate at which the maximum frame size can be sent, it constitutes a constraint on maximum frame rate for all resolutions. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-fps is used to signal a constraint, lowering the maximum frame rate from what is implied by the signaled MaxLumaSR and MaxLumaPS. The encoder MUST use a frame rate equal to or less than this value. In cases where the max-fps parameter is absent the encoder is free to choose any frame rate according to the highest signaled level and any signaled optional parameters. ------ Second, we are missing an ability to signal support for tiles (number of ti= les used/to expect) and maximum tile size. The ability to signal support fo= r a number of tiles higher than what is implied for the signalled level (as= listed in Table A-1 in the HEVC specification. These two parameters have t= he same semantics as the existing max-* parameters (max-ls, max-lps, max-cp= b, max-dpb and max-br). We propose max-tr (or max-tile-rows) and the equivalent description for max= -tc (or max-tile-cols) along the lines of: ------ (Will be introduced toghether with max-ls, max-lps, max-cpb, max-dpb, ma= x-br, as parameters that "MAY be used to signal the capabilities of a recei= ver implementation.") capabilities...: max-tr: The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than is required by the signaled highest level. When max-tr is signaled, the receiver must be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the signaled highest level is replaced with the value of max-tr. The value of max-tr MUST be greater than or equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level. Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than is indicated in the signaled highest level. max-tc: (As for max-tr with s/max-tr/max-tc/ s/MaxTileRows/MaxTileCols/ s/rows/colums) ------ The last tile related parameter is a new parameter named max-lts to specify= maximum luma tile size to make sure the decoder doesn't receive a stream w= ith too large resolution and/or bitrate in one single tile. The max-lts par= ameter is a limiting parameter - as described for max-fps above. We propose max-lts to signal the maximum size allowed in one tile along the= lines of: ------ max-lts: The value of max-lts, Maximum Luma Tile Size, is an integer indicating the maximum tile size in units of luma samples. The max-lts parameter signals the maximum size of one tile that the decoder is able to decode. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-lts is used to signal a constraint on the maximum tile size. The encoder MUST use a tile size equal to or less than this value. In cases where the max-lts parameter is absent the encoder is free to choose any tile size according to the highest signaled level and any signaled optional parameters. ------ Please consider these additions. More text needed to merge the new paramete= rs into the media subtype specification, offer/answer rules and so on - of = course. To be dealt with later. -- Tom On 11 June 2013 19:00, Wang, Ye-Kui > wrote: Dear All, We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows: Version 02: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-02.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-02 Version 03: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-03.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-03 Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author. Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft. BR, YK (on behalf of the authors) _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_8BA7D4CEACFFE04BA2D902BF11719A833844E9ABnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,=

 <= /p>

Thanks for the review and= the suggestions. I have some comments on the suggestions.

 <= /p>

On max-fps: The following= paragraph in draft-kristensen-payload-rtp-h241param-00 seems to be the mai= n reason for the introduction of max-fps. Just for a better understanding, could you please clarify why the receiver side would have a= preferred frame rate? Does that relate to rendering/display capability? If= that is the case, then discarding of the additional frames should be done = by the rendering module instead of the decoder, as conforming decoders should just output frames that are = indicated, by the bitstream, to be output.

 <= /p>

   If the encoder chooses to send at a higher fr= ame rate than preferred

   by the receiver side, the decoder will normal= ly discard the

   additional frames after decoding them.  = The transmission of the extra

   frames and the processing of frames to just d= iscard them are wasteful

   and the bandwidth and processing could be use= d more effectively.

 <= /p>

Not relevant for H.265/HE= VC payload, but for H.264/AVC payload in RFC 6184, would introduction of su= ch a parameter cause any IOP issue between a legacy sender and a new receiver? I think that should be analyzed in draft-kristensen-pa= yload-rtp-h241param-00. Certainly, it would also be good to clarify the abo= ve question related to rendering/display capability in draft-kristensen-pay= load-rtp-h241param-00 too.

 <= /p>

On max-lts: It makes sens= e to me, but we would need to specify a lower bound of the value, such that= it would at least not contradict with the min tile size implied by other parameters.

 <= /p>

On max-tr and max-tc: It = seems that they are saying that there are scenarios where you would need mo= re tiles than allowed by the indicated level. Could you please give an (practical) example that this is needed? I am asking this b= ecause in JCT-VC there had been a lot of discussions after which the level = limits of MaxTileRows and MaxTileCols were concluded.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Tom Kristensen
Sent: Thursday, June 27, 2013 6:34 AM
To: Wang, Ye-Kui
Cc: Geir Arne Sandbakken; payload@ietf.org; Tom Kristensen
Subject: Re: [payload] Submission of new versions of H.265/HEVC payl= oad format

 

We have done a first review of the new version of th= is draft. Seems promising. However, we are missing a couple of things.=

 

First, we would like to include a max-fps parameter = in line with the proposed draft draft-kristensen-payload-rtp-h241param-00. = A similar parameter has been part of H.241 for while and will eventually be= valid for H.265 in H.323 land too. Note that this is a limiting parameter, different from the other max-* par= ameters (max-ls, max-lps, max-cpb, max-dpb and max-br).

 

We propose max-fps as something along the lines of:<= o:p>

   ------

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

      frame rate in units of hundredt= hs of frames per second that can be

      efficiently received.  The= signaled highest level is conveyed in

      the value of the profile-level-= id parameter or the max-recv-level

      parameter.  The max-fps pa= rameter MAY be used to signal that the

      receiver has a constraint in th= at it is not capable of decoding

      video efficiently at the full f= rame rate that is implied by the

      signaled highest level and, if = present, one or more of the

      parameters max-ls, max-lps or m= ax-br.

 

      Notice that the value of max-fp= s is not necessarily the frame rate

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

      constraint on maximum frame rat= e for all resolutions.

 

         Informational note= : The max-fps parameter is semantically

         different from max= -ls, max-lps, max-cpb, max-dpb,

         and max-br in that= max-fps is used to signal a constraint,

         lowering the maxim= um frame rate from what is implied by the

         signaled MaxLumaSR= and MaxLumaPS.

 

      The encoder MUST use a frame ra= te equal to or less than this

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

      encoder is free to choose any f= rame rate according

      to the highest signaled level a= nd any signaled optional

      parameters.

   ------

 

Second, we are missing an ability to signal support = for tiles (number of tiles used/to expect) and maximum tile size. The abili= ty to signal support for a number of tiles higher than what is implied for = the signalled level (as listed in Table A-1 in the HEVC specification. These two parameters have the same se= mantics as the existing max-* parameters (max-ls, max-lps, max-cpb, max-dpb= and max-br).

 

We propose max-tr (or max-tile-rows) and the equival= ent description for max-tc (or max-tile-cols) along the lines of:

   ------

   (Will be introduced toghether with max-= ls, max-lps, max-cpb, max-dpb, max-br, as parameters that "MAY be used= to signal the capabilities of a receiver implementation.")=

capabilities...:

 

   max-tr: 

      The value of max-tr is an integ= er indication the maximum number

      of tile rows. The max-tr parame= ter signals that the receiver is

      capable of decoding video with = a larger number of tile rows than

      is required by the signaled hig= hest level.

 

      When max-tr is signaled, the re= ceiver must be able to decode NAL

      unit streams that conform to th= e signaled highest level, with the

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

      the signaled highest level is r= eplaced with the value of max-tr.

      The value of max-tr MUST be gre= ater than or equal to the value of

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

      level. Senders MAY use this kno= wledge to send pictures utilizing

      a larger number of tile rows th= an is indicated in the signaled

      highest level.

 

   max-tc:

      (As for max-tr with s/max-tr/ma= x-tc/

              &nb= sp;           s/MaxTileRows/MaxTileCols/

              &nb= sp;           s/rows/colums)

   ------

 

The last tile related parameter is a new parameter n= amed max-lts to specify maximum luma tile size to make sure the decoder doe= sn't receive a stream with too large resolution and/or bitrate in one singl= e tile. The max-lts parameter is a limiting parameter - as described for max-fps above. 

 

We propose max-lts to signal the maximum size allowe= d in one tile along the lines of:

   ------

   max-lts:

      The value of max-lts, Maximum L= uma Tile Size, is an integer

      indicating the maximum tile siz= e in units of luma samples. The

      max-lts parameter signals the m= aximum size of one tile that the

      decoder is able to decode.=

 

         Informational note= : The max-fps parameter is semantically

         different from max= -ls, max-lps, max-cpb, max-dpb,

         and max-br in that= max-lts is used to signal a constraint

         on the maximum til= e size.

 

      The encoder MUST use a tile siz= e equal to or less than this

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

      encoder is free to choose any t= ile size according

      to the highest signaled level a= nd any signaled optional

      parameters.

   ------

 

Please consider these additions. More text needed to= merge the new parameters into the media subtype specification, offer/answe= r rules and so on - of course. To be dealt with later.

 

-- Tom

 

On 11 June 2013 19:00, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:

Dear All,

We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows:

Version 02:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt
Htmlized:        http://tools.ietf.org/= html/draft-schierl-payload-rtp-h265-02
Diff:            http= ://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-02

Version 03:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt
Htmlized:        http://tools.ietf.org/= html/draft-schierl-payload-rtp-h265-03
Diff:            http= ://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-03

Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the email address of an author.

Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested parties and also request for the WG status o= f this draft.

BR, YK (on behalf of the authors)
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



 

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

--_000_8BA7D4CEACFFE04BA2D902BF11719A833844E9ABnasanexd02fnaqu_--