From internet-drafts@ietf.org Wed Feb 5 09:05:27 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB31A01F6; Wed, 5 Feb 2014 09:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoNzo9X5U2N5; Wed, 5 Feb 2014 09:05:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFB1A01CB; Wed, 5 Feb 2014 09:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205170524.26708.61049.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 09:05:24 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:05:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs Authors : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-05.txt Pages : 22 Date : 2014-02-05 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-aptx-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Thu Feb 6 04:37:49 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209EF1A00F6 for ; Thu, 6 Feb 2014 04:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GichGu9nPUYN for ; Thu, 6 Feb 2014 04:37:47 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C831A00F5 for ; Thu, 6 Feb 2014 04:37:47 -0800 (PST) Received: from [130.209.247.112] (port=56821 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WBODB-0004uF-IB for payload@ietf.org; Thu, 06 Feb 2014 12:37:45 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <20140205170524.26708.61049.idtracker@ietfa.amsl.com> Date: Thu, 6 Feb 2014 12:37:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140205170524.26708.61049.idtracker@ietfa.amsl.com> To: payload@ietf.org X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 12:37:49 -0000 On 5 Feb 2014, at 17:05, 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. >=20 > Title : RTP Payload Format for Standard apt-X and = Enhanced apt-X Codecs > Authors : John Lindsay > Hartmut Foerster > Filename : draft-ietf-payload-rtp-aptx-05.txt > Pages : 22 > Date : 2014-02-05 >=20 > Abstract: > This document specifies a scheme for packetizing Standard apt-X, or > Enhanced apt-X, encoded audio data into Real-time Transport Protocol > (RTP) packets. The document describes a payload format that permits > transmission of multiple related audio channels in a single RTP > payload, and a means of establishing Standard apt-X and Enhanced > apt-X connections through the Session Description Protocol (SDP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-05 This version adds a reference to draft-ietf-avtcore-srtp-vbr-audio; this = should be a reference to RFC 6562. --=20 Colin Perkins http://csperkins.org/ From harald@alvestrand.no Thu Feb 6 16:21:37 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1644E1A0573 for ; Thu, 6 Feb 2014 16:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rwChLrdFG2G for ; Thu, 6 Feb 2014 16:21:33 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D61A044D for ; Thu, 6 Feb 2014 16:21:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5DC1B7C4AA9 for ; Fri, 7 Feb 2014 01:21:30 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bXMZhuBXPUi for ; Fri, 7 Feb 2014 01:21:30 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id C95067C4AA0 for ; Fri, 7 Feb 2014 01:21:29 +0100 (CET) Message-ID: <52F42707.10606@alvestrand.no> Date: Fri, 07 Feb 2014 01:21:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010300020900050606080305" Subject: Re: [payload] New Version Notification for draft-nandakumar-payload-sdp-max-video-resolution-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 00:21:37 -0000 This is a multi-part message in MIME format. --------------010300020900050606080305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/01/2014 02:51 AM, Suhas Nandakumar wrote: > Hello All > > Following draft has been submitted to specify payload format > parameters indicating an end-point's maximum image resolution receive > capability in SDP. This draft aims at solving the issue with > specifying such functionality for VP8 and is also applicable to other > codecs in general. Thank you for finally posting this to the payload list! (The date of the draft is Dec 7 - I've been waiting for the proponents to make a public statement about it). My biggest worry with this particular proposal is that it modifies the way a=fmtp is specified. As far as I understand, the syntax of a=fmtp has previously been assumed to be specified completely by the payload specification (viz the rather non-orthogonal stuff that is in the DTMF payload). This specification proposes to add new parameters into a=fmtp that are applicable to any payload. This seems like a doubtful architectural decision. I think it would be cleaner to add a new a= attribute that is independent of codec (but linked to payload type) containing the information. I also have a nit with the way offer/answer is specified: ..... When the direction is sendonly, these attributes have no interpretation and MUST be ignored by the receiving Endpoint, if present. ...... An SDP Answerer MUST NOT include these parameters in the SDP Answer unless they are specified in the associated SDP Offer. If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless. My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply. Note: I see absolutely no reason to link this functionality, if desirable, to the RTP format for VP8. If it needs mandating, it should be mandated for all video types going forward, including H.265, and strongly recommended for all video types that have been standardized in the past. If it doesn't need mandating, it doesn't need mandating for anyone. > > > URL: > http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt > Htmlized: > http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00 > > > Looking forward for the inputs on how do we take his work ahead. > > > Thanks > Suhas Nandakumar > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. --------------010300020900050606080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:
Hello All

  Following draft has been submitted to specify payload format parameters indicating an end-point's maximum image resolution receive capability in SDP. This draft aims at solving the issue with specifying such functionality for VP8 and is also applicable to other codecs in general.

Thank  you for finally posting this to the payload list! (The date of the draft is Dec 7 - I've been waiting for the proponents to make a public statement about it).

My biggest worry with this particular proposal is that it modifies the way a=fmtp is specified.

As far as I understand, the syntax of a=fmtp has previously been assumed to be specified completely by the payload specification (viz the rather non-orthogonal stuff that is in the DTMF payload).

This specification proposes to add new parameters into a=fmtp that are applicable to any payload. This seems like a doubtful architectural decision.
I think it would be cleaner to add a new a= attribute that is independent of codec (but linked to payload type) containing the information.

I also have a nit with the way offer/answer is specified:

                          ..... When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.

   ......

   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.


If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless.

My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply.
Note: I see absolutely no reason to link this functionality, if desirable, to the RTP format for VP8. If it needs mandating, it should be mandated for all video types going forward, including H.265, and strongly recommended for all video types that have been standardized in the past.

If it doesn't need mandating, it doesn't need mandating for anyone.







URL:             http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt
Htmlized:        http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00


Looking forward for the inputs on how do we take his work ahead.


Thanks
Suhas Nandakumar


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



-- 
Surveillance is pervasive. Go Dark.
--------------010300020900050606080305-- From ron.even.tlv@gmail.com Fri Feb 7 14:18:38 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB81ACC8B; Fri, 7 Feb 2014 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5TgSQKsOO7k; Fri, 7 Feb 2014 14:18:36 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D02AB1A0449; Fri, 7 Feb 2014 14:18:35 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h14so1797303eaj.21 for ; Fri, 07 Feb 2014 14:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=UDSPHstb/HIR5WafqKWw3gjvxq+pbY2/rNzzVQgOmNY=; b=hdMzj+UhW/fwPOEy3SDTzgsDI92jL3koi/03eJRAl7I6lem7Glp2jDjfpjXFyqnkDo 9Nh1MHec+BTFad0z0qAgZR6j+h0CZtE4CJWK5TP3UAkQNjWFcIzFL1wc5xh558Ys40Wg LnJ9WrcLXEBP2iY/Ng9w98XlaiaxVayhsWUoaqk3Z62iDNRFCF2xvKYC2cR2597zoCUG sAoUSk5+Un2KjR/9drqwKdbwTUqM3uk5DBpSv4dlKuQp5qWk/9JERJyZI4lj1R+k7Wnc uEMcn8SirZF2p7VmlQ1q2SArA0m4A6zOHw4mTo2fMGkPU0Dea7n3johc4/AXIl2oMC/C V+cg== X-Received: by 10.14.127.72 with SMTP id c48mr19206358eei.16.1391811515219; Fri, 07 Feb 2014 14:18:35 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id o43sm21450686eef.12.2014.02.07.14.18.31 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Feb 2014 14:18:34 -0800 (PST) From: "Roni Even" To: , , Date: Sat, 8 Feb 2014 00:18:24 +0200 Message-ID: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E3_01CF2463.4CF91BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kUaZJHKi9Q4W3TB67kd3MihP7sA== Content-Language: en-us Cc: avt@ietf.org, draft-nandakumar-payload-sdp-max-video-resolution@tools.ietf.org Subject: [payload] Request for agenda time for payload - IETF89 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:18:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06E3_01CF2463.4CF91BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the IETF89 agenda: Please send the WG chairs requests for agenda time. payload Session Tuesday , afternoon session III 16:30 - 17:30 Room Name: Park Suite We intend to discuss the VP8 and H.265 open issues based on the mailing list discussion and would like to get feedback from the editors if they intend to present. Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool . * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_06E3_01CF2463.4CF91BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = IETF89 agenda:

 

Please send = the WG chairs requests for agenda time.

 

    payload Session Tuesday  , = afternoon session III 16:30 – 17:30

    Room Name: Park = Suite

 

    

We intend to discuss the VP8 and H.265 open issues = based on the mailing list discussion and would like to get feedback from = the editors if they intend to present.

  

Some important dates:

 

  • 2014-02-07 = (Friday): Final = agenda to be published.
  • 2014-02-14 = (Friday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 23:59, = upload using IETF ID Submission = Tool.
  • 2014-02-17 = (Monday): Draft = Working Group agendas due by UTC 23:59, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore chair

 

 

------=_NextPart_000_06E3_01CF2463.4CF91BF0-- From harald@alvestrand.no Mon Feb 10 11:47:08 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81A81A0863 for ; Mon, 10 Feb 2014 11:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfjjI30zb71d for ; Mon, 10 Feb 2014 11:47:05 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id EB33C1A01A8 for ; Mon, 10 Feb 2014 11:47:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 01E837C4BF9 for ; Mon, 10 Feb 2014 20:47:04 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13+h-VBqapLo for ; Mon, 10 Feb 2014 20:47:03 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 388697C4AA1 for ; Mon, 10 Feb 2014 20:47:03 +0100 (CET) Message-ID: <52F92CB4.20204@alvestrand.no> Date: Mon, 10 Feb 2014 20:47:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "payload@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [payload] VP8 agenda time request X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:47:09 -0000 I request 15 minutes on the PAYLOAD agenda in London to present updates to draft-ietf-vp8-payload (which will be submitted shortly). If draft-nandakumar-payload-sdp-max-video-resolution is going to be on the agenda, I request that draft-ietf-vp8-payload be scheduled after that item. Harald Alvestrand -- Surveillance is pervasive. Go Dark. From harald@alvestrand.no Mon Feb 10 11:47:47 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A61A03C9 for ; Mon, 10 Feb 2014 11:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXddn_cgUxR8 for ; Mon, 10 Feb 2014 11:47:45 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 43A881A01A8 for ; Mon, 10 Feb 2014 11:47:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B8CCC7C4BF9 for ; Mon, 10 Feb 2014 20:47:44 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEp5gNeH3Hta for ; Mon, 10 Feb 2014 20:47:44 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 13CD67C4AA1 for ; Mon, 10 Feb 2014 20:47:43 +0100 (CET) Message-ID: <52F92CDE.1090507@alvestrand.no> Date: Mon, 10 Feb 2014 20:47:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050806010208040106030001" Subject: Re: [payload] RTP payload format specification for VP9? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:47:47 -0000 This is a multi-part message in MIME format. --------------050806010208040106030001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/17/2014 01:31 AM, Ross Finlayson wrote: > VP9 has been getting some buzz recently (as an alternative to H.265 as > a codec for '4K Ultra HD'), but I don't recall seeing a RTP payload > format I-D for VP9. Does one exist? Or is this something that we can > expect soon? It will happen. No promises on target dates, though. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. --------------050806010208040106030001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/17/2014 01:31 AM, Ross Finlayson wrote:
VP9 has been getting some buzz recently (as an alternative to H.265 as a codec for '4K Ultra HD'), but I don't recall seeing a RTP payload format I-D for VP9.  Does one exist?  Or is this something that we can expect soon?

It will happen. No promises on target dates, though.



Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 



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



-- 
Surveillance is pervasive. Go Dark.
--------------050806010208040106030001-- From suhasietf@gmail.com Mon Feb 10 13:26:55 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3F1A05D2 for ; Mon, 10 Feb 2014 13:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRrJYP0JX7II for ; Mon, 10 Feb 2014 13:26:53 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51B1A0452 for ; Mon, 10 Feb 2014 13:26:52 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so3176226wib.5 for ; Mon, 10 Feb 2014 13:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JYYXWRl/upMtgWC+QW5i2pOexxeuw81yzL3DjpH/C2s=; b=i0lFF2dkSAxpu00NzFi4vDl4qu1QIGlH7/iVvcFcMIJm6bJJsIp5InX1EXN2bn1gN3 GHKWQCnkbZu0VPj26nB5CjTqDWznsPjiuxzRbGtSyxeZqPmejTZ8qvQ3/3qOPPztgAlc Fi0lg5y/9K836mdKgeNXkFgH9gt9VZLQauj5oV66z1ud5Rb5l3HDdimP6Kp8FrM5oY4h E81SlpzxKqpc9CuXv1qsujzhzEHAWpBPKsuEjYAdTNCA+ENP6cnMaz7q+zdLWXKOnSbW Ij9AA4lu1T0zOu6c61ByEebJ1hX1GJ+GY6MBHBNjURzpiYv9TSIcpF1EKH10k0+fqEHC b2YA== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr7450636wjq.40.1392067612336; Mon, 10 Feb 2014 13:26:52 -0800 (PST) Received: by 10.195.12.134 with HTTP; Mon, 10 Feb 2014 13:26:52 -0800 (PST) In-Reply-To: <52F92CB4.20204@alvestrand.no> References: <52F92CB4.20204@alvestrand.no> Date: Mon, 10 Feb 2014 13:26:52 -0800 Message-ID: From: Suhas Nandakumar To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b86e9ca89681c04f213ff34 Cc: "payload@ietf.org" Subject: Re: [payload] VP8 agenda time request X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:26:55 -0000 --047d7b86e9ca89681c04f213ff34 Content-Type: text/plain; charset=ISO-8859-1 Hello Harald I have re On Mon, Feb 10, 2014 at 11:47 AM, Harald Alvestrand wrote: > I request 15 minutes on the PAYLOAD agenda in London to present updates > to draft-ietf-vp8-payload (which will be submitted shortly). > > If draft-nandakumar-payload-sdp-max-video-resolution is going to be on > the agenda, I request that draft-ietf-vp8-payload be scheduled after > that item. > > Harald Alvestrand > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --047d7b86e9ca89681c04f213ff34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Harald

=A0 I have re
<= div class=3D"gmail_extra">

On Mon, Feb 10= , 2014 at 11:47 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
I request 15 minutes on the PAYLOAD agenda i= n London to present updates
to draft-ietf-vp8-payload (which will be submitted shortly).

If draft-nandakumar-payload-sdp-max-video-resolution is going to be on
the agenda, I request that draft-ietf-vp8-payload be scheduled after
that item.

Harald Alvestrand

--
Surveillance is pervasive. Go Dark.

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

--047d7b86e9ca89681c04f213ff34-- From suhasietf@gmail.com Mon Feb 10 13:28:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0171A06FD for ; Mon, 10 Feb 2014 13:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfD98IxOawBc for ; Mon, 10 Feb 2014 13:28:16 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 892C31A0452 for ; Mon, 10 Feb 2014 13:28:16 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so4543724wes.26 for ; Mon, 10 Feb 2014 13:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jrjD9XWg7MDCxjtdTxwUtQMAr8XJv3S7SoOt52Eehjw=; b=vdVXf9O6+afWy5bWSwnT4Mgmvrn7VIXxf7P0A81ZmvanEUo5wrZ4usyxq3OhykkzY+ Uh/Mt8kp2xl9krHUlwsS6aCj5Ys+Hq3Ga1AbVWB0kLTpE3TNcDvobaIrbsdORCd1iVfd QPjopS2R+qrrbhdKLlLwVh52nVuRBqNon0JesRcMelvv6yuX9T3waoggL1XAjRAQORCZ zpTpeIIZspVqeF95bsGbFPAJ2P79EoAOgvHwFhEeSwOMOptcIQv42eB81J4llJ7k/Adk JjGyMYqbc8ajjj/ChMFCblqyz1dBgSuLwyKTSAgkIX2JxMniXpDD59fA8S8+LRgu++Rk cKXA== MIME-Version: 1.0 X-Received: by 10.194.92.7 with SMTP id ci7mr3283127wjb.58.1392067695839; Mon, 10 Feb 2014 13:28:15 -0800 (PST) Received: by 10.195.12.134 with HTTP; Mon, 10 Feb 2014 13:28:15 -0800 (PST) In-Reply-To: References: <52F92CB4.20204@alvestrand.no> Date: Mon, 10 Feb 2014 13:28:15 -0800 Message-ID: From: Suhas Nandakumar To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e01494602838f4d04f2140413 Cc: "payload@ietf.org" Subject: Re: [payload] VP8 agenda time request X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:28:18 -0000 --089e01494602838f4d04f2140413 Content-Type: text/plain; charset=ISO-8859-1 Hello Harald I have requested for a presentation slot on draft-nandakumar-payload-sdp- max-video-resolution. Thanks Suhas On Mon, Feb 10, 2014 at 1:26 PM, Suhas Nandakumar wrote: > Hello Harald > > I have re > > > On Mon, Feb 10, 2014 at 11:47 AM, Harald Alvestrand wrote: > >> I request 15 minutes on the PAYLOAD agenda in London to present updates >> to draft-ietf-vp8-payload (which will be submitted shortly). >> >> If draft-nandakumar-payload-sdp-max-video-resolution is going to be on >> the agenda, I request that draft-ietf-vp8-payload be scheduled after >> that item. >> >> Harald Alvestrand >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > --089e01494602838f4d04f2140413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Harald

=A0 =A0I have requested fo= r a presentation slot on=A0draft-nandakumar-payload-sdp-max-video-resolution.

Tha= nks
Suhas


On Mon,= Feb 10, 2014 at 1:26 PM, Suhas Nandakumar <suhasietf@gmail.com><= /span> wrote:
Hello Harald

=
=A0 I have re


On Mon, Feb 10, 2014 at 11:47 AM, Harald= Alvestrand <harald@alvestrand.no> wrote:
I request 15 minutes on the PAYLOAD agenda i= n London to present updates
to draft-ietf-vp8-payload (which will be submitted shortly).

If draft-nandakumar-payload-sdp-max-video-resolution is going to be on
the agenda, I request that draft-ietf-vp8-payload be scheduled after
that item.

Harald Alvestrand

--
Surveillance is pervasive. Go Dark.

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


--089e01494602838f4d04f2140413-- From internet-drafts@ietf.org Mon Feb 10 13:57:25 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA481A088B; Mon, 10 Feb 2014 13:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNGPHDuKg1px; Mon, 10 Feb 2014 13:57:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 165C11A06FD; Mon, 10 Feb 2014 13:57:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210215724.3826.23837.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 13:57:24 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:57:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-11.txt Pages : 30 Date : 2014-02-10 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Mon Feb 10 14:27:08 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183FA1A05F2 for ; Mon, 10 Feb 2014 14:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U36-wHYQnwte for ; Mon, 10 Feb 2014 14:27:05 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 216D61A0447 for ; Mon, 10 Feb 2014 14:27:04 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id l9so2815812eaj.3 for ; Mon, 10 Feb 2014 14:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=vtrDqf3oDuEcfExqkRZE5HTvu4YOhiTG3TMixFqtgG0=; b=TicfEC0B3UQ+IAFps4aLH6qKsnHWEnt5N64APojpQ7MEha3HIiv3+Up5Dpf+GUZ0ob 4WdEp6aDNSXUFhEGDjsO71LmZXluFam40DDZUeg0pO+fYkzSyYZwiMhhXcKrSryBFSA8 BMVrvL0kZV6hd3BxXfmjGfjONkGa5DmkltwVGckCJe9KZ4ieWtJaeyh2xXfXkLHp5uHu hD3ERzUdPKVOsBt/VB4lYaTe4VgUmOebxoiMjDHcB6Bl9ZNDQ5CuFCAFBigH8DEi3MEN JYoc8WU/ABxJfRve+tc0q9lOeJ+oqOrJkiSSr1dePL50wYcBCVe5e50uOOsALnkS0CYp VU8w== X-Received: by 10.14.183.132 with SMTP id q4mr3511321eem.91.1392071189459; Mon, 10 Feb 2014 14:26:29 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id j41sm59643290eeg.10.2014.02.10.14.26.27 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Feb 2014 14:26:28 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , References: <52F92CB4.20204@alvestrand.no> In-Reply-To: <52F92CB4.20204@alvestrand.no> Date: Tue, 11 Feb 2014 00:26:19 +0200 Message-ID: <089801cf26af$21346d50$639d47f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/bTrfyCYySEt3cG0E0uI8HOv2SZrOg5ug Content-Language: en-us Subject: Re: [payload] VP8 agenda time request X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:27:08 -0000 Hi Harald, OK, I will prepare the agenda accordingly Roni > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: 10 February, 2014 9:47 PM > To: payload@ietf.org > Subject: [payload] VP8 agenda time request > > I request 15 minutes on the PAYLOAD agenda in London to present updates to > draft-ietf-vp8-payload (which will be submitted shortly). > > If draft-nandakumar-payload-sdp-max-video-resolution is going to be on the > agenda, I request that draft-ietf-vp8-payload be scheduled after that item. > > Harald Alvestrand > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From snandaku@cisco.com Mon Feb 10 09:59:54 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9A1A0402; Mon, 10 Feb 2014 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYm2rn2uI3cU; Mon, 10 Feb 2014 09:59:52 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A3D111A0386; Mon, 10 Feb 2014 09:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7616; q=dns/txt; s=iport; t=1392055192; x=1393264792; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZQpzpSw1SDKPJwIIem30llvKbs0P5Yiy7uRKFPl0wR0=; b=ZOa2Jxm8JvM1rY8vIpXSXYIftUBSxLNpDkqS4SyBI6Om2bQLytmDkXdO 2TblptxQ8Z/riOlTGmUHkhIgP3bvxgRqPwJ0CLa7apsQZ4MeiqAzR01bT FYP5LAtPOMwsY/u+fIR5tIqciDgLh6B06eUUTqrih7lCIOpNr+UqAX31F k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHES+VKtJV2d/2dsb2JhbABZgkpEOFW9SYEUFgF0g30BAQEEbgsQAgEIDgMEAQELJCERHQgBAQQBDQUIh2gDEQ26KQ2HYhMEjH+BYi0EB4MjgRMEliuORYU6gyuCKg X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208,217";a="300060193" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 10 Feb 2014 17:59:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AHxqbX019671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 17:59:52 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.234]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 11:59:52 -0600 From: "Suhas Nandakumar (snandaku)" To: Roni Even , "payload@ietf.org" Thread-Topic: Request for agenda time for payload - IETF89 Thread-Index: Ac8kUaZJHKi9Q4W3TB67kd3MihP7sACOA1cw Date: Mon, 10 Feb 2014 17:59:52 +0000 Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D07AC66@xmb-aln-x12.cisco.com> References: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> In-Reply-To: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.99] Content-Type: multipart/alternative; boundary="_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Feb 2014 14:28:26 -0800 Cc: "avt@ietf.org" Subject: Re: [payload] Request for agenda time for payload - IETF89 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:59:54 -0000 --_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Roni I would like to request a 25 mins slot to discuss draft-nandakumar-payl= oad-sdp-max-video-resolution. Please let me know your thoughts Cheers Suhas ________________________________ From: Roni Even [ron.even.tlv@gmail.com] Sent: Friday, February 07, 2014 2:18 PM To: payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.org; draft-ietf-pay= load-rtp-h265@tools.ietf.org Cc: Ali C. Begen (abegen); avt@ietf.org; draft-nandakumar-payload-sdp-max-v= ideo-resolution@tools.ietf.org Subject: Request for agenda time for payload - IETF89 Hi, This is the IETF89 agenda: Please send the WG chairs requests for agenda time. payload Session Tuesday , afternoon session III 16:30 =96 17:30 Room Name: Park Suite We intend to discuss the VP8 and H.265 open issues based on the mailing lis= t discussion and would like to get feedback from the editors if they intend= to present. Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59, upload using IETF ID Submission Tool. * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, up= load using IETF Meeting Materials Management Tool. Roni Even AVTcore chair --_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Roni

    I would like to request a 25 mins slot to discuss <= span style=3D"font-size: small;">draft-nandakumar-payload-sdp-max-video-res= olution.
 
   Please let me know your= thoughts
   
Cheers
Suhas
From: Roni Even [ron.even.tlv@gmail.com]<= br> Sent: Friday, February 07, 2014 2:18 PM
To: payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.org; draft-i= etf-payload-rtp-h265@tools.ietf.org
Cc: Ali C. Begen (abegen); avt@ietf.org; draft-nandakumar-payload-sd= p-max-video-resolution@tools.ietf.org
Subject: Request for agenda time for payload - IETF89

Hi,

This is the IETF89 agenda:

 

Please send the WG chairs requests for agenda time. =

 

    payload Session Tuesday  = , afternoon session III 16:30 =96 17:30

    Room Name: Park Suite

 

    

We intend to discuss the VP8 and H.265 open issue= s based on the mailing list discussion and would like to get feedback from = the editors if they intend to present.

  

Some important dates:

 

  • 2014-02-07 (Friday): Final agenda to be published.
  • 2014-02-14 (Friday):<= /strong> Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upl= oad using IETF ID Submission Tool= .
  • 2014-02-17 (Monday): = Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Managemen= t Tool.

 

Roni Even

AVTcore chair

 

 

--_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_-- From internet-drafts@ietf.org Wed Feb 12 09:46:59 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA751A0639; Wed, 12 Feb 2014 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qger3RTmbctI; Wed, 12 Feb 2014 09:46:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C251A09B4; Wed, 12 Feb 2014 09:46:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212174656.12507.10726.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 09:46:56 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:46:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-02.txt Pages : 83 Date : 2014-02-12 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC], developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yekuiw@qti.qualcomm.com Wed Feb 12 10:21:46 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F71A0635 for ; Wed, 12 Feb 2014 10:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94XVhdNWadz5 for ; Wed, 12 Feb 2014 10:21:44 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4F1A0502 for ; Wed, 12 Feb 2014 10:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1392229303; x=1423765303; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9DG+c7Hvcb7rw75dFwSQC1TM76Zv7JGyp7wYXGGmVyk=; b=HIJsax0JRpb/TDeujcreMX7Rs5AbRtBv1+M3r2tqkUH/2WgR4ESl5xjn KeSxMlvsA/N3ut0ad0P9A1IoiENlyG7kC98U0rvTLa0xt4yI4Dx9YmUAI uY74sMLFalUMSz/c6QxxHPoPDteUoKDGZLadoSpYRguyGeR182CQXgllP 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="59374974" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 12 Feb 2014 10:21:43 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="592678902" Received: from nasanexhc01.na.qualcomm.com ([172.30.48.25]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Feb 2014 10:21:44 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.244]) by NASANEXHC01.na.qualcomm.com ([172.30.48.25]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 10:21:43 -0800 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt Thread-Index: AQHPKBp+j67c7YpxuEiys14hXx4eIpqx519A Date: Wed, 12 Feb 2014 18:21:42 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833878D64E@nasanexd02f.na.qualcomm.com> References: <20140212174656.12507.10726.idtracker@ietfa.amsl.com> In-Reply-To: <20140212174656.12507.10726.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 18:21:46 -0000 Here is a summary of the changes compared to -01:=20 The authors have basically implemented topics that have been agreed at the = previous IETF meeting and on the reflector, plus other editorial reviews an= d improvements. A bit more in detail: - Integrated the temporal scalability support (as agreed in Vancouver, and = reflecting my comments on the reflector on 10/4/2013, and some other improv= ements by the authors of this draft) - Changed the term "RTP packet stream" to "RTP stream", and SST and MST now= stand for Single-Stream Transmission and Multi-Stream Transmission, respec= tively. - Added some definitions related to MST (e.g. dependent RTP stream etc.), a= nd added informative references to [I-D.ietf-avtcore-rtp-multi-stream] and = [I-D.ietf-mmusic-sdp-bundle-negotiation]. - Added that "Receivers MUST support both SST and MST" in section 4.4. - Removed tx-mode. - Removed the definition of the SPLI (specific picture loss indication) fee= dback message and the text on its use with HEVC. - Added some rules on parameter sets transmission, similar as but simpler t= han in RFC 6184. - Added details that were missing for some references. - Other editorial improvements. In my understanding, currently we have only two minor remaining open issues= , basically editorial, regarding the definition of MANE and the wording of = "NAL-unit-like structures", which I believe are not easy to resolve and pla= n to resolve a bit later. To me, the draft is mature enough to be WG-last-called, thus I'd request to= issue the WG last call soon. Thanks! BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, February 12, 2014 9:47 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-02.txt Pages : 83 Date : 2014-02-12 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC], developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From yekuiw@qti.qualcomm.com Wed Feb 12 10:57:21 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548601A0689 for ; Wed, 12 Feb 2014 10:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7fzdEaLUiX0 for ; Wed, 12 Feb 2014 10:57:16 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C9BA91A0676 for ; Wed, 12 Feb 2014 10:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1392231436; x=1423767436; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=lfoovgMLOktIwCd757/gBquC/oMQZUGIIQ1yGd+aznQ=; b=yjZkM1KpzSjSQgJqooSSt0hfr6V5tzqLaTwwXaISvWozyGhqEaFVpa9+ YusZUOpzmKTA13DhTjmRk4BUkp77QgZFLwCDyFHPE2EaBRV1UxI5xXeWk OXRZZHTKTaXv6E0uOt6BjyiMYwUtH28iimQ6EnR85NpVZl3KYxaK9xvdV 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="104649410" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 12 Feb 2014 10:57:16 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="592694141" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Feb 2014 10:57:15 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.244]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 10:57:15 -0800 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt Thread-Index: AQHPKBp+j67c7YpxuEiys14hXx4eIpqx519AgAAQcrA= Date: Wed, 12 Feb 2014 18:57:14 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833878D734@nasanexd02f.na.qualcomm.com> References: <20140212174656.12507.10726.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 18:57:21 -0000 Typo correction to the sentence below: "not easy" to "easy". In my understanding, currently we have only two minor remaining open issues= , basically editorial, regarding the definition of MANE and the wording of = "NAL-unit-like structures", which I believe are ***not easy*** to resolve a= nd plan to resolve a bit later. BR, YK -----Original Message----- From: Wang, Ye-Kui=20 Sent: Wednesday, February 12, 2014 10:22 AM To: payload@ietf.org Subject: RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt Here is a summary of the changes compared to -01:=20 The authors have basically implemented topics that have been agreed at the = previous IETF meeting and on the reflector, plus other editorial reviews an= d improvements. A bit more in detail: - Integrated the temporal scalability support (as agreed in Vancouver, and = reflecting my comments on the reflector on 10/4/2013, and some other improv= ements by the authors of this draft) - Changed the term "RTP packet stream" to "RTP stream", and SST and MST now= stand for Single-Stream Transmission and Multi-Stream Transmission, respec= tively. - Added some definitions related to MST (e.g. dependent RTP stream etc.), a= nd added informative references to [I-D.ietf-avtcore-rtp-multi-stream] and = [I-D.ietf-mmusic-sdp-bundle-negotiation]. - Added that "Receivers MUST support both SST and MST" in section 4.4. - Removed tx-mode. - Removed the definition of the SPLI (specific picture loss indication) fee= dback message and the text on its use with HEVC. - Added some rules on parameter sets transmission, similar as but simpler t= han in RFC 6184. - Added details that were missing for some references. - Other editorial improvements. In my understanding, currently we have only two minor remaining open issues= , basically editorial, regarding the definition of MANE and the wording of = "NAL-unit-like structures", which I believe are not easy to resolve and pla= n to resolve a bit later. To me, the draft is mature enough to be WG-last-called, thus I'd request to= issue the WG last call soon. Thanks! BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Wednesday, February 12, 2014 9:47 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-02.txt Pages : 83 Date : 2014-02-12 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC], developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Feb 13 10:21:17 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA4A1A03B1 for ; Thu, 13 Feb 2014 10:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHOC1TtdiQMN for ; Thu, 13 Feb 2014 10:21:15 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id B913A1A0376 for ; Thu, 13 Feb 2014 10:21:14 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u57so7755608wes.41 for ; Thu, 13 Feb 2014 10:21:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=wXeyCLu7nxHt3eSzG1AHw2wpSRJ2mK+xF105HZ1FXtg=; b=D2nJSZs/7iAiKAsoihLENac7CspQDGVVejTbjKYd1O6RVGo4zzqXx4u8CZtEZ6xiiD ZZcliFbTP+AUfeh1vXKQh1Ukq8FmrKmU822EMr/PRKmz/xK1gHPpXwUDvt3t2Ra7g0l0 vvcPYmmqmAB/3amBvZOeO/4zID/wXuSoeo7qzFuu/6dFjM3HEG5WEUDRfu7XcMSPVhk9 2VDp7c/Ous1XDp4ZF+zN1CDluUey0YM59rEgJRcTf6bOzsUwwr3CwNfZoAzQJw0ZiVTI eP54JZPlWspDa0Wys/nGvF/9EYt4xgrHrqeUGEtHwijXxRDyI07hjYAsBmnOOmOPHFAJ Jdwg== X-Gm-Message-State: ALoCoQm8jF63mtZ+ARYdrmQbgrnThptq6JvFU6kYe+MrPCJcCdg/XJSfjxcyvof/fg+qiaJfGPdr X-Received: by 10.180.73.173 with SMTP id m13mr7635978wiv.52.1392315672955; Thu, 13 Feb 2014 10:21:12 -0800 (PST) Received: from macbook-pro.u-strasbg.fr (mininet.u-strasbg.fr. [130.79.91.162]) by mx.google.com with ESMTPSA id br10sm6431077wjb.3.2014.02.13.10.21.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 10:21:12 -0800 (PST) Sender: Boris Grozev Message-ID: <52FD0D17.8010404@jitsi.org> Date: Thu, 13 Feb 2014 19:21:11 +0100 From: Boris Grozev User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: payload@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/9f5igURjETHO_14GOgwzpTItkvM Subject: [payload] A small technical note about draft-ietf-payload-vp8-11 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:21:16 -0000 Hello, In all diagrams in sections 4.6.1., 4.6.3. and 4.6.4. the PictureID field has value "0001001" (9 in decimal), but the text to the right says "PictureID = 17". Regards, Boris From nobody Thu Feb 13 16:15:06 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1A01A03ED for ; Thu, 13 Feb 2014 16:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwGo1N4zrwyc for ; Thu, 13 Feb 2014 16:15:02 -0800 (PST) Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AECED1A0421 for ; Thu, 13 Feb 2014 16:14:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E986D7C4CC9; Fri, 14 Feb 2014 01:14:57 +0100 (CET) Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8AqspdkKHpn; Fri, 14 Feb 2014 01:14:57 +0100 (CET) Received: from [172.19.7.138] (unknown [216.239.45.74]) by mork.alvestrand.no (Postfix) with ESMTPSA id DCCAB7C0929; Fri, 14 Feb 2014 01:14:56 +0100 (CET) Message-ID: <52FD5FFE.5040204@alvestrand.no> Date: Fri, 14 Feb 2014 01:14:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Boris Grozev , payload@ietf.org References: <52FD0D17.8010404@jitsi.org> In-Reply-To: <52FD0D17.8010404@jitsi.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/lKb8iJlrgb02DC5tLYkoh-mW7Sg Subject: Re: [payload] A small technical note about draft-ietf-payload-vp8-11 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:15:04 -0000 On 02/13/2014 07:21 PM, Boris Grozev wrote: > Hello, > > In all diagrams in sections 4.6.1., 4.6.3. and 4.6.4. the PictureID > field has value "0001001" (9 in decimal), but the text to the right says > "PictureID = 17". I think you're right. We'll fix that. > > > Regards, > Boris > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. From nobody Mon Feb 17 01:28:05 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E921A008E; Mon, 17 Feb 2014 01:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXESMilIpe_s; Mon, 17 Feb 2014 01:28:01 -0800 (PST) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C68591A0394; Mon, 17 Feb 2014 01:28:00 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id l9so6411472eaj.17 for ; Mon, 17 Feb 2014 01:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=k4CmKQuxlImQRxu1NNXDzGlQlCBt3yhnsMc/n2ojtxw=; b=RrnM6JaVfQLJM3ewds8d+OcfRzkragPf7SRf9DhtTu9EmVEJqxO2KipIRMDbvw7gxh XTFcxxnLlV726mCjb3nW424foN8F1C0/OviKfRTfhmZ4NAlSqy/S6/2YhnbUYNCJN0/F hZxfJtCJXnAYGDl3Kuoba9UFgYTET7EjCSTl6VT8kiXDJFJ3Tx1xD9kcjLH8Q2nKLzWD 7g7eNh/fEHtf6soLmAw7VvUPxRbXQ04TWvjajKtuv/2loxpMmOnEmG1xX9DSffmPgJIf UtiL6iCHLO/DXtBXtjkGa7LqjLFAQ/qfmPfSZGeN7CiOZCvWRPkD1zpLBSNcRfO7aRyB oAEw== X-Received: by 10.14.1.68 with SMTP id 44mr26813776eec.0.1392629277901; Mon, 17 Feb 2014 01:27:57 -0800 (PST) Received: from RoniE ([109.67.98.212]) by mx.google.com with ESMTPSA id x6sm55227735eew.20.2014.02.17.01.27.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Feb 2014 01:27:57 -0800 (PST) From: "Roni Even" To: Date: Mon, 17 Feb 2014 11:27:51 +0200 Message-ID: <023501cf2bc2$8af6beb0$a0e43c10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0236_01CF2BD3.4E7FDCD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8rwodvQck7U8IZSYq8DBBnmX1Z0A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/u1O5PEyL72mh4SArMQMEQvhQ6aE Cc: avt@ietf.org Subject: [payload] Payload WG agenda for IETF89 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:28:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0236_01CF2BD3.4E7FDCD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the proposed agenda for IETF89 Posted also to AVTcore . Any comments Roni Even ------=_NextPart_000_0236_01CF2BD3.4E7FDCD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = proposed agenda for IETF89

Posted = also to AVTcore .

Any = comments

Roni Even

 

------=_NextPart_000_0236_01CF2BD3.4E7FDCD0-- From nobody Mon Feb 17 01:50:13 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052591A03C5; Mon, 17 Feb 2014 01:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.78 X-Spam-Level: X-Spam-Status: No, score=-0.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_OUTLOOK_TAGS=0.052, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh86ClrUYurl; Mon, 17 Feb 2014 01:50:08 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 22C9B1A0118; Mon, 17 Feb 2014 01:50:07 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id e53so6891476eek.41 for ; Mon, 17 Feb 2014 01:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=6sN2NmE1eteMTNFYhN37UFQBPnIYDoL1qlRbqX/B+C8=; b=E9KmU3YL+mfpexwFp8hMqzF1c4Mz+tpfLerkXK69mNSYmnGylEqUqjwI8ybXdUwcnQ P/Us3ceUPfnbhdzKyF7kJadwvCAL/SOZDJ+AyKETdWIz6p5KKCQ1GLk8mJaRIZk/qqqb WmYH2AtcsH2UBXm+QvFxquDIAejVwncwHFbEAis3bNkypfeUQ2lhhfLe0iMynAIfobMM ivG0S9l2JgAbdc/zkR4ybTiJq5KY6P0iTTm4L/97PS8HCXz846+kJF137q3dxGOxsruf 4RFzyHS4GWRwlDBgJxGYJv1zDM3RO7pSstcACQN7E1AAIc0z42U7xQdPkhlf3/uG+BaM ZyBQ== X-Received: by 10.14.29.6 with SMTP id h6mr1078921eea.84.1392630604963; Mon, 17 Feb 2014 01:50:04 -0800 (PST) Received: from RoniE ([109.67.98.212]) by mx.google.com with ESMTPSA id q44sm55327242eez.1.2014.02.17.01.50.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Feb 2014 01:50:04 -0800 (PST) From: "Roni Even" To: Date: Mon, 17 Feb 2014 11:49:58 +0200 Message-ID: <023a01cf2bc5$a1c88b20$e559a160$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_023B_01CF2BD6.6551D050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8rxZ6gZZEKnBS2SlCt5JqfNN1naA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/NxzIFlMvIrmxImpmpnjT8AO2md4 Cc: avt@ietf.org Subject: [payload] Payload WG agenda for IETF89 - this time with the agenda X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:50:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023B_01CF2BD6.6551D050 Content-Type: multipart/alternative; boundary="----=_NextPart_001_023C_01CF2BD6.6551D050" ------=_NextPart_001_023C_01CF2BD6.6551D050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the proposed agenda for IETF89 Posted also to AVTcore . Any comments Roni Even ------=_NextPart_001_023C_01CF2BD6.6551D050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = proposed agenda for IETF89

Posted = also to AVTcore .

Any = comments

Roni Even

 

------=_NextPart_001_023C_01CF2BD6.6551D050-- ------=_NextPart_000_023B_01CF2BD6.6551D050 Content-Type: text/html; name="p1403.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1403.html" Audio/Video Transport Payloads (Payload) Working Group = Agenda

Audio/Video Transport Payloads (Payload) = Working Group Agenda

Chairs: Ali Begen , Roni Even =

Wednesday, 5 March 2014 at 16:30-17:30 (Park Suite)

16:30 Payload Status UpdateChairs
16:40 Payload specific parameters for specifying video = resolution in SDPSuhas Nandakumar
draft-nandakumar-payload-sdp-max-video-resolution-00
17:05 RTP Payload Format for VP8 VideoHarald Alvestrand
draft-ietf-pa= yload-vp8-11
17:20 RTP Payload Format for High Efficiency Video = CodingStephan Wenger=20
draft-ie= tf-payload-rtp-h265-02
17:30 End
------=_NextPart_000_023B_01CF2BD6.6551D050 Content-Type: text/plain; name="p1403.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="p1403.txt" Audio/Video Transport Payloads (Payload) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D CHAIRS: Ali Begen Roni Even AGENDA Wednesday, 5 March 2014 at 16:30-17:30 (Park Suite) --------------------------------------------------- 16:30 Payload Status Update (Chairs, 10) 16:40 Payload specific parameters for specifying video resolution in = SDP (Suhas Nandakumar, 25) draft-nandakumar-payload-sdp-max-video-resolution-00 17:05 RTP Payload Format for VP8 Video (Harald Alvestrand, 15) draft-ietf-payload-vp8-11 17:20 RTP Payload Format for High Efficiency Video Coding (Stephan = Wenger , 10) draft-ietf-payload-rtp-h265-02 17:30 End ------=_NextPart_000_023B_01CF2BD6.6551D050-- From nobody Tue Feb 25 08:34:11 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3B31A0099 for ; Tue, 25 Feb 2014 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3HdelvpAUzm for ; Tue, 25 Feb 2014 08:34:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 03B711A0056 for ; Tue, 25 Feb 2014 08:34:07 -0800 (PST) Received: from localhost ([127.0.0.1]:46699 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WIKxA-00064y-VV; Tue, 25 Feb 2014 17:33:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com X-Trac-Project: payload Date: Tue, 25 Feb 2014 16:33:56 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/9 Message-ID: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/feD5V6qzyHtt9CSAa3jIbBHjLIE Cc: payload@ietf.org Subject: [payload] #9 (rtp-h265): Empty FUs X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 16:34:10 -0000 #9: Empty FUs The draft says: "An FU payload MAY have any number of octets and MAY be empty." with the motivation: "If zero-length FU payloads were not allowed, the sender would have to generate at least one bit of data of the following fragment of the NAL unit before the current FU could be sent. Due to the characteristics of HEVC, where sometimes several CTUs occupy zero bits." While it is true that several CTUs may occupy zero bits, the last CTU of a slice segment will always occupy at least one byte (containing the rbsp_stop_one_bit) so I don't really see in which situation you would end up with the need to send an empty FU. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From nobody Tue Feb 25 08:38:13 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA721A046A for ; Tue, 25 Feb 2014 08:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxtxCLmRB-LE for ; Tue, 25 Feb 2014 08:38:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E13DC1A0794 for ; Tue, 25 Feb 2014 08:38:08 -0800 (PST) Received: from localhost ([127.0.0.1]:46844 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WIL17-0001tj-LL; Tue, 25 Feb 2014 17:38:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com X-Trac-Project: payload Date: Tue, 25 Feb 2014 16:38:01 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/10 Message-ID: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/mRE61C8UFYcHIGDBXHTV7FMFN3Q Cc: payload@ietf.org Subject: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 16:38:10 -0000 #10: Marker bit in H.265/HEVC The draft says: " Marker bit (M): 1 bit Set for the last packet of the access unit indicated by the RTP timestamp, in line with the normal use of the M bit in video formats, to allow an efficient playout buffer handling. " However, in HEVC, in contrast to H.264, there may be SEI NAL units following the last VCL NAL unit in the access unit. (and those SEI NAL units are allowed to have higher TemporalId than the VCL NAL units). A MANE that removes those SEI NAL units must therefore change the value of the marker bit in an earlier packet. One option would be to change to "Marker bit (M): 1 bit Set for the last packet of the picture (i.e. the packet containing the last VCL NAL unit of a picture).." but that would of course have other implications. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From nobody Tue Feb 25 08:46:31 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569F41A07CD for ; Tue, 25 Feb 2014 08:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRwIFp8jJQr0 for ; Tue, 25 Feb 2014 08:46:28 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A09151A07D0 for ; Tue, 25 Feb 2014 08:46:22 -0800 (PST) Received: from localhost ([127.0.0.1]:47134 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WIL92-0003mR-Mh; Tue, 25 Feb 2014 17:46:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com X-Trac-Project: payload Date: Tue, 25 Feb 2014 16:46:12 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/11 Message-ID: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/PRTkfNy2RaWpTARXGwtS95c9Sd4 Cc: payload@ietf.org Subject: [payload] #11 (rtp-h265): Slice based parallelism X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 16:46:30 -0000 #11: Slice based parallelism The sentence "This payload format does not contain any specific mechanisms aiding parallelization through slices." is a bit misleading since sprop- spatial-segmentation-idc can be used for wave-front parallel processing or tiles or slices. A solution would be to simply remove that sentence. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From nobody Tue Feb 25 08:48:07 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B241A07A4 for ; Tue, 25 Feb 2014 08:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OdGjIAmehof for ; Tue, 25 Feb 2014 08:48:03 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 751061A046A for ; Tue, 25 Feb 2014 08:48:03 -0800 (PST) Received: from localhost ([127.0.0.1]:47241 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WILAg-0003wx-Fv; Tue, 25 Feb 2014 17:47:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com X-Trac-Project: payload Date: Tue, 25 Feb 2014 16:47:54 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/12 Message-ID: <073.9a10eef9226b457d03d45e1954dcbb0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, jonatan.samuelsson@ericsson.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Jw8-U1g0hQr0onY87vz_N0CgbWU Cc: payload@ietf.org Subject: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 16:48:05 -0000 #12: The max-fps parameter The parameter max-fps breaks the fundamental design principle that a receiver shall be capable of decoding all bitstreams that conforms to the level indicated by level-id. All other receiver capabilities express things a receiver is capable of in addition to the indicated level (max- br, max-cpb, etc). I do not see why there would be motivation to break this design principle for this specific case. An option would be to let max-fps be an indicative parameter specifying what is the maximum fps a receiver is capable of displaying. I.e. to indicate that even though the receiver can decode all bitstream conforming to the level it might not have rendering and/or display capabilities to display all decoded pictures (and thus only a subset of the decoded pictures will be displayed). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 11:35:50 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D081A0700; Wed, 26 Feb 2014 09:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-_r3rYGxQ8E; Wed, 26 Feb 2014 09:30:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE991A01EB; Wed, 26 Feb 2014 09:30:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: yekuiw@qti.qualcomm.com, yago.sanchez@hhi.fraunhofer.de, ts@thomas-schierl.de, stewe@stewe.org, miska.hannuksela@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226173012.13778.82041.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 09:30:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/0Dibd2aYG2tpfnIwfCoukqVZhdU X-Mailman-Approved-At: Wed, 26 Feb 2014 11:35:46 -0800 Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 17:30:16 -0000 Dear Ye-Kui Wang, Yago Sanchez, Thomas Schierl, Stephan Wenger, Miska M. Hannuksela: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Payload Format for High Efficiency Video Coding" (draft-ietf-payload-rtp-h265) was submitted to the IETF Secretariat on 2014-02-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2321/). The title of the IPR disclosure is "Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload- rtp-h265-02.""); The IETF Secretariat From nobody Wed Feb 26 13:48:52 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7061A072D for ; Wed, 26 Feb 2014 13:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMNZTLjC4o8c for ; Wed, 26 Feb 2014 13:48:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F71A072A for ; Wed, 26 Feb 2014 13:48:46 -0800 (PST) Received: from localhost ([127.0.0.1]:53112 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WImL0-0002Yw-Tp; Wed, 26 Feb 2014 22:48:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Wed, 26 Feb 2014 21:48:22 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/9#comment:1 Message-ID: <088.191a00719c93dd27a267a55ca1018703@trac.tools.ietf.org> References: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/-OZKv7C4GklNw_swJGgi2W0W-9Y Cc: payload@ietf.org Subject: Re: [payload] #9 (rtp-h265): Empty FUs X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:48:50 -0000 #9: Empty FUs Comment (by yekuiw@qti.qualcomm.com): Good catch. I think you are right. This was inherited from RFC 6184. After checking, it seems that the reason does not hold for H.264/AVC, either. I'd suggest that we disallow any FU to be empty. Unless otherwise concluded, I will include this change to the next version of the draft. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 13:56:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0551A02BC for ; Wed, 26 Feb 2014 13:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfqlrK2RD9Mi for ; Wed, 26 Feb 2014 13:56:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id 240751A02A7 for ; Wed, 26 Feb 2014 13:56:36 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by BY2PR07MB012.namprd07.prod.outlook.com (10.255.241.38) with Microsoft SMTP Server (TLS) id 15.0.883.10; Wed, 26 Feb 2014 21:56:31 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.94]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.94]) with mapi id 15.00.0888.003; Wed, 26 Feb 2014 21:56:30 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "yekuiw@qti.qualcomm.com" Thread-Topic: [payload] #9 (rtp-h265): Empty FUs Thread-Index: AQHPMkdlZsXeHyzuF0W8h1gr9khZxJrIFGEA//98JAA= Date: Wed, 26 Feb 2014 21:56:29 +0000 Message-ID: References: <073.2f1646ebe48edf0bc7d429596764d681@trac.tools.ietf.org> <088.191a00719c93dd27a267a55ca1018703@trac.tools.ietf.org> In-Reply-To: <088.191a00719c93dd27a267a55ca1018703@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(51704005)(47446002)(74502001)(31966008)(81686001)(87936001)(92726001)(74662001)(49866001)(85852003)(74366001)(94946001)(92566001)(79102001)(81342001)(81816001)(87266001)(94316002)(83072002)(2656002)(56816005)(4396001)(90146001)(47976001)(50986001)(76786001)(47736001)(74876001)(80022001)(65816001)(36756003)(85306002)(86362001)(46102001)(51856001)(80976001)(63696002)(95416001)(77982001)(59766001)(69226001)(54356001)(53806001)(76796001)(95666003)(81542001)(66066001)(56776001)(93136001)(77096001)(74706001)(54316002)(93516002)(76482001)(83322001)(19580405001)(19580395003)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR07MB012; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:A57661E6.8F3C87C3.81F21C49.8CD43E39.20193; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <128C4C3A5BF96D4D8F158937439D25CB@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/x9I6jCRgnyUGwEQpLc_ZQG4cfxU Cc: "payload@ietf.org" Subject: Re: [payload] #9 (rtp-h265): Empty FUs X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:56:38 -0000 Sounds good to me. Stephan On 26.2.14, 13:48, "payload issue tracker" wrote: >#9: Empty FUs > > >Comment (by yekuiw@qti.qualcomm.com): > > Good catch. I think you are right. This was inherited from RFC 6184. >After > checking, it seems that the reason does not hold for H.264/AVC, either. > > I'd suggest that we disallow any FU to be empty. Unless otherwise > concluded, I will include this change to the next version of the draft. > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: >Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL:=20 > >payload > From nobody Wed Feb 26 14:00:25 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E11A0275 for ; Wed, 26 Feb 2014 14:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G2eMfhlibwt for ; Wed, 26 Feb 2014 14:00:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEDF1A0717 for ; Wed, 26 Feb 2014 14:00:20 -0800 (PST) Received: from localhost ([127.0.0.1]:53704 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WImWR-0002tc-7O; Wed, 26 Feb 2014 23:00:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Wed, 26 Feb 2014 22:00:11 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/10#comment:1 Message-ID: <088.72059a18b7fb09c8a0a0ff85c74bd4fe@trac.tools.ietf.org> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/sWGWI1UburI6Tt4vgfUfD-GBCcQ Cc: payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 22:00:25 -0000 #10: Marker bit in H.265/HEVC Comment (by yekuiw@qti.qualcomm.com): Yes, change according to the suggestion to exclude non-VCL NAL unit would at least have an implication on the purpose of setting the marker bit, i.e. for playout buffer handling. I am hesitant to agree with this change due to this reason, though frankly I have not carefully checked how exactly the marker bit plays its role in playout buffer handling. Does anyone else have an opinion here? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 14:03:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73C41A072B for ; Wed, 26 Feb 2014 14:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi1e8Xjo56ig for ; Wed, 26 Feb 2014 14:03:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 923841A0718 for ; Wed, 26 Feb 2014 14:03:05 -0800 (PST) Received: from localhost ([127.0.0.1]:53799 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WImZ9-00077X-Ep; Wed, 26 Feb 2014 23:02:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Wed, 26 Feb 2014 22:02:59 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/11#comment:1 Message-ID: <088.e940f1db1a197b2574827ca5da855262@trac.tools.ietf.org> References: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/21MrAU03rMerxuAkn3NBXGoT1Sc Cc: payload@ietf.org Subject: Re: [payload] #11 (rtp-h265): Slice based parallelism X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 22:03:13 -0000 #11: Slice based parallelism Comment (by yekuiw@qti.qualcomm.com): Good catch again. After adding sprop-spatial-segmentation-idc, we did not check the earlier added summary sentence. Agree with removing the sentence. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 14:09:24 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688B71A074D for ; Wed, 26 Feb 2014 14:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olgFo1ULHPq5 for ; Wed, 26 Feb 2014 14:09:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BC1571A02BC for ; Wed, 26 Feb 2014 14:09:14 -0800 (PST) Received: from localhost ([127.0.0.1]:53991 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WImf3-000731-8P; Wed, 26 Feb 2014 23:09:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com X-Trac-Project: payload Date: Wed, 26 Feb 2014 22:09:05 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/12#comment:1 Message-ID: <088.289a000b536b0dc1bf248bf573458f09@trac.tools.ietf.org> References: <073.9a10eef9226b457d03d45e1954dcbb0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <073.9a10eef9226b457d03d45e1954dcbb0f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/FgjDg3NblG9_ZI0xIqx7vE55Et8 Cc: payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 22:09:18 -0000 #12: The max-fps parameter Comment (by yekuiw@qti.qualcomm.com): Yet another good catch. I agree. The wording should be clarified in the way to mention other processing such as rendering capabilities, but not that decoding of the picture rate is a problem. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 15:01:47 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E551A07F2 for ; Wed, 26 Feb 2014 15:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43FwNfB1ViPi for ; Wed, 26 Feb 2014 15:01:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD81A0749 for ; Wed, 26 Feb 2014 15:01:39 -0800 (PST) Received: from localhost ([127.0.0.1]:57171 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WInTk-00080C-Eh; Thu, 27 Feb 2014 00:01:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org X-Trac-Project: payload Date: Wed, 26 Feb 2014 23:01:28 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/10#comment:2 Message-ID: <088.46f9b218370e1461161770dd09bf3934@trac.tools.ietf.org> References: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <073.d3261c7320c6cd8879101a2e0938470c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/LOxEn5CAFmWG3G2-chV_6vkiQuU Cc: payload@ietf.org Subject: Re: [payload] #10 (rtp-h265): Marker bit in H.265/HEVC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:01:45 -0000 #10: Marker bit in H.265/HEVC Comment (by stewe@stewe.org): Yes, I do have an opinion. I would leave things as is normatively, but add a note with a warning. I believe what Jonatan is concerned about here is related to a somewhat exotic use case: (a) *very* low delay selective forwarding/thinning in a MANE wherein (b) one wants to forward a packet before all other packets of the same access unit (picture) have been received by the MANE and (c) wherein the post-picture SEI message(s) are packetized in their own packet(s), rather than being aggregated with a VCL NAL unit. A well-designed sender/encoder could trivially avoid the problem by placing the trailing SEI message(s) into an aggregation packet together with the final VCL NAL unit, at least assuming there is space left in the packet from an MTU viewpoint. Most SEI messages are small, so the likelihood is high. Further, extremely low delay systems typically have real-time encoders (why use an extremely low delay transmission path for pre-recorded content), so the encoder has a lot of control in what is going where in the packet stream. Even if all this were not the case, the MANE can still remain compliant by inserting some form of a dummy RTP packet containing a "throw away" NAL unit. For that, the filler data NAL unit (which is suffix, I believe) would be a perfect example. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Wed Feb 26 15:02:16 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CCD1A07E0 for ; Wed, 26 Feb 2014 15:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iomBdQsh7a7y for ; Wed, 26 Feb 2014 15:02:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 868011A0749 for ; Wed, 26 Feb 2014 15:02:05 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by BN1PR07MB006.namprd07.prod.outlook.com (10.255.225.36) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 26 Feb 2014 23:01:58 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.94]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.94]) with mapi id 15.00.0888.003; Wed, 26 Feb 2014 23:01:57 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "yekuiw@qti.qualcomm.com" Thread-Topic: [payload] #11 (rtp-h265): Slice based parallelism Thread-Index: AQHPMkkbqQzlOovQX0CY3PgmLxuz7JrIGHOA//+KVQA= Date: Wed, 26 Feb 2014 23:01:55 +0000 Message-ID: References: <073.190fe75f7dc50ed0aad91f7757cebd2e@trac.tools.ietf.org> <088.e940f1db1a197b2574827ca5da855262@trac.tools.ietf.org> In-Reply-To: <088.e940f1db1a197b2574827ca5da855262@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(24454002)(189002)(199002)(94946001)(81686001)(19580405001)(86362001)(83322001)(93516002)(74502001)(36756003)(80976001)(85852003)(95416001)(77096001)(19580395003)(92566001)(94316002)(31966008)(92726001)(85306002)(83072002)(66066001)(65816001)(80022001)(63696002)(93136001)(79102001)(59766001)(77982001)(74366001)(90146001)(76482001)(56816005)(49866001)(47736001)(47976001)(50986001)(56776001)(54356001)(81542001)(74706001)(76786001)(47446002)(76796001)(81342001)(87266001)(74662001)(51856001)(87936001)(46102001)(74876001)(53806001)(2656002)(69226001)(54316002)(81816001)(4396001)(95666003)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR07MB006; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:F47A41D6.8F3486C3.81621049.5CD4DE4D.2014F; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/DHkh4Lz6wfDu1VkVYyE_WjA_DPo Cc: "payload@ietf.org" Subject: Re: [payload] #11 (rtp-h265): Slice based parallelism X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:02:11 -0000 Agree also. S. On 26.2.14, 14:02, "payload issue tracker" wrote: >#11: Slice based parallelism > > >Comment (by yekuiw@qti.qualcomm.com): > > Good catch again. After adding sprop-spatial-segmentation-idc, we did not > check the earlier added summary sentence. Agree with removing the > sentence. > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: >Component: rtp-h265 | Version: 2.0 > Severity: - | Resolution: > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL:=20 > >payload > From nobody Wed Feb 26 15:05:26 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CB01A0881 for ; Wed, 26 Feb 2014 15:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtuHQz-RRrdC for ; Wed, 26 Feb 2014 15:05:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A2F261A0868 for ; Wed, 26 Feb 2014 15:05:15 -0800 (PST) Received: from localhost ([127.0.0.1]:57235 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WInXG-0008Rv-2T; Thu, 27 Feb 2014 00:05:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org X-Trac-Project: payload Date: Wed, 26 Feb 2014 23:05:06 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/12#comment:2 Message-ID: <088.47b751152462617fcf3275ddc14f4d8a@trac.tools.ietf.org> References: <073.9a10eef9226b457d03d45e1954dcbb0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <073.9a10eef9226b457d03d45e1954dcbb0f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, yekuiw@qti.qualcomm.com, stewe@stewe.org, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Y6I7hwWdU2pFKGsbf0U1jxyhHEo Cc: payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 23:05:20 -0000 #12: The max-fps parameter Comment (by stewe@stewe.org): Uh, no. Wasn't max_fps specifically introduced to indicate decoder performance points *outside* the level structure? For example, that one could signal the capability for decoding of a 4k picture, but only at frame rates of 4 fps (for still images). Anyone here form Tandberg/Cisco who has an opinion? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- jonatan.samuelsson@ericsson.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rtp-h265 | Version: 2.0 Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From nobody Thu Feb 27 02:18:32 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC10B1A0806 for ; Thu, 27 Feb 2014 02:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1P0WkQZ7B_K for ; Thu, 27 Feb 2014 02:18:28 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D01A080F for ; Thu, 27 Feb 2014 02:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2777; q=dns/txt; s=iport; t=1393496306; x=1394705906; h=from:to:subject:date:message-id:mime-version; bh=Rws8MvrBWSC1F3KHecaz8AG3cbGKsJQ6d6zzglTbSCU=; b=I8tXNsoKzrPJprdnc6qe5KMsq0vrBjvsqw0VgEhjxDFvDZ4VAqc1ZMzI XP2NuEA4fCXOh5Qy42XZy7Jz0sOkA93AVPM5DDhGvX43WyKglXeYo02w+ q6mA17Npie5am29iUsD70OVRb4zjLQhhwJlWUZD6+FizMrdIoGsJAglc5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAPYPD1OtJXG8/2dsb2JhbABagkJEgRLCIRZ0giyBCwEIBHQnBIgMmiewKheTEgSYOJIpgy2CKg X-IronPort-AV: E=Sophos;i="4.97,553,1389744000"; d="scan'208,217";a="306896986" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 27 Feb 2014 10:18:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1RAIQhl011454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 10:18:26 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.113]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 04:18:25 -0600 From: "Geir Sandbakken (geirsand)" To: "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/7flCDn/vQEuMFGb3bWwIkg== Date: Thu, 27 Feb 2014 10:18:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.61.107.91] Content-Type: multipart/alternative; boundary="_000_CF34CF7F78792geirsandciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/IIv-oyQVUidavRw52qxgFUWnK8M Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 10:18:30 -0000 --_000_CF34CF7F78792geirsandciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable #12: The max-fps parameter Lessons learned from video conferencing using H.264 showed that a lot of eq= uipment designed for 30 fps could not handle 60 fps even at sufficiently lo= w resolution. We do anticipate similar problems when moving towards 120 fps= in H.265. It might not be caused by limitations in the decoder itself, b= ut that the surrounding media pipeline will not have been properly tested f= or 120 fps before being put into the wild. If we don=92t allow for a code = point to be used by the =93restricted" equipment, it will be required by th= e =93flexible/proper=94 to include one. This is what happened with max-fps= in H.264 enabling higher frame rates compared to lowering them. Geir A --_000_CF34CF7F78792geirsandciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

#12: The max= -fps parameter

Lessons learned = from video conferencing using&= nbsp;H.264 showed that a lot of equ= ipment designed for 30 fps could not handle 6= 0 fps even at sufficiently low=  resolution. We do anticipate = similar problems when moving towards 120 fps in H.265.  It might not be caused by limitations in the decoder itself,  but tha= t the surrounding media pipeline will not have been properly tested for 120= fps before being put into the wild.  If we don=92t allow for a code p= oint to be used by the =93restricted" equipment, it will be required by the =93flexible/proper=94 to include one.  Thi= s is what happened with max-fps in H.264 enabling higher frame rates compar= ed to lowering them.

Geir A
--_000_CF34CF7F78792geirsandciscocom_-- From nobody Thu Feb 27 07:32:05 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BAC1A0300 for ; Thu, 27 Feb 2014 07:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t8E1tjI4mIb for ; Thu, 27 Feb 2014 07:32:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B83911A02E0 for ; Thu, 27 Feb 2014 07:32:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-44-530f5a6f8a56 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9E.D4.10875.F6A5F035; Thu, 27 Feb 2014 16:31:59 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.347.0; Thu, 27 Feb 2014 16:31:59 +0100 Message-ID: <530F5A6E.3040900@ericsson.com> Date: Thu, 27 Feb 2014 16:31:58 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Geir Sandbakken (geirsand)" , "payload@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rjc/ij/Y4Pc/bYsTRw6yW1y6eJbJ gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4dP0Ea8EBwYpdjTtZGhgn8XUxcnJICJhI TJ20gQ3CFpO4cG89mC0kcIhR4ud7wy5GLiB7OaPE8bPdjCAJXgFtiZ6ny1lAbBYBVYn5P3ey g9hsAhYSN380gjWLCgRL7DzwG6peUOLkzCdg9SICcRL9JxaDxYUFbCSaTqxghVimL9G/YD5Y nFPAQKJl2VOgORxAB4lL9DQGgYSZgcJHFs1hhbDlJZq3zmaGaNWWaGjqYJ3AKDgLybZZSFpm IWlZwMi8ipE9NzEzJ73ccBMjMCAPbvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamDMdfv3TfuliKzuwTlyZ/8HONjpbJW5WqZusLE1atYOfXuNppk3pPQ6 g/NU9/x2lW4ONbjYUfXU+pXxg8W1b1tXhH4KXPZlcuwPhyADL7/tTVLrNwdtmrX2/eFDG4Q4 V4hcKdj07U7C71eyV8N3n3rnsfC/4ZS+Wu7JWW6W9YXCa542l56euStEiaU4I9FQi7moOBEA 1RHiDhYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/RiHRaN1vkzRoB_wusIrR8x4imy0 Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:32:04 -0000 On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > #12: The max-fps parameter > > Lessons learned from video conferencing using H.264 showed that a lot of > equipment designed for 30 fps could not handle 60 fps even at > sufficiently low resolution. We do anticipate similar problems when > moving towards 120 fps in H.265. It might not be caused by limitations > in the decoder itself, but that the surrounding media pipeline will not > have been properly tested for 120 fps before being put into the wild. > If we don’t allow for a code point to be used by the “restricted" > equipment, it will be required by the “flexible/proper” to include one. > This is what happened with max-fps in H.264 enabling higher frame rates > compared to lowering them. > I do have concerns with defining a parameter that allow dynamically sub-setting the profile and levels that has been defined for HEVC. This can also create interoperability issues with any pre-encoded content to a particular profile and level. The issues with the media pipeline has they been with the reception of the high framerate of packets and forwarding them to the decoder or the playback part, i.e. handling of the decoded picture? If it is predominately the later it appears very reasonable to have this as an informative parameter. I will not make use of higher FPS than X, if you send me higher than X I will need to reduce that to X or lower before displaying it. That way we are not re-defining the profiles, we are ensuring that we can handle content encoded within the profile and still by taking care of the this in the end of your decoder chain you can protect the rest of the media framework from not yet supported frame-rates. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Feb 27 10:15:41 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B06C1A02DC for ; Thu, 27 Feb 2014 10:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyoCdRHKWanh for ; Thu, 27 Feb 2014 10:15:38 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DFEDD1A015A for ; Thu, 27 Feb 2014 10:15:37 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so1647663eek.13 for ; Thu, 27 Feb 2014 10:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=WG7Wo9j/I67/nVrcIYuD9GmBk6pgvPh2K9gxt0/yoOw=; b=dwl4Rj0X7/ZREeJ3AIZufqW7GvWVD3iebWfBrXaCgGAfYz91RiTwY99M3nVtvsxIjJ c6GyCknkwsJCtc3KVbj6+znhrbYg+dcj895bKrmQrGz3zGC0+K11vXpmONxgUctTESSd DBhRCtsv6iAPsqC2xdXXlQY8K/JngzM7UWbcymB76bODYzD+KiQKEwkSnAIJ3xSDFO43 W74tA57GhsKnWV5/Klw09AQvpIgoNKbaHktq3L/VTVmGeg50AxstCRG3lvMvp3xvgsBc iIwWyK2F7nqZuw2L9SQ24ADcDMIGlN9FFnt9rhZsy+NNo+Jh8CL9ukXSlsLaZH2xSaY0 /jDw== X-Received: by 10.15.111.130 with SMTP id cj2mr11008173eeb.102.1393524935865; Thu, 27 Feb 2014 10:15:35 -0800 (PST) Received: from RoniE ([109.67.98.212]) by mx.google.com with ESMTPSA id j41sm409914eeg.10.2014.02.27.10.15.33 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Feb 2014 10:15:35 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'Geir Sandbakken \(geirsand\)'" , References: <530F5A6E.3040900@ericsson.com> In-Reply-To: <530F5A6E.3040900@ericsson.com> Date: Thu, 27 Feb 2014 20:15:29 +0200 Message-ID: <0d5401cf33e7$e78811b0$b6983510$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLASZ3b75rOZkdYx7ipt5kjdNBc5QGok5gImNn3xMA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/WPitFx_TcpTG9CJkGV2Dqevv6rM Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:15:40 -0000 Hi Magnus, I am not sure that the level specifies the maximum fps. Roni > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 27 February, 2014 5:32 PM > To: Geir Sandbakken (geirsand); payload@ietf.org > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter >=20 > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > > #12: The max-fps parameter > > > > Lessons learned from video conferencing using H.264 showed that a = lot > > of equipment designed for 30 fps could not handle 60 fps even at > > sufficiently low resolution. We do anticipate similar problems when > > moving towards 120 fps in H.265. It might not be caused by > > limitations in the decoder itself, but that the surrounding media > > pipeline will not have been properly tested for 120 fps before being = put into > the wild. > > If we don=92t allow for a code point to be used by the = =93restricted" > > equipment, it will be required by the =93flexible/proper=94 to = include one. > > This is what happened with max-fps in H.264 enabling higher frame > > rates compared to lowering them. > > >=20 > I do have concerns with defining a parameter that allow dynamically = sub- > setting the profile and levels that has been defined for HEVC. This = can also > create interoperability issues with any pre-encoded content to a particular > profile and level. >=20 > The issues with the media pipeline has they been with the reception of = the high > framerate of packets and forwarding them to the decoder or the = playback part, > i.e. handling of the decoded picture? >=20 > If it is predominately the later it appears very reasonable to have = this as an > informative parameter. I will not make use of higher FPS than X, if = you send me > higher than X I will need to reduce that to X or lower before = displaying it. That > way we are not re-defining the profiles, we are ensuring that we can handle > content encoded within the profile and still by taking care of the = this in the end > of your decoder chain you can protect the rest of the media framework = from > not yet supported frame-rates. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Thu Feb 27 10:19:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3524D1A0163 for ; Thu, 27 Feb 2014 10:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zGT7bk8C_fj for ; Thu, 27 Feb 2014 10:19:40 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id C9A9A1A0115 for ; Thu, 27 Feb 2014 10:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393525179; x=1425061179; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ibtT5V+x4Ayjln6w0WZBytsNEydDlOUQo0c1CJ5FmB4=; b=BXgbOLKBQBUG9Aics7HimkaYo63zgcuzDWpBbfCh1hu/6E5FSATT4TLo TFuDLqU8NsHOcD/jS/0pn0yJpD9KjRWsmAoTuXaErTCyy03Aa0uDqMZ3Z t1UbpzCiiT4+34nor+m1zsMNNGxx/qw4S+Lie2Nntiq7hGbab9kR4+aYZ U=; X-IronPort-AV: E=McAfee;i="5400,1158,7362"; a="59968711" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 27 Feb 2014 10:19:39 -0800 X-IronPort-AV: E=Sophos;i="4.97,556,1389772800"; d="scan'208";a="624968415" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Feb 2014 10:19:39 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.03.0158.001; Thu, 27 Feb 2014 10:19:38 -0800 From: "Wang, Ye-Kui" To: Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/tQCfPN0v2EGxR7CgdZmQz5rJwOwA//+msXA= Date: Thu, 27 Feb 2014 18:19:38 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> In-Reply-To: <530F5A6E.3040900@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/BgY6bYYO0M__FcAhJ1xKLiN1gdU Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:19:43 -0000 I am with Magnus here. If a decoder cannot DECODE a picture rate allowed by= a level, then the decoder is not even a confirming decoder. We usually don= 't standardize mechanisms for non-confirming decoders, unless there is a ve= ry strong reason.=20 I think making the following changes (4 places in the first paragraph of th= e semantics) would resolve the issue, with conceptually good semantics, but= the use of the parameter is still practically the same. -----------------Start of the semantics, with suggested changes------------= -------------- max-fps: The value of max-fps is an integer indicating the maximum picture rate in u= nits of hundreds of pictures per second that can be efficiently received (*= **CHANGE TO "effectively processed by the receiver"***). The max-fps param= eter MAY be used to signal that the receiver has a constraint in that it is= not capable of decoding (***CHANGE TO "processing"***) video efficiently = (***CHANGE TO "effectively"***) at the full picture rate that is implied b= y the highest level and, when present, one or more of the parameters max-ls= r, max-lps, and max-br. The value of max-fps is not necessarily the picture rate at which the maxim= um picture size can be sent, it constitutes a constraint on maximum picture= rate for all resolutions. Informative note: The max-fps parameter is semantically different from max-= lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps = is used to signal a constraint, lowering the maximum picture rate from what= is implied by other parameters. The encoder MUST use a picture rate equal to or less than this value. In c= ases where the max-fps parameter is absent the encoder is free to choose an= y picture rate according to the highest level and any signaled optional par= ameters. -----------------End of the semantics, with suggested changes--------------= ------------ Please express your opinion if this is not acceptable to you.=20 BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Thursday, February 27, 2014 7:32 AM To: Geir Sandbakken (geirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > #12: The max-fps parameter >=20 > Lessons learned from video conferencing using H.264 showed that a lot=20 > of equipment designed for 30 fps could not handle 60 fps even at=20 > sufficiently low resolution. We do anticipate similar problems when=20 > moving towards 120 fps in H.265. It might not be caused by=20 > limitations in the decoder itself, but that the surrounding media=20 > pipeline will not have been properly tested for 120 fps before being put = into the wild. > If we don't allow for a code point to be used by the "restricted" > equipment, it will be required by the "flexible/proper" to include one.=20 > This is what happened with max-fps in H.264 enabling higher frame=20 > rates compared to lowering them. >=20 I do have concerns with defining a parameter that allow dynamically sub-set= ting the profile and levels that has been defined for HEVC. This can also c= reate interoperability issues with any pre-encoded content to a particular = profile and level. The issues with the media pipeline has they been with the reception of the = high framerate of packets and forwarding them to the decoder or the playbac= k part, i.e. handling of the decoded picture? If it is predominately the later it appears very reasonable to have this as= an informative parameter. I will not make use of higher FPS than X, if you= send me higher than X I will need to reduce that to X or lower before disp= laying it. That way we are not re-defining the profiles, we are ensuring th= at we can handle content encoded within the profile and still by taking car= e of the this in the end of your decoder chain you can protect the rest of = the media framework from not yet supported frame-rates. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Feb 27 10:23:03 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC691A0115 for ; Thu, 27 Feb 2014 10:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1SZ4QPq-vly for ; Thu, 27 Feb 2014 10:22:57 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 850321A00B8 for ; Thu, 27 Feb 2014 10:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393525376; x=1425061376; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=P8/hDIMdjhy3/sI8Is7GwT2qH4ZulwEUTj6wXuagKa0=; b=xvBe25Hny3MU3vfiR7+2ItWBHbYT7vEo5+fsX7UZJWH2WArL7y7i+zW7 rUOmeE38bG0q4XRgc556DCpfe2/8VBxg7kotNx6ExDzsAcmN5veGIFJqA c+Hdk6ZlTGsquGPuYWHFMhmPKMK+Q8NhLcRPesUumr7h8YeL9X51rG2HH U=; X-IronPort-AV: E=McAfee;i="5400,1158,7362"; a="107883057" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 27 Feb 2014 10:22:55 -0800 X-IronPort-AV: E=Sophos;i="4.97,556,1389772800"; d="scan'208";a="637377165" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Feb 2014 10:22:55 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.03.0158.001; Thu, 27 Feb 2014 10:22:55 -0800 From: "Wang, Ye-Kui" To: Roni Even , 'Magnus Westerlund' , "'Geir Sandbakken (geirsand)'" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/tQCfPN0v2EGxR7CgdZmQz5rJwOwAgAAtr4D//3sq8A== Date: Thu, 27 Feb 2014 18:22:55 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4EC@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> <0d5401cf33e7$e78811b0$b6983510$@gmail.com> In-Reply-To: <0d5401cf33e7$e78811b0$b6983510$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Us4_jFd3lznWv2KtHYzbzD-e5Q4 Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:23:01 -0000 Hi Roni, I sent the previous comment before seeing your below. The level specifies t= he max luma picture size and the max luma sample rate, which together deter= mine the picture rate (i.e. the max fps). BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, February 27, 2014 10:15 AM To: 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)'; payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter Hi Magnus, I am not sure that the level specifies the maximum fps. Roni > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus=20 > Westerlund > Sent: 27 February, 2014 5:32 PM > To: Geir Sandbakken (geirsand); payload@ietf.org > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter >=20 > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > > #12: The max-fps parameter > > > > Lessons learned from video conferencing using H.264 showed that a=20 > > lot of equipment designed for 30 fps could not handle 60 fps even at=20 > > sufficiently low resolution. We do anticipate similar problems when=20 > > moving towards 120 fps in H.265. It might not be caused by=20 > > limitations in the decoder itself, but that the surrounding media=20 > > pipeline will not have been properly tested for 120 fps before being=20 > > put into > the wild. > > If we don't allow for a code point to be used by the "restricted" > > equipment, it will be required by the "flexible/proper" to include one. > > This is what happened with max-fps in H.264 enabling higher frame=20 > > rates compared to lowering them. > > >=20 > I do have concerns with defining a parameter that allow dynamically=20 > sub- setting the profile and levels that has been defined for HEVC.=20 > This can also > create interoperability issues with any pre-encoded content to a particular > profile and level. >=20 > The issues with the media pipeline has they been with the reception of=20 > the high > framerate of packets and forwarding them to the decoder or the=20 > playback part, > i.e. handling of the decoded picture? >=20 > If it is predominately the later it appears very reasonable to have=20 > this as an > informative parameter. I will not make use of higher FPS than X, if=20 > you send me > higher than X I will need to reduce that to X or lower before=20 > displaying it. That > way we are not re-defining the profiles, we are ensuring that we can handle > content encoded within the profile and still by taking care of the=20 > this in the end > of your decoder chain you can protect the rest of the media framework=20 > from not yet supported frame-rates. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Feb 27 10:24:49 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B421A0163 for ; Thu, 27 Feb 2014 10:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAcQquB7je08 for ; Thu, 27 Feb 2014 10:24:38 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 15B901A037B for ; Thu, 27 Feb 2014 10:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393525476; x=1425061476; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JveRHrQzFUhxTnTHMZzEoC7YV1jtluGZ5uoCsmyHXvw=; b=MoA0FxhqWgZebtktVhBEuLFdDqdW9rqwyAmOZDK1mT8V0+lldd1gzv2R 6eewx8QFR3qX1uWwZ0esZNfgIVmXRK++AjO9IIUvK4x66wNbYQWgk0Pq/ sDfVU4rgC3hVdQISg7KwkZMXxfgrzN0GkspYl41pgonvTnF2hGCkCe/Aw U=; X-IronPort-AV: E=McAfee;i="5400,1158,7362"; a="59872214" Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 27 Feb 2014 10:24:36 -0800 X-IronPort-AV: E=Sophos;i="4.97,556,1389772800"; d="scan'208";a="691320475" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Feb 2014 10:24:36 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Feb 2014 10:24:36 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.03.0158.001; Thu, 27 Feb 2014 10:24:35 -0800 From: "Wang, Ye-Kui" To: Magnus Westerlund , "Geir Sandbakken (geirsand)" , "payload@ietf.org" Thread-Topic: [payload] #12 (rtp-h265): The max-fps parameter Thread-Index: AQHPM6U/tQCfPN0v2EGxR7CgdZmQz5rJwOwA//+msXCAAAM/sA== Date: Thu, 27 Feb 2014 18:24:35 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4FD@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Ok843VmAWf4XtGtxxamATQpF2LU Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:24:45 -0000 Typo: 4 places -> 3 places -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Thursday, February 27, 2014 10:20 AM To: Magnus Westerlund; Geir Sandbakken (geirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter I am with Magnus here. If a decoder cannot DECODE a picture rate allowed by= a level, then the decoder is not even a confirming decoder. We usually don= 't standardize mechanisms for non-confirming decoders, unless there is a ve= ry strong reason.=20 I think making the following changes (4 places in the first paragraph of th= e semantics) would resolve the issue, with conceptually good semantics, but= the use of the parameter is still practically the same. -----------------Start of the semantics, with suggested changes------------= -------------- max-fps: The value of max-fps is an integer indicating the maximum picture rate in u= nits of hundreds of pictures per second that can be efficiently received (*= **CHANGE TO "effectively processed by the receiver"***). The max-fps param= eter MAY be used to signal that the receiver has a constraint in that it is= not capable of decoding (***CHANGE TO "processing"***) video efficiently = (***CHANGE TO "effectively"***) at the full picture rate that is implied b= y the highest level and, when present, one or more of the parameters max-ls= r, max-lps, and max-br. The value of max-fps is not necessarily the picture rate at which the maxim= um picture size can be sent, it constitutes a constraint on maximum picture= rate for all resolutions. Informative note: The max-fps parameter is semantically different from max-= lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps = is used to signal a constraint, lowering the maximum picture rate from what= is implied by other parameters. The encoder MUST use a picture rate equal to or less than this value. In c= ases where the max-fps parameter is absent the encoder is free to choose an= y picture rate according to the highest level and any signaled optional par= ameters. -----------------End of the semantics, with suggested changes--------------= ------------ Please express your opinion if this is not acceptable to you.=20 BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Thursday, February 27, 2014 7:32 AM To: Geir Sandbakken (geirsand); payload@ietf.org Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > #12: The max-fps parameter >=20 > Lessons learned from video conferencing using H.264 showed that a lot=20 > of equipment designed for 30 fps could not handle 60 fps even at=20 > sufficiently low resolution. We do anticipate similar problems when=20 > moving towards 120 fps in H.265. It might not be caused by=20 > limitations in the decoder itself, but that the surrounding media=20 > pipeline will not have been properly tested for 120 fps before being put = into the wild. > If we don't allow for a code point to be used by the "restricted" > equipment, it will be required by the "flexible/proper" to include one.=20 > This is what happened with max-fps in H.264 enabling higher frame=20 > rates compared to lowering them. >=20 I do have concerns with defining a parameter that allow dynamically sub-set= ting the profile and levels that has been defined for HEVC. This can also c= reate interoperability issues with any pre-encoded content to a particular = profile and level. The issues with the media pipeline has they been with the reception of the = high framerate of packets and forwarding them to the decoder or the playbac= k part, i.e. handling of the decoded picture? If it is predominately the later it appears very reasonable to have this as= an informative parameter. I will not make use of higher FPS than X, if you= send me higher than X I will need to reduce that to X or lower before disp= laying it. That way we are not re-defining the profiles, we are ensuring th= at we can handle content encoded within the profile and still by taking car= e of the this in the end of your decoder chain you can protect the rest of = the media framework from not yet supported frame-rates. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Feb 27 14:30:34 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706BE1A0691 for ; Thu, 27 Feb 2014 14:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx-qOJI1TygT for ; Thu, 27 Feb 2014 14:30:30 -0800 (PST) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6C1A04F6 for ; Thu, 27 Feb 2014 14:30:29 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d17so1750148eek.18 for ; Thu, 27 Feb 2014 14:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=31JzModzzpWm2jAITX9nRekdFwVV8CadBGxG48JZf+s=; b=r/Y57Ru5f13RXdrLaIly6F4NEYnAmrq93KXT3WVr1Cx9Uj4Qfl2sdQ399WRgbnciAo t97vYKxlzPfUH3wOE1zPgu0kDvKrDmb14NgGHiOj0DzqvD9sDzbeA2mhmEAIZC8vBsgS JxbqDduhVNrf986FglWynnN8lF5T/bucnper/cKiP3ppQogjO5lT4O4W3QeEHGYGMhc9 ofU2QAv10tAdPBjaN12KXEDhYhbxrLu/jgH6ObsMZxk8qNb1kXsOInvOmDbHDWA9N4HM BpLoRVlhDeqlEz9Q20jMja6G0/xzeC8duCIazyqMeyhAywBcxPOTaumCG6jO6mZPxdM+ 7zaQ== X-Received: by 10.14.7.5 with SMTP id 5mr65458eeo.100.1393540227774; Thu, 27 Feb 2014 14:30:27 -0800 (PST) Received: from RoniE ([109.67.98.212]) by mx.google.com with ESMTPSA id l4sm2789745eeo.9.2014.02.27.14.30.25 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Feb 2014 14:30:27 -0800 (PST) From: "Roni Even" To: "'Wang, Ye-Kui'" , "'Magnus Westerlund'" , "'Geir Sandbakken \(geirsand\)'" , References: <530F5A6E.3040900@ericsson.com> <0d5401cf33e7$e78811b0$b6983510$@gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4EC@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4EC@nasanexd02f.na.qualcomm.com> Date: Fri, 28 Feb 2014 00:30:22 +0200 Message-ID: <0d6101cf340b$826c3d50$8744b7f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLASZ3b75rOZkdYx7ipt5kjdNBc5QGok5gIAb9+UfEC72jQAJi0xx7A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/BESZeP3Aoz-tH9C3oRIkZ0e8Sd0 Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:30:32 -0000 Hi, The current parameters are similar to RFC6184 allowing the receiver to support higher resolution at lower frame rate but still with the level definition. The max-fps was proposed in http://tools.ietf.org/id/draft-kristensen-avt-rtp-h241param-01.txt but = as far as I can see did not progress. Roni > -----Original Message----- > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > Sent: 27 February, 2014 8:23 PM > To: Roni Even; 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)'; > payload@ietf.org > Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter >=20 > Hi Roni, >=20 > I sent the previous comment before seeing your below. The level = specifies the > max luma picture size and the max luma sample rate, which together > determine the picture rate (i.e. the max fps). >=20 > BR, YK >=20 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even > Sent: Thursday, February 27, 2014 10:15 AM > To: 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)'; = payload@ietf.org > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter >=20 > Hi Magnus, > I am not sure that the level specifies the maximum fps. > Roni >=20 > > -----Original Message----- > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > > Westerlund > > Sent: 27 February, 2014 5:32 PM > > To: Geir Sandbakken (geirsand); payload@ietf.org > > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > > > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > > > #12: The max-fps parameter > > > > > > Lessons learned from video conferencing using H.264 showed that a > > > lot of equipment designed for 30 fps could not handle 60 fps even = at > > > sufficiently low resolution. We do anticipate similar problems = when > > > moving towards 120 fps in H.265. It might not be caused by > > > limitations in the decoder itself, but that the surrounding media > > > pipeline will not have been properly tested for 120 fps before = being > > > put > into > > the wild. > > > If we don't allow for a code point to be used by the "restricted" > > > equipment, it will be required by the "flexible/proper" to include one. > > > This is what happened with max-fps in H.264 enabling higher frame > > > rates compared to lowering them. > > > > > > > I do have concerns with defining a parameter that allow dynamically > > sub- setting the profile and levels that has been defined for HEVC. > > This can > also > > create interoperability issues with any pre-encoded content to a > particular > > profile and level. > > > > The issues with the media pipeline has they been with the reception = of > > the > high > > framerate of packets and forwarding them to the decoder or the > > playback > part, > > i.e. handling of the decoded picture? > > > > If it is predominately the later it appears very reasonable to have > > this > as an > > informative parameter. I will not make use of higher FPS than X, if > > you > send me > > higher than X I will need to reduce that to X or lower before > > displaying > it. That > > way we are not re-defining the profiles, we are ensuring that we can > handle > > content encoded within the profile and still by taking care of the > > this in > the end > > of your decoder chain you can protect the rest of the media = framework > > from not yet supported frame-rates. > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Fri Feb 28 01:31:50 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1164F1A078F for ; Fri, 28 Feb 2014 01:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov0GpOwlUslI for ; Fri, 28 Feb 2014 01:31:43 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A31A0075 for ; Fri, 28 Feb 2014 01:31:42 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id m20so133682qcx.24 for ; Fri, 28 Feb 2014 01:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uEBS/wC02LCXUWUIAcC54dFes+ZVshqNRu/qUxlS7ZY=; b=UgViRzhXtmXISRXtgt1NafMC+cqJALS81UXqGeZNp+J+CV+o4NvSyk1nPonDMdHWBi 39s/qdC7MJaulUKz88UO5IP+yWaLgJVQ6BojomtqWQyMgohcsxZ8BdlZvJHjaRdnDoUm x3oFLapPwkb/bFrxWunQapNFGire6n6yvo3+jKDR3WDl2D5tVpS5SCU+HO54ElsiuopN lOuQbaCE8fF6eMrRKRyGY0yABAAU4I+1C8yB13tvVWNTRkHYnNBvTyGI713weHgfeJuK lCpJcvEgTDXUwLP4kVOk0CLdI2uxqZuIjWAtsPAzfg0FxwbTHSxcnurrW4Mx0Oz1yNhk b9Nw== MIME-Version: 1.0 X-Received: by 10.224.80.134 with SMTP id t6mr2219322qak.34.1393579900631; Fri, 28 Feb 2014 01:31:40 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 28 Feb 2014 01:31:40 -0800 (PST) In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> References: <530F5A6E.3040900@ericsson.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4DA@nasanexd02f.na.qualcomm.com> Date: Fri, 28 Feb 2014 10:31:40 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Wang, Ye-Kui" Content-Type: multipart/alternative; boundary=001a1132e232f17f6604f3741a20 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/uHxy__U6eoM4llDgbSu7-FXfrdo Cc: Tom Kristensen , "payload@ietf.org" Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:31:47 -0000 --001a1132e232f17f6604f3741a20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, YK! These changes in semantics are fine with us and express the need and usage of the parameter well. On 27 February 2014 19:19, Wang, Ye-Kui wrote: > I am with Magnus here. If a decoder cannot DECODE a picture rate allowed > by a level, then the decoder is not even a confirming decoder. We usually > don't standardize mechanisms for non-confirming decoders, unless there is= a > very strong reason. > > I think making the following changes (4 places in the first paragraph of > the semantics) would resolve the issue, with conceptually good semantics, > but the use of the parameter is still practically the same. > > -----------------Start of the semantics, with suggested > changes-------------------------- > max-fps: > The value of max-fps is an integer indicating the maximum picture rate in > units of hundreds of pictures per second that can be efficiently received > (***CHANGE TO "effectively processed by the receiver"***). The max-fps > parameter MAY be used to signal that the receiver has a constraint in tha= t > it is not capable of decoding (***CHANGE TO "processing"***) video > efficiently (***CHANGE TO "effectively"***) at the full picture rate tha= t > is implied by the highest level and, when present, one or more of the > parameters max-lsr, max-lps, and max-br. > > The value of max-fps is not necessarily the picture rate at which the > maximum picture size can be sent, it constitutes a constraint on maximum > picture rate for all resolutions. > > Informative note: The max-fps parameter is semantically different from > max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that > max-fps is used to signal a constraint, lowering the maximum picture rate > from what is implied by other parameters. > > The encoder MUST use a picture rate equal to or less than this value. In > cases where the max-fps parameter is absent the encoder is free to choose > any picture rate according to the highest level and any signaled optional > parameters. > -----------------End of the semantics, with suggested > changes-------------------------- > > Please express your opinion if this is not acceptable to you. > > BR, YK > > > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: Thursday, February 27, 2014 7:32 AM > To: Geir Sandbakken (geirsand); payload@ietf.org > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > > #12: The max-fps parameter > > > > Lessons learned from video conferencing using H.264 showed that a lot > > of equipment designed for 30 fps could not handle 60 fps even at > > sufficiently low resolution. We do anticipate similar problems when > > moving towards 120 fps in H.265. It might not be caused by > > limitations in the decoder itself, but that the surrounding media > > pipeline will not have been properly tested for 120 fps before being pu= t > into the wild. > > If we don't allow for a code point to be used by the "restricted" > > equipment, it will be required by the "flexible/proper" to include one. > > This is what happened with max-fps in H.264 enabling higher frame > > rates compared to lowering them. > > > > I do have concerns with defining a parameter that allow dynamically > sub-setting the profile and levels that has been defined for HEVC. This c= an > also create interoperability issues with any pre-encoded content to a > particular profile and level. > > The issues with the media pipeline has they been with the reception of th= e > high framerate of packets and forwarding them to the decoder or the > playback part, i.e. handling of the decoded picture? > > If it is predominately the later it appears very reasonable to have this > as an informative parameter. I will not make use of higher FPS than X, if > you send me higher than X I will need to reduce that to X or lower before > displaying it. That way we are not re-defining the profiles, we are > ensuring that we can handle content encoded within the profile and still = by > taking care of the this in the end of your decoder chain you can protect > the rest of the media framework from not yet supported frame-rates. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a1132e232f17f6604f3741a20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, YK!

These changes i= n semantics are fine with us and express the need and usage of the paramete= r well.


= On 27 February 2014 19:19, Wang, Ye-Kui <yekuiw@qti.qualcomm.com= > wrote:
I am with Magnus here. If a decoder cannot D= ECODE a picture rate allowed by a level, then the decoder is not even a con= firming decoder. We usually don't standardize mechanisms for non-confir= ming decoders, unless there is a very strong reason.

I think making the following changes (4 places in the first paragraph of th= e semantics) would resolve the issue, with conceptually good semantics, but= the use of the parameter is still practically the same.

-----------------Start of the semantics, with suggested changes------------= --------------
max-fps:
The value of max-fps is an integer indicating the maximum picture rate in u= nits of hundreds of pictures per second that can be efficiently received (*= **CHANGE TO "effectively processed by the receiver"***). =A0The m= ax-fps parameter MAY be used to signal that the receiver has a constraint i= n that it is not capable of decoding (***CHANGE TO =A0"processing"= ;***) video efficiently (***CHANGE TO =A0"effectively"***) at the= full picture rate that is implied by the highest level and, when present, = one or more of the parameters max-lsr, max-lps, and max-br.

The value of max-fps is not necessarily the picture rate at which the maxim= um picture size can be sent, it constitutes a constraint on maximum picture= rate for all resolutions.

Informative note: The max-fps parameter is semantically different from max-= lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc in that max-fps = is used to signal a constraint, lowering the maximum picture rate from what= is implied by other parameters.

The encoder MUST use a picture rate equal to or less than this value. =A0In= cases where the max-fps parameter is absent the encoder is free to choose = any picture rate according to the highest level and any signaled optional p= arameters.
-----------------End of the semantics, with suggested changes--------------= ------------

Please express your opinion if this is not acceptable to you.

BR, YK


-----Original Message-----
From: payload [mailto:payload-b= ounces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Thursday, February 27, 2014 7:32 AM To: Geir Sandbakken (geirsand); payload= @ietf.org
Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter

On 2014-02-27 11:18, Geir San= dbakken (geirsand) wrote:
> #12: The max-fps parameter
>
> Lessons learned from video conferencing using H.264 showed that a lot<= br> > of equipment designed for 30 fps could not handle 60 fps even at
> sufficiently low resolution. We do anticipate similar problems when > moving towards 120 fps in H.265. =A0It might not be caused by
> limitations in the decoder itself, =A0but that the surrounding media > pipeline will not have been properly tested for 120 fps before being p= ut into the wild.
> If we don't allow for a code point to be used by the "restric= ted"
> equipment, it will be required by the "flexible/proper" to i= nclude one.
> This is what happened with max-fps in H.264 enabling higher frame
> rates compared to lowering them.
>

I do have concerns with defining a parameter that allow dynamically sub-set= ting the profile and levels that has been defined for HEVC. This can also c= reate interoperability issues with any pre-encoded content to a particular = profile and level.

The issues with the media pipeline has they been with the reception of the = high framerate of packets and forwarding them to the decoder or the playbac= k part, i.e. handling of the decoded picture?

If it is predominately the later it appears very reasonable to have this as= an informative parameter. I will not make use of higher FPS than X, if you= send me higher than X I will need to reduce that to X or lower before disp= laying it. That way we are not re-defining the profiles, we are ensuring th= at we can handle content encoded within the profile and still by taking car= e of the this in the end of your decoder chain you can protect the rest of = the media framework from not yet supported frame-rates.

Cheers

Magnus Westerlund

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

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

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



--
= # Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/tel= epresence/
## tomkrist@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/
--001a1132e232f17f6604f3741a20-- From nobody Fri Feb 28 01:33:25 2014 Return-Path: <2mkristensen@gmail.com> X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346281A078F for ; Fri, 28 Feb 2014 01:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU0RQNIbe5pY for ; Fri, 28 Feb 2014 01:33:18 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 828571A0184 for ; Fri, 28 Feb 2014 01:33:18 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q107so1371518qgd.1 for ; Fri, 28 Feb 2014 01:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VaX4WUUKnMXdm6vwu6J257fUfqGGqz9/arRJJ6UruPs=; b=fNEVgTRLvf4J1+q9opHAD79y++8DveeoklOYoRvd/20JYQl0Ma7MgiOjftDeVyDrgT hCQ9/d0rAhT7ITIHhOPsZLjg+LSBol9BUE1K3iosh7jnbsW+0sdfcMBQvwIPI2h9hRJT tRWxvhZCX/MWDWZuy6AdKWKCnjKGPaANQFX2IQ7Bzq8K8aapcBB0khWbJYhRbb++6n9W F072SeIEIbxp9dPh/ioAtWvTvAwWqAIhSMRLrGIXiKthAt5YfMczT+hKxKtwwlhW/qjB EbbiboTZQwHwx0Z1ND1Td90IZHFpol3z5KzVXzCQjFXdnsGXl0g1eOba9Z9rjs8ELMEd EWOA== MIME-Version: 1.0 X-Received: by 10.224.22.199 with SMTP id o7mr2057577qab.51.1393579996433; Fri, 28 Feb 2014 01:33:16 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 28 Feb 2014 01:33:16 -0800 (PST) In-Reply-To: <0d6101cf340b$826c3d50$8744b7f0$@gmail.com> References: <530F5A6E.3040900@ericsson.com> <0d5401cf33e7$e78811b0$b6983510$@gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A83387CF4EC@nasanexd02f.na.qualcomm.com> <0d6101cf340b$826c3d50$8744b7f0$@gmail.com> Date: Fri, 28 Feb 2014 10:33:16 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Roni Even Content-Type: multipart/alternative; boundary=001a11c2eaa0a76e5604f3742051 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/6JiqD-G0_FGzSFm0wsIsSPXdwew Cc: IETF Payload WG Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:33:22 -0000 --001a11c2eaa0a76e5604f3742051 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This draft was heavily discussed earlier on, but there was an overall accept for the need of this parameter. However, in this case more work has to be done with regards to backwards compatibility issues and proper language addressing that. -- Tom On 27 February 2014 23:30, Roni Even wrote: > Hi, > The current parameters are similar to RFC6184 allowing the receiver to > support higher resolution at lower frame rate but still with the level > definition. The max-fps was proposed in > http://tools.ietf.org/id/draft-kristensen-avt-rtp-h241param-01.txt but as > far as I can see did not progress. > Roni > > > -----Original Message----- > > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com] > > Sent: 27 February, 2014 8:23 PM > > To: Roni Even; 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)'; > > payload@ietf.org > > Subject: RE: [payload] #12 (rtp-h265): The max-fps parameter > > > > Hi Roni, > > > > I sent the previous comment before seeing your below. The level specifi= es > the > > max luma picture size and the max luma sample rate, which together > > determine the picture rate (i.e. the max fps). > > > > BR, YK > > > > -----Original Message----- > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Thursday, February 27, 2014 10:15 AM > > To: 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)'; payload@ietf.org > > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > > > Hi Magnus, > > I am not sure that the level specifies the maximum fps. > > Roni > > > > > -----Original Message----- > > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > > > Westerlund > > > Sent: 27 February, 2014 5:32 PM > > > To: Geir Sandbakken (geirsand); payload@ietf.org > > > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter > > > > > > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote: > > > > #12: The max-fps parameter > > > > > > > > Lessons learned from video conferencing using H.264 showed that a > > > > lot of equipment designed for 30 fps could not handle 60 fps even a= t > > > > sufficiently low resolution. We do anticipate similar problems when > > > > moving towards 120 fps in H.265. It might not be caused by > > > > limitations in the decoder itself, but that the surrounding media > > > > pipeline will not have been properly tested for 120 fps before bein= g > > > > put > > into > > > the wild. > > > > If we don't allow for a code point to be used by the "restricted" > > > > equipment, it will be required by the "flexible/proper" to include > one. > > > > This is what happened with max-fps in H.264 enabling higher frame > > > > rates compared to lowering them. > > > > > > > > > > I do have concerns with defining a parameter that allow dynamically > > > sub- setting the profile and levels that has been defined for HEVC. > > > This can > > also > > > create interoperability issues with any pre-encoded content to a > > particular > > > profile and level. > > > > > > The issues with the media pipeline has they been with the reception o= f > > > the > > high > > > framerate of packets and forwarding them to the decoder or the > > > playback > > part, > > > i.e. handling of the decoded picture? > > > > > > If it is predominately the later it appears very reasonable to have > > > this > > as an > > > informative parameter. I will not make use of higher FPS than X, if > > > you > > send me > > > higher than X I will need to reduce that to X or lower before > > > displaying > > it. That > > > way we are not re-defining the profiles, we are ensuring that we can > > handle > > > content encoded within the profile and still by taking care of the > > > this in > > the end > > > of your decoder chain you can protect the rest of the media framework > > > from not yet supported frame-rates. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > ---------------------------------------------------------------------= - > > > Services, Media and Network features, Ericsson Research EAB/TXM > > > ---------------------------------------------------------------------= - > > > Ericsson AB | Phone +46 10 7148287 > > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > ---------------------------------------------------------------------= - > > > > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c2eaa0a76e5604f3742051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This draft was heavily discussed earlier on, but there was= an overall accept for the need of this parameter. However, in this case mo= re work has to be done with regards to backwards compatibility issues and p= roper language addressing that.

-- Tom


<= div class=3D"gmail_quote">On 27 February 2014 23:30, Roni Even <ron.e= ven.tlv@gmail.com> wrote:
Hi,
The current parameters are similar to RFC6184 allowing the receiver to
support higher resolution at lower frame rate but still with the level
definition. The max-fps was proposed in
http://tools.ietf.org/id/draft-kristensen-avt-rtp-h24= 1param-01.txt but as
far as I can see did not progress.
Roni

> -----Original Message-----
> From: Wang, Ye-Kui [mailto:= yekuiw@qti.qualcomm.com]
> Sent: 27 February, 2014 8:23 PM
> To: Roni Even; 'Magnus Westerlund'; 'Geir Sandbakken (geir= sand)';
> payload@ietf.org
> Subject: RE: [payload] #= 12 (rtp-h265): The max-fps parameter
>
> Hi Roni,
>
> I sent the previous comment before seeing your below. The level specif= ies
the
> max luma picture size and the max luma sample rate, which together
> determine the picture rate (i.e. the max fps).
>
> BR, YK
>
> -----Original Message-----
> From: payload [mailto:payl= oad-bounces@ietf.org] On Behalf Of Roni Even
> Sent: Thursday, February 27, 2014 10:15 AM
> To: 'Magnus Westerlund'; 'Geir Sandbakken (geirsand)';= payload@ietf.org
> Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
>
> Hi Magnus,
> I am not sure that the level specifies the maximum fps.
> Roni
>
> > -----Original Message-----
> > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus
> > Westerlund
> > Sent: 27 February, 2014 5:32 PM
> > To: Geir Sandbakken (geirsand); payload@ietf.org
> > Subject: Re: [payload] #12 (rtp-h265): The max-fps parameter
> >
> > On 2014-02-27 11:18, Geir Sandbakken (geirsand) wrote:
> > > #12: The max-fps parameter
> > >
> > > Lessons learned from video conferencing using H.264 showed t= hat a
> > > lot of equipment designed for 30 fps could not handle 60 fps= even at
> > > sufficiently low resolution. We do anticipate similar proble= ms when
> > > moving towards 120 fps in H.265. =A0It might not be caused b= y
> > > limitations in the decoder itself, =A0but that the surroundi= ng media
> > > pipeline will not have been properly tested for 120 fps befo= re being
> > > put
> into
> > the wild.
> > > If we don't allow for a code point to be used by the &qu= ot;restricted"
> > > equipment, it will be required by the "flexible/proper&= quot; to include
one.
> > > This is what happened with max-fps in H.264 enabling higher = frame
> > > rates compared to lowering them.
> > >
> >
> > I do have concerns with defining a parameter that allow dynamical= ly
> > sub- setting the profile and levels that has been defined for HEV= C.
> > This can
> also
> > create interoperability issues with any pre-encoded content to a<= br> > particular
> > profile and level.
> >
> > The issues with the media pipeline has they been with the recepti= on of
> > the
> high
> > framerate of packets and forwarding them to the decoder or the > > playback
> part,
> > i.e. handling of the decoded picture?
> >
> > If it is predominately the later it appears very reasonable to ha= ve
> > this
> as an
> > informative parameter. I will not make use of higher FPS than X, = if
> > you
> send me
> > higher than X I will need to reduce that to X or lower before
> > displaying
> it. That
> > way we are not re-defining the profiles, we are ensuring that we = can
> handle
> > content encoded within the profile and still by taking care of th= e
> > this in
> the end
> > of your decoder chain you can protect the rest of the media frame= work
> > from not yet supported frame-rates.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > -----------------------------------------------------------------= -----
> > Services, Media and Network features, Ericsson Research EAB/TXM > > -----------------------------------------------------------------= -----
> > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone =A0+46 10 714= 8287
> > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0= 949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > -----------------------------------------------------------------= -----
> >
> > _______________________________________________
> > payload mailing list
> > payload@ietf.org
> > https://www.ietf.org/mailman/listinfo/payload
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

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



--
= # Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/tel= epresence/
## tomkrist@cisco.com =A0| =A0http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/ --001a11c2eaa0a76e5604f3742051-- From nobody Fri Feb 28 07:47:32 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A891A0318 for ; Fri, 28 Feb 2014 07:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1joiYSaqyxZ for ; Fri, 28 Feb 2014 07:47:26 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 53B521A0836 for ; Fri, 28 Feb 2014 07:47:24 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-e1-5310af8a3b0e Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 81.36.23809.A8FA0135; Fri, 28 Feb 2014 16:47:22 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Feb 2014 16:47:21 +0100 Message-ID: <5310AF7F.9050508@ericsson.com> Date: Fri, 28 Feb 2014 16:47:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvjW7XeoFgg/PzZC1OXdzHanHp4lkm ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj2d7zrAXHjjFWNL55ydLAOHMiYxcjJ4eE gInE4gP9LBC2mMSFe+vZuhi5OIQEDjFK3Jl8mgXCWc4osf/xTDaQKl4BbYk1y7awg9gsAqoS r1Z8A4uzCVhI3PzRCGaLCgRL7DzwmxGiXlDi5MwnYBtEBDoYJXYs1gWxhQWMJdpWrwGq5wDa LC7R0xgEEmYW0JOYcrWFEcKWl2jeOpsZxBYCWtvQ1ME6gZF/FpKps5C0zELSsoCReRUje25i Zk56udEmRmCYHdzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAyLLOOF65j9mtdWlV8H1xwWPhJ02e5HxmPGR3qK2hZTVfzwxDP95Nnq5M8np1woWL2l+7 To6cW3VqZlii1z2p5Ryf0ypXzP9SyCduEayhtZjzbuzEWD6/22bda4sius7dvr9rx7bg9Y/P yj7+t2qH8qJO93Ah38KFJYFqfuutr/9M2vhDgUNeiaU4I9FQi7moOBEAc5iMBAECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/payload/MJwuGAfrIpur4JCBx8yiY_PCMA4 Subject: [payload] Comments on draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:47:31 -0000 Hi, I have reviewed the H.265 RTP payload format and have a some comments. 1. Move abstract The current rules for the "first page" allows one to have the abstract before the Status of this memo. I would recommend that. 2. Word issues: A guess is that you are using MS Word for producing the draft. I seen at least two issues. A) Varying page lengths. B) Table of Content has strange spaces between section levels in the TOC. I guess I can't convince you to switch draft production environment ;-). 3. Section 1.1.2: The profile, tier and level syntax structure that can be included in both VPS and sequence parameter set (SPS) includes 12 bytes data to describe the entire bitstream (including all temporally scalable layers, which are referred to as sub-layers in the HEVC specification), and can optionally include more profile, tier and level information pertaining to individual temporally scalable layers. "12 bytes data to" shouldn't this be "12 bytes of data to"? 4. Use of RTP flow: This draft includes three usage of RTP flow. This is a poorly defined term. I would suggest two things. Drop this usage and replace it with the approriate term from Grouping Taxonomy. 5. Section 1.2: o Transmission of HEVC NAL units of the same bitstream within a single RTP stream (note that RTP stream is used equivalently as RTP flow in this memo) or multiple RTP streams I would propose to make clear that "multiple RTP streams" is within one or more RTP sessions. 6. Section 3.1.1: IRAP picture: A coded picture for which each VCL NAL unit has nal_unit_type in the range of BLA_W_LP to RSV_IRAP_VCL23, inclusive. I wonder if this within paranthesis should include the corresponding values to those labels, i.e. BLA_W_LP (16) to RSV_IRAP_VCL23 (23), ... 7. Section 3.1.2: dependent RTP stream: An RTP stream in an MST on which another RTP stream depends. Here is another case where I think these definitions should be aligned or simply use the one from Grouping Taxonomy. 8. Intentionally missing! 9. Section 3.1.2: single-stream transmission (SST): Transmission of an HEVC bitstream using only one RTP stream. multi-stream transmission (MST): Transmission of an HEVC bitstream using more than one RTP stream. So these redefines the SST and MST terms in RFC 6190 to one that is single/Multi-stream instead of single/Multi-Session. I think this should be aligned with the outcome of the ongoing discussion in AVTEXT regarding grouping taxonomy. 10. Section 3.1.2: RTP stream: A sequence of RTP packets with increasing sequence numbers (except for wrap-around), identical PT and identical SSRC (Synchronization Source), carried in one RTP session. Within the scope of this memo, one RTP stream is utilized to transport one or more temporal sub-layers. I note that this is defined as "Packet Stream" in taxonomy. Consider alignment. At least this definition is clear on what is meant. 11. Section 4.1: Sequence number (SN): 16 bits Set and used in accordance with RFC 3550. To my understanding when using single stream transmission the Decoding order is recovered soley from RTP sequence numbers and order of the NALUs within each RTP payload. This usage should be mentioned here as it affects the impact if anyone would inject other payloads in the same RTP packet stream. 12. Section 4.1: I am missing the SSRC usage for this RTP payload. In SST that is the classical identification of a particular encoding of a media source. But for MST the SSRC usage is different as one needs to know which SSRC in which RTP sessions that are associated. I think this dependency needs to be noted. 13. Section 4.6: DONL (optional) I claim that using "optional" is the wrong word, it should be "conditional". The presence of the field are dependent on a signalling parameters, thus conditional on that parameter. This comment also apply to same type of usage in Section 4.7. 14. Section 4.6: The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the contained NAL unit. If sprop-depack-buf-nalus is greater than 0, the DONL field MUST be present, and the variable DON for the contained NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-depack- buf-nalus is equal to 0), the DONL field MUST NOT be present. I wonder why this is split into two paragraphs, the second paragraph's content is very important to understand what is said in the first. 15. Section 4.7: If sprop-depack-buf-nalus is greater than 0, the DOND field MUST be present in an aggregation unit that is not the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536. I really wonder over the "+1" usage in the DOND field. That prevents two NALUs in an AP to have same DON. Which at least Section 4.5 hints to as being valid. If that is not valid, then Section 4.5 is in error. Thus, this definition can cause issues and I don't see any issues with defining the field without the plus. That limits the difference to increment with a maximum of 255 instead of 256. 16. Section 4.7, figure 7: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PayloadHdr | NALU 1 Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I wonder if this would be clearer by including some values for the payload header, here the Type of the payload header (type=48) appears to be highly relevant for this example. Maybe somehting like this? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PayloadHdr (Type=48) | NALU 1 Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17. Section 4.9: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| PACI=50 | LayerId | TID |A| Type | PHSsize |F0..2|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Header Extension Structure (PHES) | |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=| | | | PACI payload: NAL unit | | . . . | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I wonder if one shouldn't mark the first 16 bits after the header as the "payload header" and instead separate out the configuration of those for this payload format. That would also resolve the next issue. 18. Section 4.9: PACI: 6 bits Indicates a PACI, and must be 50. As this field is called Type in the other definition, why not call it Type: 6 bits Indicates a PACI, and must be 50. And to clarify the confusion with the PACI payload type, that Type field should be called IType or something like that 19. Section 4.9: PHSsize: 5 bits Indicates the total length of the PHES. The value is limited to be less than or equal to 32 octets, to simplify encoder design for MTU size matching. F0..2: 3 bits Each of the three bits indicate, when set, the presence of an optional field (or set of fields) in the PHES. X: 1 bit The X bit, when set, indicates the presence of another octet consisting of seven flags and another X bit, each of the seven flags indicating the presence of more PHES fields (for future extensions). The motivation of the PHSSize of limiting this to 32 octets is not fulfilled. As the RTP payload still are variable size due to the X bit, which adds one or more bytes. Thus if the goal is to make clear that this will never be more than 32 bytes, than I think the bytes that X signals must be included in the 32-bytes for the PHES. 20. Section 4.9: Forward compability for PHES. The content of the PHES field is determined using the F0..2 field and in the future the octet(s) added using the X field, where each set bit indicates what fields are included. However, this definition have some severe implications regarding future compatibility. As each bit can represent an unknown amount of fields a first gen decoder can't know how many bits each of the bits represents. This may not matter much for the first gen, as it only knows of the PHES data defined in this version. To be able to decode these fields only a single thing is missing, an assurance that the first defined data MUST be first in the PHES data section when F0 is set. For a third generation implementation there is another implication. To know where the F2 PHES payload starts it MUST know also what F0 and F1 means in amount of fixed field data values. I am not that happy for this forward compatibility limiations. But, it can work, but the rules for how to make it work MUST be explictely stated now. 1) The fields added for a particular FX bit MUST be fixed in length and not depend on what other FX bits are set. 2) The FX bits must be assigned in order 3) An implementation that supports FX for any value will be required to understand what fields are added and their size for all FX bits that are X or less. 21. Section 4.9: I think the motivation for the PACI is missing. What are the motivation for providing this information in the PACI and what would any RTP endpoint or middlebox use the information for. 22. Section 4.10: Can you please provide a name for the functionality set the F0 bit represents so that we can use a name to reference it? 23. Section 5: Otherwise (sprop- depack-buf-nalus is equal to 0 for an RTP stream), the transmission order of NAL units carried in the RTP stream MUST be the same as the NAL unit decoding order. This fails to describe how you determines the NAL unit decoding order. I assume in RTP sequence order and for each payload in the order the NALUs are included? 24. Section 6: When MST is in use, NAL units of all RTP streams are stored in the same de-packetization buffer. I think it needs to be clarified that this is all RTP streams from the same encoder instance and media source. Not all RTP streams from multiple encoder instances and media sources. 25. Section 7.1: The receiver MUST ignore any unspecified parameter. First, I don't know if this is the right place to included this rule. Secondly, should it not be "unknown" parameters for the one processing the media format parameters? 26. Section 7.1: profile-space, profile-id: Otherwise (the RTP stream is a dependent RTP stream), the following applies, with j being the value of the sub-layer- id parameter: o profile_space = sub_layer_profile_space[j] o profile_id = sub_layer_profile_idc[j] The following text raises some concerns. A) These are defined as being stream specific values. It is unclear how one deals with these if one only want to configure the general capability within a RTP payload type. B) It is unclear if one may or are required to create different RTP payload types for the different scalability layers. From my perspective it is crucial that one can avoid a requirement to create layer specific payload types as this can result in total consumption of the available payload type space in an RTP session. Thus, I see a need to clarify if and when one uses the above assignment. And how the counter part in any signalling exchange is supposed to interpret these cases. The same concerns relate to the tier-flag, level-id: Otherwise (the RTP stream is a dependent RTP stream), the following applies, with j being the value of the sub-layer- id parameter: o tier-flag = sub_layer_tier_flag[j] o level-id = sub_layer_level_idc[j] 27. Section 7.1: profile-compatibility-indicator: Isn't this a sprop parameter? Also it is not clear what "j" is: If the RTP stream is not a dependent RTP stream, the following applies with j = 0..31: o The 32 flags = general_profile_compatibility_flag[j] Am I correct that j in this case are the integer identifying a particular HEVC profile? 28. Section 7.1: profile-compatibility-indicator: It is not clear to me that this parameter has long term applicability. If one includes this, is that a promise until signaling changes to not provide a stream that breaks the provided value? I wonder how one deals with the use cases like AD splicing. One stream may ensure this, is it the role of the signalling to enforce that what one says applies, or will be renegotiated in signalling? 29. sub-layer-id: This parameter MAY be used to indicate the highest allowed value of TID in the stream. When not present, the value of sub-layer-id is inferred to be equal to 6. This parameter is written in a generic form, however the O/A Section indicates this to declare a property of the stream to be sent. But not explicit discussion of this parameter is provided. So what is the meaning of this parameter? A) I promise that the streams I send does not use more than X sub-layers B) I require the peer sending me a stream to not use more than X sub-layers. 30. Section 7.1: sprop-vps, sprop-sps and sprop-pps: I think one unclarity and one that existed in H.264 also, is the precedence between out-of-band and in-band parameter sets. And when they start to apply. The later is especially important in cases when you actually transmit a different set in a new signalling exchange then what has previously been used. Can some clarification on this be included? 31. Section 7.1: Many of the parameters. I notices that quite a lot of the parameters are not explicitly defining the value range allowed for the parameters. This is especially true for integer style values. See the many max- parameters. 32. Section 7.1: max-dpb: Formation error 33. Section 7.1: cap-parameter = tier-flag / level-id / max-lsr / max-lps / max-br These ABNF elements are not defined. I think they need to be. 34. Section 7.2.1: Source specific parameters: o The OPTIONAL parameters "sprop-vps", "sprop-sps", and "sprop- pps", when present, MUST be included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in section 6.3 of [RFC5576]. For a particular media format (i.e. RTP payload type), "sprop-vps" "sprop-sps", or "sprop-pps" MUST NOT be both included in the "a=fmtp" line of SDP and conveyed using the "fmtp" source attribute. This text exemplifies that there are important differencies between RTP session level configuration and individual source level configuration. I think some more general discussion of the potential constraints and implications of the two methods needs to be considered. Especially when you are prevented from signalling both session and stream level. Stream level requires on to know that this stream will be sent and its configuration. And when you also can't provide a session level set that is default fall back if no stream specific is provided then you get to choose between. These parameter constraints applies to all streams, or no pre-provided parameters can be provided at all, and you need per stream signalling. 35. Section 7.2.2: Informative note: The above parameters apply for any stream sent by a declaring entity with the same configuration; i.e. they are dependent on their source. Rather than being bound to the payload type, the values may have to be applied to another payload type when being sent, as they apply for the configuration. I find this confusing. I don't know if it is a typo and should say "independent of their source", or if it is the definition of source here that is wrong. It might be that the paragraph before the above: o The parameters sprop-depack-buf-nalus and sprop-depack-buf-bytes describe the properties of the RTP stream that the offerer or the answerer is sending for the media format configuration. This differs from the normal usage of the Offer/Answer parameters: normally such parameters declare the properties of the stream that the offerer or the answerer is able to receive. When dealing with HEVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered. actually needs to separate between end point specific configurations that apply to the whole RTP session through the payload type or if is on specific media encoding basis and thus needs to be connected to the SSRC(s) that carries the particular media encoding. 36. Section 7.2.2: min_spatial_segmentation_idc equal to or larger than dec- parallel-cap.spatial-seg-idc of the capability point. A stream that is sent based on choosing a capability point with parallel tool type 't' from dec-parallel-cap MUST have entropy_coding_sync_enabled_flag equal to 0 and min_spatial_segmentation_idc equal to or larger than dec- parallel-cap.spatial-seg-idc of the capability point. It looks like someone managed to turn this text into straight left and right columns, this is not allowed in IETF, we use ragged rights. 37. Section 7.2.2: o An offerer has to include the size of the de-packetization buffer, sprop-depack-buf-bytes, and sprop-depack-buf-nalus, in the offer for an interleaved HEVC stream or for the MST transmission mode. To enable the offerer and answerer to inform each other about their capabilities for de-packetization buffering in receiving streams, both parties are RECOMMENDED to include depack-buf-cap. For interleaved streams or in MST, it is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown. This paragraph contains two mentions of "interleaved", the only two in the whole specification. I assume a copy and paste from RFC 6184 that wasn't converted properly. 38. Section 7.2.2.: However, when out-of-band transport of parameter sets is used, parameter sets MAY still be additionally transported in-band unless explicitly disallowed by an application. To me it doesn't appear that this rule is O/A specific. It should apply also to declarative usage. I propose that this is moved to the parameter definition itself. 39. Section 7.2.2.: o In MST, the answerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps of all RTP streams that a particular RTP stream depends on, when present (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute), for decoding the incoming NAL unit stream. I become uncertain how this really works. Especially in the context of recv-sub-layer-id. So the offerer includes the parameter sets for all the layers it intended to send. Then the answerer sub-sets that selection using recv-sub-layer-id. Is the intention to say that the answerer needs to try to apply the parameter sets that matches the selected layers. 40. Section 7.2.2: o If the level to use in the answerer-to-offerer direction is equal to the default level in the answer, the offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) for decoding the incoming NAL unit stream. Otherwise, the offerer MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute) and the answerer MUST transmit parameter sets in-band. Sorry, I missing something here. In the Answerer to Offerer direction, there are no reason for the answerer to not provide parameter sets that matches the offerer's declared receiving capability. Thus, why discuss the "default" level? 41. Section 7.2.2: o In MST, the offerer MUST be prepared to use the parameter sets included in sprop-vps, sprop-sps, and sprop-pps of all RTP streams that a particular RTP stream depends on, when present (either included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute), for decoding the incoming NAL unit stream. I am uncertain if this is intended to mean something else than, if provided attempt to use them. 42. Section 7.2.2: Parameter sets associated with one source MUST only be used to decode NAL units conveyed in RTP packets from the same source. The question is what is meant with "same source" in the above. Is it SSRC, Media Source or Media Encoding, or even Endpoint. 43. Section 7.2.2: sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | profile-space C X C X P profile-id C X C X P tier-flag C X C X P level-id C X C X P C: configuration for sending and receiving streams I don't get this usage or definition of C for these parameters. So these parameters are receiver capabilities, and they needs to be symmetrically used in the signalling, however the actually used values in the transmission direction from an O/A agent only needs to be within the receivers provided parameters. Thus, they are not a "configuration" for the sending direction. Also I really don't get the X's in the answer: recvonly, recv-sub-layer-id, and answer: sendrecv, recv-sub-layer-id. The answering agent is going to receive stream in both these cases, thus it needs to declare the payload type, and these parameters MUST be included (unless defaulted). So why is they marked with X? 44. Section 7.2.2: sendonly --+ answer: recvonly, recv-sub-layer-id --+ | recvonly w/o recv-sub-layer-id --+ | | answer: sendrecv, recv-sub-layer-id --+ | | | sendrecv w/o recv-sub-layer-id --+ | | | | | | | | | interop-constraints C X C X P profile-compatibility-indicator C X C X P I don't understand how these parameters really are used for receiver capability declarations, so I don't understand why the Cs are C and not P. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Feb 28 15:31:11 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2411A031B for ; Fri, 28 Feb 2014 15:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClQj7uOFlPi7 for ; Fri, 28 Feb 2014 15:31:06 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7661A0319 for ; Fri, 28 Feb 2014 15:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393630264; x=1425166264; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sg9dMFqv7IPsEGkrbGryaLjoQkVpFX3gSkoq0R1pllM=; b=aruYzrJzHGQpabtEzSgKbjQ2hjWMyNp9mS6nAIUc7OhX2u+abGqwKleo AM6gNL84tse3UawFy7CCtKRe/sMFG54cQQf2XiB4niptAAAXLgip3g3e/ PMrjPbAc6cacfPzajYyW748YEslhRmUV18Y1cGfHjWnBRFdrV64rGIkWO 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7363"; a="108303475" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 28 Feb 2014 15:31:04 -0800 X-IronPort-AV: E=Sophos;i="4.97,564,1389772800"; d="scan'208";a="692145193" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Feb 2014 15:31:04 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.238]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.03.0158.001; Fri, 28 Feb 2014 15:31:03 -0800 From: "Wang, Ye-Kui" To: Magnus Westerlund , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] Comments on draft-ietf-payload-rtp-h265-02 Thread-Index: AQHPNJxkvhCfBfHaXEuyjN/n0X9j0ZrLRhBg Date: Fri, 28 Feb 2014 23:31:03 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83387D100D@nasanexd02f.na.qualcomm.com> References: <5310AF7F.9050508@ericsson.com> In-Reply-To: <5310AF7F.9050508@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/2mi67BZB2egPOeUzpIBTpjeni4g Subject: Re: [payload] Comments on draft-ietf-payload-rtp-h265-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:31:09 -0000 Hi Magus, Thanks so much for your very careful review. Please see my responses below = to your comments #1-16. Responses to other comments are to come a bit later= . For convenience, comments 16 onwards are removed in this email. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerl= und Sent: Friday, February 28, 2014 7:47 AM To: payload@ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org Subject: [payload] Comments on draft-ietf-payload-rtp-h265-02 Hi, I have reviewed the H.265 RTP payload format and have a some comments. 1. Move abstract The current rules for the "first page" allows one to have the abstract befo= re the Status of this memo. I would recommend that. [YK]: OK. To be done in the next version. 2. Word issues: A guess is that you are using MS Word for producing the draft. I seen at le= ast two issues. A) Varying page lengths. B) Table of Content has strange sp= aces between section levels in the TOC. I guess I can't convince you to switch draft production environment ;-). [YK]: Right we are using MS Word, and I guess it probably takes some effort= to switch draft product environment. However, I will try to improve the ab= ove two aspects when producing version -03 for submission. And I will try t= o learn a different I-D product environment in the future when I got some s= pare time :-). 3. Section 1.1.2: The profile, tier and level syntax structure that can be included in both VPS and sequence parameter set (SPS) includes 12 bytes data to describe the entire bitstream (including all temporally scalable layers, which are referred to as sub-layers in the HEVC specification), and can optionally include more profile, tier and level information pertaining to individual temporally scalable layers. "12 bytes data to" shouldn't this be "12 bytes of data to"? [YK]: I also feel that adding "of" is better. To be added in the next versi= on. 4. Use of RTP flow: This draft includes three usage of RTP flow. This is a poorly defined term.= I would suggest two things. Drop this usage and replace it with the appror= iate term from Grouping Taxonomy. [YK]: OK. 5. Section 1.2: o Transmission of HEVC NAL units of the same bitstream within a single RTP stream (note that RTP stream is used equivalently as RTP flow in this memo) or multiple RTP streams I would propose to make clear that "multiple RTP streams" is within one or = more RTP sessions. [YK]: The motivation is to allow for the multiple RTP streams to be within = either one or more RTP sessions. I hope changing "or multiple RTP streams" = to "or multiple RTP streams within one or more RTP sessions" would be good = to clarify this. 6. Section 3.1.1: IRAP picture: A coded picture for which each VCL NAL unit has nal_unit_type in the range of BLA_W_LP to RSV_IRAP_VCL23, inclusive. I wonder if this within paranthesis should include the corresponding values= to those labels, i.e. BLA_W_LP (16) to RSV_IRAP_VCL23 (23), ... [YK]: It seems that including the values would be better. To be included. 7. Section 3.1.2: dependent RTP stream: An RTP stream in an MST on which another RTP stream depends. Here is another case where I think these definitions should be aligned or s= imply use the one from Grouping Taxonomy. [YK]: Agreed. Should also check the definition of "highest RTP stream" as w= ell. 8. Intentionally missing! 9. Section 3.1.2: single-stream transmission (SST): Transmission of an HEVC bitstream using only one RTP stream. multi-stream transmission (MST): Transmission of an HEVC bitstream using more than one RTP stream. So these redefines the SST and MST terms in RFC 6190 to one that is single/= Multi-stream instead of single/Multi-Session. I think this should be aligne= d with the outcome of the ongoing discussion in AVTEXT regarding grouping t= axonomy. [YK]: Agreed. 10. Section 3.1.2: RTP stream: A sequence of RTP packets with increasing sequence numbers (except for wrap-around), identical PT and identical SSRC (Synchronization Source), carried in one RTP session. Within the scope of this memo, one RTP stream is utilized to transport one or more temporal sub-layers. I note that this is defined as "Packet Stream" in taxonomy. Consider alignm= ent. At least this definition is clear on what is meant. [YK]: OK, will try to align herein too. 11. Section 4.1: Sequence number (SN): 16 bits Set and used in accordance with RFC 3550. To my understanding when using single stream transmission the Decoding orde= r is recovered soley from RTP sequence numbers and order of the NALUs withi= n each RTP payload. This usage should be mentioned here as it affects the i= mpact if anyone would inject other payloads in the same RTP packet stream. [YK]: The current draft also supports interleaved transmission, wherein dec= oding order can be different from RTP sequence number order. Decoder order = number (DON) values are used for de-packetization.=20 12. Section 4.1: I am missing the SSRC usage for this RTP payload. In SST that is the clas= sical identification of a particular encoding of a media source. But for MS= T the SSRC usage is different as one needs to know which SSRC in which RTP = sessions that are associated. I think this dependency needs to be noted. [YK]: OK. I'd appreciate if you could provide some concrete language for th= is.=20 13. Section 4.6: DONL (optional) I claim that using "optional" is the wrong word, it should be "conditional"= . The presence of the field are dependent on a signalling parameters, thus = conditional on that parameter. This comment also apply to same type of usage in Section 4.7. [YK]: OK. All instances to be changed. 14. Section 4.6: The DONL field, when present, specifies the value of the 16 least significant bits of the decoding order number of the contained NAL unit. If sprop-depack-buf-nalus is greater than 0, the DONL field MUST be present, and the variable DON for the contained NAL unit is derived as equal to the value of the DONL field. Otherwise (sprop-depack- buf-nalus is equal to 0), the DONL field MUST NOT be present. I wonder why this is split into two paragraphs, the second paragraph's cont= ent is very important to understand what is said in the first. [YK]: I think the reason is because that originally there were more conditi= ons and the sentences were not as simple. But now it makes sense to merge t= hem. To be merged. 15. Section 4.7: If sprop-depack-buf-nalus is greater than 0, the DOND field MUST be present in an aggregation unit that is not the first aggregation unit in an AP, and the variable DON for the aggregated NAL unit is derived as equal to the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536. I really wonder over the "+1" usage in the DOND field. That prevents two NA= LUs in an AP to have same DON. Which at least Section 4.5 hints to as being= valid. If that is not valid, then Section 4.5 is in error. Thus, this definition can cause issues and I don't see any issues with defi= ning the field without the plus. That limits the difference to increment wi= th a maximum of 255 instead of 256. [YK]: I don't see there is an error. Section 4.5 allows two NALUs in an AP = to have the same DON, but it does not require them to have different DONs. = To me, both options would work, and it is just a matter of design taste. To= my knowledge there are already some implementations of the payload format,= thus I'd prefer to keep the "plus 1", though I don't have a strong opinion= herein. 16. Section 4.7, figure 7: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PayloadHdr | NALU 1 Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I wonder if this would be clearer by including some values for the payload = header, here the Type of the payload header (type=3D48) appears to be highl= y relevant for this example. Maybe somehting like this? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PayloadHdr (Type=3D48) | NALU 1 Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [YK]: Good point. To be changed. Also for Figures 4, 8, and 9.