[avtext] AUTH48 change in draft-ietf-avtext-avpf-ccm-layered
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 23 February 2017 14:10 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F566129869 for <avtext@ietfa.amsl.com>; Thu, 23 Feb 2017 06:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYIz2uAjo798 for <avtext@ietfa.amsl.com>; Thu, 23 Feb 2017 06:10:00 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC62A129697 for <avtext@ietf.org>; Thu, 23 Feb 2017 06:09:59 -0800 (PST)
X-AuditID: c1b4fb30-eabff70000002c77-af-58aeed340ae1
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id D6.27.11383.43DEEA85; Thu, 23 Feb 2017 15:09:58 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Thu, 23 Feb 2017 15:09:56 +0100
To: "avtext@ietf.org" <avtext@ietf.org>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <b8878dce-aa0f-14cf-e89c-db09a5c0132c@ericsson.com>
Date: Thu, 23 Feb 2017 15:09:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGbHdSdfs7boIg2nPeCw+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP175jIXzFOo+P7mFXsD4yHJLkZODgkBE4nV+zvZuhi5OIQE 1jFK/Hr3gRHCWc4oMePxZCaQKhEBdYk70y+wgdhsAhYSN380gtnCAjYSMy/+ZwGxeQXsJQ7M +M7axcjBwSKgKnF+eTVIWFQgRmJv/30miBJBiZMzn7CAlDADlT/YWgYSZhaQl2jeOpsZxBYS 0JZoaOpgncDIOwtJxyyEjllIOhYwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAybg1t+ G+xgfPnc8RCjAAejEg9v4fK1EUKsiWXFlbmHGCU4mJVEeBe/WBchxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA6O3YdDZe86zaq+fmGU391XX7L5XhzMy ZVLfMe25MH3VIg2X4KJ+zyNan46eV7g7gzu8pXrWg3K1z95iZZ8WPslO0F4cflo20Hxr0PXi mR3G10Sn19xfYj5t/1TblQ7+a4MrfqUnl95Yu2P51C0moRe0/iVvkdFfVrqfu6lu88oPT+tr Dp45xiKuxFKckWioxVxUnAgAMafnpBcCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/HNyrLksjfvU0lOARNzw6tX12wss>
Subject: [avtext] AUTH48 change in draft-ietf-avtext-avpf-ccm-layered
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avtext/>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 14:10:01 -0000
WG, The authors have found in a questionable sentence when doing our AUTH48 reviews. In Section 5, below copied in the form edited by the RFC-Editor. The sentence in question from paragraph 2 is: In such a scenario, it is potentially, though not necessarily, counterproductive to send a decoder refresh point on all RTP streams using that payload format and SSRC. The issue with the above is that the this doesn't correctly considers Mult-stream transport (MSST and MSMT). Thus, we suggest to change this to: In such a scenario, it is potentially, though not necessarily, counterproductive to send a decoder refresh point on all layers for that payload format and media source. Thus, changing "all RTP streams" to "all layers" and "SSRC" to "media source". This encompasses all the cases we can consider. Any concerns with this change? Unless we hear something blocking this by the 2nd of March, we will continue with publication. 5. Identifying the Use of Layered Bitstreams (Informative) The above modifications to RFC 5104 unambiguously define how to deal with FIR when layered bitstreams are in use. However, it is surprisingly difficult to identify the use of a layered bitstream. In general, it is expected that implementers know when layered bitstreams (in its commonly understood sense: with inter-layer prediction between pyramid-arranged layers) are in use and when not and can therefore implement the above updates to RFC 5104 correctly. However, there are scenarios in which layered codecs are employed creating non-pyramid-shaped bitstreams. Those scenarios may be viewed as somewhat exotic today but clearly are supported by certain video coding syntaxes, such as H.264/SVC. When blindly applying the above rules to those non-pyramid-arranged layering structures, suboptimal system behavior would result. Nothing would break, and there would not be an interoperability failure, but the user experience may suffer through the sending or receiving of decoder refresh points at times or on parts of the bitstream that are unnecessary from a user experience viewpoint. Therefore, this informative section is included that provides the current understanding of when a layered bitstream is in use and when not. The key observation made here is that the RTP payload format negotiated for the RTP streams, in isolation, is not necessarily an indicator for the use of a layered bitstream. Some layered codecs (including H.264/SVC) can form decodable bitstreams including only (one or more) enhancement layers, without the base layer, effectively creating simulcastable sub-bitstreams within a single scalable bitstream (as defined in the video coding standard), but without inter-layer prediction. In such a scenario, it is potentially, though not necessarily, counterproductive to send a decoder refresh point on all RTP streams using that payload format and SSRC. It is beyond the scope of this document to discuss optimized reactions to FIRs received on RTP streams carrying such exotic bitstreams. One good indication of the likely use of pyramid-shaped layering with inter-layer prediction is when the various RTP streams are "bound" together on the signaling level. In an SDP environment, this would be the case if they are marked as being dependent on each other using "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] and layer dependency [RFC5583]. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [avtext] AUTH48 change in draft-ietf-avtext-avpf-… Magnus Westerlund
- Re: [avtext] AUTH48 change in draft-ietf-avtext-a… Roni Even