Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit

Ross Finlayson <finlayson@live555.com> Tue, 27 August 2013 05:39 UTC

Return-Path: <finlayson@live555.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6815E21F9B18; Mon, 26 Aug 2013 22:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 wL8z-lSQS4pF; Mon, 26 Aug 2013 22:38:58 -0700 (PDT)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id E680F21F99C0; Mon, 26 Aug 2013 22:38:58 -0700 (PDT)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r7R5crrk011687; Mon, 26 Aug 2013 22:38:54 -0700 (PDT) (envelope-from finlayson@live555.com)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2B275B2-78D8-432C-9001-6B09994EF54F"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ross Finlayson <finlayson@live555.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com>
Date: Mon, 26 Aug 2013 22:38:53 -0700
Message-Id: <969F6DF9-BABB-4438-BAC0-E0F36049ED63@live555.com>
References: <C1F36850-2B72-4A98-97B7-8847C9C90CB0@live555.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <A0D9B971-CDE0-4AF7-9A70-C280514AEF10@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <A6FDCB43-F221-4BE0-BEDA-1F1E5394DDEC@live555.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <F5C111A5-64A6-48AB-BBA8-8812EE49F7ED@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <B995CF20-66A4-47B9-B141-B650290F8DC7@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1508)
Cc: "avt@ietf.org" <avt@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 05:39:03 -0000

On Aug 26, 2013, at 9:50 PM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

> Hi Ross,
>  
> Sorry for a slow response. I started to edit this draft today, and have included the following note after the semantics of the M bit:
>  
> Informative note: The content of a NAL unit does not tell whether or not the NAL unit is the last NAL unit, in decoding order, of an access unit.  An RTP sender implementation may obtain this information from the video encoder.  If, however, the implementation cannot obtain this information directly from the encoder, e.g., when the stream was pre-encoded, and also there is no timestamp allocated for each NAL unit, then the sender implementation can inspect subsequent NAL units in decoding order to determine whether or not the NAL unit is the last NAL unit of an access unit as follows.  A NAL unit naluX is the last NAL unit of an access unit if the next VCL NAL unit naluY in decoding order has the high-order bit of the first byte after its NAL unit header equal to 1, and all NAL units between naluX and naluY, when present, have nal_unit_type in the range of 32 to 35, inclusive, equal to 39, in the range of 41 to 44, inclusive, or in the range of 48 to 55, inclusive.
>  
> Would you be fine with this wording?

Yes, this looks good to me.


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