[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
----------------------------------------------------------------------