From finlayson@live555.com Sun Aug 4 14:51:59 2013 Return-Path: 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 D0D3311E80D1 for ; Sun, 4 Aug 2013 14:51:59 -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 AMmaUmRN5C7N for ; Sun, 4 Aug 2013 14:51:55 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id B49F321E80A1 for ; Sun, 4 Aug 2013 14:51:52 -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 r74LpmdQ056494 for ; Sun, 4 Aug 2013 14:51:51 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_A7ACE70E-415C-4C18-90D1-AF3EE3C252B2" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Sun, 4 Aug 2013 14:51:48 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> To: "avt@ietf.org" In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [AVTCORE] Clarifying the H.264 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 21:52:00 -0000 --Apple-Mail=_A7ACE70E-415C-4C18-90D1-AF3EE3C252B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > If you are willing to detect the last NALU 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=92s the = first VCL NALU of a frame. This works in H.265 because the slice header = explicitly has such a flag. Thanks. This is exactly the kind of information that would be useful = for implementers. > Note that RTP receivers are technically forbidden to rely on the = marker bit. But many implementations detect whether it is reliable, then = use it as an optimization to minimize latency if reliable. Yes, it's unfortunate that there may be implementations out there that = do not set the RTP 'M' bit correctly. But to reduce the likelihood of = this happening, we should try to make our RTP payload format = specifications as clear as is reasonable about when to set the 'M' bit. = (It is common - in non-interactive environments - for RTP transmitting = applications to obtain their encoded data as a byte stream.) > I don=92t think the draft needs any more text beyond what it = currently says. On the contrary - I think you've explained that some additional text = would be both useful and reasonable. (Once again, because we're not = MPEG, we should not feel the need to fully-specify only the behavior = that's required by RTP *receivers*.) So I suggest adding the following paragraph to the H.265 RTP payload = format specification, just after the existing 'M bit' text: ---------- 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, = and if either: - the next NAL unit is not a VCL NAL unit, or - the next NAL unit is a VCL NAL unit, and the high-order bit of = the first byte after its NALU header is 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_A7ACE70E-415C-4C18-90D1-AF3EE3C252B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
If you are willing to detect the last NALU 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=92s the first VCL NALU of a frame. This works in H.265 = because the slice header explicitly has such a = flag.

Thanks. =  This is exactly the kind of information that would be useful for = implementers.


Note that RTP receivers are technically forbidden to = rely on the marker bit. But many implementations detect whether it is = reliable, then use it as an optimization to minimize latency if = reliable.

Yes, it's = unfortunate that there may be implementations out there that do not set = the RTP 'M' bit correctly.  But to reduce the likelihood of this = happening, we should try to make our RTP payload format specifications = as clear as is reasonable about when to set the 'M' bit.  (It is = common - in non-interactive environments - for RTP transmitting = applications to obtain their encoded data as a byte = stream.)


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

On the = contrary - I think you've explained that some additional text would be = both useful and reasonable.  (Once again, because we're not MPEG, = we should not feel the need to fully-specify only the behavior that's = required by RTP *receivers*.)

So I suggest = adding the following paragraph to the H.265 RTP payload format = specification, just after the existing 'M bit' = text:

----------
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, and if either:
- the = next NAL unit is not a VCL NAL unit, or
- the = next NAL unit is a VCL NAL unit, and the high-order bit of the first = byte after its NALU header is = 1.
----------

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

= --Apple-Mail=_A7ACE70E-415C-4C18-90D1-AF3EE3C252B2-- From finlayson@live555.com Thu Aug 8 20:15:28 2013 Return-Path: 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 27C7A11E8146; Thu, 8 Aug 2013 20:15:28 -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 pxpvQYMp0RLH; Thu, 8 Aug 2013 20:15:23 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47311E80F7; Thu, 8 Aug 2013 20:15:23 -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 r793FKMf011677; Thu, 8 Aug 2013 20:15:21 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B" Message-Id: <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 20:15:19 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , payload@ietf.org In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [AVTCORE] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 03:15:28 -0000 --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (I changed the "Subject:" line to make it clear that we're talking about = the (future) H.265 RTP payload format specification here; not the = (existing) H.264 RTP payload format specification.) > First of all, implementers are expected to have basic knowledge of the = video coding specification itself. Yes. However, in this case we seem to disagree on what constitutes = 'basic knowledge'. Determining whether or not a NAL unit ends an = 'access unit' (in the situation - common for many implementations - = where this is not available directly from the encoder) is far from = 'basic knowledge' of H.265. Unless you can point to a specific section = in the H.265 specification that describes this (in which case we could = add a reference to that section), it seems prudent to add a little text = to our RTP payload format specification that clarifies this. > Of course, bad packetization/sender implementations [of the RTP 'M' = bit] can make that unreliable =96 but bad packetization/sender = implementations can make anything unreliable =96 thus they don=92t = count. I'm not sure what you're saying here. I hope you're not saying that we = shouldn't really care about whether or not implementations set the 'M' = bit correctly, because in that case I definitely disagree; that's the = whole point of this email thread. =20 > Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) > For example, in the following copied part: what is =93the current NAL = unit=94? By this I mean the NAL unit that's being packed in the RTP packet for = which we are considering whether or not to set the "M' bit (or the final = such NAL unit, if there's more than one). =20 > Also, it is possible for non-VCL NAL unit to be between two VCL NAL = units in an AU, the [suggested] language would suggest that the first of = the two VCL NAL unit ends the AU =96 this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to = the H.265 RTP payload format specification, just after the existing 'M = bit' text): ---------- 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 available 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. The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(I changed the "Subject:" = line to make it clear that we're talking about the (future) H.265 RTP = payload format specification here; not the (existing) H.264 RTP payload = format specification.)


First of all, = implementers are expected to have basic knowledge of the video coding = specification = itself.

Yes. =  However, in this case we seem to disagree on what constitutes = 'basic knowledge'.  Determining whether or not a NAL unit ends an = 'access unit' (in the situation - common for many implementations - = where this is not available directly from the encoder) is far from = 'basic knowledge' of H.265.  Unless you can point to a specific = section in the H.265 specification that describes this (in which case we = could add a reference to that section), it seems prudent to add a little = text to our RTP payload format specification that clarifies = this.


Of course, bad = packetization/sender implementations [of the RTP 'M' bit] can make that = unreliable =96 but bad packetization/sender implementations can make = anything unreliable =96 thus they don=92t = count.

I'm not sure = what you're saying here.  I hope you're not saying that we = shouldn't really care about whether or not implementations set the 'M' = bit correctly, because in that case I definitely disagree; that's the = whole point of this email = thread.

 
 Lastly, the = suggested text is too vague and even = incorrect.

Like = Mohamed, you're inadvertently making my point for me = :-)


For example, in = the following copied part: what is =93the current NAL = unit=94?

By this I = mean the NAL unit that's being packed in the RTP packet for which we are = considering whether or not to set the "M' bit (or the final such NAL = unit, if there's more than one). =  


Also, it is = possible for non-VCL NAL unit to be between two VCL NAL units in an AU, = the [suggested] language would suggest that the first of the two VCL NAL = unit ends the AU =96 this is definitely = incorrect.

<= div>
Yes, good point - thanks.

Here, then, = is new wording for the suggested paragraph (to be added to the H.265 RTP = payload format specification, just after the existing 'M bit' = text):

----------
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 available 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. =  The following rule can be used:
    A NAL = unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to = 1.
----------

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


= --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B-- From yekuiw@qti.qualcomm.com Fri Aug 9 06:01:12 2013 Return-Path: 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 2CBFA11E80AD; Fri, 9 Aug 2013 06:01:12 -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 s39h+S-YPU1T; Fri, 9 Aug 2013 06:01:07 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 275E621E804B; Fri, 9 Aug 2013 06:01:05 -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=1376053265; x=1407589265; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NOiR/EXSJrXdjSLmtxt39oCus/g92dlcWPZAssxkv4E=; b=j1jdvJHonJjK6JYxE7QlYrfWvA5foQPslkbafWa3ujBelbxgb37zvf1m vbfGwUWs77ei6CDqajk3e5Le/ssEsV7rJmCoaMbK9+8J4FOI9mZS4mbpq +YDCJJMXDSJJl0ODXqNcz4Ndll5sCPgP19VFLUU44bOw6Iv3LP6TVuSly I=; X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="49272985" Received: from unknown (HELO ironmsg01-lv.qualcomm.com) ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 06:01:03 -0700 Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 06:01:03 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 06:01:03 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlK64MyApD0+0bEyc75pQI3FkapmM0zAQ Date: Fri, 9 Aug 2013 13:01:02 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> In-Reply-To: <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [AVTCORE] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:01:12 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Though I don't think it is not really necessary, I think we can either simp= ly add a note after the semantics of the M bit saying that the first slice = header bit indicates that the slice is the first slice of a picture, or men= tion this as part of the introduction to HEVC. The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. The semantics of the M bit is clearly specified, thus sender implementation= s should follow the semantics. Those implementations that do not follow wha= t is specified, e.g. the M bit semantics, when encapsulating NAL units into= packets, are bad implementations. It seems to me that the reasoning for yo= ur suggestion is that you expect in the future a lot of H.265 RTP payload f= ormat implementations would not follow the M bit. Nobody knows the future, = but I hope this would not happen, as it is so easy to follow the semantics,= and I don't see a reason why implementers would not follow what is being s= pecified. As I explained twice already, not as in RFC 6184, in the context = of the H.265 payload draft, there is no reliability issue with the M bit to= be used for detection the end of an AU (after de-jittering of course - sam= e for all approaches. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Thursday, August 08, 2013 8:15 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit (I changed the "Subject:" line to make it clear that we're talking about th= e (future) H.265 RTP payload format specification here; not the (existing) = H.264 RTP payload format specification.) First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. Yes. However, in this case we seem to disagree on what constitutes 'basic = knowledge'. Determining whether or not a NAL unit ends an 'access unit' (i= n the situation - common for many implementations - where this is not avail= able directly from the encoder) is far from 'basic knowledge' of H.265. Un= less you can point to a specific section in the H.265 specification that de= scribes this (in which case we could add a reference to that section), it s= eems prudent to add a little text to our RTP payload format specification t= hat clarifies this. Of course, bad packetization/sender implementations [of the RTP 'M' bit] ca= n make that unreliable - but bad packetization/sender implementations can m= ake anything unreliable - thus they don't count. I'm not sure what you're saying here. I hope you're not saying that we sho= uldn't really care about whether or not implementations set the 'M' bit cor= rectly, because in that case I definitely disagree; that's the whole point = of this email thread. Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) For example, in the following copied part: what is "the current NAL unit"? By this I mean the NAL unit that's being packed in the RTP packet for which= we are considering whether or not to set the "M' bit (or the final such NA= L unit, if there's more than one). Also, it is possible for non-VCL NAL unit to be between two VCL NAL units i= n an AU, the [suggested] language would suggest that the first of the two V= CL NAL unit ends the AU - this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to the = H.265 RTP payload format specification, just after the existing 'M bit' tex= t): ---------- 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 available 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 subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though I don’t thin= k it is not really necessary, I think we can either simply add a note after= the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 <= /p>

The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 <= /p>

The semantics of the M bi= t is clearly specified, thus sender implementations should follow the seman= tics. Those implementations that do not follow what is specified, e.g. the M bit semantics, when encapsulating NAL units into packets, are b= ad implementations. It seems to me that the reasoning for your suggestion i= s that you expect in the future a lot of H.265 RTP payload format implement= ations would not follow the M bit. Nobody knows the future, but I hope this would not happen, as it is so eas= y to follow the semantics, and I don’t see a reason why implementers = would not follow what is being specified. As I explained twice already, not= as in RFC 6184, in the context of the H.265 payload draft, there is no reliability issue with the M bit to be us= ed for detection the end of an AU (after de-jittering of course – sam= e for all approaches.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Thursday, August 08, 2013 8:15 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

(I changed the "Subject:" line to make it = clear that we're talking about the (future) H.265 RTP payload format specif= ication here; not the (existing) H.264 RTP payload format specification.)

 



First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self.

 

Yes.  However, in this case we seem to disagree= on what constitutes 'basic knowledge'.  Determining whether or not a = NAL unit ends an 'access unit' (in the situation - common for many implemen= tations - where this is not available directly from the encoder) is far from 'basic knowledge' of H.265.  Unless you= can point to a specific section in the H.265 specification that describes = this (in which case we could add a reference to that section), it seems pru= dent to add a little text to our RTP payload format specification that clarifies this.

 

 

Of course, bad packetizat= ion/sender implementations [of the RTP 'M' bit] can make that unreliable &#= 8211; but bad packetization/sender implementations can make anything unreliable – thus they don’t count.

 

I'm not sure what you're saying here.  I hope y= ou're not saying that we shouldn't really care about whether or not impleme= ntations set the 'M' bit correctly, because in that case I definitely disag= ree; that's the whole point of this email thread.

 

 

 Lastly, the suggest= ed text is too vague and even incorrect.

 

Like Mohamed, you're inadvertently making my point f= or me :-)

 

 

For example, in the follo= wing copied part: what is “the current NAL unit”?

 

By this I mean the NAL unit that's being packed in t= he RTP packet for which we are considering whether or not to set the "= M' bit (or the final such NAL unit, if there's more than one).  <= /o:p>

 



Also, it is possible for = non-VCL NAL unit to be between two VCL NAL units in an AU, the [suggested] = language would suggest that the first of the two VCL NAL unit ends the AU – this is definitely incorrect.

 

Yes, good point - thanks.

 

Here, then, is new wording for the suggested paragra= ph (to be added to the H.265 RTP payload format specification, just after t= he existing 'M bit' text):

 

----------

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.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 

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

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Fri Aug 9 08:55:09 2013 Return-Path: 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 1CED621F9F97; Fri, 9 Aug 2013 08:55:09 -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 jrC9bsnBqS2j; Fri, 9 Aug 2013 08:55:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47811E80E6; Fri, 9 Aug 2013 08:47:49 -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=1376063269; x=1407599269; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FNO/iVA6naupcatYyBsy5IGI/cKqRH8G5+YlgEUXQSU=; b=Y0v46xTfg9o7YW2sh5o3loLAoE9NGhYjwP0iZOquWYoKpVoRlUNfARzJ 5bEzoupJcWTOFgnBiD5vXkhZ9WpWhOl2xmCLjVWu2k0Y1mv9g+ndighm0 849JaqU7XgBy+3WoCgYn2Fh/v4wOUdkXBhCOiEybGeWMjlVl7pmdGTnev I=; X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="49280889" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 08:47:45 -0700 X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="581848004" Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 08:47:45 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 08:47:45 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlQCLVlfaHsfVP0SU09HfIMXjqJmNBWbA Date: Fri, 9 Aug 2013 15:47:44 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D6184@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@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_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [AVTCORE] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:55:09 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Typo: "Though I don't think it is not really necessary" -> "Though I don't = think it is really necessary" or "Though I think it is not really necessary= ". From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui Sent: Friday, August 09, 2013 6:01 AM To: Ross Finlayson; avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit Though I don't think it is not really necessary, I think we can either simp= ly add a note after the semantics of the M bit saying that the first slice = header bit indicates that the slice is the first slice of a picture, or men= tion this as part of the introduction to HEVC. The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. The semantics of the M bit is clearly specified, thus sender implementation= s should follow the semantics. Those implementations that do not follow wha= t is specified, e.g. the M bit semantics, when encapsulating NAL units into= packets, are bad implementations. It seems to me that the reasoning for yo= ur suggestion is that you expect in the future a lot of H.265 RTP payload f= ormat implementations would not follow the M bit. Nobody knows the future, = but I hope this would not happen, as it is so easy to follow the semantics,= and I don't see a reason why implementers would not follow what is being s= pecified. As I explained twice already, not as in RFC 6184, in the context = of the H.265 payload draft, there is no reliability issue with the M bit to= be used for detection the end of an AU (after de-jittering of course - sam= e for all approaches. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Ross Finlayson Sent: Thursday, August 08, 2013 8:15 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit (I changed the "Subject:" line to make it clear that we're talking about th= e (future) H.265 RTP payload format specification here; not the (existing) = H.264 RTP payload format specification.) First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. Yes. However, in this case we seem to disagree on what constitutes 'basic = knowledge'. Determining whether or not a NAL unit ends an 'access unit' (i= n the situation - common for many implementations - where this is not avail= able directly from the encoder) is far from 'basic knowledge' of H.265. Un= less you can point to a specific section in the H.265 specification that de= scribes this (in which case we could add a reference to that section), it s= eems prudent to add a little text to our RTP payload format specification t= hat clarifies this. Of course, bad packetization/sender implementations [of the RTP 'M' bit] ca= n make that unreliable - but bad packetization/sender implementations can m= ake anything unreliable - thus they don't count. I'm not sure what you're saying here. I hope you're not saying that we sho= uldn't really care about whether or not implementations set the 'M' bit cor= rectly, because in that case I definitely disagree; that's the whole point = of this email thread. Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) For example, in the following copied part: what is "the current NAL unit"? By this I mean the NAL unit that's being packed in the RTP packet for which= we are considering whether or not to set the "M' bit (or the final such NA= L unit, if there's more than one). Also, it is possible for non-VCL NAL unit to be between two VCL NAL units i= n an AU, the [suggested] language would suggest that the first of the two V= CL NAL unit ends the AU - this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to the = H.265 RTP payload format specification, just after the existing 'M bit' tex= t): ---------- 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 available 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 subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Typo: “Though I don’t think it is not really necessary= ” -> “Though I don’t think = it is really necessary” or “<= /span>Though I think it is not really necessary”= ;.

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Friday, August 09, 2013 6:01 AM
To: Ross Finlayson; avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

Though I don’t thin= k it is not really necessary, I think we can either simply add a note after= the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 <= /p>

The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 <= /p>

The semantics of the M bi= t is clearly specified, thus sender implementations should follow the seman= tics. Those implementations that do not follow what is specified, e.g. the M bit semantics, when encapsulating NAL units into packets, are b= ad implementations. It seems to me that the reasoning for your suggestion i= s that you expect in the future a lot of H.265 RTP payload format implement= ations would not follow the M bit. Nobody knows the future, but I hope this would not happen, as it is so eas= y to follow the semantics, and I don’t see a reason why implementers = would not follow what is being specified. As I explained twice already, not= as in RFC 6184, in the context of the H.265 payload draft, there is no reliability issue with the M bit to be us= ed for detection the end of an AU (after de-jittering of course – sam= e for all approaches.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Thursday, August 08, 2013 8:15 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

(I changed the "Subject:" line to make it = clear that we're talking about the (future) H.265 RTP payload format specif= ication here; not the (existing) H.264 RTP payload format specification.)

 

 

First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self.

 

Yes.  However, in this case we seem to disagree= on what constitutes 'basic knowledge'.  Determining whether or not a = NAL unit ends an 'access unit' (in the situation - common for many implemen= tations - where this is not available directly from the encoder) is far from 'basic knowledge' of H.265.  Unless you= can point to a specific section in the H.265 specification that describes = this (in which case we could add a reference to that section), it seems pru= dent to add a little text to our RTP payload format specification that clarifies this.

 

 

Of course, bad packetizat= ion/sender implementations [of the RTP 'M' bit] can make that unreliable &#= 8211; but bad packetization/sender implementations can make anything unreliable – thus they don’t count.

 

I'm not sure what you're saying here.  I hope y= ou're not saying that we shouldn't really care about whether or not impleme= ntations set the 'M' bit correctly, because in that case I definitely disag= ree; that's the whole point of this email thread.

 

 

 Lastly, the suggest= ed text is too vague and even incorrect.

 

Like Mohamed, you're inadvertently making my point f= or me :-)

 

 

For example, in the follo= wing copied part: what is “the current NAL unit”?

 

By this I mean the NAL unit that's being packed in t= he RTP packet for which we are considering whether or not to set the "= M' bit (or the final such NAL unit, if there's more than one).  <= /o:p>

 

 

Also, it is possible for = non-VCL NAL unit to be between two VCL NAL units in an AU, the [suggested] = language would suggest that the first of the two VCL NAL unit ends the AU – this is definitely incorrect.

 

Yes, good point - thanks.

 

Here, then, is new wording for the suggested paragra= ph (to be added to the H.265 RTP payload format specification, just after t= he existing 'M bit' text):

 

----------

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.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 

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

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_-- From finlayson@live555.com Fri Aug 9 13:17:52 2013 Return-Path: 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 1691921E8094; Fri, 9 Aug 2013 13:17:52 -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 aXFpHIaosvNC; Fri, 9 Aug 2013 13:17:47 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id E2EAF21F9C7A; Fri, 9 Aug 2013 13:11:04 -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 r79KB11Q003736; Fri, 9 Aug 2013 13:11:02 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5" Message-Id: <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 13:11:01 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [AVTCORE] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:17:52 -0000 --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Though I don=92t think it is [] really necessary, I think we can = either simply add a note after the semantics of the M bit saying that = the first slice header bit indicates that the slice is the first slice = of a picture, or mention this as part of the introduction to HEVC. Because the new text is intended to help implementers figure out when to = set the 'M' bit, it should be added just after the existing 'M' bit = text. (But why not just use the paragraph that I suggested?) > The addition is not really necessary because the first slice header = bit is more expected to be used by video decoders for detection of the = start of a new picture without relying on timing (because they might not = be available to the decoder etc), while for the receivers at RTP level, = they can always use the M bit and/or the RTP timestamp. Yes, but that's irrelevant here, because we're talking about how to = clarify the text for implementers of RTP *senders*, not RTP receivers. = (If the current proposed RTP payload format specification were to be = used only by the implementers of H.265/RTP receivers, then I would have = no problem with it. But that's not the case.)=20 > it is so easy to follow the semantics, and I don=92t see a reason why = implementers would not follow what is being specified. The reason is (as I've explained before) that for many RTP sender = implementers who aren't very familiar with the H.265 codec = specification, it will not be immediately obvious whether a NAL unit = ends an access unit. That's why I'm proposing adding a (very small) bit = of extra text to clarify this. I think the core of the disagreement here is that there are two = different views on what a RTP payload format specification should be: One view is that a RTP payload format specification should be the = shortest, most concise possible document that describes how to = send/receive RTP packets for a particular codec, for someone how is = already very familiar with the codec specification. =46rom the = perspective of a codec designer, this point of view makes perfect sense: = The codec specification is the 'core document'; the RTP payload format = specification is logically just an 'appendix'. Therefore, from this = point of view, there seems little sense in adding extra, redundant text = to the RTP payload format document, because it's information that is = already available in the codec specification. However, there are two problems with this point of view. The first = problem is that it makes the specification 'fragile'. Someone who = happens to misread the codec specification is more likely to implement = the RTP payload format incorrectly. The second problem with this point of view is a practical one. Many (if = not most) people who implement RTP payload formats are not codec = experts. They just want to know how to transmit data that they've = received from an encoder, or (on the receiving end) want to know how to = feed data that they've received from a RTP stream into a decoder. It's = not reasonable to expect them to have intimate knowledge of the codec = specification (especially since they may want to implement the RTP = payload formats for several codecs - not just one). Nor will they = always have time to read through the codec specification in detail to = find information that could just as easily have been made available in = the RTP payload format specification. An alternative view of what a RTP payload format should be (and this is = the view that is, I think, is shared by most members of the AVT(CORE) = working group) is that a RTP payload format specification should have = sufficient detail to allow someone to implement the payload format = (sending and/or receiving), even if they have only a limited knowledge = of the codec specification. Even if this means adding text to the RTP = payload format specification that might - from the point of view of the = codec designer - seem somewhat redundant. I hope this helps you understand why adding just a small bit of = redundant text (such as the paragraph I suggested) to the RTP payload = format specification (after the existing 'M' bit text) will help = implementers, and makes it more likely that they will implement the RTP = payload format correctly. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Though I don=92t think = it is [] really necessary, I think we can either simply add a note after = the semantics of the M bit saying that the first slice header bit = indicates that the slice is the first slice of a picture, or mention = this as part of the introduction to = HEVC.

Because the = new text is intended to help implementers figure out when to set the 'M' = bit, it should be added just after the existing 'M' bit text.  (But = why not just use the paragraph that I = suggested?)


The addition is not = really necessary because the first slice header bit is more expected to = be used by video decoders for detection of the start of a new picture = without relying on timing (because they might not be available to the = decoder etc), while for the receivers at RTP level, they can always use = the M bit and/or the RTP = timestamp.

Yes, but = that's irrelevant here, because we're talking about how to clarify the = text for implementers of RTP *senders*, not RTP receivers.  (If the = current proposed RTP payload format specification were to be used only = by the implementers of H.265/RTP receivers, then I would have no problem = with it.  But that's not the = case.) 


it is so easy to = follow the semantics, and I don=92t see a reason why implementers would = not follow what is being = specified.

The = reason is (as I've explained before) that for many RTP sender = implementers who aren't very familiar with the H.265 codec = specification, it will not be immediately obvious whether a NAL unit = ends an access unit.  That's why I'm proposing adding a (very = small) bit of extra text to clarify this.

I = think the core of the disagreement here is that there are two different = views on what a RTP payload format specification should = be:

One view is that a RTP payload format = specification should be the shortest, most concise possible document = that describes how to send/receive RTP packets for a particular codec, = for someone how is already very familiar with the codec specification. =  =46rom the perspective of a codec designer, this point of view = makes perfect sense: The codec specification is the 'core document'; the = RTP payload format specification is logically just an 'appendix'. =  Therefore, from this point of view, there seems little sense in = adding extra, redundant text to the RTP payload format document, because = it's information that is already available in the codec = specification.

However, there are two problems = with this point of view.  The first problem is that it makes the = specification 'fragile'.  Someone who happens to misread the codec = specification is more likely to implement the RTP payload format = incorrectly.

The second problem with this point = of view is a practical one.  Many (if not most) people who = implement RTP payload formats are not codec experts.  They = just want to know how to transmit data that they've received from = an encoder, or (on the receiving end) want to know how to feed data that = they've received from a RTP stream into a decoder.  It's not = reasonable to expect them to have intimate knowledge of the codec = specification (especially since they may want to implement the RTP = payload formats for several codecs - not just one).  Nor will they = always have time to read through the codec specification in detail to = find information that could just as easily have been made available in = the RTP payload format specification.

An = alternative view of what a RTP payload format should be (and this is the = view that is, I think, is shared by most members of the AVT(CORE) = working group) is that a RTP payload format specification should have = sufficient detail to allow someone to implement the payload format = (sending and/or receiving), even if they have only a limited knowledge = of the codec specification.  Even if this means adding text to the = RTP payload format specification that might - from the point of view of = the codec designer - seem somewhat redundant.

I = hope this helps you understand why adding just a small bit of redundant = text (such as the paragraph I suggested) to the RTP payload format = specification (after the existing 'M' bit text) will help implementers, = and makes it more likely that they will implement the RTP payload format = correctly.


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

= --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5-- From yekuiw@qti.qualcomm.com Thu Aug 8 09:40:51 2013 Return-Path: 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 BCF2A21E80AC; Thu, 8 Aug 2013 09:40:51 -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 PY80VgetGYmg; Thu, 8 Aug 2013 09:40:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E53111E81D0; Thu, 8 Aug 2013 09:40:42 -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=1375980042; x=1407516042; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bbxBnlLRIwouq1oJoNdAuIWKJkP2gndje5tGVBiTScw=; b=wc2NvinrUWbuCkR7VHWvfuUSQ0vLGM+L42GVMDk3hk0nOQzp9SiNMI0z 2TybT76LzXn/2y+SdrpOAZa5IeV2ZupZChOMmHVuIRqLkw+KI0b6qFK2y H7xJ5Mrt5X4jyP73hs0KAT4JY8fA+D9tcocHIuSQc94cAhFLIyoNAGRp0 c=; X-IronPort-AV: E=Sophos;i="4.89,840,1367996400"; d="scan'208,217";a="49099242" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 08 Aug 2013 09:40:42 -0700 X-IronPort-AV: E=Sophos;i="4.89,840,1367996400"; d="scan'208,217";a="517814667" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Aug 2013 09:40:25 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0146.002; Thu, 8 Aug 2013 09:40:16 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@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: AQHOkVzkeMqFQ9EXC0GCRYYICjI/eZmLhfPA Date: Thu, 8 Aug 2013 16:40:15 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Aug 2013 14:22:42 -0700 Subject: Re: [AVTCORE] Clarifying the H.264 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:40:51 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I share Mo's opinion here that there is no need to add additional text to t= he H.264 or the H.265 draft in this aspect, rather the semantics of the M b= it is sufficient. First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. If we try to explain all the coding-level de= tails, there can be a lot. Secondly, as I mentioned in the avtcore session in Berlin, the M bit for H.= 264 payload format is not reliable because RFC 6184 supports multi-time agg= regation packets (MTAPs). This is not an issue any more in the H.265 payloa= d as MTAPs are not supported anymore, thus the M bit can be a reliable indi= cation. Of course, bad packetization/sender implementations can make that u= nreliable - but bad packetization/sender implementations can make anything = unreliable - thus they don't count. Lastly, the suggested text is too vague and even incorrect. For example, in= the following copied part: what is "the current NAL unit"? Also, it is pos= sible for non-VCL NAL unit to be between two VCL NAL units in an AU, the fo= llowing language would suggest that the first of the two VCL NAL unit ends = the AU - this is definitely incorrect. The current NAL unit ends an access unit if it is a VCL NAL unit, and i= f either: - the next NAL unit is not a VCL NAL unit, or - the next NAL unit is a VCL NAL unit, and the high-order bit o= f the first byte after its NALU header is 1. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Sunday, August 04, 2013 2:52 PM To: avt@ietf.org Subject: Re: [AVTCORE] Clarifying the H.264 RTP payload format specificatio= n's text on when to set the RTP "M" bit 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. Thanks. This is exactly the kind of information that would be useful for i= mplementers. Note that RTP receivers are technically forbidden to rely on the marker bit= . But many implementations detect whether it is reliable, then use it as an= optimization to minimize latency if reliable. Yes, it's unfortunate that there may be implementations out there that do n= ot set the RTP 'M' bit correctly. But to reduce the likelihood of this hap= pening, we should try to make our RTP payload format specifications as clea= r as is reasonable about when to set the 'M' bit. (It is common - in non-i= nteractive environments - for RTP transmitting applications to obtain their= encoded data as a byte stream.) I don't think the draft needs any more text beyond what it currently says. On the contrary - I think you've explained that some additional text would = be both useful and reasonable. (Once again, because we're not MPEG, we sho= uld not feel the need to fully-specify only the behavior that's required by= RTP *receivers*.) So I suggest adding the following paragraph to the H.265 RTP payload format= specification, just after the existing 'M bit' text: ---------- 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, and i= f either: - the next NAL unit is not a VCL NAL unit, or - the next NAL unit is a VCL NAL unit, and the high-order bit of = the first byte after its NALU header is 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I share Mo’s opinio= n here that there is no need to add additional text to the H.264 or the H.2= 65 draft in this aspect, rather the semantics of the M bit is sufficient.

 <= /p>

First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self. If we try to explain all the coding-level details, there can be a lot.

 <= /p>

Secondly, as I mentioned = in the avtcore session in Berlin, the M bit for H.264 payload format is not= reliable because RFC 6184 supports multi-time aggregation packets (MTAPs). This is not an issue any more in the H.265 payload as MTA= Ps are not supported anymore, thus the M bit can be a reliable indication. = Of course, bad packetization/sender implementations can make that unreliabl= e – but bad packetization/sender implementations can make anything unreliable – thus they don’t= count.

 <= /p>

Lastly, the suggested tex= t is too vague and even incorrect. For example, in the following copied par= t: what is “the current NAL unit”? Also, it is possible for non-VCL NAL unit to be between two VCL NAL units in an AU, the followi= ng language would suggest that the first of the two VCL NAL unit ends the A= U – this is definitely incorrect.

    The current NAL unit ends an access un= it if it is a VCL NAL unit, and if either:

   &nb= sp;        - the next NAL unit is= not a VCL NAL unit, or

   &nb= sp;        - the next NAL unit is= a VCL NAL unit, and the high-order bit of the first byte after its NALU he= ader is 1.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Sunday, August 04, 2013 2:52 PM
To: avt@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.264 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

If you are willing to de= tect the last NALU 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’s the first VCL NALU of a= frame. This works in H.265 because the slice header explicitly has such a = flag.

 

Thanks.  This is exactly the kind of informatio= n that would be useful for implementers.

 



Note that RTP receivers = are technically forbidden to rely on the marker bit. But many implementatio= ns detect whether it is reliable, then use it as an optimization to minimize latency if reliable.

 

Yes, it's unfortunate that there may be implementati= ons out there that do not set the RTP 'M' bit correctly.  But to reduc= e the likelihood of this happening, we should try to make our RTP payload f= ormat specifications as clear as is reasonable about when to set the 'M' bit.  (It is common - in non-interactive en= vironments - for RTP transmitting applications to obtain their encoded data= as a byte stream.)

 



 I don’t thin= k the draft needs any more text beyond what it currently says.

 

On the contrary - I think you've explained that some= additional text would be both useful and reasonable.  (Once again, be= cause we're not MPEG, we should not feel the need to fully-specify only the= behavior that's required by RTP *receivers*.)

 

So I suggest adding the following paragraph to the H= .265 RTP payload format specification, just after the existing 'M bit' text= :

 

----------

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.  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 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.  The following rule can be used:

    The current NAL unit ends an access un= it if it is a VCL NAL unit, and if either:

   &nb= sp;      - the next NAL unit is not a VCL N= AL unit, or

   &nb= sp;      - the next NAL unit is a VCL NAL u= nit, and the high-order bit of the first byte after its NALU header is 1.

----------

 

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

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Fri Aug 9 15:57:29 2013 Return-Path: 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 366F921F9D95; Fri, 9 Aug 2013 15:57:29 -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 X3dcci-uWxSS; Fri, 9 Aug 2013 15:57:15 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 379E821F9E62; Fri, 9 Aug 2013 15:49:37 -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=1376088577; x=1407624577; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=frnj6wymdAI+6Byk9Pgll+5O5lk6+2+IKWIM8NQNT8c=; b=KtklqgjW5XzTgsP1hUR1DzkAS2NGoWejPZMMr4qahLD2LEvtHIIoH2ji +Atk2sxaS5T5xVVBkb+9rD1v2mlReVwXhKGo0MobqNDXnccGj31KOKjQ5 zL5cv/Z4sZv1N6URPFg7F2cvtDey6BI2qGVMsND7MXQHf5sSq/qezOyXP U=; X-IronPort-AV: E=Sophos;i="4.89,849,1367996400"; d="scan'208,217";a="49306333" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 15:49:36 -0700 X-IronPort-AV: E=Sophos;i="4.89,848,1367996400"; d="scan'208,217";a="582022121" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 15:49:35 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 15:49:35 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlK64MyApD0+0bEyc75pQI3FkapmM0zAQgADx7oD//7IbsA== Date: Fri, 9 Aug 2013 22:49:34 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> In-Reply-To: <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.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: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:57:29 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now I understand your intention better - did not see that the note was inte= nded for sender implementers. For this purpose, indeed (as Mo pointed out earlier?) that first of all, th= e sender needs make sure the RTP timestamp for each RTP packet is correct. = As long as RTP timestamp is correct, it is also easy to know when the M bit= should be set. Or are you saying that there is no problem with RTP timesta= mp setting but there is a problem for the M bit setting? If yes, please cla= rify why. I have no problem to putting some information in the line as you suggested,= if the suggested text is good. However, the suggested wording below still = has a few problems (or shortcomings). ---------- 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 available 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 subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- The problems (or shortcomings) are: - I don't think it is good to say that the fact that a NAL unit it= self does not indicate whether it is the last one of an AU is unfortunate. - Saying that the information can be obtained from the encoder is = vague to me. I guess you meant the bitstream instead, as the encoder may be= absent e.g. when dealing pre-encoded video. - Saying that inspecting subsequent NAL units is a must is not rea= lly correct, as I believe timing information can be used too - as mentioned= above, you got to make sure the RTP timestamp value is correctly set anywa= y. - Last but not least, an AU may also end with a non-VCL NAL unit, = e.g. a filler data NAL unit, an end of sequence NAL unit, an end of bitstre= am NAL unit, a suffix SEI NAL unit, etc. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Ross Finlayson Sent: Friday, August 09, 2013 1:11 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Though I don't think it is [] really necessary, I think we can either simpl= y add a note after the semantics of the M bit saying that the first slice h= eader bit indicates that the slice is the first slice of a picture, or ment= ion this as part of the introduction to HEVC. Because the new text is intended to help implementers figure out when to se= t the 'M' bit, it should be added just after the existing 'M' bit text. (B= ut why not just use the paragraph that I suggested?) The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. Yes, but that's irrelevant here, because we're talking about how to clarify= the text for implementers of RTP *senders*, not RTP receivers. (If the cu= rrent proposed RTP payload format specification were to be used only by the= implementers of H.265/RTP receivers, then I would have no problem with it.= But that's not the case.) it is so easy to follow the semantics, and I don't see a reason why impleme= nters would not follow what is being specified. The reason is (as I've explained before) that for many RTP sender implement= ers who aren't very familiar with the H.265 codec specification, it will no= t be immediately obvious whether a NAL unit ends an access unit. That's wh= y I'm proposing adding a (very small) bit of extra text to clarify this. I think the core of the disagreement here is that there are two different v= iews on what a RTP payload format specification should be: One view is that a RTP payload format specification should be the shortest,= most concise possible document that describes how to send/receive RTP pack= ets for a particular codec, for someone how is already very familiar with t= he codec specification. From the perspective of a codec designer, this poi= nt of view makes perfect sense: The codec specification is the 'core docume= nt'; the RTP payload format specification is logically just an 'appendix'. = Therefore, from this point of view, there seems little sense in adding ext= ra, redundant text to the RTP payload format document, because it's informa= tion that is already available in the codec specification. However, there are two problems with this point of view. The first problem= is that it makes the specification 'fragile'. Someone who happens to misr= ead the codec specification is more likely to implement the RTP payload for= mat incorrectly. The second problem with this point of view is a practical one. Many (if no= t most) people who implement RTP payload formats are not codec experts. Th= ey just want to know how to transmit data that they've received from an enc= oder, or (on the receiving end) want to know how to feed data that they've = received from a RTP stream into a decoder. It's not reasonable to expect t= hem to have intimate knowledge of the codec specification (especially since= they may want to implement the RTP payload formats for several codecs - no= t just one). Nor will they always have time to read through the codec spec= ification in detail to find information that could just as easily have been= made available in the RTP payload format specification. An alternative view of what a RTP payload format should be (and this is the= view that is, I think, is shared by most members of the AVT(CORE) working = group) is that a RTP payload format specification should have sufficient de= tail to allow someone to implement the payload format (sending and/or recei= ving), even if they have only a limited knowledge of the codec specificatio= n. Even if this means adding text to the RTP payload format specification = that might - from the point of view of the codec designer - seem somewhat r= edundant. I hope this helps you understand why adding just a small bit of redundant t= ext (such as the paragraph I suggested) to the RTP payload format specifica= tion (after the existing 'M' bit text) will help implementers, and makes it= more likely that they will implement the RTP payload format correctly. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now I understand your int= ention better – did not see that the note was intended for sender imp= lementers. 

 <= /p>

For this purpose, indeed = (as Mo pointed out earlier?) that first of all, the sender needs make sure = the RTP timestamp for each RTP packet is correct. As long as RTP timestamp is correct, it is also easy to know when the M bit should= be set. Or are you saying that there is no problem with RTP timestamp sett= ing but there is a problem for the M bit setting? If yes, please clarify wh= y.

 <= /p>

I have no problem to putt= ing some information in the line as you suggested, if the suggested text is= good. However, the suggested wording below still has a few problems (or shortcomings).

 <= /p>

----------

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.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 <= /p>

The problems (or shortcom= ings) are:

- =          I don’t thi= nk it is good to say that the fact that a NAL unit itself does not indicate= whether it is the last one of an AU is unfortunate.

- =          Saying that the i= nformation can be obtained from the encoder is vague to me. I guess you mea= nt the bitstream instead, as the encoder may be absent e.g. when dealing pre-encoded video.

- =          Saying that inspe= cting subsequent NAL units is a must is not really correct, as I believe ti= ming information can be used too – as mentioned above, you got to make sure the RTP timestamp value is correctly set anyway.=

- =          Last but not leas= t, an AU may also end with a non-VCL NAL unit, e.g. a filler data NAL unit,= an end of sequence NAL unit, an end of bitstream NAL unit, a suffix SEI NAL unit, etc.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 1:11 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Though I don’t thin= k it is [] really necessary, I think we can either simply add a note after = the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 

Because the new text is intended to help implementer= s figure out when to set the 'M' bit, it should be added just after the exi= sting 'M' bit text.  (But why not just use the paragraph that I sugges= ted?)

 



The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 

Yes, but that's irrelevant here, because we're talki= ng about how to clarify the text for implementers of RTP *senders*, not RTP= receivers.  (If the current proposed RTP payload format specification= were to be used only by the implementers of H.265/RTP receivers, then I would have no problem with it.  But th= at's not the case.) 

 

 

it is so easy to follow t= he semantics, and I don’t see a reason why implementers would not fol= low what is being specified.

 

The reason is (as I've explained before) that for ma= ny RTP sender implementers who aren't very familiar with the H.265 codec sp= ecification, it will not be immediately obvious whether a NAL unit ends an = access unit.  That's why I'm proposing adding a (very small) bit of extra text to clarify this.

 

I think the core of the disagreement here is that th= ere are two different views on what a RTP payload format specification shou= ld be:

 

One view is that a RTP payload format specification = should be the shortest, most concise possible document that describes how t= o send/receive RTP packets for a particular codec, for someone how is alrea= dy very familiar with the codec specification.  From the perspective of a codec designer, this point of view makes p= erfect sense: The codec specification is the 'core document'; the RTP paylo= ad format specification is logically just an 'appendix'.  Therefore, f= rom this point of view, there seems little sense in adding extra, redundant text to the RTP payload format document, = because it's information that is already available in the codec specificati= on.

 

However, there are two problems with this point of v= iew.  The first problem is that it makes the specification 'fragile'. =  Someone who happens to misread the codec specification is more likely= to implement the RTP payload format incorrectly.

 

The second problem with this point of view is a prac= tical one.  Many (if not most) people who implement RTP payload format= s are not codec experts.  They just want to know how to transmit = data that they've received from an encoder, or (on the receiving end) want to know how to feed data that they've received fro= m a RTP stream into a decoder.  It's not reasonable to expect them to = have intimate knowledge of the codec specification (especially since they m= ay want to implement the RTP payload formats for several codecs - not just one).  Nor will they always hav= e time to read through the codec specification in detail to find informatio= n that could just as easily have been made available in the RTP payload for= mat specification.

 

An alternative view of what a RTP payload format sho= uld be (and this is the view that is, I think, is shared by most members of= the AVT(CORE) working group) is that a RTP payload format specification sh= ould have sufficient detail to allow someone to implement the payload format (sending and/or receiving), even i= f they have only a limited knowledge of the codec specification.  Even= if this means adding text to the RTP payload format specification that mig= ht - from the point of view of the codec designer - seem somewhat redundant.

 

I hope this helps you understand why adding just a s= mall bit of redundant text (such as the paragraph I suggested) to the RTP p= ayload format specification (after the existing 'M' bit text) will help imp= lementers, and makes it more likely that they will implement the RTP payload format correctly.

 

 

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

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_-- From finlayson@live555.com Fri Aug 9 17:54:18 2013 Return-Path: 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 E184111E81A8; Fri, 9 Aug 2013 17:54:17 -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 9cy+Lq+D9p5x; Fri, 9 Aug 2013 17:54:09 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8839E21F9BFF; Fri, 9 Aug 2013 17:47:54 -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 r7A0lpd0092379; Fri, 9 Aug 2013 17:47:52 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 17:47:50 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:54:18 -0000 --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Now I understand your intention better =96 did not see that the note = was intended for sender implementers.=20 OK, thanks. > For this purpose, indeed (as Mo pointed out earlier?) that first of = all, the sender needs make sure the RTP timestamp for each RTP packet is = correct. As long as RTP timestamp is correct, it is also easy to know = when the M bit should be set. Or are you saying that there is no problem = with RTP timestamp setting but there is a problem for the M bit setting? = If yes, please clarify why. Figuring out the RTP timestamp isn't (nearly as much of) a problem, = because this can be done by knowing the stream's frame rate. But in = this email thread, I'm focusing only on the RTP 'M' bit, because for it = (unlike the timestamp) there's less of an incentive for a sender = implementation to 'get it right'. I'm worried that if the RTP payload = format specification doesn't make it crystal clear when a NAL unit ends = an 'access unit', then an implementer might be tempted to just not = bother setting the bit at all. I don't want to see that happen. Hence = this email thread. > I have no problem to putting some information in the line as you = suggested, if the suggested text is good. However, the suggested wording = below still has a few problems (or shortcomings). > =20 > ---------- > 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 available 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. The following rule can be used: > A NAL unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to 1. > ---------- > =20 > The problems (or shortcomings) are: > - I don=92t think it is good to say that the fact that a NAL = unit itself does not indicate whether it is the last one of an AU is = unfortunate. Why not? It *is* "unfortunate". I'm not intending to 'insult' H.265 = here :-) > - Saying that the information can be obtained from the = encoder is vague to me. I guess you meant the bitstream instead, as the = encoder may be absent e.g. when dealing pre-encoded video. I think you may have been confused by my use of the word "can" in the = 2nd sentence of my proposed paragraph. Here is a rewording of the 2nd = (& 3rd) sentences; I hope this will make things clearer: "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." > - Last but not least, an AU may also end with a non-VCL NAL = unit, e.g. a filler data NAL unit, an end of sequence NAL unit, an end = of bitstream NAL unit, a suffix SEI NAL unit, etc. Arggh! Now, I hope, you see the problem :-) Can you then help me = figure out a more accurate wording for the rule? In particular: 1/ Suppose we have a VCL NAL unit, followed immediately by = another VCL NAL unit with the first slice header bit set. In this case, = there's no doubt: The first VCL NAL unit definitely ends an 'access = unit' - correct? 2/ Suppose we have a VCL NAL unit, followed by a sequence of one = or more non-VCL NAL units, followed immediately by a VCL NAL unit with = the first slice header bit set. In this case, which (if any) of the = non-VCL NAL units ends an 'access unit'? Can we figure out a rule = (ideally, an easy rule, based solely on the "nal_unit_type"s) for this? Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Now I understand your = intention better =96 did not see that the note was intended for sender = implementers. 

OK= , thanks.


 For this purpose, = indeed (as Mo pointed out earlier?) that first of all, the sender needs = make sure the RTP timestamp for each RTP packet is correct. As long as = RTP timestamp is correct, it is also easy to know when the M bit should = be set. Or are you saying that there is no problem with RTP timestamp = setting but there is a problem for the M bit setting? If yes, please = clarify = why.

Figuring out = the RTP timestamp isn't (nearly as much of) a problem, because this can = be done by knowing the stream's frame rate.  But in this email = thread, I'm focusing only on the RTP 'M' bit, because for it (unlike the = timestamp) there's less of an incentive for a sender implementation to = 'get it right'.  I'm worried that if the RTP payload format = specification doesn't make it crystal clear when a NAL unit ends an = 'access unit', then an implementer might be tempted to just not bother = setting the bit at all.  I don't want to see that happen. =  Hence this email thread.


I have no problem = to putting some information in the line as you suggested, if the = suggested text is good. However, the suggested wording below still has a = few problems (or shortcomings).
 
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 available 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. =  The following rule can be used:
    A NAL unit ends an access unit if it = is a VCL NAL unit, and the next-occurring VCL NAL unit has the = high-order bit of the first byte after its NALU header equal to = 1.
 
The problems (or shortcomings) = are:
- I don=92t think it is good to say that the fact that = a NAL unit itself does not indicate whether it is the last one of an AU = is unfortunate.

Why = not?  It *is* "unfortunate".  I'm not intending to 'insult' = H.265 here :-)


 Saying that the information can be obtained from the = encoder is vague to me. I guess you meant the bitstream instead, as the = encoder may be absent e.g. when dealing pre-encoded = video.

I think you = may have been confused by my use of the word "can" in the 2nd sentence = of my proposed paragraph.  Here is a rewording of the 2nd (& = 3rd) sentences; I hope this will make things = clearer:

"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."


-Last but not least, an = AU may also end with a non-VCL NAL unit, e.g. a filler data NAL unit, an = end of sequence NAL unit, an end of bitstream NAL unit, a suffix SEI NAL = unit, = etc.

Arggh! =  Now, I hope, you see the problem :-)  Can you then help me = figure out a more accurate wording for the rule?  In = particular:
= 1/ Suppose we have a VCL NAL unit, followed immediately by = another VCL NAL unit with the first slice header bit set.  In this = case, there's no doubt: The first VCL NAL unit definitely ends an = 'access unit' - correct?
2/ Suppose we have a VCL NAL = unit, followed by a sequence of one or more non-VCL NAL units, followed = immediately by a VCL NAL unit with the first slice header bit set. =  In this case, which (if any) of the non-VCL NAL units ends an = 'access unit'?  Can we figure out a rule (ideally, an easy rule, = based solely on the "nal_unit_type"s) for this?


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

= --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3-- From mzanaty@cisco.com Fri Aug 9 20:21:47 2013 Return-Path: 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 0A1631F0D5B; Fri, 9 Aug 2013 20:21:47 -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 HPwTbovYkQqr; Fri, 9 Aug 2013 20:21:41 -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 07C5D11E80E1; Fri, 9 Aug 2013 20:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24516; q=dns/txt; s=iport; t=1376104509; x=1377314109; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9nMqi7xSAthD1UZc7OOTUeCL9yC5XS7sbLhDJVSJ9qU=; b=WoadOQubo3H5A7PLk7AOqbThmU1IDxJOi7YM7uYiIyEzy2ptuZLEoSpu H16mYSKYZFKFXQatdh2BJ6mK9cIrSOEX7NpdA8f+Zwm88IVb+ES0zefeV /mZeo3+3QMHO1CeDbYWtz9aJCKciEdnHtpRZQhRRYgAMW+OxIH2KsMHN5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFANSvBVKtJXG//2dsb2JhbABbgkJENVC9SwGBDoEcFnSCJAEBAQQtXAIBCBEEAQELFgMEBzIUCQgCBAESCIgIuEuObIEVNwGDGnUDlAuVJoFhgTqBcTk X-IronPort-AV: E=Sophos;i="4.89,849,1367971200"; d="scan'208,217";a="245494983" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 10 Aug 2013 03:15:04 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7A3F3H2030968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Aug 2013 03:15:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 22:15:02 -0500 From: "Mo Zanaty (mzanaty)" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlWQpaJZ07kYRdUCcKb/5v960lpmNqdXA Date: Sat, 10 Aug 2013 03:15:02 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.195] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 03:21:47 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, If we focus on the RTP timestamp rather than the marker bit, I think we wil= l solve your problem. The timestamp MUST be set reliably since it is critic= al for many RTP functions. The marker bit SHOULD be set reliably to allow r= eceivers to detect end of frame without waiting for the next frame/timestam= p, but this is not a MUST because it is just a latency optimization rather = than a critical function. If you are unable to set the RTP timestamp reliably, that is a much bigger = issue than the marker bit. That would be an entirely different discussion, = so I assume that is not the case. If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. In that case, you can set th= e marker bit based on the timestamp changing, assuming you are willing to w= ait for the next frame/timestamp before sending the last packet of a frame. But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender, but the latency remains the same. In both cases you incur the extra= latency between the last packet of a frame and the first packet of the nex= t frame. If the sender incurs this latency to make the marker bit reliable, the rece= iver will hopefully detect that it is reliable and not incur further latenc= y. However, a simple receiver may incur further latency if it only looks fo= r timestamp changes and has no logic to detect marker reliability to optimi= ze out this latency. Also, if the receiver jitter buffer is currently longe= r than the extra latency added by the sender, then the sender added the ext= ra latency unnecessarily. If the sender never sets the marker bit to avoid adding latency, the receiv= er will incur the latency once it sees the marker bit is unreliable (or unc= onditionally for simple receivers that only look for timestamp changes). So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. Regards, Mo From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Friday, August 09, 2013 8:48 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Now I understand your intention better - did not see that the note was inte= nded for sender implementers. OK, thanks. For this purpose, indeed (as Mo pointed out earlier?) that first of all, t= he sender needs make sure the RTP timestamp for each RTP packet is correct.= As long as RTP timestamp is correct, it is also easy to know when the M bi= t should be set. Or are you saying that there is no problem with RTP timest= amp setting but there is a problem for the M bit setting? If yes, please cl= arify why. Figuring out the RTP timestamp isn't (nearly as much of) a problem, because= this can be done by knowing the stream's frame rate. But in this email th= read, I'm focusing only on the RTP 'M' bit, because for it (unlike the time= stamp) there's less of an incentive for a sender implementation to 'get it = right'. I'm worried that if the RTP payload format specification doesn't m= ake it crystal clear when a NAL unit ends an 'access unit', then an impleme= nter might be tempted to just not bother setting the bit at all. I don't w= ant to see that happen. Hence this email thread. I have no problem to putting some information in the line as you suggested,= if the suggested text is good. However, the suggested wording below still = has a few problems (or shortcomings). ---------- 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 available 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 subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- The problems (or shortcomings) are: - I don't think it is good to say that the fact that a NAL unit it= self does not indicate whether it is the last one of an AU is unfortunate. Why not? It *is* "unfortunate". I'm not intending to 'insult' H.265 here = :-) - Saying that the information can be obtained from the encoder is = vague to me. I guess you meant the bitstream instead, as the encoder may be= absent e.g. when dealing pre-encoded video. I think you may have been confused by my use of the word "can" in the 2nd s= entence of my proposed paragraph. Here is a rewording of the 2nd (& 3rd) s= entences; I hope this will make things clearer: "Instead, the implementation may be able to obtain this informa= tion separately, from the encoder. If, however, the implementation cannot = obtain this information directly from the encoder (e.g., because the implem= entation 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." - Last but not least, an AU may also end with a non-VCL NAL unit, = e.g. a filler data NAL unit, an end of sequence NAL unit, an end of bitstre= am NAL unit, a suffix SEI NAL unit, etc. Arggh! Now, I hope, you see the problem :-) Can you then help me figure o= ut a more accurate wording for the rule? In particular: 1/ Suppose we have a VCL NAL unit, followed immediately by anot= her VCL NAL unit with the first slice header bit set. In this case, there'= s no doubt: The first VCL NAL unit definitely ends an 'access unit' - corre= ct? 2/ Suppose we have a VCL NAL unit, followed by a sequence of on= e or more non-VCL NAL units, followed immediately by a VCL NAL unit with th= e first slice header bit set. In this case, which (if any) of the non-VCL = NAL units ends an 'access unit'? Can we figure out a rule (ideally, an eas= y rule, based solely on the "nal_unit_type"s) for this? Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

If we focus on the RTP timestamp rather= than the marker bit, I think we will solve your problem. The timestamp MUS= T be set reliably since it is critical for many RTP functions. The marker bit SHOULD be set reliably to allow receivers to detect end of = frame without waiting for the next frame/timestamp, but this is not a MUST = because it is just a latency optimization rather than a critical function.<= o:p>

 

If you are unable to set the RTP timest= amp reliably, that is a much bigger issue than the marker bit. That would b= e an entirely different discussion, so I assume that is not the case.

 

If you are able to set the RTP timestam= p reliably, then you must already have some sort of frame boundary identifi= cation. In that case, you can set the marker bit based on the timestamp changing, assuming you are willing to wait for the next fram= e/timestamp before sending the last packet of a frame.

 

But you should realize that, in doing t= his, you have defeated the marker bit optimization. You have just shifted t= he latency from the receiver to the sender, but the latency remains the same. In both cases you incur the extra latency between the la= st packet of a frame and the first packet of the next frame.

 

If the sender incurs this latency to ma= ke the marker bit reliable, the receiver will hopefully detect that it is r= eliable and not incur further latency. However, a simple receiver may incur further latency if it only looks for timestamp changes = and has no logic to detect marker reliability to optimize out this latency.= Also, if the receiver jitter buffer is currently longer than the extra lat= ency added by the sender, then the sender added the extra latency unnecessarily.

 

If the sender never sets the marker bit= to avoid adding latency, the receiver will incur the latency once it sees = the marker bit is unreliable (or unconditionally for simple receivers that only look for timestamp changes).

 

So there is not much benefit in making = the marker bit reliable in this case, and there is even the risk that it wi= ll add unnecessary latency.

 

Regards,

Mo

 

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 8:48 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Now I unde= rstand your intention better – did not see that the note was intended= for sender implementers. 

 

OK, thanks.

 



 For = this purpose, indeed (as Mo pointed out earlier?) that first of all, the se= nder needs make sure the RTP timestamp for each RTP packet is correct. As long as RTP timestamp is correct, it is also easy to know when the M bi= t should be set. Or are you saying that there is no problem with RTP timest= amp setting but there is a problem for the M bit setting? If yes, please cl= arify why.

 

Figuring out the RTP timestamp isn't (nearly as much= of) a problem, because this can be done by knowing the stream's frame rate= .  But in this email thread, I'm focusing only on the RTP 'M' bit, bec= ause for it (unlike the timestamp) there's less of an incentive for a sender implementation to 'get it right'.  = I'm worried that if the RTP payload format specification doesn't make it cr= ystal clear when a NAL unit ends an 'access unit', then an implementer migh= t be tempted to just not bother setting the bit at all.  I don't want to see that happen.  Hence this em= ail thread.




I have no = problem to putting some information in the line as you suggested, if the su= ggested text is good. However, the suggested wording below still has a few problems (or shortcomings).

 

----------

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 obt= ain this information separately, from the encoder.  If, however, this information is not available di= rectly from the encoder (e.g., because the implementation is sending data t= hat consists solely of a sequence of pre-encoded NAL units), then it must i= nstead inspect subsequent NAL units, to determine whether or not the NAL unit ends an access unit.  The following rule = can be used:

    A NAL unit ends a= n access unit if it is a VCL NAL unit, and the next-occurring VCL NAL = unit has the high-order bit of the first byte after its NALU header equal t= o 1.

----------

 

The proble= ms (or shortcomings) are:

-          I don’t think it is good to say that the fact that a NAL unit itself d= oes not indicate whether it is the last one of an AU is unfortunate.=

 

Why not?  It *is* "unfortunate". &nbs= p;I'm not intending to 'insult' H.265 here :-)

 



-          Saying that the information can be obtained from the encoder is vague to me. I gu= ess you meant the bitstream instead, as the encoder may be absent e.g. when= dealing pre-encoded video.

 

I think you may have been confused by my use of the = word "can" in the 2nd sentence of my proposed paragraph.  He= re is a rewording of the 2nd (& 3rd) sentences; I hope this will make t= hings clearer:

 

   &nb= sp;        "Instead, the imp= lementation may be able to obtain this information separately, from the enc= oder.  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 subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= "




-          Last but not least, an AU may also end with a non-VCL NAL unit, e.g. a filler d= ata NAL unit, an end of sequence NAL unit, an end of bitstream NAL unit, a = suffix SEI NAL unit, etc.

 

Arggh!  Now, I hope, you see the problem :-) &n= bsp;Can you then help me figure out a more accurate wording for the rule? &= nbsp;In particular:

   &nb= sp;        1/ Suppose we have a V= CL NAL unit, followed immediately by another VCL NAL unit with the first sl= ice header bit set.  In this case, there's no doubt: The first VCL NAL= unit definitely ends an 'access unit' - correct?

   &nb= sp;        2/ Suppose we have a V= CL NAL unit, followed by a sequence of one or more non-VCL NAL units, follo= wed immediately by a VCL NAL unit with the first slice header bit set.=  In this case, which (if any) of the non-VCL NAL units ends an 'access unit'?  Can we figu= re out a rule (ideally, an easy rule, based solely on the "nal_unit_ty= pe"s) for this?

 

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

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_-- From finlayson@live555.com Fri Aug 9 21:55:27 2013 Return-Path: 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 2978D11E8131; Fri, 9 Aug 2013 21:55:27 -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 qg3n6t+LvOuc; Fri, 9 Aug 2013 21:55:21 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6677611E80F6; Fri, 9 Aug 2013 21:49:53 -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 r7A4nkJF057217; Fri, 9 Aug 2013 21:49:50 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 21:49:45 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 04:55:27 -0000 --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > If you are able to set the RTP timestamp reliably, then you must = already have some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a = frame boundary: Look at the first slice header bit. The one remaining = problem (that I identified at the end of my last message) is: How to = classify any *non-VCL* NAL units that appear between one VCL NAL unit = and another VCL unit that has the first slice header bit. Which of = these belong to the last frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point = of view of receivers that check and try to optimize for the 'M' bit) if = we always set the 'M' bit for the last VCL NAL unit of a frame, even if = some subsequent non-VCL NAL units (appearing before the first VCL NAL = unit of the next frame) also belong logically to the current frame?? > But you should realize that, in doing this, you have defeated the = marker bit optimization. You have just shifted the latency from the = receiver to the sender No, not necessarily. If the encoded video comes from a file (i.e., = pre-recorded), then the latency involved in requiring the sender to = examine the 'next' frame will usually be negligible. But in any case, = the situation we're talking about here (senders working from a sequence = of pre-encoded NAL units) is one that usually occurs only in = non-interactive environments, for which latency isn't crucial. > So there is not much benefit in making the marker bit reliable in this = case, and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a = sending implementation cannot determine whether or not a NAL unit ends = an 'access unit' (frame) without having to scan subsequent NAL units, = then it should not set the 'M' bit at all. I don't like this, though = (especially because it adds receiver latency without necessarily = reducing sender latency (note above)). But it's a possibility to = consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If you are able to set the RTP timestamp = reliably, then you must already have some sort of frame boundary = identification.

Yes, = we have a reliable way of determining when *VCL* NAL units cross a frame = boundary: Look at the first slice header bit.  The one = remaining problem (that I identified at the end of my last message) is: = How to classify any *non-VCL* NAL units that appear between one VCL NAL = unit and another VCL unit that has the first slice header bit. =  Which of these belong to the last frame, and which belong to the = next frame.

But perhaps this doesn't really = matter?  Perhaps it's OK (from the point of view of receivers that = check and try to optimize for the 'M' bit) if we always set the 'M' bit = for the last VCL NAL unit of a frame, even if some subsequent non-VCL = NAL units (appearing before the first VCL NAL unit of the next frame) = also belong logically to the current = frame??


But you should realize that, in doing this, you = have defeated the marker bit optimization. You have just shifted the = latency from the receiver to the = sender

No, not = necessarily.  If the encoded video comes from a file (i.e., = pre-recorded), then the latency involved in requiring the sender to = examine the 'next' frame will usually be negligible.  But in any = case, the situation we're talking about here (senders working from a = sequence of pre-encoded NAL units) is one that usually occurs only in = non-interactive environments, for which latency isn't = crucial.


So there is not much benefit in making the marker bit = reliable in this case, and there is even the risk that it will add = unnecessary = latency.

That's = certainly another possibility, I suppose: Recommend that if a sending = implementation cannot determine whether or not a NAL unit ends an = 'access unit' (frame) without having to scan subsequent NAL units, then = it should not set the 'M' bit at all.  I don't like this, though = (especially because it adds receiver latency without necessarily = reducing sender latency (note above)).  But it's a possibility to = consider...

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

= --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7-- From yekuiw@qti.qualcomm.com Sat Aug 10 07:00:04 2013 Return-Path: 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 0AE2111E810E; Sat, 10 Aug 2013 07:00:04 -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 aAP4SXT4ijdy; Sat, 10 Aug 2013 06:59:59 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1773921F843F; Sat, 10 Aug 2013 06:54:47 -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=1376142887; x=1407678887; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rNWQu+sNVuqJRA+KMoUGa8pfHyY2LwJyEm2J9P3jB6I=; b=zN//X2+ayOB57aSvDNdu2dTybSFVNmDBDXHhYZRgsPeqtMZAE2j+qnVG Y5csjQFpU7xbGhlSbgkCPrr9y37QmgZZ38gHAbHi3YI78pJSW25gpVJwy HklvFq+AbjNuNhhf78ejv9KVRhFOBKyMWZprCdCMW23gSx7fNkGpXoDr1 s=; X-IronPort-AV: E=Sophos;i="4.89,851,1367996400"; d="scan'208,217";a="49335680" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Aug 2013 06:54:45 -0700 Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Aug 2013 06:54:45 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0146.002; Sat, 10 Aug 2013 06:54:45 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlYXebWo12KX/i0m4/b5pwipzfZmOdc6A Date: Sat, 10 Aug 2013 13:54:45 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 14:00:04 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, You just need one more little step to get everything right here, instead of= thinking of compromising the implementation :) That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant parag= raphs are copied below for convenience (the first paragraph itself contains= the answer to your question, but the second paragraph may also provide hel= pful information): The first of any of the following NAL units after the last VCL NAL unit of = a coded picture specifies the start of a new access unit: - access unit delimiter NAL unit (when present), - VPS NAL unit (when present), - SPS NAL unit (when present), - PPS NAL unit (when present), - Prefix SEI NAL unit (when present), - NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 (= when present), - NAL units with nal_unit_type in the range of UNSPEC48..UNSPEC55 (when= present), - first VCL NAL unit of a coded picture (always present). The order of the coded pictures and non-VCL NAL units within an access unit= shall obey the following constraints: - When an access unit delimiter NAL unit is present, it shall be the fi= rst NAL unit. There shall be at most one access unit delimiter NAL unit in = any access unit. - When any prefix SEI NAL units are present, they shall not follow the = last VCL NAL unit of the access unit. - NAL units having nal_unit_type equal to FD_NUT or SUFFIX_SEI_NUT, or = in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..UNSPEC63 shall not prec= ede the first VCL NAL unit of the coded picture. - When an end of sequence NAL unit is present, it shall be the last NAL= unit in the access unit other than an end of bitstream NAL unit (when pres= ent). - When an end of bitstream NAL unit is present, it shall be the last NA= L unit in the access unit. NOTE - VPS NAL units, SPS NAL units, PPS NAL units, prefix SEI NAL units, o= r NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UN= SPEC48..UNSPEC55, may be present in an access unit, but cannot follow the l= ast VCL NAL unit of the coded picture within the access unit, as this condi= tion would specify the start of a new access unit. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Friday, August 09, 2013 9:50 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a fra= me boundary: Look at the first slice header bit. The one remaining problem= (that I identified at the end of my last message) is: How to classify any = *non-VCL* NAL units that appear between one VCL NAL unit and another VCL un= it that has the first slice header bit. Which of these belong to the last = frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point of= view of receivers that check and try to optimize for the 'M' bit) if we al= ways set the 'M' bit for the last VCL NAL unit of a frame, even if some sub= sequent non-VCL NAL units (appearing before the first VCL NAL unit of the n= ext frame) also belong logically to the current frame?? But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender No, not necessarily. If the encoded video comes from a file (i.e., pre-rec= orded), then the latency involved in requiring the sender to examine the 'n= ext' frame will usually be negligible. But in any case, the situation we'r= e talking about here (senders working from a sequence of pre-encoded NAL un= its) is one that usually occurs only in non-interactive environments, for w= hich latency isn't crucial. So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a sendin= g implementation cannot determine whether or not a NAL unit ends an 'access= unit' (frame) without having to scan subsequent NAL units, then it should = not set the 'M' bit at all. I don't like this, though (especially because = it adds receiver latency without necessarily reducing sender latency (note = above)). But it's a possibility to consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

You just need one more li= ttle step to get everything right here, instead of thinking of compromising= the implementation J

 <= /p>

That is, read subclause 7= .4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below fo= r convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful inform= ation):

 <= /p>

The first of any of the following NAL units after th= e last VCL NAL unit of a coded picture specifies the start of a new access = unit:

–     access unit delimite= r NAL unit (when present),

–     VPS NAL unit (when p= resent),

–     SPS NAL unit (when p= resent),

–     PPS NAL unit (when p= resent),

–     Prefix SEI NAL unit = (when present),

–     NAL units with nal_u= nit_type in the range of RSV_NVCL41..RSV_NVCL44 (when present),<= /p>

–     NAL units with nal_u= nit_type in the range of UNSPEC48..UNSPEC55 (when present),

–     first VCL NAL unit o= f a coded picture (always present).

 

The order of the coded pictures and non-VCL NAL unit= s within an access unit shall obey the following constraints:

= 211;     When an access unit delimiter NAL unit is pres= ent, it shall be the first NAL unit. There shall be at most one access unit= delimiter NAL unit in any access unit.

= 211;     When any prefix SEI NAL units are present, the= y shall not follow the last VCL NAL unit of the access unit.

= 211;     NAL units having nal_unit_type equal to FD_NUT= or SUFFIX_SEI_NUT, or in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..= UNSPEC63 shall not precede the first VCL NAL unit of the coded picture.

= 211;     When an end of sequence NAL unit is present, i= t shall be the last NAL unit in the access unit other than an end of bitstr= eam NAL unit (when present).

= 211;     When an end of bitstream NAL unit is present, = it shall be the last NAL unit in the access unit.

NOTE – VPS NAL unit= s, SPS NAL units, PPS NAL units, prefix SEI NAL units, or NAL units with na= l_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UNSPEC48..UNSPEC55, m= ay be present in an access unit, but cannot follow the last VCL NAL unit of the coded picture within the access unit, as this con= dition would specify the start of a new access unit.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 9:50 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

If you are able to set t= he RTP timestamp reliably, then you must already have some sort of frame bo= undary identification.

 

Yes, we have a reliable way of determining when *VCL= * NAL units cross a frame boundary: Look at the first slice header bit= .  The one remaining problem (that I identified at the end of my last = message) is: How to classify any *non-VCL* NAL units that appear between one VCL NAL unit and another VCL unit that has t= he first slice header bit.  Which of these belong to the last frame, a= nd which belong to the next frame.

 

But perhaps this doesn't really matter?  Perhap= s it's OK (from the point of view of receivers that check and try to optimi= ze for the 'M' bit) if we always set the 'M' bit for the last VCL NAL unit = of a frame, even if some subsequent non-VCL NAL units (appearing before the first VCL NAL unit of the next frame) also= belong logically to the current frame??

 



But you should realize t= hat, in doing this, you have defeated the marker bit optimization. You have= just shifted the latency from the receiver to the sender

 

No, not necessarily.  If the encoded video come= s from a file (i.e., pre-recorded), then the latency involved in requiring = the sender to examine the 'next' frame will usually be negligible.  Bu= t in any case, the situation we're talking about here (senders working from a sequence of pre-encoded NAL units) is one tha= t usually occurs only in non-interactive environments, for which latency is= n't crucial.

 

 

So there is not much ben= efit in making the marker bit reliable in this case, and there is even the = risk that it will add unnecessary latency.=

 

That's certainly anot= her possibility, I suppose: Recommend that if a sending implementation cann= ot determine whether or not a NAL unit ends an 'access unit' (frame) withou= t having to scan subsequent NAL units, then it should not set the 'M' bit at all.  I don't like this, though= (especially because it adds receiver latency without necessarily reducing = sender latency (note above)).  But it's a possibility to consider...

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

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Sat Aug 10 07:25:43 2013 Return-Path: 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 3C43E11E8102; Sat, 10 Aug 2013 07:25:43 -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 3rVb2xeyizpO; Sat, 10 Aug 2013 07:25:38 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3721F9DAA; Sat, 10 Aug 2013 07:16:47 -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=1376144207; x=1407680207; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iCUKa4gDTQFRPQYaGSZMr0Czbf73tZVUzI6EPBnyRBE=; b=N4HFosWf0tisriscPhyLEl3scuHEq78OfzxbZlHqWffzphJg6iHCZxyB 4ft7xCXrl7iJqdCPOtPVreSVDIWwLlF01wqJb2pOudZCr7BD4PjELR2UD nCpYcpqNlRBvn+779ENcc68eyiDM3UdXcwf+fHV7T214P8dpTZ+ei1yzI I=; X-IronPort-AV: E=Sophos;i="4.89,851,1367996400"; d="scan'208,217";a="49336497" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Aug 2013 07:16:47 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Aug 2013 07:16:46 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.03.0146.002; Sat, 10 Aug 2013 07:16:46 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOldHxrENwOy7dhUOuP7HJFLBE0pmOeOQQ Date: Sat, 10 Aug 2013 14:16:46 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D701C@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@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.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 14:25:43 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regardless of the following, I still think that the timestamp approach shou= ld be the way to go. A good system should have a clear mapping of each vide= o data unit (NAL unit in the context of H.265 and H.264) to an output times= tamp, be it real-time encoding or pre-encoded content. For real-time encodi= ng, the encoder knows what data units are generated for each input raw pict= ure and thus it clearly knows the timestamp for each data unit. A pre-encod= ed content should have been stored in some kind of video storage format tha= t has timestamp associated with each data unit, e.g. in a file container ac= cording to ISO base media file format, MPEG-2 systems, or whatever other fi= le storage format. Trying to generate timestamps from a raw coded video bit= stream without timing information for each coded picture based on a guess o= f frame rate is really just a hack to me, as frame rate can be adaptive, pa= rticularly at the beginning of a session in low-delay conversational applic= ations or at locations of scene change or of need of full intra refresh or = random accessibility, wherein your rate control algorithm can easily requir= e skipping the encoding of some frames. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui Sent: Saturday, August 10, 2013 6:55 AM To: Ross Finlayson; avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Hi Ross, You just need one more little step to get everything right here, instead of= thinking of compromising the implementation :) That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant parag= raphs are copied below for convenience (the first paragraph itself contains= the answer to your question, but the second paragraph may also provide hel= pful information): The first of any of the following NAL units after the last VCL NAL unit of = a coded picture specifies the start of a new access unit: - access unit delimiter NAL unit (when present), - VPS NAL unit (when present), - SPS NAL unit (when present), - PPS NAL unit (when present), - Prefix SEI NAL unit (when present), - NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 (= when present), - NAL units with nal_unit_type in the range of UNSPEC48..UNSPEC55 (when= present), - first VCL NAL unit of a coded picture (always present). The order of the coded pictures and non-VCL NAL units within an access unit= shall obey the following constraints: - When an access unit delimiter NAL unit is present, it shall be the fi= rst NAL unit. There shall be at most one access unit delimiter NAL unit in = any access unit. - When any prefix SEI NAL units are present, they shall not follow the = last VCL NAL unit of the access unit. - NAL units having nal_unit_type equal to FD_NUT or SUFFIX_SEI_NUT, or = in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..UNSPEC63 shall not prec= ede the first VCL NAL unit of the coded picture. - When an end of sequence NAL unit is present, it shall be the last NAL= unit in the access unit other than an end of bitstream NAL unit (when pres= ent). - When an end of bitstream NAL unit is present, it shall be the last NA= L unit in the access unit. NOTE - VPS NAL units, SPS NAL units, PPS NAL units, prefix SEI NAL units, o= r NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UN= SPEC48..UNSPEC55, may be present in an access unit, but cannot follow the l= ast VCL NAL unit of the coded picture within the access unit, as this condi= tion would specify the start of a new access unit. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Ross Finlayson Sent: Friday, August 09, 2013 9:50 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a fra= me boundary: Look at the first slice header bit. The one remaining problem= (that I identified at the end of my last message) is: How to classify any = *non-VCL* NAL units that appear between one VCL NAL unit and another VCL un= it that has the first slice header bit. Which of these belong to the last = frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point of= view of receivers that check and try to optimize for the 'M' bit) if we al= ways set the 'M' bit for the last VCL NAL unit of a frame, even if some sub= sequent non-VCL NAL units (appearing before the first VCL NAL unit of the n= ext frame) also belong logically to the current frame?? But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender No, not necessarily. If the encoded video comes from a file (i.e., pre-rec= orded), then the latency involved in requiring the sender to examine the 'n= ext' frame will usually be negligible. But in any case, the situation we'r= e talking about here (senders working from a sequence of pre-encoded NAL un= its) is one that usually occurs only in non-interactive environments, for w= hich latency isn't crucial. So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a sendin= g implementation cannot determine whether or not a NAL unit ends an 'access= unit' (frame) without having to scan subsequent NAL units, then it should = not set the 'M' bit at all. I don't like this, though (especially because = it adds receiver latency without necessarily reducing sender latency (note = above)). But it's a possibility to consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regardless of the followi= ng, I still think that the timestamp approach should be the way to go. A go= od system should have a clear mapping of each video data unit (NAL unit in the context of H.265 and H.264) to an output timestamp, = be it real-time encoding or pre-encoded content. For real-time encoding, th= e encoder knows what data units are generated for each input raw picture an= d thus it clearly knows the timestamp for each data unit. A pre-encoded content should have been stored in some = kind of video storage format that has timestamp associated with each data u= nit, e.g. in a file container according to ISO base media file format, MPEG= -2 systems, or whatever other file storage format. Trying to generate timestamps from a raw coded video bitst= ream without timing information for each coded picture based on a guess of = frame rate is really just a hack to me, as frame rate can be adaptive, part= icularly at the beginning of a session in low-delay conversational applications or at locations of scene change o= r of need of full intra refresh or random accessibility, wherein your rate = control algorithm can easily require skipping the encoding of some frames.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Saturday, August 10, 2013 6:55 AM
To: Ross Finlayson; avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Hi Ross,

 <= /p>

You just need one more li= ttle step to get everything right here, instead of thinking of compromising= the implementation J

 <= /p>

That is, read subclause 7= .4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below fo= r convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful inform= ation):

 <= /p>

The first of any of the following NAL units after th= e last VCL NAL unit of a coded picture specifies the start of a new access = unit:

–     access unit delimite= r NAL unit (when present),

–     VPS NAL unit (when p= resent),

–     SPS NAL unit (when p= resent),

–     PPS NAL unit (when p= resent),

–     Prefix SEI NAL unit = (when present),

–     NAL units with nal_u= nit_type in the range of RSV_NVCL41..RSV_NVCL44 (when present),<= /p>

–     NAL units with nal_u= nit_type in the range of UNSPEC48..UNSPEC55 (when present),

–     first VCL NAL unit o= f a coded picture (always present).

 

The order of the coded pictures and non-VCL NAL unit= s within an access unit shall obey the following constraints:

= 211;     When an access unit delimiter NAL unit is pres= ent, it shall be the first NAL unit. There shall be at most one access unit= delimiter NAL unit in any access unit.

= 211;     When any prefix SEI NAL units are present, the= y shall not follow the last VCL NAL unit of the access unit.

= 211;     NAL units having nal_unit_type equal to FD_NUT= or SUFFIX_SEI_NUT, or in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..= UNSPEC63 shall not precede the first VCL NAL unit of the coded picture.

= 211;     When an end of sequence NAL unit is present, i= t shall be the last NAL unit in the access unit other than an end of bitstr= eam NAL unit (when present).

= 211;     When an end of bitstream NAL unit is present, = it shall be the last NAL unit in the access unit.

NOTE – VPS NAL unit= s, SPS NAL units, PPS NAL units, prefix SEI NAL units, or NAL units with na= l_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UNSPEC48..UNSPEC55, m= ay be present in an access unit, but cannot follow the last VCL NAL unit of the coded picture within the access unit, as this con= dition would specify the start of a new access unit.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 9:50 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

If you are able to set t= he RTP timestamp reliably, then you must already have some sort of frame bo= undary identification.

 

Yes, we have a reliable way of determining when *VCL= * NAL units cross a frame boundary: Look at the first slice header bit= .  The one remaining problem (that I identified at the end of my last = message) is: How to classify any *non-VCL* NAL units that appear between one VCL NAL unit and another VCL unit that has t= he first slice header bit.  Which of these belong to the last frame, a= nd which belong to the next frame.

 

But perhaps this doesn't really matter?  Perhap= s it's OK (from the point of view of receivers that check and try to optimi= ze for the 'M' bit) if we always set the 'M' bit for the last VCL NAL unit = of a frame, even if some subsequent non-VCL NAL units (appearing before the first VCL NAL unit of the next frame) also= belong logically to the current frame??

 

 

But you should realize t= hat, in doing this, you have defeated the marker bit optimization. You have= just shifted the latency from the receiver to the sender

 

No, not necessarily.  If the encoded video come= s from a file (i.e., pre-recorded), then the latency involved in requiring = the sender to examine the 'next' frame will usually be negligible.  Bu= t in any case, the situation we're talking about here (senders working from a sequence of pre-encoded NAL units) is one tha= t usually occurs only in non-interactive environments, for which latency is= n't crucial.

 

 

So there is not much ben= efit in making the marker bit reliable in this case, and there is even the = risk that it will add unnecessary latency.=

 

That's certainly anot= her possibility, I suppose: Recommend that if a sending implementation cann= ot determine whether or not a NAL unit ends an 'access unit' (frame) withou= t having to scan subsequent NAL units, then it should not set the 'M' bit at all.  I don't like this, though= (especially because it adds receiver latency without necessarily reducing = sender latency (note above)).  But it's a possibility to consider...

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

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_-- From ron.even.tlv@gmail.com Mon Aug 12 07:18:33 2013 Return-Path: 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 21E0721E80C5 for ; Mon, 12 Aug 2013 07:18:33 -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 LFGwnqTmYW4z for ; Mon, 12 Aug 2013 07:18:32 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 681C321F9ED2 for ; Mon, 12 Aug 2013 07:10:20 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so1747258wiw.3 for ; Mon, 12 Aug 2013 07:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=YIlF+ClWmonGUuFEamjn3bJRGPVa2rHJqdrH97xATTc=; b=asfhG6iRyf/658MNdULoerCMcduws4+F47EWjBCHmZvMJF/T8yoCP1e1fJrIdmccUR /LS4HO13Rcp2khvgu9vXh0QxlOqv0bZBziz3tTrA7jANk4t+RoGmc9sVl8WxhEpwunGJ wn5EyaGRkEr0a1SNlKEXgyKvio1gLjwAP9z8x1mlnP0QfNSVjI/4ghuUq1jBN6HujkD2 rvncGRSSkmJeRHo+Te6CYkkG8IYrm6Bqfeeb9AxmyqUgzJlFQVdGjO5+9ucLEwj2mE06 zkVwBhRGqQp7jA5KddXbNI3q+UCERZJM42QgW+2xlESUvKvMSxK46aGHucgUIhXlYILC K5MQ== X-Received: by 10.180.8.42 with SMTP id o10mr6779563wia.0.1376316619552; Mon, 12 Aug 2013 07:10:19 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id b13sm16657696wic.9.2013.08.12.07.10.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 07:10:18 -0700 (PDT) From: "Roni Even" To: Date: Mon, 12 Aug 2013 17:08:07 +0300 Message-ID: <000e01ce9765$5fe2c030$1fa84090$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CE977E.85304650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6XZV499oygRG6zQr+p9Qo17WhvLg== Content-Language: en-us Subject: [AVTCORE] AVTCORE IETF87 meeting notes X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 14:18:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01CE977E.85304650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I posted the AVTcore meeting notes. See http://www.ietf.org/proceedings/87/minutes/minutes-87-avtcore Please review. Roni Even AVTcore co-chair ------=_NextPart_000_000F_01CE977E.85304650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

I posted the AVTcore meeting notes. =  See ht= tp://www.ietf.org/proceedings/87/minutes/minutes-87-avtcore

Please review.

Roni Even

AVTcore = co-chair

 

------=_NextPart_000_000F_01CE977E.85304650-- From finlayson@live555.com Mon Aug 12 12:25:32 2013 Return-Path: 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 Content-Type: multipart/alternative; boundary="Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Mon, 12 Aug 2013 12:25:23 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.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> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> To: "avt@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:25:32 -0000 --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > You just need one more little step to get everything right here, = instead of thinking of compromising the implementation J > =20 > 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/ --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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/

= --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7-- From magnus.westerlund@ericsson.com Wed Aug 14 00:47:27 2013 Return-Path: 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 43EDA11E8123 for ; Wed, 14 Aug 2013 00:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 RpDt6XQN4rwQ for ; Wed, 14 Aug 2013 00:47:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2211E8107 for ; Wed, 14 Aug 2013 00:47:20 -0700 (PDT) X-AuditID: c1b4fb30-b7ef88e00000103a-a2-520b3605f65e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AD.38.04154.5063B025; Wed, 14 Aug 2013 09:47:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Wed, 14 Aug 2013 09:47:15 +0200 Message-ID: <520B3644.3090007@ericsson.com> Date: Wed, 14 Aug 2013 09:48:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+JvrS6bGXeQwdtJfBYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49bqRpaCd2wV3/ZsZG1gPM7axcjJISFgIrFi83k2CFtM4sK9 9UA2F4eQwGFGiauXFrBCOMsZJT5vWQTWwSugLfHq1nUmEJtFQFXiyJXJYHE2AQuJmz8awSaJ CgRLtG//ygZRLyhxcuYTFhBbREBJYsekbcwgtrCAssT1tj9MEJslJbYtOsYOYjML6ElMudrC CGHLSzRvnQ1WLwS0t6Gpg3UCI/8sJGNnIWmZhaRlASPzKkb23MTMnPRy802MwIA6uOW3wQ7G TffFDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR4Cv739fiP0o+HU3p qtt2IuKZuPNltwN5nbMqTk3oT/3mntK55nuMebflO579lmLuh0/fbhKM1aq/EXbHZ7efTeh0 v5n/Gjji9ouVdcrO/Nyz64VFQqlbTPZPZquNzef2qJtxNH2ZmX1OePuVO3azlzXu3vVSKNfj y+39Lad03j7vLpIRZ5urxFKckWioxVxUnAgA3VkPQfYBAAA= Subject: [AVTCORE] This chair is back working X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 07:47:27 -0000 WG, Some of you might have noticed my absence the last couple of weeks both at the meeting and on the list. The reason has been my now 7-week daughter. I just wanted to notify you that I am now back working regular hours. I will do my best to perform my outstanding tasks and other duties. If you believe I have tasks to complete for you, don't hesitate to remind me of them. Cheers Magnus Westerlund AVTCORE Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Aug 14 05:35:52 2013 Return-Path: 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 D20DC11E8153 for ; Wed, 14 Aug 2013 05:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.121 X-Spam-Level: X-Spam-Status: No, score=-105.121 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, 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 0xAa4kMC-paM for ; Wed, 14 Aug 2013 05:35:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7925021F9F00 for ; Wed, 14 Aug 2013 05:35:45 -0700 (PDT) X-AuditID: c1b4fb25-b7fc58e000001048-0c-520b799f2456 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B5.54.04168.F997B025; Wed, 14 Aug 2013 14:35:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.328.9; Wed, 14 Aug 2013 14:35:38 +0200 Message-ID: <520B79DC.6020202@ericsson.com> Date: Wed, 14 Aug 2013 14:36:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kevin Gross References: <20130714080418.18036.97048.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre78Su4gg2urbSxe9qxkt5j0dTur xYtD7WwOzB7/rm5n9liy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4MrZsbmIueOVV8WLFS+YG xiarLkZODgkBE4n+NZNZIGwxiQv31rN1MXJxCAkcZpS4/X8mI0hCSGAZo8TcfaYgNq+AtsTV KbPZQGwWAVWJg0s2g9WwCVhI3PzRCBYXFQiWaN/+lQ2iXlDi5MwnYAtEBNQlHu16yARiMwtU SZzZ/RnI5uAQFnCW+HelFmJVG6PEl21qIDanQKDEpqY2qNskJbYtOsYO0aonMeVqCyOELS/R vHU2M0SvtkRDUwfrBEahWUg2z0LSMgtJywJG5lWM7LmJmTnp5UabGIHBe3DLb9UdjHfOiRxi lOZgURLn3ax3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4/q/V7TWXPxy6x2j5fdM6ZAj UTLZ+80nTGKNPNQU/uORZcONL/MSXjpue75U++vkzINLFx/weegtoXCxuip5171vCkefWQQ8 uiYVPvFuh9L9zyVR27bEd0TuXxwheOfOvjRLNdezay/yyT3mveY7dWu/bGu5o+5dMWEFXV7t q9Uc67/zbD1kwK/EUpyRaKjFXFScCABIeWUfLAIAAA== Cc: "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:35:53 -0000 WG, I have reviewed the -05 version and found some minor issues that I hope the authors will be able to address in the update in progress anyway to resolve the SDP directorate review. The Offer/answer section looks acceptable even if I yet again needed to read it twice to make certain that all cases are covered. The default statements in 6.1 and 6.1.1 I have a tendency to overlook when I read 6.1.2 and 6.1.3. 1. Section 3: source level : Source level information applies to a RTP media stream Source-Specific Media Attributes in the Session Description Protocol (SDP) [RFC5576] defines how source-level information is included into an SDP session description. I think this definition looks a bit strange I would propose two modifications to it to make it be clearer: NEW: source level : Source level information applies to a specific RTP ^^^^^^^^ media stream. Source-Specific Media Attributes in the Session ^^ Description Protocol (SDP) [RFC5576] defines how source-level information is included into an SDP session description. 2. Section 4.8 and 5.4: The ABNF actually is underspecified by lacking definitions. I run it in BAP (http://tools.ietf.org/tools/bap/abnf.cgi) and got the following response. ; integer UNDEFINED ; SP UNDEFINED mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk-sl = "a:ssrc" integer SP timestamp-mediaclk timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext ; token UNDEFINED sender-ext = token ; DIGIT UNDEFINED refclk = "direct" [ "=" 1*DIGIT ] [ rate ] [ direct-ext ] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = ( "master-id=" master-id streamid = ) / ( "IEEE1722=" avb-stream-id streamid = ) / streamid-ext master-id = EUI48 avb-stream-id = EUI64 ; HEXDIG UNDEFINED EUI48 = 5( 2HEXDIG ":" ) 2HEXDIG EUI64 = 7( 2HEXDIG ":" ) 2HEXDIG streamid-ext = token ; byte-string UNDEFINED mediaclock-ext = token [ SP byte-string ] ; mediaclk-master defined but not used ; timestamp-mediaclk-sl defined but not used As you see this results in a number of undefined labels. This needs to be resolved. They belong to two categories: A) The ones defined in RFC 5234. These could be easily resolved. The most explicit way is to do the following and avoids forking definitions: SP = DIGIT = HEXDIG = B) The second categories are more uncertain and which of there are three labels: integer, token and byte-string. I guess token and byte-string are the definitions from SDP RFC 4566. Thus they could be solved by: token = byte-string = The integer may also be the definition from RFC 4566, however as the only usage are in the a=ssrc attribute, I would recommend that one actually uses the formal grammer from RFC 5576, i.e.: ssrc-attr = "ssrc:" ssrc-id SP attribute ; The base definition of "attribute" is in RFC 4566. ; (It is the content of "a=" lines.) ssrc-id = integer ; 0 .. 2**32 - 1 Thus I would suggest that one changes integer to "ssrc-id" and add ssrc-id = . I think this will resolve all the issues, but please run the resulting ABNF through BAP to check that you only get unused indications from the top level constructs intended and no other indications. You might have to make changes to this depending on how you are resolving the SDP directorate review. The above also applies to the ABNF in Section 5.4. 3. Section 4.8: Then I am also not a fan of open definitions like the port one: port = 1*DIGIT This really means at least 1 Digit up to an infinite number of them. I do prefer to set some upper limit on it. So far I don't know of a protocol that uses more than 16-bit port numbers, although that could change in the future. Considering what is deployed today I think the following is much more appropriate: port = 1*5DIGIT ; 0-65535 Or if you want to be more future safe, then port = 1*10DIGIT This allows for 32-bit integers 4. Section 5.2: The signalling optionally indicates a media clock offset value. The offset indicates the RTP timestamp value at the epoch (time of origin) of the reference clock. If no offset is signalled, the offset can be inferred at the receiver by examining RTCP sender reports which contain NTP and RTP timestamps which combined define a mapping. This text actually raises two questions with me. First, I am not certain that I understand the offset. So the indicated value is an RTP timestamp, i.e. the integer representation of the 32-bit value of the RTP timestamp. So the epoch time is dependent on the clock system, but the current epoch for an NTP reference clock would be 1 jan at 0:00 year 1900. Thus you need to take all the leap seconds etc into account to determine how many time has actually passed since then and then calculate how many wrapping of the timestamp this means. This seems error prone, at least without being more explicit of how to do it for the various reference clocks. Secondly, what are the relative precedence between the SDP signaled value and any values received in RTCP SR? Is it an initial date point that then are replaced by any RTCP SR information? If not, does it blocks the usage of the RTCP SR to update the relation between the "NTP" field and the RTP TS value? This needs to be made more explicit. 5. Section 5.2 and Figure 7: A rate modifier may be specified. The modifier is expressed as the ratio of two integers and modifies the rate specified or implied by the media description by this ratio. If omitted, the rate is assumed to be the exact rate specified or implied by the media format. For example, without a rate specification, the media clock for an 8 kHz G.711 audio stream will advance exactly 8000 units for each second advance in the reference clock from which it is derived. and looking at this example in Figure 7: m=audio 5004 RTP/AVP 96 a=rtpmap:96 L24/44100/2 a=sendonly a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=mediaclk:direct=963214424 rate=1000/1001 I realize that I don't understand what the rate modifier means. Without the rate modifier there would be 44100 RTP timestamp ticks per second of reference clock. Does the rate modifier multiply with the nominal rate so that this example means 441000*1000/1001 RTP TS ticks per second of reference clock? Some clarification may be required here. 6. Section 5.3: In a given system, master clock identifiers must be unique. Such identifiers MAY be manually configured, however 17 octet string identifiers SHOULD be generated according to the "short-term persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222]. As draft-ietf-avtcore-6222bis are approved and will soon be published, I think you should update this reference. Please also check that the update of RFC 6222 does not cause any issue for this. 7. Section 8.3: When creating registries it is quite common to make it clear what information is the minimal required in a registration request. Looking at these registries I would assume any registration would be required to provide: - Value - Long name - Reference - Contact for registration Maybe you should make this explicit. 8. Section 8.5.2: The source-level SDP attribute "master-id" defined by this document is registered with the IANA registry of SDP Parameters as follows: SDP Attribute ("att-field (source level)"): Attribute name: master-id Long form: Media clock source Type of name: att-field Type of attribute: source level Subject to charset: No Purpose: See section 5 of this document Reference: This document Values: EUI48 I wonder if this part is needed at all. What I can read to in the specification all source level usage with the master ID will have it encapsulated in the mediaclk attribute, i.e. one will specify a=ssrc:12345678 mediaclk:master-id= rather than a=ssrc:12345678 master-id= Thus I wonder why there is a registation of master-id? 9. Section 9: I wonder if not the classificiation of normative references are a bit wrong. From my reading of this doc, RFC 3261 is not a normative reference as the only statement related to SIP is the statement that SIP supports renogitation and that may be used, but really are just an example. Then I think the clock system/transports which has identifiers in this specification are actual normative references, so RFC 5905, IEEE 1588-X etc are in the wrong category. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Aug 14 06:17:40 2013 Return-Path: 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 2643621F9FE5 for ; Wed, 14 Aug 2013 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.003 X-Spam-Level: X-Spam-Status: No, score=-106.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 k4rl2nFKBSZo for ; Wed, 14 Aug 2013 06:17:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 732D421F9F84 for ; Wed, 14 Aug 2013 06:17:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-24-520b836a2451 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D8.F2.22048.A638B025; Wed, 14 Aug 2013 15:17:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Wed, 14 Aug 2013 15:17:30 +0200 Message-ID: <520B83AB.90705@ericsson.com> Date: Wed, 14 Aug 2013 15:18:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Igoe, Kevin M." References: <3C4AAD4B5304AB44A6BA85173B4675CAB243CD51@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB243CD51@MSMR-GH1-UEA03.corp.nsa.gov> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvrW52M3eQwblj2hYve1ayW6w9kmjR MMvK4u/mHUwWE069ZrXYsvsciwObx5q+ZI8lS34yefTvesnq8eXyZ7YAligum5TUnMyy1CJ9 uwSujPn9HUwF57kqHv99yt7AeJSji5GTQ0LARKJpxgQmCFtM4sK99WxdjFwcQgKHGSVeT3rI AuEsZ5S48PQZWBWvgKbEpk13GEFsFgFVib7fF8FsNgELiZs/GtlAbFGBYIn27V/ZIOoFJU7O fMICYosA1f/vfskKMpRZ4BujxMvJ75lBEsICnhIXN+0AWyAkMJ1RYt5OsAZOoEFHz35ngThP UmLbomPsIDazgJ7ElKstjBC2vETz1tnMEL3aEg1NHawTGIVmIdk9C0nLLCQtCxiZVzGy5yZm 5qSXm29iBAb5wS2/DXYwbrovdohRmoNFSZx3s96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MTGWhV5ynMhy+t2Hp7JKJPby+H5fF/DrjwHgpTW6NpXXPdJ1zWsd9VKYdyPZ6s+gtm0PE zTmJmQnf/a7VJfH+dedQC/TRdZi4Wqv865tSL0E5nymXYz0cWPPNRNwKrjGe36HwzGl64Z3X 5QeenZqo1Cnfw/XTRWvn266HWYEKqp4ezNkSqgeUWIozEg21mIuKEwHsTs/1QAIAAA== Cc: Daesung Kwon , 'Woo-Hwan Kim' , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , "avt@ietf.org" , Je Hong Park Subject: Re: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 13:17:40 -0000 Kevin, I looked over Woo-Hwan's comments and clearly 1 and 2 are resolved by -07. Thus I wonder over issue nr 3. In -07 I do find that C_MAX for CCM is 2^24-16, that appears to be the value he thinks should be 2^28-16 or was the issue that is was written as 2^24+16? Can you please confirm that -07 is correct as currently written using 2^24-16 Thanks Magnus On 2013-07-11 14:46, Igoe, Kevin M. wrote: > *From:*woohwankim@gmail.com [mailto:woohwankim@gmail.com] *On Behalf Of > *Woo-Hwan Kim > *Sent:* Thursday, June 27, 2013 1:23 AM > *To:* avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org > *Cc:* Je Hong Park; Daesung Kwon; Magnus Westerlund > *Subject:* [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-06 > > > 3. Section 6, Section 11.1 > (2^24)-16 octets => (2^28)-16 octets > > > > Regards, Woo-Hwan Kim > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Aug 14 06:42:03 2013 Return-Path: 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 D5ABD11E8152 for ; Wed, 14 Aug 2013 06:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.219 X-Spam-Level: X-Spam-Status: No, score=-104.219 tagged_above=-999 required=5 tests=[AWL=-1.620, 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 PNYJisShGgeG for ; Wed, 14 Aug 2013 06:41:58 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5611E8165 for ; Wed, 14 Aug 2013 06:41:56 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-42-520b89232a2b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F6.87.25272.3298B025; Wed, 14 Aug 2013 15:41:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Wed, 14 Aug 2013 15:41:54 +0200 Message-ID: <520B8964.5070108@ericsson.com> Date: Wed, 14 Aug 2013 15:43:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" References: <51700CB9.4030601@ericsson.com> In-Reply-To: <51700CB9.4030601@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Vle5kzvI4NhCGYuXPSvZLdYeSXRg 8liy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mk5OryyYqlSx9kRZA+N8qS5GTg4JAROJHavm skLYYhIX7q1n62Lk4hASOMoosW3tUhYIZxmjxLdte4EyHBy8AtoSX1pUQBpYBFQlLjz5zgRi swlYSNz80cgGYosKBEu0b/8KZvMKCEqcnPmEBcQWEUiXWHzmO5jNLKAkMXfpa2YQW1jAVWLu oXlgcSGg8SePvWUEsTkFdCS+vd/PBHGcpMS2RcfYIXr1JKZcbWGEsOUlmrfOZobpbWjqYJ3A KDQLyepZSFpmIWlZwMi8ipGjOLU4KTfdyGATIzBMD275bbGD8fJfm0OM0hwsSuK8W/TOBAoJ pCeWpGanphakFsUXleakFh9iZOLglGpgZAmfqspf0cTc13y9XPOE+b752i9/2Enf4+nfH5SU U116+czMgzbLvHQF3H5tUN9xLf5ixUcex98+la1fIutOxr3l2fS86dr2oy/6nqzZZFsjtTsm sIhhcw7PrL5Nws7PRZQyf+kd1eu8GnP6oqOYL3NRojTz2cXWm5mke6VcWsKTuucon6tXYinO SDTUYi4qTgQAw/K6xSECAAA= Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 13:42:04 -0000 Hi, I have checked the -07 version against these comments and think most are resolved. I will comment where I believe there are still an issue. On 2013-04-18 17:09, Magnus Westerlund wrote: > Authors and WG, > > In my review of the draft in preparing the Document Shepherd's writeup I > found some issues that I believe needs to be fixed. > > 1) Section 14.1: > Security description [RFC 4568] defines SRTP "crypto suites"; a > crypto suite corresponds to a particular AEAD algorithm in SRTP. > > As the registry is located on the SDP page it can be difficult to find > and it also not named as written I propose to change this to: > > Security description [RFC 4568] defines the "SRTP Crypto Suite > Registrations" registry on the "Session Description Protocol (SDP) > Security Descriptions" page currently located at > "http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml"; > a > crypto suite corresponds to a particular AEAD algorithm in SRTP. Section 15.1 now states with: Session description [RFC4568] defines SRTP "crypto suites". A crypto suite corresponds to a particular AEAD algorithm in SRTP. In order to allow SDP to signal the use of the algorithms defined in this document, IANA will register the following crypto suites into the subregistry for SRTP crypto suites under Session Description Protocol (SDP) Parameters: I think this needs to be slightly corrected in two places: Security descriptions [RFC4568] defines SRTP "crypto suites". A crypto ^^^^^^^^ suite corresponds to a particular AEAD algorithm in SRTP. In order to allow SDP to signal the use of the algorithms defined in this document, IANA will register the following crypto suites into the subregistry for SRTP crypto suites under "Session Description ^ Protocol (SDP) Security Descriptions" Parameters: ^^^^^^^^^^^^^^^^^^^^^^ This corrects both the common name of the RFC and the correct name of the page for the sub-registries. > > > 3) Section 14.2: > > DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; > > This registry is actually named "DTLS-SRTP Protection Profiles" on > IANA's page. Lets wait and see what IANA says about this. There is a discrepancy between IANA's page and what is written in the RFC. > > > 4) IANA registry: > > On the SRTP policy Type/Value list (derived from Table 6.10.1.a of > [RFC3830]) we request the following addition: > > Type | Meaning | Possible values > ---------------------------------------------------------------- > TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) > > > This registry is called : > > MIKEY Security Protocol Parameters at > http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml > > Can you please confirm that it is this registry you want to add to? Can you please confirm that this is the right registry and in that case use the explicit name: "MIKEY Security Protocol Parameters". > > > 5) IANA registry: > > 14.4. AEAD registry > > We request that IANA make the following additions to the AEAD > registry: > > AEAD_AES_128_CCM_12 = TBD > AEAD_AES_256_CCM_12 = TBD > > > You are not using the exact correct names for the registry: > http://www.iana.org/assignments/aead-parameters/aead-parameters.xml > > Would suggest that you should write this as: > > We request that IANA make the following additions to the IANA > Authenticated Encryption with Associated Data (AEAD) Parameters page's > registry for "AEAD Algorithms": This appears to not been addressed either. I would strongly suggest that you fix it. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Aug 15 00:10:23 2013 Return-Path: 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 B1E5A11E80E1 for ; Thu, 15 Aug 2013 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.988 X-Spam-Level: X-Spam-Status: No, score=-103.988 tagged_above=-999 required=5 tests=[AWL=-1.389, 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 Lu8arQrTsiMV for ; Thu, 15 Aug 2013 00:10:18 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EADDD21F99A1 for ; Thu, 15 Aug 2013 00:10:17 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-79-520c7ed8deeb Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 21.89.25272.8DE7C025; Thu, 15 Aug 2013 09:10:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Thu, 15 Aug 2013 09:10:16 +0200 Message-ID: <520C7F1D.4010505@ericsson.com> Date: Thu, 15 Aug 2013 09:11:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20130627054313.28629.3912.idtracker@ietfa.amsl.com> In-Reply-To: <20130627054313.28629.3912.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre6NOp4ggz07NCxe9qxkt5g8WcCB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyvi16xZTwW29io5Hn9kaGJcrdTFyckgImEhc WL2EHcIWk7hwbz0biC0kcJRR4uW0vC5GLiB7GaPEspvdzCAJXgFtiWV931lAbBYBVYkbj/eD NbMJWEjc/NEI1iwqECzRvv0rG0S9oMTJmU/A6kUEDCW2TmgGq2cWEJI4PecbK4gtLOAm8W7K TXaIxQ4SEw68BtvFKeAoseTbH2aI4yQlti06BtWrJzHlagsjhC0v0bx1NjNEr7ZEQ1MH6wRG oVlIVs9C0jILScsCRuZVjBzFqcVJuelGBpsYgaF6cMtvix2Ml//aHGKU5mBREufdoncmUEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj4dNLyerX/ouff/Z8ewy/+M51rIt/hPv3Gx9/x+jy ujPhYeBX8/1PsircV9nLM/xZczDJZz9b9IqiOuFFR+T1Uze977bavmPrhAtMUWnV1TmnZoYe 45p6Yp6X5mG12d+5Kg8prSsXeG+vIiQzzfx+RsatLM1romfVba4yMIcGpHlpbZgTyLpHiaU4 I9FQi7moOBEAz1rswyMCAAA= Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:10:24 -0000 Authors and WG, I have reviewed this new version. Thanks for addressing my issue. During this review I only noticed a small number of minor issues. Note, I have not verified in any way the test vectors. Nor am I certain that I can spot any fact error regarding the crypto-algorithms. What I have done is reviewed the draft consistency and correctness in their actions to IANA and towards SRTP. 1. Section 5.3: +--------------------------------------+ | Encryption | Encryption | AEAD Auth. | | Algorithm | Key Length | Tag Length | +======================================+ SRTP_ARIA_128_CTR_HMAC_80 | ARIA-CTR | 16 octets | 80 bits | SRTP_ARIA_128_CTR_HMAC_32 | ARIA-CTR | 16 octets | 32 bits | SRTP_ARIA_192_CTR_HMAC_80 | ARIA-CTR | 24 octets | 80 bits | SRTP_ARIA_192_CTR_HMAC_32 | ARIA-CTR | 24 octets | 32 bits | SRTP_ARIA_256_CTR_HMAC_80 | ARIA-CTR | 32 octets | 80 bits | SRTP_ARIA_256_CTR_HMAC_32 | ARIA-CTR | 32 octets | 32 bits | Kim, et al. Expires December 29, 2013 [Page 18] Internet-Draft ARIA Algorithm for SRTP June 2013 SRTP_AEAD_ARIA_128_GCM | ARIA-GCM | 16 octets | 128 bits | SRTP_AEAD_ARIA_128_CCM | ARIA-CCM | 16 octets | 128 bits | SRTP_AEAD_ARIA_128_GCM_12 | ARIA-GCM | 16 octets | 96 bits | SRTP_AEAD_ARIA_128_CCM_12 | ARIA-CCM | 16 octets | 96 bits | SRTP_AEAD_ARIA_128_GCM_8 | ARIA-GCM | 16 octets | 64 bits | SRTP_AEAD_ARIA_128_CCM_8 | ARIA-CCM | 16 octets | 64 bits | SRTP_AEAD_ARIA_256_GCM | ARIA-GCM | 32 octets | 128 bits | SRTP_AEAD_ARIA_256_CCM | ARIA-CCM | 32 octets | 128 bits | SRTP_AEAD_ARIA_256_GCM_12 | ARIA-GCM | 32 octets | 96 bits | SRTP_AEAD_ARIA_256_CCM_12 | ARIA-CCM | 32 octets | 96 bits | SRTP_AEAD_ARIA_256_GCM_8 | ARIA-GCM | 32 octets | 64 bits | SRTP_AEAD_ARIA_256_CCM_8 | ARIA-CCM | 32 octets | 64 bits | +======================================+ Figure 1: Mapping MIKEY parameters to AEAD algorithm Shouldn't you split this into two tables as the last column and legend are wrong for the first ARIA CTR + SHA-1 HMAC suits which are not AEAD suites? That way you can use the correct labels on the last column for auth tag lengths and in the legend. 2. Section A.2. and A.3 In section A.1 I do understand the structure for the test vectors. They contain both just the Encrypted part and the full RTP header + payload + ROC that authentication is calculated over, and then the resulting output. However in A.2 and A.3 where there are AEAD algorithms I am bit surprised over the split in Encrypted RTP payload and Authentication tag. Due to AEAD shouldn't the relevant unit to test as input be the full SRTP packet which contains both the encrypted and the data that is just authenticated including the AEAD output in the payload location? You might need a bit more explanation what the test vectors really are so that one can correctly use them to verify ones implementation. Next Steps: Please address the above issues. I personally think this is ready for going forward to WG last call when the above is addressed. However, in that last call we will need to get a review from someone that has sufficient crypto knowledge to be reduce the risk for any such error making it through. Thus I intended to make the WG last call's completion dependent on getting such a review. Cheers Magnus On 2013-06-27 07:43, 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 Core Maintenance Working Group of the IETF. > > Title : The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) > Author(s) : Woo-Hwan Kim > Jungkeun Lee > Dong-Chan Kim > Je-Hong Park > Daesung Kwon > Filename : draft-ietf-avtcore-aria-srtp-03.txt > Pages : 32 > Date : 2013-06-26 > > Abstract: > This document describes the use of the ARIA block cipher algorithm > within the Secure Real-time Transport Protocol (SRTP) for providing > confidentiality for the Real-time Transport Protocol (RTP) traffic > and for the control traffic for RTP, the Real-time Transport Control > Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) > and a SRTP Key Derivation Function for ARIA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-aria-srtp-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Aug 15 00:34:09 2013 Return-Path: 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 4F11621E811E for ; Thu, 15 Aug 2013 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.826 X-Spam-Level: X-Spam-Status: No, score=-99.826 tagged_above=-999 required=5 tests=[AWL=-5.203, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 8nXaPF0+r8hi for ; Thu, 15 Aug 2013 00:34:04 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F021E8115 for ; Thu, 15 Aug 2013 00:34:03 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-ba-520c846a9cac Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 76.3B.25272.A648C025; Thu, 15 Aug 2013 09:34:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.328.9; Thu, 15 Aug 2013 09:34:02 +0200 Message-ID: <520C84B0.4080104@ericsson.com> Date: Thu, 15 Aug 2013 09:35:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" , "draft-ietf-avtcore-idms@tools.ietf.org" References: <20130729084350.25184.22437.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvrW52C0+QwfEL3BYve1ayWxzasYbR 4tvm64wOzB5Llvxk8ji47gKzx5fLn9kCmKO4bFJSczLLUov07RK4Mha+e8Za8F6+ovfjQqYG xrcSXYycHBICJhJ981rYIGwxiQv31gPZXBxCAkcZJS7M/MEM4SxnlPjcsokRpIpXQFvif383 mM0ioCpxcv9MVhCbTcBC4uaPRrBJogLBEu3bv7JB1AtKnJz5hAVkkIjAJEaJsyt+sncxcnAw CyhKTGqXBKkRFnCU2Lyrhx3EFhLIlzizuh/M5hSwkmhaPo0J4jpJiW2LjoHFmQX0JKZcbWGE sOUlmrfOZobo1ZZoaOpgncAoNAvJ6llIWmYhaVnAyLyKkaM4tTgpN93IYBMjMIQPbvltsYPx 8l+bQ4zSHCxK4rxb9M4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamB88GqHckrz0hsiUdnn Wy4tXiF+RPnr2uDHRyL/sRWyTX26Lf9XjuILdoNSz9mrm9yX5b7IeMBzfndc8am0gD8xaxuk JoYc1dDeWNdgdG6K0ubcKzvvHzvNvfzcls2lFifKHxQ+kJUqe6i6lCH1odSNvLK5j94GMHXe fGpl5GTnFPZ5V4n9BhU1JZbijERDLeai4kQAkRDkJy8CAAA= Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:34:09 -0000 Hi, Looking at this latest version I have a comment. section 14.4 defines the SPST registry. Why isn't is adding the ETSI defined values from the start. If they are known and have well known reference I don't see any issues with putting in the values into the registry at its creation. Value Name Reference ----- ---- --------- 1 Synchronization Client section 7 of [RFCXXXX] 2 [TS183063] 3 [TS183063] 4 [TS183063] Cheers Magnus On 2013-07-29 10:48, Brandenburg, R. (Ray) van wrote: > Hi, > > This version of the draft includes the final comments received during > IETF LC and from Martin Thomson as Appsdir reviewer. > > Best regards, > > Ray > > On 29 jul. 2013, at 10:45, "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 >> Core Maintenance Working Group of the IETF. >> >> Title : Inter-destination Media Synchronization using the >> RTP Control Protocol (RTCP) Author(s) : Ray van Brandenburg >> Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud >> Kevin Gross Filename : draft-ietf-avtcore-idms-12.txt Pages >> : 22 Date : 2013-07-29 >> >> Abstract: This document defines a new RTP Control Protocol (RTCP) >> Packet Type and an RTCP Extended Report (XR) Block Type to be used >> for achieving Inter-Destination Media Synchronization (IDMS). IDMS >> is the process of synchronizing playout across multiple >> geographically distributed media receivers. Using the RTCP XR IDMS >> Report Block defined in this document, media playout information >> from participants in a synchronization group can be collected. >> Based on the collected information, an RTCP IDMS Settings Packet >> can then be sent to distribute a common target playout point to >> which all the distributed receivers, sharing a media experience, >> can synchronize. >> >> Typical use cases in which IDMS is useful are social TV, shared >> service control (i.e. applications where two or more >> geographically separated users are watching a media stream >> together), distance learning, networked video walls, networked >> loudspeakers, etc. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-avtcore-idms-12 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-idms-12 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ Audio/Video >> Transport Core Maintenance avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > _______________________________________________ Audio/Video Transport > Core Maintenance avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Aug 15 00:45:41 2013 Return-Path: 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 9231021F9F2D for ; Thu, 15 Aug 2013 00:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.061 X-Spam-Level: X-Spam-Status: No, score=-105.061 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 c0wy7L0Ggx74 for ; Thu, 15 Aug 2013 00:45:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 06C0C11E80E1 for ; Thu, 15 Aug 2013 00:45:35 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a8-520c871e0b14 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E9.47.03802.E178C025; Thu, 15 Aug 2013 09:45:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 15 Aug 2013 09:45:33 +0200 Message-ID: <520C8764.5030807@ericsson.com> Date: Thu, 15 Aug 2013 09:46:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvra5cO0+Qwfr1/BYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+/2g0wF+1grXpy9ydbAeIqli5GTQ0LAROLylL/sELaYxIV7 69m6GLk4hAQOM0osnHmFEcJZxiixoWU+K0gVr4C2xJvF98C6WQRUJXrWPGUCsdkELCRu/mhk A7FFBYIl2rd/ZYOoF5Q4OfMJWL2IgJLEjknbmEFsYQFXiY6r31ghNktKbFt0DOwKZgE9iSlX WxghbHmJ5q2zweqFgPY2NHWwTmDkn4Vk7CwkLbOQtCxgZF7FyJ6bmJmTXm60iREYUAe3/Fbd wXjnnMghRmkOFiVx3s16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MCov2MMZaftBPvHG v7uJKR0Xnj44K+FwkmvpczOxs0mnFNu3PLIrPzjL27ayJv7cdVex8xrLHIJuz1xf/G7l8Wk+ S7vWF99z/KBzumbLf9m0jD++fk63vuTd6Jy6MWdufn13hnCMvv5j1gU/DmUsafh5cjfnm0q5 gFpni9UfK3g2/Jb39m9+OUGJpTgj0VCLuag4EQB9daOp9gEAAA== Subject: [AVTCORE] Working Group Last Call on draft-ietf-avtcore-leap-second-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:45:41 -0000 WG, This starts the WG last call on RTP and Leap Seconds with the intended status of Proposed Standard. Please provide any comments by 1st of September. https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Thu Aug 15 02:22:53 2013 Return-Path: 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 18E5C11E8106 for ; Thu, 15 Aug 2013 02:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.484 X-Spam-Level: *** X-Spam-Status: No, score=3.484 tagged_above=-999 required=5 tests=[AWL=-3.988, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 HApQWYYcA8bO for ; Thu, 15 Aug 2013 02:22:48 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9D11E8127 for ; Thu, 15 Aug 2013 02:22:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,884,1367964000"; d="scan'208";a="2081705" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 15 Aug 2013 11:22:38 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Thu, 15 Aug 2013 11:22:38 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund , "draft-ietf-avtcore-idms@tools.ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt Thread-Index: AQHOjDftiZdFqe4/jEmTIRU5lnJxVJl7WFzbgBqBoACAAD7oEA== Date: Thu, 15 Aug 2013 09:22:38 +0000 Message-ID: References: <20130729084350.25184.22437.idtracker@ietfa.amsl.com> <520C84B0.4080104@ericsson.com> In-Reply-To: <520C84B0.4080104@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 09:22:53 -0000 Hi Magnus, Good point! For some reason, I never really considered that to be an option= . I guess you're right and there's no reason not to.=20 If I don't see any disagreements from others, I will add it to the next rev= ision.=20 Thanks, Ray > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: donderdag 15 augustus 2013 9:35 > To: Brandenburg, R. (Ray) van; draft-ietf-avtcore-idms@tools.ietf.org > Cc: avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-12.txt >=20 > Hi, >=20 > Looking at this latest version I have a comment. >=20 > section 14.4 defines the SPST registry. >=20 > Why isn't is adding the ETSI defined values from the start. If they are k= nown > and have well known reference I don't see any issues with putting in the > values into the registry at its creation. >=20 > Value Name Reference > ----- ---- --------- > 1 Synchronization Client section 7 of [RFCXXXX] > 2 [TS183063] > 3 [TS183063] > 4 [TS183063] >=20 >=20 > Cheers >=20 > Magnus >=20 >=20 > On 2013-07-29 10:48, Brandenburg, R. (Ray) van wrote: > > Hi, > > > > This version of the draft includes the final comments received during > > IETF LC and from Martin Thomson as Appsdir reviewer. > > > > Best regards, > > > > Ray > > > > On 29 jul. 2013, at 10:45, "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 > >> Core Maintenance Working Group of the IETF. > >> > >> Title : Inter-destination Media Synchronization using the > >> RTP Control Protocol (RTCP) Author(s) : Ray van Brandenburg > >> Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud > >> Kevin Gross Filename : draft-ietf-avtcore-idms-12.txt Pages > >> : 22 Date : 2013-07-29 > >> > >> Abstract: This document defines a new RTP Control Protocol (RTCP) > >> Packet Type and an RTCP Extended Report (XR) Block Type to be used > >> for achieving Inter-Destination Media Synchronization (IDMS). IDMS > >> is the process of synchronizing playout across multiple > >> geographically distributed media receivers. Using the RTCP XR IDMS > >> Report Block defined in this document, media playout information from > >> participants in a synchronization group can be collected. > >> Based on the collected information, an RTCP IDMS Settings Packet can > >> then be sent to distribute a common target playout point to which all > >> the distributed receivers, sharing a media experience, can > >> synchronize. > >> > >> Typical use cases in which IDMS is useful are social TV, shared > >> service control (i.e. applications where two or more geographically > >> separated users are watching a media stream together), distance > >> learning, networked video walls, networked loudspeakers, etc. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-avtcore-idms-12 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-12 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > Audio/Video Transport > >> Core Maintenance avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > This e-mail and its contents are subject to the DISCLAIMER at > > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ Audio/Video > Transport > > Core Maintenance avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From dwing@cisco.com Thu Aug 15 17:00:33 2013 Return-Path: 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 54DDA11E8220 for ; Thu, 15 Aug 2013 17:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.38 X-Spam-Level: X-Spam-Status: No, score=-108.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, 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 S8SAhDe+eign for ; Thu, 15 Aug 2013 17:00:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4684411E81C7 for ; Thu, 15 Aug 2013 17:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93; q=dns/txt; s=iport; t=1376611228; x=1377820828; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=F0p+1MDtDUt7j9iW8vHXBx6V+z7cVr5eGOEBu+Ux8RQ=; b=QE/DdYLvgGeCIzCX/M1kyrRqVr87ce73pIubsUOgOxmJXFJ0tRh/Cw+2 f8WwlQh3Jnrn5XhnKlKkOanOIuFYrHG+OdX24KaQWdybXq2wvFbH84j9Z JcfQkwvfDUV469ofPasGLob/hJYlhi+ZtY3A3WrWon6rv0ggywBaWITRE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsHANlqDVKrRDoJ/2dsb2JhbABbgwaNHLJ+gSQWbQMEgmU/gT6IIrojkFCDIncDiS2ON5FSgzsc X-IronPort-AV: E=Sophos;i="4.89,889,1367971200"; d="scan'208";a="86714902" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Aug 2013 00:00:25 +0000 Received: from sjc-vpn5-1481.cisco.com (sjc-vpn5-1481.cisco.com [10.21.93.201]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7G00N1Z004407; Fri, 16 Aug 2013 00:00:24 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Aug 2013 17:00:23 -0700 Message-Id: <28CCD750-AFA4-4ADC-93FA-83B606CBC050@cisco.com> To: "avt@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-avt-srtp-not-mandatory@tools.ietf.org Subject: [AVTCORE] review of draft-ietf-avt-srtp-not-mandatory-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 00:00:33 -0000 I reviewed draft-ietf-avt-srtp-not-mandatory-13. It is well-written and = complete. -d From dwing@cisco.com Thu Aug 15 19:18:41 2013 Return-Path: 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 25EEC11E8235 for ; Thu, 15 Aug 2013 19:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.49 X-Spam-Level: X-Spam-Status: No, score=-109.49 tagged_above=-999 required=5 tests=[AWL=1.109, 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 3uf6ur0JhaE2 for ; Thu, 15 Aug 2013 19:18:32 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC511E81AA for ; Thu, 15 Aug 2013 19:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8868; q=dns/txt; s=iport; t=1376619511; x=1377829111; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=wHMAtl+HHUORKsaEGmP+Xgj9F5Sfx1KH3/wV3uKAM8U=; b=NYRG3jdgRJkhmu2X/L83RNbv385sPFqX2w1uxoz1twugnlkmzzYBnE7z 0GZMSqnXZAHNv3A9+PBuV9jBL2JLLsXJ/34KOSFFHzA4PgEFncn5EbJDK EWZ9uVRCjjF6WNYcg61JSv6fsPxaL+sPJ4Kt6+WDpri8thUPCeZbLDyBy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQGAIKKDVKrRDoG/2dsb2JhbABSCYMGwBqBJhZtB4JlP4E+Lod0uh+PCoFGgyJ3A4ktjjeRUoM7HA X-IronPort-AV: E=Sophos;i="4.89,890,1367971200"; d="scan'208";a="85996477" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Aug 2013 02:18:30 +0000 Received: from sjc-vpn5-1481.cisco.com (sjc-vpn5-1481.cisco.com [10.21.93.201]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7G2IShZ021417; Fri, 16 Aug 2013 02:18:28 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Aug 2013 19:18:28 -0700 Message-Id: To: "avt@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-avtcore-rtp-security-options@tools.ietf.org Subject: [AVTCORE] comments on draft-ietf-avtcore-rtp-security-options-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:18:42 -0000 Overall a strong document, and I know it was difficult to write. My comments: In the Introduction, the end of Because of the heterogeneity of RTP applications and use cases, however, a single security solution cannot be mandated.=20 feels like it could include a citation back to = draft-ietf-avt-srtp-not-mandatory. In section 3.1, Depending on when AES-GCM is published compared to when = draft-ietf-avtcore-rtp-security-options is published, updating the = following paragraph might be prudent (so it no longer says "ongoing = work", as it will be published work at that point), AES-GCM: There is also ongoing work to define AES-GCM (Galois Counter Mode) and AES-CCM (Counter with CBC) authentication for AES-128 and AES-256. This authentication is included in the cipher text which becomes expanded with the length of the authentication tag instead of using the SRTP authentication tag. This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. In section 3.1.1,=20 s/cipher suits/cipher suites/ Section 3.1.4, suggest changing OLD: This can enable interworking between DTLS-SRTP and for example security descriptions or other keying systems where either part can set the key. NEW: This can enable interworking between DTLS-SRTP and=20 other keying systems where either party can set the key (e.g.,=20 interworking with security descriptions). (original says "either part", should say "either party"). Section 3.4 for consistency with the section title and the rest of the = section's text, I suggest: OLD: There does not appear to be significant usage of RTP over DTLS. NEW: There does not appear to be significant usage of DTLS for RTP. Section 3.6 says: Mechanisms have been defined that encrypt only the payload of the RTP packets, and leave the RTP headers and RTCP in the clear. =20 which immediately made me think, "ah, like SRTP." But then the rest of = the section goes on to describe non-SRTP object encryption (DRM). Can = that first sentence somehow be made clearer that this section is not = describing SRTP encryption, but object encryption? Afterall, SRTP also = leaves RTP headers in the clear. Also, the title of the section is = "Payload-Only Security Mechanisms", but the second paragraph discusses = the need for transport security (which is not 'payload security'). = Perhaps the section could be renamed to "Object Security" or "Digital = Rights Management" or some other term, so that the payload security and = transport security can both be discussed without exceeding the scope of = the section title. Section 4.1.1, s/might provided/might provide/ Section 4.1.3, Changing from "I", "you", and "your" to "host" and "peer" = would keep this section more consistent with the rest of the document. Section 4.1.3, I had some technical heartburn over these two paragraphs, = which together make it seem like DTLS-SRTP is weaker than Security = Descriptions, and the text claims this weakness is because DTLS-SRTP = sends the certificate hash over signaling whereas Security Descriptions = sends the session key over signaling: For example, consider a point-to-point communication system that uses DTLS-SRTP using self-signed certificates for key management, and SIP for signalling. In such a system the end-points for the DTLS-SRTP handshake have securely-established keys that are not visible to the signalling nodes. However, as the certificates used by DTLS are not bound to any PKI they can't be verified. Instead, hashes of the certificate are sent over the signalling path. If the signalling can be trusted not to collaborate on performing a man-in-the-middle attack by modifying the hashes, then the end-points can verify that they have established keys with the peer they are doing signalling with. Systems where the key-exchange is done using the signalling systems, such as Security Descriptions [RFC4568] or MIKEY embedded in SDP [RFC4567], enable a direct binding between signalling and key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual security depends on the trust one can place in the signalling system to correctly associate the peer's identity with the key- exchange. Of course, DTLS-SRTP does not need to rely solely on trust for identity, = which is described elsewhere in this same document. RFC4474 or a later = section of this same document should be cited in that first paragraph = (or in the Using Identities section, whichever the authors prefer), as = RFC4474 provides a way to ensure the DTLS-SRTP certificates are bound to = the identity provider's public key. Yes, RFC4474 has some deficincies = and perhaps those should be mentioned briefly (doesn't survive going = through an SBC, for example). I would add a citation and description of = RFC4474 to that first paragraph discussing DTLS-SRTP. The second paragraph I quoted of Section 4.1.3, I am confused that its = first sentence discusses Security Descriptions and MIKEY, but the = paragraphs second sentence starts with "Independent of DTLS-SRTP or = MIKEY in SDP" -- is this an editing mistake and that second sentence = supposed to read "Independent of **security descriptions** or MIKEY" ?? = If it is not an editing mistake, I admit I cannot parse that second = paragraph and it would benefit from a rewrite to make its point more = clear. Section 4.1.5 on privacy mentions relays. It might be useful to add a = citation to TURN as an example of a relay. Section 5.1: OLD: At the basic level DTLS has a number of good security properties. For example, to enable a man in the middle someone in the signalling path needs to perform an active action and modify the signalling message. NEW: At the basic level DTLS has a number of good security properties. For example, to enable a man in the middle someone in the signalling path needs to perform an active action and modify both the signalling .....................................................^^^^ message and the DTLS handshake. ...........^^^^^^^^^^^^^^^^^^^^^^^ Also, what is meant by "At the basic level"? That wording implies there = an identified problem/weakness at some other level (advanced level). Section 5.2,=20 Unless one uses a Identity provider and the proposed identity solution [I-D.ietf-rtcweb-security-arch], the web application still has the possibility to insert a MITM.=20 There are other ways to detect and prevent insertion of a MitM other = than an Identity provider -- such as verifying the certificate hash out = of band (verifying it matches what is printed on a business card, or = verifying the hash is the same as the previously-used hash with that = same user as described by ZRTP, as two examples). Could that be = re-worded so that Identity provider is just one way to avoid insertion = of MITM? Section 5.2, Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP certificates provide information that could possibly be re-used between session instances. Thus to prevent tracking, the same information can't be re-used between different communication sessions. Yes, but another solution (allowing the re-use of DTLS-SRTP = certificates, thus saving CPU resources to create new public/private key = pairs) is to have better TLS handshake, such as is being pursued for TLS = 1.2 so the certificates are exchanged later in the TLS exchange (after = the session is encrypted). I would suggest: OLD: Prevent tracking between sessions: RTP CNAMEs and DTLS-SRTP certificates provide information that could possibly be re-used between session instances. Thus to prevent tracking, the same information can't be re-used between different communication sessions. NEW: Prevent tracking between sessions: static RTP CNAMEs and = DTLS-SRTP certificates provide information that is re-used between session instances. Thus to prevent tracking, the = information is not re-used between sessions or the information is not sent in = the clear between sessions. Section 5.3, I suggest: OLD: If these goals are to be meet with the specified solution there needs to exist trust in that neither the implementation of the client nor the platform the application runs can be accessed or modified by the attacker. NEW: To meet these goals with the specified solution the client=20 implementation and the application platform are trusted to=20 protect against access and modification by an attacker. -d From coien@cisco.com Fri Aug 16 05:39:20 2013 Return-Path: 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 1C8B211E8271 for ; Fri, 16 Aug 2013 05:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 NCFPzrTz2I8j for ; Fri, 16 Aug 2013 05:39:02 -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 B960411E8270 for ; Fri, 16 Aug 2013 05:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6225; q=dns/txt; s=iport; t=1376656742; x=1377866342; h=message-id:date:from:mime-version:to:subject; bh=uXc0F4QzITefx/O3mOx9cb5gvOjvw11LCcmyf6ij/3c=; b=H4m1+B6gm3FPzAGOmA+6D4jLKDdbTIfUe8T6lVEwxcQYjwPuUYUv/gjc wW6o8ru7DnEwHLUSONBduhtiTdLx8sxeipBKX3/WRvFNAjFrAW1wwkGl4 t4tEYubpwvtvzTfWvvtMvZbwjW/Y32F8a6pD53+68QvkQlX4DkZ4JuSW5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAIccDlKtJXG9/2dsb2JhbABbgwaBBoh3t0sWdIMjPRYYAwIBAgFLDQgBAYgMmUagKpRpA4h1jm+GKYssgx6CKA X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208,217";a="248190739" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2013 12:39:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7GCd0M7005168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Aug 2013 12:39:00 GMT Received: from [10.47.38.148] (10.47.38.148) by xhc-aln-x12.cisco.com (173.36.12.86) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 16 Aug 2013 07:38:59 -0500 Message-ID: <520E1D77.4030101@cisco.com> Date: Fri, 16 Aug 2013 14:39:19 +0200 From: Christian Oien User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------040406010709080503050104" X-Originating-IP: [10.47.38.148] Subject: [AVTCORE] Observation in RFC 3711 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:39:20 -0000 --------------040406010709080503050104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hello WG, After reading RFC 3711, and making an implementation in the context of RFC 4568 for the default ciphers, and then, afterwards, looking at a couple of existing implementations, I have come to the conclusion of having found a mismatch between the specification and the existing implementations, including libsrtp. RFC 3711 section "4.3 Key Derivation" describes a formal operator DIV, with a result having the same number of bits as its first operand. For SRTP the first operand is the SRTP packet index, which is a 48-bit quantity, meaning that the