From ron.even.tlv@gmail.com  Mon Jul  1 08:44:43 2013
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C157C11E8125 for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 08:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.076
X-Spam-Level: 
X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.522,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeOZTaXPUERY for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 08:44:43 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5539411E8112 for <payload@ietf.org>; Mon,  1 Jul 2013 08:44:41 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id z11so3724930wgg.1 for <payload@ietf.org>; Mon, 01 Jul 2013 08:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=a2GzbgnsSYk/kfLHrbsZNdDDCR7ugTH67BnXLhElFzo=; b=rVGb3gFG/vp734ZjpRq8qY3ViNHn+UrsBc60KlvdQch+p+W9YFWtzUABusn0NxsG7v ocPpRUnD+Zmpf6ycIo5Nw8ZSZuch1VtFdLYdmJKAWGdyC1PI1OEQbeeldR4SXeTJ3/tP c/m3ZqCEBJudmpx2vvM1wS35WXgiQCyFTDQh0jL4J3z28or8sXiV7dSmdlzgEO5VppF3 Rx/NOOcjy0xJ9Y7VX5mVjZmCa/yfNL1qNpzvICSlxNzt5ciM3Dglg/xC5bHc7pnuVnH+ 5qfqyYmgZxEqmsouZNNRWcCEEHtvgSamkYAoawlDRtN1DrdFxc233cvnTfUGWD+KN5kK Zr4A==
X-Received: by 10.180.85.8 with SMTP id d8mr12575356wiz.13.1372693479994; Mon, 01 Jul 2013 08:44:39 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id ez3sm6592451wib.3.2013.07.01.08.44.36 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Jul 2013 08:44:39 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: <payload@ietf.org>, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
References: 
In-Reply-To: 
Date: Mon, 1 Jul 2013 18:43:03 +0300
Message-ID: <055301ce7671$af1787e0$0d4697a0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0554_01CE768A.D465AA40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5ngwrun8+6pBZ+RHS6vfa9Cec8SQO7eZHQ
Content-Language: en-us
Subject: Re: [payload] Call for adoption of RTP Payload Format for High Efficiency Video Coding (H.265)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2013 15:44:43 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0554_01CE768A.D465AA40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

There was good support and no objection to adopt the draft as the initial
document for the payload specification.

Please go ahead and submit it as the draft-ietf-payload-rtp-h265-00

 

Please note the deadline 2013-07-08 (Monday): Internet Draft Cut-off for
initial document (-00) submission by UTC 24:00

 

 

Roni Even

 

From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: 12 June, 2013 6:40 PM
To: 'payload@ietf.org'
Cc: 'Ali C. Begen (abegen)'
Subject: Call for adoption of RTP Payload Format for High Efficiency Video
Coding (H.265) 

 

Hi,

 

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

 

There is an individual draft  titled RTP Payload Format for High Efficiency
Video Coding draft-schierl-payload-rtp-h265-03
<http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03>  

 

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

The WG chairs are looking for WG feedback

 

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

 

Roni Even

PAYLOAD WG co-chair

 

 


------=_NextPart_000_0554_01CE768A.D465AA40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
h1
	{mso-style-priority:9;
	mso-style-link:"Heading 1 Char";
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-line-height-alt:0pt;
	font-size:12.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 1";
	font-family:"Courier New";
	font-weight:bold;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Hi,<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>There was good support =
and no objection to adopt the draft as the initial document for the =
payload specification.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Please go ahead and submit it as the =
draft-ietf-payload-rtp-h265-00<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Please note the deadline =
</span><strong><span =
style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif";color:black'>=
2013-07-08 (Monday):</span></strong><span =
style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif";color:black'>=
 Internet Draft Cut-off for initial document (-00) submission by UTC =
24:00<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Roni =
Even<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Roni Even [mailto:ron.even.tlv@gmail.com] <br><b>Sent:</b> 12 June, 2013 =
6:40 PM<br><b>To:</b> 'payload@ietf.org'<br><b>Cc:</b> 'Ali C. Begen =
(abegen)'<br><b>Subject:</b> Call for adoption of RTP Payload Format for =
High Efficiency Video Coding (H.265) =
<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Hi,<o:p></o=
:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The ITU-T =
approved a new video codec </span><span lang=3DEN =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>High =
Efficiency Video Coding also known as </span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;H.265=
.<o:p></o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>There is =
an individual draft &nbsp;titled RTP Payload Format for </span><span =
lang=3DEN =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>High =
Efficiency Video Coding <a =
href=3D"http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03">dra=
ft-schierl-payload-rtp-h265-03</a> </span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The WG =
chairs would like to ask for a new milestone for December 2013 RTP =
Payload Format for </span><span lang=3DEN =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>High =
Efficiency Video Coding</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> and =
accept this document as the initial document to address the =
milestone.<o:p></o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The WG =
chairs are looking for WG feedback<o:p></o:p></span></p><p =
class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
</o:p></span></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Please =
respond by Monday July 1<sup>st</sup>&nbsp; 2013 with your positions. =
<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Roni Even<o:p></o:p></p><p class=3DMsoPlainText><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>PAYLOAD WG =
co-chair<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>
------=_NextPart_000_0554_01CE768A.D465AA40--


From internet-drafts@ietf.org  Mon Jul  1 15:05:17 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F189E11E82B8; Mon,  1 Jul 2013 15:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.459
X-Spam-Level: 
X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKiVx-ATjGKc; Mon,  1 Jul 2013 15:05:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7641A11E829B; Mon,  1 Jul 2013 15:05:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130701220516.3246.37839.idtracker@ietfa.amsl.com>
Date: Mon, 01 Jul 2013 15:05:16 -0700
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-00.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2013 22:05:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Audio/Video Transport Payloads Working Gr=
oup of the IETF.

	Title           : RTP Payload Format for High Efficiency Video Coding
	Author(s)       : Ye-Kui Wang
                          Yago Sanchez
                          Thomas Schierl
                          Stephan Wenger
                          Miska M. Hannuksela
	Filename        : draft-ietf-payload-rtp-h265-00.txt
	Pages           : 69
	Date            : 2013-07-01

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-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From yekuiw@qti.qualcomm.com  Mon Jul  1 16:18:47 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264B811E82E2 for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 16:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjmN7Nm0ueC9 for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 16:18:43 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 34ED011E82B4 for <payload@ietf.org>; Mon,  1 Jul 2013 16:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372720723; x=1404256723; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k/YdoG3+aRm2KGAFesd1DezB6i9AqkJRYCa8PVqcM8U=; b=iFQGIKYH+Xhc7Dnt6Y6ypRYRlVHS+UPcvCEgErFvWwqSMLXcowvoPdzO 5HupvrrncTN/Qi7KGXY1N3plVA0e55qnuaL6u5WR3aPPbmrzCy0cyKYtC 13e/GjLbB2/Yky45wcAEwuzESRiRxmWRINGWZua/DmPxfND3ioT5LT+dk 0=;
X-IronPort-AV: E=Sophos;i="4.87,976,1363158000"; d="scan'208";a="46670600"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 01 Jul 2013 16:18:42 -0700
X-IronPort-AV: E=Sophos;i="4.87,976,1363158000"; d="scan'208";a="473135557"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Jul 2013 16:18:39 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 16:18:31 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-00.txt
Thread-Index: AQHOdqcpyYZwb8Zx20Od5HO0PC/XYZlQdEgg
Date: Mon, 1 Jul 2013 23:18:31 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338452FDA@nasanexd02f.na.qualcomm.com>
References: <20130701220516.3246.37839.idtracker@ietfa.amsl.com>
In-Reply-To: <20130701220516.3246.37839.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-00.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2013 23:18:47 -0000

Thanks to everyone who has made comments, short or long.

For information, in the submission, I have addressed comments from Roni, Ri=
ckard, Sachin and Woo, but not yet those suggestions from Tom, as I expect =
there to be some more discussions on those suggestion before we conclusion =
on what exactly to be included into the draft.

BR, YK

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> Behalf Of internet-drafts@ietf.org
> Sent: Monday, July 01, 2013 3:05 PM
> To: i-d-announce@ietf.org
> Cc: payload@ietf.org
> Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>  This draft is a work item of the Audio/Video Transport Payloads Working
> Group of the IETF.
>=20
> 	Title           : RTP Payload Format for High Efficiency Video Coding
> 	Author(s)       : Ye-Kui Wang
>                           Yago Sanchez
>                           Thomas Schierl
>                           Stephan Wenger
>                           Miska M. Hannuksela
> 	Filename        : draft-ietf-payload-rtp-h265-00.txt
> 	Pages           : 69
> 	Date            : 2013-07-01
>=20
> Abstract:
>    This memo describes an RTP payload format for the video coding
>    standard  ITU-T  Recommendation  H.265  and  ISO/IEC  International
>    Standard 23008-2, both also known as High Efficiency Video Coding
>    (HEVC) [HEVC], 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.
>=20
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-00
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

From stewe@stewe.org  Tue Jul  2 05:53:04 2013
Return-Path: <stewe@stewe.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6929B21F9B81 for <payload@ietfa.amsl.com>; Tue,  2 Jul 2013 05:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KpVWg+O8itT for <payload@ietfa.amsl.com>; Tue,  2 Jul 2013 05:52:58 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7B21F96EB for <payload@ietf.org>; Tue,  2 Jul 2013 05:52:50 -0700 (PDT)
Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB192.namprd07.prod.outlook.com (10.242.167.144) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 12:52:47 +0000
Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 12:52:46 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: H.265 payload format, default level
Thread-Index: AQHOdyMMjkrT+XCMUECaGmg60t+kkQ==
Date: Tue, 2 Jul 2013 12:52:45 +0000
Message-ID: <CDF81B2E.9EB9F%stewe@stewe.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.220.2]
x-forefront-prvs: 0895DF8FFD
x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(199002)(189002)(63696002)(81342001)(51856001)(47976001)(66066001)(65816001)(50986001)(76482001)(59766001)(77982001)(74502001)(81542001)(54316002)(53806001)(4396001)(56776001)(31966008)(69226001)(47736001)(74876001)(54356001)(74706001)(79102001)(76786001)(74366001)(80022001)(46102001)(49866001)(16236675002)(76796001)(77096001)(56816003)(83072001)(74662001)(36756003)(47446002)(76176001)(16406001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB192; H:CO1PR07MB191.namprd07.prod.outlook.com; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_CDF81B2E9EB9Fstewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: [payload] H.265 payload format, default level
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 12:53:04 -0000

--_000_CDF81B2E9EB9Fstewesteweorg_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
I'm one of the authors, and haven't discussed this issue with my co-authors=
 yet.
When profile-space, profile, tier, and level are not specifically signaled =
in SDP, default values are assumed.  Those default values are IMO fine for =
profile-space, profile, and tier; however, the default level is 1.0 which r=
epresents QCIF @ 15 fps.  I don't know whether anyone still uses in real li=
fe such a low resolution, but it's certainly not one that is going to be re=
presentative for the use of H.265.  So I wonder: should we move the default=
 level up to something more useful?  Level 3.1 perhaps?  Systems with capab=
ilities lower than that can still downgrade by signaling a lower level ID..=
.
Stephan


--_000_CDF81B2E9EB9Fstewesteweorg_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <CA9A709676E4DA44B3BF48BD61BE379A@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Hi all,</div>
<div>I'm one of the authors, and haven't discussed this issue with my co-au=
thors yet.</div>
<div>When profile-space, profile, tier, and level are not specifically sign=
aled in SDP, default values are assumed. &nbsp;Those default values are IMO=
 fine for profile-space, profile, and tier; however, the default level is 1=
.0 which represents QCIF @ 15 fps. &nbsp;I
 don't know whether anyone still uses in real life such a low resolution, b=
ut it's certainly not one that is going to be representative for the use of=
 H.265. &nbsp;So I wonder: should we move the default level up to something=
 more useful? &nbsp;Level 3.1 perhaps? &nbsp;Systems
 with capabilities lower than that can still downgrade by signaling a lower=
 level ID&#8230;</div>
<div>Stephan</div>
<div>&nbsp;&nbsp;</div>
</body>
</html>

--_000_CDF81B2E9EB9Fstewesteweorg_--

From yekuiw@qti.qualcomm.com  Tue Jul  2 07:40:34 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA26D21F9F3F for <payload@ietfa.amsl.com>; Tue,  2 Jul 2013 07:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPy62YnyryOU for <payload@ietfa.amsl.com>; Tue,  2 Jul 2013 07:40:30 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F50221F9F3C for <payload@ietf.org>; Tue,  2 Jul 2013 07:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372776029; x=1404312029; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=V7b12FAJwojPaGDgOCPsIFMyDZ+ZqhWJnO2ypH//qiI=; b=bEW+6V5NJflZQ01+HTZKhNchBSXhvimviLxyyZkfeOS4a3oU/a5p6+WX E7QeQnlXpIdKni458BGCeRNY0dTWymyiQCqPK5nAkvY1SP+U0Lpt/uLVH bXHCyDVvGr1daWMROLlzq2PoP9kZvAPUYoX97Up/vV/5MYZm5MbLslG8I w=;
X-IronPort-AV: E=Sophos;i="4.87,980,1363158000"; d="scan'208,217";a="46605194"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 02 Jul 2013 07:40:28 -0700
X-IronPort-AV: E=Sophos;i="4.87,980,1363158000";  d="scan'208,217";a="473435425"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jul 2013 07:40:18 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 07:40:18 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Stephan Wenger <stewe@stewe.org>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: H.265 payload format, default level
Thread-Index: AQHOdyMMjkrT+XCMUECaGmg60t+kkZlRdU6w
Date: Tue, 2 Jul 2013 14:40:18 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338453981@nasanexd02f.na.qualcomm.com>
References: <CDF81B2E.9EB9F%stewe@stewe.org>
In-Reply-To: <CDF81B2E.9EB9F%stewe@stewe.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8338453981nasanexd02fnaqu_"
MIME-Version: 1.0
Subject: Re: [payload] H.265 payload format, default level
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 14:40:35 -0000

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338453981nasanexd02fnaqu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Stephan, All,

I fully agree and support to upgrade the default level as Level 3.1 (up to =
720p@30fps, an operation point that is even becoming more and more popular =
in mobile environment).

BR, YK

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Stephan Wenger
Sent: Tuesday, July 02, 2013 5:53 AM
To: payload@ietf.org
Subject: [payload] H.265 payload format, default level

Hi all,
I'm one of the authors, and haven't discussed this issue with my co-authors=
 yet.
When profile-space, profile, tier, and level are not specifically signaled =
in SDP, default values are assumed.  Those default values are IMO fine for =
profile-space, profile, and tier; however, the default level is 1.0 which r=
epresents QCIF @ 15 fps.  I don't know whether anyone still uses in real li=
fe such a low resolution, but it's certainly not one that is going to be re=
presentative for the use of H.265.  So I wonder: should we move the default=
 level up to something more useful?  Level 3.1 perhaps?  Systems with capab=
ilities lower than that can still downgrade by signaling a lower level ID..=
.
Stephan


--_000_8BA7D4CEACFFE04BA2D902BF11719A8338453981nasanexd02fnaqu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Stephan, All,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I fully agree and support=
 to upgrade the default level as Level 3.1 (up to 720p@30fps, an operation =
point that is even becoming more and more popular in mobile
 environment).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">BR, YK<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> payload-bounces@ietf.org [mailto:payload-bounces@ietf=
.org]
<b>On Behalf Of </b>Stephan Wenger<br>
<b>Sent:</b> Tuesday, July 02, 2013 5:53 AM<br>
<b>To:</b> payload@ietf.org<br>
<b>Subject:</b> [payload] H.265 payload format, default level<o:p></o:p></s=
pan></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hi all,<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I'm one of the authors, and=
 haven't discussed this issue with my co-authors yet.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">When profile-space, profile=
, tier, and level are not specifically signaled in SDP, default values are =
assumed. &nbsp;Those default values are IMO fine for profile-space,
 profile, and tier; however, the default level is 1.0 which represents QCIF=
 @ 15 fps. &nbsp;I don't know whether anyone still uses in real life such a=
 low resolution, but it's certainly not one that is going to be representat=
ive for the use of H.265. &nbsp;So I wonder:
 should we move the default level up to something more useful? &nbsp;Level =
3.1 perhaps? &nbsp;Systems with capabilities lower than that can still down=
grade by signaling a lower level ID&#8230;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Stephan<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;<o:p></o:p></sp=
an></p>
</div>
</div>
</div>
</body>
</html>

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338453981nasanexd02fnaqu_--

From rickard.sjoberg@ericsson.com  Wed Jul  3 06:46:54 2013
Return-Path: <rickard.sjoberg@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614E921F9CBF for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 06:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miYsrB3pQQdp for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 06:46:49 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 424B511E81BA for <payload@ietf.org>; Wed,  3 Jul 2013 06:46:35 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f586d000001a55-98-51d42b39c25e
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6D.1D.06741.93B24D15; Wed,  3 Jul 2013 15:46:34 +0200 (CEST)
Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 15:46:33 +0200
From: =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Submission of new versions of H.265/HEVC payload format
Thread-Index: Ac5mxRy1XpIRDmQdTgeDR7RG12PPdAG+YyWAAARO1CAAmc/S0AHu+xDw
Date: Wed, 3 Jul 2013 13:46:33 +0000
Message-ID: <4BC545FCE47FC14EAABD27484D62A9D01C1BB156@ESESSMB103.ericsson.se>
References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1B65B3@ESESSMB103.ericsson.se> <8BA7D4CEACFFE04BA2D902BF11719A8338431C78@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338431C78@nasanexd02f.na.qualcomm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvra6V9pVAgwfTuC0uXTzLZPFkzTFm ByaPJUt+MnksmvqMMYApissmJTUnsyy1SN8ugStj5SqVgpc+FQ+v/2dvYHxi28XIwSEhYCJx brldFyMnkCkmceHeejYQW0jgMKPE8VvJXYxcQPZiRomjLZtYQBJsAu4SJ990MIHYIgKhEl8+ TmUHsYUFXCR+7N7OChF3lTg7+S1UjZvEzJffwGpYBFQkvn6cywiyl1fAV+LSfRaI+Q+A5ndN BVvMKRAsMeHBeTCbUUBW4kvjamYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSjR/rSB EaJeT+LG1ClsELa2xLKFr8HqeQUEJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJmTnp 5YabGIFxcHDLb90djKfOiRxilOZgURLn3aR3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD I0vm0rz+strkR823lzBNWLuO9UgQz97S2xPjMo331Etq7EnLim6wnMQTeic9ymfLSbdJ4iuv 8Ot0d2m/ziqYd/QsX9uc00lvlPVWXNO43GvWYhM+Rczh5FPJP1aCcQ2ssos/Ja7sXqtipmIX yKr9+0HEj56kS1GqZ9+fnP/qyuHppm/L+66rKbEUZyQaajEXFScCAJN5qyxRAgAA
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 13:46:54 -0000

Hi Ye-Kui,

Thanks for your feedback on my comments, your suggestions look good to me.

Regarding discouraging fragmentation units (FUs) for live-encoding scenario=
s in section 4.7, I think using FUs does make sense when you do not have ma=
ny non-VLC NAL units for aggregation. The spatial granularity of slices was=
 16x16 pixels in H.264 but is typically 64x64 for HEVC which means that MTU=
 size matching is done with units that are 16x larger. This may lead to a l=
arger number of smaller packets when slices are used compared to FUs. In ad=
dition, there is the HEVC rule of slice and tile boundaries that makes the =
slice granularity equal to the tile granularity for cases when slices span =
multiple tiles. Finally, FUs are easier to implement since you do not need =
to care about when to break your slice to not exceed the MTU size limit. I =
think both slices and FUs has their merits and the choice between them for =
live-encoding should be left for the implementer.

Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and the POC=
 MSB sync issue, I agree that this is a corner case that we probably will n=
ot see much of in practice. I have no text change suggestion at the moment.

BR
Rickard


-----Original Message-----
From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20
Sent: den 24 juni 2013 01:00
To: Rickard Sj=F6berg; payload@ietf.org
Subject: RE: Submission of new versions of H.265/HEVC payload format

Hi Rickard,

Thanks for the careful review and the comments. Please see inline below.

BR, YK

> -----Original Message-----
> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> Sent: Thursday, June 20, 2013 9:17 AM
> To: Wang, Ye-Kui; payload@ietf.org
> Subject: RE: Submission of new versions of H.265/HEVC payload format
>=20
> Dear all,
>=20
> I have taken a first look at draft-schierl-payload-rtp-h265-03 and=20
> have some questions/comments.
>=20
> My first question is what extensions of HEVC that=20
> draft-schierl-payload-rtp-
> h265 is intended to cover? The draft mentions "future  scalable  or =20
> 3D  video coding  extensions  of  this  specification", what extensions d=
o you refer to?
> Is the intent to cover the all HEVC extensions in a single payload specif=
ication?
>=20

[YK] That is in the semantics of LayerId (nuh_layer_id), where "this specif=
ication" should be replaced with "[HEVC]". It is sort of copy-and-paste err=
or. Thanks for the good catching. No, there is no intention to cover HEVC e=
xtensions in this payload specification, though we intentionally to have th=
e depacketization process and the use with feedback messages to work for HE=
VC scalability and 3DV extensions.

> Another question for my understanding is why "Receivers MUST pass=20
> picture timing SEI messages and decoding unit information SEI messages=20
> to the decoder"?

[YK] Generally, RTP receivers should/must pass all NAL units specified by t=
he video coding spec to the video decoders. This is emphasized here for the=
 two timing related SEI messages after it is said that picture output timin=
g in RTP timestamps should be used instead (to avoid giving a wrong impress=
ion to readers that the SEI messages should be ignored). If an RTP receiver=
 discards the SEI messages, then HRD conformance checking for the bitstream=
 that was possible would be disabled, and also the information related to f=
rame doubling or tripping would be lost.

>=20
> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The=20
> fourth one does not seem to be a rule since there is no "MUST" or=20
> "SHOULD" in the corresponding text.

[YK] I see your point, it is only a "MAY" rule. An alternative to put this =
as a packetization rule is to put it as part of the semantics of NAL unit h=
eader (1.1.4), but that sub-section belongs to an overview wherein normativ=
e language (even "MAY") should not appear. One solution to this is to inser=
t "Payload Header Usage" after 4.1 "RTP Header Usage" and include at least =
this item there. I will do this in the next version unless there is a bette=
r suggestion.

> Further, the fifth one discourages using FUs, what are the reasons=20
> behind that?

[YK] The bullet item only discourages using FUs for live-encoding scenarios=
, wherein dependent slice segments should be used instead. This was added a=
fter a discussion (among the authors) on the need of whether to specify a p=
ayload structure for mixed FU and aggregation packets and from that discuss=
ion we concluded that encoding dependent slice segments at source coding le=
vel already allows for the use cases and using of FUs for live-encoding doe=
s not make sense. Please let us know if you think differently.

> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal. Isn't=20
> there a possiblity that the MSB of PicOrderCntVal may differ between=20
> the encoder and decoder?

[YK] Good question. In theory this is indeed possible when random accessing=
 to a bitstream is performed. However, it would not happen in conversationa=
l applications where the feedback messages may be used. Therefore, to me th=
is would just work just fine. But please feel free to make other suggestion=
s.

>=20
> The use of spatial-segmentation-idc may need some updates to be=20
> useful, let me come back to that later on.
>=20

[YK] OK. Look forward to seeing your input herein.

>=20
> I have also a number of spelling suggestions for your considerations:
>=20
> Section 1.1:
> Replace "community" by "communities"

[YK] I guess both are OK. But anyway I just changed it per your suggestion =
(for the next version).

>=20
> Section 1.1.1:
> Replace "In addition, interpolation filter" by "In addition, the=20
> interpolation filter"

[YK] Thanks - done.

> Replace "skipping the transform coding" by "skipping the transform"
> (transform_skip_flag of HEVC skips the transform, not the coding)
>=20

 [YK] Done.

> Section 1.1.2:
> Replace:
> "2) An indication of whether there is any parameter set within the=20
> current coded video sequence that updates another parameter set of the=20
> same type preceding in decoding order."
> by:
> "2) An indication of whether there is no parameter set update in the=20
> coded video sequence."
> since that is what no_parameter_set_update_flag in HEVC indicates.
>=20

[YK] Changed the wording to "An indication of whether there is no parameter=
 set within the current coded video sequence that updates another parameter=
 set of the same type preceding in decoding order."

> Section 4.7:
> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and "FU=20
> Type:  6 bits" to avoid confusion with the Type in the payload header.
>=20

[YK] Good point again. I will change the field name to be "FuType".

> Section 6:
> Replace "recovery" by "recover"

[YK] Done.

>=20
> Section 7.1:
> Replace "level-id" by "level-idc"

[YK] We are consistently using "id" for profile-id, level-id, max-recv-leve=
l-id etc, similarly as in RFC 6184, instead of "idc".

> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"

 [YK] Done.

>=20
> Section 8:
> Replace "two  payload-specific  feedback  messages" by "a =20
> payload-specific feedback  message", since only SPLI is "Assigned in this=
 memo".
> Also, consider removing references to H.264 in the last paragraph of=20
> Section
> 8 since the memo is about HEVC.

[YK] Good catch again. Changed.

>=20
> Section 8.1:
> Seems to me that "There MUST be exactly one RPSI contained in the FCI=20
> field" should be "There MUST be exactly one SPLI contained in the FCI fie=
ld"

[YK] Another good catch. Changed.

>=20
>=20
> Best Regards,
> Rickard Sj=F6berg
>=20
>=20
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> Behalf Of Wang, Ye-Kui
> Sent: den 11 juni 2013 19:00
> To: payload@ietf.org
> Subject: [payload] Submission of new versions of H.265/HEVC payload=20
> format
>=20
> Dear All,
>=20
> We have just submitted versions 02 and 03 of=20
> draft-schierl-payload-rtp-h265, for which the links are as follows:
>=20
> Version 02:
> URL:             http://www.ietf.org/internet-drafts/draft-schierl-payloa=
d-rtp-
> h265-02.txt
> Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h26=
5-02
> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload=
-rtp-h265-
> 02
>=20
> Version 03:
> URL:             http://www.ietf.org/internet-drafts/draft-schierl-payloa=
d-rtp-
> h265-03.txt
> Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h26=
5-03
> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload=
-rtp-h265-
> 03
>=20
> Version 02 includes huge changes compared to the earlier submitted=20
> version 01. In a short summary, the authors have worked hard to try to=20
> make the design complete, from both the payload structure and the=20
> signaling points of view. Compared to version 02, version 03 only=20
> contains a correction of the email address of an author.
>=20
> Due to that the industry is eager to deploy H.265/HEVC and other=20
> standards bodies such as 3GPP rely on the payload format for support=20
> of H.265/HEVC in RTP based video services, we need to progress this draft=
 relatively quickly.
> Therefore, we would like to request quick reviews from interested=20
> parties and also request for the WG status of this draft.
>=20
> BR, YK (on behalf of the authors)
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>=20


From ietf-secretariat-reply@ietf.org  Mon Jul  1 09:06:29 2013
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16A11E823B for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 09:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH+RZIM3IPph for <payload@ietfa.amsl.com>; Mon,  1 Jul 2013 09:06:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8888511E8291 for <payload@ietf.org>; Mon,  1 Jul 2013 09:05:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130701160535.19596.18615.idtracker@ietfa.amsl.com>
Date: Mon, 01 Jul 2013 09:05:35 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
X-Mailman-Approved-At: Wed, 03 Jul 2013 08:01:19 -0700
Subject: [payload] Milestones changed for payload WG
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2013 16:06:29 -0000

Changed milestone "Submit RTP Payload Format for MIDI for Proposed
Standard", set due date to January 2011 from January 2011.

Changed milestone "Submit RTP Payload Format for DV (IEC 61834) Video
for Proposed Standard", set due date to April 2011 from April 2011.

Changed milestone "Submit RTP profile for the carriage of SMPTE 336M
data for Proposed Standard", set due date to June 2012 from June 2012.

Changed milestone "Submit RTP Payload Format for Bluetooth's SBC audio
codec for Proposed Standard", set due date to August 2012 from August
2012.

Changed milestone "Submit How to Write an RTP Payload Format for
Informational", set due date to September 2012 from September 2012.

Changed milestone "Submit RTP Payload Format for VP8 Video for
Proposed Standard", set due date to September 2012 from September
2012.

Changed milestone "Submit RTP Payload Format for Opus Speech and Audio
Codec as proposed standard", set due date to December 2012 from
December 2012.

Changed milestone "Submit RTP Payload Format for MVC Video for
Proposed Standard", set due date to March 2013 from March 2013.

Changed milestone "Submit RTP Payload Format for Standard apt-X and
Enhanced apt-X Codecs for Proposed Standard", set due date to December
2013 from December 2013.

Changed milestone "Submit RTP Payload Format for G.711.0 for Proposed
Standard", set due date to December 2013 from December 2013.

Added milestone "Submit RTP Payload Format for High Efficiency Video
Coding for Proposed Standard.", due January 2014.

URL: http://datatracker.ietf.org/wg/payload/charter/

From internet-drafts@ietf.org  Wed Jul  3 08:50:27 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E6B21F9D1F; Wed,  3 Jul 2013 08:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.49
X-Spam-Level: 
X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKUAxGvPuUMa; Wed,  3 Jul 2013 08:50:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AC021F9D01; Wed,  3 Jul 2013 08:50:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130703155025.1852.70266.idtracker@ietfa.amsl.com>
Date: Wed, 03 Jul 2013 08:50:25 -0700
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-05.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 15:50:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Audio/Video Transport Payloads Working Gr=
oup of the IETF.

	Title           : RTP Payload Format for Bluetooth's SBC Audio Codec
	Author(s)       : Christian Hoene
                          Frans de Bont
	Filename        : draft-ietf-payload-rtp-sbc-05.txt
	Pages           : 23
	Date            : 2013-07-03

Abstract:
   This document specifies a Real-time Transport Protocol (RTP) payload
   format to be used for the low complexity subband codec (SBC), which
   is the mandatory audio codec of the Advanced Audio Distribution
   Profile (A2DP) Specification written by the Bluetooth(r) Special
   Interest Group (SIG). The payload format is designed to be able to
   interoperate with existing Bluetooth A2DP devices, to provide high
   streaming audio quality, interactive audio transmission over the
   internet, and ultra-low delay coding for jam sessions on the
   internet. This document contains also a media type registration
   which specifies the use of the RTP payload format.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-sbc-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stewe@stewe.org  Wed Jul  3 09:23:08 2013
Return-Path: <stewe@stewe.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31D811E81FB for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 09:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXIY1F7kKGLL for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 09:22:58 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id CDEC511E81EC for <payload@ietf.org>; Wed,  3 Jul 2013 09:22:56 -0700 (PDT)
Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB192.namprd07.prod.outlook.com (10.242.167.144) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 3 Jul 2013 16:22:49 +0000
Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) with mapi id 15.00.0702.005; Wed, 3 Jul 2013 16:22:48 +0000
From: Stephan Wenger <stewe@stewe.org>
To: =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, "Wang,  Ye-Kui" <yekuiw@qti.qualcomm.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: AQHOeAmOV/dQGiB6pkqltwCo8qSXjA==
Date: Wed, 3 Jul 2013 16:22:48 +0000
Message-ID: <CDF9959C.9ECA9%stewe@stewe.org>
In-Reply-To: <4BC545FCE47FC14EAABD27484D62A9D01C1BB156@ESESSMB103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [71.202.147.60]
x-forefront-prvs: 0896BFCE6C
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(51704005)(24454002)(51914003)(377454003)(52044002)(199002)(189002)(65816001)(63696002)(74706001)(81342001)(76796001)(51856001)(76482001)(50986001)(59766001)(81542001)(66066001)(74502001)(77982001)(47976001)(31966008)(80022001)(4396001)(56776001)(69226001)(54356001)(74876001)(47736001)(54316002)(53806001)(76786001)(49866001)(74366001)(46102001)(77096001)(83072001)(56816003)(47446002)(74662001)(36756003)(79102001)(76176001)(16406001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB192; H:CO1PR07MB191.namprd07.prod.outlook.com; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B4A5C1A617FB7041A4D038C140B8FA0E@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 16:23:08 -0000

Hi Rickard,
Commenting only on slices vs. FUs.
The preference for slices over FUs, historically, was pushed by myself
into RFC 3984 for reasons of error resilience, and was moved over to this
draft for the same reason.  Loose a slice, and you can recover at the next
slice boundary; loose an FU, and you have to wait for the next slice
header and throw away all trailing FUs.  RTP is in virtually all cases run
over UDP, and in the typical Internet scenario UDP is lossy (in contrast
to private, managed IP-network, which may have other constraints, but are
not the IETF's main concern.)
To set your remarks into context, let's first understand what we are
talking about: the cost of slices is the overhead stemming from the
insertion of slice headers (in-picture syntax prediction) and from the
packet headers themselves.  And, of course, implementation complexity, but
we should not be in the business to encourage implementor laziness when
there would be a more complex, but better suited tool available.    The
additional packetization overhead is only incurred when, as a result of
incompetently filled packets (which, I agree, is more likely with 64x64
CUs than with 16/16 macroblocks), an additional packet needs to be
inserted.  You may remember a quick analysis of mine we discussed way back
early in JCT, where we (I think) agreed that the practical impact is
negligible in almost all non-tile scenarios (mostly because an additional
overhead of 50 bytes or so--3% or less of the coded picture size) is
incurred statistically only rarely (only in those cases where an
additional packet would need to be generated because of the video coding
related overhead for the use of slices).  The prediction overhead of the
use of regular slices has been shown to be substantial--the price one
needs to pay for independent decodability--but for entropy slices that
overhead virtually does not exist.
With respect to tiles, I think you have a point though, especially when
considering the type of massive parallel implementations for relatively
small picture sizes some folks have been considering.
OTOH, because FUs are trivial to implement--some say in contrast to
slices--and because (I hope) we all agree that using FUs in error prone
scenarios is a bad idea if you could use slices (but for reasons like the
tile connection you mentioned), the draft should IMO continue to set a
preference for the use of regular slices over FUs.  To avoid
underperforming systems due to implementer laziness.
However, this is the IETF.  We don't have to worry about the word-count of
explanatory language.  In fact, explaining such complex tradeoffs and
relationships is generally encouraged here.  So let's just do that:
express a preference of the use of regular slices (SHOULD) when you expect
losses and can use them (real-time encoding, no tiling structure that
would lead to unacceptable packetization overhead); and suggest (MAY) the
use of FUs in other scenarios.  Accompanied by a more coherently expressed
analysis.
Stephan
=20

On 7.3.2013 06:46 , "Rickard Sj=F6berg" <rickard.sjoberg@ericsson.com> wrot=
e:

>Hi Ye-Kui,
>
>Thanks for your feedback on my comments, your suggestions look good to me.
>
>Regarding discouraging fragmentation units (FUs) for live-encoding
>scenarios in section 4.7, I think using FUs does make sense when you do
>not have many non-VLC NAL units for aggregation. The spatial granularity
>of slices was 16x16 pixels in H.264 but is typically 64x64 for HEVC which
>means that MTU size matching is done with units that are 16x larger. This
>may lead to a larger number of smaller packets when slices are used
>compared to FUs. In addition, there is the HEVC rule of slice and tile
>boundaries that makes the slice granularity equal to the tile granularity
>for cases when slices span multiple tiles. Finally, FUs are easier to
>implement since you do not need to care about when to break your slice to
>not exceed the MTU size limit. I think both slices and FUs has their
>merits and the choice between them for live-encoding should be left for
>the implementer.
>
>Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and the
>POC MSB sync issue, I agree that this is a corner case that we probably
>will not see much of in practice. I have no text change suggestion at the
>moment.
>
>BR
>Rickard
>
>
>-----Original Message-----
>From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>Sent: den 24 juni 2013 01:00
>To: Rickard Sj=F6berg; payload@ietf.org
>Subject: RE: Submission of new versions of H.265/HEVC payload format
>
>Hi Rickard,
>
>Thanks for the careful review and the comments. Please see inline below.
>
>BR, YK
>
>> -----Original Message-----
>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>> Sent: Thursday, June 20, 2013 9:17 AM
>> To: Wang, Ye-Kui; payload@ietf.org
>> Subject: RE: Submission of new versions of H.265/HEVC payload format
>>=20
>> Dear all,
>>=20
>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
>> have some questions/comments.
>>=20
>> My first question is what extensions of HEVC that
>> draft-schierl-payload-rtp-
>> h265 is intended to cover? The draft mentions "future  scalable  or
>> 3D  video coding  extensions  of  this  specification", what extensions
>>do you refer to?
>> Is the intent to cover the all HEVC extensions in a single payload
>>specification?
>>=20
>
>[YK] That is in the semantics of LayerId (nuh_layer_id), where "this
>specification" should be replaced with "[HEVC]". It is sort of
>copy-and-paste error. Thanks for the good catching. No, there is no
>intention to cover HEVC extensions in this payload specification, though
>we intentionally to have the depacketization process and the use with
>feedback messages to work for HEVC scalability and 3DV extensions.
>
>> Another question for my understanding is why "Receivers MUST pass
>> picture timing SEI messages and decoding unit information SEI messages
>> to the decoder"?
>
>[YK] Generally, RTP receivers should/must pass all NAL units specified by
>the video coding spec to the video decoders. This is emphasized here for
>the two timing related SEI messages after it is said that picture output
>timing in RTP timestamps should be used instead (to avoid giving a wrong
>impression to readers that the SEI messages should be ignored). If an RTP
>receiver discards the SEI messages, then HRD conformance checking for the
>bitstream that was possible would be disabled, and also the information
>related to frame doubling or tripping would be lost.
>
>>=20
>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
>> fourth one does not seem to be a rule since there is no "MUST" or
>> "SHOULD" in the corresponding text.
>
>[YK] I see your point, it is only a "MAY" rule. An alternative to put
>this as a packetization rule is to put it as part of the semantics of NAL
>unit header (1.1.4), but that sub-section belongs to an overview wherein
>normative language (even "MAY") should not appear. One solution to this
>is to insert "Payload Header Usage" after 4.1 "RTP Header Usage" and
>include at least this item there. I will do this in the next version
>unless there is a better suggestion.
>
>> Further, the fifth one discourages using FUs, what are the reasons
>> behind that?
>
>[YK] The bullet item only discourages using FUs for live-encoding
>scenarios, wherein dependent slice segments should be used instead. This
>was added after a discussion (among the authors) on the need of whether
>to specify a payload structure for mixed FU and aggregation packets and
>from that discussion we concluded that encoding dependent slice segments
>at source coding level already allows for the use cases and using of FUs
>for live-encoding does not make sense. Please let us know if you think
>differently.
>
>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal. Isn't
>> there a possiblity that the MSB of PicOrderCntVal may differ between
>> the encoder and decoder?
>
>[YK] Good question. In theory this is indeed possible when random
>accessing to a bitstream is performed. However, it would not happen in
>conversational applications where the feedback messages may be used.
>Therefore, to me this would just work just fine. But please feel free to
>make other suggestions.
>
>>=20
>> The use of spatial-segmentation-idc may need some updates to be
>> useful, let me come back to that later on.
>>=20
>
>[YK] OK. Look forward to seeing your input herein.
>
>>=20
>> I have also a number of spelling suggestions for your considerations:
>>=20
>> Section 1.1:
>> Replace "community" by "communities"
>
>[YK] I guess both are OK. But anyway I just changed it per your
>suggestion (for the next version).
>
>>=20
>> Section 1.1.1:
>> Replace "In addition, interpolation filter" by "In addition, the
>> interpolation filter"
>
>[YK] Thanks - done.
>
>> Replace "skipping the transform coding" by "skipping the transform"
>> (transform_skip_flag of HEVC skips the transform, not the coding)
>>=20
>
> [YK] Done.
>
>> Section 1.1.2:
>> Replace:
>> "2) An indication of whether there is any parameter set within the
>> current coded video sequence that updates another parameter set of the
>> same type preceding in decoding order."
>> by:
>> "2) An indication of whether there is no parameter set update in the
>> coded video sequence."
>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>=20
>
>[YK] Changed the wording to "An indication of whether there is no
>parameter set within the current coded video sequence that updates
>another parameter set of the same type preceding in decoding order."
>
>> Section 4.7:
>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and "FU
>> Type:  6 bits" to avoid confusion with the Type in the payload header.
>>=20
>
>[YK] Good point again. I will change the field name to be "FuType".
>
>> Section 6:
>> Replace "recovery" by "recover"
>
>[YK] Done.
>
>>=20
>> Section 7.1:
>> Replace "level-id" by "level-idc"
>
>[YK] We are consistently using "id" for profile-id, level-id,
>max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>
>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>
> [YK] Done.
>
>>=20
>> Section 8:
>> Replace "two  payload-specific  feedback  messages" by "a
>> payload-specific feedback  message", since only SPLI is "Assigned in
>>this memo".
>> Also, consider removing references to H.264 in the last paragraph of
>> Section
>> 8 since the memo is about HEVC.
>
>[YK] Good catch again. Changed.
>
>>=20
>> Section 8.1:
>> Seems to me that "There MUST be exactly one RPSI contained in the FCI
>> field" should be "There MUST be exactly one SPLI contained in the FCI
>>field"
>
>[YK] Another good catch. Changed.
>
>>=20
>>=20
>> Best Regards,
>> Rickard Sj=F6berg
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>> Behalf Of Wang, Ye-Kui
>> Sent: den 11 juni 2013 19:00
>> To: payload@ietf.org
>> Subject: [payload] Submission of new versions of H.265/HEVC payload
>> format
>>=20
>> Dear All,
>>=20
>> We have just submitted versions 02 and 03 of
>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>=20
>> Version 02:
>> URL:           =20
>>http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>> h265-02.txt
>> Htmlized:      =20
>>http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>> Diff:          =20
>>http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>> 02
>>=20
>> Version 03:
>> URL:           =20
>>http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>> h265-03.txt
>> Htmlized:      =20
>>http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>> Diff:          =20
>>http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>> 03
>>=20
>> Version 02 includes huge changes compared to the earlier submitted
>> version 01. In a short summary, the authors have worked hard to try to
>> make the design complete, from both the payload structure and the
>> signaling points of view. Compared to version 02, version 03 only
>> contains a correction of the email address of an author.
>>=20
>> Due to that the industry is eager to deploy H.265/HEVC and other
>> standards bodies such as 3GPP rely on the payload format for support
>> of H.265/HEVC in RTP based video services, we need to progress this
>>draft relatively quickly.
>> Therefore, we would like to request quick reviews from interested
>> parties and also request for the WG status of this draft.
>>=20
>> BR, YK (on behalf of the authors)
>> _______________________________________________
>> 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 thdavies@cisco.com  Wed Jul  3 09:34:06 2013
Return-Path: <thdavies@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85D921F9DF3 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 09:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAaXgx8CvXrL for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 09:34:02 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id AE1E321F9DDE for <payload@ietf.org>; Wed,  3 Jul 2013 09:34:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14397; q=dns/txt; s=iport; t=1372869241; x=1374078841; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HkF3jvCvn6aW/VEO4kBxrtfyySIYAnUyBMBSRl8ouEI=; b=A+IntaxoDeE9yYy+kzpfw5qes3tGhNSeS9rcrXaNW/p+sSRuYucQdqJD YbgOI4il1l6SjOCGQld+jK4rB2hpaSiiawdcNXNVDG/q30OHIlhrUBnGJ zMDhSCsorRv88tQvyU2oxjce8dhLkNF2i5hoVIb5Msplkyhu2jB4dpgzd 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjoFACRR1FGQ/khR/2dsb2JhbABagwkyAULAOIEDFnSCIwEBAQQBAQEvAQU2BAYBDAQLDgMEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBBQsHh3QHBbsOjh8KC4E3BwaDZwOTd4NSgSmEeIskgxI7gS0IFw
X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="15275589"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 03 Jul 2013 16:33:59 +0000
Received: from [10.47.196.175] ([10.47.196.175]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r63GXv8i017347; Wed, 3 Jul 2013 16:33:57 GMT
Message-ID: <51D4526B.9040008@cisco.com>
Date: Wed, 03 Jul 2013 17:33:47 +0100
From: Thomas Davies <thdavies@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <CDF9959C.9ECA9%stewe@stewe.org>
In-Reply-To: <CDF9959C.9ECA9%stewe@stewe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 16:34:07 -0000

Hi Stephan

I think I agree with Rickard.

I think the text in question states a preference for _dependent_ slice 
segments, which have no error resiliency advantage over FUs. Is this 
just a typo?

<snip>

FUs SHOULD NOT be applied in live-encoding scenarios such as
       video telephony, video conferencing, live streaming and live
       broadcast, in which cases dependent slice segments SHOULD be used
       when a slice should be transported in multiple RTP packets.



</snip>

In general FUs may be used where error conditions are known to be 
benign, for greater efficiency, and also where for whatever reason the 
encoder cannot support MTU matching.

We also are formulating some more general comments on this area which we 
hope to provide more fully soon.

best regards

Thomas


On 03/07/13 17:22, Stephan Wenger wrote:
> Hi Rickard,
> Commenting only on slices vs. FUs.
> The preference for slices over FUs, historically, was pushed by myself
> into RFC 3984 for reasons of error resilience, and was moved over to this
> draft for the same reason.  Loose a slice, and you can recover at the next
> slice boundary; loose an FU, and you have to wait for the next slice
> header and throw away all trailing FUs.  RTP is in virtually all cases run
> over UDP, and in the typical Internet scenario UDP is lossy (in contrast
> to private, managed IP-network, which may have other constraints, but are
> not the IETF's main concern.)
> To set your remarks into context, let's first understand what we are
> talking about: the cost of slices is the overhead stemming from the
> insertion of slice headers (in-picture syntax prediction) and from the
> packet headers themselves.  And, of course, implementation complexity, but
> we should not be in the business to encourage implementor laziness when
> there would be a more complex, but better suited tool available.    The
> additional packetization overhead is only incurred when, as a result of
> incompetently filled packets (which, I agree, is more likely with 64x64
> CUs than with 16/16 macroblocks), an additional packet needs to be
> inserted.  You may remember a quick analysis of mine we discussed way back
> early in JCT, where we (I think) agreed that the practical impact is
> negligible in almost all non-tile scenarios (mostly because an additional
> overhead of 50 bytes or so--3% or less of the coded picture size) is
> incurred statistically only rarely (only in those cases where an
> additional packet would need to be generated because of the video coding
> related overhead for the use of slices).  The prediction overhead of the
> use of regular slices has been shown to be substantial--the price one
> needs to pay for independent decodability--but for entropy slices that
> overhead virtually does not exist.
> With respect to tiles, I think you have a point though, especially when
> considering the type of massive parallel implementations for relatively
> small picture sizes some folks have been considering.
> OTOH, because FUs are trivial to implement--some say in contrast to
> slices--and because (I hope) we all agree that using FUs in error prone
> scenarios is a bad idea if you could use slices (but for reasons like the
> tile connection you mentioned), the draft should IMO continue to set a
> preference for the use of regular slices over FUs.  To avoid
> underperforming systems due to implementer laziness.
> However, this is the IETF.  We don't have to worry about the word-count of
> explanatory language.  In fact, explaining such complex tradeoffs and
> relationships is generally encouraged here.  So let's just do that:
> express a preference of the use of regular slices (SHOULD) when you expect
> losses and can use them (real-time encoding, no tiling structure that
> would lead to unacceptable packetization overhead); and suggest (MAY) the
> use of FUs in other scenarios.  Accompanied by a more coherently expressed
> analysis.
> Stephan
>
>
> On 7.3.2013 06:46 , "Rickard Sjöberg"<rickard.sjoberg@ericsson.com>  wrote:
>
>> Hi Ye-Kui,
>>
>> Thanks for your feedback on my comments, your suggestions look good to me.
>>
>> Regarding discouraging fragmentation units (FUs) for live-encoding
>> scenarios in section 4.7, I think using FUs does make sense when you do
>> not have many non-VLC NAL units for aggregation. The spatial granularity
>> of slices was 16x16 pixels in H.264 but is typically 64x64 for HEVC which
>> means that MTU size matching is done with units that are 16x larger. This
>> may lead to a larger number of smaller packets when slices are used
>> compared to FUs. In addition, there is the HEVC rule of slice and tile
>> boundaries that makes the slice granularity equal to the tile granularity
>> for cases when slices span multiple tiles. Finally, FUs are easier to
>> implement since you do not need to care about when to break your slice to
>> not exceed the MTU size limit. I think both slices and FUs has their
>> merits and the choice between them for live-encoding should be left for
>> the implementer.
>>
>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and the
>> POC MSB sync issue, I agree that this is a corner case that we probably
>> will not see much of in practice. I have no text change suggestion at the
>> moment.
>>
>> BR
>> Rickard
>>
>>
>> -----Original Message-----
>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>> Sent: den 24 juni 2013 01:00
>> To: Rickard Sjöberg; payload@ietf.org
>> Subject: RE: Submission of new versions of H.265/HEVC payload format
>>
>> Hi Rickard,
>>
>> Thanks for the careful review and the comments. Please see inline below.
>>
>> BR, YK
>>
>>> -----Original Message-----
>>> From: Rickard Sjöberg [mailto:rickard.sjoberg@ericsson.com]
>>> Sent: Thursday, June 20, 2013 9:17 AM
>>> To: Wang, Ye-Kui; payload@ietf.org
>>> Subject: RE: Submission of new versions of H.265/HEVC payload format
>>>
>>> Dear all,
>>>
>>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
>>> have some questions/comments.
>>>
>>> My first question is what extensions of HEVC that
>>> draft-schierl-payload-rtp-
>>> h265 is intended to cover? The draft mentions "future  scalable  or
>>> 3D  video coding  extensions  of  this  specification", what extensions
>>> do you refer to?
>>> Is the intent to cover the all HEVC extensions in a single payload
>>> specification?
>>>
>> [YK] That is in the semantics of LayerId (nuh_layer_id), where "this
>> specification" should be replaced with "[HEVC]". It is sort of
>> copy-and-paste error. Thanks for the good catching. No, there is no
>> intention to cover HEVC extensions in this payload specification, though
>> we intentionally to have the depacketization process and the use with
>> feedback messages to work for HEVC scalability and 3DV extensions.
>>
>>> Another question for my understanding is why "Receivers MUST pass
>>> picture timing SEI messages and decoding unit information SEI messages
>>> to the decoder"?
>> [YK] Generally, RTP receivers should/must pass all NAL units specified by
>> the video coding spec to the video decoders. This is emphasized here for
>> the two timing related SEI messages after it is said that picture output
>> timing in RTP timestamps should be used instead (to avoid giving a wrong
>> impression to readers that the SEI messages should be ignored). If an RTP
>> receiver discards the SEI messages, then HRD conformance checking for the
>> bitstream that was possible would be disabled, and also the information
>> related to frame doubling or tripping would be lost.
>>
>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
>>> fourth one does not seem to be a rule since there is no "MUST" or
>>> "SHOULD" in the corresponding text.
>> [YK] I see your point, it is only a "MAY" rule. An alternative to put
>> this as a packetization rule is to put it as part of the semantics of NAL
>> unit header (1.1.4), but that sub-section belongs to an overview wherein
>> normative language (even "MAY") should not appear. One solution to this
>> is to insert "Payload Header Usage" after 4.1 "RTP Header Usage" and
>> include at least this item there. I will do this in the next version
>> unless there is a better suggestion.
>>
>>> Further, the fifth one discourages using FUs, what are the reasons
>>> behind that?
>> [YK] The bullet item only discourages using FUs for live-encoding
>> scenarios, wherein dependent slice segments should be used instead. This
>> was added after a discussion (among the authors) on the need of whether
>> to specify a payload structure for mixed FU and aggregation packets and
> >from that discussion we concluded that encoding dependent slice segments
>> at source coding level already allows for the use cases and using of FUs
>> for live-encoding does not make sense. Please let us know if you think
>> differently.
>>
>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal. Isn't
>>> there a possiblity that the MSB of PicOrderCntVal may differ between
>>> the encoder and decoder?
>> [YK] Good question. In theory this is indeed possible when random
>> accessing to a bitstream is performed. However, it would not happen in
>> conversational applications where the feedback messages may be used.
>> Therefore, to me this would just work just fine. But please feel free to
>> make other suggestions.
>>
>>> The use of spatial-segmentation-idc may need some updates to be
>>> useful, let me come back to that later on.
>>>
>> [YK] OK. Look forward to seeing your input herein.
>>
>>> I have also a number of spelling suggestions for your considerations:
>>>
>>> Section 1.1:
>>> Replace "community" by "communities"
>> [YK] I guess both are OK. But anyway I just changed it per your
>> suggestion (for the next version).
>>
>>> Section 1.1.1:
>>> Replace "In addition, interpolation filter" by "In addition, the
>>> interpolation filter"
>> [YK] Thanks - done.
>>
>>> Replace "skipping the transform coding" by "skipping the transform"
>>> (transform_skip_flag of HEVC skips the transform, not the coding)
>>>
>> [YK] Done.
>>
>>> Section 1.1.2:
>>> Replace:
>>> "2) An indication of whether there is any parameter set within the
>>> current coded video sequence that updates another parameter set of the
>>> same type preceding in decoding order."
>>> by:
>>> "2) An indication of whether there is no parameter set update in the
>>> coded video sequence."
>>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>>
>> [YK] Changed the wording to "An indication of whether there is no
>> parameter set within the current coded video sequence that updates
>> another parameter set of the same type preceding in decoding order."
>>
>>> Section 4.7:
>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and "FU
>>> Type:  6 bits" to avoid confusion with the Type in the payload header.
>>>
>> [YK] Good point again. I will change the field name to be "FuType".
>>
>>> Section 6:
>>> Replace "recovery" by "recover"
>> [YK] Done.
>>
>>> Section 7.1:
>>> Replace "level-id" by "level-idc"
>> [YK] We are consistently using "id" for profile-id, level-id,
>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>>
>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>> [YK] Done.
>>
>>> Section 8:
>>> Replace "two  payload-specific  feedback  messages" by "a
>>> payload-specific feedback  message", since only SPLI is "Assigned in
>>> this memo".
>>> Also, consider removing references to H.264 in the last paragraph of
>>> Section
>>> 8 since the memo is about HEVC.
>> [YK] Good catch again. Changed.
>>
>>> Section 8.1:
>>> Seems to me that "There MUST be exactly one RPSI contained in the FCI
>>> field" should be "There MUST be exactly one SPLI contained in the FCI
>>> field"
>> [YK] Another good catch. Changed.
>>
>>>
>>> Best Regards,
>>> Rickard Sjöberg
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>> Behalf Of Wang, Ye-Kui
>>> Sent: den 11 juni 2013 19:00
>>> To: payload@ietf.org
>>> Subject: [payload] Submission of new versions of H.265/HEVC payload
>>> format
>>>
>>> Dear All,
>>>
>>> We have just submitted versions 02 and 03 of
>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>>
>>> Version 02:
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>> h265-02.txt
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-
>>> 02
>>>
>>> Version 03:
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>> h265-03.txt
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-
>>> 03
>>>
>>> Version 02 includes huge changes compared to the earlier submitted
>>> version 01. In a short summary, the authors have worked hard to try to
>>> make the design complete, from both the payload structure and the
>>> signaling points of view. Compared to version 02, version 03 only
>>> contains a correction of the email address of an author.
>>>
>>> Due to that the industry is eager to deploy H.265/HEVC and other
>>> standards bodies such as 3GPP rely on the payload format for support
>>> of H.265/HEVC in RTP based video services, we need to progress this
>>> draft relatively quickly.
>>> Therefore, we would like to request quick reviews from interested
>>> parties and also request for the WG status of this draft.
>>>
>>> BR, YK (on behalf of the authors)
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>> _______________________________________________
>> 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 yekuiw@qti.qualcomm.com  Wed Jul  3 11:43:06 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3144E11E81C6 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 11:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42-GqO-OBheZ for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 11:43:02 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF96D11E81F3 for <payload@ietf.org>; Wed,  3 Jul 2013 11:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372876981; x=1404412981; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ng2H/50p5WS3wVePV8jsU1UqKVeBPlj0Thl56MhLJSI=; b=YYA6EjvAaE4C+OIdnOMtT9GUTQkK5vGWn2C8MCGBphtTu6HqQ2ifc8FK iBep5FWWJN3+LT9KW3EHI37/BxvaNSUGdkOtaRSsh3Q4OHBpZJJzKSK/a jOrzwIhOTT3X0cyXLGRtiXTGTLGnQ2pScfHWRx7pV+M8xEG1Y50GOE+G2 4=;
X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="46697838"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 03 Jul 2013 11:42:54 -0700
X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="509213977"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 11:42:54 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 11:42:54 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Thomas Davies <thdavies@cisco.com>, Stephan Wenger <stewe@stewe.org>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: AQHOeAsm0Zg6PfrvRkmdBC2mn9aYvJlTR1dw
Date: Wed, 3 Jul 2013 18:42:53 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com>
In-Reply-To: <51D4526B.9040008@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.45.230.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 18:43:06 -0000

Hi All,

I drafted an email replying directly to Rickard but did not finish and ther=
e was a meeting (and then Stephan's and Thomas' emails came).

I wanted to comment that Rickard was comparing the use of FUs vs slices, no=
t FUs vs dependent slices, while the recommendation in the draft is recomme=
nding use of dependent slices over FUs in live-encoding scenarios (so this =
answers Thomas question: the intention was dependent slices ).=20

In any case, it does not make much sense to try MTU size matching and at th=
e same time use either dependent slices or FUs, because dependent slices an=
d FUs should not be used when there are considerable packet losses, while M=
TU size matching should be applied when there are considerable packet losse=
s.

For live encoding, whenever splitting of a regular slice is needed, the spl=
itting can be done by the encoder using dependent slices - and the encoder =
has more knowledge and is more powerful than the RTP packetizer and thus ca=
n do a better job for the splitting.=20

BR, YK


> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Thomas Davies
> Sent: Wednesday, July 03, 2013 9:34 AM
> To: Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Stephan
>=20
> I think I agree with Rickard.
>=20
> I think the text in question states a preference for _dependent_ slice se=
gments,
> which have no error resiliency advantage over FUs. Is this just a typo?
>=20
> <snip>
>=20
> FUs SHOULD NOT be applied in live-encoding scenarios such as
>        video telephony, video conferencing, live streaming and live
>        broadcast, in which cases dependent slice segments SHOULD be used
>        when a slice should be transported in multiple RTP packets.
>=20
>=20
>=20
> </snip>
>=20
> In general FUs may be used where error conditions are known to be benign,=
 for
> greater efficiency, and also where for whatever reason the encoder cannot
> support MTU matching.
>=20
> We also are formulating some more general comments on this area which we
> hope to provide more fully soon.
>=20
> best regards
>=20
> Thomas
>=20
>=20
> On 03/07/13 17:22, Stephan Wenger wrote:
> > Hi Rickard,
> > Commenting only on slices vs. FUs.
> > The preference for slices over FUs, historically, was pushed by myself
> > into RFC 3984 for reasons of error resilience, and was moved over to
> > this draft for the same reason.  Loose a slice, and you can recover at
> > the next slice boundary; loose an FU, and you have to wait for the
> > next slice header and throw away all trailing FUs.  RTP is in
> > virtually all cases run over UDP, and in the typical Internet scenario
> > UDP is lossy (in contrast to private, managed IP-network, which may
> > have other constraints, but are not the IETF's main concern.) To set
> > your remarks into context, let's first understand what we are talking
> > about: the cost of slices is the overhead stemming from the insertion
> > of slice headers (in-picture syntax prediction) and from the packet
> > headers themselves.  And, of course, implementation complexity, but we
> > should not be in the business to encourage implementor laziness when
> > there would be a more complex, but better suited tool available.    The
> > additional packetization overhead is only incurred when, as a result
> > of incompetently filled packets (which, I agree, is more likely with
> > 64x64 CUs than with 16/16 macroblocks), an additional packet needs to
> > be inserted.  You may remember a quick analysis of mine we discussed
> > way back early in JCT, where we (I think) agreed that the practical
> > impact is negligible in almost all non-tile scenarios (mostly because
> > an additional overhead of 50 bytes or so--3% or less of the coded
> > picture size) is incurred statistically only rarely (only in those
> > cases where an additional packet would need to be generated because of
> > the video coding related overhead for the use of slices).  The
> > prediction overhead of the use of regular slices has been shown to be
> > substantial--the price one needs to pay for independent
> > decodability--but for entropy slices that overhead virtually does not e=
xist.
> > With respect to tiles, I think you have a point though, especially
> > when considering the type of massive parallel implementations for
> > relatively small picture sizes some folks have been considering.
> > OTOH, because FUs are trivial to implement--some say in contrast to
> > slices--and because (I hope) we all agree that using FUs in error
> > prone scenarios is a bad idea if you could use slices (but for reasons
> > like the tile connection you mentioned), the draft should IMO continue
> > to set a preference for the use of regular slices over FUs.  To avoid
> > underperforming systems due to implementer laziness.
> > However, this is the IETF.  We don't have to worry about the
> > word-count of explanatory language.  In fact, explaining such complex
> > tradeoffs and relationships is generally encouraged here.  So let's jus=
t do that:
> > express a preference of the use of regular slices (SHOULD) when you
> > expect losses and can use them (real-time encoding, no tiling
> > structure that would lead to unacceptable packetization overhead); and
> > suggest (MAY) the use of FUs in other scenarios.  Accompanied by a
> > more coherently expressed analysis.
> > Stephan
> >
> >
> > On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>  =
wrote:
> >
> >> Hi Ye-Kui,
> >>
> >> Thanks for your feedback on my comments, your suggestions look good to
> me.
> >>
> >> Regarding discouraging fragmentation units (FUs) for live-encoding
> >> scenarios in section 4.7, I think using FUs does make sense when you
> >> do not have many non-VLC NAL units for aggregation. The spatial
> >> granularity of slices was 16x16 pixels in H.264 but is typically
> >> 64x64 for HEVC which means that MTU size matching is done with units
> >> that are 16x larger. This may lead to a larger number of smaller
> >> packets when slices are used compared to FUs. In addition, there is
> >> the HEVC rule of slice and tile boundaries that makes the slice
> >> granularity equal to the tile granularity for cases when slices span
> >> multiple tiles. Finally, FUs are easier to implement since you do not
> >> need to care about when to break your slice to not exceed the MTU
> >> size limit. I think both slices and FUs has their merits and the
> >> choice between them for live-encoding should be left for the implement=
er.
> >>
> >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
> >> the POC MSB sync issue, I agree that this is a corner case that we
> >> probably will not see much of in practice. I have no text change
> >> suggestion at the moment.
> >>
> >> BR
> >> Rickard
> >>
> >>
> >> -----Original Message-----
> >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >> Sent: den 24 juni 2013 01:00
> >> To: Rickard Sj=F6berg; payload@ietf.org
> >> Subject: RE: Submission of new versions of H.265/HEVC payload format
> >>
> >> Hi Rickard,
> >>
> >> Thanks for the careful review and the comments. Please see inline belo=
w.
> >>
> >> BR, YK
> >>
> >>> -----Original Message-----
> >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>> Sent: Thursday, June 20, 2013 9:17 AM
> >>> To: Wang, Ye-Kui; payload@ietf.org
> >>> Subject: RE: Submission of new versions of H.265/HEVC payload format
> >>>
> >>> Dear all,
> >>>
> >>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
> >>> have some questions/comments.
> >>>
> >>> My first question is what extensions of HEVC that
> >>> draft-schierl-payload-rtp-
> >>> h265 is intended to cover? The draft mentions "future  scalable  or
> >>> 3D  video coding  extensions  of  this  specification", what
> >>> extensions do you refer to?
> >>> Is the intent to cover the all HEVC extensions in a single payload
> >>> specification?
> >>>
> >> [YK] That is in the semantics of LayerId (nuh_layer_id), where "this
> >> specification" should be replaced with "[HEVC]". It is sort of
> >> copy-and-paste error. Thanks for the good catching. No, there is no
> >> intention to cover HEVC extensions in this payload specification,
> >> though we intentionally to have the depacketization process and the
> >> use with feedback messages to work for HEVC scalability and 3DV extens=
ions.
> >>
> >>> Another question for my understanding is why "Receivers MUST pass
> >>> picture timing SEI messages and decoding unit information SEI
> >>> messages to the decoder"?
> >> [YK] Generally, RTP receivers should/must pass all NAL units
> >> specified by the video coding spec to the video decoders. This is
> >> emphasized here for the two timing related SEI messages after it is
> >> said that picture output timing in RTP timestamps should be used
> >> instead (to avoid giving a wrong impression to readers that the SEI
> >> messages should be ignored). If an RTP receiver discards the SEI
> >> messages, then HRD conformance checking for the bitstream that was
> >> possible would be disabled, and also the information related to frame
> doubling or tripping would be lost.
> >>
> >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
> >>> fourth one does not seem to be a rule since there is no "MUST" or
> >>> "SHOULD" in the corresponding text.
> >> [YK] I see your point, it is only a "MAY" rule. An alternative to put
> >> this as a packetization rule is to put it as part of the semantics of
> >> NAL unit header (1.1.4), but that sub-section belongs to an overview
> >> wherein normative language (even "MAY") should not appear. One
> >> solution to this is to insert "Payload Header Usage" after 4.1 "RTP
> >> Header Usage" and include at least this item there. I will do this in
> >> the next version unless there is a better suggestion.
> >>
> >>> Further, the fifth one discourages using FUs, what are the reasons
> >>> behind that?
> >> [YK] The bullet item only discourages using FUs for live-encoding
> >> scenarios, wherein dependent slice segments should be used instead.
> >> This was added after a discussion (among the authors) on the need of
> >> whether to specify a payload structure for mixed FU and aggregation
> >> packets and
> > >from that discussion we concluded that encoding dependent slice
> > >segments
> >> at source coding level already allows for the use cases and using of
> >> FUs for live-encoding does not make sense. Please let us know if you
> >> think differently.
> >>
> >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> >>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
> >>> between the encoder and decoder?
> >> [YK] Good question. In theory this is indeed possible when random
> >> accessing to a bitstream is performed. However, it would not happen
> >> in conversational applications where the feedback messages may be used=
.
> >> Therefore, to me this would just work just fine. But please feel free
> >> to make other suggestions.
> >>
> >>> The use of spatial-segmentation-idc may need some updates to be
> >>> useful, let me come back to that later on.
> >>>
> >> [YK] OK. Look forward to seeing your input herein.
> >>
> >>> I have also a number of spelling suggestions for your considerations:
> >>>
> >>> Section 1.1:
> >>> Replace "community" by "communities"
> >> [YK] I guess both are OK. But anyway I just changed it per your
> >> suggestion (for the next version).
> >>
> >>> Section 1.1.1:
> >>> Replace "In addition, interpolation filter" by "In addition, the
> >>> interpolation filter"
> >> [YK] Thanks - done.
> >>
> >>> Replace "skipping the transform coding" by "skipping the transform"
> >>> (transform_skip_flag of HEVC skips the transform, not the coding)
> >>>
> >> [YK] Done.
> >>
> >>> Section 1.1.2:
> >>> Replace:
> >>> "2) An indication of whether there is any parameter set within the
> >>> current coded video sequence that updates another parameter set of
> >>> the same type preceding in decoding order."
> >>> by:
> >>> "2) An indication of whether there is no parameter set update in the
> >>> coded video sequence."
> >>> since that is what no_parameter_set_update_flag in HEVC indicates.
> >>>
> >> [YK] Changed the wording to "An indication of whether there is no
> >> parameter set within the current coded video sequence that updates
> >> another parameter set of the same type preceding in decoding order."
> >>
> >>> Section 4.7:
> >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
> >>> "FU
> >>> Type:  6 bits" to avoid confusion with the Type in the payload header=
.
> >>>
> >> [YK] Good point again. I will change the field name to be "FuType".
> >>
> >>> Section 6:
> >>> Replace "recovery" by "recover"
> >> [YK] Done.
> >>
> >>> Section 7.1:
> >>> Replace "level-id" by "level-idc"
> >> [YK] We are consistently using "id" for profile-id, level-id,
> >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> >>
> >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >> [YK] Done.
> >>
> >>> Section 8:
> >>> Replace "two  payload-specific  feedback  messages" by "a
> >>> payload-specific feedback  message", since only SPLI is "Assigned in
> >>> this memo".
> >>> Also, consider removing references to H.264 in the last paragraph of
> >>> Section
> >>> 8 since the memo is about HEVC.
> >> [YK] Good catch again. Changed.
> >>
> >>> Section 8.1:
> >>> Seems to me that "There MUST be exactly one RPSI contained in the
> >>> FCI field" should be "There MUST be exactly one SPLI contained in
> >>> the FCI field"
> >> [YK] Another good catch. Changed.
> >>
> >>>
> >>> Best Regards,
> >>> Rickard Sj=F6berg
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> >>> Behalf Of Wang, Ye-Kui
> >>> Sent: den 11 juni 2013 19:00
> >>> To: payload@ietf.org
> >>> Subject: [payload] Submission of new versions of H.265/HEVC payload
> >>> format
> >>>
> >>> Dear All,
> >>>
> >>> We have just submitted versions 02 and 03 of
> >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> >>>
> >>> Version 02:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-02.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 02
> >>>
> >>> Version 03:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-03.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 03
> >>>
> >>> Version 02 includes huge changes compared to the earlier submitted
> >>> version 01. In a short summary, the authors have worked hard to try
> >>> to make the design complete, from both the payload structure and the
> >>> signaling points of view. Compared to version 02, version 03 only
> >>> contains a correction of the email address of an author.
> >>>
> >>> Due to that the industry is eager to deploy H.265/HEVC and other
> >>> standards bodies such as 3GPP rely on the payload format for support
> >>> of H.265/HEVC in RTP based video services, we need to progress this
> >>> draft relatively quickly.
> >>> Therefore, we would like to request quick reviews from interested
> >>> parties and also request for the WG status of this draft.
> >>>
> >>> BR, YK (on behalf of the authors)
> >>> _______________________________________________
> >>> payload mailing list
> >>> payload@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/payload
> >>>
> >> _______________________________________________
> >> 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
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

From rickard.sjoberg@ericsson.com  Wed Jul  3 12:37:47 2013
Return-Path: <rickard.sjoberg@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64D221F9DA2 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 12:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.124
X-Spam-Level: 
X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NuE5LTyXx52 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 12:37:42 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DE82021F9D28 for <payload@ietf.org>; Wed,  3 Jul 2013 12:37:41 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-6d-51d47d80cb39
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.3E.11907.08D74D15; Wed,  3 Jul 2013 21:37:36 +0200 (CEST)
Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 21:37:35 +0200
From: =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, Thomas Davies <thdavies@cisco.com>, Stephan Wenger <stewe@stewe.org>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC	payload format
Thread-Index: AQHOeB0qECijCvKjP0KcCY1a6HUH2plTU6Yw
Date: Wed, 3 Jul 2013 19:37:35 +0000
Message-ID: <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW5D7ZVAg86PkhaXLp5lsrjeuInd ov/vNmaLJ2uOMTuweEz5vZHVY8mSn0wei6Y+Y/RYvP49YwBLFJdNSmpOZllqkb5dAlfG70dp BQ/6GSuudU5ka2C8U9zFyMkhIWAi8avlDCOELSZx4d56ti5GLg4hgaOMEtPfXIVyFjNKfP7y lgWkik3AXeLkmw4mEFtEoERi8aEHzCA2s4CmxKHPj9lAbGGBAImXB+4C1XMA1QRKHDyXClFu JLF7RS8jSJhFQEXi92uwal4BX4nvP36zQqyaxCjx7dtEsFWcAsESWxtWsYLYjAKyEl8aV0Ot Epe49WQ+E8TRAhJL9pxnhrBFJV4+/scKYStKtD9tYISo15O4MXUKG4StLbFs4WtmiMWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjuLU4qTcdCODTYzAaDq45bfFDsbLf20OMUpzsCiJ 827ROxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFF5+PiuQUeFRcbWrU05v+5lHFQwuDN t+0fWXnnZ9VXLNAymt24NezqbdFy5Qt+8d8SJkzeybZr9sdnKw5YnXybwXuIw1JB+U5i3s5W u49eImysOZOUpr3R42/5lrqLk0Vr9tr9cyQffj875c2HfzMOuzEWrThbueTynt1Gj+/9fb0q 5a2u04UNSizFGYmGWsxFxYkAstK32XQCAAA=
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 19:37:47 -0000

Dear all,

I wrote slices and not dependent slices since the slice granularity and sli=
ce/tile rule applies to both slices and dependent slices. Sorry for the con=
fusion. I will now use 'independent slices' and 'dependent slices' to disti=
nguish between them.

I do not question the use of independent slices, I find them useful in some=
 applications.

But the current RTP payload text says:

"FUs SHOULD NOT be applied in live-encoding scenarios such as
      video telephony, video conferencing, live streaming and live
      broadcast, in which cases dependent slice segments SHOULD be used
      when a slice should be transported in multiple RTP packets."

I believe that FUs are a viable option to dependent slices for the reasons =
I listed in my previous e-mail and think that we should not recommend depen=
dent slices over FUs but leave it to the implementer.

BR
Rickard


-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Wang, Ye-Kui
Sent: den 3 juli 2013 20:43
To: Thomas Davies; Stephan Wenger
Cc: payload@ietf.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Hi All,

I drafted an email replying directly to Rickard but did not finish and ther=
e was a meeting (and then Stephan's and Thomas' emails came).

I wanted to comment that Rickard was comparing the use of FUs vs slices, no=
t FUs vs dependent slices, while the recommendation in the draft is recomme=
nding use of dependent slices over FUs in live-encoding scenarios (so this =
answers Thomas question: the intention was dependent slices ).=20

In any case, it does not make much sense to try MTU size matching and at th=
e same time use either dependent slices or FUs, because dependent slices an=
d FUs should not be used when there are considerable packet losses, while M=
TU size matching should be applied when there are considerable packet losse=
s.

For live encoding, whenever splitting of a regular slice is needed, the spl=
itting can be done by the encoder using dependent slices - and the encoder =
has more knowledge and is more powerful than the RTP packetizer and thus ca=
n do a better job for the splitting.=20

BR, YK


> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> Behalf Of Thomas Davies
> Sent: Wednesday, July 03, 2013 9:34 AM
> To: Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Hi Stephan
>=20
> I think I agree with Rickard.
>=20
> I think the text in question states a preference for _dependent_ slice=20
> segments, which have no error resiliency advantage over FUs. Is this just=
 a typo?
>=20
> <snip>
>=20
> FUs SHOULD NOT be applied in live-encoding scenarios such as
>        video telephony, video conferencing, live streaming and live
>        broadcast, in which cases dependent slice segments SHOULD be used
>        when a slice should be transported in multiple RTP packets.
>=20
>=20
>=20
> </snip>
>=20
> In general FUs may be used where error conditions are known to be=20
> benign, for greater efficiency, and also where for whatever reason the=20
> encoder cannot support MTU matching.
>=20
> We also are formulating some more general comments on this area which=20
> we hope to provide more fully soon.
>=20
> best regards
>=20
> Thomas
>=20
>=20
> On 03/07/13 17:22, Stephan Wenger wrote:
> > Hi Rickard,
> > Commenting only on slices vs. FUs.
> > The preference for slices over FUs, historically, was pushed by=20
> > myself into RFC 3984 for reasons of error resilience, and was moved=20
> > over to this draft for the same reason.  Loose a slice, and you can=20
> > recover at the next slice boundary; loose an FU, and you have to=20
> > wait for the next slice header and throw away all trailing FUs.  RTP=20
> > is in virtually all cases run over UDP, and in the typical Internet=20
> > scenario UDP is lossy (in contrast to private, managed IP-network,=20
> > which may have other constraints, but are not the IETF's main=20
> > concern.) To set your remarks into context, let's first understand=20
> > what we are talking
> > about: the cost of slices is the overhead stemming from the=20
> > insertion of slice headers (in-picture syntax prediction) and from=20
> > the packet headers themselves.  And, of course, implementation=20
> > complexity, but we should not be in the business to encourage implement=
or laziness when
> > there would be a more complex, but better suited tool available.    The
> > additional packetization overhead is only incurred when, as a result=20
> > of incompetently filled packets (which, I agree, is more likely with
> > 64x64 CUs than with 16/16 macroblocks), an additional packet needs=20
> > to be inserted.  You may remember a quick analysis of mine we=20
> > discussed way back early in JCT, where we (I think) agreed that the=20
> > practical impact is negligible in almost all non-tile scenarios=20
> > (mostly because an additional overhead of 50 bytes or so--3% or less=20
> > of the coded picture size) is incurred statistically only rarely=20
> > (only in those cases where an additional packet would need to be=20
> > generated because of the video coding related overhead for the use=20
> > of slices).  The prediction overhead of the use of regular slices=20
> > has been shown to be substantial--the price one needs to pay for=20
> > independent decodability--but for entropy slices that overhead virtuall=
y does not exist.
> > With respect to tiles, I think you have a point though, especially=20
> > when considering the type of massive parallel implementations for=20
> > relatively small picture sizes some folks have been considering.
> > OTOH, because FUs are trivial to implement--some say in contrast to=20
> > slices--and because (I hope) we all agree that using FUs in error=20
> > prone scenarios is a bad idea if you could use slices (but for=20
> > reasons like the tile connection you mentioned), the draft should=20
> > IMO continue to set a preference for the use of regular slices over=20
> > FUs.  To avoid underperforming systems due to implementer laziness.
> > However, this is the IETF.  We don't have to worry about the=20
> > word-count of explanatory language.  In fact, explaining such=20
> > complex tradeoffs and relationships is generally encouraged here.  So l=
et's just do that:
> > express a preference of the use of regular slices (SHOULD) when you=20
> > expect losses and can use them (real-time encoding, no tiling=20
> > structure that would lead to unacceptable packetization overhead);=20
> > and suggest (MAY) the use of FUs in other scenarios.  Accompanied by=20
> > a more coherently expressed analysis.
> > Stephan
> >
> >
> > On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>  =
wrote:
> >
> >> Hi Ye-Kui,
> >>
> >> Thanks for your feedback on my comments, your suggestions look good=20
> >> to
> me.
> >>
> >> Regarding discouraging fragmentation units (FUs) for live-encoding=20
> >> scenarios in section 4.7, I think using FUs does make sense when=20
> >> you do not have many non-VLC NAL units for aggregation. The spatial=20
> >> granularity of slices was 16x16 pixels in H.264 but is typically
> >> 64x64 for HEVC which means that MTU size matching is done with=20
> >> units that are 16x larger. This may lead to a larger number of=20
> >> smaller packets when slices are used compared to FUs. In addition,=20
> >> there is the HEVC rule of slice and tile boundaries that makes the=20
> >> slice granularity equal to the tile granularity for cases when=20
> >> slices span multiple tiles. Finally, FUs are easier to implement=20
> >> since you do not need to care about when to break your slice to not=20
> >> exceed the MTU size limit. I think both slices and FUs has their=20
> >> merits and the choice between them for live-encoding should be left fo=
r the implementer.
> >>
> >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and=20
> >> the POC MSB sync issue, I agree that this is a corner case that we=20
> >> probably will not see much of in practice. I have no text change=20
> >> suggestion at the moment.
> >>
> >> BR
> >> Rickard
> >>
> >>
> >> -----Original Message-----
> >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >> Sent: den 24 juni 2013 01:00
> >> To: Rickard Sj=F6berg; payload@ietf.org
> >> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> >> format
> >>
> >> Hi Rickard,
> >>
> >> Thanks for the careful review and the comments. Please see inline belo=
w.
> >>
> >> BR, YK
> >>
> >>> -----Original Message-----
> >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>> Sent: Thursday, June 20, 2013 9:17 AM
> >>> To: Wang, Ye-Kui; payload@ietf.org
> >>> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> >>> format
> >>>
> >>> Dear all,
> >>>
> >>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and=20
> >>> have some questions/comments.
> >>>
> >>> My first question is what extensions of HEVC that
> >>> draft-schierl-payload-rtp-
> >>> h265 is intended to cover? The draft mentions "future  scalable =20
> >>> or 3D  video coding  extensions  of  this  specification", what=20
> >>> extensions do you refer to?
> >>> Is the intent to cover the all HEVC extensions in a single payload=20
> >>> specification?
> >>>
> >> [YK] That is in the semantics of LayerId (nuh_layer_id), where=20
> >> "this specification" should be replaced with "[HEVC]". It is sort=20
> >> of copy-and-paste error. Thanks for the good catching. No, there is=20
> >> no intention to cover HEVC extensions in this payload=20
> >> specification, though we intentionally to have the depacketization=20
> >> process and the use with feedback messages to work for HEVC scalabilit=
y and 3DV extensions.
> >>
> >>> Another question for my understanding is why "Receivers MUST pass=20
> >>> picture timing SEI messages and decoding unit information SEI=20
> >>> messages to the decoder"?
> >> [YK] Generally, RTP receivers should/must pass all NAL units=20
> >> specified by the video coding spec to the video decoders. This is=20
> >> emphasized here for the two timing related SEI messages after it is=20
> >> said that picture output timing in RTP timestamps should be used=20
> >> instead (to avoid giving a wrong impression to readers that the SEI=20
> >> messages should be ignored). If an RTP receiver discards the SEI=20
> >> messages, then HRD conformance checking for the bitstream that was=20
> >> possible would be disabled, and also the information related to=20
> >> frame
> doubling or tripping would be lost.
> >>
> >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The=20
> >>> fourth one does not seem to be a rule since there is no "MUST" or=20
> >>> "SHOULD" in the corresponding text.
> >> [YK] I see your point, it is only a "MAY" rule. An alternative to=20
> >> put this as a packetization rule is to put it as part of the=20
> >> semantics of NAL unit header (1.1.4), but that sub-section belongs=20
> >> to an overview wherein normative language (even "MAY") should not=20
> >> appear. One solution to this is to insert "Payload Header Usage"=20
> >> after 4.1 "RTP Header Usage" and include at least this item there.=20
> >> I will do this in the next version unless there is a better suggestion=
.
> >>
> >>> Further, the fifth one discourages using FUs, what are the reasons=20
> >>> behind that?
> >> [YK] The bullet item only discourages using FUs for live-encoding=20
> >> scenarios, wherein dependent slice segments should be used instead.
> >> This was added after a discussion (among the authors) on the need=20
> >> of whether to specify a payload structure for mixed FU and=20
> >> aggregation packets and
> > >from that discussion we concluded that encoding dependent slice=20
> > >segments
> >> at source coding level already allows for the use cases and using=20
> >> of FUs for live-encoding does not make sense. Please let us know if=20
> >> you think differently.
> >>
> >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> >>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ=20
> >>> between the encoder and decoder?
> >> [YK] Good question. In theory this is indeed possible when random=20
> >> accessing to a bitstream is performed. However, it would not happen=20
> >> in conversational applications where the feedback messages may be used=
.
> >> Therefore, to me this would just work just fine. But please feel=20
> >> free to make other suggestions.
> >>
> >>> The use of spatial-segmentation-idc may need some updates to be=20
> >>> useful, let me come back to that later on.
> >>>
> >> [YK] OK. Look forward to seeing your input herein.
> >>
> >>> I have also a number of spelling suggestions for your considerations:
> >>>
> >>> Section 1.1:
> >>> Replace "community" by "communities"
> >> [YK] I guess both are OK. But anyway I just changed it per your=20
> >> suggestion (for the next version).
> >>
> >>> Section 1.1.1:
> >>> Replace "In addition, interpolation filter" by "In addition, the=20
> >>> interpolation filter"
> >> [YK] Thanks - done.
> >>
> >>> Replace "skipping the transform coding" by "skipping the transform"
> >>> (transform_skip_flag of HEVC skips the transform, not the coding)
> >>>
> >> [YK] Done.
> >>
> >>> Section 1.1.2:
> >>> Replace:
> >>> "2) An indication of whether there is any parameter set within the=20
> >>> current coded video sequence that updates another parameter set of=20
> >>> the same type preceding in decoding order."
> >>> by:
> >>> "2) An indication of whether there is no parameter set update in=20
> >>> the coded video sequence."
> >>> since that is what no_parameter_set_update_flag in HEVC indicates.
> >>>
> >> [YK] Changed the wording to "An indication of whether there is no=20
> >> parameter set within the current coded video sequence that updates=20
> >> another parameter set of the same type preceding in decoding order."
> >>
> >>> Section 4.7:
> >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and=20
> >>> "FU
> >>> Type:  6 bits" to avoid confusion with the Type in the payload header=
.
> >>>
> >> [YK] Good point again. I will change the field name to be "FuType".
> >>
> >>> Section 6:
> >>> Replace "recovery" by "recover"
> >> [YK] Done.
> >>
> >>> Section 7.1:
> >>> Replace "level-id" by "level-idc"
> >> [YK] We are consistently using "id" for profile-id, level-id,=20
> >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> >>
> >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >> [YK] Done.
> >>
> >>> Section 8:
> >>> Replace "two  payload-specific  feedback  messages" by "a=20
> >>> payload-specific feedback  message", since only SPLI is "Assigned=20
> >>> in this memo".
> >>> Also, consider removing references to H.264 in the last paragraph=20
> >>> of Section
> >>> 8 since the memo is about HEVC.
> >> [YK] Good catch again. Changed.
> >>
> >>> Section 8.1:
> >>> Seems to me that "There MUST be exactly one RPSI contained in the=20
> >>> FCI field" should be "There MUST be exactly one SPLI contained in=20
> >>> the FCI field"
> >> [YK] Another good catch. Changed.
> >>
> >>>
> >>> Best Regards,
> >>> Rickard Sj=F6berg
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]=20
> >>> On Behalf Of Wang, Ye-Kui
> >>> Sent: den 11 juni 2013 19:00
> >>> To: payload@ietf.org
> >>> Subject: [payload] Submission of new versions of H.265/HEVC=20
> >>> payload format
> >>>
> >>> Dear All,
> >>>
> >>> We have just submitted versions 02 and 03 of=20
> >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> >>>
> >>> Version 02:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-02.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 02
> >>>
> >>> Version 03:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-03.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 03
> >>>
> >>> Version 02 includes huge changes compared to the earlier submitted=20
> >>> version 01. In a short summary, the authors have worked hard to=20
> >>> try to make the design complete, from both the payload structure=20
> >>> and the signaling points of view. Compared to version 02, version=20
> >>> 03 only contains a correction of the email address of an author.
> >>>
> >>> Due to that the industry is eager to deploy H.265/HEVC and other=20
> >>> standards bodies such as 3GPP rely on the payload format for=20
> >>> support of H.265/HEVC in RTP based video services, we need to=20
> >>> progress this draft relatively quickly.
> >>> Therefore, we would like to request quick reviews from interested=20
> >>> parties and also request for the WG status of this draft.
> >>>
> >>> BR, YK (on behalf of the authors)
> >>> _______________________________________________
> >>> payload mailing list
> >>> payload@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/payload
> >>>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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 jonathan@vidyo.com  Wed Jul  3 12:53:25 2013
Return-Path: <jonathan@vidyo.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36AB11E8228 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 12:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOI6ZSHdetaZ for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 12:53:21 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1311E8227 for <payload@ietf.org>; Wed,  3 Jul 2013 12:53:20 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 71D00416D66; Wed,  3 Jul 2013 15:52:44 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9C925416DA9; Wed,  3 Jul 2013 15:52:43 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 3 Jul 2013 15:50:43 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Date: Wed, 3 Jul 2013 15:52:49 -0400
Thread-Topic: [payload] Submission of new versions of H.265/HEVC	payload format
Thread-Index: Ac54Jsm+S0N2ZkyuRzuOvEJBW7MwCw==
Message-ID: <FDE18EB4-1A02-4699-9F68-97BDA6467381@vidyo.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 19:53:25 -0000

On Jul 3, 2013, at 2:42 PM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:
>
> In any case, it does not make much sense to try MTU size matching and at =
the same time use either dependent slices or FUs, because dependent slices =
and FUs should not be used when there are considerable packet losses, while=
 MTU size matching should be applied when there are considerable packet los=
ses.

I don't (yet) understand H.265 well enough to know the details of dependent=
 slices vs. FUs, but it's not correct to say that MTU size matching is only=
 necessary in environments with high packet losses.

Many NATs don't correctly forward IP packets that are greater than an MTU. =
 When a UDP packet is fragmented, its UDP ports appear only in the first fr=
agment of the fragmented IP packet, requiring a NAT to maintain state (to s=
upport in-order fragments) and to buffer fragments (to support out-of-order=
 fragments) in order to forward the fragments properly.  Many NATs won't do=
 this, despite RFC 4787.

Thus, MTU size matching is necessary if your network paths are possibly NAT=
ted, even when packet loss is negligible.

> For live encoding, whenever splitting of a regular slice is needed, the s=
plitting can be done by the encoder using dependent slices - and the encode=
r has more knowledge and is more powerful than the RTP packetizer and thus =
can do a better job for the splitting.
>
> BR, YK
>
>
>> -----Original Message-----
>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Beha=
lf
>> Of Thomas Davies
>> Sent: Wednesday, July 03, 2013 9:34 AM
>> To: Stephan Wenger
>> Cc: payload@ietf.org
>> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
>> format
>>
>> Hi Stephan
>>
>> I think I agree with Rickard.
>>
>> I think the text in question states a preference for _dependent_ slice s=
egments,
>> which have no error resiliency advantage over FUs. Is this just a typo?
>>
>> <snip>
>>
>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>       video telephony, video conferencing, live streaming and live
>>       broadcast, in which cases dependent slice segments SHOULD be used
>>       when a slice should be transported in multiple RTP packets.
>>
>>
>>
>> </snip>
>>
>> In general FUs may be used where error conditions are known to be benign=
, for
>> greater efficiency, and also where for whatever reason the encoder canno=
t
>> support MTU matching.
>>
>> We also are formulating some more general comments on this area which we
>> hope to provide more fully soon.
>>
>> best regards
>>
>> Thomas
>>
>>
>> On 03/07/13 17:22, Stephan Wenger wrote:
>>> Hi Rickard,
>>> Commenting only on slices vs. FUs.
>>> The preference for slices over FUs, historically, was pushed by myself
>>> into RFC 3984 for reasons of error resilience, and was moved over to
>>> this draft for the same reason.  Loose a slice, and you can recover at
>>> the next slice boundary; loose an FU, and you have to wait for the
>>> next slice header and throw away all trailing FUs.  RTP is in
>>> virtually all cases run over UDP, and in the typical Internet scenario
>>> UDP is lossy (in contrast to private, managed IP-network, which may
>>> have other constraints, but are not the IETF's main concern.) To set
>>> your remarks into context, let's first understand what we are talking
>>> about: the cost of slices is the overhead stemming from the insertion
>>> of slice headers (in-picture syntax prediction) and from the packet
>>> headers themselves.  And, of course, implementation complexity, but we
>>> should not be in the business to encourage implementor laziness when
>>> there would be a more complex, but better suited tool available.    The
>>> additional packetization overhead is only incurred when, as a result
>>> of incompetently filled packets (which, I agree, is more likely with
>>> 64x64 CUs than with 16/16 macroblocks), an additional packet needs to
>>> be inserted.  You may remember a quick analysis of mine we discussed
>>> way back early in JCT, where we (I think) agreed that the practical
>>> impact is negligible in almost all non-tile scenarios (mostly because
>>> an additional overhead of 50 bytes or so--3% or less of the coded
>>> picture size) is incurred statistically only rarely (only in those
>>> cases where an additional packet would need to be generated because of
>>> the video coding related overhead for the use of slices).  The
>>> prediction overhead of the use of regular slices has been shown to be
>>> substantial--the price one needs to pay for independent
>>> decodability--but for entropy slices that overhead virtually does not e=
xist.
>>> With respect to tiles, I think you have a point though, especially
>>> when considering the type of massive parallel implementations for
>>> relatively small picture sizes some folks have been considering.
>>> OTOH, because FUs are trivial to implement--some say in contrast to
>>> slices--and because (I hope) we all agree that using FUs in error
>>> prone scenarios is a bad idea if you could use slices (but for reasons
>>> like the tile connection you mentioned), the draft should IMO continue
>>> to set a preference for the use of regular slices over FUs.  To avoid
>>> underperforming systems due to implementer laziness.
>>> However, this is the IETF.  We don't have to worry about the
>>> word-count of explanatory language.  In fact, explaining such complex
>>> tradeoffs and relationships is generally encouraged here.  So let's jus=
t do that:
>>> express a preference of the use of regular slices (SHOULD) when you
>>> expect losses and can use them (real-time encoding, no tiling
>>> structure that would lead to unacceptable packetization overhead); and
>>> suggest (MAY) the use of FUs in other scenarios.  Accompanied by a
>>> more coherently expressed analysis.
>>> Stephan
>>>
>>>
>>> On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>  =
wrote:
>>>
>>>> Hi Ye-Kui,
>>>>
>>>> Thanks for your feedback on my comments, your suggestions look good to
>> me.
>>>>
>>>> Regarding discouraging fragmentation units (FUs) for live-encoding
>>>> scenarios in section 4.7, I think using FUs does make sense when you
>>>> do not have many non-VLC NAL units for aggregation. The spatial
>>>> granularity of slices was 16x16 pixels in H.264 but is typically
>>>> 64x64 for HEVC which means that MTU size matching is done with units
>>>> that are 16x larger. This may lead to a larger number of smaller
>>>> packets when slices are used compared to FUs. In addition, there is
>>>> the HEVC rule of slice and tile boundaries that makes the slice
>>>> granularity equal to the tile granularity for cases when slices span
>>>> multiple tiles. Finally, FUs are easier to implement since you do not
>>>> need to care about when to break your slice to not exceed the MTU
>>>> size limit. I think both slices and FUs has their merits and the
>>>> choice between them for live-encoding should be left for the implement=
er.
>>>>
>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
>>>> the POC MSB sync issue, I agree that this is a corner case that we
>>>> probably will not see much of in practice. I have no text change
>>>> suggestion at the moment.
>>>>
>>>> BR
>>>> Rickard
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>> Sent: den 24 juni 2013 01:00
>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>> Subject: RE: Submission of new versions of H.265/HEVC payload format
>>>>
>>>> Hi Rickard,
>>>>
>>>> Thanks for the careful review and the comments. Please see inline belo=
w.
>>>>
>>>> BR, YK
>>>>
>>>>> -----Original Message-----
>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload format
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
>>>>> have some questions/comments.
>>>>>
>>>>> My first question is what extensions of HEVC that
>>>>> draft-schierl-payload-rtp-
>>>>> h265 is intended to cover? The draft mentions "future  scalable  or
>>>>> 3D  video coding  extensions  of  this  specification", what
>>>>> extensions do you refer to?
>>>>> Is the intent to cover the all HEVC extensions in a single payload
>>>>> specification?
>>>>>
>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where "this
>>>> specification" should be replaced with "[HEVC]". It is sort of
>>>> copy-and-paste error. Thanks for the good catching. No, there is no
>>>> intention to cover HEVC extensions in this payload specification,
>>>> though we intentionally to have the depacketization process and the
>>>> use with feedback messages to work for HEVC scalability and 3DV extens=
ions.
>>>>
>>>>> Another question for my understanding is why "Receivers MUST pass
>>>>> picture timing SEI messages and decoding unit information SEI
>>>>> messages to the decoder"?
>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>> specified by the video coding spec to the video decoders. This is
>>>> emphasized here for the two timing related SEI messages after it is
>>>> said that picture output timing in RTP timestamps should be used
>>>> instead (to avoid giving a wrong impression to readers that the SEI
>>>> messages should be ignored). If an RTP receiver discards the SEI
>>>> messages, then HRD conformance checking for the bitstream that was
>>>> possible would be disabled, and also the information related to frame
>> doubling or tripping would be lost.
>>>>
>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
>>>>> fourth one does not seem to be a rule since there is no "MUST" or
>>>>> "SHOULD" in the corresponding text.
>>>> [YK] I see your point, it is only a "MAY" rule. An alternative to put
>>>> this as a packetization rule is to put it as part of the semantics of
>>>> NAL unit header (1.1.4), but that sub-section belongs to an overview
>>>> wherein normative language (even "MAY") should not appear. One
>>>> solution to this is to insert "Payload Header Usage" after 4.1 "RTP
>>>> Header Usage" and include at least this item there. I will do this in
>>>> the next version unless there is a better suggestion.
>>>>
>>>>> Further, the fifth one discourages using FUs, what are the reasons
>>>>> behind that?
>>>> [YK] The bullet item only discourages using FUs for live-encoding
>>>> scenarios, wherein dependent slice segments should be used instead.
>>>> This was added after a discussion (among the authors) on the need of
>>>> whether to specify a payload structure for mixed FU and aggregation
>>>> packets and
>>>> from that discussion we concluded that encoding dependent slice
>>>> segments
>>>> at source coding level already allows for the use cases and using of
>>>> FUs for live-encoding does not make sense. Please let us know if you
>>>> think differently.
>>>>
>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
>>>>> between the encoder and decoder?
>>>> [YK] Good question. In theory this is indeed possible when random
>>>> accessing to a bitstream is performed. However, it would not happen
>>>> in conversational applications where the feedback messages may be used=
.
>>>> Therefore, to me this would just work just fine. But please feel free
>>>> to make other suggestions.
>>>>
>>>>> The use of spatial-segmentation-idc may need some updates to be
>>>>> useful, let me come back to that later on.
>>>>>
>>>> [YK] OK. Look forward to seeing your input herein.
>>>>
>>>>> I have also a number of spelling suggestions for your considerations:
>>>>>
>>>>> Section 1.1:
>>>>> Replace "community" by "communities"
>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>> suggestion (for the next version).
>>>>
>>>>> Section 1.1.1:
>>>>> Replace "In addition, interpolation filter" by "In addition, the
>>>>> interpolation filter"
>>>> [YK] Thanks - done.
>>>>
>>>>> Replace "skipping the transform coding" by "skipping the transform"
>>>>> (transform_skip_flag of HEVC skips the transform, not the coding)
>>>>>
>>>> [YK] Done.
>>>>
>>>>> Section 1.1.2:
>>>>> Replace:
>>>>> "2) An indication of whether there is any parameter set within the
>>>>> current coded video sequence that updates another parameter set of
>>>>> the same type preceding in decoding order."
>>>>> by:
>>>>> "2) An indication of whether there is no parameter set update in the
>>>>> coded video sequence."
>>>>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>>>>
>>>> [YK] Changed the wording to "An indication of whether there is no
>>>> parameter set within the current coded video sequence that updates
>>>> another parameter set of the same type preceding in decoding order."
>>>>
>>>>> Section 4.7:
>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
>>>>> "FU
>>>>> Type:  6 bits" to avoid confusion with the Type in the payload header=
.
>>>>>
>>>> [YK] Good point again. I will change the field name to be "FuType".
>>>>
>>>>> Section 6:
>>>>> Replace "recovery" by "recover"
>>>> [YK] Done.
>>>>
>>>>> Section 7.1:
>>>>> Replace "level-id" by "level-idc"
>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>>>>
>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>> [YK] Done.
>>>>
>>>>> Section 8:
>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>> payload-specific feedback  message", since only SPLI is "Assigned in
>>>>> this memo".
>>>>> Also, consider removing references to H.264 in the last paragraph of
>>>>> Section
>>>>> 8 since the memo is about HEVC.
>>>> [YK] Good catch again. Changed.
>>>>
>>>>> Section 8.1:
>>>>> Seems to me that "There MUST be exactly one RPSI contained in the
>>>>> FCI field" should be "There MUST be exactly one SPLI contained in
>>>>> the FCI field"
>>>> [YK] Another good catch. Changed.
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Rickard Sj=F6berg
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>>> Behalf Of Wang, Ye-Kui
>>>>> Sent: den 11 juni 2013 19:00
>>>>> To: payload@ietf.org
>>>>> Subject: [payload] Submission of new versions of H.265/HEVC payload
>>>>> format
>>>>>
>>>>> Dear All,
>>>>>
>>>>> We have just submitted versions 02 and 03 of
>>>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>>>>
>>>>> Version 02:
>>>>> URL:
>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>> h265-02.txt
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>> Diff:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>>>>> 02
>>>>>
>>>>> Version 03:
>>>>> URL:
>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>> h265-03.txt
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>> Diff:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>>>>> 03
>>>>>
>>>>> Version 02 includes huge changes compared to the earlier submitted
>>>>> version 01. In a short summary, the authors have worked hard to try
>>>>> to make the design complete, from both the payload structure and the
>>>>> signaling points of view. Compared to version 02, version 03 only
>>>>> contains a correction of the email address of an author.
>>>>>
>>>>> Due to that the industry is eager to deploy H.265/HEVC and other
>>>>> standards bodies such as 3GPP rely on the payload format for support
>>>>> of H.265/HEVC in RTP based video services, we need to progress this
>>>>> draft relatively quickly.
>>>>> Therefore, we would like to request quick reviews from interested
>>>>> parties and also request for the WG status of this draft.
>>>>>
>>>>> BR, YK (on behalf of the authors)
>>>>> _______________________________________________
>>>>> payload mailing list
>>>>> payload@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>
>>>> _______________________________________________
>>>> payload mailing list
>>>> payload@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/payload
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>

--
Jonathan Lennox
jonathan@vidyo.com



From thdavies@cisco.com  Wed Jul  3 14:28:46 2013
Return-Path: <thdavies@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F4E11E8251 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 14:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8QPV89EvCZV for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 14:28:41 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB711E80EA for <payload@ietf.org>; Wed,  3 Jul 2013 14:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=768; q=dns/txt; s=iport; t=1372886921; x=1374096521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kapW/+wGBRbBGMAJipjldpZ+ZYT01SmRD2tuuOR9dm0=; b=PCT1/8UsCol+pdtuw9b99/9j4KmacdqJLwYElCUolscmkC7jLqc91bW2 Z2joQhEC8hMRR5dai8QFtM+7KjyvpdMrd9NVwtW1vOx0/VvEEWvnME7dp d+TcWDUh+iDE7Jc26ApG8PoGXWzyOiDOXnTYW2Sr/5CQhBupJxeFKvN+b E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAFAMyW1FGtJV2d/2dsb2JhbABagwl7wDmBCRZ0giMBAQEDAToyDRACAQgiFBAyJQIEDg2IAQa6Lo86MQeDBGkDqQ6DEYIo
X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230735217"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jul 2013 21:28:40 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63LSeC5026768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 21:28:40 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 16:28:40 -0500
From: "Thomas Davies (thdavies)" <thdavies@cisco.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: AQHOeB0p86OdufC+WkiuwYv6E4ad6ZlTdR4w
Date: Wed, 3 Jul 2013 21:28:40 +0000
Message-ID: <9C2FAEDF6B678042ADE3B6686D7C6E151913BF32@xmb-rcd-x07.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.85.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 21:28:46 -0000

Hi Ye-Kui

>> For live encoding, whenever splitting of a regular slice is needed, the =
splitting can be done by the encoder using dependent slices - and the encod=
er has more knowledge and is more powerful than the RTP packetizer and thus=
 can do a better job for the splitting.=20

There is some efficiency loss, and some complexity involved in matching a d=
ependent  slice to a packet, and you are not gaining resilience. Can you ex=
plain further why this is a "better job" than simply fragmenting? FUs seem =
useful to me in attaining an MTU target in the simplest possible way, and i=
t seems too strong to me to recommend that an encoder should be closely cou=
pled with packetization in the way that the text implies.

Best regards

Thomas


From yekuiw@qti.qualcomm.com  Wed Jul  3 15:09:34 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5AD11E823E for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YIsYYtjhQAj for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:09:30 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 714CC21F9A29 for <payload@ietf.org>; Wed,  3 Jul 2013 15:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372889370; x=1404425370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=567ziV559qyk08eUt/H2PjJVRuUocfKRXvpr29uUecY=; b=wAbmV5qum4W4s3uvpp2kR+XpWp83Jo4BAcBXf5vvmjQQqo0yve2G2AHE kpUcZQVX/iyWOfa00xMgmbFq2ufB2ahyKI2OjGc9pO27J29CNQDCbHQfT FL679ldrtzYfpq7D2REFKEUpWs545A5CUfoEowx25w9rpIGqYpGmhlwC/ 0=;
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="46820511"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 03 Jul 2013 15:09:29 -0700
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="562780084"
Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 15:09:29 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 15:09:30 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeCb95Zh5uPHvBEKXLq02N2lCA5lTgqBw
Date: Wed, 3 Jul 2013 22:09:28 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833845514D@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <FDE18EB4-1A02-4699-9F68-97BDA6467381@vidyo.com>
In-Reply-To: <FDE18EB4-1A02-4699-9F68-97BDA6467381@vidyo.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 22:09:34 -0000

Thanks Jonathan - good to learn another use of MTU size matching.

>From functionality point of view, dependent slices do exactly the same job =
as FU, one in the codec level, and one in the RTP level, they can both spli=
t one slice into multiple fragments each of which can be encapsulated into =
one RTP packet.

BR, YK

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Jonathan Lennox
> Sent: Wednesday, July 03, 2013 12:53 PM
> To: Wang, Ye-Kui
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
>=20
> On Jul 3, 2013, at 2:42 PM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
> wrote:
> >
> > In any case, it does not make much sense to try MTU size matching and a=
t the
> same time use either dependent slices or FUs, because dependent slices an=
d
> FUs should not be used when there are considerable packet losses, while M=
TU
> size matching should be applied when there are considerable packet losses=
.
>=20
> I don't (yet) understand H.265 well enough to know the details of depende=
nt
> slices vs. FUs, but it's not correct to say that MTU size matching is onl=
y
> necessary in environments with high packet losses.
>=20
> Many NATs don't correctly forward IP packets that are greater than an MTU=
.
> When a UDP packet is fragmented, its UDP ports appear only in the first
> fragment of the fragmented IP packet, requiring a NAT to maintain state (=
to
> support in-order fragments) and to buffer fragments (to support out-of-or=
der
> fragments) in order to forward the fragments properly.  Many NATs won't d=
o
> this, despite RFC 4787.
>=20
> Thus, MTU size matching is necessary if your network paths are possibly
> NATted, even when packet loss is negligible.
>=20
> > For live encoding, whenever splitting of a regular slice is needed, the=
 splitting
> can be done by the encoder using dependent slices - and the encoder has m=
ore
> knowledge and is more powerful than the RTP packetizer and thus can do a
> better job for the splitting.
> >
> > BR, YK
> >
> >
> >> -----Original Message-----
> >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> >> Behalf Of Thomas Davies
> >> Sent: Wednesday, July 03, 2013 9:34 AM
> >> To: Stephan Wenger
> >> Cc: payload@ietf.org
> >> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >> payload format
> >>
> >> Hi Stephan
> >>
> >> I think I agree with Rickard.
> >>
> >> I think the text in question states a preference for _dependent_
> >> slice segments, which have no error resiliency advantage over FUs. Is =
this
> just a typo?
> >>
> >> <snip>
> >>
> >> FUs SHOULD NOT be applied in live-encoding scenarios such as
> >>       video telephony, video conferencing, live streaming and live
> >>       broadcast, in which cases dependent slice segments SHOULD be use=
d
> >>       when a slice should be transported in multiple RTP packets.
> >>
> >>
> >>
> >> </snip>
> >>
> >> In general FUs may be used where error conditions are known to be
> >> benign, for greater efficiency, and also where for whatever reason
> >> the encoder cannot support MTU matching.
> >>
> >> We also are formulating some more general comments on this area which
> >> we hope to provide more fully soon.
> >>
> >> best regards
> >>
> >> Thomas
> >>
> >>
> >> On 03/07/13 17:22, Stephan Wenger wrote:
> >>> Hi Rickard,
> >>> Commenting only on slices vs. FUs.
> >>> The preference for slices over FUs, historically, was pushed by
> >>> myself into RFC 3984 for reasons of error resilience, and was moved
> >>> over to this draft for the same reason.  Loose a slice, and you can
> >>> recover at the next slice boundary; loose an FU, and you have to
> >>> wait for the next slice header and throw away all trailing FUs.  RTP
> >>> is in virtually all cases run over UDP, and in the typical Internet
> >>> scenario UDP is lossy (in contrast to private, managed IP-network,
> >>> which may have other constraints, but are not the IETF's main
> >>> concern.) To set your remarks into context, let's first understand
> >>> what we are talking
> >>> about: the cost of slices is the overhead stemming from the
> >>> insertion of slice headers (in-picture syntax prediction) and from
> >>> the packet headers themselves.  And, of course, implementation
> >>> complexity, but we should not be in the business to encourage
> implementor laziness when
> >>> there would be a more complex, but better suited tool available.    T=
he
> >>> additional packetization overhead is only incurred when, as a result
> >>> of incompetently filled packets (which, I agree, is more likely with
> >>> 64x64 CUs than with 16/16 macroblocks), an additional packet needs
> >>> to be inserted.  You may remember a quick analysis of mine we
> >>> discussed way back early in JCT, where we (I think) agreed that the
> >>> practical impact is negligible in almost all non-tile scenarios
> >>> (mostly because an additional overhead of 50 bytes or so--3% or less
> >>> of the coded picture size) is incurred statistically only rarely
> >>> (only in those cases where an additional packet would need to be
> >>> generated because of the video coding related overhead for the use
> >>> of slices).  The prediction overhead of the use of regular slices
> >>> has been shown to be substantial--the price one needs to pay for
> >>> independent decodability--but for entropy slices that overhead virtua=
lly
> does not exist.
> >>> With respect to tiles, I think you have a point though, especially
> >>> when considering the type of massive parallel implementations for
> >>> relatively small picture sizes some folks have been considering.
> >>> OTOH, because FUs are trivial to implement--some say in contrast to
> >>> slices--and because (I hope) we all agree that using FUs in error
> >>> prone scenarios is a bad idea if you could use slices (but for
> >>> reasons like the tile connection you mentioned), the draft should
> >>> IMO continue to set a preference for the use of regular slices over
> >>> FUs.  To avoid underperforming systems due to implementer laziness.
> >>> However, this is the IETF.  We don't have to worry about the
> >>> word-count of explanatory language.  In fact, explaining such
> >>> complex tradeoffs and relationships is generally encouraged here.  So=
 let's
> just do that:
> >>> express a preference of the use of regular slices (SHOULD) when you
> >>> expect losses and can use them (real-time encoding, no tiling
> >>> structure that would lead to unacceptable packetization overhead);
> >>> and suggest (MAY) the use of FUs in other scenarios.  Accompanied by
> >>> a more coherently expressed analysis.
> >>> Stephan
> >>>
> >>>
> >>> On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>
> wrote:
> >>>
> >>>> Hi Ye-Kui,
> >>>>
> >>>> Thanks for your feedback on my comments, your suggestions look good
> >>>> to
> >> me.
> >>>>
> >>>> Regarding discouraging fragmentation units (FUs) for live-encoding
> >>>> scenarios in section 4.7, I think using FUs does make sense when
> >>>> you do not have many non-VLC NAL units for aggregation. The spatial
> >>>> granularity of slices was 16x16 pixels in H.264 but is typically
> >>>> 64x64 for HEVC which means that MTU size matching is done with
> >>>> units that are 16x larger. This may lead to a larger number of
> >>>> smaller packets when slices are used compared to FUs. In addition,
> >>>> there is the HEVC rule of slice and tile boundaries that makes the
> >>>> slice granularity equal to the tile granularity for cases when
> >>>> slices span multiple tiles. Finally, FUs are easier to implement
> >>>> since you do not need to care about when to break your slice to not
> >>>> exceed the MTU size limit. I think both slices and FUs has their
> >>>> merits and the choice between them for live-encoding should be left =
for
> the implementer.
> >>>>
> >>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
> >>>> the POC MSB sync issue, I agree that this is a corner case that we
> >>>> probably will not see much of in practice. I have no text change
> >>>> suggestion at the moment.
> >>>>
> >>>> BR
> >>>> Rickard
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>> Sent: den 24 juni 2013 01:00
> >>>> To: Rickard Sj=F6berg; payload@ietf.org
> >>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>> format
> >>>>
> >>>> Hi Rickard,
> >>>>
> >>>> Thanks for the careful review and the comments. Please see inline be=
low.
> >>>>
> >>>> BR, YK
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>>>> Sent: Thursday, June 20, 2013 9:17 AM
> >>>>> To: Wang, Ye-Kui; payload@ietf.org
> >>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>>> format
> >>>>>
> >>>>> Dear all,
> >>>>>
> >>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
> >>>>> have some questions/comments.
> >>>>>
> >>>>> My first question is what extensions of HEVC that
> >>>>> draft-schierl-payload-rtp-
> >>>>> h265 is intended to cover? The draft mentions "future  scalable
> >>>>> or 3D  video coding  extensions  of  this  specification", what
> >>>>> extensions do you refer to?
> >>>>> Is the intent to cover the all HEVC extensions in a single payload
> >>>>> specification?
> >>>>>
> >>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> >>>> "this specification" should be replaced with "[HEVC]". It is sort
> >>>> of copy-and-paste error. Thanks for the good catching. No, there is
> >>>> no intention to cover HEVC extensions in this payload
> >>>> specification, though we intentionally to have the depacketization
> >>>> process and the use with feedback messages to work for HEVC scalabil=
ity
> and 3DV extensions.
> >>>>
> >>>>> Another question for my understanding is why "Receivers MUST pass
> >>>>> picture timing SEI messages and decoding unit information SEI
> >>>>> messages to the decoder"?
> >>>> [YK] Generally, RTP receivers should/must pass all NAL units
> >>>> specified by the video coding spec to the video decoders. This is
> >>>> emphasized here for the two timing related SEI messages after it is
> >>>> said that picture output timing in RTP timestamps should be used
> >>>> instead (to avoid giving a wrong impression to readers that the SEI
> >>>> messages should be ignored). If an RTP receiver discards the SEI
> >>>> messages, then HRD conformance checking for the bitstream that was
> >>>> possible would be disabled, and also the information related to
> >>>> frame
> >> doubling or tripping would be lost.
> >>>>
> >>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
> >>>>> fourth one does not seem to be a rule since there is no "MUST" or
> >>>>> "SHOULD" in the corresponding text.
> >>>> [YK] I see your point, it is only a "MAY" rule. An alternative to
> >>>> put this as a packetization rule is to put it as part of the
> >>>> semantics of NAL unit header (1.1.4), but that sub-section belongs
> >>>> to an overview wherein normative language (even "MAY") should not
> >>>> appear. One solution to this is to insert "Payload Header Usage"
> >>>> after 4.1 "RTP Header Usage" and include at least this item there.
> >>>> I will do this in the next version unless there is a better suggesti=
on.
> >>>>
> >>>>> Further, the fifth one discourages using FUs, what are the reasons
> >>>>> behind that?
> >>>> [YK] The bullet item only discourages using FUs for live-encoding
> >>>> scenarios, wherein dependent slice segments should be used instead.
> >>>> This was added after a discussion (among the authors) on the need
> >>>> of whether to specify a payload structure for mixed FU and
> >>>> aggregation packets and from that discussion we concluded that
> >>>> encoding dependent slice segments at source coding level already
> >>>> allows for the use cases and using of FUs for live-encoding does
> >>>> not make sense. Please let us know if you think differently.
> >>>>
> >>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> >>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
> >>>>> between the encoder and decoder?
> >>>> [YK] Good question. In theory this is indeed possible when random
> >>>> accessing to a bitstream is performed. However, it would not happen
> >>>> in conversational applications where the feedback messages may be us=
ed.
> >>>> Therefore, to me this would just work just fine. But please feel
> >>>> free to make other suggestions.
> >>>>
> >>>>> The use of spatial-segmentation-idc may need some updates to be
> >>>>> useful, let me come back to that later on.
> >>>>>
> >>>> [YK] OK. Look forward to seeing your input herein.
> >>>>
> >>>>> I have also a number of spelling suggestions for your consideration=
s:
> >>>>>
> >>>>> Section 1.1:
> >>>>> Replace "community" by "communities"
> >>>> [YK] I guess both are OK. But anyway I just changed it per your
> >>>> suggestion (for the next version).
> >>>>
> >>>>> Section 1.1.1:
> >>>>> Replace "In addition, interpolation filter" by "In addition, the
> >>>>> interpolation filter"
> >>>> [YK] Thanks - done.
> >>>>
> >>>>> Replace "skipping the transform coding" by "skipping the transform"
> >>>>> (transform_skip_flag of HEVC skips the transform, not the coding)
> >>>>>
> >>>> [YK] Done.
> >>>>
> >>>>> Section 1.1.2:
> >>>>> Replace:
> >>>>> "2) An indication of whether there is any parameter set within the
> >>>>> current coded video sequence that updates another parameter set of
> >>>>> the same type preceding in decoding order."
> >>>>> by:
> >>>>> "2) An indication of whether there is no parameter set update in
> >>>>> the coded video sequence."
> >>>>> since that is what no_parameter_set_update_flag in HEVC indicates.
> >>>>>
> >>>> [YK] Changed the wording to "An indication of whether there is no
> >>>> parameter set within the current coded video sequence that updates
> >>>> another parameter set of the same type preceding in decoding order."
> >>>>
> >>>>> Section 4.7:
> >>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
> >>>>> "FU
> >>>>> Type:  6 bits" to avoid confusion with the Type in the payload head=
er.
> >>>>>
> >>>> [YK] Good point again. I will change the field name to be "FuType".
> >>>>
> >>>>> Section 6:
> >>>>> Replace "recovery" by "recover"
> >>>> [YK] Done.
> >>>>
> >>>>> Section 7.1:
> >>>>> Replace "level-id" by "level-idc"
> >>>> [YK] We are consistently using "id" for profile-id, level-id,
> >>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> >>>>
> >>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >>>> [YK] Done.
> >>>>
> >>>>> Section 8:
> >>>>> Replace "two  payload-specific  feedback  messages" by "a
> >>>>> payload-specific feedback  message", since only SPLI is "Assigned
> >>>>> in this memo".
> >>>>> Also, consider removing references to H.264 in the last paragraph
> >>>>> of Section
> >>>>> 8 since the memo is about HEVC.
> >>>> [YK] Good catch again. Changed.
> >>>>
> >>>>> Section 8.1:
> >>>>> Seems to me that "There MUST be exactly one RPSI contained in the
> >>>>> FCI field" should be "There MUST be exactly one SPLI contained in
> >>>>> the FCI field"
> >>>> [YK] Another good catch. Changed.
> >>>>
> >>>>>
> >>>>> Best Regards,
> >>>>> Rickard Sj=F6berg
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>> On Behalf Of Wang, Ye-Kui
> >>>>> Sent: den 11 juni 2013 19:00
> >>>>> To: payload@ietf.org
> >>>>> Subject: [payload] Submission of new versions of H.265/HEVC
> >>>>> payload format
> >>>>>
> >>>>> Dear All,
> >>>>>
> >>>>> We have just submitted versions 02 and 03 of
> >>>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> >>>>>
> >>>>> Version 02:
> >>>>> URL:
> >>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>>>> h265-02.txt
> >>>>> Htmlized:
> >>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>>>> Diff:
> >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>>>> 02
> >>>>>
> >>>>> Version 03:
> >>>>> URL:
> >>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>>>> h265-03.txt
> >>>>> Htmlized:
> >>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>>>> Diff:
> >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>>>> 03
> >>>>>
> >>>>> Version 02 includes huge changes compared to the earlier submitted
> >>>>> version 01. In a short summary, the authors have worked hard to
> >>>>> try to make the design complete, from both the payload structure
> >>>>> and the signaling points of view. Compared to version 02, version
> >>>>> 03 only contains a correction of the email address of an author.
> >>>>>
> >>>>> Due to that the industry is eager to deploy H.265/HEVC and other
> >>>>> standards bodies such as 3GPP rely on the payload format for
> >>>>> support of H.265/HEVC in RTP based video services, we need to
> >>>>> progress this draft relatively quickly.
> >>>>> Therefore, we would like to request quick reviews from interested
> >>>>> parties and also request for the WG status of this draft.
> >>>>>
> >>>>> BR, YK (on behalf of the authors)
> >>>>> _______________________________________________
> >>>>> payload mailing list
> >>>>> payload@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>
> >>>> _______________________________________________
> >>>> payload mailing list
> >>>> payload@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/payload
> >>> _______________________________________________
> >>> payload mailing list
> >>> payload@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/payload
> >>
> >> _______________________________________________
> >> payload mailing list
> >> payload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/payload
> > _______________________________________________
> > payload mailing list
> > payload@ietf.org
> > https://www.ietf.org/mailman/listinfo/payload
> >
>=20
> --
> Jonathan Lennox
> jonathan@vidyo.com
>=20
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

From yekuiw@qti.qualcomm.com  Wed Jul  3 15:24:39 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70C821F9732 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLLWfj8E+ClX for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:24:34 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60221F999C for <payload@ietf.org>; Wed,  3 Jul 2013 15:24:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372890274; x=1404426274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x+N/0FqTV1yavsZE9bEGxTSGeRnL9OONFUZt+Kq0RLM=; b=enP4aPe5BUL79PC3I8jmzL9+uF9zwTmxBW9MfJZvinH3j0WucwUQTPnh uwxXrB8ElDCjSuAT0vXT5JDlrKcjINzNmhUePIZAf32jzSG0Da4AO4iKf qc51L+ataYvX6xThsw75kuD4UdkM8sF7n60frMeFkkeE5VXOSJlX4bGrc I=;
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="60648861"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 03 Jul 2013 15:24:31 -0700
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="509324111"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 15:24:31 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 15:24:31 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC	payload format
Thread-Index: AQHOeDRP0TtrEi8ewUGX2m4WNS42SplTg5XQ
Date: Wed, 3 Jul 2013 22:24:30 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338455185@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913BF32@xmb-rcd-x07.cisco.com>
In-Reply-To: <9C2FAEDF6B678042ADE3B6686D7C6E151913BF32@xmb-rcd-x07.cisco.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
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 22:24:39 -0000

Hi Thomas,

FUs would involve some efficiency loss too, due to the FU header bits. Gene=
rating dependent slice for MTU size matching is not more difficult than gen=
erating regular slices for MTU matching, and it can be easily done when you=
 know the MTU size and the IP/UDP/RTP/payload header size. I don't think th=
is is a strong coupling of encoder and packetization, and any encoder that =
would do slice for MTU size matching does not anyway. Encoders has knowledg=
e on what it plans to generate, include non-VLC NAL units et al, and it can=
 thus try to generate the best-sized dependent slices to be aggregated toge=
ther with non-VCL NAL units.=20

In any case, since MTU size matching also has its use for other than error =
resilience purpose as Jonathan pointed out, then some of the use cases Rick=
ard mentioned makes sense to me, and I now agree that we should just remove=
 that recommendation. I will do this in the next version (unless the discus=
sion goes further and to a different direction).

BR, YK

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Thomas Davies (thdavies)
> Sent: Wednesday, July 03, 2013 2:29 PM
> To: Wang, Ye-Kui
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Ye-Kui
>=20
> >> For live encoding, whenever splitting of a regular slice is needed, th=
e
> splitting can be done by the encoder using dependent slices - and the enc=
oder
> has more knowledge and is more powerful than the RTP packetizer and thus
> can do a better job for the splitting.
>=20
> There is some efficiency loss, and some complexity involved in matching a
> dependent  slice to a packet, and you are not gaining resilience. Can you
> explain further why this is a "better job" than simply fragmenting? FUs s=
eem
> useful to me in attaining an MTU target in the simplest possible way, and=
 it
> seems too strong to me to recommend that an encoder should be closely
> coupled with packetization in the way that the text implies.
>=20
> Best regards
>=20
> Thomas
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

From yekuiw@qti.qualcomm.com  Wed Jul  3 15:26:25 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0021F9BC0 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level: 
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Q4II+syWI6 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 15:26:21 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4621F9B95 for <payload@ietf.org>; Wed,  3 Jul 2013 15:26:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372890381; x=1404426381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TC1/IIhZHpuz1HBRW8WL5SNOT3ggIPru/7W0wpSmC90=; b=jI9RYKr73Bp1Zuoh1y7MnfsssjUNTXgUl3edTlniiFSp6B0yqi3aEr78 Z2eH+ko7l8srykS1M8/dIBBGLoydeDqFGBNZph3llt2jmojHhVhzjmyp0 4P9SE6c7wKxA1sPqBu7YfKMCcHDD0y/y6sp7drdYhmkxNU2xcx3Td7Q6K M=;
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="60649072"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 03 Jul 2013 15:26:21 -0700
X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="499731016"
Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 15:26:19 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 15:26:19 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeDwlVyIV74N4IEGukEjxhcgDOJlTiAiQ
Date: Wed, 3 Jul 2013 22:26:18 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384551A3@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913BF32@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338455185@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338455185@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.39.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 22:26:25 -0000

Typo: "does not anyway" -> "does it anyway"

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Wang, Ye-Kui
> Sent: Wednesday, July 03, 2013 3:25 PM
> To: Thomas Davies (thdavies)
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> FUs would involve some efficiency loss too, due to the FU header bits.
> Generating dependent slice for MTU size matching is not more difficult th=
an
> generating regular slices for MTU matching, and it can be easily done whe=
n you
> know the MTU size and the IP/UDP/RTP/payload header size. I don't think t=
his
> is a strong coupling of encoder and packetization, and any encoder that w=
ould
> do slice for MTU size matching does not anyway. Encoders has knowledge on
> what it plans to generate, include non-VLC NAL units et al, and it can th=
us try to
> generate the best-sized dependent slices to be aggregated together with n=
on-
> VCL NAL units.
>=20
> In any case, since MTU size matching also has its use for other than erro=
r
> resilience purpose as Jonathan pointed out, then some of the use cases Ri=
ckard
> mentioned makes sense to me, and I now agree that we should just remove
> that recommendation. I will do this in the next version (unless the discu=
ssion
> goes further and to a different direction).
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > Behalf Of Thomas Davies (thdavies)
> > Sent: Wednesday, July 03, 2013 2:29 PM
> > To: Wang, Ye-Kui
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Hi Ye-Kui
> >
> > >> For live encoding, whenever splitting of a regular slice is needed,
> > >> the
> > splitting can be done by the encoder using dependent slices - and the
> > encoder has more knowledge and is more powerful than the RTP
> > packetizer and thus can do a better job for the splitting.
> >
> > There is some efficiency loss, and some complexity involved in
> > matching a dependent  slice to a packet, and you are not gaining
> > resilience. Can you explain further why this is a "better job" than
> > simply fragmenting? FUs seem useful to me in attaining an MTU target
> > in the simplest possible way, and it seems too strong to me to
> > recommend that an encoder should be closely coupled with packetization =
in
> the way that the text implies.
> >
> > Best regards
> >
> > Thomas
> >
> > _______________________________________________
> > 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 mzanaty@cisco.com  Wed Jul  3 21:50:51 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63021F92A5 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 21:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level: 
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoOl8Wc0pyOH for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 21:50:46 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 24D5521F91C4 for <payload@ietf.org>; Wed,  3 Jul 2013 21:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25561; q=dns/txt; s=iport; t=1372913444; x=1374123044; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bnx+aDcrrcTzHTYgb8U+Zoa0MeUm2e2KHUXcEMFE0cg=; b=ElPK02v3gbCC9E9kFpiAJsRvedc86maK7XEz+o2rDeGj/+B2bYhFPsql ER1XA03Ssycf7GyYdmyiD5GPT+x4wb/YfPKNvffjOFFnenyaU2by6liLi 818aooYpEuRK6cbhFBN/9o/w/05qNua8O4cqMGGuXi2H9hTQmZrtT3uCI E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAM/+1FGtJXHA/2dsb2JhbABagwkyQwbAPYELFnSCIwEBAQMBAQEBF1QEBwwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCAELB4duBgcFujKOHwoBCgWBATEHBoJ+aQOIa4sMhHuQHIMRgWkIFyA
X-IronPort-AV: E=Sophos;i="4.87,992,1363132800"; d="scan'208";a="230626354"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2013 04:50:41 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r644ofZv026385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jul 2013 04:50:41 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 23:50:40 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "Thomas Davies (thdavies)" <thdavies@cisco.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeCTOo/1Zj2Q7hkmxvsQohaKfo5lTadyA
Date: Thu, 4 Jul 2013 04:50:40 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se>
In-Reply-To: <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.208.207]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 04:50:51 -0000

Thomas, Paul and I have been working on improving packet loss resilience us=
ing fragments and tiles. I mentioned this to Stephan at IETF 86 in Orlando,=
 and promised to have draft text ready before Berlin. Here is the proposed =
text along with an overview of the rationale.

Rationale:

1. Resilience to packet loss requires independent slices or tiles. Since in=
dependence requires restrictions on some coding tools, both potentially inc=
ur slight penalties in coding efficiency, with a smaller penalty for tiles.

2. Fragmentation in a higher layer like RTP can have several advantages ove=
r similar features in a codec layer like slices (independent or dependent).
a. Efficiency: RTP fragmentation has finer (byte) granularity while slices =
have much larger (CTB or tile) granularity. It also has less slice segment =
header overhead, especially for independent slices. This can impact the eff=
iciency of the packetized stream in terms of both bits and packets per seco=
nd.
b. Performance: Encoders must perform extra processing to limit slice sizes=
, which can impact encoder performance. Some implementations speculatively =
end a slice based on computed statistics (which aggravates a.), while other=
s recode a slice if the size is exceeded (which aggravates b.).
c. Decoupling: Not all encoders will support limiting slice size to MTU siz=
e. Applications (for live or stored content) using such encoders can still =
support MTU limits using RTP fragmentation since it is decoupled from the e=
ncoder.
d. Multi-party: The encoded content may go to multiple receivers with diffe=
rent MTUs. RTP fragmentation can handle this with lightweight repacketizati=
on at middle boxes whereas slices incur heavyweight transcoding.

3. Combining fragmentation and tiles can improve resilience while retaining=
 the above advantages, if fragments are enhanced to contain offsets (simila=
r to IP fragmentation). This is described in the proposed draft text below,=
 which would immediately follow section 4.7 Fragmentation Units.

Draft Text:

4.7.1 Fragmentation Units with Fragment Offsets

If a fragmented NAL unit contains tiles, its slice segment header contains =
offsets to the data of each tile. These offsets can be used for random acce=
ss to any tile for parallel processing, region of interest extraction, and =
resilience to errors in other tiles. These offsets can also be used to prov=
ide resilience to packet loss, in conjunction with fragment offsets contain=
ed in two types of fragmentation units: FU-A2 and FU-A4.

Fragmentation units FU-A2 and FU-A4 contain a fragment offset before the FU=
 payload. FU-A2 contains a 2-byte offset as shown in Figure X. FU-A4 contai=
ns a 4-byte offset as shown in Figure Y. The offset indicates the total num=
ber of bytes in all prior FU payloads of the fragmented NAL unit.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FU-A2 offset  |     DONL (optional)           |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   |                         FU payload                            |
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :...OPTIONAL RTP padding        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure X   RTP payload format for FU-A2


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FU-A4 offset                             | DONL(optional)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DONL(optional)|                                               |
   +-+-+-+-+-+-+-+-+         FU payload                            |
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :...OPTIONAL RTP padding        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure Y   RTP payload format for FU-A4


Since the offset of the first FU payload of a fragmented NAL unit is zero, =
and the Start (S) bit in the FU header is sufficient to indicate this, the =
first fragmentation unit of a fragmented NAL unit SHOULD use FU-A, but MAY =
use FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation units o=
f a fragmented NAL unit MAY use FU-A2 or FU-A4 with a non-zero offset. The =
Start (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4 contai=
ns a non-zero offset, and MUST be set if it contains a zero offset.

If a fragmentation unit is lost, tiles in the lost fragmentation unit are a=
lso lost. However, tiles which are successfully received in their entirety =
can be decoded if their slice segment header containing tile offsets is suc=
cessfully received, despite lost fragmentation units. Fragment offsets in F=
U-A2 or FU-A4 are required in order to recover from loss of prior fragmenta=
tion units and continue decoding subsequent tiles.

The following heuristic SHOULD be applied to determine if the lost fragment=
ation units are all part of the same fragmented NAL unit as subsequently re=
ceived fragmentation units with identical RTP timestamps and identical valu=
es of NAL unit header layer ID and temporal ID.

1. Let N be the number of missing sequence numbers between two received fra=
gmentation units with known offsets.
2. Let P be the FU payload size of the first of the two received FUs.
3. Let D be the difference in the offsets, minus P.
   (This is the number of missing FU payload bytes.)
4. Let E be N times P.
   (This is the estimated number of missing FU payload bytes.)
5. Let ERROR be the absolute difference between D and E, divided by D.
6. If ERROR < 50%, it is likely all FUs are part of the same fragmented NAL=
 unit, otherwise it is unlikely.

Cheers,
Mo

-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Rickard Sj=F6berg
Sent: Wednesday, July 03, 2013 3:38 PM
To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
Cc: payload@ietf.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Dear all,

I wrote slices and not dependent slices since the slice granularity and sli=
ce/tile rule applies to both slices and dependent slices. Sorry for the con=
fusion. I will now use 'independent slices' and 'dependent slices' to disti=
nguish between them.

I do not question the use of independent slices, I find them useful in some=
 applications.

But the current RTP payload text says:

"FUs SHOULD NOT be applied in live-encoding scenarios such as
      video telephony, video conferencing, live streaming and live
      broadcast, in which cases dependent slice segments SHOULD be used
      when a slice should be transported in multiple RTP packets."

I believe that FUs are a viable option to dependent slices for the reasons =
I listed in my previous e-mail and think that we should not recommend depen=
dent slices over FUs but leave it to the implementer.

BR
Rickard


-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Wang, Ye-Kui
Sent: den 3 juli 2013 20:43
To: Thomas Davies; Stephan Wenger
Cc: payload@ietf.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Hi All,

I drafted an email replying directly to Rickard but did not finish and ther=
e was a meeting (and then Stephan's and Thomas' emails came).

I wanted to comment that Rickard was comparing the use of FUs vs slices, no=
t FUs vs dependent slices, while the recommendation in the draft is recomme=
nding use of dependent slices over FUs in live-encoding scenarios (so this =
answers Thomas question: the intention was dependent slices ).=20

In any case, it does not make much sense to try MTU size matching and at th=
e same time use either dependent slices or FUs, because dependent slices an=
d FUs should not be used when there are considerable packet losses, while M=
TU size matching should be applied when there are considerable packet losse=
s.

For live encoding, whenever splitting of a regular slice is needed, the spl=
itting can be done by the encoder using dependent slices - and the encoder =
has more knowledge and is more powerful than the RTP packetizer and thus ca=
n do a better job for the splitting.=20

BR, YK


> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> Behalf Of Thomas Davies
> Sent: Wednesday, July 03, 2013 9:34 AM
> To: Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Hi Stephan
>=20
> I think I agree with Rickard.
>=20
> I think the text in question states a preference for _dependent_ slice=20
> segments, which have no error resiliency advantage over FUs. Is this just=
 a typo?
>=20
> <snip>
>=20
> FUs SHOULD NOT be applied in live-encoding scenarios such as
>        video telephony, video conferencing, live streaming and live
>        broadcast, in which cases dependent slice segments SHOULD be used
>        when a slice should be transported in multiple RTP packets.
>=20
>=20
>=20
> </snip>
>=20
> In general FUs may be used where error conditions are known to be=20
> benign, for greater efficiency, and also where for whatever reason the=20
> encoder cannot support MTU matching.
>=20
> We also are formulating some more general comments on this area which=20
> we hope to provide more fully soon.
>=20
> best regards
>=20
> Thomas
>=20
>=20
> On 03/07/13 17:22, Stephan Wenger wrote:
> > Hi Rickard,
> > Commenting only on slices vs. FUs.
> > The preference for slices over FUs, historically, was pushed by=20
> > myself into RFC 3984 for reasons of error resilience, and was moved=20
> > over to this draft for the same reason.  Loose a slice, and you can=20
> > recover at the next slice boundary; loose an FU, and you have to=20
> > wait for the next slice header and throw away all trailing FUs.  RTP=20
> > is in virtually all cases run over UDP, and in the typical Internet=20
> > scenario UDP is lossy (in contrast to private, managed IP-network,=20
> > which may have other constraints, but are not the IETF's main=20
> > concern.) To set your remarks into context, let's first understand=20
> > what we are talking
> > about: the cost of slices is the overhead stemming from the=20
> > insertion of slice headers (in-picture syntax prediction) and from=20
> > the packet headers themselves.  And, of course, implementation=20
> > complexity, but we should not be in the business to encourage implement=
or laziness when
> > there would be a more complex, but better suited tool available.    The
> > additional packetization overhead is only incurred when, as a result=20
> > of incompetently filled packets (which, I agree, is more likely with
> > 64x64 CUs than with 16/16 macroblocks), an additional packet needs=20
> > to be inserted.  You may remember a quick analysis of mine we=20
> > discussed way back early in JCT, where we (I think) agreed that the=20
> > practical impact is negligible in almost all non-tile scenarios=20
> > (mostly because an additional overhead of 50 bytes or so--3% or less=20
> > of the coded picture size) is incurred statistically only rarely=20
> > (only in those cases where an additional packet would need to be=20
> > generated because of the video coding related overhead for the use=20
> > of slices).  The prediction overhead of the use of regular slices=20
> > has been shown to be substantial--the price one needs to pay for=20
> > independent decodability--but for entropy slices that overhead virtuall=
y does not exist.
> > With respect to tiles, I think you have a point though, especially=20
> > when considering the type of massive parallel implementations for=20
> > relatively small picture sizes some folks have been considering.
> > OTOH, because FUs are trivial to implement--some say in contrast to=20
> > slices--and because (I hope) we all agree that using FUs in error=20
> > prone scenarios is a bad idea if you could use slices (but for=20
> > reasons like the tile connection you mentioned), the draft should=20
> > IMO continue to set a preference for the use of regular slices over=20
> > FUs.  To avoid underperforming systems due to implementer laziness.
> > However, this is the IETF.  We don't have to worry about the=20
> > word-count of explanatory language.  In fact, explaining such=20
> > complex tradeoffs and relationships is generally encouraged here.  So l=
et's just do that:
> > express a preference of the use of regular slices (SHOULD) when you=20
> > expect losses and can use them (real-time encoding, no tiling=20
> > structure that would lead to unacceptable packetization overhead);=20
> > and suggest (MAY) the use of FUs in other scenarios.  Accompanied by=20
> > a more coherently expressed analysis.
> > Stephan
> >
> >
> > On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>  =
wrote:
> >
> >> Hi Ye-Kui,
> >>
> >> Thanks for your feedback on my comments, your suggestions look good=20
> >> to
> me.
> >>
> >> Regarding discouraging fragmentation units (FUs) for live-encoding=20
> >> scenarios in section 4.7, I think using FUs does make sense when=20
> >> you do not have many non-VLC NAL units for aggregation. The spatial=20
> >> granularity of slices was 16x16 pixels in H.264 but is typically
> >> 64x64 for HEVC which means that MTU size matching is done with=20
> >> units that are 16x larger. This may lead to a larger number of=20
> >> smaller packets when slices are used compared to FUs. In addition,=20
> >> there is the HEVC rule of slice and tile boundaries that makes the=20
> >> slice granularity equal to the tile granularity for cases when=20
> >> slices span multiple tiles. Finally, FUs are easier to implement=20
> >> since you do not need to care about when to break your slice to not=20
> >> exceed the MTU size limit. I think both slices and FUs has their=20
> >> merits and the choice between them for live-encoding should be left fo=
r the implementer.
> >>
> >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and=20
> >> the POC MSB sync issue, I agree that this is a corner case that we=20
> >> probably will not see much of in practice. I have no text change=20
> >> suggestion at the moment.
> >>
> >> BR
> >> Rickard
> >>
> >>
> >> -----Original Message-----
> >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >> Sent: den 24 juni 2013 01:00
> >> To: Rickard Sj=F6berg; payload@ietf.org
> >> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> >> format
> >>
> >> Hi Rickard,
> >>
> >> Thanks for the careful review and the comments. Please see inline belo=
w.
> >>
> >> BR, YK
> >>
> >>> -----Original Message-----
> >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>> Sent: Thursday, June 20, 2013 9:17 AM
> >>> To: Wang, Ye-Kui; payload@ietf.org
> >>> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> >>> format
> >>>
> >>> Dear all,
> >>>
> >>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and=20
> >>> have some questions/comments.
> >>>
> >>> My first question is what extensions of HEVC that
> >>> draft-schierl-payload-rtp-
> >>> h265 is intended to cover? The draft mentions "future  scalable =20
> >>> or 3D  video coding  extensions  of  this  specification", what=20
> >>> extensions do you refer to?
> >>> Is the intent to cover the all HEVC extensions in a single payload=20
> >>> specification?
> >>>
> >> [YK] That is in the semantics of LayerId (nuh_layer_id), where=20
> >> "this specification" should be replaced with "[HEVC]". It is sort=20
> >> of copy-and-paste error. Thanks for the good catching. No, there is=20
> >> no intention to cover HEVC extensions in this payload=20
> >> specification, though we intentionally to have the depacketization=20
> >> process and the use with feedback messages to work for HEVC scalabilit=
y and 3DV extensions.
> >>
> >>> Another question for my understanding is why "Receivers MUST pass=20
> >>> picture timing SEI messages and decoding unit information SEI=20
> >>> messages to the decoder"?
> >> [YK] Generally, RTP receivers should/must pass all NAL units=20
> >> specified by the video coding spec to the video decoders. This is=20
> >> emphasized here for the two timing related SEI messages after it is=20
> >> said that picture output timing in RTP timestamps should be used=20
> >> instead (to avoid giving a wrong impression to readers that the SEI=20
> >> messages should be ignored). If an RTP receiver discards the SEI=20
> >> messages, then HRD conformance checking for the bitstream that was=20
> >> possible would be disabled, and also the information related to=20
> >> frame
> doubling or tripping would be lost.
> >>
> >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The=20
> >>> fourth one does not seem to be a rule since there is no "MUST" or=20
> >>> "SHOULD" in the corresponding text.
> >> [YK] I see your point, it is only a "MAY" rule. An alternative to=20
> >> put this as a packetization rule is to put it as part of the=20
> >> semantics of NAL unit header (1.1.4), but that sub-section belongs=20
> >> to an overview wherein normative language (even "MAY") should not=20
> >> appear. One solution to this is to insert "Payload Header Usage"=20
> >> after 4.1 "RTP Header Usage" and include at least this item there.=20
> >> I will do this in the next version unless there is a better suggestion=
.
> >>
> >>> Further, the fifth one discourages using FUs, what are the reasons=20
> >>> behind that?
> >> [YK] The bullet item only discourages using FUs for live-encoding=20
> >> scenarios, wherein dependent slice segments should be used instead.
> >> This was added after a discussion (among the authors) on the need=20
> >> of whether to specify a payload structure for mixed FU and=20
> >> aggregation packets and
> > >from that discussion we concluded that encoding dependent slice=20
> > >segments
> >> at source coding level already allows for the use cases and using=20
> >> of FUs for live-encoding does not make sense. Please let us know if=20
> >> you think differently.
> >>
> >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> >>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ=20
> >>> between the encoder and decoder?
> >> [YK] Good question. In theory this is indeed possible when random=20
> >> accessing to a bitstream is performed. However, it would not happen=20
> >> in conversational applications where the feedback messages may be used=
.
> >> Therefore, to me this would just work just fine. But please feel=20
> >> free to make other suggestions.
> >>
> >>> The use of spatial-segmentation-idc may need some updates to be=20
> >>> useful, let me come back to that later on.
> >>>
> >> [YK] OK. Look forward to seeing your input herein.
> >>
> >>> I have also a number of spelling suggestions for your considerations:
> >>>
> >>> Section 1.1:
> >>> Replace "community" by "communities"
> >> [YK] I guess both are OK. But anyway I just changed it per your=20
> >> suggestion (for the next version).
> >>
> >>> Section 1.1.1:
> >>> Replace "In addition, interpolation filter" by "In addition, the=20
> >>> interpolation filter"
> >> [YK] Thanks - done.
> >>
> >>> Replace "skipping the transform coding" by "skipping the transform"
> >>> (transform_skip_flag of HEVC skips the transform, not the coding)
> >>>
> >> [YK] Done.
> >>
> >>> Section 1.1.2:
> >>> Replace:
> >>> "2) An indication of whether there is any parameter set within the=20
> >>> current coded video sequence that updates another parameter set of=20
> >>> the same type preceding in decoding order."
> >>> by:
> >>> "2) An indication of whether there is no parameter set update in=20
> >>> the coded video sequence."
> >>> since that is what no_parameter_set_update_flag in HEVC indicates.
> >>>
> >> [YK] Changed the wording to "An indication of whether there is no=20
> >> parameter set within the current coded video sequence that updates=20
> >> another parameter set of the same type preceding in decoding order."
> >>
> >>> Section 4.7:
> >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and=20
> >>> "FU
> >>> Type:  6 bits" to avoid confusion with the Type in the payload header=
.
> >>>
> >> [YK] Good point again. I will change the field name to be "FuType".
> >>
> >>> Section 6:
> >>> Replace "recovery" by "recover"
> >> [YK] Done.
> >>
> >>> Section 7.1:
> >>> Replace "level-id" by "level-idc"
> >> [YK] We are consistently using "id" for profile-id, level-id,=20
> >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> >>
> >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >> [YK] Done.
> >>
> >>> Section 8:
> >>> Replace "two  payload-specific  feedback  messages" by "a=20
> >>> payload-specific feedback  message", since only SPLI is "Assigned=20
> >>> in this memo".
> >>> Also, consider removing references to H.264 in the last paragraph=20
> >>> of Section
> >>> 8 since the memo is about HEVC.
> >> [YK] Good catch again. Changed.
> >>
> >>> Section 8.1:
> >>> Seems to me that "There MUST be exactly one RPSI contained in the=20
> >>> FCI field" should be "There MUST be exactly one SPLI contained in=20
> >>> the FCI field"
> >> [YK] Another good catch. Changed.
> >>
> >>>
> >>> Best Regards,
> >>> Rickard Sj=F6berg
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]=20
> >>> On Behalf Of Wang, Ye-Kui
> >>> Sent: den 11 juni 2013 19:00
> >>> To: payload@ietf.org
> >>> Subject: [payload] Submission of new versions of H.265/HEVC=20
> >>> payload format
> >>>
> >>> Dear All,
> >>>
> >>> We have just submitted versions 02 and 03 of=20
> >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> >>>
> >>> Version 02:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-02.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 02
> >>>
> >>> Version 03:
> >>> URL:
> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> >>> h265-03.txt
> >>> Htmlized:
> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>> Diff:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> >>> 03
> >>>
> >>> Version 02 includes huge changes compared to the earlier submitted=20
> >>> version 01. In a short summary, the authors have worked hard to=20
> >>> try to make the design complete, from both the payload structure=20
> >>> and the signaling points of view. Compared to version 02, version=20
> >>> 03 only contains a correction of the email address of an author.
> >>>
> >>> Due to that the industry is eager to deploy H.265/HEVC and other=20
> >>> standards bodies such as 3GPP rely on the payload format for=20
> >>> support of H.265/HEVC in RTP based video services, we need to=20
> >>> progress this draft relatively quickly.
> >>> Therefore, we would like to request quick reviews from interested=20
> >>> parties and also request for the WG status of this draft.
> >>>
> >>> BR, YK (on behalf of the authors)
> >>> _______________________________________________
> >>> payload mailing list
> >>> payload@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/payload
> >>>
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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

From yekuiw@qti.qualcomm.com  Wed Jul  3 23:01:53 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87F21F9F00 for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 23:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.782
X-Spam-Level: 
X-Spam-Status: No, score=-103.782 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYG3VRk2j35y for <payload@ietfa.amsl.com>; Wed,  3 Jul 2013 23:01:48 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDFB21F9ECA for <payload@ietf.org>; Wed,  3 Jul 2013 23:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372917708; x=1404453708; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RE3IHQADvBnyq19JKXOQlRmrRu1evXH0eJ3R5sRd6uo=; b=eWoVri3fnL2VxtYQSU+VroQiajCgIVb2cdr183V4ybIx7kpCP/EP8v2W LaU0WJ1Cz0uPwFt3KRIeXhW/OVQbZw5Nwht5Dh5jdZBWBMYxzTBzqWiXN KZTi4JZ2iQrayH9mqO46iAlFIaRTqJ8lcjc/hmBZoHE+aiyXabbftqNnm w=;
X-IronPort-AV: E=Sophos;i="4.87,992,1363158000"; d="scan'208";a="46734302"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 03 Jul 2013 23:01:47 -0700
Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 23:01:47 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 23:01:47 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, "Thomas Davies (thdavies)" <thdavies@cisco.com>, Stephan Wenger <stewe@stewe.org>,  "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHINrpiwi8/7UEygLhM2FJhH9ZlUBM9A
Date: Thu, 4 Jul 2013 06:01:45 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 06:01:53 -0000

An interesting idea. Using dependent slices (again :-) together with tiles =
would do the trick too (each tile in one dependent slice, and then each dep=
endent slice NAL unit in one single NAL unit packet).

Have you guys done an analysis comparing the pros and cons of the two alter=
native approaches?

BR, YK

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: Wednesday, July 03, 2013 9:51 PM
> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan We=
nger;
> Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Thomas, Paul and I have been working on improving packet loss resilience =
using
> fragments and tiles. I mentioned this to Stephan at IETF 86 in Orlando, a=
nd
> promised to have draft text ready before Berlin. Here is the proposed tex=
t
> along with an overview of the rationale.
>=20
> Rationale:
>=20
> 1. Resilience to packet loss requires independent slices or tiles. Since
> independence requires restrictions on some coding tools, both potentially=
 incur
> slight penalties in coding efficiency, with a smaller penalty for tiles.
>=20
> 2. Fragmentation in a higher layer like RTP can have several advantages o=
ver
> similar features in a codec layer like slices (independent or dependent).
> a. Efficiency: RTP fragmentation has finer (byte) granularity while slice=
s have
> much larger (CTB or tile) granularity. It also has less slice segment hea=
der
> overhead, especially for independent slices. This can impact the efficien=
cy of
> the packetized stream in terms of both bits and packets per second.
> b. Performance: Encoders must perform extra processing to limit slice siz=
es,
> which can impact encoder performance. Some implementations speculatively
> end a slice based on computed statistics (which aggravates a.), while oth=
ers
> recode a slice if the size is exceeded (which aggravates b.).
> c. Decoupling: Not all encoders will support limiting slice size to MTU s=
ize.
> Applications (for live or stored content) using such encoders can still s=
upport
> MTU limits using RTP fragmentation since it is decoupled from the encoder=
.
> d. Multi-party: The encoded content may go to multiple receivers with dif=
ferent
> MTUs. RTP fragmentation can handle this with lightweight repacketization =
at
> middle boxes whereas slices incur heavyweight transcoding.
>=20
> 3. Combining fragmentation and tiles can improve resilience while retaini=
ng the
> above advantages, if fragments are enhanced to contain offsets (similar t=
o IP
> fragmentation). This is described in the proposed draft text below, which=
 would
> immediately follow section 4.7 Fragmentation Units.
>=20
> Draft Text:
>=20
> 4.7.1 Fragmentation Units with Fragment Offsets
>=20
> If a fragmented NAL unit contains tiles, its slice segment header contain=
s
> offsets to the data of each tile. These offsets can be used for random ac=
cess to
> any tile for parallel processing, region of interest extraction, and resi=
lience to
> errors in other tiles. These offsets can also be used to provide resilien=
ce to
> packet loss, in conjunction with fragment offsets contained in two types =
of
> fragmentation units: FU-A2 and FU-A4.
>=20
> Fragmentation units FU-A2 and FU-A4 contain a fragment offset before the =
FU
> payload. FU-A2 contains a 2-byte offset as shown in Figure X. FU-A4 conta=
ins a
> 4-byte offset as shown in Figure Y. The offset indicates the total number=
 of
> bytes in all prior FU payloads of the fragmented NAL unit.
>=20
>=20
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | FU-A2 offset  |     DONL (optional)           |               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>    |                                                               |
>    |                         FU payload                            |
>    |                                                               |
>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               :...OPTIONAL RTP padding        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>                   Figure X   RTP payload format for FU-A2
>=20
>=20
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A4 offset                             | DONL(optional)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | DONL(optional)|                                               |
>    +-+-+-+-+-+-+-+-+         FU payload                            |
>    |                                                               |
>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               :...OPTIONAL RTP padding        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>                   Figure Y   RTP payload format for FU-A4
>=20
>=20
> Since the offset of the first FU payload of a fragmented NAL unit is zero=
, and
> the Start (S) bit in the FU header is sufficient to indicate this, the fi=
rst
> fragmentation unit of a fragmented NAL unit SHOULD use FU-A, but MAY use
> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation units of =
a
> fragmented NAL unit MAY use FU-A2 or FU-A4 with a non-zero offset. The St=
art
> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4 contains a=
 non-
> zero offset, and MUST be set if it contains a zero offset.
>=20
> If a fragmentation unit is lost, tiles in the lost fragmentation unit are=
 also lost.
> However, tiles which are successfully received in their entirety can be d=
ecoded
> if their slice segment header containing tile offsets is successfully rec=
eived,
> despite lost fragmentation units. Fragment offsets in FU-A2 or FU-A4 are
> required in order to recover from loss of prior fragmentation units and c=
ontinue
> decoding subsequent tiles.
>=20
> The following heuristic SHOULD be applied to determine if the lost
> fragmentation units are all part of the same fragmented NAL unit as
> subsequently received fragmentation units with identical RTP timestamps a=
nd
> identical values of NAL unit header layer ID and temporal ID.
>=20
> 1. Let N be the number of missing sequence numbers between two received
> fragmentation units with known offsets.
> 2. Let P be the FU payload size of the first of the two received FUs.
> 3. Let D be the difference in the offsets, minus P.
>    (This is the number of missing FU payload bytes.) 4. Let E be N times =
P.
>    (This is the estimated number of missing FU payload bytes.) 5. Let ERR=
OR be
> the absolute difference between D and E, divided by D.
> 6. If ERROR < 50%, it is likely all FUs are part of the same fragmented N=
AL unit,
> otherwise it is unlikely.
>=20
> Cheers,
> Mo
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Rickard Sj=F6berg
> Sent: Wednesday, July 03, 2013 3:38 PM
> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Dear all,
>=20
> I wrote slices and not dependent slices since the slice granularity and s=
lice/tile
> rule applies to both slices and dependent slices. Sorry for the confusion=
. I will
> now use 'independent slices' and 'dependent slices' to distinguish betwee=
n
> them.
>=20
> I do not question the use of independent slices, I find them useful in so=
me
> applications.
>=20
> But the current RTP payload text says:
>=20
> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>       video telephony, video conferencing, live streaming and live
>       broadcast, in which cases dependent slice segments SHOULD be used
>       when a slice should be transported in multiple RTP packets."
>=20
> I believe that FUs are a viable option to dependent slices for the reason=
s I listed
> in my previous e-mail and think that we should not recommend dependent
> slices over FUs but leave it to the implementer.
>=20
> BR
> Rickard
>=20
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Wang, Ye-Kui
> Sent: den 3 juli 2013 20:43
> To: Thomas Davies; Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi All,
>=20
> I drafted an email replying directly to Rickard but did not finish and th=
ere was a
> meeting (and then Stephan's and Thomas' emails came).
>=20
> I wanted to comment that Rickard was comparing the use of FUs vs slices, =
not
> FUs vs dependent slices, while the recommendation in the draft is
> recommending use of dependent slices over FUs in live-encoding scenarios =
(so
> this answers Thomas question: the intention was dependent slices ).
>=20
> In any case, it does not make much sense to try MTU size matching and at =
the
> same time use either dependent slices or FUs, because dependent slices an=
d
> FUs should not be used when there are considerable packet losses, while M=
TU
> size matching should be applied when there are considerable packet losses=
.
>=20
> For live encoding, whenever splitting of a regular slice is needed, the s=
plitting
> can be done by the encoder using dependent slices - and the encoder has m=
ore
> knowledge and is more powerful than the RTP packetizer and thus can do a
> better job for the splitting.
>=20
> BR, YK
>=20
>=20
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > Behalf Of Thomas Davies
> > Sent: Wednesday, July 03, 2013 9:34 AM
> > To: Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Hi Stephan
> >
> > I think I agree with Rickard.
> >
> > I think the text in question states a preference for _dependent_ slice
> > segments, which have no error resiliency advantage over FUs. Is this ju=
st a
> typo?
> >
> > <snip>
> >
> > FUs SHOULD NOT be applied in live-encoding scenarios such as
> >        video telephony, video conferencing, live streaming and live
> >        broadcast, in which cases dependent slice segments SHOULD be use=
d
> >        when a slice should be transported in multiple RTP packets.
> >
> >
> >
> > </snip>
> >
> > In general FUs may be used where error conditions are known to be
> > benign, for greater efficiency, and also where for whatever reason the
> > encoder cannot support MTU matching.
> >
> > We also are formulating some more general comments on this area which
> > we hope to provide more fully soon.
> >
> > best regards
> >
> > Thomas
> >
> >
> > On 03/07/13 17:22, Stephan Wenger wrote:
> > > Hi Rickard,
> > > Commenting only on slices vs. FUs.
> > > The preference for slices over FUs, historically, was pushed by
> > > myself into RFC 3984 for reasons of error resilience, and was moved
> > > over to this draft for the same reason.  Loose a slice, and you can
> > > recover at the next slice boundary; loose an FU, and you have to
> > > wait for the next slice header and throw away all trailing FUs.  RTP
> > > is in virtually all cases run over UDP, and in the typical Internet
> > > scenario UDP is lossy (in contrast to private, managed IP-network,
> > > which may have other constraints, but are not the IETF's main
> > > concern.) To set your remarks into context, let's first understand
> > > what we are talking
> > > about: the cost of slices is the overhead stemming from the
> > > insertion of slice headers (in-picture syntax prediction) and from
> > > the packet headers themselves.  And, of course, implementation
> > > complexity, but we should not be in the business to encourage impleme=
ntor
> laziness when
> > > there would be a more complex, but better suited tool available.    T=
he
> > > additional packetization overhead is only incurred when, as a result
> > > of incompetently filled packets (which, I agree, is more likely with
> > > 64x64 CUs than with 16/16 macroblocks), an additional packet needs
> > > to be inserted.  You may remember a quick analysis of mine we
> > > discussed way back early in JCT, where we (I think) agreed that the
> > > practical impact is negligible in almost all non-tile scenarios
> > > (mostly because an additional overhead of 50 bytes or so--3% or less
> > > of the coded picture size) is incurred statistically only rarely
> > > (only in those cases where an additional packet would need to be
> > > generated because of the video coding related overhead for the use
> > > of slices).  The prediction overhead of the use of regular slices
> > > has been shown to be substantial--the price one needs to pay for
> > > independent decodability--but for entropy slices that overhead virtua=
lly
> does not exist.
> > > With respect to tiles, I think you have a point though, especially
> > > when considering the type of massive parallel implementations for
> > > relatively small picture sizes some folks have been considering.
> > > OTOH, because FUs are trivial to implement--some say in contrast to
> > > slices--and because (I hope) we all agree that using FUs in error
> > > prone scenarios is a bad idea if you could use slices (but for
> > > reasons like the tile connection you mentioned), the draft should
> > > IMO continue to set a preference for the use of regular slices over
> > > FUs.  To avoid underperforming systems due to implementer laziness.
> > > However, this is the IETF.  We don't have to worry about the
> > > word-count of explanatory language.  In fact, explaining such
> > > complex tradeoffs and relationships is generally encouraged here.  So=
 let's
> just do that:
> > > express a preference of the use of regular slices (SHOULD) when you
> > > expect losses and can use them (real-time encoding, no tiling
> > > structure that would lead to unacceptable packetization overhead);
> > > and suggest (MAY) the use of FUs in other scenarios.  Accompanied by
> > > a more coherently expressed analysis.
> > > Stephan
> > >
> > >
> > > On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>
> wrote:
> > >
> > >> Hi Ye-Kui,
> > >>
> > >> Thanks for your feedback on my comments, your suggestions look good
> > >> to
> > me.
> > >>
> > >> Regarding discouraging fragmentation units (FUs) for live-encoding
> > >> scenarios in section 4.7, I think using FUs does make sense when
> > >> you do not have many non-VLC NAL units for aggregation. The spatial
> > >> granularity of slices was 16x16 pixels in H.264 but is typically
> > >> 64x64 for HEVC which means that MTU size matching is done with
> > >> units that are 16x larger. This may lead to a larger number of
> > >> smaller packets when slices are used compared to FUs. In addition,
> > >> there is the HEVC rule of slice and tile boundaries that makes the
> > >> slice granularity equal to the tile granularity for cases when
> > >> slices span multiple tiles. Finally, FUs are easier to implement
> > >> since you do not need to care about when to break your slice to not
> > >> exceed the MTU size limit. I think both slices and FUs has their
> > >> merits and the choice between them for live-encoding should be left =
for
> the implementer.
> > >>
> > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
> > >> the POC MSB sync issue, I agree that this is a corner case that we
> > >> probably will not see much of in practice. I have no text change
> > >> suggestion at the moment.
> > >>
> > >> BR
> > >> Rickard
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > >> Sent: den 24 juni 2013 01:00
> > >> To: Rickard Sj=F6berg; payload@ietf.org
> > >> Subject: RE: Submission of new versions of H.265/HEVC payload
> > >> format
> > >>
> > >> Hi Rickard,
> > >>
> > >> Thanks for the careful review and the comments. Please see inline be=
low.
> > >>
> > >> BR, YK
> > >>
> > >>> -----Original Message-----
> > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > >>> To: Wang, Ye-Kui; payload@ietf.org
> > >>> Subject: RE: Submission of new versions of H.265/HEVC payload
> > >>> format
> > >>>
> > >>> Dear all,
> > >>>
> > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
> > >>> have some questions/comments.
> > >>>
> > >>> My first question is what extensions of HEVC that
> > >>> draft-schierl-payload-rtp-
> > >>> h265 is intended to cover? The draft mentions "future  scalable or
> > >>> 3D  video coding  extensions  of  this  specification", what
> > >>> extensions do you refer to?
> > >>> Is the intent to cover the all HEVC extensions in a single payload
> > >>> specification?
> > >>>
> > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> > >> "this specification" should be replaced with "[HEVC]". It is sort
> > >> of copy-and-paste error. Thanks for the good catching. No, there is
> > >> no intention to cover HEVC extensions in this payload
> > >> specification, though we intentionally to have the depacketization
> > >> process and the use with feedback messages to work for HEVC scalabil=
ity
> and 3DV extensions.
> > >>
> > >>> Another question for my understanding is why "Receivers MUST pass
> > >>> picture timing SEI messages and decoding unit information SEI
> > >>> messages to the decoder"?
> > >> [YK] Generally, RTP receivers should/must pass all NAL units
> > >> specified by the video coding spec to the video decoders. This is
> > >> emphasized here for the two timing related SEI messages after it is
> > >> said that picture output timing in RTP timestamps should be used
> > >> instead (to avoid giving a wrong impression to readers that the SEI
> > >> messages should be ignored). If an RTP receiver discards the SEI
> > >> messages, then HRD conformance checking for the bitstream that was
> > >> possible would be disabled, and also the information related to
> > >> frame
> > doubling or tripping would be lost.
> > >>
> > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
> > >>> fourth one does not seem to be a rule since there is no "MUST" or
> > >>> "SHOULD" in the corresponding text.
> > >> [YK] I see your point, it is only a "MAY" rule. An alternative to
> > >> put this as a packetization rule is to put it as part of the
> > >> semantics of NAL unit header (1.1.4), but that sub-section belongs
> > >> to an overview wherein normative language (even "MAY") should not
> > >> appear. One solution to this is to insert "Payload Header Usage"
> > >> after 4.1 "RTP Header Usage" and include at least this item there.
> > >> I will do this in the next version unless there is a better suggesti=
on.
> > >>
> > >>> Further, the fifth one discourages using FUs, what are the reasons
> > >>> behind that?
> > >> [YK] The bullet item only discourages using FUs for live-encoding
> > >> scenarios, wherein dependent slice segments should be used instead.
> > >> This was added after a discussion (among the authors) on the need
> > >> of whether to specify a payload structure for mixed FU and
> > >> aggregation packets and
> > > >from that discussion we concluded that encoding dependent slice
> > > >segments
> > >> at source coding level already allows for the use cases and using
> > >> of FUs for live-encoding does not make sense. Please let us know if
> > >> you think differently.
> > >>
> > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
> > >>> between the encoder and decoder?
> > >> [YK] Good question. In theory this is indeed possible when random
> > >> accessing to a bitstream is performed. However, it would not happen
> > >> in conversational applications where the feedback messages may be us=
ed.
> > >> Therefore, to me this would just work just fine. But please feel
> > >> free to make other suggestions.
> > >>
> > >>> The use of spatial-segmentation-idc may need some updates to be
> > >>> useful, let me come back to that later on.
> > >>>
> > >> [YK] OK. Look forward to seeing your input herein.
> > >>
> > >>> I have also a number of spelling suggestions for your consideration=
s:
> > >>>
> > >>> Section 1.1:
> > >>> Replace "community" by "communities"
> > >> [YK] I guess both are OK. But anyway I just changed it per your
> > >> suggestion (for the next version).
> > >>
> > >>> Section 1.1.1:
> > >>> Replace "In addition, interpolation filter" by "In addition, the
> > >>> interpolation filter"
> > >> [YK] Thanks - done.
> > >>
> > >>> Replace "skipping the transform coding" by "skipping the transform"
> > >>> (transform_skip_flag of HEVC skips the transform, not the coding)
> > >>>
> > >> [YK] Done.
> > >>
> > >>> Section 1.1.2:
> > >>> Replace:
> > >>> "2) An indication of whether there is any parameter set within the
> > >>> current coded video sequence that updates another parameter set of
> > >>> the same type preceding in decoding order."
> > >>> by:
> > >>> "2) An indication of whether there is no parameter set update in
> > >>> the coded video sequence."
> > >>> since that is what no_parameter_set_update_flag in HEVC indicates.
> > >>>
> > >> [YK] Changed the wording to "An indication of whether there is no
> > >> parameter set within the current coded video sequence that updates
> > >> another parameter set of the same type preceding in decoding order."
> > >>
> > >>> Section 4.7:
> > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
> > >>> "FU
> > >>> Type:  6 bits" to avoid confusion with the Type in the payload head=
er.
> > >>>
> > >> [YK] Good point again. I will change the field name to be "FuType".
> > >>
> > >>> Section 6:
> > >>> Replace "recovery" by "recover"
> > >> [YK] Done.
> > >>
> > >>> Section 7.1:
> > >>> Replace "level-id" by "level-idc"
> > >> [YK] We are consistently using "id" for profile-id, level-id,
> > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> > >>
> > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > >> [YK] Done.
> > >>
> > >>> Section 8:
> > >>> Replace "two  payload-specific  feedback  messages" by "a
> > >>> payload-specific feedback  message", since only SPLI is "Assigned
> > >>> in this memo".
> > >>> Also, consider removing references to H.264 in the last paragraph
> > >>> of Section
> > >>> 8 since the memo is about HEVC.
> > >> [YK] Good catch again. Changed.
> > >>
> > >>> Section 8.1:
> > >>> Seems to me that "There MUST be exactly one RPSI contained in the
> > >>> FCI field" should be "There MUST be exactly one SPLI contained in
> > >>> the FCI field"
> > >> [YK] Another good catch. Changed.
> > >>
> > >>>
> > >>> Best Regards,
> > >>> Rickard Sj=F6berg
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> > >>> On Behalf Of Wang, Ye-Kui
> > >>> Sent: den 11 juni 2013 19:00
> > >>> To: payload@ietf.org
> > >>> Subject: [payload] Submission of new versions of H.265/HEVC
> > >>> payload format
> > >>>
> > >>> Dear All,
> > >>>
> > >>> We have just submitted versions 02 and 03 of
> > >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> > >>>
> > >>> Version 02:
> > >>> URL:
> > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > >>> h265-02.txt
> > >>> Htmlized:
> > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > >>> Diff:
> > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> > >>> 02
> > >>>
> > >>> Version 03:
> > >>> URL:
> > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > >>> h265-03.txt
> > >>> Htmlized:
> > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > >>> Diff:
> > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> > >>> 03
> > >>>
> > >>> Version 02 includes huge changes compared to the earlier submitted
> > >>> version 01. In a short summary, the authors have worked hard to
> > >>> try to make the design complete, from both the payload structure
> > >>> and the signaling points of view. Compared to version 02, version
> > >>> 03 only contains a correction of the email address of an author.
> > >>>
> > >>> Due to that the industry is eager to deploy H.265/HEVC and other
> > >>> standards bodies such as 3GPP rely on the payload format for
> > >>> support of H.265/HEVC in RTP based video services, we need to
> > >>> progress this draft relatively quickly.
> > >>> Therefore, we would like to request quick reviews from interested
> > >>> parties and also request for the WG status of this draft.
> > >>>
> > >>> BR, YK (on behalf of the authors)
> > >>> _______________________________________________
> > >>> payload mailing list
> > >>> payload@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/payload
> > >>>
> > >> _______________________________________________
> > >> payload mailing list
> > >> payload@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/payload
> > > _______________________________________________
> > > payload mailing list
> > > payload@ietf.org
> > > https://www.ietf.org/mailman/listinfo/payload
> >
> > _______________________________________________
> > payload mailing list
> > payload@ietf.org
> > https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

From thdavies@cisco.com  Thu Jul  4 01:49:05 2013
Return-Path: <thdavies@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B19421F9E7F for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 01:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level: 
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZONCTvWEwGL for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 01:49:00 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EC27121F9A04 for <payload@ietf.org>; Thu,  4 Jul 2013 01:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29574; q=dns/txt; s=iport; t=1372927740; x=1374137340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qd/JRZwm4I3gI+wKwo0Q8EXiSLVA7FDyKWkhWgJSLKA=; b=GVO2SVR1ZK80hpv23j11sThDN9CQ2/hmvTvfpaMg/sHXt1ieuQRgLvh4 3wowdeKbWa9js6x3XrH+K4GLXdhzEmxzMfufTREd6BkSLVpgSLgzf+Rv6 yTCDBBHnPoUKjcW7avU7du6rnIuJsTbMpqwTdGcQ1kE8Rr+c5mCW02yMb I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAOg11VGtJV2a/2dsb2JhbABagwkyQwbAPoEEFnSCIwEBAQMBAQEBF1QEBwwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCAELB4duBgcFuWKOHwoBCgWBATEHBoJ+aQOIa4sMhHuQHIMRgWkIFyA
X-IronPort-AV: E=Sophos;i="4.87,993,1363132800"; d="scan'208";a="230904727"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 04 Jul 2013 08:48:56 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r648muJ5000894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jul 2013 08:48:56 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 03:48:55 -0500
From: "Thomas Davies (thdavies)" <thdavies@cisco.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHIJbt9N9SGscUaRXY0b76N0A5lUWtqA///U2oA=
Date: Thu, 4 Jul 2013 08:48:55 +0000
Message-ID: <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.86.192]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 08:49:05 -0000

Yes, we did think about one tile per packet or N tiles per packet, also: I =
guess that is where we started from. Then you could indeed align missing ti=
les with missing sequence numbers.=20

The issue is that you need to guarantee that you are doing this for it to b=
e useful, and the decoder needs to know that this is guaranteed through som=
e form of other signalling. However, the bitstream chunk associated to a ti=
le is extremely variable, and many tile chunks would be very small. So ther=
e is significant packetization overhead for them if there is one tile per p=
acket.=20

Having N>1 reduces this overhead, but it is still there and as N increases =
you run the risk of breaking the MTU size which then requires that you have=
 to re-encode to fit things in and meet the guarantee. There is definitely =
no time to re-encode whole tiles, especially if you are already using them =
for parallelization. Thus you might have to break the guarantee and fragmen=
t the packet anyhow, losing the resilience.
=20
The advantage that we see with the proposal is that you can get fairly simi=
lar resilience to regular slice MTU-size matching, but with much lower over=
heads as you can have a single regular slice header per frame, yet have a "=
dumb" packetization process and no need to re-encode to hit MTU targets. In=
 H264 MTU matching usually means re-encoding just one or two 16x16 MBs. In =
H265 it involves re-encoding at least one 64x64 CTB, and if you are doing t=
iles then you can get tiny "dangling slices" at the end of a tile, which me=
ans more small packets.

Best regards

Thomas

-----Original Message-----
From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20
Sent: 04 July 2013 07:02
To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies); Steph=
an Wenger; Paul Bright-Thomas (paubrigh)
Cc: payload@ietf.org
Subject: RE: [payload] Submission of new versions of H.265/HEVC payload for=
mat


An interesting idea. Using dependent slices (again :-) together with tiles =
would do the trick too (each tile in one dependent slice, and then each dep=
endent slice NAL unit in one single NAL unit packet).

Have you guys done an analysis comparing the pros and cons of the two alter=
native approaches?

BR, YK

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: Wednesday, July 03, 2013 9:51 PM
> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan=20
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Thomas, Paul and I have been working on improving packet loss=20
> resilience using fragments and tiles. I mentioned this to Stephan at=20
> IETF 86 in Orlando, and promised to have draft text ready before=20
> Berlin. Here is the proposed text along with an overview of the rationale=
.
>=20
> Rationale:
>=20
> 1. Resilience to packet loss requires independent slices or tiles.=20
> Since independence requires restrictions on some coding tools, both=20
> potentially incur slight penalties in coding efficiency, with a smaller p=
enalty for tiles.
>=20
> 2. Fragmentation in a higher layer like RTP can have several=20
> advantages over similar features in a codec layer like slices (independen=
t or dependent).
> a. Efficiency: RTP fragmentation has finer (byte) granularity while=20
> slices have much larger (CTB or tile) granularity. It also has less=20
> slice segment header overhead, especially for independent slices. This=20
> can impact the efficiency of the packetized stream in terms of both bits =
and packets per second.
> b. Performance: Encoders must perform extra processing to limit slice=20
> sizes, which can impact encoder performance. Some implementations=20
> speculatively end a slice based on computed statistics (which=20
> aggravates a.), while others recode a slice if the size is exceeded (whic=
h aggravates b.).
> c. Decoupling: Not all encoders will support limiting slice size to MTU s=
ize.
> Applications (for live or stored content) using such encoders can=20
> still support MTU limits using RTP fragmentation since it is decoupled fr=
om the encoder.
> d. Multi-party: The encoded content may go to multiple receivers with=20
> different MTUs. RTP fragmentation can handle this with lightweight=20
> repacketization at middle boxes whereas slices incur heavyweight transcod=
ing.
>=20
> 3. Combining fragmentation and tiles can improve resilience while=20
> retaining the above advantages, if fragments are enhanced to contain=20
> offsets (similar to IP fragmentation). This is described in the=20
> proposed draft text below, which would immediately follow section 4.7 Fra=
gmentation Units.
>=20
> Draft Text:
>=20
> 4.7.1 Fragmentation Units with Fragment Offsets
>=20
> If a fragmented NAL unit contains tiles, its slice segment header=20
> contains offsets to the data of each tile. These offsets can be used=20
> for random access to any tile for parallel processing, region of=20
> interest extraction, and resilience to errors in other tiles. These=20
> offsets can also be used to provide resilience to packet loss, in=20
> conjunction with fragment offsets contained in two types of fragmentation=
 units: FU-A2 and FU-A4.
>=20
> Fragmentation units FU-A2 and FU-A4 contain a fragment offset before=20
> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.=20
> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset=20
> indicates the total number of bytes in all prior FU payloads of the fragm=
ented NAL unit.
>=20
>=20
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | FU-A2 offset  |     DONL (optional)           |               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>    |                                                               |
>    |                         FU payload                            |
>    |                                                               |
>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               :...OPTIONAL RTP padding        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>                   Figure X   RTP payload format for FU-A2
>=20
>=20
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      FU-A4 offset                             | DONL(optional)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | DONL(optional)|                                               |
>    +-+-+-+-+-+-+-+-+         FU payload                            |
>    |                                                               |
>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               :...OPTIONAL RTP padding        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>                   Figure Y   RTP payload format for FU-A4
>=20
>=20
> Since the offset of the first FU payload of a fragmented NAL unit is=20
> zero, and the Start (S) bit in the FU header is sufficient to indicate=20
> this, the first fragmentation unit of a fragmented NAL unit SHOULD use=20
> FU-A, but MAY use
> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation units=20
> of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a non-zero=20
> offset. The Start
> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4=20
> contains a non- zero offset, and MUST be set if it contains a zero offset=
.
>=20
> If a fragmentation unit is lost, tiles in the lost fragmentation unit are=
 also lost.
> However, tiles which are successfully received in their entirety can=20
> be decoded if their slice segment header containing tile offsets is=20
> successfully received, despite lost fragmentation units. Fragment=20
> offsets in FU-A2 or FU-A4 are required in order to recover from loss=20
> of prior fragmentation units and continue decoding subsequent tiles.
>=20
> The following heuristic SHOULD be applied to determine if the lost=20
> fragmentation units are all part of the same fragmented NAL unit as=20
> subsequently received fragmentation units with identical RTP=20
> timestamps and identical values of NAL unit header layer ID and temporal =
ID.
>=20
> 1. Let N be the number of missing sequence numbers between two=20
> received fragmentation units with known offsets.
> 2. Let P be the FU payload size of the first of the two received FUs.
> 3. Let D be the difference in the offsets, minus P.
>    (This is the number of missing FU payload bytes.) 4. Let E be N times =
P.
>    (This is the estimated number of missing FU payload bytes.) 5. Let=20
> ERROR be the absolute difference between D and E, divided by D.
> 6. If ERROR < 50%, it is likely all FUs are part of the same=20
> fragmented NAL unit, otherwise it is unlikely.
>=20
> Cheers,
> Mo
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> Behalf Of Rickard Sj=F6berg
> Sent: Wednesday, July 03, 2013 3:38 PM
> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Dear all,
>=20
> I wrote slices and not dependent slices since the slice granularity=20
> and slice/tile rule applies to both slices and dependent slices. Sorry=20
> for the confusion. I will now use 'independent slices' and 'dependent=20
> slices' to distinguish between them.
>=20
> I do not question the use of independent slices, I find them useful in=20
> some applications.
>=20
> But the current RTP payload text says:
>=20
> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>       video telephony, video conferencing, live streaming and live
>       broadcast, in which cases dependent slice segments SHOULD be used
>       when a slice should be transported in multiple RTP packets."
>=20
> I believe that FUs are a viable option to dependent slices for the=20
> reasons I listed in my previous e-mail and think that we should not=20
> recommend dependent slices over FUs but leave it to the implementer.
>=20
> BR
> Rickard
>=20
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> Behalf Of Wang, Ye-Kui
> Sent: den 3 juli 2013 20:43
> To: Thomas Davies; Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Hi All,
>=20
> I drafted an email replying directly to Rickard but did not finish and=20
> there was a meeting (and then Stephan's and Thomas' emails came).
>=20
> I wanted to comment that Rickard was comparing the use of FUs vs=20
> slices, not FUs vs dependent slices, while the recommendation in the=20
> draft is recommending use of dependent slices over FUs in=20
> live-encoding scenarios (so this answers Thomas question: the intention w=
as dependent slices ).
>=20
> In any case, it does not make much sense to try MTU size matching and=20
> at the same time use either dependent slices or FUs, because dependent=20
> slices and FUs should not be used when there are considerable packet=20
> losses, while MTU size matching should be applied when there are consider=
able packet losses.
>=20
> For live encoding, whenever splitting of a regular slice is needed,=20
> the splitting can be done by the encoder using dependent slices - and=20
> the encoder has more knowledge and is more powerful than the RTP=20
> packetizer and thus can do a better job for the splitting.
>=20
> BR, YK
>=20
>=20
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> > Behalf Of Thomas Davies
> > Sent: Wednesday, July 03, 2013 9:34 AM
> > To: Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> > payload format
> >
> > Hi Stephan
> >
> > I think I agree with Rickard.
> >
> > I think the text in question states a preference for _dependent_=20
> > slice segments, which have no error resiliency advantage over FUs.=20
> > Is this just a
> typo?
> >
> > <snip>
> >
> > FUs SHOULD NOT be applied in live-encoding scenarios such as
> >        video telephony, video conferencing, live streaming and live
> >        broadcast, in which cases dependent slice segments SHOULD be use=
d
> >        when a slice should be transported in multiple RTP packets.
> >
> >
> >
> > </snip>
> >
> > In general FUs may be used where error conditions are known to be=20
> > benign, for greater efficiency, and also where for whatever reason=20
> > the encoder cannot support MTU matching.
> >
> > We also are formulating some more general comments on this area=20
> > which we hope to provide more fully soon.
> >
> > best regards
> >
> > Thomas
> >
> >
> > On 03/07/13 17:22, Stephan Wenger wrote:
> > > Hi Rickard,
> > > Commenting only on slices vs. FUs.
> > > The preference for slices over FUs, historically, was pushed by=20
> > > myself into RFC 3984 for reasons of error resilience, and was=20
> > > moved over to this draft for the same reason.  Loose a slice, and=20
> > > you can recover at the next slice boundary; loose an FU, and you=20
> > > have to wait for the next slice header and throw away all trailing=20
> > > FUs.  RTP is in virtually all cases run over UDP, and in the=20
> > > typical Internet scenario UDP is lossy (in contrast to private,=20
> > > managed IP-network, which may have other constraints, but are not=20
> > > the IETF's main
> > > concern.) To set your remarks into context, let's first understand=20
> > > what we are talking
> > > about: the cost of slices is the overhead stemming from the=20
> > > insertion of slice headers (in-picture syntax prediction) and from=20
> > > the packet headers themselves.  And, of course, implementation=20
> > > complexity, but we should not be in the business to encourage=20
> > > implementor
> laziness when
> > > there would be a more complex, but better suited tool available.    T=
he
> > > additional packetization overhead is only incurred when, as a=20
> > > result of incompetently filled packets (which, I agree, is more=20
> > > likely with
> > > 64x64 CUs than with 16/16 macroblocks), an additional packet needs=20
> > > to be inserted.  You may remember a quick analysis of mine we=20
> > > discussed way back early in JCT, where we (I think) agreed that=20
> > > the practical impact is negligible in almost all non-tile=20
> > > scenarios (mostly because an additional overhead of 50 bytes or=20
> > > so--3% or less of the coded picture size) is incurred=20
> > > statistically only rarely (only in those cases where an additional=20
> > > packet would need to be generated because of the video coding=20
> > > related overhead for the use of slices).  The prediction overhead=20
> > > of the use of regular slices has been shown to be substantial--the=20
> > > price one needs to pay for independent decodability--but for=20
> > > entropy slices that overhead virtually
> does not exist.
> > > With respect to tiles, I think you have a point though, especially=20
> > > when considering the type of massive parallel implementations for=20
> > > relatively small picture sizes some folks have been considering.
> > > OTOH, because FUs are trivial to implement--some say in contrast=20
> > > to slices--and because (I hope) we all agree that using FUs in=20
> > > error prone scenarios is a bad idea if you could use slices (but=20
> > > for reasons like the tile connection you mentioned), the draft=20
> > > should IMO continue to set a preference for the use of regular=20
> > > slices over FUs.  To avoid underperforming systems due to implementer=
 laziness.
> > > However, this is the IETF.  We don't have to worry about the=20
> > > word-count of explanatory language.  In fact, explaining such=20
> > > complex tradeoffs and relationships is generally encouraged here. =20
> > > So let's
> just do that:
> > > express a preference of the use of regular slices (SHOULD) when=20
> > > you expect losses and can use them (real-time encoding, no tiling=20
> > > structure that would lead to unacceptable packetization overhead);=20
> > > and suggest (MAY) the use of FUs in other scenarios.  Accompanied=20
> > > by a more coherently expressed analysis.
> > > Stephan
> > >
> > >
> > > On 7.3.2013 06:46 , "Rickard=20
> > > Sj=F6berg"<rickard.sjoberg@ericsson.com>
> wrote:
> > >
> > >> Hi Ye-Kui,
> > >>
> > >> Thanks for your feedback on my comments, your suggestions look=20
> > >> good to
> > me.
> > >>
> > >> Regarding discouraging fragmentation units (FUs) for=20
> > >> live-encoding scenarios in section 4.7, I think using FUs does=20
> > >> make sense when you do not have many non-VLC NAL units for=20
> > >> aggregation. The spatial granularity of slices was 16x16 pixels=20
> > >> in H.264 but is typically
> > >> 64x64 for HEVC which means that MTU size matching is done with=20
> > >> units that are 16x larger. This may lead to a larger number of=20
> > >> smaller packets when slices are used compared to FUs. In=20
> > >> addition, there is the HEVC rule of slice and tile boundaries=20
> > >> that makes the slice granularity equal to the tile granularity=20
> > >> for cases when slices span multiple tiles. Finally, FUs are=20
> > >> easier to implement since you do not need to care about when to=20
> > >> break your slice to not exceed the MTU size limit. I think both=20
> > >> slices and FUs has their merits and the choice between them for=20
> > >> live-encoding should be left for
> the implementer.
> > >>
> > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2=20
> > >> and the POC MSB sync issue, I agree that this is a corner case=20
> > >> that we probably will not see much of in practice. I have no text=20
> > >> change suggestion at the moment.
> > >>
> > >> BR
> > >> Rickard
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > >> Sent: den 24 juni 2013 01:00
> > >> To: Rickard Sj=F6berg; payload@ietf.org
> > >> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> > >> format
> > >>
> > >> Hi Rickard,
> > >>
> > >> Thanks for the careful review and the comments. Please see inline be=
low.
> > >>
> > >> BR, YK
> > >>
> > >>> -----Original Message-----
> > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > >>> To: Wang, Ye-Kui; payload@ietf.org
> > >>> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> > >>> format
> > >>>
> > >>> Dear all,
> > >>>
> > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03=20
> > >>> and have some questions/comments.
> > >>>
> > >>> My first question is what extensions of HEVC that
> > >>> draft-schierl-payload-rtp-
> > >>> h265 is intended to cover? The draft mentions "future  scalable=20
> > >>> or 3D  video coding  extensions  of  this  specification", what=20
> > >>> extensions do you refer to?
> > >>> Is the intent to cover the all HEVC extensions in a single=20
> > >>> payload specification?
> > >>>
> > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where=20
> > >> "this specification" should be replaced with "[HEVC]". It is sort=20
> > >> of copy-and-paste error. Thanks for the good catching. No, there=20
> > >> is no intention to cover HEVC extensions in this payload=20
> > >> specification, though we intentionally to have the=20
> > >> depacketization process and the use with feedback messages to=20
> > >> work for HEVC scalability
> and 3DV extensions.
> > >>
> > >>> Another question for my understanding is why "Receivers MUST=20
> > >>> pass picture timing SEI messages and decoding unit information=20
> > >>> SEI messages to the decoder"?
> > >> [YK] Generally, RTP receivers should/must pass all NAL units=20
> > >> specified by the video coding spec to the video decoders. This is=20
> > >> emphasized here for the two timing related SEI messages after it=20
> > >> is said that picture output timing in RTP timestamps should be=20
> > >> used instead (to avoid giving a wrong impression to readers that=20
> > >> the SEI messages should be ignored). If an RTP receiver discards=20
> > >> the SEI messages, then HRD conformance checking for the bitstream=20
> > >> that was possible would be disabled, and also the information=20
> > >> related to frame
> > doubling or tripping would be lost.
> > >>
> > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.=20
> > >>> The fourth one does not seem to be a rule since there is no=20
> > >>> "MUST" or "SHOULD" in the corresponding text.
> > >> [YK] I see your point, it is only a "MAY" rule. An alternative to=20
> > >> put this as a packetization rule is to put it as part of the=20
> > >> semantics of NAL unit header (1.1.4), but that sub-section=20
> > >> belongs to an overview wherein normative language (even "MAY")=20
> > >> should not appear. One solution to this is to insert "Payload Header=
 Usage"
> > >> after 4.1 "RTP Header Usage" and include at least this item there.
> > >> I will do this in the next version unless there is a better suggesti=
on.
> > >>
> > >>> Further, the fifth one discourages using FUs, what are the=20
> > >>> reasons behind that?
> > >> [YK] The bullet item only discourages using FUs for live-encoding=20
> > >> scenarios, wherein dependent slice segments should be used instead.
> > >> This was added after a discussion (among the authors) on the need=20
> > >> of whether to specify a payload structure for mixed FU and=20
> > >> aggregation packets and
> > > >from that discussion we concluded that encoding dependent slice=20
> > > >segments
> > >> at source coding level already allows for the use cases and using=20
> > >> of FUs for live-encoding does not make sense. Please let us know=20
> > >> if you think differently.
> > >>
> > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may=20
> > >>> differ between the encoder and decoder?
> > >> [YK] Good question. In theory this is indeed possible when random=20
> > >> accessing to a bitstream is performed. However, it would not=20
> > >> happen in conversational applications where the feedback messages ma=
y be used.
> > >> Therefore, to me this would just work just fine. But please feel=20
> > >> free to make other suggestions.
> > >>
> > >>> The use of spatial-segmentation-idc may need some updates to be=20
> > >>> useful, let me come back to that later on.
> > >>>
> > >> [YK] OK. Look forward to seeing your input herein.
> > >>
> > >>> I have also a number of spelling suggestions for your consideration=
s:
> > >>>
> > >>> Section 1.1:
> > >>> Replace "community" by "communities"
> > >> [YK] I guess both are OK. But anyway I just changed it per your=20
> > >> suggestion (for the next version).
> > >>
> > >>> Section 1.1.1:
> > >>> Replace "In addition, interpolation filter" by "In addition, the=20
> > >>> interpolation filter"
> > >> [YK] Thanks - done.
> > >>
> > >>> Replace "skipping the transform coding" by "skipping the transform"
> > >>> (transform_skip_flag of HEVC skips the transform, not the=20
> > >>> coding)
> > >>>
> > >> [YK] Done.
> > >>
> > >>> Section 1.1.2:
> > >>> Replace:
> > >>> "2) An indication of whether there is any parameter set within=20
> > >>> the current coded video sequence that updates another parameter=20
> > >>> set of the same type preceding in decoding order."
> > >>> by:
> > >>> "2) An indication of whether there is no parameter set update in=20
> > >>> the coded video sequence."
> > >>> since that is what no_parameter_set_update_flag in HEVC indicates.
> > >>>
> > >> [YK] Changed the wording to "An indication of whether there is no=20
> > >> parameter set within the current coded video sequence that=20
> > >> updates another parameter set of the same type preceding in decoding=
 order."
> > >>
> > >>> Section 4.7:
> > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"=20
> > >>> and "FU
> > >>> Type:  6 bits" to avoid confusion with the Type in the payload head=
er.
> > >>>
> > >> [YK] Good point again. I will change the field name to be "FuType".
> > >>
> > >>> Section 6:
> > >>> Replace "recovery" by "recover"
> > >> [YK] Done.
> > >>
> > >>> Section 7.1:
> > >>> Replace "level-id" by "level-idc"
> > >> [YK] We are consistently using "id" for profile-id, level-id,=20
> > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> > >>
> > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > >> [YK] Done.
> > >>
> > >>> Section 8:
> > >>> Replace "two  payload-specific  feedback  messages" by "a=20
> > >>> payload-specific feedback  message", since only SPLI is=20
> > >>> "Assigned in this memo".
> > >>> Also, consider removing references to H.264 in the last=20
> > >>> paragraph of Section
> > >>> 8 since the memo is about HEVC.
> > >> [YK] Good catch again. Changed.
> > >>
> > >>> Section 8.1:
> > >>> Seems to me that "There MUST be exactly one RPSI contained in=20
> > >>> the FCI field" should be "There MUST be exactly one SPLI=20
> > >>> contained in the FCI field"
> > >> [YK] Another good catch. Changed.
> > >>
> > >>>
> > >>> Best Regards,
> > >>> Rickard Sj=F6berg
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]=20
> > >>> On Behalf Of Wang, Ye-Kui
> > >>> Sent: den 11 juni 2013 19:00
> > >>> To: payload@ietf.org
> > >>> Subject: [payload] Submission of new versions of H.265/HEVC=20
> > >>> payload format
> > >>>
> > >>> Dear All,
> > >>>
> > >>> We have just submitted versions 02 and 03 of=20
> > >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
> > >>>
> > >>> Version 02:
> > >>> URL:
> > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > >>> h265-02.txt
> > >>> Htmlized:
> > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > >>> Diff:
> > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> > >>> 02
> > >>>
> > >>> Version 03:
> > >>> URL:
> > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > >>> h265-03.txt
> > >>> Htmlized:
> > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > >>> Diff:
> > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
> > >>> 03
> > >>>
> > >>> Version 02 includes huge changes compared to the earlier=20
> > >>> submitted version 01. In a short summary, the authors have=20
> > >>> worked hard to try to make the design complete, from both the=20
> > >>> payload structure and the signaling points of view. Compared to=20
> > >>> version 02, version
> > >>> 03 only contains a correction of the email address of an author.
> > >>>
> > >>> Due to that the industry is eager to deploy H.265/HEVC and other=20
> > >>> standards bodies such as 3GPP rely on the payload format for=20
> > >>> support of H.265/HEVC in RTP based video services, we need to=20
> > >>> progress this draft relatively quickly.
> > >>> Therefore, we would like to request quick reviews from=20
> > >>> interested parties and also request for the WG status of this draft=
.
> > >>>
> > >>> BR, YK (on behalf of the authors)=20
> > >>> _______________________________________________
> > >>> payload mailing list
> > >>> payload@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/payload
> > >>>
> > >> _______________________________________________
> > >> payload mailing list
> > >> payload@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/payload
> > > _______________________________________________
> > > payload mailing list
> > > payload@ietf.org
> > > https://www.ietf.org/mailman/listinfo/payload
> >
> > _______________________________________________
> > 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

From yekuiw@qti.qualcomm.com  Thu Jul  4 08:34:37 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011921F9590 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 08:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.411
X-Spam-Level: 
X-Spam-Status: No, score=-103.411 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRl-p1vibDb2 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 08:34:32 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id A16DA11E812C for <payload@ietf.org>; Thu,  4 Jul 2013 08:34:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372952054; x=1404488054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=StBX0RFXP2arPZOCfN7c6Q1Hup1mSqqRw7BTvq7bW8Y=; b=DklRfsSUD2H5d8F4UZxLNyEkAZ19IOUuSufhLr0OR8FZgxzZWwawCUNK sGMZGC85S5wQedP6Zqpp/B8TRbYpEbo9v9vXGAzde8rJ0FJh+gtv3J/Hy B3aFVVYRDTi5hDGVCX6R7KU7Pi7eXn1vn7KtadrL9Vl4c02QflvA4G4zb A=;
X-IronPort-AV: E=Sophos;i="4.87,995,1363158000"; d="scan'208";a="46865367"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 04 Jul 2013 08:34:09 -0700
X-IronPort-AV: E=Sophos;i="4.87,995,1363158000"; d="scan'208";a="500095274"
Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jul 2013 08:34:09 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 08:34:09 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Thomas Davies (thdavies)" <thdavies@cisco.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHINrpiwi8/7UEygLhM2FJhH9ZlUBM9AgACmR4D///S3IA==
Date: Thu, 4 Jul 2013 15:34:08 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com>
In-Reply-To: <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 15:34:37 -0000

Hi Thomas,

My point was really about using dependent slices, not about 1 or N tiles pe=
r packets (sorry that I did not make that clearer). Whatever strategy you w=
ould like to do in terms of the number of tiles in a packet, using dependen=
t slices can do the same, as each dependent slice can include 1 or N tiles.

I see the following advantages with the approach using dependent slices ins=
tead of defining new FUs:

- First of all, no need to define new payload structures.

- The RTP packetizer does not need to parse slice headers to identify bound=
aries of tiles within a coded slice, as tiles of one SLICE are already in s=
eparate NAL units each containing a DEPENDENT SLICE.

- No additional overhead in packetization (the 1-byte FU header and the 2- =
or 4-byte FU offset). The overhead of the short slice header for dependent =
slice NAL units is compensated by less number of tile entry offsets signall=
ed, as the entry offset of the first tile in each NAL unit is not signalled=
 in the slice header. Using dependent slices would need more two-byte NAL u=
nit headers, while using new FUs would need more two-byte packet payload he=
aders, and the overhead bits here are the same for both methods.

Am I missing anything here?

BR, YK

> -----Original Message-----
> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> Sent: Thursday, July 04, 2013 1:49 AM
> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Wenger;
> Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Yes, we did think about one tile per packet or N tiles per packet, also: =
I guess
> that is where we started from. Then you could indeed align missing tiles =
with
> missing sequence numbers.
>=20
> The issue is that you need to guarantee that you are doing this for it to=
 be
> useful, and the decoder needs to know that this is guaranteed through som=
e
> form of other signalling. However, the bitstream chunk associated to a ti=
le is
> extremely variable, and many tile chunks would be very small. So there is
> significant packetization overhead for them if there is one tile per pack=
et.
>=20
> Having N>1 reduces this overhead, but it is still there and as N increase=
s you
> run the risk of breaking the MTU size which then requires that you have t=
o re-
> encode to fit things in and meet the guarantee. There is definitely no ti=
me to
> re-encode whole tiles, especially if you are already using them for
> parallelization. Thus you might have to break the guarantee and fragment =
the
> packet anyhow, losing the resilience.
>=20
> The advantage that we see with the proposal is that you can get fairly si=
milar
> resilience to regular slice MTU-size matching, but with much lower overhe=
ads
> as you can have a single regular slice header per frame, yet have a "dumb=
"
> packetization process and no need to re-encode to hit MTU targets. In H26=
4
> MTU matching usually means re-encoding just one or two 16x16 MBs. In H265
> it involves re-encoding at least one 64x64 CTB, and if you are doing tile=
s then
> you can get tiny "dangling slices" at the end of a tile, which means more=
 small
> packets.
>=20
> Best regards
>=20
> Thomas
>=20
> -----Original Message-----
> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> Sent: 04 July 2013 07:02
> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies); Ste=
phan
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
>=20
> An interesting idea. Using dependent slices (again :-) together with tile=
s would
> do the trick too (each tile in one dependent slice, and then each depende=
nt
> slice NAL unit in one single NAL unit packet).
>=20
> Have you guys done an analysis comparing the pros and cons of the two
> alternative approaches?
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > Sent: Wednesday, July 03, 2013 9:51 PM
> > To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan
> > Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Thomas, Paul and I have been working on improving packet loss
> > resilience using fragments and tiles. I mentioned this to Stephan at
> > IETF 86 in Orlando, and promised to have draft text ready before
> > Berlin. Here is the proposed text along with an overview of the rationa=
le.
> >
> > Rationale:
> >
> > 1. Resilience to packet loss requires independent slices or tiles.
> > Since independence requires restrictions on some coding tools, both
> > potentially incur slight penalties in coding efficiency, with a smaller=
 penalty
> for tiles.
> >
> > 2. Fragmentation in a higher layer like RTP can have several
> > advantages over similar features in a codec layer like slices (independ=
ent or
> dependent).
> > a. Efficiency: RTP fragmentation has finer (byte) granularity while
> > slices have much larger (CTB or tile) granularity. It also has less
> > slice segment header overhead, especially for independent slices. This
> > can impact the efficiency of the packetized stream in terms of both bit=
s and
> packets per second.
> > b. Performance: Encoders must perform extra processing to limit slice
> > sizes, which can impact encoder performance. Some implementations
> > speculatively end a slice based on computed statistics (which
> > aggravates a.), while others recode a slice if the size is exceeded (wh=
ich
> aggravates b.).
> > c. Decoupling: Not all encoders will support limiting slice size to MTU=
 size.
> > Applications (for live or stored content) using such encoders can
> > still support MTU limits using RTP fragmentation since it is decoupled =
from
> the encoder.
> > d. Multi-party: The encoded content may go to multiple receivers with
> > different MTUs. RTP fragmentation can handle this with lightweight
> > repacketization at middle boxes whereas slices incur heavyweight transc=
oding.
> >
> > 3. Combining fragmentation and tiles can improve resilience while
> > retaining the above advantages, if fragments are enhanced to contain
> > offsets (similar to IP fragmentation). This is described in the
> > proposed draft text below, which would immediately follow section 4.7
> Fragmentation Units.
> >
> > Draft Text:
> >
> > 4.7.1 Fragmentation Units with Fragment Offsets
> >
> > If a fragmented NAL unit contains tiles, its slice segment header
> > contains offsets to the data of each tile. These offsets can be used
> > for random access to any tile for parallel processing, region of
> > interest extraction, and resilience to errors in other tiles. These
> > offsets can also be used to provide resilience to packet loss, in
> > conjunction with fragment offsets contained in two types of fragmentati=
on
> units: FU-A2 and FU-A4.
> >
> > Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
> > the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
> > FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> > indicates the total number of bytes in all prior FU payloads of the fra=
gmented
> NAL unit.
> >
> >
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | FU-A2 offset  |     DONL (optional)           |               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
> >    |                                                               |
> >    |                         FU payload                            |
> >    |                                                               |
> >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                               :...OPTIONAL RTP padding        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                   Figure X   RTP payload format for FU-A2
> >
> >
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A4 offset                             | DONL(optional)|
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | DONL(optional)|                                               |
> >    +-+-+-+-+-+-+-+-+         FU payload                            |
> >    |                                                               |
> >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                               :...OPTIONAL RTP padding        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                   Figure Y   RTP payload format for FU-A4
> >
> >
> > Since the offset of the first FU payload of a fragmented NAL unit is
> > zero, and the Start (S) bit in the FU header is sufficient to indicate
> > this, the first fragmentation unit of a fragmented NAL unit SHOULD use
> > FU-A, but MAY use
> > FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation units
> > of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a non-zero
> > offset. The Start
> > (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> > contains a non- zero offset, and MUST be set if it contains a zero offs=
et.
> >
> > If a fragmentation unit is lost, tiles in the lost fragmentation unit a=
re also lost.
> > However, tiles which are successfully received in their entirety can
> > be decoded if their slice segment header containing tile offsets is
> > successfully received, despite lost fragmentation units. Fragment
> > offsets in FU-A2 or FU-A4 are required in order to recover from loss
> > of prior fragmentation units and continue decoding subsequent tiles.
> >
> > The following heuristic SHOULD be applied to determine if the lost
> > fragmentation units are all part of the same fragmented NAL unit as
> > subsequently received fragmentation units with identical RTP
> > timestamps and identical values of NAL unit header layer ID and tempora=
l ID.
> >
> > 1. Let N be the number of missing sequence numbers between two
> > received fragmentation units with known offsets.
> > 2. Let P be the FU payload size of the first of the two received FUs.
> > 3. Let D be the difference in the offsets, minus P.
> >    (This is the number of missing FU payload bytes.) 4. Let E be N time=
s P.
> >    (This is the estimated number of missing FU payload bytes.) 5. Let
> > ERROR be the absolute difference between D and E, divided by D.
> > 6. If ERROR < 50%, it is likely all FUs are part of the same
> > fragmented NAL unit, otherwise it is unlikely.
> >
> > Cheers,
> > Mo
> >
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > Behalf Of Rickard Sj=F6berg
> > Sent: Wednesday, July 03, 2013 3:38 PM
> > To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Dear all,
> >
> > I wrote slices and not dependent slices since the slice granularity
> > and slice/tile rule applies to both slices and dependent slices. Sorry
> > for the confusion. I will now use 'independent slices' and 'dependent
> > slices' to distinguish between them.
> >
> > I do not question the use of independent slices, I find them useful in
> > some applications.
> >
> > But the current RTP payload text says:
> >
> > "FUs SHOULD NOT be applied in live-encoding scenarios such as
> >       video telephony, video conferencing, live streaming and live
> >       broadcast, in which cases dependent slice segments SHOULD be used
> >       when a slice should be transported in multiple RTP packets."
> >
> > I believe that FUs are a viable option to dependent slices for the
> > reasons I listed in my previous e-mail and think that we should not
> > recommend dependent slices over FUs but leave it to the implementer.
> >
> > BR
> > Rickard
> >
> >
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > Behalf Of Wang, Ye-Kui
> > Sent: den 3 juli 2013 20:43
> > To: Thomas Davies; Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Hi All,
> >
> > I drafted an email replying directly to Rickard but did not finish and
> > there was a meeting (and then Stephan's and Thomas' emails came).
> >
> > I wanted to comment that Rickard was comparing the use of FUs vs
> > slices, not FUs vs dependent slices, while the recommendation in the
> > draft is recommending use of dependent slices over FUs in
> > live-encoding scenarios (so this answers Thomas question: the intention=
 was
> dependent slices ).
> >
> > In any case, it does not make much sense to try MTU size matching and
> > at the same time use either dependent slices or FUs, because dependent
> > slices and FUs should not be used when there are considerable packet
> > losses, while MTU size matching should be applied when there are
> considerable packet losses.
> >
> > For live encoding, whenever splitting of a regular slice is needed,
> > the splitting can be done by the encoder using dependent slices - and
> > the encoder has more knowledge and is more powerful than the RTP
> > packetizer and thus can do a better job for the splitting.
> >
> > BR, YK
> >
> >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > > Behalf Of Thomas Davies
> > > Sent: Wednesday, July 03, 2013 9:34 AM
> > > To: Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Hi Stephan
> > >
> > > I think I agree with Rickard.
> > >
> > > I think the text in question states a preference for _dependent_
> > > slice segments, which have no error resiliency advantage over FUs.
> > > Is this just a
> > typo?
> > >
> > > <snip>
> > >
> > > FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >        video telephony, video conferencing, live streaming and live
> > >        broadcast, in which cases dependent slice segments SHOULD be u=
sed
> > >        when a slice should be transported in multiple RTP packets.
> > >
> > >
> > >
> > > </snip>
> > >
> > > In general FUs may be used where error conditions are known to be
> > > benign, for greater efficiency, and also where for whatever reason
> > > the encoder cannot support MTU matching.
> > >
> > > We also are formulating some more general comments on this area
> > > which we hope to provide more fully soon.
> > >
> > > best regards
> > >
> > > Thomas
> > >
> > >
> > > On 03/07/13 17:22, Stephan Wenger wrote:
> > > > Hi Rickard,
> > > > Commenting only on slices vs. FUs.
> > > > The preference for slices over FUs, historically, was pushed by
> > > > myself into RFC 3984 for reasons of error resilience, and was
> > > > moved over to this draft for the same reason.  Loose a slice, and
> > > > you can recover at the next slice boundary; loose an FU, and you
> > > > have to wait for the next slice header and throw away all trailing
> > > > FUs.  RTP is in virtually all cases run over UDP, and in the
> > > > typical Internet scenario UDP is lossy (in contrast to private,
> > > > managed IP-network, which may have other constraints, but are not
> > > > the IETF's main
> > > > concern.) To set your remarks into context, let's first understand
> > > > what we are talking
> > > > about: the cost of slices is the overhead stemming from the
> > > > insertion of slice headers (in-picture syntax prediction) and from
> > > > the packet headers themselves.  And, of course, implementation
> > > > complexity, but we should not be in the business to encourage
> > > > implementor
> > laziness when
> > > > there would be a more complex, but better suited tool available.   =
 The
> > > > additional packetization overhead is only incurred when, as a
> > > > result of incompetently filled packets (which, I agree, is more
> > > > likely with
> > > > 64x64 CUs than with 16/16 macroblocks), an additional packet needs
> > > > to be inserted.  You may remember a quick analysis of mine we
> > > > discussed way back early in JCT, where we (I think) agreed that
> > > > the practical impact is negligible in almost all non-tile
> > > > scenarios (mostly because an additional overhead of 50 bytes or
> > > > so--3% or less of the coded picture size) is incurred
> > > > statistically only rarely (only in those cases where an additional
> > > > packet would need to be generated because of the video coding
> > > > related overhead for the use of slices).  The prediction overhead
> > > > of the use of regular slices has been shown to be substantial--the
> > > > price one needs to pay for independent decodability--but for
> > > > entropy slices that overhead virtually
> > does not exist.
> > > > With respect to tiles, I think you have a point though, especially
> > > > when considering the type of massive parallel implementations for
> > > > relatively small picture sizes some folks have been considering.
> > > > OTOH, because FUs are trivial to implement--some say in contrast
> > > > to slices--and because (I hope) we all agree that using FUs in
> > > > error prone scenarios is a bad idea if you could use slices (but
> > > > for reasons like the tile connection you mentioned), the draft
> > > > should IMO continue to set a preference for the use of regular
> > > > slices over FUs.  To avoid underperforming systems due to implement=
er
> laziness.
> > > > However, this is the IETF.  We don't have to worry about the
> > > > word-count of explanatory language.  In fact, explaining such
> > > > complex tradeoffs and relationships is generally encouraged here.
> > > > So let's
> > just do that:
> > > > express a preference of the use of regular slices (SHOULD) when
> > > > you expect losses and can use them (real-time encoding, no tiling
> > > > structure that would lead to unacceptable packetization overhead);
> > > > and suggest (MAY) the use of FUs in other scenarios.  Accompanied
> > > > by a more coherently expressed analysis.
> > > > Stephan
> > > >
> > > >
> > > > On 7.3.2013 06:46 , "Rickard
> > > > Sj=F6berg"<rickard.sjoberg@ericsson.com>
> > wrote:
> > > >
> > > >> Hi Ye-Kui,
> > > >>
> > > >> Thanks for your feedback on my comments, your suggestions look
> > > >> good to
> > > me.
> > > >>
> > > >> Regarding discouraging fragmentation units (FUs) for
> > > >> live-encoding scenarios in section 4.7, I think using FUs does
> > > >> make sense when you do not have many non-VLC NAL units for
> > > >> aggregation. The spatial granularity of slices was 16x16 pixels
> > > >> in H.264 but is typically
> > > >> 64x64 for HEVC which means that MTU size matching is done with
> > > >> units that are 16x larger. This may lead to a larger number of
> > > >> smaller packets when slices are used compared to FUs. In
> > > >> addition, there is the HEVC rule of slice and tile boundaries
> > > >> that makes the slice granularity equal to the tile granularity
> > > >> for cases when slices span multiple tiles. Finally, FUs are
> > > >> easier to implement since you do not need to care about when to
> > > >> break your slice to not exceed the MTU size limit. I think both
> > > >> slices and FUs has their merits and the choice between them for
> > > >> live-encoding should be left for
> > the implementer.
> > > >>
> > > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
> > > >> and the POC MSB sync issue, I agree that this is a corner case
> > > >> that we probably will not see much of in practice. I have no text
> > > >> change suggestion at the moment.
> > > >>
> > > >> BR
> > > >> Rickard
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > > >> Sent: den 24 juni 2013 01:00
> > > >> To: Rickard Sj=F6berg; payload@ietf.org
> > > >> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > >> format
> > > >>
> > > >> Hi Rickard,
> > > >>
> > > >> Thanks for the careful review and the comments. Please see inline =
below.
> > > >>
> > > >> BR, YK
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > > >>> To: Wang, Ye-Kui; payload@ietf.org
> > > >>> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > >>> format
> > > >>>
> > > >>> Dear all,
> > > >>>
> > > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03
> > > >>> and have some questions/comments.
> > > >>>
> > > >>> My first question is what extensions of HEVC that
> > > >>> draft-schierl-payload-rtp-
> > > >>> h265 is intended to cover? The draft mentions "future  scalable
> > > >>> or 3D  video coding  extensions  of  this  specification", what
> > > >>> extensions do you refer to?
> > > >>> Is the intent to cover the all HEVC extensions in a single
> > > >>> payload specification?
> > > >>>
> > > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> > > >> "this specification" should be replaced with "[HEVC]". It is sort
> > > >> of copy-and-paste error. Thanks for the good catching. No, there
> > > >> is no intention to cover HEVC extensions in this payload
> > > >> specification, though we intentionally to have the
> > > >> depacketization process and the use with feedback messages to
> > > >> work for HEVC scalability
> > and 3DV extensions.
> > > >>
> > > >>> Another question for my understanding is why "Receivers MUST
> > > >>> pass picture timing SEI messages and decoding unit information
> > > >>> SEI messages to the decoder"?
> > > >> [YK] Generally, RTP receivers should/must pass all NAL units
> > > >> specified by the video coding spec to the video decoders. This is
> > > >> emphasized here for the two timing related SEI messages after it
> > > >> is said that picture output timing in RTP timestamps should be
> > > >> used instead (to avoid giving a wrong impression to readers that
> > > >> the SEI messages should be ignored). If an RTP receiver discards
> > > >> the SEI messages, then HRD conformance checking for the bitstream
> > > >> that was possible would be disabled, and also the information
> > > >> related to frame
> > > doubling or tripping would be lost.
> > > >>
> > > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> > > >>> The fourth one does not seem to be a rule since there is no
> > > >>> "MUST" or "SHOULD" in the corresponding text.
> > > >> [YK] I see your point, it is only a "MAY" rule. An alternative to
> > > >> put this as a packetization rule is to put it as part of the
> > > >> semantics of NAL unit header (1.1.4), but that sub-section
> > > >> belongs to an overview wherein normative language (even "MAY")
> > > >> should not appear. One solution to this is to insert "Payload Head=
er
> Usage"
> > > >> after 4.1 "RTP Header Usage" and include at least this item there.
> > > >> I will do this in the next version unless there is a better sugges=
tion.
> > > >>
> > > >>> Further, the fifth one discourages using FUs, what are the
> > > >>> reasons behind that?
> > > >> [YK] The bullet item only discourages using FUs for live-encoding
> > > >> scenarios, wherein dependent slice segments should be used instead=
.
> > > >> This was added after a discussion (among the authors) on the need
> > > >> of whether to specify a payload structure for mixed FU and
> > > >> aggregation packets and
> > > > >from that discussion we concluded that encoding dependent slice
> > > > >segments
> > > >> at source coding level already allows for the use cases and using
> > > >> of FUs for live-encoding does not make sense. Please let us know
> > > >> if you think differently.
> > > >>
> > > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> > > >>> differ between the encoder and decoder?
> > > >> [YK] Good question. In theory this is indeed possible when random
> > > >> accessing to a bitstream is performed. However, it would not
> > > >> happen in conversational applications where the feedback messages =
may
> be used.
> > > >> Therefore, to me this would just work just fine. But please feel
> > > >> free to make other suggestions.
> > > >>
> > > >>> The use of spatial-segmentation-idc may need some updates to be
> > > >>> useful, let me come back to that later on.
> > > >>>
> > > >> [YK] OK. Look forward to seeing your input herein.
> > > >>
> > > >>> I have also a number of spelling suggestions for your considerati=
ons:
> > > >>>
> > > >>> Section 1.1:
> > > >>> Replace "community" by "communities"
> > > >> [YK] I guess both are OK. But anyway I just changed it per your
> > > >> suggestion (for the next version).
> > > >>
> > > >>> Section 1.1.1:
> > > >>> Replace "In addition, interpolation filter" by "In addition, the
> > > >>> interpolation filter"
> > > >> [YK] Thanks - done.
> > > >>
> > > >>> Replace "skipping the transform coding" by "skipping the transfor=
m"
> > > >>> (transform_skip_flag of HEVC skips the transform, not the
> > > >>> coding)
> > > >>>
> > > >> [YK] Done.
> > > >>
> > > >>> Section 1.1.2:
> > > >>> Replace:
> > > >>> "2) An indication of whether there is any parameter set within
> > > >>> the current coded video sequence that updates another parameter
> > > >>> set of the same type preceding in decoding order."
> > > >>> by:
> > > >>> "2) An indication of whether there is no parameter set update in
> > > >>> the coded video sequence."
> > > >>> since that is what no_parameter_set_update_flag in HEVC indicates=
.
> > > >>>
> > > >> [YK] Changed the wording to "An indication of whether there is no
> > > >> parameter set within the current coded video sequence that
> > > >> updates another parameter set of the same type preceding in decodi=
ng
> order."
> > > >>
> > > >>> Section 4.7:
> > > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> > > >>> and "FU
> > > >>> Type:  6 bits" to avoid confusion with the Type in the payload he=
ader.
> > > >>>
> > > >> [YK] Good point again. I will change the field name to be "FuType"=
.
> > > >>
> > > >>> Section 6:
> > > >>> Replace "recovery" by "recover"
> > > >> [YK] Done.
> > > >>
> > > >>> Section 7.1:
> > > >>> Replace "level-id" by "level-idc"
> > > >> [YK] We are consistently using "id" for profile-id, level-id,
> > > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> > > >>
> > > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > > >> [YK] Done.
> > > >>
> > > >>> Section 8:
> > > >>> Replace "two  payload-specific  feedback  messages" by "a
> > > >>> payload-specific feedback  message", since only SPLI is
> > > >>> "Assigned in this memo".
> > > >>> Also, consider removing references to H.264 in the last
> > > >>> paragraph of Section
> > > >>> 8 since the memo is about HEVC.
> > > >> [YK] Good catch again. Changed.
> > > >>
> > > >>> Section 8.1:
> > > >>> Seems to me that "There MUST be exactly one RPSI contained in
> > > >>> the FCI field" should be "There MUST be exactly one SPLI
> > > >>> contained in the FCI field"
> > > >> [YK] Another good catch. Changed.
> > > >>
> > > >>>
> > > >>> Best Regards,
> > > >>> Rickard Sj=F6berg
> > > >>>
> > > >>>
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> > > >>> On Behalf Of Wang, Ye-Kui
> > > >>> Sent: den 11 juni 2013 19:00
> > > >>> To: payload@ietf.org
> > > >>> Subject: [payload] Submission of new versions of H.265/HEVC
> > > >>> payload format
> > > >>>
> > > >>> Dear All,
> > > >>>
> > > >>> We have just submitted versions 02 and 03 of
> > > >>> draft-schierl-payload-rtp-h265, for which the links are as follow=
s:
> > > >>>
> > > >>> Version 02:
> > > >>> URL:
> > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > >>> h265-02.txt
> > > >>> Htmlized:
> > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > > >>> Diff:
> > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265=
-
> > > >>> 02
> > > >>>
> > > >>> Version 03:
> > > >>> URL:
> > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > >>> h265-03.txt
> > > >>> Htmlized:
> > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > > >>> Diff:
> > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265=
-
> > > >>> 03
> > > >>>
> > > >>> Version 02 includes huge changes compared to the earlier
> > > >>> submitted version 01. In a short summary, the authors have
> > > >>> worked hard to try to make the design complete, from both the
> > > >>> payload structure and the signaling points of view. Compared to
> > > >>> version 02, version
> > > >>> 03 only contains a correction of the email address of an author.
> > > >>>
> > > >>> Due to that the industry is eager to deploy H.265/HEVC and other
> > > >>> standards bodies such as 3GPP rely on the payload format for
> > > >>> support of H.265/HEVC in RTP based video services, we need to
> > > >>> progress this draft relatively quickly.
> > > >>> Therefore, we would like to request quick reviews from
> > > >>> interested parties and also request for the WG status of this dra=
ft.
> > > >>>
> > > >>> BR, YK (on behalf of the authors)
> > > >>> _______________________________________________
> > > >>> payload mailing list
> > > >>> payload@ietf.org
> > > >>> https://www.ietf.org/mailman/listinfo/payload
> > > >>>
> > > >> _______________________________________________
> > > >> payload mailing list
> > > >> payload@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/payload
> > > > _______________________________________________
> > > > payload mailing list
> > > > payload@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/payload
> > >
> > > _______________________________________________
> > > payload mailing list
> > > payload@ietf.org
> > > https://www.ietf.org/mailman/listinfo/payload
> > _______________________________________________
> > 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 yekuiw@qti.qualcomm.com  Thu Jul  4 08:55:10 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA911E8137 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 08:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.189
X-Spam-Level: 
X-Spam-Status: No, score=-105.189 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSnDl0mkDXv8 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 08:55:05 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28621F9FF8 for <payload@ietf.org>; Thu,  4 Jul 2013 08:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372953301; x=1404489301; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=myTfRqwwv0747qM2qzmBbUiXUdzVifBI35FWa/849N8=; b=gjdq5TueFObmcfaqhpaGLbRixPLUI3uAzhBhsEZnvRXptIV77aqPv++A Ou80vztFQwxUfjqSlYlmzNyV10qOCInaP0Sv9Jb0R75igyEXCrbgO5cY1 snUEvmTkFFP6zlUjVFxYfGed2OIpa3xAmL95j+5o/QWFiZECLEQtPRU72 A=;
X-IronPort-AV: E=Sophos;i="4.87,995,1363158000"; d="scan'208";a="60792085"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 04 Jul 2013 08:54:49 -0700
X-IronPort-AV: E=Sophos;i="4.87,995,1363158000"; d="scan'208";a="563111986"
Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jul 2013 08:54:49 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 08:54:49 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Thomas Davies (thdavies)" <thdavies@cisco.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: Ac54zluE8yZWKykCRXC3TXG+wl6phQ==
Date: Thu, 4 Jul 2013 15:54:48 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338459CE9@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 15:55:10 -0000

Of course, one advantage of the new-FU based approach is that it can be app=
lied to pre-encoded or stored content without the need of transcoding. Howe=
ver, the purpose here is for improved error resilience, which IMO is most r=
elevant for converstational applications like video telephony, video confer=
encing, and telepresence where content is real-time encoded.=20

BR, YK

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Wang, Ye-Kui
> Sent: Thursday, July 04, 2013 8:34 AM
> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; Ste=
phan
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> My point was really about using dependent slices, not about 1 or N tiles =
per
> packets (sorry that I did not make that clearer). Whatever strategy you w=
ould
> like to do in terms of the number of tiles in a packet, using dependent s=
lices can
> do the same, as each dependent slice can include 1 or N tiles.
>=20
> I see the following advantages with the approach using dependent slices
> instead of defining new FUs:
>=20
> - First of all, no need to define new payload structures.
>=20
> - The RTP packetizer does not need to parse slice headers to identify bou=
ndaries
> of tiles within a coded slice, as tiles of one SLICE are already in separ=
ate NAL
> units each containing a DEPENDENT SLICE.
>=20
> - No additional overhead in packetization (the 1-byte FU header and the 2=
- or
> 4-byte FU offset). The overhead of the short slice header for dependent s=
lice
> NAL units is compensated by less number of tile entry offsets signalled, =
as the
> entry offset of the first tile in each NAL unit is not signalled in the s=
lice header.
> Using dependent slices would need more two-byte NAL unit headers, while
> using new FUs would need more two-byte packet payload headers, and the
> overhead bits here are the same for both methods.
>=20
> Am I missing anything here?
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> > Sent: Thursday, July 04, 2013 1:49 AM
> > To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> > Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Yes, we did think about one tile per packet or N tiles per packet,
> > also: I guess that is where we started from. Then you could indeed
> > align missing tiles with missing sequence numbers.
> >
> > The issue is that you need to guarantee that you are doing this for it
> > to be useful, and the decoder needs to know that this is guaranteed
> > through some form of other signalling. However, the bitstream chunk
> > associated to a tile is extremely variable, and many tile chunks would
> > be very small. So there is significant packetization overhead for them =
if there
> is one tile per packet.
> >
> > Having N>1 reduces this overhead, but it is still there and as N
> > increases you run the risk of breaking the MTU size which then
> > requires that you have to re- encode to fit things in and meet the
> > guarantee. There is definitely no time to re-encode whole tiles,
> > especially if you are already using them for parallelization. Thus you
> > might have to break the guarantee and fragment the packet anyhow, losin=
g
> the resilience.
> >
> > The advantage that we see with the proposal is that you can get fairly
> > similar resilience to regular slice MTU-size matching, but with much
> > lower overheads as you can have a single regular slice header per frame=
, yet
> have a "dumb"
> > packetization process and no need to re-encode to hit MTU targets. In
> > H264 MTU matching usually means re-encoding just one or two 16x16 MBs.
> > In H265 it involves re-encoding at least one 64x64 CTB, and if you are
> > doing tiles then you can get tiny "dangling slices" at the end of a
> > tile, which means more small packets.
> >
> > Best regards
> >
> > Thomas
> >
> > -----Original Message-----
> > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > Sent: 04 July 2013 07:02
> > To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies);
> > Stephan Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> >
> > An interesting idea. Using dependent slices (again :-) together with
> > tiles would do the trick too (each tile in one dependent slice, and
> > then each dependent slice NAL unit in one single NAL unit packet).
> >
> > Have you guys done an analysis comparing the pros and cons of the two
> > alternative approaches?
> >
> > BR, YK
> >
> > > -----Original Message-----
> > > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > > Sent: Wednesday, July 03, 2013 9:51 PM
> > > To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stepha=
n
> > > Wenger; Paul Bright-Thomas (paubrigh)
> > > Cc: payload@ietf.org
> > > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Thomas, Paul and I have been working on improving packet loss
> > > resilience using fragments and tiles. I mentioned this to Stephan at
> > > IETF 86 in Orlando, and promised to have draft text ready before
> > > Berlin. Here is the proposed text along with an overview of the ratio=
nale.
> > >
> > > Rationale:
> > >
> > > 1. Resilience to packet loss requires independent slices or tiles.
> > > Since independence requires restrictions on some coding tools, both
> > > potentially incur slight penalties in coding efficiency, with a
> > > smaller penalty
> > for tiles.
> > >
> > > 2. Fragmentation in a higher layer like RTP can have several
> > > advantages over similar features in a codec layer like slices
> > > (independent or
> > dependent).
> > > a. Efficiency: RTP fragmentation has finer (byte) granularity while
> > > slices have much larger (CTB or tile) granularity. It also has less
> > > slice segment header overhead, especially for independent slices.
> > > This can impact the efficiency of the packetized stream in terms of
> > > both bits and
> > packets per second.
> > > b. Performance: Encoders must perform extra processing to limit
> > > slice sizes, which can impact encoder performance. Some
> > > implementations speculatively end a slice based on computed
> > > statistics (which aggravates a.), while others recode a slice if the
> > > size is exceeded (which
> > aggravates b.).
> > > c. Decoupling: Not all encoders will support limiting slice size to M=
TU size.
> > > Applications (for live or stored content) using such encoders can
> > > still support MTU limits using RTP fragmentation since it is
> > > decoupled from
> > the encoder.
> > > d. Multi-party: The encoded content may go to multiple receivers
> > > with different MTUs. RTP fragmentation can handle this with
> > > lightweight repacketization at middle boxes whereas slices incur
> heavyweight transcoding.
> > >
> > > 3. Combining fragmentation and tiles can improve resilience while
> > > retaining the above advantages, if fragments are enhanced to contain
> > > offsets (similar to IP fragmentation). This is described in the
> > > proposed draft text below, which would immediately follow section
> > > 4.7
> > Fragmentation Units.
> > >
> > > Draft Text:
> > >
> > > 4.7.1 Fragmentation Units with Fragment Offsets
> > >
> > > If a fragmented NAL unit contains tiles, its slice segment header
> > > contains offsets to the data of each tile. These offsets can be used
> > > for random access to any tile for parallel processing, region of
> > > interest extraction, and resilience to errors in other tiles. These
> > > offsets can also be used to provide resilience to packet loss, in
> > > conjunction with fragment offsets contained in two types of
> > > fragmentation
> > units: FU-A2 and FU-A4.
> > >
> > > Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
> > > the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
> > > FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> > > indicates the total number of bytes in all prior FU payloads of the
> > > fragmented
> > NAL unit.
> > >
> > >
> > >     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
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  =
|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | FU-A2 offset  |     DONL (optional)           |               |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
> > >    |                                                               |
> > >    |                         FU payload                            |
> > >    |                                                               |
> > >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                               :...OPTIONAL RTP padding        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >                   Figure X   RTP payload format for FU-A2
> > >
> > >
> > >     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
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  =
|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A4 offset                             | DONL(optional)|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | DONL(optional)|                                               |
> > >    +-+-+-+-+-+-+-+-+         FU payload                            |
> > >    |                                                               |
> > >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                               :...OPTIONAL RTP padding        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >                   Figure Y   RTP payload format for FU-A4
> > >
> > >
> > > Since the offset of the first FU payload of a fragmented NAL unit is
> > > zero, and the Start (S) bit in the FU header is sufficient to
> > > indicate this, the first fragmentation unit of a fragmented NAL unit
> > > SHOULD use FU-A, but MAY use
> > > FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
> > > units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
> > > non-zero offset. The Start
> > > (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> > > contains a non- zero offset, and MUST be set if it contains a zero of=
fset.
> > >
> > > If a fragmentation unit is lost, tiles in the lost fragmentation unit=
 are also
> lost.
> > > However, tiles which are successfully received in their entirety can
> > > be decoded if their slice segment header containing tile offsets is
> > > successfully received, despite lost fragmentation units. Fragment
> > > offsets in FU-A2 or FU-A4 are required in order to recover from loss
> > > of prior fragmentation units and continue decoding subsequent tiles.
> > >
> > > The following heuristic SHOULD be applied to determine if the lost
> > > fragmentation units are all part of the same fragmented NAL unit as
> > > subsequently received fragmentation units with identical RTP
> > > timestamps and identical values of NAL unit header layer ID and tempo=
ral
> ID.
> > >
> > > 1. Let N be the number of missing sequence numbers between two
> > > received fragmentation units with known offsets.
> > > 2. Let P be the FU payload size of the first of the two received FUs.
> > > 3. Let D be the difference in the offsets, minus P.
> > >    (This is the number of missing FU payload bytes.) 4. Let E be N ti=
mes P.
> > >    (This is the estimated number of missing FU payload bytes.) 5.
> > > Let ERROR be the absolute difference between D and E, divided by D.
> > > 6. If ERROR < 50%, it is likely all FUs are part of the same
> > > fragmented NAL unit, otherwise it is unlikely.
> > >
> > > Cheers,
> > > Mo
> > >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > > Behalf Of Rickard Sj=F6berg
> > > Sent: Wednesday, July 03, 2013 3:38 PM
> > > To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Dear all,
> > >
> > > I wrote slices and not dependent slices since the slice granularity
> > > and slice/tile rule applies to both slices and dependent slices.
> > > Sorry for the confusion. I will now use 'independent slices' and
> > > 'dependent slices' to distinguish between them.
> > >
> > > I do not question the use of independent slices, I find them useful
> > > in some applications.
> > >
> > > But the current RTP payload text says:
> > >
> > > "FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >       video telephony, video conferencing, live streaming and live
> > >       broadcast, in which cases dependent slice segments SHOULD be us=
ed
> > >       when a slice should be transported in multiple RTP packets."
> > >
> > > I believe that FUs are a viable option to dependent slices for the
> > > reasons I listed in my previous e-mail and think that we should not
> > > recommend dependent slices over FUs but leave it to the implementer.
> > >
> > > BR
> > > Rickard
> > >
> > >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > > Behalf Of Wang, Ye-Kui
> > > Sent: den 3 juli 2013 20:43
> > > To: Thomas Davies; Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Hi All,
> > >
> > > I drafted an email replying directly to Rickard but did not finish
> > > and there was a meeting (and then Stephan's and Thomas' emails came).
> > >
> > > I wanted to comment that Rickard was comparing the use of FUs vs
> > > slices, not FUs vs dependent slices, while the recommendation in the
> > > draft is recommending use of dependent slices over FUs in
> > > live-encoding scenarios (so this answers Thomas question: the
> > > intention was
> > dependent slices ).
> > >
> > > In any case, it does not make much sense to try MTU size matching
> > > and at the same time use either dependent slices or FUs, because
> > > dependent slices and FUs should not be used when there are
> > > considerable packet losses, while MTU size matching should be
> > > applied when there are
> > considerable packet losses.
> > >
> > > For live encoding, whenever splitting of a regular slice is needed,
> > > the splitting can be done by the encoder using dependent slices -
> > > and the encoder has more knowledge and is more powerful than the RTP
> > > packetizer and thus can do a better job for the splitting.
> > >
> > > BR, YK
> > >
> > >
> > > > -----Original Message-----
> > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> > > > On Behalf Of Thomas Davies
> > > > Sent: Wednesday, July 03, 2013 9:34 AM
> > > > To: Stephan Wenger
> > > > Cc: payload@ietf.org
> > > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > > payload format
> > > >
> > > > Hi Stephan
> > > >
> > > > I think I agree with Rickard.
> > > >
> > > > I think the text in question states a preference for _dependent_
> > > > slice segments, which have no error resiliency advantage over FUs.
> > > > Is this just a
> > > typo?
> > > >
> > > > <snip>
> > > >
> > > > FUs SHOULD NOT be applied in live-encoding scenarios such as
> > > >        video telephony, video conferencing, live streaming and live
> > > >        broadcast, in which cases dependent slice segments SHOULD be=
 used
> > > >        when a slice should be transported in multiple RTP packets.
> > > >
> > > >
> > > >
> > > > </snip>
> > > >
> > > > In general FUs may be used where error conditions are known to be
> > > > benign, for greater efficiency, and also where for whatever reason
> > > > the encoder cannot support MTU matching.
> > > >
> > > > We also are formulating some more general comments on this area
> > > > which we hope to provide more fully soon.
> > > >
> > > > best regards
> > > >
> > > > Thomas
> > > >
> > > >
> > > > On 03/07/13 17:22, Stephan Wenger wrote:
> > > > > Hi Rickard,
> > > > > Commenting only on slices vs. FUs.
> > > > > The preference for slices over FUs, historically, was pushed by
> > > > > myself into RFC 3984 for reasons of error resilience, and was
> > > > > moved over to this draft for the same reason.  Loose a slice,
> > > > > and you can recover at the next slice boundary; loose an FU, and
> > > > > you have to wait for the next slice header and throw away all
> > > > > trailing FUs.  RTP is in virtually all cases run over UDP, and
> > > > > in the typical Internet scenario UDP is lossy (in contrast to
> > > > > private, managed IP-network, which may have other constraints,
> > > > > but are not the IETF's main
> > > > > concern.) To set your remarks into context, let's first
> > > > > understand what we are talking
> > > > > about: the cost of slices is the overhead stemming from the
> > > > > insertion of slice headers (in-picture syntax prediction) and
> > > > > from the packet headers themselves.  And, of course,
> > > > > implementation complexity, but we should not be in the business
> > > > > to encourage implementor
> > > laziness when
> > > > > there would be a more complex, but better suited tool available. =
   The
> > > > > additional packetization overhead is only incurred when, as a
> > > > > result of incompetently filled packets (which, I agree, is more
> > > > > likely with
> > > > > 64x64 CUs than with 16/16 macroblocks), an additional packet
> > > > > needs to be inserted.  You may remember a quick analysis of mine
> > > > > we discussed way back early in JCT, where we (I think) agreed
> > > > > that the practical impact is negligible in almost all non-tile
> > > > > scenarios (mostly because an additional overhead of 50 bytes or
> > > > > so--3% or less of the coded picture size) is incurred
> > > > > statistically only rarely (only in those cases where an
> > > > > additional packet would need to be generated because of the
> > > > > video coding related overhead for the use of slices).  The
> > > > > prediction overhead of the use of regular slices has been shown
> > > > > to be substantial--the price one needs to pay for independent
> > > > > decodability--but for entropy slices that overhead virtually
> > > does not exist.
> > > > > With respect to tiles, I think you have a point though,
> > > > > especially when considering the type of massive parallel
> > > > > implementations for relatively small picture sizes some folks hav=
e been
> considering.
> > > > > OTOH, because FUs are trivial to implement--some say in contrast
> > > > > to slices--and because (I hope) we all agree that using FUs in
> > > > > error prone scenarios is a bad idea if you could use slices (but
> > > > > for reasons like the tile connection you mentioned), the draft
> > > > > should IMO continue to set a preference for the use of regular
> > > > > slices over FUs.  To avoid underperforming systems due to
> > > > > implementer
> > laziness.
> > > > > However, this is the IETF.  We don't have to worry about the
> > > > > word-count of explanatory language.  In fact, explaining such
> > > > > complex tradeoffs and relationships is generally encouraged here.
> > > > > So let's
> > > just do that:
> > > > > express a preference of the use of regular slices (SHOULD) when
> > > > > you expect losses and can use them (real-time encoding, no
> > > > > tiling structure that would lead to unacceptable packetization
> > > > > overhead); and suggest (MAY) the use of FUs in other scenarios.
> > > > > Accompanied by a more coherently expressed analysis.
> > > > > Stephan
> > > > >
> > > > >
> > > > > On 7.3.2013 06:46 , "Rickard
> > > > > Sj=F6berg"<rickard.sjoberg@ericsson.com>
> > > wrote:
> > > > >
> > > > >> Hi Ye-Kui,
> > > > >>
> > > > >> Thanks for your feedback on my comments, your suggestions look
> > > > >> good to
> > > > me.
> > > > >>
> > > > >> Regarding discouraging fragmentation units (FUs) for
> > > > >> live-encoding scenarios in section 4.7, I think using FUs does
> > > > >> make sense when you do not have many non-VLC NAL units for
> > > > >> aggregation. The spatial granularity of slices was 16x16 pixels
> > > > >> in H.264 but is typically
> > > > >> 64x64 for HEVC which means that MTU size matching is done with
> > > > >> units that are 16x larger. This may lead to a larger number of
> > > > >> smaller packets when slices are used compared to FUs. In
> > > > >> addition, there is the HEVC rule of slice and tile boundaries
> > > > >> that makes the slice granularity equal to the tile granularity
> > > > >> for cases when slices span multiple tiles. Finally, FUs are
> > > > >> easier to implement since you do not need to care about when to
> > > > >> break your slice to not exceed the MTU size limit. I think both
> > > > >> slices and FUs has their merits and the choice between them for
> > > > >> live-encoding should be left for
> > > the implementer.
> > > > >>
> > > > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
> > > > >> and the POC MSB sync issue, I agree that this is a corner case
> > > > >> that we probably will not see much of in practice. I have no
> > > > >> text change suggestion at the moment.
> > > > >>
> > > > >> BR
> > > > >> Rickard
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > > > >> Sent: den 24 juni 2013 01:00
> > > > >> To: Rickard Sj=F6berg; payload@ietf.org
> > > > >> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > > >> format
> > > > >>
> > > > >> Hi Rickard,
> > > > >>
> > > > >> Thanks for the careful review and the comments. Please see inlin=
e
> below.
> > > > >>
> > > > >> BR, YK
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > > > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > > > >>> To: Wang, Ye-Kui; payload@ietf.org
> > > > >>> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > > >>> format
> > > > >>>
> > > > >>> Dear all,
> > > > >>>
> > > > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03
> > > > >>> and have some questions/comments.
> > > > >>>
> > > > >>> My first question is what extensions of HEVC that
> > > > >>> draft-schierl-payload-rtp-
> > > > >>> h265 is intended to cover? The draft mentions "future
> > > > >>> scalable or 3D  video coding  extensions  of  this
> > > > >>> specification", what extensions do you refer to?
> > > > >>> Is the intent to cover the all HEVC extensions in a single
> > > > >>> payload specification?
> > > > >>>
> > > > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> > > > >> "this specification" should be replaced with "[HEVC]". It is
> > > > >> sort of copy-and-paste error. Thanks for the good catching. No,
> > > > >> there is no intention to cover HEVC extensions in this payload
> > > > >> specification, though we intentionally to have the
> > > > >> depacketization process and the use with feedback messages to
> > > > >> work for HEVC scalability
> > > and 3DV extensions.
> > > > >>
> > > > >>> Another question for my understanding is why "Receivers MUST
> > > > >>> pass picture timing SEI messages and decoding unit information
> > > > >>> SEI messages to the decoder"?
> > > > >> [YK] Generally, RTP receivers should/must pass all NAL units
> > > > >> specified by the video coding spec to the video decoders. This
> > > > >> is emphasized here for the two timing related SEI messages
> > > > >> after it is said that picture output timing in RTP timestamps
> > > > >> should be used instead (to avoid giving a wrong impression to
> > > > >> readers that the SEI messages should be ignored). If an RTP
> > > > >> receiver discards the SEI messages, then HRD conformance
> > > > >> checking for the bitstream that was possible would be disabled,
> > > > >> and also the information related to frame
> > > > doubling or tripping would be lost.
> > > > >>
> > > > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> > > > >>> The fourth one does not seem to be a rule since there is no
> > > > >>> "MUST" or "SHOULD" in the corresponding text.
> > > > >> [YK] I see your point, it is only a "MAY" rule. An alternative
> > > > >> to put this as a packetization rule is to put it as part of the
> > > > >> semantics of NAL unit header (1.1.4), but that sub-section
> > > > >> belongs to an overview wherein normative language (even "MAY")
> > > > >> should not appear. One solution to this is to insert "Payload
> > > > >> Header
> > Usage"
> > > > >> after 4.1 "RTP Header Usage" and include at least this item ther=
e.
> > > > >> I will do this in the next version unless there is a better sugg=
estion.
> > > > >>
> > > > >>> Further, the fifth one discourages using FUs, what are the
> > > > >>> reasons behind that?
> > > > >> [YK] The bullet item only discourages using FUs for
> > > > >> live-encoding scenarios, wherein dependent slice segments should=
 be
> used instead.
> > > > >> This was added after a discussion (among the authors) on the
> > > > >> need of whether to specify a payload structure for mixed FU and
> > > > >> aggregation packets and
> > > > > >from that discussion we concluded that encoding dependent slice
> > > > > >segments
> > > > >> at source coding level already allows for the use cases and
> > > > >> using of FUs for live-encoding does not make sense. Please let
> > > > >> us know if you think differently.
> > > > >>
> > > > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > > > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> > > > >>> differ between the encoder and decoder?
> > > > >> [YK] Good question. In theory this is indeed possible when
> > > > >> random accessing to a bitstream is performed. However, it would
> > > > >> not happen in conversational applications where the feedback
> > > > >> messages may
> > be used.
> > > > >> Therefore, to me this would just work just fine. But please
> > > > >> feel free to make other suggestions.
> > > > >>
> > > > >>> The use of spatial-segmentation-idc may need some updates to
> > > > >>> be useful, let me come back to that later on.
> > > > >>>
> > > > >> [YK] OK. Look forward to seeing your input herein.
> > > > >>
> > > > >>> I have also a number of spelling suggestions for your considera=
tions:
> > > > >>>
> > > > >>> Section 1.1:
> > > > >>> Replace "community" by "communities"
> > > > >> [YK] I guess both are OK. But anyway I just changed it per your
> > > > >> suggestion (for the next version).
> > > > >>
> > > > >>> Section 1.1.1:
> > > > >>> Replace "In addition, interpolation filter" by "In addition,
> > > > >>> the interpolation filter"
> > > > >> [YK] Thanks - done.
> > > > >>
> > > > >>> Replace "skipping the transform coding" by "skipping the transf=
orm"
> > > > >>> (transform_skip_flag of HEVC skips the transform, not the
> > > > >>> coding)
> > > > >>>
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 1.1.2:
> > > > >>> Replace:
> > > > >>> "2) An indication of whether there is any parameter set within
> > > > >>> the current coded video sequence that updates another
> > > > >>> parameter set of the same type preceding in decoding order."
> > > > >>> by:
> > > > >>> "2) An indication of whether there is no parameter set update
> > > > >>> in the coded video sequence."
> > > > >>> since that is what no_parameter_set_update_flag in HEVC indicat=
es.
> > > > >>>
> > > > >> [YK] Changed the wording to "An indication of whether there is
> > > > >> no parameter set within the current coded video sequence that
> > > > >> updates another parameter set of the same type preceding in
> > > > >> decoding
> > order."
> > > > >>
> > > > >>> Section 4.7:
> > > > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> > > > >>> and "FU
> > > > >>> Type:  6 bits" to avoid confusion with the Type in the payload =
header.
> > > > >>>
> > > > >> [YK] Good point again. I will change the field name to be "FuTyp=
e".
> > > > >>
> > > > >>> Section 6:
> > > > >>> Replace "recovery" by "recover"
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 7.1:
> > > > >>> Replace "level-id" by "level-idc"
> > > > >> [YK] We are consistently using "id" for profile-id, level-id,
> > > > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc=
".
> > > > >>
> > > > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 8:
> > > > >>> Replace "two  payload-specific  feedback  messages" by "a
> > > > >>> payload-specific feedback  message", since only SPLI is
> > > > >>> "Assigned in this memo".
> > > > >>> Also, consider removing references to H.264 in the last
> > > > >>> paragraph of Section
> > > > >>> 8 since the memo is about HEVC.
> > > > >> [YK] Good catch again. Changed.
> > > > >>
> > > > >>> Section 8.1:
> > > > >>> Seems to me that "There MUST be exactly one RPSI contained in
> > > > >>> the FCI field" should be "There MUST be exactly one SPLI
> > > > >>> contained in the FCI field"
> > > > >> [YK] Another good catch. Changed.
> > > > >>
> > > > >>>
> > > > >>> Best Regards,
> > > > >>> Rickard Sj=F6berg
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: payload-bounces@ietf.org
> > > > >>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> > > > >>> Sent: den 11 juni 2013 19:00
> > > > >>> To: payload@ietf.org
> > > > >>> Subject: [payload] Submission of new versions of H.265/HEVC
> > > > >>> payload format
> > > > >>>
> > > > >>> Dear All,
> > > > >>>
> > > > >>> We have just submitted versions 02 and 03 of
> > > > >>> draft-schierl-payload-rtp-h265, for which the links are as foll=
ows:
> > > > >>>
> > > > >>> Version 02:
> > > > >>> URL:
> > > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > > >>> h265-02.txt
> > > > >>> Htmlized:
> > > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > > > >>> Diff:
> > > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h2=
6
> > > > >>> 5-
> > > > >>> 02
> > > > >>>
> > > > >>> Version 03:
> > > > >>> URL:
> > > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > > >>> h265-03.txt
> > > > >>> Htmlized:
> > > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > > > >>> Diff:
> > > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h2=
6
> > > > >>> 5-
> > > > >>> 03
> > > > >>>
> > > > >>> Version 02 includes huge changes compared to the earlier
> > > > >>> submitted version 01. In a short summary, the authors have
> > > > >>> worked hard to try to make the design complete, from both the
> > > > >>> payload structure and the signaling points of view. Compared
> > > > >>> to version 02, version
> > > > >>> 03 only contains a correction of the email address of an author=
.
> > > > >>>
> > > > >>> Due to that the industry is eager to deploy H.265/HEVC and
> > > > >>> other standards bodies such as 3GPP rely on the payload format
> > > > >>> for support of H.265/HEVC in RTP based video services, we need
> > > > >>> to progress this draft relatively quickly.
> > > > >>> Therefore, we would like to request quick reviews from
> > > > >>> interested parties and also request for the WG status of this d=
raft.
> > > > >>>
> > > > >>> BR, YK (on behalf of the authors)
> > > > >>> _______________________________________________
> > > > >>> payload mailing list
> > > > >>> payload@ietf.org
> > > > >>> https://www.ietf.org/mailman/listinfo/payload
> > > > >>>
> > > > >> _______________________________________________
> > > > >> payload mailing list
> > > > >> payload@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/payload
> > > > > _______________________________________________
> > > > > payload mailing list
> > > > > payload@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/payload
> > > >
> > > > _______________________________________________
> > > > payload mailing list
> > > > payload@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/payload
> > > _______________________________________________
> > > 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

From thdavies@cisco.com  Thu Jul  4 09:23:04 2013
Return-Path: <thdavies@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D443D21F9C8F for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 09:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhWctPsZX8Io for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 09:22:59 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F10CA11E813A for <payload@ietf.org>; Thu,  4 Jul 2013 09:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34017; q=dns/txt; s=iport; t=1372954978; x=1374164578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6bGITnHZhndtoDA+2EfawlOPnR6OHXsSzNG6tql/t7s=; b=PNnadU1hvCNtXDKSoN/7E7O7kZuH+dJrdZr+EW+SWaejFxYDN30q4ptc OXU47DtdcbfQB500EI4/HLD/DeW1NFqgR9zZJKBD9+kCJ6Ftbp8NyQyX7 c5EGYjcWOUDVJhj/WtXohKTnXsbggOE6o54k2pO+e1O9zH05Gf0wTlSCM I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAA2g1VGtJXHA/2dsb2JhbABQCoMJMkMGwD2BBRZ0giMBAQEDAQEBARcBUwQHDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIAQsHh24GBwW5RI4fCgEFBQWBATEHBoJ+aQOIa4sMhHuQHIMRgWkIFyA
X-IronPort-AV: E=Sophos;i="4.87,995,1363132800"; d="scan'208";a="231022102"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jul 2013 16:22:56 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r64GMuBQ013105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jul 2013 16:22:56 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 11:22:56 -0500
From: "Thomas Davies (thdavies)" <thdavies@cisco.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHIJbt9N9SGscUaRXY0b76N0A5lUWtqA///U2oCAAMsSAP//sSag
Date: Thu, 4 Jul 2013 16:22:55 +0000
Message-ID: <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.209.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 16:23:04 -0000

Hi Ye-Kui

Thank you for the clarification - I understand your point a bit better now.

With the proposed scheme there is no need for the RTP packetizer to parse s=
lice headers or identify tile boundaries. All it needs to do is to keep tra=
ck of the offset of the start of the payload to the beginning of the NALU a=
nd put this into the field. It needs to know this offset anyway. The packet=
izer is completely dumb.

The point is that a decoder wishing to do error resilience can parse the sl=
ice header and identify the tile boundaries in the case that a packet goes =
missing, for tiles that occur in the same frame but after the packet that i=
s lost. The decoder can compare the tile offsets with the FU offsets to wor=
k out what data is missing.
=20
Re dependent slices, there are indirect overheads as well, which come from =
having to quantize the packet size to a whole number of tiles, plus you hav=
e to manage the encoder to match the MTU size. The granularity of tiles you=
 need for your parallel processing may not match the granularity you need t=
o fit in the MTU very well.

Best regards

Thomas


-----Original Message-----
From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20
Sent: 04 July 2013 16:34
To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; Steph=
an Wenger; Paul Bright-Thomas (paubrigh)
Cc: payload@ietf.org
Subject: RE: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Hi Thomas,

My point was really about using dependent slices, not about 1 or N tiles pe=
r packets (sorry that I did not make that clearer). Whatever strategy you w=
ould like to do in terms of the number of tiles in a packet, using dependen=
t slices can do the same, as each dependent slice can include 1 or N tiles.

I see the following advantages with the approach using dependent slices ins=
tead of defining new FUs:

- First of all, no need to define new payload structures.

- The RTP packetizer does not need to parse slice headers to identify bound=
aries of tiles within a coded slice, as tiles of one SLICE are already in s=
eparate NAL units each containing a DEPENDENT SLICE.

- No additional overhead in packetization (the 1-byte FU header and the 2- =
or 4-byte FU offset). The overhead of the short slice header for dependent =
slice NAL units is compensated by less number of tile entry offsets signall=
ed, as the entry offset of the first tile in each NAL unit is not signalled=
 in the slice header. Using dependent slices would need more two-byte NAL u=
nit headers, while using new FUs would need more two-byte packet payload he=
aders, and the overhead bits here are the same for both methods.

Am I missing anything here?

BR, YK

> -----Original Message-----
> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> Sent: Thursday, July 04, 2013 1:49 AM
> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan=20
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
> Yes, we did think about one tile per packet or N tiles per packet,=20
> also: I guess that is where we started from. Then you could indeed=20
> align missing tiles with missing sequence numbers.
>=20
> The issue is that you need to guarantee that you are doing this for it=20
> to be useful, and the decoder needs to know that this is guaranteed=20
> through some form of other signalling. However, the bitstream chunk=20
> associated to a tile is extremely variable, and many tile chunks would=20
> be very small. So there is significant packetization overhead for them if=
 there is one tile per packet.
>=20
> Having N>1 reduces this overhead, but it is still there and as N=20
> increases you run the risk of breaking the MTU size which then=20
> requires that you have to re- encode to fit things in and meet the=20
> guarantee. There is definitely no time to re-encode whole tiles,=20
> especially if you are already using them for parallelization. Thus you=20
> might have to break the guarantee and fragment the packet anyhow, losing =
the resilience.
>=20
> The advantage that we see with the proposal is that you can get fairly=20
> similar resilience to regular slice MTU-size matching, but with much=20
> lower overheads as you can have a single regular slice header per frame, =
yet have a "dumb"
> packetization process and no need to re-encode to hit MTU targets. In=20
> H264 MTU matching usually means re-encoding just one or two 16x16 MBs.=20
> In H265 it involves re-encoding at least one 64x64 CTB, and if you are=20
> doing tiles then you can get tiny "dangling slices" at the end of a=20
> tile, which means more small packets.
>=20
> Best regards
>=20
> Thomas
>=20
> -----Original Message-----
> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> Sent: 04 July 2013 07:02
> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies);=20
> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC=20
> payload format
>=20
>=20
> An interesting idea. Using dependent slices (again :-) together with=20
> tiles would do the trick too (each tile in one dependent slice, and=20
> then each dependent slice NAL unit in one single NAL unit packet).
>=20
> Have you guys done an analysis comparing the pros and cons of the two=20
> alternative approaches?
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > Sent: Wednesday, July 03, 2013 9:51 PM
> > To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan=
=20
> > Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC=20
> > payload format
> >
> > Thomas, Paul and I have been working on improving packet loss=20
> > resilience using fragments and tiles. I mentioned this to Stephan at=20
> > IETF 86 in Orlando, and promised to have draft text ready before=20
> > Berlin. Here is the proposed text along with an overview of the rationa=
le.
> >
> > Rationale:
> >
> > 1. Resilience to packet loss requires independent slices or tiles.
> > Since independence requires restrictions on some coding tools, both=20
> > potentially incur slight penalties in coding efficiency, with a=20
> > smaller penalty
> for tiles.
> >
> > 2. Fragmentation in a higher layer like RTP can have several=20
> > advantages over similar features in a codec layer like slices=20
> > (independent or
> dependent).
> > a. Efficiency: RTP fragmentation has finer (byte) granularity while=20
> > slices have much larger (CTB or tile) granularity. It also has less=20
> > slice segment header overhead, especially for independent slices.=20
> > This can impact the efficiency of the packetized stream in terms of=20
> > both bits and
> packets per second.
> > b. Performance: Encoders must perform extra processing to limit=20
> > slice sizes, which can impact encoder performance. Some=20
> > implementations speculatively end a slice based on computed=20
> > statistics (which aggravates a.), while others recode a slice if the=20
> > size is exceeded (which
> aggravates b.).
> > c. Decoupling: Not all encoders will support limiting slice size to MTU=
 size.
> > Applications (for live or stored content) using such encoders can=20
> > still support MTU limits using RTP fragmentation since it is=20
> > decoupled from
> the encoder.
> > d. Multi-party: The encoded content may go to multiple receivers=20
> > with different MTUs. RTP fragmentation can handle this with=20
> > lightweight repacketization at middle boxes whereas slices incur heavyw=
eight transcoding.
> >
> > 3. Combining fragmentation and tiles can improve resilience while=20
> > retaining the above advantages, if fragments are enhanced to contain=20
> > offsets (similar to IP fragmentation). This is described in the=20
> > proposed draft text below, which would immediately follow section=20
> > 4.7
> Fragmentation Units.
> >
> > Draft Text:
> >
> > 4.7.1 Fragmentation Units with Fragment Offsets
> >
> > If a fragmented NAL unit contains tiles, its slice segment header=20
> > contains offsets to the data of each tile. These offsets can be used=20
> > for random access to any tile for parallel processing, region of=20
> > interest extraction, and resilience to errors in other tiles. These=20
> > offsets can also be used to provide resilience to packet loss, in=20
> > conjunction with fragment offsets contained in two types of=20
> > fragmentation
> units: FU-A2 and FU-A4.
> >
> > Fragmentation units FU-A2 and FU-A4 contain a fragment offset before=20
> > the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
> > FU-A4 contains a 4-byte offset as shown in Figure Y. The offset=20
> > indicates the total number of bytes in all prior FU payloads of the=20
> > fragmented
> NAL unit.
> >
> >
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | FU-A2 offset  |     DONL (optional)           |               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
> >    |                                                               |
> >    |                         FU payload                            |
> >    |                                                               |
> >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                               :...OPTIONAL RTP padding        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                   Figure X   RTP payload format for FU-A2
> >
> >
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      FU-A4 offset                             | DONL(optional)|
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | DONL(optional)|                                               |
> >    +-+-+-+-+-+-+-+-+         FU payload                            |
> >    |                                                               |
> >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                               :...OPTIONAL RTP padding        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                   Figure Y   RTP payload format for FU-A4
> >
> >
> > Since the offset of the first FU payload of a fragmented NAL unit is=20
> > zero, and the Start (S) bit in the FU header is sufficient to=20
> > indicate this, the first fragmentation unit of a fragmented NAL unit=20
> > SHOULD use FU-A, but MAY use
> > FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation=20
> > units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a=20
> > non-zero offset. The Start
> > (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4=20
> > contains a non- zero offset, and MUST be set if it contains a zero offs=
et.
> >
> > If a fragmentation unit is lost, tiles in the lost fragmentation unit a=
re also lost.
> > However, tiles which are successfully received in their entirety can=20
> > be decoded if their slice segment header containing tile offsets is=20
> > successfully received, despite lost fragmentation units. Fragment=20
> > offsets in FU-A2 or FU-A4 are required in order to recover from loss=20
> > of prior fragmentation units and continue decoding subsequent tiles.
> >
> > The following heuristic SHOULD be applied to determine if the lost=20
> > fragmentation units are all part of the same fragmented NAL unit as=20
> > subsequently received fragmentation units with identical RTP=20
> > timestamps and identical values of NAL unit header layer ID and tempora=
l ID.
> >
> > 1. Let N be the number of missing sequence numbers between two=20
> > received fragmentation units with known offsets.
> > 2. Let P be the FU payload size of the first of the two received FUs.
> > 3. Let D be the difference in the offsets, minus P.
> >    (This is the number of missing FU payload bytes.) 4. Let E be N time=
s P.
> >    (This is the estimated number of missing FU payload bytes.) 5.=20
> > Let ERROR be the absolute difference between D and E, divided by D.
> > 6. If ERROR < 50%, it is likely all FUs are part of the same=20
> > fragmented NAL unit, otherwise it is unlikely.
> >
> > Cheers,
> > Mo
> >
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> > Behalf Of Rickard Sj=F6berg
> > Sent: Wednesday, July 03, 2013 3:38 PM
> > To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> > payload format
> >
> > Dear all,
> >
> > I wrote slices and not dependent slices since the slice granularity=20
> > and slice/tile rule applies to both slices and dependent slices.=20
> > Sorry for the confusion. I will now use 'independent slices' and=20
> > 'dependent slices' to distinguish between them.
> >
> > I do not question the use of independent slices, I find them useful=20
> > in some applications.
> >
> > But the current RTP payload text says:
> >
> > "FUs SHOULD NOT be applied in live-encoding scenarios such as
> >       video telephony, video conferencing, live streaming and live
> >       broadcast, in which cases dependent slice segments SHOULD be used
> >       when a slice should be transported in multiple RTP packets."
> >
> > I believe that FUs are a viable option to dependent slices for the=20
> > reasons I listed in my previous e-mail and think that we should not=20
> > recommend dependent slices over FUs but leave it to the implementer.
> >
> > BR
> > Rickard
> >
> >
> > -----Original Message-----
> > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20
> > Behalf Of Wang, Ye-Kui
> > Sent: den 3 juli 2013 20:43
> > To: Thomas Davies; Stephan Wenger
> > Cc: payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> > payload format
> >
> > Hi All,
> >
> > I drafted an email replying directly to Rickard but did not finish=20
> > and there was a meeting (and then Stephan's and Thomas' emails came).
> >
> > I wanted to comment that Rickard was comparing the use of FUs vs=20
> > slices, not FUs vs dependent slices, while the recommendation in the=20
> > draft is recommending use of dependent slices over FUs in=20
> > live-encoding scenarios (so this answers Thomas question: the=20
> > intention was
> dependent slices ).
> >
> > In any case, it does not make much sense to try MTU size matching=20
> > and at the same time use either dependent slices or FUs, because=20
> > dependent slices and FUs should not be used when there are=20
> > considerable packet losses, while MTU size matching should be=20
> > applied when there are
> considerable packet losses.
> >
> > For live encoding, whenever splitting of a regular slice is needed,=20
> > the splitting can be done by the encoder using dependent slices -=20
> > and the encoder has more knowledge and is more powerful than the RTP=20
> > packetizer and thus can do a better job for the splitting.
> >
> > BR, YK
> >
> >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]=20
> > > On Behalf Of Thomas Davies
> > > Sent: Wednesday, July 03, 2013 9:34 AM
> > > To: Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC=20
> > > payload format
> > >
> > > Hi Stephan
> > >
> > > I think I agree with Rickard.
> > >
> > > I think the text in question states a preference for _dependent_=20
> > > slice segments, which have no error resiliency advantage over FUs.
> > > Is this just a
> > typo?
> > >
> > > <snip>
> > >
> > > FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >        video telephony, video conferencing, live streaming and live
> > >        broadcast, in which cases dependent slice segments SHOULD be u=
sed
> > >        when a slice should be transported in multiple RTP packets.
> > >
> > >
> > >
> > > </snip>
> > >
> > > In general FUs may be used where error conditions are known to be=20
> > > benign, for greater efficiency, and also where for whatever reason=20
> > > the encoder cannot support MTU matching.
> > >
> > > We also are formulating some more general comments on this area=20
> > > which we hope to provide more fully soon.
> > >
> > > best regards
> > >
> > > Thomas
> > >
> > >
> > > On 03/07/13 17:22, Stephan Wenger wrote:
> > > > Hi Rickard,
> > > > Commenting only on slices vs. FUs.
> > > > The preference for slices over FUs, historically, was pushed by=20
> > > > myself into RFC 3984 for reasons of error resilience, and was=20
> > > > moved over to this draft for the same reason.  Loose a slice,=20
> > > > and you can recover at the next slice boundary; loose an FU, and=20
> > > > you have to wait for the next slice header and throw away all=20
> > > > trailing FUs.  RTP is in virtually all cases run over UDP, and=20
> > > > in the typical Internet scenario UDP is lossy (in contrast to=20
> > > > private, managed IP-network, which may have other constraints,=20
> > > > but are not the IETF's main
> > > > concern.) To set your remarks into context, let's first=20
> > > > understand what we are talking
> > > > about: the cost of slices is the overhead stemming from the=20
> > > > insertion of slice headers (in-picture syntax prediction) and=20
> > > > from the packet headers themselves.  And, of course,=20
> > > > implementation complexity, but we should not be in the business=20
> > > > to encourage implementor
> > laziness when
> > > > there would be a more complex, but better suited tool available.   =
 The
> > > > additional packetization overhead is only incurred when, as a=20
> > > > result of incompetently filled packets (which, I agree, is more=20
> > > > likely with
> > > > 64x64 CUs than with 16/16 macroblocks), an additional packet=20
> > > > needs to be inserted.  You may remember a quick analysis of mine=20
> > > > we discussed way back early in JCT, where we (I think) agreed=20
> > > > that the practical impact is negligible in almost all non-tile=20
> > > > scenarios (mostly because an additional overhead of 50 bytes or=20
> > > > so--3% or less of the coded picture size) is incurred=20
> > > > statistically only rarely (only in those cases where an=20
> > > > additional packet would need to be generated because of the=20
> > > > video coding related overhead for the use of slices).  The=20
> > > > prediction overhead of the use of regular slices has been shown=20
> > > > to be substantial--the price one needs to pay for independent=20
> > > > decodability--but for entropy slices that overhead virtually
> > does not exist.
> > > > With respect to tiles, I think you have a point though,=20
> > > > especially when considering the type of massive parallel=20
> > > > implementations for relatively small picture sizes some folks have =
been considering.
> > > > OTOH, because FUs are trivial to implement--some say in contrast=20
> > > > to slices--and because (I hope) we all agree that using FUs in=20
> > > > error prone scenarios is a bad idea if you could use slices (but=20
> > > > for reasons like the tile connection you mentioned), the draft=20
> > > > should IMO continue to set a preference for the use of regular=20
> > > > slices over FUs.  To avoid underperforming systems due to=20
> > > > implementer
> laziness.
> > > > However, this is the IETF.  We don't have to worry about the=20
> > > > word-count of explanatory language.  In fact, explaining such=20
> > > > complex tradeoffs and relationships is generally encouraged here.
> > > > So let's
> > just do that:
> > > > express a preference of the use of regular slices (SHOULD) when=20
> > > > you expect losses and can use them (real-time encoding, no=20
> > > > tiling structure that would lead to unacceptable packetization=20
> > > > overhead); and suggest (MAY) the use of FUs in other scenarios. =20
> > > > Accompanied by a more coherently expressed analysis.
> > > > Stephan
> > > >
> > > >
> > > > On 7.3.2013 06:46 , "Rickard
> > > > Sj=F6berg"<rickard.sjoberg@ericsson.com>
> > wrote:
> > > >
> > > >> Hi Ye-Kui,
> > > >>
> > > >> Thanks for your feedback on my comments, your suggestions look=20
> > > >> good to
> > > me.
> > > >>
> > > >> Regarding discouraging fragmentation units (FUs) for=20
> > > >> live-encoding scenarios in section 4.7, I think using FUs does=20
> > > >> make sense when you do not have many non-VLC NAL units for=20
> > > >> aggregation. The spatial granularity of slices was 16x16 pixels=20
> > > >> in H.264 but is typically
> > > >> 64x64 for HEVC which means that MTU size matching is done with=20
> > > >> units that are 16x larger. This may lead to a larger number of=20
> > > >> smaller packets when slices are used compared to FUs. In=20
> > > >> addition, there is the HEVC rule of slice and tile boundaries=20
> > > >> that makes the slice granularity equal to the tile granularity=20
> > > >> for cases when slices span multiple tiles. Finally, FUs are=20
> > > >> easier to implement since you do not need to care about when to=20
> > > >> break your slice to not exceed the MTU size limit. I think both=20
> > > >> slices and FUs has their merits and the choice between them for=20
> > > >> live-encoding should be left for
> > the implementer.
> > > >>
> > > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2=20
> > > >> and the POC MSB sync issue, I agree that this is a corner case=20
> > > >> that we probably will not see much of in practice. I have no=20
> > > >> text change suggestion at the moment.
> > > >>
> > > >> BR
> > > >> Rickard
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > > >> Sent: den 24 juni 2013 01:00
> > > >> To: Rickard Sj=F6berg; payload@ietf.org
> > > >> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> > > >> format
> > > >>
> > > >> Hi Rickard,
> > > >>
> > > >> Thanks for the careful review and the comments. Please see inline =
below.
> > > >>
> > > >> BR, YK
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > > >>> To: Wang, Ye-Kui; payload@ietf.org
> > > >>> Subject: RE: Submission of new versions of H.265/HEVC payload=20
> > > >>> format
> > > >>>
> > > >>> Dear all,
> > > >>>
> > > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03=20
> > > >>> and have some questions/comments.
> > > >>>
> > > >>> My first question is what extensions of HEVC that
> > > >>> draft-schierl-payload-rtp-
> > > >>> h265 is intended to cover? The draft mentions "future =20
> > > >>> scalable or 3D  video coding  extensions  of  this =20
> > > >>> specification", what extensions do you refer to?
> > > >>> Is the intent to cover the all HEVC extensions in a single=20
> > > >>> payload specification?
> > > >>>
> > > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where=20
> > > >> "this specification" should be replaced with "[HEVC]". It is=20
> > > >> sort of copy-and-paste error. Thanks for the good catching. No,=20
> > > >> there is no intention to cover HEVC extensions in this payload=20
> > > >> specification, though we intentionally to have the=20
> > > >> depacketization process and the use with feedback messages to=20
> > > >> work for HEVC scalability
> > and 3DV extensions.
> > > >>
> > > >>> Another question for my understanding is why "Receivers MUST=20
> > > >>> pass picture timing SEI messages and decoding unit information=20
> > > >>> SEI messages to the decoder"?
> > > >> [YK] Generally, RTP receivers should/must pass all NAL units=20
> > > >> specified by the video coding spec to the video decoders. This=20
> > > >> is emphasized here for the two timing related SEI messages=20
> > > >> after it is said that picture output timing in RTP timestamps=20
> > > >> should be used instead (to avoid giving a wrong impression to=20
> > > >> readers that the SEI messages should be ignored). If an RTP=20
> > > >> receiver discards the SEI messages, then HRD conformance=20
> > > >> checking for the bitstream that was possible would be disabled,=20
> > > >> and also the information related to frame
> > > doubling or tripping would be lost.
> > > >>
> > > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> > > >>> The fourth one does not seem to be a rule since there is no=20
> > > >>> "MUST" or "SHOULD" in the corresponding text.
> > > >> [YK] I see your point, it is only a "MAY" rule. An alternative=20
> > > >> to put this as a packetization rule is to put it as part of the=20
> > > >> semantics of NAL unit header (1.1.4), but that sub-section=20
> > > >> belongs to an overview wherein normative language (even "MAY")=20
> > > >> should not appear. One solution to this is to insert "Payload=20
> > > >> Header
> Usage"
> > > >> after 4.1 "RTP Header Usage" and include at least this item there.
> > > >> I will do this in the next version unless there is a better sugges=
tion.
> > > >>
> > > >>> Further, the fifth one discourages using FUs, what are the=20
> > > >>> reasons behind that?
> > > >> [YK] The bullet item only discourages using FUs for=20
> > > >> live-encoding scenarios, wherein dependent slice segments should b=
e used instead.
> > > >> This was added after a discussion (among the authors) on the=20
> > > >> need of whether to specify a payload structure for mixed FU and=20
> > > >> aggregation packets and
> > > > >from that discussion we concluded that encoding dependent slice=20
> > > > >segments
> > > >> at source coding level already allows for the use cases and=20
> > > >> using of FUs for live-encoding does not make sense. Please let=20
> > > >> us know if you think differently.
> > > >>
> > > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may=20
> > > >>> differ between the encoder and decoder?
> > > >> [YK] Good question. In theory this is indeed possible when=20
> > > >> random accessing to a bitstream is performed. However, it would=20
> > > >> not happen in conversational applications where the feedback=20
> > > >> messages may
> be used.
> > > >> Therefore, to me this would just work just fine. But please=20
> > > >> feel free to make other suggestions.
> > > >>
> > > >>> The use of spatial-segmentation-idc may need some updates to=20
> > > >>> be useful, let me come back to that later on.
> > > >>>
> > > >> [YK] OK. Look forward to seeing your input herein.
> > > >>
> > > >>> I have also a number of spelling suggestions for your considerati=
ons:
> > > >>>
> > > >>> Section 1.1:
> > > >>> Replace "community" by "communities"
> > > >> [YK] I guess both are OK. But anyway I just changed it per your=20
> > > >> suggestion (for the next version).
> > > >>
> > > >>> Section 1.1.1:
> > > >>> Replace "In addition, interpolation filter" by "In addition,=20
> > > >>> the interpolation filter"
> > > >> [YK] Thanks - done.
> > > >>
> > > >>> Replace "skipping the transform coding" by "skipping the transfor=
m"
> > > >>> (transform_skip_flag of HEVC skips the transform, not the
> > > >>> coding)
> > > >>>
> > > >> [YK] Done.
> > > >>
> > > >>> Section 1.1.2:
> > > >>> Replace:
> > > >>> "2) An indication of whether there is any parameter set within=20
> > > >>> the current coded video sequence that updates another=20
> > > >>> parameter set of the same type preceding in decoding order."
> > > >>> by:
> > > >>> "2) An indication of whether there is no parameter set update=20
> > > >>> in the coded video sequence."
> > > >>> since that is what no_parameter_set_update_flag in HEVC indicates=
.
> > > >>>
> > > >> [YK] Changed the wording to "An indication of whether there is=20
> > > >> no parameter set within the current coded video sequence that=20
> > > >> updates another parameter set of the same type preceding in=20
> > > >> decoding
> order."
> > > >>
> > > >>> Section 4.7:
> > > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> > > >>> and "FU
> > > >>> Type:  6 bits" to avoid confusion with the Type in the payload he=
ader.
> > > >>>
> > > >> [YK] Good point again. I will change the field name to be "FuType"=
.
> > > >>
> > > >>> Section 6:
> > > >>> Replace "recovery" by "recover"
> > > >> [YK] Done.
> > > >>
> > > >>> Section 7.1:
> > > >>> Replace "level-id" by "level-idc"
> > > >> [YK] We are consistently using "id" for profile-id, level-id,=20
> > > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
> > > >>
> > > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > > >> [YK] Done.
> > > >>
> > > >>> Section 8:
> > > >>> Replace "two  payload-specific  feedback  messages" by "a=20
> > > >>> payload-specific feedback  message", since only SPLI is=20
> > > >>> "Assigned in this memo".
> > > >>> Also, consider removing references to H.264 in the last=20
> > > >>> paragraph of Section
> > > >>> 8 since the memo is about HEVC.
> > > >> [YK] Good catch again. Changed.
> > > >>
> > > >>> Section 8.1:
> > > >>> Seems to me that "There MUST be exactly one RPSI contained in=20
> > > >>> the FCI field" should be "There MUST be exactly one SPLI=20
> > > >>> contained in the FCI field"
> > > >> [YK] Another good catch. Changed.
> > > >>
> > > >>>
> > > >>> Best Regards,
> > > >>> Rickard Sj=F6berg
> > > >>>
> > > >>>
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: payload-bounces@ietf.org=20
> > > >>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> > > >>> Sent: den 11 juni 2013 19:00
> > > >>> To: payload@ietf.org
> > > >>> Subject: [payload] Submission of new versions of H.265/HEVC=20
> > > >>> payload format
> > > >>>
> > > >>> Dear All,
> > > >>>
> > > >>> We have just submitted versions 02 and 03 of=20
> > > >>> draft-schierl-payload-rtp-h265, for which the links are as follow=
s:
> > > >>>
> > > >>> Version 02:
> > > >>> URL:
> > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > >>> h265-02.txt
> > > >>> Htmlized:
> > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > > >>> Diff:
> > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
> > > >>> 5-
> > > >>> 02
> > > >>>
> > > >>> Version 03:
> > > >>> URL:
> > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > >>> h265-03.txt
> > > >>> Htmlized:
> > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > > >>> Diff:
> > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
> > > >>> 5-
> > > >>> 03
> > > >>>
> > > >>> Version 02 includes huge changes compared to the earlier=20
> > > >>> submitted version 01. In a short summary, the authors have=20
> > > >>> worked hard to try to make the design complete, from both the=20
> > > >>> payload structure and the signaling points of view. Compared=20
> > > >>> to version 02, version
> > > >>> 03 only contains a correction of the email address of an author.
> > > >>>
> > > >>> Due to that the industry is eager to deploy H.265/HEVC and=20
> > > >>> other standards bodies such as 3GPP rely on the payload format=20
> > > >>> for support of H.265/HEVC in RTP based video services, we need=20
> > > >>> to progress this draft relatively quickly.
> > > >>> Therefore, we would like to request quick reviews from=20
> > > >>> interested parties and also request for the WG status of this dra=
ft.
> > > >>>
> > > >>> BR, YK (on behalf of the authors)=20
> > > >>> _______________________________________________
> > > >>> payload mailing list
> > > >>> payload@ietf.org
> > > >>> https://www.ietf.org/mailman/listinfo/payload
> > > >>>
> > > >> _______________________________________________
> > > >> payload mailing list
> > > >> payload@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/payload
> > > > _______________________________________________
> > > > payload mailing list
> > > > payload@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/payload
> > >
> > > _______________________________________________
> > > 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

From mzanaty@cisco.com  Thu Jul  4 09:50:19 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDDC21F9AE2 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 09:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.962
X-Spam-Level: 
X-Spam-Status: No, score=-9.962 tagged_above=-999 required=5 tests=[AWL=0.638,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW6zdW8WKBI8 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 09:50:14 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ACD9121F9AEF for <payload@ietf.org>; Thu,  4 Jul 2013 09:50:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33789; q=dns/txt; s=iport; t=1372956613; x=1374166213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b5gIHyZdPvpcKxR+0XErAdtKRbONzcKp8bxiae9aeBs=; b=H5im4ieiRwyXd+kI2Tak6W12HK/vTCbKPmT12xpeq9McGzQ8WQnBQlNV wp2mAMCMG9xHEv+8wWY2gPr18fbou0WXhhNBLE3JZLhjkeKPxWWzKfcJd +L5CoeZMBxT9QJAzVmxGVD+P1zvtTRcDawISuBxAW2ELmvdd7WHpIdRWU w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAKWm1VGtJXG8/2dsb2JhbABQCoMJMkPAQ4EFFnSCIwEBAQQBAQEXAVMEBwwEAgEIEQQBAQEnBycLFAkIAQEEDgUJCweHdAcFuVCOHwoBBQUFfzMHBoJ+aQOIa4sMg1KBKZAcgxGBaQgX
X-IronPort-AV: E=Sophos;i="4.87,995,1363132800"; d="scan'208";a="231021553"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jul 2013 16:50:12 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r64GoCZu028024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jul 2013 16:50:12 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 11:50:11 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: Ac54zluEHZ27KnEH6UGWKhRFD5go/wACDDs8
Date: Thu, 4 Jul 2013 16:50:11 +0000
Message-ID: <6640A7D7-232F-48BE-8585-4726AECF1159@cisco.com>
References: <8BA7D4CEACFFE04BA2D902BF11719A8338459CE9@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338459CE9@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 16:50:19 -0000

Hi YK,

You are correct, tiles can indeed be used with dependent slices to improve =
resilience, which is already supported by the current draft. But you lose t=
he advantages of fragments described in 2 below. You are not missing anythi=
ng if you doubt or don't care about these advantages.

The proposal is for applications which care about the advantages of fragmen=
ts. Many (perhaps most) applications, including live encoding, use encoders=
 outside the application. For example, hardware accelerators or external so=
ftware components. These encoders don't always support limiting slice size =
to MTU size (2c), or it may lower performance (2b), or entail other restric=
tions. For example, I'm aware of very widely deployed H.264 silicon which c=
an't do CABAC when MTU matching, so apps must choose between mode 0 and HP.=
 And it took a long time for popular silicon and software libraries to even=
 support MTU matching at all. So even if you doubt any efficiency advantage=
s (2a), there are more reasons apps (including live encoding) may prefer fr=
agments over dependent slices. Hence the proposal to provide this option.

Cheers,
Mo


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

Of course, one advantage of the new-FU based approach is that it can be app=
lied to pre-encoded or stored content without the need of transcoding. Howe=
ver, the purpose here is for improved error resilience, which IMO is most r=
elevant for converstational applications like video telephony, video confer=
encing, and telepresence where content is real-time encoded.=20

BR, YK

> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal=
f
> Of Wang, Ye-Kui
> Sent: Thursday, July 04, 2013 8:34 AM
> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; Ste=
phan
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> My point was really about using dependent slices, not about 1 or N tiles =
per
> packets (sorry that I did not make that clearer). Whatever strategy you w=
ould
> like to do in terms of the number of tiles in a packet, using dependent s=
lices can
> do the same, as each dependent slice can include 1 or N tiles.
>=20
> I see the following advantages with the approach using dependent slices
> instead of defining new FUs:
>=20
> - First of all, no need to define new payload structures.
>=20
> - The RTP packetizer does not need to parse slice headers to identify bou=
ndaries
> of tiles within a coded slice, as tiles of one SLICE are already in separ=
ate NAL
> units each containing a DEPENDENT SLICE.
>=20
> - No additional overhead in packetization (the 1-byte FU header and the 2=
- or
> 4-byte FU offset). The overhead of the short slice header for dependent s=
lice
> NAL units is compensated by less number of tile entry offsets signalled, =
as the
> entry offset of the first tile in each NAL unit is not signalled in the s=
lice header.
> Using dependent slices would need more two-byte NAL unit headers, while
> using new FUs would need more two-byte packet payload headers, and the
> overhead bits here are the same for both methods.
>=20
> Am I missing anything here?
>=20
> BR, YK
>=20
>> -----Original Message-----
>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>> Sent: Thursday, July 04, 2013 1:49 AM
>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
>> Wenger; Paul Bright-Thomas (paubrigh)
>> Cc: payload@ietf.org
>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>> payload format
>>=20
>> Yes, we did think about one tile per packet or N tiles per packet,
>> also: I guess that is where we started from. Then you could indeed
>> align missing tiles with missing sequence numbers.
>>=20
>> The issue is that you need to guarantee that you are doing this for it
>> to be useful, and the decoder needs to know that this is guaranteed
>> through some form of other signalling. However, the bitstream chunk
>> associated to a tile is extremely variable, and many tile chunks would
>> be very small. So there is significant packetization overhead for them i=
f there
> is one tile per packet.
>>=20
>> Having N>1 reduces this overhead, but it is still there and as N
>> increases you run the risk of breaking the MTU size which then
>> requires that you have to re- encode to fit things in and meet the
>> guarantee. There is definitely no time to re-encode whole tiles,
>> especially if you are already using them for parallelization. Thus you
>> might have to break the guarantee and fragment the packet anyhow, losing
> the resilience.
>>=20
>> The advantage that we see with the proposal is that you can get fairly
>> similar resilience to regular slice MTU-size matching, but with much
>> lower overheads as you can have a single regular slice header per frame,=
 yet
> have a "dumb"
>> packetization process and no need to re-encode to hit MTU targets. In
>> H264 MTU matching usually means re-encoding just one or two 16x16 MBs.
>> In H265 it involves re-encoding at least one 64x64 CTB, and if you are
>> doing tiles then you can get tiny "dangling slices" at the end of a
>> tile, which means more small packets.
>>=20
>> Best regards
>>=20
>> Thomas
>>=20
>> -----Original Message-----
>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>> Sent: 04 July 2013 07:02
>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies);
>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>> Cc: payload@ietf.org
>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>> payload format
>>=20
>>=20
>> An interesting idea. Using dependent slices (again :-) together with
>> tiles would do the trick too (each tile in one dependent slice, and
>> then each dependent slice NAL unit in one single NAL unit packet).
>>=20
>> Have you guys done an analysis comparing the pros and cons of the two
>> alternative approaches?
>>=20
>> BR, YK
>>=20
>>> -----Original Message-----
>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan
>>> Wenger; Paul Bright-Thomas (paubrigh)
>>> Cc: payload@ietf.org
>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>> payload format
>>>=20
>>> Thomas, Paul and I have been working on improving packet loss
>>> resilience using fragments and tiles. I mentioned this to Stephan at
>>> IETF 86 in Orlando, and promised to have draft text ready before
>>> Berlin. Here is the proposed text along with an overview of the rationa=
le.
>>>=20
>>> Rationale:
>>>=20
>>> 1. Resilience to packet loss requires independent slices or tiles.
>>> Since independence requires restrictions on some coding tools, both
>>> potentially incur slight penalties in coding efficiency, with a
>>> smaller penalty
>> for tiles.
>>>=20
>>> 2. Fragmentation in a higher layer like RTP can have several
>>> advantages over similar features in a codec layer like slices
>>> (independent or
>> dependent).
>>> a. Efficiency: RTP fragmentation has finer (byte) granularity while
>>> slices have much larger (CTB or tile) granularity. It also has less
>>> slice segment header overhead, especially for independent slices.
>>> This can impact the efficiency of the packetized stream in terms of
>>> both bits and
>> packets per second.
>>> b. Performance: Encoders must perform extra processing to limit
>>> slice sizes, which can impact encoder performance. Some
>>> implementations speculatively end a slice based on computed
>>> statistics (which aggravates a.), while others recode a slice if the
>>> size is exceeded (which
>> aggravates b.).
>>> c. Decoupling: Not all encoders will support limiting slice size to MTU=
 size.
>>> Applications (for live or stored content) using such encoders can
>>> still support MTU limits using RTP fragmentation since it is
>>> decoupled from
>> the encoder.
>>> d. Multi-party: The encoded content may go to multiple receivers
>>> with different MTUs. RTP fragmentation can handle this with
>>> lightweight repacketization at middle boxes whereas slices incur
> heavyweight transcoding.
>>>=20
>>> 3. Combining fragmentation and tiles can improve resilience while
>>> retaining the above advantages, if fragments are enhanced to contain
>>> offsets (similar to IP fragmentation). This is described in the
>>> proposed draft text below, which would immediately follow section
>>> 4.7
>> Fragmentation Units.
>>>=20
>>> Draft Text:
>>>=20
>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>=20
>>> If a fragmented NAL unit contains tiles, its slice segment header
>>> contains offsets to the data of each tile. These offsets can be used
>>> for random access to any tile for parallel processing, region of
>>> interest extraction, and resilience to errors in other tiles. These
>>> offsets can also be used to provide resilience to packet loss, in
>>> conjunction with fragment offsets contained in two types of
>>> fragmentation
>> units: FU-A2 and FU-A4.
>>>=20
>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
>>> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>> indicates the total number of bytes in all prior FU payloads of the
>>> fragmented
>> NAL unit.
>>>=20
>>>=20
>>>    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
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  |
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   | FU-A2 offset  |     DONL (optional)           |               |
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>   |                                                               |
>>>   |                         FU payload                            |
>>>   |                                                               |
>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |                               :...OPTIONAL RTP padding        |
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>=20
>>>                  Figure X   RTP payload format for FU-A2
>>>=20
>>>=20
>>>    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
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  |
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |      FU-A4 offset                             | DONL(optional)|
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   | DONL(optional)|                                               |
>>>   +-+-+-+-+-+-+-+-+         FU payload                            |
>>>   |                                                               |
>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>   |                               :...OPTIONAL RTP padding        |
>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>=20
>>>                  Figure Y   RTP payload format for FU-A4
>>>=20
>>>=20
>>> Since the offset of the first FU payload of a fragmented NAL unit is
>>> zero, and the Start (S) bit in the FU header is sufficient to
>>> indicate this, the first fragmentation unit of a fragmented NAL unit
>>> SHOULD use FU-A, but MAY use
>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>> non-zero offset. The Start
>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>> contains a non- zero offset, and MUST be set if it contains a zero offs=
et.
>>>=20
>>> If a fragmentation unit is lost, tiles in the lost fragmentation unit a=
re also
> lost.
>>> However, tiles which are successfully received in their entirety can
>>> be decoded if their slice segment header containing tile offsets is
>>> successfully received, despite lost fragmentation units. Fragment
>>> offsets in FU-A2 or FU-A4 are required in order to recover from loss
>>> of prior fragmentation units and continue decoding subsequent tiles.
>>>=20
>>> The following heuristic SHOULD be applied to determine if the lost
>>> fragmentation units are all part of the same fragmented NAL unit as
>>> subsequently received fragmentation units with identical RTP
>>> timestamps and identical values of NAL unit header layer ID and tempora=
l
> ID.
>>>=20
>>> 1. Let N be the number of missing sequence numbers between two
>>> received fragmentation units with known offsets.
>>> 2. Let P be the FU payload size of the first of the two received FUs.
>>> 3. Let D be the difference in the offsets, minus P.
>>>   (This is the number of missing FU payload bytes.) 4. Let E be N times=
 P.
>>>   (This is the estimated number of missing FU payload bytes.) 5.
>>> Let ERROR be the absolute difference between D and E, divided by D.
>>> 6. If ERROR < 50%, it is likely all FUs are part of the same
>>> fragmented NAL unit, otherwise it is unlikely.
>>>=20
>>> Cheers,
>>> Mo
>>>=20
>>> -----Original Message-----
>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>> Behalf Of Rickard Sj=F6berg
>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>> Cc: payload@ietf.org
>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>> payload format
>>>=20
>>> Dear all,
>>>=20
>>> I wrote slices and not dependent slices since the slice granularity
>>> and slice/tile rule applies to both slices and dependent slices.
>>> Sorry for the confusion. I will now use 'independent slices' and
>>> 'dependent slices' to distinguish between them.
>>>=20
>>> I do not question the use of independent slices, I find them useful
>>> in some applications.
>>>=20
>>> But the current RTP payload text says:
>>>=20
>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>      video telephony, video conferencing, live streaming and live
>>>      broadcast, in which cases dependent slice segments SHOULD be used
>>>      when a slice should be transported in multiple RTP packets."
>>>=20
>>> I believe that FUs are a viable option to dependent slices for the
>>> reasons I listed in my previous e-mail and think that we should not
>>> recommend dependent slices over FUs but leave it to the implementer.
>>>=20
>>> BR
>>> Rickard
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>> Behalf Of Wang, Ye-Kui
>>> Sent: den 3 juli 2013 20:43
>>> To: Thomas Davies; Stephan Wenger
>>> Cc: payload@ietf.org
>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>> payload format
>>>=20
>>> Hi All,
>>>=20
>>> I drafted an email replying directly to Rickard but did not finish
>>> and there was a meeting (and then Stephan's and Thomas' emails came).
>>>=20
>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>> slices, not FUs vs dependent slices, while the recommendation in the
>>> draft is recommending use of dependent slices over FUs in
>>> live-encoding scenarios (so this answers Thomas question: the
>>> intention was
>> dependent slices ).
>>>=20
>>> In any case, it does not make much sense to try MTU size matching
>>> and at the same time use either dependent slices or FUs, because
>>> dependent slices and FUs should not be used when there are
>>> considerable packet losses, while MTU size matching should be
>>> applied when there are
>> considerable packet losses.
>>>=20
>>> For live encoding, whenever splitting of a regular slice is needed,
>>> the splitting can be done by the encoder using dependent slices -
>>> and the encoder has more knowledge and is more powerful than the RTP
>>> packetizer and thus can do a better job for the splitting.
>>>=20
>>> BR, YK
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>> On Behalf Of Thomas Davies
>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>> To: Stephan Wenger
>>>> Cc: payload@ietf.org
>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>=20
>>>> Hi Stephan
>>>>=20
>>>> I think I agree with Rickard.
>>>>=20
>>>> I think the text in question states a preference for _dependent_
>>>> slice segments, which have no error resiliency advantage over FUs.
>>>> Is this just a
>>> typo?
>>>>=20
>>>> <snip>
>>>>=20
>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>       video telephony, video conferencing, live streaming and live
>>>>       broadcast, in which cases dependent slice segments SHOULD be use=
d
>>>>       when a slice should be transported in multiple RTP packets.
>>>>=20
>>>>=20
>>>>=20
>>>> </snip>
>>>>=20
>>>> In general FUs may be used where error conditions are known to be
>>>> benign, for greater efficiency, and also where for whatever reason
>>>> the encoder cannot support MTU matching.
>>>>=20
>>>> We also are formulating some more general comments on this area
>>>> which we hope to provide more fully soon.
>>>>=20
>>>> best regards
>>>>=20
>>>> Thomas
>>>>=20
>>>>=20
>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>> Hi Rickard,
>>>>> Commenting only on slices vs. FUs.
>>>>> The preference for slices over FUs, historically, was pushed by
>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>> and you can recover at the next slice boundary; loose an FU, and
>>>>> you have to wait for the next slice header and throw away all
>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>> private, managed IP-network, which may have other constraints,
>>>>> but are not the IETF's main
>>>>> concern.) To set your remarks into context, let's first
>>>>> understand what we are talking
>>>>> about: the cost of slices is the overhead stemming from the
>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>> from the packet headers themselves.  And, of course,
>>>>> implementation complexity, but we should not be in the business
>>>>> to encourage implementor
>>> laziness when
>>>>> there would be a more complex, but better suited tool available.    T=
he
>>>>> additional packetization overhead is only incurred when, as a
>>>>> result of incompetently filled packets (which, I agree, is more
>>>>> likely with
>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>> needs to be inserted.  You may remember a quick analysis of mine
>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>> that the practical impact is negligible in almost all non-tile
>>>>> scenarios (mostly because an additional overhead of 50 bytes or
>>>>> so--3% or less of the coded picture size) is incurred
>>>>> statistically only rarely (only in those cases where an
>>>>> additional packet would need to be generated because of the
>>>>> video coding related overhead for the use of slices).  The
>>>>> prediction overhead of the use of regular slices has been shown
>>>>> to be substantial--the price one needs to pay for independent
>>>>> decodability--but for entropy slices that overhead virtually
>>> does not exist.
>>>>> With respect to tiles, I think you have a point though,
>>>>> especially when considering the type of massive parallel
>>>>> implementations for relatively small picture sizes some folks have be=
en
> considering.
>>>>> OTOH, because FUs are trivial to implement--some say in contrast
>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>> error prone scenarios is a bad idea if you could use slices (but
>>>>> for reasons like the tile connection you mentioned), the draft
>>>>> should IMO continue to set a preference for the use of regular
>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>> implementer
>> laziness.
>>>>> However, this is the IETF.  We don't have to worry about the
>>>>> word-count of explanatory language.  In fact, explaining such
>>>>> complex tradeoffs and relationships is generally encouraged here.
>>>>> So let's
>>> just do that:
>>>>> express a preference of the use of regular slices (SHOULD) when
>>>>> you expect losses and can use them (real-time encoding, no
>>>>> tiling structure that would lead to unacceptable packetization
>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
>>>>> Accompanied by a more coherently expressed analysis.
>>>>> Stephan
>>>>>=20
>>>>>=20
>>>>> On 7.3.2013 06:46 , "Rickard
>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>> wrote:
>>>>>=20
>>>>>> Hi Ye-Kui,
>>>>>>=20
>>>>>> Thanks for your feedback on my comments, your suggestions look
>>>>>> good to
>>>> me.
>>>>>>=20
>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>> aggregation. The spatial granularity of slices was 16x16 pixels
>>>>>> in H.264 but is typically
>>>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>>>> units that are 16x larger. This may lead to a larger number of
>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>> that makes the slice granularity equal to the tile granularity
>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>> easier to implement since you do not need to care about when to
>>>>>> break your slice to not exceed the MTU size limit. I think both
>>>>>> slices and FUs has their merits and the choice between them for
>>>>>> live-encoding should be left for
>>> the implementer.
>>>>>>=20
>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
>>>>>> and the POC MSB sync issue, I agree that this is a corner case
>>>>>> that we probably will not see much of in practice. I have no
>>>>>> text change suggestion at the moment.
>>>>>>=20
>>>>>> BR
>>>>>> Rickard
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>> Sent: den 24 juni 2013 01:00
>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>> format
>>>>>>=20
>>>>>> Hi Rickard,
>>>>>>=20
>>>>>> Thanks for the careful review and the comments. Please see inline
> below.
>>>>>>=20
>>>>>> BR, YK
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>> format
>>>>>>>=20
>>>>>>> Dear all,
>>>>>>>=20
>>>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03
>>>>>>> and have some questions/comments.
>>>>>>>=20
>>>>>>> My first question is what extensions of HEVC that
>>>>>>> draft-schierl-payload-rtp-
>>>>>>> h265 is intended to cover? The draft mentions "future
>>>>>>> scalable or 3D  video coding  extensions  of  this
>>>>>>> specification", what extensions do you refer to?
>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>> payload specification?
>>>>>>>=20
>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>> sort of copy-and-paste error. Thanks for the good catching. No,
>>>>>> there is no intention to cover HEVC extensions in this payload
>>>>>> specification, though we intentionally to have the
>>>>>> depacketization process and the use with feedback messages to
>>>>>> work for HEVC scalability
>>> and 3DV extensions.
>>>>>>=20
>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>> pass picture timing SEI messages and decoding unit information
>>>>>>> SEI messages to the decoder"?
>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>> specified by the video coding spec to the video decoders. This
>>>>>> is emphasized here for the two timing related SEI messages
>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>> checking for the bitstream that was possible would be disabled,
>>>>>> and also the information related to frame
>>>> doubling or tripping would be lost.
>>>>>>=20
>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
>>>>>> to put this as a packetization rule is to put it as part of the
>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>> belongs to an overview wherein normative language (even "MAY")
>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>> Header
>> Usage"
>>>>>> after 4.1 "RTP Header Usage" and include at least this item there.
>>>>>> I will do this in the next version unless there is a better suggesti=
on.
>>>>>>=20
>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>> reasons behind that?
>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>> live-encoding scenarios, wherein dependent slice segments should be
> used instead.
>>>>>> This was added after a discussion (among the authors) on the
>>>>>> need of whether to specify a payload structure for mixed FU and
>>>>>> aggregation packets and
>>>>>> from that discussion we concluded that encoding dependent slice
>>>>>> segments
>>>>>> at source coding level already allows for the use cases and
>>>>>> using of FUs for live-encoding does not make sense. Please let
>>>>>> us know if you think differently.
>>>>>>=20
>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>> differ between the encoder and decoder?
>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>> random accessing to a bitstream is performed. However, it would
>>>>>> not happen in conversational applications where the feedback
>>>>>> messages may
>> be used.
>>>>>> Therefore, to me this would just work just fine. But please
>>>>>> feel free to make other suggestions.
>>>>>>=20
>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>> be useful, let me come back to that later on.
>>>>>>>=20
>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>=20
>>>>>>> I have also a number of spelling suggestions for your consideration=
s:
>>>>>>>=20
>>>>>>> Section 1.1:
>>>>>>> Replace "community" by "communities"
>>>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>>>> suggestion (for the next version).
>>>>>>=20
>>>>>>> Section 1.1.1:
>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>> the interpolation filter"
>>>>>> [YK] Thanks - done.
>>>>>>=20
>>>>>>> Replace "skipping the transform coding" by "skipping the transform"
>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>> coding)
>>>>>>>=20
>>>>>> [YK] Done.
>>>>>>=20
>>>>>>> Section 1.1.2:
>>>>>>> Replace:
>>>>>>> "2) An indication of whether there is any parameter set within
>>>>>>> the current coded video sequence that updates another
>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>> by:
>>>>>>> "2) An indication of whether there is no parameter set update
>>>>>>> in the coded video sequence."
>>>>>>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>>>>>>=20
>>>>>> [YK] Changed the wording to "An indication of whether there is
>>>>>> no parameter set within the current coded video sequence that
>>>>>> updates another parameter set of the same type preceding in
>>>>>> decoding
>> order."
>>>>>>=20
>>>>>>> Section 4.7:
>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
>>>>>>> and "FU
>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload head=
er.
>>>>>>>=20
>>>>>> [YK] Good point again. I will change the field name to be "FuType".
>>>>>>=20
>>>>>>> Section 6:
>>>>>>> Replace "recovery" by "recover"
>>>>>> [YK] Done.
>>>>>>=20
>>>>>>> Section 7.1:
>>>>>>> Replace "level-id" by "level-idc"
>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>>>>>>=20
>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>> [YK] Done.
>>>>>>=20
>>>>>>> Section 8:
>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>> "Assigned in this memo".
>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>> paragraph of Section
>>>>>>> 8 since the memo is about HEVC.
>>>>>> [YK] Good catch again. Changed.
>>>>>>=20
>>>>>>> Section 8.1:
>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>> contained in the FCI field"
>>>>>> [YK] Another good catch. Changed.
>>>>>>=20
>>>>>>>=20
>>>>>>> Best Regards,
>>>>>>> Rickard Sj=F6berg
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: payload-bounces@ietf.org
>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>> To: payload@ietf.org
>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Dear All,
>>>>>>>=20
>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>>>>>>=20
>>>>>>> Version 02:
>>>>>>> URL:
>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>> h265-02.txt
>>>>>>> Htmlized:
>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>> Diff:
>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>> 5-
>>>>>>> 02
>>>>>>>=20
>>>>>>> Version 03:
>>>>>>> URL:
>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>> h265-03.txt
>>>>>>> Htmlized:
>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>> Diff:
>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>> 5-
>>>>>>> 03
>>>>>>>=20
>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>> worked hard to try to make the design complete, from both the
>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>> to version 02, version
>>>>>>> 03 only contains a correction of the email address of an author.
>>>>>>>=20
>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>> other standards bodies such as 3GPP rely on the payload format
>>>>>>> for support of H.265/HEVC in RTP based video services, we need
>>>>>>> to progress this draft relatively quickly.
>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>> interested parties and also request for the WG status of this draft=
.
>>>>>>>=20
>>>>>>> BR, YK (on behalf of the authors)
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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

From stewe@stewe.org  Thu Jul  4 10:26:27 2013
Return-Path: <stewe@stewe.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8D721F9E58 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 10:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmOAceYTO4WN for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 10:26:22 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 29EE621F9D0A for <payload@ietf.org>; Thu,  4 Jul 2013 10:26:21 -0700 (PDT)
Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB190.namprd07.prod.outlook.com (10.242.167.139) with Microsoft SMTP Server (TLS) id 15.0.702.21; Thu, 4 Jul 2013 17:26:11 +0000
Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) with mapi id 15.00.0702.005; Thu, 4 Jul 2013 17:26:10 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?Windows-1252?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, "Thomas Davies (thdavies)" <thdavies@cisco.com>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: AQHOeNuTit/0OPl5LEeK8QZTeaGkMQ==
Date: Thu, 4 Jul 2013 17:26:10 +0000
Message-ID: <CDFAF888.9EDD0%stewe@stewe.org>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [71.202.147.60]
x-forefront-prvs: 08978A8F5C
x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(13464003)(53754006)(51914003)(377454003)(24454002)(479174003)(199002)(189002)(50986001)(76176001)(4396001)(16406001)(63696002)(74706001)(47976001)(54316002)(46102001)(81542001)(56776001)(59766001)(54356001)(53806001)(51856001)(69226001)(66066001)(83072001)(80022001)(77982001)(65816001)(47736001)(36756003)(76482001)(76786001)(49866001)(74366001)(74876001)(74662001)(81342001)(47446002)(74502001)(79102001)(77096001)(15202345003)(76796001)(31966008)(56816003)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB190; H:CO1PR07MB191.namprd07.prod.outlook.com; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <F9DA4C082ED71548A9871B045AD37AC9@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 17:26:27 -0000

Hi Mo,
A few comments about some of your arguments below.
Stephan

On 7.3.2013 21:50 , "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

>[=8A]
>
>2. Fragmentation in a higher layer like RTP can have several advantages
>over similar features in a codec layer like slices (independent or
>dependent).
>a. Efficiency: RTP fragmentation has finer (byte) granularity while
>slices have much larger (CTB or tile) granularity. It also has less slice
>segment header overhead, especially for independent slices. This can
>impact the efficiency of the packetized stream in terms of both bits and
>packets per second.

About this aspect I have had a lot of communication about with Rickard and
others.  The benefit one gets in terms of bits and packets per second is
negligible when comparing dependent slices and fragmentation (i.e. the
additional overhead stems from the finer granularity and the resulting
lower number of packets generated in certain corner cases).  I could walk
you through the math, but have to dig through old messages or recreate it.
 Obviously, when using independent slices, one gets the additional benefit
of error resilience, and pays for it through prediction penalty overhead.

>b. Performance: Encoders must perform extra processing to limit slice
>sizes, which can impact encoder performance. Some implementations
>speculatively end a slice based on computed statistics (which aggravates
>a.), while others recode a slice if the size is exceeded (which
>aggravates b.).

My main comment here is that it is entirely possible to design an encoder
which implements your option a) in a fairly reliable way; it's bread and
butter technology and has been for decades.  Let me also note that, in
option b) the re-encode only applies to the entropy coding, which is a
very small part of an H.265 encoder in terms of complexity in almost any
architecture, and certainly for the bitrates used in most RTP-based
systems.  Both can have have been used in practical systems with
competitive R-D performance.  To put things into perspective, we are
talking about what?  0.1% encoder cycle increase for option a?  Less?
=20


>c. Decoupling: Not all encoders will support limiting slice size to MTU
>size. Applications (for live or stored content) using such encoders can
>still support MTU limits using RTP fragmentation since it is decoupled
>from the encoder.

Yes, this is a fine argument.  At the first glance.  However: Those
decoupled, dumb encoders, which cannot even cope with trivially
implementable features involving static conditions (like MTU size
matching) are not likely to cope well with less static, and equally
disturbing features of IP network such as packet loss.  As certain
products in the video conferencing market can tell us :-)  And yes, those
systems cope with packet loss through FEC and whatnot, but that, I would
suggest, is a bolt-on to fix a broken system rather than a conscious,
organic, design choice that was from the outset based on the environment
the system is working in.

>d. Multi-party: The encoded content may go to multiple receivers with
>different MTUs. RTP fragmentation can handle this with lightweight
>repacketization at middle boxes whereas slices incur heavyweight
>transcoding.

No one argues against removing fragmentation as such, and this is one use
case where it makes sense.  Though, AFAIK, even that use case has lost
most of its relevance nowadays, where the 500 octet MTU size of 2G and
2.5G networks is a thing of the past, at least for video).
[...]
>
>-----Original Message-----
>From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>Behalf Of Rickard Sj=F6berg
>Sent: Wednesday, July 03, 2013 3:38 PM
>To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>Cc: payload@ietf.org
>Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
>format
>
>Dear all,
>
>I wrote slices and not dependent slices since the slice granularity and
>slice/tile rule applies to both slices and dependent slices. Sorry for
>the confusion. I will now use 'independent slices' and 'dependent slices'
>to distinguish between them.
>
>I do not question the use of independent slices, I find them useful in
>some applications.
>
>But the current RTP payload text says:
>
>"FUs SHOULD NOT be applied in live-encoding scenarios such as
>      video telephony, video conferencing, live streaming and live
>      broadcast, in which cases dependent slice segments SHOULD be used
>      when a slice should be transported in multiple RTP packets."
>
>I believe that FUs are a viable option to dependent slices for the
>reasons I listed in my previous e-mail and think that we should not
>recommend dependent slices over FUs but leave it to the implementer.
>
>BR
>Rickard
>
>
>-----Original Message-----
>From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>Behalf Of Wang, Ye-Kui
>Sent: den 3 juli 2013 20:43
>To: Thomas Davies; Stephan Wenger
>Cc: payload@ietf.org
>Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
>format
>
>Hi All,
>
>I drafted an email replying directly to Rickard but did not finish and
>there was a meeting (and then Stephan's and Thomas' emails came).
>
>I wanted to comment that Rickard was comparing the use of FUs vs slices,
>not FUs vs dependent slices, while the recommendation in the draft is
>recommending use of dependent slices over FUs in live-encoding scenarios
>(so this answers Thomas question: the intention was dependent slices ).
>
>In any case, it does not make much sense to try MTU size matching and at
>the same time use either dependent slices or FUs, because dependent
>slices and FUs should not be used when there are considerable packet
>losses, while MTU size matching should be applied when there are
>considerable packet losses.
>
>For live encoding, whenever splitting of a regular slice is needed, the
>splitting can be done by the encoder using dependent slices - and the
>encoder has more knowledge and is more powerful than the RTP packetizer
>and thus can do a better job for the splitting.
>
>BR, YK
>
>
>> -----Original Message-----
>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>> Behalf Of Thomas Davies
>> Sent: Wednesday, July 03, 2013 9:34 AM
>> To: Stephan Wenger
>> Cc: payload@ietf.org
>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>> payload format
>>=20
>> Hi Stephan
>>=20
>> I think I agree with Rickard.
>>=20
>> I think the text in question states a preference for _dependent_ slice
>> segments, which have no error resiliency advantage over FUs. Is this
>>just a typo?
>>=20
>> <snip>
>>=20
>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>        video telephony, video conferencing, live streaming and live
>>        broadcast, in which cases dependent slice segments SHOULD be used
>>        when a slice should be transported in multiple RTP packets.
>>=20
>>=20
>>=20
>> </snip>
>>=20
>> In general FUs may be used where error conditions are known to be
>> benign, for greater efficiency, and also where for whatever reason the
>> encoder cannot support MTU matching.
>>=20
>> We also are formulating some more general comments on this area which
>> we hope to provide more fully soon.
>>=20
>> best regards
>>=20
>> Thomas
>>=20
>>=20
>> On 03/07/13 17:22, Stephan Wenger wrote:
>> > Hi Rickard,
>> > Commenting only on slices vs. FUs.
>> > The preference for slices over FUs, historically, was pushed by
>> > myself into RFC 3984 for reasons of error resilience, and was moved
>> > over to this draft for the same reason.  Loose a slice, and you can
>> > recover at the next slice boundary; loose an FU, and you have to
>> > wait for the next slice header and throw away all trailing FUs.  RTP
>> > is in virtually all cases run over UDP, and in the typical Internet
>> > scenario UDP is lossy (in contrast to private, managed IP-network,
>> > which may have other constraints, but are not the IETF's main
>> > concern.) To set your remarks into context, let's first understand
>> > what we are talking
>> > about: the cost of slices is the overhead stemming from the
>> > insertion of slice headers (in-picture syntax prediction) and from
>> > the packet headers themselves.  And, of course, implementation
>> > complexity, but we should not be in the business to encourage
>>implementor laziness when
>> > there would be a more complex, but better suited tool available.
>>The
>> > additional packetization overhead is only incurred when, as a result
>> > of incompetently filled packets (which, I agree, is more likely with
>> > 64x64 CUs than with 16/16 macroblocks), an additional packet needs
>> > to be inserted.  You may remember a quick analysis of mine we
>> > discussed way back early in JCT, where we (I think) agreed that the
>> > practical impact is negligible in almost all non-tile scenarios
>> > (mostly because an additional overhead of 50 bytes or so--3% or less
>> > of the coded picture size) is incurred statistically only rarely
>> > (only in those cases where an additional packet would need to be
>> > generated because of the video coding related overhead for the use
>> > of slices).  The prediction overhead of the use of regular slices
>> > has been shown to be substantial--the price one needs to pay for
>> > independent decodability--but for entropy slices that overhead
>>virtually does not exist.
>> > With respect to tiles, I think you have a point though, especially
>> > when considering the type of massive parallel implementations for
>> > relatively small picture sizes some folks have been considering.
>> > OTOH, because FUs are trivial to implement--some say in contrast to
>> > slices--and because (I hope) we all agree that using FUs in error
>> > prone scenarios is a bad idea if you could use slices (but for
>> > reasons like the tile connection you mentioned), the draft should
>> > IMO continue to set a preference for the use of regular slices over
>> > FUs.  To avoid underperforming systems due to implementer laziness.
>> > However, this is the IETF.  We don't have to worry about the
>> > word-count of explanatory language.  In fact, explaining such
>> > complex tradeoffs and relationships is generally encouraged here.  So
>>let's just do that:
>> > express a preference of the use of regular slices (SHOULD) when you
>> > expect losses and can use them (real-time encoding, no tiling
>> > structure that would lead to unacceptable packetization overhead);
>> > and suggest (MAY) the use of FUs in other scenarios.  Accompanied by
>> > a more coherently expressed analysis.
>> > Stephan
>> >
>> >
>> > On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>wrote:
>> >
>> >> Hi Ye-Kui,
>> >>
>> >> Thanks for your feedback on my comments, your suggestions look good
>> >> to
>> me.
>> >>
>> >> Regarding discouraging fragmentation units (FUs) for live-encoding
>> >> scenarios in section 4.7, I think using FUs does make sense when
>> >> you do not have many non-VLC NAL units for aggregation. The spatial
>> >> granularity of slices was 16x16 pixels in H.264 but is typically
>> >> 64x64 for HEVC which means that MTU size matching is done with
>> >> units that are 16x larger. This may lead to a larger number of
>> >> smaller packets when slices are used compared to FUs. In addition,
>> >> there is the HEVC rule of slice and tile boundaries that makes the
>> >> slice granularity equal to the tile granularity for cases when
>> >> slices span multiple tiles. Finally, FUs are easier to implement
>> >> since you do not need to care about when to break your slice to not
>> >> exceed the MTU size limit. I think both slices and FUs has their
>> >> merits and the choice between them for live-encoding should be left
>>for the implementer.
>> >>
>> >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
>> >> the POC MSB sync issue, I agree that this is a corner case that we
>> >> probably will not see much of in practice. I have no text change
>> >> suggestion at the moment.
>> >>
>> >> BR
>> >> Rickard
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>> >> Sent: den 24 juni 2013 01:00
>> >> To: Rickard Sj=F6berg; payload@ietf.org
>> >> Subject: RE: Submission of new versions of H.265/HEVC payload
>> >> format
>> >>
>> >> Hi Rickard,
>> >>
>> >> Thanks for the careful review and the comments. Please see inline
>>below.
>> >>
>> >> BR, YK
>> >>
>> >>> -----Original Message-----
>> >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>> >>> Sent: Thursday, June 20, 2013 9:17 AM
>> >>> To: Wang, Ye-Kui; payload@ietf.org
>> >>> Subject: RE: Submission of new versions of H.265/HEVC payload
>> >>> format
>> >>>
>> >>> Dear all,
>> >>>
>> >>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
>> >>> have some questions/comments.
>> >>>
>> >>> My first question is what extensions of HEVC that
>> >>> draft-schierl-payload-rtp-
>> >>> h265 is intended to cover? The draft mentions "future  scalable
>> >>> or 3D  video coding  extensions  of  this  specification", what
>> >>> extensions do you refer to?
>> >>> Is the intent to cover the all HEVC extensions in a single payload
>> >>> specification?
>> >>>
>> >> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>> >> "this specification" should be replaced with "[HEVC]". It is sort
>> >> of copy-and-paste error. Thanks for the good catching. No, there is
>> >> no intention to cover HEVC extensions in this payload
>> >> specification, though we intentionally to have the depacketization
>> >> process and the use with feedback messages to work for HEVC
>>scalability and 3DV extensions.
>> >>
>> >>> Another question for my understanding is why "Receivers MUST pass
>> >>> picture timing SEI messages and decoding unit information SEI
>> >>> messages to the decoder"?
>> >> [YK] Generally, RTP receivers should/must pass all NAL units
>> >> specified by the video coding spec to the video decoders. This is
>> >> emphasized here for the two timing related SEI messages after it is
>> >> said that picture output timing in RTP timestamps should be used
>> >> instead (to avoid giving a wrong impression to readers that the SEI
>> >> messages should be ignored). If an RTP receiver discards the SEI
>> >> messages, then HRD conformance checking for the bitstream that was
>> >> possible would be disabled, and also the information related to
>> >> frame
>> doubling or tripping would be lost.
>> >>
>> >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
>> >>> fourth one does not seem to be a rule since there is no "MUST" or
>> >>> "SHOULD" in the corresponding text.
>> >> [YK] I see your point, it is only a "MAY" rule. An alternative to
>> >> put this as a packetization rule is to put it as part of the
>> >> semantics of NAL unit header (1.1.4), but that sub-section belongs
>> >> to an overview wherein normative language (even "MAY") should not
>> >> appear. One solution to this is to insert "Payload Header Usage"
>> >> after 4.1 "RTP Header Usage" and include at least this item there.
>> >> I will do this in the next version unless there is a better
>>suggestion.
>> >>
>> >>> Further, the fifth one discourages using FUs, what are the reasons
>> >>> behind that?
>> >> [YK] The bullet item only discourages using FUs for live-encoding
>> >> scenarios, wherein dependent slice segments should be used instead.
>> >> This was added after a discussion (among the authors) on the need
>> >> of whether to specify a payload structure for mixed FU and
>> >> aggregation packets and
>> > >from that discussion we concluded that encoding dependent slice
>> > >segments
>> >> at source coding level already allows for the use cases and using
>> >> of FUs for live-encoding does not make sense. Please let us know if
>> >> you think differently.
>> >>
>> >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>> >>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
>> >>> between the encoder and decoder?
>> >> [YK] Good question. In theory this is indeed possible when random
>> >> accessing to a bitstream is performed. However, it would not happen
>> >> in conversational applications where the feedback messages may be
>>used.
>> >> Therefore, to me this would just work just fine. But please feel
>> >> free to make other suggestions.
>> >>
>> >>> The use of spatial-segmentation-idc may need some updates to be
>> >>> useful, let me come back to that later on.
>> >>>
>> >> [YK] OK. Look forward to seeing your input herein.
>> >>
>> >>> I have also a number of spelling suggestions for your
>>considerations:
>> >>>
>> >>> Section 1.1:
>> >>> Replace "community" by "communities"
>> >> [YK] I guess both are OK. But anyway I just changed it per your
>> >> suggestion (for the next version).
>> >>
>> >>> Section 1.1.1:
>> >>> Replace "In addition, interpolation filter" by "In addition, the
>> >>> interpolation filter"
>> >> [YK] Thanks - done.
>> >>
>> >>> Replace "skipping the transform coding" by "skipping the transform"
>> >>> (transform_skip_flag of HEVC skips the transform, not the coding)
>> >>>
>> >> [YK] Done.
>> >>
>> >>> Section 1.1.2:
>> >>> Replace:
>> >>> "2) An indication of whether there is any parameter set within the
>> >>> current coded video sequence that updates another parameter set of
>> >>> the same type preceding in decoding order."
>> >>> by:
>> >>> "2) An indication of whether there is no parameter set update in
>> >>> the coded video sequence."
>> >>> since that is what no_parameter_set_update_flag in HEVC indicates.
>> >>>
>> >> [YK] Changed the wording to "An indication of whether there is no
>> >> parameter set within the current coded video sequence that updates
>> >> another parameter set of the same type preceding in decoding order."
>> >>
>> >>> Section 4.7:
>> >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
>> >>> "FU
>> >>> Type:  6 bits" to avoid confusion with the Type in the payload
>>header.
>> >>>
>> >> [YK] Good point again. I will change the field name to be "FuType".
>> >>
>> >>> Section 6:
>> >>> Replace "recovery" by "recover"
>> >> [YK] Done.
>> >>
>> >>> Section 7.1:
>> >>> Replace "level-id" by "level-idc"
>> >> [YK] We are consistently using "id" for profile-id, level-id,
>> >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>> >>
>> >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>> >> [YK] Done.
>> >>
>> >>> Section 8:
>> >>> Replace "two  payload-specific  feedback  messages" by "a
>> >>> payload-specific feedback  message", since only SPLI is "Assigned
>> >>> in this memo".
>> >>> Also, consider removing references to H.264 in the last paragraph
>> >>> of Section
>> >>> 8 since the memo is about HEVC.
>> >> [YK] Good catch again. Changed.
>> >>
>> >>> Section 8.1:
>> >>> Seems to me that "There MUST be exactly one RPSI contained in the
>> >>> FCI field" should be "There MUST be exactly one SPLI contained in
>> >>> the FCI field"
>> >> [YK] Another good catch. Changed.
>> >>
>> >>>
>> >>> Best Regards,
>> >>> Rickard Sj=F6berg
>> >>>
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>> >>> On Behalf Of Wang, Ye-Kui
>> >>> Sent: den 11 juni 2013 19:00
>> >>> To: payload@ietf.org
>> >>> Subject: [payload] Submission of new versions of H.265/HEVC
>> >>> payload format
>> >>>
>> >>> Dear All,
>> >>>
>> >>> We have just submitted versions 02 and 03 of
>> >>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>> >>>
>> >>> Version 02:
>> >>> URL:
>> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>> >>> h265-02.txt
>> >>> Htmlized:
>> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>> >>> Diff:
>> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>> >>> 02
>> >>>
>> >>> Version 03:
>> >>> URL:
>> >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>> >>> h265-03.txt
>> >>> Htmlized:
>> >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>> >>> Diff:
>> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>> >>> 03
>> >>>
>> >>> Version 02 includes huge changes compared to the earlier submitted
>> >>> version 01. In a short summary, the authors have worked hard to
>> >>> try to make the design complete, from both the payload structure
>> >>> and the signaling points of view. Compared to version 02, version
>> >>> 03 only contains a correction of the email address of an author.
>> >>>
>> >>> Due to that the industry is eager to deploy H.265/HEVC and other
>> >>> standards bodies such as 3GPP rely on the payload format for
>> >>> support of H.265/HEVC in RTP based video services, we need to
>> >>> progress this draft relatively quickly.
>> >>> Therefore, we would like to request quick reviews from interested
>> >>> parties and also request for the WG status of this draft.
>> >>>
>> >>> BR, YK (on behalf of the authors)
>> >>> _______________________________________________
>> >>> payload mailing list
>> >>> payload@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/payload
>> >>>
>> >> _______________________________________________
>> >> 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
>> _______________________________________________
>> 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


From yekuiw@qti.qualcomm.com  Thu Jul  4 10:59:19 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A78821F957B for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 10:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.374
X-Spam-Level: 
X-Spam-Status: No, score=-105.374 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4EAhq8plqni for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 10:59:14 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4E21F9F30 for <payload@ietf.org>; Thu,  4 Jul 2013 10:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372960754; x=1404496754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XgElmxgVgwGYxcchJGkzHb86fO1EhvWSJY591+MHG1s=; b=axnLZJfqOL0RkadcvmigXNldYY7B6gCdxXu4dketIkU3+IHPADv/xmjU cCNcTWKELEJlD5C3ZaQ0isMxpA4tfW8t7TCv8/Sr/qIsgNKOaz772ygNJ +p1OaAmWQNUHIVzIXfHiXzHEr7LuhPMXcyrrqir9/CpCRADG0Nf7SmS1b c=;
X-IronPort-AV: E=Sophos;i="4.87,996,1363158000"; d="scan'208";a="60721032"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 04 Jul 2013 10:59:14 -0700
X-IronPort-AV: E=Sophos;i="4.87,996,1363158000"; d="scan'208";a="500147659"
Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jul 2013 10:59:13 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 10:59:13 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Thomas Davies (thdavies)" <thdavies@cisco.com>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>, Stephan Wenger <stewe@stewe.org>, "Paul Bright-Thomas (paubrigh)" <paubrigh@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHINrpiwi8/7UEygLhM2FJhH9ZlUBM9AgACmR4D///S3IIAAiiGA//+fwlA=
Date: Thu, 4 Jul 2013 17:59:12 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com>
In-Reply-To: <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 17:59:19 -0000

Hi Thomas,

Thanks for the clarification - I think now understand your scheme better.

So you did not intent to encapsulate only entire tiles into packets, though=
 that would obviously be more error resilient as you won't encounter the pr=
oblem where a part of a tile gets lost and the received rest becomes useles=
s. Rather, one tile may be carried in two (or even more) packets.=20

I think I was confused by the suggested language such as "If a fragmentatio=
n unit is lost, tiles in the lost fragmentation unit are also lost. However=
, tiles which are successfully received in their entirety can be decoded if=
 their slice segment header containing tile offsets is successfully receive=
d, despite lost fragmentation units.", from where I got an impression that =
an FU includes entire tiles.

As seen from other discussions, it is very questionable how big a penalty w=
ould be when an encoder tries to splitting encoded data into separate NAL u=
nits (slices or dependent slices) for MTU size matching, even for large CTB=
 sizes - that's the reason why the JCT-VC later decided to remove the fine-=
granularity slice feature.

Let's tentatively assume that overall penalty and the overhead of the new-F=
U approach are roughly equivalent, and take into account latest comments fr=
om Mo and Stephan, do we see an advantage of the new-FU approach compared t=
o using dependent slices?

I am not trying to conclude yet - just try to (very briefly) summarize the =
situation so far at least for myself.  We should certainly have more discus=
sions - preferable involving more people who care about this payload format=
.

BR, YK

> -----Original Message-----
> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> Sent: Thursday, July 04, 2013 9:23 AM
> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Wenger;
> Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Ye-Kui
>=20
> Thank you for the clarification - I understand your point a bit better no=
w.
>=20
> With the proposed scheme there is no need for the RTP packetizer to parse
> slice headers or identify tile boundaries. All it needs to do is to keep =
track of the
> offset of the start of the payload to the beginning of the NALU and put t=
his into
> the field. It needs to know this offset anyway. The packetizer is complet=
ely
> dumb.
>=20
> The point is that a decoder wishing to do error resilience can parse the =
slice
> header and identify the tile boundaries in the case that a packet goes mi=
ssing,
> for tiles that occur in the same frame but after the packet that is lost.=
 The
> decoder can compare the tile offsets with the FU offsets to work out what=
 data
> is missing.
>=20
> Re dependent slices, there are indirect overheads as well, which come fro=
m
> having to quantize the packet size to a whole number of tiles, plus you h=
ave to
> manage the encoder to match the MTU size. The granularity of tiles you ne=
ed
> for your parallel processing may not match the granularity you need to fi=
t in
> the MTU very well.
>=20
> Best regards
>=20
> Thomas
>=20
>=20
> -----Original Message-----
> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> Sent: 04 July 2013 16:34
> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; Ste=
phan
> Wenger; Paul Bright-Thomas (paubrigh)
> Cc: payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> My point was really about using dependent slices, not about 1 or N tiles =
per
> packets (sorry that I did not make that clearer). Whatever strategy you w=
ould
> like to do in terms of the number of tiles in a packet, using dependent s=
lices can
> do the same, as each dependent slice can include 1 or N tiles.
>=20
> I see the following advantages with the approach using dependent slices
> instead of defining new FUs:
>=20
> - First of all, no need to define new payload structures.
>=20
> - The RTP packetizer does not need to parse slice headers to identify bou=
ndaries
> of tiles within a coded slice, as tiles of one SLICE are already in separ=
ate NAL
> units each containing a DEPENDENT SLICE.
>=20
> - No additional overhead in packetization (the 1-byte FU header and the 2=
- or
> 4-byte FU offset). The overhead of the short slice header for dependent s=
lice
> NAL units is compensated by less number of tile entry offsets signalled, =
as the
> entry offset of the first tile in each NAL unit is not signalled in the s=
lice header.
> Using dependent slices would need more two-byte NAL unit headers, while
> using new FUs would need more two-byte packet payload headers, and the
> overhead bits here are the same for both methods.
>=20
> Am I missing anything here?
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> > Sent: Thursday, July 04, 2013 1:49 AM
> > To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> > Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Yes, we did think about one tile per packet or N tiles per packet,
> > also: I guess that is where we started from. Then you could indeed
> > align missing tiles with missing sequence numbers.
> >
> > The issue is that you need to guarantee that you are doing this for it
> > to be useful, and the decoder needs to know that this is guaranteed
> > through some form of other signalling. However, the bitstream chunk
> > associated to a tile is extremely variable, and many tile chunks would
> > be very small. So there is significant packetization overhead for them =
if there
> is one tile per packet.
> >
> > Having N>1 reduces this overhead, but it is still there and as N
> > increases you run the risk of breaking the MTU size which then
> > requires that you have to re- encode to fit things in and meet the
> > guarantee. There is definitely no time to re-encode whole tiles,
> > especially if you are already using them for parallelization. Thus you
> > might have to break the guarantee and fragment the packet anyhow, losin=
g
> the resilience.
> >
> > The advantage that we see with the proposal is that you can get fairly
> > similar resilience to regular slice MTU-size matching, but with much
> > lower overheads as you can have a single regular slice header per frame=
, yet
> have a "dumb"
> > packetization process and no need to re-encode to hit MTU targets. In
> > H264 MTU matching usually means re-encoding just one or two 16x16 MBs.
> > In H265 it involves re-encoding at least one 64x64 CTB, and if you are
> > doing tiles then you can get tiny "dangling slices" at the end of a
> > tile, which means more small packets.
> >
> > Best regards
> >
> > Thomas
> >
> > -----Original Message-----
> > From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > Sent: 04 July 2013 07:02
> > To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies);
> > Stephan Wenger; Paul Bright-Thomas (paubrigh)
> > Cc: payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> >
> > An interesting idea. Using dependent slices (again :-) together with
> > tiles would do the trick too (each tile in one dependent slice, and
> > then each dependent slice NAL unit in one single NAL unit packet).
> >
> > Have you guys done an analysis comparing the pros and cons of the two
> > alternative approaches?
> >
> > BR, YK
> >
> > > -----Original Message-----
> > > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > > Sent: Wednesday, July 03, 2013 9:51 PM
> > > To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Stepha=
n
> > > Wenger; Paul Bright-Thomas (paubrigh)
> > > Cc: payload@ietf.org
> > > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Thomas, Paul and I have been working on improving packet loss
> > > resilience using fragments and tiles. I mentioned this to Stephan at
> > > IETF 86 in Orlando, and promised to have draft text ready before
> > > Berlin. Here is the proposed text along with an overview of the ratio=
nale.
> > >
> > > Rationale:
> > >
> > > 1. Resilience to packet loss requires independent slices or tiles.
> > > Since independence requires restrictions on some coding tools, both
> > > potentially incur slight penalties in coding efficiency, with a
> > > smaller penalty
> > for tiles.
> > >
> > > 2. Fragmentation in a higher layer like RTP can have several
> > > advantages over similar features in a codec layer like slices
> > > (independent or
> > dependent).
> > > a. Efficiency: RTP fragmentation has finer (byte) granularity while
> > > slices have much larger (CTB or tile) granularity. It also has less
> > > slice segment header overhead, especially for independent slices.
> > > This can impact the efficiency of the packetized stream in terms of
> > > both bits and
> > packets per second.
> > > b. Performance: Encoders must perform extra processing to limit
> > > slice sizes, which can impact encoder performance. Some
> > > implementations speculatively end a slice based on computed
> > > statistics (which aggravates a.), while others recode a slice if the
> > > size is exceeded (which
> > aggravates b.).
> > > c. Decoupling: Not all encoders will support limiting slice size to M=
TU size.
> > > Applications (for live or stored content) using such encoders can
> > > still support MTU limits using RTP fragmentation since it is
> > > decoupled from
> > the encoder.
> > > d. Multi-party: The encoded content may go to multiple receivers
> > > with different MTUs. RTP fragmentation can handle this with
> > > lightweight repacketization at middle boxes whereas slices incur
> heavyweight transcoding.
> > >
> > > 3. Combining fragmentation and tiles can improve resilience while
> > > retaining the above advantages, if fragments are enhanced to contain
> > > offsets (similar to IP fragmentation). This is described in the
> > > proposed draft text below, which would immediately follow section
> > > 4.7
> > Fragmentation Units.
> > >
> > > Draft Text:
> > >
> > > 4.7.1 Fragmentation Units with Fragment Offsets
> > >
> > > If a fragmented NAL unit contains tiles, its slice segment header
> > > contains offsets to the data of each tile. These offsets can be used
> > > for random access to any tile for parallel processing, region of
> > > interest extraction, and resilience to errors in other tiles. These
> > > offsets can also be used to provide resilience to packet loss, in
> > > conjunction with fragment offsets contained in two types of
> > > fragmentation
> > units: FU-A2 and FU-A4.
> > >
> > > Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
> > > the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
> > > FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> > > indicates the total number of bytes in all prior FU payloads of the
> > > fragmented
> > NAL unit.
> > >
> > >
> > >     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
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  =
|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | FU-A2 offset  |     DONL (optional)           |               |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
> > >    |                                                               |
> > >    |                         FU payload                            |
> > >    |                                                               |
> > >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                               :...OPTIONAL RTP padding        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >                   Figure X   RTP payload format for FU-A2
> > >
> > >
> > >     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
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  =
|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |      FU-A4 offset                             | DONL(optional)|
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    | DONL(optional)|                                               |
> > >    +-+-+-+-+-+-+-+-+         FU payload                            |
> > >    |                                                               |
> > >    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |                               :...OPTIONAL RTP padding        |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >                   Figure Y   RTP payload format for FU-A4
> > >
> > >
> > > Since the offset of the first FU payload of a fragmented NAL unit is
> > > zero, and the Start (S) bit in the FU header is sufficient to
> > > indicate this, the first fragmentation unit of a fragmented NAL unit
> > > SHOULD use FU-A, but MAY use
> > > FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
> > > units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
> > > non-zero offset. The Start
> > > (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> > > contains a non- zero offset, and MUST be set if it contains a zero of=
fset.
> > >
> > > If a fragmentation unit is lost, tiles in the lost fragmentation unit=
 are also
> lost.
> > > However, tiles which are successfully received in their entirety can
> > > be decoded if their slice segment header containing tile offsets is
> > > successfully received, despite lost fragmentation units. Fragment
> > > offsets in FU-A2 or FU-A4 are required in order to recover from loss
> > > of prior fragmentation units and continue decoding subsequent tiles.
> > >
> > > The following heuristic SHOULD be applied to determine if the lost
> > > fragmentation units are all part of the same fragmented NAL unit as
> > > subsequently received fragmentation units with identical RTP
> > > timestamps and identical values of NAL unit header layer ID and tempo=
ral
> ID.
> > >
> > > 1. Let N be the number of missing sequence numbers between two
> > > received fragmentation units with known offsets.
> > > 2. Let P be the FU payload size of the first of the two received FUs.
> > > 3. Let D be the difference in the offsets, minus P.
> > >    (This is the number of missing FU payload bytes.) 4. Let E be N ti=
mes P.
> > >    (This is the estimated number of missing FU payload bytes.) 5.
> > > Let ERROR be the absolute difference between D and E, divided by D.
> > > 6. If ERROR < 50%, it is likely all FUs are part of the same
> > > fragmented NAL unit, otherwise it is unlikely.
> > >
> > > Cheers,
> > > Mo
> > >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > > Behalf Of Rickard Sj=F6berg
> > > Sent: Wednesday, July 03, 2013 3:38 PM
> > > To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Dear all,
> > >
> > > I wrote slices and not dependent slices since the slice granularity
> > > and slice/tile rule applies to both slices and dependent slices.
> > > Sorry for the confusion. I will now use 'independent slices' and
> > > 'dependent slices' to distinguish between them.
> > >
> > > I do not question the use of independent slices, I find them useful
> > > in some applications.
> > >
> > > But the current RTP payload text says:
> > >
> > > "FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >       video telephony, video conferencing, live streaming and live
> > >       broadcast, in which cases dependent slice segments SHOULD be us=
ed
> > >       when a slice should be transported in multiple RTP packets."
> > >
> > > I believe that FUs are a viable option to dependent slices for the
> > > reasons I listed in my previous e-mail and think that we should not
> > > recommend dependent slices over FUs but leave it to the implementer.
> > >
> > > BR
> > > Rickard
> > >
> > >
> > > -----Original Message-----
> > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> > > Behalf Of Wang, Ye-Kui
> > > Sent: den 3 juli 2013 20:43
> > > To: Thomas Davies; Stephan Wenger
> > > Cc: payload@ietf.org
> > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > payload format
> > >
> > > Hi All,
> > >
> > > I drafted an email replying directly to Rickard but did not finish
> > > and there was a meeting (and then Stephan's and Thomas' emails came).
> > >
> > > I wanted to comment that Rickard was comparing the use of FUs vs
> > > slices, not FUs vs dependent slices, while the recommendation in the
> > > draft is recommending use of dependent slices over FUs in
> > > live-encoding scenarios (so this answers Thomas question: the
> > > intention was
> > dependent slices ).
> > >
> > > In any case, it does not make much sense to try MTU size matching
> > > and at the same time use either dependent slices or FUs, because
> > > dependent slices and FUs should not be used when there are
> > > considerable packet losses, while MTU size matching should be
> > > applied when there are
> > considerable packet losses.
> > >
> > > For live encoding, whenever splitting of a regular slice is needed,
> > > the splitting can be done by the encoder using dependent slices -
> > > and the encoder has more knowledge and is more powerful than the RTP
> > > packetizer and thus can do a better job for the splitting.
> > >
> > > BR, YK
> > >
> > >
> > > > -----Original Message-----
> > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> > > > On Behalf Of Thomas Davies
> > > > Sent: Wednesday, July 03, 2013 9:34 AM
> > > > To: Stephan Wenger
> > > > Cc: payload@ietf.org
> > > > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > > > payload format
> > > >
> > > > Hi Stephan
> > > >
> > > > I think I agree with Rickard.
> > > >
> > > > I think the text in question states a preference for _dependent_
> > > > slice segments, which have no error resiliency advantage over FUs.
> > > > Is this just a
> > > typo?
> > > >
> > > > <snip>
> > > >
> > > > FUs SHOULD NOT be applied in live-encoding scenarios such as
> > > >        video telephony, video conferencing, live streaming and live
> > > >        broadcast, in which cases dependent slice segments SHOULD be=
 used
> > > >        when a slice should be transported in multiple RTP packets.
> > > >
> > > >
> > > >
> > > > </snip>
> > > >
> > > > In general FUs may be used where error conditions are known to be
> > > > benign, for greater efficiency, and also where for whatever reason
> > > > the encoder cannot support MTU matching.
> > > >
> > > > We also are formulating some more general comments on this area
> > > > which we hope to provide more fully soon.
> > > >
> > > > best regards
> > > >
> > > > Thomas
> > > >
> > > >
> > > > On 03/07/13 17:22, Stephan Wenger wrote:
> > > > > Hi Rickard,
> > > > > Commenting only on slices vs. FUs.
> > > > > The preference for slices over FUs, historically, was pushed by
> > > > > myself into RFC 3984 for reasons of error resilience, and was
> > > > > moved over to this draft for the same reason.  Loose a slice,
> > > > > and you can recover at the next slice boundary; loose an FU, and
> > > > > you have to wait for the next slice header and throw away all
> > > > > trailing FUs.  RTP is in virtually all cases run over UDP, and
> > > > > in the typical Internet scenario UDP is lossy (in contrast to
> > > > > private, managed IP-network, which may have other constraints,
> > > > > but are not the IETF's main
> > > > > concern.) To set your remarks into context, let's first
> > > > > understand what we are talking
> > > > > about: the cost of slices is the overhead stemming from the
> > > > > insertion of slice headers (in-picture syntax prediction) and
> > > > > from the packet headers themselves.  And, of course,
> > > > > implementation complexity, but we should not be in the business
> > > > > to encourage implementor
> > > laziness when
> > > > > there would be a more complex, but better suited tool available. =
   The
> > > > > additional packetization overhead is only incurred when, as a
> > > > > result of incompetently filled packets (which, I agree, is more
> > > > > likely with
> > > > > 64x64 CUs than with 16/16 macroblocks), an additional packet
> > > > > needs to be inserted.  You may remember a quick analysis of mine
> > > > > we discussed way back early in JCT, where we (I think) agreed
> > > > > that the practical impact is negligible in almost all non-tile
> > > > > scenarios (mostly because an additional overhead of 50 bytes or
> > > > > so--3% or less of the coded picture size) is incurred
> > > > > statistically only rarely (only in those cases where an
> > > > > additional packet would need to be generated because of the
> > > > > video coding related overhead for the use of slices).  The
> > > > > prediction overhead of the use of regular slices has been shown
> > > > > to be substantial--the price one needs to pay for independent
> > > > > decodability--but for entropy slices that overhead virtually
> > > does not exist.
> > > > > With respect to tiles, I think you have a point though,
> > > > > especially when considering the type of massive parallel
> > > > > implementations for relatively small picture sizes some folks hav=
e been
> considering.
> > > > > OTOH, because FUs are trivial to implement--some say in contrast
> > > > > to slices--and because (I hope) we all agree that using FUs in
> > > > > error prone scenarios is a bad idea if you could use slices (but
> > > > > for reasons like the tile connection you mentioned), the draft
> > > > > should IMO continue to set a preference for the use of regular
> > > > > slices over FUs.  To avoid underperforming systems due to
> > > > > implementer
> > laziness.
> > > > > However, this is the IETF.  We don't have to worry about the
> > > > > word-count of explanatory language.  In fact, explaining such
> > > > > complex tradeoffs and relationships is generally encouraged here.
> > > > > So let's
> > > just do that:
> > > > > express a preference of the use of regular slices (SHOULD) when
> > > > > you expect losses and can use them (real-time encoding, no
> > > > > tiling structure that would lead to unacceptable packetization
> > > > > overhead); and suggest (MAY) the use of FUs in other scenarios.
> > > > > Accompanied by a more coherently expressed analysis.
> > > > > Stephan
> > > > >
> > > > >
> > > > > On 7.3.2013 06:46 , "Rickard
> > > > > Sj=F6berg"<rickard.sjoberg@ericsson.com>
> > > wrote:
> > > > >
> > > > >> Hi Ye-Kui,
> > > > >>
> > > > >> Thanks for your feedback on my comments, your suggestions look
> > > > >> good to
> > > > me.
> > > > >>
> > > > >> Regarding discouraging fragmentation units (FUs) for
> > > > >> live-encoding scenarios in section 4.7, I think using FUs does
> > > > >> make sense when you do not have many non-VLC NAL units for
> > > > >> aggregation. The spatial granularity of slices was 16x16 pixels
> > > > >> in H.264 but is typically
> > > > >> 64x64 for HEVC which means that MTU size matching is done with
> > > > >> units that are 16x larger. This may lead to a larger number of
> > > > >> smaller packets when slices are used compared to FUs. In
> > > > >> addition, there is the HEVC rule of slice and tile boundaries
> > > > >> that makes the slice granularity equal to the tile granularity
> > > > >> for cases when slices span multiple tiles. Finally, FUs are
> > > > >> easier to implement since you do not need to care about when to
> > > > >> break your slice to not exceed the MTU size limit. I think both
> > > > >> slices and FUs has their merits and the choice between them for
> > > > >> live-encoding should be left for
> > > the implementer.
> > > > >>
> > > > >> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
> > > > >> and the POC MSB sync issue, I agree that this is a corner case
> > > > >> that we probably will not see much of in practice. I have no
> > > > >> text change suggestion at the moment.
> > > > >>
> > > > >> BR
> > > > >> Rickard
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > > > >> Sent: den 24 juni 2013 01:00
> > > > >> To: Rickard Sj=F6berg; payload@ietf.org
> > > > >> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > > >> format
> > > > >>
> > > > >> Hi Rickard,
> > > > >>
> > > > >> Thanks for the careful review and the comments. Please see inlin=
e
> below.
> > > > >>
> > > > >> BR, YK
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> > > > >>> Sent: Thursday, June 20, 2013 9:17 AM
> > > > >>> To: Wang, Ye-Kui; payload@ietf.org
> > > > >>> Subject: RE: Submission of new versions of H.265/HEVC payload
> > > > >>> format
> > > > >>>
> > > > >>> Dear all,
> > > > >>>
> > > > >>> I have taken a first look at draft-schierl-payload-rtp-h265-03
> > > > >>> and have some questions/comments.
> > > > >>>
> > > > >>> My first question is what extensions of HEVC that
> > > > >>> draft-schierl-payload-rtp-
> > > > >>> h265 is intended to cover? The draft mentions "future scalable
> > > > >>> or 3D  video coding  extensions  of  this specification", what
> > > > >>> extensions do you refer to?
> > > > >>> Is the intent to cover the all HEVC extensions in a single
> > > > >>> payload specification?
> > > > >>>
> > > > >> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> > > > >> "this specification" should be replaced with "[HEVC]". It is
> > > > >> sort of copy-and-paste error. Thanks for the good catching. No,
> > > > >> there is no intention to cover HEVC extensions in this payload
> > > > >> specification, though we intentionally to have the
> > > > >> depacketization process and the use with feedback messages to
> > > > >> work for HEVC scalability
> > > and 3DV extensions.
> > > > >>
> > > > >>> Another question for my understanding is why "Receivers MUST
> > > > >>> pass picture timing SEI messages and decoding unit information
> > > > >>> SEI messages to the decoder"?
> > > > >> [YK] Generally, RTP receivers should/must pass all NAL units
> > > > >> specified by the video coding spec to the video decoders. This
> > > > >> is emphasized here for the two timing related SEI messages
> > > > >> after it is said that picture output timing in RTP timestamps
> > > > >> should be used instead (to avoid giving a wrong impression to
> > > > >> readers that the SEI messages should be ignored). If an RTP
> > > > >> receiver discards the SEI messages, then HRD conformance
> > > > >> checking for the bitstream that was possible would be disabled,
> > > > >> and also the information related to frame
> > > > doubling or tripping would be lost.
> > > > >>
> > > > >>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> > > > >>> The fourth one does not seem to be a rule since there is no
> > > > >>> "MUST" or "SHOULD" in the corresponding text.
> > > > >> [YK] I see your point, it is only a "MAY" rule. An alternative
> > > > >> to put this as a packetization rule is to put it as part of the
> > > > >> semantics of NAL unit header (1.1.4), but that sub-section
> > > > >> belongs to an overview wherein normative language (even "MAY")
> > > > >> should not appear. One solution to this is to insert "Payload
> > > > >> Header
> > Usage"
> > > > >> after 4.1 "RTP Header Usage" and include at least this item ther=
e.
> > > > >> I will do this in the next version unless there is a better sugg=
estion.
> > > > >>
> > > > >>> Further, the fifth one discourages using FUs, what are the
> > > > >>> reasons behind that?
> > > > >> [YK] The bullet item only discourages using FUs for
> > > > >> live-encoding scenarios, wherein dependent slice segments should=
 be
> used instead.
> > > > >> This was added after a discussion (among the authors) on the
> > > > >> need of whether to specify a payload structure for mixed FU and
> > > > >> aggregation packets and
> > > > > >from that discussion we concluded that encoding dependent slice
> > > > > >segments
> > > > >> at source coding level already allows for the use cases and
> > > > >> using of FUs for live-encoding does not make sense. Please let
> > > > >> us know if you think differently.
> > > > >>
> > > > >>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
> > > > >>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> > > > >>> differ between the encoder and decoder?
> > > > >> [YK] Good question. In theory this is indeed possible when
> > > > >> random accessing to a bitstream is performed. However, it would
> > > > >> not happen in conversational applications where the feedback
> > > > >> messages may
> > be used.
> > > > >> Therefore, to me this would just work just fine. But please
> > > > >> feel free to make other suggestions.
> > > > >>
> > > > >>> The use of spatial-segmentation-idc may need some updates to
> > > > >>> be useful, let me come back to that later on.
> > > > >>>
> > > > >> [YK] OK. Look forward to seeing your input herein.
> > > > >>
> > > > >>> I have also a number of spelling suggestions for your considera=
tions:
> > > > >>>
> > > > >>> Section 1.1:
> > > > >>> Replace "community" by "communities"
> > > > >> [YK] I guess both are OK. But anyway I just changed it per your
> > > > >> suggestion (for the next version).
> > > > >>
> > > > >>> Section 1.1.1:
> > > > >>> Replace "In addition, interpolation filter" by "In addition,
> > > > >>> the interpolation filter"
> > > > >> [YK] Thanks - done.
> > > > >>
> > > > >>> Replace "skipping the transform coding" by "skipping the transf=
orm"
> > > > >>> (transform_skip_flag of HEVC skips the transform, not the
> > > > >>> coding)
> > > > >>>
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 1.1.2:
> > > > >>> Replace:
> > > > >>> "2) An indication of whether there is any parameter set within
> > > > >>> the current coded video sequence that updates another
> > > > >>> parameter set of the same type preceding in decoding order."
> > > > >>> by:
> > > > >>> "2) An indication of whether there is no parameter set update
> > > > >>> in the coded video sequence."
> > > > >>> since that is what no_parameter_set_update_flag in HEVC indicat=
es.
> > > > >>>
> > > > >> [YK] Changed the wording to "An indication of whether there is
> > > > >> no parameter set within the current coded video sequence that
> > > > >> updates another parameter set of the same type preceding in
> > > > >> decoding
> > order."
> > > > >>
> > > > >>> Section 4.7:
> > > > >>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> > > > >>> and "FU
> > > > >>> Type:  6 bits" to avoid confusion with the Type in the payload =
header.
> > > > >>>
> > > > >> [YK] Good point again. I will change the field name to be "FuTyp=
e".
> > > > >>
> > > > >>> Section 6:
> > > > >>> Replace "recovery" by "recover"
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 7.1:
> > > > >>> Replace "level-id" by "level-idc"
> > > > >> [YK] We are consistently using "id" for profile-id, level-id,
> > > > >> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc=
".
> > > > >>
> > > > >>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > > > >> [YK] Done.
> > > > >>
> > > > >>> Section 8:
> > > > >>> Replace "two  payload-specific  feedback  messages" by "a
> > > > >>> payload-specific feedback  message", since only SPLI is
> > > > >>> "Assigned in this memo".
> > > > >>> Also, consider removing references to H.264 in the last
> > > > >>> paragraph of Section
> > > > >>> 8 since the memo is about HEVC.
> > > > >> [YK] Good catch again. Changed.
> > > > >>
> > > > >>> Section 8.1:
> > > > >>> Seems to me that "There MUST be exactly one RPSI contained in
> > > > >>> the FCI field" should be "There MUST be exactly one SPLI
> > > > >>> contained in the FCI field"
> > > > >> [YK] Another good catch. Changed.
> > > > >>
> > > > >>>
> > > > >>> Best Regards,
> > > > >>> Rickard Sj=F6berg
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: payload-bounces@ietf.org
> > > > >>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> > > > >>> Sent: den 11 juni 2013 19:00
> > > > >>> To: payload@ietf.org
> > > > >>> Subject: [payload] Submission of new versions of H.265/HEVC
> > > > >>> payload format
> > > > >>>
> > > > >>> Dear All,
> > > > >>>
> > > > >>> We have just submitted versions 02 and 03 of
> > > > >>> draft-schierl-payload-rtp-h265, for which the links are as foll=
ows:
> > > > >>>
> > > > >>> Version 02:
> > > > >>> URL:
> > > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > > >>> h265-02.txt
> > > > >>> Htmlized:
> > > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> > > > >>> Diff:
> > > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h2=
6
> > > > >>> 5-
> > > > >>> 02
> > > > >>>
> > > > >>> Version 03:
> > > > >>> URL:
> > > > >>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
> > > > >>> h265-03.txt
> > > > >>> Htmlized:
> > > > >>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> > > > >>> Diff:
> > > > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h2=
6
> > > > >>> 5-
> > > > >>> 03
> > > > >>>
> > > > >>> Version 02 includes huge changes compared to the earlier
> > > > >>> submitted version 01. In a short summary, the authors have
> > > > >>> worked hard to try to make the design complete, from both the
> > > > >>> payload structure and the signaling points of view. Compared
> > > > >>> to version 02, version
> > > > >>> 03 only contains a correction of the email address of an author=
.
> > > > >>>
> > > > >>> Due to that the industry is eager to deploy H.265/HEVC and
> > > > >>> other standards bodies such as 3GPP rely on the payload format
> > > > >>> for support of H.265/HEVC in RTP based video services, we need
> > > > >>> to progress this draft relatively quickly.
> > > > >>> Therefore, we would like to request quick reviews from
> > > > >>> interested parties and also request for the WG status of this d=
raft.
> > > > >>>
> > > > >>> BR, YK (on behalf of the authors)
> > > > >>> _______________________________________________
> > > > >>> payload mailing list
> > > > >>> payload@ietf.org
> > > > >>> https://www.ietf.org/mailman/listinfo/payload
> > > > >>>
> > > > >> _______________________________________________
> > > > >> payload mailing list
> > > > >> payload@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/payload
> > > > > _______________________________________________
> > > > > payload mailing list
> > > > > payload@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/payload
> > > >
> > > > _______________________________________________
> > > > payload mailing list
> > > > payload@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/payload
> > > _______________________________________________
> > > 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 mzanaty@cisco.com  Thu Jul  4 21:18:49 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDB511E8230 for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 21:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.261
X-Spam-Level: 
X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk84FsJ2J++J for <payload@ietfa.amsl.com>; Thu,  4 Jul 2013 21:18:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4111E8231 for <payload@ietf.org>; Thu,  4 Jul 2013 21:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23677; q=dns/txt; s=iport; t=1372997924; x=1374207524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qRYA1xgW65I2UNGgMEXuM+4oKr04TmE59t/PnZBsF9Y=; b=j7XgUPwd4zKvME6N1woFHIsFVypswQpFoSSnm2waeA9QdcE3ANDzAgh0 tSPByMDJ1No0MPOMZ/6icvHd+rgb0X9wU1w13utcN1HlKDBkfiAoPmKvl vZ902FzR99FGTVouEe4YgPs4t4Acldeu5njI9afaqXpIOvlR5lNjpR3Ci 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai4FABpI1lGtJXG+/2dsb2JhbABagwkyQ8A+gQEWdIIjAQEBAwEBAQEXVAQHBQcEAgEIDgMBAwEBAR0KBycLFAMGCAIEDgUJCweHbgYHBbkljh8KAQoFfzMHBoJ+aQOTd4NSgSmQHIMRgWkIFw
X-IronPort-AV: E=Sophos;i="4.87,999,1363132800"; d="scan'208";a="231234660"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2013 04:18:38 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r654Icwn024361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 04:18:38 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 23:18:38 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Stephan Wenger <stewe@stewe.org>
Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format
Thread-Index: AQHOeNulgmb/sxArTEStFYdzo9B6EJlVe7rU
Date: Fri, 5 Jul 2013 04:18:37 +0000
Message-ID: <1EC20A2A-AC3A-41A1-A90B-E473A6F6C8B3@cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com>, <CDFAF888.9EDD0%stewe@stewe.org>
In-Reply-To: <CDFAF888.9EDD0%stewe@stewe.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 04:18:49 -0000

Hi Stephan,

I agree with most of your points, in the context of "design an encoder" as =
you mention. However, this draft/RFC is for designers of RTP apps not encod=
ers. H.265 itself is for designers of encoders. We can (and should) try to =
influence encoder designers to optimize live RTP apps. But we should also g=
ive RTP apps the best tools to optimize themselves given any encoder they u=
se.

I think you hint at a more general point, that we should focus on joint sou=
rce and channel coding. So encoders and RTP apps coordinate an optimal divi=
sion of labor rather than do it all or expect the other to do it all. I als=
o agree with this point as an ideal situation, but think we should also pro=
vide tools in tactical less-than-ideal situations.

More inline.

Cheers,
Mo


On Jul 4, 2013, at 1:26 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Mo,
A few comments about some of your arguments below.
Stephan

On 7.3.2013 21:50 , "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> wrote:

> [=8A]
>=20
> 2. Fragmentation in a higher layer like RTP can have several advantages
> over similar features in a codec layer like slices (independent or
> dependent).
> a. Efficiency: RTP fragmentation has finer (byte) granularity while
> slices have much larger (CTB or tile) granularity. It also has less slice
> segment header overhead, especially for independent slices. This can
> impact the efficiency of the packetized stream in terms of both bits and
> packets per second.

About this aspect I have had a lot of communication about with Rickard and
others.  The benefit one gets in terms of bits and packets per second is
negligible when comparing dependent slices and fragmentation (i.e. the
additional overhead stems from the finer granularity and the resulting
lower number of packets generated in certain corner cases).  I could walk
you through the math, but have to dig through old messages or recreate it.
Obviously, when using independent slices, one gets the additional benefit
of error resilience, and pays for it through prediction penalty overhead.

Mo: I know the math well. I agree the bps delta may be negligible, but the =
pps delta can be significant, and wireless networks are often more stressed=
 by pps than bps. The worst case is going from 2 to 3 packets per frame, wh=
ich is 50% pps overhead.


> b. Performance: Encoders must perform extra processing to limit slice
> sizes, which can impact encoder performance. Some implementations
> speculatively end a slice based on computed statistics (which aggravates
> a.), while others recode a slice if the size is exceeded (which
> aggravates b.).

My main comment here is that it is entirely possible to design an encoder
which implements your option a) in a fairly reliable way; it's bread and
butter technology and has been for decades.  Let me also note that, in
option b) the re-encode only applies to the entropy coding, which is a
very small part of an H.265 encoder in terms of complexity in almost any
architecture, and certainly for the bitrates used in most RTP-based
systems.  Both can have have been used in practical systems with
competitive R-D performance.  To put things into perspective, we are
talking about what?  0.1% encoder cycle increase for option a?  Less?

Mo: Agreed. But the draft is about designing RTP apps not encoders.


> c. Decoupling: Not all encoders will support limiting slice size to MTU
> size. Applications (for live or stored content) using such encoders can
> still support MTU limits using RTP fragmentation since it is decoupled
> from the encoder.

Yes, this is a fine argument.  At the first glance.  However: Those
decoupled, dumb encoders, which cannot even cope with trivially
implementable features involving static conditions (like MTU size
matching) are not likely to cope well with less static, and equally
disturbing features of IP network such as packet loss.  As certain
products in the video conferencing market can tell us :-)  And yes, those
systems cope with packet loss through FEC and whatnot, but that, I would
suggest, is a bolt-on to fix a broken system rather than a conscious,
organic, design choice that was from the outset based on the environment
the system is working in.

> d. Multi-party: The encoded content may go to multiple receivers with
> different MTUs. RTP fragmentation can handle this with lightweight
> repacketization at middle boxes whereas slices incur heavyweight
> transcoding.

No one argues against removing fragmentation as such, and this is one use
case where it makes sense.  Though, AFAIK, even that use case has lost
most of its relevance nowadays, where the 500 octet MTU size of 2G and
2.5G networks is a thing of the past, at least for video).
[...]
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> Behalf Of Rickard Sj=F6berg
> Sent: Wednesday, July 03, 2013 3:38 PM
> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Dear all,
>=20
> I wrote slices and not dependent slices since the slice granularity and
> slice/tile rule applies to both slices and dependent slices. Sorry for
> the confusion. I will now use 'independent slices' and 'dependent slices'
> to distinguish between them.
>=20
> I do not question the use of independent slices, I find them useful in
> some applications.
>=20
> But the current RTP payload text says:
>=20
> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>     video telephony, video conferencing, live streaming and live
>     broadcast, in which cases dependent slice segments SHOULD be used
>     when a slice should be transported in multiple RTP packets."
>=20
> I believe that FUs are a viable option to dependent slices for the
> reasons I listed in my previous e-mail and think that we should not
> recommend dependent slices over FUs but leave it to the implementer.
>=20
> BR
> Rickard
>=20
>=20
> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> Behalf Of Wang, Ye-Kui
> Sent: den 3 juli 2013 20:43
> To: Thomas Davies; Stephan Wenger
> Cc: payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi All,
>=20
> I drafted an email replying directly to Rickard but did not finish and
> there was a meeting (and then Stephan's and Thomas' emails came).
>=20
> I wanted to comment that Rickard was comparing the use of FUs vs slices,
> not FUs vs dependent slices, while the recommendation in the draft is
> recommending use of dependent slices over FUs in live-encoding scenarios
> (so this answers Thomas question: the intention was dependent slices ).
>=20
> In any case, it does not make much sense to try MTU size matching and at
> the same time use either dependent slices or FUs, because dependent
> slices and FUs should not be used when there are considerable packet
> losses, while MTU size matching should be applied when there are
> considerable packet losses.
>=20
> For live encoding, whenever splitting of a regular slice is needed, the
> splitting can be done by the encoder using dependent slices - and the
> encoder has more knowledge and is more powerful than the RTP packetizer
> and thus can do a better job for the splitting.
>=20
> BR, YK
>=20
>=20
>> -----Original Message-----
>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>> Behalf Of Thomas Davies
>> Sent: Wednesday, July 03, 2013 9:34 AM
>> To: Stephan Wenger
>> Cc: payload@ietf.org
>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>> payload format
>>=20
>> Hi Stephan
>>=20
>> I think I agree with Rickard.
>>=20
>> I think the text in question states a preference for _dependent_ slice
>> segments, which have no error resiliency advantage over FUs. Is this
>> just a typo?
>>=20
>> <snip>
>>=20
>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>       video telephony, video conferencing, live streaming and live
>>       broadcast, in which cases dependent slice segments SHOULD be used
>>       when a slice should be transported in multiple RTP packets.
>>=20
>>=20
>>=20
>> </snip>
>>=20
>> In general FUs may be used where error conditions are known to be
>> benign, for greater efficiency, and also where for whatever reason the
>> encoder cannot support MTU matching.
>>=20
>> We also are formulating some more general comments on this area which
>> we hope to provide more fully soon.
>>=20
>> best regards
>>=20
>> Thomas
>>=20
>>=20
>> On 03/07/13 17:22, Stephan Wenger wrote:
>>> Hi Rickard,
>>> Commenting only on slices vs. FUs.
>>> The preference for slices over FUs, historically, was pushed by
>>> myself into RFC 3984 for reasons of error resilience, and was moved
>>> over to this draft for the same reason.  Loose a slice, and you can
>>> recover at the next slice boundary; loose an FU, and you have to
>>> wait for the next slice header and throw away all trailing FUs.  RTP
>>> is in virtually all cases run over UDP, and in the typical Internet
>>> scenario UDP is lossy (in contrast to private, managed IP-network,
>>> which may have other constraints, but are not the IETF's main
>>> concern.) To set your remarks into context, let's first understand
>>> what we are talking
>>> about: the cost of slices is the overhead stemming from the
>>> insertion of slice headers (in-picture syntax prediction) and from
>>> the packet headers themselves.  And, of course, implementation
>>> complexity, but we should not be in the business to encourage
>> implementor laziness when
>>> there would be a more complex, but better suited tool available.
>> The
>>> additional packetization overhead is only incurred when, as a result
>>> of incompetently filled packets (which, I agree, is more likely with
>>> 64x64 CUs than with 16/16 macroblocks), an additional packet needs
>>> to be inserted.  You may remember a quick analysis of mine we
>>> discussed way back early in JCT, where we (I think) agreed that the
>>> practical impact is negligible in almost all non-tile scenarios
>>> (mostly because an additional overhead of 50 bytes or so--3% or less
>>> of the coded picture size) is incurred statistically only rarely
>>> (only in those cases where an additional packet would need to be
>>> generated because of the video coding related overhead for the use
>>> of slices).  The prediction overhead of the use of regular slices
>>> has been shown to be substantial--the price one needs to pay for
>>> independent decodability--but for entropy slices that overhead
>> virtually does not exist.
>>> With respect to tiles, I think you have a point though, especially
>>> when considering the type of massive parallel implementations for
>>> relatively small picture sizes some folks have been considering.
>>> OTOH, because FUs are trivial to implement--some say in contrast to
>>> slices--and because (I hope) we all agree that using FUs in error
>>> prone scenarios is a bad idea if you could use slices (but for
>>> reasons like the tile connection you mentioned), the draft should
>>> IMO continue to set a preference for the use of regular slices over
>>> FUs.  To avoid underperforming systems due to implementer laziness.
>>> However, this is the IETF.  We don't have to worry about the
>>> word-count of explanatory language.  In fact, explaining such
>>> complex tradeoffs and relationships is generally encouraged here.  So
>> let's just do that:
>>> express a preference of the use of regular slices (SHOULD) when you
>>> expect losses and can use them (real-time encoding, no tiling
>>> structure that would lead to unacceptable packetization overhead);
>>> and suggest (MAY) the use of FUs in other scenarios.  Accompanied by
>>> a more coherently expressed analysis.
>>> Stephan
>>>=20
>>>=20
>>> On 7.3.2013 06:46 , "Rickard Sj=F6berg"<rickard.sjoberg@ericsson.com>
>> wrote:
>>>=20
>>>> Hi Ye-Kui,
>>>>=20
>>>> Thanks for your feedback on my comments, your suggestions look good
>>>> to
>> me.
>>>>=20
>>>> Regarding discouraging fragmentation units (FUs) for live-encoding
>>>> scenarios in section 4.7, I think using FUs does make sense when
>>>> you do not have many non-VLC NAL units for aggregation. The spatial
>>>> granularity of slices was 16x16 pixels in H.264 but is typically
>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>> units that are 16x larger. This may lead to a larger number of
>>>> smaller packets when slices are used compared to FUs. In addition,
>>>> there is the HEVC rule of slice and tile boundaries that makes the
>>>> slice granularity equal to the tile granularity for cases when
>>>> slices span multiple tiles. Finally, FUs are easier to implement
>>>> since you do not need to care about when to break your slice to not
>>>> exceed the MTU size limit. I think both slices and FUs has their
>>>> merits and the choice between them for live-encoding should be left
>> for the implementer.
>>>>=20
>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2 and
>>>> the POC MSB sync issue, I agree that this is a corner case that we
>>>> probably will not see much of in practice. I have no text change
>>>> suggestion at the moment.
>>>>=20
>>>> BR
>>>> Rickard
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>> Sent: den 24 juni 2013 01:00
>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>> format
>>>>=20
>>>> Hi Rickard,
>>>>=20
>>>> Thanks for the careful review and the comments. Please see inline
>> below.
>>>>=20
>>>> BR, YK
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>> format
>>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03 and
>>>>> have some questions/comments.
>>>>>=20
>>>>> My first question is what extensions of HEVC that
>>>>> draft-schierl-payload-rtp-
>>>>> h265 is intended to cover? The draft mentions "future  scalable
>>>>> or 3D  video coding  extensions  of  this  specification", what
>>>>> extensions do you refer to?
>>>>> Is the intent to cover the all HEVC extensions in a single payload
>>>>> specification?
>>>>>=20
>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>> "this specification" should be replaced with "[HEVC]". It is sort
>>>> of copy-and-paste error. Thanks for the good catching. No, there is
>>>> no intention to cover HEVC extensions in this payload
>>>> specification, though we intentionally to have the depacketization
>>>> process and the use with feedback messages to work for HEVC
>> scalability and 3DV extensions.
>>>>=20
>>>>> Another question for my understanding is why "Receivers MUST pass
>>>>> picture timing SEI messages and decoding unit information SEI
>>>>> messages to the decoder"?
>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>> specified by the video coding spec to the video decoders. This is
>>>> emphasized here for the two timing related SEI messages after it is
>>>> said that picture output timing in RTP timestamps should be used
>>>> instead (to avoid giving a wrong impression to readers that the SEI
>>>> messages should be ignored). If an RTP receiver discards the SEI
>>>> messages, then HRD conformance checking for the bitstream that was
>>>> possible would be disabled, and also the information related to
>>>> frame
>> doubling or tripping would be lost.
>>>>=20
>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules. The
>>>>> fourth one does not seem to be a rule since there is no "MUST" or
>>>>> "SHOULD" in the corresponding text.
>>>> [YK] I see your point, it is only a "MAY" rule. An alternative to
>>>> put this as a packetization rule is to put it as part of the
>>>> semantics of NAL unit header (1.1.4), but that sub-section belongs
>>>> to an overview wherein normative language (even "MAY") should not
>>>> appear. One solution to this is to insert "Payload Header Usage"
>>>> after 4.1 "RTP Header Usage" and include at least this item there.
>>>> I will do this in the next version unless there is a better
>> suggestion.
>>>>=20
>>>>> Further, the fifth one discourages using FUs, what are the reasons
>>>>> behind that?
>>>> [YK] The bullet item only discourages using FUs for live-encoding
>>>> scenarios, wherein dependent slice segments should be used instead.
>>>> This was added after a discussion (among the authors) on the need
>>>> of whether to specify a payload structure for mixed FU and
>>>> aggregation packets and
>>>> from that discussion we concluded that encoding dependent slice
>>>> segments
>>>> at source coding level already allows for the use cases and using
>>>> of FUs for live-encoding does not make sense. Please let us know if
>>>> you think differently.
>>>>=20
>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may differ
>>>>> between the encoder and decoder?
>>>> [YK] Good question. In theory this is indeed possible when random
>>>> accessing to a bitstream is performed. However, it would not happen
>>>> in conversational applications where the feedback messages may be
>> used.
>>>> Therefore, to me this would just work just fine. But please feel
>>>> free to make other suggestions.
>>>>=20
>>>>> The use of spatial-segmentation-idc may need some updates to be
>>>>> useful, let me come back to that later on.
>>>>>=20
>>>> [YK] OK. Look forward to seeing your input herein.
>>>>=20
>>>>> I have also a number of spelling suggestions for your
>> considerations:
>>>>>=20
>>>>> Section 1.1:
>>>>> Replace "community" by "communities"
>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>> suggestion (for the next version).
>>>>=20
>>>>> Section 1.1.1:
>>>>> Replace "In addition, interpolation filter" by "In addition, the
>>>>> interpolation filter"
>>>> [YK] Thanks - done.
>>>>=20
>>>>> Replace "skipping the transform coding" by "skipping the transform"
>>>>> (transform_skip_flag of HEVC skips the transform, not the coding)
>>>>>=20
>>>> [YK] Done.
>>>>=20
>>>>> Section 1.1.2:
>>>>> Replace:
>>>>> "2) An indication of whether there is any parameter set within the
>>>>> current coded video sequence that updates another parameter set of
>>>>> the same type preceding in decoding order."
>>>>> by:
>>>>> "2) An indication of whether there is no parameter set update in
>>>>> the coded video sequence."
>>>>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>>>>=20
>>>> [YK] Changed the wording to "An indication of whether there is no
>>>> parameter set within the current coded video sequence that updates
>>>> another parameter set of the same type preceding in decoding order."
>>>>=20
>>>>> Section 4.7:
>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type" and
>>>>> "FU
>>>>> Type:  6 bits" to avoid confusion with the Type in the payload
>> header.
>>>>>=20
>>>> [YK] Good point again. I will change the field name to be "FuType".
>>>>=20
>>>>> Section 6:
>>>>> Replace "recovery" by "recover"
>>>> [YK] Done.
>>>>=20
>>>>> Section 7.1:
>>>>> Replace "level-id" by "level-idc"
>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>>>>=20
>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>> [YK] Done.
>>>>=20
>>>>> Section 8:
>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>> payload-specific feedback  message", since only SPLI is "Assigned
>>>>> in this memo".
>>>>> Also, consider removing references to H.264 in the last paragraph
>>>>> of Section
>>>>> 8 since the memo is about HEVC.
>>>> [YK] Good catch again. Changed.
>>>>=20
>>>>> Section 8.1:
>>>>> Seems to me that "There MUST be exactly one RPSI contained in the
>>>>> FCI field" should be "There MUST be exactly one SPLI contained in
>>>>> the FCI field"
>>>> [YK] Another good catch. Changed.
>>>>=20
>>>>>=20
>>>>> Best Regards,
>>>>> Rickard Sj=F6berg
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>>> On Behalf Of Wang, Ye-Kui
>>>>> Sent: den 11 juni 2013 19:00
>>>>> To: payload@ietf.org
>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>> Dear All,
>>>>>=20
>>>>> We have just submitted versions 02 and 03 of
>>>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>>>>=20
>>>>> Version 02:
>>>>> URL:
>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>> h265-02.txt
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>> Diff:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>>>>> 02
>>>>>=20
>>>>> Version 03:
>>>>> URL:
>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>> h265-03.txt
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>> Diff:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-
>>>>> 03
>>>>>=20
>>>>> Version 02 includes huge changes compared to the earlier submitted
>>>>> version 01. In a short summary, the authors have worked hard to
>>>>> try to make the design complete, from both the payload structure
>>>>> and the signaling points of view. Compared to version 02, version
>>>>> 03 only contains a correction of the email address of an author.
>>>>>=20
>>>>> Due to that the industry is eager to deploy H.265/HEVC and other
>>>>> standards bodies such as 3GPP rely on the payload format for
>>>>> support of H.265/HEVC in RTP based video services, we need to
>>>>> progress this draft relatively quickly.
>>>>> Therefore, we would like to request quick reviews from interested
>>>>> parties and also request for the WG status of this draft.
>>>>>=20
>>>>> BR, YK (on behalf of the authors)
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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 randell-ietf@jesup.org  Fri Jul  5 00:08:33 2013
Return-Path: <randell-ietf@jesup.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5334611E8251 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 00:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVqg7+jQps2D for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 00:08:27 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB0611E8250 for <payload@ietf.org>; Fri,  5 Jul 2013 00:08:27 -0700 (PDT)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2798 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1Uv082-000Gxl-IP for payload@ietf.org; Fri, 05 Jul 2013 02:08:26 -0500
Message-ID: <51D670D8.5030309@jesup.org>
Date: Fri, 05 Jul 2013 03:08:08 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: payload@ietf.org
References: <CDFAF888.9EDD0%stewe@stewe.org>
In-Reply-To: <CDFAF888.9EDD0%stewe@stewe.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: none
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 07:08:33 -0000

On 7/4/2013 1:26 PM, Stephan Wenger wrote:
> Mo wrote:
>> c. Decoupling: Not all encoders will support limiting slice size to MTU
>> size. Applications (for live or stored content) using such encoders can
>> still support MTU limits using RTP fragmentation since it is decoupled
> >from the encoder.
>
> Yes, this is a fine argument.  At the first glance.  However: Those
> decoupled, dumb encoders, which cannot even cope with trivially
> implementable features involving static conditions (like MTU size
> matching) are not likely to cope well with less static, and equally
> disturbing features of IP network such as packet loss.  As certain
> products in the video conferencing market can tell us :-)  And yes, those
> systems cope with packet loss through FEC and whatnot, but that, I would
> suggest, is a bolt-on to fix a broken system rather than a conscious,
> organic, design choice that was from the outset based on the environment
> the system is working in.

Agreed, mostly - I've built systems using H.264 fragmentation without 
limiting NAL size without problems.  These tended to stay at bandwidths 
<1Mbps (and in fact almost entirely at bandwidths <384 Kbps, and thus on 
average a frame was less than one 1500-byte packet, with a few things 
like IDRs being the exceptions).  And perhaps some 
non-interactive-focused (hardware) encoders might not provide the 
options you'd want here.  But I agree in general.

>> d. Multi-party: The encoded content may go to multiple receivers with
>> different MTUs. RTP fragmentation can handle this with lightweight
>> repacketization at middle boxes whereas slices incur heavyweight
>> transcoding.
> No one argues against removing fragmentation as such, and this is one use
> case where it makes sense.  Though, AFAIK, even that use case has lost
> most of its relevance nowadays, where the 500 octet MTU size of 2G and
> 2.5G networks is a thing of the past, at least for video).

I would note that per papers submitted at the RTP congestion control 
workshop last year, larger packets on cell networks have considerably 
higher loss rates, and so you may want to limit packet size to those 
clients even though they support 1500-byte packets, and at higher loss 
rates you also may lose less total "goodput" by running a larger number 
of smaller packets, even with overhead.


-- 
Randell Jesup
randell-ietf@jesup.org


From thomas.schierl@hhi.fraunhofer.de  Fri Jul  5 02:34:43 2013
Return-Path: <thomas.schierl@hhi.fraunhofer.de>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC0921F9CA2 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 02:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ttWPiHOYw4C for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 02:34:38 -0700 (PDT)
Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E521F9C4F for <payload@ietf.org>; Fri,  5 Jul 2013 02:34:37 -0700 (PDT)
X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0
Received: from ic-pc009m.ic.tu-berlin.de (ic-pc009m.ic.tu-berlin.de [130.149.228.97]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id C6E361C90009; Fri,  5 Jul 2013 11:34:34 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com>
Date: Fri, 5 Jul 2013 11:34:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1508)
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-7.0.0.1014-19994.005
X-TM-AS-Result: No--35.178-11.0-31-10
X-imss-scan-details: No--35.178-11.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TMASE-MatchedRID: 8HTFlOrbAtGoB6BkKpx1kbMjW/sniEQKJjlv06yk4fB6fLdhzTLcV+2l xlW3AjAIiNQGt9W18zwqkVjM7stQLsuY+x+wpWIHt1AhvyEKdj5ERtuz7a4uLrWkS2au3FFFg/5 gNr8OG73KH19Q6YMxmEQ9uY1SbFrVHPB54jAqBhfY5KPiokD1BjtSuYjPEOig55TSoW/nwH5uhO 0f4AzeKKG2K4R+6ghuLOE2D7Ypt/P1nyrqs74iHhIRh9wkXSlFKaRmDCmXszck0J7rldHc+o4ma kWSIXbD5OfMmSmbH5u8GbaGjMSXVNDpKoZcjgcDF0vYDRID+crtMsBKGEjbqS62hjZS0WoYCL1y YUEE8H5O5gaRckOLyEnOYTDFtFSyYUCKP+jKbg9IRA38P/dwbmKaLwu81+avMBIR1uSlQM9uiGI Az03yCgA1xPFd5qRFRAJMdpeIiOkEVfbO5MVlckg5Iem1vm3HKpBqUyGzhQFjPrlNB+gMq2+KB6 8utkHuj5DH+mvOvgJ/DUPTGhX4ufHgKSpVZydJ9Ib/6w+1lWTYP/ttQgmUXUiO8DX9hL7R8kdIj 5/vuBRLGM/g/IHl2WNuoFAqzEAvFMmbsxtPvUt+7IhLVmN+u3/0yDqj7AyLtRXhV8npIHToOCqM HQKQMjptORajk0CaHegHerukELD2uFM7xPmS0WLcC5LMI6Rwk9atiES99p0ifM7JMNHW66imtn2 ub/5OPZZgAqG+mnbhB3MLqxt9Xn976qbiQKm/1FnWYpN8q2El1tHtusOLDSAaCgpFJrgJsYKQLF UbB7t71POrVC8uzCXquvz3fdpuxlHnMvFtXmoksSBZTGCrwmNn8XPiALIbp2c3EY8h4cmrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
X-IMSS-DKIM-White-List: No
X-alterMIME: Yes
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 09:34:43 -0000

Dear Ye-Kui, all,

Further I would tentatively assume that you can use the slice segment =
address in the dependent slice fragment header for the same degree of =
error resilience as the new-FU header, if you put a tile into a =
dependent slice. And this part would be understood by the decoder =
itself, which should be able to do the error resilience on codec level. =
Without fancy interfaces into the decoder, etc.

A point in the discussion which seems to be missing is that the =
rewriting of a single slice into multiple dependent slice fragments =
(including also one independent slice fragment) can be done at very low =
processing costs, as shown during the standardization of HEVC.=20

Thomas=20
--
Thomas Schierl
Fraunhofer HHI

Am 04.07.2013 um 19:59 schrieb "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>:

> Hi Thomas,
>=20
> Thanks for the clarification - I think now understand your scheme =
better.
>=20
> So you did not intent to encapsulate only entire tiles into packets, =
though that would obviously be more error resilient as you won't =
encounter the problem where a part of a tile gets lost and the received =
rest becomes useless. Rather, one tile may be carried in two (or even =
more) packets.=20
>=20
> I think I was confused by the suggested language such as "If a =
fragmentation unit is lost, tiles in the lost fragmentation unit are =
also lost. However, tiles which are successfully received in their =
entirety can be decoded if their slice segment header containing tile =
offsets is successfully received, despite lost fragmentation units.", =
from where I got an impression that an FU includes entire tiles.
>=20
> As seen from other discussions, it is very questionable how big a =
penalty would be when an encoder tries to splitting encoded data into =
separate NAL units (slices or dependent slices) for MTU size matching, =
even for large CTB sizes - that's the reason why the JCT-VC later =
decided to remove the fine-granularity slice feature.
>=20
> Let's tentatively assume that overall penalty and the overhead of the =
new-FU approach are roughly equivalent, and take into account latest =
comments from Mo and Stephan, do we see an advantage of the new-FU =
approach compared to using dependent slices?
>=20
> I am not trying to conclude yet - just try to (very briefly) summarize =
the situation so far at least for myself.  We should certainly have more =
discussions - preferable involving more people who care about this =
payload format.
>=20
> BR, YK
>=20
>> -----Original Message-----
>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>> Sent: Thursday, July 04, 2013 9:23 AM
>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan =
Wenger;
>> Paul Bright-Thomas (paubrigh)
>> Cc: payload@ietf.org
>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>> format
>>=20
>> Hi Ye-Kui
>>=20
>> Thank you for the clarification - I understand your point a bit =
better now.
>>=20
>> With the proposed scheme there is no need for the RTP packetizer to =
parse
>> slice headers or identify tile boundaries. All it needs to do is to =
keep track of the
>> offset of the start of the payload to the beginning of the NALU and =
put this into
>> the field. It needs to know this offset anyway. The packetizer is =
completely
>> dumb.
>>=20
>> The point is that a decoder wishing to do error resilience can parse =
the slice
>> header and identify the tile boundaries in the case that a packet =
goes missing,
>> for tiles that occur in the same frame but after the packet that is =
lost. The
>> decoder can compare the tile offsets with the FU offsets to work out =
what data
>> is missing.
>>=20
>> Re dependent slices, there are indirect overheads as well, which come =
from
>> having to quantize the packet size to a whole number of tiles, plus =
you have to
>> manage the encoder to match the MTU size. The granularity of tiles =
you need
>> for your parallel processing may not match the granularity you need =
to fit in
>> the MTU very well.
>>=20
>> Best regards
>>=20
>> Thomas
>>=20
>>=20
>> -----Original Message-----
>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>> Sent: 04 July 2013 16:34
>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; =
Stephan
>> Wenger; Paul Bright-Thomas (paubrigh)
>> Cc: payload@ietf.org
>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>> format
>>=20
>> Hi Thomas,
>>=20
>> My point was really about using dependent slices, not about 1 or N =
tiles per
>> packets (sorry that I did not make that clearer). Whatever strategy =
you would
>> like to do in terms of the number of tiles in a packet, using =
dependent slices can
>> do the same, as each dependent slice can include 1 or N tiles.
>>=20
>> I see the following advantages with the approach using dependent =
slices
>> instead of defining new FUs:
>>=20
>> - First of all, no need to define new payload structures.
>>=20
>> - The RTP packetizer does not need to parse slice headers to identify =
boundaries
>> of tiles within a coded slice, as tiles of one SLICE are already in =
separate NAL
>> units each containing a DEPENDENT SLICE.
>>=20
>> - No additional overhead in packetization (the 1-byte FU header and =
the 2- or
>> 4-byte FU offset). The overhead of the short slice header for =
dependent slice
>> NAL units is compensated by less number of tile entry offsets =
signalled, as the
>> entry offset of the first tile in each NAL unit is not signalled in =
the slice header.
>> Using dependent slices would need more two-byte NAL unit headers, =
while
>> using new FUs would need more two-byte packet payload headers, and =
the
>> overhead bits here are the same for both methods.
>>=20
>> Am I missing anything here?
>>=20
>> BR, YK
>>=20
>>> -----Original Message-----
>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>> Sent: Thursday, July 04, 2013 1:49 AM
>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
>>> Wenger; Paul Bright-Thomas (paubrigh)
>>> Cc: payload@ietf.org
>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>> payload format
>>>=20
>>> Yes, we did think about one tile per packet or N tiles per packet,
>>> also: I guess that is where we started from. Then you could indeed
>>> align missing tiles with missing sequence numbers.
>>>=20
>>> The issue is that you need to guarantee that you are doing this for =
it
>>> to be useful, and the decoder needs to know that this is guaranteed
>>> through some form of other signalling. However, the bitstream chunk
>>> associated to a tile is extremely variable, and many tile chunks =
would
>>> be very small. So there is significant packetization overhead for =
them if there
>> is one tile per packet.
>>>=20
>>> Having N>1 reduces this overhead, but it is still there and as N
>>> increases you run the risk of breaking the MTU size which then
>>> requires that you have to re- encode to fit things in and meet the
>>> guarantee. There is definitely no time to re-encode whole tiles,
>>> especially if you are already using them for parallelization. Thus =
you
>>> might have to break the guarantee and fragment the packet anyhow, =
losing
>> the resilience.
>>>=20
>>> The advantage that we see with the proposal is that you can get =
fairly
>>> similar resilience to regular slice MTU-size matching, but with much
>>> lower overheads as you can have a single regular slice header per =
frame, yet
>> have a "dumb"
>>> packetization process and no need to re-encode to hit MTU targets. =
In
>>> H264 MTU matching usually means re-encoding just one or two 16x16 =
MBs.
>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you =
are
>>> doing tiles then you can get tiny "dangling slices" at the end of a
>>> tile, which means more small packets.
>>>=20
>>> Best regards
>>>=20
>>> Thomas
>>>=20
>>> -----Original Message-----
>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>> Sent: 04 July 2013 07:02
>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies =
(thdavies);
>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>>> Cc: payload@ietf.org
>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>> payload format
>>>=20
>>>=20
>>> An interesting idea. Using dependent slices (again :-) together with
>>> tiles would do the trick too (each tile in one dependent slice, and
>>> then each dependent slice NAL unit in one single NAL unit packet).
>>>=20
>>> Have you guys done an analysis comparing the pros and cons of the =
two
>>> alternative approaches?
>>>=20
>>> BR, YK
>>>=20
>>>> -----Original Message-----
>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); =
Stephan
>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>=20
>>>> Thomas, Paul and I have been working on improving packet loss
>>>> resilience using fragments and tiles. I mentioned this to Stephan =
at
>>>> IETF 86 in Orlando, and promised to have draft text ready before
>>>> Berlin. Here is the proposed text along with an overview of the =
rationale.
>>>>=20
>>>> Rationale:
>>>>=20
>>>> 1. Resilience to packet loss requires independent slices or tiles.
>>>> Since independence requires restrictions on some coding tools, both
>>>> potentially incur slight penalties in coding efficiency, with a
>>>> smaller penalty
>>> for tiles.
>>>>=20
>>>> 2. Fragmentation in a higher layer like RTP can have several
>>>> advantages over similar features in a codec layer like slices
>>>> (independent or
>>> dependent).
>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity while
>>>> slices have much larger (CTB or tile) granularity. It also has less
>>>> slice segment header overhead, especially for independent slices.
>>>> This can impact the efficiency of the packetized stream in terms of
>>>> both bits and
>>> packets per second.
>>>> b. Performance: Encoders must perform extra processing to limit
>>>> slice sizes, which can impact encoder performance. Some
>>>> implementations speculatively end a slice based on computed
>>>> statistics (which aggravates a.), while others recode a slice if =
the
>>>> size is exceeded (which
>>> aggravates b.).
>>>> c. Decoupling: Not all encoders will support limiting slice size to =
MTU size.
>>>> Applications (for live or stored content) using such encoders can
>>>> still support MTU limits using RTP fragmentation since it is
>>>> decoupled from
>>> the encoder.
>>>> d. Multi-party: The encoded content may go to multiple receivers
>>>> with different MTUs. RTP fragmentation can handle this with
>>>> lightweight repacketization at middle boxes whereas slices incur
>> heavyweight transcoding.
>>>>=20
>>>> 3. Combining fragmentation and tiles can improve resilience while
>>>> retaining the above advantages, if fragments are enhanced to =
contain
>>>> offsets (similar to IP fragmentation). This is described in the
>>>> proposed draft text below, which would immediately follow section
>>>> 4.7
>>> Fragmentation Units.
>>>>=20
>>>> Draft Text:
>>>>=20
>>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>>=20
>>>> If a fragmented NAL unit contains tiles, its slice segment header
>>>> contains offsets to the data of each tile. These offsets can be =
used
>>>> for random access to any tile for parallel processing, region of
>>>> interest extraction, and resilience to errors in other tiles. These
>>>> offsets can also be used to provide resilience to packet loss, in
>>>> conjunction with fragment offsets contained in two types of
>>>> fragmentation
>>> units: FU-A2 and FU-A4.
>>>>=20
>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset =
before
>>>> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure =
X.
>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>>> indicates the total number of bytes in all prior FU payloads of the
>>>> fragmented
>>> NAL unit.
>>>>=20
>>>>=20
>>>>    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
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  =
|
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   | FU-A2 offset  |     DONL (optional)           |               |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>>   |                                                               |
>>>>   |                         FU payload                            |
>>>>   |                                                               |
>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                               :...OPTIONAL RTP padding        |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>=20
>>>>                  Figure X   RTP payload format for FU-A2
>>>>=20
>>>>=20
>>>>    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
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  =
|
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |      FU-A4 offset                             | DONL(optional)|
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   | DONL(optional)|                                               |
>>>>   +-+-+-+-+-+-+-+-+         FU payload                            |
>>>>   |                                                               |
>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                               :...OPTIONAL RTP padding        |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>=20
>>>>                  Figure Y   RTP payload format for FU-A4
>>>>=20
>>>>=20
>>>> Since the offset of the first FU payload of a fragmented NAL unit =
is
>>>> zero, and the Start (S) bit in the FU header is sufficient to
>>>> indicate this, the first fragmentation unit of a fragmented NAL =
unit
>>>> SHOULD use FU-A, but MAY use
>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>>> non-zero offset. The Start
>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>>> contains a non- zero offset, and MUST be set if it contains a zero =
offset.
>>>>=20
>>>> If a fragmentation unit is lost, tiles in the lost fragmentation =
unit are also
>> lost.
>>>> However, tiles which are successfully received in their entirety =
can
>>>> be decoded if their slice segment header containing tile offsets is
>>>> successfully received, despite lost fragmentation units. Fragment
>>>> offsets in FU-A2 or FU-A4 are required in order to recover from =
loss
>>>> of prior fragmentation units and continue decoding subsequent =
tiles.
>>>>=20
>>>> The following heuristic SHOULD be applied to determine if the lost
>>>> fragmentation units are all part of the same fragmented NAL unit as
>>>> subsequently received fragmentation units with identical RTP
>>>> timestamps and identical values of NAL unit header layer ID and =
temporal
>> ID.
>>>>=20
>>>> 1. Let N be the number of missing sequence numbers between two
>>>> received fragmentation units with known offsets.
>>>> 2. Let P be the FU payload size of the first of the two received =
FUs.
>>>> 3. Let D be the difference in the offsets, minus P.
>>>>   (This is the number of missing FU payload bytes.) 4. Let E be N =
times P.
>>>>   (This is the estimated number of missing FU payload bytes.) 5.
>>>> Let ERROR be the absolute difference between D and E, divided by D.
>>>> 6. If ERROR < 50%, it is likely all FUs are part of the same
>>>> fragmented NAL unit, otherwise it is unlikely.
>>>>=20
>>>> Cheers,
>>>> Mo
>>>>=20
>>>> -----Original Message-----
>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>> Behalf Of Rickard Sj=F6berg
>>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>>> Cc: payload@ietf.org
>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>=20
>>>> Dear all,
>>>>=20
>>>> I wrote slices and not dependent slices since the slice granularity
>>>> and slice/tile rule applies to both slices and dependent slices.
>>>> Sorry for the confusion. I will now use 'independent slices' and
>>>> 'dependent slices' to distinguish between them.
>>>>=20
>>>> I do not question the use of independent slices, I find them useful
>>>> in some applications.
>>>>=20
>>>> But the current RTP payload text says:
>>>>=20
>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>      video telephony, video conferencing, live streaming and live
>>>>      broadcast, in which cases dependent slice segments SHOULD be =
used
>>>>      when a slice should be transported in multiple RTP packets."
>>>>=20
>>>> I believe that FUs are a viable option to dependent slices for the
>>>> reasons I listed in my previous e-mail and think that we should not
>>>> recommend dependent slices over FUs but leave it to the =
implementer.
>>>>=20
>>>> BR
>>>> Rickard
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>> Behalf Of Wang, Ye-Kui
>>>> Sent: den 3 juli 2013 20:43
>>>> To: Thomas Davies; Stephan Wenger
>>>> Cc: payload@ietf.org
>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>=20
>>>> Hi All,
>>>>=20
>>>> I drafted an email replying directly to Rickard but did not finish
>>>> and there was a meeting (and then Stephan's and Thomas' emails =
came).
>>>>=20
>>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>>> slices, not FUs vs dependent slices, while the recommendation in =
the
>>>> draft is recommending use of dependent slices over FUs in
>>>> live-encoding scenarios (so this answers Thomas question: the
>>>> intention was
>>> dependent slices ).
>>>>=20
>>>> In any case, it does not make much sense to try MTU size matching
>>>> and at the same time use either dependent slices or FUs, because
>>>> dependent slices and FUs should not be used when there are
>>>> considerable packet losses, while MTU size matching should be
>>>> applied when there are
>>> considerable packet losses.
>>>>=20
>>>> For live encoding, whenever splitting of a regular slice is needed,
>>>> the splitting can be done by the encoder using dependent slices -
>>>> and the encoder has more knowledge and is more powerful than the =
RTP
>>>> packetizer and thus can do a better job for the splitting.
>>>>=20
>>>> BR, YK
>>>>=20
>>>>=20
>>>>> -----Original Message-----
>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>>> On Behalf Of Thomas Davies
>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>>> To: Stephan Wenger
>>>>> Cc: payload@ietf.org
>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>> Hi Stephan
>>>>>=20
>>>>> I think I agree with Rickard.
>>>>>=20
>>>>> I think the text in question states a preference for _dependent_
>>>>> slice segments, which have no error resiliency advantage over FUs.
>>>>> Is this just a
>>>> typo?
>>>>>=20
>>>>> <snip>
>>>>>=20
>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>       video telephony, video conferencing, live streaming and live
>>>>>       broadcast, in which cases dependent slice segments SHOULD be =
used
>>>>>       when a slice should be transported in multiple RTP packets.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> </snip>
>>>>>=20
>>>>> In general FUs may be used where error conditions are known to be
>>>>> benign, for greater efficiency, and also where for whatever reason
>>>>> the encoder cannot support MTU matching.
>>>>>=20
>>>>> We also are formulating some more general comments on this area
>>>>> which we hope to provide more fully soon.
>>>>>=20
>>>>> best regards
>>>>>=20
>>>>> Thomas
>>>>>=20
>>>>>=20
>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>>> Hi Rickard,
>>>>>> Commenting only on slices vs. FUs.
>>>>>> The preference for slices over FUs, historically, was pushed by
>>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>>> and you can recover at the next slice boundary; loose an FU, and
>>>>>> you have to wait for the next slice header and throw away all
>>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>>> private, managed IP-network, which may have other constraints,
>>>>>> but are not the IETF's main
>>>>>> concern.) To set your remarks into context, let's first
>>>>>> understand what we are talking
>>>>>> about: the cost of slices is the overhead stemming from the
>>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>>> from the packet headers themselves.  And, of course,
>>>>>> implementation complexity, but we should not be in the business
>>>>>> to encourage implementor
>>>> laziness when
>>>>>> there would be a more complex, but better suited tool available.  =
  The
>>>>>> additional packetization overhead is only incurred when, as a
>>>>>> result of incompetently filled packets (which, I agree, is more
>>>>>> likely with
>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>>> needs to be inserted.  You may remember a quick analysis of mine
>>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>>> that the practical impact is negligible in almost all non-tile
>>>>>> scenarios (mostly because an additional overhead of 50 bytes or
>>>>>> so--3% or less of the coded picture size) is incurred
>>>>>> statistically only rarely (only in those cases where an
>>>>>> additional packet would need to be generated because of the
>>>>>> video coding related overhead for the use of slices).  The
>>>>>> prediction overhead of the use of regular slices has been shown
>>>>>> to be substantial--the price one needs to pay for independent
>>>>>> decodability--but for entropy slices that overhead virtually
>>>> does not exist.
>>>>>> With respect to tiles, I think you have a point though,
>>>>>> especially when considering the type of massive parallel
>>>>>> implementations for relatively small picture sizes some folks =
have been
>> considering.
>>>>>> OTOH, because FUs are trivial to implement--some say in contrast
>>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>>> error prone scenarios is a bad idea if you could use slices (but
>>>>>> for reasons like the tile connection you mentioned), the draft
>>>>>> should IMO continue to set a preference for the use of regular
>>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>>> implementer
>>> laziness.
>>>>>> However, this is the IETF.  We don't have to worry about the
>>>>>> word-count of explanatory language.  In fact, explaining such
>>>>>> complex tradeoffs and relationships is generally encouraged here.
>>>>>> So let's
>>>> just do that:
>>>>>> express a preference of the use of regular slices (SHOULD) when
>>>>>> you expect losses and can use them (real-time encoding, no
>>>>>> tiling structure that would lead to unacceptable packetization
>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
>>>>>> Accompanied by a more coherently expressed analysis.
>>>>>> Stephan
>>>>>>=20
>>>>>>=20
>>>>>> On 7.3.2013 06:46 , "Rickard
>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>>> wrote:
>>>>>>=20
>>>>>>> Hi Ye-Kui,
>>>>>>>=20
>>>>>>> Thanks for your feedback on my comments, your suggestions look
>>>>>>> good to
>>>>> me.
>>>>>>>=20
>>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
>>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>>> aggregation. The spatial granularity of slices was 16x16 pixels
>>>>>>> in H.264 but is typically
>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>>>>> units that are 16x larger. This may lead to a larger number of
>>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>>> that makes the slice granularity equal to the tile granularity
>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>>> easier to implement since you do not need to care about when to
>>>>>>> break your slice to not exceed the MTU size limit. I think both
>>>>>>> slices and FUs has their merits and the choice between them for
>>>>>>> live-encoding should be left for
>>>> the implementer.
>>>>>>>=20
>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
>>>>>>> and the POC MSB sync issue, I agree that this is a corner case
>>>>>>> that we probably will not see much of in practice. I have no
>>>>>>> text change suggestion at the moment.
>>>>>>>=20
>>>>>>> BR
>>>>>>> Rickard
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>>> Sent: den 24 juni 2013 01:00
>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>> format
>>>>>>>=20
>>>>>>> Hi Rickard,
>>>>>>>=20
>>>>>>> Thanks for the careful review and the comments. Please see =
inline
>> below.
>>>>>>>=20
>>>>>>> BR, YK
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>> format
>>>>>>>>=20
>>>>>>>> Dear all,
>>>>>>>>=20
>>>>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03
>>>>>>>> and have some questions/comments.
>>>>>>>>=20
>>>>>>>> My first question is what extensions of HEVC that
>>>>>>>> draft-schierl-payload-rtp-
>>>>>>>> h265 is intended to cover? The draft mentions "future scalable
>>>>>>>> or 3D  video coding  extensions  of  this specification", what
>>>>>>>> extensions do you refer to?
>>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>>> payload specification?
>>>>>>>>=20
>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>>> sort of copy-and-paste error. Thanks for the good catching. No,
>>>>>>> there is no intention to cover HEVC extensions in this payload
>>>>>>> specification, though we intentionally to have the
>>>>>>> depacketization process and the use with feedback messages to
>>>>>>> work for HEVC scalability
>>>> and 3DV extensions.
>>>>>>>=20
>>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>>> pass picture timing SEI messages and decoding unit information
>>>>>>>> SEI messages to the decoder"?
>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>>> specified by the video coding spec to the video decoders. This
>>>>>>> is emphasized here for the two timing related SEI messages
>>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>>> checking for the bitstream that was possible would be disabled,
>>>>>>> and also the information related to frame
>>>>> doubling or tripping would be lost.
>>>>>>>=20
>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
>>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
>>>>>>> to put this as a packetization rule is to put it as part of the
>>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>>> belongs to an overview wherein normative language (even "MAY")
>>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>>> Header
>>> Usage"
>>>>>>> after 4.1 "RTP Header Usage" and include at least this item =
there.
>>>>>>> I will do this in the next version unless there is a better =
suggestion.
>>>>>>>=20
>>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>>> reasons behind that?
>>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>>> live-encoding scenarios, wherein dependent slice segments should =
be
>> used instead.
>>>>>>> This was added after a discussion (among the authors) on the
>>>>>>> need of whether to specify a payload structure for mixed FU and
>>>>>>> aggregation packets and
>>>>>>> from that discussion we concluded that encoding dependent slice
>>>>>>> segments
>>>>>>> at source coding level already allows for the use cases and
>>>>>>> using of FUs for live-encoding does not make sense. Please let
>>>>>>> us know if you think differently.
>>>>>>>=20
>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>>> differ between the encoder and decoder?
>>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>>> random accessing to a bitstream is performed. However, it would
>>>>>>> not happen in conversational applications where the feedback
>>>>>>> messages may
>>> be used.
>>>>>>> Therefore, to me this would just work just fine. But please
>>>>>>> feel free to make other suggestions.
>>>>>>>=20
>>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>>> be useful, let me come back to that later on.
>>>>>>>>=20
>>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>>=20
>>>>>>>> I have also a number of spelling suggestions for your =
considerations:
>>>>>>>>=20
>>>>>>>> Section 1.1:
>>>>>>>> Replace "community" by "communities"
>>>>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>>>>> suggestion (for the next version).
>>>>>>>=20
>>>>>>>> Section 1.1.1:
>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>>> the interpolation filter"
>>>>>>> [YK] Thanks - done.
>>>>>>>=20
>>>>>>>> Replace "skipping the transform coding" by "skipping the =
transform"
>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>>> coding)
>>>>>>>>=20
>>>>>>> [YK] Done.
>>>>>>>=20
>>>>>>>> Section 1.1.2:
>>>>>>>> Replace:
>>>>>>>> "2) An indication of whether there is any parameter set within
>>>>>>>> the current coded video sequence that updates another
>>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>>> by:
>>>>>>>> "2) An indication of whether there is no parameter set update
>>>>>>>> in the coded video sequence."
>>>>>>>> since that is what no_parameter_set_update_flag in HEVC =
indicates.
>>>>>>>>=20
>>>>>>> [YK] Changed the wording to "An indication of whether there is
>>>>>>> no parameter set within the current coded video sequence that
>>>>>>> updates another parameter set of the same type preceding in
>>>>>>> decoding
>>> order."
>>>>>>>=20
>>>>>>>> Section 4.7:
>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
>>>>>>>> and "FU
>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload =
header.
>>>>>>>>=20
>>>>>>> [YK] Good point again. I will change the field name to be =
"FuType".
>>>>>>>=20
>>>>>>>> Section 6:
>>>>>>>> Replace "recovery" by "recover"
>>>>>>> [YK] Done.
>>>>>>>=20
>>>>>>>> Section 7.1:
>>>>>>>> Replace "level-id" by "level-idc"
>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of =
"idc".
>>>>>>>=20
>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>>> [YK] Done.
>>>>>>>=20
>>>>>>>> Section 8:
>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>>> "Assigned in this memo".
>>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>>> paragraph of Section
>>>>>>>> 8 since the memo is about HEVC.
>>>>>>> [YK] Good catch again. Changed.
>>>>>>>=20
>>>>>>>> Section 8.1:
>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>>> contained in the FCI field"
>>>>>>> [YK] Another good catch. Changed.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Best Regards,
>>>>>>>> Rickard Sj=F6berg
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: payload-bounces@ietf.org
>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>>> To: payload@ietf.org
>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>>> payload format
>>>>>>>>=20
>>>>>>>> Dear All,
>>>>>>>>=20
>>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as =
follows:
>>>>>>>>=20
>>>>>>>> Version 02:
>>>>>>>> URL:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>> h265-02.txt
>>>>>>>> Htmlized:
>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>>> Diff:
>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>> 5-
>>>>>>>> 02
>>>>>>>>=20
>>>>>>>> Version 03:
>>>>>>>> URL:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>> h265-03.txt
>>>>>>>> Htmlized:
>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>>> Diff:
>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>> 5-
>>>>>>>> 03
>>>>>>>>=20
>>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>>> worked hard to try to make the design complete, from both the
>>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>>> to version 02, version
>>>>>>>> 03 only contains a correction of the email address of an =
author.
>>>>>>>>=20
>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>>> other standards bodies such as 3GPP rely on the payload format
>>>>>>>> for support of H.265/HEVC in RTP based video services, we need
>>>>>>>> to progress this draft relatively quickly.
>>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>>> interested parties and also request for the WG status of this =
draft.
>>>>>>>>=20
>>>>>>>> BR, YK (on behalf of the authors)
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> payload mailing list
>>>> payload@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/payload
>>>> _______________________________________________
>>>> payload mailing list
>>>> payload@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>=20


From thdavies@cisco.com  Fri Jul  5 07:20:55 2013
Return-Path: <thdavies@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE921F9FE1 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 07:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfcXpTcAnU9k for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 07:20:50 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3167911E8104 for <payload@ietf.org>; Fri,  5 Jul 2013 07:20:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37976; q=dns/txt; s=iport; t=1373034048; x=1374243648; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gSCdyrJgmX82f2l54FEyODO5Lr5hMj5/oRM/8joIfTo=; b=gvLUpaKlCXJFMMWt2UOfH8j/Syrr2ZjNDYj7bFx6gF2dusahPT6SuOLy z5pM/bJYddjMwecHNrftY1b6oQWoMuzSKDcp0FjEQ+6L+4caDTLuKeJ3c ooD1IxoaAAPzTe9z8XO1zYuvs9FytYQg+BTwuNva4rfGkHURN4JlFvLiX E=;
X-IronPort-AV: E=Sophos;i="4.87,1001,1363132800"; d="scan'208";a="84001183"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 05 Jul 2013 14:20:45 +0000
Received: from [10.47.196.175] ([10.47.196.175]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r65EKhiw005953; Fri, 5 Jul 2013 14:20:43 GMT
Message-ID: <51D6D62E.2090705@cisco.com>
Date: Fri, 05 Jul 2013 15:20:30 +0100
From: Thomas Davies <thdavies@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de>
In-Reply-To: <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 14:20:55 -0000

Dear Thomas

On your first point, the decoder always has to be told there is missing 
data. I don't see much different or fancy in the interface between the 
two cases. Usually error concealment must be addressed both within the 
codec (because of reference dependencies) and also in the application 
(because of display and call-management/error response functionality). 
That's surely a very minor issue.

On the second point, the context we are considering in our proposal is 
where FUs are being used, in the circumstances Mo set out, and providing 
some level of sub-frame resilience where possible in that case. If your 
assumption is that FUs are not being used, and re-writing is 
possible/desirable, you will certainly conclude that FUs should not be 
used. Since we concluded that FUs should not be discouraged, it seems 
reasonable to consider adding features which make them more resilient 
when they are.

best regards

Thomas

On 05/07/13 10:34, Thomas Schierl wrote:
> Dear Ye-Kui, all,
>
> Further I would tentatively assume that you can use the slice segment address in the dependent slice fragment header for the same degree of error resilience as the new-FU header, if you put a tile into a dependent slice. And this part would be understood by the decoder itself, which should be able to do the error resilience on codec level. Without fancy interfaces into the decoder, etc.
>
> A point in the discussion which seems to be missing is that the rewriting of a single slice into multiple dependent slice fragments (including also one independent slice fragment) can be done at very low processing costs, as shown during the standardization of HEVC.
>
> Thomas
> --
> Thomas Schierl
> Fraunhofer HHI
>
> Am 04.07.2013 um 19:59 schrieb "Wang, Ye-Kui"<yekuiw@qti.qualcomm.com>:
>
>> Hi Thomas,
>>
>> Thanks for the clarification - I think now understand your scheme better.
>>
>> So you did not intent to encapsulate only entire tiles into packets, though that would obviously be more error resilient as you won't encounter the problem where a part of a tile gets lost and the received rest becomes useless. Rather, one tile may be carried in two (or even more) packets.
>>
>> I think I was confused by the suggested language such as "If a fragmentation unit is lost, tiles in the lost fragmentation unit are also lost. However, tiles which are successfully received in their entirety can be decoded if their slice segment header containing tile offsets is successfully received, despite lost fragmentation units.", from where I got an impression that an FU includes entire tiles.
>>
>> As seen from other discussions, it is very questionable how big a penalty would be when an encoder tries to splitting encoded data into separate NAL units (slices or dependent slices) for MTU size matching, even for large CTB sizes - that's the reason why the JCT-VC later decided to remove the fine-granularity slice feature.
>>
>> Let's tentatively assume that overall penalty and the overhead of the new-FU approach are roughly equivalent, and take into account latest comments from Mo and Stephan, do we see an advantage of the new-FU approach compared to using dependent slices?
>>
>> I am not trying to conclude yet - just try to (very briefly) summarize the situation so far at least for myself.  We should certainly have more discussions - preferable involving more people who care about this payload format.
>>
>> BR, YK
>>
>>> -----Original Message-----
>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>> Sent: Thursday, July 04, 2013 9:23 AM
>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sjöberg; Stephan Wenger;
>>> Paul Bright-Thomas (paubrigh)
>>> Cc: payload@ietf.org
>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
>>> format
>>>
>>> Hi Ye-Kui
>>>
>>> Thank you for the clarification - I understand your point a bit better now.
>>>
>>> With the proposed scheme there is no need for the RTP packetizer to parse
>>> slice headers or identify tile boundaries. All it needs to do is to keep track of the
>>> offset of the start of the payload to the beginning of the NALU and put this into
>>> the field. It needs to know this offset anyway. The packetizer is completely
>>> dumb.
>>>
>>> The point is that a decoder wishing to do error resilience can parse the slice
>>> header and identify the tile boundaries in the case that a packet goes missing,
>>> for tiles that occur in the same frame but after the packet that is lost. The
>>> decoder can compare the tile offsets with the FU offsets to work out what data
>>> is missing.
>>>
>>> Re dependent slices, there are indirect overheads as well, which come from
>>> having to quantize the packet size to a whole number of tiles, plus you have to
>>> manage the encoder to match the MTU size. The granularity of tiles you need
>>> for your parallel processing may not match the granularity you need to fit in
>>> the MTU very well.
>>>
>>> Best regards
>>>
>>> Thomas
>>>
>>>
>>> -----Original Message-----
>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>> Sent: 04 July 2013 16:34
>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sjöberg; Stephan
>>> Wenger; Paul Bright-Thomas (paubrigh)
>>> Cc: payload@ietf.org
>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
>>> format
>>>
>>> Hi Thomas,
>>>
>>> My point was really about using dependent slices, not about 1 or N tiles per
>>> packets (sorry that I did not make that clearer). Whatever strategy you would
>>> like to do in terms of the number of tiles in a packet, using dependent slices can
>>> do the same, as each dependent slice can include 1 or N tiles.
>>>
>>> I see the following advantages with the approach using dependent slices
>>> instead of defining new FUs:
>>>
>>> - First of all, no need to define new payload structures.
>>>
>>> - The RTP packetizer does not need to parse slice headers to identify boundaries
>>> of tiles within a coded slice, as tiles of one SLICE are already in separate NAL
>>> units each containing a DEPENDENT SLICE.
>>>
>>> - No additional overhead in packetization (the 1-byte FU header and the 2- or
>>> 4-byte FU offset). The overhead of the short slice header for dependent slice
>>> NAL units is compensated by less number of tile entry offsets signalled, as the
>>> entry offset of the first tile in each NAL unit is not signalled in the slice header.
>>> Using dependent slices would need more two-byte NAL unit headers, while
>>> using new FUs would need more two-byte packet payload headers, and the
>>> overhead bits here are the same for both methods.
>>>
>>> Am I missing anything here?
>>>
>>> BR, YK
>>>
>>>> -----Original Message-----
>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>> Sent: Thursday, July 04, 2013 1:49 AM
>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sjöberg; Stephan
>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>
>>>> Yes, we did think about one tile per packet or N tiles per packet,
>>>> also: I guess that is where we started from. Then you could indeed
>>>> align missing tiles with missing sequence numbers.
>>>>
>>>> The issue is that you need to guarantee that you are doing this for it
>>>> to be useful, and the decoder needs to know that this is guaranteed
>>>> through some form of other signalling. However, the bitstream chunk
>>>> associated to a tile is extremely variable, and many tile chunks would
>>>> be very small. So there is significant packetization overhead for them if there
>>> is one tile per packet.
>>>> Having N>1 reduces this overhead, but it is still there and as N
>>>> increases you run the risk of breaking the MTU size which then
>>>> requires that you have to re- encode to fit things in and meet the
>>>> guarantee. There is definitely no time to re-encode whole tiles,
>>>> especially if you are already using them for parallelization. Thus you
>>>> might have to break the guarantee and fragment the packet anyhow, losing
>>> the resilience.
>>>> The advantage that we see with the proposal is that you can get fairly
>>>> similar resilience to regular slice MTU-size matching, but with much
>>>> lower overheads as you can have a single regular slice header per frame, yet
>>> have a "dumb"
>>>> packetization process and no need to re-encode to hit MTU targets. In
>>>> H264 MTU matching usually means re-encoding just one or two 16x16 MBs.
>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you are
>>>> doing tiles then you can get tiny "dangling slices" at the end of a
>>>> tile, which means more small packets.
>>>>
>>>> Best regards
>>>>
>>>> Thomas
>>>>
>>>> -----Original Message-----
>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>> Sent: 04 July 2013 07:02
>>>> To: Mo Zanaty (mzanaty); Rickard Sjöberg; Thomas Davies (thdavies);
>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>> payload format
>>>>
>>>>
>>>> An interesting idea. Using dependent slices (again :-) together with
>>>> tiles would do the trick too (each tile in one dependent slice, and
>>>> then each dependent slice NAL unit in one single NAL unit packet).
>>>>
>>>> Have you guys done an analysis comparing the pros and cons of the two
>>>> alternative approaches?
>>>>
>>>> BR, YK
>>>>
>>>>> -----Original Message-----
>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>>>> To: Rickard Sjöberg; Wang, Ye-Kui; Thomas Davies (thdavies); Stephan
>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>
>>>>> Thomas, Paul and I have been working on improving packet loss
>>>>> resilience using fragments and tiles. I mentioned this to Stephan at
>>>>> IETF 86 in Orlando, and promised to have draft text ready before
>>>>> Berlin. Here is the proposed text along with an overview of the rationale.
>>>>>
>>>>> Rationale:
>>>>>
>>>>> 1. Resilience to packet loss requires independent slices or tiles.
>>>>> Since independence requires restrictions on some coding tools, both
>>>>> potentially incur slight penalties in coding efficiency, with a
>>>>> smaller penalty
>>>> for tiles.
>>>>> 2. Fragmentation in a higher layer like RTP can have several
>>>>> advantages over similar features in a codec layer like slices
>>>>> (independent or
>>>> dependent).
>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity while
>>>>> slices have much larger (CTB or tile) granularity. It also has less
>>>>> slice segment header overhead, especially for independent slices.
>>>>> This can impact the efficiency of the packetized stream in terms of
>>>>> both bits and
>>>> packets per second.
>>>>> b. Performance: Encoders must perform extra processing to limit
>>>>> slice sizes, which can impact encoder performance. Some
>>>>> implementations speculatively end a slice based on computed
>>>>> statistics (which aggravates a.), while others recode a slice if the
>>>>> size is exceeded (which
>>>> aggravates b.).
>>>>> c. Decoupling: Not all encoders will support limiting slice size to MTU size.
>>>>> Applications (for live or stored content) using such encoders can
>>>>> still support MTU limits using RTP fragmentation since it is
>>>>> decoupled from
>>>> the encoder.
>>>>> d. Multi-party: The encoded content may go to multiple receivers
>>>>> with different MTUs. RTP fragmentation can handle this with
>>>>> lightweight repacketization at middle boxes whereas slices incur
>>> heavyweight transcoding.
>>>>> 3. Combining fragmentation and tiles can improve resilience while
>>>>> retaining the above advantages, if fragments are enhanced to contain
>>>>> offsets (similar to IP fragmentation). This is described in the
>>>>> proposed draft text below, which would immediately follow section
>>>>> 4.7
>>>> Fragmentation Units.
>>>>> Draft Text:
>>>>>
>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>>>
>>>>> If a fragmented NAL unit contains tiles, its slice segment header
>>>>> contains offsets to the data of each tile. These offsets can be used
>>>>> for random access to any tile for parallel processing, region of
>>>>> interest extraction, and resilience to errors in other tiles. These
>>>>> offsets can also be used to provide resilience to packet loss, in
>>>>> conjunction with fragment offsets contained in two types of
>>>>> fragmentation
>>>> units: FU-A2 and FU-A4.
>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
>>>>> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>>>> indicates the total number of bytes in all prior FU payloads of the
>>>>> fragmented
>>>> NAL unit.
>>>>>
>>>>>     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
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |      FU-A2 NAL HDR (type=52)  |   FU header   | FU-A2 offset  |
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    | FU-A2 offset  |     DONL (optional)           |               |
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>>>    |                                                               |
>>>>>    |                         FU payload                            |
>>>>>    |                                                               |
>>>>>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |                               :...OPTIONAL RTP padding        |
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>>                   Figure X   RTP payload format for FU-A2
>>>>>
>>>>>
>>>>>     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
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |      FU-A4 NAL HDR (type=53)  |   FU header   | FU-A4 offset  |
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |      FU-A4 offset                             | DONL(optional)|
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    | DONL(optional)|                                               |
>>>>>    +-+-+-+-+-+-+-+-+         FU payload                            |
>>>>>    |                                                               |
>>>>>    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>    |                               :...OPTIONAL RTP padding        |
>>>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>
>>>>>                   Figure Y   RTP payload format for FU-A4
>>>>>
>>>>>
>>>>> Since the offset of the first FU payload of a fragmented NAL unit is
>>>>> zero, and the Start (S) bit in the FU header is sufficient to
>>>>> indicate this, the first fragmentation unit of a fragmented NAL unit
>>>>> SHOULD use FU-A, but MAY use
>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>>>> non-zero offset. The Start
>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>>>> contains a non- zero offset, and MUST be set if it contains a zero offset.
>>>>>
>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation unit are also
>>> lost.
>>>>> However, tiles which are successfully received in their entirety can
>>>>> be decoded if their slice segment header containing tile offsets is
>>>>> successfully received, despite lost fragmentation units. Fragment
>>>>> offsets in FU-A2 or FU-A4 are required in order to recover from loss
>>>>> of prior fragmentation units and continue decoding subsequent tiles.
>>>>>
>>>>> The following heuristic SHOULD be applied to determine if the lost
>>>>> fragmentation units are all part of the same fragmented NAL unit as
>>>>> subsequently received fragmentation units with identical RTP
>>>>> timestamps and identical values of NAL unit header layer ID and temporal
>>> ID.
>>>>> 1. Let N be the number of missing sequence numbers between two
>>>>> received fragmentation units with known offsets.
>>>>> 2. Let P be the FU payload size of the first of the two received FUs.
>>>>> 3. Let D be the difference in the offsets, minus P.
>>>>>    (This is the number of missing FU payload bytes.) 4. Let E be N times P.
>>>>>    (This is the estimated number of missing FU payload bytes.) 5.
>>>>> Let ERROR be the absolute difference between D and E, divided by D.
>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
>>>>> fragmented NAL unit, otherwise it is unlikely.
>>>>>
>>>>> Cheers,
>>>>> Mo
>>>>>
>>>>> -----Original Message-----
>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>>> Behalf Of Rickard Sjöberg
>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>>>> Cc: payload@ietf.org
>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I wrote slices and not dependent slices since the slice granularity
>>>>> and slice/tile rule applies to both slices and dependent slices.
>>>>> Sorry for the confusion. I will now use 'independent slices' and
>>>>> 'dependent slices' to distinguish between them.
>>>>>
>>>>> I do not question the use of independent slices, I find them useful
>>>>> in some applications.
>>>>>
>>>>> But the current RTP payload text says:
>>>>>
>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>       video telephony, video conferencing, live streaming and live
>>>>>       broadcast, in which cases dependent slice segments SHOULD be used
>>>>>       when a slice should be transported in multiple RTP packets."
>>>>>
>>>>> I believe that FUs are a viable option to dependent slices for the
>>>>> reasons I listed in my previous e-mail and think that we should not
>>>>> recommend dependent slices over FUs but leave it to the implementer.
>>>>>
>>>>> BR
>>>>> Rickard
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>>> Behalf Of Wang, Ye-Kui
>>>>> Sent: den 3 juli 2013 20:43
>>>>> To: Thomas Davies; Stephan Wenger
>>>>> Cc: payload@ietf.org
>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I drafted an email replying directly to Rickard but did not finish
>>>>> and there was a meeting (and then Stephan's and Thomas' emails came).
>>>>>
>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>>>> slices, not FUs vs dependent slices, while the recommendation in the
>>>>> draft is recommending use of dependent slices over FUs in
>>>>> live-encoding scenarios (so this answers Thomas question: the
>>>>> intention was
>>>> dependent slices ).
>>>>> In any case, it does not make much sense to try MTU size matching
>>>>> and at the same time use either dependent slices or FUs, because
>>>>> dependent slices and FUs should not be used when there are
>>>>> considerable packet losses, while MTU size matching should be
>>>>> applied when there are
>>>> considerable packet losses.
>>>>> For live encoding, whenever splitting of a regular slice is needed,
>>>>> the splitting can be done by the encoder using dependent slices -
>>>>> and the encoder has more knowledge and is more powerful than the RTP
>>>>> packetizer and thus can do a better job for the splitting.
>>>>>
>>>>> BR, YK
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>>>> On Behalf Of Thomas Davies
>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>>>> To: Stephan Wenger
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>
>>>>>> Hi Stephan
>>>>>>
>>>>>> I think I agree with Rickard.
>>>>>>
>>>>>> I think the text in question states a preference for _dependent_
>>>>>> slice segments, which have no error resiliency advantage over FUs.
>>>>>> Is this just a
>>>>> typo?
>>>>>> <snip>
>>>>>>
>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>        video telephony, video conferencing, live streaming and live
>>>>>>        broadcast, in which cases dependent slice segments SHOULD be used
>>>>>>        when a slice should be transported in multiple RTP packets.
>>>>>>
>>>>>>
>>>>>>
>>>>>> </snip>
>>>>>>
>>>>>> In general FUs may be used where error conditions are known to be
>>>>>> benign, for greater efficiency, and also where for whatever reason
>>>>>> the encoder cannot support MTU matching.
>>>>>>
>>>>>> We also are formulating some more general comments on this area
>>>>>> which we hope to provide more fully soon.
>>>>>>
>>>>>> best regards
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>>>> Hi Rickard,
>>>>>>> Commenting only on slices vs. FUs.
>>>>>>> The preference for slices over FUs, historically, was pushed by
>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>>>> and you can recover at the next slice boundary; loose an FU, and
>>>>>>> you have to wait for the next slice header and throw away all
>>>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>>>> private, managed IP-network, which may have other constraints,
>>>>>>> but are not the IETF's main
>>>>>>> concern.) To set your remarks into context, let's first
>>>>>>> understand what we are talking
>>>>>>> about: the cost of slices is the overhead stemming from the
>>>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>>>> from the packet headers themselves.  And, of course,
>>>>>>> implementation complexity, but we should not be in the business
>>>>>>> to encourage implementor
>>>>> laziness when
>>>>>>> there would be a more complex, but better suited tool available.    The
>>>>>>> additional packetization overhead is only incurred when, as a
>>>>>>> result of incompetently filled packets (which, I agree, is more
>>>>>>> likely with
>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>>>> needs to be inserted.  You may remember a quick analysis of mine
>>>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>>>> that the practical impact is negligible in almost all non-tile
>>>>>>> scenarios (mostly because an additional overhead of 50 bytes or
>>>>>>> so--3% or less of the coded picture size) is incurred
>>>>>>> statistically only rarely (only in those cases where an
>>>>>>> additional packet would need to be generated because of the
>>>>>>> video coding related overhead for the use of slices).  The
>>>>>>> prediction overhead of the use of regular slices has been shown
>>>>>>> to be substantial--the price one needs to pay for independent
>>>>>>> decodability--but for entropy slices that overhead virtually
>>>>> does not exist.
>>>>>>> With respect to tiles, I think you have a point though,
>>>>>>> especially when considering the type of massive parallel
>>>>>>> implementations for relatively small picture sizes some folks have been
>>> considering.
>>>>>>> OTOH, because FUs are trivial to implement--some say in contrast
>>>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>>>> error prone scenarios is a bad idea if you could use slices (but
>>>>>>> for reasons like the tile connection you mentioned), the draft
>>>>>>> should IMO continue to set a preference for the use of regular
>>>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>>>> implementer
>>>> laziness.
>>>>>>> However, this is the IETF.  We don't have to worry about the
>>>>>>> word-count of explanatory language.  In fact, explaining such
>>>>>>> complex tradeoffs and relationships is generally encouraged here.
>>>>>>> So let's
>>>>> just do that:
>>>>>>> express a preference of the use of regular slices (SHOULD) when
>>>>>>> you expect losses and can use them (real-time encoding, no
>>>>>>> tiling structure that would lead to unacceptable packetization
>>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
>>>>>>> Accompanied by a more coherently expressed analysis.
>>>>>>> Stephan
>>>>>>>
>>>>>>>
>>>>>>> On 7.3.2013 06:46 , "Rickard
>>>>>>> Sjöberg"<rickard.sjoberg@ericsson.com>
>>>>> wrote:
>>>>>>>> Hi Ye-Kui,
>>>>>>>>
>>>>>>>> Thanks for your feedback on my comments, your suggestions look
>>>>>>>> good to
>>>>>> me.
>>>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
>>>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>>>> aggregation. The spatial granularity of slices was 16x16 pixels
>>>>>>>> in H.264 but is typically
>>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>>>>>> units that are 16x larger. This may lead to a larger number of
>>>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>>>> that makes the slice granularity equal to the tile granularity
>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>>>> easier to implement since you do not need to care about when to
>>>>>>>> break your slice to not exceed the MTU size limit. I think both
>>>>>>>> slices and FUs has their merits and the choice between them for
>>>>>>>> live-encoding should be left for
>>>>> the implementer.
>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
>>>>>>>> and the POC MSB sync issue, I agree that this is a corner case
>>>>>>>> that we probably will not see much of in practice. I have no
>>>>>>>> text change suggestion at the moment.
>>>>>>>>
>>>>>>>> BR
>>>>>>>> Rickard
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>>>> Sent: den 24 juni 2013 01:00
>>>>>>>> To: Rickard Sjöberg; payload@ietf.org
>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>> format
>>>>>>>>
>>>>>>>> Hi Rickard,
>>>>>>>>
>>>>>>>> Thanks for the careful review and the comments. Please see inline
>>> below.
>>>>>>>> BR, YK
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Rickard Sjöberg [mailto:rickard.sjoberg@ericsson.com]
>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>> format
>>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03
>>>>>>>>> and have some questions/comments.
>>>>>>>>>
>>>>>>>>> My first question is what extensions of HEVC that
>>>>>>>>> draft-schierl-payload-rtp-
>>>>>>>>> h265 is intended to cover? The draft mentions "future scalable
>>>>>>>>> or 3D  video coding  extensions  of  this specification", what
>>>>>>>>> extensions do you refer to?
>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>>>> payload specification?
>>>>>>>>>
>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>>>> sort of copy-and-paste error. Thanks for the good catching. No,
>>>>>>>> there is no intention to cover HEVC extensions in this payload
>>>>>>>> specification, though we intentionally to have the
>>>>>>>> depacketization process and the use with feedback messages to
>>>>>>>> work for HEVC scalability
>>>>> and 3DV extensions.
>>>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>>>> pass picture timing SEI messages and decoding unit information
>>>>>>>>> SEI messages to the decoder"?
>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>>>> specified by the video coding spec to the video decoders. This
>>>>>>>> is emphasized here for the two timing related SEI messages
>>>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>>>> checking for the bitstream that was possible would be disabled,
>>>>>>>> and also the information related to frame
>>>>>> doubling or tripping would be lost.
>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
>>>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
>>>>>>>> to put this as a packetization rule is to put it as part of the
>>>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>>>> belongs to an overview wherein normative language (even "MAY")
>>>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>>>> Header
>>>> Usage"
>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item there.
>>>>>>>> I will do this in the next version unless there is a better suggestion.
>>>>>>>>
>>>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>>>> reasons behind that?
>>>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>>>> live-encoding scenarios, wherein dependent slice segments should be
>>> used instead.
>>>>>>>> This was added after a discussion (among the authors) on the
>>>>>>>> need of whether to specify a payload structure for mixed FU and
>>>>>>>> aggregation packets and
>>>>>>>> from that discussion we concluded that encoding dependent slice
>>>>>>>> segments
>>>>>>>> at source coding level already allows for the use cases and
>>>>>>>> using of FUs for live-encoding does not make sense. Please let
>>>>>>>> us know if you think differently.
>>>>>>>>
>>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>>>> differ between the encoder and decoder?
>>>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>>>> random accessing to a bitstream is performed. However, it would
>>>>>>>> not happen in conversational applications where the feedback
>>>>>>>> messages may
>>>> be used.
>>>>>>>> Therefore, to me this would just work just fine. But please
>>>>>>>> feel free to make other suggestions.
>>>>>>>>
>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>>>> be useful, let me come back to that later on.
>>>>>>>>>
>>>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>>>
>>>>>>>>> I have also a number of spelling suggestions for your considerations:
>>>>>>>>>
>>>>>>>>> Section 1.1:
>>>>>>>>> Replace "community" by "communities"
>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>>>>>> suggestion (for the next version).
>>>>>>>>
>>>>>>>>> Section 1.1.1:
>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>>>> the interpolation filter"
>>>>>>>> [YK] Thanks - done.
>>>>>>>>
>>>>>>>>> Replace "skipping the transform coding" by "skipping the transform"
>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>>>> coding)
>>>>>>>>>
>>>>>>>> [YK] Done.
>>>>>>>>
>>>>>>>>> Section 1.1.2:
>>>>>>>>> Replace:
>>>>>>>>> "2) An indication of whether there is any parameter set within
>>>>>>>>> the current coded video sequence that updates another
>>>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>>>> by:
>>>>>>>>> "2) An indication of whether there is no parameter set update
>>>>>>>>> in the coded video sequence."
>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC indicates.
>>>>>>>>>
>>>>>>>> [YK] Changed the wording to "An indication of whether there is
>>>>>>>> no parameter set within the current coded video sequence that
>>>>>>>> updates another parameter set of the same type preceding in
>>>>>>>> decoding
>>>> order."
>>>>>>>>> Section 4.7:
>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
>>>>>>>>> and "FU
>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload header.
>>>>>>>>>
>>>>>>>> [YK] Good point again. I will change the field name to be "FuType".
>>>>>>>>
>>>>>>>>> Section 6:
>>>>>>>>> Replace "recovery" by "recover"
>>>>>>>> [YK] Done.
>>>>>>>>
>>>>>>>>> Section 7.1:
>>>>>>>>> Replace "level-id" by "level-idc"
>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc".
>>>>>>>>
>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>>>> [YK] Done.
>>>>>>>>
>>>>>>>>> Section 8:
>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>>>> "Assigned in this memo".
>>>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>>>> paragraph of Section
>>>>>>>>> 8 since the memo is about HEVC.
>>>>>>>> [YK] Good catch again. Changed.
>>>>>>>>
>>>>>>>>> Section 8.1:
>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>>>> contained in the FCI field"
>>>>>>>> [YK] Another good catch. Changed.
>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Rickard Sjöberg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: payload-bounces@ietf.org
>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>>>> To: payload@ietf.org
>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>>>> payload format
>>>>>>>>>
>>>>>>>>> Dear All,
>>>>>>>>>
>>>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as follows:
>>>>>>>>>
>>>>>>>>> Version 02:
>>>>>>>>> URL:
>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>> h265-02.txt
>>>>>>>>> Htmlized:
>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>>>> Diff:
>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h26
>>>>>>>>> 5-
>>>>>>>>> 02
>>>>>>>>>
>>>>>>>>> Version 03:
>>>>>>>>> URL:
>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>> h265-03.txt
>>>>>>>>> Htmlized:
>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>>>> Diff:
>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h26
>>>>>>>>> 5-
>>>>>>>>> 03
>>>>>>>>>
>>>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>>>> worked hard to try to make the design complete, from both the
>>>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>>>> to version 02, version
>>>>>>>>> 03 only contains a correction of the email address of an author.
>>>>>>>>>
>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>>>> other standards bodies such as 3GPP rely on the payload format
>>>>>>>>> for support of H.265/HEVC in RTP based video services, we need
>>>>>>>>> to progress this draft relatively quickly.
>>>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>>>> interested parties and also request for the WG status of this draft.
>>>>>>>>>
>>>>>>>>> BR, YK (on behalf of the authors)
>>>>>>>>> _______________________________________________
>>>>>>>>> payload mailing list
>>>>>>>>> payload@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> payload mailing list
>>>>>>>> payload@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>> _______________________________________________
>>>>>>> payload mailing list
>>>>>>> payload@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>> _______________________________________________
>>>>>> payload mailing list
>>>>>> payload@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>> _______________________________________________
>>>>> payload mailing list
>>>>> payload@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>> _______________________________________________
>>>>> 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 thomas.schierl@hhi.fraunhofer.de  Fri Jul  5 07:39:10 2013
Return-Path: <thomas.schierl@hhi.fraunhofer.de>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7A11E812B for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 07:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU-easZIEet2 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 07:39:04 -0700 (PDT)
Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED1DC11E80F4 for <payload@ietf.org>; Fri,  5 Jul 2013 07:39:03 -0700 (PDT)
X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0
Received: from ic-pc009m.ic.tu-berlin.de (ic-pc009m.ic.tu-berlin.de [130.149.228.97]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id 918FE186802B; Fri,  5 Jul 2013 16:39:02 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>
In-Reply-To: <51D6D62E.2090705@cisco.com>
Date: Fri, 5 Jul 2013 16:38:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com>
To: Thomas Davies <thdavies@cisco.com>
X-Mailer: Apple Mail (2.1508)
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-7.0.0.1014-19994.006
X-TM-AS-Result: No--40.149-11.0-31-10
X-imss-scan-details: No--40.149-11.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TMASE-MatchedRID: 8HTFlOrbAtGoB6BkKpx1kR3EEAbn+GRbIaVkFIrQFhsL/50zj0KL7DKC ++TafYOREkrLu4ziNa+kXfhYuzAsILkv8Y95Xhh/CFaAixm5eU+U1za3Jug9wpPOTcYj4US4gwO 8VyXMhRiWUaXKwoXzYcsrFLh+DRrPUkJo0fO4fjfx5KZMlKYS/dZKsq3DGpalIbxYwbCxGTTLVj XXbbt89e/spC84eMUo08Y2psbcJpVkGxL9+NfcsdOEZs/2oH3cjiWciALpTNMbQ3XP/Jy4snbpp cmWmfjkH5oUv1OBV8HczQ8bBFUHNIT3OBUyTeleJrUxoq6hvw+MAJiPkwmsiWecrqZc3vabL6a+ FayCasCL6ipxaEPINax/hQDzwli6ZF6ysdFjt0pDU5wIS9P5t7fAPAnSysrqh8BhJvgqWBmsqnE kU6FrjJ6sqMiYW1Ae4BcUc1D2EdE0sh08d+KcpwwfhKwa9GwDMVx/3ZYby79u4FknyqyshLD8Yk lvSqaseV1sjgdoraSSocsiO6ApLA7Y8CdzmK6YatGCGdi/nWrtMsBKGEjbqS62hjZS0WoYcQ2ah 832eukDTDGMzJypOcV93Ntn+QJTusc6DiTAbfH9vE/QVDV5IeNlVbqPGsKi47E6rstCUYsZ10NZ ZkVfEnf8GA9hkav6YtfgFc3n2b2EBu8e5T8phYKWRoCzKVjWm+AnKHZE1eK1YUw9VHYKvGAYUKE 3f0S+vWGG5+60R6sAosJtvlK5hZ8H7IRkmk14Pey2g5E3u1sYXAQYNFfm7C4RpcoQGaIaG2Mkge eC0THZnqdsTEJp5Zn78AdcdK5fHGxbnWywHBgksSBZTGCrwmNn8XPiALIbp2c3EY8h4cmrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0=
X-IMSS-DKIM-White-List: No
X-alterMIME: Yes
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 14:39:11 -0000

Dear Thomas,

For the error resilience in the case of slices or dependent slices, =
which do match with tiles, I do not think an additional pointer =
information in the FU header does improve the error resilience =
capabilities over a system without those information.=20

I think I did not exclude the use of FUs even for dependent slice =
fragments, but I would not require an additional mechanism to those, as =
stated in my email before.

Thomas
--

Dr.-Ing. Thomas Schierl

Head of Multimedia Communications Group
Image Processing Department
thomas.schierl@hhi.fraunhofer.de

Tel.:  +49 30 31002-227
Fax:  +49 30 31002-190
Skype:  thomas.schierl

Fraunhofer HHI - Heinrich Hertz Institute
Einsteinufer 37, 10587 Berlin, Germany
http://www.hhi.fraunhofer.de/ip/mc

Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:

> Dear Thomas
>=20
> On your first point, the decoder always has to be told there is =
missing data. I don't see much different or fancy in the interface =
between the two cases. Usually error concealment must be addressed both =
within the codec (because of reference dependencies) and also in the =
application (because of display and call-management/error response =
functionality). That's surely a very minor issue.
>=20
> On the second point, the context we are considering in our proposal is =
where FUs are being used, in the circumstances Mo set out, and providing =
some level of sub-frame resilience where possible in that case. If your =
assumption is that FUs are not being used, and re-writing is =
possible/desirable, you will certainly conclude that FUs should not be =
used. Since we concluded that FUs should not be discouraged, it seems =
reasonable to consider adding features which make them more resilient =
when they are.
>=20
> best regards
>=20
> Thomas
>=20
> On 05/07/13 10:34, Thomas Schierl wrote:
>> Dear Ye-Kui, all,
>>=20
>> Further I would tentatively assume that you can use the slice segment =
address in the dependent slice fragment header for the same degree of =
error resilience as the new-FU header, if you put a tile into a =
dependent slice. And this part would be understood by the decoder =
itself, which should be able to do the error resilience on codec level. =
Without fancy interfaces into the decoder, etc.
>>=20
>> A point in the discussion which seems to be missing is that the =
rewriting of a single slice into multiple dependent slice fragments =
(including also one independent slice fragment) can be done at very low =
processing costs, as shown during the standardization of HEVC.
>>=20
>> Thomas
>> --
>> Thomas Schierl
>> Fraunhofer HHI
>>=20
>> Am 04.07.2013 um 19:59 schrieb "Wang, =
Ye-Kui"<yekuiw@qti.qualcomm.com>:
>>=20
>>> Hi Thomas,
>>>=20
>>> Thanks for the clarification - I think now understand your scheme =
better.
>>>=20
>>> So you did not intent to encapsulate only entire tiles into packets, =
though that would obviously be more error resilient as you won't =
encounter the problem where a part of a tile gets lost and the received =
rest becomes useless. Rather, one tile may be carried in two (or even =
more) packets.
>>>=20
>>> I think I was confused by the suggested language such as "If a =
fragmentation unit is lost, tiles in the lost fragmentation unit are =
also lost. However, tiles which are successfully received in their =
entirety can be decoded if their slice segment header containing tile =
offsets is successfully received, despite lost fragmentation units.", =
from where I got an impression that an FU includes entire tiles.
>>>=20
>>> As seen from other discussions, it is very questionable how big a =
penalty would be when an encoder tries to splitting encoded data into =
separate NAL units (slices or dependent slices) for MTU size matching, =
even for large CTB sizes - that's the reason why the JCT-VC later =
decided to remove the fine-granularity slice feature.
>>>=20
>>> Let's tentatively assume that overall penalty and the overhead of =
the new-FU approach are roughly equivalent, and take into account latest =
comments from Mo and Stephan, do we see an advantage of the new-FU =
approach compared to using dependent slices?
>>>=20
>>> I am not trying to conclude yet - just try to (very briefly) =
summarize the situation so far at least for myself.  We should certainly =
have more discussions - preferable involving more people who care about =
this payload format.
>>>=20
>>> BR, YK
>>>=20
>>>> -----Original Message-----
>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>> Sent: Thursday, July 04, 2013 9:23 AM
>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan =
Wenger;
>>>> Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>>>> format
>>>>=20
>>>> Hi Ye-Kui
>>>>=20
>>>> Thank you for the clarification - I understand your point a bit =
better now.
>>>>=20
>>>> With the proposed scheme there is no need for the RTP packetizer to =
parse
>>>> slice headers or identify tile boundaries. All it needs to do is to =
keep track of the
>>>> offset of the start of the payload to the beginning of the NALU and =
put this into
>>>> the field. It needs to know this offset anyway. The packetizer is =
completely
>>>> dumb.
>>>>=20
>>>> The point is that a decoder wishing to do error resilience can =
parse the slice
>>>> header and identify the tile boundaries in the case that a packet =
goes missing,
>>>> for tiles that occur in the same frame but after the packet that is =
lost. The
>>>> decoder can compare the tile offsets with the FU offsets to work =
out what data
>>>> is missing.
>>>>=20
>>>> Re dependent slices, there are indirect overheads as well, which =
come from
>>>> having to quantize the packet size to a whole number of tiles, plus =
you have to
>>>> manage the encoder to match the MTU size. The granularity of tiles =
you need
>>>> for your parallel processing may not match the granularity you need =
to fit in
>>>> the MTU very well.
>>>>=20
>>>> Best regards
>>>>=20
>>>> Thomas
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>> Sent: 04 July 2013 16:34
>>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg;=
 Stephan
>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>>>> format
>>>>=20
>>>> Hi Thomas,
>>>>=20
>>>> My point was really about using dependent slices, not about 1 or N =
tiles per
>>>> packets (sorry that I did not make that clearer). Whatever strategy =
you would
>>>> like to do in terms of the number of tiles in a packet, using =
dependent slices can
>>>> do the same, as each dependent slice can include 1 or N tiles.
>>>>=20
>>>> I see the following advantages with the approach using dependent =
slices
>>>> instead of defining new FUs:
>>>>=20
>>>> - First of all, no need to define new payload structures.
>>>>=20
>>>> - The RTP packetizer does not need to parse slice headers to =
identify boundaries
>>>> of tiles within a coded slice, as tiles of one SLICE are already in =
separate NAL
>>>> units each containing a DEPENDENT SLICE.
>>>>=20
>>>> - No additional overhead in packetization (the 1-byte FU header and =
the 2- or
>>>> 4-byte FU offset). The overhead of the short slice header for =
dependent slice
>>>> NAL units is compensated by less number of tile entry offsets =
signalled, as the
>>>> entry offset of the first tile in each NAL unit is not signalled in =
the slice header.
>>>> Using dependent slices would need more two-byte NAL unit headers, =
while
>>>> using new FUs would need more two-byte packet payload headers, and =
the
>>>> overhead bits here are the same for both methods.
>>>>=20
>>>> Am I missing anything here?
>>>>=20
>>>> BR, YK
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>>> Sent: Thursday, July 04, 2013 1:49 AM
>>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>> Yes, we did think about one tile per packet or N tiles per packet,
>>>>> also: I guess that is where we started from. Then you could indeed
>>>>> align missing tiles with missing sequence numbers.
>>>>>=20
>>>>> The issue is that you need to guarantee that you are doing this =
for it
>>>>> to be useful, and the decoder needs to know that this is =
guaranteed
>>>>> through some form of other signalling. However, the bitstream =
chunk
>>>>> associated to a tile is extremely variable, and many tile chunks =
would
>>>>> be very small. So there is significant packetization overhead for =
them if there
>>>> is one tile per packet.
>>>>> Having N>1 reduces this overhead, but it is still there and as N
>>>>> increases you run the risk of breaking the MTU size which then
>>>>> requires that you have to re- encode to fit things in and meet the
>>>>> guarantee. There is definitely no time to re-encode whole tiles,
>>>>> especially if you are already using them for parallelization. Thus =
you
>>>>> might have to break the guarantee and fragment the packet anyhow, =
losing
>>>> the resilience.
>>>>> The advantage that we see with the proposal is that you can get =
fairly
>>>>> similar resilience to regular slice MTU-size matching, but with =
much
>>>>> lower overheads as you can have a single regular slice header per =
frame, yet
>>>> have a "dumb"
>>>>> packetization process and no need to re-encode to hit MTU targets. =
In
>>>>> H264 MTU matching usually means re-encoding just one or two 16x16 =
MBs.
>>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you =
are
>>>>> doing tiles then you can get tiny "dangling slices" at the end of =
a
>>>>> tile, which means more small packets.
>>>>>=20
>>>>> Best regards
>>>>>=20
>>>>> Thomas
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>> Sent: 04 July 2013 07:02
>>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies =
(thdavies);
>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>>=20
>>>>> An interesting idea. Using dependent slices (again :-) together =
with
>>>>> tiles would do the trick too (each tile in one dependent slice, =
and
>>>>> then each dependent slice NAL unit in one single NAL unit packet).
>>>>>=20
>>>>> Have you guys done an analysis comparing the pros and cons of the =
two
>>>>> alternative approaches?
>>>>>=20
>>>>> BR, YK
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); =
Stephan
>>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Thomas, Paul and I have been working on improving packet loss
>>>>>> resilience using fragments and tiles. I mentioned this to Stephan =
at
>>>>>> IETF 86 in Orlando, and promised to have draft text ready before
>>>>>> Berlin. Here is the proposed text along with an overview of the =
rationale.
>>>>>>=20
>>>>>> Rationale:
>>>>>>=20
>>>>>> 1. Resilience to packet loss requires independent slices or =
tiles.
>>>>>> Since independence requires restrictions on some coding tools, =
both
>>>>>> potentially incur slight penalties in coding efficiency, with a
>>>>>> smaller penalty
>>>>> for tiles.
>>>>>> 2. Fragmentation in a higher layer like RTP can have several
>>>>>> advantages over similar features in a codec layer like slices
>>>>>> (independent or
>>>>> dependent).
>>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity =
while
>>>>>> slices have much larger (CTB or tile) granularity. It also has =
less
>>>>>> slice segment header overhead, especially for independent slices.
>>>>>> This can impact the efficiency of the packetized stream in terms =
of
>>>>>> both bits and
>>>>> packets per second.
>>>>>> b. Performance: Encoders must perform extra processing to limit
>>>>>> slice sizes, which can impact encoder performance. Some
>>>>>> implementations speculatively end a slice based on computed
>>>>>> statistics (which aggravates a.), while others recode a slice if =
the
>>>>>> size is exceeded (which
>>>>> aggravates b.).
>>>>>> c. Decoupling: Not all encoders will support limiting slice size =
to MTU size.
>>>>>> Applications (for live or stored content) using such encoders can
>>>>>> still support MTU limits using RTP fragmentation since it is
>>>>>> decoupled from
>>>>> the encoder.
>>>>>> d. Multi-party: The encoded content may go to multiple receivers
>>>>>> with different MTUs. RTP fragmentation can handle this with
>>>>>> lightweight repacketization at middle boxes whereas slices incur
>>>> heavyweight transcoding.
>>>>>> 3. Combining fragmentation and tiles can improve resilience while
>>>>>> retaining the above advantages, if fragments are enhanced to =
contain
>>>>>> offsets (similar to IP fragmentation). This is described in the
>>>>>> proposed draft text below, which would immediately follow section
>>>>>> 4.7
>>>>> Fragmentation Units.
>>>>>> Draft Text:
>>>>>>=20
>>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>>>>=20
>>>>>> If a fragmented NAL unit contains tiles, its slice segment header
>>>>>> contains offsets to the data of each tile. These offsets can be =
used
>>>>>> for random access to any tile for parallel processing, region of
>>>>>> interest extraction, and resilience to errors in other tiles. =
These
>>>>>> offsets can also be used to provide resilience to packet loss, in
>>>>>> conjunction with fragment offsets contained in two types of
>>>>>> fragmentation
>>>>> units: FU-A2 and FU-A4.
>>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset =
before
>>>>>> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure =
X.
>>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>>>>> indicates the total number of bytes in all prior FU payloads of =
the
>>>>>> fragmented
>>>>> NAL unit.
>>>>>>=20
>>>>>>    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
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 =
offset  |
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   | FU-A2 offset  |     DONL (optional)           |               =
|
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               =
|
>>>>>>   |                                                               =
|
>>>>>>   |                         FU payload                            =
|
>>>>>>   |                                                               =
|
>>>>>>   |                               =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |                               :...OPTIONAL RTP padding        =
|
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>=20
>>>>>>                  Figure X   RTP payload format for FU-A2
>>>>>>=20
>>>>>>=20
>>>>>>    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
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 =
offset  |
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A4 offset                             | =
DONL(optional)|
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   | DONL(optional)|                                               =
|
>>>>>>   +-+-+-+-+-+-+-+-+         FU payload                            =
|
>>>>>>   |                                                               =
|
>>>>>>   |                               =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |                               :...OPTIONAL RTP padding        =
|
>>>>>>   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>=20
>>>>>>                  Figure Y   RTP payload format for FU-A4
>>>>>>=20
>>>>>>=20
>>>>>> Since the offset of the first FU payload of a fragmented NAL unit =
is
>>>>>> zero, and the Start (S) bit in the FU header is sufficient to
>>>>>> indicate this, the first fragmentation unit of a fragmented NAL =
unit
>>>>>> SHOULD use FU-A, but MAY use
>>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>>>>> non-zero offset. The Start
>>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>>>>> contains a non- zero offset, and MUST be set if it contains a =
zero offset.
>>>>>>=20
>>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation =
unit are also
>>>> lost.
>>>>>> However, tiles which are successfully received in their entirety =
can
>>>>>> be decoded if their slice segment header containing tile offsets =
is
>>>>>> successfully received, despite lost fragmentation units. Fragment
>>>>>> offsets in FU-A2 or FU-A4 are required in order to recover from =
loss
>>>>>> of prior fragmentation units and continue decoding subsequent =
tiles.
>>>>>>=20
>>>>>> The following heuristic SHOULD be applied to determine if the =
lost
>>>>>> fragmentation units are all part of the same fragmented NAL unit =
as
>>>>>> subsequently received fragmentation units with identical RTP
>>>>>> timestamps and identical values of NAL unit header layer ID and =
temporal
>>>> ID.
>>>>>> 1. Let N be the number of missing sequence numbers between two
>>>>>> received fragmentation units with known offsets.
>>>>>> 2. Let P be the FU payload size of the first of the two received =
FUs.
>>>>>> 3. Let D be the difference in the offsets, minus P.
>>>>>>   (This is the number of missing FU payload bytes.) 4. Let E be N =
times P.
>>>>>>   (This is the estimated number of missing FU payload bytes.) 5.
>>>>>> Let ERROR be the absolute difference between D and E, divided by =
D.
>>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
>>>>>> fragmented NAL unit, otherwise it is unlikely.
>>>>>>=20
>>>>>> Cheers,
>>>>>> Mo
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] =
On
>>>>>> Behalf Of Rickard Sj=F6berg
>>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Dear all,
>>>>>>=20
>>>>>> I wrote slices and not dependent slices since the slice =
granularity
>>>>>> and slice/tile rule applies to both slices and dependent slices.
>>>>>> Sorry for the confusion. I will now use 'independent slices' and
>>>>>> 'dependent slices' to distinguish between them.
>>>>>>=20
>>>>>> I do not question the use of independent slices, I find them =
useful
>>>>>> in some applications.
>>>>>>=20
>>>>>> But the current RTP payload text says:
>>>>>>=20
>>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>      video telephony, video conferencing, live streaming and live
>>>>>>      broadcast, in which cases dependent slice segments SHOULD be =
used
>>>>>>      when a slice should be transported in multiple RTP packets."
>>>>>>=20
>>>>>> I believe that FUs are a viable option to dependent slices for =
the
>>>>>> reasons I listed in my previous e-mail and think that we should =
not
>>>>>> recommend dependent slices over FUs but leave it to the =
implementer.
>>>>>>=20
>>>>>> BR
>>>>>> Rickard
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] =
On
>>>>>> Behalf Of Wang, Ye-Kui
>>>>>> Sent: den 3 juli 2013 20:43
>>>>>> To: Thomas Davies; Stephan Wenger
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Hi All,
>>>>>>=20
>>>>>> I drafted an email replying directly to Rickard but did not =
finish
>>>>>> and there was a meeting (and then Stephan's and Thomas' emails =
came).
>>>>>>=20
>>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>>>>> slices, not FUs vs dependent slices, while the recommendation in =
the
>>>>>> draft is recommending use of dependent slices over FUs in
>>>>>> live-encoding scenarios (so this answers Thomas question: the
>>>>>> intention was
>>>>> dependent slices ).
>>>>>> In any case, it does not make much sense to try MTU size matching
>>>>>> and at the same time use either dependent slices or FUs, because
>>>>>> dependent slices and FUs should not be used when there are
>>>>>> considerable packet losses, while MTU size matching should be
>>>>>> applied when there are
>>>>> considerable packet losses.
>>>>>> For live encoding, whenever splitting of a regular slice is =
needed,
>>>>>> the splitting can be done by the encoder using dependent slices -
>>>>>> and the encoder has more knowledge and is more powerful than the =
RTP
>>>>>> packetizer and thus can do a better job for the splitting.
>>>>>>=20
>>>>>> BR, YK
>>>>>>=20
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>>>>> On Behalf Of Thomas Davies
>>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>>>>> To: Stephan Wenger
>>>>>>> Cc: payload@ietf.org
>>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Hi Stephan
>>>>>>>=20
>>>>>>> I think I agree with Rickard.
>>>>>>>=20
>>>>>>> I think the text in question states a preference for _dependent_
>>>>>>> slice segments, which have no error resiliency advantage over =
FUs.
>>>>>>> Is this just a
>>>>>> typo?
>>>>>>> <snip>
>>>>>>>=20
>>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>>       video telephony, video conferencing, live streaming and =
live
>>>>>>>       broadcast, in which cases dependent slice segments SHOULD =
be used
>>>>>>>       when a slice should be transported in multiple RTP =
packets.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> </snip>
>>>>>>>=20
>>>>>>> In general FUs may be used where error conditions are known to =
be
>>>>>>> benign, for greater efficiency, and also where for whatever =
reason
>>>>>>> the encoder cannot support MTU matching.
>>>>>>>=20
>>>>>>> We also are formulating some more general comments on this area
>>>>>>> which we hope to provide more fully soon.
>>>>>>>=20
>>>>>>> best regards
>>>>>>>=20
>>>>>>> Thomas
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>>>>> Hi Rickard,
>>>>>>>> Commenting only on slices vs. FUs.
>>>>>>>> The preference for slices over FUs, historically, was pushed by
>>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>>>>> and you can recover at the next slice boundary; loose an FU, =
and
>>>>>>>> you have to wait for the next slice header and throw away all
>>>>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>>>>> private, managed IP-network, which may have other constraints,
>>>>>>>> but are not the IETF's main
>>>>>>>> concern.) To set your remarks into context, let's first
>>>>>>>> understand what we are talking
>>>>>>>> about: the cost of slices is the overhead stemming from the
>>>>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>>>>> from the packet headers themselves.  And, of course,
>>>>>>>> implementation complexity, but we should not be in the business
>>>>>>>> to encourage implementor
>>>>>> laziness when
>>>>>>>> there would be a more complex, but better suited tool =
available.    The
>>>>>>>> additional packetization overhead is only incurred when, as a
>>>>>>>> result of incompetently filled packets (which, I agree, is more
>>>>>>>> likely with
>>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>>>>> needs to be inserted.  You may remember a quick analysis of =
mine
>>>>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>>>>> that the practical impact is negligible in almost all non-tile
>>>>>>>> scenarios (mostly because an additional overhead of 50 bytes or
>>>>>>>> so--3% or less of the coded picture size) is incurred
>>>>>>>> statistically only rarely (only in those cases where an
>>>>>>>> additional packet would need to be generated because of the
>>>>>>>> video coding related overhead for the use of slices).  The
>>>>>>>> prediction overhead of the use of regular slices has been shown
>>>>>>>> to be substantial--the price one needs to pay for independent
>>>>>>>> decodability--but for entropy slices that overhead virtually
>>>>>> does not exist.
>>>>>>>> With respect to tiles, I think you have a point though,
>>>>>>>> especially when considering the type of massive parallel
>>>>>>>> implementations for relatively small picture sizes some folks =
have been
>>>> considering.
>>>>>>>> OTOH, because FUs are trivial to implement--some say in =
contrast
>>>>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>>>>> error prone scenarios is a bad idea if you could use slices =
(but
>>>>>>>> for reasons like the tile connection you mentioned), the draft
>>>>>>>> should IMO continue to set a preference for the use of regular
>>>>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>>>>> implementer
>>>>> laziness.
>>>>>>>> However, this is the IETF.  We don't have to worry about the
>>>>>>>> word-count of explanatory language.  In fact, explaining such
>>>>>>>> complex tradeoffs and relationships is generally encouraged =
here.
>>>>>>>> So let's
>>>>>> just do that:
>>>>>>>> express a preference of the use of regular slices (SHOULD) when
>>>>>>>> you expect losses and can use them (real-time encoding, no
>>>>>>>> tiling structure that would lead to unacceptable packetization
>>>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
>>>>>>>> Accompanied by a more coherently expressed analysis.
>>>>>>>> Stephan
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 7.3.2013 06:46 , "Rickard
>>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>>>>> wrote:
>>>>>>>>> Hi Ye-Kui,
>>>>>>>>>=20
>>>>>>>>> Thanks for your feedback on my comments, your suggestions look
>>>>>>>>> good to
>>>>>>> me.
>>>>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
>>>>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>>>>> aggregation. The spatial granularity of slices was 16x16 =
pixels
>>>>>>>>> in H.264 but is typically
>>>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>>>>>>> units that are 16x larger. This may lead to a larger number of
>>>>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>>>>> that makes the slice granularity equal to the tile granularity
>>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>>>>> easier to implement since you do not need to care about when =
to
>>>>>>>>> break your slice to not exceed the MTU size limit. I think =
both
>>>>>>>>> slices and FUs has their merits and the choice between them =
for
>>>>>>>>> live-encoding should be left for
>>>>>> the implementer.
>>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and =
8.2
>>>>>>>>> and the POC MSB sync issue, I agree that this is a corner case
>>>>>>>>> that we probably will not see much of in practice. I have no
>>>>>>>>> text change suggestion at the moment.
>>>>>>>>>=20
>>>>>>>>> BR
>>>>>>>>> Rickard
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>>>>> Sent: den 24 juni 2013 01:00
>>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>> format
>>>>>>>>>=20
>>>>>>>>> Hi Rickard,
>>>>>>>>>=20
>>>>>>>>> Thanks for the careful review and the comments. Please see =
inline
>>>> below.
>>>>>>>>> BR, YK
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>>> format
>>>>>>>>>>=20
>>>>>>>>>> Dear all,
>>>>>>>>>>=20
>>>>>>>>>> I have taken a first look at =
draft-schierl-payload-rtp-h265-03
>>>>>>>>>> and have some questions/comments.
>>>>>>>>>>=20
>>>>>>>>>> My first question is what extensions of HEVC that
>>>>>>>>>> draft-schierl-payload-rtp-
>>>>>>>>>> h265 is intended to cover? The draft mentions "future =
scalable
>>>>>>>>>> or 3D  video coding  extensions  of  this specification", =
what
>>>>>>>>>> extensions do you refer to?
>>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>>>>> payload specification?
>>>>>>>>>>=20
>>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>>>>> sort of copy-and-paste error. Thanks for the good catching. =
No,
>>>>>>>>> there is no intention to cover HEVC extensions in this payload
>>>>>>>>> specification, though we intentionally to have the
>>>>>>>>> depacketization process and the use with feedback messages to
>>>>>>>>> work for HEVC scalability
>>>>>> and 3DV extensions.
>>>>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>>>>> pass picture timing SEI messages and decoding unit =
information
>>>>>>>>>> SEI messages to the decoder"?
>>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>>>>> specified by the video coding spec to the video decoders. This
>>>>>>>>> is emphasized here for the two timing related SEI messages
>>>>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>>>>> checking for the bitstream that was possible would be =
disabled,
>>>>>>>>> and also the information related to frame
>>>>>>> doubling or tripping would be lost.
>>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 =
rules.
>>>>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
>>>>>>>>> to put this as a packetization rule is to put it as part of =
the
>>>>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>>>>> belongs to an overview wherein normative language (even "MAY")
>>>>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>>>>> Header
>>>>> Usage"
>>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item =
there.
>>>>>>>>> I will do this in the next version unless there is a better =
suggestion.
>>>>>>>>>=20
>>>>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>>>>> reasons behind that?
>>>>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>>>>> live-encoding scenarios, wherein dependent slice segments =
should be
>>>> used instead.
>>>>>>>>> This was added after a discussion (among the authors) on the
>>>>>>>>> need of whether to specify a payload structure for mixed FU =
and
>>>>>>>>> aggregation packets and
>>>>>>>>> from that discussion we concluded that encoding dependent =
slice
>>>>>>>>> segments
>>>>>>>>> at source coding level already allows for the use cases and
>>>>>>>>> using of FUs for live-encoding does not make sense. Please let
>>>>>>>>> us know if you think differently.
>>>>>>>>>=20
>>>>>>>>>> In 8.2 and 8.3, the feedback messages are using =
PicOrderCntVal.
>>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>>>>> differ between the encoder and decoder?
>>>>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>>>>> random accessing to a bitstream is performed. However, it =
would
>>>>>>>>> not happen in conversational applications where the feedback
>>>>>>>>> messages may
>>>>> be used.
>>>>>>>>> Therefore, to me this would just work just fine. But please
>>>>>>>>> feel free to make other suggestions.
>>>>>>>>>=20
>>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>>>>> be useful, let me come back to that later on.
>>>>>>>>>>=20
>>>>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>>>>=20
>>>>>>>>>> I have also a number of spelling suggestions for your =
considerations:
>>>>>>>>>>=20
>>>>>>>>>> Section 1.1:
>>>>>>>>>> Replace "community" by "communities"
>>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per =
your
>>>>>>>>> suggestion (for the next version).
>>>>>>>>>=20
>>>>>>>>>> Section 1.1.1:
>>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>>>>> the interpolation filter"
>>>>>>>>> [YK] Thanks - done.
>>>>>>>>>=20
>>>>>>>>>> Replace "skipping the transform coding" by "skipping the =
transform"
>>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>>>>> coding)
>>>>>>>>>>=20
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 1.1.2:
>>>>>>>>>> Replace:
>>>>>>>>>> "2) An indication of whether there is any parameter set =
within
>>>>>>>>>> the current coded video sequence that updates another
>>>>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>>>>> by:
>>>>>>>>>> "2) An indication of whether there is no parameter set update
>>>>>>>>>> in the coded video sequence."
>>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC =
indicates.
>>>>>>>>>>=20
>>>>>>>>> [YK] Changed the wording to "An indication of whether there is
>>>>>>>>> no parameter set within the current coded video sequence that
>>>>>>>>> updates another parameter set of the same type preceding in
>>>>>>>>> decoding
>>>>> order."
>>>>>>>>>> Section 4.7:
>>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
>>>>>>>>>> and "FU
>>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the =
payload header.
>>>>>>>>>>=20
>>>>>>>>> [YK] Good point again. I will change the field name to be =
"FuType".
>>>>>>>>>=20
>>>>>>>>>> Section 6:
>>>>>>>>>> Replace "recovery" by "recover"
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 7.1:
>>>>>>>>>> Replace "level-id" by "level-idc"
>>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of =
"idc".
>>>>>>>>>=20
>>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 8:
>>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>>>>> "Assigned in this memo".
>>>>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>>>>> paragraph of Section
>>>>>>>>>> 8 since the memo is about HEVC.
>>>>>>>>> [YK] Good catch again. Changed.
>>>>>>>>>=20
>>>>>>>>>> Section 8.1:
>>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
>>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>>>>> contained in the FCI field"
>>>>>>>>> [YK] Another good catch. Changed.
>>>>>>>>>=20
>>>>>>>>>> Best Regards,
>>>>>>>>>> Rickard Sj=F6berg
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: payload-bounces@ietf.org
>>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>>>>> To: payload@ietf.org
>>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>>>>> payload format
>>>>>>>>>>=20
>>>>>>>>>> Dear All,
>>>>>>>>>>=20
>>>>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as =
follows:
>>>>>>>>>>=20
>>>>>>>>>> Version 02:
>>>>>>>>>> URL:
>>>>>>>>>> =
http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>> h265-02.txt
>>>>>>>>>> Htmlized:
>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>>>>> Diff:
>>>>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>> 5-
>>>>>>>>>> 02
>>>>>>>>>>=20
>>>>>>>>>> Version 03:
>>>>>>>>>> URL:
>>>>>>>>>> =
http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>> h265-03.txt
>>>>>>>>>> Htmlized:
>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>>>>> Diff:
>>>>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>> 5-
>>>>>>>>>> 03
>>>>>>>>>>=20
>>>>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>>>>> worked hard to try to make the design complete, from both the
>>>>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>>>>> to version 02, version
>>>>>>>>>> 03 only contains a correction of the email address of an =
author.
>>>>>>>>>>=20
>>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>>>>> other standards bodies such as 3GPP rely on the payload =
format
>>>>>>>>>> for support of H.265/HEVC in RTP based video services, we =
need
>>>>>>>>>> to progress this draft relatively quickly.
>>>>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>>>>> interested parties and also request for the WG status of this =
draft.
>>>>>>>>>>=20
>>>>>>>>>> BR, YK (on behalf of the authors)
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>> _______________________________________________
>>>>>>>> payload mailing list
>>>>>>>> payload@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>> _______________________________________________
>>>>>>> payload mailing list
>>>>>>> payload@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>> _______________________________________________
>>>>>> payload mailing list
>>>>>> payload@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>> _______________________________________________
>>>>>> payload mailing list
>>>>>> payload@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>>>=20
>=20


From mzanaty@cisco.com  Fri Jul  5 08:31:52 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCE11E82FE for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 08:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.329
X-Spam-Level: 
X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVeVIdfAN8W5 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 08:31:47 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3860E11E81DA for <payload@ietf.org>; Fri,  5 Jul 2013 08:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41621; q=dns/txt; s=iport; t=1373038307; x=1374247907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TJg/QiOYWVMM0pE8VcF4OF5Q/dW/sNSt8wwiWck/zWE=; b=HC7ZTH5lTmDP3Wy3ZMXcMywizr36cE0OZojvrhmABArmf2IQdHKmx5yU 60PAF2SpHhphiB8JblLJM2HgQz2y+AKQIIiiG2WABIfcHvbZiMC2SeW5Q Ki6fMRIx/fn3fOKFzLYEVpWUaxu1aS7OqDqro8/0ADslxEj20sYskZrWK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAFHm1lGtJXHB/2dsb2JhbABQCoMJMkMGwDeBABZ0giMBAQEDAQEBARcBTAcEBwUHBAIBCBEEAQEBCgsSBycLFAkIAgQBDQUIAQsHh24GBwW5B4xxgS4KAQUFBYEBDyIHBgSCemkDiGuLDIR7kByDEYFpCBcg
X-IronPort-AV: E=Sophos;i="4.87,1002,1363132800"; d="scan'208";a="231415891"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2013 15:31:43 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r65FVhF8016831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 15:31:43 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 10:31:42 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>, "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeCTOo/1Zj2Q7hkmxvsQohaKfo5lTadyAgALAqzyAAAVP0A==
Date: Fri, 5 Jul 2013 15:31:41 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com> <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de>
In-Reply-To: <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.208.83]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 15:31:52 -0000

Hi Thomas,

Please see my reply to YK about why some RTP apps may prefer (or be forced =
to use) fragmentation rather than dependent slice segments. The current dra=
ft supports resilience using tiles with dependent slice segments. The propo=
sed enhancement supports resilience using tiles with fragmentation.

I understand that dependent slice segments were specifically added to allow=
 a form of codec level fragmentation at finer granularity than slices. Howe=
ver, they are not always sufficient, desirable or even available in all cas=
es of interest for RTP apps. If they were, there would be no need for RTP l=
evel fragmentation at all. Since the current draft supports RTP level fragm=
entation, I assume there is consensus among the authors that there is value=
 in it. The proposed enhancement extends that value by also supporting resi=
lience, so RTP apps which use fragmentation can also support resilience.

Regards,
Mo

-----Original Message-----
From: Thomas Schierl [mailto:thomas.schierl@hhi.fraunhofer.de]=20
Sent: Friday, July 05, 2013 10:39 AM
To: Thomas Davies (thdavies)
Cc: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Wenger; P=
aul Bright-Thomas (paubrigh); payload@ietf.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Dear Thomas,

For the error resilience in the case of slices or dependent slices, which d=
o match with tiles, I do not think an additional pointer information in the=
 FU header does improve the error resilience capabilities over a system wit=
hout those information.=20

I think I did not exclude the use of FUs even for dependent slice fragments=
, but I would not require an additional mechanism to those, as stated in my=
 email before.

Thomas
--

Dr.-Ing. Thomas Schierl

Head of Multimedia Communications Group
Image Processing Department
thomas.schierl@hhi.fraunhofer.de

Tel.:  +49 30 31002-227
Fax:  +49 30 31002-190
Skype:  thomas.schierl

Fraunhofer HHI - Heinrich Hertz Institute
Einsteinufer 37, 10587 Berlin, Germany
http://www.hhi.fraunhofer.de/ip/mc

Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:

> Dear Thomas
>=20
> On your first point, the decoder always has to be told there is missing d=
ata. I don't see much different or fancy in the interface between the two c=
ases. Usually error concealment must be addressed both within the codec (be=
cause of reference dependencies) and also in the application (because of di=
splay and call-management/error response functionality). That's surely a ve=
ry minor issue.
>=20
> On the second point, the context we are considering in our proposal is wh=
ere FUs are being used, in the circumstances Mo set out, and providing some=
 level of sub-frame resilience where possible in that case. If your assumpt=
ion is that FUs are not being used, and re-writing is possible/desirable, y=
ou will certainly conclude that FUs should not be used. Since we concluded =
that FUs should not be discouraged, it seems reasonable to consider adding =
features which make them more resilient when they are.
>=20
> best regards
>=20
> Thomas
>=20
> On 05/07/13 10:34, Thomas Schierl wrote:
>> Dear Ye-Kui, all,
>>=20
>> Further I would tentatively assume that you can use the slice segment ad=
dress in the dependent slice fragment header for the same degree of error r=
esilience as the new-FU header, if you put a tile into a dependent slice. A=
nd this part would be understood by the decoder itself, which should be abl=
e to do the error resilience on codec level. Without fancy interfaces into =
the decoder, etc.
>>=20
>> A point in the discussion which seems to be missing is that the rewritin=
g of a single slice into multiple dependent slice fragments (including also=
 one independent slice fragment) can be done at very low processing costs, =
as shown during the standardization of HEVC.
>>=20
>> Thomas
>> --
>> Thomas Schierl
>> Fraunhofer HHI
>>=20
>> Am 04.07.2013 um 19:59 schrieb "Wang, Ye-Kui"<yekuiw@qti.qualcomm.com>:
>>=20
>>> Hi Thomas,
>>>=20
>>> Thanks for the clarification - I think now understand your scheme bette=
r.
>>>=20
>>> So you did not intent to encapsulate only entire tiles into packets, th=
ough that would obviously be more error resilient as you won't encounter th=
e problem where a part of a tile gets lost and the received rest becomes us=
eless. Rather, one tile may be carried in two (or even more) packets.
>>>=20
>>> I think I was confused by the suggested language such as "If a fragment=
ation unit is lost, tiles in the lost fragmentation unit are also lost. How=
ever, tiles which are successfully received in their entirety can be decode=
d if their slice segment header containing tile offsets is successfully rec=
eived, despite lost fragmentation units.", from where I got an impression t=
hat an FU includes entire tiles.
>>>=20
>>> As seen from other discussions, it is very questionable how big a penal=
ty would be when an encoder tries to splitting encoded data into separate N=
AL units (slices or dependent slices) for MTU size matching, even for large=
 CTB sizes - that's the reason why the JCT-VC later decided to remove the f=
ine-granularity slice feature.
>>>=20
>>> Let's tentatively assume that overall penalty and the overhead of the n=
ew-FU approach are roughly equivalent, and take into account latest comment=
s from Mo and Stephan, do we see an advantage of the new-FU approach compar=
ed to using dependent slices?
>>>=20
>>> I am not trying to conclude yet - just try to (very briefly) summarize =
the situation so far at least for myself.  We should certainly have more di=
scussions - preferable involving more people who care about this payload fo=
rmat.
>>>=20
>>> BR, YK
>>>=20
>>>> -----Original Message-----
>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>> Sent: Thursday, July 04, 2013 9:23 AM
>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Weng=
er;
>>>> Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC payloa=
d
>>>> format
>>>>=20
>>>> Hi Ye-Kui
>>>>=20
>>>> Thank you for the clarification - I understand your point a bit better=
 now.
>>>>=20
>>>> With the proposed scheme there is no need for the RTP packetizer to pa=
rse
>>>> slice headers or identify tile boundaries. All it needs to do is to ke=
ep track of the
>>>> offset of the start of the payload to the beginning of the NALU and pu=
t this into
>>>> the field. It needs to know this offset anyway. The packetizer is comp=
letely
>>>> dumb.
>>>>=20
>>>> The point is that a decoder wishing to do error resilience can parse t=
he slice
>>>> header and identify the tile boundaries in the case that a packet goes=
 missing,
>>>> for tiles that occur in the same frame but after the packet that is lo=
st. The
>>>> decoder can compare the tile offsets with the FU offsets to work out w=
hat data
>>>> is missing.
>>>>=20
>>>> Re dependent slices, there are indirect overheads as well, which come =
from
>>>> having to quantize the packet size to a whole number of tiles, plus yo=
u have to
>>>> manage the encoder to match the MTU size. The granularity of tiles you=
 need
>>>> for your parallel processing may not match the granularity you need to=
 fit in
>>>> the MTU very well.
>>>>=20
>>>> Best regards
>>>>=20
>>>> Thomas
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>> Sent: 04 July 2013 16:34
>>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg; =
Stephan
>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>> Cc: payload@ietf.org
>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC payloa=
d
>>>> format
>>>>=20
>>>> Hi Thomas,
>>>>=20
>>>> My point was really about using dependent slices, not about 1 or N til=
es per
>>>> packets (sorry that I did not make that clearer). Whatever strategy yo=
u would
>>>> like to do in terms of the number of tiles in a packet, using dependen=
t slices can
>>>> do the same, as each dependent slice can include 1 or N tiles.
>>>>=20
>>>> I see the following advantages with the approach using dependent slice=
s
>>>> instead of defining new FUs:
>>>>=20
>>>> - First of all, no need to define new payload structures.
>>>>=20
>>>> - The RTP packetizer does not need to parse slice headers to identify =
boundaries
>>>> of tiles within a coded slice, as tiles of one SLICE are already in se=
parate NAL
>>>> units each containing a DEPENDENT SLICE.
>>>>=20
>>>> - No additional overhead in packetization (the 1-byte FU header and th=
e 2- or
>>>> 4-byte FU offset). The overhead of the short slice header for dependen=
t slice
>>>> NAL units is compensated by less number of tile entry offsets signalle=
d, as the
>>>> entry offset of the first tile in each NAL unit is not signalled in th=
e slice header.
>>>> Using dependent slices would need more two-byte NAL unit headers, whil=
e
>>>> using new FUs would need more two-byte packet payload headers, and the
>>>> overhead bits here are the same for both methods.
>>>>=20
>>>> Am I missing anything here?
>>>>=20
>>>> BR, YK
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>>> Sent: Thursday, July 04, 2013 1:49 AM
>>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>> Yes, we did think about one tile per packet or N tiles per packet,
>>>>> also: I guess that is where we started from. Then you could indeed
>>>>> align missing tiles with missing sequence numbers.
>>>>>=20
>>>>> The issue is that you need to guarantee that you are doing this for i=
t
>>>>> to be useful, and the decoder needs to know that this is guaranteed
>>>>> through some form of other signalling. However, the bitstream chunk
>>>>> associated to a tile is extremely variable, and many tile chunks woul=
d
>>>>> be very small. So there is significant packetization overhead for the=
m if there
>>>> is one tile per packet.
>>>>> Having N>1 reduces this overhead, but it is still there and as N
>>>>> increases you run the risk of breaking the MTU size which then
>>>>> requires that you have to re- encode to fit things in and meet the
>>>>> guarantee. There is definitely no time to re-encode whole tiles,
>>>>> especially if you are already using them for parallelization. Thus yo=
u
>>>>> might have to break the guarantee and fragment the packet anyhow, los=
ing
>>>> the resilience.
>>>>> The advantage that we see with the proposal is that you can get fairl=
y
>>>>> similar resilience to regular slice MTU-size matching, but with much
>>>>> lower overheads as you can have a single regular slice header per fra=
me, yet
>>>> have a "dumb"
>>>>> packetization process and no need to re-encode to hit MTU targets. In
>>>>> H264 MTU matching usually means re-encoding just one or two 16x16 MBs=
.
>>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you ar=
e
>>>>> doing tiles then you can get tiny "dangling slices" at the end of a
>>>>> tile, which means more small packets.
>>>>>=20
>>>>> Best regards
>>>>>=20
>>>>> Thomas
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>> Sent: 04 July 2013 07:02
>>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies (thdavies);
>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>> payload format
>>>>>=20
>>>>>=20
>>>>> An interesting idea. Using dependent slices (again :-) together with
>>>>> tiles would do the trick too (each tile in one dependent slice, and
>>>>> then each dependent slice NAL unit in one single NAL unit packet).
>>>>>=20
>>>>> Have you guys done an analysis comparing the pros and cons of the two
>>>>> alternative approaches?
>>>>>=20
>>>>> BR, YK
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); Steph=
an
>>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Thomas, Paul and I have been working on improving packet loss
>>>>>> resilience using fragments and tiles. I mentioned this to Stephan at
>>>>>> IETF 86 in Orlando, and promised to have draft text ready before
>>>>>> Berlin. Here is the proposed text along with an overview of the rati=
onale.
>>>>>>=20
>>>>>> Rationale:
>>>>>>=20
>>>>>> 1. Resilience to packet loss requires independent slices or tiles.
>>>>>> Since independence requires restrictions on some coding tools, both
>>>>>> potentially incur slight penalties in coding efficiency, with a
>>>>>> smaller penalty
>>>>> for tiles.
>>>>>> 2. Fragmentation in a higher layer like RTP can have several
>>>>>> advantages over similar features in a codec layer like slices
>>>>>> (independent or
>>>>> dependent).
>>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity while
>>>>>> slices have much larger (CTB or tile) granularity. It also has less
>>>>>> slice segment header overhead, especially for independent slices.
>>>>>> This can impact the efficiency of the packetized stream in terms of
>>>>>> both bits and
>>>>> packets per second.
>>>>>> b. Performance: Encoders must perform extra processing to limit
>>>>>> slice sizes, which can impact encoder performance. Some
>>>>>> implementations speculatively end a slice based on computed
>>>>>> statistics (which aggravates a.), while others recode a slice if the
>>>>>> size is exceeded (which
>>>>> aggravates b.).
>>>>>> c. Decoupling: Not all encoders will support limiting slice size to =
MTU size.
>>>>>> Applications (for live or stored content) using such encoders can
>>>>>> still support MTU limits using RTP fragmentation since it is
>>>>>> decoupled from
>>>>> the encoder.
>>>>>> d. Multi-party: The encoded content may go to multiple receivers
>>>>>> with different MTUs. RTP fragmentation can handle this with
>>>>>> lightweight repacketization at middle boxes whereas slices incur
>>>> heavyweight transcoding.
>>>>>> 3. Combining fragmentation and tiles can improve resilience while
>>>>>> retaining the above advantages, if fragments are enhanced to contain
>>>>>> offsets (similar to IP fragmentation). This is described in the
>>>>>> proposed draft text below, which would immediately follow section
>>>>>> 4.7
>>>>> Fragmentation Units.
>>>>>> Draft Text:
>>>>>>=20
>>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>>>>=20
>>>>>> If a fragmented NAL unit contains tiles, its slice segment header
>>>>>> contains offsets to the data of each tile. These offsets can be used
>>>>>> for random access to any tile for parallel processing, region of
>>>>>> interest extraction, and resilience to errors in other tiles. These
>>>>>> offsets can also be used to provide resilience to packet loss, in
>>>>>> conjunction with fragment offsets contained in two types of
>>>>>> fragmentation
>>>>> units: FU-A2 and FU-A4.
>>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset before
>>>>>> the FU payload. FU-A2 contains a 2-byte offset as shown in Figure X.
>>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>>>>> indicates the total number of bytes in all prior FU payloads of the
>>>>>> fragmented
>>>>> NAL unit.
>>>>>>=20
>>>>>>    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
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset  =
|
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   | FU-A2 offset  |     DONL (optional)           |               |
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>>>>   |                                                               |
>>>>>>   |                         FU payload                            |
>>>>>>   |                                                               |
>>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |                               :...OPTIONAL RTP padding        |
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>=20
>>>>>>                  Figure X   RTP payload format for FU-A2
>>>>>>=20
>>>>>>=20
>>>>>>    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
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset  =
|
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |      FU-A4 offset                             | DONL(optional)|
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   | DONL(optional)|                                               |
>>>>>>   +-+-+-+-+-+-+-+-+         FU payload                            |
>>>>>>   |                                                               |
>>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>   |                               :...OPTIONAL RTP padding        |
>>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>=20
>>>>>>                  Figure Y   RTP payload format for FU-A4
>>>>>>=20
>>>>>>=20
>>>>>> Since the offset of the first FU payload of a fragmented NAL unit is
>>>>>> zero, and the Start (S) bit in the FU header is sufficient to
>>>>>> indicate this, the first fragmentation unit of a fragmented NAL unit
>>>>>> SHOULD use FU-A, but MAY use
>>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>>>>> non-zero offset. The Start
>>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>>>>> contains a non- zero offset, and MUST be set if it contains a zero o=
ffset.
>>>>>>=20
>>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation uni=
t are also
>>>> lost.
>>>>>> However, tiles which are successfully received in their entirety can
>>>>>> be decoded if their slice segment header containing tile offsets is
>>>>>> successfully received, despite lost fragmentation units. Fragment
>>>>>> offsets in FU-A2 or FU-A4 are required in order to recover from loss
>>>>>> of prior fragmentation units and continue decoding subsequent tiles.
>>>>>>=20
>>>>>> The following heuristic SHOULD be applied to determine if the lost
>>>>>> fragmentation units are all part of the same fragmented NAL unit as
>>>>>> subsequently received fragmentation units with identical RTP
>>>>>> timestamps and identical values of NAL unit header layer ID and temp=
oral
>>>> ID.
>>>>>> 1. Let N be the number of missing sequence numbers between two
>>>>>> received fragmentation units with known offsets.
>>>>>> 2. Let P be the FU payload size of the first of the two received FUs=
.
>>>>>> 3. Let D be the difference in the offsets, minus P.
>>>>>>   (This is the number of missing FU payload bytes.) 4. Let E be N ti=
mes P.
>>>>>>   (This is the estimated number of missing FU payload bytes.) 5.
>>>>>> Let ERROR be the absolute difference between D and E, divided by D.
>>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
>>>>>> fragmented NAL unit, otherwise it is unlikely.
>>>>>>=20
>>>>>> Cheers,
>>>>>> Mo
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>>>> Behalf Of Rickard Sj=F6berg
>>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Dear all,
>>>>>>=20
>>>>>> I wrote slices and not dependent slices since the slice granularity
>>>>>> and slice/tile rule applies to both slices and dependent slices.
>>>>>> Sorry for the confusion. I will now use 'independent slices' and
>>>>>> 'dependent slices' to distinguish between them.
>>>>>>=20
>>>>>> I do not question the use of independent slices, I find them useful
>>>>>> in some applications.
>>>>>>=20
>>>>>> But the current RTP payload text says:
>>>>>>=20
>>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>      video telephony, video conferencing, live streaming and live
>>>>>>      broadcast, in which cases dependent slice segments SHOULD be us=
ed
>>>>>>      when a slice should be transported in multiple RTP packets."
>>>>>>=20
>>>>>> I believe that FUs are a viable option to dependent slices for the
>>>>>> reasons I listed in my previous e-mail and think that we should not
>>>>>> recommend dependent slices over FUs but leave it to the implementer.
>>>>>>=20
>>>>>> BR
>>>>>> Rickard
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>>>>>> Behalf Of Wang, Ye-Kui
>>>>>> Sent: den 3 juli 2013 20:43
>>>>>> To: Thomas Davies; Stephan Wenger
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Hi All,
>>>>>>=20
>>>>>> I drafted an email replying directly to Rickard but did not finish
>>>>>> and there was a meeting (and then Stephan's and Thomas' emails came)=
.
>>>>>>=20
>>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>>>>> slices, not FUs vs dependent slices, while the recommendation in the
>>>>>> draft is recommending use of dependent slices over FUs in
>>>>>> live-encoding scenarios (so this answers Thomas question: the
>>>>>> intention was
>>>>> dependent slices ).
>>>>>> In any case, it does not make much sense to try MTU size matching
>>>>>> and at the same time use either dependent slices or FUs, because
>>>>>> dependent slices and FUs should not be used when there are
>>>>>> considerable packet losses, while MTU size matching should be
>>>>>> applied when there are
>>>>> considerable packet losses.
>>>>>> For live encoding, whenever splitting of a regular slice is needed,
>>>>>> the splitting can be done by the encoder using dependent slices -
>>>>>> and the encoder has more knowledge and is more powerful than the RTP
>>>>>> packetizer and thus can do a better job for the splitting.
>>>>>>=20
>>>>>> BR, YK
>>>>>>=20
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
>>>>>>> On Behalf Of Thomas Davies
>>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>>>>> To: Stephan Wenger
>>>>>>> Cc: payload@ietf.org
>>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Hi Stephan
>>>>>>>=20
>>>>>>> I think I agree with Rickard.
>>>>>>>=20
>>>>>>> I think the text in question states a preference for _dependent_
>>>>>>> slice segments, which have no error resiliency advantage over FUs.
>>>>>>> Is this just a
>>>>>> typo?
>>>>>>> <snip>
>>>>>>>=20
>>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>>       video telephony, video conferencing, live streaming and live
>>>>>>>       broadcast, in which cases dependent slice segments SHOULD be =
used
>>>>>>>       when a slice should be transported in multiple RTP packets.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> </snip>
>>>>>>>=20
>>>>>>> In general FUs may be used where error conditions are known to be
>>>>>>> benign, for greater efficiency, and also where for whatever reason
>>>>>>> the encoder cannot support MTU matching.
>>>>>>>=20
>>>>>>> We also are formulating some more general comments on this area
>>>>>>> which we hope to provide more fully soon.
>>>>>>>=20
>>>>>>> best regards
>>>>>>>=20
>>>>>>> Thomas
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>>>>> Hi Rickard,
>>>>>>>> Commenting only on slices vs. FUs.
>>>>>>>> The preference for slices over FUs, historically, was pushed by
>>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>>>>> and you can recover at the next slice boundary; loose an FU, and
>>>>>>>> you have to wait for the next slice header and throw away all
>>>>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>>>>> private, managed IP-network, which may have other constraints,
>>>>>>>> but are not the IETF's main
>>>>>>>> concern.) To set your remarks into context, let's first
>>>>>>>> understand what we are talking
>>>>>>>> about: the cost of slices is the overhead stemming from the
>>>>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>>>>> from the packet headers themselves.  And, of course,
>>>>>>>> implementation complexity, but we should not be in the business
>>>>>>>> to encourage implementor
>>>>>> laziness when
>>>>>>>> there would be a more complex, but better suited tool available.  =
  The
>>>>>>>> additional packetization overhead is only incurred when, as a
>>>>>>>> result of incompetently filled packets (which, I agree, is more
>>>>>>>> likely with
>>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>>>>> needs to be inserted.  You may remember a quick analysis of mine
>>>>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>>>>> that the practical impact is negligible in almost all non-tile
>>>>>>>> scenarios (mostly because an additional overhead of 50 bytes or
>>>>>>>> so--3% or less of the coded picture size) is incurred
>>>>>>>> statistically only rarely (only in those cases where an
>>>>>>>> additional packet would need to be generated because of the
>>>>>>>> video coding related overhead for the use of slices).  The
>>>>>>>> prediction overhead of the use of regular slices has been shown
>>>>>>>> to be substantial--the price one needs to pay for independent
>>>>>>>> decodability--but for entropy slices that overhead virtually
>>>>>> does not exist.
>>>>>>>> With respect to tiles, I think you have a point though,
>>>>>>>> especially when considering the type of massive parallel
>>>>>>>> implementations for relatively small picture sizes some folks have=
 been
>>>> considering.
>>>>>>>> OTOH, because FUs are trivial to implement--some say in contrast
>>>>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>>>>> error prone scenarios is a bad idea if you could use slices (but
>>>>>>>> for reasons like the tile connection you mentioned), the draft
>>>>>>>> should IMO continue to set a preference for the use of regular
>>>>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>>>>> implementer
>>>>> laziness.
>>>>>>>> However, this is the IETF.  We don't have to worry about the
>>>>>>>> word-count of explanatory language.  In fact, explaining such
>>>>>>>> complex tradeoffs and relationships is generally encouraged here.
>>>>>>>> So let's
>>>>>> just do that:
>>>>>>>> express a preference of the use of regular slices (SHOULD) when
>>>>>>>> you expect losses and can use them (real-time encoding, no
>>>>>>>> tiling structure that would lead to unacceptable packetization
>>>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
>>>>>>>> Accompanied by a more coherently expressed analysis.
>>>>>>>> Stephan
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 7.3.2013 06:46 , "Rickard
>>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>>>>> wrote:
>>>>>>>>> Hi Ye-Kui,
>>>>>>>>>=20
>>>>>>>>> Thanks for your feedback on my comments, your suggestions look
>>>>>>>>> good to
>>>>>>> me.
>>>>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
>>>>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>>>>> aggregation. The spatial granularity of slices was 16x16 pixels
>>>>>>>>> in H.264 but is typically
>>>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
>>>>>>>>> units that are 16x larger. This may lead to a larger number of
>>>>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>>>>> that makes the slice granularity equal to the tile granularity
>>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>>>>> easier to implement since you do not need to care about when to
>>>>>>>>> break your slice to not exceed the MTU size limit. I think both
>>>>>>>>> slices and FUs has their merits and the choice between them for
>>>>>>>>> live-encoding should be left for
>>>>>> the implementer.
>>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and 8.2
>>>>>>>>> and the POC MSB sync issue, I agree that this is a corner case
>>>>>>>>> that we probably will not see much of in practice. I have no
>>>>>>>>> text change suggestion at the moment.
>>>>>>>>>=20
>>>>>>>>> BR
>>>>>>>>> Rickard
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>>>>> Sent: den 24 juni 2013 01:00
>>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>> format
>>>>>>>>>=20
>>>>>>>>> Hi Rickard,
>>>>>>>>>=20
>>>>>>>>> Thanks for the careful review and the comments. Please see inline
>>>> below.
>>>>>>>>> BR, YK
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
>>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>>> format
>>>>>>>>>>=20
>>>>>>>>>> Dear all,
>>>>>>>>>>=20
>>>>>>>>>> I have taken a first look at draft-schierl-payload-rtp-h265-03
>>>>>>>>>> and have some questions/comments.
>>>>>>>>>>=20
>>>>>>>>>> My first question is what extensions of HEVC that
>>>>>>>>>> draft-schierl-payload-rtp-
>>>>>>>>>> h265 is intended to cover? The draft mentions "future scalable
>>>>>>>>>> or 3D  video coding  extensions  of  this specification", what
>>>>>>>>>> extensions do you refer to?
>>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>>>>> payload specification?
>>>>>>>>>>=20
>>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
>>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>>>>> sort of copy-and-paste error. Thanks for the good catching. No,
>>>>>>>>> there is no intention to cover HEVC extensions in this payload
>>>>>>>>> specification, though we intentionally to have the
>>>>>>>>> depacketization process and the use with feedback messages to
>>>>>>>>> work for HEVC scalability
>>>>>> and 3DV extensions.
>>>>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>>>>> pass picture timing SEI messages and decoding unit information
>>>>>>>>>> SEI messages to the decoder"?
>>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>>>>> specified by the video coding spec to the video decoders. This
>>>>>>>>> is emphasized here for the two timing related SEI messages
>>>>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>>>>> checking for the bitstream that was possible would be disabled,
>>>>>>>>> and also the information related to frame
>>>>>>> doubling or tripping would be lost.
>>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
>>>>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
>>>>>>>>> to put this as a packetization rule is to put it as part of the
>>>>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>>>>> belongs to an overview wherein normative language (even "MAY")
>>>>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>>>>> Header
>>>>> Usage"
>>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item there=
.
>>>>>>>>> I will do this in the next version unless there is a better sugge=
stion.
>>>>>>>>>=20
>>>>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>>>>> reasons behind that?
>>>>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>>>>> live-encoding scenarios, wherein dependent slice segments should =
be
>>>> used instead.
>>>>>>>>> This was added after a discussion (among the authors) on the
>>>>>>>>> need of whether to specify a payload structure for mixed FU and
>>>>>>>>> aggregation packets and
>>>>>>>>> from that discussion we concluded that encoding dependent slice
>>>>>>>>> segments
>>>>>>>>> at source coding level already allows for the use cases and
>>>>>>>>> using of FUs for live-encoding does not make sense. Please let
>>>>>>>>> us know if you think differently.
>>>>>>>>>=20
>>>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal.
>>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>>>>> differ between the encoder and decoder?
>>>>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>>>>> random accessing to a bitstream is performed. However, it would
>>>>>>>>> not happen in conversational applications where the feedback
>>>>>>>>> messages may
>>>>> be used.
>>>>>>>>> Therefore, to me this would just work just fine. But please
>>>>>>>>> feel free to make other suggestions.
>>>>>>>>>=20
>>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>>>>> be useful, let me come back to that later on.
>>>>>>>>>>=20
>>>>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>>>>=20
>>>>>>>>>> I have also a number of spelling suggestions for your considerat=
ions:
>>>>>>>>>>=20
>>>>>>>>>> Section 1.1:
>>>>>>>>>> Replace "community" by "communities"
>>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per your
>>>>>>>>> suggestion (for the next version).
>>>>>>>>>=20
>>>>>>>>>> Section 1.1.1:
>>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>>>>> the interpolation filter"
>>>>>>>>> [YK] Thanks - done.
>>>>>>>>>=20
>>>>>>>>>> Replace "skipping the transform coding" by "skipping the transfo=
rm"
>>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>>>>> coding)
>>>>>>>>>>=20
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 1.1.2:
>>>>>>>>>> Replace:
>>>>>>>>>> "2) An indication of whether there is any parameter set within
>>>>>>>>>> the current coded video sequence that updates another
>>>>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>>>>> by:
>>>>>>>>>> "2) An indication of whether there is no parameter set update
>>>>>>>>>> in the coded video sequence."
>>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC indicate=
s.
>>>>>>>>>>=20
>>>>>>>>> [YK] Changed the wording to "An indication of whether there is
>>>>>>>>> no parameter set within the current coded video sequence that
>>>>>>>>> updates another parameter set of the same type preceding in
>>>>>>>>> decoding
>>>>> order."
>>>>>>>>>> Section 4.7:
>>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
>>>>>>>>>> and "FU
>>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload h=
eader.
>>>>>>>>>>=20
>>>>>>>>> [YK] Good point again. I will change the field name to be "FuType=
".
>>>>>>>>>=20
>>>>>>>>>> Section 6:
>>>>>>>>>> Replace "recovery" by "recover"
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 7.1:
>>>>>>>>>> Replace "level-id" by "level-idc"
>>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "idc"=
.
>>>>>>>>>=20
>>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>>>>> [YK] Done.
>>>>>>>>>=20
>>>>>>>>>> Section 8:
>>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>>>>> "Assigned in this memo".
>>>>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>>>>> paragraph of Section
>>>>>>>>>> 8 since the memo is about HEVC.
>>>>>>>>> [YK] Good catch again. Changed.
>>>>>>>>>=20
>>>>>>>>>> Section 8.1:
>>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
>>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>>>>> contained in the FCI field"
>>>>>>>>> [YK] Another good catch. Changed.
>>>>>>>>>=20
>>>>>>>>>> Best Regards,
>>>>>>>>>> Rickard Sj=F6berg
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: payload-bounces@ietf.org
>>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>>>>> To: payload@ietf.org
>>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>>>>> payload format
>>>>>>>>>>=20
>>>>>>>>>> Dear All,
>>>>>>>>>>=20
>>>>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as follo=
ws:
>>>>>>>>>>=20
>>>>>>>>>> Version 02:
>>>>>>>>>> URL:
>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>> h265-02.txt
>>>>>>>>>> Htmlized:
>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>>>>> Diff:
>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>> 5-
>>>>>>>>>> 02
>>>>>>>>>>=20
>>>>>>>>>> Version 03:
>>>>>>>>>> URL:
>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>> h265-03.txt
>>>>>>>>>> Htmlized:
>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>>>>> Diff:
>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>> 5-
>>>>>>>>>> 03
>>>>>>>>>>=20
>>>>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>>>>> worked hard to try to make the design complete, from both the
>>>>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>>>>> to version 02, version
>>>>>>>>>> 03 only contains a correction of the email address of an author.
>>>>>>>>>>=20
>>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>>>>> other standards bodies such as 3GPP rely on the payload format
>>>>>>>>>> for support of H.265/HEVC in RTP based video services, we need
>>>>>>>>>> to progress this draft relatively quickly.
>>>>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>>>>> interested parties and also request for the WG status of this dr=
aft.
>>>>>>>>>>=20
>>>>>>>>>> BR, YK (on behalf of the authors)
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>> _______________________________________________
>>>>>>>> payload mailing list
>>>>>>>> payload@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>> _______________________________________________
>>>>>>> payload mailing list
>>>>>>> payload@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>> _______________________________________________
>>>>>> payload mailing list
>>>>>> payload@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>> _______________________________________________
>>>>>> payload mailing list
>>>>>> payload@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>>>=20
>=20


From yekuiw@qti.qualcomm.com  Fri Jul  5 08:57:31 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD01811E8310 for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 08:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpA9B+4q-9iR for <payload@ietfa.amsl.com>; Fri,  5 Jul 2013 08:57:23 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2611E82F1 for <payload@ietf.org>; Fri,  5 Jul 2013 08:57:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373039839; x=1404575839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t/HaaHPPt166V5epOaLVXfYffZXSmEFG8tbiesbmuNg=; b=zesq36PGnFyD8K02/g7RU0p4CzqX7eXGM68WU+5bThTzs1ff7gh3qajR raxa/JVNz9I0yMSO93wkpPVH92yUQ2uheGwEIH2oRbViGRvmsoKZYUOBc FYWhx7S3YM54ttbDtU/V2zx5lydlVXoxkX8OWZnu3OErzRNguuSx5VwwD M=;
X-IronPort-AV: E=Sophos;i="4.87,1002,1363158000"; d="scan'208";a="46809717"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 05 Jul 2013 08:57:11 -0700
X-IronPort-AV: E=Sophos;i="4.87,1002,1363158000"; d="scan'208";a="474865156"
Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Jul 2013 08:57:10 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 08:57:10 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>, "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHINrpiwi8/7UEygLhM2FJhH9ZlUBM9AgACmR4D///S3IIAAiiGA//+fwlCAAYB+AIAAT+EAgAAFJYCAAA6/gP//jHiw
Date: Fri, 5 Jul 2013 15:57:09 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833845BCCC@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com> <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de> <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.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
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 15:57:31 -0000

Hi Mo,

FUs IMO are mainly used for fragmenting big slices for stored /pre-encoded =
contents. Though I agreed not to discourage the use of FUs for live-encodin=
g scenarios, I agreed on the basis that MTU size matching can be used for o=
ther purposes than error resilience. For error resilience purposes in live-=
encoding scenarios, I still don't think using FUs is a good choice, as Step=
han also mentioned and others basically agreed too. Note also that actually=
 FUs came earlier (as they were included in H.264 payload and this draft in=
herited a lot of stuff from the H.264 payload spec) than dependent slices (=
only in H.265).

>From the discussions so far, for the error resilience optimization you guys=
 are trying to achieve, my understanding is that using dependent slices can=
 achieve at least the same performance, and conforming H.265 decoders are r=
equired to support dependent slices anyway.

BR, YK

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: Friday, July 05, 2013 8:32 AM
> To: Thomas Schierl; Thomas Davies (thdavies)
> Cc: Wang, Ye-Kui; Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas
> (paubrigh); payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> Please see my reply to YK about why some RTP apps may prefer (or be force=
d
> to use) fragmentation rather than dependent slice segments. The current d=
raft
> supports resilience using tiles with dependent slice segments. The propos=
ed
> enhancement supports resilience using tiles with fragmentation.
>=20
> I understand that dependent slice segments were specifically added to all=
ow a
> form of codec level fragmentation at finer granularity than slices. Howev=
er,
> they are not always sufficient, desirable or even available in all cases =
of interest
> for RTP apps. If they were, there would be no need for RTP level fragment=
ation
> at all. Since the current draft supports RTP level fragmentation, I assum=
e there
> is consensus among the authors that there is value in it. The proposed
> enhancement extends that value by also supporting resilience, so RTP apps
> which use fragmentation can also support resilience.
>=20
> Regards,
> Mo
>=20
> -----Original Message-----
> From: Thomas Schierl [mailto:thomas.schierl@hhi.fraunhofer.de]
> Sent: Friday, July 05, 2013 10:39 AM
> To: Thomas Davies (thdavies)
> Cc: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Wenger;
> Paul Bright-Thomas (paubrigh); payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Dear Thomas,
>=20
> For the error resilience in the case of slices or dependent slices, which=
 do match
> with tiles, I do not think an additional pointer information in the FU he=
ader
> does improve the error resilience capabilities over a system without thos=
e
> information.
>=20
> I think I did not exclude the use of FUs even for dependent slice fragmen=
ts, but
> I would not require an additional mechanism to those, as stated in my ema=
il
> before.
>=20
> Thomas
> --
>=20
> Dr.-Ing. Thomas Schierl
>=20
> Head of Multimedia Communications Group
> Image Processing Department
> thomas.schierl@hhi.fraunhofer.de
>=20
> Tel.:  +49 30 31002-227
> Fax:  +49 30 31002-190
> Skype:  thomas.schierl
>=20
> Fraunhofer HHI - Heinrich Hertz Institute Einsteinufer 37, 10587 Berlin,
> Germany http://www.hhi.fraunhofer.de/ip/mc
>=20
> Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:
>=20
> > Dear Thomas
> >
> > On your first point, the decoder always has to be told there is missing=
 data. I
> don't see much different or fancy in the interface between the two cases.
> Usually error concealment must be addressed both within the codec (becaus=
e
> of reference dependencies) and also in the application (because of displa=
y and
> call-management/error response functionality). That's surely a very minor=
 issue.
> >
> > On the second point, the context we are considering in our proposal is =
where
> FUs are being used, in the circumstances Mo set out, and providing some l=
evel
> of sub-frame resilience where possible in that case. If your assumption i=
s that
> FUs are not being used, and re-writing is possible/desirable, you will ce=
rtainly
> conclude that FUs should not be used. Since we concluded that FUs should =
not
> be discouraged, it seems reasonable to consider adding features which mak=
e
> them more resilient when they are.
> >
> > best regards
> >
> > Thomas
> >
> > On 05/07/13 10:34, Thomas Schierl wrote:
> >> Dear Ye-Kui, all,
> >>
> >> Further I would tentatively assume that you can use the slice segment
> address in the dependent slice fragment header for the same degree of err=
or
> resilience as the new-FU header, if you put a tile into a dependent slice=
. And
> this part would be understood by the decoder itself, which should be able=
 to do
> the error resilience on codec level. Without fancy interfaces into the de=
coder,
> etc.
> >>
> >> A point in the discussion which seems to be missing is that the rewrit=
ing of a
> single slice into multiple dependent slice fragments (including also one
> independent slice fragment) can be done at very low processing costs, as =
shown
> during the standardization of HEVC.
> >>
> >> Thomas
> >> --
> >> Thomas Schierl
> >> Fraunhofer HHI
> >>
> >> Am 04.07.2013 um 19:59 schrieb "Wang, Ye-
> Kui"<yekuiw@qti.qualcomm.com>:
> >>
> >>> Hi Thomas,
> >>>
> >>> Thanks for the clarification - I think now understand your scheme bet=
ter.
> >>>
> >>> So you did not intent to encapsulate only entire tiles into packets, =
though
> that would obviously be more error resilient as you won't encounter the
> problem where a part of a tile gets lost and the received rest becomes us=
eless.
> Rather, one tile may be carried in two (or even more) packets.
> >>>
> >>> I think I was confused by the suggested language such as "If a
> fragmentation unit is lost, tiles in the lost fragmentation unit are also=
 lost.
> However, tiles which are successfully received in their entirety can be d=
ecoded
> if their slice segment header containing tile offsets is successfully rec=
eived,
> despite lost fragmentation units.", from where I got an impression that a=
n FU
> includes entire tiles.
> >>>
> >>> As seen from other discussions, it is very questionable how big a pen=
alty
> would be when an encoder tries to splitting encoded data into separate NA=
L
> units (slices or dependent slices) for MTU size matching, even for large =
CTB
> sizes - that's the reason why the JCT-VC later decided to remove the fine=
-
> granularity slice feature.
> >>>
> >>> Let's tentatively assume that overall penalty and the overhead of the=
 new-
> FU approach are roughly equivalent, and take into account latest comments
> from Mo and Stephan, do we see an advantage of the new-FU approach
> compared to using dependent slices?
> >>>
> >>> I am not trying to conclude yet - just try to (very briefly) summariz=
e the
> situation so far at least for myself.  We should certainly have more disc=
ussions -
> preferable involving more people who care about this payload format.
> >>>
> >>> BR, YK
> >>>
> >>>> -----Original Message-----
> >>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> >>>> Sent: Thursday, July 04, 2013 9:23 AM
> >>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> >>>> Wenger; Paul Bright-Thomas (paubrigh)
> >>>> Cc: payload@ietf.org
> >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>> payload format
> >>>>
> >>>> Hi Ye-Kui
> >>>>
> >>>> Thank you for the clarification - I understand your point a bit bett=
er now.
> >>>>
> >>>> With the proposed scheme there is no need for the RTP packetizer to
> >>>> parse slice headers or identify tile boundaries. All it needs to do
> >>>> is to keep track of the offset of the start of the payload to the
> >>>> beginning of the NALU and put this into the field. It needs to know
> >>>> this offset anyway. The packetizer is completely dumb.
> >>>>
> >>>> The point is that a decoder wishing to do error resilience can
> >>>> parse the slice header and identify the tile boundaries in the case
> >>>> that a packet goes missing, for tiles that occur in the same frame
> >>>> but after the packet that is lost. The decoder can compare the tile
> >>>> offsets with the FU offsets to work out what data is missing.
> >>>>
> >>>> Re dependent slices, there are indirect overheads as well, which
> >>>> come from having to quantize the packet size to a whole number of
> >>>> tiles, plus you have to manage the encoder to match the MTU size.
> >>>> The granularity of tiles you need for your parallel processing may
> >>>> not match the granularity you need to fit in the MTU very well.
> >>>>
> >>>> Best regards
> >>>>
> >>>> Thomas
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>> Sent: 04 July 2013 16:34
> >>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg=
;
> >>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>> Cc: payload@ietf.org
> >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>> payload format
> >>>>
> >>>> Hi Thomas,
> >>>>
> >>>> My point was really about using dependent slices, not about 1 or N
> >>>> tiles per packets (sorry that I did not make that clearer).
> >>>> Whatever strategy you would like to do in terms of the number of
> >>>> tiles in a packet, using dependent slices can do the same, as each
> dependent slice can include 1 or N tiles.
> >>>>
> >>>> I see the following advantages with the approach using dependent
> >>>> slices instead of defining new FUs:
> >>>>
> >>>> - First of all, no need to define new payload structures.
> >>>>
> >>>> - The RTP packetizer does not need to parse slice headers to
> >>>> identify boundaries of tiles within a coded slice, as tiles of one
> >>>> SLICE are already in separate NAL units each containing a DEPENDENT
> SLICE.
> >>>>
> >>>> - No additional overhead in packetization (the 1-byte FU header and
> >>>> the 2- or 4-byte FU offset). The overhead of the short slice header
> >>>> for dependent slice NAL units is compensated by less number of tile
> >>>> entry offsets signalled, as the entry offset of the first tile in ea=
ch NAL unit
> is not signalled in the slice header.
> >>>> Using dependent slices would need more two-byte NAL unit headers,
> >>>> while using new FUs would need more two-byte packet payload
> >>>> headers, and the overhead bits here are the same for both methods.
> >>>>
> >>>> Am I missing anything here?
> >>>>
> >>>> BR, YK
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> >>>>> Sent: Thursday, July 04, 2013 1:49 AM
> >>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> >>>>> Wenger; Paul Bright-Thomas (paubrigh)
> >>>>> Cc: payload@ietf.org
> >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>> payload format
> >>>>>
> >>>>> Yes, we did think about one tile per packet or N tiles per packet,
> >>>>> also: I guess that is where we started from. Then you could indeed
> >>>>> align missing tiles with missing sequence numbers.
> >>>>>
> >>>>> The issue is that you need to guarantee that you are doing this
> >>>>> for it to be useful, and the decoder needs to know that this is
> >>>>> guaranteed through some form of other signalling. However, the
> >>>>> bitstream chunk associated to a tile is extremely variable, and
> >>>>> many tile chunks would be very small. So there is significant
> >>>>> packetization overhead for them if there
> >>>> is one tile per packet.
> >>>>> Having N>1 reduces this overhead, but it is still there and as N
> >>>>> increases you run the risk of breaking the MTU size which then
> >>>>> requires that you have to re- encode to fit things in and meet the
> >>>>> guarantee. There is definitely no time to re-encode whole tiles,
> >>>>> especially if you are already using them for parallelization. Thus
> >>>>> you might have to break the guarantee and fragment the packet
> >>>>> anyhow, losing
> >>>> the resilience.
> >>>>> The advantage that we see with the proposal is that you can get
> >>>>> fairly similar resilience to regular slice MTU-size matching, but
> >>>>> with much lower overheads as you can have a single regular slice
> >>>>> header per frame, yet
> >>>> have a "dumb"
> >>>>> packetization process and no need to re-encode to hit MTU targets.
> >>>>> In
> >>>>> H264 MTU matching usually means re-encoding just one or two 16x16
> MBs.
> >>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you
> >>>>> are doing tiles then you can get tiny "dangling slices" at the end
> >>>>> of a tile, which means more small packets.
> >>>>>
> >>>>> Best regards
> >>>>>
> >>>>> Thomas
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>>> Sent: 04 July 2013 07:02
> >>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies
> >>>>> (thdavies); Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>>> Cc: payload@ietf.org
> >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>> payload format
> >>>>>
> >>>>>
> >>>>> An interesting idea. Using dependent slices (again :-) together
> >>>>> with tiles would do the trick too (each tile in one dependent
> >>>>> slice, and then each dependent slice NAL unit in one single NAL uni=
t
> packet).
> >>>>>
> >>>>> Have you guys done an analysis comparing the pros and cons of the
> >>>>> two alternative approaches?
> >>>>>
> >>>>> BR, YK
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> >>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
> >>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies);
> >>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Thomas, Paul and I have been working on improving packet loss
> >>>>>> resilience using fragments and tiles. I mentioned this to Stephan
> >>>>>> at IETF 86 in Orlando, and promised to have draft text ready
> >>>>>> before Berlin. Here is the proposed text along with an overview of=
 the
> rationale.
> >>>>>>
> >>>>>> Rationale:
> >>>>>>
> >>>>>> 1. Resilience to packet loss requires independent slices or tiles.
> >>>>>> Since independence requires restrictions on some coding tools,
> >>>>>> both potentially incur slight penalties in coding efficiency,
> >>>>>> with a smaller penalty
> >>>>> for tiles.
> >>>>>> 2. Fragmentation in a higher layer like RTP can have several
> >>>>>> advantages over similar features in a codec layer like slices
> >>>>>> (independent or
> >>>>> dependent).
> >>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity
> >>>>>> while slices have much larger (CTB or tile) granularity. It also
> >>>>>> has less slice segment header overhead, especially for independent
> slices.
> >>>>>> This can impact the efficiency of the packetized stream in terms
> >>>>>> of both bits and
> >>>>> packets per second.
> >>>>>> b. Performance: Encoders must perform extra processing to limit
> >>>>>> slice sizes, which can impact encoder performance. Some
> >>>>>> implementations speculatively end a slice based on computed
> >>>>>> statistics (which aggravates a.), while others recode a slice if
> >>>>>> the size is exceeded (which
> >>>>> aggravates b.).
> >>>>>> c. Decoupling: Not all encoders will support limiting slice size t=
o MTU
> size.
> >>>>>> Applications (for live or stored content) using such encoders can
> >>>>>> still support MTU limits using RTP fragmentation since it is
> >>>>>> decoupled from
> >>>>> the encoder.
> >>>>>> d. Multi-party: The encoded content may go to multiple receivers
> >>>>>> with different MTUs. RTP fragmentation can handle this with
> >>>>>> lightweight repacketization at middle boxes whereas slices incur
> >>>> heavyweight transcoding.
> >>>>>> 3. Combining fragmentation and tiles can improve resilience while
> >>>>>> retaining the above advantages, if fragments are enhanced to
> >>>>>> contain offsets (similar to IP fragmentation). This is described
> >>>>>> in the proposed draft text below, which would immediately follow
> >>>>>> section
> >>>>>> 4.7
> >>>>> Fragmentation Units.
> >>>>>> Draft Text:
> >>>>>>
> >>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
> >>>>>>
> >>>>>> If a fragmented NAL unit contains tiles, its slice segment header
> >>>>>> contains offsets to the data of each tile. These offsets can be
> >>>>>> used for random access to any tile for parallel processing,
> >>>>>> region of interest extraction, and resilience to errors in other
> >>>>>> tiles. These offsets can also be used to provide resilience to
> >>>>>> packet loss, in conjunction with fragment offsets contained in
> >>>>>> two types of fragmentation
> >>>>> units: FU-A2 and FU-A4.
> >>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset
> >>>>>> before the FU payload. FU-A2 contains a 2-byte offset as shown in
> Figure X.
> >>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> >>>>>> indicates the total number of bytes in all prior FU payloads of
> >>>>>> the fragmented
> >>>>> NAL unit.
> >>>>>>
> >>>>>>    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
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset=
  |
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   | FU-A2 offset  |     DONL (optional)           |               =
|
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                         FU payload                            =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |                               :...OPTIONAL RTP padding        =
|
> >>>>>>
> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>>
> >>>>>>                  Figure X   RTP payload format for FU-A2
> >>>>>>
> >>>>>>
> >>>>>>    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
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset=
  |
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A4 offset                             | DONL(optional)=
|
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   | DONL(optional)|                                               =
|
> >>>>>>   +-+-+-+-+-+-+-+-+         FU payload                            =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |                               :...OPTIONAL RTP padding        =
|
> >>>>>>
> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>>
> >>>>>>                  Figure Y   RTP payload format for FU-A4
> >>>>>>
> >>>>>>
> >>>>>> Since the offset of the first FU payload of a fragmented NAL unit
> >>>>>> is zero, and the Start (S) bit in the FU header is sufficient to
> >>>>>> indicate this, the first fragmentation unit of a fragmented NAL
> >>>>>> unit SHOULD use FU-A, but MAY use
> >>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
> >>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
> >>>>>> non-zero offset. The Start
> >>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> >>>>>> contains a non- zero offset, and MUST be set if it contains a zero=
 offset.
> >>>>>>
> >>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation
> >>>>>> unit are also
> >>>> lost.
> >>>>>> However, tiles which are successfully received in their entirety
> >>>>>> can be decoded if their slice segment header containing tile
> >>>>>> offsets is successfully received, despite lost fragmentation
> >>>>>> units. Fragment offsets in FU-A2 or FU-A4 are required in order
> >>>>>> to recover from loss of prior fragmentation units and continue dec=
oding
> subsequent tiles.
> >>>>>>
> >>>>>> The following heuristic SHOULD be applied to determine if the
> >>>>>> lost fragmentation units are all part of the same fragmented NAL
> >>>>>> unit as subsequently received fragmentation units with identical
> >>>>>> RTP timestamps and identical values of NAL unit header layer ID
> >>>>>> and temporal
> >>>> ID.
> >>>>>> 1. Let N be the number of missing sequence numbers between two
> >>>>>> received fragmentation units with known offsets.
> >>>>>> 2. Let P be the FU payload size of the first of the two received F=
Us.
> >>>>>> 3. Let D be the difference in the offsets, minus P.
> >>>>>>   (This is the number of missing FU payload bytes.) 4. Let E be N =
times P.
> >>>>>>   (This is the estimated number of missing FU payload bytes.) 5.
> >>>>>> Let ERROR be the absolute difference between D and E, divided by D=
.
> >>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
> >>>>>> fragmented NAL unit, otherwise it is unlikely.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Mo
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>> On Behalf Of Rickard Sj=F6berg
> >>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
> >>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Dear all,
> >>>>>>
> >>>>>> I wrote slices and not dependent slices since the slice
> >>>>>> granularity and slice/tile rule applies to both slices and depende=
nt slices.
> >>>>>> Sorry for the confusion. I will now use 'independent slices' and
> >>>>>> 'dependent slices' to distinguish between them.
> >>>>>>
> >>>>>> I do not question the use of independent slices, I find them
> >>>>>> useful in some applications.
> >>>>>>
> >>>>>> But the current RTP payload text says:
> >>>>>>
> >>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
> >>>>>>      video telephony, video conferencing, live streaming and live
> >>>>>>      broadcast, in which cases dependent slice segments SHOULD be =
used
> >>>>>>      when a slice should be transported in multiple RTP packets."
> >>>>>>
> >>>>>> I believe that FUs are a viable option to dependent slices for
> >>>>>> the reasons I listed in my previous e-mail and think that we
> >>>>>> should not recommend dependent slices over FUs but leave it to the
> implementer.
> >>>>>>
> >>>>>> BR
> >>>>>> Rickard
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>> On Behalf Of Wang, Ye-Kui
> >>>>>> Sent: den 3 juli 2013 20:43
> >>>>>> To: Thomas Davies; Stephan Wenger
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I drafted an email replying directly to Rickard but did not
> >>>>>> finish and there was a meeting (and then Stephan's and Thomas' ema=
ils
> came).
> >>>>>>
> >>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
> >>>>>> slices, not FUs vs dependent slices, while the recommendation in
> >>>>>> the draft is recommending use of dependent slices over FUs in
> >>>>>> live-encoding scenarios (so this answers Thomas question: the
> >>>>>> intention was
> >>>>> dependent slices ).
> >>>>>> In any case, it does not make much sense to try MTU size matching
> >>>>>> and at the same time use either dependent slices or FUs, because
> >>>>>> dependent slices and FUs should not be used when there are
> >>>>>> considerable packet losses, while MTU size matching should be
> >>>>>> applied when there are
> >>>>> considerable packet losses.
> >>>>>> For live encoding, whenever splitting of a regular slice is
> >>>>>> needed, the splitting can be done by the encoder using dependent
> >>>>>> slices - and the encoder has more knowledge and is more powerful
> >>>>>> than the RTP packetizer and thus can do a better job for the split=
ting.
> >>>>>>
> >>>>>> BR, YK
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>>> On Behalf Of Thomas Davies
> >>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
> >>>>>>> To: Stephan Wenger
> >>>>>>> Cc: payload@ietf.org
> >>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>>> payload format
> >>>>>>>
> >>>>>>> Hi Stephan
> >>>>>>>
> >>>>>>> I think I agree with Rickard.
> >>>>>>>
> >>>>>>> I think the text in question states a preference for _dependent_
> >>>>>>> slice segments, which have no error resiliency advantage over FUs=
.
> >>>>>>> Is this just a
> >>>>>> typo?
> >>>>>>> <snip>
> >>>>>>>
> >>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
> >>>>>>>       video telephony, video conferencing, live streaming and liv=
e
> >>>>>>>       broadcast, in which cases dependent slice segments SHOULD b=
e
> used
> >>>>>>>       when a slice should be transported in multiple RTP packets.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> </snip>
> >>>>>>>
> >>>>>>> In general FUs may be used where error conditions are known to
> >>>>>>> be benign, for greater efficiency, and also where for whatever
> >>>>>>> reason the encoder cannot support MTU matching.
> >>>>>>>
> >>>>>>> We also are formulating some more general comments on this area
> >>>>>>> which we hope to provide more fully soon.
> >>>>>>>
> >>>>>>> best regards
> >>>>>>>
> >>>>>>> Thomas
> >>>>>>>
> >>>>>>>
> >>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
> >>>>>>>> Hi Rickard,
> >>>>>>>> Commenting only on slices vs. FUs.
> >>>>>>>> The preference for slices over FUs, historically, was pushed by
> >>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
> >>>>>>>> moved over to this draft for the same reason.  Loose a slice,
> >>>>>>>> and you can recover at the next slice boundary; loose an FU,
> >>>>>>>> and you have to wait for the next slice header and throw away
> >>>>>>>> all trailing FUs.  RTP is in virtually all cases run over UDP,
> >>>>>>>> and in the typical Internet scenario UDP is lossy (in contrast
> >>>>>>>> to private, managed IP-network, which may have other
> >>>>>>>> constraints, but are not the IETF's main
> >>>>>>>> concern.) To set your remarks into context, let's first
> >>>>>>>> understand what we are talking
> >>>>>>>> about: the cost of slices is the overhead stemming from the
> >>>>>>>> insertion of slice headers (in-picture syntax prediction) and
> >>>>>>>> from the packet headers themselves.  And, of course,
> >>>>>>>> implementation complexity, but we should not be in the business
> >>>>>>>> to encourage implementor
> >>>>>> laziness when
> >>>>>>>> there would be a more complex, but better suited tool available.
> The
> >>>>>>>> additional packetization overhead is only incurred when, as a
> >>>>>>>> result of incompetently filled packets (which, I agree, is more
> >>>>>>>> likely with
> >>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
> >>>>>>>> needs to be inserted.  You may remember a quick analysis of
> >>>>>>>> mine we discussed way back early in JCT, where we (I think)
> >>>>>>>> agreed that the practical impact is negligible in almost all
> >>>>>>>> non-tile scenarios (mostly because an additional overhead of 50
> >>>>>>>> bytes or so--3% or less of the coded picture size) is incurred
> >>>>>>>> statistically only rarely (only in those cases where an
> >>>>>>>> additional packet would need to be generated because of the
> >>>>>>>> video coding related overhead for the use of slices).  The
> >>>>>>>> prediction overhead of the use of regular slices has been shown
> >>>>>>>> to be substantial--the price one needs to pay for independent
> >>>>>>>> decodability--but for entropy slices that overhead virtually
> >>>>>> does not exist.
> >>>>>>>> With respect to tiles, I think you have a point though,
> >>>>>>>> especially when considering the type of massive parallel
> >>>>>>>> implementations for relatively small picture sizes some folks
> >>>>>>>> have been
> >>>> considering.
> >>>>>>>> OTOH, because FUs are trivial to implement--some say in
> >>>>>>>> contrast to slices--and because (I hope) we all agree that
> >>>>>>>> using FUs in error prone scenarios is a bad idea if you could
> >>>>>>>> use slices (but for reasons like the tile connection you
> >>>>>>>> mentioned), the draft should IMO continue to set a preference
> >>>>>>>> for the use of regular slices over FUs.  To avoid
> >>>>>>>> underperforming systems due to implementer
> >>>>> laziness.
> >>>>>>>> However, this is the IETF.  We don't have to worry about the
> >>>>>>>> word-count of explanatory language.  In fact, explaining such
> >>>>>>>> complex tradeoffs and relationships is generally encouraged here=
.
> >>>>>>>> So let's
> >>>>>> just do that:
> >>>>>>>> express a preference of the use of regular slices (SHOULD) when
> >>>>>>>> you expect losses and can use them (real-time encoding, no
> >>>>>>>> tiling structure that would lead to unacceptable packetization
> >>>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
> >>>>>>>> Accompanied by a more coherently expressed analysis.
> >>>>>>>> Stephan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 7.3.2013 06:46 , "Rickard
> >>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
> >>>>>> wrote:
> >>>>>>>>> Hi Ye-Kui,
> >>>>>>>>>
> >>>>>>>>> Thanks for your feedback on my comments, your suggestions look
> >>>>>>>>> good to
> >>>>>>> me.
> >>>>>>>>> Regarding discouraging fragmentation units (FUs) for
> >>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
> >>>>>>>>> make sense when you do not have many non-VLC NAL units for
> >>>>>>>>> aggregation. The spatial granularity of slices was 16x16
> >>>>>>>>> pixels in H.264 but is typically
> >>>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
> >>>>>>>>> units that are 16x larger. This may lead to a larger number of
> >>>>>>>>> smaller packets when slices are used compared to FUs. In
> >>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
> >>>>>>>>> that makes the slice granularity equal to the tile granularity
> >>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
> >>>>>>>>> easier to implement since you do not need to care about when
> >>>>>>>>> to break your slice to not exceed the MTU size limit. I think
> >>>>>>>>> both slices and FUs has their merits and the choice between
> >>>>>>>>> them for live-encoding should be left for
> >>>>>> the implementer.
> >>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and
> >>>>>>>>> 8.2 and the POC MSB sync issue, I agree that this is a corner
> >>>>>>>>> case that we probably will not see much of in practice. I have
> >>>>>>>>> no text change suggestion at the moment.
> >>>>>>>>>
> >>>>>>>>> BR
> >>>>>>>>> Rickard
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>>>>>>> Sent: den 24 juni 2013 01:00
> >>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
> >>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>>>>>>> format
> >>>>>>>>>
> >>>>>>>>> Hi Rickard,
> >>>>>>>>>
> >>>>>>>>> Thanks for the careful review and the comments. Please see
> >>>>>>>>> inline
> >>>> below.
> >>>>>>>>> BR, YK
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
> >>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
> >>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>>>>>>>> format
> >>>>>>>>>>
> >>>>>>>>>> Dear all,
> >>>>>>>>>>
> >>>>>>>>>> I have taken a first look at
> >>>>>>>>>> draft-schierl-payload-rtp-h265-03 and have some
> questions/comments.
> >>>>>>>>>>
> >>>>>>>>>> My first question is what extensions of HEVC that
> >>>>>>>>>> draft-schierl-payload-rtp-
> >>>>>>>>>> h265 is intended to cover? The draft mentions "future
> >>>>>>>>>> scalable or 3D  video coding  extensions  of  this
> >>>>>>>>>> specification", what extensions do you refer to?
> >>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
> >>>>>>>>>> payload specification?
> >>>>>>>>>>
> >>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> >>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
> >>>>>>>>> sort of copy-and-paste error. Thanks for the good catching.
> >>>>>>>>> No, there is no intention to cover HEVC extensions in this
> >>>>>>>>> payload specification, though we intentionally to have the
> >>>>>>>>> depacketization process and the use with feedback messages to
> >>>>>>>>> work for HEVC scalability
> >>>>>> and 3DV extensions.
> >>>>>>>>>> Another question for my understanding is why "Receivers MUST
> >>>>>>>>>> pass picture timing SEI messages and decoding unit
> >>>>>>>>>> information SEI messages to the decoder"?
> >>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
> >>>>>>>>> specified by the video coding spec to the video decoders. This
> >>>>>>>>> is emphasized here for the two timing related SEI messages
> >>>>>>>>> after it is said that picture output timing in RTP timestamps
> >>>>>>>>> should be used instead (to avoid giving a wrong impression to
> >>>>>>>>> readers that the SEI messages should be ignored). If an RTP
> >>>>>>>>> receiver discards the SEI messages, then HRD conformance
> >>>>>>>>> checking for the bitstream that was possible would be
> >>>>>>>>> disabled, and also the information related to frame
> >>>>>>> doubling or tripping would be lost.
> >>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> >>>>>>>>>> The fourth one does not seem to be a rule since there is no
> >>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
> >>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
> >>>>>>>>> to put this as a packetization rule is to put it as part of
> >>>>>>>>> the semantics of NAL unit header (1.1.4), but that sub-section
> >>>>>>>>> belongs to an overview wherein normative language (even "MAY")
> >>>>>>>>> should not appear. One solution to this is to insert "Payload
> >>>>>>>>> Header
> >>>>> Usage"
> >>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item the=
re.
> >>>>>>>>> I will do this in the next version unless there is a better sug=
gestion.
> >>>>>>>>>
> >>>>>>>>>> Further, the fifth one discourages using FUs, what are the
> >>>>>>>>>> reasons behind that?
> >>>>>>>>> [YK] The bullet item only discourages using FUs for
> >>>>>>>>> live-encoding scenarios, wherein dependent slice segments
> >>>>>>>>> should be
> >>>> used instead.
> >>>>>>>>> This was added after a discussion (among the authors) on the
> >>>>>>>>> need of whether to specify a payload structure for mixed FU
> >>>>>>>>> and aggregation packets and from that discussion we concluded
> >>>>>>>>> that encoding dependent slice segments at source coding level
> >>>>>>>>> already allows for the use cases and using of FUs for
> >>>>>>>>> live-encoding does not make sense. Please let us know if you
> >>>>>>>>> think differently.
> >>>>>>>>>
> >>>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal=
.
> >>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> >>>>>>>>>> differ between the encoder and decoder?
> >>>>>>>>> [YK] Good question. In theory this is indeed possible when
> >>>>>>>>> random accessing to a bitstream is performed. However, it
> >>>>>>>>> would not happen in conversational applications where the
> >>>>>>>>> feedback messages may
> >>>>> be used.
> >>>>>>>>> Therefore, to me this would just work just fine. But please
> >>>>>>>>> feel free to make other suggestions.
> >>>>>>>>>
> >>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
> >>>>>>>>>> be useful, let me come back to that later on.
> >>>>>>>>>>
> >>>>>>>>> [YK] OK. Look forward to seeing your input herein.
> >>>>>>>>>
> >>>>>>>>>> I have also a number of spelling suggestions for your
> considerations:
> >>>>>>>>>>
> >>>>>>>>>> Section 1.1:
> >>>>>>>>>> Replace "community" by "communities"
> >>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per
> >>>>>>>>> your suggestion (for the next version).
> >>>>>>>>>
> >>>>>>>>>> Section 1.1.1:
> >>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
> >>>>>>>>>> the interpolation filter"
> >>>>>>>>> [YK] Thanks - done.
> >>>>>>>>>
> >>>>>>>>>> Replace "skipping the transform coding" by "skipping the
> transform"
> >>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
> >>>>>>>>>> coding)
> >>>>>>>>>>
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 1.1.2:
> >>>>>>>>>> Replace:
> >>>>>>>>>> "2) An indication of whether there is any parameter set
> >>>>>>>>>> within the current coded video sequence that updates another
> >>>>>>>>>> parameter set of the same type preceding in decoding order."
> >>>>>>>>>> by:
> >>>>>>>>>> "2) An indication of whether there is no parameter set update
> >>>>>>>>>> in the coded video sequence."
> >>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC
> indicates.
> >>>>>>>>>>
> >>>>>>>>> [YK] Changed the wording to "An indication of whether there is
> >>>>>>>>> no parameter set within the current coded video sequence that
> >>>>>>>>> updates another parameter set of the same type preceding in
> >>>>>>>>> decoding
> >>>>> order."
> >>>>>>>>>> Section 4.7:
> >>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> >>>>>>>>>> and "FU
> >>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload
> header.
> >>>>>>>>>>
> >>>>>>>>> [YK] Good point again. I will change the field name to be "FuTy=
pe".
> >>>>>>>>>
> >>>>>>>>>> Section 6:
> >>>>>>>>>> Replace "recovery" by "recover"
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 7.1:
> >>>>>>>>>> Replace "level-id" by "level-idc"
> >>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
> >>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "id=
c".
> >>>>>>>>>
> >>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 8:
> >>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
> >>>>>>>>>> payload-specific feedback  message", since only SPLI is
> >>>>>>>>>> "Assigned in this memo".
> >>>>>>>>>> Also, consider removing references to H.264 in the last
> >>>>>>>>>> paragraph of Section
> >>>>>>>>>> 8 since the memo is about HEVC.
> >>>>>>>>> [YK] Good catch again. Changed.
> >>>>>>>>>
> >>>>>>>>>> Section 8.1:
> >>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
> >>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
> >>>>>>>>>> contained in the FCI field"
> >>>>>>>>> [YK] Another good catch. Changed.
> >>>>>>>>>
> >>>>>>>>>> Best Regards,
> >>>>>>>>>> Rickard Sj=F6berg
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: payload-bounces@ietf.org
> >>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> >>>>>>>>>> Sent: den 11 juni 2013 19:00
> >>>>>>>>>> To: payload@ietf.org
> >>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
> >>>>>>>>>> payload format
> >>>>>>>>>>
> >>>>>>>>>> Dear All,
> >>>>>>>>>>
> >>>>>>>>>> We have just submitted versions 02 and 03 of
> >>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as fol=
lows:
> >>>>>>>>>>
> >>>>>>>>>> Version 02:
> >>>>>>>>>> URL:
> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp
> >>>>>>>>>> -
> >>>>>>>>>> h265-02.txt
> >>>>>>>>>> Htmlized:
> >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>>>>>>>>> Diff:
> >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h=
2
> >>>>>>>>>> 6
> >>>>>>>>>> 5-
> >>>>>>>>>> 02
> >>>>>>>>>>
> >>>>>>>>>> Version 03:
> >>>>>>>>>> URL:
> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp
> >>>>>>>>>> -
> >>>>>>>>>> h265-03.txt
> >>>>>>>>>> Htmlized:
> >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>>>>>>>>> Diff:
> >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h=
2
> >>>>>>>>>> 6
> >>>>>>>>>> 5-
> >>>>>>>>>> 03
> >>>>>>>>>>
> >>>>>>>>>> Version 02 includes huge changes compared to the earlier
> >>>>>>>>>> submitted version 01. In a short summary, the authors have
> >>>>>>>>>> worked hard to try to make the design complete, from both the
> >>>>>>>>>> payload structure and the signaling points of view. Compared
> >>>>>>>>>> to version 02, version
> >>>>>>>>>> 03 only contains a correction of the email address of an autho=
r.
> >>>>>>>>>>
> >>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
> >>>>>>>>>> other standards bodies such as 3GPP rely on the payload
> >>>>>>>>>> format for support of H.265/HEVC in RTP based video services,
> >>>>>>>>>> we need to progress this draft relatively quickly.
> >>>>>>>>>> Therefore, we would like to request quick reviews from
> >>>>>>>>>> interested parties and also request for the WG status of this =
draft.
> >>>>>>>>>>
> >>>>>>>>>> BR, YK (on behalf of the authors)
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> payload mailing list
> >>>>>>>>>> payload@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> payload mailing list
> >>>>>>>>> payload@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>>> _______________________________________________
> >>>>>>>> payload mailing list
> >>>>>>>> payload@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>> _______________________________________________
> >>>>>>> payload mailing list
> >>>>>>> payload@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>> _______________________________________________
> >>>>>> payload mailing list
> >>>>>> payload@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>> _______________________________________________
> >>>>>> 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 mzanaty@cisco.com  Sun Jul  7 20:48:42 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82F21F9C61 for <payload@ietfa.amsl.com>; Sun,  7 Jul 2013 20:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.374
X-Spam-Level: 
X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5S1ZAjND8nG for <payload@ietfa.amsl.com>; Sun,  7 Jul 2013 20:48:37 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7321F9C60 for <payload@ietf.org>; Sun,  7 Jul 2013 20:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45647; q=dns/txt; s=iport; t=1373255316; x=1374464916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JPSR8mptvZMIRlOFeNMirmhLUPEBLNjoq/GVrHJIzTQ=; b=N6YIHYHGL5qSoYVNI4Dh8+8ePAVe0cbTjXM/F0u0s0LQ/mtFA2oATJM0 NPXh/X4RE3I26mQSkFgPUSGJbHMaHYHhcjDffEREa2cmjJQ/fM073OtS5 6usRQCoB8gX7bguXctdhyvqQx2Vkmg+hwtpWEvuOwmb9YzPbJo3Y1nIrc I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFANM12lGtJXG+/2dsb2JhbABQCoMJMkcGwGGBDRZ0giMBAQEEAQEBFwFMBwQHDAQCAQgRBAEBAQoLEgcnCxQJCAIEAQ0FCAELB4d0BwW4E4xxgS4KAQUFBYEBMQcGBIJ9aQOIbYsThHyQH4MRgWkIFyA
X-IronPort-AV: E=Sophos;i="4.87,1016,1363132800"; d="scan'208";a="231896587"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jul 2013 03:48:35 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r683mYdQ017422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 03:48:34 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Sun, 7 Jul 2013 22:48:33 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>, Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>, "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeCTOo/1Zj2Q7hkmxvsQohaKfo5lTadyAgALAqzyAAAVP0IAAZE2AgAN87fA=
Date: Mon, 8 Jul 2013 03:48:33 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48FB59@xmb-rcd-x14.cisco.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com> <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de> <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A833845BCCC@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A833845BCCC@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.236.110]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 03:48:42 -0000

Hi YK,

This is not about decoder conformance. Almost all decoders fully conform to=
 the standards they support (for their advertised profiles/levels). This is=
 about encoder feature set and APIs for tool selection. Even today, after a=
 decade of H.264, most popular hardware chipsets don't support encoder MTU =
slicing at all, or with degraded performance, or with constraints on other =
features (e.g. CABAC). Preliminary information on H.265 plans seems to mirr=
or this.

While I certainly agree we should influence encoders to support dependent s=
lices, I think we should also give RTP applications the best tools to work =
with any encoder (or at least the most popular encoders). Remember, this is=
 the spec for RTP applications, not the spec for encoder designers.

Cheers,
Mo

-----Original Message-----
From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]=20
Sent: Friday, July 05, 2013 11:57 AM
To: Mo Zanaty (mzanaty); Thomas Schierl; Thomas Davies (thdavies)
Cc: Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas (paubrigh); paylo=
ad@ietf.org
Subject: RE: [payload] Submission of new versions of H.265/HEVC payload for=
mat

Hi Mo,

FUs IMO are mainly used for fragmenting big slices for stored /pre-encoded =
contents. Though I agreed not to discourage the use of FUs for live-encodin=
g scenarios, I agreed on the basis that MTU size matching can be used for o=
ther purposes than error resilience. For error resilience purposes in live-=
encoding scenarios, I still don't think using FUs is a good choice, as Step=
han also mentioned and others basically agreed too. Note also that actually=
 FUs came earlier (as they were included in H.264 payload and this draft in=
herited a lot of stuff from the H.264 payload spec) than dependent slices (=
only in H.265).

>From the discussions so far, for the error resilience optimization you guys=
 are trying to achieve, my understanding is that using dependent slices can=
 achieve at least the same performance, and conforming H.265 decoders are r=
equired to support dependent slices anyway.

BR, YK

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: Friday, July 05, 2013 8:32 AM
> To: Thomas Schierl; Thomas Davies (thdavies)
> Cc: Wang, Ye-Kui; Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas
> (paubrigh); payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Thomas,
>=20
> Please see my reply to YK about why some RTP apps may prefer (or be force=
d
> to use) fragmentation rather than dependent slice segments. The current d=
raft
> supports resilience using tiles with dependent slice segments. The propos=
ed
> enhancement supports resilience using tiles with fragmentation.
>=20
> I understand that dependent slice segments were specifically added to all=
ow a
> form of codec level fragmentation at finer granularity than slices. Howev=
er,
> they are not always sufficient, desirable or even available in all cases =
of interest
> for RTP apps. If they were, there would be no need for RTP level fragment=
ation
> at all. Since the current draft supports RTP level fragmentation, I assum=
e there
> is consensus among the authors that there is value in it. The proposed
> enhancement extends that value by also supporting resilience, so RTP apps
> which use fragmentation can also support resilience.
>=20
> Regards,
> Mo
>=20
> -----Original Message-----
> From: Thomas Schierl [mailto:thomas.schierl@hhi.fraunhofer.de]
> Sent: Friday, July 05, 2013 10:39 AM
> To: Thomas Davies (thdavies)
> Cc: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan Wenger;
> Paul Bright-Thomas (paubrigh); payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Dear Thomas,
>=20
> For the error resilience in the case of slices or dependent slices, which=
 do match
> with tiles, I do not think an additional pointer information in the FU he=
ader
> does improve the error resilience capabilities over a system without thos=
e
> information.
>=20
> I think I did not exclude the use of FUs even for dependent slice fragmen=
ts, but
> I would not require an additional mechanism to those, as stated in my ema=
il
> before.
>=20
> Thomas
> --
>=20
> Dr.-Ing. Thomas Schierl
>=20
> Head of Multimedia Communications Group
> Image Processing Department
> thomas.schierl@hhi.fraunhofer.de
>=20
> Tel.:  +49 30 31002-227
> Fax:  +49 30 31002-190
> Skype:  thomas.schierl
>=20
> Fraunhofer HHI - Heinrich Hertz Institute Einsteinufer 37, 10587 Berlin,
> Germany http://www.hhi.fraunhofer.de/ip/mc
>=20
> Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:
>=20
> > Dear Thomas
> >
> > On your first point, the decoder always has to be told there is missing=
 data. I
> don't see much different or fancy in the interface between the two cases.
> Usually error concealment must be addressed both within the codec (becaus=
e
> of reference dependencies) and also in the application (because of displa=
y and
> call-management/error response functionality). That's surely a very minor=
 issue.
> >
> > On the second point, the context we are considering in our proposal is =
where
> FUs are being used, in the circumstances Mo set out, and providing some l=
evel
> of sub-frame resilience where possible in that case. If your assumption i=
s that
> FUs are not being used, and re-writing is possible/desirable, you will ce=
rtainly
> conclude that FUs should not be used. Since we concluded that FUs should =
not
> be discouraged, it seems reasonable to consider adding features which mak=
e
> them more resilient when they are.
> >
> > best regards
> >
> > Thomas
> >
> > On 05/07/13 10:34, Thomas Schierl wrote:
> >> Dear Ye-Kui, all,
> >>
> >> Further I would tentatively assume that you can use the slice segment
> address in the dependent slice fragment header for the same degree of err=
or
> resilience as the new-FU header, if you put a tile into a dependent slice=
. And
> this part would be understood by the decoder itself, which should be able=
 to do
> the error resilience on codec level. Without fancy interfaces into the de=
coder,
> etc.
> >>
> >> A point in the discussion which seems to be missing is that the rewrit=
ing of a
> single slice into multiple dependent slice fragments (including also one
> independent slice fragment) can be done at very low processing costs, as =
shown
> during the standardization of HEVC.
> >>
> >> Thomas
> >> --
> >> Thomas Schierl
> >> Fraunhofer HHI
> >>
> >> Am 04.07.2013 um 19:59 schrieb "Wang, Ye-
> Kui"<yekuiw@qti.qualcomm.com>:
> >>
> >>> Hi Thomas,
> >>>
> >>> Thanks for the clarification - I think now understand your scheme bet=
ter.
> >>>
> >>> So you did not intent to encapsulate only entire tiles into packets, =
though
> that would obviously be more error resilient as you won't encounter the
> problem where a part of a tile gets lost and the received rest becomes us=
eless.
> Rather, one tile may be carried in two (or even more) packets.
> >>>
> >>> I think I was confused by the suggested language such as "If a
> fragmentation unit is lost, tiles in the lost fragmentation unit are also=
 lost.
> However, tiles which are successfully received in their entirety can be d=
ecoded
> if their slice segment header containing tile offsets is successfully rec=
eived,
> despite lost fragmentation units.", from where I got an impression that a=
n FU
> includes entire tiles.
> >>>
> >>> As seen from other discussions, it is very questionable how big a pen=
alty
> would be when an encoder tries to splitting encoded data into separate NA=
L
> units (slices or dependent slices) for MTU size matching, even for large =
CTB
> sizes - that's the reason why the JCT-VC later decided to remove the fine=
-
> granularity slice feature.
> >>>
> >>> Let's tentatively assume that overall penalty and the overhead of the=
 new-
> FU approach are roughly equivalent, and take into account latest comments
> from Mo and Stephan, do we see an advantage of the new-FU approach
> compared to using dependent slices?
> >>>
> >>> I am not trying to conclude yet - just try to (very briefly) summariz=
e the
> situation so far at least for myself.  We should certainly have more disc=
ussions -
> preferable involving more people who care about this payload format.
> >>>
> >>> BR, YK
> >>>
> >>>> -----Original Message-----
> >>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> >>>> Sent: Thursday, July 04, 2013 9:23 AM
> >>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> >>>> Wenger; Paul Bright-Thomas (paubrigh)
> >>>> Cc: payload@ietf.org
> >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>> payload format
> >>>>
> >>>> Hi Ye-Kui
> >>>>
> >>>> Thank you for the clarification - I understand your point a bit bett=
er now.
> >>>>
> >>>> With the proposed scheme there is no need for the RTP packetizer to
> >>>> parse slice headers or identify tile boundaries. All it needs to do
> >>>> is to keep track of the offset of the start of the payload to the
> >>>> beginning of the NALU and put this into the field. It needs to know
> >>>> this offset anyway. The packetizer is completely dumb.
> >>>>
> >>>> The point is that a decoder wishing to do error resilience can
> >>>> parse the slice header and identify the tile boundaries in the case
> >>>> that a packet goes missing, for tiles that occur in the same frame
> >>>> but after the packet that is lost. The decoder can compare the tile
> >>>> offsets with the FU offsets to work out what data is missing.
> >>>>
> >>>> Re dependent slices, there are indirect overheads as well, which
> >>>> come from having to quantize the packet size to a whole number of
> >>>> tiles, plus you have to manage the encoder to match the MTU size.
> >>>> The granularity of tiles you need for your parallel processing may
> >>>> not match the granularity you need to fit in the MTU very well.
> >>>>
> >>>> Best regards
> >>>>
> >>>> Thomas
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>> Sent: 04 July 2013 16:34
> >>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard Sj=F6berg=
;
> >>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>> Cc: payload@ietf.org
> >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>> payload format
> >>>>
> >>>> Hi Thomas,
> >>>>
> >>>> My point was really about using dependent slices, not about 1 or N
> >>>> tiles per packets (sorry that I did not make that clearer).
> >>>> Whatever strategy you would like to do in terms of the number of
> >>>> tiles in a packet, using dependent slices can do the same, as each
> dependent slice can include 1 or N tiles.
> >>>>
> >>>> I see the following advantages with the approach using dependent
> >>>> slices instead of defining new FUs:
> >>>>
> >>>> - First of all, no need to define new payload structures.
> >>>>
> >>>> - The RTP packetizer does not need to parse slice headers to
> >>>> identify boundaries of tiles within a coded slice, as tiles of one
> >>>> SLICE are already in separate NAL units each containing a DEPENDENT
> SLICE.
> >>>>
> >>>> - No additional overhead in packetization (the 1-byte FU header and
> >>>> the 2- or 4-byte FU offset). The overhead of the short slice header
> >>>> for dependent slice NAL units is compensated by less number of tile
> >>>> entry offsets signalled, as the entry offset of the first tile in ea=
ch NAL unit
> is not signalled in the slice header.
> >>>> Using dependent slices would need more two-byte NAL unit headers,
> >>>> while using new FUs would need more two-byte packet payload
> >>>> headers, and the overhead bits here are the same for both methods.
> >>>>
> >>>> Am I missing anything here?
> >>>>
> >>>> BR, YK
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> >>>>> Sent: Thursday, July 04, 2013 1:49 AM
> >>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> >>>>> Wenger; Paul Bright-Thomas (paubrigh)
> >>>>> Cc: payload@ietf.org
> >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>> payload format
> >>>>>
> >>>>> Yes, we did think about one tile per packet or N tiles per packet,
> >>>>> also: I guess that is where we started from. Then you could indeed
> >>>>> align missing tiles with missing sequence numbers.
> >>>>>
> >>>>> The issue is that you need to guarantee that you are doing this
> >>>>> for it to be useful, and the decoder needs to know that this is
> >>>>> guaranteed through some form of other signalling. However, the
> >>>>> bitstream chunk associated to a tile is extremely variable, and
> >>>>> many tile chunks would be very small. So there is significant
> >>>>> packetization overhead for them if there
> >>>> is one tile per packet.
> >>>>> Having N>1 reduces this overhead, but it is still there and as N
> >>>>> increases you run the risk of breaking the MTU size which then
> >>>>> requires that you have to re- encode to fit things in and meet the
> >>>>> guarantee. There is definitely no time to re-encode whole tiles,
> >>>>> especially if you are already using them for parallelization. Thus
> >>>>> you might have to break the guarantee and fragment the packet
> >>>>> anyhow, losing
> >>>> the resilience.
> >>>>> The advantage that we see with the proposal is that you can get
> >>>>> fairly similar resilience to regular slice MTU-size matching, but
> >>>>> with much lower overheads as you can have a single regular slice
> >>>>> header per frame, yet
> >>>> have a "dumb"
> >>>>> packetization process and no need to re-encode to hit MTU targets.
> >>>>> In
> >>>>> H264 MTU matching usually means re-encoding just one or two 16x16
> MBs.
> >>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if you
> >>>>> are doing tiles then you can get tiny "dangling slices" at the end
> >>>>> of a tile, which means more small packets.
> >>>>>
> >>>>> Best regards
> >>>>>
> >>>>> Thomas
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>>> Sent: 04 July 2013 07:02
> >>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies
> >>>>> (thdavies); Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>>> Cc: payload@ietf.org
> >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>> payload format
> >>>>>
> >>>>>
> >>>>> An interesting idea. Using dependent slices (again :-) together
> >>>>> with tiles would do the trick too (each tile in one dependent
> >>>>> slice, and then each dependent slice NAL unit in one single NAL uni=
t
> packet).
> >>>>>
> >>>>> Have you guys done an analysis comparing the pros and cons of the
> >>>>> two alternative approaches?
> >>>>>
> >>>>> BR, YK
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> >>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
> >>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies);
> >>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Thomas, Paul and I have been working on improving packet loss
> >>>>>> resilience using fragments and tiles. I mentioned this to Stephan
> >>>>>> at IETF 86 in Orlando, and promised to have draft text ready
> >>>>>> before Berlin. Here is the proposed text along with an overview of=
 the
> rationale.
> >>>>>>
> >>>>>> Rationale:
> >>>>>>
> >>>>>> 1. Resilience to packet loss requires independent slices or tiles.
> >>>>>> Since independence requires restrictions on some coding tools,
> >>>>>> both potentially incur slight penalties in coding efficiency,
> >>>>>> with a smaller penalty
> >>>>> for tiles.
> >>>>>> 2. Fragmentation in a higher layer like RTP can have several
> >>>>>> advantages over similar features in a codec layer like slices
> >>>>>> (independent or
> >>>>> dependent).
> >>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity
> >>>>>> while slices have much larger (CTB or tile) granularity. It also
> >>>>>> has less slice segment header overhead, especially for independent
> slices.
> >>>>>> This can impact the efficiency of the packetized stream in terms
> >>>>>> of both bits and
> >>>>> packets per second.
> >>>>>> b. Performance: Encoders must perform extra processing to limit
> >>>>>> slice sizes, which can impact encoder performance. Some
> >>>>>> implementations speculatively end a slice based on computed
> >>>>>> statistics (which aggravates a.), while others recode a slice if
> >>>>>> the size is exceeded (which
> >>>>> aggravates b.).
> >>>>>> c. Decoupling: Not all encoders will support limiting slice size t=
o MTU
> size.
> >>>>>> Applications (for live or stored content) using such encoders can
> >>>>>> still support MTU limits using RTP fragmentation since it is
> >>>>>> decoupled from
> >>>>> the encoder.
> >>>>>> d. Multi-party: The encoded content may go to multiple receivers
> >>>>>> with different MTUs. RTP fragmentation can handle this with
> >>>>>> lightweight repacketization at middle boxes whereas slices incur
> >>>> heavyweight transcoding.
> >>>>>> 3. Combining fragmentation and tiles can improve resilience while
> >>>>>> retaining the above advantages, if fragments are enhanced to
> >>>>>> contain offsets (similar to IP fragmentation). This is described
> >>>>>> in the proposed draft text below, which would immediately follow
> >>>>>> section
> >>>>>> 4.7
> >>>>> Fragmentation Units.
> >>>>>> Draft Text:
> >>>>>>
> >>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
> >>>>>>
> >>>>>> If a fragmented NAL unit contains tiles, its slice segment header
> >>>>>> contains offsets to the data of each tile. These offsets can be
> >>>>>> used for random access to any tile for parallel processing,
> >>>>>> region of interest extraction, and resilience to errors in other
> >>>>>> tiles. These offsets can also be used to provide resilience to
> >>>>>> packet loss, in conjunction with fragment offsets contained in
> >>>>>> two types of fragmentation
> >>>>> units: FU-A2 and FU-A4.
> >>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset
> >>>>>> before the FU payload. FU-A2 contains a 2-byte offset as shown in
> Figure X.
> >>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> >>>>>> indicates the total number of bytes in all prior FU payloads of
> >>>>>> the fragmented
> >>>>> NAL unit.
> >>>>>>
> >>>>>>    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
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offset=
  |
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   | FU-A2 offset  |     DONL (optional)           |               =
|
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                         FU payload                            =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |                               :...OPTIONAL RTP padding        =
|
> >>>>>>
> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>>
> >>>>>>                  Figure X   RTP payload format for FU-A2
> >>>>>>
> >>>>>>
> >>>>>>    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
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offset=
  |
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |      FU-A4 offset                             | DONL(optional)=
|
> >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   | DONL(optional)|                                               =
|
> >>>>>>   +-+-+-+-+-+-+-+-+         FU payload                            =
|
> >>>>>>   |                                                               =
|
> >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> >>>>>>   |                               :...OPTIONAL RTP padding        =
|
> >>>>>>
> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>>
> >>>>>>                  Figure Y   RTP payload format for FU-A4
> >>>>>>
> >>>>>>
> >>>>>> Since the offset of the first FU payload of a fragmented NAL unit
> >>>>>> is zero, and the Start (S) bit in the FU header is sufficient to
> >>>>>> indicate this, the first fragmentation unit of a fragmented NAL
> >>>>>> unit SHOULD use FU-A, but MAY use
> >>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
> >>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
> >>>>>> non-zero offset. The Start
> >>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> >>>>>> contains a non- zero offset, and MUST be set if it contains a zero=
 offset.
> >>>>>>
> >>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation
> >>>>>> unit are also
> >>>> lost.
> >>>>>> However, tiles which are successfully received in their entirety
> >>>>>> can be decoded if their slice segment header containing tile
> >>>>>> offsets is successfully received, despite lost fragmentation
> >>>>>> units. Fragment offsets in FU-A2 or FU-A4 are required in order
> >>>>>> to recover from loss of prior fragmentation units and continue dec=
oding
> subsequent tiles.
> >>>>>>
> >>>>>> The following heuristic SHOULD be applied to determine if the
> >>>>>> lost fragmentation units are all part of the same fragmented NAL
> >>>>>> unit as subsequently received fragmentation units with identical
> >>>>>> RTP timestamps and identical values of NAL unit header layer ID
> >>>>>> and temporal
> >>>> ID.
> >>>>>> 1. Let N be the number of missing sequence numbers between two
> >>>>>> received fragmentation units with known offsets.
> >>>>>> 2. Let P be the FU payload size of the first of the two received F=
Us.
> >>>>>> 3. Let D be the difference in the offsets, minus P.
> >>>>>>   (This is the number of missing FU payload bytes.) 4. Let E be N =
times P.
> >>>>>>   (This is the estimated number of missing FU payload bytes.) 5.
> >>>>>> Let ERROR be the absolute difference between D and E, divided by D=
.
> >>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
> >>>>>> fragmented NAL unit, otherwise it is unlikely.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Mo
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>> On Behalf Of Rickard Sj=F6berg
> >>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
> >>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Dear all,
> >>>>>>
> >>>>>> I wrote slices and not dependent slices since the slice
> >>>>>> granularity and slice/tile rule applies to both slices and depende=
nt slices.
> >>>>>> Sorry for the confusion. I will now use 'independent slices' and
> >>>>>> 'dependent slices' to distinguish between them.
> >>>>>>
> >>>>>> I do not question the use of independent slices, I find them
> >>>>>> useful in some applications.
> >>>>>>
> >>>>>> But the current RTP payload text says:
> >>>>>>
> >>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
> >>>>>>      video telephony, video conferencing, live streaming and live
> >>>>>>      broadcast, in which cases dependent slice segments SHOULD be =
used
> >>>>>>      when a slice should be transported in multiple RTP packets."
> >>>>>>
> >>>>>> I believe that FUs are a viable option to dependent slices for
> >>>>>> the reasons I listed in my previous e-mail and think that we
> >>>>>> should not recommend dependent slices over FUs but leave it to the
> implementer.
> >>>>>>
> >>>>>> BR
> >>>>>> Rickard
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>> On Behalf Of Wang, Ye-Kui
> >>>>>> Sent: den 3 juli 2013 20:43
> >>>>>> To: Thomas Davies; Stephan Wenger
> >>>>>> Cc: payload@ietf.org
> >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>> payload format
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I drafted an email replying directly to Rickard but did not
> >>>>>> finish and there was a meeting (and then Stephan's and Thomas' ema=
ils
> came).
> >>>>>>
> >>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
> >>>>>> slices, not FUs vs dependent slices, while the recommendation in
> >>>>>> the draft is recommending use of dependent slices over FUs in
> >>>>>> live-encoding scenarios (so this answers Thomas question: the
> >>>>>> intention was
> >>>>> dependent slices ).
> >>>>>> In any case, it does not make much sense to try MTU size matching
> >>>>>> and at the same time use either dependent slices or FUs, because
> >>>>>> dependent slices and FUs should not be used when there are
> >>>>>> considerable packet losses, while MTU size matching should be
> >>>>>> applied when there are
> >>>>> considerable packet losses.
> >>>>>> For live encoding, whenever splitting of a regular slice is
> >>>>>> needed, the splitting can be done by the encoder using dependent
> >>>>>> slices - and the encoder has more knowledge and is more powerful
> >>>>>> than the RTP packetizer and thus can do a better job for the split=
ting.
> >>>>>>
> >>>>>> BR, YK
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]
> >>>>>>> On Behalf Of Thomas Davies
> >>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
> >>>>>>> To: Stephan Wenger
> >>>>>>> Cc: payload@ietf.org
> >>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> >>>>>>> payload format
> >>>>>>>
> >>>>>>> Hi Stephan
> >>>>>>>
> >>>>>>> I think I agree with Rickard.
> >>>>>>>
> >>>>>>> I think the text in question states a preference for _dependent_
> >>>>>>> slice segments, which have no error resiliency advantage over FUs=
.
> >>>>>>> Is this just a
> >>>>>> typo?
> >>>>>>> <snip>
> >>>>>>>
> >>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
> >>>>>>>       video telephony, video conferencing, live streaming and liv=
e
> >>>>>>>       broadcast, in which cases dependent slice segments SHOULD b=
e
> used
> >>>>>>>       when a slice should be transported in multiple RTP packets.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> </snip>
> >>>>>>>
> >>>>>>> In general FUs may be used where error conditions are known to
> >>>>>>> be benign, for greater efficiency, and also where for whatever
> >>>>>>> reason the encoder cannot support MTU matching.
> >>>>>>>
> >>>>>>> We also are formulating some more general comments on this area
> >>>>>>> which we hope to provide more fully soon.
> >>>>>>>
> >>>>>>> best regards
> >>>>>>>
> >>>>>>> Thomas
> >>>>>>>
> >>>>>>>
> >>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
> >>>>>>>> Hi Rickard,
> >>>>>>>> Commenting only on slices vs. FUs.
> >>>>>>>> The preference for slices over FUs, historically, was pushed by
> >>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
> >>>>>>>> moved over to this draft for the same reason.  Loose a slice,
> >>>>>>>> and you can recover at the next slice boundary; loose an FU,
> >>>>>>>> and you have to wait for the next slice header and throw away
> >>>>>>>> all trailing FUs.  RTP is in virtually all cases run over UDP,
> >>>>>>>> and in the typical Internet scenario UDP is lossy (in contrast
> >>>>>>>> to private, managed IP-network, which may have other
> >>>>>>>> constraints, but are not the IETF's main
> >>>>>>>> concern.) To set your remarks into context, let's first
> >>>>>>>> understand what we are talking
> >>>>>>>> about: the cost of slices is the overhead stemming from the
> >>>>>>>> insertion of slice headers (in-picture syntax prediction) and
> >>>>>>>> from the packet headers themselves.  And, of course,
> >>>>>>>> implementation complexity, but we should not be in the business
> >>>>>>>> to encourage implementor
> >>>>>> laziness when
> >>>>>>>> there would be a more complex, but better suited tool available.
> The
> >>>>>>>> additional packetization overhead is only incurred when, as a
> >>>>>>>> result of incompetently filled packets (which, I agree, is more
> >>>>>>>> likely with
> >>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
> >>>>>>>> needs to be inserted.  You may remember a quick analysis of
> >>>>>>>> mine we discussed way back early in JCT, where we (I think)
> >>>>>>>> agreed that the practical impact is negligible in almost all
> >>>>>>>> non-tile scenarios (mostly because an additional overhead of 50
> >>>>>>>> bytes or so--3% or less of the coded picture size) is incurred
> >>>>>>>> statistically only rarely (only in those cases where an
> >>>>>>>> additional packet would need to be generated because of the
> >>>>>>>> video coding related overhead for the use of slices).  The
> >>>>>>>> prediction overhead of the use of regular slices has been shown
> >>>>>>>> to be substantial--the price one needs to pay for independent
> >>>>>>>> decodability--but for entropy slices that overhead virtually
> >>>>>> does not exist.
> >>>>>>>> With respect to tiles, I think you have a point though,
> >>>>>>>> especially when considering the type of massive parallel
> >>>>>>>> implementations for relatively small picture sizes some folks
> >>>>>>>> have been
> >>>> considering.
> >>>>>>>> OTOH, because FUs are trivial to implement--some say in
> >>>>>>>> contrast to slices--and because (I hope) we all agree that
> >>>>>>>> using FUs in error prone scenarios is a bad idea if you could
> >>>>>>>> use slices (but for reasons like the tile connection you
> >>>>>>>> mentioned), the draft should IMO continue to set a preference
> >>>>>>>> for the use of regular slices over FUs.  To avoid
> >>>>>>>> underperforming systems due to implementer
> >>>>> laziness.
> >>>>>>>> However, this is the IETF.  We don't have to worry about the
> >>>>>>>> word-count of explanatory language.  In fact, explaining such
> >>>>>>>> complex tradeoffs and relationships is generally encouraged here=
.
> >>>>>>>> So let's
> >>>>>> just do that:
> >>>>>>>> express a preference of the use of regular slices (SHOULD) when
> >>>>>>>> you expect losses and can use them (real-time encoding, no
> >>>>>>>> tiling structure that would lead to unacceptable packetization
> >>>>>>>> overhead); and suggest (MAY) the use of FUs in other scenarios.
> >>>>>>>> Accompanied by a more coherently expressed analysis.
> >>>>>>>> Stephan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 7.3.2013 06:46 , "Rickard
> >>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
> >>>>>> wrote:
> >>>>>>>>> Hi Ye-Kui,
> >>>>>>>>>
> >>>>>>>>> Thanks for your feedback on my comments, your suggestions look
> >>>>>>>>> good to
> >>>>>>> me.
> >>>>>>>>> Regarding discouraging fragmentation units (FUs) for
> >>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs does
> >>>>>>>>> make sense when you do not have many non-VLC NAL units for
> >>>>>>>>> aggregation. The spatial granularity of slices was 16x16
> >>>>>>>>> pixels in H.264 but is typically
> >>>>>>>>> 64x64 for HEVC which means that MTU size matching is done with
> >>>>>>>>> units that are 16x larger. This may lead to a larger number of
> >>>>>>>>> smaller packets when slices are used compared to FUs. In
> >>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
> >>>>>>>>> that makes the slice granularity equal to the tile granularity
> >>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
> >>>>>>>>> easier to implement since you do not need to care about when
> >>>>>>>>> to break your slice to not exceed the MTU size limit. I think
> >>>>>>>>> both slices and FUs has their merits and the choice between
> >>>>>>>>> them for live-encoding should be left for
> >>>>>> the implementer.
> >>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and
> >>>>>>>>> 8.2 and the POC MSB sync issue, I agree that this is a corner
> >>>>>>>>> case that we probably will not see much of in practice. I have
> >>>>>>>>> no text change suggestion at the moment.
> >>>>>>>>>
> >>>>>>>>> BR
> >>>>>>>>> Rickard
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> >>>>>>>>> Sent: den 24 juni 2013 01:00
> >>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
> >>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>>>>>>> format
> >>>>>>>>>
> >>>>>>>>> Hi Rickard,
> >>>>>>>>>
> >>>>>>>>> Thanks for the careful review and the comments. Please see
> >>>>>>>>> inline
> >>>> below.
> >>>>>>>>> BR, YK
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com]
> >>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
> >>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
> >>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
> >>>>>>>>>> format
> >>>>>>>>>>
> >>>>>>>>>> Dear all,
> >>>>>>>>>>
> >>>>>>>>>> I have taken a first look at
> >>>>>>>>>> draft-schierl-payload-rtp-h265-03 and have some
> questions/comments.
> >>>>>>>>>>
> >>>>>>>>>> My first question is what extensions of HEVC that
> >>>>>>>>>> draft-schierl-payload-rtp-
> >>>>>>>>>> h265 is intended to cover? The draft mentions "future
> >>>>>>>>>> scalable or 3D  video coding  extensions  of  this
> >>>>>>>>>> specification", what extensions do you refer to?
> >>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
> >>>>>>>>>> payload specification?
> >>>>>>>>>>
> >>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), where
> >>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
> >>>>>>>>> sort of copy-and-paste error. Thanks for the good catching.
> >>>>>>>>> No, there is no intention to cover HEVC extensions in this
> >>>>>>>>> payload specification, though we intentionally to have the
> >>>>>>>>> depacketization process and the use with feedback messages to
> >>>>>>>>> work for HEVC scalability
> >>>>>> and 3DV extensions.
> >>>>>>>>>> Another question for my understanding is why "Receivers MUST
> >>>>>>>>>> pass picture timing SEI messages and decoding unit
> >>>>>>>>>> information SEI messages to the decoder"?
> >>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
> >>>>>>>>> specified by the video coding spec to the video decoders. This
> >>>>>>>>> is emphasized here for the two timing related SEI messages
> >>>>>>>>> after it is said that picture output timing in RTP timestamps
> >>>>>>>>> should be used instead (to avoid giving a wrong impression to
> >>>>>>>>> readers that the SEI messages should be ignored). If an RTP
> >>>>>>>>> receiver discards the SEI messages, then HRD conformance
> >>>>>>>>> checking for the bitstream that was possible would be
> >>>>>>>>> disabled, and also the information related to frame
> >>>>>>> doubling or tripping would be lost.
> >>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rules.
> >>>>>>>>>> The fourth one does not seem to be a rule since there is no
> >>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
> >>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An alternative
> >>>>>>>>> to put this as a packetization rule is to put it as part of
> >>>>>>>>> the semantics of NAL unit header (1.1.4), but that sub-section
> >>>>>>>>> belongs to an overview wherein normative language (even "MAY")
> >>>>>>>>> should not appear. One solution to this is to insert "Payload
> >>>>>>>>> Header
> >>>>> Usage"
> >>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item the=
re.
> >>>>>>>>> I will do this in the next version unless there is a better sug=
gestion.
> >>>>>>>>>
> >>>>>>>>>> Further, the fifth one discourages using FUs, what are the
> >>>>>>>>>> reasons behind that?
> >>>>>>>>> [YK] The bullet item only discourages using FUs for
> >>>>>>>>> live-encoding scenarios, wherein dependent slice segments
> >>>>>>>>> should be
> >>>> used instead.
> >>>>>>>>> This was added after a discussion (among the authors) on the
> >>>>>>>>> need of whether to specify a payload structure for mixed FU
> >>>>>>>>> and aggregation packets and from that discussion we concluded
> >>>>>>>>> that encoding dependent slice segments at source coding level
> >>>>>>>>> already allows for the use cases and using of FUs for
> >>>>>>>>> live-encoding does not make sense. Please let us know if you
> >>>>>>>>> think differently.
> >>>>>>>>>
> >>>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntVal=
.
> >>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> >>>>>>>>>> differ between the encoder and decoder?
> >>>>>>>>> [YK] Good question. In theory this is indeed possible when
> >>>>>>>>> random accessing to a bitstream is performed. However, it
> >>>>>>>>> would not happen in conversational applications where the
> >>>>>>>>> feedback messages may
> >>>>> be used.
> >>>>>>>>> Therefore, to me this would just work just fine. But please
> >>>>>>>>> feel free to make other suggestions.
> >>>>>>>>>
> >>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
> >>>>>>>>>> be useful, let me come back to that later on.
> >>>>>>>>>>
> >>>>>>>>> [YK] OK. Look forward to seeing your input herein.
> >>>>>>>>>
> >>>>>>>>>> I have also a number of spelling suggestions for your
> considerations:
> >>>>>>>>>>
> >>>>>>>>>> Section 1.1:
> >>>>>>>>>> Replace "community" by "communities"
> >>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per
> >>>>>>>>> your suggestion (for the next version).
> >>>>>>>>>
> >>>>>>>>>> Section 1.1.1:
> >>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
> >>>>>>>>>> the interpolation filter"
> >>>>>>>>> [YK] Thanks - done.
> >>>>>>>>>
> >>>>>>>>>> Replace "skipping the transform coding" by "skipping the
> transform"
> >>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
> >>>>>>>>>> coding)
> >>>>>>>>>>
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 1.1.2:
> >>>>>>>>>> Replace:
> >>>>>>>>>> "2) An indication of whether there is any parameter set
> >>>>>>>>>> within the current coded video sequence that updates another
> >>>>>>>>>> parameter set of the same type preceding in decoding order."
> >>>>>>>>>> by:
> >>>>>>>>>> "2) An indication of whether there is no parameter set update
> >>>>>>>>>> in the coded video sequence."
> >>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC
> indicates.
> >>>>>>>>>>
> >>>>>>>>> [YK] Changed the wording to "An indication of whether there is
> >>>>>>>>> no parameter set within the current coded video sequence that
> >>>>>>>>> updates another parameter set of the same type preceding in
> >>>>>>>>> decoding
> >>>>> order."
> >>>>>>>>>> Section 4.7:
> >>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type"
> >>>>>>>>>> and "FU
> >>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the payload
> header.
> >>>>>>>>>>
> >>>>>>>>> [YK] Good point again. I will change the field name to be "FuTy=
pe".
> >>>>>>>>>
> >>>>>>>>>> Section 6:
> >>>>>>>>>> Replace "recovery" by "recover"
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 7.1:
> >>>>>>>>>> Replace "level-id" by "level-idc"
> >>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
> >>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of "id=
c".
> >>>>>>>>>
> >>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> >>>>>>>>> [YK] Done.
> >>>>>>>>>
> >>>>>>>>>> Section 8:
> >>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
> >>>>>>>>>> payload-specific feedback  message", since only SPLI is
> >>>>>>>>>> "Assigned in this memo".
> >>>>>>>>>> Also, consider removing references to H.264 in the last
> >>>>>>>>>> paragraph of Section
> >>>>>>>>>> 8 since the memo is about HEVC.
> >>>>>>>>> [YK] Good catch again. Changed.
> >>>>>>>>>
> >>>>>>>>>> Section 8.1:
> >>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained in
> >>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
> >>>>>>>>>> contained in the FCI field"
> >>>>>>>>> [YK] Another good catch. Changed.
> >>>>>>>>>
> >>>>>>>>>> Best Regards,
> >>>>>>>>>> Rickard Sj=F6berg
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: payload-bounces@ietf.org
> >>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> >>>>>>>>>> Sent: den 11 juni 2013 19:00
> >>>>>>>>>> To: payload@ietf.org
> >>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
> >>>>>>>>>> payload format
> >>>>>>>>>>
> >>>>>>>>>> Dear All,
> >>>>>>>>>>
> >>>>>>>>>> We have just submitted versions 02 and 03 of
> >>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as fol=
lows:
> >>>>>>>>>>
> >>>>>>>>>> Version 02:
> >>>>>>>>>> URL:
> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp
> >>>>>>>>>> -
> >>>>>>>>>> h265-02.txt
> >>>>>>>>>> Htmlized:
> >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
> >>>>>>>>>> Diff:
> >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h=
2
> >>>>>>>>>> 6
> >>>>>>>>>> 5-
> >>>>>>>>>> 02
> >>>>>>>>>>
> >>>>>>>>>> Version 03:
> >>>>>>>>>> URL:
> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp
> >>>>>>>>>> -
> >>>>>>>>>> h265-03.txt
> >>>>>>>>>> Htmlized:
> >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
> >>>>>>>>>> Diff:
> >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h=
2
> >>>>>>>>>> 6
> >>>>>>>>>> 5-
> >>>>>>>>>> 03
> >>>>>>>>>>
> >>>>>>>>>> Version 02 includes huge changes compared to the earlier
> >>>>>>>>>> submitted version 01. In a short summary, the authors have
> >>>>>>>>>> worked hard to try to make the design complete, from both the
> >>>>>>>>>> payload structure and the signaling points of view. Compared
> >>>>>>>>>> to version 02, version
> >>>>>>>>>> 03 only contains a correction of the email address of an autho=
r.
> >>>>>>>>>>
> >>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
> >>>>>>>>>> other standards bodies such as 3GPP rely on the payload
> >>>>>>>>>> format for support of H.265/HEVC in RTP based video services,
> >>>>>>>>>> we need to progress this draft relatively quickly.
> >>>>>>>>>> Therefore, we would like to request quick reviews from
> >>>>>>>>>> interested parties and also request for the WG status of this =
draft.
> >>>>>>>>>>
> >>>>>>>>>> BR, YK (on behalf of the authors)
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> payload mailing list
> >>>>>>>>>> payload@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> payload mailing list
> >>>>>>>>> payload@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>>> _______________________________________________
> >>>>>>>> payload mailing list
> >>>>>>>> payload@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>>> _______________________________________________
> >>>>>>> payload mailing list
> >>>>>>> payload@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>> _______________________________________________
> >>>>>> payload mailing list
> >>>>>> payload@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/payload
> >>>>>> _______________________________________________
> >>>>>> 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 yekuiw@qti.qualcomm.com  Sun Jul  7 23:35:23 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4516621F9A57 for <payload@ietfa.amsl.com>; Sun,  7 Jul 2013 23:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.656
X-Spam-Level: 
X-Spam-Status: No, score=-103.656 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y4RO6UkcgWJ for <payload@ietfa.amsl.com>; Sun,  7 Jul 2013 23:35:18 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 095E711E819A for <payload@ietf.org>; Sun,  7 Jul 2013 23:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373265314; x=1404801314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WK2zqbAj8SXLxV9KYI1U8sTV4vCeJiThcBLcennIf+c=; b=XjlPpetrY0wWKvuqtkp/kkWu8VFWwgA8RiIRyEunH5wt5bO8PRH6TGgr QOJzT3G1s4ZrUw5EgdD+4wfl813IHNvhtVmCjDNKgLM6NjdAXQaf0jf62 IEAjuoVhScOLD4RmdQRv56JElFKyRYBHj7oDM5O0kF0F/62leQ5LKArGF U=;
X-IronPort-AV: E=Sophos;i="4.87,1016,1363158000"; d="scan'208";a="46930693"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 07 Jul 2013 23:35:14 -0700
X-IronPort-AV: E=Sophos;i="4.87,1016,1363158000"; d="scan'208";a="510875503"
Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Jul 2013 23:35:13 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.13]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.004; Sun, 7 Jul 2013 23:35:13 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>, "Thomas Davies (thdavies)" <thdavies@cisco.com>
Thread-Topic: [payload] Submission of new versions of	H.265/HEVC	payload format
Thread-Index: AQHOeHINrpiwi8/7UEygLhM2FJhH9ZlUBM9AgACmR4D///S3IIAAiiGA//+fwlCAAYB+AIAAT+EAgAAFJYCAAA6/gP//jHiwAIzCT4AACZfH0A==
Date: Mon, 8 Jul 2013 06:35:12 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833845DDEA@nasanexd02f.na.qualcomm.com>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com> <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de> <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A833845BCCC@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D48FB59@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48FB59@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload	format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 06:35:23 -0000

Hi Mo,

Implementing dependent slices in either encoder side or decoder side IMO is=
 trivial.

In all those standards organizations that I have ever worked, including her=
e, the experience that I have learned is that any new tool, particularly a =
normative standard feature, needs to provide good improvements against meth=
ods using existing tools, to be justified to be added to a specification, a=
s adding new tools always incur additional costs in specifying, implementat=
ion, testing, and so on.

Arguments like "This is about the RTP payload, thus we can ignore some codi=
ng tools specified in the coding specification" are not convincing to me. I=
n video coding development, people would often need to discuss tools that a=
re available in systems, including in RTP environments, when trying to judg=
ing whether a coding tool proposal makes sense. In different standards bodi=
es, features addressing some issues because of non-desirable implementation=
s are often seen and are more often seen not agreed.

BR, YK

> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: Sunday, July 07, 2013 8:49 PM
> To: Wang, Ye-Kui; Thomas Schierl; Thomas Davies (thdavies)
> Cc: Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas (paubrigh);
> payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi YK,
>=20
> This is not about decoder conformance. Almost all decoders fully conform =
to
> the standards they support (for their advertised profiles/levels). This i=
s about
> encoder feature set and APIs for tool selection. Even today, after a deca=
de of
> H.264, most popular hardware chipsets don't support encoder MTU slicing a=
t
> all, or with degraded performance, or with constraints on other features =
(e.g.
> CABAC). Preliminary information on H.265 plans seems to mirror this.
>=20
> While I certainly agree we should influence encoders to support dependent
> slices, I think we should also give RTP applications the best tools to wo=
rk with
> any encoder (or at least the most popular encoders). Remember, this is th=
e
> spec for RTP applications, not the spec for encoder designers.
>=20
> Cheers,
> Mo
>=20
> -----Original Message-----
> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> Sent: Friday, July 05, 2013 11:57 AM
> To: Mo Zanaty (mzanaty); Thomas Schierl; Thomas Davies (thdavies)
> Cc: Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas (paubrigh);
> payload@ietf.org
> Subject: RE: [payload] Submission of new versions of H.265/HEVC payload
> format
>=20
> Hi Mo,
>=20
> FUs IMO are mainly used for fragmenting big slices for stored /pre-encode=
d
> contents. Though I agreed not to discourage the use of FUs for live-encod=
ing
> scenarios, I agreed on the basis that MTU size matching can be used for o=
ther
> purposes than error resilience. For error resilience purposes in live-enc=
oding
> scenarios, I still don't think using FUs is a good choice, as Stephan als=
o
> mentioned and others basically agreed too. Note also that actually FUs ca=
me
> earlier (as they were included in H.264 payload and this draft inherited =
a lot of
> stuff from the H.264 payload spec) than dependent slices (only in H.265).
>=20
> From the discussions so far, for the error resilience optimization you gu=
ys are
> trying to achieve, my understanding is that using dependent slices can ac=
hieve
> at least the same performance, and conforming H.265 decoders are required=
 to
> support dependent slices anyway.
>=20
> BR, YK
>=20
> > -----Original Message-----
> > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > Sent: Friday, July 05, 2013 8:32 AM
> > To: Thomas Schierl; Thomas Davies (thdavies)
> > Cc: Wang, Ye-Kui; Rickard Sj=F6berg; Stephan Wenger; Paul Bright-Thomas
> > (paubrigh); payload@ietf.org
> > Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Hi Thomas,
> >
> > Please see my reply to YK about why some RTP apps may prefer (or be
> > forced to use) fragmentation rather than dependent slice segments. The
> > current draft supports resilience using tiles with dependent slice
> > segments. The proposed enhancement supports resilience using tiles with
> fragmentation.
> >
> > I understand that dependent slice segments were specifically added to
> > allow a form of codec level fragmentation at finer granularity than
> > slices. However, they are not always sufficient, desirable or even
> > available in all cases of interest for RTP apps. If they were, there
> > would be no need for RTP level fragmentation at all. Since the current
> > draft supports RTP level fragmentation, I assume there is consensus
> > among the authors that there is value in it. The proposed enhancement
> > extends that value by also supporting resilience, so RTP apps which use
> fragmentation can also support resilience.
> >
> > Regards,
> > Mo
> >
> > -----Original Message-----
> > From: Thomas Schierl [mailto:thomas.schierl@hhi.fraunhofer.de]
> > Sent: Friday, July 05, 2013 10:39 AM
> > To: Thomas Davies (thdavies)
> > Cc: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> > Wenger; Paul Bright-Thomas (paubrigh); payload@ietf.org
> > Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > payload format
> >
> > Dear Thomas,
> >
> > For the error resilience in the case of slices or dependent slices,
> > which do match with tiles, I do not think an additional pointer
> > information in the FU header does improve the error resilience
> > capabilities over a system without those information.
> >
> > I think I did not exclude the use of FUs even for dependent slice
> > fragments, but I would not require an additional mechanism to those,
> > as stated in my email before.
> >
> > Thomas
> > --
> >
> > Dr.-Ing. Thomas Schierl
> >
> > Head of Multimedia Communications Group Image Processing Department
> > thomas.schierl@hhi.fraunhofer.de
> >
> > Tel.:  +49 30 31002-227
> > Fax:  +49 30 31002-190
> > Skype:  thomas.schierl
> >
> > Fraunhofer HHI - Heinrich Hertz Institute Einsteinufer 37, 10587
> > Berlin, Germany http://www.hhi.fraunhofer.de/ip/mc
> >
> > Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:
> >
> > > Dear Thomas
> > >
> > > On your first point, the decoder always has to be told there is
> > > missing data. I
> > don't see much different or fancy in the interface between the two case=
s.
> > Usually error concealment must be addressed both within the codec
> > (because of reference dependencies) and also in the application
> > (because of display and call-management/error response functionality). =
That's
> surely a very minor issue.
> > >
> > > On the second point, the context we are considering in our proposal
> > > is where
> > FUs are being used, in the circumstances Mo set out, and providing
> > some level of sub-frame resilience where possible in that case. If
> > your assumption is that FUs are not being used, and re-writing is
> > possible/desirable, you will certainly conclude that FUs should not be
> > used. Since we concluded that FUs should not be discouraged, it seems
> > reasonable to consider adding features which make them more resilient w=
hen
> they are.
> > >
> > > best regards
> > >
> > > Thomas
> > >
> > > On 05/07/13 10:34, Thomas Schierl wrote:
> > >> Dear Ye-Kui, all,
> > >>
> > >> Further I would tentatively assume that you can use the slice
> > >> segment
> > address in the dependent slice fragment header for the same degree of
> > error resilience as the new-FU header, if you put a tile into a
> > dependent slice. And this part would be understood by the decoder
> > itself, which should be able to do the error resilience on codec
> > level. Without fancy interfaces into the decoder, etc.
> > >>
> > >> A point in the discussion which seems to be missing is that the
> > >> rewriting of a
> > single slice into multiple dependent slice fragments (including also
> > one independent slice fragment) can be done at very low processing
> > costs, as shown during the standardization of HEVC.
> > >>
> > >> Thomas
> > >> --
> > >> Thomas Schierl
> > >> Fraunhofer HHI
> > >>
> > >> Am 04.07.2013 um 19:59 schrieb "Wang, Ye-
> > Kui"<yekuiw@qti.qualcomm.com>:
> > >>
> > >>> Hi Thomas,
> > >>>
> > >>> Thanks for the clarification - I think now understand your scheme b=
etter.
> > >>>
> > >>> So you did not intent to encapsulate only entire tiles into
> > >>> packets, though
> > that would obviously be more error resilient as you won't encounter
> > the problem where a part of a tile gets lost and the received rest beco=
mes
> useless.
> > Rather, one tile may be carried in two (or even more) packets.
> > >>>
> > >>> I think I was confused by the suggested language such as "If a
> > fragmentation unit is lost, tiles in the lost fragmentation unit are al=
so lost.
> > However, tiles which are successfully received in their entirety can
> > be decoded if their slice segment header containing tile offsets is
> > successfully received, despite lost fragmentation units.", from where
> > I got an impression that an FU includes entire tiles.
> > >>>
> > >>> As seen from other discussions, it is very questionable how big a
> > >>> penalty
> > would be when an encoder tries to splitting encoded data into separate
> > NAL units (slices or dependent slices) for MTU size matching, even for
> > large CTB sizes - that's the reason why the JCT-VC later decided to
> > remove the fine- granularity slice feature.
> > >>>
> > >>> Let's tentatively assume that overall penalty and the overhead of
> > >>> the new-
> > FU approach are roughly equivalent, and take into account latest
> > comments from Mo and Stephan, do we see an advantage of the new-FU
> > approach compared to using dependent slices?
> > >>>
> > >>> I am not trying to conclude yet - just try to (very briefly)
> > >>> summarize the
> > situation so far at least for myself.  We should certainly have more
> > discussions - preferable involving more people who care about this payl=
oad
> format.
> > >>>
> > >>> BR, YK
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> > >>>> Sent: Thursday, July 04, 2013 9:23 AM
> > >>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> > >>>> Wenger; Paul Bright-Thomas (paubrigh)
> > >>>> Cc: payload@ietf.org
> > >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > >>>> payload format
> > >>>>
> > >>>> Hi Ye-Kui
> > >>>>
> > >>>> Thank you for the clarification - I understand your point a bit be=
tter now.
> > >>>>
> > >>>> With the proposed scheme there is no need for the RTP packetizer
> > >>>> to parse slice headers or identify tile boundaries. All it needs
> > >>>> to do is to keep track of the offset of the start of the payload
> > >>>> to the beginning of the NALU and put this into the field. It
> > >>>> needs to know this offset anyway. The packetizer is completely dum=
b.
> > >>>>
> > >>>> The point is that a decoder wishing to do error resilience can
> > >>>> parse the slice header and identify the tile boundaries in the
> > >>>> case that a packet goes missing, for tiles that occur in the same
> > >>>> frame but after the packet that is lost. The decoder can compare
> > >>>> the tile offsets with the FU offsets to work out what data is miss=
ing.
> > >>>>
> > >>>> Re dependent slices, there are indirect overheads as well, which
> > >>>> come from having to quantize the packet size to a whole number of
> > >>>> tiles, plus you have to manage the encoder to match the MTU size.
> > >>>> The granularity of tiles you need for your parallel processing
> > >>>> may not match the granularity you need to fit in the MTU very well=
.
> > >>>>
> > >>>> Best regards
> > >>>>
> > >>>> Thomas
> > >>>>
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > >>>> Sent: 04 July 2013 16:34
> > >>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard
> > >>>> Sj=F6berg; Stephan Wenger; Paul Bright-Thomas (paubrigh)
> > >>>> Cc: payload@ietf.org
> > >>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > >>>> payload format
> > >>>>
> > >>>> Hi Thomas,
> > >>>>
> > >>>> My point was really about using dependent slices, not about 1 or
> > >>>> N tiles per packets (sorry that I did not make that clearer).
> > >>>> Whatever strategy you would like to do in terms of the number of
> > >>>> tiles in a packet, using dependent slices can do the same, as
> > >>>> each
> > dependent slice can include 1 or N tiles.
> > >>>>
> > >>>> I see the following advantages with the approach using dependent
> > >>>> slices instead of defining new FUs:
> > >>>>
> > >>>> - First of all, no need to define new payload structures.
> > >>>>
> > >>>> - The RTP packetizer does not need to parse slice headers to
> > >>>> identify boundaries of tiles within a coded slice, as tiles of
> > >>>> one SLICE are already in separate NAL units each containing a
> > >>>> DEPENDENT
> > SLICE.
> > >>>>
> > >>>> - No additional overhead in packetization (the 1-byte FU header
> > >>>> and the 2- or 4-byte FU offset). The overhead of the short slice
> > >>>> header for dependent slice NAL units is compensated by less
> > >>>> number of tile entry offsets signalled, as the entry offset of
> > >>>> the first tile in each NAL unit
> > is not signalled in the slice header.
> > >>>> Using dependent slices would need more two-byte NAL unit headers,
> > >>>> while using new FUs would need more two-byte packet payload
> > >>>> headers, and the overhead bits here are the same for both methods.
> > >>>>
> > >>>> Am I missing anything here?
> > >>>>
> > >>>> BR, YK
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
> > >>>>> Sent: Thursday, July 04, 2013 1:49 AM
> > >>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
> > >>>>> Wenger; Paul Bright-Thomas (paubrigh)
> > >>>>> Cc: payload@ietf.org
> > >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > >>>>> payload format
> > >>>>>
> > >>>>> Yes, we did think about one tile per packet or N tiles per
> > >>>>> packet,
> > >>>>> also: I guess that is where we started from. Then you could
> > >>>>> indeed align missing tiles with missing sequence numbers.
> > >>>>>
> > >>>>> The issue is that you need to guarantee that you are doing this
> > >>>>> for it to be useful, and the decoder needs to know that this is
> > >>>>> guaranteed through some form of other signalling. However, the
> > >>>>> bitstream chunk associated to a tile is extremely variable, and
> > >>>>> many tile chunks would be very small. So there is significant
> > >>>>> packetization overhead for them if there
> > >>>> is one tile per packet.
> > >>>>> Having N>1 reduces this overhead, but it is still there and as N
> > >>>>> increases you run the risk of breaking the MTU size which then
> > >>>>> requires that you have to re- encode to fit things in and meet
> > >>>>> the guarantee. There is definitely no time to re-encode whole
> > >>>>> tiles, especially if you are already using them for
> > >>>>> parallelization. Thus you might have to break the guarantee and
> > >>>>> fragment the packet anyhow, losing
> > >>>> the resilience.
> > >>>>> The advantage that we see with the proposal is that you can get
> > >>>>> fairly similar resilience to regular slice MTU-size matching,
> > >>>>> but with much lower overheads as you can have a single regular
> > >>>>> slice header per frame, yet
> > >>>> have a "dumb"
> > >>>>> packetization process and no need to re-encode to hit MTU targets=
.
> > >>>>> In
> > >>>>> H264 MTU matching usually means re-encoding just one or two
> > >>>>> 16x16
> > MBs.
> > >>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if
> > >>>>> you are doing tiles then you can get tiny "dangling slices" at
> > >>>>> the end of a tile, which means more small packets.
> > >>>>>
> > >>>>> Best regards
> > >>>>>
> > >>>>> Thomas
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > >>>>> Sent: 04 July 2013 07:02
> > >>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies
> > >>>>> (thdavies); Stephan Wenger; Paul Bright-Thomas (paubrigh)
> > >>>>> Cc: payload@ietf.org
> > >>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > >>>>> payload format
> > >>>>>
> > >>>>>
> > >>>>> An interesting idea. Using dependent slices (again :-) together
> > >>>>> with tiles would do the trick too (each tile in one dependent
> > >>>>> slice, and then each dependent slice NAL unit in one single NAL
> > >>>>> unit
> > packet).
> > >>>>>
> > >>>>> Have you guys done an analysis comparing the pros and cons of
> > >>>>> the two alternative approaches?
> > >>>>>
> > >>>>> BR, YK
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> > >>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
> > >>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies);
> > >>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
> > >>>>>> Cc: payload@ietf.org
> > >>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
> > >>>>>> payload format
> > >>>>>>
> > >>>>>> Thomas, Paul and I have been working on improving packet loss
> > >>>>>> resilience using fragments and tiles. I mentioned this to
> > >>>>>> Stephan at IETF 86 in Orlando, and promised to have draft text
> > >>>>>> ready before Berlin. Here is the proposed text along with an
> > >>>>>> overview of the
> > rationale.
> > >>>>>>
> > >>>>>> Rationale:
> > >>>>>>
> > >>>>>> 1. Resilience to packet loss requires independent slices or tile=
s.
> > >>>>>> Since independence requires restrictions on some coding tools,
> > >>>>>> both potentially incur slight penalties in coding efficiency,
> > >>>>>> with a smaller penalty
> > >>>>> for tiles.
> > >>>>>> 2. Fragmentation in a higher layer like RTP can have several
> > >>>>>> advantages over similar features in a codec layer like slices
> > >>>>>> (independent or
> > >>>>> dependent).
> > >>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity
> > >>>>>> while slices have much larger (CTB or tile) granularity. It
> > >>>>>> also has less slice segment header overhead, especially for
> > >>>>>> independent
> > slices.
> > >>>>>> This can impact the efficiency of the packetized stream in
> > >>>>>> terms of both bits and
> > >>>>> packets per second.
> > >>>>>> b. Performance: Encoders must perform extra processing to limit
> > >>>>>> slice sizes, which can impact encoder performance. Some
> > >>>>>> implementations speculatively end a slice based on computed
> > >>>>>> statistics (which aggravates a.), while others recode a slice
> > >>>>>> if the size is exceeded (which
> > >>>>> aggravates b.).
> > >>>>>> c. Decoupling: Not all encoders will support limiting slice
> > >>>>>> size to MTU
> > size.
> > >>>>>> Applications (for live or stored content) using such encoders
> > >>>>>> can still support MTU limits using RTP fragmentation since it
> > >>>>>> is decoupled from
> > >>>>> the encoder.
> > >>>>>> d. Multi-party: The encoded content may go to multiple
> > >>>>>> receivers with different MTUs. RTP fragmentation can handle
> > >>>>>> this with lightweight repacketization at middle boxes whereas
> > >>>>>> slices incur
> > >>>> heavyweight transcoding.
> > >>>>>> 3. Combining fragmentation and tiles can improve resilience
> > >>>>>> while retaining the above advantages, if fragments are enhanced
> > >>>>>> to contain offsets (similar to IP fragmentation). This is
> > >>>>>> described in the proposed draft text below, which would
> > >>>>>> immediately follow section
> > >>>>>> 4.7
> > >>>>> Fragmentation Units.
> > >>>>>> Draft Text:
> > >>>>>>
> > >>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
> > >>>>>>
> > >>>>>> If a fragmented NAL unit contains tiles, its slice segment
> > >>>>>> header contains offsets to the data of each tile. These offsets
> > >>>>>> can be used for random access to any tile for parallel
> > >>>>>> processing, region of interest extraction, and resilience to
> > >>>>>> errors in other tiles. These offsets can also be used to
> > >>>>>> provide resilience to packet loss, in conjunction with fragment
> > >>>>>> offsets contained in two types of fragmentation
> > >>>>> units: FU-A2 and FU-A4.
> > >>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset
> > >>>>>> before the FU payload. FU-A2 contains a 2-byte offset as shown
> > >>>>>> in
> > Figure X.
> > >>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
> > >>>>>> indicates the total number of bytes in all prior FU payloads of
> > >>>>>> the fragmented
> > >>>>> NAL unit.
> > >>>>>>
> > >>>>>>    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
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 offs=
et  |
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   | FU-A2 offset  |     DONL (optional)           |             =
  |
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             =
  |
> > >>>>>>   |                                                             =
  |
> > >>>>>>   |                         FU payload                          =
  |
> > >>>>>>   |                                                             =
  |
> > >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   |                               :...OPTIONAL RTP padding      =
  |
> > >>>>>>
> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> > >>>>>>
> > >>>>>>                  Figure X   RTP payload format for FU-A2
> > >>>>>>
> > >>>>>>
> > >>>>>>    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
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 offs=
et  |
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   |      FU-A4 offset                             | DONL(optiona=
l)|
> > >>>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   | DONL(optional)|                                             =
  |
> > >>>>>>   +-+-+-+-+-+-+-+-+         FU payload                          =
  |
> > >>>>>>   |                                                             =
  |
> > >>>>>>   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+
> > >>>>>>   |                               :...OPTIONAL RTP padding      =
  |
> > >>>>>>
> > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
> > >>>>>>
> > >>>>>>                  Figure Y   RTP payload format for FU-A4
> > >>>>>>
> > >>>>>>
> > >>>>>> Since the offset of the first FU payload of a fragmented NAL
> > >>>>>> unit is zero, and the Start (S) bit in the FU header is
> > >>>>>> sufficient to indicate this, the first fragmentation unit of a
> > >>>>>> fragmented NAL unit SHOULD use FU-A, but MAY use
> > >>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
> > >>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
> > >>>>>> non-zero offset. The Start
> > >>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
> > >>>>>> contains a non- zero offset, and MUST be set if it contains a ze=
ro
> offset.
> > >>>>>>
> > >>>>>> If a fragmentation unit is lost, tiles in the lost
> > >>>>>> fragmentation unit are also
> > >>>> lost.
> > >>>>>> However, tiles which are successfully received in their
> > >>>>>> entirety can be decoded if their slice segment header
> > >>>>>> containing tile offsets is successfully received, despite lost
> > >>>>>> fragmentation units. Fragment offsets in FU-A2 or FU-A4 are
> > >>>>>> required in order to recover from loss of prior fragmentation
> > >>>>>> units and continue decoding
> > subsequent tiles.
> > >>>>>>
> > >>>>>> The following heuristic SHOULD be applied to determine if the
> > >>>>>> lost fragmentation units are all part of the same fragmented
> > >>>>>> NAL unit as subsequently received fragmentation units with
> > >>>>>> identical RTP timestamps and identical values of NAL unit
> > >>>>>> header layer ID and temporal
> > >>>> ID.
> > >>>>>> 1. Let N be the number of missing sequence numbers between two
> > >>>>>> received fragmentation units with known offsets.
> > >>>>>> 2. Let P be the FU payload size of the first of the two received=
 FUs.
> > >>>>>> 3. Let D be the difference in the offsets, minus P.
> > >>>>>>   (This is the number of missing FU payload bytes.) 4. Let E be =
N times
> P.
> > >>>>>>   (This is the estimated number of missing FU payload bytes.) 5.
> > >>>>>> Let ERROR be the absolute difference between D and E, divided by=
 D.
> > >>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
> > >>>>>> fragmented NAL unit, otherwise it is unlikely.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Mo
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: payload-bounces@ietf.org
> > >>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Rickard Sj=F6berg
> > >>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
> > >>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
> > >>>>>> Cc: payload@ietf.org
> > >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > >>>>>> payload format
> > >>>>>>
> > >>>>>> Dear all,
> > >>>>>>
> > >>>>>> I wrote slices and not dependent slices since the slice
> > >>>>>> granularity and slice/tile rule applies to both slices and depen=
dent
> slices.
> > >>>>>> Sorry for the confusion. I will now use 'independent slices'
> > >>>>>> and 'dependent slices' to distinguish between them.
> > >>>>>>
> > >>>>>> I do not question the use of independent slices, I find them
> > >>>>>> useful in some applications.
> > >>>>>>
> > >>>>>> But the current RTP payload text says:
> > >>>>>>
> > >>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >>>>>>      video telephony, video conferencing, live streaming and liv=
e
> > >>>>>>      broadcast, in which cases dependent slice segments SHOULD b=
e
> used
> > >>>>>>      when a slice should be transported in multiple RTP packets.=
"
> > >>>>>>
> > >>>>>> I believe that FUs are a viable option to dependent slices for
> > >>>>>> the reasons I listed in my previous e-mail and think that we
> > >>>>>> should not recommend dependent slices over FUs but leave it to
> > >>>>>> the
> > implementer.
> > >>>>>>
> > >>>>>> BR
> > >>>>>> Rickard
> > >>>>>>
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: payload-bounces@ietf.org
> > >>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> > >>>>>> Sent: den 3 juli 2013 20:43
> > >>>>>> To: Thomas Davies; Stephan Wenger
> > >>>>>> Cc: payload@ietf.org
> > >>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
> > >>>>>> payload format
> > >>>>>>
> > >>>>>> Hi All,
> > >>>>>>
> > >>>>>> I drafted an email replying directly to Rickard but did not
> > >>>>>> finish and there was a meeting (and then Stephan's and Thomas'
> > >>>>>> emails
> > came).
> > >>>>>>
> > >>>>>> I wanted to comment that Rickard was comparing the use of FUs
> > >>>>>> vs slices, not FUs vs dependent slices, while the
> > >>>>>> recommendation in the draft is recommending use of dependent
> > >>>>>> slices over FUs in live-encoding scenarios (so this answers
> > >>>>>> Thomas question: the intention was
> > >>>>> dependent slices ).
> > >>>>>> In any case, it does not make much sense to try MTU size
> > >>>>>> matching and at the same time use either dependent slices or
> > >>>>>> FUs, because dependent slices and FUs should not be used when
> > >>>>>> there are considerable packet losses, while MTU size matching
> > >>>>>> should be applied when there are
> > >>>>> considerable packet losses.
> > >>>>>> For live encoding, whenever splitting of a regular slice is
> > >>>>>> needed, the splitting can be done by the encoder using
> > >>>>>> dependent slices - and the encoder has more knowledge and is
> > >>>>>> more powerful than the RTP packetizer and thus can do a better j=
ob
> for the splitting.
> > >>>>>>
> > >>>>>> BR, YK
> > >>>>>>
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: payload-bounces@ietf.org
> > >>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Thomas Davies
> > >>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
> > >>>>>>> To: Stephan Wenger
> > >>>>>>> Cc: payload@ietf.org
> > >>>>>>> Subject: Re: [payload] Submission of new versions of
> > >>>>>>> H.265/HEVC payload format
> > >>>>>>>
> > >>>>>>> Hi Stephan
> > >>>>>>>
> > >>>>>>> I think I agree with Rickard.
> > >>>>>>>
> > >>>>>>> I think the text in question states a preference for
> > >>>>>>> _dependent_ slice segments, which have no error resiliency
> advantage over FUs.
> > >>>>>>> Is this just a
> > >>>>>> typo?
> > >>>>>>> <snip>
> > >>>>>>>
> > >>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
> > >>>>>>>       video telephony, video conferencing, live streaming and l=
ive
> > >>>>>>>       broadcast, in which cases dependent slice segments
> > >>>>>>> SHOULD be
> > used
> > >>>>>>>       when a slice should be transported in multiple RTP packet=
s.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> </snip>
> > >>>>>>>
> > >>>>>>> In general FUs may be used where error conditions are known to
> > >>>>>>> be benign, for greater efficiency, and also where for whatever
> > >>>>>>> reason the encoder cannot support MTU matching.
> > >>>>>>>
> > >>>>>>> We also are formulating some more general comments on this
> > >>>>>>> area which we hope to provide more fully soon.
> > >>>>>>>
> > >>>>>>> best regards
> > >>>>>>>
> > >>>>>>> Thomas
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
> > >>>>>>>> Hi Rickard,
> > >>>>>>>> Commenting only on slices vs. FUs.
> > >>>>>>>> The preference for slices over FUs, historically, was pushed
> > >>>>>>>> by myself into RFC 3984 for reasons of error resilience, and
> > >>>>>>>> was moved over to this draft for the same reason.  Loose a
> > >>>>>>>> slice, and you can recover at the next slice boundary; loose
> > >>>>>>>> an FU, and you have to wait for the next slice header and
> > >>>>>>>> throw away all trailing FUs.  RTP is in virtually all cases
> > >>>>>>>> run over UDP, and in the typical Internet scenario UDP is
> > >>>>>>>> lossy (in contrast to private, managed IP-network, which may
> > >>>>>>>> have other constraints, but are not the IETF's main
> > >>>>>>>> concern.) To set your remarks into context, let's first
> > >>>>>>>> understand what we are talking
> > >>>>>>>> about: the cost of slices is the overhead stemming from the
> > >>>>>>>> insertion of slice headers (in-picture syntax prediction) and
> > >>>>>>>> from the packet headers themselves.  And, of course,
> > >>>>>>>> implementation complexity, but we should not be in the
> > >>>>>>>> business to encourage implementor
> > >>>>>> laziness when
> > >>>>>>>> there would be a more complex, but better suited tool availabl=
e.
> > The
> > >>>>>>>> additional packetization overhead is only incurred when, as a
> > >>>>>>>> result of incompetently filled packets (which, I agree, is
> > >>>>>>>> more likely with
> > >>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
> > >>>>>>>> needs to be inserted.  You may remember a quick analysis of
> > >>>>>>>> mine we discussed way back early in JCT, where we (I think)
> > >>>>>>>> agreed that the practical impact is negligible in almost all
> > >>>>>>>> non-tile scenarios (mostly because an additional overhead of
> > >>>>>>>> 50 bytes or so--3% or less of the coded picture size) is
> > >>>>>>>> incurred statistically only rarely (only in those cases where
> > >>>>>>>> an additional packet would need to be generated because of
> > >>>>>>>> the video coding related overhead for the use of slices).
> > >>>>>>>> The prediction overhead of the use of regular slices has been
> > >>>>>>>> shown to be substantial--the price one needs to pay for
> > >>>>>>>> independent decodability--but for entropy slices that
> > >>>>>>>> overhead virtually
> > >>>>>> does not exist.
> > >>>>>>>> With respect to tiles, I think you have a point though,
> > >>>>>>>> especially when considering the type of massive parallel
> > >>>>>>>> implementations for relatively small picture sizes some folks
> > >>>>>>>> have been
> > >>>> considering.
> > >>>>>>>> OTOH, because FUs are trivial to implement--some say in
> > >>>>>>>> contrast to slices--and because (I hope) we all agree that
> > >>>>>>>> using FUs in error prone scenarios is a bad idea if you could
> > >>>>>>>> use slices (but for reasons like the tile connection you
> > >>>>>>>> mentioned), the draft should IMO continue to set a preference
> > >>>>>>>> for the use of regular slices over FUs.  To avoid
> > >>>>>>>> underperforming systems due to implementer
> > >>>>> laziness.
> > >>>>>>>> However, this is the IETF.  We don't have to worry about the
> > >>>>>>>> word-count of explanatory language.  In fact, explaining such
> > >>>>>>>> complex tradeoffs and relationships is generally encouraged he=
re.
> > >>>>>>>> So let's
> > >>>>>> just do that:
> > >>>>>>>> express a preference of the use of regular slices (SHOULD)
> > >>>>>>>> when you expect losses and can use them (real-time encoding,
> > >>>>>>>> no tiling structure that would lead to unacceptable
> > >>>>>>>> packetization overhead); and suggest (MAY) the use of FUs in o=
ther
> scenarios.
> > >>>>>>>> Accompanied by a more coherently expressed analysis.
> > >>>>>>>> Stephan
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 7.3.2013 06:46 , "Rickard
> > >>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
> > >>>>>> wrote:
> > >>>>>>>>> Hi Ye-Kui,
> > >>>>>>>>>
> > >>>>>>>>> Thanks for your feedback on my comments, your suggestions
> > >>>>>>>>> look good to
> > >>>>>>> me.
> > >>>>>>>>> Regarding discouraging fragmentation units (FUs) for
> > >>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs
> > >>>>>>>>> does make sense when you do not have many non-VLC NAL units
> > >>>>>>>>> for aggregation. The spatial granularity of slices was 16x16
> > >>>>>>>>> pixels in H.264 but is typically
> > >>>>>>>>> 64x64 for HEVC which means that MTU size matching is done
> > >>>>>>>>> with units that are 16x larger. This may lead to a larger
> > >>>>>>>>> number of smaller packets when slices are used compared to
> > >>>>>>>>> FUs. In addition, there is the HEVC rule of slice and tile
> > >>>>>>>>> boundaries that makes the slice granularity equal to the
> > >>>>>>>>> tile granularity for cases when slices span multiple tiles.
> > >>>>>>>>> Finally, FUs are easier to implement since you do not need
> > >>>>>>>>> to care about when to break your slice to not exceed the MTU
> > >>>>>>>>> size limit. I think both slices and FUs has their merits and
> > >>>>>>>>> the choice between them for live-encoding should be left for
> > >>>>>> the implementer.
> > >>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and
> > >>>>>>>>> 8.2 and the POC MSB sync issue, I agree that this is a
> > >>>>>>>>> corner case that we probably will not see much of in
> > >>>>>>>>> practice. I have no text change suggestion at the moment.
> > >>>>>>>>>
> > >>>>>>>>> BR
> > >>>>>>>>> Rickard
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
> > >>>>>>>>> Sent: den 24 juni 2013 01:00
> > >>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
> > >>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC
> > >>>>>>>>> payload format
> > >>>>>>>>>
> > >>>>>>>>> Hi Rickard,
> > >>>>>>>>>
> > >>>>>>>>> Thanks for the careful review and the comments. Please see
> > >>>>>>>>> inline
> > >>>> below.
> > >>>>>>>>> BR, YK
> > >>>>>>>>>
> > >>>>>>>>>> -----Original Message-----
> > >>>>>>>>>> From: Rickard Sj=F6berg [mailto:rickard.sjoberg@ericsson.com=
]
> > >>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
> > >>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
> > >>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC
> > >>>>>>>>>> payload format
> > >>>>>>>>>>
> > >>>>>>>>>> Dear all,
> > >>>>>>>>>>
> > >>>>>>>>>> I have taken a first look at
> > >>>>>>>>>> draft-schierl-payload-rtp-h265-03 and have some
> > questions/comments.
> > >>>>>>>>>>
> > >>>>>>>>>> My first question is what extensions of HEVC that
> > >>>>>>>>>> draft-schierl-payload-rtp-
> > >>>>>>>>>> h265 is intended to cover? The draft mentions "future
> > >>>>>>>>>> scalable or 3D  video coding  extensions  of  this
> > >>>>>>>>>> specification", what extensions do you refer to?
> > >>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
> > >>>>>>>>>> payload specification?
> > >>>>>>>>>>
> > >>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id),
> > >>>>>>>>> where "this specification" should be replaced with "[HEVC]".
> > >>>>>>>>> It is sort of copy-and-paste error. Thanks for the good catch=
ing.
> > >>>>>>>>> No, there is no intention to cover HEVC extensions in this
> > >>>>>>>>> payload specification, though we intentionally to have the
> > >>>>>>>>> depacketization process and the use with feedback messages
> > >>>>>>>>> to work for HEVC scalability
> > >>>>>> and 3DV extensions.
> > >>>>>>>>>> Another question for my understanding is why "Receivers
> > >>>>>>>>>> MUST pass picture timing SEI messages and decoding unit
> > >>>>>>>>>> information SEI messages to the decoder"?
> > >>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
> > >>>>>>>>> specified by the video coding spec to the video decoders.
> > >>>>>>>>> This is emphasized here for the two timing related SEI
> > >>>>>>>>> messages after it is said that picture output timing in RTP
> > >>>>>>>>> timestamps should be used instead (to avoid giving a wrong
> > >>>>>>>>> impression to readers that the SEI messages should be
> > >>>>>>>>> ignored). If an RTP receiver discards the SEI messages, then
> > >>>>>>>>> HRD conformance checking for the bitstream that was possible
> > >>>>>>>>> would be disabled, and also the information related to frame
> > >>>>>>> doubling or tripping would be lost.
> > >>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 rule=
s.
> > >>>>>>>>>> The fourth one does not seem to be a rule since there is no
> > >>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
> > >>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An
> > >>>>>>>>> alternative to put this as a packetization rule is to put it
> > >>>>>>>>> as part of the semantics of NAL unit header (1.1.4), but
> > >>>>>>>>> that sub-section belongs to an overview wherein normative
> > >>>>>>>>> language (even "MAY") should not appear. One solution to
> > >>>>>>>>> this is to insert "Payload Header
> > >>>>> Usage"
> > >>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item t=
here.
> > >>>>>>>>> I will do this in the next version unless there is a better s=
uggestion.
> > >>>>>>>>>
> > >>>>>>>>>> Further, the fifth one discourages using FUs, what are the
> > >>>>>>>>>> reasons behind that?
> > >>>>>>>>> [YK] The bullet item only discourages using FUs for
> > >>>>>>>>> live-encoding scenarios, wherein dependent slice segments
> > >>>>>>>>> should be
> > >>>> used instead.
> > >>>>>>>>> This was added after a discussion (among the authors) on the
> > >>>>>>>>> need of whether to specify a payload structure for mixed FU
> > >>>>>>>>> and aggregation packets and from that discussion we
> > >>>>>>>>> concluded that encoding dependent slice segments at source
> > >>>>>>>>> coding level already allows for the use cases and using of
> > >>>>>>>>> FUs for live-encoding does not make sense. Please let us
> > >>>>>>>>> know if you think differently.
> > >>>>>>>>>
> > >>>>>>>>>> In 8.2 and 8.3, the feedback messages are using PicOrderCntV=
al.
> > >>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
> > >>>>>>>>>> differ between the encoder and decoder?
> > >>>>>>>>> [YK] Good question. In theory this is indeed possible when
> > >>>>>>>>> random accessing to a bitstream is performed. However, it
> > >>>>>>>>> would not happen in conversational applications where the
> > >>>>>>>>> feedback messages may
> > >>>>> be used.
> > >>>>>>>>> Therefore, to me this would just work just fine. But please
> > >>>>>>>>> feel free to make other suggestions.
> > >>>>>>>>>
> > >>>>>>>>>> The use of spatial-segmentation-idc may need some updates
> > >>>>>>>>>> to be useful, let me come back to that later on.
> > >>>>>>>>>>
> > >>>>>>>>> [YK] OK. Look forward to seeing your input herein.
> > >>>>>>>>>
> > >>>>>>>>>> I have also a number of spelling suggestions for your
> > considerations:
> > >>>>>>>>>>
> > >>>>>>>>>> Section 1.1:
> > >>>>>>>>>> Replace "community" by "communities"
> > >>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per
> > >>>>>>>>> your suggestion (for the next version).
> > >>>>>>>>>
> > >>>>>>>>>> Section 1.1.1:
> > >>>>>>>>>> Replace "In addition, interpolation filter" by "In
> > >>>>>>>>>> addition, the interpolation filter"
> > >>>>>>>>> [YK] Thanks - done.
> > >>>>>>>>>
> > >>>>>>>>>> Replace "skipping the transform coding" by "skipping the
> > transform"
> > >>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
> > >>>>>>>>>> coding)
> > >>>>>>>>>>
> > >>>>>>>>> [YK] Done.
> > >>>>>>>>>
> > >>>>>>>>>> Section 1.1.2:
> > >>>>>>>>>> Replace:
> > >>>>>>>>>> "2) An indication of whether there is any parameter set
> > >>>>>>>>>> within the current coded video sequence that updates
> > >>>>>>>>>> another parameter set of the same type preceding in decoding
> order."
> > >>>>>>>>>> by:
> > >>>>>>>>>> "2) An indication of whether there is no parameter set
> > >>>>>>>>>> update in the coded video sequence."
> > >>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC
> > indicates.
> > >>>>>>>>>>
> > >>>>>>>>> [YK] Changed the wording to "An indication of whether there
> > >>>>>>>>> is no parameter set within the current coded video sequence
> > >>>>>>>>> that updates another parameter set of the same type
> > >>>>>>>>> preceding in decoding
> > >>>>> order."
> > >>>>>>>>>> Section 4.7:
> > >>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU Type=
"
> > >>>>>>>>>> and "FU
> > >>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the
> > >>>>>>>>>> payload
> > header.
> > >>>>>>>>>>
> > >>>>>>>>> [YK] Good point again. I will change the field name to be "Fu=
Type".
> > >>>>>>>>>
> > >>>>>>>>>> Section 6:
> > >>>>>>>>>> Replace "recovery" by "recover"
> > >>>>>>>>> [YK] Done.
> > >>>>>>>>>
> > >>>>>>>>>> Section 7.1:
> > >>>>>>>>>> Replace "level-id" by "level-idc"
> > >>>>>>>>> [YK] We are consistently using "id" for profile-id,
> > >>>>>>>>> level-id, max-recv-level-id etc, similarly as in RFC 6184, in=
stead of
> "idc".
> > >>>>>>>>>
> > >>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
> > >>>>>>>>> [YK] Done.
> > >>>>>>>>>
> > >>>>>>>>>> Section 8:
> > >>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
> > >>>>>>>>>> payload-specific feedback  message", since only SPLI is
> > >>>>>>>>>> "Assigned in this memo".
> > >>>>>>>>>> Also, consider removing references to H.264 in the last
> > >>>>>>>>>> paragraph of Section
> > >>>>>>>>>> 8 since the memo is about HEVC.
> > >>>>>>>>> [YK] Good catch again. Changed.
> > >>>>>>>>>
> > >>>>>>>>>> Section 8.1:
> > >>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained
> > >>>>>>>>>> in the FCI field" should be "There MUST be exactly one SPLI
> > >>>>>>>>>> contained in the FCI field"
> > >>>>>>>>> [YK] Another good catch. Changed.
> > >>>>>>>>>
> > >>>>>>>>>> Best Regards,
> > >>>>>>>>>> Rickard Sj=F6berg
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> -----Original Message-----
> > >>>>>>>>>> From: payload-bounces@ietf.org
> > >>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
> > >>>>>>>>>> Sent: den 11 juni 2013 19:00
> > >>>>>>>>>> To: payload@ietf.org
> > >>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
> > >>>>>>>>>> payload format
> > >>>>>>>>>>
> > >>>>>>>>>> Dear All,
> > >>>>>>>>>>
> > >>>>>>>>>> We have just submitted versions 02 and 03 of
> > >>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as f=
ollows:
> > >>>>>>>>>>
> > >>>>>>>>>> Version 02:
> > >>>>>>>>>> URL:
> > >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-r
> > >>>>>>>>>> tp
> > >>>>>>>>>> -
> > >>>>>>>>>> h265-02.txt
> > >>>>>>>>>> Htmlized:
> > >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-0
> > >>>>>>>>>> 2
> > >>>>>>>>>> Diff:
> > >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp=
-
> > >>>>>>>>>> h2
> > >>>>>>>>>> 6
> > >>>>>>>>>> 5-
> > >>>>>>>>>> 02
> > >>>>>>>>>>
> > >>>>>>>>>> Version 03:
> > >>>>>>>>>> URL:
> > >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-schierl-payload-r
> > >>>>>>>>>> tp
> > >>>>>>>>>> -
> > >>>>>>>>>> h265-03.txt
> > >>>>>>>>>> Htmlized:
> > >>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-0
> > >>>>>>>>>> 3
> > >>>>>>>>>> Diff:
> > >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp=
-
> > >>>>>>>>>> h2
> > >>>>>>>>>> 6
> > >>>>>>>>>> 5-
> > >>>>>>>>>> 03
> > >>>>>>>>>>
> > >>>>>>>>>> Version 02 includes huge changes compared to the earlier
> > >>>>>>>>>> submitted version 01. In a short summary, the authors have
> > >>>>>>>>>> worked hard to try to make the design complete, from both
> > >>>>>>>>>> the payload structure and the signaling points of view.
> > >>>>>>>>>> Compared to version 02, version
> > >>>>>>>>>> 03 only contains a correction of the email address of an aut=
hor.
> > >>>>>>>>>>
> > >>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
> > >>>>>>>>>> other standards bodies such as 3GPP rely on the payload
> > >>>>>>>>>> format for support of H.265/HEVC in RTP based video
> > >>>>>>>>>> services, we need to progress this draft relatively quickly.
> > >>>>>>>>>> Therefore, we would like to request quick reviews from
> > >>>>>>>>>> interested parties and also request for the WG status of thi=
s draft.
> > >>>>>>>>>>
> > >>>>>>>>>> BR, YK (on behalf of the authors)
> > >>>>>>>>>> _______________________________________________
> > >>>>>>>>>> payload mailing list
> > >>>>>>>>>> payload@ietf.org
> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> > >>>>>>>>>>
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> payload mailing list
> > >>>>>>>>> payload@ietf.org
> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> > >>>>>>>> _______________________________________________
> > >>>>>>>> payload mailing list
> > >>>>>>>> payload@ietf.org
> > >>>>>>>> https://www.ietf.org/mailman/listinfo/payload
> > >>>>>>> _______________________________________________
> > >>>>>>> payload mailing list
> > >>>>>>> payload@ietf.org
> > >>>>>>> https://www.ietf.org/mailman/listinfo/payload
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > >>>
> > >


From thomas.schierl@hhi.fraunhofer.de  Mon Jul  8 03:10:50 2013
Return-Path: <thomas.schierl@hhi.fraunhofer.de>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C900321F8925 for <payload@ietfa.amsl.com>; Mon,  8 Jul 2013 03:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-yzD-M2SIX9 for <payload@ietfa.amsl.com>; Mon,  8 Jul 2013 03:10:46 -0700 (PDT)
Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4421F8C4C for <payload@ietf.org>; Mon,  8 Jul 2013 03:10:45 -0700 (PDT)
X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0
Received: from ic-pc009m.ic.tu-berlin.de (ic-pc009m.ic.tu-berlin.de [130.149.228.97]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id B98F21C90006; Mon,  8 Jul 2013 12:10:42 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com>
Date: Mon, 8 Jul 2013 12:10:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C48F3CEB-8FC0-40AF-813F-1FDEF52AC3AB@hhi.fraunhofer.de>
References: <CDF9959C.9ECA9%stewe@stewe.org> <51D4526B.9040008@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338454E0A@nasanexd02f.na.qualcomm.com> <4BC545FCE47FC14EAABD27484D62A9D01C1BB380@ESESSMB103.ericsson.se> <3879D71E758A7E4AA99A35DD8D41D3D91D48EEB9@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384578BC@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C04C@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459C6B@nasanexd02f.na.qualcomm.com> <9C2FAEDF6B678042ADE3B6686D7C6E151913C169@xmb-rcd-x07.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338459EC4@nasanexd02f.na.qualcomm.com> <69098CA5-38B3-4097-AFD2-DB0012A3E1BB@hhi.fraunhofer.de> <51D6D62E.2090705@cisco.com> <3FF7DC51-B441-4B7D-B31B-48C13BA0D7E5@hhi.fraunhofer.de> <3879D71E758A7E4AA99A35DD8D41D3D91D48F562@xmb-rcd-x14.cisco.com>
To: Mo Zanaty (mzanaty) <mzanaty@cisco.com>
X-Mailer: Apple Mail (2.1508)
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-7.0.0.1014-20000.006
X-TM-AS-Result: No--51.960-11.0-31-10
X-imss-scan-details: No--51.960-11.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TMASE-MatchedRID: IeZYkn8zfFqoB6BkKpx1kZmug812qIbz9xIiieITJai/K9mCmWrmBsUo qBn4GUiDT7k2Zp/UVqQzO548X1ZYiQ/6hdw9FUgYSEQN/D/3cG5QCOsAlaxN79dNOeiluJSBfMr dD3NIUvsOakZ3BhIK3wqP6e7S8APaRwPZcL7YQSa7bScJeyAvlgr5O7MBXAmQsKXjy/5u25vZMI rjS2GiJED/AONVDeigUlbq/4bZjdVhQIo/6MpuD0NTnAhL0/m3Xs5nqGvDCfMUWf/cATIRrJrAS HsnChAHAWMdzSV1IwbuEzNMGCluBPUe3cF58v23uIwLnB3Aqp0K3iJpXUOQQ/aH4H9eVYWysgMn LZQRV/hNoYPsmZQHk3a29EXMuQPoMC91A8xILXPvVbHa5Rs8t4N12XKYbuJLI3ymHOS8tAM4+qr sHfOFPIm0sjkOghkWE2bz2NnzjO9NfAuy6MOHAaKa0xB73sAAttKJDdalq/VeJmBTX64KQXZruQ G5/1P7jjPxwQbZO6LOgXE6r4gNcxvMQPGNwEh5h3ZN+5lFR7eGm/9Tv2/OgWrhyhOS2sZfWTFH8 4r4cDRM3ViFZiJ6JH1Loqlf1BjWfBycIaY2IkJv/kcFnp29GLPgPvvwZyAR+mSoV2MYGwDX6Xzu WIU293EThXRIGYQCSLZNZCXMGZSj6NSDI7ulr3XuAcDIAWvT+pkYmVlzZ8sUl9bvAS7WQAsIFD4 3HGfwGoenZ9i00pPMLieEBhyy2QcSBA/LYDiheUyVZX4ivrul9VzHf0qr7vYygSWEaXdVNYfISZ cwNo4T/DbY5fhiAwxDl046ubH7eLWH6Z7ulE8ksSBZTGCrwmNn8XPiALIbuIId/K6NAscBi3kqJ OK62QtuKBGekqUpPjKoPgsq7cA=
X-IMSS-DKIM-White-List: No
X-alterMIME: Yes
Cc: "Paul Bright-Thomas \(paubrigh\)" <paubrigh@cisco.com>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Submission of new versions of	H.265/HEVC	payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 10:10:50 -0000

Dear Mo,

I think I cannot  agree with your point "they are not always sufficient, =
desirable or even available in all cases of interest for RTP apps. " If =
you are using the codec as it is supposed to be used, they should be =
sufficient as presented in my earlier email and they should be =
available. I am not sure about the term "desirable" wrt. standards.

However, if there should be a very simple application, which wants to =
make use of the advanced codec features of HEVC without having the codec =
itself under control, I may be able to agree in using FUs but only under =
the prerequisite that in the normal case you SHOULD use the codec =
features as they are. Further I am still not convinced to use in such a =
case an additional mechanism in the FU header.

Anyway, it is hard for me to imagine an advanced codec product, which =
does not has control over the codec to use tools such as tiles and/or =
dependent slice segments, where the latter tool is much easier to use =
and to apply to a bitstream.

--
Thomas Schierl
Fraunhofer HHI


Am 05.07.2013 um 17:31 schrieb Mo Zanaty (mzanaty) <mzanaty@cisco.com>:

> Hi Thomas,
>=20
> Please see my reply to YK about why some RTP apps may prefer (or be =
forced to use) fragmentation rather than dependent slice segments. The =
current draft supports resilience using tiles with dependent slice =
segments. The proposed enhancement supports resilience using tiles with =
fragmentation.
>=20
> I understand that dependent slice segments were specifically added to =
allow a form of codec level fragmentation at finer granularity than =
slices. However, they are not always sufficient, desirable or even =
available in all cases of interest for RTP apps. If they were, there =
would be no need for RTP level fragmentation at all. Since the current =
draft supports RTP level fragmentation, I assume there is consensus =
among the authors that there is value in it. The proposed enhancement =
extends that value by also supporting resilience, so RTP apps which use =
fragmentation can also support resilience.
>=20
> Regards,
> Mo
>=20
> -----Original Message-----
> From: Thomas Schierl [mailto:thomas.schierl@hhi.fraunhofer.de]=20
> Sent: Friday, July 05, 2013 10:39 AM
> To: Thomas Davies (thdavies)
> Cc: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan =
Wenger; Paul Bright-Thomas (paubrigh); payload@ietf.org
> Subject: Re: [payload] Submission of new versions of H.265/HEVC =
payload format
>=20
> Dear Thomas,
>=20
> For the error resilience in the case of slices or dependent slices, =
which do match with tiles, I do not think an additional pointer =
information in the FU header does improve the error resilience =
capabilities over a system without those information.=20
>=20
> I think I did not exclude the use of FUs even for dependent slice =
fragments, but I would not require an additional mechanism to those, as =
stated in my email before.
>=20
> Thomas
> --
>=20
> Dr.-Ing. Thomas Schierl
>=20
> Head of Multimedia Communications Group
> Image Processing Department
> thomas.schierl@hhi.fraunhofer.de
>=20
> Tel.:  +49 30 31002-227
> Fax:  +49 30 31002-190
> Skype:  thomas.schierl
>=20
> Fraunhofer HHI - Heinrich Hertz Institute
> Einsteinufer 37, 10587 Berlin, Germany
> http://www.hhi.fraunhofer.de/ip/mc
>=20
> Am 05.07.2013 um 16:20 schrieb Thomas Davies <thdavies@cisco.com>:
>=20
>> Dear Thomas
>>=20
>> On your first point, the decoder always has to be told there is =
missing data. I don't see much different or fancy in the interface =
between the two cases. Usually error concealment must be addressed both =
within the codec (because of reference dependencies) and also in the =
application (because of display and call-management/error response =
functionality). That's surely a very minor issue.
>>=20
>> On the second point, the context we are considering in our proposal =
is where FUs are being used, in the circumstances Mo set out, and =
providing some level of sub-frame resilience where possible in that =
case. If your assumption is that FUs are not being used, and re-writing =
is possible/desirable, you will certainly conclude that FUs should not =
be used. Since we concluded that FUs should not be discouraged, it seems =
reasonable to consider adding features which make them more resilient =
when they are.
>>=20
>> best regards
>>=20
>> Thomas
>>=20
>> On 05/07/13 10:34, Thomas Schierl wrote:
>>> Dear Ye-Kui, all,
>>>=20
>>> Further I would tentatively assume that you can use the slice =
segment address in the dependent slice fragment header for the same =
degree of error resilience as the new-FU header, if you put a tile into =
a dependent slice. And this part would be understood by the decoder =
itself, which should be able to do the error resilience on codec level. =
Without fancy interfaces into the decoder, etc.
>>>=20
>>> A point in the discussion which seems to be missing is that the =
rewriting of a single slice into multiple dependent slice fragments =
(including also one independent slice fragment) can be done at very low =
processing costs, as shown during the standardization of HEVC.
>>>=20
>>> Thomas
>>> --
>>> Thomas Schierl
>>> Fraunhofer HHI
>>>=20
>>> Am 04.07.2013 um 19:59 schrieb "Wang, =
Ye-Kui"<yekuiw@qti.qualcomm.com>:
>>>=20
>>>> Hi Thomas,
>>>>=20
>>>> Thanks for the clarification - I think now understand your scheme =
better.
>>>>=20
>>>> So you did not intent to encapsulate only entire tiles into =
packets, though that would obviously be more error resilient as you =
won't encounter the problem where a part of a tile gets lost and the =
received rest becomes useless. Rather, one tile may be carried in two =
(or even more) packets.
>>>>=20
>>>> I think I was confused by the suggested language such as "If a =
fragmentation unit is lost, tiles in the lost fragmentation unit are =
also lost. However, tiles which are successfully received in their =
entirety can be decoded if their slice segment header containing tile =
offsets is successfully received, despite lost fragmentation units.", =
from where I got an impression that an FU includes entire tiles.
>>>>=20
>>>> As seen from other discussions, it is very questionable how big a =
penalty would be when an encoder tries to splitting encoded data into =
separate NAL units (slices or dependent slices) for MTU size matching, =
even for large CTB sizes - that's the reason why the JCT-VC later =
decided to remove the fine-granularity slice feature.
>>>>=20
>>>> Let's tentatively assume that overall penalty and the overhead of =
the new-FU approach are roughly equivalent, and take into account latest =
comments from Mo and Stephan, do we see an advantage of the new-FU =
approach compared to using dependent slices?
>>>>=20
>>>> I am not trying to conclude yet - just try to (very briefly) =
summarize the situation so far at least for myself.  We should certainly =
have more discussions - preferable involving more people who care about =
this payload format.
>>>>=20
>>>> BR, YK
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>>> Sent: Thursday, July 04, 2013 9:23 AM
>>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan =
Wenger;
>>>>> Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>>>>> format
>>>>>=20
>>>>> Hi Ye-Kui
>>>>>=20
>>>>> Thank you for the clarification - I understand your point a bit =
better now.
>>>>>=20
>>>>> With the proposed scheme there is no need for the RTP packetizer =
to parse
>>>>> slice headers or identify tile boundaries. All it needs to do is =
to keep track of the
>>>>> offset of the start of the payload to the beginning of the NALU =
and put this into
>>>>> the field. It needs to know this offset anyway. The packetizer is =
completely
>>>>> dumb.
>>>>>=20
>>>>> The point is that a decoder wishing to do error resilience can =
parse the slice
>>>>> header and identify the tile boundaries in the case that a packet =
goes missing,
>>>>> for tiles that occur in the same frame but after the packet that =
is lost. The
>>>>> decoder can compare the tile offsets with the FU offsets to work =
out what data
>>>>> is missing.
>>>>>=20
>>>>> Re dependent slices, there are indirect overheads as well, which =
come from
>>>>> having to quantize the packet size to a whole number of tiles, =
plus you have to
>>>>> manage the encoder to match the MTU size. The granularity of tiles =
you need
>>>>> for your parallel processing may not match the granularity you =
need to fit in
>>>>> the MTU very well.
>>>>>=20
>>>>> Best regards
>>>>>=20
>>>>> Thomas
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>> Sent: 04 July 2013 16:34
>>>>> To: Thomas Davies (thdavies); Mo Zanaty (mzanaty); Rickard =
Sj=F6berg; Stephan
>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>> Cc: payload@ietf.org
>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC =
payload
>>>>> format
>>>>>=20
>>>>> Hi Thomas,
>>>>>=20
>>>>> My point was really about using dependent slices, not about 1 or N =
tiles per
>>>>> packets (sorry that I did not make that clearer). Whatever =
strategy you would
>>>>> like to do in terms of the number of tiles in a packet, using =
dependent slices can
>>>>> do the same, as each dependent slice can include 1 or N tiles.
>>>>>=20
>>>>> I see the following advantages with the approach using dependent =
slices
>>>>> instead of defining new FUs:
>>>>>=20
>>>>> - First of all, no need to define new payload structures.
>>>>>=20
>>>>> - The RTP packetizer does not need to parse slice headers to =
identify boundaries
>>>>> of tiles within a coded slice, as tiles of one SLICE are already =
in separate NAL
>>>>> units each containing a DEPENDENT SLICE.
>>>>>=20
>>>>> - No additional overhead in packetization (the 1-byte FU header =
and the 2- or
>>>>> 4-byte FU offset). The overhead of the short slice header for =
dependent slice
>>>>> NAL units is compensated by less number of tile entry offsets =
signalled, as the
>>>>> entry offset of the first tile in each NAL unit is not signalled =
in the slice header.
>>>>> Using dependent slices would need more two-byte NAL unit headers, =
while
>>>>> using new FUs would need more two-byte packet payload headers, and =
the
>>>>> overhead bits here are the same for both methods.
>>>>>=20
>>>>> Am I missing anything here?
>>>>>=20
>>>>> BR, YK
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Thomas Davies (thdavies) [mailto:thdavies@cisco.com]
>>>>>> Sent: Thursday, July 04, 2013 1:49 AM
>>>>>> To: Wang, Ye-Kui; Mo Zanaty (mzanaty); Rickard Sj=F6berg; Stephan
>>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>> Yes, we did think about one tile per packet or N tiles per =
packet,
>>>>>> also: I guess that is where we started from. Then you could =
indeed
>>>>>> align missing tiles with missing sequence numbers.
>>>>>>=20
>>>>>> The issue is that you need to guarantee that you are doing this =
for it
>>>>>> to be useful, and the decoder needs to know that this is =
guaranteed
>>>>>> through some form of other signalling. However, the bitstream =
chunk
>>>>>> associated to a tile is extremely variable, and many tile chunks =
would
>>>>>> be very small. So there is significant packetization overhead for =
them if there
>>>>> is one tile per packet.
>>>>>> Having N>1 reduces this overhead, but it is still there and as N
>>>>>> increases you run the risk of breaking the MTU size which then
>>>>>> requires that you have to re- encode to fit things in and meet =
the
>>>>>> guarantee. There is definitely no time to re-encode whole tiles,
>>>>>> especially if you are already using them for parallelization. =
Thus you
>>>>>> might have to break the guarantee and fragment the packet anyhow, =
losing
>>>>> the resilience.
>>>>>> The advantage that we see with the proposal is that you can get =
fairly
>>>>>> similar resilience to regular slice MTU-size matching, but with =
much
>>>>>> lower overheads as you can have a single regular slice header per =
frame, yet
>>>>> have a "dumb"
>>>>>> packetization process and no need to re-encode to hit MTU =
targets. In
>>>>>> H264 MTU matching usually means re-encoding just one or two 16x16 =
MBs.
>>>>>> In H265 it involves re-encoding at least one 64x64 CTB, and if =
you are
>>>>>> doing tiles then you can get tiny "dangling slices" at the end of =
a
>>>>>> tile, which means more small packets.
>>>>>>=20
>>>>>> Best regards
>>>>>>=20
>>>>>> Thomas
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>> Sent: 04 July 2013 07:02
>>>>>> To: Mo Zanaty (mzanaty); Rickard Sj=F6berg; Thomas Davies =
(thdavies);
>>>>>> Stephan Wenger; Paul Bright-Thomas (paubrigh)
>>>>>> Cc: payload@ietf.org
>>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>>> payload format
>>>>>>=20
>>>>>>=20
>>>>>> An interesting idea. Using dependent slices (again :-) together =
with
>>>>>> tiles would do the trick too (each tile in one dependent slice, =
and
>>>>>> then each dependent slice NAL unit in one single NAL unit =
packet).
>>>>>>=20
>>>>>> Have you guys done an analysis comparing the pros and cons of the =
two
>>>>>> alternative approaches?
>>>>>>=20
>>>>>> BR, YK
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
>>>>>>> Sent: Wednesday, July 03, 2013 9:51 PM
>>>>>>> To: Rickard Sj=F6berg; Wang, Ye-Kui; Thomas Davies (thdavies); =
Stephan
>>>>>>> Wenger; Paul Bright-Thomas (paubrigh)
>>>>>>> Cc: payload@ietf.org
>>>>>>> Subject: RE: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Thomas, Paul and I have been working on improving packet loss
>>>>>>> resilience using fragments and tiles. I mentioned this to =
Stephan at
>>>>>>> IETF 86 in Orlando, and promised to have draft text ready before
>>>>>>> Berlin. Here is the proposed text along with an overview of the =
rationale.
>>>>>>>=20
>>>>>>> Rationale:
>>>>>>>=20
>>>>>>> 1. Resilience to packet loss requires independent slices or =
tiles.
>>>>>>> Since independence requires restrictions on some coding tools, =
both
>>>>>>> potentially incur slight penalties in coding efficiency, with a
>>>>>>> smaller penalty
>>>>>> for tiles.
>>>>>>> 2. Fragmentation in a higher layer like RTP can have several
>>>>>>> advantages over similar features in a codec layer like slices
>>>>>>> (independent or
>>>>>> dependent).
>>>>>>> a. Efficiency: RTP fragmentation has finer (byte) granularity =
while
>>>>>>> slices have much larger (CTB or tile) granularity. It also has =
less
>>>>>>> slice segment header overhead, especially for independent =
slices.
>>>>>>> This can impact the efficiency of the packetized stream in terms =
of
>>>>>>> both bits and
>>>>>> packets per second.
>>>>>>> b. Performance: Encoders must perform extra processing to limit
>>>>>>> slice sizes, which can impact encoder performance. Some
>>>>>>> implementations speculatively end a slice based on computed
>>>>>>> statistics (which aggravates a.), while others recode a slice if =
the
>>>>>>> size is exceeded (which
>>>>>> aggravates b.).
>>>>>>> c. Decoupling: Not all encoders will support limiting slice size =
to MTU size.
>>>>>>> Applications (for live or stored content) using such encoders =
can
>>>>>>> still support MTU limits using RTP fragmentation since it is
>>>>>>> decoupled from
>>>>>> the encoder.
>>>>>>> d. Multi-party: The encoded content may go to multiple receivers
>>>>>>> with different MTUs. RTP fragmentation can handle this with
>>>>>>> lightweight repacketization at middle boxes whereas slices incur
>>>>> heavyweight transcoding.
>>>>>>> 3. Combining fragmentation and tiles can improve resilience =
while
>>>>>>> retaining the above advantages, if fragments are enhanced to =
contain
>>>>>>> offsets (similar to IP fragmentation). This is described in the
>>>>>>> proposed draft text below, which would immediately follow =
section
>>>>>>> 4.7
>>>>>> Fragmentation Units.
>>>>>>> Draft Text:
>>>>>>>=20
>>>>>>> 4.7.1 Fragmentation Units with Fragment Offsets
>>>>>>>=20
>>>>>>> If a fragmented NAL unit contains tiles, its slice segment =
header
>>>>>>> contains offsets to the data of each tile. These offsets can be =
used
>>>>>>> for random access to any tile for parallel processing, region of
>>>>>>> interest extraction, and resilience to errors in other tiles. =
These
>>>>>>> offsets can also be used to provide resilience to packet loss, =
in
>>>>>>> conjunction with fragment offsets contained in two types of
>>>>>>> fragmentation
>>>>>> units: FU-A2 and FU-A4.
>>>>>>> Fragmentation units FU-A2 and FU-A4 contain a fragment offset =
before
>>>>>>> the FU payload. FU-A2 contains a 2-byte offset as shown in =
Figure X.
>>>>>>> FU-A4 contains a 4-byte offset as shown in Figure Y. The offset
>>>>>>> indicates the total number of bytes in all prior FU payloads of =
the
>>>>>>> fragmented
>>>>>> NAL unit.
>>>>>>>=20
>>>>>>>   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
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  |      FU-A2 NAL HDR (type=3D52)  |   FU header   | FU-A2 =
offset  |
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  | FU-A2 offset  |     DONL (optional)           |               =
|
>>>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               =
|
>>>>>>>  |                                                               =
|
>>>>>>>  |                         FU payload                            =
|
>>>>>>>  |                                                               =
|
>>>>>>>  |                               =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  |                               :...OPTIONAL RTP padding        =
|
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>=20
>>>>>>>                 Figure X   RTP payload format for FU-A2
>>>>>>>=20
>>>>>>>=20
>>>>>>>   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
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  |      FU-A4 NAL HDR (type=3D53)  |   FU header   | FU-A4 =
offset  |
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  |      FU-A4 offset                             | =
DONL(optional)|
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  | DONL(optional)|                                               =
|
>>>>>>>  +-+-+-+-+-+-+-+-+         FU payload                            =
|
>>>>>>>  |                                                               =
|
>>>>>>>  |                               =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>  |                               :...OPTIONAL RTP padding        =
|
>>>>>>>  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>=20
>>>>>>>                 Figure Y   RTP payload format for FU-A4
>>>>>>>=20
>>>>>>>=20
>>>>>>> Since the offset of the first FU payload of a fragmented NAL =
unit is
>>>>>>> zero, and the Start (S) bit in the FU header is sufficient to
>>>>>>> indicate this, the first fragmentation unit of a fragmented NAL =
unit
>>>>>>> SHOULD use FU-A, but MAY use
>>>>>>> FU-A2 or FU-A4 with an offset of zero. Subsequent fragmentation
>>>>>>> units of a fragmented NAL unit MAY use FU-A2 or FU-A4 with a
>>>>>>> non-zero offset. The Start
>>>>>>> (S) bit in the FU header MUST NOT be set if the FU-A2 or FU-A4
>>>>>>> contains a non- zero offset, and MUST be set if it contains a =
zero offset.
>>>>>>>=20
>>>>>>> If a fragmentation unit is lost, tiles in the lost fragmentation =
unit are also
>>>>> lost.
>>>>>>> However, tiles which are successfully received in their entirety =
can
>>>>>>> be decoded if their slice segment header containing tile offsets =
is
>>>>>>> successfully received, despite lost fragmentation units. =
Fragment
>>>>>>> offsets in FU-A2 or FU-A4 are required in order to recover from =
loss
>>>>>>> of prior fragmentation units and continue decoding subsequent =
tiles.
>>>>>>>=20
>>>>>>> The following heuristic SHOULD be applied to determine if the =
lost
>>>>>>> fragmentation units are all part of the same fragmented NAL unit =
as
>>>>>>> subsequently received fragmentation units with identical RTP
>>>>>>> timestamps and identical values of NAL unit header layer ID and =
temporal
>>>>> ID.
>>>>>>> 1. Let N be the number of missing sequence numbers between two
>>>>>>> received fragmentation units with known offsets.
>>>>>>> 2. Let P be the FU payload size of the first of the two received =
FUs.
>>>>>>> 3. Let D be the difference in the offsets, minus P.
>>>>>>>  (This is the number of missing FU payload bytes.) 4. Let E be N =
times P.
>>>>>>>  (This is the estimated number of missing FU payload bytes.) 5.
>>>>>>> Let ERROR be the absolute difference between D and E, divided by =
D.
>>>>>>> 6. If ERROR<  50%, it is likely all FUs are part of the same
>>>>>>> fragmented NAL unit, otherwise it is unlikely.
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>> Mo
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] =
On
>>>>>>> Behalf Of Rickard Sj=F6berg
>>>>>>> Sent: Wednesday, July 03, 2013 3:38 PM
>>>>>>> To: Wang, Ye-Kui; Thomas Davies (thdavies); Stephan Wenger
>>>>>>> Cc: payload@ietf.org
>>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Dear all,
>>>>>>>=20
>>>>>>> I wrote slices and not dependent slices since the slice =
granularity
>>>>>>> and slice/tile rule applies to both slices and dependent slices.
>>>>>>> Sorry for the confusion. I will now use 'independent slices' and
>>>>>>> 'dependent slices' to distinguish between them.
>>>>>>>=20
>>>>>>> I do not question the use of independent slices, I find them =
useful
>>>>>>> in some applications.
>>>>>>>=20
>>>>>>> But the current RTP payload text says:
>>>>>>>=20
>>>>>>> "FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>>     video telephony, video conferencing, live streaming and live
>>>>>>>     broadcast, in which cases dependent slice segments SHOULD be =
used
>>>>>>>     when a slice should be transported in multiple RTP packets."
>>>>>>>=20
>>>>>>> I believe that FUs are a viable option to dependent slices for =
the
>>>>>>> reasons I listed in my previous e-mail and think that we should =
not
>>>>>>> recommend dependent slices over FUs but leave it to the =
implementer.
>>>>>>>=20
>>>>>>> BR
>>>>>>> Rickard
>>>>>>>=20
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] =
On
>>>>>>> Behalf Of Wang, Ye-Kui
>>>>>>> Sent: den 3 juli 2013 20:43
>>>>>>> To: Thomas Davies; Stephan Wenger
>>>>>>> Cc: payload@ietf.org
>>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>>> payload format
>>>>>>>=20
>>>>>>> Hi All,
>>>>>>>=20
>>>>>>> I drafted an email replying directly to Rickard but did not =
finish
>>>>>>> and there was a meeting (and then Stephan's and Thomas' emails =
came).
>>>>>>>=20
>>>>>>> I wanted to comment that Rickard was comparing the use of FUs vs
>>>>>>> slices, not FUs vs dependent slices, while the recommendation in =
the
>>>>>>> draft is recommending use of dependent slices over FUs in
>>>>>>> live-encoding scenarios (so this answers Thomas question: the
>>>>>>> intention was
>>>>>> dependent slices ).
>>>>>>> In any case, it does not make much sense to try MTU size =
matching
>>>>>>> and at the same time use either dependent slices or FUs, because
>>>>>>> dependent slices and FUs should not be used when there are
>>>>>>> considerable packet losses, while MTU size matching should be
>>>>>>> applied when there are
>>>>>> considerable packet losses.
>>>>>>> For live encoding, whenever splitting of a regular slice is =
needed,
>>>>>>> the splitting can be done by the encoder using dependent slices =
-
>>>>>>> and the encoder has more knowledge and is more powerful than the =
RTP
>>>>>>> packetizer and thus can do a better job for the splitting.
>>>>>>>=20
>>>>>>> BR, YK
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: payload-bounces@ietf.org =
[mailto:payload-bounces@ietf.org]
>>>>>>>> On Behalf Of Thomas Davies
>>>>>>>> Sent: Wednesday, July 03, 2013 9:34 AM
>>>>>>>> To: Stephan Wenger
>>>>>>>> Cc: payload@ietf.org
>>>>>>>> Subject: Re: [payload] Submission of new versions of H.265/HEVC
>>>>>>>> payload format
>>>>>>>>=20
>>>>>>>> Hi Stephan
>>>>>>>>=20
>>>>>>>> I think I agree with Rickard.
>>>>>>>>=20
>>>>>>>> I think the text in question states a preference for =
_dependent_
>>>>>>>> slice segments, which have no error resiliency advantage over =
FUs.
>>>>>>>> Is this just a
>>>>>>> typo?
>>>>>>>> <snip>
>>>>>>>>=20
>>>>>>>> FUs SHOULD NOT be applied in live-encoding scenarios such as
>>>>>>>>      video telephony, video conferencing, live streaming and =
live
>>>>>>>>      broadcast, in which cases dependent slice segments SHOULD =
be used
>>>>>>>>      when a slice should be transported in multiple RTP =
packets.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> </snip>
>>>>>>>>=20
>>>>>>>> In general FUs may be used where error conditions are known to =
be
>>>>>>>> benign, for greater efficiency, and also where for whatever =
reason
>>>>>>>> the encoder cannot support MTU matching.
>>>>>>>>=20
>>>>>>>> We also are formulating some more general comments on this area
>>>>>>>> which we hope to provide more fully soon.
>>>>>>>>=20
>>>>>>>> best regards
>>>>>>>>=20
>>>>>>>> Thomas
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 03/07/13 17:22, Stephan Wenger wrote:
>>>>>>>>> Hi Rickard,
>>>>>>>>> Commenting only on slices vs. FUs.
>>>>>>>>> The preference for slices over FUs, historically, was pushed =
by
>>>>>>>>> myself into RFC 3984 for reasons of error resilience, and was
>>>>>>>>> moved over to this draft for the same reason.  Loose a slice,
>>>>>>>>> and you can recover at the next slice boundary; loose an FU, =
and
>>>>>>>>> you have to wait for the next slice header and throw away all
>>>>>>>>> trailing FUs.  RTP is in virtually all cases run over UDP, and
>>>>>>>>> in the typical Internet scenario UDP is lossy (in contrast to
>>>>>>>>> private, managed IP-network, which may have other constraints,
>>>>>>>>> but are not the IETF's main
>>>>>>>>> concern.) To set your remarks into context, let's first
>>>>>>>>> understand what we are talking
>>>>>>>>> about: the cost of slices is the overhead stemming from the
>>>>>>>>> insertion of slice headers (in-picture syntax prediction) and
>>>>>>>>> from the packet headers themselves.  And, of course,
>>>>>>>>> implementation complexity, but we should not be in the =
business
>>>>>>>>> to encourage implementor
>>>>>>> laziness when
>>>>>>>>> there would be a more complex, but better suited tool =
available.    The
>>>>>>>>> additional packetization overhead is only incurred when, as a
>>>>>>>>> result of incompetently filled packets (which, I agree, is =
more
>>>>>>>>> likely with
>>>>>>>>> 64x64 CUs than with 16/16 macroblocks), an additional packet
>>>>>>>>> needs to be inserted.  You may remember a quick analysis of =
mine
>>>>>>>>> we discussed way back early in JCT, where we (I think) agreed
>>>>>>>>> that the practical impact is negligible in almost all non-tile
>>>>>>>>> scenarios (mostly because an additional overhead of 50 bytes =
or
>>>>>>>>> so--3% or less of the coded picture size) is incurred
>>>>>>>>> statistically only rarely (only in those cases where an
>>>>>>>>> additional packet would need to be generated because of the
>>>>>>>>> video coding related overhead for the use of slices).  The
>>>>>>>>> prediction overhead of the use of regular slices has been =
shown
>>>>>>>>> to be substantial--the price one needs to pay for independent
>>>>>>>>> decodability--but for entropy slices that overhead virtually
>>>>>>> does not exist.
>>>>>>>>> With respect to tiles, I think you have a point though,
>>>>>>>>> especially when considering the type of massive parallel
>>>>>>>>> implementations for relatively small picture sizes some folks =
have been
>>>>> considering.
>>>>>>>>> OTOH, because FUs are trivial to implement--some say in =
contrast
>>>>>>>>> to slices--and because (I hope) we all agree that using FUs in
>>>>>>>>> error prone scenarios is a bad idea if you could use slices =
(but
>>>>>>>>> for reasons like the tile connection you mentioned), the draft
>>>>>>>>> should IMO continue to set a preference for the use of regular
>>>>>>>>> slices over FUs.  To avoid underperforming systems due to
>>>>>>>>> implementer
>>>>>> laziness.
>>>>>>>>> However, this is the IETF.  We don't have to worry about the
>>>>>>>>> word-count of explanatory language.  In fact, explaining such
>>>>>>>>> complex tradeoffs and relationships is generally encouraged =
here.
>>>>>>>>> So let's
>>>>>>> just do that:
>>>>>>>>> express a preference of the use of regular slices (SHOULD) =
when
>>>>>>>>> you expect losses and can use them (real-time encoding, no
>>>>>>>>> tiling structure that would lead to unacceptable packetization
>>>>>>>>> overhead); and suggest (MAY) the use of FUs in other =
scenarios.
>>>>>>>>> Accompanied by a more coherently expressed analysis.
>>>>>>>>> Stephan
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 7.3.2013 06:46 , "Rickard
>>>>>>>>> Sj=F6berg"<rickard.sjoberg@ericsson.com>
>>>>>>> wrote:
>>>>>>>>>> Hi Ye-Kui,
>>>>>>>>>>=20
>>>>>>>>>> Thanks for your feedback on my comments, your suggestions =
look
>>>>>>>>>> good to
>>>>>>>> me.
>>>>>>>>>> Regarding discouraging fragmentation units (FUs) for
>>>>>>>>>> live-encoding scenarios in section 4.7, I think using FUs =
does
>>>>>>>>>> make sense when you do not have many non-VLC NAL units for
>>>>>>>>>> aggregation. The spatial granularity of slices was 16x16 =
pixels
>>>>>>>>>> in H.264 but is typically
>>>>>>>>>> 64x64 for HEVC which means that MTU size matching is done =
with
>>>>>>>>>> units that are 16x larger. This may lead to a larger number =
of
>>>>>>>>>> smaller packets when slices are used compared to FUs. In
>>>>>>>>>> addition, there is the HEVC rule of slice and tile boundaries
>>>>>>>>>> that makes the slice granularity equal to the tile =
granularity
>>>>>>>>>> for cases when slices span multiple tiles. Finally, FUs are
>>>>>>>>>> easier to implement since you do not need to care about when =
to
>>>>>>>>>> break your slice to not exceed the MTU size limit. I think =
both
>>>>>>>>>> slices and FUs has their merits and the choice between them =
for
>>>>>>>>>> live-encoding should be left for
>>>>>>> the implementer.
>>>>>>>>>> Regarding the use of PicOrderCntVal for feedback in 8.2 and =
8.2
>>>>>>>>>> and the POC MSB sync issue, I agree that this is a corner =
case
>>>>>>>>>> that we probably will not see much of in practice. I have no
>>>>>>>>>> text change suggestion at the moment.
>>>>>>>>>>=20
>>>>>>>>>> BR
>>>>>>>>>> Rickard
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Wang, Ye-Kui [mailto:yekuiw@qti.qualcomm.com]
>>>>>>>>>> Sent: den 24 juni 2013 01:00
>>>>>>>>>> To: Rickard Sj=F6berg; payload@ietf.org
>>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC payload
>>>>>>>>>> format
>>>>>>>>>>=20
>>>>>>>>>> Hi Rickard,
>>>>>>>>>>=20
>>>>>>>>>> Thanks for the careful review and the comments. Please see =
inline
>>>>> below.
>>>>>>>>>> BR, YK
>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Rickard Sj=F6berg =
[mailto:rickard.sjoberg@ericsson.com]
>>>>>>>>>>> Sent: Thursday, June 20, 2013 9:17 AM
>>>>>>>>>>> To: Wang, Ye-Kui; payload@ietf.org
>>>>>>>>>>> Subject: RE: Submission of new versions of H.265/HEVC =
payload
>>>>>>>>>>> format
>>>>>>>>>>>=20
>>>>>>>>>>> Dear all,
>>>>>>>>>>>=20
>>>>>>>>>>> I have taken a first look at =
draft-schierl-payload-rtp-h265-03
>>>>>>>>>>> and have some questions/comments.
>>>>>>>>>>>=20
>>>>>>>>>>> My first question is what extensions of HEVC that
>>>>>>>>>>> draft-schierl-payload-rtp-
>>>>>>>>>>> h265 is intended to cover? The draft mentions "future =
scalable
>>>>>>>>>>> or 3D  video coding  extensions  of  this specification", =
what
>>>>>>>>>>> extensions do you refer to?
>>>>>>>>>>> Is the intent to cover the all HEVC extensions in a single
>>>>>>>>>>> payload specification?
>>>>>>>>>>>=20
>>>>>>>>>> [YK] That is in the semantics of LayerId (nuh_layer_id), =
where
>>>>>>>>>> "this specification" should be replaced with "[HEVC]". It is
>>>>>>>>>> sort of copy-and-paste error. Thanks for the good catching. =
No,
>>>>>>>>>> there is no intention to cover HEVC extensions in this =
payload
>>>>>>>>>> specification, though we intentionally to have the
>>>>>>>>>> depacketization process and the use with feedback messages to
>>>>>>>>>> work for HEVC scalability
>>>>>>> and 3DV extensions.
>>>>>>>>>>> Another question for my understanding is why "Receivers MUST
>>>>>>>>>>> pass picture timing SEI messages and decoding unit =
information
>>>>>>>>>>> SEI messages to the decoder"?
>>>>>>>>>> [YK] Generally, RTP receivers should/must pass all NAL units
>>>>>>>>>> specified by the video coding spec to the video decoders. =
This
>>>>>>>>>> is emphasized here for the two timing related SEI messages
>>>>>>>>>> after it is said that picture output timing in RTP timestamps
>>>>>>>>>> should be used instead (to avoid giving a wrong impression to
>>>>>>>>>> readers that the SEI messages should be ignored). If an RTP
>>>>>>>>>> receiver discards the SEI messages, then HRD conformance
>>>>>>>>>> checking for the bitstream that was possible would be =
disabled,
>>>>>>>>>> and also the information related to frame
>>>>>>>> doubling or tripping would be lost.
>>>>>>>>>>> In "5. Packetization Rules" in Section 4.7, there are 5 =
rules.
>>>>>>>>>>> The fourth one does not seem to be a rule since there is no
>>>>>>>>>>> "MUST" or "SHOULD" in the corresponding text.
>>>>>>>>>> [YK] I see your point, it is only a "MAY" rule. An =
alternative
>>>>>>>>>> to put this as a packetization rule is to put it as part of =
the
>>>>>>>>>> semantics of NAL unit header (1.1.4), but that sub-section
>>>>>>>>>> belongs to an overview wherein normative language (even =
"MAY")
>>>>>>>>>> should not appear. One solution to this is to insert "Payload
>>>>>>>>>> Header
>>>>>> Usage"
>>>>>>>>>> after 4.1 "RTP Header Usage" and include at least this item =
there.
>>>>>>>>>> I will do this in the next version unless there is a better =
suggestion.
>>>>>>>>>>=20
>>>>>>>>>>> Further, the fifth one discourages using FUs, what are the
>>>>>>>>>>> reasons behind that?
>>>>>>>>>> [YK] The bullet item only discourages using FUs for
>>>>>>>>>> live-encoding scenarios, wherein dependent slice segments =
should be
>>>>> used instead.
>>>>>>>>>> This was added after a discussion (among the authors) on the
>>>>>>>>>> need of whether to specify a payload structure for mixed FU =
and
>>>>>>>>>> aggregation packets and
>>>>>>>>>> from that discussion we concluded that encoding dependent =
slice
>>>>>>>>>> segments
>>>>>>>>>> at source coding level already allows for the use cases and
>>>>>>>>>> using of FUs for live-encoding does not make sense. Please =
let
>>>>>>>>>> us know if you think differently.
>>>>>>>>>>=20
>>>>>>>>>>> In 8.2 and 8.3, the feedback messages are using =
PicOrderCntVal.
>>>>>>>>>>> Isn't there a possiblity that the MSB of PicOrderCntVal may
>>>>>>>>>>> differ between the encoder and decoder?
>>>>>>>>>> [YK] Good question. In theory this is indeed possible when
>>>>>>>>>> random accessing to a bitstream is performed. However, it =
would
>>>>>>>>>> not happen in conversational applications where the feedback
>>>>>>>>>> messages may
>>>>>> be used.
>>>>>>>>>> Therefore, to me this would just work just fine. But please
>>>>>>>>>> feel free to make other suggestions.
>>>>>>>>>>=20
>>>>>>>>>>> The use of spatial-segmentation-idc may need some updates to
>>>>>>>>>>> be useful, let me come back to that later on.
>>>>>>>>>>>=20
>>>>>>>>>> [YK] OK. Look forward to seeing your input herein.
>>>>>>>>>>=20
>>>>>>>>>>> I have also a number of spelling suggestions for your =
considerations:
>>>>>>>>>>>=20
>>>>>>>>>>> Section 1.1:
>>>>>>>>>>> Replace "community" by "communities"
>>>>>>>>>> [YK] I guess both are OK. But anyway I just changed it per =
your
>>>>>>>>>> suggestion (for the next version).
>>>>>>>>>>=20
>>>>>>>>>>> Section 1.1.1:
>>>>>>>>>>> Replace "In addition, interpolation filter" by "In addition,
>>>>>>>>>>> the interpolation filter"
>>>>>>>>>> [YK] Thanks - done.
>>>>>>>>>>=20
>>>>>>>>>>> Replace "skipping the transform coding" by "skipping the =
transform"
>>>>>>>>>>> (transform_skip_flag of HEVC skips the transform, not the
>>>>>>>>>>> coding)
>>>>>>>>>>>=20
>>>>>>>>>> [YK] Done.
>>>>>>>>>>=20
>>>>>>>>>>> Section 1.1.2:
>>>>>>>>>>> Replace:
>>>>>>>>>>> "2) An indication of whether there is any parameter set =
within
>>>>>>>>>>> the current coded video sequence that updates another
>>>>>>>>>>> parameter set of the same type preceding in decoding order."
>>>>>>>>>>> by:
>>>>>>>>>>> "2) An indication of whether there is no parameter set =
update
>>>>>>>>>>> in the coded video sequence."
>>>>>>>>>>> since that is what no_parameter_set_update_flag in HEVC =
indicates.
>>>>>>>>>>>=20
>>>>>>>>>> [YK] Changed the wording to "An indication of whether there =
is
>>>>>>>>>> no parameter set within the current coded video sequence that
>>>>>>>>>> updates another parameter set of the same type preceding in
>>>>>>>>>> decoding
>>>>>> order."
>>>>>>>>>>> Section 4.7:
>>>>>>>>>>> Replace "Type" in Figure 10, and "Type:  6 bits" by "FU =
Type"
>>>>>>>>>>> and "FU
>>>>>>>>>>> Type:  6 bits" to avoid confusion with the Type in the =
payload header.
>>>>>>>>>>>=20
>>>>>>>>>> [YK] Good point again. I will change the field name to be =
"FuType".
>>>>>>>>>>=20
>>>>>>>>>>> Section 6:
>>>>>>>>>>> Replace "recovery" by "recover"
>>>>>>>>>> [YK] Done.
>>>>>>>>>>=20
>>>>>>>>>>> Section 7.1:
>>>>>>>>>>> Replace "level-id" by "level-idc"
>>>>>>>>>> [YK] We are consistently using "id" for profile-id, level-id,
>>>>>>>>>> max-recv-level-id etc, similarly as in RFC 6184, instead of =
"idc".
>>>>>>>>>>=20
>>>>>>>>>>> Replace "sub_layer_leve_idc[j]" by "sub_layer_level_idc[j]"
>>>>>>>>>> [YK] Done.
>>>>>>>>>>=20
>>>>>>>>>>> Section 8:
>>>>>>>>>>> Replace "two  payload-specific  feedback  messages" by "a
>>>>>>>>>>> payload-specific feedback  message", since only SPLI is
>>>>>>>>>>> "Assigned in this memo".
>>>>>>>>>>> Also, consider removing references to H.264 in the last
>>>>>>>>>>> paragraph of Section
>>>>>>>>>>> 8 since the memo is about HEVC.
>>>>>>>>>> [YK] Good catch again. Changed.
>>>>>>>>>>=20
>>>>>>>>>>> Section 8.1:
>>>>>>>>>>> Seems to me that "There MUST be exactly one RPSI contained =
in
>>>>>>>>>>> the FCI field" should be "There MUST be exactly one SPLI
>>>>>>>>>>> contained in the FCI field"
>>>>>>>>>> [YK] Another good catch. Changed.
>>>>>>>>>>=20
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Rickard Sj=F6berg
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: payload-bounces@ietf.org
>>>>>>>>>>> [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
>>>>>>>>>>> Sent: den 11 juni 2013 19:00
>>>>>>>>>>> To: payload@ietf.org
>>>>>>>>>>> Subject: [payload] Submission of new versions of H.265/HEVC
>>>>>>>>>>> payload format
>>>>>>>>>>>=20
>>>>>>>>>>> Dear All,
>>>>>>>>>>>=20
>>>>>>>>>>> We have just submitted versions 02 and 03 of
>>>>>>>>>>> draft-schierl-payload-rtp-h265, for which the links are as =
follows:
>>>>>>>>>>>=20
>>>>>>>>>>> Version 02:
>>>>>>>>>>> URL:
>>>>>>>>>>> =
http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>>> h265-02.txt
>>>>>>>>>>> Htmlized:
>>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
>>>>>>>>>>> Diff:
>>>>>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>>> 5-
>>>>>>>>>>> 02
>>>>>>>>>>>=20
>>>>>>>>>>> Version 03:
>>>>>>>>>>> URL:
>>>>>>>>>>> =
http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-
>>>>>>>>>>> h265-03.txt
>>>>>>>>>>> Htmlized:
>>>>>>>>>>> http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
>>>>>>>>>>> Diff:
>>>>>>>>>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h26
>>>>>>>>>>> 5-
>>>>>>>>>>> 03
>>>>>>>>>>>=20
>>>>>>>>>>> Version 02 includes huge changes compared to the earlier
>>>>>>>>>>> submitted version 01. In a short summary, the authors have
>>>>>>>>>>> worked hard to try to make the design complete, from both =
the
>>>>>>>>>>> payload structure and the signaling points of view. Compared
>>>>>>>>>>> to version 02, version
>>>>>>>>>>> 03 only contains a correction of the email address of an =
author.
>>>>>>>>>>>=20
>>>>>>>>>>> Due to that the industry is eager to deploy H.265/HEVC and
>>>>>>>>>>> other standards bodies such as 3GPP rely on the payload =
format
>>>>>>>>>>> for support of H.265/HEVC in RTP based video services, we =
need
>>>>>>>>>>> to progress this draft relatively quickly.
>>>>>>>>>>> Therefore, we would like to request quick reviews from
>>>>>>>>>>> interested parties and also request for the WG status of =
this draft.
>>>>>>>>>>>=20
>>>>>>>>>>> BR, YK (on behalf of the authors)
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>> _______________________________________________
>>>>>>>>> payload mailing list
>>>>>>>>> payload@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>>> _______________________________________________
>>>>>>>> payload mailing list
>>>>>>>> payload@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>> _______________________________________________
>>>>>>> payload mailing list
>>>>>>> payload@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>>>> _______________________________________________
>>>>>>> payload mailing list
>>>>>>> payload@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/payload
>>>> _______________________________________________
>>>> payload mailing list
>>>> payload@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/payload
>>>>=20
>>=20
>=20


From internet-drafts@ietf.org  Wed Jul 10 08:50:19 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4103911E8129; Wed, 10 Jul 2013 08:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3onROMoRBu1; Wed, 10 Jul 2013 08:50:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9529011E812F; Wed, 10 Jul 2013 08:50:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130710155018.2660.90024.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2013 08:50:18 -0700
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 15:50:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Audio/Video Transport Payloads Working Gr=
oup of the IETF.

	Title           : RTP Payload Format for VP8 Video
	Author(s)       : Patrik Westin
                          Henrik F Lundin
                          Michael Glover
                          Justin Uberti
                          Frank Galligan
	Filename        : draft-ietf-payload-vp8-09.txt
	Pages           : 30
	Date            : 2013-07-10

Abstract:
   This memo describes an RTP payload format for the VP8 video codec.
   The payload format has wide applicability, as it supports
   applications from low bit-rate peer-to-peer usage, to high bit-rate
   video conferences.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-vp8

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-vp8-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stewe@stewe.org  Wed Jul 10 13:28:11 2013
Return-Path: <stewe@stewe.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BD621F9EE7; Wed, 10 Jul 2013 13:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfGk8StFlPWB; Wed, 10 Jul 2013 13:28:06 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id F30DC21F9CD7; Wed, 10 Jul 2013 13:28:05 -0700 (PDT)
Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB189.namprd07.prod.outlook.com (10.242.167.147) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 10 Jul 2013 20:28:03 +0000
Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.32]) with mapi id 15.00.0702.005; Wed, 10 Jul 2013 20:28:02 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
Thread-Index: AQHOfYUxhFi/7yUXdEGnXmExcC+EyZld54eA
Date: Wed, 10 Jul 2013 20:28:02 +0000
Message-ID: <CE0310FB.9F149%stewe@stewe.org>
In-Reply-To: <20130710155018.2660.90024.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [71.202.147.60]
x-forefront-prvs: 0903DD1D85
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(24454002)(377424004)(65816001)(77096001)(31966008)(66066001)(47446002)(47736001)(56816003)(81542001)(63696002)(54316002)(59766001)(74706001)(56776001)(76786001)(51856001)(47976001)(76482001)(77982001)(79102001)(36756003)(83072001)(53806001)(74502001)(4396001)(74662001)(76176001)(69226001)(74366001)(80022001)(50986001)(74876001)(49866001)(76796001)(81342001)(46102001)(16406001)(54356001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB189; H:CO1PR07MB191.namprd07.prod.outlook.com; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CB931A055594EF4C84F5B5A20E2561A7@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 20:28:12 -0000

Hi,
I read through the diff file.  The main change seems to be to reduce the
PartitionID field by one bit, which is now reserved.  This is fine.
While reading through the diff file (without checking against the main
text--too lazy or too busy, take your choice :-), I noticed that max_fr
and max_fs are optional, and could not see a default being defined.  Is
this prudent?  How does a decoding system decide whether it is able to
decode a stream without any indication of the complexity of the stream?
Start decoding and reject once the header tells you that this stream is
beyond your capacity?
Stephan
 =20

On 7.10.2013 08:50 , "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Audio/Video Transport Payloads Working
>Group of the IETF.
>
>	Title           : RTP Payload Format for VP8 Video
>	Author(s)       : Patrik Westin
>                          Henrik F Lundin
>                          Michael Glover
>                          Justin Uberti
>                          Frank Galligan
>	Filename        : draft-ietf-payload-vp8-09.txt
>	Pages           : 30
>	Date            : 2013-07-10
>
>Abstract:
>   This memo describes an RTP payload format for the VP8 video codec.
>   The payload format has wide applicability, as it supports
>   applications from low bit-rate peer-to-peer usage, to high bit-rate
>   video conferences.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-payload-vp8
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-payload-vp8-09
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-09
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload


From ron.even.tlv@gmail.com  Tue Jul 16 00:15:09 2013
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00B121E81AB for <payload@ietfa.amsl.com>; Tue, 16 Jul 2013 00:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level: 
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.514,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UkyP4jsr6Ve for <payload@ietfa.amsl.com>; Tue, 16 Jul 2013 00:15:08 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0121E81AD for <payload@ietf.org>; Tue, 16 Jul 2013 00:15:08 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id w56so264906wes.39 for <payload@ietf.org>; Tue, 16 Jul 2013 00:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=om58VcgQLdJYDgpdsw9m2/Vt8OKrAgsStQmQdk7PsCw=; b=r3tCl26uW3TPQ/9A0AtBK4uCCceQ1sDflEURcEJeo5PKLlbyI2pdARQMAEzCFEXswe QZRHBru62W/kGDnjeoZ+Avv0Gmtkz1VD9FLumTtzyARxJAxVyWD4l9You+GUtgwpa3h0 qfS+SyF5pg6HYyp43DwqqEcNWi2JYxHs42QjK4XHSqTU2fKDl1A9EN2+1MzgF3xMlWl5 EPEjzAvzD74CrZL/XF/ruAoV2tv0yWOVQXXVoHiotgmQ+to0wXBDC75+QwmcpPYfT3Fj VrWi7mxjIB3xXFAnJpMHhP3zd8+m+XHToQTNIbRB2XVNxnNViMOG7KgBWOUBJ+HxnKnq P69Q==
X-Received: by 10.180.9.212 with SMTP id c20mr11201749wib.65.1373958907413; Tue, 16 Jul 2013 00:15:07 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id o10sm282622wiz.5.2013.07.16.00.15.05 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Jul 2013 00:15:06 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: <payload@ietf.org>
Date: Tue, 16 Jul 2013 10:13:18 +0300
Message-ID: <000a01ce81f3$f3e61020$dbb23060$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CE820D.19343280"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac6B8vJzCBaBnd+wRcqvB/Q9vbGEfA==
Content-Language: en-us
Cc: "Christian Hoene \(Symonics\)" <christian.hoene@symonics.com>
Subject: [payload] review of http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-05
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 07:15:09 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000B_01CE820D.19343280
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I read the document and have some questions and comments

 

1.       The reference to A2DPV12 is normative but does not point to a
specific document. Can you provide a link to the specification.

2.       The join and RFC frame header field are mentioned but not explained
in section 3.2

3.       The "Capabilities" is an optional parameter. What is the default
values if not specified. Maybe it should be a required parameter.

4.       In section 7.2.1 do you mean that the "capabilities" parameters is
symmetric, the send and receive MUST be the same? Please calrify

Thanks

Roni Even as individual

 

 


------=_NextPart_000_000B_01CE820D.19343280
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1820229202;
	mso-list-type:hybrid;
	mso-list-template-ids:1250089766 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoNormal>Hi,<o:p></o:p></p><p class=3DMsoNormal>I read the =
document and have some questions and comments<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'color:black'><span =
style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span>The reference to =
<a name=3Dref-A2DPV12><span =
style=3D'color:black'>A2DPV12</span></a><span style=3D'color:black'> is =
normative but does not point to a specific document. Can you provide a =
link to the specification.<o:p></o:p></span></p><p =
class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'color:black'><span =
style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span>The join and RFC =
frame header field are mentioned but not explained in section 3.2<span =
style=3D'color:black'><o:p></o:p></span></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'color:black'><span =
style=3D'mso-list:Ignore'>3.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span>The =
&#8220;Capabilities&#8221; is an optional parameter. What is the default =
values if not specified. Maybe it should be a required parameter.<span =
style=3D'color:black'><o:p></o:p></span></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span style=3D'color:black'><span =
style=3D'mso-list:Ignore'>4.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></span></span><![endif]><span dir=3DLTR></span>In section 7.2.1 =
do you mean that the &#8220;capabilities&#8221; parameters is symmetric, =
the send and receive MUST be the same? Please calrify<span =
style=3D'color:black'><o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'page-break-before:always'><span =
style=3D'color:black'>Thanks<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'page-break-before:always'><span style=3D'color:black'>Roni Even =
as individual<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'page-break-before:always'><span =
style=3D'color:black'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_000B_01CE820D.19343280--


From wuym2000cn@gmail.com  Tue Jul 16 19:31:29 2013
Return-Path: <wuym2000cn@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D521F9C32 for <payload@ietfa.amsl.com>; Tue, 16 Jul 2013 19:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXBvzzQandCb for <payload@ietfa.amsl.com>; Tue, 16 Jul 2013 19:31:27 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B69CF21F9A8E for <payload@ietf.org>; Tue, 16 Jul 2013 19:31:27 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id s9so3055888iec.41 for <payload@ietf.org>; Tue, 16 Jul 2013 19:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=80tuu7bnNhtwkGa63gdComdRDhkX6DHwR9V/i03Tec4=; b=jRenN+QRrzPtA/I8TJOSxahSGxSVsY66AvuGtz2b5jNyRTxJKAafybxY+8TYF5PGNa PzALuxEOq2n1/tk4JW5ppEP4tgRDdBmBjZWlUdc1wNrAyLBxJKX3vjOzZXKXb+KBjva4 x8bYaq57PadQnpo7U9UY4VyHlH47Fjvw1UYrexT2FLXj8d2CfT0ZezcxGtszRZf42Fxj PD5ZnwrcS53jmbjler7Fbac+4EgMkkMMkQFub/9iudL8ucwp18zDL9ezexS19HqgDbtB U0xmPjpmSY7IHDEBp3E06AdDdjgGcuTL1Q0XrNWRE+SNixc6u4Qsgnt2eFm2a4/plE/s VzMg==
MIME-Version: 1.0
X-Received: by 10.43.164.129 with SMTP id ms1mr3816882icc.74.1374028286304; Tue, 16 Jul 2013 19:31:26 -0700 (PDT)
Received: by 10.42.68.143 with HTTP; Tue, 16 Jul 2013 19:31:26 -0700 (PDT)
Date: Wed, 17 Jul 2013 10:31:26 +0800
Message-ID: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.com>
From: Woo Johnman <wuym2000cn@gmail.com>
To: payload@ietf.org
Content-Type: multipart/alternative; boundary=001a11c2fb76eaa6b904e1abe321
Subject: [payload] some comments about H.265 payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 02:31:29 -0000

--001a11c2fb76eaa6b904e1abe321
Content-Type: text/plain; charset=ISO-8859-1

Hi,
ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?
In section which discuss depack-buf-cap,depack-buf-req is referred but not
defined.
At table 1,the last column has all 'P',I think
some parameters should be 'C'.If so it look more consistent.

Regards,

Woo.

--001a11c2fb76eaa6b904e1abe321
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br>ln section 7.2.1 there is an SDP example.Is profile-id &#39;ST&#39; =
valid?<br>In section which discuss depack-buf-cap,depack-buf-req is referre=
d but not defined.<br>At table 1,the last column has all &#39;P&#39;,I thin=
k<br>
some parameters should be &#39;C&#39;.If so it look more consistent.<br><br=
>Regards,<br><br>Woo. =A0

--001a11c2fb76eaa6b904e1abe321--

From harald@alvestrand.no  Wed Jul 17 07:06:28 2013
Return-Path: <harald@alvestrand.no>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA47021E804E for <payload@ietfa.amsl.com>; Wed, 17 Jul 2013 07:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYUnZVlSVksB for <payload@ietfa.amsl.com>; Wed, 17 Jul 2013 07:06:24 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83221E805F for <payload@ietf.org>; Wed, 17 Jul 2013 07:06:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1C3039E1BB for <payload@ietf.org>; Wed, 17 Jul 2013 16:06:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPej-zpYOC7z for <payload@ietf.org>; Wed, 17 Jul 2013 16:06:17 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A211F39E176 for <payload@ietf.org>; Wed, 17 Jul 2013 16:06:17 +0200 (CEST)
Message-ID: <51E6A4D9.30003@alvestrand.no>
Date: Wed, 17 Jul 2013 16:06:17 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: payload@ietf.org
References: <CE0310FB.9F149%stewe@stewe.org>
In-Reply-To: <CE0310FB.9F149%stewe@stewe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 14:06:29 -0000

On 07/10/2013 10:28 PM, Stephan Wenger wrote:
> Hi,
> I read through the diff file.  The main change seems to be to reduce the
> PartitionID field by one bit, which is now reserved.  This is fine.
> While reading through the diff file (without checking against the main
> text--too lazy or too busy, take your choice :-), I noticed that max_fr
> and max_fs are optional, and could not see a default being defined.
The theory is that there would be external constraints (such as an 
application-wide configuration, or an out-of-SDP signalling mechanism) 
that gave the constraints in question.

Quote from 6.2.2:

    In many practical applications, the max frame size and
    max frame rate are known from other information; if they are not
    constrained by other means, the max-fs and max-fr parameters MUST be
    used to establish these limits.

We did not see a compelling reason to make non-compliant the present 
applications that do not use these parameters.



>    Is
> this prudent?  How does a decoding system decide whether it is able to
> decode a stream without any indication of the complexity of the stream?
> Start decoding and reject once the header tells you that this stream is
> beyond your capacity?
> Stephan
>    
>
> On 7.10.2013 08:50 , "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Payloads Working
>> Group of the IETF.
>>
>> 	Title           : RTP Payload Format for VP8 Video
>> 	Author(s)       : Patrik Westin
>>                           Henrik F Lundin
>>                           Michael Glover
>>                           Justin Uberti
>>                           Frank Galligan
>> 	Filename        : draft-ietf-payload-vp8-09.txt
>> 	Pages           : 30
>> 	Date            : 2013-07-10
>>
>> Abstract:
>>    This memo describes an RTP payload format for the VP8 video codec.
>>    The payload format has wide applicability, as it supports
>>    applications from low bit-rate peer-to-peer usage, to high bit-rate
>>    video conferences.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-09
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From ron.even.tlv@gmail.com  Thu Jul 18 06:54:43 2013
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1911E8146; Thu, 18 Jul 2013 06:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcxrea7hAxys; Thu, 18 Jul 2013 06:54:43 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1EB11E814B; Thu, 18 Jul 2013 06:54:39 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id m6so6674771wiv.2 for <multiple recipients>; Thu, 18 Jul 2013 06:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=BmMv3sJHFEtC2IOe/mUJ3EBblimAT9bdF+9iFwZNyEM=; b=kdjeolUmlW6fZPvPtjBKyHUG7izArn0qdBtLdazbFW/w7edNwdXz5x6MGG2jR/Ybtb XK1PcXTvpvCSwyLHJHi6SSnjeU1ftrQ00pLNeciMonG2ZwmScvqOGG/CeSo8DD4HvpXo iubVlikgW6mQNmKBGRsCLrX09T9w1DIU1jHgRl3gh3/I78CORw93Na2tCxOmr1Y2VpY5 cqLJ+CI+vG9a0KxgTHH4+u6JvFlh5TUjNViSTFFXbdf2NFCn22xKGLe4WgPhDxigTZHs Vse+77/6wq6lT471bujQsSx15pMPByctcrNXilq/pzIQhbW6QZW++CITF5jctUdkojM/ HfVw==
X-Received: by 10.180.36.107 with SMTP id p11mr8279985wij.31.1374155678309; Thu, 18 Jul 2013 06:54:38 -0700 (PDT)
Received: from RoniE ([109.67.165.48]) by mx.google.com with ESMTPSA id fs8sm42137895wib.0.2013.07.18.06.54.36 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Jul 2013 06:54:37 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: <avt@ietf.org>
Date: Thu, 18 Jul 2013 16:52:49 +0300
Message-ID: <02cc01ce83be$18770040$496500c0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_02CD_01CE83D7.3DC48660"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac6DvcjZVgjnzbluS1OU6/8RBOibkg==
Content-Language: en-us
Cc: payload@ietf.org
Subject: [payload] IETF87 Berin agenda - AVTcore
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 13:54:43 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02CD_01CE83D7.3DC48660
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_02CE_01CE83D7.3DC48660"


------=_NextPart_001_02CE_01CE83D7.3DC48660
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

Attached is the agenda (txt and HTML version), note that we have allocated
time for h.265 payload specification which is a payload WG document

Roni


------=_NextPart_001_02CE_01CE83D7.3DC48660
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoNormal>Hi,<o:p></o:p></p><p class=3DMsoNormal>Attached is the =
agenda (txt and HTML version), note that we have allocated time for =
h.265 payload specification which is a payload WG =
document<o:p></o:p></p><p =
class=3DMsoNormal>Roni<o:p></o:p></p></div></body></html>
------=_NextPart_001_02CE_01CE83D7.3DC48660--

------=_NextPart_000_02CD_01CE83D7.3DC48660
Content-Type: text/plain;
	name="a13072.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="a13072.txt"

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

CHAIRS:  Magnus Westerlund       <magnus.westerlund@ericsson.com>
         Roni Even         <roni.even@mail01.huawei.com>

AGENDA

Wednesday, 31 July 2013 at 9:00-11:30 (Bellevue        )
--------------------------------------------------------
09:00   AVTCore Status Update                               (Chairs, 20)

09:20   Multiplex guidelines                        (Colin Perkins , 10)
        draft-ietf-avtcore-multiplex-guidelines-01

09:30   Support of mutiple RTP streams            (Jonathan Lennox , 25)
        draft-ietf-avtcore-multi-media-rtp-session-03
        draft-ietf-avtcore-rtp-multi-stream-01
        draft-ietf-avtcore-rtp-multi-stream-optimisation-00

09:55   Circuit Breakers for Unicast Sessions       (Colin Perkins , 25)
        draft-ietf-avtcore-rtp-circuit-breakers-03

10:20   RTP Clock Source Signalling                 (Aidan Williams, 15)
        draft-ietf-avtcore-clksrc-05

10:35   RTP Payload Format for High Efficiency Video Coding(Ye-kui Wang, 15)

10:50   End

------=_NextPart_000_02CD_01CE83D7.3DC48660
Content-Type: text/html;
	name="agenda.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="agenda.html"

<html>
<head>
<title>Audio/Video Transport Core Maintenance  (AVTCore) Working Group =
Agenda</title>
</head>
<body bgcolor=3D"#ffffff"><h1>Audio/Video Transport Core Maintenance  =
(AVTCore) Working Group Agenda</h1>
<hr>
<p>
<h3>
Chairs: Magnus Westerlund       <magnus.westerlund@ericsson.com>, Roni =
Even         <roni.even@mail01.huawei.com>
</h3>
<p>
<h2>Wednesday, 31 July 2013 at 9:00-11:30 (Bellevue        )</h2>
<p>
<table border=3D"0" cellpadding=3D"5">
<tr>
<th align=3D"left">09:00
<th align=3D"left">AVTCore Status Update<th align=3D"left">Chairs
<tr>
<th align=3D"left">09:20
<th align=3D"left">Multiplex guidelines<th align=3D"left">Colin Perkins=20
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-multiplex-guidelines-=
01">draft-ietf-avtcore-multiplex-guidelines-01</a>
<tr>
<th align=3D"left">09:30
<th align=3D"left">Support of mutiple RTP streams<th =
align=3D"left">Jonathan Lennox=20
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-multi-media-rtp-sessi=
on-03">draft-ietf-avtcore-multi-media-rtp-session-03</a>
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-rtp-multi-stream-01">=
draft-ietf-avtcore-rtp-multi-stream-01</a>
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-rtp-multi-stream-opti=
misation-00">draft-ietf-avtcore-rtp-multi-stream-optimisation-00</a>
<tr>
<th align=3D"left">09:55
<th align=3D"left">Circuit Breakers for Unicast Sessions<th =
align=3D"left">Colin Perkins=20
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-rtp-circuit-breakers-=
03">draft-ietf-avtcore-rtp-circuit-breakers-03</a>
<tr>
<th align=3D"left">10:20
<th align=3D"left">RTP Clock Source Signalling<th align=3D"left">Aidan =
Williams
<tr>
<td align=3D"left">
<td align=3D"left"><a =
href=3D"http://tools.ietf.org/id/draft-ietf-avtcore-clksrc-05">draft-ietf=
-avtcore-clksrc-05</a>
<tr>
<th align=3D"left">10:35
<th align=3D"left">RTP Payload Format for High Efficiency Video =
Coding<th align=3D"left">Ye-kui Wang
<tr>
<th align=3D"left">10:50
<th align=3D"left">End</table>

------=_NextPart_000_02CD_01CE83D7.3DC48660--


From yekuiw@qti.qualcomm.com  Thu Jul 18 09:17:25 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F411E8147 for <payload@ietfa.amsl.com>; Thu, 18 Jul 2013 09:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqlk2qftJSWv for <payload@ietfa.amsl.com>; Thu, 18 Jul 2013 09:17:22 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id D703311E80FC for <payload@ietf.org>; Thu, 18 Jul 2013 09:17:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374164241; x=1405700241; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7B1dIY3tAwkVMPMx/sy5lFwq6Zbqjb+g8TuRR1V47vI=; b=ZenMXinda0grur9ZJlY+nv8RIkwItbtTbPmm3jtlz3gtZEXI4botwiMx LJ6Uk6pl2/gFo1PZE9Z3RIyRUXlDQ+JSaqJLMGhfIj1OjCMscPa4Sq/Br L/hH6wfXuxwzmygK6NZOCohfi2XOHcd57TldeL0rnm7Vee9PFZO0NROxS I=;
X-IronPort-AV: E=Sophos;i="4.89,694,1367996400"; d="scan'208,217";a="47750818"
Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 18 Jul 2013 09:17:21 -0700
Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:17:20 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 09:17:20 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Woo Johnman <wuym2000cn@gmail.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] some comments about H.265 payload format
Thread-Index: AQHOgpXBc3yzhx0mBUGdlZ5psA/3TplqniXg
Date: Thu, 18 Jul 2013 16:17:19 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com>
References: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.com>
In-Reply-To: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.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: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E22nasanexd02fnaqu_"
MIME-Version: 1.0
Subject: Re: [payload] some comments about H.265 payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 16:17:26 -0000

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E22nasanexd02fnaqu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for the comments. See inline below.

BR, YK

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Woo Johnman
Sent: Tuesday, July 16, 2013 7:31 PM
To: payload@ietf.org
Subject: [payload] some comments about H.265 payload format

Hi,
ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?
[YK] Hmm, this example should come from Yago (the second author). Yago?

In section which discuss depack-buf-cap,depack-buf-req is referred but not =
defined.
[YK] Thanks. I corrected it in the next version I am preparing.

At table 1,the last column has all 'P',I think
some parameters should be 'C'.If so it look more consistent.
[YK] Why? The last column is for sendonly, thus P (properties of the stream=
 to be sent) is correct, not C (configuration for sending and receiving str=
eams). No?


Regards,

Woo.

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E22nasanexd02fnaqu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks for the comments. =
See inline below.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">BR, YK<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> payload-bounces@ietf.org [mailto:payload-bounces@ietf=
.org]
<b>On Behalf Of </b>Woo Johnman<br>
<b>Sent:</b> Tuesday, July 16, 2013 7:31 PM<br>
<b>To:</b> payload@ietf.org<br>
<b>Subject:</b> [payload] some comments about H.265 payload format<o:p></o:=
p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi,<br>
ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?<span sty=
le=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK] Hmm, this exam=
ple should come from Yago (the second author). Yago?<o:p></o:p></span></i><=
/b></p>
<p class=3D"MsoNormal"><br>
In section which discuss depack-buf-cap,depack-buf-req is referred but not =
defined.<span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK] Thanks. I corr=
ected it in the next version I am preparing.<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><br>
At table 1,the last column has all 'P',I think<br>
some parameters should be 'C'.If so it look more consistent.<span style=3D"=
color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK] Why? The last =
column is for sendonly, thus P (properties of the stream to be sent) is cor=
rect, not C (configuration for sending and receiving streams).
 No?<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><br>
<br>
Regards,<br>
<br>
Woo. &nbsp; <o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E22nasanexd02fnaqu_--

From yekuiw@qti.qualcomm.com  Thu Jul 18 09:37:35 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AFD11E8194 for <payload@ietfa.amsl.com>; Thu, 18 Jul 2013 09:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YupZfEbyKb24 for <payload@ietfa.amsl.com>; Thu, 18 Jul 2013 09:37:31 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20011E8147 for <payload@ietf.org>; Thu, 18 Jul 2013 09:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374165451; x=1405701451; h=from:to:cc:subject:date:message-id:mime-version; bh=ZOZvS6oM60IJHQzP23nNERQsKcc/wv+HawnafXBpsXU=; b=cxN8QTBCF8McB7WEBfbA/yRGEd+P8GXY1n/ldq7ezHYsjYJP7temrNbG nBYCCawgXjHl6CEDyoYCaeeMaNfS4LqrRL1dbAQvq4rDLOdnoSBjlrkiO xIy+SLhFNhCdQNpN2JviX3BJgz+kKlFWQLOicM2qCD/fYCezu85IKoZuO I=;
X-IronPort-AV: E=Sophos;i="4.89,695,1367996400"; d="scan'208,217";a="47752065"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 18 Jul 2013 09:37:30 -0700
Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Jul 2013 09:37:30 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 09:37:30 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Lunch gathering for H.265/HEVC payload format on 7/31
Thread-Index: Ac6D07YB6IpRswL7TiKaS4ji5p11iQ==
Date: Thu, 18 Jul 2013 16:37:29 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338496E78@nasanexd02f.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.39.5]
Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E78nasanexd02fnaqu_"
MIME-Version: 1.0
Subject: [payload] Lunch gathering for H.265/HEVC payload format on 7/31
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 16:37:35 -0000

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E78nasanexd02fnaqu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear All,

Due to that we must be attending the MPEG meeting during the same week in V=
ienna, thus we cannot spend too much time in Berlin, Stephan and I plan to =
organize an unofficial gathering among interested parties during 7/31 Wedne=
sday lunch for some discussions on H.265/HEVC payload format (for whatever =
questions, comments, concerns people may have, in order to be able to meet =
the WG milestone for this work). It would be soon after the avtcore session=
, during which we would have a presentation on this payload format.

To those who would like to attend, could you please RSVP so that we can res=
erve a nearby place for the gathering in time? To avoid spamming others, pl=
ease RSVP to Stephan and me. Thanks!

BR, YK


--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E78nasanexd02fnaqu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dear All,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Due to that we must be at=
tending the MPEG meeting during the same week in Vienna, thus we cannot spe=
nd too much time in Berlin, Stephan and I plan to organize
 an unofficial gathering </span><span style=3D"font-size:11.0pt;font-family=
:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">among interested=
 parties during 7/31 Wednesday lunch for some discussions on H.265/HEVC pay=
load format (for whatever questions, comments, concerns
 people may have, in order to be able to meet the WG milestone for this wor=
k). It would be soon after the avtcore session, during which we would have =
a presentation on this payload format.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">To those who would like t=
o attend, could you please RSVP</span>
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">so that we can reserve a nearby place for the ga=
thering in time? To avoid spamming others, please RSVP to Stephan and me. T=
hanks!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">BR, YK</span><o:p></o:p><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
</div>
</body>
</html>

--_000_8BA7D4CEACFFE04BA2D902BF11719A8338496E78nasanexd02fnaqu_--

From yago.sanchez@hhi.fraunhofer.de  Fri Jul 19 03:18:36 2013
Return-Path: <yago.sanchez@hhi.fraunhofer.de>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B52421F9C12 for <payload@ietfa.amsl.com>; Fri, 19 Jul 2013 03:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+pMtTdxN2Lh for <payload@ietfa.amsl.com>; Fri, 19 Jul 2013 03:18:32 -0700 (PDT)
Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id B775F21F9E39 for <payload@ietf.org>; Fri, 19 Jul 2013 03:18:31 -0700 (PDT)
X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0
Received: from [130.149.228.88] (ysanchez-pc.ic.tu-berlin.de [130.149.228.88]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id 487221C90022 for <payload@ietf.org>; Fri, 19 Jul 2013 12:18:27 +0200 (CEST)
Message-ID: <51E91272.7010206@hhi.fraunhofer.de>
Date: Fri, 19 Jul 2013 12:18:26 +0200
From: Yago Sanchez <yago.sanchez@hhi.fraunhofer.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: payload@ietf.org
References: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com>
Content-Type: multipart/alternative; boundary="------------060607000703020807070503"
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-7.0.0.1014-20024.006
X-TM-AS-Result: No--33.106-11.0-31-10
X-imss-scan-details: No--33.106-11.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TMASE-MatchedRID: EMyCvCfVN1GoB6BkKpx1kbxygpRxo469tvjn5WNmIymwpePL/m7bm2zS Uc9/JDIkhRRldM2EkSLA3E/7HJRrJ/nVY0DWsTq3y7TSWcbz49ZAq6/y5AEOOqPMuQsqVNXhWLt 167EoD8yLB6kB2sP0O2GArav7zDJnuN0AXBH/oPGm/Bn0aZ3AM4UpeygF2mvC5DJ1FS+XdBNIBU 76nhg21p7+4Fgc4YB4B1vg3gDcqQJhaj10i6TXQEK9qlwiTElfdZPoD9V2prQHiwiF9OOogUqyU ztVRoTBdvgGbsWpCcsPg1TZ1+mCN0Xs1WbxNtVLyDp+jSvEtWsl3afZehJEWedlU2K5Jm9blhlc mWETTroEdWbTGHnxVjwu4/5s6Qxa3eMXZ9Vw93MMH4SsGvRsA1qvZZ9/gpIhZ5yuplze9ps57kF jOTI5JYBMc1fifV0YUanNe82h3Oc1gbUlmfmxOnpruoeiWYa5tPGelsKOu4gVGU3zNNLOPv5DCQ Vs54vCzh9/JTWzqExcSNmWV/ZuF99faxl/I4mhFEUknJ/kEl6V8bCk1I9Wfr6qvLNjDYTw5AP+y qovSZne3/9uSSiAviAHAopEd76v/AzOx3L7thgXxESUInRjkrTWVQq2QFocp96THsTo9FbjaRfI Di7UwA==
X-IMSS-DKIM-White-List: No
X-alterMIME: Yes
Subject: Re: [payload] some comments about H.265 payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 10:18:36 -0000

This is a multi-part message in MIME format.
--------------060607000703020807070503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Ye-Kui, all,
please see inline.

Best regards,
Yago

Am 18.07.2013 18:17, schrieb Wang, Ye-Kui:
>
> Thanks for the comments. See inline below.
>
> BR, YK
>
> *From:*payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On 
> Behalf Of *Woo Johnman
> *Sent:* Tuesday, July 16, 2013 7:31 PM
> *To:* payload@ietf.org
> *Subject:* [payload] some comments about H.265 payload format
>
> Hi,
> ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?
>
> */[YK] Hmm, this example should come from Yago (the second author). 
> Yago?/*
>
>

[YS] 'ST' is not correct. It was simply a placeholder it has being kept 
there. We should update it to idicate e.g. the Main 10 profile 
substituting 'ST' by '02'.

> In section which discuss depack-buf-cap,depack-buf-req is referred but 
> not defined.
>
> */[YK] Thanks. I corrected it in the next version I am preparing./*
>
>
> At table 1,the last column has all 'P',I think
> some parameters should be 'C'.If so it look more consistent.
>
> */[YK] Why? The last column is for sendonly, thus P (properties of the 
> stream to be sent) is correct, not C (configuration for sending and 
> receiving streams). No?/*
>
>
[YS]  I agree with Ye-Kui. Since it is sendonly 'P' is correct.

>
> Regards,
>
> Woo.
>
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


--------------060607000703020807070503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dear Ye-Kui, all,<br>
      please see inline.<br>
      <br>
      Best regards,<br>
      Yago<br>
      <br>
      Am 18.07.2013 18:17, schrieb Wang, Ye-Kui:<br>
    </div>
    <blockquote
cite="mid:8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks
            for the comments. See inline below.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">BR,
            YK<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"
                    lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"
                  lang="EN-US"> <a class="moz-txt-link-abbreviated" href="mailto:payload-bounces@ietf.org">payload-bounces@ietf.org</a>
                  [<a class="moz-txt-link-freetext" href="mailto:payload-bounces@ietf.org">mailto:payload-bounces@ietf.org</a>]
                  <b>On Behalf Of </b>Woo Johnman<br>
                  <b>Sent:</b> Tuesday, July 16, 2013 7:31 PM<br>
                  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:payload@ietf.org">payload@ietf.org</a><br>
                  <b>Subject:</b> [payload] some comments about H.265
                  payload format<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">Hi,<br>
            ln section 7.2.1 there is an SDP example.Is profile-id 'ST'
            valid?<span style="color:#1F497D"><o:p></o:p></span></p>
          <p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK]
                  Hmm, this example should come from Yago (the second
                  author). Yago?<o:p></o:p></span></i></b></p>
          <p class="MsoNormal"><br>
          </p>
        </div>
      </div>
    </blockquote>
    <br>
    [YS] 'ST' is not correct. It was simply a placeholder it has being
    kept there. We should update it to idicate e.g. the Main 10 profile
    substituting 'ST' by '02'. <br>
    <br>
    <blockquote
cite="mid:8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com"
      type="cite">
      <div class="WordSection1">
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <p class="MsoNormal">
            In section which discuss depack-buf-cap,depack-buf-req is
            referred but not defined.<span style="color:#1F497D"><o:p></o:p></span></p>
          <p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK]
                  Thanks. I corrected it in the next version I am
                  preparing.<o:p></o:p></span></i></b></p>
          <p class="MsoNormal"><br>
            At table 1,the last column has all 'P',I think<br>
            some parameters should be 'C'.If so it look more consistent.<span
              style="color:#1F497D"><o:p></o:p></span></p>
          <p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[YK]
                  Why? The last column is for sendonly, thus P
                  (properties of the stream to be sent) is correct, not
                  C (configuration for sending and receiving streams).
                  No?<o:p></o:p></span></i></b></p>
          <p class="MsoNormal"><br>
          </p>
        </div>
      </div>
    </blockquote>
    [YS]&nbsp; I agree with Ye-Kui. Since it is sendonly 'P' is correct.<br>
    <br>
    <blockquote
cite="mid:8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com"
      type="cite">
      <div class="WordSection1">
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <p class="MsoNormal">
            <br>
            Regards,<br>
            <br>
            Woo. &nbsp; <o:p></o:p></p>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
payload mailing list
<a class="moz-txt-link-abbreviated" href="mailto:payload@ietf.org">payload@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/payload">https://www.ietf.org/mailman/listinfo/payload</a>
</pre>
    </blockquote>
    <br>
  
<br>
<br>
</body>
</html>

--------------060607000703020807070503--


From fluffy@iii.ca  Fri Jul 19 17:12:28 2013
Return-Path: <fluffy@iii.ca>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC021E80C6; Fri, 19 Jul 2013 17:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.467,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcAz74yMz2EM; Fri, 19 Jul 2013 17:12:23 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49321E8056; Fri, 19 Jul 2013 17:12:22 -0700 (PDT)
Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 62B2822E1F3; Fri, 19 Jul 2013 20:12:16 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51E6A4D9.30003@alvestrand.no>
Date: Fri, 19 Jul 2013 13:17:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca>
References: <CE0310FB.9F149%stewe@stewe.org> <51E6A4D9.30003@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1508)
Cc: The IESG <iesg@ietf.org>, payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 00:12:28 -0000

These can't be optional otherwise a device that is hardware limited =
can't know that the other side will use them. Thus there is no way to =
build solutions that interoperate by design instead of luck.=20
=20


On Jul 17, 2013, at 7:06 AM, Harald Alvestrand <harald@alvestrand.no> =
wrote:

> On 07/10/2013 10:28 PM, Stephan Wenger wrote:
>> Hi,
>> I read through the diff file.  The main change seems to be to reduce =
the
>> PartitionID field by one bit, which is now reserved.  This is fine.
>> While reading through the diff file (without checking against the =
main
>> text--too lazy or too busy, take your choice :-), I noticed that =
max_fr
>> and max_fs are optional, and could not see a default being defined.
> The theory is that there would be external constraints (such as an =
application-wide configuration, or an out-of-SDP signalling mechanism) =
that gave the constraints in question.
>=20
> Quote from 6.2.2:
>=20
>  In many practical applications, the max frame size and
>  max frame rate are known from other information; if they are not
>  constrained by other means, the max-fs and max-fr parameters MUST be
>  used to establish these limits.
>=20
> We did not see a compelling reason to make non-compliant the present =
applications that do not use these parameters.
>=20
>=20
>=20
>>  Is
>> this prudent?  How does a decoding system decide whether it is able =
to
>> decode a stream without any indication of the complexity of the =
stream?
>> Start decoding and reject once the header tells you that this stream =
is
>> beyond your capacity?
>> Stephan
>>=20
>> On 7.10.2013 08:50 , "internet-drafts@ietf.org" =
<internet-drafts@ietf.org>
>> wrote:
>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Audio/Video Transport Payloads =
Working
>>> Group of the IETF.
>>>=20
>>> 	Title           : RTP Payload Format for VP8 Video
>>> 	Author(s)       : Patrik Westin
>>>                         Henrik F Lundin
>>>                         Michael Glover
>>>                         Justin Uberti
>>>                         Frank Galligan
>>> 	Filename        : draft-ietf-payload-vp8-09.txt
>>> 	Pages           : 30
>>> 	Date            : 2013-07-10
>>>=20
>>> Abstract:
>>>  This memo describes an RTP payload format for the VP8 video codec.
>>>  The payload format has wide applicability, as it supports
>>>  applications from low bit-rate peer-to-peer usage, to high bit-rate
>>>  video conferences.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-09
>>>=20
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From fluffy@cisco.com  Fri Jul 19 17:12:33 2013
Return-Path: <fluffy@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2A121E80D8; Fri, 19 Jul 2013 17:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.233
X-Spam-Level: 
X-Spam-Status: No, score=-110.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsZ+4KA8-CEO; Fri, 19 Jul 2013 17:12:28 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA3F21E8099; Fri, 19 Jul 2013 17:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3964; q=dns/txt; s=iport; t=1374279143; x=1375488743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A2v46ecp32uktyJKzIu4CBNuGbXDDprIfwZCh80Ap1g=; b=T6X6a788lzidBRyphR8YybCdOxeCVakGEz4Rjk7ELCb+GqGVMES1Az9y Y+FutvbYp8fJ8dZM6+KC9AnD7LgmWWHqmqGF2zqY2LxyzjkD+0XRZz0+H P7PD7lUAZAerrvDp8kP8k1KUmhxBuFCNdbdi3V0yuh7W4DlXXUDhu0d0v U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FAG7V6VGtJXG+/2dsb2JhbABagwY1UMBLgREWdIIkAQEBAwEBAQFlBgsQAgEIIhkLJwsUEQIEDgUIiAIGDLdIj1wCMQeDEG4DmQaQJIFZgTmCKg
X-IronPort-AV: E=Sophos;i="4.89,705,1367971200"; d="scan'208";a="234170650"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 20 Jul 2013 00:12:14 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6K0CDqQ028528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Jul 2013 00:12:13 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 19:12:12 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
Thread-Index: AQHOhN3IWUW5SiulikKclv0UR7hd+A==
Date: Sat, 20 Jul 2013 00:12:12 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB1135E7A62@xmb-aln-x02.cisco.com>
References: <20130604222555.32402.16024.idtracker@ietfa.amsl.com>
In-Reply-To: <20130604222555.32402.16024.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.91.75]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9E37F7028DA44C45A7B4D40F952DEBE8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 00:12:33 -0000

Resent on different list =85


I would like to raise an issue interoperability with this payload specifica=
tion that we are currently having with WebRTC implementations. In WebRTC, a=
nd many other places, you want SDP to be able to control the resolution of =
the image (or at least the outer limits of the resolution). Yes, I realize =
there are applications where you know the resolution vis a some out of band=
 mechanisms but O/A SDP is not one of the where this is guaranteed. We do n=
eed to specify how this works for use with O/A SDP.=20

Some implementations think that if you want the resolution to by 720 lines =
by 1280, you control the resolution of codec with a SDP line something like=
=20

 m=3Dvideo 62537 RTP/SAVPF 96  =20
 a=3Drtpmap:96 VP8/90000
 a=3Dssrc:5 imageattr:* [1280, 720]

Some other implementers think you control the resolution using RFC 6236 wit=
h something like=20

  m=3Dvideo 62537 RTP/SAVPF 96=20
  a=3Drtpmap:96 VP8/90000
  a=3Dimageattr:96 [x=3D1280,y=3D720]

There is one thing that as far as I can tell that all the implementors agre=
e on. None of the implications control the resolution using=20

  m=3Dvideo 62537 RTP/SAVPF 96=20
  a=3Drtpmap:96 VP8/90000
  a=3Dfmtp:96 max-fr=3D30;max-fs=3D3600

What resolution do you think "max-fs=3D3600" is? I have no idea. It is not =
possible to implement so it is not surprising no one is doing  it. However,=
 this draft-ietf-payload-vp8 draft says the resolution is specified using t=
he max-fs and max-fr.=20

I raised this in the WG and the WG came to consensus that current draft is =
fine. So I actually believe that current draft does represent IETF consensu=
s and that I was merely in the rough on that consensus. I had decided to ju=
st ignore it in LC because I was under the impressing that all the implemen=
tations would just ignore the RFC and do "a=3Dimageattr:96 [x=3D1280,y=3D72=
0]". However, when it came to my attention that many were doing  "a=3Dimage=
attr:96 [x=3D1280,y=3D720]" but some where doing the non interoperable "a=
=3Dssrc:5 imageattr:* [1280, 720]", I decided that this problem actually ne=
eded to be fixed.=20

I think this draft is broken and will create interoperability problems for =
years to come. I encourage the IESG to fix it. I don't care how it is resol=
ved, I care that there is a way to for O/A to sort out the resolution and s=
ince the approach used be SDP to do this is codec specific, it needs to be =
in this draft.=20

Cullen

On Jun 4, 2013, at 3:25 PM, The IESG <iesg-secretary@ietf.org> wrote:

>=20
> The IESG has received a request from the Audio/Video Transport Payloads
> WG (payload) to consider the following document:
> - 'RTP Payload Format for VP8 Video'
>  <draft-ietf-payload-vp8-08.txt> as Proposed Standard
>=20
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-06-18. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>=20
> Abstract
>=20
>=20
>   This memo describes an RTP payload format for the VP8 video codec.
>   The payload format has wide applicability, as it supports
>   applications from low bit-rate peer-to-peer usage, to high bit-rate
>   video conferences.
>=20
>=20
>=20
>=20
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/
>=20
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/
>=20
>=20
> The following IPR Declarations may be related to this I-D:
>=20
>   http://datatracker.ietf.org/ipr/1622/
>=20
>=20
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From wuym2000cn@gmail.com  Sat Jul 20 19:14:08 2013
Return-Path: <wuym2000cn@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9521F9A05 for <payload@ietfa.amsl.com>; Sat, 20 Jul 2013 19:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.074
X-Spam-Level: 
X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-2.525, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFlcE7R2+Ahw for <payload@ietfa.amsl.com>; Sat, 20 Jul 2013 19:14:07 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CDBF121F94DC for <payload@ietf.org>; Sat, 20 Jul 2013 19:14:06 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id w15so4132647iea.36 for <payload@ietf.org>; Sat, 20 Jul 2013 19:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8+LzS+SvkJt/1R/zny/1Gt/G3KIa+Px4DI1eIu+PPKA=; b=Kj3C4bneTVp5fQxQhXmbWKAU8lRrerXoCindjuWRA7H1Tno8dZ2VFfT54cL6FlFu4f GOBVA8iZollUX/HXIUNNQW8XWyqcudpYFpZTtEx1MKpnslEQKMwoJFnrhNfUQx7yL4JH pGfieJ1c32Xne0nLTVDsnbxoldIZFpQTVCxfvNPABZah7rKqaH2pzM/1B9ppcmvardBG bLmZB8Cg+4lhLD8RjtCWV0YtHEuAQong6JjmuaYXg3OUdB2mBXZMlOAZAPDqIUbQ6ovn JNkC63XNeLDgSTxGl2xyGBonggFj6V42TSi+nGzZPIRyMiGbygv/dSr+IkW4+kfYxsSv sBug==
MIME-Version: 1.0
X-Received: by 10.42.49.15 with SMTP id u15mr14538279icf.30.1374372846105; Sat, 20 Jul 2013 19:14:06 -0700 (PDT)
Received: by 10.42.68.143 with HTTP; Sat, 20 Jul 2013 19:14:05 -0700 (PDT)
In-Reply-To: <51E91272.7010206@hhi.fraunhofer.de>
References: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com> <51E91272.7010206@hhi.fraunhofer.de>
Date: Sun, 21 Jul 2013 10:14:05 +0800
Message-ID: <CAMxBvpDttKQp-v-ghqPXrH66euc1+iaDB7gO--_x3sttpXqMHA@mail.gmail.com>
From: Woo Johnman <wuym2000cn@gmail.com>
To: Yago Sanchez <yago.sanchez@hhi.fraunhofer.de>
Content-Type: multipart/alternative; boundary=90e6ba1efcb247fe4e04e1fc1d5a
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] some comments about H.265 payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2013 02:14:08 -0000

--90e6ba1efcb247fe4e04e1fc1d5a
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi,
I am not sure for question 3.
One peer offers a recvonly SDP, the other answers a sendonly SDP.
I wonder if it need two different meaning in this case.

=D4=DA 2013=C4=EA7=D4=C21=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACYago Sanchez <yago.s=
anchez@hhi.fraunhofer.de> =D0=B4=B5=C0=A3=BA
> Dear Ye-Kui, all,
> please see inline.
>
> Best regards,
> Yago
>
> Am 18.07.2013 18:17, schrieb Wang, Ye-Kui:
>
> Thanks for the comments. See inline below.
>
>
>
> BR, YK
>
>
>
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
Behalf Of Woo Johnman
> Sent: Tuesday, July 16, 2013 7:31 PM
> To: payload@ietf.org
> Subject: [payload] some comments about H.265 payload format
>
>
>
> Hi,
> ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?
>
> [YK] Hmm, this example should come from Yago (the second author). Yago?
>
> [YS] 'ST' is not correct. It was simply a placeholder it has being kept
there. We should update it to idicate e.g. the Main 10 profile substituting
'ST' by '02'.
>
> In section which discuss depack-buf-cap,depack-buf-req is referred but
not defined.
>
> [YK] Thanks. I corrected it in the next version I am preparing.
>
> At table 1,the last column has all 'P',I think
> some parameters should be 'C'.If so it look more consistent.
>
> [YK] Why? The last column is for sendonly, thus P (properties of the
stream to be sent) is correct, not C (configuration for sending and
receiving streams). No?
>
> [YS]  I agree with Ye-Kui. Since it is sendonly 'P' is correct.
>
>
> Regards,
>
> Woo.
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>
>
>
>

--90e6ba1efcb247fe4e04e1fc1d5a
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi,<br>I am not sure for question 3.<br>One peer offers a recvonly SDP, the=
 other answers a sendonly SDP.<br>I wonder if it need two different meaning=
 in this case.<br><br>=D4=DA 2013=C4=EA7=D4=C21=C8=D5=D0=C7=C6=DA=CE=E5=A3=
=ACYago Sanchez &lt;<a href=3D"mailto:yago.sanchez@hhi.fraunhofer.de">yago.=
sanchez@hhi.fraunhofer.de</a>&gt; =D0=B4=B5=C0=A3=BA<br>
&gt; Dear Ye-Kui, all,<br>&gt; please see inline.<br>&gt;<br>&gt; Best rega=
rds,<br>&gt; Yago<br>&gt;<br>&gt; Am 18.07.2013 18:17, schrieb Wang, Ye-Kui=
:<br>&gt;<br>&gt; Thanks for the comments. See inline below.<br>&gt;<br>
&gt; &nbsp;<br>&gt;<br>&gt; BR, YK<br>&gt;<br>&gt; &nbsp;<br>&gt;<br>&gt; F=
rom: <a href=3D"mailto:payload-bounces@ietf.org">payload-bounces@ietf.org</=
a> [mailto:<a href=3D"mailto:payload-bounces@ietf.org">payload-bounces@ietf=
.org</a>] On Behalf Of Woo Johnman<br>
&gt; Sent: Tuesday, July 16, 2013 7:31 PM<br>&gt; To: <a href=3D"mailto:pay=
load@ietf.org">payload@ietf.org</a><br>&gt; Subject: [payload] some comment=
s about H.265 payload format<br>&gt;<br>&gt; &nbsp;<br>&gt;<br>&gt; Hi,<br>=
&gt; ln section 7.2.1 there is an SDP example.Is profile-id &#39;ST&#39; va=
lid?<br>
&gt;<br>&gt; [YK] Hmm, this example should come from Yago (the second autho=
r). Yago?<br>&gt;<br>&gt; [YS] &#39;ST&#39; is not correct. It was simply a=
 placeholder it has being kept there. We should update it to idicate e.g. t=
he Main 10 profile substituting &#39;ST&#39; by &#39;02&#39;.<br>
&gt;<br>&gt; In section which discuss depack-buf-cap,depack-buf-req is refe=
rred but not defined.<br>&gt;<br>&gt; [YK] Thanks. I corrected it in the ne=
xt version I am preparing.<br>&gt;<br>&gt; At table 1,the last column has a=
ll &#39;P&#39;,I think<br>
&gt; some parameters should be &#39;C&#39;.If so it look more consistent.<b=
r>&gt;<br>&gt; [YK] Why? The last column is for sendonly, thus P (propertie=
s of the stream to be sent) is correct, not C (configuration for sending an=
d receiving streams). No?<br>
&gt;<br>&gt; [YS]&nbsp; I agree with Ye-Kui. Since it is sendonly &#39;P&#3=
9; is correct.<br>&gt;<br>&gt;<br>&gt; Regards,<br>&gt;<br>&gt; Woo. &nbsp;=
<br>&gt;<br>&gt; _______________________________________________<br>&gt; pa=
yload mailing list<br>
&gt; <a href=3D"mailto:payload@ietf.org">payload@ietf.org</a><br>&gt; <a hr=
ef=3D"https://www.ietf.org/mailman/listinfo/payload">https://www.ietf.org/m=
ailman/listinfo/payload</a><br>&gt;<br>&gt;<br>&gt;<br>&gt;

--90e6ba1efcb247fe4e04e1fc1d5a--

From yekuiw@qti.qualcomm.com  Sun Jul 21 12:55:26 2013
Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D226711E8105 for <payload@ietfa.amsl.com>; Sun, 21 Jul 2013 12:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.609
X-Spam-Level: 
X-Spam-Status: No, score=-103.609 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVK7v5cMsy32 for <payload@ietfa.amsl.com>; Sun, 21 Jul 2013 12:55:22 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5E89C11E8103 for <payload@ietf.org>; Sun, 21 Jul 2013 12:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374436522; x=1405972522; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MSE/lzUBn8m4PIU0JhlNwpvmwpOJpsRyQUD6jp/oE3A=; b=O6cMgjrSithmVIn2fCXwMKBtbsJCal9LB+vIH2qE/twdlPQedS4i6dKj wcTas4SelUpEirsbKfBlebkQZS9VW2wBb9a1Z8g8hDZEYacJCzJuHVmdb +bzKyBtiqK+BcTwu9aWjkhTg9fa15q4UFbzBk+7pbQ/eWtRlub/VkjHzy s=;
X-IronPort-AV: E=Sophos;i="4.89,714,1367996400"; d="scan'208,217";a="47934716"
Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 21 Jul 2013 12:55:20 -0700
X-IronPort-AV: E=Sophos;i="4.89,714,1367996400";  d="scan'208,217";a="571663053"
Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Jul 2013 12:55:20 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.02.0318.004; Sun, 21 Jul 2013 12:55:20 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Woo Johnman <wuym2000cn@gmail.com>, Yago Sanchez <yago.sanchez@hhi.fraunhofer.de>
Thread-Topic: [payload] some comments about H.265 payload format
Thread-Index: AQHOgpXBc3yzhx0mBUGdlZ5psA/3TplqniXggAGkpACAAp1XgIAAsgOw
Date: Sun, 21 Jul 2013 19:55:18 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833849B44F@nasanexd02f.na.qualcomm.com>
References: <CAMxBvpDAXNe+gDHgtpuKde3FsD49LKo+ppqndZG6_AXgx3CLtA@mail.gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A8338496E22@nasanexd02f.na.qualcomm.com> <51E91272.7010206@hhi.fraunhofer.de> <CAMxBvpDttKQp-v-ghqPXrH66euc1+iaDB7gO--_x3sttpXqMHA@mail.gmail.com>
In-Reply-To: <CAMxBvpDttKQp-v-ghqPXrH66euc1+iaDB7gO--_x3sttpXqMHA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.106.115.132]
Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A833849B44Fnasanexd02fnaqu_"
MIME-Version: 1.0
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] some comments about H.265 payload format
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2013 19:55:26 -0000

--_000_8BA7D4CEACFFE04BA2D902BF11719A833849B44Fnasanexd02fnaqu_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

If an offerer sends an SDP with sendonly (applies to the entire SDP), and t=
he answerer wants to establish a communication for sending-by-the-offerer-a=
nd-receiver-by-the-answerer, it must include an SDP with recvonly or sendre=
cv. If the answerer only includes an SDP with sendonly, there is no way for=
 them to establish any communication without further negotiation steps.

BR, YK

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf =
Of Woo Johnman
Sent: Saturday, July 20, 2013 7:14 PM
To: Yago Sanchez
Cc: payload@ietf.org
Subject: Re: [payload] some comments about H.265 payload format

Hi,
I am not sure for question 3.
One peer offers a recvonly SDP, the other answers a sendonly SDP.
I wonder if it need two different meaning in this case.

=1B$B:_=1B(B 2013=1B$BG/=1B(B7=1B$B7n=1B(B1=1B$BF|@14|8^!$=1B(BYago Sanchez=
 <yago.sanchez@hhi.fraunhofer.de<mailto:yago.sanchez@hhi.fraunhofer.de>> =
=1B$B<LF;!'=1B(B
> Dear Ye-Kui, all,
> please see inline.
>
> Best regards,
> Yago
>
> Am 18.07.2013 18:17, schrieb Wang, Ye-Kui:
>
> Thanks for the comments. See inline below.
>
>
>
> BR, YK
>
>
>
> From: payload-bounces@ietf.org<mailto:payload-bounces@ietf.org> [mailto:p=
ayload-bounces@ietf.org<mailto:payload-bounces@ietf.org>] On Behalf Of Woo =
Johnman
> Sent: Tuesday, July 16, 2013 7:31 PM
> To: payload@ietf.org<mailto:payload@ietf.org>
> Subject: [payload] some comments about H.265 payload format
>
>
>
> Hi,
> ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?
>
> [YK] Hmm, this example should come from Yago (the second author). Yago?
>
> [YS] 'ST' is not correct. It was simply a placeholder it has being kept t=
here. We should update it to idicate e.g. the Main 10 profile substituting =
'ST' by '02'.
>
> In section which discuss depack-buf-cap,depack-buf-req is referred but no=
t defined.
>
> [YK] Thanks. I corrected it in the next version I am preparing.
>
> At table 1,the last column has all 'P',I think
> some parameters should be 'C'.If so it look more consistent.
>
> [YK] Why? The last column is for sendonly, thus P (properties of the stre=
am to be sent) is correct, not C (configuration for sending and receiving s=
treams). No?
>
> [YS]  I agree with Ye-Kui. Since it is sendonly 'P' is correct.
>
>
> Regards,
>
> Woo.
>
> _______________________________________________
> payload mailing list
> payload@ietf.org<mailto:payload@ietf.org>
> https://www.ietf.org/mailman/listinfo/payload
>
>
>
>

--_000_8BA7D4CEACFFE04BA2D902BF11719A833849B44Fnasanexd02fnaqu_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-=
jp">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">If an offerer sends an SD=
P with sendonly (applies to the entire SDP), and the answerer wants to esta=
blish a communication for sending-by-the-offerer-and-receiver-by-the-answer=
er,
 it must include an SDP with recvonly or sendrecv. If the answerer only inc=
ludes an SDP with sendonly, there is no way for them to establish any commu=
nication without further negotiation steps.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">BR, YK<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> payload-bounces@ietf.org [mailto:payload-bounces@ietf=
.org]
<b>On Behalf Of </b>Woo Johnman<br>
<b>Sent:</b> Saturday, July 20, 2013 7:14 PM<br>
<b>To:</b> Yago Sanchez<br>
<b>Cc:</b> payload@ietf.org<br>
<b>Subject:</b> Re: [payload] some comments about H.265 payload format<o:p>=
</o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi,<br>
I am not sure for question 3.<br>
One peer offers a recvonly SDP, the other answers a sendonly SDP.<br>
I wonder if it need two different meaning in this case.<br>
<br>
<span lang=3D"ZH-CN">=1B$B:_=1B(B</span> 2013<span lang=3D"ZH-CN">=1B$BG/=
=1B(B</span>7<span lang=3D"ZH-CN">=1B$B7n=1B(B</span>1<span lang=3D"ZH-CN">=
=1B$BF|@14|8^!$=1B(B</span>Yago Sanchez &lt;<a href=3D"mailto:yago.sanchez@=
hhi.fraunhofer.de">yago.sanchez@hhi.fraunhofer.de</a>&gt;
<span lang=3D"ZH-CN">=1B$B<LF;!'=1B(B</span><br>
&gt; Dear Ye-Kui, all,<br>
&gt; please see inline.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Yago<br>
&gt;<br>
&gt; Am 18.07.2013 18:17, schrieb Wang, Ye-Kui:<br>
&gt;<br>
&gt; Thanks for the comments. See inline below.<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; BR, YK<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; From: <a href=3D"mailto:payload-bounces@ietf.org">payload-bounces@ietf=
.org</a> [mailto:<a href=3D"mailto:payload-bounces@ietf.org">payload-bounce=
s@ietf.org</a>] On Behalf Of Woo Johnman<br>
&gt; Sent: Tuesday, July 16, 2013 7:31 PM<br>
&gt; To: <a href=3D"mailto:payload@ietf.org">payload@ietf.org</a><br>
&gt; Subject: [payload] some comments about H.265 payload format<br>
&gt;<br>
&gt; &nbsp;<br>
&gt;<br>
&gt; Hi,<br>
&gt; ln section 7.2.1 there is an SDP example.Is profile-id 'ST' valid?<br>
&gt;<br>
&gt; [YK] Hmm, this example should come from Yago (the second author). Yago=
?<br>
&gt;<br>
&gt; [YS] 'ST' is not correct. It was simply a placeholder it has being kep=
t there. We should update it to idicate e.g. the Main 10 profile substituti=
ng 'ST' by '02'.<br>
&gt;<br>
&gt; In section which discuss depack-buf-cap,depack-buf-req is referred but=
 not defined.<br>
&gt;<br>
&gt; [YK] Thanks. I corrected it in the next version I am preparing.<br>
&gt;<br>
&gt; At table 1,the last column has all 'P',I think<br>
&gt; some parameters should be 'C'.If so it look more consistent.<br>
&gt;<br>
&gt; [YK] Why? The last column is for sendonly, thus P (properties of the s=
tream to be sent) is correct, not C (configuration for sending and receivin=
g streams). No?<br>
&gt;<br>
&gt; [YS]&nbsp; I agree with Ye-Kui. Since it is sendonly 'P' is correct.<b=
r>
&gt;<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Woo. &nbsp;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; payload mailing list<br>
&gt; <a href=3D"mailto:payload@ietf.org">payload@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/payload">https://www.=
ietf.org/mailman/listinfo/payload</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; <o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_8BA7D4CEACFFE04BA2D902BF11719A833849B44Fnasanexd02fnaqu_--

From rickard.sjoberg@ericsson.com  Mon Jul 22 09:02:40 2013
Return-Path: <rickard.sjoberg@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5420B11E80D9 for <payload@ietfa.amsl.com>; Mon, 22 Jul 2013 09:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level: 
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6v0BKzutHo2 for <payload@ietfa.amsl.com>; Mon, 22 Jul 2013 09:02:34 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EA76621F8D0D for <payload@ietf.org>; Mon, 22 Jul 2013 09:02:29 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-9a-51ed5793bf0c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 58.20.11907.3975DE15; Mon, 22 Jul 2013 18:02:27 +0200 (CEST)
Received: from ESESSMB103.ericsson.se ([169.254.3.155]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 18:02:27 +0200
From: =?iso-8859-1?Q?Rickard_Sj=F6berg?= <rickard.sjoberg@ericsson.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Adding signaling of parallel decoding capabilities to the HEVC/H.265 payload specification
Thread-Index: Ac6G9MHg+wc9OsJjRRWVFpE7ns783g==
Date: Mon, 22 Jul 2013 16:02:26 +0000
Message-ID: <4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7@ESESSMB103.ericsson.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: multipart/mixed; boundary="_004_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvre7k8LeBBudOGFpcuniWyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGddO32UvOPWYpeLvwfWMDYybj7F0MXJwSAiYSEz5odXFyAlk iklcuLeerYuRi0NI4CijxIeNjxhBEkICSxgl/nySBrHZBNwlTr7pYALpFRHQlHj0XQgkLCyQ KnF+30ZWEFtEIEtiwt6JjBAlehJ7XzCBhFkEVCV23J4PVsIr4Ctx/tNVdhCbUUBW4kvjamYQ m1lAXOLWk/lMEOeISDy8eJoNwhaVePn4HyuErSjx8dU+Roj6TInGrb+ZIWYKSpyc+YRlAqPQ LCSjZiEpm4WkDCKeL7Hi4XVGCFtP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xoIpzAdmdjBJXd/yG arCTeLVkHyNE4iSjxOJlv9ghEooSU7ofsi9g5FnFyFGcWpyUm25ksIkRGHMHt/y22MF4+a/N IUZpDhYlcd4temcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDqc6rXcrUHpbhWzF3mOdH3 +AnnpLSrZdw3pn7aP+Npa6DUuTP3rfuMfuk6bWzk9C5OZzfzvP1R9C1Piu72508/602XZS/O mNqe0cr1LibL3kJcbH/KxRdLz+0Ob14iUF5WW5kj27KFuc8926iwwM31WG73rnKhx08//GPn Mvqtdf3OvVcB7kosxRmJhlrMRcWJAP4/queHAgAA
Subject: [payload] Adding signaling of parallel decoding capabilities to the HEVC/H.265 payload specification
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 16:02:40 -0000

--_004_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_
Content-Type: multipart/alternative;
	boundary="_000_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_"

--_000_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

We lack a feature in the H.265/HEVC payload specification which we would li=
ke to address. We see that the number of cores used in devices that decodes=
 video is increasing. New high-end computers, tablets and phones typically =
have four cores or more. This trend towards more cores in devices seems to =
continue, albeit slow.

With this in mind, it would be good to address multi-core architectures in =
the session negotiation of HEVC, especially for Offer/Answer, as a part of =
the RTP payload specification. Let me give you an example: Assume that a mu=
lti-core device is capable of decoding 720p30 sequentially. This is all wel=
l, but assume further that since the device has multiple cores it is actual=
ly capable of decoding 1080p30 given that the bitstream is made parallel by=
 using e.g. slices, tiles, or wavefronts. It would then be beneficial if th=
e decoder could express that an encoder could either send a parallel stream=
 up to 1080p30 or a sequential stream up to 720p30. As the draft stands now=
, the decoder would have to declare 720p30 as the maximum since there are n=
o guarantees that the stream is parallel.

This is not yet addressed in the payload specification draft. The current d=
raft includes the spatial-segmentation-idc parameter for HEVC that conveys =
the parallel property of a stream. But in the draft it is only used to desc=
ribe the stream and not for specifying receiver capabilities. What we propo=
se is to use spatial-segmentation-idc as base also for expressing receiver =
capabilities.

The basics of our suggestion is that each decoder can optionally declare hi=
gher decoding capabilities given that the spatial-segmention-idc value of t=
he received stream have a given value (or higher). The decoding capabilitie=
s are expressed as tier and level for the profile defined by the payload ty=
pe and any extended encoding capabilities expressed using appropriate param=
eters, such as the max-ls and max-lps parameters. Multiple such declaration=
s can be given to express different capabilities at different levels of spa=
tial-segmentation-idc and to sufficiently express the capability space for =
each spatial-segmentation-idc value.

The set of decoding capabilities expressed, including the basic level (spat=
ial-segmentation-idc=3D0) expressed using the existing level + extension pa=
rameters, are then provided to the peer which can then choose how to encode=
 the video stream to meet the decoder capabilities. As this parallelism dec=
oding capability information is receiver related and declarative, the infor=
mation actually fits SDP Offer/Answer well.

Given the 1080p30/720p30 example above, the decoder could use any of these =
examples to express its parallel capabilities:
// Level 3.1, but if spatial-segmentation-idc >=3D 16 then the receiver is =
also capable of Level 4
a=3Dfmtp:98 profile=3DHigh;Level=3D3.1;dec_parallel_cap=3D{16;Level=3D4}
// Level 3.1, but if spatial-segmentation-idc >=3D 16 then the receiver is =
also capable of Level 3.1 with lps equal to 1920x1080 and max-ls equal to 1=
920x1080x30:
a=3Dfmtp:98 profile=3DHigh;Level=3D3.1;dec_parallel_cap=3D{16;max-ls=3D6220=
8000;max-lps=3D2073600}

A more complicated example could be:


a=3Dfmtp:98 profile=3DHigh;level-id=3D2.1;max-recv-level-id=3D3.1;dec-paral=
lel-cap=3D{8;max-ls=3D46080000,16;max-ls=3D62208000;max-lps=3D2073600,16;le=
vel-id=3D4}



This example describes the configuration of payload type 98 where the agent=
 declares extended decoding capabilities given some stream requirement rela=
ted to parallel decoding. Three different points beyond the configuration f=
or sequential decoding are given:

1)      No requirement on min_spatial_segmentation_idc:
Using Level 3.1 which supports 720p30 (max-recv-level-id overrides the symm=
etric level-id).

2)      min_spatial_segmentation_idc >=3D8
Level 3.1 extended with max-ls =3D46080000 is supported (enables 720p50).

3)      min_spatial_segmentation_idc >=3D 16
Two different capability points are provided:

a.       Level=3D3.1 with max-ls=3D62208000 and max-lps=3D2073600 (enables =
1080p30)

b.      Level 4.0.

The attachment provides draft text changes to the payload specification. We=
 believe it is important to address multicore devices and that the text cha=
nges provides what is necessary in a compact and straightforward way.

Best regards
Rickard Sjoberg, Bo Burman, and Magnus Westerlund


--_000_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1779174344;
	mso-list-type:hybrid;
	mso-list-template-ids:-1878078196 67698705 67698713 67698715 67698703 6769=
8713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Dear all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">We lack a feature in the H.265/HEVC payload specific=
ation which we would like to address. We see that the number of cores used =
in devices that decodes video is increasing. New high-end computers, tablet=
s and phones typically have four cores
 or more. This trend towards more cores in devices seems to continue, albei=
t slow.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">With this in mind, it would be good to address multi=
-core architectures in the session negotiation of HEVC, especially for Offe=
r/Answer, as a part of the RTP payload specification. Let me give you an ex=
ample: Assume that a multi-core device
 is capable of decoding 720p30 sequentially. This is all well, but assume f=
urther that since the device has multiple cores it is actually capable of d=
ecoding 1080p30 given that the bitstream is made parallel by using e.g. sli=
ces, tiles, or wavefronts. It would
 then be beneficial if the decoder could express that an encoder could eith=
er send a parallel stream up to 1080p30 or a sequential stream up to 720p30=
. As the draft stands now, the decoder would have to declare 720p30 as the =
maximum since there are no guarantees
 that the stream is parallel.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">This is not yet addressed in the payload specificati=
on draft. The current draft includes the spatial-segmentation-idc parameter=
 for HEVC that conveys the parallel property of a stream. But in the draft =
it is only used to describe the stream
 and not for specifying receiver capabilities. What we propose is to use sp=
atial-segmentation-idc as base also for expressing receiver capabilities.<o=
:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The basics of our suggestion is that each decoder ca=
n optionally declare higher decoding capabilities given that the spatial-se=
gmention-idc value of the received stream have a given value (or higher). T=
he decoding capabilities are expressed
 as tier and level for the profile defined by the payload type and any exte=
nded encoding capabilities expressed using appropriate parameters, such as =
the max-ls and max-lps parameters. Multiple such declarations can be given =
to express different capabilities
 at different levels of spatial-segmentation-idc and to sufficiently expres=
s the capability space for each spatial-segmentation-idc value.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The set of decoding capabilities expressed, includin=
g the basic level (spatial-segmentation-idc=3D0) expressed using the existi=
ng level &#43; extension parameters, are then provided to the peer which ca=
n then choose how to encode the video stream
 to meet the decoder capabilities. As this parallelism decoding capability =
information is receiver related and declarative, the information actually f=
its SDP Offer/Answer well.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Given the 1080p30/720p30 example above, the decoder =
could use any of these examples to express its parallel capabilities:<o:p><=
/o:p></p>
<p class=3D"MsoNormal">// Level 3.1, but if spatial-segmentation-idc &gt;=
=3D 16 then the receiver is also capable of Level 4
<o:p></o:p></p>
<p class=3D"MsoNormal">a=3Dfmtp:98 profile=3DHigh;Level=3D3.1;dec_parallel_=
cap=3D{16;Level=3D4}<o:p></o:p></p>
<p class=3D"MsoNormal">// Level 3.1, but if spatial-segmentation-idc &gt;=
=3D 16 then the receiver is also capable of Level 3.1 with lps equal to 192=
0x1080 and max-ls equal to 1920x1080x30:<o:p></o:p></p>
<p class=3D"MsoNormal">a=3Dfmtp:98 profile=3DHigh;Level=3D3.1;dec_parallel_=
cap=3D{16;max-ls=3D62208000;max-lps=3D2073600}<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">A more complicated example could be:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">a=3Dfmtp:98 profile=3DHigh;level-id=3D2.1;max-rec=
v-level-id=3D3.1;dec-parallel-cap=3D{8;max-ls=3D46080000,16;max-ls=3D622080=
00;max-lps=3D2073600,16;level-id=3D4}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This example describes the configuration of paylo=
ad type 98 where the agent declares extended decoding capabilities given so=
me stream requirement related to parallel decoding. Three different points =
beyond the configuration for sequential
 decoding are given:<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m=
so-list:l0 level1 lfo2">
<![if !supportLists]><span style=3D"mso-list:Ignore">1)<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>No requirement on min_spatial_segmentation_idc:<br>
Using Level 3.1 which supports 720p30 (max-recv-level-id overrides the symm=
etric level-id).<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m=
so-list:l0 level1 lfo2">
<![if !supportLists]><span style=3D"mso-list:Ignore">2)<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>min_spatial_segmentation_idc &gt;=3D8<br>
Level 3.1 extended with max-ls =3D46080000 is supported (enables 720p50).<o=
:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m=
so-list:l0 level1 lfo2">
<![if !supportLists]><span style=3D"mso-list:Ignore">3)<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>min_spatial_segmentation_idc &gt;=3D 16<br>
Two different capability points are provided:<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:72.0pt;text-indent:-18.0pt;m=
so-list:l0 level2 lfo2">
<![if !supportLists]><span style=3D"mso-list:Ignore">a.<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Level=3D3.1 with max-ls=3D62208000 and max-lps=3D20=
73600 (enables 1080p30)<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:72.0pt;text-indent:-18.0pt;m=
so-list:l0 level2 lfo2">
<![if !supportLists]><span style=3D"mso-list:Ignore">b.<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Level 4.0.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The attachment provides draft text changes to the pa=
yload specification. We believe it is important to address multicore device=
s and that the text changes provides what is necessary in a compact and str=
aightforward way.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Best regards<o:p></o:p></p>
<p class=3D"MsoNormal">Rickard Sjoberg, Bo Burman, and Magnus Westerlund<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_--

--_004_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="dec-parallel-cap-h265-rtp-payload_r0.docx"
Content-Description: dec-parallel-cap-h265-rtp-payload_r0.docx
Content-Disposition: attachment;
	filename="dec-parallel-cap-h265-rtp-payload_r0.docx"; size=45268;
	creation-date="Mon, 22 Jul 2013 13:14:27 GMT";
	modification-date="Mon, 22 Jul 2013 13:14:27 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
lc1u2zAQhO8B+g4Cr4FEJ4eiKCznkCbH1EAdpFeaWtlE+QfuOrHfvivZFpxWtdw4uQiQyJ35OOCu
xjdrZ7NnSGiCL8VVMRIZeB0q4xeleJzd519EhqR8pWzwUIoNoLiZfLoYzzYRMONqj6VYEsWvUqJe
glNYhAieV+qQnCJ+TQsZlf6lFiCvR6PPUgdP4CmnRkNMxt+gVitL2d2aP29JElgU2e12Y+NVChWj
NVoRk8pnX/3hku8cCq5s9+DSRLxkDCF7HZqVfxvs6r5zNMlUkE1VogflGEO+hFTJKuiV4zMUx2V6
OENdGw1dfaMWU9CAyJk7W3QrThm/5+/j0Cuk4H46Kw2Bm6YQ8epsnE600YNEBroM+xjaLPzKzSEx
/dnuf4XRSR8LooVA2ljA9yfY6p5o/2RoeVfXoPnWD18Mh3mDXmwtDmqH3YCI8z7F5HUv5kO3D3fK
gwgvMP/xYRQH4oMgNc+ImZpbOCHx/wyjkx6EIB58INvn+T3Yyhyz5BHRtjsP0vSGY+8nZVOd8+w5
oc87Rx7CZ+cMzZivoOrxlu1vZfIbAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC
X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j
ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM
Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03
Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1
nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQAqQskQQwEAAMwE
AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAKyUMU/DMBCFdyT+Q+SdOCnQItSkCyB1hSJYXeecWMR2ZF+A/nsOooZULWHJ
eM/yvU/Pd16uPk0dvYMP2tmMpXHCIrDSFdqWGXvePFzcsCigsIWonYWM7SCwVX5+tnyEWiBdCpVu
QkRdbMhYhdjcch5kBUaE2DVg6UQ5bwRS6UveCPkmSuCzJJlzP+zB8oOe0brImF8X5L/ZNeT8f2+n
lJZw52RrwOIJC47EBdRQ+BIwYz9lJ6YxgTJ+muFySoaAu5pC7CG6esx+MaW9chY3YlsPYuilMYjZ
lBC2NVvwNGO/MfTSGEQ6JYRsAzrzSs/ev0Uc817lGsGMjsV8SpoP2D4BImUymI2BOBbL9ZQg4Yhi
r4whXP2BYLT0LjiFsXSGdxv6vZmLw+Xn3Ra8aKzulQKJgxCOjvYc/OAPyr8AAAD//wMAUEsDBBQA
BgAIAAAAIQBZYP97KHIAAOj6BAARAAAAd29yZC9kb2N1bWVudC54bWzsff1u3Ea25/8L7DsU9Mcd
+64kS7JjJ75jXTiOc+NBnBi2JoPZIDCobkpizCZ7SLZkzcUC8xi7wO5r7Avsm8yT7O9UsUgesiiW
yGqqKbeBRF9NVtWp8/35x3//vAjFpZ+kQRy92DncP9gRfjSL50F0/mLnzyff7329I9LMi+ZeGEf+
i51rP9359+P/+l/+ePV8Hs9WCz/KBF4Rpc+vlrMXOxdZtnz+6FE6u/AXXrq/CGZJnMZn2f4sXjyK
z86Cmf/oKk7mj44ODg/kd8sknvlpivVeedGll+7kr1s03xYv/QhrncXJwsvS/Tg5f7Twkk+r5R7e
vvSy4DQIg+wa7z54ql8Tv9hZJdHzfEN7xYbokedqQ/kX/UTSOIVhXfXkdzkE5IqPEj/EHuIovQiW
5TH6vg1HvNBburzpEJeLUH/uann4pLFecWSbO/gu8a5wFeULG68zAGOuHlqECg50v+Wt1t94eHDT
YfIboVcUe7DZAl9T72ThBVHxmn6gqQIXFDEEv/8jiVfLYjvLYNjb3kSfincRYd5iZwdPJeVVj5be
6gUN0v1w4S39HbGYPX9zHsWJdxpiR1eHTwRh5M4xmMVpPL+mr0tx9RzMZv7+xc7BwavDZ89egePk
v/rOP/NWYdb8y7vKr9TL4k9E+R8yL8nwdDDHB+g1kbfAwh//I/7Wm33aeVT97OtoXnxS/iGhv2bH
z/bFO+86jL25+F4yFvyY4DUZeOIfH9En6P/4MP6/dHICuboTOKgjEMN8ni69GY6+TPzUTy79nWMh
xMlFkIrUnxFTEunSnwVngZ+K7MIXy+KM+NHLxNuXfxWnvlil/lxkMR4K8ZiIl/SoF4oz38tWeLWI
z/LHFcQUKxYQD2LmJxnIrfLRRIALLPFrWjR/8DTI0izxvcU+bY/tw0v8YpNzceHjR29NN0DX2AE7
dvW4+SSOz14nCVAou14C0OfAEYl+CstyZAJYM5sngYzV51puMIfZwp8HnqBlReKfB4CfFDMCwJeX
8cPrX14JiGx/BqC+FAtvuQQLZ9twhrtrgxzOSodhu24Bux3wqigugghILYElPpCyAXoQ3/npLAkk
hgvxLomzeBaHQjz48N27h2wbYwLv1/ffv3ry1dOnbAMtcGii329CBJxkWh61BKEXpgAbcP8ymIMx
SIwTQK8wmClNh2AK7kF8QwgAbp/te0zAsYVbTt0E2Ou/rYJLLyQltoIvNu+yhOAsXoUAHFirmPtn
QURQ9MPUv5L8TQFUAu8qyC7YupsPvFkcZUkcsl23QN4OWkA0SYQkooBV81hEcSZxa32o5VoYQ584
FG8lxz4hjv2+wrEZpJzdr+sTtAgjJa+VLEpXp1IcNSUQ+I/wwjAGfwCqnyXxQnLdN69Pvl/P6dcm
kKCl9JFGx2tigaPecuLP/ABOAfH2zx9OREAqPZSx6FqsIq1Gzkt+udEndgM3N28pcfX4L150viv8
DMQCRb349/rzMiA1+09etPKSa3G4K+AoeVL8Pf/m13feuS8ef/3bmmnqtNR3l1iRVFawLZe2UAGS
0Euz9340h9o/p9N9CyPhkwR7dvwmgjEW+dkefAlnkNTy3/uTd3XDjdiRVIbzj+DLn1ahhuLj9QDL
DWq4eUsBTemTM9qEFdFExvJzCSpS7+JNBo/1wbRkys/2w9HTryZ+rvc+dFQQRclv0+fQiyIunKan
Tfz87uTNzz+9/LF6rolfFWjpTST1nbMYOhA5UpXWH0i3MPlASr/LrtghR4zyhuwIsC76eT0QsCAf
7J0uYxUFWbGnxD+DE4z8QVDpij+n8DVEl/41UBLuHjrDbJUkMKHucu8kDdLcsseuPnw42ZVeKauN
Czx9l5tna7dYUE3bNT+uzcN25hd58drhFeOmE4KUhnNupd0x0tocvwk7E8a2AN4OdhW4gOQRp5rD
5RkRgbz9cLLRCrIdb+gHZhj0Z0Ho70nntM0rasA+3iXnk3xFMH/OXjA9gSc1LcEO0YJyTXw9AZfV
oLB5Qx2O6gYqPi44CqM5efFgbEgeTkw98z9Du4YWzZZwBmk7TAOY2PLWMIKP108Q/8iUdxzS1uY9
NUi1OT9IzOkL2AvgxCsEuRBwIK58uN6lh4StORXQ5UTG9t4C9xq8QKFXF8HsoojcqPAS1PAUxi0U
HpVKAB0iDnOBsfCu2UJTAdKFd8nVMzsItWDUqe9HRbjt3I98BHV8SYlKIySFUHpBCfO0P2aScEtX
y2WcZH3iEsAuxABFgVygO0hU8SsZ+b/hb3A2lm710+tmBGkquIVklNMgWgfj0vJTimBAEzpehY9J
rsWwqgWpmyLppxj4KlHU5vmcbUzlPhjUbnG+jrAy8DXR5jysKkSF8BM8gPj+gDBbI/bpat3G1A3u
thaGpdSXvsJZWg/uAClFbirDZ7BXIVEIlqVrGqAktnm2oqQFAcbw5uTPeydgqWwHU0HGNx9+fvTm
9StuRbTQqWs6G80vqdDrTZ5eUrUbJM/SBAnVq9C8EGnC7eYpK5O8Wa2Ds83ffLMdHAZwqmTceIXT
Jvfp7AqQi15V6WO7bPGp0ETG3dWDYIbEGSTPVHSvXfn9IoiCxWohWnRZb5JwU2flfHAQ8C6gn0F8
5UoeaWTEeXNyrbBkMOFTCIFJAq3kOGz7dnCbfEB4GGeeqjdh5i09lU7e485bVCj/8+wCcV+fbDvt
rIaZvFo22DKUGWlBs7WnwptdOl6q7gPtagCPKdTmCrMhro2sIfqNTIacJOwGGMstSEdBceK8uROB
YlJkBKY+/H/ROVcqnWHY+GpjFGuhk/s6gSVwBuKYGSJBykdH/qgDldMCcyGIEN1CYHWSeIIrZPu2
k0UtKBKcIaBcgA8qdgk7SU5vKa9bi3SZEnTKPWHO8GbtLmLDlduBbrPFuBt626S3lJjgJlfqm22u
FCty2eZKddeAKM33pLRnctFC8rPdIYEUNuROquRXxqOnwiWhQbF92zHIFtmSQlVDQWml0geqByJD
iZBJZ6U3R/5ap6Ck0/RK1OqVhgEur9eSWTbaMQxjW6UWpfdDcfseeIBcHUIHYkiku+fhr1kM3Sxd
xlJLJQ8D/e0iOL/w0+yu83XAF2wIpBkzcZ6yA4UW+SUIwSKYSN9AcZPlOf5c+bDKPDT16/QLTqIw
MyjUN3XdJeIKYdi8zFwCdD1NhYL1oPlHq4QYuW7tUfMhxIu+h1CR5/Bjfpjbb2wiQs0Mt7u5/KDT
dLuLmw/msy5Urm7L2b27MTpKc8F800qVw/9J4igRk8rqsi45Uzjqal4tZ+e33vntGD2cZagoFL8j
MHqXxcAK7l2IZS6mdqqHyogxOYCkjrE63Qu9az+hVK7Cu7+VjbUWAnfDHjdGNsIF/1FiSX/pqKO1
x7/+vm7/Q3vJzwAaNDPTu8GLzRCbTaS4peBcP0qMKVF7cvYArPcs9HiTCjtzGTmBoX/ph2Dd94Nh
n8CwRSKdBgm+LyQSvi+TNfI87TJR+55katugkJ0VlEt3jR5FYjZBGN0XqLeQwp1pepdkorU7aIXB
As14FJBkf570Osq8z2hP4VNXN/wqoRIWL4EeiXZIATcPxtd/bU7etNIrmbV9MpDNApD0yDwFEd/V
4IZwI7ouVbx3bOPu4dY/lVN7FeE10s1JkKZDCnIFalJnLpgTub4Vfa35VGtRZ467dQiTu+Z++Frz
3MpS0JR3WbWCWFZlIX4medtwauXJkGz7dnpGO+VbZVWSy1ol27G13ZP/eggFTIDtexDMcpc+MRZU
RZMDX7IQyWnyhERhzCNkW5gK6HJNg+19EPgksO4HD7IBSlOGg3MRrtg8bKcoVrVt4oKFRVHRvVFa
ROnlKr98sqr2yGmMROKNmNOaUNfacQr0WXif97rQR3q3m8iH2rtLq0drqHe8V9gh0K+okVmRjkZQ
YvaIVr/YOlPhd6e8nHMQq2tRTkojmECno8CFEJkk2Jo5qoMgdxWkCI1XUvFR2vczoJXgDz6CwUyD
vxNymOQtaRpmmx90URqXpfbTQGWVuqzLKWSFG1t6KkxBVSzXI092gDsG6lKYzofjAS1HileptHmZ
EAIbOwyV1FZVTJMEEvQLtm878LQYJqRZy5JxVfvIMStPK0dWmkzflX1dJ5rDWxylB+i2SbzB/P13
Nl3WXccQnCTxPjlYdxBt2/CwuwG/G9Rw85bb2AAocSi1oLLCoaM6hIplGKeZigQOHLa/Aei0IlSp
DWGQe3wgHgT7aIOjtHIMknkoZc0kYVcTjYPksi4zWpMVPDIdncD+KqnoJg9yNQ2+4b2ZChHp7HWG
xYPQoYztWqXB3+UIjAF5I8dF/Msd5Cr9UbZp8Ns0+OqoGwRhb5cdeVeZI+8wXKz/2KPlOzlmJlFf
QpSSYxwN4tAvdtLLvQ+vdXtu+jMx2PzTpCO5DhJhXTnEiZ1HKmMWe2vdTp+8sqE7OSZp1sWkqonP
ndx/6I7M9r1Ml+qT5z90O8e6RIAA9dEmaasKLbeCfuhZzKBVcg7/70IDc5oysFbqvDZP12IE5v1Q
UvLggg65pY+3zE10dlsja6XbpH7J8IkBjzFXbohiCJeuM0IpuzrgrdQxZYOS+plk1HzLyvUmbzGX
3RbSdCvpbfQhmuO4lfQ3KIwEoDK3vZesh06oEZ1h/y30wjXXSQzdnlle3yv9ocSBXhrEl1XdUE8Z
QcKhzZRQ2ak8XnbJwaoeXcAVc6sj5NOhI0+/jsp3Zflaiz5p4vbPaX4pTr3UP3wq5CTNp0++/k08
uPA/e8gzDBZe+BDh5DwPR3VbzmsG0uAzuw5nmrBkfvQ/1ya4fOfx6bXs4J87W9kROg3VG3clR/fJ
HAVUwOYtPKqFKeS9pIC8auPBFp4K7ApXLNv9ILARVIoeJvU6gLy9MxXwpJjiS53Y7ryouOvodQ4n
qTM7BqM7R3uOFI1uPqbxKpn5t/YMaI5mlqlo7s7+9dyn5LQhylrnQ7d5vOk1Qy03hUlhHzEa/BMg
UEqOHpdlJ9paL7Pn/Z3RJPauZ00lGx/jKLweduIc1WkEwZ2HgKmRIaa6zz/+3U/ij0+e0Bj1sXv3
30ywAoK1uUca0cCubyqyQbfpZ5sfJBpQD4Kmk0Xj0nq/fyE75OuqMmqGFGRs8alArj7eZRDQADHw
tVlwFpTT5ppd/YWxQ74zgI3szES6OvIt2N0bYNjC7l2ZFrL2IVeU662kvtQOoNMwndZiZ5jlep94
nTJbKvpjF6IbpftadE4EXQ7ZbpxxEDq0UifMgCxUXba8geqNESjzO/tfTqk022ynFtI6Hqpom0+D
uzlgu/lC7wbqPANDC440LsWFCXAjBm9ph3w8x3dvsLTSzyR52zHYmDYseiF+xWBaHw9xoyHev7eU
cs9N/v/hNv9/28T7XSWFrkSwFranNSvKENk2GjaFp2qqQgscJ5Nhebs409ZY4vFK6VWww4jBGWoV
G7CvzfCFGgEbaqB16WctLiudX1qeaosO0tRqhFxaALi5NiHDiPGJVQv/4ivbj8F0bgGwxlA3sbTx
4dB17FG8SptrGTPwjH87BXbqb9h+bo+lEtCD45/jw6Hr2EYsdewf0JSuXQ7VeCvbnzPwuDH6b2UH
bdvfLwle20z5bfv7G6My/SMoFdOGcQ0DMx8zvMX24oyDWfMeLd+Kr2w/Bti0qGNlinIFzn1tBh2Y
W3PmOQFpEs6G0grrup0t5hKEbmWplZhbgnmLuC8qpdz9ee7WCp75VUgWXLbxTRdhd7JdN3bwlvNm
VLFfgGFrII+GwG5M5OLm1j/cp389TBexj2FVl2LPZFevDXpjmtb9wAz99SwIfdR0LZYoRzoNwiC7
3ss7hMadbSlMGtgXnKR4/FLkxV82t2EX5aqUkSEPJU+IVZVjNBhDFUidoQIGS1MpFlt5fBOLLW+w
qMzUXhyMSpIavbpaXmMJv8dH6Kmu0FzQWJESz4WgZiJos47GTo1FpwI6XRtnA3g7iBVVaVZzslEE
8pKtPRXA5XMf2N4HYRqqm1A1sSAURqmFJ2Z+kqFKtkA+1CVQAYZ3GqKD3aRnc1DxT5b43gK0U57a
HSQJPHk5iobekGIjahmo39Njk8e8cf/4+M2YFt9MC8I2hwgUIl1Cgibfc0nR8iI7jiFQ3jxDNS46
TYIAuHBiAB8fdmz5lkM2oeUpRcjmYTsIQVJ7+TSepEIyZkZxX5iDO/CVTEZCDLMsqC97LtUhgd7G
GJSCD80SP/PD611R6z07Fbxz2ptIKz2MfUiVB6BKYAgtY9nKnkBK7Yvyz296mbFZg3Q8mrBBrDTY
AmiFuXp+JsvRVJN7PTwKfyC5zjB+MkgXs223MEk7PqfgAXTyMlFoCWoQOKEY6dsKgoFEQH+WoYB/
85sQmHFuHdSKqekXwewC0qIEX8795GyVB6BSkt5zBeP6FqaCc86V73woA83iqM/nyRusFPB8uNGN
sN34jNy8peIb/gt6ve4KNBfxwqo7//XnZQBJIv7kRSsvuRaHu+Lo4PBJ9SP0/a/vvHNfPDnaVk9s
qyfWXT2h5868P3kHUYMOMbWCxfFZJLnpqDs0WLsPT5P8FgpDPtjvCkOG4H7yF8s4IeJKZ16Y2x/T
9UoVI/jcqRbechkGYDUSXr9TKd3+/uPDL9nbDCfJictmpvCUKoeoi8oKCiug/U3F3dqj548q+F1f
ZoxrMdlSu6TFIdWAaccZzWM0mmEG/iUe3L2eV2GnuYqKHiHKDq/+ae4v/WiO0e3RQwpP6Kb4jA2M
z4FpG+C4qxR6s+QfBbutcltSHQvGJXJ+c8c7Z8u3mGZN/xWd0eZJO6Ou600t6RqB1XN2Wzj1pVsd
FySn3hNq0W0hrmvouEztsgQkBFt/fKRjy1tfnZRqNo/WAHe8lYQ9oNbCsIdLwjLjIHerOZOFXad0
SY3Hv33BuRFV5tIF9PubCHFyAcFZhoTfvvwrBTGlJIXfmM2SPXnznWbMuRLDwDYVDlzcO9t9CwOv
ceEWfqLFlQyaIl7xFzIESQO0WaIp3nVbNJun7TZIwrSQrAQA9uqp3FzoXftUUsI2P+jiSHMnU52+
RGc+nNZz+QMFqPEPlED/VE9F+i7jvvTxAXe5TD9iuPbHQv7gxyBapYf/7VCqRekNfw94Z6fxN29z
b01qqNtGgy6cfOtxhd9RP2VSJ3WaTf1PKaK6Z0Hkc5ybCuhqNz4Icr/+8PqXV79ttG+98Gf3zGbt
ws+66gXVj3e3MMeRMF/80urVNV5+vFeIqn5M757YDDerKGlwHsGv6iF7cuYj2pj8IRWziziYbeOO
/s4xFDaINfhrEkpPCTEQHrxOW9UpZUaSamCFnU3OnIIAlnsQSVbP17EbetKJVkvYC6bCXWu99Qdx
VwYAw5vqrCf3nLphLYWar8KrUPr9zzVNXyIN2+RUbkkqjWznBvAa7DsbVV8F6UvWAygtEeaRrdO1
DcCWngrQcguE7X0I2FSH58IC6XrvmrGd+F6u7EPRr83insoVSaOkC5D2eA1AFHIB2sY09LwbC55t
YNOUaTCuuHFsQHvn6CknYW11PKMbCqwjPvehpWD2G4XSaXKcnFVLf2B3PBXK1U41tnkDmt2CeKFH
6biixKWKOlyRSaRuTdlzJ4/mFmraaCigRO6gYoYG6caF0LoTzsBOOz6Ca8YkxDxQaYmoQhPi8QFq
q2BSSONBvKUqGDmq64fgnHJdQKFCPPC4WTD+5hnsWuirKQDmSDGnKp+ay6fl+ZpR06I0AmYF2yqx
64Bghow6StVWmbLh9TZ5MZi/t2qx6ia3w81bCsdT5qYN9eNtIuU2kbJXIqW0Ou9EUhWiAgKUQl86
iCVlhBKi+Is2vBhvnopoqOmbw0RCZVSXBt09MLoQI2NX2wKjpti9U5y12bKdpJejq376+YRChzkF
qLRgUiWZis7WnAwFuMxHNerexDoknBJyrukqrDNvFWZC0sk9IBJ29QYKqfsXLONMPd3xxrfXsP2L
iCShDuvSv0Y4+FrNHOaxYHZpU6FXPSpYe/NVdjInIQMC2nseVKoLk/V1L84kAUcJUGzjw6AEVxUk
o3b84NtZjHAcffWWRTGITERAgQjCc+qe2AamgnKzCy9BtwA/oQnUM+4DGATEB8G+v09VzEs03qBK
EWRdFY1lZFMC+SsC3yQBJwNVDuHlFbkrQLx8NPhDGhl+5YeIl6fSgxOvsr34bO/07icQsztrQZSm
2pglXpQugmYZWMsbanKtxV8DzDIkClGPEnKhFh5B6HRs11Mh0YJDs90PghhMO3TEiRcLby/16f0Z
Eg0e/GH3Dw9FCEZAtHrqpf7TJ2W/K7b4VEBXYzjsDIMAmKeQGtBOaCEOEHP2MBWgkXtTTlh2By5w
tA/kM40j8Wz/8f7R/iGh2JRy1AbFLgdZCMgR7boI+f6CV24tBCosgwqXWwjmZFEG0/FJs+QSOStR
OmRdyouqxATN3PGu2fItDLQp9fUF2DxdYLFKmWqR+IVIpPYlJkFfMQZJ1rGV3V92zwTW3t63muRm
p2u5FTu43qwC1PV3tq57qN7IcnvDrkZDg8BFXkKN3BWMoyz1kr6huhcSFar9JIHGhfdRm/C+GZjO
MMR1FLCFyQDFut3jg0T7civaMYjc3Kb+5jTyXLQvg1m2QrM5Jg+I9iZJZasInTzZzm8mKN1wvAV/
b6VYiByUbHlnFFtG3Fv2KmnNgtzI1dlUMIrrZ7sfBDw7vSK3odmyUwFaYfiz3Q8C2u3Uh6mqs3U/
0iCQtXIwIbkBOf6q2oM2o9mdjY9xyoh/3KYHONvQJkl6M+sZEAgPO3l9D7t+VwzZ0W31kbyuZdCi
s+Upw2YDOXE4uFh0fheLnnZOcDAe9H60EoErPq0oaqmo9S7ICwPJpCqibHnYaN3m+3oMTZ0v0YXc
9tHbYLEM/YUfZTJ8tk/RjRpI/4zOSnk6i+wJgaxftrwzxrxmhQ5BfbZvA0+wB1vennqVLOMUIUkZ
FGK5PeJBKWKrub9sC85A50ambdJbSmRwk0/7ZJtPu82n7ZVPyyi2hWk0zcd6NL3lQTsX6gD1q395
sE5JfShkRiOyGdMV2lbLxt8kUbUsonKZs1UYcu7qjLWVjGAtZr7UC2pt3QfdFTwkeQkw+tlBMvRD
nwE3vjUBaA7u8cRMgDq/mAr9DEDU25ouNjHoFh5RswuKLLy6VVDla4xwp3IdxJ3ZxgfxMv9z5qMz
koLK31boAz9vGFL0R2Vn4Y+5Csx2MBXQSXnHdm4Hu+Nd7lA79cP4iufXOgOBGw3dWqSqUiKavCMT
8eOoYmyLsyReSNSg0OSDAXzgtgLLha8m7OuVYgji7F6tb2QAmG8tEI38tqnp7gpyDzK4WBIOT9I1
PCRdV80V+zvahjgybyuucjR9qNoLFvnxkmRK5Vkq1wx44yMVW95wDWYvda7lCswLCW3eYGfqlLKE
Sxr8foECIC/y41UaXkOxFgLN1tnCU4EcZumR143tvQXsNaBB1gRIo4X3aQgm92O4LaoVtU4cwJX6
UVXbXihsT/OfIzXBq0AmBuqpoIlJmbJDkxbwSA2nHNUltTsankIhN4lTpMvJueWCsrepGGWSgMMc
KNo/2/sgwMHDkXM7fy6dvZh9FqSqo1XVDbJRg191tlgxjwIJ02ryGF1zuFp4IpV8SF02zrhaUobr
AGK+HWMZnw4f2KBEU98Iolm4StFY0ubxOsd+qNAkx0lylg0Gs1Oe+aA4ndopO+P4V8SWbyHa5g1R
LR3nVS2P1m6nhVHqBIrTFbXOhBT5u08XN0dF2yWs3Hr+BOiJbXsqUEv9hRdRhR5a9/As8EHQUxru
ADbiFL8reXyoyIdpDnuFdBa1SxnHm+TllVWQbPuDbo6GOYXXpYbAI5rNgCZbeSpYTwOw2MYHgWyg
+js8PHM/PE2w5t7o0eIYF4sWEP5zVVhOysrP707e/Ez6zMKfB57IrpcVRxTPeBofC3tnmKITszs8
lKkZ1MFT9cImqJUcghR8rygfyBXCu54C3RtuAyTL7RRUO8YAm3yQztzXEzlo1Vs7Awun65CzDnDc
SZE94Obd6hQgXUFMitHvhFhP7iRh27fGdroK4i9FETwYDc2C3Eup8GKX+I78MZjD9KFWrWwZ91Dq
XynXmwW51yF0toVYrFAr74VX3nVKHaR4zoW26dcM0a7kxd5wMzQ1sUO7FkNNKqyU0SkTUErFtVRV
c2SUKr+E8T3Ql9jtt8CvaSMPYJ5rEZtrSkG2DqWdVFnYiMBRkrQFoeFlQMezIMr8czge8jwFPRgT
m0QQZMGu3z077SJ+trw19oEOZzSqO3Joe0knNbyaqqoFOm7FqYmJduS58VHUB5ct3XXjijcPdPV4
J4BmM11oHeTZgp9FVVxuaNC4EDjDSR2oOsLzrDqyO9DkKp7Xr33zQG+OccpeLDYIb+dXBKQ83dpQ
Iq9MqwDNJ+g3LrNrKFUcsNQJNWzpqQBtPXGreyC3oTYNbc57W1LvEjYa0WqxLJ3xu9kBLcl6wOBR
kYJMpJhRjk5FUx1D79rXwejYWma6nfFNfMX/PPOXsmVSwba7tlaXSbkj4K33+UeEED+8t3rejj3m
LaIjcSLx7uUeNYVg7x+fBap+UrKFTpUxc/Si4BDagoUwf/X0+YmGhOQVMJC3YKvdjUL+N9Quwwtb
cKwfsztW6l7hnRh9Ay2qk+ap54mP5IS8t/FUM5j+tvIcJn3lvLu4si4EbMGXdfCkc0R8ySBjPCnv
Mse2OT5rYssbqMqs0tbLN1setKNvYoksSLiPZgKYHYhxk5Ryj6AEhDKY46covgr9+Tl+RIgCn2B7
dwY6N+nRm/SW0pvhpgzyq20Z5LYMcsQyyDyThsdoB7EcGcpUXFnm5VRtap23U7Wt18NpSrpskfaw
9eQ/tnzLwZu+Wl2gxPlky+N2rBoirF2BvQfGdT9AD1EObxu4NXrzape3rikL1vh6Aole6GFjQqfL
U3FP3eKq2ZwN8tYwpYXvqFzFFp943qhiY6618Caz8ztTB62Rni3fwmWbTFr5zhyKtsIn0+FKFxji
jvAQ2/VUgJaLaLb3FojbI7yMQkSCsjLaPOk1M4WtPz7sBruBbyt7urjr1g+cYurki52Dg1eHz569
OtgRaIRJv7IaRLlmRjMBP/C7D4yiDBQtfTZ2JK30j4rPhTr7s/ePT7FbP/BzG/21RSsZ6Afux+1c
OoL77aAFGltP8PO2JBO3nmCnXKnhCa7MG7lj5sSWN/DeL88TvGaJbFDAW8BuJ/G0m0xIbxYY7TLG
gLM4Qmn9tUDNEsJFlbrcPGuE3fr4EpEt33L6ptG09WxVlEw7LO0H6AFG/q2LA2w0g3vj2bo1dLps
r/vp2RqjJLfi5uoikpaQ8avl6bfJL7Pwe8yrrMXiDSztFjYM6r3leEW2r6kwaQQK2L4NoCCVwk62
/fLqR/HD++/KOlxKcZ5TSL3I2+1a7KbL+8nbXt6ODFnnmVlOL0/IqkEhL1BUrhA1bzTUnMqgOjtc
3nR76yA9Wd/NUMo93fWvOWIbMxDWTdBaB66T03TunwURUtdAk3oq08v9J5S9nY9TFPc8g/7WMt1G
42mx/ougxw0p9BdoMbGgvnsLH18oJ9yLGOK4x+g2i1yFsbup3GxjOmVGiyCi+hfhLeJVJAfKSiVD
jxkSebuOHGaVSMAWdNq/XwuDDM5HvzXhdCnDeqMyIX2S96aDd2zzBkZvr0FpfyHPxq/X8+elOHk+
PFt9MtwiZtseBDRwnqKMhmP9blkn2syHZxvYPLi1aAdvvc+v3n3L9m4AnnzYTmk3hmBybaA1GZ6t
v3mwM0uovm1/W6S7qRLASUJNT07bGQTZvHuq47hR12p6Fm8NION77chDc+RaLr9AGZ8X6lKkIo2K
0UUbXTYP5JyoZQSDbWbzLt9MpLURtwYY2ktTXVxUCd8UHO3mXPZJgo7y79nGBwGPJfJD1UBDh9Us
w8hK9N8Tslq2aDdJWQsiJxC2gakg3aWXBHIqFtv9IPDBotaNIGUQZwbf7ykarc4uAp86C0qYkebS
tWSdR+a+n9uzjOlcRrhy6JSsJZdoPwcDuzPQuCkosQsWKXO92UvtBEhltJahsMjeYYBI3Vh3BoDb
bJ1dQQuxNWXlxfWSWjmimaXLurTER/tPP5qRh4yAl4gHL6PI/yxekW/sh9e/vHqoig0BQbbvCUGu
llnVAnE7tYg4V/UmkI1ZB6DUj9G2ByMHSWTUBPuE4Ea3LwSQg/DCoYQl7VFcotPs2TX1KEVCgKzb
oK5a8xXVF5MEMfRRcgY6N9zKzVtKxuGm/O3ptvxtW/7Wq/zNIs5lNl1yf5xDDpHnyKUYhjH3ErSj
pn58MaR7lCUxrE8w4XiVLVeZ1jXXVN1VEmeLL0SHDvD15GKV98tvU0KwfepNAfsZKU/IEvKXJCGi
ybZYdClXMbpW5BNn0RgXLbvhZFDBjpRidnTj2uuMASHUrX4DOi71ppi5zztGGlSSFvMH/Sc/QQf8
u5XVxr2hA5xBRH/Y8+9BRm0d8ntReiFD9qlqiOpEbPeGK7F3wEQ+tBg0TyXLtxg/LXVBrWYjQwQT
N5b+LDgLNkRJrOn9u7jnjAZnIAcCHg/FifdUO0r01C8PAgufQc6ZmnYb7st20HJ3BpvK6zXxokUY
EA9TmETtDL0k8aJzOXgcnfqSmFxH1FUW6i5Aeo3ZT5MFmzIVbUBuZ1QZsKuwAFJiMyRZIQWWCXLY
AjTgZUtPCN9w8WzrLYhqB7UgkgqQGuCBnidovKfck9qSz11vstUm9QtQzje2gQnB7l7ITHKqVHWZ
Nemtrk3TFoYntV+GTy0I3eS8A3K3b91i3UbxuTe527eGTle6yv3M3VY80mHzEd2YRSkAyMuggUo6
AThfTadxQfmTSgAjnfFZMVveQLktJggiMNQX0WnlGYkv4ossOgmZv+/vi2i1OIUKCs5purTNA5vZ
SaLrn7qAbm9kKByi7oMyZVAjoMQ8ne6aN9s19audCuD6Zq90poXYY7xbnqozK9IFHEFAbBkmBf7r
zAqGIePf0uFTZdiPKaFvlEG3ySa+Y9ix5Q34ZWYNKpvX5lk7w0AiFHHTZjZxTRDl5ipbenyMY8vf
GdQqydQQNGceRjEjjfIimF1Q79uuPbbLyu+Wp++C2bcr3t7BcEzurbuRJOA7yjk829dUrq4WEjXA
wl4K5l0rHmjuKZ4iYD20+Yxbhg/0YTnfhSf7ji9PC6LbJF3nmX93vHO2fAv6NG1OfQlCq5k2r7Fj
uXkPdlSMUUqYVGUrnchJxKsgN1vRPbmOXrMFW6Dgby4ZnEos1Vos7KiczMH4nnbyYrOUdZkjyDqh
r/lOJ1C1VKQBj68zQst/hRxNcH8EDcPrXThBdZxQUZ0ieh6bdk9467mkMcFp4yRrcQNqOVIZiZOi
1FzPdDqLQ/T3oJ8KS36SJGPyPrTIHjuhIfudpKJzZPuNuuUHOJoYOA1bMmmWxw/JPUUl/GabYE2z
y8b0TFeSM4pvu0DVIjvOOi/JXmPt2kLLdcOIoLt+E33wMMLaT/9q9R47TPyXMPu3F+JBp2Rt2Rq0
AOcewX85z/6N/hNH4qF4yM46Pvu2CnS0AwcqUl8ybWG5LzqvyozIb4PIISY/Ef86ZPhJTysL04gP
n24ASjCcNHBd8w34YS2RuuVJO8INzvpT7ZfKUA63DEWOMX6xs0z81E8u/Z1jsRkM5WjLUI6JrUjn
n1Ejb3o1viyG8kA8Bo50sd52UexcT3kotpoKJeq1WcCbwVge3JGq8lA8Eo+/JH1lq5tDlI7nt3EG
7ru1yxGvSXy4IzaIr9/UC7leTM+27exKrNOf2fIt5kRTb+ibV9FikVKJQNdGWsTyOg0RxN4oEj5b
JahyzVRaFjKJfNSjs91O5dacOyGXajxPmasG6IRI7xKpcjNRnUIjDrPRaatuWJmbt5Q07Ka689m2
unNb3dm3urNwguObEzDFOwzbtQgRHUm6qenQJNm2BDXbeYuctnP7gUd3vaxF1sJVXwTsrV5ht6EH
MlP36UOztNATc9mC40vc9nm9qMztaPNzx1tny7egTlPFQ+kh6s58h1nuVP4Hp2GKwQ0brQOUcreF
01R5YeN7U28ZKJJlIuoVlCJvTvV8yyRYoIkSCroz3tlxfPTGMfqhiazplIWKNs/bMQToj8EiwBCR
zj21MCqqK17GqF3r2pN83m5TsDDJGHhz8ue9E/Ee/W5kj5ZmKfWd3N0P+0dPvtoVaUw8FM0OzrxZ
EAYZ6vby7EHKoDjHj1feNTRyymuRtZE8+n8nW++6InMkbG2mjC7BQQ6Kn1I6kObuoNfcqpEp7slk
Qecyly2KAaJQEkF6ESxRsp5d+b4epYwqJigbRDW1NBF25xPCuhw5qKUIO0KLULVjLBJAui+CUN3G
yKIW70/eYY6ADx41Q0cLSAmAkbd+2EjQ1XmyZShqk5pTsMt1BmTXXoGbtBN2ghb0bOp8A3zPp3ze
rmFJLmuNWFEjmHtTV3tb4NxYvwFlsrOsVhXzMyRwhsbW6jFb3oAQZsmeNwC1ebiGLi30AFbqZJLO
OmaxUKcKsaQeKaRozIvYAIYCMQCMf3lTHElUAvKOgceWt8Z8qmMmZcDmaTvUV9OJ6CpL+xPdUPRo
oq6F6pJcsaXjV+saCtbQq8ZH+yEgubPxQ2zTzmA2prrS8KJIH/OI6siNErf03eQFIaDSvICeN81R
1s56rmPNYlcXvrDNt7AuO+YDPaVS1CEtQPJCKIgBfJ6qpENLuCCjDkME1Igt7wyV1ww7lxZ1tZKY
LOei7pB1t7iX/tOhhbeutWwNejlrKcdb8izOtFdD04yg0NMkMffUobLxpVUCswsfxCkZaVfGL5XF
b8UgJt3QlC0+FT4Zwquf8WrKQXCTnjHZApO3qlEF1feyCI3dewvwmn4dtEw/cWlXuAj+O+XW8EIv
Q28Gjz3JzC4gtdg1CG9/+97qWTsFSEEJ7gc9UueIvXwqVOuyU3NeiW/s2HUvdRp247ehV1KGbB62
Q0WiigHW1K1nh1maUzARqNExZQUgwVLpWfge3XOgYrHTT4VYAGi275Yrt7u1Uv6DYBarkNoTVNhc
wYW7Vmznd26nIlZYHdvS+JdXGV52L9UA6S/pLMYd697zIK+2l5T69dCi1MocARjAqG6rVNhEoVrC
Co+G9F5wqmdshNdJYiSj+hbW19RONd7YPG3HOJlB9fBeKhbfU9PHzzLNHq1Oz6qtaxQ8c+8bpQFd
y7jSWw/8GQh/FoRcRo3Pnn/ENL8QzRlkw6sRyf1GtaRoAnd0cHBAugi0Ewxawci0DHaFp3ulMix1
Bjo3zvZNekvpc3VTvfD1tnphW73Qq3qBUay1VJJxCptH7USSDnJAWBN/6euj+EQZA127knpfbVvH
j5BiIOUAcgsEj+6j8Rl7pTOuVvKAFiVKx/3Y8tZXBMkhu1cbsl1a3lEDStuu9GWRo18c4b66s6Nb
dO2B9yUvrIjiMyhN5ZKK4Gkn2pI1ULsgtOuh2lBPwFAt6i+JfoiEiBTEA/3TI3H4lfz9JKH0r3r3
NW31Zjx2hgNuFAdrctdkn3+Fb3pYPZnRjGsaGre1Dm9UF5tBv5vvKm/M0tbqAsO+toVrqndNG4gY
YRuA3cKC3zp26zeK+49ITNQ820ab1hm5WhNaF8jMDhjTxAcDvA38ukWgynYB99IM/+BjCmeSivby
QHi25/VMlzwHhkvEqWAHShHiK5d1gXBLUHxCIolqFxBkqBEkqlJjBV/St3KgNEqb0HwhgPuAYfZU
QOe+plJh0t8wFhZunntDYdsayhu6uNVU5BaWu62hfPbqYMdaUEIT7VdD2UisGJ8XYe+MG7aI6qY+
7KXparEkXmvzvB3eFZmxEUoB4+QTzT+ppIEixXMeUhpourrzJjq94Za7B7j4boG6HdQoHRYDYJVq
mQULNB3yonwG8MKb++IsiRdSSuqgL7uxCeEcudXZ3gfBrXAu7AvxBtENL8GIVwTKk10kFtDId8z6
pn4DBE6apzxPvCuO7JMCnddZ0G6vk5PKpa2UIgUbxLqM0aHhNPRRNAXNlmB47qcNHjEhsOEEWRKH
7pAOL0TDD0TTsvQeaFxdcKlb1Za+luyz1Ytr7PF4b4EE664nDUi+rlLRkR1jJxR0LJhaJfx4deGD
YNWcS+BelC4C2UhFELxIxn6YaAZ63Fk3bLjtFp337YeTe0CQUEuYQ7SLGuoEqryWx0MIUPo2SV4W
MXEfo6mAfjsA8Y5A6sEO8G1nTcC2VtplwUgjgVBrSJ1K8ToAB0oMojMfDSPn1IdFg5Dd4fiyky3f
onA1zYNaU6KW52ocvIU014kvI/PoN6qlSZ7dnZY0IoljV4BEFP30g7rLkhx41lYppiCLn4l6r4La
9IjxEbEzZZGYvQETXWbVGi6OmNnDXZKhBefLQcfu0Bm8RsbYzRMnSo5QGQC8ydToZj1wtpYkbPkW
RtdEy1Q1s3NozwLrYKjeDz2mC6Z18WtpWKT43HIP/d282ac9NGTaizzY+FaLFaLKuFTx11yB2ujE
cTccZPsW+IgFIvNpMDenlrnJXfxmm7u4zV00I1iLvgwjUP6rOQTAM2cBKl5VnaPOfytGY8pMMdXs
iPzwjCk6U17WLFRRDDbze/mAWkDpFVChrnpQhBtt9AwCvy6ccpkwoEmdekPLHvPGgtgfnb4ZkpnK
5cUJfMYM7QywtXfoUO6fKoKT9/bTyx9lKy+6x6KfiFxyTZ4IN/LRmmBc6Oku1KMbUVW3WWc96Oh6
2LVPBWHhSj3nOx+EsMhTOSC/z+OjZ0+foS5HxZ8u/fuBn+vxt60dY2sBx6mgpvYjMroahJ0VhyQh
6cE9wkoS63AjoI+iCovAPvSjeSoojSxCG+IEgZIEX/G5pPpBbjiOjxo9HWJB5BArKOY089LefTPc
RhqkawjOOFl/V4TC2HHHvyYt9PJOBbIogVBuaKxh7bxv25kK82lZYv194HqMGgwioW69GP1dBn8m
udas3l33lfG25BY7yu0p5cYbdUmYWv3WO71GHXDXowbb5p6kJticvIlS0n9RZjTYvKSGWy0Wc567
lMqOuQJm899WAQVdVZWYLNwjBt2w9ceXHV1n7kmsA1wRRnZgB/bSUVH01JZ0gRjjSVUeAvbs3JsH
dnOk0axwGBiagdBbMFXrDkwKUfcGytonPZzwVLvyFHwnCbp4NlstvWh2zXY/CHQP4OjhePaQKJsA
Vh+FYVinTlij+PDY4aeC9V4fudaC7oC6dFHPyUuHmnNZyvN0GqZm6KXZe9iNGCg8f+ed+98mvvdJ
OgHbahJLP70jY4DhTxtS13j18RejfhXpGVvv4/MUGoD/YkeapMmlDztHex+fHH3z5Junz46+wUiw
++iCJP6/dfYkCSLX2fUSOGCvjEivyvjOHrOskMneBUkX+pDyAJHPzooZNo2OqlfF6hU389PNk+J1
zcao0DfhAuVyXdky5gumxPSqyww/Mi1Yt9kya93jw12r6tU9E7Nx4uZzgIlt+kDzqifnWJFsgIFo
/OtnyxtgbTYZXSbscuqYhtLcpRpDRe4H2GoVOPUJ5h6FlvupsXIzX3revaU6i82NRylauo4jn61t
5AvS0aFz6q6JG5AX0Bv9tEux67btla80qE5E7Wu0DXD83ZjYkbv24ii8hjev0X98fHbc++by0nN3
F/d7kGVUCwurk7xcqC7Gd96SwiVJgPagmM1KdzsX6oNs4QnBzeB8HMJlxYUaRo0iKO/SwzxvqirG
r678MLwHoo3dsgFOdQliqaRPSXNDY4cuKBi44zYgNkJATPbcoObPlCwsw2EeRclmfnBZy9Acn0HZ
4EzTpEHzpNBfYE6EHDdu846aCmbWBWUuR6mxkLnnLeJVRCMo7iLK4Ow63CSvbtJbykRaJ2UZXx1s
yzK2ZRm9yjJsuE+Tg7nWr2QEgMJsPEYKoyufTqr5vdTECh2Mbd4ZuymJs4XP6lAZW96gN5m9LKgV
tXnQjuUDLrKHywrRSfSiIp5f1BbUCguEeFmITbgz2R6mAjtSvNnGW6BuBzxkLMguXpCTaFmFTji+
t5B9qq8ugtmFBGbhLyXIdq1c15Mde1o275LqB76HhkHfXLkW1lHEByigkC5QMy5b4ZA5zvJoJkqf
xfG6SMVkTN0DSxqSYT2lJcqWllXi8OZ1Qdfktm1BSKChLs9ABhd78ebxG7NAdRm2KEK3B/U8QAYa
g9ip88Kc+U/MCVLEsMu0FHbwqeCE27ISX8jqui8hLaW3q3oTY1xTI75avEnoZNo7JsHeOFF04JRB
BXYKAwc16AQtQkt6AUkjvwu3Vsf4C5FHn/Qe2anHZ5+9766wuFF2GLrLhIZY7Q5Zm+W81KyE85BY
HuoSMiimo2KwCKd6cSyaxw4xiOaqYUGN4+awGFtzQhhP0Ty2dzt4Hd8Du6Xr2HXltsvQDyIER58H
8xc7h9SVyFtlF3HyYud9MPvkJXPx4ff/939P/eSc/jZH1PnFztHB4eO9g2d7R0cnh0+eP/n6+cHB
f9+Rjjh8hJoavX+xc3Dw+PDp9199K3+fHfdJYGl9GU9hANLiBKUf8Dj1z4t4zV4w7wKXQZLdk1Bh
rYsPDYtBUBytGWWTUNWFWzrOqhCDYRmHd+1w1JmQ5GWWO9QOPxk2w2/gaVYiAAdSJyJfILvq8ZkZ
W76FHzXd8+SGgWcpDP7eN8J4XDd/q/cJCqjYiWyLU4EQWp7757XwcQt47XzJwCpSSLmd+LhatWBw
DU0SdDgm2/cgsBX+9Tp+cb9U0X74vnX7MBy7dEHJ0Q/wzsXJQtKx8E7jVUZ4xi5gKjRXPSs7wCAM
krJFpefHNENqDs4lLYXqcsSxgFEStGzpqcCu5podBLFDcKWs4mqQoi8NgxkNB0drGS0pc5am4mJr
UnJLHavN1Cd7Ef9uvFLiCkemU2WYEH/XigfDt5aLa4pwXITNg3bCyXyj3UBlOxifVEh8NhD1L+/e
ESlLlXMMDHWTNmSH5wzeBlTpb4Yd9THDvjrYNDNsCTnohXuMtd8WaHlgJpjPrJ4sKMxo8xZ/zd+6
0a2W7ZAQzLYLMGb/3EshTtF86/CpzeM1wLVx/1/ff//qydMnX/9GKZ85G1O6kPavok/KNTIpPwvh
q6RKtvr4TIst74CGc8RaBNFHZEkR+n+sov/HteBxy3Ug5R0sqGyKoEYFS1PxC0xYaAFSzScy99NZ
EsCnUDPK4WtYeqd5XjNDms3DWTO9x53tpwx+sBagke1srWh+8/Loq2+ekkSTnsHv/DNvFWbkIOR/
qSdELt9JYkrUl9JH+XiAcIR6gPuSr6R7o1cb7y93XRr2zP8i91zxc7bt+YnbPTtgVCU8vxqwt1JG
HSN/kdFF2x5rouR4T1PaXr+qDjOKPudSEZcsXcSjXLbE9ds60XPtzYCgcuvARPLPP3NzVzW/MK9C
kImofvLPf/yvfIKqruaA2ab+Bh+sNEhhwFMrKTULOk/IzEeJgkEo+T9D81N0TiKXsvAjZIRS4qu+
cvU+/GZXzmWlIi1l2T6SpuAjK4RqWmNX3qWPwaWYk2j1ghpGmhGKfIPSZ1g97b5sPlZk7hYy4lqe
GTDIYYnMgGsU8yfX4grzzORrUj+TOcB5W6kGRHKQGW3BXeHvn++r11RKOyXM8Fsa6sodAxjKLNNl
5X4THy4qf1cswIUDlLagWVKGhrVnpYi7xjBOmjIpt02yMFG+GqyLKejaF6EzmKHrBIvVIp+jjvc0
z6IyCzQe6QLXXZiF+iVWF9W8aXd6llLczHdflk3hQs+CCOETIEOuTrGdj8pnvh7ADDr4zDcDXl2R
Ca8JXSpUIdGK/AEajCB4D6NeF6dBpOwEQp8kPoMjSDzQH1oi6XbpqYoR6jsD4KcZGr5RJEvjzz//
8b/z5/ZkdcI///F/ZKSo8vtgTr8k5Fz4qKpNZa9fX+ATqFVL9s5C77zyVOhf+iEckewZtW/UtiGL
X74+liMTEL0BxVfbPatecXg1+uvxYGWbWGzidi0G1/ZgjXsdV84wZPGlQ97JYJjui5eYvSX5Xozm
z+WFSK7187uTNz9TUQSkjewhRWNGUfTcQKN98fMC5dGEAA3Q195rfB7ChgKgEhdJIVXNVjDgRDVG
jOnlIPTq9mYzDH2QGKc+kwKTRLKC0zLnusslIcIqQwRciT2IAMYf2i6xefuQHFZP1q+fqVNKPqX+
woswn1oyeeBkFbXNoAGFSpERzDIY8qp2s3oBNB8jvYhX4VzGk6lxXQoRL6PK+tKGIT9WvexzfjMD
36seOUYhahLIe+TAgIgn7uOnqPUkyAEKJt4F44cmfsuur6U4l8UBadb3ukcXZCqUp0WxIrH8qnG3
qrgGpHC2CsGM0S4UmFwAA6W9+/ygo8q9Qzk7az0K9mGvDJiq65XE3w39HI9PAEkJfE2OVemzS+Ko
iqxEaXle5jX9bQhL78XRN1+e3C3DbWE4JDYop4OMWoF2srNwJTkOdJqKsJEcJ5c0D3OlSI3YqtKa
LHLTKryyIKxYY1OojMRlijQBlGWcXKxy6VgcKTcvVFLKTz+fkAzJpcacTEDAThbBSy9Tq20CyUUf
6AkJJ+K1VA4a8dbxvA2HQ4JFHWbA4RBfW2kHmGmEGOFm3B4kGzQCqcWV1nDTqqdP+NEMg+/nVQPm
1A/jK6VpQVqGhTmtbf8C7+Xzn0nBoAS802uJv4V+Kchmx+tDKK/SvkS/H2iTpwm6rabiAXj/f3ZB
y+z4/R941ObJuib5cF9I+w3uAdLWzfCgTaeYiZogL1SeCcbcwqM+RVAGccGV4+E3udyD/0F5EpQ9
qN6xCGAIhpibU77u9xUUKjAEvAieE61u4iPwP/3zH/+z61D1+GsemzlbZEurR2sAMWMx3GTiw3fv
BPxaGHhNOH0jvGC4JnCsFHojjNxZAN3xoYKN9htZ7e/O+HvlUktTHvj8w+tfXsmbp4ZVF3DC4Ydr
sHaZvJcfMGfbPPPuycE3X+VSMkWfGGDeAOYwkpArgaDEHawFNTJQUS+dXI4IJEKvf5asB0qK0N4L
6enQboVTGChK5NMrlCdBvZk+XrwqbQSv1yZzlh+yazhkrp7jpC92fgzS7B0IHtxmebEDCXL1HINA
8yhNeBnqzx0Uf3sz1787pN/BWCgeaER3Dp2HSgCW3Ht+6CjUUWjsjEzXaQONegNrjF8cOgpgaBPp
fl7AGh27h448u6PZofeFqo7W6LQ4cuK0yI6HXOrt/MXrvNWGSDlao4V0tG4LqZA1UrHSfE86DtCa
WLsrlf8OugHcvKvQo5ahebpKbmzvksUiPQ+5f1spLSpau0Ee61K/2Rdvzqiium/4ZE0eZJW7Ln3E
heOJDB0mif4/e9+/3DaSpPkqCP0x294zbVE/bXWIEW7ZnvZEu62w1LOzu+GYAElQwpgkOABoWXP7
Kvca9wL3YvdlFgCiABRRBAsEQMvRbUuUABSysjK//L1jN/+KaM9FFJYT6OcchaC1ZZkh5gVYViKQ
IZgBWLMBeg8S57xA/VssoVrErNiu4+O2zVo2E4glZeor1F/h5LMlNvciAwxxTWRvCLNidVsrnTHQ
InnQoGPtqEZL5MiQJUJmcrKJnLETpdfCGsXEYUpAEfkKwtZ888vv7y1K0j09Oj75sjsDMq+SjdsY
uXzvrPcn9wsZb9nKTDwyZKTAtaOlFTJ+ppoy4qxLih9pLSjvWDLyKpQGgCVcRv/+b3xNqqknvID/
Ti7O5/Sz5LNn9OtwX/4fadW7xY7GbbEN+NCQrZbQUyJjAUbRTwC+RGa5KO4ou2f2GEZOWCTFa12Z
OxtaV+UZeOO8+7X5YBYz688Js8Y5Rc+k1e2UUY+N25f6jHpsyP7cd54qpGiGwxVo9NLq//vJ2w9/
/nBr/Wz1e+Qwb5DXjBvUhZRJneKVcj42Y3APWCjG51Yi5ZaC0VpZ7C9X1tjLbUwro3bNdivZzKox
JwGv+ufnV4cHFGxQ1VgcG8brWPyCn4foQbanTfzR21UxS0FhSLRoDpEs4kuo8CX6QfxR6i7yT7Il
MeuVEhVev6P4NMWJqNE0shARl6Vk1RzUz7+Z/OTPWmva5Zvh5TglT2QAI3kKfc4S84YiyiFiisEE
ucLfXJvHdP4EQ8c6Pj09fJazItv0+maIaOYuq5wNM5MO+l8k0Vp4pKowXrLOoY9DJIaRLjA4OQov
4pyYf9S6pL4PiHH76HXXe+vbE3Qm4j80KvY6ylt/z11BOKzLUfLoV/DPX5bgYzR5oJ5a9RDLDGuY
uUuycWun9904SH5xw8e9lGI3jmPhBXk++WsK8JOY+hv+tFpK6W3c9RIFXqO47HjEymc/dM/11EG1
PLLhScPAbR7vYP94z7bwzXjMmSgo7Es1M7qwfkeVRZvlkx6DvqfKIud76AAdES7CfM99eK2P9ghp
Vl5wXxqHyng9BaIcUMGVtLlbGUEM0ShPcl/I+2n4DwhsC3gadTQTVIvR/IdPH97uy/tdo34HaZV/
smeLny1UC7lTyx6PKVGVRB1MidDG6xPInix9RBR9STRIjGMMd+0SbxB8QxHTGCl5AJEX1tWnjx8/
/d7993rDnVwvoKxWkKN/smcK6wpTge4Q5AaX+h5qLvz9ABwf3t2+t96gasR7+VcIHs+6Jft24aE2
IjIqkNbo+V/J2L/zveUCxvDUuaM87HoYV0/BwqKRHq9QJCnfXqyCfG+mc6Wev5TSHj68u/lzRzD1
4PzFEaeRX8cuSblYq3tSlSLTSenoxz9ubi0U26LvAKeEJyFrTJCTWhSFVHQ5c2Zeh/btRd/6iC7u
dA5hzMUG/y0Vqq92k02Gt9cSg3dzU2fOGP41hnjcCuPlr0dnp1QxSgSg3QMtoEmBGwCUpmMaWMSV
IDdAE4Dc9VBAQza95c5OXK9vXfte6KHaxPoJpRvPOCPi5PTs7AsVm4hU+857TCU6awthj5ysBi0B
wSxzqpOP2OBgdnnAxTJ0WKhwhmXDEDWxpOQ6cuwVQbqqqs801blIjY6jRHj7sownFLF6P1zgUGtd
nFHOg+KtZonxE1S0dE9j4lBDGFRGKczQ0rIVZytDCQXHBMshSdJ2Byg06KlDkTzkM833qJ0cfUVT
93AlbRpk+liwvT7En1YLNjOmtpm7rJjNTATq6CkC9TRre8M4ejukmZW0Qlql+AaWdYBcGXLXij5X
B89Tn7hj/pYTUKR36IRqpQZc0qr1NOsA73wQ18XQ12X3UKAcKlP2vWowp0fZFsg/wD0CWkK8RSiG
pzRJ7hv72JMW1oktiRpDZubqbLAvwDe9qf2I9mrMm1X3pmotz6CXXcAWFR3VFyG4s8ntF9Tf4uWr
paDx2dzmqZulm8VFNNs+drQYSptVwPAsRDIYf9vHjpt57FCemrXJy2pRKY/7w+9aF2bJ20EBOkMQ
tOxdC7LuiZPoT1V5GUABLXqpKeRze7qUPcobbPPWKymjQOFhkndbtdw8c3VpivDwMXQAGCT67BgY
bMxiYC1v8s5f5d0VZxR0aRuQCy5tQQGzqQ7pxuRLZbJXqwHst2vKS7FjKz3zQkA/K0NhBCuRuUk9
zY+r1QLm6fDWQXcaaewoHnKLZJ/iNVKLKl5V9FsDWqHIHMUnKT/ENntcrZQw/24ND1QtneSzY6mV
YaacTMraeLlfKBZaG1eJFd43g1uKuQ8aPvMSKclQrehQh2uI6TfmZ5L12QoIOh9hhaEPqlsVU0nq
ZnwgUwwsB5KlzukDN+YV/XufJ3GlpLNkHICq7BKu2jhOjoLU5Ale0aGYkownRQXFKvqOcK2TNCTk
Xuyp6K4I6aLfgIjfIvtrJnFsy4588Yk2OfUGLVidmZttUjhFOzSKZSZUvRTdNLjHW02bbdrVrmQZ
acMVsCgPwU3HdRJHaELjoIIQExJLmEbftnAslNEkq3ui/Cbx4KD6g6uJ7tRbay08o7wGshnWsjOf
JXWhOs7z52LTTSi8b5ZS0Ojd0EASH7RsRxVS3JfWrBBEmQ1RCDW46r85j5zrSykSlCi4OSASp2oL
QBB4Sx8DTOwQeVPDJQLW0L7g5mRYn/S+ndijQJQ0SQvfaqPOXnBpDberOT0/+4LBhaiiw2AKaIG4
zZmAKwRNMPToJ/eFlrMtLxBeyC6Y9cve8W5QFWF6+g3G1lTl1y1135bP3UL1Ydu3e+eNJX6ktA/Y
jJB4esfbH/XHH3qYG9Y2U4Z7pMXytEkiSc9WnN78qeeeWDqX6imWlmgSiEmevt4GZpGIu+ODIz1b
myeojbvOlXosIVJcnxPIyE+6Ulre0vN3TLXY6Cern7ERVX3NLDJwoXlTBnCqTT/SeWEC41eaXLj0
bO3tTgzKS53rM5s+SBv60amLpWGquXtVzbU1upReacd8JD1bezsSOKxzeXY3FMeM+4Rg1ps3cnlG
RTJ6gXvfSg/qBI2E5SCtW0HfDIEU9hC5FdL4kiwRQtg8nqotOk16XWPbZNiNtqZBiIL2wimLvz/M
hQ2D4ReoSA+pBJXNVJ5yCdlbVYZsifi3NTW2gPxgy3o2Xc9RvnXOQ6+6ybGaC1J127dWHWnHxBTj
jagsCkXvy7BRdyBtisQUCsGXh/repDfMcpTiYj2pyc2muBg37fqn2T+i4M1bYJbRHU18mrpfK3cH
v8Vtyl6YfaCZRTfrtaVt4pLlXgBlO7rvfbz6I+vfEl2I+/3zL10PkbyZI4aGxgnoKwJWEA4p34nG
iHIDHMLSVOmGaNv+1BfSJlvW7JLL9qyT1/3zQ2q69vLNX6+t168kpjWmr7VFt32pV7NW7G2+yKx/
K0FBtW4vuQSocZroaIUdUATBFK5fQO7Pze3PDVNFsDH9LS2kYMsrxpoqIjCtiNPln6bhz+IAJoas
UEFjO7T/dBfWRF3DuDmk7gfof/AHNV8Ro/FIXH6aoNXWyzfz4AH9Zj4ikXYqbZExqWL6bZRYn91y
3P0PmsCjt0MUiqZRc7dKgfpYT/CAQ+n1KY+4ptfXEKoUgjk+OjuR6F9wRIqFxxeLwKPOtRkUoyLk
3LnzQhjz6CbAt7bQRcId2eSD4v49yJ0muzWq5EeQT3q2Mb7RIJz0YG2CTV3MnufXK03ZJorrUY3M
fDGqHv0Zpo+t7pFj5kS26S4rXjFT1Xr8RWIt8zz91FeVhmXlezWnK0nbyWAqqVkKcIqlt+lcrgSo
wE4W7fQeKQ3Djiwn4QajZl4T924pulez74H0Zs08r8gTFxBRera2KKepSpjRxoBX5w5aslxU/kLL
rZA0qTy0JexRDS2+jsth8WXZU7OwNgp8b1UNKz3TvGyqYZ/Ab3H9rrR4xUZrbVMuwTuH6RW0r1Ye
V3zue4QcxTjushdTrEYYMEZqyRCavuVIaL6LSle4JCWVKEqCxkaoGq8C0wY4m873kbMAaiXfavrM
cucQCz2RgGeb7eZXxjPFOiN4nIEuPjD5dPqocwut8ySyKwnZow8ibELYTWMPDlYagxklO1SVdtVL
u1f15dJ7doKdXTnCso2sIxfnamd+tpCJ94Ljsau9YqZ2XPyWjx5x0C/43wKDdI9uEjiRlr8VCVfi
hLoL+2iCiGAgEVVOcoxitdJzO8Fu1OhKWrUetQbPgAbJvR4600eefomO3UShGXWThMudSJTQTgy5
hKMdP4NgkJ7XCSoFywWFlTJiX5NUYoJqMs01hoHPKPQw4ja59nDqdD3iEvls8zHzW3CC7/xz6eLw
oFM369VEF5EuTRRGk3yh42wu1qvsuZGWrscXxdCQyROziICIiT7lJ/Ev0OlC7imENgCyY8+kx+/4
RFWnHKD3wkHWuFMFqinIRx41VI7borvPSgQFXT9ft54VuJC47uTRgtAYIycSBjreFkn2o3v6Rkhd
nCdJFQZC4wcAxY1xSTZb3povZ0MwLwHpGKSw6926+fXTH7+9BQIJPILaqV9obPHSgxVHO5/bINCw
zrUZmA0TJFN1wlF58vRTsQVJU9pLjk5IGWKCptITdykJpAdrkylnSimuzBBJcfgjvCtYiaFtASNF
4DdruEjrbz/hItvKoOSUCFCwDQpPRFUrrXgLpdZgYHeOzpG2E+cpgQrN2ZYSmdrPJytTuJJhCWmU
oj4fKap9gYYRliIUrGhkya3HU2K9Y2Ry59KCC9hfP6hHBBMiaDmf8rQWfCDpZEL+SE8ahRgyR7/N
Ah1SX8gvaSXt5zB+VWnNW1EPNiSRJEOvtCMjGjLpUqweKZCYUIErUGmY2cP2Uw7vaZBuRA6Rp2Fb
YyYOWVs5szPCEJE8/fjmP6UlmCdalfxraUkKbspDrkgo6VysByeID8vuZlgryr0xV+aL5U6gAi3O
UxEmXyyDZQRgfv/UcZ0y0hSbyzNEcF3Ky7TI+OOECp0b6e2YtfCo26tl/SQSd6zQmcFxg6l5VgC/
d2wVst1kkWqUHt1+4nHXVnnHFcdDi17PmBASDQpup2Dxijl0IpRZjP5IL2YrJIUmRQ8H+A4TMMOu
RGnd7d+7KPlYWnUBtfVxRmTtFKQaQsZ/EC7Ysqftdm/h8KHVks0vLaz9m2fLC95q35ijybWH/6KQ
GdQwUkSnNM5Q6qSQiEgh2LoJEGEhOiihMhjXgtvrJXBidAACwjlCKcYWo8RdBZulYPuqtmxGa7uy
hG4/d9clmgR/CxNSxMtkWJ8EiALRGA6mpbRz7afc0CCCj3YhZmtBPHD0ZxtA1FdTkY2frC3RftLF
wk/a8YKzqq8QH9zplANKlLohpE7kJCdpATExpm+BMQjYU7yS3cvZNOj2Uy6711sRTagdynmP4Xik
a9gfMUa6CMKeMU+y6up6JEUZqWRnI9RyGUcqtAcTxynNqeerteB5xMPIpkmwAns6pPXtkl0jyknP
VzBf3jynMKbOlXqkaUl+kTtG8kOIgFw0kxmTRWCntCAbpHpUljy5hjdq7IymoIssRqyhTeE/lIuQ
OBbwIJeN0gB3U8MyWcRpsziyB9kaq8DmA57Y+Qz9XBDSZYpY9pByjSLKyA5R6QEN0Eh6vjZ5VnBP
53o9OcCNQ+z5Y3zmeAYqvAjiTNpTZEeMHzGEWTCgvK8NEO6WRukyTnHmlPVDC8VQ1jElrM7Q5Yii
kjgOxT5wiWoNLF56vvau/3PpBFQVpnO13p6DhHPngbLN4BUFAfE95RfB1U2WIMgpWRnSc41RrZ1l
JmbqmE6e6piepvOla6pWhXIKv20EDMsLW4pjApGYlk6qQr7oSQgBxYHNAriTkTyQCogVBaxn9iOy
jaTHGxMUddOulgyaxPdwC2gWR00gWGEiUi1Y1lbsJuWE5WtUMwmlDnstNt2gyD1rGbpT918ibTwJ
SIl41LSjXDe3w6Uvr33LA0s2biq8WRNSM6O2Nc60dCQUpMnbyDXWdZYtSOHUMFdoplAdZO9sszat
azNaI9OJqWB7FNTo0vwsHmMmUWfHOk16dgGNi7HA2AlG6L5uULaQe2GVah4Xp4ic5NFXJ44dsWuN
Le+yhSuYo4L/rxM7YrJNCO1F7Pgnuy12ypPHnn4mVVVJZlxNCkFDlAPclnFEMSuzsR9BT4MeNZHy
JnxEc2qyj+wWbrEiGgITGaU2PdLiO8FxWzmKBheoMSOqILkyWI7uV0lUQewHYtpJIqF7NMI2S4tW
CNiM5lMo4SilLI4klvK7OQkYTwdWLCwSC2mRwW4zoOooraBRucARo7FjczEOuyIJwopQbdnu7IyG
aLO8nCGIlOxuTE1phZ0QDOQ5lVa9FdejwCjDTJH+ceYjNGgYQ6pSwJgEqqSKpBV0gm5DBy8iLXsr
wkXulZqO3s5stMRrlS9a5TorEYBZKSNrVYCJiINEzh1zgVi5tALFhuZtzEjWE/SSK7EVd9DTINbw
kWcRiEgLHRsL93dDfMpyUcCVRqsQk+2uRje1CNAj3CDVgOHRojAxrElnTu2WoiCoiyQVnkBV08HS
w7qCTCLpiHTGHK5R2s+ht4SpDsVL8jDtRRXqjgsNAlSjdvZg3NvfDEIqEIr0C9r6udAk+M5GygJF
9tKkE0WIgr50Hp9LrNkhoWIbtG9AJZwP6oeY1LpLZ6+m07EztSPtsUJ25MW2addgYZE8ju93uSai
YH0K4DotZQG+MKNOUGC4zTM3nRkZNVLb6qGjxbBsC82/6bjyQ+FglZZrXqpUKfGClpFWVcBnxU6V
LbhluGFuHjwE3uSdT4O2KTHp8oBWlOFfhd1KCf0Q/5xgCtkf5Z9Yk6XPOiA5fDSLIOqWU0YOxbF7
8jqy4F5bVhQbvKxPksRg7ssjTwBLCpyxdwsxs1zaFvNnR11eV/mEIIVozilk0tIVB0yPneHEBNlE
b+dkHJRFDtzqQ3Cc+ZimQJUtslCUHkR5csWv2oldSpmVEA+mYx7C3Er1rBa+4QeqkxY/06J7AQzh
DukbCtK1hxN5XNJaCnfv6PXpL1evDyCJ/cAdf37rTNZ0Ao5+Wc/ckZ6tOCR5MsQSRedqvSNmj6jt
pBjpk4ioqKypruZFRKHFNe+OL/5x50hPvMAQiINjpra9DO89//Lgszv6avtj6+Yf/+//onPPHe0E
xhlAJx4d9o97h+e9o6Pb/snF6fHF4eF/HUAkYxv5nrSddO/CbT3un70//aVoW+WfcDJS9NG6RZ8c
0r02XvSJatEgRUKQk36lewuCaPCiDivlGLEYfsBWkO4G2uM9aA2p1zmq9DqCVPw68WG8Bn8cHqZ2
JxzcbhqcUN+r+A0JUcFF6xf2+pJfvuBM56CU+vEDPEiipep2q1Ouvlnxu/RIFUynzrQHWGjtAjmq
VzioACdx0NU3LH5lyt2NRWgWlP1qfyN308weU8E34ncCPHOngHQRXBw6XjhgA1FAC/9U3LI8jmgJ
d1UUK0LHMU7FovtDrlGrtLhVHAHxJZxxIgzNIZMF450kahLdcbKcYlDOVBSRpfsaopCBmZJ9Zewx
W3hB4FKSNyyAeI85DwzOILzaZOKOXPL+jZ0733FEm8iR5wN3LjxRq6bFeWmhoN6IAdLL/x4sQEZ7
+vfAuaNejEzTv7vjujncCh7xsO8WKpy5BSTD7BXEpuoyHADr5vqGmQHE4a6G2CNq68JZAuGqXGR0
73kcmLFX24f8f+r8IELjJqlm8vgPpJOec2OxiDamJtvvznozL9sofXu77E45iU8aLKwo7fhahWCL
KsHi1tew9pGDjNzPyMgfO1XdawubcpXcf2l1TEkbTYUcddU/P79isKSBp6NfZqW/7t05clC2E8Ve
nSGkYXnppDY/oBCrbB0KjuB8R61rVwpf8FLVje1OTmExy/c40RAU58o1LdKlNZYgnrk0UziUoU+k
Zez4BNCZjxrAsToDYWhJqPCaOggxobyP85xjJUdYSPweX/jxprkeCJVdTjx4deYC7pis86IpGeh/
cOshlCwSNUBZaWdVYDzPYNVw7TppR+yeYFggPJenRUvL2zHjSc8uIE2x6HVsYGzRTVrnBhmxVywT
IAwQLhauJkS1VziNYLZg9idNWLwdQhPCiDC3GYDXOY/Sc8TzQ86NpP7bnI7w+d3Vp48f3/3+9t1b
WCzS4zvByBHmkhauOAV6TFx2JwWE6I5CH5DHARL2PVRQWkEJ8wuRKe6xBI3ETQ4abGtUWTFR/+ey
bdRGlZZ8QigpEM5ouAxYubDTIm5umE7yoILv8F5aRSfOU9JEVFr6VicqEW4QSMlECNCHIlaEfiR3
jDCZpId3gm6xs0la+VZko2Sx5fzr3HuY57wGC8Ioi9jvk5+NWBIriWw7M96C/bsLEZfjI2tyHMwU
3Z8+Fd0/Fd1vWHRPejvW1SKJEAOp0WoxGWHNzXZpCLNwnE+86dR7IEXFQ4clAbVL0So9WCEZ8yYc
pwTqXJpBd4NWj1VOJIw6E0TnnfPkMp0wqC7NIxd9NDaWcl2RCY7MKQRJnGgmqrT+XfJZZdgYr7/S
zIRikxgncDULdjXgSaJNwVFQ2BiM1r2F1tWZ41C8vB6BWbhxcGNMDNK6b57lqs1IHfA4VHIfSo9t
GaNkN6IwOTBPEhOOzcJHae0qbLtyT3ixH+KWZ8KKgihpXwqYVN+CIt8PBlbBI5SeJS3dv2X7Xkyd
VfaWtHY92sBFLXwVpIlXoiCOinLSaDIhj+pYf+ZIqPSkTlAp4zHQpg7bgivnqmgObEVjSpEZACFF
c0o5aPxDc1KxLCe/TdmkUu6Tlx7iWZNhqQFvIKJ+90JqjwPBEFKDPJ5zB69kknsRHxJ2HX+iUOHL
N9w7HQepe8ciQeXS0vVOh2LHQTTqiLo/40QR9EnGHZJnaPORhxJxdykupQcrdrUAKGQHNCqu1NL7
qumAoiAh6pvPXsuiiYvSC7SfchkRsBXdiNVEUG/9GMY38fCG5hvXA0lF2tBKagtZulvxmE2x6xCV
Ueq32Hh4FHk6GSnbju24GjxutfkQorT/8jQ24dyvSTuacZhq6FhpgxVEyssk0y4E9jqxDo9LYVFQ
Ra1vRQAyTXxRe09tgZZz9KAPQukNdimUKltQJmtipx5MBWoyTvKJ+0ILWlJkwBs6j8646xx6yxke
fWvqBqiCoPdkHweqsESaKmXQUZIo/WRlfeFbgMbIcmqMRaQHa58us5076agQbb7ZvustMVnemw1d
tGlERg6XGLLQp6lDNHKI/h2virqk9Zs/W2tiJwo4W9VpkdSmldYia7ss4EJJWycwUx6owfR0OaPK
EBpLFsEpiYgFTJB1IImiqAGihd+0Ls0AP3nmkHQH8zto2jedHGBp3QVE094m8kGz44RqCqPuAUjK
EuwOjybvVCRAhfKJ9lBaQfspVzUIojhoIBHnAbF0oDkjcU5bXSVnLUc8kRaSlelWfGl9oMxPSY0l
3C+q/RQSu2OMKThIWvQ2dIs1FY7uqvZ4Jd5xoJFTw/xKX1CuYdmja5G/0kPbLz14fmivUlRrAEV4
Fak9Bl1jj11OLiqVaEZUlPEMFCJkbiKDO0YiEofSkvW4eCCLDGOsUCovperLOA1ofX10qp5Drv71
38OXQAXAdjBy3cuDK3SjQtDS+t15oGLR+zfId8t9Ogrkj3jFKP29gsvuDgNNuJr45LhStekpF+ay
fXvt48Yga3Ln+Dv+N36PmAASVaLr+Z/63vCkxjdErZJCgVOAT+tPGU9nxWNh0DHtImiQ1Kf1knpA
paWb96YopNgKtTdIr7N66aVgzV7vf0lMpyMTpXMbU6x90uy8RoISmaKeDDEBJKrsRpq9qvEN9aSZ
xDsKJdwSeVStVYaecqMyVYGodAjSBnFzWq0JhzY5isXNxeYGQHPH67RaLxFtErFXiTTY8wrupQbJ
Uq0niT5ZesFy2IuNIAsKyrL+RzpW+6OjTvcecZ+2AHFLzFOgpDqEqk/rRtUkivYIVZ82g6ofXnqd
0nR1QmXCRt1ScDXDajkoFCm4PdZxdQLvVthhZ41gaeFQKtNt2czo5nDjWd1wulsG2FnNMHoPDLCz
OtExqSVyIXZKNZ01gqYrlBo1KGZ2gZDLpC5bFG1w85zVjH9VWGZ/4cxZnVi5HXCmZvxbrJni+JjW
0Uq5lAsDOqmf+w2KojqRb3X9VUixNgir82ZwdMeM9fO6cXSnENF5zTB6jYLbXx13XifwboWOO28E
SMc6rvTf/wFvJf9JGnF/Yh/ndQL1djBZzeB7HZCSmKYg5tEev9B5nYCaUBLwzqrPiQ5dWoGFGgXh
soC6sqy/Ia+U/76WCLhH0qhOrN4KafSqGXTNrCQxTaul0au60XUsjTbN727OjH1VM8Rep8ZkQcTf
7aM0miILGxuM8byXB8G33s07Gs6USqPGz2jc0ysDuJzuW/g4CCmkbccJ2yIxPP6uJenbrxpE7WUi
LJtEskO/U+F2FnCPAcBdkXsIhlFnNS0iNgG/dEloANFvQcLS6RXNoXpdAhoA+1sQcDK1MfNe9eeq
jD3lQtfdaWRd4hqwGaoTV6XG98500N0NAxZFxd2I7Y3ummeaNH5twKb5YWmcFOlF6PJ1naZPzJKA
JbuTm7k3rNmSMdNk/GzzJuNS7VFM39ZVZL02YL60u770db0GypDOjphyv7DvnHiCr7DOSI6tGzHQ
ER4xYKS0nEcM2BDKNyTbPgg/OzQk1Rlfg0l+8R37K3sTwgF3uZg7Ye+tb0/Q35f/fL69tq7tWtv6
d4T1DNgmyo2J9V93IVlOmRqwNn4kchkwB0rJ1Si66h8aQOPKV4TiU1mYJMZ0TPd2ZIX1D+vE2eRp
ixsx69CkCWdbVpL0D2vG5esYRyjBzN/7GGPIU33v4Xj/sF48vpVEygYMCtMy2yKy6kTlJLK4jejG
o1JiS1fCl2QHgdf5n9oaCfUP60XxIaY+rma9dEeQ1wmhSxDASoT/GNJ7F/C7YTxZJ2Qu4SadI9cS
4dyvGXYnCXToVrxAr+KhO3XDx17UU9ArDeo2FTXLAZ5+zcBbDTN/CInUrxPFx/6TZiVSv07IvEcS
qWbYPZjZ30tzIbL4usG4U79fN37uVM1Ov187eO6cC6TfCuRsWZ/LXWmtOlh1omAyTD+XAUGmRiu8
aP2G4LIWhVqClY/qxsod4pejhuBwp/ilTkzbMfly1BD4lZFedwOomjlt/SMD6HnLpLZmrayjmtGy
2k5vNfjR5h8D6Loi/5BE23i++O68+NoUNADGt6CgLPBaVS6nTUEDuHwLCs68sbOKB+S/6nqmf//I
ANavTl+VAN27VP+cC/m4TvuhER+n7ok+NmAtmOc4Otqb2hNtDrQf121vBHj7RW/sLOzR195wOenN
7emydBCj7OQoJGArXCDHDZkoKQ1zvTlDNumZPjZgbKzL2RvIDSMKwIzMW43SoiG7o2dZ+E8mVHfN
3LzONGCPKFmsEZ2Zf0UDBoPyFbeMC2bd9YXSuyXu2WMDZsM6Og5Y/WkBhnboMwMwfy09Sk3NLPc0
KZ9P6gTf5LoQsKg77HFiAJPvEXvUjZ0BlzvEGzVD4UFv+Bg6pZZDa5K/TmoGuiqfSHdNg5Oa4XCX
TIOTOjHsGoC356bBSZ24uR2mwUnNkHad3NHSVino32bT4KRuKNw18Ff3BM9Bp2yD2od1dgr8ndYN
hXsje1EmXVoD/WqdsrlGeaegX/xlx9Ir657e2aX0yrpHb6oUedkxa5OHpu5xm53ilzqx7Rqp0yl+
qRkcd4pfaga4Kvkiw7w9ijvVOpazHcZl3TM1VTxDcKZMzhD8S9mWTQYO6p61iUGSdzNnHqI41pv3
utPZvV/3hM11/BNDYvHvdTlDtQno1D2Is0u+0bOa/cQqJioTQK3il5r9x53ilydg7C19dMO3fnce
igc99M/qBsZytlGr07LOGgLGXZIvdY/O3Ey+7JERUeu0zXYYEXWP0FTpbwJ+ZWesRUZErUMxKfso
oOY69rQnGRNlBGoTyKl7qObAHY+06JHk7hUGNJOfNmmS1jr9co13UFhb+Pu6/PC1ireeALSDQkma
Atave2KmSmBrnb2WuHzOnwD0il+eAHSpwVX3dMzNAHSz9fd1z8DcB/lS91DMzfhljwwuEzMulTnt
7TC42jzGskUG16ua/cqd6yL4qm4MPCzt5comQWJAtde8etWQjzkxr/JfdCz161XdALpDndJePQHo
UgBtYhSjUm+Te6xD/FLrJMU1zp0uGeiv605R7hK/1FyrpzK49jb1q9Y5jO0wIl7XjI5VPEPApkzO
tMiIeF03Zu5aK/LXNSPjwWgxLOOPrlgRr2vGwOvOWN6AoE86ZkS8rhk4dwgUHjU1HVHrMLYjanNU
+2jE7oDCo6aGInaKX2oGzp2SLw01uNgXI0KzEebRoQHgXbERZissj6O6Rx+uQ0UZ4bTDDB5t9jCA
ryuyB3nJqpgjhW78ZhCBNpUNIPMtqDze1MZpI6MawObVSbjukCtMn8zZL+TaJDTVQoKbmNNonuBl
VG0wCVBXGJiY61idsC3GiNoENOCLr05AlSjYB840YJ9UJ+w+cKYBo6Y6AfeZM5uzYtodzNWWmQYC
C+Y580czxk2Mzay4C40Y49rc2ah9pJKbBOx/EAPVxDDOioxJ8nVa2phXjsG10FwyMaqzOgXXsXCx
fWqVxhYoLN5mA9XEQFDzFN8DM+CoUftqD8wAE6NHnzgTVUXX/tW9Pb+LS8OOGpw1uh9mgIlZpU+c
WcSZjdpX+yAzGw1EqfDTj2agHjVniLXaQG3nANMfyEA1Mcm0uuIaTBfdt1DbOxK12ELtvIFqYjpq
dZ5VqbQ9MFBNzE2tTtg9AFsmxqhWJ+A+c+ZTnOpiFFweXGULMHUjAceN2lH7zJmN2lf7IDObM43g
e1Jx5r4YqDlX37GBfD9lgXarbU0Tc2PNK2fC6JtCx8Kcx2YydXP8Vfsw2m7Nbj46MRD0UZ43cp73
FjYCik7o+GgZGpaa001FH/OMYiApbh1hVJJdMoqvNz98O4yR52lmIA9uHc02azfWaHu6o7rn0qr4
R3sW69nR8bGYFuYH7vjzW2diL6fh5cHh4RV6d17xFHP6yXXqI9Ivi2uf/sHm0z/uPIgafh5tNX0W
2457vvfmId3PDkauK5sT+PT+zTzIf1pgd0DP8/Ia0ff5U2EAgq87FSpO2DvVbQCJr6PjwHdG37Sw
ThPpMXm2qhMps+YOlsPe1H6E5u7OsKCjugfOrjttad39N8v6ZFnibw1r7bh/9v70lwNIOZbG1z5J
3cyHKREt/2S9iDYlVVmoyokZtc6zXUnvlJLZfmZsSnmZokysb9YY7DlhjGvwWrSYnLmULWbK/UKm
c02aPNVQ69nF4eF/HTBl6iXPYOxs2Bw/DTZq2C9hn0ynznTbYcFHr09/eXMsiBhBJMNwpoS90tIn
o8ZqJqJCJlZpA1Mz+5UGFzMJx/UuR0G3jR0uNW/vxl7cJ6oRfnritU3ttTzVyrRkhMQJKhDTLWL8
lLJZ449S6Elt4LIZuvVdmP/pL6X/HrL6N+fOmY8vJEndxfewri6skTefuHdLn0eLWhPPtwK8mzu/
s+z52IJd5bjf6Lsg9B17JjsBjb2zFtWt6wsLeGrh+KHrBJY3scJ7J1qXFXrWEN9gRmo9u5KscGoH
4WdQyPGd8bV95/wCsnxl3lvHMdbni4iWmMo3shf20J269Bo1r3btmj5dWERNsfMLz52HIODUGdGQ
2SbX9bcL6+MfN7fW759uaVMXvrODfV1Lqd6FNfdCaxnYw6nz3Hq4d+bxsqybXz/98dtbWqh7N/fA
FfWQbmfi7Tp2+gd4X2fMIgHQf2r7JAaEQMgwsWX7ePu5BakIdprWQ4DkBKp3SnqwAeuMwVk4GHsP
c9htY9p8rUdEqq1gBXKMhPXM4GfLfeG8eE7S7NFyvhO7ByzalgucTmvqztyQd8Fm0ez4/9ac1Ch7
/Yx5GxFw4QWBq0G8AuoocPbQube/uZ7/wrJu75fBcyumjfXxzX9GUox0AuJWlgu/tDMfeRDZ0vJ3
qb2kByv4Ih1mFZyxDHDkdC5NGE4QXEE0bz59tKbeg+O/nILHwFvQ9s4/l/bU+mZPl4lODSBzEyHw
Qnq+MZo1Ic5WUszOwB6h/EiKkZgfcQVTJOrd8L4eChiQZ8WnDXJEWrGC3fR4xvk+chYECGK8NXW+
weHijlcswrJpOXdHQEakIu8cPpVu16RUJHozmGwr6kXHyl6pTTwEAAvynfEqK1jC2Yx3ACHoA2nz
jB242tjtm+MPASFn0rK3ohqYjZE9o2wLcUxiqA8TK2E9N4jO6BiCf47/Asi0rkn3YiGdAF93Ppou
xw5Tooy0Wa9zpHYrBMWE3umlw0ergy6rgvVbbIxvd6YoyohcLGz/g0wBy9a5WE/gJhjPkuxEPAPa
yRIqzAHfs3kOdTXvrdSVtApjO1Cb5FiBDGnh6xkLoSxm0uLjw1RiqQpzJLyHoBAUYxuXIbYEbhK4
LW9g+0kneW3MUS+8t4GXA8sekdYnBMTKPSWNobciEzD2CMlSwRjpzJx7M3dZnYDBf6C4/bkFqwKg
OfXn3feFC7vN+os9X9r+o9V/bqHX+EnqN/jL/yaPkXV6/kXaMmM0S9Y5pFSy8HHhXB4s8MQDkAEP
wcEx/6g1/rDBhzlyB+dO2Hvr25MwIsbn22vr2n6cevbYeu/5M3AceR1/fffXqxS5/rKErSKoeFwP
scywhpm7JBun9m18AAL3YcIScrRH9y5guHXv3t3D7wIisx+PfYqw8AihwySG1wBH2ZuEzrweCmqs
WnqwQrDn7V57/M1lV5vO5XpqFVTzJhOQb4ZMOXcBwWZPiTmhGEBISZwGhDaJdtLTzZ8c9V5LD9am
mjsz72fJk00mFXn94HqBmwIUXYhTLa2+/WQjMSktWUHwDJ8N2Mgl1xN7gxO2kugjeA76FNhtZo/h
OnZwdsWn0jPbTyYfjiJScdKy9UilgGrkl4Nn1SKFELGORZth2UHgjVw7hPP5Ae4XNoH48LYaamhI
wzcxdvLjqMGSAklBSC4Aezq1Zs7YtQURVuAYTPMNRoY7gUSXqN9+piGPo7TkrRgmgEPc88E1kDjL
Ibl2oxhgzD3AEYAT/xZYk+Wco1g2gmyPfFA7J82debA0etwY26c8UeREoUAkBDfIuGJEivKwSINn
RajM0JP2sP1sF1ko0qq34jxxLkegCHx0cTgI4gnq8SEymSLmxIfDR5ZYcaRMWkX7aedNpAVvRTay
G/dDcK+cjBxgcr4DVGP74/cTesoejxHT9+YwDQXDCHkk0bP9DCABmCrqnpDRr4gywTEMj4uH2BsL
GRDL9UV8ALbJ3Jp5CBcgZgCruWvel8ABkWQ//VbnRIhZCOQIZCHo7nszZi+JeQoeonD98h0zHnHV
1Rlgq0Br2Egk33yDM57XJdKBpNW1n7Wj7CGDkGSF0kAVeDJIIoizT1lUMDcfXMA6OCQjEAKUF3jW
vS2fq/ZTDu8l7XUBL+kH7x0Y4iOiVUSwsjvvjMexL1FgTkisla+TXcm8sdJi279xBSpoq72TtMNz
DpdzWgHEA3E8TJSOGGmD8xdHL46tPyheTeroLac4CXfQDbIjKOT91glGvsvh75oO7M7chxynYh+r
B73MNjc7B+ESi83sm7fXwp2ThEzgGQvCR8p4w8Fwu+ZF/OyQj/7WnRkUXdYNp8GSjWRd+17ojTw8
46fPtzfXzyzrvz+/vzo6Pjr7YlFmjRWxUc0SY40DXqHKLevNfO7BRHZmyJddvcdPN2/wFvwSr89P
vnC4DL75KVKG6IVx9CkWL/JFazoPGk4UiZwKWVbgUvYNcsEcWdFBgDhPR2Sdkg+q0dIDA03lLE/F
PuhByxSISnkkXGShjyCPwXlDD15AgTjTGeDwmkkvsEttjFCV9GwFAfKMGLsF5PC+zr30iGlxngCH
wAnLQGwzGZE7wHo6IqP0vE7QbZX5L61dQfcMrWCSvqdcx+/2DKEfNj8Z0ZH5KcRcwoPEYBN36mgU
/sq1KPptGNYmMHAMVOcV86yFegK/FydJ6dwiQyWFmIhyTkROcpTRxvwVObrEwRRYMGsndIK1lPUY
esylIBuQd+TuJxEmiEShxVvKSoFnF3FIAlWJGSRtWCfolkADaelbEY2D2QvfCSH4VzmnyeEMpETJ
rhdgCZODuMMehZSFLRlXBCFzOq/rr2xZvYp6MxbLwcIebQLldnuStn27jbp1dOPVWCtNpvYmhQzd
eLMKqrZtL5Z1reGUeZN3/ip9rDjrNco5KpP7fPcMyBj0yI4MfRv3kI3I9YpjTygXfq9GtBnKl8qu
THlgjVHLjIOqTXdZuRjMJHO+ekrmfErmzLZxKjXxyoFCRdEckKFcJimKBXMCszdt92lM2qzOpsKo
Iuu4XtL1xg4Q5tfecDnpIZK/LNVRMi0LFWikAveJTNU4TOuqvGNDbInWxTm0oXVV/pHYfq0rc88b
PoYbJUm2jSmKAV/g3FGsgK3yzVoKduT9Fng1ewrBl3pPLQbIs447HmldmbDOTmSGGQimIaB/Txpl
WD9xHiHcOdS/g/2sj3HiK/LoonYZz35cn0aVUdUCWWw+3monTKbBHjr6u1gGbUOtPdbixok1Wgxb
KL/aylrjJ2rpNEKNxNZQbsFS4PLpLpw2fhARKt60qTWdEgxu+HE9k10yFRB3LBO0xFPrrMfz8+NX
v/Dohs0mARjwTxSze7pzxLYvJ3fKTsfX5Z+w8yX6iA6AcszBabUhF6LFMgA0bJnMcIJ0/+Zqg+Qy
/ZvVRaE6wKmizwgR/rK9ksVyJM15QEyFBsygIzfQNmYb7sy4KSNT8aGghCmdKxOLcO3xTDKIouo3
zttM1Q5QKq6olOOawsSrhzqLLiZMiYwTc+RLagaj2UZBXNcw/tlCnpnjP7hxUlBCaerKI63AGOdq
wdqKIXPf+Qfy7KV1FwCulIop6a0SpbkiL4G6pIGvQnfkwnHC+dMieZTqH1DRQ9nTSHVBFf0EZa2y
8dUJ0mUaoG5FNqLJCF1iQxAuYr6IRJSgh0yquPueqNBEqbhoEsb1hdLudYJ0w03ilCUcpyiq5JSZ
xWLK+aHgtHqIZFqpcMXBCYoKFg5Kg+Yj+MLgAkOJMhKAkAf2kRpT9KKccevWR1ezmcsnqRuvp4zY
oHPbR3TzRdYbZQ2KdEt/iQ6UyEhF64iYBKJsClDE4+7TAPIxmRqsPCDditqHsTNx5ziP2CZKjz89
fXX8xbLBgaK43LGS9zlAZxbf9tGgZYSELk82d3d5fiWmUcivvO+aZwZlWhAqLtYDK9x4FRyO8TjU
yoHbZHCjSJDyRrSatk5fnJNgJMqenJ6hemLskYaR3qD9pGN2kNasR7gB0pHj/r/02iLzkbJHr7w5
Kg04EfKtHdrWwejyAP7zN7/9FrfGpgMlPbL9ZCI2kJasRyWFdJmh4TZl0KJVwRyNQ8ZjxBpEki0q
z7ldEhgr1rZpkdIcJtF5+fzBvEObIrkAayu6JfXFn9F8JaYPErNCpGWRPiLMQp2CUaIdOugrhK7e
1HNDzBST3qCQ42T7PG25yznzWct9rd1TteIi075iK7oRXdaQjBpyFdOsGKOgkDy8pmQ79t6k5oax
G+Pu5l/40cPlQf/oSIwYvsfXp6/wtcAmdx9tztTzFvj8pM/DCn0sAaMg429ROhN6s9X3U2eS+um9
g6ZEmFd2fsgD+iaeF6a+vVuG/G30OJS60YBHTsAVl/Aqxt7ozz76AT9cAMk41244wiqPz/giMId4
RfadDL3xI3+BS5YUTh78fwEAAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29y
ZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDS
SX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd
EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX
lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrA
Z2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bps
QXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ
/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRg
Dq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjW
DPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+/
/ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb
5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJ
iaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQO
SUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6
SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrd
vsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68G
t2noiDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV
5cz2iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKu
e0wZG6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVK
uYTDohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6
M7e6Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7S
es/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHb
azWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaR
DQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqx
idjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXK
bpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC
2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre
2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bn
e29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11
yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz
2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPkt
R7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQBNA5aQfwQAAHEMAAARAAAAd29yZC9zZXR0aW5ncy54
bWy0V9tu2zgQfV9g/8HQe2LqbmvrFJZs7bZItkWVfgAl0TYRUhRIyo779R3qEjcNExRb7JOpmTlz
J2f87v0jZ7MjkYqKZuW418iZkaYSNW32K+frfX61cGZK46bGTDRk5ZyJct7f/PnHu1OiiNYgpmag
olEJr1bOQes2mc9VdSAcq2vRkgaYOyE51vAp93OO5UPXXlWCt1jTkjKqz3MPocgZ1YiV08kmGVVc
cVpJocROG0gidjtakfFnQshfsTsgN6LqOGl0b3EuCQMfRKMOtFWTNv5ftUGIh0nJ8a0gjpxNcicX
vSU5hnsSsn5C/Ip7BtBKURGloECcDeFyTJsnNW7wQtFTqq8h1fPB9tyoAriL+tPFc8Ve4C3VHqp4
S0uJ5VBmaADjBa+SD/tGSFwyaKqTGzg30FHfhOCzU9ISWUGRoB0RcuaGUYt/hd5Q1TJ8/oz3JBUd
dKSkRPVsiFXsCo01AbRqCWN9+1aMYLB1SvYSc2i8lTNQeoyWuHr4Qo7UdP6gpiY73DF9j8tCixZw
RwxRxt7oRHXAgNFEFi2uwEAmGi0Fm+R6HzPoawlpH9weutwEMJyK4cYAosEc4h6o4y24EzUxznaS
vkjtq6UxgN5LyGAflt2QgBsuaU0gNEYKfWYkB+cL+o2sm/pjpzSFe9Xfhd/w4C0HSGMsf4L34P7c
kpxg3UGa/idjfSVyRts7KqWQH5oauul3jc2nIppywnNZq+nwRQg9lQGhzI3jbOwYI3bhoMDLFt6Q
pZ84GfLD1MbxkJ+isbTPMd4yTLOlFZMFnpvZOD4KFpFr5bhRbvfA990Q2bXlob+IbNoCFIaeNZ7Q
DaJ1bMOEQZBNTfw80jD2N7k1o5Hn+2Fo0xb5obexcwI3y6zxRGmwWVizE8f+IrVWId7G0cbqW5xH
KLTaWSC08HOb1ws/XC/XNs4yRvHaGs9y7YVLaxWW6ziN7ZhtiILXOGvP6tsyD6PM7lseb7bWTky9
wAutvqVenCKrB2nmbkKrnddvVgZdnVn7beujfGu1sw3iPLfa2aax51nvaR7EwDL1gdfANCm8ATwx
g/+znE7mYZ3x4VHOMC8lxbM7sxoAiielfEhpM/FLAqsR+ZFTdOXEvLoaGIpjxnKYPBOjbzee1DAO
N2TXq2V3WO4vekcJaaXClPv4pMvMWSL/lqJrB2snidvhwZzMuUEw6qONvqV8oquuLCZUA+P9BxYM
509HaRTOL+k5JRq2wn7w3OJmP72LpLn6WhhReF+ZLMzmSO5w28KABZFy764cRvcH7ZphoeEL5v5D
/1HuvZHn9Tz4Mrz+A1cmMpAeD0ZgOILUeLjQ/InmX2iwHw1ywYUWTrTwQosmGmywp+QA003C9vEA
I3w6GvpOMCZOpP5nIq6cF6QhCeqAWwJ1NZsItJdIesK4mqjZMSGPsBmRmmpYzFtac/xoFiWvv2aj
NGxJotPPZI0mI9w+o85qrDHA+1I9A/ct/pMvsIeRikI7FmdeXhaf68FxRpUuSAs7khYSQu7Xkr96
zZf/CjffAQAA//8DAFBLAwQUAAYACAAAACEAJixWBH0JAAB5SAAADwAAAHdvcmQvc3R5bGVzLnht
bMRca2/buBL9foH7HwR9b/3Iw22w7iJ129sA3W62TnA/0zIdcyuJXklumv31OxzKNC2J0jBSsECB
RA/OIWfOnKFTjn/59WcSBz94lguZzsPJ63EY8DSSa5E+zMP7u0+v3oRBXrB0zWKZ8nn4xPPw13f/
/c8vj1d58RTzPAADaX6VRPNwWxS7q9Eoj7Y8YflrueMpPNzILGEFXGYPo4Rl3/e7V5FMdqwQKxGL
4mk0HY8vw9JMRrEiNxsR8Q8y2ic8LXD8KOMxWJRpvhW7/GDtkWLtUWbrXSYjnuew6CTW9hImUmNm
cl4zlIgok7ncFK9hMSM9o5EyBcMnY/wticMgia5uHlKZsVUMznucnIfvwHNrGX3gG7aPi1xdZrdZ
eVle4Y9PMi3y4PGK5ZEQd+BSMJAIsPX5Os1FCE84y4vrXLDGh1v1VuOTKC8sa+/FWoQjhZj/DTZ/
sHgeTqeHOws1g5N7MUsfDvd4+up+ac9kHppbK7A7D1n2anmtjI1wmYef1nJ3J4uHK5zKjkUQDMBh
m4IDKYAjCicWioPTGfBFX3zbK7+yfSFLEDQAYLZZuKx4HLgCzFlqAsNTvvkio+98vSzgwTxELLh5
f3ObCZkBSefh27cKE24ueSI+i/Waq3wp792nW7Hm/9/y9D7n6+P9Pz4h+UuLkdynBUz/coYsiPP1
x58R3ynagumUqQh/VQOAOBAOCwcntBfH2egbFVS8+dcBcqJj2Iiy5UxleIDzbwXCVe97A03ViuwF
oF2vuZ71N3He38RFfxNI3n6+mPWfBeh634hoblispAe1kJEmn+2Hs7ctlFUjaizqHFEjTeeIGkc6
R9Qo0TmixoDOEbWAd46oxbdzRC2crSMihsJVZdEZeoOU2HeiiLka3ypAk55SV5aa4JZl7CFju22g
Cmt12m1iudyvCtpUUU6fL5bLIpPpQ6dHoDqr1H22Jn9MdluWC9gldbh+2tP1d2rXE/wvE+tOqAtN
vtqacGPSWMJuYxbxrYzXPAvu+E8dUY/xX2Ww1LuMzsn1DOsX8bAtguUWS24n2KXD6W5PaPtfRI4+
aE2mS8dSuoyTYnjp4KXb+G98LfbJwTWE3cil1nOPMFcgcIrtLjpXIapnV+cqVAAoS9Dlwn8JaJ8w
f11c/O2rGFPmr0vRM+0T5q8L1zPtIz/a4+utNB/gQ2tASq+Zd+4uZCyzzT4+5ECnPMy8M9hA0Jbg
ncTGPkkkZt4ZfCKfwXUUwSc3Ck+9Y3HUUQ8U73BoFEw2+lq8g1KRvYnHirwDVMGaemD101oPIG/R
/cZ/CPU3Md9igCpt9pqd6Xzm8ACUINIe+o+9LLr30FOH5lFRblL4c0nOAxramSPzqGgln3S984hx
v8LnAdSvAnoA9SuFHkAOfrj3PKYm0kH6F0cPLG9ZNlUMaUdW5pm3MhsgvxIwUN0k7L8c2evmQr1u
ElC8A1SvmwQU7+hUapmpmwSsweomActRNdwxsjXVZ1HeddMGMjsBwoqGEW8C0DDiTQAaRrwJQP3F
uxtkOPEmYHlrg9FUW7wJQPiKz0d9A2SLNwHIWxu02pV/MzrUPbTS/uF2APEmoHgHqC7eBBTv6LjE
m4CFr/gwoYJlpI6ANYx4E4CGEW8C0DDiTQAaRrwJQMOINwGov3h3gwwn3gQsb20wmmqLNwHIWx4M
kC3eBCB8xUcbGsUbs/7FxZuA4h2gungTULyjUxFUs0klYHkHqIJlxJuAha/4kKHEQnL7LGoY8Sas
aBjxJgANI94EoGHEmwDUX7y7QYYTbwKWtzYYTbXFmwDkLQ8GyBZvApC3NjSKNybji4s3AcU7QHXx
JqB4R6ciqEbnCFjeAapgGfEmYCFfeos3AQhfeS6Qz4qGEW/CioYRbwLQMOJNAOov3t0gw4k3Actb
G4ym2uJNAPKWBwNkizcByFsbGsUbc+TFxZuA4h2gungTULyjUxFUI94ELO8AVbCM1BGwhhFvAhAS
s7d4E4DwlWcAYRb5hGkY8SasaBjxJgD1F+9ukOHEm4DlrQ1GU23xJgB5y4MBssWbAOStDeqcLZwX
JR9PnThIQD1ncDjVQAacOoJEBSwX+I1veAZNVrz7dEhPwMMKPRAd9KAu8b2U3wPawe4zB0HIUGIV
C4lHup/wlI7ViHA2a+kkuPt9EXzWDTC1cUip05M30D1ktwthe5JqHIJ5Fk87aNnZHU6WK2vQIKT6
usoWIGyRu4GGoLKtRw1WfT7wIjZVlbfx/21LVPgdEHFgHSraAlYEHVEtUOWBd3MGCY+7V4Edp+Jx
IseWjMM0y9Pxxz2Ufu/kjGbrvAt1ErxlznhSvNVHAb6io1qfIDRn4ZS6ZgghW8W6xQx+uUnXsEJo
EsT/NdPBXP9k2hQ8X/A4/o1hQ1ohd+5XY74p9NPJGCtgxdRKFoVM3OMzPCCOM2kyAHSwJ6Mv1SLc
PEn3yYpn0OHV4vOvUlUO7EQ7paQ+6+qgAtXT7rmdcNgkyEImqpnzqFRVxrI0ldCdp3rlMiOgOMkV
g56731ULHeZUI/97rgaaF3M4HV0ijMdv4N/ZJ00U6N7ERDXdk5PLkox/H7sn9T1wCr7tds6JllSd
g20OLX4pVBtEk0tsmYEWyu+HhZROV3YXoCx6rDu7TreqCOR2S62Ts+zdPMdkUxfNvZuli0ACjUOh
DwXBcsuh+l63Q0/YFu1zSMSlUu+qQFddUXVz+RxbTYKjs8jcc7i9y+Vu/9Zo18dLrbSDbcufPKor
hZWReflKE/ksz+rVpkC3Bgbqhw1+KvGPTncztFv/Ox260mtY5PBzcHrZS3ExrHzHTTLLoUefuP3W
RbGKz7wcNFSWNvPvPYtjKdNG2Suf6davJtq5NM8yevTeyzCqJoFlM7tRQOgFJ8thdvJ9APPwjm1l
wlR9x05/+0aUmyv0zFFJ+5SmyN57tihp1cFVntuRc5PcXcVtpltYQ9P8X/d3c06oPdut+cBR9S3+
LeD4uCsv6rSHfgQcdPwwUt36vP14cT0ttz4lwQXuo9UueB7ODmUogi5bEPo9i8s2S7ALeopDfPc/
0OspmmUAn/iLgDFIkYDObc/4fLp4U35lxovm/ILFYpUJlfSH7/6Yh9bNUgmsOygFIoGvafnKH4Nv
oBipDvDJXgo/3w1X7E69W+XoMWR9s9/gdOX+aU2zw1XuoqrJbnnw33B0c+qblqSqR80DTF34JhL4
bhL8tZ7fjo9vpw46H19cTN9rpw7B52O6H37L3/0DAAD//wMAUEsDBBQABgAIAAAAIQARnl7SZQMA
ALgPAAASAAAAd29yZC9udW1iZXJpbmcueG1szFfdTtswFL6ftHeocg9x+kepKKgUdWPa0CQ67dpN
XGLhn8h2WnrLy+wR9li8wo7jJE0oQiSgqTckHB9/Pufz+U5Ozy4eOOusidJUiokXHCOvQ0QoIyru
Jt6vxfxo5HW0wSLCTAoy8bZEexfnnz+dbcYi5UuiwLEDGEKPN0k48WJjkrHv6zAmHOtjTkMltVyZ
41ByX65WNCT+RqrI76IAZW+JkiHRGnBmWKyx9nI4vo8mEyLgrJVUHBt9LNWdz7G6T5MjQE+woUvK
qNkCNhoWMHLipUqM84COyoDslrELKH8UO9ReFi+c63ZeyTDlRJjsRF8RBjFIoWOa7NJoiwYpxkVI
69eSWHNW+G2SoL93XpnyW+7gSuENXMUOcA/uBTIit4kzx4O9392tPkcM0GvJ5DdiIcoY3hJC/cwi
Eo6pKGHaUVMlFyTxnvr+omSalOEk9H1o1+K+xLLKbBAZGmbKq6amGwHsSfc2xgnxOjwcX98JqfCS
QUSboN+xFemdQ7fAS20UDs1Nyju1/66jiYcyF6FpBGtrzCZe77LbR7Pe1PPtZp4yQ7+TNWGLbUIK
n3i7VDT6YdeYXXO+hies8OheTfu9KRq5Fba2CxQe9kR4NQmDJnM5nU8vR4NZFgP0OmWK7SduHzS6
OS+Ny5QxYkrEBXkol45K67ewwGBklTsnP5XNhQqbpDVDv0WjLJAYi7us4/aGyGL4m3HurdwmNZfC
aNiHdUihcGaYUUjeJkGwNlNN8QI6LpDOKfD/dQpc2sXYvtTcQ20qjpc0cn5UQDgRWWFgM48gOxoi
Ab5s3FX2gh17qI9OEUK9zAKtEDrgGsII9tkMHDtvZlM2ZnOEWrIpU0WJ6tyQTZW0ujUEiczqprgZ
a9091gYfz9rT45+mvHUH3Xa8/YaatZMCfOzKUqvbmhHkiigTZV5WrtA+tKyeHv82JagHvShLsalM
b7d8KeHrXLJTMTSjpp9VSpWaQ1Bc7xT6lc2uKTHPhZS3qbq83q84p68qa4ehuP6wZd+vq8uxVrc1
KysYk4vP4EEpbtBv2corAnPsVAzNqDnZo+YQFDcMWvbq/6Q4+Ln4rKAOQ3HDUcsWXldXG8XBCFUZ
fu0oBSMQsAR/7ezrJqWKx7WdD7MhuJgFwTObCeHpfnGf/wMAAP//AwBQSwMEFAAGAAgAAAAhAHBY
2N7gAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBSsQwEIbvgu8Q5p5NY7dVl6bL1hDYqyh4zaZpG2iSkqSi
iO9uiqf16Gn4Zpj5fqY5ftgZvesQjXcM6K4ApJ3yvXEjg9cXgR8AxSRdL2fvNAPn4dje3jR9PPQy
yZh80OekLcoNk+uZM/gSQtCOP52w2IsO78v6EXdlRTHlouRdfU+rU/UNKKtdPhMZTCktB0KimrSV
cecX7fJw8MHKlDGMxA+DUZp7tVrtErkripqoNevtm52h3fL8bj/rIV7jFm0N5r+Wi7nMxo9BLtMn
kLYhf1QbX72i/QEAAP//AwBQSwMEFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4ACAFjdXN0b21YbWwv
X3JlbHMvaXRlbTEueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE
z8GKAjEMBuC74DuU3J3OeBCR6XhZFryJuOC1dDIzxWlTmij69hZPKyzsMQn5/qTdP8Ks7pjZUzTQ
VDUojI56H0cDP+fv1RYUi429nSmigScy7Lvloj3hbKUs8eQTq6JENjCJpJ3W7CYMlitKGMtkoBys
lDKPOll3tSPqdV1vdP5tQPdhqkNvIB/6BtT5mUry/zYNg3f4Re4WMMofEdrdWChcwnzMlLjINo8o
BrxgeLeaqtwLumv1x3/dCwAA//8DAFBLAwQUAAYACAAAACEAtlPo9fMBAADwAwAAEAAIAWRvY1By
b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/Y
Pxi+N45Tt2sCRUWXbuhhawPEbc+aTMfCZEmQ2KDZ14+yG8fZeqpP5CP9+PREsevXVic78EFZs0zz
yTRNwEhbKbNdpo/l97OrNAkoTCW0NbBM9xDSa/75E1t768CjgpAQhQnLtEF0iywLsoFWhAmVDVVq
61uBlPptZutaSbi18qUFg9lsOr3M4BXBVFCduYEw7RkXO/woaWVl1Beeyr0jwZyV0DotEPh9lKMn
lcWWZQPKSotCl6oFPiV4SNhabCHw4pJlfcSera8C/3J+MWdZH7NVI7yQSB7yIp9fEMEIYTfOaSUF
kr/8p5LeBltj8tA5kUQGlo1bGLmzAfniFe6jlnHKfihDas4Lmt2HpM+LrReuCXx+FUUOKdtIoWFF
LvBa6AAsOwLsDkS84bVQJJrtcLEDidYnQf2hO56lyS8RIHq3THfCK2GQPIxtfdLF2gX0vFSoiZtq
fd6F47ZxrAqedw0UnDZGgl4DFU7VdRPCQ01nw3fE5mOxnYZe6kjOKBxm/MO6sq0TZs+/eSVDsCa5
+UrX+AZG33+HR1fa27hCb3aegqMteFbYbJyQcXHms5xOfNyHUY1taG+gogs+MB4Bdkfeex3H0r9m
C9Wh5/9C3LCn/gHzvJhM6etW6oDRVgwvi/8FAAD//wMAUEsDBBQABgAIAAAAIQCpyFyqjAAAANoA
AAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACySbIKzi8tSk4tVghOzUlNLklNCS6pzEm1VYpxDHDUiwj2UVIAC/gl5gIFgWJKChW5
OXnFVkm2ShklJQVW+vrFyRmpuYnFevkFqXlAubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDA
TD8pMyknMz+9KLEgoxJqGFWMsrPRh3vGjpcLAAAA//8DAFBLAwQUAAYACAAAACEAC+p8/3ACAADL
CAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbMSVTY/aMBCG75X6HyLflzghfGrDapcuUi89dKl6NsEh
VmM7sgNZ/n3HdhJaCIVIrRqkBGbiF8+jecePT+889w5UaSZFjIIBRh4VidwysYvRt/XqYYo8XRKx
JbkUNEZHqtHT4uOHx2qeSlFqD9YLPedJjLKyLOa+r5OMcqIHsqACkqlUnJTwU+18TtSPffGQSF6Q
km1YzsqjH2I8RrWMukdFpilL6CeZ7DkVpV3vK5qDohQ6Y4Vu1Kp71CqptoWSCdUaaua50+OEiVYm
iC6EOEuU1DItB1CM73bkGylYHmD7jefI48n8805IRTY5sKuCCC1qcF41F4RDcElytlHMJgoipKYB
5A4kjxEO8QqP4G4+ER6aO/KNQpIRpWnZvohdOCWc5ccmqiumtUsUrEyyJn4gipkNuZRmO0js9QbH
6BXDFa5WyEWCGEUQeF62kRA25a6gfmfYRqBzYGNWx74SzKwORECnXmX36bvWuSCxZpxq7wutvK+S
E3GFSIjHQGIEPAyZYS8iyupagj2IhM9t/VDJEkqZTKOm/hOR2W0iTud+Iku5V4wqw+QKjQkQmNn+
MDSiXjS43FIlOhokZe90290dnSyGdeX/lMV3cKeZSrqTxKhpsNPTFXDulNCFf3cK2Zeyg8N1ozT/
UhcObRHUoQsU1hZgr06jTH9ZdX9bvB35RuZXOIxg/pgZNAGfhOCRSQ8O/f3xf0GsSQaO7gQR4hcA
YIamGRWRMUc3iL81OqEBwtfzQTHGo5fzjghvDYoAB70HBeFwhlwjYUal42BGZz8S/Vui+xDBUcvm
NCb+6A3bWrcPkfo00YufAAAA//8DAFBLAwQUAAYACAAAACEAF6AWTgIBAACsAQAAFAAAAHdvcmQv
d2ViU2V0dGluZ3MueG1sjNDBSgMxEAbgu+A7LLm32ZUisnS3IFLxIoL6AGl2dhvMZMJMaqxPb9qq
IF56yySZj5l/ufpAX70Di6PQqWZeqwqCpcGFqVOvL+vZjaokmTAYTwE6tQdRq/7yYpnbDJtnSKn8
lKooQVq0ndqmFFutxW4BjcwpQiiPIzGaVEqeNBp+28WZJYwmuY3zLu31VV1fq2+Gz1FoHJ2FO7I7
hJCO/ZrBF5GCbF2UHy2fo2XiITJZECn7oD95aFz4ZZrFPwidZRIa07wso08T6QNV2pv6eEKvKrTt
wxSIzcaXBHOzUH2Jj2Jy6D5hTXzLlAVYH66N95SfHu9Lof9k3H8BAAD//wMAUEsDBBQABgAIAAAA
IQCwy+PNAgoAAGpLAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzEXG1v2zYQ/j5g/0HQ
9zS289YGc4fUbdcAXZfVCfaZlulYiyR6kpw0+/U7HimalkTrGCkYUCC2JN5zr8/RLs+//PojTYJH
nhexyKbh+M0oDHgWiWWc3U/Du9vPR2/DoChZtmSJyPg0fOZF+Ov7n3/65emyKJ8TXgQgICsunzbR
NFyX5eby+LiI1jxlxZs0jnJRiFX5JhLpsVit4ogfP4l8eTwZjUf4apOLiBcFoM1Y9siKUItLm9LE
hmeAtRJ5ysrijcjvj1OWP2w3RyB9w8p4ESdx+QyyR+eVGDENt3l2qRU6MgrJJZdKIf2nWpE3rGjB
VSs/imib8qxExOOcJ6CDyIp1vNmZ8VJpYOK6UunxkBGPaVI997QZnzbwjMmUGHzM2ROEYiewIa7F
GUu1KE2UH2R8d1GtSxyPDhmjIyJFGB0oKuxjVpqkLM6MmJe5xnYu1EOf/P4tF9uNUWcT95N2nT0Y
WbIsPTQbnWPl2aYVXgIapTtfsw0PgzS6vL7PRM4WCWj0ND4NZEaG74EqliL6yFdsm5SFfJvf5Pqt
fod/PousLIKnS1ZEcXwLFAJS0hgEfrnKijiEO5wV5VURs9aba/lU652oKC1pH+JlHB5LxOJfkPnI
kmk4mVRXZlKDvWsJy+6razw7upvbmkxDc2kBcqchy4/mV1LYMZpZ/bXM3ewZD+9QlQ2LoPIAh61K
DiQELCZxklhGd3IBjKbefN9K57JtKTQICgAwWyy8rXkcuAmYaq4YG+7y1VcRPfDlvIQb0xCx4OLd
9U0eixxodBq+eycx4eKcp/GXeLnkskHoa3fZOl7yv9Y8uyv4cnf9z89Iz1piJLZZCeqfX2AWJMXy
04+IbyRNguiMyQh/kwuAwyAcFg4qtI132qgLNVS8+E8FOVYxbEVZcyZbWoD6HwRCq7e9gSbSItsA
lOul60l/Eaf9RZz1F4HJ288XF/21gI1M34io3LCykh7UUkQq+Ww/nLw7kLJyRSOLOlc0kqZzRSNH
Olc0UqJzRSMDOlc0At65ohHfzhWNcB5cETEkrnoWnaA3SIV9G5cJ9MkOphv3pDrdaoIblrP7nG3W
gWysdbUPkeV8uyhpqiKdvpws52Uu5HazwyPQnWXpvpiTP6WbNSti2JV3AfV0/a3c+gS/5TFsXzug
zlTyNWzCjUlrC7tJWMTXIlnyPLjlP1REPdZ/E8Fc7TI6lesZ1q/x/boMYFcoW24n2LnD6W5PKPlf
4wJ9cLCbnztM6RJOiuG5Iy/dwn/ny3ibVq4h7EbOFZ97hLkGgSoedtGpDFGzujqtkAGgmKDahb8J
KJ+gv2ou/vJljCn6q1b0QvkE/VXjeqF8zI/D8fVmmo/wtUpAKq8L79qdiUTkq21S1UAnPVx4V7CB
oJngXcRGPokkLrwreI8+g6sogk9ulDz1jsWORz1QvMOhULDY6LZ4B6VGe2MPi7wDVMOaeGD141oP
IG/S/c4fY/klsG8zQJY2e83Ocj5xeABaEGkP/edWlN176ImD86go1xl8XVLwgIZ24qg8KprOJ9Xv
PGLcr/F5APXrgB5A/VqhB5AjP9x7HtMT6SD9m6MHljctmy6GaUdm5gtvZjZAfi1goL5J2H85qted
C82+SUDxDlCzbxJQvKNT62WmbxKwBuubBCxH13DHyOZUH6O8+6YNZHYCBIuGIW8C0DDkTQAahrwJ
QP3JuxtkOPImYHlzg+FUm7wJQPiIz0d9A2STNwHImxsU2+nvjKq+h1IOf7gdgLwJKN4BapI3AcU7
Oi7yJmDhIz6ZUMMyVEfAGoa8CUDDkDcBaBjyJgANQ94EoGHImwDUn7y7QYYjbwKWNzcYTrXJmwDk
TQ8GyCZvAhA+4sMNreSNVf/q5E1A8Q5Qk7wJKN7RqRGq2aQSsLwDVMMy5E3Awkd8kkFjYXL7GDUM
eRMsGoa8CUDDkDcBaBjyJgD1J+9ukOHIm4DlzQ2GU23yJgB504MBssmbAOTNDa3kjcX46uRNQPEO
UJO8CSje0akRquE5ApZ3gGpYhrwJWJgvvcmbAISPvBTIx6JhyJtg0TDkTQAahrwJQP3JuxtkOPIm
YHlzg+FUm7wJQN70YIBs8iYAeXNDK3ljjbw6eRNQvAPUJG8Cind0aoRqyJuA5R2gGpahOgLWMORN
AMLE7E3eBCB85AVAWEU+YRqGvAkWDUPeBKD+5N0NMhx5E7C8ucFwqk3eBCBvejBANnkTgLy5QZ6z
hfOi5OOpY0cSUM8ZVKcayIATR5CogNrA73zFc5gq5N2nQ3oCVhZ6IDrSg2riByEeAtrB7hNHgpCh
4kUSCzzS/YyndKxBhJOLA5MEt3/Mgi9qAKaxDlNq/+QNTA/Z40I4niQHh0DP8nkDIzub6mS5lAYD
QnKuS48A4UzoNQwE6bEeuVjO+cCDOFSlL+P/22pUeA2IuLAJFa0BK4KJqANQ+sC7OYOEx93rwI5T
8ajIbiSjUlOfjt/todRze2c0D+pdypPgB3TGk+IHfRTgIyqqTQVhOAtV6tIQQrZI1IgZvLjOlmDh
k57OUsFc/mBKFNyf8ST5neFAWik27kcTvirV3fEIO2BN1EKUpUjd63M8II6atAmAdLCVUW+lEe48
ybbpguf6uLkzJWXnwEm0/ZRUZ10dqUD1tFu3vRw2BTITqRwe3jFVPWNZlgmYzpOzcrkhUFRywWDm
7g85Qoc11Zr/Pa2B4cUCTkdrhNHoLfw7+awSBaY3sVDN9OT4XCfjv7vpSXUNnIJPu52zxyV15+CY
wwG/lHIMos0lNs3ACOVDZYh2upQ7A2ZRa93Vtb9VRSC3WxqTnHp28xT/i1q+aZ/d1C4CCjQOnYya
DlXXuh26l23RtoBCnEv2rhN03RV1N+v7OGoS7JxFzj2H27tc7vZvI+36eOlg2sG25W8eNZnCqshC
P9KWfJZnlbUZpFtLBqqbLX7S+DunuzO0m/87HbpQNswK+Dt4etmmuDJMP+NOMsuhO5+4/daVYjWf
eTloqCptz78PLEmEyFppT99To19taefiPEvoznuvk1ENCtTD7IYBYRacTIf53u8BTMNbthYpk3sq
nPS3L0TwAwb6Nnpmx6R9WlNk7z0PMGndwfU8tyPnTnJ3F7cz3cIaOs3/d3+314Tcs92YDxx13+J3
AbvbXXXRTHuYR8BFuw8j9a3Pu09nVxO99dEJHuM+Wu6Cp+FF1YYimLIFot+yRI9ZglzgU1ziu/+B
Wc+4nQbwjj8JGIEUCujc9oxOJ7O3+iczXrXmZyyJF3ksi7767Y9paF3UTGBdQSqIU/hdom/8KfgO
jJGpABfW5hS+11DB6dicUhlg37v1HN2FrG/1G5yu2t/vaXa49C6qXuyWB/8PR7eXvhlJqnvU3MDS
hV8igd8mwZfN+nZ8fNt30Ono7GzyQTl1iHzelXv1qnj/HwAAAP//AwBQSwMEFAAGAAgAAAAhAMcN
eT1fAQAAjgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAJySTU7DMBSE90jcIfI+cX4QoChxJUBdUQlBURE7Y7+mhtixbLdpL8YFuBhO0oZW
sGLpzLzxNy8uJltZBxswVjSqREkUowAUa7hQVYme59PwGgXWUcVp3Sgo0Q4smpDzs4LpnDUGHkyj
wTgBNvBJyuZMl2jlnM4xtmwFktrIO5QXl42R1PmjqbCm7INWgNM4vsQSHOXUUdwFhnpMRPtIzsZI
vTZ1H8AZhhokKGdxEiX4x+vASPvnQK8cOaVwO+077XGPszkbxNG9tWI0tm0btVmP4fkT/DK7f+qr
hkJ1u2KASMFZzgxQ1xgyo5Va22AB1hPUa8ULfKR2m6ypdTO/9KUAfrMjj8Jvx/Dg6f3r8w1MVeDf
nm7MwEZ0P46kvWM8+sv7rgMB8MDT50PXg7LIbu/mU0TSOMnC+CpM03mS5clFHsevHd7JfNdm+CD3
kP9OPASQnvj0BZFvAAAA//8DAFBLAQItABQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAAAAAAAAAAA
AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsA
AAAAAAAAAAAAAAAA5AMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACpCyRBDAQAAzAQAABwA
AAAAAAAAAAAAAAAACAcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAA
ACEAWWD/eyhyAADo+gQAEQAAAAAAAAAAAAAAAACNCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAU
AAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAADkewAAd29yZC90aGVtZS90aGVtZTEu
eG1sUEsBAi0AFAAGAAgAAAAhAE0DlpB/BAAAcQwAABEAAAAAAAAAAAAAAAAAv4IAAHdvcmQvc2V0
dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhACYsVgR9CQAAeUgAAA8AAAAAAAAAAAAAAAAAbYcAAHdv
cmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQARnl7SZQMAALgPAAASAAAAAAAAAAAAAAAAABeR
AAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEAcFjY3uAAAABVAQAAGAAAAAAAAAAA
AAAAAACslAAAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAA
KAEAAB4AAAAAAAAAAAAAAAAA6pUAAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1BLAQIt
ABQABgAIAAAAIQC2U+j18wEAAPADAAAQAAAAAAAAAAAAAAAAAPCXAABkb2NQcm9wcy9hcHAueG1s
UEsBAi0AFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAAAAAAAAAAAAAAAAAGZsAAGN1c3RvbVhtbC9p
dGVtMS54bWxQSwECLQAUAAYACAAAACEAC+p8/3ACAADLCAAAEgAAAAAAAAAAAAAAAAD+mwAAd29y
ZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhABegFk4CAQAArAEAABQAAAAAAAAAAAAAAAAA
np4AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhALDL480CCgAAaksAABoAAAAA
AAAAAAAAAAAA0p8AAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0AFAAGAAgAAAAhAMcN
eT1fAQAAjgIAABEAAAAAAAAAAAAAAAAADKoAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAAQABAA
HAQAAKKsAAAAAA==

--_004_4BC545FCE47FC14EAABD27484D62A9D01C1D6BE7ESESSMB103erics_--

From tterribe@xiph.org  Wed Jul 24 03:57:46 2013
Return-Path: <tterribe@xiph.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2711E80DC; Wed, 24 Jul 2013 03:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.077
X-Spam-Level: 
X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwmb0RLDGDBZ; Wed, 24 Jul 2013 03:57:32 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB311E839F; Wed, 24 Jul 2013 03:57:32 -0700 (PDT)
Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 79E6CF20BA;  Wed, 24 Jul 2013 03:57:31 -0700 (PDT)
Message-ID: <51EFB31A.3010506@xiph.org>
Date: Wed, 24 Jul 2013 03:57:30 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16
MIME-Version: 1.0
To: "ietf@ietf.org" <ietf@ietf.org>
References: <20130604222555.32402.16024.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135E7A62@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1135E7A62@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 10:57:46 -0000

Cullen Jennings (fluffy) wrote:
> There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using
>
>    m=video 62537 RTP/SAVPF 96
>    a=rtpmap:96 VP8/90000
>    a=fmtp:96 max-fr=30;max-fs=3600
>
> What resolution do you think "max-fs=3600" is? I have no idea. It is not possible to implement so it is not surprising no one is doing  it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr.

I can't speak for other implementations, but here at Mozilla, our 
interpretation of RFC 6236 was that the values specified in imageattr 
can be completely ignored by either side, if they so choose. That leaves 
max-fs and max-fr as the only mechanism to indicate a resource 
constraint that cannot be ignored, and we plan to use it as such.

See <https://bugzilla.mozilla.org/show_bug.cgi?id=881935> for details.

From fluffy@cisco.com  Sun Jul 28 01:43:41 2013
Return-Path: <fluffy@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1421F9C6E; Sun, 28 Jul 2013 01:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level: 
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmM6MHzhBWOk; Sun, 28 Jul 2013 01:43:37 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C74C321F9C6C; Sun, 28 Jul 2013 01:43:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1713; q=dns/txt; s=iport; t=1375001017; x=1376210617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8dO/6ph5SJm18PIqDuaYPOAulOn9nuB6mZhzHTec+t4=; b=XO5PkN1Ay9cNNXsVBzPeZxlPE1zkx0Wg2yfcmU9/5BAma7SsbefcGXi8 K/zQZvj6DWtT5ikbImKkLgpoHHQMdnIqYhSpJEHJnIle3E3zrvkX/eeA1 Gd35s1L428FCgju0OBQQXTJRq0AJK3utmfN6/o2Df0iIzNaqF0/Nt+BrA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAFfZ9FGtJXG8/2dsb2JhbABagwY1UL1SgRcWdIIkAQEBAwEBAQE3NAsFCwIBCBgKFAULJwslAgQOBQiIAgYMt10EjkmBAQIxB4MWbwOpK4FbgTmBaUE
X-IronPort-AV: E=Sophos;i="4.89,763,1367971200"; d="scan'208";a="240416385"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jul 2013 08:43:36 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6S8haUY003905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 08:43:36 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 03:43:36 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Thread-Topic: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
Thread-Index: AQHOi26MMJs9rmga5UWYQED6+9xbFw==
Date: Sun, 28 Jul 2013 08:43:35 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB113617E32@xmb-aln-x02.cisco.com>
References: <20130604222555.32402.16024.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135E7A62@xmb-aln-x02.cisco.com> <51EFB31A.3010506@xiph.org>
In-Reply-To: <51EFB31A.3010506@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.97.124]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <99BA1A193C12AB47B2EAACB4F53C79BE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" <ietf@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 08:43:42 -0000

So do you expect your implementations on devices with hardware acceleration=
 to have any limits on resolution of images they can decode?  I can't imagi=
ne how I could implement the frame buffers in VP8 in VLSI without having an=
 upper limit on both the width and height of the image. How do you deal wit=
h that?

I don't know if you ever got the Google VHDL code for VP8 but I have never =
got it so I don't know what it does but if you do, that would be great.=20


On Jul 24, 2013, at 12:57 PM, Timothy B. Terriberry <tterribe@xiph.org> wro=
te:

> Cullen Jennings (fluffy) wrote:
>> There is one thing that as far as I can tell that all the implementors a=
gree on. None of the implications control the resolution using
>>=20
>>   m=3Dvideo 62537 RTP/SAVPF 96
>>   a=3Drtpmap:96 VP8/90000
>>   a=3Dfmtp:96 max-fr=3D30;max-fs=3D3600
>>=20
>> What resolution do you think "max-fs=3D3600" is? I have no idea. It is n=
ot possible to implement so it is not surprising no one is doing  it. Howev=
er, this draft-ietf-payload-vp8 draft says the resolution is specified usin=
g the max-fs and max-fr.
>=20
> I can't speak for other implementations, but here at Mozilla, our interpr=
etation of RFC 6236 was that the values specified in imageattr can be compl=
etely ignored by either side, if they so choose. That leaves max-fs and max=
-fr as the only mechanism to indicate a resource constraint that cannot be =
ignored, and we plan to use it as such.
>=20
> See <https://bugzilla.mozilla.org/show_bug.cgi?id=3D881935> for details.
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From tterribe@xiph.org  Tue Jul 30 20:43:11 2013
Return-Path: <tterribe@xiph.org>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111D511E8155; Tue, 30 Jul 2013 20:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXhN21rlwFL2; Tue, 30 Jul 2013 20:43:02 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9411E80E4; Tue, 30 Jul 2013 20:43:01 -0700 (PDT)
Received: from [192.168.15.42] (unknown [213.23.104.157]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C5ADAF223F;  Tue, 30 Jul 2013 20:43:00 -0700 (PDT)
Message-ID: <51F887C3.6070802@xiph.org>
Date: Tue, 30 Jul 2013 20:42:59 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <20130604222555.32402.16024.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135E7A62@xmb-aln-x02.cisco.com> <51EFB31A.3010506@xiph.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113617E32@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB113617E32@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" <ietf@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Last Call: <draft-ietf-payload-vp8-08.txt> (RTP Payload Format for	VP8 Video) to Proposed Standard
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 03:43:11 -0000

Cullen Jennings (fluffy) wrote:
> I can't imagine how I could implement the frame buffers in VP8 in VLSI without having an upper limit on both the width and height of the image. How do you deal with that?

The one hardware VP8 decoder I have any experience with so far is mostly 
throughput-limited, not resolution limited (nor even limited by the 
number of streams... I was surprised to find this out, too). There are 
width/height limits, I'm sure, just because the size of the addresses 
must be finite, but they're not the bottleneck on any video you'd 
actually want to send. I could easily see how that might not be true on 
all (or even most) hardware implementations, however.

> I don't know if you ever got the Google VHDL code for VP8 but I have never got it so I don't know what it does but if you do, that would be great.

No, I dropped the ball here, so I don't know what it does either.

From mzanaty@cisco.com  Wed Jul 31 16:58:37 2013
Return-Path: <mzanaty@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CCE11E80E2; Wed, 31 Jul 2013 16:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4mXpUnOWnZP; Wed, 31 Jul 2013 16:58:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A88AF21F99A9; Wed, 31 Jul 2013 16:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19170; q=dns/txt; s=iport; t=1375315104; x=1376524704; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7JIuxYoqp7rsDFCvKAgZVXeFWnu0pN210KoennfGuNA=; b=fKj8ykvLiTxzygSv04mmmUegqrQcBKGwg46uQX5mmmXPn3Py159N8JJ0 sJnSggwn5edY1rc733Wi4orC9wlg8keSbATs9AbPljpMI7hqiljclzavD aaYUE0UNgr7pjc+u8aB9AeNFaYTAxmhAtClzDx1wxGUXEp23sP+RcP0zt 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsFAOCj+VGtJXG+/2dsb2JhbABbgkJENVC9K4EJgRwWdIIkAQEBBC1cAgEIEQQBAQsZBAcyFAkIAgQBEgiICLklj1Y3AYMYcwOpLIFbgTmCKg
X-IronPort-AV: E=Sophos;i="4.89,790,1367971200";  d="scan'208,217";a="242026423"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 23:58:23 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6VNwNIc013551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 23:58:23 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 18:58:22 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Ross Finlayson <finlayson@live555.com>, "avt@ietf.org" <avt@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [AVTCORE] Clarifying the H.264 RTP payload format specification's	text on when to set the RTP "M" bit
Thread-Index: AQHOjhp3XWusdVYmq0SHqDkxPhapBJl/ZD4w
Date: Wed, 31 Jul 2013 23:58:22 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com>
References: <C1F36850-2B72-4A98-97B7-8847C9C90CB0@live555.com>
In-Reply-To: <C1F36850-2B72-4A98-97B7-8847C9C90CB0@live555.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.170.78]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: Re: [payload] [AVTCORE] Clarifying the H.264 RTP payload format specification's	text on when to set the RTP "M" bit
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 23:58:37 -0000

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ross,

If your application interfaces with an encoder or systems layer (container =
file format, transport stream, CDN stream, etc.) that does not indicate fra=
me boundaries nor any timing information, then how are you setting the RTP =
timestamp? That seems like a much more fundamental issue than the marker bi=
t.

If you are willing to detect the last NALU of a frame by waiting for the fi=
rst VCL NALU of the next frame, that is very simple in both H.264 and H.265=
. The first bit after the VCL NALU header is set if it's the first VCL NALU=
 of a frame. This works in H.265 because the slice header explicitly has su=
ch a flag. It works in H.264 because the slice header starts with the macro=
block address which will be 0 at the start of the frame (assuming no ASO/FM=
O), and 0 encodes to 1 under ue(v) encoding rules. Keep in mind the NALU he=
ader is 2 bytes in H.265 vs. 1 byte in H.264, so the slice header offsets a=
re different.

If you can't wait for the first NALU of the next frame, it is much harder t=
o detect the last NALU of a frame without full VCL bitstream parsing, unles=
s you use some heuristics which may be simpler but less reliable. This is p=
art of the reason why the marker bit in video payloads indicates end of fra=
me, because it may be very difficult for RTP receivers to detect without de=
ep parsing otherwise. Note that RTP receivers are technically forbidden to =
rely on the marker bit. But many implementations detect whether it is relia=
ble, then use it as an optimization to minimize latency if reliable.

I don't think the draft needs any more text beyond what it currently says.

Regards,
Mo


From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross =
Finlayson
Sent: Wednesday, July 31, 2013 2:19 PM
To: avt@ietf.org
Subject: [AVTCORE] Clarifying the H.264 RTP payload format specification's =
text on when to set the RTP "M" bit

As I noted in Wednesday morning's AVTCORE session, the proposed H.265 RTP p=
ayload format specification is not as clear as it could be about how a RTP =
sender knows when to set the "M" bit on an outgoing RTP packet.

Currently, the text 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.  Decoders
      can use this bit as an early indication of the last packet of an
      access unit.

There is nothing inherently wrong with this.  However (because we're not in=
 the MPEG world here :-) it's not sufficient to fully specify only how the =
receivers of RTP packets should behave; we should also try to specify, as c=
learly as possible, how the *senders* of RTP packets should behave.  We sho=
uld try to give at least some guidance about when the NAL unit that's being=
 sent ends an "access unit" because - for many implementations - it is not =
immediately obvious.

If I were amending the H.264 payload format specification - which of course=
 I'm not - then I would, hypothetically, add a paragraph something like the=
 following:

----------
Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender=
 implementation whether or not the NAL unit ends an access unit.  Instead, =
the implementation can obtain this information separately, from the encoder=
.  If, however, this information is not directly available from the encoder=
 (e.g., because the implementation is sending data that consists solely of =
a sequence of pre-encoded NAL units), then it must instead inspect the next=
 NAL unit, to determine whether or not the current NAL unit ends an access =
unit.  The following rule can be used:
    The current NAL unit ends an access unit if it is a VCL NAL unit (i.e.,=
 if its "nal_unit_type" is in the range [1..5]), and if either:
            - the next NAL unit is not a VCL NAL unit, or
            - either the current NAL unit's "nal_unit_type" or the next NAL=
 unit's "nal_unit_type" - but not both - is 5 (i.e., "Coded slice of an IDR=
 picture"), or
            - the next NAL unit's "nal_ref_idc" field differs from the curr=
ent NAL unit's "nal_ref_idc" field, with one of them being equal to zero, o=
r
            - both the current and next NAL units begin with slice headers,=
 and their "frame_num" fields differ, or
            - both the current and next NAL units begin with slice headers,=
 and their "pic_parameter_set_id" fields differ, or
            - both the current and next NAL units begin with slice headers,=
 and their "field_pic_flag" fields differ, or
            - both the current and next NAL units begin with slice headers,=
 and their "bottom_field_flag" fields differ, or
            - both the current and next NAL units' "nal_ref_idc" field is 5=
, and the "idr_pic_id" fields differ.
----------

(I derived this rule from Section 7.4.1.2.4 - "Detection of the first VCL N=
AL unit of a primary coded picture" - of the H.264 specification.  Perhaps =
it could be simplified?)

I suggest that an analogous paragraph be added to the H.265 RTP payload for=
mat specification.  (Or alternatively, instead of writing a detailed rule l=
ike this, perhaps a reference to an appropriate part of the H.265 specifica=
tion might be made instead (can we do this in a IETF RFC?).)

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


--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-tab-span
	{mso-style-name:apple-tab-span;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Hi Ross,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">If your application interfaces with an =
encoder or systems layer (container file format, transport stream, CDN stre=
am, etc.) that does not indicate frame boundaries nor any
 timing information, then how are you setting the RTP timestamp? That seems=
 like a much more fundamental issue than the marker bit.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">If you are willing to detect the last N=
ALU of a frame by waiting for the first VCL NALU of the next frame, that is=
 very simple in both H.264 and H.265. The first bit after
 the VCL NALU header is set if it&#8217;s the first VCL NALU of a frame. Th=
is works in H.265 because the slice header explicitly has such a flag. It w=
orks in H.264 because the slice header starts with the macroblock address w=
hich will be 0 at the start of the frame
 (assuming no ASO/FMO), and 0 encodes to 1 under ue(v) encoding rules. Keep=
 in mind the NALU header is 2 bytes in H.265 vs. 1 byte in H.264, so the sl=
ice header offsets are different.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">If you can&#8217;t wait for the first N=
ALU of the next frame, it is much harder to detect the last NALU of a frame=
 without full VCL bitstream parsing, unless you use some heuristics
 which may be simpler but less reliable. This is part of the reason why the=
 marker bit in video payloads indicates end of frame, because it may be ver=
y difficult for RTP receivers to detect without deep parsing otherwise. Not=
e that RTP receivers are technically
 forbidden to rely on the marker bit. But many implementations detect wheth=
er it is reliable, then use it as an optimization to minimize latency if re=
liable.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">I don&#8217;t think the draft needs any=
 more text beyond what it currently says.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Mo<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> avt-boun=
ces@ietf.org [mailto:avt-bounces@ietf.org]
<b>On Behalf Of </b>Ross Finlayson<br>
<b>Sent:</b> Wednesday, July 31, 2013 2:19 PM<br>
<b>To:</b> avt@ietf.org<br>
<b>Subject:</b> [AVTCORE] Clarifying the H.264 RTP payload format specifica=
tion's text on when to set the RTP &quot;M&quot; bit<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">As I noted in Wednesday morning's AVTCORE session, t=
he proposed H.265 RTP payload format specification is not as clear as it co=
uld be about how a RTP sender knows when to set the &quot;M&quot; bit on an=
 outgoing RTP packet.<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Currently, the text says:<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp;Marker bit (M): 1 bit<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; &nbsp; Set for the last packet of the =
access unit indicated by the RTP<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; &nbsp; timestamp, in line with the nor=
mal use of the M bit in video<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; &nbsp; formats, to allow an efficient =
playout buffer handling. &nbsp;Decoders<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; &nbsp; can use this bit as an early in=
dication of the last packet of an<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; &nbsp; access unit.<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">There is nothing inherently wrong with this. &nbsp;H=
owever (because we're not in the MPEG world here :-) it's not sufficient to=
 fully specify only how the receivers of RTP packets should behave; we shou=
ld also try to specify, as clearly as possible,
 how the *senders* of RTP packets should behave. &nbsp;We should try to giv=
e at least some guidance about when the NAL unit that's being sent ends an =
&quot;access unit&quot; because -&nbsp;for many implementations - it is not=
 immediately obvious.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">If I were amending the H.264 payload format specific=
ation - which of course I'm not - then I would, hypothetically, add a parag=
raph something like the following:<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">----------<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Unfortunately the contents of a NAL unit, alone, doe=
s not tell a RTP sender implementation whether or not the NAL unit ends an =
access unit. &nbsp;Instead, the implementation can obtain this information =
separately, from the encoder. &nbsp;If, however,
 this information is not directly available from the encoder (e.g., because=
 the implementation is sending data that consists solely of a sequence of p=
re-encoded NAL units), then it must instead inspect the next NAL unit, to d=
etermine whether or not the current
 NAL unit ends an access unit. &nbsp;The following rule can be used:<o:p></=
o:p></p>
</div>
<div>
<p class=3D"MsoNormal">&nbsp; &nbsp; The current NAL unit ends an access un=
it if it is a VCL NAL unit (i.e., if its &quot;nal_unit_type&quot; is in th=
e range [1..5]), and if either:<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- the next NAL unit is=
 not a VCL NAL unit, or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- either the current N=
AL unit's &quot;nal_unit_type&quot; or the next NAL unit's&nbsp;&quot;nal_u=
nit_type&quot; - but not both - is 5 (i.e., &quot;Coded slice of an IDR pic=
ture&quot;), or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- the next NAL unit's =
&quot;nal_ref_idc&quot; field differs from the current NAL unit's&nbsp;&quo=
t;nal_ref_idc&quot; field, with one of them being equal to zero, or<o:p></o=
:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- both the current and=
 next NAL units begin with slice headers, and their &quot;frame_num&quot; f=
ields differ, or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- both the current and=
 next NAL units begin with slice headers, and&nbsp;their&nbsp;&quot;pic_par=
ameter_set_id&quot; fields differ, or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- both the current and=
 next NAL units begin with slice headers, and&nbsp;their&nbsp;&quot;field_p=
ic_flag&quot; fields differ, or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- both the current and=
 next NAL units begin with slice headers, and&nbsp;their&nbsp;&quot;bottom_=
field_flag&quot; fields differ, or<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-tab-span">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>- both the current and=
 next NAL units' &quot;nal_ref_idc&quot; field is 5, and&nbsp;the &quot;idr=
_pic_id&quot; fields differ.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">----------<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">(I derived this rule from Section&nbsp;7.4.1.2.4 - &=
quot;Detection of the first VCL NAL unit of a primary coded picture&quot; -=
 of the H.264 specification. &nbsp;Perhaps it could be simplified?)<o:p></o=
:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I suggest that an analogous paragraph be added to th=
e H.265 RTP payload format specification. &nbsp;(Or alternatively, instead =
of writing a detailed rule like this, perhaps a reference to an appropriate=
 part of the H.265 specification might
 be made instead (can we do this in a IETF RFC?).)<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"font=
-size:13.5pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;;color=
:black">Ross Finlayson</span></span><span style=3D"font-size:13.5pt;font-fa=
mily:&quot;Helvetica&quot;,&quot;sans-serif&quot;;color:black"><br>
<span class=3D"apple-style-span">Live Networks, Inc.</span><br>
<span class=3D"apple-style-span"><a href=3D"http://www.live555.com/">http:/=
/www.live555.com/</a></span></span>
<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7xmbrcdx14ciscoc_--