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

[Roni Even <[e-mail]>]

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:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: יום ה 23 פברואר 2017 16:10
> To: [e-mail]
> Subject: [avtext] AUTH48 change in draft-ietf-avtext-avpf-ccm-layered
> 
> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> avtext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avtext