Subject: [avtext] AUTH48 change in draft-ietf-avtext-avpf-ccm-layered

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Feb 2017 15:09:55 +0100

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: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Mon, 27 Feb 2017 11:31:11 +0000

Hi,
I agree with this new text as more precise even though I would expect this behavior as in the new text also from someone reading the current text.
So I support making the change
Roni

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: יום ה 23 פברואר 2017 16:10
> To: [email-masked]
> Subject: [avtext] AUTH48 change in draft-ietf-avtext-avpf-ccm-layered
> 
> WG,
> 
> reviews. In Section 5, below copied in the form edited by the RFC-Editor. The
> sentence in question from paragraph 2 is:
> 
> 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:
> 
> Thus, changing "all RTP streams" to "all layers" and "SSRC" to "media source".
> This encompasses all the cases we can consider.
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext