Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

"Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> Tue, 02 June 2015 16:26 UTC

Return-Path: <yekuiw@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B241B2AB3; Tue, 2 Jun 2015 09:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj4KrZExQwL2; Tue, 2 Jun 2015 09:26:45 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0322D1B2ACE; Tue, 2 Jun 2015 09:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433262405; x=1464798405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jQpM89HlSYHuA3CoMOrig9Na17DpCldRxGphfZ2arHA=; b=ziLYmSRFi/w+wfe87gpki69zIzxv+0ISqp2ak3KrKWMfUwz1zcNgQG+u luF4w/zyrhHQjTiUXNOdOU7FwSkr446yymA3JL3+fKS1f66qtHpGiR4Rr k0agu0sLfpNMMvRS+5PbTbZNm+F+Zecs29fZ4wku8YRnfyiPA2Xgxlke3 8=;
X-IronPort-AV: E=McAfee;i="5700,7163,7820"; a="91195539"
Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 02 Jun 2015 09:26:45 -0700
X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="33240221"
Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jun 2015 09:26:43 -0700
Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 2 Jun 2015 09:26:43 -0700
Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Tue, 2 Jun 2015 09:26:43 -0700
From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
To: Bo Burman <bo.burman@ericsson.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Stephan Wenger <stewe@stewe.org>, Ben Campbell <ben@nostrum.com>
Thread-Topic: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09
Thread-Index: AQHQlzlcVEvfCj5WRk+v2nDAi0LC1J2PMW4AgAAKOgCAAmWFMIAGRQmAgABHTACAADdXAP//lApQgAFkWACAAERAgP//0V/Q
Date: Tue, 02 Jun 2015 16:26:42 +0000
Message-ID: <04f8a83883304f3cbaef861e9067e6ff@NASANEXM01H.na.qualcomm.com>
References: <31DE4E9A-C2A7-41E3-91BE-BADF559F3084@nostrum.com> <D18A2606.54DCA%stewe@stewe.org> <66FB43F1-7CAF-42B7-ACEA-89FD11EF0EFA@nostrum.com> <4d40fec8cea741178fb2331f5d620245@NASANEXM01H.na.qualcomm.com> <556C29A9.5070409@ericsson.com> <F51A0EAC-6D82-4907-8E55-F57F010EAC63@nostrum.com> <D191DDBA.5531A%stewe@stewe.org> <c31a06b150204989af47c93e77e663d0@NASANEXM01H.na.qualcomm.com> <556D6440.2020309@ericsson.com> <BBE9739C2C302046BD34B42713A1E2A22E5FF635@ESESSMB105.ericsson.se>
In-Reply-To: <BBE9739C2C302046BD34B42713A1E2A22E5FF635@ESESSMB105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/Xp3swZqqwr84y36C6-M3AbupQ80>
Cc: "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-rtp-h265@ietf.org" <draft-ietf-payload-rtp-h265@ietf.org>
Subject: Re: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <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 Jun 2015 16:26:48 -0000

Thanks Bo - the suggested change is indeed an improvement! Thanks Magnus as well for confirming the other change. 

I will now go ahead to make these two changes and submit -11. 

BR, YK

-----Original Message-----
From: Bo Burman [mailto:bo.burman@ericsson.com] 
Sent: Tuesday, June 02, 2015 5:12 AM
To: Magnus Westerlund; Wang, Ye-Kui; Stephan Wenger; Ben Campbell
Cc: draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org
Subject: RE: [payload] WGLC Feedback for draft-ietf-payload-rtp-h265-09

I checked -09 and -10 versions. Besides the comment made by Magnus and the solution suggested below, which I agree to, I  found only the following nit:

Section 4.1, below Figure 2:
OLD:
Marker bit (M): 1 bit
       Set for the last packet carried in the current RTP stream of
       the access unit.  This is in line with the normal use of the M
NEW:
Marker bit (M): 1 bit
       Set for the last packet of the access unit, carried in the current
       RTP stream.  This is in line with the normal use of the M

Cheers,
Bo

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus 
> Westerlund
> Sent: den 2 juni 2015 10:07
> To: Wang, Ye-Kui; Stephan Wenger; Ben Campbell
> Cc: draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org
> Subject: Re: [payload] WGLC Feedback for 
> draft-ietf-payload-rtp-h265-09
> 
> Wang, Ye-Kui skrev den 2015-06-01 20:02:
> > Ben noted earlier (in his initial reviewing comments) that we have 
> > the following use of this bit specified at the end of
> 4.4.3:
> >
> > "A receiver in an endpoint or in a MANE MAY aggregate the first n-1 
> > fragments of a NAL unit to an (incomplete) NAL
> unit, even if fragment n of that NAL unit is not received.  In this 
> case, the forbidden_zero_bit of the NAL unit MUST be set to one to indicate a syntax violation."
> >
> > This is also more-or-less aligned with what Magnus mentioned below.
> >
> > Thus, maybe it is better to remove the UDP-Lite example, and mention its actual use in this document, as follows:.
> >
> > "forbidden_zero_bit.  Required to be zero in [HEVC].  Note that the 
> > inclusion of this bit in the NAL unit header was to
> enable transport of HEVC video over MPEG-2 transport systems 
> (avoidance of start code emulations) [MPEG2S].  In the context of this 
> memo, the value 1 may be used to indicate a syntax violation, e.g. for a NAL unit resulted from aggregating a number of fragmented units of a NAL unit but missing the last fragment, as described in Section 4.4.3."
> >
> > If agreeable, I can quickly update the document and submit -v11.
> 
> Yes, that appears a good solution.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload