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> Mon, 12 August 2013 19:25 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 43B1521F9E63; Mon, 12 Aug 2013 12:25:32 -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=[AWL=-0.000, 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 HgLcMt2yMicZ; Mon, 12 Aug 2013 12:25:27 -0700 (PDT)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id A67BC21F9E52; Mon, 12 Aug 2013 12:25:27 -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 r7CJPN4B018049; Mon, 12 Aug 2013 12:25:25 -0700 (PDT) (envelope-from finlayson@live555.com)
From: Ross Finlayson <finlayson@live555.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7"
Message-Id: <B995CF20-66A4-47B9-B141-B650290F8DC7@live555.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Date: Mon, 12 Aug 2013 12:25:23 -0700
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>
To: "avt@ietf.org" <avt@ietf.org>, "payload@ietf.org" <payload@ietf.org>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com>
X-Mailer: Apple Mail (2.1508)
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: Mon, 12 Aug 2013 19:25:32 -0000

> You just need one more little step to get everything right here, instead of thinking of compromising the implementation J
>  
> That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below for convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful information)

Thanks for the info; that was useful.

Here, then is the updated text of a paragraph - to be added after the existing 'M bit' text - that clarifies when/how to set it:
----------
Unfortunately the contents of a NAL unit, alone, do not tell a RTP sender implementation whether or not the NAL unit ends an access unit.  Instead, the implementation may be able to obtain this information separately, from the encoder.  If, however, the implementation cannot obtain this information directly 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 subsequent NAL units, to determine whether or not the NAL unit ends an access unit.  If the NAL units have already been timestamped, then these timestamps can be used to determine the access unit boundaries.  Otherwise, the access unit boundaries (and times) must be determined by inspecting the NAL units' contents - specifically, the "nal_unit_type" and (for VCL NAL units) the "first_slice_segment_in_pic_flag".  The following rule can be used:
	 A NAL unit (X) ends an access unit if the next-occurring VCL NAL unit (Y) has the high-order bit of the first byte after its NAL unit header equal to 1, and all NAL units, if any, between (X) and (Y) have a "nal_unit_type" in one of the following ranges: [32,35], 39, [41,44], or [48,55].
----------

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