Re: [avtext] Adam Roach's No Objection on draft-ietf-avtext-lrr-06: (with COMMENT)

[Jonathan Lennox <[e-mail]>]

Hi, sorry for the delay in responding.  Responses inline.

> On Jun 19, 2017, at 8:12 PM, Adam Roach <[e-mail]> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-avtext-lrr-06: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 2.1: "...requires that a spatial layer be encoded in a way that
> references only lower-layer subpictures..." had me puzzled for quite some time,
> as I didn't think this was an inherent charateristic of *any* codec. It took
> quite a bit of re-reading before I figured out that this is referring only to
> the refresh packets themselves, not an intrinsic constraint on the stream
> across all time. Rephrase.

I’ve tried to rephrase this:

	For spatial (or quality) layers, in normal encoding, a subpicture can
	depend both on earlier pictures of that spatial layer and also on
	lower-layer pictures of the current picture.  A layer refresh,
	however, typically requires that a spatial layer picture be encoded
	in a way that references only the lower-layer subpictures of the
	current picture, not any earlier pictures of that spatial layer.

Is that clearer?

> The description of temporal scaling introduces the same confusion.

Similarly, added a clause:

	For temporal layers, while normal encoding allows frames to
        depend on earlier frames of the same temporal layer,
        layer refresh requires that the layer be
       "temporally nested”, 

> I had the same heartburn as EKR regarding "(opt)" in Figure 5 -- given that it
> appears at the end of the data, there is a real risk that some implementors
> will attempt to literally omit the field rather than setting it to 0. Please
> remove the "(opt)". [n.b., I'm on the fence as to whether this should be a
> Comment or a Discuss, as it has the risk of introducing actual interop issues
> in the field].

Fixed, regardless.

> The description for "Seq nr." indicates that the number is increased by "1
> modulo 256." While it's certainly possible to figure out what is intended here,
> what this says on its face is to increase by one, as "1 modulo 256" is always
> one. Please rephrase to indicate that "modulo" applies to "Seq nr." instead of
> applying to "1”.

Changed to

	The sequence number SHALL be increased by 1 for each new command (modulo 256, so the value after 255 is 0)


> Section 3.2 indicates that the technique should not be used for picture losses
> (packet losses, presumably?), but instead for situations where not sending it
> would "render the video unusable."  This all seems very subjective and
> ill-defined for normative statements. Please be precise with what you mean by
> "picture losses," and please give an example of when LRR SHOULD be used --
> perhaps my imagination is a bit dull today, but I cannot come up with
> situations in which LRR would be appropriate, given this "MUST.”

Changed to:

	LRR MUST NOT be sent as a reaction to picture losses due to packet
	loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead.
	LRR SHOULD be used only in situations where there is an explicit
	change in decoders' behavior, for example when a receiver will start
	decoding a layer which it previously had been discarding.

Is that clearer?